«前月 最新 翌月» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2003-09-02 古い日記からの変換データ [長年日記]

_ IWPSE/FSE

IWPSE2003 1日目が無事終了.発表も無事(?)終了.質疑応答をまとめる.

論文は面白いものが色々.研究室の特定の人に読んでもらったほうがよさそうな論文がいくつかあるので,後でまとめることにする.

JAISTの,おざきさんと話す.ネタが固まると,いきなり論文を英語で書く(書かせられる)らしい.けっこう大変そうだけど…….D1で2回目の発表だ,と言ったら感心された.

カンファレンス・ディナーはフィンランド料理のコース.1品1時間くらいの間隔で,3時間ほど食べてたらしい.会話が主役だからかゆっくりしている.最後のほうは,みんな疲れたせいか口数も少なくなってたけど.

夜になると,さすがに寒い.吐く息が微妙に白かったりする.


2003-09-03 古い日記からの変換データ [長年日記]

_ FSE

ようやくIWPSEが終わってFSE.AOP 系の人の名前がいくつかあるので楽しみではある.


2003-09-04 古い日記からの変換データ [長年日記]

_ HTML Help

ML アーカイブを作ったときに,以前流れていたウィルスが含めていたりしないかと不安になって急いで確認.添付ファイルは検知したときに削ってたので大丈夫らしい.

_ Office

セキュリティ・アップデートが出てたのでインストール.……と思ったら,4つのパッチのうち2つは「CDが必要です」とかいうダイアログが出てきた.出張先で作業してる場合はまったく対処できないというのではセキュリティパッチとしてダメな気がする.インストールしてない機能へのパッチならいいのだけど…….


2003-09-07 古い日記からの変換データ [長年日記]

_ AspectJ

出張中にたまっていたメールを消化していたら,aspectj-users ML でちょっとだけAspectJ 的 Generics なんてものが出てきた.もしやるとしたら aspect AspectName pertype T とか書いておいて type T を使ってアドバイスを書けるとかいう形になりそう,という.

Java 1.5 対応になるとそんな言語要素のサポートが必要になってくるのかもしれない.現状ではあまり関係ないが.

_ FSE

無事終了して帰国.あとは,XVCLの作者の人に,コードクローンに基づいたリファクタリングの論文の情報を送るだけ.

それにしても暑い.最高気温で20度の差があるのが辛いところ.


2003-09-08 古い日記からの変換データ [長年日記]

_ 論文

JML について調べてる最中に偶然見つけた論文.

Maximilian Storzer, Jens Krinke, Silvia Breu:Trace Analysis for Aspect Application

出典は Workshop on Analysis of Aspect-Oriented Software (AAOS 2003) as part of ECOOP 2003, July, 2003

実行履歴トレースの差分から impact analysis をするらしい.役立つのかどうかは謎.

_ 論文

FSE 2003 論文整理もこれで終わり.

FSE Session IX: Safety and Security

S. Yong, S. Horwitz:Protecting C Programs from Attacks via Invalid Pointer Dereferences

「ポインタが指してよい領域」を保持したメモリマップを作っておいて,それに対する書き込みをチェックする.また,フロー解析をして,ポインタが予期せぬ領域を指す可能性があるものをunsafe とマークしておいて,unsafe ポインタのアクセスだけを監視すればオーバーヘッドを抑えられる,という話.unsafe な read は調べるべきか調べないべきか,という議論はあるが,完全に実用を考えた構成になっている.

K. Sen, G. Rosu, G. Agha:Runtime Safety Analysis of Multithreaded Programs

Temporal Logic でデータアクセスの順序を検証しようというもの.データの流れを Lattice 化して検証しているようなのだが,空間も時間も O(w・2^m) で m は Temporal Logic の式の数,w は Lattice の幅(イベントの「同期」数に依存)らしくて,コスト的によいと言えるのかどうか謎.個人的には Temporal Logic を誰が書くんだろうというのも気になる.誰かが,「オブジェクト指向言語でなら,もうちょっとインスタンス共有とかうまい方法で状態数が減りそう」とか言っていた.

_ 論文

FSE 2003 論文整理はさらに続く.

FSE Session VIII: Component-Based Software Engineering

F. Xie, J. Browne:Verified System by Compsoition from Verified Components

コンポーネントの検証の話.After(xxx) Never (yyy) Until (zzz) のような動作特性をボトムアップに検証する.Assumption (ソースコードやマニュアルから自動生成の予定)とProperty (調べたい特性) を比較するんだーという,目的がはっきりしている点は好感が持てた.

S. McCamant, M. Ernst:Predicting Problems Caused by Component Upgrade

アプリケーションはコンポーネントの実装に依存しているかもしれないのでBehavioral Subtyping では不十分.( Pre_app → Pre_comp )∧( Pre_app ∧ Post_cop → Post_app )というのが良い,と言っている.で,実際に検証して,「このバージョン変化でこの部分は動作しなくなる可能性がある」と表示するということになるらしい.ただ,コンポーネントの不変条件とかは自分で書かないといけないらしいので,そのあたり,実用化には厳しい.

H. Rajan, K. Sulivan:Eos: Instance-Level Aspects for Integrated System Design

Mediator としてアスペクトを使いたいので,アスペクトのインスタンスがほしい.型ベースで,すべてのインスタンスに反応するようなのは嫌.また,対応相手がいない場合や1個のインスタンスに複数のアスペクトのインスタンスが貼り付くようなのも考えたい.そこで,インスタンスレベルアスペクトというのを考えた.要は,イベント処理を言語要素にしたくて,単に new Aspect(obj1, obj2) とか叫びましょう,というものなのだが,これ,アスペクトを生成するのは誰か,という問題が出てくるので,かえって複雑度を上げてたりはしないのだろうか?

_ 論文

FSE 2003 論文整理その5.

FSE Session VII: Software Analysis and Model Checking

Stan Jarzabek:Eliminating Redundancies with a "Composition with Adaptation" Meta-Programming Technique

XVCL を使って,コードをパラメタライズすることで冗長性を減らしましょう,というもの.発表の後で,「継承と Generics と XVCL ではどれがいいんですか?」と聞いてみたのだが,「リファクタリングで複雑なモジュール構造を導入するのは良くない,リファクタリングで大事なのは冗長性を減らすこと」みたいな考えを持っているらしい.メタプログラミング(というより「コード本体のテンプレート化」か)は難しくないのだろうか,とは思わなくもないが,ただの Generics よりはコード本体部分をパラメータ化できる強みがある.コードの冗長性はいいが,理解容易性やメンテナンス性はどうなのか,とか質問もあって,みんな興味は惹かれていた様子.

