uml - ユースケース図はどのレベルの複雑さを示す必要がありますか?

Question

ユースケース図はどのレベルの複雑さを示す必要がありますか?どの程度の詳細を含める必要がありますか?また、シーケンス図または別の UML 図を使用する必要がある場合の「カットオフ」ポイントはどこですか?

Answer 1

UML 仕様では、UML 図に何を表示するかについて非常に多くの自由が認められていますが、以下は UC 図に含める必要があります。

• アクター
• ユースケース
• 検討中のシステム (SUC) を象徴する境界の可能性。

これは「メイン」の UC ダイアグラム用ですが、設計の要件やクラスなどを含む他のダイアグラムを作成する可能性があります。

現在、アクターはすべて、最初に SUC と対話するオブジェクトです。ユースケースはすべて、SUC がアクターに提供する個々の付加価値 (技術的な手順ではありません!!) を意味するバブルです。

ユースケース図はシステムの付加価値に関するものであり、技術的な機能に関するものではありません!

Answer 2

もちろん、簡単に言えば、(複雑さではなく) どんなレベルの詳細が必要かということです。より思慮深いのは、アナリストがユースケースを使用して、非技術的な利害関係者に、ユースベースの要件がすべて満たされていることを示すことです。そのためには、マネージャー、顧客、およびマーケティング担当者が、開発者が希望する製品を開発するという確信を持てるように、十分な詳細が必要です。開発者の意思決定をキャプチャするユースケース図には、より深い設計やプログラミングを続行できるように十分な詳細が必要です。両方のタイプのユーザー (利害関係者と開発者) のニーズに対応しようとする図を作成しないことをお勧めします。最後に、これは描画とレビューの反復プロセスです。シンプルに始めて、必要に応じて詳細を追加します。

Answer 3

ユースケース

UML はユース ケースを定義します。

ユースケースは、システムの要件、つまりシステムが何をすべきかを把握する手段です。(...) ユースケースは動作の仕様です。ユース ケースのインスタンスは、緊急の動作 (...) の発生を参照します。このようなインスタンスは、多くの場合、相互作用によって記述されます。

言い換えれば、それはシステムが外界との相互作用で何をするべきかについての外部ビューです。

詳細レベルはかなり高くする必要があります。通常、ユーザーとシステムとの対話の最上位レベルであり、ユーザーが目標を達成するために呼び出す主な機能です。通常の ATM の例を使用すると、主な目標は「現金を引き出す」、「口座残高を確認する」であり、「カードを挿入する」、「ピンを入力する」、「メニューでアクションを選択する」、「お金を受け取る」ではありません。

しかし、規範はありません。非常に詳細な図を用意することもできます。描くのが面倒なだけで、必ずしも要件の理解に役立つとは限りません。これが、コックバーンのアプローチ などを使用して、高レベルのユースケース (「海面」) を物語としてさらに詳しく説明することが認められている理由です。

シーケンス図で切り捨てる

UML は、シーケンス図を次のように定義します。

シーケンス図は、交換される一連のメッセージに焦点を当てて相互作用を記述します (..) シーケンス図で記述される相互作用は、相互作用パッケージのメタ クラスのセマンティクスを理解するための基礎を形成します。

ここでは、システムの内部と交換されるメッセージに焦点を当てます。ただし、UML はユース ケースを特殊なクラス図と見なします。これを念頭に置いて、非常に詳細なユース ケース図がある場合、シーケンス図はアクターとユース ケース間の相互作用を記述する必要があります。