面向对象的分析设计之RUP基础及用例建模

出家如初 成佛有余httpwwwyeeachcom

2008年 12月

面向对象的分析设计培训大纲

2

3

目 录

RUP基础业务建模需求分析编写有效用例

什么是 Rational Unified Process Rational Unified Process（简称 RUP）是一个面向对象软件工程的通用业务流程它描述了一系列相关的软件工程流程 RUP 为在开发组织中分配任务和职责提供了一种规范方法其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件RUP又是一套软件工程方法的框架各个组织可根据自身的实际情况以及项目规模对 RUP进行裁剪和修改以制定出合乎需要的软件工程过程

4

RUP 是最佳软件开发经验的总结

迭代式开发（ develop software iteratively）管理需求（ manage requirements）使用基于构件的体系结构（ use component-based

architectures）可视化软件建模（ visually model software）验证软件质量（ verify model quality）控制软件变更（ control changes to software）

5

RUP 的核心思想

尽早并且持续的化解重大风险否则带来很多麻烦风险列表是不断变化的要持续不断的化解风险用例驱动确保满足客户需求用例的主要优势是使团队成员在设计实现测试和最终编写用户手册的过程中紧紧的以用户需求为中心把注意力放在可执行软件上可执行软件使项目进度的最好体现对项目进度评估时尽可能以正在编写以及正在运行的代码和通过测试的用例为标准

6

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

3

目 录

RUP基础业务建模需求分析编写有效用例

什么是 Rational Unified Process Rational Unified Process（简称 RUP）是一个面向对象软件工程的通用业务流程它描述了一系列相关的软件工程流程 RUP 为在开发组织中分配任务和职责提供了一种规范方法其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件RUP又是一套软件工程方法的框架各个组织可根据自身的实际情况以及项目规模对 RUP进行裁剪和修改以制定出合乎需要的软件工程过程

4

RUP 是最佳软件开发经验的总结

迭代式开发（ develop software iteratively）管理需求（ manage requirements）使用基于构件的体系结构（ use component-based

architectures）可视化软件建模（ visually model software）验证软件质量（ verify model quality）控制软件变更（ control changes to software）

5

RUP 的核心思想

尽早并且持续的化解重大风险否则带来很多麻烦风险列表是不断变化的要持续不断的化解风险用例驱动确保满足客户需求用例的主要优势是使团队成员在设计实现测试和最终编写用户手册的过程中紧紧的以用户需求为中心把注意力放在可执行软件上可执行软件使项目进度的最好体现对项目进度评估时尽可能以正在编写以及正在运行的代码和通过测试的用例为标准

6

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

什么是 Rational Unified Process Rational Unified Process（简称 RUP）是一个面向对象软件工程的通用业务流程它描述了一系列相关的软件工程流程 RUP 为在开发组织中分配任务和职责提供了一种规范方法其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件RUP又是一套软件工程方法的框架各个组织可根据自身的实际情况以及项目规模对 RUP进行裁剪和修改以制定出合乎需要的软件工程过程

4

RUP 是最佳软件开发经验的总结

迭代式开发（ develop software iteratively）管理需求（ manage requirements）使用基于构件的体系结构（ use component-based

architectures）可视化软件建模（ visually model software）验证软件质量（ verify model quality）控制软件变更（ control changes to software）

5

RUP 的核心思想

尽早并且持续的化解重大风险否则带来很多麻烦风险列表是不断变化的要持续不断的化解风险用例驱动确保满足客户需求用例的主要优势是使团队成员在设计实现测试和最终编写用户手册的过程中紧紧的以用户需求为中心把注意力放在可执行软件上可执行软件使项目进度的最好体现对项目进度评估时尽可能以正在编写以及正在运行的代码和通过测试的用例为标准

6

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 是最佳软件开发经验的总结

迭代式开发（ develop software iteratively）管理需求（ manage requirements）使用基于构件的体系结构（ use component-based

architectures）可视化软件建模（ visually model software）验证软件质量（ verify model quality）控制软件变更（ control changes to software）

5

RUP 的核心思想

尽早并且持续的化解重大风险否则带来很多麻烦风险列表是不断变化的要持续不断的化解风险用例驱动确保满足客户需求用例的主要优势是使团队成员在设计实现测试和最终编写用户手册的过程中紧紧的以用户需求为中心把注意力放在可执行软件上可执行软件使项目进度的最好体现对项目进度评估时尽可能以正在编写以及正在运行的代码和通过测试的用例为标准

