软件再工程的类型 <br />2002-11-25 12:56:22<br /><br />--------------------------------------------------------------------------------<br /> <br /><br />严格地说，再工程的潜在需求尽管大得不可估量，但目前只能说是进入了再工程时代。其理由众所周知:一是资金不足——再工程需要大量投资；二是软件开发人员不足。所以除了应付尚未实施的一次软件工程外，可以有计划地 投入再工程的资源很有限。目前的再工程主要为三类： <br /><br /><br />● 适应性维护的再工程 <br /><br /><br />① 伴随硬件和操作系统更新换代的软件维护。像小型机换PC机、PC机换Unix工作站、Win95换WinXP所带来的软件维护。 <br /><br /><br />② 业务环境变化带来的软件维护。譬如由于企业业务的发展和系统使用年限的增加，既存系统的存储媒体和数据管理系统满足不了数据量及其种类剧增的要求，需要更新数据库系统；随外部条件变化而必须修改部分数据变量定义或算法，例如征收消费税的法律修订、邮政编码位数改变、2000年问题等。 <br /><br /><br />③ 系统运行环境变化带来的软件修正。如由主机方式变为客户/服务器方式，由客户/服务器方式变为Web方式，这时的系统体系结构必须做相应的改变。 <br /><br /><br />④ 适应系统开发环境变化的软件维护。有一些软件，主要是定制软件，如ERP软件等，其软件再工程常伴随企业的BPR发生，所以开发环境也需随经常性的系统完善性再工程而更新，譬如PowerBuilder等开发环境的升级换代如同操作系统一样频繁发生。 <br /><br /><br />● 完善性维护的再工程　增加或修改功能，以提高系统的安全性、处理能力等性能。 <br /><br /><br />● 预防性维护的再工程　为了提高可维护性而对系统进行优化（再结构化、再标准化等），对文档进行重构，对数据进行重组。

