netail.net

_ 論文 ▲

OOPSLA 2002 投稿論文のうち，タイトルが目を引いたMira Mezini, Klaus Ostermann:``Integrating Independent Componentswith On-Demand Remodularization'' を読んでみた．

interface として expect, provide の二通りを定義し，expect を使って provide を実装する implements class とprovide を使って expect を実装する bind class とを作成し，collaboration = implements + bind という形式でペアにしてそれらを結合して利用する，というもの．expect/provide interface の発想は今までにもあったが，fluid (流動的?) AOP，実行時のペアの差し替えなども視野に入れている様子．

これは class -> aspect 方向の依存辺を引くという点がaspectual collaboration などと異なっていて，自分でやろうとしている仕事と近い立場．

ただ，bind する側はすべての expected を実装する必要があって，３者以上が参加する collaboration を定義するのは難しそう．また，アクセス制限なども考慮されてないので，そのあたり微妙な問題を含んでいる気がする．もう少し，自分のネタとの比較は真剣に検討したほうがよさそうだが，同じような立場を取る人が他にもいる，というのは心強い．

_ delphi PCL ▲

Persistent Component Library に含まれているHashTables.pas にバグ発見．

function THashTable.Current: Pointer; の中身誤: if (FPosition >= 0) and (FPosition < FCapacity) and正: if (FPosition >= 0) and (FPosition < FCapacity * 2) and

これのせいで TStringTable.Current, TStringTable.CurrentKey が正しく動かない．なぜだろうと思っててひたすら内部をデバッグしていて気付いた．（他の条件節ではすべて FCapacity * 2 なのに，ここだけ * 2 がなかった）

_ 読書 ▲

ネビル・シュート「パイド・パイパー~自由への越境」読了．古い作品の復刊だが，構成として非常によくできている，と思う．たくさんの子供を連れて戦火の中を移動する，強い責任感を持って行動する老人の頑張りが印象強い．別に大事件が起こるわけではないけれど，追われる側の緊張感がある．

長い旅路っていうネタは TRPG でもやってみたいと思ってるので，そのときにはこの作品も参考になるかも，とか思う．

さて，パスポート申請に行ったついでに買ってきたアン・マキャフリィ「竜の貴婦人(上・下)」を読み始めることにする．テーマは「モレタの飛翔」で，最終的にどうなるかはバラードとして既に他の作品で語られているが，どうしてそうなったのか，というところが気になるので読んでみる．

_ Bookmark Manager ▲

非階層ブックマークを実装するべく，久しぶりに Delphi を起動．カテゴリを扱うために文字列の集合クラスを作りたいが，TSet なんて標準では定義されてない．Tommi Johtela の公開している Persistent Component Library を使わせてもらうことにした．

紹介記事：http://www.undu.com/Articles/991117a.htmlダウンロードはここから：http://www.cs.utu.fi/tjohtela/software.htm#PCL

いちおう集合クラスも定義されていたのだが，TSet はTItem とかいうクラスしかアイテムとして取れなかったので，いちいち String のラッパーを生成するのが面倒そう．そこで，StringTable (KeyがStringなHashtable)を利用して，関連付ける値としては TObject に Singletonなオブジェクト１個を食わせる形式で，自前の StringSet を定義することにした．

_ パスポート ▲

パスポートの申請に出かける．申請書を書いて，戸籍抄本や住民票と一緒に提出するだけなのだが，この手の形式的な書類書きは苦手なので，妙に疲れた．

_ [論文]モデルとコードの対応調査 ▲

Alexander Egyed:Resolving Uncertainties during Trace Analysis.Proceedings of the 12th FSE (FSE2004), pp.3-12,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

Trace Analysis って何だろうと思っていたら，実行履歴の解析ではなくて，モデルとソースコードの対応（いわゆる追跡性）の解析だった．

モデルとコードの対応を included/shared/excluded で記述して，Footprint Graph というものでrefine していくらしい．"M is F" 以外に "M isAtLeast F" や "M isAtMost F" のように持ってる知識を適度に定式化して入力として与えるらしい．

今のところ，こちらの研究との関連は特にないようなので，置いておく．

_ [Java]表明オプション ▲

