netail.net

_ [近況] ワークショップのプログラム ▲

AOASIA2 プログラムが出てるようです．基調講演＋発表12件＋Panelという構成なようです．おかげさまで，10分プレゼン時間もらってます．

今回，プレゼンは人にお任せモードなので，その期間のうちに休憩時間に人に見せられるくらいのデモが準備できないかなぁと考えてます．しかし，そろそろ院試後の卒論に向けての方針とか，M1の人のネタのことも少しは考えておかないといけないので，時間がどれだけ開発に割けるか微妙なところ．

_ [論文] デザインパターンカタログの品質メトリクス ▲

Cutumisu, M., Onuczko, C., Szafron, D., Schaeffer, J., McNaughton, M., Roy, T., Siegel, J. and CarbonaroEvaluating M.: Pattern Catalogs - The Computer Games Experience. Proceedings of ICSE 2006, pp.132-141, Shanghai, China, May 2006.

ゲーム開発を題材にしているが，定型的なコードの生成（もしくは手作業での記述）に使うデザインパターンを一式用意したとき，それがどのくらい「良い」カタログかを計測するメトリクスを提案している．

メトリクスは，カタログ単体ではなく，カタログとアプリケーションの組に対して計測される．カタログに掲載しているパターンのうち何％がそのアプリケーションで使われたかを表現する usage（低い＝有用なパターンを見つけにくい），アプリケーション内で使っているパターンのうち何％をカタログが網羅しているかの coverage，１パターンあたり何回くらい使われてるかの utility，パターンを実際の場面に適用するのに必要なステップ数の少なさをあらわす precision の４つ．

「そのアプリケーションに対するカタログの適切さ」なので，値が良くなるようなデザインパターンのサブセットをカタログから取り出しておき，同じドメインの別アプリケーションの開発に使う，とかいう形になるのだろうか．

ふと思ったのだけど，コーディングパターンとかをソースコードから自動抽出するような手法の出力結果に対して，この４つのメトリクスの値を良くするようなフィルタリングを行えば，出力の有用性が上がったりするかもしれない．抽出されたパターンのインスタンスがどこにあるかを数えたり，どのくらい元パターンから変形してるかを判定する方法のは大変だろうけども．

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

「１回クリックだけでは音量を変更しない」オプションが，別ウィンドウからフォーカス移動してきたときに働いてくれない問題を修正しました．それから，縦方向にツールバーを表示しているときのポップアップ文字列の表示位置を，ツールバーと重ならないように移動しました．

音量が変わってしまう原因は，ウィンドウのフォーカス移動時など特定のマウス操作において，マウスボタン押下のMouseDownメッセージの直後になぜかカーソル移動のMouseMoveメッセージが発生するためでした．それに対して，座標が変化していないMouseMoveメッセージを無視することで対応しています．

_ [近況] ワークショップの論文，最終版投稿 ▲

なんとか投稿終了．投稿したバージョンの原稿から大幅に修正したので，疲れた．

ページ数が厳しいときは，ちゃんと説明すべき重要な部分がどこなのかという判断はやっぱり大事だなーと痛感．説明不足の部分を補うために説明用の図を入れてみたり，そのかわり重要でない部分の長々とした説明をばっさり削ったりと色々やってたら，結局，図表が全部新しく置き換わってしまった．書いた本人ですら，ぱっと見では別論文のような印象を持ってしまう．

_ [論文] アスペクトの相互作用の例 ▲

concern interaction にどんなのがあるの？という質問に対して，aosd-discuss メーリングリストで挙げられていたStudy on interaction issuesというAOSD-Europeのドキュメントを見てみた．

interaction は conflict（競合），dependency（依存），reinforcement（強化），mutex（排他）に分類できる，としていて，case study でどんなものが実際に見つかったかを紹介している．で，カタログとして，述語論理ぽい状態の記述で関係を説明している．

conflict は２つのアスペクトを同時に使うとこけるパターン，dependency は１つのアスペクトが他の特定のアスペクトの存在を仮定しているパターン．mutex は２つのアスペクトが同時には使えないパターン．reinforcement は，「あるアスペクトが存在すると，機能を強化できる」というものらしい．たとえば計算結果をキャッシュするアスペクトは，データ暗号化アスペクトの暗号処理の結果をキャッシュするので処理速度を向上できるとか，セッションの状態を保存するアスペクトがあればネットワーク監視アスペクトはネットワーク切断・接続に合わせたセッションの自動再開をすべきだとか．

reinforcement 以外の３つは述語論理ぽく関係をうまく記述できているように見えるのだけど，reinforcement だけは「別のアスペクトの存在で放っておいても機能が強化される」パターンと「別のアスペクトを使って新たなサービスを提供できる」パターンが混ざっているような感じがして，何か曖昧な印象がある．なんか誤解してるのかもしれないが．

とりあえず，「すべてのアスペクトが直交してるわけではない」とか，「aspect interactionのすべてが害のあるものではない」とか書きたい場合には，具体例を色々載せてることもあって，引用するのに手ごろかもしれない．

_ [論文] アーキテクチャ情報に基づいてコールグラフをレイアウトする ▲

J. Bohnet, J. Doellner: Analyzing Feature Implementation by Visual Exploration of Architecturally-Embedded Call-Graphs. Proceedingds of the 4th International Workshop on Dynamic Analysis (WODA2006), pp.41-48, Shanghai, China, May 2006.

ものものしいタイトルに惹かれて読んでみた……が，やってることはコールグラフの可視化だけ．騙された感が強い．

コールグラフを可視化するときに，システム-サブシステム-コンポーネント-メソッドの階層を意識してレイアウトしよう，という論文．アーキテクチャ記述としてどのクラスがどのサブシステムの一部かというのを用意する必要があるのだけど，単にディレクトリをサブシステムにマップしてるだけみたい．

コールグラフは３次元画像として可視化される．サブシステムを１枚の平面で表現して，コンポーネントの箱を載せて，その箱の上にさらにサブコンポーネントの箱を載せていくことで階層構造を表現する．平面上に配置するコンポーネント間の距離は，メソッド呼び出し関係を引力とみなし，コンポーネント同士が重なるのを防ぐための斥力と足しこんで位置を探すらしい．あとは，サブシステムが複数になったら平面の枚数を増やして３次元的に配置する．呼び出し関係はコンポーネントからコンポーネントへの３次元的な軌跡として表現される．

３次元空間を全部使ってノードを配置すると，どこに何があるやら分かりにくくなってしまいがちだが，平面＋その上での階層構造という2.5次元の表現ならドローバックが少ない，と主張している．球面上へのマッピングなどよりは多少直観的かもしれない．

アーキテクチャ情報を使う意味は，メソッド間の呼び出しを，コンポーネント間，サブシステム間の呼び出しというように分類して明示的に可視化できることにあるのだろう，と思う．それがどのくらい効果があるかは分からないけど，ないよりはあったほうが有利？

使いやすさその他の評価実験はなし．トレーサビリティ情報を使っての可視化とかいうのもなし．タイトル的には色々期待してしまったので少し残念．

_ [近況] 研究室バーベキュー ▲

新しく入ってきた人なんかと顔合わせ．

今まで顔合わせる機会のなかった Kris de Volder と，今後の研究ネタ関連の雑談できて，かなり勉強になりました．内容については書けませんが……．

英語で喋っていると，一般的話題の雑談は10分ちょっとでも疲れるのに，研究やプログラミング関連の雑談は比較的楽にこなせていることに気付きました．頭の中にある語彙か何かが偏っているせいかもしれません．