第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 (参与者基数)
第3章用例及用例图-案例精品PPT课件
9
● ② 确定各参与者所期望的系统行为。
管理员: 增加课程 修改课程 删除课程
学生: 查询课程 选择课程 网上付费
10
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
11
● ④ 确定各用例之间的关系(泛化,包含,扩展)。
12
● ⑤ 绘制用例图。
5
案例1: • 用例图
6
案例1: • 优化
7
案例2:
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统,建立本学 期要开设的各种课程,将课程信息保存到系统中, 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统,选择课程:可 以查询课程,选择课程,支付课程费用。
8
● ① 找出系统外部参与者,确定系统边界和范围。
You Know, The More Powerful You Will Be
谢谢大家
荣幸这一路,与你同行
It'S An Honor To Walk With You All The Way
演讲人:XXXXXX 时 间:XX年XX月XX日
2
3.7 业务用例图
• 业务角色(Business Actor)
– 机构(组织)外部参与者
• 业务工人(Business Worker)
– 机构内部参与者所起作用的表示
• 业务用例(Business Use Case)
– 业务功能(无论是手工还是自动处理)
• 业务机构(Business Organization)
13
● ⑥ 编制用例说明。
● 用例:增加课程
●参与者:管理员
●操作流:
● ② 确定各参与者所期望的系统行为。
管理员: 增加课程 修改课程 删除课程
学生: 查询课程 选择课程 网上付费
10
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ● ③ 把这些系统行为命名为用例。
11
● ④ 确定各用例之间的关系(泛化,包含,扩展)。
12
● ⑤ 绘制用例图。
5
案例1: • 用例图
6
案例1: • 优化
7
案例2:
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统,建立本学 期要开设的各种课程,将课程信息保存到系统中, 并可以对课程进行改动和删除。 学生通过客户机浏览器进入系统,选择课程:可 以查询课程,选择课程,支付课程费用。
8
● ① 找出系统外部参与者,确定系统边界和范围。
You Know, The More Powerful You Will Be
谢谢大家
荣幸这一路,与你同行
It'S An Honor To Walk With You All The Way
演讲人:XXXXXX 时 间:XX年XX月XX日
2
3.7 业务用例图
• 业务角色(Business Actor)
– 机构(组织)外部参与者
• 业务工人(Business Worker)
– 机构内部参与者所起作用的表示
• 业务用例(Business Use Case)
– 业务功能(无论是手工还是自动处理)
• 业务机构(Business Organization)
13
● ⑥ 编制用例说明。
● 用例:增加课程
●参与者:管理员
●操作流:
第3章(用例图)
识别用例
从分析系统的参与者开始,考虑每个参与者是怎样使用系统。
①参与者希望系统提供什么功能; ②系统是否存储和检索信息; ③当系统改变状态时,是否通知参与者; ④是否存在影响系统的外部事件,是哪个参与者通知系
统这些外部事件。
用例
识别用例 例1:Email客户端(如:outlook express),A在北京发邮件给深 圳的B,系统提醒B”你有新邮件”,B收邮件。
参与者的表示方法
参与者
如何发现系统的参与者 ①谁使用系统? ②谁安装系统、维护系统? ③谁启动系统、关闭系统? ④谁从系统中获取信息,谁提供信息给系统? ⑤在系统交互中,谁扮演了什么角色? ⑥系统会与哪些其他系统相关联?
参与者
如何发现系统的参与者 例1:客户给销售员发来传真订货, 销售员下班前将当日订货单汇总 输入系统。
用例
用例的粒度 用例所包含的系统服务或功能单元的多少。
用例
用例规约 对每一个用例的详细描述信息,以便于其他人对整个系统有一
个更加详细地了解。
用例规约的内容
(1)简要说明 (2)前置条件 (3)基本事件流 (4)其他事件流 (5)异常事件流 (6)后置条件
前置条件 扩展事件流 基本事件流
后置条件
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─基本事件流
基本流步骤1:用户插入信用卡 基本流步骤2:输入密码 基本流步骤3:输入提款金额 基本流步骤4:提取现金 基本流步骤5:退出系统,取回信用卡
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。
问题:谁是系统的Actor?
答案: 销售员
参与者
从分析系统的参与者开始,考虑每个参与者是怎样使用系统。
①参与者希望系统提供什么功能; ②系统是否存储和检索信息; ③当系统改变状态时,是否通知参与者; ④是否存在影响系统的外部事件,是哪个参与者通知系
统这些外部事件。
用例
识别用例 例1:Email客户端(如:outlook express),A在北京发邮件给深 圳的B,系统提醒B”你有新邮件”,B收邮件。
参与者的表示方法
参与者
如何发现系统的参与者 ①谁使用系统? ②谁安装系统、维护系统? ③谁启动系统、关闭系统? ④谁从系统中获取信息,谁提供信息给系统? ⑤在系统交互中,谁扮演了什么角色? ⑥系统会与哪些其他系统相关联?
参与者
如何发现系统的参与者 例1:客户给销售员发来传真订货, 销售员下班前将当日订货单汇总 输入系统。
用例
用例的粒度 用例所包含的系统服务或功能单元的多少。
用例
用例规约 对每一个用例的详细描述信息,以便于其他人对整个系统有一
个更加详细地了解。
用例规约的内容
(1)简要说明 (2)前置条件 (3)基本事件流 (4)其他事件流 (5)异常事件流 (6)后置条件
前置条件 扩展事件流 基本事件流
后置条件
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。 提款─基本事件流
基本流步骤1:用户插入信用卡 基本流步骤2:输入密码 基本流步骤3:输入提款金额 基本流步骤4:提取现金 基本流步骤5:退出系统,取回信用卡
用例
事件流
例:将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。
问题:谁是系统的Actor?
答案: 销售员
参与者
第三章 用例和用例图
2014-7-16
用例间的关系
关联(association)是指参与者与其参与 执行的用例之间的通信途径 泛化(generalization)是代表一般和特殊 的关系 在泛化关系中,子用例继承父用例的行为 和含义,子用例也可以增加新的行为和含 义或覆盖父用例的行为和含义
2014-7-16
2014-7-16
UML中的 Use Case 表示
Communication
Buy Soda Customer
Actor
2014-7-16
Use Case
UML中的 Use Case 表示
post 购买商品
登录
出纳员 退还商品
顾客
2014-7-16
常见错误
识别用例时一个常见的 错误是把用例当成 是单独的步骤、操作或事务的处理。
Validate user
Buy Ticket
Individual Buy
Check password
Retinal scan
Group Buy
2014-7-16
包含(include)关系指的是两个用例之间 的关系,其中一个用例(称为基本用例, base use case)的行为包含另一个用例 (称为包含用例,inclusion use case)的 行为
箭头方向由扩展用例指向基本用例。
扩展用例依赖于被扩展用例,不是完整的独立用
例,无法单独执行。
2014-7-16
2014-7-16
用例的泛化、包含和扩展关系的比较
在扩展关系中,一个基本用例执行时,可 以执行、也可以不执行扩展部分 在包含关系中,在执行基本用例时,一定 会包含用例部分
UML-用例图
2012年 2012年4月
UML与设计模式 与设计模式
18/60 18/60
要点2 要点2:主动语句
欧文丛贝克汉姆处得到传球,守门员 欧文丛贝克汉姆处得到传球,守门员… 贝克汉姆传球给欧文,欧文射门,守门员扑救… 贝克汉姆传球给欧文,欧文射门,守门员扑救 图书管理员…… 图书管理员 系统…… 系统
UML与设计模式 与设计模式
17/60 17/60
要点1 只写“可观测” 要点1:只写“可观测”的
系统通过ADO建立数据库连接,传送SQL查询语 建立数据库连接,传送 系统通过 建立数据库连接 查询语 商品表”查询商品的详细信息… 句,从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息
2012年 2012年4月
UML与设计模式 与设计模式
13/60 13/60
用例阐述组成
用例名称 用例概述 涉及的参与者 前置条件Preconditions 前置条件 后置条件Postcondition 后置条件 事件流Flow of events 事件流 分支流Subflows 备选流Alternate flow
2012年 2012年4月
UML与设计模式 与设计模式
11/60 11/60
“Borrow Book”用例中的场景 Book”用例中的场景
如,在“Borrow Book”这个用例中,包含着几 ”这个用例中, 个相关的scenario: 个相关的 : Scenario-1:顺利地借到书 : Scenario-2:该种书刊不存在 : Scenario-3:物理书刊都已借出 : Scenario-4:没有该借阅者信息 :
2012年 2012年4月 UML与设计模式 与设计模式
3/60
第三讲用例图
3.3 用例图的概念
• 1. 用例图
• 用例图是描述用例、参与 者及其关系的图。与所有 UML的其它图一样,用例 图可以包括注释、约束。 图3-1是棋牌管理系统对应 的用例图。 • 图中的元素包括:参与者、 用例、一个方框和一些表 示关系的连接线,所有的 用例都位于方框之内,该 方框称为“系统边界”。 方框内是棋牌管理系统的 多个用例,方框外是外部 参与者。
第3章 用例图
目录
3.1 需求技术
3.2 RUP开发过程
3.3 用例图的概念 3.4 用例图的表示 3.5 参与者之间的关系
目录
3.6 用例之间的关系
3.7 参与者与用例之间的关系
3.8 阅读用例图 3.9 用例图应用 3.10 建模要点
第3章 用例图
• 用例图是外部参与者所能观察到的系统功能的模型图,该 图呈现了一些参与者和一些用例,以及它们之间的关系, 主要用于对系统、子系统或类的功能行为进行建模。
3.3.2 标识用例间的关系
• 2.包含关系 • 在UML中,包含关系用构造型《include》表示,它是指基用例(base use case)在它内部的某一个位置上显式地合并了另一个用例的行为。 • (1) 包含用例的表示 • 包含是指一个用例被另一个用例使用,被使用的用例就是包含用例, 使用包含用例的是基用例。 • 图3-7说明:查询、提款、转帐三个是基用例,它们都包含打印回执用 例.基用例执行时必须执行包含用例,否则,基用例是不完整的,包 含用例不是孤立存在的,它仅作为基用例的一部分出现.图中,包含 关系的箭头是从基用例指向包含用例. • 只有当某个事件流片断在多个用例中出现时,才将这个事件流片段抽 取出来,放在一个单独的用例中,把这个用例用作包含用例。
2_用例及用例图-3
确定参与者; 1. 参与者所看到的功能; 2. 把这些功能分解为用例; 3. 确定用例之间的关系; 4. 画用例图; 5. 优化用例图; 6. 描述事件流。
●
③ 把这些系统行为命名为用例。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。
●
④ 确定各用例之间的关系(泛化,包含,扩展)。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化,包含,扩展)。
参与者
1. 参与者的概念
参与者(actor)是外部需要与系统交互的事物。 也被称为活动者。
2.参与者的三种类型 ①. 人:客户,读者,库管员 ②. 外部系统:上层系统等
参与者的表示
参与者可以表示为下面三种形式。
参与者之间的关系
参与者之间可以有泛化关系。
参与者与用例之间的关系参与者与用 例之间具有使用,交互信息的关联。
⑦ATM记录事务到日志文件。
发现用例
发现用例的一般方法:
●
① 找出系统外部参与者,确定系统边界和范围。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。
●
② 确定各参与者所期望的系统行为。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。
用例之间的关系(1)
用例之间的几种关系:
1. 泛化关系
2. 包含关系
3. 扩展关系
●
③ 把这些系统行为命名为用例。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。
●
④ 确定各用例之间的关系(泛化,包含,扩展)。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化,包含,扩展)。
参与者
1. 参与者的概念
参与者(actor)是外部需要与系统交互的事物。 也被称为活动者。
2.参与者的三种类型 ①. 人:客户,读者,库管员 ②. 外部系统:上层系统等
参与者的表示
参与者可以表示为下面三种形式。
参与者之间的关系
参与者之间可以有泛化关系。
参与者与用例之间的关系参与者与用 例之间具有使用,交互信息的关联。
⑦ATM记录事务到日志文件。
发现用例
发现用例的一般方法:
●
① 找出系统外部参与者,确定系统边界和范围。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。
●
② 确定各参与者所期望的系统行为。
发现用例
发现用例的一般方法:
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。
用例之间的关系(1)
用例之间的几种关系:
1. 泛化关系
2. 包含关系
3. 扩展关系
第3章 用例图
这里的Actor 是 小猪。
思考:识别参与者?
寻呼台系统:用户如果预定了天气预报,系 统每天定时给他发天气消息;如果当天气温 高于35度,还要提醒用户注意防暑;
在这个叙述里,谁是寻呼台系统的Actor?
用户,气温,时间都是Actor
1、机票购买者通过登录网站购买机票,机票购买者 就是actor
要点:用户观点而非系统观点
旅客
订票 查看今日航班
用户观点
旅客
处理订票 显示今日航班
系统观点
用例的命名
执行者视角:
(状语)动词+(定语+ )宾语
顾客
购买商品 <<extend>> 信用卡支付
要点:用例的粒度(1)
用例要有路径,路径要有步骤;而这一切都 是可观测的
最常犯错误:粒度过细,陷入功能分解
过细的粒度,一般都会导致技术语言的描述, 而不再是业务语言
用例粒度(2)
把步骤当用例
会员
<<include>>
输入用户名
会员
登录
把系统活动当用例
验证用户名和密码
<<include>> 建立数据库连接
查询订单
<<include>>
执行SQL语句
要点:用例的粒度(3)
“四轮马车”
C(Create) R(Read) U(Update) D(Delete)
个参与者。 不同的用户也可以只对应于一个参与者,从而代表同一
参与者的不同实例。
参与者
每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用
(因此也与用例所在的系统或类发生了交互 作用) 参与者的内部实现与用例是不相关的,参与 者可以被一组定义它的状态的属性充分描述。
思考:识别参与者?
寻呼台系统:用户如果预定了天气预报,系 统每天定时给他发天气消息;如果当天气温 高于35度,还要提醒用户注意防暑;
在这个叙述里,谁是寻呼台系统的Actor?
用户,气温,时间都是Actor
1、机票购买者通过登录网站购买机票,机票购买者 就是actor
要点:用户观点而非系统观点
旅客
订票 查看今日航班
用户观点
旅客
处理订票 显示今日航班
系统观点
用例的命名
执行者视角:
(状语)动词+(定语+ )宾语
顾客
购买商品 <<extend>> 信用卡支付
要点:用例的粒度(1)
用例要有路径,路径要有步骤;而这一切都 是可观测的
最常犯错误:粒度过细,陷入功能分解
过细的粒度,一般都会导致技术语言的描述, 而不再是业务语言
用例粒度(2)
把步骤当用例
会员
<<include>>
输入用户名
会员
登录
把系统活动当用例
验证用户名和密码
<<include>> 建立数据库连接
查询订单
<<include>>
执行SQL语句
要点:用例的粒度(3)
“四轮马车”
C(Create) R(Read) U(Update) D(Delete)
个参与者。 不同的用户也可以只对应于一个参与者,从而代表同一
参与者的不同实例。
参与者
每个参与者可以参与一个或多个用例。 参与者通过交换信息与用例发生交互作用
(因此也与用例所在的系统或类发生了交互 作用) 参与者的内部实现与用例是不相关的,参与 者可以被一组定义它的状态的属性充分描述。
第03章 用例和用例图
Icon形式 形式
Label形式 形式
Decoration形式 形式
推荐采用
13
3.2 参与者
由于Actor实际上是一个类 因此它们之间可以存在 由于 实际上是一个类, 实际上是一个类 一定的关系,如 一定的关系 如:
14
第
3章 用例和用例图
3.1 用例 3.2 参与者 3.3 脚本 3.4 用例间的关系 3.5 用例图 3.6 用例的描述 3.7 寻找用例的方法 3.8 用例的常见问题
进行中进行中等待审查等待审查通过审查通过审查未通过审查未通过审查前臵条件前臵条件一个条件列表一个条件列表这些条件必须在访问用例前得到满足这些条件必须在访问用例前得到满足后臵条件后臵条件一个条件列表一个条件列表这些条件必须在用例完成之后得到满足这些条件必须在用例完成之后得到满足基本操作流程基本操作流程描述用例中各项工作都顺利进行时用例的工作方式描述用例中各项工作都顺利进行时用例的工作方式可选操作流程可选操作流程描述变异工作方式出现异常或发生错误的情况下的路径描述变异工作方式出现异常或发生错误的情况下的路径用例的描述用例规约格式3636用例的描述用例的描述3838描述项说明被包含的用例被包含的用例此用例所包含的用例列表此用例所包含的用例列表被扩展的用例被扩展的用例此用例所扩展的用例列表此用例所扩展的用例列表修改历史记录修改历史记录可选可选关于用例的修改时间修改原因修改人的详细信息关于用例的修改时间修改原因修改人的详细信息问题问题可选可选与此用例的开发有关的问题列表与此用例的开发有关的问题列表决策决策可选可选关键决策的列表关键决策的列表将这些决策信息记录下来以便维护时将这些决策信息记录下来以便维护时使用使用频率频率可选可选参与者访问此用例的频率参与者访问此用例的频率每日一次每日一次每月一次等每月一次等用例的描述格式续表3636用例的描述用例的描述3939用例阐述
T3_用例及用例图
1)摘要:需求分析早期使用,通常用于主成功场景
2)非正式:需求分析早期使用,可覆盖不同的场景
3)详述:详细编写所有步骤及各种变化。
二、用例图
1.用例图的作用
1)用例图用来描述软件需求模型中的系统功能,通过一组用例可以描述软件系统能够给用户提供的功能。
2)用例图可以作为整个系统开发过程中的开发依据,指导和驱动其他模型。
2.关联关系:参与者与用例之间是关联关系,表示参与者与用例之间具有使用,交互信息的关联。
3.泛化关系:参与者与参与者之间,用例与用例之间存在一般与特殊的关系。
4.包含关系:
1)两个用例之间,一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。
2)包含关系Βιβλιοθήκη 依赖关系的<<include>>构造型来表示。
周次
第3周,第1次课;总第2次课
章节名称
第三章:用例及用例图
授课方式
课堂讲授(√);上机实验();
实际操作( );课程设计();
教学时数
2
授课方法
和手段
课堂讲授
教学目的
与要求
目的和要求:
1.理解什么是用例及用例图
2.用例的特点
3.用例的构成
4.用例的编写
5.用例的关系
6.如何发现用例
7.案例演示
教学基本内容纲要
5.扩展关系“
1)扩展关系表示基本用例在扩展点要增加新的行为或功能,以扩展到新用例。
2)扩展关系用依赖关系的<<extend>>构造型来表示。
七、如何发现用例
1.发现用例的简单描述:
1)选择系统边界
2)确定主要参与者
3)确定每个主要参与者的目标
2)非正式:需求分析早期使用,可覆盖不同的场景
3)详述:详细编写所有步骤及各种变化。
二、用例图
1.用例图的作用
1)用例图用来描述软件需求模型中的系统功能,通过一组用例可以描述软件系统能够给用户提供的功能。
2)用例图可以作为整个系统开发过程中的开发依据,指导和驱动其他模型。
2.关联关系:参与者与用例之间是关联关系,表示参与者与用例之间具有使用,交互信息的关联。
3.泛化关系:参与者与参与者之间,用例与用例之间存在一般与特殊的关系。
4.包含关系:
1)两个用例之间,一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。
2)包含关系Βιβλιοθήκη 依赖关系的<<include>>构造型来表示。
周次
第3周,第1次课;总第2次课
章节名称
第三章:用例及用例图
授课方式
课堂讲授(√);上机实验();
实际操作( );课程设计();
教学时数
2
授课方法
和手段
课堂讲授
教学目的
与要求
目的和要求:
1.理解什么是用例及用例图
2.用例的特点
3.用例的构成
4.用例的编写
5.用例的关系
6.如何发现用例
7.案例演示
教学基本内容纲要
5.扩展关系“
1)扩展关系表示基本用例在扩展点要增加新的行为或功能,以扩展到新用例。
2)扩展关系用依赖关系的<<extend>>构造型来表示。
七、如何发现用例
1.发现用例的简单描述:
1)选择系统边界
2)确定主要参与者
3)确定每个主要参与者的目标
第3章 用例和用例图-2
3.4.3 扩展关系
在一定条件下,把新的行为加入到已有的 用例中,获得的新用例叫扩展用例,原有 的用例叫基本用例。 扩展用例的规则限制
基本用例必须声明若干“扩展点”(extension point),而扩展用例只能在这些扩展点上增加新的 行为和含义。
<<extend>>
扩展用例
基本用例
<<include>>
参与者、用例间的关系类型
□ 下表是参与者、用例之间关系的总结
3.4 UML中几个概念的区别和联系
□ 关系:模型元素之间的语义联系,包括关联、 泛化、依赖 □ 关联:两个或多个类元(参与者、类、用例、组件等) 之间的关系。描述了类元的实例之间的联系 □ 泛化:特殊和一般的关系 □ 依赖:例如包含关系和扩展关系 目标元素: 被依赖的元素 改变 源 元素: 依赖元素 相应的改变
练习
3.4 用例间的关系
□ 用例之间的关系包括:
① 泛化关系(generalization) ② 包含关系(include) ③ 扩展关系(extend)
3.4.1 泛化关系
□ 泛化(generalization)代表一般与特殊的 关系。 ■ 在泛化关系中,子用例继承了父用例的行 为和含义,子用例也可以增加新的行为和含 义或覆盖父用例中的行为和含义。
父用例
子用例
3.4.1 泛化关系
Validate User
订票
电话订票
网上订票
Retinal Scan
Check Password
□ 什么时候使用泛化关系?
当发现系统中有两个或者多个用例在行为、结构、目 的方面存在共性时就可以使用泛化关系。可以用新的 用例(通常是抽象的)来描述共有部分,这个新用例 就是父用例。
《软件工程》第3章用例图及其应用
用例与参与者之间存在关联关系,表示参与者可以参与用例的执行。这种关系有助于明确系统的边界和 交互方式。
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一,它能 够帮助开发团队更好地理解用户需求,明确系统 的功能范围。
2
通过用例图,开发团队可以对系统的交互方式进 行模拟和验证,从而发现潜在的问题和缺陷,提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
02
针对每个测试场景,细化出具体的测试用例,包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求,从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程,为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系, 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物,它描 述了用户期望的系统功能和行为。
02 在系统设计完成后,可以通过与原始用例图进行 对比,验证设计是否满足原始需求。
03 如果设计不符合原始需求,则需要重新调整设计, 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一,它能 够帮助开发团队更好地理解用户需求,明确系统 的功能范围。
2
通过用例图,开发团队可以对系统的交互方式进 行模拟和验证,从而发现潜在的问题和缺陷,提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
02
针对每个测试场景,细化出具体的测试用例,包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求,从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程,为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系, 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物,它描 述了用户期望的系统功能和行为。
02 在系统设计完成后,可以通过与原始用例图进行 对比,验证设计是否满足原始需求。
03 如果设计不符合原始需求,则需要重新调整设计, 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03
第3章用例及用例图课件
12
总结 用例的特点
① 用例用于描述系统的功能,这个功能是外部 使用者看到的系统功能,不反映功能的实现方 式。 ② 用例描述用户提出的一些可见需求,对应一 个具体的用户目标。 ③ 用例反映系统与用户的一次交互过程,应该 具有交互的信息的传递。 ④ 用例是对系统功能的描述,属于需求建模。
13
4. 怎样确定用例的粒度
35
3.5 用例描述
• 用例名称
– 应该与用例图相符,并写上其相应的编号
• 简要说明
– 对该用例对参与者所传递的价值结果进行描述,应 注意语言简要,使用用户能够阅读的自然语言
• 前置条件
– 是执行用例之前必须存在的系统状态,这部分内容 如果在现在不容易确定可以在后面再细化
• 后置条件
– 用例执行完毕系统可能处于的一组状态,这部分内 容如果在现在不容易确定可以在后面再细化
9、UML是通过什么方法来对语言进 行扩展的?
6
教学进程
第3章
用例及用例图
3.1 用例 3.2 参与者 3.3 用例之间的关系 3.4 用例图 3.5 用例描述 3.6 用例分析
7
3.1 用例
1. 用例的概念 用例(use case): 系统、子系统或类与外部的参与者
交互的动作序列的说明,包括各种序列及出错序列。简 单的说,表示参与者与系统的一次交互过程。 用例分析可以认为是对系统功能的分解。 2.用例的表示
UML除了可以用于软件建模之外,
还可以用于(
)建模。
3
教学进程
?问题:
4、填空 UML的基本语言要素包括( )、
( ) 和 ( )。
4
教学进程
?问题:
5、UML建模元素之间可以有哪几种 关系?
总结 用例的特点
① 用例用于描述系统的功能,这个功能是外部 使用者看到的系统功能,不反映功能的实现方 式。 ② 用例描述用户提出的一些可见需求,对应一 个具体的用户目标。 ③ 用例反映系统与用户的一次交互过程,应该 具有交互的信息的传递。 ④ 用例是对系统功能的描述,属于需求建模。
13
4. 怎样确定用例的粒度
35
3.5 用例描述
• 用例名称
– 应该与用例图相符,并写上其相应的编号
• 简要说明
– 对该用例对参与者所传递的价值结果进行描述,应 注意语言简要,使用用户能够阅读的自然语言
• 前置条件
– 是执行用例之前必须存在的系统状态,这部分内容 如果在现在不容易确定可以在后面再细化
• 后置条件
– 用例执行完毕系统可能处于的一组状态,这部分内 容如果在现在不容易确定可以在后面再细化
9、UML是通过什么方法来对语言进 行扩展的?
6
教学进程
第3章
用例及用例图
3.1 用例 3.2 参与者 3.3 用例之间的关系 3.4 用例图 3.5 用例描述 3.6 用例分析
7
3.1 用例
1. 用例的概念 用例(use case): 系统、子系统或类与外部的参与者
交互的动作序列的说明,包括各种序列及出错序列。简 单的说,表示参与者与系统的一次交互过程。 用例分析可以认为是对系统功能的分解。 2.用例的表示
UML除了可以用于软件建模之外,
还可以用于(
)建模。
3
教学进程
?问题:
4、填空 UML的基本语言要素包括( )、
( ) 和 ( )。
4
教学进程
?问题:
5、UML建模元素之间可以有哪几种 关系?
第三章 用例和用例图
系统边界
… 参与者透过系统边界直接与系统交互,参与者的确定代表
系统边界的确定
有意义交互
任何事物
人、外部系统、外部因素等
武汉大学国际软件学院
12
3.2.2 识别参与者:参与者要点
•
参与者指在系统中所扮演的角色。即在确定参与者时, 应主要考虑他的角色,而不是这个角色的实例。
•
• • •
某些组织中可能有很多营销人员,但他们均起着同 一种作用,扮演着相同的角色。 … 一个用户也可以扮演多种角色:一个高级营销人员
经理
用例C
•
如系统中经理可以参加雇员 的所有用例
武汉大学国际软件学院
21
3.2.2 识别参与者:泛化关系的误用
浏览信息
注册成员
普通浏览者 搜索产品
用户
留言
登录验证身分
系统管理员
回复留言
发送邮件
武汉大学国际软件学院
22
3.2.3 识别用例(use case) 分析典型用例是开发者准确迅速地了解用户要求的最常用 也是最有效的方法,是用户和开发者一起深入剖析系统功 能需求的起点。 “用例”是Ivar Jacobson于20世纪60~70年代在爱立信公 司开发AKE、AXE系列时发明的。
武汉大学国际软件学院
29
用例要点:用户观点而非系统观点
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
武汉大学国际软件学院
30
用例 VS. 功能
•呼叫某人
•传输/接收 •电源/基站 •输入输出(显示、键盘) •电话簿管理 •……
•接听电话
•发送短信 •记住电话号码
•…… 用户观点
第三章用例图
方法2:每个use case 画一个交互图。
32
Create, Retrieve, Update, Delete 类型用例的处理:
– 采用CRUD四个用例还是一个用例? – 从用户需求的角度考虑而不是从数据 处理的角度考虑。
第3章 用例图
东北大学信息科学与工程学院
E-Mail: yanglei@
杨雷
1/336
学习目标
1、掌握用例模型包括内容 2、熟练掌握用例图 3、熟练掌握用例图中的关系 4、掌握用例描述 5、掌握用例图建模技术
2
主要内容 3.1 用例模型概述 3.2 用例图 3.3 用例图中的关系
– 可观测:用例止于系统边界 – 结果值:用例是目标向导的 – 系统执行:结果值是由系统生成的 – 由参与者观测:业务语言,用户观点 – 一组用例实例:用例的粒度
22
可观测
描述交互,而不是内在的系统活动
23
用例是目标导向的
系统的存在是因为:参与者有一些需要使用它 来满足的目标。用例是用来描述系统的目标
10
Use Case的定义
在一个workshop(专题讨论会)上,14位主要的 OO专家对Use Case有14个定义。 定义1:use case是对一个活动者(actor)使用 系统的一项功能时所进行的交互过程的一个文 字描述序列 (见[2])。 定义2:用例是系统、子系统或类和外部的参与 者(actor)交互的动作序列的说明,包括可选的 动作序列和会出现异常的动作序列. (见[3])
ቤተ መጻሕፍቲ ባይዱ12
用例基本思想
问题的提出:在系统尚未存在时,如何描绘用户需 要一个什么样的系统?如何规范地定义用户需求? 考虑问题的思路:把系统看作一个黑箱,看它对外 部的客观世界发挥什么作用,描述它外部可见的行 为。
第3章用例和用例图
□ 包含关系 表示的是用例之间的“has a”关系
3.4.4 用例的泛化、包含、扩展关系
□ 在扩展关系中,基本用例一定是一个well formed的用例,即是可以独立存在的用例。 一个基本用例执行时,可以执行,也可以不 执行扩展部分。
□ 在包含关系中,基本用例可能是、也可能 不是well formed。在执行基本用例时,一定 会执行包含用例(inclusion use case)部分。
3.1 用例
□ 使用用例进行需求分析的特点:
① 从使用者的角度描述系统中的信息 站在系统外部看系统 ② 描述了用户提出的一些可见需求 对应一个具体的用户目标 ③ 对系统行为的动态描述 属于UML的动态建模部分
3.1 用例
UML建模: ① 静态建模 ② 动态建模 ◇ 静态建模:类图、对象图、构件图和 部署图 ◇ 动态建模:用例图、顺序图、协作图、 状态图和活动图。
3.4.3 扩展关系
□ 包含用例和扩展用例
Buy Merchandise Customer
<<include>> <<extend>>
Browse Web Site
Add Order to Warehouse System
3.4.4 用例的泛化、包含、扩展关系
□ 泛化关系和扩展关系 表示的是用例之间的“is a”关系 泛化关系 扩展关系 比泛化关系多了扩展点
Trader
<<extend>>
Capture Deal
SalesPerson
Limits Exceeded
3.6 用例的描述
□ UML初学者 缺少用例的描述或用例的描述不完整 □ 用例是一个“文字描述序列” □ 用例是“动作序列的说明” □ 用例的描述才是用例的主要部分 是后续的交互图分析和类图分析必不可少 的部分。
第3章用例和用例图
特点:由基本用例决定是否调用,包含用例对调 用对象一无所知,且不参与其中的选择判断。
图形表示:
包含关系
使用包含关系的三种情况:
a. 多个用例包含大量类似的行为,应该考虑将这 些类似的行为通过包含关系包含到用例中
b.对两个或多个互相独立的用例建模时做了重复 的工作,可以通过包含关系包含这些重复的工 作
协作的内部由两部分组成:
结构部分:类等建模元素 行为部分:建模元素如何协调工作
图形表示
User
Login
Login realization
Login realization(with security)
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始,考虑每个参与者是如何使用系统的。 参与者要向系统请求什么功能? 每个参与者的特定任务是什么?
Telephone Catalog
用例 参与者与用例间的关系
check status
place order
顾客 用例名
fill orders
establish credit
系统边界
参与者 销售员 货运员 监督员
3.2 参与者
参与者指系统外部的、需要使用系统或与 系统交互的一个实体。
参与用例的执行过程。 通过向系统输入或请求系统输入某些事件
3.6 事件流及脚本
事件流用于描述参与者什么时候激活用例,以及 用例如何完成其任务
1.定义一个事件流
推荐使用叙述式风格,为每一个步骤编号,给每个独 立的部分加标题。
2.定义主事件流
应该覆盖用例执行时,正常发生的情况,是用例事件 流部分所描述的第一个事件流 从定义参与者启动用例的事件着手 描述参与者与系统正常交互 描述用例如何结束
图形表示:
包含关系
使用包含关系的三种情况:
a. 多个用例包含大量类似的行为,应该考虑将这 些类似的行为通过包含关系包含到用例中
b.对两个或多个互相独立的用例建模时做了重复 的工作,可以通过包含关系包含这些重复的工 作
协作的内部由两部分组成:
结构部分:类等建模元素 行为部分:建模元素如何协调工作
图形表示
User
Login
Login realization
Login realization(with security)
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始,考虑每个参与者是如何使用系统的。 参与者要向系统请求什么功能? 每个参与者的特定任务是什么?
Telephone Catalog
用例 参与者与用例间的关系
check status
place order
顾客 用例名
fill orders
establish credit
系统边界
参与者 销售员 货运员 监督员
3.2 参与者
参与者指系统外部的、需要使用系统或与 系统交互的一个实体。
参与用例的执行过程。 通过向系统输入或请求系统输入某些事件
3.6 事件流及脚本
事件流用于描述参与者什么时候激活用例,以及 用例如何完成其任务
1.定义一个事件流
推荐使用叙述式风格,为每一个步骤编号,给每个独 立的部分加标题。
2.定义主事件流
应该覆盖用例执行时,正常发生的情况,是用例事件 流部分所描述的第一个事件流 从定义参与者启动用例的事件着手 描述参与者与系统正常交互 描述用例如何结束
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
17
●
② 确定各参与者所期望的系统行为。
柜台人员 客房预订 预订变更
入住登记
退房结帐 选择课程 信息查询
18
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。
●
③ 把这些系统行为命名为用例。
19
●
④ 确定各用例之间的关系(泛化,包含,扩展)。
20
●
⑤ 绘制用例图。
第 章 用例及用例图-案例
3.7 业务用例图 3.8 案例
3
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– – – – 对机构不熟悉 机构业务发生变更 机构中主要部分使用的软件需建立 机构中有些大型复杂工作流的文档不足
9
●
② 确定各参与者所期望的系统行为。
管理员: 增加课程 修改课程
删除课程
学生: 查询课程 选择课程 网上付费
10
① 找出系统外部参与者,确定系统边界和范围。 ② 确定各参与者所期望的系统行为。
●
③ 把这些系统行为命名为用例。
11
●
④ 确定各用例之间的关系(泛化,包含,扩展)。
12
●
⑤ 绘制用例图。
5
案例1:
• 用例图
6
案例1:
• 优化
7
案例2:
某学校网上选课系统的用例分析
管理员通过系统管理界面进入系统,建立本学 期要开设的各种课程,将课程信息保存到系统中,
并可以对课程进行改动和删除。
学生通过客户机浏览器进入系统,选择课程:
可以查询课程,选择课程,支付课程费用。
8
●
① 找出系统外部参与者,确定系统边界和范围。
21
●
⑥ 编制用例说明明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
●
⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 输入预订人标志信息。 ③ 系统显示该预订人的客房预订信息。 ④ 预订变更。 ⑤ 预订变更成功。
2
3.7 业务用例图
• 业务角色(Business Actor)
– 机构(组织)外部参与者
• 业务工人(Business Worker)
– 机构内部参与者所起作用的表示
• 业务用例(Business Use Case)
– 业务功能(无论是手工还是自动处理)
• 业务机构(Business Organization)
13
●
⑥ 编制用例说明。
● 用例:增加课程
●参与者:管理员 ●操作流:
① 管理员选择进入管理界面,用例开始。 ② 系统提示输入管理员密码。 ③ 管理员输入密码。 ④ 系统检验密码。 A1:密码出错。 ⑤ 进入管理界面,系统显示当前所建立的全部课程信息。 ⑥ 管理员选择增加课程,管理员输入新课程信息。 ⑦系统验证是否与已有课程冲突。 A2:有冲突。 ⑧系统添加新课程,并提示添加成功。
● —— 重要知识点
26
本章作业
(1) 什么叫用例? (2) 用例图在软件建模中的作用是什么? (3) 用例之间存在那几种关系?
(4) 包含关系和扩展关系有什么区别?
(5) 参与者可以是那几种形式? (6) 什么叫事件流,作用是什么?
END
27
23
●
⑥ 编制用例说明。
● 用例:入住登记 ●参与者:柜台工作人员
●说明:
① 工作人员启动入住登记功能。 ② 根据旅客要求查询客房空闲信息。
③ 如果不满足旅客入住要求,则退出。
④ 接收旅客信息。 ⑤ 给旅客分配房间床位。
⑥ 接收押金。
⑦ 打印入住单 ⑧ 入住登记结束。
24
●
⑥ 编制用例说明。
● 用例:退房结帐 ●参与者:柜台工作人员
⑨系统回到管理主界面,显示所有课程,用例结束。
14
●
⑦ 对异常流程确定单独用例。 ⑧ 优化用例图,解决用例之间的冲突和重复。
15
案例3:
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的
功能。
16
●
① 找出系统外部参与者,确定系统边界和范围。
●说明:
① 工作人员启动退房结帐功能。 ② 输入旅客标志信息。
③ 系统显示旅客入住信息。
④ 显示入住天数,费用。 ⑤ 接收费用。
⑥ 打印发票。
⑦ 入住登记结束。
25
● 小结
第3章 用例和用例图
3.1 用例
3.2 参与者
3.3 用例之间的关系 4.3.1 关联关系 4.3.2 泛化关系 4.3.3 包含关系 4.3.4 扩展关系 ● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式 ● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
– 机构的组织部门,业务元素的集合
• 业务实体(Business Entity)
– 机构的主要产品等实体
• 物理工人(Phsical Worker)
– 机构内部人类参与者
3
3.7 业务用例图
4
3.8 实例
• 案例1:
– 有一个爱书之人,家里各类书籍已过千册,平时又 时常有朋友外借,因此需要一个图书管理系统。该 系统应该能够将书籍的基本信息按计算机类、非计 算机类分别建档,实现按书名、作者、类别、出版 社等关键字的组合查询功能。在使用系统录入新书 籍时系统会自动按规则生成书号,以修改信息,但 不能够删除记录。该系统还应该能够对书籍的外借 情况进行记录,可对外借情况列出打印。另外,还 希望能够对书籍的购买金额、册数按特定时限进行 统计。