软件技术基础.ppt

《软件技术基础.ppt》由会员分享，可在线阅读，更多相关《软件技术基础.ppt（315页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、第1章软件工程1.1 软件的基本概念 1.2 软件工程 1.3 软件生存周期 1.4 结构化的软件开发方法 1.5 面向对象的软件开发方法 习题1 第1章软件工程1.1.1 软件的特征软件的特征要理解软件的含义，首先要了解软件的特征。软件是逻辑的而不是物理的产品，因此，软件具有与硬件完全不同的特征。(1)软件的开发不是传统意义上的生产制造。软件开发与硬件制造之间有一些相似之处，但却有着本质的区别。软件产品的生产主要是脑力劳动、手工开发方式，大部分产品是“定做”的。1.1 软件的基本概念软件的基本概念第1章软件工程(2)软件不会“磨损”。硬件在其生命初期有较高的故障率(这些故障主要是设计或制造的

2、缺陷)，这些缺陷修正之后，故障率在一段时间内会降到一个很低的水平；随着时间的推移，故障率又将提升。硬件故障率的变化曲线如图1.1所示。第1章软件工程图1.1 硬件故障率的变化曲线第1章软件工程软件并不受引起硬件磨损的环境因素的影响。因此，理论上讲，软件的故障率曲线呈现出如图1.2所示的形式。软件在其生命初期具有较高的故障率，但在这些错误改正之后(我们假设理想情况下改正过程中并不引入其他错误)，曲线就会趋于平稳。软件不会被磨损，不过它会退化，这一点可以通过图1.2来解释清楚。在其生命期中，软件会经历修改(维护)，随着这些修改有可能会引入新的错误，使得故障率曲线呈现为图1.2所示的锯齿形。第1章软

3、件工程图1.2 软件故障率的理想曲线与实际曲线第1章软件工程硬件和软件之间的不同还表现在当一个硬件构件磨损时，可以用另外一个备用零件替换它，但对于软件就没有备用零件可以替换了。每一个软件故障都表明了设计或是将设计转换成机器可执行代码的过程中存在错误。因此，软件维护要比硬件维护复杂得多。第1章软件工程(3)软件的可复用性差，不能通过已有的构件组装而成。我们先来看一下一个基于微处理器的控制硬件是如何设计和建造出来的。设计工程师画一个简单的数字电路图，做一些基本的分析以保证可以实现预定的功能，然后查阅所需的元器件的目录，每一个集成电路(通常称为“IC”或“芯片”)都有一个零件编号、固定的功能、定义好

4、的接口和一组标准的集成指南，每一个选定的零件都可以买到，由此可以很方便地组装起一个基于微处理器的控制硬件。在软件开发中，采用一些已有的构件组建一个软件的方法，仅仅在小范围内得到应用。多数软件的设计开发还必须完全从零开始。第1章软件工程1.1.2 软件的分类软件的分类软件种类繁多，概括起来可分为两类：系统软件和应用软件。1系统软件系统软件系统软件是指操作系统及与之相关的各种软件的总称。系统软件是一组为其他程序服务的程序。一类系统软件(如编译器、编辑器和文件管理程序)所处理的信息结构是复杂的，但又是确定的；还有一类系统软件(如操作系统、驱动程序和通信进程等)则处理大量的非确定的信息。系统软件具有以

5、下特点：第1章软件工程 与计算机硬件频繁交互；支持多用户；需要精细调度、资源共享及灵活的进程管理的并发操作；复杂的数据结构；多外部接口；具有可移植性，例如嵌入式系统中的实时操作系统。常见的操作系统有DOS、UNIX、Linux以及Windows。2应用软件应用软件应用软件是指为用户的特殊应用目的而开发的软件。例如财务管理软件、人力资源管理软件。第1章软件工程1.1.3 软件的发展软件的发展今天，软件担任着双重角色，它是一种产品，同时又是开发和运行产品的载体。作为一种产品，它扩充了计算机硬件的功能；作为开发和运行产品的载体，它是计算机控制(操作系统)的基础、信息通信(网络)的基础，也是创建和控制

