netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-09-26 古い日記からの変換データ [長年日記] ▲
2004-09-25 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar] 0.8.6 リリース ▲
これ以上機能追加するときりがなさそうなので，0.8.6 としてリリース．
いーかげん機能的には満足してきたので，次はやはり「タスクトレイへの常駐」だろうか．
Outlook とのインポート／エクスポートに対応してみるのも技術的には面白そうなのだが，使わないツールを作ってもまったくうれしくないのが難点．
ちなみに，0.8.6 をエンターブレイン様のフリーウェア年鑑にも収録していただく予定．致命的なバグとか出なければいいけど…．
_ [論文] EIWASワークショップ ▲
EIWAS'04: 1st European Interactive Workshop on Aspects in Softwarehttp://www.topprax.de/EIWAS04/
というのが開催されていたらしい．あんまり時間がないので，ざっくりメモしておく．
「AOP considered harmful」というパネルでは，advice と対比する形で "come from X" （goto文の逆で，「行 X が実行されたらここに来る」という文）を見せて，アスペクトの濫用の危険性について言及されている．
また，Rémi Douence による， AOP はどんなものか，といった論文が出ていた．AOP そのものはコード再利用が主目的ではないとか，AOP を非機能的要求以外にも使ってるじゃないか，とかベースプログラムの意味を変えるべきではない（プログラムの持つ不変条件に違反しない）とか．
Kasper B. Graversen らによる「アスペクトのアスペクト」はどうだろう，という話もあって，pointcut や advice 定義自体もinter-type declaration できるべきではないのか，みたいな話のよう．
Kris Gybels, and Andy Kellens: An Experiment in Using Inductive Logic Programming to Uncover Pointcuts.これは，アスペクトを既存コードから抽出するときに，とりうる Join Point の組み合わせと結果の Pointcut とを比べるとかして正しく join point を選べるように，とか言っている．
Christian Koppen, Maximilian Stoerzer:PCDiff: Attacking the Fragile Pointcut Problem.こちらは，クラス名やメソッド名の変更によって，pointcut が影響を受けていないか検出しましょうという話．ようやく出てきた？という気もしなくはない．ただ，分かったところで，変更に追随すべきか，すべきでないかを判断するのは難しいのだろうけど…．
István Nagy and Lodewijk Bergmans:Towards Semantic Composition in Aspect-Oriented Programming.attribute (いわゆる javadoc 系のタグ）ベースでpointcut を記述したほうがいいのでは，という論文．こちらのアプローチのほうがPCDiffのアプローチよりも安全そう．属性を付けるルールが明示されていて，間違った属性を付加することがなければ，という限定は付くが．
_ [論文] 実行履歴の図示 ▲
どこかで読んだはずなのだがメモしてなかったみたいなので書いておく．
Dean F. Jerding, John T. Stasko, Thomas Ball:Visualizing Interactions in Program Executions.ICSE 97, pp.360-370, Boston, MA, USA, 1997.
実行履歴を可視化するために，メソッド間の呼び出し関係を接続した地図のようなグラフを表示したり，横軸に時間，縦軸に呼ばれたメソッドをプロットすることで呼び出しパターンを可視化したりということをしている．
_ [論文] トレースデータの抽象的な表示 ▲
Robert J. Walker, Gail C. Murphy, Bjorn Freeman-Benson,Darin Wright, Darin Swanson, Jeremy Isaak:Visualizing Dynamic Software System Information through High-level Models.Proceedings of OOPSLA 98, pp.271-283, Vancouver, B.C., October 1998.
実行トレース情報を，抽象化されたビューにマッピングしましょう，という話．手法としては，上位のコンポーネント（サブシステムなど）を適当にドキュメントなどから見つけてきておいて，開発者は，実行トレースからコンポーネントへのマッピングを宣言的な言語で記述するというもの．
基本的には実行中，時間的にある程度限られた範囲でシステムの中をどのように実行が進んでいるかを見るが，それがどのようなコンテキストで起こったのか，という全体像のようなものがないと使いにくい，ということと，やはりその時点でのスタックの中身および実行中のコードへのリンクみたいなものも必要だ，といった結果がケーススタディの結果として議論されている．
_ [論文] トレースデータの活用 ▲
Johan Moe, David A. Carr:Using Execution Trace Data to Improve Distributed Systems.Software Practice and Experience, Vol.32, No.9, pp.889-906,25 July 2002.
分散システムの開発時に，トレースデータを集めて使ったという話．・長期間のカバレッジ観測でまったく 実行されていないメソッドが見つかった・頻繁なリモートメソッド呼び出し（主にコレクションの取得）を 発見し，修正した・動的メトリクスなどを使ってオブジェクト間の強い結合を見つけたといった感じで使われたらしい．短期間だけでなく，長期間（数日，あるいはそれより長い単位）でトレースデータを使うというのは珍しいかも．
参考文献リストをちらっと見た限りでは，システムの可視化やメトリクスなどへの論文のポインタとして便利そうな感じ．
_ [論文] 依存関係の管理 ▲
S. Ducasse, M. Blay-Fornarino, A.M. Pinna-Dery:A Reflective Model for First Class Dependencies.Proceedings of OOPSLA'95, pp.265-280, Austin, TX, USA.
オブジェクト間の依存関係を，First-Class なエンティティとして管理しましょうという論文．FLO という言語を提案していて，オブジェクト間のリンクを記述する．
たとえば，stack への pop 呼び出しが，memory オブジェクトに store された結果を返す場合，「(pop :stack) implies (store :memory :result)」といったように記述する．関連付け自体をインスタンス化する必要がある点は，association aspect なんかの使い方と同じ．
・オブジェクト間のインタフェースにのみ規定されるので カプセル化は守られる．
・関連は動的に生成，チェック，破棄される．
・オブジェクト間に双方向のリンクを貼ることができる．（ある一方の変更が他方へ伝わるなど．アドバイスの動作に近い）
・リンク自体が first-class なので，リンク間のリンクなんかも定義できたりする．
propagation が伝わっていく途中でループが起きた場合は，リンクごとに停止用の invariant を書くか，割り込み処理のようなメカニズムを使うらしい．
で，MOPを使った実装の話が載っている．
関連研究については，クラス間の相互通信インタフェースを記述する手法ではクラスの仕様情報が他のクラス定義にまで分散してよくない，また，オブジェクト間のインタラクションの制約を記述すると制約自体がカプセル化を破壊してしまう，などとも言及している．
2004-09-24 古い日記からの変換データ [長年日記] ▲
_ [論文] メタクラスの互換性問題 ▲
Noury Bouraqadi-Saadani, Thomas Ledoux, Fred Rivard:Metaclass Composability.Composability Workshop held in conjunction with ECOOP 96.
前に読んだ OOPSLA の論文でのメタクラスの互換性問題について述べていた論文．
Upward Compatibility は，親クラスがメタクラス情報にアクセスしているとき，子クラスは自分自身のメタクラスにアクセスすることになるが，このときにメタクラス同士は直接関係ないので困ったことになる（直接は関係なくてもメタクラス間できちんと関係を維持しないといけない）という問題．
Downward Compatiblity はメタクラス間の継承関係が，クラス側に影響を及ぼしてしまう問題．
また，複数のメタクラスを同時に使うときにはそれらを合成するメカニズムが必要である（たとえば多重継承など…）．
で，この人たちは，メタクラスからのインスタンス生成（self.new）とクラスからのメタクラス取得（self.class）とがベース・メタレベル間を移動する瞬間なので，そこを Metapipe というポイントとして何らかの取り扱いをすればよさそうでは，という提案をしている．
AOP的な文脈に置き換えられるかな？と思ったのだが，アスペクトの動作をメタレベルへの移動ととらえられないことはないかもしれないが，アスペクトの中でベースレベルに「降りる」移動のほうがいつなのか，というのは明確には言いづらいのかも．
_ [論文] オブジェクト指向対応の差分計算アルゴリズム ▲
Taweesup Apiwattanapong, Alessandro Orso, Mary Jean Harrold:A Differencing Algorithm for Object-Oriented Programs.Proceedings of the 12th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE 2004),Newport Beach, CA, USA, November, 2004.
言語のsemanticsまで考慮した diff を作りましょうという話．クラスおよびインタフェースの対応をとって，メソッド単位の対応をとって，メソッドの中身では制御フローグラフのノード間の対応を取る．
クラスは基本的にはパッケージ名まで含めた名前比較だが，メソッド単位ではシグネチャを優先しつつ，名前だけでの対応も作る．メソッドの中身は，制御フローグラフをベースに比較する．
制御フローグラフでは，メソッド呼び出し文ごとに，dynamic binding の結果でどのメソッドに行くか分岐情報を持ったようなグラフを作っている．で，Hammock という Signle Entry Single Exit な部分グラフを見つける．要は，メソッド内の制御フローで，「どんな条件でも必ず通過するノード」を識別して，その部分を「Hammock Node」という集約された形に置き換える．で，それを繰り返していって全体の簡略化された制御構造を取り出す．あとは Hammock Node 間の類似度とかで計るみたい．
従来のマッチングアルゴリズムに比べると，マッチするノード数はだいぶ増えているらしい．時間は，20000ノードぐらいのプログラムで5分かそこらなので，そこそこの時間はかかるみたい．
わりとアルゴリズムの計算量とかについても述べていてかなり真面目で，よさそうな論文．diff について引用することはないと思うが，この人たちの Hammock のアイディアは（もっと前の論文で出ているものだが）どこかで使うことになるのかも．
_ [論文] feature 実装位置の特定作業 ▲
ICSM のどれかの研究で引用されてて，なぜか放置してた論文のメモ．
Chen, K. and Rajlich, V.:Case Study of Feature Location Using Dependence Graph.Proceedings of the 8th International Workshop on Program Comprehension (IWPC 2000), pp.241-249, 10-11 June 2000.
ASDG (Abstract System Dependence Graph) を使って，特定の機能を実装したソースコード位置を特定するfeature location の支援には，グラフを展開しながら閲覧するという形のツールが必要だろう，グラフ全体を把握しつつグラフの一部だけを見ていくのがいい，といった種類のことを言っている論文．
実際にはグラフが大きくなりすぎるので，頂点の集約とか何か色々な工夫が必要なのだろうけれど．最終的に生データ（ソースコード）に近づいていくことになると思うのだが，ソースコードに近づくほどグラフよりもソースコードのほうが理解が早くなったりしないのだろうか．
_ [PptWatch] PptWatch: Point 発表時間計測ツール ▲
もういい加減ハンドルである意味がなくなってきたので大学のサイトで公開することに．http://sel.ist.osaka-u.ac.jp/~t-isio/pptwatch.html
人柱募集中とか書いたりすると誰も使ってくれなさそうなので，使い方だけ書いて置いておくことにする．
_ [hyCalendar] 0.8.6 向け機能追加 ▲
次バージョン向けに，久々にコーディング．とりあえず昨日から５，６時間かけて実装したのは次の通り．他にどこまで組み込むかは未定．
・表示ツールバーの日付入力ボックスなど，一部でIME無効化．・装飾文字列の情報が，ハイパーリンク文字列の後で消えてしまう問題を修正．・「ハイパーリンク対象文字列も装飾文字列の効果に従う」オプションを追加．・フリーメモ，TODOエリアを最小化すると，復帰しないことがある問題を修正．・右クリックからのポップアップで [この日付に色を塗る] メニューを追加．・右クリックからのポップアップで [この日付の色をパレットに抽出] メニューを追加．・ファイル保存後も「元に戻す」を有効に設定．・[表示]メニューに，フリーメモ，TODOリストを追加．・[終了時のウィンドウ位置を保存する]を[終了時のウィンドウレイアウトを保存する]に変更． 有効なときはフリーメモ，TODOリストの表示状態を保存する．
2004-09-23 古い日記からの変換データ [長年日記] ▲
2004-09-19 古い日記からの変換データ [長年日記] ▲
_ 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を表現すれば楽だと言う人間もいるが，処理系を作る人間が楽をするぶんユーザが苦労するので，言語処理系を作る人が多大な努力をして他の開発者の仕事を楽にすることが重要だ，とも言ってた．
なんというか，言語処理系の構成とかよりもなぜ重要なのかという姿勢の話がメインだったような気がする．
