1、西安电子科技大学出版社西安电子科技大学出版社 Http:/ 软件技术基础 周大为钟桦周大为钟桦 朱虎有潘晓珠朱虎有潘晓珠 姚若玉编著姚若玉编著 21世纪高等学校电子信息类规划教材世纪高等学校电子信息类规划教材 目目 录录 第第1章章 软件工程软件工程 第第2章章 数据结构概述数据结构概述 第第3章章 线性表线性表 第第4章章 栈和队列栈和队列 第第5章章 串和数组串和数组 第第6章章 树树 第第7章章 图图 第第8章章 查找查找 第第9章章 排序排序 第第10章章 操作系统操作系统 第第11章章 数据库系统及其应用数据库系统及其应用 谢谢使用！谢谢使用！ 策策 划：马武装划：马武装 制制 作：
2、张囡英作：张囡英 监监 制：梁家新制：梁家新 单单 位：西安电子科技大学出版社位：西安电子科技大学出版社 电电 话：话：029-88204256 029-88201467 (发行发行) 传传 真：真：029-88232746 主主 页：页：http:/ E-mail： xdupfxb001 (发行发行) 1.1 软件的基本概念 1.2 软件工程 1.3 软件生存周期 1.4 结构化的软件开发方法 1.5 面向对象的软件开发方法 习题1 1.1.1 软件的特征软件的特征 要理解软件的含义，首先要 了解软件的特征。软件是逻辑的 而不是物理的产品，因此，软件 具有与硬件完全不同的特征。 (1) 软件
3、的开发不是传统意义 上的生产制造。 软件开发与硬件制造之间有 一些相似之处，但却有着本质的 区别。软件产品的生产主要是脑 力劳动、手工开发方式，大部分 产品是“定做”的。 1.1 软件的基本概念软件的基本概念 (2) 软件不会“磨损”。 硬件在其生命初期有较高的故障率(这些故障主要是设 计或制造的缺陷)，这些缺陷修正之后，故障率在一段时间 内会降到一个很低的水平；随着时间的推移，故障率又将 提升。硬件故障率的变化曲线如图1.1所示。 图1.1 硬件故障率的变化曲线 软件并不受引起硬件磨损的 环境因素的影响。因此，理论上 讲，软件的故障率曲线呈现出如 图1.2所示的形式。软件在其生命 初期具有较
4、高的故障率，但在这 些错误改正之后(我们假设理想情 况下改正过程中并不引入其他错 误)，曲线就会趋于平稳。软件不 会被磨损，不过它会退化，这一 点可以通过图1.2来解释清楚。在 其生命期中，软件会经历修改(维 护)，随着这些修改有可能会引入 新的错误，使得故障率曲线呈现 为图1.2所示的锯齿形。 图1.2 软件故障率的理想曲线与实际曲线 硬件和软件之间的不同还表 现在当一个硬件构件磨损时，可 以用另外一个备用零件替换它， 但对于软件就没有备用零件可以 替换了。每一个软件故障都表明 了设计或是将设计转换成机器可 执行代码的过程中存在错误。因 此，软件维护要比硬件维护复杂 得多。 (3) 软件的可
5、复用性差，不能 通过已有的构件组装而成。 我们先来看一下一个基于微 处理器的控制硬件是如何设计和 建造出来的。设计工程师画一个 简单的数字电路图，做一些基本 的分析以保证可以实现预定的功 能，然后查阅所需的元器件的目 录，每一个集成电路(通常称为 “IC”或“芯片”)都有一个零件 编号、固定的功能、定义好的接 口和一组标准的集成指南，每一 个选定的零件都可以买到，由此 可以很方便地组装起一个基于微 处理器的控制硬件。 在软件开发中，采用一些已 有的构件组建一个软件的方法， 仅仅在小范围内得到应用。多数 软件的设计开发还必须完全从零 开始。 1.1.2 软件的分类软件的分类 软件种类繁多，概括起
6、来可 分为两类：系统软件和应用软件。 1系统软件系统软件 系统软件是指操作系统及与 之相关的各种软件的总称。系统 软件是一组为其他程序服务的程 序。一类系统软件(如编译器、编 辑器和文件管理程序)所处理的信 息结构是复杂的，但又是确定的； 还有一类系统软件(如操作系统、 驱动程序和通信进程等)则处理大 量的非确定的信息。系统软件具 有以下特点： 与计算机硬件频繁交互； 支持多用户； 需要精细调度、资源共享 及灵活的进程管理的并发操作； 复杂的数据结构； 多外部接口； 具有可移植性，例如嵌入 式系统中的实时操作系统。 常见的操作系统有DOS、 UNIX、Linux以及Windows。 2应用软件
7、应用软件 应用软件是指为用户的特殊 应用目的而开发的软件。例如财 务管理软件、人力资源管理软件。 1.1.3 软件的发展软件的发展 今天，软件担任着双重角色， 它是一种产品，同时又是开发和 运行产品的载体。作为一种产品， 它扩充了计算机硬件的功能；作 为开发和运行产品的载体，它是 计算机控制 (操作系统)的基础、信息通信(网 络)的基础，也是创建和控制其他 程序(软件工具和环境)的基础。 计算机硬件的发展经历了四 个时代，同样，计算机软件的发 展也大致经历了四个阶段。 (1) 20世纪60年代中期以前， 是计算机系统发展的早期阶段。 在计算机发展的早期阶段， 大多数人把软件开发看成是不需 预先
8、计划的事情。计算机编程很 简单，没有什么系统化的方法。 软件的开发没有任何管理，一旦 进度拖后了或者成本提高了，程 序员才开始手忙脚乱地弥补。由 于那个时期的软件很简单，因而 他们的努力在一般情况下往往也 会见效。 当通用的硬件已经非常普遍 的时候，软件却相反，对每一类 应用均需自行设计，应用范围很 有限。此时，软件产品还处在婴 儿阶段，大多数软件均是由使用 它们的人员或组织自行开发的， 软件在使用过程中出现了问题， 编写软件的人员必须负责修改。 在这种个人化的软件开发环境中， 设计往往仅是人们头脑中的一种 模糊想法，而软件文档根本就不 存在。在早期，我们了解了很多 关于计算机系统的实现，但对
9、于 计算机系统工程却几乎一无所知。 (2) 从20世纪60年代中期到70 年代中期，是计算机系统发展的 第二阶段。 计算机系统发展的第二阶段 跨越了从20世纪60年代中期到70 年代中期的十余年。其主要特征 是：多道程序设计、多用户系统 引入了人机交互的新概念；交互 技术打开了计算机应用的新世界 及硬件和软件配合的新层次；实 时系统能够从多个源收集、分析 和转换数据，使得进程的控制和 输出的产生以毫秒而不是分钟来 进行；在线存储的发展导致了第 一代数据库管理系统的出现。 第二阶段的一个特点就是软 件产品的使用和“软件作坊”的 出现。随着计算机应用领域的扩 大，来自工业界、政府和学术界 的人们纷
10、纷开始开发各类软件包， 并取得了巨大的经济利益。 随着计算机系统的增多，新 的问题出现了，当发现软件存在 错误或缺陷时，需要纠正部分代 码甚至全部代码；当用户需求发 生变化时，需要对软件进行修改； 当硬件环境更新时，需要修改软 件以适应硬件的变化。这些活动 统称为软件维护。在软件维护上 所花费的精力开始以惊人的速度 消耗资源。更糟糕的是，许多程 序的个人化特性使得它们根本不 能维护。这就是所谓的“软件危 机”。 (3) 计算机系统发展的第三个 阶段从20世纪70年代中期开始， 并且跨越了整整10年。 在分布式系统中，多台计算 机之间的分布式处理和通信极大 地提高了计算机系统的复杂性。 广域网和
11、局域网、高带宽数字通 信以及对“即时”数据访问需求 的增加都对软件开发者提出了更 高的要求。然而，软件仍然继续 应用于工业界和学术界，个人应 用很少。第三阶段的另外一个特 点是微处理器的出现和广泛应用， 微处理器的出现使得一系列智能 产品纷纷面世，大到汽车，小到 微型医疗设备等，使计算机的应 用真正成为大众化的应用。 (4) 计算机系统发展的第四个 阶段已经不再着重于单台计算机 和计算机程序，而是面向计算机 和软件的综合影响。 20世纪70年代后由复杂的操 作系统控制的功能强大的计算机、 广域网和局域网，配以先进的应 用软件已成为标准。计算机体系 结构迅速从集中的主机环境转变 为分布的客户机/
12、服务器环境。世 界范围的信息网提供了一个基本 结构，使得“信息高速公路”和 “网际空间连通”成为可能。事 实上，Internet可以看做是能够被 单个用户访问的“软件”。 软件产业在世界经济中不再 是无足轻重的，由产业巨子(如微 软)所做的一个决定可能会带来成 百上千亿美元的风险。随着第四 阶段的进展，一些新技术开始涌 现。面向对象技术在许多领域中 迅速取代了传统软件开发方法。 虽然关于“第五代”计算机的预 言仍是一个未知数，但是软件开 发的“第四代技术”确实改变了 软件界开发计算机程序的方式。 专家系统和人工智能软件终于从 实验室里走了出来，进入了实际 应用，解决了现实世界中的大量 问题。结
13、合模糊逻辑应用的人工 神经网络软件揭示了模式识别和 类似人的信息处理能力的可能性。 虚拟现实和多媒体系统使得与最 终用户的通信可以采用完全不同 的方法。“遗传算法”则提供了 可以驻留于大型并行生物计算机 上的软件的潜在可能性。 现将计算机软件的发展历程归纳于表 1.1。 表 1.1 计算机软件的发展历程 早 期 第二阶段 第三阶段 第四阶段 面向批处理 多用户 分布式系统 强大的桌面系统 有限的分布 实时 嵌入“智能” 面向对象技术 自定义软件 数据库 低成本硬件 专家系统 软件产品 消费者的影响 人工神经网络 并行计算 网络计算机 1.1.4 软件危机软件危机 1软件危机的概念软件危机的概念
14、 软件危机是指在计算机软件 的开发和维护过程中所遇到的一 系列严重问题。这些问题不仅仅 是不能正常运行的软件才具有的， 实际上，几乎所有软件都不同程 度地存在这些问题，如开发周期 延长，成本增加，可靠性降低等。 具体来说，软件危机主要有 以下一些典型表现： (1) 对软件开发成本和进度的 估计常常很不准确。 (2) 用户对“已完成的”软件 系统不满意。 (3) 软件产品的质量不可靠。 (4) 软件常常是不可维护的。 (5) 软件通常没有适当的文档 资料。 (6) 软件成本在计算机系统总 成本中所占的比例逐年上升。 (7) 软件开发生产率提高的速 度，既跟不上硬件的发展速度， 也远远跟不上计算机
15、应用迅速普 及、深入的趋势。 以上列举的仅仅是软件危机的一 些明显表现，与软件开发和维护 有关的问题远远不止这些。 在软件产业中，“危机”已 经伴随我们走过了30多年的历程。 面向对象方法(OO)就是在这种背 景下诞生的，它使业界看到了成 功的希望，同时也促使OO方法和 技术的研究得以迅速发展。 2产生软件危机的原因产生软件危机的原因 在软件开发和维护的过程中 之所以存在这么多问题，一方面 与软件本身的特点有关，另一方 面也和软件开发与维护的方法不 正确有关。 与软件开发和维护有关的许 多错误认识和做法的形成，可以 归因于在计算机系统发展的早期 阶段软件开发的个体化特点。错 误的认识和做法主要
16、表现为忽视 软件需求分析的重要性，认为软 件开发就是写程序并设法使之运 行，轻视软件维护等。 了解产生软件危机的原因， 澄清错误认识，建立起关于软件 开发和维护的正确概念，仅仅是 解决软件危机的开始，全面解决 软件危机需要一系列综合措施。 3消除软件危机的途径消除软件危机的途径 为了消除软件危机，首先应 该对计算机软件有一个正确的认 识，应该推广使用在实践中总结 出来的开发软件的成功的技术和 方法，并且研究探索更好、更有 效的技术和方法，尽快消除在计 算机系统早期发展阶段形成的一 些错误概念和做法，应该开发和 使用更好的软件工具。 总之，为了消除软件危机， 既要有技术措施(方法和工具)， 又要
17、有必要的组织管理措施。软 件工程正是从管理和技术两方面 研究如何更好地开发和维护计算 机软件的一门新兴 学科。 1.2.1 软件工程的基本概念软件工程的基本概念 概括地说，软件工程是指导 计算机软件开发和维护的工程学 科。采用工程的概念、原理、技 术和方法来开发与维护软件，把 经过时间考验而证明正确的管理 技术和方法与当前能够得到的最 好的技术和方法相结合，经济地 开发出高质量的软件并有效地维 护它，这就是软件工程。 下面我们给出软件工程的基 本原理，以期对软件工程的概念 有更深刻的理解。 1.2 软软 件件 工工 程程 (1) 用分阶段的生命周期计划 严格管理。 (2) 坚持进行阶段评审。
18、(3) 实行严格的产品控制。 (4) 采用现代程序设计技术。 (5) 结果应能清楚地审查。 (6) 开发小组的人员应该少而 精。 (7) 承认不断改进软件工程实 践的必要性。 1.2.2 软件工程方法学软件工程方法学 通常把在软件生命周期全过 程中使用的一整套技术的集合称 为软件工程方法学。 软件工程方法学包括三个要 素：方法、工具和过程。其中， 方法是完成软件开发的各项任务 的技术方法，回答“如何做”的 问题；工具是为方法的运用提供 自动的或半自动的软件支撑环境； 过程是为了获得高质量的软件所 需要完成的一系列任务的框架， 它规定了完成各项任务的工作步 骤。 软件工程方法学分为结构化 方法、
19、Jackson方法、维也纳方法 （VDM）、面向对象方法。目前 使用最广泛的软件工程方法学是 传统方法学和面向对象方法学。 1.2.3 软件工程的目标软件工程的目标 软件工程的目标是提高软件 的质量与生产率，最终实现软件 的工业化生产。质量是软件需求 方最关心的问题。生产率是软件 供应方最关心的问题，老板和员 工都想用更少的时间挣更多的钱。 质量与生产率之间有着内在的联 系，高生产率必须以质量合格为 前提。从短期效益看，追求高质 量会延长软件开发时间并且增大 费用，似乎降低了生产率。从长 期效益看，高质量将保证软件开 发的全过程更加规范流畅，大大 降低了软件的维护代价，提高了 生产率，同时可获
20、得很好的信誉。 质量与生产率之间不存在根本的 对立，好的软件工程方法可以同 时提高质量与生产率。 质量与生产率的提高就是开 发人员与项目经理共同努力的结 果。对开发人员而言，如果非得 在质量与生产率之间分个主次不 可，那么应该是质量第一，生产 率第二。这是因为： (1) 质量直接体现在软件的每 段程序中，高质量自然是开发人 员的技术追求，也是职业道德的 要求。 (2) 高质量对所有的用户都有 价值，而高生产率只对开发方有 意义。 (3) 如果一开始就追求高生产 率，则容易留下隐患。宁可进度 慢些，也要保证每个环节的质量， 以图长远利益。 软件的质量因素很多，如正 确性、性能、可靠性、容错性、
21、易用性、灵活性、可扩充性、可 理解性、可维护性等。有些因素 相互重叠，有些因素则相互抵触， 要提高质量是非常不容易的。 软件工程的主要环节有人员 管理、项目管理，其中包括可行 性与需求分析、系统设计、程序 设计、测试、维护等，如图1.3所 示。 图1.3 软件工程的主要环节 1.3 软件生存周期软件生存周期 1.3.1 生存周期的划分及各阶段的主要任务生存周期的划分及各阶段的主要任务 概括地说，软件生存周期由软件定义、软件开发和运行 维护三个时期组成，每个时期又可进一步划分成若干个阶段。 下面简要介绍上述各个阶段应该完成的基本任务。 (1) 问题定义：问题定义阶段必须回答的关键问题是 “要解决
22、的问题是什么”。 (2) 可行性研究：这个阶段要回答的关键问题是“上一 个阶段所确定的问题是否有行得通的解决办法”。 (3) 需求分析：这个阶段的任 务仍然不是具体地解决客户的问 题，而是准确地回答“目标系统 必须做什么”这个问题。这个阶 段的另外一项重要任务是用正式 文档准确地记录对目标系统的需 求，这份文档通常称为需求说明 (specification)。 (4) 概要设计：这个阶段的基 本任务是概括地回答“怎样实现 目标系统”这个问题。概要设计 又称为初步设计、逻辑设计、高 层设计或总体设计。首先，应该 设计出实现目标系统的几种可能 的方案。概要设计的另一项主要 任务就是设计程序的体系结
23、构， 也就是确定程序由哪些模块组成 以及模块间的关系。 (5) 详细设计：概要设计阶段 以抽象概括的方式提出了解决问 题的办法。详细设计阶段的任务 就是把解法具体化，也就是回答 “应该怎样具体地实现这个系统” 这个关键问题。这个阶段的任务 还不是编写程序，而是设计出程 序的详细规格说明。 (6) 编码：这个阶段的关键任 务是写出正确的容易理解、容易 维护的程序模块。 (7) 测试：这个阶段的关键任 务是通过各种类型的测试(及相应 的调试)使软件达到预定的要求。 (8) 软件维护：维护阶段的关 键任务是，通过各种必要的维护 活动使系统持久地满足用户的需 要。通常有四类维护活动：改正 性维护，也就
24、是诊断和改正在使 用过程中发现的软件错误；适应 性维护，即修改软件以适应环境 的变化；完善性维护，即根据用 户的要求改进或扩充软件，使它 更完善；预防性维护，即修改软 件，为将来的维护活动做准备。 在实际从事软件开发工作时， 软件规模、种类、开发环境及开 发时使用的技术方法等因素会影 响阶段的划分。 生命周期模型规定了把生命 周期划分成哪些阶段及各个阶段 的执行顺序，因此，也称为过程 模型。 1.3.2 软件生存周期模型软件生存周期模型 软件开发方法是指在规定的 投资规模和时间限制内，为实现 符合用户需求的高质量软件所制 定的开发策略。人们提出了多种 软件开发策略，常见的软件设计 模型有瀑布模
25、型(Waterfall Model)、 增量模型(也叫渐进模 型)(Increamental Model)、快速原 型模型(Rapid Prototype Model)、 演化模型(Evolutionary Model)、 螺旋模型(Spiral Model)、喷泉模 型(Fountain Model)、智能模型 (Intelligent Model)等。这里介绍 其中主要的几种模型。 1瀑布模型瀑布模型 瀑布模型于1970年由 W.Royce提出，其开发过程依照 固定顺序进行，各阶段的任务与 工作结果如图1.4所示。该模型严 格规定各阶段的任务，上一阶段 任务的输出作为下一阶段工作的 输入。
26、此模型适合于用户需求明 确、开发技术比较成熟、工程管 理严格的场合使用。其缺点是， 由于任务顺序固定，软件研制周 期长，前一阶段工作中造成的差 错越到后期越大，而且纠正前期 错误的代价高。 在20世纪80年代之前，瀑布 模型一直是唯一被广泛采用的生 命周期模型，现在它仍是软件工 程中应用最广泛的过程模型。 图1.4 传统的瀑布模型 按照传统的瀑布模型来开发 软件，有如下几个特点： (1) 阶段间具有顺序性和依赖 性。 (2) 推迟实现的观点：清楚地 区分逻辑设计与物理设计，尽可 能推迟程序的物理实现，是按照 瀑布模型开发软件的一条重要的 指导思想。 (3) 质量保证的观点：每个阶 段都必须完成
27、规定的文档，没有 交出合格的文档就是没有完成该 阶段的任务；每个阶段结束前都 要对本阶段所完成的文档进行评 审，以便尽早发现问题，改正错 误。 瀑布模型的开发过程如表1.2 所示。 表 1.2 瀑布模型的开发过程 阶 段 基本任务 工作结果 问题定义 理解问题 系统目标与范围说明书 可行性研究 理解工作范围 项目计划任务书 需求分析 定义用户需求 需求规格说明书 总体设计 建立软件结构 总体设计说明书 详细设计 模块功能实现 程序规格说明书 编码 编写程序 程序清单 测试 发现错误、调试 软件产品 运行维护 运行和管理 改进的软件产品 实际的瀑布模型是带“反馈 环”的，如图1.5所示(图中实线
28、 箭头表示开发过程，虚线箭头表 示维护过程)。当在后面阶段发现 前面阶段的错误时，需要沿图中 左侧的反馈线返回前面的阶段， 在修正前面阶段的错误之后，再 回来继续完成后面阶段的任务。 图1.5 实际的瀑布模型 下面我们对瀑布模型的优缺 点作一总结。 瀑布模型具有顺序性和依赖 性，即后一阶段的工作必须在前 一阶段的工作完成后才能开始。 把逻辑设计与物理设计清楚地划 分开，是瀑布模型的重要指导思 想。 瀑布模型强调的是优质，即 每一步都循序渐进，及早消除隐 患，从而保证软件质量。它的致 命缺点在于只有做出精确的需求 分析，才能取得预期的结果。由 于各种客观、主观的原因，需求 分析往往不很精确，常常
29、给日后 的开发带来隐患。 2快速原型模型快速原型模型 原型是指模拟某种产品的原 始模型，在其它产业中经常使用 模型。例如，在建造一座楼房之 前，先按一定的比例建造一个缩 小的楼房模型，通过模型的外观、 形状和颜色等可以对所要建造的 楼房有一个直观的理解和认识。 软件开发中的原型不同于最 终的系统，两者在功能范围上的 区别在于最终系统要实现软件需 求的全部功能，而原型只实现所 选择的部分功能。最终系统对所 有的软件需求都必须详细实现， 而原型仅仅是为了试验和演示用 的，部分功能需求可以忽略或者 模拟实现。 快速原型模型的表示如图1.6 所示。图1.6(a)是原型本身的表示， 图1.6(b)说明了
30、原型的开发步骤。 可以看出，采用快速原型模型开 发软件经历了快速分析、构造原 型、运行原型、评价原型、根据 评价的结果进行修改这样一个过 程。 图1.6 快速原型模型 采用快速原型模型开发软件 时，在开发的整体上仍然采用瀑 布模型。按照引入原型的阶段不 同，快速原型分为以下三种类型： (1) 探索型：在需求分析阶段 引入原型，即用原型过程代替需 求分析。把原型作为需求说明的 补充形式，运用原型尽可能使需 求说明完整、准确、一致、无二 义性。 (2) 实验型：用原型过程代替 设计阶段，即在总体设计阶段使 用原型。快速分析实现软件系统 的方案，并构造出原型，然后通 过运行考察设计方案的可行性与 合
31、理性。 (3) 演化型：用原型过程代替 软件开发的全部阶段，通过原型 过程的反复循环演化，直至得到 软件系统。在开发过程中并不强 调严格的阶段性和高质量的阶段 性文档，不追求理想的开发模型。 3增量模型增量模型 增量模型也称为渐增模型， 如图1.7所示。使用增量模型开发 软件时，把软件产品作为一系列 的增量构件来设计、编码、集成 和测试。每个构件由多个相互作 用的模块构成，并且能够完成特 定的功能。使用增量模型时，第 一个增量构件往往实现软件的基 本需求，提供最核心的功能。 图1.7 增量模型 增量模型在各个阶段并不交 付一个可运行的完整产品，而是 交付满足客户需求的可运行产品 的一个子集。整
32、个产品被分解成 若干个构件，开发人员逐个构件 地交付产品。这样做的好处是软 件开发可以较好地适应变化，客 户可以不断地看到所开发的软件， 从而降低开发风险。但是，增量 模型也存在以下缺陷： (1) 由于各个构件是逐渐并入 已有的软件体系结构中的，所以 加入的构件不应当破坏已构造好 的系统部分，这需要软件具备开 放式的体系结构。 (2) 在开发过程中，需求的变 化是不可避免的。增量模型的灵 活性可以使其适应这种变化，这 一点大大优于瀑布模型和快速原 型模型，但也很容易退化为“边 做边改”的模型，从而使软件过 程的控制失去整体性。 4螺旋模型螺旋模型 软件开发几乎总要冒一定的 风险，因此，在软件开
33、发过程中 必须及时识别和分析风险，并且 采取适当措施以消除或减少风险 的危害。1988年，Barry Boehm正 式发表了软件系统开发的螺旋模 型。 螺旋模型的基本思想是将瀑 布模型和快速原型模型结合起来， 强调了其他模型所忽视的风险分 析，以尽量降低风险，其特别适 合于大型复杂的系统。 5喷泉模型喷泉模型(面向对象面向对象的生的生 存期模型存期模型, OO模型模型) 迭代是软件开发过程中普遍 存在的一种内在属性。经验表明， 软件过程是各个阶段之间的迭代 或一个阶段内各个工作步骤之间 的迭代。喷泉模型是一种以用户 需求为动力，以对象作为驱动的 模型，这种模型在面向对象范型 中比在结构化范型中
34、更常见。图 1.8所示的喷泉模型是典型的面向 对象生命周期模型。“喷泉”这 个词体现了面向对象软件开发过 程中迭代和无缝的特性。图1.8 喷泉模型 喷泉模型的固有特征是： 迭代，指多次重复、演进的过程； 无间隙，指各阶段间无明显的 界限，支持分析和设计结果的自 然复用。 图1.8 喷泉模型 喷泉模型与传统的结构化生 存期比较，具有更多的增量和迭 代性质，生存期的各个阶段可以 相互重叠和多次反复，而且在项 目的整个生存期中还可以嵌入子 生存期，就像水喷上去又可以落 下来，可以落在中间，也可以落 在最底部。为避免在使用喷泉模 型开发软件时开发过程过分无序， 应该把一个线性过程(例如，快速 原型模型
35、)作为总目标。但是，同 时也应该记住，面向对象范型本 身要求经常对开发活动进行迭代 或求精。 6各种模型的比较各种模型的比较 每个软件开发组织应该选择 适合于该组织的软件开发模型， 并且应该随着当前正在开发的特 定产品的特性而变化，以减小所 选模型的缺点，充分利用其优点。 表1.3列出了几种常见模型的优缺 点。 表 1.3 常见模型比较 模 型 优 点 缺 点 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能导致系统设计差、 效率低 螺旋模型 风险驱动 风险分析人员
36、需要有经验且经过充分训练 软件过程是为了获得高质量 软件产品所需要完成的一系列任 务的框架，它规定了完成各项任 务的工作步骤。软件过程必须科 学、合理，才能开发出高质量的 软件产品。 按照在软件生命周期全过程 中应完成的任务的性质，在概念 上可以把软件生命周期划分成问 题定义、可行性研究、需求分析、 概要设计、详细设计、编码和单 元测试、综合测试以及维护等八 个阶段。实际上，从事软件开发 工作时，软件规模、种类、开发 环境及使用的技术方法等因素， 都影响阶段的划分。因此，一个 科学、有效的软件过程应该定义 一组适合于所承担的项目特点的 任务集合。 生命周期模型(即软件过程模 型)规定了把生命周
37、期划分成的阶 段及各个阶段的执行顺序。本章 介绍了五类典型的软件生命周期 模型。 瀑布模型历史悠久、广为人 知，它的优势在于它是规范的、 文档驱动的方法；这种模型的问 题是，最终交付的产品可能不是 用户真正需要的。 快速原型模型正是为了克服 瀑布模型的缺点而提出来的。它 通过快速构建起一个可运行的原 型系统，让用户试用原型并收集 用户反馈意见的办法，来获取用 户的真实需求。但是，需要软件 法开发技术和工具支持，需要用 户参与开发过程，参与原型的运 行和评价。 增量模型具有能在软件开发 的早期使投资获得明显回报和易 于维护的优点。但是，要求软件 具有开放结构是使用这种模型时 固有的困难。 风险驱
38、动的螺旋模型适用于 大规模的内部开发项目。但是， 只有在开发人员具有风险分析和 排除风险的经验及专门知识时， 使用这种模型才会获得成功。 当使用面向对象范型开发软 件时，软件生命周期必须是循环 的，也就是说，软件过程必须支 持反馈和迭代。喷泉模型是一种 典型的适合于面向对象范型的过 程模型。 每个软件开发组织都应该选 择适合于本组织及所要开发的软 件特点的软件生命周期模型。这 样的模型应该把各种生命周期模 型的合适特性有机地结合起来， 以便尽量减少它们的缺点，充分 利用它们的优点。 1.4.1 系统分析与定义系统分析与定义 为了开发出真正满足用户需 求的软件产品，首先必须知道用 户的需求。对软
39、件需求的深入理 解是软件开发工作获得成功的前 提和关键。不论我们把设计和编 码工作做得如何出色，不能真正 满足用户需求的软件只会给用户 带来失望，给开发者带来烦恼。 传统的软件工程方法学采用 结构化分析(Structured Analysis， SA)技术来完成需求分析工作。 1.4 结构化的软件开发方法结构化的软件开发方法 1需求分析的任务需求分析的任务 需求分析是发现、求精、建 模、规格说明和复审的过程。为 了发现用户的真正需求，首先应 该从宏观角度调查、分析用户所 面临的问题，也就是说，需求分 析的第一步是尽可能准确地了解 用户当前的情况和需要解决的问 题。 分析员对用户提出的初步要 求
40、应该反复求精、多次细化，才 能充分理解用户的需求，得出对 目标系统的完整、准确和具体的 要求。 为了更好地理解问题，人们 常常采用建立模型的方法。所谓 模型，就是为了理解事物而对事 物做出的一种抽象，是对事物的 一种无歧义的书面描述。通常， 模型由一组图形符号和组织这些 符号的规则构成。结构化分析就 是一种建立模型的活动，通常建 立数据模型、功能模型和行为模 型等三种模型。 除了用分析模型表示软件需 求之外，还要写出准确的软件需 求规格说明。模型既是软件设计 的基础，也是编写软件规格说明 的基础。 在分析软件需求和编写软件 规格说明的过程中，软件开发者 和软件用户都起着关键的、必不 可少的作用
41、。 用户与开发者之间需要通信、 沟通的内容非常多，在双方交流 信息的过程中很容易出现误解或 遗漏，也可能存在二义性。因此， 不仅在整个需求分析过程中应该 采用行之有效的通信技术，集中 精力缜密工作，而且对需求分析 的结果(分析模型和规格说明)必 须严格审查。 尽管目前存在许多不同的结构化 分析方法，但是，所有这些分析 方法都遵守下述准则： 必须理解和表示问题的信 息域，根据这条准则应该建立数 据模型。 必须定义软件应完成的功 能，这条准则要求建立功能模型。 必须表示作为外部事件结 果的软件行为，这条准则要求建 立行为模型。 必须对描述信息、功能和 行为的模型进行分解，用层次的 方式展示细节。
42、分析过程应该从要素信息 移向实现细节。 2需求分析的方法需求分析的方法 软件需求分析是与用户通信 的过程，总是从两方或多方之间 的通信开始的。用户面临的问题 需要用基于计算机的方案来解决； 开发者应该对用户的需求作出反 应，给用户提供帮助，这样就产 生了相互通信的需求。 1) 访谈 访谈(或称为会谈)是最早开 始运用的获取用户需求的技术， 也是迄今为止仍然广泛使用的主 要的需求分析技术。 访谈有两种基本形式，分别 是正式的和非正式的访谈。在正 式的访谈中，系统分析员将提出 一些事先准备好的具体问题，例 如，询问客户公司销售的商品种 类、雇用的销售人员数目以及信 息反馈时间的长短等。在非正式 的
43、访谈中，将提出一些可以自由 回答的开放性问题，以鼓励被访 问的人员表达自己的想法，例如， 询问用户为什么对目前正在使用 的系统感到不满意。当需要调查 大量人员的意见时，向被调查的 人员分发调查表是一个十分有效 的做法。 在对用户进行访谈的过程中， 使用情景分析技术往往非常有效。 所谓情景分析，就是对用户运用 目标系统解决某个具体问题的方 法和结果进行分析。 2) 简易的应用规格说明技术 这种方法提倡用户与开发者 密切合作，共同标识问题，提出 解决方案的要素，商讨不同的方 法并指定基本的需求。现在，简 易的应用规格说明技术已经成为 信息系统界使用的主流技术。尽 管存在许多不同的简易应用规格 说明
44、方法，但是它们遵循的基本 准则是相同的。 在中立地点举行由开发者 和用户双方出席的会议。 制定准备会议和参加会议 的规则。 提出一个议事日程，这个 日程应该足够正式，以便能够涵 盖所有要点；同时，这个日程又 应该足够非正式，以便鼓励自由 思维。 由一个“协调人”来主持 会议，他既可以是用户，也可以 是开发者，还可以是从外面请来 的人。 使用一种“定义机 制”(例如，工作表、图表等)。 目标是标识问题、提出解 决方案的要素，商讨不同的方案 并制定初步的需求。 3) 构建软件原型 构建原型的要点是，应该实 现用户看得见的功能(例如屏幕显 示或打印报表)，省略目标系统的 “隐含”功能(例如修改文件)
45、。 快速原型应该具备的第一个 特性是“快速”。快速原型的目 的是尽快向用户提供一个可在计 算机上运行的目标系统的模型， 以便使用户和开发者在目标系统 应该“做什么”这个问题上尽可 能快地达成共识。 快速原型应该具备的第二个 特性是“容易修改”。如果原型 的第一版不是用户所需要的，就 必须根据用户的意见迅速地修改 它，构建出原型的第二版，以更 好地满足用户的需求。在实际开 发软件产品时，“修改试用 反馈”的过程可能要重复多遍， 如果修改耗时过多，则势必延误 软件开发时间。 3分析建模和软件需求规分析建模和软件需求规 格说明格说明 结构化分析实质上是一种创 建模型的活动。通过需求分析而 建立的模型
46、必须达到下述三个基 本目标：描述用户的需求；为软 件设计工作奠定基础；定义一组 需求，一旦开发出软件产品之后， 就可以用这组需求作为标准来验 收该产品。为了达到上述目标， 在结构化分析过程中导出的分析 模型的形式如图1.9所示。 通过需求分析除了创建分析 模型之外，还应该写出软件需求 规格说明，它是分析阶段的最终 成果。 图1.9 分析模型的结构 4实体实体关系图关系图 数据模型包含三种相互关联 的信息：数据对象、描述数据对 象的属性及数据对象彼此间相互 连接的关系。 数据对象：是对软件必须理 解的复合信息的表示。所谓复合 信息，是指具有一系列不同性质 或属性的事物，因此，仅有单个 值的事物(
47、例如宽度)不是数据对 象。 属性：定义了数据对象的性 质，应根据对所要解决的问题的 理解，来确定特定数据对象的一 组合适的属性。 关系：数据对象彼此之间相 互连接的方式称为关系，也称为 联系。关系分为一对一联系 (1 1)，一对多联系(1 N)，多 对多联系(M N)。其中多对多联 系也具有属性。 用实体关系图(Entity Relationship Diagram)建立的数据 模型简称为E-R图。相应地，用 E-R图描绘的数据模型也可以称 为E-R模型。 E-R图中包含了实体(即数据 对象)、关系和属性等三种基本成 分。通常用矩形框代表实体，用 连接相关实体的菱形框表示关系， 用椭圆形或圆角
48、矩形表示实体(或 关系)的属性，并用无向边把实体 (或关系)与其属性连接起来。例 如，图1.10是某学校教学管理的 E-R图。 图1.10 某学校教学管理的E-R图 5数据流图数据流图 当数据在软件中移动时，它 将被一系列“变换”所修改。数 据流图(DFD)是一种图形化技术， 它描绘信息流和数据从输入移动 到输出的过程中所经受的变换。 如图1.11所示，数据流图有 四种基本符号：正方形(或立方体) 表示数据的源点或终点，是系统 之外的人员或组织；圆形(或圆角 矩形)代表变换数据的处理；两条 平行横线(或矩形)代表数据存储； 箭头表示数据流，即特定数据的 流动方向。源点/终点与处理、处 理与处理
49、之间的数据流应当具有 名称，与数据存储有关的数据流 的名称可以省略，因为用数据存 储的名称就可以清楚表示了。 图1.11 数据流图的基本符号 下面通过一个简单例子来具 体说明怎样画数据流图。 【例例1.1】 假设一家工厂的 采购部每天需要一张订货报表， 报表按零件编号排序，表中列出 所有需要再次订货的零件。对于 每个需要再次订货的零件，应该 列出下述数据：零件编号、零件 名称、定货数量、目前价格、主 要供应者和次要供应者。零件入 库或出库称为事务，通过放在仓 库中的CRT终端把事务报告给订 货系统。当某种零件的库存数量 少于库存量临界值时，就应该再 次订货。 数据流图有四种成分：源点 或终点、处理、数据存储和数据 流。因此，可采用以下步骤画出 订货系统的数据流图。 首先要从问题描述中提取数 据流图的四种成分，接下来考虑 数据的处理与加工，最后考虑数 据存储和数据流。一旦把数据流 图的四种成分都分离出来以后， 就可以着手画数据流图了。任何 系统的基本模型都是由若干个数 据源点/终点以及一个处理组成的， 这个处理就代表了系统对数据加 工变换的基本功能。对于上述的 订货系统可以画出如图1.12所示 的顶层数据流图来表示基本系统 模型，在顶层和数据流图中突出 表明了数据的源点、终点和系统 的输入、输出。 图1.12 订货系统的基本系统模型顶层数据流图 下一步应该把基本系统模型 细化，得到
