Usecase图

Question

我是UML.I新手。我有一个question.consider，我们有一个用户可以更改用户规范(更改用户密码、授予访问权限...)对于用例图，这两张图中哪一张是正确的：

1)

​

2)

​

如果1号是正确的，我们应该在哪个图表中显示详细信息?谢谢

Answer 1

我倾向于说图#1是正确的，但这取决于您的具体需求。给出示例用例，我更希望是这样的：

1. 执行元管理员->修改用户授权(匹配授予/拒绝访问)
2. 执行元管理员->更改用户密码
3. 执行元管理员->修改用户详细信息(user specification)
4. Actor最终用户->更改用户密码(#2的变体)
5. 执行元最终用户->修改用户详细信息(#3的变体)

为了详细描述UML图中的用例，您有两个选项，一个活动图和/或一个序列图。无论如何，我会小心地走这条路，在你的项目期间，你将不得不投入大量的精力来维护这些图表。我的经验是，一旦编写了第一行代码，就没有人会再去看美图了。经验法则-正式规范是团队复杂性的函数。如果您有一个全球团队，其开发人员分布在不同的时区，那么在这种规范上投入更多的精力可能是有意义的。

这对我很有效：

order document)

• Document创建一个用例概述(像您这样的图形化或简单的文本活动图形式的复杂流程的

• 用例，可能跨越多个用例，例如一个order process

• Create几个序列图，以记录系统的重要技术方面，如授权、事务管理、所有不同层之间的端到端通信

编辑：UML提供了几种类型的图表来对系统上的不同视图进行文档记录和建模。用例图本身并不是为了记录系统的详细、低级方面而设计的。根据WikiPedia：

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

Answer 2

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

谨慎对待用例和用户故事！

如您所示，

• 用例以图表的形式呈现，并以相当严格的格式进行描述。它们是特定用户操作的规范，并允许您记录和规定相当详细的功能(从用户的角度来看，但也从系统的角度来看)。另一方面，sometimes).
• User故事来自敏捷世界，是对“功能”的更简单的描述。有一点很重要，那就是澄清用户故事并不意味着规范！它们不包括前置和后置条件，也不包括详细的基本和可选流程描述！它们应该是如此之小，以至于可以用一句话来描述。

有了用户故事，程序员就可以自由/被要求自己解决问题，比如如果出现错误该怎么办等等。对于用例，都有文档记录，错误消息本身以及应该发生的事情。

Answer 3

第一种情况更好，用例不应该用于某些功能分解，它们只是用例:)。如果像“更改密码”这样的操作既可以被看作是单独的用例，也可以说是其他用例中或多或少独立的部分，那么您可以对它们进行<>。