netail.net

_ [論文] アスペクトを使ってアーキテクチャのプロトタイピング ▲

Ingolf H. Krueger, Reena Mathew, Michael Meisinger: Efficient Exploration of Service-Oriented Architectures using Aspects.

Proceedings of ICSE 2006, pp.62-71.

あまり詳しくは読みきってないけど，アイディアが面白かった論文．

目的は複数のアーキテクチャ候補の比較評価．シーケンス図やロールモデル，コンポーネントのマッピングを記述して，それらに基づいてアスペクト（AspectJ ソース）を生成し，プログラムとして実行することで性能の試算などを行おうというもの．

アーキテクチャごとに，コンポーネントがどう接続されるか，どう相互作用するかという部分をシーケンス図やロールモデルで記述する． 登場する個々のエンティティは，比較的単純にクラスとしてマッピングすることができる（と思う）．

シーケンス図に書かれたメッセージ列は，「C1.A の実行が終わったあとに C2.B を実行する」というように解釈すれば，機械的にafter(): execution(C1.A) { C2.B; } のようなアドバイスに変換できる．

また，ロールドメインモデルで，「Manager は Broadcaster にアクセスする必要がある」と書いてあったらインタータイプ宣言を使って Manager に Broadcast 型の変数と setter/getter を作成することができる．

クラスとアスペクトを一通り生成したら，あとは weaver に任せてコンパイルを通し，実行して評価するだけ．従来だと，シーケンス図に登場する各クラスに相互のメソッド呼び出し用のコードを適切な順序に並べて埋め込んでいくとかいった手間のかかっていた部分が，ほとんど weaver 任せになっている．

生成されたコードはえらいことになる気がするけれど，保守するわけではないので問題なし．

アスペクトだけでコードを書くと「アスペクトが全部の処理を接続して，クラスはデータ構造を宣言するだけになる」というのは想像したことはあったけれど，そういうコードを生成してプロトタイピング的に使ってしまおう，という考え方にはすごく感心してしまった．

_ [Java] Extensible Java Profiler を試してみた ▲

JDK 1.4 で動くプロファイラがほしくてExtensible Java Profilerを試してみた． 別に何でも良かったのだけど，＠ITの記事 で紹介されていたプロファイラの中で，最新版が一番新しかったから選んでみた．（1.5用ならこんなのとかがある）

lib/tracer.dll にパスを通して -Xruntracer で実行すると，スレッドごととおぼしき *.ejp ファイルが生成されるので，それを presenter.bat で起動するツールに読ませる．出力結果はメソッド呼び出しの履歴（コールツリー）に時間情報が付加されているだけのシンプルなUIなので，使う段階で迷うことは特になし．

Extensible というのは，どうやら色々なフィルタを噛ませて閲覧できるという点らしい．メソッドごとに時間積算するぐらいで十分だけど……．

このツールは，どうもログファイルの肥大化が目立つ気がする．積極的にライブラリなどを排除しておかないと，すぐ数百MB，下手するとGB単位のファイルになってしまう．「後からプロファイル結果を加工する」という考え方をしてるので，JVM からデータを取っている段階でデータ量を減らせないというのが不利に働いている気がする．適用対象のプログラムがやたらと多数のオブジェクトを使ってたせいかもしれないけれど．

大規模な入力に対しては，このツールだと太刀打ちできなかったので， System.getCurrentMillis あたりを使っての簡易時間計測で済ませることにした．

_ [OUCC] ouccのサーバこけの影響（関係者向け情報） ▲

日本時間で11月6日夜ぐらいからディスクトラブル起こしてるようです．home のディスク以外は特に問題ないのでメールとかは読めたりします．メーリングリストは配送されないみたいですが．

MAngband サーバは停止後，データ回収に成功しています．復帰次第，再開する予定です．

(10日追記) POP3 の接続は通るものの，メールは配送されてないようです．エラーメールも帰ってこないので，どこかに引っかかっているか，もしかして全部ロストしている？

(29日追記) 部員専用wikiのミラーを勝手に設置しました．サイドバーの下のほうにリンクがあります．ユーザ名，パスワードは元サイトと同じです．

_ [VolumeDeskbar] Vista 対応はしばらく見送り ▲

