参与者父类
8
参与者之间的关系


参与者也是类，因此它拥有与类相同的关系 主要是继承（泛化）关系。 参与者之间大量地反映出的‚权限‛关系。 公司管理系统
常规操作
职 员
销售经理
销售管理
人事经理
人事管理
9
参与者之间的关系的泛化
将销售经理与人事经理看成是特殊的参与者，不仅 有职员的功能，还有其特殊职务所赋予的功能，是职 员的泛化。

用例驱动的方法论。 用例是各种交互的动作序列之间的说明与描述。 用例的描述、表示与命名方法、规律。 用例描述的是系统功能性的需求。 理解用例之间相互关系（泛化、包含、扩展）。 脚本是用例的实例。 参与者在系统中的含义。参与者之间同样有泛化关系。 用例描述是用例的主要部分。 用例描述无统一的标准。 用例分析结果与分析人员的水平与领域知识相关
基本用例
扩展用例1
扩展用例2
19
§3.4.3 扩展关系（续）

一个用例相对于包含和扩展关系来讲是变换的。 例如：网上买东西
对应于包含关系来讲是基本用例 对应于扩展关系来讲是扩展用例
Customer
Buy Merchandise
<<extend >>
<<include>>
Browse Web Site
由以上例子看出： 其用例描述并无一个固定的模式可循，各自有理解和侧重， 关键是要多加练习。
25
§3.7 寻找用例的方法

用例分析可遵循的步骤：
1、找出系统外部的参与者和外部系统，确定系统的边界； 2、确定每一个参与者所期望的系统行为； 3、命名这些系统行为为用例； 4、使用泛化\包含\扩展关系处理系统行为的公共或变更部分； 5、编制每一个用例的脚本； 6、绘制用例图； 7、区分主事件流和异常事件流，单独处理异常事件流用例； 8、细化用例图，去掉重复与冲突；
11
§3.3 脚本（scenario）


脚本又称为情景、场景、情节、剧本等 在UML中，脚本贯穿用例的一条单一路径。 脚本的定义：脚本是用例的实例(instance)。 脚本与用例之间是对象与类的关系。 例如：针对‘取钱’的用例，脚本就会有 1、正常完成取钱的脚本。 2、账户拒绝、取不出钱的处理脚本。 3、取出钱不对后的处理脚本。 但是有1、2、3、…构成了一个用例。 脚本的描述：一个脚本是用具体的文字加以描述的。

取钱
WithDrawe Money
用例名
3
§3.1 用例（续）

用例的特点：
1、从系统外看系统功能。 2、描述一个系统可见需求，对应于一个具体的用户目标。 3、是系统行为的动态描述，属于动态建模范畴。

软件开发过程是由用例驱动的。 用例将软件开发过程中各个阶段捆绑在一起， 以实现功能的系统行为作为所达成的契约。 例如：来看银行对外业务系统的简单描述： 查询账户余额 列出业务菜单项 转账 存款与支付 登录与退出系统
5
§3.1 用例（续三）
寻找用例及识别用例的方法 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统 的某种信息？若是又是如何完成这些操作？ 参与者是否会将外部的某些事件通知系统的？ 系统中发生的事件是否会通知参与者？ 是否存在影响系统的外部事件？
6
§3.2 参与者（actor）

用‘启发性原则’检验用例分析的方法：
和用户交互 和系统交互 参与者与用例的关系不可分割。
26
§3.8 常见问题分析

问题：同学们自己看书即可，不再赘述。 根据看书关注思考一下问题？ 1、用例的粒度问题？ 2、组合用例还是分解用例？ 并注意着重理解细化用例与合并用例。
27
§3.9 第三章用例章节小结
UML 面向对象技术教程
第三章 用例及用例图
1
本章中所涉及的内容


用例 参与者 脚本 用例间关系（泛化、包含、扩展、三种关系 的比较） 用例图 用例的描述 寻找用例的方法 常见问题的分析 小结
2
§3.1 用例
用例（use case） 用例就是对包含变量在内的一组活动序列的描述，系统执 行这些活动，并产生传递特定参与者的价值的可观察结果。 定义一：用例是对一个活动者(actor)使用系统的一项功 能时所进行的交互过程的一个文字描述。 定义二：用例是系统、子系统或类和外部的参与者(actor) 交互动作序列的说明，包括可选的动作序列和会 出现异常的动作序列。 如何在UML中表示用例： 用例用一个椭圆来表示，用例名下在下面，其用例名往 往是一个动宾结构。如‚取钱‛是一个用例,它的表示如 下：
在UML中表示法
<<extend>>
（包含参与者之间的泛化表示方法） 包含 在基础用例上插入附加的行为
<<include>>
______________________________________________
14
§3.4 用例间关系（续二）

