netail.net

_ OOPSLA ▲

Proceedings が ACM のディジタルライブラリからアクセスできるようになってた．

Current Year 2004 を選ぶと Companions of OOPSLA（パネルやポスターなどの掲載のもの）が当たるのは相変わらずで，過去の Proceedings のリストからでないとアクセスできない．

_ 研究会 ▲

学生の登録補助を使ってソフトウェア工学研究会に登録することにした．特典としては研究会のPDFが自由に取れるようになることで少し利便性が上がるかもしれない，というぐらい．研究会参加費がタダになるのは，あまり研究会に参加してないのであまり影響がない．

_ [論文]AspectJプログラムの性能計測 ▲

Bruno Dufour, Christopher Goard, Laurie Hendren, Clark Verbrugge, Oege de Moor and Ganesh Sittampalam:Measuring the Dynamic Behaviour of AspectJ Programs.Proceedings of OOPSLA 2004, pp.150-169.

AspectJ プログラムのパフォーマンス計測の話．どこかで見たなーと思っていたら以前読んだテクニカルレポートの採録版らしい．

気のせいか，OOPSLA ってパフォーマンス系（実行速度，メモリ消費量など）の話が最近多い？

_ [OUCC]部室 ▲

学祭用に一部のハブやディスプレイを持っていくためにネットワークなんかの構成も一部変えた影響か，ネットワークに接続できなくなっていたものを復旧．結局，ルータのDHCPサーバがこけていたのが原因で，学祭用体制は問題ではなかった．前回もこれが原因だったので，ルータが故障している？

学祭の実働部隊の裏に，ネットワーク整備から部室掃除まで環境整備をこなせる保守チームが必要なのかも．

_ 出張準備 ▲

研究会行きのホテルだけとりあえず確保．東洋大学白山キャンパスは三田線で行けばいいようなので，水道橋のホテルウィングインターナショナル後楽園を取ってみた．１階だと6900円らしいので，わりとお手ごろっぽい感じ．

_ [OUCC]スマブラDX ▲

書くのを忘れていたが，部室GCのスマブラDX で「対戦回数が6800回になった！１プレイ１円未満？」が出た．

約２年かかっているとはいえ，本当に達成されてしまうとは．

_ [OUCC]LAN再構築 ▲

部室LANの再構築．傷んだLANケーブルを交換して，ハブの構成と位置も少し変更して，ノートＰＣ使う人でかつワイヤレスだと困る人がケーブルを追加しやすい位置に移動．

ワイヤレスのアクセスポイントも再設定．一時期よりはだいぶ回線が安定するようになった気がする．

一台，以前から調子の悪かった（しばらく起動しているとフリーズするのを繰り返していた）小型PCがメモリ破損らしきBEEPを鳴らして起動しなくなったので，とりあえずLANから切り離しておくことになった．

_ [hyCalendar]Todo管理 ▲

Todo管理用チェックボックスリスト（TListView）が，アイテムの名前編集中にもアイテムの位置入れ替えが有効になっていることが判明．

アイテム位置入れ替えが作動しても編集相手は場所で選ばれているので，本来編集するはずではなかったアイテムが編集できてしまう．かなり危険．

FOSEから戻ってきたら直したいところ．

_ [work]ICSE ▲

FOSEのホテルの部屋ではネットワークがまったく使えないので電波状態の良い会場にいる間に作業する．

2nd author な ICSE に出した paper の rejected 通知到着．評価的には，手法説明の曖昧さや関連研究への言及の不備をつつかれているが，そんなにひどいことは言われてない気がする．

_ FOSE2004 ▲

FOSE2004 終了．

今回の収穫(?):

・数名，名前しか知らなかった人の顔を認識した

・紙名さんの発練での増原先生の指導を見ることができた

・東工大のアサーション記述用のアスペクト指向言語の話が聞けた

あるようなないような．

_ [hyCalendar]0.9.1 ▲

FOSE 移動中などの間の作業時間で修正した 0.9.1 をリリース．プログラム変更的にはほとんどないが，時間があったのでサイトにしかなかった faq.html がヘルプに取り込まれたりしている．

