IOP(Inside-Out Principle) 2.0

2006/04/11

多くの方からコメントを頂いて、再考してみる。（emeitchさん、chris dingさん、ひがさん、takadsignさん、satoshi さんありがとうございました！）

まず、

Meyer のIOPは、クラシックOOの意味で正しい。

モデルTというか、一次近似というか、設計とはなんぞや、の意味である理想化された問題状況において、クラシックに正しいのだ。ここでの理想とは、

ユーザは要求を把握している。
要求は設計活動が終わるまではとりあえず変更されない。（その後変更はあるが）

ということだ。まずはこの前提に立って、あるべき設計方法とは、という解決原則を提示しているのが、IOPだといえる。

さて、１，２が疑わしいとなると、事態は「さらに」複雑になる。そうなった場合、２つのアイディアが現在世の中では提示されている。

Extreme Programming等のアジャイル開発（アプリケーションのスライスを開発し、肉付けする）
UCD（中心をシステムやモデルにおかず、ユーザにおく）

それぞれを図にするとこんな感じになる。（音楽をメタファに使うと、IOPをクラシックと位置づけ、現在旬であるものを、ポップスと捉えて重視する、というスタンスで解説してみた）

平鍋

2006/04/11 13:45:30

Comment(1)

trackback(0)

Special

- PR -

最新の投稿

コメント

essence

2006/04/12 16:00

アプリケーションスライスのイメージがとても面白いですね。
外から内、内から外、両方ありだと思うのですが、よくやりがちな失敗は普遍的構造を追求しすぎると、UIに存在しない必要ない構造をプログラム内に作ってしまうことだと思います。
今後の発展を見越してという点はあると思うのですが、その点平鍋さんのアプリーケーションスライスのイメージは必要以上のモデル（普遍構造依存部分）の実装を行わないという点を達成できているように思います。
この議論をきっかけに普遍構造と普遍度ごとの領域をどうゆう形でもつか、どのライフサイクルで実装しやすいかという観点で実装とのマッピングを整理してみているところです。

コメントを投稿する

トラックバック

http://app.blogs.itmedia.co.jp/t/trackback/77444/2957962

トラックバック・ポリシー

» このブログのTOP

» オルタナティブ・ブログTOP

プロフィール

平鍋　健児

株式会社チェンジビジョン代表取締役社長、永和システムマネジメント副社長。
オブジェクト指向開発、UMLの勘所、アジャイルな開発手法の未来、マインドマップのソフトウェア開発での利用方法、プロジェクトファシリテーション（見える化）を語ります。現在、マインドマップとUMLの融合エディタ、astah*(アスター、旧JUDE)を開発中。

詳しいプロフィール

最近のエントリー