第3章 用例图

为了保证系统正常运行，谁将对系统进行维护管理

（副参与者）？ 谁将完成系统数据的录入、导出及修改等工作（主 动参与者）？ 谁或什么系统对系统产生的结果感兴趣（被动参与 外部系统进行交互？ 在预定的时间，是否有事件自动触发？ 系统从何处获取信息？
（2）参与者不一定是人，也可以是一个外部系统， 该系统与本系统相互作用。代表的是一种角色。 （3）在系统的实际运作中，多个不同的用户可能 只对应于一个参与者；同时一个实际用户也可 能对应系统的多个参与者。
例如： 在“房地产开发经营管理系统”中，
所有的购房者作为一个集合，在“房屋销售子 系统”中作为购房合同的签约方出现，多个个 体在系统中担任一个参与者；同时，某个独立 的购房者在“物业管理子系统”中又作为房屋 的业主出现，同一个人在系统中担任了两类参 与者。
主参与者和副参与者
主参与者使用系统的主要功能，是使用系统较 频繁、业务量较大的用户。 副参与者处理系统的辅助功能，它与用例进行 交互的主要目的是为了给其他的参与者提供某些服 务。如管理数据库、通信、系统备份以及其他管理
等系统维护工作。
主动参与者和被动参与者
主动参与者是系统的启动者，负责启动一个或多
借阅图书用例的描述
用例名称 标识符 用例描述 参与者 状态 BorrowBook UC0001 图书管理员代理借阅者办理借阅手续 图书管理员 通过审查
前置条件
后置条件 假设 基本操作流程
图书管理员登录进入系统
如果这个用例成功，在系统中建立并存储借阅记录 图书管理员已经成功地登录到系统 1. 2. 3. 4. 5. 管理员输入借书证信息 系统验证借阅证的有效性 图书管理员输入图书信息 添加新的借阅记录 显示借书后的借阅信息
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后，与用例进行信息交换，用例在完 成相应功能后，向执行者返回结果。关联用执行者
与用例之间的带箭头连线来表示。
1、关联关系
关联关系是执行者与用例之间的联系。执行者 触发了用例之后，与用例进行信息交换，用例在完 成相应功能后，向执行者返回结果。关联用执行者 与用例之间的带箭头连线来表示。

<<include>>
基本用例
被包含用例
用例间的包含关系
<<include>>
BorrowBook
Librarian
ProcessOverTime
<<include>>
ReturnBook
图书管理系统用例图包含关系示例
4、扩展关系
扩展关系是一种依赖关系。它指定了一个用例可 以增强另一个用例的功能，通过基本用例添加动作来 扩展该用例。
AddBook
Libraian::LoanBook
3.3.2 确定用例
1、确定用例策略
确定用例最好的方法是从分析系统的参与者开始，
对于已经确定的参与者，通过考虑每个参与者是如
何使用系统的，以及系统对事件的响应来识别用例。
使用这种策略进行具体分析的过程中，可能会发现
新的参与者，这对完善整个系统的建模有很大的帮 助作用。
3.2.3 参与者之间的关系
参与者是类，类之间的关联也适用于参与者， 多个参与者之间的关系就是类与类之间的关系。在 用例图中，使用泛化关系来描述多个参与者之间的 公共行为。如果系统中存在几个参与者，他们既扮 演自身的角色，同时也扮演更具一般化的角色，那 么就用泛化关系来描述他们。
泛化关系：用一个三角箭头来表示，其中箭头所 指向的角色为超类参与者，箭头尾端的角色为特殊化
1、描述用例作用
用例图通过图形符号描述了参与者和系统之间
的关系，但是它对于系统行为的细节描述比较 欠缺。
在一般情况下，需要以书面文档的形式对于用
例进行描述。
2、描述用例包含的内容
1.名称：能够明确的表明用户的意图或用例的用途， 切记不要使用诸如UseCase1、UseCase2之类的 名称，会使用例图的读者在阅读时无法读懂用例 图所描述的内容。
参与者（Actor）
3.2.2 确定参与者
1、说明
（1）进行用例图建模，首先要做的就是确定系统 的参与者。 （2）在确定参与者之前，一定要明确一点：参与 者对于系统而言，总是处于系统外部的，而不 是系统的组成部分。
2、识别参与者
谁将使用系统的主要功能（主参与者）？ 谁将借助于系统来完成日常工作？

