软件工程笔记

1 软件与软件工程

1.1 软件与软件工程

1.1.1 软件工程的概念

软件是计算系统中与硬件相互依存的另一部分，它包括程序、数据以及相关文档的完整集合。

软件=知识+程序+数据+文档

• 数据：使程序能适当处理信息的数据结构

• 程序：能够完成预定功能和性能的可执行指令序列

• 文档：开发、使用和维护过程程序所需要的图文资料

1.1.2 软件工程的概念

采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，经济的开发出高质量的软件并维护它

1.1.3 软件的质量要素

• 正确性

• 可用性

• 可靠性

• 有效性

• 可维护性

• 可移植性

• 安全性

• 可复用性

1.2 软件的生命周期⭐

软件生命周期：

• 软件定义

• 问题定义

• 可行性研究

• 需求分析

• 软件开发

• 总体设计

• 详细设计

• 编码和单元测试

• 综合测试

• 软件维护

• 运行维护

1.3 软件的开发方法

1.3.1 结构化方法

按照系统的功能模型自顶向下，逐步求精，最终得到组成系统的模块及其控制关系。强调层次性、模块化、强调顺序、选择、重复3种基本结构，强调模块的单入口，单出口，限制GOTO语句的使用等。

1.3.2 面向对象方法

将对象的属性和操作封装到一起，支持软件开发的模块化可复用和信息隐蔽。是的分析、设计、实现和测试获得连接自然、便捷，提高了软件的开发效能。

1.3.3 形式化开发方法

以软件开发的正确性为目标，软件需求规约用形式化需求规约语言描述，如VDM的META-IV。CSP，Z语言。形式化方法可以有效解决歧义性、完整性、一致性、安全性等问题，依靠严格的数学推理，保证软件开发的正确性

1.4 软件过程⭐

软件过程：是为获得高质量软件所需要完成的一系列任务框架。通常用软件生命周期模型描述软件过程

主要包括：

• 瀑布模型

• 快速原型模型

• 增量模型

• 螺旋模型

• 喷泉模型

• 其他模型

1.4.1 瀑布模型

将软件生命周期的各项活动规定为依照固定顺序连接的若干阶段工作，最终得到软件产品

• 特点

• 阶段间具有顺序性和依赖性

• 推迟实现的观点

• 质量保证的观点

• 每个阶段必须完成规定的文档

• 每个阶段结束前完成文档审查

• 及时修改错误

• 优点

• 强迫开发人员采用规范的方法

• 严格规定了每个阶段必须提交文档

• 要求规定了每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

• 缺点

• 在软件开发初期就要求正确全面完整的需求分析很难

• 需求分析阶段很难验证需求分析的是否正确

• 不支持唱片的演化，缺乏灵活性，从而难以维护

1.4.2 快速原型模型

快速建立可运行的程序它完成的功能往往是最终产品功能的子集

相较于瀑布模型，多了一步创建快速模型，并且对每一步都添加了测试维护

• 优点

• 开发的软件产品通常满足用户需求

• 软件产品开发基本上线性

• 缺点

• 准确原型设计困难

• 原型立即可能不同

• 不利于开发人员创新

1.4.3 增量模型

先完成一个系统子集的开发，再按同样步骤增加功能，直到完成全部功能

• 优点

• 短时间内可提交完成部分功能

• 逐渐增加产品功能，用户适应产品快

• 缺点

• 增量构建划分以及集成困难

• 容易退化为边做边改模型

1.4.4 螺旋模型

就是在快速原型模型的基础上添加了风险分析

• 优点

• 利于把软件质量作为软件的开发目标

• 减少测试

• 维护开发不分离

• 缺点

• 风险估计困难

1.4.5 喷泉模型

典型的面向对象软件过程模型。体现迭代和无缝特性

1.5 敏捷开发

1.5.1 开发原则

1. 人员和交互胜过过程和工具

2. 可以工作的软件胜过面面俱到的文档

3. 与客户合作胜过合同谈判

4. 响应变更胜过遵循计划

1.5.2 实践

1. 完整的团队

2. 增量式规则

3. 客户参与全过程

4. 简单设计

5. 结对编程

6. 测试驱动开发

7. 适时重构

8. 持续集成

9. 代码集体所有

10. 其他

2 UML⭐

• 通用的可视化的建模语言

• 目前在软件工程里主要用于系统分析与系统设计

• 软件生存周期：RUP（统一过程）

• 软件建模方式：可视化的语言

