netail.net

_ [VolumeDeskbar][お知らせ] Volume Deskbar 1.0.10 リリース ▲

「ポップアップで音量を表示する」オプションが増えました．マウスカーソルでポイントされている間はずっとヒントで音量が表示されます．

また，ボリュームコントロールからの操作などで音量が変化した場合には，カーソルが乗ってなくても約３秒間だけポップアップ表示されるようにしてみました．いちおう，一般的なヒントの長さだとは思います．

また，ミュート時は，ヒント文字列の後ろに「(Mute)」を付けるようにしてみました．

ご意見，ご感想，お待ちしております．

(追記) リリース状態にしてから気づきましたが，画面右端に縦方向表示でツールバーを使っている場合，「Mute」で伸びたぶん，微妙にヒント文字列が音量バーに重なってしまうようです．ごめんなさい．次に改良ネタがたまったときに，一緒に直したいと思います．

_ [論文] Dominance Tree アルゴリズム系を探すのこと ▲

こちらで紹介されているDominance Treeを探索する反復アルゴリズムに相当するものをちゃんと論文にまとめている人を探してみたら，Keith D. Cooper, Timothy J. Harvey, Ken Kennedy: A Simple, Fast Dominance Algorithm. というのがどうやら同じようなものらしい．性能評価も付いている．

しかしこの論文，掲載先は SPE だと書いてあったにも関わらず，SPEの目次には載ってなかった．よく見たらVol.がなくてNo.だけあったり，pp.1-10って書いてあるのにPDFが28ページある．

あまりに怪しいので，関連を調べてみたたら，Finding Dominators in Practiceという論文が，K. D. Cooper, T. J. Harvey, and K. Kennedy. A simple, fast dominance algorithm. Available online at http://www.cs.rice.edu/~keith/EMBED/dom.pdf.と引用していた．こちらの論文は，２フェイズに分けたDominanceツリー処理なんかの性能評価もしているので，こちらを引用したほうが無難かもしれない．

L. Georgiadis, R. F. Werneck, R. E. Tarjan, S. Triantafyllis and D. I. August: Finding Dominators in Practice. In Proceedings of the 12th Annual European Symposium on Algorithms (ESA 2004), Lecture Notes in Computer Science, volume 3221, pages 677-688, Springer-Verlag, 2004.

_ [論文] "Feature-Oriented" リファクタリング ▲

Jia Liu, Don Batory and Christian Lengauer: Feature Oriented Refactoring of Legacy Applications.

Proceedings of ICSE 2006, pp.112-121, Shanghai, China, May 2006.

Feature-Oriented Refactoring (FOR) は，色々なfeatureを持ったソフトウェアを，featureごとにモジュール分割する作業のことを指す．この作業を補助する手法を提案している論文．

各featureは，それぞれ固有のメンバー定義（AspectJでいうインタータイプ宣言）である基本のモジュール(base)と，基本モジュールに対する変更操作（アドバイス）である派生モジュール(derivative)によって構成される．派生モジュールの中には，依存する他の派生モジュールを改変するもの（他の特定のfeatureの存在を仮定した処理）が含まれる．この定式化が論文の前半を占めている．

プログラムをfeatureごとに分割する作業では，最初に，開発者が「featureがどう合成されているか」をモデルとして（マニュアルやソースから割り出して）定義する．たとえばロギング機能とバックアップ機能が付いたバッファクラスなら [LOGGING] [BACKUP] BUFFER といった具合．ケーススタディでは GenVoca という文法をこのモデル記述のために使っていて，もしあるfeatureが他のfeatureに依存しているなら「LOGGING implies BACKUP」のように制約を記述できるようにしている．

モデルができたら，元のプログラムの各メンバーがどのfeatureに属するかをラベル付けし，base 部分と derivative 部分を先に切り離してから（先の例なら BUFFER だけを先に取り出してから），派生モジュールのほうをさらに細かく分割していく．

featureごとのモジュールさえできたら（形式的にはAspectJのアスペクトやAHEADのrefineクラスで），あとは組み合わせたいfeatureの組み合わせ（モデルの文法で生成可能な文）を選ぶだけで，プログラムを自動的に再合成することができる．

feature間の相互作用がすべて派生モジュールとして登場するので，featureの数 n に対して，組み合わせ数である2のn乗の派生モジュールが生じてしまうが，実際には相互作用というのはほとんどないので，実際には 3*n 個くらいのモジュール数に収まるようだ，とケーススタディに基づいて述べられている．

この論文の偉いところは，feature間の相互作用を必ず考えろと定式化段階で言ってるところかもしれない．また，featureのモデルを作るのが，必須の機能と付加的な機能を列挙して，その間の依存関係を定義するだけなので，開発者にとっての負荷もそれほど高くなさそうなところもいいかもしれない（コードをそのモデルに基づいて分割するのはけっこうなコストだとは思うけど）．

_ [VolumeDeskbar][お知らせ] VolumeDeskbar 1.0.9 リリース ▲

