netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-05-07 古い日記からの変換データ ▲
_ レガシーアプリケーションの保守の話と，http://www-6.ibm.com/jp/developerworks/java/040507/j_j-aopsc2.html ▲
Javassist の話．http://www-6.ibm.com/jp/developerworks/java/040507/j_j-dyn0302.html
IBM ががんばってるのだけは良く分かる．
_ bun45 ▲
bun45.let.osaka-u.ac.jp が文学部内部ネットワークに切り離された．……ので，学内からも他学部だとアクセスできないのでCGI 等の保守がまったく不可能になってしまった．
www.let.osaka-u.ac.jp あたりがゲートウェイも兼ねているのかな？という予想があるのでssh アカウントくれくれと管理者の人にお願いするメールを送ってみた．ページも www.let に移動しないといけないし．
本当は誰かのコネを使ってroot になるくらいの覚悟で活動すればいいんだろうけど，それは避けたいし．
それにしても，bun45.let.osaka-u.ac.jp へのリンクを既に広めてしまっているので移転するのをさっさとやらないと問題だ．
_ 読書 ▲
Anne McCaffrey, "Pegasus In Space" を読み始めた．「ペガサスで飛ぶ」と「銀の髪のローワン」をつなぐ間の話でなぜか未訳．時間的には「ペガサスで飛ぶ」の直後．Concluding her magnificent Pegasus Series と書いてあるからこれでシリーズがひとまず終わり．
読んでて一番厳しいのは人名のスペルだったりして．Rhyssa，Peter や John のようにすぐ分かる人はいいとしても，Tirla（ティーラ）とSascha（サーシャ）あたりは微妙に見落としそうだった．
技術論文とは違って会話が多いので，読むのが遅い．
_ 論文 ▲
J. Rilling, A. Seffah, C. Bouthier:The CONCEPT Project - Applying Source Code Analysisto Reduce Information Complexity of Static and Dynamic Visualization Techniques.In 1st International Workshop on Visualizing Software for Understanding and Analysis, 2002.
ソースコードを理解するための環境を作ろう，という研究．ソースコードから図を構成することで全体の様相を把握して，静的スライス，動的スライスで注目したい部分だけを抽出するというタイプ．
図の構成には，アイテムを矩形で表現して全体の大きな矩形を埋めていく Treemap と，注目したノードの周辺を大きく，遠くなるほど小さく描画するHyperbolic tree，プログラムスライスだけをハイライト表示するシーケンス図など．詳細を省き，あくまで概略をつかむための図という位置づけのようで，focus を一箇所に絞るのが動的スライスだ，と言っている．
動的スライスについては，実行履歴上で，「ある注目したい機能に関連した部分」とそうでない部分で同じ関数を呼び出している場合もある，そんなときは関係ない場所から呼ばれたことは無視したりできたらいい，ということも言っている．
2002年の論文なので，現在だともう少し研究が進んでいる可能性が高い．どこかに出ているかな？
_ 論文 ▲
Dirk Heuzeroth, Thomas Holl, Welf Lowe:Combining Static and Dynamic Analyses to Detect Interaction Patterns.IDPT 2002, Pasadena, CA.
ソースコードからデザインパターンなどを検出しようという試み．Observer パターンであれば Observer と Subject の候補がきちんと addListener に相当するメソッドなどを持っているかどうか，ということを検査する．お互いのメソッド呼び出し関係がデザインパターンの規則を満たしているかどうか，などが基準となるよう．
で，静的解析結果で得られた候補から，さらに動的解析を行って（テストケースを実行して）実際の結果を出すらしい．
だから，・ある程度きちんとデザインパターンに則っていること，・十分な数のテストケースが容易されていること，などが満たされないと検出は難しそう．
手を抜いて removeListener がない（登録しても解除不可）とか類似したコードを書いていても検出されない場合も出てきそう．（もちろん，テストケースで，インタラクションがなければ 検出できない）．厳しい分，false positive はなさそうだが．
モデル図上で「ここはイベントリスナーで接続」とか「ここは delegate で」とか分かるのであればそれなりにうれしいかもしれない．
_ 論文 ▲
William Landi, Barbara G. Ryder, Sean Zhang:Interprocedural Modification Side Effect AnalysisWith Pointer Aliasing.
ポインタによるエイリアスを考慮した副作用解析．各代入文などで「ポインタが指しうる範囲」を調査することでどのメモリ領域が書き換えられるかを調べる．
アルゴリズムとしては，手続き単位で「到達しうるエイリアス」を集めておいて，手続き呼び出しごとにそのエイリアス集合を足していくという形になる．
Java などに応用する場合，多態性の管理が生じると少し大変そうだが．
_ 論文 ▲
Stuart M. Charters, Claire Knight, Nigel Thomas and Malcolm Munro:Visualisation for Informed Decision Making;From Code to Components.Proceedings of SEKE 2002, pp.765-772, July 15-19, Ischia, Italy.
ソフトウェアの可視化に関する論文で，ソフトウェアおよびコンポーネントをそれぞれ "City" として表現しようというもの．
建物が１個のメソッド（建物の高さがメソッドのコード量）でひとつの区画がクラスを表現して，クラスが集まって街が構成される，……とうようなSoftware City として表現するらしい．
また，コンポーネントについても，１つの建築物が１つ（あるいは複数の）コンポーネントで，数によって家だったりマンションだったり，といった表現を用いて，コンポーネントの機能ごとに街の区画整理を行うことで，コンポーネント群を表現する．
都市空間としての表現は実は強力なメタファらしいのだが，欠点として，非機能的特性（品質その他）はどう表現していいか困る，ということも挙げられている．
地理的な区分は，単純な階層区分よりは「境界のあたり」といった表現ができるので多少表現の範囲は広そうだが，構造が階層的であることに変わりはないので最初に何を基準に区画化するかが，大きな影響を与えそう．
