正版新书]程序员教程(第5版)张淑平97873024911

章 计算机系统基础知识
1.1 计算机系统的基本组成
1.2 数据的表示及运算
1.2.1 计算机中数据的表示
1.2.2 校验码
1.. 逻辑代数及逻辑运算
1.2.4 机器数的运算
1.3 计算机的基本组成及工作原理
1.3.1 总线的基本概念
1.3.2 中央处理单元
1.3.3 存储系统
1.3.4 输入/输出技术
1.4 指令系统简介
1.5 多媒体系统简介
1.5.1 数字声音
1.5.2 图形与图像
1.5.3 动画和视频
第2章 操作系统基础知识
2.1 操作系统概述
2.2 进程管理
2.2.1 基本概念
2.2.2 进程控制
2.. 进程通信
2.2.4 进程调度
2.2.5 死锁
2.2.6 线程
. 存储管理
..1 基本概念
..2 存储管理方案
.. 分页存储管理
..4 分段存储管理
..5 虚拟存储管理
2.4 设备管理
2.4.1 设备管理概述
2.4.2 设备管理技术
2.4.3 磁盘调度
2.5 文件管理
2.5.1 基本概念
2.5.2 文件的结构和组织
2.5.3 文件目录
2.5.4 存取方法、存取控制
2.5.5 文件的使用
2.5.6 文件的共享和保护
2.5.7 系统的安全与可靠
2.6 作业管理
2.6.1 作业管理
2.6.2 作业调度
2.6.3 人机界面
第3章 程序设计语言基础知识
3.1 程序设计语言概述

