netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2005-12-03 [長年日記] ▲
_ [hyCalendar] ログオフ時にオプションが保存されない問題を修正 ▲
ログオフ時は，FormClose イベントがなぜか飛んでこないのでファイル保存に失敗していた問題を修正．素直に CloseQuery で true を返すタイミングで保存すればいい，ということに気づくまでにずいぶん時間がかかった．
他に何事もなければ，このバイナリが 1.3.3 になる予定．ドキュメント書く時間とかの都合で，リリース自体は少し先送り．
2005-12-04 [長年日記] ▲
_ [論文]タスク間の依存関係の解析をソフトウェアモジュールに適用 ▲
Neeraj Sangal, Ev Jordan, Vineet Sinha, Daniel Jackson: Using Dependency Models to Manage Complex Software Architecture.
Proceedings of OOPSLA 2005, pp.167-176, San Diego, California, USA, October 2005.
Dependency Structure Matrix (DSM) という，タスク間の依存関係をチェックするための道具をソフトウェアモジュールに適用してみました，というお話．DSM は，コードクローン分析なんかで使ってるプロット図に似ていて，要素を横軸と縦軸に並べておき，縦軸の要素から横軸の要素へ依存関係があるときに，そこにチェックを付ける．通常，タスクは作業順序をあらわすので，すべての依存関係が対角線より下側に来るように，タスクを並べ替えたり，相互依存したタスクを１つにまとめたりするらしい．
それをモジュール間の依存関係に適用すると，うまく階層化されたシステムなら相互依存関係がないので，対角線より下側にモジュールが整列してくれる．
相互依存した複数のタスクをまとめるアルゴリズムを使って，相互依存したモジュールをグループ化したり，パッケージ単位などで「View パッケージは Model パッケージに依存する」といった設計ルール（A can use B, A cannot use B）を記述したりして，ソフトウェアの依存関係を整理する．
依存関係のパターンを見ることで，うまくインタフェースが整えられたサブシステムであったり，あるいは他のモジュールと相互に依存した問題のある要素なんかを発見できるらしい．
論文自体は，実際にソフトウェアに適用したケーススタディが解説されている．手法自体はシンプルで，モジュール間の依存関係さえ抽出してくれば導入できるので，けっこう便利そう．単なるモジュール間の参照関係の整理以外でも使い道があるかもしれない．
_ [論文] Role の依存関係の明確な定義 ▲
Daniel Chernuchin and Gisbert Dittrich: Dependencies of Roles.
Workshop on Views, Aspects and Roles (VAR 2005) at ECOOP 2005.
静的な Role の活用についての position paper．Role = ロールの名前，属性の集合，メソッドの集合として定義したとき，クラスを Role の集合と，Role 間の依存関係によって定義しようという提案．
Role を一般的な(C++などにおける)クラスとして考えると，この提案でのクラスは多重継承を使って定義されたサブクラスと見ることができる．このとき，複数の Role 間で，常に等しい値を共有する属性を equality 関係としてクラス側に定義する．また，意味的に同じメソッドが存在する場合も，メソッド間の equality を定義する．また，ひとつの Role の属性が変更されたときに，その変更に反応して動作するメソッドを dependent 関係として定義する．
これらを使うと，各処理ではオブジェクトの特定の側面だけを見て処理を実行することができ（るはずで），多重継承なんかよりも Role 間の関係を整理しやすくできるかもしれない．
論文では，これ以外に，継承関係なんかにも言及がある．
_ [ゲーム][OUCC]僧侶＆魔法使いでバラモス退治 ▲
戦士・武闘家・商人・遊び人の４人パーティとどちらが楽かという話になって，試みられた結果．
勇者１人でのバラモス退治に比べたら圧倒的に楽と思われる僧侶＆魔法使いだが，攻撃が２人に集中し，意外と苦しいことが判明（サル相手の修行が必要なかったという意味では勇者より楽だったが）．
僧侶はLv30台後半から力が60程度で成長が止まってしまい，バイキルト＋ルカニを使っても与えるダメージは100〜130程度．逆に魔法使いはLv30台からHPとすばやさが伸び始めてかなり強くなるものの，メラゾーマは50％くらいの確率でしか効かないので倒すのは難しい．
結局，魔法使いは１ターン目に僧侶にスカラをかけ，あとはバイキルトを僧侶にかけてからモシャスで僧侶に変身．その間に僧侶はラリホーでバラモスを眠らせ，フバーハ，マホトーン，ピオリム，マヌーサ，ルカニで戦闘準備．
僧侶が攻撃し続けてバラモスの自動回復100をキャンセルし，僧侶に変身した魔法使いはベホマで味方を回復しつつ時々バギクロスで攻撃支援という長期戦でぎりぎり倒せた．とはいえ，マヌーサで攻撃を何度も回避したり，バギクロスが最大ダメージが出たりと，かなり幸運には支えられている．
モシャスを使うと，攻撃力や防御力，使える呪文はコピーするが，装備による魔法・ブレス耐性，スカラなどの魔法による上昇分はコピーされない．また一度死んでもモシャスの変身は解除されない．このあたりの細かい特性のおかげで，スカラとバイキルトを僧侶にかける（スクルトを使わない）といった戦い方になっている．今回は関係なかったが，ドラゴラムを使った場合も，防御力とすばやさが変化するので，スカラの効果などは失われる．マホカンタの効果は，これら変身によって消えることはない様子．
僧侶はゾンビキラー，まほうのよろい，みかがみのたて，てつかぶと，Lv41．魔法使いはどくばり，てんしのローブ，ふしぎなぼうしでLv42．２人ともHPは230程度，MPは220程度．
ちなみに，魔法なしパーティのほうは，防御攻撃のおかげで，Lv30台前半で勝利している．こちらはくさなぎの剣＋攻撃だけ．バラモスまで薬草が足りないので（途中のバリアのせい），わざと死んでせかいじゅのはを使うといった小技が必要らしい．
2005-12-05 [長年日記] ▲
_ [授業]レポートの採点 ▲
ごそごそと作業．
AspectJの課題については，コード自体は普通に書けているという印象．アスペクトのテスト方法を考える，という点については，アスペクトを接続した相手のクラスに他のアスペクトも貼りついていることに気づかず，はまった人が数名いた様子．
Eclipse 特有のトラブルとしては，あるメソッドを参照しているコードを検索するときに，AspectJ のコードが対象にならないことではまっていたらしい．このあたり，ツールが完全に揃ってない点が，授業教材としては難しいのかもしれない．
_ [hyCalendar] 全角文字入りのURLが認識できない問題 ▲
URLに含まれる valid な文字集合に全角文字を含めていなかったので，こけていた．全角文字自体は Delphi の場合，ByteType(str, index) で SingleByte ではない（LeadByte/TrailByteのいずれか）で判定するのが確実？で，valid な文字集合に入ってなくても全角文字の一部ならURLの一部として含めるということになるか．
ただ，URLの直後に全角文字が来ているケースを作られていると，今までに書いたデータでこける可能性があるので，何か明示的なエスケープを使っての導入にしないといけないかもしれない．
2005-12-07 [長年日記] ▲
_ [ツール]Volume Deskbar 1.0.2 公開 ▲
起動時にツールバーが表示されない（どころか，他のツールバーまで表示に失敗する）というバグ報告をいただいたので，修正．
初期化まわりがおかしいはず，と考えて，Microsoft のコード例と手元のコードを見比べてみたら，使ってたサンプルコードが，IPersistStreamではなくIPersistStreamInitを使っていて，InitNew関数で NOTIMPL を返していた．これは怪しそう，ということで IPrintStreamInit をやめて IPrintStream に変更したら直った（InitNewが消えただけなので他には修正なし）．
2005-12-09 [長年日記] ▲
_ Volume Deskbar が窓の杜で取り上げられる ▲
12月8日の「今日のお気に入り」．70件くらいだったアクセスカウンタが１日で700ぐらい回ったと思うので，やはり影響力の大きいサイトなのだと感心する．
2005-12-13 [長年日記] ▲
_ コントロールパネルのアイテム ▲
「オーディオとマルチメディアのプロパティ」なんかをプログラムから開くのはどうするんだろう，と思っていたら，＠ＩＴにコントロールパネルのアイテムをコマンドラインから呼び出す方法の解説が書いてあった．ボリュームコントロールを開くのは sndvol32.exe でいけるので，これで実質オーディオアイコンと同等の役割を果たすことは可能だと思われる．
こういう実装を選ぶと，Windows のファイル名に依存してしまうが……．
_ 複数の enumerate 環境のカウンタを継続する ▲
LaTeX で，途中で見出しを入れるとどうしてもenumerate環境が途切れるので，無理やりカウンタ値を保存して継続することにしてみた．
\newcounter{preserved} % 保存用カウンタを宣言
\begin{enumerate}
\setcounter{enumi}{\value{preserved}} % カウンタ値を復元
\item アイテム群を書く
\setcounter{preserved}{\value{enumi}} % カウンタ値を保存
\end{enumerate}
\begin{enumerate}
\setcounter{enumi}{\value{preserved}} % カウンタ値を復元
:
2005-12-17 [長年日記] ▲
_ APSEC ３日目 ▲
基調講演＋AO-ASIAワークショップのみ．発表＋質疑で約30分ずつのペースで続いた．会場が寒かったのでヒーターのまわりに集まって，という形式は珍しかったかも :-)
ユースケースのシナリオをシーケンス図で記述したとき，シナリオ間で共通部分列があるかどうかで，各シナリオが部分列を持たないほど，そのユースケースモデルの凝集度が高いとして計ってはどうか，とかいう発表があって，わりと面白かった．
_ コンポーネントモデルとアスペクト ▲
AO-ASIA ワークショップにて，Pointcut + Advice 形式で，コンポーネントの接続しかしないことも多いのだから，コンポーネントモデル（アーキテクチャ記述とかの）上での一種のコネクタのようなものと考えられる，といった感じの千葉先生の話はわりとしっくりしたものだと感じられた．
あるアスペクトが，「オブジェクトＡからオブジェクトＢのメソッドを呼び出した時に動作する」と記述することを「アスペクトがオブジェクトの実装の詳細に依存している」のでは？と気になるのは，コンポーネント間の接続（仕様として記述された public な接続）と，オブジェクトの内部的メソッド呼び出し（実装の詳細としてのメソッド呼び出し）とが混同してしまうせいかもしれない．
Javaだとメソッド呼び出しを仕様上のものか実装のものか区別できないので仕方がないけれど，Dependency Injection での明示的なオブジェクトの接続の記述とか，UMLのシーケンス図とかに登場するメソッド呼び出しについては，設計なんだからその順序に依存したアスペクトくっつけてもいいよね（ついでに実際のクラスの振る舞いがその前提と違うようだったら検出する），とかなったりするかな，どうかな？
2005-12-21 [長年日記] ▲
_ AspectJ 5 がリリースされていた ▲
12月20日付け．これで，アノテーション，可変引数，Generics などにアスペクトをくっつけることができる．ただ，これだけ syntax ベースな join point の記述が複雑になってくると，アスペクトってもっと単純な仕組みだけで何とかならないの？とも思ってしまったりする．
ふと，アーキテクチャ記述言語で書いたとおりに Dependency Injection でオブジェクトを接続してくれて，外部には facade インタフェースだけ出してくれる，とか，そういうのはできるんだろうか．アーキテクチャ記述を読んで GluonJ 記述を生成すればいける？
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-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-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-28 [長年日記] ▲
_ [お出かけ] 神戸市立博物館のナポレオンとヴェルサイユ展 ▲
見に行ってきた．絵画と，家具がメインな展示．人物の肖像画がかなり多かった気がする．
肖像画か何かのところに付いてた説明を読んでたら，当時はヘアスタイルとして，もみあげを伸ばしてたらしいので，アルセーヌ・ルパンのもみあげと関連してるのか，とか，どうでもいいことを思ったり（年代は離れているが）．
_ [論文] 実行履歴に対してマッチするアドバイスの定義方法 ▲
Allan, C., Avgustinov, P., Christensen, A. S., Hendren, L., Kuzins, S., Lhotak, O., de Moor, O., Sereni, D., Sittampalam, G. and Tibble, J.: Adding Trace Matching with Free Variables to AspectJ.
Proceedings of OOPSLA 2005, pp.345-364, San Diego, California, USA, October 2005.
イベント列にマッチするアドバイスを定義するために，before/after ＋ pointcut でイベントシンボルを定義し，イベントシンボルの正規表現によってアドバイス実行の条件を記述することを提案している．
before/after + pointcut を使うのは，通常の join point だと，呼び出しが始まってから終わるまで，のような有効範囲を持ってしまうためそれを before/after によって「点」に変更している．
「オブジェクト x に対して特定のメソッド呼び出しが起きたとき」といったオブジェクトのバインディングを，AspectJ のように各アドバイスで保存・参照するのではなく，シンボル列のマッチ時に解決することで，プログラムの簡潔な記述を実現している．
pointcut マッチによって生成されるシンボル列に対して，非決定性オートマトンを使った正規表現マッチでアドバイスの実行を決定する．このとき，シンボルとして，関係あるイベントだけが取り出されており，どのポイントカットにもマッチしないイベントはフィルタされる．
たとえば「ログイン後にクエリーを投げたとき」というアドバイスは，login/logout/query というイベントだけ定義しておけば，「login query+」というパターンで記述できる．logout が間に一度でも出現していたら上にはマッチしないし，それ以外のメソッド呼び出しはそもそもシンボルとしては登場しない．
手法に対する形式的記述や，関連研究の説明もうまくまとめられており，かなり参考になりそうな文献．
2005-12-31 [長年日記] ▲
_ [hyCalendar] 地道に単体テストを書く ▲
インポート機能を実装するついでに，DUnit を導入してみたら，なんとhyCalendar の分割コンパイルに失敗（モジュール間の依存関係が多すぎて，分割コンパイルできる境界を見つけられなかった）．いずれ整理しないと，と思いながら放置してた部分がけっこうたくさんあること判明．
とりあえず DUnit の使い方メモ．やることは次の通り．
- DUnit が提供しているコードへの参照を追加する
- テストケースを実行するインタフェースを起動するコード
- テストケース自体
- 実行対象のテストケースを登録するコード
DUnit のコードを参照するには，プロジェクトの検索パスに，DUnit-x.x.x/src ディレクトリを加えておく．
テスト起動コードは，通常は，プロジェクトソースに記述する．以下は独立したプロジェクトとしているパターン．コンパイルスイッチなどで，通常のプロジェクトと切り替えるのもありかもしれない．
program HogeTest; // プログラム名をここに書く uses TestFrameWork, GUITestRunner, // ここにテスト対象のユニットも並べる begin Application.Initialize; GUITestRunner.RunRegisteredTests; // テストインタフェース表示 end;
テストケース自体は，TTestCase クラスを継承したクラスを定義する．必要なのは，"Test" という名前ではじめることと，アクセス権を "published" にしておくこと．published で宣言すると，実行時にメソッド名をプログラムから参照することができるようになるので，テスト登録に使われる．
uses
TestFrameWork; // TTestCase などを参照するのに必要
type
THogeTest = class(TTestCase)
protected
procedure TearDown; override;
published
procedure TestFirst;
procedure TestSecond;
end;
テスト条件のチェックは，Check という関数を使って記述する．trueになる条件と，エラー時に表示される文字列を記述する．
Check(not data.hasError, 'エラーは起きないはず');
で，作ったテストケースは，そのユニットの initialization 節で，RegisterTest という処理を呼び出すことで登録を行なう．テスト用クラスで登録するが，このとき，クラスの Suite メンバを使う． ユニットの初期化タイミングで動作する initialization 節をまじめに使っている例だといえる．
initialization TestFramework.RegisterTest(THogeTest.Suite);
_ [論文] パフォーマンス向上のための自動コード変換 ▲
Liu, Y. A., Stoller, S. D, Gorbovitski, M., Rothamel, T. and Liu, Y. E.: Incrementalization Across Object Abstraction.
Proceedings of OOPSLA 2005, pp.473-486.
モジュール性の高い素直な実装だけでは性能が足りないときは，コストの高い問い合わせメソッド系の戻り値をあらかじめ保持することになる．
このとき，状態の更新メソッドが呼ばれたら，その保持している内容を更新する必要があり，その実装はかなり複雑になりがち．
そこで，プログラム変換を使って， invariant を保存しつつ，状態更新処理のコードを作ろうというもの．
アイディア的には AOP の立ち位置と同じようだが，コードを変換するルールを記述していく作業が，今のところは，メタプログラミングの要素が強い．
_ [論文] コードからのオブジェクトの状態機械の抽出 ▲
Nanda, M. G, Grothoff, C. and Chandra, S.: Deriving Object Typestates in the Presence of Inter-Object References.
Proceedings of OOPSLA 2005, pp.77-96.
各メソッドのコードを解析して，オブジェクトの取りうる状態をどう変化させるかを調べておき，とりうるヒープの状態（オブジェクト間の参照含む）をメソッド呼び出しで遷移する状態遷移図を構成する．これによって，同じメソッド呼び出し列でも，値などによって状態が変わる場合を区別して確認できる．
_ [論文] 実行履歴に対するクエリ ▲
Goldsmith, S., O'Callahan, R. and Aiken, A.: Relational Queries Over Program Traces.
実行トレースに対するクエリを PTQL という SQL に近い言語で書くと，それに必要な監視コードをプログラムに埋め込む．
イベントの開始・終了時刻，宣言しているクラスや実装クラス，パラメータの値などの値をクエリの条件式として使える．
tracematch での実行履歴のマッチとはやり方が違うが，実現時の最適化技術などはたぶん同様だと思われる．
使いやすさについては，どのくらい，と明確に言えないが，有用そうな例いくつかに対して，パフォーマンスのオーバーヘッドでの評価を行なっている．
_ かな [はじめまして。inkscape使い方教えてくれますか？ブログのアイコン作りたいので良かったらお返事ください。]