netail.net

_ [VolumeDeskbar] バグをごそごそ修正 ▲

タスクバーからドッキング解除した状態のデスクバー(IDeskband)を閉じると，CloseDW メソッドの処理後にウィンドウに WM_DESTROY が飛んできてしまうようで，無造作にクラッシュしていた問題が判明．フォームを解放するときは TCustomForm.Free ではなく TCustomForm.Release を使わないといけない（Releaseは，必要なメッセージ処理が終わるまで解放を遅らせる）というのを忘れていたのが原因らしく，修正した．

ドッキング中に「タスクバーを閉じる」が選ばれたときは，親ウィンドウの破棄が起きないので，問題は起きないらしい．

それにしても，ドッキング解除時は，なぜか縦方向に伸縮するタイプのウィンドウが用意されるらしい（サイズを返す構造体に x メンバに代入した値がウィンドウ高さ，y メンバに代入した値が横幅になる）．縦横の方向の指定というのは，やり方がまったく示されていないようなので，とりあえずこのままにしておく．

_ [論文] AOPで書き直した場合のメトリクス値の変化 ▲

Tsang, S. L., Clarke, S. and Baniassad, E.: Object Metrics for Aspect Systems: Limiting Empriical Inference Based on Modularity.

Trinity College Dublin technical report.

ある traffic simulator を改造して，非同期処理とかメモリ管理とかをアスペクトとして実装しなおしたとき，AOPでの実装はOOPでの実装に比べてどう変わってるのか，というのをCKメトリクスに基づいて調べた論文．CKメトリクスはそのままでは使えないので，クラスの数としてアスペクトの数も数える，といった簡単な拡張をしている．

アスペクトによって結合が弱まるけれど，登場人物数は増えるので，CBO (Coupling Between Objects) が大きく減少するかわり WMC (Weighted Methods per Class)，RFC (Response For a Class) は増えてしまう．その結果，保守性は大きく向上していたが，WMC と RFC が保守性と理解容易性の足を引っ張る部分がある，と述べている．再利用性は，RFC の影響は受けないと考えられるため向上しており，テスト容易性はほとんど変化がないようだと述べている．

一点，よく分からなかったところは，論文では表を作ってどのメトリクスが保守性・理解容易性・再利用性・テスト容易性のどれに影響を与えるかを示しているが，文章の書き方からして，具体的数値で（たとえば，CBOの減った値に対してRFCの上昇値がどう，とか）向上や悪化を判断しているわけではなさそうなところ．

(追記)An Evaluation of Aspect-Oriented Programming for Java-Based Real-Time Systems Development というタイトルで，ISORC 2004, pp.291-300 に採録されているものがたぶん同じ話だと思われる．

_ [論文] 依存関係を表明として記述 ▲

Jackson, D.: Abstract Analysis with Aspect. Proceedings of ISSTA 1993, pp.19-27, Cambridge, MA, USA.

アスペクトといっても，アスペクト指向のアスペクトではなく，筆者が提案している解析手法のこと．要は手続きごとに，出力変数 x は入力変数 y に依存している，といったデータフロー関係を記述することで，それがない場合にはエラーとみなす．これによって，大事な変数の中身を途中で上書きしてしまうといったエラーを検出することができる．

「少なくともなくてはならない」条件を書くだけなので，仕組みとしては単純だし，誤検出なんかは起きない（そのかわり完全な条件ではないので，素通りの可能性はある）．実現の方法とか，その辺はあんまり書いてなかったので適当だが．

_ [論文] Aspectual Caml の論文を再び読み直してみた ▲

Hidehiko Masuhara, Hideaki Tatsuzawa, Akinori Yonezawa: Aspectual Caml: an Aspect-Oriented Functional Language.

Proceedings of ICFP 2005, pp.320-330, Tallinn, Estonia, Sep 205.

関数呼び出しが join point なのはいいとして，関数自体が変数に束縛されて違う場所で使われたりするから within みたいな静的スコープのポイントカットの使用がちょっと怖い気がした．

関数型言語的に嬉しくなさそうな副作用を伴う処理を全部アスペクト側に追い出すと，プログラムが簡潔になったりするのかなぁ，と思ってみたり．いわゆる計算方法自体と，入出力系などはまったく違うものだから分けて記述しましょう，という考え方はよさそうな気がするけど…．誰かに試してみてほしいような，別にどうでもいいような．

