netail.net

_ AspectJ ▲

アクセス解析を見ると，世の中のＯＳ・ブラウザ普及率が何となくわかる．

それにしても，ドメイン名に有名企業 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)

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

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

_ ODINS ▲

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

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

_ LotR ▲

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

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

_ 論文 ▲

Behaviroral Specification メモその３．

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 関連情報その２．

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 系の定義を組み合わせたらかなりのレベルまで詳細な仕様記述が書けそう．

_ 論文 ▲

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

_ 論文 ▲

FSE 2003 論文整理その５．

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 その４．正確には論文ではなく Invited Talk だけど．

Ari Jaaksi:Assessing Software Projects - Tools for Business Owners

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

_ 論文 ▲

FSE 2003 その３．

FSE Session V: Validation and Verification

J. Krinke:Context-Sensitive Slicing of Concurrent Programs

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

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

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

_ 論文 ▲

FSE 2003 論文その２．

FSE Session IV: Software Process and Workflow

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

XP が儲かるか？という話．経済モデルとして，Net Present Value Model （だったか？）:現在の１＄ ＞ 翌年の１＄＋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 論文整理その４．

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 の論文整理その３．

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 の論文整理その２．

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 論文の整理その１．

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

_ 論文 ▲

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

_ AspectJ ▲

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

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

_ FSE ▲

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

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

_ HTML Help ▲

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

_ Office ▲

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

_ FSE ▲

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