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のように定義する，この記述を統合開発環境などのツールから利用する…とかいう話だと思う．興味はあるけど，アスペクトの再利用についてはまだ色々問題がありそうな気がする．
2003-08-05 古い日記からの変換データ ▲
_ ZAQ ▲
ZAQ も Web メールを提供しまっせ，というメールが届いてた．まあ，activemail も Web メールがあるので，ZAQ アカウントを使おうという気はないのだが．
以下の URL は 8月6日から available らしい．https://pw1.zaq.ne.jp/support1/cgi-bin/webmail_top.cgi
2004-08-05 古い日記からの変換データ ▲
_ [論文]DｂCを条件付で無視するキャスト ▲
Robert Bruce Findler, Matthew Flatt, Matthias Felleisen:Semantic Casts: Contracts and Structural Subtyping in a Nominal World. Proceedings of 18th European Conference onObject-Oriented Programming, pp.364-388, Oslo, Norway, June 14-18, 2004.
ほんのわずかに事前条件や事後条件が異なるだけでコンポーネントが再利用できなくなる場合がある．特定のコンテキストで利用するために少なくともその場面では制約に従っていることがある．
たとえば，正の整数しか格納しないキューが要求されている場面で，手元に任意の整数を格納できるキューが存在していて，それをそのまま使いたい，という要求が生じる．
そこで，Semantic Castとして「今回はこのコンポーネントが責任を持つから事前条件・事後条件の一部を見逃してくれ」という感じの宣言をしてキャストを行う．実際にエラーが起きた場合は，Semantic Castを行ったときに「責任を持つ」と宣言したコンポーネントが悪いというエラーが出されることになる．
基本的には，クラス階層として継承関係になくてもBehavioral Subtyping を保っている場合などは安全にキャストできるので，場合によっては便利でないこともない．そのわりには仕掛けがおおげさかもしれないが．
_ [AspectJ]ドキュメント整理 ▲
アスペクト指向技術セミナーに出かけたりする準備をしつつ，AspectJ のドキュメント量がいい加減増えてきた感があるのでそろそろ整理しようと思い立ったりする．wiki にしておくのが，レイアウト面の手抜きができて楽そう？なので，wiki 各種について調査開始．
_ [論文]テスト実行結果からのマルコフモデル構築 ▲
James F. Bowring, James M. Rehg, Mary Jean Harrold:Active Learning for Automatic Classification of Software Behavior.Proceedings of ISSTA 2004, pp.195-205,Boston, Massachusetts, USA, July 2004.
あるプログラムにテストケースを与えて出てきた実行履歴のうち，各分岐で True/False のどちらにどう進んだか情報を抽出する．この True/False での分岐回数を次の分岐点への遷移確率と考え，マルコフモデルを構築する．
テストデータの自動生成ツール等を使ってデータを生成し，プログラムを１回実行して分岐をどう通ったか列が出るので，それを作成済みのマルコフモデル上である程度の確率で起こる動作なのかをテストし，確率的に起こりにくい＝未知の振る舞いとして新しいマルコフモデルを追加するというactive learning を行ってテストケースを増やしていけば，有用なテストケースだけが抽出されていくという話．
ケーススタディで Batch Learning と比較しているが，学習データが増えてきたときの学習効率が若干違っていて，Batch のほうはデータの増加量に対して結果があまりよくならない場合があるみたい．
350個のデータで13000近いデータを分類したときで，未知の振る舞いが検出される確率が，active learning 側は batch に比べて10分の１程度まで下がっている．これは，未知の振る舞いが検出されにくい＝テストケースがそれなりにそろっていて，未知の環境（実働環境）に置かれても大丈夫だろう，と確信できるということになってくる，らしい．
batch learning に対する active learning のテストデータの分類における有用性を示してはいると思うのだが，この手法を用いて作ったテスト計画が（たとえば未知の振る舞いが検出される確率が 0.001 になるまで，といったテスト計画が）どのくらい意味を持つのか，というのはいまいち分からず．けっこう面白い研究ではあると思うのだが．
_ [論文]外部状態のアサーション ▲
Robert DeLine, Manuel Fähndrich: Typestates for Objects. Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.465-490,Oslo, Norway, June 14-18, 2004.
クラスの型以外に，オブジェクトの取りうる（外部から見える）状態も宣言できるようにして，各メソッドの事前条件や事後条件として状態遷移を記述できるようにする手法の提案．
たとえば，[ TypeState("Open", "Closed") ] class WebPageFetcher {...} と記述することで，そのインスタンスが Open か Closed の２状態を取るようにする．
各メソッドの先頭に[ Pre("Closed"), Post("Open") ] void Open() { ... }というようにヘッダをつけることで状態遷移を宣言する．また，[ Post("Closed") WhenReturnValue=true ] といった記述でメソッドが返した値に状態遷移を関連付けるといったことを考慮している点はけっこう面白い．インタフェースを書く人間は状態を考慮して記述するが，実装者はその状態を考慮せずともコードが記述できる（もちろん戻り値の値はきちんと設定する必要はあるが）．
あるクラスの事前の状態・事後の状態からフィールド値がどのような条件であればその状態である，というのがわかるが，子クラスでメソッドが書き換えられるとその条件は変わってくる．そのため，クラスフレームという単位で状態管理を行う．１つのオブジェクトに，そのオブジェクトが属するクラス階層の各クラスについてそれぞれ１フレームが準備され，状態を格納する．
WebFetcher を継承して CacheFetcher を作ったとすると，普通に WebFetcher.Open を使っている場合は，[WebFetcher＠Open][CacheFetcher＠Closed]といった状態になる．これでは子クラスを使う場合に不便なこともあるので，virtual なメソッドに対してはきちんと子クラスの状態も変わって，変えたくない場合は Post("Closed", Type=Subclasses) などと明示的に宣言できるようにするみたい．
基本的には Liskov Substitution Principle とかに従っていてメソッドごとの状態の "副作用" が明示されるので使い方によってはかなり便利．インタフェースで外部状態だけ書いて実装クラスで内部状態まで書くといった使い方をすれば仕様と実装も区切られるし，面白いかも．
_ [論文]Composite パターンの拡張問題 ▲
Mads Torgersen: The Expression Problem Revisited. Proceedings of 18th European Conference on Object-Oriented Programming (ECOOP 2004), pp.123-143,Oslo, Norway, June 14-18, 2004.
"Expression Problem" と呼んでいるのは，Composite パターンを使ってツリー構造を作ってその上で再帰呼び出しや Visitor を使って処理を行うとき（たとえば Expression クラスを継承したAdd クラスと Literal クラスで加算式を表現するとき），Composite ツリーに新しいクラスや処理を追加しようとすると既存のクラスのコードを変更しなければならない場合がある，という問題．
で，この人は，Java Generics が導入されそうな時期だからかGenerics を使って問題を解決できるんですよーという提案．Visitor パターンによる実装を operation-centered，クラス階層による再帰構造を data-centered approach としてそれぞれの場合で，別個に解法を提案して，さらに hybrid approach というのを提案している．
基本的には，ある古いコードで生成されたオブジェクトが他の新しい演算などが追加されたコード上でも稼動することが目標らしい．
アプローチとしては Visitor パターンを使って accept(T node) のように型パラメータでaccept を一般化しておいて，ノード側も受け取る Visitor を型パラメータで一般化しておいて，既存のコードを使っている部分を変更せずに新しいクラスなどを追加できるようにしましょう，と言っている．
立場としてはコードの書き方，実装のための技術という感じ．
2008-08-05 ▲
_ AOAsia2008 CFP ▲
既にあちこちで（一部は個人的に）案内流してますが，APSEC 2008 併設ワークショップ AOAsia2008 の宣伝です．ワークショップのページはこちら．
発表のネタとしては，AOSD に関連したトピックなら何でもいけます．研究だけでなく，実際の適用事例に関する報告も受け付けています．
投稿は，10ページ以内の Research Paper か，5ページ以内の Position です．文書レイアウトは IEEE あるいは ACM のフォーマットの使用を推奨しています．締め切りは，Research Paper のほうが 9月8日，Position が 10月22日となっており，会議自体は12月2日に開催されます．
個人的な印象ですが，私が参加したことのあるワークショップの中では議論が比較的穏やかに進む（たとえば早口でまくし立てるように喋る人がいない）ので，英語でのワークショップが初めての人でも比較的議論についていきやすいと思います．アスペクト指向関連の研究・開発を進めている／これからやろうとしている人がおられたら，ぜひ投稿をご検討ください．
