netail.net

_ [論文] 相互依存したプログラム要素の発見方法 ▲

Binkley, D. and Harman, M.: Lcoating Dependence Clusters and Dependence Pollution.

Proceedings of the 21th International Conference on Software Maintenance (ICSM 2005), pp.177-186, Budapest, Hungary, September 2005.

プログラムの中に，相互依存するような要素群があると，保守が難しくなる．

依存関係はプログラムスライスによって調べることができるが，相互依存関係を持った要素の数が多いかどうか（問題かどうか）を判断するのは難しい．

そこで，相互依存した頂点から計算したスライスはまったく等しくなり，従ってスライスのサイズも等しくなるという性質を使う．

各頂点から計算したプログラムスライスを，横軸にサイズ順に並べて，縦軸にサイズをとると，突然サイズが大きくなり，しかもサイズが等しいようなスライスの固まりが可視化できる．そのような形が現れたら，そこはまったく同じスライス（相互依存関係を持った頂点群）が並んでいるのではないか，と開発者は判断できる．必ずしもサイズが同じ＝スライスが等しいとは限らないが，ほぼ一致することを実験的に確認している．

このような相互依存したコードの固まりを Dependence Pollution と呼び，それをリファクタリングすることで，スライスサイズを減らせる（影響の量を減らし，回帰テストなどのコストを下げられる）と主張しており，ケーススタディとして様々なプログラムに対して適用し，実際に問題のありそうな部分を調べてリファクタリングすることでスライスサイズの平均値を大きく減らせる例などを示している．

グラフの中で，ループした要素を見つけたいというときに，そこからたどり着けるノードの数でソートすれば楽，という発想は，何か他でも使えるかもしれない．

_ [VolumeDeskbar] 1.0.4 の設定ダイアログ ▲

コマンドボタンが Windows XP スタイルじゃなくなったのか，と報告をいただいたので，少し調べてみたら，ＰＣによって微妙に「設定」グループボックスが表示されなかったり，XP スタイルじゃなくなったりするらしい．開発環境のPCでは分からなかったのだけど．

愉快な問題なので，もしかしたら設定ダイアログのウィンドウリソースが破損しているのかな，と思ってクリーンビルド（Delphiの「再構築」）したらいちおう直った．

テスト用プロジェクト（ボリューム調節のバーをタスクバー上ではなく，普通のウィンドウ上に出す）側の中間コンパイル結果ファイルが悪さをしていた可能性が考えられる．

_ [論文] クラスの使い方の実行時情報からの抽出 ▲

Salah, M., Denton, T., Mancoridis, S., Shokoufandeh, A. and Vokolos, F. I.: Scenariographer: A Tool for Reverse Engineering Class Usage Scenarios from Method Invocation Sequences.

Proceedings of the 21st International Conference on Software Maintenance (ICSM 2005), pp.155-164, Budapest, Hungary, September 2005.

プログラムの実行履歴（各オブジェクトへのメソッド呼び出しの履歴９から，そのクラスの使い方を探してこようというもの．インタフェース記述でメソッドの呼び出し順序の解説なんかを書こうという動きもあるし，この手の研究が最近流行っている気がする．

「メソッド呼び出し列」の集合から，その中のメソッド列群を代表するような "canonical set" を選び出し，他のメソッド列は canonical set の各要素のどれに属するかを分類する（canonical set の１要素に代表されるメソッド列の集合を canonical group と呼ぶ）．で，１つのcanonical group に属するメソッド列たちに対して，それらを簡潔に表現するような正規表現を見つけてくる．ユーザには，あるクラスに対する典型的なメソッド呼び出し列を表現した正規表現の集合が出力として与えられることになる．

canonical set を計算するところは，各メソッド列を頂点として，他のメソッド列との類似度を重みとした完全グラフを作ったとき，その中から頂点集合 V を，「V に含まれる頂点同士の辺の重みの総和ができるだけ小さく，V と V の外部にある頂点をつなぐ辺の重みの総和ができるだけ大きくなるように」選び出すという最適化問題になる．これに対して，類似度には edit-distance を使って，既存の近似アルゴリズムを適用している．

canonical set が決まると，他のメソッド呼び出し列は，一番類似度の高い（同じ類似度が複数あればそれらすべての）canonical group に分類され，あとはそこに正規表現での近似処理が適用される．

適用実験では，正規表現クラスとソケットクラスに対して適用しており，正規表現のほうは，match してから isMatch を何回か呼び出す，というそれっぽい出力が得られている．ソケットのほうはある部分列（getLocalAddress/getLocalPort/getPort/getInetAddress）が繰り返し登場するパターンが出力されていたが，実はソケットへの入出力を行うストリームクラスが，これらのパターンを作り出していたらしい．このような特定クラスからの関与が，自動的に判別されてから情報が出力されるなら，そこそこ便利な手法かもしれない．

