1

第三部分第三部分

面向对象的设计面向对象的设计

2

第一章 什么是面向对象的设计（OOD）？

主要知识点

1、什么是OOD

早期的OOD和现今OOD的差别；

2、 OOA与OOD的关系。

3、从MDA的观点看OOA与OOD

3

概而言之，面向对象的设计（OOD）就是运用面向对象方法 进行系统设计；但不同时期有不同内容及特点。

一、早期的OOD（八十年代至九十年代初）：

历史：从OOP发展到OODG. Booch 1982 年发表“Object-Oriented Design” ，

首次称“面向对象的设计”。1986 年发表“Object-Oriented Development”

较完整地阐述了OOD思想。

两个术语都用OOD作为缩写，内容上也没有根本区别

R. J. Abbott 1983年提出正文分析方法，

用规范的英语描述对一个问题的解释，然后从描述中提取对象及其

特征。例：名词——对象，动词——操作。被后来的许多OOD方法

所采用。

1986年后，相继出现了一批（早期的）OOD方法

什么是面向对象的设计（OOD）？

4

早期的OOD方法

Booch86——Object-Oriented Development面向对象的开发

GOOD——General Object-Oriented Development通用面向对象的开发

HOOD——Hierarchical Object-Oriented Design层次式面向对象的设计

OOSD——Object-Oriented Structured Design面向对象的结构设计

……

5

1、不是基于OOA的

大多基于结构化分析结果（数据流图）

2、是OO编程方法的延伸多数方法与编程语言有关，特别受Ada影响很大

3、不是纯OO的对某些OO概念（如继承）缺少支持，搀杂一些非OO 概念（如数据流、包、模块等）

4、不是只针对软件生命周期的设计阶段OOD中的“D”——指的是Design 或 Development多少涉及分析问题（如识别问题域的对象），但很不彻底

——早期的OOD可看作现今OOA&D方法的雏形

早期OOD的特点：

6

定义：

面向对象的设计（OOD）就在是OOA模型基础上运用面 向对象方法进行系统设计，目标是产生一个符合具体实

现条件的OOD模型。

二、现今（90年代）的OOD特点：

1. 以面向对象的分析为基础，一般不依赖结构化分析。

2. 与相应的OOA方法共同构成一种OOA&D方法体系。 OOA和OOD采用一致的概念与原则，但属于软件生命周 期的不同阶段，有不同的目标及策略。

3. 较全面地体现面向对象方法的概念与原则。

4. 大多数方法独立于编程语言，通过面向对象的分析与设 计所得到的系统模型可以由不同的编程语言实现。

7

一致的概念与表示法

OOD是否有必要引入非OO概念？Booch方法引入模块、依赖关系等概念及表示法，OMT引入模块概念，OOSE引入块概念及表示法

本书的观点：前端

OOA——可以全部用OO概念建模；

后端

OOP——可以全部用OOPL支持的OO概念编程。

OOD作为OOA与OOP之间承前启后中间环节，不必借助非 OO的概念和表示法。

——提倡采用与OOA和OOP一致的概念建立完整的、可实 现的面向对象设计模型。

三、OOA与OOD的关系

8

不同的内容与目标：OOA——主要内容是研究问题域和用户需求，运用面向对

象的观点和原则发现问题域中与系统责任有关的对象，以及 对象的特征和相互关系。目标是建立一个直接映射问题域， 符合用户需求的OOA模型。

OOD——主要内容是以OOA模型为基础，按照实现的要求 进行系统设计，包括全局性的决策和局部细节的设计。目标 是产生一个满足用户需求，并且完全可实现的OOD模型。

OOD的抽象层次——设计层次

由抽象层次决定的设计策略全局性设计决策：体系结构、分布方案、并发控制、人机交

互、数据管理等。OOD方法应支持用户以OO概念表达对这 些问题的设计。

局部细节的设计：对每个对象类的每个属性和每个操作给出 详细的定义。

不同的目标、内容和抽象层次

9

从MDA看OOA与OOD的关系

