软件是能够完成预定功能和性能的可执行的计算机程序，包括是程序正常执行所需的数据，以及有关描述程序操作和使用的文档。

简言之，软件=程序+文档

程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列。 文档是软件活动开发的记录。

2.软件的特征

（1）软件是一种逻辑实体，不是具体的物理实体

（2）软件产品的生产主要是研制

（3）软件具有复杂性其开发和运行常受到计算机系统的，有些软件甚至依赖于硬件的配置

（4）软件成本昂贵，其开发方式目前尚未摆脱手工生产方式

（5）软件不存在磨损和老化问题，但存在退化问题

（6）软件通常针对特定的应用而设计，需要大量的时间精力

3.软件危机

软件危机的定义：计算机软件的开发和维护过程中所遇到的一系列严重问题

软件危机的表现：

（1）对软件开发成本和进度的估算很不准确

（2）用户很不满意

（3）质量不靠谱

（4）没有适当的文档

（5）软件成本比重上升

（6）供不应求：软件开发生产率跟不上计算机应用迅速深入的趋势

软件危机产生的原因：

客观原因：软件本身的特点：逻辑部件，规模庞大，维护费用急剧上升，生产技术进步缓慢

软件维护费用急剧上升，直接威胁计算机应用的扩大

①.软件生产技术进步缓慢，是加剧软件危机的重要原因

②. 主观原因：不正确的开发方式：忽视需求分析，错误认为软件开发=程序编写，轻视软件维护

1.1 绪论

2014年3月25日

21:31

分区第一章的第1 页

2014年3月25日

21:57

中心思想是把软件当作是一种工业产品，要求“要求工程化的原理和方法对软件进行计划、开发和维护”

软件工具：帮助开发软件的软件

方法与工具相结合，再加上配套的软、硬件支持就形成环境

分区第一章的第2 页

3种编程范式

1.遵循“程序=数据结构+算法”的思路，把程序理解为由一组被动的数据和一组能动的过程所构成。

(1)过程式编程范型

(2)面向对象编程范型

程序=对象+消息

(3)基于构件技术的编程范型

构件可以理解为标准化（或者规范化）的对象类

(4) 3种编程范式的比较

过程式编程范型：着眼于程序的过程和基本的控制结构，粒度最小

面向对象编程范型：着眼于程序中的对象，粒度比较大

基于构件的编程范型：着眼于适合整个领域的类对象，粒度更大

1.3 软件工程的发展

2014年3月25日

22:01

分区第一章的第3 页

一个软件从开始立项起，到废弃不用为止，统称为软件生存周期（life cycle ）。 软件生存周期一般被划分为计划、开发、运行3个周期。

软件生存周期的主要活动：

1.需求分析 确需要解决的问题（从用户的 度） 立需求模型：功能、性能、环境 、 部接 描述

2.软件分析 从开发 的视 对软件的需求模型进行分析（在系统需求模型基 上） 立分析模型：软件系统逻辑模型的描述

3.软件设计 确立软件的 体结构和 部件的数据结构和操作 立软件设计模型 实现技术和

4.编码 用程序设计语言 设计文档 成 程序 立软件实现模型：包括软件现有的软件包

5.软件测试 发现程序中的错误， 软件质量 测试、 成测试

6.运行维护

作为生存周期最后一个阶段，运行维护阶段的任务主要是做好软件维护，使软件在整个生存周期内都可以满足用户的需求，并延长其使用寿命。

运行周期与软件过程的关系

1.从软件生存周期到过程模型

软件过程可理解为围绕软件开发所进行的一系列活动。

软件开发模型包含的阶段与活动同软件周期划分的阶段与活动基本上是一致的。2.软件过程的演变

2.1 软件生存周期

2014年3月25日

22:13

分区第二章的第4 页

2014年5月9日

22:06

1.瀑布模型

瀑布开发模型是一种基于软件生存周期的线性开发模型。

瀑布模型的特点：

1.阶段间的顺序性和依赖性

包含两层含义：

第一、顺序性：只有 前一阶段的工作完成之后，后一阶段的工作才能开始。

第二、依赖性：前一阶段的输出文档是后一阶段的输入文档。

2.推迟实现的观点

推迟实现就是把待开发软件的逻辑设计与物理实现清楚地区别开来，即在需求分析和软件设计阶段只 系统的逻辑模型， 到编码阶段再来完成程序清 。

3.保证质量的观点

第一、每一阶段必须完成规定的文档。没有完成文档，就不能视为完成该阶段的任务。

第二、每一阶段都要对完成的文档进行复审，以便尽早发现问题，消除隐患。

4.存在的问题

一、不适合需求模糊的系统

二、开发初始阶段很难彻底弄清软件需求

2.快速原型模型

1.原型开发的优越性

快速原型模型的中心思想是：先 立一个能够反映用户需求的模型，让用户实际看一下未来系统的概貌，以便判断哪些功能是符合需要的，哪些方面还需要改进。然后 原型反复改进，直至 立完全符合用户要求的新系统。

2.原型开发方法

首先，原型系统只包括未来系统的主要功能及其系统的重要接 。它不包括系统的细节，对系统的性能需求可推迟 。

其次，为了尽快向用户 供原型，开发原型系统时应尽量使用缩短开发周期的语言和工具。

最后，把原型作为基 ，通过补充和修改获得最终的实际系统。

3.原型模型的启示

原型开发模型改变了“把生存周期 同于过程模型”的习惯性思维，使 们意识到：生存周期只指出了整个周期中应包含哪些活动，并未规定这些活动应该发生多少次。所以软件开发 的任务，就是通过对软件过程的重新安排，使之更适合于待开发的软件系统

4.应该防止的偏向

采用原型法应防止两种偏向：一种可能来自用户，他们舍不得 “活生生”的原型废弃不用，要求开发者仅作“少量修改”就交付使用；另一种常常来自开发者，当他们熟悉原型后， 知它有许多不足，却不愿全部推倒重来，宁可在最终系统保留一部分不理想的程序。

