netail.net

_ [hyCalendar] 0.8.5 リリース ▲

プリンタ情報コンポーネントだけ更新してリリース．

_ [hyCalendar] アクセス違反 ▲

プリンタ情報コンポーネントが，プリンタ情報構造体のサイズが小さいものから大きいものへサイズを大きいほうに合わせてデータをコピーしていてこけていた．

発現条件は特定のプリンタがインストールされていること．問題が発生したPC上では「自動 Printer （Host上）」というのが原因だったが，他のPCでは必ずしも再現するわけではないよう．気づいたのもほとんど偶然．

最新版のコンポーネント（先週リリースされていた）では，問題のコード部分に，問題を回避するための条件分岐が増えていたので移行．0.8.5 としてリリースの予定．

_ [論文] クエリーとしてPointcutを指定する ▲

読もうとしてたらたまたま aosd-jp ML でも紹介されてたり．

Michael Eichberg, Mira Mezini, Klaus Ostermann:Pointcuts as Functional Queries. In The Second ASIAN Symposium on Programming Languages and Systems (APLAS 2004), Springer, LNCS.

Java などを XML 表現に変換してその上で XQuery を使えば，実は pointcut 言語と同じことができるよという感じのお話．

題材としては Kiczales の predictive control flow など．「draw メソッドの実行中に参照される（特定クラスの）フィールドの集合」を「ディスプレイの状態」とみなして「ディスプレイの状態が変更されたら…」と実装の詳細をある程度抽象化した表現に持っていきたい（と言いたいのだと思う）が，そういう pointcut を書くための道具立てとしてXQuery も使えるんですよという展開になってる．

とりあえず静的な pointcut だけに限定した話だが，まあそれなりの時間で計測もできているしこういうクエリーを pointcut 記述に使うのもいいでしょう，という話らしい．関連研究では dflow なんかも実現してみたいとか，Josh のようなメタプログラミングは難しいですよとか，色々．

この論文の主旨ではないが，pcflow は，不用意に書くと「draw から参照されるフィールド集合」の中に無関係に貼りついたアスペクト（たとえばキャッシュ処理とか）が勝手に導入したフィールドまで含まれたりしそうで怖そうでもある．きっと便利だし，あれば使う機能だと思うのだけど……．フィールド集合が静的に解析できるなら自前でチェックもできるし，大丈夫……かな？

_ 地震 ▲

大阪府北部（部室）では震度４．本棚の縦板がずれて（！）中板が傾いた．損傷度合いについては未評価．

_ [AspectJ] aosd-jp ML 解凍(?) ▲

aosd-jp ML が，久々に動き始めてる．アスペクトの使い方にはどんなものがあるか，分類的な話など．

"凍った" ML が再び動き出すときは"溶けた" って表現するのだろうか．謎．

まだ完全に溶けたとは限らないけど．

_ 地震 ▲

真夜中に再び地震で目を覚ます．今度もM7.3規模自体はけっこう大きいみたい．震源が直下とかでないから震度５程度で済んでるのだろうけど．

……部室の本棚は大丈夫かな？

_ [論文] IWPSE ▲

IWPSE2004 が無事終了．

今回の収穫（？）というか好感を持った論文は，以下の２本．

Vibha Sazawal, Miryung Kim, and David Notkin:A Study of Evolution in the Presence of Source-Derived Partial Design Representations.Proceedings of IWPSE2004, pp.21-30, Kyoto, Japan, September, 2004.

注目したソースファイルに対して，そこから抽出できる低レベルの（具体的な）情報が変更支援に役立ちます，という話．どんな型を使っているか，インスタンス化しているか，戻り値として受け取ったオブジェクトをどうキャストしているか，といった情報を抽出して提示する話．

Giuliano Antoniol, Massimiliano Di Penta, and Ettore Merlo:An Automatic Approach to identify Class Evolution Discontinuities.Proceedings of IWPSE2004, pp.31-40, Kyoto, Japan, September, 2004.

プロジェクトの履歴において，途中で現れたクラスや消えたクラスが，他のどのクラスから分割されたのか，あるいはどのクラスへ吸収されたのか，同じ実装のクラスの名前が変わったのか，といった情報をソースコードのベクトル表現から角度を求めて推定するという話．

_ それから，引用するかも（？）文献として１本． ▲

