netail.net

_ bun45 ▲

文学部西洋史学研究室のＰＣ関連トラブル相談役（？）の後継者が sin＠OUCC さんに決定．

収入の都合とか大学にいる残り年数とかからそろそろ決めないとまずいなーと今年前半から思ってたのだけど，ようやく解決．

引継ぎ用の資料とかは作らないとまずそうだけど．

_ [論文]二項関係でのクエリー記述 ▲

Dirk Beyer, Andreas Noack, Claus Lewerentz:Simple and Efficient Relational Querying of Software Structures.Proceedings of 10th Working Conference on Reverse Engineering (WCRE2003), pp.216-225, Victoria, B.C., Canada, November 2003.

クラス間の関係・構造をCALL(A, B), INHERIT(A, B), CONTAIN(A, B) のような形でデータベースに入れておき，論理型言語でクエリーを記述する．

たとえば，x と z は同じメソッド呼び出しを持つことは:IdCall(x, z) := for all y, CALL(x, y) → CALL(z, y) ∧ CALL(z, y) → CALL(x, y)といったようになる．

基本的には言語の提案っぽく，大規模なシステムが相手でも記述の行数が増えないこと，サイクルの検出や，同じクラスを２回以上継承した場合の検出などを題材に，実行時間的に優れていること，などが説明されている．

_ [論文]FCAでのクラス分析 ▲

Uri Dekel, Yossi Gil:Revealing Class Structure with Concept Lattices.Proceedings of 10th Working Conference on Reverse Engineering (WCRE2003), pp.353-363, Victoria, B.C., Canada, November 2003.

どのフィールドがどのメソッドに使われているかをベースにConcept Lattice を構築して，Lattice の Top/Bottom 以外では disjoint であるようなフィールド群は別クラスに分割できる，とかいった分析を行おうという話．まあ，やればできそうという話だけど．

実際には使われてないメソッドやフィールドの除去や，フィールドの役割の分析なんかも必要みたい．また，配列への追加・削除時の growArraySize （配列の領域調整）のような副次的な存在は，クラス内での役割が分かりにくい様子．

_ [work]活動予定 ▲

活動予定を更新．

AOSD 2005 は，SPA-SUMMER で出したネタの続き(?)話をStudent Extravaganza に Late Registration で出してみて，色々な人に意見を聞いてみるつもりでいくことにする．

AOSD2005 はシカゴでも Magnificent Mile のほうにあるインターコンチネンタルホテルであるらしい．チュートリアルとワークショップのスケジュールが微妙なところ．スケジュール確定のために，さっさとどれに参加するか決めてearly registration (12日まで)して，それからポスター作成となりそう．

_ 出張準備 ▲

AOSD2005はAOPなリファクタリングに関する半日のチュートリアル＋本会議３日間の参加．20日の夕方に日本に戻ってくる予定．

Registration＆ホテル予約を完了して飛行機予約のお願いもしたもののポスターはまだ影も形もなし．

_ [論文]暗黙のメソッド呼び出し変換 ▲

だいぶ前に読んだはずの論文だけどメモし忘れていたらしい．

Robert J. Walker, Gail C. Murphy:Implicit Context: Easing Software Evolution and Reuse.Proceedings of FSE2000, pp.69-78, San Diego, CA, USA,November, 2000.

「あるクラスが AbstractFactory パターンを使っている」といったデザイン情報は，コード上では単に new を使わずにmakeInstance のようなメソッド呼び出しとして表現され，ユーザに makeInstance の使用を強制することはできない．

そこで，「new へのメソッド呼び出しが起きたら，かわりに makeInstance を呼んでね」といったContext を生成してオブジェクトにアタッチする．Context 自体の記述は，過去のメソッド呼び出し履歴に対するリフレクション機能を使ったプログラム形式で書けるようにしている．

これを使うと，一部のコンポーネントへの依存関係をオブジェクト本体から切り離しておけるので，Swing ライブラリでの Look and Feel の切り離しという実験をしている．

AspectJ などを使ってできることとほとんど同じだが，AspectJ などよりも実行コンテキストへのアクセスが主体となっていて，過去のメソッド呼び出し履歴に応じてメソッドのディスパッチを変えるといったことができる．AspectJ の around アドバイスに，その種のリフレクションを持たせたら同じになるといえなくもないか．

_ コンテキスト制約記述言語CCL ▲

Context-Based Constraint Language，というのがあるらしいというので調べてみた．