分区第二章的第5 页

2.3.1 增量模型

增量模型是瀑布模型的顺序特征与快速原型法的迭代特征相结合的产物。这种模型把软件看做一系列相互联系的增量，在开发过程的 次迭代中，每次完成其中的一个增量。

1.典型的迭代模型

计划

①.风险分析

②. 立原型

③.用户评审

④.2.3.2 螺旋增量

1.面向对象的基本概念

面向对象=对象+分类+继承+消息通信

2. 什么是构件

对象技术 事物封装成包含数据和加工该数据的方法的对象，并抽象成为类。经过适当设计和实现的类，也称为构件。它们在某个领域中具有一定的通用性，可以在不同的计算机软件系统中服用。 这些构件存储起来构成一个构件库。

3.构件 成模型的特征

构件 成模型利用预先封装好的构件来构造应用软件。他它融合螺旋模型的不少特征，也支持软件开发的迭代方法。开发活动从描述候选类开始，通过检查软件系统处理的数据以及操作这些数据的方法，把相关的数据和方法封装成一个类，然后到构件库中查找这个实现它，并把它添加到构件库中。这样，通过 成从构件库中 取的已有类和为了满足应用程序的特定需要而构件的新类，即可得到待开发软件的第一个迭代。然后进入下一轮螺旋周期，继续进行构件 成的迭代。2.3.3 构件 成模型

2.3 软件演化模型

2014年5月28日

14:34

分区第二章的第6 页

2.4 形式化方法模型

2014年5月28日

14:56

2.4.1 转换模型

转换模型是 形式化软件开发和程序自动生成技术相结合的一种软件开发模型。

采用严格的数学方法来表示软件需求规格说 书，然后进行一些列自动或半自动的程序变换，最终 需求规格说 书转换为计算机系统能够接受的目标程序系统。

1.装换模型的软件开发过程

（1）确定形式化的需求规格说 书

（2）进行自动的程序变换

（3）对形式化开发记录进行测试

2.4.2 净室模型

净室模型是一种形式化的增量开发模型。基本思想是力求在分析和设计阶段就消除错误，在无缺陷或“洁净”的状态下实现软件的制作。

结构化分析与设计最初是由结构化程序设计扩展而来的。

结构化设计和结构化分析合称为结构化分析与设计方法。它是第一代软件工程时期最有代表性的应用系统开发方法

基本任务与指导思想

立分析模型

①.编写需求规格说 书（SRS ）

②.主要指导思想：抽象和分解

③.3.1.1 结构化分析与设计的由来

软件设计= 体设计+详细设计

①.SC 图需分两步完成：首先通过“映射”获得初始SC 图；然后通过“优

化”获得最终SC 图

②.软件设计的指导思想。在软件开发的所有阶段中，软件设计是最富有

活力、最需要发挥创造力的阶段

③.分解和细化，历来是重要的软件设计策略。细化是与抽象相反而又互补的一对概念。

细化的实质就是分解。

结构化设计

3.1 概述

2014年5月28日

15:07

4.1.1 对象和类

对象代表客观世界中世纪存在或抽象的食物。

一方面：客观世界是由 种对象组成的

另一方面：对象可定义为数据以及在其上的操作的封装体。 类是一组相似的对象的共性抽象

类的含义：第一，类是一组客观对象的抽象；第二，类是一种 供具有特定功能的模块和一种代码共享的手段或工具，即类是实现抽象数据类型的工具

类与对象的关系，可看成是抽象与具体的关系。组成类的每个对象都是该类的实例；实例是类的具体事物，类是 个实例的综合抽象。

4.1.2 面向对象的基本特征

1.抽象

抽象常用于在某个重要的或想要关注的侧面来表示某个物体或概念。它忽略主题中与当前目标无关的因素

2.封装

封装可用于把操作和数据包围起来，对数据的访问只通过已定义的接 来完成。

3.继承

定义一个新类，可以从现有的类中派生处理；子类可以从它的父类继承方法和属性，继承可在类之间 立“is a ”或“is like ”的关系

4.多态

不同对象之间可以对同一消息作出响应，执行不同的处理，这称为多态

4.1.3面向对象开发的优点

软件系统的可复用性

1. 软件系统的可扩展性

2. 软件系统的可维护性

3.面向对象符合 类习惯的思维方式。这种开发方法主要具有的优点：

4.1面向对象概述

2014年6月4日

22:22

4.2.1UML 的组成

UML 是一种基于面向对象的可视化 模语言。它 供了丰富的以图形符号表示的模型 素，这些标准的图形符号隐含了UML 的语法，而由这些图形符号组成的 种模型则是给出了UML 的语义

1.UML 的模型 素

关联：模型 素实例之间的固定对应关系，为永久性的结构关系①.泛化：表示一般与特殊关系

②.依赖：表示 素以某种方式依赖于另一个 素，为短暂性关系③.实现：表示接 和实现它的模型 素之间的关系

④.聚 ：表示“整体”和“部分”的关系

⑤.组合：表示强烈的“整体”与“部分”关系

⑥. UML 定义了两类模型 素。一类模型 素用于表示模型中某个概念；另一类用于表示模型 素之间的关联关系。其中主要有关联、泛化、依赖、实现、聚 和组合 。

2.UML 的 模型结构

下一层是上一层的基 ，上一层是下一层的实例

（1） 模型

模型定义了用于描述 模型的语言，它是任何模型的基 ，“事物”可以代表任何可定义的东西

（2） 模型

模型定义了用于描述模型的语言，它组成了UML 得基本 素，包括面向对象和构件的概念。 模型是 模型的一个实例

（3）模型

模型定义了用于描述信息领域的语言，它组成UML 的模型

（4）用户模型

用户模型是模型的实例，它用于表达一个模型的特定情况。

3.图和视图

UML 是用来描述模型的，它用模型来描述系统的结构和静态特征以及行为或动态特征。它从不同的视 为系统 模，形成不同的视图。每个视图由一组图构成，图中包含了强调系统中某一方的信息，显示了这个系统中一个特定的方面

