netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-03-29 古い日記からの変換データ ▲
2005-03-29 ▲
_ [work]PC返却のつづき ▲
Webメーラを使うと，HTMLメールが素で表示されてしまって鬱陶しいことが分かったので，おとなしく一時使用のノートにAl-Mailをインストールして，サーバにメールは全部残しておく設定で運用することにした．普段使っているBeckyのメールボックスを移動してくるほうが素直なのかもしれないが，あと１日か２日だと信じて．
できることが少ないので，論文読みを加速中．ワークショップのポジションペーパーだらけ（１つ６ページ程度）なので，ざくざく進める．
_ クリーニング ▲
この時期にいつも使ってるハーフコートが阪急石橋の踏み切り近辺に固まって生息している鳩のせいで汚れたので，クリーニングに出してきた．ついでに，暖かくなってきたので，普通のコートのほうもクリーニングに出した．なんか立て込んでるようで，一週間くらいかかるらしい．それまでは厚手のジャケットを使う予定．
_ [論文]動的解析に基づく再利用コードの発見 ▲
Andrew Le Gear, Brendan Cleary, Jim Buckley, J.J.Collins, Chris Exton: Making a Reuse Aspectual View Explicit in Existing Software.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
複数のテストケースを与えてプログラムを実行し，各テストケースがどの機能を実行していて，かつどのプログラム要素を実行しているかという情報を集めて分析する Software Reconnaissance 手法をアスペクトマイニングに使ってみようというもの．
システムの注目した機能 f について，f を実行しているようなテストケースで共通して使われているプログラム要素（Indispensable Elements）の集合から，他のテストケースでまったく触れられないプログラム要素（Unique Elements）と，すべてのテストケースで共通して使われているプログラム要素とを取り除いた結果残ったもの（Common elements）を Shared(f) として定義している（Shared(f) = Indispensable(f) - Unique(f) - Common）．
この得られたプログラム要素の集合 Shared(f) を，すべての機能について和集合を取ったものが，最終的な「複数の機能で再利用されている（しかもすべての機能で使われるユーティリティではない）プログラム要素」となる．
簡単なケーススタディを行った結果，わりと再利用可能なコード（本当にライブラリっぽく作ったものを含む）が発見されたらしい．そこからアスペクトと呼べるものに持っていくのは簡単ではないような気がするが…．
_ [論文]距離の近いメソッドの集合を横断的関心事とみなす ▲
David Shepherd, Lori Pollock: Interfaces, Aspects, and Views.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
横断的関心事のコードを１つにまとめるのは大変な作業なので（自動化されていないから），ソースコードビューとしてあちこちに散らばったコードを閲覧できるようにすべきだ，という立場の人たち．で，距離関数を定義してメソッドのクラスタリングを行って，適当なカタマリができたところで，それを見るビューを使って横断的関心事を管理しましょう，という提案．
クラスタは，最初メソッド１個ずつから開始して，距離が一番近いもの同士を同じクラスタとして，２つのメソッド名の共通の部分文字列の長さの逆数をクラスタ間距離とする（共通部分文字列が長いほど距離が近くなる），という簡単なアプローチを取っている．クラスタ名としては共通の部分文字列を取り出しておき，２つのメソッドの親ノードとして，ツリー構造を構築していく．
ケーススタディを見た限りではなんとなくそれっぽい感じの出力になっている．距離関数の定義が問題だが，重みの調整とか色々な手段はありそうだし，横断的関心事を管理する上でのスタート地点としては便利かもしれない．ソースコード編集して距離がごろごろ変わるようだと気持ち悪いが．Concern Graphのような形で見つけた関心事を保存するとか，色々手はありそう．
_ [論文]Concern Manipulation Environment ▲
William Chung, William Harrison, Vincent Kruskal: Working with Implicit Concerns in the Concern Manipulation Environment.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
Concern Manipulation Environment (CME) という開発環境を作ってますという話．基本的には，「関心事」を作成→プログラム要素を関心事に関連付ける→モジュール分割などの方法を色々考える，という形態のよう．同じプログラム要素を複数の関心事に関連付けることを許可して，より良い分割方法がないか探したい，といったことも言っている．
_ [論文]アスペクトを抽出したときのコード検証 ▲
Charles Zhang, Hans-Arno Jacobsen, Julie Waterhouse, Adrian Colyer: Aspect Refactoring Verifier.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
アスペクトを抽出した時点で，（ポイントカットの定義などによって）元のコードと振る舞いが変わってしまうと嫌だから自動で調べたいね，という話．さすがに真面目な同一性の検証は無理なので，変更前と後で，同じメソッドから同じメソッドを呼び出しているかどうか，という判定で，メソッド呼び出しが消えた・増えたのを報告する．単純だけど，ないよりは，あったほうがずっと役立ちそうな印象．
_ [論文]ポイントカット定義の自動生成 ▲
D. Binkley, M. Ceccato, M. Harman, P. Tonella: Automated Pointcut Extraction.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
リファクタリング時に，自動でポイントカット定義を生成できるか，という議論．メソッドをアスペクトに移動するだけならインタータイプ宣言でよいが，メソッド呼び出しが特定のメソッドの先頭で起きているなら before execution，特定のメソッド呼び出しの直前なら before call といったようになる．そのメソッド呼び出しの中，というのを限定するために cflow(execution) を使う．また，DEF/REF関係を維持できる範囲でプログラム文の順序入れ替えを許可することで，もしメソッド呼び出し文をメソッドの先頭などに移動できるならそうする，らしい．プログラムの構造を必ずしも保存しない，というのは Amorphous Slicing の手法が既にあるので，それを使うみたい．
ただ，このアプローチを使おうとすると，生成されたポイントカット定義が fragile base code problem を起こさないように抽象化するとか，また複数のコード片から生成したものをきれいにまとめるとか，うまくコンテキスト上の変数（使われているローカル変数など）をアスペクト側からアクセスできるようにするとか，微妙な工夫が必要になるみたい．
複数のコード片に適用するときに，一歩間違うと，実は１つのポイントカットにまとめられるのに，コード片ごとに違う定義が生成されて，まとまらなくなってしまう，といったことが起きそう．うまくいったら嬉しい手法かもしれないが．
2006-03-29 ▲
_ [ツール] JUnitとFIT ▲
JUnitでは，データの値と結果のペアをひたすら assertEquals で並べるので疲れると思っていたら，そういうテストに適したFITというツールがあるらしい．
developerWorksの記事によると，どうやらHTMLテーブルを書いておくと，列名が変数名なら入力データとみなし，メソッド名ならそこに書いてある値がそのメソッドのあるべき出力値とみなして，自動的にテストしてくれるというものらしい．
あと，鷲崎先生も記事を書いていた．ぱっと見た限り，けっこう便利そうなので，次の開発から使ってみたいところ．
ダウンロードページを見てたら，現段階ではJavaやC++など色々なバージョンが既にリリースされている様子．Delphi 版はさすがに（開発しようとした人はいるようだけれど）なし．こういうのを見ると，hyCalendar とかもそろそろサポートが充実した別の言語に移行すべきかなとちょっと悩んでしまう．
