netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-04-28 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
先ほどのつづき，関連研究だけ別に整理．この量はさすが TSE というべきか．
関連研究としては，Wilde, Scully らによるSoftware Reconnaissance での機能の分類法で・f が実行されるされないに関わらず実行されるもの・f が実行されるときに実行されることがあるもの・f が実行されるときは必ず実行されるもの・f が実行されるときは必ずかつそのときのみ実行されるものというような分類があるらしい．
また，静的情報を使う系統ではChen, Rajlich らによるCase Study of Feature Location Using Dependence Graph (IWPC95) というのが，ソースコードをグラフに抽象化するアプローチらしい．ただし，この論文の筆者らは，「どこから探していいか分かってないときには この手法は向かない」としている．
Concept Analysis の活用についてはSiff and Repse: Identifying Module via Concept Analysis,Deursen and Kuipers:Identifying Objects using Cluster and Concept Analysisなど．
表示関係ではKoskimies and Mossenbock: Schenario-Based Browsing of Object-Oriented Systems with Scene.Lange and Nakamura: Program Explorer: A Program Visualizer for C++.Lange and Nakamura: Object-Oriented Program Tracing and Visualization.などが挙げられている．
_ [論文]Concept Analysis による機能の実装位置特定 ▲
Thomas Eisenbarth, Rainer Koschke, and Daniel Simon, Locating Features in Source Code, IEEE Transactions on Software Engineering, Vol. 29, No. 3, pp.210-224, March, 2003.
「ある機能を実行するテストケース」を実行して，各機能に対してどのユニット（関数 or クラスなど）が実行されたかを実行履歴から取得し，その結果に Concept Analysis を行うというもの．Concept Analysis を行うことで特定の機能に固有なもの，共有されているもの，といった情報が手に入るので，それと静的な関係図をもとに開発者が手動で Feature-Code マッピングを作成する．
「何をテストしているのか」という知識などが多少必要になること，最終的な分類は人手に頼ること，などが少し弱いといえば弱いが，それなりの結果は出ているようだし，アプローチも面白い．
ケーススタディにおけるルーチン間の接続などを見ると，相互に密な結合をしている部分とばらばらの部分があったりして，プログラムによってはかなり分類ができる可能性が分かる．
Concept Analysis 自体は学習も容易で便利だが，手続きなどを単位とするとConcept Lattice が大きくなってしまい作業しづらくなる，といった弱点はあるよう．
また，テストケースの選び方による偏りが生じるので，プログラム保守のタイミングなどで，「ここを直すのが一番影響が少ない」とかいったことを調べるにはこの手法は対応していない．（あくまで特定の機能がどこにあるかを理解することが目的で， そのユニットが他の機能に関わるかどうかまでは考えない）
_ 論文 ▲
Joel Winstead and David Evans:Towards Differential Program Analysis.Workshop on Dynamic Analysis. 9 May 2003.
プログラムの差分（主にバージョン間差分）を認識するタイプの解析方法が重要だ，という立場の position paper．
この筆者たちは，ふたつのプログラムの実行結果が変わるようなテストケースを見つけることが大事だろう，と言っていて，プログラム変更箇所から入力パラメータなどを simulated annealing など経験的手法で生成していく方法について紹介している．
生成した入力パラメータを使って実行してみて，評価として条件式の true/false を変えるような値に近いほうが優れている，とするらしい．いちおう小さな実験結果が載っていて，この判定基準を使うかどうかで，差分が分かるような入力セットを見つけられるかどうかの試行回数を大きく削減できるらしい．（300万回かかっても７割くらいの確率でしか見つからないものが 70万回くらいで発見できている）
……とはいえ，小さな手続き１個が相手で試行が70万回というのは多いか少ないかは意見が分かれそうだが，自動デバッグな世界の人らしい考え方な気はする．
_ Download ASCII ▲
サービス停止，のはずだった Download ASCII だが，サービス移管されるらしい．
移行先はシーサー株式会社．オンラインショッピング＆ブログサービスらしい．http://shop.seesaa.jp/
_ 論文 ▲
Rainer Koschke: Software Visualization for Reverse Engineering.Software Visualization, LNCS 2269, pp.151-162, 2002.
ソフトウェア可視化に関する Survey か Position Paper ．Software Visualization はソフトウェアを他の（グラフィカルな）表現にマッピングすることであるが，その方法として代表的なものにグラフとハイパーリンクがあり，特にグラフはほとんどの既存研究で使われている．
ところが，関数などを単位としたグラフを作ると高々５万行程度でも辺や頂点の数が5000~10000といった数になってしまうので，見せ方はとても重要．
また，ツールの構築では，以下のようなことに気をつけること，としている．
・意味が一貫していて理解しやすいこと． たとえば UML なら，継承関係が上下方向に並ぶとか．・大きくなると，「すべてを一度に見る」のは現実的ではない． 「現在位置」のようなものが常に分かるように しながらレンズでズームアップする，といった メンタルモデルが重要．・保守作業などでは，システムはどんどん変化するので 変化に追随できる機能が必要．・大規模ソフトウェアの保守はチームワーク． 複数人が（できれば地理的に離れた場所でも） 利用できるようなシステムが好ましい．・同一のシステムを複数の perspective から見られるようにする．・静的特性，動的特性を両方とも扱えることが重要．・認知モデルの構築・相互運用性の実現
そのほか，何％くらいのツールが UML 表現だったりグラフを使っていたり，といった数値が載っていたが，それを見た限りではグラフが多いこと，UMLが意外と少ないこと，またアニメーションなどは稀だということ，くらいだろうか．
_ ライセンス占い ▲
ソフトウェアライセンス占い．http://u-maker.com/42212.html
面白いなーと思ったのが，質問への回答がテキストでの自由回答なところ．いったいどうやって判定しているんだろう．文字コードからの乱数とかではないのかなぁ．質問への答え方によるのかな？
_ ちなみに旧 BSD ライセンスでした． ▲
---以下，引用---旧 BSD ライセンスが適用された貴方は、落ち着いていて伝統重視の、とても洗練された人。時の厳しい選別に耐えた品のあるもの、優雅なものを好むタイプで、あくせくした暮らしは好きではないでしょう。といっても、それにふさわしいだけの心の余裕や、品位があればよいのですが、なかなか難しいかもしれません。浅ましく世間ずれした連中に出し抜かれてしまいがちで、経済的な生活レベルは普通かそれ以下になってしまうかも。慎ましく現状維持を念頭に置いた生活、そして侘び寂びや諸行無常の境地が、そんな貴方の日々の生活に自ずと潤いと美をもたらしてくれるでしょう。そんな貴方の恋愛面は、意外なことにとても積極的。俺が私がとどんどん自分をさらけ出し、相手に自分のエゴイスティックな刻印を残そうとするでしょう。でも大枠では、相手に合わせた恋愛をしていきそうです。
