1、1 1第13章 软 件 演 化第13章 软 件 演 化13.1 软件演化的动态特性13.2 软件维护13.3 软件再工程本章小结习题2 2第13章 软 件 演 化13.1 软件演化的动态特性13.1.1 软件的本质特性 Lehman和Belady对软件演化的动态特性进行了系统的研究，提出了著名的关于系统变更的定律，被称为Lehman定律，该定律总结了软件在变更过程中的演化特性。3 3第13章 软 件 演 化Lehman定律的主要内容包括：(1)软件维护是一个必然的过程。现实环境是在不断变化的，新的需求会不断地涌现，因此运行在相应环境中的软件也应随之发生变化，从而继续发挥其作用。(2)软件的不断
2、修改会导致软件的退化。因此为了防止这种退化，必须改善软件的结构和质量。4 4第13章 软 件 演 化(3)软件系统的演化特性是在早期的开发阶段建立起来的。软件规模限制着较大的变更发生，较大的变更会引起更多新的缺陷。在大型软件开发组织中，较大的软件变更需要组织的决策和预算的变动，而这种决策过程也制约着新版本的时间周期。(4)软件开发的效率与投入的资源无关。在大型软件开发项目中，团队成员数量的增加使项目的有效交流变得十分困难，过多的沟通时间使得开发人员没有足够的时间完成自己的开发任务，也会导致开发效率的相对低下。5 5第13章 软 件 演 化(5)在软件系统中添加新的功能不可避免地会产生新的缺陷，
3、因此若软件的功能增量较大意味着需要发布一个新版本，若新增功能较少，则其主要任务是修补这些新产生的软件缺陷。Lehman的结论揭示了软件演化的普遍特性，现实环境决定了软件系统不可避免地发生变更，软件的持续变更又会引入新的缺陷，甚至会破坏原有的系统结构。对于软件变更引起的各种问题，人们通常采用不同的策略进行处理，即进行软件维护和软件再工程。6 6第13章 软 件 演 化13.1.2 遗留系统问题许多大型系统往往具有较长的生命周期，使用时间多为10年以上。由于某些软件在业务中的重要性和稳定性，一些机构甚至仍然依赖于已经有20多年历史的软件系统，因此，这些老系统出现任何问题都会对机构的业务带来巨大影响
4、。人们把这些老系统称为遗留系统。7 7第13章 软 件 演 化经历长时间运行的遗留系统往往已不是最初交付的系统，这期间系统内、外部环境的变化，如市场、法规、管理上的变化以及软、硬件技术的发展等，都使软件系统面对新的需求，需要随着业务的变化而改变。因此，遗留系统在其生命周期中是不断变更着的，但如果要抛弃一个遗留软件系统，用一个全新开发的软件系统去替换它，则存在巨大风险，其原因在于：8 8第13章 软 件 演 化首先，遗留系统很少具有完整的文档，往往最初的文档已经不存在了，即使存在，也很难包含所做变更的所有细节，因此，很难有一个简单的方法可以产生与遗留系统功能相同的新系统。其次，业务过程和遗留系统
5、的操作方式紧密地“交织”在一起。这些业务过程已经根据软件服务的特点做了调整，为的是充分发挥软件服务的优势，弥补其不足。如果系统被替换，这些过程也必须改变。这样一来，替换的成本以及对业务的影响就难以估量。9 9第13章 软 件 演 化另外，重要的业务规则隐藏在软件内部，业务规则是对某些业务功能施加的约束，新的系统可能会打破这些规则，从而会给业务带来不可预知的结果。例如，一家保险公司可能将保单申请的风险评估规则嵌入到软件中，如果不保留这些规则，公司就可能接受高风险保单，由此带来日后昂贵的赔付。同时，开发新软件本身是有风险的，所以新系统会遇到难以预料的问题。它可能无法按时交付，对软件支付的价格也可能
6、要超出预期的估计。1010第13章 软 件 演 化在这种情况下，继续使用遗留系统则可以避免以上所述风险，但是对现有软件进行变更也会带来较大的代价，越老的系统越是如此。其主要的原因在于：系统的不同部分是由不同的团队实现的，整个系统中的程序设计风格是不一致的；系统的部分或全部可能是用一种已被淘汰的编程语言写的，目前已难以找到能使用这种语言的程序员；系统文档通常是不充分的和过时的。1111第13章 软 件 演 化有些时候，系统源代码是唯一的系统文档，而有些时候系统源代码已经不复存在，只剩下系统的可执行版本；经过许多年的维护，系统结构可能已经被破坏，理解系统设计的难度逐渐加大。加进来的新程序可能以一种
7、特别的接口方式与系统的其他部分对接；系统可能对空间或运行速度进行了优化，但可读性不好，这对那些掌握现代软件工程技术的人员来说理解起来是相当困难的。源程序中可能使用了许多小的程序设计窍门，对新人来说同样是极难弄懂的。系统所处理的数据可能保留在一些结构不相容的文件中，这些文件中的数据可能存在重复现象，数据也已经过时、不精确，也不完整。1212第13章 软 件 演 化因此，如果继续使用遗留系统，根据需要做系统变更，成本不可避免地要增加。如果用新系统替换遗留系统，费用和风险也会很高，而且新系统不一定能像遗留系统那样对系统提供有力的支持。所以需要有软件工程技术来延长遗留系统的生命周期，降低系统的维护成本
8、，即进行软件维护和软件再工程。1313第13章 软 件 演 化13.2 软 件 维 护13.2.1 软件维护内容 1软件维护的类型软件维护活动可以分为三种典型的类别：改正性维护、适应性维护、完善性维护。另外不排除其他类型的一些维护，如预防性维护。1414第13章 软 件 演 化在软件交付使用后，由于开发时测试的不彻底、不完全，必然会有一部分隐藏的错误被带到运行阶段来，这些隐藏下来的错误在某些特定的使用环境下就会暴露。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当对软件进行诊断和修正错误，称之为改正性维护。例如，改正性维护可以是改正原来程序中未使开关复原的错误；解决开发时
9、未能测试各种可能情况带来的问题等。1515第13章 软 件 演 化适应性维护是指随着计算机的飞速发展，外部环境(新的硬、软件配置)或数据环境(数据库、数据格式、数据输入输出方式、数据存储介质)可能发生变化，为了使软件适应这种变化，而去修改软件的过程。例如，适应性维护可以是为现有的某个应用问题实现一个数据库，对某个指定的事务编码进行修改，增加字符个数；调整两个程序，使它们可以使用相同的记录结构；修改程序，使其适用于另外一种终端。1616第13章 软 件 演 化完善性维护是指在软件的使用过程中，根据用户对软件提出的新的功能与性能要求，来修改、再开发软件，以扩充软件功能、增强软件性能、改进加工效率、
10、提高软件的可维护性。例如，完善性维护可能是修改一个计算工资的程序，使其增加新的扣除项目；提高系统响应速度，以达到特定的要求；改进用户与程序的对话方式；改进图形输出，增加联机帮助功能；为软件的运行增加监控设施等。1717第13章 软 件 演 化在维护阶段的头两年，改正性维护的工作量较大。随着错误发现率急剧降低，并趋于稳定，就进入了正常使用期。然而，由于变化的需求，适应性维护和完善性维护的工作量逐步增加，在这种维护过程中又会引入新的错误，从而加重了维护的工作量。实践表明，在几种维护活动中，完善性维护所占的比重最大，即大部分维护工作是改变和加强软件，而不是纠错。所以，维护是有计划、有预谋的一种再开发
11、活动。统计说明，来自用户要求扩充、加强软件功能和性能的维护活动约占整个维护工作的50%。1818第13章 软 件 演 化预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法用于昨天的系统以满足明天的需要。”如图13.1所示，在整个维护阶段的全部工作中，预防性维护只占很小的比例，而完善性维护占了近1/2的工作量。从图13.2中可知，软件维护花费的工作占整个生存期工作量的70%以上，这是由于在软件运行过程中要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求。这些修改需要花费很多精力和时间，而且有时修改不正确，还会引
12、入新的错误。同时，软件维护技术不像开发技术那样成熟、规范化，自然消耗工作量就较多。1919第13章 软 件 演 化图13.1 几类维护占总维护的比例 2020第13章 软 件 演 化图13.2 维护在软件生存期所占的比例 2121第13章 软 件 演 化2软件维护成本在系统的维护过程中，需要花费较大的工作量，不可避免地涉及到软件的维护成本问题。随着软件规模和复杂性的不断增长，软件维护的成本呈现上升的趋势。除此之外，软件维护还有无形的代价，由于维护工作占据着软件开发的可用资源，因而有可能使新的软件开发因投入的资源不足而受到影响，甚至错失市场良机。况且，由于维护时对软件的修改，在软件中引入了潜在的
13、故障，从而降低了软件的质量。2222第13章 软 件 演 化系统的大小、程序设计语言、系统的生命周期长短、软件所采用的开发技术等是维护工作量的决定因素。通常，系统越大、越复杂，维护人员阅读和理解该软件就越困难，因此，需要维护的工作量和成本就越大。使用功能强的程序设计语言，可以比较好地控制程序的规模，所生成的指令数也比较少；反之，实现相同的功能所需的语句就越多，相应程序就越大。早期，很多软件使用的程序设计语言较落后，所编写的程序逻辑性混乱，且程序的内聚和封装特性较差，导致程序的可读性、可维护性较差。2323第13章 软 件 演 化早期的老系统(遗留系统)除了设计结构上存在的缺陷，通常还会面临没有
14、文档，或文档太少的问题。另一方面，随着软件的不断修改，系统结构严重退化，长期的维护过程使得文档与程序不一致，程序也变得越来越难理解。所以，老系统和生命周期较长的系统需要更多的维护成本。近年来，数据库技术越来越成熟，在数据管理的应用领域中起着非常重要的作用。使用数据库可以简单有效地存储和管理程序中的数据，数据库工具可以很方便地修改和扩充报表等，因此，数据库技术的应用可以减少维护工作量。2424第13章 软 件 演 化在软件开发中，如果使用能使软件结构比较稳定的分析与设计方法以及程序设计技术，如复用技术、面向对象技术等，将大大减少软件的维护成本。另外，软件在程序中是否使用了数学模型、任务的难度、I
15、F嵌套的深度等因素都会对系统维护成本有影响。用于维护的工作量可以分成生产性活动和非生产性活动。例如，分析评价、修改设计和实现的源代码等是生产性活动；理解程序的功能、解释与判断数据结构、接口特点、性能的限度等是非生产性活动。2525第13章 软 件 演 化 维护工作量可以用一个模型表达：M=P+K exp(c-d)其中，M是维护的工作量；P是生产性工作量；K是经验常数；c是因为缺乏好的方法和文档而导致软件的复杂度；d是维护人员对软件熟悉的程度。该模型说明，如果没有一个好的软件开发途径，原来的开发人员不能参加维护工作，则维护工作量(成本)将按指数级增加。2626第13章 软 件 演 化3降低维护成
16、本的策略根据影响软件维护工作量的各种因素，一些策略被用于软件开发过程，以控制维护成本。在软件开发过程中，通过采用新技术，可大大提高可靠性，并减少进行改正性维护的需要。这些技术包括数据库管理系统、软件开发环境、程序自动生成系统和较高级(第四代)语言，应用这四种技术可产生更加可靠的代码。2727第13章 软 件 演 化此外，利用应用软件包可开发出比完全由用户自己开发的系统可靠性更高的软件；采用面向对象和结构化技术可以使软件有良好的可维护性；将自检能力引入程序，通过非正常状态的检查，提供审查跟踪，可降低发现和改正错误的代价；周期性维护审查易于在形成维护问题之前就可确定质量缺陷。2828第13章 软
17、件 演 化软件的适应性维护不可避免，但可以控制。在开发过程中，若配置管理时，把硬件、操作系统和其他相关环境因素的可能变化考虑在内，可以减少某些适应性维护的工作量；把硬件、操作系统，以及其他外围设备有关的程序归到特定的程序模块中，可以把因环境变化而必须修改的程序局限在某些程序模块之中；使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。开发过程可建立软件系统的原型，在实际系统开发之前把它提供给用户，用户通过研究原型进一步完善它们的功能要求，就可以减少以后完善性维护的需要。2929第13章 软 件 演 化13.2.2 软件维护过程 软件维护过程又称为软件维护活动。由于在软
18、件的运行过程中，需要不断地进行修改和完善，使得维护工作量逐年上升。软件维护过程与软件类型、软件开发过程以及人员因素有着密切的关系。软件维护过程由一系列变更请求触发。变更请求可能来自系统用户、管理层或者客户。一旦变更请求获得批准，就要对系统规划一个新版本，然后实现这个变更。软件维护过程的参考模型如图13.3所示。3030第13章 软 件 演 化图13.3 软件维护过程模型3131第13章 软 件 演 化1软件维护组织通常并不需要建立一个正式的维护机构，在一个维护过程中，每一位参加维护的人员都要明确自己的责任，为了减少维护过程的混乱，建立一种非正式的组织还是有必要的。软件维护组织如图13.4所示3
19、232第13章 软 件 演 化图13.4 软件维护组织3333第13章 软 件 演 化维护申请提交给一个维护管理员，维护管理员将申请交给某个系统监督员去评价。系统监督员是技术人员，他必须熟悉产品程序的某一部分。一旦做出评价，由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。维护管理员、系统监督员、修改负责人等，均代表维护工作的某个职责范围。修改负责人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小组。系统监督员可以有其他职责，但应具体分管某一个软件包。3434第13章 软 件 演 化2软件维护
20、申请报告应该用标准的格式提出软件维护的申请。维护申请报告是由软件组织外部提交的文档，它是软件维护工作的基础。维护组织接到的申请报告由维护管理员和系统监督员来研究处理。软件维护申请报告应说明产生错误的情况，如输入的数据、错误的清单等。如果申请的是适应性和完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。维护申请报告由维护管理员和系统监督员来研究处理。3535第13章 软 件 演 化维护申请报告是由软件组织外部提交的文档，它是计划维护工作的基础。软件组织内部应相应地做出软件修改报告(SCR)，指明以下问题。(1)所需要修改的性质；(2)申请修改的优先级；(3)为满足某一项维护申请所需要的
21、工作量；(4)预计修改后的状况。3636第13章 软 件 演 化3软件维护流程软件维护流程如图13.5所示，维护流程的第一步是先确认维护要求，弄清错误概况及对业务影响的大小，以及用户希望做什么样的修改，并把这些情况存入故障数据库，然后由维护组织管理员确认维护类型。3737第13章 软 件 演 化图13.5 维护的工作流程3838第13章 软 件 演 化对于改正性维护申请，从评价错误的严重性开始。如果存在严重的错误，则必须安排人员在系统监督员的指导下，进行问题分析、寻找问题发生的原因、进行“救火”性的紧急维护；对于不严重的错误，可根据任务，视轻重缓急进行排队，统一安排时间。对于适应性维护和完善性
22、维护申请，需要先确定每项申请的优先次序。若某项申请的优先级非常高，就可以立即开始维护工作。否则，维护申请和其他的开发工作一样，进行排队，统一安排时间。并不是所有的完善性维护申请都必须承担，因为它相当于做二次开发，工作量很大，所以要根据业务需要，可利用资源的情况，以及其他的考虑，决定是否承担。3939第13章 软 件 演 化4软件维护记录为了估计软件维护的有效程度，应该做好维护记录。记录的内容可考虑以下项目：程序标识(名称)；源程序行数；机器指令条数；所用的程序设计语言：程序安装的日期；程序安装后运行的次数；程序安装后失败的次数；4040第13章 软 件 演 化 程序改变的层次及名称；修改程序所
23、增加的源程序行数；修改程序所减少的源程序行数；每次修改所付出的“人时”数；程序修改的日期；软件维护人员的姓名；维护申请报告的标识(名称)；维护类型；维护的开始时间和结束时间；累计用于维护的“人时”数；完成维护任务的纯收益。4141第13章 软 件 演 化5软件维护评价如果已具有软件维护记录，则可以对维护工作进行评价。可供参考的度量值是：程序每次运行的平均失效次数；各类维护活动所花费的总“人时”数；每个程序、每种语言、每种维护类型所做的程序变动平均数；因为维护而增加或删除一个源程序语句，平均花费的“人时”数；维护每一种语言的程序所花费的“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比
24、。4242第13章 软 件 演 化13.3 软件再工程13.3.1 再工程活动从技术角度来看，软件再工程似乎是软件演化问题的一个次优级解决方案。比如将集中式的软件体系结构转换为分布式非常困难；通常也不大可能从根本上改变系统所用的程序语言，这意味着一些老系统难以被转换到如Java或C+这样的面向对象程序设计语言上；且由于软件功能没有变化，所以系统原有的局限性仍然存在。4343第13章 软 件 演 化然而，从业务角度看，对于有较高使用价值的软件系统，再工程可能是保证遗留系统能继续提供服务唯一可行的方法。改用其他任何方案都将带来更高的费用和更高风险。原因在于遗留系统中的代码量是极大的。20世纪90年
25、代以后，支持业务过程的计算机应用在大幅增加。因此，估计到目前为止，大约有2500亿行源代码需要维护；其中大部分都不是采用面向对象语言编写的，而且它们大多数是运行在大型机平台上。4444第13章 软 件 演 化软件系统再工程方法与其他方法相比有两个绝对优势：一是可减少风险。对机构所用的某个基本软件系统做重新开发是个高风险的决策，比如系统中会发生错误，会出现开发中的种种问题等；二是可降低成本。再工程的成本较之重新开发一个软件的成本来说要小得多。比如一个商业系统，该系统新开发的成本高达5000万美元，而再工程的成本仅仅1200万美元。有数据表明，再工程的费用大约是重写同一个系统费用的1/4。4545
26、第13章 软 件 演 化另外，软件再工程和业务过程再工程有密切的关联。业务过程再工程是指重新设计业务过程来减少多余的活动并提高过程的效率。由于遗留系统与现有业务过程存在着固有的依赖关系，业务再工程通常是软件进化的驱动器。由于软件系统与业务过程存在着这些联系，因此，当业务过程再工程需要对软件系统做大的改变，而这又不可能通过程序维护达到时，就需要对软件系统进行再工程。4646第13章 软 件 演 化再工程与新软件开发之间的重要差别在于软件开发的起点上。再工程不是从系统需求定义开始，而是将旧系统作为新系统的定义。如果称传统的开发为正向工程，则正向工程和再工程的区别如图13.6所示。正向工程开始于系统
27、定义，并进行设计和实现。再工程开始于已有的系统，开发过程基于对原始系统的理解和转换。4747第13章 软 件 演 化图13.6 正向工程和再工程4848第13章 软 件 演 化 图13.7所示是一个可能的再工程过程。过程的输入是一个遗留程序，输出是一个结构化和模块化的程序新版本。在程序再工程的同时，系统的数据也可能要被再工程。4949第13章 软 件 演 化图13.7 再工程过程5050第13章 软 件 演 化再工程过程中的主要活动有：(1)源代码转换。程序从旧的程序设计语言转换到相同语言的一个较新的版本或另一种语言。(2)逆向工程。对程序进行分析并从中抽取信息以获取系统的结构和功能信息、恢复
28、系统文档。(3)程序结构改善。对程序的控制结构进行分析和修改，使它更容易读和理解。(4)程序模块化。程序的相关部分被收集在一起，在一定程度上消除冗余。在某些情况下，这个阶段可能会产生软件系统体系结构的转换。(5)数据再工程。对程序处理的数据做改变来反映程序变更。5151第13章 软 件 演 化再工程不一定需要图13.7中的所有步骤，如果所用的程序设计语言仍能得到编译器支持，源代码就没有必要做转换；如果再工程完全依赖于自动化工具，那么通过逆向工程来恢复文档就没有必要。数据再工程只有在程序中数据结构发生改变时才需要。再工程不管怎样总是包括一些程序重建工作。再工程的成本明显依赖于所做的工作范围。图1
29、3.8给出了再工程可能使用的方法，成本从左到右逐渐增长，所以源代码转换是最经济的活动，而再工程加上一部分体系结构改变是费用最高的活动。5252第13章 软 件 演 化图13.8 再工程方法5353第13章 软 件 演 化除了再工程的范围之外，影响再工程成本的主要因素还有：(1)需要再工程的软件的质量。软件和相关文档(如果存在)越少，再工程的成本就会越高。(2)可用的工具支持。除非能使用CASE工具自动完成大多数的程序变更，否则一般来说再工程的成本会很高。(3)所需的数据转换的范围。如果再工程需要对大量数据做转换，这将极大地增加过程的成本。(4)成员的可用性。如果负责维护系统的人员不能参与到再工
30、程过程中来，这将会增加成本，系统再工程人员需要花很多的时间来理解系统。5454第13章 软 件 演 化再工程的缺点是系统经过再工程得以改善的范围有限。比如，它不能把面向功能的系统转换为面向对象的系统；主要体系结构的变更或对系统数据管理的重新组织不能自动地执行，因此需要额外的高成本；虽然再工程能改善可维护性，但经过再工程的系统不可能像用现代软件工程方法开发的新系统一样容易维护。5555第13章 软 件 演 化13.3.2 源代码转换 软件再工程的一个最简单的形式是程序转换，将原用一种语言编写的源代码转换为以另一种语言编写的源代码，程序本身的结构和组织不发生变化。目标语言可以是原先使用的语言的新版
31、本，例如从COBOL-74到COBOL-85；或者是一种全新的语言，例如从FORTRAN到C语言。5656第13章 软 件 演 化源代码转换有时是必要的，一是因为硬件平台升级，硬件平台升级后，最初语言编译器可能无法在新硬件平台上使用；二是技术人员不足。软件的生命周期较长时，受过最初语言维护培训的人员可能越来越缺乏，例如，原金融系统普遍采用的COBOL语言，在我国的软件人员中，熟练掌握的较少。另外，机构的政策变更也是一个因素。机构可能决定统一所用的语言，从而将支持软件成本减到最少。再者，原有系统可能缺乏软件和工具的支持。例如，语言编译器的提供商可能不再从事这项业务，或者是不再支持这个产品，市场上
32、也缺乏支持这些语言的维护和开发工具。5757第13章 软 件 演 化图13.9说明了源代码转换的过程。在这个过程中，不需要理解软件运行的详细内容，也没有必要修改系统体系结构。所需的分析集中在编程语言本身，如考虑程序的控制结构等价性等。5858第13章 软 件 演 化图13.9 程序转换过程5959第13章 软 件 演 化值得注意的是，只有存在源代码的自动转换软件能对大部分源代码自动进行转换时，源代码转换才是经济的。源代码转换器可能是从一种语言转换到另一种语言的专门工具或是模式匹配系统。如果是模式匹配系统，必须给出一组规则描述说明该如何从一种表示法转换到另外一种表示法。源语言中的参数化模式是需要
33、定义的，然后将它映射到目标语言，作为一种等价模式。6060第13章 软 件 演 化在许多情况下，完全的自动转换是不存在的。源语言中的结构可能在目标语言中没有直接的等价形式，比如源代码中嵌入的条件编译指令在目标语言中得不到支持。在这些情形下，需要手工完成系统的代码转换。6161第13章 软 件 演 化13.3.3 逆向工程很多情况下，时间的流逝和开发过程的不规范会造成软件文档的缺失，为维护带来较大困难，逆向工程致力于解决这类问题。逆向工程是以复原软件的描述和设计为目标的对软件的分析过程。程序本身经过逆向工程过程并无变化。逆向工程过程通常从软件源程序代码着手，如果源代码遗失，逆向工程只好从可执行代
34、码分析开始。逆向工程不同于再工程，逆向工程的目标是要从软件的源程序代码导出系统的设计和描述，而再工程的目标是产生一个新的更易维护的系统。6262第13章 软 件 演 化软件再工程过程借助逆向工程来复原程序设计，以帮助工程师在重组系统的结构之前理解程序。尽管如此，逆向工程并不总是与再工程一起进行，一是对现行系统进行逆向工程所生成的设计和描述可以作为系统替代品的需求描述的参考，以利于构造和开发新系统；二是逆向工程所得的设计和描述有助于程序的维护，通过逆向工程恢复的信息和文档，可以不必再对系统源代码进行再工程。6363第13章 软 件 演 化图13.10说明了逆向工程的过程。逆向工程始于一个分析阶段
35、。在这个阶段中，使用自动化工具对系统进行分析来发现它的结构。但这不足以重建出系统的设计，还要参考系统源代码和系统的结构模型，在对系统理解的基础上添加信息到所收集的设计信息中。这些信息被组织为有向图模型，这些模型与程序源代码相关联，例如程序的控制流图、数据流图等。6464第13章 软 件 演 化图13.10 逆向工程过程 6565第13章 软 件 演 化文档生成工具可以将信息库的图结构和代码生成为可被开发人员理解的各类文档，并使用分析的信息加以注释，例如程序和数据结构图、可追溯矩阵等。可追溯矩阵表示出程序实体是在系统何处定义的又是在何处被引用的，如对一个函数，其追溯矩阵可表示出函数的算法设计、需
36、求定义出处等。文档生成的过程是个循环的过程，因为设计信息又可以用于对系统存储中的信息做进一步的提炼。6666第13章 软 件 演 化用于程序理解的工具可以用于支持逆向工程过程。这些工具通常依据不同的建模规范和建模角度表现出不同的系统视图，例如有的逆向工具可生成UML模型视图，而有的工具则生成控制流程图。视图提供在源程序代码间的导航。在系统设计文档产生出来之后，通常需要对系统结构做进一步的手工注释，因为描述不可能完全从系统模型中自动导出。6767第13章 软 件 演 化13.3.4 程序结构改善许多遗留系统的结构较差，受当时的软件技术所限，在程序的控制结构中可能存在很多无条件分支和难以理解的控制
37、逻辑，而频繁的维护往往会使控制结构变得更糟。例如，对程序所做的变更可能使得某些代码变得根本不可达，而维护人员也不敢轻易删除这些代码，以防万一这些代码被间接访问到。表13.1中的例子是个供暖系统控制器，这是一个相对较简单的程序，但由于使用非结构化的程序设计而使其控制逻辑变得复杂和难以理解。6868第13章 软 件 演 化6969第13章 软 件 演 化该程序是使用类似于FORTRAN语言编写的。在该例子中，面板开关可以设置为On、Off或Controlled。如果系统处于受控状态，那么开关置于开和关状态依赖于定时器和温度调节装置的设定。如果加热器处于开状态，Switch-heating把它转换为
38、关状态，反之亦然。在这个示例中，大量使用了无条件转移语句，致使程序结构不是很好，也较难理解。随着维护过程中不断进行修改，程序中的逻辑结构变得更为复杂。新的条件和相关的动作被添加进旧的控制结构中。在短期内，这是一种降低风险的做法，因为减少了向系统中引入缺陷的可能性。但是，长期来看，这样做的后果是使代码难以理解，同时，修改过程中程序员试图避免代码重复造成了复杂的代码结构。7070第13章 软 件 演 化表13.2给出的是用结构化控制语句对同一控制系统的改写。程序可以从上到下顺序阅读，所以要容易理解得多。三个开关位置(开、关和受控)被清晰地表示出来并连接到相应代码。因为最初的语言不是面向对象的，所以
39、未用面向对象的语言来改写。7171第13章 软 件 演 化7272第13章 软 件 演 化表13.1中无结构的控制，使复杂的条件语句在程序结构重构过程中得到简化。表13.3说明了含有“非”逻辑的条件语句是如何简化的，从而使程序变得更容易理解。7373第13章 软 件 演 化7474第13章 软 件 演 化程序结构的重构和改善可以采用自动程序重构工具来实现。可以证明任何程序都可以用简单的if-then-else条件语句和while-loop语句重写，无条件goto语句是不必要的，这是自动程序重构的基础。图13.11给出了运用软件工具实现自动程序结构重构的几个阶段。首先是将待重构的原程序转换为有向
40、图，然后依据有向图生成一个不带goto语句的结构化的等价程序。7575第13章 软 件 演 化图13.11 自动的程序结构化过程7676第13章 软 件 演 化有向图为程序流图模型，可以描述程序中的控制转移结构，类似于第12章中介绍的自动静态分析技术，通过它可以检测出代码中的不可达部分并删除之。在此基础上，根据程序的重写规则就可以生成新的程序。while-loop语句和简单条件语句代替了基于goto的语句控制。重构后的程序可以使用原先的语言，也可以使用一种不同的语言，例如可以从FORTRAN语言转换为C语言。7777第13章 软 件 演 化使用自动程序结构重构工具会带来注释和文档信息的缺失。如
41、果原程序中有内嵌的注释，会因使用软件重构工具而造成注释不可再现；外部的程序文档和原程序之间的映射关系也会因结构重构而变得不再有效。另外，结构重构工具的算法较为复杂，如果需要重构的系统较为庞大，则重构计算的过程需要很大的计算量和较长的时间。而通常，需要重构的系统不会是一个简单系统。7878第13章 软 件 演 化代码结构重构对于那些非结构化程序系统和非良构的结构化系统较为有效。如果程序是数据驱动的，则组件间通过共享数据结构紧密地耦合在一起，代码结构重构就不一定能带来很大的改善。在某些情况下，对系统所有程序做结构重构并不合理，因为系统中有些程序的质量较好，而有些则没有经过频繁变更。一般情况下，应该
42、收集数据帮助分析哪些程序通过结构重构能得到较大的改善。可以通过度量程序的失效率、源代码每年变更的百分比、组件复杂性以及组件达到现行标准的等级找出结构重构的候选对象。7979第13章 软 件 演 化13.3.5 程序模块化程序模块化也是对程序重新组织的过程，其目标是改善原有老系统的模块化特性。程序模块化将系统中具有紧密关联的程序部分聚集在一起作为单一模块。程序模块化能消除相关组件中的冗余、优化组件间的交互、弱化它们与其他程序的耦合。例如对于一个气象数据收集和气象地图生成处理系统，与数据的图形化表示相关的操作可以被集合在一起作为一个模块，负责驱动设备采集数据的程序作为一个模块，负责传送处理分布于各
43、个气象站的数据的程序作为一个模块。8080第13章 软 件 演 化在程序模块化过程中创建的模块类型可以有很多，包括：(1)数据抽象模块。将数据和处理部分相关联，形成抽象数据类型。例如，对于面向对象的系统，这些模块可被封装成一个对象类，通过对象接口对其访问。(2)硬件模块。这些模块是与硬件紧密相关的，把控制特殊硬件设备的功能集中在一起。(3)功能模块。这些模块是相似功能或与任务紧密相关的功能的集合。例如，所有的有关输入和输出有效性验证的功能可以被放在一个模块中。(4)过程模块。这些模块是支持一个特定业务过程所需要的功能和数据的集合。例如，在图书馆管理系统中，过程模块可能包括支持图书发放和归还所需
44、的所有功能处理。8181第13章 软 件 演 化13.3.6 数据再工程迄今为止，有关软件演化的大多数讨论把重心集中在程序和软件系统变更上。然而在许多情况下，软件演化还涉及到数据进化的问题。遗留系统所处理的数据，其存储、组织和格式也须经过演化来适应软件的变更。对数据结构的分析和重组过程，有时还包括对系统中的数据值的分析过程，被称为数据再工程，这些过程有助于更好地理解这些数据结构及其值。8282第13章 软 件 演 化原则上讲，如果系统的功能没有发生改变，那么数据再工程就没有必要。但在实际过程中，会因种种原因使得在对遗留系统的程序做修改时也需要同时修改数据结构或数据。首先，由于系统的数据可能会退
45、化。随着时间的推移，数据的质量在逐步下降。长期的维护过程中，由于对数据的变更引入了错误，数据可能产生了多个副本，来自外部环境的变更也可能没有反映到数据中。8383第13章 软 件 演 化其次，是因为程序本身的限制。在进行最初的设计时，很多程序的开发者对所处理的数据量都有一定的限制。然而，程序现在时常需要处理比估计的数据量多的数据。数据再工程需要修正或取消这些限制。例如，20和21世纪之交的千年虫问题，就引起了全球大量系统的再工程。另外，体系结构需要进化。例如，现在的系统广泛建立在计算机网络的基础上，其系统结构是分布式的。如果一个老的遗留系统，其集中式的处理要转换到分布式体系中，其核心是能被远程
46、客户机访问的数据库管理系统，就需要较大的数据再工程工作量。表13.4反映了数据再工程的方法8484第13章 软 件 演 化8585第13章 软 件 演 化遗留系统中的数据可能有如下问题：(1)数据的命名问题。所用的名字可能很晦涩、难以理解。在系统的不同程序中会给相同的逻辑实体命名不同的名字(同义)。同一个名字在不同的程序中可能用来指不同的实体。(2)域长度问题。这个问题往往出在程序中记录的域长度被显式定义的时候。在不同的程序中同一个项可能被赋予不同的长度，或者是域长度设置得太短而无法表现目前的数据。为了解决这个问题，有些时候复用其他的域，所以程序中有名字的数据域在系统中会造成不一致。8686第
47、13章 软 件 演 化(3)常量的直接引用。常量被直接包含在程序中，而不是通过符号名引用。(4)没有数据字典。可能没有数据字典来定义所用的名字以及名字的表示和使用。(5)数据定义的不一致问题。数据值也可能以多种不一致的方式被存储。在数据定义被再工程之后，数据值也必须被转换，使之与其结构相适应。表13.5描述了一些可能的数据值的不一致性。8787第13章 软 件 演 化8888第13章 软 件 演 化对使用数据的程序进行详细分析是进行数据再工程之前的必要工作，其目的是：发现程序中标识符的含义，找出命名常量的数量值，发现数据有效性验证规则和数据表示法的变化。一些工具如交叉索引分析器和模式匹配器可以
48、用来帮助进行这种分析。可以用表格来显示数据在哪里被引用以及对每个引用要进行的改变。图13.12说明了数据再工程的过程，其中包括数据定义的修改、常量值的命名、数据格式的更新以及数据值转换。变更汇总表记录了所有这些变更的详细内容，在数据再工程过程中的所有阶段都可使用。8989第13章 软 件 演 化图13.12 数据再工程过程9090第13章 软 件 演 化在这个过程的第一阶段中，修改程序中的数据定义可以改善程序的可理解性。数据本身在这一修改中没有发生改变。采用一些模式匹配系统可以帮助自动完成这个过程，这些模式匹配系统可以发现和替换数据定义，也可以将这些定义用XML语言进行描述。XML可以作为一种
49、通用的公共数据交换标准，作为一种中间数据模型，以驱动数据转换工具完成数据转换。一般来说，一个系统的数据完全自动地转换难以做到，手工操作是不可避免的。9191第13章 软 件 演 化如果数据再工程的目的仅仅是改善数据结构定义的可理解性，那么数据再工程过程只需完成第一阶段的工作。然而，如果有数据值的问题，那么就要进入过程的第二阶段。并在此后执行第三阶段的工作，即数据转换。这个阶段通常需要编写程序，来处理老数据以及输出经过转换的信息，这个过程的代价较大。有时可以借助有效的模式匹配系统来实现这个转换。9292第13章 软 件 演 化本 章 小 结软件的长期运行会因本身的缺陷、需求的变化而不断地演化，即
50、进入软件的演化阶段，以保证软件长期处于可用状态，并能够适应实际业务的不断变化。软件演化主要涉及维护和再工程活动。软件维护是为了修改软件缺陷或增加新的功能而对软件进行的变更，实际上只对软件进行局部变更，不改变整个系统的总体结构。改正性维护、适应性维护和完善性维护是典型的软件维护类型。9393第13章 软 件 演 化软件再工程是为了避免软件的退化而对软件的一部分重新进行设计、编码和测试，以提高软件的可维护性和可靠性等，为以后进一步的软件维护打下良好的基础。软件再工程过程包括源代码转换、逆向工程、程序结构改善、程序模块化和数据再工程。9494第13章 软 件 演 化习 题1解释为什么遗留系统对业务运
