netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-10-01 古い日記からの変換データ [長年日記] ▲
_ [work]動的解析のスケーラビリティ ▲
AspectJ プログラムの実行時情報を集計するツールを再構築中．Ruby スクリプトでプロファイル結果→イベント列→集計情報→頂点集約→DOTという段階を踏んで Strategy パターンを適用していくインフラっぽいスクリプトを構築してみた．
生成された DOT ファイルを Graphviz のコマンドでコンパイルするところまでは自動化．コマンドは次の通り．
dot -Tsvg -o outputfile inputfileで，とりあえずメソッド呼び出し関係とメソッド間のデータ依存関係（１個以上の引数を渡しているメソッド呼び出し，void 以外の戻り値，フィールド経由のデータ依存関係）を抽出するするスクリプトを作って動かしてみた．
800行のコードの実行履歴が4MB程度で，データ依存関係は10万くらいの辺数．さすが生データというべきか．効率の良いフィルタを作らないことには何とも使い物にならない．動的スライスの実装とかしている人たちはどうやって実装してたのだろう……．
2004-10-02 古い日記からの変換データ [長年日記] ▲
2004-10-04 古い日記からの変換データ [長年日記] ▲
_ [論文][work]モデルベースでのアスペクトの競合の検出 ▲
Francis Tessier, Mourad Badri, Linda Badri:A Model-Based Detection of Conflicts BetweenCrosscutting Concerns: Towards a Formal Approach.Workshop on Aspect-Oriented Software Development 2004.
アスペクトの導入が問題を起こさないかどうか（アスペクト同士が競合しないかどうかなど）を早い段階で（モデルを作ったあたりで）検出しましょう，というもの．
基本的なアイディアとして，アスペクト同士が・同じクラスに作用するが Join Point が異なる→OK・同じクラス，同じ Join Point に作用する→危険 -- アドバイスのタイプ(before/after)が同じ場合は高リスク -- 引数が同じ場合もリスクがある・異なるクラスにしか作用しない，共通部分がない →OKといった感じの分類をして，警告を出しましょうというもの．
この情報は静的解析なので，これをベースに動的解析したりとか，他の手法と組み合わせることも考えているよう．
アプローチとしてはそれなりに単純で分かりやすい．もしソースコード上から解析するのであれば静的に Join Point の共通部分とかをテストするのが（Cflow などを含む場合は）難しそうな気はするが．
モデル記述でテストする場合，モデルの記述に必要なコストがそれなりに低くてモデルとコードの対応付けがきちんとできるのならそれなりに有用そうではある．
ただ，「競合してるかもー」と警告を出すのは簡単だけど，開発者がシステム全体で一貫した解決方法を使っているかとか，その解決方法が正しそうかどうかとかをいかに確認するかも問題になってくるだろうから，その辺で議論できたら面白そう．
_ [論文]合成可能なメタオブジェクトの記述 ▲
Philippe Mulet, Jacques Malenfant, Pierre Cointe: Towards a Methodology for Explicit Composition of Metaobjects.Proceedings of the 10th annual Conference on Object-Oriented Programming Systems, Languages, and Applications(OOPSLA95), pp.316-330, Austin, Texas, United States, 1995.
メタオブジェクトを複数使う場合の問題を解決しましょうという論文．複数のメタオブジェクトは，順番に連結されるものとすると，Trace→Delegate→(Basic) というように順番が決まる．
メソッドの呼び出し・実行を Lookup + Apply ととらえて，メタオブジェクトはそれぞれ自分の Lookup を実装するが，このときに連結先のメタオブジェクトの Lookup を利用して，Lookup 処理や，追加の処理（Delegationなど）を実装する．
メタオブジェクト間の関係の取り扱いにはSpecialization と Aggreagation の二つを考えていて，親メタオブジェクトの Self 参照が自分自身を指すか親メタオブジェクトを指すかを選択する．
Lookup が起きると，連結されたメタオブジェクトの中でメッセージを読み替えや Lookup の連鎖などが起こって，最終的に実際のオブジェクトの動作が決まる．
このアプローチでは，メタオブジェクトは，自分自身が，連結相手に対してどのように振舞うかを記述する．汎用的な Mix-in が書ける人ならちゃんと書けそう．Composition Filter では結合演算自体は外部で定義されて通常はフィルタ生成順序などで implicit に扱われる点が異なる．
2004-10-05 古い日記からの変換データ [長年日記] ▲
_ [Java]J2SE 5.0 (JDK1.5) ▲
J2SE 5.0 をインストールしてみた．今までは C:/ 直下にディレクトリを作っていたのに，なんと Program Files 以下にインストールされる．とても大きな進化．
_ [論文]アーキテクチャレベルでの情報可視化 ▲
Mohlalefi Sefika, Aamod Sane and Roy H. Campbell:Architecture-Oriented Visualization.Proceedings of OOPSLA96, pp.389-405, CA, USA.
情報をまとめて抽象化して提示するのが大事ですよと主張する論文．メソッド単位，クラス単位ではなくサブシステム単位などで情報を集計した結果を出すためにInstrument という名前の観測ツールをCompositeパターンで合成して使うらしい．どのクラスがどのサブシステムに対応するかは開発者が与えないといけないので手間はそれなりにかかる．
_ [論文]オブジェクトの探索 ▲
Raimondas Lencevicius, Urs Holzle, Ambuj K. Singh:Query-Based Debugging of Object-Oriented Programs.Proceedings of OOPSLA97, pp.304-317, Atlanta, GA, USA.(注: Holzle の o はウムラウトつき)
デバッグ時にオブジェクトの情報を参照したいけど普通のデバッガだと特定のインスタンスしか見れないのでクエリーにマッチするようなオブジェクトのペア（というかtuple）を取り出してきましょうという話．
クエリーかけるのに a == b かどうかの判定ができないといけないとか，属性（フィールド）の参照に副作用があってはいけないとかいう条件は付くが，(a include b) and (c include b) and (a != c) のようにしてオブジェクト b を共有しているオブジェクト a, c のペアを見つけるとか，何か色々な使い方はできる，ということらしい．筆者たちの実装では，オブジェクト集合から該当オブジェクトを探すパフォーマンスもそれほど悪くない（１秒程度で結果が表示され始める）らしい．
いつクエリーを実行して，どうデバッグに使えるのかというところについての言及はあまりなかったりするが……．条件付ブレークポイントに比べてどのくらい便利なのか？というのがいまいち見えてこなかったりする．「あるクエリーにマッチするオブジェクトのメソッドが呼ばれたなら……」という条件付ブレークポイントなんかを作れば便利？
_ [work]動的解析の高速化 ▲
プロファイル結果→イベント列→集計情報→頂点集約→DOTという段階を踏んで処理を進めていくと，各頂点が集約対象かチェック→頂点に接続した辺を操作という処理が O(V*E): Vは頂点数，Eは辺数となってしまって遅くてたまらないことが判明．（辺のつなぎ替えが集合の操作なので実はさらに遅い…）
除去されることになる頂点については，それぞれ source(V) = {V に到達する依存関係の発生頂点の集合}という集合を記憶しておいて，{除去される頂点 V → 除去されない頂点 v }の依存関係が発生したらsource(V) の各頂点 → v の辺を生成するようにした．
こうすると，ログのサイズ n に比例する時間で処理が進むのでだいぶ高速になった．集合の管理の手間があるので，厳密に O(n) とは限らないが．
とはいえ，AspectJ のコードだと，AspectJ がいっぱい依存関係を追加で生成しているようでデータ依存関係が分かりやすいとは到底いえないみたい．
2004-10-06 古い日記からの変換データ [長年日記] ▲
_ [AspectJ]wiki ▲
Wikiへの移行完了（アスペクト指向な wiki）．変更点としては・文章の構造化・重複した記述の排除といったところ．
2004-10-07 古い日記からの変換データ [長年日記] ▲
_ [論文]Fan-Inベースのアスペクト抽出 ▲
Marius Marin, Arie van Deursen, Leon Moonen:Identifying Aspects using Fan-In Analysis.WCRE 2004, to appear.
各メソッドがいくつのメソッドから呼ばれているかをあらわすFan-In の数値でクラスをランキングして，上位のもののうち，Setter/Getter/Utility クラスを除去した結果がアスペクトの候補としてよさそう，という論文．
Setter/Getter は基本的にシグネチャベースでフィルタしていて，いちおう実装も少しはチェックしているらしい．Utility としては toString などのメソッド名フィルタと，*Utils のようなクラス名ベースのフィルタを使っている．このあたり，少し経験的な手法ではある．
ロギングなどのあちこちにコーディングされた「大きなfootprintを持つ」アスペクトに対しては有効だが，デザインパターンの個別の実装みたいに小さなfootprintのものは見つけられなかったりする．
シンプルなわりには効いているという気はする．false positive も negative も出てくるが，コードクローン分析と組み合わせたりして使おうと考えているみたい．
_ [論文]インタフェース実装のアスペクトへの移行 ▲
Paolo Tonella, Mariano Ceccato:Migrating Interface Implementations to Aspects.Proceedings of ICSM2004, pp.220-229.
スライシングのセッションと重なってたのでチェックしないままになっていた論文．
Java で使われる *able インタフェース，呼び出し関係でグループ化したら同じクラスの他のメソッドと一緒には使われないもの，同じクラスの他のメソッドから呼ばれていないので分離しても問題ないもの，などをアスペクトとして分離してみたという話．
Java における「アスペクトっぽいもの」を重点的に取り出してみたら，実は java.util や java.awt などにたくさんその手のクラスが含まれていて，それらをアスペクトに分離するとコード行数で約10％，クラス図上での依存辺の数にして約36％減少した，とかいった実験．
呼び出し関係グラフを作ったときに同じクラス中にあるメソッドなのに同一のクラスタには含まれないものがある，というのが面白いところ．評価としてもクラス間の依存関係なんかを使っているのは今までの単なる行ベースの方法より好感が持てる．
2004-10-11 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar]0.9.0 リリース ▲
スクリーンショットの撮りなおしとヘルプの更新が終わったので0.9.0としてリリース．
プログラムのどのGUIが変わったかでヘルプのどこを更新すればいいかという影響波及解析とかできないものか．ヘルプの保守というのが意外と難しい．
_ [hyCalendar]0.9向け機能追加 ▲
今のところ機能強化は次の通り．拡大率設定の保存情報が変わった（移行できない）ので0.9 にしてしまうことにした．
・検索ボタン「前へ移動」を追加
・期間予定の設定に「開始日からＮ日」設定を追加
・縦横別々での拡大率設定を追加．これに伴って「50〜300％」の拡大率を廃止．
・月曜始まり表示にしたとき，期間予定のカレンダー，表示セレクトカレンダーが月曜スタートになるように設定．
2004-10-12 古い日記からの変換データ [長年日記] ▲
_ すだち ▲
人からすだちをもらったので，果汁をしぼって蜂蜜を混ぜてお湯にといて飲む．けっこう蜂蜜を入れないと酸味が強い．レモンに近いといえば近いのだけど，レモンティーのかわりになるのかな？風味が違うから合わないのかな？
_ AOM Workshop ▲
The 5th Aspect-Oriented Modeling WorkshopIn Conjunction with UML 2004 http://www.cs.iit.edu/~oaldawud/AOM/
Models for Non-functional Aspects of Component-Based Software (NfC'04) http://www.comquad.org/nfc04
が開催されたらしいので論文チェックなリストに追加．
_ [論文]モデルの保存 ▲
UML04 ワークショップの論文がダウンロードできる．http://uml04.ci.pwr.wroc.pl/Workshop-materials.pdf
Ragnhild Van Der Straeten:Formalizing Behaviour Preserving Dependencies in UML.Proceedings of UML04, pp.71-82.
モデルの変更前と後で何を保存しているかというのを定義しましょうという話．アクセスする属性，更新する属性が同じかどうか，メソッド呼び出しでも，完全に同じメソッド呼び出し列なのか単に到達可能なだけなのか，とかを決めておいて，Dependency relation のメタクラスをサブクラス化してOCL を関連付けることで，振る舞いの保存について制約を付けているらしい．
ちらっと見ただけなので怪しいが一貫性をチェックするツールを実装しましょうみたいな話の論文も出ているよう．MDDとかの関係で流行ってるの？
_ ナイトライダー ▲
ナイトライダー シーズン１コンプリートボックスDVDが出るらしい．実は今まで出てなかったのに少しびっくり．amazonのページ
シーズン１だけで全話そろってるわけではないのでとりあえず見送り．
2004-10-15 古い日記からの変換データ [長年日記] ▲
_ ESS2004 ２日目 ▲
無事終了して帰宅．クロージング後直帰してこの時間．やっぱりもう一晩泊まるような出張日程のほうが楽かも．
全体参加者が２６０人程度だったらしいので賑やかだった．アスペクト指向ソフトウェア開発のチュートリアルは４０人程度．司会は初めてなので微妙に疲れた．発表よりは気楽だけど．
組み込み系のテスト工数の増大とかいう話は，今現在はカバレッジ向上くらいしかないような気がするけど組み込み系って電源OFF（バッテリ切れ）以外に初期化が存在しないのでパス数が発散しているようだし，アスペクトのテストも初期化タイミングはシステム開始時だけであとは状態遷移していくというので実は問題構造は似ているような似ていないような感じ．そのうち設計のパターンみたいにテストのパターンとかできるのかしら．
頭があまり働いてない気がするので後日整理してみることにする．
2004-10-17 古い日記からの変換データ [長年日記] ▲
2004-10-19 古い日記からの変換データ [長年日記] ▲
_ [work]Dominatorの検出 ▲
バイトコードの制御フローグラフ上で，条件分岐の結果がいつまで有効だといえるかをPostDominator（どちらに分岐しても必ず通過する最初の頂点）で判定するために，PostDominatorの計算を実装してみた．
アルゴリズムは悩んだが，実装が単純な繰り返し計算方法Keith D. Cooper, Timothy J. Harvey, Ken Kennedy:A Simple, Fast Dominance Algorithm.に掲載のものを使ってみた．文献自体はSoftware Practice and Experience にSubmitted となっているもの（Acceptedではないらしい）．これ自体はDominantの計算なので，PostDominantを判定するために依存関係のたどり方だけ逆向きにして適用してみた．
パフォーマンス的には最適化の余地はあるのだが，とりあえず単純な実装で動作試験にはいちおう成功しているみたい．
2004-10-21 古い日記からの変換データ [長年日記] ▲
_ [work]制御フロー解析 ▲
Java バイトコードのうち，Finally節を実装するために生成されるJSR〜RET （BASICで言うところのGOSUB〜RETURN）の処理を実装してみた．面倒だったのでとりあえずRETからすべてのJSR へ戻るようにしただけなのだが．
テストして気付いたのだが，Eclipse 3.1M2 のJava コンパイラは JSR-RET を使わない実装に変わっているのか，以前は生成されていた RET 命令が生成されなくなっていた．
ということで，今までテストデータにしていたもの（自分自身のクラスファイル）が使えなくなってしまった．新しいテストケースだけ，別に用意しないといけない．
2004-10-23 古い日記からの変換データ [長年日記] ▲
_ AspectBench ▲
AspectJ の言語をサポートしたコンパイラの別の実装としてAspectBench 1.0.0 がリリース．パフォーマンスとかを重視しているらしい．http://aspectbench.org
フロントエンドの言語拡張，バックエンドの最適化にそれぞれなんかフレームワークを使っているらしい．AspectJ ベースで言語を少し実験するとかの材料になるかも？
Sable Research Group とかも絡んでると書いてるのでパーサが SableCC でできてたりするのだろうか．色々気になるところはあるツール．
_ [Java]バージョンＩＤ ▲
Serializable なクラス（独自の例外クラス）を作ったら serialVersionUID を定義しなさいと警告が出てきた．
どうやら serialver とかいうツールで作れるらしい．
serialver -classpath クラスパス クラス名
単にメソッドとかのシグネチャから計算してるみたいだけど．リファクタリングとかしたらパッケージを移動すると値が変わってしまう（ソースコードを修正しないといけない）のかな？
_ [work]バイトコードのスタック変化 ▲
Java バイトコード上でのデータ依存関係を調べるのにスタックの変化情報が必要なのだが，BCELの org.apache.bcel.generic のパッケージサマリを見るとだいたいの情報が載っていることが判明．
抽象クラスで複数の命令の処理をまとめて書かないと，オブジェクトの種類による条件分岐がえらいことなりそうだが．
_ [論文]モデルの一貫性管理 ▲
Models for Non-functional Aspects of Component-Based Software (NfC'04) の論文を消化．
Francois Mekerke, Wolfgang Theurer, and Joel Champeau:Non-functional aspects management for craft-oriented design.利害関係者ごと（あるいは開発チームごとなど）に作成したモデルをいかに一貫性を保つかが問題となるが，そこで， Facet と Pivot という二つを使ってモデルを管理しようというもの．Facet は，システムの色々な側面を表現したもので，最終的にはプロダクトとなるもの．それぞれ，external (pivot から可視)なものとinternal (外部から不可視) なもので構成される．モデル自体は，それぞれの Facet ごとに独立な構築になるみたい．で，Pivot というのが連携用の道具で，各 Facet の external な要素間での結合として，データの流れや，成立する不変条件を記述する．
Pivot を先に作って，Facet がそれぞれ何を提供すればいいか明示してから Facet を個別に定義していくような感じなのか．
_ [論文]アスペクト指向なモデリング ▲
Aspect-Oriented Modeling Workshop の論文のうち興味を引いたもの若干をメモ．
Shin Nakajima, Tetsuo Tamai:Lightweight Formal Analysis of Aspect-Oriented Models.Aspect-Oriented Modeling Workshop 2004.
各アスペクトは，ロール同士のインタラクションとしてアスペクトを複数使ったときに正しく動くかどうか，「複数使ったときにどう動くべきか（どう重なるか）」を書いてモデルを動かしてみてチェックしましょうということになるらしい．
Mark Mahoney, Atef Bader, Tzilla Elrad:Using Aspects to Abstract and Modularize Statecharts.Aspect-Oriented Modeling Workshop 2004.
複雑なシステムのステートチャートを作るとき，直交した状態は別々のステートチャートに分離しておいて，あるステートチャートのイベントが，他のステートチャートのどのイベントとして「解釈」しうるか，という定義を付加してステートチャート間の結合を整理しようという話．
あるステートチャートでのイベント発生に他のステートの遷移を設定するというのはAspectJ の before/after の考え方にも近い概念だ，と言っている．
ステートチャート間のイベント連動をどこに書くかというのが問題のような気はするが，それ以外はわりとシンプルな感じ．
Alexis Muller:Reusing functional aspects: from composition to parameterization.Aspect-Oriented Modeling Workshop 2004.
コンポーネントの再利用のためには，関連しあったクラス群をまとめてビューとして扱うのがよい，ということでビューというのがどうあればよいか，メタモデルを定義している．
Subject-Oriented など従来のアプローチでは，再利用を狙ってシステムとは独立にモデルの設計などを行うときにシステムごとの名前の変化などが扱いづらいので，型やメソッド名のパラメータを使って制御するタイプの手法を使って作ったビューを適用していくのが良さそうだ，と言っている．
2004-10-26 古い日記からの変換データ [長年日記] ▲
_ [work]例外ハンドラのデータ依存解析 ▲
OOPSLA 開催でまた論文リストが増えるぞっと思いながらコード書きが続く．
例外ハンドラ（catch ブロック，finally ブロック）へはどこから例外で移動してくるか分からないので，実はデータフローが決定できない．Checked Exception や Null Pointer Exception 系などは絞れないことはないのだが，あまり効果として嬉しくないので，とりあえず例外ハンドラの先頭（Handler Entry 仮頂点）ですべてのローカル変数を初期化したとみなしてデータ依存関係を整理することにした．
_ [Java]enum ▲
enum 型が使いたくなったので Eclipse 3.1M2 で使えたのかなと思って試してみたら，まだ対応してなかった．Eclipse 3.1M2 のリリースノート
構文的には通るが型としては認識できないみたい．
2004-10-27 古い日記からの変換データ [長年日記] ▲
_ [work]エイリアス解析の価値の謎 ▲
エイリアス識別付きのフィールド間データ依存関係の解析を実装しようとしてこける．エイリアス情報が変わるとデータフローが変わってデータフローが変わるとエイリアスの流れも変わるんでは…．という疑問があるし，あまり効果的な解析方法がない．
Flow Sensitive にエイリアスを解析しようとするとメソッド呼び出し順序などが必要になってくるのだが，外部へのメソッド呼び出し時に何が起きるかは（多態性の都合で）決定できないので，外部からメソッド呼び出しを受ける可能性を考えると非現実的．
結局手抜きな実装としては，自分のメソッド内で作ったオブジェクトに対してだけ，外部から参照可能なフィールドに代入されるかメソッドの引数で外へ出て行くまでエイリアスを識別しておくということになるのだろうか．ここでも「外部から参照可能な」が曲者で，Java の private フィールドって自分自身の他のインスタンス（this.class.new したもの）からは参照できてしまう．
こうなると，ローカル変数に代入されているものだけが対象となるわけで，エイリアス解析で解決できる問題がすごく狭いような気がしてきた．
this と，それ以外（thisあるいは他のインスタンスを指す参照）はいちおう区別しておいたほうが良さそうに思えるが，それ以外の場面ではあまり真面目にエイリアス解析しないほうが幸せっぽい気がしてきた．