面向对象的系统分析主要特点是把问题域中的事 物抽象为系统中的对象，最终建立一个用面向对 象概念表达的系统模型。 抽象必须有一个目标，对分析而言，这个目标就 是要满足用户需求。 Jacobson提出：针对系统对外提供的每一项功 能，详细地描述对这项功能的使用情况（use case，简称用例）。


的参与者。
超类参与者
特殊化的参与者
特殊化的参与者
例：假设在图书管理系统中，管理员分为对系统进
行维护的系统管理员和完成借书、还书等日常操作 的图书管理员。在这里，管理员参与者描述了图书
管理员和系统管理员所扮演的一般角色。
管理员
图书管理员
系统管理员
3.3 用例（Use Case）
3.3.1 用例的概念



用例模型是表达系统外部事物（参与者）与系统 之间交互的可视化工具。

一个系统的用例模型由若干用例图组成，用例图 的主要成分有参与者（Actor）、用例（Use Case）以及用例间的各种关系。
用例图可以包含注释和约束，还可以包含包，用 于将模型中的元素组合成更大的模块。

用例1
参与者1 基用例1
3、参与者的分类
（1）人参与者和外部系统参与者 （2）主参与者和副参与者 （3）主动参与者和被动参与者
人参与者和外部系统参与者。
人参与者是系统的各类用户，用户通过与系统进行交
互来操纵系统，完成各种工作。 外部系统参与者是位于系统外部的其他软件系统或硬
件设备。
例如：计算机网络系统的参与者可以包括操作员系 统管理员、数据库管理员以及普通用户等人参与者，另 外也可以有外部系统参与者，如网络打印机。
可选操作流程
该借阅者有超期的借阅信息，进行超期处理； 借阅者所借阅的图书超过了规定的数量，用例终止，拒绝借阅； 借阅证不合法，用例终止，图书管理员进行确认 王强，定义基本操作流程，2008年1月7日 丁一，定义可选操作流程，2008年1月10日
修改历史记录
3.3.4 用例间的关系
在用例模型中，用例与参与者之间、用例与用 例之间有一定的关系。 UML中用例之间的关系主要有4种：关联关系、 泛化关系、包含关系和扩展关系。
2.标识符[可选]：用来唯一标识一个用例，如 “UC0001”，这样就可以在项目的其他元素中用 它来引用这个用例。 3.参与者[可选]：与此用例相关的参与者列表。在 没有用例图时，它有助于增加对该用例的理解。
4.状态[可选]：用来指示该用例的状态，通常可 包括进行中、等待审查、通过审查或未通过审查 等状态。 5.频率：记录参与者使用该用例的频率。
<<include>>
参与者2 基用例2
<<include>>
被包含用例 用例2
参与者3
基用例3
<<extend>>
扩展用例
基本用例图
3.2 参与者（Actor）
3.2.1 参与者概念
1、概念 参与者是在系统之外与系统进行交互的任 何事物，可以是人或其他系统，他以某种方式 参与了系统内用例的执行。 2、特征 （1）参与者作为外部用户与系统发生交互，交 互的方式可以是参与者向系统发送消息，也可 以是从系统那里接收消息，或与系统之间交换 消息。
8.假设[可选]：假设描述的是系统在使用用例之前 必须满足的状态，这些条件并没有经过用例的检 测，用例只是假设它们为真。 9.基本操作流程：参与者在用例中所遵循的主要逻 辑路径。操作流程描述了用户和执行用例之间交 互的每一步。 10.可选操作流程：包括用例中很少使用的逻辑路径， 那些在变更工作方式、出现异常或发生错误的情 况下所遵循的路径。 11.修改历史记录[可选]：主要记录的是关于用例的 修改时间、修改原因和修改人的详细信息。
用例建模的过程是一个迭代并逐步细化的过程。
2、确定用例方法
参与者需要系统提供什么功能？即参与者需要系统
“做什么”？
参与者是否需要读取、产生、删除、修改或存储系
统中的某种信息？
当系统状态改变时，是否通知参与者？ 是否存在影响系统的外部事件？ 系统需要什么样的输入/输出信息？
3.3.3 描述用例
<<extend>>
基本用例
扩展用例
<<include>>
BorrowBook Librarian ReturnBook
<<extend>>
<<include>>
ProcessOverTime
NotifyOverTime
3.4 用例图建模
1、用例图建模的步骤 在UML中，用例图建模的步骤主要包括： ① 识别和确定参与者。 ② 识别和确定用例。 ③ 描述用例。 ④ 定义用例之间的关系。 ⑤ 建立用例图，构造用例模型。 ⑥ 审核用例模型。
个用例，他们是为了完成某项事务而启动系统的，一 个主动参与者可以请求某种服务或者触发一个事件。 被动参与者从不启动用例，只是参与一个或多个 用例，他们响应系统的请求，为系统提供某种服务。
4、参与者的表示 在用例图中，参与者用一个简化的人体形状的 符号（稻草人）表示，在符号的下方注明了参与者 的名称。

