netail.net

_ 入学手続き ▲

大学院博士後期課程の入学手続きをしに大学へ．入学料はいらないし，授業料は自動引き落としなので，手続きは一瞬．これで三度目の入学式の案内をもらった．

_ 論文 ▲

SPLAT2004 残り２本．

Istvan Nagy, Lodewijk Bergmans, Mehmet Aksit:Declarative Aspect Composition.特定の join point に複数のアスペクトがくっつくとき，往々にして「アスペクトAの後に，アスペクトBは動く」とか「アスペクトAが動かないときだけアスペクトBが動く」といった関係が生じることがある．このような関係を，宣言的に記述することであとは言語処理系が勝手に処理しようというもの．Aが動く，動かないというのを boolean メソッドで判定するあたりいい加減なようで，わりと実用的かも．

_ 論文 ▲

Thomas Cottenier, TzillaLinguistic provisions for Aspect/Core semantic interactions.

Aspect と Core（ベースモジュール）の間を橋渡しするような何か（invariants とか）がないと，現在のような Syntax-based で記述する joinpoints になってしまって，Syntax-based ではクラスの改変にあわせて join points も変わってしまうのでうれしくない．

"Semantic" な記述ができるとうれしい，といいたいのだろうが，何をもって semantic と言っているのか分からないので，現状ではなんともいえない．

_ 論文 ▲

splat2004 つづき．

Bert Lagaisse, Wouter Joosen, Bart De Win:Managing semantic interference with aspect integration contracts.

アスペクトはコンポーネントに対して何を要求するか，コンポーネントはアスペクトに対して何を許すか，を記述することでアスペクトが不用意にコンポーネントの状態を破壊したりしないようにするという話．

Kasper B. Graversen:Role collaborations.

コラボレーションごとに，役割（Role）が用意されていて，コラボレーションのインスタンスごとに，その役割にオブジェクトを関連付けることでインタラクションをしようというもの．なんか昔考えた（けれど効果が疑わしいので捨てた）アイディアに近い．

Pengcheng Wu and Mitchell Wand:An Empirical Study of the Demeter System.

いわゆる Adaptive Programming を実際に使って，オブジェクトの Traverse 関連のコードがどれだけ減ったか，という論文．実際に Traverse 処理というのはプログラム中にけっこうあるらしく，結果としては，かなり効果があった，らしい．

Tom Tourwe and Andy Kellens:Inductively Generated Pointcuts to Support Refactoring to Aspects.

プログラム構造が改変されたら pointcut 定義も変更しなければならないので，アスペクトと Refactoring との相性の悪さが問題となっている．プログラムの情報を使って帰納的に pointcut を簡潔な形式に変換してやろう，というもの．ただ，自動生成が本当に正しいかどうか，とかを調べるのが難しいので，必ずしもうまくいっているわけではないよう．

_ 論文 ▲

SPLAT2004 ワークショップ参加前準備として論文読み．

Erik Ernst:Simple, eh?言語の単純さというのはどういう意味があるのか，というワークショップのテーマ的な論文．言語のコンセプト・文法の単純さがcomprehensibilityには重要．また，predictabilityは，「何が起きるか」という意味では言語がハードウェアに近いほど簡単となるが，それは情報隠蔽の性質でもある．"semantic interactions"は，変数への代入文がその後のプログラム実行に影響を与えるような状態（依存関係の影響）をあらわしている言葉のつもりだったらしい．

_ 論文 ▲

Jonathan Aldrich:Open Modules: Reconciling Extensibility and Information Hiding.Proceedings of SPLAT 2004 in conjunction with AOSD 2004, March (2004).

アスペクトが追加できる範囲を・モジュールインタフェースとして宣言されたメソッドへの外部からの呼び出し・モジュールインタフェースとして宣言された pointcutに抑えることで，カプセル化を守ろうという提案．

_ 論文 ▲

Gustav Bostrom:A case study on estimating the software engineering properties of implementing Database Encryption as an aspect.

データの暗号化をアスペクトを使ってやってみた，という話．ところが，SQL の LIKE 文による部分文字列のマッチが，暗号化に対応できなくて困ったらしい．Comprehensibility と Evolvability は下がったが，ツールサポートが大きく影響を与えたらしい．また，Evolvability については，インタフェースが安定している（pointcut 定義が変わらない）ことが強く影響するみたい．

_ tdiarysearch ▲

ネックだった検索まわりも，お手ごろなインタフェースの tdiarysearch を発見できたので，いちおう解決． というわけで，tdiary に正式に移行することに．

_ [Java]Contract4J ▲

メソッド引数宣言に対する @pre 属性，メソッドに対する @post 属性，クラスに対する @contract 属性などとして条件式をくっつけておくと，assert文として読み替えてくれるツールみたい．公式サイトを見ていたら，assert 文をそのままプログラムに書くと "contract" concern がソースと混ざってしまうね，といったことを主張していた．やりたいことも，やってることもわりと素直．

AspectJ を使って annotation をインタータイプ宣言して制約を付加するようになると，それなりに面白いと言えなくはないが，やっぱりオブジェクトなどの実行状態（コンテキスト？）を表現できないので，やっぱり何か足りない気がする．

_ [論文]デザインパターンのアスペクト指向実装の定量的評価 ▲

A. Garcia, C. Sant'Anna, E. Figueiredo, U. Kulesza, C. Lucena, A. von Staa:

Modularizing Design Patterns with Aspects: A Quantitative Study.

Proceedings of AOSD 2005, pp.3-14, Chicago, Illinois, March 2005.

デザインパターンをアスペクト指向で書くと嬉しいことがある，とは今までにも言われてきたが，それがソフトウェアの品質メトリクス的に本当のことなのかどうか調べてみようという論文．

計測方法としては，「関心事の分離されている度合い」として，デザインパターンを１つの関心事と見たときに，関心事に参加しているクラス，アスペクトの数とそれにアクセスするクラス，アスペクトの数の合計を「拡散度合い」と考えて，クラス・アスペクト単位での数，メソッド・アドバイス単位での数を調べている（小さいほど固まっている = 良い分離）．また，凝集度，結合度，行数を見ている．

結果としては，良くなるものもあれば悪くなるものもある，という点ではKiczalesらの定性的な評価から極端な変化はない．

「関心事の分離されている度合い」が上がっても，その結果出てきたクラス群が強い依存関係を持っていたり，妙に行数が増えたり（実装が複雑になったり），といった結果になって，結果が良さそうなのは Observer や Mediator など一部だけに限られていた様子．まあ，何でもかんでもAOPで書いて嬉しくなるわけがないので，そこは当然だろうけど…．

評価メトリクスの妥当性やら実験対象の正しさやらの問題は微妙にあるが，Separation of Concerns を無理に進めると問題が起きる可能性に言及したくなったときには引用できそう．