«前の日記(2006-07-20) 最新 次の日記(2006-07-25)» 編集

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2006-07-21 [長年日記]

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

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

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

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

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

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

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

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

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

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

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

お名前:
E-mail:
右の画像に書かれている文字列を入力してください:
コメント: