第3章 用例图
合集下载
第3章 用例图及其应用
1 基本概念
1.2 用例
– 定义
对一组动作序列的描述,系统通过执行这一组动作序 列为参与者产生一个可观察的结果
– 用例特征
说明了系统具有的一种行为模式 说明了一个参与者与系统执行的一个相关的事务序列 提供了一种获取系统需求的方法 提供了一种与最终的用户和领域专家进行沟通的方法 提供了一种测试系统的方法
– 2)包含关系 )
是一种构造型关系,它将一个基用例连接到一个包含用 例 UML1.1中为使用关系,在1.3中改为包含关系 包含关系在一个用例中重用另一个用例中的步骤 包含关系用带箭头的虚线表示,沿线上加一个用双尖括 号括起来的"include"
2 关系及其应用
2.4 关系的扩展
使用包含关系的三种情况: a.如果有多个用例,并且这些用例包含大量类似 的行为,应该考虑将这些类似的行为通过包含关 系包含到用例中 b.对两个或多个互相独立的用例建模时做了重复 的工作,可以通过包含关系包含这些重复的工作 c.如果某个行为可能会引入冗余,或者,当行为 发生变化时可能导致不一致性,这时,应该对这 种行为进行孤立建模并将它包含到用例中
3 参与者规范及应用
3.1 参与者规范
– Rose在实现中对参与者和类使用相同的规 范窗口,包括如下一些标签:
General Detail Operations Attributes Relations Components Nested Files
3 参与者规范及应用
3.1 参与者规范
– General标签
Name Stereotype Documentation
3 参与者规范及应用
3.1 参与者规范
– Detail标签
Multiplicity (参与者基数)
UML概述
UML建模基础——UML概述东软人才实训中心3 Sept. 2008©Neusoft Confidential课程结构1第五章：状态图和活动图2第三章：类图1第四章：交互图1第二章：用例图1第一章：UML 概述、Rose 简介课时（H ）内容培训目标•能够使用Rose工具画UML类图•能够看懂用UML表示的设计第一章：UML 概述、Rose 简介学时：1学时教学方法：讲授ppt ＋上机练习目标:本章旨在向学员简要介绍UML建模的重要性、UML的概念模型,通过本课的学习，学员应该掌握如下知识：1）了解UML的概念模型2）简要介绍UML的“4+1view ”3）了解Rose工具UML概述•什么是UML?–UML: 统一建模语言Unified Modeling Language–UML是由Rational公司三位世界级面向对象技术专家Grady Booch，Ivar Jacobson和Jim Rumbaugh提出的。
–UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。
•什么是UML?–不是一种可视化编程语言，而是一种可视化建模语言–不是工具或知识库的规格说明，而是建模语言的规格说明，是一种表示的标准–不是过程，也不是方法，但是允许任何一种过程和方法使用它•什么是模型?–模型就是真实世界的简化–为我们提供一个系统的原型•为什么要建模?–为了更好的理解我们将要或正在开发的系统–是把复杂的系统变成小的系统，采用“各个击破”的原则逐一解决–因为我们通常无法理解一个复杂系统的全部–模型能为我们做什么?•帮助我们对系统进行可视化•允许我们详细说明系统的结构或行为•给出一个指导我们构造系统的模板•对我们做出的决策进行文档化业务流程计算机系统可视化建模可视化建模就是用标准的图形表示法来建模“建模获取系统的关键部分”UML•什么是可视化建模?可视化建模的作用•可视化建模获取业务流程–用例（use case）分析是一种从用户的角度获取业务流程的技术–使用相同的语言，不至于产生歧义–用例分析能让分析师在构建系统之前理解要构建什么可视化建模的作用(续)•可视化建模是一个交流工具–使用相同的语言，不至于产生歧义业务领域计算机领域Logical ViewPhysical View User InterfaceBusiness Logic Database Java JSPC++ JavaSQL•管理复杂性–把3000多个类放在一张图中不好–可视化建模的“包”（package）•把元素模型化成有意义的组合•为不同的人提供不同级别的抽象–软件构架(architecture)•促进复用(reuse)–复用是软件的“圣杯”–不止是复用代码，而是复用建立原始工件时需要的所有分析、设计、实现、测试、文档化–可以有一个类复用、多个类（或一个组件）的复用、应用模式等复用方式–可视化建模让你从复用的角度看，如果想复用工件，什么是可用的UML的概念模型•UML的概念模型–UML建模的三个主要元素•构造块：事物、关系、图•规则：命名、范围、可见性、完整性、执行•公共机制：规范说明、通用划分、扩展机制•UML元素–构造块–事物•对模型中最具有代表性的成分的抽象–关系•把事物结合在一起–图•聚集了相关的事物•UML元素–构造块–事物–结构事物：通常是UML模型的静态部分，描述概念或物理元素•类•接口•用例：通常代表一个需求•协作：表示一个用例的实现•主动类：至少拥有一个进程或线程的类•组件：系统中物理的、可替代的部件，如源代码文件•节点：运行时存在的物理元素，如一个设备•UML元素–构造块–事物（续）–行为事物：是UML模型的动态部分，是模型中的动词•交互（interaction）：可描述一个对象群体的行为或单个操作的行为•状态机（state machine）：可描述单个类或一组类之间协作的行为–分组事物：是UML中的组织部分•包（package）–注释事物：是UML中的注释部分•注解（note）•UML元素–构造块–关系–关系•依赖（dependency）：一个事物发生变化会影响到另一个事物。
第03章 用例和用例图
5
用例的特点 ① 用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的实现 方式。
储蓄系统
开户 存款
√
√ √ √
取款
转帐
6
用例的特点
② 用例描述用户提出的一些可见需求，对应 一个具体的用户目标。
储蓄系统 √ √ √ 开户 存款 取款 转帐
√
×
数据上传
7
用例的特点 ③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
泛化关系代表一般与特殊的关系, 与继承类似.
在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
20
3.4.2 泛化关系
21
3.4.3 包含关系
包含关系是指一个用例(基本用例)的行为包含了另一 个用例(包含用例)的行为.
包含关系是依赖关系的版型, 但其含义更多.
3.6 用例的描述
用例阐述：写用例规约
用例规约：更进一步的精度
用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值
用例图是骨架，而用例规约则是其内在的血肉
43
3.6 用例的描述
谁来写用例文档 ?
最完美：业务人员接受训练，写出优美的 用例文档 最现实：业务人员提供素材，开发人员写 用例文档 最糟糕：业务人员不管，完全由开发人员 杜撰
3
3.7 寻找用例的方法
3.8 用例的常见问题
15
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本.
第3章用例及用例图-案例学习资料
16
● ① 找出系统外部参与者，确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
① 管理员选择进入管理界面，用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1：密码出错。
⑤ 进入管理界面，系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程，管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1：
– 有一个爱书之人，家里各类书籍已过千册，平时又 时常有朋友外借，因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号，以修改信息，但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录，可对外借情况列出打印。另外，还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
● ① 找出系统外部参与者，确定系统边界和范围。
17
● ② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更 入住登记 退房结帐 选择课程 信息查询
18
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
19
● ④ 确定各用例之间的关系(泛化，包含，扩展)。
13
● ⑥ 编制用例说明。
● 用例：增加课程
●参与者：管理员
●操作流：
① 管理员选择进入管理界面，用例开始。
② 系统提示输入管理员密码。
③ 管理员输入密码。
④ 系统检验密码。
A1：密码出错。
⑤ 进入管理界面，系统显示当前所建立的全部课程信息。
⑥ 管理员选择增加课程，管理员输入新课程信息。
⑦系统验证是否与已有课程冲突。
2
3.7 业务用例图
4
3.8 实例
• 案例1：
– 有一个爱书之人，家里各类书籍已过千册，平时又 时常有朋友外借，因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档，实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号，以修改信息，但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录，可对外借情况列出打印。另外，还 希望能够对书籍的购买金额、册数按特定时限进行 统计。
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例：客房预订 ●参与者：柜台工作人员 ●说明：
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
第3章 Rational Rose概述
2015-3-22 西安财经学院管理学院
Rational Rose窗口介绍
浏览器中包含四个视图： • Use Case视图 • Logical视图 • Component视图 • Deployment视图
•
•
Rose浏览器的功能非常强大，并且易于操作，具有 很强的拖放功能，可以自动地更新模型中的元素等。
2015-3-22
西安财经学院管理学院
Rose模型视图
• Logical视图关注的是系统的逻辑结构。在Logical 视图中，要标识系统中的构件，检查系统信息和功 能，检查组件之间的关系。重复使用是一个主要目 的。通过认真指定类的信息和行为、组合类，以及 检查类和包之间的关系，就可以确定重复使用的类 和包。完成多个项目后，就可以将新类和包加进重 复使用库中。
2015-3-22
西安财经学院管理学院
Rational Rose窗口介绍
5 框图窗口
• 框图窗口是Rose的主要编辑窗口，可以在框图窗 口中浏览模型中的一个或者几个UML框图。如果改 变框图中的元素中，Rose自动更新浏览器中对应的 内容。同样，如果在浏览器中改变元素时，Rose自 动更新相应框图。这样Rose就可以保证模型的一致 性。
Rational Rose窗口介绍
2 浏览器
浏览器功能如下： 浏览器采用的是树形结构， • 增加模型元素 如下图所示，用于在Rose • 浏览现有模型元素间的关 模型中迅速漫游。浏览器 系 • 移动模型元素 中显示了模型中的所有角 • 更名模型元素 色、使用案例、类、组件 • 将模型元素加进框图 等。 • 将文件或URL链接到元素 • 将元素组成包 • 访问元素的详细规范 • 打开框图
用于查看错误和报告各个命令的结果西安财经学院管理学院2016228绘制类图右键单击类图从弹出的菜单中选择openspecificatio双击要设定的属性从type下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228右键单击类图从弹出的菜单中选择openspecification双击要设定的属性从return下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228绘制类图时的良好习惯属性和操作的文档说明在设定它们的值类型的窗体中西安财经学院管理学院2016228西安财经学院管理学院2016228绘制关系系统之间的类是有关联的在uml中可以用关系来描述类之间的关系类之间的关系主要有以下五种
Rational Rose窗口介绍
浏览器中包含四个视图： • Use Case视图 • Logical视图 • Component视图 • Deployment视图
•
•
Rose浏览器的功能非常强大，并且易于操作，具有 很强的拖放功能，可以自动地更新模型中的元素等。
2015-3-22
西安财经学院管理学院
Rose模型视图
• Logical视图关注的是系统的逻辑结构。在Logical 视图中，要标识系统中的构件，检查系统信息和功 能，检查组件之间的关系。重复使用是一个主要目 的。通过认真指定类的信息和行为、组合类，以及 检查类和包之间的关系，就可以确定重复使用的类 和包。完成多个项目后，就可以将新类和包加进重 复使用库中。
2015-3-22
西安财经学院管理学院
Rational Rose窗口介绍
5 框图窗口
• 框图窗口是Rose的主要编辑窗口，可以在框图窗 口中浏览模型中的一个或者几个UML框图。如果改 变框图中的元素中，Rose自动更新浏览器中对应的 内容。同样，如果在浏览器中改变元素时，Rose自 动更新相应框图。这样Rose就可以保证模型的一致 性。
Rational Rose窗口介绍
2 浏览器
浏览器功能如下： 浏览器采用的是树形结构， • 增加模型元素 如下图所示，用于在Rose • 浏览现有模型元素间的关 模型中迅速漫游。浏览器 系 • 移动模型元素 中显示了模型中的所有角 • 更名模型元素 色、使用案例、类、组件 • 将模型元素加进框图 等。 • 将文件或URL链接到元素 • 将元素组成包 • 访问元素的详细规范 • 打开框图
用于查看错误和报告各个命令的结果西安财经学院管理学院2016228绘制类图右键单击类图从弹出的菜单中选择openspecificatio双击要设定的属性从type下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228右键单击类图从弹出的菜单中选择openspecification双击要设定的属性从return下拉框中选择数据类型在exportcontrol分组框中选择可见性类型西安财经学院管理学院2016228绘制类图时的良好习惯属性和操作的文档说明在设定它们的值类型的窗体中西安财经学院管理学院2016228西安财经学院管理学院2016228绘制关系系统之间的类是有关联的在uml中可以用关系来描述类之间的关系类之间的关系主要有以下五种
第3章 统一建模语言UML
第3章统一建模语言UML简介本章目录第3章统一建模语言UML简介.............................................................. 错误！未定义书签。
3.1 UML概述 (1)3.1.1 UML的产生背景 (1)3.1.2 什么是UML (2)3.1.3 UML中的视图 (3)3.2 UML的构成 (4)3.2.1 UML的体系结构 (4)3.2.2 UML的模型元素 (5)3.2.3 UML的模型结构 (5)3.2.4 UML的模型图 (6)3.2.5 UML建模规则 (7)3.2.6 UML的公用机制 (8)3.3 一个UML的例子 (8)3.3.1 用例图 (9)3.3.2 活动图 (9)3.3.3 顺序图 (10)3.3.4 协作图 (11)3.3.5 类图 (12)3.3.6 状态图 (12)3.3.7 组件图 (13)3.3.8 部署图 (13)建模是为软件开发服务的，因此，如果模型所包含的信息足够完备，就可以以这些信息为基础，进行软件系统的建造。
统一建模语言UML是一种总结了以往建模技术的经验并吸收当今优秀成果的标准建模技术，利用UML表达的软件模型，可以直接和某种设计语言建立映射关系，通过UML建造工具，将UML模型转换为对应的程序设计语言源代码框架。
本章简要地回顾了UML的产生背景与UML的视图，重点介绍UML的体系结构和建模规则等内容。
3.1 UML概述UML是一个通用的可视化建模语言，是用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。
其中制品是指软件开发过程中产生的各种产物，例如模型、源代码、测试用例等。
UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域及各种开发工具。
3.1.1 UML的产生背景早在20世纪70年代就陆续出现了面向对象的建模方法，在80年代末到90年代中期，各种建模方法如雨后春笋般出现，从不到10种增加到50多种。
第3章 信息系统分析与设计 用例及用例图
第48页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
第49页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
①.泛化关系 ②.包含关系 ③.扩展关系
第31页，共87页。
1. 泛化关系
参与者与参与者之间，用例与用例之间存在一般与 特殊的泛化关系。
第32页，共87页。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要用到 另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
②.在基用例执行的过程中，被包含的用例一定要被执行；
扩展关系如果条件不为真，扩展用例可以不执行。
③.包含关系中的基用例必须依赖被包含的用例，它不能
独立存在；扩展关系中的基用例可以独立存在。
第37页，共87页。
3.6 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能，通 过一组用例可以描述软件系统能够给用户提供的功 能。
3. 参与者的表示 参与者可以表示为下面三种形式。
第23页，共87页。
4. 参与者之间的关系 参与者之间可以有泛化关系。
第24页，共87页。
5. 参与者的特性 参与者具有以下特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系 ③.参与者与系统之间存在交互接口
第25页，共87页。
3.4 参与者与用例之间的关系
3.5 用例之间的关系 3.6 用例图
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
● ② 确定各参与者所期望的系统行为。
第49页，共87页。
3.8 发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。
② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
①.泛化关系 ②.包含关系 ③.扩展关系
第31页，共87页。
1. 泛化关系
参与者与参与者之间，用例与用例之间存在一般与 特殊的泛化关系。
第32页，共87页。
2. 包含关系
两个用例之间，一个用例(基用例)的行为要用到 另外一个用例(包含用例)的行为。 包含关系用依赖关系的<<include>>构造型来 表示。
②.在基用例执行的过程中，被包含的用例一定要被执行；
扩展关系如果条件不为真，扩展用例可以不执行。
③.包含关系中的基用例必须依赖被包含的用例，它不能
独立存在；扩展关系中的基用例可以独立存在。
第37页，共87页。
3.6 用例图
1. 用例图的作用
用例图用来描述软件需求模型中的系统功能，通 过一组用例可以描述软件系统能够给用户提供的功 能。
3. 参与者的表示 参与者可以表示为下面三种形式。
第23页，共87页。
4. 参与者之间的关系 参与者之间可以有泛化关系。
第24页，共87页。
5. 参与者的特性 参与者具有以下特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系 ③.参与者与系统之间存在交互接口
第25页，共87页。
3.4 参与者与用例之间的关系
3.5 用例之间的关系 3.6 用例图
第3章 用例图
案例分析--用例图
实例：“杂志流通”
在杂志的内容被一个雇员分析之前，每个杂志 首先由图书馆登记；分析员认为有意义的文章 被汇总输入到系统中；随后，杂志在雇员中传 阅。在此过程中，要求生成流通通知。该通知 被附到杂志上，并且包含现在正在阅读杂志的 雇员的名字。最后，在最后一名读者把杂志返 回到图书馆时，它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象：
GUI（图形用户界面）：识别用户的命令，接收 用户的输入，显示程序的结果。
Recorder（记录员）：记录中奖信息。 Chooser（抽奖者）：抽出中奖号码。 Printing（打印对象）：打印中奖信息。 Searching（查询对象）：为奖票持有者查询中
3.2 用例
问：抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情？兑奖人员
抽奖程序
如何用这个系统帮助兑奖
？
抽出中奖号码
答：抽奖主持人用这个系统 活动主持人 抽出中奖号码，兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素：
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统，他们代表的是系统的使用者 或使用环境。
在确定系统的用例时，首要问题就是识别参与者 （是一个类！！！！！！不是对象）。
如何识别用例？
参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？
《软件工程》第3章用例图及其应用
用例与参与者之间存在关联关系，表示参与者可以参与用例的执行。这种关系有助于明确系统的边界和 交互方式。
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一，它能 够帮助开发团队更好地理解用户需求，明确系统 的功能范围。
2
通过用例图，开发团队可以对系统的交互方式进 行模拟和验证，从而发现潜在的问题和缺陷，提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中，保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率，确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例，可以找出未被测 试到的功能和业务流程，从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率，降低 漏测的风险。
02
针对每个测试场景，细化出具体的测试用例，包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求，从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程，为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系， 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物，它描 述了用户期望的系统功能和行为。
02 在系统设计完成后，可以通过与原始用例图进行 对比，验证设计是否满足原始需求。
03 如果设计不符合原始需求，则需要重新调整设计， 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
《数控加工编程与操作》课件第3章
轴，由正方向向负方向看，顺时针方向为G02，逆时针方 向为G03，如图3.5所示。
第 章 数控车削加工及编辑
图3.5 圆弧方向的判别
第 章 数控车削加工及编辑
说明: (1) 绝对编程时，X、Z是指圆弧插补的终点坐标值；增 量编程时，U、W为圆弧的终点相对于圆弧的起点的坐标值。 (2) I、K是指圆弧起点到圆心的增量坐标，与G90，G91 无关，为零时可省略。有的机床厂家用I、K作为起点相对于 圆心的坐标增量。 (3) R为指定圆弧半径，当圆弧的圆心角小于等于180° 时，R值为正；当圆弧的圆心角大于180°时，R值为负，如 图3.6所示。同一程序段中，I、K、R同时出现时，R优先，I、 K无效。
第 章 数控车削加工及编辑
图3.1 恒线速切削方式
第 章 数控车削加工及编辑
(3) 恒线速度取消G97。 编程格式：
G97 S ； S后面的数字表示恒线速度控制取消后的主轴转速，如S 未指定，将保留G96的最终值。
例3.5 “G97 S1000；”表示恒线速度控制取消后主 轴转速为1000 r/min。
深孔钻循环 外径切槽循环 复合螺纹切削循环
第 章 数控车削加工及编辑
G27
G28
00
G29
*G40
G41
07
G42
G50
00
回参考点检查 回参考点 参考点返回 刀补取消 左刀补 右刀补 坐标系设置
*G90
外圆切削循环
G92
01
螺纹切削循环
G94
端面切削循环
G96
主轴恒线速度控制
* G97
02
取消主轴恒线速度控制
第 章 数控车削加工及编辑
例3.8 实现图3.4中从P0点到P1点的运动，其程序段为：
第 章 数控车削加工及编辑
图3.5 圆弧方向的判别
第 章 数控车削加工及编辑
说明: (1) 绝对编程时，X、Z是指圆弧插补的终点坐标值；增 量编程时，U、W为圆弧的终点相对于圆弧的起点的坐标值。 (2) I、K是指圆弧起点到圆心的增量坐标，与G90，G91 无关，为零时可省略。有的机床厂家用I、K作为起点相对于 圆心的坐标增量。 (3) R为指定圆弧半径，当圆弧的圆心角小于等于180° 时，R值为正；当圆弧的圆心角大于180°时，R值为负，如 图3.6所示。同一程序段中，I、K、R同时出现时，R优先，I、 K无效。
第 章 数控车削加工及编辑
图3.1 恒线速切削方式
第 章 数控车削加工及编辑
(3) 恒线速度取消G97。 编程格式：
G97 S ； S后面的数字表示恒线速度控制取消后的主轴转速，如S 未指定，将保留G96的最终值。
例3.5 “G97 S1000；”表示恒线速度控制取消后主 轴转速为1000 r/min。
深孔钻循环 外径切槽循环 复合螺纹切削循环
第 章 数控车削加工及编辑
G27
G28
00
G29
*G40
G41
07
G42
G50
00
回参考点检查 回参考点 参考点返回 刀补取消 左刀补 右刀补 坐标系设置
*G90
外圆切削循环
G92
01
螺纹切削循环
G94
端面切削循环
G96
主轴恒线速度控制
* G97
02
取消主轴恒线速度控制
第 章 数控车削加工及编辑
例3.8 实现图3.4中从P0点到P1点的运动，其程序段为：
第3章用例和用例图
第3章 用例和用例图
3.1 用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译 名有: 用况、用案等. 它是站在用户的角度看待系统、 定义系统 ；使用用户能够看懂的语言来表述
定义1: 用例是对一个活动者(actor，角色，参与者)使用 系统的一项功能时所进行的交互过程的一个文字描述序 列. 定义2: 用例是系统、子系统或类和外部参与者交互的动 作序列的说明, 包括可选的动作序列和会出现异常的动 作序列. 用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约, 软件开发过程是用例驱动的.
18
面向对象分析与设计 & UML
3.4.1 泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子 用例也可以增加新的行为和含义或覆盖父用例中的行 为和含义.
右图的例子演示了 泛化关系
19
面向对象分析与设计 & UML
3.4.1 泛化关系
•
可以用来表示参与者与参与者之间，用例与用例之间的 特殊/一般化关系
33
面向对象分析与设计 & UML
3.6 用例的描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了主路径外, 其它路径是什么 用例结束后系统的状态 其它需要描述的内容
描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在 开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
3.1 用例
用例(use case)是Ivar Jacobson发明的. 其它的中文译 名有: 用况、用案等. 它是站在用户的角度看待系统、 定义系统 ；使用用户能够看懂的语言来表述
定义1: 用例是对一个活动者(actor，角色，参与者)使用 系统的一项功能时所进行的交互过程的一个文字描述序 列. 定义2: 用例是系统、子系统或类和外部参与者交互的动 作序列的说明, 包括可选的动作序列和会出现异常的动 作序列. 用例是代表系统中各个项目相关人员之间就系统的行为 所达成的契约, 软件开发过程是用例驱动的.
18
面向对象分析与设计 & UML
3.4.1 泛化关系
泛化关系代表一般与特殊的关系, 与继承类似. 在泛化关系中, 子用例继承了父用例的行为和含义, 子 用例也可以增加新的行为和含义或覆盖父用例中的行 为和含义.
右图的例子演示了 泛化关系
19
面向对象分析与设计 & UML
3.4.1 泛化关系
•
可以用来表示参与者与参与者之间，用例与用例之间的 特殊/一般化关系
33
面向对象分析与设计 & UML
3.6 用例的描述
用例描述一般包括的内容：
用例的目标 用例是怎么启动的 参与者与用例之间的消息如何传送 用例中除了主路径外, 其它路径是什么 用例结束后系统的状态 其它需要描述的内容
描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
柜员机系统中，银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在 开发IC卡门禁系统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
需求分析与用例模型
什么是需求？
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。
➢ 功能性（Functional）：特性、功能、安全性；
➢ 可用性（Usability）：人性化因素、帮助、文档；
非
➢ 可靠性（Reliability）：故障频率、可恢复性、可预测
功 能
性；
性
➢ 性能（Performance）：响应时间、吞吐量、准确性、有
用例之间的各种关系
3.包含关系 ➢包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 ➢在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
事件流
➢ 说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。
➢ 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
➢ 在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
第3章 需求分析与用例模型
在统一过程（UP）中，需求按照“FURPS”模型进行分类。
➢ 功能性（Functional）：特性、功能、安全性；
➢ 可用性（Usability）：人性化因素、帮助、文档；
非
➢ 可靠性（Reliability）：故障频率、可恢复性、可预测
功 能
性；
性
➢ 性能（Performance）：响应时间、吞吐量、准确性、有
用例之间的各种关系
3.包含关系 ➢包含关系描述的是一个用例需要某种功能，而该功能被另外一个 用例定义，那么在用例的执行过程中，就可以调用已经定义好的用 例。 ➢在UML中，用例之间的包含关系含有关键字<<include>>的带有箭 头的虚线表示。
3.包含关系
3.包含关系
3.包含关系
3.包含关系
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
用例之间的各种关系
2.泛化关系
➢如果系统中一个或多个用例是某个一般用例的特殊化时，就需要 使用用例的泛化关系。 ➢在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角 箭头从子用例指向父用例。
事件流
➢ 说明用例如何开始和结束。只说明属于该用例的事件， 而不是发生在其他用例中或系统外部的事件。
➢ 避免不明确的术语，如“例如”、“等等”和“信息”
事件流
➢ 在事件流里要对事件流进行结构化说明 基本事件流 • 描述每个情节的行为者:目标语句对的顺序 • 假设之前的每一步都是成功的 备选事件流 • 异常情况
第3章(用例图)
用例
事件流
将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 (ATM)系统中的 例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─ 提款─基本事件流
基本流步骤1：用户插入信用卡 基本流步骤1 基本流步骤2 基本流步骤2：输入密码 基本流步骤3 基本流步骤3：输入提款金额 基本流步骤4 基本流步骤4：提取现金 基本流步骤5 退出系统， 基本流步骤5：退出系统，取回信用卡
用例规约模板
用例编号 用例名称 用例概述 范围 主参与者 次要参与者 项目相关人 利益说明 [为用例制定一个唯一的编号，通常格式为UCxx] 为用例制定一个唯一的编号，通常格式为UCxx] [应为一个动词短语，让读者一目了然地知道用例的目标] 应为一个动词短语，让读者一目了然地知道用例的目标] [用例的目标，一个概要性的描述] 用例的目标，一个概要性的描述] [用例的设计范围] 用例的设计范围] [该用例的主Actor，在此列出名称，并简要的描述它] 该用例的主Actor，在此列出名称，并简要的描述它] Actor [该用例的次要Actor，在此列出名称，并简要的描述它] 该用例的次要Actor，在此列出名称，并简要的描述它] Actor 项目相关人 [项目相关人员名称] 项目相关人员名称] …… 前置条件 后置条件 成功保证 基本事件流 1 2 扩展事件流 1a 1b 子事件流 规则与约束 [从该用例获取的利益] 从该用例获取的利益] …… 利益
[即启动该用例所应该满足的条件。] 即启动该用例所应该满足的条件。 [即该用例完成之后，将执行什么动作。] 即该用例完成之后，将执行什么动作。 [描述当前目标完成后，环境变化情况。] 描述当前目标完成后，环境变化情况。 步骤 活动 [在这里写出触发事件到目标完成以及清除的步骤。] 在这里写出触发事件到目标完成以及清除的步骤。 ……(其中可以包含子事件流，以子事件流编号来表示) ……(其中可以包含子事件流，以子事件流编号来表示) 其中可以包含子事件流 [1a表示是对1的扩展，其中应说明条件和活动] [1a表示是对1的扩展，其中应说明条件和活动] 表示是对 ……(其中可以包含子事件流，以子事件流编号来表示) ……(其中可以包含子事件流，以子事件流编号来表示) 其中可以包含子事件流
第3章 用例和用例图-4
include>>
Add to Wish List
<<include>>
Customer
Login
Checkout
作业
题目: p. 230 18、19、20题 任选一题 只需要uml建模不需要实现, 用例图至少有一个用例需 要有用例描述，其他类型的图需要有一段每个图的文 字描述 用例图、类图、顺序图（至少一个）、协作图（至少 一个） 作业提交日期：2014年5月31 (第十四周 周六)
前置条件 基本操作流程
验证用户
当一个用户插卡后是这个用例的开始。 它处理有关用户验证的问题。 用户插入银行卡 用户提交密码信息 系统检查密码是否正确。如果有效系 统进入欢迎页面 用户被准许转账等其他操作
基本操作流程 的后置条件
练习
用例名 可选操作流程1 验证用户 用户在提交密码之前清除密码 用户重新输入密码并提交密码 系统检查密码是否正确。如果有效系 统进入欢迎页面
用例描述 客户可以给图书评分 参与者：客户 前置条件：客户已经登录 主事件流: 1. 客户在个人页面上输入关键字并点击搜素按钮 2. 系统在网页上显示匹配的书籍 3. 客户点击想评论的书籍的图标 4. 系统在书籍信息页面显示书籍具体信息 5. 客户在网页上点击评论按钮 6. 系统显示评论书籍页面 7. 客户点击想给的星星按钮并点击ok按钮 8. 系统计算书籍总评分并更新数据库书籍表 9. 系统显示更新书籍信息页面 后置条件: 书籍表和评分表被更新
案例学习: 网上书店
用例 Register
用例描述 新客户在使用系统进行任何操作前需要首先注册 参与者: 客户 前置条件: 一个未注册客户 主事件流： 1. 客户提交注册所需的信息 2. 系统检查输入的所有信息。更新客户记录。 后置条件： 新客户已注册。
Add to Wish List
<<include>>
Customer
Login
Checkout
作业
题目: p. 230 18、19、20题 任选一题 只需要uml建模不需要实现, 用例图至少有一个用例需 要有用例描述，其他类型的图需要有一段每个图的文 字描述 用例图、类图、顺序图（至少一个）、协作图（至少 一个） 作业提交日期：2014年5月31 (第十四周 周六)
前置条件 基本操作流程
验证用户
当一个用户插卡后是这个用例的开始。 它处理有关用户验证的问题。 用户插入银行卡 用户提交密码信息 系统检查密码是否正确。如果有效系 统进入欢迎页面 用户被准许转账等其他操作
基本操作流程 的后置条件
练习
用例名 可选操作流程1 验证用户 用户在提交密码之前清除密码 用户重新输入密码并提交密码 系统检查密码是否正确。如果有效系 统进入欢迎页面
用例描述 客户可以给图书评分 参与者：客户 前置条件：客户已经登录 主事件流: 1. 客户在个人页面上输入关键字并点击搜素按钮 2. 系统在网页上显示匹配的书籍 3. 客户点击想评论的书籍的图标 4. 系统在书籍信息页面显示书籍具体信息 5. 客户在网页上点击评论按钮 6. 系统显示评论书籍页面 7. 客户点击想给的星星按钮并点击ok按钮 8. 系统计算书籍总评分并更新数据库书籍表 9. 系统显示更新书籍信息页面 后置条件: 书籍表和评分表被更新
案例学习: 网上书店
用例 Register
用例描述 新客户在使用系统进行任何操作前需要首先注册 参与者: 客户 前置条件: 一个未注册客户 主事件流： 1. 客户提交注册所需的信息 2. 系统检查输入的所有信息。更新客户记录。 后置条件： 新客户已注册。
第3章(用例图)
4）清晰地描述事件流，使得读者能够轻而易举地理解
5）摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行 为和角色，最好使它们在物理上也更加接近；
• 根据系统实际情况控制粒度
Agenda
• 用例和用例驱动开发 • 如何阅读用例图 • 如何绘制用例图 • 用例图应用说明 • 本章小结
本章小结
• 首先从传统的需求表述方法开始，引入了用例图表达系统需
任务：请分析该系统的需求，确定系统中的参与者和主要用 例，并画出用例视图。
案例分析
需求分析
（1）读者需要借书、还书； （2）读者需要预约书籍、也可以取消预约； （3）管理员根据读者要求提供服务； （4）管理员必须维护读者信息； （5）管理员必须维护书籍信息。
案例分析
确定系统参与者
管理员 读者
用例
识别用例 例2：一个论坛类的应用，用户可以提问，别人来回答，如果有 自己提的问题被解答的话，就给回答者发一份邮件表示感谢。
论坛类应用的用例图
用例
如何判断一个用例是否是一个优秀的用例呢？
①用例是否描述了应该做什么，而不是如何做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联用例或关联参与 者？
案例分析
确定系统用例
（1）读者信息管理模块 新增读者 修改读者信息 删除读者
（2）书籍信息管理模块 删除书籍 删除书目 新增书籍 新增书目 修改书籍信息
（3）图书馆业务功能模块 还书 借书 预约书籍 取消预约
（4）信息查询模块 查询读者信息 查询书籍信息
案例分析
绘制用例图
图书管理系统顶层用例图
输入支付信息 将商品放入购物车 结账 预订商品 用户登录 邮寄商品 查看商品详情
5）摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行 为和角色，最好使它们在物理上也更加接近；
• 根据系统实际情况控制粒度
Agenda
• 用例和用例驱动开发 • 如何阅读用例图 • 如何绘制用例图 • 用例图应用说明 • 本章小结
本章小结
• 首先从传统的需求表述方法开始，引入了用例图表达系统需
任务：请分析该系统的需求，确定系统中的参与者和主要用 例，并画出用例视图。
案例分析
需求分析
（1）读者需要借书、还书； （2）读者需要预约书籍、也可以取消预约； （3）管理员根据读者要求提供服务； （4）管理员必须维护读者信息； （5）管理员必须维护书籍信息。
案例分析
确定系统参与者
管理员 读者
用例
识别用例 例2：一个论坛类的应用，用户可以提问，别人来回答，如果有 自己提的问题被解答的话，就给回答者发一份邮件表示感谢。
论坛类应用的用例图
用例
如何判断一个用例是否是一个优秀的用例呢？
①用例是否描述了应该做什么，而不是如何做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联用例或关联参与 者？
案例分析
确定系统用例
（1）读者信息管理模块 新增读者 修改读者信息 删除读者
（2）书籍信息管理模块 删除书籍 删除书目 新增书籍 新增书目 修改书籍信息
（3）图书馆业务功能模块 还书 借书 预约书籍 取消预约
（4）信息查询模块 查询读者信息 查询书籍信息
案例分析
绘制用例图
图书管理系统顶层用例图
输入支付信息 将商品放入购物车 结账 预订商品 用户登录 邮寄商品 查看商品详情
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
36
用例
例如：网站后台管理系统中的会员信息维护用例， 例如：网站后台管理系统中的会员信息维护用例，管理员需要进 行添加会员信息、修改会员信息、删除会员信息等操作。 行添加会员信息、修改会员信息、删除会员信息等操作。
过细的粒度，一般都会导致技术语言的描述， 过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
29
用例粒度(2) 用例粒度
把步骤当用例
输入用户名 会员
<<include>>
登录 会员
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 << include>> 查询订单
执行SQL语句
3
概述
用例图的作用
用例图是需求分析中的产物， 用例图是需求分析中的产物，主要作用是描述 参与者和用例之间的关系， 参与者和用例之间的关系，帮助开发人员可视 化的了解系统的功能。借助于用例图， 化的了解系统的功能。借助于用例图，系统用 系统分析人员、系统设计人员、 户、系统分析人员、系统设计人员、领域专家 能够以可视化的方式对问题进行探讨， 能够以可视化的方式对问题进行探讨，减少了 大量交流上的障碍，便于对问题达成共识。 大量交流上的障碍，便于对问题达成共识。
第3章 用例图（Use case） 章 用例图（ ）
冯国奇 gqfeng@
1
主要内容
概述 参与者 用例 习题案例
2
概述
用例图的含义
由参与者（ 由参与者（Actor）、 ）、 用例（ 用例（Use Case）以 ） 及它们之间的关系构成 的用于描述系统功能的 视图称为用例图。 视图称为用例图。
Use Cases 把所有这些过程绑到一起
用例图定义和描述了系统的外部可见行为， 用例图定义和描述了系统的外部可见行为， 外部可见行为 是分析、设计直至组装测试的重要依据。 是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。 让用户参与前期的系统分析与设计。
5
概述
用例图特点
用例图可视化地表达了系统的需求，具有直观、 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。 规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能， 用例方法是完全从外部来定义系统功能，它把 需求和设计完全的分离开来。 需求和设计完全的分离开来。我们不用关心系 统内部是如何完成各种功能的， 统内部是如何完成各种功能的，系统对于我们 来说就是一个黑箱子。 来说就是一个黑箱子。
8
参与者
每个参与者可以参与一个或多个用例。 每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用 （因此也与用例所在的系统或类发生了交互 作用） 作用） 参与者的内部实现与用例是不相关的,参与 参与者的内部实现与用例是不相关的 参与 者可以被一组定义它的状态的属性充分描述。 者可以被一组定义它的状态的属性充分描述。
用例A
雇员
用例B
如系统中经理可以参 加雇员的所有用例
用例C 经理
15
用例
用例是外部可见的一个系统功能单元。 用例是外部可见的一个系统功能单元。 这些功能由系统单元所提供， 这些功能由系统单元所提供，并通过一系列 系统单元与一个或多个参与者之间交换的消 息所表达。 息所表达。
16
用例
在模型中,每个用例的执行独立于其他用例 在模型中 每个用例的执行独立于其他用例
19
用例识别方法
可以通过以下问题来寻找用例： 可以通过以下问题来寻找用例：
参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、 参与者是否会读取、创建、修改、删除、存储 系统的某种信息？如果是的话， 系统的某种信息？如果是的话，参与者又是如 何完成这些操作的？ 何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 什么用例将支持和维护系统？ 什么用例将支持和维护系统？ 是否存在影响系统的外部事件。 是否存在影响系统的外部事件。
9
识别参与者的方法
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理） 系统需要应付（处理）哪些硬设备 系统需要和哪些外部系统交互 或什么）对系统运行产生的结果（ 谁（或什么）对系统运行产生的结果（值）感兴 趣 时间、 时间、气温等内部外部条件
4、如果扩大边界，让呼 叫中心成为机票预订系 统的一个子系统，机票 购买者通过人工座席、 自动语音及网站预订机 票，那么机票购买者是 actor，人工座席成了业 务工人
14
参与者
参与者之间也可以象类一样存在泛化或者依 赖关系。 赖关系。 在这种泛化关系中， 在这种泛化关系中，一个参与者的抽象描述 可以被一个或多个具体的参与者所共享。 可以被一个或多个具体的参与者所共享。
10
参与者可以非人
如果我开发一个 猪圈自动供食供 水系统，猪的前 蹄触发一个开关 系统就供食或供 水。 这里的Actor 是 小猪。
11
思考：识别参与者？
寻呼台系统：用户如果预定了天气预报，系 统每天定时给他发天气消息；如果当天气温 高于35度，还要提醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 在这个叙述里，谁是寻呼台系统的Actor？
17
用例
用例用一个名字在里面的椭圆表示， 用例用一个名字在里面的椭圆表示，用例和 与它通信的参与者之间用实线连接。 与它通信的参与者之间用实线连接。
将关联属性设置 为navigable即 即 可显示为双向关 联
18
用例
识别用例
任何用例都不能在缺少参与者的情况下独立存 同样， 在。同样，任何参与者也必须要有与之关联的 用例。 用例。所以识别用例的最好方法就是从分析系 统参与者开始， 统参与者开始，在这个过程中往往会发现新的 参与者。 参与者。
30
要点：用例的粒度(3) 要点：用例的粒度
“四轮马车” 四轮马车” 四轮马车
C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为 CRUD？ ？ CRUD能为 能为Actor提供 能为 提供 价值？ 价值？ CRUD掩盖业务，锐变 掩盖业务， 掩盖业务 成关系数据库的建模： 成关系数据库的建模：
虽然在具体执行一个用例功能时由于用例之间 共享对象的缘故可能会造成本用例与其他用例 之间有这样或那样的隐含的依赖关系。 之间有这样或那样的隐含的依赖关系。
每一个用例都是一个纵向的功能块， 每一个用例都是一个纵向的功能块，这个功 能块的执行会和其他用例的执行发生混杂。 能块的执行会和其他用例的执行发生混杂。
要点：有意义的目标 要点：
设定查询条件
检索零件 会员
会员 选择零件
23
由参与者发起
24
要点：结果值由系统生成 要点：
吃饭 出纳员
系统需要处理的， 系统需要处理的，由系统生成
25
要点： 要点：业务语言而非技术语言
用户词汇， 用户词汇，而不是技术词汇
如：发票，商品，洗衣机 发票，商品， 而不是：记录，字段， 而不是：记录，字段，COM，C++等 ， 等
管理用户 管理员
32
要点：用例的粒度(4) 要点：用例的粒度
灵活处理CRUD 灵活处理
<<extend>>
管理用户 管理员
增加用户
可以把包含复杂交互的路径独立出去形成用例
33
用例的获得
首先确定actor 首先确定 接下来，开始对actor即业务代表进行访谈 接下来，开始对 即业务代表进行访谈
您对系统有什么期望？ 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？ 您做完这件事希望有一个什么样的结果？
34
用例的获得--ATM 用例的获得
客户代表说：我希望这台 客户代表说：我希望这台ATM能支持跨行 能支持跨行 业务，我插入卡片输入密码后， 业务，我插入卡片输入密码后，可以让我选 择是取钱还是存钱；为了方便， 择是取钱还是存钱；为了方便，可以设置一 些默认的存取金额按钮；我可以修改密码， 些默认的存取金额按钮；我可以修改密码， 也可以挂失；还有我希望可以缴纳电话费、 也可以挂失；还有我希望可以缴纳电话费、 水费、电费等费用；为了安全起见， 水费、电费等费用；为了安全起见，ATM 上应该有警示小心骗子的提示条， 上应该有警示小心骗子的提示条，还有摄像 如果输入三次密码错误， 头；如果输入三次密码错误，卡片应当被自 动吞没。 动吞没。
用户,气温,时间都是Actor 用户,气温,时间都是Actor
12
1、机票购买者通过登录网站购买机票，机票购买者 就是actor
2、机票购买者通过呼叫中心，由人工座席操 作订票系统购买机票;人工座席是actor
13
3、如果机票购买者通过呼叫中心的自动语音预订机 票，那么呼叫中心就成了机票预订系统的一个actor
用例图是从用户的角度来描述对软件产品的 用例图是从用户的角度来描述对软件产品的 用户的角度 需求，分析产品的功能和行为 因此， 功能和行为， 需求，分析产品的功能和行为，因此，对整 个软件开发过程而言，用例图是至关重要的。 个软件开发过程而言，用例图是至关重要的。
4
Use Case 对开发的意义
需求 分析和设计 实现 测试
26
要点： 要点：用户观点而非系统观点
处理订票
用例
例如：网站后台管理系统中的会员信息维护用例， 例如：网站后台管理系统中的会员信息维护用例，管理员需要进 行添加会员信息、修改会员信息、删除会员信息等操作。 行添加会员信息、修改会员信息、删除会员信息等操作。
过细的粒度，一般都会导致技术语言的描述， 过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
29
用例粒度(2) 用例粒度
把步骤当用例
输入用户名 会员
<<include>>
登录 会员
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 << include>> 查询订单
执行SQL语句
3
概述
用例图的作用
用例图是需求分析中的产物， 用例图是需求分析中的产物，主要作用是描述 参与者和用例之间的关系， 参与者和用例之间的关系，帮助开发人员可视 化的了解系统的功能。借助于用例图， 化的了解系统的功能。借助于用例图，系统用 系统分析人员、系统设计人员、 户、系统分析人员、系统设计人员、领域专家 能够以可视化的方式对问题进行探讨， 能够以可视化的方式对问题进行探讨，减少了 大量交流上的障碍，便于对问题达成共识。 大量交流上的障碍，便于对问题达成共识。
第3章 用例图（Use case） 章 用例图（ ）
冯国奇 gqfeng@
1
主要内容
概述 参与者 用例 习题案例
2
概述
用例图的含义
由参与者（ 由参与者（Actor）、 ）、 用例（ 用例（Use Case）以 ） 及它们之间的关系构成 的用于描述系统功能的 视图称为用例图。 视图称为用例图。
Use Cases 把所有这些过程绑到一起
用例图定义和描述了系统的外部可见行为， 用例图定义和描述了系统的外部可见行为， 外部可见行为 是分析、设计直至组装测试的重要依据。 是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。 让用户参与前期的系统分析与设计。
5
概述
用例图特点
用例图可视化地表达了系统的需求，具有直观、 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。 规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能， 用例方法是完全从外部来定义系统功能，它把 需求和设计完全的分离开来。 需求和设计完全的分离开来。我们不用关心系 统内部是如何完成各种功能的， 统内部是如何完成各种功能的，系统对于我们 来说就是一个黑箱子。 来说就是一个黑箱子。
8
参与者
每个参与者可以参与一个或多个用例。 每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用 （因此也与用例所在的系统或类发生了交互 作用） 作用） 参与者的内部实现与用例是不相关的,参与 参与者的内部实现与用例是不相关的 参与 者可以被一组定义它的状态的属性充分描述。 者可以被一组定义它的状态的属性充分描述。
用例A
雇员
用例B
如系统中经理可以参 加雇员的所有用例
用例C 经理
15
用例
用例是外部可见的一个系统功能单元。 用例是外部可见的一个系统功能单元。 这些功能由系统单元所提供， 这些功能由系统单元所提供，并通过一系列 系统单元与一个或多个参与者之间交换的消 息所表达。 息所表达。
16
用例
在模型中,每个用例的执行独立于其他用例 在模型中 每个用例的执行独立于其他用例
19
用例识别方法
可以通过以下问题来寻找用例： 可以通过以下问题来寻找用例：
参与者希望系统提供什么功能？ 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、 参与者是否会读取、创建、修改、删除、存储 系统的某种信息？如果是的话， 系统的某种信息？如果是的话，参与者又是如 何完成这些操作的？ 何完成这些操作的？ 参与者是否会将外部的某些事件通知给系统？ 参与者是否会将外部的某些事件通知给系统？ 系统中发生的事件是否通知参与者？ 系统中发生的事件是否通知参与者？ 什么用例将支持和维护系统？ 什么用例将支持和维护系统？ 是否存在影响系统的外部事件。 是否存在影响系统的外部事件。
9
识别参与者的方法
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、 谁负责日常维护、管理并保证系统正常运行 系统需要应付（处理） 系统需要应付（处理）哪些硬设备 系统需要和哪些外部系统交互 或什么）对系统运行产生的结果（ 谁（或什么）对系统运行产生的结果（值）感兴 趣 时间、 时间、气温等内部外部条件
4、如果扩大边界，让呼 叫中心成为机票预订系 统的一个子系统，机票 购买者通过人工座席、 自动语音及网站预订机 票，那么机票购买者是 actor，人工座席成了业 务工人
14
参与者
参与者之间也可以象类一样存在泛化或者依 赖关系。 赖关系。 在这种泛化关系中， 在这种泛化关系中，一个参与者的抽象描述 可以被一个或多个具体的参与者所共享。 可以被一个或多个具体的参与者所共享。
10
参与者可以非人
如果我开发一个 猪圈自动供食供 水系统，猪的前 蹄触发一个开关 系统就供食或供 水。 这里的Actor 是 小猪。
11
思考：识别参与者？
寻呼台系统：用户如果预定了天气预报，系 统每天定时给他发天气消息；如果当天气温 高于35度，还要提醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 在这个叙述里，谁是寻呼台系统的Actor？
17
用例
用例用一个名字在里面的椭圆表示， 用例用一个名字在里面的椭圆表示，用例和 与它通信的参与者之间用实线连接。 与它通信的参与者之间用实线连接。
将关联属性设置 为navigable即 即 可显示为双向关 联
18
用例
识别用例
任何用例都不能在缺少参与者的情况下独立存 同样， 在。同样，任何参与者也必须要有与之关联的 用例。 用例。所以识别用例的最好方法就是从分析系 统参与者开始， 统参与者开始，在这个过程中往往会发现新的 参与者。 参与者。
30
要点：用例的粒度(3) 要点：用例的粒度
“四轮马车” 四轮马车” 四轮马车
C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为 CRUD？ ？ CRUD能为 能为Actor提供 能为 提供 价值？ 价值？ CRUD掩盖业务，锐变 掩盖业务， 掩盖业务 成关系数据库的建模： 成关系数据库的建模：
虽然在具体执行一个用例功能时由于用例之间 共享对象的缘故可能会造成本用例与其他用例 之间有这样或那样的隐含的依赖关系。 之间有这样或那样的隐含的依赖关系。
每一个用例都是一个纵向的功能块， 每一个用例都是一个纵向的功能块，这个功 能块的执行会和其他用例的执行发生混杂。 能块的执行会和其他用例的执行发生混杂。
要点：有意义的目标 要点：
设定查询条件
检索零件 会员
会员 选择零件
23
由参与者发起
24
要点：结果值由系统生成 要点：
吃饭 出纳员
系统需要处理的， 系统需要处理的，由系统生成
25
要点： 要点：业务语言而非技术语言
用户词汇， 用户词汇，而不是技术词汇
如：发票，商品，洗衣机 发票，商品， 而不是：记录，字段， 而不是：记录，字段，COM，C++等 ， 等
管理用户 管理员
32
要点：用例的粒度(4) 要点：用例的粒度
灵活处理CRUD 灵活处理
<<extend>>
管理用户 管理员
增加用户
可以把包含复杂交互的路径独立出去形成用例
33
用例的获得
首先确定actor 首先确定 接下来，开始对actor即业务代表进行访谈 接下来，开始对 即业务代表进行访谈
您对系统有什么期望？ 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？ 您做完这件事希望有一个什么样的结果？
34
用例的获得--ATM 用例的获得
客户代表说：我希望这台 客户代表说：我希望这台ATM能支持跨行 能支持跨行 业务，我插入卡片输入密码后， 业务，我插入卡片输入密码后，可以让我选 择是取钱还是存钱；为了方便， 择是取钱还是存钱；为了方便，可以设置一 些默认的存取金额按钮；我可以修改密码， 些默认的存取金额按钮；我可以修改密码， 也可以挂失；还有我希望可以缴纳电话费、 也可以挂失；还有我希望可以缴纳电话费、 水费、电费等费用；为了安全起见， 水费、电费等费用；为了安全起见，ATM 上应该有警示小心骗子的提示条， 上应该有警示小心骗子的提示条，还有摄像 如果输入三次密码错误， 头；如果输入三次密码错误，卡片应当被自 动吞没。 动吞没。
用户,气温,时间都是Actor 用户,气温,时间都是Actor
12
1、机票购买者通过登录网站购买机票，机票购买者 就是actor
2、机票购买者通过呼叫中心，由人工座席操 作订票系统购买机票;人工座席是actor
13
3、如果机票购买者通过呼叫中心的自动语音预订机 票，那么呼叫中心就成了机票预订系统的一个actor
用例图是从用户的角度来描述对软件产品的 用例图是从用户的角度来描述对软件产品的 用户的角度 需求，分析产品的功能和行为 因此， 功能和行为， 需求，分析产品的功能和行为，因此，对整 个软件开发过程而言，用例图是至关重要的。 个软件开发过程而言，用例图是至关重要的。
4
Use Case 对开发的意义
需求 分析和设计 实现 测试
26
要点： 要点：用户观点而非系统观点
处理订票