Document Actions
|
||||
|
Inside-Out Principleは、「中から外へ向って設計せよ」という
Bertrand Meyer(*1)のソフトウェア設計原則で、「Model Before GUI」とも言
います。 ユーザとの界面を持つソフトウェアでは、まず「モデル」を設計し、後で界面 を設計するという指針になります。モデルとは、このソフトウェアが扱う問題 領域の「基本概念群」です。 例えばレンタルビデオ屋のシステムであれば「ビデオ」、「貸し出し」、「顧 客」などなどの基本的な概念群がキャプチャできるでしょう。これらの概念群 を分析し、概念間の関連や汎化構造を探索することで、「概念モデル」と呼ば れる分析成果物が得られます。 まずこのモデルを設計し、そこからユーザインターフェイスを設計します。最 初から画面デザインや画面の遷移を細かく設計してはいけないのです。 ┏━━━━━━━━━━━┓ ┃ユーザインターフェイス┃ ┃ ┏━━━━━━━┓ ┃ ┃ ┃ ┏━━━┓ ┃ ┃ ┃ ┃ ┃モデル┃⇒。。。⇒ 中から外へ向かって設計 ┃ ┃ ┗━━━┛ ┃ ┃ ┃ ┗━━━━━━━┛ ┃ ┃ ┃ ┗━━━━━━━━━━━┛なぜこうするのでしょうか？理由は、ユーザインターフェイスは変化しやすく、 モデルは変化しにくいからです。あるいは、ユーザインターフェイスは要求変 更に敏感であり、モデルは要求変更に鈍感であるとも言えます。オブジェクト 指向設計の有効性の1つは、要求変更に強いソフトウェア構造を作り出すこと です。そのために、変更されにくい部分をまず固め、その後で変更されやすい 部分を固めるのです。 別の言葉で説明すると、IOPを適用することでソフトウェアの「アーキテクチャ 連続性」が確保できます。よいソフトウェア構造はアーキテクチャ連続性を持っ ており、小さい要求変更は小さいアーキテクチャ変更になるべきなのです。x軸 に要求、y軸にアーキテクチャをとった関数が連続関数となり、要求を左右に微 小に揺さぶってもアーキテクチャ変更は微小である必要があるのです。 みなさんも、ほんのちょっとした要求変更がシステム全体に渡って大きな変更 を引き起こす例を、過去に経験しているはずです。このような作りは、微小な 要求変更に対してアーキテクチャがジャンプしてしまう、不連続なアーキテク チャと言えます。 Inside-Out Principleによって、アーキテクチャ連続性の高いソフトウェア構 造が作られます。設計順序はモジュールの依存性の方向と一致するので、内側 の変更は外へ伝播しますが、外側の変更は内へ伝播しません。変更の多い外側 の変更は、外側だけで食い止められるのです。 では、なぜ一番内側のモデルは安定している、と言えるのでしょうか？それは、 オブジェクト指向では、現実世界とソフトウェアモデルをできるだけ1対1に マッピングするからです(これを、"Direct Mapping Principle"と言います)。 現実世界の基本構造というものは変化しにくいため、モデルも変化しにくいの です。 「顧客」という概念は、「貸し出し画面」というユーザインターフェイスよりも システムのライフサイクルに渡って安定しています。 Inside-Out Principleの1つの具体設計例として、MVCアーキテクチャがありま す。システムを Model/View/Controllerに分割する手法です、オブジェクト指 向の発祥であるSmalltalkの開発環境から、現代のWebを使ったインターネット システムまで、応用例の大変多いアーキテクチャです。 また、Inside-Out Principleをより抽象化すると、「安定性の高いモジュール から設計せよ、そして安定性の方向と依存性の方向を一致させよ」という、 Robert C. Martin(*2)の"Stable Dependencies Principle"になります。 * * * ところで、ソフトウェア設計とは何でしょうか？ 今回紹介した原則からソフトウェア設計という活動を再定義すると、 ************************************************************ システム全体をレイアウトする「場」(アーキテクチャ)を作り、 そこに安定性の順序に従って抽象を切り出していく作業。 ************************************************************ だと言えるでしょう。今回は上記のレイアウトと順序についての原則でした。 次回は、次の「抽象を切り出す」指針についての原則を紹介していきます。 |
||||
|
[1] "Object-Orietend Software Construction 2nd"、Prentice Hall、1997 [2] "Agile Software Development"、Prentice Hall、2003 |
||||
| つづき |