模型驱动的体系结构（model-driven architecture，MDA ） 是OMG的一个技术规范，是一种加强模型能力的系统开发途

径。

模型驱动（ model-driven ）：用模型来对系统的理解、设计、 构造、部署、操作、维护和更改进行指导。

体系结构（ architecture ）：是对系统的部件和连接件以及 这些部件通过连接件进行交互的规约。

平台（platform）：是一组子系统和技术，它通过一些接口 和专用规则提供了一个连贯的功能集合，任何由该平台支持 的应用可以使用平台所提供的功能而不必关心其实现细节。

平台无关模型（platform independence model，PIM）：独 立于任何一种平台特征的模型。

平台专用模型（platform specific model，PSM）：与特定类 型的平台特征有关的模型。

10

模型转换（model transformation）：由系统的一个模型转化成 同一个系统的另外一个模型。它是MDA 为关键的部分，其核 心问题是从PIM转换到PSM 。

MDA提倡：在系统开发中首先建立平台无关模型（PIM）， 然后将它转换为平台专用模型（PSM）

技术

11

把MDA的观点运用于OOA和OOD提倡在OOA阶段建立一个平台无关的OOA模型，并在

OOD阶段将它转换成一个平台专用的OOD模型。

Coad/Yourdon方 法关于OOA与OOD 的分工观点恰好 符合MDA的思想

做什么

怎么做

问题域与系统责任

与实现有关的因素

分

析

设

计

第一种观点

分 析 设 计

第二种观点

12

主要知识点

1、更具体地理解OOA和OOD的关系

2、OOD模型四个组成部分之间的关系

——OOD模型框架

第二章 本课讲授的OOD方法概貌

13

概念：运用与OOA相同的概念——没有增加新概念

对象、类、属性、操作、封装、 继承、消息、关联、聚合、多态、

主动对象

等

表示法：采用与OOA一致的表示法

分析

设计

数据流图（DFD）

模块结构图

（MSD）

实体-关系图（ERD）

传统方法分析与设

计之间的鸿沟

使分析 与设计 之间不 存在鸿 沟

OOA OOD

一致的

概念

一致的

表示法

类图

类图

面向对象的分析与设计

之间不存在鸿沟

14

OOD的基本思想：

问题域 部分

OOA模型

以平台无关的OOA模型为 基础，按实现平台进行必 要的调整，作为OOD模型

的核心部分，即问题域部 分；

人机交互部分

数据接口部分

控制驱动部分

针对实现平台的三个主要 方面，增补三个平台相关 的外围部分，尽可能隔离 实现条件对核心部分的影 响，构成完整的OOD模型。

以OOA模型为基础，继续运用面向对象的概念与原则，针 对具体的实现条件进行系统设计。

15

OOD模型框架——从两个侧面来描述

人机交互部分

数据接口部分

控制驱动部分

问题域部分

从一个侧面观察：OOD模型包括几个主要部分？

一个核心加三个外围

需

求

模

型辅

助

模

型

类

图

模型

规约

从另一侧面观察：OOD模型每个部分

如何用OO概念表达？采用与OOA相同的概念及

模型组织方式

16

OOD过程：

逐个设计OOD模型的四个部分

问题域部分的设计人机交互部分的设计控制驱动部分的设计数据接口部分的设计

不强调次序

每个部分均采用与OOA一致的概念、表示法及活动，

但具有自己独特的策略。

17

主要知识点

1、什么是问题域部分，它与OOA的关系

2、问题域部分的设计内容与策略

第三章 问题域部分的设计

18

将OOA模型搬到OOD作为OOD的基础

人机交互部分

数据接口部分

控制驱动部分

问题域部分

OOA模型

按编程语言、网络

、操作系统、复用

支持等实现条件进

行必要的调整

什么是问题域部分？

对OOA结果按实现条件进行补充与调整,所得到的结果就是 OOD模型的问题域部分。

不是传统方法中的“转换”，分析与设计之间不存在鸿沟。主要不是细化，但OOA未完成的细节定义要在OOD完成。是对OOA模型的补充与调整

