netail.net

_ [近況] ワークショップのプログラム ▲

AOASIA2 プログラムが出てるようです．基調講演＋発表12件＋Panelという構成なようです．おかげさまで，10分プレゼン時間もらってます．

今回，プレゼンは人にお任せモードなので，その期間のうちに休憩時間に人に見せられるくらいのデモが準備できないかなぁと考えてます．しかし，そろそろ院試後の卒論に向けての方針とか，M1の人のネタのことも少しは考えておかないといけないので，時間がどれだけ開発に割けるか微妙なところ．

_ [近況] 今日も講演を聞いてきた ▲

Thomas Zimmermann という人が，今度のASEで発表する内容とかを話してくれた．この人は，去年のFSEではCVS履歴から「Aを追加してる人は同時にBも追加している」という情報を集めてきて，パターン分析しようというのを発表してた．

今度の手法は，アスペクトマイニング．「どこでどのメソッドを呼び出しているか」の関係を呼び出し側を縦軸，呼び出し先を横軸にとってチェックをつけていく．concept anlaysis を使って縦長の長方形になる部分（２〜３個程度のメソッド集合が，たくさんの場所で呼び出されているケース）を発見すればそれはアスペクトの候補だろう，としている．fan-in analysis の拡張といえる（？）

この人のアプローチで面白いと思ったのは，ロギングのような横断的関心事は「同時に複数個所に配置される」，IteratorのhasNextとnextのようなメソッドペアは「一度に一箇所ずつ増えていく」という仮定．これらの違いをCVS履歴から区別しようとしている．「一度にたくさんの箇所に呼び出しが追加されているもののほうがアスペクトっぽい」というメトリクスを定義しているようで，それをランキングに使った結果，lock/unlock ペアとか，意味のありそうなものが上位に出てきているらしい．

この人は，「データ抽出タイミングと，出てきたパターンのランキング手法とのどちらで頑張るかという選択肢があるが，ランキング側に力を入れている」らしい．だから，メソッド呼び出し対象のエイリアス解析とか，その辺はコストかけず適当に，という感じらしい．

メトリクスのちゃんとした定義とか，CVSから取ってきたデータと最新ソースのデータの取り扱いとか，ちゃんと論文が出てから確認したいところ．

_ [近況] ワークショップの notification 待ち． ▲

まだ届いてないので，月曜には聞いてみる予定．

今回はスケジュールにも余裕がずいぶんあるので，あんまり緊急でもない．

_ [hyCalendar][お知らせ] hyCalendar 1.4.0 リリース ▲

ヘルプまわりの修正が終わったのでリリースしました．先日出したバイナリだけ版からは，特に変わってません．ヘルプのほうは，ちょっとファイルを小分けにしたりとか，目次を増やしたりとかしています．それから，HTML構文的にまずかった部分をかなり修正しました．

ワークショップに出してる論文の査読結果がもうすぐ届いたりとかするので，またしばらく本業専念モードになる予定です．更新間隔が広くなると思います．

_ [読書] Heuristics 本ようやく読了 ▲

Arthur J. Riel: Object-Oriented Design Heuristics. Addison Wesley, April 1996.

９章までがヒューリスティクスの紹介だったのに対して，10章はデザインパターンとヒューリスティクスの違いについて検討されている．この本の発表の時期的には，パターンランゲージは既に知られているけど GoF のデザインパターンカタログなんかはまだ，というぐらい？

ヒューリスティクスとデザインパターンの関連性は明らかにあり，筆者の「ヒューリスティクス」というのは「悪い設計パターン」から「良い設計パターン」へ至る変換のパターンであるといえる．

デザインパターンは，それをいつ適用すべきかというのが分かりづらいことがある．それに対して，ヒューリスティクスは「悪い設計パターン」というのがどういうものかを短く表現していて，しかもCASEツールによって自動的に検出できるものが多い．

ただし，変換パターンとして適用できる変換というのは複数あって，たとえば柔軟性とかクラス数の最小化とか，どの属性に着目するかで適用する変換が変わってくる．ものによっては，性能面など，実装都合上のトレードオフなんかも影響する，と述べている．

10章ではいくつか今までのヒューリスティクスを変換パターンとして書き直して紹介していて，１つのパターンの出力が他のパターンの入力になりうる推移性と，specialize/generalize のような反射性（２つ適用すると元に戻る）を持つパターンが挙げられている．

今後の研究の方向性として，次のようなことが挙げられていた: (1) 変換パターンをどう分類するのが良いのか．推移性などでその関連性を整理できるか． (2) 機能拡張などでの設計変更は，変換パターンによってとらえることが可能か？もしそうなら，それらのパターンの入力とは何なのか？ (3) 変換パターンを多数持っていたとして，それによって設計の最適化を自動化することは可能か？つまり，悪いデザインから良いデザインへユーザを導くようなツールは作れるか？そんなツールを作るには，設計の良さを，柔軟性，移植性，効率性，ソフトウェアやハードウェアの制約，クラス数の最小化といった側面から判断できる必要がある．

最後の11章は銀行のATMと銀行のトランザクションを取り扱った設計の例．途中でどんな選択肢があり，どのヒューリスティクスに基づいて設計を選んでいくかというのが解説されている．あとは付録で，ヒューリスティクスのリストと，なぜか「C++で起きるメモリリーク」の例とかが付いていた．