第5章软件工程基础知识　　软件是计算机系统中的重要组成部分，它包括程序、数据及相关文档。软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。
　　软件工程涉及软件开发、维护、管理等多方面的原理、方法、工具与环境，限于篇幅，本章不能对软件工程做全面的介绍。根据程序员级大纲的要求，本章着重介绍软件开发过程中的基本方法和内容。
5.1软件工程概述　　早期的软件主要指程序，程序的开发工作主要依赖于开发人员的个人技能和程序设计技巧。当时的软件通常缺少与程序有关的文档，软件开发的实际成本和进度常常与预计的相去甚远，软件的质量得不到保。随着计算机应用的需求不断增长，软件的规模也越来越大，然而软件开发的生产率远远跟不上计算机应用的迅速增长。此外，由于缺少好的方法指导和工具辅，同时又缺少相关文档，使得大量已有的软件难以维护。上述这些问题严重地阻碍了软件的发展，20世纪60年代中期，人们把上述软件开发和维护过程中所遇到的各种问题称为“软件危机”。
　　1968年，在德国召开的NATO（NorthAtlanticTreatyOrganization，北大西洋公约组织）会议上，首次提出了“软件工程”这个概念，希望用工程化的原则和方法来克服软件危机。在此以后，人们开展了软件过程模型、开发方法、工具与环境的研究，提出了瀑布模型、演化模型、螺旋模型和喷泉模型等开发过程模型，出现了面向数据流方法、面向数据结构方法、面向对象方法等开发方法，以及一批CASE（ComputerAidedSoftwareEngineering，计算机辅软件工程）工具和环境。
5.1.1软件生存周期
　　同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡的许多阶段，一般称为软件生存周期。把整个软件生存周期划分为若干阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。目前划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方都会影响软件生存周期阶段的划分。在划分软件生存周期阶段时应该遵循的一条基本原则，就是使各阶段的任务彼此间尽可能相对独立，同一阶段各任务的质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发的组织管理。
　　1．问题定义　　问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”通过问题定义阶段的工作，系统分析员应该提出关于问题质、工程目标和规模的书面报告。问题定义阶段是软件生存周期中简短的阶段，一般只需要甚至更少的时间。
　　2．可行分析　　这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗？”可行分析阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题值得去解，以及有可行的解决办法。
　　3．需求分析　　需求分析阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、能、数据和界面等要求，从而确定系统的逻辑模型。
　　4．总体设计　　这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”　　首先，应该考虑几种可能的解决方案。系统分析员应该使用系统流程图或工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，一个较好的系统（方案），并且制定实现所的系统的详细计划。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。
　　5．详细设计　　总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的主要任务就是对每个模块完成的功能进行具体描述，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢?”。因此，详细设计阶段的任务不是编写程序，而是设计出程序的详细规格说明，该说明应该包含必要的细节，程序员可以根据它们写出实际的程序代码。通常采用HIPO（层次加输入/处理/输出图）或PDL语言（过程设计语言）描述详细设计的结果。
　　6．编码和单元测试　　编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单，并仔细测试编写出的每一个模块。
　　7．综合测试　　综合测试阶段的关键任务是通过各种类型的测试（及相应的测试）使软件达到预定的要求。基本的测试是集成测试和验收测试。所谓集成测试，是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试，是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参与下）对目标系统进行验收。
　　通过对软件测试结果的分析可以预测软件的可靠；反，根据对软件可靠的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。
　　8．维护　　维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有改正、适应、完善和预防四类维护活动。其中，改正维护是指诊断和改正在使用过程中发现的软件错误；适应维护是指修改软件以适应环境的变化；完善维护是指根据用户的要求改进或扩充软件使它更完善；预防维护是指修改软件为将来的维护活动预先做准备。
　　每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。
5.1.2软件生存周期模型　　软件生存周期模型是一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止（IEEE标准12207.0—1996）。把这个概念应用到开发过程，即软件过程模型，可以发现所有生存周期模型的内在基本特征：描述了开发的主要阶段；定义了每一个阶段要完成的主要过程和活动；规范了每一个阶段的输入和输出（提交物）；提供了一个框架，可以把必要的活动映到该框架中。
　　软件过程是生产一个满足需求并且达到工程目标的软件产品所需的步骤。《计算机科学技术百科全书》中指出，软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。软件过程有3层含义：一是个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等；二是整体含义，即指软件产品在所有上述含义下的软件过程的总体；三是工程含义，即指解决软件过程的工程，应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本。
　　常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型和喷泉模型等。
　　1．瀑布模型（WaterfallModel）　　瀑布模型是将软件生存周期各个活动规定为依线顺序连接的若干阶段的模型。它包括需求分析、设计、编码、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落，如图5-1所示。
　　瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
　　瀑布模型设，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生。瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
　　2．增量模型（IncrementalModel）　　增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它设可以将需求分段为一系列增量产品，每一增量可以分别地开发。该模型采用随着日程时间的进展而交错的线序列，每一个线序列产生软件的一个可发布的“增量”，如图5-2所示。当使用增量模型时，个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
　　增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点，此外，它还有以下优点：个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了个版本，因此可以减少用户需求的变更；运行增量，即在项目开始时，可以仅对一个或两个增量。
　　增量模型的不足之处：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发；管理发生的成本、进度和配置的复杂，可能会超出组织的能力。
图5-2增量模型　　3．演化模型（EvolutionaryModel）　　演化模型主要针对事先不能完整定义需求的软件开发，是在快开一个原型的基础上，根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，可得到令用户满意的软件产品。
　　演化模型的主要优点是，任何功能一经开发就能进入测试，以便验符合产品需求，可以帮引导出高质量的产品要求。其主要缺点是，如果不加控制地让用户接触开发中尚未稳定的功能，可能对开发人员及用户都会产生负面影响。
　　4．螺旋模型（SpiralModel）　　对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
　　螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如图5-3所示。在每个螺旋周期分为如下4个工作步骤。
　　（1）制定计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。
　　（2）风险分析。分析所选的方案，识别风险，消除风险。
　　（3）实施工程。实施软件开发，验阶段产品。
　　（4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。
　　螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
　　与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。
图5-3螺旋模型　　5．喷泉模型（FountainModel）　　喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限。喷泉模型使开发过程具有迭代和无间隙，如图5-4所示。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，需求分析活动结束后才开始设计活动，设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
　　喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高软件项目开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加。　　6．统一过程（UnifiedProcess）　　统一过程的特色是“用例和风险驱动，以架构为中心，迭代的增量开发过程”。迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。
　　统一过程定义了5个阶段及其制品。
　　1）起始阶段（InceptionPhase）　　起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档（VisionDocument）、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。本阶段的里程碑是生命周期目标。
　　2）精化阶段（ElaborationPhase）　　精华阶段在理解了初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、软件体系结构描述、可执行的软件体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。本阶段的里程碑是生命周期架构。
　　3）建阶段（ConstructionPhase）　　构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。初始运作功能。
　　4）移交阶段（TransitionPhase）　　移交阶段关注于软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。
　　5）生产阶段（ProductionPhase）　　生产阶段对持续使用的软件进行监控，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。
　　在每个迭代中，有5个核心工作流：捕获系统应该做什么的需求工作流，精化和结构化需求的分析工作流，用系统构架实现需求的设计工作流，构造软件的实现工作流，验实现如期望那样工作的测试工作流。
　　统一过程的典型代表是RUP（RationalUnifiedProcess），主要针对前4个技术阶段。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。
　　7．敏捷方法（AgileDevelopment）　　敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活，敏捷方法使用户能够在开发周期的后期增加或改变需求。
　　敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。
　　1）极限编程（XP）　　XP是一种轻量级（敏捷）、高效、低风险、柔、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
*四大价值观：沟通、简单、反馈和勇气。
*5个原则：快速反馈、简单设、逐步修改、提倡更改和优质工作。
*12个实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。
　　2）水晶法（Crystal）　　水晶法认为每一个不同的项目都需要一套不同的策略、约定和方。
　　3）并列争求法（Scrum）　　并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。
　　4）自适应软件开发（ASD）　　ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。
5.1.3软件过程评估　　自从软件工程概念提出以后，出现了许多开发、维护软件的模型、方法、工具和环境，他们对提高软件的开发、维护效率和质量起到了很大的作用。尽管如此，人们开发和维护软件的能力仍然跟不上软件所涉及的问题的复杂程度的增长，大多是软件组织面临的主要问题仍然是无法符合预算和进度要求的高可靠和可用的软件。人们开始意识到问题的实质是缺乏管理软件过程的能力。
　　1．软件能力成熟度模型（CMM）　　在美国支持下，1987年，卡内基·梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果——软件过程能力成熟度模型（CapabilityMaturityModelofSoftware,CMM），其研究目的是提供一种评价软件承接方能力的方法，同时它可用于帮软件组织改进其软件过程。
　　CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步前进。该能力成熟度模型使软件组织较容易地确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进为关键的几个问题，从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步地改善其全组织的软件过程，使全组织的软件过程能力持续增长。
　　CMM将软件过程改进分为如下5个成熟度级别，分别为：　　（1）初始级（Initial）。软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
　　（2）可重复级（Repeatable）。建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特。有必要的过程准则来重复以前在同类项目的成。
　　（3）已定义级（Defined）。管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
　　（4）已管理级（Managed）。制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
　　（5）优化级（Optimized）。加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。
　　CMM模型提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了循序渐进的基础。这5个成熟度等级定义了一个有序的尺度，用来测量一个组织的软件过程成熟度和评价其软件过程能力。成熟度等级是已得到确切定义的，也是在向成熟软件组织前进途中的平台。每一个成熟度等级为继续改进过程提供一个基础。每一等级包含一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标，当目标满足时，能使软件过程的一个重要成分稳定。每达到成熟度框架的一个等级，就建立起软件过程的一个相应成分，导致组织过程能力一定程度的增长。
　　基于CMM模型的产品包括一些诊断工具，可应用于软件过程评价和软件能力评估小组以确定一个机构的软件过程实力、弱点和风险。著名的是成熟度调查表。软件过程评价及软件能力评估的方法及培训也依赖于CMM模型。
　　2．能力成熟度模型集成（CMMI）　　CMM的成功导致了适用不同学科领域的模型的衍生，如系统工程的能力成熟度模型，适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科，因此有必要将各种过程改进的工作集成起来。1998年由美业界、和卡内基·梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。2000年发布了CMMI-SE/SW/PP，集成了适用于软件开发的SW-CMM（草案版本2（C））、适用于系统工程的EIA/IS731以及适用于集成化产品和过程开发的PCMM（0.98版）。2002年1月发布了CMMI-SE/SW/PP1.1版。
　　CMMI提供了两种表示方法：阶段式模型和连续式模型。
　　（1）阶段式模型　　阶段式模型的结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/PP1.1版中有5个成熟度等级。
　　初始的：过程不可预测且缺乏控制。
　　已管理的：过程为项目服务。
　　已定义的：过程为组织服务。
　　定量管理的：过程已度量和控制。
　　优化的：集中于过程改进。