软件工程构件模型-软件工程构件模型

3．质量保证的观点 为了保证质量，瀑布型软件开发在各个阶段坚持了两 个重要的做法： （1）每一阶段都要完成规定的文档。没有完成文档， 就认为没有完成该阶段的任务。 （2）每一阶段都要对完成的文档进行复审，以便尽早 发现问题，消除隐患。 图2.8 增量模型 2.7.1 增量模型 * 第2章 软件工程过程模型 * 第2章 软件工程过程模型 第2章 软件工程过程模型 2.1 软件工程的技术基础 2.2 软件工程过程 2.3 软件过程模型 2.4 线性顺序模型 2.5 原型模型 2.6 快速应用开发模型 2.7 演化软件过程模型 2.8 软件过程技术 2.9 软件重用技术 2.10 小结 图2.1 软件工程过程层次图 软件工程是一种层次化的技术，如图： 2.1 软件工程的技术基础 1、对质量的关注构成了软件工程的根基。 2、过程层是软件工程的基层。 目前流行比较广泛的软件工程过程包括有RUP过程、极限(XP)过程、敏捷软件过程(Agile S.P)等等。 3、软件工程方法涵盖了需求分析、设计、编程、测试、维护等各个环节，它给出了完成这些任务在技术上应当“如何做”的方法。

4、工具层对过程和方法提供支持，使得工程活动、管理活动得以自动、半自动的进行。例如，目前广为使用的数据库建模工具Erwin、面向对象的建模工具Rationnal Rose、配置管理工具等等。 2.1 软件工程的技术基础 2.2 软件工程过程软件工程过程是开发或维护软件及其相关产品的一系列活动。软件工程过程通常包括四种基本的过程活动： (1) 软件规格说明：规定软件的功能、性能及其运行限制。 (2) 软件开发：产生满足规格说明的软件，包括设计与编码等工作。 (3) 软件确认：确认软件能够满足客户提出的要求，对应于软件测试。 (4) 软件演进：为满足客户的变更要求，软件必须在使用的过程中演进，以求尽量延长软件的生命周期。 此外，在一个良好的软件过程中，还应当包括一些“保护性”的活动。 在具体的工程过程中，可以根据实际需要，采用不同的过程模型来实现上述的基本活动和保护活动。一个良好的软件工程过程应当具备如下特点： (1) 易理解性。 (2) 可见性：每个过程活动都以得到明确的结果而告终，保证过程的进展对外可见。 (3) 可支持性 ：容易得到CASE工具的支持。

(4) 可接受性：比较容易被软件工程师接受和使用。 (5) 可靠性：不会出现过程错误，或者出现的过程错误能够在产品出错之前被发现。 (6) 健壮性：不受意外发生问题的干扰。 (7) 可维护性：过程可以根据开发组织的需求的改变而改进。 (8) 高效率：从给出软件规格说明起，就能够较快地完成开发而交付使用。 2.2 软件工程过程 图2.2 软件工程过程 一个软件过程可以表示成如图2.2所示的形式： 2.2 软件工程过程 2.3 软件过程模型 什么是软件工程过程模型？ 在一个具体的实际工程活动中，软件工程师必须设计、提炼出一个工程开发策略，用以覆盖软件过程中的基本阶段，确定所涉及的过程、方法、工具。这种策略常被称为“软件工程过程模型”。 图2.3 问题循环解决的各个阶段 2.3 软件过程模型 从宏观上来看，所有的软件开发过程都可以看成是一个循环解决问题的过程。如图2.3所示。上述的问题循环解决过程可以应用于软件工程的多个不同开发级别(阶段)上，包括考虑整个系统开发的宏观阶段，开发程序构件的中间阶段，甚至是代码编制阶段，因此可以采用分级集合表示。可以定义一个模式，然后在连续的、更小的规模上递归地应用它，这样来提供一个关于过程的理想化的视图。

问题循环解决过程的每一个阶段又包含一个相同的问题循环解决过程，如图2.4所示。 2.3 软件过程模型 图2.4 问题循环解决阶段中的阶段 2.3 软件过程模型 在软件工程实践中，以下过程模型比较流行： 瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、RUP（ Rational Unified Process ）模型、敏捷过程模型、构件组装模型、并发开发模型等等。 过程模型的共性： 一般都包含“定义（或计划）”、“开发”和“维护”3类活动。定义活动主要弄清软件“做什么”；开发活动集中解决让软件“怎么做”；维护活动则聚集于软件的“修改”，即“What-How-Change”。 2.3 软件过程模型 2.4瀑布模型（Waterfall model） 瀑布模型（也称线性顺序模型或软件生存周期模型）， 是W.Royce在1970年提出的。瀑布模型遵循软件生存期的 划分，明确规定各个阶段的任务，各个阶段的工作自上而 下、顺序展开，如同瀑布流水，逐级下落。瀑布模型把软件生存周期划分为计划时期（或定义时 期）、开发时期和运行时期。这三个时期又分别细分为若 干个阶段。