あるコンポーネントにコンテキスト値を付加して，そのコンポーネントが働いているときに属しているコンテキストをリストアップしておく．そして，「コンテキスト 'Controller' のときは 'Personal Data = Yes' の属性を持ったオブジェクトに アクセスしては駄目です」といったように制約を記述する．

使い方としては，設計時に UML などに付加しておいてあとでコードに落とす制約言語なので，OCL と似ている．

単なる表明だけでなくて ENCRYPTED WHEN CALLING とかいった呼び出しまわりの属性付加もあるので，主には CORBA やら EJB なんかでの使用になるみたい．

単に表明を記述する言語としてみると，AspectJ・JBoss AOP などでアトリビュートを付加してdeclare error や実行時のエラーチェックを付加する実装方法とうまく対応しそうな印象がある．

SPLAT2004に出したアサーションをアスペクトで書くと，という話とも絡むけれど，CCLでいうコンテキストはかなり大域的な情報で，「利用コンポーネントに応じて違う表明を書く」というのはコンポーネントとその利用者の間だけのローカルな情報なのかなと思ったりする．技術的には極端な差はないように見えるけれど．

_ [論文]ソフトウェア内部のパターン認識 ▲

Martin Pinzger and Harald Gall:Pattern-Supported Architecture Recovery.Technical Report, TUV-1841-2002-16, Technical University of Vienna.

ソフトウェア・アーキテクチャをソースやドキュメントから復元するために，どんな設計上の決定がシステム内に含まれているかを認識しましょう，という話みたい．

ただ，やってることはちょっと賢い（複数行に渡った情報が扱える）grep のように見えなくもない．マッチした結果を「パターンインスタンス」と呼んで，それらの関係図を出力しましょう，といった感じに見える．

_ [論文]データ項目の自動対応付け ▲

Sebastian Bossung, Hermann Stoeckle, John Grundy, Robert Amor, John Hosking:Automated Data Mapping Specification via Schema Heuristics and User Interaction.Proceedings of ASE 2004, pp.208-217.

XMLスキーマがたくさんあって，データを相互変換したいが，毎回手動で変換ルールを作るのは大変だから，XMLスキーマが２個与えられたとき，なるべく自動でデータのマッピングを生成しましょう，という論文．スキーマだけでなく，インスタンス文書のほうも（もしあれば）入力として受け付けるようにしているみたい．

スキーマ間のデータ項目のマッチが基本になるが，マッチの実装方式としては，色々なヒューリスティックを実装したエージェントを環境に放り込む，という形にしている．

使うヒューリスティックとしては

・項目の名前が同一である

・一方の項目の名前が，他方の項目名の部分列になっている

・文字列同士の Levenshtein 距離（一方を他方に変換する操作列の長さ）が小さい

・要素型が等しい

・要素のセット（あるタグの配下全員）で型が等しい

・一方が他方の略称アルファベット列になっている

・インスタンス文書の，要素の値が同じ…など．

ツールをプロトタイプを作ってみたら，スキーマがそれなりに似ていると事前に分かっているものでは，いい感じに使えた，らしい．

ただ，この時点では，データのマッピングは値のコピーにしか対応してないようなので，複数項目の集計とかに反応しようとすると大変そう．（変換を容易に記述できるスクリプトと組み合わせになる？）

あったら便利そう，という印象はあるけれど，こういう類のツールはどう評価するのがいいのか分からない（せいぜい「正しい対応付け」に対する正解率？）という微妙なところ．どのヒューリスティックがよく効くのかは見てみたい気もするが．

_ [論文]デバッグ操作のプログラム化 ▲

Guillaume Marceau, Gregory H. Cooper, Shriram Krishnamurthi, Steven P. Reiss:A Dataflow Language for Scriptable Debugging.Proceedings of ASE 2004, pp.218-227.

デバッグ用の操作をプログラム（スクリプト）から扱えるようにした，という話．デバッグ時に行う操作はわりと定型的だ，というのが前提．

Lispぽい文法の言語を作っていて，Trace命令で（AspectJの args や this などのように）プログラムの状態のいくつかを変数にバインドして，プログラム実行中に制約違反を起こしたらプログラムを止める，といったスクリプトを作っている．

東工大の千葉先生のところでやってたデバッガにAOPな機能を取り込んでみる，という話が近いのかも．

_ [論文]抽象プログラムによる制約違反の発見 ▲