Yung-pin Cheng:Towards Scalable Compositional Analysis by Refactoring Design Models

リファクタリングの話かと思っていたら,モデル P から,解析しやすく意味は等価な P' を作りましょう,という話だった.こんなの考える人がいるんだなーと感心はしたが,興味がないので飛ばす.

_ 論文

FSE 2003 その4.正確には論文ではなく Invited Talk だけど.

Ari Jaaksi:Assessing Software Projects - Tools for Business Owners

色々なツールをどう使うか,という話だったのだが,その中ではエラー数グラフの読み方が面白かった.・時刻に対してエラー数が増えないのは,テストが正しくない可能性が高い.・新しいエラーを見つけながら古いエラーは修正されるはずである. エラーが未解決のままなら,開発は進展していない.という感じで考えるらしい.また,Product Family 間でドキュメントやテストを共有することでコストを削減できる,といった発言もあった.

_ 論文

FSE 2003 その3.

FSE Session V: Validation and Verification

J. Krinke:Context-Sensitive Slicing of Concurrent Programs

スレッドの扱いをきちんと行った論文.普通は「すべての可能性を」依存関係に含めるが,その中から,ありえないパスを除去するためにコンテキスト情報を使う.依存関係を解析するときに「スレッドAなら1行目か5行目から,スレッドBなら2行目から」依存関係が来る,という情報を持ってスレッドを追いかけていくことで,「スレッドAの6行目からの依存関係はありえない」というようにスライスの正確性をできるだけ保持しようとする.

O. Tkachuk, M. Dwyer:Adapting Side Effects Analysis for Modular Program Model Checking

ある検証範囲を設定して,その中での Side Effect を抽出しようというもの.ここでの Side Effect というのは「データの変化」っぽいのだが.将来的には,連動するクラスを勝手に探すとかいうのも考えているらしい.

_ 論文

FSE 2003 論文その2.

FSE Session IV: Software Process and Workflow

M. Muller, F. Padbera:On the Economic Evaluation of XP Projects

XP が儲かるか?という話.経済モデルとして,Net Present Value Model (だったか?):現在の1$ > 翌年の1$+Discount Rate という計算を考えて,

XPは「ペアプログラミングなので開発は少し遅れる」,普通の方法は「品質がXPより少し下がるのでその品質保証分作業時間が必要」というSpeed Factor, Defect Factor という二つのパラメータを考えて,パラメータの変化でどのくらい得られる金額が変わるかを計算した論文.ある程度の Speed Factor と Defect Factor があるなら,Market Pressure が大きくなると(Discount Rate が上がると)XP のほうが儲かりやすくなるらしい.

Communication Overhead を考慮していなかったり,どうやって二つのパラメータを推定するんだ,とかモデルにも色々な問題はあるのだが,最初に言ったという意味ではすごくえらいと思う.

_ 論文

続いて,FSE 2003 の論文整理.

FSE Session I: Requirements Engineering and Design

S. Uchitel, J. Kramer, J. Magee:Behaviour Model Elaboration using Partial Labelled Transition Systems

仮定,制約 から シナリオ(シーケンス図)を書いて,それを読んで Labelled Transition Model を生成して解析しましょう,というもの.

従来は,モデルに書いてあるものは許可,書いてないものは禁止,だったのだが今度は許可と禁止は明示して,そうでないものは Undefined として,状態変数と,シナリオごとの事前条件から,「この状態ではこういう遷移の選択肢があるけど,これは未定義だよ」とユーザにフィードバックをしようというもの.設計フェイズで使うと面白そうなツール.わりと実用的に見えたけど,どうなんだろう.

R. Jeffords, C. Heitmeyer:A Proof Strategy for Efficient Verification of Requirements Specifications Using Composition and Invariants

全然よくは分かっていないのだが,検証コストが高いものを,Σ → Σ1 + Σ2 に分解してから個別に検証をかけよう,という Compositional Approach という言葉だけが印象に残った.最近,スケーラビリティが問題になることが多いせいだろうか.

_ 論文

IWPSE2003 論文整理その4.

Ahmed E. Hassan, Richard C. Holt:The Chaos of Software Development

ある一定の期間の,ファイル変更回数を「各ファイルが変更される確率」とみなして,Entropy を計算する.変更が特定ファイルにかたまるほど Entropy が下がる.正規化する都合上,ファイル数が増えると Entropy が小さくなるので変更される Active Set のサイズで見よう,とか言っている.ちなみに,期間はリリース回数や時間,変更回数などで見る.Future Work として,複雑度 Metrics との対応や,リファクタリングやアスペクト抽出の手がかりなどを挙げていた.

John Champaign, Andrew Malton, Xinyi Dong:Stability and Volatility in the Linux Kernel

変更されてリリースされた回数÷総リリース回数 で得られる確率から,「変更される確率」を予測しようという話があって,それを Linux Kernel に適用したらあまり合ってなかった,らしい.予測しようというだけえらいいとは思うのだが,もうちょっと考える必要があるのかもしれない.

_ 論文

IWPSE2003 の論文整理その3.

Reeigineering a PC-based System into the mobile Device Product Line

PC上で動かす City Guide アプリケーション(JDK1.4, J2SE)をMobile デバイス用の J2ME or J2SE(しかもディスプレイやメモリも制限される)上で動作させる.XVCL でメタコンポーネントを作って,目的デバイスに合わせたコードを生成するようにした.

個々のコンポーネントを作るのは,コンポーネントの数または大きさが増加するし,共有コードをうまく扱えないし,冗長で無駄が多いので,メタ情報を使ったほうがよい.実行時アーキテクチャと開発時のアーキテクチャは別物.実行時: Components, Connectors, ...開発時: 変更をどう扱うかunit of change != unit of execution

C. O'Reilly, P. Morrow and D. Bustard:Lightweight Prevention of Architectural Erosion

ソース変更→依存関係の変化,をビューアで見ようとかいうものらしい.ArchAngel というツールを実装しているあたりは偉い.

_ How History Justifies System Architecture (or not)

変更履歴 → 同時に変更された Entity → Couplings Metricsを計算する.ソースコードから,抜き出す情報は,クラス名やメソッド名と,その行番号の対応だけ.その範囲の行が変更されたら,メソッドが変更されたとみなす.

Coupling を dotplot (クローンの場合と違って多段階だが) で表す.A が10回,Bが4回変更されていて,同時に変更されたのが3回なら,A→B は 30%,B→A は75%の結合度となるので,非対称の絵になる.絵の中で,結合度がある区画にまとまっているほどモジュールの強度が良いということになる.また,エディタ上での変更に対して,この結合度を使って変更波及可能性を出したりしてプログラマの支援を行う.

_ 論文

IWPSE2003 の論文整理その2.

Using Coordination Contracts for Flexible Adaptation to Changing Business RulesM. Wermelinger et al.

Service を computation interface (機能の実装)とconfiguration interface (必要な条件パラメータを返す)という二つのinterface を持つものと考えて,Coordination Contracts を記述する.Coordination Contract は,サービスに対するメソッド呼び出しに対して,Configuration インタフェースを使って条件をテストし,when ... do {} という書き方で Dynamic AOP 的に手続きを実行する.Instance ベースで,システムを止めずに BR を追加できたりするらしい.

Dynamic Behavior and Protocol Models for Incremental Changes among a Set of Collaborative ObjectsNguyen Truong Thang, Takuya Katayama

1 concern = 1 collaboration と考えて,Separation of Concerns を実践する.incremental change を collaboration の追加と考えて,モジュールとして扱う.別々に定義した collaboration を形式的手法で合成するらしい.

Class Refinement for Software EvolutionHiroyuki Ozaki, Katsuhiko Gondow, Takuya Katayama

クラスの継承は「Class Refinement (機能の変更)」と「Augmentation (オーバーライドなしの継承)」に区分できる.CLASSICJAVA (Javaのサブセットらしい)上でA# を拡張した A と B# を拡張した B があるとき,A# と B# の Augmentation の関係があり, A と B に Augmentation であるときにA# + B# が A + B と Augmentation であることを形式的に示すらしい.インスタンス変数が親子クラス間で共有していないこと,といった微妙な制約だけでよいらしい.CLASSICJAVA については Flatt, Krishnamurthi, Fellenisen, "Classes and mixins", POPL 98, を参照.

_ 論文

IWPSE 論文の整理その1.

Reconstruction of Successful Software Evolution Using Code Clone DetectionF. Van Rysselberghe and S. Demeyer

バージョン間のクローンを解析して,システム内部の変更なしのコピーを識別したりリファクタリングの手がかりを得よう,dotplot による可視化で,メソッドの移動などを識別したりコードクローンの exact マッチからメソッド抽出リファクタリングなどをしようという話.発表の後で本人に聞いてみたら,クローンの図にはパッケージ単位などではなくシステム全体を使うらしく,「100 万行くらいになったら小さいクローンはどうするの?」と聞いたら,「難しい,困ってる」という感じで返ってきた.ちなみにクローン識別には Duploc を使ってるらしい.「違いを見つける」ことで「同じところを見つける」らしい.

Beyond the Refactoring Browser: Advanced Tool Support for Software RefactoringT. Mens, T. Tourwe, and F. Munoz

リファクタリングは,1. リファクタリングをするべきか,2. どこにどのリファクタリングをするのか,3. リファクタリング作業,4. リファクタリングの効果を評価,という4ステップで実行される.ここで,論理型言語で「使われていないパラメータが存在する」などといった「不吉な臭い」述語を記述しておいて,それらがtrue になったらリファクタリングを提案する.小さなリファクタリング(メソッドの移動,名前の変更,etc)の組み合わせでリファクタリングを実行する.また,メトリクスを使ってその効果を計る(あくまでリファクタリング終了後に効果を計るだけの様子で,別に「どのリファクタリングが効果的か」というのを示すわけではない).また,リファクタリング作業が終わると,述語を再評価して新たなリファクタリング候補を提示する.

_ 論文

論文の題目が長くなって,ページのヘッダに登場する部分がページ番号と重なるなぁ,と困っていたら,ipsjpapers.sty 的には title タグを\title[ページのヘッダに出したい題目]{先頭ページの題目}と書けば通るらしい(サンプルを見ていて気付いた).微妙な仕様だ.


2003-09-09 古い日記からの変換データ [長年日記]

_ LotR

どうやら誤植訂正は,お馬さんや Warg の Strength の修正だけらしい.ルールに関しては,長い持続時間の呪文のペナルティが累積していく問題が修正された.

BRGx1時間より長い持続時間であるような呪文に関しては,夜明けの時点で,持続中の呪文によるペナルティが消える.また,Sorcery に関しては夜明けのかわりに日没がその条件になる.持続が "集中" の呪文は,この処理の対象とはならず,効果が持続している間,ペナルティとなる.

_ 論文

Behaviroral Specification メモその3.

SDL とかのはなし.http://www.cs.rutgers.edu/~shklar/www11/final_submissions/paper5.pdf

Component Protocols/Sequencing Constraints Bibliographyhttp://www.cs.washington.edu/homes/taoxie/sequencing.htm

実行時の振舞いからコンポーネントの使い方を見つけるhttp://www.cs.ualberta.ca/~stroulia/Papers/KDD2002.pdf

Integrating Behavior Protocols in Enterprise Java BeansEJBで,メソッドの呼び出し順序などをステートマシンで表現して静的・動的にチェックしましょうという話.http://www.emn.fr/x-info/afarias/docs/farias-geheneuc-sudholt2002integrating.pdf同じ人の別論文. http://www.emn.fr/x-info/afarias/docs/doa2002.pdfこの人,メソッド呼び出し順序だけに「状態」を限定しているのかな?

Bandera: Extracting Finite-state Models from Java Source Code

Rediscovering Workflow Models from Event-Based Data http://cnts.uia.ac.be/benelearn2001/proceedings/bene01-weyters.pdf

S. Butkevich, M. Renedo, G. Baumgartner, and M. Young. Compiler and tool support for debugging object protocols. FSE 2000 http://www.cis.ohio-state.edu/~gb/Brew/Publications/Protocols.pdf

_ 論文

Behavioral Specification 関連情報その2.

Behavioral Specification Walk-thru

What should the behavior spec include?- How does the component act in every defined situation?- How does it change its functional state?- How does it restrict state changes?- How does it maintain its internal state variables?- If it is a physical object, what is the physics of its performance?- How are its output requirements met?- How are its constraints met (if applicable)- How are potentially dangerous states/commands handled?- How are any potential ambiguities in the command structure handled?- Once this is done ask yourself - does it meet its safety and performance objectives?

