netail.net

_ UBCのInvitaiton Letter まわりの手続き ▲

あちらでもRequest for Invitation Letter みたいなのを大学に出す必要があるらしくて，向こうの秘書の人から色々情報を教えてほしいというメールが来ていた．

５日くらい前に受信してたのに，spam と誤認識されてしまって気づいてなかったので，急いで返事を出したついでに，フォルダ振り分けルールを少し改変して，あちらの大学からのメールならとりあえず無条件で受け入れるよう設定．

_ [hyCalendar] 1.3.4 での修正内容 ▲

hyCalendar 1.3.4 バイナリがいちおう出来上がった．修正内容は以下の２点．

• 日付の右クリックメニュー，テキスト編集エリアの右クリックメニューに「切り取り・コピー・貼り付け」を追加．
• ツールバーの位置を入れ替えたとき，ツールバーが正しく表示・非表示を切り替えられない問題を修正．

またドキュメントの修正が必要なので，とりあえずバイナリだけ，リリースまで置いときます．

_ [hyCalendar][お知らせ] hyCalendar 1.3.4 リリース ▲

ドキュメントの更新も無事終わったので，公開しました．ダウンロードはこちらから．

また何かご意見／ご要望ありましたら，tdiaryのツッコミないし掲示板にて，コメントをお願いいたします．

_ [VolumeDeskbar] Bluetooth ヘッドセットと「既定のデバイス」の変化 ▲

Skypeとか使うために Plantronics M3000 + Planex BT-01UDE を買ってインストールしてみた．音声出力先を Bluetooth デバイスに指定しないと内蔵スピーカから音が出てしまうので，切り替えはどうするのだろうと思っていたら，接続が確立されると同時に「Bluetooth Wave」というデバイスが出現し，「既定のデバイス」をそれに切り替えるという仕組みが付いていた．

ところが，VolumeDeskbar 側は，この突然のデバイス出現と切り替えに追随できないので，これらの Bluetooth デバイスに対する音量はうまく動作しない．

定期的にポーリングして変更を検知するのも効率が悪いということであちこち調べてみて，オーディオの「既定のデバイス」は，レジストリのHKEY_CURRENT_USER\Software\Microsoft\Multimedia\Sound Mapperという場所に書き込まれていることがようやく判明．

ということは，レジストリ変更を通知するRegNotifyChangeKeyValue あたりを使えば，ちゃんと変更に追随できるようになるかも．

_ [VolumeDeskbar] レジストリ変更への対応 ▲

確定申告やら事務手続きを色々片付けつつ，RegNotifyChangeKeyValue を使って「既定のデバイス」の変更を監視する処理を実験してみたら，実験コードはちゃんと動いた．

というわけで，次は，実際に Volume Deskbar に組み込んでみることにする．Explorer のプロセス内部で勝手に監視用スレッドを作るので，ちょっと気持ち悪い気もするけど……．

_ 全国大会 ▲

Webサービスとアスペクト指向のセッションでは，Bugdelは企業で使われてるんですよとAPSECのときに聞いてた話（使ってたほうの人々の発表）とか，ビジュアルなコンポーネント指向プログラムの記述環境を用意してエンドユーザ側でも開発ができるようにしようという話とか．（たまたま？）企業の人が多かったおかげか，実システムの開発に即した話が多かったので，収穫はそれなりにあったと思う．メモは，あとでまとめることにする．

_ SPLAT 2006 の参加 ▲

paper１本あたり２人しか参加できないという制限つきの開催（本数が多いせいか，ポスター＆デモ主体）らしいから大変なんかな，と思っていたら，Organizer の人々から，参加してもいいよ，という連絡を受け取った．その理由は，実はプログラム委員の人々なんかは，論文出してなくても invite 対象になってるから，とか何とか．

_ [VolumeDeskbar] デバイス変更への自動追随はあきらめ． ▲

