软考--软件工程

需求分析阶段

安全攸关系统
安全攸关系统：系统失败会对生命构成威胁的系统，如航天，轨道交通等
软件安全性需求是指：通过约束软件的行为，使其不会出现不可接受的违反系统安全的行为。
软件安全性需求的获取：根据已知的系统信息，如软件危害条件等以及其他一些类似的系统数据和通用惯例，完成通用软件安全性需求的裁剪和特定软件安全性需求的获取工作。

需求变更管理
需求变更管理的过程主要包括问题分析和变更描述、变更分析和成本计算、变更实现。

需求管理流程

1. 问题分析和变更描述。识别和分析需求问题或一份明确的变更提议，以检查它的有效性，从而产生一个更明确的需求变更提议。
2. 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并确认，应该进行是否执行这一变更的决策。
3. 变更实现。需求文档和系统设计以及实现都要同时修改。

开发模型

软件过程是制作软件产品的一组活动以及结果，这些活动主要由软件开发人员完成，主要有：

1. 软件描述：定义软件与使用限制
2. 软件开发：编码
3. 软件有效性验证：进行严格的验证
4. 软件进化：变更需求

敏捷开发

以人为核心，迭代，循序渐进的开发方法，强调的是个体和交互胜过过程和工具。敏捷开发是面向对象的。

• XP（极限编程）：在一些对费用控制严格的公司中使用，已被证明是非常有效的
• 水晶系列法：用最少的纪律约束仍能成功的方法，在产出效率与易于运作上达到一种平衡
• 开放式源码：适合程序员在地域上分布广
• SCRUM法：明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题
• Coad的功用驱动开发方法：把开发人员分为首席程序员和类程序员
• ASD：核心是三个非线性的、重叠的开发阶段：猜测、合作与学习

软件生命周期

软件生命周期可以分为：软件定义、软件开发、软件运行与维护三个阶段
软件定义包括可行性研究和详细需求分析过程， 任务是确定软件开发工程必须完成的总目标。
软件开发包括软件的设计与实现。分为概要（总体）设计、详细设计、编码、测试
软件运行包括软件产品移交给用户使用。
软件维护包括对软件产品进行修改或软件需求变化做出响应的过程

软件开发环境

按照软件过程活动将软件工程分为：软件开发工具、软件维护工具、软件管理工具、软件支持工具。

• 软件开发工具：需求分析工具、设计工具、编码与排错工具
• 软件维护工具：版本控制工具（UNIX源代码控制工具）、文档分析工具、开发信息库工具、逆向工程工具、再工程工具
• 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择

软件设计

软件设计包括：

• 结构设计：定义软件系统各主要部件之间的关系
• 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程的复杂性
• 接口设计（人机界面设计）：软件内部，软件和操作系统间以及软件和人之间如何通信
• 过程设计：系统结构部件转换成过程的描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法

结构化设计方法

传统软件工程方法采用结构化设计方法（SD），分为两步：

1. 概要设计：将软件需求转化为数据结构和软件系统结构。
2. 详细设计：过程设计、通过对结构细化，得到软件详细数据结构和算法

结构化设计包括：

1. 架构设计：定义软件系统各主要部件之间的关系
2. 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性
3. 接口设计：定义软件内部、软件和操作系统间以及软件和人之间如何通信。
4. 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法

逆向工程

逆向工程导出的信息可分为如下4个抽象层次：

1. 实现级：包括程序的抽象语法树、符号表等信息
2. 结构级：反应程序分量之间相互依赖关系的信息，例如调用图、结构图等
3. 功能级：包括反应程序段功能及程序段之间关系的信息
4. 领域级：包括反映程序分量或程序与应用领域概念之间对应关系的信息

软件过程改进

• 能力成熟度模型：在软件开发机构中被广泛用来指导软件过程改进
• 关键过程领域：一系列互相关联的操作活动，反映了一个软件组织改进过程时必须集中精力改进的几个方面
• 需求跟踪能力链：跟踪一个需求的全过程
• 工作分解结构：按一定原则将项目分解为各个任务，知道分解不下去为止

配置管理

软件系统的文档可以分为用户文档和系统文档两类。
系统文档包括：系统设计、系统实现和测试

软件测试

性能测试

• 压力测试：确定系统的瓶颈或不能接收的性能点，来获得系统能够提供的最大服务级别的测试
• 强度测试：系统资源特别低的情况下考察软件系统极限运行的情况
• 负载测试：测试超负荷环境中程序是否能够承担，确定各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化
• 容量测试：用于测试系统同时处理在线最大用户数

单元测试：针对软件设计的最小单位进行正确性检查。一般使用白盒。在软件详细设计阶段完成。
集成测试：对已通过单元测试模块进行测试。一般使用黑盒。包括一次性组装测试和增量式组装测试。在概要设计阶段完成。

• 驱动模块 ：相当于被测模块的主程序。接收测试数据，把这些数据传送到被测模块，输出实测结果
• 桩模块：用以代替被测模块调用的子模块，桩模块不需要将所有功能都带进来

