netail.net

_ [Java]Scanner クラス ▲

Sun の Core Java Technologies Tech Tips を見ていたら，J2SE5.0 で加わった Scanner クラスはかなり便利そうな印象を受けた．

java.util.StringTokenizer のストリーム対応版みたいな感じだが，String next() 以外に int nextInt() などを用意してたり，delimiter として正規表現(java.util.regex)が使えたりするらしい．

_ [work]OOPなコールグラフ ▲

AspectJ なバイトコードで付加されている情報はorg.aspectj.weaver.AjAttribute クラスを使って読み出せることが分かったので，AspectJ 展開後のコード相手の解析は何とかなりそう．

ただ，Java バイトコードからメソッドのサマリ情報を生成するまではわりと自動化できてきたが，集めたメソッド間の呼び出し関係と所有しているオブジェクト参照の情報とを同時に提示する方法としてはよさそうなものがないことが判明．とりあえずオブジェクト参照とクラスの関係も抽出しておいて，グラフ上に一緒に載せてみることにする．

_ [OUCC]類似画像判定 ▲

定点カメラで撮影した144枚（10分間隔・24時間）の画像の画素間の距離を判定する実験をしてみた．

画像読み込みには libjpeg62-dev パッケージを普通に使ってみた．サンプルコードが落ちていたので，それを拾って改造してみた．

画像間の距離を，ピクセルごとの色空間(RGB/HSV)での距離の総和と定義してみたが，画像の10〜20％程度を落とす程度なら，いちおう直感的に「似ている」と判断できるくらいみたい．

_ クリスマスマーケット ▲

今年もどうやらやってるらしい．http://www.skybldg.co.jp/event/xmas2004/

時間があればまたグリューワイン飲みに行きたいところ．

_ [Java] Subversion ディレクトリ ▲

