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 が使えるらしく，（おそらくは）論文を引用してなかったので突っ込まれていた．
どんな環境だと，使う効果が大きいのか？がこの手の分散環境のプロジェクトには参加したことがないので良く分からない．言語系だと，モジュールの複雑さが落ちましたとか，行数が減りましたとか，そういうところで評価するのだろうか？