Nguyen Truong Thang, Takuya Katayama:Handling Consistency of Software Evolution in an Efficient Way.Proceedings of IWPSE2004, pp.121-130, Kyoto, Japan, September, 2004.

基本はソフトウェアの変更に対してP で成立する性質 p が，変更を加えた P+E でも成り立つかCTL logic を使って調べよう，というもの．

変更として，feature-based software に注目していて，いくつかのプロダクトファミリで同じ性質が保持され続けるか，といった検査に使うのかな，というところ．アスペクトによってプログラムが壊れないかの検査にも使えそう．

_ [日記CGI] 活動予定 ▲

微妙に右側に活動予定が出るようにしてみた．XMLから日付タグの中身でフィルタしてHTMLにして出すだけなので，実装は約１時間半．

XMLの編集とかのCGIは今のところ用意していないので，ちょっと編集は面倒だったりするのだが．

_ Power Point 発表時間計測ツール ▲

朝起きてからホテルチェックアウトまでと，飛行機待ちの時間で作ってみた．

Power Point 標準のリハーサルモードだと，時間記録した結果が１個分だけな上，選択を間違うと以降のスライド再生に使ってしまうのであまり好ましくないということで，各スライド切り替えごとに時間を記録する単純な実験バージョンを構築．

Power Point の COM オブジェクトのインタフェースが Borland Delphi に用意されていたので，OnSlideShowBegin と OnSlideShowEnd，OnSlideShowNextSlide イベントハンドラを定義したらなんか簡単にできてしまった．

Power Point と一緒に起動して（EXEとどちらが先でもOK），あとは普通にプレゼンテーションを起動するだけというお手軽ぶり．さすが付属ライブラリ．

いちおうローカルでテストはしたので，他のPC上でも動くことを確認したら公開の予定．

_ METRICS 2004 ▲

METRICS 2004 のほうは，プロセスに関するメトリクスが主体でプロダクトに関するメトリクスはほとんどなし．

メモしとこうと思った話はSystematic Review についての基調講演くらい．

evidence based な医学でのレビューを題材に，ソフトウェア工学でも客観的なレビューが大事だろう，という講演．

systematic なレビューの利点として結果の公平性や，作業経過や判断の透明性を挙げている．欠点は少ないが，レビュー方法自体の説明が長くなるのでショートペーパーなどとして出しにくいこと，複数人でのレビュー結果を付き合わせるので人数，労力がかかることを挙げている．

publication bias （「都合の悪いことは書かない」ことによる偏り）に気をつけながら過去の研究から用語やリソースを探して，情報ソースの品質の評価基準や情報抽出方法なども考える必要がある．

また，他の研究との違いを構造的なテーブルとしてまとめたり，結果に対するコメントを受け取る方法を作ったりといった作業も重要らしい．

ソフトウェア工学では，しばしば実験室的環境で，学生が被験者であること，タスクが人工的であること（いずれもランダムではない）が難しいところ．質問として，医学では個人単位だがソフトウェア工学ではプロジェクト単位なので扱いが難しいのでは，といった話や，学生にレビューさせる場合は相互に影響しないように個別にレビューを行わせるような注意が必要だ，といった話なんかも出ていた．

_ [論文] ICSM 2004 まとめ (7) ▲

T12: Metrics for Maintenance より．

R. Marinescu: Detection Strategies: Metrics-Based Rules for Detecting Design Flaws.

メトリクス値を基準にデザイン上の問題を探そうというもの．God Class はLOCが100行以上で，メンバ数が上位25％に入っていて，…といった形で条件を記述して，該当するクラスを探す．

バージョン更新で，Bad-Design がなくならなかったら直し方が悪いか評価関数が悪いかで，バージョン更新で問題が新たに生じたら調査が必要，といった感じに使うらしい．

実験もしていて，「疑わしい」として出るもののうち，50％〜80％くらいは本物だった，らしい．うまく関数を作るのがかなり大変そう．

Z. Wen, V. Tzerpos: Evaluating Similarity Measures for Software Decompositions.

ソフトウェアをサブシステムに分解したとき，人間の評価と比較したいが，その評価基準を提案したもの．

普通なら，分類 A と B が与えられたとき，A から B に，要素の移動と集合の合成で変換するスクリプトの長さ (MoJo）を使うが，これでは依存辺の情報が反映されないので，クラスタ内の辺とクラスタ外の辺，という情報を使って要素移動に重みをつける，ことを提案している．

提案としては妥当っぽいが，ケーススタディなどはこれから，らしい．

T13: Empirical Study より．

J Luo, R Jiang, L. Zhang, H. Mei, J. Sun:An Empirical Study of Two Graph Analysis Based Component Capture Methods for Object-Oriented Systems.

システムをサブシステムに分解する手法のうち，グラフから重みの小さい辺を取り除いていくトップダウンな手法と，依存関係が「固まっている」ところを１つの塊としていくボトムアップな手法を比較実験したという論文．

結果としては，ボトムアップに構築したほうが時間はかかるが，良好な結果が出たらしい．それでも手動の分類には遠くて，人間は意味的な情報に基づいた分類をしているのでグラフの構造だけに基づいた分類方法ではやはり苦しいのではないか，と言っていた．

_ [論文] ICSM 2004 まとめ (6) ▲

Tools III より．

F. Balmas: DDFGraph: A Tool for Dynamic Data Flow Graphs Visualization.

動的なデータフローをグラフ化する．Lisp で実装．関数呼び出しの，引数と戻り値，本体を表現するノードをデータフローで接続する．粒度を適切に操作すれば，何となく便利そう．

W. Abdelmoez, M. Shereshevsky, R. Gunnalan, H. Ammar, B. Yu, S. Bogazzi, M. Korkmaz, A. Milli:Software Architecture Change Propagation Tool (SACPT).

A が変更された → B が変更された，という伝播確率を計算してマトリクス表示するというもの．

他へ伝播しやすいものは変更すると危険なもの，他から影響を受けすぎるものは将来も頻繁に変更される，といった推測をするのに使うらしい．

伝播確率の計算方法などはちょっと不明．

また，プログラムには入ってなかったが，Ducasse: Re-engineering Tool Moose の紹介をしていた．言語非依存のリポジトリ＋メトリクス計算ツール＋解析ツール用API といった感じで，クラスのメトリクスなどを計算・統計するための基盤ツールらしい．BSD ライセンスで公開中とか．

_ [論文] ICSM 2004 まとめ (5) ▲

T10: Configuration Management より．

A. De Lucia, F. Fasano, R. Oliveto, G. Tortora:Enhancing an Artefact Management System withTraceability Recovery Features.

IR手法によって，ドキュメントを探してきてソースコードに関連付けるという話．人間の評価と比較している．正解はそれなりだが，実用性という観点では微妙か．

T11: Program Comprehension and Visualization より．

F. Van Rysselberghe, S. Demeyer:Studying Software Evolution Information byVisualizing Change History.

バージョン情報の可視化で，ファイル軸と時間軸を取って，各タイミングで変更されたファイルのところに点を打って，同時に変更されているファイルといったパターンを探しましょうというもの．メーリングリストとの対応付けで検証している．応用としては，問題の修正方法を学ぶなど．

ファイルの名前変更や合成が起きたらどうなるのか，といった質問があったが，確実にそれと分かるわけではないが，途中でぴたっと変更が止まったりするので分かる，といった感じの応答をしていた．

C. Dang, A. Le, A. Michail, K. Pham, T. Pham, N. Seow, A. Sridhar, J. Timm:Design Recovery Tool of Real-Time Graphical Applications Using Video.

連続的な画像キャプチャとプロファイラを組み合わせて，プログラムのどの部分とグラフィック動作が関連づいているかを調べるというもの．一度呼ばれてから一定時間内にまた呼ばれる，というものを把握して，アニメーションに関連づいているのではないかと推定したりするらしい．

_ [論文] ICSM 2004 まとめ (4) ▲

Short Paper Session I より．

E. Merlo, G. Antoniol, M. Di Penta, F. Rollo:Linear Complexity Object-Oriented Similarity for Clone Detection and Software Evolution Analysis.

クラスの要素の各メトリクス値から平均値を取り出して，「中心」を見つけ，他と比較するという話．「ハッシュか？」と聞かれて，値は１つではないと答えていたのでベクトル表現だというほうが正しいのか．ケーススタディで false positive が出ていないので，入力データの特性なのか不明だが，だいぶ叩かれていた．

T. Everitt, R. Tvedt, J. Tvedt:Validating and Improving an Existing Software Architectural Evolution Process.

Reflexion Model みたいな感じで，モデル上に定義されたのにコード上に出現していない依存関係，モデル上に定義されていないのにコード上に存在する依存関係を図示しましょうという話．

L. Tahvildari, K. Kontogiannis:Developing a Multi-objective Decision Approachto Select Source-Code Improving Transformations.

どこかの論文で定義したプログラム変換のメタモデルを使っていて，目的の品質を達成するために「小さな変更」列を探しましょう，というもの．リファクタリング手順を動的に探索するといった感じ．

_ [論文] ICSM 2004 まとめ (3) ▲

T4: Testing より．

M. Galli, M. Lanza, O.Nierstrasz, R. Wuyts: Ordering Broken Unit Tests for Focused Debugging.

使っているメソッドの種類が包含関係にあるとき，一方がエラーだともう一方もエラーになりやすい，ということをケーススタディで確認している論文．テストケースの順序設定なんかに使う．将来的には他にも展開したいらしい．

T6: Slicing and Change Analysis より．

S. Raghavan, R. Rohana, D. Leon, A. Podgurski:Dex: A Semantic-Graph Diffrencing Tool in Large Code Bases.

Abstract Semantic Graph の差分（edit script）を計算して，意味的な差分情報（ローカル変数が追加された，など）を抽出する．回帰テストや，変更の理解なんかに使えるのではないかという提案．

_ [論文] ICSM 2004 まとめ (2) ▲

T3: Program Comprehension より．

M. Salah, S. Mancoridis: A Hierarchy of Dynamic Software Views: From Object-Interactions to Feature-Interactions.

SMQL というコードで取得する実行シーケンスを指定して，各featureがどのオブジェクトを生成するか，あるいは他のfeatureのオブジェクトを使用するか，ということからfeature間の関係を取り出そうというもの．

発表を聞いた限りでは，featureの定義がいまいち不明瞭．また，質疑応答では，いくつテストケースを実行すれば十分なfeature間の関係が分かるか，などといった質問が出ていた．

A Rountev: Precise Identification of Side-Effect Free Methods in Java.

定めたクラス集合の境界内での副作用解析．100％正確と本人は言っていた．

A. Rostkowycz, V. Rajlich, A. Marcus: A Case Study on the Long-Term Effects of Software Redocumentation.

プログラムにドキュメントを付け加えていくと徐々にコンポーネントの変更にかかる時間が短くなり，またドキュメントをつける速度も早くなっていく，という話．数年にわたるケーススタディで，変更に応じてドキュメントをつけていくと数年でだいたい８割がたのコンポーネントにはドキュメントがきちんと付いたらしい．

_ ICSM 2004 まとめ ▲

ICSM/METRICS 2004 が無事終了したところで情報整理．Ira Baxter の Program Transformation の Tutorial．

full automatic tool よりもhighly configurable tool がいい，と言いながらプログラム変換のモデルについてと，自分たちで作っている Design Maintenance System ではどんな選択肢を取ったか，といった話．

requirement = functional (What) + performance (How well) という考え方がわりと面白いかも．性能以外の要求は基本的に functional であるととらえているみたい．

プログラム変換系の大規模ソフトウェアへの適用を真剣に考えていて，変換系を作るのは難しい（例として１人年程度のプロジェクトが挙がっていた）が，それでも手動で移行するコストよりは低い，と主張していた．

また，XML などでASTを表現すれば楽だと言う人間もいるが，処理系を作る人間が楽をするぶんユーザが苦労するので，言語処理系を作る人が多大な努力をして他の開発者の仕事を楽にすることが重要だ，とも言ってた．

なんというか，言語処理系の構成とかよりもなぜ重要なのかという姿勢の話がメインだったような気がする．

_ 携帯切り替え ▲

端末の電源が突然切れたりして物理的に寿命が近いようなので，これを機会にFOMAに移行してみた．番号などは変わらず．

_ [論文] メタクラスの互換性問題 ▲

Noury Bouraqadi-Saadani, Thomas Ledoux, Fred Rivard:Metaclass Composability.Composability Workshop held in conjunction with ECOOP 96.

前に読んだ OOPSLA の論文でのメタクラスの互換性問題について述べていた論文．

Upward Compatibility は，親クラスがメタクラス情報にアクセスしているとき，子クラスは自分自身のメタクラスにアクセスすることになるが，このときにメタクラス同士は直接関係ないので困ったことになる（直接は関係なくてもメタクラス間できちんと関係を維持しないといけない）という問題．

Downward Compatiblity はメタクラス間の継承関係が，クラス側に影響を及ぼしてしまう問題．

また，複数のメタクラスを同時に使うときにはそれらを合成するメカニズムが必要である（たとえば多重継承など…）．

で，この人たちは，メタクラスからのインスタンス生成（self.new）とクラスからのメタクラス取得（self.class）とがベース・メタレベル間を移動する瞬間なので，そこを Metapipe というポイントとして何らかの取り扱いをすればよさそうでは，という提案をしている．

AOP的な文脈に置き換えられるかな？と思ったのだが，アスペクトの動作をメタレベルへの移動ととらえられないことはないかもしれないが，アスペクトの中でベースレベルに「降りる」移動のほうがいつなのか，というのは明確には言いづらいのかも．

_ [論文] オブジェクト指向対応の差分計算アルゴリズム ▲

Taweesup Apiwattanapong, Alessandro Orso, Mary Jean Harrold:A Differencing Algorithm for Object-Oriented Programs.Proceedings of the 12th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE 2004),Newport Beach, CA, USA, November, 2004.

言語のsemanticsまで考慮した diff を作りましょうという話．クラスおよびインタフェースの対応をとって，メソッド単位の対応をとって，メソッドの中身では制御フローグラフのノード間の対応を取る．

クラスは基本的にはパッケージ名まで含めた名前比較だが，メソッド単位ではシグネチャを優先しつつ，名前だけでの対応も作る．メソッドの中身は，制御フローグラフをベースに比較する．

制御フローグラフでは，メソッド呼び出し文ごとに，dynamic binding の結果でどのメソッドに行くか分岐情報を持ったようなグラフを作っている．で，Hammock という Signle Entry Single Exit な部分グラフを見つける．要は，メソッド内の制御フローで，「どんな条件でも必ず通過するノード」を識別して，その部分を「Hammock Node」という集約された形に置き換える．で，それを繰り返していって全体の簡略化された制御構造を取り出す．あとは Hammock Node 間の類似度とかで計るみたい．

従来のマッチングアルゴリズムに比べると，マッチするノード数はだいぶ増えているらしい．時間は，20000ノードぐらいのプログラムで5分かそこらなので，そこそこの時間はかかるみたい．

わりとアルゴリズムの計算量とかについても述べていてかなり真面目で，よさそうな論文．diff について引用することはないと思うが，この人たちの Hammock のアイディアは（もっと前の論文で出ているものだが）どこかで使うことになるのかも．