今日のはまり．実行時に "-ea" オプションを有効にしないと assert 文は検査されない．

_ [OUCC][ゲーム]ドラゴンクエスト３（ファミコン版）勇者１人でのバラモス退治 ▲

ドラクエ３の勇者１人旅でのバラモスの倒し方が Nelcy＠OUCC らによって確認された．

レベルが60超えてもHPが足りないので（409で成長が止まった），サマンオサでクマとサルを相手に修行することがポイント．グリズリーがちからのたね，コングがいのちのきのみを１時間〜２時間に１個くらいは落とすので，それを集めて，HPが459，ちからが206となった時点で初めて倒せた．

このときレベルは74，MPは256．すばやさはほしふるうでわつきで255．レベルアップごとに，MPが3〜4伸びるまではリセット．ちからのたねは3，いのちのきのみは5が出るまで同様にねばる．

マホトーンで呪文を封じ，くさなぎの剣で守備を 0 まで下げてから，本格的に戦闘開始．攻撃３回→ベホマの繰り返しでダメージを累積させられるかどうかが勝利できるかどうかに直接影響する．攻撃３回で，420〜480程度のダメージを与えられれば，自動回復４ターン分の400を差し引いても，20〜80程度累積させることができる．で，蓄積した値の記録を取りながら戦い，蓄積ダメージが0に戻るようなら一度仕切りなおし．会心の一撃が出て，ダメージがある程度乗ってきたら，あとはギガデインの連打で決着をはかる．

バラモスはHP900，自動回復が100．バラモスからの攻撃は，マホトーンを使って魔法を封じると，攻撃２回→炎＋攻撃→攻撃＋炎の繰り返しになり，ドラゴンメイルを着ると１ターンに100〜130程度の範囲で分布する．HPが480程度あれば，３回攻撃→回復のリズムをほぼ確実に保てるので，確実に勝利できると思われる．

ちなみに，勝利時のダメージ数値列は以下の通り．

136, 122, 163, ベホマ, 172, 131, 163, ベホマ, 
251(会心), 282(会心), 127, ベホマ, 
199(ギガデイン), 219(ギガデイン), 186(ギガデイン), ベホマ,
181(ギガデイン), 208(ギガデイン), 214(ギガデイン) →勝利

詳細の写真（ステータスやら退治した瞬間など）いくつかはこちら．

_ [読書][AspectJ] ユースケースがアスペクトになる ▲

Aspect-Oriented Software Development with Use Cases という本が ACM の Online Books プログラムの無料で読める範囲に入ってたので読んでみたら，そういう記述があった．

ユースケースのシナリオを書いていくと，シナリオのうち特別なケースでのみ実行される alternate flow や，定義済みのシナリオを拡張する extends 関係が登場してくるが，これらは複数のクラスに影響を与えるので，クラスを拡張するアスペクトとして表現するほうが良い，と解説していた．（アスペクトが使えることを強く意識したシナリオの書き方になっているような気もする．）

ユースケースは，それに対応する「ユースケーススライス」というモジュールとして実現できる．ユースケース固有のクラスはそのままクラスとしておけるが，他のクラスを拡張する部分はアスペクトとしてインタータイプ宣言ないしポイントカット＋アドバイス表現を用いて記述する．これによって，特定のユースケースに関するコードを他のユースケース用のコードから独立したままに保つ．

異なるユースケースに所属するコードを分離したままで管理するために，ユースケース固有のコードを，それぞれ独立した（ユースケース名を付けた）ディレクトリに配置してしまおう，とも言及されていた．Eclipse では，コンパイル対象のソースコードが入ったディレクトリを指定することができるが，そこで各ユースケースのディレクトリを列挙すれば良いらしい．

非機能的要求も，できるだけ infrastructure use case としてシステム側の振る舞いを記述し，普通のユースケース（application use case）との関係を整理しておくらしい．そうすることで，システムのサービスを担うアスペクトなんかも設計時にきちんと扱うことができる．

別々に記述したものはそのまま混ぜずに置いておくという一貫した方針になっているので，けっこう読みやすい本だと思う．そのかわり，ユースケースとコードの中間（分析モデルとか）については扱いが小さい気がした．

(追記) この本，日本語訳が出てますね．まったく気づいてませんでした．