netail.net

_ AOSD Keynote ▲

Keynote 1:Aspects - From Promise to RealityDr Daniel Sabbah, Vice President, IBM Development and SWG Technology,Application Integration and Middleware Division,Software Group

AOSD を IBM では使ってます，という keynote．AspectJ の使い方としては，private な（バージョン依存の）API 呼び出しを禁止するといった渋い方法も．アスペクト干渉など，一部では問題が山積みのような気もするのだが，使い方次第，ということだろうか．実際の開発では，干渉っていうのはあんまり起きないのか，それとも干渉が起きないようにうまく書いているのか．

Java クラスを EJB コンポーネントとして動かすなんてこともやっているらしいので，たいしたもの．

ソフトウェア工学をきちんと教えるような体制が重要だよ，というところは主張していた．

質疑応答では，ドキュメントはどうしてますか，とかIBM は資源がいっぱいあるからいいけど，資源がない人はどこから始めるのでしょう，といったものが出ていた．これだ，という解決方法はどうも今のところないみたいだが．オブジェクト指向でもドキュメントなどが固まったのはだいぶ後になってからなので，アスペクト指向もそうなのかもしれない．

_ AOSD Tutorial ▲

Tutorial T5: Good AOP: Idioms, Rules and Patterns in AspectJWes Isberg, Adrian Colyer によるチュートリアル．

アスペクトは Role-based design に親和性が高く，デザインパターンには Role-base なものが多いらしい．

基本的には，「同時に変更されるようなコードは１つのモジュールに」というデザインが良いらしい．また，モジュールを abstract/concrete に分類したとき，concrete -> abstract という依存関係は OK だが，逆はよくない，という基準で作れ，とも言っていた．このあたり，わりと一般的ではある．

_ AOSD Tutorial ▲