どうやら,動作仕様というのは「全部」書くもので,最小限の制約記述ではないらしい?

Functional and Non-Functional Contracts Support for Component-Oriented Programminghttp://www.ccs.neu.edu/home/lorenz/oopsla2001/53_Collet.pdf

Deploying Non-Functional Aspects by Contractcontract 記述でコンポーネントが従う QoS 情報などを指定する.オブジェクトはそのままで,Contract だけを差し替えることが可能?http://www.cs.wustl.edu/~corsaro/papers/RM2003/p1-sztajnberg.pdf

Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programmingオブジェクトの振る舞いを記述する.振る舞いの記述は,一般に,プロセッサ・回路設計,通信プロトコル合成などで使われている

http://www.objs.com/x3h7/sec24.htm

ステートマシンを使って,コンポーネントの合成結果の一貫性を調べるものは既にあるらしい.でも,ステートを全部記述するのは「実用的ではない」という気がする.

http://www.uni-paderborn.de/cs/ag-engels/Papers/2002/IDPT-Pasadena.pdfConsistent Interaction of Software ComponentsGregor Engels and Jochen M. K¨ uster

_ 論文

Behavioral Specification 関連の話をメモ一式.なんか適当だ.

Larch/C++ インタフェース記述言語:http://www.cs.iastate.edu/~leavens/larchc++.htmlドキュメントコメント形式で,各メソッドの事前条件と事後条件を記述できる.

通常,事前・事後条件は,各メソッドの開始と終了にだけ言及する.インタフェース記述であり,実装に関する言及は行わない.

http://www.i3s.unice.fr/~map/WEBSPORTS/1999a2002.htmlBehavioral specification of Java component using SyncCharts.コンポーネントの振る舞いの仕様を記述しようというもの.

Isabelle Ryl and Mireille Clerbout and Arnaud Bailly:A Component Oriented Notation for BehavioralSpecification and Validationhttp://www.cs.iastate.edu/~leavens/SAVCBS/2001/papers-2001/ryl-clerbout-bailly.pdf

コンポーネントの仕様をIDLで記述する,特にメソッドごとの振る舞いについても記述されている.

_ LotR

8月11日付で更新が出ていた.とりあえず,後で確認することにする.

_ マイレージ

海外出張一回分で,ANA マイレージが13000マイルほどたまった.やっぱり国内移動に使う分って誤差?

_ JML

Gary T. Leavens, Albet L. Baker, Clyde Ruby:JML: A Notation for Detailed Designを読んだ.各クラスの仕様を /*@ @*/ コメントとして記述しておく.記述言語が Java に特化されており,Eiffel の Pre/Post Condition に加えてnormal behavior と exceptional behavior を分けて書いたり,モデル上でのみ有効な型や変数を定義したり,必要なら実装上の変数にマップできたり,といった色々な機能が使えるらしい.これと Protocol 系の定義を組み合わせたらかなりのレベルまで詳細な仕様記述が書けそう.


2003-09-10 古い日記からの変換データ [長年日記]

_ ODINS

ネットワークが不安定だと,Web 上にある資料が取れなくて仕事にならない.

ネットワークなければただの人か.仕方がないので,OO2003 に出した原稿の英語論文化をぼちぼち進める.


2003-09-11 古い日記からの変換データ [長年日記]

_ AspectJ

アクセス解析を見ると,世の中のOS・ブラウザ普及率が何となくわかる.

それにしても,ドメイン名に有名企業 or 大学が多い :-)

_ 論文

Dataflow pointcut に関しては増原先生の論文が APLAS'03 に出るらしい.11月らしいのでメモしておく.連絡して論文送ってもらうようお願いしたほうが早い気もするけど :-)

_ 論文

Mitchell Wand, Gregor Kiczales, Christopher Dotchyn:A Semantics for Advice and Dynamic Join Points in Aspect-Oriented ProgrammingACM Transactions on Programming Languages and Systems

Workshop on Foundations of Aspect-Oriented Languages (FOAL2002) に登場した論文の改良版(?)らしい.

アドバイスをλ抽象で記述したりしているのを見ていると,Dataflow Pointcut なんかもこうやって記述される日が来るのだろうか.でも,control flow はスタックでいいとして,data flow はどうやって表現するのが正解なのだろう.

_ 論文

Jianjun Zhao:"Unit Testing for Aspect-Oriented Programs" を読む.

AspectJ なプログラムを Unit Test するには?ということで書いてるのだが,アスペクトは全部織り込んだ状態でテストするのだろうか.複数のアスペクトが揃わないと動作しないようなアスペクトはそれでいいのだが,オブジェクトに対するテストケースはアスペクトの存在を仮定していてもよいのか?とか,逆にアスペクト単体のテストケースは考えなくてよいのか?とか微妙な話も出てくる.アスペクトがモデルの中のものを表現しているかそうでないかで変わってきそう.

_ 論文

査読の手伝いをしている間に教えてもらった論文.

白鳥則郎,高橋薫,野口正一:NESDEL: プロトコル向き仕様記述言語とその応用情報処理学会論文誌 Vol.26, No.6, pp.1136-1144, Nov. (1985)

有向グラフ(状態機械など)でプロトコル仕様を表現する試みはあるが,それにプリミティブ記述というプログラミング言語のような記述子を加えることで曖昧さを取り払っている.言語だけの記述に比べると,階層的なグラフによる図示がプロトコルの理解容易性に寄与している,らしい.

昔からこんなことやってる人はいるんだなぁ,と感心.


2003-09-12 古い日記からの変換データ [長年日記]

_ 定年

親の定年&再就職が決まったらしい.良かった良かった.重工業系な営業の人なので,それに相応しく(?)行き先は土木コンサルタント.そんな仕事もあるのね,とちょっと感心.

_ 論文

Thomas Reps, Susan Horwitz, and Mooly Sagiv:Precise Interprocedural Dataflow Analysis via Graph Reachability

データフロー解析を調べていて見つけた論文.どっかで見た図が載っていたので,輪講で以前紹介されたものかも.読む時間がないのでとりあえず置いておく.

_ goo mail

mail.goo.ne.jp な人が,どうも返信で ML に投稿してるような気配があるのだが,References や In-Reply-To ヘッダが付いていない.スレッドがつながって欲しくない場面なので別にいいのだが,スレッドつなげておいてほしいときに切れてしまうと,後で MHonArc でインデクス付けるときに困る.


2003-09-15 古い日記からの変換データ [長年日記]