6、其他程序(软件工具和环境)的基础。计算机硬件的发展经历了四个时代，同样，计算机软件的发展也大致经历了四个阶段。第1章软件工程(1)20世纪60年代中期以前，是计算机系统发展的早期阶段。在计算机发展的早期阶段，大多数人把软件开发看成是不需预先计划的事情。计算机编程很简单，没有什么系统化的方法。软件的开发没有任何管理，一旦进度拖后了或者成本提高了，程序员才开始手忙脚乱地弥补。由于那个时期的软件很简单，因而他们的努力在一般情况下往往也会见效。第1章软件工程当通用的硬件已经非常普遍的时候，软件却相反，对每一类应用均需自行设计，应用范围很有限。此时，软件产品还处在婴儿阶段，大多数软件均是由使用它们的人员

7、或组织自行开发的，软件在使用过程中出现了问题，编写软件的人员必须负责修改。在这种个人化的软件开发环境中，设计往往仅是人们头脑中的一种模糊想法，而软件文档根本就不存在。在早期，我们了解了很多关于计算机系统的实现，但对于计算机系统工程却几乎一无所知。第1章软件工程(2)从20世纪60年代中期到70年代中期，是计算机系统发展的第二阶段。计算机系统发展的第二阶段跨越了从20世纪60年代中期到70年代中期的十余年。其主要特征是：多道程序设计、多用户系统引入了人机交互的新概念；交互技术打开了计算机应用的新世界及硬件和软件配合的新层次；实时系统能够从多个源收集、分析和转换数据，使得进程的控制和输出的产生以毫

8、秒而不是分钟来进行；在线存储的发展导致了第一代数据库管理系统的出现。第1章软件工程第二阶段的一个特点就是软件产品的使用和“软件作坊”的出现。随着计算机应用领域的扩大，来自工业界、政府和学术界的人们纷纷开始开发各类软件包，并取得了巨大的经济利益。随着计算机系统的增多，新的问题出现了，当发现软件存在错误或缺陷时，需要纠正部分代码甚至全部代码；当用户需求发生变化时，需要对软件进行修改；当硬件环境更新时，需要修改软件以适应硬件的变化。这些活动统称为软件维护。在软件维护上所花费的精力开始以惊人的速度消耗资源。更糟糕的是，许多程序的个人化特性使得它们根本不能维护。这就是所谓的“软件危机”。第1章软件工程(

9、3)计算机系统发展的第三个阶段从20世纪70年代中期开始，并且跨越了整整10年。在分布式系统中，多台计算机之间的分布式处理和通信极大地提高了计算机系统的复杂性。广域网和局域网、高带宽数字通信以及对“即时”数据访问需求的增加都对软件开发者提出了更高的要求。然而，软件仍然继续应用于工业界和学术界，个人应用很少。第三阶段的另外一个特点是微处理器的出现和广泛应用，微处理器的出现使得一系列智能产品纷纷面世，大到汽车，小到微型医疗设备等，使计算机的应用真正成为大众化的应用。第1章软件工程(4)计算机系统发展的第四个阶段已经不再着重于单台计算机和计算机程序，而是面向计算机和软件的综合影响。20世纪70年代后

10、由复杂的操作系统控制的功能强大的计算机、广域网和局域网，配以先进的应用软件已成为标准。计算机体系结构迅速从集中的主机环境转变为分布的客户机/服务器环境。世界范围的信息网提供了一个基本结构，使得“信息高速公路”和“网际空间连通”成为可能。事实上，Internet可以看做是能够被单个用户访问的“软件”。第1章软件工程软件产业在世界经济中不再是无足轻重的，由产业巨子(如微软)所做的一个决定可能会带来成百上千亿美元的风险。随着第四阶段的进展，一些新技术开始涌现。面向对象技术在许多领域中迅速取代了传统软件开发方法。虽然关于“第五代”计算机的预言仍是一个未知数，但是软件开发的“第四代技术”确实改变了软件界