6

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 的核心思想

尽早并且持续的化解重大风险否则带来很多麻烦风险列表是不断变化的要持续不断的化解风险用例驱动确保满足客户需求用例的主要优势是使团队成员在设计实现测试和最终编写用户手册的过程中紧紧的以用户需求为中心把注意力放在可执行软件上可执行软件使项目进度的最好体现对项目进度评估时尽可能以正在编写以及正在运行的代码和通过测试的用例为标准

6

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 的核心思想 ( 续 )

尽早在项目中适应变化RUP要求在初识阶段结束时达成对系统总体外貌的共识在细化阶段结束时候建立系统构架的基线（设计实现测试的构架）在构造阶段结束时候完成ldquo特性冻结rdquo在早期确定一个可执行的构架（ architectural）确立了系统的构架就识别出了在创建系统时候会遇到的许多最复杂的困难

7

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 的核心特点

用例驱动以架构为中心迭代和增量开发

8

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

ldquo4+1rdquo 视图

bullProcess

View

bullDeployment

View

bullLogical

View

bullImplementation

View

bullProgrammers

bullSoftware management

bullPerformance

bullScalability

bullThroughput

bullSystem IntegratorsbullSystem topology

bullDelivery installation

bullcommunication

bullSystem Engineering

bullUse-Case

View

bullStructure

bullAnalysts

Designers bullEnd-user bullFunctionality

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 基本架构

10

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 主要的建模元素

开发流程定义了ldquo谁rdquoldquo何时rdquoldquo如何rdquo做ldquo某事rdquo四种主要的建模元素被用来表达 RUP

角色（ Workers）谁活动（ Activities）如何产物（ Artifacts）某事工作流（ Workflows）何时

11

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 的核心概念

12

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 的核心工作流

6 个核心工程工作流 商业建模工作流 需求工作流 分析和设计工作流 实现工作流 测试工作流 分发工作流

3 个核心支持工作流项目管理工作流配置和变更控制工作流环境工作流

13

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 开发过程阶段 - 初始阶段

主要目标

建立项目的软件规模和边界条件包括运作前景验收标准以及希望产品中包括和不包括的内容识别系统的关键用例对比一些主要场景展示至少一个备选构架 评估整个项目的总体成本和进度评估潜在的风险（源于各种不可预测因素）准备项目的支持环境

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 开发过程阶段 - 细化阶段主要目标

确保构架需求和计划足够稳定充分减少风险从而能够有预见性地确定完成开发所需的成本和进度处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架制作产品质量构件的演进式原型证明已建立基线的构架将在适当时间以合理的成本支持系统需求建立支持环境（创建开发案例创建模板和指南安装工具）

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 开发过程阶段 - 构建阶段

主要目标完成所有所需功能的分析开发和测试迭代式递增式地开发为部署应用程序作好准备

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

RUP 开发过程阶段 - 移交阶段

主要目标确保最终用户可以使用软件培训用户和维护人员 根据产品的完整前景和验收标准对部署基线进行的评估

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

面向对象开发过程

业务建模需求分析设计构建测试部署

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

19

目 录

RUP基础业务建模需求分析编写有效用例

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务建模的目的

目的了解目标组织（将要在其中部署系统的组织）的结构及机制了解目标组织中当前存在的问题并确定改进的可能性确保客户最终用户和开发人员就目标组织达成共识导出支持目标组织所需的系统需求

为实现这些目标业务建模工作流程说明了如何拟定新目标组织的前景并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程角色以及职责作为对这些模型的补充还编写了以下文档补充业务规约词汇表

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务建模 - 工作流程明细

21

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务建模 - 活动概述

22

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务建模 - 工件

23

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

从业务模型到系统

24

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务模型和系统 Actor

25

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

业务建模成果组织结构视图概述业务中的关键角色和职责以及他们的分组情况

业务流程视图包括业务的关键业务流程并对其进行概述这些流程是业务存在的原因

文化视图表述对组织文化前景的设想并定义为促进该文化而应用的机制

人力资源状况视图讨论为维持和发展公司职员的技能而应用的机制

领域视图（可选）对于处理结构复杂信息的组织通常需要定义应用于这些信息结构的关键机制和模式在简单的情况下组织结构视图中可能已经清楚地表示了领域视图

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

27

目 录