静态图

①.共有5种，包括用例图、类图、对象图、构件图和部署图。

用例图描述系统功能；类图描述系统的静态结构；对象图描述系统在某个时刻地静态结构；构件图描述实现系统的 素的组织；部署图描述系统环境 素的配置，亦可称为配置图

动态图

②.（1）图

4.2UML 简介

2014年6月4日

22:42

②.

状态图用于描述系统 素的状态条件和响应；

时序图按时间顺序描述系统 素间的交互；

协作图按照连接关系描述 素间的交互

活动图描述系统 素的活动流程。

（2）视图

用例视图：表达从用户 度看到的系统应有的 部功能

①.

②.

逻辑视图：主要用类图和对象图来描述系统的静态结构

③.

进程视图：用于展示系统的动态行为及其并发性

构 视图：展示系统实现的结构和行为特征

④.

部署视图：显示系统的实现环境和构件被部署到物理结构中的映射⑤.

4.2.2 UML的特点

统一标准

1.

面向对象

2.

表达能力强大，可视化

3.

4.2.3UML应用

主要作用：

通过对问题进行说 和可视化描述，帮助理解问题，并 立文档①.

②.

获取和交流有关应用问题求解的知识

③.

对解决方案进行说 和可视化描述，辅助构 系统，并 立文档

采用面向对象技术开发系统时：

第一步，描述需求

第二步，根据需求 立系统的静态模型，以构造系统的结构

第三步，描述系统的行为

不同的测试小组使用不同的UML图作为测试依据： 测试使用类图和类规格说 ； 成测试使用构件图和协作图；系统测试按照用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。

4.3静态 模

2014年6月5日

6:42

UML静态 模机制包括用例图、类图和对象图。

4.3.1用例图与用例模型

用例模型用于把应满足用户需求的基本功能聚合起来表示。对于待开发的新系统，用例描述系统应该做什么；对于已构造完毕的系统，用例反映系统能完成什么样的功能。

用例模型由一组用例图组成，其基本组成部件是用例、参与者和系统。用例图可描述软件系统和 部参与者之间的交互。

1.组成符号

2. 立用例图

3.用例之间的关系

（1）扩展关系

根据指定的条件，一个用例中有可能加入另一个用例的动作，这两个用例之间的关系就是扩展关系。

（2）包含关系

当一个用例的行为包含另一个用例的行为时，这两个用例之间就构成了包含关系。

4.3.2类图和对象图

1.类图和对象图

类描述同类对象的属性和行为。类图可表示类（包括类名、类的属性和操作）和类之间的关系。

UML规定的类属性的语法为：

可见性属性名：类型=默认值{ 条件}

对象是类的实例。对象之间的链是类之间的关联的实例。对象图常用于表示复杂的类图的一个实例

2.关联关系

关联表示两个类之间存在的某种语义上的联系，即与该关联连接的类在对象之间的语义连接（称为链接）

（1）普通关联

（2）递归关联

一个类与自身关联，这称为递归关联

（3）多重关联

多重关联是指两个以上的类之间互相关联

（4）有序关联

在重数为“多”的关联端的对象必须是有序的则可在关联的“多”端上写上“{ordered}”来指

端上写上“{ordered}”来指

（5）关联

关联用于一对多或多对多的关联。用一个称为子的小方块；来区分关联“多”端的对象的 合，指 “多”端的某个特殊对象，它 模型中一对多的关系简化为一对一， 多对多简化为多对一。

（6）或关联

（7）关联类

当两个类之间的关联重数是多对多时，可以把该关联定义成关联类。

3.聚 关系

一般表示类之间具有整体与部分之间的关系，聚 表示为空心菱形，组合表示为实心菱形。

（1）聚

特征：“部分”对象可以是多个任意“整体”对象的一部分。

（2）组合

4.泛化

泛化也称为继承。

一般 素所具有的关联、属性和操作，特殊 素也都隐含性地具有①.特殊 素应包含额 信息

②.允许使用特殊 素实例的地方，也应能使用一般 素

③. UML 对泛化的要求：

（1）一般泛化

用一个附加标记值“{abstract}”来表示

（2）泛化

多重继承指的是子类可以同时继承多个上一级子类

①.不相交继承，即一个子类不能同时继承多个上一级子类

②.完全继承是指父类的所有子类都被穷举完毕

③.不完全继承

④. 泛化是指在泛化关系上附加一个 条件，以便进一步说 泛化关系的使用方法或扩充方法。预定义的 有4种：多重、不相交、完全和不完全（也称非完全）

5.依赖

假设有两个 素X,Y ，如果修改X 的定义可能会引起对Y 的定义的修改，则称 素Y 依赖于 素X 。

依赖关系的图形表示为带箭头的虚线，箭头指向的类，箭头旁边，具体说 依赖的种类

6.派生与

派生用于描述某种事物的产生规律

和派生机制能应用于任何模型 素。 和派生一般用花括号括起来放在模型 素旁边，或者用圆括号括起来以注释的方式与模型 素相连

通常在派生属性的=前面加一个“/”表示，但不出现在类的对象中。 如果一个关联是另一个关联的子 ，则它们之间就有 关联

一些模型 素组织成语义上相关的组的分组机制称为包

包与包之间可以由一下关系，允许的关系有：依赖和泛化

用于描述系统中的对象在执行期间的不同时间点的如何进行行动动态交互的。

4.4.1消息

简 消息：表示简 的控制流

①.同步消息：表示嵌套的控制流

②.异步消息：表示异步控制流

③. 对象之间的交互通过对象间的消息传递来完成

4.4.2状态图

状态图用来描述一个特定对象之间的所有可能状态以及引起其状态转移的事件。

1.状态

用3个标准事件entry,exit 和do 分别说 在进入状态、退出状态和处于进入/退出状态中间时需执行的动作。

活动的表示格式：事件名 参数表 / 动作表达式

2.状态转移

对象从一种状态改变成另一种状态称为状态转移，在状态图中用带箭头的连线表示。状态的变迁通常是由事件触发的，应在转移上标出触发转移的事件表达式；状态转移的表示格式为：

事件说 [守卫条件] / 动作表达式 ^ 发送子句

3.事件

事件是指已发生的且可能触发某些活动的事情。

条件变真

①.收到另一个对象的信号

②.收到另一个对象（或对象本身）的操作调用

③.经过指定的时间间隔

④.UML 中4类事件：

4.4.3 时序图和协作图

1.时序图

时序图用来描述对象之间的动态交互，着重体现对象间消息传递的时间顺序。以垂直轴表示不同的对象。对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。

2.协作图

协作图用于描述相互协作的对象之间的交互和链接。着重体现交互的时间顺序，而协作图则着重体现交互对象之间的静态链接

（1）链接

（2）消息流

4.4 动态 模

2014年6月5日

7:55

在协作图的链接上，可以用带有消息串的消息来描述对象间的交互4.4.4活动图

活动图显示动作流程及其结果，它既可用来描述操作（类的方法）的行为，也可描述用例和对象内部的工作过程。

1.活动转移

2.泳道

泳道的作用是 活动图的逻辑描述与顺序图、协作图的责任描述结合在一起。

3，对象

4.信号

4.5.1 物理架构

物理架构详细描述系统的软件和硬件。说 实现逻辑架构中定义的概念所对应的代码模块的物理结构和相关性，以及软件运行时，进程、程序和其他构件的分布情况。

4.5.2 构件图和部署图

构件图

①.部署图。部署图描述系统硬件的物理拓扑结构以及在此结构上执行

的软件。显示计算结点的拓扑结构和通信路径、节点上运行的软件构件、软件构件包含的逻辑 （对象、类） 。部署图常常用于帮助理解分布式系统。

②.结点和连接

③.节点之间的连线表示系统之间进行交互的通信路径，在UML 中被称为连接。通信类型放在连接旁边的“<<>>”之间，表示所用的通信协议或网络类型。

构件和接 接 可表示为一端是小圆圈的直线

④.对象

⑤. 构件图和部署图显示系统实现时的一些特性，包括 代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构，描述 代码的依赖关系。

4.5 物理架构 模

2014年6月5日

8:18

5.1.1 软件需求的定义

软件需求主要是指一个软件系统必须遵循的条件或具备的能力。理解：

一是用户解决问题或达到目标所需的条件或能力，即系统的 部行为 二是系统为了满足合同、规划或其他规定文档所具有的条件或能力，即系统的内部特性

软件需求一般包括3个不同的层次：业务需求、用户需求和功能需求 第一个层次是业务需求

第二个层次是用户需求

第三个层次是功能需求

功能性

1.可用性

2.可靠性

3.性能

4.可支持性

5.设计

6.5.1.2 需求工程的特性

5.1.3 需求工程的由来

软件需求工程是一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其 部行为特征的学科。通过合适的工具和记号，系统地描述待开发系统及其行为特征的和相关 ，形成需求文档，并能对不断变化的需求演进给予支持。

软甲需求工程是一门分析、记录并维护软件需求的学科，它把系统需求分解成若干子系统和任务，再把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发 过程，把这些系统需求转换成软件的需求描述和性能参数。

5.1 软件需求工程

2014年6月4日

21:08

需求工程是软件工程的一个子领域，贯穿与软件整个生命周期的始终。需求分析通过指软件开发的第一项活动，而该项活动的目的主要是为待开发的软件系统进行需求定义与分析，并 立一个需求模型。

5.2.1 需求分析的步骤

软件需求分析一般包括4个步骤：需求获取、需求 模、需求描述（即编写SRS ）和需求验证、

1.需求获取

需求获取通常从分析当前系统包含的数据开始。

2.需求 模

需求分析的主要任务是 立需求模型。图形化的模型是可视化地说 软件需求的最好手段，常用的模型包括用例图、数据流图、实体联系图、控制流图和状态装欢图 。

3.需求描述

需求描述即编写软件需求规格说 书（SRS ），必须用统一格式的文档进行描述。

指 需求的来 或业务规范、法规，标准或其他 部来 。①.为每项需求注入标号，以便进行跟踪；记录需求的变更，并为需求状

态及其变更活动 立度量

②. 为使所有相关 白SRS 为何要 出这些功能需求，在编写SRS 时应该：

4.需求验证

5.2 需求分析与 模

2014年6月4日

21:27

5.4.1 需求模型概述

1.结构化需求模型

该模型主要由3部分组成：包括数据流图和加工规格说 的功能模型：主要由数据字典和E-R 图 组成的数据模型：由状态转换图、控制流图和控制规格说 组成的行为模型。

2.面向对象需求模型

采用面向对象的思想进行软件需求 模，就可得到面向对象的需求模型。

面向对象需求模型由3个部分组成：用例模型、补充规 和术语表，其中用例模型又包括用例图和用例规 。

用例图主要用于显示软件系统的功能，它包括用例和参与者两方面的内容。在 立用例模型前，首先要确定系统 部的参与者，然后针对每个参与者确定系统的用例，其实质是看 个参与者需要系统 供什么样的服务。一个全面的用例不仅可以显示软件系统的所有功能，而且能逐一表 这些功能与 部参与者的对应关系。用例图下方的用例规 是对软件系统中的每个功能的具体描述。

5.4.2 面向对象的需求 模

1.画用例图

（1）确定参与者

参与者泛指所有在于系统 部并与系统进行交互的 、硬件或其他系统。

（2）确定用例

主要 察参与者需要系统 供什么样的服务

第一步，确定参与者

第二步，确定用例。确定用例时解决的问题之一是用例描述的详细程度，即用例要多大（或多小）才合适。通常规定：用例应该典型地描绘系统功能中某个从开始到结 的过程，并且给参与者 供某些信息。

