netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2004-01-02 古い日記からの変換データ [長年日記] ▲
2004-01-03 古い日記からの変換データ [長年日記] ▲
2004-01-05 古い日記からの変換データ [長年日記] ▲
2004-01-06 古い日記からの変換データ [長年日記] ▲
2004-01-07 古い日記からの変換データ [長年日記] ▲
2004-01-09 古い日記からの変換データ [長年日記] ▲
2004-01-12 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Suhaimi Ibrahim, Norbik Bashah Idris, Aziz Deraman:Case study: Reconnaissance techniques to support feature location using RECON2.Proceedings of APSEC 2003.
プログラムのあるフィーチャーを含むような,プログラム実行テストケースを "Y" テストケース,含まないようなテストケースを "N" テストケースとして,それらの実行経過の差分を取り出すことでフィーチャーがどこに実装されているかを調べようというものらしい.
ユーザは,テストケースを作り,それを Y/N に分類しておく必要がある.
ケーススタディの結果,そんなにテストケースの個数はいらないが注意深く選んである必要はあるらしい.この手法は,どんな機能があるか,ある程度知っている状態でならプログラムのどこに,その機能が実装しているかを示すのはやりやすい.
弱点は,テストケースが実行できなければならないので,テストケースとして表現しにくい機能ほど見つけにくい.
ちなみに,「部分的な理解だけでもそれなりに保守はできる」ということは既に以下の論文でいわれているらしい.Lakotia, A., "Understanding someone else's code: Analysis of experience", Journal of System and Software,1993, Vol.23, pp.269-275.
_ 論文 ▲
Hiralal Agrawal, Richard A. DeMillo and Eugene H. Spafford:Debugging with Dynamic Slicing and Backtracking.Software Practice and Experience, Vol. 23(6), pp.589-616, June 1993. 動的スライスを使えるような環境を GDB ベースで作って,それに加えてバックトラック(「一ステップ前に戻る」)を実装したような環境を作ってみた,という論文. ある地点でブレークして,値がおかしいから動的スライスで前のほうへ戻って原因を調べていく,というもの.いちおうデータのみ,制御のみ,それぞれに注目したスライスも取れるようにしたりとか工夫されていて,成功したテストケースと失敗したテストケースでのスライスの違いなどが役立つだろう,と言っている. プログラムスライスや実行バックトラッキングの限界として,次のようなものを挙げている.- 複数回同じ行が実行されたことを,スライスは明示してくれない. (せっかく動的スライスでも,見た目はソースコードだから)
- スライスは「何が影響しているか」は教えてくれるが,そこから「どの制御あるいはデータが間違ったか」という原因に立ち戻るにはやはりかなりの苦労が必要である.
- 実行のバックトラックは,システムに対する副作用があるとそこで戻れなくなってしまうので「部分的」バックトラッキングで我慢するか,再実行する仕組みのほうが良いかもしれない.
_ 論文 ▲
Andreas Zeller: Yesterday, my program worked.Today, it does not. Why?, Proceedings of 7th ESEC/FSE 1999
ベースライン(既存プログラム)に対する変更の集合 C を考える.test(x) は テスト結果 PASS, Failure, Unresolved を返す.
ある日,プログラムが動かなくなる: (test(φ) = PASS) ∧ test(C) = FAIL )
変更集合 C を適当に組み替えて(バージョン管理ツールなどを使って),どの変更でプログラムが動かなくなったかを調べる.
このとき,変更は [単調] である.∀c ⊆ C (test (c) = FAIL --> ∀ c' ⊇ c ( test(C') != PASS ) )
この変形で,うまくいっている変更の部分集合だけを取り出しても,テストは失敗しない.∀c ⊆ C (test (c) = PASS --> ∀ c' ⊆ c ( test(C') != FAIL ) )(一時的に実行不能になっている場合もあるかもしれないが)
で,失敗してる構成同士を組み合わせても意味がなくて,∀c1, c2 ⊆ C ( test(c1) = FAIL ∧ test(c2) = FAIL --> test(c1∩c2) != PASS )
どんなテスト組み合わせでも未解決のテストが出ない状態を,[一貫した] 状態であるという.∀c ⊆ C ( test(c) != Unresolved )
…ということを利用すると,変更単位が自動で扱えるなら,自動で,どの変更がバグの原因かを示せる.
変更 8個あれば 4個ずつでテストを実行し,失敗したものについてはさらに2分してどちらが失敗しているか(あるいは両方失敗しているか),さらに失敗したものについて2分して……としていくことで,失敗するテストを判定する.成功したもの同士は今度はくっつけてテストを実行して,組み合わせることによって成功するものはどれか,というのを調べる.たとえば,1-4, 5-8 がそれぞれ成功したとして,3-8 がテスト失敗したなら 3 + 5-8 と 4+ 5-8 でテストして,……というように組み合わせを自動で探索する.
テストを効率よくグループ化するために,プログラムの変更に対してプログラムスライスをとって共有ノードがあるかどうか,といったことでその変更が相互に影響するかどうかを調べたらいいなぁ,なんてことを将来の課題として説明している.
2004-01-13 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Katharina Mehner:JaVis: A UML-Based Visualization and Debugging Environment for Concurrent Java Programs.Software Visualization, LNCS 2269, pp.163-175, 2002.
実行トレースから UML のシーケンス図を生成して,その上にデッドロック情報を乗せる.デッドロック検出アルゴリズムは既存だし,シーケンス図を作ること自体は今のところ力技のようなので,新規というわけではないが,あると便利そう,というところ.
シーケンス図を作る,というところで,Visualizing the Execution of Java Programs の筆者らが「スケーラビリティがないので実際には使いにくい」という主張をするのは仕方がないところかも.
_ 論文 ▲
Wim De Pauw, Erik Jensen, Nick Mitchell, Gary Sevitsky,John Vlissides, and Jeaha Yang:Visualizing the Execution of Java Programs.Software Visualization, LNCS 2269, pp.151-162, 2002.
Java のプログラム実行時情報を可視化するJinsight というツールを紹介した論文.
オブジェクトのインスタンス数・呼び出し数・消費メモリ量・実行時間を見る Histogram View,呼び出し・参照関係をツリー状に表現して,枝にその参照が何回ずつ起こっているかを表す Reference Pattern View,オブジェクトを「世代」にグループ化することで行うメモリリーク分析(「捨てられるべき」オブジェクトグループへの参照を誰かがこっそり保持していないか調べる),プロファイラ結果を図示する Execution View,呼び出し回数の比率を示す Call Tree View がある.
Execution View は,全部のメソッド呼び出し関係を図示するようで,かなり見づらいが,150万行程度の実行履歴でもちゃんと表示できているあたりは,かなりがんばっている.
主にメモリおよび実行性能上の問題に対処することが目的らしいので,このあたりで十分なのだろう.なんとなくだが,Eclipse の Java プロファイラツールで使われているビューに似ている気がする.IBM の人たちだし.
関連研究としては,・情報をいかに減らすか(適当な単位で分割するなど)・いかに探すか(クエリーベースの探索ツールなど)があげられる.UML で並列性の問題を可視化するツールなどもあるようだがスケーラビリティの問題が大きい,とも述べている.また,一般的な情報表示よりは,特定のタスクに絞って便利な情報を提供するツールのほうが良い,とも述べている.
2004-01-14 古い日記からの変換データ [長年日記] ▲
2004-01-15 古い日記からの変換データ [長年日記] ▲
_ Cygterm ▲
Cygterm を Guevara からつついてみた. http://www.dd.iij4u.or.jp/~nsym/cygwin/cygterm/cygterm.cc を適当に置き換えてみた.怒られそうな変更してるけど.ポートはデフォルトの値1個だけを使うようにしてる. cygterm.cc cygterm.cfg Guevara 側の設定例.(cygterm.cfg で設定したポート番号をつつくようにする) cygterm.cfg2004-01-16 古い日記からの変換データ [長年日記] ▲
_ ファミコン ▲
レーサーミニ四駆ジャパンカップ攻略用セッティングのページにこっそり(でもないが)アクセスカウンタとアクセス解析を設置.
……昨日から9人来てるみたい(自分で実験用に踏んだの除く).そんなに需要あるのだろうか :-)
_ Calendar ▲
hyCalendar 0.6.4 アーカイブ版作って公開.ini ファイルを zip から取り除いて,それに伴って README, CHM ファイルも更新.間違って設定ファイルを上書きしてしまうーと文句言われたので,それに対応.
2004-01-20 古い日記からの変換データ [長年日記] ▲
2004-01-21 古い日記からの変換データ [長年日記] ▲
2004-01-25 古い日記からの変換データ [長年日記] ▲
2004-01-27 古い日記からの変換データ [長年日記] ▲
_ 読書 ▲
E.T.ベル「数学をつくった人びと III」(ハヤカワ文庫)読了.さすがに時代的に1900年前後になってくると数学も高度化してる気はする.
3巻で登場している人物のうち,ソフトウェア工学やる人としてお世話になるのはブールくらいか.やっぱり数学系か,もうちょっと工学・物理学系の人なら楽しめるんだろうなーという気がする.
_ 読書 ▲
ドナルド・J・ソボル「二分間ミステリ」読了.
暇つぶしにいい本だ.わずかな時間で,論理のミスに気づけるかどうか,というところ.そこそこ解けるが,「やられた」と思うときもある,というバランスがあるので面白い.逆に,まったく解けない人はだめなんだろうけど.
2004-01-29 古い日記からの変換データ [長年日記] ▲
_ Calendar ▲
0.6.6 を目指しての作業が一段落.たいしたこともないバグなのに根は深かった.Windows のスタンバイ/ロック解除を頻繁に使う人間なので直したが,実際には毎回プログラムを終了させるタイプの人には必要のない修正だったりして.
でも,まだリリースまでは時間がかかりそう.いちおうバイナリだけは今月中(あと2日ほどしかないが)に出すつもりだが.
_ Delphi ▲
いろいろ試行錯誤した挙句,次のようにまとまった.・アプリケーションの MainForm としてfrmPlaceHolderを作成.・frmPlaceHolder は,幅0,高さ0. 最小化命令が飛んできたときだけ, 本来のフォームと同じサイズに化けて, アプリ全体を最小化する.・本来のカレンダーフォームは, アプリが最小化されている間は消えている. (表示していると,ビジュアルスタイル変更時に クラッシュするため -- これは VCL のバグだろうか?)・カレンダー画面表示中にビジュアルスタイル変更が来た場合, 一度画面を消してから再表示する. (メッセージは1回ではない場合もあり, その場合は点滅することになる)・最小化中は(ウィンドウが非表示なので)黙って耐える.