色々試してみたものの，RegNotifyChangeKeyValueでデバイス変更をトラップした直後にミキサーの状態を取得しても，直後にはまだミキサーAPI側で新しい状態が取れない（１秒程度待つ必要がある）ので，いまいちレスポンスが悪く，切り替わったタイミングについてもうまくユーザに表示できないので，あきらめることにした．かわりに「最新の状態に更新」メニューとかを付けて実験中．デバイスが変わったら，そのメニューを選ぶと，新しいデバイスの音量を表示するようになるというもの．ちょっと不親切な気もするけど．

Norton Internet Security とかの「更新しました」メッセージポップアップは偉大な通知方法なのかもしれない，とちょっと思ったものの，たかが音量のためにそこまで実装するのも面倒だったりする．

_ 書類の送付とか ▲

UBCの寮に送る書類はEMSで送付してみた．20枚ほどの書類＋クリアファイルで，1200円．

_ [読書] プレファクタリング ▲

Ken Pugh 著「プレファクタリング -リファクタリング軽減のための新設計-」（オライリー・ジャパン）．

リファクタリングとかの必要性が少しは減るように（なるべく変更量が小さく保守しやすいコードになるように），コーディング前にリファクタリングをする，というのが紹介文には書いてあった．

ざっと中身を眺めた限りでは，分析やクラス設計，コーディングまで，今まで色々言われてきたプラクティスを整理していて，保守しやすいコードを作ることを考えよう，ということを，１つのシステム開発の例を題材に解説している．

「関心事の分離」（「横断的関心事の分離」ではなく）に関する記述なんかが気になったので購入してみた．

_ [論文] アスペクトの記述支援 ▲

斉藤 瞳，櫻井 孝平，山崎 雄大，古宮 誠一: 横断的関心事の特定に基づくアスペクトモジュールの記述支援．

第68回情報処理学会全国大会，4F-6，2006年3月．

アスペクトの生成支援は，元のコードと，追加したい処理を書き加えたコードの差分から，アスペクトの定義を生成しようというものらしい．

α-ωマーキングをしたところを機械的にリファクタリングする Binkley らのアプローチ（ICSM2005）に似ている．

after call と after execution のように，同じことを実現する複数の選択肢がある場合をどうやって決めていくかといった，設計をどう支援できるかにもよるかも．

_ [論文] Bugdelを使ったAOP的デバッグ ▲

組み込みJava向け開発環境へのアスペクト指向ツールの適用

第68回情報処理学会全国大会，4F-7，2006年3月．

Bugdel を使って，本稼動に近い環境上でデバッグ用コード（トレースとか）付きのシステムを走らせてみた，という話．

組み込み環境ではデバッグ用VMだとJITが使えないとか，厳しい制限があるので，そのあたりをデバッグ用アスペクトとして書いてしまう，という発想になったらしい．

デバッグ用コードの分離・再利用がいちおうできるというのも利点の１つ．

行ポイントカットは，デバッグ用だからOKといえばOKなのだけど，CVSとかでチェックアウトしてきて，差分でコードがずれたとかいうことになると厄介．

コメント行として何かを書き込んでおいて，ツールを通してポイントカット定義を生成するなんて方法を使えば，的確に固定のデバッグ用ポイントを埋め込めるんじゃないかな？と思ったりもする．

_ [読書] プレファクタリング（前半）を読んでみた ▲

とりあえず１６章中，７章を読んでみた．

どのクラスにメソッドを配置するか，継承と委譲のどちらを使うか，命名をどうするかといった設計段階での色々な決定事項についての議論が紹介されている．契約による設計とか，XPとか，テスト駆動型開発とか，色々な人が言ってきたことをトピック別に整理している印象．

全部あくまで指針になっているのは，設計の良し悪しは明らかに良いもの，悪いものを除くと判断が難しいこと（関心事を分離しようとすると個々のクラスは単純になってもクラス数は増える），必ずしもすべての状況に適用できるとは限らないことなどに起因するらしい．

