netail.net

_ [ツール] Cygwin のシェルでのバッチファイル ▲

昔は，cygwinからバッチファイルを使うとコマンドプロンプトのウィンドウが開いて，実行後すぐに閉じられてしまうという動きをして，バッチファイルが使いにくかった気がするのだが，いつの間にか，バッチファイルの実行経過がちゃんとシェル上に表示されるようになっていた．ちょっと感動．今さら？

_ [work] AspectJの解説記事 ▲

原稿としてはひとまず仕上がったので，連休中に校正作業とかが入る予定．

サンプルとして掲載するソースコードが多いとはいえ，Word 標準のA4の１段組レイアウトで50ページ．今まで書いた原稿の中では最長記録を更新．

それにしても，数百ページに及ぶ教科書や読み物を書ける人々はすごく偉いと思う．

_ [hyCalendar] Towards 1.0.2 ▲

期間予定アイテムの表示順序のソート順序を開始日付＋終了日付に加えて，文字列の順序を使うようにした．これで順序が安定化する．また，ヒントウィンドウを自前のに変更したので，二重ポップアップができるようになっただけでなく，ポップアップした文字列からのクリップボードへのコピーなんかもできるようになった．

まだ他に取り込む機能がないかのチェックが必要だし，ドキュメント書く作業なんかもあるので，リリースはもう少し先．

_ [論文] 単体テストの労力とOOPのメトリクスとの相関 ▲

Magiel Bruntink, Arie van Deursen: Predicting Class Testability using Object-Oriented Metrics.

Proceedings of SCAM 2004.

書いたソースからテスト労力の予想をしたいので（レビューなどのタイミングでコードのテストしやすさを調べたいから），クラスから計測可能なメトリクスと，JUnit のテスト用クラスの大きさに関するメトリクス（テストクラスのサイズ，assertメソッドの数）との順位相関を見て労力を予想しようという統計的な調査．

結果としては，サイズ系のメトリクス（フィールド数，メソッド数）が多いとやはりテストも増えるのだが，相関が強いのはクラスの行数，クラスから利用している他のクラス数（Fan-Out）や，直接・間接的に呼び出しているメソッド数の和（Response For Class）あたりだったらしい．

依存しているクラス数が増えると，テストを実行するために必要な準備のコストも上がるというのかと思ったのだが，クラスのサイズと Response For Classが強い相関を持っていたので，他のメソッドをたくさん呼ぶクラスほどクラスのサイズが大きかっただけのよう．なので，「単体テストをしやすくするために，クラスを小さくまとめましょう」という程度のことしか言えてないような気がする．

_ [論文] 実行履歴からの Role/Collaboration の復元 ▲

Tamar Richner and Stephane Ducasse: Using Dynamic Information for the Iterative Recovery of Collaborations and Roles.

Proceedings of ICSM 2002.

輪講で紹介された論文．実行履歴からパターンを認識して，一連のメソッド呼び出しに関わるクラス集合だけを取り出したりする．主にツールを作ってケーススタディしたという感じで，パターン認識部分の方法について詳しい記述がないのが少し残念．１つのクラスの中にデザインパターンの複数の役割が割り当てられている可能性にきちんと言及しているので，引用はすることになるかもしれない．

_ aosd.net が wiki 化 ▲

aosd.net のプロジェクト情報・ツール情報ページなどが，wikiに変わった．メンテナンスするコストの削減のためっぽい気がするが，そのおかげで原稿もちょっとだけ修正する必要が出てきた．

_ [work] 校正作業終了 ▲

原稿の校正を終了して，簡単な著者紹介と一緒に送付する．Word の校正ツールなんてあまり使ったことがなかったが，変更した部分にマーカーを自動で配置してくれて，CTRL+Z での一次元的に「元に戻す」のと違って，特定のブロックを選んで「ここを元に戻す」と選べるのはけっこう便利．ソースコードエディタ系であったら使いたいところ．

_ [hyCalendar] Towards 1.1 ▲

