系统架构设计师备考系列之软件工程-优快云博客

一、软件工程

1.1 软件工程定义

软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②对①中所述方法的研究。
软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下4个方面。
- (1) P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
- (2) D(Do)——软件开发。开发出满足规格说明的软件。
- (3) C(Check)——软件确认。确认开发的软件能够满足用户的需求。
- (4) A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。

1.2 软件过程模型（软件生命周期模型）

软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个全过程称为软件的生命周期。软件生命周期描述了软件从生到死的全过程。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型，有时也称之为软件生命周期模型。

1.2.1 瀑布模型

介绍
瀑布模型 (Waterfall Model) 是最早使用的软件过程模型之一，包含一系列活动。这些活动从一个阶段到另一个阶段逐次下降，它的工作流程在形式上很像瀑布，因此被称为瀑布模型。如下图：
特点
- 阶段清晰；
- 各阶段有产出物，上一阶段的输出作为下一阶段的输入；
- 对活动的实施工作成功进行评审，评审确认通过后，则进行下一项开发活动；
应用场景
- 需求明确的开发
- 二次开发
缺点
- 软件需求完整性、正确性难确定
- 严格串行化，很长时间才能看到结果
- 要求每个阶段一次性完全解决该阶段工作，这不现实

1.2.2 原型模型（快速原型）

介绍
第一步是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过充分的讨论和分析，最终弄清楚当前系统的需求。原型的概念也被后续出现的过程模型采纳，如螺旋模型和敏捷方法。
特点
- 先构建一个简易原型
- 原型的构造一般是为了演示
分类
- 快速原型（抛弃型原型）
  获得需求后抛弃原型
- 演化原型
  将原型演化为最终软件产品
应用场景
- 需求不明确的系统

1.2.3 螺旋模型

介绍
开发过程具有周期性重复的螺旋线状，每个周期分为四个阶段：制定计划、风险分析、实施工程、客户评估。
特点
- 以快速原型模型为基础 + 瀑布 + 迭代
- 强调风险分析
应用场景
- 适用于庞大而复杂、高风险的系统

1.2.4 敏捷模型

开发宣言
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过谈判
- 响应变化胜过遵循计划
特点
- 适应性
- 以人为本
- 迭代增量式的开发过程
- 以原型开发思想为基础，采用迭代式增量开发，发型版本小型化
  
  传统软件开发方法敏捷方法
  预设性的适应性的
  以开发过程为本以人为本
  整体分阶段增量迭代, 小步快跑
  （适合小型项目）
主要敏捷方法
- 极限敏捷（XP）
  - 加强沟通，从简单做起，寻求反馈，勇于实事求是；
  - 将复杂的开发过程分解为一个个相对比较简单的小周期；
  - 测试先行
- 水晶系列方法
  - 以人为中心
  - 提倡机动性，不同的项目需要不同的方法
- 并列争球法（Scrum）
  - 侧重于项目管理；
  - 每段时间一次的迭代成为一个“冲刺”；
  - 按需求的优先级别来实现产品；（使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。）
  - 发布产品的重要性高于一切；
- 特性驱动开发方法（FDD）
  - 认为有效的软件开发需要3个要素：人、过程、技术
  - 定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、普通程序员、领域专家
  - 5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。
应用场景
- 适用于小项目（实际项目中，可将大项目拆成小项目）

传统软件开发方法	敏捷方法
预设性的	适应性的
以开发过程为本	以人为本
整体分阶段	增量迭代, 小步快跑（适合小型项目）

1.2.5 统一过程模型（RUP）

介绍
描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、目标以及实例支持。
核心工作流
RUP软件开发生命周期是一个二维的软件开发模型， RUP 中有9个核心工作流，这9个核心工作流如下：
- 业务建模（商业建模）
  理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。简单来说就是，商业价值评估。
- 需求
- 分析与设计
  把需求分析的结果转化为分析与设计模型。
- 实现
- 测试
- 部署
- 配合与变更管理
  跟踪并维护系统开发过程中产生的制品的一致性和完整性。
- 项目管理
- 环境
  为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
四个阶段
- 初始阶段：定义最终产品视图和业务模型，确定系统范围
- 细化阶段：设计和确定系统的体系结构，制定工作计划和资源要求
- 构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交
- 移交阶段：交付产品给用户使用
特点
- 用例驱动
  RUP中的开发活动是用例驱动的，即需求分析、设计、实现和测试等活动都是用例驱动的。
- 以体系结构为中心
  RUP采用如下图所示的“4+1”视图模型来描述软件系统的体系结构。
- 迭代与增量

1.2.6 喷泉模型

以用户需求为动力，以对象作为驱动；
面向对象的模型，而其他模型都是结构化的模型；
开发过程具有迭代性和无间隙性；；

1.2.7 基于构件的开发模型CBSE

