第一节　软件工程

1-1　软件工程定义

1-1-1 软件工程过程

(1)P(Plan)--软件规格说明。规定软件的功能及其运行时的限制。

(2)D(Do)--软件开发。开发出满足规格说明的软件。

(3)C(Check)--软件确认。确认开发的软件能够满足用户的需求,

(4)A(Action)--软件演进。软件在运行过程中不断改进以满足客户新的需求。

1-1-2　软件的生命周期

根据传统的软件生命周期方法学软件生命周期可以划分为软件定义、软件开发、件运行与维护三个阶段。

需要进行可行性研在软件定义阶段究和详细需求分析，以确定软件开发工程需要完的总目标。
软件开发阶段包括概要设计、详细设计、编码和测并持久满足用户要求。
软件维护阶段包括对软件产品进行修改试等。软件运行阶段将软件产品交付给用户使用或对软件需求变化作出响应，以延长软件寿命。
软件没有维护价值时，宣告退役，软件生命周期结束。

1-2　软件过程模型

基本概念

软件过程是指一组制作软件产品此题考察了软件过程模型的基本概念，属于常规的活动和结果，其主要包括软件描述、开发、有改性验证和进化。

1-2-1 瀑布模型

瀑布模型的特点是前后阶段存在因果关系，每之上，否则错误会隐蔽地传递到后一个阶段。因此每个阶段工作各阶段的工作都必须建立在前一个阶段正确结果完成后都需要审查和确认。虽然瀑布模型历史上发挥过重要作用，但也存在着一些问题，如无法适应快速变化的需求等。

1-2-2 原型化模型（快速模型）

适用范围：用户对系统的认识模糊不清，无法准确回答目标系统的需求

1-2-3 螺旋模型

4个部分：

目标设定
风险分析
开发和有效性验证
评审

适用范围：该模型支持大型软件开发，适用于面向规格说明、面向过程和面向对象的软件开发方法，也适用于几种开发方法的组合。

1-2-4 喷泉模型

一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。

1-2-5 W模型

W 模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

（二）系统工具

1．开发工具

需求分析工具、设计工具、编码与排错工具

2．维护工具

版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具

3．管理工具和支持工具

项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

1-3　敏捷模型

两个特点

适应性（adaptive）而非预设性（predictive）面向人的（People-oriented）而非面向过程的（Process-oriented）

1-3-1 主要的敏捷方法简介

极限编程（Extreme Programming，XP）
水晶系列方法：提倡”机动性的“方法
Scrum：侧重于项目管理。
特征驱动开发方法（Feature Driven Development，FDD）
- FDD 是一个迭代的开发模型。FDD 认为有效的软件开发需要3个要素:人、过程和技术。
- FDD 定义了6种关键的项目角色:项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
- FDD有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。

1-4　RUP（统一过程模型）

1-4-1 RUP的生命周期

1-4-1-1、9个核心工作流

业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境

1-4-1-2、 4个阶段

初始(inception)阶段:定义最终产品视图和业务型，并确定系统范围。
细化(elaboration)阶段:设计及确定系统的体系结构，制订工作计划及资源要求。
构造(construction)阶段:构造产品并继续演进需求、体系结构、计划直至产品提交。
移交(transition)阶段:把产品提交给用户使用。

细化阶段就可以得到一个完善的架构

每一次迭代都需要测试与集成

1-4-2 RUP中的核心概念

角色(Role):Who的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师(Architect)、设计人员(Designer)、实现人员(Implementer)、测试员(tester)和配置管理人员(Configuration Manager)等，并对每一个角色的工作和职责都做了详尽的说明。
活动(Activity):How 的问题。活动是一个有明确目的的独立工作单元。
制品(Artifact): What的问题。制品是活动生成、创建或修改的一段信息。也有些书把Artifact翻译为产品、工件等，和制品的意思差不多。
工作流(Workfow):When 的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

1-4-3 RUP的特点

1-4-3-1．用例驱动

RUP 中的开发活动是用例驱动的，即需求分析、设计、实现和测试等活动都是用例驱动的。

