应如何为用例图的条件路径建模?

How Should Conditional Paths for Use-case Diagrams be Modeled?

我正在制作一个网站,访问者可以:

我不明白我应该如何为访问者可用的不同用例建模。由于未注册访客可以成为注册访客,注册访客也可以成为未注册访客,他们可以在网站上做同样的事情,只是走不同的路。

这些条件对于用例图重要吗?说正规注册需要填写很多字段,而Facebook注册只需要访问者选择一个用户名,这样说是不是太具体了?

用例可以自我扩展吗?比如注册失败,访客重新注册。

编辑:我猜想如何制作图表:

编辑 2:或者像这样更简单?

你的第二个模型要好得多。即使在规范中提供了示例,也不经常使用用例概括。 .

由于用户应该可以注册,因此可以删除演员 "Unregistered User"。没有?

我只在一种情况下使用用例泛化:当我希望多个用例获得相同的包含或扩展时。

按照您的方式显示约束并没有错。我所做的通常是创建一个像您的#2 这样的概览图。然后专注于单个用例,仅显示它们与参与者和需求的关系 - 以及最终从后者得出的约束。

不要陷入功能分解的陷阱,避免 <<include>>/<<extend>> 甚至更糟的泛化。用例不是用来分解功能部分而是综合它们。用例显示了所考虑的系统为其参与者之一提供的单一附加值。

Login 不是用例,因为它没有附加值。这是一个可以附加到用例的约束。

一如既往:UML 规范不利于理解用例综合。它是由没有什么商业背景的书呆子写的。请查看 Bittner/Spence。

正如@granier 所说,你的第二个模型要好得多,@Thomas Kilian 的观点是可以重塑的。

我想说出你的错误并提供一个新的用例图。我认为您的模型中存在一些错误(逻辑上和实践上):

  1. Use Case Diagram太详细(模型1)(请看我之前的postTIPShere )
  2. 用户名不是用例。
  3. 登录名和重置密码之间没有扩展关系。 (模型 2)
  4. 登录与注册用户关联?所有用户都可以触发登录用例(无论是否成功)。
  5. 包含和扩展以及继承关系的错误使用(模型 1)。

请考虑我提供的用例图:

此外,您可以向用例 文档 添加先决条件和 post 条件。但是,它们不会更改用例。