uml - アクターとしての「時間」の使用例

Question

(明示的なユーザー操作の直接の結果として実行されるのではなく) スケジュールに基づいて定期的に実行されるシステム動作をモデル化するためにユース ケースを使用するためのベスト プラクティスは何ですか?

「時間」がアクターとしてモデル化されている場合、ユースケースをトリガーするために時間がどのように使用されるかを説明するために受け入れられているアプローチは何ですか?

Answer 1

特定のタスクをスケジュールする原因となったアクターは、タスクが実際に開始された時点でもアクターであると見なしたほうがよい場合があります。

1. ストック担当者がピッキングされた部品のリストを提出
2. システムはピッキングされた部品のリストを処理して在庫を更新します

後者が一晩で発生することを示すメモを追加します。

これを書いている今、ユースケースでは時間が問題になるとは思いません。このレベルで重要なのは、何が起き、どのアクターが関与しているかです。この段階では、いつどのように発生するかよりも重要ではありません。

Answer 2

スケジューリングはシステムの一部ですか、それとも外部ですか?

スケジュールが外部の場合は、俳優として扱います。それでは時間が見えません。

スケジューリングがシステムの責任である場合、時間を「ベルを鳴らす」アクター、つまり入力を提供するアクターと考えると役立つと思います。時間の責任を列挙することは、スケジュールの設計に役立ちます。ただし、実際にスケジュールを設定する他の俳優もいます。スケジュールとは別の時間。

Answer 3

時間は決して主要なアクターではありません。結局のところ、ユース ケースがインスタンス化されると、時間はシステムから価値のあるものを受け取りませんか?

実装の決定と、実装の決定が選択されたというビジネス要件を混同していると思います。

定期的に行われていることとその理由の概要を説明していただければ、詳しく説明できます。