8.3.1 用例图
描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
（1）用例模型概述。用例模型描述的外部参与者所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结构，描述了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它把系统开发视作黑盒子，从外部参与者的角度来理解系统；最后，它参与了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。
（2）用例的组成。一个用例由以系统边界、参与者、用例和关系要素构成，下面分别一一介绍。
1）系统边界。系统边界是定义由谁或什么（即参与者）使用系统，系统能够为哪些参与者提供什么特定利益（即用例）。
系统边界在UML中绘制为方框，用系统的名称作为标签，参与者绘制在边界外部，用例绘制在边界内部。一个棋盘管理系统的边界如图8.3所示。
图8.3 棋盘管理系统边界
2）参与者（活动者，Actor）
①参与者的表示。参与者是与系统交互的人或物，它代表外部实体，例如用户，硬件设备或与本系统交互的另一个软件系统。使用用例并与系统交互的任何人或物都是参与者。如图8.4所示。
图8.4 参与者的表示
参与者是一个群体概念，代表的是一类能够使用某个功能的人或物，而不是某个个体。例如，在自动售货机系统中，使用售货功能的人可以是张三，也可以是李四，但是张三或李四这样的个体对象并不能称为参与者。事实上，一个具体的人在系统中可以充当多种不同的角色。例如，某个人既可以为售货机添加物品（执行供货功能），又可以把售货机中的钱取走（执行取货款功能）。
②参与者间的关系。如果一个角色的操作是由另一个角色代理完成的，先建立该角色到另外角色之间的依赖。如下图所示，角色之间的关系如图8.5所示。
图8.5 角色之间的关系
③怎样识别参与者。实践表明，参与者对确定用例是非常有用的，面对一个大型、复杂的系统，要列出用例清单往往很困难，这时可以先列出参与者清单，在针对每个参与者列出它的用例。对于参与者通过以下几个问题来确认。
谁向系统提供信息？
谁从系统获取信息？
谁操作系统？
谁维护系统？
系统使用哪些外部资源？
系统是否和已经存在的系统交互？
3）用例（Use Case）。
一个用例实质上是用户与计算机系统之间的一次典型的交互作用，它代表的是系统的一个完整的功能。在UML中把用例定义成系统执行的一系列动作，动作的结构能被外部参与者察觉到。
在UML用例图中，用例表示为一个椭圆。图8.6是自动售货机系统的用例图。其中“售货”“供货”和“取货款”都是典型的用例。
概括地说，用例具有以下特点：
①用例代表某些用户可见的功能，实现一个具体的用户目标；
②用例由参与者激活，并提供确切的值给参与者；
③用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。
需要注意的是，用例是一个类，它代表一类功能而不是使用该功能的某个具体事例。用例的实例是系统的一种实际使用方法，通常把用例的实例称为脚本。脚本是系统的一次具体执行过程。例如，在自动售货机系统中，张三投入硬币购买矿泉水，系统收到钱后把矿泉水送出来，这个过程就是一个脚本。
图8.6 自动售货机系统用例图
4）关系（Relationship）。
用例图中有以下四种基本关系：
关联（association）；
包含（include）；
扩展（extend）；
泛化（generalization）。
①关联关系。描述参与者与用例之间的关系，用单向箭头，表示谁启动用例，每个用例都有角色启动，除包含和扩展用例。客户和转账之间是关联关系，如图8.7所示。
图8.7 关联关系
②包含关系。是指两个用例之间的关系。其中一个用例（基本用例，base use case）的行为包含了另一个用例（包含用例，inclusion use case）的行为。如图8.8所示。
图8.8 包含关系
执行基础用例时，必须执行被包含用例，被包含用例也可单独执行。例如在图8.9中，取消订单用例必须先执行查询订单用例，所以这两个用例是包含关系。
图8.9 包含关系
如果一个用例的功能太多时，可用包含关系建模成两个或多个小用例。如图8.10所示，学生信息管理用例有分解成添加学生记录、删除学生记录和修改学生记录用例。
图8.10 包含关系
③扩展关系。扩展关系是指两个用例之间的关系。一个用例可以被定义为基础用例的增量扩展，称作扩展关系。扩展关系是把新的行为插入到已有用例中的方法。
基础用例即使没有扩展用例也是完整的。一般情况下基础用例的执行不会涉及扩展用例，只有特定条件发生，扩展用例才被执行。如图8.11是基本用例和包含用例的关系。
图8.11 扩展关系
例8.2 如图8.12所示订货购物用例和VIP打折用例之间的关系为扩展关系。
图8.12 扩展关系示例
④泛化关系。一个用例和几种情形的用例间构成泛化关系。往往父用例表示为抽象用例，任何父用例出现的地方子用例也可出现。如图8.13所示。电话预订用例和网上预订用例是父用例预订的具体用例，之间是泛化关系。
(https://www.daowen.com)
图8.13 泛化关系
（3）建立用例模型。几乎在任何情况下都需要使用用例，通过用例可以获取用户需求，规划和控制项目。获取用例是需求分析阶段的主要工作之一，而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生，并且随着开发工作的深入还会发现更多用例，这些新发现的用例都应及时补充进已有的用例集中。用例集中的每个用例都是系统的一个潜在的需求。
1）发现参与者。为获取用例首先要找出系统的参与者，可以通过请系统的用户回答一下问题的办法来发现参与者。
①谁将使用系统的主要功能？
②谁来维护和管理系统？
③系统控制哪些硬件设备？
④系统需要与哪些其他的系统交换？
2）获取用例。事实上，从识别参与者起获取用例的过程就已经开始了。一旦识别出了参与者，就可以对每个参与者提出问题以获取用例。
参与者需要从系统中获得何种功能？
①参与者需要读取、产生、删除、修改或存储系统中的某种信息吗？
②系统中发生的事件需要通知参与者吗？
③系统需要何种输入/输出？
例8.3 有一业务需求列表如下，要求为其构建一个用例图。
①系统可以供教师使用，为学生记录成绩。
②系统根据需要创建报告卡。
③系统允许用户浏览记录的成绩。
第一步：首先需要询问业务需求的提出者以获取更多的信息。
提问1：教师可以对已经输入的信息进行更新吗？
回答：可以！
提问2：谁来创建报告卡，是教师吗？
回答：不！有一位管理人员来做这项工作。
提问3：报告卡创建后，还可以对它做些什么工作？
回答：在报告卡创建后，管理人员要检查其准确性。当报告卡核准后，教师应该通过计算机分发报告卡。
提问4：谁需要浏览成绩？
回答：教师和学生。
第二步：确定系统的边界范围，找出系统中的参与者和用例。
通过访谈，会得出一个修改过的新的系统需求列表。
需求1：系统可以供教师使用来为学生记录并更新成绩。
需求2：系统根据需求由管理人员创建报告卡，管理人员要检查报告卡的准确性。
需求3：教师需要通过计算机分发报告卡。
需求4：系统允许教师和学生浏览记录的成绩。
由此可得出系统的参与者及用例。
参与者：教师、学生、管理员。
用例：记录成绩、更新成绩、生成报告卡、检查报告卡的准确性、分发报告卡、浏览成绩。
第三步：细化每个用例。
①对“记录成绩”用例进行细化，下面是该用例的主事件流。
②教师确定出要记录哪些学生的成绩。
③系统要确保学生在数据库中。
④教师说明要记录哪项作业的成绩。
⑤系统开始数据库的一项事务处理。
⑥系统为学生把作业加入数据库。
⑦教师输入学生作业的成绩。
⑧系统核对输入的成绩以确保其属于正确的范围。
⑨系统记录作业的成绩。
⑩系统结束事务的处理。
⑪系统提示教师成绩已经记录。
细化过程中可添加新发现的用例，并根据优先级重新排列。
①登录。
②保存成绩（save grades）。
③记录成绩（record grades）。
④加载成绩（load grades）。
⑤浏览成绩（view grades）。
⑥更新成绩（update grades）。
⑦生成报告卡（generate grades）。
⑧分发报告卡（distribute report cards）。
第四步：建立用例模型结构，建立用例图如图8.14所示。
图8.14 系统用例图
