use-case - 用例图中的不同参与者是否应该共享相同的登录用例？

Question

我目前有一个Use Case Diagram与上述类似的：

在我的最终应用程序中，我可能会为和共享相同的Login表单。我应该在这方面反映这一点，两者都使用相同的吗？如果是这样，那么我怎么能代表他们每个人在做完之后可以做什么？EmployeesEmployersUse Case DiagramActorsLogin Use CaseLogin

Answer 1

很可能会有其他共享用例？所以我认为“抽象”用户是有道理的，虽然我认为它不需要是“抽象的”，但它本身就可以是一个演员吗？

无论您喜欢哪种风格，建模的目的都是为了抽象信息。如果登录用例在某种程度上非常重要，它需要出现在图表中，那么这个图表并没有告诉我任何关于它的特别之处。这张图告诉我，在这个系统中，登录用例先于所有其他用例？呃？任何系统都会有一个登录用例，因此对于大多数系统来说，它不会（在架构上/非常）重要。如果用例由于某种原因很特殊，我会在没有关系的情况下放入图表，我认为这就足够了。该图将传达：我们有一个特殊的登录用例，我们希望您注意它。系统是否有匿名用例？可以在没有登录用例的情况下执行的用例？这很重要，值得一些模型元素。否则，这是暗示恕我直言。

如果您的建模需要做的不仅仅是理解和交流，例如需要驱动代码生成，这当然是不同的。但是你可以——根据你的建模环境——让它成为模型的一部分，而不是图表的一部分。这样一来，它就可以做到这两点：推动代码生成并促进理解和交流。

Answer 2

为什么不让 Employer 和 Employee 都从抽象 User 中专门化，并让 User 参与者使用 Login 用例？

然后 Employer 和 Employee 将只使用他们的特定用例。

Answer 3

@CesarGon's 是一个很好的解决方案。另一种选择——不一定更好，只是不同——是同时拥有UC和 Employee用Employer例。<<include>>login

您使用哪种取决于风格和偏好。Abstract User 方法看起来更简洁，更具声明性（您应该将登录指定为其他 UC 的先决条件）。该<<includes>>方法可能更适合命令式/流程建模思维方式，因为每个 UC 都会将登录调用明确显示为第一步。