19

影响问题域部分设计的主要因素

编程语言

语言的实现能力

硬件、操作系统及网络设施

对性能的影响

复用支持

需要根据复用支持对模型做适当调整

数据管理系统

需要问题域部分做某些修改以实现数据的永久存储

界面支持系统

问题域部分与人机界面之间的消息传输

20

设计准备保留OOA文档复制OOA文档，作为OOD的输入

根据需求的变化和发现的错误进行修改

设计内容与策略（本节的重点）针对编程语言支持能力的调整

增加一般类以建立共同协议

实现复用提高性能

为实现对象永久存储所做的修改

完善对象的细节

定义对象实例

对辅助模型、模型规约的修改和补充

建立OOD文档与OOA文档的映射

21

1、按编程语言调整继承与多态

起因：OOA强调如实地反映问题域，OOD考虑实现问题，

所用语言不支持多继承或者不支持多态

多继承模式

狭义菱形 广义菱形

（1）多继承化为单继承

22

方法1：简单转换

（a）

一般方法

或

A

C 1

1

1

1

1

1

B A

C

B

1

A

C

B

（c）

不合适的例子

？

职员 学员

在职学员

职员 学员

在职学员

1

1

1

1

（b）

合适的例子

汽车 制冷设备

冷藏车

或1

1

1

1

11

汽车 制冷设备

冷藏车

汽车 制冷设备

冷藏车

（d）

转换产生信息重复

A A

B C

D

？ B C

D

23

方法2：重新定义对象类，化解多继承

职员 学员

在职学员

人员

职员身份 学员身份

人员

1

0..1

1

0..1

职员身份 学员身份

身份

人员

1

0..2

24

不适当的方法增加程序代码

职员 学员

人员

在职学员

方法3：保持分类，剥离多继承信息

职员 学员

人员

在职学员

职员信息 学员信息

1

1

1

1

1

1

1

1

25

（2）取消多态性

(a) (b)

多边形

线条色线型边数顶点坐标

绘图填充

正多边形

*顶点坐标

*绘图

矩形

×边数*顶点坐标

*绘图

多边形

线条色线型

正多边形

绘图

矩形

顶点坐标

绘图

不规则多边形

绘图

边数顶点坐标

边数顶点坐标

填充

26

2、增加一般类以建立共同协议

增加根类：将所有的类组织在一起

提供全系统通用的协议

例：提供创建、删除、复制等操作

增加其他一般类：提供局部通用的协议

例：提供永久存储及恢复功能

27

B C E

A

属性

操作

D F

1

*

属性

操作

属性

操作

属性

操作

属性

操作

属性

操作

例： Object«复用»

28

3、为实现复用所进行的设计

如果已存在一些可复用的类，而且这些类既有分析、设 计时的定义，又有源程序，那么，复用这些类即可提高 开发效率与质量。

目标：尽可能使复用成分增多，新开发的成分减少

当前所需的类的信息

比

可复用类定义的信息

＝

直接复用

＜

通过继承复用

＞

删除可复用类的多余信息

≈

删除多余信息，通过继承而复用

29

例：

车辆

序号颜色式样出厂年月

序号认证

车辆

序号厂商式样

序号认证

可复用的类

问题域部分的类

«复用»车辆

序号厂商式样

序号认证

可复用的类

30

4、提高性能

（1）调整对象分布

类A 类B

类C

甲机

乙机

类A

类B 类C

甲机

乙机 甲机

乙机

类A 类B

类C

（2）缩短对象存取时间

设立缓冲区

或

31

（3）合并通讯频繁的类

流速调节器

指定流速……

流速调节… …

流速探测器

当前流速……

流速探测取当前流速… …

流速控制器

指定流速当前流速……

流速调节流速探测… …

合并前 合并后

（4）增加属性以减少重复计算

32

（5）降低算法的计算复杂性

（6）细化对象的分类

二次曲线

……

……

抛物线

绘图

双曲线

绘图

椭圆

绘图

二次曲线

……

绘图

……

33