_ [論文] feature 実装位置の特定作業 ▲

ICSM のどれかの研究で引用されてて，なぜか放置してた論文のメモ．

Chen, K. and Rajlich, V.:Case Study of Feature Location Using Dependence Graph.Proceedings of the 8th International Workshop on Program Comprehension (IWPC 2000), pp.241-249, 10-11 June 2000.

ASDG (Abstract System Dependence Graph) を使って，特定の機能を実装したソースコード位置を特定するfeature location の支援には，グラフを展開しながら閲覧するという形のツールが必要だろう，グラフ全体を把握しつつグラフの一部だけを見ていくのがいい，といった種類のことを言っている論文．

実際にはグラフが大きくなりすぎるので，頂点の集約とか何か色々な工夫が必要なのだろうけれど．最終的に生データ（ソースコード）に近づいていくことになると思うのだが，ソースコードに近づくほどグラフよりもソースコードのほうが理解が早くなったりしないのだろうか．

_ [PptWatch] PptWatch: Point 発表時間計測ツール ▲

もういい加減ハンドルである意味がなくなってきたので大学のサイトで公開することに．http://sel.ist.osaka-u.ac.jp/~t-isio/pptwatch.html

人柱募集中とか書いたりすると誰も使ってくれなさそうなので，使い方だけ書いて置いておくことにする．

_ [hyCalendar] 0.8.6 向け機能追加 ▲

次バージョン向けに，久々にコーディング．とりあえず昨日から５，６時間かけて実装したのは次の通り．他にどこまで組み込むかは未定．

