用例分析技术(课堂PPT)
合集下载
用例建模案例分析【优质PPT】
包含关系的描述
2021/10/10
32
扩展关系的描述
2021/10/10
33
要点：用例粒度-1
• 用例要有路径，路径要有步骤；而这一切都是可 观测的
• 最常犯错误：粒度过细，陷入功能分解 ❖过细的粒度，一般都会导致技术语言的描述， 而不再是业务语言
2021/10/10
34
34
兴趣？
2021/10/10
16
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角 色：值班护士，医生，病人，标准病症信号库。
角色描述模板
角色：病 人
角色职责： 提供病症信号
角色职责识别：
负责生成、实时提供 各种病症信号。
角色：医 生
角色职责： 对病人负责，负责 处理病情的变化 角色职责识别： (1)需要系统支持以完 成其日常工作 (2)对系统运行结果感 兴趣
2021/10/10
更新病历
13
二、简单的需求分析说明
系统名称：医院病房监护系统
根据分析系统主要实现以下功能：
1、病症监视器可以将采集到的病症信号（组 合），格式化后实时的传送到中央监护系统。
2、中央监护系统将病人的病症信号开解后与 标准的病症信号库里的病症信号的正常值进行比 较，当病症出现异常时系统自动报警。
2021/10/10
17
2、识别出系统的用例
通过分析可以初步识别出系统的用例为：中央监护， 病症监护，提供标准病症信号，病历管理，病情报 告管理。顶层用例图为：
值班护士
医生
2021/10/10
中央监护
《使用》 病症监护
病情报 告管理
《使用》
《使用》
提供标准 病症信号
用例和用例图ppt课件
精选课件
6
参与者间的关系
▪ 在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
▪ 示例：
父参与者
子参与者
子参与者
▪ 子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
▪ 子参与者可以出现在父参
与者能出现的任何位置上
精选课件
7
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
使用扩展关系 ▪ 扩展用例总是在一个或多个扩展点处来扩展基本用例，或
处于特定条件下， 才扩展基本用例。
基本用例
扩展点 扩展点名称
<<extend>>
扩展用例
精选课件
21
扩展关系
使用情形
a.两个用例相似但不完全相同时 b.当要对多个额外情况逐一建模时，使用扩展关
系，用一个独立的用例替代每个额外的情况 c.如果用例涵盖了所有的情况变化，则该用例将
识别用例
用例识别
识别用例最好的方法就是从分析系统的参与者开 始，考虑每个参与者是如何使用系统的。
➢ 参与者要向系统请求什么功能？
➢ 每个参与者的特定任务是什么？
➢ 参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
➢ 是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
会变得十分复杂，应该考虑使用扩展关系
精选课件
22
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]
管理任务
第6讲 用例分析
种模型图：描述对象及其交互 这些图按照用例模型来组织，每个用例图都会产生 数张图。如：
类图（class diagram）：描述了构成一类对象特征 的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之间的 交互行为（描述系统行为）
分析模型与用例模型的区别
所有得到的 分析类 应该都是为项目 涉众 产生价值的
牢记：需求分析是发现、求精、建模、规
格说明与复审的过程。
第6讲 用例分析
6.1 理解分析
6.2 从用例开始分析
6.3 架构分析 6.4 构造用例实现 6.5 定义分析类
OOA目标
开发一系列模型来描述计算机软件，从而满足 不同客户定义的需求：建立分析模型
把握分析的“度”
把整个分析活动限制在业务问题域词汇上， 而不考虑任何技术领域的实现策略，目的 是：
保持对系统静态结构和行为的精确和简单陈述
所有与实现相关内容都留给设计和实现阶段来 考虑
课后思考：什么是业务问题域词汇？ 什么是技术领域的实现策略？
把握分析的“度”（续）
分析侧重于系统 主要业务 部分——关注 核心业务场景；对支撑性行为、非功能需 求等不做深入的分析
Administrativ e User Administrativ e User
Login
Login
Employee
Employee
Record Time
Record Time
Create Charge Code
2-重要性——主要完成的业务
Create Employee
分析阶段的用例—用例实现
持久性
类图（class diagram）：描述了构成一类对象特征 的状态和行为（描述软件架构） 交互图（interaction diagram）：描述对象之间的 交互行为（描述系统行为）
分析模型与用例模型的区别
所有得到的 分析类 应该都是为项目 涉众 产生价值的
牢记：需求分析是发现、求精、建模、规
格说明与复审的过程。
第6讲 用例分析
6.1 理解分析
6.2 从用例开始分析
6.3 架构分析 6.4 构造用例实现 6.5 定义分析类
OOA目标
开发一系列模型来描述计算机软件，从而满足 不同客户定义的需求：建立分析模型
把握分析的“度”
把整个分析活动限制在业务问题域词汇上， 而不考虑任何技术领域的实现策略，目的 是：
保持对系统静态结构和行为的精确和简单陈述
所有与实现相关内容都留给设计和实现阶段来 考虑
课后思考：什么是业务问题域词汇？ 什么是技术领域的实现策略？
把握分析的“度”（续）
分析侧重于系统 主要业务 部分——关注 核心业务场景；对支撑性行为、非功能需 求等不做深入的分析
Administrativ e User Administrativ e User
Login
Login
Employee
Employee
Record Time
Record Time
Create Charge Code
2-重要性——主要完成的业务
Create Employee
分析阶段的用例—用例实现
持久性
用例图实例讲解PPT课件
1.借阅者 2.管理员处 3.管理系统
第16页/共20页
1. 借阅者请求服务的用例图
第17页/共20页
2. 图书馆管理员处理借书、还书 的用例图
第18页/共20页
3. 系统管理员进行系统维护的用 例图
第19页/共20页
谢谢您的观看！
第20页/共20页
概述
• 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及 用户需要为系统提供的服务。
• 用例图最常用来描述系统以及子系统。
第1页/共20页
概述
•
用例图包含6个元素：
① 参与者（Actor）
② 用例（Use Case）
③ 关联关系（Association）
④ 包含关系（Include）
⑤ 扩展关系（Extend）
第8页/共20页
关联关系
• 表示参与者用例之间进行通信。 • 不同的参与者可以访问相同的用例。
第9页/共20页
包含关系
• 客户用例可以简单地包含提供者用例具有的行为，并把它所包含 的用例行为作为自身行为的一部分。
第10页/共20页
扩展关系
• 扩展用例被定义为基础用例的增量扩展。 • 基础用例提供扩展点以添加新的行为。 • 扩展用例提供插入片段以插入到基础用例的扩展点上。
第5页/共20页
用例
• 用例的名称： ① 简单名 ② 路径名
第6页/共20页
识别用例
• 识别用例最好的方法就是从分析系统的参与者开始，考虑每/共20页
5.1.4 用例间的关系
• 1 关联关系 • 2 包含关系 • 3 扩展关系 • 4 泛化关系
第14页/共20页
对需求建模
① 识别系统的外部参与者来建立系统的语境。 ② 考虑每一个参与者期望的行为或需要系统提供的行为。 ③ 把这些公共的行为命名为用例。 ④ 确定提供者用例和扩展用例。 ⑤ 对这些用例、参与者和它们之间的关系建模。 ⑥ 用注释修饰用例。
第16页/共20页
1. 借阅者请求服务的用例图
第17页/共20页
2. 图书馆管理员处理借书、还书 的用例图
第18页/共20页
3. 系统管理员进行系统维护的用 例图
第19页/共20页
谢谢您的观看！
第20页/共20页
概述
• 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及 用户需要为系统提供的服务。
• 用例图最常用来描述系统以及子系统。
第1页/共20页
概述
•
用例图包含6个元素：
① 参与者（Actor）
② 用例（Use Case）
③ 关联关系（Association）
④ 包含关系（Include）
⑤ 扩展关系（Extend）
第8页/共20页
关联关系
• 表示参与者用例之间进行通信。 • 不同的参与者可以访问相同的用例。
第9页/共20页
包含关系
• 客户用例可以简单地包含提供者用例具有的行为，并把它所包含 的用例行为作为自身行为的一部分。
第10页/共20页
扩展关系
• 扩展用例被定义为基础用例的增量扩展。 • 基础用例提供扩展点以添加新的行为。 • 扩展用例提供插入片段以插入到基础用例的扩展点上。
第5页/共20页
用例
• 用例的名称： ① 简单名 ② 路径名
第6页/共20页
识别用例
• 识别用例最好的方法就是从分析系统的参与者开始，考虑每/共20页
5.1.4 用例间的关系
• 1 关联关系 • 2 包含关系 • 3 扩展关系 • 4 泛化关系
第14页/共20页
对需求建模
① 识别系统的外部参与者来建立系统的语境。 ② 考虑每一个参与者期望的行为或需要系统提供的行为。 ③ 把这些公共的行为命名为用例。 ④ 确定提供者用例和扩展用例。 ⑤ 对这些用例、参与者和它们之间的关系建模。 ⑥ 用注释修饰用例。
第三章 用例和用例图PPT课件
精选课件
9
3.2.2 识别参与者(actor)
对于一个大系统，难以列出所有用例的清单。此时，应先 列出所有的参与者，然后在对每个参与者列出他所需的所 有用例。即提供了一种获取用例的系统化过程。
“参与者”（活动者、执行…者）是指在系统之外，透过系 统边界与系统进行有意义交互的任何事物。
精选课件
10
3.2 识别参与者
精选课件
14
思考：识别参与者？
• 寻呼台系统：用户如果预定了天气预报，系统每天定
时给他发天气消息；如果当天气温高于35度，还要提 醒用户注意防暑；
在这个叙述里，谁是寻呼台系统的Actor？ 用户？气温？时间？
时间作为参与者，一种习惯用法，用于激活那些系统定 期的、自动执行的用例
精选课件
15
3.2.2 识别参与者：参与者与系统边界
精选课件
40
3.2.4 用例之间的关系
Generalization 泛化关系中，子用例继承父用例的行为和含义，子用例也 可以增加新的行为和含义或覆盖父用例中的行为和含义
<<include>> Include
一个用例（称作基本用例）的行为包含了另一个用例（称 作包含用例）的行为
<<extend>> Extend 扩展关系比泛化关系用更多的规则限制，基础用例提供扩 展点，扩展用例只能在这些扩展点上增加新的行为。
精选课件
19
识别参与者：棋牌馆管理系统
目标：构建一个棋牌馆管理系统 问题描述： 客户通过Internet预订座位，检查座位详情，如果没有空闲 的座位或满意的座位，可以选择进入等候队列。 总台服务员在客户到棋牌馆时，根据客户的预订信息，安排 客户座位。 当客户要离开棋牌馆时，客户到总台服务员办理结账，可以 采用两种方式，一种是现金结账，另一种是银行卡结账，而 银行卡结账将通过与银联POS系统交互来完成。
第2讲用例与UML用例图精品PPT课件
用例与UML用例图
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。
学习目标
上讲回顾 用例的概念 用例分析的过程 使用用例模型捕获系统需求
上讲回顾
UML的全称__________________________________. UML的图基本构造块包括_______和______. UML的基本构造块中的关系包括哪几种__________. UML的图包括哪几种____________. 动态图包括哪些_____________________________. 静态图包括哪些_____________________________. RUP是______________________________________.
评价应聘者
录用应聘者
录用应聘者
拒绝应聘者
拒绝应聘者
参与者的泛化
Employee Manager
面试面应试聘应者 聘者 评评价价应应聘聘者 者 录录用用应应聘聘者者
拒拒绝绝应应聘者聘者
参与者的泛化
• 只有在子参与者使用了父参与者所使用的 所有用例时，参与者泛化才是合适的。
• 参与者泛化会带来不必要的复杂性，所以 不要强加一个不存在的关系。
用例的特点 ： 用例捕获某些用户可见的需求，实现一个具 体的用户目标。 用例由参与者激活，并提供确切的值给参与 者。 用例可大可小，但它必须是对一个具体的用 户目标实现的完整描述。
参与者（Actor）
参与者是指对用例所描述的事件序列的发 起者。
参与者可以是一个人、另一个系统、一台 硬件设备或某段时间的流逝。
后置条件：顾客得到现金
事件流
（1）事件流由简短步骤的序列组成。 （2）陈述性的、带编号、按时间排序 （3）每个步骤简单地描述了什么东西执
行了什么动作。 每个步骤应该具有如下格式： <编号> <某事> <行为> （4）一个事件流仅描述用例中的一条路径， 不包括其它的分支。
需求分析——UML用例图PPT课件
-32-
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
用例分析与用例图ppt课件
前言之一
软件开发过程中常见的场景
这个做还不错，不过 好像不是我想要的。
我们这很混乱，你这 个系统应该把我们的 所有问题全部解决掉
！
你这做的是什么 东西！
“弱弱”地问：“您 到底想要什么？”
前言之二
需求分析与管理—软件开发过程中的“永远 的痛”
基于用例的分析与设计
以用例为中心组织需求
性能 可用性
√
会员
检索零件
系统执行：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
参与者观测：用户观点而非系统观点
旅客
订票 查看今日航班
用户观点
旅客
处理订票 显示今日航班
系统观点
用例粒度
• 用例要有路径，路径要有步骤；而 这一切都是可观测的
• 最常犯错误：粒度过细，陷入功能 分解
–过细的粒度，一般都会导致技术语 言的描述，而不再是业务语言
• 所有业务最终会成为CRUD？ • CRUD能为Actor提供价值？ • CRUD掩盖业务，锐变成关系数据库的建模：
– “系统就是数据的增删改查” – 关心数据的存储和维护，反而忽略了用户的目的
用例粒度-4
• 如果确实是CRUD？
– 如果CRUD不涉及复杂的交互，一个 用例“管理××”即可
– 不管是C、R、U、D，都是为了完成
– 关键词：边界 – 参与者：在系统之外，透过
系统边界与系统进行有意义 交互的任何事物
边界---Boundary
• 也叫系统边界，用于界定系统功能范围
用一个带名称的矩形框，把描述系统功能的用 例都置于其中，而描述的与系统交互的角色都 置于其外
系统----完整系统或子系统 一个系统包括一个或多个用例
图书馆管理系统用例分析ppt课件
8.成功保证（或后置条件）：存储注册信息、修改个人信息查询个人信 息。
9.主成功场景（或基本流程）： 1.管理员返回是否需要注册。 2.进入注册界面，输入各种信息注册。 3.注册成功，进入各种界面。 4.可以查询读者注册信息，可以允许修改。 5.完成各种操作，退出系统。
10.特殊要求： 1.适用于window系统 2.由于某些原因，我们希望访问的时候出现问题，系统能比较强的
管理员：希望每个读者成功注册并系统能快捷传递给管理员。 读者：希望以最短的时间完成注册操作，能登陆各个操作界面。 6.前置条件：读者必须经过确认和认证。 7.成功保证（或后置条件）：存储注册信息、修改个人信息、查询个 人信息。
——场景描述 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
惩罚金
——用例图 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
4.借书者用例
借书者
书籍借阅处理 创建借书记录 更新读者信息 更新图书信息
检查读者账号
——场景描述 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
书籍：book Bnum: Int Bname:nvarchar Bkinds: nvarchar Bwriter:nvarchar Bpub:nvarchar Bdate:datetime
find(); void create(); void destroy(); void borrow(); void return_back(); void
管理员
修改个人信息 查询书籍信息
增加书籍或者类型 修改书籍或者类型
9.主成功场景（或基本流程）： 1.管理员返回是否需要注册。 2.进入注册界面，输入各种信息注册。 3.注册成功，进入各种界面。 4.可以查询读者注册信息，可以允许修改。 5.完成各种操作，退出系统。
10.特殊要求： 1.适用于window系统 2.由于某些原因，我们希望访问的时候出现问题，系统能比较强的
管理员：希望每个读者成功注册并系统能快捷传递给管理员。 读者：希望以最短的时间完成注册操作，能登陆各个操作界面。 6.前置条件：读者必须经过确认和认证。 7.成功保证（或后置条件）：存储注册信息、修改个人信息、查询个 人信息。
——场景描述 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
惩罚金
——用例图 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
4.借书者用例
借书者
书籍借阅处理 创建借书记录 更新读者信息 更新图书信息
检查读者账号
——场景描述 在日常生活中，随处都可以看到浪费粮食的现象。也许你并未意识到自己在浪费，也许你认为浪费这一点点算不了什么
书籍：book Bnum: Int Bname:nvarchar Bkinds: nvarchar Bwriter:nvarchar Bpub:nvarchar Bdate:datetime
find(); void create(); void destroy(); void borrow(); void return_back(); void
管理员
修改个人信息 查询书籍信息
增加书籍或者类型 修改书籍或者类型
第4章用例及用例图(同济大学软件工程硕士面向对象技术)精品PPT课件
用例的事件流是对系统行为的动态描述
取款 用例的动态事件流
a 通过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM记录事务到日志文件。
Sales system ListProducts OrderProducts AcceptPayment CalcualteCommission
用例的泛化关系
父类用例
- 查找产品
两个子类：
- 查找书籍 - 查找CD
Sales system
Customer
FindProduct
FindBook
FindCD
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ● ⑤ 绘制用例图。
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ● ⑥ 编制用例说明。
① 通过读卡机，储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号。 ③ 储户键入密码，系统检验密码。 ④储户输入取款金额，按确认键。 ⑤ATM把帐号和取款金额传递给银行系统，取回确认信息和帐户
余额。 ⑥ ATM输出现金，并显示帐户余额。 ⑦ATM记录事务到日志文件。
取款用例描述另一种描述
取款 用例的动态事件流
a 通过读卡机，储户插入ATM卡
b ATM系统从卡上读取银行ID、帐号、并验证帐号。 c 储户键入密码，系统检验密码。 d 储户按确认键，输入取款金额。 e ATM把帐号和取款金额传递给银行系统，取回帐户余额。 f ATM输出现金，并显示帐户余额。 d ATM记录事务到日志文件。
Sales system ListProducts OrderProducts AcceptPayment CalcualteCommission
用例的泛化关系
父类用例
- 查找产品
两个子类：
- 查找书籍 - 查找CD
Sales system
Customer
FindProduct
FindBook
FindCD
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ● ⑤ 绘制用例图。
发现用例
发现用例的一般方法：
① 找出系统外部参与者，确定系统边界和范围。 ② 确定各参与者所期望的系统行为。 ③ 把这些系统行为命名为用例。 ④ 确定各用例之间的关系(泛化，包含，扩展)。 ⑤ 绘制用例图。 ● ⑥ 编制用例说明。
① 通过读卡机，储户插入ATM卡 ② ATM系统从卡上读取银行ID、帐号、并验证帐号。 ③ 储户键入密码，系统检验密码。 ④储户输入取款金额，按确认键。 ⑤ATM把帐号和取款金额传递给银行系统，取回确认信息和帐户
余额。 ⑥ ATM输出现金，并显示帐户余额。 ⑦ATM记录事务到日志文件。
取款用例描述另一种描述
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 这些术语通常来自于问题域中的术语表 。
• 用例事件流最终要描述所有可能的过程 。
2020/7/20
22
用例实例的事件流
• 一系列动作实际上是贯穿整个系统的某个特定事件流，即一个实 例。
• 可能会有许多事件流，而许多事件流可能非常相似。 • 为了使用例模型便于理解，应该将相似的事件流组合到一个用例
• 现代社会对象之间的交互主要是信息交 互。
2020/7/20
4
用例是描述交互行为的一种方法
• 人类社会的对象之间交互需要计算机的 帮助。
• 计算机是社会对象之间交互的一种工具 ，利用它去尽量模拟真实的社会。
• 用例是描述人类社会对象之间交互行为 的一种方法。
2020/7/20
5
用例是捕获需求的一种方法
• 用的定义对于我们捕获需求、用例 描述、用例粒度分析有直接的帮助 。
2020/7/20
10
参与者(角色)
• 是系统之外与系统能产生交互作用 的某个人或某件事。
• 软件是由人来使用的，操作者使用 用例来完成他的任务，许多任务的 集合代表了操作者的职责。
• 系统是我们的研究对象；参与者与 之交互，用例定义了这些交互作用 。
2020/7/20
20
用例实例的概念
• 一个用例实例是一个用例的行为。 • 一个用例一定包含一组用例实例。 • 一个用例的一组用例实例完整的说明了一个用例的所
有可能的行为状况。 • 用例实例并不与其它用例实例交互。 • 用例实例是系统执行的一系列动作。
2020/7/20
21
事件流
• 事件流描述了参与者与系统之间的动作 序列，它用自然语言写成，或者用含有 精确术语的前后一致的散文写成。
可以从几个选项中决定下一步
应该做什么。
2020/7/20
• 任何软件产品都面向软件产品 的操作者和一些特定的操作者 以及这些操作者的不同的使用 环境，重视不同的操作者以 及它们不同的使用环境可确 保软件产品的价值。
ATM机 环境： 学校 操作者:学生
ATM机 环境：北京王府井 操作者:购物者
2020/7/20
17
ATM机用例图
• 银行客户可以通过使 用自动取款机提款、 查询帐户余额、修改 帐户密码。
• 用例通常作为一种捕获需求和对已知功能需求 进行建模的方法而被使用。
• 用例提供了一种大部分项目相关人员都能理解 的形式来表述问题。
• 用例确实是需求，但用例不是所有的需求。 • 用例只是行为需求，外部接口、数据格式、业
务规则、计算公式等是用例行为需求的聚集。
2020/7/20
6
用例是软件开发过程的基础
• 这些功能可以通过一 组用例表示出来。
• 用例名称通常可以表 达提供给参予者的价 值。
2020/7/20
18
用例
2020/7/20
19
用例的概念
• 用例可以用来捕获系统的 需求，尤其是交互系统的 需求。
• 每一个用例代表了一个特 定的事件流。
• 一组用例就可以定义系统 的功能。
• 一个用例是一种规格说明 ，它规定了动态事物的一 种对交互双方有价值的行 为。
2020/7/20
15
有价值的可见结果
• 动作序列一定要产生对系统的参与 者有价值的结果
• 可见结果表达了交互的作用 • 重视价值可确保用例的适度性 • 可确保用户理解用例的粒度水平。
2020/7/20
16
特定的操作者
• 重视特定的操作者可帮助我们 分隔提供给系统某一组特定用 户的价值,确保系统满足它们 的需要。
• 以用例为单位进行项目状态的追踪和管 理。
• 以用例中的各种元素为单位进行度量。
2020/7/20
8
用例分析中的一些概念
• 用例 • 参与者(角色) • 用例实例(情景或场景) • 事件流 • 用例实现
2020/7/20
9
用例的定义
• 系统的参与者与系统交互后,由系统 所执行的动作序列,对特定的操作者 产生可以观察到的有价值的结果值 。
用例分析技术
2020/7/20
1
用例分析技术
• 用例概念 • 用例 • 用例图
2020/7/20
2
用例概念
2020/7/20
3
用例的交互概念
• 人类的社会是社会对象之间交互的社会 。
• 社会对象之间的交互使社会充满活力。
• 交互产生运动、摩擦和阻力，所以还需 要能量。
• 最终消耗能量的运动产生新的有价值的 结果(产品)。
理解,将同一类事件流合并为一个用例。 • 动作序列可以用状态图或活动图说明，它
是用例的一条路径，并可能存在多条类似 的路径(候选动作序列)。
2020/7/20
13
动作序列的描述
• 用例实例被初始化并进入开始状态。
• 由参与者发出的外部消息激活。
• 通过执行一个动作序列(顺序图或活动图)转移 到其它状态。
中。 • 确定和说明某个用例实际上就是确定和说明一组相关的事件流。
2020/7/20
23用例实例的路径 Nhomakorabea• 一个用例具有许多可能的实例 。
• 一个用例实例几乎可以遵循无 限多的路径，但这些路径仍然 可以计数。
• 路径代表了用例事件流说明中 的用例实例可以选择的各种方 案。路径的选择取决于事件。
• 事件类型包括： • 来自主角的输入。例如，主角
2020/7/20
11
动作
• 是一个计算程序或算法程序，在参与者 或系统得到一个事件时被调用。
• 动作是原子的，或是执行全部动作或是 根本不执行。
• 动作中不能由操作者打断。 • 一个动作的完成意味着将某种信号传递
给调用动作的参与者。
2020/7/20
12
动作序列
• 贯穿于系统的事件流。 • 有各种各样的事件流，为使用例模型易于
• 用例通过定义由系统执行的行为提供了 要开发的软件可视化的线索。
• 用例驱动的软件开发过程中，为系统定 义的用例是软件开发过程的基础。
• 用例可以协调不同模型的同步。
2020/7/20
7
用例适合于项目管理
• 用例用来定义迭代的内容。
• 通过功能点分析技术从用例描述中导出 工作量估计。
• 以用例为单位制定开发计划。
• (在新的状态)等待由参与者发出的另一个外部 消息。
• 再次由新消息所激发，依次类推，可能经过许 多状态(状态图)直到用例实例结束。
2020/7/20
14
系统执行
• 系统是我们的研究对象；参与者与之交 互，用例定义了这些交互作用。
• 我们关心系统要做些什么才能完成动作 序列，用例帮助我们限定系统的边界(范 围)
• 用例事件流最终要描述所有可能的过程 。
2020/7/20
22
用例实例的事件流
• 一系列动作实际上是贯穿整个系统的某个特定事件流，即一个实 例。
• 可能会有许多事件流，而许多事件流可能非常相似。 • 为了使用例模型便于理解，应该将相似的事件流组合到一个用例
• 现代社会对象之间的交互主要是信息交 互。
2020/7/20
4
用例是描述交互行为的一种方法
• 人类社会的对象之间交互需要计算机的 帮助。
• 计算机是社会对象之间交互的一种工具 ，利用它去尽量模拟真实的社会。
• 用例是描述人类社会对象之间交互行为 的一种方法。
2020/7/20
5
用例是捕获需求的一种方法
• 用的定义对于我们捕获需求、用例 描述、用例粒度分析有直接的帮助 。
2020/7/20
10
参与者(角色)
• 是系统之外与系统能产生交互作用 的某个人或某件事。
• 软件是由人来使用的，操作者使用 用例来完成他的任务，许多任务的 集合代表了操作者的职责。
• 系统是我们的研究对象；参与者与 之交互，用例定义了这些交互作用 。
2020/7/20
20
用例实例的概念
• 一个用例实例是一个用例的行为。 • 一个用例一定包含一组用例实例。 • 一个用例的一组用例实例完整的说明了一个用例的所
有可能的行为状况。 • 用例实例并不与其它用例实例交互。 • 用例实例是系统执行的一系列动作。
2020/7/20
21
事件流
• 事件流描述了参与者与系统之间的动作 序列，它用自然语言写成，或者用含有 精确术语的前后一致的散文写成。
可以从几个选项中决定下一步
应该做什么。
2020/7/20
• 任何软件产品都面向软件产品 的操作者和一些特定的操作者 以及这些操作者的不同的使用 环境，重视不同的操作者以 及它们不同的使用环境可确 保软件产品的价值。
ATM机 环境： 学校 操作者:学生
ATM机 环境：北京王府井 操作者:购物者
2020/7/20
17
ATM机用例图
• 银行客户可以通过使 用自动取款机提款、 查询帐户余额、修改 帐户密码。
• 用例通常作为一种捕获需求和对已知功能需求 进行建模的方法而被使用。
• 用例提供了一种大部分项目相关人员都能理解 的形式来表述问题。
• 用例确实是需求，但用例不是所有的需求。 • 用例只是行为需求，外部接口、数据格式、业
务规则、计算公式等是用例行为需求的聚集。
2020/7/20
6
用例是软件开发过程的基础
• 这些功能可以通过一 组用例表示出来。
• 用例名称通常可以表 达提供给参予者的价 值。
2020/7/20
18
用例
2020/7/20
19
用例的概念
• 用例可以用来捕获系统的 需求，尤其是交互系统的 需求。
• 每一个用例代表了一个特 定的事件流。
• 一组用例就可以定义系统 的功能。
• 一个用例是一种规格说明 ，它规定了动态事物的一 种对交互双方有价值的行 为。
2020/7/20
15
有价值的可见结果
• 动作序列一定要产生对系统的参与 者有价值的结果
• 可见结果表达了交互的作用 • 重视价值可确保用例的适度性 • 可确保用户理解用例的粒度水平。
2020/7/20
16
特定的操作者
• 重视特定的操作者可帮助我们 分隔提供给系统某一组特定用 户的价值,确保系统满足它们 的需要。
• 以用例为单位进行项目状态的追踪和管 理。
• 以用例中的各种元素为单位进行度量。
2020/7/20
8
用例分析中的一些概念
• 用例 • 参与者(角色) • 用例实例(情景或场景) • 事件流 • 用例实现
2020/7/20
9
用例的定义
• 系统的参与者与系统交互后,由系统 所执行的动作序列,对特定的操作者 产生可以观察到的有价值的结果值 。
用例分析技术
2020/7/20
1
用例分析技术
• 用例概念 • 用例 • 用例图
2020/7/20
2
用例概念
2020/7/20
3
用例的交互概念
• 人类的社会是社会对象之间交互的社会 。
• 社会对象之间的交互使社会充满活力。
• 交互产生运动、摩擦和阻力，所以还需 要能量。
• 最终消耗能量的运动产生新的有价值的 结果(产品)。
理解,将同一类事件流合并为一个用例。 • 动作序列可以用状态图或活动图说明，它
是用例的一条路径，并可能存在多条类似 的路径(候选动作序列)。
2020/7/20
13
动作序列的描述
• 用例实例被初始化并进入开始状态。
• 由参与者发出的外部消息激活。
• 通过执行一个动作序列(顺序图或活动图)转移 到其它状态。
中。 • 确定和说明某个用例实际上就是确定和说明一组相关的事件流。
2020/7/20
23用例实例的路径 Nhomakorabea• 一个用例具有许多可能的实例 。
• 一个用例实例几乎可以遵循无 限多的路径，但这些路径仍然 可以计数。
• 路径代表了用例事件流说明中 的用例实例可以选择的各种方 案。路径的选择取决于事件。
• 事件类型包括： • 来自主角的输入。例如，主角
2020/7/20
11
动作
• 是一个计算程序或算法程序，在参与者 或系统得到一个事件时被调用。
• 动作是原子的，或是执行全部动作或是 根本不执行。
• 动作中不能由操作者打断。 • 一个动作的完成意味着将某种信号传递
给调用动作的参与者。
2020/7/20
12
动作序列
• 贯穿于系统的事件流。 • 有各种各样的事件流，为使用例模型易于
• 用例通过定义由系统执行的行为提供了 要开发的软件可视化的线索。
• 用例驱动的软件开发过程中，为系统定 义的用例是软件开发过程的基础。
• 用例可以协调不同模型的同步。
2020/7/20
7
用例适合于项目管理
• 用例用来定义迭代的内容。
• 通过功能点分析技术从用例描述中导出 工作量估计。
• 以用例为单位制定开发计划。
• (在新的状态)等待由参与者发出的另一个外部 消息。
• 再次由新消息所激发，依次类推，可能经过许 多状态(状态图)直到用例实例结束。
2020/7/20
14
系统执行
• 系统是我们的研究对象；参与者与之交 互，用例定义了这些交互作用。
• 我们关心系统要做些什么才能完成动作 序列，用例帮助我们限定系统的边界(范 围)