netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-11-22 古い日記からの変換データ ▲
_ ワイン ▲
ジャック・デパニューのボジョレー・ヌーボーを飲んだ．けっこう香りが強くて渋い．ボジョレーってライトボディじゃなかったっけ？美味しいからいいんだけど．この分だと，フルボディと言われているワインがどうなってるか楽しみ．
2004-11-22 古い日記からの変換データ ▲
_ [Java]Generics の制限 ▲
Generics で型パラメータを static メソッドに与えようとしたら怒られた．また，instanceof でも比較対象に型パラメータを使えないらしい．
これらは，C++ template の場合と違って，型情報が実行時には落とされてクラス自体は１個しか存在しないためらしい．なので，型パラメータごとに Singleton なインスタンスを作ろうとしたりはできないらしい．
Singleton 問題を回避するのに，Factory パターンを使って型パラメータごとに Factory を１個生成して，それぞれの Factory が Singleton なインスタンスを管理するようにしてみた．
2005-11-22 ▲
_ [読書][AspectJ] アスペクト指向入門 ▲
千葉先生の本が出ていたと聞いて買ってみた．ちょうどアスペクト指向の授業を終えたところなので，タイミング的には少し遅かったけれど．「アスペクト指向は呼ぶ側のモジュールを再利用するための技術」という説明のしかたをしている部分は，そういう言い方もあるのね，とちょっと感心した．
アスペクト（アドバイス）間の干渉の問題についても少し触れられていたけれど，この問題は，実用性に影響を与えているというよりも，開発者にとっての「書いたプログラムがどういう順序で動くか良く分からないのは気持ち悪い」という心理的影響が大きい気がするこの頃．
アスペクトの Obliviousness によってクラス側にアスペクトのコードがまったく入らない気持ち悪さも，これに似ているかもしれない．アスペクトに書かれた処理を呼び出すためだけの不自然な文を入れるとかいった愉快なプログラマがいなければ，調査用のツールさえ一緒に使えれば大丈夫な気はする．オブジェクト指向でも，Delphi の一部のコンポーネントとか，
_ [論文]コードクローン技術を使ったアスペクトマイニングの実験 ▲
Magiel Bruntink, Arie van Deursen, Remco van Engelen, and Tom Tourwe: On the Use of Clone Detection for Identifying Crosscutting Concern Code.
IEEE Transactions on Software Engineering, Vol.31, No.10, pp.804-818, October 2005.
横断的関心事の中には，モジュール化機構が存在しないから仕方なくあちこちに同じ実装をばらまいてしまっているものがあるはずだ，という仮定に基づいて，コードクローン検出ツール３つを使って，本当に見つけられるかどうかを実験している．
各関心事をあらかじめコード中に見つけておいて，クローン検出で出てきたものとつき合わせる．関心事もクローンも，プログラム行の集合ととらえて，手でマークをつけた行のうちどれだけがクローンに入っていたかで再現率・正確性を評価している．ただし，いくつのクローンを調べるかで，クローンとして検出されたクラス群のうち，正確性の向上に一番貢献するものから優先的に（greedy に）k個選び出している．
この選択のやり方でアスペクトを探した場合，手でマークをつけた情報に依存して正確性が決まっているので，マークがないコードに対するアスペクトマイニングでは，この性能を超えることはないだろう，と言及されている．マークつきでもログ記録は60％程度，エラー処理は40％程度しか見つけられない，という情報が，自動的なアスペクトマイニングの性能がどのくらい良いのか悪いのかを考える指標にはなりそう（ログ記録とエラー処理のどちらが相手かで，30％のコードを発見した，の意味合いがかなり変わる）．
_ [論文] feature trace をリビジョンごとに作る ▲
Orla Greevy, Stephane Ducasse and Tudor Girba: Analyzing Feature Traces to Incorporate the Semantics of Change in Software Evolution Analysis.
Proceedings of ICSM 2005, pp.347-356.
どのクラスがいくつのフィーチャーに参加しているかを not covered/single/group/infrastructural に分類するが，バージョン間での変化量を使って，機能の追加とか削除を識別しようという試み．
単純には，直前の変更で参加するフィーチャー数が増えてカテゴリが変わったならactivity をプラスに，減ってカテゴリを移動したならマイナスに，not covered に移動したら 0 にする．で，プラスなら新機能の追加か再利用が発生しており，マイナスなら機能が削られている可能性が高く，0なら obsolete になっている，といった判断をする．
実行してトレースをとって，特定のフィーチャー集合についての分析なので，クラスのカテゴリが変わるというのは非機能的要求の追加・削除が影響しているだろうと考えている様子．もちろん，実行で一度も触れられなかったクラス群に対しては何の評価も下すことはない．
カテゴリにランク値を与えて（not covered を0として始めて，infraが3）平均値とか今までの変化量の総和とかも計算しているのだが，変化量が 0 より大とか，今のところ，単純なフィルタとしての使い方しかしていない様子．
