netail.net

_ Power Point 発表時間計測ツール ▲

朝起きてからホテルチェックアウトまでと，飛行機待ちの時間で作ってみた．

Power Point 標準のリハーサルモードだと，時間記録した結果が１個分だけな上，選択を間違うと以降のスライド再生に使ってしまうのであまり好ましくないということで，各スライド切り替えごとに時間を記録する単純な実験バージョンを構築．

Power Point の COM オブジェクトのインタフェースが Borland Delphi に用意されていたので，OnSlideShowBegin と OnSlideShowEnd，OnSlideShowNextSlide イベントハンドラを定義したらなんか簡単にできてしまった．

Power Point と一緒に起動して（EXEとどちらが先でもOK），あとは普通にプレゼンテーションを起動するだけというお手軽ぶり．さすが付属ライブラリ．

いちおうローカルでテストはしたので，他のPC上でも動くことを確認したら公開の予定．

_ METRICS 2004 ▲

METRICS 2004 のほうは，プロセスに関するメトリクスが主体でプロダクトに関するメトリクスはほとんどなし．

メモしとこうと思った話はSystematic Review についての基調講演くらい．

evidence based な医学でのレビューを題材に，ソフトウェア工学でも客観的なレビューが大事だろう，という講演．

systematic なレビューの利点として結果の公平性や，作業経過や判断の透明性を挙げている．欠点は少ないが，レビュー方法自体の説明が長くなるのでショートペーパーなどとして出しにくいこと，複数人でのレビュー結果を付き合わせるので人数，労力がかかることを挙げている．

publication bias （「都合の悪いことは書かない」ことによる偏り）に気をつけながら過去の研究から用語やリソースを探して，情報ソースの品質の評価基準や情報抽出方法なども考える必要がある．

また，他の研究との違いを構造的なテーブルとしてまとめたり，結果に対するコメントを受け取る方法を作ったりといった作業も重要らしい．

ソフトウェア工学では，しばしば実験室的環境で，学生が被験者であること，タスクが人工的であること（いずれもランダムではない）が難しいところ．質問として，医学では個人単位だがソフトウェア工学ではプロジェクト単位なので扱いが難しいのでは，といった話や，学生にレビューさせる場合は相互に影響しないように個別にレビューを行わせるような注意が必要だ，といった話なんかも出ていた．

_ [論文] ICSM 2004 まとめ (7) ▲

T12: Metrics for Maintenance より．

R. Marinescu: Detection Strategies: Metrics-Based Rules for Detecting Design Flaws.

メトリクス値を基準にデザイン上の問題を探そうというもの．God Class はLOCが100行以上で，メンバ数が上位25％に入っていて，…といった形で条件を記述して，該当するクラスを探す．

バージョン更新で，Bad-Design がなくならなかったら直し方が悪いか評価関数が悪いかで，バージョン更新で問題が新たに生じたら調査が必要，といった感じに使うらしい．

実験もしていて，「疑わしい」として出るもののうち，50％〜80％くらいは本物だった，らしい．うまく関数を作るのがかなり大変そう．

Z. Wen, V. Tzerpos: Evaluating Similarity Measures for Software Decompositions.

ソフトウェアをサブシステムに分解したとき，人間の評価と比較したいが，その評価基準を提案したもの．

普通なら，分類 A と B が与えられたとき，A から B に，要素の移動と集合の合成で変換するスクリプトの長さ (MoJo）を使うが，これでは依存辺の情報が反映されないので，クラスタ内の辺とクラスタ外の辺，という情報を使って要素移動に重みをつける，ことを提案している．

提案としては妥当っぽいが，ケーススタディなどはこれから，らしい．

T13: Empirical Study より．

J Luo, R Jiang, L. Zhang, H. Mei, J. Sun:An Empirical Study of Two Graph Analysis Based Component Capture Methods for Object-Oriented Systems.

システムをサブシステムに分解する手法のうち，グラフから重みの小さい辺を取り除いていくトップダウンな手法と，依存関係が「固まっている」ところを１つの塊としていくボトムアップな手法を比較実験したという論文．

結果としては，ボトムアップに構築したほうが時間はかかるが，良好な結果が出たらしい．それでも手動の分類には遠くて，人間は意味的な情報に基づいた分類をしているのでグラフの構造だけに基づいた分類方法ではやはり苦しいのではないか，と言っていた．

_ [論文] ICSM 2004 まとめ (6) ▲

Tools III より．

F. Balmas: DDFGraph: A Tool for Dynamic Data Flow Graphs Visualization.

動的なデータフローをグラフ化する．Lisp で実装．関数呼び出しの，引数と戻り値，本体を表現するノードをデータフローで接続する．粒度を適切に操作すれば，何となく便利そう．

W. Abdelmoez, M. Shereshevsky, R. Gunnalan, H. Ammar, B. Yu, S. Bogazzi, M. Korkmaz, A. Milli:Software Architecture Change Propagation Tool (SACPT).

A が変更された → B が変更された，という伝播確率を計算してマトリクス表示するというもの．

他へ伝播しやすいものは変更すると危険なもの，他から影響を受けすぎるものは将来も頻繁に変更される，といった推測をするのに使うらしい．

伝播確率の計算方法などはちょっと不明．

また，プログラムには入ってなかったが，Ducasse: Re-engineering Tool Moose の紹介をしていた．言語非依存のリポジトリ＋メトリクス計算ツール＋解析ツール用API といった感じで，クラスのメトリクスなどを計算・統計するための基盤ツールらしい．BSD ライセンスで公開中とか．

_ [論文] ICSM 2004 まとめ (5) ▲

T10: Configuration Management より．

A. De Lucia, F. Fasano, R. Oliveto, G. Tortora:Enhancing an Artefact Management System withTraceability Recovery Features.

IR手法によって，ドキュメントを探してきてソースコードに関連付けるという話．人間の評価と比較している．正解はそれなりだが，実用性という観点では微妙か．

T11: Program Comprehension and Visualization より．

F. Van Rysselberghe, S. Demeyer:Studying Software Evolution Information byVisualizing Change History.

バージョン情報の可視化で，ファイル軸と時間軸を取って，各タイミングで変更されたファイルのところに点を打って，同時に変更されているファイルといったパターンを探しましょうというもの．メーリングリストとの対応付けで検証している．応用としては，問題の修正方法を学ぶなど．

ファイルの名前変更や合成が起きたらどうなるのか，といった質問があったが，確実にそれと分かるわけではないが，途中でぴたっと変更が止まったりするので分かる，といった感じの応答をしていた．

C. Dang, A. Le, A. Michail, K. Pham, T. Pham, N. Seow, A. Sridhar, J. Timm:Design Recovery Tool of Real-Time Graphical Applications Using Video.

連続的な画像キャプチャとプロファイラを組み合わせて，プログラムのどの部分とグラフィック動作が関連づいているかを調べるというもの．一度呼ばれてから一定時間内にまた呼ばれる，というものを把握して，アニメーションに関連づいているのではないかと推定したりするらしい．

_ [論文] ICSM 2004 まとめ (4) ▲

Short Paper Session I より．

E. Merlo, G. Antoniol, M. Di Penta, F. Rollo:Linear Complexity Object-Oriented Similarity for Clone Detection and Software Evolution Analysis.

クラスの要素の各メトリクス値から平均値を取り出して，「中心」を見つけ，他と比較するという話．「ハッシュか？」と聞かれて，値は１つではないと答えていたのでベクトル表現だというほうが正しいのか．ケーススタディで false positive が出ていないので，入力データの特性なのか不明だが，だいぶ叩かれていた．

T. Everitt, R. Tvedt, J. Tvedt:Validating and Improving an Existing Software Architectural Evolution Process.

Reflexion Model みたいな感じで，モデル上に定義されたのにコード上に出現していない依存関係，モデル上に定義されていないのにコード上に存在する依存関係を図示しましょうという話．

L. Tahvildari, K. Kontogiannis:Developing a Multi-objective Decision Approachto Select Source-Code Improving Transformations.

どこかの論文で定義したプログラム変換のメタモデルを使っていて，目的の品質を達成するために「小さな変更」列を探しましょう，というもの．リファクタリング手順を動的に探索するといった感じ．

_ [論文] ICSM 2004 まとめ (3) ▲

T4: Testing より．

M. Galli, M. Lanza, O.Nierstrasz, R. Wuyts: Ordering Broken Unit Tests for Focused Debugging.

使っているメソッドの種類が包含関係にあるとき，一方がエラーだともう一方もエラーになりやすい，ということをケーススタディで確認している論文．テストケースの順序設定なんかに使う．将来的には他にも展開したいらしい．

T6: Slicing and Change Analysis より．

S. Raghavan, R. Rohana, D. Leon, A. Podgurski:Dex: A Semantic-Graph Diffrencing Tool in Large Code Bases.

Abstract Semantic Graph の差分（edit script）を計算して，意味的な差分情報（ローカル変数が追加された，など）を抽出する．回帰テストや，変更の理解なんかに使えるのではないかという提案．

_ [論文] ICSM 2004 まとめ (2) ▲

T3: Program Comprehension より．

M. Salah, S. Mancoridis: A Hierarchy of Dynamic Software Views: From Object-Interactions to Feature-Interactions.

SMQL というコードで取得する実行シーケンスを指定して，各featureがどのオブジェクトを生成するか，あるいは他のfeatureのオブジェクトを使用するか，ということからfeature間の関係を取り出そうというもの．

発表を聞いた限りでは，featureの定義がいまいち不明瞭．また，質疑応答では，いくつテストケースを実行すれば十分なfeature間の関係が分かるか，などといった質問が出ていた．

A Rountev: Precise Identification of Side-Effect Free Methods in Java.

定めたクラス集合の境界内での副作用解析．100％正確と本人は言っていた．

A. Rostkowycz, V. Rajlich, A. Marcus: A Case Study on the Long-Term Effects of Software Redocumentation.

プログラムにドキュメントを付け加えていくと徐々にコンポーネントの変更にかかる時間が短くなり，またドキュメントをつける速度も早くなっていく，という話．数年にわたるケーススタディで，変更に応じてドキュメントをつけていくと数年でだいたい８割がたのコンポーネントにはドキュメントがきちんと付いたらしい．

_ ICSM 2004 まとめ ▲

ICSM/METRICS 2004 が無事終了したところで情報整理．Ira Baxter の Program Transformation の Tutorial．

full automatic tool よりもhighly configurable tool がいい，と言いながらプログラム変換のモデルについてと，自分たちで作っている Design Maintenance System ではどんな選択肢を取ったか，といった話．

requirement = functional (What) + performance (How well) という考え方がわりと面白いかも．性能以外の要求は基本的に functional であるととらえているみたい．

プログラム変換系の大規模ソフトウェアへの適用を真剣に考えていて，変換系を作るのは難しい（例として１人年程度のプロジェクトが挙がっていた）が，それでも手動で移行するコストよりは低い，と主張していた．

また，XML などでASTを表現すれば楽だと言う人間もいるが，処理系を作る人間が楽をするぶんユーザが苦労するので，言語処理系を作る人が多大な努力をして他の開発者の仕事を楽にすることが重要だ，とも言ってた．

なんというか，言語処理系の構成とかよりもなぜ重要なのかという姿勢の話がメインだったような気がする．