uml 面向对象分析与设计

《软件工程》

UML 概述

马丽

UML 面向对象分析与设计

UML 把 Booch, Rumbaugh 和 Jacobson 等各自独立的 OOA 和 OOD 方法中最优秀的特色组合成一个统一的方法。

UML 的特点： 统一标准 面向对象 可视化，表示能力强大 独立于过程 容易掌握使用

UML 的定义

UML 定义有两个主要组成部分： 语义：用自然语言描述 表示法：定义 UML 的可视化标准表示符号

使用 UML 时，要从不同的角度观察系统，为此定义了概念 “视图”。视图是对系统的模型在某方面的投影，注重于系统的某个方面。

结构视图结构视图结构视图结构视图

行为视图行为视图行为视图行为视图

实现视图实现视图实现视图实现视图

环境视图环境视图环境视图环境视图

用例视图用例视图用例视图用例视图

为最终用户做什么为最终用户做什么系统静态结构系统静态结构

程序员提供什么程序员提供什么软件组织与管理软件组织与管理

系统集成人员如何组织系统集成人员如何组织与控制系统与控制系统

系统工程师如何配置系统工程师如何配置和运行系统和运行系统

系统拓扑、交付、安系统拓扑、交付、安装、操作、通信装、操作、通信

分析员或测分析员或测试员试员

系统任务控制与管理系统任务控制与管理(( 性能，可伸缩性性能，可伸缩性 ,, 吞吐量吞吐量 ))

行为行为

1) 结构视图：描述系统的静态结构，可根据它确定重要的设计：类、包和子系统。

2) 实现视图：描述处于开发环境中的静态软件成分的组织（源程序、构件、数据文件、可执行程序等）。

3) 行为视图：描述系统在运行时的并发性，包括任务、线程、进程及其相互作用。

软件体系结构的 4+1 视图模型

4) 环境视图：描述处于运行环境中的各种可执行程序是如何映射到底层平台或计算结点上的。

5)5) 用例视图：包括若干关键场景或用例。在初用例视图：包括若干关键场景或用例。在初始和细化阶段用来帮助发现和设计体系结构。始和细化阶段用来帮助发现和设计体系结构。在构造阶段用来验证各种不同视图。在文档在构造阶段用来验证各种不同视图。在文档中用来表明其他视图是如何工作的。中用来表明其他视图是如何工作的。

UMLUML 分析建模着重系统的用例模型和结构分析建模着重系统的用例模型和结构模型，设计建模着重行为模型，实现模型和模型，设计建模着重行为模型，实现模型和环境模型上。环境模型上。

体系结构中主要的元素包括： 主要的类，如为业务实体建模的类。 将行为赋予类的机制，如协同。 模式与框架。 层次与子系统。 接口以及主要的进程控制或线程控制。

UML 的三个主要组成元素 基本构造块 组织构造块的规则 运用于整个 UML 的公共机制

UML 的构成

UML 包括三种基本构造块：事物、关系和图。

UMLUML 事物—结构事物事物—结构事物

类名

属性

操作open( )close( )move( )display( )

originsize

Window1)类

2) 接口 — 描述一个类或构件的服务（操作）。

3) 协作 — 描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模。

4) 用例 — 表示系统想要实现的行为，不关心这些行为是怎样实现的。

ISpelling

Place Order

OrderManagement

用例 协作

实现

5) 主动类 —它至少拥有一个进程或线程，故能够启动控制活动。

suspend()flush()

EventManager

6) 构件 — 系统中物理 的、可替代的部件。

7) 节点 — 系统在运行 时存在的物理元素。

Orderform.java

数据库服务器

应用服务器

课程管理

成绩管理

UML 事物—行为事物

8) 交互 — 由在特定环境中共同完成一定任务的一组对象之间交换的消息组成。

p:Person :Company

Assign(development)

消息有名对象

匿名对象

9) 状态机 — 描述了一个对象或一个交互在生存周期内响应事件所经历的状态序列。

initializing command

idle

Keypress

Finished

Exit

UML 事物—分组事物

10) 包用户接口

包

业务对象包

数据库包

应用包

UML 事物—注释事物

11) 注释 — 依附于一个元素或一组元素之上，对其进行约束或解释的简单符号。

CashAccount

presentValue()

See policy8-5-96.doc for details about these algorithms.

UML 关系

1) 依赖 — 两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。

CourseSchedule

add(c:Course)remove(c:Course)

Course

Iterator

<<friend>>

2) 关联 — 一种描述一组对象之间连接的结构关系。

聚合是一种特殊类型的关联，描述了整体和部分间的结构关系。

3) 泛化 — 一种一般化—特殊化的关系。employer employee0..1 *

Event

ConsoleWindow DialogBox Control

依赖

泛化 关联

Window

open()close()move()display()handleEvent()

4) 实现 — 类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

两种情况出现实现关系：a. 在接口和实现它们的类或构件之间；b. 用例和它们的协作之间。

Place Order

OrderManagement

用例协作

实现

类属性操作

对象属性操作

接口用例

构件 节点

状态机

包 注 释

依赖 关联 泛化 实现

聚合 复合

模型中主要的图形元素

UML 模型的图形

Use CaseDiagramsUse Case

Diagrams用例图用例图

ScenarioDiagramsScenario

Diagrams协作图State

DiagramsStateDiagrams构件图

ComponentDiagramsComponent

Diagrams部署图

StateDiagramsState

Diagrams对象图

ScenarioDiagramsScenario

Diagrams状态图

Use CaseDiagramsUse Case

Diagrams顺序图

StateDiagramsState

Diagrams类图类图

活动图

模型

1. 用例图 用例图展现了一组用例、参与者以及它们间的关

系。 可以用用例图描述系统的静态使用情况，它定义

了系统的功能需求，但这是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。

在对系统行为组织和建模方面，用例图的是相当重要的。

查询商品价格

顾客 库存系统

售货员

总账系统

查询商品信息

预售商品

网上销售商品打折销售商品

出售商品

查询商品成分

商品查询

售货管理

说明 顾客持所欲购买的商品至收银台结帐，店员刷商品条码后，根据数量及单价计算总金额商品售出后，商品编码、单价、总金额存入电脑，数据记载到“库存系统”和“总帐系统”中（含预售、网络购物、打折销售）。。

事件流基本事件流 刷条码 ? 结算金额 ?付款 ?扣库存 ?记入日记账 ?打

印发票异常事件流 第一异常事件流 顾客结帐后更换商品

第二异常事件流 顾客将已售商品退回特殊需求 第一个特殊需求 允许退货 , 并将退回商品加回库存

第二个特殊需求 记录顾客的性别，年龄 , 供后续统计分析用

用例规格说明：销售商品用例规格说明：销售商品

2. 类图

类图展示了一组类、接口和协作及它们间的关系。 类图没有时间概念，是概念数据模型（如 E-R

图）的一种延伸。 用类图说明系统的静态结构视图，包含主动类的

类图—专注于系统的静态处理视图。 系统可有多个类图，单个类图仅表达了系统的一

个方面，要在高层给出类的主要职责，在低层给出类的属性和操作。

类图是从系统构成角度来描述系统。 类的表示：

类的名称类的名称属性属性属性 属性 :: 数据类型数据类型属性 属性 :: 数据类型 数据类型 = = 初值初值

操作操作操作操作 (( 参数表参数表 ):): 结果类型结果类型

限定关联

类 1 类 2限定词关联名称

角色 1 角色 2

聚合、引用和重复度

0..*

0..1

0..*

整体 类名

部分 类名 2部分 类名 1

0..1聚合简单引用

复合聚合双方捆绑

关联名类 1类 1 类 2类 2

关联类名关联类名

属性属性

操作操作

角色 1 角色 2

关联类

泛化关系

超类超类

子类 1子类 1 子类 2

操作

子类 2

操作

抽象类

操作

抽象类

操作

雇员雇员标识 : char姓名 : char职务 : char工资 : long

项目项目标识项目名称

参与开始日期结束日期

任务任务标识任务名称任务费用

技能技能标识技能名称

团队团队标识承担工作

部门部门标识部门名称

客户客户标识客户名称客户地址客户电话客户代表

0..*

0..*

1

0..* 1..*

