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