netail.net

_ 読書 ▲

森博嗣「黒猫の三角」を読み終えた．

_ Clotho ▲

…再び電源を投入すると，何事もなかったかのように起動．なんだったんだろう？

_ Clotho ▲

Clotho が Physical Address とかを吐きながら青画面で死亡．起動しなくなった．原因はメモリだろうか…．

_ ネットワーク構成 ▲

下宿のネットワーク構成を変更．Asteria (Libretto) の２枚差しカードで NAT を動かして，Clotho を 192.168.0.2 に設定，外へ出られるようにした．これで Wavellite はファイルサーバの役目だけとなり，今までよりもさらに影が薄くなってきた．

_ 読書 ▲

森博嗣「地球儀のスライス」を読破．

_ MERP ▲

Middle-Earth Role Playing を遊んでみた．感想は・参照する必要のあるチャート多すぎ・キャラクターシートにアイテムなどを書き込める場所がない・能力修正より乱数が強すぎる？といったところ．

_ 論文 ▲

JML について調べてる最中に偶然見つけた論文．

Maximilian Storzer, Jens Krinke, Silvia Breu:Trace Analysis for Aspect Application

出典は Workshop on Analysis of Aspect-Oriented Software (AAOS 2003) as part of ECOOP 2003, July, 2003

実行履歴トレースの差分から impact analysis をするらしい．役立つのかどうかは謎．

_ 論文 ▲

FSE 2003 論文整理もこれで終わり．

FSE Session IX: Safety and Security

S. Yong, S. Horwitz:Protecting C Programs from Attacks via Invalid Pointer Dereferences

「ポインタが指してよい領域」を保持したメモリマップを作っておいて，それに対する書き込みをチェックする．また，フロー解析をして，ポインタが予期せぬ領域を指す可能性があるものをunsafe とマークしておいて，unsafe ポインタのアクセスだけを監視すればオーバーヘッドを抑えられる，という話．unsafe な read は調べるべきか調べないべきか，という議論はあるが，完全に実用を考えた構成になっている．

K. Sen, G. Rosu, G. Agha:Runtime Safety Analysis of Multithreaded Programs

Temporal Logic でデータアクセスの順序を検証しようというもの．データの流れを Lattice 化して検証しているようなのだが，空間も時間も O(w・2^m) で m は Temporal Logic の式の数，w は Lattice の幅（イベントの「同期」数に依存）らしくて，コスト的によいと言えるのかどうか謎．個人的には Temporal Logic を誰が書くんだろうというのも気になる．誰かが，「オブジェクト指向言語でなら，もうちょっとインスタンス共有とかうまい方法で状態数が減りそう」とか言っていた．

_ 論文 ▲

FSE 2003 論文整理はさらに続く．

FSE Session VIII: Component-Based Software Engineering

F. Xie, J. Browne:Verified System by Compsoition from Verified Components

