@[TOC](1.4 软件工程)

本节重要考点：

• 需求分析
• 软件测试
• 软件质量保证及评价
• 软件设计
• 面向对象及UML等
• CMMI

一、需求分析

1. 层次

• 业务需求：确定项目试图和范围
• 用户需求：具体目标，系统必须完成的任务
• 系统需求：功能需求、非功能需求和设计约束
  包括功能需求、非功能需求和设计约束

2. 质量功能部署

是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程中用户的满意度。分为三类：

• 常规需求：实现越多用户越满意
• 期望需求：如果没有得到实现，会让用户不满意
• 意外需求：用户要求范围外的功能或性能

3. 需求获取

确定和理解不同的项目干系人的需求和约束过程

4. 需求分析

应具备无二义性、完整性、一致的、可测试的、确定的、可跟踪的、正确的、必要性等特性。

5. 软件需求规格说明书

（software Requirement specification，SRS）
是软件开发过程中最重要的文档之一，对任何规模和性质的软件项目都不应该缺少。
应包括以下内容：

• 范围
• 引用文件
• 需求
• 合格性规定
• 需求和追踪性
• 尚未解决的问题
• 注解
• 附录

6. 需求验证

主要通过需求评审和需求测试来验证。为了确定以下几个方面的内容：

• SRS正确的描述了预期的、满足项目干系人大需求的系统行为和特征
• SRS中的软件需求是从系统需求、业务规格和其它来源中正确推导而来的
• 需求是完整和高质量的
• 需求的表示在所有地方都是一致的
• 需求为继续进行系统设计、实现和测试提供了足够的基础

7.UML

统一建模语言（Unified Modeling Language，UML）
支持从需求分析开始的软件开发的全过程
独立于开发语言的，它不是可视化的程序设计语言，而是一种可视化的建模语言。

UML 2.0 包括14种图，分别列举如下：
(1) 类图(class diagram) ：类图描述一组类、接口、协作和它们之间的关系。在OO系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。

(2) 对象图(object diagram) ：对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

(3) 构件图(component diagram) ：构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。

(4) 组合结构图(composite structure diagram) ：组合结构图描述结构化类(例如，构件或类)的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。

(5) 用例图(use case diagram) ：用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。

(6) 顺序图(sequence diagram， 也称序列图) ：顺序图是一种交互图(interaction diagram) ， 交互图展现了一种交互， 它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。

(7) 通信图(communication diagram) ：通信图也是一种交互图， 它强调收发消息的对象或参与者的机构组织。顺序图强调的是时序，通信图强调的是对象之间的组织结构。

(8) 定时图(timing diagram， 也称计时图) ：定时图也是一种交互图， 它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

(9) 状态图(state diagram) ：状态图描述一个状态机， 它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。

(10) 活动图(activity diagram) ：活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。

(11) 部署图(deployment diagram) ：部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。

(12) 制品图(artifact diagram) ：制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。

(13) 包图(package diagram) ：包图描述由模型本身分解而成的组织单元， 以及它们之间的依赖关系。

(14) 交互概览图(interaction overview diagram) ：交互概览图是活动图和顺序图的混合物。

UML视图：

视图	内容	主要使用者
逻辑视图	也称设计视图，表示了设计模型中架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集	设计人员和开发人员
进程视图	它是逻辑视图的一次执行实例	开发人员、系统集成人员
实现视图	基于系统的物理代码的文件和构建进行建模	开发人员
部署视图	把构建部署到一组物理节点上，表示软件到硬件的映射和分布结构	开发人员、系统集成人员、测试人员
用例视图	最基本的需求分析模型	需求人员和用户

8.面向对象分析

OOA的基本任务是运用OO方法， 对问题域进行分析和理解， 正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。

OOA模型独立于具体实现， 即不考虑与系统具体实现有关的因素， 这也是OOA和OOD的区别之所在。OOA的任务是“做什么”， OOD的任务是“怎么做”。

（1）用例模型：用例方法是一种需求合成技术。在OOA方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者，合并需求获得用例，细化用例描述和调整用例模型，其中前三个阶段是必需的。

用例之间的关系主要有包含、扩展和泛化。
包含关系：比如修改、删除和查看个人信息，都包含查找个人信息，因为修改、删除、查看是包含关系
扩展关系：比如系统允许用户对查询结果进行导出、打印。导出、打印和查询相对独立，且为查询添加了新行为，因此可用扩展关系来描述。
泛化关系：业务中可能存在许多需要部门领导审批的事情，如工资审批、人事审批，此时这些审批可以做成泛化关系表示。
用例关系说明：

注意：组合（不可分离）更紧密，聚合（可分离）更松散

补充知识点

面向对象的基本概念：