1

0..*

1..* 1..*

1

1

0..*

1

1..*

0..*

1..*

3. 对象图

对象图展示了一组对象及它们间的关系。 用对象图说明类图中类的对象实例的数据结构和静态快照，即在某一时刻，一组对象的状态及其关系。

对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面因素外，它与类图作用是相同的。

c: 公司

名称 =“研发”d2: 部门d1: 部门

名称 =“销售”

d3: 部门名称 =“打印机销售”

: 联系信息地址 =“清华产业楼 411”

p: 人员姓名 =“郑人杰”雇员标识 =6037职务 =“销售副总”

经理

连接 link

属性值

对象

匿名对象

4. 包图

包图表明包及其之间的依赖类图。 包是对模型中涉及的元素分组所得的结果，是具有特定语义的一个子集，必须保证低耦合、高内聚。

广义地讲，包可以包含类、接口、构件、节点、协作、用例等，还可以内嵌其他子包。

包之间的访问权限通过输出（输出品）和导入（进口货）设置，虚箭头 从源包到目标包。

年个

控制器

微软窗口

基本图形

窗口系统

窗口核心

基本图形核心

图形核心

图组件见、、、

编辑器

图组件见、、、

5. 构件图 构件图展现了一组构件之间的组织和依赖，用于

对源代码、可执行的发布、物理数据库等的系统建模。

构件图表示系统的静态实现视图。

Course CourseOffering

Student Professor

Course.dllPeople.dll

课程

用户

Register.exeBilling.exe

课表系统

6. 部署图 部署图展现了对运行时处理节点以及其中构件的

配置每一节点代表一个计算单元。。 它描述系统硬件的物理拓扑结构 ( 包括网络布局和构件在网络上的位置 ) ，以及在此结构上执行的软件（即运行时软构件在节点中的分布情况）。

用部署图说明系统结构的静态环境视图，即说明分布、交付和安装的物理系统。

注册服务器 数据库

宿舍客户机

图书馆客户机

主排课客户机

8. 活动图

活动图是一种特殊的状态图，描述要做的活动、执行这些活动的顺序以及工作流。它对于系统的功能建模特别重要，强调对象间的控制流程。

高层活动图用于表示任务。即用于分析用例，理解涉及多个用例的工作流、多线程及并行，显示相互联系的行为整体，还可用于业务过程建模，对系统的功能建模。低层活动图用于表示类的方法。

按订单供货

接订单

开发票

结清订单

快速交付 正常交付 收款

起点

分叉

活动

分支

合并

汇合结束

[ 紧急订单 ] [非紧急订单 ]

变迁

9. 状态图

状态图展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。

一个状态图描述了一个状态机，用状态图说明系统的动态视图。

状态图对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生存周期。

Project 对象的状态图

注册 预售

开发

系统分析

系统设计

程序编码

软件测试

系统部署

单元测试与调试

维护

新 project

project 完

开始 结束

10. 交互图 交互图展现了按一定的目的进行一种交互，它由

在一个上下文中的一组对象及它们之间交互的信息组成。

交互图可用于描述一个用例的行为。顺序图和协作图都是交互图，它们可以相互转换。

如果希望查看单个对象跨用例的行为 , 要使用状态图。

如果希望查看跨用例跨线程的行为，要使用活动图。

10-1 顺序图 顺序图展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。

对象表述为虚垂线顶端的矩形小框。 垂线是对象的生命线，说明对象的生命。 生命线之间的箭头表示消息。消息出现的次序自上而下。

消息箭头可以回到同一条生命线，指明自调用，即对象发给自己的消息。

移动电话系统的用例图

移动用户 移动网络

与对方通话

下载图符

下载铃声

管理电话本

移动电话系统的顺序图

: 移动用户 : 移动按键 : 移动显示 : 移动手机 : 移动基站

按数字键 显示按键号码

按发送键连接基站 建立连接

连接成功显示连接成功

10-2 协作图

协作图展现了一组对象，这组对象之间的连接以及这组对象收发的消息。

它强调收发消息的对象结构组织，按组织结构对控制流建模。

协作图中的协作不是参与者与系统之间的交互，而是系统内部某一个用例中各个对象之间信息传递的方式。