介绍
- 基于构件的软件工程 (Component-Based Software Engineering,CBSE) 是一种基于分布对象技术、 强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的构件可以是COTS(Commercial-Off-The-Shelf) 构件，也可以是通过其他途径获得的构件(如自行开发)。 CBSE 体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于已有构件的组装，以更快地构造系统，减轻用来支持和升级大型系统所需要的维护负担，从而降低软件开发的费用。
- 在软件复用领域，一般观点认为 构件是一个独立的软件单元，可以与其他构件构成一个软件系统。用于CBSE 的构件应该具备以下特征。
  - (1) 可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须对自身信息的外部访问。
  - (2) 可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是二进制形式，无须在部署前编译。
  - (3) 文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
  - (4) 独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
  - (5) 标准化：构件标准化意味着在 CBSE过程中使用的构件必须符合某种标准化的构件模型。
- 构件的组装方式
  - 顺序组装
  - 层次组装
  - 叠加组装
- 构件的不兼容情况
  - 参数不兼容
  - 操作不兼容
  - 操作不完备
CBSE过程中的主要活动
- (1) 系统需求概览；
- (2) 识别候选构件；
- (3) 根据发现的构件修改需求；
- (4) 体系结构设计；
- (5) 构件定制与适配；
- (6) 组装构件，创建系统。
特点
- 增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。

1.2.9 净室软件工程

介绍
净室 (Cleaning Room) 软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室软件工程的理论基础主要是函数理论和抽样理论。
缺点
- CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。 CSE要求采用增量式开发、盒子结构、统计测试方法，普通工程师必须经过加强训练才能掌握，开发软件的成本比较高昂。
- CSE 开发小组不进行传统的模块测试，这是不现实的。工程师可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的bug也可能导致未预期的错误。
- CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。

1.2.8 形式化方法模型

建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。

1.4 软件能力成熟度模型

CMMI 是由美国卡耐基梅隆大学软件工程研究所组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的，并在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。

能力等级	特点	关键过程区域
初始级	过程不可预测且缺乏控制
已管理级	过程为项目服务	需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证
已定义级	过程为组织服务	需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
定量管理	过程已度量和控制	组织过程性能、定量项目管理
优化级	集中于过程改进和优化	组织级改革与实施、因果分析和解决方案

1.5 逆向工程

逆向工程：软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
逆向工程的四个级别：
- 实现级：包括程序的抽象语法树、符号表、过程的设计表示。（从二进制或低级代码还原出高级语言代码）
- 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。（分析程序的模块、包、类、函数、调用关系等架构信息）
- 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。(理解代码的具体功能和行为逻辑)
- 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。(理解系统背后的业务规则和领域知识)
  其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。

二、需求工程

2.1 需求开发

2.1.1 需求获取

目的：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

需求获取方法

方法	特点
用户面谈	1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。
联合需求计划(JRP)	高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。
问卷调查	用户多，无法一一访谈，成本低。
现场观察	针对较为复杂的流程和操作。
原型化方法	通过简易系统方式解决早期需求不确定问题。
头脑风暴法	一群人围绕新业务，发散思维，不断产生新的观点。

2.1.2 需求分析

目的：为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
结构化方法
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。
- 特点：自顶向下，逐步分解，面向数据
- 三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图） 以及数据字典
- 数据流图（DFD）基本元素
  - 数据流
    数据流的流向必须经过加工
  - 加工
  - 数据存储
    文件、表、库、清单、档案
  - 外部实体
    人物角色、组织机构、外部系统、时间、温度、传感参数等
面向对象方法
- 面向对象需求建模模型：
  - 用例模型（用例图）
    - 识别参与者
    - 合并需求获得用例
    - 细化用例描述
    - 调整用例模型
  - 分析模型（类图）
    - 定义概念类
    - 识别类之间的关系
    - 为类添加职责
    - 建立交互图
  - 统一建模语言（UML）
    - 结构
      - 构造块
        事物
        关系
        图（多个相互关联的事物的集合）
      - 公共机制（达到特定目标的公共UML方法）
      - 规则（构造块如何放在一起的规定）
    - UML图
    - 4+1模型

2.1.3 需求定义 [形成需求规格说明书SRS]

需求定义方法

2.1.4 需求验证 [形成需求基线(经过评审的SRS)]

需求验证：也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SRS进行评审和测试，包括两个步骤：
- 需求评审：正式评审和非正式评审。
- 需求测试：设计概念测试用例。
需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

2.2 需求管理

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

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

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。

三、系统分析与设计

系统分析阶段是应用系统思想和方法，把复杂的对象分解为简单的组成部分，找出这些部分的基本属性和彼此之间的关系的过程，其基本任务是系统分析师和用户在充分了解用户需求的基础上，把双方对新系统的理解表达为系统需求规格说明书。
系统设计的目标是根据系统分析的结果，完成系统的构建过程。其主要目的是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型，指导系统实施工作的顺利开展。系统设计的主要内容包括概要设计和详细设计。

3.1 结构化方法

3.1.1 结构化分析

结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等

3.1.2 结构化设计

