ロバストネス図の概要
by Scott
W. Ambler, Copyright 2003
『In Use Case Driven Object Modeling With UML』においてDoug RosenbergとKendall Scott(1999)は、ロバストネス分析という技法を説明しています。その基本となる考えは、ユースケースのステップを分析することで、その中のビジネスロジックを検証し、それまでに分析した他のユースケースと統一の取れた用語を使っていることを確認できるというものです。言い換えると、ユースケースが十分にロバスト(堅牢)で、開発対象のシステムの利用要求を表現していると確認できるということです。もう1つの用途として、ユースケース内で呼び出されるロジックをサポートするオブジェクトやオブジェクトの責務の候補を識別するために使うことができます。これは事実上、UMLシーケンス図やUMLクラス図といった他のダイアグラムへの橋渡しとなります。
ロバストネス図は、基本的にUMLコミュニケーション/コラボレーション図を単純化したものであり、図1に示すグラフィカルなシンボルを使います。この図を見れば分かるように、ロバストネス図ではいくつかの種類の概念を表します。
-
アクター：UMLユースケース図のアクターと同じ概念です。
-
バウンダリ要素：アクターが相互作用する画面や、レポート、HTMLページ、システムインターフェースなどのソフトウェア要素を表します。インターフェース要素とも呼ばれます。
-
コントロール要素：バウンダリ要素とエンティティ要素とをつなぐ役割をし、さまざまな要素とその相互作用を管理するためのロジックを実装します。プロセス要素、または単にコントローラとも呼ばれます。設計したコントローラをオブジェクト以外のものとして実装することも可能だと理解しておいてください。例を挙げると、コントローラの中には、単純なためエンティティクラスやバウンダリクラスのメソッドとして実装できるものも多くあります。
-
エンティティ要素：一般的に概念モデルに含まれるエンティティ型です。「学生」や「ゼミ」などです。
-
ユースケース(オプション)：ユースケースは他のユースケースを呼び出すことができるため、ロバストネス図にはユースケースを書けるようにしておく必要があります。
図1. ロバストネス図のシンボル
図2は、「大学に登録する」のシステムユースケースに含まれるロジックを、ホワイトボード上のロバストネス図として表現したものです。私は、単にユースケースのロジックに従って、以下の方法によってこの図を導き出しました。
-
画面や帳票といった主ユーザインターフェース要素ごとにバウンダリ要素を追加する：ユースケースの中には、アクターがボタンを押したりフィールドを編集したりといったレベルで非常に詳細に書かれているものもありますが、私はもっと高いレベルで記述し、詳細は含めない方が好きです。ただしこの図には「学生作成アイコン」を記述することにしました。後で考えると、このバウンダリクラスには「デスクトップ」と名前をつけた方がよかったかもしれません。しかし図は変更しないことにしました。私はAMの「困った時だけ更新しよう」のプラクティスに従っていて、正直なところこの小さな問題は修正するほど重要ではないからです。ユーザインターフェースフロー図を作成するのであれば、これらのクラスはおそらくその図にも書かれることになるでしょう。
-
モデリング対象のシナリオのプロセス全体を管理するコントローラを追加する：図2では「大学に登録する」という要素がこれにあたります。見れば分かるように、この要素は図をまとめる役割を果たしています。設計時には、この要素はおそらく、クラスとして、あるいは1つ以上の操作として、あるいは何らかのワークフローエンジンがアーキテクチャ全体の中に含まれているならそれによって、実装されることになるでしょう。
-
ビジネスルールごとにコントローラを追加する：これによって図上でビジネスルールが明確に示されます。ビジネスルールをまったくモデリングせず図を簡潔にしておく人もいますが、そうすると図から非常に重要な情報が抜け落ちてしまうことになります。両方のやり方を試してみて、自分に合った方法を選んでください。
-
他の複数の要素と関係するアクティビティに対してコントローラを追加する：ビジネスルールおよび「学生」エンティティと相互作用している「学生を作成する」という要素がこれにあたります。
-
ビジネス概念ごとにエンティティを追加する：「学生」と「学生授業料」がこれにあたります。概念モデルを作成するのであれば、これらの要素はおそらくそこにも書かれることになるでしょう。
-
シナリオにユースケースが含まれてればそれを追加する：私は、「ゼミに登録する」のユースケースの呼び出しを、ユースケースの標準のUML表記法で書くことにしました。ユースケースをコントローラとして書く方法もありますが、私の経験では、プロジェクトの利害関係者にとってはあまり分かりやすくないようです。AMの「見栄えより中身」の原則を思い出して、自分の状況にもっとも合った方法を選んでください。
図2. ロバストネス図の例
ロバストネス図を書くことで、このユースケースを実装するためにしなければならない作業がどのような感じかを短時間に知ることができます。構築しなければならない可能性のある要素を、目に見える形で表すことができるからです。バウンダリ要素によって、ユースケースがユーザインターフェースの開発や既存のシステムの分析作業に結び付けられます。これらのクラスの中にはエンティティ要素があり、それらは必ず概念モデルに含めなければなりません。コントローラはそれよりもずっと設計概念に近いものなので、ロバストネス図は設計への橋渡しもしているといえます。
ロバストネス図のアジャイルさを保つにはどうすればよいでしょうか。私の経験では、次のAMのプラクティスが役に立ちます。
-
利害関係者の積極的な参加：状況によって、ロバストネス図は、利害関係者と分析を行う上で非常に有効な手法となります。図2を見ると分かりますが、ロバストネス図は非常に簡単で書きやすいため、包括的なモデリング手法だといえます。
-
一時的なモデルは捨てよう：通常、ロバストネス図は、ユースケースのロジックを分析するためにホワイトボードに書きます。ユースケースを改善した後、ロバストネス図が残されるのは次の開発ステップ(以下を参照)への橋渡しをするまでで、その後は消されます。
-
適切な成果物を使おう：モデリング担当者の中には、利害関係者がユースケースからシーケンス図などの開発成果物へ論理的に飛び移れるようになれば、ロバストネス図を作成しなくなる人がいます(私もその1人です)。ロバストネス図は、利害関係者が抽象的な考え方をできるよう教育するためのもので、その目的が達成されれば手法としては不要になる、と言うこともできます。このモデルが作業全体にとってまだ大きな価値があるという理由で、ロバストネス図を使いつづけるモデリング担当者もいます。
ロバストネス図の次には何を行うのでしょうか。多くの場合、ロバストネス図はユースケースから他のモデルへの橋渡しとなります。たとえば、シーケンス図を作ってユースケースをサポートするのに必要な詳細設計ロジックを表すことは、非常によく行なわれています。また、システムのユーザインターフェースに焦点を合わせることもよくあります。つまり、プロトタイプを作成したり、あるいは直接「本物の」コーディングにかかってしまうわけです(これはロバストネス図にバウンダリ/インターフェース要素が明示されているため可能になっています)。さらに、ロバストネス図には主要なビジネスエンティティも記述されているため、それを入力情報として概念/ドメインモデリングの作業を行うことも非常に一般的です。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。
.
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including The
Object Primer 2/e, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since November 17, 2003.
|
