netail.net

_ 論文 ▲

AOSD2003の論文読みの続き．ショートペーパーかと思ってたら，やっぱりこの辺りは Position Paper だったらしい．PDF を印刷してから，２週間以上経っているのでまったく忘れていた．

J. Kienzle, Y. Yu, J. Xiong: On Composition and Reuse of Aspects.

アスペクトは，サービスを提供，要求，除去する．アスペクトが他のアスペクトが要求しているものを提供する場合もあるが，他のアスペクトが要求しているものを除去してしまう場合もある．

依存しているサービス Depends-On 集合 D，除去するサービス Remove 集合 Rから，R が空集合なら保存性がある，D が空集合なら直交している，というように分類する．

また，アスペクト間の優先度などを構成グラフ(Configuration Graph)として，グラフ中の循環（相互依存関係）は分離しよう，とかいうことを説明している．どういう研究に発展するか楽しみ．

_ 論文 ▲

B. Tekinerdogan: ASAAM: Aspectual Software Architecture Analysis Method.

こちらは Full Paper．SAAM: Software Architecture Analysis Method というアーキテクチャの評価手法のアスペクト指向への拡張らしい．シナリオを Direct/Indirect で整理し，アスペクト付きシナリオを構築し，アーキテクチャのアスペクトを抽出するというもの．私の仕事とはあんまり関係ないので読むのは保留．

アスペクト指向と一口に言っても，色々やってるなぁ，というのが現在の感想．

_ 論文 ▲

さらにAOSD2003論文読みの続き．

I. Brito, A. Moreira:"Towards a Composition Process for Aspect-Oriented Requirements"

要求からアスペクト間の優先度（dominates）関係を決定するプロセスに関する話．興味がないので省略．

_ 論文 ▲

A. Gal, M. Franz, D. Beuche:"Learning from Components: Fitting AOP for System Software"

OS などで AOP を使うには信頼性が重要だが，アスペクトはコンポーネントの中身を直接扱うので使いにくい．そこで，コンポーネント側に，interface LockNeeded { void print(); }のようにインタフェース定義を置いておいて，アスペクトはそれらのインタフェースに対してのみ仕掛けることができるようにしよう，というもの．発想としては非常にシンプルで分かりやすい．

_ 論文 ▲

A. Colyer G. Blair, A. Rashid:"Managing Complexity In Middleware"

分散ソフトの複雑さを抑えるためにはミドルウェアが重要だが，そのミドルウェア自体の複雑さが問題となっている．そこで，AOSDの "宣言的" 性質を使ってミドルウェアの特性を分解したり，アプリケーションとミドルウェアの結合度を弱めるために使いましょう，という論文．６ページのショートペーパーだし，どっちかというと Position Paper ぽい気配．

_ 論文 ▲

AOSD2003周辺論文読みの続き．

W. Schult, A. Polze:"Speed vs. Memory Usage - An Approach to Deal with Contrary Aspects"

C# で dynamic weaving を実装して，メモリ節約アスペクト，分散計算アスペクトを使ってどのくらいシステム性能が変わるかを調べた論文．実データとソースコードが載ってて，ここまで変えられるのか，とちょっと感心．

_ 論文 ▲

S. Hanenberg, A. Schmidmeier:"Idioms for Building Software Frameworks in AspectJ"AspectJ のイディオム４種類を紹介している論文．

子アスペクトが親アスペクトのメソッドを実装する Template Advice, 子アスペクトが，動作すべきかどうかを boolean 値で返して，true のときのみアドバイスが動作する pointcut method，複数のアスペクトをチェインさせる Chained Advice，Factory メソッドの実体を定義する Factory Advice．

有効性については今のところ不明．

_ 論文 ▲

J. Araujo, P. Coutinho:"Identifying Aspectual Use CasesUsing a Viewpoint-Oriented Requirements Method"

"Vision" という要求分析法があるらしく，それを使って非機能的要求(Non-Functional Requirements)を確定し，複数の要求に絡む要求はaspectual use case として取り出す，とかいう話らしい．あんまり関係ない話のようなので，詳しくは読まないで置いておく．

