netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2003-10-23 古い日記からの変換データ ▲
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 など従来のアプローチでは，再利用を狙ってシステムとは独立にモデルの設計などを行うときにシステムごとの名前の変化などが扱いづらいので，型やメソッド名のパラメータを使って制御するタイプの手法を使って作ったビューを適用していくのが良さそうだ，と言っている．
2005-10-23 ▲
_ wiki（非公開のもの）の整備とか ▲
ちょっとグループで作業する都合で，wikiを設置したりページのテンプレートを整えたりした．
pukiwiki のコメント欄が１行だと長い文が入力しにくい，ということでcomment.inc.php のinputタグ生成をtextarea生成にして，コメント欄を無理やり３行の表示に改造してみた．単にタグ生成部分だけ変更すれば，入力された文字列の中の改行は無視して処理してくれるようなので，意外と変更は簡単だった．
_ 自販機のポイントカード ▲
大学近くの自動車の中古買取のお店(たぶん）のそばにあったダイドーの自販機で，カード発行とかいう見慣れないインタフェースが付いてたので，とりあえず受け取ってみた．
ダイドーのニュースリリースによれば，実は４月からやっていたキャンペーンらしくて，１本１ポイントで50ポイントから景品がもらえるらしい．缶にシール貼るキャンペーンと違って，どの賞品でも良いという違いはあるけど，そのかわり自販機での購入に限定され，店頭でのケース買いとかは対象にならない．どのくらいの人がポイントためられるのかな？
2006-10-23 ▲
_ [論文] イベントを記録／再生してデバッグ ▲
Alessandro Orso, Shrinivas Joshi, Martin Burger, Andreas Zeller: Isolating Relevant Component Interactions with JINSI.
Proceedings of WODA 2006, pp.3-9.
プログラムの動作が失敗する場合に，コンポーネントレベルでのイベントを記録しておいて後から再生することで，デバッグを行う環境を作ろうと提案している．
注目する特定のコンポーネントに対して「境界」を越えるコンストラクタ呼び出し，メソッド呼び出しと戻り，フィールド操作を記録する．このときに，引数や外部メソッドからの戻り値などのプリミティブは全部値まで覚えておく，また，境界を越えない内部呼び出しなんかは無視するみたい．
で，その対象コンポーネントの周辺をすべてモックに差し替え，記録した外部とのやりとりを再生すれば，そのコンポーネントだけを独立してテストできる．この「再生」処理は完全に自動化できるので，delta-debuggingを適用し，問題が発生するような短いメソッド呼び出し列を探索する．
観測するのはあくまで境界を出入りする呼び出しなどだけなので，観測対象はコンポーネント単独でなく，特定のサブシステムなどの単位でも利用できる，とも述べている．一方で，外部からのメソッド呼び出し回数などは減らせるが，そのコンポーネント内部の処理量は減らせない（処理が多いコンポーネントのデバッグはこれでも大変かもしれない），リアルタイム系の処理は再現できない，といった弱点はあるし，コンポーネントの観測境界をどう適切に設置するかというのも難しいかもしれない．
個人的にはかなり良い印象のアプローチで，「プログラムの実行履歴データを全部保存するぞ」というomniscent debuggingよりはだいぶ現実的だという印象がある．それに，彼らが過去に提案している delta-debugging の制約（入力がプログラムから制御可能で，結果の成功失敗が判定可能とか）をうまく満たせるような状況に持ち込んでるのは，やり方としてうまいと思う．
気になる弱点(?)は，特定のコンポーネントを怪しいとにらんで動作記録をとったときに，「なぜその入力が来たのか」を調べようとすると，境界を再設定してデータ取り直しという，大変な作業が待っていそう，というあたり．
今後どうなるかはけっこう楽しみ．
