netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-08-02 古い日記からの変換データ [長年日記] ▲
_ [論文]現在実行しているコードの表示 ▲
Kazimiras Lukoit, Norman Wilde, Scott Stowell, Tim Hennessey:TraceGraph: Immediate Visual Location of Software Features.Proceedings of International Conference on Software Maintenance (ICSM'00), pp.33-39,San Jose, California, October, 2000.
ソフトウェアの実行履歴で，ある機能を実行した場合としなかった場合とで実行された関数の差分を手がかりにどの機能をどの関数が実装しているか調べるSoftware Reconnaissance というツールではいちいち実行履歴の取得→解析という手間があるので，プログラム実行時の様子を直接可視化するTraceGraphというツールを作った，という話．
TraceGraphは，横軸にメッセージ（現在実行中の手続き），縦軸に時間をとって，現在実行中の部分に四角いマークを描画する．ある種シーケンス図に近いが，これをプログラムを実行しながら見ていくことでプログラムの理解を進める．
論文自体はこのツールを用いたケーススタディ．保守作業をする人間が作業開始のための手がかりをすばやく見つけられることがツールの利点らしい．
2004-08-03 古い日記からの変換データ [長年日記] ▲
_ [論文]実行経歴の特徴抽出 ▲
M. J. Harrold, G. Rothermel, K. Sayre, R. Wu, L. Yi:An Empirical Investigation of the Relationship Between Fault-Revealing Test Behavior and Differences in Program Spectra.Journal of Software Testing, Verification, and ReliabilityVol.10, No.3, pp.171-194, September, 2000.
プログラムの実行系列から，どのパスを通ったか，各ブランチでどの経路を何回ずつ選んだか，といった実行系列の特徴を取り出そうという試み．
なんか振る舞いが少しでも違うプログラムだとけっこう違う値には変わるみたい．ただ，変わったからといってどうだというのか，というのがある．使用法としては，実験的にソフトウェアのバグがどの特徴と関連するかを調べるということになるのだろうか．
いまいち役立つのかどうか不明．
_ [論文]実行パスへのＩＤ割り当て ▲
The Use of Program Profiling for Software Maintenance with Applications to the Year 2000 Problem.Proceedings of the 6th European Software Engineering Conference held jointly with the 5th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE97), pp.432-449, Zurich, Switzerland, September, 1997.
2000年問題に対処するために（それ以外にも使えるが）各テストケースがプログラムの実行パスのどこを通ったかプロファイルする，という話．
実行パスの各分岐点に，それが二分決定木であるかのように，選んだ経路に応じた数値加算を埋め込んで，終点まで到着した時点でパスのIDが得られるようにする．
あとは，テストケースごとに数値が出てくるので，それをスペクトルのように並べて比較したりとかして問題のパスを特定したりする．
_ [論文]依存関係のテスト容易性への影響 ▲
Stefan Jungmayr:Identifying Test-Critical Dependencies.Proceedings of the 18th International Conference on Software Maintenance (ICSM 2002), pp.404-413,Montreal, Quebec, Canada, 2002.
テストを難しくする要素として，コンポーネント間の依存関係があるが，ある依存関係を取り除いたときの依存関係のメトリクスの減少度合いを比較し，減少が大きいものを Test-Critical な依存関係として認識しよう，というもの．
依存関係のメトリクスとしては，この論文では各コンポーネントが直接あるいは推移的に依存するコンポーネントの平均個数 ACD を使っている．
実際，ACDを減少させる度合いで上位の１０％くらいの依存関係を取り除くと ACD の値は半分くらいまで落ちたりする．このような依存関係の要因は，主にデザイン上の悪い決定，GUI上でのウィンドウ間の遷移の実装，などだったらしい．ACD は結合度メトリクスCBOなどとは相関が少なく，CBOは実はテスト容易性とは関係があまりないのでは，とも言っている．
設計時に，このようなテスト容易性にかかわる依存関係を考慮して，設計を考え直すことで，テスト容易性を少しは向上できるかもしれない．
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回くらいクラッシュした，といった感じ．統計的に，クラッシュ原因として上位に来たのがわりと役立つ結果ですよという話のようなのだが，実行するテストケースをたくさん準備するのと，実行するコストは，プログラムによっては大きいかもしれない．また，プログラムによって「変数の代入文が多いので変数同士の比較を行った」といった微妙なカスタマイズをしているので，怪しい感じはする．
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-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-26 古い日記からの変換データ [長年日記] ▲
_ [AspectJ] AOPで契約による設計 ▲
DBC のチェックを行うコードをアスペクトとして付加するという話が developerWorks に載ってた．
どうでもいい話だが，「Design by Contract」はInteractive Software Engineering の登録商標らしい．
2004-08-27 古い日記からの変換データ [長年日記] ▲
2004-08-28 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar]全角スペースの扱い ▲
0.8.4 向けに，起動時にIMEを自動有効にするオプションを追加．ついでに，TODOリストビューにおいて，チェックボックスのON・OFF切り替えを半角スペースだけでなく全角スペースでも取り扱えるようにしてみた．
MS-IMEの状態取得では，JP・ENのモード切替が起こっても「変換モードの取得」では設定が取得されないことが判明．しかも IME は ON になっていると判定される．TListView は，EN モードのときのスペースキー押下は半角スペースとして扱うが，JP モードの「半角英数」入力時とプログラム側からの区別ができなかった．
仕方がないので，KeyDown イベント時にチェックボックスの状態を保存しておいて，その後飛んでくる KeyPress 時にチェックボックスの状態が既に変わっていれば処理済みなのでイベントをそのまま捨てて，チェックボックスの状態が変わっていなければIME の半角英数が有効なので半角スペースかどうか判定する，という微妙な処理で実装した．
ちなみに，全角スペースは，KeyDown ではトラップできずKeyPress で２回（２バイト分）のイベントが飛んでくることで判定している．我ながらひどい実装．
2004-08-29 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar]0.8.4 リリース ▲
地味なバグフィクスが終了したので 0.8.4 リリース．本当は他にやること一杯あるんだけど……．
「インストールできず削除もできません」という曖昧な質問が来た．「曖昧なので答えられません」という旨の返事を出しておくことにする．具体的にどういう操作ができないのだろう．謎．
2004-08-31 古い日記からの変換データ [長年日記] ▲
_ [論文]安全なメタクラスの結合 ▲
ICSMの発表資料作りで一時的に煮詰まってきたので，気分転換に論文を探して読むことにする．
Noury M. N. Bouraqadi, Thomas Ledoux, Fred Rivard:Safe Metaclass Programming.Proceedings of OOPSLA 98, pp.84-96,Vancouver, B.C., October, 1998.
メタクラスを使って継承階層を作るときには，クラス間の継承関係と，対応するメタクラス間の継承関係がきちんと保たれないと困る，とかいう互換性問題があるらしい．
ところが，特定のクラスにだけ属性を付与しようとすると（たとえばあるクラスのインスタンス生成を禁止するAbstract を付加すると）その属性が継承されてしまって困ったことになる．
そこで，互換性を維持するためのメタクラスと，クラスごとの属性を付与していく「属性メタクラス」を区分し，実際のクラスたちは属性メタクラスのインスタンスとする．
MetaA ←(inherit)← "MetaA + Singleton" ←(instance)← Aといったようになる．間の "MetaA + Singleton" のところが付与する属性の数に応じて継承階層数が増えていく．
著者らは2003とかにも原稿を書いていて，このあたりの継承階層をMix-inとして実装するつもりのよう．クラスのプログラマが，サービスとして提供されているメタクラスをMix-inとして導入するイメージみたい．
Non-orthogonalな属性（Value-Conflict）については単に継承元のメソッドを呼ぶようにして振舞いましょうといった程度のことしか書いていなかった．あとは開発者がMix-inする段階などで順番など何らかのコントロールをする，ということになりそう．このあたりの話は他にも文献をあたってみないといけない．
結合の安全性という話とは直接は関係ないが，この論文の著者らは，属性メタクラスのクラス（メタ-メタクラス）をベースに使われる場面ごとに属性メタクラスがインスタンス化されるという考え方をしている．この辺はアスペクトのインスタンス化の話に何か結びつくかも？結合対象はあくまでクラス単位だけれど．