11、开发计算机程序的方式。专家系统和人工智能软件终于从实验室里走了出来，进入了实际应用，解决了现实世界中的大量问题。结合模糊逻辑应用的人工神经网络软件揭示了模式识别和类似人的信息处理能力的可能性。虚拟现实和多媒体系统使得与最终用户的通信可以采用完全不同的方法。“遗传算法”则提供了可以驻留于大型并行生物计算机上的软件的潜在可能性。第1章软件工程第1章软件工程1.1.4 软件危机软件危机1软件危机的概念软件危机的概念软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题，如开发周期延长，成本增加，可靠性

12、降低等。具体来说，软件危机主要有以下一些典型表现：(1)对软件开发成本和进度的估计常常很不准确。(2)用户对“已完成的”软件系统不满意。(3)软件产品的质量不可靠。(4)软件常常是不可维护的。第1章软件工程(5)软件通常没有适当的文档资料。(6)软件成本在计算机系统总成本中所占的比例逐年上升。(7)软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及、深入的趋势。以上列举的仅仅是软件危机的一些明显表现，与软件开发和维护有关的问题远远不止这些。在软件产业中，“危机”已经伴随我们走过了30多年的历程。面向对象方法(OO)就是在这种背景下诞生的，它使业界看到了成功的希望，

13、同时也促使OO方法和技术的研究得以迅速发展。第1章软件工程2产生软件危机的原因产生软件危机的原因在软件开发和维护的过程中之所以存在这么多问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。与软件开发和维护有关的许多错误认识和做法的形成，可以归因于在计算机系统发展的早期阶段软件开发的个体化特点。错误的认识和做法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。了解产生软件危机的原因，澄清错误认识，建立起关于软件开发和维护的正确概念，仅仅是解决软件危机的开始，全面解决软件危机需要一系列综合措施。第1章软件工程3消除软件危机的途径消除

14、软件危机的途径为了消除软件危机，首先应该对计算机软件有一个正确的认识，应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好、更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法，应该开发和使用更好的软件工具。总之，为了消除软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。第1章软件工程1.2.1 软件工程的基本概念软件工程的基本概念概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证

15、明正确的管理技术和方法与当前能够得到的最好的技术和方法相结合，经济地开发出高质量的软件并有效地维护它，这就是软件工程。下面我们给出软件工程的基本原理，以期对软件工程的概念有更深刻的理解。1.2 软软 件件 工工 程程第1章软件工程(1)用分阶段的生命周期计划严格管理。(2)坚持进行阶段评审。(3)实行严格的产品控制。(4)采用现代程序设计技术。(5)结果应能清楚地审查。(6)开发小组的人员应该少而精。(7)承认不断改进软件工程实践的必要性。第1章软件工程1.2.2 软件工程方法学软件工程方法学通常把在软件生命周期全过程中使用的一整套技术的集合称为软件工程方法学。软件工程方法学包括三个要素：方法

16、、工具和过程。其中，方法是完成软件开发的各项任务的技术方法，回答“如何做”的问题；工具是为方法的运用提供自动的或半自动的软件支撑环境；过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件工程方法学分为结构化方法、Jackson方法、维也纳方法（VDM）、面向对象方法。目前使用最广泛的软件工程方法学是传统方法学和面向对象方法学。第1章软件工程1.2.3 软件工程的目标软件工程的目标软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量是软件需求方最关心的问题。生产率是软件供应方最关心的问题，老板和员工都想用更少的时间挣更多的钱。质量与生产率

17、之间有着内在的联系，高生产率必须以质量合格为前提。从短期效益看，追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率。从长期效益看，高质量将保证软件开发的全过程更加规范流畅，大大降低了软件的维护代价，提高了生产率，同时可获得很好的信誉。质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生产率。第1章软件工程质量与生产率的提高就是开发人员与项目经理共同努力的结果。对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。这是因为：(1)质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求。(2)高质量对所有的用户