Aspect の使い方として，・元の振る舞いを変えない検査など（Invariants の追加）・制約の付加（古いコードとの整合性チェックなど）・新しい join point 指定 (「JUnit テストの assert 前後」など）を挙げていた．

面白い idiom としては，次のようなものがあった．

"_" で始まるフィールド以外を禁止するdeclare error: set(* *) && !set(* _*)

あるインタフェースを implement しているすべてのクラスを検知する（implements している == クラス初期化コードが動くので検知できる）pointcut anyRunnableImplementation(): staticinitialization(IRunnable);

delegation を行うための this 差し替えpointcut delegationScope(D d): this(d);around(D d): delegationScope(d) { proceed(expr ? delegate : d);}

_ AOSD Tutorial ▲

注意点として挙げられていたのは，Abstract Aspect を使うとき．

抽象アスペクトに定義された pointcut を，複数の継承したアスペクトでオーバーライドした場合，それらの pointcut を p1 と p2 とすると，p1 && p2 であるような join point ではadvice が２回実行されるので注意が必要．declare error: p1 && p2; のようにしてエラーを出させる方法もあるが，これは p1 と p2 が両方とも static でないといけない．

また，やはり，join point が変化したら pointcut も変わる，というところだけは注意が必要らしい．何か依存関係解析でも必要だろうか．

_ SPLAT2004 ▲

SPLAT2004 のまとめ．

Comprehensibility セッションでは，

Karl Lieberrharl は，Demeter ツールを使ってオブジェクトを traverse するコードを書き直したら，どのくらい短くなって，理解性が上がったか，という話をしていた．

Abstractness = 書き直し前コードの長さ / 書き直し後のコードの長さという考え方は単純だけど．

また，Role モデルが好きっぽい人が，アスペクトの依存関係の管理することが大事だ，というように発言していた．しかし，依存関係を explicit にすると non-invasive adaptation がなくなってしまう，ということで対立していた．今のところ non-invasiveness のほうが大事で，explicit にするのは統合開発環境の役目じゃないか，というような考え方ではあるらしいが．

また，pointcut は構文的なものと論理的なものとでは差異があるため，semantic な join point という考え方がもっと必要そうだ，という意見には，みんな賛同していたが，今のところこれだ，というものはない様子．来年くらいにはいっぱい出てきそう．

しかし，「汎用的な（どんな場面でも動く）コードは複雑」という考え方と，「抽象的なコードのほうが理解しやすいのではないか」というすごく微妙な対立が起こっていたりした．

_ SPLAT2004 ▲

Predictability セッションでは，アスペクトを使って表明を書きましょう，という話と，アスペクトを使ってデータ暗号化アスペクトを書いてみました，という話の二軸．

表明を複数に分離する（コンポーネント側に「本来の制約」を書いて，アプリケーション側に「アプリケーション依存の制約」を書く）という考えに，Erik Ernst が食いついてきた．

表明の持つ副作用の問題について，データ暗号化のアスペクトを書いた人が，副作用の問題は非常に大きくて，アスペクトが気づかないうちにデータを壊したりする可能性を何とかして防げたらうれしい，というふうに発言していた．しかし，副作用を防ぐという意味では C++ の const などがあるが，「本当の」const はデータフロー解析などを使えばある程度できるがdata flow pointcut などは難しいのではないか，とも言っていた．JAC (Java Access Control?) という論文が ECOOP に出ているらしい．

しかし，実用的には，Java 1.5 で導入された readonly 属性付加などを使えばそれに近いことができるのではないか，ということを言っていたので，実践してみる価値は大きそう．表明に違反したときどうするか，は考えないといけないようだが．

ただ，みんな Predictability と Comprehensibility について明確な区別を持っているわけではないらしい．Predictability は「あるコード片の動作を予測できるか」という感じで何となく思っていて，Comprehensibility は「全体的に依存関係などを把握できるか」というくらい，らしい．Predictability は f(A) + f(B) と f(A+B) がどう違うか，といった問題のようでもある，とも言っていた，

_ SPLAT2004 ▲

Evolvability については，Erik Ernst が，アプリケーションの修正単位（アスペクト）が「相互に干渉しないべきだ」という立場を取っていた．pluggability というのを重視して，「あってもなくても動く」ような状態をうまく作ることで，システムの信頼性などを上げようとしている．

でも，「そんなので本当に必要なものが作れるのか」みたいにけっこう対立していた．どうも，「こう書けるとうれしい」派と「こう制限すると保守性が上がってうれしい」派に別れているような印象．

ベースプログラムを変更すると join point が変わるのでpointcut 側も変更しなきゃいけない，というのが嫌なので何か semantic な情報があればいいのだが，というような話もあった．下手に，「AのあとのBの呼び出し」といった言葉を作ると，ドメインに対応する言葉がないので困る，というような発言もあった．特定のイベントに名前をつける，といったイベントモデルなどが似ているといえば似ているか．

_ SPLAT2004 ▲

Semantic Interaction については，Aldrich という人が，external/internal 呼び出しを区別したり，モジュール境界をきちんと考えましょう，と発言していた．ただ，モジュール境界による区別をしてはいけない場合もあるよ，と反論も出ていた．その場合はモジュール境界をちゃんと引き直せばいいだけのような気もするのだが……．

アスペクトやクラスをグループ化して，何らかの制約を付加する，というのはやはり他の人も考えていたらしい．振る舞いを「変更していい」「値にアクセスしていい」といった情報をモジュール側に記述してアスペクトが「不用意に」値を変更したりしないように，という考え方も提案されていたが，簡単には解決しなさそう．「どこでモジュールを切りますか？」というのが出てこないので議論がうまくいってないような気がする．

ワークショップ全体の総括としては，

・Core Logic (class) と Aspect が明確に結びつきすぎるのはよくない

・何らかの情報隠蔽がほしい

・高水準言語を目指すべき？

・core と aspect の双方に表明を付加して，結果を予測可能とすることが有効？

といった形で締めくくられた．

_ AspectJ ▲

"Lancaster" のリリースは結局AOSDには間に合わず．コードネームに締め切りいれるのは間違いということか．

_ AOSD ▲

AOSD 2004 Technical Papers: Tools and Implementation

Shigeru Chiba, Kiyoshi Nakagawa:Josh: An Open AspectJ-like Language.

開発者が，新しい pointcut を追加できるような，言語の見た目は AspectJ によく似た言語処理系．メタプログラミングなので，この手の言語処理系を開発・テストする環境としてはおそらく最強のアプローチを取っているといえる．一杉さんの EPP に似ている気もする．

Josh が "助手" なのはかなりびっくりしたけど．

_ AOSD ▲

AOSD 2004 Technical Papers: Tools and Implementation

Christoph Bockisch, Michael Haupt, Mira Mezini, Klaus Ostermann:Virtual Machine Support for Dynamic Join Points.

今回，あまり興味がなかったので見送り．

_ AOSD ▲

Ran Ettinger, Mathieu Verbaere:Untangling: Refactoring extract aspects using program slicing.

単に，interleaved (織り交ざったコード) をスライスで分離しました，という程度の話．ぜんぜんモジュール間を横断してないので意味がない，と思う．これなら，学生ポスターセッションに出ていた，コードクローンからアスペクト探しましょうという話のほうがよっぽどえらいような気がする．（実際にはコードクローンだけでは難しくてスライスと組み合わせることになるのだろうが）

Nate というスライスツールがあるらしい．

スライスをメソッド抽出するときは，状態変数として使われているローカル変数の扱いが問題．Local -> Field 昇格をするとrecursive call などの場合に問題が起きる

スライスが大きくなる場合の問題については，何らかの半自動化された negotiation を行って量を減らそうと試みることが必要であろうと考えている

スライシングの見せ方として，diff ツールみたいに「削除されてるよー」ということが分かるように，スライス前・後を比較表示する点は面白い．しかし，大規模な(1000行以上の)スライスだと，そういうレベルの見せ方が通じない気がする．

プログラムスライスは，Fluid AOP の，実態コードは元のままで，見た目だけ AOP っぽくするという考え方に近い気がする．

_ AOSD ▲

AOSD 2004 Technical Papers: Applications I Steffen Gobel, Christoph Pohl, Simone Roettger and Stefen Zschaler: The COMQUAD Component Model - Enabling Dynamic Selection of Implementationsby Weaving Non-functional Aspects コンポーネントを，次のように考える．Component Specification と Component Interface は 1:n 対応．Component Specification と Component Implementation も 1:n 対応． Component Implementation は，Installed Component と 1:n 対応．Installed Component は，Component Object と 1:n 対応． Component specification に対して，複数の実装があるが，それぞれの実装が，どのような条件で動作するように作られているかプロファイル { provides, uses, resources } が存在してくる．そして，どの spec, implementation, profile を使うか，コンポーネントの接続をどうするかを XML で記述する． そして，この profile を使うことで QoS 実現を行う．たとえば，帯域の制御であれば，次のように provides と uses を作る．

quality fast_network { threshold bandwidth > 1 000 000; }
profile videoBinding for video_component {
  provides high_quality_video;
  uses fast_network;
}

これらを接続していくことで，目標の QoS に到達する，ということになるらしい．

_ AOSD ▲

AOSD 2004 Technical Papers: Applications I Gary Duzen, Joseph Lyall, Richard Schantz, Richard Shapiro and John Zinky: Building Adaptive Distributed Applications with Middleware and Aspects. CORBA などの分散環境でのアスペクト指向開発な話．アドバイスの記述は code の位置や実行ではなくシステムと環境の「状態」に対して行ったらしい． Contract 記述とかをアスペクトとしてきちっとやっている例かもしれない．面白いと思ったのが，登場する region という単位．ひとつの region は，システムがとりうる状態の範囲を示している．使える状態変数をどうするのか，といった点は難しそうではあるが，「……をしている間は，ｘｘの条件が成り立っている」といった関係を，region をネストさせながら記述できるようにしたらしい．

contract 表明の名前 {
  region Normal ( 成立している条件 ) {}
  region NetworkLoad (条件) {
    region Compress (条件) {}
     : 
  }
}

_ AOSD ▲

AOSD 2004 Technical Papers: Applications I

Adrian Colyer and Andrew Clement: Large Scale AOSD for Middleware.

AspectJ での開発に関する経験論文．EJB support concern (Java クラスを EJB として動かすためのアスペクト) を分離してみたら，けっこううまくいったらしい．これが一番面白いところか．また，AspectJ が，コードを貼り付けて振る舞いを変更できることから，リファクタリングなどに対して効果的であるらしい．また，コンパイル速度の問題なども解決されつつあるが，declare error を使ったコードスタイル検査などは，いわゆる専用のエンジンではないので時間コストは高いらしい．

_ AOSD Keynote ▲

Keynote 2: Crosscutting Requirements

Prof. Bashar Nuseibeh,Professor of Computing at The Open University (英国 放送大学)

ワークショップ以外では数少ない "Early Aspects" の話．Concern は，利害関係者が興味を持っている属性のこと，としている．

たとえば，エレベータを構築する場合には，ユーザからは「多く載れるかどうか」という観点から，モータ設計者からは「荷重耐性をどうするか」という観点から積載重量に関心を持っている．

"View Point" を何らかの形で（たとえば状態機械などで）定義し，それらの View Point 間の接続を満たすように複数の View Point を Overlap している要素を調整していくのが要求分析である，と考えているよう．

要求工学は各利害保有者の目標や要求，期待を見つけて，調整し，開発者とのコミュニケーションを行う，ということが目的である，といっていた．Requirements Engineering については，Nuseibeh, Easterbrook: Requirements Engineering: A Roadmap.Proceedings of ICSE2000. を参考に挙げていた．

_ AOSD ▲

AOSD 2004 Technical Papers: Weaving

Stefan Hanenberg, Robert Hirschfeld and Rainer Unland:Morphing Aspects: Incomplete Woven Aspects and Continuous Weaving.

アスペクトの結合を実行時に少しずつやっていこうという論文(?)．いわゆる lazy evaluation ．dynamic pointcut ばかり使うアプリケーションには有効とか言っていた気はするが，そんなアプリケーションがどのくらいあるのか，という点は不明．（このあたりは，新しい言語要素を導入する場合に重要な気はするのだが）

スレッドごとに cflow が違う場合などに，実行を最適化してしまうとまずくないか，また，いつ morphing するのかが問題ではないか，といった指摘が出ていた．

_ AOSD ▲

AOSD 2004 Technical Papers: Weaving

Jeff Gray and Suman Roychoudhury:A Technique for Constructing Weavers Using a Program Transformation Engine.

パターン（正規表現マッチの置換など）ベースの advice weaving 機構の話．スライドで説明された限りでは，項書き換えのような形でプログラム書き換え( weaving )が進んでいく．syntax tree をどこまで作るかがけっこう微妙な気はするが，Delphi など，weaver が存在しない言語でもそれなりに頑張れるよ，という実例として，とても面白い．

_ AOSD ▲

AOSD 2004 Technical Papers: Weaving

Erik Hilsdale, Jim Hugunin:Advice Weaving in AspectJ.

AspectJ における Weaving 技術の実装について説明した論文．static shadow (join point がマッチしうる地点) とdynamic residue (static shadow において，join point がマッチする条件) という用語を使うときにはこの論文を引用することになりそう．

exec(..) && if(..) のほうがアドバイス本体で if を使うよりも inline 化されて高速，とか実装の都合によるところはけっこうあるらしいが，効率のよいコードを書くためのガイドラインのようなものは存在しないらしい．

_ AOSD ▲

AOSD 2004 Technical Papers: Languages I

Kouhei Sakurai, Hidehiko Masuhara, Naoyasu Ubayashi,Saeko Matsuura and Seiichi Komiya:Association Aspects.

オブジェクト間の関連をアスペクトとして記述することを提案した論文．EoS (Rajan & Sullivan) に似ているらしい．

現在の AspectJ では，ひとつの join point に対してひとつの advice が実行されるが，インスタンスごとにアスペクトを追加すると，ひとつの join point に対して複数の advice が実行されることがあってなんかモデルがだいぶ変わっているのでは，という指摘があった．また，マルチスレッド上での振舞い（ロック機構など）についても質問が出ていたが，今のところ特に何かを考えているようではないらしい．

個人的には，E-R モデルとの親和性とかがあって，開発者に（たぶん）理解しやすい点がうれしいように思える．ただ，こうなってくると，アーキテクチャ記述言語とかコンポーネントの接続を管理しましょう，と研究しているタイプの人との違いの主張がむしろ重要なのかもしれない．

今後どうなるのか楽しみな研究．

_ AOSD ▲

AOSD 2004 Technical Papers: Languages I

Muga Nishizawa, Shigeru Chiba and Michiaki Tatsubori:Remote Pointcut - A Language Construct for Distributed AOP.

どのホストで動作しているか，といった条件を記述するremote pointcut を導入してみました，という論文．また，ホスト間をまたがって cflow が有効らしい．

JAC でも remote pointcut が使えるらしく，（おそらくは）論文を引用してなかったので突っ込まれていた．

どんな環境だと，使う効果が大きいのか？がこの手の分散環境のプロジェクトには参加したことがないので良く分からない．言語系だと，モジュールの複雑さが落ちましたとか，行数が減りましたとか，そういうところで評価するのだろうか？

_ EDエディタ ▲

1.2 から 1.3 に移行してみたら，なぜかファイルから関連付けで開いたとき，ファイルはちゃんと復号されるのだが，なぜか暗号化エラーのダイアログが出る．謎．

ファイルごとのパスワード設定機能とかは必要ないので，とりあえず 1.2 に戻してみた．

_ Java ▲

Java から USB を使えるらしい．JVM さえあれば OS を選ばない，という意味では，能動的にユーザが制御するようなデバイスを作るときにはけっこういいかも．ネイティブコンパイルできるのならカーネルに組み込み……というわけにはいかないんだろうけど（JDK をリンクするとバイナリが大きくなるだろうから）．

http://www-6.ibm.com/jp/developerworks/java/040312/j_j-usb.html

_ AOSD その他 ▲

Student Extravaganza や，その他の雑談で得られた話．

_ コードクローンからのアスペクトマイニングというのが狙っている人はやはりいるらしい．私自身は検討したけれど捨てているのだが． ▲

・どれがアスペクト候補か，というのをどうやって決めるか・うまくアスペクト候補を引き剥がせるか・アスペクト候補に該当するがクローンでないものを　どうやって一緒に引き剥がすか・クローンだけれどお互いに関係ないものをどうやって区別するかといった問題山積みなところが気になる．

_ PROSE ▲

Dynamic AOP の実装．ミドルウェアとかに使おうと思っているらしい．しかし，ユビキタス・コンピューティングな世界では，端末が，移動先で（地域的な設定を持った）アスペクトの影響を受ける可能性がある．このとき，アスペクトは，他のベンダーが提供したものである可能性が高いので，セキュリティ上の問題などがかなり大きいように思われるので，そのあたりに研究ネタがありそう．……という話を，某企業から東工大に出かけている人がしていた．

_ Fragile Base Code Problem ▲

ベース（通常はクラス）コードが変更されて，Join points が変化し，アスペクトの pointcut 定義がうまく動かなくなって，プログラムが壊れてしまう問題．

これに対して，semantic join points のような，もっと違う「何か」を使おう，という動きがある．region アプローチなどは，システムの状態に注目しているので，ある意味では semantic join points に属するのかもしれない．

_ AOSD ▲

AOSD 2004 Technical Papers: Languages II

Maja D'Hondt, Viviane Jonckers:Hybrid Aspects for Weaving Object-Oriented Functionality and Rule-Based Knowledge.

business rule を論理型言語(prolog)で書いて，メインプログラムはオブジェクト指向(smalltalk)で書いて，メソッド呼び出しに対して assert や query のような論理型言語が得意とする部分を実行させる，らしい．効果のほどは不明．

メソッドのパラメータなどが prolog 側にどう渡されるか，といったGeneral Model がよく分からない，といった指摘が出ていた．

Remi Douence, Pascal Fradet, Mario Sudholt:Composition, Reuse and Interaction Analysis of Stateful Aspects.

Aspect Interaction を真面目に取り扱っている数少ない人たち．この人たちは，ベースプログラムと，アスペクトの実行はまったく別のものだ，と考えているよう．同じ join point で複数のアドバイスが動くとき，干渉であると考えている．

また，「ひとつのアスペクトは必ずしも *すべての* アプリケーションで動く必要はない」と言っている点もえらいところかも．

ベースプログラムを，正規言語のようなものに直して，アスペクトとくっつけて，問題が起きないか調べましょう，という形式的手法を用いたアプローチ．

この手の形式手法は，どう動くのか直観的でないので，有効性についてもあまり考えられないのだが，もうちょっと，形式手法，制約言語といった系統のベースプログラムが壊れない，アスペクトが壊れないといったことを調べる人には頑張ってほしいところ．

_ AOSD ▲

AOSD 2004 Technical Papers: Applications II

Charles Haley, Robin Laney, Bashar Nuseibeh:Deriving Security Requirementsfrom Crosscutting Threat Descriptions.

「脅威」を { (action, harm), asset } と定義して，要求と，それに対応するドメイン要素，エンティティをインタフェースで相互に接続し，問題が起きるかどうかを考えよう，というもの．

あまり縁がない分野だったりするので効果のほどはよくわからないが．脅威を明示する，というタイプの手法なので，Potential Problem については対処できない．たとえば，金庫の鍵がないと金庫は開けられない，ということは明示できるが，鍵の管理に問題がある可能性に気づくことはない，らしい．

_ AOSD ▲

Bruno Harbulot, John Gurd:Using AspectJ to Separate Concernsin Parallel Scientific Java Code.

Java コードを，並列処理(MPI)な部分だけをアスペクト化した，という論文．しかし，スレッドが増えると，同期コードのコストが上がって高速化されていなかったり，どうも取り上げている例が悪いような気がする．ちょっと残念．

_ AOSD Invited Paper ▲

What are the Key issues for Commercial AOP Use - How does AspectWerkz Address them ?Jonas Boner, BEA

AspectWerkz は，XML と xDoclet 的タグ付けを使ってアスペクトを記述する．基本は「多少特殊な情報を付加した」 Java コードという形．そのおかげでIDEは自由に選べるようになっている．

また，AspectWerkz では，AspectJ などで使う pointcuts / advice 以外に，pointcuts--advice 連結の「binding」が増えているところも特徴らしい．

Class loader の管理はけっこう大事だと考えている様子（複数のクラスローダが同時には使えないため）．Runtime Weaving は，unwoven なメソッドの実行にはオーバーヘッドがかからないところが利点である，といっていた．

IDE 等ツール連携に関しては JSR-175 のメタデータ付加によって対応するつもりらしい．また，将来的には AOP をサポートするJVM (JRockit JVM 1.5)，JVMTI ベースの Weaving，Java 1.5 への対応を考えているらしい．

開発環境に対して依存しすぎないように，という立場などは特徴的なところか．今のところ使う必要がないので AspectWerkz を使おうとは思わないが．

_ AOSD ▲

AOSD 2004 Technical Papers: Industry Paper

Miguel Pessoa Monteiro, Joao Miguel Femandes:Object-to-Aspect Refactorings For Feature Extraction.

リファクタリングを行う際に，・ローカル変数への参照の扱い・抽出したアスペクトの配置（可視性）という問題がある，ということを言っている論文．

「どこをアスペクトに追い出すべきか」といった議論とは，論点が違う．可視性の問題には，Encapsulation を守るべきか，Aspect の効果をうまく使うべきか，といった悩ましい問題があるみたい．

_ Calendar ▲

hyCalendar が，エンターブレインのフリーウェア5000 に収録されて到着．

とりあえず，出張が終わって再開したTODO機能の実装が終わりそうなのでさっさと 0.7 としてリリースしたいところ．

_ Calendar ▲

hyCalendar 0.7.0 のドキュメント更新したので公開．一部のスクリーンショットも撮り直している．

_ Profes2004 ▲

Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering

続き．

ドメインのスコープだけは，広すぎないようにしないといけなくて，基準としては「変化するものが多すぎるときは，もっと狭める」らしい．また，開発者だけだと，実装の詳細に踏み込みすぎるので気をつけましょう，とも言っていた．ドメインが未成熟なときは terminology の定義も必要．

モデルが複雑になりすぎるのを抑えるために，モデルが複雑になりすぎたときは抽象クラスの作成や，共有されるようなクラスが多いときは逆に違いをはっきりさせるために派生クラスの作成を行ったりもする．また，ドメインからアーキテクチャ上にマップするときに１対多対応になってしまうものは，１対１になるように分解する，といったことによって目的を達成するらしい．

_ Profes2004 ▲

Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering

Feature-Oriented Programming と関係あるのかな？ということで聞きにいってみたチュートリアル．チュートリアルの担当者は，SEI でドメイン分析 FODA とかを研究していた人らしい．

特定のドメインに対するソフトウェア群（たとえば「エレベータ制御」--どんな場所に設置されるか，何人乗せられるか，実際に動かす対象などが異なる）をうまく共通のアーキテクチャ，コンポーネント群を使って構築しようというのが基本コンセプト．

ただ，ソフトウェアの変更や継続的なメンテナンスにもドメイン分析は有効である，とは言っていた．一つのシステムが変化していくのを，Product Line の開発として考えれば，確かにその通り．

ハードウェアなら CPU やメモリ容量が仕様に相当するが，ソフトウェアならサービスがそれに当たる．ドメイン上で，必要なサービスや品質特性を分析して，それをアーキテクチャ上のコンポーネントにマッピングしていく．コンポーネントを，さらに実際のソフトウェア部品などに対応させていく．

Capability と Operating Environment を顧客とアナリストがつくり，開発者が，アナリストと一緒に Domain Technology やImplementation Technique を考えていく．Feature の階層構造から，わりと自然に，ドメインに対応するクラスが導出できるものらしい．で，抽出された要素をアーキテクチャ上にマップしていく．

_ Profes2004 ▲

今日から Profes 2004 ＠けいはんなプラザ．とりあえず午前のチュートリアルだけ受けてきた．

Proceeding 以外には，大阪，京都，奈良の観光ガイドとペンホルダ付き手帳，ボールペン，ease プロジェクトの宣伝，Profes2004 ロゴ入り USB フラッシュメモリ32MB．

_ Calendar ▲

hyCalendar 0.7.0 実行ファイルのみリリース．まだ，マニュアルを更新してやる必要がある．

_ AspectJ ▲

AspectJ の書籍の話を追加．初日本語書籍．

書いてるメンバーがメンバーなので（といっても知っているのは四人のうち二人だけれど）それなりに期待してよさそうかも？

ただ，アスペクト指向について説明するときは，どうしてもオブジェクト指向ベースで話を進めるような気がするので，Java やオブジェクト指向をある程度理解していないと駄目なのか，そのあたりは少し気になる．

_ ファミコン ▲

「彷魔ヶ刻」と「ファジカルファイター」を例によって famiget.com で購入．またも部室に送る．

_ メーラ ▲

oucc.org が SMTP サービスを提供しないように設定されてしまったので，oucc.org で受信したデータへの返信が面倒くさくなってしまった．Al-Mail だと，smtp サーバだけをactivemail.jp から送るといったように設定できないようなので（ユーザアカウントが違うから仕方がないが），Al-Mail から，Becky へ移行してみた．

_ 論文 ▲

Profes の間に読んだ最後の論文．

Andrea De Lucia, Mark Harman, Robert Hierons, Jens Krinke:Unions of Slices are not Slices.

プログラム P のスライス P' は，Weiser の定義から，以下の条件を満たす．・P' は，P から０行以上の文を消している．・P が停止する入力なら，P' も停止する．・P' は，ある変数群 V について P と同じ値を計算する．

この条件には意外と自由度が高く，Static Slice を複数計算したとき，それらの和を取ると，スライスではなくなってしまう場合がある，というもの．Dynamic Slice については，既存研究があるらしい．

安易に union を取るのはよくない，らしいがスライスの union, intersection にはどのくらい意味があるのか，という議論はどれくらいあるのだろうか．

参考文献を（暇があれば）あたってみることにする．

_ 論文 ▲

Profes 余暇の利用して読んだ論文その３．

Raju Pandey, Brant Hashii:Providing Fine-Grained Access Control for Java Programs.ECOOP 99, pp.449-473, 1999.

アクセス制御を外付けする．条件判定に，インスタンスのフィールドやクラスの情報を使えるので，アスペクトとして if でテストするコードを追加する実装にかなり近いアプローチだという気がする．

外付けするのは，モバイル端末がサイトに勝手にアクセスするのを防ぐ，といった，「後付け」制限になるため．Readonly でも，機密データならばアクセスできない，といった制限も考えられる．このあたりは Java の SecurityManager などが関連しているともいえる．

この機能，今なら本当にアスペクトで実現しそう．

_ 論文 ▲

Profes の余り時間で読んだ論文その２．

Gunter Kniesel, Dirk Theisen:JAC - Access Right based encapsulation for Java.Software Practice and Experience, 00(S1), 1-21(2000).

いわゆる "const" を Java に導入する話．オブジェクトの状態を，ローカル変数で定義される local state と参照しているオブジェクトの状態で定義される transitive state に区分している．

そして，参照変数に readonly という修飾子を追加し，this が "readonly" として参照されたコンテキストではreadonly が付加されたメソッドしか実行できない．また，mutable と明示的に定義されたデータしか変更できない．

this のとりうるコンテキスト＋変数のコンテキスト＋メソッドのコンテキスト，で static に型チェックを行うというもの．

これは，JDK 1.5 で導入されるとかいうものと同じ？

_ 論文 ▲

Profes 2004 の暇な時間に読んだ論文．

Pascal Costanza, Gunter Kniesel, and Michael Austermann:Independent Extensibility for Aspect-Oriented Systems.

6ページのショートペーパー．

アスペクトが予期せぬ環境で使用され，副作用をもたらすことは避けられない．アスペクトを適用するごとに join point が変化していき，結局，アスペクトの結合順序などに依存した結果となる．

この論文では，アスペクトの適用をコード変換とインタフェース変換に区分していて，インタフェース変換は，インタフェースのメソッド集合を追加するだけなので順序の影響を受けないが，コード変換は順序の影響を受ける．

……ということから，コード変換のほうは開発者が考慮するような環境が望ましく，データフロー解析などが重要になるかもしれない，というふうに主張している．

_ IPSJ ▲

論文２本目が採録決定．これで D が取れる．

_ Profes 2004 ▲

Session 12: COTS

Profes 2004 最後のセッションの論文二つ．（残り１つは発表取り消し）

Jingyue Li, Reidar Conradi, Parastoo Mohagheghi, Odd Are Sæhle, Øivind Wang, Erlend Naalsund, Ole Anders Walseth:A Study of Developer Attitude to Component Reuse in Three IT Companies.

３つの企業（Ericsson, EDB, Mogul）での調査結果．

・コンポーネントは十分（期待通りに）効果的に働くか？

・コンポーネントが効果的なら，コンポーネントをたくさん使うか？

・関連したコンポーネントについて，十分な情報が得られるか？

・component quality と reuse level は関係あるのか?

といったことについて，開発者にアンケートをとっている．

その結果，Ericsson は Reuse レベルが高かったよう．会社ごとに，回答の範囲がある程度固まっていたので，嘘ではなさそう．

会社が reusable components repository に投資することは期待されていなかったらしい．component structure, interface は理解できる．コンポーネントの設計ルールについても理解できる．でも，そのコンポーネントのドキュメントが良いとは思っていなくて，非形式的な，ソースコードがベース．

この評価の話は，特定の企業で，人数も少ないという点から，妥当性という点で弱い，と本人たちも言っていた．

Mercedes Ruiz, Isabel Ramos, Miguel Toro:Using Dynamic Modeling and Simulation to Improve COTS Software Process.

Software process simulation によってCOTS ベースなプロセスの dynamic behavior を調べたりしよう，というものらしい．

Traditional Estimation (WBS, statistical correlation) + System Dynamics Modeling

Simulation 実行データと実際のデータをDBに持っておいて，「現状で実行するとこうなる」，という状態と改善した状態を比べるような話らしい．あまり興味がないのでちゃんと聞いてない．

_ Profes 2004 ▲

論文整理続き．Session 10: Software Process Assessment

Fredrik Ekdahl, Stig Larsson:Selecting CMMI Appraisal Classes Based on Maturity and Openness.

必ずしもCMMIでなくてもよいらしいが．組織の状態を Maturity, Openness でとらえると，Maturity や Openness は必ずしも単調に増加するわけではなく，組織の変化などの影響で下がったりもする．

Openness は外部からの援助などを（対価を払ってでも）獲得しようという行動の度合いで，経験的，企業の振る舞いから，現在は主観的，定性的に決めている．

いくつかの企業についてマッピングを行っていたが，現段階では，そのうち何か面白い結果が出るかも，という程度の話．

Pasi Ojala:Combining Capability Assessment and Value Engineering: a BOOTSTRAP example.

Value Engineering(価値工学; 最小コストの製造法を得るための設計・製造工程の分析とかの工学)を導入してみました，という話．

Value = 価値(worth) / cost worth = 客がいくら支払ってくれるか or かかったかもしれないコストcost = 実際にかかったコスト

+Capability, +Value: Situation is in control

+Capability, -Value: Wasted Quality

-Capability, +Value: Do something / Improve

-Capability, -Value: Do not worry

Full assessment を行って，すべてのプロセスに対して Maturity を，また，Value を部分的に計算して，価値の高いところから改善していこう，というもの．それなりに面白そうな話ではあった．

Marcello Visconti, Curtis A. Cook:Assessing the State of Software Documentation Practices.

ドキュメントが大事 --- コードを書く前に欠陥を取り除くことが重要，という立場の論文．

Key Practices/Sub practices/Questionsという構成．GQM に近い気がする．

意外と，「良いドキュメント」はやりたいと思っていても実際には実践できていない，らしい．

_ Profes 2004 ▲

Session 8: Software Process Improvement 2あんまり興味がないので適当．

Mingyang Gu, Xin Tong:Towards Hypotheses on Creativity in Software Development.

Creative Work の割合が開発効率に影響するのではないか，と考えて "Creative Work" と discipline-based work と，それ以外のタスクにかかった時間を，学生相手に調べてみたという論文．

しかし，Creative Work が高いからといって開発速度が変わるわけではないらしい．UML がアイディア記述のための道具として役立っていた，といった報告もしていた．

Lasse Harjumaa, Ilkka Tervonen, Pekka Vuorio:Using Software Inspection as a Catalyst for SPI in a Small Company.

アンケートによる分析→目標の設定→improvement pattern を選ぶ，という形でのソフトウェアプロセス改善．

pattern ベースでやるのはガイドラインとしては便利なのだが，・行動リストが一般的すぎたり・同じようなパターンが複数あったり・結果がどうなるか書いてなかったりするときがあるので注意が必要である，と言っていた．

もちろん，small/large company で違うかもしれない．small であるという仮定がどの程度効いているのかはよく分からない．

_ Profes 2004 ▲

Session 6: Industrial Experiences経験論文系．

Marek Vokáč, Oluf Jensen:Using a reference application with Design Patterns to produce Industrial Software.

「お手本」をもとにシステムを構築するという話のよう．再利用については，２つ目の Key note でも言われていたが，パターンやアーキテクチャ，モデルといった抽象度の高いレベルで再利用をしましょう，ということになるらしい．

そうすることで，そんなに経験をつんでないチームでもそれなりにいいものが作れた，らしい．他のプロジェクトでも使えるか？という問題があるが，requirements が reference application にマッチするかどうか，がキーとなる．

Keynote 2:"Embedded Software Development -Today and Tomorrow-"Mr. Takashi Yamamura (Ricoh Company, Ltd.)

品質を下げずに再利用を行うためにはソースコードではなくモデルを再利用する，また，品質はテストではなく設計によって確保する，という話．

Component == Fixed part + Variable Part となるらしい．このあたりは，チュートリアルで聞いた話とも同じ．

それにしても，実際にバグ数が減少して，時間あたりのソースコード量での生産性が倍程度に向上している，という具体的なグラフを見せてくれた点が面白かった．

_ Profes 2004 ▲

Profes 2004 論文整理．

Session 3: Measurement

Felix Garcia, Francisco Ruiz, Mario Piattini:Definition and Empirical Validation of Metrics for Software Process Models.

プロセスに対するメトリクス．プロセスモデルの保守性，理解容易性，変更容易性などをやはり GQM paradigm ベースで評価している．

10 Software Process Models に対して適用してみていて，NA, NWP, NDWPIn, NDWPOut と modifiability time との相関があるらしい．（ここでのmodification というのは activity の追加とか）

Pasquale Ardimento, Maria Teresa Baldassarre, Danilo Caivano, Giuseppe Visaggio:Multiview Framework for Goal Oriented Measurement Plan Design.

色々なメトリクス，ゴールがあるが，実際にはメトリクス間の依存関係があったり時間的な制約によってはかれるものが限られたりする（テストフェイズまで進まないと計れないものなど）．どうやったらこれらをうまく管理できるか？という話．

ゴールとプロセス/プロダクトの表を作って，全体を管理ゴールの「解釈」についてはデシジョンテーブルを使うGQM ベースなアプローチを使っている．GQM パラダイム，やっぱりみんな好き？使いやすいのかな？

Magne Jørgensen, Kjetil Moløkken:Does Awareness of Previous Estimation Performance Lead to Less Overconfidence.

以前のプロジェクトの情報を使えば，見積もりが大きすぎる/小さすぎるという状態を抑えられるはずである，という仮定に基づく実験．

Estimate = 100% として実際にかかった工数が何％であったかを調べている．

そして，実際に過去のデータを使ってみたところ，ある程度抑えることができた（９０％~１５０％）．ただし，１５０％というのは overconfidence かもしれないが．

組織間を超えた結果の適用などは難しそう．また，過信を抑えるのと，正確さを向上するのとは違うよう．評価結果が "どのくらい信用できるか" といった感じのものらしい．

_ Profes 2004 ▲

適当に論文をピックアップ．あんまり興味がないので適当．

Session 2: Software Quality

Jukka Riekki, Pekka Isomursu, Minna Isomursu:Evaluating the Calmness of Ubiquitous Applications.

ユビキタスコンピューティングでは「いつでもどこでも」が重要なので，システムの availability などを考える必要がある．

Calmness に注目して，分析結果から簡単な図表現を作って，何が足りないか考えよう，というものか．なんかよく分かってないが．

Axel Spriestersbach, Thomas Springer:Quality Attributes in mobile Web Application Development

ユビキタスなシステムは，環境にあわせてインタフェースなどを変化させる．（たとえば入力項目数が減るなど）

このとき，applications x devices の組み合わせが発生する．これに対して，次の対策が取れる．

・再実装：高ユーザビリティだが高コスト

・自動変換：低コストだが低ユーザビリティ

・一部自動変換（GUI は抽象 widget クラスで作るが アプリケーションレベルで一部書き換え）

Cost -- Usability はおおむね比例のように感じられるが，実際には，一部は自動変換するというアプローチがコスト対効果が良く，少ないデバイス集合からだんだん対応デバイスを増やしていく方法が良い，といったことを言っていたように思う．　　Lerina Aversano, Gerardo Canfora, Giuseppe Capasso, Giuseppe A. Di Lucca, Corrado A.Visaggio:Introducing Quality System in Small and Medium Enterprises: An experience report.

Quality System は導入・使用におけるコストが，活用への大きな障害になるというわけで，開発した Quality System を使ったケーススタディ．

・開発者が既に慣れているものを使うと， 導入コストは低くなったらしい．

・GQM での品質比較を行った結果， 期待品質と実際の品質の差はほとんどなかったらしい．

_ Profes 2004 ▲

Profes 2004 で聞いた情報整理その１．

Richard Turner による Key note:

Best Practices は真実だと思っているが事実とは異なるかもしれない，という話から始まっていた，

物をもつときはしっかり抱える，という practice を盲目的に実践してしまうとケーキを押しつぶしてしまう，…というところから始まって，

"Wrap well" practice from cake melted mess. "Cool in stream" practice from butter experience nearly drowned dog."Tie to string" practice from puppy experience → very dirty bread and very angry aunt.

ということで，not blindly applied practice,apply empiricism to practice.ということになる．

その利益は qualitative (Schedule, Quality, Cost) であって数値としては見えてこない．

Best Practice の Pedigree (系図) として・誰が作ったか・どのくらい時間が経ったか・データはあるか・使って成功した人はいるか ...といった情報も役立つ．

また，コンテキスト（プロジェクトサイズ，ライフサイクル，...）も重要だし，効果が出てくるまでの時間も問題となる．たとえば，データを集め始めてから効果が出るまで組織などの支援は続くか？プロジェクトが終わってしまわないか？といったことを考慮する必要がある．

Beware the myth. Trust, but verify ...

しかし，実験するときには，その環境で得られた結果が実プロジェクトなどで本当に適用可能かどうか，についてはきちんと吟味する必要がある，ということで話を締めくくっていた．

_ AOP ▲

static crosscutting の活用事例．さすが developerWorks．

http://www-6.ibm.com/jp/developerworks/java/040409/j_j-aopsc.html

_ 定期入れ ▲

定期入れを購入．郵送で届くのが便利でいいかも．

http://www.rakuten.co.jp/yy/

_ Profes 2004 ▲

どうでもいい話ではあるけど，Conference Banquet で行った百楽荘はやっぱりけっこういいお値段なお店だったらしい．http://r.gnavi.co.jp/k170005/

_ Delphi ▲

TListView のインプレースエディタの情報が取りたいなーと思って調べてみたら，

editor_handle := ListView_GetEditControl(listview.Handle); で取れるらしい．unit は CommCtrl．

ハンドルが有効かどうか（（editor_handle != 0) でかつ Visible かどうか）についてはTListView.IsEditing が true かどうかで判定可能．