模式化轻松重用过去<br /><br />北京工业大学软件工程研究所　赵晓华<br /><br /><br />--------------------------------------------------------------------------------<br /> <br /><br />很多搞软件的人喜欢将目光盯在程序上。着眼于程序还是系统，只要看他是就事论事还是举一反三就大致可分经纬。软件再工程如果“就事论事”，就会陷入“维护地狱”，只有“举一反三”——模式化思考——才能从“地狱”中自拔。 <br /><br />20世纪90年代“软件模式（Software Patterns）”被引入软件工程，确切地说是再工程将其引入了软件开发技术。这可能是软件工程诞生以来最大的一次理论飞跃，也开创了一个新的理念—— <br /><br />再工程与模式化运动 <br /><br />美国加利佛尼亚大学环境结构中心研究所所长Alexander博士用了约20年的时间，对舒适住宅和周边环境进行了大量的调查和资料收集工作，发现人们对舒适住宅和城市环境存在着共同的认同规律。他把它们归纳为253个模式，对每一个模式都从Context（模式可适用的前提条件）、Theme或Problem（在特定条件下要解决的目标问题）、Solution（对目标问题求解过程中各种物理关系的记述）三个侧面进行描述，并给出了从用户需求条件分析到建筑环境结构设计直至经典实例的过程模型。 <br /><br />Alexander的贡献主要在两方面:其一是集既往之大成——它概括归纳了迄今为止各种风格建筑师的共同设计规则，给东西方、古代派、现代派建筑设计与城市规划提供了共同的语言和准则;其二是他不仅给出了方法，还给出了最优解决方案。 <br /><br />在Alexander研究模式以前，人们注重研究的是高质量、高效率、低成本的系统开发方法，而Alexander的模式注重则是“什么是最好的、成功的”系统。为了找出最优方案——模式，Alexander用了20年对既存物进行比较分析；如果没有对大量既存建筑的逆向分析，就不可能筛选出最优方案，从这一点可以说模式思想起源于再工程。 <br /><br />1990年，软件工程界开始关注这一住宅、公共建筑与城市规划领域的重大突破。最早将该思路引入软件工程方法学的是1991～1992年以“四人帮（Gang of Four，GoF）”自称的四位著名软件工程学者，他们在1994年归纳发表了23种设计模式，旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。 <br /><br />所谓“模式”是指遵从某种规则或规律反复出现的思维方式或表现。Alexander把模式的集合称为模式语言（Pattern Language）。构成模式语言的各模式是针对某一特定前提的解法，它们记述着我们身边频繁发生的某类问题及其基本解法。我们可以反复使用这些解法，对同类问题可以使用同一解法，而不必总是一切从头做起。模式并不是单独存在的，它们可以由粒度小的模式组合而成，也可以和其他模式一起组合成粒度更大的模式。 <br /><br />软件模式是将“模式”的一般概念用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于“设计模式”，还有“体系结构模式”、“分析模式”、“过程模式”等，软件生存期的各个阶段都存在着被认同的模式。换言之，是不是软件模式取决于是否按照模式的基本构成方式来描述，而与问题域和以软件生存期的哪一阶段为对象无关。根据这一思路，近来的模式化研究已将模式概念的应用从软件开发领域推广到组织机构、应用业务、经营活动甚至日常生活领域。对此西方称之为“模式化运动”。 <br /><br />面向模式的软件再工程 <br /><br />模式不是面向特定的，而是面向一般的；模式应该能够得到广泛认同；模式的形态是多样的，可以是物理实现级的，也可以是逻辑抽象级的，可以是方法模式，也可以是过程模式、结构模式；非模式是一对一的，模式是一对多的；模式可以重用…… <br /><br />模式的思想是基于对既成的继承——对既存系统的模式化抽象和既成模式的再利用。面向模式是在面向对象思路上建立起来的，可以将软件模式看成“宏对象类”，这是一个理解软件模式的捷径。  <br /><br />可以认为软件模式是对软件开发这一特定“问题”的“解法”的某种统一表示，它和Alexander所描述的模式定义完全相同，即软件模式=一定状况下的{问题+解法}。如图1所示，软件模式的基础结构由4个部分构成：问题、前提条件、解法和适用结果。 <br /><br />目前尚没有对于上述基本构成表述法的约束，因此用UML、DFD或其他表述法在理论上都是允许的。由于面向模式方法也被解释为“宏面向对象方法”，所以一般用UML表述较顺理成章，特别是对下层使用Java、C++等面向对象语言的软件模式而言。图2是用UML类图表述的软件模式元模型。 <br /><br />根据软件模式的基本构成，我们可以按模式用户的问题域特征来分类，例如系统结构化、分散系统、交互系统、结构分割、存取控制、作业管理、服务多样化、服务扩充、通信、资源管理等；也可以从求解的约束过程（即软件生存期）来分类，如体系结构模式、分析模式、设计模式、实现模式/方言等。  <br /><br />根据软件工程的分割原则，模式是可以多层次细分的，所以软件模式究竟应该分成多少类多少种，现在远不能做结论。对GoF归纳的23种设计模式有人认为太多太细，也有人认为不能包含所有的设计模式。 <br /><br />软件再工程首先面对反面模式 <br /><br />如果说软件模式研究的是最优软件模式，即正面模式、成功模式，那么研究频繁出现的最劣软件模式、失败模式，并给出改善它们的解决方案就是反面模式的目的。换言之，如果说一次软件工程要面向正面软件模式——特定前提下的最优解，那么再工程大部分面临的是反面模式——最拙劣解。 <br /><br />反面模式（Anti-Patterns）的概念是在1996年首次由米切尔·阿克鲁提出来的，它研究软件开发既存问题及其解法。反面模式主要研究最常见的拙劣软件模式特征、识别方法，以及改善（再构）方法。 <br /><br />一些反面模式研究者主张将反面模式分为：反面开发模式，该模式与软件开发者有关，以各种编程问题为中心；反面体系结构模式，该模式与系统设计者有关，以各种软件系统结构问题为中心；反面项目管理模式，该模式与项目管理者有关，以各种项目组织与过程管理为中心。 <br /><br />目前成为再工程研究热点的再构，大部分研究的是针对反面开发模式的解决方案，例如下面一些反面开发模式: <br /><br />臃肿模式（The Blob）　让一个对象承担起几乎全部重要处理过程。 <br /><br />不断退化模式（Continuous Obsolescence）　其软件价值跟不上技术变化，例如使用带有年号的软件产品，像“product2000”，必须不断对它们进行版本升级，才能适应不断发展变化的新技术、新环境、新平台。像微软的OLE 1.0、OLE 1.2、COM、ActiveX、DCOM、DDE等都属此列。 <br /><br />熔岩流模式（Lava Flow）　熔岩流即“死代码（遗留在软件中的无用代码）”或“废文档”。随着软件的调试和维护，常会有很多无用的“熔岩块”被丢弃在各处。 <br /><br />思路不清模式（Ambiguous Viewpoint）　将面向对象编程思路用于面向对象分析设计，造成无意义的面向对象分析设计等。 <br /><br />从再工程过程中抽象软件模式  <br /><br />据《美国程序员》杂志1995年7月号提供的统计资料，全球大约5/6的软件项目存在失败的部分；1/3中途而废；2/3预算经费翻番，其中一半用于需求和设计变更。我们可能无法像Alexander那样从大海一样的既成物中淘出253个硕大珍珠——模式，但是在一个个的再工程中发现比比皆是的反面模式，并通过再构将其改造为可以重用的正面模式，这是可以做到的（参看图3）。 <br /><br />模式化思考推动自动化 <br /><br />从再工程过程可以抽象软件模式，模式是一对多的，可以重用。只有从特殊问题抽象出一般问题，并对其求解，从而实现“问题→前提条件→解→效果”的模式链，一个软件工具——同一类问题的求解模式的自动化实现——才能诞生。 <br /><br />自动化不仅可以使我们走出“维护地狱”，更可以运用继承到的模式轻便地定制新的软件系统。我所目前拥有的多个自主版权的产品，如支持开发环境变化适应性维护的自动化解决方案——多功能版本升级辅助工作台VWB、逆向分析工程支持工具——再工程调查工具SFRE，以及已经历时近两年即将发布的Web化系统重构自动化解决方案eVWB，都可以说是上述模式思维的产物。 <br /><br />从我们的实践经验出发，一个面向模式的软件再工程过程可以归纳如下： <br /><br />（1） 对既存系统进行模式化抽象，继承原开发方法的实现结果，用再结构化技术在物理级（通过中间件、桥接件、对象包装技术等）解决原不同方法学之间的沟通； <br /><br />（2） 继承再工程目标系统的既成体系结构模式、设计模式、实现模式，必要时也可对既成模式进行适当的修改和追加； <br /><br />（3） 对再工程过程或最终产品进行模式化处理，即对其进行再造、再结构化、再构、文档重构等加工，使其成为可重用模式，并保存到既成可重用模式库（Repository）中； <br /><br />（4） 重复步骤（1）～（3），使可重用模式库不断扩充和完备，直至达到像253个建筑环境模式一样可以基本包含绝大部分软件模式； <br /><br />（5） 诞生可重用软件工程模式库，以此为基础支援各种一次或再次软件工程。 <br /><br />从原始概念来说，软件再工程自动化与CASE应是同义词。但是由于最初的CASE工具基于软件生存期的瀑布模型，而瀑布模型是基于过程的，过程集成是全自动化的关键。但是过程集成相当复杂，受数据集成和控制集成的制约，要使处于变动中的整个开发过程不同阶段、不同工具加工出来的各种数据都保证连续、完备、一致非常困难，所以CASE产品大多庞大、烦琐，对用户（开发者）的约束很苛刻，高价却适应面狭窄，长期以来被比喻为“公主”、“贵族小姐”，始终被束之高阁，没能走入“平民社会”。软件再工程自动化与CASE也因此成为两个概念。 <br /><br /> <br /><img src='http://www2.ccw.com.cn/02/0244/b/pic/b01_2t1.jpg' border='0' alt='user posted image' /><br /><img src='http://www2.ccw.com.cn/02/0244/b/pic/b01_2t2.jpg' border='0' alt='user posted image' /><br /><img src='http://www2.ccw.com.cn/02/0244/b/pic/b01_2t3.jpg' border='0' alt='user posted image' />

