やあみんな！私はUMLを研究しており、問題のユースケース図を設計しようとしています。
私のアプリがこれで構成されているとしましょう：
2 つの要件: - チームの作成 - プレーヤーの作成
これは取り引きです: ユーザーはチームを作成でき、チームを作成した後、そのチームのプレーヤーを作成できます (必須ではありません)。しかし、このアプリには複数のユーザーがいて、ユーザーはチームを作成し、他のユーザーはプレーヤーを作成できます。唯一の制約は、プレイヤーを作成するには、すでにチームに存在している必要があるということです。私は研究し、少し混乱してしまいます。ユースケース図で関係の概念を正しく理解できれば、次の 2 つのユースケースが必要だと思います。
[ユースケース - チームの作成] <-------extends---- [ユースケース - プレーヤーの作成]
私は意見が必要です,これは適切な解決策ですか? または、関連しない2つのユースケースが必要ですか?
よろしくお願いします。私の英語で申し訳ありません。
通常、ユースケース図で「B を実行する前に A を実行する必要がある」などの依存関係をモデル化する必要はありません。ユース ケースは、一連のシナリオを表し、それらを共通のケースとしてグループ化する必要があります。
「extends」依存関係は、拡張されたユース ケースよりも特別なユース ケースを指定するために使用されます。したがって、プレイヤーの作成がチーム作成の特別な形式であることを「拡張」を使用して表現したい場合は問題ありません。しかし、これは上記の状況と一致しません。
プレイを作成することは常にチームを作成することも意味することを表現したい場合は、「include」依存関係を使用できます。これはあなたのケースに一致する可能性がありますが、imoは完全には一致しません。
最後のオプションは、未指定の依存関係 (<< >> マーカーなし) を描画して、ユース ケースが互いに何か関係があることを表現することです。
私の推奨事項: この場合、依存関係を使用しないでください。
もっと良い説明がここにあります。
ユースケースには、リレーションという共通の問題があります。私たちは、一連のユースケースを説明するためにリレーションを使用する傾向があります。しかし、これは誤解です。The UML User Guide のUse Cases and Flow of Events (パート 4、第 17 章)からのいくつかの単語を次に示します。
You can specify a use cases's flow of events in a number of ways
[...] informal structured text
[...] formal structured text
[...] states machines
[...] activity diagrams
要点は、イベントの流れを指定するためにリレーションシップを使用すべきではないとガイドが (暗黙のうちに) 言いがちな場合、それはユース ケースのリレーションを何に使用すべきかを述べていないということです。UMLやUPでユースケースが重要なポイントでありながら、非常に扱いにくいツールである理由はここにあると思います。
モデルでは、おそらく矢印と用語を変更する必要があります (単純な提案、あなたはアナリストです)。
制約を強調したい場合は、これをダイアグラムに表示する必要がありますが、一連の操作の表現としてではありません (微妙な区別)。
extends用語は通常、一般化/専門化に関連しています。私の意見では、これはチームとユーザー作成の間にあるような関係ではありません。ガイドが示す例は次のとおりです (パート 4、第 18 章)。
とはいえ、ユースケースの専門化をモデル化することは、ほとんどの場合、限られた関心しかありません。しかし、ユースケースの説明によっては、これが必要な場合もあります。両方が等しい場合は必要ありません。熟練したプログラマーは、特殊化が同等のアサーションを意味しないことを知っています。