_ [OUCC]新入部員(?) ▲

前に話だけ聞いてた立命館大学の人が部室に来たところに初めて会った．さすがに遠いはずなので，来るのは休日だけだったりするのかな？

外部の人で実質的に部員だった人は今までもいたけど，わりと久しぶりかもしれない．

_ [論文]オブジェクトの所有関係の解析 ▲

Samuel Z. Guyer, Kathryn S. McKinley:Finding Your Cronies: Static Analysis for Dynamic Object Colocation.Proceedings of OOPSLA2004, pp.237-250.

静的解析を使って，オブジェクトの所有関係を見つけて，その情報をガベージコレクタの動作に反映させようという話らしい．使っているのは Java バイトコードに対する points-to analysis で，GCのパフォーマンス向上に使った評価の話のようだが，同様の情報はクラス間の関係図を作るといった用途にも使えそう．

_ [論文][work]アスペクトの振る舞いの認識 ▲

Martin Rinard, Alexandru Salcianu, and Suhabe Bugrara:A Classification System and Analysis for Aspect-Oriented Programs.Proceedings of the 12th FSE (FSE2004), pp.147-158,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

関連研究．アスペクトがシステムに与える振る舞いの影響をAugmentation （アスペクトは常に実行される），Narrowing （ある条件下でアスペクトは実行される），Replacement （static crosscutting などシステムの一部を置換するもの），Combination （その他の振る舞い）に分類して，またデータに関する影響をOrthogonal （クラスとアスペクトは別個のフィールドを触る），Independent （一方が書き込んだフィールドには，他方は書き込まない），Observation （メソッドだけが書き込み，アドバイスが読むだけ），Actuation （アスペクトが書き込み，メソッド側は読むだけ），Interference（アスペクトもメソッドも同じものに書き込む）に分類し，あとは依存関係解析によって，メソッド-アドバイス間，アドバイス-アドバイス間での影響を調べようというもの．

フィールドの集合を適当に抽象的な「structure フィールド」といった名前を付けたものにマッピングしているようで，わりと面白いアイディアな気がする．

静的解析ベースで，レポートとして出力されてくるので，コンパイルした後に実行するとかいう使い方ができそう．

アドバイスがどのメソッドを呼んでて，その結果どんな作用を起こしているかについてはメソッドごとのサマリのようなものを作っているみたい．ただ，アドバイスの中で他のアドバイスの実行まで検出してたら解析がきちんと終了できるのかどうか良く分からない．

_ [論文]モデルとコードの対応調査 ▲

Alexander Egyed:Resolving Uncertainties during Trace Analysis.Proceedings of the 12th FSE (FSE2004), pp.3-12,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

Trace Analysis って何だろうと思っていたら，実行履歴の解析ではなくて，モデルとソースコードの対応（いわゆる追跡性）の解析だった．

モデルとコードの対応を included/shared/excluded で記述して，Footprint Graph というものでrefine していくらしい．"M is F" 以外に "M isAtLeast F" や "M isAtMost F" のように持ってる知識を適度に定式化して入力として与えるらしい．

今のところ，こちらの研究との関連は特にないようなので，置いておく．

_ [Java]表明オプション ▲

今日のはまり．実行時に "-ea" オプションを有効にしないと assert 文は検査されない．

_ [work][Java]Ant with Eclipse ▲

久しぶりに Ant の build.xml を書いてみた．JAR を生成する処理とソースコードおよび周辺ファイルのZIP アーカイブ作成処理だが，それぞれ [Run]-[External Tools] から Ant build を使うと，ボタン一つで両方の処理を実行できてかなりお手軽な感じになってきた．

user.dir が build.xml を配置しているディレクトリになるようで，eclipse.home は Eclipse インストール先を指すようだし，プロジェクト自体のディレクトリを指してくれるものが見つからなくてちょっと微妙な感じ．プロジェクトのトップディレクトリに配置しろということか．

_ [論文]イベントパターンを使ったアスペクト記述 ▲

Robert J. Walker, Kevin Viggers:Implementing Protocols via Declarative Event Patterns.Proceedings of the 12th FSE (FSE2004), pp.159-169,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

