netail.net

_ 読書 ▲

「パズルの国のアリス II」読了．

今度は鏡の国のアリスがベースになった話で，ハンプティ・ダンプティによるパラドクスの話と様相論理を用いたパズルが主体．

こういうパズルが普通に（難易度の高いものは手間がかかるが）解けるようになった時点で，大学とかで受けた一部の講義がそれなりに効果を発揮しているのかもしれない．

_ [論文]モデルと実装の対応 ▲

Rainer Koschke, Daniel Simon:Hierarchical Reflexion Models.Proceedings of 10th Working Conference on Reverse Engineering (WCRE 2003), pp.36-45,13-16 November 2003, Victoria, Canada.

reflexion model というアーキテクチャと実装の対応付けを行う手法をきちんと階層化した構造に対して適用可能にしたもの．

最初に，モデルとして，モデル要素とその依存関係を適当に設定する．次に，ソースコードの各要素からモデル要素へのマッピングを決めて，モデルに含まれていないのにソースコードにある依存関係，モデルには含まれているのにソースコードにはない依存関係がないかどうかを調べる．これらの依存関係が存在する場合はマッピングがおかしい（モデルと実装が食い違っている）のでマッピングを修正していって正しいモデルを得る，ということになる．

Reflexion model 自体は G. C. Murphy らによって提案されたもので，この論文は階層化に関する拡張で階層化された要素間でのマッピングの関係を整理しているところが新規性か．大規模のソースコードに対するケーススタディを行っているあたりがえらい．

最初のモデル構築の部分は人手に頼る部分は大きいが，モデルと実装のギャップを調べるという技術としては有用であるように思える．

_ 論文 ▲

移動中に読んだ論文の整理．

R.M. Hierons, M. Harman, and H. Singh:Automatically Generating information from a Z specification to support the Classification Tree Method.

Z 言語で記述された仕様の事前条件などの predicates から，いわゆる事前条件と，入力の値域の分割とを表現した述語を区別する．この区分ができると，少なくとも事前条件を満たした上で，入力の値域に関する述語それぞれをTRUE/FALSE とするような Calssification Tree が構築でき，テストケースの自動生成につながる，というもの．

アプローチとしては面白い．

_ 論文 ▲

Bixin Li:Analyzing Information-Flow in Java Program Based on Slicing Technique.Software Engineering Notes Vol.27, No.5, pp.98-103, Sep. 2002.

プログラムスライシングを使って，コンポーネント間を流れている情報量や結合度の計算などをやってみよう，というもの．前提として正確なスライシングができることなどが入っていて，また提案している要素の妥当性の説明が弱い気がする．

_ 論文 ▲

Jens Krinke:Evaluating Context-Sensitive Slicing and Chopping.ICSM 2002.

現在のコールスタック状態を意識しながらスライス計算を実行するとき，その call string の長さを定数 k で固定するとどうなるか，というのをk を変化させながら実験している．呼び出し関係のグラフのうちループを１頂点に縮約したFolded Context Slicing 手法ならSummary Edge を使って計算した手法と比べてもそんなに悪くない結果が出ている．

PDG 構築コストが高いので Summary Edge 計算のコストが無視されている，というところが微妙だったりする．

この比較結果は面白いところで，PDG 構築以外の場所でも役立ちそうな気がする．

_ 論文 ▲

Gagan Agrawal, Liang Guo:Evaluating Explicitly Context-Sensitive Program Slicing.PASTE'01, pp.6-12, June 18-19, 2001.

プログラムスライスの計算時に，その時点でのコールスタックの中身がどうなっているかを計算しながら実行することでCall String （コールスタックの中身の表現）ごとに同じ手続きでも異なるスライス結果を持つように設定する．その結果，スライスサイズが減少する．計算時間については，極端に増えるとかいうことはなく，むしろスライスサイズの変化によっては計算時間が減少することもあるらしい．

_ 論文 ▲

Donglin Liang, Mary Jean Harrold:Slicing Objects Using System Dependence Graph.ICSM 1998, pp.358-367.

