使用用例建模系统需求PPT课件

第七章 使用用例建 模系统需求
.
1
7.1 用例建模概述
100%
16%
80%
60%
53%
40%
20%
31%
0%
1
项目成功率
27%
26%
33%
46%
40%
28%
2
3
年
Standish Group报告的项目成功率
.
成功的 有挑战的 失败的
2
7.1 用例建模概述
• 以用户为中心的开发是一个系统开发过程， 该过程基于对关联人员的需求，以及对开 发该系统原因的充分理解之上。
扩扩扩扩
生成仓库 打包定单
<<ext ends>>
计算定单 总额和销
售税
<<ext ends>>
提交新会 员定单
.
8
7.2.3.3 使用（或包含）关系
• 抽象用例通过组合几个用例中公共的步骤 来降低用例之间的冗余。
.
9
7.2.3.4 依赖关系
• 依赖是用例之间的一种关系，表示一个用 例需要等到另一个用例执行之后才能执行。
.
17
• 记录用例的事件过程
• 用例的典型事件过程是从参与者发起用例直到业务事件结 束的步骤描述。
• 用例描述包括：
– 前置条件 – 触发器 – 典型事件过程 – 替代过程 – 结论 – 后置条件 – 业务规则 – 实现约束和说明 – 假设 – 开放问题理
• 7.4.1 分级和评估用例 • 用例分级和评估矩阵使用6个标准按1~5级
• 用例是一个行为上相关的步骤序列，既可 以是自动的也可以是手工的，其目的是完 成一个单一的业务任务。
用例符号
.
5
7.2.2 参与者
• 参与者代表了需要同系统交互以交换信息 的任何事物。
• 参与者代表了同系统交互的用户所扮演的 角色，而不代表一个人或者工作职位。
• 四类主要的参与者：
– 主要业务参与者
.
10
7.2.3.5 继承关系
• 继承是参与者之间的一种关系，创建继承 关系的目的是当一个抽象参与者继承多个 实际参与者的角色时简化绘图。
.
11
7.3 需求用例建模过程
• 7.3.1 第1步：确定业务参与者 • 7.3.2 第2步：确定业务需求用例 • 7.3.3 第3步：构造用例模型图 • 7.3.4 第4步：记录业务需求用例描述
• 用例使用输入的名称前加一个行动动词命 名。
.
15
7.3.3 第3步：构造用例模型图
• 用例模型图描述系统范围和边界。
• 用例被组合成业务子系统。子系统表示业 务过程的逻辑功能区。
.
16
7.3.4 第4步：记录业务需求用例描述
• 用例描述：作者、日期、版本、用例名称、 用例类型、用例ID、优先权、来源、主要 业务参与者、其他参与者、有利益的关联 人员、描述
评估用例。
–对架构设计的重要影响 –容易实现但包含重要功能 –包含有风险、时间紧迫或者复杂的功能 –需要大量的研究或者新的、有风险的技术 –包含主要的业务功能 –将增加或者减少费用
.
19
7.4.2 确定用例依赖关系
• 用例依赖关系图具有以下优点：
– 系统事件及其状态的图形化表述有利于对系统 功能的理解
• 用例建模是使用用例的方法来描述系统的 功能需求的过程
.
3
7.2 用例建模的系统概念
• 用例图是描述系统与外部其他系统以及用 户之间交互的图形。换句话说，用例图描 述了谁将使用系统，用户希望以什么方式 与系统交互。
• 用例描述是业务时间以及用户如何同系统 交互以完成任务的文字描述。
.
4
7.2.1 用例
– 有助于确定遗漏的用例 – 通过描述哪个用例更关键并需要最高优先权，
有助于推动项目管理
.
20
.
12
7.3.1 第1步：确定业务参与者
• 谁或者什么为系统提供输入 • 谁或者什么接收系统的输出 • 需要与其他系统连接的接口吗 • 是否存在在预定的时间自动触发的事件 • 谁将维护系统中的信息
.
13
7.3.2 第2步：确定业务需求用例
• 业务需求用例是在需求分析过程中为了捕捉用户 与系统之间交互而建立的用例，并没有技术和实 现细节，也称为基本用例。
• 寻找用例时，询问以下问题：
– 参与者的主要任务是什么 – 参与者需要系统什么信息 – 参与者为系统提供什么信息 – 系统需要通知参与者发生的变化和事件吗 – 参与者需要通知系统发生的变化和事件吗
.
14
7.3.2 第2步：确定业务需求用例
• 上下文图是分析参与者和发现潜在用例的 极好来源。
• 触发组织内的业务事件的主要输入被认为 是用例，提供这些输入的外部各方被认为 是参与者。
– 主要系统参与者
– 外部服务参与者 – 外部接收参与者
.
6
7.2.3 关系
• 7.2.3.1 关联关系 • 关联关系是一个参与者与一个用例发生交互
的关系。
俱乐部会员
提交新会 员定单
分销中心
.
7
7.2.3.2 扩展关系
• 扩展用例是一个由从某个更复杂的用例中提取 出来的步骤构成的用例，以便简化原始用例并 扩展其功能。