netail.net

_ [論文]実行経歴の特徴抽出 ▲

M. J. Harrold, G. Rothermel, K. Sayre, R. Wu, L. Yi:An Empirical Investigation of the Relationship Between Fault-Revealing Test Behavior and Differences in Program Spectra.Journal of Software Testing, Verification, and ReliabilityVol.10, No.3, pp.171-194, September, 2000.

プログラムの実行系列から，どのパスを通ったか，各ブランチでどの経路を何回ずつ選んだか，といった実行系列の特徴を取り出そうという試み．

なんか振る舞いが少しでも違うプログラムだとけっこう違う値には変わるみたい．ただ，変わったからといってどうだというのか，というのがある．使用法としては，実験的にソフトウェアのバグがどの特徴と関連するかを調べるということになるのだろうか．

いまいち役立つのかどうか不明．

_ [論文]実行パスへのＩＤ割り当て ▲

The Use of Program Profiling for Software Maintenance with Applications to the Year 2000 Problem.Proceedings of the 6th European Software Engineering Conference held jointly with the 5th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE97), pp.432-449, Zurich, Switzerland, September, 1997.

2000年問題に対処するために（それ以外にも使えるが）各テストケースがプログラムの実行パスのどこを通ったかプロファイルする，という話．

実行パスの各分岐点に，それが二分決定木であるかのように，選んだ経路に応じた数値加算を埋め込んで，終点まで到着した時点でパスのIDが得られるようにする．

あとは，テストケースごとに数値が出てくるので，それをスペクトルのように並べて比較したりとかして問題のパスを特定したりする．

_ [論文]依存関係のテスト容易性への影響 ▲

Stefan Jungmayr:Identifying Test-Critical Dependencies.Proceedings of the 18th International Conference on Software Maintenance (ICSM 2002), pp.404-413,Montreal, Quebec, Canada, 2002.

テストを難しくする要素として，コンポーネント間の依存関係があるが，ある依存関係を取り除いたときの依存関係のメトリクスの減少度合いを比較し，減少が大きいものを Test-Critical な依存関係として認識しよう，というもの．

依存関係のメトリクスとしては，この論文では各コンポーネントが直接あるいは推移的に依存するコンポーネントの平均個数 ACD を使っている．

実際，ACDを減少させる度合いで上位の１０％くらいの依存関係を取り除くと ACD の値は半分くらいまで落ちたりする．このような依存関係の要因は，主にデザイン上の悪い決定，GUI上でのウィンドウ間の遷移の実装，などだったらしい．ACD は結合度メトリクスCBOなどとは相関が少なく，CBOは実はテスト容易性とは関係があまりないのでは，とも言っている．

設計時に，このようなテスト容易性にかかわる依存関係を考慮して，設計を考え直すことで，テスト容易性を少しは向上できるかもしれない．

_ [論文]現在実行しているコードの表示 ▲

