netail.net

_ 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 のカバー率っぽくみえるところが微妙ではある．