Vista ではマルチメディア系の API の構造がいくらか変わってるようです．mixerOpen などの従来の API も存続していますが，今までだとオーディオデバイス名などが見えたものが取れなくなってます（そのかわりアプリケーションごとの音量が制御可能です）．

で，MSDN ライブラリによれば，それより抽象度の低い API としてCore Audio APIs in Windows Vistaというのが，mixerOpen などの下層に入り込んでいるようです．

この中に入っている IMMDevice オブジェクトを取得して Activate メソッドから IAudioEndpointVolume あたりを取得すればマスターボリュームが取れそう……と当たりは付けてます．正しいかどうかは分かりませんが．

実験コードを書くための環境を整えるところからまず大変なので，しばらくは対応については見送ります．少なくとも Vista がインストールされた開発環境を手に入れる（どんなに早くとも来年の４月以降）までは．

_ [Java] Java への GPL 適用 ▲

J2SE が丸ごと GPL v2 になると，その上で動くアプリケーションはどうなるんだろう，と思って調べていたら，ライブラリに関しては「classpath exception」という例外項目がくっついていた．

FAQの解説とライセンスの記述によると，ライブラリを改変しない限りは任意のライセンスのコードとリンクして使って良いよ，という条項らしい．

これのおかげで，既存のアプリケーション側は特にライセンス変更せずとも新しい GPL v2 版の J2SE の実装を利用できる．これはけっこう親切なライセンス規定だといえそう．

アスペクトを使って JDK 標準のバイナリ改変をやりたかった人には，オープンになって「禁止」じゃなくなった点が良いのかも．

_ [論文] AOP でのミドルウェア構築についての講演 ▲

Charles Zhang という Aspect-Oriented Middleware をやってる人が喋りに来たのを聞いてきた．

ミドルウェアが含んでいる feature 間の相互作用部分をアスペクトに追い出して保守性を向上するという話で，そのためにマイニング環境 Prism と，変更後のコードレベル検証ツール ARV を構築し，リファクタリングを行ったらしい．

調査した結果によると，ミドルウェアに含まれていた６個のfeatureのうち50％ぐらいのモジュールは１つのfeature としか関連しないが，10％ちょっとのモジュールは３つ以上のfeatureと相互作用していて，コードの変更などを難しくしていた，と言っていた．一般化できる結果ではないと思うけれど，少数のモジュールが全体の保守性を悪化させているみたい．

そういうリファクタリングの結果，ミドルウェアの様々な feature がアスペクトとして分離される．それらを使って，アプリケーションのコンパイル時にどの feature が使われているかを調べ，必要な feature だけを取り込んだミドルウェアの configuration を生成する，なんてことも研究しているらしい．

feature が他のどの feature に依存するか，また同時に使用できない feature の存在はきちんと記述して与えないといけない．feature を実装する側がそれなりに（高価かどうかは良く分からない）コストを支払えば，使う側はかなり楽をできそうな仕組みに聞こえた．feature-oriented なアスペクトの使い方としてはけっこう面白いと思う．

_ [読書][AspectJ] ユースケースがアスペクトになる ▲

Aspect-Oriented Software Development with Use Cases という本が ACM の Online Books プログラムの無料で読める範囲に入ってたので読んでみたら，そういう記述があった．

ユースケースのシナリオを書いていくと，シナリオのうち特別なケースでのみ実行される alternate flow や，定義済みのシナリオを拡張する extends 関係が登場してくるが，これらは複数のクラスに影響を与えるので，クラスを拡張するアスペクトとして表現するほうが良い，と解説していた．（アスペクトが使えることを強く意識したシナリオの書き方になっているような気もする．）

ユースケースは，それに対応する「ユースケーススライス」というモジュールとして実現できる．ユースケース固有のクラスはそのままクラスとしておけるが，他のクラスを拡張する部分はアスペクトとしてインタータイプ宣言ないしポイントカット＋アドバイス表現を用いて記述する．これによって，特定のユースケースに関するコードを他のユースケース用のコードから独立したままに保つ．

異なるユースケースに所属するコードを分離したままで管理するために，ユースケース固有のコードを，それぞれ独立した（ユースケース名を付けた）ディレクトリに配置してしまおう，とも言及されていた．Eclipse では，コンパイル対象のソースコードが入ったディレクトリを指定することができるが，そこで各ユースケースのディレクトリを列挙すれば良いらしい．