（7）将复杂对象化为整体-部分结构

帧

5、为数据存储管理增补属性与操作

在数据接口部分设计中介绍

背景 前景

显示显示

1

* 1

1

34

6、完善对象的细节

OOD在OOA模型基础上所做的主要工作，不能用“细化”二 字概括，但细化是不可缺少的

（1）完善与问题域有关的属性和操作在OOA阶段允许不详尽，OOD必须加以完善

（2）解决OOA阶段推迟考虑的问题，包括：因封装原则而设立的对象操作与对象永久存储方案有关的属性和操作

（3）设计类的每个操作必要时用流程图或者活动图表示用属性表示算法所需的数据结构

（4）设计表示关联的属性区分多重性的3种情况，决定属性设置在哪一端

（5）设计表示聚合的属性区分组合与松散的聚合对于组合，用嵌套对象实现对于松散的聚合，采用与关联相同的策略

35

7、定义对象实例

在逻辑上，一个类的对象实例是：问题域中所有可用这个类描述的实际事物

在物理上，一个类的对象实例可以是：内存中的对象变量文件的一个记录，或数据库表的一个元组

一个类的对象实例可以分布到不同的处理机上对每一台处理机

说明在它之上创建的每一个（或组）内存对象说明在它之上保存的外存对象

类的对象实例说明：{处理机：<结点名>{,<结点名>}内存对象：{<名称>[（n元数组）][<文字描述>]}外存对象：{<名称>[<文字描述>]}

}

36

建立与OOA文档的映射

指出OOA模型中的哪个 （或哪些）类演化为

OOD模型中的哪个（或 哪些）类

OOA 类与OOD 类映射表

映射方式 OOA 类 OOD 类

1 = 1

1 to 1

1 to m

m to 1

m to m

0 to 1

图 3.13 OOA 类与 OOD 类的映射表

37

第四章 人机交互部分的设计

主要知识点

1、什么是人机交互部分，它的主要作用

2、如何从用况抽取人机交互

3、命令的组织结构

4、根据命令结构确定界面成分

5、用面向对象概念表示界面成分

38

一、什么是人机交互部分

人机交互部分是OOD模型的外围组成部分之一，是系统中负 责人机交互的部分。其中所包含的对象（称作界面对象）构 成了系统的人机界面。

现今的系统大多采用图形方式的人机界面——形象、直观、 易学、易用，远远胜于命令行方式的人机界面，是使软件系 统嬴得广大用户的关键因素之一。

但开发工作量大，成本高。近20年出现了许多支持图形用户 界面开发的软件系统，包括：

窗口系统（如X Window，News，MS-Windows）；图形用户界面（GUI）（如OSF/Motif，Open Look）；可视化开发环境（如Visual C++，Visual Basic，

Delphi）——统称界面支持系统。

人机交互部分既取决于需求，又与界面支持系统密切相关。

39

人机界面的开发不仅是设计和实现问题，也包括分析问 题——对人机交互需求的分析。

人机界面的开发也不纯粹是软件问题，它还需要心理学、 美学等许多其它学科的知识。

把人机交互部分作为系统中一个独立的组成部分进行分析 和设计，有利于隔离界面支持系统的变化对问题域部分的 影响

控制驱动部分

问题域部分

数据接口部分

人机交互部分

OSF/Motif

人机交互部分

X-Window

人机交互部分

MS-Windows

40

二、人机交互部分的需求分析

对使用系统的人进行分析——以便设计出适合其特点的交互方式和界面表现形式；

对人和机器的交互过程进行分析——核心问题是人如何命令系统，以及系统如何向人提交

信息。

1、分析与系统交互的人（参与者）

人对界面的需求，不仅在于人机交互的内容，而且在于他 们对界面表现形式、风格等方面的爱好

——前者是客观需求，对谁都一样；后者是主观需求，因 人而异。

(1)列举所有的人员参与者(2)调查研究(3)区分人员类型(4)统计（或估算）各类人员的比例(5)了解使用者的主观需求

41

2、从用况分析人机交互