消息上所附编号指明执行顺序。

移动电话系统的协作图

: 移动用户

1: 按数字键3: 按发送键

: 移动按键 2: 显示按键号码 : 移动显示

: 移动手机

: 移动基站

4: 连接基站

5: 建立连接 6: 连接成功

7: 显示连接成功

*RUP （ Rational Unified Process 统一开发过程）的分析 / 设计工作流

分析和设计工作流的目的是研究欲采用的实现环境和系统构件的效用，定义软件的组织结构，把需求获取结果转化为实现规格。

为实现这种转化，必须理解需求，采用最佳实现策略将其翻译为系统设计。

为此，首先是建立健壮的软件体系结构，设计出易于理解、开发和演进的系统，然后调整这个设计，使之适应实现环境。

最后结果是产生一个对象模型，即设计模型。

定义初始体系结构定义初始体系结构

[早期细化迭代 ]

分析行为分析行为

设计实时构件设计

实时构件设计

数据库设计

数据库设计构件设计构件

细化体系结构细化体系结构

[ 细化迭代 ]

[ 可选 ][ 实时 ][非实时 ]

1) 定义一个初始的体系结构 建立一个初始的系统体系结构草图。定义

一组初始的重要体系结构元素。一组初始分析机制。系统的初始分层和组织。在当前迭代过程中处理的用例实现。

从重要的构件用例中确定类。 确定类之间的交互作用，修改用例实现。

2) 细化体系结构

建立从分析到设计的自然转移，并标识：从分析元素中确定适当的设计元素。从相关分析机制中确定适当的设计机制。

保持体系结构的一致性和完整性，确保：将当前迭代中标识的新的设计元素与已有的设计元素集成在一起。在设计中尽早地、最大限度地复用可获得的构件和设计元素。

描述系统运行的组织和实施体系结构。 组织实现模型以实现设计到实现无缝转移。

3) 分析行为 将用例提供的行为描述转变为一系列可作为

设计基础的元素。 在分析行为时，主要注重于如何能够提供要求的功能，较少关心系统的非功能需求。

4) 设计构件 找出设计元素如何实现要求行为的细节，细

化设计元素的定义。 根据新的设计元素来细化和更新用例实现。 当设计演进后，进行设计评审。

5) 设计实时构件 在实时的或交互式的上下文中，使用封装制品作为主要的设计元素。

设计实时构件与设计构件有相似的活动，但增加了封装设计活动，定义系统的并发控制线程和它们之间的协议。

6) 设计数据库 在设计中标识永久类并设计适当的数据库结

构来存储永久类。 定义一种存储和检索永久数据的机制和策略，

以满足系统的性能需求。

分析和设计工作流中的关键制品：1) 设计模型 由类的协作构成。这些类的协作

可能集成为包或子系统。包是对类的逻辑分组，是为了减少系统的复杂性。

2) 分析模型 是设计的抽象和泛化，它提供系统的功能描述，忽略了系统如何工作的细节。

3) 软件体系结构文档 涵盖系统不同的体系结构视图。

实现工作流

实现工作流的目的是 建立代码的分层结构； 从构件（源文件、二进制文件、可执行文件或其他文件）角度来实现类和对象；

对开发出来的构件进行单元测试； 将个人和开发团队开发的结果集成到可执行系统中。

单元测试仅对单个构件进行。集成测试和系统测试在测试工作流中执行。

构造实现模型构造实现模型

集成每个子系统集成每个子系统

集成系统集成系统

制定集成计划制定集成计划

实现构件实现构件

[ 可用于单元测试的构件 ]

[ 可用于集成的实现子系统 ][针对这个

迭代过程 的更多的 系统构造 ]

[针对这 个迭代 过程的 更多的 子系统构造 ]

[针对这个 迭代过程 的更多的 要实现的

构件 ]

实现模型是在细化阶段通过不断迭代，不断使用更大规模的集成构造建立起来的。

对于每一次迭代，要求做到：1) 确定要实现哪一个子系统，以及在当前迭代中子

系统的集成顺序。2) 对于每一个子系统，确定实现每个类的顺序，以