关联关系（association） 用来描述参与者与用例之间的通信。 通俗地讲就是参与者与用例之间所形成的关系。
4
§3.1 用例（续二）




用例是UML建模过程中一个非常重要概念，它处于核 心位置。 不能指望在一个系统分析中列出全部的用例。 用例是外部可见的一个系统功能单元。用途在于不 揭示系统内部构造的情况下定义一组连贯的行为。 用例可大可小，但它必须是对一个具体的用户实现 目标的完整描述。 用例的动态执行过程 在UML中可以交互表现在‘用例图’、‘顺序图’、 ‘协作图’ 或文字描述来表示。功能的执行过程用 ‚类‛之间的协作来实现。
Add Order to Warehouse Syatem 对应于包含关系来讲是包含用例
20
对应于包含关系来讲是基本用例 对应于扩展关系来讲是扩展用例

例如：还书的扩展用例
借书学生
还书
缴纳过期或破损罚款
21
§3.4.4 用例的泛化、包含、扩展关系的比较
关系是模型元素之间的语义联系。 关联是两个或多个类元（classfier）之间的关系 类元包括：类、参与者、组件、数据类型、接口、结点、 信号、子系统、用例等，在UML中用 表示关联。 泛化表示的是两个类元之间（通用和特殊）的关系。 二者的结构和行为上一致，其特殊类元包含更多信息。在 UML中用 表示泛化，特殊指向通用。 依赖关系的二种形式：包含和扩展 依赖是指两个元素或元素类集之间（行为涵盖）的关系。 它们之间存在依赖关系，被依赖元素目标元素，依赖元 素源元素，源元素随目标元素改变而调整。 包含：基本指向包含，UML中用 <<include >> 表示。 扩展：扩展指向基本，UML中用 <<extend >> 表示。 22
职 员
常规操作
销售经理
销售管理
人事经理
人事管理
10
寻找参与者的参考方法





系统开发出来后，是谁使用系统的主要功能。 谁需要借助系统来完成日常工作。 系统需要从哪些人或其他系统中获取数据。 系统会为哪些人或其他系统提供数据。 系统会与哪些系统交互？这些系统分为两类，一是 该系统要使用的系统，二是启动该系统的系统，包 括其他软件。 系统由谁来维护和管理的，以保证系统处于工作状 态？ 系统控制的硬件设备有哪些？ 谁对系统产生的结果感兴趣2 参与者（actor）续
参与者事实上就是一个类。
继承关系 泛化关系（在系统分析阶段是相等的） 参与者可以被一组定义它状态的属性加以描述，代 表一个角色。 参与者的重要性有分级：主要角色、次要角色 参与者的性质有主动参与（执行主要功能）、 被动参与（执行次要功能）。
参与者子类

12
§3.4 用例间关系
针对用例的描述要遵循的几个要点： 清楚地确定系统的边界。 用标准模板书写用例说明。 关注用例的真正目的。 不能将用例说明与用户接口设计相混淆。 实现使用例交互与用户接口之间的松散耦合。 不要在用例与用户接口之间建立通信。
13
§3.4 用例间关系（续）

用例之间关系有以下几种： 关系 所表示的功能 关联 参与者与用例之间通信 扩展 在基础用例上插入扩展部分 泛化 表示用例间的一般和特殊关系
24

§3.6 用例的描述（续）

p30表3.2 用例的描述格式（参考的描述问题样本） p31表3.3 用例处理订单的描述（参考的具体） P31例3.5 Withdraw Case的用例描述(缺少系统行为) p32例3.6 Withdraw Case的用例描述(缺少参与者行为) p32例3.7 Buy something 的用例描述(界面描述过于详细) p33例3.8 Buy something 的用例描述(描述冗长，应合并)

§3.5 用例图（use case diagram）
显示一组用例、参与者以及它们之间关系的图。
在UML中，由若干个用例图组成一组用例模型。 用例图又称为‘用户模型图’，属于OOA的第一步。 是系统功能细节的最高形式。只关注系统功能不关心内部 实现细节。 教材上的用例图例子可见P29中图3.9 金融贸易系统用例 图，这个例子是使用Rational Rose 2003绘制的。 例子：银行日常业务用例图：
用 例 参与者
15
§3.4.1 泛化关系


泛化（generalization） 代表一般和特殊的关系。 例如：付款、订票等。
在UML中泛化关 系的表示，由子 用例指向父用例
父用例
付款
子用例，它 继承了父用例 的行为和含义， 同时也可以增 加新行为