用例图

Question

我是UML的新手。我有一个问题。考虑我们有一个用户可以更改用例规范（更改用户密码，授予访问权限，...）用例图这两个图片中的哪一个是正确的：< / p>

1）

2）

如果No.1在哪个图表中是否正确，我们会显示详细信息？谢谢

Answer 1

我倾向于说图＃1是正确的，但这取决于您的具体要求。鉴于样本用例，我宁愿期待这样的事情：

1. 演员管理员 - ＆gt;修改用户授权（匹配授予/拒绝访问）
2. 演员管理员 - ＆gt;更改用户密码
3. 演员管理员 - ＆gt;修改用户详细信息（用户规范）
4. 演员最终用户 - ＆gt;更改用户密码（＃2的变体）
5. 演员最终用户 - ＆gt;修改用户详细信息（＃3的变体）

要详细说明 UML图表中的用例，您有两个选项，即活动图和/或序列图。 Neverthess，我会小心走这条路，在你的项目中，你将不得不付出很多努力来维护这些图表。我的经验是，只要编写了第一行代码，就不会再有人看到美丽的图表了。经验法则 - 形式规范是团队复杂性的一个功能。如果你有一个全球团队，开发人员在不同的时区，那么在这种规范中投入更多精力是有意义的。

这对我有用：

1. 创建用例概述（图形就像您的图形或只是文本文档）
2. 以user stories
的形式记录用例
3. 使用复杂流程的活动图，可能跨越多个用例，例如：订单处理
4. 创建一些序列图，以记录系统的重要技术方面，如授权，事务管理，所有不同层之间的端到端通信

编辑：UML提供了几种类型的图表来记录和建模系统上的不同视图。 用例图本身并非旨在记录系统的详细低级方面。根据WikiPedia：

  

用例图：描述系统根据参与者提供的功能，   他们的目标表示为用例，以及它们之间的任何依赖关系   用例。

Answer 2

该图表只是为了给您一个概述。用例的重量级是随之而来的文本描述。在那里，您将按顺序描述用例，涉及的参与者，前后条件以及用例的实际步骤。请查看此textual specification并注意标题部分。这是一个很好的例子，说明如何描述用例。基本上，您希望将您的描述拆分为＃2，但对于概述“大”图片，将它们分组可能也是有益的。所以你有例如用例“＃1更改用户规范”然后你有“＃1a更改用户密码”，“＃1b授予访问权限”等。

对用例和用户故事保持谨慎！

• 用例在您显示的图表中显示，并以相当严格的格式描述。它们旨在成为某个用户操作的规范，并允许您将该功能记录并规定到相当详细的级别（从用户的角度来看，但有时也会进入系统视角）。
• 另一方面，用户故事来自敏捷世界，是对“功能”的简化描述。重要的是要澄清用户故事并不是规范！它们不包括前后条件或详细的基本和替代流程描述！它们的意思是如此之小，不能用一句话来描述。

对于用户故事，程序员可以自由/需要自己解决问题，例如如果出现错误等该怎么做。对于用例，它都记录在案，错误信息本身以及应该发生的事情。

Answer 3

第一种情况更好，用例不应该用于某些功能分解，它们只是用例:)。如果作为“更改密码”的操作可以被视为单独的用例，或者让我们说其他用例的或多或少独立部分，那么您可以＆lt;＆lt; include＆gt;＆gt; 。< / p>