及子系统集成的计划。3) 实现设计模型中的类和对象，包括编写源代码、改写已有构件、编译、链接和执行，及时反馈设计中可能的缺陷。

4) 修改有缺陷的源代码，进行单元测试以验证这些变更。最后进行代码评审。

5) 指定专人负责将所有新的和已变更的构件集成为一个新的实现子系统版本。在团队环境，集成将产生一系列构造，对每个构造由集成测试员进行集成测试。

6) 将发布的子系统集成到系统。最终的构造即为系统。由系统测试员进行系统测试。

实现工作流的关键制品有：1) 实现子系统 构件和其他实现子系统的集成。它是

将实现模型细分为更小的部分，并使其构造化。2) 构件 可以是一块程序代码，或是包含信息的文件。

构件可以由其他构件聚合而成。3) 集成构造计划 定义构件和子系统的实现顺序，详

细描述系统集成时要建立的构造。 实现与设计的关系紧密。在设计元素和实现元素之间有非常

明显的跟踪链接。

创建良好设计的原则

设计原则 1 ：分治 软件系统分解为子系统

分布式系统可以分解为客户机和服务器； 系统可以分解为一系列子系统； 子系统可以分解为一个或多个包； 包可以分解为类； 类可以分解为方法。

设计原则 2 ：尽可能增加内聚 不同内聚类型：优先级从高到低排序7) 功能内聚：模块只执行单一计算并返回结果，没

有副作用。如函数过程。8) 层内聚：相关服务放在一起，并有严格的层次结

构，高层服务可访问低层服务，反之不可。如分层结构。

9) 通信内聚：访问或操作同一数据的过程放在一个类中，这些过程可以互相通信。如某个类设计。

4) 顺序内聚：存在一系列过程，其中一个过程向另一个过程提供输入，这些过程放在一起，形成顺序内聚。如消息序列。

5) 过程内聚：几个一次调用的过程放在一起，但其中一个过程的输出不一定是另一个过程的输入，形成过程内聚。如调用结构。

6) 时间内聚：程序执行过程中同一阶段内完成的操作放在一起，达到时间内聚。

7) 实用程序内聚：逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用程序内聚。如可复用的过程或类。

设计原则 3 ：尽可能降低耦合 模块间存在相互依赖关系即为耦合。不同耦合类

型从高向低排列有：9) 内容耦合：一个构件在不被察觉的情况下修改另

一个构件内部的数据，应始终避免。10) 公共耦合：一组构件使用了全局数据，就产生公

共耦合。应通过封装降低公共耦合。11) 控制耦合：一个过程通过标志、开关或命令显式地控制另一个过程的动作，就产生控制耦合。降低的方法是采用多态操作。

6) 标记耦合：在一个操作的参数表中将类作为参数，就产生标记耦合。降低标记耦合的方法可以传递简单变量或使用接口做参数。

7) 数据耦合：在一个操作的参数表中用简单变量或简单的类（如 string ）作为参数，就产生数据耦合。应通过减少参数个数降低耦合。

8) 例程调用耦合：一个例程（或类操作）调用另一个例程，就产生例程调用耦合。如果出现例程调用序列，降低的方法是编写一个例程将这个调用序列封装起来。

3) 类型使用耦合：类将实例变量或本地变量声明为另一个类时，就产生类型（嵌套）使用耦合。降低该耦合的方法是将变量的类型声明为包含所需操作的最通用的类或接口。

4) 包含 /引入耦合：当一个构件引入（ import ）一个包时就产生引入耦合，当一个构件包含（ include ）另一个构件时，就产生包含耦合。

5) 外部耦合：模块对外部系统，如操作系统、共享库或硬件有依赖关系时就产生外部耦合。可通过信息隐蔽减少这种依赖关系。

设计原则 4 ：尽可能提高抽象层次 设计应隐藏或推迟考虑细节以降低复杂性。

类是包含过程抽象的数据抽象。 父类和接口可进一步提高抽象层次。 类中公有操作越少，抽象程度越高。 类中所有变量都是私有，抽象程度达到最高。

抽象可确保在设计时不必关心不必要的细节，能把握问题的本质并做出重要的决策。