オブジェクト指向言語のためのスライシングの話．オブジェクトのメンバー構造をツリー状で表現する（メンバーがオブジェクトなら，さらに下も必要に応じて展開する）．フィールドはやっぱりパラメータとして渡されて，パラメータがオブジェクトなら，オブジェクトのメンバーへのアクセスはオブジェクト変数からのデータ依存を持つ，という形になる．

インタフェースの解析については参照される変数集合(GREF)と変更される変数集合(GMOD)を解析する手法が次の文献に出ているらしい．W. Landi, B.G. Ryder, and S. Zhang:Interprocedural modification side effect analysiswith pointer aliasing. Proceedings of SIGPLAN'93 Conference on Programming Language Design and Implementation,pp.56-67, June 1993.

_ ホテル ▲

新宿パークホテルは，シングル8400円のわりにネットワーク接続があってけっこう快適．電話と一緒にユニットが付いてるので VDSL か何かかな？

_ 論文 ▲

論文の大量消化を進行中．

Mark Harman, Lin Hu, Malcolm Munro, Xingyuan Zhang, David Binkley, Sebastian Danicic, Lahcen Ouarbya and Dave (Mohammed) Daoudi:Syntax-Directed Amorphous Slicing.Journal of Automated Software Engineering,11(1): pp.27-61, 2004.

Amorphous slicing は，構文の簡略化を含んだスライシング手法．スライス計算の結果，if 文の条件式が必ず false になるとか，関数の引数が使われないとかいったことが判明したら，if文を丸ごと削除したり，引数を減らした関数定義を作ったりして構文木を保存しない状態でスライス結果を出力する．なので，用途としてはプログラムの簡略化などになる．

計算時間や空間コストはやっぱり n の自乗．500 行のプログラムで，最善で約１秒，最悪で約２分とかいうくらいに極端な差が出るようで，そんなに大規模なシステムに適用できるわけではない．

AST 変換なアプローチを取っていて，依存グラフ構築のアプローチよりも局所的な変換ルールはシンプルになる点が有利らしい．SDG アプローチ側は依存関係の整理には向いている，というように比較が入っているので，この種の比較を引用するには便利そう．

_ 論文 ▲

Lahcen Ouarbya, Sebastian Danicic, Dave (Mohammed) Daoudi, Mark Harman and Chris Fox:A Denotational Interprocedural Program Slicer.9th IEEE Working Conference on Reverse Engineering (WCRE 2002). 28 October - 1 November, 2002. Richmond, Virginia, USA, Pages 181 - 189.

コールグラフなどの構築ではなく，AST の変換によってプログラムスライスを計算しようという方法．

V が注目している変数（スライス基点）だとして，Slice(if B then S1 else S2, V) はif B then Slice(S1, V) else Slice(S2, V) となる，といったような処理を，各時点での変数の最新値を持ちながら計算していく．グラフ構築→ traverse という順序のかわりにいきなり計算しているだけのようにも見えるが．

式における SideEffect のあるなしを考慮している点はえらいかもしれない．関連研究として CodeSurfer を挙げているわりにほとんど比較がないので，この手法の利点がよく分からない．

_ 論文 ▲

Mark Harman, Rob Hierons, Chris Fox, Sebastian Danicic and John Howroyd:Pre/Post Conditioned Slicing.17th IEEE International Conference on Software Maintenance (ICSM 2001). Florence, Italy, November 6th-10th, 2001. Pages 138-147.