_ 論文 ▲

H. Rajan, K. Sullivan:"Need for Instance Level Aspect Language with Rich Pointcut Language"

pointcut の種類を Rich/Simple，アスペクトが動作する単位を Type/Instance と区別して，Rich/Instance な言語がほしいよね，というのでプロトタイプを作ってみました，という論文．

instancelevel aspect Equality {アスペクト定義}と定義して，コンストラクタ呼び出しのように動作し，アスペクト初期化時に addObject(引数でもらったオブジェクト) という呼び出しでアスペクトがそのオブジェクトに張り付くらしい．フックを仕掛けてるのと気分的には同じ．

_ 論文 ▲

M. Storzer, J. Krinke:"Interference Analysis for AspectJ"

アスペクトによる Introduction，クラス階層の改変機能で，どこのメソッド呼び出しが影響を受けるかを解析する，という論文．計算アルゴリズムが明確に記述されているので，後で参考にするかもしれない．

_ 論文 ▲

I. Nagy, M. Aksit, L. Bergmans:"Composition Graphs: a Foundation for Reasoning about Aspect-Oriented Composition"

Composition Graph という中間形式に落とすことで，複数のアスペクト指向の手法を混ぜて使おうという Position Paper．クラスやアスペクトの，メンバー間の関係をグラフに落として，グラフ変換で頑張ろうとしている．それにしても，各アスペクト指向言語の表現をグラフ上の表現に落とす変換ルールを作るのが大変そうだが，逆に，新しく言語を作る人はそのルールさえ作ればあとは共通処理になるので，新しい手法の提案が楽にはなるかもしれない．

_ 論文 ▲

ICSE2003 ツール・デモンストレーションに関するまとめ．

M. P. Robillard, G. C. Murphy:"FEAT: A Tool for Locating, Describing, and Analyzing Concerns in Source Code"

Concern Graph の管理ツール．Eclipse プラグイン．Concern に属するメソッド・フィールドの呼び出し関係などを知ることができる．このグラフをアスペクト作成などにも使うことができる．-- ＧＵＩ表現があると面白いのだが．AspectJ はモジュールとして分けようとするが，FEATでは必ずしもそうする必要はない．このツールに対しては，取り出したものが正しい Concern かどうか，また Concern の粒度はどの程度か，という問題がある．ちなみに，FEAT はダウンロード可能らしい．

S. P. Reiss:"JIVE: Visualizing Java in Action"

プログラムのどのクラスが動作しているかを示すツール．プロファイラの GUI 版のようにも見えなくはない．時系列情報などを保存してるのは少しえらいとも思うが，時系列情報をどの程度取っているのかによっては，コストが微妙なところでもある．

あとは，DRT (Design Recovery Tool) がある．DRT は，GUI 操作から，実行された関数などを記録して重要度の算出などを行って，簡略化されたシーケンス図を表示してくれるのだが，論文のほうにある計算式がまだ把握できてないので保留しておく．

_ 論文 ▲

ICSE2003で聞いたプレゼンテーション等のまとめ．

J. Law, G. Rothermel:"Whole Program Path-Based Dynamic Impact Analysis"

全部動的情報から行う影響波及解析．実行トレース（主にメソッドコール？）列を作って，トレース列に２箇所以上同一の系列が出現したら，たとえば "ABCAB" ならば "xCx" + "x -> AB" に変換するという形でSEQUITOR文法という一種の圧縮形式に変換し，その上で影響波及解析を行う．

static forward slicing との比較を行っていて，動的にやった分小さくなっていると主張している．

実は，実行トレースから SEQUITOR 文法に直すときに，過去の系列をすべてパースしたら n^2 に近いアルゴリズムになってしまうはずなので，けっこう苦しいと思うのだが……．

X. Zhang, R. Gupta, Y. Zhang:"Precise Dynamic Slicing Algorithms"

動的データスライシングの話．制御構造を追いかける場合もそれほど差はない，らしい．