设计原则 5 ：尽可能提高可复用性

可以在算法、类、过程、框架和完整应用程序的级别上创建可复用性。

复用构件的机制包括过程调用和继承父类。

设计原则 6 ：尽可能复用已有的设计和代码 复用已有的设计是对可复用性设计的补充。通过复用可从以往对可复用构件的投资中获益。

设计原则 7 ：灵活性设计 积极预测将来可能在实现和功能上的变化，并为

此采取相应措施。

在设计中引入灵活性的方法有： 降低耦合并提高内聚（易于提高替换能力） 建立抽象（创建有多态操作的接口和父类） 不要将代码写死（消除代码中的常数） 抛出异常（由操作的调用者处理异常） 使用并创建可复用的代码

设计原则 8 ：预计过期 积极预测将来可能在技术和运行环境上的变化，

并为此采取相应措施。

在设计中应遵循的预计过期的规则有： 避免使用早期发布的技术 避免使用针对特定环境的软件库 避免使用软件库中未编档的或很少使用的功能 避免使用小公司或可能不提供长期支持的公司提供的可复用构件或特殊硬件

使用众多厂商支持的标准语言和技术

设计原则 9 ：可移植性设计

可移植性设计的主要目标是让软件在尽可能多的平台上运行。实现可移植性的规则有： 避免使用特定环境的专有功能 使用不依赖特定平台的程序设计语言 小心使用可能依赖某一平台的类库 了解其他语言可能依赖特殊硬件结构的功能和文本文件的差异

设计原则 10 ：可测试性设计 设计时采取措施使得测试易于进行。

可测试性设计的最重要的方法是保证代码的所有功能都能脱离图形用户界面执行

设计原则 11 ：防御性设计 为提高可靠性，应确保不引入任何缺陷，能够处理

其他代码不适当使用构件引起的问题。 按契约设计是防御性设计技术，其核心思想：

被调用操作为正常执行必须满足的前置条件 (precondition) ：调用操作在调用一个操作时有责任确保该操作的前置条件成立。

被调用操作正常执行所得到的结果即为后置条件 (postcongdition) ：要求被调用操作在返回前有责任保证这些后置条件成立。

被调用操作在执行时确保不会被修改的不变量(invariant) 。

前置条件、后置条件和不变式都是布尔表达式，其计算结果为假，表示有错误发生。

可以使用断言机制。 在重要构件的边界（如层）应始终保留严格的断言检测。

设计模式

设计模式是面向对象软件设计经验的总结。 设计模式系统地命名、解释和评价了面向对象系

统中的一个重要的和重复出现的设计。 设计模式使人们可以简单方便地复用成功的设计

和体系结构。 设计模式描述了在特定场景下使用的解决一般设

计问题的类和相互通信的对象。

设计模式的四个基本要素

模式名 用于描述模式的名字，说明模式的问题、解决方案和效果。

问题 说明在何种场合使用模式。要描述使用模式的先决条件和特定设计问题。

解决方案 描述设计的成分、它们之间的相互关系、各自的职责和合作方式。

效果 描述模式使用的效果，包括对时间和空间的衡量，以及对系统灵活性、可扩充性、可移植性的影响。

设计模式的特性

灵活性 设计模式应是精巧的解决方法。 一般化 设计模式不依赖于某一种特定的系统

类型、程序设计语言或应用领域。 已验证 设计模式已在某些面向对象系统中实践并已通过测试。

简单性 设计模式通常较小，只有几个类。 可复用 可在设计层次（不是编码层次）应用

于所有的系统。 面向对象 设计模式以面向对象的形式出现。

设计模式的类型 依据设计模式工作目的不同，模式可分为

创建型模式 (Creational pattern) 结构型模式 (Structural pattern) 行为型模式 (Behavioral pattern)

创建型模式与对象的创建有关； 结构型模式处理类和对象的组合，将一组对象组

合成一个大的结构，例如复杂的用户界面； 行为型模式描述类或对象的交互和职责分配，定

义对象间的通信和复杂程序中的流控。

1 、创建型模式

创建型模式描述怎样创建一个对象。它隐藏对象创建的具体细节，使用程序可不依赖具体的对象。因此当增加一个新对象时几乎不需要修改代码。

