IOP(Inside-Out Principle)

ずいぶん前にオブジェクト倶楽部のメルマガに書いた記事ですが、人気がある、ということなので、図を加えて再掲します。

ソフトウェア原則 [2] IOP(Inside-Out Principle)

Inside-Out Principleは、「中から外へ向って設計せよ」というBertrand Meyer(*1)のソフトウェア設計原則で、「Model Before UI」とも言います。

ユーザとの界面を持つソフトウェアでは、まず「モデル」を設計し、後で界面を設計するという指針になります。モデルとは、このソフトウェアが扱う問題領域の「基本概念群」です。
例えばレンタルビデオ屋のシステムであれば「ビデオ」、「貸し出し」、「顧客」などなどの基本的な概念群がキャプチャできるでしょう。これらの概念群を分析し、概念間の関連や汎化構造を探索することで、「概念モデル」と呼ばれる分析成果物が得られます。

まずこのモデルを設計し、そこからユーザインターフェイスを設計します。最初から画面デザインや画面の遷移を細かく設計してはいけないのです。　　

なぜこうするのでしょうか？理由は、ユーザインターフェイスは変化しやすく、モデルは変化しにくいからです。あるいは、ユーザインターフェイスは要求変更に敏感であり、モデルは要求変更に鈍感であるとも言えます。オブジェクト指向設計の有効性の１つは，要求変更に強いソフトウェア構造を作り出すことです．そのために，変更されにくい部分をまず固め，その後で変更されやすい部分を固めるのです．

別の言葉で説明すると、IOPを適用することでソフトウェアの「アーキテクチャ連続性」が確保できます。よいソフトウェア構造はアーキテクチャ連続性を持っており、小さい要求変更は小さいアーキテクチャ変更になるべきなのです。x軸に要求、y軸にアーキテクチャをとった関数が連続関数となり、要求を左右に微小に揺さぶってもアーキテクチャ変更は微小である必要があるのです。

みなさんも、ほんのちょっとした要求変更がシステム全体に渡って大きな変更を引き起こす例を、過去に経験しているはずです。このような作りは、微小な要求変更に対してアーキテクチャがジャンプしてしまう、不連続なアーキテクチャと言えます。

Inside-Out Principle によって、アーキテクチャ連続性の高いソフトウェア構造が作られます。設計順序はモジュールの依存性の方向と一致するので、内側の変更は外へ伝播しますが、外側の変更は内へ伝播しません。変更の多い外側の変更は、外側だけで食い止められるのです。

では、なぜ一番内側のモデルは安定している、と言えるのでしょうか？それは、オブジェクト指向では、現実世界とソフトウェアモデルをできるだけ１対１にマッピングするからです（これを、"Direct Mapping Principle"と言います）。現実世界の基本構造というものは変化しにくいため、モデルも変化しにくいのです。「顧客」という概念は、「貸し出し画面」というユーザインターフェイスよりもシステムのライフサイクルに渡って安定しています。

Inside-Out Principleの１つの具体設計例として、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