软件工程

软件过程模型

瀑布模型

【特点】

• 严格区分阶段，每个阶段因果关系紧密相连
• 只适合需求明确的项目

【缺点】

• 软件需求完整性、正确性难确定
• 严格串行化，很长时间才能看到结果
• 瀑布模型要求每个阶段一次性完全解决该阶段工作，这不现实

原型模型

适合需求不明确的项目

原型模型两个阶段

1. 原型开发阶段
2. 目标软件开发阶段

V模型

测试贯穿于始终，测试分阶段，测试计划提前

螺旋模型

以快速原型为基础+瀑布模型，考虑了风险问题

构建组装模型

【优点】 以扩展、易重用、降低成本、安排任务更灵活 【缺点】 构建设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标（如性能）、第三方构件质量难控制 【示例】 方舱医院、乐高积木

基于构件的软件工程（CBSE）

CBSE体现了【购买而不是重新构造】的哲学

【CBSE的构件应该具备的特征】

1. 可组装性：所有外部交互必须通过公开定义的接口进行
2. 可部署性：构件总是二进制形式的，能作为一个独立实体在平台上运行
3. 文档化：用户根据文档来判断构件是否满足需求
4. 独立性：可以在无其他特殊构件的情况下进行组装和部署
5. 标准化：符合某种标准化的构件模型

【构件的组装】

1. 顺序组装：按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件
2. 层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容
3. 叠加组装：多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口

统一过程

用例驱动、以架构为中心、迭代和增量

• 初始
  • 定义最终产品视图和业务模型
  • 确定系统范围
• 细化
  • 设计及确定系统架构
  • 指定工作技术啊及资源要求
• 构造
  • 开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试
• 移交
  • 确保软件对最终用户是可用的，进行测试，制作产品发布版本

生命周期

• 业务建模
• 需求
• 分析与设计
• 实现
• 测试
• 部署
• 配置与变更管理
• 项目管理
• 环境

敏捷方法

特点

• 适应性的
• 以人为本
• 增量迭代，小步快跑

敏捷方法

4大价值观

• 沟通【加强面对面沟通】

• 简单【不过度设计】

• 反馈【及时反馈】

• 勇气【姐搜变更的勇气】

• 极限编程：价值观【交流、朴素、反馈、勇气】、近螺旋式的开发方法

• 水晶方法：提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程

• SCRUM：侧重于项目管理

• 特征驱动开发方法：认为有效的软件开发需要3要素【人、过程、技术】。定义了6种关键的项目角色：项目经理、首席结构设计师、开发经理、主程序员、程序员和领域专家

• 开放式源码：程序开发人员在地域上分布很广【其他方法强调集中办公】

• ASD方法：其核心是三个非线形的、重叠的开发阶段：猜测、合作与学习

• 动态系统开发方法：倡导以业务为核心

逆向工程

实现级：包括程序的抽象语法树、符号表、过程的设计表示 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程

1. 重构/重组。重构是指在【同一抽象级别】上【转换系统描述形式】
2. 设计恢复。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息
3. 逆向工程。逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程
4. 正向工程。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量
5. 再工程/重构工程。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤

净室软件工程

• 净室即无尘室、洁净室。也就是一个受控污染级别的环境
• 使用盒结构规约（或形式化方法）进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制
• 使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息

【技术手段】

• 统计过程控制下的增量式开发：控制迭代
• 基于函数的规范和设计：盒子结构
  • 定义3种抽象层次：行为视图（黑盒）-》有限状态机视图（状态盒）-》过程视图（明盒）
• 正确性验证：净室工程的核心
• 统计测试和软件认证：使用统计学原理，总体太大时必须采用抽样方法

【缺点】

• 太理论化，正确性验证的步骤比较困难且耗时
• 开发小组不进行传统的模块测试，这是不现实的
• 脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端

需求工程

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

【需求工程主要活动的阶段划分】

• 需求获取
• 需求分析
• 形成需求规格【形成SRS】
• 需求确认与验证【形成需求基线（经过评审的SRS）】
• 需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】

需求管理是对【需求基线的管理】

需求获取

需求分析

数据流图

数据流图平衡原则

UML图

用例图

包含、扩展、泛化

类图与对象图

• 1：表示一个集合中的一个对象对应另一个集合中一个对象
• 0..*:表示一个集合中的一个对象对应另一个集合中的0个或多个对象（可以不对应）
• 1..*:表示一个集合中的一个对象对应另一个集合中的一个或多个对象（至少对应一个）
• *：表示一个集合中的一个对象对应另一个集合中的多个对象

顺序图

通信图（协作图）

状态图

活动图

定时图

构件图与包图

部署图

需求开发

需求定义

• 严格定义法
  • 所有需求都能被预先定义
  • 开发人员与用户之间能够准确而清晰地交流
  • 采用图形/文字可以充分体现最终系统
