软件工程导论

第1章软件工程导论业余软件工程师总在寻找奇迹用某种惊人的方法或工具来让软件开发变得轻而易举，但职业软件工程师都知道不存在这种灵丹妙药。——摘自《面向对象分析和设计》，GradyBooch软件工程这一术语产生于1968年，当时及时地在预算内开发出高质量软件的技术还是一片空白，软件工程一词因此应运而生。当时软件开发者无法制定具体目的，无法预测实现目的所需的资源，也无法实现客户的盼望。他们通常承诺的是给用户摘月亮，而制造的却是登月车，最后交付的却是一副方形车轮，这与目的相去甚远。软件工程的重点既在软件，也在工程。一个工程师应当可以在一定期间和预算内，通过使用和集成构件，来构造高质量软件产品。工程师通常面临的问题是问题定义不清和解决方案不全，不得不依靠实验方法来评估解决方案。在飞机设计和桥梁建设等应用领域工作的工程师们已成功地迎接了类似的挑战，而软件工程师们却没那么幸运和成功。在指定期间内构造和交付复杂软件系统的问题，一直以来都得到了人们积极的探讨和研究。一切的一切，涉及从客户（“我问你，我为什么不能花50美元得到月亮”）到软件中的“软”的成分（“要是我能加上最后那个特性……”），都被归咎于该学科太年轻。问题究竟是什么？复杂性和变化有用的软件系统通常是复杂的。为了有用，它们必须随着终端用户需求和目的环境的变化而变化。在本书中，我们描述了为了征服复杂且不断变化的软件系统方法，即面向对象技术。本章中，我们提供了采用面向对象技术的依据，定义了贯穿全书的基本概念。1.1导言：软件工程的失误看看下面的例子[Neumann,1995]：192023错误1992年，来自明尼苏达州怀俄明的玛丽收到一份幼儿园的入园告知，她当时是104岁。闰年错误1988年2月29日，一家超市因出售过期一天的肉而被罚款1 000美元。由于在肉的标签上打印保质期的计算机程序没有考虑到1988年是闰年。接口误用1990年4月10日，在伦敦地铁运营过程中，司机还没上车，地铁列车就驶离车站。当时司机按了启动键，正常情况下假如车门是开着的，系统就应当可以阻止列车起动。当时的问题是司机离开了列车去关一扇卡着的门，但当门终于关上时，列车还没有等到司机上车就开动了。安全问题迟延和超支在1995年，由于新丹佛尔国际机场自动行李系统的错误，导致旅客行李箱的损坏。机场则被迫推迟16个月再开放，且大部分采用手工行李系统，产生32亿美元超支。迟延和超支（2）2023年的Swanick空运控制系统，涉及英格兰和威尔士所有空运线路。在系统交付时，已延期6年且严重超支（实际花费6.23亿英傍，原计划花费3.5亿英镑），其中两次重要的系统升级是在运送操作员培训已经开始后才交付的。按期交付1984年，通过18个月的开发，一个耗资2亿美元的系统交付给了威斯康星州的一家健康保险公司。但是该系统无法正常工作，只好追加了6千万美元，又花了3年才解决了问题。不必要的复杂性麦克道尔道格拉斯的C-17货机由于控制系统的软件问题，而超支5亿美元。C-17具有19台机载计算机，80个微解决器以及6种不同的编程语言。上述各种失误的产生都与软件问题有关。有时，开发者没有考虑到偶发事件（如一个人的年龄超过100岁，影响保质期的闰年）。有时，开发者没有考虑到用户积极误用系统（按下按钮、使用网络软件的安全孔）。尚有些系统失误的情形是由于管理失误（迟延和超支交付、按期交付不对的的系统以及不必要的复杂度）导致的。软件系统的开发是一个复杂的发明过程。软件系统需要完毕多种功能；构建软件系统需要达成许多不同目的，这些目的通常还会互相冲突。软件系统包含许多构件，这些构件是定做的且自身就很复杂。同时，不同领域的人参与了这些构件的开发，这也导致了开发过程的复杂性。开发过程和软件生命周期通常是以年计数的。并且，任何一个人都很难完全理解复杂系统。有很多系统，即使处在开发阶段，也是很难被理解的，以致这些系统最终难以完毕而成为“空想件”（vaporware）。软件开发项目要不断变化。由于需求是复杂的，当发现错误、当开发者能更好地理解其应用之后，需求就需要不断被更新。假如一个项目被开发数年，也许出现的问题是人在下一节中，我们将提出一种高层次软件工程视点。我们从科学、工程学以及知识获取和形式化等方面描述软件工程。在第1.3节中，我们更具体地描述了本书所用的重要术语和概念。在第1.4节中，我们对软件工程的开发活动提出了总体见解。在第1.5节中，我们提出了对软件工程管理活动的总体见解。1.2什么是软件工程软件工程是一种建模活动。软件工程师通过建模来解决复杂性，以做到每次只专注于相关联的细节而忽略其他一切。在开发过程中，软件工程师构建许多不同的系统模型以及应用域模型。软件工程是一种解决问题的活动。模型用于寻找一种可接受的解决问题的方法。这种寻找方法受实验的驱动。软件工程师没有无限可用的资源，并且会受到预算和提交的最后期限的限制。由于缺少基本理论，他们通常得依靠实验方法来评价各种可选方案的优点。软件工程是一种知识获取的活动。在相应用域和解决方案域进行建模时，软件工程师收集数据，将这些数据转化为信息，并将这些信息形式化为知识。对知识的获取不是线性的，由于单个多余数据就能让整个模型变得无效。软件工程是一种受软件工程原理指导的活动。在获取有关系统或其应用域的知识并做出决策的过程中，软件工程师还需要捕获到做决策的环境，以及这些决策背后的原理。表达为一组问题模型的软件工程原理信息，可使软件工程师可以在重审一个决策时，理解某种建议改动的含义。在本节中，我们更具体地从建模、问题求解、知识获取和基本原理等角度描述了软件工程。在这些活动中，软件工程师还受到人力、时间和预算的制约。此外，我们假设变化随时会发生。1.2.1建模科学的目的是描述和理解复杂系统，比如一个原子系、一个人类社会或一个太阳系。通常，人们将自然科学和社会科学相区分，将这两者作为两种重要体系对待。自然科学的目的是理解自然及其子系统。自然科学涉及诸如生物学、化学、物理学和古生物学等学科。社会科学的目的是理解人类。社会科学涉及心理学和社会学。尚有一种系统，我们称之为人工系统。人工系统涉及诸如航天飞机、航班预订系统、股票交易系统。HerbertSimon杜撰了一个词汇人工科学（scienceofartificial）来描述解决人工系统的科学[Simon，1970]。自然科学和社会科学已经出现了许多世纪了，而人工科学才出现不久。人工科学的典型实例，如计算机科学，就是一种理解计算机系统的科学，该科学在20世纪才诞生。很多已经成功运用于自然科学和人文科学的方法，也可以运用于人工科学中。通过了解其他科学，我们就可以了解关于人工科学方面的更多知识。科学的基本方法之一是建模。一个模型是对一个系统的抽象表达。这种表达使我们可以回答关于系统的问题。在解决太大、太小、太复杂或第一手亲历代价太高的系统时，模型是非常有用的。模型也使我们可以想象和理解那些已经不复存在的系统，或那些被认为存在但未经证实的系统。化石生物学家们出土了一些恐龙的骨头和牙齿，没人见过这些恐龙。运用一些骨头残片，他们依照解剖学的规律，重新构造了恐龙模型。他们发现的骨头越多，就越清楚这些骨头是如何连接起来的，也就越相信他们构建的模型与原始恐龙相符。假如他们发现了足够数量的骨头、牙齿和爪子，他们几乎就可以拟定其模型准确地反映了事实，并且，他们可以推测找不到的部分。例如，腿通常是成对的。假如找到了左腿，右腿没有被找到，那么骨头生物学家也很清楚没找到的腿应当是什么样子以及如何连接到模型身上。这就是一个不复存在的系统建模的例子。今天的高能物理学家们也处在一个与已经找到大部分恐龙骨头的化石生物学家相类似的位置。物理学家们也正在构建一个物质与能量以及它们如何在最基本的亚原子层结合的模型。在数年使用粒子加速器进行实验之后，高能物理学家们已有了足够的自信：他们构建的模型能反映现实，并且那些没有被找到的部分可以与所谓的标准模型相吻合。这是对人们假设存在的一个系统建模的一个实例。两类系统建模者，化石生物学家们和高能物理学家们，他们研究的是两种实体：现实生活系统，即通过一系列现象观测到的系统；应用域模型，即表达为一组互相依存的概念。这里的现实世界系统是一只恐龙或亚原子微粒。应用域模型是对现实世界系统中那些与在研问题相关的方面进行的描述。软件工程师与化石生物学家和高能物理学家面临着类似的挑战。一方面，软件工程师需要理解一个系统的运营环境。对于一个列车交通控制系统，软件工程师需要了解列车的信号程序。对于一个股票交易系统，软件工程师需要了解交易规则。软件工程师不需要成为一个完全合格的列车调度员或股票经纪人；他们只需要了解与系统有关的应用域中的概念。换句话说，他们需要构建一个应用域模型。另一方面，软件工程师需要理解他们可以构建的系统，并能评估不同的解决方案和其他可替换的方案。许多系统都过于复杂，任何个人都无法所有理解，并且许多系统的构建是十分昂贵的。要解决这些难题，软件工程师要描述他们所研究的一些可选系统的某些重要方面。换句话说，他们需要构建一个解决方案域模型。面向对象方法将应用域与解决方案域建模活动合二为一。一方面，将应用域建模为一组对象和关系，接着这一模型被系统用来表达它所解决的现实世界中的概念。一个列车交通控制系统涉及列车对象，表达该系统监控的列车。一个股票交易系统涉及代表股票买卖的交易对象。另一方面，解决方案域的概念也被建模为对象。用来描绘一列列车或者一次经济交易的语句行就是对象，这些对象是解决方案域的一部分。面向对象方法的思想是：解决方案域模型就是应用域模型的一种转化。开发软件就转化为找出一个解决最终用户问题的系统并将之描述为模型集合。我们将在第2章中更具体地描述建模以及一些对象的概念。1.2.2问题解决工程是一种解决问题的活动。工程师通常在资源有限和知识不完备的情况下，通过尝试和失败、通过实验评估各种可供选择的方法，寻求解决问题的合适方法，用最简朴的形式表述问题与解决方案，工程方法涉及以下5步：1．明确问题；2．分析问题；3．寻找解决方案；4．选定合适的解决方案；5．具体说明解决方案。软件工程是一种工程活动，不是算法活动。软件工程需要实验、标准设计方案的复用、对系统的增量评估以便找到一个客户能接受的方案。面向对象的软件开发通常涉及5种开发活动：需求获取、分析、系统设计、对象设计和实现。在需求获取和分析阶段，软件工程师与客户把问题明确化并构建问题域模型。需求获取和分析相应于工程方法的第1步和第2步。在系统设计过程中，软件工程师分析问题，把它提成小块，并选择一些总体策略来设计系统。在对象设计过程中，开发者为每一小块选择一些具体的解决方案，并且最终选择一种最合适的方案。系统设计和对象设计用于产生解决方案域模型。系统设计和对象设计相应于工程方法的第3步和第4步。在实现阶段，软件工程师通过把解决方案域模型转换为可执行表达来实现系统，实现相应于工程方法的第5步。软件工程不同于其他科学的是，在问题解决过程中，应用域和解决方案域还在发生变化。软件开发还涉及旨在评价各种模型预算的活动。在分析审查时，应用域模型将与客户实际情况相对比，客户实际情况也也许由于建模而变化。在设计审查时，解决方案域模型要参照项目目的进行评估。在测试过程中，系统的验证要与解决方案域模型进行对比，解决方案域模型也许由于新技术的使用而进行了修改。在项目管理中，经理们将其开发进程模型（即项目进度和预算）与实际情况（即提交的工作产品和使用的资源）相对比。1.2.3知识获取软件工程师和经理们常犯的错误是，认为开发一个系统所需的知识获取是线性的。不仅软件经理们犯此类错误，其他领域的人也也许犯此类错误。在17世纪，出版了一本书，该书试图在6小时内将所有德国诗歌用像漏斗同样的工具灌入学生头脑。使用漏斗学习的想法是基于我们的头脑如同一个桶的假设，这个桶最开始是空的，可以用线性的方法装满。学习材料通过我们的知觉进来，积聚起来并被我们消化。Popper把这种线性的知识获取模式称为“大脑桶式理论”。在这一理论的诸多错误中（见[Popper,1992]描述），有一种错误就是认为知识是由可装在桶里的东西构成的：即，桶越满，我们的知识越多。事实上，知识获取是一个非线性的过程。对理解一个系统而言，一条新信息的获得就也许使我们为了理解系统已获取的所有知识变得无效。即使我们已经在文档和编码中证明了这种理解（“这一系统已经完毕了90%的代码，我们下周就竣工了”），我们必须做好从零开始的心理准备。这一点对于我们定义的用于开发软件系统的活动集合及其交互有重要含义。大脑桶式理论相称于软件开发的线性瀑布模型，其中工程方法的每一步都是被有序地完毕的。有一些软件过程，通过避免瀑布模型所固有的线性依存性来解决这一问题。基于风险的开发，将试图通过找出高风险构件来预测一个项目后期的意外。基于问题的开发，将试图完全摆脱线性特性。任何一种开发活动——分析、系统设计、对象设计、实现、测试或交付——都也许影响其他活动。在基于问题的开发中，所有这些活动都是被并行执行的。非线性开发模型的困难则是难于管理。1.2.4基本原理在描述知识获取或者知识的进化时，我们准备的知识还局限性以描写一个现存系统。一个数学家是如何得到一个证明的？数学课本满是证明，但是很少提供证明导出这一证明过程的线索。由于数学家认为这一背景知识不重要。一旦那些公式和推理规则被给出，其证明就是长期有效的。对软件工程师来说，情况是不同的。开发者对系统的结识是不断变化的。尽管一旦开发者对问题有了足够的理解，应用域模型最终会拟定下来，但解决方案域模型将处在不断变化中。在测试阶段发现的设计和实现错误，以及在用户评估阶段发现的可用性问题，都会引起解决方案域模型的变化。新技术也也许引起变化。例如，长效电池和宽带无线通信的出现也许引发移动终端概念的修改。新技术引起的变化通常会产生新的功能性或非功能性的需求。软件工程师通常的任务是修改一个当前可操作的软件系统来吸纳这种新技术。要修改一个系统，理解其当前构件和行为是不够的，还必须捕获和理解做出每个设计决定的背景。这种额外的知识被称做系统的基本原理。捕获并进一步到一个系统的基本原理不是小事情。一方面，每做出一个决定，其他许多备选方案也许已经通过考虑、评估、探讨了。因此，基本原理比解决方案模型反映了更多的信息。另一方面，基本原理信息通常是隐含的。开发者会基于自己的经验和直觉做出许多决定，而不会对不同方案做出明确的评价。当被规定对某个决定做出解释时，开发者也许要花大量的时间重新研究其基本原理。然而，为了解决经常变化的系统，软件工程师必须面对捕获基本原理并进一步探索基本原理的挑战。1.3软件工程概念图1-1用一个UML类图描述的软件