（3）绘制和检查用例图

2.写用例规

用例模型是由用例图和用例规 组成的。

简要说 ：简要介绍该用例的作用和目的

•事件流：包括基本流和备选流，表示出所有可能的活动及流程•特殊需求：描述与该用例相关的非功能性需求和设计

•前置条件结合后置条件

•简要说 主要用文本方式表述

①.基本流。基本流是指该用例最正常的一种场景。在基本流中，系统执

行一系列活动来响应参与者 出的服务请求。

②.（1）用例规 的内容

5.4 需求模型

2014年6月4日

21:42

③.

备选流

④.

特殊需求。特殊需求的例子：法律或法规方面的需求、应用程序标准和所构 系统的质量属性。

前置和后置条件。前置条件是执行用例之前必须存在的系统状态，后⑤.

置条件是用例执行完毕后系统可能出处于的一组状态。

3.描述补充规

4.编写术语表

5.调整用例模型软件需求规格说 书（SRS）是软件开发 在分析阶段需要完成的用于描述需求的文档。

6.1.1 面向对象软件分析

1.OOA 的主要任务

理解用户的需求，包括全面理解和分析用户需求， 确所开发的软件系统的职责，形成文件并规范地加以表述

进行分析， 取类和对象，并结合分析进行 模。基本步骤是：标识类，定义属性和方法；刻画类的层次；表示对象以及对象之间的关系；为对象的行为 模。

2.OOA 的模型

3.OOA 所谓优点

同时加强了对问题空间和软件系统的理解

①.改进包括用户在内的与软件分析有关的 类 之间的交流②.对需求的变化具有较强的适应性

③.很好地支持软件复用

④.确保从需求模型到设计模型的一致性

⑤.与传统的软件分析方法相比较，面向对象分析具有的优点：

4.分析模型的一般特点

分析模型是一类概念模型，具有的内容和特点：

第一，全面覆盖软件的功能需求

第二，分析模型与软件的实现无关

第三，分析模型的表述方法与所采用的分析技术有关

6.1.2 面向对象分析模型

立类/对象层。定义类和对象

①. 立属性层。定义属性，为类/对象层中抽取出来的 个类和对象设

计静态属性和它们之间的关系

②. 立服务层。定义对象和类的动态属性以及对象之间的消息通信③. 立结构层。定义对象和类之间的层次结构关系，常见的关系有包含

关系、继承关系和关联关系

④. 立主题层。定义若干个主题，把有关的对象分别划归不同的主题，

每个主题构成一个子系统

⑤.1.典型的五层模型

用例模型是面向分析最常采用的一种模型。

以用例模型为主体的需求模型，是以模型中的每个用例为研究对象的，不需要 实现的细节。通常把这样从用例开始的分析过程称为用例分析，在这一阶段定义的类型称为分析类。

用例分析的步骤：

首先回顾需求阶段产生的用例规 ，补充必要的详细信息；然后研究用例的事件流， 用例职责分配给若干分析类；基于这些职责分配以及分析类之间的协作，即可开始为分析类间的关系 模了。分析了用例以后，需要察看所确定的类，确保它们被详尽地描述，并确保分析模型 个部分之间的一致。

6.2.1 识别与确定分析类

1.分析类的类型

（1）边界类

边界类 供了对参与者或 部系统交互协议的接 ，边界类 系统和 界的变化隔开，使 部环境的变化不会直接影响系统内部 素。用户界面类：用于和系统用户进行通信、

①.系统接 类：用于和其他软件系统进行通信

②.设备接 类：

③. 一个系统可能有多种边界类：

边界类对系统中依赖与环境的那些部分进行 模。实体类和控制类对可与系统 部环境无关的那部分进行 模。

（2）控制类

控制类用于封装一个或几个用例所特有的流程控制行为，通过它可 立系统的动态行为模型。

边界类和实体类之间并非始终需要一个控制类，只有当用例的事件流比较复杂并具有可以于系统的接 （边界类）或者存储信息（实体类）的动态行为时，才需要控制类。

（3）实体类

实体类用于对必须存储的信息和相关的行为 模，其主要职责是存储和管理系统中的信息。它通常具有持久性，即它们的属性和关系需要长期保存，有时甚至在系统整个生存周期都存在。

为每对参与者/用例确定一个边界类

①.为每个用例设置一个控制类

②.确定相关的 个实体（包括属性与方法）

③.2.查找分析类

6.2.2 立对象-行为模型

1.时序图

时序图按时间顺序描述系统 素之间的交互。首先，在时序图中加入6.2 面向对象分析 模

2014年6月4日

17:02

时序图按时间顺序描述系统 素之间的交互。首先，在时序图中加入触发这个用例的参与者，然后加入边界类对象，接着加入控制类对象，最后是实体类对象。

2.协作图

协作图按照时间和空间的顺序描述系统 素之间的交互即相互关系。

3.为分析类分配职责

动态图 用例所要求的行为分派到分析类的过程，从软件需求过渡到OOD设计的重要环节。核心概念是消息合职责的对应关系。

4.状态图

针对一个类的状态变化，研究该类的动态行为。

6.2.3 立对象-关系模型

1.分析类的属性

分析类的属性即分析类本身具有的信息。类可以用属性来存储信息2.分析类的关联

分析类具有指向其他分析类的关联，通过关联能够找到其他分析类。

在协作图中，对象之间的链接是相应分析类之间存在关联关系的动态表现形式。它表 两个类的对象需要互相交流，以便执行用例的行为

3.分析类图

分析类图用于表现分析类及其关系，描述某个用例的分析类图称为参与类图

4.分析类的合并

每个分析类都代表一个 确定义的概念，具有不重叠的职责。把具有相似行为的类合并为一个。

7.1软件设计概述

2014年6月3日

14:48

面向对象设计的任务是 分析阶段 立的分析模型转变为软件设计模型。

