netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-04-02 古い日記からの変換データ [長年日記] ▲
_ AOSD ▲
AOSD 2004 Technical Papers: Tools and Implementation
Shigeru Chiba, Kiyoshi Nakagawa:Josh: An Open AspectJ-like Language.
開発者が，新しい pointcut を追加できるような，言語の見た目は AspectJ によく似た言語処理系．メタプログラミングなので，この手の言語処理系を開発・テストする環境としてはおそらく最強のアプローチを取っているといえる．一杉さんの EPP に似ている気もする．
Josh が "助手" なのはかなりびっくりしたけど．
_ AOSD ▲
AOSD 2004 Technical Papers: Tools and Implementation
Christoph Bockisch, Michael Haupt, Mira Mezini, Klaus Ostermann:Virtual Machine Support for Dynamic Join Points.
今回，あまり興味がなかったので見送り．
_ AOSD ▲
Ran Ettinger, Mathieu Verbaere:Untangling: Refactoring extract aspects using program slicing.
単に，interleaved (織り交ざったコード) をスライスで分離しました，という程度の話．ぜんぜんモジュール間を横断してないので意味がない，と思う．これなら，学生ポスターセッションに出ていた，コードクローンからアスペクト探しましょうという話のほうがよっぽどえらいような気がする．（実際にはコードクローンだけでは難しくてスライスと組み合わせることになるのだろうが）
Nate というスライスツールがあるらしい．
スライスをメソッド抽出するときは，状態変数として使われているローカル変数の扱いが問題．Local -> Field 昇格をするとrecursive call などの場合に問題が起きる
スライスが大きくなる場合の問題については，何らかの半自動化された negotiation を行って量を減らそうと試みることが必要であろうと考えている
スライシングの見せ方として，diff ツールみたいに「削除されてるよー」ということが分かるように，スライス前・後を比較表示する点は面白い．しかし，大規模な(1000行以上の)スライスだと，そういうレベルの見せ方が通じない気がする．
プログラムスライスは，Fluid AOP の，実態コードは元のままで，見た目だけ AOP っぽくするという考え方に近い気がする．
_ AOSD ▲
AOSD 2004 Technical Papers: Applications I Steffen Gobel, Christoph Pohl, Simone Roettger and Stefen Zschaler: The COMQUAD Component Model - Enabling Dynamic Selection of Implementationsby Weaving Non-functional Aspects コンポーネントを，次のように考える．Component Specification と Component Interface は 1:n 対応．Component Specification と Component Implementation も 1:n 対応． Component Implementation は，Installed Component と 1:n 対応．Installed Component は，Component Object と 1:n 対応． Component specification に対して，複数の実装があるが，それぞれの実装が，どのような条件で動作するように作られているかプロファイル { provides, uses, resources } が存在してくる．そして，どの spec, implementation, profile を使うか，コンポーネントの接続をどうするかを XML で記述する． そして，この profile を使うことで QoS 実現を行う．たとえば，帯域の制御であれば，次のように provides と uses を作る．
quality fast_network { threshold bandwidth > 1 000 000; }
profile videoBinding for video_component {
provides high_quality_video;
uses fast_network;
}
これらを接続していくことで，目標の QoS に到達する，ということになるらしい．
_ AOSD ▲
AOSD 2004 Technical Papers: Applications I Gary Duzen, Joseph Lyall, Richard Schantz, Richard Shapiro and John Zinky: Building Adaptive Distributed Applications with Middleware and Aspects. CORBA などの分散環境でのアスペクト指向開発な話．アドバイスの記述は code の位置や実行ではなくシステムと環境の「状態」に対して行ったらしい． Contract 記述とかをアスペクトとしてきちっとやっている例かもしれない．面白いと思ったのが，登場する region という単位．ひとつの region は，システムがとりうる状態の範囲を示している．使える状態変数をどうするのか，といった点は難しそうではあるが，「……をしている間は，ｘｘの条件が成り立っている」といった関係を，region をネストさせながら記述できるようにしたらしい．
contract 表明の名前 {
region Normal ( 成立している条件 ) {}
region NetworkLoad (条件) {
region Compress (条件) {}
:
}
}
_ AOSD ▲
AOSD 2004 Technical Papers: Applications I
Adrian Colyer and Andrew Clement: Large Scale AOSD for Middleware.
AspectJ での開発に関する経験論文．EJB support concern (Java クラスを EJB として動かすためのアスペクト) を分離してみたら，けっこううまくいったらしい．これが一番面白いところか．また，AspectJ が，コードを貼り付けて振る舞いを変更できることから，リファクタリングなどに対して効果的であるらしい．また，コンパイル速度の問題なども解決されつつあるが，declare error を使ったコードスタイル検査などは，いわゆる専用のエンジンではないので時間コストは高いらしい．
_ AOSD Keynote ▲
Keynote 2: Crosscutting Requirements
Prof. Bashar Nuseibeh,Professor of Computing at The Open University (英国 放送大学)
ワークショップ以外では数少ない "Early Aspects" の話．Concern は，利害関係者が興味を持っている属性のこと，としている．
たとえば，エレベータを構築する場合には，ユーザからは「多く載れるかどうか」という観点から，モータ設計者からは「荷重耐性をどうするか」という観点から積載重量に関心を持っている．
"View Point" を何らかの形で（たとえば状態機械などで）定義し，それらの View Point 間の接続を満たすように複数の View Point を Overlap している要素を調整していくのが要求分析である，と考えているよう．
要求工学は各利害保有者の目標や要求，期待を見つけて，調整し，開発者とのコミュニケーションを行う，ということが目的である，といっていた．Requirements Engineering については，Nuseibeh, Easterbrook: Requirements Engineering: A Roadmap.Proceedings of ICSE2000. を参考に挙げていた．
_ AOSD ▲
AOSD 2004 Technical Papers: Weaving
Stefan Hanenberg, Robert Hirschfeld and Rainer Unland:Morphing Aspects: Incomplete Woven Aspects and Continuous Weaving.
アスペクトの結合を実行時に少しずつやっていこうという論文(?)．いわゆる lazy evaluation ．dynamic pointcut ばかり使うアプリケーションには有効とか言っていた気はするが，そんなアプリケーションがどのくらいあるのか，という点は不明．（このあたりは，新しい言語要素を導入する場合に重要な気はするのだが）
スレッドごとに cflow が違う場合などに，実行を最適化してしまうとまずくないか，また，いつ morphing するのかが問題ではないか，といった指摘が出ていた．
_ AOSD ▲
AOSD 2004 Technical Papers: Weaving
Jeff Gray and Suman Roychoudhury:A Technique for Constructing Weavers Using a Program Transformation Engine.
パターン（正規表現マッチの置換など）ベースの advice weaving 機構の話．スライドで説明された限りでは，項書き換えのような形でプログラム書き換え( weaving )が進んでいく．syntax tree をどこまで作るかがけっこう微妙な気はするが，Delphi など，weaver が存在しない言語でもそれなりに頑張れるよ，という実例として，とても面白い．
_ AOSD ▲
AOSD 2004 Technical Papers: Weaving
Erik Hilsdale, Jim Hugunin:Advice Weaving in AspectJ.
AspectJ における Weaving 技術の実装について説明した論文．static shadow (join point がマッチしうる地点) とdynamic residue (static shadow において，join point がマッチする条件) という用語を使うときにはこの論文を引用することになりそう．
exec(..) && if(..) のほうがアドバイス本体で if を使うよりも inline 化されて高速，とか実装の都合によるところはけっこうあるらしいが，効率のよいコードを書くためのガイドラインのようなものは存在しないらしい．
_ AOSD ▲
AOSD 2004 Technical Papers: Languages I
Kouhei Sakurai, Hidehiko Masuhara, Naoyasu Ubayashi,Saeko Matsuura and Seiichi Komiya:Association Aspects.
オブジェクト間の関連をアスペクトとして記述することを提案した論文．EoS (Rajan & Sullivan) に似ているらしい．
現在の AspectJ では，ひとつの join point に対してひとつの advice が実行されるが，インスタンスごとにアスペクトを追加すると，ひとつの join point に対して複数の advice が実行されることがあってなんかモデルがだいぶ変わっているのでは，という指摘があった．また，マルチスレッド上での振舞い（ロック機構など）についても質問が出ていたが，今のところ特に何かを考えているようではないらしい．
個人的には，E-R モデルとの親和性とかがあって，開発者に（たぶん）理解しやすい点がうれしいように思える．ただ，こうなってくると，アーキテクチャ記述言語とかコンポーネントの接続を管理しましょう，と研究しているタイプの人との違いの主張がむしろ重要なのかもしれない．
今後どうなるのか楽しみな研究．
_ AOSD ▲
AOSD 2004 Technical Papers: Languages I
Muga Nishizawa, Shigeru Chiba and Michiaki Tatsubori:Remote Pointcut - A Language Construct for Distributed AOP.
どのホストで動作しているか，といった条件を記述するremote pointcut を導入してみました，という論文．また，ホスト間をまたがって cflow が有効らしい．
JAC でも remote pointcut が使えるらしく，（おそらくは）論文を引用してなかったので突っ込まれていた．
どんな環境だと，使う効果が大きいのか？がこの手の分散環境のプロジェクトには参加したことがないので良く分からない．言語系だと，モジュールの複雑さが落ちましたとか，行数が減りましたとか，そういうところで評価するのだろうか？
2004-04-01 古い日記からの変換データ [長年日記] ▲
_ AOSD Keynote ▲
Keynote 1:Aspects - From Promise to RealityDr Daniel Sabbah, Vice President, IBM Development and SWG Technology,Application Integration and Middleware Division,Software Group
AOSD を IBM では使ってます，という keynote．AspectJ の使い方としては，private な（バージョン依存の）API 呼び出しを禁止するといった渋い方法も．アスペクト干渉など，一部では問題が山積みのような気もするのだが，使い方次第，ということだろうか．実際の開発では，干渉っていうのはあんまり起きないのか，それとも干渉が起きないようにうまく書いているのか．
Java クラスを EJB コンポーネントとして動かすなんてこともやっているらしいので，たいしたもの．
ソフトウェア工学をきちんと教えるような体制が重要だよ，というところは主張していた．
質疑応答では，ドキュメントはどうしてますか，とかIBM は資源がいっぱいあるからいいけど，資源がない人はどこから始めるのでしょう，といったものが出ていた．これだ，という解決方法はどうも今のところないみたいだが．オブジェクト指向でもドキュメントなどが固まったのはだいぶ後になってからなので，アスペクト指向もそうなのかもしれない．
_ AOSD Tutorial ▲
Tutorial T5: Good AOP: Idioms, Rules and Patterns in AspectJWes Isberg, Adrian Colyer によるチュートリアル．
アスペクトは Role-based design に親和性が高く，デザインパターンには Role-base なものが多いらしい．
基本的には，「同時に変更されるようなコードは１つのモジュールに」というデザインが良いらしい．また，モジュールを abstract/concrete に分類したとき，concrete -> abstract という依存関係は OK だが，逆はよくない，という基準で作れ，とも言っていた．このあたり，わりと一般的ではある．
_ AOSD Tutorial ▲
Aspect の使い方として，・元の振る舞いを変えない検査など（Invariants の追加）・制約の付加（古いコードとの整合性チェックなど）・新しい join point 指定 (「JUnit テストの assert 前後」など）を挙げていた．
面白い idiom としては，次のようなものがあった．
"_" で始まるフィールド以外を禁止するdeclare error: set(* *) && !set(* _*)
あるインタフェースを implement しているすべてのクラスを検知する（implements している == クラス初期化コードが動くので検知できる）pointcut anyRunnableImplementation(): staticinitialization(IRunnable);
delegation を行うための this 差し替えpointcut delegationScope(D d): this(d);around(D d): delegationScope(d) { proceed(expr ? delegate : d);}
_ AOSD Tutorial ▲
注意点として挙げられていたのは，Abstract Aspect を使うとき．
抽象アスペクトに定義された pointcut を，複数の継承したアスペクトでオーバーライドした場合，それらの pointcut を p1 と p2 とすると，p1 && p2 であるような join point ではadvice が２回実行されるので注意が必要．declare error: p1 && p2; のようにしてエラーを出させる方法もあるが，これは p1 と p2 が両方とも static でないといけない．
また，やはり，join point が変化したら pointcut も変わる，というところだけは注意が必要らしい．何か依存関係解析でも必要だろうか．
_ SPLAT2004 ▲
SPLAT2004 のまとめ．
Comprehensibility セッションでは，
Karl Lieberrharl は，Demeter ツールを使ってオブジェクトを traverse するコードを書き直したら，どのくらい短くなって，理解性が上がったか，という話をしていた．
Abstractness = 書き直し前コードの長さ / 書き直し後のコードの長さという考え方は単純だけど．
また，Role モデルが好きっぽい人が，アスペクトの依存関係の管理することが大事だ，というように発言していた．しかし，依存関係を explicit にすると non-invasive adaptation がなくなってしまう，ということで対立していた．今のところ non-invasiveness のほうが大事で，explicit にするのは統合開発環境の役目じゃないか，というような考え方ではあるらしいが．
また，pointcut は構文的なものと論理的なものとでは差異があるため，semantic な join point という考え方がもっと必要そうだ，という意見には，みんな賛同していたが，今のところこれだ，というものはない様子．来年くらいにはいっぱい出てきそう．
しかし，「汎用的な（どんな場面でも動く）コードは複雑」という考え方と，「抽象的なコードのほうが理解しやすいのではないか」というすごく微妙な対立が起こっていたりした．
_ SPLAT2004 ▲
Predictability セッションでは，アスペクトを使って表明を書きましょう，という話と，アスペクトを使ってデータ暗号化アスペクトを書いてみました，という話の二軸．
表明を複数に分離する（コンポーネント側に「本来の制約」を書いて，アプリケーション側に「アプリケーション依存の制約」を書く）という考えに，Erik Ernst が食いついてきた．
表明の持つ副作用の問題について，データ暗号化のアスペクトを書いた人が，副作用の問題は非常に大きくて，アスペクトが気づかないうちにデータを壊したりする可能性を何とかして防げたらうれしい，というふうに発言していた．しかし，副作用を防ぐという意味では C++ の const などがあるが，「本当の」const はデータフロー解析などを使えばある程度できるがdata flow pointcut などは難しいのではないか，とも言っていた．JAC (Java Access Control?) という論文が ECOOP に出ているらしい．
しかし，実用的には，Java 1.5 で導入された readonly 属性付加などを使えばそれに近いことができるのではないか，ということを言っていたので，実践してみる価値は大きそう．表明に違反したときどうするか，は考えないといけないようだが．
ただ，みんな Predictability と Comprehensibility について明確な区別を持っているわけではないらしい．Predictability は「あるコード片の動作を予測できるか」という感じで何となく思っていて，Comprehensibility は「全体的に依存関係などを把握できるか」というくらい，らしい．Predictability は f(A) + f(B) と f(A+B) がどう違うか，といった問題のようでもある，とも言っていた，
_ SPLAT2004 ▲
Evolvability については，Erik Ernst が，アプリケーションの修正単位（アスペクト）が「相互に干渉しないべきだ」という立場を取っていた．pluggability というのを重視して，「あってもなくても動く」ような状態をうまく作ることで，システムの信頼性などを上げようとしている．
でも，「そんなので本当に必要なものが作れるのか」みたいにけっこう対立していた．どうも，「こう書けるとうれしい」派と「こう制限すると保守性が上がってうれしい」派に別れているような印象．
ベースプログラムを変更すると join point が変わるのでpointcut 側も変更しなきゃいけない，というのが嫌なので何か semantic な情報があればいいのだが，というような話もあった．下手に，「AのあとのBの呼び出し」といった言葉を作ると，ドメインに対応する言葉がないので困る，というような発言もあった．特定のイベントに名前をつける，といったイベントモデルなどが似ているといえば似ているか．
_ SPLAT2004 ▲
Semantic Interaction については，Aldrich という人が，external/internal 呼び出しを区別したり，モジュール境界をきちんと考えましょう，と発言していた．ただ，モジュール境界による区別をしてはいけない場合もあるよ，と反論も出ていた．その場合はモジュール境界をちゃんと引き直せばいいだけのような気もするのだが……．
アスペクトやクラスをグループ化して，何らかの制約を付加する，というのはやはり他の人も考えていたらしい．振る舞いを「変更していい」「値にアクセスしていい」といった情報をモジュール側に記述してアスペクトが「不用意に」値を変更したりしないように，という考え方も提案されていたが，簡単には解決しなさそう．「どこでモジュールを切りますか？」というのが出てこないので議論がうまくいってないような気がする．
ワークショップ全体の総括としては，
・Core Logic (class) と Aspect が明確に結びつきすぎるのはよくない
・何らかの情報隠蔽がほしい
・高水準言語を目指すべき？
・core と aspect の双方に表明を付加して，結果を予測可能とすることが有効？
といった形で締めくくられた．
