ロバストネス分析

『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人です)。ロバストネス図は、利害関係者が抽象的な考え方をできるよう教育するためのもので、その目的が達成されれば手法としては不要になる、と言うこともできます。このモデルが作業全体にとってまだ大きな価値があるという理由で、ロバストネス図を使いつづけるモデリング担当者もいます。

ロバストネス図にはもう一つ、学習効果がある。ロバストネス分析は開発者たちにユースケース図とロバストネス図の確認を何度も強いる。これは多少は彼らの時間を奪うが同時に彼らに業務に関する学習の機会を与えこれが品質につながる。

これぞ品質向上の要諦である。