netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
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-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-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-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-07 古い日記からの変換データ [長年日記] ▲
_ [論文]ソースコード編集作業の分析 ▲
aosd-discuss ML で紹介されていた論文をちらっと読んでみる．
Martin P. Robillard, Gail C. Murphy:Automatically Inferring Concern Code from Program Investigation Activities.Proceedings of 18th International Conference on Automated Software Engineering, pp.225-234, October 2003.
ある concern に関係したコードを変更するとき，複数の場所に分散したコードをあちこち見たりしながら作業を進めていくのが普通なので，そのエディタの操作情報を集めていくことで（どんなソースコードを見ていったか記録することで），その作業時に必要な情報はどのあたりにあるのか，とか開発者の作業を補助しようというもの．
修正作業を，調査イベントの順序付き集合transcript E = { e1, e2, ..., en } として捉えると，イベント e = (D, c, X) はc がアクションの種類（エディタの切り替えとか検索とか）でD がエディタに表示されているメソッド，フィールドでX がアクションごとの追加情報（検索して見つけたメソッドとか）．で，検索対象として見つかったようなエレメントのほうが重みを大きくして，どれかを見ただろうという確率を計算する．
で，全イベントで１度でも閲覧された要素をリストアップして，各要素間の関係の強さを計算する．ある二つの要素について，一方を閲覧したアクションの次のアクションでもう一方を閲覧していたら，何らかの関係があるだろう，と考える．
途中の重み計算のパラメータの影響を強く受けているみたいだが，探している作業という頼りないものがベースのわりにはそれなりの結果が出ている気がする．ただ，いつからが調査でいつからがコーディングだとかいった情報がそれなりに必要？また，false positive も出てしまう（仕方がないが）．
単体で使うよりは，他と組み合わせたほうがうれしいかもしれない．スライシングとか concept analysis とか．個人的には面白いと思うけど．
プログラム変更履歴における「誰々もこの辺りを見ていたよ」という協調フィルタリングにノリとしては近いかもしれない．
_ ニュース ▲
コンピュータの埃からの有害物質の検出とかの話．
具体的数値とか載ってます．http://www.computertakeback.com/the_problem/bfr.cfm
ネタはこちら．http://nikkeibp.jp/wcs/leaf/CID/onair/jp/it/311922
部室とかで多数の PC を一度に掃除するときは少し気をつけたほうがいいかも？
_ 日記CGI ▲
国際会議があるたびに論文ネタで埋め尽くされてしまうので，やっぱりカテゴリごとの最終更新くらいは表示されるようにしようかしら．
実体データは XML なのでカテゴリ情報とかの追加は楽なのだが，そこから最新情報だけ切り出しておくのが面倒だったりする．今のところカテゴリ割り当ても何もやってないし．
_ 論文 ▲
ICSE 2004 Technical Papers, Emirical Methods より．
Parastoo Mohagheghi, Reidar Conradi, Ole M. Kili, Henrik Schwarz:An Empirical Study of Software Reuse vs. Defect-Density and Stability.Proceedings of ICSE 2004, pp.282-291.
ソフトウェアの再利用は品質向上に役立つのか？という仮説に対する実験論文．数値の材料としては defect-density （コード量に対する問題の個数）を使う．
１社（Ericsson）のプロジェクトデータなのでexternal validity としては注意が必要だが，この手の実験データを出してる論文は少ないので比較しようがない気がする．
Accept された仮説:再利用コンポーネントは，non-reused コンポーネントと比べて低い defect-density となる．
Reject された仮設:再利用コンポーネントの defect-density はnon-reused コンポーネントと同じである．
non-reused コンポーネントについて，欠陥の個数と，コンポーネントのサイズは関係しない．
再利用コンポーネントとnon-reused コンポーネントは同じように変更される．
再利用コンポーネントのほうがnon-reused コンポーネントよりも変更される．
棄却できなかった仮説:すべてのコンポーネントについて，欠陥の個数と，コンポーネントのサイズは関連がない．
再利用されたコンポーネントについて，欠陥の個数と，コンポーネントのサイズは関連がない．
defect-density とコンポーネントのサイズは関連がない．（すべてのコンポーネントについての場合でも， また再利用コンポーネントに限った場合でも， non-reused に限った場合でも棄却できない）
_ 論文 ▲
ICSE 2004 Technical Papers, Unified Modeling Language より．
Tewfik Ziadi, Loic Helouet, Jean Marc Jezequel:Revisiting Statechart Synthesis with an Algebraic Approach.Proceedings of ICSE 2004, pp.242-
UML 2.0 シーケンス図からステートチャートを合成しようという試み．各オブジェクトに注目して，メッセージの送受信をイベントとみなして状態遷移が起こると考える．で，シナリオごとに生成したステートチャートを合成して大きなステートチャートを構成する．各シナリオの合成したシナリオ（シーケンス図を含んだシーケンス図）が記述できるようになったことや，ループ記述などができるようになったことが大きいらしい．
でもシーケンス図以外からなら（テキストなどで）合成はできたような気がするのだが……．新規性というか，ネタとしての新しさはあんまり感じられないが，実際にアルゴリズムを明示してがんばっているのはかなり偉いかも．
_ 論文 ▲
ICSE 2004 Technical Papers, Verification より．
Dimitra Giannakopoulou, Corina S. Pasareanu, Jamieson M. Cobleigh:Assume-guarantee Verification of Source Code with Design-Level Assumptions.Proceedings of ICSE 2004, p.211-220.
いわゆるモデルチェック手法．状態の爆発を防ぐために，Assume-guarantee 手法というのを用いている．具体的には，＜Ａ＞ Ｍ ＜Ｐ＞ という３項組で，モジュールＭが動作している環境で，仮定Ａが成立しているときＰが成立するのであれば式全体が true になる．で，二つ部品があるとき＜Ａ＞Ｍ1＜Ｐ＞＜true＞Ｍ2＜Ａ＞が両方とも成立しているのであれば＜true＞Ｍ1 + Ｍ2＜Ｐ＞ が成立する．確認したいプロパティＰが成立するかどうかはＭ1とＭ2についてそれぞれモデルチェックを行えばよいので問題の規模を小さくすることができる．途中の＜Ａ＞をうまく作れたら良い．
設計時は Labelled Transition System としてモデル構築して，実装時は，Ｍ1とＭ2に対応するコンポーネントを構築したら，メソッド単位の呼び出し監視とかを使って本当に条件を満たしているかどうかをテストする．
いちおう（１個だけ）実験もしていて，全体を検査するよりは分割しているほうが明らかにコスト的に優位に立っている．
アイディアとしては，モジュール単位での境界を置くタイプだが仮定Ａの作り方次第では，クラス単位などよりも自由な分割ができそうなので面白いかもしれない．
_ 論文 ▲
ICSE 2004 Technical Papers, Quality of Service より．
Eric Wohlstadter, Stefan Tai, Thomas Mikalsen, Isabelle Rouvelleou, and Premkumar Devanbu:GlueQoS: Middleware to Sweeten Quality-of-Service Policy Interactions.Proceedings of ICSE 2004, pp.189-199.
１つの Web サービスが１つのコンポーネントとみなせるようなサービス指向の環境下で，コンポーネント間でのQoS ポリシーの制御を行う手法．
基本的には，各コンポーネントごとに，サービスに関する述語（cpu_load ＜ 0.5 など）を記述して，ポリシーを呼び出す段階でマッチングを取ってコンポーネント間でのやり取りを行っても大丈夫かどうかをチェックする．
基本的にはコンポーネントと QoS 記述は分離しておくべきだという立場．QoS をサーバで集中管理するのは現実的でないので（今後分散環境での Web サービスが主流となると考えると），各コンポーネントが「自分はこういうポリシーだ」と持っている情報を交換できるようなミドルウェアでの実現となっている．
2004-06-08 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
ICSE 2004 Technical Pepers, Testing II より．
Saurabh Sinha, Alessandro Orso, Mary Jean Harrold:Automated Support for Development, Maintenance, and Testingin the Presence of Implicit Control Flow.Proceedings of ICSE 2004, pp.336-345.
例外による実行パスを考慮した作業サポートツールの実験．手法については interprocedural cfg を使ったとか，簡単に触れられるだけで終わっている．
到達不可能な catch ブロックとか，throw するメソッドから catch までが離れているとか，そういう問題を分析しようというのが目的のように見える．
実験結果を見ると，throw-catch ペアごとのカバレッジなんかは実はけっこう低いのでテストをサポートするのは重要そう．
ただ，例外まわりのパスは非常に数が多くなるので難しいような気はするけど．throw 文で明示的に投げるものだけが対象だからいいといえばいいのか．
_ 論文 ▲
ICSE 2004 Technical Pepers, Testing II より．
Dirk Beyer, Adam J. Chlipala, Rupak Majumdar:Generating Tests from Counterexamples.
Ｃ言語のモデルチェッカ．プログラムの制御フローオートマトンを構築し，プログラムの各文について，その文に到達するために通過する必要がある制御文の条件式を順番に取得していって，それらを満たすようなテストデータを生成する．到達不可能なデッドコードの検出もできる．
テスト自動化ツールなので，無限ループなどに陥っていつまで経っても到達しないようならタイムアウトするとか，工夫はしているよう．
あまり大きなプログラムになってくると扱いきれないみたい．また，この論文執筆時点では再帰呼び出しが扱えないといった弱点もあるみたい．
_ 論文 ▲
ICSE 2004 Technical Papers, Feature-Based Software Engineering より．
Wei Zhao, Lu Zhang, Yin Liu, Jisau Sun, Fuqing Yang:SNIAFL: Towards a Static Non-Interactive Approach to Feature Location.Proceedings of ICSE 2004, pp.293-303.
ソースコードのどの部分がどの機能を実装しているか，というtraceability の回復に IR 手法とBRCG(ブランチ保存コールグラフ）を使うというもの．
最初に，feature ごとの説明ドキュメントをベクタ空間モデルにマップして，各関数から各 feature への類似度を計算する．で，各 feature ごとに，類似度の高い関数を順番に並べて，類似度に一番格差のあるところ（d[i]-d[i+1] が最大となるi）までの関数群だけを取り出して，その feature の specific function とする．
で，ブランチ関係を保存したコールグラフを使って，specific function を呼び出すようなブランチだけを残してコールグラフの枝刈りをして，relevant function を取り出す．
そして，relevant function として得られた関数のうち，単一の feature にのみ関係しているようなものだけを最終的な specific function とする．おまけとして，BRCG から，feature ごとの擬似的な実行トレースを生成する．
単純な IR 手法や，テストケースの実行を分析する dynamic approach と比べて優れた結果となる．また，擬似的な実行のトレースを出力することによって，dynamic approach のような開発者が準備しないような特殊なテストケースも生成できる．（ただし効率はそんなによくない）
specific function の発見については，この手法が85％に対して，dynamic approach のほうが95％と高い結果を出しているが，静的解析だけでも85％は正しい結果が出たというのはすごいといえばすごい．
2004-06-09 古い日記からの変換データ [長年日記] ▲
_ 特許 ▲
マイクロソフトがTODOリストの特許取得．特許の内容よりも，TODOリストが「やることリスト」と書かれていたことにちょっとショック．http://www.itmedia.co.jp/news/articles/0406/09/news010.html 特許の原文． 特許の内容をちらっと見た限りでは，Eclipse のTODOリスト＋Java タスクタグがやばそうな感じ．コンパイルエラーの赤線表示＆タスク表示ってVisual J++ の頃からあるものだし．当時はあまり目立たなかったような気がするけど．_ 論文 ▲
ICSE 2004 Technical Papers, Decentralized Systems より．
Nathan D. Ryan, Alexander L. Wolf:Using Event-Based Translation to Support Dynamic Protocol Evolution.
プロトコルからメッセージへと変換するようなトランスレータをプロトコルの状態機械としての仕様から生成してプロトコルでの一連の対話からイベントを生成，イベントからまた対応するプロトコルに変換する，というように「イベント」概念を挿むことでプロトコル間の相互変換を行おう，という研究っぽい．
プロトコルとイベントの相互変換というのは，単なるネットワークプロトコル以外にも適用できるし，異なるプロトコルをしゃべるコンポーネントをイベントでつなぐ以外に，終端がイベントドリブンで真ん中をネットワークでつなぐとか，色々使い道はある．Conceptualの対応が取れないとだめだが．
まだ formalize とかされているわけではなく，何か特別新しいという感じはしない．この先の発展し方次第だろうか．
_ 授業 ▲
JUnit with Eclipse な授業が無事終了．
Eclipse プラグインを探してみて〜という課題を出した結果，SimScan とかいうコード類似部分（コードクローン）検出ツールとか，その他，いくつか微妙なものがレポートとして提出されていた．
上記の結果なども含めて，授業資料などはこちら．http://sel.ist.osaka-u.ac.jp/~t-isio/sd2004/
ベース資料は，http://www.aptest.com/resources.html達人プログラマー（The Pragmatic Programmer），XP本，オブジェクト指向入門（MeyerのEiffel本），など．ちょうどタイムリーな記事なんかもあったりして．http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040531/145101/
_ 論文 ▲
ICSE 2004 Technical Papers, Process and Project Management より．
Peter Manhart, Kurt Schneider:Breaking the Ice for Agile Development of Embedded Software:An Industry Experience Report.Proceedings of ICSE 2004, pp.378-386.
組み込み系のソフトウェア開発にアジャイル系のアプローチ（主に単体テスト自動化）を取り込んでみよう，という話．GQM パラダイムをベースに改善してみたらちゃんと効果はあったよーということらしい．
2004-06-10 古い日記からの変換データ [長年日記] ▲
_ [OUCC] IRC ▲
IRCに奈良先からのお客様が来る（所属的にはM1の人）．ロボ作り（主に機械学習と画像認識）に協力してくれませんか，という話がメイン．（OUCCの）掲示板に書いておいたけど見てくれた？ということでIRCにわざわざ来てくださったらしい．行動力はあるかも．
組み込み系の敷居は高く感じてるんでは，とか阪大にはソフト屋さんが多いから，とか言ったら，メカ系は自分たちでやるよ，阪大の情報よりすごい人多いから，と色々言われた．
丁寧な口調は最初の概要説明くらいまでで，この辺から対等な口調に移っていたのだけれど，１年〜３年生が話し相手だと思ってるのか，年上の社会人相手でも対等でいいと思ってるのかは謎．M1以上も半分くらいいるのになぁ……．
で，なぜか研究室が金持ち，という話になってしまって，4000万のロボットを作ってる人たちと一緒に仕事してる，先生が世界的に有名だ，と自慢された．そして，COEが取れないから阪大は駄目，COE取れないところは興味なし，といったことを言われた．
あと，聞いた話といえば，卒論の枚数が100枚超えたとか．ソフトウェア工学系のＤ論並み．ロボット関係の研究室らしいので，必須のデータがそれだけある分野なのか，読ませる気がないだけか，情報をまとめる力がないのか，いずれなのかは分からずじまい．その人の先輩には１５０枚書いた人がいたようで，「論文書いてたら１５０枚の偉さがわかるよ」と言われた．残念ながら分からない．
結局，本来の話題（どんなことしているか，など）はほとんどなくて，その挙句に話がそれて，なし崩し状態のままで帰られてしまったのだが，会話の論理が飛躍しまくりで，とても楽しい人だった．
_ [ツール] Eclipse 3.0RC1 ▲
研究室関連のプログラム書く環境用に新しい Eclipse を使ってみようかな？と思ってダウンロードサイトに行ったら，いつの間にやら 3.0RC1 が出現していた．
Java2 SDK 1.5 環境まであと少し？
_ [論文] Ontologyの検査？ ▲
ICSE 2004 Tutorial の概要から発見．
Jin Song Dong:Software Modeling Techniques and the Semantic Web.Proceedings of ICSE 2004, pp.724-725.
Semantic Web の Ontology の関係は複雑だから，UML できちんとモデル化したり，形式仕様記述言語でチェックしたりすると便利だなーという話みたい．あと，形式仕様記述から Ontology を生成するとかいう研究もあるらしい．
どんな場面で役に立つのかよくわからないが，いちおう見てしまったのでメモしとく．
_ [日記CGI] キーワード機能追加 ▲
いーかげん見出しが内容を表現してないので，このCGIにキーワード機能追加．実データとしては，ファイルに keyword タグが追加された．まだキーワードをクリックしたら単なる検索が走るだけだが，そのうちキーワードを含んだデータだけが表示されるようになる予定．（まだキーワードが設定されてないデータのほうが多いのでしばらくは移行せず）
_ [論文] 動的影響波及解析の比較 ▲
ICSE 2004 Technical Papers, Dynamic Analysis より．
Alessandro Orso, Taweesup Apiwattanapong, James Law,Gregg Rothermel, Mary Jean Harrold:An Empirical Comparison of Dynamic Impact Analysis Algorithms.
Proceedings of ICSE 2004, pp.491-500.
実行時にデータを集めるタイプの影響波及解析のうち，メソッドの呼び出し関係をきちんと意識する PathImpact とその実行履歴で呼ばれたか呼ばれてないかだけを情報として使うCoverageImpact の実験的な比較．
PathImpact は実行履歴が大きくなると（トレースサイズがGB単位になってくると）実用的でなくなる．CoverageImpact は簡単だが正確性は（著しく）欠ける．これら両方と，Static Slicing を比較するとやはり Static Slicing のほうが大きい結果を返す．このあたりは，いつものトレードオフの問題．
これらの両方を組み合わせられるような手法を考えたい，というところで終わっている．
_ [論文] 機械学習のデバッグ適用 ▲
ICSE 2004 Technical Papers, Dynamic Analysis より．
Yuriy Brun, Michael D. Ernst:Finding latent code errors via machine learning over program executions.Proceedings of ICSE 2004, pp.480-490.
実行するのが高価であったり，テストケースをこれ以上思いつかない，といった場合に，プログラムにまだ見つけていないエラーが残ってないかどうか調べる方法を考えようという論文．
機械学習を使って，エラーのあるコードから抽出された特徴と，エラーの除去されたコードから抽出された特徴とで学習を行い，新たなプログラムから抽出した特徴のうちどれがエラーだと予想されるかを分類する．
特徴として使うのは，動的解析でも静的解析でも使える，と主張しているが，この論文では動的解析によって抽出された Dynamic Invariant を題材にしている．「この部分を（過去に）直されたのならここも怪しいはずだ」という推論は興味深いといえば興味深いのだが，まだどんな特徴を抽出すればエラー検出に役立つとかはよくわかっていないのでそのあたりは将来の課題としている．
うまくいったら面白いなーとは思うのだが，機械学習系って， false positive を出しすぎるとみんな信用してくれなくなって使ってくれない，とか心理的作用があるので実用化は難しいような気がするけれど．
_ [論文] 実行時情報からのアーキテクチャ再構成 ▲
ICSE 2004 Technical Papers, Dynamic Analysis より．
Hong Yan, David Garlan, Bradley Schmerl, Jonathan Aldrich, Rick Kazman:DiscoTect: A System for Discovering Architectures from Running Systems.Proceedings of ICSE 2004, pp.470-479.
プログラムの実行時情報を集めて，アーキテクチャモデルを再構成する．手法としては，アーキテクチャに関係したシステムの特定の振る舞いに反応するステートマシンを用意しておいて，各ステートマシンが，その振る舞いが，コンポーネント間の特定の関係を示しているかどうかを判定する．
たとえば PipedReader を持ったインスタンスと，PipedWriter を持ったインスタンスが出現すると，パイプ接続で対話するコネクションではないか，ということで，それらのインスタンスのPipedReader/Writer との対話イベントを監視するステートマシンを動作させ，それらのインスタンスがデータの読み込み・書き込みなどのイベントを起こしてステートマシンが最終状態まで到達したら，パイプ接続だと判定する．
この手法の利点は，実行時情報のモニタができれば実現できること，また，ステートマシンの用意さえ変えれば，同じアーキテクチャが異なる実装方法で実現されていても対応できる．そのかわり，実行時情報を使う都合上，実行された部分しか調査できないし，ステートマシンが対応できないような ad hoc な実装の場合も発見できない．けれど，実行時情報の使い方としては面白いところ．実行時情報の抽象化とかにも使えるかもしれない．
_ [論文] 形式手法を実践しやすくする開発環境 ▲
ICSE 2004 Technical Papers, Analysis Tools より．
Johannes Henkel, Amer Diwan:A Tool for Writing and Debugging Algebraic Specifications.Proceedings of ICSE 2004, pp.449-458.
形式的仕様記述は便利だという主張のわりには使っているプログラマが少ないので，もっと使えるような環境を整備すべきだ，という論文．
用意するのは，ソースコードから形式仕様を抽出するツールと，実行時に，実オブジェクトのデータを使いながら仕様をチェックするツール．項書き換えで，途中で止まってしまった場合，仕様が不完全だよーとユーザに提示する，らしい．仕様抽出ツールで発見された仕様を徐々に直しながら使っていくことができる．
LinkedList.java の39個のメソッドをカバーするのに100個以上の axioms が要るらしいのですべてのクラスに仕様記述するというのは大変そう．開発者がどれだけ仕様記述に慣れているかにも依存する．
仕様で書ききれない外部メソッド（equals(A, B)など）は，直接 Java コードを呼んで結果を解釈したりもしようとしているので，かなり実用に向けた考え方はしているみたい．
2004-06-11 古い日記からの変換データ [長年日記] ▲
_ 炊飯ジャー ▲
煮物も作れる炊飯ジャーというヘッドラインに惹かれて見てみた．http://nikkeibp.jp/wcs/leaf/CID/onair/jp/mech/313078
煮物作ってるとご飯が炊けないと思うのだけど．
_ [論文] 動的スライス＋プログラムの逆実行 ▲
ICSE 2004 Technical Papers, Slicing より．
Tankut Akgul, Vincent J. Mooney III, and Santosh Pande:A Fast Assembly Level Reverse Execution Method via Dynamic Slicing.Proceedings of ICSE 2004, pp.522-531.
Reverse Execution (逆実行) というのは，プログラムを前の状態に戻すように実行していく手法．普通にやると，途中で捨てられていく情報を保存しておかないといけないので，激しくメモリを消費する．そこで，動的スライスを使って，注目してる部分に関連したところだけが回復すればいい，と割り切った手法．
命令の逆転についても，全部の状態を保存していくのではなく，命令列に対して逆命令列を生成する方法を用いるので，各時点でのレジスタ値を保存する方法よりは経済的になっている．
逆実行がどのくらい役立つかは Agrawal か誰かが研究してたような気がする．特定の値だけ復帰させて，もう一度そこだけ細かく実行して，とかできると，かなり面白いデバッグ作業は展開できる気はする．一度ブレークポイントで止めて「システムの状態を保存」とか指示するのと，後から「戻ってみよう」というのとで，どのくらい開発効率が違うのかは分からないが．
_ [論文] 動的スライス用の実行履歴圧縮 ▲
ICSE 2004 Technical Papers, Slicing より．
Tao Wang, Abhik Roychoudhury:Using Compressed Bytecode Traces for Slicing Java Programs.Proceedings of ICSE 2004, pp.512-521.
Java バイトコードの実行履歴を，RLESe とかいう文から文法を構成するタイプのアルゴリズムで圧縮して，圧縮した状態でも実はそのままスライス計算ができますよーという論文．
動的スライスはコストさえ何とかすれば使える，というふうにみんな考えているのだろうか．静的スライスに比べて研究が活発な気がする．
_ [論文] 動的スライスのメモリ節約 ▲
ICSE 2004 Technical Papers, Slicing より．
Xiangyu Zhang, Rajiv Gupta, Youtao Zhang:Efficient Forward Computation of Dynamic SlicingUsing Reduced Ordered Binary Decision Diagrams.Proceedings of ICSE 2004, pp.502-511.
動的スライスの Forward Computation （１ステップ進むごとに，その時点でのスライスを計算して蓄積していく手法）を使うとき，メモリ消費量を抑える方法の提案．
Binary Decision Diagrams は各ノードが０と１のエッジ（２本だけ）を持っていて末端ノードが０または１でラベル付けされている．で，プログラムスライスはスライスに含まれるIDの集合なので，開始頂点から，IDを表現する２進数（0110とか）で表現されるパスをたどっていくと，末端が０か１かでそのIDがスライスに含まれているかいないか分かる．
で，この論文では，reduced-ordered BDD という，途中のノードをできるだけ共有・省略した状態にすることで各スライスの中身を共有して，全体のデータ量を減らしている．すべてのスライスを合計すると200GB相当のデータになるところが400MB程度で収まるとか．
加えて，スライス基点情報の圧縮とかも何かやっているらしい．（これは去年のICSEで発表されたものっぽい）
プログラムの実行時間については，一番大きい材料（67000LOCくらい）で５時間くらい．一度計算してしまえば好きなだけ動的スライスを取得できるのでおいしいといえるか？
個人的には，ちょっと修正→再実行→スライス計算みたいなやり方で使いたいのであまりうれしくないのだが，空間コスト的には非実用ではなくなった分についてはすごい．CPUがさらに高速化すれば本気で実用になってしまうかも？
2004-06-12 古い日記からの変換データ [長年日記] ▲
2004-06-13 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar]0.7.8 リリース ▲
ドキュメント書き終えたので hyCalendar 0.7.8 リリース．ふー．
今回は，１日の予定をクリップボードにコピーするのと，TODOリストをコピーする機能だけ．ちょっとメニュー項目の名前は微妙だが．
_ [hyCalendar]クリップボード機能強化 ▲
hyCalendar の新機能を実装．TODOリスト，日付に表示される予定（日付メモ＋期間予定＋...）をそれぞれクリップボードにコピーできるようになった．
メールなどで予定を他の人に見せたい人向け．というわけで，またマニュアル書きの仕事が発生．
2004-06-14 古い日記からの変換データ [長年日記] ▲
_ [ツール]単位換算スクリプト ▲
単位換算スクリプト．長さ，重量などの換算に便利だったのでメモしておく．http://www.motorworks.ne.jp/mwc/utilgp/convcalc.html
仕事率の計算もできるので，100万馬力が何ワットかも計算できる．
_ [論文]サービス指向なコンポーネント ▲
ICSE 2004 Technical Papers, Dynamic Reconfiguration より．
Humberto Cervantes and Richard S. Hall:Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model.Proceedings of ICSE 2004, pp.614-623.
コンポーネントの接続をきちんとContractとして定義してコンポーネントは，自分が提供するサービスをService Registry に登録しに行き，Requester が Registry から目的のサービスを見つけるというブローカーが存在するモデル．サービス間の依存関係なども Registry に登録するときに一緒に登録しておいて，必要なサービスを動的に集めながらプログラムが実行されることになる．
この論文で紹介されている Gravity プロジェクトはhttp://gravity.sf.net/で公開されているらしい．
_ ▲ 本筋とはあまり関係ないが，Reconfiguration系の人たちは，コンポーネントの定義としてSzyperski, C.: Component Software: beyond object-oriented programming.ACM Press/Addison-Wesley Publishing Co., 1998.によるA software component is a binary unit of composition with contractually specified interfaces andexplicit context dependencies only. A softwarecomponent can be deployed independently and is subject tocomposition by third parties.というのをよく引用しているみたい．
_ [論文]動的再構成フレームワーク ▲
ICSE 2004 Technical Papers, Dynamic Reconfiguration より．
Jamie Hillman, Ian Warren:An Open Framework for Dynamic Reconfiguration.Proceedings of ICSE 2004, pp.594-603.
動的にコンポーネント間の接続を変えられるようにするOpenRec というフレームワークを作りました，というもの．
基本的には，システムの状態を監視する方法と接続を再構成するためのスクリプト（OpenRecML）を提供するのであとはその上で自由に再構成のアルゴリズムとかアルゴリズムのコストとかの研究をしましょう，というツールの提示の論文．
ツール本体やらドキュメントやらは以下のURLから取れるみたい．いきなりログインフォームが出ているが，右上のほうに News というリンクがあって，そこから最新情報を見ることができる．http://www.openrec.org/
_ [論文]関係ある変更の提示 ▲
ICSE 2004 Technical Papers, Software Configuration Management and Deployment より．
Thomas Zimmermann, Peter Weissgerber, Stephan Diehl, Andreas Zeller: Mining Version Histories to Guide Software Changes.Proceedings of ICSE 2004, pp.563-572.
協調フィルタリングを使って，「この関数を変更したプログラマはここも変更しています」「この関数は変更しなくていいのか？」などと提示する手法．Eclipse ベースのツールとして実装している．
元になる情報はバージョン履歴で，同時期に変更されたもの，というのが基準になる．正確さなどの点ではかなり怪しげ．今のところ，少しだけ正確なものを出すか，正確性が下がっても数をカバーするか，のどちらかになってしまうらしい．
2004-06-17 古い日記からの変換データ [長年日記] ▲
_ [論文]プログラム実行の可視化 ▲
ICSE 2004 Research (Formal) Demos, Analysis and Visualization より．
Alessandro Orso, James A. Jones, Mary Jean Harrold, John Stasko:GAMMATELLA: Visualization of Program-Execution Data for Deployed Software.Proceedings of ICSE 2004, pp.699-700.
ソフトウェア可視化ツール．カバレッジ計測，データ収集デーモン，可視化ツールのセットらしい．
http://sourceforge.net/projects/insectj
_ [論文]Traits ▲
ICSE 2004 Technical Papers, Object-Oriented Programming より．
Andrew P. Black, Nathanael Scharli:Traits: Tools and Methodology.Proceedings of ICSE 2004, pp.676-686.
Traits というプログラミング言語のお話．クラスのメンバー群をクラスとは別単位で固めておけるというだけなのだが．
ECOOP2003のときの論文に比べると，開発環境まわりの話が主体に見える．Traits Browser とかいうツールでメンバーの管理などができるらしい．前に読んだとき
Agile系の話が少し加わっていて，リファクタリング時などには，関連しあったメンバーの集合をクラスから分離しておくと便利だ，とかいう話が増えている．Subject-Oriented Programming なんかにも近い話だと思うのだがそのあたりの話は出て来ず．
_ [論文]リンク解析によるクラス分類 ▲
ICSE 2004 Technical Papers, Object-Oriented Programming より．
Alexander Chatzigeorgiou, Spiros Xanthos and George Stephanides:Evaluating Object-Oriented Designs with Link Analysis.Proceedings of ICSE 2004, pp.656-665.
井上先生の論文が引用されているのだが論文タイトルがなぜか抜けてたりしてけっこういい加減……．
Component Rank は汎用コンポーネントの発見が目的だが，こちらはシステムの設計上の問題点を見つけることが目的らしい．
メインは，クラス間のリンク情報を使ってクラスの分類をしましょう，という論文．"オーソリティ" （色々なクラスから参照されるクラス）と"ハブ" （色々なクラスを参照するクラス）という概念を使って，クラスをグループ化する．
お互いに（密に）参照しあっているようなクラス群が存在するとそこをグループとして取り出すことになる．インタフェース使って厳しく抽象化されてしまっても，特定のインタフェース群を参照しているグループが取り出せる．グループといっても３，４個のクラスから構成される小さなものだが．
"fat interface" アンチパターンみたいに責任が集中しているとクラス群が全部固まって出てくるから責任を分散させよう，みたいな話になるのか．どのくらいで集中したら問題，という話がないのでよく分からない．
_ [論文]生成されうるSQLの静的チェック ▲
ICSE 2004 Technical Papers, Static Analysis より．
Carl Gould, Zhendong Su, Premkumar Devanbu:Static Checking of Dynamically Generated Queries in Database Applications.Proceedings of ICSE 2004, pp.645-654.
プログラム中で動的に生成されるSQL文を静的にチェックしたい，という動機の論文．チェックの対象は，生成される文がSQLとして正しいかどうか（構文）と，生成される列名や値の型が正しいかどうか（意味）．
生成されうる文字列をオートマトン表現に落として，Context-Free Language Rechability という方法を使ってテストする．アルゴリズムの計算量は O( |s|^3 + |D|^3 ) ．ここで，|s|はアルファベットの種類数，|D|はグラフサイズ．ただ，一般にはSQL生成のオートマトンは小さいので，実験で使われた最も大きいもの（1300ノード程度）でもたかだか数分で検査が終了している．
動的生成されるHTML検査の研究などに立場は近い．SQLのほうが，アプリケーションごとのデータベーススキーマの情報が使えることと，SQL自体が長くなることがあまりないので有利という気はする．
また，きちんと型検査などもしているので，たとえば列名ごとの型チェックだとか（String 型の列を間違って Integer として取り出したりとか）にも応用が利くだろう，とも言っている．このあたり，使えるとけっこう便利な技術ではある．ちょっと false error も出てしまうので悩ましくはあるが．
_ [論文]モデルチェックへのヒューリスティックの導入 ▲
ICSE 2004 Technical Papers, Static Analysis より．
Jianbin Tan, George S. Avrunin, Lori A. Clarke:Heuristic-Based Model Refinement for FLAVERS.Proceedings of ICSE 2004, pp.635-644.
FLAVERS という名前のモデルチェックの話．特定の性質が成り立つかどうかを，プログラム実行中のイベント列を受理するかどうかという有限オートマトンとして表現しておいて，プログラム側から自動生成した Task Flow Graph （プログラム実行中に発生するイベントをノードとして，その発生順序関係を辺とするようなグラフ）上のパスがオートマトンの条件を満たすかどうか，ということになるらしい．
ただ，グラフ上にはパスが作れても「実際には起こらないパス」というのが登場してくる．
これを削るために，イベント間の制約であるTask Automata（実行スレッドごとに分解したTask Flow）を使うが，チェックするべき制約が少なすぎるとパスの除去に失敗し，多すぎると無用にコストが増大していくという問題がある．
そこで，ヒューリスティックを使って，必要なオートマトンを適当な数だけ選び出そう，ということになる．特定のタスクでしか使われていないイベントがある場合はそのタスクを選び，また，複数（通常２つ）が同期したイベントではカバーしてないイベントの個数が多いものを選ぶ，といった具合でイベントを一通りカバーするようなタスクセットを選ぶと80％くらいの正確性となり，コスト対効果が良くなるらしい．
_ [論文]ソース解析ツール DMS ▲
ICSE 2004 Technical Papers, Static Analysis より．
Ira D. Baxtor, Christopher Pidgeon, Michael Mehlich:DMS(TM): Program Transformations for Practical Scalable Software Evolution.Proceedings of ICSE 2004, pp.625-634.
筆者たちが DMS という名前の商用のソース解析ツールを作っているらしく，その中身を紹介している論文．
ソースコードを高速に解析することで大規模なソフトウェアにも適用可能なツールにしました，という話．COBOL や C，Java などが相手で，機能としては，コードクローン検出，プリプロセッサ命令の部分評価，カバレッジ計算，DTD に対応したパーサの合成など．
高速化の工夫としては，できるだけ並列に処理できるようにするとか，構文の書き換えルールを使って，たとえば A = A + 1 を A++ に置き換えるような形で，ソースコードの表現をまとめていくとか，LR文法で，解釈候補が複数あった場合に並行して処理するGLRという手法を使ったりとか．
研究や開発のインフラとして，この種の解析プラットフォームが必要だろう，という立場のよう．Conclusion のところに50人年で８年くらいかけてる，とか書いている．このプロジェクト管理能力はすごい．
2004-06-21 古い日記からの変換データ [長年日記] ▲
_ [論文]プログラム理解支援アスペクト（？） ▲
Darren Ng, David R. Kaeli, Sergei Kojarski, David H. Lorenz:Program Comprehension Using Aspects.Proceedings of Workshop on Directions in Software Engineering Environments (WoDiSEE) 2004,in conjunction with ICSE 2004, pp.88-95, May 25th, Edinburgh, Scotland, UK, 2004.
プログラム理解を支援するといわれるツールは数多くあるが，使いやすさと機能のバランスが難しい．対象のプログラムの調査そのものよりも，プログラミング環境に慣れるために時間が必要だったりする．
そこで，プログラマが親しみやすく表現力も十分にあるAOPな言語要素（今回はAspectJ）をプログラム理解ツールとして使ってみた，という実験報告．
使い方としては，declare warning: call を使って使われていないインタフェースを洗い出す，特定のクラスのユーザを見つける，インタフェースの階層情報を集めてくる，選択的なプロファイリングをする，といったところ．
で，それなりに便利だったらしい．AOP Refactoring か何かの記事で載ってたような話を実際にやってみました，という程度かもしれない．
_ [hyCalendar]ファイルが読めないバグ？ ▲
バグ報告を受け取る．
ファイルが読めずに（読んだのに何も表示されずに），プログラムを終了するとファイルが空データで上書きされるらしい．
ファイル読み込み権限がなくて，かつ書き込み権限がある場合にこの問題が起こることはコード読んだだけでわかったのだが，それ以外のたいていのエラーの場合は（例外が投げられた場合は）読み込み失敗のダイアログを出すようになっているので，何か微妙なデータになると読み込みに失敗するらしい．
スケジュールはとても私的な情報なので，データ見せてくださいというわけにもいかないし……．
2004-06-23 古い日記からの変換データ [長年日記] ▲
_ [論文] 複数ビューのサポート環境 ▲
Andrew P. Black, Mark P. Jones:The Case for Multiple Views.Proceedings of Workshop on Directions in Software Engineering Environments (WoDiSEE) 2004,in conjunction with ICSE 2004, pp.96-103, May 25th, Edinburgh, Scotland, UK, 2004.
Traits を提案している人たちの提案．Traits を展開したビュー，完全に階層的なビューなど，見せ方だけを変えたビューをいくつも切り替えていくことができたら理解容易性などが上がってよいね，という話．統合開発環境が，開発者が注目したい情報を表示する複数のビューを作れるように頑張る，ということになる．
アスペクトとかを展開済みの状態で見れたりすると便利かも？とか，有用性は想像しやすいのだが，実用的なビューの構築というのはどのくらいあるのか，とかビューを構築したときに情報を落とすとそのせいで問題が起こったりしないのか，とか気になるところではある．
_ [論文] アスペクト的パターンの適用 ▲
Imed Hammouda, Mika Katara, Kai Koskimies:A Tool Environment for Aspectual Patterns in UML.Proceedings of Workshop on Directions in Software Engineering Environments (WoDiSEE) 2004,in conjunction with ICSE 2004, pp.57-64, May 25th, Edinburgh, Scotland, UK, 2004.
クラスの相互作用のパターンを，アスペクトとして定義しておいてアスペクトを順番に適用していくことで目標のアーキテクチャを得る，といった考え方をしているらしい．で，モデルにパターンを適用していく作業をツールで支援する．
アスペクトとしてクラス間の相互作用を一部分ずつ規定していくことで，付けたり外したりして色々なシステムの構造を作れるね，というような形らしい．
ソースコード上でやったら Association Aspect に近いといえば近い？
2004-06-24 古い日記からの変換データ [長年日記] ▲
_ [Java]例外をめぐる議論 ▲
IBM developerWorks の例外に関する議論の話．面白い話なので，忘れないようにメモ．http://ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html
チェック例外がメソッドシグネチャに与える影響はやっぱり嫌われるらしい．アスペクトを使って例外送出＆例外処理，というのがWormhole パターンの逆みたいで面白そうではあるのだが．
_ [論文]データ構造の一貫性チェック ▲
Brian Demsky, Cristian Cadar, Daniel Roy, Martin Rinard:Efficient Specification-Assisted Error Localization.Proceedings of Second International Workshop on Dynamic Analysis (WODA2004), in conjunction with ICSE 2004,pp.60-67, Edinburgh, Scotland, UK, 25 May, 2004.
データ構造の仕様・制約を記述できるようにする言語の提案．いわゆる表明では，その時点での局所的な制約しかチェックできないので，データ構造が壊れた後もそのまま表明を通過する恐れがあるので，このような仕組みが有効な場面がある，らしい．
加えて，仕様チェック処理のコードの最適化についても色々言及している．実行速度が遅くなるようでは使い物にならない，という実用指向な立場の人たちのよう．
_ [論文]80％のバグは20％のファイルに ▲
Thomas J. Ostrand, Elaine J. Weyuker, Robert M. Bell:Using Static Analysis to Determine Where to Focus Dynamic Testing Effort.Proceedings of Second International Workshop on Dynamic Analysis (WODA2004), in conjunction with ICSE 2004,pp.1-8, Edinburgh, Scotland, UK, 25 May, 2004.
統計的にバグのある確率の高いファイルを選んでいくと20％のファイルで80％くらいのバグが捕まえられます，という面白い実験的論文．
ファイルの種類によるバグ密度ではsh, sql, html, java, perl, c などのファイルを比較しているがmakefile や sh, sql が行数に対するエラー数が多いらしい．その他，LOCなどの値と過去のバグ履歴情報を使うらしい．
コストの高い解析手法も20％のファイルに集中すればそんなにコストが高くない，かもしれない．
_ [論文]Reactive System 監視用コードの自動生成 ▲
Mikhail Auguston, Mark Trakhtenbrot:Run Time Monitoring of Reactive System Models.Proceedings of Second International Workshop on Dynamic Analysis (WODA2004), in conjunction with ICSE 2004,pp.68-75, Edinburgh, Scotland, UK, 25 May, 2004.
Reactive System は通常ステートチャートでモデル化されるが，記述された Assertion に対して，実行時にそれを検証する処理を自動生成しましょう，といったタイプの研究．
使えるのは，取りうる状態列の正規表現記述と，ALWAYS，EVENTUALLY，UNTILなどの時間に関する表明．主には UML 上で使うことを想定しているようなので，一般のプログラムとの状態対応付けさえうまくできれば色々使えそうな感じではある．
2004-06-28 古い日記からの変換データ [長年日記] ▲
_ [hyCalendar]Y2K問題？ ▲
hyCalendar で特定の環境で holidays.txt （休日情報）が読み込めなかったり，保存したファイルが開けなかったりする問題が発生している．
どうも，ロケール情報が原因っぽい．イギリスでファイルが読めなかったのはほぼ確実にロケールが問題で，もう一つ，Windows バージョンによる問題のほうはShortDateFormat （Windows ロケールから自動設定される）が違うことが原因である可能性が出てきた．
試せる環境が少ない（稼動している古い環境が少ない）が，調べてみる価値は高そう．
2004-06-30 古い日記からの変換データ [長年日記] ▲
_ [論文]欠陥の原因として疑わしい文の可視化 ▲
James A. Jones , Mary Jean Harrold, John Stasko:Visualization of Test Information to Assist Fault Localization.Proceedings of ICSE 2002,pp.467-477, Orlando, Florida, May 2002.
ICSE2004 の Doctoral Paper で出ていたもの の Full paper バージョン．２年前のものだが，内容としてはこちらのほうが充実している．
ある文 s について，その文が実行された回数が多いほど色を明るくし，そのうち失敗したテストケースが多いほど色を赤くしてソースコードのビューを作る．
で，結果としては，テストケースを準備することで，疑わしいレベルが高いものにバグが含まれていたらしい．
たまに，バグがあるけれど緑色（安全）な方向に振られていたものもあったようなので，そう簡単に実用というわけにはいかないかもしれないが．プログラムスライシングなどと組み合わせて，バグがないのに赤色に振られたものをチェックするとか，future work に色々書いている．
パスしたテストケースで実行された文の集合 P と失敗したテストケースで実行された文の集合 F で，F⊃P である（Pに含まれずFに含まれる文が１つ以上ある）ことが前提条件になる．また，実験結果ではだいたい１〜２割程度の文に絞っていたが，プログラムスライスの場合と同様，その結果が十分小さいと言えるのかどうかについては不明．
