建模——用例图（Use）

用例图主要用于描述角色以及角色与用例之间的连接关系。 描述谁将使用该系统以及他们可以用它做什么。 用例图包含多个模型元素，例如系统、参与者和用例，并显示这些元素之间的各种关系，例如泛化、关联和依赖关系。 它呈现了可供外部用户观察的系统功能模型图。

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

1. 用例图中包含的元素

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

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

3. ()——用于显示系统的部分功能，这些功能密切相关。

2. 用例图中包含的关系

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

如下表所示：

A。 协会（）

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

[箭头指向]：无箭头，将参与者连接到用例，指向消息接收者

b. 概括（）

就是通常理解的继承关系。 子用例与父用例类似，但表现出更特殊的行为； 子用例将继承父用例的所有结构、行为和关系。 子用例可以使用父用例中的一个行为，也可以覆盖它。 父用例通常是抽象的。 泛化关系在实际应用中很少使用，子用例中的特殊行为可以作为父用例中的替代流存在。

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

C。 包含（

包含关系用于将更复杂的用例所表示的功能分解为更小的步骤。 包含关系的一个典型应用就是复用，也就是定义中提到的场景。 但有时当用例的事件流过于复杂时，为了简化用例的描述，我们也可以将某个事件流抽象为包含的用例； 相反，当用例划分得太细时，我们也可以抽象出一个基本用例。 包括这些细粒度的用例。 这种情况类似于用过程设计语言将程序的某种算法封装成一个子流程，然后从主程序中调用这个子流程。

例如：在业务中，总有维护某些信息的功能。 如果作为用例，添加、修改、删除必须在用例详细信息中描述，过于复杂； 如果划分为添加用例、修改用例和删除用例则划分得太细。 这时候就可以利用包含关系来理清关系。

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

d.()

扩展关系是指用例功能的扩展，相当于为基本用例提供了额外的功能。 用()用例封装基用例中相对独立且可选的动作，然后从基用例中声明的扩展点（Point）进行扩展，从而使基用例行为更加简洁和集中。 。 扩展用例向基本用例添加新行为。 扩展用例可以访问基本用例的属性，因此它可以根据基本用例中扩展点的当前状态来确定是否执行自身。 但扩展用例对基本用例不可见。

对于扩展用例，基本用例上可以有多个扩展点。

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

e. 依赖（）

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

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

5. 项目（）

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

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

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

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

6.评论()

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

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

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

扩展

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

●泛化侧重于表达子用例之间的互斥性；

●包容性侧重于包含的用例向参与者提供的服务的间接性；

●扩展强调代表扩展用例触发的不确定性；

需要提及的另一点是，泛化中的子用例和扩展中的扩展用例都可以作为基本用例事件的替代流而存在。

3. 用例图的几个例子

********************************************************** *****************************

下面是一个在线购物系统的用例图，它提供了系统的整体描述。

(1) 系统整体用例图

（用户配置文件用例）