参照ファイルの表示・非表示を切り替えられるようにしてみた．ついでに，印刷まわりのバグ修正．

次は1.0.2 にしようと思ってたのだが，参照ファイルの表示・非表示を格納するためにファイル形式が少しだけ変わってしまったので，バージョンは1.1.0とする．

機能追加はとりあえず一段落したので，マニュアルの修正作業に入る．４月予定だったものが既に５月にずれ込んでいるので，早いうちにリリースしたいところ．とりあえず実行ファイルだけ先行公開．

_ Python Challenge ▲

Python Challengeというのを教えられたので，Python を使ってみることにした．最初何なのかまったく分からなかったが，書かれたお題の答えの文字列をスクリプト書いて計算して，それに + ".html" を付けたページに移動すれば OK というものらしい．

Web で拾った Python のサンプルコードで構文を適当に把握して，プログラムリファレンスとライブラリリファレンスを見ながら頑張ってみたら，stringやlistの操作が "Sequence" という名前でまとめられているのに気づかなくて苦戦してしまった． あんまり時間をこれに割くわけにはいかないが，時間が空いたときにちょこちょこと進めてみることにする．

_ [work]査読 ▲

査読した結果を一度整理するために査読報告書のテンプレートを見ようとしたら，実は手元にないこと発覚．連絡して送ってもらう．最初に連絡をもらったときに，添付ファイルの数が多かったので見落としていた．

_ [hyCalendar] 1.1.0 リリース ▲

マニュアル更新中に見つけたバグもつぶしたのでリリース．あとはVectorの人に連絡するだけ．

_ [OUCC]webカメラのトラブル ▲

ftpd がこけていたらしい．

_ [work] 査読終わり． ▲

査読のレポートを送付．これで仕事が片付いたので，PPLで発表したネタの今後の発展（後始末？）モードに移行．

_ Norton ▲

バックアップを取ろうと思ってツールを走らせたら，AntiVirusをいつの間にか通過していたウィルスメールがぼろぼろ引っかかって，AntiVirus がファイルアクセスを拒否させるせいで途中エラーで中断してしまった．

スパムフィルタに引っかかったものを入れていたフォルダの中身を全部削除して対処．

_ Python Challenge ▲

ようやく Level 6 に到達．まだ先は長い．

_ [授業] PBLとかゼミとか ▲

PBL は Robocode の，戦術についてのプレゼンテーション．戦車数３対３のチーム戦らしいので，どう戦うか色々考えているみたいではあった．戦い方の相性がかなり影響しそうな感じ．プログラミング能力にも依存するが…．授業でやる前だし．

ゼミは，資料の作り方の簡単な説明と，日本語訳の明らかな誤り部分を指摘．英語のドキュメントやその翻訳版をあまり読んでないようで，直訳ではまっているところが多い気がする．標準とか実装とか．

_ [hyCalendar] 機能拡張のお話 ▲

iCalendarの形式をサポートしてほしいという要望はあるようではあるものの，今からiCalendarのRFC読んで，概念のマッピングして，表現力がきちんと対応してないものをどう表現するか決めて，という作業になるので，面倒だから保留．ファイル形式は公開してるので誰かトランスレータ書いてくれるとうれしいけど．

WebDAVのサポートは，Webにスケジュール置くのに使えるので，Delphiに無償の良いコンポーネントが見つかったりしたらやってもいいかも．

_ [お出かけ] 三宮 ▲

mahisaというお店で，きのこのソテーとチーズを載せて焼いたマフィンがとてもおいしかった．ケーキとか甘いものメインの喫茶店なのだけど，これは軽い食事としてよさそう．

_ [Java] 設定ファイルの形式 ▲

趣味で組んでるAspectJプログラムで，設定ファイルをXMLにしようかなーと安易に考えてXerces-Javaを取ってきたまではよかったのだが，スキーマがまだ固まってないので，DOMのgetChildメソッドとかをダイレクトに使うと保守性が悪い．こんなときはXPathで対処するのが正しいのかな？

