第12-14章 面向对象的建模
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
9
第13章 业务建模
业务建模是一种建模方法的集合，是一种问题分析 的技术，有助于定义系统及其应用。其工作包括了 对业务流程建模，对业务组织建模，改进业务流程， 领域建模等方面。
10
业务建模的目的
理解现有业务组织的静态结构和动态运作方 式。 确保客户、最终用户以及开发人员对业务有 共同的理解。 理解如何部署新的系统以提高生产率，现有 哪些系统会受到新系统的影响。
34
编写用例
将基本用例(essential use case)定义为 “……对某项任务或某种交互所作的简化、 概括、抽象的描述，与技术和实现无 关，……体现了进行这种交互的真正目的或 意图。” 需求分析员将角色的每个动作和系统的每个 响应记在便笺上，将便笺贴到活页挂图上， 用这种方式引导讨论会的进行。 另一种方式是将用例模板从电脑投影到大屏 幕上，在讨论过程中填完这份模板。 35
39
检查用例模型
功能需求的完备性 模型是否易于理解 是否存在不一致性 避免二义性语义
40
RUP中的需求工件集合
用例模型：记录功能性需求 用例图：描述参与者和用例之间的关系 用例规约：描述每一个用例的细节信息 补充规约：记录一些全局性的功能需求、非 功能性需求和设计约束等 词汇表：记录一些系统需求相关的术语
17
第14章 用例建模
18
用例
什么是用例（Use Case） 用例构成元素：参与者、通讯关联、用例
19
用 例 法
用例描述了系统与外部角色之间的一系列交互。 角色(actor)指与系统交互以实现某种目的的人、 软件系统或硬件设备(Cockburn 2001)。角色的 另外一个名称是用户角色(user role)。 用例源于面向对象的开发方法，用例是目前广泛 应用的统一软件开发过程的核心(Jacobson、 Booch和Rumbaugh 1999)。 用例转变了需求开发的角度，用例更接近目标。 用例图(user-case diagram)提供了对用户需求的 高级可视化表示。
从业务模型到系统模型
业务工作人员可以成为所开发系统的主角。 业务工作人员的行为是可以自动化的事物， 可以帮助我们找到系统用例并定义需要的功 能。 业务对象是我们希望系统帮助我们维护的一 些事物，可帮助我们在分析系统模型时找到 实体类。
16
何时使用业务建模
当应用环境复杂而且是多维的，以及涉及到 许多人直接使用系统时，业务建模技术更有 价值。 而对一个单纯的系统特性的开发则不需要这 样做。
参与者(Actor)：参与者是指存在于被定义系统外部并与该系统发生交互 的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use Case)：用例用于表示系统所提供的服务，它定义了系统是如 何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完 整功能而与系统之间发生的一段对话。 通讯关联(Communication Association)：通讯关联用于表示参与者和用 例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例）， 或者说系统所提供的服务（用例）是被哪些参与者所使用的。
在需求分析阶段 可以用用例来捕获用户需求。通过用例建 模，描述对系统感兴趣的外部角色及其对系 统(用例)的功能要求。
5
利用UML建模 建模 利用
利用统一建模语言UML 来对系统结构进行全 面的分析设计，即构建系统模型的过程，这 就是可视化建模(Visual Modeling)。 可视化建模技术已经成为一种成熟标准的软 件开发技术规范。
41
RUP（Rational Unified Process，统一软件开 发过程，统一软件过程)是一个面向对象且基 于网络的程序开发方法论。 根据Rational(Rational Rose和统一建模语言的 Rational(Rational Rose 开发者)的说法，好像一个在线的指导者，它 可以为所有方面和层次的程序开发提供指导 方针，模版以及事例支持。
11
业务建模时期的主要任务
确定项目范围 建立上层（high-level）需求 取得涉众支持 业务建模会议
12
CRC建模 建模
CRC是“类”（class），“责任” （responsibility）及“辅助者”（collaborator） 三者的简称，这些资料常呈现在一张卡片上。
类名称 责任 1 责任 1 … 责任 1 的协作者 1 责任 1 的协作者 1 …
用例方法的特点
用例方法完全是从外部来定义系统的功能， 它把需求与设计完全分离开来。 在面向对象的分析设计方法中，用例模型主 要用于表述系统的功能性需求，系统的设计 主要由对象模型来记录表述。 用例定义了系统功能的使用环境与上下文， 每一个用例描述的是一个完整的系统服务。 用例方法比传统的SRS更易于被用户所理解， 它可以作为开发人员和用户之间针对系统需 25 求进行沟通的一个有效手段 。
20
用例模型
用例图(Use Case Diagram)
源自文库• 确定系统中所包含的参与者、用例和两者之间的 对应关系，用例图描述的是关于系统功能的一个 概述。
用例规约(Use Case Specification)
• 针对每一个用例都应该有一个用例规约文档与之 相对应，该文档描述用例的细节内容。
21
用例模型主要的模型元素
3
为什么要使用UML 为什么要使用
UML的使用目的如下： UML易于使用，能够进行可视化建模； 与具体的实现无关，可应用于任何语言平台 和工具平台； 与具体的过程无关，可应用于任何软件开发 的过程； 简单并且可扩展，具有扩展和专有化机制， 便于扩展，无须对核心概念进行修改；
4
UML在软件开发过程中的应用 在软件开发过程中的应用
• 1. 只使用用例
是把功能性需求包含在每个用例描述中，不过你还 是需要一个单独的补充说明来记录非功能性需求， 以及所有不与特定用例相关的功能性需求。
37
用例与功能性需求
• 2. 用例与软件需求规格说明
是写一个相当简单的用例描述，同时把从用例 中推导出的功能性需求记录在软件需求规格说 明中。
• 3. 只使用软件需求规格说明
13
建立业务用例模型
作为一个核心输入模型，业务用例模型用于确定组 织的各个角色和可交付工件。 业务用例模型实际上就是企业经营业务的一种描述， 为了建立完整、准确的企业用例模型，应该将注意 力专注于企业的业务做了些什么事情，而不应该集 中于如何做。
14
业务建模的步骤
第一步，从涉众中找出用户。并定义这些用户之间 的关系。 第二步，找出每个用户要做的事，即业务用例。 第三步，利用业务场景图帮助分析业务流程。 第四步，绘制用例场景图。 第五步，从第三步或第四步中绘制的活动图中找到 每一步活动将使用到的或产生的结果。 第六步，在上述过程中，随时补充词汇表。它包括 所有业务词汇，专业词汇等一切在建模过程中使用 到的需要解释的名词。 第七步，根据涉众的期望评审建立好的模型，确定 业务范围，决定哪些业务用例在系统建设范围内 。 上述的步骤 是可以迭代的。 15
6
可视化建模方法
在UML中采用了“4+1 View”模型来进行可 视化建模工作，“4+1 View”指的是：用例视 图、逻辑视图、进程视图、实施视图、部署 视图。这几种视图从不同的角度来对系统进 行完整的描述。 称为“架构视图(Architecture View)”，即 通过这样几种视图可以完整地展示系统的架 构。
编写用例
图 获取用例的方法。
起草功能 性需求 已验证的 功能性需求 用例 讨论会 用例 描述 起草测试 用例 已验证的 分析模型 起草 分析模型 一致理解
数据 字典
36
用例与功能性需求
软件开发人员实现的不是业务需求或用 例，而是功能性需求。功能性需求是让 用户得以执行用例并达成目标的系统行 为。 记录与用例相关的功能性需求有好几种 方式：
根据用例或特性来组织软件需求规格说明， 并把用例和功能性需求都记录在软件需求 规格说明中。
38
使用用例时应避免的问题
与所有的软件工程方法一样，用例法的应用也 经常会误入歧途。要避免下面这些问题：
• • • • • • • 用例过多。 用例过于复杂 。 在用例中包含用户界面设计 。 在用例中包含数据定义。 用户无法理解用例。 新的业务流程。 滥用包含和扩充关系。
32
用例与使用场景
主干过程 分支过程 用例的前置条件 步骤 1
步骤 2
(分支条件)
步骤 3a
如图所示。流程 图和活动图能够 显示使主干过程 分支为分支过程 的判断点和判断 条件。
(继续条件) 步骤 3 步骤 3b
步骤 4 用例的后置条件
步骤 3c
33
确定用例
可采用以下几种方法确定用例：
• 首先明确有哪些角色，然后确定他们各自参与 了哪些业务过程。 • 确定哪些外部事件是系统必须响应的，将它们 与参与的角色和特定用例关联起来。 • 用特定场景来描述业务过程，将这些场景归纳 为用例，并确定每项用例涉及哪些角色。 • 从已有的功能性需求推导出可能的用例。
1
利用UML进行系统建模 进行系统建模 利用
它是编制软件蓝图的标准化语言，用于对复杂软件系 统的各种成分的可视化地说明和构造系统模型（建 模是人类对客观世界和抽象事物之间联系的具体描 述），以及建立软件文档。 因为模型的作用就是使复杂的信息关联简单易懂，它 使我们容易洞察复杂堆砌而成的原始数据背后的规 律，并能有效地使我们将系统需求映射到软件结构 上去。
第12章 面向对象的建模
（1）UML ） UML（Unified Modeling Language）统一建模 语言，UML是构建软件系统模型的标准化语 言，它提供了描述软件系统模型的概念和图 形表示法. 由于它采用面向对象的技术、方法，因此能准 确方便地表达面向对象的概念，体现面向对 象的分析与设计风格。
7
8
餐馆定座系统需求示例
功能性的需求 服务生可以通过系统查询是否有满足条件的桌子尚未定出 服务生可以通过系统为顾客定座以及取消定座 服务生可以查询客户以往的消费情况 非功能性的需求 系统的响应查询时间应该小于10秒 系统必须7X24小时服务，每天可以有30分钟的维护时间， 同时只能在0点到1点之间 环境限制 在局域网络的环境中完成此功能
2
UML的诞生 的诞生
面向对象建模的标准语言的产生背景: 目前人们普遍开始采用面向对象的分析与设 计，但是很少有开发人员使用形象化的设计 方法，其主要原因就是缺乏统一的语言语义 来为复杂软件系统的组件定义、可视化、构 建和编制文档。而UML的出现彻底的改变了 这一现状，并成为了面向对象建模的标准语 言。
22
ATM 的用例图
23
ATM系统中的“提款”用例的事件流
提款--基本事件流：
• • • • • 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
提款--备选事件流
• 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 • 备选流二：在基本流步骤1中，用户插入无效信用卡，系 统显示错误并退出信用卡，用例结束。 • 备选流三：在基本流步骤２中，用户输入错误密码，系 统显示错误并提示用户重新输入密码，重新回到基本流 步骤2；三次输入密码错误后，信用卡被系统没收，用例 24 结束。 • …
示例
31
用例与使用场景
用例是角色为达到某种重要目标而执行的一 种离散、独立的活动。 每项用例都有一个场景被确定为事件的主干 过程(normal course)，也称为主过程、基本 过程、普通流、主场景、主要的成功场景和 快乐之路(happy path)。 用例中的其他有效场景则被描述为分支过程 (alternative course)或次要场景(secondary scenario)(Schneider和Winters 1998)。
建立用例模型
先找出参与者，再根据参与者确定每个参与 者相关的用例，最后再细化每一个用例的用 例规约。
26
ATM系统的用例图
27
用例图
28
示例
29
用例规约
简要说明。简要介绍该用例的作用和目的。 事件流。包括基本流和备选流，事件流应该表示出 所有的场景。 用例场景。包括成功场景和失败场景，场景主要是 由基本流和备选流组合而成的。 特殊需求。描述与该用例相关的非功能性需求（包 括性能、可靠性、可用性和可扩展性等）和设计约 束（所使用的操作系统、开发工具等）。 前置条件。执行用例之前系统必须所处的状态。 后置条件。用例执行完毕后系统可能处于的一组状 30 态。
第13章 业务建模
业务建模是一种建模方法的集合，是一种问题分析 的技术，有助于定义系统及其应用。其工作包括了 对业务流程建模，对业务组织建模，改进业务流程， 领域建模等方面。
10
业务建模的目的
理解现有业务组织的静态结构和动态运作方 式。 确保客户、最终用户以及开发人员对业务有 共同的理解。 理解如何部署新的系统以提高生产率，现有 哪些系统会受到新系统的影响。
34
编写用例
将基本用例(essential use case)定义为 “……对某项任务或某种交互所作的简化、 概括、抽象的描述，与技术和实现无 关，……体现了进行这种交互的真正目的或 意图。” 需求分析员将角色的每个动作和系统的每个 响应记在便笺上，将便笺贴到活页挂图上， 用这种方式引导讨论会的进行。 另一种方式是将用例模板从电脑投影到大屏 幕上，在讨论过程中填完这份模板。 35
39
检查用例模型
功能需求的完备性 模型是否易于理解 是否存在不一致性 避免二义性语义
40
RUP中的需求工件集合
用例模型：记录功能性需求 用例图：描述参与者和用例之间的关系 用例规约：描述每一个用例的细节信息 补充规约：记录一些全局性的功能需求、非 功能性需求和设计约束等 词汇表：记录一些系统需求相关的术语
17
第14章 用例建模
18
用例
什么是用例（Use Case） 用例构成元素：参与者、通讯关联、用例
19
用 例 法
用例描述了系统与外部角色之间的一系列交互。 角色(actor)指与系统交互以实现某种目的的人、 软件系统或硬件设备(Cockburn 2001)。角色的 另外一个名称是用户角色(user role)。 用例源于面向对象的开发方法，用例是目前广泛 应用的统一软件开发过程的核心(Jacobson、 Booch和Rumbaugh 1999)。 用例转变了需求开发的角度，用例更接近目标。 用例图(user-case diagram)提供了对用户需求的 高级可视化表示。
从业务模型到系统模型
业务工作人员可以成为所开发系统的主角。 业务工作人员的行为是可以自动化的事物， 可以帮助我们找到系统用例并定义需要的功 能。 业务对象是我们希望系统帮助我们维护的一 些事物，可帮助我们在分析系统模型时找到 实体类。
16
何时使用业务建模
当应用环境复杂而且是多维的，以及涉及到 许多人直接使用系统时，业务建模技术更有 价值。 而对一个单纯的系统特性的开发则不需要这 样做。
参与者(Actor)：参与者是指存在于被定义系统外部并与该系统发生交互 的人或其他系统，他们代表的是系统的使用者或使用环境。 用例(Use Case)：用例用于表示系统所提供的服务，它定义了系统是如 何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完 整功能而与系统之间发生的一段对话。 通讯关联(Communication Association)：通讯关联用于表示参与者和用 例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例）， 或者说系统所提供的服务（用例）是被哪些参与者所使用的。
在需求分析阶段 可以用用例来捕获用户需求。通过用例建 模，描述对系统感兴趣的外部角色及其对系 统(用例)的功能要求。
5
利用UML建模 建模 利用
利用统一建模语言UML 来对系统结构进行全 面的分析设计，即构建系统模型的过程，这 就是可视化建模(Visual Modeling)。 可视化建模技术已经成为一种成熟标准的软 件开发技术规范。
41
RUP（Rational Unified Process，统一软件开 发过程，统一软件过程)是一个面向对象且基 于网络的程序开发方法论。 根据Rational(Rational Rose和统一建模语言的 Rational(Rational Rose 开发者)的说法，好像一个在线的指导者，它 可以为所有方面和层次的程序开发提供指导 方针，模版以及事例支持。
11
业务建模时期的主要任务
确定项目范围 建立上层（high-level）需求 取得涉众支持 业务建模会议
12
CRC建模 建模
CRC是“类”（class），“责任” （responsibility）及“辅助者”（collaborator） 三者的简称，这些资料常呈现在一张卡片上。
类名称 责任 1 责任 1 … 责任 1 的协作者 1 责任 1 的协作者 1 …
用例方法的特点
用例方法完全是从外部来定义系统的功能， 它把需求与设计完全分离开来。 在面向对象的分析设计方法中，用例模型主 要用于表述系统的功能性需求，系统的设计 主要由对象模型来记录表述。 用例定义了系统功能的使用环境与上下文， 每一个用例描述的是一个完整的系统服务。 用例方法比传统的SRS更易于被用户所理解， 它可以作为开发人员和用户之间针对系统需 25 求进行沟通的一个有效手段 。
20
用例模型
用例图(Use Case Diagram)
源自文库• 确定系统中所包含的参与者、用例和两者之间的 对应关系，用例图描述的是关于系统功能的一个 概述。
用例规约(Use Case Specification)
• 针对每一个用例都应该有一个用例规约文档与之 相对应，该文档描述用例的细节内容。
21
用例模型主要的模型元素
3
为什么要使用UML 为什么要使用
UML的使用目的如下： UML易于使用，能够进行可视化建模； 与具体的实现无关，可应用于任何语言平台 和工具平台； 与具体的过程无关，可应用于任何软件开发 的过程； 简单并且可扩展，具有扩展和专有化机制， 便于扩展，无须对核心概念进行修改；
4
UML在软件开发过程中的应用 在软件开发过程中的应用
• 1. 只使用用例
是把功能性需求包含在每个用例描述中，不过你还 是需要一个单独的补充说明来记录非功能性需求， 以及所有不与特定用例相关的功能性需求。
37
用例与功能性需求
• 2. 用例与软件需求规格说明
是写一个相当简单的用例描述，同时把从用例 中推导出的功能性需求记录在软件需求规格说 明中。
• 3. 只使用软件需求规格说明
13
建立业务用例模型
作为一个核心输入模型，业务用例模型用于确定组 织的各个角色和可交付工件。 业务用例模型实际上就是企业经营业务的一种描述， 为了建立完整、准确的企业用例模型，应该将注意 力专注于企业的业务做了些什么事情，而不应该集 中于如何做。
14
业务建模的步骤
第一步，从涉众中找出用户。并定义这些用户之间 的关系。 第二步，找出每个用户要做的事，即业务用例。 第三步，利用业务场景图帮助分析业务流程。 第四步，绘制用例场景图。 第五步，从第三步或第四步中绘制的活动图中找到 每一步活动将使用到的或产生的结果。 第六步，在上述过程中，随时补充词汇表。它包括 所有业务词汇，专业词汇等一切在建模过程中使用 到的需要解释的名词。 第七步，根据涉众的期望评审建立好的模型，确定 业务范围，决定哪些业务用例在系统建设范围内 。 上述的步骤 是可以迭代的。 15
6
可视化建模方法
在UML中采用了“4+1 View”模型来进行可 视化建模工作，“4+1 View”指的是：用例视 图、逻辑视图、进程视图、实施视图、部署 视图。这几种视图从不同的角度来对系统进 行完整的描述。 称为“架构视图(Architecture View)”，即 通过这样几种视图可以完整地展示系统的架 构。
编写用例
图 获取用例的方法。
起草功能 性需求 已验证的 功能性需求 用例 讨论会 用例 描述 起草测试 用例 已验证的 分析模型 起草 分析模型 一致理解
数据 字典
36
用例与功能性需求
软件开发人员实现的不是业务需求或用 例，而是功能性需求。功能性需求是让 用户得以执行用例并达成目标的系统行 为。 记录与用例相关的功能性需求有好几种 方式：
根据用例或特性来组织软件需求规格说明， 并把用例和功能性需求都记录在软件需求 规格说明中。
38
使用用例时应避免的问题
与所有的软件工程方法一样，用例法的应用也 经常会误入歧途。要避免下面这些问题：
• • • • • • • 用例过多。 用例过于复杂 。 在用例中包含用户界面设计 。 在用例中包含数据定义。 用户无法理解用例。 新的业务流程。 滥用包含和扩充关系。
32
用例与使用场景
主干过程 分支过程 用例的前置条件 步骤 1
步骤 2
(分支条件)
步骤 3a
如图所示。流程 图和活动图能够 显示使主干过程 分支为分支过程 的判断点和判断 条件。
(继续条件) 步骤 3 步骤 3b
步骤 4 用例的后置条件
步骤 3c
33
确定用例
可采用以下几种方法确定用例：
• 首先明确有哪些角色，然后确定他们各自参与 了哪些业务过程。 • 确定哪些外部事件是系统必须响应的，将它们 与参与的角色和特定用例关联起来。 • 用特定场景来描述业务过程，将这些场景归纳 为用例，并确定每项用例涉及哪些角色。 • 从已有的功能性需求推导出可能的用例。
1
利用UML进行系统建模 进行系统建模 利用
它是编制软件蓝图的标准化语言，用于对复杂软件系 统的各种成分的可视化地说明和构造系统模型（建 模是人类对客观世界和抽象事物之间联系的具体描 述），以及建立软件文档。 因为模型的作用就是使复杂的信息关联简单易懂，它 使我们容易洞察复杂堆砌而成的原始数据背后的规 律，并能有效地使我们将系统需求映射到软件结构 上去。
第12章 面向对象的建模
（1）UML ） UML（Unified Modeling Language）统一建模 语言，UML是构建软件系统模型的标准化语 言，它提供了描述软件系统模型的概念和图 形表示法. 由于它采用面向对象的技术、方法，因此能准 确方便地表达面向对象的概念，体现面向对 象的分析与设计风格。
7
8
餐馆定座系统需求示例
功能性的需求 服务生可以通过系统查询是否有满足条件的桌子尚未定出 服务生可以通过系统为顾客定座以及取消定座 服务生可以查询客户以往的消费情况 非功能性的需求 系统的响应查询时间应该小于10秒 系统必须7X24小时服务，每天可以有30分钟的维护时间， 同时只能在0点到1点之间 环境限制 在局域网络的环境中完成此功能
2
UML的诞生 的诞生
面向对象建模的标准语言的产生背景: 目前人们普遍开始采用面向对象的分析与设 计，但是很少有开发人员使用形象化的设计 方法，其主要原因就是缺乏统一的语言语义 来为复杂软件系统的组件定义、可视化、构 建和编制文档。而UML的出现彻底的改变了 这一现状，并成为了面向对象建模的标准语 言。
22
ATM 的用例图
23
ATM系统中的“提款”用例的事件流
提款--基本事件流：
• • • • • 1. 用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退出系统，取回信用卡
提款--备选事件流
• 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 • 备选流二：在基本流步骤1中，用户插入无效信用卡，系 统显示错误并退出信用卡，用例结束。 • 备选流三：在基本流步骤２中，用户输入错误密码，系 统显示错误并提示用户重新输入密码，重新回到基本流 步骤2；三次输入密码错误后，信用卡被系统没收，用例 24 结束。 • …
示例
31
用例与使用场景
用例是角色为达到某种重要目标而执行的一 种离散、独立的活动。 每项用例都有一个场景被确定为事件的主干 过程(normal course)，也称为主过程、基本 过程、普通流、主场景、主要的成功场景和 快乐之路(happy path)。 用例中的其他有效场景则被描述为分支过程 (alternative course)或次要场景(secondary scenario)(Schneider和Winters 1998)。
建立用例模型
先找出参与者，再根据参与者确定每个参与 者相关的用例，最后再细化每一个用例的用 例规约。
26
ATM系统的用例图
27
用例图
28
示例
29
用例规约
简要说明。简要介绍该用例的作用和目的。 事件流。包括基本流和备选流，事件流应该表示出 所有的场景。 用例场景。包括成功场景和失败场景，场景主要是 由基本流和备选流组合而成的。 特殊需求。描述与该用例相关的非功能性需求（包 括性能、可靠性、可用性和可扩展性等）和设计约 束（所使用的操作系统、开发工具等）。 前置条件。执行用例之前系统必须所处的状态。 后置条件。用例执行完毕后系统可能处于的一组状 30 态。