・表示ツールバーの日付入力ボックスなど，一部でIME無効化．・装飾文字列の情報が，ハイパーリンク文字列の後で消えてしまう問題を修正．・「ハイパーリンク対象文字列も装飾文字列の効果に従う」オプションを追加．・フリーメモ，TODOエリアを最小化すると，復帰しないことがある問題を修正．・右クリックからのポップアップで [この日付に色を塗る] メニューを追加．・右クリックからのポップアップで [この日付の色をパレットに抽出] メニューを追加．・ファイル保存後も「元に戻す」を有効に設定．・[表示]メニューに，フリーメモ，TODOリストを追加．・[終了時のウィンドウ位置を保存する]を[終了時のウィンドウレイアウトを保存する]に変更． 有効なときはフリーメモ，TODOリストの表示状態を保存する．

_ [hyCalendar] 0.8.6 リリース ▲

これ以上機能追加するときりがなさそうなので，0.8.6 としてリリース．

いーかげん機能的には満足してきたので，次はやはり「タスクトレイへの常駐」だろうか．

Outlook とのインポート／エクスポートに対応してみるのも技術的には面白そうなのだが，使わないツールを作ってもまったくうれしくないのが難点．

ちなみに，0.8.6 をエンターブレイン様のフリーウェア年鑑にも収録していただく予定．致命的なバグとか出なければいいけど…．

_ [論文] EIWASワークショップ ▲

EIWAS'04: 1st European Interactive Workshop on Aspects in Softwarehttp://www.topprax.de/EIWAS04/

というのが開催されていたらしい．あんまり時間がないので，ざっくりメモしておく．

「AOP considered harmful」というパネルでは，advice と対比する形で "come from X" （goto文の逆で，「行 X が実行されたらここに来る」という文）を見せて，アスペクトの濫用の危険性について言及されている．

また，Rémi Douence による， AOP はどんなものか，といった論文が出ていた．AOP そのものはコード再利用が主目的ではないとか，AOP を非機能的要求以外にも使ってるじゃないか，とかベースプログラムの意味を変えるべきではない（プログラムの持つ不変条件に違反しない）とか．

Kasper B. Graversen らによる「アスペクトのアスペクト」はどうだろう，という話もあって，pointcut や advice 定義自体もinter-type declaration できるべきではないのか，みたいな話のよう．

Kris Gybels, and Andy Kellens: An Experiment in Using Inductive Logic Programming to Uncover Pointcuts.これは，アスペクトを既存コードから抽出するときに，とりうる Join Point の組み合わせと結果の Pointcut とを比べるとかして正しく join point を選べるように，とか言っている．

Christian Koppen, Maximilian Stoerzer:PCDiff: Attacking the Fragile Pointcut Problem.こちらは，クラス名やメソッド名の変更によって，pointcut が影響を受けていないか検出しましょうという話．ようやく出てきた？という気もしなくはない．ただ，分かったところで，変更に追随すべきか，すべきでないかを判断するのは難しいのだろうけど…．

