计算机专业英语翻译

：软件过程模型

一、引言

一个软件过程是生产出软件 产品的一系列活动。这些活动可能涉及使用一种像

Java

或< /p>

C

这样的标准编程语言从零开始开发软件。然而，开发新软件越 来越多地使用的方法是，扩展

和修改现有系统，以及配置和集成现成软件或系统组件。

一个软件过程模型是对一个软件过程的一种抽象表示。每个过程模型都从一个特定角度

表示一个过程，因此都只提供有关那个过程的部分信息。本文介绍几 种非常通用的过程模型

（有时称为过程范例），并从体系结构 的角度描述它们。也就是说，我们看到的是过程的框

架，而非具体活动的细节。

..

.

这些类属模型不是对软件过程的规定性描述。确切点说，它 们是过程的抽象，可用于解

释软件开发的不同方法。你可以将 其视为可扩展和调整以创建更为具体软件工程过程的过程

框架。

这里论述的过程模型是瀑布模 型、演化开发和基于组件的软件工程。这

3

种类属过程模

型在当前的软件工程实践中广泛使用。它们不是互不相容，而是经常 一起使用，尤其是在大

型系统开发的情况下。一个较大型系统 内的子系统可使用不同的方法开发。因此，尽管分别

讨论这些 模型比较方便，但应该明白，实际上它们经常结合使用。

二、瀑布模型

最早公布的软件开发过 程模型源自比较通用的系统工程过程。这种模型如图

5A-1

所 示。

由于从一个阶段到另一个阶段的瀑布状级联，该模型称为 瀑布模型或软件生命周期。该模型

的主要阶段映射基本的开发活动：

1

、

需求分 析与定义。系统的服务、约束和目标要经过与系统用户的磋商加以确定。然

后，它们得到详细定义并作为系统规格说明。

2

、

系统与 软件设计。系统设计过程将需求划分成需硬件或软件系统实现的部分。该过

< br>

其相互关系。

3

、

实现与 单元测试。在这个阶段，软件设计被实现为一组程序或程序单元。单元测试

涉及到验证每个单元是否符合其规格说明。

4

、

集成与 系统测试。单个的程序单元或程序进行集成并作为一个完整系统进行测试，

以确保软件需求已得到满足。测试之后，软件系统交付客户。

5

、

运行与 维护。通常（但并非必定），这是软件生命周期最长的阶段。系统经过安装

< br>

统单元的实现，并随着新需求的发现增强系统的服务。

原则上，每个阶段的结果都要形成一份或多份经过批准的文件。前一个阶段未结束，下< /p>

一个阶段不应开始。实际上，这些阶段重叠并互相馈送信息。在 设计期间，需求方面存在的

问题得到识别；在编码期间，设计 问题被发现，等等。软件过程并非一个简单的线性模型，

而是涉及到一系列迭代的开发活动。

由于编制和批准文件的成本，迭代需要大笔开销，而且需要做大量重复工作。因此，经

过少数迭代之后，通常应冻结开发的某些部分，如规格说明，并继续进行后面的开发阶段 。

存在的问题留待以后解决，置之不顾，或者通过编程绕过去 。这样仓促冻结需求，可能意味

图

5 A-1

：软件生命周期

运行与

维护

集成与

系统测试

实现与

单元测试

系统与

软件设计

需求定义

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

统结构。

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

疏 漏被发现，程序与设计错误浮现，而且新的功能需要得到确定。因此，为保持有用性，系

统必须演变。进行有关更改（软件维护）可能涉及到重复以前的过程阶段。

瀑布模型的优点在于每个阶段都编制文件，而且它与其他的工程过程模型相 符合。其主

要问题在于将项目僵硬地划分成不同的阶段。在过 程的一个早期阶段，必须定下决心，从而

..

.

使得应对客户需求变化很困难。

因此，只有在需求得到很好理解、在系统开发期间不可能发生根本性变化的情况下，才< /p>

应使用瀑布模型。然而，瀑布模型体现了在其他工程项目中所使 用的过程模型类型。所以，

基于这种方法的软件过程仍然用于 软件开发，特别是当有关软件项目是一个较大系统工程项

目的一部分时。

三、演化开发

演化开发基于这样的思 想：开发一个初始的实现，让其接受用户评论，并让其经过多个

版本的改进，一直到开发出能够满足需要的系统（图

5A-2

）。规格说明、开发及验证活动不

是分开进行，而是交叉进行，各项活动之间有快速的信息反馈。

演化开发有两个基本类型：

1

、

探索式 开发。在这种类型中，过程的目标是与客户协作探索其需求，并交付一个最

< br>

中间

版本

并行活动

图

5A-2

：演化开发

描述

最终

版本

初始

版本

开发

验证

规格说明

断演变。

2

、

抛弃式 原型开发。在这种类型中，演化开发过程的目标是理解客户的需求，从而为

< /p>

在生产满足客户眼下需要的系统时，软件开发的演化方法常常比瀑布方法有效。基于演

化方法的软件过程的优点是，规格说明可以渐进地开发。随着用户 增进对其问题的理解，这

种理解可以反映在软件系统中。然而 ，从工程和管理的角度来看，演化方法存在两个问题：

1

、

过程缺 乏可视性。管理员需要定期交付的产品来衡量进度。在快速开发系统的情况

下，编制反映每个系统版本的文件不合算。

2

、

系统常 常缺乏良好的结构。不断的更改往往会破坏软件的结构。吸收软件更改变得

越来越困难，越来越成本高昂。

对于 中小型系统（上至

50

万行代码），演化方法或许是最佳的开发 方法。对于不同小组

