井上 研一 オブジェクト指向分析・設計（OOAD）講座は、第4回を迎えました。
前回はブログシステムの責務側面と静的側面を分析したので、今回は動的側面の分析の第一歩となるロバストネス分析を説明します。
Diorama d’usine à l’ancienne / zigazou76
画面の設計
前回、責務側面の分析でアクターとユースケースを、静的側面の分析でクラスを導出しました。
その作業は、作りたいシステムのことそのものというより、そのシステムでやりたいこと（サービスとかビジネス）の分析のように感じたと思います。それは、そのとおりです。コンピュータを使ってやりたいサービスやビジネスのことがきちんと整理されていなければ、システムを作ることは出来ません。
例えば、リーンスタートアップの考え方では、実際にユーザに試してもらってフィードバックを得ないと、サービスやビジネスの詳細を決めることは出来ないと思うかもしれません。しかし、フィードバックを得られるだけのシステムとなるMVPを作るには、MVPの範囲ではきちんとサービスやビジネスの詳細が決まっていなければならないのです。
これから説明するロバストネス分析では、画面の概要とその遷移程度の設計が行われていることが前提となっています。この連載では画面設計については説明しませんが、責務側面・静的側面の分析と並行して（その分析で深まった理解をベースとして）、MVPの範囲では画面設計も行う必要があります。
もちろん、MVPは1回作ったら終わりではありませんから、ユーザの評価等を受けて、何度も作り直したり、出来ることを増やしたりしながら、画面も分析も洗練されていきます。
ロバストネス分析とは
静的側面の分析で導出したクラスは、システム化対象としている領域（ドメイン）そのものを表現しているので「ドメインモデルにあるクラス」です（微妙な表現ですが、あまり「ドメインクラス」という表現を聞かないので・・・）。
第1回で、オブジェクト指向でのシステムの考え方は、コンピュータの中に箱庭を作るような物だと書きましたが、ドメインモデルは箱庭そのものであり、そこにあるクラスは箱庭の登場人物です。
動的側面の分析とは、その登場人物である複数のクラス（厳密にはそのオブジェクト）の間で、どのようなやりとりを交わせば、与えられた責務を実現出来るかを分析することです。
そのため、責務は細分化されて、それぞれのクラスに割り当てられていく必要があります。ロバストネス分析の主眼は、責務の細分化にあります。つまり、クラスに責務を割り当てる際の元ネタを作るのです。
ロバストネス分析の決まり
ロバストネス図には、ユースケース図に出てきたアクター以外に、新たに3つのオブジェクトタイプが増えます。
バウンダリ：画面や画面上のボタンなど、アクターとシステム内部の境界（バウンダリ）にあるオブジェクトタイプ。
コントロール：バウンダリからの指示を受けてエンティティを操作するなど、アプリケーションロジックを表すオブジェクトタイプ。
エンティティ：システムが管理するデータを示すオブジェクトタイプ。静的分析で導出されたクラスは、エンティティになります。
ここにアクターを含めて4つのオブジェクトタイプは、それぞれがメッセージのやりとりが出来るか否かに決まりがあります。
メッセージのやりとりが出来るすべては、上図に示されているとおりです。
- アクターはバウンダリとだけやりとりできる
- バウンダリはコントロールとだけやりとりができる
- コントロールはエンティティか、他のコントロールとやりとりができる
- エンティティはコントロールとだけやりとりができる
アクターは責務側面の分析で、エンティティも静的側面の分析で、既に導出済みです。バウンダリは責務分析で導出したユースケースを満たすような（ある程度の）画面設計によって導出されます。
つまり、ロバストネス分析に入る時点で導出されていないのは、コントロールだけです。よって、コントロールの導出がロバストネス分析の主眼となるわけです。
ロバストネス分析によって、エンティティの抜け漏れが発見されることがあります。その際は、静的側面の分析に戻ってエンティティをクラスとして加えましょう。
「記事を投稿する」ユースケースの分析
ロバストネス分析の実例を示しましょう。
記事投稿画面を表示するには、投稿者にカテゴリを選択させる必要があるので「カテゴリを取得する」コントロールが必要です。
記事投稿画面には投稿ボタンがあり（バウンダリ間に線が引かれていますが、線の端に集約を示す菱形が付いているので、メッセージのやりとりを示すものではなく、ロバストネス図の決まりに反するものではありません）、「記事を登録する」コントロールを呼び出しています。また、「記事を登録する」コントロールから「記事にカテゴリをセットする」コントロールを呼び出して、記事を登録する際に一緒にカテゴリもセットするようになっています。
このロバストネス図によって、記事の投稿は実現できそうです。ただ、記事を投稿した後にどの画面が表示されるのかが分かりません。これは、もう少し分析を続ける必要がありそうですね。
「記事を読む」ユースケースの分析
もう一つ実例です。「記事を読む」ユースケースには、記事の一覧画面と詳細画面があります。（当サイトでも良いですが、よくあるブログサイトを思い出してください。大抵、記事の一覧と、個別の記事を表示する詳細画面がありますね）
「最新の記事を5件取得する」コントロールと、「記事を1件取得する」コントロールから、「記事に紐付くカテゴリを取得する」コントロールが共用されています。このように、共通化が図れるのなら、そのように分析することが出来ます。
記事詳細画面には投稿されたコメントを表示したいので、「記事に対するコメントを取得する」コントロールもありますね。
まとめ
ロバストネス分析により、コントロールが導出されたことで、何となくプログラムが書けそうな雰囲気になってきたのではないでしょうか。
次回は（たぶん）最終回として、ここまでの分析の成果を、CakePHPでの実装にどうやって持っていくのかを説明したいと思います。