• 对象：由数据及其操作所构成的封装体，是系统中用来描述客观事物的一个模块，是构成系统的基本单位。由一组属性和操作构成。包含三个基本要素，分别是对象标识、对象状态和对象行为。
• 类：现实世界中实体的形式化描述，类将该实体的属性（数据）和操作（函数）封装在一起。类和对象的关系可理解为，对象是类的实例，类是对象的模板。如果将对象比作房子，那么类就是房子的设计图纸。
• 抽象：通过特定的实例抽取共同特征以后形成概念的过程。抽象是一种单一化的描述，强调给出与应用相关的特性，抛弃不相关的特性。对象是现实世界中某个实体的抽象，类是一组对象的抽象。
• 封装：将相关的概念组成一个单元模块，并通过一个名称来引用它。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或者修改只能通过对象对外提供的接口进行
• 继承：表示类之间层次关系（父类与子类），这种关系使得某类对象可以继承另外一类对象的特征，继承又可分为单继承和多继承
• 多态：使得在多个类中可以定义同一个操作或属性名，并在每个类中可以有不同的实现
• 接口：说明操作该做什么
• 消息：体现对象间的交互，通过发消息请求操作
• 组件：封装模块功能的实现，是内聚的，并具有相对稳定的公开接口
• 复用：将已有的软件机器有效成分用于构造新的软件或系统，组件技术是软件复用实现的关键
• 模式：描述了一个不断发生的问题，以及该问题的解决方案。其包括特定环境、问题和解决方案三个组成部分。应用设计模式可以更加简单和方便的去复用成功的软件设计和架构，从而帮助设计者更快更好的完成系统设计。

二、软件架构设计

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用(连接件)、指导构件集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。

软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

软件架构风格

核心问题是能否达到架构级的软件复用。

• 数据流风格：包括批处理序列（顺序执行）和管道/过滤器（输入输出数据流）
• 调用/返回风格：包括主程序/子程序、数据抽象和面向对象以及层次结构
• 独立构件风格：包括进程通信（消息传递、远程调用）和事件驱动（事件触发调用）
• 虚拟机风格：包括解释器（解释引擎）和基于规则（规则集）
• 仓库风格：数据库系统（中央共享数据源）、黑板系统（知识源、黑板及共享数据和控制）和超文本系统（非线性交叉引用）

三、软件设计

分为结构化设计（SD）和面向对象设计（OOD)

1. SD

面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。
在SD中，需要遵循一个基本的原则：高内聚，低耦合

2. OOD

主要任务是对类和对象进行设计，包括类的属性、方法，以及类与类之间的关系。OOD的结果就是设计模型，对于OOD而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提高软件的可维护性和可复用性，是OOD需要解决的核心问题之一。

3.设计模式

设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
根据处理范围不同，可分为类模式（静态关系）和对象模式（动态性）
根据目的和用途不同，可分为创建型模式（创建对象）、结构型模式（处理类或者对象的组合）和行为型模式（描述类或对象的交互及职责分配）

四、软件工程的过程管理

CMMI --> Capability Maturity Model Integration 软件能力成熟度集成模型，是一种为组织的有效过程提供基本要素的过程改进方法，其目的是帮助软件企业对软件工程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
CMMI继承了CMM的阶段表示法和EIS/IS731的连续式表示法。

1. 连续式模型

在这里插入图片描述

2.阶段式模型

在这里插入图片描述

这两种表示方法在逻辑上等价，得出的结论应该是相同的。

五、软件测试以及管理

1. 测试方法

可分为静态测试和动态测试

• 静态测试：不运行程序，采用人工检测和计算机辅助静态分析的手段对程序进行检测。使用这种方法能够有效发现30%~70%的逻辑设计和编码错误。
• 动态测试：实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。
  白盒测试：看成透明的盒子里，完全了解程序的结构和处理过程，根据内部逻辑设计测试用例。
  黑盒测试：又叫功能测试，通过测试来检测每个功能是否都能正常使用。不考虑程序内部结构和内部特性。

2.测试类型

分为单元测试、集成测试、确认测试、系统测试、配置型测试和回归测试。

• 单元测试： 也叫模块测试，依据是软件详细设计说明书
• 集成测试：检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求，技术依据是软件概要设计文档
• 确认测试：确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。包括以下类型：
  内部确认测试：由软件开发组织内部按照SRS进行测试
  Alpha测试和Beta测试：Alpha测试是指由用户在开发环境下进行测试；Beta测试是指由用户在实际使用环境下进行测试，Beta测试通过后，才能把产品发布或交付给用户
  验收测试：指针对SRS，在交付前以用户为主进行的测试。应满足准入条件，且已通过系统测试。
  系统测试：在真实系统工作环境下，验证完整对的软件配置能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。依据是用户需求或开发合同。系统测试的主要内容包括功能测试，健壮性测试。性能测试，用户界面测试，安全性测试，安装与反安装测试。
  配置项测试：目的是检验软件配置项与SRS的一致性
  回归测试：目的是测试软件变更之后，变更部分的正确性和对变更需求的复合型，以及软件原有的、正确的功能、性能和其它规定的要求未受到损害。

六、软件集成技术

企业应用集成：Enterprise Application Integration，EAI
助记：表数控业

在这里插入图片描述