二、瀑布模型

最早公布的软件开发过程模型源自比较通用的系统工程过程。这种模型如图5A-1所示。 由于从一个阶段到另一个阶段的瀑布状级联，该模型称为瀑布模型或软件生命周期。该模型 的主要阶段映射基本的开发活动：

1、 需求分析与定义。系统的服务、约束和目标要经过与系统用户的磋商加以确定。然 后，它们得到详细定义并作为系统规格说明。

2、 系统与软件设计。系统设计过程将需求划分成需硬件或软件系统实现的部分。该过 程确立一个总的系统体系结构。软件设计涉及到确定和描述基本的软件系统抽象及 其相互关系。

3、 实现与单元测试。在这个阶段，软件设计被实现为一组程序或程序单元。单元测试 涉及到验证每个单元是否符合其规格说明。

4、 集成与系统测试。单个的程序单元或程序进行集成并作为一个完整系统进行测试， 以确保软件需求已得到满足。测试之后，软件系统交付客户。 5、 运行与维护。通常（但并非必定），这是软件生命周期最长的阶段。系统经过安装 投入实际使用。维护涉及到纠正在软件生命周期前面阶段没有发现的错误，改进系 统单元的实现，并随着新需求的发现增强系统的服务。

原则上，每个阶段的结果都要形成一份或多份经过批准的文件。前一个阶段未结束，下 一个阶段不应开始。实际上，这些阶段重叠并互相馈送信息。在设计期间，需求方面存在的 问题得到识别；在编码期间，设计问题被发现，等等。软件过程并非一个简单的线性模型， 而是涉及到一系列迭代的开发活动。

由于编制和批准文件的成本，迭代需要大笔开销，而且需要做大量重复工作。因此，经 过少数迭代之后，通常应冻结开发的某些部分，如规格说明，并继续进行后面的开发阶段。 存在的问题留待以后解决，置之不顾，或者通过编程绕过去。这样仓促冻结需求，可能意味 图5A-1：软件生命周期 运行与 维护 集成与 系统测试 实现与 单元测试 系统与 软件设计 需求定义

着系统将难以满足用户的要求。由于使用实现技巧规避了设计问题，这也可能导致不良的系 统结构。

在最后的生命周期阶段（运行与维护），软件投入使用。最初软件需求中存在的错误与

疏漏被发现，程序与设计错误浮现，而且新的功能需要得到确定。因此，为保持有用性，系 统必须演变。进行有关更改（软件维护）可能涉及到重复以前的过程阶段。

瀑布模型的优点在于每个阶段都编制文件，而且它与其他的工程过程模型相符合。其主 要问题在于将项目僵硬地划分成不同的阶段。在过程的一个早期阶段，必须定下决心，从而 使得应对客户需求变化很困难。

因此，只有在需求得到很好理解、在系统开发期间不可能发生根本性变化的情况下，才 应使用瀑布模型。然而，瀑布模型体现了在其他工程项目中所使用的过程模型类型。所以， 基于这种方法的软件过程仍然用于软件开发，特别是当有关软件项目是一个较大系统工程项

11

目的一部分时。 三、演化开发

演化开发基于这样的思想：开发一个初始的实现，让其接受用户评论，并让其经过多个 版本的改进，一直到开发出能够满足需要的系统（图5A-2）。规格说明、开发及验证活动不 是分开进行，而是交叉进行，各项活动之间有快速的信息反馈。 演化开发有两个基本类型：

1、 探索式开发。在这种类型中，过程的目标是与客户协作探索其需求，并交付一个最 终的系统。开发从业已理解的系统部分开始。随着增添客户提出的新特征，系统不 中间 版本 并行活动

图5A-2：演化开发 描述 最终 版本 初始 版本 开发 验证 规格说明 断演变。

2、 抛弃式原型开发。在这种类型中，演化开发过程的目标是理解客户的需求，从而为 系统开发比较好的需求定义。原型集中试验没有很好理解的客户需求。

在生产满足客户眼下需要的系统时，软件开发的演化方法常常比瀑布方法有效。基于演 化方法的软件过程的优点是，规格说明可以渐进地开发。随着用户增进对其问题的理解，这 种理解可以反映在软件系统中。然而，从工程和管理的角度来看，演化方法存在两个问题： 1、 过程缺乏可视性。管理员需要定期交付的产品来衡量进度。在快速开发系统的情况 下，编制反映每个系统版本的文件不合算。

2、 系统常常缺乏良好的结构。不断的更改往往会破坏软件的结构。吸收软件更改变得 越来越困难，越来越成本高昂。

对于中小型系统（上至50万行代码），演化方法或许是最佳的开发方法。对于不同小组 开发系统不同部分的大型、复杂、长寿命系统，演化开发存在的问题尤为严重。使用这种方 法难以建立一个稳定的系统体系结构，这使得集成各小组的贡献变得很难。