Kazimiras Lukoit, Norman Wilde, Scott Stowell, Tim Hennessey:TraceGraph: Immediate Visual Location of Software Features.Proceedings of International Conference on Software Maintenance (ICSM'00), pp.33-39,San Jose, California, October, 2000.

ソフトウェアの実行履歴で，ある機能を実行した場合としなかった場合とで実行された関数の差分を手がかりにどの機能をどの関数が実装しているか調べるSoftware Reconnaissance というツールではいちいち実行履歴の取得→解析という手間があるので，プログラム実行時の様子を直接可視化するTraceGraphというツールを作った，という話．

TraceGraphは，横軸にメッセージ（現在実行中の手続き），縦軸に時間をとって，現在実行中の部分に四角いマークを描画する．ある種シーケンス図に近いが，これをプログラムを実行しながら見ていくことでプログラムの理解を進める．

論文自体はこのツールを用いたケーススタディ．保守作業をする人間が作業開始のための手がかりをすばやく見つけられることがツールの利点らしい．

_ [論文] アスペクト干渉の検出 ▲

Remi Douence, Pascal Fradet, Mario Sudholt:Deetction and resolution of aspect interactions.Technical Report, INRIA, No.4435, 2002.

AOSD2004 で出ていた論文の前の話みたい．アスペクトの干渉についての研究で，あるアスペクトと別のアスペクトが同一の Join Point には決してマッチしないときアスペクトは強独立で，また対象のプログラムにおいて共通のJoin Pointが存在しないとき独立である，といっている．

アスペクトが状態を持つ場合の拡張がAOSDの論文ぽい．

アスペクト同士がデータ依存関係を持ってしまう場合などは考慮していない様子．難しいところだけれど．

_ [論文] モジュール単位とクラス単位のビューの併用環境 ▲

Doug Janzen and Kris De Volder:Programming With Crosscutting Effective Views.Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.195-218,Oslo, Norway, June 14-18, 2004.

異なるクラスに分散した一つの機能を見るためのモジュールビューと，クラス単位でどんなモジュールに関与している機能があるか見ることができるクラスビューとを行き来して，作業ごとに適切な環境で作業するべきだ，という論文．プロトタイプではデータベース上にソースコードを置いて，仮想ソースファイルとしてユーザに提示するらしい．

アスペクトの記述内容が与えている影響などもクラス上に表示されたら便利でもあるし，またクラスに分散した機能をアスペクトかのように見る機能はFEATなどで提案されているがそれなりに便利そう．

ただ，理想的にはそうだと分かっていても，実装が伴わないとみんな納得してくれなさそうではあるが．このような複数のビューを行き来することが開発効率をどのくらい向上するかなど，疑問というか研究としての発展性としては気になるところ．

_ [論文] テストケースの実行履歴に基づく分類 ▲

William Dickinson, David Leon, Andy Podgurski:Finding Failures by Cluster Analysis of Execution Profiles.Proceedings of the 23rd International Conference onSoftware Engineering, pp.339-348, Toronto, Ontario, Canada, May 2001.

多数のテストケースから，バグ発見に効果的なテストケースを抽出するための手法．個々のテストケースの実行プロファイル（この論文ではどの関数からどの関数が何回呼ばれたかのリスト）をもとにクラスタを構築し，各クラスタから代表者を選び出すことでバグ発見に効果的なテストケースを選び出す．

各クラスタリング手法（使っている類似度の基準）とクラスタからの代表者の選択方法（各クラスタから１つなのか，エラーとなるような実行履歴を持つクラスタから多めに選ぶか）を変えて実験をしていて，呼び出し回数を単純に正規化した方法がヒストグラムなどよりも効果があり，エラーとなる実行履歴を持つクラスタから多めにテストケースを選ぶ手法だとだいたい３０％のテストケースを選んだだけで９０％のバグをカバーできたらしい．

テストケースのうち要らないものを減らしたりはできるかもしれないが，テストケース生成時に実行プロファイル結果が予想できないと使いにくかったりする？という気がする．プロファイル取ってる時点で実行してるわけだし．

_ [論文] テストケースの選択方法 ▲

William Dickinson, David Leon, Andy Podgurski:Pursuing Failure:The Distribution of Program Failures in a Profile Space.Proceedings of the 8th European Software EngineeringConference held jointly with 9th ACM SIGSOFT InternationalSymposium on Foundations of Software Engineering 2001,(ESEC/FSE 2001), pp.246-255, Vienna, Austria, September 10-14, 2001.

ICSEの続きの話っぽい論文．エラーが見つかったテストケースと同じクラスタから別のテストケースを選び出すとき，クラスタ全体から適当に選ぶより，プロファイル結果が近いものを選び出したほうが別のバグ発見ができる場合がある，ということが示されている．エラーのある実行と成功した実行は大きく離れていて，エラー同士はある程度かたまる傾向にあるらしい．

_ [hyCalendar] 0.8.3 リリース ▲

微妙に間が空いてしまったが，hyCalendar 0.8.3 リリース．

今回の更新は・日付メモからはみ出す文字列の折り返しをオプションとして追加．・印刷コンポーネントを最新版にした (Windows 98 関連でバグが直っているらしい）

TODO などの項目がはみ出して嫌だーという人や印刷時に項目がはみ出して悔しい人向け．期間予定だけは，自動位置調整の都合上，折り返せなかったりと微妙な条件は付いているが，たいていの人には十分なはず．逆に，たいした機能でもないので，使わない人はバージョンアップする意味はあまりない．

_ [hyCalendar] GetPrivateProfileString の仕様 ▲

hyCalendar が Windows 98 で動かなかった問題の原因が何となく判明．

INIファイル読み込みに使われる関数 GetPrivateProfileString についての MSDN ライブラリの説明に，読み込みに失敗したときに使われる lpDefault パラメータに関して次のようなOS限定の記述があった．

Windows Me/98/95: Although lpDefault is declared as a constant parameter, the system strips any trailing blanks by inserting a null character into the lpDefault string before copying it to the lpReturnedString buffer.

で，TODO文字列のデフォルト値は 'TODO: ' という定数で，文字列はおそらくポインタで渡されているだろうから，定数値を書き換えようとしてアクセス違反が起きていた，という仮説が有力になってきた．

TIniFile.ValueExists などのデフォルト値を伴わない処理を使ったら（読み出しには同じ関数を使うが），アクセス違反は起きなくなった．

ValueExists は毎回，指定したセクションのキーのリストをいちいち読み出すので読み出しのコストが上がってしまう．定数をCopy関数による明示的コピーで一時変数に格納してから読み出すようにするか，デフォルト値から空白を取り除くか．どちらでも問題は回避できることを Windows 98 上で確認した．

さすがに無駄なコピーを作ると将来（人かコンパイラが）消してしまう可能性があるので，あからさまなデフォルト値を設定しておいて，その値が使用されたら，本来の空白を含んだ初期値に変更する方法にする方向で修正してみることにする．

MSDN ライブラリの説明文

_ [AspectJ] AJDT 1.1.11 ▲

AJDT 1.1.11 が公開されたので早速アップデート．以前のバージョンに比べると，わざわざ手動で Rebuild しなくてもアウトラインビューがきちんと表示されるようになったので，使い勝手は大幅アップにしている．

AJDT 1.1.4 ではまったアスペクト内で inter-type 宣言されたフィールドへのset イベントが認識されない問題も解決されていたので，もう一度プログラムを動かすテストをしてみる．

プログラムの動的解析は，最終的には JVMDI（いずれはJVMTI）の実装へ移行するつもりだが．

_ [論文] アスペクトのインスタンス化 ▲

下滝 亜里: アスペクトのインスタンス化とインスタンス単位でのアスペクトの適用．FIT 2004, to appear.http://noselab.ise.osaka-sandai.ac.jp/~asato/pubs/fit2004.pdf

どちらかというとプログラミング言語なネタか？インスタンスごとに貼りつくアスペクトのインスタンスを簡単に利用できるように，AspectJだけを用いて記述する方法と，クラスタグ付けによる記述法の提案．

オブジェクト１個以上に対してアスペクトが１個貼りつく，どのインスタンスにアスペクトを付加するか自分で決める，というのは Mix-in に近い立場に見える．１個のインスタンスに同じアスペクトのインスタンスが動的に複数貼りつくことがありうるので少し違う？

アスペクト指向的にはやはり複数のクラスのインスタンスにアスペクトを貼り付けたくなるが，そうなると芝浦工大の櫻井さんたちのAssociation Aspectに近いように見える．スペースの都合か，関連研究に対する位置づけが説明されてないので不明．

個人的な思いつきとしては，インスタンスレベルのアスペクトは対象を「この」インスタンス，と手動で特定しているといわゆるベースコードとアスペクトが混ざってしまうので，特定の関係にあるオブジェクト間にアスペクトが貼りつく，みたいな書き方ができるようになればうれしいのかもしれない．これは Association Aspect を適切なタイミングで付けたり外したりするアスペクトを書けば実現可能？

余談だが，インスタンスごとにアスペクトを動的に貼り付けるようになると，干渉のしかたも動的に決まるから，干渉の検出に使うプログラム解析などは難しくなりそう．アスペクトの貼りつき順序の禁止ルールとかを作るのは難しいし一杉さんの「安全な結合ルール」みたいな手法をきちんと考えないと複雑さがすぐに爆発しそうな予感．スライシングは解析コスト高いし，もうちょっと Lightweight な手法に進まないと苦しいか．

_ [hyCalendar] iniファイル読み込み ▲

hyCalendar が Windows 98 上で動かなかったのは，INIファイルから文字列を読み込むために使うGetProfileString （DLL上ではGetProfileStringA）が存在しない項目の一部にアクセスしようとしたときにページ違反を起こすためらしいということが判明．

hyCalendar 0.7.0 で追加された項目の中にどうやら引っかかるものがあるらしい．

とりあえず回避方法は，すべての設定が作られたini ファイルをあらかじめ用意しておくこと．なので，いちおうの対処はできた格好になった．

これで，少し余裕をもって対処できる．

_ ECOOP2004 ▲

ECOOP2004の開催をなぜか７月だと思い込んでいて，そろそろプログラムをチェックするかーと思って見に行ったら実は6月開催だったことが発覚．

本会議はシングルトラックで小さめで，ワークショップがたくさんくっついている．

Proceedings がなかったので（LNCSかな？）著者名で探してPDFだけ拾い集めておく．ワークショップのほうは，ほとんど全部原稿が PDF で読めるみたい．読みたいものをピックアップしておくことにする．

_ [AspectJ] inter-type宣言へのfield set ▲

今日のはまり．

AspectJ 1.1 (AJDT 1.1.4) で，そのアスペクト内で inter-type 宣言されたフィールドへのaround アドバイス内での set イベントが認識されていなかった．

これがどのくらい再現する問題なのかは不明だが，これのおかげで取れるはずだったイベント情報が取れてなかった．

今回は一種のプロファイルが目的だったので，素直に JVMDI へ移行したほうがいいかもしれない．