_ 新マシン

小型ケースなのでファンが貧弱(ちなみに電源はACアダプタ),放熱が大丈夫なのかなーと思ってたら,ケース全体の熱伝導性がかなり良いようで長時間は触っていられない熱さになっている.こう熱いと上に変なものを載せられないので,微妙に置き場所が難しい.

_ 読書

本を整理していて,そういえばそろそろエリザベス・ヘイドン「ラプソディ」の第3部が出るはずだなぁ,と思っていたら,もう発売されていたらしい.タイトルは「デスティニィ -大空の子-」.時間が取れ次第買いに行くことにする.

_ 新マシンの続き

結局,・Pentium 4 1.5(?)GHz・マザーボード+ミドルタワーケース・サウンドブラスター PCI Digital・3COM の LAN カード・SCSI 9GB ハードディスク・IDE 8GB ハードディスク・DVD-ROM ドライブ・ATI All-In-Wonder (初代)などが余った.サウンドも VGA もオンボードで満足してるのでこのあたりは部室に移動か.誰かに売り払うほうがいいといえばいいのだが.

_ 新マシン

F-Force というよさげなベアボーンを見つけたので,これを機会にデスクトップを小型化.Pentium 4 2.6GHz + DDR 512MB という,派手さはないがサイズに比べると強力な構成.

