netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-06-06 古い日記からの変換データ [長年日記] ▲
_ Calendar ▲
hyCalendar 0.7.7 リリース．機能を実装してから，ヘルプ更新するのが遅れていた．
"|仕事|" とか "*重要*" とか，特定のマーク文字でくくった文字列の出現に対して，色やスタイルを指定できる．使うかどうかは好みに依存．
_ 論文 ▲
ICSE 2004 Technical Papers, Requirements から．
Elisa Baniassad and Siobh\acute{a}n Clarke:Theme: An Approach for Aspect-Oriented Analysis and Design.Proceedings of ICSE 2004, pp.158-167.
アスペクトを探すときは，それらがどの部分を横断しているかを早い段階で見つけておいたほうが望ましい，ということで要求分析段階の話．AOREやConcept Graphing などが関連研究．アクションビューというものを作って，要求内に登場するアクション間の関係をグラフ化し，アクションのうち他のアクショングループと一緒に使われないようなアクションを Base Code に分類し，複数の Base アクションに依存するような（「……するときは……する」といった）アクションをCrosscutting に分類しようという考え方が基本らしい．
システムの規模が大きくなるとアクションビューが大きくなるのでMajor Action と Minor Action に分ける，とか色々考えてはいる様子．でも，アクション間の依存関係が，イベントに対する Trigger なのか単に利用関係だけなのか，とかによってはそんな簡単に Crosscutting に分類していいのかどうか．
_ 論文 ▲
ICSE 2004 Technical Papers, Patterns and Frameworks から．
Wilhelm Hasselbring, Ralf Reussner:The Dublo Architecture Pattern for Smooth Migration ofBusiness Information Systems: An Experience Report.Proceedings of ICSE 2004, pp.117-126.
レガシーシステムから新システムへ移行するとき，レガシーシステム側のビジネスロジックにアクセスするためのAPIを付け足して新しいビジネスロジックは古いビジネスロジックを経由してデータベースなどにアクセスするというDublo (Double Logic) パターンについて説明した論文．
この手法の利点は，クライアントの移行がスムーズであること，レガシーシステムを新システムの１層として取り込めること，データベースの一貫性を保てることなどを利点として挙げている．ざっと読んだ限り，素直なアプローチという気がする．
_ Stephen M Blackburn, Perry Cheng, Kathryn S McKinley:Oil and Water? High Performance Garbage Collection in Java with MMTk.Proceedings of ICSE 2004, pp.137-146. ▲
Memory Management Toolkit は，Java ガベージコレクタの Java による実装で，モジュール性をきちんと考慮していて高い保守性が特徴だ，らしい．で，それを Jikes RVM の Watson Collector などとベンチマーク比較して，性能的にも実は勝ってるんだよーという論文．また，柔軟性なんかの面でも勝利しているから，すごくがんばったら MMTk を上回るようなモノリシックなGCを作れるかもしれないが，MMTk は保守性・柔軟性を保持して，かつ良い性能を発揮しているので好ましいだろう，ということになる．
JavaでGC書いても十分高速だ，というのがわりと意外だったりする．コンパイラとかその辺の進歩の影響？
2004-06-05 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
L. C. Briand, Y. Labiche, Y. Wang:Using Simulation to Empirically Investigate Test Coverage Criteria Based on StatechartProceedings of ICSE 2004, pp.86-95.
テストケースの選択として，ステートチャートのすべての遷移(AT)，遷移のペア(ATP)，遷移木のすべてのパス(TT)，すべての述語(FP)，のどれを100％カバーするようにテストケースを選んだらコスト的に良いだろうか，というシミュレーションベースの比較．結果としては，ATは不十分で，ATP，FPはコストは高いが，バグ発見には効果的だったらしい．
TTは，プロトコルテストなどには効果的らしいが，常に効果的とは限らず，ツリーの中に，非現実的なパスが含まれていないことなどが重要らしい．データフローに基づくブランチ選択のようなヒューリスティックが必要かもしれない，という感じで結ばれている．
_ 論文 ▲
Wee Kheng Leow, Siau Cheng Khoo, and Yi Sun:Automated Generation of Test Programs FromClosed Specifications of Classes and Test Cases.Proceedings of ICSE 2004, pp.96-105.
テストケースの生成話．入出力の仕様などから，Java クラスの単体テストコードのようなものを生成したりする．オブジェクトを生成した状態から，状態変化メソッドを適用していって目標の条件に到達する，という経路探索みたいな形になるらしい．
アプローチとしては面白いと思うのだが，Closed Specification を準備する手間というのが曲者に思える．テストケースを書こうとして始めて仕様の穴に気づく，といった状態だとテスト生成もうまくいかない気がする．
_ 論文 ▲
Jennifer Black, Emanuel Melachrinoudis, David Kaeli:Bi-Criteria Models for All-Uses Test Suite Reduction.Proceedings of ICSE 2004, pp.106-115.
プログラム内の define-use 関係(DUA) の情報を使って発見するエラー数が同じだがテストケースの数だけ減らす，といった計算を行うモデル提案．手法についてはあまりよく理解していないが，どのテストケースが，どれだけバグを検出していてどれだけ DUA をカバーしているかという情報が必要で，なんかコストが高そうな印象．
_ 論文 ▲
ICSE 2004 Doctoral paper から拾い読みの続き．
Michael J. Pacione:Software Visualisation for Object-Oriented Program Comprehension.Proceedings of ICSE 2004, pp.63-65.
ソフトウェア可視化の研究．最近流行ってる？抽象度をレベル分けしていて，コードレベル，オブジェクト内部の動作，メソッド単位（オブジェクト間），オブジェクトまたはクラス単位，アーキテクチャ（サブシステム）レベル，システムレベルといった感じで分けている．で，抽象度レベルと，構造・振る舞いといったどの側面に興味があるかでシステムを自由に見ていけるようなシステムを作ろう，といったところか．どんな情報やシステムがこの考えにマッチするか，といった点については色々考える余地があるみたい．
_ 論文 ▲
Jennifer Tenzer:Improving UML design tools by formal games.Proceedings of ICSE 2004, pp.75-77.
UML の設計の検証を，Refuter と Verifier のゲーム（ルールに則った操作の連続）として実行しようというアイディア．基本はモデルチェックの話らしい．この種の研究がどのくらい価値があるのかよくわかってないのだが．
ちなみに，メタ操作（モデル変更）は cheat らしい．cheat した結果，verifier 側に勝ち目が出てくるというのならそれはいい変更だったりするのかもしれない．
_ 論文 ▲
Pakorn Waewsawangwong:A Constraint Architectural Description Approach toSelf-Organising Component-Based Software Systems.Proceedings of ICSE 2004, pp.81-83.
architecture description language などで書かれたコンポーネントが，与えられた制約を満たすように自分たちで reconfigure する，という環境の研究．実行時に後から制約を追加したりとかも考えているみたい．やっぱりこれからはコンポーネント単位でコーディングする時代が来るのかしら．
_ 論文 ▲
ICSE 2004 Doctoral paper をいくつか拾い読み．
Hridesh Rajan:One More Step in the Direction of Modularized Integration Concerns.Proceedings of ICSE2004, pp.36-38.
コンポーネントの結合（イベントの通知など）がコンポーネント本来の機能とくっついて保守性とかに悪影響を与えるのが嫌なのでアスペクトを使って書きましょう，という話のよう．Association Aspect に近い話のような気がしなくもない．
_ 論文 ▲
James A. Jones:Fault Localization using Visualization of Test Information.Proceedings of ICSE2004, pp.54-56.
テスト結果などから，失敗した原因の「疑わしい」文を素早く見つける方法についての研究．ある文 s について，その文を実行したテストケースのうち成功したものの割合によって s を着色したり（失敗したテストケースが多いと赤に近づくといった感じ），全体テストケースのうちどのくらいのテストケースでその文が実行されたかによって文の輝度を設定したり（毎回実行されるような文が一番目立つ），といったものらしい．
アイディアとしてはけっこう好きかも．最終的なソースコードがどんな見た目になるのか，一度見てみたい気はする．
2004-06-04 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
ICSE2004 Keynote その２．
Jonathan Barker, Janet Thornton:Software engineering challenges in bioinformatics.
分子生物学などの生物情報系の扱うデータ量の増加ペースなどが基本の話題のよう．
新しい種類の情報と過去の情報を組み合わせる方法，それからデータをどのように提示するか，といった問題が出てきているよ，というもの．
あまり技術的にどうこう，という話はなくて，わりとお話だけのような印象．
_ 論文 ▲
ICSE2004 Keynote.
Karl J. Lieberharr:Controlling the Complexity of Software Designs.
毎度おなじみ？というくらい聞いている気がするLaw of Demeter の Lieberharr が keynote だったらしい．
AOSD のときに聞いた話とあまり変わらず，Law of Demeter の有効性の話がメイン．Law of Demeter for Concerns （LoDC）はLoD をさらに限定したもので，LoD の「友達としか話しちゃ駄目だよ」ルールの「友達」が「自分が所有する，直接作る，引数でもらうオブジェクト」の中から同じ関心事に関わるものだけに限定するというもの．
LoDC に従うプログラムは変更に強くなる……らしい．使ったことないからいまいち実感がないのだが．
LoDC に従うとアスペクトの機能というのは少し制限されそうだが，アスペクトの恩恵の大部分は得られる，という態度．
アスペクト関係での未解決の問題としては，アスペクトの能力の制御以外には，アスペクト間の相互作用，リソース消費の予測などがあがっている．
この keynote では adaptation dilemma と呼んでいる「ベースのプログラムが変わったけど，アスペクトが作用する要素は正しいままかどうかテストする必要がある」という問題は，Fragile Code Problem とほぼ同様のことを指摘している．
Semantic JoinPoint と絡んで来年の AOSD あたりで大きな話題になるかなー？と勝手に予想している．
_ 論文 ▲
授業の準備があらかた片付いたので，たまっていた論文の消化．
Mark Weiser: Programmers Use Slices When Debugging.Communications of ACM, Vol.25, No.7, pp.446-452, July 1982.
デバッグ作業において，開発者は変数がどこから来たかを追っていく（プログラムスライスをたどっていく）作業を行っているのかどうか，またプログラムを理解するときにはプログラム中の連続したコード単位で理解しているかどうか，ということを実験しようという論文．
開発者がモジュールの構造とかをきちんと把握していなくても，プログラムスライスのような，モジュールにちらばったコード群を取り出してきて作業を行っている，という実験結果を示している．
プログラムスライシングの手法をきちんと理解することがソフトウェアの保守やデバッグ作業に役立つだろう，また，もしかしたらデバッグ能力などの向上にも役立つかもしれない，と結んでいる．
2004-06-02 古い日記からの変換データ [長年日記] ▲
_ AspectJ ▲
AspectJ のサイトがなぜ shizuoka.ac.jp から見られているのだろう……と思っていたら研究室の輪講資料の参考サイトとしてリンクされていたらしい．アクセス解析から判明．
さすがに直接リンクするのも悪いような気がするので置いておくが，輪講用の情報が外部から直接アクセスできていいのかしら……．
_ 授業 ▲
院生相手のソフトウェア開発論にて，Eclipse プラグインもろもろの話をする．今回の課題は，プラグインを作るとしたらどうするか考える，またはプラグインを適当に使ってみて報告．次回は JUnit なので話は盛りだくさん……かも？
授業で出す都合で集めた資料にあった Eclipse 関連ネタとしては，My Own Shopping Cart プラグイン．http://www.myownshoppingcart.com/index.html
通称 Amazon perspective を追加して，Eclipse から商品の検索・ショッピングができる．"Check Out" を選ぶと，ブラウザを立ち上げて Amazon.com の決済直前（カートの中身確認してるところ）に移動する．Eclipse プラグインは IRC，Instant Messanger，ほか色々あるようなので，「何でも Emacs で」のノリに近い．GUI が許されるぶん範囲も広いし．
この種の Entertainment カテゴリ(www.eclipse-plugins.info分類)のプラグインは Eclipse 3.0M8，M9 あたりの新しい stable でもちゃんと動くとテストされてたりするので，こういう人たちの熱意ってすごいんだろうなー．
2004-05-30 古い日記からの変換データ [長年日記] ▲
_ Eclipse ▲
いまさら気づいたが，Eclipse のダイアログは，ときどき文章量のほうがダイアログサイズより多いので省略されてしまっている場合があるみたい．
Java ビルド・パスの追加における[変数の追加] は，実は[拡張...]を選んで変数が指しているフォルダから先のJAR ファイル選択をするのが正しい使い方らしい．（ラベルにメッセージが出ていたのだが， "..." で 省略されていて気づかなかった）
[外部 JAR の追加] はディレクトリによる絶対パスあるいはプロジェクト内部の相対パスによる追加で，ECLIPSE_HOME などの変数を使った可変クラスパスの追加は [変数の追加] らしい．なんか言葉の使い方としていけてないような気がする．変数というより「可変パスの追加」なのかもしれない．（.classpath ファイル中では，それぞれ kind="lib" と kind="var" として表記される）
_ JUnit ▲
授業で教える都合で，とりあえず勉強しながら使ってみる．何となく「達人プログラマー」やXP本で話は聞いているのでテストケースを作ってみる．
Eclipse から使うと，クラスを右クリックして[新規]-[その他...] [JUnit/TestCase] でそのクラスのテスト用クラスが生成される．すごく便利．[実行...] [JUnit] を選ぶと「パッケージ内のすべてのテストケースを実行」とか選べて，JUnit View からボタン１つでテスト実行した結果を見られる．これは，これから Java でコード書くときはJUnit 使っていこうかな，と思ってしまうくらい快適．さらっとテストケースと実装を書いてしまう．
いちおう学生にはテストケースを渡してコードを書いてみるとかやらせないといけないので，クラスのコードを抜いてかわりに // TODO タスク・タグを埋め込んだ状態にしておく．
