Page 1 ?
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第六章 用例
什么是用例
创建、包含和扩展用例背后的思想
如何开始一个用例分析
Page 3 ?
当用例视图在外部用户前出现时，它捕获到系统、子
系统或类的行为。它将系统功能划分成对参与者 (即系
统的理想用户 )有用的需求。而交互功能部分被称作用
例。用例使用系统与一个或多个参与者之间的一系列
消息来描述系统中的交互作用。参与者可以是人,也可
以是外部计算机系统和外部进程。
1、概述
Page 4 ?
2,用例 （ use case）
用例是外部可见的一个系统功能单元,这些功能由系统单元所提供,并通过一
系列系统单元与一个或多个参与者之间交换的消息所表达。
用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。
用例的定义包含用例所必需的所有行为 — 执行用例功能的主线次序、标准
行为的不同变形、一般行为下的所有异常情况及其预期反应。从用户角度
来看,上述情况很可能是异常情况；从系统角度来看,它们是必须被描述和处
理的附加情况。
在模型中,每个用例的执行独立于其他用例，虽然在具体执行一个用例功能
时由于用例之间共享对象的缘故可能会造成本用例与其他用例之间有这样
或那样的隐含的依赖关系。每一个用例都是一个纵向的功能块，这个功能
块的执行会和其他用例的执行发生混杂。
Page 5 ?
? 用例的动态执行过程可以用 UML的交互作用来说明，可以用状态图、
顺序图、合作图或非正式的文字描述来表示。用例功能的执行通过类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用
例。
? 在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用户可使用的系统操作。然而，它又与操作不同，用例可以在执
行过程中持续接受参与者的输入信息。用例也可以被像子系统和独立类这样的小单元所应用。一个内部用例表示了系统的一部分对另一部
分呈现出的行为。例如，某个类的用例表示了一个连贯的功能，这个功能是该类提供给系统内其他有特殊作用的类的。一个类可以有多个
用例。
? 用例是对系统一部分功能的逻辑描述，它不是明显的用于系统实现的构件。非但如此，每个用例必须与实现系统的类相映射。用例的行为
与类的状态转换和类所定义的操作相对应。只要一个类在系统的实现中充当多重角色，那么它将实现多个用例的一部分功能。设计过程的
一部分工作即在不引入混乱的情况下，找出具有明显的多重角色的类，以实现这些角色所涉及的用例功能。用例功能靠类间的协作来实现
。
Page 6 ?
3、用例的可视化表示
Maintain ScheduleMaintain Curriculum Request Course Roster
在 UML中，用例表示为一个椭圆，用例的名字可以放
在椭圆的里面，也可以放在椭圆的下面。
Page 7 ?
4、参与者 (actor)
? 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他
系统的理想化概念。作为外部用户与系统发生交互作用，这是参与者
的特征。在系统的实际运作中，一个实际用户可能对应系统的多个参
与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者
的不同实例。
? 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交
互作用（因此也与用例所在的系统或类发生了交互作用），而参与者
的内部实现与用例是不相关的,参与者可以被一组定义它的状态的属性
充分描述。
? 参与者可以通过泛化关系来定义,在这种泛化关系中，一个参与者的抽
象描述可以被一个或多个具体的参与者所共享。
? 参与者可以是人、另一个计算机系统或一些可运行的进程。在图中，
参与者用一个名字写在下面的小人表示。如下图所示：
Student Billing System
Page 8 ?
5、用例模型（ use case model）
用例
参与者 参与者
用例分析的一个好处是它能够展现出系统和外部世界之间的边界。参与
者是典型的系统外部实体，而用例是典型的属于系统内部。系统的边界
用一个矩形来代表，里面写上系统的名字。系统的用例装入矩形之内。
系统
用例的发起者在用例图的左侧，接受者在用例图的右侧。参与者的名字
放在参与者图标的下方。关联线连接参与者和用例并且表示参与者与用
例之间有通信关系。关联线是实线，和类之间的关联线类似。
Page 9 ?
Page 10 ?
6、包含用例
虽然每个用例的实例是独立的，但是一个用例可以用其他的
更简单的用例来描述。这有点像一个类可以通过继承它的超
类并增加附加描述来定义。一个用例可以简单地包含其他用
例具有的行为，并把它所包含的用例行为做为自身行为的一
部分，这被称作包含关系。在这种情况下，新用例不是初始
用例的一个特殊例子，而且不能被初始用例代替。
Page 11 ?
包含关系可以用含有关键字 <<include>>的带箭头的虚线表示。包含关系
箭头指向被包含的用例。
打开销售机
<<include>>
向自动销售机
中放物品
<include>>
关闭销售机
Page 12 ?
7、扩展用例
一个用例也可以被定义为基用例（原来的用例）的增量扩展,这叫做扩展
关系。同一个基用例的几个扩展用例可以在一起应用。基用例的扩展增
加了原有的语义,此时是本用例而不是扩展用例被作为例子使用。
扩展点（ extension points）：扩展只能发生在基用例的序列中的某几个
具体指定点上，这个点被称为扩展点。
Page 13 ?
扩展关系可以用含有关键字 <<extend>>的带箭头的虚线表示。扩展关系箭头指向
被扩展的用例。在基用例中，扩展点出现在,extension point”的下方。
打开销售机<<include>>
向自动销售机中放
物品 <include>>
关闭销售机extension point
在放入物品前
补充物品按照
物品的销售情况
<extend>>
Page 14 ?
一个用例也可以被特别列举为一个或多个子用例，这被称做用例泛化。当父
用例能够被使用时，任何子用例也可以被使用。
用例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指向父用例。
8,用例泛化
买一杯饮料
△
买一罐饮料
买饮料
Page 15 ?
? 参与者之间也像用例一样可能存在泛化关系。
9、参与者 泛化
? 参与者泛化与用例泛化关系的表示法相同，都用一个三角箭头从子参与者指向
父参与者。
财务经理项目经理
经理
人事经理
△
Page 16 ?
关系 功能 表示法
关联 参与者与其参与执行的用例之间的通信途
径
扩展 在基础用例上插入基础用例不能说明的扩
展部分
用例泛化 用例之间的一般和特殊关系，其中特殊用
例继承了一般用例的特性并增加了新的特
性
包括 在基础用例上插入附加的行为，并且具有
明确的描述
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<include>>
Page 17 ?
用例的适用性
? 用例首先用于需要响应客观事件的系统。它们能用于提供
了一个有很容易理解的目标的清楚的行为者的环境。当结
果不可定义或不清晰时不能用用例。意思是如果目标成功
或目标失败不能有一个明确的定义，那么用例不能用来捕
获需求。
? 然而说到这，现在大部分对象方法都使用用例。因为用例
被证明是捕获需求的非常有效的机制。
Page 18 ?
总结
用例以一种可读的、可驳倒的格式捕获需求。用例是系统客观必需机能
的可驳倒的描述。
可驳倒的意思是当你说明用例时期望从用户和开发者处获得关于用例品
质的反馈。
用例并没有从一开始就就明确的定义，它主要的开发顺序如下：
1,指出行为者
2,指出行为者的目标
3,指出每一行为者：目标语句对的成功或失败的意思
4,指出每一用例的主要的成功的情节
5,在细化阶段，指出失败的条件及可恢复 /不可恢复的情节
只有做到了第四步才能决定哪一些的东西在 Use Case中逐步开发出来。
总而言之，用例是非常有效的需求捕获技术，它能使需求变得容易回顾
，并且避免在需求中有实现细节的偏好出现。
UML及软件建模
主讲人, 李 唯
clx7000@163.com
Page 2 ?
第六章 用例
什么是用例
创建、包含和扩展用例背后的思想
如何开始一个用例分析
Page 3 ?
当用例视图在外部用户前出现时，它捕获到系统、子
系统或类的行为。它将系统功能划分成对参与者 (即系
统的理想用户 )有用的需求。而交互功能部分被称作用
例。用例使用系统与一个或多个参与者之间的一系列
消息来描述系统中的交互作用。参与者可以是人,也可
以是外部计算机系统和外部进程。
1、概述
Page 4 ?
2,用例 （ use case）
用例是外部可见的一个系统功能单元,这些功能由系统单元所提供,并通过一
系列系统单元与一个或多个参与者之间交换的消息所表达。
用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。
用例的定义包含用例所必需的所有行为 — 执行用例功能的主线次序、标准
行为的不同变形、一般行为下的所有异常情况及其预期反应。从用户角度
来看,上述情况很可能是异常情况；从系统角度来看,它们是必须被描述和处
理的附加情况。
在模型中,每个用例的执行独立于其他用例，虽然在具体执行一个用例功能
时由于用例之间共享对象的缘故可能会造成本用例与其他用例之间有这样
或那样的隐含的依赖关系。每一个用例都是一个纵向的功能块，这个功能
块的执行会和其他用例的执行发生混杂。
Page 5 ?
? 用例的动态执行过程可以用 UML的交互作用来说明，可以用状态图、
顺序图、合作图或非正式的文字描述来表示。用例功能的执行通过类之间的协作来实现。一个类可以参与多个协作，因此也参与了多个用
例。
? 在系统层，用例表示整个系统对外部用户可见的行为。一个用例就像外部用户可使用的系统操作。然而，它又与操作不同，用例可以在执
行过程中持续接受参与者的输入信息。用例也可以被像子系统和独立类这样的小单元所应用。一个内部用例表示了系统的一部分对另一部
分呈现出的行为。例如，某个类的用例表示了一个连贯的功能，这个功能是该类提供给系统内其他有特殊作用的类的。一个类可以有多个
用例。
? 用例是对系统一部分功能的逻辑描述，它不是明显的用于系统实现的构件。非但如此，每个用例必须与实现系统的类相映射。用例的行为
与类的状态转换和类所定义的操作相对应。只要一个类在系统的实现中充当多重角色，那么它将实现多个用例的一部分功能。设计过程的
一部分工作即在不引入混乱的情况下，找出具有明显的多重角色的类，以实现这些角色所涉及的用例功能。用例功能靠类间的协作来实现
。
Page 6 ?
3、用例的可视化表示
Maintain ScheduleMaintain Curriculum Request Course Roster
在 UML中，用例表示为一个椭圆，用例的名字可以放
在椭圆的里面，也可以放在椭圆的下面。
Page 7 ?
4、参与者 (actor)
? 参与者是与系统、子系统或类发生交互作用的外部用户、进程或其他
系统的理想化概念。作为外部用户与系统发生交互作用，这是参与者
的特征。在系统的实际运作中，一个实际用户可能对应系统的多个参
与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者
的不同实例。
? 每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交
互作用（因此也与用例所在的系统或类发生了交互作用），而参与者
的内部实现与用例是不相关的,参与者可以被一组定义它的状态的属性
充分描述。
? 参与者可以通过泛化关系来定义,在这种泛化关系中，一个参与者的抽
象描述可以被一个或多个具体的参与者所共享。
? 参与者可以是人、另一个计算机系统或一些可运行的进程。在图中，
参与者用一个名字写在下面的小人表示。如下图所示：
Student Billing System
Page 8 ?
5、用例模型（ use case model）
用例
参与者 参与者
用例分析的一个好处是它能够展现出系统和外部世界之间的边界。参与
者是典型的系统外部实体，而用例是典型的属于系统内部。系统的边界
用一个矩形来代表，里面写上系统的名字。系统的用例装入矩形之内。
系统
用例的发起者在用例图的左侧，接受者在用例图的右侧。参与者的名字
放在参与者图标的下方。关联线连接参与者和用例并且表示参与者与用
例之间有通信关系。关联线是实线，和类之间的关联线类似。
Page 9 ?
Page 10 ?
6、包含用例
虽然每个用例的实例是独立的，但是一个用例可以用其他的
更简单的用例来描述。这有点像一个类可以通过继承它的超
类并增加附加描述来定义。一个用例可以简单地包含其他用
例具有的行为，并把它所包含的用例行为做为自身行为的一
部分，这被称作包含关系。在这种情况下，新用例不是初始
用例的一个特殊例子，而且不能被初始用例代替。
Page 11 ?
包含关系可以用含有关键字 <<include>>的带箭头的虚线表示。包含关系
箭头指向被包含的用例。
打开销售机
<<include>>
向自动销售机
中放物品
<include>>
关闭销售机
Page 12 ?
7、扩展用例
一个用例也可以被定义为基用例（原来的用例）的增量扩展,这叫做扩展
关系。同一个基用例的几个扩展用例可以在一起应用。基用例的扩展增
加了原有的语义,此时是本用例而不是扩展用例被作为例子使用。
扩展点（ extension points）：扩展只能发生在基用例的序列中的某几个
具体指定点上，这个点被称为扩展点。
Page 13 ?
扩展关系可以用含有关键字 <<extend>>的带箭头的虚线表示。扩展关系箭头指向
被扩展的用例。在基用例中，扩展点出现在,extension point”的下方。
打开销售机<<include>>
向自动销售机中放
物品 <include>>
关闭销售机extension point
在放入物品前
补充物品按照
物品的销售情况
<extend>>
Page 14 ?
一个用例也可以被特别列举为一个或多个子用例，这被称做用例泛化。当父
用例能够被使用时，任何子用例也可以被使用。
用例泛化与其他泛化关系的表示法相同，都用一个三角箭头从子用例指向父用例。
8,用例泛化
买一杯饮料
△
买一罐饮料
买饮料
Page 15 ?
? 参与者之间也像用例一样可能存在泛化关系。
9、参与者 泛化
? 参与者泛化与用例泛化关系的表示法相同，都用一个三角箭头从子参与者指向
父参与者。
财务经理项目经理
经理
人事经理
△
Page 16 ?
关系 功能 表示法
关联 参与者与其参与执行的用例之间的通信途
径
扩展 在基础用例上插入基础用例不能说明的扩
展部分
用例泛化 用例之间的一般和特殊关系，其中特殊用
例继承了一般用例的特性并增加了新的特
性
包括 在基础用例上插入附加的行为，并且具有
明确的描述
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<include>>
Page 17 ?
用例的适用性
? 用例首先用于需要响应客观事件的系统。它们能用于提供
了一个有很容易理解的目标的清楚的行为者的环境。当结
果不可定义或不清晰时不能用用例。意思是如果目标成功
或目标失败不能有一个明确的定义，那么用例不能用来捕
获需求。
? 然而说到这，现在大部分对象方法都使用用例。因为用例
被证明是捕获需求的非常有效的机制。
Page 18 ?
总结
用例以一种可读的、可驳倒的格式捕获需求。用例是系统客观必需机能
的可驳倒的描述。
可驳倒的意思是当你说明用例时期望从用户和开发者处获得关于用例品
质的反馈。
用例并没有从一开始就就明确的定义，它主要的开发顺序如下：
1,指出行为者
2,指出行为者的目标
3,指出每一行为者：目标语句对的成功或失败的意思
4,指出每一用例的主要的成功的情节
5,在细化阶段，指出失败的条件及可恢复 /不可恢复的情节
只有做到了第四步才能决定哪一些的东西在 Use Case中逐步开发出来。
总而言之，用例是非常有效的需求捕获技术，它能使需求变得容易回顾
，并且避免在需求中有实现细节的偏好出现。
