«前の日記(2004-12-25) 最新 次の日記(2004-12-31)» 編集

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2004-12-29 古い日記からの変換データ [長年日記]

_ [論文]制御フローに基づくアスペクトマイニング

Jens Krinke, Silvia Breu:Control-Flow-Graph-Based Aspect Mining.1st Workshop on Aspect Reverse Engineering.

以前実行トレースからマイニングしていたものを,制御フローグラフから探してみたというもの.で,それなりに候補は出てきたようなのだが,Iterator などコレクションの処理や,あるメソッドを実行した後の後始末など,アスペクトとして抽出しにくいものも一緒に出てきてしまうらしい.アスペクトにできるものもきちんと含んでいるようなので,いかに "refactorable" なものだけを抽出できるようにするかが問題だろうと考えている様子.

_ [論文]重要なクラスを見つける

Andy Zaidman, Toon Calders, Serge Demeyer, Jan Paredans:Selective Introduction of Aspects for Program Comprehension.1st Workshop on Aspect Reverse Engineering.

重要なクラスにだけロギングなどのアスペクトを追加したいが,どうすれば重要なクラスを見つけられるだろうか,ということで通常のプロファイル結果からノードをクラス単位にまとめたコールグラフを作成し,Web で使われる Hub/Authority の識別を行うことを提案している.

Hub は数多くのモジュールを呼び出すモジュールで,Authority は数多くのモジュールに呼び出されるモジュール.で,Authority がいわゆる Utility など再利用可能なクラスであることが多く,Hub はプログラムを駆動する側にあるだろう,ということからHub が重要である,と認識する.ケーススタディとして Ant のプロジェクトに適用していて,Ant 開発者がマーキングしたクラスを正解とみて,評価してみている.CBO による順序付けよりは,人間が重要だとマークしたものを見落とす可能性はかなり少なくなっている.ただ,正解率的には6割程度.また,通常のコールグラフでなくプロファイル結果なので,シナリオによるバイアスがかかる可能性がある.(「そのシナリオで」重要なクラスを見つける,という意味では問題ないが)

あんまりアスペクト限定の話ではないような気もする.

_ [論文]アスペクト導入の効果は?

1st Workshop on Aspect Reverse Engineering より.5ページのショートペーパー群.Aspect Mining/Refactoring がテーマ.http://homepages.cwi.nl/~tourwe/ware/submissions.html

_ Mariano Ceccato and Paolo Tonella:Measuring the Effects of Software Aspectization.

アスペクト導入によるメトリクス値の変化を調べることでアスペクト導入の効果を測りましょうという論文.

Observer パターンの Java 実装と AspectJ 実装を比べていて,AspectJ バージョンのほうが1モジュールあたりの機能数である Weighted Operations in Module (WOM) が低くなりそのモジュールが呼び出す他のモジュール数 Coupling on Method Calls (CMC) や\呼び出されうるメソッドの数 RFM (Response For a Module) は減少している.

で,逆に悪くなっているのは,AbstractObserverProtocol の導入によって継承階層が増加すること.あと,アスペクトがどれだけのモジュールを横断しているかという指数だけは増える(当然ながら).

これだけだと,AOP アプローチのほうが有利に見えているのだが,使っているメトリクスで「アスペクトが横断しているモジュールの数」などはJava 実装との比較評価には使っても意味がなさそうなので,まだ何とも言えないような気がする.

_ [論文]クラス構造の分類に基づくパターンの調査

Gabriela Arevalo, Frank Buchli, Oscar Nierstrasz:Detecting Implicit Collaboration Patterns.Proceedings of 11th Working Conference on Reverse Engineering (WCRE'04), pp.122-131,November 8-12, 2004, Delft, The Netherlands.

クラス図から,A isSubclass B, A access B などのクラス間の関係を取り出し,クラス図から選んだいくつかのクラス(この論文では2〜5個程度)の連結関係を Formal Concept Analysis で分類し,デザインパターンの連結構造と比較することでパターンの実装などを発見しようという試み.

クラス図からクラス群を選ぶときの組み合わせを減らすことや,分類結果から「同じ型」をマージするなど,組み合わせ数を減らすことに気を配っている.

パターンとよく似た形になっているものなども見つけることができるが,逆に,デザインパターンと偶然同じ形になったものというのも登場してしまう.また,分類された結果から,実際に有用かどうかを検査するのは別の問題になっている.

_ [論文]Topic Map によるソフトウェアの可視化

読んだまま放置していた論文メモをざっくり整理.

Christian Zimmer:Tuna: Ontology-Based Source Code Navigation and Annotation.Workshop on Ontologies as Software Engineering Artifacts.

Topic Map というグラフによる知識表現でソース情報を表現するために,Topic Map の各要素が何をあらわすかを定義している論文.で,実際に Topic Map に対応したビューア&クエリーかけツールを作っている.出力がグラフになったらコードが読みやすいかというとそうでもないと思うのだが.JQuery よりは言語非依存といえるが,提供できるサービス量はどうなのかよくわからない.

_ [hyCalendar]towards 1.0

メール&掲示板で色々要望は集まってきた.

アプリが開いている単体ファイルに対応していたCalendarDocument クラスが今まで単体だったものが複数インスタンスへ変化するので,暗黙のうちに Singleton を前提としてしまっているコードがだいぶ変更されてしまう.

Singleton に染まったコードをうまく解除する変更パターンのようなものはないものだろうか….

お名前:
E-mail:
右の画像に書かれている文字列を入力してください:
コメント: