netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-11-29 古い日記からの変換データ [長年日記] ▲
_ [論文]実行履歴からのシナリオ抽出 ▲
Glenn Ammons, Rastislav Bodik, James R. Larus:Mining Specifications.Proceedings of POPL 2002.
実行履歴として引数の値の情報を含めた関数呼び出し列を持ってきておいて，抽出したい特定の関数だけをシナリオとして残して，そこからオートマトンを生成する．
オートマトン学習のコストを下げるためにシナリオの長さをある程度で切る必要があったり，関係のあるメソッド呼び出しだけを使うためにフロー解析を使ったりしているらしい．
オートマトン抽出した結果の使い道が verification となっていて，論文での評価実験でも各プログラムからのオートマトン生成結果で検証を行っている．実行履歴はプログラムの入力に依存するので，設計時の情報に比べると，生成されたオートマトンは情報の一部が落ちている可能性があるのだが…．用途としては verification よりは設計時のオートマトンとの比較によるトレーサビリティの確保などのほうが面白そう．
2004-11-28 古い日記からの変換データ [長年日記] ▲
_ [論文]コンポーネントの使い方抽出 ▲
John Whaley, Michael C. Martin, Monica S. Lam:Automatic Extraction of Object-Oriented Component Interfaces.Proceedings of ISSTA 2002, pp.218-228.
コンポーネントの状態遷移を起こすようなメソッドを識別し使い方をテストケースの実行履歴や静的解析結果から発見するような方法．
静的解析では，・どのメソッドがどのフィールドに依存しているか・例外を投げるような条件を調べておき，実行履歴を解析した結果からどのようなメソッド呼び出し順序が行われているかを出力する．
フィールドごとに状態遷移を分割してしまうことで，状態遷移を簡略化するところがポイントっぽい．
_ [論文]アスペクト指向設計な話 ▲
Charles Zhang, Hans-Arno Jacobsen:Resolving Feature Convolution in Middleware Systems.Proceedings of OOPSLA 2004, pp.188-205.
ミドルウェアの設計において，縦方向（階層的）な設計に加えて横方向の分解（horizontal decomposition）を導入しましょう，という話．
モジュールの階層的な機能分解は今までやってきたが，ミドルウェアはけっこう色々な機能を含んでいて，モジュールの明確な境界ができないままにコードがあちこちに分散する．主な提案事項は次の通り．
1. アスペクトは，システムの主要な機能に対して相対的に定義されることを認識すること．
たとえば，分散アプリケーションでは「ローカル呼び出しの最適化」が横断的関心事となるが，普通のアプリケーションでは逆に透過的なリモート呼び出しのほうが横断的関心事となる．
2. 主要な機能については，凝集度が高くなるように分解を行うこと．3. アスペクトは，機能分解の結果を横断したものだけにする．（たとえば，横断してなければクラスでよい）4. クラスで構成するアーキテクチャを安定した形に保つ．（これは fragile-code problem を防ぐため）5. リファクタリングで凝集度などを高く保つこと．
基本的には，AspectJ でのコーディングを強く意識した提案なのでNECの野田さんたちのモデリング方向とはちょっと違う．
core - aspect，aspect - aspect の関係を整理するのにマトリクスを作っているが，使い方は不明．ただ，誰が誰を crosscut しているかを管理しておくのは重要だということは何となく分かる．
2004-11-27 古い日記からの変換データ [長年日記] ▲
_ ワイン ▲
ロマネ・コンティ2001のオークションがあるらしいと店の発行する宣伝メールを見てオークションページを覗いてみたら，その宣伝メールの送信時刻から１時間経たずして落札確定価格(約36万円)の入札で終わってた．さすがというか何というか．http://www.rakuten.co.jp/yuhara/460416/595262/
2004-11-25 古い日記からの変換データ [長年日記] ▲
_ SIGSE出張 ▲
ホテルウィングインターナショナル後楽園はかなり便利な位置にあることは判明．ただ，無線LANがあるのにDHCPが死んでるのかIPが取れない．仕方ないので b-Mobile を使う．
１Ｆの部屋は一部携帯の電波が届かないことがある，という但し書きの通り，携帯電話やPHSは窓際（ベッドの上）なら接続できるがテーブルからではアクセスできないみたい．微妙．
_ [論文]Traits の実際の適用 ▲
Emerson R. Murphy-Hill, Andrew P. Black:Traits: Experience with a Language Feature.Companions of OOPSLA 2004, pp.275-282.
本会議のほうではなくショートペーパーなんかが収録されている Companion のほうの論文．
メソッドの集合を扱う Traits を実際に使って，文字列の連結をツリー構造として扱う Rope というクラスをString と一緒に定義してみたという話．
String と Rope では，同じような特性を持っているので横断したような部分を Traits に取り出している．結果としては，Traits は理解しやすい概念でコードの再利用も容易だった（Traits の中のメソッドを使った数が多かった）が，Traits は black-box 的に使いたくなるので，String と Rope の構造にあわせた改造というのができず，非効率的な実装になってしまう可能性があったらしい．（Traits を使わない場合は，コピーしてから実装に合わせて書き換え，という形式になっている）
また，Traits の情報を見ることができるツールなどとセットでないと難しいだろう，とも述べている．
アスペクトによる実装についても少しだけ触れられていて，アスペクトの場合は Rope のツリー構造とツリーのバランス調整機能をきれいに分解はできたけれど，バランスを調整するアスペクトのほうは，Rope クラス決め打ちの実装になってしまって，再利用は Traits のほうが楽だろう，と述べていた．
_ [論文]Generics クラスの型パラメータの自動決定 ▲
Alan Donovan, Adam Kiezun, Matthew S. Tschantz, Michael D. Ernst:Converting Java Programs to Use Generic Libraries.Proceedings of OOPSLA 2004, pp.15-34.
Java Generics の登場にあわせたプログラム変換についての論文の１本．クラスを Generics クラスに書き換えたときに，それを使っているクラスに適切な型パラメータを付与できるよう自動で型推論を行うというもの．
アルゴリズム的には，各変数の Points-To セットを作って複数の取りうる型がある場合は共通の親を取って，というもの．ただし正解は１つ以上ありうる（一番緩くするか，一番厳しくするかなど）ので型キャストができるだけ減るのがいいのだろう，という立場で考えているらしい．
論文としてはそのアルゴリズムの解説．結果のお役立ち度はそれなりな感じがする．テンプレート化（総称型の導入）リファクタリングを行うときには，この種の技術を使うのが正しそう．
_ [論文]Vertical Profiling ▲
Matthias Hauswirth, Peter F. Sweeney:Vertical Profiling: Understanding the Behavior ofObject-Oriented Applications.Proceedings of OOPSLA 2004, pp.251-269.
オブジェクト指向プログラムではシステムの提供する機能を仮想化して取り扱う（スレッドやガベージコレクションなど）．で，システムの複数のレイヤから集めたデータを一緒に調べれば，システムの性能についての理解が深まるだろうという話．"Vertical" と付いているのは，システム階層を横断して情報を集めることから，らしい．
たとえばキャッシュのヒット率と１サイクルあたりの完了命令数とスレッドの切り替え数とか，パフォーマンス系のメトリクスを時系列に一緒に並べて相関を調べたりする環境を構築している．
ケーススタディでは，主に Virtual Machine レベルとハードウェアレベルのデータを見比べることに使っている．パフォーマンスチューニングなんかの使い道か．
_ [論文]実行時のフェイズの認識 ▲
Andy Georges, Dries Buytaert, Lieven Eeckhout, Koen De Bosschere:Method-Level Phase Behavior in Java Workloads.Proceedings of OOPSLA 2004, pp.270-287.
プログラムの実行履歴をある程度の大きさで（時間消費量を基準に）フェイズに区切って，それぞれのフェイズでのパフォーマンスメトリクスを調べて（たとえばキャッシュのヒット率とか），どのあたりにボトルネックがあるとかを調べる手法の提案．
Java では Runtime 環境も含まれるので，過去の C などを対象にした研究よりも難しい，らしい．
関連研究で，この手のフェイズ分割手法についていくつか触れられているのだが，固定時間間隔で区切る方法や，実行時間が一定の閾値に達するような手続きを基準に分解を行うものが多いよう．
実行履歴のフェイズへの分解については，目的は違うが，このあたりの関連研究は調べてみる必要がありそう．
_ [論文]単位計算用クラスの導入 ▲
出張前に，一部放置していた論文を消化．
Eric Allen, David Chase, Victor Luchangco, Jan-Willem Maessen, Guy L. Steele Jr.:Object-Oriented Units of Measurement.Proceedings of OOPSLA 2004, pp.384-403.
いわゆる単位系（時間・距離など）を数値計算に導入する仕組みとしてメタクラスと総称型を使うことを提案した論文．
次元パラメータ D を受け取る Unit メタクラスを使って，Mile や Meter は Unit[Length] に属するクラスとして，Second や Minutes は Unit[Time] に属するクラスとして定義する．
で，あとは単位の組み合わせを扱えるようにCanonical form（Length * Time * Length^-1 == Time など）を定義したり型変換関数を定義したり，各単位の次元値をパラメータ化してLength^n (int n) のような動的な型の表記を可能にしたり，といったことをしている．
このアプローチの場合，メタクラスが一つの次元を整理してくれるので，摂氏・華氏のような単位混在も可能だし，ログスケール系への拡張も容易である，らしい．言語の拡張が含まれるのでいきなり導入して使えるというものではないが．
2004-11-22 古い日記からの変換データ [長年日記] ▲
_ [Java]Generics の制限 ▲
Generics で型パラメータを static メソッドに与えようとしたら怒られた．また，instanceof でも比較対象に型パラメータを使えないらしい．
これらは，C++ template の場合と違って，型情報が実行時には落とされてクラス自体は１個しか存在しないためらしい．なので，型パラメータごとに Singleton なインスタンスを作ろうとしたりはできないらしい．
Singleton 問題を回避するのに，Factory パターンを使って型パラメータごとに Factory を１個生成して，それぞれの Factory が Singleton なインスタンスを管理するようにしてみた．
