netail.net

_ Ruby ▲

ディレクトリ内部のファイル名の一括変更方法が分からなかったので，Ruby で実行．"p Dir.methods" とか "p Dir.open(".").methods" とかやって使い方をオブジェクトに聞きながら作ってみた．

ruby -e 'Dir.open(".")each { |filename| system("mv #{filename} #{filename.gsub(\".jar\", \".zip\") }")if filename [-4, 4] == ".jar") } '

この辺の手軽さが，Perl との違いかも．

_ Eclipse ▲

eclipse.org で公開されている統合開発環境 Eclipse を動かしてみる．ぱっと見の特徴は，・間違ってるところにアンダーラインを引いてくれるので見やすい・エラーを含むファイルのアイコンにマークが付く・コンパイルが高速．インクリメンタルコンパイルをしている？など．実はすごいツールかも．Libretto で動かすには画面が狭いけど．

_ [Java]J2SE 5.0 (JDK1.5) ▲

J2SE 5.0 をインストールしてみた．今までは C:/ 直下にディレクトリを作っていたのに，なんと Program Files 以下にインストールされる．とても大きな進化．

_ [論文]アーキテクチャレベルでの情報可視化 ▲

Mohlalefi Sefika, Aamod Sane and Roy H. Campbell:Architecture-Oriented Visualization.Proceedings of OOPSLA96, pp.389-405, CA, USA.

情報をまとめて抽象化して提示するのが大事ですよと主張する論文．メソッド単位，クラス単位ではなくサブシステム単位などで情報を集計した結果を出すためにInstrument という名前の観測ツールをCompositeパターンで合成して使うらしい．どのクラスがどのサブシステムに対応するかは開発者が与えないといけないので手間はそれなりにかかる．

_ [論文]オブジェクトの探索 ▲

Raimondas Lencevicius, Urs Holzle, Ambuj K. Singh:Query-Based Debugging of Object-Oriented Programs.Proceedings of OOPSLA97, pp.304-317, Atlanta, GA, USA.(注: Holzle の o はウムラウトつき)

デバッグ時にオブジェクトの情報を参照したいけど普通のデバッガだと特定のインスタンスしか見れないのでクエリーにマッチするようなオブジェクトのペア（というかtuple）を取り出してきましょうという話．

クエリーかけるのに a == b かどうかの判定ができないといけないとか，属性（フィールド）の参照に副作用があってはいけないとかいう条件は付くが，(a include b) and (c include b) and (a != c) のようにしてオブジェクト b を共有しているオブジェクト a, c のペアを見つけるとか，何か色々な使い方はできる，ということらしい．筆者たちの実装では，オブジェクト集合から該当オブジェクトを探すパフォーマンスもそれほど悪くない（１秒程度で結果が表示され始める）らしい．

いつクエリーを実行して，どうデバッグに使えるのかというところについての言及はあまりなかったりするが……．条件付ブレークポイントに比べてどのくらい便利なのか？というのがいまいち見えてこなかったりする．「あるクエリーにマッチするオブジェクトのメソッドが呼ばれたなら……」という条件付ブレークポイントなんかを作れば便利？

_ [work]動的解析の高速化 ▲

プロファイル結果→イベント列→集計情報→頂点集約→DOTという段階を踏んで処理を進めていくと，各頂点が集約対象かチェック→頂点に接続した辺を操作という処理が O(V*E): Vは頂点数，Eは辺数となってしまって遅くてたまらないことが判明．（辺のつなぎ替えが集合の操作なので実はさらに遅い…）

除去されることになる頂点については，それぞれ source(V) = {V に到達する依存関係の発生頂点の集合}という集合を記憶しておいて，{除去される頂点 V → 除去されない頂点 v }の依存関係が発生したらsource(V) の各頂点 → v の辺を生成するようにした．

こうすると，ログのサイズ n に比例する時間で処理が進むのでだいぶ高速になった．集合の管理の手間があるので，厳密に O(n) とは限らないが．

とはいえ，AspectJ のコードだと，AspectJ がいっぱい依存関係を追加で生成しているようでデータ依存関係が分かりやすいとは到底いえないみたい．

_ [ツール] Tortoise SVN のセットアップ ▲

前のPCで使っていて，しばらくツール開発から離れていたので，いまさらながらインストール．前のPCでローカルに作ってたリポジトリを持ってきたら，subversion と bdb のバージョンが合わない(?)といったエラーが出てきた．

cygwin の subversion などもかなり古かった（今はもう1.2.3が出ているのに1.1系だった）ので，一回リポジトリを再構築してみた．

svnadmin dump Subversion/ > dumpfile.txt # 情報のエクスポート
Subversion/ ディレクトリを移動
cygwin の subversion をアップグレード
TortoiseSVN から新しいリポジトリ作成
  （このとき，ついでに bdb をやめて fsfs にした）
