软件开发方法的主要分类笔记
# 软件开发方法
## 原型图的方法
### 分类
- 按功能
- 水平原型（针对界面）
- 垂直原型(针对复杂算法)
- 按最终结果
- 抛弃型[Throw Away Prototype]
- 此类原型在系统真正实现以后就弃用了
- 演化型/进化型[Evolutionary Prototype]
- 此类原型的构造，从目标系统的一个或几个基本需求出发，通过修改和追加功能的过程逐渐丰富，演化为最终的系统
### 特点
- 适用于需求不明确的开发
- 对用户需求是动态响应的、逐步纳入的
- 系统分析、设计、实现随着工作模型的不断修改而同时完成，互相没有明显的界限，没有明确的分工
- 系统开发计划是一个反复修改的过程
- 适用于需求刚开始定义不清晰、管理决策方法结构化程度不高
- 如果用户配合不好，随意修改，会拖延开发过程
## 结构化的方法
### 特点
- 自顶向下
- 用户至上
- 逐步分解或求解
- 严格区分工作阶段，每阶段有任务和成果
- 强调系统开发的整体性、全局性
- 系统开发过程工程化
- 文档资料标准化
### 优点
- 理论基础严密
- 用户需求在系统建立之前可以充分被理解
- 注重开发过程的整体性、全局性
### 缺点
- 开发周期长
- 文档、设计说明繁琐
- 工作效率低
- 开发阶段初期就要全面认识系统的需求、预料各种可能情况，不太现实
- 如果开发人员不稳定，可能造成系统交接不顺畅，系统运行和维护管理难度加大
- 阶段固化，不利于变化。适用于需求明确的场景
## 面向对象的方法
### 特点
- 系统的描述和信息模型的表示与客观实体相对应
- 符合人们的思维习惯
- 有利于开发过程中，用户和开发人员的交流与沟通，缩短开发周期
- 提高系统开发的准确性和效率
- 具有更好的复用性
- 关键在于建立一个全面、合理、统一的模型
- 分析、设计、实现三个阶段界限不明确
### 面向对象方法的三种模型
- 对象模型(描述系统数据结构)
- 表示静态的、结构化的系统的“数据性质”
- 是对模型客观世界实体的对象以及对象彼此间的关系的映射，描述了系统的静态结构
- 动态模型(描述系统控制结构)
- 表示瞬时的、行为化的系统的“控制性质”，规定了对象模型中对象的合法变化序列(对象的动态行为)
- 用状态图来描绘对象的状态、触发状态转换的事件、以及对象的行为/对事件的响应
- 每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型
- 功能模型(描述系统功能)
- 表示变化的系统的“功能性质”，指明了系统应该“做什么”，更直接反映了用户对目标系统的需求
- 通常也由一组数据流程图表示
- 面向对象方法中，数据流程图没有在结构化分析中重要，有时候可以省略
## 面向服务的方法
### 特点
- 以粗粒度、松耦合的系统功能为核心
- 强调系统功能的标准化和构件化
- 加强了系统的灵活性、可复用性和可演化性
### 概念上，划分3个抽象级别
- 操作(低)
- 代表单个逻辑工作单元(LUW)的事务
- 执行操作通常会导致读、写或修改一个或多个持久性的数据
- SOA操作可以直接与OO方法相比：都有特定的结构化接口，并且返回结构化的响应。
- 完全同方法一样，特定操作的执行可能涉及调用附加的操作。
- 操作位于最底层
- 服务(中)
- 代表操作的逻辑分组
- 业务流程(高)
- 为实现特定业务目标而执行的一组长期运行的动作或活动
- 通常包括多个业务调用
### 面向服务的分析和设计(SAOD)的三个层次
- 基础设计层(底层服务构件)
- 应用结构层(服务之间的接口和服务级协定)
- 业务组织层(业务流程建模和服务流程编排)
### 服务建模，分为三个阶段
- 服务发现
- 服务规约
- 服务实现
## 其他开发方法
### 形式化方法
- 特点：数学模型化；所有东西均可证明/验证，而不是测试
### 统一过程方法
### 敏捷开发方法
### 基于架构的开发方法 ABSD