タスクバーを縦方向にしても，ツールバーは水平方向で表示したい人向けのオプションと，ただの左クリックだけでは音量を変更しないオプションが増えました．

現在の機能で既に満足されている場合，あまりアップデートする意味はないかもしれません．

さすがに水平方向表示は，ちょっと無理していて，横幅は可変ではありません．「ツールバーの最小幅」オプションで設定された値をそのまま水平方向の幅として採用しています．

VARIABLEHEIGHTを使えば良いと思われるかもしれませんが，描画時，透過色がうまく使えず，音量バーの外側の領域が灰色（通常のツールバーの背景色）で染まってしまうのでやめました．

操作体系まわりの改造は，まだかなり悩んでいますので，今回はとりあえずオプション１個だけの対応にとどめてあります．アイディアをお持ちの方は，ぜひお聞かせください．

_ [近況] セーターをまだ着たり着なかったり ▲

この学部では，必要なソフト一式（マイクロソフトのOfficeや開発環境，SQLサーバとかAdobe AcrobatとかSSHクライアントとか）が用意されたサーバにリモートデスクトップで接続して使うということができるようで，けっこう面白い．使う側としてはインストールの手間がないし，管理側もメディア類を貸し出したりとかの管理をしなくていいので楽なのかもしれない．また，人の出入りが多いせいか，ドキュメント類とサポートデスクがちゃんと用意されている．

研究室の特定の部屋に入るための非接触型の鍵（fob）をなくして$20のデポジットを失ったので，少し反省して大学の本屋でちゃんとしたキーホルダー（key chain）を$10で購入してきた．UBCと大学名が入ってるだけで値段がけっこう上がるみたいで，コーヒー用マグカップなんかはUBCロゴ入りだと，$20したりする（スーパーで，同じタイプの「Vancouver」マークのものを$7で見つけた）．さすが記念品．

_ [hyCalendar] 今後の改造プラン ▲

メールで質問を受けて気づいたのですが，今まで「隔週予定」はあっても「５日ごとの予定」とかは書けなかったんですね．30日ごとにチャージしなおす必要があるプリペイドSIMを買ってみたところなので，ちょっと対応してみようかと思います．

ただし，現在は単体テストの導入に向けてかなり大規模な改修を加えている真っ最中です．本業の都合も強く影響しているので，次のリリースはまだ少し（かなり？）先になる予定です．

_ [論文] 良いテスト集合の選択基準の提案 ▲

Benoit Baudry and Franck Fleurey, Yves Le Traon: Improving Test Suites for Efficient Fault Localization.

Proceedings of ICSE 2006, pp.82-91, Shanghai, China, May 2006.

各ステートメントに対して「成功／失敗したテストケースの数」をカウント・比較することで「疑わしさ」を計算し，調査すべき対象のステートメントを推薦することができる．しかし，下手にテストを用意すると，ほとんどの文が同じ「疑わしさ」を持ってしまって役に立たないため，疑わしい文とそうでない文をうまく区別できるような良いテスト集合を作ろう，という論文．

論文では，テストケースの最適化の基準の提案と，それを用いることで「バグを発見するまでに調べなければならなかったステートメントの数」がどのくらい小さくなったかを実験している．

この論文では，テストケースの良さの基準を「Dynamic Basic Block（DBB）」と名づけている．DBBは，あるテスト集合に対して，まったく同じテストケースによってカバーされるような文の集合のことを指す．

たとえば，文 p, q, r, s に対してテスト３つのカバレッジが t1 = (p, q, r, s)，t2 = (p, q, r) ，t3 = (r, s) だったとすると，(t1, t2) によってカバーされる (p, q)，(t1, t2, t3) によってカバーされる(r), (t1, t3) によってカバーされる(s) という３つの Dynamic Basic Block が得られる．(p, q) の片方だけを実行するようなテストケースが作れなければ，これらは区分できないので，同じブロックに属し，「疑わしさ」度合いが常に同じ値になる．

Dynamic Basic Block の数が大きい（１つの集合が少数の文しか含まない）テスト集合というのは，テストごとに違う文の集合を実行することになるので，各文ごとのテストの成功・失敗数をカウントする方法による調査が容易なテスト集合であると考えられる．

この論文では，テストケースを遺伝的アルゴリズムで選ぶ・生成する方法によってテスト集合を洗練する実験を行っている．その評価基準として Dynamic Basic Block を使っており，従来手法より，調べるべきステートメント数を減らせるような少数のテストケースを選択することに成功している．

「良いテスト集合」を得るまでは，カバレッジ計算のためにひたすらテスト実行する必要はあるのが個人的には気になるけれど……，そこは人間の仕事ではないからOKという立場でもいいのかもしれない．

_ [ツール] bddbddbの使い方 ▲

Java コードを joeq/bddbddb で解析したいーという人向けに，how to use bddbddb for java software analysisというメモ書きを作ってみました．日本語・英語両方あります．

急いで書いたんで間違いがなければいいですが．何か発見されたら，ご連絡ください．