netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-10-01 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
GPCE2003 その２．
Mariano Cilia, Michael Haupt, Mira Mezini, Alejandro Buchmann:The Convergence of AOP and Active Databases:Towards Reactive Middleware
active database における Event-Condition-Action （特定のイベントに対して条件をテストし，対応するアクションを取るようなデータベース）は AOP に類似しているメカニズムである．しかし，双方で使っている Terminology はまったく異なっている．
対象プログラムを書き換える(invasiveness)度合いについて，active database は non-invasive，AOP は invasive (AspectJ), non-invasive (初期のPROSE, JPDA), Aspect-aware runtime environment (AspectS)，などと分類している．
この作者たちは，Active Database と AOP の間のミドルウェアとして Aspect-Oriented Run-Time Architecture というのを作りたいらしい．それ自体はともかく，色々な AOP と Active Database がまとめられているので参考文献として良いかも．active database 知らない人も多いだろうから，個人的には貢献度は高いと思う．
_ 論文 ▲
GPCE 2003 の論文読み．といっても，Proceedings が LNCS で PDF が取れなかったので筆者が PDF を配ってた二本だけ読む．
Jeff Gray, Ted Bapty, Sandeep Neema, Douglas C. Schmidt, Aniruddha Gokhale, Balachandran Natarajan:"An Approach for Supporting Aspect-Oriented Domain Modeling"2nd International Conference on Generative Programming and Component Engineering (GPCE2003),
モデル＋制約言語から，制約付きモデルを導出する．Join Point としてモデル内のノード，Pointcut Designator として宣言的記述（モデル内の位置を指定する），アドバイスとして「concern に関わっているよー」という strategy あるいは heuristic の情報が埋め込まれる．コードジェネレータと組み合わせて（C++限定だが）Strategy に対応したコードを生成する．
モデル自体は general で，domain-specific な weaver を使うというアイディアらしい．weaver 作る手間が高そうだ．
_ 論文 ▲
Pascal Costanza:Dynamically Scoped Functions as the Essence of AOPについての議論が続いてる．
AspectJ の pointcut の考え方では，cflow を使って「呼び出しの上のほう」と「下のほう」のそれぞれ独立に定義されたイベント間を接続できるが，dynamically scoped な考え方では「"real" cflow ではなく "predicted" cflow を対象にしている」という主張が出ている．
……まだ議論は続きそう．Kiczales が Non-Invasiveness (Obliviousness) は重要だ，というのを繰り返してるところを見ると，そこが AspectJ の設計時のキーだったらしい．
2003-10-02 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
AspectJ 1.2 に向けてどうしよう，という話が進んでいる様子．スケーラビリティ，パフォーマンス問題，再利用可能なアスペクトを書くための方法，なんかが重視されてるみたい．
「ほしい機能リスト」には，"静的に実行可能なアドバイス" とかも入ってた．どうなることやら．
2003-10-03 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Hidehiko Masuhara and Kazunori Kawauchi:Dataflow Pointcut in Aspect-Oriented Programming,In Proceedings of The First Asian Symposium on Programming Languages and Systems (APLAS'03), November 2003, to appearを読む．dflow pointcut は，どの変数を経由してきたかを示すように変数に "タグ付け" して後でそのタグがあるかどうかをチェックする，という形で書かれていた．「C.foo の戻り値由来の値が D.bar に届いたとき」なんてのが書けるようになる．これは，cflow では表現できない世界なので今まで HashMap とかを使って自前で実装していた部分が不要になって便利そう．ただ，言語仕様としても，実装方法としても，利用方法にも，まだまだ研究の余地は多分にありそう．
ライブラリなど，外部でのデータやり取りを抽象化する declare propagate は便利だなーと思う．解析系の人々の作業も多少は楽になるし．（たとえば，ある関数の戻り値がある関数の引数に 依存していることを明示できる）ライブラリとかを書く人は手間が増えて大変だけど，データフロー解析して propagate の宣言を自動生成とかすれば解決できそう．ステートフルな外部オブジェクトの扱いが難しそうではある．
とりあえず refer する予定リストに追加．
2003-10-04 古い日記からの変換データ [長年日記] ▲
_ IEEE ▲
IEEE Computer Society の値段を調べてたら，$160 (IPSJ会員なら1割引で $144) だった．Digital Library 利用したければさらに $109 と，なかなか微妙．ACM は論文などが portal.acm.org で無料で取れるので取るなら IEEE アカウントのような気もするのだが．とりあえず，学生の間はあまり取る必要もなさそうなので見送ることにする．
2003-10-06 古い日記からの変換データ [長年日記] ▲
_ EJB ▲
コンポーネントの precondition や postcondition のことを考えながら EJB のことを調べていたのだが，EJB では synchronized キーワードやスレッド生成を禁止してコンテナが全部管理するということになっているらしい．同時性制御に関しては，セッション Bean ，エンティティ Bean はデフォルトではリエントラントではない（あるトランザクションコンテキスト内部で マルチスレッドなアクセスをしてくる可能性と 区別できないため）．そのため，コンポーネント間のループバックは禁止されている．ループバック禁止がプログラムに与える制約はどの程度だろう？
メッセージ駆動型 Bean は，複数インスタンスを生成することで複数メッセージを同時に並行して処理するらしい．
2003-10-08 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
The Concept of Dynamic AnalysisESEC/FSE 99, Thomas Ball
頻繁に動作している部分とそうでない部分を明示することでプログラムの分解に役立てる Frequency Spectrum Analysis とテストケースごとにどのあたりが実行されるかを見ることでカバレッジ向上を行う Coverage Concept Analysis を提案している論文．
Introduction での静的解析と動的解析の比較を行っていて，静的解析はプログラムが特定の性質を持つかどうかを判定できるが，動的解析は特定の性質の違反を検出することができる．動的解析は「入力に注目した解析」で静的解析は「プログラムに注目した解析」だとしている．また，これらは，完全性，スコープ，正確性の違いだとしている．
完全性において，動的解析はプログラムを十分な回数を実行する必要があり，静的解析ではありえない実行系列などを排除する必要がある．
スコープについて，静的解析はプログラム中の位置による制約を受けやすい．特に遠距離（異なるモジュール，時間的距離）の依存関係を解析するのは非効率的である場合もある．
正確性については，静的解析は解析を終わらせるために情報の抽象化（ある種の情報損失）が必要となる．動的解析では，プログラム実行のうち必要なドメインにのみ注目することでコストを削減することが容易である．
_ 論文 ▲
久々にプログラムスライス関係の論文を読む．
Paolo Tonella:Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis,IEEE Transactions on Software Engineering, Vol.29, No.6, pp.495-509, June (2003)
ある変数に対する計算処理を Decomposition Slice と呼ぶが，Decomposition Slice Graph ではなく Lattice として構造化し複数の変数で共通した計算部分をくくりだす．
影響波及解析自体は，Lattice を使ってチェックされる．ただの Forward Slice と違い，影響を受ける文だけでなく，何の計算に影響を与えるかを示せる点らしい．ちょっと怪しい気もするが．文を「計算」という単位にグループ化できることがLattice の強みらしい．
共有されている部分が Decomposition Slice でない場合（たまたま同一の制御構造などを共有している場合）を，弱い干渉 (Weak Interference) と定義して実験している点が興味深いと言えなくはない．
静的解析で，どこまで正確に解析できるかとか，その解析コストがどの程度か，とかいうあたりの議論がないような気はするが，それにしても，Concept Lattice をちゃんと使っている論文は珍しい．
2003-10-09 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Stephan Herrmann:Object Teams: Improving Modularityfor Crosscutting CollaborationsNet.Object Days 2002
を読んだ．Object Team というモジュール単位を導入している．Aspectual Collaboration に近い概念(?)で，Team class 側は「こんな参加者がいるよー」と宣言して，個々のクラス側は「私は Subscriber 役をやります，メソッド xxx は私のこのメソッドに delegate してね」と宣言する．依存関係が AOP の場合と逆．
で，クラス側が「この Team を active にしてブロックを実行」というようにコントロールできるみたいではある．登場人物となるオブジェクトが全員揃った状態でオブジェクト間の関係を明示しながらプログラムを書くことになりそうなので，1:n あるいは m:n のオブジェクト対応をどう扱うのか，とかちょっと気になる．
個人的には，アスペクトと併用してTeam オブジェクト記述→ Team に参加するオブジェクト記述→ オブジェクト間のルールをアスペクトで記述なんてやってみたい．
アプローチ自体は嫌いじゃないのだけど，プログラム言語を作ったことで，どのくらい複雑さが低減できるのか，とか抽象度が高い記述が可能なのか，とか色々議論する余地は多そう．
すべての振る舞いを Object Team で書いたらどうなるか，っていうのを見てみたいところ．
_ 論文 ▲
以前読んだ論文の読み直し．Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programming
Object Oriented Design Language (OODL) という形式記述言語とその検証系を説明した論文．オブジェクトがやり取りするメッセージやそれに伴う状態遷移を記述して，オブジェクト間の依存関係の循環や，結合度，client/server 関係といったものを調べる．しかし，ソースコードとの対応関係の確認はできない．
2003-10-15 古い日記からの変換データ [長年日記] ▲
_ Neverbird ▲
JBoss を広めようとしている Neverbird の人からもAOP のキーワードでリンクされていたことに気付いた．developerWorks や OO シンポに関する記事と同列．でも「その他」かぁ．
Neverbird の人々，かなり情報収集量が多い．参考にさせてもらいつつ，もうちょっと頑張ろう．http://neverbird.sourceforge.jp/
_ カレンダー ▲
スケジューラというほうが正しいのかなぁ．ある程度，形になってきたのでいちおう公開してみる．hyCalendar 公開ページ
_ Delphi ▲
Delphi から Windows API を叩くための資料を探していて，サイトを発見．ソースコードを積極的に掲載しているので，すぐ使える断片が手に入って嬉しい．http://halbow.cool.ne.jp/top.html
2003-10-17 古い日記からの変換データ [長年日記] ▲
2003-10-20 古い日記からの変換データ [長年日記] ▲
_ Calendar ▲
hyCalendar (仮) 0.3.0 公開してみる．ようやくクリップボードに対応．hyCalendar 公開ページ
2003-10-21 古い日記からの変換データ [長年日記] ▲
_ アクセス ▲
アクセス解析の結果から，至近 1000 件のアクセスのうち約１割の 99件 が *.fit.ac.jp から．趙先生が一人で叩いてるとは思えないので，誰か学生とかで興味持ってる人がいるんだろうか……．
_ AOSD ▲
"Dynamically Scoped Function" を書いたPascal Costanza が aosd-discuss に投稿していて，Join points という名前はないがプログラムを変換するフレームワークはすでにあったから，Join points というのが AOP の貢献というわけではない．
構文木上のある範囲を超えて作用することができる（Lexical Scope ならマクロがあるが， 副作用などの問題もある上に Lexical Scope は超えられない）ところこそが AOP の良いところなのではないだろうか，と言っていた．
プログラム実行中のイベント（Join points）をFirst class に持ってきたところ，も貢献であるような気はするけど，どうなんだろう．
2003-10-23 古い日記からの変換データ [長年日記] ▲
2003-10-24 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Kasper B. Graversen and Kasper {\O}sterbye:Implementation of a Role Language for Object-Specific Dynamic Separation of Concerns,AOSD '03 Workshop ``SPLAT''を読んだ．
"Role" を動的にオブジェクトに貼り付けてメソッド定義などを置き換えるDelegation Layer, JAC 系のアプローチ．Role 間は，継承関係がない場合は完全に独立．貼り付けられた複数の Role は相互に影響を与えない．super や self 同様，貼り付けられた対象を示すintrinsic という参照を使うらしい．
たまたま継承オブジェクトと貼り付けられたロールが同じ名前のメソッドを追加していたら名前の上書きが起こるみたいだけど，そのあたりはあまり本質的ではないので置いておくとして，どのロールとして参照されているかによってオブジェクトの振る舞いが変わることになる．この点はとても面白い．そのかわり，オブジェクトを管理する側は大変そう．
この論文の筆者らは，このChameleon モデルについて他にも論文を書いている様子．
_ 論文 ▲
オブジェクト間の制約とかを書いたり解決できたりするのかなーとちょっと期待して Constraint Programming 関係の文献をあさってみたが，結局，Object-Oriented Constraint Programming とか言ってる人が少し関連していることをしているように見えるけれど実は整理される対象がオブジェクトなだけ？で制約を一般的なプログラム上で使うのはしんどそう．
せっかく読んだので論文名だけメモ．Samir Ouis, Narendra Jussien and Patrice Boizumault:k-relevant explanations for constraint programming
_ 論文 ▲
R\acute{e}mi Douence and Narendra Jussien:Non-intrusive constraint solver enhancements
単純な Constraint Solver ＋アスペクトで拡張していこうというショートペーパー．バックトラックなどをアスペクトとして実装することで拡張性なんかを確保できる……のかな？
_ 論文 ▲
オブジェクト制約言語に関して色々調べてみる．
中島 震:制約伝播機構を内蔵するオブジェクト指向言語: COOL. 情報処理学会論文誌 Vol.30, No.1, January (1989).
オブジェクトの状態が変化したら命題を評価してその命題に依存した他の命題を評価して，……というようにたとえば回路の入力ピンの値が１箇所変化したら順番にそれを伝播させていく，というような制約記述を Lisp ベースで導入している．矛盾解消機構を持っていて，命題の出力が処理キューに並んでいる命題値と矛盾した場合に勝手にその基となった命題を削除して解消したりするみたい．勝手に制約が置き換えられていくことになるので本当に動くのかなぁ，と不思議．
Hon Wai Chun:A Methodology for Object-Oriented Constraint ProgrammingAPSEC 97, P.116ILOG を使って分析を行い，UML のクラス図などの上で制約を記述し，ILOG 記述に落としていくという話．
C++ プログラム上でどう使っていくか，みたいな話っぽいのだが，オブジェクト間の制約が，必要なオブジェクトが一式揃う前から適用されてしまうような気がするのだけど初期化タイミングなんかではどう扱うんだろう．コンストラクタがすごく頑張るんだろうか……．
_ 論文 ▲
OOPSLA 2003 間近ということで ML に流れてきた論文．Jim Hugunin: The Next Steps For Aspect-Oriented Programming Languages(in Java)
今後の研究の方向性について述べた Position Paper．
(1) 適切な分割コンパイル，静的なチェック(declare errorなど)とロード時 weave との扱いなどに関する問題
(2) Pointcut の表現範囲 -- たとえば dataflow の拡張
(3) 特定ドメインに対応したアスペクト，再利用可能なアスペクトライブラリの構築
(4) 拡張可能なコンパイラなど，様々な開発ツールといったところ．
確かに，そのくらいの方向性だという気はする．(1) と (4), (2) と (3) は相互に絡んでいくんだろうか……．
2003-10-26 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Curtis Clifton and Gary T. Leavens:Obliviousness, Modular Reasoning, andthe Behavioral Subtyping Analogy
これも出典はSPLAT2003．アスペクトが勝手にクラスを置き換えてBehavioral Subtyping を破壊することがあり，しかもクラスはこれに気づくことがない．（これはAspectJ の obliviousness であるという特徴）
しかし，実際には，それではプログラマは「１モジュールずつ理解する」ということができないので，このような Behavioral Subtyping を破壊するようなアスペクトについては "Assistants" と呼んで別扱いし，（破壊しないものは "Spectators" と呼ぶ）Assistants については明示的に取り扱いません？という論文．これ，出典は忘れたが前に同じ著者がどこかで出していた論文(or テクニカルレポート)と内容的には同じ．今後は Assistants を接続するような言語を作ったりしようか，とか言っている．
参考文献としてFilman and Friedman, Aspect-oriented programming is quantification and obliviousness (OOPSLA2000) を挙げている．http://ic.arc.nasa.gov/~filman/text/oif/aop-is.pdf
_ 論文 ▲
SPLAT2003 Workshop の論文を読む．Therapon Skotiniotis, Karl Lieberherr, David H. Lorenz:Aspect Instances and their Interactions
6ページ弱のショートペーパー．アスペクトを記述するときに，「あるクラスのインスタンスのみ」を指定しようとすると!call((Circle+ && !Circle).*) && call(Circle.*) といった記述になる．また，if(thisJoinPoint.getTarget().getName() == ...)といった式や aspectOf をうまく使おう，というテクニック紹介みたいな論文．
アスペクトのインスタンスを生成したり特定のオブジェクトに install したりするAspectS の設計は良さげだと思える，らしい．Dynamic Aspect なほうが柔軟なアスペクトの管理ができていいなぁ，ということなのかな？
2003-10-27 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
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 としては，コールスタックのサイズであるとか，例外の発生や特定の実行パターンがある．
2003-10-30 古い日記からの変換データ [長年日記] ▲
_ MERP ▲
Web に公開していた情報をたぐって，Mr. Duckworth という人からメールをもらった．「MERP を日本でも遊んでる人がいるのね．もしよかったら東京近辺で遊ぶような人いないっすか」という感じ．で「とりあえず，そういう知り合いがいそうな人に転送しといたよ」と返事をしたら，「ありがとう．機会があれば色々話をしてみたい」とか返事が返ってきた．うーむ．
