软件开发模型与软件工程
瀑布式模型
原型模型
增量模型
螺旋模型
XP开发模型
面向对象的开发模型
构件集成模型
第二章 软件开发模型
软件开发模型：
软件开发模型是软件开发的全部过程、活动、任务和管理
的结构框架。
软件开发模型能清晰、直观地表达软件开发全过程， 明确
规定了要完成的主要活动和任务，用来作为软件项目工作的基础。
选择合适的开发模型是十分重要的
软件开发模型与软件工程
软件开发模型是将软件开发中的主要活动细分为：
软件开发模型与软件工程
系统需求分析
程序设计
程序
编码
测
试
运行维护
系统
设计
人员管理
项目管理
常见的开发模型：
瀑布模型、演化模型、螺旋模型、 XP开发模型、 快速开发模型等。
由于现在还没有任何一种方法能够解决软件危机中的所有问题，所以在软件开发的各个阶段采用综合治理的方法。
软件开发模型直接影响软件开发的周期和软件质量，是软件开发的组织管理形式，是软件工程最重要的内容之一。
软件开发模型与软件工程
瀑布模型的概念：
瀑布模型（Waterfall Model）
瀑布模型是将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。它包括需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型的概念：
瀑布模型（Waterfall Model）
需求分析
系统设计
程序设计
编码
测试
运行及维护
瀑布模型
（需求说明书）
（系统设计书）
（程序设计书）
（程序清单）
（测试报告）
（维护报告，
改进的系统
）
阶段任务、结果及人员
阶段
基本任务
工作结果
参加者
需求分析
理解和表达用户的要求，
需求说明书
用户、分析人员
系统设计
建立系统的结构,模块划分
系统设计书
用户、系统设计人员
程序设计
程序内的模块设计，数据库的物理设计
程序设计书
程序员？
编程
程序编写
程序
程序员
测试
发现错误和排除错误
测试报告
测试人员
运行及维护
维护
维护报告、改进的系统
用户、维护人员
瀑布模型概念
特征：
从上一阶段承接的成果物作为本阶段的工作对象；
对上一阶段成果实施本阶段的活动；
给出本阶段的成果，作为下一阶段的输入；
对本阶段的工作进行评审，若本阶段的工作得到确认，则继续下阶段的工作，否则返回前一阶段或更前一阶段。
优点：
提供了一个模板，使得分析、设计、编码、测试、运行维护可以在该模板的指导下应用。
瀑布模型的特点
缺点：
缺乏灵活性，不能适应用户需求的改变
开始阶段的小错误被逐级放大，可能导致软件产品报废
返回上一级的开发需要十分昂贵的代价
随着软件规模和复杂性的增加，对于需求不能完全确定的软件开发项目将产生很大的风险。
通常使用场合：
需求分析做得比较好的系统
二次开发系统
瀑布模型的特点
在项目开发的初始阶段，人们对软件的需求认识往往不够清楚，因而使得开发项目难以做到一次开发成功，出现返工再开发在所难免。
原型模型
在获得用户基本需求说明的基础上，投入少量人力和物力，快速建立一个原始模型，使用户及时运行和看到模型的概貌和使用效果，并对需求说明进行补充和精化，提出改进意见，开发人员进一步修改完善，如此循环迭代，直到得到一个用户满意的模型为止。 从原型法的基本思想中可以看到，用户能及早看到系统模型，在循环迭代修改和完善过程中，使用户的需求日益明确，从而消除了用户需求的不确定性，同时从原型到模型的生成，周期短、见效快，对环境变化的适应能力较强。
原型模型的基本思想
⑴ 功能选择 要恰当选择原型实现的功能。根据用户基本需求，对系统给出初步定义。用户的基本需求包括各种功能的要求、数据结构、菜单和屏幕、报表内容和格式等要求。这些要求虽是概略的，但是最基本的，易于描述和定义。原型和最终的软件系统不同，两者在功能范围上的区别主要有以下两个方面：
原型模型的内容
第一最终系统是软件需求全部功能的实现，而原型只实现所选择的部分功能。 第二最终系统对每个软件需求都要求详细实现，而原型仅仅是为了试验和演示用的，部分功能需求可以忽略，或者模拟实现。
原型模型的内容
⑵ 构造原型 根据用户初步需求，开发出一个可以应用的系统，它应满足上述的由用户提出的基本要求。在构造一个原型时，应当强调着眼于预期的评估，而不是为了正规的长期使用。
⑶ 运行和评价原型 在试用中能亲自参加和面对一个实在的模型，能较为直观和明确地进一步提出需求，提出修改意见。通过运行原型对软件需求规格说明进行评价和确认。评价要有用户参与，注意来自用户的反馈信息。
原型模型的内容
⑷ 修改和完善原型 根据修改意见进行修改，以得到新的系统原型，然后再进行试用和评价，这样经过有限次的循环反复，逐步提高和完善，直到得到一个用户满意的系统模型为止。根据原型实现的特点和环境，可以把原型作为试验的工具，用完就丢弃之（大部分原型都废弃不用，主要因为原型太慢、太大、结构不合理等原因）；也可以使原型全部或部分地成为最终系统的组成部分。 原型开发与原型运行评价两者需反复进行多次，才能最后得到经过确认的需求规格说明，并以此作为进一步的软件设计和实现的基础。
原型模型的内容
需求分析
原型开发
最终系统设计
原型评价
最终系统实现
用户
反馈
图 快速原型模型
原型模型的内容
原型模型（快速原型模型）
原型范型
用户测试
运行原型
建造/修改
原型
听取用
户意见
原型模型的内容
采用原型模型的软件生存周期
分析定义
系统需求
生成
原型
系统
设计
程序
设计
编码
测试
运 行
和维护
原型化
含原型化的
软件生存期
原型模型的内容
优点：
开发者与用户充分交流，可以澄清模糊需求，需求定义比其他模型好得多
为用户需求的改变提供了充分的余地
缺点：
开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。软件系统的组成部分可能会打折扣；
资源规划和管理较为困难，随时更新文档也带来麻烦。
一般使用场合：
开发者在不了解的应用领域开发
客户不清楚其所开发软件项目的最终目标
原型模型的特点
增量模型
1.阶段式开发：增量模型
系统设计时分片交付，可使用户在使用某些基本功能的同时，开发剩余的功能。这样通常会并行地存在两个系统：生产系统和开发系统。运行或生产系统是当前被客户或用户所使用的系统。而开发系统是准备用于替代当前生产系统的下一个版本。
增量模型是一种非整体开发的模型。是瀑布模型的顺序特征和快速原型模型的迭代特征相结合的产物。
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
创建版本1
创建版本2
创建版本3
使用版本1
使用版本2
使用版本3
开发者
使用者
阶段式开发：增量和迭代模型
增量模型
规格说明
设计
实现和集成
交付客户
规格说明
设计
实现和集成
交付客户
规格说明
设计
实现和集成
交付客户
规格说明
设计
实现和集成
交付客户
增量1
增量2
增量3
增量n
增量模型
特点： 在前面增量的基础上开发后面的增量 每个增量的开发可用瀑布或快速原型模型 迭代的思路
优点： 如果在项目既定的商业要求期限不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增量可以有少量的人员实现。同时，增量模型可以规避技术风险。
增量模型
软件开发几乎总要冒一定的风险，例如，产品交付给用户之后用户可能对产品不满意，到了预定的交付日期软件可能还未开发出来，实际的开发成本可能超过了预算，产品完成之前一些关键的开发人员可能“跳槽”了，产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等等。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件产品越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。
构建原型是一种能使某些类型的风险降至最低的方法。 于是在1988年提出了螺旋模型。
螺旋模型
螺旋模型的基本思想是，使用原型及其他方法以尽可能地降低风险。理解这种模型的一个简易方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型，如右图所示。
简化的螺旋模型图
螺旋模型
螺旋模型将瀑布模型与原型模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。
螺旋模型是一种风险驱动的模型。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。
螺旋模型适合于大型软件的开发。
螺旋模型
螺旋模型
完整的螺旋模型图
制定计划
风险分析
客户评估
工程实施
螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。当项目按照顺时针方向沿螺旋移动时，每一个螺旋周期包含了风险分析，并且按以下4个步骤来进行：
（1）确定目标，选定方案，设定约束条件，选定完成本周期所定目标的策略。
（2）分析该策略可能存在的风险。必要时通过建立一个原型来确定风险的大小，然后据此决定是按原定目标执行，还是修改目标或终止项目。
（3）在排除风险之后，实现本螺旋周期的目标，例如，第一圈可能产生产品的规格说明，第二圈可能产生实现产品设计等。
（4）最后一步是评价前一步的结果，并且计划下一轮的工作。
螺旋模型
优点：
结合瀑布模型和原型模型的优点
风险分析可使一些极端困难的问题和可能导致费用过高的问题被更改或取消
缺点：
螺旋模型开发的成败，很大程度上依赖于风险评估的成败。需要开发人员具有相当丰富的风险评估经验和专门知识
一般使用场合：
需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。
螺旋模型
XP开发模型
XP开发模型概要
XP极限编程(eXtreme Programming)是一种敏捷（Agile）开发方法，以编码为核心任务的，供中小型小组用于开发需求快速变化的软件。
敏捷是什么？敏捷已经成为当今描述现代软件过程的时髦用词。每个人都是敏捷的，敏捷团队是能够适当响应变化的灵活团队。变化就是软件开发本身，软件构建有变化，团队成员在变化、使用新技术带来变化，各种 变化都会对开发的软件产品以及项目本身造成影响。我们必须接受“支持变化”的思想，它应当根植于软件开发中的每一件事中，因为这是软件的心脏与灵魂。敏捷团队意识到软件是团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。
敏捷方法是为了克服传统软件工程中认识和实践的弱点开发而成的（Jim Highsmith说：“传统方法学家陷入了误区，乐于生完美的文档而不是满足业务需要的可运行系统”）。敏捷开发可以带来多方面的好处，但它并不使用于所有的项目、所有的方面、所有的人和所有的情况，它并不完全对立于传统的软件工程实践。
XP有四部分组成：价值、原则、活动和实践
XP的4种价值观：
交流：侧重口头交流，而不是文档、报表和计划。因而，人际关系显得尤为重要。
简化：在管用的前提下，做最简单的事。目标放在客户当前的需求上，摒弃了过多的文档。
反馈：
通过及时地单元测试和功能测试获得快速反馈。
快速地编写软件，然后向客户演示。为确保准确性和高质量，获取客户关于到目前为止的进度的反馈是至关重要的。
勇气：
提倡积极面对现实和处理问题的勇气
快速工作并在必要时重新进行开发的勇气。
XP开发模型概要
XP的指导原则：
快速反馈：开发人员通过简短的反馈循环迅速了解其当前产品是否满足了客户的需求。
简单性假设：将每个问题都视为很容易解决。只需为当前迭代打算，而无需洞察未来可能需要什么。
逐步修改：通过一系列细微的修改来解决问题。
拥抱变化：包容变化，提倡变化。
高质量的工作：工作质量决不可打折扣。XP采用测试先行的编程方式，强调编码和测试的重要性。
XP开发模型概要
XP活动：
倾听：积极倾听。
测试：非“马后炮”式的测试。编码之前编写测试用例。
编码：编写代码是一种工艺，通过重构、结对编程和代码复核等实践得以改进。
设计：设计是不断演化的，并非固定的，不能赋予它单个职责，而是基于小组的，动态的。
XP开发模型概要
XP实践：
XP开发模型概要
实践
描述
规则游戏
规则游戏的职责是快速制定下一次发布或迭代的高级规划
小型发布
XP周期提供业务价值的频繁发布组成
隐喻
隐喻是用于描述项目的通用观点、术语和语言
简单设计
从XP的角度说，简单意味着代码完成的是最简单、惯用的
测试
测试首先被开发，然后再测试装置中实现
重构
不改变系统中可见行为的前提下，对已有的代码设计进行改进
结对编程
两位开发人员坐在同一台工作站前，一起完成开发任务
集体拥有
任何小组成员能够在任何时间对代码的任何部分进行修改
持续集成
每天对系统组件进行多次的集成
每周工作40小时
加班加点，无法确保高质量和高性能。XP要求正常的工作时间，以确保质量。不要连续两个星期都加班
现场客户
团队中加入一位真正的、起作用的用户，他将负责全职回答问题
编码标准
编码标准是一系列的约定，所有人在开发时都必须遵守
XP开发模型概要
XP关键特征：
明确的反馈：早期的明确反馈。
逐步规划：“让我们对现在知道的进行规划，然后在发生变化时，不断地重新规范”
测试优先
口头交流
一般使用场合：
规模小、进度紧、需求变化大、质量要求严的项目
XP开发模型特点
一般不适合的场合：
中大型的项目
重构会导致大量经费开销的应用项目
需要很长的编译或者较长的测试周期的系统
不容易进行测试的应用项目
团队人员异地分布的项目
不能接受XP文化的组织和团队
XP开发模型特点
面向对象的开发模型——1
在讲面向对象的开发模型之前先讲
面向对象的基本概念
面向对象的基本概念
对象Object
类Class
继承Inheritance
消息Message
面向对象
对象+类+继承+消息通信
对象Object
客观世界中的实体
状态（静态属性 Attributes）
操作（动态行为 Methods）
对象::=<ID,MS,DS,MI>
Identifier——（标识：即名称，用来在问题域中区分其他对象）
Method Set——（即行为或方法：一是对自身的操作，改变原有的属性状态；另一是施加于其他对象的操作，将产生的输出结果作为消息发送的操作）
Data Structure——（数据：描述对象属性的存储或数据结构，他表示了对象的一个状态）
Message Interface——（接口：主要指对外接口，指对象受理外部消息所制定的操作的名称集合）
类Class和实例Instance
类
相同属性和行为的对象的抽象
实例
特定类所描述的一个具体对象
子类直接继承父类的数据和操作
继承的传递性，单继承、多重继承
继承（Inheritance）
家具
桌子
椅子
衣柜
床
椅子的实例
多态性Polymorphism
概念
不同类层次共享一个方法名
相同的参数特征和返回值类型
多种不同实现
C++中虚函数实现
动态联编
重载Overloading
函数重载
同一作用域
多个名字相同的函数
参数特征不同
静态联编
运算符重载
消息Message
对象间的交互手段
形式：
Message:[dest,op,para]
Destination Object（目标对象）
Operation（操作）
Parameters（参数）
面向对象的开发模型——2
对象技术为软件工程的基于构件的过程模型提供了技术框架。面向对象范型强调了类的创建，类封装了数据和用于操纵该数据的算法。如果经过合适的设施和实现，面向对象的类可以在不同的应用及基于计算机的系统结构中复用
面向对象模型融合了螺旋模型的许多特征。它本质上是演化的，支持软件开发的迭代方法。
构件集成模型
构件（component)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件组装起来协调工作。
该模型支持软件重用，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、跨越不同操作平台的软件，扩展了软件的应用前景，促进了软件标准化、商品化的发展。
因此，在此基础上专家们又提出了“基于构件的软件工程”(CBSE)。
构件组装模型具有极其广阔的实用性和深远的意义。
构件组装模型如下图所示：
构件集成模型
软件需求
标识构件
检索构件库
开发构件
取出构件
存入构件库
集成目标系统
体系结构设计
构件适应性修改
集成测试
系统测试
运行维护
构件集成模型
构件集成模型
特点
面向对象
基于构件库
融合螺旋模型特征
支持软件开发的迭代方法
软件重用
构件技术
软件体系结构被建立后，必须用构件去充实，这些构件可从复用库中获得，或者根据专门需要而开发。整个过程可以演化地进行，面向对象方法给予技术上的支持。
构件技术目前主要有三种流行标准：
• OMG的CORBA： 对象管理组织发布的公共对象请求代理体系结构(Common Object Request Broker Architecture)。一个对象请求代理（ORB)提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。
构件技术
• 微软的COM/DCOM：微软开发了构件对象模型（Component Object Model)，它提供了运行于windows之上的单个应用系统使用不同厂商生产的构件的规约。基于分布式环境下的COM称为DCOM (Distribute COM)。
• SUN的EJB (Enterprise JavaBean)：随着Java在企业级应用的地位日趋重要，Sun提出了一个统一的企业级Java平台—J2EE。在J2EE中，EJB负责最核心的业务处理。它为服务器端的应用程序提供了一种与厂商无关的Java接口，让任何符合EJB规范的构件都可以运行在每一台这样的服务器上。
基于构件的未来软件生产线
应用构件
提取车间
应用
构件库
构件生
产车间
构件库
组装
车间
领域
1
领域
2
应用
系统
...
1
2
3
4
1基础构件，2功能构件
3接口构件，4用户界面构件