18、都有价值，而高生产率只对开发方有意义。(3)如果一开始就追求高生产率，则容易留下隐患。宁可进度慢些，也要保证每个环节的质量，以图长远利益。第1章软件工程软件的质量因素很多，如正确性、性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等。有些因素相互重叠，有些因素则相互抵触，要提高质量是非常不容易的。软件工程的主要环节有人员管理、项目管理，其中包括可行性与需求分析、系统设计、程序设计、测试、维护等，如图1.3所示。第1章软件工程图1.3 软件工程的主要环节第1章软件工程1.3 软件生存周期软件生存周期1.3.1 生存周期的划分及各阶段的主要任务生存周期的划分及各阶段的主要任务概括

19、地说，软件生存周期由软件定义、软件开发和运行维护三个时期组成，每个时期又可进一步划分成若干个阶段。下面简要介绍上述各个阶段应该完成的基本任务。(1)问题定义：问题定义阶段必须回答的关键问题是“要解决的问题是什么”。(2)可行性研究：这个阶段要回答的关键问题是“上一个阶段所确定的问题是否有行得通的解决办法”。第1章软件工程(3)需求分析：这个阶段的任务仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。这个阶段的另外一项重要任务是用正式文档准确地记录对目标系统的需求，这份文档通常称为需求说明(specification)。(4)概要设计：这个阶段的基本任务是概括地回答“怎

20、样实现目标系统”这个问题。概要设计又称为初步设计、逻辑设计、高层设计或总体设计。首先，应该设计出实现目标系统的几种可能的方案。概要设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。第1章软件工程(5)详细设计：概要设计阶段以抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答“应该怎样具体地实现这个系统”这个关键问题。这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。(6)编码：这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。(7)测试：这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预

21、定的要求。第1章软件工程(8)软件维护：维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件，使它更完善；预防性维护，即修改软件，为将来的维护活动做准备。在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素会影响阶段的划分。生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序，因此，也称为过程模型。第1章软件工程1.3.2 软件生存周期模型软件生存周期模型软件开发方法是指在规定的投资

22、规模和时间限制内，为实现符合用户需求的高质量软件所制定的开发策略。人们提出了多种软件开发策略，常见的软件设计模型有瀑布模型(Waterfall Model)、增量模型(也叫渐进模型)(Increamental Model)、快速原型模型(Rapid Prototype Model)、演化模型(Evolutionary Model)、螺旋模型(Spiral Model)、喷泉模型(Fountain Model)、智能模型(Intelligent Model)等。这里介绍其中主要的几种模型。第1章软件工程1瀑布模型瀑布模型瀑布模型于1970年由W.Royce提出，其开发过程依照固定顺序进行，各阶段

23、的任务与工作结果如图1.4所示。该模型严格规定各阶段的任务，上一阶段任务的输出作为下一阶段工作的输入。此模型适合于用户需求明确、开发技术比较成熟、工程管理严格的场合使用。其缺点是，由于任务顺序固定，软件研制周期长，前一阶段工作中造成的差错越到后期越大，而且纠正前期错误的代价高。在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍是软件工程中应用最广泛的过程模型。第1章软件工程图1.4 传统的瀑布模型第1章软件工程按照传统的瀑布模型来开发软件，有如下几个特点：(1)阶段间具有顺序性和依赖性。(2)推迟实现的观点：清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按

24、照瀑布模型开发软件的一条重要的指导思想。(3)质量保证的观点：每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务；每个阶段结束前都要对本阶段所完成的文档进行评审，以便尽早发现问题，改正错误。瀑布模型的开发过程如表1.2所示。第1章软件工程第1章软件工程实际的瀑布模型是带“反馈环”的，如图1.5所示(图中实线箭头表示开发过程，虚线箭头表示维护过程)。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，在修正前面阶段的错误之后，再回来继续完成后面阶段的任务。第1章软件工程图1.5 实际的瀑布模型第1章软件工程下面我们对瀑布模型的优缺点作一总结。瀑布模型具有