Eclipse でソースをコンパイルするとき，Build Path の Exclude の中に **/.svn/* を入れておかないと.svn ディレクトリの構造が丸ごとコピーされて，bin ディレクトリ以下が Subversion 管理下にあるとTortoiseSVN に勘違いされてしまうらしい．

ディレクトリの中身がコピーされるわけではないので直接的に被害が出るというわけではないようだが，一部怪しげな振る舞いになってしまうときがあるらしい．

（追記：比較的新しいバージョンの Eclipse では，svn 関連のデータはちゃんと無視してくれている様子）

_ [Java] 型キャスト ▲

今日のはまり．

equals メソッドを別クラスからコピー＆ペーストしたら，インスタンスチェック部分を直し忘れて，if (o instanceof コピー元) { ... }というコードのままにしてしまっていた．this.equals(this) が false になった時点で気づいた．

_ [論文]単体テストをアスペクトで記述 ▲

Guoqing Xu, Zongyuan Yang, Haitao Huang, Qian Chen, Ling Chen and Fengbin Xu:JAOUT: Automated Generation of Aspect-Oriented Unit Test.Proceedings of APSEC 2004, pp.374-381.

単体テストの記述をアスペクトで書こうというお話．単に AspectJ では書きにくいのでAspectJ に translate されるような言語 AOTDL というのを作っている．基本的には JUnit などで記述されたテストケースと並行して，Temporal Logic などで望ましい性質が成り立っているかどうかをテストするアスペクトを付加する．このときに，無視してよいテストケースの条件も別に記述する．（たとえば，スタックのテストであれば，オーバーフローが起きるかどうかのテストの場合，Temporal な性質のほうは無視して良い）

意味のある／なし判定を，自動生成したテストケースの振り分けに使っているらしく，適当なグループ分けされたテストケースのうち，少数ずつサンプリング→実行して，後から大量のテストケースを投入するときに意味のないテストケースがあまり含まれないようにする，らしい．

_ [論文]実行の差分を使ったデバッグ手法 ▲

W. Eric Wong and Yu Qi:An Execution Slice and Inter-Block Data Dependency-based Approach for Fault Localization.Proceedings of APSEC 2004, pp.366-373.

失敗したテストケース１つと成功したテストケース１つ以上が与えられたときを対象としたデバッグ手法．

単純には，失敗したテストケースで実行した文集合から成功したテストケースのどれかで実行した文集合を取り除いてからコードを調べて，原因が見つからなければ成功したテストケースの数を減らして（探索対象コードを増やして）調査を続け，それでも見つからない場合は失敗したテストケースの実行した文集合にデータ依存関係を持っているブロックを探索対象に追加し，それでも見つからない場合は追加されたブロックにデータ依存しているブロックを…というように段階的に探索対象のブロックを増やしていく方法．

これで文集合としては失敗時に実行された文集合の３〜６割程度のサイズに分布するらしい．

スライシングなどで見つけにくい「必要なはずのコードが抜けている」ような場合でも，文集合を段階的に増やしていくときに予期しない文が増えたりすることで気付きやすい，らしい．

_ [論文]インタラクションの分析 ▲

Lei Wu, Houari Sahraoui, Petko Valtchev:Automatic Detecting Code Cooperation.Proceedings of APSEC 2004, pp.204-211.

C などのプログラムの実行履歴からシナリオID，呼び出し階層の深さ，メッセージ送信元・送信先のモジュール，関数名を取り出してきて，基準をユーザが組み合わせることで自動的にパターンを分析してくれるらしい．

で，出てきたパターンに対して，どのような Collaboration パターンか（Supplier-Consumer，Director-Manager-Worker など）役割を当てはめてシステムを理解する，らしい．

１個の「パターン」をどこで認識するのか，何かパターン認識のためのツールキットを作ったとはあったが，それ以上は不明．分割の適切さについても不明．

パターン同士が同じものかどうかの比較基準もあいまい．ケーススタディで一言「メッセージの順序は考慮しない」と書いているので，呼び出し回数付きコールグラフともいえる実行ツリーを作る手法(*1)でのツリー比較っぽい．

あとは，発見されたパターン（粒度としては細かそう）に対して，統計ツールなどを使って性質を調べたり，このパターンでは各ルーチンがどのような役割をしているか，というのを調べていくことになるらしい．

いちおうシーケンス図生成などの話の関連研究なのだが，肝心のアルゴリズム的な部分があいまいなので何とも評価しがたい．オブジェクト指向じゃないので適当な方法でもそれなりにうまくいくのかもしれないが．

*1: Wim De Pauw, David Lorenz:Execution Patterns in Object-Oriented Visualization.Proceedings of COOTS 1998.

_ [論文]Concern Graph ▲

Concern Graphs: Finding and Describing ConcernsUsing Structural Program Dependencies.Martin P. Robillard and Gail C. Murphy.Proceedings of ICSE 2002.

ある Concern についての情報をクラス・メソッド・フィールドを頂点とし，declare, call, read, write, check （instanceof/キャスト）,create, superclass を関係としたグラフを作ることで，ソフトウェアの変更を容易にしようという試み．

FEAT は Concern Graph の作成を助けるツールで，メソッドから Fan-Out, Transitive Fan-Out を計算したり，クラスへの参照を取ってきたりする．（ICSE2003でツールデモをやってた）

バイトコードからモデルを作っているのだが，ソフトウェアの変更という観点では，コンパイル時にfinal 宣言された定数が展開されたりメソッドがインライン化されたりといった影響が気になる，と述べている．

制約としては，ある Concern に参加する頂点の集合を取り出したとき，頂点間の依存辺を単にすべて取り出してしまうと，別の Concern 用に作られた Call や Read/Write も含んでしまうかもしれない，というところ．手作業でフィルタする必要がある？

_ [work]スライシングのテスト ▲

プログラム依存グラフをもとにサマリ情報を生成する処理がほぼ完成．for, while, try, if, などの制御構造＋メソッド呼び出し，フィールド参照などのテストデータを与えてサマリを生成してみたら，ほぼ結果は正しいみたい．目視確認なのがいけてないが．

JUnit とかで自動化できればいいのだが……．まだソースコードとの対応関係の取得を実装すればisDataDepends(L1, L2) のようにしてテスト関数を実装できるようになる…かも？

_ AspectJ 1.5.0M1 ▲

J2SE 5 にあわせて AspectJ 5 の開発もがんばっているみたい．

とりあえず最初のステップとして annotation など新構文がサポート．call(@hoge void A.*(..)) とか書けるらしい．宣言的な（Java World の記事で「アトリビュート指向な」と表現されていた）アスペクトの記述が可能になるという意味でけっこう大きいかも．

_ [work]データ依存解析 ▲

java.util.Date.parse(String) メソッドでスライスツールが落ちるので調べてみたら，約1000命令のうち，分岐命令が79個．ローカル変数が19個，スタック最大深さが７なので，分岐命令ごとにフレームを複製して合流地点でフレームの同一性をチェックする（解析済みの状態と同じ状態が到着したら捨てる）という現在のアルゴリズムだと，組み合わせ爆発が起きているっぽい．26個も変数の状態が一致することのほうが少ないだろうし…．

追記:制御フローを見てみたら，分岐→合流→分岐→合流という感じの流れになっていたので，２のＮ乗（Ｎ＝分岐数）にかなり近いような状態になっていた様子．というわけで，アルゴリズム差し替えの予定．

_ 写真プリンタ ▲

研究室にある OLYMPUS CAMEDIA P-200 で印刷の画像サイズが調整できない？と思っていたら，プリンタが 320 dpi 固定なので 1024x768 画像なら規定の用紙サイズにそのまま出てくることが判明．640x480 だと２インチ x 1.5インチなのでかなり小さい．

どこにメモしておいても書いたこと自体忘れそうなのでとりあえずここにメモしておく．

_ [work]データ依存解析の書きなおし ▲

制御フローグラフの "合流点" ごとに，そこまで到達するデータ依存関係を解析を記憶しておいて，また合流点から到達したデータ依存関係を覚えておいて，後からまとめて集計する方式に切り替え．

グラフ上での分岐・合流点間の経路の個数で計算量はだいぶ抑えられる…はず．

_ wiki ▲

アスペクト情報の wiki が荒らされていたので復帰．荒らす人はやっぱりいるものらしい．

_ [AspectJ]AJDT 1.2.0M2 ▲

新バージョンリリース．Eclipse 3.1M3 まで対応らしい．どのメンバーにアスペクトが関与しているかのアウトライン表示など，だんだん強化されてる．

それにしても，毎回 Eclipse のバージョンに依存しまくりなのが大変そうではあるが．

_ 携帯ストラップ ▲

家の小物入れ用引き出しを片付けてたら発見．Pentium2 ストラップ

かなり前の学祭での講演会か何かのときにもらったものだと思うが…．

_ 映画 ▲

飲み会が２晩連続して疲労気味．

映画の花道シート予約というのを初利用してみた．普通の予約だと，関西圏は毎週木曜に翌週の日曜までのが買えるというところが，曜日関係なく普通に１週間先まで予約できるらしい．使える映画館は限定されているけど．http://eiganohanamichi.com/

_ [work]配列／フィールド経由のデータ依存解析 ▲

データフロー解析の構造が変わってしまったので再実装を開始．通常のデータフロー処理の場合と違うのは，通常のデータフロー上で参照の到達関係を調べて，どの型が使われるかを調べる必要がある点．

全体構造の擬似コードと，制御パスごとに必要なデータ構造を作る部分はほぼ完成．あとは，各パスで集めた部分情報を集計する処理を実装するだけだが，ここから長そう．

_ [Delphi]コンソールのリダイレクト ▲

Graphviz のコンパイラを特定のファイル右クリックから使いたいので，第一引数にファイル名を取って dot.exe を実行する簡単な実行ファイルを作ってみた．

パイプを使ってリダイレクトする方法は以下のサイトを参考にしてみた．http://hp.vector.co.jp/authors/VA026252/tips/delphi_anonymous_pipe.html

TMemoryStream にデータを一度書き出して，それを読み込んでいる．Stream に書き込んだ後，再読み出しするのにPosition := 0 を忘れて読み込みに失敗したりしたが，それ以外は特に問題なく動作しているみたい．

_ Graphviz GUI ▲

dot ファイルにプログラムを関連付けたら，あとはダブルクリックするだけでファイルがコンパイルされるというお気楽仕様．Graphviz を使ってる人がそもそもどれくらいいるか分からないのだけど，作ったのを非公開にするのももったいないのでとりあえず公開．

http://sel.ist.osaka-u.ac.jp/~t-isio/dotui.html.ja

_ 研究会登録費補助 ▲

情報処理学会の学生会員に対する研究会登録費補助は，平成17年度は１研究会に限って登録費が *無料* になるとのこと．ありがたい．

http://www.ipsj.or.jp/09sig/kenkyukai/student17.html

_ [論文]ルールベースでのスライシングの実装 ▲

Mathieu Verbaere の修士論文，Program Slicing for Refactoring の４章: Slicing using inference rules を読んでみた．

{parsed statements, Context, slicing result} の３つ組を特定ルールに基づいて更新していくことでスライシングを実現している．

使うのは，各命令での Ref 集合と Def 集合で，Context は，各変数がそれ以降で参照される可能性があるか（もしくは上書きされるだけなのか）を保存している．

呼び出し位置ごとに個別に処理を行う Context-sensitive なスライシングの実装となっているみたい．

グラフ上での処理に比べるとアルゴリズムが厳密に記述されている感じはする．計算されるスライスとしては，ほとんど Summary Edge を使った SDG の作成と変わらないようだが，メソッドごとの PDG を全体の SDG として接続する場合に比べて，手続きごとに作られた３つ組を呼び出し文ごとにマージする処理として記述されるので，「メソッド単位での処理結果」が再利用される様子が分かりやすい．

_ tex2text ▲

Tex2Text.rb を地味に更新．Ruby 1.8 になって，文字列リテラル内のダブルクォートのエスケープあたりが微妙に変わって動かなくなっていたのを修正．tex2text 公開ページ

_ [論文]制御フローに基づくアスペクトマイニング ▲

Jens Krinke, Silvia Breu:Control-Flow-Graph-Based Aspect Mining.1st Workshop on Aspect Reverse Engineering.

以前実行トレースからマイニングしていたものを，制御フローグラフから探してみたというもの．で，それなりに候補は出てきたようなのだが，Iterator などコレクションの処理や，あるメソッドを実行した後の後始末など，アスペクトとして抽出しにくいものも一緒に出てきてしまうらしい．アスペクトにできるものもきちんと含んでいるようなので，いかに "refactorable" なものだけを抽出できるようにするかが問題だろうと考えている様子．

_ [論文]重要なクラスを見つける ▲

Andy Zaidman, Toon Calders, Serge Demeyer, Jan Paredans:Selective Introduction of Aspects for Program Comprehension.1st Workshop on Aspect Reverse Engineering.

重要なクラスにだけロギングなどのアスペクトを追加したいが，どうすれば重要なクラスを見つけられるだろうか，ということで通常のプロファイル結果からノードをクラス単位にまとめたコールグラフを作成し，Web で使われる Hub/Authority の識別を行うことを提案している．

Hub は数多くのモジュールを呼び出すモジュールで，Authority は数多くのモジュールに呼び出されるモジュール．で，Authority がいわゆる Utility など再利用可能なクラスであることが多く，Hub はプログラムを駆動する側にあるだろう，ということからHub が重要である，と認識する．ケーススタディとして Ant のプロジェクトに適用していて，Ant 開発者がマーキングしたクラスを正解とみて，評価してみている．CBO による順序付けよりは，人間が重要だとマークしたものを見落とす可能性はかなり少なくなっている．ただ，正解率的には６割程度．また，通常のコールグラフでなくプロファイル結果なので，シナリオによるバイアスがかかる可能性がある．（「そのシナリオで」重要なクラスを見つける，という意味では問題ないが）

あんまりアスペクト限定の話ではないような気もする．

_ [論文]アスペクト導入の効果は？ ▲

1st Workshop on Aspect Reverse Engineering より．５ページのショートペーパー群．Aspect Mining/Refactoring がテーマ．http://homepages.cwi.nl/~tourwe/ware/submissions.html

_ Mariano Ceccato and Paolo Tonella:Measuring the Effects of Software Aspectization. ▲

アスペクト導入によるメトリクス値の変化を調べることでアスペクト導入の効果を測りましょうという論文．

Observer パターンの Java 実装と AspectJ 実装を比べていて，AspectJ バージョンのほうが１モジュールあたりの機能数である Weighted Operations in Module (WOM) が低くなりそのモジュールが呼び出す他のモジュール数 Coupling on Method Calls (CMC) や\呼び出されうるメソッドの数 RFM (Response For a Module) は減少している．

で，逆に悪くなっているのは，AbstractObserverProtocol の導入によって継承階層が増加すること．あと，アスペクトがどれだけのモジュールを横断しているかという指数だけは増える（当然ながら）．

これだけだと，AOP アプローチのほうが有利に見えているのだが，使っているメトリクスで「アスペクトが横断しているモジュールの数」などはJava 実装との比較評価には使っても意味がなさそうなので，まだ何とも言えないような気がする．

_ [論文]クラス構造の分類に基づくパターンの調査 ▲

Gabriela Arevalo, Frank Buchli, Oscar Nierstrasz:Detecting Implicit Collaboration Patterns.Proceedings of 11th Working Conference on Reverse Engineering (WCRE'04), pp.122-131,November 8-12, 2004, Delft, The Netherlands.

クラス図から，A isSubclass B, A access B などのクラス間の関係を取り出し，クラス図から選んだいくつかのクラス（この論文では２〜５個程度）の連結関係を Formal Concept Analysis で分類し，デザインパターンの連結構造と比較することでパターンの実装などを発見しようという試み．

クラス図からクラス群を選ぶときの組み合わせを減らすことや，分類結果から「同じ型」をマージするなど，組み合わせ数を減らすことに気を配っている．

パターンとよく似た形になっているものなども見つけることができるが，逆に，デザインパターンと偶然同じ形になったものというのも登場してしまう．また，分類された結果から，実際に有用かどうかを検査するのは別の問題になっている．

_ [論文]Topic Map によるソフトウェアの可視化 ▲

読んだまま放置していた論文メモをざっくり整理．

Christian Zimmer:Tuna: Ontology-Based Source Code Navigation and Annotation.Workshop on Ontologies as Software Engineering Artifacts.

Topic Map というグラフによる知識表現でソース情報を表現するために，Topic Map の各要素が何をあらわすかを定義している論文．で，実際に Topic Map に対応したビューア＆クエリーかけツールを作っている．出力がグラフになったらコードが読みやすいかというとそうでもないと思うのだが．JQuery よりは言語非依存といえるが，提供できるサービス量はどうなのかよくわからない．

_ [hyCalendar]towards 1.0 ▲

メール＆掲示板で色々要望は集まってきた．

アプリが開いている単体ファイルに対応していたCalendarDocument クラスが今まで単体だったものが複数インスタンスへ変化するので，暗黙のうちに Singleton を前提としてしまっているコードがだいぶ変更されてしまう．

Singleton に染まったコードをうまく解除する変更パターンのようなものはないものだろうか…．

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

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.

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

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

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

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

_ [Delphi]RichEdit の Protected 属性 ▲

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

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

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