• 软件文档规范：文档由UML建模工具自动产生

• 软件人员分工：岗位界面逐渐趋向模糊

用例视图：

从外部用户的角度描述系统的功能，并指出参与者

• 用例图

结构视图：（静态结构）

从不同的层面表示系统的静态结构

• 包图

• 类图

• 对象图

行为视图：（动态结构）

从不同的侧面刻画系统的动态行为

• 状态图

• 活动图

• 交互图

构件视图：

描述软件系统中各个组件、构建的内部结构以及构件间的依赖关系

• 构件图

部署视图：

描述软件系统的各个类工件在物理运行环境中的分布情况

• 部署图

2.1 用例图

• 包含:如果B是A的某项子功能，并且建模者确切地知道在A所对应的动作序列中何时将调用B，则称用例A包含用例B。

• 扩展:如果A与B相似，但A的功能较B多，A的动作序列是通过B的动作序列中的某些执行点上插入附加动作序列而构成的，则称用例A扩展用例B。

• 继承(泛化):如果A与B相似，但A的动作序列是通过改写B的部分动作或者扩展B的部分动作而获得的，则称用例A继承用例B。

2.2 类图

【【有翻译】10 分钟学会 UML 类图（UML Class Diagram Tutorial）】 https://www.bilibili.com/video/BV1P741127u7/?share_source=copy_web&vd_source=34be3dc39becda21baf2fd46b7d99d54

2.3 时序图

3 需求工程概述

3.1 需求工程的过程模型

1. 需求工程策划

2. 需求获取

3. 需求分析

4. 需求规范化

5. 需求验证

6. 总结

3.2 ER图⭐

和数据库原理一样

• 实体：描述数据对象。

• 属性：描述数据对象的性质。

• 联系：描述数据对象之间的交互方式

3.3 状态转换图⭐

• 状态：系统的行为模式， 包括初态、终态、中间状态。

• 事件：是指在某个特定时刻发生的事情， 即对系统从—个状态转换到另—个状态的事件抽象。

• 在—张状态图中只能有一个初态而终态可以有0至多个。

4 需求获取

4.1 用例图⭐

参考上面的UML用例图

4.2 类图⭐

参考上面的UML类图

4.3 需求获取模型

1. 定义软件问题

2. 创建框架

3. 精化用例

4. 评审用例模型

5 需求分析验证

5.1 顺序图⭐

参考上面UML顺序图

5.2 设计分析类

5.2.1 边界类

负责目标软件系统与外部执行者之间的交互，包括以下部分：

• 界面控制

• 外部接口

• 环境隔离

5.2.2 控制类

作为完成用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为

5.2.3 实体类

负责保存目标软件系统中具有持久意义的信息项并向其他类提高信息访问的操作

5.3 导出分析类图

按照需求牵引的观点，分析类的职责源于其必须响应、处理的消息。即对消息的响应构成作为消息接收者的分析类对象的职责

步骤：

1. 创建初始化的分析类图

2. 根据消息确定分析类的职责

3. 根据消息传递确定分析类之间的连接

4. 根据交互图确立分析类的属性

5. 整理分析类图

5.4 需求规约

5.4.1 目标

1. 便于利益相关方、需求工程师和软件设计人员进行理解和交流

2. 支持目标软件系统的确认

3. 控制系统进化过程

5.4.2 内容

1. 系统概述

• 文档概况

• 术语定义

• 系统概述

• 目标软件

• 用户特征

• 假设与依赖

• 参考文献

2. 功能性需求

3. 质量需求

4. 约束性需求

5. 需求优先级

6. 接口定义

7. 需求验收标准

8. 需求来源表

6 软件设计概论

原则包括抽象、逐步求精、强内聚、松耦合、信息隐藏及关注点分离

• 抽象

• 抽出事务的本质特性而暂时不考虑它们的细节。

• 逐步求精

• 逐步揭露出底层细节。

• Miller法则：注意力集中在(7 士2)上

• 模块化

• 模块：能够单独命名， 由边界元素限定的程序元素的序列， 是构成程序的基本构件。

• 模块化：把程序划分成独立命名且可独立访问的模块， 每个模块完成—个子功能把这些模块集成起来构成—个整体， 可以完成指定的功能满足用户的需求。

• 信息隐藏与局部化

• 信息隐藏：指—个模块内包含的信息对于不需要这些信息的模块来说， 是不能访问的。主要是指模块的实现细节。

