面向对象软件工程详解-优快云博客

本文详细介绍了面向对象的基本概念，包括对象、类、实例、消息、方法和属性、继承、多态和重载，并对比了面向对象方法学与传统方法学的优缺点。接着，深入探讨了UML建模语言，包括用例图、类图、对象图、包、消息、顺序图、协作图、活动图等，并讲解了UML物理框架机制和扩展机制。最后，阐述了面向对象分析过程、设计准则和动态模型建立，强调了在设计过程中如何进行系统分解、任务管理和数据管理子系统的设计。

【考核内容】

面向对象的基本概念，面向对象的模型（用例图、类图、状态图、顺序图或事件跟踪图）的符号及其作用；面向对象设计框架；软件重用的概念与重用级别；面向对象编程、面向对象测试。

【考核要求】

（1）掌握面向对象的基本概念；

（2）掌握面向对象的软件工程方法；

（3）掌握对象模型的结构、对象模型的建立、动态模型的建立、功能模型的建立；

（4）掌握面向对象设计系统的基本框架；

（5）理解软件重用的概念与软件重用的内容；

（6）了解面向对象程序设计语言的特点。

一、面向对象的基本概念

传统软件工程方法学适用于中小型软件产品开发；

面向对象软件工程方法学适用于大型软件产品开发。

1. 面对对象方法学概念

1.1 对象

定义：具有相同状态的一组操作的集合，对状态和操作的封装。

1.2 类

对具有相同状态和相同操作的一组相似对象的定义。类是一个抽象数据类型。

1.3 实例

实例是由某个特定类所描述的一个具体对象。

1.4 消息

要求某对象执行某个操作的规格说明。

三部分：

接收消息的对象
消息名
0或多个变元

quadrilateral1.move(1,3)

1.5 方法和属性

方法
对象执行的操作，即类中定义的服务。
如：draw()，要给出实现代码。
属性
类中所定义数据，对客观世界实体具体性质的抽象。
如：Quadrilateral类中的point1、point2、point3point4。

1.6 继承

子类自动共享基类中定义的属性和方法的机制。

1.7 多态

在类等级不同层次可共享一个方法名，不同层次每个类按各自需要实现这个方法。

优点：

提高程序可复用性（接口设计的复用，不是代码实现复用）
派生类的功能可被基类指针引用，提高程序可扩充性和可维护性。

1.8 重载

函数重载
在同一作用域内，参数特征不同的函数可使用相同的名字。优点：
1. 程序易于阅读和理解。
2. 调用者不需记住功能雷同函数名，方便用户；
运算符重载
同一运算符可施加于不同类型操作数上面。
例：23+24 23.0+24.0

2. 与传统方法学比较

3. 面向对象方法学优点

与人类习惯思维方法一致
对象是对现实世界正确抽象，问题空间和解空间结构一致。
稳定性好
软件系统结构根据问题领域模型建立，功能需求变化不会引起软件结构整体变化，作局部性修改。如从已有类派生新子类实现功能扩充或修改。
可重用性好
传统软件重用技术：标准函数库。
面向对象重用技术：类，派生类和创建类的实例
易开发大型软件产品
封装性好，易于分解，易于合作开发。
可维护性好
稳定性好、容易修改、容易理解、易于测试和调试。

二、面向对象的模型

UML 全称为 Unified Modeling Language目前最流行的面向对象建模语言

1. UML简介

1.1 建模必要性

建模是捕获系统本质的过程.

建模必须使用，标准图形记法 --UML

捕获商业流程
促进沟通
管理复杂性
将模型划分成不同的视图（结构、行为等）;
用包（Package）将视图组织成一棵抽象层次渐深的树形结构.
定义软件构架
促进软件复用

1.2 UML发展

1.3 UML视图

1.用例视图

定义了系统的外部行为，是最终用户、分析人员和测试人员所关心。该视图定义了系统的需求，因此约束了描述系统设计和构造的某些方面的所有其他视图。

2.设计视图

描述的是支持用例视图中规定的功能需求的逻辑结构。它由程序组件的定义，主要是类、类所包含的数据、类的行为以及类之间交互的说明组成。

3.实现视图

