netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-06-05 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
L. C. Briand, Y. Labiche, Y. Wang:Using Simulation to Empirically Investigate Test Coverage Criteria Based on StatechartProceedings of ICSE 2004, pp.86-95.
テストケースの選択として，ステートチャートのすべての遷移(AT)，遷移のペア(ATP)，遷移木のすべてのパス(TT)，すべての述語(FP)，のどれを100％カバーするようにテストケースを選んだらコスト的に良いだろうか，というシミュレーションベースの比較．結果としては，ATは不十分で，ATP，FPはコストは高いが，バグ発見には効果的だったらしい．
TTは，プロトコルテストなどには効果的らしいが，常に効果的とは限らず，ツリーの中に，非現実的なパスが含まれていないことなどが重要らしい．データフローに基づくブランチ選択のようなヒューリスティックが必要かもしれない，という感じで結ばれている．
_ 論文 ▲
Wee Kheng Leow, Siau Cheng Khoo, and Yi Sun:Automated Generation of Test Programs FromClosed Specifications of Classes and Test Cases.Proceedings of ICSE 2004, pp.96-105.
テストケースの生成話．入出力の仕様などから，Java クラスの単体テストコードのようなものを生成したりする．オブジェクトを生成した状態から，状態変化メソッドを適用していって目標の条件に到達する，という経路探索みたいな形になるらしい．
アプローチとしては面白いと思うのだが，Closed Specification を準備する手間というのが曲者に思える．テストケースを書こうとして始めて仕様の穴に気づく，といった状態だとテスト生成もうまくいかない気がする．
_ 論文 ▲
Jennifer Black, Emanuel Melachrinoudis, David Kaeli:Bi-Criteria Models for All-Uses Test Suite Reduction.Proceedings of ICSE 2004, pp.106-115.
プログラム内の define-use 関係(DUA) の情報を使って発見するエラー数が同じだがテストケースの数だけ減らす，といった計算を行うモデル提案．手法についてはあまりよく理解していないが，どのテストケースが，どれだけバグを検出していてどれだけ DUA をカバーしているかという情報が必要で，なんかコストが高そうな印象．
_ 論文 ▲
ICSE 2004 Doctoral paper から拾い読みの続き．
Michael J. Pacione:Software Visualisation for Object-Oriented Program Comprehension.Proceedings of ICSE 2004, pp.63-65.
ソフトウェア可視化の研究．最近流行ってる？抽象度をレベル分けしていて，コードレベル，オブジェクト内部の動作，メソッド単位（オブジェクト間），オブジェクトまたはクラス単位，アーキテクチャ（サブシステム）レベル，システムレベルといった感じで分けている．で，抽象度レベルと，構造・振る舞いといったどの側面に興味があるかでシステムを自由に見ていけるようなシステムを作ろう，といったところか．どんな情報やシステムがこの考えにマッチするか，といった点については色々考える余地があるみたい．
_ 論文 ▲
Jennifer Tenzer:Improving UML design tools by formal games.Proceedings of ICSE 2004, pp.75-77.
UML の設計の検証を，Refuter と Verifier のゲーム（ルールに則った操作の連続）として実行しようというアイディア．基本はモデルチェックの話らしい．この種の研究がどのくらい価値があるのかよくわかってないのだが．
ちなみに，メタ操作（モデル変更）は cheat らしい．cheat した結果，verifier 側に勝ち目が出てくるというのならそれはいい変更だったりするのかもしれない．
_ 論文 ▲
Pakorn Waewsawangwong:A Constraint Architectural Description Approach toSelf-Organising Component-Based Software Systems.Proceedings of ICSE 2004, pp.81-83.
architecture description language などで書かれたコンポーネントが，与えられた制約を満たすように自分たちで reconfigure する，という環境の研究．実行時に後から制約を追加したりとかも考えているみたい．やっぱりこれからはコンポーネント単位でコーディングする時代が来るのかしら．
_ 論文 ▲
ICSE 2004 Doctoral paper をいくつか拾い読み．
Hridesh Rajan:One More Step in the Direction of Modularized Integration Concerns.Proceedings of ICSE2004, pp.36-38.
コンポーネントの結合（イベントの通知など）がコンポーネント本来の機能とくっついて保守性とかに悪影響を与えるのが嫌なのでアスペクトを使って書きましょう，という話のよう．Association Aspect に近い話のような気がしなくもない．
_ 論文 ▲
James A. Jones:Fault Localization using Visualization of Test Information.Proceedings of ICSE2004, pp.54-56.
テスト結果などから，失敗した原因の「疑わしい」文を素早く見つける方法についての研究．ある文 s について，その文を実行したテストケースのうち成功したものの割合によって s を着色したり（失敗したテストケースが多いと赤に近づくといった感じ），全体テストケースのうちどのくらいのテストケースでその文が実行されたかによって文の輝度を設定したり（毎回実行されるような文が一番目立つ），といったものらしい．
アイディアとしてはけっこう好きかも．最終的なソースコードがどんな見た目になるのか，一度見てみたい気はする．