FTPプロトコルでのユーザ認証を題材にした論文で，pointcut でイベントを定義する以外に，tracecut というイベント列（pointcut を使って正規表現ぽく指定する）で処理の実行を記述できるようにしたもの．実行が済んだ部分にアクセスする history(tracecut) という述語を使って，過去のイベント情報（システムの状態？）をアスペクトの記述の基準にできる．

状態を保存する部分が自動化されていて便利だ，という主張ぽい．イベントベースのAOP，AspectJ などと比べて表現力，追跡性，拡張性，理解容易性が全部「高い」と言ってるあたりは少し「？」だが，個人的にはけっこうよさげな手法のように見える．うまくベースのイベントと切り分けられるものについては，AspectJ よりもうまくいきそう．

_ [論文]Pointcut のマッチの検査 ▲

Shriram Krishnamurthi, Kathi Fisler, Michael Greenberg:Verifying Aspect Advice Modularity.Proceedings of the 12th FSE (FSE2004), pp.137-146,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

基本的には pointcut をオートマトンと考えて（受理状態になると関連付けられたアドバイスが実行される），メソッド呼び出し列などのプログラムの状態に対してpointcut がいつ受理されるかどうかを判定しつつ，CTL によって記述した性質をテストするらしい．

使い道としては，pointcut の状態を見ることができるので，複数の類似した pointcut の性質の違いを調べたりするのに使えそうな気はするが…．

_ [論文]良い反例の出力 ▲

Sagar Chaki, Alex Groce, Ofer Strichman:Explaining Abstract Counterexamples.Proceedings of the 12th FSE (FSE2004), pp.73-82,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

モデル上でエラーとなるような反例を見つけて，実行が成功するような実行系列の例と「距離」が近いような実行系列の例として出力したいねという話．

一方の実行系列を他方へと変換するような基本操作の数が，実行系列間の距離となる．ここで，実行系列は，状態と，実行する命令の組の系列らしい．

発想はそのうち参考にすることになるかも?

_ [論文]動的解析による不変条件の推定 ▲

Jeff H. Perkins, Michael D. Ernst:Efficient Incremental Algorithms for Dynamic Detection of Likely Invariants.Proceedings of the 12th FSE (FSE2004), pp.23-32,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

実行時の各変数の状態から，不変条件を推定するという話．"Incremental" なのは，最初の実行で成立した条件を仮に全部不変条件だと思っておいて，反例が見つかった時点でそれを捨てていくというもの．

条件がプログラムのどの場所で成立しているかによって，広い範囲で成立する条件とその部分範囲でのみ成立する条件とをツリー階層で管理することで，反例が見つかった瞬間にツリー間で条件式を移動して，「条件が成立している範囲」の情報を調整する形になっている．

この論文の主旨としては Incremental なアルゴリズムに対して適用したいくつかの最適化方針に対してパフォーマンスを測ってみたというところ．

時間の単位が1000〜20000秒となっているので，実用かどうかというとちょっと怪しげな側面もあるが，重要な場所だけ絞って判定するとか工夫すればそれなりの結果は得られるのかな？と思わないこともない．ただ，サンプルが多くないと「そのテストケースでの不変条件」という微妙な出力を得ることになるので，使い道としては微妙か．

_ OACIS ▲

IT連携フォーラム OACIS 第７回シンポジウムに参加．鳥居先生が喋るのを見たのは実は初めて?

中ノ島センターに行ったのも初めてだったりするが，市バスの75系統だと，かなり近くまで行けて楽だった．ただ，バス自体の本数がない（12時代は12:31の１本だけ）ので少し使いにくい．次に行くときには忘れてそうだけど．

_ [論文]モデルとコードの対応付け ▲

Xiaofang Zhang, Michal Young, John H. E. F. Lasseter:Refining Code-Design Mapping with Flow Analysis.Proceedings of the 12th FSE (FSE2004), pp.231-240,Oct.31-Nov.6, 2004, Newport Beach, CA, USA.

モデルとコードとのマッピングを取るときに，モデル要素間の use 関係と実装コード間の use 関係，モデル要素とコードとの部分的なマッピングが与えられたら，残りの対応付けが済んでいないコードが与えられたモデル間の use 関係（制約）を満たすようにモデル要素へマッピングできるかどうかを調べるという話．