• 原型法
  • 并非所有的需求都能在开发前被准确的说明
  • 项目参加者之间通常都存在交流上的困难
  • 需要实际的、可供用户参与的系统模型
  • 有合适的系统开发环境
  • 反复是完全需要和值得提倡的，需求一旦确定，就应该遵从严格的方法

需求验证

需求跟踪

需求变更

识别出问题 -》 问题分析和变更描述 -》 变更分析和成本计算 -》 变更实现 -》 修改后端需求

软件系统建模

人机界面设计

• 置于用户控制之下
  • 以不强迫用户进入不必要的或不希望的动作方式来定义交互方式
  • 提供灵活的交互
  • 允许用户交互可以被中断和撤销
  • 当技能级别增加时可以使交互流水化并允许定制交互
  • 式用户隔离内部技术细节
  • 设计应允许用户和出现在屏幕上的对象直接交互
• 减少用户的记忆负担
  • 减少对短期记忆的要求
  • 建立有意义的缺省
  • 定义直觉性的捷径
  • 界面的视觉布局应该基于真实的世界的隐喻
  • 以不断进展的方式揭示信息
• 保持界面的一致性
  • 允许用户将当前任务放入有意义的语境
  • 在应用系列内保持一致性
  • 如过去的交互模型已建立了用户的期望，除非有迫不得已的理由不要改变它

结构化设计

• 概要设计【外部设计】：功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图
• 详细设计【内部设计】：为每个具体任务选择适当的技术手段和处理方法

结构化设计原则

• 模块独立性原型（高内聚、低耦合）
• 保持模块的大小适中
• 多扇入，少扇出
• 深度和宽度均不宜过高

内聚

耦合

模块四要素

• 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那取得输入，进行加工后再把输出返回调用者
• 处理功能：：值模块把输入转换成输出所作的工作
• 内部数据：指仅供该模块本身引用的数据
• 程序代码：值用来实现模块功能的程序

面向对象设计

基本过程

类的分类

• 边界类
  • 数据
• 控制类
  • 应用逻辑
  • 业务逻辑
  • 数据访问逻辑
• 实体类
  • API接口
  • 用户界面

设计原则

• 单一职责原则：设计目的单一的类
• 开放-封闭原则：对扩展开放，对修改封闭
• 李氏替换原则：子类可以替换父类
• 依赖倒置原则：要依赖与抽象，而不是具体实现；针对接口编程，不要针对实现编程
• 接口隔离原则：使用多个专门的接口比使用单一的总接口要好
• 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
• 迪米特原则（最少知识原则）：一个对象应当对其他对象有尽可能少的了解

软件测试

• 动态测试【计算机运行】
  • 白盒测试法
  • 黑盒测试法
  • 灰盒测试法
• 静态测试【人工监测和计算机辅助分析】
  • 桌前检查
  • 代码审查
  • 代码走查

控制流分析：是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性 表达式分析：括号不配对、数组引用越界、除数为零

白盒测试与黑盒测试

• 白盒测试【结构测试】：主要用于单元测试阶段
  • 控制流测试【逻辑覆盖测试】（语句覆盖最弱，路径测试覆盖最强）
  • 数据流测试
  • 程序变异测试【错误驱动测试】
• 黑盒测试【功能测试】：主要用于集成测试、确认测试和系统测试阶段
  • 等价类划分：不同等价类，揭示不同问题；有效等价类/无效等价类
  • 边界值分析：1<x<=10,可取的x值为0、1、10和11作为测试数据
  • 错误推测：依靠测试人员的经验和直觉
  • 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作
  • 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例

软件测试阶段

• 单元测试：依据【详细设计】，模块测试，模块功能、性能、接口等
• 集成测试：依据【概要设计】，模块间的接口
• 系统测试：依据【需求文档】，在真实环境下，验证完整的软件配置项能否和系统正确连接
• 确认测试：依据【需求文档】，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试
• 回归测试：测试软件变更后，变更部分的正确性和对变更需求的符合性

集成测试

系统测试

系统转换计划

遗留系统演化策略

新旧系统的转换策略

• 直接转换策略
• 并行转换策略
• 分段转换策略

数据转换与迁移

软件维护

影响可维护性的因素

• 【可理解性】是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度
• 【可修改性】是指修改软件的难易程度
• 【可测试性】是指验证软件程序正确的难易程度。可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大
• 【可靠性】一个软件的可靠性越高，需要维护的概率就会越低
• 【可移植性】是指将软件从一个环境移植到新的环境下正确运行的难易程度。软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率

软件维护的类型

• 正确性维护/改正性维护【修BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误
• 适应性维护【应变】：指使应用软件适应环境变化【外部环境、数据环境】而进行的修改
• 完善性维护【新需求】：扩充功能和改善性能而进行的修改
• 预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。经典实例：【专用】改【通用】