描述构造系统的物理组件，这些组件包括如可执行文件、代码库和数据库等内容。这个视图中包含的信息与配置管理和系统集成这类活动有关。

4.进程视图

进程视图包括形成并发和同步机制的进程和线程。

5.部署视图

部署视图描述物理组件如何在系统运行的实际环境(如计算机网路)中分布

2. 用例图

用例图描述外部执行者（actor）与系统的交互，表达系统功能，即系统提供服务。

主要元素：用例和执行者。

用例：执行者与计算机一次典型交互，代表系统某一完整功能。

执行者:描述与系统交互的人或物，代表外部实体（如用户、硬件设备或其它软件系统）。

建立用例模型

2.1 发现执行者

谁使用该系统；
谁改变系统的数据；
谁从系统获取信息；
谁需要系统的支持以完成日常工作任务；
谁负责维护、管理并保持系统正常运行；
系统需要应付那些硬件设备；
系统需要和那些外部系统交互；
谁对系统运行产生的结果感兴趣

2.2 获取用例

向执行者提出问题获取用例：

执行者需获取何种功能，需要作什么；
执行者需读取、产生、删除、修改或存储
系统中某种信息；系统发生事件和执行者间是否需要通信。

2.3执行者间关联

泛化关系

2.4 用例间关联

泛化关系

一般与特殊关系

有父用例的行为，可出现在父用例出现的任何地方。添加自己行为（前者检查文本密码，后者检查用户视网膜）。

扩展关系

允许一个用例扩展另一用例提供的功能，与泛化关联类似，有更多规则限制：

基本UseCase必须声明若干“扩展点”，扩展UseCase只能在扩展点上增加新行为。

扩展用例指向基本用例

包含关系

一个基本UseCase行为包含另一个UseCase行为。

Check Credit检查输入的信用卡号是否有效，有足够资金。处理Purchase Ticket用例，总运行Check Credit用例

基本用例指向包含用例

3. 类图

类图是面向对象建模最常用的图，描述类与类间的静态关系。

3.1 类属性的语法

[可见性] 属性名[：类型][=初值]

可见性：公有（＋）、私有（－）、保护（#）

公有：可被外部对象访问
私有：不可为外部对象访问，只能为本类对象使用
保护：可为本类对象和子类对象访问。

3.2 类操作的语法

[可见性]操作名[（参数列表）] [：返回类型]

3.3 类的版型

（1）边界类

位于系统与外界的交界处

User interface boundary class
窗体（form）、对话框（dialog box）、报表（report）
External system boundary class
1. 表示通讯协议（如TCP/IP）的类
2. 直接与外部设备交互的类
3. 直接与外部系统交互的类

（2）控制类

每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。

（3）实体类

用于对必须存储的信息和相关行为建模的类。

（4）接口类

描述一个类或构件服务的操作集，不含属性，只包含方法的声明。

3.4 类之间关系

四种：关联、泛化（继承）、依赖、实现。

（1）关联关系

普通关联：双向，用实线连接两个类。

导航关联:关联是单向的，用实线箭头连接两个类。

限定关联:限定符放在关联关系末端的矩形内。

关联类：用关联类记录关联附加信息。

聚合（Aggregation）：

类与类间关系是"has-a"，整体与部分较弱关系情况。

菱形端代表整体事物类；代表部分事物类可属于整体事物类。

聚合关系中代表部分事物对象与代表聚合事物对象生存期无关，删除聚合对象不一定删除代表部分事物对象。

组合（Composition）:

组合是“contains-a”关系，是整体与部分较强关系，部分类完全隶属于整体类。

组合中删除组合对象，同时也就删除代表部分事物对象。

（2）泛化关系

指类间的“一般-特殊”关系。

由特殊类指向一般类

（3）依赖

一模型元素变化必影响另一模型元素。

（4）实现

指一个类描述了另一个类保证实现的合约。

系统设计视图中的类AccountBusinessRules（帐户商业规则）由接口类IRuleAgent（规则代理）实现。

4. 对象图

对象图表示一组对象之间联系，对象图是类图的实例。

类图和对象图是建立对象模型主要工具，用于各类系统：信息管理系统、数据库系统、Web应用系统、实时控制系统。

5. 包

UML中包是对模型元素成组组织的通用机制。