• 局部化：指把—些关系密切的软件元素物理地放得彼此靠近， 它有助于实现信息隐藏。

• 模块独立

• 模块独立性：是模块化、抽象、信息隐蔽和局部化概念的直接结果。

• 模块独立是好设计的关键， 设计是决定软件质量的关键环节。

• 度量标准耦合、内聚

• 耦合⭐

• 耦合是对一个软件结构内不同模块之间互连程序的度量。耦合强度取决于模块接口的复杂程度、 通过接口的数据等耦合性越高 模块独立性越弱。

• 耦合分类（程度从低 ——> 高）

• 非直接耦合：两个模块不相互依赖

• 数据耦合与控制耦合：两个模块通过参数交换信息，如果这些信息不影响模块的功能活执行路径则是数据耦合否则是控制耦合

• 外部耦合：与外部设备活外部环境相关联

• 公共耦合：若干模块通过公共的数据环境相互作用

• 内容耦合：两模块的业务逻辑处理线索相互交织

• 内聚⭐

• 是用来度量—个模块内部各个元素彼此结合的紧密程度的。

• 内聚分类（程度从低 ——>高）

• 偶然性内聚

• 逻辑性内聚

• 时间性内聚

• 过程性内聚

• 过程性内聚

• 通信性内聚

• 顺序性内聚

• 功能性内聚：

软件设计目标高内聚、 低耦合

7 软件体系结构设计

7.1 体系结构视图

1. 逻辑视图：体系结构中各个软件模块的逻辑功能划分，以及基于这种划分的协作行为。

2. 开发视图：软件源代码的程序分包及目录结构，采用的类库、中间件或框架，他们与逻辑视图中各个模块间的映射关系

3. 物理视图：按照部署的物理及其及其忘了连接，逻辑视图及开发视图中模块或程序包的物理部署位置。

4. 运行视图：软件运行时进程、线程的划分，它们之间的并发与同步，瞬时快照——软件运行过程中某个特定时刻活跃的对象及其协作关系，以及他们与逻辑视图和开发视图之间的映射关系

5. 数据视图：持久数据的存储方案，数据传递，备份，恢复，同步方案与物理视图之间的映射关系

7.2 体系结构精化

逻辑视图体系结构的精化过程：

1. 搜索并选取可用的设计资产

2. 设计技术支撑设施

3. 确立设计元素

4. 整合设计元素

8 人机交互设计

8.1 用户界面设计模型的表示

1. 静态元素

2. 动态元素

3. 用户输入元素

4. 用户命令元素

8.2 用户界面UML类图

参考2.2

9 软件详细设计

9.1 用例设计

用例设计的主要任务：

1. 针对每个用例，采用体系结构设计中确定软件设计元素，以及用户界面设计中确定界面类，完整地实现每个用例要求的业务处理和交互动作序列。

2. 详细考察每个设计元素与其协作者之间的协作关系，以求更精确地定义这些设计元素，如补齐必要的细节、调整接口定义等。

9.2 确定类之间的连接关系

1. 引用全局对象

2. 通过参数传递对象

3. 引用局部对象

4. 通过类的成员变量

10 软件实现

软件实现的任务：设计和编写子类程序、类模块，创建数据类型并命名变量，选择控制结构并组织语句块，找出缺陷并通过条hi是进行修正，对代码的细节设计进行评审，通过走查和证据以及来改进变编码，对代码等实现结果试试配置管理，对分别万的软件结果单元进行集成，调整编码使其更简洁、高效

11 结构化软件开发

11.1 数据流图⭐

描述信息流和数据从输入到输出过程所经受的变换。 没有任何具体物理部件，只是描绘数据在软件中流动和被处理的逻辑过程

常用符号：

画法：

1. 确定系统的输入输出、源点以及终点

2. 画系统顶层数据流图

3. 自顶向下分解，画出分层数据流图

11.2 数据字典⭐

是关于数据的信息集合，即对数据流图中包含的所有原始定义的集合

数据字典的内容：数据流、 数据流分量（数据元素）、 数据存储、 处理。

12 软件测试

12.1 软件测试原则

1. 测试时一个持续进程的过程，不是一个阶段

2. 测试一定有计划、受控制，并提供足够的时间和资源

3. 测试应当分优先级

4. 测试应当有重点

5. 测试不是为了证明程序正确性，而是为了证明程序不能工作

6. 测试时不可能穷尽的，当测试充分性满足时就可停止测试

7. 测试是开发的朋友不是敌人