结构化设计 (Structured Design,SD) 是一种面向数据流的设计方法，它以SRS和SA阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。 SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段，其中概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；详细设计的主要任务是为每个模块设计实现的细节。

软件结构化设计分为四个活动
- 数据设计：将模型转化为数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
- 架构(体系结构)设计：定义软件系统各主要部件之间的关系。
- 人机界面(接口)设计：软件内部、软件、操作系统间以及软件和人之间如何通信、交互。
- 过程设计：系统结构部件转换成软件的过程描述。
模块结构
- 信息隐蔽和抽象
- 模块化
- 耦合
- 内聚
设计原则
- 保持模块独立性原则（高内聚、低耦合）
- 保持模块的大小适中
- 多扇入，少扇出
- 深度和宽度都不宜过高
流程表示工具
- 程序流程图（PFD）
  程序流程图（Program FlowDiagram，PFD）用一些图框表示各种操作，它独立于任何一种程序设：计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。
- IPO图
  IPO图也是流程描述工具，用来描述构成软件系统的每个模块的输入（Input）、加工（Processing）、输出（Output）。
- N-S图（盒图）
  N-S图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大，因此不适合于复杂程序的设计。
- 问题分析图（PAD）
  一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

3.1.3 结构化编程

“面向结构”的程序设计方法即结构化程序设计方法，是“面向过程”方法的改进，结构上将软件系统划分为若干功能模块，各模块按要求单独编程，再组合构成相应的软件系统。该方法强调程序的结构性，所以容易做到易读易懂。

3.2 面向对象方法

3.2.1 面向对象分析

面向对象的分析方法 (Object-Oriented Analysis,OOA), 是在一个系统的开发过程中进
行了系统业务调查以后，按照面向对象的思想来分析问题。 OOA与结构化分析有较大的区别。OOA 所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构；另一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。

3.2.2 面向对象设计

面向对象的设计原则
- 单一责任原则
  设计目的单一的类
- 开闭原则
  对扩展开放，对修改封闭。即当需求发生变化时，应通过扩展现有代码来适应新需求，而不是修改已有代码。
- 里氏替换原则
  子类可以替换父类
- 依赖倒置原则
  抽象不应该依赖于细节，细节应该依赖于抽象。
- 接口分离原则
  使用多个专用的接口比使用单一的通用接口要好。不要强迫客户依赖于它们不用的方法。接口依赖于抽象，不要依赖于具体。
UML
- 类关系
  - 关联
    描述一组对象之间连接的结构关系
  - 组合
    部分和整体的关系，相同生命周期
  - 聚合
    部分和整体的关系，不同生命周期
  - 泛化
    一般与特殊的关系，即子类和父类之间的关系
  - 实现
    是一种类与接口的关系，表示类是接口所有特征和行为的实现
  - 依赖
    其中一个事物的变化会影响另一个事物
- 用例关系
  - 泛化
  - 扩展
  - 包含
- 在OOD 中，类可以分为3种类型：实体类、控制类和边界类。

3.2.3 面向对象编程

基本特点
- 封装
- 多态
- 继承

3.3 界面设计

黄金三大法则
- 置于用户控制之下
- 减少用户的记忆负担
- 保持界面的一致性

3.4 设计模式

创建型
结构型
行为型

四、软件测试

4.1 测试方法（执行状态为依据）

4.1.1 静态方法

桌前检查、代码评审、代码走查
控制流分析：使用控制流图系统地检查程序的控制结构。是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序。
数据流分析：用数据流图分析数据处理的异常现象（数据异常），如：初始化、赋值、引用过程中的异常。
接口分析：分析子程序和函数之间的接口一致性，包括检查形参和实参类型、个数、维数、顺序的一致性等。
表达式分析：括号不配对、数组引用越界、除数为零等。

4.1.2 动态方法

黑盒测试【功能性测试】（主要用于集成测试阶段）
白盒测试【结构性测试】（主要用于单元测试阶段）

4.2 测试用例设计

黑盒测试
- 等价类划分
  把所有的数据按模组特性进行归类，而后在每类的数据里选取一个即可。设计原则：设计一个新的测试用例，使其尽可能地覆盖尚未被覆盖的有效等价类；设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类；
- 边界值划分
  将每类的边界值作为测试用例，边界值一般为范围的两端值及此范围之外与范围间隔最小的两个值。
- 错误推测
  没有固定方法，凭经验而言，推测可能产生问题的地方。
- 因果图
- 没有固定方法，由一个结果来反推原因的方式，具体结构具体分析。
白盒测试
- 语句覆盖
  所有的语句都执行一遍，覆盖层级最低。因为执行了所有的语句，不代表执行了所有的条件判断。
- 判定覆盖
  逻辑代码中所有的条件判断的条件的真假分支都要覆盖一次。
- 条件覆盖
  针对每一个判断条件内的每一个独立条件都要执行一遍真和假
- 条件判定组合覆盖
  同时满足判断覆盖和条件覆盖
- 路径覆盖
  逻辑代码中所有的可行路径都覆盖了，覆盖层级最高。