系统架构设计师 5：软件工程

一、软件工程

1 软件过程模型

软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个全过程称为软件的生命周期。

为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型。

1.1 瀑布模型

瀑布模型的特点是因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。

瀑布模型的主要缺点：

1. 软件需求的完整性、正确性等很难确定，甚至是不可能和不现实的。因为用户不理解计算机和软件系统，无法回答目标系统“做什么”就，对系统将来的改变也难以确定，往往用“我不能确定”回答开发人员。

2. 用户和软件项目负责人要相当长的时间才能得到一个可以看得见的软件系统。如果出现与用户的期望不一致，或者出现需求变更，将会带来巨大的损失（如人力、财力、时间等）。

3. 瀑布模型的基本原则是在每个阶段一次性地完全解决该阶段的工作，不会出现遗漏、错误等情况，而实际上这是不现实或不可能的。

1.2 原型化模型

软件开发人员先根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。

1.3 螺旋模型

螺旋模型把整个软件开发流程分成多个阶段，每个阶段都由四部分组成：

1. 目标设定。

2. 风险分析。

3. 开发和有效性验证。

4. 评审。

该模型支持大型软件开发。

2 敏捷模型

敏捷方法的核心思想主要有以下三点：

1. 敏捷方法是“适应性”（adaptive）而非“预设性”（predictive）的。

    使用反馈机制对不可预测过程进行控制。

2. 敏捷方法是“面向人”（People-oriented）而非“面向过程”（Process-oriented）的。

    开发人员有权做技术方面的所有决定。

    开发中的相关人员之间应保证充分的信息交流，并提倡直接面对面交流。

3. 采用迭代增量式的开发过程。

几种影响比较大的敏捷方法：

1. 极限编程（XP）。

    它的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。

2. 水晶系列方法。

    其目的是发展一种提倡“机动性”的方法。

3. Scrum。

    该方法侧重于项目管理，包括了一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。

4. 特征驱动开发方法（FDD）。

    FDD认为有效的软件开发需要三个要素：人、过程和技术。

    FDD定义了六种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。

    FDD有五个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。

3 统一过程模型（RUP）

RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。

RUP中有九个核心工作流（Discipline）：

1. 业务建模。

    理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。

2. 需求。

    定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。

3. 分析与设计。

    把需求分析的结果转化为分析与设计模型。

4. 实现。

    把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。

5. 测试。

    检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。

6. 部署（Deployment）。

    打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。

7. 配置与变更管理。

    跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。

8. 项目管理。

    为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。

9. 环境。

    为软件开发机构提供软件开发环境，即提供过程管理和工具支持。

4 软件能力成熟度模型（CMM）

Level 1：初始级。

Level 2：已管理级。

Level 3：已定义级。

Level 4：量化管理级。

Level 5：优化级。

二、需求工程

需求工程的目标是：确定用户需求，定义设想中系统的所有外部特征。

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

1. 需求获取。

2. 需求分析。

3. 形成需求规格（文档化）。

    产出《产品需求规格说明书》。

4. 需求确认与验证。

5. 需求管理。

    包括需求文档的追踪管理、变更控制、版本控制等管理性活动。

1 需求获取

常见的需求获取方法有：

1. 用户面谈。

2. 需求专题讨论会。

3. 问卷调查。

4. 现场调查。

5. 原型化方法。

6. 头脑风暴法。

2 需求变更

迟到的需求变更会对已进行的工作产生非常大的影响，因此，项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。

变更控制过程用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。一旦确定了需求基线，应该使所有已建议的变更都遵循变更控制过程。需求变更管理过程如下：

1. 问题分析和变更描述。

2. 变更分析和成本计算。

3. 变更实现。

变更控制委员会（CCB）是项目所有者权益代表，负责裁定接受哪些变更。

3 需求跟踪

需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。

需求跟踪有两种方式：

1. 正向跟踪。

    检查《产品需求规格说明书》中的每个需求是否都能在后续工作成果中找到对应点。

2. 逆向跟踪。

    检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

三、系统分析与设计

1 结构化方法

1.1 结构化分析

结构化分析的常用手段是数据流图（DFD）和数据字典。

数据流图

数据流图（DFD）建模方法的核心是数据流，从应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。

DFD方法由四种基本元素组成：

1. 数据流。

    在图中用一个箭头描述数据的流向，箭头上标注的内容可以是信息说明或数据项。

2. 处理（Process）。

    表示对数据进行的加工和转换，在图中用矩形框表示。指向处理的数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。

3. 数据存储。

    表示持久化的数据，对其进行的存取分别以指向或离开数据存储的箭头表示。

4. 外部项。

    数据源或者数据终点，描述系统数据的提供者或者数据的使用者，在图中用圆角框或者平行四边形框表示。

数据字典

数据字段是对系统中使用的所有数据元素定义的集合。

在结构化分析中，数据字典的作用是给数据流图上每个元素加以定义和说明。

数据字典各部分的描述如下：

1. 数据项。

    数据项描述 = {数据项名, 数据项含义说明, 别名, 数据类型, 长度, 取值范围, 与其他数据项的逻辑关系}

2. 数据结构。

    数据结构描述 = {数据结构名, 含义说明, 组成: {数据项或数据结构}}

3. 数据流。

    数据流描述 = {数据流名, 说明, 数据流来源, 数据流去向, 组成: {数据结构}, 平均流量, 高峰期流量}

4. 数据存储。

    数据存储描述 = {数据存储名, 说明, 编号, 流入的数据流, 流出的数据流, 组成: {数据结构}, 数据量, 存取方式}

5. 处理过程。

    处理过程描述 = {处理过程名, 说明, 输入: {数据流}, 输出: {数据流}, 处理: {简要说明}}

1.2 结构化设计

结构化设计（SD）方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段：

1. 概要设计。

    主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系。

2. 详细设计。

    主要任务是为每个模块设计实现的细节。

信息隐藏与抽象

信息隐藏原则要求采用封装技术，将程序模块的实现细节隐藏起来，对于不需要这些信息的其他模块来说是不能访问的。按照信息隐藏的原则，系统中的模块应设计成“黑盒”，模块外部只能使用模块接口说明中给出的信息。

抽象原则要求抽取事务最基本的特性和行为，忽略非本质的细节，采用分层次抽象的方式可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程的管理。通常，抽象层次包括过程抽象、数据抽象和控制抽象。

模块化

在SD方法中，模块是实现功能的基本单位，它一般具有三个基本属性：

1. 功能：指该模块“做什么”。

2. 逻辑：描述模块内部“怎么做”。

3. 状态：该模块使用时的环境和条件。

耦合

耦合表示模块之间联系的程度，通常分为以下七种：

1. 非直接耦合。

    两个模块之间没有直接关系，它们之间的联系完全是通过上级模块的控制和调用来实现的。

2. 数据耦合。

    一组模块借助参数表传递简单数据。

3. 标记耦合。

    一组模块通过参数表传递记录等复杂信息。

4. 控制耦合。

    模块之间传递的信息中包含用于控制模块内部逻辑的信息。

5. 通信耦合。

    一组模块共用了一组输入信息，或者它们的输出需要整合以形成完整数据，即共享了输入或输出。

6. 公共耦合。

    多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

7. 内部耦合。

    一个模块直接访问另一个模块的内部结构；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口等。

内聚

内聚表示模块内部各代码成分之间联系的紧密程度，是从功能角度来度量模块内的联系。模块的内聚类型可以分为以下七种：

1. 功能内聚。

    完成一个单一功能，各个部分协同工作，缺一不可。

2. 顺序内聚。

    处理元素相关，而且必须顺序执行。

3. 通信内聚。

    所有处理元素集中在一个数据结构的区域上。

4. 过程内聚。

    处理元素相关，而且必须按特定的次序执行。

5. 时间内聚。

    所包含的任务必须在同一时间间隔内执行。

6. 逻辑内聚。

    完成逻辑上相关的一组任务。

7. 偶然内聚。

    完成一组没有关系或松散关系的任务。

在模块的分解中应尽量遵循“高内聚，低耦合”的设计原则。

1.3 结构化编程

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

结构化程序设计的原则可表示为：程序 = 算法 + 数据结构。

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

1.4 数据库设计

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

