トピック

はじめに ページの先頭へ

グループ作業としてユース・ケース分析を実行することは、チーム確立作業の早期の反復において重要であり、システム・アーキテクチャーの共通の開発構想を確立するものです。これは (ユース・ケースで示す) ユーザーのシステム・ビューと (この時点では分析クラスで示す) システム設計者のシステム・ビューを結び付けるものであり、反復における重要な移行ポイントとなります。

後の反復や、実務経験のあるチームでは、ユース・ケース分析は必要に応じて個々に実行されます。既存の設計モデルが十分なものであれば、その設計の既存のクラスを、新規ユース・ケースで必要なシステムの振る舞いに適用できるため、新たにオブジェクトを開発する必要はなくなります。

必要な能力 ページの先頭へ

検討会議はブレーンストーミング・セッションとして構成されます。ここでは、次に示すような、さまざまな領域に関する幅広い能力が必要となります。

  • 要求
  • 分析/設計
  • アーキテクチャー
  • テスト
  • 領域に関する問題
  • 一般的な方法論に関する問題

検討会議の人数は少なめにしてください。6 ~ 7 人以上になると、すべてのメンバーが自由に参加できなくなります。

必要な設備 ページの先頭へ

  • 大きめのホワイトボード
  • A3 または法律文書サイズの用紙 (コピー機で扱える最大の用紙サイズに依存します)
  • テープ
  • 付せん紙 (できれば数色)
  • ホワイトボード用のペン (赤、緑、青)
  • 鉛筆 (赤、緑、青)
  • 用紙を貼り付けるための壁

必要な時間 ページの先頭へ

ユース・ケースごとに、平均して最低 2 ~ 3 時間を予定します。最初は時間がかかりますが、新しいクラスの数が減ってきて、グループのメンバーが経験を積んでいくうちに、次第に時間を短縮できます。

役割 ページの先頭へ

検討会議では、次の役割が必要になります。役割を順に交代し、全員がすべてを担当することを推奨します。

  • リーダー: 検討会議を進行し、コミュニケーション図をホワイトボードに描きます。通常は最初にメソッドのコンサルタントが担当し、後でチーム・メンバーと交代して、全員が経験するようにします。
  • クラスの「所有者」: 割り当てられた 1 組のクラスに関する情報を記録します。一連のクラスごとに記録するため、これは数人で担当します。
  • 秘書: ホワイトボードに示したコミュニケーション図を、ホワイトボードにあるとおりの色で記録します。

検討会議の実行 ページの先頭へ

チームは、ユース・ケースのイベント・フローに沿って検討を進めます。ユース・ケースで判明したそれぞれの振る舞いについて、その振る舞いを促すオブジェクトが識別されます。オブジェクトは既存クラスのインスタンスの場合もありますが、クラスを作成しなければならない場合もあります。

リーダーがホワイトボードにコミュニケーション図を描き、全員が検討に参加します。

ユース・ケースを図示したら、A3 または法律文書サイズの用紙にホワイトボードのダイアグラムと同じ色で記録します。

同時に、オブジェクトの責務も A3 または法律文書サイズの用紙に示します。形式については、『成果物: 分析クラス』の『カスタマイズ』の項を参照してください。責務、イベント、関連するクラスを付せん紙に記録し、責務を簡単に移動できるようにします。

コミュニケーション図の図示

次の規則で、ダイアグラムを読みやすくし、検討会議で使用できるようにします。

  • すべてのクラスとリンクを描き、オブジェクト名を青色で書く。
  • メッセージ・テキストとリンクに送られる情報の種類を付せん紙に緑色で書く。オブジェクト間のメッセージが読みやすく、簡単に移動できるようになり、オブジェクトの責務のバランスを取ることができます。
  • メッセージの番号 (イベント・フローの順序) を別の付せん紙に赤で書く。検討会議中にオブジェクトの責務のバランスを取り直した場合に、イベントの順序を調整することができます。

ユース・ケースの基本フローのダイアグラムを描き、代替フローのダイアグラムも追加します。ユース・ケースが単純な場合、ダイアグラムは 1 つでも十分です。

コミュニケーション図の例

「現金自動預け払い機」における、「ユーザー認証」ユース・ケースのコミュニケーション図の例



Rational Unified Process   2003.06.15