把语言相近，可能一起变更模型元素组织在包里，便于理解复杂系统。

包图由包和包间联系构成，包的联系：依赖、泛化。

包依赖：

一个元素定义改变引起另一元素发生相应改变，用虚线箭头表示包间依赖关系，虚箭线从依赖包指向独立包。

包泛化：

两个包间有一般特殊关系，实线箭头表示包间泛化关系。

6. 消息

对象间交互通过消息。　

7. 顺序图

顺序图（sequence diagram）描述对象间交互关系。

对象用矩形框表示，框内标对象名；

矩形框下的竖线代表对象的生命线；

对象生命线上的细长矩形框表示对象被激活；

对象间通信用对象间水平消息线表示，箭头形状表明消息类型（同步、异步或简单）。

8. 协作图

协作图（Collaboration diagram）描述相互协作对象间交互关系和链接关系。

顺序图着重表现交互时间顺序；

协作图着重表现交互对象的静态链接消息；

协作图显示对象间处理过程的分布。

9. 活动图

活动图（Activity diagram）描述为完成某一个用例需要做的活动以及这些活动的执行顺序。

活动图由状态图变化而来，各自用于不同目的。

状态图着重描述对象的状态变化以及触发状态变化的事件。

活动图着重描述各种活动的执行顺序。

三、UML物理框架机制

系统架构：逻辑架构；物理架构。

逻辑架构：

描述系统功能。

用例图、类图、对象图、状态图、活动图、协作图、顺序图。

物理框架：

关心的是实现。
类和对象物理上分布在那个程序或进程中；
程序进程在哪台计算机上运行；
系统有哪些硬件设备，如何连接。
构件图和配置图

1. 构件图

构件图（Component Diagrams）展现了一组构件的类型、内部结构和它们之间的依赖关系。

构件代表系统一物理实现块，一般作为一独立文件存在。

构件种类：

部署构件

是构成一可执行系统必要构件，如操作系统，Java虚拟机。

工作产品构件

开发过程产物，包括源代码文件及数据文件。构件不直接参与可执行系统，用来产生可执行系统的中间工作产品。

执行构件

构成一可执行系统必要构件，动态链接库、exe文件、CORBA构件、.net构件等。

2. 配置图

配置图（Deployment diagram）描述了系统硬件和软件物理配置情况和系统体系结构，显示系统运行时刻的结构。

配置图包含结点和连接两个元素，配置图中的结点代表实际的物理设备以及在该设备上运行的构件和对象，结点的图符是一个立方体。

配置图各结点之间进行交互的通信路径称为连接用结点间的连线表示。

四、UML扩展机制

利用扩展机制，用户可定义使用自己的模型元素。

1. 标签值

标签值是存储元素相关信息字符串，可附加在任何独立元素（图形元素、视图元素）。

标签是建模人员需要记录某些特性的名称；

值是给定特性的值。

标签值对项目管理特别有用，如元素创建日期

开发状态、完成日期和测试状态。

标签值用｛｝扩起。

2. 约束

约束是用文字表达式表达的语义限制，对声明全局的或影响大量元素的条件特别适用。

约束表示为括号中的表达式字符串，附加在类、对象、关系上和注释上等。

3. 版类

版类（版型）在模型本身中定义的一种模型元素，UML元素具有通用语义，利用版类进行专有化和扩展，在已有元素上增加新语义。

版类用放置在基本模型元素符号中或附近的被《》括起的文字串显示，还可为特殊版型创建图标，替换基本元素符号。

五、面向对象分析

1. 面向对象分析过程

1. 获取需求

与用户交谈，向用户提问题；
参观用户的工作流程，观察用户的操作；
向用户群体发调查问卷；
与同行、专家交谈，听取他们的意见；
分析已经存在的同类软件产品，提取需求；
从行业标准、规则中提取需求；
从Internet上搜查相关资料等。

2. 整理需求

书写需求陈述；

需求陈述内容包括问题范围，功能需求，性能需求，应用环境及假设条件。

3. 建立模型

抽取整理用户需求建立问题域精确模型。

面向对象分析模型由三个独立模型组成：

功能模型：
指明系统应“做什么”，由用例图表示。
对象模型：
描述静态结构, 定义做事情实体，类图和对象图表示。
动态模型：
描述交互过程, 由状态图和顺序图表示。

4. 书写需求规格说明书

5. 复审

2. 建立功能模型

功能模型用用例图表达，研究需求陈述建立用例图。

步骤：

1.识别外部执行者；

2.识别用例；

3.建立用例图；

4.补充用例描述：为建立对象模型和动态模型打基础。

例子：需求陈述

银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。

柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。

拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。

3. 建立对象模型

对象模型描述类及相互关系，表达目标系统静态结构。

建立对象模型步骤：

确定分析类；
确定类的关联；
划分主题；
确定属性；
识别继承；
反复修改。

3.1 确定分析类

分析模型中，分析类是概念层次上内容，类直接与应用逻辑相关，不关注技术实现。

找出候选分析类：①边界类；②控制类；③实体类。

确定边界类（操作界面）

通常，一参与者与一用例间交互或通信关联对应一边界类。

识别控制类（动词）

控制类负责协调边界类和实体类，通常在现实世界没有对应的事物。一般来说，一个用例对应一个控制类。

识别实体类（名词）

实体类通常是用例中的参与对象，对应着现实世界中“事物”

非正式分析法：

（1）需求陈述中名词。

例：用非正式分析法提取ATM系统中的实体类。

银行，自动取款机（ATM），系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问

ATM系统分析员根据领域知识或常识提取出隐含的类。通信链路、事务日志

（2）筛选出正确的类

① 冗余：储户与用户，现金兑换卡与磁卡及副本应去掉“用户”、“磁卡”、“副本”，保留“储户”和“现金兑换卡”。

② 无关：与本问题密切相关类放进目标系统，去掉“成本”、“市”“街道”、“营业厅”、“储蓄所”。

③ 笼统：银行（总行和分行）、系统、软件、信息、访问（事务）。

④ 属性：现金、支票、取款额、账单、余额、分行代码、卡号、密码和类型。

⑤ 操作：需求陈述中既作名词又作动词的词，慎重考虑是作类合适，还是作类中操作合适。

⑥ 实现：事务日志、通信链路。

ATM系统筛选后的类：银行，自动取款机（ATM），系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号用户，副本，信息，密码，类型，取款额，账单，访问

3.2 确定关联

（1）初步确定关联

① 直接提取动词短语

② 需求陈述中隐含的关联

③ 根据问题域知识得出的关联

（2）筛选

① 已删去类之间关联：删掉某候选类，与这个类有关的关联也删去，或重新表达。

② 与问题无关或与实现密切相关的关联删去。

③ 瞬时事件

④ 三元关联：三个或三个以上对象关联，可分解为二元关联或限定关联。

如：“柜员输入针对账户的事务”分解成“柜员输入事务”和“事务修改账户”。

（3）进一步完善

① 正名："分行提供分行计算机和柜员终端"改为"分行拥有分行计算机"和"分行拥有柜员终端"。

② 分解：把“事务”分解成“远程事务”和“柜员事务”。

③ 补充：需补充"柜员输入柜员事务"、"柜员事务输进柜员终端"、"在ATM上输入远程事务"和"远程事务由现金兑换卡授权"。

3.3 划分主题

3.4 确定属性

需求陈述中的名词

（1）误把类当属性

独立存在更重要，则应为类。

（2）误把链属性作为属性

属性要依赖某关联链存在，则为关联类的属性。

（3）误把限定当属性

属性值固定下来可减少重数，则应为限定。

（4）误把内部状态当属性

对象的非公开内部状态不作属性。

（5）过于细化

忽略对大多数操作都没有影响的属性。

（6）存在不一致属性

分解两个类。

3.5 识别继承

3.6 反复修改

（1）分解“现金兑换卡”类：现金兑换卡有两独立功能：标志储户访问账号的权限；含有分行代码和卡号的数据载体。（卡权限和现金兑换卡）

（2）“事务”由“更新”组成：更新包括取款、存款、查询。有自己属性（类型、金额），应独立存在。

（3）合并“分行”和“分行计算机”：同理合并总行和总行计算机。

4. 建立动态模型

开发交互式系统，动态模型非常重要。

步骤：

