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 を着色したり（失敗したテストケースが多いと赤に近づくといった感じ），全体テストケースのうちどのくらいのテストケースでその文が実行されたかによって文の輝度を設定したり（毎回実行されるような文が一番目立つ），といったものらしい．
アイディアとしてはけっこう好きかも．最終的なソースコードがどんな見た目になるのか，一度見てみたい気はする．
2006-06-05 ▲
_ [論文] "Feature-Oriented" リファクタリング ▲
Jia Liu, Don Batory and Christian Lengauer: Feature Oriented Refactoring of Legacy Applications.
Proceedings of ICSE 2006, pp.112-121, Shanghai, China, May 2006.
Feature-Oriented Refactoring (FOR) は，色々なfeatureを持ったソフトウェアを，featureごとにモジュール分割する作業のことを指す．この作業を補助する手法を提案している論文．
各featureは，それぞれ固有のメンバー定義（AspectJでいうインタータイプ宣言）である基本のモジュール(base)と，基本モジュールに対する変更操作（アドバイス）である派生モジュール(derivative)によって構成される．派生モジュールの中には，依存する他の派生モジュールを改変するもの（他の特定のfeatureの存在を仮定した処理）が含まれる．この定式化が論文の前半を占めている．
プログラムをfeatureごとに分割する作業では，最初に，開発者が「featureがどう合成されているか」をモデルとして（マニュアルやソースから割り出して）定義する．たとえばロギング機能とバックアップ機能が付いたバッファクラスなら [LOGGING] [BACKUP] BUFFER といった具合．ケーススタディでは GenVoca という文法をこのモデル記述のために使っていて，もしあるfeatureが他のfeatureに依存しているなら「LOGGING implies BACKUP」のように制約を記述できるようにしている．
モデルができたら，元のプログラムの各メンバーがどのfeatureに属するかをラベル付けし，base 部分と derivative 部分を先に切り離してから（先の例なら BUFFER だけを先に取り出してから），派生モジュールのほうをさらに細かく分割していく．
featureごとのモジュールさえできたら（形式的にはAspectJのアスペクトやAHEADのrefineクラスで），あとは組み合わせたいfeatureの組み合わせ（モデルの文法で生成可能な文）を選ぶだけで，プログラムを自動的に再合成することができる．
feature間の相互作用がすべて派生モジュールとして登場するので，featureの数 n に対して，組み合わせ数である2のn乗の派生モジュールが生じてしまうが，実際には相互作用というのはほとんどないので，実際には 3*n 個くらいのモジュール数に収まるようだ，とケーススタディに基づいて述べられている．
この論文の偉いところは，feature間の相互作用を必ず考えろと定式化段階で言ってるところかもしれない．また，featureのモデルを作るのが，必須の機能と付加的な機能を列挙して，その間の依存関係を定義するだけなので，開発者にとっての負荷もそれほど高くなさそうなところもいいかもしれない（コードをそのモデルに基づいて分割するのはけっこうなコストだとは思うけど）．
