ユースケース図に監査証跡とエラーログを含める必要があります

Question

私たちのアプリケーションサポートチームは、監査証跡、広範なエラーログ、および内部的にいくつかのデータを処理する新しいバッチジョブを実装することを提案しています。これを実装する前に、ユースケース図に変更を加えたいと思います。私は、監査証跡はユースケースでなければならないと思いますが、エラーのロギングについてはわかりません。ユースケースと考えるべきか？このリンクhttp://www.umlchannel.com/en/uml/item/24-use-case-actor-system-timerは、ユースケースには時には俳優がいない可能性があると言っています。アクターなしのユースケースとしてエラーロギングを検討できますか？ バッチジョブをバケツスケジューラをアクタとして使用するユースケースと考えることはできますか？

私が必要とするもう一つの明確化は次のとおりです。私は俳優が人または別のシステムになる可能性があることを知っています。アクターとしてイベント（ユースケースを通じてソリューションとやりとりするイベント）を考えることができますか？

Answer 1

ユースケースにはアクタが必要です。基本的にはアクタの追加値を記述するだけであるためです。参照された記事の著者はここでは間違っています。 UML 2.5仕様の

P. 637：

各ユースケースは、被験体は、1つ以上のアクタと共同で実行できるいくつかの動作を指定します。

...

ユースケースの主題は、そのようなコンポーネントまたはクラスとして挙動を有することができるシステム、または任意の他の要素であってもよいです。それぞれのユースケースは、そのサブジェクトがユーザーに提供する有用な機能の単位を指定します。

N.B .: UMLは「真のソース」ですが、ユースケースについてはあまり読めません。代わりに私はBittner/Spenceを強く勧めます。

Log error「ユースケース」にアプローチする方法はいくつかあります。 1つはLog errorの<extend>ユースケースです。しかし、実際には、これにはいくつかの欠点があります。 Log errorは、長期的には付加価値をもたらすかもしれない（システムの改善とバグ修正）が、先験的な付加価値ではない。また、ユースケース図を乱雑にするだけです。

第2の方法は、パースペクティブを変更して、「システム」自体をアクターとして含めることです。しかし、これは反パターンです。だからお勧めしません。

最後に、システムに非機能要件を追加するだけで、関連するユースケースをトレースすることができます。これは私がすることをお勧めするものです。

あなたの追加質問：

• バッチジョブには、ユースケースではありませんが、ユースケースは、バッチジョブとして実装することができ、スケジューラが俳優になることができます。
• いいえ、イベントはイベントであり、アクタではありません。イベントは、ユースケースの一部である一連のアクションをトリガーできます。