用况的构成参与者的行为和系统行为按时间顺序交替出现，左右分

明。形成交叉排列的段落。每个段落至少含有一个输入语句或输出语句；有若干纯属参与者自身或系统自身的行为陈述；可能包含一些控制语句或括号。

抽取方法：删除所有与输入、输出无关的语句删除不再包含任何内容的控制语句与括号剩下的就是对参与者（人）使用一项系统功能时的人机

交互描述

42

收款员·收款

输入开始本次收款的命令；作好收款准备，应收款总数置为0，输出提示信息；

for

顾客选购的每种商品

do输入商品编号；if

此种商品多于一件

then输入商品数量

end if；检索商品名称及单价；货架商品数减去售出数；if

货架商品数低于下限

then通知供货员请求上货

end if；计算本种商品总价并打印编号、名称、数量、单价、总价；总价累加到应收款总数；

end for；打印应收款总数；

输入顾客交来的款数；计算应找回的款数，打印以上两个数目，收款数计入账册。

（b）删除与输入输出无关的陈述

收款员·收款

输入开始本次收款的命令；作好收款准备，应收款总数置为0，输出提示信息；

for

顾客选购的每种商品

do输入商品编号；if

此种商品多于一件

then输入商品数量

end if；检索商品名称及单价；货架商品数减去售出数；if

货架商品数低于下限

then通知供货员请求上货

end if；计算本种商品总价并打印编号、名称、数量、单价、总价；总价累加到应收款总数；

end for；打印应收款总数；

输入顾客交来的款数；计算应找回的款数，打印以上两个数目，收款数计入账册。

（a）一个用况的例子

从用况提取人机交互描述

收款员．收款（人机交互）输入开始本次收款的命令；

输出提示信息；for 顾客选购的每种商品输入商品编号；if 此种商品多于一件 then输入商品数量

end if；打印商品编号、名称、数量、单价、总价；

end for；打印应收款总数

输入顾客交来的款数打印交款数及找回款数；

（c）得到人机交互描述

43

2．人机交互的细化

（1）输入的细化

①输入步骤的细化②输入设备的选择③输入信息表现形式的选择

（2）输出的细化

①输出步骤的细化②输出设备的选择③输出信息表现形式的选择

44

3、命令的组织

不受欢迎的命令组织方式：（1）一条命令含有大量的参数和任选项（2）系统有大量命令，不加任何组织和引导

命令的组织措施——分解与组合（1）分解：将一条含有许多参数和选项的命令分解为

若干命令步（2）组合：将基本命令组织成高层命令，从高层命令

引向基本命令

基本命令：使用一项独立的系统功能的命令。命令步：在执行一条基本命令的交互过程中所包含的具体

输入步骤。高层命令：如果一条命令是在另一条命令的引导下被选用

的，则后者称作前者的高层命令。

45

（c）

半序网状结构

（b）

树型结构

（a）

线性结构

（d）

一般的网状结构

基本命令及其命令步的结构

46

高层命令及其结构

47

两层命令之间的输出信息结构

反馈信息

处理结果

提示信息

反馈信息

处理结果

处理结果

提示信息 提示信息

处理结果

提示信息

48

三、人机界面的设计准则

使用简便一致性启发性减少人脑记忆的负担减少重复的输入容错性及时反馈其它：如艺术性、趣味性、风格、视感等

49

四、人机界面的OO设计

1、选择界面支持系统

不同的支持级别：0级：操作系统和普通编程语言

——全部人工编程1级：图形软件包

——提供基本图形元素的绘制函数2级：窗口系统

——提供实现人机界面基本成分的支撑机制

如实现窗口、菜单、对话框的库函数3级：GUI

——为实现具有特定的风格和视感的图形用户 界面提供了更强的支持

4级：可视化编程环境——以“所见即所得”的方式构造用户界面

50

2．根据人机交互需求选择界面元素

如窗口、菜单、对话盒、图符、滚动条、控制板、剪辑 板、光标、按钮等

（1）系统的启动

选用实现主界面的界面元素，如窗口、对话框窗口（2）高层命令组织结构的实现

通过界面元素的构造层次体现高层命令的组织结构（3）基本命令的执行

高层命令的执行是在人机界面上把用户引向基本命令， 基本命令的执行则是从界面给实现其功能的对象送消息

（4）详细交互过程的输入与输出

选择适当的界面元素完成每个命令步的输入与输出（5）异常命令的输入

使用支持异常命令输入的界面功能，如鼠标右键菜单

51

3、用OO概念与表示法表达所有的界面成分

（1）用对象表示各种界面元素

尽可能使用界面类库中提供的可复用类

自定义的类

类名

属性……

操作……

类名«复用»

复用类库中的类

（2）属性与 操作

用属性表示界面对象的静态特征物理特征——如：位置、尺寸、颜色、立体效果逻辑特征——聚合、关联

用操作表示界面对象的行为例如：创建、激活、 大化、 小化、移动、选

中、单击、双击 ……

52

（3）整体-部分结构

表示界面元素之间的构成关系，例如：窗口

与

其中的菜单、按钮、图符、对话框、滚动条

表示界面对象在操作中的逻辑层次反映上、下两层命令之间的关系

例：

53

框架窗口

主菜单

下拉菜单

视窗 工具条

滚动条 按钮

11

1

*

1

*

1

1

1

2

1

1

1

*

54

（4）一般-特殊结构表示较一般的界面类和较特殊的界面类之间的关系

自定义的类之间的一般-特殊关系

用一般-特殊结构特化可复用类

CDialog«复用»

操作

属性

对话框

A

55

（5）关联

表示界面元素之间的语义联系，例如：

按钮

1 1

对话框

（6）消息高层命令到低层命令——界面对象之间的消息基本命令的执行——从界面对象向功能对象发消息信息输出——从功能对象向界面对象发消息

工具条

1 *

56

五、

可视化编程环境下的人机界面设计

1、问题的提出2、所见即所得的界面开发3、设计的必要性（1）设计的主要目的是为实现提供依据

可视化环境下的界面开发，仍然需要预先对以下问题有正确、高效的

设计方案：·为了满足人机交互的需求，人机界面中要使用哪些界面对象？·交互过程中的各项输入和输出应由哪些界面对象完成？·如何通过界面对象类之间的各种关系体现人机交互命令的组织结

构与层次？·如何通过界面对象和功能对象之间的消息实现它们之间的动态联

系？（2）设计的另一个目的是降低失败的风险

不经过设计的界面开发，即使重新做一遍也难以保证有根本性的改进。

4、设计策略需要改进（1）类库的存在（2）以所见即所得的定义界面对象的各种物理属性更为直接

57

5、基于可视化编程环境的设计策略

（1）学习可视化编程环境及其类库

（2）根据人机交互需求选择界面元素（3）建立类图——做什么，不做什么

类的设立——首先想到复用

Cdialog«复用»

CMysystemDig… …

… …

CEdit «复用»

（a）

通过继承复用 （b）

直接复用

两种复用方式举例

58

属性——忽略物理特征，着重表示逻辑特征

设计阶段不必关心描述界面物理特征的属性。诸如：大小、形状、位置、颜色、边框、底纹、图案式样、

三维效果等，由实现人员去自主处理效果更好，效率 更高。

以主要精力定义描述界面逻辑特征的属性表现命令的组织结构的属性、

例如：菜单类的每个选项表示什么命令表现界面元素之间组成关系和关联的属性

例如：对话框中包含哪些控件

59

CMysystemDig

… …

√SetDlgItemText… …

操作——显式地表示从高层类继承的操作

例：CDialog«复用»

60

整体-部分结构——表现界面的组织结构和命令层次

通过整体-部分结构表现界面对象之间的组成关系和人 机交互命令的层次关系——与采用其它界面支持系统

的策略相同

区分界面对象的普通属性和它的部分对象

有些组成部分被作为对象的一个普通属性——例如下拉菜单的选项，窗口的边框

