netail.net

_ [Java] XML操作 ▲

XMLファイルを手軽に読み書きする方法を探してたら，XML Data Binding Resourcesというページを発見．ざっと見た限りでは，XMLの好きな要素とJavaクラスのメソッドを任意に対応付けられるCastorがかなりよさそう．XMLの構造がまだ固まってない間でも，マッピングだけ変えたらクラス側が影響を受けないのが嬉しい．

_ [論文] 動的影響波及解析 ▲

Taweesup Apiwattanapong, Alessandro Orso, and Mary Jean Harrold: Efficient and Precise Dynamic Impact Analysis Using Execute-After Sequences.

Proceedings of International Conference of Software Engineering 2005, pp.432-441, May 2005.

輪講で紹介した論文．あるメソッドAが実行された後に実行された（returnで戻った先含む）メソッドすべてはAに影響を受ける，という基準での動的な影響波及解析の方法．各メソッドが最初に実行された時間と最後に実行された時間だけを覚えておくことで，低コストで解析を実現している．

シーケンス図上で影響を受けた部分を図示するといったデバッグ用途では使えそう．

しかし，影響波及と言われて想像する回帰テストの範囲の特定などには使えなさそう．テストしないと計測できないし，テストケースが揃わなかったら取りこぼしが起きる．影響波及解析という名前でなければあまり気にしないのかもしれないが．

_ [論文] クラスとアスペクトを１つにしたclasspects ▲

Hridesh Rajan, Kevin J. Sullivan: Classpects: Unifying Aspect- and Object-Oriented Language Design.

Proceedings of International Conference on Software Engineering 2005, pp.59-68.

クラスとアスペクトという別々のモジュール単位ではなく１個のモジュール単位に統一しようという意欲的だけれど怪しい論文．

ポイントカットに関連付けられるアドバイスをメソッドに限定しているので，クラスが通常のメソッドと，特定のJoin Pointsに反応するイベントハンドラを両方持った形になる．アドバイスの本体はメソッドとして実装されるので，オーバーライドなどは簡単に実現できる． アスペクト自体がインスタンスとして明確に管理されることになるので，アスペクトに貼りつく階層的なアスペクトは定義しやすそう．Java でのイベントリスナのような相互接続の仕組みが不要になるという利点もある．

そのかわり，クラスとアスペクトの区別がないので，new Logging(obj)といったコンストラクタ呼び出し（＝アドバイスの接続）がobjの機能を変更するかもしれない，ということになるので，開発者の負担は上がりそうな気が．

_ [論文][ツール] 静的解析でテストケースを生成 ▲

Christoph Csallner, Yannis Smaragdakis: Check 'n' Crash: Combining Static Checking and Testing. Proceedings of International Conference on Software Engineering 2005, pp.422-431, May 2005. 配列の範囲外の値を参照するとか，null参照を使ってしまうとかいった問題が起きる可能性を静的に検出して，そのクラッシュするような条件（CounterExample）をJUitのソースとして生成して，実際に走らせてクラッシュするかどうかをチェックする（クラッシュしなければ false positive）とかいう話らしい．

手続き単位だけで解析し，他のメソッドの返り値の範囲などは気にしないようなので，手軽に使えるツールなのかも……と思ったが，必要だった時間がけっこう長い（5KLOCで1.5分，18KLOCで26分）ので不安．CnCという名前でツール自体は公開されているらしいので，暇があったらつついてみるのもいいかも．

_ [AspectJ] Java の "-ea" オプション ▲

Eclipse3.1M6 + AJDT で assert 文を書いていて気づいたのだが，アスペクト内部に書いた assert は "-ea" オプションがなくても検査される．アスペクトの結合対象になっている Java　クラス内に書かれた assert 文は，"-ea" を付けない限り検査されない．コンパイラのバグっぽい症状．AspectJのサイトで調べないといけないか．

_ [論文]差分デバッグでのエラー波及の分析 ▲

Holger Cleve, Andreas Zeller: Locating Causes of Program Failures.

Proceedings of International Conference on Software Engineering 2005, pp.342-351, May 2005.

