#边学边记 软件工程与新技术 软件工程（3）

软件架构设计

以下内容需要牢记

1. 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成；
2. Garlan和Shaw对通用软件架构风格进行了分类。

• 数据流风格：包括批处理序列和管道/过滤器两种风格；管道过滤器是黑盒模式。
• 调用/返回风格：包括主程序/子程序、数据抽象和面向对象及层次结构；
• 独立构件风格：包括进程通信和事件驱动的系统；
• 虚拟机风格：包括解释器和基于规则的系统；
• 仓库风格：包括数据库系统、黑板系统和超文本系统；
  以上内容需要牢记

软件架构评估

1. 敏感点是一个或多个构件（和/或构件之间的关系）的特性；
2. 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点；
3. 软件评估技术分为基于调查问卷的方式、基于场景的方式（最为常用）和基于度量（打分）的方式。
4. 基于场景的方式最常用，分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
5. 基于场景的方式最主要包括：架构权衡分析法（ATAM）、软件架构分析法（SAAM）和成本效益分析法（CBAM）。
6. 在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。

软件设计

结构化设计（SD）

1. SD是一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典为文档基础，是一个自顶向下、逐步求精和模块化的过程。分为概要设计（又称为总体设计，其结果是系统结构图 和详细设计）。
2. SD遵循的一个基本原则是：高内聚、低耦合。
3. 内聚表示模块内部各成分之间的联系程度，是从功能角度来度量模块内的联系。
4. 耦合表示模块之间联系的程度。

面向对象设计（OOD）

1. OOD基本思想：抽象、封装和可扩展。可扩展主要通过继承和多态来实现。
2. 在OOD，可维护性的复用是以设计原则为基础。常用的OOD原则包括：单一职责原则 ；开放封装原则；李氏替换原则 ；依赖倒置原因；接口隔离原则 ；组合重用原则；迪米特原则（最少知识法则）。

设计模式

设计模式可以使人们方便地复用成功的软件设计。

• 根据处理范围不同，分为类模式（静态）和对象模式（动态）；
• 根据目的和用途不同，可分为创建型模式、结构型模式和行为模式三种。

软件工程的过程管理

阶段式模型

阶段式模型基本沿袭CMM模型框架，4个成熟等级，但关键过程域做了调整和扩充：

成熟度等级	过程
2 可管理级	需求管理、项目计划、配置管理、项目监督与控制、供应商管理、度量和分析、过程和产品质量保证
3 已定义级	需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、4 决策分析和解决方案、组织集成环境
4 量化管理级	组织级过程性能、定量项目管理
5 优化管理级	组织改革与实施、因果分析和解决方案

表：过程域的阶级式分组

第一级是混乱的；
第二级是可以复制以往的成功；
第三级 标准化文档化
第四级 管理更加量化
第五级 持续改进优化

连续式模型

连续式模型与阶段式模型相比，连续式模型没有组织成熟度相关的几个阶段。连续式模型将24个过程域按照功能分为过程管理、项目管理、工程和支持四个过程组。

连续式分组	过程域
过程管理	组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施
项目管理	项目计划、项目监督与控制、供应商合同管理、项目集成管理、风险管理、集成化团队、定量项目管理
工程	需求管理、需求开发、技术解决方案、产品集成、验证、确认
支持	配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、因果分析和解决方案

表：连续式模型的过程域分组
速记词：
组织即过程——凡是有『组织』，就是『过程管理』，但『组织级集成环境』除外。
风合团项目——凡是有风险、合同、团队、项目等字样的，均是『项目管理』。
谗言却急需——凡是有『产品』、『验证』、『确认』、『技术』、『需求』的即工程。
其它还支持——不在以上速记词的均是『支持』，还=环，即『组织级集成环境』的『环』。

软件测试及其管理

测试方法

1. 软件测试的目的是验证软件是否满足软件开发合同或项目开发计划系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。
   软件测试仍是发现软件错误（缺陷）的主要手段。
2. 软件测试方法可分为静态测试和动态测试。

	静态测试	动态测试
定义	被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。	在计算机上实际运行软件测试
方法	文档的静态测试：检查 单代码的静态测试：桌前检查、代码走查、代码审查	白盒测试和黑盒测试

白盒测试VS黑盒测试

	白盒测试	黑盒测试
定义	也称为结构测试，主要用于软件单元测试中。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作	黑盒测试也称为功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试，将程序看作是一个不透明的黑盒，完全不考虑（或不了解 ）程序的内部结构和处理算法，而只检查程序功能是否能按照SRS的要求正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息（例如文件和数据库等）的完整性等。
方法	逻辑覆盖（包括语句、判定、条件、条件/判定、条件组合、正的条件/判定、路径）	等价类划分、边界值分析、判定表、因果表、状态图、随机测试、猜错法和正交试验法。

测试类型

类别	内容
单元测试	也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO类软件的类（统称为模块）。目的是检查每个模块能否正确地实现设计说明的内容，发现模块内可能存在的各种差错。
集成测试	目的是检测模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。
确认测试	用于验证软件的功能、性能和其他特性否与用户需求一致
系统测试	系统测试的对象是完整的、集成的计算机系统。目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。
配置项测试	对象是软件配置项。目的是检测软件配置项与SRS的一致性。
回归测试	目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

