netail.net

_ [hyCalendar] 0.8.6 リリース ▲

これ以上機能追加するときりがなさそうなので，0.8.6 としてリリース．

いーかげん機能的には満足してきたので，次はやはり「タスクトレイへの常駐」だろうか．

Outlook とのインポート／エクスポートに対応してみるのも技術的には面白そうなのだが，使わないツールを作ってもまったくうれしくないのが難点．

ちなみに，0.8.6 をエンターブレイン様のフリーウェア年鑑にも収録していただく予定．致命的なバグとか出なければいいけど…．

_ [論文] EIWASワークショップ ▲

EIWAS'04: 1st European Interactive Workshop on Aspects in Softwarehttp://www.topprax.de/EIWAS04/

というのが開催されていたらしい．あんまり時間がないので，ざっくりメモしておく．

「AOP considered harmful」というパネルでは，advice と対比する形で "come from X" （goto文の逆で，「行 X が実行されたらここに来る」という文）を見せて，アスペクトの濫用の危険性について言及されている．

また，Rémi Douence による， AOP はどんなものか，といった論文が出ていた．AOP そのものはコード再利用が主目的ではないとか，AOP を非機能的要求以外にも使ってるじゃないか，とかベースプログラムの意味を変えるべきではない（プログラムの持つ不変条件に違反しない）とか．

Kasper B. Graversen らによる「アスペクトのアスペクト」はどうだろう，という話もあって，pointcut や advice 定義自体もinter-type declaration できるべきではないのか，みたいな話のよう．

Kris Gybels, and Andy Kellens: An Experiment in Using Inductive Logic Programming to Uncover Pointcuts.これは，アスペクトを既存コードから抽出するときに，とりうる Join Point の組み合わせと結果の Pointcut とを比べるとかして正しく join point を選べるように，とか言っている．

Christian Koppen, Maximilian Stoerzer:PCDiff: Attacking the Fragile Pointcut Problem.こちらは，クラス名やメソッド名の変更によって，pointcut が影響を受けていないか検出しましょうという話．ようやく出てきた？という気もしなくはない．ただ，分かったところで，変更に追随すべきか，すべきでないかを判断するのは難しいのだろうけど…．

István Nagy and Lodewijk Bergmans:Towards Semantic Composition in Aspect-Oriented Programming.attribute (いわゆる javadoc 系のタグ）ベースでpointcut を記述したほうがいいのでは，という論文．こちらのアプローチのほうがPCDiffのアプローチよりも安全そう．属性を付けるルールが明示されていて，間違った属性を付加することがなければ，という限定は付くが．

_ [論文] 実行履歴の図示 ▲

どこかで読んだはずなのだがメモしてなかったみたいなので書いておく．

Dean F. Jerding, John T. Stasko, Thomas Ball:Visualizing Interactions in Program Executions.ICSE 97, pp.360-370, Boston, MA, USA, 1997.

実行履歴を可視化するために，メソッド間の呼び出し関係を接続した地図のようなグラフを表示したり，横軸に時間，縦軸に呼ばれたメソッドをプロットすることで呼び出しパターンを可視化したりということをしている．

_ [論文] トレースデータの抽象的な表示 ▲

Robert J. Walker, Gail C. Murphy, Bjorn Freeman-Benson,Darin Wright, Darin Swanson, Jeremy Isaak:Visualizing Dynamic Software System Information through High-level Models.Proceedings of OOPSLA 98, pp.271-283, Vancouver, B.C., October 1998.

実行トレース情報を，抽象化されたビューにマッピングしましょう，という話．手法としては，上位のコンポーネント（サブシステムなど）を適当にドキュメントなどから見つけてきておいて，開発者は，実行トレースからコンポーネントへのマッピングを宣言的な言語で記述するというもの．

基本的には実行中，時間的にある程度限られた範囲でシステムの中をどのように実行が進んでいるかを見るが，それがどのようなコンテキストで起こったのか，という全体像のようなものがないと使いにくい，ということと，やはりその時点でのスタックの中身および実行中のコードへのリンクみたいなものも必要だ，といった結果がケーススタディの結果として議論されている．

_ [論文] トレースデータの活用 ▲

Johan Moe, David A. Carr:Using Execution Trace Data to Improve Distributed Systems.Software Practice and Experience, Vol.32, No.9, pp.889-906,25 July 2002.

分散システムの開発時に，トレースデータを集めて使ったという話．・長期間のカバレッジ観測でまったく　実行されていないメソッドが見つかった・頻繁なリモートメソッド呼び出し（主にコレクションの取得）を　発見し，修正した・動的メトリクスなどを使ってオブジェクト間の強い結合を見つけたといった感じで使われたらしい．短期間だけでなく，長期間（数日，あるいはそれより長い単位）でトレースデータを使うというのは珍しいかも．

参考文献リストをちらっと見た限りでは，システムの可視化やメトリクスなどへの論文のポインタとして便利そうな感じ．

_ [論文] 依存関係の管理 ▲

S. Ducasse, M. Blay-Fornarino, A.M. Pinna-Dery:A Reflective Model for First Class Dependencies.Proceedings of OOPSLA'95, pp.265-280, Austin, TX, USA.

オブジェクト間の依存関係を，First-Class なエンティティとして管理しましょうという論文．FLO という言語を提案していて，オブジェクト間のリンクを記述する．

たとえば，stack への pop 呼び出しが，memory オブジェクトに store された結果を返す場合，「(pop :stack) implies (store :memory :result)」といったように記述する．関連付け自体をインスタンス化する必要がある点は，association aspect なんかの使い方と同じ．

・オブジェクト間のインタフェースにのみ規定されるので　カプセル化は守られる．

・関連は動的に生成，チェック，破棄される．

・オブジェクト間に双方向のリンクを貼ることができる．（ある一方の変更が他方へ伝わるなど．アドバイスの動作に近い）

・リンク自体が first-class なので，リンク間のリンクなんかも定義できたりする．

propagation が伝わっていく途中でループが起きた場合は，リンクごとに停止用の invariant を書くか，割り込み処理のようなメカニズムを使うらしい．

で，MOPを使った実装の話が載っている．

関連研究については，クラス間の相互通信インタフェースを記述する手法ではクラスの仕様情報が他のクラス定義にまで分散してよくない，また，オブジェクト間のインタラクションの制約を記述すると制約自体がカプセル化を破壊してしまう，などとも言及している．