netail.net

_ CD ▲

飯塚雅弓の「虹の咲く場所」購入．ポスターをもらったがいらないので部室に貼ることにする．

_ 論文 ▲

Scharli, N., Ducasse, S., Nierstrasz, O. and Black, A.P.:"Traits: Composable Units of Behaviour"ECOOP2003

今回一番気になった論文．trait = 特徴 を再利用単位にしよう，という話．trait は，メソッドの実装を提供し，必要なものを要求する．Trait は状態変数には直接アクセスはしない．Traits はクラスと合成される．Conflict が起こったときは明示的に解決する必要がある．

多重継承や mix-in の問題点を挙げている．たとえば，出力ストリームクラス A と B に対して，それらを継承してSyncA, SyncB という同期クラスを作るとき，共通部分だけを取り出して AやBと独立にSyncWrite クラスを作ることはできない（Template使えば別だが）．

Traits の例として，たとえば・TDrawing はBounds と Canvas を要求して，draw メソッドの実装を提供する．・TCircle は bounds を TDrawing に提供し，size を要求する．・Circle クラスは，TDrawing に Canvas， TCircle に size を提供する．……といった接続関係を定義できるらしい．

この方法は，オブジェクトが Traits を取り込むと宣言するので，アスペクトとは逆にObject -> Traits 方向の依存関係が発生する．必要最小限の Traits -> Object 依存関係を持つので下手すると依存関係が複雑化しそうだが．

多重継承などよりは整理された方式なので個人的には好み．スクリプト言語なんかで実装されてて，簡単な Traits がたくさん準備されてたら，思わず使ってしまいそうだ．ただ，Traits はアスペクトと違って「勝手に動けない」ところが少し弱いので悲しい．動けるようなものなら間違いなく使う．昔，そういうネタを考えてたけれど，誰か作ってくれないかなぁ．自分で実装するのは面倒だ．

_ 論文 ▲

Lam, P. and Rinard, M.:"A Type System and Analysis for the Automatic Extractionand Enforcement of Design Information"ECOOP2003

型システムを少しいじって，「これはｘｘという名前のサブシステムね」と型宣言をできるようにして，システムの動作を解析している．

モデルとしては，Call/Return Interaction Model (制御関係)Heap Ineteraction Model (共有データへのアクセス) なんかが導出可能らしい．

Call/Return Interaction Diagram は，すべての interaction の可能性を示しているもの．UML のシーケンス図は特定のユースケースに縛られているのでそれとはちょっと違うものだよ，と主張している．

実装方法としては，言語を拡張すればいける，というのが偉いのかどうか．ソースコードをぱっと見た限りでは，こんなのを手作業で書くのは大変そう．

たとえば，サブシステムに属するクラス宣言は class Hoge enter H1 { ... } とか書くことになる．この H1 とかいう名前が後で出力される図のベースになる．小さなサンプルで 3つくらい型パラメータがある時点であまり使いたくない．

いちおう静的情報でがんばって獲得しているように見える．が，言語をこれだけ拡張されてしまうと，実用性という観点では，適用するのが難しそう．どっちかというと，「誰がどのサブシステムです」と言語の外側にメタデータとして付けてほしいところ．メタデータで実装が可能なら，けっこう便利かも．

_ 論文 ▲

Popovici, A., Alonso, G. and Gross, T.:"Spontaneous Container Services"ECOOP2003

Spontaneous は "自然な，自発的な" という意味．EJB のようなコンテナ技術は固定されたネットワークを前提に作られているが，モバイルネットワークでもコンテナの透過性やトランザクション機能は便利なので使えるようにしましょう，という話．実装に dynamic AOP とか Jini を使っている様子．

コンテナが勝手に実装を置き換えたりできる世界になってる……らしい．dynamic AOP を使って，static にできない何ができるか，っていういい代表例になるかもしれない．そのうち．

_ 論文 ▲