_ AOP ▲

AOP な記事もだんだん増えてきた感じ．そろそろ，Join Point = 結合点,Pointcut = ポイントカット,Advice = アドバイスといった訳しかたが定着してきた感じがする．そろそろ，この訳にあわせて，公開してるドキュメントを直そうか？

http://www.atmarkit.co.jp/farc/rensai/redge24/redge24.html

_ Calendar ▲

バグ報告を受けて，hyCalendar を 0.7.2 に更新．現在の終了日よりも後ろに新しい開始日を設定したときに表示がおかしくなる問題を修正．

_ 5/2 ▲

ライブのチケットが取れたので東京行きは確定したが，泊まるかどうか悩みどころ．ワシントンホテルが，20周年記念で，シングルに7000円で泊まれるプランを出してるのに少し惹かれる．たまにはもうちょっと高いところに泊まってもいいけど，一人じゃあまり意味がない．

_ 論文 ▲

日本学術振興会の特別研究員公募の申請用に下調べ．

粗粒度なプログラムスライス系の話を探してみる．次の文献くらいか．

Jianjun Zhao:A Slicing-Based Approach to Extracting Reusable Software Architectures.

Architecture Description 上での依存関係解析によってサブシステムなどを取り出す．調べるのはコンポーネント間の接続関係．Architecture Description そのものは比較的素直？コンポーネント指向な世界だとコンポーネント間の接続を流れていくオブジェクトたちはコンポーネントなのかどうか，というのが相変わらず気になる．ベースレベルとメタレベルをごっちゃにしてるだけ？

