netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
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-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-21 久々にプログラムを書く． [長年日記] ▲
_ [hyCalendar]Towards 1.0.1 ▲
ヒントウィンドウの多重ポップアップの実装途中で放り出していたのを久しぶりにつついてみる．何をどこまで実装したかがテストケースしか手がかりがなかったりするあたり厳しい．
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-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-16 tDiary設置． [長年日記] ▲
_ tDiary に移行してみました． ▲
トラックバック使いたさに tDiary，実際に使ってみると，書式に関するサービスは貧弱な印象で，いっぱいあるプラグインも，単に ERb で後からHTMLを色々挿入できるからいいよね，というだけに聞こえるのがいまいち…．
前の日記にあってこっちにないものが，スケジュール記録とキーワード検索．キーワード検索がないと，過去にたまった論文情報がまったく使い物にならなくなってしまう．最大の問題は，「コンテンツのフィルタリング」部分がプラグイン機構になっていないので拡張できない，ことのような気が．namazuみたいな全文検索では，実際，論文には特殊用語が多く出現するので分かち書き失敗してうまく検索できなくなったりするので，個別CGIで外部インタフェースでtDiaryソースを処理して検索結果（このスタイルに合わせたインタフェースで）提供するのが正しいあり方？