以下は，今まであまり聞いたことがなかった・考えてなかったことのメモ:

ユースケースの処理手順をさらに詳細化すると，クラスに対する一連のメソッド呼び出し（ワークケース）が出てくる．ワークケースが１つもないようなクラスは目的の無いクラスではないかと考えられる．また，理想的には各メソッドに個別にテストを実施するが，個別のメソッドがあまり意味を持たない場合やそこまで時間が取れない場合はワークケース単位でのテストにする．

一括したものを分割するより，分割したものを一括するほうが容易．AとBと書いてあれば，BをAに置換することができるが，逆は簡単にはいかない．異なる概念かもしれないものは，とりあえず分割しておいて，あとで同じものだと分かったらまとめてしまう．

_ 学振の資格切り替え ▲

DC2→PD切り替えのため，とりあえず電話連絡してね，と書いてあったので，電話してみた．

様式５−１（資格変更願）については，DC2の人として切り替えをお願いするので，右上側にはDC2で書くのだけど，５−２（受入承諾書）についてはPDとしての１年間の受入承諾書となるのでPDで出して，とかいうことを言われた．微妙に複雑なのね……．

_ [読書] プレファクタリング（後半） ▲

システム開発中に，設計上の色々な選択肢からどれを選ぶのが（その状況では）妥当か，というのを例ベースで説明している．指針が守れない場合も紹介されており，わりと現実的な立場で書かれてるので読みやすいのかも？

これ読んで，hyCalendarとかの再設計をやりたくなってしまった．

_ [論文] データの到達条件の解析方法 ▲

Gregor Snelting, Torsten Robschink, Jens Krinke: Efficient Path Conditions in Dependence Graphs.

To appear in ACM Transactions on Software Engineering and Methodology.

Path Condition (PC) というのは，プログラム中のある２点 x, y に対して，x で定義しているある変数が，y に影響を与えるときの条件を指す．たとえば:

a = 1;     // 1
if (x > 0) // 2
  b = a;   // 3
else       // 4
  b = 0;   // 5
c = b;     // 6

といった状態で，１行目の変数代入が６行目に影響を与えるのは３行目の文が実行されたときだけなので，PC(1,6) = (x > 0)となる．基本的には，if文やfor文での条件節をどんどんANDでつないでいった形にする．プログラムの入力変数以外（中間データ）に関しては変数を消去していって，プログラムへの入力変数がどのような条件を満たせば，その情報の流れが発生するか，ということを示す．

プログラム中の重要な変数が，他の変数から影響を受けないことを調べるには，先ほどのPCを計算して，それが充足不能であることを示せばよいことになる．これは，static program slicing で「影響を受けるかもしれない」と出てくる false positive を取り除くためにも利用できる．また，充足可能である場合は，その条件を求めれば，いつその情報流が発生するかを調べることができる．

この論文では，このPath Conditionの計算方法と，それを色々なプログラムに適用した場合の時間・空間計算量を評価している．

地点 x から y へは複数のパスがあるので，「影響を与えるとき」というのは各パスでの到達条件のORを取ればよいとか，assertionで書かれた条件も含めるとか，dominator（通過しなければならない頂点）を使って解析を前後で分割するとか，手続きに対するサマリ辺の作り方とかが説明されている．いわゆるプログラムスライシング技術がベースで，このあたりの手法自体はわりと普通．メソッドの多態性なんかも，とりうるサブクラスを調べてきて，((a instanceof A) -> PC_for_M_A ) ∧((a instanceof B)-> PC_for_M_B)のように述語をつないでいくだけで表現することができる．