_ [VolumeDeskbar] 全体音量とWAVEの連動＋他のツールとの相互作用 ▲

掲示板で報告いただいた内容を調べてみた．

ViC-3(http://www.forest.impress.co.jp/article/2004/02/26/vic3.html)というツールは，アプリケーションの音量を（おそらくウィンドウクラスごとに）覚えておいて，そのアプリケーションがアクティブになったら既定の音量に戻すということをするものらしい．

Volume Deskbarの「全体音量とWAVEの連動」機能を有効にした状態で，全体音量とWAVE音量を違った値に設定するようViC-3が働きかけると，たとえば ViC が全体音量として 10 をセットするので，Volume Deskbar がそれに連動してWAVE音量も 10 にセットする．ここまでは良いのだが，ここで ViC がWAVE音量をたとえば20にセットしようとすると，Volume Deskbar が全体音量も20にセット，ここでViCは再び全体音量を 10 にセットしようとし，Volume Deskbar がそれに反応してWAVEを10にしてしまう，といったように音量自動調整がループを起こしてしまう．しかも，一方のプログラムから見ると，音量の調整はいちおう成功しているのに，すぐに元に戻されているという程度のことしか分からないので，対処のしようがなかったりする（ViC側がセットしようとする音量が，全体音量＝WAVE音量だったら大丈夫かもしれないが）．

_ [日記CGI] 「リンク元」設定の変更 ▲

いわゆる検索エンジンからこのページへ来る→「リンク元」としてキーワードが載る→そのキーワード自体を検索で見つけてさらにこのページへ来るという動きが気になったので，「リンク元」として表示しない正規表現として検索エンジン系のを一通りを入れてみた．

_ [ゲーム] "鉄人" Mangband ▲

Ironman MAngband という企画の結果が出ていた．要は１ヶ月で得点・フロア数を競うというものだったらしい．ランキングで名前を選ぶと，そのキャラクターの dump 結果（"C" で表示される情報）が見られる．他人のアイテムやら銘の刻み方が分かって面白い．

_ [論文] コード変換を使用してのアスペクト抽出リファクタリング ▲

Binkley, D., Ceccato, M., Harman, M., Ricca, F. and Tonella, P.: Automated Refactoring of Object Oriented Code into Aspects.

Proceedings of ICSM 2005, pp.27-36.

アスペクトマイニングなどで，アスペクトにするとよさそうな範囲がαとωというマークで括られているとき，そこに適用可能なリファクタリングの種類を選び出し，そこから開発者が実際にどれを適用するかを選択し，機械的な変換によってアスペクトを生成しよう，という手法．

リファクタリングの種類としては，メソッドの先頭あるいは終端のコードを取り出す Extract Beginning/End，あるメソッドの前後に登場するメソッドを取り出す Extract Before/After Call，条件文を取り出す Extract Conditional，Return文の前に実行されるコードを取り出す Pre Return，ラッパーオブジェクトを追加する操作を取り出す Extract Wrapper の５種類．

リファクタリングを適用可能かどうかは，TXLという言語を使ってルール記述を行なっている．たとえば Extract Before Call なら，「α; 文; ω; メソッド呼び出し;」という列に対して「α(BC適用可能); 文; ω; メソッド呼び出し;」といったようにアスペクト適用可能マークを追加するプログラム変換として記述している．そして，適用可能なリファクタリングのマーキングが複数付いていたら，開発者が最大で１つ選ぶ（適用しないという選択肢もあり）．

実験では，JHotDraw をこれでリファクタリングをどんどん適用したら，Extract Begin/End，Extract Before/After Call，Extract Wrapper がほとんどを占めていたらしい．また，お互いに関連しない（DEF-REF 順序に関係ない）文を入れ替えることが必要なケースは２割程度．

リファクタリングの適用は，それぞれのコード片に対して個別に作用しているようなので，その後でうまく一般的なポイントカット定義を作ってアスペクトをまとめないと，小さなアスペクトが大量に生成されるだけのようにも見えた．

_ [論文] Micro Patterns＝クラス単位の実装コードのパターン ▲

Gil, J. and Marman, I.: Micro Patterns in Java Code. [ACM site]

Proceedings of the 20th annual ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA2005), pp.97-116, San Diego, CA, USA., October 2005.

デザインパターンよりも実装に近いレベルでのパターンについて，ソースコードを分析してカタログを作ってみたという論文．設計の良し悪しの判断は難しいので，まず設計の違いについて調べてみる，といったことを言っている．

