«前の日(12-30) 最新 次の日(01-01)» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2003-12-31 古い日記からの変換データ

_ Collector

Collector v2.2 -> v3.1 アップデートしてみた.あまり変わらないのだけど.

http://www.geocities.co.jp/SiliconValley-Cupertino/6494/collector.html

_ K2Editor

K2Editor を使っていた 1.1 から 1.4 にアップグレード.バージョンアップを1年以上忘れていた.文字コードの対応や正規表現まわりが強化されてきたので,Sakura Editor との使い分けがあまり意味がなくなってきたかも.

_ Calendar

ひそかに hyCalendar 0.6.0 をリリースしてみる.Vector などに送るのは翌年になってからの予定.(さすがに年末年始は仕事してないだろうし)


2004-12-31 古い日記からの変換データ

_ [論文]動的アスペクトマイニングへの静的情報の付与

Silvia Breu:Towards Hybrid Aspect Mining: Static Extension to Dynamic Aspect Mining.1st Workshop on Aspect Reverse Engineering.

実行履歴から呼び出しパターンを解析するアスペクトマイニングでは,メソッド呼び出しが全部具象クラスになってしまって,クラスAとBが継承関係にあるときにA のメソッド実行と B のメソッド実行の関連情報が落ちてしまう.

そこで,呼び出し文で使っている型,あるいは親クラスへクラス情報だけを書き換えた状態でマイニングしたらどうか,と考えているらしい.パターン認識のコストはちょっと上がるだけで済みそうだが,効果は不明.

_ [論文]コードクローンでのアスペクトマイニング

Magiel Bruntink:Aspect Mining using Code Clone Metrics.Workshop on Aspect Reverse Engineering.

エラー処理,動的実行トレース,関数のパラメータチェック,メモリ確保の4つが主な横断的関心事であるとして,コードクローンを取得して,クローンクラス全体のコード量と分散している関数の個数の積でランキングをとって,上位20件を調べるという実験をしている.

結果としては,上位に入ったクローンクラスで上記の4つを含んでいるものは見つけられたらしい.ただ,1個のクローンクラスで特定の Concern に関するコードを全部カバーできるというわけではなく,複数のクローンクラスのを合わせてみないと分からない.

また,エラー処理(エラーコード変数の初期化〜設定など)は他のメイン処理にあたる初期化処理なども含んでしまって,そう簡単にアスペクトとして抽出できるというわけではなかったらしい.

今のところ,それらしいコードを見つけることはできても,分離して役立つコード,分離できるコード,という基準が明確でないところが微妙.

_ [Delphi]RichEdit の Protected 属性

TRichEdit には一部領域の編集を防ぐ Protected 属性が付加できるのだが,一度 Protected をセットすると解除してよいかどうかを OnProtectChange イベントで許可を出す必要がある.

クリップボードへのコピーなど変更を伴わない作業も保護されてしまうので,いくつかの特定の処理中(e.g. cflowbelow(LoadFromFile), cflowbelow(CopyToClipboard)) だけは許可を出す,というのでモジュールレベルのフラグ管理だらけになりつつある.

cflowbelow などよりももうちょっと抽象的な「今何をしているか」をシステム自身が認識できれば少しはまっとうに解決する?


2005-12-31

_ [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 での実行履歴のマッチとはやり方が違うが,実現時の最適化技術などはたぶん同様だと思われる.

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