以用例作为建立需求模型的基本单位，一个用例 只针对一项系统功能，详细的描述系统边界以外 的参与者使用这项功能时与系统进行交互的情况， 这可以比较确切地定义系统的功能需求。 用例的概念的提出弥补了以往各种面向对象分析 方法在需求定义方面的不足，因此很快就被广泛 采纳。 UML的面向对象系统开发过程中在需求分析阶段 的需求模型由用例建模完成，以用例为驱动，因 此又称为用例模型。
基本用例1
管理员
基本用例2
2、泛化关系
泛化关系表示两个用例之间存在用例泛化，其 中一个用例称为父用例，其派生的用例称为子用例， 子用例是父用例的特殊化形式。子用例除了具有父 用例的特性外，还可以有自己另外的特性。
父用例
子用例
用例间的泛化关系
3、包含关系
一个用例可以简单地包含其他用例具有的行为， 并把它所包含的用例行为作为自身行为的一部分， 这被称作包含关系。 包含关系是一种依赖关系。 包含关系把几个公共步骤抽取出来形成一个单独 的被包含用例，包含有公共步骤的用例称为基本 用例。 包含关系用虚线箭头加注<<include>>字样来表 示。
第3章 用例图
3.1 3.2 3.3 3.4 3.5 3.6 概述 参与者（Actor） 用例（Use Case） 用例间的关系 用例图建模 用例图建模实例
3.1 概述
在软件开发过程中，首先需要准确地描述客 户需求中的功能需求，即系统需要做什么，以便 进一步确定系统应建立哪些对象及所建立对象之 间的关系。用例建模是用于描述一个系统的功能 （即系统应该做什么）的建模技术。 建立用例模型的目的是为了寻找需求规约， 需要通过开发人员和客户之间进行多次的交互方 可完成。
1、概念
用例（Use Case）是对参与者使用系统某项
功能时所进行的交互过程的描述，过程中包括 交互双方所执行的一系列动作。
用例描述了参与者与系统交互的完整过程。
2、用例特征
响应性。一个用例不会自动执行，总是由参与
者启动或由系统根据某些事件触发，参与者必 须直接或间接地指示系统去执行用例。
6.前置条件：前置条件以一个条件列表的形式进 行记录，用来描述执行用例之前系统所必须满 足的条件。这些条件必须在使用用例之前得到 满足。前置条件在使用之前，已经由用例进行 过测试。如果条件不满足，则用例不会被执行。
7.后置条件：后置条件将在用例成功完成以后得 到满足，它提供了系统的部分描述。即在前置 条件满足后，用例做了什么？以及用例结束时， 系统处于什么状态？
回执性。用例执行完毕，向参与者提供可识别
的返回值。
完整性。用例表示一个完整的功能，必须是一
个完整的描述。
3、用例的表示 在UML语言中，用例用一个椭圆来表示，并 且每个用例必须有一个名字。 在用例命名时用例的名字一般用字符串来表 示，可分为简单名和路径名。其中，路径名引 入了包的概念，在用例名前加上该用例所属包 的名字，两个名字之间用两个冒号分开。