netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2002-08-05 古い日記からの変換データ [長年日記] ▲
_ 読書 ▲
クリプトノミコン 2 を読み終えた．解説は東大の今井先生が，以前「情報処理」（情報処理学会誌）か何かに書いてたのと似たような話を書いてた．普通は文章や作者に関する解説があるところで，暗号技術についての解説があるというところがこの本がやや専門的領域に踏み込んでるのを感じさせる．
_ 論文 ▲
論文チェック．M. Mock, M.Berryman, C.Chambers, and S.J.Eggers.Calpa: A Tool for Automating Selective Dynamic Compilation実行中に最適化していくコンパイラに関する論文．
C プログラムに観測用プログラムを instrument して，sample input を与えて実行した結果から最適化を行うための情報を得るとか，Dynamic Slice などと一種似たような解析をしている．instrument のやり方についての詳細説明はないけど，Aspect Weaver などが実現してるのと同等の処理を実現していそう．
_ AspectJ ▲
AspectJ の dominates ディレクティブについて誤解していたことが発覚．
aspect A dominates B のとき，A は B より優先である…から A が優先して貼りつく，B before → A before → join point → A After → B After の順序で動作すると思ってたのだけど，正しくは 「A が B を支配する」つまりA before → B before → join point → B After → A After の順序で動作して，A が途中でいきなり throw とかしてB の実行を回避することができるらしい．ちなみに，"dominates *" 「他すべてを支配」するようなアスペクトが複数あった場合の動作は未定義っぽい．(現実には dominates * を記述する必然性はほとんどないが)
_ 論文 ▲
Constantions A. Constantinides, Atef Bader and Tzilla Elrad.An Aspect-Oriented Design Framework for Concurrent Systems.ECOOP '99 Workshop on Aspect-Oriented Programmingをチェック．Moderator というのを使って weaver の代わりにアスペクトの結合をコントロールするっぽい．Moderator のほうが Weaver にくらべてaspect の階層とかを考慮できるから有利，とか言ってる．アスペクトを直接貼り付けるのでなくて仲介役を導入してる点で AJC と似ていて，仲介役にアスペクトの優先度コントロールとかをしてもらえば，特に直交していないアスペクト間の調整ができれば，とても楽だろうなぁ，という印象．AspectJ の現在の実装では利用できないけど，将来的にはこういう問題の解決は必要になってくると予想される．
_ 論文 ▲
論文チェックその３．
On the Requirements for Concurrent Software Architecturesto Support Advanced Separation of ConcernsConstantions A. Constantinides and Tzilla Elradアスペクト指向が持つ色々な問題を列挙しただけ…のようにも見える．[Constantinides et al. 99] で，アスペクトの分類をしているらしいとの言及を発見した．Constantions A. Constantinides, Atef Bader and Tzilla Elrad.An Aspect-Oriented Design Framework for Concurrent Systems.ECOOP '99 Workshop on Aspect-Oriented Programmingということなので，後日チェックしよう．
_ 論文 ▲
論文チェックその２．
Compaction of Large Class Hierarchies in Databases for Chemical EngineeringM. Baumeister and M. Jarkeクラスの複数のインスタンス生成やサブクラスの分類などにアスペクトを導入，またクラスのアスペクト間の関係をモデル化しよう，という話．オブジェクトをクラス階層だけで分類するのは苦しいのでアスペクトというクラスとは別の階層を導入しているだけかも．AOP と直接の関連があるわけではなく，ちょっと期待外れだった．
JAC: A Flexible Solution for Aspect-Oriented Programing in JavaRenaud Pawlak, Lionel Seinturier, Laurence Duchien, and Gerard Florin一貫性や順序性などの inter-aspect problem についてまとめている．JAC 自体はその解決策として，アスペクトを wrapper で実現してWrapperController が起動順序などを設定するという形式っぽいのでAspectJ で実装する場合には利用できそうもない．また，ソースコードへのリフレクションも JAC では使えなさそう．ただ，AspectJ と違って，利用者側が weaver を定義できるっぽく，用途によっては便利となるかもしれない．
_ 論文 ▲
論文チェックその１．
An Approach To Using Formal Methods In Aspect OrientationX. Xie, S. M. ShatzState-Based Object Petri Nets とかいうColored Petri Net のオブジェクト表現用を使って，Aspect を Petri Net で表現して，それを結合することでAspect の合成を行うとかいう話．面白いんだけど，現状では利用する必要はなさそう．
The Watson Subject Compiler & AspectJ(A Critique of Practical Objects)Mark SkipperSOPとAOPを比較した論文．SOPとAOPの類似性について述べている．AOP は，aspect と base program のインタラクションで，n個アスペクトがあればn回インタラクションが発生するだけで，理想的には inter-aspect problem は発生しないはずだが，実際にはそうもいかない．かといって，SOPのようにすべてのモジュールが対等だと，手動で合成ルールを記述しないといけないが，これも難しい作業である…とかいう話．結局 inter-aspect problem を解決するような言語要素が現在の AspectJ には含まれてないので，もっと他に方法を考える必要がある，ということでやっぱり誤魔化されてる気分．
Mutli-Perspective Specification, Design and Implementation of Software Components Using AspectsJohn Grundyコンポーネントにアスペクト情報を持たせて選択的な再利用を実現する．コンポーネントごとに，アスペクトを aspect Collaboration provides hoge require foo end aspectのように定義する，この記述を統合開発環境などのツールから利用する…とかいう話だと思う．興味はあるけど，アスペクトの再利用についてはまだ色々問題がありそうな気がする．