svnadmin load Subversion/ < dumpfile.txt

_ [論文] アスペクトが与える影響をどう表示するか問題 ▲

Wesley Coelho, Gail C. Murphy: ActiveAspect: Presenting Crosscutting Structure.

Proceedings of Workshop on Modeling and Analysis of Concerns in Software (MACS 2005).

AJDTのツリービューとかでは横断的関心事の構造は見づらいし，Composition patterns （下の論文）の記法ではアスペクトが実際にどこに接続されているかが分からないので困る．ということで新しくビューアを作りたい，というショートペーパー．

基本的にはアスペクトが貼りついている先（callポイントカットならメソッドの呼び出し側と呼び出し先のクラス）と，その継承階層，アスペクトが直接参照しているクラス，ぐらいを関係図として示す．また，対象の数が多いときはパッケージ単位などでクラス表示をまとめる，といったアイディアも示している．

グラフ表現だといかに要素数が増えるのを防ぐか，という問題がメインなのかも．

_ [論文] UML的表現でアスペクトを書く ▲

S. Clarke and R. J. Walker: Composition patterns: An approach to designing reusable aspects.

Proceedings of International Conference on Software Engineering 2001 (ICSE 2001), pp.5-14, 2001.

昔読んだはずなのにメモに入ってなかったので読み直し．

横断的関心事について図で記述するために，クラス図とシーケンス図を使って，横断的関心事のテンプレートを書こうというもの．ステレオタイプ「subject」としてアスペクトの名前を書き，包含する要素としてそのアスペクトに参加するクラス（そのクラスが持つメンバーのリスト）と，そのクラス群が起こす動作のシーケンス図を記述する．

クラス図側が，クラスがどのようなメンバーを持っているべきかという制約の記述とインタータイプ宣言を担当し，シーケンス図側が，そのメンバーの振舞い（pointcutとアドバイスの動き方）を指定する．

この状態で，アスペクトの中の各クラスやメンバー名に，実際にどのクラスやメソッドが該当するかを bind する．

アスペクトを，結合対象のクラスから分離して記述するのは，接続対象が多いロギングなどのアスペクトについては有効だと思われる．ただ，bind 結果の具体例くらいは一緒に書き添えないと理解が難しいかもしれない．

_ [論文] ASE 2006 の情報少しだけまとめ ▲

NIIでやってたASE2006は，参加者221人(うち本会議参加者は182人)，日本人が当然ながら最多で129人，USAから33人，ドイツから13人，フランスから12人．論文投稿数は121，うち22本がフルペーパー，17本がショートペーパー採録でした．フルペーパー採択率は18％．

個人的な印象としては，formal methods を使えるツールにしていこう，と努力してる人が目立った気がします．

便利そうなツールとしては，基調講演で紹介されていた仕様記述＆検証環境のCafeObj，Java などオブジェクトの要素をちゃんと扱ってコードのモデルチェックをしようというBogorあたりでしょうか．後者のほうは某先生が「授業で使おうかな」とか仰ってたくらいに良いもののようです（さすがにこの種のツールの良さはまだ自分では判断できないので伝聞形です）．

そのほかにも，ツールの使い勝手という側面では，コンパイラに組み込んだらどう？と Volanschi, N.: "A Portable Compiler-Integrated Approach to Permanent Checking" が提案していたり，ツール自体のカスタマイズを容易にするためにZ言語でコード量を小さく抑えてみた，と Ledru, Y. et al.: "Tobias-Z: An executable formal specification of a test generator" が言っていたりしました（Tobias 自体はテストケース生成ツールです）．

_ [論文] ASE 2006 でのアスペクト関連な話 ▲

ASE の formal methods 系に少し関連しそうな AOP 関連の発表としては，では，Falcarin, P. et al.: "Automated Reasoning on Aspects Interactions", Stoerzer, M. et al.: "Detecting Precedence-Related Advice Interference" の２本のショートペーパーがありました（他にはアスペクトマイニングの発表なんかもありました）．

前者はアドバイスが書くデータを読むアドバイスやメソッドが他にいるかどうかを調べて警告を出す，後者はアスペクトの動作順によって文間の依存関係が変わってしまうような場合に警告を出す，というツールの提案です．

どちらの手法も，「あるとちょっと嬉しい」というのは分かっても，本当にどのくらい役立つ事例があるのかはよく分かりません．現時点では世の中にあまり AspectJ プログラムが転がってるわけではないので（Stoerzer は実例は１個だけ知っていると言ってました），その辺は仕方ないかなと思います．

AOASIA の話は独立して長くなりそうなんでまた後日にします．