25、顺序性和依赖性，即后一阶段的工作必须在前一阶段的工作完成后才能开始。把逻辑设计与物理设计清楚地划分开，是瀑布模型的重要指导思想。瀑布模型强调的是优质，即每一步都循序渐进，及早消除隐患，从而保证软件质量。它的致命缺点在于只有做出精确的需求分析，才能取得预期的结果。由于各种客观、主观的原因，需求分析往往不很精确，常常给日后的开发带来隐患。第1章软件工程2快速原型模型快速原型模型原型是指模拟某种产品的原始模型，在其它产业中经常使用模型。例如，在建造一座楼房之前，先按一定的比例建造一个缩小的楼房模型，通过模型的外观、形状和颜色等可以对所要建造的楼房有一个直观的理解和认识。软件开发中的原型不同于最终的系

26、统，两者在功能范围上的区别在于最终系统要实现软件需求的全部功能，而原型只实现所选择的部分功能。最终系统对所有的软件需求都必须详细实现，而原型仅仅是为了试验和演示用的，部分功能需求可以忽略或者模拟实现。第1章软件工程快速原型模型的表示如图1.6所示。图1.6(a)是原型本身的表示，图1.6(b)说明了原型的开发步骤。可以看出，采用快速原型模型开发软件经历了快速分析、构造原型、运行原型、评价原型、根据评价的结果进行修改这样一个过程。第1章软件工程图1.6 快速原型模型第1章软件工程采用快速原型模型开发软件时，在开发的整体上仍然采用瀑布模型。按照引入原型的阶段不同，快速原型分为以下三种类型：(1)探

27、索型：在需求分析阶段引入原型，即用原型过程代替需求分析。把原型作为需求说明的补充形式，运用原型尽可能使需求说明完整、准确、一致、无二义性。(2)实验型：用原型过程代替设计阶段，即在总体设计阶段使用原型。快速分析实现软件系统的方案，并构造出原型，然后通过运行考察设计方案的可行性与合理性。(3)演化型：用原型过程代替软件开发的全部阶段，通过原型过程的反复循环演化，直至得到软件系统。在开发过程中并不强调严格的阶段性和高质量的阶段性文档，不追求理想的开发模型。第1章软件工程3增量模型增量模型增量模型也称为渐增模型，如图1.7所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成

28、和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。第1章软件工程图1.7 增量模型第1章软件工程增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的可运行产品的一个子集。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：(1)由于各个构件是逐渐并入已有的软件体系结构中的，所以加入的构件不应当破坏已构造好的系统部分，这需要软件具备开放式的体系结构。(2)在开发过程中

29、，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化，这一点大大优于瀑布模型和快速原型模型，但也很容易退化为“边做边改”的模型，从而使软件过程的控制失去整体性。第1章软件工程4螺旋模型螺旋模型软件开发几乎总要冒一定的风险，因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。1988年，Barry Boehm正式发表了软件系统开发的螺旋模型。螺旋模型的基本思想是将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，以尽量降低风险，其特别适合于大型复杂的系统。第1章软件工程5喷泉模型喷泉模型(面向对象面向对象的生存期模型的生存期模型,OO模型

30、模型)迭代是软件开发过程中普遍存在的一种内在属性。经验表明，软件过程是各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代。喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，这种模型在面向对象范型中比在结构化范型中更常见。图1.8所示的喷泉模型是典型的面向对象生命周期模型。“喷泉”这个词体现了面向对象软件开发过程中迭代和无缝的特性。图1.8 喷泉模型喷泉模型的固有特征是：迭代，指多次重复、演进的过程；无间隙，指各阶段间无明显的界限，支持分析和设计结果的自然复用。第1章软件工程图1.8 喷泉模型第1章软件工程喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互

31、重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期，就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。为避免在使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程(例如，快速原型模型)作为总目标。但是，同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。第1章软件工程 6各种模型的比较各种模型的比较每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品的特性而变化，以减小所选模型的缺点，充分利用其优点。表1.3列出了几种常见模型的优缺点。第1章软件工程第1章软件工程软件过程是为了获得高质量软件产品所需要完成的一系列任务的框架，

32、它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量的软件产品。按照在软件生命周期全过程中应完成的任务的性质，在概念上可以把软件生命周期划分成问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试以及维护等八个阶段。实际上，从事软件开发工作时，软件规模、种类、开发环境及使用的技术方法等因素，都影响阶段的划分。因此，一个科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。第1章软件工程生命周期模型(即软件过程模型)规定了把生命周期划分成的阶段及各个阶段的执行顺序。本章介绍了五类典型的软件生命周期模型。瀑布模型历史悠久、广为人知，它的优势在于

33、它是规范的、文档驱动的方法；这种模型的问题是，最终交付的产品可能不是用户真正需要的。快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可运行的原型系统，让用户试用原型并收集用户反馈意见的办法，来获取用户的真实需求。但是，需要软件法开发技术和工具支持，需要用户参与开发过程，参与原型的运行和评价。第1章软件工程增量模型具有能在软件开发的早期使投资获得明显回报和易于维护的优点。但是，要求软件具有开放结构是使用这种模型时固有的困难。风险驱动的螺旋模型适用于大规模的内部开发项目。但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。当使用面向对象范型

34、开发软件时，软件生命周期必须是循环的，也就是说，软件过程必须支持反馈和迭代。喷泉模型是一种典型的适合于面向对象范型的过程模型。每个软件开发组织都应该选择适合于本组织及所要开发的软件特点的软件生命周期模型。这样的模型应该把各种生命周期模型的合适特性有机地结合起来，以便尽量减少它们的缺点，充分利用它们的优点。第1章软件工程1.4.1 系统分析与定义系统分析与定义为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提和关键。不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的软件只会给用户带来失望，给开发者带来烦恼。传统的软件工程方法学

35、采用结构化分析(Structured Analysis，SA)技术来完成需求分析工作。1.4 结构化的软件开发方法结构化的软件开发方法第1章软件工程1需求分析的任务需求分析的任务需求分析是发现、求精、建模、规格说明和复审的过程。为了发现用户的真正需求，首先应该从宏观角度调查、分析用户所面临的问题，也就是说，需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。分析员对用户提出的初步要求应该反复求精、多次细化，才能充分理解用户的需求，得出对目标系统的完整、准确和具体的要求。第1章软件工程为了更好地理解问题，人们常常采用建立模型的方法。所谓模型，就是为了理解事物而对事物做出的一种抽象，

36、是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则构成。结构化分析就是一种建立模型的活动，通常建立数据模型、功能模型和行为模型等三种模型。除了用分析模型表示软件需求之外，还要写出准确的软件需求规格说明。模型既是软件设计的基础，也是编写软件规格说明的基础。在分析软件需求和编写软件规格说明的过程中，软件开发者和软件用户都起着关键的、必不可少的作用。第1章软件工程用户与开发者之间需要通信、沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效的通信技术，集中精力缜密工作，而且对需求分析的结果(分析模型和

37、规格说明)必须严格审查。尽管目前存在许多不同的结构化分析方法，但是，所有这些分析方法都遵守下述准则：必须理解和表示问题的信息域，根据这条准则应该建立数据模型。必须定义软件应完成的功能，这条准则要求建立功能模型。第1章软件工程 必须表示作为外部事件结果的软件行为，这条准则要求建立行为模型。必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。分析过程应该从要素信息移向实现细节。第1章软件工程2需求分析的方法需求分析的方法软件需求分析是与用户通信的过程，总是从两方或多方之间的通信开始的。用户面临的问题需要用基于计算机的方案来解决；开发者应该对用户的需求作出反应，给用户提供帮助，这样就产生