とはいえ，ろくに使ってないXercesやXalan使うより，XMLやめて簡易言語で対処したほうが設定ファイル書くときは気楽でいいなーという気もしてきた．設定ファイル作りのベストプラクティスとかってあるんだろうか．"XML best practice" とかで検索すると，スキーマ設計のベストプラクティスは見つかったが…．

_ [論文]引数を実際に使ってるかどうかの分析 ▲

David Binkley, Mark Harmann: Aanlysis and Visualization of Predicate Dependence on Formal Parameters and Global Variables.

IEEE Transactions on Software Engineering, Vol.30, No.11, pp.715-735, November 2004.

だいぶ前にチェックリストに入ったまま放置していた．

依存関係解析を使って，各手続きにおいて，渡された引数（グローバル変数含む）がどのくらい使われているかを，20個のプログラムを相手に調査した論文．

結果としては，ほとんどの引数はちゃんと使われているが，引数の数が多くなればなるほど，使われている割合が悪くなっていて，10以上になると，ほとんどの変数は使われていなかったりするらしい（可視なグローバル変数のほとんどは，実際には使われないから）．

使われている変数を調査することでテストケースの作成のコストを減らしたり，パラメータの多い関数を２つ以上の小さな関数に区分したりといった用途に使えそうで，品質のメトリクスなんかとも関連性がありそう，と述べている．

_ [work] ミーティング ▲

先生がいないのでミーティング仕切り．とはいえ，カメラレディ原稿を書く人と，締め切りが１ヶ月以上先の人と，あとは締め切りが明確でない論文投稿なので，新情報も特になし．

M1/B4は資料の下調べとかだけれど，何を調べたとか，軽い発表のようなものをどこかにセットしないと進まないか，進んでいても分かりにくいような気もする．

_ [hyCalendar] バグ報告 ▲

1.1.0でポップアップウィンドウを自前で作るようになったが，ポップアップの順番によってウィンドウのサイズが変わる（表示行数も変わってしまう）らしい．サイズ計算はある程度やっているはずなのだが，どうも誤りがあるらしい．

1.1.1として直す予定．修正としては簡単そうだが，いつ直すかが問題か．

_ [Java][ツール] Eclipse Visual Editor で GUI デザイン ▲

JavaのGUIが作りたくなったのでつついてみる．インストールはHelp → Software Updates → Find and Install で，Eclipse公式サイトからVE，EMF，GEFをダウンロードするだけと非常に簡単．

パーツをパレットから選んで配置していくだけなので簡単っぽいのだが，privateとはいえ，コンポーネントを作成する getter メソッドがいっぱい生成されるのが気にかかる．実装が簡単にできるからこうなってるのかな？

プロパティセット系のメソッドをコンポーネント生成コード部分に書き込むと，直接画面に反映されて，けっこう面白い．

_ pukiwikiのプラグイン設定変更 ▲

XSS脆弱性とかのニュースを見つけたので，アスペクト指向の情報公開用に使っているpukiwikiのプラグインの設定を変更．

_ [論文] リファクタリング効果のCOCOMO IIでの予測 ▲

Robert Leitch, Eleni Stroulia: Assessing the Maintainability Benefits of Design Restructureing Using Dependency Analsyis.

Proceedings of METRICS 2003.

輪講で紹介された論文．

リファクタリングのコストが回収できるかどうかは，実施前後での保守コストの差がどれだけあるかで決まる．保守コスト＝回帰テストのコスト＝コードを変更したときに影響を受ける平均コード量＝各手続きからの影響波及解析を行ったときの行数の平均として見積もっている．

リファクタリングでどのようにコードが変更されるかは与えないといけないので，自動リファクタリングツールとの組み合わせが必要そうで，複雑なリファクタリングに適用することは難しそう．保守コストが回帰テストのコード量に比例するかどうかといった妥当性や，見積もった結果の妥当性については評価を行っていない．ただ，リファクタリングを行った場合か行わなかった場合のどちらかでしか実際には計測できないので，このあたり苦しいところではある．

