ユースケース図の通知
アクターが通知を受け取るユースケース図を書いています。私の質問は this one に似ていますが、通知のユースケースが横断的な問題であるかどうかがわかりません。
私のシステムが卵のタイマーだとしましょう。俳優は料理人です。料理人は、卵タイマーがオフになるまでの間隔を設定できます。料理人はまた、卵のタイマーを聞きたがっています。
これは適切な図ですか？クックは「通知される」アクションを実行しません。ただし、「Set Alarm Time」のユースケースのみを残した場合、卵タイマーが実際に料理人に通知する必要があることは指定されていません。
「Be Notified」ユースケースを別のタイプの図に入れる必要がありますか？クックがシステムであり、エッグタイマーがアクターである別のユースケース図を作成する必要がありますか？
「通知される」というのは、ユースケース図にもあるようなものではないと思います。各ユースケースは、一連のステップまたはアクションです。ユースケース図に表示されるのは、完全なユースケースの概要です。これは、ステップ、前提条件と事後条件、最小保証、トリガー、または通常関連付けられているその他の情報のすべてをキャプチャするわけではないためです。ユースケース。
あなたの特定のユースケースでは、「アラーム時間の設定」、「タイマーの開始」、「タイマーの停止」など、私が期待するユースケースの種類があります。通知は、「タイマーを開始する」ユースケースの1つの結果になります。これはシステムが出力として行うことであり、誰かがシステムを使用して達成することではありません。
ユースケースに関するウィキペディアの記事 および ユースケース図 および ユースケース のScott Amblerのアジャイルモデリングページを読むことをお勧めします。
余談ですが、 ML Distilled では、Martin Fowlerはユースケース図に大きな重みを与えず、ユースケースはテキスト形式または表形式でキャプチャするのが最適であると主張しています。ユースケーステーブルで詳細を取得できるため、私はこれに同意する傾向があります。ただし、図は、ユースケースとそれらの相互関係およびアクターとの関係のクイックインデックスを提供する場合があります。