非機能的要求も，できるだけ infrastructure use case としてシステム側の振る舞いを記述し，普通のユースケース（application use case）との関係を整理しておくらしい．そうすることで，システムのサービスを担うアスペクトなんかも設計時にきちんと扱うことができる．

別々に記述したものはそのまま混ぜずに置いておくという一貫した方針になっているので，けっこう読みやすい本だと思う．そのかわり，ユースケースとコードの中間（分析モデルとか）については扱いが小さい気がした．

(追記) この本，日本語訳が出てますね．まったく気づいてませんでした．

_ [論文] プログラムの条件分岐を無理やり変更してデバッグ ▲

Xiangyu Zhang, Neelam Gupta, Rajiv Gupta: Locating Faults Through Automated Predicate Switching.

ICSE 2006, pp.272-281.

プログラム実行中のある時点でデータに誤りが発生した場合，それはそこまでの実行経路に問題がある．直前ないし近い位置の分岐で別方向に進んでいたらプログラムはうまく動いていたかもしれない．だから，そういう条件分岐（"critical predicate"）がもしあるのなら自動的に見つけよう，という論文です．

critical predicate が見つかれば，入力変数から critical predicate を経由して誤った変数値に到達するまでの経路の chopping を計算することで，バグの位置を普通のスライシングよりも絞れるだろうという見込みがあったりします．

方法自体はわりと単純で，動的解析でどの条件分岐を何回どちらに進んだかを記録しておき，コード書き換え技術を使って「このif文を20回目に通過するときは必ずTRUEだとみなす」というような細工を施してプログラムを再実行するというものです．どの条件分岐を変更するか，という選び方を工夫してます．

実験結果では，それなりに critical predicate を発見できていて（発見できないケースもあり），その結果を使って計算したスライスのサイズも小さくなっている，という評価を行っています．「デバッグの手間」というのは計測しにくいので，普通に計算したスライスのサイズと，critical predicate が分かっている場合のスライスのサイズを比較することで，開発者が調査するであろうコード量を比べています．

この手法は，ひたすらプログラムを再実行するという力技で，面白いやり方だなーと思います．特定の条件分岐を中身を気にせず強制変更するので，無造作にデータ構造を壊したりしないのか，という点は多少気になります．

_ PSP ぽいことをはじめてみる ▲

PSPといっても，ゲーム機じゃなくて Personal Software Process のほうです．

コード書きや，論文の執筆とか他人の原稿のチェックとかにどのくらい時間を使っているのか，少し見積もりができるようになってみようと思って，作業時間を記録してみることにしました．

時間記録・管理の支援ツールとかもあってもよさそうなんですが，これといったものが見つからなかったので，計測用タイマーは普通の時計で，記録は Excel にしました．

「どのくらい作業ができたか」を記録する実績値は，論文の場合，とりあえず２段組でのページ数にしてみます．

_ ゲーム検定の結果 ▲

ゲーム検定 (日経エンタテインメント)なんてのを教えられたので，試してみました．

けっこう難しかったです．ハードウェアに関する知識が多いのは，ベーマガがマイナーなものまで幅広くカバーしていた影響です．たぶん．

（得点表の横の xx/yy という実際のスコアは，自動出力ではなく，後から手で追加したものです．）

あなたの総合得点は64点　　全国平均　54点
 
全国順位（11月24日 4時現在）
9560位（57197人中）
 
−−ジャンル別得点表−−−−−−−−−−−−
　　　　　　　　　　　　０＿＿＿＿＿＿＿＿＿50＿＿＿＿＿＿＿＿＿＿100％
ハードウェア　　　　　　　■■■■■■■■■■■■■■■■　13/16
ゲームシステム＆テクニック■■■■■■■■■■■　　　　　　16/28
キャラクター　　　　　　　■■■■■■■■■■■■■　　　　10/15
ビジネス　　　　　　　　　■■■■■■■■■■■■　　　　　16/26
雑学　　　　　　　　　　　■■■■■■■■■■■■　　　　　 9/15
−−−−−−−−−−−−−−−−−−−−−−−−−−
 