确认测试（有效性测试）：验证软件的功能、性能和其他特性，在需求分析阶段完成。

• 内部确认测试：软件开发组织内部按需求说明书进行测试
• α测试：用户在开发环境进行测试
• β测试：用户在实际应用环境中进行测试
• 验收测试：针对需求说明书，在交付前以用户为主进行测试

系统测试：主要包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试。在需求分析阶段完成。在需求分析阶段完成。

软件重用

软件重用是指：在两次或多次软件开发的过程中重复使用相同或相似软件元素的过程。
软件元素包括：需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识。
对于新的软件开发项目而言，它们或者是构成整个项目软件系统的部件，或者在软件开发过程中发挥某种作用。这些软件元素被称为软部件。

面向对象

面向对象分析模型包括：顶层架构图、用例图、领域概念模型（UML的类图）。
设计模型：包图表示 软件体系结构；交互图表示用例实现；复杂对象状态图，流程处理活动图。
结构化设计：数据流图表示功能模型；状态图表示行为模型；ER图表示数据模型。

UML

UML图

面向对象的分析模型主要有顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图，以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和描述流程化处理过程的活动图等。

4+1视图

4+1视图	UML
场景视图	use case
逻辑视图	类图
开发视图	类图、组件图
进程视图
部署视图	部署图

UML关系

• 泛化（继承）：两个用例之间存在父子关系
• 包含：如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中；或者一个用例功能太多时，可以使用包含关系建立更小的用例
• 扩展：一个用例混合了两种或两种以上的不同场景，即根据情况可能发生多种分支

设计模式

设计模式可分为

• 创建型模式：用于创建对象，为设计类实例化新对象提供指南
• 结构型模式：处理类或对象的组合，对类如何设计以形成更大的结构提供指南
• 行为型模式：用于描述类或对象的交互及职责的分配，对类的之间交互以及分配责任的方式提供指南

创建型模式主要包括：工厂模式、抽象工厂模式、原型（prototype）模式、单例（singleton）模式、构件（builder）模式。
结构型模式主要包括：适配器（adapter）模式、桥接模式、组合（composite）模式、装饰（decorator）模式、外观（dacade）模式、亨元（flyweight）模式、代理（proxy）模式。
行为型模式主要包括：命令模式、解释器模式、迭代器模式、中介者（mediator）模式、备忘录（memento）模式、观察者模式、状态模式、策略（strategy）模式、模板方法模式。
常见的设计模式有：

设计模式名称	简要说明
工厂模式	定义一个创建对象的接口，但由于子类决定需要实例化哪一个类，工厂方法使得子类实例化的过程推迟
抽象工厂模式	提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类
单例模式	保证一个类只有一个实例，并提供一个访问它的全局访问点
构建模式	将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示
原型模式 （prototype）	用原型实例指定创建对象的类型，并通过复制这个原型来创建新的对象
适配器模式 （Adapter）	将一个类的接口转成用户希望得到的接口。使原本不相容的接口得以协同工作
桥接模式	将类的抽象部分和现实部分分离开来，使他们可以独立的变化
组合模式 （Composite）	将对象组合成树形结构，使用户对单个对象和组合对象的使用具有一致性
装饰模式	动态的给一个对象添加一些额外的职责
外观模式 （Facade）	定义了一个高层接口，为子系统中的一组系统接口提供了一个一致外观，简化了系统的使用
亨元模式 （Flyweight）	提供支持大量细粒度对象共享的有效方法
代理模式 （Proxy）	为其他对象提供一种代理以控制这个对象的访问
职责链模式 （Chain of Responsibility）	通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合。将接受对象链接起来，直到有对象处理这个请求
命令模式	将一个请求封装为一个对象，将不同的请求封装为参数化，支持可撤销操作
解释器模式 （Interpreter）	定义一个解释器，该解释器用来根据文法表示解释语言中的句子
迭代器模式 （Iterator）	顺序访问一个聚合对象中的各个元素，不需要暴露该对象内部表示
中介者模式 （Mediator）	用中介对象封装一系列对象交互。使各对象不需要显示调用，从而达到低耦合，还可以独立地改变对象之间的交互
备忘录模式 （Memeto）	不破坏封装的前提下，捕获对象内部的状态，在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态
观察者模式	定义对象之间一对多的依赖，当一个对象发生改变时，所有依赖它的对象都会得到通知并自动更新
状态模式	允许一个对象在其内部状态改变时改变他的行为
策略模式 （Strategy）	定义一系列算法，把它们一个个封装起来，他们之间可以相互替换
访问者模式	作用于某对象结构中的各元素操作，使得不改变各元素的类的前提下定义作用与这些元素的新操作
模板模式	定义一个操作中的算法骨架，将这些步骤延迟到子类中，使得子类可以不改变算法的结构即可重新定义算法的某些特定步骤

遗留系统