38、了相互通信的需求。1)访谈 访谈(或称为会谈)是最早开始运用的获取用户需求的技术，也是迄今为止仍然广泛使用的主要的需求分析技术。第1章软件工程访谈有两种基本形式，分别是正式的和非正式的访谈。在正式的访谈中，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间的长短等。在非正式的访谈中，将提出一些可以自由回答的开放性问题，以鼓励被访问的人员表达自己的想法，例如，询问用户为什么对目前正在使用的系统感到不满意。当需要调查大量人员的意见时，向被调查的人员分发调查表是一个十分有效的做法。在对用户进行访谈的过程中，使用情景分析技术往往非常有效。所谓

39、情景分析，就是对用户运用目标系统解决某个具体问题的方法和结果进行分析。第1章软件工程2)简易的应用规格说明技术这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不同的方法并指定基本的需求。现在，简易的应用规格说明技术已经成为信息系统界使用的主流技术。尽管存在许多不同的简易应用规格说明方法，但是它们遵循的基本准则是相同的。在中立地点举行由开发者和用户双方出席的会议。制定准备会议和参加会议的规则。第1章软件工程 提出一个议事日程，这个日程应该足够正式，以便能够涵盖所有要点；同时，这个日程又应该足够非正式，以便鼓励自由思维。由一个“协调人”来主持会议，他既可以是用户，也可以是开

40、发者，还可以是从外面请来的人。使用一种“定义机制”(例如，工作表、图表等)。目标是标识问题、提出解决方案的要素，商讨不同的方案并制定初步的需求。第1章软件工程3)构建软件原型构建原型的要点是，应该实现用户看得见的功能(例如屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如修改文件)。快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。第1章软件工程快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出

41、原型的第二版，以更好地满足用户的需求。在实际开发软件产品时，“修改试用反馈”的过程可能要重复多遍，如果修改耗时过多，则势必延误软件开发时间。第1章软件工程3分析建模和软件需求规格说明分析建模和软件需求规格说明结构化分析实质上是一种创建模型的活动。通过需求分析而建立的模型必须达到下述三个基本目标：描述用户的需求；为软件设计工作奠定基础；定义一组需求，一旦开发出软件产品之后，就可以用这组需求作为标准来验收该产品。为了达到上述目标，在结构化分析过程中导出的分析模型的形式如图1.9所示。通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明，它是分析阶段的最终成果。第1章软件工程图1.9 分析模

42、型的结构第1章软件工程4实体实体关系图关系图 数据模型包含三种相互关联的信息：数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。数据对象：是对软件必须理解的复合信息的表示。所谓复合信息，是指具有一系列不同性质或属性的事物，因此，仅有单个值的事物(例如宽度)不是数据对象。属性：定义了数据对象的性质，应根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。第1章软件工程关系：数据对象彼此之间相互连接的方式称为关系，也称为联系。关系分为一对一联系(11)，一对多联系(1N)，多对多联系(MN)。其中多对多联系也具有属性。用实体关系图(Entity Relationship Dia

43、gram)建立的数据模型简称为E-R图。相应地，用E-R图描绘的数据模型也可以称为E-R模型。E-R图中包含了实体(即数据对象)、关系和属性等三种基本成分。通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用无向边把实体(或关系)与其属性连接起来。例如，图1.10是某学校教学管理的E-R图。第1章软件工程图1.10 某学校教学管理的E-R图第1章软件工程5数据流图数据流图 当数据在软件中移动时，它将被一系列“变换”所修改。数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。如图1.11所示，数据流图有四种

44、基本符号：正方形(或立方体)表示数据的源点或终点，是系统之外的人员或组织；圆形(或圆角矩形)代表变换数据的处理；两条平行横线(或矩形)代表数据存储；箭头表示数据流，即特定数据的流动方向。源点/终点与处理、处理与处理之间的数据流应当具有名称，与数据存储有关的数据流的名称可以省略，因为用数据存储的名称就可以清楚表示了。第1章软件工程图1.11 数据流图的基本符号第1章软件工程下面通过一个简单例子来具体说明怎样画数据流图。【例例1.1】假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件，应该列出下述数据：零件编号、零件名称、定货数

45、量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时，就应该再次订货。数据流图有四种成分：源点或终点、处理、数据存储和数据流。因此，可采用以下步骤画出订货系统的数据流图。第1章软件工程首先要从问题描述中提取数据流图的四种成分，接下来考虑数据的处理与加工，最后考虑数据存储和数据流。一旦把数据流图的四种成分都分离出来以后，就可以着手画数据流图了。任何系统的基本模型都是由若干个数据源点/终点以及一个处理组成的，这个处理就代表了系统对数据加工变换的基本功能。对于上述的订货系统可以画出如图1.12所示的顶层数

46、据流图来表示基本系统模型，在顶层和数据流图中突出表明了数据的源点、终点和系统的输入、输出。第1章软件工程图1.12 订货系统的基本系统模型顶层数据流图第1章软件工程下一步应该把基本系统模型细化，得到描绘系统的主要功能的0层数据流图。图1.13是系统的0层数据流图，系统中含有处理事务和产生报表两个子系统，所给出的处理和数据存储都加了编号，这样做的目的是便于引用和追踪。接下来应该对功能级数据流图中描绘的系统主要功能进一步细化，对0层数据流图中的每个子系统进一步分解，得到1层数据流图。图1.14是将事务处理子系统进一步分解的订货系统的1层数据流图。第1章软件工程图1.13 订货系统的功能级数据流图0

47、层数据流图第1章软件工程图1.14 将事务处理子系统进一步细化的数据流图1层数据流图第1章软件工程在对数据流图分层细化时，必须保持信息的连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性，因此，给这些成分起名字时应该仔细推敲。命名时应注意以下问题：为数据流(或数据存储)命名时，名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分；不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)；如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是对数据流图分解

48、不恰当而造成的，应该试试重新分解，看是否能克服这个困难。第1章软件工程通常先为数据流命名，然后为与之相关联的处理命名，这样命名比较容易，而且体现了人们习惯的“由表及里”的思考过程。名字应该反映整个处理的功能，而不是它的一部分功能；名字最好由一个具体的及物动词，加上一个具体的宾语组成；应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字；通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些；如果在为某个处理命名时遇到了困难，则很可能是发现了分解不当的迹象，应考虑重新分解。第1章软件工程6数据字典数据字典数据字典是为了描述在结构化分析过程

49、中定义的对象的内容，而使用的一种半形式化的工具。数据字典中的每个条目是对数据流图中所出现的每个成分的精确、严格的定义，从而使得用户和系统分析员双方对构成输入、输出、数据存储的数据项，以及加工处理逻辑有共同的理解。第1章软件工程虽然可以使用自然语言描述数据流和数据存储的条目，但是为了更加清晰简洁起见，建议采用下列符号：=等价于(或定义为)。+和(即连接两个分量)。例如：X=a+b，表示X由数据项a和b组成。|或(即从方括号内列出的若干个分量中选择一个)，通常用“|”号分开供选择的分量。例如：X=a|b，表示X由数据项a或b组成。第1章软件工程重复(即重复花括号内的分量)，常常使用上限和下限进一步

50、注释表示重复的花括号。一种注释方法是在花括号的右边用上角标和下角标分别表明重复的上限和下限；另一种注释方法是在括号左侧标明重复的下限，在括号的右侧标明重复的上限。例如：X=a，表示X由若干个数据项a组成。X=或X=，表示X中最少出现2次a，最多出现5次a。5和2分别为重复次数的上、下界。()可选(即圆括号里的数据项可有可无)。例如：X=(a)，表示数据项a可在X中出现，也可不出现。“”基本数据项。例如：X=“a”，表示X可取的数据项为字符a。.连接符。例如：X=1.9，表示X可取1到9中任意一个值。第1章软件工程(1)数据流条目的主要内容举例如下：数据流名称：订货报表别名：无简述：提供给采购员