netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-08-07 古い日記からの変換データ [長年日記] ▲
_ [論文]コンポーネント更新時の問題予測 ▲
Stephen McCamant, Michael D. Ernst:Early Identification of Incompatibilities in Multi-component Upgrades.Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.440-464,Oslo, Norway, June 14-18, 2004.
データフロー解析を使って，ある関数呼び出し先を新しい関数の実装で差し替えたときに問題が起きるかどうかを予想しようというもの．
基本的には，呼び出し側の事前条件→呼び出し先の事前条件，呼び出し側の事前条件＋呼び出し先の事後条件→呼び出し側の事後条件，というのが成立すればよいらしいのだが．
データフロー解析の例として挙がっている記述が，条件分岐や式の中身まできちんと意識しているっぽいのでそこまでうまく動くのかな？と少しあやしげな印象．入出力のパラメータの関係だけに注目すれば（どのパラメータがどの出力に到達するかだけ使えば）意外とうまくいくのかもしれないが．
C のライブラリに対して適用していて，結果としてはそれなり，ではあるみたい．
_ [論文]カプセル化のポリシー選択 ▲
Nathanael Schärli, Stéphane Ducasse, Oscar Nierstrasz, Roel Wuyts: Composable Encapsulation Policies. Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.26-50,Oslo, Norway, June 14-18, 2004.
クラスのどのメンバーにアクセスできるかはpublic, protected などで宣言できるが，クラスの利用方法をインスタンス化・継承の２択に決め付けていて，しかもあとから変更がきかない（サブクラスごとに個別にアクセス権を設定したりはできない）．
C++だと friend 宣言を導入したりして部分的に解決しているが，逆にいうとたいした解決方法がないのが現状．
で，この人たちは，クラスのメンバーをグループ化してポリシーとして名前をつけている．たとえば，MyCollectionクラスを作ったときに，add, collect, at だけにアクセスできる「AppendOnly」，remove にもアクセスできる「Collection」，internalAdd にもアクセスできる「All」という３つを定義して，MyCollectionを所有するTransactionProtocolはappendOnlyで，継承するMySetはCollectionポリシーでアクセスする，といったことを別個に宣言することができるようにしている．
Smalltalkをベースに例を説明していて，インスタンスを作る時点やサブクラス定義時に使うポリシーを記述するのだが，そのときに「BasicUseポリシーだけど，そのうちｘｘは除く」といったカスタマイズも許していたり，ポリシー自体はクラスとは個別に名前を付けられるのでReadOnlyポリシーのインスタンスなら……といった記述もできそう．
アイディアとしては面白くて，価値もわかりやすい．インタフェースにアクセス権に関するメタデータを付加する話とも言えなくはない．
_ [論文]動的リンクなコネクタ ▲
Yu David Liu, Scott F. Smith: Modules with Interfaces for Dynamic Linking and Communication. Proceedings of 18th European Conference onObject-Oriented Programming, pp.414-439,Oslo, Norway, June 14-18, 2004.
いわゆるコンポーネント間のコネクタ（import／export）を作りましょうという話を，動的リンク上で実現する話．コンポーネントが動的に差し替えられるような環境などを想定しているらしい．
CORBAなどのインタフェースを双方向性にした，とかJavaなどのクラス単位よりも粒度の粗いコンポーネント単位にした，といった感じの印象でよさそう．逆にいうと，あまり新鮮味のようなものはなかったりする．単に興味の範囲外だからか．
_ [AspectJ]アスペクト指向技術セミナー ▲
とりあえず，セミナー上で登場した質問などはWiki にまとめてみようかと試みてみたり．とりあえず Wiki 準備．アスペクト指向な wiki
_ [AspectJ]アスペクト指向技術セミナー ▲
とりあえず話を聞いてきたことをまとめておくと:
長瀬さんによる「アスペクト指向入門」．アスペクトって何，という基本的な話と，Eclipse による簡単なデモ．長瀬さんは，Join Point Model が話に出てこないので，「そのモジュールはどこで使われるのかを定義する」という形で話を進めていた．授業で使った「いつ実行するか」にも近いが，「どこで」のほうが，ソース上の位置という感じがしてわかりやすいかも．
_ 鷲崎先生による「実践アスペクト指向プログラミング」 ▲
一部，M1相手に授業やったときの資料が再利用されているけれど実行メカニズムとか，ソースコード例とかだいぶ詳しくなっていた．
ひがやすおさんによる「現場で使えるAOP」．Seasar2を使った場合のアスペクト記述方法など，実践よりの話．インスタンスごとに，実行時に適用するアスペクトで，実行のための環境は必要だが覚えることは少ない，という感じ．
立堀さんによる「応用アスペクト指向プログラミング」．アスペクトを使ってデザインパターンを記述した，アスペクト指向リファクタリング，などの話をまとめたもの．
ＱＡとしては以下のような感じ．
・パフォーマンスは悪くならないのか
・コンパイラのパフォーマンスはどうなのか→多少悪くなる．（AspectJ 1.2 でだいぶ良くなっているとは聞いているのだけど， 「手書きの最適化コードよりは遅い」のは宿命． オブジェクト指向が出てきた直後も「遅い」って言われたので， 保守性と速度とどっちが大事かという話？）
・スレッドの競合時，といった記述はできるのか→何らかの形でできたような気はするが不明
・デバッガなどの開発サポートは十分あるのか→ある程度使えるが，まだ十分ではない
・デバッグは難しくないのか． OOP では Liskov の置換原則のような問題を減らすための デザイン規則があるが，AOP にそういったものはないのか．
・設計方法というのはないのか？→設計まわりの話はまだまだ未成熟で， プログラミングがしっかりしてきて， 良いデザインというのが分かってくるまでは難しそう．
・Seasar2ではコンテナの適用作業が面倒ではないのか？→それぞれのフレームワーク個別の支援を用意して， コンテナに依存したコードは書かなくていいようにしている．
2004-08-05 古い日記からの変換データ [長年日記] ▲
_ [論文]DｂCを条件付で無視するキャスト ▲
Robert Bruce Findler, Matthew Flatt, Matthias Felleisen:Semantic Casts: Contracts and Structural Subtyping in a Nominal World. Proceedings of 18th European Conference onObject-Oriented Programming, pp.364-388, Oslo, Norway, June 14-18, 2004.
ほんのわずかに事前条件や事後条件が異なるだけでコンポーネントが再利用できなくなる場合がある．特定のコンテキストで利用するために少なくともその場面では制約に従っていることがある．
たとえば，正の整数しか格納しないキューが要求されている場面で，手元に任意の整数を格納できるキューが存在していて，それをそのまま使いたい，という要求が生じる．
そこで，Semantic Castとして「今回はこのコンポーネントが責任を持つから事前条件・事後条件の一部を見逃してくれ」という感じの宣言をしてキャストを行う．実際にエラーが起きた場合は，Semantic Castを行ったときに「責任を持つ」と宣言したコンポーネントが悪いというエラーが出されることになる．
基本的には，クラス階層として継承関係になくてもBehavioral Subtyping を保っている場合などは安全にキャストできるので，場合によっては便利でないこともない．そのわりには仕掛けがおおげさかもしれないが．
_ [AspectJ]ドキュメント整理 ▲
アスペクト指向技術セミナーに出かけたりする準備をしつつ，AspectJ のドキュメント量がいい加減増えてきた感があるのでそろそろ整理しようと思い立ったりする．wiki にしておくのが，レイアウト面の手抜きができて楽そう？なので，wiki 各種について調査開始．
_ [論文]テスト実行結果からのマルコフモデル構築 ▲
James F. Bowring, James M. Rehg, Mary Jean Harrold:Active Learning for Automatic Classification of Software Behavior.Proceedings of ISSTA 2004, pp.195-205,Boston, Massachusetts, USA, July 2004.
あるプログラムにテストケースを与えて出てきた実行履歴のうち，各分岐で True/False のどちらにどう進んだか情報を抽出する．この True/False での分岐回数を次の分岐点への遷移確率と考え，マルコフモデルを構築する．
テストデータの自動生成ツール等を使ってデータを生成し，プログラムを１回実行して分岐をどう通ったか列が出るので，それを作成済みのマルコフモデル上である程度の確率で起こる動作なのかをテストし，確率的に起こりにくい＝未知の振る舞いとして新しいマルコフモデルを追加するというactive learning を行ってテストケースを増やしていけば，有用なテストケースだけが抽出されていくという話．
ケーススタディで Batch Learning と比較しているが，学習データが増えてきたときの学習効率が若干違っていて，Batch のほうはデータの増加量に対して結果があまりよくならない場合があるみたい．
350個のデータで13000近いデータを分類したときで，未知の振る舞いが検出される確率が，active learning 側は batch に比べて10分の１程度まで下がっている．これは，未知の振る舞いが検出されにくい＝テストケースがそれなりにそろっていて，未知の環境（実働環境）に置かれても大丈夫だろう，と確信できるということになってくる，らしい．
batch learning に対する active learning のテストデータの分類における有用性を示してはいると思うのだが，この手法を用いて作ったテスト計画が（たとえば未知の振る舞いが検出される確率が 0.001 になるまで，といったテスト計画が）どのくらい意味を持つのか，というのはいまいち分からず．けっこう面白い研究ではあると思うのだが．
_ [論文]外部状態のアサーション ▲
Robert DeLine, Manuel Fähndrich: Typestates for Objects. Proceedings of 18th European Conference onObject-Oriented Programming (ECOOP 2004), pp.465-490,Oslo, Norway, June 14-18, 2004.
クラスの型以外に，オブジェクトの取りうる（外部から見える）状態も宣言できるようにして，各メソッドの事前条件や事後条件として状態遷移を記述できるようにする手法の提案．
たとえば，[ TypeState("Open", "Closed") ] class WebPageFetcher {...} と記述することで，そのインスタンスが Open か Closed の２状態を取るようにする．
各メソッドの先頭に[ Pre("Closed"), Post("Open") ] void Open() { ... }というようにヘッダをつけることで状態遷移を宣言する．また，[ Post("Closed") WhenReturnValue=true ] といった記述でメソッドが返した値に状態遷移を関連付けるといったことを考慮している点はけっこう面白い．インタフェースを書く人間は状態を考慮して記述するが，実装者はその状態を考慮せずともコードが記述できる（もちろん戻り値の値はきちんと設定する必要はあるが）．
あるクラスの事前の状態・事後の状態からフィールド値がどのような条件であればその状態である，というのがわかるが，子クラスでメソッドが書き換えられるとその条件は変わってくる．そのため，クラスフレームという単位で状態管理を行う．１つのオブジェクトに，そのオブジェクトが属するクラス階層の各クラスについてそれぞれ１フレームが準備され，状態を格納する．
WebFetcher を継承して CacheFetcher を作ったとすると，普通に WebFetcher.Open を使っている場合は，[WebFetcher＠Open][CacheFetcher＠Closed]といった状態になる．これでは子クラスを使う場合に不便なこともあるので，virtual なメソッドに対してはきちんと子クラスの状態も変わって，変えたくない場合は Post("Closed", Type=Subclasses) などと明示的に宣言できるようにするみたい．
基本的には Liskov Substitution Principle とかに従っていてメソッドごとの状態の "副作用" が明示されるので使い方によってはかなり便利．インタフェースで外部状態だけ書いて実装クラスで内部状態まで書くといった使い方をすれば仕様と実装も区切られるし，面白いかも．
_ [論文]Composite パターンの拡張問題 ▲
Mads Torgersen: The Expression Problem Revisited. Proceedings of 18th European Conference on Object-Oriented Programming (ECOOP 2004), pp.123-143,Oslo, Norway, June 14-18, 2004.
"Expression Problem" と呼んでいるのは，Composite パターンを使ってツリー構造を作ってその上で再帰呼び出しや Visitor を使って処理を行うとき（たとえば Expression クラスを継承したAdd クラスと Literal クラスで加算式を表現するとき），Composite ツリーに新しいクラスや処理を追加しようとすると既存のクラスのコードを変更しなければならない場合がある，という問題．
で，この人は，Java Generics が導入されそうな時期だからかGenerics を使って問題を解決できるんですよーという提案．Visitor パターンによる実装を operation-centered，クラス階層による再帰構造を data-centered approach としてそれぞれの場合で，別個に解法を提案して，さらに hybrid approach というのを提案している．
基本的には，ある古いコードで生成されたオブジェクトが他の新しい演算などが追加されたコード上でも稼動することが目標らしい．
アプローチとしては Visitor パターンを使って accept(T node) のように型パラメータでaccept を一般化しておいて，ノード側も受け取る Visitor を型パラメータで一般化しておいて，既存のコードを使っている部分を変更せずに新しいクラスなどを追加できるようにしましょう，と言っている．
立場としてはコードの書き方，実装のための技術という感じ．
2004-08-04 古い日記からの変換データ [長年日記] ▲
_ [論文]統計的デバッグ ▲
Alice X. Zheng, Michael I. Jordan, Ben Liblit, Alex Aiken:Statistical Debugging of Sampled Programs.Proceedings of the 17th Annual Conference on Neural Information Processing Systems (NIPS 2003).
プログラムのあちこちに検査用の処理として関数戻り値のチェック（０，０より大・小）や代入時の値チェック（そのスコープのほかの変数との大小比較）を埋め込んでおいて，それをランダムな間隔で検査していく．で，各検査処理の実行回数を結果として出力し，その結果とプログラムの成否とを統計的に調べる手法．
ケーススタディでは7000回くらいの入力を与えて1000回くらいクラッシュした，といった感じ．統計的に，クラッシュ原因として上位に来たのがわりと役立つ結果ですよという話のようなのだが，実行するテストケースをたくさん準備するのと，実行するコストは，プログラムによっては大きいかもしれない．また，プログラムによって「変数の代入文が多いので変数同士の比較を行った」といった微妙なカスタマイズをしているので，怪しい感じはする．