OOD方法是在基于抽象、信息屏蔽、功能和模块化 重要的软件设计概念的基 上进行的，不过它的模块化不仅仅局限在过程处理部分，而是通过 数据和对数据的操作封装在一起，共同完成信息和处理的双重模块化。

7.1.1 软件设计的概念

设计的目标是细化解决方案的可视化设计模型，确保设计模型最终能 滑地过渡到程序代码。

分析模型强调的是软件“应该做什么”，并不给出解决问题的方案，也不涉及具体的技术和 。

设计模型要回答“该怎么做”的问题，而且要 供解决问题的全部方案，包括软件如何实现、如何适应特定的实施环境 。

1.模块与构件

模块是一个拥有 确定义的输入、输出和特性的程序实体。如果模块的所有输入都是实现功能必不可少的，所有输出都有动作产生，即成为定义 确的模型。

2.抽象与细化

细化的实质是分解。逐步细化强调细化的“逐步”性质，即每一步分解仅较其前一步增加少量的细节。

3.信息隐藏

把系统分解为模块时应遵循的指导思想，称之信息的隐藏。模块内部的数据与过程的模块隐藏起来。这一指导思想的目的是为了 模块的性，当修改或维护模块时，减少 一个模块的错误扩散到其他模块中去的机会。

数据封装指在一个模块中包含一个数据结构和在此数据结构上执行的操作。

抽象数据类型指一种数据结构，其中可包含在该类型的实例上执行的操作。

比较3种不同的设计思想：面向过程的思想、面向功能的思想和面向对象的思想。 模块的功能可能相互交叉或重叠，模块间常常存在数据的共享或数据结构的共享，很难把这些模块移动到其他应用中。第二种思想设计出来的模型， 模块的功能 一，如能 它们与其他模块的数据共享降到最低限度，就可以在某些应用中重用。利用最后一种思想设计出来的模块是一个个的 位，不仅重用性较好，而且易于测试、联调和维护。

护。

7.1.2 软件设计的任务

分析阶段对目标系统的数据、功能和行为进行了 模，这是软件设计的基 。软件设计的任务是把分析阶段产生的分析模型转换为用适当手段表示的软件设计模型。

软件设计包括数据设计、体系结构设计、接 设计和过程设计 内容。数据设计 分析阶段创 的信息模型转变成实现软件所需的数据结构；体系结构设计定义软件主要组成部件之间的关系；接 设计描述软件内部、软件和接 系统之间以及软件与 之间是如何通信的（包括数据流和控制流）；过程设计 软件体系结构的组成部件转变成软件组件的过程性描述。

传统的设计任务通常分两个阶段完成。第一个阶段是概要设计，包括结构设计和接 设计，并编写概要设计文档；第二阶段是详细设计，其任务是确定 个软件的数据结构和操作，产生描述 软件部件的详细设计文档。每个阶段完成的文档，都必须经过复审。

7.1.3 模块化设计

模块化设计的目的是按照规定的原则把大型软件划分为一个个较小的、相对但相互关联的模块。

分解和模块性是实现模块设计的重要指导思想。

1.分解

2.模块性

性从两个方面来度量：模块本身的度量和模块之间的耦合。

模块本身的度量指模块内部 个成分之间的联系，也称块内联系或模块强度；模块之间的耦合指一个模块与其他模块间的联系，也称块间联系。模块的性愈 则块内联系愈强，块间联系愈弱。

（1）内聚

内聚从功能的 度对模块内部聚合能力的量度

偶然性内聚

①.逻辑性内聚

②.时间性内聚

③.过程性内聚

④.通信性内聚

⑤.顺序性内聚

⑥.功能性内聚

⑦.内聚强度由弱到强的顺序：

偶然性模块。块内 组成分在功能上是否互不相关的。这类模块内部

成分的组合纯属偶然

①.低内聚包括3类模块：

成分的组合纯属偶然

逻辑性模块。由若干个逻辑功能相似的成分组成。

②.时间性模块。模块所包含的成分，是由相同的执行时间而联接在一起

的。

③.过程性模块。当一个模块中包含的一组任务必须按照某一特定的次序

执行时，就称为过程性模块

①.通信性模块。模块内部 个成分都使用同一种输入数据，或者产生同

一个输出数据。靠公用数据而联系在一起，称为通信性内聚

②.中内聚包括2类模块

顺序性模块。这类模块中的 组成部分是顺序执行的。通常情况下，

上一个处理框的输出就是下一个处理框的输入。

①.功能性模块。功能性模块具有 内聚、与其他模块的联系少 优

点。“一个模块，一个功能”

②. 内聚模块

（2）耦合

耦合是对软件内部块间联系的度量。

一个模块可以直接调用另一模块中的数据，或者允许一个模块直接转移到另一模块中去，就称它们间的耦合为内容耦合

2014年6月4日

14:11

7.2.2面向对象设计的任务

设计阶段的主要任务是数据设计、体系结构设计、接 设计和过程设计。在面向对象的设计中，数据和过程被封装为类/对象的属性和操作；接 被封装为对象间的消息；体系结构的设计则表现为系统的技术基 设施和具有控制流程的对象间的协作。

1.系统架构设计

系统架构设计是指系统主要组成 素的组织或结构，以及其他全局性决策，组成 素之间通过接 进行交互。

2，系统 素设计

7.2.3模式的应用

1.模式的定义

模式是解决某一类问题的方，也是对通用问题的通用解决方案。其目的是把解决某一类问题得的方法 结、归纳到理论 度，供其他 在解决类似问题时参 或直接套用。

模式的经典定义：每个模式都描述了一个在某个特定环境中不断出项的问题，然后描述该问题解决方案的核心。通过这种方法，就可以无数次地使用那些已有的解决方案，无须再重复相同的工作。

2.软件模式的分类

软件模式可以分为架构模式、设计模式和习惯用法3种

层次架构的基本原则是 系统划分成不同层次

应用子系统层。包括应用程序特有的服务

①.业务专用层。包括在一些应用程序中使用的业务专用构件②.中间件层。包括 种复用构

