netail.net
自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.
最近のお知らせ (古いものはこちら)
2003-11-28 古い日記からの変換データ ▲
_ Adobe ▲
Adobe Acrobat Developer Workshop in Osaka はAcrobat で PDF にスクリプト埋め込んだりプラグイン作ったりという話だった.
意図して作った PDF をいじるだけならわりと簡単そうで,今のところそういう要求はないが,PDF に直接記入されたデータに対して計算を行って結果を PDF 上に出力できることを考えると,それなりに遊べそうなツールではある.
一番びっくりしたのは,検索機能が Acrobat 6 から複数ファイルから探せるようになっていたことだけど.pdftotext を通してから grep かけるなんてことはしなくてよかったらしい.
ちなみに,アンケートに答えたら Adobe ロゴ入りペンケース&ペンをもらえた.
2004-11-28 古い日記からの変換データ ▲
_ [論文]コンポーネントの使い方抽出 ▲
John Whaley, Michael C. Martin, Monica S. Lam:Automatic Extraction of Object-Oriented Component Interfaces.Proceedings of ISSTA 2002, pp.218-228.
コンポーネントの状態遷移を起こすようなメソッドを識別し使い方をテストケースの実行履歴や静的解析結果から発見するような方法.
静的解析では,・どのメソッドがどのフィールドに依存しているか・例外を投げるような条件を調べておき,実行履歴を解析した結果からどのようなメソッド呼び出し順序が行われているかを出力する.
フィールドごとに状態遷移を分割してしまうことで,状態遷移を簡略化するところがポイントっぽい.
_ [論文]アスペクト指向設計な話 ▲
Charles Zhang, Hans-Arno Jacobsen:Resolving Feature Convolution in Middleware Systems.Proceedings of OOPSLA 2004, pp.188-205.
ミドルウェアの設計において,縦方向(階層的)な設計に加えて横方向の分解(horizontal decomposition)を導入しましょう,という話.
モジュールの階層的な機能分解は今までやってきたが,ミドルウェアはけっこう色々な機能を含んでいて,モジュールの明確な境界ができないままにコードがあちこちに分散する.主な提案事項は次の通り.
1. アスペクトは,システムの主要な機能に対して相対的に定義されることを認識すること.
たとえば,分散アプリケーションでは「ローカル呼び出しの最適化」が横断的関心事となるが,普通のアプリケーションでは逆に透過的なリモート呼び出しのほうが横断的関心事となる.
2. 主要な機能については,凝集度が高くなるように分解を行うこと.3. アスペクトは,機能分解の結果を横断したものだけにする.(たとえば,横断してなければクラスでよい)4. クラスで構成するアーキテクチャを安定した形に保つ.(これは fragile-code problem を防ぐため)5. リファクタリングで凝集度などを高く保つこと.
基本的には,AspectJ でのコーディングを強く意識した提案なのでNECの野田さんたちのモデリング方向とはちょっと違う.
core - aspect,aspect - aspect の関係を整理するのにマトリクスを作っているが,使い方は不明.ただ,誰が誰を crosscut しているかを管理しておくのは重要だということは何となく分かる.
2006-11-28 ▲
_ [論文] ArgoUML の解析が流行中? ▲
今年5月のMSR 2006 の予稿集をいくらか調べていたら,多くの論文が ArgoUML を解析対象にしているようです.みんなで同じものを相手にすれば比較しやすいので,ありがたいことですが…….
さすがに1つだけだと validity の都合もあるので,次の文献では,ArgoUML と Columbia,jEditの3つを解析対象にしてました.Columbia も別の論文で名前を見たことがあるので,やはり解析実験の対象として手ごろなようです.
Sunghun Kim, Kai Pan, E. James Whitehead, Jr.: Micro Pattern Evolution. MSR 2006, pp.40-46.
この論文は,クラスがどのマイクロパターン(提案した人のサイトはこちら)に該当するかをバージョンごとにチェックしています.コードが変更された結果,クラスのパターンがどう変化したか(あるいはそのパターンのままか)という情報と,バグの混入しやすさの関連を調べてます.OOPSLA論文のパターンカタログの定義には入ってない Limited Self というのが1つ無造作に加わってるのは謎です.
変更するコードによって,(この人が定義している言葉での)バグの混入しやすさには偏りがあるという点は,けっこう面白いと思います.
_ はやし [MSR Challenge のお題に含まれているからではないでしょうか? >ArgoUML See also: ht..]
_ いしお [そうみたいですね.ご指摘ありがとうございます. 皆で同じものを相手にすれば,デモも議論もやりやすいでしょうし,面白い..]