ポインタなどの区別は単純に値（アドレス）のマッチングでやっているらしい．実行トレースを出すのに必要なコストは考慮していない．

オンデマンドに必要な部分だけの PDG を構築するというところがポイント．スライス回数が少なければ，かなり高速になる．また，トレース結果をブロックに分解しておく Limit Processing とも比較を行っている． Data Slicing では，80％くらいのブロックは処理せずに済むらしい．

もっとも，実行トレースのサイズが 1M ステップとかになってくると，トレースをディスクに書き込んだりするコストや，スライスのサイズ自体が馬鹿馬鹿しいものになる気もするが……．

_ 余談 ▲

動的スライスでは，1. データ取得， 2. スライス計算， 3. 表示方法 を頑張らないといけないので，まだまだ課題は多そう．

Hybrid Slicing [Gupta, Saffa, FSE'95] なんてものもあるらしい．動的情報を部分的に使うものらしいので，いちおうチェックしたほうがよさそう．

_ 論文 ▲

OOPSLA2003に投稿していた原稿が reject されたので，少し修正して IWPSE に再投稿を試みることに．締め切りまであと一週間というところで決めるあたりが適当ではあるが，原稿の大まかな修正は終えて，とりあえず先生の確認待ち．

_ 論文 ▲

情報処理学会論文誌に掲載が決定した論文の原稿をメールで送付．初掲載なので，やっぱりちょっとだけ嬉しい．

_ 論文 ▲

IWPC2003 のうち，論文著者が自前で web で公開してるものを集めて読んでみた．主にプログラム解析系．（Program Comprehensionのワークショップなのだから当然だが）

D. Heuzeroth, T. Holl, G. Hogstrom, W. Lowe: "Automatic Design Pattern Detection"

デザインパターン候補を，ソースコードの静的解析＋動的解析で抽出する．静的解析の手法としては，既存の各メソッドをパターンの構成要素とみなして（たとえばあるメソッド m を Observer.notify の役割を果たすと仮定して），メソッド役割の組み合わせを探索する．それらに対して，実行時情報でフィルタリングを行う．実験データでは，静的解析で約300程度の候補が発見され，動的解析で20程度まで絞った後，手作業で1~6個程度識別していた．

_ 論文 ▲

R. Komondoor, S. Horwitz:"Effective, Automatic Procedure Extraction"

コードからの手続き抽出．break, continue などの goto 系を解決しながら手続き抽出を行う．アルゴリズムはＣＦＧ上での計算っぽい．どこまでを手続きとして抽出するか，とかいうのは微妙．

_ 論文 ▲

E.B. Duffy, J.P.Gibson, B.A. Malloy:"Applying the Decorator Pattern for Profiling Object-Oriented Software"

Decorator を使って C++ 上でのプロファイリングを実装している．ユーザの記述したクラスと，Profilerクラスを多重継承したクラスを実際には用いる，とうい形式．メモリ・プロファイルには new をフックしているあたりが若干怪しげ．クラスの Clone メソッドなどのコピー時の扱いに，多少困っている様子．これは，コピーコンストラクタで継承クラス部分がコピーされないときの問題と同様．また，継承を用いているため，名前衝突にもちょっと弱い．

_ AspectJ ▲

AspectJ 1.1rc2 リリース．とうとうバイトコード weave ＋インクリメンタルコンパイルの世界に突入できるらしい．しかし，AJDTの構成がまったく変わってしまうと，AspectJ コードを解析する側にとってはしんどい話だ．

_ Java ▲

無名クラスにはコンストラクタが書けないので不便だなーと思っていたのだが，実は {} だけを用いて初期化処理を書けたらしい． Core Java Technologies Tech Tips, May 6, 2003に掲載のサンプルコードを以下に抜粋しておく．

Comparator cmp1 = new Comparator() {
    {
      System.out.println("object initialization");    
    }       
    public int compare(Object o1, Object o2) {
      int cc = ((Integer)o1).compareTo(o2);
      return (cc < 0 ? 1 : cc > 0 ? -1 : 0); 
    }
};