对于大型系统，建议使用一种混合过程，将瀑布模型和演化开发模型的最佳特征结合起 来。这可能涉及到使用演化方法开发一个抛弃式原型，以解决系统规格说明中存在的不确定 性。然后，可使用一种结构化程度比较高的方法重新实现系统。得到很好理解的系统部分可 使用基于瀑布模型的过程进行规格说明和开发。事先难以进行规格说明的其他系统部分，如 用户界面，无例外地应使用探索式编程方法来开发。 四、基于组件的软件工程

大多数软件项目都存在某种程度的软件复用。通常，这是非正式发生的。参加项目的人 知道有现成的设计或编码类似于他们所需的设计或编码。他们寻找这些设计或编码，根据需 要对其进行修改，并将其吸收进他们的系统。对于使用演化方法进行快速系统开发，复用常 常是必要的。

12

这种非正式复用的发生是不考虑所使用的开发过程的。然而，在过去几年中，出现了一 种软件开发方法，这种方法使用得越来越多，它依靠复用，被称为基于组件的软件工程。 这种面向复用的方法依靠大量的可复用软件组件，以及用于这些组件的某种集成框架。 有时，这些组件本身就是可提供文本格式化或数值计算等特定功能的系统（商用现成系统）。 基于组件的软件工程的类属过程模型如图5A-3所示。

就最初的需求规格说明阶段和验证阶段而言，面向复用过程与其他过程相类似，但它的 中间阶段与其他过程不同。这些阶段是：

1、 组件分析。在有需求规格说明的情况下，搜索实现该规格的组件。通常，不存在完 全相符的组件。可能被使用的组件只在某种程度上提供所要求的功能。

2、 需求修改。在这个阶段，使用已经发现的组件的相关信息分析需求，然后修改需求 以反映可用的组件。在无法进行修改的情况下，可能重新进入组件分析活动，以搜 索可供选择的解决方案。

3、 带复用的系统设计。在这个阶段，设计系统框架或复用现有的框架。设计员考虑到 复用的组件，并组织安排框架使其适应复用的要求。如果得不到可复用的组件，可 能得设计一些新软件。

4、 开发与集成。无法外部获得的软件要进行开发，组件和商用现成系统要集成以创建 新的系统。系统集成在这种模型中可能是开发过程的一部分，而非一项分开的活动。 基于组件的软件工程具有减少需要开发的软件量并因此降低成本与风险的明显优点。它 通常也可更快地交付软件。然而，需求方面的妥协不可避免，这可能导致系统不能满足用户 的真正需要。此外，可复用组件的新版本不受其使用机构的控制，因此丧失了对系统演变的 某些控制。

图5A-3：基于组件的软件工程 需求 规格说明 组件 分析 需求 修改 带复用的 系统设计 系统 验证 开发与 集成

第六单元：数据库

课文A：数据库概览 一、引言

数据存储传统上是使用单独的没有联系的文件，这些文件有时称为平面文件。在过去， 一个机构中的每个应用程序都使用自己的文件。例如，在一个大学中，每个部门都可能有其 自己的文件集：档案办公室保存着关于学生信息和学生成绩的文件；经济资助办公室保存着 其自己的关于需要经济资助以继续学业的学生的文件；调度办公室保存着教授的姓名和他们 所教的课程；工薪发放部门保存着其自己的关于全体教职员工（包括教授）的文件，等等。

13

然而，所有这些平面文件今天都可结合成一个实体——供整个大学使用的数据库。 虽然难以给出一个普遍接受的数据库定义，但我们使用下面常见的定义：一个数据库是 被一个机构内的应用程序所使用的具有逻辑相干性的相关数据的集合。 二、数据库管理系统

数据库管理系统定义、创建和维护数据库。数据库管理系统也允许对数据库中的数据进 行受控的访问。一个数据库管理系统由5个组成部分构成：硬件、软件、数据、用户和规程。 1、硬件

硬件是指允许访问数据的计算机物理系统。例如，终端、硬盘、主机和工作站被认为是 数据库管理系统的硬件组成部分。 2、软件

软件是指允许用户访问、维护和更新数据的实际程序。另外，软件还控制着哪个用户可 以对数据库中的哪部分数据进行访问。 3、数据

数据库中的数据存储在物理存储设备上。在一个数据库中，数据是独立于对其进行访问 的软件的一个实体。这种独立使一个机构可以在不必更改物理数据及其存储方式的情况下更 改软件。如果一个机构决定使用一个数据库管理系统，那么该机构所需要的所有信息都应作 为一个实体保存在一起，可由数据库管理系统中的软件访问。 4、用户

在数据库管理系统中，用户这个术语有着广泛的定义。我们可以将用户分为两类：最终 用户和应用程序。