1-4-3-2．以体系结构为中心

（1） “ 4+1 ” 视图

4+1 视图模型可以从多个视图或视角来描述软件架构。其中，

① 进程（过程）视图用于捕捉设计的并发和同步特征；

② 实现（开发）视图描述了在开发环境中软件的静态组织结构。

③ 逻辑视图：最终用户关系的系统功能

④ 部署视图：系统工程师关系的系统发布、安装、拓扑结构

在“4+1”视图模型中，分析人员和测试人员关心的是系统的行为，会侧重于用例视图;
最终用户关心的是系统的功能，会侧重于逻辑视图:
程序员关心的是系统的配置、装配等问题会侧重于实现视图:
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图;
系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。

1-4-3-3．迭代和增量

软件开发采用迭代和增量的方式有以下好处。

(1)在软件开发的早期就可以对关键的、影响大的风险进行处理。

(2)可以提出一个软件体系结构来指导开发。

(3)可以更好地处理不可避免的需求变更。

(4)可以较早得到一个可运行的系统，鼓舞发团队的士气，增强项目成功的信心。

(5)为开发人员提供一个能更有效工作的开发过程。

1-5 软件能力成熟度模型（CMM）

1)Level1初始级

处于成熟度级别1级时，过程通常是随意且混乱的。这些组织的成功依赖于组织内人员的能力与英雄主义。成熟度1级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本。

2)Level2已管理级

在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。

3)Level3 已定义级

在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。

4)Level4 量化管理级

在成熟度4级，组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测。

5)Level5优化级

在优化级水平上，企业的项目管理达到了最高的境界。成熟度级别5级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。处于成熟度5级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。

1-6　UML图

1-6-1 对象图

描述一组对象及它们之间的关系，是系统的静态设计图或静态进程视图

1-6-2 类图

描述了一组类、接口、协作和他们之间的关系，给出了系统设计视图，活动类的类图还给出了系统的静态进程视图

1-6-3 活动图

将进程或其他计算结构展示位计算内部一步步的控制流和数据流，是系统的动态视图，对系统的功能建模和业务流程建模特别重要。

1-6-4 状态图

描述了一个状态机，强调事件导致的对象行为，适用于接口、类或协作的行为建模

1-7　设计模式

原型模式通过拷贝原型实例来创建新对象，不需要了解创建对象的类和细节;
抽象工厂模式提供创建一系列相关或相互依赖对象的接口;
构建器模式将复杂类的表示与构造相分离，能够得出不同的表示;
单例模式保证一个类只有一个实例并提供全局访问点。

二、　需求工程

2-0 概念

软件需求包括3个不同的层次:业务需求、用户需求和功能需求(也包括非功能需求)。

需求工程的活动主要被划分为以下几个阶段。

需求获取:通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
需求分析:为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
形成需求规格(或称之为需求文档化):按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件;软件需求描述规约乍为后续软件系统开发的指南。
需求确认与验证:以需求规格说明为输入，通过用户确认、复审会议、符号执行、模以仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
需求管理:包括需求文档的追踪管理、变更控制、版本控制等管理性活动。

2-1 需求获取

2-1-1 需求获取的基本步骤

开发高层的业务模型
定义项目范围和高层需求
识别用户角色和用户代表
获取具体需求
确定目标系统的业务工作流
需求整理与总结

2-1-2 需求获取方法

用户面谈
需求专题讨论会
问卷调查
现场观察
原型化方法
头脑风暴方法

2-2 需求变更

2-2-1 变更控制过程

常见的需求变更策略:

(1)所有需求变更必须遵循变更控制过程。
(2)对于未获得批准的变更，不应该做设计和实现工作。
(3)变更应该由项目变更控制委员会决定实现哪些变更:
(4)项目风险承担者应该能够了解变更的内容。
(5)绝不能从项目配置库中删除或者修改变更请求的原始文档。
(6)每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。

2-2-2 变更控制委员会（Change Control Board ， CCB）

变更控制委员会可能包括如下方面的代表。

