我可以在一个用例图中添加 2 个登录功能吗

Question

我为学术日历应用程序绘制了一个用例模型，但令人困扰的是我在同一模型中放置了 2 个登录功能。一份给学术顾问，一份给学生。

所以我的问题是：这样可以吗？
或者我应该从演员学术顾问到与学生登录相同的功能划清界限。

最后也是重要的一点：虚线中的Extends意味着什么？

这是我的模型

Answer 1

简而言之

\n

Login原则上不应该是一个用例。但是，如果保留它，请不要为不同的参与者重复它：更喜欢与相同用例进行加法关联，或者更好地重构您的图表以使用泛化。

\n

扩展意味着Change Profile Status在某些情况下可以丰富 的行为和交互Login。

\n

更多说明

\n

1. 登录是一个用例吗？

\n

用例之间没有顺序，用例应该是参与者使用系统的原因。根据您的图表，参与者可以仅出于Login（真的吗？）的唯一目的使用该系统。或者做一个Managing schedule或者在没有登录的情况下

\n

这表明登录不是用例，而是约束，或者是活动图中描述每个用例的操作。（顺便说一句，在单点登录时代，登录通常已经过时，这使得登录在后台发生而无需用户参与；autheticate user）将是相应的操作）

\n

2. 多个参与者的用例的模糊性

\n

UML 规范没有定义具有多个参与者的用例的语义。这可能意味着几个中的一个可以执行该用例（但应相应地设置多重性），或者多个或全部都参与该用例，但不告诉它是否在销售时\xe2\x80\x99s或一个接一个地。

\n

无论如何，它\xe2\x80\x99 都是含糊不清的，即使我们大多数人在阅读图表时都正确理解了预期的含义。

\n

另一方面，用例不应该重复来表示不同参与者的同一组行为。

\n

还有其他选择吗？

\n

两种流行的技术有助于消除针对销售用例的多个参与者的歧义：

\n

\n
• 参与者的泛化：如果一个用例对于多个参与者来说是通用的，那么您也许可以为所有常见用例确定一个基本参与者。在你的图中，这意味着引入一个 actorUser并让Student并Admin继承自User。
\n
• 消除用于描述每个用例的文本叙述中的歧义
\n

\n