netail.net

_ readme ▲

英語で readme.txt を書く．以前に比べるとまだ少しはスムーズに書けるようになった気はするが，まだ語彙の不足だけはどうしようもない．なんかいい教材とかないものだろうか．

_ 論文 ▲

輪講でIWPC2003のRaghavan Komondoor, Susan Horwitz: "Effective, Automatic Procedure Extraction" について説明した．

結局，手続き抽出するときにループ中のbreak や return を扱わないとダメだね，と言ってて実際に成功しているけど，やっぱり一番難しいのは，今回対象外となっている「どこが手続きか」を識別することなのかも．

それに，人間とほぼ同じ出力を出すといっても，それが「良いコード」であるとは限らないというところも問題か．

_ Eclipse ▲

Eclipse 3.0 はやはり Java2 SDK 1.5 をサポートする気らしい．プログラム解析なプラグインを書きたい身としては，リリースされ次第反応しないといけないかも．

2.0 から 2.1 でもクラス構成が一部変わったのに，今回またクラス構成が変わってしまうと，追随が難しい．

_ [AspectJ] AspectJのよいところ？ ▲

普通，プログラムとして，「やりたいこと」を書くけれど，AspectJ の declare warning/error みたいに「やってはいけないこと」も一緒に書けるので，特定の concern に限定した（他の開発者には触れてほしくない）メソッドの呼び出しを禁止するとかいった使い方ができて，実はけっこう嬉しい気がするこの頃．

単に設計が悪い可能性も否定できないし，AspectJ の declare error よりは Hyper/J 系を使えという話かもしれないけど．

カスタマイズ可能なコーディングルールチェッカでいいじゃん，とか言われそうだけれど，アプリケーション依存なことがいっぱい含まれているので，ツールの一部というよりはプログラムの一部であるべきという気はする．

_ [論文] Modular Reasoning な話 ▲

G. Kiczales, M. Mezini: Aspect-Oriented Programming and Modular Reasoning.

Proceedings of International Conference on Software Engineering 2005, pp.49-58, May, 2005.

コードが modular であるとは，一箇所にまとめて書かれていて，他のシステムとどのようにインタラクションを起こすかのインタフェースがあって，インタフェースの整合性がチェックできて，他のモジュールと接続することができるとき．また，Modular Reasoning とは，そのモジュールに関する決定が，他のモジュールを見なくてもできるようにすること．

過去の研究では，クラス側をBlack-Boxとみなせるようにアスペクトの影響力を抑えたり，アスペクトについての言及をクラス側で行うというのが多いが，こちらは AspectJ などのフルセットをきちんと扱いたいというもの．

アスペクトのインタフェースをどう規定するとうれしいか，というのがメインの話題で，アスペクトのインタフェースの中には，アドバイスやポイントカットの宣言と，それがどこで動くのかというクラスのメソッドのリストなども含めている．ただし，executionポイントカットならメソッド名だけでいいが，callやget, setについては join point shadow を含んだメソッドをリストするという程度で，良いアイディアは今のところないらしい．

PointクラスとLineクラスの座標移動時のDisplayUpdatingに関するアスペクトの例を用いて，Non-AOPとAOPについてのReasoningの作業の違いを簡単に説明している．DisplayのUpdateが，オブジェクトが移動した後にただ１度だけ起きることを理解して，それを守った形でコードを変更するには，そのルールについてのドキュメントにたどり着くという作業と，DisplayUpdateを起こすタイミングを知る必要がある．Non-AOPとAOPで，ドキュメントを調べる作業までは同じだが，DisplayUpdatingの振る舞いを調べるのは，Non-AOPの実装では全体を読んでいく必要があり，AOP実装だと簡単に知ることができると述べている．

_ [論文]仮定の記述をアーキテクチャの図に含める ▲

P. Lago, H. van Vliet: Explicit Assumptions Enrich Architectural Models.

Proceedings of International Conferenc on Software Engineering 2005, pp.206-214, May 2005.

ほとんど図だけの拾い読み．

変化するものを管理するのと同様に，変化しないもの，システムに対する様々な仮定（技術的・管理上など）もきちんと扱いましょうというものらしい．アーキテクチャの図（Feature Model とかクラスより抽象度の高い図）で，仮定を表現した assumption という要素を配置して，どのfeatureに影響を与えているか F-Impacts 辺を作って示す．また，featureを実装する役割の要素（featureからリンクされている要素の一部）からは，assumption に対して Realize 辺を引くといった感じ．

最終的には，作ったアーキテクチャから，実際のモジュールへの対応を追いかけていくと，assumption が変化したときへの応対などが楽になりそうではある．traceability が確立されてないといけないから，MDAとか好きな人にはよいのかも．