読むのにけっこう時間はかかったものの，読んだ価値はあったといえそう．10章の内容は，悪い設計パターン＝「コードの不吉なにおい」と読み替えると，「リファクタリング」の話に近いことだと言ってよいかもしれない（リファクタリングはコード可読性レベルの話もあるので一緒くたにするとまずい？）．今後の研究の方向性については，けっこうどこかの学会で聞いたかな？というような話もあったりするし，かなり示唆に富んでいるように思う．

余談: ヒューリスティクスによる改善の効果は，リファクタリングの効果が評価しにくいというのと同じように，評価しにくい．この本で出ているヒューリスティクスは，局所的な依存関係の変換だけを提示しているので，クラス数の増減や実行効率の変化を除いては，システムのほかの部分に波及することがない（カプセル化がうまくされているなら）．だからこそ step-by-step な改善に適用できるんだけど，「その改善ってどのくらい効果があるの？」と聞かれると弱かったりする．

_ [hyCalendar] 1.4.0 バイナリだけ ▲

ヘルプファイルを書き直そうと思ってるわりにぐだぐだしてるので，1.4.0バイナリだけを置いてみます．

期間予定を土日祝日だけ非表示にしたい人，「５日おき」のように定間隔の予定を書きたい人，「〜〜まであとX日」とか書きたい人向けの機能拡張が入ってます．変更点のリスト参照のこと．

当然ながら，新たな情報がファイルに保存されるので，データのバックアップをしてから使ってみてください．

「１月１日から１日おき」という表現だと１月１日，３日，５日...とか容易に想像できるんですが，１月１日，１１日，２１日...の予定を「９日おき」と表現するのはいまいち分かりにくい気がしました．そのため，「１０日に１回」という表現を使ってみていますが，どうでしょうか？もっといい表現があるよ，という方がいらっしゃいましたら，お教えいただけると幸いです．

_ [読書] Heuristics 本の，さらに続き． ▲

Object-Oriented Design Heuristics ６章〜９章．このあたり，あんまり新規な内容はなかったので短くメモ．

６章は「多重継承は正しく使おうね」という話だけ．

７章は「association」の解説．use でも containment でも inehritance でもない関係のこと．たとえば，車とメーカーがあるとき，車とメーカーオブジェクトが互いにメソッドを呼び合うわけでもないし，互いに所有関係にあるわけでもないが，どのメーカーがどの車を生産したか，という関連を持っている．で，車が持つメーカー名のような属性はメーカーオブジェクトを発見するための参照用の属性（referential attribute）だとしている．referential attribute を使うと，クラスの外部で間接的な利用関係を定義できる．たとえば「特定のメーカーの車を回収する」recall クラスなんかは，メーカークラスの機能数の増加を抑えるために有効だと言及されている．ただし，containment に比べると，「こう使ってほしい」という情報を外部に公開する分，クラスを使う側が理解する必要のある情報が増えてしまうので，containment を選べるならそうしたほうが良いと述べている．

８章は，オブジェクトに固有のIDを割り付けるといった，オブジェクト単体では対処できない振る舞いをメタクラスでモデル化しましょう，という話．メタクラスといっても，実装としては C++ や Java での static 宣言とか C++ でのテンプレートとかになるけど．

９章は physical design として，論理的な設計をプラットフォームに落とし込むときにどうするか，という話．プラットフォーム依存な設計をするのは良くないが，設計案が複数あるときに，実装上コストがかからないとか，プラットフォームの情報を使った意思決定は別に良い，と言っていたりする．あとは，ラッパークラスを使って外部システムをオブジェクトに見せることで従来のシステムやデータを再利用できるので良い，という話とか．この辺の内容は，普通の設計関連の本ではあまり見たことがない気がする．

_ [読書] Heuristics 本の続き ▲

昨日の続きで Arthur J. Riel: Object-Oriented Design Heuristics を読む．１章読むのに２時間ぐらいのペース？

４章はオブジェクトの使用（Use）と所有（Containment）についての説明．所有しているオブジェクトはちゃんと自分で使う（その参照を外部に提供しない）とか，良く知られた指針が多い．

５章ではクラスの継承なんかについては丁寧に触れられていた．紹介されてる改善例の中に，今では Strategy パターンや Composite パターンと呼ばれているものを発見．デザインパターンというのが良く考えられて作られているものだというのがちょっと分かった．

オブジェクトの参照については，あんまりたくさんあると複雑になるから６個ぐらいまで，少ないほうが良いと言ってるのに対して，クラスの継承については，「継承しても継承元は複雑にならないから」別に気にしなくていいと述べていたりする．

クラスの継承階層について，「正しく継承を使っているのであれば，継承の階層は深ければ深いほど良い」という意見を見たのはたぶん初めて．ただ，10を超えたあたりからクラス継承階層が把握しきれなくなるので，GUIツールなんかを使ったサポートで把握できる範囲（何もなければ６段程度）で使うのが妥当，といったふうに書いていた．継承階層の幅（１つの基底に対する派生クラスの数）については，「多い＝基底クラスがうまく再利用されている」なので，こちらは普通に多くて良いらしい（ただ，クラスでないものまでクラスにしてしまうことがあるので気をつけるべし，というのは書いてあったが）．

深ければ深いほど良いというのは，多段階の継承によって，差分で細かくクラスが定義されているほうが，再利用しやすいと考えていたりするのかもしれない……．

知らなかったのでいちおうメモ: C++ で，superclass/subclass ではなく「基底クラス base class」「派生クラス derived class」という呼び方をするのは，スーパークラスが持つデータメンバーはサブクラスのデータメンバーの subset になっている，といった紛らわしさを避けるためらしい．