netail.net

_ AOSD 2003 ▲

AOSD2003本会議の論文（の中で興味を引いたもの）はこれで最後．

Mark C. Chu-Carroll, James Wright, Annie T. T. Ying:``Visual Separation of Concerns through Multidimensional Program Storage''

発想は，Separation of Concerns を，「言語的に分けずに，見た目的に分ける」というもの．

必要なのは，クラスより細かい単位でのストレージへの保管，複数のソースフラグメントの集約，動的なフラグメントの選択，フラグメントを認識するエディタ，などなど．

この論文では，「ツールの見た目こんな感じ」というスクリーンショットがやっぱり Eclipse ベースで作られていて，すごく格好よさそうに見える :-)

個人的な好みで言うなら，アスペクトとオブジェクトを分離しておいて，オブジェクトを見るときはアスペクトのコードがあたかもそこにあるかのように（灰色などで）見せる，というのもアリかなーと思うのだが，Visual C# などのコード「折りたたみ」機能などと同様に実装されないものだろうか．

_ AOSD 2003 ▲

だんだん読むのにも疲れてきたのでざっと斜め読み．

Doug Janzen and Kris De Volder:``Navigating and Querying Code Without Getting Lost''

JQuery による検索ツールの実装．Query としてはpackage( ?P, type, ?T) のように"?"で始まる自由変数を満たすノードを見つけてくる Prolog のような言語で書く．パッケージ，型，メソッド，どのメソッドから参照されているか，といった情報が使える．

クエリー結果はツリー構造で表示されるが，その中からさらに検索するときは，ツリーを「接木」していくと検索プロセスが分かる，とか言っているあたりが面白いかも．

ちなみに，プロトタイプは Eclipse ベース．クエリーを直接書くのは面倒だから，何か適当なラッパーを間にかませばすごく便利になりそうな予感．

_ AOSD 2003 ▲

AOSD2003の論文はこれを読んだところであと二つ．もっとも，併設ワークショップの分がさらにあるのだが．

David B. Tucker, Shriam Krishnamurthi:``Pointcuts and Advice in Higher-Order Languages''

Scheme で pointcut 定義や advice の定義をしている論文．pointcutがlambda定義されてるあたりが格好いい．(lambda (jp) (and (eq? f (first jp)) (memq g (rest jp))))とかいう感じで順番に構築していってる様子が説明してある．

この様子を見ている限りでは，Scheme ではかなり頑張れるみたい．ただ，関数型特有の性質について触れてなくて，lambda をカリー化していったときはどうなるのか，とか色々気になるところは残ったまま．今後に期待したい．

_ AOSD2003 (下の続き) ▲

JAsCo のシステムでは，Beans を必要以上に操作しないので，動的にアスペクトの取り外しができる．逆に，アスペクトを回避して元の実装を呼ぶ，という処理は使えなかったりする（そのあたりはコネクタでうまく回避する必要がある）．

ツールとして，Visualにコネクタをつないだり外したりする環境もあるらしく，それを使うと格好よくアスペクトの付け替え作業ができそう．何より，動機，モデル，言語要素が理解しやすいのがポイントかも．JAC よりも良くまとまっている気がする.

さりげなく，将来の課題のところに .NET のMSILにも対応してみたいなぁ，とか書いてあって，もし実装されたら一回は使ってみたいかも．

ちょっと気になるところは，コネクタを定義するのが，アスペクトが多くなると意外と大変なのではないか，というところと，アスペクトに対するアスペクトを書くときなんかに怪しげなことが起こったりしないのか言及がないところ．まあ，実際の開発言語として使われるようになったら，もっと利点や弱点が分かるかも．

_ AOSD2003 ▲

論文読みは続く．Davy Suv\acute{e}e, Wim Vanderperren, Viviane Jonckers:``JAsCo: an Aspect-Oriented approach tailored for Component Based Software Development'' コンポーネントベースの世界(とりあえずこの論文ではJava Beansが材料)では，コンポーネント，アスペクトの再利用性は非常に重要．しかし，今のアスペクト指向では，アスペクトの結合基準の記述がアスペクトの定義にくっついていて再利用性が低かったり，コンパイル時に結合するので動的な特性を持ったシステムでは利用できなかったりする． そこで，JAsCo 言語では，アスペクトとして次のように定義する．

