┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.16 2003/10/01
■ I N D E X
┃
┣【プログラミング】ソフトウェア原則 [2] IOP(Inside-Out Principle)
┗【ＸＰ】XP実践家への道 [4] 第四道標 - 「ストーリ伝達」と「受け入れテスト」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】ソフトウェア原則 [2] IOP(Inside-Out Principle)
Inside-Out Principleは、「中から外へ向って設計せよ」という
Bertrand Meyer(*1)のソフトウェア設計原則で、「Model Before GUI」とも言
います。
ユーザとの界面を持つソフトウェアでは、まず「モデル」を設計し、後で界面
を設計するという指針になります。モデルとは、このソフトウェアが扱う問題
領域の「基本概念群」です。
例えばレンタルビデオ屋のシステムであれば「ビデオ」、「貸し出し」、「顧
客」などなどの基本的な概念群がキャプチャできるでしょう。これらの概念群
を分析し、概念間の関連や汎化構造を探索することで、「概念モデル」と呼ば
れる分析成果物が得られます。
まずこのモデルを設計し、そこからユーザインターフェイスを設計します。最
初から画面デザインや画面の遷移を細かく設計してはいけないのです。
┏━━━━━━━━━━━┓
┃ユーザインターフェイス┃
┃ ┏━━━━━━━┓ ┃
┃ ┃ ┏━━━┓ ┃ ┃
┃ ┃ ┃モデル┃⇒。。。⇒ 中から外へ向かって設計
┃ ┃ ┗━━━┛ ┃ ┃
┃ ┗━━━━━━━┛ ┃
┃ ┃
┗━━━━━━━━━━━┛
なぜこうするのでしょうか？理由は、ユーザインターフェイスは変化しやすく、
モデルは変化しにくいからです。あるいは、ユーザインターフェイスは要求変
更に敏感であり、モデルは要求変更に鈍感であるとも言えます。オブジェクト
指向設計の有効性の１つは，要求変更に強いソフトウェア構造を作り出すこと
です．そのために，変更されにくい部分をまず固め，その後で変更されやすい
部分を固めるのです．
別の言葉で説明すると、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
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+1+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+1+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E001+1+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＸＰ】XP実践家への道 [4] 第四道標 - 「ストーリ伝達」と「受け入れテスト」
こんにちは、天野勝です。
今回から読まれる方もいらっしゃると思いますので、簡単にこの連載の概要を
説明します。この連載はRoy W. Miller(*1)の提案しているXPのプラクティス(*2)
を、筆者の解釈にもとづき皆様に紹介していくというものです。
☆ ☆ ☆
今回は顧客のプラクティスです。ここでいう顧客とは仕様に関して責任を負う
人のことをさしています。
■それで伝わったつもり？
「○○って書いてあるでしょう！！(怒り)」「それって△△って意味だと思い
ましたよ！！(逆ギレ)」
この記事を読まれている方ならば、少なからず身に覚えがある光景ではないで
しょうか。口頭での情報交換よりも文書での情報交換のほうが確実だと思われ
ている方も多いでしょうが、口頭のほうが優れている場合もあります。
情報の発信側が情報をまとめきれていない場合や、情報の受信側に十分なバッ
クグラウンドがない場合には有効です。聞いても分からなければその場で聞き
直せば良いですし、相手が分かったかどうか不安ならば分かったかどうか尋ね
ればすみます。
これが、もし相手が遠隔にいて、情報の交換手段が文書だけだったならば、こ
のようなフィードバックをかけるのは難しそうです。フィードバックをかける
ことができないとなると、情報の発信側はさまざまな想定をして、あれもこれ
も書いておかないと不安になり、文書量が増えてしまいます。巨大な文書が来
たら、受信側は読む気がしなくなりますね。
そこでXPでは「ストーリ伝達」というプラクティスがあり、カードにユーザ要
求(ストーリ)を書くことを推奨します。ストーリを書くのは顧客です。文書の
証拠能力と、口頭による必要十分な情報交換を実現します。
コミュニケーションというと「情報交換」「情報共有」がまず頭に浮かぶと思
いますが、「人を動かす！話す技術」(*3)によると「コミュニケーションの最
終目的は『相手にアクションをとってもらう』ことです。いくら口頭でも、言
いっ放しではコミュニケーションとは呼べませんね。
■十分な品質のソフトウェア
顧客がストーリを書いたら、開発側はそれをタスクに分割してサインアップし
実装するわけですが、その実装の品質レベルを明確にする必要があります。品
質レベルが明確ではないと、必要以上の品質を得るためにコストをつぎ込み過
ぎてしまうことがあります。
XPでは品質基準を顧客にストーリとして書いてもらい、開発側が自動実行可能
なテストコードを書きます。これが「受け入れテスト」のプラクティスです。
プログラムであれば、書いてあるとおりに動きますので、誰でも何度でも受け
入れテストを実行できます。この受け入れテストに通るだけの品質が得られれ
ば十分です。ただ、プログラムですので、書いたとおりには動きますが、書い
た人の意図のとおりに動くとは限らないのが問題です。
受け入れテストのストーリを書くというのはストーリを理解していないことに
は書けませんので、これによりもとのストーリの漏れが見つかるというのも利
点の一つです。
☆ ☆ ☆
今回は顧客のプラクティスから「ストーリ伝達」と「受け入れテスト」を説明
しました。次回は、今回と同じく顧客のプラクティスの「頻繁なリリース」と
「リリース計画」について説明いたします。この連載に対するご意見お待ちし
ています。(天野勝)
*1: 「XP エクストリーム・プログラミング 適用編」の著者です
*2: http://www-6.ibm.com/jp/developerworks/java/021018/j_j-xp0813.html
*3: 「人を動かす！話す技術」杉田 敏、PHP新書、2002
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+3+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+3+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+3+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
今朝（火曜日）の朝の情報番組「ト○ダネ」の司会者のオープニングトークで、
SCOのLinux訴訟の話をしてました。
珍しいネタだなあ、と思いつつ、ボリューム上げて見ていたのですが、論調が
「Linux陣営とWindows陣営の戦い」という面（本来は違う話ですが）が強調さ
れていて、オープンソースの理念や、ここまでLinuxが発展してきた背景があま
り、語られなかった印象を受けました。
ここまで言うと過激かもしれませんが、MSがSCOに金払って、HPがLinux陣営に
金払うって話って、昔の冷戦時代とか、いまの中東とか？の政治局面をほうふ
つとしませんか。（＃^_^;）
（いりさ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.