有些组成部分则被作为一个部分对象——例如对话框的一个下拉菜单或按钮

区分两种情况的依据——环境类库有没有给出这种组成部分的类定义

61

一般-特殊结构——多从可复用类直接继承

例：对话框«复用»

对话框

A

对话框

B

编辑框«复用»

按钮«复用»

1

3

1

1

… …… …

… …… …

普通策略

2

1

对话框«复用»

… …… …对话框

A

… …… …对话框

B

编辑框«复用» 按钮«复用»1

11

5

1

1 1

3

直接继承可复用类的策略

62

消息——忽略自动实现的消息

注意需要编程实现的消息

1、界面对象接收到一个操作事件，通过它的一个操作 向处理该事件的功能对象所发送的消息。

2、从功能对象向完成其输入/输出的界面对象发送的 消息。

3、其它：凡是需要通过手工编程来实现的消息，都 要在设计中加以表示。

63

控制驱动部分的设计

主要知识点

1、概念：控制流——进程、线程

2、什么是控制驱动部分，它的作用

3、影响控制驱动部分设计的主要因素

4、如何设计控制驱动部分

关键问题：确定系统中有哪些控制流

64

一、什么是控制驱动部分

控制流（control flow）——进程（process）或线程（thread）

有多个控制流并发执行的系统称作并发系统（多任务系统）

控制驱动部分——是OOD模型的组成部分之一，用来定义和表示并发

系统中的每个控制流，并隔离实现条件对其它各部 分的影响。

用主动对象表示每个控制流

所有的主动类构成OOD模型的控制驱动部分

65

为什么需要控制驱动部分

并发行为是现实中固有的

当前大量的系统都是并发系统（多任务系统），例如：设备与计算机并发工作的系统有多个窗口进行人机交互的系统多用户系统多个子系统并发工作的系统单处理机上的多任务系统多处理机系统……

多任务的设置描述问题域固有的并发行为表达实现所需的设计决策

为了隔离硬件、操作系统、网络的变化对整个系统的影响

66

二、相关技术问题

1、由系统总体方案决定的实现条件：

计算机硬件性能、容量和CPU数目

操作系统对并发和通讯的支持

网络方案网络软硬件设施、网络拓扑结构、通讯速率、网络

协议等软件体系结构编程语言

对进程和线程的描述能力其它商品软件

如数据管理系统、界面支持系统、构件库等——对共享和并发访问的支持

67

2、软件体系结构抽象地说，软件体系结构描述了构成系统的元素、这些

元素之间的相互作用、指导其组合的模式以及对这些模 式的约束

——Mary Shaw

几种典型的软件体系结构风格：管道与过滤器风格（pipe and filter style）数据抽象风格（data abstraction style）面向对象风格（object-oriented style）隐式调用风格（implicit invocation style）层次风格（layered style）仓库风格（repository style）黑板风格（blackboard style）解释器模型（interpreter model）进程控制风格（process control style）客户-服务器风格（client-server style）

68

主机+仿真终端体系结构

文件共享体系结构

客户-服务器体系结构

二层客户-服务器体系结构

三层客户-服务器体系结构

对等式客户-服务器体系结构

瘦客户-服务器体系结构

浏览器-服务器体系结构

3、分布式系统的体系结构风格

69

进程（process）概念出现之前，并发程序设计困难重重

主要原因：并发行为彼此交织，理不出头绪与时间有关的错误不可重现

进程概念的提出使这个问题得到根本解决

进程的全称是顺序进程（sequential process），其基本思想 是把并发程序分解成一些顺序执行的进程，使得：

1、每个进程内部不再包含并发行为

所以叫做顺序进程，其设计避免了并发问题2、多个进程之间是并发（异步）执行的

所以能够构成并发程序

4、系统的并发性

70

由于并行计算的需要，要求人为地在顺序程序内部定义识 别可并发执行的单位。

所以后来的操作系统支持线程（Thread ）概念。

线程与进程的区别：

进程既是处理机分配单位，也是存储空间、设备等资 源的分配单位（重量级的控制流）；

