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