バグのあるプログラムでは，その実行中に，ある時点で変数の値がおかしくなって，その値が他の変数の値に波及していって，最終的に出力文などで開発者から見えるものとなる．

間違った変数の値が他の変数に波及するタイミング（正しいテストケースとそうでないテストケースで，値が異なる変数の集合が変わったとき）を Cause Transition と呼んで，それを発見することがバグの原因を見つけることに役立つ（開発者が調べるべきプログラムの範囲が減少する）ことを，他の手法と比較実験して確認した論文．

Cause Transition の概念自体は悪くないような気がする．スライシングが「出力に影響を与えた文の集合」を求めるのに対して，入力された値の違いと，出力された値の違いの間に，どれだけ Cause Transition があったかを求める（実行履歴の中に区切りを入れると言ってよい？）．

成功するテストケースと失敗するテストケースが与えられる必要があるので，まったく動かないプログラムのデバッグには使えなかったりするけれど．

_ [AspectJ] Eclipse での拡張子.aj ファイルのパッケージ間移動 ▲

パッケージのリネームやファイルのパッケージ間の移動は，Java Development Tools プラグインで実装されているものをそのまま使っているようで，拡張子 ".aj" のファイルを移動させようとすると怒られる．

また，パッケージをリネームしたときは，".aj" ファイルの中の package 宣言は自動では書き換えてくれず，そのままの状態で新しいパッケージに移動する．

"Update fully qualified name in non-Java files" にチェックを付けるのを試してみたら，パッケージの名前変更で得られた新しいファイル（変更後のパッケージの中に含まれるファイル）の中身は変更されておらず，変更前のパッケージに，パッケージ名が変更された ".aj" ファイルが生成されるという状態になる．微妙．

_ [OUCC][ゲーム] ファミコン ▲

１回生の人に「チャレンジャー」の１周クリアを見せてもらった．部室に置かれてから数年間クリアできる人がまったくいなかっただけに，ちょっと感動．

_ [work] ショートペーパー ▲

原稿ちょっとだけ添削．個人的にはショートペーパーが一番書きにくい（手間がかかる）と思う．著者と所属とアブストラクトでけっこう取られて狭いし．

_ [work]輪講の準備 ▲

Taweesup Apiwattanapong, Alessandro Orso, and Mary Jean Harrold: Efficient and Precise Dynamic Impact Analysis Using Execute-After Sequences. を紹介することにして準備開始．

_ 手提げ袋 ▲

重量超過してしまったせいか，ICSM/METRICS2004 ロゴ入り袋に裂け目がはいってしまった．もう１枚あるからいいけど．

_ 一力 ▲

一力で夕食＋酒．年賀状で１年に何十回か行くと言っていた先生が来ないと嘆いて(?)いた．

_ Pukiwikiの添付ファイル ▲

Pukiwikiの添付ファイル名，標準では "ページ名" + "_" + "ファイル名" (ただしページ名とファイル名は，EUCのコード値を16進数で並べたもの: "実験" ページの "txt" ファイルなら "BCC2B8B3_747874")だったのだが，ファイル名を "BCC2B8B374_747874" のように変えてみたら，別のページに移動してくれた．後からページ構造を整理したくなったときには，簡単に対処できそう．あまり安全な操作とは言えないかもしれないが．

_ [論文] APIの更新に対応したリファクタリング操作の自動生成 ▲

Johannes Henkel, Amer Diwan: CatchUp! Capturing and Replaying Refactorings to Support API Evolution.

Proceedings of International Conference on Software Engineering 2005, pp.274-283, May 2005.

輪講で紹介された論文．クラスライブラリで，APIが変更されたときにそれに合わせてクライアント側のコードを変更できるように，インタフェースの変更に関するリファクタリング操作列もファイル保存して，再生できるようにしましょうというもの．けっこうライブラリの更新で困ってる人は多いので，あると便利そう．

ただ，Eclipse上でライブラリ開発者が実施したリファクタリング操作列を自動で記録する，という実装を取っている点が，少し怪しい．

開発者は普通にAPIの変更に関するドキュメントを書かないといけないので，そこで簡単なリファクタリング用スクリプトを手動で書く，とかいうのでもいいような気はする．