最终用户是指可直接访问数据库以获取信息的人。最终用户又分为两类：数据库管理员 和普通用户。数据库管理员拥有最高程度的特权，可以控制其他用户及其对数据库管理系统 的访问，可以将其某些特权授予其他人并保留随时收回这些特权的能力。另一方面，普通用 户只能使用数据库的一部分，只能进行有限的访问。

数据库中数据的其他用户就是应用程序。应用程序需要访问和处理数据。例如，工薪发 放应用程序需要在月底访问数据库中的部分数据，来开支付工薪的支票。 5、规程

数据库管理系统的最后一个组成部分就是应该明确定义并为数据库用户所遵循的一套 规程或规则。 三、数据库体系结构

美国国家标准协会标准计划与需求委员会（ANSI/SPARC）为数据库管理系统确立了一 个包含3个层次的体系结构：内层、概念层和外层（图6A-1）。 1、内层

内层决定数据在存储设备上的实际存储位置。该层涉及低级访问方法，以及字节如何传 向和传自存储设备。换句话说，内层直接与硬件交互。 2、概念层

概念层定义数据的逻辑视图。数据模型在该层定义，数据库管理系统的主要功能——如 查询——也在该层。数据库管理系统把数据的内部视图转化为用户需要看到的外部视图。概 念层是中介层，它使得用户不必与内层打交道。 3、外层

外层直接与用户（最终用户或应用程序）交互。它将来自概念层的数据转化为用户所熟 悉的格式和视图。 四、数据库模型

14

数据库模型定义数据的逻辑设计。它也描述数据的不同部分之间的关系。在数据库设计 史上，使用过3种数据库模型：层次模型、网络模型和关系模型。 1、层次数据库模型

在层次模型中，数据被组织成一棵倒置的树。每个实体只有一个父，但可有数个子。在 分层结构的顶部，有一个实体，称为根。图6A-2给出了一个层次模型例子的逻辑视图。层次模型现在已经过时。 2、网络数据库模型

在网络模型中，实体以图的形式来组织，图中的有些实体可通过多条路径访问（图6A-3）。 网络模型没有分层结构。这种模型现在也已经过时。 3、关系数据库模型

在关系模型中，数据被组织成称为关系的二维表。关系模型没有分层或网络结构强加于 数据。然而，表或关系是相互关联的（图6A-4）。关系数据库管理系统组织数据，使其外部 视图呈现为关系或表的集合。这并不意味着数据以表的形式存储：数据的物理存储与数据的 逻辑组织方式毫无关系。图6A-5给出了一个关系的例子。关系数据库管理系统中的关系具有以下特征：

● 名称。关系数据库中的每个关系都应具有一个名称，而这个名称在所有关系中是独一 无二的。

● 属性。关系中的每一列都称为一个属性。在图6A-5的表中，属性是列的标题。每个 属性赋予存储在其下面的数据以意义。表中的每一列都必须具有一个在关系的范围内 独一无二的名称。一个关系的属性总数称为该关系的度。例如，在图6A-5中，关系 的度为3。注意属性名并不存储在数据库中：概念层使用属性给每一列赋予一定的意 义。

● 元组。关系中的每一行称为一个元组。元组定义一组属性值。一个关系中的总行数称 为该关系的基数。注意一个关系的基数随着元组的增加或删除而改变。这使数据库具 有了动态性。

关系模型是今天使用的常见模型之一。源自关系模型的另外两种常见模型是分布式模型 和面向对象模型。 4、分布式数据库模型

分布式数据库模型并非一种新模型，而是基于关系模型的。但是，数据存储在通过因特 网或专用广域网通信的数台计算机上。每台计算机（或站点）保持数据库的一部分或整个数 据库。换句话说，数据或者是分段存储的——每个站点存储一段，或者被每个站点复制一份。 在分段型分布式数据库中，数据是本地化的，本地使用的数据存储在相应的站点上。然 而，这并不意味着一个站点不能访问存储在另一个站点上的数据，但访问大多是本地性的， 偶尔是全局性的。虽然每个站点对其本地数据具有完全的控制，但也存在通过因特网或广域 网的全局控制。

例如，一家制药公司可能在许多国家拥有多个站点。每个站点有一个数据库，存储着自 己雇员的信息。但是，中心人事部门可以控制所有的数据库。

在复制型分布式数据库中，每个站点都有其他站点的一个完全副本。对一个站点所存储 的数据进行的任何修改，都要在其他每个站点上精确地重复进行。拥有这种数据库是为了安 全。如果一个站点上的系统发生故障，该站点的用户可以访问另一个站点上的数据。 5、面向对象数据库模型

关系数据库具有一个特定的数据视图，该视图基于数据库元组与属性的性质。关系数据 库中最小的数据单位是一个元组与一个属性的交集。然而，有些应用程序需要将数据视为其 他形式，如看作一种结构，像由字段构成的记录。

15