编写典型交互行为脚本
从脚本中提取事件及相关对象，用顺序图表达
确定对象状态及状态间转换关系，用状态图描绘

六、面向对象设计

分析：提取、整理用户需求，建立问题域精确模型。

设计：转变需求为系统实现方案，建立求解域模型。

1. 面向对象设计准则

在实际的软件开发过程中分析和设计的界限是模糊的。

分析和设计活动是一个多次反复迭代的过程。

面向对象方法学在概念和表示方法上的一致性，保证了在各项开发活动之间的平滑(无缝)过渡，领域专家和开发人员能够比较容易地跟踪整个系统开发过程，这是面向对象方法与传统方法比较起来所具有的一大优势。

1. 抽象

通过像类抽象机制实现

提高可重用性

2. 信息隐蔽

通过封装性实现

提高独立性

3. 弱耦合

对象间耦合：交互耦合、继承耦合

交互耦合：对象间通过消息连接实现。（松散）

-降低消息连接复杂度（减少参数个数，降低参数复杂度）

-减少信息数

继承耦合：一般类和特殊类之间耦合。（紧密）

有继承关系基类和派生类是系统中粒度更大模块。

4. 强内聚

服务内聚：只完成一个功能。

类内聚：一个类只有一个用途，否则分解。

一般特殊内聚：设计合理，是对领域知识正确抽取。

5. 可重性

-尽量利用已有类（类库、已创建类）

-创建新类考虑以后可重用性

2. 面向对象设计启发规则

1. 设计结果清晰易懂。

用词一致
使用已有协议
减少消息模式的数目
避免模糊的定义

2. 一般-特殊结构深度适当。

约100个classes，则设计7±2层

3. 设计简单class

避免过多attributes
分配给每个类任务应简单
objects间合作关系简单
避免过多methods（7个）

4. 使用简单的协议

经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。

5. 使用简单的服务

3. 系统分解

面向对象设计模型：四部分组成。

有些领域目标系统可只由3个或更少子系统组成。

问题域：直接负责实现客户需求子系统。
人机交互：实现用户界面子系统包括可复用的GUI子系统。
任务管理：确定各类任务，把任务分配给适当的硬件或软件去执行。
数据管理:负责对象的存储和检索的子系统。

子系统间交互方式：

客户－供应商关系：“客户”子系统了解“供应商”子系统接口反之则不用。

平等伙伴关系：各子系统都有可能调用其它子系统，或为其它子系统提供服务。

交互方式复杂，各子系统需要了解彼此接口。

4. 设计问题域子系统

设计基础: 分析阶段精确问题域模型。

设计任务 :从实现角度补充、修改问题域模型。

包括如下几个方面：

（1）调整需求

用户需求或外部环境变化；

分析模型不完整、准确。

无论出现上述哪种情况，通常都只需简单地修改面向对象分析结果，然后再把这些修改反映到问题域子系统中。

（2）重用已有类

根据问题解决的需要，把从类库或其他来源得到既存类增加到问题解决方案中去。

ATM系统分析模型，没把开发工具提供类包括在设计模型，增加了一个或几个主要的类。(TForm类)

（3）把问题域类组合在一起

设计时，从类库中引进一个根类，作为包容类，把所有与问题域有关的类关联到一起，建立类的层次。

（4）增加一般化类

某些特殊类要求一组类似的服务，应加入一般化的类，定义为所有特殊类共用的一组服务名，服务都是虚函数；在特殊类中定义其实现。

（5）调整继承关系

在OOA阶段建立的对象模型中可能包括多继承关系，但实现时使用程序设计语言可能只有单继承，需对分析结果修改。

例： ATM系统问题域子系统

划分成三个更小的子系统

ATM站子系统；中央计算机子系统；分行计算机子系统

ATM系统问题域子系统结构：

星型拓扑结构；以专用电话线连接

5. 设计人机交互子系统

分析阶段：用户界面需求

设计阶段：确定人机交互细节，窗口报表形式，命令层次等。

在有关界面设计的著作中，Theo Mandel创造三条黄金原则：

置用户于控制之下
减少用户的记忆负担
保持界面一致

允许用户操作控制的原则：