Jon Beck, David Eichmann:Program and Interface Slicing for Reverse Engineering.ICSE 1993.

パッケージの中の再利用したい一部のインタフェースだけを選んだら，それに必要なサブシステムだけを抜き出してくる．調べるのは関数呼び出し関係とデータの依存関係．それなりにうまくいっているようで，OO 全盛ではなかった時代だからそんなに難しくなかったのかなぁ，という気もする．それでも Name overload や Generics みたいなのはあったようだけど．

_ amazon ▲

いつも見てる blog でこんなものを作ってた．http://www.goodpic.com/mt/aws/

ページのデザインによっては使うかどうか悩みどころかもしれないが．

_ AspectJ ▲

AspectJ 1.2 Release Candidate 1 がリリースされていた．AJDT も新バージョン．Eclipse 3.0M8 で動くらしい（逆に前のバージョンでは動かない）．

_ 読書 ▲

まったく和訳されなさそうなのでアン・マキャフリィ「Pegasus In Space」購入．ついでに，論理パズルで有名なスマリヤンの「パズルランドのアリス I, II」購入．

_ 読書 ▲

アン・マキャフリィ「天より授かりしもの」読了．読みきりな中編．事件が起きない平和なお話な気がする．そこそこ面白いんだけど，なんか物足りないかも．