あなたは「ゲーム大臣」
これだけの知識があれば、たいていのゲーム好きの人間とは
楽しく会話ができるはず。しかし、この先、もっと深く広い
知識を得ることで、世界はさらに広がるだろう。
 
貴方がもっとも詳しいゲームのジャンル：
　　　ハードウェア
貴方がもっとも詳しいゲームの年代：
　　　90年代前半を中心としたゲーム発展期

_ [近況] 雪が降りました． ▲

冬の滞在先は温暖な地域にしておけば良かった，と少し思わなくはないです．

しかし，研究の参考文献としてリストアップした良さげな論文は全部UBCの関係者（既に他所へ行った人含む）のものだったので，ここを選んで正解ではあったと思います．

_ [hyCalendar] 1.5βから1.5リリースの差分（予定） ▲

ご意見をくださった皆様，ありがとうございました．

日付カウントダウン機能について，以下の３点を実装中です．来週ないし再来週には出せるんではないかと思います．

(1)「誕生日まであと10日」のように，日付／周期予定に対して別名を指定するオプションを追加します．

(2)指定した日を過ぎたら自動で翌年の同じ日までの日数を出すオプションを追加します．

(3)編集方法が少し変わります．現在は項目を設定して「追加」ボタンを押す形ですが，これからは「新規」ボタンを押すとアイテム追加，項目の情報を操作すると即座に反映（保存などのボタンなし）となります．

_ [Java] String.intern の簡易版を作ってみた ▲

開発中の某システムで，同じ文字列がたくさん含まれたファイルをストリームから読み出すとき，文字列が各行ごとに個別にインスタンスが確保されてしまうので，HashMap を使って単一インスタンスに置換するようにしてみた．

実装は次の通り．すごく適当．

private static Map stringTable = new HashMap();
public static String toSingletonString(String s) {
  if (stringTable.containsKey(s)) {
    return (String)stringTable.get(s);
  } else {
    stringTable.put(s, s);
    return s;
  }
}

しかし，こんなものでも，ストリームから読み込んでいる文字列のインスタンス数が少なく見積もって50万〜，互いに異なる文字列が数万と推定される環境で，フットプリントが1.3GB→1.0GBと減少．手間のわりには効果があって満足です．

_ [近況] 停電してました ▲

積雪のため休校，かつ未明から午後３時頃まで大学ほぼ全体で停電してました．部屋の暖房が止まったのは元々の断熱性の高さで何とかなってましたが，CSのサーバ群などは室温上昇のため，告知用のwebサーバと外部への経路を残して停止してたようです．

今回は水・食料を買い置きしておくことの重要性をちょっと認識しました（そこまで考えずに買い置きしてあったんですが）．

_ Python Challenge の Level 19 で ▲

どうしても言葉が聞き取れなくて詰まっていたんですが，同じものがたまたまflashで使われていたことから解けました．

この Challenge のために Python を少しかじって以来，結局使ってないです……．20以降はまたそのうちやってみることにします．

_ [論文] ArgoUML の解析が流行中？ ▲

今年５月のMSR 2006 の予稿集をいくらか調べていたら，多くの論文が ArgoUML を解析対象にしているようです．みんなで同じものを相手にすれば比較しやすいので，ありがたいことですが……．

さすがに１つだけだと validity の都合もあるので，次の文献では，ArgoUML と Columbia，jEditの３つを解析対象にしてました．Columbia も別の論文で名前を見たことがあるので，やはり解析実験の対象として手ごろなようです．

Sunghun Kim, Kai Pan, E. James Whitehead, Jr.: Micro Pattern Evolution. MSR 2006, pp.40-46.

この論文は，クラスがどのマイクロパターン（提案した人のサイトはこちら）に該当するかをバージョンごとにチェックしています．コードが変更された結果，クラスのパターンがどう変化したか（あるいはそのパターンのままか）という情報と，バグの混入しやすさの関連を調べてます．OOPSLA論文のパターンカタログの定義には入ってない Limited Self というのが１つ無造作に加わってるのは謎です．

変更するコードによって，（この人が定義している言葉での）バグの混入しやすさには偏りがあるという点は，けっこう面白いと思います．