文集：《35 小时通关软考高项》
上篇：《1.3 信息系统开发方法》
下篇：《1.5 新一代信息技术》

---

章节概要

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的事故提高软件生产率、提高软件质量、降低软件成本。

软件需求 ，是指用户解决问题或达到目标所需的条件或能力的文档说明，分为三个层次（细分细分再细分）：

1. 业务需求：指反映企业或客户对系统高层次的目标要求。

2. 用户需求：描述的是用户的具体目标，或用户要求系统必须完成的任务。

3. 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

然后介绍了软件需求的分类，所使用的技术，如何获取，如何分析，如何验证，有哪些工具等。

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

解决好软件的复用、质量和维护问题是研究软件架构的根本目的，也是其核心问题。

软件设计 ，分为结构化设计（SD）与面向对象设计（OOD）

• SD：一种面向数据流的方法，自项向下，逐步求精和模块化的过程

• OOD：基本思想包括抽象、封装和可扩展性，其中可扩展行主要通过继承和多态来实现

软件工程的过程管理 ，有两种模型：阶段式模型和连续式模型

软件测试及其管理，每个测试用例应包括名称和标识、测试追踪、用例说明、测试的初始化要求、测试的输入、期望结果、评价测试结果准则、操作过程、前提和约束、测试终止条件。

软件集成技术，企业应用集成（EAI）：

1. 表示集成

2. 数据集成

3. 控制集成

4. 业务流程集成

5. 企业之间的应用集成

考点

系统需求的三个方面

1. 功能需求：规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。

2. 非功能需求：指系统必须具备的属性或品质，又可细分为软件的质量（可维护性、效率，健壮性等）。

3. 设计约束：一些开发的限制条件（如：必须在 UNIX 系统下运行等）。

质量功能部署（QFD）

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

1. 常规需求：用户认为系统应该做到的功能或性能

2. 期望需求：用户想当然认为系统应具备的功能或性能，但用户并不能正确描述的需求

3. 意外需求：用户要求范围外的功能或性能

需求获取

是一个确定和理解不同的项目干系人的需求和约束的过程。常见的方法包括：用户访谈、问卷调查、采样、情节串联板和联合需求设计等。

需求分析

一个好的需求应具备无二性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特征，把杂乱无章的用户要求和期望转化为用户需求。

其分析方法为 SA 法，其建立的模型的核心是数据字典，总共分为三个层次模型：

1. 数据模型：实体联系图（E-R 图）

2. 功能模型：数据流图（DFD）

3. 行为模型：状态转换图（STD）

软件需求规格说明书（SRS）

编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同理解，使之成为整个开发工作的基础。在国际标准 GB/T 8567-2006 规定必须包含以下内容：

1. 范围

2. 引用文件

3. 需求

4. 合格性规定

5. 需求可追踪性

6. 尚未解决的问题

7. 注解

8. 附录

需求验证

为了保证 SRS 的正确性，减少不必要额度修补工作，一般采用以下几个需求验证：

1. SRS 正确地描述了预期的、满足项目干系人需求的系统行为和特征

2. SRS 的需求是从系统需求、业务规格和其他来源中正确推导而来的

3. 需求是完整的和高质量的

4. 需求的表示在所有地方都是一致的

5. 需求为继续进行系统设计 、实现和测试提供了足够的基础

实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。

统一建模语言 - UML

支持从需求分析开始的软件开发的全过程，包括构造块（事物、关系、图）、规则和公共机制，是一种可视化的建模语言。

事物：结构事物、行为事物、分组事物、注释事物

关系：依赖、关联、泛化、实现

在 UML 2.0 标准中包括了 14 种图（加粗为动态视图）：

1. 类图：描述一组类、接口、协作和他们之间的关系，是最常见的视图，也称为静态设计视图。

2. 对象图：描述一组对象及它们之间的关系。

3. 构件图：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。

4. 组合构件图：描述结构化类（构件或类）的内部结构。

5. 用例图：描述一组用例、参与者及它们之间的关系。

6. 顺序图：是一种交互图（序列图），它由一组对象或参与者以及它们之间可能发送的消息构成。

7. 通信图：也是一种交互图，它强调收发消息的对象或参与者的结构组织。

8. 定时图：它强调消息跨越不同对象或参与者的实际时间。

9. 状态图：描述一个状态机，它由状态、转移、事件和活动组成，是对象的动态视图。

10. 活动图：将进程或其他计算机结构展示为计算内部一步步的控制流和数据流，对系统的功能建模和业务流程建模特别重要。

11. 部署图：描述对运行时的处理节点及在其中生存的构件配置。

12. 制品图：描述计算机中一个系统的物理结构。

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

14. 交互概览图：是活动图和顺序图的混合物。

UML 五个系统视图

1. 逻辑视图：即设计视图，表示了设计模型中在架构方面具有重要意义的部份。

2. 进程视图：是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例。

3. 实现视图：对组成基于系统的物理代码的文件和构件进行建模。

4. 部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

5. 用例视图：是最基本的需求分析模型。

面向对象分析（OOA）

运用 OO 方法，对问题域进行分析和理解，最终产生一个符合用户需求的模型。

• OOA（面向对象分析）的任务是“做什么”

• OOD（面向对象设计）的任务是“怎么做”

• 面向对象分析阶段的核心工作是建立系统的用例模型与分析模型

用例之间的主要关系：

1. 包含关系：可以从两个或两个以上的用例中提取公共行为

2. 扩展关系：一个用例可能产生多种分支

3. 泛关系：将它们的共性抽象成为父用例

类之间的六种主要关系

类之间的关系表示

聚合关系又名共享关系，部分与整体的生命周期可以不同，而组合聚集的生命周期相同

五类软件架构风格

1. 数据流风格：包括批处理序列和管道/过滤器两种风格

2. 调用/返回风格：包括主程序/子程序、数据抽象和面向对象，以及层次结构

3. 独立构件风格：包括进程通信和事件驱动的系统

4. 虚拟机风格：包括解释器和基于规则的系统

5. 仓库风格：包括数据库系统、黑板系统和超文本系统

软件架构评估

• 评估人员所关注的是系统的质量属性

• 敏感点：是一个或多个构件的特性

• 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点

评估技术分为三类：

1. 基于调查问卷

2. 基于场景的方式（常用）

3. 基于度量的方式

软件设计

• SD：高内聚、低耦合，模块间低耦合、模块内高聚集。

• OOD：提高软件的可复用性是一个至关重要的问题。

OOD 原则：

1. 单一职责原则

2. 开放-封闭原则

3. 李氏替换原则

4. 依赖倒置原则

5. 接口隔离原则

6. 组合重用原则

7. 迪米特原则

设计模式

根据处理范围不同：

• 类模式：处理类和子类之间的关系，通过继承建立的静态关系

• 对象模式：处理对象之间的关系的动态关系

根据目的和用途不同：

• 创建型模式：创建对象

• 结构型模式：处理类或对象的组合

• 行为型模式：描述类或对象的交互以及职责的分配

软件工程的过程管理

阶段式模型

连续式模型

软件测试方法

• 静态测试：测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析，对文档和代码桌前检查、代码走查和代码审查。

• 动态测试：在机器上直接运行程序，分为白盒测试（调试）和黑盒测试（功能测试），等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法。

按过程分类：

1. 单元测试：模块测试，依据是软件详细设计说明书

2. 集成测试：验证模块之间，依据是软件概要说明书

3. 确认测试：用于验证软件的功能、性能和其他特性是否与用户需求一致（内部确认测试、Alpha 测试、Beta 测试、验收测试、系统测试、配置项测试、回归测试）