_ [論文] Fragile Base Class Problem ▲

Leonid Mikhajlov and Emil Sekerinski: A Study of The Fragile Base Class Problems.

Proceedings of ECOOP 98.

親クラスと子クラスがあって，親クラスを変更したら子クラスに影響が及んでしまう問題(Fragile Base Class Problem)について述べた論文．

たとえば，Bag.addAll が Bag.add を内部的に使っていることを想定して，addメソッドで要素数をカウントする CountableBag を作ると，Bag.addAllが addメソッドを使わなくなったとき，CountableBagは正しく機能しなくなる．このような問題を色々分析して，問題を避けるために (1) ベースクラスの変更や，サブクラスは，メソッド依存関係に循環を導入しないこと，(2) 親クラス側を変更するとき，メソッドは，自身のほかのメソッドの振る舞いに余計な仮定を置かないこと．(3) 継承クラス側のメソッドは，親クラスの中で自分自身を呼び出しているとき，それを継承クラス側で受け取ろうとしないこと．(4) 継承クラスから，親クラスの内部状態を触らないこと，を挙げている．

で，上記のような問題がなく，親クラスと子クラスが安全に拡張できるような性質かどうかの判定を行う Flexibility Theorem というのを作っている．

_ [論文] Sublclassing Contract ▲

Clyde D. Ruby: Safely Creating Correct Subclasses without Seeing Superclass Code.

Proceedings of OOPSLA 2000.

OOPSLA2000の２ページのポジションペーパー．サブクラスからスーパークラスへの呼び出しを行っても安全かどうか，オーバーライドしなければならないメソッドがないか，といった情報をクラスの contract の一部に含めようという提案．

_ [授業] ゼミ ▲

３人発表で，みんなUSBメモリを持ってきてた（１人はMP3プレーヤだったけど）．メディアとしては，フロッピーよりも一般的になってきた感がある．

来週は学科の各研究室の研究内容紹介らしいので研究室には来なくていいよーという告知を出して，あとはあんまり指摘することもなくあっさり終了．

今回登場した謎の訳語は，利害関係者の意味でのstakeholder → 弁護士．辞書の１つに，係争物保管人という意味の後ろに「（普通, 弁護士）」と書かれていた．そこから出てきたのかもしれないが．不思議．

_ ほうじ茶 ▲

研究室で余っていたほうじ茶450g（ちょっと賞味期限が近い）をもらった．OUCCの人でほしい人にあげようかと思うけれど，450gは普通のお茶缶に入らないのでどうしたものやら．

_ [論文] デザインパターンを使っても欠陥が入りにくくなったりはしないみたい ▲

Vokac, M.: Defect frequency and design patterns: an empirical study of industrial code.

IEEE Transactions on Software Engineering, Vol.30, No.12, pp.904-917, Dec. 2004.

ざくっと目を通しただけだが，デザインパターンは良い設計の再利用で，良い設計ならバグが入り込みにくいはず，本当にバグが少ないかどうか調べてみよう，という調査を行った論文．

対象システムは１つなので，さすがにあまり強い結果でもなく，デザインパターンによっても傾向が違って，実はあまり影響なさそう？ということが分かった，くらいか．

_ [hyCalendar] towards 1.1.1 ▲

ポップアップウィンドウのサイズが毎回異なる問題を修正したついでに，期間予定のウィンドウ上での表示とポップアップ時で順序が違うことがある問題を修正した．

ついでに，六曜（友引とか仏滅とか）を表示する機構のプロトタイプを作ってみた．六曜の計算自体は，実装が正しいかどうか検証することが困難なので，外部ライブラリに頼りっきりにして，責任を切り離しておく．

_ [hyCalendar] 1.1.1 リリース ▲

調べてる間にさらにバグを見つけたので，それも直してリリース．六曜表示に必要なライブラリは，再配布に関する要件が書いてなかったので，作者の方に連絡を取ることにした．それまでは，作者の方のページへのリンクで対処．

