模式化轻松重用过去

软件拒绝喜新厌旧

重用软件再工程的灵魂

举一反三的结果——面向模式的Web化再工程辅助平台eVWB

Web化再工程的两种整体解决方案

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

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

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

    重用越多越好

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

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

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

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

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

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