«前の日(12-28) 最新 次の日(12-30)» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2002-12-29 古い日記からの変換データ

_ 大掃除

実家に帰る前に下宿の大掃除.ついでに部室でも大掃除.「1年使わなかったものはこれから1年も使わない確率が高い」という基準でがんがん捨てるものを決めていく.

下宿のほうでは,買った本がかなりたまっているのを実感.部室のほうは,散らかりすぎというか,ゴミが多すぎ.

_ お菓子

人から鳥取旅行のお土産をもらった.鳥取県境港市は水木しげるの故郷ということで「目玉おやじの棒付き飴」.目玉をあしらったブルーベリー味の棒付きキャンディだった.まあ見た目はともかく,普通の味.

これをもらったついでに,天保山マーケットプレースで一緒におやつを食べる.たこ焼きコロッケとかいう一口コロッケの中に蛸が入っているという品を食べて,それからカフェ デュ モンドでベニエを食べた.ベニエは普通に美味しい.パウダーシュガーで手が真っ白になったけど.

で,「なにわ名物開発考社」でたこ焼きゃんでぃとたこ焼きようかんを購入して帰った.

たこ焼きゃんでぃのほうは,「うまい棒のたこ焼き味がずっと続くような感じ」と評される.生姜が素で入っていて,後味がとても悪い.

たこ焼きようかんは,ソースやら海苔やらが全部入ったようかん.味としては,たこ焼きエキスを注入したような羊羹.一言で言うと不味い.これが人気No.1というのは非常に嘘っぽいが……珍しさではトップだから売れるのだろうか.


2003-12-29 古い日記からの変換データ

_ AspectJ

ライセンスまわりの話でリンク貼られていたので,よく見てみたら,バイナリ改変とソース改変の話が「コードの改変」というので紛らわしかったので修正.#こっちでやってるのは基本的に全部バイナリ改変の話.

_ 帰省

実家に帰省する準備をする.服があることは分かっているので,持ち物はノートPC,b-Mobile カード,携帯電話の充電ケーブル,折りたたみ傘くらい.実家は ADSL 回線だから b-Mobile のカードは必ずしも要らないのだが,実家のPCのケーブル接続を変えるのが面倒なのでいちおう持って帰る.

MDがわりにしているPDAは,稼働時間が短いので今回は見送ることにする.

_ Calendar

hyCalendar 0.6 いちおう完成?バイナリができたのでアーカイブを作ってみる.あとはクリーンインストールして,テスト動作させておかしなところがなかったらリリースできそう.


2004-12-29 古い日記からの変換データ

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

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 による順序付けよりは,人間が重要だとマークしたものを見落とす可能性はかなり少なくなっている.ただ,正解率的には6割程度.また,通常のコールグラフでなくプロファイル結果なので,シナリオによるバイアスがかかる可能性がある.(「そのシナリオで」重要なクラスを見つける,という意味では問題ないが)

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

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

1st Workshop on Aspect Reverse Engineering より.5ページのショートペーパー群.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 バージョンのほうが1モジュールあたりの機能数である 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 などのクラス間の関係を取り出し,クラス図から選んだいくつかのクラス(この論文では2〜5個程度)の連結関係を 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 に染まったコードをうまく解除する変更パターンのようなものはないものだろうか….