Mana Taghdiri: Inferring Specifications to Detect Errors in Code.Proceedings of 19th International Conference on Automated Software Engineering (ASE'04), pp.144-153,Linz, Austria, September, 2004.

クラスの各メソッドから簡単な仕様を抽出し（たとえば戻り値が null でないとかフィールドが更新されるとか），プログラム中のメソッド呼び出しをその制約式で単純化し（a = list.contains(element) なら [a = "?"] のように）抽象化されたプログラムが制約を本当に満たすか検査する．満たさない場合，制約違反を起こすような抽象実行列を出力する．

あんまりよく分かっていないが，データ構造コンポーネントの一貫性検査などに使ったりするみたい．

_ [論文]ソフトウェア変更時の横断的関心事 ▲

Elisa L.A. Baniassad, Gail C. Murphy, Christa Schwanninger and Michael Kircher:Managing Crosscutting Concerns During Software Evolution Tasks:An Inquisitive Study.Proceedings of AOSD 2002.

ソフトウェアの変更時に，開発者がどう横断的関心事を意識して対処するかを調べようというケーススタディ．

開発者に後からインタビューしたところ，明示的にドキュメントやモジュールがないと，「何をしているのか」という理解が人によって変わってきて，また対処方法も３つくらいのパターンに分かれたらしい．

また，「このコードを変更するとどこに変更が及ぶのか？」というのが開発者の不安の種となっていることが確認されている．

開発者の作業の監視ではなく終わった後のインタビューなのと，参加者８人でタスクも小さいということからValidity として強いわけではないけれど．

_ DoS ▲

OUCC部室にてFC版DQ3のカートリッジを分解したりして遊んでたら，web にアクセスできなくない（サーバの応答がない）ことが判明．

どうも Inktomi というところから Crawler が大量に（１秒に数回）存在しない URL にアクセスしてた様子．ありそうな CGI を総実行していくらしい．

Yahoo/Crawler/DoS あたりで検索してたらrobots.txt を無視するらしいとか，色々ろくでもない情報だけ見つかった．

ちょうど同じ時刻に cgi 動かしたり大量にデータ転送してたらしき人に嫌疑がかかったりもしたが，どうも Crawler が原因っぽい．１日１回くらい，集中的にアクセスに来るっぽいのであまり性質の良いものではなさそう．

_ [work]卒論タイトル ▲

卒論タイトルを３人がかりで１時間かけて煮詰めた．＃１時間もかかった，とも言う．

「〜に基づく」「〜による」「〜を利用した」などの表現が係り受け関係を怪しくしてしまっていたので，表現を単純化して，あとは微妙な表現の変更だけ．だいぶ疲れた．

_ メールチェッカ ▲

特定の人からの重要メールだけを通せるようなメールチェッカがほしかったので，色々調べてみた結果，通知方法に凝ってるものはあってもフィルタに凝ってるものは意外と少ないことが判明．

結局，いくつかピックアップしてみたうち，NEMCHI というチェッカが要望を満たしている（http://a-tak.com/wiki/index.php?NEMCHI 「おすすめの使い方」によればそのために作られていた）ようだったので，導入してみた．ユーザインタフェースもシンプルで，好感触．

_ 全国大会 ▲

情報処理学会の全国大会のプログラムを見ていて，「ソフトウェアの保守と検証」セッションにある高橋裕康，紫合治: アスペクト指向プログラミングによるシーケンス図の自動生成が少し気になる．

シーケンス図生成ツールを AOP 的に作成したのかなと思わなくもないけど，AOPでのロギングの実装だけが工夫だったらどうしよう…．

_ [Delphi]RichEdit ▲

RichEdit コントロールはバージョン 1.0, 3.0 と 2.0 で，同じ API でも引数および戻り値の意味が違うというドキュメントを見つけたはいいけれど，Delphi でどのバージョンを使っているか文書がなかったのでVCL のソースを調べてみた．

結果，LoadLibrary してるところに 'RICHED32.DLL' という定数が埋め込んであるのを発見．

これは 1.0 のライブラリで (2.0〜3.0は RICHED20.DLLらしい），Windows XP SP1 以降も 1.0 Emulator 搭載らしいのであんまり気にせずに 1.0 だと思って使っても良さそう．

_ [Java]Enum にメソッドを関連付ける ▲

Sun が提供する Java Core Technology Tips を読んでたら，enum の話が載ってた．

public enum Coin3 {
  PENNY { int value(){ return 1;} },
  NICKEL { int value(){ return 5;} },
  DIME { int value() { return 10;} },
  QUARTER { int value() {return 25;} };
  abstract int value();
}

上記のように，enum 定数をオブジェクトとみなしつつメソッドを持たせたり，コンストラクタを持たせたりといったことをしていいらしい．こういう使い方は考えてもなかったので，けっこう驚いた．

http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

_ PPL2005 ▲

Category 2 の採録通知が届いた．ということで発表準備＆参加申し込みが必要．

_ ファミコン ▲

ナムコ，ローリングサンダー（裏面）をクリア．表面は２面に１つしかパスワードが出なくて，裏面は敵は強いが１面に１つパスワードが出る．裏面のほうがボス戦以外は簡単な気が．

_ 工事 ▲

ケーブルテレビ用の宅内の端子を交換する工事が来た．来る予定の時刻にたまたま宗教の勧誘も来たので，思わずドアを開けてしまった．

_ [OUCC]MAngband ▲

久々にサーバを稼動させてみる．（例によって非公開）

_ Norton ▲

LiveUpdate がなぜか失敗したので，エラーメッセージの解説記事にあったとおりの手順でLiveUpdate の新バージョンをダウンロード→インストール→再起動→LiveUpdate で動いた．

_ くろがね 堅パン ▲

おみやげにもらった「くろがね 堅パン（ほうれん草味）」を食べてみた．本当に堅くて，カントッチョの和風版みたいな印象．ほうれん草らしき味はあまりしなくて，緑色＋ほんのり甘さで，言われないと抹茶かと思ってしまいそうな．

_ 確定申告 ▲

３月は出張でごたごたした昨年度の反省を踏まえて，今回はさっさと作成することに．

国税庁のWebページの確定申告書等作成コーナーで，去年の住所等データを引き継げるようになっていてけっこうあっさり完成．

あとは印刷して送付するだけ．

_ 査読の仕方 ▲

_ [論文]表明のOOPでの利用 ▲

M. Satpathy, N.T. Siebel, D. Rodriguez:Assertions in Object Oriented Software Maintenance: Analysis and a Case Study.Proceedings of the 20th International Conference on Software Maintenance (ICSM 2004), pp.124-133, Chicago, September 2004.

オブジェクト指向プログラムで，アサーションがどのように使われているかを調査し，またアサーションがソフトウェアの変更のときにどのように変わるか（リファクタリング時にコピーされるなど）を調べた論文．

基本的には，クラス内の特性として，

・クラス不変表明

・メソッドの事前条件としての入力値の範囲，複数の入力の一貫性，オブジェクトの状態の検査

・事後条件としての，戻り値の範囲，戻り値と引数の関係，オブジェクトの状態（副作用の禁止など含む）の検査

クラス間の関係として，

・派生クラスに対する Liskov の置換原則

・オブジェクト間の相互参照関係のチェック

そのほか，

・バグ調査での利用

・システム間のインタフェースでの入出力値が正しいか

・設計と実装の対応が取れているかなど．

これらを踏まえた上で，リファクタリング作業時に（できれば自動で）適切な assert 文のコピーや移動をしたいらしい．

_ 出張準備 ▲

追いコン前に梅田で買い物ついでにPPL2005参加用の新幹線チケットを購入．

行きは東京11:40→13:04上毛高原，帰りは上毛高原14:28→15:48東京16:03→18:40新大阪．

新大阪→東京行きの切符だけ，係の人の間違いでちょっと早い時間のになっていることが判明したので（窓口で気づかなかったのでこっちにも責任がある），今度また買い物に行くときにでも時間変更することにする．

_ 追いコン ▲

RPG研の追いコン．４年たった人と就職して大阪を離れる人が追い出し対象．

就職しても勤め先が豊中の人とか，OBで離れてたけど転勤で高槻に戻ってきている人とかもいて，遠いところに行く／行った人は実は意外と少ない気も．

_ C# ▲

C# 2.0 の Partial Class が aspectj-users ML で話題になってた．クラス定義の一部だけを別ファイルに書いておいてコンパイル時に足しこめるというもの．http://www-ise2.ise.eng.osaka-u.ac.jp/~iwanaga/programming/csharp/ap_ver2.htmlにC#新機能がまとめられていた．

Partial Type を自動生成すればAspectJ の Inter-Type Declaration に近いことができそうだがcrosscutting の記述ができないから違うんでは，というのは aspectj-users で出ていた意見だが，うまくクラス定義をモジュールに分割して，簡単なプリプロセッサでも書けばAspectJ や Hyper/J でやっていることに近いことができそう，という意味で面白そうではある．

本来の用途は「賢い #ifdef」なのかなと個人的に思っていたら，http://www.ondotnet.com/pub/a/dotnet/2004/04/05/csharpwhidbeypt1.htmlには，これは大きいクラスを分割しておくための仕組みで，デザイナなどで自動生成したコードと，人間が書いたコードとを自動で区分して管理しておくことが本当の目的だ，と書いてあった．

AspectJ で Inter-Type Declaration を使えば同じことはできるけれど，crosscutting もしてないのにコードを分割してていいのか，と怒られそうな気がする．

_ TOEIC ▲

１年ぶりのTOEICの結果，やはり１ヶ月経って忘れた頃に帰ってきた．

リスニング380＋リーディング420で，合計800（PERCENTILEで91.5）．１年前よりリスニングが+50されているのは，留学生な人の影響とか海外出張の効果？

_ MAngband ▲

アイテム「家の鍵」を家の中に置き忘れて扉を閉じて家に入れなくなってしまった人を救出する方法がないのかと思って調べたら，結局「管理者」ユーザなら家の鍵を所有している判定がされないことが判明．

管理者かどうかはキャラクター名だけの strcmp で判定しているので，実は管理者キャラクターはサーバ立ち上げ時に作成して適切なパスワードを設定しておかないと誰でも管理者キャラクターを作れてしまうらしい．このあたり実装が適当．

_ AspectWerkz ▲

PPL 2005 発表の材料作りに AspectWerkz 2.0RC3 を使ってみた．

アスペクト結合を指示する XML ファイルに構文エラーがあると（XML バージョン宣言はタグの前後が "?" で 閉じられているが，終端の "?" を忘れていたら）あっさり NullPointerException （しかも Chain している）を吐かれてしまった．

ユーザビリティの観点で問題じゃないんだろうか…．みんな正しいXMLを書くエディタとか使ってるから引っかかる場所ではないのかな？

_ [work]発表準備 ▲

卒論が無事終わったので，再びPPLの資料作り．現在，発表20分に対してスライド22枚．まだ一回も通しで読んでないので喋ってみないと分からないが．

もう発表まで２週間切ってるので少し急ぎたいところ．

_ 梅 ▲

万博記念公園まで梅の花を見に行ってきた．カメラと三脚を持った年配の方々の集団（１０人くらい？）が頑張ってたくらいで，あとは人はまばら．

出かけたついででだいぶ寄り道して，千里中央のミスタードーナッツとダイエーの間にあるコーヒー屋さんに初めて入ってみて，コーヒーとケーキがけっこう美味しいことを確認．ついでに出張用切符の新幹線の時間変更なんかも済ませてきた．

_ [論文]クラスの階層構造の識別 ▲

Stephane Ducasse and Michele Lanza:The Class Blueprint: Visually Supporting the Understanding of Classes.IEEE Transactions on Software Engineering,Vol.31, No.1, January 2005.

Class Blueprint は，１つのクラスのメンバーを初期化用，インタフェース，内部実装用，アクセサ，属性という５種類のレイヤーに分類して，相互に呼び出し関係を接続したもの．

分類にはヒューリスティックとして，名前に "init" を含んでいたり，そんなメソッドを呼び出しているようなメソッドは初期化用である，private インタフェースだったりクラス内のほかのメソッドから呼ばれているようなメソッドは内部実装用である，というような，わりと経験的に妥当っぽい基準で分類している．

メンバーの種類もスーパークラスの同じメソッドを呼んでいたら Extend でまったく書き換えていたら Override で特定の呼び出しパターンをしていたら Delegate で，といったように経験的に分類し，色づけして配置すると，Blueprint が１枚出来上がるらしい．

Blueprint が複数枚出てくると，特定のレイヤーが大きいとか，小さな機能を実装したクラスだとか，定数を定義するクラスだとかいったように，可視化した内容からクラスの傾向をつかむことができる．また，継承木単位で Blueprints を接続して理解するということも可能になる．

静的解析だけでがんばっていて，さすがにクラス間の接続などは行っていない．単一クラスの傾向をつかむという意味ではけっこう面白い．（あんまりクラス間で Blueprints を接続すると 役に立たない複雑な図が生成されそう）５つのレイヤーへの分類結果をメトリクスとみなしてクラスタリングみたいなことをすると何か出てきたりするかも？