netail.net

_ 論文 ▲

Elissa Newmann and William L. Scherlis:Toward Query-based Constraints

Concern を探すのにsemantic なクエリーを使えるFEAT というツールの話をしている．FEAT そのものの話は ICSE にも出ていた．

この論文での制約というのは「このクラスのサブクラスはこれらのただ二つだけ」とか「このメソッドを呼びたいなら lock をしておけ」とかいう感じの制約のこと．

concern をモデルから取り出して，それらをクエリーによって定義して，concern 間の結合度や合成の制約をクエリーの与える制約によって調べたりできる……のかなぁ．これ自体は Position Paper だったので，素直に FEAT の論文を読んだほうがよさそう．

_ 論文 ▲

Sergei Kojarski, Karl Lieberherr, David H. Lorenz, Robert Hirschfeld:Aspectual ReflectionAOSD 2003 SPLAT Workshop

アスペクトのアプローチとリフレクションを分類した論文．Core Reflection Mechanism と Aspectual Reflection Mechanism を区分けしている．

Core Reflection == メソッド名などの構造的要素Aspectual Reflection == Join Points のような時系列的な要素

主なグループ分けとしては

Smalltak = CRM で実装されたリフレクションインタフェース RI^RAspectS = CRM で実装されたアスペクトインタフェース RI^AAspectJ = ARM で実装されたアスペクトインタフェース AI^ARaspect = ARM で実装されたリフレクションインタフェース I^R

と対応付けている（厳密には AspectJ ではリフレクションが使えたりするので RI^R な側面も持っていることも述べられている）．

_ 論文 ▲

Jeff Gray, Ted Bapty, Sandeep Neema, James Tuck:Handling Crosscutting Constraints inDomain-Specific Modeling

SPLAT2003あたりに出ていた論文．GPCE に出ていたのと同じで，モデルの制約記述をモデルと独立に書いておいてWeaver を使って結合する．基本は XML ベースで結合処理を行う様子．Meta-Weaver Framework からDomain-Specific な Weaver のインスタンスを生成するとか言っている．

_ 論文 ▲

Gary T. Leavens and Yoonsik CheonDesign by Contract with JML

論文というよりは JML の紹介原稿というべきか．

JML の良い点:invariants にも可視性がある． "public" 宣言しない限り，同一パッケージのクラスからしかその invariants は見えない．

representation invariants はクラスの外からは見えない．type invariants は見える．

ensures, signals で通常の終了，例外的終了を分けて書ける．

forall, sum, max, min といった述語が使える．

継承した場合は Liskov の置換原則を保持する．

モデル・フィールドを宣言することができ，実変数を対応付けることができる．同様に，モデルメソッド・モデルクラスを宣言することもできる．

_ ▲ JML の注意点:副作用を持たないメソッドについては不変条件の記述に使うことができるが，メソッドが副作用を持つかどうかを"pure" と自前で宣言しなくてはならない．（書けるだけマシなのだが）

_ 論文 ▲

aosd-discuss で，読んでみてくれーと流れていた論文．

Claudio Sant'Anna, Alessandro Garcia, Christina Chavez,Carlos Lucena, Arndt von Staa:On the Reuse and Maintenance of Aspect-Oriented Software:An Assessment Framework

アスペクト指向ソフトウェア用のメトリクスを提案している論文．

Separation of Concerns Metrics としてどのくらいのコンポーネントがひとつの concern に参加しているか，とかを数え上げている．また，結合度，凝集度，サイズを使っている．オブジェクト指向で書かれたソフトウェアでも同じものは測れるので，それを比較する形になっている．

品質モデルは Basili の GQM パラダイムがベース．実験では，OOとAOで同じシステムを設計して，メトリクス値を測る．システムにいくつかの変更を加えて，それに必要だった変更がどの程度か（いくつ Entity が変更されたか，など）というのをメトリクス値が示している性質と一貫した答えになっているかどうか，評価している様子．

_ 論文 ▲

Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and Obliviousnessの続き．

実装上の問題として，スコープをどうするとか，本当に Obliviousness は達成できるのかとか，関連しあったアスペクト間の扱いをどうするのかとか，一貫性の問題は，とかが列挙されている．

アスペクト指向言語とは何なのか，ということも整理されている．・ルールベースのシステムとしてとらえる． しかし，対象プログラムがすべてルールベースだと AOP の議論はできない．・イベントベースの Publish/Subscribe モデルとしてとらえる． コンポーネント間がイベントで動作するモデルなら， Black-Box AOP として考えられる． プログラマが手動でイベントを生成しなければならないのなら， それは oblivious ではないので AOP ではない．・Intentional Programming / Meta-programming としてとらえる． それ自体を AOP というよりは，AOP の実現手段．・Generative Programming としてとらえる． これも AOP の実現手段． まとめ：・AOP の持つ，oblivious quantification というのは OOP とは独立の概念．・一箇所にしか登場しないものはアスペクトにしないほうがよい・より良い AOP システムは，より oblivious である．

_ 論文 ▲

Robert E. Filman, Daniel P. Friedman:Aspect-Oriented Programming is Quantification and ObliviousnessOOPSLA 2000 の論文らしい．

OOP までの概念では，特定のルール，たとえば「オブジェクトを移動させたらディスプレイをアップデートすること」といったルールをで実装するには，「クラスを継承したプログラマは super.foo をメソッドの終わりで呼ぶこと」といったプログラマが協調するためのルールを作る必要があった．

このようなルールが必要ないようにするのが "oblivious" で関連した文を選び出すことが "quantification" ということになる．

AOP でやりたいことは，In programs P, whenever condition C arises, perform action A.という条件ドリブンなプログラミングである．

Static Quantification はプログラムの構造上の情報で条件を定めるもの．特定のコンポーネントへのアクセスや特定のサブルーチン呼び出しをラップしたりする．アスペクトがどこまでベースプログラムの情報を使うかでBlack-Box AOP と Clear-Box AOP と分類している．Clear box はベースプログラムの中身を見るのでソースコード情報が必要だが，デバッグなどには適するし，しかし実装するのは難しい．Black-Box はインタフェースなどを基準に操作するので実装などは簡単だが使える範囲は限られてくる．

また，Dynamic Quantification としては，コールスタックのサイズであるとか，例外の発生や特定の実行パターンがある．

_ クレジット ▲

426USD の謎の請求．IWPSE は EUR で払ったはずだし……？でもどこかで見覚えがある，とひたすら研究室に置いた請求書やらの山を調べていたら，その正体は IWPSE の Reprint Order だった．うーむ．請求団体名の後ろに一言くらい添えられるような空間を用意しておいてほしい……．

_ Ruby ▲

サーバーの Ruby が 1.8 になったとたん，コンパイラの微妙な変化でエラーで落ちるようになってしまっていた．とりあえず式展開中のダブルクォートが怒られるようになったことが原因のようなのでそれだけ直した．