netail.net

_ [論文]単体テストをアスペクトで記述 ▲

Guoqing Xu, Zongyuan Yang, Haitao Huang, Qian Chen, Ling Chen and Fengbin Xu:JAOUT: Automated Generation of Aspect-Oriented Unit Test.Proceedings of APSEC 2004, pp.374-381.

単体テストの記述をアスペクトで書こうというお話．単に AspectJ では書きにくいのでAspectJ に translate されるような言語 AOTDL というのを作っている．基本的には JUnit などで記述されたテストケースと並行して，Temporal Logic などで望ましい性質が成り立っているかどうかをテストするアスペクトを付加する．このときに，無視してよいテストケースの条件も別に記述する．（たとえば，スタックのテストであれば，オーバーフローが起きるかどうかのテストの場合，Temporal な性質のほうは無視して良い）

意味のある／なし判定を，自動生成したテストケースの振り分けに使っているらしく，適当なグループ分けされたテストケースのうち，少数ずつサンプリング→実行して，後から大量のテストケースを投入するときに意味のないテストケースがあまり含まれないようにする，らしい．

_ [論文]実行の差分を使ったデバッグ手法 ▲

W. Eric Wong and Yu Qi:An Execution Slice and Inter-Block Data Dependency-based Approach for Fault Localization.Proceedings of APSEC 2004, pp.366-373.

失敗したテストケース１つと成功したテストケース１つ以上が与えられたときを対象としたデバッグ手法．

単純には，失敗したテストケースで実行した文集合から成功したテストケースのどれかで実行した文集合を取り除いてからコードを調べて，原因が見つからなければ成功したテストケースの数を減らして（探索対象コードを増やして）調査を続け，それでも見つからない場合は失敗したテストケースの実行した文集合にデータ依存関係を持っているブロックを探索対象に追加し，それでも見つからない場合は追加されたブロックにデータ依存しているブロックを…というように段階的に探索対象のブロックを増やしていく方法．

これで文集合としては失敗時に実行された文集合の３〜６割程度のサイズに分布するらしい．

スライシングなどで見つけにくい「必要なはずのコードが抜けている」ような場合でも，文集合を段階的に増やしていくときに予期しない文が増えたりすることで気付きやすい，らしい．

_ [論文]インタラクションの分析 ▲

Lei Wu, Houari Sahraoui, Petko Valtchev:Automatic Detecting Code Cooperation.Proceedings of APSEC 2004, pp.204-211.

C などのプログラムの実行履歴からシナリオID，呼び出し階層の深さ，メッセージ送信元・送信先のモジュール，関数名を取り出してきて，基準をユーザが組み合わせることで自動的にパターンを分析してくれるらしい．

で，出てきたパターンに対して，どのような Collaboration パターンか（Supplier-Consumer，Director-Manager-Worker など）役割を当てはめてシステムを理解する，らしい．

１個の「パターン」をどこで認識するのか，何かパターン認識のためのツールキットを作ったとはあったが，それ以上は不明．分割の適切さについても不明．

パターン同士が同じものかどうかの比較基準もあいまい．ケーススタディで一言「メッセージの順序は考慮しない」と書いているので，呼び出し回数付きコールグラフともいえる実行ツリーを作る手法(*1)でのツリー比較っぽい．

あとは，発見されたパターン（粒度としては細かそう）に対して，統計ツールなどを使って性質を調べたり，このパターンでは各ルーチンがどのような役割をしているか，というのを調べていくことになるらしい．

いちおうシーケンス図生成などの話の関連研究なのだが，肝心のアルゴリズム的な部分があいまいなので何とも評価しがたい．オブジェクト指向じゃないので適当な方法でもそれなりにうまくいくのかもしれないが．

*1: Wim De Pauw, David Lorenz:Execution Patterns in Object-Oriented Visualization.Proceedings of COOTS 1998.

_ [論文]Concern Graph ▲

Concern Graphs: Finding and Describing ConcernsUsing Structural Program Dependencies.Martin P. Robillard and Gail C. Murphy.Proceedings of ICSE 2002.

ある Concern についての情報をクラス・メソッド・フィールドを頂点とし，declare, call, read, write, check （instanceof/キャスト）,create, superclass を関係としたグラフを作ることで，ソフトウェアの変更を容易にしようという試み．

FEAT は Concern Graph の作成を助けるツールで，メソッドから Fan-Out, Transitive Fan-Out を計算したり，クラスへの参照を取ってきたりする．（ICSE2003でツールデモをやってた）

バイトコードからモデルを作っているのだが，ソフトウェアの変更という観点では，コンパイル時にfinal 宣言された定数が展開されたりメソッドがインライン化されたりといった影響が気になる，と述べている．

制約としては，ある Concern に参加する頂点の集合を取り出したとき，頂点間の依存辺を単にすべて取り出してしまうと，別の Concern 用に作られた Call や Read/Write も含んでしまうかもしれない，というところ．手作業でフィルタする必要がある？