netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2005-12-03 [長年日記] ▲
_ [hyCalendar] ログオフ時にオプションが保存されない問題を修正 ▲
ログオフ時は，FormClose イベントがなぜか飛んでこないのでファイル保存に失敗していた問題を修正．素直に CloseQuery で true を返すタイミングで保存すればいい，ということに気づくまでにずいぶん時間がかかった．
他に何事もなければ，このバイナリが 1.3.3 になる予定．ドキュメント書く時間とかの都合で，リリース自体は少し先送り．
2005-11-27 [長年日記] ▲
_ [論文] アスペクトの単体テスト ▲
Cristina Videira Lopes and Trung Chi Ngo: Unit-Testing Aspectual Behavior.
ISSRE 2005 Workshop on Testing Aspect-Oriented Programs.
アドバイスのテストについての Position Paper．題材には Jaml という，アドバイスの中身をクラスとして書いて，結合には XML を使うという言語を使っている．
テスト方法としては，MockJoinPoint という Join Point の中身を作成し，それをアドバイスに渡して実行するだけ．利点は，JUnit に親しい開発者なら簡単に導入できることと，おおげさな仕組みが必要ないこと．
これに対する問題点は，与える MockJoinPoint が本当にそのアドバイスを実行するのに適切でないといけないこと，コンテキストとして適切なオブジェクト（this や target）を設定すること．どういう join point をテストケースとして用意すると嬉しいかは実験が必要だろうし，依存関係解析などでコンテキストをある程度自動的に作るとかいった方法があるだろう，と述べている．
また，AspectJ では，アスペクトの振る舞いを独立した実行コードとして実現できない（あちこちに weave されるという形でしかコードが現れない）のでアスペクトの振る舞いをテストしにくい，ということも指摘している．
2005-11-25 [長年日記] ▲
_ [論文] 状態に基づくJoin Point Model ▲
Noorazean Mohd Ali, Awais Rashid: A State-based Join Point Model for AOP.
Proceedings of Workshop on Views, Aspects and Roles (VAR) (held with ECOOP 2005).
オブジェクトの状態変数に基づいて状態機械をモデル化し，状態遷移に対してアスペクトを定義しよう，という提案．オブジェクトの具体的な変数値と状態機械を対応付けるモデリングのためのアスペクトと，その状態遷移に対してアドバイスを関連付けるアスペクトを組み合わせて使う．アドバイスとしては，特定の状態遷移や，状態遷移の列（transition flow）への対応が可能としている．
event-based でのメソッド呼び出し列を状態遷移としたオートマトンを構築する試みとの違いとしては，複数のメソッド呼び出しによるデータ操作などイベント列では定義しにくい状態遷移をうまく表現できる可能性がある．
メソッド呼び出し列による状態遷移の定義で作った状態遷移モデル＋JML などを使った事前条件や事後条件としての変数値の状態の指定と，このデータによって定義された状態遷移モデルとを付き合わせると，ちょっとした比較ができるような気がする（できてどうなるかは不明だけど）．
2005-11-23 [長年日記] ▲
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 より大とか，今のところ，単純なフィルタとしての使い方しかしていない様子．
_ かな [はじめまして。inkscape使い方教えてくれますか？ブログのアイコン作りたいので良かったらお返事ください。]