netail.net

_ 卒業式 ▲

学位授与式ということで，修了証書をもらってきた．あまりありがたみはないが……．これで最終学歴がようやく高卒から修士に変わった．

_ 読書 ▲

J・グレゴリイ・キイズ「錬金術師の魔砲」（上）読了．１セクション20ページ程度で場面を切り替えていくので，テンポがよくて読みやすい．怪しげな科学と錬金術の入り乱れた世界なので，変な小道具がいっぱい出てくる．このあたりはけっこう好みかも．

_ Java ▲

developer Works の記事で，浮動小数点の比較などに関してまとめた話が掲載されていた．0 == -0 なのに Float(0) > Float(-0) だったりNaN != NaN なのに Float(NaN).equals(Float(NaN)) だったり．まったく使わないので知らなかった．とりあえずメモしておく．

http://www-6.ibm.com/jp/developerworks/java/030314/j_j-jtp0114.html

_ AOSD ▲

AOSD本会議２日目．Aspect-Oriented Programming 系が強くてRequirements Engineering や Software Design なんかの話は少ない．Keynote と，IBM の AOP 実践の話ぐらいか．

ランカスターはなんかゆっくり時間が流れている気がする．夜19:00にはほとんどの店が閉まっているので食事とか困るけど．

_ AspectJ入門用ドキュメントの執筆 ▲

過去の授業スライドの説明文章を展開するだけの作業と言えなくもないが，ぼちぼち書き始めてみる．あまり長くないドキュメントにしたいので，実際のコード例を多めに含めて例ベースで説明できたらいいかな？というところ．

_ 今日のはまり． ▲

シンボリックリンクに対して，ファイル更新するスクリプトを走らせたら，そのスクリプトはデータ読み込み→既存のファイルをリネームして退避→ファイルを開いてデータ書き込み，という動きをしていたので，リンクがリネームされて，リンク先ファイルを更新せず，新しいファイルが生成されてしまっていた．

_ [論文]アスペクト合成の問題 ▲

Roberto E. Lopez-Herrejon and Don Batory: Improving Incremental Development in AspectJ by Bounding Quantification.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

"set*" のようなワイルドカードの使用が，後から追加されたメソッドにもマッチしてしまって問題を引き起こすことがある，という話．

アスペクトのうち，インタータイプ宣言を加算項 "a" として，ポイントカット定義を乗算として作用する項 "m" と考えたときに，A2・A1・P = (m2 + m1) * (a2 + a1 + P) と考えると， a2 に対しても m1 が作用してしまうことが原因であろう，と分析している．A2・A1・P = m2 * (a2 + m1 * (a1 + P) ) と結合を変えることで，この問題に対処できる，というもの．

これだけで問題が全部解決しているわけではなくて，declare parentsとかアスペクトの継承とか考えることはあるが，アスペクトが何でもとりあえず貼り付けばいいというわけではない，ワイルドカードが危険で，ちゃんと貼りつく範囲をうまく限定する必要があるねという方向性が見えたという点で，けっこう重要そうな印象．

_ [論文]クエリーベースの織り込み ▲

Istvan Nagy, Lodewijk Bergmans, Gurcan Gulesir, Pascal Durr, Mehmet Aksit: Generic, Property Based Queries for Evolvable Weaving Specifications.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

アドバイスの実装を複数のアスペクトとして使いまわしたり，ポイントカット定義を共有するために，論理型言語っぽいクエリーを使って，「figureClasses は FigureElement クラスを継承したすべてのクラス」「tracingModules は Tracing に属するすべてのモジュール」といったような条件を定義して，figureClasses に tracingModules を持たせる，という定義を行うらしい．

annotationを使った例なども載っていて，有利な点は，多対多のマッピングを簡単に作れること．すべてのモジュールの組み合わせを列挙しなくてよくなる．また，annotationなどをうまく使えば，新しい要素を追加するときにも，特定のannotationを付加すれば完了，となるので作業は楽になる．

不利な点は，クエリー自体が間接的な記述なので，今までのexplicitな定義より読みにくくなる可能性が高いことと，クエリーの条件で使うモジュール名やannotationを開発者が一貫した定義で用いてくれないと怪しいマッチ結果になってしまう可能性があること．

annotationのある場合とない場合とを別に議論してくれているので，annotationの有効性について話したいときには引用できるかも．

_ [論文]アルゴリズムをAOP的に書く ▲

Karl Matthias Hamel, Klaus Ostermann: Modularity and Reusability of Algorithms - A Case Study using Caesar.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

STLコンテナのようにアルゴリズムを接続したいね，という話らしい．Caesar では動的なアスペクトの織り込みが可能なので，特定のデータクラスにアルゴリズムアスペクトをバインドして計算，とかやってみたいらしい．特別有効とか効果がないとかいうことはないようだが…．

_ [論文]Extract Method Calls リファクタリングの自動化の問題 ▲

Andy Kellens, Kris Gybels: Issues in Performing and Automating the "Extract Method Calls" Refactoring.

Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.

アスペクトとして抽出したいメソッド呼び出しが，メソッドの実装の先頭や終端以外に現れたり，計算式の途中に現れたりすると，アスペクトを自動で取り出すのがうまくいかないとかいう問題がある，らしい．で，それを文単位の Join Point を用意して問題を解決しようとしている様子．やりたいことは良く分かってないが，Join point 同士の関係をグラフ化した図は（そんな大層なものではないが）他で見たことがないので面白いかも．