重用是软件再工程的最高境界，如果不追求重用，软件也就可以和硬件一样弃旧迎新了。软件再工程面对的不是原始需求，而是既存软件，因此开发者面临的第一个课题将是“如何重用既存系统”。

软件重用是指重复使用软件资源的过程。软件资源有产品，也有过程，所以软件重用也可以分为产品重用和过程重用。对软件再工程来说，产品重用似乎是最现实的主流途径，其内容可以包括需求规格、体系结构、设计规约、测试用例、源代码乃至可运行代码等。

软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。不过对再工程来说前者很大一部分内容是对既存系统中非可重用构件的改造。

重用越多越好

在软件再工程的各个阶段，软件的可重用程度都将决定软件再工程的工作量。

再分析　再分析阶段的主要任务是对既存系统的规模、体系结构、外部功能、内部算法、复杂度等进行调查分析。这一阶段早期分析最直接目的就是调查和预测再工程涉及的范围。北京工业大学软件工程研究所研制开发的“软件再工程辅助调查工具——SFRE”正是从整体上支持该分析阶段的再工程自动化工具。重用是软件工程经济学最重要原则之一，重用得越多，再工程成本越低，所以逆向工程再分析阶段最重要的目的是寻找可重用的对象和重用策略，最终确定的再工程任务和工作量也将依存于可重用对象范围(重用率)和重用策略。

与一次工程不同，再工程分析者最终提出的重用范围和重用策略将成为决定再工程成败以及再工程产品系统可维护性高低的关键因素。如果重用对象都是既存代码级的当然理想，然而可能性有限。但是再工程分析者如果因此而放弃重用，以为“改他人的代码不如自己重新编写”，便犯了再工程的大忌。因为一个运行良久的既存系统，最起码的价值是在操作方法和正确性上已被用户接受。而再高明的程序员在软件没有经过用户一段时间的使用验证之前都不敢保证自己的程序正确无误;更何况越是有经验的程序员越是知道对一个处于局部变更地位的程序进行重新编写远比一次工程的原始编程复杂得多，因为他需要对应无数的“副作用”，正所谓“碰一筋而动全身”。所以，读文档——即使是“破烂不堪”、读代码——即使是“千疮百孔”，也要坚持住，并且从中筛出可重用对象。

再编码　根据再分析阶段做成的再工程设计书，再编码过程将在系统整体再分析基础上对代码做进一步分析。如果说再分析阶段产品是再工程的基本设计书，那么再编码阶段如同一次工程一样，先要产生的是类似详细设计书的编码设计书。但是再工程比一次工程更难以进行过程分割，换言之，瀑布模型更不适应再工程，无法将再分析、再设计、再编码截然分开。

再测试　一般来说，再测试是再工程过程中工作量最大的一项工作。如果能够重用原有的测试用例及运行结果，将能大大降低再工程成本。对于重用的部分，特别是可重用的（独立性较强的）局部系统，还可以免除测试，这也正是重用技术被再工程高度评价的关键原因之一。当然再工程后的系统总有变动和增加的部分，对受其影响的整个范围都要毫无遗漏地进行测试，不可心存侥幸，以免因“一个苍蝇坏了百年老汤”。

实用的重用战略

在判断既存系统应该如何重用时，首先要明确哪些是可重用对象，以及如何使用这些可重用对象。下面以既存LAN系统重构成Web系统的再工程为例，说明再分析和再编码将遇到的一些重用课题。

我们可以将既存LAN系统划分成界面、逻辑、数据三个层次。用既存系统的三个层次去分别对应典型Web系统的表示层、逻辑层和数据层。由此从逻辑上得到对应每个层次的输入和输出，然后为每一层寻找能够实现最大程度重用的重构方法。

● 界面重用策略

界面模拟方法　将基于文本的旧界面包装为新的图形界面。旧界面运行在终端上，新界面可以是基于PC的图形界面，也可以是运行在浏览器上的HTML页面。新用户界面通过一个界面模拟工具与旧界面通信。此方法重用率相当高。但是不修改既存系统会同时将旧系统的结构性缺点全部继承下来。

基于客户端的Web应用（Java Applet）　Applet可以实现从界面、逻辑到数据库的许多功能。完全用Java语言重写一个系统是不现实的，重用率也不会很高，这不是软件再工程所提倡的。但目前已有许多Applet自动转化工具，而且其转化后代码的重用率相当高。

基于服务器端的Web应用　即重新开发界面。这种方法看上去没有重用既存界面代码，其实不然。首先，界面设计完全可以重用，从而节省设计时间；其次，我们可以将某些界面做成可重用的，这样也会减少工作量。

● 逻辑层包装原则

通过对逻辑层的分解可以得到可重用和不可重用的两部分代码。对可重用部分可直接使用，对于不可重用部分则应尽量通过各种包装技术按统一标准将其改造成可重用构件。包装方法有很多，如对象包装法、部件包装法等。

● 数据层重用策略

数据层通常要求更高的重用率。逻辑和数据休戚相关，如果改动数据库，逻辑势必不能正常运行，对逻辑部分的重用也就无从谈起。如果非改不可的话，也要以保证最大限度的重用为原则，争取做到只增不删，以保证数据的完整性。

制度保证软件重用

和软件开发是团队的事业一样，软件重用不是个人行为。一个组织如何系统化地实现软件重用呢？答案是软件重用制度化，其内容包括：

（1）管理层支持　软件重用初期投资较大，盈利周期较长，没有管理层的明智决策寸步难行。

（2）软件开发过程改革　传统软件开发方法在高速、高效、高质的软件开发市场需求面前越来越显得无力。尽快摆脱传统思路束缚，建立起全新的基于重用的软件开发过程是软件企业亟待解决的问题。

（3）克服非技术因素　非技术因素主要指人的因素。许多程序员长期在传统软件开发方法下工作，逐渐形成了一套自成一体的开发习惯，让他们摒弃老方法，必然会产生抵触心理。实现软件重用制度化，必须让开发人员都能对软件重用有深刻理解，都能成为重用制度的自觉执行者。

（4） 对可重用软件的奖励　使用可重用软件，可以减少工作量、降低成本、保证质量、提高系统价值水平。要鼓励大家从事可重用性开发，对于重用程度高的软件应给予奖励。

（5）软件重用定量化标准的确立　软件开发费用、开发规模、产品质量等都与软件重用定量化标准有关。可以用重用率、沉积率、重用力度等指标定量化表示软件重用。其中重用率用可重用代码占总代码比例或可重用对象占整个系统对象的比例来计算；沉积率指重用对象占开发出的总对象的比例；重用力度指重用对象被使用的次数。有了软件重用定量化标准，我们才能对工程进行合理的评估，奖励制度才有依据。

（6）软件重用的自动化　软件重用制度化的终极目标就是提高软件生产率。软件重用自动化不仅指自动实现对可重用构件的提取，还能自动实现对可重用构件的管理和维护。

（计算机世界报 第44期 B6、B7）