_ Calendar ▲

hyCalendar 0.7.2 リリースして，まだ Vector には連絡してないのだが，窓の杜はしっかりアップデートされていた．実はアンテナ張られてるのかな？ある意味えらい．http://www.forest.impress.co.jp/lib/offc/business/pim/hycalendar.html

_ SMTP-AUTH ▲

oucc.org サーバで，SMTP 禁止だったのがSMTP-AUTH 導入になったらしい．

_ CodeSurfer ▲

Static Slice Tool らしい．http://www.grammatech.com/products/codesurfer/

実際には，有用なんだろうか？

_ Knight Rider ▲

CNNj を見てたらKnight Rider returns? とか言ってた．日本では関係ないと思うけど……．http://www.knightrideronline.com/mt/archives/000089.php

KITT のスペックの一部がFAQに載ってた．ちょっとびっくり．http://www.ocf.berkeley.edu/%7Etverona/krfaq.html#10

_ 論文 ▲

Marek Majkut:Generation of Implementation for the Model Driven Architecture with Syntactic Unit Trees.

なぜかファイルにはさまってた．読み忘れていたのか，それとも読んだが意味がなかったのか．

Syntactic Unit と呼んでいるのはようはテンプレート（スケルトン）コードで，UMLの図からテンプレートの中身を埋めるという話．

どうやって図にコードを対応させるのか，というあたりの具体性があまりない．

_ 論文 ▲

査読の都合で，Cohesion 話の論文をチェック．

Jianjun Zhao, Baowen Xu:Measuring Aspect Cohesion.FASE 2004.

・データの依存関係があるか・呼び出し関係があるかといった関係をもとに，スコアを重み付きで足しこんで 0~1 の範囲で計算する．AOP な適用部分は，アドバイスを扱うこととまた inter-type declaration をアスペクトの一部とみなすこと，だろうか．pointcut 定義についての扱いをどうするべきかはけっこう微妙な気がする．「いつ呼ばれるか」という意味では，外側に影響しているだけなので coupling のほうにしか影響しないのかもしれないが，同一 pointcut にふたつのアドバイスが存在する場合のほうがふたつ，関係ないアドバイスがあるよりはcohesion が高いような気もする．少し怪しいが．

_ POPFile ▲

スパムがたいがい多くなってきたので導入してみた．Norton AntiSpam に比べると，いわゆるプロキシとしてがんばってますーという動作方法が明瞭なところと，学習させやすいところが嬉しい．

_ JVMTI ▲

JVMTI は，どうやら JDA (Java Debugger Architecture) の拡張らしく，in-process な "Agent" が JVM からEvent Callback とかを受け取ってout-process なデバッガ等と通信するらしい．http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html

bytecode-instrumentation がきちんと加えられていてクラス定義を書き換えた場合は実行中のメソッドだけはそのまま動く，とかの規定もちゃんと入ってる．

_ AspectJ ▲

アクセス解析で不思議なリンクがあったので見てみたらなんか引用されてた．大丈夫なのかなぁ，こんな適当な解説を引用して……．

http://www.okisoft.co.jp/esc/log4j/aspect/A1.html

発言には気をつけないと，間違いまで広まってしまう．

_ The Darwin Award ▲

リアルタイム UML 第２版 p.270 に記載されている「自動車が時速300参る（時速480km程度）で走行することはありません．[注６]」のネタの出所をつい調べてしまった．

http://www.darwinawards.com/darwin/index_darwin1994.html

_ 読書 ▲

研究室に置いてあった「リアルタイムUML第２版」（翔泳社）を読んでみた．ちなみに原著は：Real-Time UML, Second EditionDeveloping Efficient Objects for Embedded Systems.

リアルタイムシステムだから，何か特別なことでも入るかと思ったら，意外とそうでもなかった．（実時間に関する情報が UML 上に埋め込まれているくらいか）

とりあえず，何となく忘れそうになってたことをいくつか再確認．

• オブジェクトのクラスがオブジェクトの債務を規定できるのは，それらのオブジェクトがすべて同じコンテキストで同じように使われる場合のみ
• ひとつのオブジェクトが複数のインタフェースを備えることもある（ソースコード上では区別は付かない場合もあるかもしれないが）……実は自動で分割できると嬉しいかな．嬉しくないかな．
• アクティブオブジェクトとパッシブオブジェクトアクティブなほうは，自律的でイベントを発生させたり，システムの全体を構成する役割を持つパッシブのほうは，クライアントにサービスを提供する
• オブジェクトは債務を果たさなくてはならない．そのために必要な情報を持たなくてはならない．
• 継承による拡張と特化 拡張 = 新しい振る舞いを追加する 特化 = 親クラスの振る舞いを置き換える（ただし Liskov の置換原理は守る）
• アーキテクチャ設計とは，システムを構成するための戦略の決定．たとえばオブジェクトをレイヤ形式で配置するとか，オブジェクト間の接続をオブジェクトブローカーに任せるとか．
• メカニズム設計：コラボレーション（一連の協調動作を行うオブジェクト群）の設計．ただし，同じロールを担当する交換可能なクラスが複数存在するとき，それはパターンとなる．少数のスコープに限定されたパターンをメカニズムと呼ぶ．メカニズム設計として，オブジェクトがどのように協調するかを決定する．
• 詳細設計：データ構造の決定，精度や値域の確定，アルゴリズムの決定．関連，操作，可視性の決定，例外の決定（誰が送出し，誰が捕捉するか）．