Henkel, J. and Diwan, A.:"Discovering Algebraic Specifications from Java Classes"ECOOP 2003

Java クラスのコードから，実行時情報を使って，代数的仕様を発見しようというもの．

たとえば，Class が Immutable かどうかを，すべてのメソッド呼び出しの前後でシリアライズした表現とハッシュ値が同じかどうかでチェックするらしい．

見つけてきた情報から Term -> Equation -> Axiom と発展させるらしい．

実験対象はデータ構造系ばっかり．代数的仕様の弱点は，オブジェクトの内部状態ばかりに注目して，外部に及ぼす影響を評価していないことだと思うのだが……．

_ 論文 ▲

ECOOP2003が開催されているのに合わせて論文読み．# 別に意味はないが．

Aldrich, J., Sazawal, V., Chambers, C. and Notkin, D.:"Language Support for Connector Abstractions"

システム間，分散したコンポーネント間を接続するコネクターの話．ArchJava をベースに，connect という言語要素を導入している．コンポーネントの port 定義を，connect(ui.search, peer.search); とかいう感じで接続できるらしい．

connect (PoemPeer.client, PemPeer.server) with new TCPConnector (..)というように， "with" を使って接続メディアを指定できるあたりが便利そう．Connector オブジェクトが，オブジェクトの登録やら接続，通信の面倒な処理を全部やってくれるらしい．Connector は Decorator などに近いので，CachingConnector とか，Connectorに特殊な機能を持たせることでシステムを拡張することもできる．

理解容易性と拡張性がアップするらしい．コネクタベースの記述というのは面白いかも．競争相手は，もちろん，通常のOOPやAOP，各種分散システムのインフラ系など．

_ Windows ▲

Windows のパスワードが破られたという話を教えられた．

http://headlines.yahoo.co.jp/hl?a=20030724-00000024-zdn-sci

論文をちらっと読んでみると， key' = res(hash(key))というように逆ハッシュっぽい関数で，key を key' にマップすると， f = res(hash) とするとどこかで f^n(key) = key となって，keyが破れるという話っぽい．1.4G とかのルックアップテーブルを作れば OK だそうな．で，このテーブルの構造を工夫したところがポイントだったらしい．

まあ，目標の（対象マシンのパスワードがエンコードされた）ハッシュ値が取れないとクラックしようがないので，そういうハッシュ値が簡単に取ってこれるようなスクリプトや ActiveX がなければそれほど問題ではないかな．

パスワードの関数がへぼいからといって，ハッシュ関数を置き換えてしまうと，元パスワードでログインできなかったりしそうだし．どうやってアップデートするんだろ？Longhorn まで待つのかなぁ．

_ [論文] プログラムの読みやすさ ▲

ISSTA 2008 で Ditinguished Paper を取った，A Metric for Software Readability という論文が，かなり面白いです．発表を聞いて，論文をざっと眺めただけですが．

120人の学生に，様々な Java のコード断片を提示し，読みやすさで1〜5の点数をつけてもらって，コードの１行の長さの平均とか，１行あたりの識別子の数の平均とか，ピリオドの数とか，色々な指標のどれが効いているかを調べています．可読性の判断は，人によって分かれるかというとそうでもなく，「読みにくいコードは，誰にとっても読みにくい」ようです．

多数の指標に対して descriptive power を計算していて，１行あたりの識別子の数の平均，行の長さあたりが一番効いてくるらしい，としています．このあたり，今までの経験則の裏づけに近いところでもあります．実際は，複数の指標が1つの性質を反映してるようなので，ここから可読性の自動計測ツールに進むには，実際にどの指標を使えばいいのか，調査が必要なようです．

指標の種類が十分でない可能性とか，評価者の好みに偏りがある可能性とかはありますし，また，コードの可読性が開発者に依存するのか，それとも問題が複雑ならコードも複雑になるのか，といった疑問も多く残りますが，この手の話が好きな人は，とりあえず読んでおいて損がない論文だと思います．