netail.net

_ AOSD ▲

Ramnivas Laddad によるリファクタリングの記事．http://www.theserverside.com/resources/articles/AspectOrientedRefactoringPart1/article.html

「メソッド呼び出しの抽出」として，クラス内のある特定タイミングでのメソッド呼び出しをアスペクトとして抽出する段階を説明している．・pointcut と空のアドバイスを作って， pointcut が正しい位置にくっついたことを AJDT などを使って確認する．・アドバイスの中にメソッドの中の横断的な部分を移す． declare warning を使って， 元のクラスに除去すべき部分が残ってないことを調べる．・pointcut 定義を整理する．・必要なら，アスペクトの定義を整理する．

declare warning を積極的に使うところがポイントかも．AspectJ 1.2 ではコンテキスト情報（どこで warning になったか）を使ったメッセージ生成ができるようになるらしいので，pointcut が完全に消えたかどうか，あるいは本当に望みの位置にかかっているかどうか，というのを調べるために活用できそう．

_ APSEC2003 ▲

これも論文発表者のスライドだけ．

Yuming Zhou, Lijie Wen, Jianmin Wang, and Yujian Chen:DRC: A Dependence Relationships Based Cohesion Measure for Classes.

クラスの凝集度を測るためのメトリクス提案．クラスのメンバー間での呼び出し・読み書き，データ依存するかどうかでのフィールド間の依存関係をとって，

各メンバーごとに，「依存関係をたどって到達可能なメンバーの数」を計算して平均をとる．値としては，メンバー間の依存関係が完全グラフ（どのメンバーも他のすべてのメンバーに依存する）となるときに１，逆に依存辺がまったくない場合に０となる．

凝集度のメトリクスとしては必ず計算可能であること，単調増加であること，といった要求があるが，Chidamber の LCOM，Briand の RCI，Chae の CBMC がそれぞれ不適切な値となるケースでも正しく振舞うことができる，と述べている．

_ APSEC2003 ▲

これまた論文ではなくスライドだけ見ている． Wei Zhao, Lu Zhang, Yin Liu, Jing Luo, Jiasu Sun: Understanding How the Requirements Are Implemented in Source Code. ソフトウェアの保守作業にかかるコストはライフサイクルの40％を占めると言われている．しかも，保守作業中に行われる，ソフトウェアの拡張や修正作業ではソフトウェア理解が，それぞれ 47％，62％を占める[Fjeldstad 83]，あるいは半分以上を占めている [Corbi 89] という報告がある． そこで，要求ドキュメントの内容とソースコードの対応を自動的にとることができれば，機能に対応したコードを簡単に発見できて開発者のソフトウェア理解作業に役立てることができる，としている． 手法としては，要求ドキュメントの内容から抽出したソースコードから抽出した内容でマッチングを行って（ベクタ空間モデルを使うらしい）要求に対応したコードがどこか，その機能の中心はどのあたりかを探すというもの．最終的には完全性，正確性ともに60％くらいのところで最適値になっているので（完全性90％だと正確性10％程度），それなりに見つかるらしい． 引用している文献はそれぞれ，次の通り．

(Fjeldstad 93) Application Program Maintenance Study: 
Report to Our Respondents. 
Proceedings GUIDE 48,Philadelphia, PA, April 1983.
(Corbi 89) Program Understanding: Challenge for the 1990's.
IBM Systems Journal, 28(2), pp.294-306, 1989.

_ APSEC2003 ▲

APSEC2003開催．出席してる先生から，参考になりそうな論文のメールが届いたので発表者のスライドをチェック．

ライブ映像も見ることができる．スライド映されても声聞こえないんですけど……．http://vwin.co.th/apsec/

Tao Qin, Lu Zhang, Zhiying Zhou, Dan Hao, Jiasu Sun: Discovering Use Cases from Source Code using the Branch-Reserved Call Graph.

ユースケース図は機能を把握するために便利だけれど，ドキュメントが常に最新に保たれているとは限らない（最悪失われている）ので，ソースコードから最新の状態を発見したい，というもの．

ソースコードから，分岐を残した状態の（if 文の骨格が残った状態の）コールグラフを作成して，関数ごとに作ったものを接続してやる．接続後，重要度(Importance Metric)を計算する．末端には初期値として適当な重みを与えておき，if による分岐なら分岐先の重要度の和，ただの順接しているブロックなら一番大きいものを取り出す，という形で計算していく．で，閾値で枝を刈ったあとに実行トレースを生成する．重要度の計算方法から，条件判定が大きな影響を与える if 文，粒度の大きい関数ほど残りやすいことになるので，その実行トレースはユースケースに近いものになると考えられる．おおざっぱな方法のわりに，そこそこの結果が出ているようで，面白い．

_ Delphi ▲

Delphi から XML を使おうかな？と思ったので探してみた．XDOMJ: XDOM の日本語化した DOM Level2 ライブラリhttp://hp.vector.co.jp/authors/VA017148/delphi/xml/

XML 編集エディタ Open eXeed （Delphi による GPL なエディタ）http://openexeed.sourceforge.jp/ja/about.html