netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2005-12-26 [長年日記] ▲
_ [work] 学位申請書類とかを作る ▲
作業をする．さりげなく，論文内容の要旨が1000字程度と指定されていて，今手元にある日本語版を数えてみたら約2500字．これはさすがに1000字「程度」には収まらないよなぁ，とため息．
_ [論文] アクセス権限を与えるアスペクト ▲
K. Chen: Using Dynamic Aspects for Delegating Fine-Grained Access Rights.
AO-ASIA Workshop, proceedings of APSEC 2005.
管理者が書いたアクセス管理ファイルの内容に従って，対応するユーザのオブジェクトに権限付与のアスペクトが貼りつく，みたいな動的アスペクトの使い方．
静的なアスペクトがいちいち設定ファイルを読みに行くのに比べたら，いきなりオブジェクトにコードを付加してやるほうが高速化できそうな気もするけど，性能的評価はまだこれからの様子．
_ [論文] 要求〜設計段階でのメトリクスの提案 ▲
M. Kassab, O. Ormandjieva, and C. Constantinides: Providing Quality Measurement for Aspect-Oriented Software Development.
ユースケースのシナリオをシーケンス図で記述したとき，シナリオ間で共通部分列があるかどうかで，各シナリオが部分列を持たないほど，そのユースケースモデルの凝集度が高いと判断しよう，とかいったメトリクスの提案．
設計段階に入る前に，要求ごとの絡み合いを見て，複雑になりそうなところほど設計段階でリソースを投入するといった考え方もしているらしい．
_ APSEC Keynote やらのメモ ▲
これで，APSEC 2005 関係の記述はラスト（のはず）．
APSEC の基調講演での話題として，Goal-Oriented Model の使い方というのが紹介されていた．
システムが達成すべき機能的なゴールから，それを達成するための小目標へ，そして手段へと段階的に分解していく．
ここまでは知っていたけれど，末端のそれぞれの実現方法が，他のゴール（品質とか）にもどのような影響を与えるかを評価して，全体的に良い影響を与える選択肢を選ぶ，といった設計を決定する上での指針にもなることはまったく気づいてなかった．
また，別の keynote での質疑応答で，Ontology についての話が上っていた．会社間でのデータ交換時などに，データの項目名以外にも，データの中身の表記法（たとえば会社名を記述するときの言語とか，末尾の Ltd. とかをどうするかとか）での問題もあって，今のところは ad-hoc に対応しているらしい．Ontology の重要性をまともに説明してもらえたのは初めてな気がする．
2005-12-25 [長年日記] ▲
_ Windows でのマウスのホイール操作のフック ▲
Volume Deskbar 用に導入する気はないけど，いちおう調べてしまったので，まとめ．
フックを仕掛けるときは，SetWindowsHookEx 関数を使う．
// フック: ４番目のパラメータの値は，仕掛けたいスレッドによって適宜変更
// HInstance は，DLL への参照をあらわす変数
MouseHookHandle := SetWindowsHookEx(WH_MOUSE,
MouseHookProc,
HInstance, 0);
// ここで，MouseHookProc の型は，次のとおり．
function MouseHookProc(code: Integer; wparam:
WPARAM; lparam: LPARAM): LRESULT;
lparam の中身は，PMouseHookStruct（MOUSEHOOKSTRUCT へのポインタ）なのだが，ホイールマウス用の拡張メンバが付いたMouseHookStructEx へのポインタとして扱うと，後ろにある mouseData へのアクセスが可能になる．
// 構造体やらの定義
// Delphi 7 では， windows ユニットには定義が存在しないので
// 自前で定義が必要
PMouseHookStructEx = ^TMouseHookStructEx;
tagMOUSEHOOKSTRUCTEX = packed record
MouseHookStruct: TMouseHookStruct;
mouseData: DWord;
end;
TMouseHookStructEx = tagMOUSEHOOKSTRUCTEX;
// 参照方法の例
// メッセージが WM_MOUSEWHEEL のとき，
// mouseData の上位16ビットが，ホイールのスクロール量．
function MouseHookProc(code: Integer;
wparam: WPARAM; lparam: LPARAM): LRESULT;
var
mouse: PMouseHookStructEx;
delta: Word;
begin
if (code >= 0) and (wParam = WM_MOUSEWHEEL) then begin
mouse := PMouseHookStructEx(lParam);
delta := HiWord(mouse.mouseData);
// delta の Word 型は符号なし16ビットなので，
// 符号ありに変換してから使用する
:
_ [論文]メソッドの呼び出し順序についての制約記述 ▲
Tran, N., Abramson, D. and Mingins, C.: Call-Ordering Constraints.
Proceedings of APSEC 2005, pp.291-298, Taipei, Taiwan, December 2005.
Design by Contract の一環として，特定クラスのメソッドの呼び出し順序，それらのメソッドが「必ず呼び出すメソッド」「呼び出すことはないメソッド」（プロトコル）を指定しよう，という提案．基本的には，メソッド呼び出しが状態遷移を表す非決定性オートマトンで定義される．
Behavioral Subtyping として，「親クラスで valid な呼び出し順序は，子でも valid である（子で失敗するなら親でも失敗する）」という条件を指定している．また，必ず呼び出すメソッド，呼び出すことはないメソッドについては，減らすことはできないが，増加することは許している．多重継承のときは，すべての親のプロトコルを満たす必要がある．
必ず呼び出すメソッド・禁止のメソッドについては，メソッド呼び出しごとにスタックに積み上げていき，新しいメソッド呼び出しが「呼び出すリスト」に該当しているなら，リストから（もう呼び出されたので）削除し，禁止メソッドに該当しているときは，違反としてプログラムを停止する．
実装は CLI 上で行なっている様子だが，手法としてはわりと素直な印象がある．
_ [論文] 起こりうるメソッド呼び出し列からの影響波及解析 ▲
L. Badri, M. Badri, and D. St-Yves: Supporting Predictive Change Impact Analysis: A Control Call Graphs Based Technique.
Proceedings of APSEC 2005.
単純なコールグラフで，呼び出し関係を追跡すると，順番の考慮がないのでほとんどのメソッドが「影響を受ける」判定になってしまうので，制御フローグラフ上で，メソッド呼び出し頂点だけを残した「Control Call Graph」を使うことを提案した論文．
記法として，繰り返し，選択，省略可能を {m1}, (m1/m2), [m1] と書くことでメソッドの呼び出し列を表現していた．あくまで静的アプローチだが，動的解析からこのような列を見つけられるなら動的な影響波及解析も可能だろう，と言っていた．
2005-12-22 [長年日記] ▲
_ Volume Deskbar 1.0.3 リリース ▲
改良色々．今回は，提案された案をほとんどそのまま受け入れた感あり．ボリュームコントロールやオーディオのプロパティが開けるようになったり，WAVEがコントロールできるようになったり，日本語メニュー表示が可能になったり．さすがに項目数が増えてくると日本語メニューでないと厳しい人もいるよね，ということで付けてみた．
テスト項目を列挙してみたらもう40件くらいになっていたが，タスクバーを左右や上側に表示したケースや，ログオフして再ログオンとかいうのがテスト項目に入ってたりして，自動化がほぼ不可能なところが厳しい．
_ [論文] 非決定的要素に対するテスト ▲
L. Wildman, B. Long, and P. Strooper: Dealing with Non-determinism in Testing Concurrent Java Components
Proceedings of APSEC 2005.
並行動作するプログラムのテストケースをいかに記述し，テストするかというお話．
基本はモニタ制御で，時刻を進めながらイベントを処理するようなのだが，Producer-Consumer パターンで，Consumer A, B ２つがデータを待ち受けているとき，次に Producer ２つが put した２つのデータのどちらを Consumer A が受け取るかは非決定的になってしまう．
しかし，スレッドの実行順序に JVM 依存な仮定を置くのも嫌なので，とりうる状態の組み合わせの宣言を可能にすることで，テストケースを簡潔に記述できるようにしている．
_ [論文] コンポーネントのアップグレードに対する回帰テストケースの選択 ▲
A. Pasala and A. Bhowmick: An Approach for Test Suite Selection to Validate Applications on Deployment of COTS Upgrades.
Proceedings of APSEC 2005.
Windows のパッチなんかが当たったときに，回帰テストをシステム全体にかけるのは非現実的なので，Component Interaction Graph (CIG) という，Windows 内部コンポーネントに関する動的コールグラフを作り，各テストケースがどの Windows コンポーネントを使っているか調べておく．
そして，アップグレードが起きたら，そのコンポーネントを使っているテストケースだけを回帰テストしたらいいよね，というだけなのが，Windows パッチに実施したら，だいたい半分くらいのパッチについては回帰テスト不要だったことが判明したらしい．
_ [論文]相互作用のプロトコルをオートマトンで記述 ▲
Y. Jin and J. Han: Consistency and Interoperability Checking for Software Component Interaction Rules.
Proceedings of APSEC 2005.
interaction protocols とは，サービスの呼び出し順序に対する相対的な順序の指定． 以下のようなパターンとスコープを組み合わせて定義するらしい．
Patterns: OP is absent / OP exists at most n times / OP exists at least n times / OP1 precedes OP2 / OP1 leads to OP2 Scopes: globally / before OP3 / after OP3 / after OP3 until OP4 / between OP3 and OP4
これらを使って，一貫性とか，システム全体でプロトコルに従って動くか検査するよーという話．
2005-12-21 [長年日記] ▲
_ AspectJ 5 がリリースされていた ▲
12月20日付け．これで，アノテーション，可変引数，Generics などにアスペクトをくっつけることができる．ただ，これだけ syntax ベースな join point の記述が複雑になってくると，アスペクトってもっと単純な仕組みだけで何とかならないの？とも思ってしまったりする．
ふと，アーキテクチャ記述言語で書いたとおりに Dependency Injection でオブジェクトを接続してくれて，外部には facade インタフェースだけ出してくれる，とか，そういうのはできるんだろうか．アーキテクチャ記述を読んで GluonJ 記述を生成すればいける？
2005-12-17 [長年日記] ▲
_ APSEC ３日目 ▲
基調講演＋AO-ASIAワークショップのみ．発表＋質疑で約30分ずつのペースで続いた．会場が寒かったのでヒーターのまわりに集まって，という形式は珍しかったかも :-)
ユースケースのシナリオをシーケンス図で記述したとき，シナリオ間で共通部分列があるかどうかで，各シナリオが部分列を持たないほど，そのユースケースモデルの凝集度が高いとして計ってはどうか，とかいう発表があって，わりと面白かった．
_ コンポーネントモデルとアスペクト ▲
AO-ASIA ワークショップにて，Pointcut + Advice 形式で，コンポーネントの接続しかしないことも多いのだから，コンポーネントモデル（アーキテクチャ記述とかの）上での一種のコネクタのようなものと考えられる，といった感じの千葉先生の話はわりとしっくりしたものだと感じられた．
あるアスペクトが，「オブジェクトＡからオブジェクトＢのメソッドを呼び出した時に動作する」と記述することを「アスペクトがオブジェクトの実装の詳細に依存している」のでは？と気になるのは，コンポーネント間の接続（仕様として記述された public な接続）と，オブジェクトの内部的メソッド呼び出し（実装の詳細としてのメソッド呼び出し）とが混同してしまうせいかもしれない．
Javaだとメソッド呼び出しを仕様上のものか実装のものか区別できないので仕方がないけれど，Dependency Injection での明示的なオブジェクトの接続の記述とか，UMLのシーケンス図とかに登場するメソッド呼び出しについては，設計なんだからその順序に依存したアスペクトくっつけてもいいよね（ついでに実際のクラスの振る舞いがその前提と違うようだったら検出する），とかなったりするかな，どうかな？
