netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2005-03-06 古い日記からの変換データ [長年日記] ▲
2005-03-07 古い日記からの変換データ [長年日記] ▲
2005-03-13 トラックバック実験． [長年日記] ▲
2005-03-16 tDiary設置． [長年日記] ▲
_ tDiary に移行してみました． ▲
トラックバック使いたさに tDiary，実際に使ってみると，書式に関するサービスは貧弱な印象で，いっぱいあるプラグインも，単に ERb で後からHTMLを色々挿入できるからいいよね，というだけに聞こえるのがいまいち…．
前の日記にあってこっちにないものが，スケジュール記録とキーワード検索．キーワード検索がないと，過去にたまった論文情報がまったく使い物にならなくなってしまう．最大の問題は，「コンテンツのフィルタリング」部分がプラグイン機構になっていないので拡張できない，ことのような気が．namazuみたいな全文検索では，実際，論文には特殊用語が多く出現するので分かち書き失敗してうまく検索できなくなったりするので，個別CGIで外部インタフェースでtDiaryソースを処理して検索結果（このスタイルに合わせたインタフェースで）提供するのが正しいあり方？
2005-03-17 tdiary へ正式移動． [長年日記] ▲
_ tdiarysearch ▲
ネックだった検索まわりも，お手ごろなインタフェースの tdiarysearch を発見できたので，いちおう解決． というわけで，tdiary に正式に移行することに．_ [Java]Contract4J ▲
メソッド引数宣言に対する @pre 属性，メソッドに対する @post 属性，クラスに対する @contract 属性などとして条件式をくっつけておくと，assert文として読み替えてくれるツールみたい．公式サイトを見ていたら，assert 文をそのままプログラムに書くと "contract" concern がソースと混ざってしまうね，といったことを主張していた．やりたいことも，やってることもわりと素直．
AspectJ を使って annotation をインタータイプ宣言して制約を付加するようになると，それなりに面白いと言えなくはないが，やっぱりオブジェクトなどの実行状態（コンテキスト？）を表現できないので，やっぱり何か足りない気がする．
_ [論文]デザインパターンのアスペクト指向実装の定量的評価 ▲
A. Garcia, C. Sant'Anna, E. Figueiredo, U. Kulesza, C. Lucena, A. von Staa:
Modularizing Design Patterns with Aspects: A Quantitative Study.
Proceedings of AOSD 2005, pp.3-14, Chicago, Illinois, March 2005.
デザインパターンをアスペクト指向で書くと嬉しいことがある，とは今までにも言われてきたが，それがソフトウェアの品質メトリクス的に本当のことなのかどうか調べてみようという論文．
計測方法としては，「関心事の分離されている度合い」として，デザインパターンを１つの関心事と見たときに，関心事に参加しているクラス，アスペクトの数とそれにアクセスするクラス，アスペクトの数の合計を「拡散度合い」と考えて，クラス・アスペクト単位での数，メソッド・アドバイス単位での数を調べている（小さいほど固まっている = 良い分離）．また，凝集度，結合度，行数を見ている．
結果としては，良くなるものもあれば悪くなるものもある，という点ではKiczalesらの定性的な評価から極端な変化はない．
「関心事の分離されている度合い」が上がっても，その結果出てきたクラス群が強い依存関係を持っていたり，妙に行数が増えたり（実装が複雑になったり），といった結果になって，結果が良さそうなのは Observer や Mediator など一部だけに限られていた様子．まあ，何でもかんでもAOPで書いて嬉しくなるわけがないので，そこは当然だろうけど…．
評価メトリクスの妥当性やら実験対象の正しさやらの問題は微妙にあるが，Separation of Concerns を無理に進めると問題が起きる可能性に言及したくなったときには引用できそう．
2005-03-18 論文読み． [長年日記] ▲
_ [論文]AOP設計の分析 ▲
Cristina Videira Lopes, Sushil Krishna Bajracharya: An Analysis of Modularity in Aspect Oriented Design.
Proceedings of AOSD 2005, pp.15-26, Chicago, Illinois, March 2005.
Design Structure Matrix とかいう設計道具と評価枠組みの上で，あるWebサービスを対象に，設計を評価してみましたという話．アスペクトを含んだ設計のほうがよい値となるという話らしい．
アスペクトとして使われているのはロギングと認証だけなので，何をアスペクトを作れば効果が大きいとかいった話ではないらしい．
_ [論文]AspectCOBOL ▲
Ralf Lammel, Kris De Schutter: What does Aspect-Oriented Programming Mean to Cobol ?
Proceedings of AOSD 2005, pp.99-110, Chicago, Illinois, March 2005.
AspectCOBOL があったとしたらどんな言語で，何に使えるのか，という普通の論文とちょっと構成が違う感じの論文．同期制御や永続化などはCOBOLだとあんまり嬉しくなくて，ポリシーの強制，やり取りしたデータの記録および再生による回帰テストの実現，などのほうが嬉しいのでは，と挙げられている．
_ [論文]アスペクトのためのDbC ▲
Therapon Skotiniotis, David H. Lorenz: Cona: Aspects for Contracts and Contracts for Aspects.
Companion to the 19th OOPSLA, pp.196-197, 2004.
AOPとDbCを同時に使うという場合に，いつ表明を検査すればよいのか，という問題について記述したもの．
要は，メソッドの事前条件をチェック→beforeアドバイス実行→メソッドの事前条件をもう一度チェック→メソッド実行，となる．事後条件についても同様に，afterアドバイス実行前後に２回検査することになる．こうして，アスペクトがオブジェクトの振る舞いに影響を与えないようにしよう，というもの．
メソッドの事前条件成立から，beforeアドバイスの事前条件が成立しない場合は，そこにbeforeアドバイスを配置することが間違っている，となるらしい．
_ [論文]abc: AspectJコンパイラの別実装 ▲
Pavel Avgustinov, Simon Christensen, Laurie Hendren, Sascha Kuzins, Jennifer Lhotak, Ondrej Lhotak, Oege de Moora, Damien Sereni, Ganesh Sittampalam, Julian Tibble: abc: An extensible AspectJ compiler.
Proceedings of AOSD 2005, pp.87-98, Chicago, Illinois, March 2005.
abc コンパイラの実装のお話．いちおう，eaj という AspectJ を拡張した言語の処理部分を作るのに行数が少なくてよい，といった感じで評価を行っている．
あんまり論文読んでどうこう，というのはなくて，abc を研究のツールとして使ったら引用しよう，というくらいか．
_ [論文]リファクタリングのための基本操作の定義 ▲
Leonardo Cole, Paulo Borba: Deriving Refactorings for AspectJ.
Proceedings of AOSD 2005, pp.123-134, Chicago, Illinois, March 2005.
メソッドやフィールドのアスペクトへの移動とか，アドバイスの追加とか，色々な変更操作それぞれについて，いつならそれを行ってもプログラムの意味が変わらないかを定義しましたという話．実際に，「ポイントカットの抽出」のようなリファクタリングが，この操作上でどのような作業なのか，というのを考えている．
やっぱりリファクタリングが「元のプログラムの意味を保存していること」を保証するのが難しいので，かなり自明な「等価なコード片」の条件を規定している様子．ただ，実際にリファクタリングをこのような操作列で定義したときに，「各操作を適用するための条件」を，初期状態から成立させることができるかどうか，いつ誰が判定するの？という問題は消えなかったり．
2005-03-21 久々にプログラムを書く． [長年日記] ▲
_ [hyCalendar]Towards 1.0.1 ▲
ヒントウィンドウの多重ポップアップの実装途中で放り出していたのを久しぶりにつついてみる．何をどこまで実装したかがテストケースしか手がかりがなかったりするあたり厳しい．
2005-03-22 全国大会２日目 [長年日記] ▲
_ D-3「ソフトウェアサイエンス」 ▲
セッション「ソフトウェアサイエンス」は，ソフトウェア工学という分類と違って，アルゴリズムからフォーマルアプローチまでごった煮な感じ．
質問もほとんど出なくて，Session Chair の東工大の佐伯先生がよく色々質問を出せるなーと感心．
個人的には，尾崎敦夫・佐藤裕幸（三菱電機）「並列処理環境における消費電力低減化方式」，低速モード（省電力）のCPU多数と，高速モード（電力は消費する）のCPU少しと，どちらを使って，ピーク時以外の並列環境の消費電力をいかに抑えるか，といった主旨の発表が面白かった．高速モードのCPU少数で計算したほうが通信コストが少ない分，総コストも減少する，といったように簡単にいくわけではないらしい．
_ [論文] 注目度に応じたプログラム要素のフィルタリング ▲
M. Kersten and G. C. Murphy: Mylar: a degree-of-interest model for IDEs.
Proceedings of AOSD 2005, pp.159-168, Chicago, Illinois, March 2005.
degree-of-interest tree は，注目しているノードに近い葉の重要度が高くなるように重要度を付加したツリー構造のことで，元々，注目したツリーの特定の要素だけを画面に表示するために使うものらしい．
で，この論文では，注目度として「閲覧されている（アクティブな）エディタ」に注目度ポイントを与えて，またキー入力があったエディタに対してポイントを与えて，逆に時間経過でポイントを減らして，という形でJavaパッケージ階層図，クラスのメンバーリストなどに注目度の高い要素だけを表示するような環境を Eclipse 上に構築している．構造的な情報は使っていないようなことを言っているので， DOI ツリーを厳密に適用したわけではないらしい．
効果としては，ソフトウェアの変更作業などを行っていると，そのコンテキストに合わせて重要なものだけがビュー上に残されることになり，大規模アプリケーションの開発時にも，ビューがクラスリストなどで溢れたりしなくて済むということになる．
実験としては，６人の開発者に使ってもらって，報告書を書いてもらって，有効性の確認を行っている．表示されるアイテムのタスクへの関連性は高いらしく，良い評価を得ているよう．ただ，複数タスクをサポートするのに DOI モデルを複数保持するのかとか，いつまでモデルを保持すべきなのかとか，考慮すべき要素はかなり残っているみたい．
Concern Graph のような「手動で関心事を管理する」のが嫌だから「開発者が同時に書き換えているようなコードは関連性が強い」とみて関心事の一種として認識する，といった使い方を考えている？
_ [論文] "sequence" アスペクトの記述 ▲
R. Douence, T. Fritz, N. Loriant, J. M. Menaud, M. S. Devillechaise, M. Sudholt: An Expressive Aspect Language for System Applications with Arachne.
Proceedings of AOSD 2005, pp.27-38, Chicago, Illinois, March 2005.
プロトコルの処理やバッファオーバーフロー検知などを実装するためにSequence Pointcut という概念を導入している論文．単純には，A-B-Cと３つアスペクトを連結すると，Aのjoin pointsがマッチしたら（Aが動作したら）Bがアクティブになって，Bが動作したらCがアクティブになるといった「連結」を可能にしている．で，アスペクトのインスタンスを考慮していて，AがマッチしてBがアクティブになっている間に，また別のAのイベントが起きたら，それはBが２個アクティブである（並列に動作する）と考えるらしい．
基本はC言語ベースのシステムが相手なのでthisやtargetはなかったりするが，そのかわりアクセスする変数がグローバルかどうかなどの記述要素が入っていたりする．
で，連結したアスペクト間で，変数はそのまま共通して使えるので，ある関数呼び出しの戻り値が，他の関数の引数で渡されたとき，といったようなアスペクトの記述が可能．生のAspectJでの記述と比べるとアスペクトの状態変数の管理を自動化して，しかも複数インスタンスが自動サポートしてくれる点が嬉しいところか．
_ [論文]アスペクト指向リファクタリングのカタログ作り ▲
M. P. Monteiro, J. M. Fernandes: Towards a Catalog of Aspect-Oriented Refactorings.
Proceedings of AOSD 2005, pp.111-122, Chicago, Illinois, March 2005.
Fowler のリファクタリングの不吉な匂いとその対策と同様に，アスペクト指向なリファクタリングの情報をまとめようという話．主には，ある機能を変更しようとしたら複数のソースコードを触ってしまう，というときに "Extract Feature into Aspect" を適用したいね，ということで Crosscutting Concerns を抽出するための操作として抽象クラスをインタフェースにするとか，コード断片をアドバイスに移動するとかいった操作の typical situation / recommended action のペアをまとめている．
カタログ作ってるだけのことはあって，関連研究がかなり丁寧にリストしてある印象．リファクタリング系について調査することになったら，スタート地点にいい論文かも．
_ [論文]複数のアスペクトを混ぜたときの問題 ▲
N. McEachen, R. T. Alexander: Distributing Classes with Weven Concerns - An Exploration of Potential Fault Scenarios.
Proceedings of AOSD 2005, pp.192-200, Chicago, Illinois, March 2005.
AspectJ 1.2 で Reweavable （アスペクトをウィーブした後のJARファイルにさらにほかのアスペクトをウィーブ可能にする）オプションが有効になったが，それによって起こりうる「予期せぬアスペクトの合成」問題を提起した論文．
(1) "メソッド m はメソッド f を呼ぶ" といった仮定が新しい実装の追加であっさり壊れることがある，
(2) policy enforcement (declare error 宣言されたメソッド呼び出し)が付いたJARファイルにポリシーに違反したコードを追加しようとしたとき，違反したことはエラーメッセージで分かるが，肝心のエラー原因のソースコードは見えない，
(3) 二重にスレッド保護が効いてプログラムが動かなくなる，といった例が挙げられている．
問題を回避するためのガイドラインとして，ワイルドカードの適用先を適切に限定しておくこと，またクラス階層の拡張などに対応できるように限定しすぎないこと，プログラムの持つjoin pointsに対して過大な仮定をしないこと，使うpointcutはconcernごとに区分すること，またpointcutにはドキュメントを付加すること，などを挙げている．
ある意味では回避しようがない問題で，構成管理とかで対応すべき問題かもしれないが，アスペクト指向プログラムを安心して "混ぜて" 使うためには避けて通れない場所のような気はする．システムの振る舞いの一部を端的に示す，抽象的で，干渉しにくい "semantic pointcut" が定義できればいいのかもしれないが…．この論文では配布時の問題として例示されているが，「予期せぬアスペクトの合成」はアスペクトの再利用時に，たとえソースがあっても引っかかりそうな感じがするので，根は深そうな印象．SPA-SUMMER で発表したネタとも重なるので，参考文献として取っておくことにする．
_ [論文]カバレッジ計算のためのアスペクト指向言語 ▲
H. Rajan, K. Sullivan: Aspect Language Features for Concern Coverage Profiling.
Proceedings of AOSD 2005, pp.181-191, Chicago, Illinois, March 2005.
テストケースの選択にマニュアル情報などを頼りに人間が選ぶといった方法ではなく，AOPの宣言的な構文でテストケースの情報を書いたりして情報提供するといったことをしたい，というもの．
やってることは，pointcutを記述すると，そのjoin point がどれだけカバーされているかという話の様子．iterationとかconditionalとか，そのために細かい粒度のpointcut記述を作っている．
join points のカバレッジの計算が，join point shadows のカバー率っぽくみえるところが微妙ではある．
2005-03-23 全国大会３日目 [長年日記] ▲
_ Workshop on Dynamic Analysis ▲
ICSE併設ワークショップの Workshop on Dynamic Analysis は 11/21 で約50％の採択率だったみたい．以前，妙にクオリティが高い（単に好みに合致しているだけかも）論文が固まってた年があった気がしたが，やっぱりそれなりの採択率だったらしい．
_ [論文]デザインパターン上の役割とコードの対応認識によるリファクタリング支援 ▲
Jan Hannemann, Gail C. Murphy, Gregor Kiczales: Role-Based Refactoring of Crosscutting Concerns.
Proceedings of AOSD 2005, pp.135-146, Chicago, Illinois, March 2005.
デザインパターンなどの横断的関心事をアスペクトとして抽出する作業を支援するために，パターンの雛形情報を保持しておく．たとえばObserverパターンなら，SubjectとObserverという２つのクラスがいて，Observerを引数に取るattachメソッドとdetachメソッドを持つ，といった情報を保持しておく．で，開発者が部分的に，抽出したいデザインパターンやクラス名を与えることで，残りの部分をできるだけ自動で補完してデザインパターンの構成要素とコードの対応関係を作成して，実際のリファクタリング作業に移るというもの．
observerとlistener，addやattach，deleteやdetachなど，メソッド名やフィールド名からある程度推測するといった工夫も行っているよう．パターン上の要素と実際のコードの対応関係さえできれば，自動的なコード変換＋影響波及解析での変更支援となるらしい．あらかじめ作りたいアスペクトの構造が分かっているのであれば，うまく使える可能性が高い手法のように見える．
_ [論文]既存ソフトウェアのアスペクトでの拡張 ▲
Li-Te Cheng, John Patterson, Steven L. Rohall, Susanne Hupfer, Steven Ross: Weaving a Social Fabric into Existing Software.
Proceedings of AOSD 2005, pp.147-158, Chicago, Illinois, March 2005.
既存アプリケーションにいかに影響を与えずに新しい機能を追加するかということで，AOPを使いましょうという話．既存のアドレス帳アプリケーションに，ユーザがオンライン状態かどうかを表示する機能を追加するという例が載っている．
あんまり特別な話には見えないのだが，レガシーアプリケーションに対するパッチのようなアスペクトの利用を行う場合の利点（対象コードを変えなくてよい，アプリケーションの動作フローに対して機能を付加できる）と弱点（正しいjoin pointsの選択が難しい場合や，アプリケーションの実装に不用意に依存してしまう場合がある）とを参照したい場合にこの論文が登場することになるのかも．
2005-03-24 AOSDの論文読みはまだ続く… [長年日記] ▲
_ 失敗知識データベース ▲
「失敗学」で前から知られていた失敗知識データベースが，一般公開された．URLはhttp://shippai.jst.go.jp/．情報系の事例はあまり多くない．「動かないコンピュータ」は日経で特集されるくらいいっぱいあるらしいけど，こういうデータベースに載るようなものはさすがに少ないか．
_ [論文] データ構造の一貫性検査のための横断的性質記述 ▲
Patrick Lam, Viktor Kuncak, Martin Rinard: Crosscutting Techniques in Program Specifications and Analysis.
Proceedings of AOSD 2005, pp.169-180, Chicago, Illinois, March 2005.
データ構造の一貫性を検査しようとすると，一般的には手続き単位での事前条件・事後条件などを記述することになるが，そうした場合に，手続きの条件が，その中で使っている手続きの事前条件や事後条件を含まないといけなくなり，同種の条件があちこちに散らばっていき，スケーラビリティを失ってしまう，らしい．
問題解決のためのアプローチとしては，Listに参加するNode型はnextとprevを持つ，といったデータ構造用の変数をListモジュール自身が保持しておき，Node型の実体としてCellクラスを使うと宣言した時点でCellにNode用のデータ構造が自動追加される，というった感じに見える．
同じオブジェクトが複数のデータ構造に参加している場合に，データ構造単位で検証を行える（対象オブジェクト内に複数のデータ構造の情報が混ざらない）のが利点といえるか．
_ [論文] Adaptive Programming用のJAsCo拡張 ▲
Wim Vanderperren, Davy Suvee, Bart Verheecke, Maria Agustina Cibran, Viviane Jonckers: Adaptive Programming in JAsCo.
Proceedings of AOSD 2005, pp.75-86, Chicago, Illinois, March 2005.
動的AOPの実装であるJAsCoでは，Aspect Beansとして，フックをかける対象（pointcut）をパラメータとして受け取れるような機構を持っていて，実際にどのようなインスタンス・メソッドが処理対象となるかをconnectorとして定義するらしい．また，アスペクト内部からクラスへのアクセス用のメソッドを，"refinable" としておくことで，後で適用先のクラスにあわせて定義を差し替えることができるようにしている．
で，これに traversal connector という新しいタイプのconnectorを導入して，AspectJ Pointcut 系の定義ではなく Adaptive Programming の "visiting" 系の定義を受け取れるようにしました，という話らしい．どちらかというとAdaptiveなvisitorを便利に使うためにJAsCoの既存のconnector枠組みを使っている，というほうが正しいのかもしれないが．
記述を便利にするという話はいいけど，開発者はどこまでプログラムの複雑さを管理できるんだろう．可読性とかも謎．Generics＋メタデータ＋AOPの連携のおかげで，最近，急に使えるテクニックが増えているような気がする．
_ [論文] QoS管理のためのアスペクト ▲
Aleksandra Tesanovic, Mehdi Amirijoo, Mikael Bjork, Jorgen Hansson: Empowering Configurable QoS Management in Real-Time Systems.
Proceedings of AOSD 2005, pp.39-50, Chicago, Illinois, March 2005.
システムのQoS管理をアスペクトとして分離したというケーススタディな論文．QoS管理パッケージをアスペクトで書いて，無事QoSの目標を達成できたらしい．が，アスペクトとして分離するほど構成管理や再利用は容易になるが保守はしにくい，といった話を引用することになる，かも？
2005-03-25 [長年日記] ▲
_ AspectJ入門用ドキュメントの執筆 ▲
過去の授業スライドの説明文章を展開するだけの作業と言えなくもないが，ぼちぼち書き始めてみる．あまり長くないドキュメントにしたいので，実際のコード例を多めに含めて例ベースで説明できたらいいかな？というところ．
_ 今日のはまり． ▲
シンボリックリンクに対して，ファイル更新するスクリプトを走らせたら，そのスクリプトはデータ読み込み→既存のファイルをリネームして退避→ファイルを開いてデータ書き込み，という動きをしていたので，リンクがリネームされて，リンク先ファイルを更新せず，新しいファイルが生成されてしまっていた．
_ [論文]アスペクト合成の問題 ▲
Roberto E. Lopez-Herrejon and Don Batory: Improving Incremental Development in AspectJ by Bounding Quantification.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
"set*" のようなワイルドカードの使用が，後から追加されたメソッドにもマッチしてしまって問題を引き起こすことがある，という話．
アスペクトのうち，インタータイプ宣言を加算項 "a" として，ポイントカット定義を乗算として作用する項 "m" と考えたときに，A2・A1・P = (m2 + m1) * (a2 + a1 + P) と考えると， a2 に対しても m1 が作用してしまうことが原因であろう，と分析している．A2・A1・P = m2 * (a2 + m1 * (a1 + P) ) と結合を変えることで，この問題に対処できる，というもの．
これだけで問題が全部解決しているわけではなくて，declare parentsとかアスペクトの継承とか考えることはあるが，アスペクトが何でもとりあえず貼り付けばいいというわけではない，ワイルドカードが危険で，ちゃんと貼りつく範囲をうまく限定する必要があるねという方向性が見えたという点で，けっこう重要そうな印象．
_ [論文]クエリーベースの織り込み ▲
Istvan Nagy, Lodewijk Bergmans, Gurcan Gulesir, Pascal Durr, Mehmet Aksit: Generic, Property Based Queries for Evolvable Weaving Specifications.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
アドバイスの実装を複数のアスペクトとして使いまわしたり，ポイントカット定義を共有するために，論理型言語っぽいクエリーを使って，「figureClasses は FigureElement クラスを継承したすべてのクラス」「tracingModules は Tracing に属するすべてのモジュール」といったような条件を定義して，figureClasses に tracingModules を持たせる，という定義を行うらしい．
annotationを使った例なども載っていて，有利な点は，多対多のマッピングを簡単に作れること．すべてのモジュールの組み合わせを列挙しなくてよくなる．また，annotationなどをうまく使えば，新しい要素を追加するときにも，特定のannotationを付加すれば完了，となるので作業は楽になる．
不利な点は，クエリー自体が間接的な記述なので，今までのexplicitな定義より読みにくくなる可能性が高いことと，クエリーの条件で使うモジュール名やannotationを開発者が一貫した定義で用いてくれないと怪しいマッチ結果になってしまう可能性があること．
annotationのある場合とない場合とを別に議論してくれているので，annotationの有効性について話したいときには引用できるかも．
_ [論文]アルゴリズムをAOP的に書く ▲
Karl Matthias Hamel, Klaus Ostermann: Modularity and Reusability of Algorithms - A Case Study using Caesar.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
STLコンテナのようにアルゴリズムを接続したいね，という話らしい．Caesar では動的なアスペクトの織り込みが可能なので，特定のデータクラスにアルゴリズムアスペクトをバインドして計算，とかやってみたいらしい．特別有効とか効果がないとかいうことはないようだが…．
_ [論文]Extract Method Calls リファクタリングの自動化の問題 ▲
Andy Kellens, Kris Gybels: Issues in Performing and Automating the "Extract Method Calls" Refactoring.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
アスペクトとして抽出したいメソッド呼び出しが，メソッドの実装の先頭や終端以外に現れたり，計算式の途中に現れたりすると，アスペクトを自動で取り出すのがうまくいかないとかいう問題がある，らしい．で，それを文単位の Join Point を用意して問題を解決しようとしている様子．やりたいことは良く分かってないが，Join point 同士の関係をグラフ化した図は（そんな大層なものではないが）他で見たことがないので面白いかも．
2005-03-26 [長年日記] ▲
_ 追いコン ▲
井上先生のお宅訪問．去年はAOSD2004に参加していなかったので２年ぶり．宴会で撮影した写真の１枚がメールで届いたけれど，実は解像度が2560x1920 (!) だったのでJPEG１枚2MBくらい．ちょっとびっくり．
_ [論文]FuseJ: コンポーネントの接続記述 ▲
Davy Suvee, Bruno De Fraine, Wim Vanderperren: FuseJ: An Architectural Description Language for Unifying Aspects and Components.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
コンポーネント間のコネクタにAOP要素を取り込んだ手法．コンポーネントのインタフェース自体はゲートという単位で，実際のコンポーネントのメソッド名との対応を宣言する．また，コネクタがポイントカットとアドバイス定義に相当していて，特定のゲートへのアクセス時に，他のコンポーネントを動かすことができる．ゲートに対して定義するので，コンポーネントの実装に依存しなくてよさそうなあたり，ちょっと好感．
2005-03-27 [長年日記] ▲
_ [お出かけ]川西 ▲
みどりの窓口でオフ会用切符を押さえるついでに本屋にも寄りたかったので，久しぶりに川西へ．JR川西池田で切符を買ってから川西能勢口のモザイク（の４階の紀伊国屋書店）に向かったら，どうも何かのイベントをやっていたらしく，若い女性ばかりの人だかりでエスカレーターが完全に塞がっていた．２階が吹き抜けになってるので，その側のエスカレーターに人が鈴なりになっていたようで，１階と２階の間がまったく移動不可能．結局，一度建物の外に出て，２階からの入り口に回り込むことになった．なんか興奮した甲高い叫び声がときどき聞こえたけど，結局何だったのかは分からずじまい．
主目的だった小栗 左多里，トニー・ラズロ著「ダーリンの頭ン中」を探したけど見つからなかったので，たまたま見つけた「ラヴクラフト全集７」「賢者の国の魔法戦士」「呪縛の島の魔法戦士」を購入．
2005-03-28 [長年日記] ▲
_ [work]PC返却 ▲
とうとう返却期限が近いので，新しいPCは未だ到着していないが，データのバックアップ→初期化→箱詰め．新しいPCが到着するまではデモ用ノートPCで作業する予定．といっても，デモ用PCにはPowerPoint以外のアプリケーションはほとんど入っていないので，テキストエディタとWebブラウザだけで作業できる範囲にとどまる予定．メール読み書きはWebメーラーで対処．
なので，原稿書きとかhyCalendarのアップデートとかの作業は一時停止．
_ [読書]賢者の国の魔法戦士，呪縛の島の魔法戦士 ▲
話の展開はすごく早いのであっさり読み終わり．高級マジックアイテムの強さがよくわかる．
話の本筋ではないけれど気になったのが，登場した呪われた島の住人が死ぬまで戦う様子．これは，かつて「ロードス島戦記コンパニオン」で，LPが０になった時点で即死だった（ソードワールドと違って生死判定がない）から？
_ [論文]ポイントカットの分類 ▲
Maximilian Stoerzer, Stefan Hanenberg: A Classification of Pointcut Language Constructs.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
アスペクト指向の言語ごとに使えるポイントカットが違うので，ある目的の機能をアスペクトとして記述しやすいかどうかなど，簡単に判断することができない．そこで，ポイントカットとして使える要素を整理してみようというもの．
提案している分類は三つのタイプに基づいている．１つはSpecification-Based，プログラムの抽象化した情報（クラス名やクラス間の関係など，ソースコードから得られる情報）．２つ目は，State-Basedで，AspectJのifポイントカットのように，その時点での実行コンテキスト（アクセス可能な変数やスタックトレースの状態）に依存した情報．３つ目が，Process-Basedで，cflowやdataflowのように過去に通過した状態に基づいたもの．この分類はかなり直観的で好きかも．
３パートモデルを実装したインタプリタで，ポイントカットをこういった種類に基づいて，適用タイミングとかをあらかじめ分けておくと，複数のJoin Point Modelを混ぜたときに，きれいに収まるような気がしないでもない．３パートモデルにおける "weave" が，Join Point Modelに応じて違う作業（プログラムの実行orプリプロセス）を表現するのが気持ち悪いからそう思うだけなのかもしれないが…．
_ [論文]ポイントカットの条件式のコンパイル時評価 ▲
Tomoyuki Aotani, Hidehiko Masuhara: Compiling Conditional Pointcuts for User-Level Semantic Pointcuts.
Proceedings of SPLAT 2005, Chicago, Illinois, March 2005.
何も考えずに（著者名見ずに）ざっくり眺めて，どこかで聞いた話だなーと思ったらSPA-SUMMERで聞いた話だった．
この手法は，うまく使うと，特定のメソッドを実装しているクラスは勝手に declare parent の対象になるとか，静的ポイントカットとの組み合わせで，何か便利な応用がありそうな気がする．コンパイラの負荷が上がるところは，個人的には，人間ががんばるかわりにコンピュータががんばってくれるほうが幸せなので，あんまり気にならない．
_ [論文]アクションと状態遷移の分離 ▲
Gurcan Gulesir, Lodewijk Bergmans, Pascal Durr, Istvan Nagy: Separating and Managing Dependent Concerns.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
Cで構築されたシステムで，状態ごとのアクションを実装した関数呼び出し＋状態遷移のための変数変更を羅列していたら，もし新しく関数呼び出しを追加したり，あるいは既にあるものを削除したり移動したりすると，それに合わせて状態遷移が正しく行われるかどうか毎回チェックしないといけなくなる．
そこで，状態遷移に必要な変数設定を，いつ行うか，ポイントカットとして定義することで，システム内部での操作と，状態遷移とを切り離している．ポイントカットとして，基本的には，（特定の関数内部で）どのような関数呼び出しが起こったときかを指定するのだが，状態遷移より前に起こるべき関数を列挙しても，その順番については言及しないことで，fragile なポイントカットになってしまうことをある程度回避している．アクションと状態の更新とを混ぜていた場合に比べて，どの関数の配置が自由であるか（状態遷移に関係があってそこに配置しないといけないのか，関係ないがたまたま配置されているだけなのか）を区分できるようになっている点は利点と言えそう．
また，Weave時に，関数によって生成される Join Point 列が変わった場合，その変化を開発者に通知することで，状態遷移図を描いた開発者が，自分が定義したポイントカット記述を必要なら修正できるようにしている．ベースコードの変更時にポイントカットの変更は避けられないことがあるなら，コード変更時に，ちゃんと関連するポイントカットの変更を検討できるようにする，という立場のよう．
2005-03-29 [長年日記] ▲
_ [work]PC返却のつづき ▲
Webメーラを使うと，HTMLメールが素で表示されてしまって鬱陶しいことが分かったので，おとなしく一時使用のノートにAl-Mailをインストールして，サーバにメールは全部残しておく設定で運用することにした．普段使っているBeckyのメールボックスを移動してくるほうが素直なのかもしれないが，あと１日か２日だと信じて．
できることが少ないので，論文読みを加速中．ワークショップのポジションペーパーだらけ（１つ６ページ程度）なので，ざくざく進める．
_ クリーニング ▲
この時期にいつも使ってるハーフコートが阪急石橋の踏み切り近辺に固まって生息している鳩のせいで汚れたので，クリーニングに出してきた．ついでに，暖かくなってきたので，普通のコートのほうもクリーニングに出した．なんか立て込んでるようで，一週間くらいかかるらしい．それまでは厚手のジャケットを使う予定．
_ [論文]動的解析に基づく再利用コードの発見 ▲
Andrew Le Gear, Brendan Cleary, Jim Buckley, J.J.Collins, Chris Exton: Making a Reuse Aspectual View Explicit in Existing Software.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
複数のテストケースを与えてプログラムを実行し，各テストケースがどの機能を実行していて，かつどのプログラム要素を実行しているかという情報を集めて分析する Software Reconnaissance 手法をアスペクトマイニングに使ってみようというもの．
システムの注目した機能 f について，f を実行しているようなテストケースで共通して使われているプログラム要素（Indispensable Elements）の集合から，他のテストケースでまったく触れられないプログラム要素（Unique Elements）と，すべてのテストケースで共通して使われているプログラム要素とを取り除いた結果残ったもの（Common elements）を Shared(f) として定義している（Shared(f) = Indispensable(f) - Unique(f) - Common）．
この得られたプログラム要素の集合 Shared(f) を，すべての機能について和集合を取ったものが，最終的な「複数の機能で再利用されている（しかもすべての機能で使われるユーティリティではない）プログラム要素」となる．
簡単なケーススタディを行った結果，わりと再利用可能なコード（本当にライブラリっぽく作ったものを含む）が発見されたらしい．そこからアスペクトと呼べるものに持っていくのは簡単ではないような気がするが…．
_ [論文]距離の近いメソッドの集合を横断的関心事とみなす ▲
David Shepherd, Lori Pollock: Interfaces, Aspects, and Views.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
横断的関心事のコードを１つにまとめるのは大変な作業なので（自動化されていないから），ソースコードビューとしてあちこちに散らばったコードを閲覧できるようにすべきだ，という立場の人たち．で，距離関数を定義してメソッドのクラスタリングを行って，適当なカタマリができたところで，それを見るビューを使って横断的関心事を管理しましょう，という提案．
クラスタは，最初メソッド１個ずつから開始して，距離が一番近いもの同士を同じクラスタとして，２つのメソッド名の共通の部分文字列の長さの逆数をクラスタ間距離とする（共通部分文字列が長いほど距離が近くなる），という簡単なアプローチを取っている．クラスタ名としては共通の部分文字列を取り出しておき，２つのメソッドの親ノードとして，ツリー構造を構築していく．
ケーススタディを見た限りではなんとなくそれっぽい感じの出力になっている．距離関数の定義が問題だが，重みの調整とか色々な手段はありそうだし，横断的関心事を管理する上でのスタート地点としては便利かもしれない．ソースコード編集して距離がごろごろ変わるようだと気持ち悪いが．Concern Graphのような形で見つけた関心事を保存するとか，色々手はありそう．
_ [論文]Concern Manipulation Environment ▲
William Chung, William Harrison, Vincent Kruskal: Working with Implicit Concerns in the Concern Manipulation Environment.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
Concern Manipulation Environment (CME) という開発環境を作ってますという話．基本的には，「関心事」を作成→プログラム要素を関心事に関連付ける→モジュール分割などの方法を色々考える，という形態のよう．同じプログラム要素を複数の関心事に関連付けることを許可して，より良い分割方法がないか探したい，といったことも言っている．
_ [論文]アスペクトを抽出したときのコード検証 ▲
Charles Zhang, Hans-Arno Jacobsen, Julie Waterhouse, Adrian Colyer: Aspect Refactoring Verifier.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
アスペクトを抽出した時点で，（ポイントカットの定義などによって）元のコードと振る舞いが変わってしまうと嫌だから自動で調べたいね，という話．さすがに真面目な同一性の検証は無理なので，変更前と後で，同じメソッドから同じメソッドを呼び出しているかどうか，という判定で，メソッド呼び出しが消えた・増えたのを報告する．単純だけど，ないよりは，あったほうがずっと役立ちそうな印象．
_ [論文]ポイントカット定義の自動生成 ▲
D. Binkley, M. Ceccato, M. Harman, P. Tonella: Automated Pointcut Extraction.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
リファクタリング時に，自動でポイントカット定義を生成できるか，という議論．メソッドをアスペクトに移動するだけならインタータイプ宣言でよいが，メソッド呼び出しが特定のメソッドの先頭で起きているなら before execution，特定のメソッド呼び出しの直前なら before call といったようになる．そのメソッド呼び出しの中，というのを限定するために cflow(execution) を使う．また，DEF/REF関係を維持できる範囲でプログラム文の順序入れ替えを許可することで，もしメソッド呼び出し文をメソッドの先頭などに移動できるならそうする，らしい．プログラムの構造を必ずしも保存しない，というのは Amorphous Slicing の手法が既にあるので，それを使うみたい．
ただ，このアプローチを使おうとすると，生成されたポイントカット定義が fragile base code problem を起こさないように抽象化するとか，また複数のコード片から生成したものをきれいにまとめるとか，うまくコンテキスト上の変数（使われているローカル変数など）をアスペクト側からアクセスできるようにするとか，微妙な工夫が必要になるみたい．
複数のコード片に適用するときに，一歩間違うと，実は１つのポイントカットにまとめられるのに，コード片ごとに違う定義が生成されて，まとまらなくなってしまう，といったことが起きそう．うまくいったら嬉しい手法かもしれないが．
2005-03-30 [長年日記] ▲
_ [論文]メソッドがユニークかどうかによるアスペクトの発見 ▲
Kris Gybels, Andy Kellens: Experiences with Identifying Aspects in Smalltalk Using 'Unique Methods'.
Proceedings of LATE 2005, Chicago, Illinois, March 2005.
あちこちから呼ばれる単一のメソッドで，引数がなくて，その実装以外に同じメッセージに対する実装がないもの（？） "A method without a return value which implements a message implemented by no other method" は，アドバイスとして独立させることができるのではないかというもの．
コードクローンに基づく分析だと，単純な１行の log メソッド呼び出しなどが発見できないので，（fan-in analysis の一種だが）あちこちから呼ばれるような特徴的なメソッドがある場合にはアスペクトの候補として良いのではないか，というアプローチ．
呼び出される回数などでフィルタすると，多数のクラスからでも，それなりの数（人間が検査できるくらい）しか出てこなかったのでそれなりに働くのかも．
2005-03-31 [長年日記] ▲
_ [AspectJ]簡易リファレンス ▲
新PCにウィルススキャンかけている間が暇だったので，AspectJ Quick Reference の一部日本語化したバージョンをアスペクト指向な wiki内に簡易リファレンスとして作ってみた．元々サンプルコードだらけで文章はないのだけど，英語だというだけでアレルギー起こす人向け．
元々，東大の河内さんの AspectJ Primer の日本語訳があるから十分かなーと思っていたのだが，ポイントカットの述語が完全に古くなってしまった（calls とか 0.8 ベースだった）ことが判明したので，ちょっと書くことにした．
_ てぃる [コメント実験．]