RUP基础业务建模需求分析编写有效用例

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

什么是需求需求是指系统必须符合的条件或具备的功能功能性系统无需考虑物理约束而必须能够执行的动作非功能性bull 可用性bull 可靠性bull 性能bull 可支持性bull 设计约束bull 实施需求bull接口需求bull 物理需求

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

需求工作流程的目的

与客户和其他涉众在系统的工作内容方面达成并保持一致 定义系统的用户界面重点是用户的需要和目标使系统开发人员能够更清楚地了解系统需求 定义系统边界（限定） 为计划迭代的技术内容提供基础 为估算开发系统所需成本和时间提供基础

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

需求 - 工作流程

30

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

需求 - 活动

31

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

需求 - 工件

32

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

33

目 录

RUP基础业务建模需求分析编写有效用例

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例 (Use Case) 建模

用例 (Use Case)是一种描述系统需求的方法使用用例的方法来描述系统需求的过程就是用例建模用例建模技术用于描述系统的功能需求在宏观上给出模型的总体轮廓通过对典型用例的分析使开发者能够有效地了解用户的需求整个 RUP流程都是 用例驱动 (Use-Case Driven)

的各种类型的开发活动包括项目管理分析设计测试实现等都是以系统用例为主要输入工件用例模型奠定了整个系统软件开发的基础

34

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例模型（ Use case model）

用例模型描述外部执行者 (Actor)所理解的系统功能即待开发系统的功能需求用例模型驱动了需求分析之后各阶段的开发工作 还被用于验证和检测所开发的系统 影响了 UML 的各个模型用例模型由若干个用例图构成用例图中主要描述执行者和用例之间的关系在 UML中 构成用例图的主要元素是用例和执行者及其它们之间的联系

35

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例模型核心元素

参与者 (Actor)

参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统他们代表的是系统的使用者或使用环境 用例 (Use Case)

用例用于表示系统所提供的服务它定义了系统是如何被参与者所使用的它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话 通讯关联 (Communication Association)

通讯关联用于表示参与者和用例之间的对应关系它表示参与者使用了系统中的哪些服务（用例）或者说系统所提供的服务（用例）是被哪些参与者所使用的

36

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

参与者 Actor

参与者实例是指在系统外部与系统进行交互的人或物参与者类定义一个参与者实例集其中的各个参与者实例在系统中都担任同一角色

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

查找参与者 Actor

与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意有些时候时间触发器也可看作参与者

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

记录参与者 Actor

名称应明确表示参与者的角色确保在以后不会对参与者的名称产生混淆 简要说明所代表的对象 为何需要 在系统中能获得哪些利益 特征职责数量环境使用系统的频率领域知识水平计算机水平使用的其它应用程序

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

参与者的 UML 表示

bullActor

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

参与者之间的关系

泛化关系

bull学生

bull读者

bull教师

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用户与参与者之间的关系

一个用户可以抽象为多个参与者张三 教师 amp 学生

一个参与者可以包含多个用户教师 张三 amp 李四

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

参与者与系统边界的关系

bull图书馆管理信息系统

bull管理员

bull管理员

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

图书馆管理信息系统中的参与者

bull学籍系统

bull学生

bull读者

bull教师

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

列出事件

系统必须响应的外部事件和内部事件外部事件来自系统外部bull顾客＋下定单

内部事件来自系统内部bull 和时间有关每天晚上检查账户

事件描述语法ldquo主语＋动词 ( ＋宾语 )rdquo主语 Actor的候选例如乘客顾客店员动词表示行为例如买发送修改hellip

宾语动词所代表行为的目标

47

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

列出事件 - 例子

48

bull零件销售系统事件表格

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例 Use Case

用例实例是系统执行的一系列动作这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例用例的 UML表示

bull用例名称

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例

从每个 Actor出发考虑参与者希望系统执行的主要任务是什么参与者是否将在系统中创建存储更改删除或读取数

据 参与者是否需要将突发变更或外部变更通知给系统 是否需要将系统中发生的某些特定事件通知给此参与者 此参与者是否将执行系统启动或关闭操作

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例mdashmdash用例要点

用例止于系统边界用例是目标导向的结果值由系统生成业务语言而非技术语言用户观点而非系统观点用例的粒度

52

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例 - 用例的粒度

常见错误把交互的某个步骤当作用例把系统活动当作用例粒度过细陷入功能分解四轮马车的错误（增加删除修改查询）