ソース改変などで不完全になってしまったモデルを再び完全状態に戻すといった使い道ができそう．逆に，マッピングが少ない状態からスタートすると，最初に与えるモデルがエラーを含んでいる場合などにはその影響が大きく波及してしまうらしい．

_ ボジョレー・ヌーボー ▲

去年飲んだフランク・サンカンのを探してみたけど見つからなかったので，今年はピエール・アンドレのにしてみた．

_ [Java]Generics の制限 ▲

Generics で型パラメータを static メソッドに与えようとしたら怒られた．また，instanceof でも比較対象に型パラメータを使えないらしい．

これらは，C++ template の場合と違って，型情報が実行時には落とされてクラス自体は１個しか存在しないためらしい．なので，型パラメータごとに Singleton なインスタンスを作ろうとしたりはできないらしい．

Singleton 問題を回避するのに，Factory パターンを使って型パラメータごとに Factory を１個生成して，それぞれの Factory が Singleton なインスタンスを管理するようにしてみた．

_ 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) のような動的な型の表記を可能にしたり，といったことをしている．

このアプローチの場合，メタクラスが一つの次元を整理してくれるので，摂氏・華氏のような単位混在も可能だし，ログスケール系への拡張も容易である，らしい．言語の拡張が含まれるのでいきなり導入して使えるというものではないが．

_ ワイン ▲

ロマネ・コンティ2001のオークションがあるらしいと店の発行する宣伝メールを見てオークションページを覗いてみたら，その宣伝メールの送信時刻から１時間経たずして落札確定価格(約36万円)の入札で終わってた．さすがというか何というか．http://www.rakuten.co.jp/yuhara/460416/595262/

_ SIGSE出張 ▲

ようやく大阪に到着．

アスペクトの単体テストの話をしてた人がTesting AOP のワークショップに出るのか？という話をしたら古宮先生がかなり乗り気になっていたので，去年の人に続いてB4で海外発表となるのだろうか．# 今回ので先生に顔を覚えられた，かな？

_ ちょうどテスト・仕様検証という話の関連で，アスペクトの仕様とは何か（何をテストするのか）という話が少しあって，議論の余地はたくさんあるみたいだということだけは分かった． ▲

野田さん，岸先生によるアスペクト指向設計の考えもだいぶ分かった気がするので，収穫としてはそこそこ．

_ [論文]コンポーネントの使い方抽出 ▲

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 しているかを管理しておくのは重要だということは何となく分かる．

_ [AspectJ]AspectJ Cookbook ▲

AspectJ Cookbook が O'Reilly から発売されるらしいので，wiki の書籍リストに追加．

_ [論文]実行履歴からのシナリオ抽出 ▲

Glenn Ammons, Rastislav Bodik, James R. Larus:Mining Specifications.Proceedings of POPL 2002.

実行履歴として引数の値の情報を含めた関数呼び出し列を持ってきておいて，抽出したい特定の関数だけをシナリオとして残して，そこからオートマトンを生成する．

オートマトン学習のコストを下げるためにシナリオの長さをある程度で切る必要があったり，関係のあるメソッド呼び出しだけを使うためにフロー解析を使ったりしているらしい．

オートマトン抽出した結果の使い道が verification となっていて，論文での評価実験でも各プログラムからのオートマトン生成結果で検証を行っている．実行履歴はプログラムの入力に依存するので，設計時の情報に比べると，生成されたオートマトンは情報の一部が落ちている可能性があるのだが…．用途としては verification よりは設計時のオートマトンとの比較によるトレーサビリティの確保などのほうが面白そう．

_ [AspectJ][work]Join Points 探索 ▲

AspectJ の Join Points だけをバイトコードから探索してきたいが，abc も AspectJ も，実装がきれいに分離されているというわけではないらしい．

Pointcut は明示的に実体として存在するが，Join Point のほうはそうではないらしい．実行時の Join Point 情報へアクセスするためのクラスがヒットしてしまって，かなり調査しづらい．