_ [AspectJ] AspectJのよいところ？ ▲

普通，プログラムとして，「やりたいこと」を書くけれど，AspectJ の declare warning/error みたいに「やってはいけないこと」も一緒に書けるので，特定の concern に限定した（他の開発者には触れてほしくない）メソッドの呼び出しを禁止するとかいった使い方ができて，実はけっこう嬉しい気がするこの頃．

単に設計が悪い可能性も否定できないし，AspectJ の declare error よりは Hyper/J 系を使えという話かもしれないけど．

カスタマイズ可能なコーディングルールチェッカでいいじゃん，とか言われそうだけれど，アプリケーション依存なことがいっぱい含まれているので，ツールの一部というよりはプログラムの一部であるべきという気はする．

_ [論文] Modular Reasoning な話 ▲

G. Kiczales, M. Mezini: Aspect-Oriented Programming and Modular Reasoning.

Proceedings of International Conference on Software Engineering 2005, pp.49-58, May, 2005.

コードが modular であるとは，一箇所にまとめて書かれていて，他のシステムとどのようにインタラクションを起こすかのインタフェースがあって，インタフェースの整合性がチェックできて，他のモジュールと接続することができるとき．また，Modular Reasoning とは，そのモジュールに関する決定が，他のモジュールを見なくてもできるようにすること．

過去の研究では，クラス側をBlack-Boxとみなせるようにアスペクトの影響力を抑えたり，アスペクトについての言及をクラス側で行うというのが多いが，こちらは AspectJ などのフルセットをきちんと扱いたいというもの．

アスペクトのインタフェースをどう規定するとうれしいか，というのがメインの話題で，アスペクトのインタフェースの中には，アドバイスやポイントカットの宣言と，それがどこで動くのかというクラスのメソッドのリストなども含めている．ただし，executionポイントカットならメソッド名だけでいいが，callやget, setについては join point shadow を含んだメソッドをリストするという程度で，良いアイディアは今のところないらしい．

PointクラスとLineクラスの座標移動時のDisplayUpdatingに関するアスペクトの例を用いて，Non-AOPとAOPについてのReasoningの作業の違いを簡単に説明している．DisplayのUpdateが，オブジェクトが移動した後にただ１度だけ起きることを理解して，それを守った形でコードを変更するには，そのルールについてのドキュメントにたどり着くという作業と，DisplayUpdateを起こすタイミングを知る必要がある．Non-AOPとAOPで，ドキュメントを調べる作業までは同じだが，DisplayUpdatingの振る舞いを調べるのは，Non-AOPの実装では全体を読んでいく必要があり，AOP実装だと簡単に知ることができると述べている．

_ [論文]仮定の記述をアーキテクチャの図に含める ▲

P. Lago, H. van Vliet: Explicit Assumptions Enrich Architectural Models.

Proceedings of International Conferenc on Software Engineering 2005, pp.206-214, May 2005.

ほとんど図だけの拾い読み．

変化するものを管理するのと同様に，変化しないもの，システムに対する様々な仮定（技術的・管理上など）もきちんと扱いましょうというものらしい．アーキテクチャの図（Feature Model とかクラスより抽象度の高い図）で，仮定を表現した assumption という要素を配置して，どのfeatureに影響を与えているか F-Impacts 辺を作って示す．また，featureを実装する役割の要素（featureからリンクされている要素の一部）からは，assumption に対して Realize 辺を引くといった感じ．

最終的には，作ったアーキテクチャから，実際のモジュールへの対応を追いかけていくと，assumption が変化したときへの応対などが楽になりそうではある．traceability が確立されてないといけないから，MDAとか好きな人にはよいのかも．

_ 支店番号の変更 ▲

銀行の支店番号が変わって新しいカードが到着．豊中郵便局まで自転車で取りに行ってきた．片道約20分．

_ [論文] コードの使い方の例を見つける ▲