开发系统不同部分的大型、复杂、长寿命 系统，演化开发存在的问题尤为严重。使用这种方

法难以建立 一个稳定的系统体系结构，这使得集成各小组的贡献变得很难。

对于大型系统，建议使用一种混合过程，将瀑布模型和演化开发模型的最佳特征结合起

来。这可能涉及到使用演化方法开发一个抛弃式原型，以解决系统规格说明中存在的不确 定

性。然后，可使用一种结构化程度比较高的方法重新实现系 统。得到很好理解的系统部分可

使用基于瀑布模型的过程进行 规格说明和开发。事先难以进行规格说明的其他系统部分，如

用户界面，无例外地应使用探索式编程方法来开发。

四、基于组件的软件工程

大多数软件 项目都存在某种程度的软件复用。通常，这是非正式发生的。参加项目的人

要对其进行修改，并将其吸收进他们的系统。对于使用演化方法进行快 速系统开发，复用常

常是必要的。

..

.

这种非正式复用的发生是不 考虑所使用的开发过程的。然而，在过去几年中，出现了一

种 软件开发方法，这种方法使用得越来越多，它依靠复用，被称为基于组件的软件工程。

这种面向复用的方法依靠大量的可复用软件组件，以及用于这些组件的某种集成框架。< /p>

有时，这些组件本身就是可提供文本格式化或数值计算等特定功 能的系统（商用现成系统）。

基于组件的软件工程的类属过程 模型如图

5A-3

所示。

中间阶段与其他过程不同。这些阶段是：

1

、

组件分 析。在有需求规格说明的情况下，搜索实现该规格的组件。通常，不存在完

2

、

需求修 改。在这个阶段，使用已经发现的组件的相关信息分析需求，然后修改需求

< br>

索可供选择的解决方案。

3

、

带复用 的系统设计。在这个阶段，设计系统框架或复用现有的框架。设计员考虑到

< br>

能得设计一些新软件。

4

、

开发与 集成。无法外部获得的软件要进行开发，组件和商用现成系统要集成以创建

基于组件的软件工程具有减少需要开发的软件量并因此降低成本与风险的明显 优点。它

通常也可更快地交付软件。然而，需求方面的妥协不 可避免，这可能导致系统不能满足用户

的真正需要。此外，可 复用组件的新版本不受其使用机构的控制，因此丧失了对系统演变的

某些控制。

图

5A-3

：基于组件的软件工程

需求

规格说明

组件

分析

需求

修改

带复用的

系统设计

系统

验证

开发与

集成

第六单元：数据库

课文

A

：数据库概览

一、引言

数据存储传统上是使用单独 的没有联系的文件，这些文件有时称为平面文件。在过去，

一 个机构中的每个应用程序都使用自己的文件。例如，在一个大学中，每个部门都可能有其

自己的文件集：档案办公室保存着关于学生信息和学生成绩的文件；经济资助办公室保存 着

其自己的关于需要经济资助以继续学业的学生的文件；调度 办公室保存着教授的姓名和他们

所教的课程；工薪发放部门保 存着其自己的关于全体教职员工（包括教授）的文件，等等。

然而，所有这些平面文件今天都可结合成一个实体

——

供整个大 学使用的数据库。

虽然难以给出一个普遍接受的数据库定义， 但我们使用下面常见的定义：一个数据库是

被一个机构内的应 用程序所使用的具有逻辑相干性的相关数据的集合。

二、数据库管理系统

数据库管理系统 定义、创建和维护数据库。数据库管理系统也允许对数据库中的数据进

..

.

行受控的访问。一个数据库 管理系统由

5

个组成部分构成：硬件、软件、数据、用户和规程 。

1

、硬件

硬件是指允许访问数据的计算机物理系统。例如，终端、硬盘、主机和工作站被认为是< /p>

数据库管理系统的硬件组成部分。

2

、软件

软 件是指允许用户访问、维护和更新数据的实际程序。另外，软件还控制着哪个用户可

以对数据库中的哪部分数据进行访问。

3

、数据

数 据库中的数据存储在物理存储设备上。在一个数据库中，数据是独立于对其进行访问

< /p>

的软件的一个实体。这种独立使一个机构可以在不必更改物理数据及其存储方式的情况下更

改软件。如果一个机构决定使用一个数据库管理系统，那么该 机构所需要的所有信息都应作

为一个实体保存在一起，可由数据库管理系统中的软件访问。

4

、用户

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

用户和应用程序。

最终用户是指可直 接访问数据库以获取信息的人。最终用户又分为两类：数据库管理员

< br>和普通用户。数据库管理员拥有最高程度的特权，可以控制其他用户及其对数据库管理系统

的访问，可以将其某些特权授予其他人并保留随时收回这些特权的能力。另一 方面，普通用

户只能使用数据库的一部分，只能进行有限的访问。

数据库中数据的其他用户就是应用程序。应用程序需要访问和处理数据。例如，工薪发

放应用程序需要在月底访问数据库中的部分数据，来开支付工薪的支票。

5

、规程

数据库管理系统的最后一个组成部分就是应该明确定义并为数据库用户所遵循的一套

规程或规则。

三、数据库体系结构

美国国家标准协 会标准计划与需求委员会（

ANSI/SPARC

）为数据库管 理系统确立了一

个包含

3

6A-1

）。

1

、内层

内 层决定数据在存储设备上的实际存储位置。该层涉及低级访问方法，以及字节如何传

向和传自存储设备。换句话说，内层直接与硬件交互。

2

、概念层

概念层定义数据的逻辑视图。数据模型在该层定义，数据库管理系统的主要功能

——

如

查询

——

也在该层。数据库管理系统把数据的内部视图转化为用户需要看到的外部视图。概