③.系统软件层，它包括操作系统、数据库、与特定硬件的接 构件④.针对中型或大型软件的典型的分层方法，包括4个层次：

分布式应用是指应用程序的不同部件被安装在多个通过网络连接的计算机上，系统运行时不同计算机上的应用部件相互协作， 供应用服务

7.3.6 机交互设计

1.根据用户特定设计不同界面

2.增加用户界面专用的类与对象

3.利用快速原型演示，来改进界面设计

7.3 系统架构设计

2014年6月4日

14:29

系统 素设计的重点在于如何实现相关的类、关联、属性与操作，定义实现所需要的对象的算法与数据结构

7.4.1 子系统设计

子系统设计主要针对子系统内部所包含的设计 素及其交互。子系统设计的具体步骤：

1. 子系统行为分配给子系统 素

2.描述子系统 素

3.说 子系统依赖关系

7.4.2 分包设计

分包的目的是使设计 素更有秩序，呈现出更 显的 内聚、低耦合特征。

1.分包的原则

（1） 边界类打包

（2） 功能相关的类打包

2.描述包之间的依赖关系

包依赖关系显示了对某些类的修改如何波及系统的其他部分、

注：要杜绝包之间相互依赖对方的现象，否则如果对系统的一部分进行了某些修改，就很难对其他部分所受的影响做出正确的估计，因为在一个包中所做的修改 会波及整个依赖循环

3.包之间的耦合关系

包之间的耦合表现为依赖关系，意味着有机会使用其他包中对象的行为。

7.4.3 类/对象设计

类/对象设计主要 3个问题：

第一，如何实现分析模型中的边界类、实体类和控制类？

第二，在解决类设计中的实现问题时如何应用设计模式？

第三，系统架构中的全局性决定如何在类设计中体现？

设计边界类、

a.设计实体类

b.设计控制类

c.复杂性

i.变更的可能性

ii.设计控制类时至少要 的问题

创 初始设计类

(1)类设计的步骤：

7.4 系统 素设计

2014年6月4日

14:40

ii.

iii.

分布和性能

iv.

事务管

(2)

定义操作

(3)

定义方法

(4)

定义状态

定义属性

(5)

(6)

定义依赖关系

(7)

定义关联关系

定义泛化关系

(8)

(9)

处理非功能性需求

软件测试是动态查找程序代码中的 类错误和问题的过程。

8.4.1 目的与任务

测试的目的：发现程序中的错误

测试的任务：通过在计算机上执行程序，暴露程序中潜在的错误 纠错的目的：定位和纠正错误

纠错的任务：消除软件故障，保证程序的可靠运行。

8.4.2 测试的特性

1.挑剔性

测试是为了证 程序有错

2.复杂性

3.不彻底性

彻底测试就是让被测程序在一切可能的输入情况下全部执行一遍，这种测试为穷举测试。

4.经济性

穷举测试行不通，在程序测试中， 是选择一些典型的、有代表性的测试用例，进行有限测试，这种测试被称为选择测试。

选择测试用例时应注意遵守经济性原则：

第一，要根据程序的重要性和一旦发生故障 造成的损失来确定它的可靠性 级，不要随意 级，从而增加测试的成本；

第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。

8.4.3测试的种类

测试是一个执行程序的过程，即要求被测程序在计算机上运行。

程序测试 静态分析（程序不执行） 静态分析 分析（自动方式）代码评审（ 工方式） 代码会审 查 公 检查动态测试（程序执行） 测试（测试程序功能）白 测试（测试程序结构）

8.4.4 测试的文档

测试文档主要应包括测试计划和测试报告两个方面的内容

测试计划的主体是测试的内容说 。它包括测试项目的名称， 项测试的目的、步骤和进度，以及测试用例的设计 。

8.4 测试的基本概念

2014年6月3日

10:18

测试报告的主体是测试结果，它包括测试项目的名称，实测结果与期望结果的比较，发现问题，以及测试达到的效果 。

一个程序所需的测试用例可以定义为：

测试用例={测试的结果+期望结果}

测试结果={测试数据+ 期望结果+ 实际结果}

测试用例不仅是连接测试计划与执行的桥梁，也是软件测试的中心内容。

8.5.1 测试

测试就是根据被测试程序功能来进行测试，也称为功能测试 测试的常用技术：

1. 价分类法

价分类就是把输入数据的可能值划分为若干 价类，使每类中的任何一个测试用例，都能代表同一 价类中的其他测试用例。如果从某一 价类中任意选出一个测试用例未能发现程序的错误，就可以合理地认为使用该类中的其他测试用例也不会发现程序的错误。

采用这一技术要注意的两点：

其一是划分 价类不仅要 代表有效输入值的有效 价类，还需 代表无效输入值的无效 价类；

其二是每一无效 价类至少要用一个测试用例，不然就可能漏掉某一类错误，但允许若干有效 价类合同同一个测试用例，以便进一步减少测试的次数。

步骤：

第一步：划分 价类

第二步：设计有效 价类需要的测试用例。

第三步：为每一无效 价类至少设计一个测试用例

2.边界值分析法

边界值分析就是要把测试的重点放在 个 价类的边界上，选取刚好 于、刚刚大于和刚刚小于边界值的数据为测试数据，并据此设计出相应的测试用例。

价分类法的测试数据是在 个 价类允许的值域内任意选取的，而

边界值分析的测试数据必须在边界值附近选取

①.用边界值分析法设计的测试用例比 价分类法的代表性更广，发现错

误的能力也更强，但是，对边界的分析与确定比较复杂，要求测试 具有更多的经验和创造性

②. 价分类法和边界值分析法的比较：

3.错误猜测法

猜测就是猜测被测程序在哪些地方容易出错，然后针对可能的薄弱环节来设计测试用例。

4.因果图法

8.5 测试和白 测试、

2014年6月3日

10:50

4.因果图法

8.5.2 白 测试

白 测试以程序的结构为依据，又称为结构测试。

1.逻辑覆盖测试法