Reid Holmes and Gail C. Murphy: Using Structural Context to Recommend Source Code Examples.

Proceedings of International Conference on Software Engineering 2005, pp.117-125, May 2005.

フレームワークなどを使うときには開発者が適切な順番でクラスのインスタンス化や準備用メソッドの呼び出しを行う必要があるが，それを調べるのはけっこう大変なので，自動でコード片を探してこようというもの．

基本的には，開発者が書きかけのコード片から，使っているクラスやメソッド名を取ってきて，リポジトリ内にあるメソッドが使っているクラスやメソッドとマッチを行うというもの．"Structural Context"という響きにちょっと期待したのだけど，特別なものではなかった．

呼び出す相手のクラスやメソッドは分かっていても，そのインスタンスをどこからもらってくるといいのか分からないときなどに使える．

Eclipse を実験相手にして，与えたタスクは一通り実現されたらしいが，適切な例が見つからないものもあった．ただ，それがマッチさせる基準の問題なのか，そもそも例がなかったのかは不明とのこと．

動機の部分（フレームワークを，ドキュメントなどをもとに正しく使うのはけっこう大変というあたり）は別のところで使いそう．

_ [論文] 動的なロールのバインディング ▲

Tetsuo Tamai, Naoyasu Ubayashi, Ryoichi Ichiyama: An Adaptive Object Model with Dynamic Role Binding.

Proceedings of International Conference on Software Engineering 2005, pp.166-175, May 2005.

複数のオブジェクトが相互作用するための "Context" というオブジェクトを作って，Context の中に定義された各 Role に対してインスタンスを割り付けると，Role に定義されているメソッドが使えるようになるというもの．

メソッド名のバインディングや，Role を担当するインタフェースへの require などの要素もあるので，一般的なアスペクトの逆で「オブジェクトから明示的にバインドされて使われるアスペクト」として，しっかり作られたモデルという印象．

コンテキストのインスタンス数がコントロール可能で，インスタンスごとにバインディングの設定が可能で，クラス側ではなくコンテキスト側の再利用が容易となっている（AspectJ や Caesar のように抽象アスペクトと具象アスペクトを区別しなくてよい）．ちょっとコーディング上の工夫をすれば，Association Aspect でやりたいと思った Role の１対Ｎ関係などの管理なんかもできるかも？

_ [hyCalendar]六曜表示モジュール ▲

六曜計算ライブラリの再配布の許諾がいただけたので，セットでの配布開始．

_ [Java] Primitive Collections for Java (PCJ) ▲

int や long を格納できるコンテナクラス群 PCJ のページを 1.0 beta 以来久しぶりに見に行ってみたら，最近はあまり更新されていないみたいだった．

int リストの各要素に対する処理は IntIterator などの Iterator を拡張したクラスを使うので，Iterable（for文の新しい形式）をはサポートしてくれていない．サポートしてても int から Integer への boxing → unboxing という激しいオーバーヘッドが出そう．

あんまり更新されてない分，違うバージョンを使ってしまって不整合を起こすとかいうこともないので，嬉しいといえば嬉しい．

_ [hyCalendar] カレンダーのタブの保存 ▲

１ヶ月単位で作っているタブの表示は保存できないのか（４ヶ月先とかの予定を記入した後は，アプリ再起動しても表示しっぱなしにできないか）という質問が届いてたので，できませんと返事を出した．

何か対応はしたほうが便利になってよさそうな気はするが，前の月のタブは自動で閉じてほしかったりするので，ちゃんとしたルールの決定が難しそう．

_ 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の変更に関するドキュメントを書かないといけないので，そこで簡単なリファクタリング用スクリプトを手動で書く，とかいうのでもいいような気はする．

_ [work]輪講の準備 ▲

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

_ 手提げ袋 ▲

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

_ 一力 ▲

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

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

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

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

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

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

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

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

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

_ [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 があったかを求める（実行履歴の中に区切りを入れると言ってよい？）．

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