_ [AspectJ] 単体テストでは動的アスペクトのほうが楽？ ▲

アスペクトをテストしようとすると，AspectJの場合，テスト用クラスと一緒にアスペクトをコンパイルして実行，という作業が発生して，構成ファイルをいちいち用意したり，けっこう手間だったりする．普通にEclipse＋AJDT でコンパイルしてると，標準ではすべてのアスペクトが同時にコンパイルされるので，単体テストにならない．

Dynamic Deployment を持った処理系（CaesarJとか）だと，JUnit でいうところの setup メソッドでアスペクトをテスト用オブジェクトに deploy して実行するというコードが書けるので，テスト容易性という観点では有利だといえそう．コンパイルあたりを ant で自動化した場合でも，実行コストの差だけでなく，テストケース側に「どのアスペクトがdeployされた場合のテストか」が明示されている点は有利だと考えられる．

動的なほうが，どのアスペクトがバインドされているかコンパイル時には分からないので問題が起きたときの調査は難しそうという印象があるのだが，コンポーネントの接続などに限定したアスペクトなら，動的に適用したほうが問題が簡単になったりするのかもしれない．

ということで，CaesarJとかに少し心惹かれているこの頃．

_ 黒豆コーヒー ▲

というものをお土産にもらったので飲んでみた．コーヒー＋黒豆なので，きな粉を入れたのに近いと言えそう．黒豆とおぼしき香りのぶん，コーヒーっぽさはあまりない．

ちょっと甘みがあるので，ココアみたいに牛乳に溶かすと美味しく飲めるみたい．

_ [ツール] Volume Deskbar 1.0.4 リリース ▲

全体音量とWAVE音量との同時制御を可能にしてみた．

全体音量とWAVE音量の積で効果が表れると，音量バーの変更量に対して実際の音量変化が線形ではなくなるという問題があるかと思っていたのだけれど，実際やってみると，そう気になるほど極端な変化は起きないようなので，そのままリリースすることにした．

_ 本棚の整理 ▲

一部RPG研に寄付することにして，本棚から除去．E.A.ポオの小説全集と詩集（文庫版）は，MLで聞いてみたらすぐに引き取り手が名乗り出てくれたので，古本屋に持っていく手間が省けてありがたいところ．

_ [hyCalendar] 1.3.3 リリース ▲

再起動時にオプションを破棄していたバグが一番の修正点で，あとはハイパーリンクが全角文字対応になったり，日付メモのインポートができるようになったり．

Kt関数アドインが昭和の日に対応してくれていたので，配布アーカイブ内の休日情報（holidays.txt）も新しいものに更新した．

_ お土産を買う ▲

香月堂のお店でおみやげを１つ買うついでに，ばら売りのもみじ饅頭を１個だけ買ったら，売店の人がおまけしてくれた．ちょっと嬉しい．

_ [hyCalendar] 地道に単体テストを書く ▲

インポート機能を実装するついでに，DUnit を導入してみたら，なんとhyCalendar の分割コンパイルに失敗（モジュール間の依存関係が多すぎて，分割コンパイルできる境界を見つけられなかった）．いずれ整理しないと，と思いながら放置してた部分がけっこうたくさんあること判明．

とりあえず DUnit の使い方メモ．やることは次の通り．

• DUnit が提供しているコードへの参照を追加する
• テストケースを実行するインタフェースを起動するコード
• テストケース自体
• 実行対象のテストケースを登録するコード

DUnit のコードを参照するには，プロジェクトの検索パスに，DUnit-x.x.x/src ディレクトリを加えておく．

テスト起動コードは，通常は，プロジェクトソースに記述する．以下は独立したプロジェクトとしているパターン．コンパイルスイッチなどで，通常のプロジェクトと切り替えるのもありかもしれない．

program HogeTest; // プログラム名をここに書く
uses
  TestFrameWork,
  GUITestRunner, 
  // ここにテスト対象のユニットも並べる
begin
 Application.Initialize;
 GUITestRunner.RunRegisteredTests; // テストインタフェース表示
end;

テストケース自体は，TTestCase クラスを継承したクラスを定義する．必要なのは，"Test" という名前ではじめることと，アクセス権を "published" にしておくこと．published で宣言すると，実行時にメソッド名をプログラムから参照することができるようになるので，テスト登録に使われる．

uses
    TestFrameWork; // TTestCase などを参照するのに必要
type
    THogeTest = class(TTestCase)
    protected
        procedure TearDown; override;
    published
        procedure TestFirst;
        procedure TestSecond;
    end;

テスト条件のチェックは，Check という関数を使って記述する．trueになる条件と，エラー時に表示される文字列を記述する．

