uml - 私が作成したUMLユースケース図。include/extend の使い方は正しいですか?

Question

拡張とインクルードを正しく使用しているかどうかを判断したいだけです。ここのどこかでどちらかを間違って使用している場合は、どこが間違っているのか、可能であれば理由を示してください。

https://imageshack.com/scaled/large/163/nlnk.jpg

乾杯。

Answer 1

<<include>>とを使用するためのルール<<extend>>は簡単です。

• <<include>>一般的なユースケースに常に含まれるサブユースケースを定義します: use-case -include--> sub use-case。通常、ユースケースの個別の部分、または他のユースケースで再利用できる共通部分を示すために使用されます。

• <<extend>>特定の条件で実行できるオプションのサブ ユース ケースを定義します (ユース ケース図ではなく、下位レベルの設計で定義する必要があります)。ここで、リレーションの方向はリレーションの反対<<include>>です: use-case <--extend- sub use-case。

これらのルールを図に適用し、それが正しいかどうかを判断してください。

Answer 2

ここでは、多くの関係が明らかに正しくありません。ただし、この図の主な問題は、include と extend の正しい使用ではなく、複雑で全体的に不明確な関係にあると思います。状況的に有効ですが、これらの関係の複数のレベルを使用することは避ける必要があります。

あなたの図は、たどって解釈するのが本当に難しいです。

いくつかのリファクタリングのアイデアと修正:

• 「安全なログイン」クラスを個別に表示し、アクターのみにリンクし、それを「含む」すべてのユースケースに次の前提条件を適用します:「ユーザーは安全にログインしています」
• 「5 分後にログアウト」は、「ユーザーが安全にログインしている」と「ユーザーが 5 分間非アクティブだった」という 2 つの前提条件を使用して、アクターにのみ接続する独自のユース ケースである必要があります。
• 「5 分後にログアウト」と「通話を開始」の間のインクルードを削除します。拡張する方が適切かもしれません
• 「資金を送金...」と「適切な資金を保証する...」の間のインクルードの方向を逆にします-最初のものが2番目のものを含み、その逆ではないことは明らかです
• 関連する UC のみの 2 つ以上の単純で小さな図に図を分割することを検討してください。たとえば、すべてのログイン/ログアウトを別々に表示して、ビューを簡素化できます。1 つの図に 5 ～ 7 個を超えるユース ケースを含めないでください。

Answer 3

リンクする他のアクティビティの前に、「安全なログイン」を実行する必要があるようです<<include>>。インクルードは、ユースケースが含まれているユースケースを毎回実行することを意味しますが、これはおそらく意図したものではありません (セッションごとに 1 回のログインのみ)。などの新しいステレオタイプをいつでも作成できます<<precedes>> or <<requires>>。それらを一貫して使用すると、意味を伝えることができます。