Conditioned slicing を応用して，Pre condition からの forward conditioning (Pre condition が成立している状態で実行されるプログラム文）と Post condition の否定からの backward conditioning(Post condition が成立しない状態へ寄与するプログラム文）の共通部分を抽出することで，「pre condition が成り立っているのに post condition が失敗する可能性のある（バグの可能性がある）」文集合を抽出しようというもの．

基本は conditioned slicing で，symblic state expression（システムがとりうる状態）を各プログラム文に対して伝播させていく．

pre/post conditioned slicing が空になるようにコンポーネント抽出を行う，あるいは verification 用途に使う，といったことが主目的となる．assert の積極的な定義と合わせて使えば強力なツールとなりうる？フィールド値などの条件定義をうまく与えないと他の手続きからの影響を除去しきれないかもしれないが．とはいえ，スライス系の研究の中ではかなり面白い部類に思える．

_ 論文 ▲

Mark Harman, Nicolas Gold, Rob Hierons, Dave Binkley:Code Extraction Algorithms which Unify Slicing and Concept Assignment.9th IEEE Working Conference on Reverse Engineering (WCRE 2002). 28 October - 1 November, 2002. Richmond, Virginia, USA Pages 11 - 21.

プログラムスライシングと Concept Assignment を併用することでプログラムを分解しようという試み．

Concept Assignment というのは，プログラム文の集合と Concept を対応付けるというものらしい．これに，各 Concept のプログラム文からスライスを計算することで Concept に関連したプログラム文を得る．また，concept の最終結果となるような変数 (Principal Variable) を最後に使ったプログラム文を重視して，それを基点に計算したスライスに含まれているところを重要度が高い，と分類する．（0から1の実数と定義しているが，　実際には 0と1だけを使っている）

そして，各 concept の Principal Variable の最後の利用場所から計算したスライスの共通部分の大きさによって concept 間の依存性を解析する．で，concept 間の関係を重み付きグラフとして出力する．

いちおうケーススタディとして小さなプログラムを相手に計算を行って，どの文が重要か，というところは計算している．しかし，concept 間の関係については，得られた結果をどう使うか，という問題がある，concept 同士の依存関係がわかっても，concept 同士の相互の関係がどういうものか分かるというわけではない，としている．

全体としては，こんなので効果があるのかなぁ，という落ち着きのない感じがする．アルゴリズムは丁寧に書いてあるのだが，スライシングや concept assignment の手法についてほとんど言及がないせいかもしれない．

_ 論文 ▲

David Binkley, Mark Harman:A Survey of Empirical Results on Program Slicing.

プログラムスライシングの survey．といっても，ほとんどの論文は読んだことがあったのであまり意味がなかったが，どのデータがどの論文から来たか，というのが分かるという点で便利な論文．

静的スライスはだいたいプログラムを３割くらいに減らせる，とか CodeSurfer はシステム依存グラフを事前計算してしまうのでスライス計算速度自体は早い，とか，dataflow based slicing は10万行ぐらいのプログラムでも相手にできる，とか．

スライシングの方法としてデータフローから計算するタイプとプログラム依存グラフを構築する方法と大きく区別できて，それにサポート技術として context-sensitivity やsummary edge やグラフの集約があるため，条件を対等にして比較することが難しい，と言っている．スライスの応用に関しても，たとえばプログラム理解であれば，単なる静的スライスを使う方法とPre/Post Conditioned Slicing などを使う方法ではだいぶ違った結果になるだろう，としている．

全体としては，プログラムスライシング技術が実用的であるといえるだけの証拠はある，というふうに締め括っている．ちょっと胡散臭い気もするが．何に使うか，という話から始まらないとどの目的にはどのスライス手法が有効，みたいな議論になっていかないので，まだまだ怪しい気がする．

_ 論文 ▲

David Larochelle, David Evans:Statically Detecting Likely Buffer Overflow Vulnerabilities.

LCLint でのバッファオーバーフロー検出機能に関する話．配列ごとに安全に読み書きできる範囲をmaxSet, minSet, maxRead, minRead として保持して，その範囲外になる可能性がある読み書きの文に対して警告メッセージを出す，というもの．

検出方法として，手続き内部で制約を伝播させていく以外にfor ループから，*buf++ のような定型句を見つけてindex や buf がどの範囲を指しうるかを検出する．こんなのでうまくいくのか，という気もするのだが，けっこううまくいくらしい．

C言語だと書き方がある程度決まりきっているからかもしれないが，実例として wu-ftpd や BIND などが上がっていて，きちんと実験しているツールなので，説得力もある．

_ 論文 ▲

David Evans, John Guttag, James Horning, and Yang Meng Tan:LCLint: A Tool for Using Specifications to Check Code.Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering.pp.87-96, New Orleans, Louisiana, United States, 1994.

論文というよりは LCLint の説明ドキュメントか．「こういう spec を書くとこういうエラーが検出できます」という見本集のような印象．

_ 論文 ▲

L.C.Briand, Y.Labiche, J.Leduc:Towards the Reverse Engineering of UML Sequence Diagramsfor Distributed, Real-Time Java software.Carleton University, Technical Report SCE-04-04, April 2004.

AspectJ Users ML で，「loop や if 文を検出するpointcut がほしい」と言っていた研究者の論文．

やってることは実行履歴からのシーケンス図の復元．contribution としては復元方法についてきちんと仕様として明記したこと．他の手法は形式的な記述が少なく詳細も十分でない，らしい．

スレッドIDとどのメソッドが実行されているか，とどのループや if 文が実行されているか，という情報を合わせて使って，プログラムの動作を追跡する．

分散環境についてもきちんと考えていて，RMI は呼び出し時にブロックするのでノード（JVM）ごとに local clock を１個だけ保持しておけばRMI に関しては呼び出し側の node ID + client thread ID を覚えておけば remote 側の呼び出し履歴と対応が取れる，ときちんと説明しているあたりはえらい．# 非同期な呼び出しは想定していないとも言うが……．

スレッド間の同期方法については，Runnable.start および run の呼び出しの監視が基本．データ構造を介した非同期な情報のやりとりについては，（開発者は組織などの標準的情報を持っているはずなので）どのクラスがスレッド間の情報転送に使われるかを設定ファイルとして用意するらしい．何か参考になるかと期待していたのに，がっかり．

実現方法について，AspectJ のソースコード風に表現しているところが親切．「AspectJ の future release では loop や if を　検出する pointcut が入る可能性がある」と書いてるあたりはいい加減だが，東工大の千葉先生のグループの Josh とかを使って自前で実装するぶんにはできるだろうし．

一通り目を通してみて，実際にはシーケンス図作ってないなーと思ったら論文タイトルの "Towards" に気づいてがっかり．ステレオタイプの "boundary" とか "control" とかまで書いてある図が一つあって「こんなのまで識別してるのか！」と期待してしまったが，単に設計書からのコピーだった．うーむ．

_ 論文 ▲

Tamara Munzner:H3: Laying Out Large Directed Graphs in 3D Hyperbolic Space.

ノード数は指数的に増えるが，ユークリッド空間は多項式でしか増えないので空間が足りない，だから hyperbolic space 上で配置して，Focus+Context view というユークリッド空間への写像として扱う．

関連研究はいろいろ．2Dでノードを階層的に配置するもの，平面上にビルのように積み重ねていくもの，3Dで木を描画するものなど．

基本はグラフから spanning tree を構築してあるノードから隣接したノードを球面上に配置していって，それらを回転させて見ていく，という感じ．

意外とグラフ表示関係のアルゴリズムはたくさんあるらしい．

_ Calendar ▲

hyCalendar 0.7.3 が Vector で公開された．

こちらが送るの忘れていたのに，更新してくださったのだろうか．感謝 :-)

_ 論文 ▲

Davide Balazarotti, Mattia Monga:Using Program Slicing to Analyze Aspect Oriented Composition.FOAL 2004.

プログラムスライスでアスペクト間の干渉を検出しようという Position Paper．A1, A2 というアスペクトがあるとき，それらをスライス基点として計算した S1, S2 がA1 ∩ S2 = φ なら干渉なし，とする方法．ただし，スライスが正確でないと（冗長なコードを含むと）false positive が出てしまうし，誤ったスライスを計算してしまうとfalse negative が出てしまう．いちおうスライスツールを作っていて実際的な AspectJ プログラムに適用可能なJava バイトコードスライスを計算できるようにしたい，としている．スライスはどんどん発散してしまうので，効果のほどは謎．

_ 論文 ▲

Kiarash Mahdavi, Mark Harman, Robert Mark Hierons:A Multiple Hill Climbing Approach to Software Module Clustering.19th IEEE International Conference on Software Maintenance (ICSM 2003), pp. 315-324, Amsterdam, The Netherlands, 22-26 September 2003.

モジュール間の接続を重み付きグラフで表現したものを入力として，モジュールのクラスタを再構築する．評価関数は i = モジュール内部辺の重みの総和j = モジュール外部辺の重みの総和各モジュールについて，MF = i / (i + j/2 )全体の評価関数 MQ = Sum of MFと定義する．実験では，重みとして関数呼び出しや変数参照の回数を取っている．

ただし，MQ は正規化されていないので順序値としてしか使えないらしい．なので，改善度合いの評価については微妙．MQ がどのくらいよくなったか，ということから実際のモジュール構成がどのくらいよくなったか，という直接的な評価ができない．

_ 論文 ▲

論文というよりは article だが．

David Evans, David Larochelle:Improving Security Using Extensible Lightweight Static Analysis.IEEE Software January/Feburary 2002, pp. 42-51, 2002.

Splint（以前はLClint と呼ばれていたもの）の実装に関するお話．NULL ポインタによる問題やリソース解放忘れ，バッファオーバーフローなどを防ぐために，/* @notnull */ のような annotation をプログラムに付加しておいて手続き単位でのフロー解析を行うというもの．基本は pre/post condition 間の接続チェック．バッファオーバーフローに関しては，間違いやすい gets などの関数を使っているかどうか，というのと引数のバッファ長が文字列より長くなり得るかどうか，といった検査を行う．このあたり，かなり heuristics を入れて実用性の維持を重視しているらしい．false positive と false negative と両方出るが，false positive/negative のどっちかをなくすために実用性を失うのは嫌だ，ということで警告メッセージの一部をフィルタするといったことで対処しよう，ということらしい．

_ 論文 ▲

Jinlin Yang, David Evans:Dynamically Inferring Temporal Properties.ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tols and Engineering(PASTE 2004), Washington, D.C., June 7-8, 2004.

プログラムの実行系列（イベント列；基本はメソッド）からパターンを認識しよう，というもの．ここでのパターンは，いくつかのテンプレートのマッチで，関連研究の中には機械学習の手法やErnst, Cockrell, Griswold, Notokin によるDynamically discovering likely program invaliantsto support program evolution.などが挙げられている．

イベントパターンのテンプレートとしては，Response (Pが起こった後には，必ずSが起きる）　-- SPPSS は OK だが SPPSSP は不可OneEffect (Pが１回以上起きたら，１回だけ S が起きる） -- SPPS は OK だが PPSS, SPSS は不可といったものを用意して，P と S として使うイベントを選んで，それが複数のイベントトレースでどのくらい出現するか，ということを調べて，推論する．イベント列の順序について甘いのは，並行性を強く意識しているためのよう．

いちおう Producer/Consumer パターンで小さな実験をして，イベント間の関係をそれなりに認識できているみたい．しかし，大規模システムでは，多数のイベントが発生するので，P, S の組み合わせをどうするか，また大量の実行履歴に対するマッチをどうするか，という問題を抱えている．このあたりはさすがに position paper っぽい．

_ 論文 ▲

M. Daoudi, L. Ouarbya, Mark Harman, Chris Fox, M.P. Ward:ConSUS: A Scalable Approach to Conditioned Slicing.

conditioned slicing は，入力パラメータなどに対する特定の条件を与えて "conditioned program" を生成して，その上で静的スライス計算を行うことで，特定の条件に対するプログラムだけを抽出してくるというもの．

というわけで，重要なのは，与えられた条件に対してその条件を伝播させていく Symbolic Execute というステップ．制御フローをたどりながら，if, while, assert などを，常に true/false となる場合に限って，簡略化していく．

問題は，どのくらい時間がかかるのか，ということだが，色々な　if 文の構造を自動生成してコードサイズごとにどう変化していくかをテストしている．グラフを見た限りではだいたい n の自乗ペースで，多項式時間なのでまあ reasonable ではないか，と言っている．意外と時間がかかってないといえばかかっていない．

conditioned slicing の特徴が簡単に説明されているので親切な論文．

_ 論文 ▲

H.A.Muller, S.R.Tilley, M.A.Orgun, B.D.Corrie, N.H.Madhavji:A Reverse Engineering Environment Based on Spatial and Visual Software Interconnection Models.Proceedings of the Fifth ACM SIGSOFT Symposium on Software Development Environments, pp.88-98, 1992.

Rigi というプログラム理解のためのビューアを作った，という話．基本はコンポーネントのグラフ化とその操作．

・Strongly Connected Components の識別

・コンポーネントの共通クライアントの識別

・複数のコンポーネントから共通で利用されているコンポーネントの識別

・コンポーネントの近傍の識別

・コンポーネントが変更された場合の影響波及解析

・全体図の表示

・関係の一部だけを抽出して表示

・中心となるコンポーネントの表示

・コンポーネントの密集の識別

・接続されていないコンポーネントの識別

・モジュール品質の表示

といった操作を適用する．説明では，基本はコールグラフから開始するよう．また，共通のデータを操作する関数群を固めて表示とか，密接に関連しあった関数群ごとにグループ化して相互接続辺だけを見せるとか，そういった操作によって，開発者が効果的にプログラム理解を進められる，らしい．

依存関係の検出と，そこからの抽象化を別フェイズとして切り分けている．これは次の文献からの引用．R.S. Arnold. Tutorial on software reengineering.ICSM 1990, pp.12-19, 1990.基本はコンポーネント間の依存関係をグラフ上で整理してサブシステム抽出して，ということになるらしい．

_ 論文 ▲

先ほどのつづき，関連研究だけ別に整理．この量はさすが 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 が大きくなってしまい作業しづらくなる，といった弱点はあるよう．

また，テストケースの選び方による偏りが生じるので，プログラム保守のタイミングなどで，「ここを直すのが一番影響が少ない」とかいったことを調べるにはこの手法は対応していない．（あくまで特定の機能がどこにあるかを理解することが目的で，　そのユニットが他の機能に関わるかどうかまでは考えない）

_ 学祭 ▲

洗って再利用する，リターナブル皿が推奨されているのは分かるのだけど，なぜ returnable なんだろう．reusable とかじゃない不思議．

_ 論文 ▲

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 ライセンスが適用された貴方は、落ち着いていて伝統重視の、とても洗練された人。時の厳しい選別に耐えた品のあるもの、優雅なものを好むタイプで、あくせくした暮らしは好きではないでしょう。といっても、それにふさわしいだけの心の余裕や、品位があればよいのですが、なかなか難しいかもしれません。浅ましく世間ずれした連中に出し抜かれてしまいがちで、経済的な生活レベルは普通かそれ以下になってしまうかも。慎ましく現状維持を念頭に置いた生活、そして侘び寂びや諸行無常の境地が、そんな貴方の日々の生活に自ずと潤いと美をもたらしてくれるでしょう。そんな貴方の恋愛面は、意外なことにとても積極的。俺が私がとどんどん自分をさらけ出し、相手に自分のエゴイスティックな刻印を残そうとするでしょう。でも大枠では、相手に合わせた恋愛をしていきそうです。

_ 読書 ▲

レイモンド・スマリヤン「パズルランドのアリス」文庫版の分冊１読了．

いわゆる論理パズル．分冊１は「不思議の国」のお話と登場人物を踏まえて展開している．解説が３分の１を占めていてけっこう丁寧だが，難易度の高いものもいくつか．もっとも，難易度が高くないと面白くないのだけど．ちょっとずつ時間つぶしに読んでいくのにわりとちょうどいい．

ちなみに原著名はAlice in Puzzle-LandA Carrollian Tale for Children Under Eightyらしい．

_ 読書 ▲

「AspectJ によるアスペクト指向プログラミング入門」読了．

感想はというと：・２章，３章が「振る舞いへの作用」「構造への作用」として dynamic crosscutting と inter-type declaration （と Static crosscutting）を区別していて親切． 特に，pointcut ごとの this, target, args などの内容が 日本語で解説されているのはリファレンスとして便利そう． 応用例として挙がっているのは・コンテキストの識別・キャッシュ・アクセス制御など．やっぱりこのあたりが自然に受け入れられるみたい．

面白いと思ったのが，MDA との関連性．ビジネスモデルと実装技術の統合をウィービングと考えて，MOF, QVT がウィービング記述だ，という考え方は，以前聞いた，ビジネスルールをアスペクトとして書いて~という話なんかよりはだいぶ自然に感じられる．

最後の７章は，パッチとしてのアスペクトの話．~tail/aspectj/ ではちょっとだけ，使えそう，という程度しか書いてないけれど，それをそこそこの規模のソフトウェアに適用するというケーススタディっぽいことをやっていて面白い．

やっぱり問題は統合開発環境からの支援が落ちること，理解容易性・予測可能性の低下あたりだろうか．こういうのを読むと，やっぱりアスペクトを使った表明記述の話とかをもう少し進めないとなぁ，と思うのだが，他の論文読みやら作業もたくさん．けっこう忙しくなりそう．

_ テンキー ▲

テンキーの仮想キーコードは VK_NUMPADx で VK_x とは違った．当たり前といえば当たり前かもしれないが．

外付けテンキーの NUMLOCK が入力したときだけ瞬間的に ON/OFF されるのが怪しいけれど．

_ 読書 ▲

「AspectJ によるアスペクト指向プログラミング入門」が研究室に届いたのでさっそく読むことにする．感想などは AspectJ 側の紹介ドキュメントとして更新される……予定．

鷲崎先生ありがとうございます．

_ 論文 ▲

Baowen Xu, Zhenqiang Chen:Dynamic Slicing Object-Oriented Programs for Debugging.

動的スライスへの適用論文．使っている手法は静的スライスの場合と変わってない．メソッドを，出力パラメータが依存する入力パラメータの集合，という形で各出力パラメータへの依存関係を設定している点とフィールドなどローカル変数以外の要素を入出力パラメータ扱いするところがいちおう新しいところなのだろうか．

_ 論文 ▲

Zhenqiang Chen, Baowen Xu:Slicing Object-Oriented Java Programs.ACM SIGPLAN Notices, Vol.36, No.4, pp.33-40, April 2004.

プログラムスライシングをオブジェクト指向プログラムに適用しようという論文．メソッド単位で PDG を構築して，メソッド呼び出し文が登場するごとに，そのメソッドの出力パラメータを基点にスライスを取った結果を加えていくという形になるらしい．内部実装が存在しない場合はすべての入力値がすべての出力値に依存するとみなす．フィールドは全部パラメータ扱い．

それ以外にも，スライス範囲をしぼったスライシングも提案している．Object Slicing が１個のオブジェクトに，Class Slicing が１個のクラスに注目したものらしい．どのくらい役立つのかは不明だが．

_ Calendar ▲

謎のバグ報告が一つ．EXE と同一のディレクトリにあるデータファイルが読めないor読む途中でエラーが出ているらしい．

とりあえず Exception.Message を吐かせるコードを追加して使ってもらうしかなさそう．WinXP Pro 環境で使っているのであまり間違いはないはずだが…．ファイルの配置されているディレクトリと中身のどちらが原因だろう？

_ Calendar ▲

フリーウェア収録した雑誌が２冊ほど届く．あんまりこの手の雑誌は買わないのでもらってみたのだが，もらっても読まない雑誌は読まない，という気がしてきた．