«前の日記(2004-06-09) 最新 次の日記(2004-06-11)» 編集

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2004-06-10 古い日記からの変換データ [長年日記]

_ [OUCC] IRC

IRCに奈良先からのお客様が来る(所属的にはM1の人).ロボ作り(主に機械学習と画像認識)に協力してくれませんか,という話がメイン.(OUCCの)掲示板に書いておいたけど見てくれた?ということでIRCにわざわざ来てくださったらしい.行動力はあるかも.

組み込み系の敷居は高く感じてるんでは,とか阪大にはソフト屋さんが多いから,とか言ったら,メカ系は自分たちでやるよ,阪大の情報よりすごい人多いから,と色々言われた.

丁寧な口調は最初の概要説明くらいまでで,この辺から対等な口調に移っていたのだけれど,1年〜3年生が話し相手だと思ってるのか,年上の社会人相手でも対等でいいと思ってるのかは謎.M1以上も半分くらいいるのになぁ…….

で,なぜか研究室が金持ち,という話になってしまって,4000万のロボットを作ってる人たちと一緒に仕事してる,先生が世界的に有名だ,と自慢された.そして,COEが取れないから阪大は駄目,COE取れないところは興味なし,といったことを言われた.

あと,聞いた話といえば,卒論の枚数が100枚超えたとか.ソフトウェア工学系のD論並み.ロボット関係の研究室らしいので,必須のデータがそれだけある分野なのか,読ませる気がないだけか,情報をまとめる力がないのか,いずれなのかは分からずじまい.その人の先輩には150枚書いた人がいたようで,「論文書いてたら150枚の偉さがわかるよ」と言われた.残念ながら分からない.

結局,本来の話題(どんなことしているか,など)はほとんどなくて,その挙句に話がそれて,なし崩し状態のままで帰られてしまったのだが,会話の論理が飛躍しまくりで,とても楽しい人だった.

_ [ツール] 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 コードを呼んで結果を解釈したりもしようとしているので,かなり実用に向けた考え方はしているみたい.

お名前:
E-mail:
右の画像に書かれている文字列を入力してください:
コメント: