考分5-9分

1.4 软件工程

• 本节重要考点：
• 一、需求分析
• • 1. 三个层次
  • 2. 质量功能部署
  • 3. 需求获取
  • 4. 需求分析
  • 5. 软件需求规格说明书
  • 6. 需求验证
  • 7. UML
  • • UML五种视图
  • 8. 面向对象分析
  • • 用例关系说明
    • 类之间的主要关系
  • 补充知识点
• 二、软件架构设计
• • 五种软件架构风格
• 三、软件设计
• • 1. SD
  • 2. OOD
  • 3.设计模式
• 四、软件工程的过程管理（必考）
• • 1. 连续式模型
  • 2. 阶段式模型
  • CMMI的5个阶段层次
• 五、软件测试以及管理（必考）
• • 1. 测试方法
  • 2.测试类型
• 六、四种软件集成技术（必考）

本节重要考点：

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

一、需求分析

1. 三个层次

• 业务需求：反应客户对系统高层次的目标要求，通常来自项目投资人等；确定项目视图和范围
• 用户需求：用户的具体目标，用户要求系统必须完成的任务
• 系统需求：从系统的角度，包括功能需求、非功能需求和设计约束
  包括功能需求、非功能需求和设计约束

2. 质量功能部署

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

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

3. 需求获取

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

4. 需求分析

应具备无二义性、完整性、一致的、可测试的、确定的、可跟踪的、正确的、必要性等特性。把杂乱无章的用户要求和希望转化为用户需求说明书。

5. 软件需求规格说明书

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

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

6. 需求验证

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

• 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方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者，合并需求获得用例，细化用例描述和调整用例模型，其中前三个阶段是必需的。

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

用例关系说明

2. 阶段式模型

助记：表数控业