これで,かつての Atropos(NLX), Lachesis(Let's Note), Clotho (ATX) が全員お払い箱になった.

新しいマシンの名前は lazulite (天藍石).さて,あとは MS Blaster に気をつけながらWindows Update のお時間.間にルータがあるから大丈夫かな?


2003-09-16 古い日記からの変換データ [長年日記]

_ 論文

AAOS2003 からもうひとつ.

Maximilian Storzer, Jens Krinke, Silvia Breu:Trace Analysis for Aspect Application

以前ざっと見て役に立つのかなーと思って流してたのだが,実はJens Krinke ってコードクローンな研究してる人だったような気がしたり,いくつか気になったのでちゃんと読み直し.

アスペクトの影響を調べるために実行トレースの差分を取ってやろう,というもの.実行トレースを用いる都合上,「たまたまアスペクトが貼り付いていない」場所などは認識できないという問題はあるが,どのメソッドが呼ばれるように/呼ばれないようになった,とか調べることができる.

もちろん,条件はシステムが同じ入力を受け取ること,同じ入力には同じ動作をする(ランダムな振る舞いをしない)こと.

マルチスレッドな場合も,ちゃんとスレッドの区別だけしてれば大丈夫らしい.

システムを改造しても(たとえばアスペクトの抽出をしても)セマンティクスさえ同じなら実行トレースは同じはずだ,と言っているけど,クラス名なんかの変化をどうやって扱う気なんだろう(このあたりは特に記述はない).

アスペクト指向なプログラムにおけるデータフロー解析の研究はまだ十分ではないので,static analysis を支援するのにこういう実行時解析を使いましょう,とも言っている.たしかに,実現は楽かも.

_ 論文

Analysis of Aspect-Oriented Software (AAOS2003) より:

A. M. Reina, J. Torres, M. Toro:Aspect-Oriented Web Development vs.Non Aspect-Oriented Web Development

Cocoon2 と AspectJ で同じ Web Application を開発して比較したという論文.

比較されているのはユーザ認証と引数チェックだけだが,結果として,・Cocoon2 は XML で制御されているので,簡単に書けるけど 局所性は完全ではない・AspectJ は局所性はうまく行ってるけど,見易さという意味では Cocoon2 にはかなわないという結果となった.Cocoon2 のほうが Domain-Specific だと考えればわりと妥当な結果である.

理想系は「強力な(高い抽象度記述が可能な)AspectJみたいなアスペクトを使ったフレームワークがあること」なんだろうなぁ.分散した(Scattered)記述を管理するためのツールさえあれば,ある程度はうまくいくのだろうけど,

_ Aspect Browser

Aspect Browser: Aspect Emacs and Nebuloushttp://www.cs.ucsd.edu/users/wgg/Software/AB/を試してみる.

grep (正規表現あり)の結果を色づけマーキングしてソースコードを縮小表示するツール.JDK1.3 でないと動かなかったり,画面描画もちょっと怪しかったりするが.

マッチした部分が重なったときに色を組み合わせて表示できないところが,少し物足りない.が,「こんなに同じ行が登場してるよ」とリスト表示してくれる機能は面白い.Eclipse プラグイン化するらしいので,それに伴ってユーザインタフェースがもう少し洗練されたらちゃんと使えるツールになるかも.

_ 論文

論文のアブストラクトの文字数制限が気になって調べてみた.投稿規程によると,情報処理学会の場合はAbstract 和文600字/英文200Words らしい.意外と長い.


2003-09-17 古い日記からの変換データ [長年日記]

_ AOSD

ようやく AOSD2004 の Call for Contribution が更新された.Full Paper は 10 ページらしい.おかげで,日本語論文ではかなりカットした原稿までフルに載せられそう(載せないといけない,という意味でもあるが).

_ Java

JScrollPane に載せたテキストコンポーネントにファイルをロードしてもスクロールバーが有効にならない,のはスクロールバーを revalidate すればいける,と教えてもらった.

_ 読書

研究室で,金出 武雄「素人のように考え,玄人のように実行する」を読む.先生のお勧めらしい.

研究に対する考え方やプレゼン,英語や教育の話までわりと幅広く扱っていて面白い.ちょっと,自慢話も多いが.

_ 読書

エリザベス・ヘイドン「デスティニィ -大空の子-(上)」読了.だいぶ<予言>が消化されてきた感じがするが,クライマックスに向けての伏線張りもまだ続いている.

_ JST

科学技術振興事業団 (Japan Science and Technology Corporation)→科学技術振興機構 (Japan Science and Technology Agency)と変わるよー,という通達が届いた.英語の略称は変わらないらしい.日本語の略称はどうなるんだろう.


2003-09-18 古い日記からの変換データ [長年日記]

_ C言語

cppll で紹介されてたのを見て知ったのだが,これの発売元,日経BPなのかぁ.色々やってるなぁと感心.http://edu.stackart.net/c/c_seihin.html

_ 論文

OO2003 の論文を refine したものを特集論文に投稿.ようやく片付いたのでAOSDの原稿に専念できる.

_ 読書

エリザベス・ヘイドン「デスティニィ -大空の子- (下)」読了.ようやく無事完結.一巻から登場していたメリディオンの正体も分かったし,見事に伏線は全部消化されていた.第一部の前半こそ退屈だったけど,それ以外はいい作品だったかも.後半は特に予言の成就がファンタジーらしくていいなぁ.

フドールの与える疑惑の正体に気付いたりできるあたりファンタジー系の "お約束" に慣れすぎなのかも.でも,言霊使い「らしい」話ではあるので,TRPG のシナリオでも使ってみたいネタではある.


2003-09-19 古い日記からの変換データ [長年日記]

_ TV

アルファデータのAD-POPTVを購入.電源OFF状態ではディスプレイ・オーディオ信号素通しで,ON にするとテレビ画像をディスプレイ信号に重ね合わせ or 置き換えをするという,かなり面白い品物.

明らかにUSB2系統のものより使いやすいので,これをメインに使っていくことに決定.


2003-09-20 古い日記からの変換データ [長年日記]

_ mail

メールアドレスの登録変更ができるのかなーと思って某ソフト会社のWebサイトへ行ったら,メールアドレスだけは変更できなかった.IDに使ってるらしい.仕方がないので,メール配信を停止させた.


2003-09-21 古い日記からの変換データ [長年日記]

_ NIS

Network Infomation Service ではなく,Norton Internet Security 2004 のアップグレード案内が届く.今回は5300円.なんか税金みたいに取られていくが,頻繁に(ほぼ毎日)移動するノートPCだといつ感染するか分からないので投資としては妥当な金額か.

デスクトップのほうはルータで守られているので放置の方針.

_ LaTeX

ニ段組ぶち抜きの表や図はfigure* や table* らしい.なぜ "*" なのかはよく分からない.eqnarray* は数式の番号省略だし.Windows API の ...Ex みたいなものだろうか.

_ AspectJ

最近,AspectJ 関連の話題がほとんどない気がする.メーリングリストでも既出の問題やバグ修正やらがほとんどだし.

早く増原先生の論文が読みたいところ.

_ DupChecker

DupChecker 1.0.2 にバージョンアップ.1.0.1 では複数のビューの連動が怪しかったので,モデルオブジェクトから Listener に対してイベントを発行して再描画するように修正した.

DupChecker 公開ページ

_ 読書

茅田砂胡「女王と海賊・暁の天使たち5」読了.もう5巻.シリーズ刊行が早い.それにしても,完全にスカーレット・ウィザードの続き話になって本編で新登場したキャラクターの立場が薄いのが少し残念.


2003-09-22 古い日記からの変換データ [長年日記]

_ 読書

ウィルススキャンをしている間が暇なので,Essential Java Style: Patterns for Implementation を読む.

コーディングで使えるテクニック(メソッドオブジェクト,デフォルト設定を返す関数, 二つのオブジェクトのどちらが主体でどちらが引数になるか, などなど)が色々書いてあって面白い.

正しい設計に組み合わせないと逆にひどいコードになりそうではあるけど.


2003-09-23 古い日記からの変換データ [長年日記]

_ 読書

水野良「砂塵の国の魔法戦士」読了.以前からの伏線(魔法戦士リウイシリーズ)が長かったのでもう半分以上状況は忘れてた気もするが,あとがきによれば,次回作では "ファーラムの剣" など,ソードワールド初期からの設定が関わってくるらしいし,アトンのせいで止められていた新王国歴521年以降にようやく踏み込んでいくらしい.かなり期待.

_ PDA

愛用の Genio e550G の液晶フィルタを交換.筆圧が高いせいか,文字入力部分はぼろぼろになっていた.もう少し大事に使いたいところ.

_ ゲーム

ある意味伝説のゲームであるメガドライブの「マイケルジャクソン's ムーンウォーカー」を部室に入荷させる.3500円.

_ TRPG

トーキョーN◎VA the Detonation 購入.世界設定は the Revolution のときに比べて使いやすそうなので少し期待している.ルールの変化をちゃんと把握しないといけないけど.

_ 読書

秋田禎信「我が聖域に開け扉(下)」読了.9年越し,20巻目にしてようやく完結.

最終的な解決方法はわりと妥当な感じ.でも,真相解明~エンディングまでがちょっと短すぎるような気はする.やっぱり作品の長さに対して発愛の都合とかもあって構成が難しいんだろうか.

_ AspectJ

Macneil Shonle という人の報告によれば,(AspectJ-dev ML)AJDT では,まだ Organize Import が動作しないらしい.単に AspectJ の構文解析ができないせいらしいが.もっとも, import 文の自動生成は,以前,パッケージ名が異なりクラス名が同一であるようなクラス名に対しての処理が甘くてファイル全部壊されたので,あまり使う気が起きない.

あとは,set* のようなワイルドカードが,ソース整形したときにトークン単位で set * のように分離されて構文エラーになるとか.もうちょっと,良い表記法があればいいのだけど.

_ AspectJ

AJDT も AspectJ 1.1.1 に合わせてバージョンアップ.こっちは 1.1.4.(1.1.2 まではRelease Candidate で使ったので番号がずれている)

Mac OS X にも対応したらしい.(今までは Swing にくっついてた実装があったらしい)

_ Acrobat

結局,CDチェックはアップグレード確認用だったので,Acrobat 5 をネットワークインストール→ Acrobat 6 のインストーラをネットワークで起動→ Acrobat 5 をアンインストール→ Acrobat 6 のインストーラをもう1回起動で通った.やれやれ.

_ AspectJ

Acrobat のことで少し機嫌が悪くなってたが,AspectJ 1.1.1 リリースの報にちょっと機嫌が良くなった.

_ Acrobat

Adobe Acrobat 6 が起動しなくなった(プラグインを全部読み込んだ後,何も言わずにクラッシュする)ので再インストールしようとしたら,「CDのチェック」で直接接続されたCDドライブしか認識しようとしないので,インストールできない.

大学に置いたままの USB 接続ドライブを使うしかないのか…….今さらCDチェックなんてあるとは思ってなかったのだが.一時的に Adobe Reader を入れるのも癪だしなぁ.


2003-09-24 古い日記からの変換データ [長年日記]

_ 読書

研究室に転がっていたので,飯久保廣嗣「質問力 -論理的に考えるためのトレーニング-」を読んでみた.

「なぜ?」と質問すること,複数の候補を考えること,問題の優先度,緊急度,拡大傾向,情報の信頼度とリスク,といったわりと普通な(と思ってるだけでやってる人は少なそうな)ことがいろいろ列挙されていた.悪い例・良い例が実例ベースで解説されているところが面白い.


2003-09-25 古い日記からの変換データ [長年日記]

_ AspectJ

AspectJ 関連情報の過去のニュース&更新履歴を別ファイルに移行.

_ Java

Java の言語仕様に AOP を取り込むことを考えている,とかいう微妙な記事.熱心なのは JBoss と IBM の人々らしいが,どうするんだろう.取り込まれるのは AOP であってAspectJ ではないので,どういう形式になるかによって実用的かどうかが決まってきそう.http://news.com.com/2100-1007_3-5081831.html

_ 論文

The Computer Journal Special Issue on AOP and Crosscutting ConcernsVolume 46, Issue 5, September 2003がオンラインからアクセス可能になったよーとaosd-announce でアナウンスされてた.

http://www3.oup.co.uk/computer_journal/current/

リストを見た限りでは,どこかで見たことがあるものばかり.

_ AspectJ

久しぶりに AspectJ サイトを更新.http://www.early-aspects.net へのリンクの追加と,「共有インスタンスの監視」の追加.元ネタは AspectJ-users ML の"Static Crosscutting" という Eric Jain の投稿で,ちょっとだけ c.getChlidren().add(o) っていう add は監視できないのかなぁ,と書いてたのでそこから考えてみた.Dataflow pointcut とかがあったら,もっと綺麗に書けるのだろうか?

_ クレジット

クレジットカードの利用金額が予想より大きかったので,なぜだろうと思ってたら8月のOO2003出張のときのホテル代が入ってた.IWPSE/FSE出張のせいで,すっかり忘れてた.


2003-09-26 古い日記からの変換データ [長年日記]

_ OO2003

赤坂さんがOO2003でのアスペクト指向関連のセッションのレポート記事を書いてた.自分のも載ってた.http://www.ogis-ri.co.jp/otc/hiroba/Report/OOSympo2003/aspect.html

_ Acrobat

また Acrobat が起動しないなーと思っていたら,原因は Sharp E/J Manager の「アドイン翻訳」機能がAcrobat 6 に非対応だったのに,アップグレードしたときにまた翻訳機能が ON になったせいだったらしい.


2003-09-27 古い日記からの変換データ [長年日記]

_ 紅茶

アッサム・ディコムを100g仕入れる.涼しくなってきたので,また紅茶の消費量が増えてきた.

_ Ys6

待望の(?)イース6購入.PC-8801MH 以来全部遊んできたシリーズだから,つい買ってしまう.

_ 予約

和 DINING ひいきや での夕食予約.ぐるなびから予約したのに,通ってなかったので電話を入れた.せっかくディジタルな世界なのに処理がアナログだから結局意味がない.http://r.gnavi.co.jp/k025913/menu1.htm

3人という少人数で行くのであまり問題ないが,システムとしては,あまりいけてない.

_ 論文

論文の査読の手伝いのために,生物学,生化学の資料を漁る.バイオ情報系な話なので,ボキャブラリが乏しい点がつらい.

_ レーサーミニ四駆

レーサーミニ四駆ジャパンカップ攻略用セッティングメモ

レーサーミニ四駆ジャパンカップ(ファミコン)のセッティングを作ってしまった.あまり暇でもないんだけど.


2003-09-28 古い日記からの変換データ [長年日記]

_ 論文

査読が一区切りついたので,集めた情報を先生に投げる.

こんなのとかを参考にして読み進めた.これだけ見ると,全然ソフトウェアとは関係ない.http://xakimich.hp.infoseek.co.jp/pharmacology/node11.html

_ 部室LAN

DNS設定が(なぜか)DHCPで取れなくて,しかもIPが設定したはずの値と違うなーと思っていたら,昔,学祭に使ったノートPCがDHCPサービスを自動で立ち上げていた.


2003-09-29 古い日記からの変換データ [長年日記]

_ プログラムスライス

プログラムスライスのツールがほしいという人がいたらしくて,教授に紹介された.ドキュメントのアップデートがまだ済んでないので,さっさと作ってしまわないといけなくなった.

_ レーサーミニ四駆

苦労のかいあって,渡したセッティング+αでクリアしてもらった.買ってから十何年かかったのかぁ.

_ pdftotext

あまり時間をかけても仕方ないし,pdftotext -raw で実用に比較的近いものが出てくるようなので妥協することにした.それでも改行時の "-" 取ったりとか適当な文の切れ目を見つけたりとか,色々やることはあるんだけど.

_ PDF2TEXT

PDF2Text Batch バージョンなんてものがあったから試してみたが,"ff" などの特定の文字並びが一部文字化けする上ニ段組の解決もしてないので,全然役に立たない.http://www.traction-software.co.uk/pdf2textBatch/index.html

_ PDF2ASCII

pdf2ascii ってないんだなーと思っていたら pdftotext だった.PDF から英語論文のコーパスを作ってみたいのだが,ニ段組がそのままの形で出力されてしまうのが難点.

_ 書類

午前中に時間指定されたアルバイト用の書類作りも無事修了.「言った通りの時間に忘れずに来るので,信頼度が高い」と言われる.

_ 論文

Frank Hunleth, Ron Cytron, and Christopher Gill:Building Customizable Middleware using Aspect-Oriented Programming

分散アプリケーションのミドルウェアでアスペクト指向を使おうというshort paper.CORBA を使っているので,AspectIDL とかいうのを考えていたらしい.アスペクトがミドルウェアの実装とテストフレームワークを横断している図にちょっと興味を惹かれた.

_ 論文

AspectJ のイディオムを整理した論文.前の Idioms for Building Software Framworks in AspectJ を包含して,Marker Interface が新しく加わっている.

Stefan Hanenberg, Rainer Unland:AspectJ Idioms for Aspect-Oriented Software Constructionhttp://www.cs.uni-essen.de/dawis/publications/papers/aop/2003_HSU_AspectJIdioms_EuroPLOP_2003.pdf

こっちのほうが refer するには良さそう.Hanenberg, S., Schmidmeier, A.: AspectJ Idioms for Aspect-Oriented Software Construction, Proceedings of 8th European Conference on Pattern Languages of Programs (EuroPLoP), Irsee, Germany, 25th–29th June, 2003

このあたりも,一度サイトに整理してみようかなぁ.

_ 論文

Stefan Hanenberg, Pascal Costanza:Connecting Aspects in AspectJ: Strategies vs. Patterns

AspectJ の機能を整理している論文.アスペクトをどのようにアプリケーションに接続していくか,という Strategy (パターンではなくて戦略)の話.

アスペクト・アプリケーション間の接続に利用可能な Strategy を,次のように規定している.

Static Crosscutting:

・クラスの先祖を直接追加

・クラスのメンバーを直接追加

・アスペクトの影響を受けたコンテナと 接続するアスペクト(間接的な振る舞いの追加)

Dynamic Crosscutting:

・直接,pointcut で接続・アスペクトが接続されたコンテナに,オブジェクトを接続

・具象アスペクトが抽象 pointcut を再定義して接続

・独立した pointcut 同士を組み合わせて接続

それぞれ,どんなメリットがあるかを記述しているのでデザインパターンに似ているのだが,この人たちはあえて Strategy という言葉を使っているらしい.

Strategy と Idiom, Pattern の区別として,Idiom は特定言語の実装例のこと,Pattern は,使うことで品質が保証されたりといった利益があるものである,という立場を取っている.

_ 論文

前に読んだ論文の読み直し.

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

子アスペクトが,動作すべきかどうかを boolean 値で返して,true のときのみアドバイスが動作する pointcut method,というイディオムがあるのだが,pointcut method が副作用を持っていると問題が起こる場合があるので,それを防止する策と一緒に使わないと困るのかなぁ,とふと思った.副作用について議論しようとすると,その過程で refer することになるかな?と思ったのでここに再掲しておくことにする.

_ AspectJ

ふと思い立ってGoogle で "AspectJ" で検索してみたら,日本語サイトだけなら2位,英語も含めても13位.だんだん順位が上がってきた."アスペクト指向" ではまだまだ developerWorks などにかなわないけど,論文などは10位以内に出るようになってきた.

_ AspectJ

こんなのもあるらしい.aosd-discuss で紹介されていた.The Aspect-Oriented Software Architecture Design Portalhttp://trese.cs.utwente.nl/taosad/

どこかで見た URL だと思っているのだが,Early Aspects の Workshop を去年くらいに開催したところのような気がする.

_ AspectJ

Wes Isberg のアスペクトをテストする話をサイトに追加.でも,アスペクトを本格的にテストしようとするとイベント列生成ツールとかが必要かもしれない.シーケンス図とかから自動生成できると格好いいかも?

_ Java

Java World 11月号にて,RandomAccess インタフェースの存在を初めて知った.メソッドのないマーカーインタフェースで,ランダムアクセスが高速であることを示すらしい.ArrayList とかが対応するのだが,aspect を使って RandomAccess インタフェースに対するアクセスだけを高速化するぜーとか叫ぶのに使えそう?


2003-09-30 古い日記からの変換データ [長年日記]

_ 論文

Hanenberg, S., Oberschulte, C., Unland, R.: Refactoring of Aspect-Oriented Software, Net.ObjectDays 2003, Erfurt, Germany, September 22-25, 2003

Aspect-aware Refactorings をしましょう,という論文.

call(class_name.set(*)) でアスペクトを貼り付けても,「メソッドの引き上げ」などのリファクタリングをしてしまうとアスペクトが効果を発揮しなくなってしまう.

メソッドの名前変更 (Rename Method):

C.foo から C.bar に変更した場合,pointcut も変更する必要がある.call(*.foo()) → call(*.foo()) || call(C.bar()); とか,call(*.bar()) → call(*.bar()) && !call(C.bar()); とか.

メソッドの抽出:

C.foo の一部を C.bar に抽出した場合,withincode を等価変換するには,次のように変更する必要がある.withincode(void *.foo(..)) → (withincode(void *.foo(..)) && !call(void C.bar(..))) ||(withincode(void C.bar(..)) && !execution(void C.bar(..)) && cflow(withincode(void C.foo(..))));

メソッドの移動:

C.foo から D.foo に移動した場合,target や this を変更する必要がある.pointcut x(C c): execution(void *.foo()) && this(c) → pointcut new_x(C c): execution(void *.foo()) && this(c);pointcut new_y(D d): execution(void D.foo()) && this(d);

アドバイスの抽出(Extract Advice):

this, target, args, などを使って元のメソッドを厳密に指定する.また,advice 自体は around を使って,メソッドの実装をコピーして,元のメソッドに残した部分だけをproceed に変えて,なるべく元の制御構造を維持するようにすると簡単.

Introduction の抽出(Extract Introduction):

こっちは,普通にメソッド定義をコピーし,頭に型名をつけるだけでよい.

Pointcut の分解 (Separate Pointcut):

pointcut 定義の共通部分だけをくくりだして別の pointcut にする.

で,この人たちは,Aspect-aware なリファクタリングをするためのツールを Eclipse プラグインとして作ったらしい.

主に名前と型情報関係だけで,cflow などは(実際に呼ばれるコンテキストが変わらない限り)影響を受けないので気にしなくてよいらしい.

_ 論文

Pascal Costanza:Dynamically Scoped Functions as the Essence of AOP

を読んでみた.Lexical Scope (定義位置に依存して変数の binding が決まる)と Dynamic Scope (実行時点に依存して変数の binding が決まる)の違いをCommon Lisp 的記述を使って説明している.

で,アスペクトの役割をdflet という述語を使ってdflet (関数などの再定義) (評価したい関数)という形で書いている.「評価したい関数」というのが変換元のプログラムのことで,「関数などの再定義」 がアドバイスに相当し,「評価したい関数」の中で呼んでいる関数を実行時バインディングで置き換える.

「関数などの再定義」をする dflet をどこに配置するかというのが,Pointcut の役割をしている.

「特定のポイントで関数のバインディングを変える」とみなすか「イベントに連動してまったく処理を行う」と考えるか,という違いのような気がするけれど,関数のバインディングと制限してるほうがちょっと範囲が狭くて,それで十分な範囲をカバーしているのか謎.

_ 論文

aosd-discuss で,次の記事のことが話題に上がっていた.

Pascal Costanza:Dynamically Scoped Functions as the Essence of AOPACM SIGPLAN Notices,Volume 38 , Issue 8, pp.29-36 (August 2003)http://portal.acm.org/citation.cfm?doid=944579.944587

この記事に対して,Kiczales が,「cflow を dynamically scoped functionとしてとらえるにしても,AOP はそれだけじゃないでしょ,たとえばメソッド呼び出し以外の join points だってあるんだから,云々」と言ってた.ということで,後で読んでみることにする.