系统或外部系统作为用例中的参与者？

Question

让我们想象一个新的简单 CRM，其中...

• 某个外部系统A上传新数据，CRM保存它们
• CRM 验证数据并创建例如。他们的新案例
• 用户展示案例

这些要求涉及到系统和外部系统，我对这些是否符合演员资格有一些疑问：

第一个可能的用例图：

第二个可能的用例图：

我关于系统和参与者之间边界的问题可以分解如下：

1. 我相信，第一个图是错误的，因为系统不应该是一个演员。它应该看起来像第二张图。正确吗？

2. 用例“验证数据”和“创建新用例”将仅在场景中包含系统执行的步骤（系统验证列数；系统验证数据类型；系统验证强制值...）。 系统不应该是一个“参与者实体”，但是拥有一个系统是唯一起作用的部分的 uc 并不违反规则，对吗？重要的是，UC 与另一个 UC 存在关系，这对于某些演员来说非常有价值。正确吗？

3. 以演员身份展现“外系A”是否正确？执行用例应该给参与者带来价值...我不确定系统A是否乐意上传数据:)但是系统可能对什么是“价值”有不同的观点

谢谢您的建议！

Answer 1

所考虑的系统从来都不是一个演员。永远不能。参与者始终处于系统外部。

Actor 也可以是其他系统。然后，期望它们独立于所考虑的系统，并在这方面拥有一定的自主权。如果系统帮助其他系统实现其目标，则该外部系统参与者可以是主要参与者，或者（更常见）为系统用例做出贡献的辅助参与者。两个典型例子：

• 系统的数据库不符合参与者的资格。尽管数据库可以运行在另一台服务器上并且可以独立购买，但它只是系统的一个组件。如果没有该数据库，系统将无法使用。所以它实际上是一个内部细节，并且内部细节不应在 UC 图中泄漏。
• 外部天气预报系统可以作为运输管理系统的参与者。外部天气服务完全独立于系统运行。无论您的系统是否存在，它都存在。您的系统可能需要其他系统的贡献，但假设它也可能依赖于人类参与者每小时输入预测。

直接得出的结论是，第一个图是不正确的，但第二个图可能提供不相关的细节而不是真实的用例。更具体地说：

1. 正确：没有系统参与者

2. 或多或少是正确的：但是一个对任何人都没有用、也没有人关心的系统功能，不会提供参与者或利益相关者重视的可观察结果。因此它不符合用例。也许这是一个更大的内部细节的一部分。不要“上传数据”，而是从用户的目标角度考虑它（例如“获取有关......的信息”

3. 这要看情况。关键问题是：“它是否独立自主？” （如果它是为系统提供数据而编写的上传脚本，那么它并不是真正独立的），以及“用户关心吗？” （见上文）。