交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式
提供灵活的交互
允许用户交互可以被中断和撤销
当技能级别增长时可以使交互流水化并允许定制交互
使用户隔离内部技术细节

能够减少用户记忆负担：

减少对短期记忆的要求
建立有意义的缺省
定义直觉性的捷径
界面的视觉布局应该基于真实世界的隐喻
以不断进展的方式揭示信息

用户应以一致的方式展示和获取信息:

所有可视信息的组织均按照贯穿所有屏幕显示所保持的设计标准
输入机制被约束到有限的集合，在整个应用中被一致地使用
从任务到任务的导航机制被一致地定义和实现

Web界面设计

简洁性

避免使用许多复杂的图片和动画等造成用户操作的分心
界面布局应当适合清晰地表达信息
具有与之匹配的导航性

一致性

诸如同样的按钮在所有窗口中保持一致的位置、始终使用一致的配色方案等。

6. 设计任务管理子系统

在实际系统中，许多对象之间往往存在相互依赖关系。

设计工作的一项重要内容就是，确定哪些是必须同时动作的对象，哪些是相互排斥的对象。进一步设计任务管理子系统。

系统总有许多并发行为，需按照各自行为的协调和通信关系，划分各种任务（进程），简化并发行为的设计和编码。

确定各类任务，把任务分配给适当的硬件和软件去执行。

根据动态模型分析、定义并发行。

6.1 分析并发性

并发对象：

无交互行为的对象
同时接受事件的对象

定义任务：

检查各个对象的状态图，找没并发对象的路径（任何时候路径中只有单个对象是活跃的），称控制线。

通过分离出控制线设计任务。

并发任务的分配方案：

每个任务分配到独立的处理器
分配到相同处理器，通过操作系统提供并发支持

6.2 设计任务子系统

（1）事件驱动型

指睡眠任务（不占用cpu），某个事件发生，任务被触发，醒来做相应处理，又回到睡眠状态。

（2）时钟驱动型任务

按特定时间间隔去触发任务进行处理。如某些设备需要周期性的采集数据。

（3）确定优先任务

高优先级，分离成独立任务，保证时间约束。

（4）确定关键任务

严格可靠性，分离考虑，精心设计和编码，严格测试。

（5）确定协调任务

三个以上任务，引入协调任务，控制封装任务间协调。

（6）尽量减少任务数

任务多，设计复杂、不易理解、难维护

（7）确定资源需求

计算系统载荷，每秒处理业务数，处理一个业务花费时间，估算所需cpu（或其他固件）处理能力。

综合考虑，确定哪些任务硬件实现，哪些任务软件实现。

注：任务管理部件一般在信息系统中使用较少；在控制系统中应用较多。

7. 设计数据管理子系统

7.1 选择数据存储管理模式

（1）文件管理系统：

成本低，简单。
操作级别低，不同操作系统的文件系统差别大。

（2）关系数据库管理系统

（3）面向对象数据库管理系统

扩展的关系数据库管理系统：

增加抽象数据类型，继承等机制，如oracle8.0 。

扩展的面向对象语言：增加数据库存储和管理对象机制。

7.2 设计数据管理子系统

（1）设计数据格式

与数据存储管理模式密切相关：

文件系统：
达到第一范式；
减少文件数；
编码减少文件中属性值。
关系数据库管理系统：
达到第三范式，满足性能和存储需求。
面向对象数据库管理系统：同（2）。

范式

对表的数据结构进行规范，规范化的模式称为范式。

（2）设计相应服务

文件系统：
打开文件、记录定位、检索记录、更新。
关系数据库管理系统：
哪些由数据库管理系统承担，哪些由前端开发工具承担；访问哪些库表、定位记录、更新等。
面向对象数据库管理系统：同（2）。

8. 面向对象程序设计风格

8.1 面向对象实现

把面向对象设计结果翻译成面向对象程序

测试并调试面向对象的程序

8.2 程序设计语言

所有语言都可完成面向对象实现，但效果不同。

使用非面向对象语言编写面向对象程序，则必须由程序员自己把面向对象概念映射到目标程序中。

选用面向对象语言的优点。

将来能够占主导地位
产品有生命力
可重用性
类库和开发环境
考虑类库中提供有价值类
开发环境中提供基本软件工具和类库编辑工具及浏览工具
其他因素
培训服务；技术支持；开发工具、开发平台、发行平台；对机器性能和内存需求；集成已有软件容易程度