线程只是处理机分配单位（轻量级的控制流）；

一个进程可以包含多个线程，也可以是单线程的。

“控制流”是进程和线程的总称。

71

应用系统的并发性

从网络、硬件平台的角度看：分布在不同计算机上的进程之间的并发；在多CPU的计算机上运行的进程或线程之间的并发；在一个CPU上运行的多个进程或线程之间的并发。

从应用系统的需求看：需要跨地域进行业务处理的系统；需要同时使用多台计算机或多个CPU进行处理的系统；

需要同时供多个用户或操作者使用的系统；需要在同一时间提供多项功能的系统；需要与系统外部多个参与者同时进行交互的系统。

72

例：用多进程实现遥感信息的输入、处理和显示

输入进程

操作

数据

数据处理进程

操作

数据

显示进程

操作

数据

数据 数据

IPC IPC

数据数据

显示屏

地面接收设备

输入输出

遥感信息处理系统

73

用多线程实现遥感信息的输入、处理和显示

输入线程

数据处理线程

显示线程

数据

数据数据

输入 输出

地面接收设备 显示屏

遥感信息处理进程

74

……

业务处理进程 1

操作

输入线程

数据处理线程

显示线程

遥感信息处理进程

数据

数据库管理系统

数据库

数据

数据

业务处理进程 n

操作

数据

IPC/RPC

同时采用多进程和多线程

75

三、如何设计控制驱动部分

1、选择软件体系结构风格

二层客户-服务器体系结构

（数据）服务器——客户机

三层客户-服务器体系结构

数据服务器——应用服务器——客户机

76

2、确定系统分布方案

系统分布——功能分布和数据分布在OOD中都体现于对象分布

原则：减少远程传输，便于管理，可以有副本

根据下列因素决定对象分布：软件体系结构系统功能在哪些节点提供数据在哪些节点长期存储管理，在哪些节点临时使用参照用况

把合作紧密的对象尽可能分布在同一节点

追踪消息

把一个控制流经历的对象尽可能分布在同一节点

对象分布通过类的分布体现

77

考虑分布方案之前，将系统暂时看作集中式的确定分布方案之后，将对象分布的各个处理机上以每台处理机上的类作为一个包

集中式类图

分布到不同结点上

类的分布：根据对象分布的需要

结点A

包A

结点B

包B

结点C

包C

78

3、识别控制流

（1）以结点为单位识别控制流

（2）从用户需求出发认识控制流

（3）从用况认识控制流——区分不同情况

（4）参照OOA模型中的主动对象

（5）为改善性能而增设的控制流

——高优先级任务、低优先级任务、紧急任务

（6）实现并行计算的控制流（线程）

（7）实现结点之间通讯的控制流（进程）

（8）对其它控制流进行协调的控制流

79

4、用主动对象表示控制流

类 名«active»

（a）采用关键字

类 名

类 名«process» 类 名«thread»

@类名

@主动操作@主动操作名

……

被动操作名……

（b）采用特殊的图形

（c）用特定符号指明主动操作

80

@类A

@进程P……

@类B

@线程T1……

@类C

@线程T2……

创建 创建

显示地表示由进程创建线程

81

把控制驱动部分看成一个包其中包含了系统中全部主动类

OOD模型的各个部分可能有交叉例：订单系统中营业员对象等对象可以有不同的设计方案

人机交互部分

数据接口部分

控制驱动部分

问题域部分

营业员

@营业员进程

营业员窗口«call»

«call»

方案1：无交叉

82

人机交互部分

数据接口部分

控制驱动部分

问题域部分

@营业员

营业员窗口

«call»

方案2：问题域部分和控制驱动部分交叉

83

人机交互部分

数据接口部分

控制驱动部分

问题域部分

营业员

«call»

方案3：问题域部分和人机交互部分交叉

@营业员进程

84

人机交互部分

数据接口部分

控制驱动部分

问题域部分

方案4：问题域部分、人机交互部分、控制驱动部分都交叉

@营业员

提问：还有没有其他方案？