ロバストネス分析
ロバストネス図とは何か。
ロバストネス図の概要にはこうある。
『In Use Case Driven Object Modeling With UML』においてDoug RosenbergとKendall Scott(1999)は、ロバストネス分析という技法を説明しています。その基本となる考えは、ユースケースのステップを分析することで、その中のビジネスロジックを検証し、それまでに分析した他のユースケースと統一の取れた用語を使っていることを確認できるというものです。言い換えると、ユースケースが十分にロバスト(堅牢)で、開発対象のシステムの利用要求を表現していると確認できるということです。もう1つの用途として、ユースケース内で呼び出されるロジックをサポートするオブジェクトやオブジェクトの責務の候補を識別するために使うことができます。これは事実上、UMLシーケンス図やUMLクラス図といった他のダイアグラムへの橋渡しとなります。
ユースケースシナリオはホワイトボードやノート、iPad上でロバストネス図として表現することが可能だ。ステークホルダーの目の前でユースケースシナリオに従ってこの図を導き出す。導出手順は以下の通り。
- 画面や帳票といった主ユーザインターフェース要素ごとにバウンダリ要素を追加する：ユースケースの中には、アクターがボタンを押したりフィールドを編集したりといったレベルで非常に詳細に書かれているものもありますが、私はもっと高いレベルで記述し、詳細は含めない方が好きです。ただしこの図には「学生作成アイコン」を記述することにしました。後で考えると、このバウンダリクラスには「デスクトップ」と名前をつけた方がよかったかもしれません。しかし図は変更しないことにしました。私はAMの「困った時だけ更新しよう」のプラクティスに従っていて、正直なところこの小さな問題は修正するほど重要ではないからです。ユーザインターフェースフロー図を作成するのであれば、これらのクラスはおそらくその図にも書かれることになるでしょう。
- モデリング対象のシナリオのプロセス全体を管理するコントローラを追加する：図2では「大学に登録する」という要素がこれにあたります。見れば分かるように、この要素は図をまとめる役割を果たしています。設計時には、この要素はおそらく、クラスとして、あるいは1つ以上の操作として、あるいは何らかのワークフローエンジンがアーキテクチャ全体の中に含まれているならそれによって、実装されることになるでしょう。
- ビジネスルールごとにコントローラを追加する：これによって図上でビジネスルールが明確に示されます。ビジネスルールをまったくモデリングせず図を簡潔にしておく人もいますが、そうすると図から非常に重要な情報が抜け落ちてしまうことになります。両方のやり方を試してみて、自分に合った方法を選んでください。
- 他の複数の要素と関係するアクティビティに対してコントローラを追加する：ビジネスルールおよび「学生」エンティティと相互作用している「学生を作成する」という要素がこれにあたります。
- ビジネス概念ごとにエンティティを追加する：「学生」と「学生授業料」がこれにあたります。概念モデルを作成するのであれば、これらの要素はおそらくそこにも書かれることになるでしょう。
- シナリオにユースケースが含まれてればそれを追加する：私は、「ゼミに登録する」のユースケースの呼び出しを、ユースケースの標準のUML表記法で書くことにしました。ユースケースをコントローラとして書く方法もありますが、私の経験では、プロジェクトの利害関係者にとってはあまり分かりやすくないようです。AMの「見栄えより中身」の原則を思い出して、自分の状況にもっとも合った方法を選んでください。
図2. ロバストネス図の例
ロバストネス図は組み立てられたら「はい、終了」ではない。終了までには３つのステップを踏まなければならない。
モデラーはまずメンバーを招集して「会議」を催す。そこで参加者の認識を確認する。認識が違えばその原因を追究し認識の統一を図る。ロバストネス図はオブジェクト図の特殊な形態である。オブジェクト図はオブジェクトを描いた図でありオブジェクトとは「名前を持つ何か」であるが、ロバストネス図に登場するオブジェクトは名前のほかに種別と関連を持つ。種別には「バウンダリ」「コントローラ」「エンティティ」があり、それぞれも種別はアイコンを持つ。関連は他のオブジェクトとの関わのことである。この名前、種別、関連をもつオブジェクトでユースケースのフローを表現した図がロバストネス図であり、逆にロバストネス図を表現した文章がユースケースシナリオである。だがユースケースをロバストネス図にしようとしてもうまくいかないことがある。原因はユースケースシナリオにある不備、不明点である。そこでユースケース担当者に問い合わせてこれを解消し、改めてロバストネス図作成を試行する。うまくいけばロバストネス分析の第１ステップは終了する。もちろんうまくいかなければ再びユースケース担当者に問い合わせることになる。
ロバストネス分析の第２ステップは公開である。担当者は図を公開しユースケース図やロバストネス図に関心のある者たちがオブジェクトに対して自分と同じ認識を持っていることを確認する。違っていれば何らかの問題があることになるので原因を追究し解決を図る。
ロバストネス分析の第３ステップは熟成である。公開後しばらく放置したら再びメンバーを招集し認識に変わりがないことを確認する。だが変わりがあれば再びロバストネス図を修正し再度確認。承認を得られたらユースケースシナリオに反映する。これを繰り返すことで図はブラッシュアップされ安定する。
これをもってロバストネス分析は終了する。
ロバストネス図を書くことで、このユースケースを実装するためにしなければならない作業がどのような感じかを短時間に知ることができます。構築しなければならない可能性のある要素を、目に見える形で表すことができるからです。バウンダリ要素によって、ユースケースがユーザインターフェースの開発や既存のシステムの分析作業に結び付けられます。これらのクラスの中にはエンティティ要素があり、それらは必ず概念モデルに含めなければなりません。コントローラはそれよりもずっと設計概念に近いものなので、ロバストネス図は設計への橋渡しもしているといえます。
ロバストネス図のアジャイルさを保つにはどうすればよいでしょうか。私の経験では、次のAMのプラクティスが役に立ちます。
- 一時的なモデルは捨てよう：通常、ロバストネス図は、ユースケースのロジックを分析するためにホワイトボードに書きます。ユースケースを改善した後、ロバストネス図が残されるのは次の開発ステップ(以下を参照)への橋渡しをするまでで、その後は消されます。
- 適切な成果物を使おう：モデリング担当者の中には、利害関係者がユースケースからシーケンス図などの開発成果物へ論理的に飛び移れるようになれば、ロバストネス図を作成しなくなる人がいます(私もその1人です)。ロバストネス図は、利害関係者が抽象的な考え方をできるよう教育するためのもので、その目的が達成されれば手法としては不要になる、と言うこともできます。このモデルが作業全体にとってまだ大きな価値があるという理由で、ロバストネス図を使いつづけるモデリング担当者もいます。
ロバストネス図にはもう一つ、学習効果がある。ロバストネス分析は開発者たちにユースケース図とロバストネス図の確認を何度も強いる。これは多少は彼らの時間を奪うが同時に彼らに業務に関する学習の機会を与えこれが品質につながる。
これぞ品質向上の要諦である。
ドメインについて（６）
ビジネスという関心事を分離し品質を向上させることがドメイン設計の目的である。
具体的にどのようにすればいいのか。云うまでもなくシステム開発ではアーキテクチャの選定が重要である。だがドメイン開発ではこのアーキテクチャは決まっている。これについては考える余地はない。レイヤーアーキテクチャである。レイヤーアーキテクチャではコア層であるドメインを中心に設計する。以下の文書が主な成果だ。
注目すべきはこれら文書の保守性の高さである。設計文書というのは下流になっても継続的に変更されるものである。だが一般的には設計書等の下流における変更コストは非常に高いという問題がある。だがドメイン化をすればその問題がなくなる。凝集度が高いためどこにどんな機能やデータがあるかが分かり易くなる。結果修正時間が短縮される。修正だけではない。内容を把握したり、検証する時間も短縮される。変更は影響範囲の調査が難しい。下流の開発者はビジネスに精通していない。変更をどのようにすればいいか分からない。それについては聞かなければならない。所がそのソースを見せてもAPIレベルのソースコードと一緒になっている。そのため調査に高いコミュニケーションコストがかかる。
だがドメインクラスが分離されていれば対応も容易となりコミュニケーションコストも安くなる。
ドメインについて（５）
FDDはDe Lucaによって開発され、シンガポールプロジェクトで彼がCoadと作業している時に修正された。ますます短期化するビジネスライフサイクルへのレスポンスタイムに取り組むためには不要な工程を切り捨てる必要があった。
Coadは云った。「10年前、私たちの一人が110頁のプロセスを大規模開発チームのために作成した。私は彼のプロセスの各頁が価値あるものだと弁護したがチームメンバーは最後の4頁の要約を常に見て残りは無視した」
De Lucaは云った。「プロジェクトではクライアント、開発者、管理者の全てがFDDを気に入っていた。」
FDDでは2週間のインターバルで機能が納品される。頻繁に発生するこの納品はクライアントにとって意味のあるマイルストーンにより計画される。
FDDプロセスはイテレーティブなアジャイル開発の中でもっともシンプルな手法の一つである。ワークフローはこうだ。
- ドメインの開発（10%を最初に、4%を継続的に）
- フィーチャー一覧の構築（4%を最初に、1%を継続的に）
- フィーチャーの計画（2%を最初に、2%を継続的に）
- フィーチャーの設計と開発（77%をこの組み合わせに）
プロセス1が特に重要だ。ここではチーフアーキテクトがモデラーとドメインエキスパートで構成されるチームを主導する。ドメインエキスパートは要件を提供し、モデラーはこれをドメインモデルに落とす。それが役目だ。De Lucaはこのプロセス1の10%の時間が開発に於いて最も価値がある時間とした。
短いレスポンスタイムが要求されるシステム開発でFDDは要件定義を行わない代わりにドメイン設計を行う。つまり設計工程に新たな作業を導入する。これにより設計工程は複雑になるし様々な対立も発生する。これは課題のひとつだが、その代わりに得られる開発短期化の魅力は課題を鑑みてもお釣りが来る。
- オブジェクト指向モデラー対データベースモデラー・・これは思想の対立と云える。両者の対立は管理者や他の開発者も巻き込む。このようなことが起きないように管理者はメンバー選定に注意を払うべきだろう。
- プログラマ対モデラー・・これはプログラマがドメインを無視するという意味である。何の対策もしなければプログラマは自分が欲しい機能を作成する。ドメインを利用しなくてもいいなら利用しない。結果、この対立の勝者はプログラマとなる。この対立を防ぐためにはプログラマに分かり易いガイド（標準）の作成と監査が必要だ。プログラマを設計者に置き換えた対立もある。
- 管理者対モデラー・・作業量の多さ、高頻度の要件変更、情報収集の機会のなさなどが対立の原因である。これはプロセス1で解決するより他ない。
ドメインについて（４）
ドメイン分析を開始するにあたってドメイン辞書の作成、つまり語彙の収集を始めなければならない。
語彙は「解釈」と「関連」を持つ。そして語彙は一度定義すれば完了というものではない。改良され続ける事になる。
「意味」ではなく「解釈」としているのはシステム開発はチームによる協業である故である。一人しか開発者がいないのであれば「意味」でもよい。だがチームの場合、人により解釈が異なることがままある。ドメイン辞書には最初にその語彙を定義した者の「解釈」が記述されるが、別の者の「解釈」がより適切となればその定義に変更となることもある。
ドメイン辞書の作成とはアプリケーションドメインの語彙の文書化である。作成の目的は次のようなものである。
共通性分析ではドメイン辞書を作成する事から始める。ドメイン辞書にはそのアプリケーションの領域の語彙を文書化する。このようにする意図はこれから解決しようとする問題に絡む全ての側面を把握することだ。またそれと同時にソリューションの全ての側面も可能な限り把握するためである。問題を広く深く理解する前に顧客の言葉や要求を記述する文書の中から問題を一瞥するのである。また自分自身の経験もここで役立つだろう。このようなものを「ドメイン語彙」または「ドメイン辞書」と呼んでいる。これは古くからあるソフトウェア設計ツールの１つであるが現代の設計手法の中で再認識され始めている。
ドメイン辞書はその問題領域に於ける技術用語のカタログであり設計者はこのカタログに記載されている用語を使って作業を始める。ドメイン辞書は構造化設計技法をサポートするためのデータ辞書とは別物である。問題に初めてアプローチする時設計者が直面するのは目の前胃にあるニーズである。ソフトウェ開発の作業の大部分は明示された問題により発生する。そしてそのような問題は顧客自身の問題である。このようなニーズの性質からアプリケーションはその顧客の問題に特化したものになる。
「マルチパラダイムデザイン」より
ドメインについて（３）
システム開発にドメイン設計を導入する最大のメリットは凝集化である。ドメイン（ビジネス）に関わることを全て「ドメイン層」に閉じ込めることで高凝集システムとなる。
高凝集と低結合はどちらも重要な概念である。だが高凝集は低結合に比べこれまで議論される事が少なかった。これはそれだけ高凝集の価値が分かりにくい事を示しているだろう。グレーグラーマンは次のように指摘する。
オブジェクト指向開発では凝集性はクラスの責務がどの程度強く関係し収束されているかを示す基準です。関係性の高い責務を持ちあまり多くの作業をしないクラスは高凝集性を持ちます。凝集性の低いクラスは関係のない仕事をこなしたり仕事が大量になったりします。
「実践UML」より
凝集化はシステムの可読性、変更性、検証性、拡張性、そして再利用性は格段に向上する。凝集度はまた強度とも云われる。どれだけ同じ関心事を集めるかで凝集度が決まる。
凝集化の中でもビジネスという関心事を集めてグループの強度を上げていく行為をドメイン化と云い、その集合をドメイン層と云う。対してアプリケーション層は「ビジネス以外」に関わる集合である。この２つの集合は高凝集である。そして高凝集モジュールは他のモジュールとの結合度が低くなる。
ドメイン巣をインフラストラクチャ層とユーザインターフェース層から分離する事により各レイヤを遥かに明確に設計できるようになる。レイヤを明確にすると保守にかかるコストが格段に低くなるがそれは各レイヤーが別々の速度で進化して別々の要求に対応する傾向があるからである。このように分離することで分散システムにも配置し易くなる。別々のレイヤをそれぞれ別々のサーバやクライアントに柔軟に配置できるようにする事で通信のオーバーヘッドを最小化して性能を向上させる事ができるのだ。
「ドメイン駆動設計」より
だがこの凝集化、すなわちドメイン層の分離は知識と経験が必要である。思った以上に難しい。単純なシステムでさえ経験がなければ失敗するリスクが高い。 それ故小規模な開発ではドメインによる凝集化というアプローチが適さないこともある。
利口なUIパターンはユーザインターフェースにビジネスロジックを組み込む手法である。例えばユーザインターフェースでJavaScriptによるビジネスロジックプログラムを組み込むことがこれにあたる。凝集化とは真逆のアプローチだが、多くの小規模開発ではこの利口なUIパターンがしばしば「推奨」される。理由は次のケースでメリットがあるからである。
単純なアプリケーションの場合➡️単純なので分離しない方が生産性と保守性が高い。無理に分離すると逆に複雑になる。
有能な開発者がいない場合➡️レイヤ化のノウハウを学習する必要がない。レイヤ化の実践は開発者の育成と経験者による牽引がないと難しい。
ドメインについて（２）
「分析」とは何か。一般的な「分析」とは収集した情報を要素に分けて整理し、分析目的に合致した意味合い（メッセージ）を得ることである。システム開発に於ける「分析」も同様である。情報を分け、整理し、メッセージを得ること。だがシステム開発の現場では分析者が「分析」を正しく認識していないことは珍しくない。
実際そのような分析者にとって「分析」はクライアントとの話をそのまま要件定義書にトレースする行為にすぎない。これは本来の意味である「情報を収集し分けて整理し意味合いを見つける」という行為とは異なる。そのような分析によって作成された要件定義書は曖昧で複雑で不完全となる。
それでも通常の開発であれば曖昧さ、複雑さ、不完全さはレビューによって検知されるが、開発期間が十分でない場合、レビューがその役割を果たさない。そのため曖昧で複雑で不完全な要件定義書はそのまま設計工程、プログラム工程へと流れてしまう。
この問題の原因は分析者（或いはレビューア）の無知と怠惰である。
だが彼らはこう云い分けをする。
「クライアントの要求が曖昧で複雑なのだから要件定義書が曖昧で複雑になるのは仕方がない」
クライアントはただ、自分たちが活動しているドメインに於いて今後自分たちが関心がある事、そして実現したい事を話したいだけである。分析者がドメインに精通していればクライアントのイメージは伝わるはずである。然し勉強不足の分析者にそのイメージは伝わらない。故に完成したシステムは寿命の短いシステムとなってしまう。
よいシステムの分析対象はアプリケーションだけではない。アプリケーションドメイン、マーケットドメイン、企業ビジョンまでもが対象なのである。
ソフトウェア開発の実プロジェクトでの大半では極めて初期の段階から複数の開発コンフィグレーションの分岐を考慮する必要がある。単一システムのためにスタートしたプロジェクトであっても何らかの分岐の発生は通常の事で、マーケットが成長したり顧客のシステムに対する期待が拡がったりするとそれに合わせてプロダクトがカスタマイズされる。従って当面のアプリケーションを分析するだけでは十分とは云えない。分析の範囲をアプリケーションドメイン全体、さらにはマーケットドメイン、企業ビジョンにまで広げる必要がある。つまりアプリケーション分析ではなくドメイン分析を行いたいのである。ドメインとは何だろうか。”American Heritage Dictionary"によればドメインとは「活動・関心・機能の範囲、領域」のことである。ドメイン分析という言葉は基礎的なビジネス上の抽象を研究するということを意味する事が多い。例えばファイナンシャルトレーディングはドメインである。そのドメインの抽象の中にはトランザクション、株、債券、セキュリティ、先物取引、金融派生商品、外国株などが含まれる。また電話通信も一つのドメインである。呼び出しコール、電話、回線、リレー、加入者などがドメインの重要な抽象となる。ファイナンシャルトレーでイングや電話通信はアプリケーションドメインである。各々のアプリケーションドメインは１個のビジネス、企業、マーケットを定義し、我々はそこから完全なシステムのファミリを見つけ出す事ができる。「マルチパラダイムデザイン」より
ドメインについて（１）
ドメインとは、企業が定めた自社の競争する領域・フィールドのこと。事業ドメインともいう。
企業はドメイン（事業ドメイン）の設定により、戦う領域を設定し、組織活動の指針とする。ドメインは、企業の方向性を示す上で、非常に重要な意味を持つ。
例えば、ある鉄道会社がドメインを「鉄道事業」と定義した場合と「総合輸送事業」と定義した場合とでは、おのずと環境変化に対応する発想が変わってくる。「鉄道事業」と定義した場合は、輸送手段の進歩あるいは他の輸送手段との競合に対し、鉄道という枠の中でのみ差別化して優位に立つことを模索する。
一方、「総合輸送事業」と定義した場合は、経営環境の変化に対し、鉄道以外の輸送手段にも参入することにより競争優位を確立することを考える。つまり、他の輸送手段との競合を常に視野に入れた戦略を立てることになる。
ドメインを掲げることによって経営資源をフォーカスさせ、継続的に見ても経営資源を一貫して蓄積でき、組織全体として戦う方向性を定めることができる。
一方、ドメインを予め限定しないまま、多角化や買収を行って多様な事業分野に進出する企業もある。そういう状況においては、事業機会の拡大とともにドメインは次第に拡大する傾向にある。
設計そのものの目的は、ビジネス上のニーズを満たす事だ。そしてビジネス上のニーズはユーザの期待に左右される。成功はビジネスを十分に理解しているかにかかっている。ここでのビジネスはドメインと言い換える事もできる。システムを構築するという時、そのドメインのためにシステムを作成することになるのだ。しかし、設計の目的というのはそれだけではない。例を挙げよう。まず、設計は実装を導くためのものだ。その実装を分かり易く構築し易いものにするのは設計の責任である。（アインシュタインの言葉を言い換えて引用すれば、可能な限り作り易く、然しそれは以下にはならないように、）また、設計はシステム構築をするに足るものでなければならない。ここでいうシステムは時間の経過とともに拡張されて新しいマーケットや新しいアプリケーションにも適用できるものでなければならない。「マルチパラダイムデザイン」より
設計にはアプリケーション設計とドメイン設計がある。
アプリケーション設計はシステム寄りである。たいていのアプリケーション設計担当者はシステムに関してはよく知っているが、ビジネスには無関心である。一方、ドメイン設計はビジネス寄りである。たいていのドメイン設計担当者はビジネスに関してはよく知っているが、システムには無関心である。
２つの設計は対等ではない。設計の中心はドメイン設計である。ドメイン設計はビジネス要件をもとに行われ、ドメイン設計書にはビジネスの全てが網羅される。故に、ドメイン設計担当者はドメイン、すなわちビジネスに精通していなければならない。一方、アプリケーション設計にはビジネス要件は含まれないからアプリケーション担当技術者はビジネスを知らなくてもよいということになる。
ドメイン設計を導入するとシステムの凝集化が促進される。導入コストは安くないがその引き換えに得られる凝集化は大きい。エリックエバンスは次のように述べている。
オブジェクト指向プログラムでは、ユーザインターフェース（UI）、データベースおよびその他の補助的なコードが、ビジネスオブジェクトにビジネスオブジェクトに書かれる事はしばしばある。また、ビジネスオブジェクトが新たに追加されるときには、UIウィジェットやデータベーススクロプとの振る舞いに組み込まれてしまう。こういうことが起きるのは、短期的に見ると、動くようにするには最も簡単な方法だからだ。ドメイン関連のコードがこうした膨大な他のコードに拡散してしまうと、コードを見て意味を理解するのが極めて困難になる。ユーザインターフェースに対する表面的な変更が、実はビジネスロジックを変更する事もある。ビジネスルールを変更するために、ユーザインターフェースコードやデータベースコード、その他のプログラムコードを丹念に追跡しなければならないかもしれない。これでは、凝集度の高いモデル駆動のオブジェクトを実現するのは現実的ではなくなる。また自動化されたテストコードはぎこちないものになってしまう。全ての技術とロジックがそれぞれの活動に関連しているので、プログラムを非常にシンプルに保たなければ理解できなくなってしまう。「エリックエバンスのドメイン駆動設計」より
ドメイン設計をせずにアプリケーション設計を始めてしまうとビジネスの変化に対応できなくなる。その結果システムの寿命が短くなってしまう。
凝集化のメリットは再利用性、拡張性、可読性等の向上である。デメリットは初期コストだが、これは新しい事を始める際に避けては通れない道である。
