Uml 需要在我的用例图中包括审计跟踪和错误日志记录

我们的应用程序支持团队建议实施审计跟踪、广泛的错误日志记录和新的批处理作业，以便在内部处理一些数据。在实现这一点之前，我希望在用例图中进行更改。我认为审计跟踪必须是一个用例，但不能确定错误日志。应将其视为一个用例。这个链接表示用例有时可能没有参与者。我们可以考虑错误日志作为一个没有演员的用例吗？ 我能把批作业看作一个批量调度程序作为一个演员的用例吗？< /P>

---

我需要的另一个澄清是：我知道参与者可以是个人或其他系统。我们可以考虑一个事件（通过用例与一个解决方案交互）作为一个演员吗？

< p>用例>强>必须/<强>有一个演员，因为它基本上只是描述了它的演员的附加值。引用文章的作者在这里完全错了

UML2.5规范第637页：

每个用例都指定了主题可以与一个或多个参与者协作执行的一些行为

用例的主题可以是系统或任何其他可能具有行为的元素，例如组件或类。每个用例都指定了主题向其用户提供的有用功能单元

注：尽管UML是“真正的来源”，但它不是一本关于用例的好读物。相反，我强烈推荐Bittner/Spence

有几种方法可以处理

日志错误

“用例”。一种方法是

使用带有

日志错误的用例。但实际上，这有几个缺点<代码>日志错误

从长远来看可能会带来额外的价值（系统改进和错误纠正），但它不是先验的附加价值。同样，您也会把用例图弄得乱七八糟

第二种方法是改变视角，将“系统”本身作为参与者纳入其中。但这是一种反模式。所以也不推荐

最后，您可以简单地向您的系统添加一个非功能性需求，并跟踪相关的用例。这是我的建议

你的补充问题：

• 批处理作业不是用例，但用例可以实现为批处理作业，调度器可以是参与者
• 不，事件是事件而不是参与者。事件可以触发作为用例一部分的一系列动作