István Nagy and Lodewijk Bergmans:Towards Semantic Composition in Aspect-Oriented Programming.attribute (いわゆる javadoc 系のタグ）ベースでpointcut を記述したほうがいいのでは，という論文．こちらのアプローチのほうがPCDiffのアプローチよりも安全そう．属性を付けるルールが明示されていて，間違った属性を付加することがなければ，という限定は付くが．

_ [論文] 実行履歴の図示 ▲

どこかで読んだはずなのだがメモしてなかったみたいなので書いておく．

Dean F. Jerding, John T. Stasko, Thomas Ball:Visualizing Interactions in Program Executions.ICSE 97, pp.360-370, Boston, MA, USA, 1997.

実行履歴を可視化するために，メソッド間の呼び出し関係を接続した地図のようなグラフを表示したり，横軸に時間，縦軸に呼ばれたメソッドをプロットすることで呼び出しパターンを可視化したりということをしている．

_ [論文] トレースデータの抽象的な表示 ▲

Robert J. Walker, Gail C. Murphy, Bjorn Freeman-Benson,Darin Wright, Darin Swanson, Jeremy Isaak:Visualizing Dynamic Software System Information through High-level Models.Proceedings of OOPSLA 98, pp.271-283, Vancouver, B.C., October 1998.

実行トレース情報を，抽象化されたビューにマッピングしましょう，という話．手法としては，上位のコンポーネント（サブシステムなど）を適当にドキュメントなどから見つけてきておいて，開発者は，実行トレースからコンポーネントへのマッピングを宣言的な言語で記述するというもの．

基本的には実行中，時間的にある程度限られた範囲でシステムの中をどのように実行が進んでいるかを見るが，それがどのようなコンテキストで起こったのか，という全体像のようなものがないと使いにくい，ということと，やはりその時点でのスタックの中身および実行中のコードへのリンクみたいなものも必要だ，といった結果がケーススタディの結果として議論されている．

_ [論文] トレースデータの活用 ▲

Johan Moe, David A. Carr:Using Execution Trace Data to Improve Distributed Systems.Software Practice and Experience, Vol.32, No.9, pp.889-906,25 July 2002.

分散システムの開発時に，トレースデータを集めて使ったという話．・長期間のカバレッジ観測でまったく　実行されていないメソッドが見つかった・頻繁なリモートメソッド呼び出し（主にコレクションの取得）を　発見し，修正した・動的メトリクスなどを使ってオブジェクト間の強い結合を見つけたといった感じで使われたらしい．短期間だけでなく，長期間（数日，あるいはそれより長い単位）でトレースデータを使うというのは珍しいかも．

参考文献リストをちらっと見た限りでは，システムの可視化やメトリクスなどへの論文のポインタとして便利そうな感じ．

_ [論文] 依存関係の管理 ▲

S. Ducasse, M. Blay-Fornarino, A.M. Pinna-Dery:A Reflective Model for First Class Dependencies.Proceedings of OOPSLA'95, pp.265-280, Austin, TX, USA.

オブジェクト間の依存関係を，First-Class なエンティティとして管理しましょうという論文．FLO という言語を提案していて，オブジェクト間のリンクを記述する．

たとえば，stack への pop 呼び出しが，memory オブジェクトに store された結果を返す場合，「(pop :stack) implies (store :memory :result)」といったように記述する．関連付け自体をインスタンス化する必要がある点は，association aspect なんかの使い方と同じ．

・オブジェクト間のインタフェースにのみ規定されるので　カプセル化は守られる．

・関連は動的に生成，チェック，破棄される．

・オブジェクト間に双方向のリンクを貼ることができる．（ある一方の変更が他方へ伝わるなど．アドバイスの動作に近い）

・リンク自体が first-class なので，リンク間のリンクなんかも定義できたりする．

propagation が伝わっていく途中でループが起きた場合は，リンクごとに停止用の invariant を書くか，割り込み処理のようなメカニズムを使うらしい．

で，MOPを使った実装の話が載っている．

関連研究については，クラス間の相互通信インタフェースを記述する手法ではクラスの仕様情報が他のクラス定義にまで分散してよくない，また，オブジェクト間のインタラクションの制約を記述すると制約自体がカプセル化を破壊してしまう，などとも言及している．

_ ガーデンフィールズ ▲

もらった庭園の鑑賞タダ券の期限が９月いっぱいだったので，宝塚ガーデンフィールズに行ってきた．

だいぶ植物は育ってきていたが，今の時期は花はあまり咲いてないので見所は少なめ．また時期をずらして行きたいところ．

入場時に，開場１周年記念の絵葉書をもらった．

_ V:tR ▲

シカゴのおもちゃ屋さんで売ってた「Vampire: the Requiem」は，どうやら World of Darkness の世界を一度リセットして仕切りなおしの新ルールブックだったらしい．

立ち読みしただけなので Vampire: the Masquerade から何が変わったのかは不明だが．Amazon.co.jp で約4000円のところが600円引きになってた．

そこそこの厚さのルールブックなので，今のところ手は出したくないけど．

_ WAOSD ▲

Net.Object Days と，Workshop on AOSD の論文いくつかをチェックリストに追加．http://www.fit.ac.jp/~zhao/waosd2004/

SPA-SUMMER で発表した動的解析のプロトタイプの実装を進めつつ，論文のほうも10月末の OOPSLA，FSE までには消化する予定．（別に参加するわけではないのだが）

_ [論文] Before/After の合成 ▲

Ira R. Forman, Scott Danforth, Hari Madduri:Composition of Before/After Metaclasses in SOM.Proceedings of OOPSLA 94, pp.427-439, Portland, Oregon, USA, 1994.

Before/After メソッド（AspectJでいう before/after advice）を複数同じクラスにくっつける場合にはどうしたらよいか，というので・メタクラス２個を順序付きで合成したメタクラスを作って，　それをインスタンス化したクラスを作る・合成したいメタクラスを個別にインスタンス化した　クラスを作って，それらのクラスを多重継承・一方のメタクラスをインスタンス化したクラスを継承して　クラスを作り，そのクラスにもう一方のメタクラスをくっつけるという手法があるが，メタクラス２個を順序付きで合成したメタクラスを作るという方法が，関係が明示的で良い，というふうに言っている．

ただ，３個以上のメタクラスを合成するときの結合規則の問題（A(BC)と(AB)Cが等しい振る舞いをする）や，他にどのメタクラスがかかわっているか分からないのでC=AB, D=BA といったメタクラスがあるときにE=CD を作って貼り付けると ABBA と同じメソッドが２回ずつ動いてしまったりする問題がある．また，read-onlyなメソッドに対してのみ動きたいとか，条件付きのメタクラスも存在する上，本来動くべきメソッドを動かしたくないメタクラスも扱っていく必要がある．

クラスが名詞ならメタクラスは形容詞に相当する，とかいう言い方をしているのは面白いところだけど．

_ 宅配便待ち． ▲

宅配便を待ちつつ家で作業．今日明日で２つ荷物が届くので，拘束時間が若干長い．

近所のコンビニに行ったらRPG研の後輩がバイトしてた．下宿が近いから，たしかに遭遇してもおかしくないのだけど，下宿の近所で出会ったのは初めて？# あまりに久しぶりで忘れてるだけかも…．

_ [hyCalendar] 追加機能 ▲

hyCalendar に対する機能提案をいただいた． 1. 月をまたがっても連続して変化していくようなカレンダー表示 特定日を中心に前後１ヶ月のような表示方法．月単位でタブ表示をしているのだが，各タブごとに「表示基準日」を持っているので，うまく新しいタブを生成する方向に持っていけば作れなくはなさそう．本当はスクロールバーやボタンなど，ちょっとした動作でカレンダーが一週間単位でずれる，というのが理想だったりするのだが． 2. 検索ボタンでの前へ移動 実は「次へ移動」しかサポートしてなかったりするので，これは素直に対応したほうがよさそう．ツールバー的にも，前に戻るボタンを付けるだけでいけるので簡単． 3. 期間予定のカレンダーの何日後・何日前が欲しい 開始日を基点に，n 日間 (0日なら当日終わり，負なら過去）で情報を設定する方法．これはユーザインタフェース的には簡単だし妥当な設定．GUIのコンポーネント配置的にも何とかなりそうなので対応してよさそう． 4. フリーメモのポップアップ若しくは表示・非表示 とりあえずフリーメモエリアを消せるようにはなったのだが，別ウィンドウとしての表示（あるいはショートカットでの切り替え）というのには対応してない．テキストの同期が面倒だから．フリーメモの表示・非表示切り替えにショートカットキーでも割り当てておこうか．とりあえず優先度は高くない． 5. 期間予定のカレンダー・表示セレクトカレンダーを月曜スタートに． 日付入力欄が表示するミニカレンダーは，日曜開始で固定されている．月曜開始オプションを有効にしたときは月曜始まりで表示したい，というもの．プロパティがないので無理かなーと思っていたら， http://www.sugi-family.net/papanvb/vbnet_tips.asp?cate=23&tips=23001に方法が書いてあった． DropDown イベント時にカレンダーが生成されるので，DTM_GETMONTHCAL メッセージでカレンダーオブジェクトのハンドルを奪ってきて，MCM_SETFIRSTDAYOFWEEK メッセージで開始日付をセットできる． VB用のものをDelphiに書き換えると次のような感じ．

procedure 
  TForm1.DateTimePicker1DropDown
  (Sender: TObject);
var 
  handle: THandle;
begin
  handle := DateTimePicker1.
             Perform(DTM_GETMONTHCAL, 0, 0);
  if not (handle = 0) then begin
    // 火曜日始まりにする例
    SendMessage(handle, 
                MCM_SETFIRSTDAYOFWEEK, 0, 1);
  end;
end;