netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2003-10-15 古い日記からの変換データ [長年日記] ▲
_ Neverbird ▲
JBoss を広めようとしている Neverbird の人からもAOP のキーワードでリンクされていたことに気付いた.developerWorks や OO シンポに関する記事と同列.でも「その他」かぁ.
Neverbird の人々,かなり情報収集量が多い.参考にさせてもらいつつ,もうちょっと頑張ろう.http://neverbird.sourceforge.jp/
_ カレンダー ▲
スケジューラというほうが正しいのかなぁ.ある程度,形になってきたのでいちおう公開してみる.hyCalendar 公開ページ
_ Delphi ▲
Delphi から Windows API を叩くための資料を探していて,サイトを発見.ソースコードを積極的に掲載しているので,すぐ使える断片が手に入って嬉しい.http://halbow.cool.ne.jp/top.html
2003-10-09 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Stephan Herrmann:Object Teams: Improving Modularityfor Crosscutting CollaborationsNet.Object Days 2002
を読んだ.Object Team というモジュール単位を導入している.Aspectual Collaboration に近い概念(?)で,Team class 側は「こんな参加者がいるよー」と宣言して,個々のクラス側は「私は Subscriber 役をやります,メソッド xxx は私のこのメソッドに delegate してね」と宣言する.依存関係が AOP の場合と逆.
で,クラス側が「この Team を active にしてブロックを実行」というようにコントロールできるみたいではある.登場人物となるオブジェクトが全員揃った状態でオブジェクト間の関係を明示しながらプログラムを書くことになりそうなので,1:n あるいは m:n のオブジェクト対応をどう扱うのか,とかちょっと気になる.
個人的には,アスペクトと併用してTeam オブジェクト記述→ Team に参加するオブジェクト記述→ オブジェクト間のルールをアスペクトで記述なんてやってみたい.
アプローチ自体は嫌いじゃないのだけど,プログラム言語を作ったことで,どのくらい複雑さが低減できるのか,とか抽象度が高い記述が可能なのか,とか色々議論する余地は多そう.
すべての振る舞いを Object Team で書いたらどうなるか,っていうのを見てみたいところ.
_ 論文 ▲
以前読んだ論文の読み直し.Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programming
Object Oriented Design Language (OODL) という形式記述言語とその検証系を説明した論文.オブジェクトがやり取りするメッセージやそれに伴う状態遷移を記述して,オブジェクト間の依存関係の循環や,結合度,client/server 関係といったものを調べる.しかし,ソースコードとの対応関係の確認はできない.
2003-10-08 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
The Concept of Dynamic AnalysisESEC/FSE 99, Thomas Ball
頻繁に動作している部分とそうでない部分を明示することでプログラムの分解に役立てる Frequency Spectrum Analysis とテストケースごとにどのあたりが実行されるかを見ることでカバレッジ向上を行う Coverage Concept Analysis を提案している論文.
Introduction での静的解析と動的解析の比較を行っていて,静的解析はプログラムが特定の性質を持つかどうかを判定できるが,動的解析は特定の性質の違反を検出することができる.動的解析は「入力に注目した解析」で静的解析は「プログラムに注目した解析」だとしている.また,これらは,完全性,スコープ,正確性の違いだとしている.
完全性において,動的解析はプログラムを十分な回数を実行する必要があり,静的解析ではありえない実行系列などを排除する必要がある.
スコープについて,静的解析はプログラム中の位置による制約を受けやすい.特に遠距離(異なるモジュール,時間的距離)の依存関係を解析するのは非効率的である場合もある.
正確性については,静的解析は解析を終わらせるために情報の抽象化(ある種の情報損失)が必要となる.動的解析では,プログラム実行のうち必要なドメインにのみ注目することでコストを削減することが容易である.
_ 論文 ▲
久々にプログラムスライス関係の論文を読む.
Paolo Tonella:Using a Concept Lattice of Decomposition Slices for Program Understanding and Impact Analysis,IEEE Transactions on Software Engineering, Vol.29, No.6, pp.495-509, June (2003)
ある変数に対する計算処理を Decomposition Slice と呼ぶが,Decomposition Slice Graph ではなく Lattice として構造化し複数の変数で共通した計算部分をくくりだす.
影響波及解析自体は,Lattice を使ってチェックされる.ただの Forward Slice と違い,影響を受ける文だけでなく,何の計算に影響を与えるかを示せる点らしい.ちょっと怪しい気もするが.文を「計算」という単位にグループ化できることがLattice の強みらしい.
共有されている部分が Decomposition Slice でない場合(たまたま同一の制御構造などを共有している場合)を,弱い干渉 (Weak Interference) と定義して実験している点が興味深いと言えなくはない.
静的解析で,どこまで正確に解析できるかとか,その解析コストがどの程度か,とかいうあたりの議論がないような気はするが,それにしても,Concept Lattice をちゃんと使っている論文は珍しい.
2003-10-06 古い日記からの変換データ [長年日記] ▲
_ EJB ▲
コンポーネントの precondition や postcondition のことを考えながら EJB のことを調べていたのだが,EJB では synchronized キーワードやスレッド生成を禁止してコンテナが全部管理するということになっているらしい.同時性制御に関しては,セッション Bean ,エンティティ Bean はデフォルトではリエントラントではない(あるトランザクションコンテキスト内部で マルチスレッドなアクセスをしてくる可能性と 区別できないため).そのため,コンポーネント間のループバックは禁止されている.ループバック禁止がプログラムに与える制約はどの程度だろう?
メッセージ駆動型 Bean は,複数インスタンスを生成することで複数メッセージを同時に並行して処理するらしい.