Check(not data.hasError, 'エラーは起きないはず');

で，作ったテストケースは，そのユニットの initialization 節で，RegisterTest という処理を呼び出すことで登録を行なう．テスト用クラスで登録するが，このとき，クラスの Suite メンバを使う． ユニットの初期化タイミングで動作する initialization 節をまじめに使っている例だといえる．

initialization
 TestFramework.RegisterTest(THogeTest.Suite);

_ [論文] パフォーマンス向上のための自動コード変換 ▲

Liu, Y. A., Stoller, S. D, Gorbovitski, M., Rothamel, T. and Liu, Y. E.: Incrementalization Across Object Abstraction.

Proceedings of OOPSLA 2005, pp.473-486.

モジュール性の高い素直な実装だけでは性能が足りないときは，コストの高い問い合わせメソッド系の戻り値をあらかじめ保持することになる．

このとき，状態の更新メソッドが呼ばれたら，その保持している内容を更新する必要があり，その実装はかなり複雑になりがち．

そこで，プログラム変換を使って， invariant を保存しつつ，状態更新処理のコードを作ろうというもの．

アイディア的には AOP の立ち位置と同じようだが，コードを変換するルールを記述していく作業が，今のところは，メタプログラミングの要素が強い．

_ [論文] コードからのオブジェクトの状態機械の抽出 ▲

Nanda, M. G, Grothoff, C. and Chandra, S.: Deriving Object Typestates in the Presence of Inter-Object References.

Proceedings of OOPSLA 2005, pp.77-96.

各メソッドのコードを解析して，オブジェクトの取りうる状態をどう変化させるかを調べておき，とりうるヒープの状態（オブジェクト間の参照含む）をメソッド呼び出しで遷移する状態遷移図を構成する．これによって，同じメソッド呼び出し列でも，値などによって状態が変わる場合を区別して確認できる．

_ [論文] 実行履歴に対するクエリ ▲

Goldsmith, S., O'Callahan, R. and Aiken, A.: Relational Queries Over Program Traces.

実行トレースに対するクエリを PTQL という SQL に近い言語で書くと，それに必要な監視コードをプログラムに埋め込む．

イベントの開始・終了時刻，宣言しているクラスや実装クラス，パラメータの値などの値をクエリの条件式として使える．

tracematch での実行履歴のマッチとはやり方が違うが，実現時の最適化技術などはたぶん同様だと思われる．

使いやすさについては，どのくらい，と明確に言えないが，有用そうな例いくつかに対して，パフォーマンスのオーバーヘッドでの評価を行なっている．

_ [お出かけ] 神戸市立博物館のナポレオンとヴェルサイユ展 ▲

見に行ってきた．絵画と，家具がメインな展示．人物の肖像画がかなり多かった気がする．

肖像画か何かのところに付いてた説明を読んでたら，当時はヘアスタイルとして，もみあげを伸ばしてたらしいので，アルセーヌ・ルパンのもみあげと関連してるのか，とか，どうでもいいことを思ったり（年代は離れているが）．

_ [論文] 実行履歴に対してマッチするアドバイスの定義方法 ▲

Allan, C., Avgustinov, P., Christensen, A. S., Hendren, L., Kuzins, S., Lhotak, O., de Moor, O., Sereni, D., Sittampalam, G. and Tibble, J.: Adding Trace Matching with Free Variables to AspectJ.

Proceedings of OOPSLA 2005, pp.345-364, San Diego, California, USA, October 2005.

イベント列にマッチするアドバイスを定義するために，before/after ＋ pointcut でイベントシンボルを定義し，イベントシンボルの正規表現によってアドバイス実行の条件を記述することを提案している．

before/after + pointcut を使うのは，通常の join point だと，呼び出しが始まってから終わるまで，のような有効範囲を持ってしまうためそれを before/after によって「点」に変更している．

「オブジェクト x に対して特定のメソッド呼び出しが起きたとき」といったオブジェクトのバインディングを，AspectJ のように各アドバイスで保存・参照するのではなく，シンボル列のマッチ時に解決することで，プログラムの簡潔な記述を実現している．

pointcut マッチによって生成されるシンボル列に対して，非決定性オートマトンを使った正規表現マッチでアドバイスの実行を決定する．このとき，シンボルとして，関係あるイベントだけが取り出されており，どのポイントカットにもマッチしないイベントはフィルタされる．

たとえば「ログイン後にクエリーを投げたとき」というアドバイスは，login/logout/query というイベントだけ定義しておけば，「login query+」というパターンで記述できる．logout が間に一度でも出現していたら上にはマッチしないし，それ以外のメソッド呼び出しはそもそもシンボルとしては登場しない．

手法に対する形式的記述や，関連研究の説明もうまくまとめられており，かなり参考になりそうな文献．