UMLユースケース図の関係-必須/オプションかつ独立
UML仕様を使用してユースケース図を作成する方法を学んでいますが、自分では解決できないユースケースの関係についていくつか疑問があります。
私の質問は、2つの異なる状況に関するものです。
- 特定のユースケースの完了は、別のユースケースを実行するための前提条件です。一部の記事で「先行」コネクタが推奨されていることを確認しましたが、UMLで類似するものが見つかりません（「先行」と「呼び出し」の関係は OML仕様 で定義する必要があります）。 ML 2.5仕様 の "include"関係は、一部のシナリオでは適切と思われますが、すべてではありません。
- ユースケースの実行中に別の（つまり、オプションの）フローがあり、独立して意味のある別のユースケースとして識別することもできます。 「除外」関係の説明を読んで、「拡張UseCaseは通常、必ずしもそれ自体では意味がない動作を定義する」ことを理解しています。また、 一部の記事 は、「拡張ユースケースは拡張（ベース）ユースケースに依存している」（つまり、それ自体ではあまり意味がない）と述べています。そのような状況で「拡張」が適切な関係であるかどうかはわかりません。
同じ図を設計しているときに両方の状況に直面したので、完全性と理解を深めるためにここで報告します（図にすべてのシステムユースケースを含めていません）。
- ユーザーは予約を再スケジュールする前にシステムにログインしている必要があります（ 一部の記事 これは「含める」関係であることが推奨されます）。ユーザーは予約を表示して、予約を「トリガー」する必要があります-schedulingユースケース（これは「先行」により近い）。
- 再スケジュール中に適切な選択肢がない場合、ユーザーは現在の予約を（再スケジュールする代わりに）削除できるはずです。
ユースケースは、それらの間の順序付けを意図したものではありません。
ユースケースは、アクターにとって価値のあるシステムとの相互作用を表すことを目的としています（つまり、ユースケースはアクターの目標に対応しています）。 UCは、発生するアクションとその所有の詳細な仕様には決して触れていません。これは、そのような仕様の単なるプレースホルダーです。
includeとextendの関係を除き、使用例は原則として互いに独立しています。これらの関係は、共通の動作/サブゴール/相互作用の再利用を促進することを目的としています。
動作を順序付けする場合は、UMLアクティビティ図またはBPMN図を検討する必要があります。