创建型类模式将对象的部分创建工作延迟到子类，创建型对象模式将它延迟到另一对象中。

这时，重点从定义固定的行为集合转向定义一个较小的基本行为集合，由这些行为可以组成许多更复杂的行为集合。

模式的特点 封装了系统中使用的类的具体信息； 隐藏了这些类的实例如何创建、如何放在一起的（机制）。

系统关于这些对象所知道的只有由抽象类定义的接口。

创建型类模式有 Factory Method ( 工厂方法 ) 。 创建型对象模式包括 Abstract Factory (抽象工厂 ) 、 Builder (生成器 ) 、 Prototype (原型 ) 、Singleton (单件 )四种模式。

2 、结构型模式

结构型模式处理类或对象的组合，即描述类和对象之间怎样组织起来形成大的结构，从而实现新的功能。

结构型类模式采用继承机制来组合类，如 Adapter (适配器 ) 模式；

结构型对象模式则描述了对象的组装方式，如 Adapter (适配器 ) 、 Bridge (桥接 ) 、 Composite (复合 ) 、 Decorator ( 装饰 ) 、 Facade (外观 ) 、Flyweight (享元 ) 、 Proxy (代理 ) 等七种模式。

3 、行为型模式

行为模式涉及算法和对象之间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信。

行为模式刻划了在运行时难以跟踪的复杂的控制流，但这类模式把人们的注意力从控制流转移到对象间的相互联系。

类行为模式使用继承机制在类间分派行为，如 Template Method ( 模板方法 ) 和 Interpreter (解释器 ) 模式。

对象行为模式使用对象复合而不是继承，描述对象如何协同完成预定任务，如 Chain of Responsibility (职责链 ) 、 Command (命令 ) 、 Iterator (遍历器 ) 、 Mediator ( 中介者 ) 、 Memento (备忘录 ) 、 Observer ( 观察者 ) 、 State (状态 ) 、 Strategy (策略 ) 、 Visitor (访问者 ) 等九种模式。

面向对象测试 面向对象系统的测试与传统的基于功能的系统

的测试之间存在很大差别：1) 对象作为一个单独的构件一般比一个功能模

块大。2) 由对象到子系统的集成通常是松散耦合的，没有一个明显的“顶层”。

3) 如果对象被复用，测试者无权进入构件内部来分析其代码。

面向对象系统的测试可分为 4 个层次：1) 测试与对象相关联的单个操作 它们是一

些函数或程序，传统的白盒测试和黑盒测试方法都可以使用。

2) 测试单个对象类 黑盒测试的原理不变，但等价划分的概念要扩展以适合操作序列的情况。

3) 测试对象簇（聚集） 严格的自顶向下或自底向上的集成不适合一组关联对象的情形。应使用基于场景的测试等其他方法。

对象类测试

4) 测试面向对象系统 根据系统需求规格说明进行检验和有效性验证的过程可以像对其他范型的系统一样进行。

在测试对象时，完全的覆盖测试应当包括：在测试对象时，完全的覆盖测试应当包括：1)1) 隔离对象中所有隔离对象中所有操作操作，进行独立测试。，进行独立测试。2)2) 测试对象中所有测试对象中所有属性属性的设置和访问。的设置和访问。3)3) 测试对象的所有可能的测试对象的所有可能的状态转换状态转换。所有可。所有可

能引起状态改变的事件都要模拟到。能引起状态改变的事件都要模拟到。

对象类，作为在语法上独立的构件，应当允许用在不同的应用中。每个类都应是可靠的，并且不需了解任何实现的细节就能复用。因此，对象类应尽可能孤立地进行测试。

设计操作的测试用例时需要注意： 首先定义测试对象的各操作的测试用例。 对于一个单独的操作，可通过该操作的前置条件选择测试用例，产生输出，让测试者能够判断后置条件是否能够得到满足。

各个操作的测试与传统对函数过程定义的测试基本相同。

然后再把测试用例组扩充，针对被测操作调用对象类中其他操作的情况，设计操作序列的测试用例组。

测试可以覆盖每个操作的整个输入域。但这不够，还必须测试这些操作的相互作用，才能认为测试是充分的。

