用例导致其他用例

Question

我正在制作这个独立的无人机控制系统，用户可以启动和停止。当程序启动时，连接的无人机起飞，悬停，转向另一边。首先，我想到了这样的用例图：

这方面的问题是，似乎开发人员可以执行“起飞”等，即使这只是由系统完成。至少，这就是我从大多数示例用例图中解释它的方式。在另一个问题中，包含的用例也是由系统单独完成的，但被认为不适合于用例图。因此，

• 是否删除包含的用例？
• 如果我删除这些用例，我还会在“开始”和“停止”的主流程中描述它们吗？

例如，"Start“用例的主要流程：

开发人员启动程序。无人机起飞了。无人机在空中盘旋。那架无人驾驶飞机向相反的方向飞去。

• 我是否保留了它们，但添加了一个连接到所包含的用例的"FlightController“参与者？

谢谢

Answer 1

您的用例看起来是正确的，

正在考虑的系统(您的无人机系统)的每个用例是：

系统所执行的一组动作序列和变体的描述，对参与者产生可观察的值结果的描述。 -伊瓦尔·雅各布森

图中的每个UC都符合这个定义。

链接参与者/UC意味着参与者参与了用例。在这里，我会理解Developer参与了启动。但你对包括的案子只字未提，我不认为演员会直接参与其中，尽管我也不能排除它。

添加FlightController是不正确的，因为它不是系统环境中的参与者，而是系统的一部分。

我发现唯一令人困惑的是Start的误导性名称:命名意味着演员的目标仅仅是启动它。但在现实中，目标是执行一组预定义的操作。

注意:在您提到的另一个问题中，建议保存到数据库不是UC，因为它不是由用户执行的。此外，必须指出的是，保存到数据库并不是用户所能做到的。THe用户只通过其他用例查看数据库中的内容。您的情况有点不同，因为无人机的行为是可以观察到的，甚至可能是用户所期望的。

替代

不过，作为另一种选择，你可以考虑：

• 仅限于用户目标和用户真正参与的用例(例如，开始飞行和停止)。
• 使用活度图来描述在用例中发生的行为的细节，特别是在用户不参与的情况下。

这看起来可能是：

主要的好处是，您可以改进飞行逻辑，使其更加复杂，而不会失去用例图应该提供的大局。