_ Calendar ▲

hyCalendar の次の改造をそろそろ開始する．

TODO リストに優先度を付けられるようにする

TODO リストの中身のソート機能を追加する（優先度，更新日時，登場する日付によるソーティング）

周期予定で，カレンダー側から＜この日は除く＞というマークを簡単に付けられるようにする．

readonly モードの追加

くらいか．どうしようかな？

_ 日記CGI ▲

ヘッダコメントが無駄に長いので削った．もうちょいレイアウトは気を使ったほうがいいかもしれないが．

_ 論文 ▲

プログラム依存グラフの計算簡略化のための方法を探して論文読み．

Mark Harman, Rob Hierons, Sebastian Danicic, Mike Laurence, John Howroyd and Chris Fox: Node Coarsening Calculi for Program Slicing.

8th IEEE Working Conference on Reverse Engineering (WCRE 2001). 2-5 October 2001, Stuttgart, Germany, 2001. Pages 25-34.

制御フローグラフに対して，隣接したノードを集約していくことでノード数を減らしていこうというもの．そのときに，一貫性を維持した中で一番良い結果を出すような方法を考えましょう，というもの．集約時に少しだけ不正確な結果が加わるが，それでも集約を重視するという姿勢．

R-Coarsening という手法をケーススタディ形式で紹介している．

Rb = ( I, D, d, R )
I = ノードのラベル集合
D = そのノードが実行されたときに必ず定義される変数
d = そのノードで定義されることがある変数（Dの要素もすべて含む）
R = 参照される変数

という四項組を定義して，

Assignment: v := f(R) --> Rb({f}, {v}, {v}, R) 
b1 = Rb(I1, D1, d1, R1), b2 = Rb(I2, D2, d2, R2) 

とすると

Sequence: b1;b2 
  --> Rb(I1∪I2, D1∪D2, d1∪d2, R1∪(R2-D1))
 
Conditional: if p(R) then b1 else b2 
  --> Rb({p}∪I1∪I2, D1∩D2, d1∪d2, R∪R1∪R2) 
  注: D = D1∩D2 なのは，if なので分岐の両方でも更新されるものだけということ.
 
