本稿は、2003年11月号に掲載した「ロバストネス分析実践 第一回」の続編になります。前回の記事を掲載した後に、読者の方々から様々なご意見、ご感想を頂いていたにもかかわらず、今回の第二回掲載までに、1年3ヶ月もの空白期間を作ってしまいました。本稿の掲載を心待ちにしていた読者の方々にお詫びいたします。
はじめに
前回の記事の訂正
前回の記事ではロバストネス分析を適用したソフトウェア開発の流れ、ロバストネス分析の方法を説明しました。 しかし、前回の記事を掲載してから今回の記事までの 1年3ヶ月の期間で、よりよいロバストネス分析について考えた結果、前回の記事で紹介した内容についていくつか訂正を加えようと思います。いずれ、下記の訂正を前回の記事に反映する予定です。
ロバストネス分析の範囲からユーザーインターフェースの定義を除く
前回の記事では、ロバストネス分析の「バウンダリを識別する」作業でバウンダリの属性を定義して、ユーザーインターフェースの項目を定義していました。 しかしながら、大抵のソフトウェア開発プロジェクトでは画面仕様書や帳票仕様書など、ユーザーインターフェースごとに仕様（以下、UI仕様）を作成します。UI仕様にはユーザーインターフェースに含む項目や、画面遷移が定義されます。そのため、ロバストネス分析では UI仕様をインプットとして作業するものとします。
ロバストネス分析でのクラス図と相互作用図は平行して記述する
前回の記事では、「クラス図の作成」と「相互作用図の作成」を別の作業としていました。 しかし、実際のロバストネス分析では、最初に完成したクラス図を作成してから、相互作用図を書くことはほぼ不可能です。そのため、クラス図と相互作用図は平行して作成するものとします。
概念モデルとエンティティのモデルは別物
前回の記事では、概念モデルのクラスとエンティティを同一視していました。 しかし、概念モデルはソフトウェア開発プロジェクトで対象としているドメインを簡潔に説明するためのモデルで、対してエンティティのモデルはソフトウェアが動作するためにエンティティに必要とされるデータや振る舞いを定義するためのモデルです。 エンティティをモデリングする過程で概念モデルに手直しを加えてしまうと、対象ドメインを簡潔に説明できないモデルになってしまいます。そのため、概念モデルとエンティティのモデルは、抽象度が異なる別のモデルであると考えます。
コントロールの粒度の変更
前回の記事では、コントロールを定義する粒度として、ユースケースの単位と、ユーザーのイベントの単位の2つがあると説明しました。しかし、本稿ではこれらとは別の粒度を採用します。3つ目の粒度とは、似たイベントやビジネスルールをまとめて 1 つのコントロールとして定義します。こうすることにより、凝集度の高いコントロールができあがり、次の設計作業でこのコントロールをコンポーネントとして設計することができます。
モデリングの題材
前回の記事では、ロバストネス分析の基本的な考え方や作業の進め方の説明に重点をおいていました。 今回の記事では、オーピス商店という架空の酒専門のディスカウントショップという題材をもとにして、実際のプロジェクトに近い形式でロバストネス分析を行います。
オーピス酒屋の背景
オーピス酒屋は、首都圏密着型(約20店舗)の酒専門ディスカウントショップです。近隣のスーパーと比較しても遜色のない低価格、スーパーと比べて圧倒的に多い商品数、商品に関する専門知識を売りにして、昨年までの5年間、順調に業績を伸ばしてきました。
しかし、今年に入ってからは業績が伸び悩み始めたため、新たな打ち手を考えてより多くの顧客を呼び込むことになりました。
オーピス酒屋の経営陣は、その新たな打ち手の1つとしてポイント制度を導入します。そのために、現在運用しているPOSシステムにポイント制度対応の機能追加をすることになりました。
オーピス酒屋の新業務フロー
オーピス酒屋では、ポイント制度を導入した場合に、以下のような新業務フローになると想定しています。
ポイント会員を登録する流れ
- ポイント会員の申請をする
オーピス商店の顧客は各店舗にある「ポイント会員申請書」の記入をし、店舗にいるポイント会員受付担当に渡します。 - ポイント会員の申請を受け取る
ポイント会員受付担当は、「ポイント会員申請書」に記入ミスがないか確認し、記入ミスがなければ顧客にポイントカードを渡します。その際に、「ポイント会員申請書」にポイントカードの番号を記入します。 - ポイント会員の申請を受け取る
ポイント会員受付担当は、営業時間終了後にすべての「ポイント会員申請書」を回収し、メンテナンス担当に渡します。 - ポイント会員を登録する
メンテナンス担当は、「ポイント会員申請書」に記入されている内容をシステムに登録します。
ポイントを使用して商品を購入する流れ
- 購入する商品を選ぶ
オーピス商店の顧客は、ポイントを使用しない場合と同様に、店舗にある商品から購入するものを選び、会計をしにレジへ行きます。 - 商品を販売する
チェッカーは、ポイントカードとすべての商品をスキャンし、顧客に合計金額を伝え、顧客から現金を受け取り、お釣りとポイントカードを顧客に返します。顧客はポイントを使って買い物をすることもできます
このシステム開発プロジェクトでは、既存システムにポイント会員を登録する作業と、商品を販売する作業を支援する機能を追加します。
概念モデル
以下の図は、ポイント制度の概念モデルです。
- 販売
オーピス酒屋で１回の販売に関する情報。１回の販売で複数の商品を販売することができる。販売した金額によって、ポイントが決まる。 - 商品
オーピス酒屋で販売する商品 - ポイント会員カード
ポイントを貯めるためのカード。ポイント会員カードを持つ顧客が商品を購入すると、ポイントが貯まり、ポイントを使用して商品を購入することができる。
ユースケースモデル
今回、開発するシステムの利用者であるアクターには、以下の2つがあります。
- メンテナンス担当
ポイント会員カードのマスタデータを管理します。 - チェッカー
レジ精算を行って商品を販売します。
今回、開発するシステムが提供するユースケースには、以下の4つのユースケースがあります。
UC001 ポイント会員を登録する
事前条件：メンテナンス担当はシステムにログインしている。
基本フロー
- メンテナンス担当は、ポイント会員情報（ポイント会員番号、氏名、住所など）を入力する。
- システムは、登録するポイント会員情報が正しいことを確認し、登録する。
- システムは、登録されたポイント会員情報を表示する。
代替フロー1 (基本フローの2で不正なポイント会員情報を見つけた場合)
2a. システムは、不正な入力情報を表示する。（基本フロー1に戻る）
UC002 ポイント会員を照会する
事前条件：メンテナンス担当はシステムにログインしている。
基本フロー
- メンテナンス担当は、ポイント会員番号をもとにポイント会員を指定する。
- システムは、ポイント会員情報を表示する。
UC003 ポイント会員を更新する
事前条件：メンテナンス担当はシステムにログインしている。
基本フロー
- メンテナンス担当は、ポイント会員番号をもとにポイント会員を指定する。
- システムは、ポイント会員情報を表示する。
- メンテナンス担当は、ポイント会員情報を入力する。
- システムは、更新するポイント会員情報が正しいことを確認し、登録する。
- システムは、更新されたポイント会員情報を表示する。
代替フロー1 (基本フローの4で不正なポイント会員情報を見つけた場合)
4a. システムは、不正な入力情報を表示する。(基本フロー３に戻る)
UC004 商品を販売する
事前条件：チェッカーはレジにログインしている。前の顧客の精算が済んでいる。
基本フロー
- チェッカーは、バーコードリーダーでポイント会員カード、または商品をスキャンする。
- システムは、ディスプレイに商品と販売情報を表示する。
- 1から2を繰り返す。
- チェッカーは、預かり金額を入力し、現金計算の指示をする。
- システムは、レシートを出力する。
代替フロー1 (基本フローの4でポイント会員カードを使って買い物をする場合)
4a. チェッカーは、ポイント精算の指示をする。(基本フロー5に戻る)
ユーザーインターフェース
開発する4つのユースケースには、メンテナンス担当者が利用する画面が4つ、チェッカーが利用する画面が2つ、出力するレシートが1つと、全部で7種類のユーザーインターフェースがあります。
UC001 ポイント会員を登録する
メンテナンス担当者が利用するユースケースUC001では、「ポイント会員新規登録画面」からポイント会員情報を入力してボタンを押下すると、ポイント会員情報に不備がなければ「ポイント会員画面」が表示され、ポイント会員情報に不備があれば「ポイント会員新規登録画面」にエラー情報が表示されます。
図 4 UC001 のユーザーインターフェース
UC002 ポイント会員を照会する
メンテナンス担当者が利用するユースケース UC002では、「ポイント会員検索画面」からポイント会員カード番号を入力してボタンを押下すると、「ポイント会員画面」が表示されます。
図 5 UC002 のユーザーインターフェース
UC003 ポイント会員を更新する
メンテナンス担当者が利用するユースケース UC003 では、「ポイント会員検索画面」からポイント会員カード番号を入力してボタンを押下すると、「ポイント会員画面」が表示され、この画面で項目を修正しボタンを押下すると、修正内容に不備がなければ修正内容が「ポイント会員画面」に表示され、修正内容に不備があればエラー情報が「ポイント会員画面」に表示されます。
図 6 UC003 のユーザーインターフェース
UC004 商品を販売する
チェッカーが利用するユースケース UC004では、「商品販売画面」が表示されている状態で、商品やポイント会員カードをバーコードリーダーでスキャンすると「商品販売画面」に商品の情報やポイントカードの情報や合計金額が表示されます。
チェッカーが受け取った現金の金額を入力すると、同様に「商品販売画面」に現金の金額が表示されます。
チェッカーが現金計算を指示すると、「販売結果画面」が表示され、「販売レシート」が出力されます。
ロバストネス分析の適用
それでは、概念モデルやユースケースや UI仕様をもとにして、UC001、UC002、UC003、UC004のロバストネス分析を行います。
UC001 ポイント会員を登録する
クラス ( バウンダリ、コントロール、エンティティ ) を識別する
ロバストネス分析で始めにすることは、ユースケースを実現するために必要となるバウンダリ、コントロール、エンティティを識別することです。これらのクラスを識別するために概念モデル、ユースケース、UI仕様を用います。
バウンダリは、UI仕様から識別します。UI仕様には、ユースケースに登場する画面や帳票などのユーザーインターフェースが定義されているので、これをそのままバウンダリとして定義します。UC001の例では、「ポイント会員登録画面」と「ポイント会員更新画面」が UI仕様に定義されているので、これをそのまま、「ポイント会員登録画面」バウンダリ、「ポイント会員更新画面」バウンダリとして定義します。
エンティティは、主に概念モデルから識別しますが、それだけではなくユースケースや UI仕様から識別することもあります。概念モデルは対象ドメインを簡潔に説明するためのモデルなので、ソフトウェアに必要な情報のすべてが記述されているとは限りません。そのため、ソフトウェアに必要なエンティティを、概念モデルだけではなく、ユースケースやUI仕様からも識別しなければならないわけです。UC001 はポイント会員を登録するユースケースなので、概念モデルで定義されている「ポイント会員カード」を「ポイント会員カード」エンティティとして定義します。UI仕様から識別できるエンティティは特にありません。
コントロールは、概念モデルやユースケースやすでに定義済みのバウンダリやエンティティケースを総合して識別します。UC001 はポイント会員を登録することを目的としたユースケースです。このユースケースのようにポイント会員のメンテナンス機能に特化したユースケースがある場合には、「ポイント会員カード」エンティティの管理に特化した「ポイント会員カード管理」コントロールを定義します。
基本フローの相互作用図を作成する
ユースケースを実現するために必要となるバウンダリ、コントロール、エンティティを識別した後には、これらのクラスにどのような操作が必要で、どのように相互作用しなければならないのか定義します。クラスのオブジェクトの相互作用を定義する UML の図には、シーケンス図とコラボレーション図がありますが、ロバストネス分析で使う相互作用図としてはコラボレーション図が適当です。ロバストネス分析の相互作用図は、様々なバウンダリ、コントロール、エンティティが登場するものです。様々なクラスが登場する場合に、シーケンス図を使ってしまうと横長の図になってしまい、図の可読性が非常に下がってしまうため、コラボレーション図の方が適当なわけです。
コラボレーション図を作成するために、ユースケースのイベントフローやUI仕様を用います。コラボレーション図を作成する場合には、ユースケースのイベントフローの流れに従ってモデリングすると良いでしょう。
UC001の基本フロー
- メンテナンス担当は、ポイント会員情報を入力する。
このイベントから、アクターが「ポイント会員登録画面」バウンダリにポイント会員情報を入力するところからユースケースが始まることが分かります。
UC001の基本フロー
- システムは、登録するポイント会員情報が正しいことを確認し、登録する。
- システムは、登録されたポイント会員情報を表示する。
このイベントのようにシステムが行う処理は、コントロールやエンティティの操作として定義します。コントロールの操作とエンティティの操作の違いをまとめると以下のようになります。
- コントロール
- バウンダリからシステムの入力の情報を受け取る。
- 複数のエンティティに関わるビジネスルールを処理する。
- エンティティの操作を呼ぶ。
- バウンダリへシステムの出力の情報を送る。
- エンティティ
- 個々のエンティティに関わるビジネスルールを処理する。
「2. システムは、登録するポイント会員情報が正しいことを確認し、登録する。」のイベントで示している「ポイント会員情報の正当性の確認」、「ポイント会員情報の登録」は「ポイント会員カード」エンティティ固有のビジネスルールです。そのため、「ポイント会員カード」エンティティに「ポイント会員情報の正当性の確認」、「ポイント会員情報の登録」の処理をする操作「作成する」を定義します。
ただし、エンティティにのみビジネスルールがあり、コントロールはビジネスルールがないからといって、コントロールには操作が必要ないわけではありません。ロバストネス分析では、バウンダリはコントロールの操作しか呼ぶことはできないというルールがあります。そのために、コントローラにエンティティの操作を呼ぶ操作を定義し、このコントローラの操作をバウンダリが呼ぶように定義します。
このユースケースの例なら、「ポイント会員カード管理」コントロールにエンティティの操作を呼ぶ操作「ポイント会員を登録する」を定義して、「ポイント会員新規登録画面」バウンダリはこの操作を呼ぶようにコラボレーション図を記述します。
「3. システムは、登録されたポイント会員情報を表示する」のイベントでは、「ポイント会員カード管理」コントロールで取得したポイント会員の情報を「ポイント会員更新画面」バウンダリに表示します。そのため、「ポイント会員更新画面」バウンダリに操作「表示する」を定義し、「ポイント会員カード管理」コントロールからこの操作を呼び出します。
代替フローのコラボレーションを定義する
基本フローのコラボレーション図を記述した様に、代替フローでもコラボレーション図を記述します。
UC001の代替フロー1 (基本フローの2で不正なポイント会員情報を見つけた場合）
2a. システムは、不正な入力情報を表示する。（基本フローの1に戻る）
「ポイント会員新規登録画面」バウンダリから不正な情報が入力された場合には、「ポイント会員登録画面」バウンダリにその不正な情報を表示しなければなりません。そのため、「ポイント会員登録画面」バウンダリに操作「不正情報を表示する」を定義し、「ポイント会員カード管理」コントロールからこの操作を呼び出すようなコラボレーション図を記述します。
コントロールやエンティティのビジネスルールを定義する
基本フロー、代替フローのコラボレーション図の作成が終わったら、コントロールやエンティティの操作に必要なビジネスルールを定義します。このユースケースの例では、「ポイント会員カード管理」コントロールにはビジネスルールはありません。「ポイント会員カード」エンティティには、どのような属性が必要か、属性にはどのような情報を保持することができるか（裏を返せば属性に保持できない不正なデータとは何か）、といったようなビジネスルールを定義することになります。このようなビジネスルールをもとにして、エンティティの属性を定義します。
UC002 ポイント会員を照会する
既存のクラスや操作を再利用してロバストネス分析をする
ロバストネス分析では、新しいバウンダリ、コントロール、エンティティを定義するだけではなく、既存のバウンダリ、コントロール、エンティティを再利用します。
UC002は、UC001と同じようにポイント会員情報のメンテナンス機能を提供するユースケースです。そのため、UC001で識別した多くのクラスを再利用できます。
UC002では、UI仕様にある「ポイント会員検索画面」と「ポイント会員画面」に対応するバウンダリが必要になります。「ポイント会員検索画面」に対応する「ポイント会員検索画面」バウンダリを新しく定義しますが、「ポイント会員画面」については、UC001のロバストネス分析で定義した「ポイント会員画面」バウンダリを再利用します。
バウンダリと同様に、UC001のロバストネス分析で定義した「ポイント会員カード」エンティティを再利用します。
コントロールについても、UC001のロバストネス分析で定義した「ポイント会員カード管理」コントロールを再利用します。
次に、基本フローのコラボレーション図を作成します。必要に応じて、すでに定義されているバウンダリ、コントロール、エンティティの操作を再利用します。
UC002 の基本フロー
- メンテナンス担当は、ポイント会員番号をもとにポイント会員を指定する。
このイベントから、アクターが「ポイント会員検索」バウンダリにポイント会員番号を入力するところからユースケースが始まることが分かります。
UC002 の基本フロー
- システムは、ポイント会員情報を表示する。
システムが画面にポイント会員情報を表示するためには、画面に入力したポイント会員番号から適切な「ポイント会員カード」エンティティを探し出さなければなりません。このために、「ポイント会員カード管理」コントロールに操作「ポイント会員カード番号からポイント会員を検索する」を定義し、「ポイント会員カード」エンティティに操作「取得する」を定義します。
UC003 ポイント会員を更新する
既存のクラスや操作を再利用してロバストネス分析をする
UC003に必要なバウンダリ、コントロール、エンティティは、UC001、UC002で定義済みなのでこれを再利用するだけで、新たに定義するものはありません。
UC003の基本フロー
- メンテナンス担当は、ポイント会員番号をもとにポイント会員を指定する。
- システムは、ポイント会員情報を表示する。
イベント1、イベント2で行う処理はUC002と同じなので、このUC002のコラボレーション図と同じようにコラボレーション図を作成します。
UC003 の基本フロー
- メンテナンス担当は、ポイント会員情報を入力する。
- システムは、更新するポイント会員情報が正しいことを確認し、登録する。
- システムは、更新されたポイント会員情報を表示する。
「ポイント会員カード管理」コントロールや「ポイント会員カード」エンティティには、ポイント会員情報を更新するための操作がないため、「ポイント会員カード管理」コントロールには操作「ポイント会員を更新する」を、「ポイント会員カード」エンティティには操作「更新する」を定義します。
包含するユースケースを識別する
ロバストネス分析をする過程で、同じようなユースケースのイベントフローやコラボレーション図に何度か出会うことがあります。そのイベントフローを独立したユースケースとして定義できないか、検討してみましょう。UC003では、イベントフローの途中までがUC002のイベントフローと同じなので、UC003からUC002を包含する(include)ことができます。UC002を包含するように変更するのであれば、UC003のイベントフローを見直します。
UC003(見直し後)
事前条件：メンテナンス担当はシステムにログインしている。
基本フロー
- UC002「ポイント会員を照会する」ユースケースのイベントフローに従って処理する。
- メンテナンス担当は、ポイント会員情報を入力する。
- システムは、更新するポイント会員情報が正しいことを確認し、登録する。
- システムは、更新されたポイント会員情報を表示する。
代替フロー 1（基本フローの 3 で不正なポイント会員情報を見つけた場合）
3a. システムは、不正な入力情報を表示する。（基本フローの 2 に戻る）
UC004 商品を販売する
複雑なユースケースのロバストネス分析をする
UC004はこれまでのメンテナンス系のユースケースと違い、複雑な処理を行うユースケースです。そのため、これまで識別してこなかったバウンダリ、コントロール、エンティティを識別し、複雑なコラボレーション図を作成することになります。
まずは、UC004 に必要なクラスを識別します。
UI仕様書には、UC004に登場する画面として「販売画面」と「販売結果画面」、「販売レシート」が定義されているので、これを「販売画面」バウンダリ、「販売結果画面」バウンダリ、「販売レシート」バウンダリとして定義します。
UC004では、商品や販売の情報も扱えば、ポイント会員カードも扱います。そのため、概念モデルで定義している「販売」クラスを「販売」エンティティとして、「商品」クラスを「商品」エンティティとして定義します。ただし、「ポイント会員カード」エンティティは既存のものを再利用します。
UC004 では、商品を販売するための処理を行っています。そのため、販売のビジネスルールに特化したコントロールが必要になります。そのため、「商品販売」コントロールを定義します。また、商品の情報を検索するためのコントロールとして、「商品検索」コントロールを定義します。また、ポイントカードにポイントを計上し、ポイントを消費して販売をする必要があるため、既存の「ポイント会員カード管理」コントロールも再利用します。
次に、ユースケースの基本フローや代替フローに従って、コラボレーション図を作成します。
UC004 の基本フロー
- チェッカーは、バーコードリーダーでポイント会員カード、または商品をスキャンする。
- システムは、ディスプレイに商品と販売情報を表示する。
- 1から2を繰り返す。
UC004は、商品かポイント会員カードをバーコードリーダーでスキャンするところから始まります。
商品をスキャンした場合、システムは何を行わなければならないのでしょうか？まず、商品コードから適切な「商品」エンティティを検索しなければなりません。また、「商品」エンティティの情報から販売の明細にあたる情報や、販売合計金額を求めなければなりません。
この流れを定義したコラボレーション図が図 22 です。それぞれのクラスに新しい操作が定義されています。
UC004のような複雑なユースケースのコラボレーション図を作成すると、「商品販売」コントロールが「商品検索」コントロールの操作を呼ぶというように、コントロールが別のコントロールの操作を呼び出すこともあります。
ポイント会員カードをスキャンした場合、システムは何を行わなければならないのでしょうか？まず、ポイント会員カード番号から適切な「ポイント会員カード」エンティティを検索しなければなりません。また、「販売」エンティティにどのポイント会員カードが使われるのか記録しなければなりません。この流れを定義したコラボレーション図が図23です。ポイントカードに関係する操作はUC002のロバストネス分析で定義したものを再利用しています。
UC004 の基本フロー
- チェッカーは、預かり金額を入力し、現金計算の指示をする。
- システムは、レシートを出力する。
すべての商品、ポイント会員カードをスキャンし終わると、現金計算を行い、販売結果画面を表示し、販売レシートを印刷します。そのために、必要な操作を定義し、コラボレーション図を作成します。
基本フローのコラボレーション図が作成できたら、同じように代替フローのコラボレーション図を作成します。
UC004の代替フロー1 (基本フローの4でポイント会員カードを使って買い物をする場合）
4a. チェッカーは、ポイント精算の指示をする。(基本フローの5に戻る）
ポイント精算を行う代替フローでは、システムはポイントカードを消費して、販売の現金計算を行わなければなりません。そのために、必要な操作を定義し、コラボレーション図を作成します。
エンティティの構造を見直す
UC004 のユースケースの実現では、「販売」エンティティ、「商品」エンティティ、「ポイント会員カード」エンティティという 3 つのエンティティが登場します。概念モデルやこれまでのロバストネス分析の結果から必要な属性を検討しクラス図としてまとめると、以下のようになります。
しかし、このエンティティの構造や属性では、UC004のユースケースを実現することはできません。UI仕様には、販売画面に販売する商品の個数情報が表示されていますが、エンティティのクラス図はこれについて未検討だからです。
このような場合には、エンティティの構造や属性を見直します。今回のクラス図には、UI仕様にあるような販売の明細にあたるクラスがありません。そのため、「販売明細」クラスを追加して、商品の個数情報を持つ属性を追加する必要があります。
ユースケースの振る舞いを見直す
これで、すべてのユースケースのロバストネス分析が完了しました。しかし、ロバストネス分析でビジネスルールを定義していく過程で、ユースケースの振る舞いの問題を発見したり、改善案を見つけたりすることがあります。
例えば、UC004 ではポイント精算をするための代替フローを定義していましたが、販売に必要なポイントが貯まっていない場合に、どのようにソフトウェアが振る舞えばよいか考慮されていませんでした。そのため、ユースケースの代替フローを見直さなければなりません。見直し案の例としては、以下の２つが考えられます。
- ポイントが不足している場合には、現金のみでの購入しかできないようにする。
- ポイントが不足している場合には、追加の現金を払うことによって商品の販売をできるようにする。
前者の案を採用した場合には、次のような変更が必要になるでしょう。
- ポイント精算でポイントが不足している場合の代替フローを追加する。
- 商品販売画面にポイント不足のメッセージを表示できるように、UI仕様を見直す。
- ポイントが不足している場合の代替フローのコラボレーション図を作成する。
変更後のUC004の代替フロー2 (代替フローの4aでポイントが不足している場合)
4a. システムは、ディスプレイにポイントが足りないことを表示する。（基本フローの4に戻る）
まとめ
今回のモデリングはこれで終わりです。今回の記事で、実際のロバストネス分析では様々なことを考慮してモデリングすることが分かったかと思います。以下に、ロバストネス分析で行うことをまとめます。
- バウンダリ、コントロール、エンティティの識別
- バウンダリ、コントロール、エンティティの操作の定義
- コントロール、エンティティのビジネスルールの定義
- エンティティの属性の定義
- バウンダリ、コントロール、エンティティのコラボレーション図の作成
- エンティティの構造の見直し
- 包含するするユースケースの発見
- ユースケースのイベントフローの見直し
- UI仕様の見直し
次回に向けて
どうでしょうか。自分もロバストネス分析を行えるかもと思っていただけでしょうか。せっかくですので、以下の問題について考えて、自らロバストネス分析をしてみてはいかがでしょうか。
- UC004 のロバストネス分析で、ユースケースの振る舞いを見直しました。
もし、見直し案 2 ではなく見直し案 1 （ポイントが不足している場合には、現金のみでの購入しかできないようにする）を採用した場合を想定して、ユースケースのイベントフロー、UI仕様、コラボレーション図を作成し直してください。 - UC005「ポイントを現金で返金する」がユースケースとして追加された場合を想定して、ユースケースのイベントフロー、UI仕様、コラボレーション図を作成してみてください。
次回の記事では、今回説明しきれなかった以下のような実践的なテクニックを紹介します。
- コントロールの粒度
- 外部システムやデバイスなどの特別なバウンダリの扱い
- ロバストネス分析から設計へのマッピング
参考文献
- [1] 『ユースケース入門－ユーザーマニュアルからプログラムを作る』 Doug Rosenberg・Kendall Scott／著, 長瀬嘉秀・今野睦／監訳, ピアソン・エデュケーション
- [2] 『ラショナル統一プロセスによるJ2EEアプリケーション構築』 Peter Eeles・Kelli Houston・Wojtek Kozaczynski／著, 堀井 未来／訳, 新紀元社
改訂履歴
・サイトテンプレート変更に伴う変更（2018年3月）