作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
役割: システム分析者 | |
ツール メンター: |
ワークフローの詳細: |
ユース ケース モデルを作成するための最初のステップは、1 つ以上のユース ケースに共通する要求を理解することです。各ユース ケースをレビューし、あらゆる共通性をメモします。
これらのメモを後のステップ (包含ユース ケース、拡張ユース ケース、汎化ユース ケースの作成) で使用して、冗長性を最小限に抑えます。目標は、要求を理解し、維持しやすくすることであり、設計に持ち越される機能分解を定義することではありません。
共通の要求は、常に新しいユース ケースを作成することによって最適に処理されるとは限りません。必要に応じて、共通の内容を、ユース ケースから、用語集、補足仕様書、参照などのその他の要求成果物に移動することを検討します。
また、補足仕様書の内容が特定のユース ケースに関連する場合は、その内容をユース ケース内に移動することも検討します。
ユース ケースが、結果を得るための方法ではなく、その結果のみがほかのユース ケースにとって重要な振る舞いのセグメントを含んでいる場合は、この振る舞いを新しい包含ユース ケースに分離できます。そのとき元のユース ケースは、包含ユース ケースと包含関係を持つ基底ユース ケースになります。「ガイドライン: ユース ケース モデル」と「ガイドライン: 包含関係」も参照してください。
2 つのユース ケース間の包含関係は、基底ユース ケースの説明の後のユース ケース インスタンスが完全になるためには、包含ユース ケースの説明の後に来る必要もあるということを意味します。
包含関係は次のように、ユース ケースの識別に役立ちます。
一般に、複数のユース ケースが包含ユース ケースを含んでいなければ、余分なユース ケースと包含関係を維持する価値はありません。
基底ユース ケースのみが、2 つのユース ケース間の関係を知っています。包含ユース ケースは、ほかのどのユース ケースに自身が含まれているかを知りません。
基底ユース ケース内で包含が挿入される場所と併せて、包含の大まかな目的を記述することによって、包含関係を説明します。
基底ユース ケースのイベント フローを説明するときに、包含が挿入される場所で、その包含について言及する必要があります。
ユース ケースにオプションまたは例外的な振る舞いの性質のセグメントがあり、ユース ケースの主要目的の理解に貢献しない場合は、それらを新しい拡張ユース ケースに分離します。そのとき、元のユース ケースは、拡張ユース ケースと拡張関係を持つ基底ユース ケースになります。「ガイドライン: ユース ケース モデル」と「ガイドライン: 拡張関係」も参照してください。
拡張が行われる可能性がある、基底ユース ケース内の場所を定義する拡張点を、基底ユース ケース内で宣言します。「ガイドライン: ユース ケース」も参照してください。
複雑なサブフローとオプションの振る舞いは、拡張ユース ケースに分離される最初の候補です。しばしば、この振る舞いはかなり複雑で、説明しにくい場合があります。したがって、ユース ケースのイベント フローにこの振る舞いを含めると、「正常な」振る舞いが見えにくくなる可能性があります。この振る舞いを抽出すると、ユース ケース モデルが分かりやすくなります。
基底ユース ケースのイベント フローが、拡張ユース ケースへの参照がなくても、それ自体で完全でわかりやすいことを確認します。
拡張ユース ケースのみが、2 つのユース ケース間の関係を知っています。基底ユース ケースは、拡張点があることのみを知っていて、どの拡張ユース ケースが拡張点を使用しているかは知りません。
定義する各拡張関係の概略を説明します。拡張が発生するために満たされなければならない条件を定義します。拡張を挿入する基底ユース ケース内の拡張点を必ず定義します。
2 つ以上のユース ケースが構造と振る舞いの点で類似している場合は、共通の振る舞いを分離して、新しい親ユース ケースを作成できます。そのとき、元のユース ケースは、親と汎化関係を持つ、子ユース ケースになります。子ユース ケースは、親ユース ケースで説明されるすべての振る舞いを継承します。「ガイドライン: ユース ケース モデル」と「ガイドライン: ユース ケースの汎化」も参照してください。
2 つのユース ケース間の汎化関係が意味することは、ユース ケース インスタンスが子ユース ケースの説明の後に来る場合は、それが完全と見なされるためには、親ユース ケースの説明の後に来る必要もあるということです。
一般に、同じ親から継承される子ユース ケースが最低 2 つ存在しなければ、親ユース ケースと子との汎化関係を維持する価値はありません。例外は、2 つのユース ケースがあって、その 1 つがもう 1 つを特殊化したものであるが、両方とも独立してインスタンス化可能でなければならない場合です。
子ユース ケースのみが、2 つのユース ケース間の関係を知っています。親ユース ケースは、どの子ユース ケースがそれを特殊化しているかを知りません。
ほかの人にとってモデルが理解しやすくなるように、汎化関係は簡単に説明する必要があります。なぜ汎化関係を作成したかを説明します。
子ユース ケースのイベント フローで、振る舞いの新しいセグメントを挿入することによって、子が継承した振る舞いのシーケンスをどのように変更するかを説明する必要があります。
アクターは共通の特性を持っているので、アクター汎化を使用してモデリングする必要があります。この部分の作業は、ユース ケース モデルで試した後に行うと、最もうまくいきます。
アクター汎化の概要を記述し、さらに明確化するためにユース ケース図に含めます。
「ガイドライン: アクター汎化」も参照してください。
包含関係、拡張関係、汎化関係の組み込みについて、継続的に顧客やユーザーと話し合って、これらの人々が最終的なユース ケースやアクターを明確に理解しているかと、その説明に同意するかを確認する必要があります。
この段階でユース ケース モデルを調べて、作業が予定どおりに進んでいるかどうかを確認しますが、モデルを詳細にレビューすることは避けます。新しく組み込まれたユース ケースと関係について、顧客やユーザーと一緒にレビュー、検討して、これらの人々がユース ケースを明確に理解し、その説明に同意するようにする必要があります。
必要であれば、ユース ケースをユース ケース パッケージの中に組み込むこともできます。このオプションを検討する時期について詳しくは、「ガイドライン: ユース ケース パッケージ」を参照してください。
また、ユース ケース モデルの作業を行っている間、ユース ケース モデルのチェックポイントを考慮に入れる必要もあります。「作業: 要求のレビュー」の、特にアクター、ユース ケース、ユース ケース モデルのチェックポイントを参照してください。
Rational Unified Process
|