软件工程（第四版）高等教育出版社统一建模语言

参考资料：

软件工程（第4版）高等教育出版社

统一建模语言（UML）可分为：

·功能模型：从用户的角度展示系统的功能，包括用例图。

·对象模型：用对象、属性、操作、关联等概念来展示系统的结构和基础，包括类别图和对象图。

·动态模型：显示系统的内部行为。 包括序列图、活动图和状态图。

1.UML用例图

用例的概念：

从外部用户的角度来看，用例是参与者和目标软件系统之间的典型交互。 效果是执行者借助软件系统完成一定的业务功能。

从软件系统的内部角度来看，用例代表系统执行的一系列操作。

简而言之：用例是参与者在使用系统功能时执行的交互过程的一系列文本描述。

执行者是指系统交互过程中外部用户或外部实体所扮演的角色。 执行者可以是一类用户，也可以是其他软件系统或物理设备。

用例图：

UML用例模型由一个或多个用例图组成，这些用例图代表了从软件系统外部用户的角度看到的各种系统功能，并清晰地说明了软件系统的边界。

即用例图中使用的用例集合构成了目标软件系统应提供的功能，该软件系统不再承诺其他功能。

用例图中有两种类型的节点：执行器和用例。

用例图的边缘表示执行器和用例之间、两个用例之间以及两个执行器之间的关系。

1.1 执行者和用例之间的关系

执行器与用例之间的连接边是指：执行器触发用例的执行、向用例提供信息或从用例中获取信息。

1.2 用例之间的关系

用例之间的关系主要有三种类型：()、() 和。

1.2.1 包含

包含关系意味着基础用例（Base）将被包含的用例（）使用

例如：在一台ATM机中，如果查询、取款、转账这三个用例都需要打印一张收据给客户，我们可以将打印收据的内容提取出来，抽象成一个单独的用例“打印”收据”，而原来的一些查询、提现、转账的例子都会包含这个用例。 以后每当修改打印票据的需求时，只需要修改一个用例，而不是每个用例都进行相应的修改，提高了用例模型的可维护性。

当某个用例的事件流过于复杂时，为了简化用例的描述，我们可以将事件流的某一段抽象为一个包含的用例。

这种情况类似于过程式设计语言中，将程序的某种算法封装成一个子流程，然后在主程序中调用该子流程。

1.3.2 扩展

() 关系，在基本用例（Base）中定义一个或多个命名扩展点。 扩展关系是指在一定条件下将扩展用例（）的事件流按照对应的扩展点插入到基础用例中。

对于包含关系，包含的用例必须插入到基本用例中。 扩展关系可以根据一定的条件决定是否将扩展用例的事件流插入到基本用例事件流中，插入点可以有多个。

扩展关系通常用于区分正常业务处理功能和异常处理功能。

例如：假设课程注册管理系统中每门课程允许的学生人数是有限的。 一旦超过限制，必须征得老师的同意。可以设置用例“制定选课计划[考虑学生人数的限制]”，并将其作为“制定选课计划”的扩展用例选课计划”

例如，对于电话业务，可以将呼叫等待（Call）、呼叫转移（Call）等一些增值业务扩展到基本呼叫业务。 我们可以使用扩展关系来描述这些业务的用例模型，如右图所示。

在这个例子中，呼叫等待和呼叫转移都是基本呼叫用例的扩展，但这两个用例只会在某些条件下（例如响应者忙或响应者不忙）才会转移扩展用例的事件流。回答）。 嵌入基本调用用例的扩展点并重用基本调用用例中的事件流。

1.1.3 继承（也称为泛化）

当多个用例具有相似的结构和行为时，我们可以将它们的共性抽象为父用例，将其他用例抽象为泛化关系中的子用例。

子用例从父用例继承行为和属性，并且还可以添加行为或覆盖和更改继承的行为。

1.3 执行人之间的关系

执行者之间唯一的关系就是继承。

比如需求分析中常见的权限控制问题（如右图），普通用户只能使用一些常规操作，而管理员除了常规操作外还需要进行一些系统管理工作。 操作员既可以进行常规操作也可以进行一些配置操作。

在这个例子中我们会发现管理员和操作员都是特殊用户。 他们拥有普通用户拥有的所有权限。 此外，他们还有自己独特的权限。 这里我们可以将普通用户、管理员、操作员之间的关系进一步抽象为广义的()关系。 管理员和操作员可以继承普通用户的所有特征（包括权限），并且可以拥有自己独特的（如操作、权限等）。 这可以显着减少用例图中的关联数量，简化用例模型，使其更易于理解。