こうやって計算を進めていくと， Path Condition として長々とした条件節が出てきてしまうので，定理証明系(であってるのかな？)で条件節を簡単化していく．実験結果とかを見てると，「P行目での変数xの値がaになっていて，かつQ行目でyになっていて，…」というような条件式がだらだらと並んだ形になる様子．条件式を読み解くのに知識は必要だが，それほど大変でもないというような書き方はされていた．また，セキュリティ解析では，重要情報の危険な変数への到達可能性が充足不能であることさえ示せればよいので，あまり気にしなくても良いのかもしれない，とも思う．

この手法の良いところは，関数単位で独立に処理できるように規定されていることと，PC(x,y) は x から y に情報流が発生するために少なくとも必要な条件であること（十分な条件とは限らない）．メソッド呼び出し階層が深いときなどは，途中で探索を打ち切ってしまっても，「少なくともこれだけ成り立ってたら，情報流が発生する可能性があります」と情報を出すことができる．探索を途中で打ち切ると，条件が弱くなってしまうぶん（冗長な条件を出すことはない），充足不能性とかを示そうとすると大変になる．しかし，プログラム理解などの他の場面では，コールグラフ上で近い階層だけをざっと調べて大雑把な到達条件を見る，といった使い方もできるかもしれない．

この人々，dynamic な手法（実際にどの条件式の影響を受けたかを調べる）というのも Dynamic Path Conditions in Depndence Graphs (PEPM2006) という論文で発表する様子．けっこうがんばっている．

_ AOSD１日目 ▲

無事会場の無線LANに接続．日本人の姿もちらほら．

_ AOSD２日目 ▲

SPLAT参加．個々のアスペクトの動作記述から，全部が同時に動く場合はこうなる，という記述を自動合成する手法を提案している人がいて，そこで少し長話．

Gregor Kiczales の顔をちゃんと認識できてなかったので増原先生に紹介してもらった．次に会うときにはちゃんと認識できるといいんだけど．

_ AOSD３日目（本会議１日目） ▲

オブジェクト間の関連（クラス図における association）を，Java Generics の型パラメータを使ったアスペクトで実装したら，アスペクトを好きなクラス間で関連を持たせることができて（そのためのメンバ変数を各クラスに持たせずに済み），パフォーマンスも悪くない，という話をしている人がいた．

The Relationship Aspect Libraryとして公開しているらしい．

このライブラリは，クラス C1, C2 に対して関連がただ１つしかない場合には，たぶん有効．逆に，たとえば，Student, Professor に「授業履修」という関連と「研究室所属」という別個の関連を同時に持たせようとすると，Relation＜Student, Professor＞の関連インスタンスが２つ必要になるので，AspectJ のインタータイプ宣言では，関連情報を保存するフィールドの名前が衝突してしまう気がする．あくまでAspectJのアスペクト継承で実装した場合の問題なので，コード生成ツール（XVCLとか）を使って，雛形アスペクトから名前衝突を起こさないようなアスペクト生成をすればOKだとは思うけど．

_ AOSD４日目（本会議２日目） ▲

ドイツの人で，steamloomというDynamic AspectサポートVM環境を作ってる人たちが，動的スライスをまじめに実装したツールデモをやっていた．見たかぎり，完成度はそれなりに高そう．

動的スライスを選んだ理由は，omniscient debugging という実行時情報を全部保存するアプローチで元々研究をしているためか，Dynamic Deploy ができるアスペクト指向プログラムの実行環境なので動的スライスでないと（たぶん）ちゃんとした結果が出せないためか，どちらが直接の動機なのかは不明．

あとで少し聞いてみたら，けっこう開発工数はかかっているらしい．

メモリと実行時間がたくさん必要（例題でもMB単位のメモリ，実行時間が3〜25倍必要）というのがネックなものの，まだデータ構造の最適化などはしてないから，もうちょっと良くなるかもしれないとは言っていた．

また，動くものがあるので，実際にどのようにスライスを使えば（どこを基点にするか，intersectionとかunionを使うか，など）問題解決に役立つか調べられるし，問題の解決のためにどの範囲を解析する必要があるか，とか分かればもっと軽くなるかもしれない．