工程概念[OMG，2023]迄今为止，我们已经从建模、问题求解、知识获取和基本原理等方面提出了一种软件工程的高层次视点。在本节中，我们将介绍全书使用的重要术语和概念。1我们将尽量依据IEEE的软件工程[IEEE，1997]标准进行定义。一个项目（Project）由许多活动（Activity）组成，其目的在于开发一个软件系统。每种活动则由许多任务（Task）构成。一个任务使用资源（Resource）并产生工作产品（WorkProduct）。一个工作产品可以是一个系统、一个模型或者一个文档。资源涉及参与者、时间和设备。这些概念可以用图1-1表达。每一个矩形表达一个概念。矩形间的线段表达概念间的不同关系。例如，菱形表达聚集：一个项目涉及许多活动，一个活动又涉及许多任务。三角形表达一种归纳关系：参与者（Participan图1-1用一个UML类图描述的软件

工程概念[OMG，2023]1我们将尽量依据IEEE的软件工程[IEEE，1997]标准进行定义。1.3.1参与者和角色开发一个软件系统需要很多来自不同背景、具有不同爱好的人的协作。例如，开发客户预定和付费系统。现在开发者要构建该系统。项目经理做项目计划和项目预算，并协调开发者和客户。终端用户得到系统的支持。我们把所有参与到这个项目中的人员称为参与者。把项目或系统的一组职责称为角色。一个角色与一组任务联系在一起，且被派给一个参与者。一个参与者能充当多个角色。现在请看一个售票系统（TicketDistributor）：售票系统（TicketDistributor）是一台发售火车票的机器。旅客可以选择单程车票和多程车票，也可以选择一天或一周的时间卡。售票系统（TicketDistributor）根据如下信息计算出旅客所要的车票价格：旅行者的地点、旅行者是成人还是儿童。售票系统（TicketDistributor）必须可以解决一些意外情况，例如该系统可以解决旅客没有完毕交易的情况，可以解决旅客试图使用巨额支票支付的情况，以及可以解决资源用尽的情况：如售完了车票、没有零钱或停电等。把这个售票系统（TicketDistributor）的开发当成一个软件工程项目实行时，表1-1给出了该实例中角色的一些例子。表1-1售票系统（TicketDistributor）项目软件工程的角色实例角色职责例子客户客户负责提供对系统的高层需求并负责定义项目的范畴（交付日期、预算、质量标准）把售票系统（TicketDistributor）承包出去的列车公司用户用户负责提供有关当前用户任务的域知识；注意客户和用户通常是不同的人旅客经理经理负责工作组织，涉及雇佣员工、给他们分派任务、管理工作进程、提供人员培训、总体管理客户提供的资源，直至成功交付Alice（上司）人力专家人力专家负责系统的可用性Zoe（人机交互专家）开发者开发者负责系统的构造，涉及：规模说明、设计、实现和测试；在大型项目中，开发者的角色还要被细分John（分析员）、Marc（程序员）、Zoe（测试员）a技术撰写者技术撰写者负责交付客户的文献，技术撰写者要采访开发者、经理和用户，以理解系统Johna．开发售票系统（TicketDistributor）是一个小项目，Zoe承担了人力专家和测试员两个角色，John承担了分析员和技术撰写者两个角色。1.3.2系统和模型我们用系统一词来指内部关联部分的集合。建模是一种通过忽略不相关的细节来解决复杂性的方法。我们用建模一词来指系统的任何抽象。一个地铁售票系统就是一个系统。售票系统的蓝图、电线布线的示意图、软件的对象模型都是售票系统（TicketDistributor）的模型。注意，一个开发项目自身就是一个可建模的系统。其项目规划、预算以及预计的交付期都是开发项目的模型。1.3.3工作产品一个是一件在开发中生产的人工产品，如给其他开发者或客户开发的一个文档或者一个软件。我们把供项目内部使用的工作产品称为内部工作产品，把必须交付给客户的工作产品称为交付的工作产品。交付的工作产品通常在项目开始之前就已定义，通过与客户签订具有约束的协议，并对开发者加以限定。表1-2描述了一售票系统例子中的一些工作产品实例。表1-2售票系统项目中一些工作产品的实例工作产品类型描述规格说明交付产品规格说明从用户的角度描述系统，它是项目和客户间的一种契约性文档，售票系统规格说明具体描述了在旅客眼中该系统应当是什么样子操作手册交付产品操作手册是供列车公司负责安装和配置售票系统的工作人员使用的；这种手册描述了诸如如何变化票价，如何将网络结构提成区域等问题状态报告内部工作产品状态报告描述一定期间内已经完毕，以及仍在进展中的任务；状态报告是为经理Alice准备的，列车公司通常是看不到的测试手册内部工作产品测试者Zoe负责制作测试计划和测试结果，这些文档跟踪售票系统原型中已知的缺陷及其修改状态，这些文档通常不会给客户1.3.4活动、任务和资源活动是为完毕某一特定目的的任务集合。例如，需求获取就是一种活动，其目的是与客户一起定义系统将做什么；交付是一种活动，其目的是在一个操作场合安装系统；管理是一种活动，其目的是管理和控制项目，以使其达成目的（即交付期限、质量、预算）。某些活动可由其他一些活动组成。交付活动涉及软件安装活动和操作员培训活动。活动有时也被称为阶段。任务代表一种可管理的极小单位的工作：一个经理把它布置给一个开发者，开发者把它实现，经理管理进度以及任务的完毕。任务花费资源，产生工作产品并依赖其他任务生产的工作产品。资源是用来实现工作的资本。资源涉及时间、设备和劳动。在规划一个项目时，经理把工作提成任务并把这些任务赋给资源。表1-3描述了软件工程中活动、任务和资源的实例。表1-3售票系统项目的活动、任务和资源的实例实例类型描述需求获取活动需求获取活动涉及从客户和用户那里获得和验证需求和应用域知识；需求获取活动的结果是规格说明工作产品（如表1-2所示）为售票系统开发“没有零钱”的测试用例任务布置给测试员Zoe的这一任务重要是验证售票系统在用完零钱以及找不开用户钱的情况下的行为；这一活动涉及规定测试环境、要键入的输入顺序，以及预期的结果检查“获取在线帮助”的使用实例的可用性任务这一布置给人力专家John的任务重点是找出获取系统在线帮助的可用性问题价目表数据库资源价目表数据库涉及有一个列车网络计划的价目表