コンポーネントの検証の話．After(xxx) Never (yyy) Until (zzz) のような動作特性をボトムアップに検証する．Assumption (ソースコードやマニュアルから自動生成の予定）とProperty (調べたい特性) を比較するんだーという，目的がはっきりしている点は好感が持てた．

S. McCamant, M. Ernst:Predicting Problems Caused by Component Upgrade

アプリケーションはコンポーネントの実装に依存しているかもしれないのでBehavioral Subtyping では不十分．( Pre_app → Pre_comp )∧( Pre_app ∧ Post_cop → Post_app )というのが良い，と言っている．で，実際に検証して，「このバージョン変化でこの部分は動作しなくなる可能性がある」と表示するということになるらしい．ただ，コンポーネントの不変条件とかは自分で書かないといけないらしいので，そのあたり，実用化には厳しい．

H. Rajan, K. Sulivan:Eos: Instance-Level Aspects for Integrated System Design

Mediator としてアスペクトを使いたいので，アスペクトのインスタンスがほしい．型ベースで，すべてのインスタンスに反応するようなのは嫌．また，対応相手がいない場合や１個のインスタンスに複数のアスペクトのインスタンスが貼り付くようなのも考えたい．そこで，インスタンスレベルアスペクトというのを考えた．要は，イベント処理を言語要素にしたくて，単に new Aspect(obj1, obj2) とか叫びましょう，というものなのだが，これ，アスペクトを生成するのは誰か，という問題が出てくるので，かえって複雑度を上げてたりはしないのだろうか？

_ 論文 ▲

FSE 2003 論文整理その５．

FSE Session VII: Software Analysis and Model Checking

Stan Jarzabek:Eliminating Redundancies with a "Composition with Adaptation" Meta-Programming Technique

XVCL を使って，コードをパラメタライズすることで冗長性を減らしましょう，というもの．発表の後で，「継承と Generics と XVCL ではどれがいいんですか？」と聞いてみたのだが，「リファクタリングで複雑なモジュール構造を導入するのは良くない，リファクタリングで大事なのは冗長性を減らすこと」みたいな考えを持っているらしい．メタプログラミング（というより「コード本体のテンプレート化」か）は難しくないのだろうか，とは思わなくもないが，ただの Generics よりはコード本体部分をパラメータ化できる強みがある．コードの冗長性はいいが，理解容易性やメンテナンス性はどうなのか，とか質問もあって，みんな興味は惹かれていた様子．

Yung-pin Cheng:Towards Scalable Compositional Analysis by Refactoring Design Models

リファクタリングの話かと思っていたら，モデル P から，解析しやすく意味は等価な P' を作りましょう，という話だった．こんなの考える人がいるんだなーと感心はしたが，興味がないので飛ばす．

_ 論文 ▲

FSE 2003 その４．正確には論文ではなく Invited Talk だけど．

Ari Jaaksi:Assessing Software Projects - Tools for Business Owners

色々なツールをどう使うか，という話だったのだが，その中ではエラー数グラフの読み方が面白かった．・時刻に対してエラー数が増えないのは，テストが正しくない可能性が高い．・新しいエラーを見つけながら古いエラーは修正されるはずである． エラーが未解決のままなら，開発は進展していない．という感じで考えるらしい．また，Product Family 間でドキュメントやテストを共有することでコストを削減できる，といった発言もあった．

_ 論文 ▲

FSE 2003 その３．

FSE Session V: Validation and Verification

J. Krinke:Context-Sensitive Slicing of Concurrent Programs

スレッドの扱いをきちんと行った論文．普通は「すべての可能性を」依存関係に含めるが，その中から，ありえないパスを除去するためにコンテキスト情報を使う．依存関係を解析するときに「スレッドＡなら１行目か５行目から，スレッドＢなら２行目から」依存関係が来る，という情報を持ってスレッドを追いかけていくことで，「スレッドＡの６行目からの依存関係はありえない」というようにスライスの正確性をできるだけ保持しようとする．

O. Tkachuk, M. Dwyer:Adapting Side Effects Analysis for Modular Program Model Checking

ある検証範囲を設定して，その中での Side Effect を抽出しようというもの．ここでの Side Effect というのは「データの変化」っぽいのだが．将来的には，連動するクラスを勝手に探すとかいうのも考えているらしい．

_ 論文 ▲

FSE 2003 論文その２．

FSE Session IV: Software Process and Workflow

M. Muller, F. Padbera:On the Economic Evaluation of XP Projects

XP が儲かるか？という話．経済モデルとして，Net Present Value Model （だったか？）:現在の１＄ ＞ 翌年の１＄＋Discount Rate という計算を考えて，

XPは「ペアプログラミングなので開発は少し遅れる」，普通の方法は「品質がXPより少し下がるのでその品質保証分作業時間が必要」というSpeed Factor, Defect Factor という二つのパラメータを考えて，パラメータの変化でどのくらい得られる金額が変わるかを計算した論文．ある程度の Speed Factor と Defect Factor があるなら，Market Pressure が大きくなると(Discount Rate が上がると)XP のほうが儲かりやすくなるらしい．

Communication Overhead を考慮していなかったり，どうやって二つのパラメータを推定するんだ，とかモデルにも色々な問題はあるのだが，最初に言ったという意味ではすごくえらいと思う．

_ 論文 ▲

続いて，FSE 2003 の論文整理．

FSE Session I: Requirements Engineering and Design

S. Uchitel, J. Kramer, J. Magee:Behaviour Model Elaboration using Partial Labelled Transition Systems

仮定，制約 から シナリオ（シーケンス図）を書いて，それを読んで Labelled Transition Model を生成して解析しましょう，というもの．

従来は，モデルに書いてあるものは許可，書いてないものは禁止，だったのだが今度は許可と禁止は明示して，そうでないものは Undefined として，状態変数と，シナリオごとの事前条件から，「この状態ではこういう遷移の選択肢があるけど，これは未定義だよ」とユーザにフィードバックをしようというもの．設計フェイズで使うと面白そうなツール．わりと実用的に見えたけど，どうなんだろう．

R. Jeffords, C. Heitmeyer:A Proof Strategy for Efficient Verification of Requirements Specifications Using Composition and Invariants

全然よくは分かっていないのだが，検証コストが高いものを，Σ → Σ1 ＋ Σ2 に分解してから個別に検証をかけよう，という Compositional Approach という言葉だけが印象に残った．最近，スケーラビリティが問題になることが多いせいだろうか．

_ 論文 ▲

IWPSE2003 論文整理その４．

Ahmed E. Hassan, Richard C. Holt:The Chaos of Software Development

ある一定の期間の，ファイル変更回数を「各ファイルが変更される確率」とみなして，Entropy を計算する．変更が特定ファイルにかたまるほど Entropy が下がる．正規化する都合上，ファイル数が増えると Entropy が小さくなるので変更される Active Set のサイズで見よう，とか言っている．ちなみに，期間はリリース回数や時間，変更回数などで見る．Future Work として，複雑度 Metrics との対応や，リファクタリングやアスペクト抽出の手がかりなどを挙げていた．

John Champaign, Andrew Malton, Xinyi Dong:Stability and Volatility in the Linux Kernel

変更されてリリースされた回数÷総リリース回数 で得られる確率から，「変更される確率」を予測しようという話があって，それを Linux Kernel に適用したらあまり合ってなかった，らしい．予測しようというだけえらいいとは思うのだが，もうちょっと考える必要があるのかもしれない．

_ 論文 ▲

IWPSE2003 の論文整理その３．

Reeigineering a PC-based System into the mobile Device Product Line

PC上で動かす City Guide アプリケーション（JDK1.4, J2SE）をMobile デバイス用の J2ME or J2SE（しかもディスプレイやメモリも制限される）上で動作させる．XVCL でメタコンポーネントを作って，目的デバイスに合わせたコードを生成するようにした．

個々のコンポーネントを作るのは，コンポーネントの数または大きさが増加するし，共有コードをうまく扱えないし，冗長で無駄が多いので，メタ情報を使ったほうがよい．実行時アーキテクチャと開発時のアーキテクチャは別物．実行時: Components, Connectors, ...開発時: 変更をどう扱うかunit of change != unit of execution

C. O'Reilly, P. Morrow and D. Bustard:Lightweight Prevention of Architectural Erosion

ソース変更→依存関係の変化，をビューアで見ようとかいうものらしい．ArchAngel というツールを実装しているあたりは偉い．

_ How History Justifies System Architecture (or not) ▲

変更履歴 → 同時に変更された Entity → Couplings Metricsを計算する．ソースコードから，抜き出す情報は，クラス名やメソッド名と，その行番号の対応だけ．その範囲の行が変更されたら，メソッドが変更されたとみなす．

Coupling を dotplot (クローンの場合と違って多段階だが) で表す．A が10回，Bが4回変更されていて，同時に変更されたのが3回なら，A→B は 30％，B→A は75％の結合度となるので，非対称の絵になる．絵の中で，結合度がある区画にまとまっているほどモジュールの強度が良いということになる．また，エディタ上での変更に対して，この結合度を使って変更波及可能性を出したりしてプログラマの支援を行う．

_ 論文 ▲

IWPSE2003 の論文整理その２．

Using Coordination Contracts for Flexible Adaptation to Changing Business RulesM. Wermelinger et al.

Service を computation interface （機能の実装）とconfiguration interface （必要な条件パラメータを返す）という二つのinterface を持つものと考えて，Coordination Contracts を記述する．Coordination Contract は，サービスに対するメソッド呼び出しに対して，Configuration インタフェースを使って条件をテストし，when ... do {} という書き方で Dynamic AOP 的に手続きを実行する．Instance ベースで，システムを止めずに BR を追加できたりするらしい．

Dynamic Behavior and Protocol Models for Incremental Changes among a Set of Collaborative ObjectsNguyen Truong Thang, Takuya Katayama

1 concern = 1 collaboration と考えて，Separation of Concerns を実践する．incremental change を collaboration の追加と考えて，モジュールとして扱う．別々に定義した collaboration を形式的手法で合成するらしい．

Class Refinement for Software EvolutionHiroyuki Ozaki, Katsuhiko Gondow, Takuya Katayama

クラスの継承は「Class Refinement （機能の変更）」と「Augmentation （オーバーライドなしの継承）」に区分できる．CLASSICJAVA (Javaのサブセットらしい）上でA# を拡張した A と B# を拡張した B があるとき，A# と B# の Augmentation の関係があり， A と B に Augmentation であるときにA# + B# が A + B と Augmentation であることを形式的に示すらしい．インスタンス変数が親子クラス間で共有していないこと，といった微妙な制約だけでよいらしい．CLASSICJAVA については Flatt, Krishnamurthi, Fellenisen, "Classes and mixins", POPL 98, を参照．

_ 論文 ▲

IWPSE 論文の整理その１．

Reconstruction of Successful Software Evolution Using Code Clone DetectionF. Van Rysselberghe and S. Demeyer

バージョン間のクローンを解析して，システム内部の変更なしのコピーを識別したりリファクタリングの手がかりを得よう，dotplot による可視化で，メソッドの移動などを識別したりコードクローンの exact マッチからメソッド抽出リファクタリングなどをしようという話．発表の後で本人に聞いてみたら，クローンの図にはパッケージ単位などではなくシステム全体を使うらしく，「100 万行くらいになったら小さいクローンはどうするの？」と聞いたら，「難しい，困ってる」という感じで返ってきた．ちなみにクローン識別には Duploc を使ってるらしい．「違いを見つける」ことで「同じところを見つける」らしい．

Beyond the Refactoring Browser: Advanced Tool Support for Software RefactoringT. Mens, T. Tourwe, and F. Munoz

リファクタリングは，1. リファクタリングをするべきか，2. どこにどのリファクタリングをするのか，3. リファクタリング作業，4. リファクタリングの効果を評価，という４ステップで実行される．ここで，論理型言語で「使われていないパラメータが存在する」などといった「不吉な臭い」述語を記述しておいて，それらがtrue になったらリファクタリングを提案する．小さなリファクタリング（メソッドの移動，名前の変更，etc）の組み合わせでリファクタリングを実行する．また，メトリクスを使ってその効果を計る（あくまでリファクタリング終了後に効果を計るだけの様子で，別に「どのリファクタリングが効果的か」というのを示すわけではない）．また，リファクタリング作業が終わると，述語を再評価して新たなリファクタリング候補を提示する．

_ 論文 ▲

論文の題目が長くなって，ページのヘッダに登場する部分がページ番号と重なるなぁ，と困っていたら，ipsjpapers.sty 的には title タグを\title[ページのヘッダに出したい題目]{先頭ページの題目}と書けば通るらしい（サンプルを見ていて気付いた）．微妙な仕様だ．

_ [hyCalendar] 高速化実験中 ▲

ここ最近いじってないなーと，ふと思い立って起動速度を早くできないか色々実験．しかし，明確なボトルネックが発見できず，今のところあまり目立った成果は出てません．もう少し粘ってみます．

_ [近況] 新入生歓迎パーティ ▲

研究室ではなく，滞在してる College のほうのパーティ．カナダのビールを初めて飲んできた．長いことお酒飲んでなかったせいか，少ししか飲んでないのにふらふら．

「カタンの開拓者」がドイツでは人気あるんだよ，とか，バンクーバーではゲームが手に入りやすくていいよ，とかいう話をしてきた．しかし，英語でのＤ＆Ｄ関連の会話にはさすがについていけず．バトルアクスとかファイアボールとかの単語は分かるのだけど，動詞あたりの言い回しがよく分からず．

Junior Fellow Speaker という，持ち回りで自分の専門分野の内容を紹介するシリーズで喋ってよ！と言われて，面白そうだったのでなんとなく引き受けてみた．発表は２月半ばの予定．ちょうど修士論文とかの時期に重なるけど，その時期はきっと時間的に余裕があると信じたい :)

_ [近況] 久しぶりに更新 ▲

来週末締め切りの某国際会議に full paper が間に合うかな？と思って黙々と作業してたんですが，前回 reject されたときの査読コメントに対抗できるような実験がまったく間に合いそうになかったので（１本国内の別締め切りがあったり，研修の宿題があったりで），ちょっと諦めモードに入りました．

その分，来週の金曜は，ソフトウェア科学会の大会に金曜だけ参加しに行くことにしました．NAISTに行くのは実は初めてです．

_ AOAsia2008 論文募集の締め切り延長 ▲

AOAsia2008の論文締め切りは９月１４日まで延長されました．ポジションのほうは変わらず１０月２２日です．