netail.net

_ [ツール]Inkscape ▲

inkscape という open source な SVG エディタがあるらしい．http://inkscape.org/

試しにちょっと使ってみた限りでは，- 図のサイズを調整しての印刷が容易で，そこそこきれい．- png のエクスポートが可能．- 保存形式に eps もある．ということで，かなり好感触．

読み込み時にプログレス表示などがないので，ちょっと重い処理したときに固まったように見える難点はあるが，Internet Explorer や Batik よりも軽快に使えそう．

_ [Delphi]フォント設定ダイアログ ▲

フォント設定ダイアログで色をコンボボックスから選択するとき，コンボボックスを閉じるのに，色の項目名を選ぶのではなくコンボボックス自体をクリックして閉じた場合に，ダイアログでのプレビューは更新されてもダイアログの Font プロパティには保存されないらしい．微妙な操作で回避できるといえば回避できる．

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

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

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

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 に染まったコードをうまく解除する変更パターンのようなものはないものだろうか…．

_ tex2text ▲

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

_ 研究会登録費補助 ▲

情報処理学会の学生会員に対する研究会登録費補助は，平成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 として接続する場合に比べて，手続きごとに作られた３つ組を呼び出し文ごとにマージする処理として記述されるので，「メソッド単位での処理結果」が再利用される様子が分かりやすい．

_ Graphviz GUI ▲

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

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