netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2002-08-25 古い日記からの変換データ ▲
2003-08-25 古い日記からの変換データ ▲
_ OO2003 ▲
OO2003 のパターン関連ツールデモンストレーションとして紹介されていたツールのメモ．
Pattern Studio for Eclipse: Eclipse でデザインパターンを適用したコードを生成する． コードの生成にたまに失敗する，らしい．
Borland Together: デザインパターン適用ツール．Eclipse用のバージョンでは デザインパターン検出とかもできるらしい． 商用だけあって，いい速度で動作しているし， パターンのカタログも充実していた． しかも，メタデータを使わずに（変なコードを生成せずに） 動作するあたりがかなり偉い．
PTIDEJ: ソースコードからのデザインパターン検出ツール． もちろん，検出率は100％ではないらしい．
これに対する意見，要望，疑問は，
・使えるデザインパターンをどれだけ知っているか？
・知らないパターンを使えるようになるか？
・適用されているデザインパターンを「除去」できるか？
・デザインパターンの「再発明」をユーザに見せられるか？
といったところ．パターンといっても，GoF 以外のはほとんど知らないので本当に使いきれるのかなぁ，と疑問ではある．
_ OO2003 ▲
OO2003 で集めた情報その２．
ポストオブジェクト技術のセッションでの発表:
オンデマンドなアスペクトウィービングを使ったWebシステムのパーソナライズの話:・動的ウィーブで，必要なところだけキャッシングして高速化・クライアントごとに別クラスローダを用意して， 別アプリケーションとして認識させるらしい．・JIT Aspect Weaver を使うことでウィーブのコストを下げる．
しかし，問題として，・生成したアプリケーションの生存期間をどうするか．・クライアントの数が多くなったとき， パーソナライズしすぎて死ぬ？といったものを挙げていた．生存期間をアクセス頻度などから推定するとかするんだろうか．ちょっと面白そう．
_ Mixin によるプログラミングの話: ▲
Mix-in = 抽象サブクラス，という説明はとても面白いと思う．Mixin を追加した Java （Javaへ変換する形で実装可能）McJava: http://kumiki.c.u-tokyo.ac.jp/~kamina/mcjava/を実装したらしい．
合成されるクラスにインタフェースを requires セクションで要求できるらしい．Mixin ID requires Interface { ... }合成は ID::ID::ID というようにMixinとクラスの識別子を連結するだけ．
関連研究の調査が充実していた．ABT: Sullivan, Abstract Behavioral Type -- イベントを定義しておいてイベントをListen したい人を登録しておけるようにする．クラスをあらかじめ ABT にしておかないといけない．
AspectJ : AspectJ では Aspect はファーストクラスでないのでオブジェクト間の関係のインスタンスが書けない？とか言っていた実は Aspect は class Aspect のインスタンスだし関係オブジェクトは素直にブジェクトにすればいいのになぁ，と思う．
Epsilon モデル: Ubayashi, N. et al., 2001役割，役割間の関係を分離するらしい．暇があったら見てみよう．
クラス（デザインパターンなど，インタフェースによる分離）による実装とMix-In による実装とで，結合度とかが違うのか？という質問があった．アスペクト使った場合もそうだが，実装方法にかなり依存しそうで，Mixin 使わないとできないこと，は少ないような気がする．
_ OO2003 ▲
OO2003 で集めた情報の整理，その１．
チュートリアル：アスペクト指向ソフトウェア開発:
デザインパターンのうち，オブジェクト間の連携に関するものは AOP で書こう，というのを考えている人は多いらしい．
デザインパターンの典型的な実装問題として，継承ベースでの構築はアプリケーションの基本機能を再利用できない．（例: 一度 Observer にしちゃうと，再利用するときに Observer はいらないよーとは言えない）
しかし，継承でObserverを実装している場合のような，型の安全性を捨ててるように見受けられる，という意見もあったり．そんなことはないと思うのだが……．
挙げられていた参考文献はたいてい読んだことがあるものだった．
サブジェクト指向に関しては: Harrison, W., Ossher, H. (IBM)Subject-Oriented Programming- A Critique of Pure Objects, Proceedings of OOPSLA 93
ロールモデルに関して： ロール実現に使う基本的な手法 Kendall, E.:Role Model Designs and Implementations with Aspect-Oriented Programming, OOPSLA 99
アスペクトでメンバを導入したりして実現するテクニック集
Katara, M. "Architectural Views of Aspects", AOSD2003
アスペクトの観点からアーキテクチャを設計 -- ロールベースのアイディア aspect architecture == view type の一種，アーキテクチャを設計するための要素とその間の関係を定義.
Aspect-Oriented Design: 設計のレベルでアスペクトを使う，-- ウィーブを設計レベルで，あるいは言語で，というように選択肢はあるらしい．
2005-08-25 ▲
_ [hyCalendar] バグ発見＋仕様変更． ▲
新機能を追加すべく少しいじっていたら，エクスポート時に「休日として設定された周期予定」が出力されない問題を発見．なんと戻り値をセットしていなかったので，今まで不定値で動いてたのかと思うと少しぞっとする（文字列型だったから，たまたま空文字列ンい初期化されてたのかもしれない）．
また，「休日なら１日ずらす」ように設定されたユーザ定義の祝日が，今までは他のユーザ定義の祝日を取り扱うことができなかったので，対処．ユーザ定義の祝日には優先度を持たせて，自分自身より優先度の高いユーザ定義の祝日だけの影響を受けるようにしてみた．
まだイベントが多い（旅行，FSE出張など）ので，次のリリースはいつになるやら．
2006-08-25 ▲
_ [論文] アーキテクチャ情報に基づいてコールグラフをレイアウトする ▲
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次元の表現ならドローバックが少ない，と主張している．球面上へのマッピングなどよりは多少直観的かもしれない．
アーキテクチャ情報を使う意味は，メソッド間の呼び出しを，コンポーネント間，サブシステム間の呼び出しというように分類して明示的に可視化できることにあるのだろう，と思う．それがどのくらい効果があるかは分からないけど，ないよりはあったほうが有利？
使いやすさその他の評価実験はなし．トレーサビリティ情報を使っての可視化とかいうのもなし．タイトル的には色々期待してしまったので少し残念．