Loop: while p(R') do b 
  --> Rb( {p}∪I,φ,d, R∪R') 

というようにルールを定義する．論文ではこれが一貫性があって，しかもできうる限りでは最適であるという証明も付属している．ただ，Minimalではない(スライス結果に関係ない文が含まれることがある）．

関連研究としてCFGのグラフ上での変換作業が載っていて，グラフ操作では不必要に不正確になる可能性があることに言及している．

ちなみに，この粗粒度化の方法自体の適用についてどのくらい時間がかかるかは不明．どのくらい粗粒度化するのかとかに依存か．制御フローグラフ構築時にいきなりこれを意識しながら作業すれば，そんなにコストはかからないかもしれない？

そのうち引用することになりそう．

_ 論文 ▲

David Binkley and Mark Harman. Results From a Large-Scale Study of PerformanceOptimization Techniques for Source Code Analyses Based on Graph Reachability Algorithms. 3rd IEEE International Workshop on Source Code Analysis and Manipulation (SCAM 2003). 27th September 2003, Amsterdam, Netherlands. pages 203-212.

大規模 C プログラムに対するスライス計算をするときに，グラフを事前にどういじったらどのくらい高速化したか，という最適化の実験の話．

Strongly Connected Components の接続の１頂点化，SCC に対するデータ構造的なサポート導入，頂点のトポロジカルソート導入，推移的な辺の除去，というようにだんだん最適化している．

実験の適用対象はけっこう大規模で（というか他の論文と同じだが）100万行分くらい．とはいえ，全部で100万行なので，この書き方は誤解を招きそう．平均的には，３倍くらいの高速化をしている．

例によって，評価している時間はスライス計算の時間のみでグラフ構築時間を見ていない．実はグラフ構築に激しく時間かかってたりしないよなぁ，とちょっと邪推したくなるのだが．CodeSurfer を使ってる人たちで，SDG (System Dependence Graph) 構築時間について言及している人を，あまり見たことがない．昔はとても遅かったらしいが，今はどうなんだろう．

_ 論文 ▲

Laura K. Dillon, R.E.Kurt Stirewalt:Lightweight Analysis of Operational SpecificationsUsing Inference Graphs.

Operational Specifications というのはLOTOS などの形式言語のことらしく，色々な言語に対応するために式評価を Inference Graph としてアーキテクチャ構築で使うコンポーネント図みたいな部品を合成したデータフローグラフとして表現すれば，入力値が要らないものから順番に評価していけば結果が取れますね，という感じ．

何が lightweight なのかはよく分からないが，ルールベースで自動生成するところなのだろうか．inference graph の有用性はいまひとつ分からない．

_ 論文 ▲

David Binkley and Mark Harman. An Empirical Study of Predicate Dependence Levels and Trends 25th IEEE/ACM International Conference on Software Engineering (ICSE 2003). 3-10 May, 2003. Portland, Oregon, USA, Pages 330-339.

プログラムの中に登場する predicate から参照できる Formal parameters の数と，predicate で実際に使われるパラメータの数に関する統計を取ってみた，という論文．predicate の定義が曖昧だが，たぶん if など制御文などで使われる変数式全般．

対象のプログラムは20個の C プログラムで，最大で160KLOCくらい．Predicates per KLOC はどのプログラムでも変わらなかったらしい．

で，結果としては，使えるパラメータ数が増えていくに従って，だんだん参照可能なパラメータは増えていくが，実際に使われるパラメータはあまり増えないので，コンテキストへの依存度（使われる率）は下がっていくらしい．ただし，グローバル変数に関してはそういう関係がなく，グローバル変数が増えるほど使われる傾向にあったらしい．

で，依存度が低ければスライスサイズなども小さくなるので人間の労力を大きく削減できるだろう，ということになる．参照可能な Parameter の数さえ数えればだいたいの傾向がわかって，しかもそんなに計算コストは高くないので便利そう？これ単体で，どうこうできるものではないような気もするが．

_ 論文 ▲

David Binkley, Mark Harman:A Large-Scale Empirical Study of Forward and Backward Static Slice Size and Context Sensitivity.19th IEEE International Conference on Software Maintenance (ICSM 2003). Amsterdam, The Netherlands, 22-26 September 2003. Pages 44-53.

プログラムスライスを全部のスライス基点から計算することで統計的に比較をしている論文．実験時のスライス基点については，基点の選び方が効いてくるので，とりあえず全部計算するのがいい，と思っている様子．

対象プログラムは C で書かれた43プログラム，合計100万行ばかり．静的スライスの計算は CodeSurfer で計算されたもの．グラフ中でループになっているようなStrongly Connected Components (SCC) を１頂点として集約して，手続き内頂点はトポロジカルソートしてから，計算している．

グラフ構築は置いておいて，計算そのものは平均 3000KLOC/sec くらいのペースで処理が進んだらしい．(大きいものほど遅くて，100KLOC/sec を切るものもいくつか)

スライスサイズは，プログラム全体の７％~６０％程度．また，context-sensitive （ある手続きに複数の呼び出し文があるときにそれらを区別する）を省略すると，スライスサイズが sensitive なときの50％増しくらい（物によっては数倍）になったらしい．

ちなみに，forward slice と backward slice とを比べるとforward slice のほうがサイズが小さくなるらしい．何となく正しいような気はするけど．

context-sensitivity に関しては色々研究があるらしくて，呼び出し列を call string という文脈自由文法扱いにしてスライスサイズを減らすための情報に使うらしい．引用されているのは次の二つ．

Krinke, J.: Evaluation context-sensitive slicing and chopping. ICSM 2002, pp.22-31.

Agrawal, G. and Guo, L.: Evaluating explicitly context-sensitive program slicing. Workshop on Program Analysis for Software Tools and Engineering, pp.6-12, 2001.

_ 論文 ▲

Thomas Reps and Genevieve Rosay:Precise Interprocedural Chopping.Proceedings of 3rd FSE, 1995.

Program Chopping というのは，プログラムスライシングの forward と backward を組み合わせて「ある文 s からある文 t までデータが到達する経路」となる．で，Jackson and Rollins がオリジナルを提案したのだが，彼らは intraprocedural なものしか考えていなかったので手続き間でも使えるように変更しました，というもの．

基本の考え方は，手続き内では依存関係を summary edge という形式で作成して，手続き間をcall，parameter in/out で接続したもの．

しかし，実験結果を見た限りでは，えらく時間がかかっている気がする．realizable path を探すために，メソッドの call/return の対応を取りながらグラフの traversal をする必要があるので，実はスライスよりも計算は難しいらしい．

単純にスライスで得られた頂点の積集合を取るだけだと「到達するかもしれない」集合が大きくなりすぎて駄目ということなのだろうか．

_ カウンタ ▲

カウンタの集計結果を見られるようにしてみた．わりと偏りが出ていて怪しい．

_ 論文 ▲

Kim Mens, Bernard Poll, Sebastian Gonzalez:Using Intentional Source-Code Viewsto Aid Software Maintenance.Proceedings of ICSM 2003, pp.169-178.

"intentional source-code view" というのは開発者がある目的のためにソースコード中を抽出したもの．論理型言語を使って結果を抽出し，それに加えて incremental に例外要素の追加・削除を行う．

ケーススタディとして，コード自動生成した部分と手動部分の切り分けとか，コーディング基準が維持されているかどうかとか，実は AspectJ の declare warning などの活用でやっていることに近い気がする．

関連研究として一番近いものが Conceptual Module．論理型言語を使ってモジュールを抽出するという点で同じ．次に Concern Graph．ただし，粒度が違っていて，Conceptual Module は正規表現での行単位マッチに制約されていたりConcern Graph はエンティティ間の関係が限られているといった理由から，提案手法が一番使いやすい，と主張している．わりともっともらしい．ただ，論理型言語の性能は，使える述語次第という気もするが．

その他の関連研究としては，Aspect Browser，Subject-Oriented Programming，データベースにおけるビュー管理やGrundy らのソースコードビューに関する非一貫性の管理とかが挙げられている．

_ カウンタ ▲

特に意味はないけれど日記にもカウンタを付けてみた．カウントされるのは私が一番多いかも．

_ Calendar ▲

hyCalendar 0.7.3 リリース．今回のリリースはグループウェアなユーザの人からの要望で，特定の日を選んで，周期的な予定から除外できるようになった．

GUI のマイナーチェンジといえばそれまでなのでまだ 0.8 にはしていない．

次は TODO の優先度設定や順序変更で 0.7.4 にして，それから読み込み専用機能や，複数ファイルの取り扱い問題を扱うか……．だいぶ先送りされている．複数ファイルを扱えるようになるとグループウェアに近い運用ができて面白そうなのだけど．

長くなってる読む論文キュー（現在２３本）と読書キュー（現在３冊）も早く片付けないといけない．

_ 読書 ▲

「AspectJ によるアスペクト指向プログラミング入門」読了．

感想はというと：・２章，３章が「振る舞いへの作用」「構造への作用」として dynamic crosscutting と inter-type declaration （と Static crosscutting）を区別していて親切． 特に，pointcut ごとの this, target, args などの内容が 日本語で解説されているのはリファレンスとして便利そう． 応用例として挙がっているのは・コンテキストの識別・キャッシュ・アクセス制御など．やっぱりこのあたりが自然に受け入れられるみたい．

面白いと思ったのが，MDA との関連性．ビジネスモデルと実装技術の統合をウィービングと考えて，MOF, QVT がウィービング記述だ，という考え方は，以前聞いた，ビジネスルールをアスペクトとして書いて~という話なんかよりはだいぶ自然に感じられる．

最後の７章は，パッチとしてのアスペクトの話．~tail/aspectj/ ではちょっとだけ，使えそう，という程度しか書いてないけれど，それをそこそこの規模のソフトウェアに適用するというケーススタディっぽいことをやっていて面白い．

やっぱり問題は統合開発環境からの支援が落ちること，理解容易性・予測可能性の低下あたりだろうか．こういうのを読むと，やっぱりアスペクトを使った表明記述の話とかをもう少し進めないとなぁ，と思うのだが，他の論文読みやら作業もたくさん．けっこう忙しくなりそう．

_ テンキー ▲

テンキーの仮想キーコードは VK_NUMPADx で VK_x とは違った．当たり前といえば当たり前かもしれないが．

外付けテンキーの NUMLOCK が入力したときだけ瞬間的に ON/OFF されるのが怪しいけれど．

_ 読書 ▲

「AspectJ によるアスペクト指向プログラミング入門」が研究室に届いたのでさっそく読むことにする．感想などは AspectJ 側の紹介ドキュメントとして更新される……予定．

鷲崎先生ありがとうございます．

_ 論文 ▲

Baowen Xu, Zhenqiang Chen:Dynamic Slicing Object-Oriented Programs for Debugging.

動的スライスへの適用論文．使っている手法は静的スライスの場合と変わってない．メソッドを，出力パラメータが依存する入力パラメータの集合，という形で各出力パラメータへの依存関係を設定している点とフィールドなどローカル変数以外の要素を入出力パラメータ扱いするところがいちおう新しいところなのだろうか．

_ 論文 ▲

Zhenqiang Chen, Baowen Xu:Slicing Object-Oriented Java Programs.ACM SIGPLAN Notices, Vol.36, No.4, pp.33-40, April 2004.

プログラムスライシングをオブジェクト指向プログラムに適用しようという論文．メソッド単位で PDG を構築して，メソッド呼び出し文が登場するごとに，そのメソッドの出力パラメータを基点にスライスを取った結果を加えていくという形になるらしい．内部実装が存在しない場合はすべての入力値がすべての出力値に依存するとみなす．フィールドは全部パラメータ扱い．

それ以外にも，スライス範囲をしぼったスライシングも提案している．Object Slicing が１個のオブジェクトに，Class Slicing が１個のクラスに注目したものらしい．どのくらい役立つのかは不明だが．

_ Calendar ▲

謎のバグ報告が一つ．EXE と同一のディレクトリにあるデータファイルが読めないor読む途中でエラーが出ているらしい．

とりあえず Exception.Message を吐かせるコードを追加して使ってもらうしかなさそう．WinXP Pro 環境で使っているのであまり間違いはないはずだが…．ファイルの配置されているディレクトリと中身のどちらが原因だろう？

_ Calendar ▲

フリーウェア収録した雑誌が２冊ほど届く．あんまりこの手の雑誌は買わないのでもらってみたのだが，もらっても読まない雑誌は読まない，という気がしてきた．

_ 論文 ▲

先ほどのつづき，関連研究だけ別に整理．この量はさすが TSE というべきか．

関連研究としては，Wilde, Scully らによるSoftware Reconnaissance での機能の分類法で・f が実行されるされないに関わらず実行されるもの・f が実行されるときに実行されることがあるもの・f が実行されるときは必ず実行されるもの・f が実行されるときは必ずかつそのときのみ実行されるものというような分類があるらしい．

また，静的情報を使う系統ではChen, Rajlich らによるCase Study of Feature Location Using Dependence Graph (IWPC95) というのが，ソースコードをグラフに抽象化するアプローチらしい．ただし，この論文の筆者らは，「どこから探していいか分かってないときには　この手法は向かない」としている．

Concept Analysis の活用についてはSiff and Repse: Identifying Module via Concept Analysis,Deursen and Kuipers:Identifying Objects using Cluster and Concept Analysisなど．

表示関係ではKoskimies and Mossenbock: Schenario-Based Browsing of Object-Oriented Systems with Scene.Lange and Nakamura: Program Explorer: A Program Visualizer for C++.Lange and Nakamura: Object-Oriented Program Tracing and Visualization.などが挙げられている．

_ [論文]Concept Analysis による機能の実装位置特定 ▲

Thomas Eisenbarth, Rainer Koschke, and Daniel Simon, Locating Features in Source Code, IEEE Transactions on Software Engineering, Vol. 29, No. 3, pp.210-224, March, 2003.

「ある機能を実行するテストケース」を実行して，各機能に対してどのユニット（関数 or クラスなど）が実行されたかを実行履歴から取得し，その結果に Concept Analysis を行うというもの．Concept Analysis を行うことで特定の機能に固有なもの，共有されているもの，といった情報が手に入るので，それと静的な関係図をもとに開発者が手動で Feature-Code マッピングを作成する．

「何をテストしているのか」という知識などが多少必要になること，最終的な分類は人手に頼ること，などが少し弱いといえば弱いが，それなりの結果は出ているようだし，アプローチも面白い．

ケーススタディにおけるルーチン間の接続などを見ると，相互に密な結合をしている部分とばらばらの部分があったりして，プログラムによってはかなり分類ができる可能性が分かる．

Concept Analysis 自体は学習も容易で便利だが，手続きなどを単位とするとConcept Lattice が大きくなってしまい作業しづらくなる，といった弱点はあるよう．

また，テストケースの選び方による偏りが生じるので，プログラム保守のタイミングなどで，「ここを直すのが一番影響が少ない」とかいったことを調べるにはこの手法は対応していない．（あくまで特定の機能がどこにあるかを理解することが目的で，　そのユニットが他の機能に関わるかどうかまでは考えない）

_ 学祭 ▲

洗って再利用する，リターナブル皿が推奨されているのは分かるのだけど，なぜ returnable なんだろう．reusable とかじゃない不思議．

_ 論文 ▲

Joel Winstead and David Evans:Towards Differential Program Analysis.Workshop on Dynamic Analysis. 9 May 2003.

プログラムの差分（主にバージョン間差分）を認識するタイプの解析方法が重要だ，という立場の position paper．

この筆者たちは，ふたつのプログラムの実行結果が変わるようなテストケースを見つけることが大事だろう，と言っていて，プログラム変更箇所から入力パラメータなどを simulated annealing など経験的手法で生成していく方法について紹介している．

生成した入力パラメータを使って実行してみて，評価として条件式の true/false を変えるような値に近いほうが優れている，とするらしい．いちおう小さな実験結果が載っていて，この判定基準を使うかどうかで，差分が分かるような入力セットを見つけられるかどうかの試行回数を大きく削減できるらしい．（300万回かかっても７割くらいの確率でしか見つからないものが　70万回くらいで発見できている）

……とはいえ，小さな手続き１個が相手で試行が70万回というのは多いか少ないかは意見が分かれそうだが，自動デバッグな世界の人らしい考え方な気はする．

_ Download ASCII ▲

サービス停止，のはずだった Download ASCII だが，サービス移管されるらしい．

移行先はシーサー株式会社．オンラインショッピング＆ブログサービスらしい．http://shop.seesaa.jp/

_ 論文 ▲

Rainer Koschke: Software Visualization for Reverse Engineering.Software Visualization, LNCS 2269, pp.151-162, 2002.

ソフトウェア可視化に関する Survey か Position Paper ．Software Visualization はソフトウェアを他の（グラフィカルな）表現にマッピングすることであるが，その方法として代表的なものにグラフとハイパーリンクがあり，特にグラフはほとんどの既存研究で使われている．

ところが，関数などを単位としたグラフを作ると高々５万行程度でも辺や頂点の数が5000~10000といった数になってしまうので，見せ方はとても重要．

また，ツールの構築では，以下のようなことに気をつけること，としている．

・意味が一貫していて理解しやすいこと．　たとえば UML なら，継承関係が上下方向に並ぶとか．・大きくなると，「すべてを一度に見る」のは現実的ではない．　「現在位置」のようなものが常に分かるように　しながらレンズでズームアップする，といった　メンタルモデルが重要．・保守作業などでは，システムはどんどん変化するので　変化に追随できる機能が必要．・大規模ソフトウェアの保守はチームワーク．　複数人が（できれば地理的に離れた場所でも）　利用できるようなシステムが好ましい．・同一のシステムを複数の perspective から見られるようにする．・静的特性，動的特性を両方とも扱えることが重要．・認知モデルの構築・相互運用性の実現

そのほか，何％くらいのツールが UML 表現だったりグラフを使っていたり，といった数値が載っていたが，それを見た限りではグラフが多いこと，UMLが意外と少ないこと，またアニメーションなどは稀だということ，くらいだろうか．

_ ライセンス占い ▲

ソフトウェアライセンス占い．http://u-maker.com/42212.html

面白いなーと思ったのが，質問への回答がテキストでの自由回答なところ．いったいどうやって判定しているんだろう．文字コードからの乱数とかではないのかなぁ．質問への答え方によるのかな？

_ ちなみに旧 BSD ライセンスでした． ▲

---以下，引用---旧 BSD ライセンスが適用された貴方は、落ち着いていて伝統重視の、とても洗練された人。時の厳しい選別に耐えた品のあるもの、優雅なものを好むタイプで、あくせくした暮らしは好きではないでしょう。といっても、それにふさわしいだけの心の余裕や、品位があればよいのですが、なかなか難しいかもしれません。浅ましく世間ずれした連中に出し抜かれてしまいがちで、経済的な生活レベルは普通かそれ以下になってしまうかも。慎ましく現状維持を念頭に置いた生活、そして侘び寂びや諸行無常の境地が、そんな貴方の日々の生活に自ずと潤いと美をもたらしてくれるでしょう。そんな貴方の恋愛面は、意外なことにとても積極的。俺が私がとどんどん自分をさらけ出し、相手に自分のエゴイスティックな刻印を残そうとするでしょう。でも大枠では、相手に合わせた恋愛をしていきそうです。

_ 読書 ▲

レイモンド・スマリヤン「パズルランドのアリス」文庫版の分冊１読了．

いわゆる論理パズル．分冊１は「不思議の国」のお話と登場人物を踏まえて展開している．解説が３分の１を占めていてけっこう丁寧だが，難易度の高いものもいくつか．もっとも，難易度が高くないと面白くないのだけど．ちょっとずつ時間つぶしに読んでいくのにわりとちょうどいい．

ちなみに原著名はAlice in Puzzle-LandA Carrollian Tale for Children Under Eightyらしい．

_ 論文 ▲

H.A.Muller, S.R.Tilley, M.A.Orgun, B.D.Corrie, N.H.Madhavji:A Reverse Engineering Environment Based on Spatial and Visual Software Interconnection Models.Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments, pp.88-98, 1992.

Rigi というプログラム理解のためのビューアを作った，という話．基本はコンポーネントのグラフ化とその操作．

・Strongly Connected Components の識別

・コンポーネントの共通クライアントの識別

・複数のコンポーネントから共通で利用されているコンポーネントの識別

・コンポーネントの近傍の識別

・コンポーネントが変更された場合の影響波及解析

・全体図の表示

・関係の一部だけを抽出して表示

・中心となるコンポーネントの表示

・コンポーネントの密集の識別

・接続されていないコンポーネントの識別

・モジュール品質の表示

といった操作を適用する．説明では，基本はコールグラフから開始するよう．また，共通のデータを操作する関数群を固めて表示とか，密接に関連しあった関数群ごとにグループ化して相互接続辺だけを見せるとか，そういった操作によって，開発者が効果的にプログラム理解を進められる，らしい．

依存関係の検出と，そこからの抽象化を別フェイズとして切り分けている．これは次の文献からの引用．R.S. Arnold. Tutorial on software reengineering.ICSM 1990, pp.12-19, 1990.基本はコンポーネント間の依存関係をグラフ上で整理してサブシステム抽出して，ということになるらしい．

_ 論文 ▲

Tamara Munzner:H3: Laying Out Large Directed Graphs in 3D Hyperbolic Space.

ノード数は指数的に増えるが，ユークリッド空間は多項式でしか増えないので空間が足りない，だから hyperbolic space 上で配置して，Focus+Context view というユークリッド空間への写像として扱う．

関連研究はいろいろ．2Dでノードを階層的に配置するもの，平面上にビルのように積み重ねていくもの，3Dで木を描画するものなど．

基本はグラフから spanning tree を構築してあるノードから隣接したノードを球面上に配置していって，それらを回転させて見ていく，という感じ．

意外とグラフ表示関係のアルゴリズムはたくさんあるらしい．

_ Calendar ▲

hyCalendar 0.7.3 が Vector で公開された．

こちらが送るの忘れていたのに，更新してくださったのだろうか．感謝 :-)

_ 論文 ▲

Davide Balazarotti, Mattia Monga:Using Program Slicing to Analyze Aspect Oriented Composition.FOAL 2004.

プログラムスライスでアスペクト間の干渉を検出しようという Position Paper．A1, A2 というアスペクトがあるとき，それらをスライス基点として計算した S1, S2 がA1 ∩ S2 = φ なら干渉なし，とする方法．ただし，スライスが正確でないと（冗長なコードを含むと）false positive が出てしまうし，誤ったスライスを計算してしまうとfalse negative が出てしまう．いちおうスライスツールを作っていて実際的な AspectJ プログラムに適用可能なJava バイトコードスライスを計算できるようにしたい，としている．スライスはどんどん発散してしまうので，効果のほどは謎．

_ 論文 ▲

Kiarash Mahdavi, Mark Harman, Robert Mark Hierons:A Multiple Hill Climbing Approach to Software Module Clustering.19th IEEE International Conference on Software Maintenance (ICSM 2003), pp. 315-324, Amsterdam, The Netherlands, 22-26 September 2003.

モジュール間の接続を重み付きグラフで表現したものを入力として，モジュールのクラスタを再構築する．評価関数は i = モジュール内部辺の重みの総和j = モジュール外部辺の重みの総和各モジュールについて，MF = i / (i + j/2 )全体の評価関数 MQ = Sum of MFと定義する．実験では，重みとして関数呼び出しや変数参照の回数を取っている．

ただし，MQ は正規化されていないので順序値としてしか使えないらしい．なので，改善度合いの評価については微妙．MQ がどのくらいよくなったか，ということから実際のモジュール構成がどのくらいよくなったか，という直接的な評価ができない．

_ 論文 ▲

論文というよりは article だが．

David Evans, David Larochelle:Improving Security Using Extensible Lightweight Static Analysis.IEEE Software January/Feburary 2002, pp. 42-51, 2002.

Splint（以前はLClint と呼ばれていたもの）の実装に関するお話．NULL ポインタによる問題やリソース解放忘れ，バッファオーバーフローなどを防ぐために，/* @notnull */ のような annotation をプログラムに付加しておいて手続き単位でのフロー解析を行うというもの．基本は pre/post condition 間の接続チェック．バッファオーバーフローに関しては，間違いやすい gets などの関数を使っているかどうか，というのと引数のバッファ長が文字列より長くなり得るかどうか，といった検査を行う．このあたり，かなり heuristics を入れて実用性の維持を重視しているらしい．false positive と false negative と両方出るが，false positive/negative のどっちかをなくすために実用性を失うのは嫌だ，ということで警告メッセージの一部をフィルタするといったことで対処しよう，ということらしい．

_ 論文 ▲

Jinlin Yang, David Evans:Dynamically Inferring Temporal Properties.ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tols and Engineering(PASTE 2004), Washington, D.C., June 7-8, 2004.

プログラムの実行系列（イベント列；基本はメソッド）からパターンを認識しよう，というもの．ここでのパターンは，いくつかのテンプレートのマッチで，関連研究の中には機械学習の手法やErnst, Cockrell, Griswold, Notokin によるDynamically discovering likely program invaliantsto support program evolution.などが挙げられている．

イベントパターンのテンプレートとしては，Response (Pが起こった後には，必ずSが起きる）　-- SPPSS は OK だが SPPSSP は不可OneEffect (Pが１回以上起きたら，１回だけ S が起きる） -- SPPS は OK だが PPSS, SPSS は不可といったものを用意して，P と S として使うイベントを選んで，それが複数のイベントトレースでどのくらい出現するか，ということを調べて，推論する．イベント列の順序について甘いのは，並行性を強く意識しているためのよう．

いちおう Producer/Consumer パターンで小さな実験をして，イベント間の関係をそれなりに認識できているみたい．しかし，大規模システムでは，多数のイベントが発生するので，P, S の組み合わせをどうするか，また大量の実行履歴に対するマッチをどうするか，という問題を抱えている．このあたりはさすがに position paper っぽい．

_ 論文 ▲

M. Daoudi, L. Ouarbya, Mark Harman, Chris Fox, M.P. Ward:ConSUS: A Scalable Approach to Conditioned Slicing.

conditioned slicing は，入力パラメータなどに対する特定の条件を与えて "conditioned program" を生成して，その上で静的スライス計算を行うことで，特定の条件に対するプログラムだけを抽出してくるというもの．

というわけで，重要なのは，与えられた条件に対してその条件を伝播させていく Symbolic Execute というステップ．制御フローをたどりながら，if, while, assert などを，常に true/false となる場合に限って，簡略化していく．

問題は，どのくらい時間がかかるのか，ということだが，色々な　if 文の構造を自動生成してコードサイズごとにどう変化していくかをテストしている．グラフを見た限りではだいたい n の自乗ペースで，多項式時間なのでまあ reasonable ではないか，と言っている．意外と時間がかかってないといえばかかっていない．

conditioned slicing の特徴が簡単に説明されているので親切な論文．