class AccessManager {    hook AccessControl {    AccessControl(method(..args)) {      executes(method);    }    replace() {      if (p_db.check(currentuser, object) {        return method(args);      } else {        throw new AccessException();      }    }  }
  :  // other methods and fields, shared by hooks
}

この hook に対して，コネクタを定義する．

connector PrintAccessControl {  AccessManager.AccessControl control =     new AccessManager.AccessControl(* Printer.*(*));}

ここで，コネクタは結合対象を定義する．また，複数のアスペクトを結合したいときは，ConnectionStrategy というインタフェースを使って「１個目のアスペクトが動作しなければ二つ目も動作しない」といった処理を定義できる． 基本的には動的処理で，バイトコード変換を使って普通の Java Beans にアスペクト用のフックを埋め込み，そのフックに到達するとコネクタ・レジストリを探して，マッチしたらアスペクトを実行させる，といった形になる．

_ 花見 ▲

造幣局の桜の通り抜けに行ってきた．天気もよく，色々な種類の桜が満開で，満足．ちょっと混雑の度合いがひどいような気はするが．

帰りにロンドンティールームでスコーンを食べて休憩してたら，研究室の事務から呼び出されてすぐに帰還することに．ちょっとショックだった．

_ AOSD2003 ▲

Karl Lieberherr, David H. Lorenz, Pengcheng Wu:``A Case for Statically Executable Advice:Checking the Law of Demeter with AspectJ''

Law of Demeterをチェックするために，コンパイル時に実行可能なアドバイスを書けるようにしてみようとかいう感じの話．当然ながらJoinPoint.StaticPart だけに依存して実行できるものだけに限られるが．

AspectJのdeclare warning とかの上位バージョンと言えないこともない．

Law of Demeter とは：

1. Class Formあるクラス C のメソッドは，以下のメソッドにしか依存してはならない．

・C のほかのメソッド

・C のメソッドの戻り値のクラスのメソッド

・C のメソッドの引数のクラスのメソッド

・C のインスタンス変数のクラスのメソッド継承クラスは，Cの一部だからどう呼んでもいいのかな？忘れてしまった．

2. Object Formあるオブジェクト o は，以下のオブジェクトにしかメッセージを送ってはならない．

・o 自身

・o に引数として渡された変数

・o のインスタンス変数

・o の中で構築されたローカルオブジェクト

・o 自身のメソッドの戻り値のオブジェクト

これは，守る側も検査する側も大変なので，アスペクトとして検査を書くのだが，できればコンパイル時に検査までやってしまいたいよね，という話．

この論文では特に述べられていないようだが，アスペクトも Law of Demeter に従うべきなんだろうか．オブジェクト指向とはそもそも考え方が違う，という話もあるが……．

_ AOSD2003 ▲

Sean McDirmid, Wilson C. Hsieh:``Aspect-Oriented Programming with Jiazzi''

Jiazziという言語の紹介に近い論文．

signature としてクラス群のシグネチャだけを定義する．atom というのが接続単位で，atom は import, export で入出力ポートを宣言する．import, export のインタフェース指定に signature を使う．で，link unit1, unit2; という形式で atom 間を接続できる．

signature は， sigunature new_sig = old_sig + { .. } という形式で拡張できる．

実装ファイルは，atom名/sigunature名/クラス名 のような形式になるっぽい．

型パラメータもサポートしている．name [DEVICE];class [DEVICE] extends .. { void set[DEVICE]([DEVICE] dvc);}というように記述しておいて，実装サイドではvoid setDEVICE(DEVICE dvc) を実装する．で，後からsignature hoge = foo + { [DEVICE] = Spell;}というようにしてパラメータを与える．

基本的には Hyper/J や mix-in のアイディアに近くて，利用関係をプログラマが明示的に書けるところがやはりポイント．クラス間の利用関係，継承関係を接続できるところが面白いかも．

_ 背景については OOPSLA2001の論文を読め，ということらしい． ▲

S. McDirmid, M. Flatt, and W.C. Hsieh:``Jiazzi: New-age components for old-fashioned Java'',In Proc. of OOPSLA, Oct. 2001

_ AspectJ ▲

とりあえず，AspectJ のインストール方法をドキュメントに追加．別にこの程度，まとめてくれてるサイトは他にもあるのだが，初めて使う人に向けた情報も載せよう，ってことで．

_ AOSD2003 ▲

タイトルに興味を引かれてしまった論文．Stefan Hanenberg, Rainer Unland:``Parametric Introductions''

Introduction中での自己参照thisはどう扱うべきか？もし結合対象のクラスを指すとしたら（わりと妥当な判断だが）abstract introduction(結合対象クラスが，まだそのアスペクトでは未確定のintroduction)では型チェックができない．weave-timeよりも前にthisの型が決定できればうれしい，というのが動機．

Introductionがうまくいかない例として，Singleton, Visitor, Decoratorが掲載されている．Singletonは，オブジェクトを返すときのシグネチャが具象クラスに設定できないので型キャストが必須になる．他も，結合対象クラスの存在をアスペクトが知らないと対処できない．

で，この筆者らの提案は，一言で言えば?class と書いたところがweave対象クラスの名前になる，というようにパラメタライズして，?class を戻り値や引数の型として使う．そして，pointcut target(): equals(?class, A)||equals(?class, B);というようにしてパラメータと実体名をバインドする．

Introductionに対してどういう検査が有効だとか，そのときにIntroductionのタイプに応じてどう影響があるか，とかは将来の課題．

_ AOSD2003 ▲

さらに論文読みは続く．Erik Ernst, David H. Lorenz:``Aspects and Polymorphism in AspectJ''

オブジェクトの型に合わせて，適切なアドバイスのうちひとつを実行したい，といった要求があるが，そのときに今のAspectJでは ad hoc な方法しかないので何とかしたい，という話．で，アドバイスに名前を付けてグループ化しておき，そこから適切なものを選ぶということを提案している．また，オブジェクトの従来の多態性のかわりに，各アスペクトがintroductionを使ってクラスに必要な実装を与えよう，とか言っている．

_ 論文 ▲

輪講で使った論文：Damien Sereni, Oege de Moor:``Static Analysis of Aspects'',Proceedings of AOSD 2003.コールグラフを構築して，呼び出し関係の正規表現に直して，Pointcut 定義との包含関係を取ったらアドバイスを静的に結合できるね，という話．正規表現との包含関係については，Chip-Chop Matrix というものを使って計算できるらしい．Oege de Moor, Stephen Drape, David Lacey and Ganesh Sittampalam:``Incremental Program Analysis via Language Factors''という論文に載っていた．もし使うことがあれば見ることにしよう．また，正規表現を生成する Tarjan のアルゴリズムというのも使われている．ポインタだけメモ．R.E.Tarjan: ``Fast algorithms for solving path problems'',Journal of the Association for Computing Machinery, 28(3):594-614, 1981

とりあえず，静的解析コストが高くて（正規表現の包含関係のテストが重い）スケーラビリティがあやしいというのだけは確かだが，予備知識へのポインタが色々あって面白い．

_ AOP ▲

AOPでは，ソースをカット＆ペーストした場合に，その位置の join point が違うからアスペクトの動作が変わってしまってプログラムがうまく動かなくなる場合があるよね，という話をAspectJ-Users ML に Tim Pedone という人が投稿していた．実は，けっこう重要な話かも．「どこにアスペクトが貼りついてるかを常に意識する」のを開発環境でフォローするときの動機のひとつとして使わせてもらうことになりそう．

_ 出張 ▲

アメリカへの出張準備，の前段階として親の了承確認が入った．いちおう情勢の不安定を受けての措置らしい．ってことで，親にメールを送ってみた．しかし，緊急というほどでもないが，気になるので仕事から戻ってくるあたりで連絡がなければ素直に電話してみよう．

_ メーラー ▲

Al-MailからBeckyへ移行するかどうか考えるために，軽くBeckyをつついてみた．オプションなどを見た限り，使い勝手はよさそう．4000円程度のライセンス料も今となっては安いものだ．学生の間はAl-Mailでもいいかもしれないが．

Al-Mailのメールを選択して「ファイル保存」でmbox形式出力してBeckyに食わせればいちおうメールの移行はできるらしい．各フォルダごとに実行しなくてはならないので，それなりに手間はかかりそう．

_ お菓子 ▲

昼前に府議会議員選挙の投票に行く．近所の小学校が投票所だったが，桜がちょうど散り際で綺麗だった．

で，帰ってきたところで来客．chez copainのマンゴープリンと苺のゼリーっぽいケーキ．どっちも見た目が華やかだった．最近，お菓子をたくさんもらうのだが，甘いものを普段は控えている人がお菓子を買うダシにされてる感がある．もちろん，タダであちこちの新作ケーキが食べられたりするので，文句を言う筋合いはないのだけど．

_ 料理 ▲

人に勧められて，朝食はリンゴのソテー（単に薄く切ってバターで焼いたともいう）と食パン．食べてみたら，アップルパイの簡易版みたいな感じだった．欠点は，リンゴが１個だと量が多いことだろうか．一部，アップルティーにするというのもありかも．

_ bun45 ▲

なんと，データを削除する直前に確認を取るためのデータ表示を行っていたのだが，そこで参考文献データのparseに失敗していた．昔，データ形式を変更したときに変更し忘れたものらしい．結局，参考文献を持ったデータが削除されることがなかったためにいまさらバグが発現したということだった．事前テストで検出できたはずのバグなので，ちょっと恥ずかしい．

_ bun45 ▲

バイト代の支給と，ミーティング．

なぜかファイルのうち削除できないものがある，という謎の報告を受け取ったので，原因を調査することにする．とりあえず，忘れないようにここに必要なデータだけメモしておく．NiemeyerSirOttoErnst.xml

_ AspectJ ▲

aosd-discuss メーリングリストで，Concern って何，という話が出ていた．

それに対して，Ana Moreira が次のようにまとめていた．

Message-ID: 00fb01c2ff46$bd31b420$0100a8c0@microrede.pt

List-Archive: http://aosd.net/pipermail/discuss/

Subject: Re: [aosd-discuss] How determine what is crosscuting in requierements level

A concern is anything with interest for a system; therefore, a concern may be a functional requirement or a non-functional requirement. Any requirement(functional or non-nonfunctional) can be described in terms of other (sub)requirements. So, you have requirements at different levels of granularity.

A concern cuts across another concern (is crosscutting) if one is related with the other, or needed in the other.

_ 工事 ▲

家の前でガス管の夜間工事をしてるので，寝不足．派手な音はしないが，ライトの明滅がうっとうしい．