详见数据库章节。

E-R图

通常采用 实体-联系图（Entity Relationship Diagram, E-R图）来描述现实世界的概念模型。

在E-R图中有如下成分：

1. 实体。

    用矩形框表示。

2. 属性。

    用椭圆形框表示。

3. 联系。

    用菱形框表示。

    存在三种一般性约束：一对一约束（1 : 1）、一对多约束（1 : N）、多对多约束（M : N）。

2 面向对象方法

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程，主要包括需求分析、系统分析、系统设计和系统实现四个阶段。

2.1 面向对象分析

面向对象的分析方法（OOA）的基本原则包括如下内容：

1. 抽象。

    从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征。

2. 封装。

    把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。

3. 继承。

4. 分类。

    把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。

5. 聚合。

    把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。

6. 关联。

7. 消息通信。

    对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。在OOA中要求用消息连接表示出对象之间的动态联系。

8. 粒度控制。

    考虑全局时，注意其大的组成部分，暂时不考虑具体的细节；考虑某部分的细节时则暂时撇开其余的部分。

9. 行为分析。

2.2 面向对象设计

面向对象设计方法（OOD）的基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。

2.3 面向对象编程

面向对象程序设计（OOP）是一种计算机编程架构。

OOP的基本特点有封装、继承和多态。

2.4 数据持久化

对象持久化是把内存中的对象保存到数据库或可永久保存的存储设备中。

将对象持久化到关系数据库中，需要进行对象/关系的映射（Object/Relation Mapping, ORM）。

四、软件测试

1 测试方法

以测试过程中程序执行状态为依据，软件测试可分为：

1. 静态测试。

2. 动态测试。

以具体实现算法细节和系统内部结构相关情况为依据，软件测试可分为：

1. 黑盒测试。

2. 白盒测试。

3. 灰盒测试。

从程序执行的方式来分类，软件测试可分为：

1. 人工测试。

2. 自动化测试。

2 测试阶段

从阶段上划分，软件测试可以分为：

1. 单元测试。

2. 集成测试。

3. 系统测试。

    包含功能测试、性能测试、验收测试等。

五、净室软件工程

净室软件工程（CSE）是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。

说白了，追求一次写对。

六、基于构件的软件工程

基于构件的软件工程（CBSE）是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。

CBSE将考虑的重点从编程软件移到组装软件系统，工程师的焦点从“实现”变成了“集成”。这样做的基础是假定在很多大型软件系统中存在足够多的共性，从而使得开发可复用组件来满足这些共性是值得的。

七、软件项目管理

为使软件项目开发获得成功，关键问题是必须对软件项目的工作范围、可能风险、需要资源（人、硬件/软件）、要实现的任务、经历的里程碑、花费工作量（成本）、进度安排等进行预先计划和执行。

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

1 软件进度管理

1.1 工作分解结构

工作分解结构（WBS），就是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。

WBS总是处于计划过程的中心，也是制订进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

1.2 任务活动图

经过工作分解之后，会得到一组活动任务，这时需要对每个活动进行定义，并确定活动之间的关系。

活动定义是指确定完成项目的各个交付成果所必须进行的各项具体活动，需要明确每个活动的前驱、持续时间、必须完成日期、里程碑或交付成果。

每个活动在明确了前驱、必须完成日期等内容后，就确定了活动之间的相互关系，也就是活动执行的前后顺序。根据活动顺序就可以得到对应的任务活动图。

任务活动图是项目进度管理、项目成本管理等一系列项目管理活动的基础。

2 软件配置管理

软件配置管理（SCM）是一种标识、组织和控制修改的技术，应用于整个软件工程过程。SCM的核心内容包括：

1. 版本控制。

    对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理。

    版本控制最主要的功能是追踪文件的变更和并行开发。

2. 变更控制。

    对变更进行管理，确保变更有序进行。

3 软件质量管理

3.1 软件质量保证

软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

3.2 软件质量认证

目前国内软件企业主要采用的是ISO 9000和能力成熟度模型（CMM）。

4 软件风险管理

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。

在进行软件项目风险管理时，要辨识风险，评估它们出现的概率及产生的影响，然后建立一个规划来管理风险。