重用：软件再工程的灵魂<br /><br />■ 北京工业大学软件工程研究所　张振彪<br /><br /><br />--------------------------------------------------------------------------------<br /> <br /><br />重用是软件再工程的最高境界，如果不追求重用，软件也就可以和硬件一样弃旧迎新了。软件再工程面对的不是原始需求，而是既存软件，因此开发者面临的第一个课题将是“如何重用既存系统”。 <br /><br />软件重用是指重复使用软件资源的过程。软件资源有产品，也有过程，所以软件重用也可以分为产品重用和过程重用。对软件再工程来说，产品重用似乎是最现实的主流途径，其内容可以包括需求规格、体系结构、设计规约、测试用例、源代码乃至可运行代码等。 <br /><br />软件再工程是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统的各种资源是再工程的最重要特点之一。从软件重用方法学来说，如何开发可重用软件和如何构造采用可重用软件的系统体系结构是两个最关键问题。不过对再工程来说前者很大一部分内容是对既存系统中非可重用构件的改造。 <br /><br />重用越多越好 <br /><br />在软件再工程的各个阶段，软件的可重用程度都将决定软件再工程的工作量。 <br /><br />再分析　再分析阶段的主要任务是对既存系统的规模、体系结构、外部功能、内部算法、复杂度等进行调查分析。这一阶段早期分析最直接目的就是调查和预测再工程涉及的范围。北京工业大学软件工程研究所研制开发的“软件再工程辅助调查工具——SFRE”正是从整体上支持该分析阶段的再工程自动化工具。重用是软件工程经济学最重要原则之一，重用得越多，再工程成本越低，所以逆向工程再分析阶段最重要的目的是寻找可重用的对象和重用策略，最终确定的再工程任务和工作量也将依存于可重用对象范围(重用率)和重用策略。 <br /><br />与一次工程不同，再工程分析者最终提出的重用范围和重用策略将成为决定再工程成败以及再工程产品系统可维护性高低的关键因素。如果重用对象都是既存代码级的当然理想，然而可能性有限。但是再工程分析者如果因此而放弃重用，以为“改他人的代码不如自己重新编写”，便犯了再工程的大忌。因为一个运行良久的既存系统，最起码的价值是在操作方法和正确性上已被用户接受。而再高明的程序员在软件没有经过用户一段时间的使用验证之前都不敢保证自己的程序正确无误;更何况越是有经验的程序员越是知道对一个处于局部变更地位的程序进行重新编写远比一次工程的原始编程复杂得多，因为他需要对应无数的“副作用”，正所谓“碰一筋而动全身”。所以，读文档——即使是“破烂不堪”、读代码——即使是“千疮百孔”，也要坚持住，并且从中筛出可重用对象。 <br /><br />再编码　根据再分析阶段做成的再工程设计书，再编码过程将在系统整体再分析基础上对代码做进一步分析。如果说再分析阶段产品是再工程的基本设计书，那么再编码阶段如同一次工程一样，先要产生的是类似详细设计书的编码设计书。但是再工程比一次工程更难以进行过程分割，换言之，瀑布模型更不适应再工程，无法将再分析、再设计、再编码截然分开。 <br /><br />再测试　一般来说，再测试是再工程过程中工作量最大的一项工作。如果能够重用原有的测试用例及运行结果，将能大大降低再工程成本。对于重用的部分，特别是可重用的（独立性较强的）局部系统，还可以免除测试，这也正是重用技术被再工程高度评价的关键原因之一。当然再工程后的系统总有变动和增加的部分，对受其影响的整个范围都要毫无遗漏地进行测试，不可心存侥幸，以免因“一个苍蝇坏了百年老汤”。 <br /><br />实用的重用战略 <br /><br />在判断既存系统应该如何重用时，首先要明确哪些是可重用对象，以及如何使用这些可重用对象。下面以既存LAN系统重构成Web系统的再工程为例，说明再分析和再编码将遇到的一些重用课题。 <br /><br />我们可以将既存LAN系统划分成界面、逻辑、数据三个层次。用既存系统的三个层次去分别对应典型Web系统的表示层、逻辑层和数据层。由此从逻辑上得到对应每个层次的输入和输出，然后为每一层寻找能够实现最大程度重用的重构方法。 <br /><br />● 界面重用策略 <br /><br />界面模拟方法　将基于文本的旧界面包装为新的图形界面。旧界面运行在终端上，新界面可以是基于PC的图形界面，也可以是运行在浏览器上的HTML页面。新用户界面通过一个界面模拟工具与旧界面通信。此方法重用率相当高。但是不修改既存系统会同时将旧系统的结构性缺点全部继承下来。 <br /><br />基于客户端的Web应用（Java Applet）　Applet可以实现从界面、逻辑到数据库的许多功能。完全用Java语言重写一个系统是不现实的，重用率也不会很高，这不是软件再工程所提倡的。但目前已有许多Applet自动转化工具，而且其转化后代码的重用率相当高。 <br /><br />基于服务器端的Web应用　即重新开发界面。这种方法看上去没有重用既存界面代码，其实不然。首先，界面设计完全可以重用，从而节省设计时间；其次，我们可以将某些界面做成可重用的，这样也会减少工作量。 <br /><br />● 逻辑层包装原则 <br /><br />通过对逻辑层的分解可以得到可重用和不可重用的两部分代码。对可重用部分可直接使用，对于不可重用部分则应尽量通过各种包装技术按统一标准将其改造成可重用构件。包装方法有很多，如对象包装法、部件包装法等。 <br /><br />● 数据层重用策略 <br /><br />数据层通常要求更高的重用率。逻辑和数据休戚相关，如果改动数据库，逻辑势必不能正常运行，对逻辑部分的重用也就无从谈起。如果非改不可的话，也要以保证最大限度的重用为原则，争取做到只增不删，以保证数据的完整性。 <br /><br />制度保证软件重用  <br /><br />和软件开发是团队的事业一样，软件重用不是个人行为。一个组织如何系统化地实现软件重用呢？答案是软件重用制度化，其内容包括： <br /><br />（1）管理层支持　软件重用初期投资较大，盈利周期较长，没有管理层的明智决策寸步难行。 <br /><br />（2）软件开发过程改革　传统软件开发方法在高速、高效、高质的软件开发市场需求面前越来越显得无力。尽快摆脱传统思路束缚，建立起全新的基于重用的软件开发过程是软件企业亟待解决的问题。 <br /><br />（3）克服非技术因素　非技术因素主要指人的因素。许多程序员长期在传统软件开发方法下工作，逐渐形成了一套自成一体的开发习惯，让他们摒弃老方法，必然会产生抵触心理。实现软件重用制度化，必须让开发人员都能对软件重用有深刻理解，都能成为重用制度的自觉执行者。 <br /><br />（4） 对可重用软件的奖励　使用可重用软件，可以减少工作量、降低成本、保证质量、提高系统价值水平。要鼓励大家从事可重用性开发，对于重用程度高的软件应给予奖励。 <br /><br />（5）软件重用定量化标准的确立　软件开发费用、开发规模、产品质量等都与软件重用定量化标准有关。可以用重用率、沉积率、重用力度等指标定量化表示软件重用。其中重用率用可重用代码占总代码比例或可重用对象占整个系统对象的比例来计算；沉积率指重用对象占开发出的总对象的比例；重用力度指重用对象被使用的次数。有了软件重用定量化标准，我们才能对工程进行合理的评估，奖励制度才有依据。 <br /><br />（6）软件重用的自动化　软件重用制度化的终极目标就是提高软件生产率。软件重用自动化不仅指自动实现对可重用构件的提取，还能自动实现对可重用构件的管理和维护。 <br /><br /><img src='http://www2.ccw.com.cn/02/0244/b/pic/b01_3t1.jpg' border='0' alt='user posted image' />