确认测试类型

确认测试根据用户的参与程度，包括：

1. 内部确认测试主要由软件开发组织内部按照SRS进行测试。
2. Alpha测试和Beta测试。

• Alpha测试是指由用户在开发环境下测试；
• Beta测试是指用户在实际使用环境下测试。

3. 验收测试是指针对SRS，在交付前以用户为主进行的测试。其测试对象为完整的、集成的计算机系统。哈哈哈哈哈的是在真实的用户工作环境下，检验软件系统能否满足开发技术合同或SRS。结论是用户确定是否接收该软件的主要依据，项目能不能正确验收。

回归测试的对象

• 未通过软件单元测试的软件，在变更之后，应对其进行单元测试；
• 未通过配置项测试的软件，在变更之后，首先应对变更的软件进行单元测试，然后再进行相关的集成测试和配置项测试；
• 未通过系统测试的软件，在变更之后，首先应对变更的软件进行单元测试，然后再进行相关的集成测试、配置项测试和系统测试；
• 因其他原因进行变更之后的软件单元，也首先应对变更的软件进行单元测试，然后再进行相关的软件测试；

面向对象的测试

1. OO系统的测试目标与传统信息系统测试目标是一致的，测试的焦点是类，以及测试的视角扩大到了分析和设计模型。
2. OO系统具有三个明显的特征。

• 封装性决定了OO系统的测试必须考虑到**信息隐蔽原则 **对测试的影响，以及对象状态与类的测试序列；
• 继承性决定了OO系统的测试必须考虑到继承对测试充分性的影响，以及误用引起的错误；
• 多态性决定了OO系统的测试必须考虑到多态绑定对测试充分性的影响、抽象类的测试、以及误用对测试的影响。

软件调试

1. 软件调试（排错）。测试成功的标志是发现了错误，根据错误迹象确定氐的原因和准确位置，并加以改正，主动依靠软件调试技术。软件调试策略可分为蛮力法、回溯法和原因排除法三类。

• 蛮力法
  是分离软件错误原因最常用也是最低效的方法。当所有的其他方法都失败的情况下，才使用这种方法。利用『让计算机自己找错误』的思想，进行内存转储，激活运行时跟踪，以及在程序中加载大量的输出语句（例如不同断点不同错误提示），以期望在所产生的大量信息里可以找到错误原因的线索。尽管大量的信息可能最终导致成功，但是浪费了精力和时间，还是要以分析为主。
• 回溯法
  是比较常用的调试方法，可以用于比较轻量级的软件中，从发现症状的地方开始，向后手工追踪源代码，直到发现错误的原因，随着代码量的增加，潜在回溯路径可能会增加到难以控制的地步。
• 原因排除法
  是通过演绎和归纳 并引入二分法的概念来实现。对于错误出现相关的数据加以组织，以分享出潜在的错误原因。假设一个错误原因，利用得到的数据证明或反对这个假设。或者先列出所有可能的原因，再执行测试逐个排除。

2. 软件调试与测试的区别如下表：

	软件调试	软件测试
目的	定位错误并修改错误以修正错误	找出存在的错误
顺序	测试之后的活动	调试之前的活动
进度	不能描述过程或持续时间	事先设定，事先确定

软件测试管理

软件测试的管理包括过程管理、配置管理和评审工作。

• 过程管理。 其包括测试活动管理和测试资源管理；
• 配置管理。应按照软件配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。
• 评审。测试过程中的魔道祖师包括测试就绪评审、测试评审。
• 

软件集成技术

表示集成

表示集成也称为界面集成，比如原始和最浅层次的集成。这种方法将用户界面作为公共的集成点，把原有零散的系统界面集中在一个新的界面中。它是黑盒集成。

数据集成

数据集成：为了完成控制集成和业务流程集成，必须首先解决数据和数据库的集成问题。它是白盒集成，比表示集成要更加灵活。但是当业务逻辑经常发生变化时，数据集成就会面临困难。

*数据集成一般是从中间件开始。

控制集成

控制集成也称功能集成或应用集成，是在业务逻辑上对应用系统进行集成的。实现控制集成时，可以借助于远程过程调用或远程方法调用、面向消息中间件、分布式对象技术和事务处理监视器来实现。控制集成与表示集成、数据集成相比，灵活性更高。表示集成和数据集成适用的环境下，都适用于控制集成。控制集成是黑盒集成。

业务流程集成

业务流程集成，也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准的、统一数据格式的工作流组成。它包括应用集成、B2B集成、自动化业务流程管理、人工流程管理、企业门户，以及对所有应用系统和流程的管理和监控等。

企业之间的应用集成（EAI）

企业之间的应用集成，EAI技术可以适用于大多数要实施电子商务的企业，以及企业之间的应用集成。EAI使得应用集成架构里的客户和业务伙伴，都可以通过集成供应链内所有应用和数据库实现信息共享。