参看图2.5。 图2.5 软件生存周期的瀑布模型 2.4瀑布模型（Waterfall model） 瀑布模型软件开发具有以下几个特征： 1．阶段间的顺序性和依赖性 顺序性是指：只有等前一阶段的工作完成以后，后一 阶段的工作才能开始；前一阶段的输出文档，就是后一 阶段的输入文档。依赖性又同时表明了，只有前一阶段 有正确的输出时软件工程构件模型，后一阶段才可能有正确的结果。 2.4瀑布模型（Waterfall model） 2．推迟实现的观点过早地考虑程序的实现，常常导致大量返工，有时甚 至给开发人员带来灾难性的后果。 瀑布模型在编码以前安排了分析阶段和设计阶段，并 且明确宣布，这两个阶段都只考虑目标系统的逻辑模型，不涉及软件的物理实现。 把逻辑设计与物理设计清楚地划分开来软件工程构件模型，尽可能推 迟程序的物理实现，这是瀑布型软件开发的一条重要的 指导思想。 2.4瀑布模型（Waterfall model） 2.4瀑布模型（Waterfall model） 瀑布模型所带来的问题： １、不适应需求经常发生变更的环境：在项目的开发过程中，变更可能会引起混乱。所以，有人形象地把采用线性模型进行商业软件工程称之为“在沙滩上盖楼房”。

２、瀑布模型也经常不能接受项目开始阶段自然存在的不确定性：在采用线性顺序模型的时候，用户只有到项目的开发晚期才能够得到程序的可运行版本。大的错误如果到这时才被发现，那么造成的后果往往是灾难性的。 ３、线性顺序模型每一步的工作都必须以前一阶段的输出为输入，这种特征会导致工作中发生“阻塞”状态。 2.4瀑布模型（Waterfall model）虽然存在着上述的种种问题，但是线性顺序模型仍然有其值得肯定之处。 1、它提供了一个模板，使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序地展开，避免了软件开发、维护过程中的随意状态。 2、对于需求确定、变更相对较少的项目，线性顺序模型仍然是一种可以考虑采取的过程模型。采用这种模型，曾经成功地进行过许多大型软件工程的开发。 2.4瀑布模型（Waterfall model） 图2.6 原型模型 2.5 原型模型 2.5 原型模型 需求分析 原型开发 最终系统设计 原型评价 最终系统实现 用户 反馈 特点 快速开发工具 循环 低成本 种类 渐进型 抛弃型 2.5 原型模型 使用原型模型必须有两个前提: (1)是用户必须积极参与原型的建造，建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。

从这个意义上说，原型模型又往往被称为“抛弃原型模型”。 (2)是必须有快速开发工具可供使用。 2.5 原型模型 2.6 快速应用开发模型快速应用开发(RAD)模型是线性顺序模型的一个“高速”变种，强调极端的开发周期。RAD模型通过使用基于构件的建造方法达到快速开发的效果。RAD过程主要用于信息应用软件的开发，如图2.7所示，它包含以下几个开发阶段（见图）： 图2.7 RAD模型 2.6 快速应用开发模型1)业务建模：业务活动中的信息流被模型化。此阶段说明什么信息驱动业务流程、生成什么信息、谁负责生成该信息、该信息流向何处、谁处理它等。2)数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需的数据对象。此阶段标识出每个数据对象的特征属性，定义这些对象之间的关系。3)处理建模：数据建模阶段定义的数据对象变换成为要完成一项业务功能所需的信息流。此阶段创建处理描述以便增加、修改、删除或获取某个数据对象。 2.6 快速应用开发模型4)应用生成：RAD过程不是采用传统的第三代程序设计语言来创建软件，而主要是复用已有的程序构件或是创建可复用的构件。在所有情况下，均使用自动化工具辅助软件建造。

5)测试及反复：RAD过程强调复用，许多构件是已经测试过的，减少了测试工作量。但是所有的新创建构件、所有的接口都必须测试到。注：采用RAD模型时，系统的每一个主要功能部件可以由一个单独的RAD工作组完成，最后再将所有的部件集成起来形成完整的软件。 2.6 快速应用开发模型 优点： RAD模型强调可复用程序构件的开发，支持多小组并行工作以缩短整体工期。 缺点： 1)如果一个系统难以被适当地模块化，构件的复用和建造就会出现问题； 2)RAD模型依赖于构件复用，它不适用于技术风险很高的、要采用很多新技术的项目。 2.6 快速应用开发模型 2.7 演化软件过程模型软件就象其他复杂系统一样，需要经过一段时间的演化改进，才能够最终满足用户需求。业务和产品需求随着开发的进展常常发生变更，因而难以一步到位地完成最终的软件产品，但是，紧迫的市场期限又不允许软件工程师过多地延长开发周期。为了应对市场竞争或商业目标的压力，构造了“演化软件模型”。它的基本思想是“分期完成、分步提交”。可以先提交一个有限功能的版本，再逐步地使其完善。 演化模型的主要特点： 1)利用“迭代”方法，使工程师们渐进地开发，生产出逐步完善的软件版本。

2)用户的支持、理解和全程参与是成功采用演化模型的重要前提。 3)兼有线性顺序模型和原型模型的一些特点。根据开发策略的不同，演化模型又可以细分为“增量”模型和“螺旋”模型两种。 2.7 演化软件过程模型 问题背景：由于传统的瀑布模型本身存在的不足，在开发过程中不论怎样严格，终究难以接近理想目标，考虑能否将整个软件一部分一部分地开发？ 解决方案：在需求难以完全明确的情况下，快速分析并构造一个小的原型系统，满足用户的某些要求后，使用户在使用过程中受其启发，逐步确定各种需求。即所谓的增量模型。 增量模型：融合了线性顺序模型的基本成分(重复的应用这些成分)和原型模型的迭代特征，如图2.8所示。增量模型实际上是一个随着日程/时间的进展而交错的线性序列集合。每一个线性序列产生一个软件的可发布的“增量”，所有的增量都能够结合到原型模型中去。 2.7.1 增量模型