(1)产品或计划管理部门。
(2)项目管理部门。
(3)开发部门。
(4)测试或质量保证部门。
(5)市场部或客户代表。
(6)制作用户文档的部门。
(7)技术支持部门。
(8)帮助桌面或用户支持热线部门。
(9)配置管理部门。

2-3 需求追踪

需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等，是要在整个项目的工件之间形成水平可追踪性。

需求跟踪有两种方式:

(1)正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
(2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

三、　系统分析与设计

系统设计的主要内容包括概要设计和详细设计。

3-1　结构化方法

结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它有结构化分析(SA)、结构化设计(SD)和结构化编程(SP)等方法。

3-1-1 结构化分析

结构化分析的步骤如下:

分析业务情况，做出反映当前物理模型的数据流图(Data Flow Diagram，DFD);
推导出等价的逻辑模型的 DFD;
设计新的逻辑系统，生成数据字典和基元描述;
建立人机接口，提出可供选择的目标系统物理模型的 DFD:
确定各种方案的成本和风险等级，据此对各种方案进行分析;
选择一种方案;
建立完整的需求规约。

3-1-1-1 数据流图

DFD 需求建模方法，也称为过程建模和功能建模方法。DFD 建模方法的核心是数据流，

DFD 方法由4种基本元素(模型对象)组成:数据流、处理/加工、数据存储和外部项。

数据流(Data Flow)。数据流用一个箭头描述数据的流向，箭头上标注的内容可以是信息说明或数据项。
处理(Process)。表示对数据进行的加工和转换，在图中用矩形框表示。指向处理的数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。
数据存储。表示用数据库形式(或者文件形式)存储的数据，对其进行的存取分别以指向或离开数据存储的箭头表示。
外部项。也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者，如教师、学生、采购员、某个组织或部门或其他系统，在图中用圆角框或者平行四边形框表示。

具体建模过程及步骤如下：

明确目标，确定系统范围
建立顶层DFD图
构建第一层DFD分解图
开发DFD层次结构图
检查确认DFD图

行为建模:状态转换图

3-1-1-2 数据字典

数据字典(Data Dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录,数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明。简而言之，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素定义的集合。

3-1-2 结构化设计

结构化设计(Structured Design，SD)是一种面向数据流的设计方法，它以 SRS 和 SA 阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。
SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。
概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系;将软件需求转化为数据结构和系统结构
详细设计的主要任务是为每个模块设计实现的细节。通过结构细化得出软件的详细数据结构和算法
软件设计包括四个既独立又相互联系的活动：
- 数据设计：高质量的数据设计将改善程序结构和模块划分，降低过程复杂性
- 软件结构设计：软件结构设计的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系
- 人机界面设计：人机界面设计描述了软件与用户之间的交互关系
- 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法
软件设计阶段的四个任务：
- 体系结构设计：用来定义主要部件之间的关系
- 接口设计：包括软件内部、软件和操作系统之间以及软件和人之间的通信
- 数据设计：数据设计将模型转化为数据结构的定义
- 过程设计。描述了系统结构部件转化为软件的过程，并确定了各个组成部分内的算法和内部数据结构

3-1-2-1 模块结构

信息隐藏与抽象

信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单的设计模块中，并且尽可能少地暴露其内部的处理过程。通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代软件设计的一个关键性原则

模块化
耦合

耦合性从低到高依次为非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合和内容耦合。所以应该尽量使用数据耦合、少用控制耦合和特征耦合、限制公共环境耦合的范围.完全不用内容耦合。

内聚

内聚性从高到低依次为功能内聚、顺序内聚、通信内聚、过程内聚、时内聚、逻辑内聚和偶然内聚。其中，功能内聚是最高的内聚性级别，

3-1-2-2 系统结构图

概要设计的表示工具：

1.图形工具

模块结构图、
层次图、
HIPO图

详细设计的基本步骤如下。

(1)分析并确定输入/输出数据的逻辑结构。
(2)找出输入数据结构和输出数据结构中有对应关系的数据单元。
(3)按一定的规则由输入、输出的数据结构导出程序结构。
(4)列出基本操作与条件，并把它们分配到程序结构图的适当位置。
(5)用伪码写出程序。

详细设计的表示工具有图形工具、表格工具和语言工具。

图形工具：

业务流图、
程序流程图（程序框图）
盒图（NS图）
PAD

表格工具
语言工具

伪代码
PDL

3-1-2-3 结构化编程（Structured Programming）

结构化程序设计采用自顶向下、逐步求精的设计方法，各个模块通过“顺序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。

结构化程序设计提出的原则可以归纳为 32 个字:自顶向下，逐步细化;清晰第一，效率第二；书写规范，缩进格式;基本结构，组合而成。

3-1-2-4 数据库设计

数据库设计是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和建立数据库的过程。

数据库设计的内容包括:需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护。

3-2　面向对象方法

面向对象开发方法认为客观世界是由对象组成的，对象由属性和操作组成，对象可按其属性进行分类，对象之间的联系通过传递消息来实现，对象具有封装性、继承性和多态性。
面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程，主要包括需求分析、系统分析、系统设计和系统实现4个阶段，但是，各个阶段的划分不像结构化开发方法那样清晰，而是在各个阶段之间迭代进行的。

3-2-1 面向对象分析 OOA

OOA 模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。

面向对象的分析模型主要由

顶层架构图、
用例与用例图、
领域概念模型

3-2-2 面向对象设计 OOD

在 OOD 中，类可以分为3种类型:

实体类:名词
控制类：动词+名词，名词+动词
边界类：边界类用于封装在用例内、外流动的信息或数据流

设计模型：

以包图表示的软件体系结构图、
以交互图表示的用例实现图、完整精确的类图、
针对复杂对象的状态图
用以描述流程化处理过程的活动图等

面向对象设计原则：单一职责原则：要求类应该只有一个设计目的开放-封闭原则：要求对于扩展开放，对于修改封闭里氏替换原则：要求子类可以替换父类依赖倒置原则：依赖倒置原则要求依赖于抽象，而不是具体实现接口隔离原则：要求使用多个专门的接口而不是单一的总接口组合重用原则：要求优先使用组合而不是继承关系实现代码重用。迪米特原则(最少知识法则)：要求一个对象应该对其他对象有尽可能少的了解

3-2-3 面向对象编程 OOP

OOP 达到了软件工程的3个主要日标:重用性、灵活性和扩展性。
0OP=对象+类+继承+多态+消息，其中核心概念是类和对象。
OOP 的基本特点有封装、继承和多态。

接口标准化是对接口中消息的格式、模式和协议的标准化

3-2-4 数据持久化与数据库

在面向对象开发方法中，对象只能存在于内存中，而内存不能永久保存数据，如果要永久保存对象的状态，需要进行对象的持久化(Persistence)，对象持久化是把内存中的对象保存到数据库或可永久保存的存储设备中。在多层软件设计和开发中，为了降低系统的耦合度，一般会引入持久层(Persistence Layer)，即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联，持久层的设计实现了数据处理层内部的业务逻辑和数据逻辑的解耦。

四、软件测试

4-1　测试方法

4-1-1 静态测试

静态测试是一种程序测试的方法，通过人工检测和计算机辅助静态分析，在机器上不运行程序，检测文档和代码的准确性和逻辑错误。检查文档通常以单独的形式进行，而检查代码一般采用桌面检查、代码审查和代码走查，能有效发现逻辑设计和编码错误。

4-1-2 静态测试

动态测试：在机器上运行

4-1-3 黑盒测试

黑盒测试从程序块功能、输入、输出等方面进行测试用例的设计和展开测试工作。

黑盒测试是针对产品功能规格说明书进行的验证活动，旨在确认产品的功能和特性是否得到完整实现，用户能否正常使用这些功能。它不考虑内部逻辑结构，主要集中在程序外部结构进行测试，试图发现的错误包括功能不正确或遗漏、界面错误、数据库访问错误、性能错误、初始化和终止错误。
黑盒测试的方法包括等价类划分法、边界值分析法、因果图法、判定表驱动法和错误推测法等。
黑盒测试主要用于集成测试、确认测试和系统测试阶段。
判定表驱动法方法最适合描述在多个逻辑条件取值组合所构成的复杂情况下，分别要执行哪些不同的动作。

4-1-4 白盒

白盒测试主要是借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。
白盒测试是从程序结构方面出发对测试用例进行设计。主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常以及内部结构是否有效。
常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。根据测试用例的覆盖程度，分为语句覆盖、判定覆盖、分支覆盖和路径覆盖等

4-1-5 灰盒

不仅关注输入输出，也关注逻辑

4-1-6 自动化测试

自动化测试工具：主要使用脚本技术来生成测试用例，脚本是一组测试工具执行的指令集合。
脚本的基本结构主要有五种:
- 线性脚本是录制手工测试的测试用例时得到的脚本;
- 结构化脚本具有各种逻辑结构和函数调用功能;
- 共享脚本是指一个脚本可以被多个测试用例使用;
- 数据驱动脚本是指将测试输入存储在独立的数据文件中，而不是脚本中;
- 关键字驱动脚本是数据驱动脚本的逻辑扩展，用测试文件描述测试用例

4-2　测试阶段

从阶段上划分，软件测试可以分为单元测试、集成测试和系统测试，
系统测试中又包含了多种不同的测试种类，例如功能测试、性能测试、验收测试、压力测试等

4-2-1 单元测试

驱动模块相当于被测模块的主程序，接收数据并将数据传送给被测模块，启动被测模块并打印结果，自顶向下的单元测试中不需要另外编写驱动模块。
桩模块是模拟被测模块调用的模块，用于替代直接相连的模块，以便测试被测模块的接口，为了模拟下级模块功能，测试前需要编写一些模拟接口的桩模块。
单元测试是针对独立的程序模块进行的测试，其目的是检查模块是否实现了设计说明中的各种要求

4-2-2 集成测试

集成测试可以分为一次性组装和增量式组装，增量式组装测试效果更好。集成测试计划一般在概要设计阶段完成

集成测试主要是检查模块之间的接口关系，以及已集成的软件是否符合设计要求。其测试的技术依据是软件概要设计文档。。而回归测试则是测试软件变更对已有功能的影响，主要关注变更部分的正确性以及对原有功能的不损害性，

4-2-3 系统测试

系统测试则是在真实系统环境下验证整个软件配置项的连接和是否满足各种要求

4-2-4 性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
强度测试、压力测试、负载测试、并发测试和可靠性测试是性能测试的主要类型。
强度测试是在系统资源特别低的情况下考查软件系统极限运行情况，比如网络状况不好，环墇极端。
压力测试偏重干这边请求并发数达到什么阶段的时候服务会崩溃。
负载测试主要测试系统能够承受多大的负载满足正常业务运行，比如系统的性能指标是1秒之内返回，不断加负载，看多大的负载情况下能够满足该指标。两者略有不同。
并发测试也称为容量测试，主要用于测试系统可同时处理的在线最大用户数量。并发，负载，压力比较接近，一般不作比较

4-2-5 验收测试 - 确认测试

通过了验收测试，该产品就可进行发布。用于验证软件与用户需求的一致性。
但是，在实际交付给用户之后，开发人员是无法预测该软件用户在实际运用过程中是如何使用该程序的，所以从用户的角度出发，测试人员还应进行 Alpha 测试或 Beta 测试。
Alpha测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。Alpha 测试主要是对软件产品的功能、局域化、界面、可使用性以及性能等等方面进行评价。
Beta 测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。

4-2-6 其他测试

AB测试
Web测试
链接测试
表单测试

五净室软件工程

净室软件工程(Cleanroom Software Engineering，CSE)是一种在软件开发过程中强调在软件中建立正确性的需要的方法。
在净室软件工程背后的哲学是:通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

5-1 理论基础

净室软件工程的理论基础主要是函数理论和抽样理论。

5-1-1 函数理论

一个明确定义的函数应当具备以下特性

完备性
一致性
正确性

5-1-2 抽样理论

5-2 技术手段

统计过程控制下的增量式开发(Incremental Development )
基于函数的规范与设计
正确性验证
统计测试（Statistically Based Testing）和软件认证

5-3 应用与缺点

净室软件工程在使用的过程中，也显示出一些缺点。

CSE 太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。CSE要求采用增量式开发、盒子结构、统计测试方法，普通工程师必须经过加强训练才能掌握，开发软件的成本比较高昂。
CSE 开发小组不进行传统的模块测试，这是不现实的。工程师可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的 bug 也可能导致未预期的错误。
CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

六　基于构件的软件工程（CBSE）

购买而非建造
从实现变成了集成

6-1 构件和构件模型

不管构件如何定义，用于CBSE 的构件应该具备以下特征。

可组装型:对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
可部署性:软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
文档化:构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
独立性:构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署,如确实需要其他构件提供服务，则应显示声明。
标准化:构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。

构件模型包含了一些模型要素，这些要素信息定义了构件接口、在程序中使用构件需要知道的信息，以及构件应该如何部署。

接口。构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等。
使用信息。为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。用户可以通过元数据找到构件提供的服务。构件模型的实现通常包括访问构件的元数据的特定方法。构件是通用实体，在部署的时候，必须对构件进行配置来适应应用系统。
部署。构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。

6-2 CBSE 过程

CBSE 过程中的主要活动包括:

系统需求概览;
识别候选构件;
根据发现的构件修改需求;
体系结构设计;
构件定制与适配;
组装构件，创建系统。

6-3 构件组装

构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。
构件组装技术可分为基于功能的、基于数据的和面向对象的三种、
构件组装分为三个不同的层次，分别是定制、集成和扩展。这三个层次对应着不同的任务，涉及到构件组装过程中的不同方面。

6-3-1 顺序组装

通过按顺序调用已有构件来创建新构件,适用于构件作为程序元素或服务。需要胶水代码保证前一构件输出与下一构件输入相兼容。

6-3-2 层次组装

一个构件直接调用另一构件提供的服务，被调用构件的"提供"接口必须与调用构件的"请求"接口相容，否则需编写胶水代码实现转换

6-3-3 叠加组装

两个或多个构件合并创建新构件，新构件合并了原构件功能并对外提供新接口。原构件之间无依赖关系,外部应用通过新接口调用原构件接口

6-4 构件管理

构件描述，构件分类，构件库组织，人员及权限管理，用户意见反馈等。

6-5 构件分类

构件分类方法包括关键字分类法、刻面分类法和超文本组织方法。

关键字分类法将应用领域的概念按照从抽象到具体的顺序逐次分解为树状或有向无回路图结构，每个概念用一个描述性的关键字表示。
刻面分类法定义若干用于刻画构件特征的“面”，每个面包含若干概念，这些概念表述构件在面上的特征;
超文本组织方法基于全文检索技术，要求所有构件必须辅以详尽的功能或行为说明文档，说明中出现的重要概念或构件以网状链接方式相互连接，用户在阅读文档的过程中可按照人类的联系思维方式任意跳转到包含相关概念或构件的文档，全文检索系统实现构件的浏览式检索。将用户给出的关键字与说明文档中的文字进行匹配

6-6 体系结构失配问题

体系结构失配问题，即在软件复用过程中，由于待复用构件对最终系统的假设与实际情况不同所引起的冲突。
失配问题主要包括由构件和连接子引起以及系统成分对全局体系结构的冲突。

6-7　面向构件编程（COP）

6-7-1 基本支持

多态性、模块封装性、后期的绑定和装载、安全性

面向构件的编程(COP)是关注如何构建面向构件的解决方案的编程方式。

多态性：表示同一类型的不同实例对象可以具有不同的行为，可以相互替代，是构件之间互换性和可重用性的关键;
模块封装性：表示将构件内部的实现细节和高层次的信息隐藏起来，只对外暴露必要的接口可以防止构件被错误地使用，同时提高构件的可维护性;
后期的绑定和装载：指的是在构件部署时进行绑定，从而实现构件的部署独立性，可以使构件更加灵活和易干部署;
安全性：则是确保构件的类型和模块安全性，以避免构件被非法访问或使用，可以保护系统的完整性和稳定性。

6-7-2　CORBA

CORBA 是一种面向对象的远程调用技术，其中包括三核心组件。

伺服对象：实现客户端请求，对象适配器屏蔽ORB 内核的实现细节，为服务器对象提供抽象接口，
对象请求代理：解析调用并负责查找实现请求的对象。通过这三个组件，客户方无需了解服务对象的位置、通信方式、实现、激活或存储机制，实现了面向对象的远程过程调用。
可移植对象适配器 POA ：是 CORBA 中的一个中个，它可以连接ORB和其他组件。客户端请求可以通过略POA 传递到服务器对象，并提供了管理服务器对象的策略。

6-7-3　EJB

（一）会话Bean:负责完成服务端与客户端的交互，可以有状态态或无状态，用于实现业务逻辑，可以直接访问数据库或通过实体 Bean 访问数据库。

（二）实体Bean:用于数据持久化来简化数据库开发工作；实体 Bean 使用 O/R 映射将数据库表记录映射为内存中的实体对象，与数据库的状态保持同步。

（三）消息驱动Bean：主要用来处理并发和异步访问操作。消息驱动 Bean 基于 JMS 消息，只能接收 JMS 消息用于异步处理客户端请求，适合于需要异步处理请求的场合，如订单处理等

七　软件项目管理

7-1 软件管理概述

软件管理的对象是软件工程项目

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。

7-2 软件进度管理

在软件进度管理过程中，一般包括:活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制。

7-2-1 工作分解结构（Work Breakdown Structure ， WBS）

7-2-2 任务活动图

在项目管理中，目前通常采用甘特图等方式来展示和管理项目活动。

7-3 软件配置管理（Software Configuration Management·，SCM）

软件配置管理核心内容包括版本控制和变更控制。

配置管理工具的常见功能，包括版本控制、变更管理、配置状态管理、访问控制和安全控制等。
配置管理工具包含版本控制工具，后者的功能是存储、更新、恢复和管理软件的多个版本。

7-4 软件质量管理

7-4-1 软件质量保证（Software Quality Assurance，SQA）

软件质量保证的主要任务是以下3个方面。

(1)SQA 审计与评审。SQA 审计包括对软件工作产品、软件工具和设备的审计，评价这几项内容是否符合组织规定的标准。SOA评审的主要任务是保证软件工作组的活动与预定的软件过程一致，确保软件过程在软件产品的生产中得到遵循。
(2)SQA报告。SQA 人员应记录工作的结果，并写入到报告之中，发布给相关的人员。SOA报告的发布应遵循三条原则:
- SOA和高级管理者之间应有直接沟通的渠道;
- SOA 报告必须发布给软件工程组，但不必发布给项目管理人员;
- 在可能的情况下向关心软件质量的人发布SOA 报告。
(3)处理不符合问题。这是 SOA 的一个重要的任务，SOA 人员要对工作过程中发现的问题进行处理及时向有关人员及高级管理者反映

7-4-2 软件质量认证

7-5 软件风险管理

7-6 逆向工程

逆向工程导出信息包括4个抽象层次，实现级、结构级、功能级和领域级。其中，如调用图、结构图等。构级包括程序分量之间相互依赖关系的信息与应用领域概念之间对应功能级包括程序段功能及程序段之间关系的信息。领域级则反映程序分量或程序诸实体关系。

7-6-1 实现级

7-6-2 结构级

包含程序分量之间相互依赖关系的信息，如调用图，结构图

7-6-3 功能级

包括程序段功能及程序段之间关系的信息

7-6-4 领域级

反映程序分量或程序诸实体与应用领域概念之间对应关系

第5章-软件工程基础知识

第一节 软件工程

1-1 软件工程定义