netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-10-04 古い日記からの変換データ [長年日記] ▲
_ IEEE ▲
IEEE Computer Society の値段を調べてたら，$160 (IPSJ会員なら1割引で $144) だった．Digital Library 利用したければさらに $109 と，なかなか微妙．ACM は論文などが portal.acm.org で無料で取れるので取るなら IEEE アカウントのような気もするのだが．とりあえず，学生の間はあまり取る必要もなさそうなので見送ることにする．
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-02 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
AspectJ 1.2 に向けてどうしよう，という話が進んでいる様子．スケーラビリティ，パフォーマンス問題，再利用可能なアスペクトを書くための方法，なんかが重視されてるみたい．
「ほしい機能リスト」には，"静的に実行可能なアドバイス" とかも入ってた．どうなることやら．
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-09-30 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Hanenberg, S., Oberschulte, C., Unland, R.: Refactoring of Aspect-Oriented Software, Net.ObjectDays 2003, Erfurt, Germany, September 22-25, 2003
Aspect-aware Refactorings をしましょう，という論文．
call(class_name.set(*)) でアスペクトを貼り付けても，「メソッドの引き上げ」などのリファクタリングをしてしまうとアスペクトが効果を発揮しなくなってしまう．
メソッドの名前変更 (Rename Method):
C.foo から C.bar に変更した場合，pointcut も変更する必要がある．call(*.foo()) → call(*.foo()) || call(C.bar()); とか，call(*.bar()) → call(*.bar()) && !call(C.bar()); とか．
メソッドの抽出:
C.foo の一部を C.bar に抽出した場合，withincode を等価変換するには，次のように変更する必要がある．withincode(void *.foo(..)) → (withincode(void *.foo(..)) && !call(void C.bar(..))) ||(withincode(void C.bar(..)) && !execution(void C.bar(..)) && cflow(withincode(void C.foo(..))));
メソッドの移動:
C.foo から D.foo に移動した場合，target や this を変更する必要がある．pointcut x(C c): execution(void *.foo()) && this(c) → pointcut new_x(C c): execution(void *.foo()) && this(c);pointcut new_y(D d): execution(void D.foo()) && this(d);
アドバイスの抽出(Extract Advice):
this, target, args, などを使って元のメソッドを厳密に指定する．また，advice 自体は around を使って，メソッドの実装をコピーして，元のメソッドに残した部分だけをproceed に変えて，なるべく元の制御構造を維持するようにすると簡単．
Introduction の抽出(Extract Introduction):
こっちは，普通にメソッド定義をコピーし，頭に型名をつけるだけでよい．
Pointcut の分解 (Separate Pointcut):
pointcut 定義の共通部分だけをくくりだして別の pointcut にする．
で，この人たちは，Aspect-aware なリファクタリングをするためのツールを Eclipse プラグインとして作ったらしい．
主に名前と型情報関係だけで，cflow などは（実際に呼ばれるコンテキストが変わらない限り）影響を受けないので気にしなくてよいらしい．
_ 論文 ▲
Pascal Costanza:Dynamically Scoped Functions as the Essence of AOP
を読んでみた．Lexical Scope （定義位置に依存して変数の binding が決まる）と Dynamic Scope （実行時点に依存して変数の binding が決まる）の違いをCommon Lisp 的記述を使って説明している．
で，アスペクトの役割をdflet という述語を使ってdflet (関数などの再定義) (評価したい関数)という形で書いている．「評価したい関数」というのが変換元のプログラムのことで，「関数などの再定義」 がアドバイスに相当し，「評価したい関数」の中で呼んでいる関数を実行時バインディングで置き換える．
「関数などの再定義」をする dflet をどこに配置するかというのが，Pointcut の役割をしている．
「特定のポイントで関数のバインディングを変える」とみなすか「イベントに連動してまったく処理を行う」と考えるか，という違いのような気がするけれど，関数のバインディングと制限してるほうがちょっと範囲が狭くて，それで十分な範囲をカバーしているのか謎．
_ 論文 ▲
aosd-discuss で，次の記事のことが話題に上がっていた．
Pascal Costanza:Dynamically Scoped Functions as the Essence of AOPACM SIGPLAN Notices,Volume 38 , Issue 8, pp.29-36 (August 2003)http://portal.acm.org/citation.cfm?doid=944579.944587
この記事に対して，Kiczales が，「cflow を dynamically scoped functionとしてとらえるにしても，AOP はそれだけじゃないでしょ，たとえばメソッド呼び出し以外の join points だってあるんだから，云々」と言ってた．ということで，後で読んでみることにする．
2003-09-29 古い日記からの変換データ [長年日記] ▲
_ pdftotext ▲
あまり時間をかけても仕方ないし，pdftotext -raw で実用に比較的近いものが出てくるようなので妥協することにした．それでも改行時の "-" 取ったりとか適当な文の切れ目を見つけたりとか，色々やることはあるんだけど．
_ PDF2TEXT ▲
PDF2Text Batch バージョンなんてものがあったから試してみたが，"ff" などの特定の文字並びが一部文字化けする上ニ段組の解決もしてないので，全然役に立たない．http://www.traction-software.co.uk/pdf2textBatch/index.html
_ PDF2ASCII ▲
pdf2ascii ってないんだなーと思っていたら pdftotext だった．PDF から英語論文のコーパスを作ってみたいのだが，ニ段組がそのままの形で出力されてしまうのが難点．
_ 論文 ▲
Frank Hunleth, Ron Cytron, and Christopher Gill:Building Customizable Middleware using Aspect-Oriented Programming
分散アプリケーションのミドルウェアでアスペクト指向を使おうというshort paper．CORBA を使っているので，AspectIDL とかいうのを考えていたらしい．アスペクトがミドルウェアの実装とテストフレームワークを横断している図にちょっと興味を惹かれた．
_ 論文 ▲
AspectJ のイディオムを整理した論文．前の Idioms for Building Software Framworks in AspectJ を包含して，Marker Interface が新しく加わっている．
Stefan Hanenberg, Rainer Unland:AspectJ Idioms for Aspect-Oriented Software Constructionhttp://www.cs.uni-essen.de/dawis/publications/papers/aop/2003_HSU_AspectJIdioms_EuroPLOP_2003.pdf
こっちのほうが refer するには良さそう．Hanenberg, S., Schmidmeier, A.: AspectJ Idioms for Aspect-Oriented Software Construction, Proceedings of 8th European Conference on Pattern Languages of Programs (EuroPLoP), Irsee, Germany, 25th–29th June, 2003
このあたりも，一度サイトに整理してみようかなぁ．
_ 論文 ▲
Stefan Hanenberg, Pascal Costanza:Connecting Aspects in AspectJ: Strategies vs. Patterns
AspectJ の機能を整理している論文．アスペクトをどのようにアプリケーションに接続していくか，という Strategy (パターンではなくて戦略）の話．
アスペクト・アプリケーション間の接続に利用可能な Strategy を，次のように規定している．
Static Crosscutting:
・クラスの先祖を直接追加
・クラスのメンバーを直接追加
・アスペクトの影響を受けたコンテナと 接続するアスペクト（間接的な振る舞いの追加）
Dynamic Crosscutting:
・直接，pointcut で接続・アスペクトが接続されたコンテナに，オブジェクトを接続
・具象アスペクトが抽象 pointcut を再定義して接続
・独立した pointcut 同士を組み合わせて接続
それぞれ，どんなメリットがあるかを記述しているのでデザインパターンに似ているのだが，この人たちはあえて Strategy という言葉を使っているらしい．
Strategy と Idiom, Pattern の区別として，Idiom は特定言語の実装例のこと，Pattern は，使うことで品質が保証されたりといった利益があるものである，という立場を取っている．
_ 論文 ▲
前に読んだ論文の読み直し．
S. Hanenberg, A. Schmidmeier:"Idioms for Building Software Frameworks in AspectJ"AspectJ のイディオム４種類を紹介している論文．
子アスペクトが，動作すべきかどうかを boolean 値で返して，true のときのみアドバイスが動作する pointcut method，というイディオムがあるのだが，pointcut method が副作用を持っていると問題が起こる場合があるので，それを防止する策と一緒に使わないと困るのかなぁ，とふと思った．副作用について議論しようとすると，その過程で refer することになるかな？と思ったのでここに再掲しておくことにする．
_ AspectJ ▲
ふと思い立ってGoogle で "AspectJ" で検索してみたら，日本語サイトだけなら２位，英語も含めても13位．だんだん順位が上がってきた．"アスペクト指向" ではまだまだ developerWorks などにかなわないけど，論文などは10位以内に出るようになってきた．
_ AspectJ ▲
こんなのもあるらしい．aosd-discuss で紹介されていた．The Aspect-Oriented Software Architecture Design Portalhttp://trese.cs.utwente.nl/taosad/
どこかで見た URL だと思っているのだが，Early Aspects の Workshop を去年くらいに開催したところのような気がする．
