美国科学家展示外部用户的系统功能模型图

【目的】：帮助开发团队直观地了解系统的功能需求。

用例图中包含的元素如下：

1. 演员

代表与您的应用程序或系统交互的用户、组织或外部系统。 以一个小人物为代表。

2.使用案例

用例是外部可见的系统功能，描述系统提供的服务。 用椭圆表示。

3. 子系统()

用于显示系统的部分功能，这些功能是密切相关的。

4.关系

用例图中涉及的关系有：关联、泛化、包含和扩展。

如下表所示：

A。 协会（）

代表参与者和用例之间的通信，任何一方都可以发送或接收消息。

【箭头指向】：指向消息接收者

b. 概括（）

就是通常理解的继承关系。 子用例与父用例类似，但表现出更特殊的行为； 子用例将继承父用例的所有结构、行为和关系。 子用例可以使用父用例中的一个行为，也可以覆盖它。 父用例通常是抽象的。

[箭头指向]：指向父用例

C。 包含（）

包含关系用于将更复杂的用例所表示的功能分解为更小的步骤。

[箭头指向]：指向分解后的功能用例

d.()

扩展关系是指用例功能的扩展，相当于为基本用例提供了额外的功能。

[箭头指向]：指向基本用例

e. 依赖（）

以上四种关系是UML定义的标准关系。 然而，在用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

[箭头指向]：指向从属项

5. 项目（）

虽然用例图可以帮助人们直观地理解功能需求，但能够理解的人并不多。 在许多情况下，与用户沟通甚至使用 Excel 都比用例图更好。 用例图中引入了元素“项目”，以便开发人员可以链接用例图中的公共文档。

使用依赖项来依赖于项目的用例：

然后将->设置为你的文档；

这样，当您双击用例图上的某个项目时，就会打开关联的文档。

6.评论()

()、() 和 () 之间的区别：

条件性：泛化中的子用例和包含的用例将无条件发生，而扩展用例中的发生是有条件的；

直接性：泛化用例和扩展用例中的子用例为参与者提供直接服务，而包含的用例为参与者提供间接服务。

例如，扩展用例不包括基本用例的内容，并且基本用例不包括扩展用例的内容。

例如，子用例包括基础用例的所有内容及其与其他用例或参与者的关系；

用例图示例：

抱怨：

我感觉用例图不成熟，不能很好地表达系统需求。 没有UML背景的用户很难知道正在绘制什么。

其次，包含关系和扩展关系的箭头符号实际上是相同的箭头。 它们的区别在于只在上面写一个字。 如果翻译成其他语言，几乎不可能知道它们的意思。 也很难理解为什么扩展关系的箭头指向基本用例而不是扩展用例。

增加的“项目”元素是一个很好的创新，可以与用例图中的word、excel等文档关联起来。 但为什么不直接将这些功能集成到用例中呢？ 如果双击用例时弹出一个文档不是更容易理解吗？ 您必须在额外的步骤中添加一个组件才能提供链接功能。

用例描述表：

由于柱形图无法清晰表达功能需求，因此通常使用描述表来补充一些开发过程中难以表达的用例。 下图中的表格为您提供参考：