逻辑覆盖测试法通过流程图来设计测试用例。它 察的重点是图中的判定框（菱形框）

逻辑覆盖测试的5种标准：

语句覆盖

每条语句至少执行一次判定覆盖

每一判定的每个分支至少执行一次条件覆盖每一判定中的每个条件，分别按“真”、“假”至少 执

行一次

判定/条件覆盖

同时满足判定覆盖和条件覆盖的要求

条件组合覆

盖求出判定中所有条件的 种可能组合值，每一=可能的条件组合至少执行一次

2.路径测试法：基于流程图的分支路径

路径测试就是对程序图中每一条可能的程序执行路径至少测试一次。

满足结构测试的最低要求

①.有利于安排循环测试

②.从程序的执行路径而不是 纯从判定的 度来测试程序，有利于对程序中包含的循环结构进行更有效的测试。

路径测试的特征：

零次循环，即不执行循环体，直接从循环入 跳到出

•一次循环，循环体仅执行一次，主要检查在循环初始化中可能存在的错误

•典型次数的循环

•最大值次循环，如果循环次数存在最大值，应按此最大值进行循环，需要时还可增加比最大值次数少一次或多一次的循环测试

• 对 循环结构的路径测试可包括：

选择具有功能含义的路径

①.尽量用短路径代替长路径

②.从上一条测试路径到下一条测试路径，应尽量减少变动的部分（包括

变动的边和结点）

③.由简入繁，如果可能，应先 不含循环的测试路径，然后补充对循④. 选择测试路径的原则：

由简入繁，如果可能，应先 不含循环的测试路径，然后补充对循④.

环的测试

⑤.

除非不得已（如为了要覆盖某条边），不要选取没有 显功能含义的复杂路径

软件测试主要指多模块程序的测试。

8.7.1 测试的层次性

多模块程序的测试分层：

测试的层次 测试

成测试 级测试 确认测试系统测试

8.7.2 测试

测试的目的：通过对象模块的静态分析与动态测试，使其代码达到模块说 书的要求

对模块代码进行编 ，发现并纠正其语法错误

①.进行静态分析，验证模块结构及其内部调用序列是否正确

②.确定模块的测试策略，并据此设计一组测试用例和必要的测试软件③.用选定的测试用例对模块进行测试，直至满足测试终止标准为止④.静态分析与动态测试的重点，均应放在模块内部的重要执行路径、出

错处理路径和局部数据结构，也要重视模块的对 接

⑤.编制 测试报告

⑥.实施步骤：

编 →静态分析 检查→代码评审→动态测试

测试的任务:

代码评审：

评审有两类组织形式：

一类是 公 检查，由编程序者自己审查自己的代码，仅适用于规模较小的程序。

另一类以小组会的方式进行，又可分 查和代码会审两种，适用于 种规模的程序

测试软件

在 测试时，需要为被测模块编制若干测试软件，给它的上级模块或下级模块做替身。代替上级模块的称为测试驱动模块，代替下级模块的称为测试桩模块

8.7.3 成测试

在组装过程中进行的测试称为 成测试或组装测试

1.目的： 经过 测试的模块逐步组装成具有良好一致性的完整的程序8.7 多模块程序的测试策略

2014年6月3日

13:10

1.目的： 经过 测试的模块逐步组装成具有良好一致性的完整的程序制定 成测试实施策略。根据程序的结构，可以选择自顶向下或自底

向上或二者混合的两头逼近策略

①.确定 成测试的实施步骤，设计测试用例。二者的选择，应有利于揭

露在接 关系、访问全局性数据（包括公用文件与数据结构）、模块调用序列和出错处理 方面存在的隐患。

②.进行测试，即在已通过 测试的基 上，逐一地添加模块。每并入

一个模块，除进行新的测试项目 ，还需重复先前已经进行过的测试，后者也称为回归测试。回归测试可用于防止因软件组装改变而导致新的不协调，出现不可预料的错误。

③. 任务:

2.策略与步骤

成测试的策略，可以分为自顶向下、自底向上以及从两头逼近的混合方式3种。

（1）自顶向下测试

先广后深实施步骤

①.先深后广实施步骤

②.自顶向下测试要使用桩模块

步骤

从下层模块中找到一个没有下级模块的模块，由下向上地逐步添加新

模块，组成程序中的一个子系统或模块群

①.从另一子系统或模块群中选出另一个无下级模块的模块，仿照前一步

组成又一个子系统

②.重复上一步，直至得出所有的子系统，把他们组装为完整的程序。

③.（2）自底向上测试

（3）混合方式测试

对上层模块采取自顶向下测试

①.对关键模块或子系统采取由底向上测试

②.具体步骤：

3. 中策略的比较

由顶向下测试的优点是，能较早显示整个程序的轮廓，向用户展示程序的概貌，取得用户的理解和支持。其主要的缺点是，当测试上层模块时因使用桩模块较多，很难模拟出真实模块的全部功能，使部分测试内容被迫推迟，只能 到换上真实模块后再补充测试。

由底向上测试从下层模块开始，设计测试用例比较容易，但是在测试的早期不能显示出程序的轮廓。混合测试的优点正在于扬长避短，综合了以上两种策略的长处。

8.7.4确认测试

α与β测试

α测试是在一个受控的环境下，由用户在开发者的指导下进行的测

β 测试是由最终用户在自己的场所进行的，开发者通常不会在场，也不能控制应用的环境。

8.7.5系统测试

测试的目的是检查把确认测试合格的软件安装到系统中以后，能否与系统的其余部分协调运行，并且实现SRS的要求。

8.7.6终止测试的标准

1.规定测试策略和应达目标

进行白 测试时一般可规定以完全覆盖为标准，即语句覆盖率和分支覆盖率必须分别达到100%，满足这些条件就可以终止测试。

测试时，可结合程序的实际情况选择一或数种方法来设计测试用例。当把所有测试用例全部测试便可终止。

2.规定至少要查出的错误数量下载本文