各个操作间的相互作用包括类内通信和类间通信。

putReferencePoint(Point)putReferencePoint(Point)

moveTo(Point)moveTo(Point)ReferencePointReferencePoint

area( )area( )

draw( )draw( )

erase( )erase( )

getReferencePoint(Point)getReferencePoint(Point)

DisplayableShape(Point)DisplayableShape(Point)

DisplayableShape

类内消息类间消息

DisplayableShape( )DisplayableShape( )

在设计对象类的规格说明测试时需要注意： 把对象类当做一个黑盒，确认类的实现是否遵照它的定义。对于“ Stack” 的测试应当确保 LIFO 原则得以实施。

对于多数的对象类，主要检验在类声明的 public 域中的那些操作。

对于子类，要检查继承父类的 public 域和 protected 域的那些操作。

检查所有 public域， protected域及 private 域中的操作以完全检查对象中定义的操作。

等价划分的思想也可用到对象类上。将使用对象相同属性的测试归入同一个等价划分集合中。这样可以建立对对象类属性进行初始化、访问、更新等的等价划分。

在设计对象类的行为测试时需要注意： 基于对象的状态模型进行测试时，首先要识别需要测试的状态的变迁序列，并定义事件序列来强制执行这些变迁。

原则上应当测试每一个状态变迁序列，当然这样做测试成本很高。

对象集成测试 当开发面向对象系统时，集成的层次并不明显。而当一组对象类通过组合行为提供一组服务时，则需将它们一起测试，这就是簇测试。

此时不存在自底向上和自顶向下的集成。

完全的单元应当保证类的执行必须覆盖它完全的单元应当保证类的执行必须覆盖它的一个有代表性的状态集合。的一个有代表性的状态集合。

构造函数和消息序列（线索）的参数值的构造函数和消息序列（线索）的参数值的选择应当满足这个规则。选择应当满足这个规则。

簇需要根据对象操作以及对象属性的关联来构成。 面向对象系统的集成测试有 3 种可用的方法：

1) 用例或基于场景的测试 用例或场景描述了对系统的使用模式。测试可以根据场景描述和对象簇来制定。这种测试着眼于系统结构，首先测试几乎不使用服务器类的独立类，再测试那些使用了独立类的下一层次的（依赖）类。这样一层一层地持续下去，直到整个系统构造完成。

2) 基于线程的测试 它把为响应某一系统输入或事件所需的一组对象类组装在一起。每一条线程将分别测试和组装。因为面向对象系统通常是事件驱动的，因此这是一个特别合适的测试形式。

3) 对象交互测试 这个方法提出了集成测试的中间层概念。中间层给出叫做 “方法 -消息”路径的对象交互序列。所谓“原子系统功能”就是指一些输入事件加上一条“方法 -消息”路径，终止于一个输出事件。

面向对象的确认测试

在确认测试或系统测试的层次上，不再考虑对象类间相互连接的细节。主要着眼于用户可见的动作和用户可识别的系统输出。

为了帮助确认测试的执行，测试者需要回到分析时的动态模型和描述系统行为的事件序列（脚本）进行测试。

可以利用黑盒测试的方法来驱动确认测试。测试检测软件中的故障并确定软件是否执行了预定要开发的功能。

面向对象测试用例的设计

测试过程包括了一组测试用例的开发，每一个测试用例要求能检验应用的一个特定的元素。还需要分析用各个测试用例执行测试的结果来收集有关软件的信息。

软件测试人员可以参考以下方法：1) 应当唯一标识每一个测试用例，并与被测试

的类显式地建立关联。2) 陈述测试对象的一组特定状态。

3) 对每一个测试建立一组测试步骤，要思考和确定的问题包括：

被测试对象的一组特定状态； 一组消息和操作； 考虑在对象测试时可能产生的一组异常； 一组外部条件； 辅助理解和实现测试时的补充信息。

传统的白盒测试方法可用在类定义的操作测试和类级别测试中，黑盒测试方法可用于多类测试。

小结：（自己完成）

P223 一 , 二 ( 书上 )

作业作业 ::

谢谢使用谢谢使用本课件本课件 !!