ツールも公開するし論文も publish するよ，と言っていたので楽しみ．

今回のバンケットは，料理はビュッフェ式だったけど，手品ショーとか付いて豪華だった．UBCの人々とか，同じテーブルにいた合気道やってるドイツ人とかと知り合いになった．

_ AOSD５日目（本会議３日目，最終日） ▲

最終日は午前だけ．テストに関するセッションでは，単にAspectJコンパイラでクラスに変換された後のコードに対してテストコード生成ツールを適用してもうまくいかないので，生成ツールがうまく働けるようにラッパークラスを生成する，という話はけっこう面白かった．

また，アスペクトの相互作用に関するセッションでは，アトリビュートをインタータイプ宣言した場合に，宣言の有線順序によって結果が異なる可能性を検知するというわりと実用寄りな話や，音楽情報（メロディやテンポなど）の合成(weaving)によって音楽を合成するという話があった．

_ PC環境を新しくする作業を始めました ▲

単に別のPCに移行するだけですが，使うコンパイラも新しいバージョンのものになります．

これに伴って，hyCalendar や Volume Deskbar の更新は，多少，遅延すると思います．

_ AOSD まとめメモ／ポスターセッション ▲

ポイントカットを提案していたものでは，path expression pointcut と，block pointcut というのがあった．

path expression は，フィールドに格納されている参照を使って，obj.field1.field2 のようにたどれる範囲のオブジェクトを宣言できるようにしようというもの．target(p) ＆＆ path(obj -> p) のように記述することで，オブジェクト p を保有する obj なんかを変数に束縛できる．これは，DemeterJ とかで使っているtraversalの記法でもあり，強力な仕組みになる可能性はある

ただ，実現のアイディアについて聞いてみたら，ガベージコレクタなんかがオブジェクトの参照を見つけるような方法，といっていたので，かなりの力技になりそうな点が不安．成果が出てみないと何ともいえない．

一方の block pointcut は，東工大の人々による提案．エラーから回復するために，エラーを検出する特定の try ブロックを２つのポイントカット pcd-begin と pcd-end を使って block(pcd-begin, pcd-end) という形式で指定し，それに対して回復用のアドバイスをくっつけることを提案している．pcd-beginとpcd-endが同じブロック内にならないといけないという制約を付けていても，beginとendの対応が正しく取れているかどうか，コンパイル時にしっかり判定する必要があり，実装はけっこう難しそう．

そのかわり，ポイントカットの抽象度を向上させる可能性はありそう．たとえばファイル処理に関するブロックを pointcut FileProcess(): block(call(File.open), call(File.close))のような記述で記述すると，今までのようにbefore(): open と after(): close と書くかわりに，before(): FileProcess と after(): FileProcessと書いたりできる．これは，実装の詳細のメソッド名などを見せずにポイントカットだけを公開するために使えたりするかも？とちょっと期待．

_ [ツール] JUnitとFIT ▲

JUnitでは，データの値と結果のペアをひたすら assertEquals で並べるので疲れると思っていたら，そういうテストに適したFITというツールがあるらしい．

developerWorksの記事によると，どうやらHTMLテーブルを書いておくと，列名が変数名なら入力データとみなし，メソッド名ならそこに書いてある値がそのメソッドのあるべき出力値とみなして，自動的にテストしてくれるというものらしい．

あと，鷲崎先生も記事を書いていた．ぱっと見た限り，けっこう便利そうなので，次の開発から使ってみたいところ．

ダウンロードページを見てたら，現段階ではJavaやC++など色々なバージョンが既にリリースされている様子．Delphi 版はさすがに（開発しようとした人はいるようだけれど）なし．こういうのを見ると，hyCalendar とかもそろそろサポートが充実した別の言語に移行すべきかなとちょっと悩んでしまう．