デザインパターンでは自動的なパターンの適用・認識が困難であることを踏まえて，Micro Pattern の特徴は，機械的に判定できるように定義してあること．たとえば「メンバーを持たないインタフェース」のように，属性，型名，メソッドのシグネチャなどから決定する．また，１つのモジュール単位で，パターンにマッチするかどうかを判定できるようになっている．

Micro Pattern を共通の語彙として使うといった使い方はデザインパターンと同じだが，Micro Pattern はそれぞれ，特定の設計問題に対する解法というわけではなく，もっと一般的な道具のようだ，とも述べている．

どんなパターンがあるか，なんかいずれ使うかもしれないのでいちおう日本語版っぽいものを作ってみた．

統計調査では，JDKやTomcat，Antなどを集めてきて，それらの中から各クラスがどの micro pattern に該当するかを調べている．統計によって，言語による制約ではなくちゃんと設計から生じたものであることを確認し，また，１つの仕様に対して，違う実装でも同じパターンを使っている傾向があることを確認している．

結果として，約75％のモジュールは少なくとも１つのmicro patternに該当する．登場回数では，Sink，Stateless，Implementor，Overrider，Pure Type の５つで約58％を占めた．

一方で，パターンごとの条件は排他的ではないので，２個以上のパターンに属するものも数多く，最大では６個のパターンに該当していたらしい．同じパターン群に属したクラスは互いに構造的に類似していたようで，Canopy/Restricted Creation/Overrider/Sink/Functional Object/Data Manager の６個セットに該当した１２個のクラスとか，Joiner/Pure Type/Stateless/Sinkにマッチした30個のクラスの例が挙げられていた．ある意味では，これらのパターンの組で，１つのパターンを定義しているといえる．

その他の調査としては，パターン群への分類の偏りを調べて，そこから得られる情報量を計算しており，定義したパターンによる分類には意味があることを確認していたり，複数の JRE ライブラリを比較して，パターンの出現率が同じ傾向であることを確認していたりする．

_ Call for Paper を見てたら ▲

First International Conference on Software Engineering Approaches For Offshore and Outsourced Development (SEAFOOD) というのが開催されるらしい．Conference Site.

露骨な名前だなーと思ったら，開催場所は ETH Zurich，Switzerland．何か名産でもあった？単に語呂合わせ？

それにしても，seafood で web 検索したとき，ちゃんと当たるんだろうか．ドメイン名にseafoodが入ってるから大丈夫なのかな…．

_ 書籍をRPG研に寄付 ▲

ソードワールドSFC/PCシナリオ100本集と，クトゥルー関連の書籍色々を寄付してきた．まだたくさん本が転がってるので，順次処分していく必要あり．

_ [論文] イディオムのアスペクトでの置き換え ▲

Bruntink, M., van Deursen, A. and Tourwe, T.: Isolating Idiomatic Crosscutting Concerns.

Proceedings of ICSM 2005, pp.37-46.

Cプログラムでのパラメータチェックをしていたイディオムを，アスペクトとして分離したよーという話．

イディオムを使っているとき，どうしてもイディオムから逸脱した要素（たとえばパラメータチェックが必要ない状況）も出てくるが，アスペクトとして必要な場合と必要でない場合とが両方とも明記されるので，理解容易性は向上すると述べている．保守性については，関数のシグネチャが変わったときにアスペクト側にも更新が必要という潜在的なリスクを背負うので，たとえば存在しないシグネチャをアスペクトが指定している場合は警告を出すとかいったチェックで対応している．

_ [論文] 分散システムのロギングのAOP実装 ▲

Briand, L. C., Labiche, Y. and Leduc, J.: Tracing Distributed Systems Executions Using AspectJ.

Proceedings of ICSM 2005, pp.81-90.

RMI を使った分散システムで，通信時には特定のコーディング規約に従っているという前提で，AspectJを使って分散システムの実行時情報を集めました，という論文．ロギングサーバを１つ作って，そこへデータを集めるような実装になっている．

実装のやり方，アスペクトのソースなんかが論文の大きな割合を占めている．ケーススタディでは実行時間の評価を行っており，分散システムだと，ネットワーク越しの処理なんかが遅くなるのでログ取りが重くなるのかと思えば，そうでもない（20％程度余分に時間がかかる程度）．数百ミリ秒で終わる処理だから微妙ではあるが．