53

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 -- 用例的路径

55

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 - 用例模板用例编号用例名用例描述参与者前置条件后置条件基本路径（事件流） 1helliptimestimestimestimes

10487292helliphelliptimestimestimestimes10487293helliptimestimestimestimes扩展点10487292atimestimestimestimes1048729 2a1helliptimestimestimestimestimes补充说明

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 -- 用例模板要素

Mandatory （必须）

Element （要素） Phase （阶段）

radic Author and date of the first version Gathering（需求收集阶段）

Author and date of the latest revision Throughout（全过程）

radic Actors Gathering

radic Use case description

用例说明Gathering

radic Preconditions

前置条件Specification（需求规格阶段）

radic Postconditions

后置条件Specification

Priority Gathering

radic Normal course of events

主流程Specification

Alternate courses

分支流程Specification

radic Exceptions and Issues

异常Specification

Includes Gathering

Notes Throughout

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 - 前置后置条件前置条件开始用例前所必需的系统及其环境的状态后置条件用例成功结束后系统应该具备的状态编写前置后置条件的意义

某些用例依赖于其他用例bull 一个用例在离开系统时可能是另一个用例的前置条件（例如ldquo登录rdquo和ldquo管理订单rdquo）

有助于识别漏掉的用例bull 如果一个用例的前置条件不能由执行其他用例满足可能意味着丢失了用例（ 例如ldquo管理订单rdquo却没有ldquo登录rdquo ）

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 - 事件流说明用例如何开始和结束说明在参与者和用例之间交换的是什么数据说明事件流而不只是功能每个动作都应从ldquo当参与者 时rdquo开始只说明属于该用例的事件而不是发生在其他用例中或系统外部的事件避免不明确的术语如ldquo例如rdquoldquo等等rdquo和ldquo信息rdquo详细说明事件流即回答所有包含ldquo什么rdquo的问题说明系统要做什么而不是系统怎样做

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 - 事件流

使用结构化的叙述格式 每个 use case只描述没有大的分支的行为的单个线索 在事件流里要对事件流进行结构化说明

基本事件流描述每个情节的行为者 目标语句对的顺序假设之前的每一步都是成功的

备选事件流将失败情节作为延伸部分

对于失败中的失败用更长的前缀标记更深一层的失败情节

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

编写用例规约 - 识别扩展点的思路参与者的选择另一条成功路线

ldquo用支票结账rdquo

参与者错误的操作ldquo没有提供 Email地址rdquo

每次系统验证时都暗示着扩展ldquo系统验证账户名和密码rdquo

系统内部出现错误

61

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

Actor与Use Case 的交互

每当找到一个用例就应确定哪些参与者将与之进行交互定义一个通信关联关系其导航方向应该与参与者和用例之间的信号传输方向相同

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

Actor与Use Case 交互图

bull用例名称bullActor

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系

包含 (include)关系

扩展 (Extend)关系

泛化 (generalization)关系

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的包含关系包含关系是指基础用例 (Base)会用到被包含用例(Inclusion)就是将被包含用例的事件流插入到基础用例的事件流中包含关系用于从基本用例中分解出来这种的行为它对于了解基本用例的主要目的不是必需的只有它的结果才比较重要分解出两个或者多个用例所共有的行为

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的包含关系

67

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的扩展关系

扩展（ extend）关系是指将扩展用例 (Extension)的事件流在一 定的条件下按照相应的扩展点插入到基础用例 (Base)中基础用例 (Base)中定义有一至多个已命名的扩展点基本用例自身应该是完整的即基本用例应该是可理解并且有意义的而不必引用任何扩展用例但是基本用例并不独立于扩展用例因为如果无法遵循扩展用例就不能执行基本用例扩展是有条件的它是否执行取决于在执行基本用例时所发生的事件基本用例并不控件执行扩展的条件这些条件在扩展关系中进行说明扩展用例可以访问和修改基本用例的属性但是基本用例看到到扩展用例也无法访问它们的属性

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的扩展关系扩展的目的在于

表明用例的某一部分是可选的（或者可能可选）的系统行为这样你就可以将模型中的可选行为和必选行为分开表明只有在特定 条件下（有时候是异常情况下）才执行的分支流如触发警报表明可能有一组行为段其中的一个或者多个段可以在基本用例中的扩展点处插入所插入的 行为段（以及插入的顺序）将取决于在执行基本用例时与主角进行的交互

