3.5.1 Use Case的确定
Use Case的种类大体如下： （1）系统的开始和停止的Use Case。 （2）系统维护的Use Case。 如添加新用户，设置用户的操作模板（profile）等。 （3）维护系统中存储数据的Use Case。 如所建造的系统要与现存的系统数据同步。 （4）修改系统行为的功能的Use Case。 如创建一个新报表，而不是对一个一个的报表进行单 独的编程。
正确
正确
错误
3.4.2 用例之间的关系
包含关系用于表示用例为执行其功能时需要 从其他用例引入功能。 扩展关系则表示用例的功能可以通过其他用 例的功能得到扩充。 泛化关系表示用例之间的一般与特殊关系。
一、包含关系
1、概念
包含关系描述的是一个用例需要某种类型的功能，而该功 能被另外一个用例定义，那么在用例的执行过程中，就可 以调用已经定义好的用例。 2、表示符号
3.2.2 参与者
参与者运行Use Case，获得系统的某项服务。一个参与 者可以运行多个Use Case，而一个Use Case可以由多个 参与者运行。 参与者的图形表示如图3.3所示。
<<actor>>
参与者名
图3.3 参与者的表示图形
3.2.2 参与者
一个参与者与其他的参与者可以有泛化联系，即一个参与 者可以继承一个更一般的参与者的特性。
3.5.1 Use Case的确定
注意Use Case的大小。 不要只用一个Use Case就把一个系统或子系统 的功能行为全部包括在内，也不要把Use Case 划分得过于琐碎细小。 一般应该把系统或子系统中主要的业务流找出 来，对每一个业务流建立一个相应的Use Case。 为业务处理的各种例外（异常）情况的事件流 单独建立一个相应的Use Case。
3.5.2 建立Use Case模型
应当先建立业务 Use Case模型，然 后再从业务Use Case模型向系统 Use Case模型映射。 注意Use Case图的 层次，从系统到 子系统逐层建立 Use Case图。
实例：图书管理系统
实例：自动饮料售货系统
分析此用例图，
思考： •是不是“取消订单”每次都会调用“查询订单”？ •“查询订单”能否单独执行？
3、包含关系的使用场合 （1）如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一 个用例中，其他用例可以和这个用例建立包含关系。（如之前介绍的自动 饮料售货系统） （2）一个用例的功能太多时，可以使用包含关系建立若干个更小的用例。 （如下页的学生信息管理系统） 4、意义 它有助于在将来实现系统时，确定哪些功能可以重用，在编写代码时就可 实现代码的重用，缩短开发周期。
3.3.2 业务Use Case与系统Use Case
业务Use Case 是指系统提供的业务（Business）功能与参与者（用户）的交互，表现 问题领域中各实体之间的联系和业务往来活动。 业务Use Case用于建立问题领域的业务Use Case模型。 系统Use Case 是指参与者与系统的交互，它表现了系统的功能需求和动态行为。 系统Use Case用于建立系统的Use Case模型。 每一个业务Use Case都要由一组系统Use Case支持。 在系统开发的开端阶段，应把注意力集中在业务Use Case上，在精化阶 段和构建阶段再考虑系统Use Case。
用例名 用例名 Rose
图3.4 Use Case的表示图形
Visio
3.3.3 Use Case图
按照抽象层次，Use Case图可以划分为系统层（最高 层）、子系统层和对象类层（最低层）。 系统层Use Case图描述系统提供的全部服务。 子系统层Use Case图描述子系统提供的服务，它的外部 交互者可以是其他的子系统或高一层的参与者。子系统 层又可以划分为多个层次。 对象类层的Use Case图描述对象类提供的功能片或操作， 它的外部交互者可以是其它对象类或高一层参与者。 在系统的开发过程中，Use Case图可以自顶向下不断精 化，抽象出不同层次的Use Case图。
关系
系统
用例
参与者
Student Grade Manage System RecordGrade
QueryGrade
Teacher
ModifyGrade
Student
图 3.2 学生成绩管理系统的用例图
系统的符号：用一个长方形表示
系统的名称：写在长方形的顶部
参与者画在长方形外部，用例画在长方形的内部。
3.2.3 参与者的确定
确定参与者首先应明确系统的范围，并从应用的角度考 虑系统的作用，确定将有哪些外部事物与系统进行交互。 凡是与系统进行信息交换（包括数据信息和控制信息交 换）的外部事物可以确认为参与者。 系统的外部事物包括：人员、设备、外部系统。 凡是直接使用系统的人员可以确认为参与者。 某些设备与系统相联，直接向系统提供外界信息或在系 统的控制下运行，可以确认为参与者。 凡是与系统相联，并与系统交互的外部系统，可以确认 为参与者。
VerifyIdentity
身份验证用例
CheckPassword Fingerprint
子用例可以出现在父用例出现的任何位置
实例：银行存取款系统
代理客户操作
3.5 Use Case图的应用
3.5.1
3.5.2
Use Case的确定
建立Use Case模型
3.5.1 Use Case的确定
确定Use Case时必须考虑参与者对系统的服务功能的要 求以及参与者与系统的交互过程。 在标识Use Case时需要考虑的问题如下： · 对于每一个已经确定的参与者，系统将有一些什么任务， 提供什么服务。 · 在系统中是否需要传递信息给参与者。 · 参与者是否需要通知系统某些突然的外部变化。 · 系统是否为领域业务提供了正确的行为。 · Case的运行特征是否标识出来了。 Use · Case将支持和维护的系统功能是什么。 Use
3.3 Use Case
3.3.1 3.3.2 3.3.3
Use Case概念 业务Use Case与系统Use Case Use Case图
3.3.1 Use Case概念
Use Case是对系统的用户需求（主要是功能需求）的描述， Use Case表达了系统的功能和所提供的服务。 Use Case描述参与者与系统交互中的对话。它可以用一系 列的步骤来描述，这些步骤构成一个“脚本”（Scenario）。 脚本”的集合就是Use Case。全部的Use Case构成了对于系 统外部是可见的行为的描述。 Use Case只描述参与者和系统在交互过程中做些什么，并 不描述怎样做。 一个参与者可以运行多个Use Case，而一个Use Case可以有 多个参与者运行它。但是，也有的Use Case很难有与它明确 关联的参与者。
3.3.1 Use Case概念
例：一个网上商店，顾客购买商品的过程的Use Case可以用文字列表描述 如下。 购买商品 （1）顾客浏览查询产品分类目录，找出所需要的产品。 （2）顾客准备结算。 （3）顾客填写购货信息（产品信息，数量、送货地址、送货日期）。 （4）系统显示价格和应付款项。 （5）顾客填写信用卡信息。 （6）系统检查信用卡的有效性，确认交易成功。 （7）系统确定发货时间，发出发货通知。 （8）系统发确认成交的电子邮件给顾客。 异常处理：信用卡有效性检查失败。 本Use Case包含了两个脚本：成功的商品交易的 “购买商品” 脚本， “信用卡有效性检查失败”的脚本。
提示：执行基用例时，每次都必须调用被包含用例，被包含用例也可单独 执行。
实例：学生信息管理系统
二、扩展关系 1、概念
用一个用例（可选）扩展另一个用例（基本例）的 功能。 对扩展用例的限制规则：将一些常规的动作放在一 个基本用例中；将可选的或只在特定条件下才执行 的动作放在它的扩展用例中。
பைடு நூலகம்
2、符号表示
基用例
<<extend>>
扩展用例
提示： 扩展用例依赖于基用例。扩展用例不是完整的独立用例， 无法单独执行。
基用例没有扩展也是完整的，只有特定的条件发生了，扩 展用例的行为才被执行。
思考：以下三个用例图中，哪些是正确的，哪些是错误的？
三、泛化关系
泛化将特殊用例和一般用例联系起来。即子用例是父用例的 特化，子用例除具有父用例的特性外，还可以有自己的另外 特性。父用例往往是抽象用例，子用例来代表父用例的更多 明确的形式。
3.1 概述
Use Case图示例，如图3.1所示。 一个有关金融贸易业务活动的Use Case图
图3.1 Use Case图示例
3.2 参与者
3.2.1 3.2.2 3.2.3
系统范围与系统边界 参与者 参与者的确定
3.2.1 系统范围与系统边界
系统（System）是指由多个系统元素有机地结合在一起， 并执行特定的功能以达到特定目标的集合体。计算机系 统是用于解决某个特定的领域问题的。 系统分析的首要任务是问题识别，明确系统范围，划分 系统边界，确定系统的责任。 系统范围（System Scope）是指系统的问题域的目标、 责任、任务和规模，以及系统应提供的服务。 系统边界（System Border）是指一个系统的所有系统元 素与系统以外的事物的分界线。 系统的范围与边界取决于开发的目标、任务和规模。
3.3.3 Use Case图
Use Case图是系统的一个功能模型。它提供计算机系统的高层次的 用户视图，表示以外部参与者的角度来看系统将是怎样使用的。 一个Use Case图包含参与者、Use Case，以及它们之间的联系. 参与者与Use Case之间的联系用实线表示。 Use Case与Use Case之间的联系可以用实箭线或虚箭线表示。
3.4 关系