netail.net

_ [work]新PC到着 ▲

新しいPCが到着．設定の大部分は移行したが，キーボードのサイズが変わってしまったので，作業効率が元に戻るには時間がかかりそう．

_ [論文]メソッドがユニークかどうかによるアスペクトの発見 ▲

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 の一種だが）あちこちから呼ばれるような特徴的なメソッドがある場合にはアスペクトの候補として良いのではないか，というアプローチ．

呼び出される回数などでフィルタすると，多数のクラスからでも，それなりの数（人間が検査できるくらい）しか出てこなかったのでそれなりに働くのかも．

_ [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 を起こさないように抽象化するとか，また複数のコード片から生成したものをきれいにまとめるとか，うまくコンテキスト上の変数（使われているローカル変数など）をアスペクト側からアクセスできるようにするとか，微妙な工夫が必要になるみたい．

複数のコード片に適用するときに，一歩間違うと，実は１つのポイントカットにまとめられるのに，コード片ごとに違う定義が生成されて，まとまらなくなってしまう，といったことが起きそう．うまくいったら嬉しい手法かもしれないが．

_ [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 列が変わった場合，その変化を開発者に通知することで，状態遷移図を描いた開発者が，自分が定義したポイントカット記述を必要なら修正できるようにしている．ベースコードの変更時にポイントカットの変更は避けられないことがあるなら，コード変更時に，ちゃんと関連するポイントカットの変更を検討できるようにする，という立場のよう．

_ [お出かけ]川西 ▲

みどりの窓口でオフ会用切符を押さえるついでに本屋にも寄りたかったので，久しぶりに川西へ．JR川西池田で切符を買ってから川西能勢口のモザイク（の４階の紀伊国屋書店）に向かったら，どうも何かのイベントをやっていたらしく，若い女性ばかりの人だかりでエスカレーターが完全に塞がっていた．２階が吹き抜けになってるので，その側のエスカレーターに人が鈴なりになっていたようで，１階と２階の間がまったく移動不可能．結局，一度建物の外に出て，２階からの入り口に回り込むことになった．なんか興奮した甲高い叫び声がときどき聞こえたけど，結局何だったのかは分からずじまい．

主目的だった小栗 左多里，トニー・ラズロ著「ダーリンの頭ン中」を探したけど見つからなかったので，たまたま見つけた「ラヴクラフト全集７」「賢者の国の魔法戦士」「呪縛の島の魔法戦士」を購入．

_ 追いコン ▲

井上先生のお宅訪問．去年は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要素を取り込んだ手法．コンポーネントのインタフェース自体はゲートという単位で，実際のコンポーネントのメソッド名との対応を宣言する．また，コネクタがポイントカットとアドバイス定義に相当していて，特定のゲートへのアクセス時に，他のコンポーネントを動かすことができる．ゲートに対して定義するので，コンポーネントの実装に依存しなくてよさそうなあたり，ちょっと好感．

_ 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 同士の関係をグラフ化した図は（そんな大層なものではないが）他で見たことがないので面白いかも．

_ 失敗知識データベース ▲

「失敗学」で前から知られていた失敗知識データベースが，一般公開された．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の目標を達成できたらしい．が，アスペクトとして分離するほど構成管理や再利用は容易になるが保守はしにくい，といった話を引用することになる，かも？