8. 测试人员应该公正地测试，如是记录和报告缺陷

9. 测试自动化能够解决一部分问题而不是全部

10. 测试不能仅仅包括功能性验证，还应包括性能、可靠性、可维护性和安全性等方面的验证

12.2 软件测试过程

1. 单元测试：主要测试单元内部的数据结构起辑控制、是常处理等。

2. 综合测试（集成测试）：主要测试模块之间的接口和接日数据传递关系，以及模块组合后的整体功能，即既要验证”设计“，又要验证”需求。

3. 确认测试（验证测试）：在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一一个阶段， 也称为交付测试。

4. 系统测试：主要测试整个系统相对于需求的符合度。

12.3 软件测试方法

12.3.1 白盒测试⭐

根据程序内部的逻辑结构测试程序内部的主要执行通路是否能够按照预定的要求正确工作。

测试用例：测试输入数据和预期的输出结果。

测试方案：测试目的、 测试用例的集合。

• 语句覆盖：被测试程序中的每条语句至少执行—次。

• 判定覆盖：使得被测程序中每个判定表达式至少获得—次真值和假值

• 条件覆盖：使得判定表达式中每个条件的各种可能的值至少出现—次。

• 判定／条件覆盖：使得判定表达式中的每个条件的所有可能取值至少出现—次， 并使每个判定表达式所有可能的结果也至少出现—次。

• 条件组合覆盖：设计足够多的测试用例， 使得每个判定表达式中条件的各种可能的值的组合都至少出现—次。

• 路径覆盖：覆盖被测程序中所有可能的路径。

12.3.2 黑盒测试⭐

将软件看作一个黑盒子, 不考麒内部结构和处理过程，只按照规格说明书的规定,测试软件是否能够正确接收输入数据,产正确的输出数据

等价类划分法⭐

1. 把程序的输入数据集合按输入条件划分为若干个等价类， 每—个等价类相对千输入条件表示为—组有效或无效的输入。

2. 为每—等价类设计—个测试用例。

边界值分析法

输入等价类和输出等价类的边界就是应该着重测试的程序边界清况。选取的测试数据应该刚好等于、刚好小于、刚好大于边界值

13 软件维护

• 定义：为了改正错误或满足新的需要而修改软件的过程。

• 分类：

• 改正性维护:软件中肯定隐藏着某些未被发现的错误，在使用过程中发现了隐藏的错误后，诊断和改正这些隐藏错误而修改软件的活动。

• 适应性维护:为了适应变化的环境而修改软件的活动

• 完善性维护:为扩充或完善原有软件的功能或性能而修改软件的活动

• 预防性维护:把今天的方法学用于昨天的系统以满足明天的需要

• 特点：

• 结构化维护与非结构化维护差别巨大，维护的代价高昂，维护的问题很多

• 非结构化维护:软件配置的唯一成分只有代码

• 结构化维护:有完整的软件配置存在

• 软件再工程过程

1. 库存目录分析

2. 文档重构

3. 逆向工程

4. 代码重构

5. 数据重构

6. 正向工程

• 维护工作流

14 持续集成

14.1 持续集成的概念

持续集成是当前一种广为采纳的软件开发实践，它鼓励团队中的开发者尽早将自己的阶段性新成功集成至目标软件产品的某个版本，以便尽早暴露项目中存在的缺陷

持续集成的核心思想是领域各种工具将软件系统的构造、测试、代码质量分析、发布、部署都能工作任务简便化、自动化、加速从代码修改到新版软件上线运行的全过程

14.2 持续集成的步骤

1. 提交代码

2. 触发集成

3. 持续集成

4. 发送通知

15 软件规模度量

15.1 代码行度量

适用于软件的实现过程，软件开发的初期

用项目的代码行表示软件项目的规模，代码行数可以用人工或软件工具直接测量。

15.2 功能点度量

适用于软件的设计过程，软件系统概要设计阶段或软件体系结构设计阶段

依据对软件信息域特性和软件复杂性的评估结果估算软件规模。以功能点为单位进行度量

15.3 对象点度量

适用于软件的需求过程，软件开发的初始阶段

对象点度量软件的要素是面向对象系统的实体个数；元素链的长度；交付客户端系功能

16 软件项目管理

定义：指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内有效地利用力资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。软件项目管理的对象主要包括产品,过程和资源

软件配置管理：

• 目的：减少回来，提高软件的生产效率

• 概念：对软件修改进行标识，组织辉夜控制的技术，用来协调和控制整个系统的过程