UML统一建模语言——用例图使用方法

UML概念

UML(Unified Modeling Language)是一个支持模型化和软件系统开发的图形化语言，为面向对象开发系统的产品进行说明、可视化、编制文档的一种标准语言。

UML2中一共定义14种图示，分为结构式图形和行为式图形。结构式图形分为：剖面图、类图、复合结构图、组件图、部署图、对象图、包图。行为式图形分为：活动图、交互图（交互图又分为序列图、通信图、交互概览图、时序图）、用例图和状态图。

UML的绘制工具

用例图的概念

用例图（Use Case Diagram）是用户与系统交互的最简表示形式，展现了用户和与TA相关的用例之间的关联关系。通过用例图，人们可以获知系统不同种类的用户和用例：

• 用例图呈现出谁将是相关的用户
• 用户希望系统提供什么样的服务
• 用户需为系统提供什么样的操作

用例图的构成元素

用例图主要有4个构成元素：

参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类外部实体的抽象。

• 建立系统的外部用户模型，并对系统边界外对象做描述
• 每个参与者可以参与一个或多个用例，每个用例也可以有一个或者多个参与者

系统（System）是用例图的一个组成部分，代表的是一个软/硬件或-一个活动等，并不是真正实现的软件系统。系统边界，指系统与系统之间的界限:

• 一般我们所说的系统都是由一系列的相互作用的元素形成的具有特定功能的整体
• 一个系统往往本身又可以是另一个更大系统的组成部分

因此我们需要把系统用边界区分开来，系统边界以外的系统和其他关联部分，我们称为系统环境。

用例（Use Case）用来描述系统提供给参与者的服务或功能。

• 用例由某个参与者来执行
• 用例把执行的结果反馈给参与者
• 用例在功能上具有完整性:从参与者接受输入，产生的结果输出给参与者

关系（Association），表示参与者和用例间的关联关系。

从图中可看出:

• 所有的用例都放在一个系统边界内，说明它们属于一个系统。
• 参与者在系统边界外面，说明参与者并不属于系统，但参与者驱动与之关联用例的执行。

用例图的特点

1.用例用以描述系统的功能，这个功能是指外部使用者看到的系统功能，不需反映功能的实现方式。

2.用例用以描述参与者提出的一些可见需求，对应具体的目标参与者。并且用例必须由参与者激活才能执行，即每个用例至少有一个参与者。

3.用例反映系统与用户的交互过程，可具有交互的信息传递。

用例图的规约

1.用例名称

需与用例图中的名称保持一致。 （也可加一个“用例ID”，如用：名称英文+编号即可，保持唯一性）

2.简要描述

简要说明用例及它的作用、目的。

3.参与者

与该用例相关的参与者，与用例图中的参与者关系保持一致。

4.相关用例

与该用例存在关系的用例，不同的用例关系采用不同表示方式，并与用例图中的用例间关系一致。

5.前置条件

指执行用例之间系统必须所处的状态。例如，前置条件是要求用户有访问的权限，或是要求某个用例必须已经执行完。

6.后置条件

指用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。

7.事件流

事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。备选流描述的时用例执行过程中可能发生的异常事件和分支事件。

8.补充约束

描述与该用例相关的其他约束，包括数据需求、业务规则、非功能需求、设计约束等。

用例图的关系类型

注：包含、扩展关系表示符号建议采用英文<<include>>、<<extend>>, 此处并非书名号《》，而是大于小于号<<>>

ps：泛化有点像java中的继承

参与者与用例之间的关系

表示参与者与用例的关联关系，一般用实线连接参与者与用例。

参与者与参与者之间的关系

参与者之间的泛化关系表示某些具有共同行为的参与者。一般使用空心三角箭头的实线表示。

用例与用例之间的关系（包含关系）

用例可以包含其他用例具有的行为，并把所包含的用例行为作为自身行为的一部分，主要有两种情况使用包含关系：

• 多个用例用到同一段行为，把这段共同的行为单独抽象成为一个用例，让其他用例包含这一用例。
• 用例功能过多，事件流过于复杂，也可把某一段事件流抽象为一个被包含的用例，用以简化描述。

被包含的用例是包含用例，使用包含用例的为基用例。用例间的包含关系用：带实箭头的虚线+<< include >>字样来表示。

在下图中，“录入年级”和“修改年级”是基用例，都包含“保存年级”，基用例执行时必须执行包含用例，不然用例不完整。

用例与用例之间的关系（扩展关系）

一定条件下，把新的行为加入到已有的用例中，获得的新用例称为扩展用例，原有的用例叫做基础用例，从扩展用例到基础用例的关系就是扩展关系。

一个基础用例可以有一个或多个扩展用例，这些扩展用例可以一起使用。用例间的扩展关系用：带实箭头的虚线+ << extend >>字样来表示。

在下图中，“语音答题”是扩展用例，“互动答题”是基础用例。

用例与用例之间的关系（泛化关系）

用例的泛化指一个父用例可以被特化成多个子用例，它们之间的关系称为泛化关系。在用例的泛化关联中，子用例继承父用例所有的结构、行为和关系。子用例是父用例的一种特殊形式。子用例也可以添加、覆盖、改变继承的行为。用例间的泛化关系用：带空箭头的实线来表示。

如下图，线上答题有两种方式，一种是在课堂互动答题，一种是课后练习，在这里“课堂互动答题”和“课后练习”都是答题的一种特殊方式。因此，“答题”为父用例，“课堂互动答题"和“课后练习”为子用例，它们间的关联为泛化关系。

各种关系间的联系和区别（主要：包含、扩展、泛化）

用例泛化过程是将不同用例之间的可合并部分抽象成独立的父用例，并将不可合并部分单独成各自的子用例；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的：

• 泛化侧重表示子用例间的互斥性
• 包含侧重表示被包含用例对参与者提供服务的间接性，基础用例执行时，包含用例一定执行
• 扩展侧重表示扩展用例的触发不定性，它的发生是有条件的

用例图的三层级

用例图存在各种关系，通过一层层的关系，我们可以将用例分层。如果不分层，随意去写用例，会导致用例没有层次和顺序，导致遗漏一些需求，另外也不利于协作人员理解需求。

用例图的构建

（一）找出参与者

可以是与系统有交互的外部硬/软件、人等。（都以“人型”符号标识）

• 如对于鼠标或打印机驱动的用例，参与者就是鼠标或者是打印机
• 如动物的饮水系统，由动物来触发自动出水，参与者就是动物

在确认用例前先要确定系统的参与者，我们可以通过回答以下的问题来寻找系统的参与者：

• 谁将使用该系统的主要功能
• 谁将需要该系统的支持以完成其工作
• 谁将需要维护、管理该系统，以及保持该系统处于工作状态
• 系统需要处理哪些硬件设备
• 与该系统交互的是什么系统
• 谁或什么系统对本系统产生的结果感兴趣

（二）创建用例图

找出用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。并用用例三层级来梳理用例，使用这种策略的过程可避免发生遗漏。

在识别用例的过程中，通过回答下面几个问题，可以获得帮助：

• 特定参与者希望系统提供什么功能
• 系统是否存储和检索信息。如果是，那么由哪一个参与者触发
• 是否存在影响系统的外部事件
• 哪个参与者通知系统这些事件
• 当系统改变状态时，是否通知参与者

（三）编制用例说明

 转自知乎letinv ，仅限交流学习