8.3 程序设计风格

提高可重用性
提高可扩充性
提高健壮性

提高可重用性

提高方法的内聚
方法只完成单个功能。涉及多个不相关功能，分解。
减小方法的规模
方法规模过大，分解。
保持方法的一致性
功能相似方法有一致名字、参数特征（包括参数个数、类型和次序）、返回值类型、使用条件及出错条件等。
把策略与实现分开
负责做出决策，提供变元，管理全局资源，称策略方法。
负责完成具体操作，称实现方法。
实现方法相对独立，可在其它系统中重用，将二者分开。
全面覆盖应
针对所有组合写方法。
当前应用需要：获取表中第一元素
提高可重用写：获取表中最后一元素
处理正常值
对空值、极限值、界外值做出响应
尽量不用全局信息
降低方法与外界耦合程度。
利用继承机制
实现共享和提高重用程度的主要途径。
1. 调用子过程
  把公共代码分离出来，构成一个公用方法。
2. 分解因子
  从不同类相似方法分解出不同的代码，余下作为公用方法中公共代码。把分解出的因子作为名字相同算法不同的方法，在不同类中定义。
3. 使用委托
4. 代码封装在类中
  把被重用的代码封装在类中。

提高可扩充性

封装实现策略
应把类的实现策略（包括数据结构、算法等）封装起来，对外提供公有接口。
不要用一个方法遍历多条关联链
一个方法应只包含对象模型中有限内容。否则导致方法过分复杂，不易理解和修改扩充。
避免使用多分支语句
增添新类时会修改原有的代码。合理利用多态性机制。
精心确定公有方法
公有方法是向公众公布的接口。

提高健壮性

预防用户操作错误
任何输入（错误），给出提示信息，再次接收用户输入。
检查参数合法性
不预先确定限制条件
使用动态内存分配机制，创建未预先设定限制条件数据结构。
先测试后优化

9. 面向对象测试

9.1 测试策略

单元测试
单元：封装的类和对象
对程序内部具体单一功能模块测试，如程序用C++实现，主要对类成员函数测试。
传统的测试方法都可使用，等价类划分、边值分析、逻辑覆盖法、基本路径法。
集成测试
在面向对象的软件中不存在层次的控制结构，传统的自顶向下或自底向上的集成策略就没有意义了。
此外，由于构成类的各个成分彼此间存在直接或间接的交互，一次集成一个操作到类中（传统的渐增式集成方法）通常是不现实的。
面向对象软件的集成测试主要有下述两种不同的策略。
1. 基于线程的集成测试：
  把响应系统的一个输入或一个事件所需类集成起来。
2. 基于使用的集成测试：
  先测独立类，测完后测独立类下一层类（依赖类），到测完。
确认测试
测用户可见动作，可识别系统输出。
根据动态模型和描述系统行为的脚本设计确认测试用例。黑盒法

9.2 测试类的方法

测试单个类的方法主要有随机测试、划分测试和基于故障的测试等3种。

（1）随机测试

在类的多个操作排列中，随机选择。

银行应用系统的account（账户）类操作：open（打开）、setup、deposit（存款）、withdraw（取款）、balance（余额）、summarize（清单）、creditLimit（透支限额）和close（关闭）一个account类实例的最小行为历史包括下列操作： open·setup·deposit·withdraw·close

这就是对account类的最小测试序列。

（2）划分测试（类似等价类划分）

基于状态的划分
根据改变类状态能力划分：改变类状态；不改变类状态。
例：设计测试用例：
open.setup.deposit.withdraw.withdraw.close
open.setup.deposit.summarize.creditLimit. Withdraw.close
基于属性的划分
根据类操作属性：使用该属性；修改属性；不操作该属性。
例：account类可根据balance属性把操作定义划分三个类别:
使用balance的操作
修改balance的操作
不使用也不修改balance的操为
上述每个类别设计测试序列
基于功能的划分
根据类操作完成功能：
初始化操作(open、setup)；
计算操作（deposit、withdraw）；
查询操作（balance、summarize、creditLimit）；
终止操作（close）