69

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的泛化关系当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例其他的用例作为泛化关系中的子用例在用例的泛化关系中子用例是父用例的一种特殊形式子用例继承了父用例所有的结构行为和关系父用例可以特化形成一个或者多个子用例这些子用例代表了父用例比较特殊的形式尽管在大多数情况下父用例是抽象的但是无论是父用例还是子用例这两者都 不要求一定抽象子用例继承父用例的所有结构行为和关系同一父用例的子用例都是该父用例的特例

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

识别用例的关系 - 用例的泛化关系

bull现金支付 bull信用卡支付

bull支付

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例分析流程

识别系统边界和参与者列出事件识别用例编写用例规约（ Use Case Specification）识别用例的关系对用例进行优先级排序

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

对用例进行优先级排序 - 排序原则

以下情况的用例优先级别最高对类图有重要影响包含丰富的业务过程信息和线索有开发风险时间紧迫或功能复杂涉及到重要核心技术或新技术能直接产生经济效益或降低成本代表本系统的核心流程

73

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例 vs 场景（ Scenario ）

场景是用例的一个实例表示用例的一个流程可能是主流程也可能是分支流程

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

大量用例时的组织

按参与者分包按主题分包按开发团队分包按发布情况分包

可以先按主题分包主题内再按开发团队和发布情况分包

75

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例包

用例包是用例参与者关系图和其他包的集合通过将其划分为若干个较小部分来建立用例模型

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

划分用例包标准

用例包中的对象都要是直接包含在包中的对象划分到一个包的情况与同一个参与者交互的用例要划分在一个包内相互之间有包含和扩展关系的包都为可选且由系统一起提供（或不提供）的包

顶级包包括所有的顶级用例包所有顶级参与者以及所有的顶级用例

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例图

用例图显示参与者用例用例包以及它们之间的关系对每一个用例包都做一个用例图对顶级包做一个用例图

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例建模之需求分析过程

识别用例Identify Use Cases

用例规格Specify Use Cases

需求建模Model Problem

用例实现Realize Use Cases

用例场景StroyBoard Use Cases

需求规格Specify Requirement

用例模型Use Case Models

用例场景Use Case Scenarios

用例情景Storyboards

类图Class Diagrams

时序图Sequence Diagrams

软件需求Software Reqmts Spec

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

用例建模之需求的组成Analysis Model分析模型

Activity Diagram活动图

Use Case Model用例模型

Sequence Diagram序列图

Class Diagram类图

State Diagram状态图

Use Case Specification用例规格

User Requirement用户需求

Nonfunctional Requirement非功能性需求

Storyboard用例场景

Functional Requirement功能性需求

Software Requirement Specification软件规格说明书

Interface Requirement Specification接口规格说明书

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

参考文档

编写有效用例（ Writing Effective Use Cases）UML和模式应用（ Applying UML and Pattern）Rational官方文档（ Rational RUP中文教程）

81

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82

82

谢 谢

• Slide 1
• Slide 2
• Slide 3
• Slide 4
• Slide 5
• Slide 6
• Slide 7
• Slide 8
• Slide 9
• Slide 10
• Slide 11
• Slide 12
• Slide 13
• Slide 14
• Slide 15
• Slide 16
• Slide 17
• Slide 18
• Slide 19
• Slide 20
• Slide 21
• Slide 22
• Slide 23
• Slide 24
• Slide 25
• Slide 26
• Slide 27
• Slide 28
• Slide 29
• Slide 30
• Slide 31
• Slide 32
• Slide 33
• Slide 34
• Slide 35
• Slide 36
• Slide 37
• Slide 38
• Slide 39
• Slide 40
• Slide 41
• Slide 42
• Slide 43
• Slide 44
• Slide 45
• Slide 46
• Slide 47
• Slide 48
• Slide 49
• Slide 50
• Slide 51
• Slide 52
• Slide 53
• Slide 54
• Slide 55
• Slide 56
• Slide 57
• Slide 58
• Slide 59
• Slide 60
• Slide 61
• Slide 62
• Slide 63
• Slide 64
• Slide 65
• Slide 66
• Slide 67
• Slide 68
• Slide 69
• Slide 70
• Slide 71
• Slide 72
• Slide 73
• Slide 74
• Slide 75
• Slide 76
• Slide 77
• Slide 78
• Slide 79
• Slide 80
• Slide 81
• Slide 82