netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-09-02 古い日記からの変換データ [長年日記] ▲
_ IWPSE/FSE ▲
IWPSE2003 １日目が無事終了．発表も無事(?)終了．質疑応答をまとめる．
論文は面白いものが色々．研究室の特定の人に読んでもらったほうがよさそうな論文がいくつかあるので，後でまとめることにする．
JAISTの，おざきさんと話す．ネタが固まると，いきなり論文を英語で書く（書かせられる）らしい．けっこう大変そうだけど……．D1で2回目の発表だ，と言ったら感心された．
カンファレンス・ディナーはフィンランド料理のコース．１品１時間くらいの間隔で，３時間ほど食べてたらしい．会話が主役だからかゆっくりしている．最後のほうは，みんな疲れたせいか口数も少なくなってたけど．
夜になると，さすがに寒い．吐く息が微妙に白かったりする．
2003-08-28 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
AspectJ 1.1 での intertype declaration の微妙な変化のことをドキュメントに追加．まだ Introduction という表現になったままだったので，Introduction -> intertype declaration に修正．
_ AspectJ ▲
aosd-discuss ML にて，Obliviousness Principle in Aspect-Orientedというスレッドで，
Join Point というのはアプリケーション拡張のためのインタフェースの一つで，最終的なシステムがちゃんと動作するためには，クラスに private, public というアクセス制御があるように，Join Point にも何らかのアクセス制御が必要なのではないだろうか？（オブジェクトがアスペクトに「侵入」されるのを防ぐ方法などもあってもよいのではないか）
という話が出ていた．でも，過去の議論によれば，
「ソースコードを変更しないでね」と宣言するようなメカニズムを作ることは可能だが，実際にそれでよいのかというのは疑問．「予期せぬ変更」はAOSDの裏にある問題でもある．結局，明示したとして，「意識的な変更」を妨害することはできても，予期せぬ変更を防ぐことはできない．
……ということで，あっさり流された感じがする．
2003-08-27 古い日記からの変換データ [長年日記] ▲
_ FSE ▲
FSE はなぜシングルトラックなんだろう，と思っていたら先生に「それが売りの会議だから」と言われた．
あまり関連のない分野の話も聞いてみる機会という意味ではいいのかも．シングルトラック→論文発表可能数が少ない→競争率が上がる→論文の質も上がるはず．FSE のほうが ICSE よりも引用したくなる論文が多い気がするのも，そのせいだろうか？
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: 設計のレベルでアスペクトを使う，-- ウィーブを設計レベルで，あるいは言語で，というように選択肢はあるらしい．
