（计算机软件与理论专业论文）设计模式检测工具的设计与实现.pdf

摘要 软件程序当中。遗产软件( 1 e g a c ys o f t w a r e ) 的问题是比较突出的一个。由于遗产 软件经常存在文档不齐以及结构不清晰的问题，软件结构很难理解。p a t t e r ne x p l o r e r 就是为了解决这一问题才提出的。在后来的研究过程中，发现p a t t e r ne x p l o r e r 不仅 对分析理解遗产程序有帮助，对于逆向工程以及软件验证一样会起很大的作用。 本课题的目标是研究如何从已经存在的u m l 图中，发现软件的设计模式。我们在文 中首先提出现在同类研究存在的一系列问题，并针对这些问题，提出了一种新的解决方 案。然后，根据这种新的解决方案，提出了一系列的算法和数据结构，并在理论和算法 上证明了该方法是可行的。最后。设计并实现了一个具体的工具“p a t t e r ne x p l o r e r ” 来验证我们的理论。经过验证，表明了该方法在理论上和实践中都是切实可行且卓有成 效的。 本论文分为五部分。第一部分先简单得介绍相关的背景知识、研究意义、研究目标、 研究内容和研究方法。第二部分将会介绍u m l 和设计模式的理论基础。第三部分介绍了 本毕业设计的开发平台，以及p a t t e r ne x p l o r e r 的总体设计，工作原理，m v c 三层层次 结构和各个模块的组成和功能。第四部分详细介绍我们实现的工具p a t t e r ne x p l o r e r 的详细设计。在介绍p a t t e r ne x p l o r e r 中，将分为其外在表现形式和内部算法、理论 分开来讲。第五部分则给出了两个具体的应用实例来验证p a t t e r ne x p l o r e r 的正确性 和实用性。 关键词设计模式：u m l ；检测：分析 华南理工大学硕士学位论文 a b s t r a c t l e g a c ys o f t w a r ei s s u ei sr e l a t i v e l ys e v e r ea m o n ga 1 1s o f t w a r ep r o b l e m s t h i s i sm a i n l yb e c a u s eo ft h ed e f i c i e n c yo fd o c u m e n t a t i o n w h i c hm a k e si t v e r y d i f f i c u l tt ou n d e r s t a n ds o f t w a r ea r c h i t e c t u r e p a t t e r ne x p l o r e ri sp r o p o s e df o r t h i sc i r c u m s t a n c e i nt h ef o l l o w i n gr e s e a r c h e s ，i ti sf o u n dt h a tp a t t e r n e x p l o r e r i sn o to n l yu s e f u lf o ru n d e r s t a n d i n gl e g a c ys o f t w a r e ，b u ta l s os i g n i f i c a n tt o r e v e r s i n ge n g i n e e r i n ga n ds o f t w a r ev e r i f i c a t i o n t h et a s ko ft h i st h e s i si st od e t e c tg o fd e s i g np a t t e r n sf r o me x i s t e du m l d i a g r a m f i r s ts o m ep r o b l e m sa m o n gc u r r e n ts i m i l a rr e s e a r c h e sw e r ep r e s e n t e d t oa d d r e s st h e s ep r o b l e m s ，an e ws o l u t i o ni sp r o p o s e db yu s t h e n ，as e to f a l g o r i t h m sa n dd a t as t r u c t u r e sb a s e do nt h i ss o l u t i o na r ep r e s e n t e dt op r o v e t h a tt h i sm e t h o di sf e a s i b l ea n dp r a c t i c a li nt h e o r ya n da l g o r i t h m a tl a s t ， at o o ln a m e d “p a t t e r ne x p l o r e r ”i sd e s i g n e da n di m p l e m e n t e dt op r o v et h e s o l u t i o n 。t h er e s u l ts h o w st ou st h a tt h i ss o l u t i o ni sf e a s i b l ea n de f f e c t i v e t h i s t h e s i sc o m p r i s e s5s e c t i o n s i nt h ef i r s ts e c t i o nw ei n t r o d u c e s o m e b a c k g r o u n dk n o w l e d g e ，t h ec o n t e n t a n dm e t h o d o l o g yo fo u rr e s e a r c h i nt h es e c o n d s e c t i o nw ed e s c r i b et h eb a s i ck n o w l e d g ew i t hr e s p e c tt ou 札a n dd e s i g np a t t e r n s ， i nt h et h i r ds e c t i o nt h ed e v e l o p m e n te n v i r o n m e n t ，d e v e i o p m e n tt o o l s ，w o r k i n g t h e o r y ，a n dt h em v c3l a y e r ss t r u c t u r ea r ei n t r o d u c e d i nt h ef o u r t hs e c t i o n ， w ei n t r o d u c eo u rt o o l “p a t t e r ne x p l o r e r ”i nd e t a i l w ew i l ld i s c u s st h e “p a t t e r ne x p l o r e r ”i nt w oa s p e c t s ：t h eg r a p h i cu s e ri n t e r f a c ea n dt h ei n n e r a l g o r i t h m i nt h ef i f t hs e c t i o ns o m ec o n c r e t ec a s e sw i l lb ep r o p o s e dt op r o v e t h ec o r r e c t n e s sa n dp r a c t i c a l i t yo f “p a t t e r ne x p l o r e r ” k e y n o r dd e s i g np a t t e r n ：u m l ：d e t e c t i n g i i 华南理工大学 学位论文原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行 研究所取得的研究成果。除了文中特别加以标注引用的内容外，本 论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本 文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。 本人完全意识到本声明的法律后果由本人承担。 作者签名：固i 专售 日期：伽降月。日 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定， 同意学校保留并向国家有关部门或机构送交论文的复印件和电子 版，允许论文被查阅和借阅。本人授权华南理工大学可以将本学位 论文的全部或部分内容编入有关数据库进行检索，可以采用影印、 缩印或扫描等复制手段保存和汇编本学位论文。 保密口，在一年解密后适用本授权书。 本学位论文属于 不保密口。 ( 请在以上相应方框内打“4 ”) 日期：协年石月卢日 日期：0 ”牟年占月，o 日 瞄黼 闭新 名名签签者师作导 第一章绪论 1 1 本课题的学术背景 1 1 1 问题的提出 第一章绪论 人们总是希望在更高的抽象层上把握软件，例如：给出程序代码，希望由编译程序 和链接程序自动生成机器码；给出b m l 设计图，希望正向工程来自动生成程序代码：给 出软件的体系结构( s o f t w a r ea r c h i t e c t u r e ) u 1 ，希望自动生u m l 设计图，继而自动生 成代码。但是，这个过程需要人们对计算机认识的不断加深以及严格的形式化方法才能 完成。由程序代码生成二进制机器码在几十年前已经完成了，而从u m l 设计图通过正向 工程生成程序语言是于前几年完成了，这个过程经历了几十年。之所以从上一抽象级自 动生成下一抽象级越来越难，是因为越要站在宏观的角度上上把握细节，就需要对越多 的环境变量( i n v a r i a n t ) ，先决条件( p r e c o n d i t i o n ) ，后置条件( p o s t c o n d i t i o n ) 以及 操作( o p e r a t i o n ) 定义。 所以，现在在设计模式层和删l 层之间做正向和逆向工程的工作是当前设计模式这 一领域的重点。本毕业设计正是在这个基础上，利用设置约束条件方法来解决软件设计 层次上u m l 图检测( d e t e c t i n g ) 的问题。 目前，c a s e 工具和软件开发工具中，在删l 级与程序语言级，以及程序语言级与机 器码级都有比较成熟的技术来支持软件的自动化生成( 如u m l 的正向工程) 和软件的测 试( 如集成在各个开发工具中的语法检查和词法检查工具) 。而在从设计模式到u m l 层 之间，却还没有好的工具来支持设计的自动生成和设计的检测，目前主要是靠软件设计 人员依靠自己的软件设计知识来生成软件设计图。至于对软件设计图的检测，根本无从 谈起。因此，一些基础的理论工作现在已经展开，具体的说就是设计模式的形式化工作， ( 详见1 1 3 节) 。此外，基于这些理论基础，一些尝试性的工具也出现了( 详见1 2 2 节) 。 1 1 2 设计模式的基本思想 所谓模式( p a t t e r n ) ，就是在特定场合( c o n t e x t ) 下，对特定问题( p r o b l e m ) 的 惯用解决方案( s o l u t i o n ) 。在软件开发过程中，经常在某特定场合中遇到某些以前 经常出现或感觉似曾相识的问题，直截了当地解决方案就是套用原有的已经过证明的解 华南理工大学硕士学位论文 决方案，或参考别人成熟的思路来解决，久而久之，通过不断完善并文档化就形成了针 对这种问题的模式。通过这种方式，便将专家头脑中的经验和技巧固化下来，就可以一 次又一次地使用已有的解决方案，无需再重复相同的工作。根据软件开发过程，模式又 可分为分析模式和设计模式等，设计模式是当前面向对象领域研究的热点。 1 9 9 5 年，g a m m a 等人提出了g o f 设计模式，他们把现实中存在的软件设计模式以文 字，图片，表格的形式整理出来，很容易被人理解接受。这实际是软件结构的设计知识 的非形式表示。 但是，这种非形式的表示方法有很大的局限性。 ( 一) 首先，如文献 2 所说的那样，非形式化的表示方法是以一种自然语言的形式表示 的，这样就会导致二义性和不准确。 ( 二) 其次，用非形式化的表示方法来表示设计模式，会导致设计模式的误用。 ( 三) 最重要的是，非形式化的设计模式表示方法不能应用于c a s e 工具中，指导软件的 设计和检测。 因此，学术界产生了各种形式化的方法来表示设计模式。这些形式化的方法也是本 论文的理论基础。 1 1 3 设计模式的形式化表示 软件工程是系统工程( s y s t e me n g i n e e r i n g ) 的一个分支。相比于系统工程中的其它 领域来说，最大的特点就是它的不成熟性，难以把握性。而且根源是因为它是随着软件 产业的发展而发展起来的一门新兴学科，人们对其属性还不了解，难以把握软件工程的 规律。针对这一问题，现在软件工程的研究方法论( m e t h o d o l o g y ) 主要分为两种，一种 是基于经验的非正式的方法；另一种是基于数学推导的形式化方法( f o r m a lm e t h o d s ) 。 目前用于形式化方法的主要工具就是形式化说明语言( f o r m a ls p e c i f i c a t i o n l a n g u a g e s ) ， 比如说z 。，c s p “”，l a r c h ”1 和、巾m f b 】。 现在比较成熟的用于描述设计模式的形式化方法主要有以下几种：c o n t r a c t s ”， d i s c d ，c o n s t r a i n td i a g r a mn o t a t i o n tu l ，c d l n 1 以及e l e p u se m 。本文将在第二章中详 细介绍这几种方法的优缺点，并基于本课题实际的需要在这些方法中加以改进，以产生 出一个基于x m l 的半形式化方法，可以被p a t t e r ne x p l o r e r 直接使用。 2 1 2 设计模式工具的研究近况 1 2 1 国内研究近况 经过多方查找资料，国内仅发现一片介绍性的论文有少量关联m ，。在论文和工具设 计上国内目前为止尚没有任何研究说明。 1 2 2 国际研究近况 该方面研究的主要理论基础就是设计模式的形式化表示，这方面的国际研究情况已 经在前面1 1 3 节介绍了。至于具体的工具，有： ( 一) r o s e2 0 0 3 “唑已经内置了g o f 2 3 个设计模式中的2 0 个模式实例化生成。 ( 二) 德国h a g e n 大学有专门的研究组构造基于设计模式的设计工具 t 。l i l 7 ，他们的基本思 想是建立一个设计模式的元模型( m e t a m o d e l ) ，并由此派生出一个智能的模式库 ( i n t e l l i g e n tp a t t e r nr e p o s i t o r y ) 。值得指出的是该工具是针对于 g i s ( g e o g r a p h i ci n f o r m a t i o ns y s t e m ) 专用的工具，缺乏通用性。 ( 三) g u 6 h 6 n e u c 和a r a i o t 建造了一个基于设计模式和约束条件( c o n s t r a i n t s ) 的类之 间的c a s e 工具“”，用于检测设计上的缺陷。这篇论文对本课题有指导的意义。 1 3 课题来源和研究内容 本课题是广州市科委重点攻关项目“企业信息系统集成开发平台的研究”的主一个 子课题。作为该项目中的一个分支内容，我重点对如何从已经存在的u m l 类图中发现g o f 设计模式做了相应的研究。 本课题主要是通过以现有的设计模式的半形式化方法为理论指导，对g o f t m 设计模 式进行约束表示，使其成为可以被本工具使用的形式。 本课题首先通过对现有的设计模式的形式化方法进行一定的修改，用一系列约束条 件来对设计模式进行定义。然后从u m l 类图中查找与该定义类似的软件微结构，并把查 找结果显示给用户。 3 华南理工大学硕士学位论文 1 4 课题研究意义及目标 本课题的研究意义在于可以在更高的抽象层次上把握软件，可以应用到基于模式的 软件维护，开发，设计，恢复等各个方面。例如可以应用于基于设计模式的软件设计 和检测。基于设计模式的软件恢复( r e c o v e r y ) 恤，基于设计模式的推理( r e a s o n i n g ) “” 等等。 本课题希望达到的目标是能够最终实现可以设计模式匹配( m a t c h i n g ) 和检测 ( d e t e c t i n g ) 的c a s e 工具“p a t t e r ne x p l o r e r ” ( p e ) ，与r a t i o n a lr o s e2 0 0 3 结合 起来用于辅助软件的设计。如图卜l 所示： p a t t e r ne x p l o r e r 图卜1p a t t e r ne x p l o r e r 工作示意图 f i g l l i l l u s t r a t i o nf o rp a t t e r ne x p l o r e r p a t t e r ne x p l o r e r 从r o s e2 0 0 3 的u m l 文件水m d l 中读取u m l 设计图，经过与内部 的设计模式形式化规则做比较匹配后，把结果输出到用户界面中。结果主要是分析出u m l 图中包含的设计模式的种类，个数，以及判断该设计是不是符合设计模式的规则。具体 的开发环境请见第三章，具体的实现方法参见第四章。 1 5 论文结构 本论文分为五部分。 第一章先简单得介绍相关的背景知识、研究意义、研究目标、研究内容和研究方法。 第二章将会介绍u m l 和设计模式的理论基础。 第三章介绍了本毕业设计的开发平台，以及p a t t e r ne x p l o r e r 的总体设计、工作原 4 第一章绪论 理、m v c 三层层次结构和各个模块的组成和功能。 第四章详细介绍我们实现的工具p a t t e r ne x p l o r e r 。在介绍p a t t e r ne x p l o r e r 中， 将分为其外在表现形式和内部算法、理论分开来讲。 第五章则给出了两个具体的应用实例来验证p a t t e r ne x p l o r e r 的正确性和实用性。 5 华南理工大学硕士学位论文 i | 1 1 1 1 _ - - - - - - _ l _ _ - l l - l _ _ _ l - - l - - - _ _ _ l _ l _ _ _ _ _ _ _ _ l - - _ _ _ l _ _ _ _ l - - _ l i l l 目_ l _ _ - _ _ _ _ _ - _ 2 1t i n _ 简介 第二章u m l 和设计模式的理论基础 统一建模语言u m l 是o m g ( o b j e c tm a n a g e m e n tg r o u p ) 在1 9 9 7 年发表的图标式软件 设计语言，它综合了很多种当时已经存在的面向对象的建模语言、方法和过程。 u m l 包括以下的图： u s ec a s ed i a g r a m s 类图( c l a s sd i a g r a m s ) 对象图( o b j e c td i a g r a m s ) 序列图( s e q u e n c ed i a g r a m s ) 合作图( c o l l a b o r a t i o nd i a g r a m s ) 状态图( s t a t e c h a r td i a g r a m s ) 活动图( a c t i v i t yd i a g r a m s ) 构件图( c o m p o n e n td i a g r a m s ) 部署图( d e p l o y m e n td i a g r a m s ) 在所有的这些图里面，u s ec a s e 图、类图和序列图这三种类图对我们的设计是最为 有用的。 根据这些图的用意，可以讲它们大体上划分为结构图和行为图两种。结构图描述了 系统的静态结构，在描述一个系统已有的类以及它们之间的静态关系时最为有用。行为 图描述了一个系统的动态性质，在显示系统的元素如何协作产生满足要求的系统行为方 面最为有用。 ( 1 )结构图 如下表所示，其中给出了所有的u m l 结构图。当然，在所有的结构图里，类图是最 为常用的。 表2 - 1u m l 的结构图 t a b l e2 - 1s t r u c t u r ed i a g r a m si nu m l 图的名字介绍 类图类图描述一些类、包的静态结构和它们之间的静态关系 对象图对象图给出了一个系统种的对象的快照 6 第二章u m l 和设计模式的理论基础 构件图 描述可以部署的软件构件( 比如j a r 文件，e j b 等) 之间的静态关系 部署图描述一个系统的拓扑结构 显然，要描述一个设计模式的静态结构，使用类图和对象图是很合适的。这也正是 我们下面的工作的重点。 ( 2 )行为图 如下表所示，其中给出了所有的u m l 行为图。当然，在所有的行为图里，u s ec a s e 图和时序图是最为常用的。 表2 - 2u m l 的行为图 t a b l e2 - 1b e h a v i o u rd i a g r a m si nu m l 图的名字介绍 u s ec a s e 图u s ec a s e 图描述一系列的角色和使用案例及它们之间的关系。可以用 来对一个系统的最基本的行为进行建模 活动图描述不同过程之间的动态接触。活动图是使用案例图所描述的行为的具 体化 状态图描述一系列对象的内部状态及状态的变化和转移。注意一个类不能有两 个不同的状态图 时序图时序图是一种相互作用图，描述不同对象之间信息传递的时序 合作图合作图是一种相互作用图，描述发出信息、接收信息的一系列对象的组 织结构 显然，要描述一个设计模式的行为特性，使用状态图和时序图就很合适。 只要有意义，所有类型的u m l 图都是可以混合在一起使用的。比如，一个对象图可以与 一个类图同时出现在个结构图中，一个构件图中可以有类图出现等( 有的时候，一些 u m l 建模工具软件不定允许这样做) 。 应当指出的是：一个使用u m l 的系统设计，往往是从u s ec a s e 图开始的，而且一个 设计应当是以使用案例驱动的( u s ec a s e d r i v e n ) 。 在下面，本文仅就设计模式所涉及的类图、状态图和序列图做简单的介绍。 ( 3 )类图 类图是显示类，接口以及它们之间的静态结构和关系的图。类图最基本的元素是类 ( 包括抽象类) 和接口。 7 华南理工大学硕士学位论文 表示类的框分成一下几层： 类名 属性清单 方法清单 性质清单 如果一个类有内部成员类，它的类图就会有五层。在类图中，除了类名是不能省略、 必须显示的以外，其他4 层都是可以省略的。 第一层是类名。类名如果是正体，表明类是具体的( c o n c r e t e ) ；如果是斜体字，则 表明类是抽象的( a b s t r a c t ) 。 第二层是属性层。一个属性可以是p u b l i c 、p r i v a t e 或p r o t e c t e d 。一个属性的左 面如果有一个+ 号，表示它是p u b l i c ；如果有一个一号，表示它是p r l v a t e ：如果是一 个# 号，表示它是p r o t e c t e d 。 第三层是方法层。一个方法可以是p u b l i c 、p r i v a t e 或p r o t e c t e d 。一个方法的左 面如果有一个+ 号，表示它是p u b l i c ；如果有一个一号，表示它是p r i v a t e ；如果是一 个# 号，表示它是p r o t e c t e d 。 如果一个方法的下面有一道下划线，表明该方法是一个静态方法。 第四层是性质层。性质层是由一个属性即由一个内部变量，一个赋值函数和一个取 值函数组成的结构。 ( 4 )泛化关系 在类与类之间，会有连线指明它们之间的关系。类和类、类和接口、接口和接口之 间可以建立以下几种关系：一般化关系、关联关系、聚合关系、合成关系和依赖关系。 值得指出的是：这几种关系都是静态的。 泛化关系( g e n e r a l i z a t i o n ) 表示类与类之间的继承关系，接口与接口之间的继承关系， 或类对接口的实现关系。般化的关系是从子类指向父类的，或从实现接口的类指向被 实现的接口，与继承或实现的方向相反，如下图所示： 图2 - 1 泛化关系 f i g2 - 1g e n e r a l i z a t i o nr e l a t i o n s h i p 8 第二章删l 和设计模式的理论基础 ( 5 )关联关系 关联关系( a s s o c i a t i o n ) 是类与类之间的联接，他使一个类知道另一个类的属性和 方法。关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头。 如下图所示： r r 1 l 鱼塑墨坠l 一曼堕塑曼l e 二二二二 亡二二二二 图2 2 关联关系 f i g2 - 2a s s o c i a t i o nr e l a t i o n s h i p ( 6 )聚合关系 聚合关系( a g g r e g a t i o n ) 是关联关系的一种，是强的关联关系。聚合是整体和个体 之间的关系。其在u m l 中的表示如下图所示： l 鱼堕塑垒u 璺垦塑璺l e 二二二二 e 二= 二爿 图2 3 聚合关系 f i g2 - 3a g g r e g a t i o nr e l a t i o n s h i p ( 7 )合成关系 合成关系( c o m p o s i t i o n ) 是关联关系的一种，是比聚合关系还要强的关系。应用合成 关系时，需要注意以下两点： l _ 它要求聚合关系中代表整体的对象负责代表部分的对象的生命周期 2 合成关系时不能共享的。 ( 8 )依赖关系 依赖关系( d e p e n d e n c y ) 也是类与类之间的连接，依赖总是单向的。依赖关系表示 个类依赖于另一个类的定义。当满足下列3 个条件之一时，即是依赖关系： 1 一个类a 的某个局域变量的类型是另一个类b ，那么类a 就依赖于类b 2 如果一个方法的变量是另一个类b 的实例，那么这么方法所在的类a 就依赖于类 b 。 3 如果一个类a 调用了另一个类b 的静态方法，那么类a 依赖于类b 。 r 1r 幽一斗竺型 图2 - 4 依赖关系 f i g2 - 4d e p e n d e n c yr e l a ti o n s h i p 9 华南理工大学硕士学位论文 ( 9 )时序圈 时序图又叫序列图、活动序列图。作为交互图的一种，序列交互图按照时间顺序从 上往下显示每个使用案例。在一个时序图中，垂直的虚线叫做生命线，它代表一个对象 存在的时间。每一个箭头都是一个调用，这个箭头从调用者对象连接到接受者对象的生 命线上的激活条( a c t i v a t i o nb a r ) 上。每一个激活条代表调用所持续的时间。更深入 的内容请参阅相关著作。 ( 1 0 ) 状态图 状态图又称作状态转换图( s t a t et r a n s i t i o nd i a g r a m ) 。状态图的基本想法是定义 一个具有有限个内部状态的机器，因此状态图又称作有限状态机。对象被外界的时间激 发，从而从一个状态转换到另一个状态。更深入的内容请参阅相关著作。 设计模式从人工智能( a i ) 的角度可以被看作为软件工程中知识表示的雏形。设计模式 的语义描述一直是研究的重点，它既要求面向计算机，尽可能的形式化，严格化，又要 求面向人，易于交流和理解。这两种在实际中近乎矛盾的要求需要折中考虑，单纯强调 前者和单纯强调后者都是片面的。 2 2 设计模式简介 在面向对象的程序设计中使用模式化方法研究的开创性著作是文献 。这本书发表于1 9 9 5 年，而模式理论被引进到软件设计界的历史要稍早一些。 所谓模式，用最简练的术语概括，就是在特定场合下( c o n t e x t ) ，对特定问题 ( p r o b l e m ) 的惯用解决方案( s o l u t i o n ) 。在软件开发过程中，经常在某一特定场合中 遇到某些以前经常出现或感觉似曾相识的问题，直接了当地解决方案就是套用原有地已 经过证明的解决方案，或参考别人成熟的思路来解决，久而久之，通过不断完善并文档 化就形成了针对这种问题的模式。 2 3 设计模式语义描述的现状分析 当前典型的模式描述形式主要分为两类：即自然语言( n a t u r a ll a n g u a g e ) 结合0 0 框图的非形式化描述方法和形式化的描述方法，前者以a l e x a n d e r f o r m ，g o ff o r m ，p o s a f o r m 为代表，这三者非常类似，区别仅在于理解的角度和划分的粒度，其主要缺点是： 忽略了模式描述内部各部分间丰富的语义联系，文本和0 0 框图只是松散地，随意地结 合在一起，相互之间没有紧密的结构化语义关联；自然语言成分带来的歧异性，使问题 域的描述可能误导重用者；设计模式知识只能通过人阅读来接受，理解，在通过人这一 1 0 第二章删l 和设计模式的理论基础 中问环节在计算机中加以体现。这些问题使得描述基本是面向人而不是面向计算机和 c a s e 环境，这些显然严重制约了设计模式的进一步发展和它在软件工程中的作用。形式 化描述主要以c o n t r a c t s ，d i s c o 。1 ，c o n s t r a i n td i a g r a mn o t a t i o n 嘲，c d l 以及 e l e p u s 。1 为代表，其主要缺点是：回避了对问题的描述，而着重描述解的部分。 设计模式的表示分三个层次：模式内部各部分的表示，模式各部分之间语义联系的 表示以及模式系统中模式之间联系的表示。 ( 1 ) 对于模式内部各部分来说，其主流描述不外乎是自然语言加0 0 框图，其中0 0 框图 目前已经统一到了统一建模语言( 删l ) 。u m l 是对象管理集团( o m g ) 确定的可视化 0 0 建模语言的工业标准，其中统一了b o o t h 、o m t 、o o s e 为代表的经典主流o o 方法 并对o o 模型的语义进行了严格化的定义，突出表现在引入元模型( m e t am o d e l ) 和 对象约束语言( o b j e c tc o n s t r a i n tl a n g u a g e ) ，并进一步引入面向并发、分布、实 时的扩展。 ( 2 ) 模式各部分之间的语义联系在目前一直被忽视，模式描述中各部分之间语义划分不 明确，存在冗余和潜在的不一致性。 2 3 1g o f 方法 g o f 认为一个设计模式有四个基本要素： ( 1 ) 模式名称( p a t t e r nn a m e ) 。这是一个助记名，它用一两个词来描述模式的问题， 解决方案和效果。 ( 2 ) 问题( p r o b l e m ) 。描述了该设计模式所适应的问题域。描述了应该在何时使用模 式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题， 如怎样用对象表示算法等。 ( 3 ) 解决方案( s o l u t i o n ) 。描述了设计的组成部分，它们之间的相互关系及各自的 职责和协作方式。 ( 4 ) 效果( c o n s e q u e n c e ) 。这是一个助记名，它用一两个词来描述模式的问题，解决 方案和效果。 但是，由于g o f 的设计模式小册子只是一个介绍，讲述设计模式的书籍，因此g o f 描述设计模式的方式是一种非正式的方法。它是以一种把文本，b o o c h 方法，以及图标 结合起来的形式来覆盖上面设计模式的四个基本要素的。这种方式的优点是适合初学者 了解、学习设计模式，但是并不适合作为一个设计模式的定义从u m l 图中发现设计模式， 文本和0 0 框图只是松散地，随意地结合在一起，相互之间没有紧密地结构化语义关联； 自然语言成分带来地歧义性，使阿题域的描述可能误导使用者；设计模式知识只能通过 人阅读来接受、理解、再通过人这一中间环节在计算机中加以体现。这些问题使得描述 基本是面向人而不是面向计算机和c a s e 环境，这些显然严重制约了设计模式的进一步 华南理工大学硕士学位论文 发展和它在软件工程汇总的作用。 2 3 2 形式化方法 形式化描述主要以c o n t r a c t ，d i s c o ，c o n s t r a i n t sd i a g r a mn o t a t i o n ，e l e p u s 以 及c d l 方法为代表。其实，形式化方法并不适合用来描述设计模式，这是因为设计模式 是过于抽象，不能用形式化语言来描述设计模式低层的细节。 ( 1 ) c o n t r a c t s 是一个描述语言( s p e c i f i c a t i o nl a n g u a g e ) ，它用来描述行为成分以 及参与对象的职责。c o n t r a c t s 可以明确地、抽象地把握住互操作对象问的行为 依赖。c o n t r a c t s 通过定义类型义务( t y p eo b l i g a t i o n ) ，可以捕获参与者以及 合同义务( c o n t r a c t u a lo b l i g a t i o n s ) ，可以在行为上指定约束条件，可以捕获 对象间的行为依赖。一个c o n t r a c t 还可以在参与者上定义建立合同所必须的 p r e c o n d i t i o n s 以及由这些参与者所维护的常量。通过一个一致性声明 ( c o n f o r m a n c ed e c l a r a t i o n ) 来建立实现和合同间的通信。这个一致性声明指定 了一个具体的类的实现是如何满足一个具体对象的合同义务的。 ( 2 ) d i s c o ( d i s t r i b u t e dc o - o p e r a t i o n ) 是针对反应系统( r e a c t i v es y s t e m s ) 的形 式化描述语言。它把描述语言，开发描述语言的方法以及支持该方法的工具这三 者合为一体。d i s c o 可以在高抽象层上对对象交互( m o d e li n t e r a c t i o n s ) 进行指 定和建模。d i s c o 也可以规定如何描述模式的暂时行为。 ( 3 ) 约束图( c o n s t r a i n td i a g r a m ) 标记通过使用约束图提供了一种获得纯粹可视的， 形式化的模式描述方法。它是一个描述模式的三层模型，并利用u m l 来指定模式 的动态特性。角色模型( r o l e - m o d e l ) 是最抽象的一层，这一层仅描述模式的本 质特性，排除了一些非本质的与应用域有关的具体细节。第二层模型“类型模型 ( t y p e - - m o d e l ) ”通过增加抽象的状态和操作接口提供了一个比角色模型更具体 的精化。最后一层模型是“类模型( c l a s s - - m o d e l ) ”。类模型实现了类型模型， 这样就可以根据具体的类来配置底层的模式。类模型也支持图形化模式说明和文 本补充说明。这些文本补充说明有两个作用：a ) 增强图标的说明作用，b ) 使模 式图表无二义。 ( 4 ) l e p u s ( t h el a n g u a g ef o rp a t t e r nu n i f o r ms p e c i f i c a t i o n ) 。l e p u s 是针对模 式的一个严格的形式化语言。目前，l e p u s 方法增加了一些新的机制来更好的描 述设计模式的结构，称作e l e p u s 。 1 2 第二章u m l 和设计模式的理论基础 利用形式化方法实现设计模式检测的工具是p t i d e j ( p a t t e r nt r a c e si d e n t i f i c a t i o n ， d e t e c t i o n ，a n de n h a n c e m e n ti nj a v a ) 。p t i d e j 是加拿大的教授y a n n - g a lg u 6 h 6 n e u c 用e c l i p s e 做的一个工具。这个工具可以从j a v a 源代码中发现某些g o f 设计模式，如 下图所示。 但是p t i d e j 有2 个缺点。 图2 - 5p t i d e j 用户界面 f i g2 - 5u io fp t i d e j ( 1 ) p t i d e j 只能从j a v a 源码中发现设计模式，不能从其他编程语言的源码中发现设计 模式。 ( 2 ) 只能发现g o f 中一部分的设计模式，而不是g o f 全部2 3 个设计模式。 其中，第一个缺点尤其重大。第二个缺点目前是无法避免的，因为g o f 设计模式中 有不少模式过于抽象，无法用约束条件来确定。 针对第一个缺点，本毕业设计从另一种角度进行了改进增强，即：不再从源码中发 现设计模式，而转而从u m l 类图中发现模式。这样做比起p t i d e j 来有3 个好处： ( 1 ) 仍然可以从源码中发现设计模式。只是需要增加一些手段，比如说先用某些逆向工 程工具把已经存在的源码转化为u m l 类图，然后即可从u 扎类图中发现设计模式。 ( 2 ) 与具体语言无关。不再像p t i d e j 一样仅限于从某种语言的源码中发现设计模式，而 利用逆向工程工具可以从几乎所有的源码中发现设计模式。 ( 3 ) 可以不再依赖于源码，可以直接从u m l 设计图中发现设计模式，这对于正向工程时 1 3 华南理工大学硕士学位论文 早发现设计缺陷具有重大意义。如果用p t i d e j 的方法，那就只能在开发已经完成时 才发现设计缺陷。如果用本文实现的c a s e 工具p a t t e r ne x p l o r e 则可以在设计阶段 发现设计缺陷。 此外，还有一种基于a i 知识表示设计模式的方法。这种方法认为知识层建模 ( k n o w l e d g e l e v e lm o d e l i n g ，简称k l ) 的动机与设计模式具有很多的相似之处，因此 建议用基于a i 知识的方法来表示设计模式。这种方法是非主流的，笔者认为也是短期 内难以实现的，所以这里也就不再介绍了。 但是，形式化方法也有其本身固有的缺点：回避了对问题的描述，而着重描述解的 部分。总之。上面两大类方法要么过于面向人而不够严格，要么过于严格。因此都不能 被本课程设计直接拿来用。为了能在u m l 中发现设计模式，我们需要对设计模式进行定 义，该定义要满足两个条件： 2 3 3 本文提出的x m l 方法 一方面，表示要面向人，易于理解和交流；另一方面，表示还要尽可能严格、形式 化，从而面向计算机。这两个方面对应了模式描述的两种极端方法。极端向上方法仅仅 能在思想的高度上指导软件开发，但不能有效地平滑延伸到软件分析与设计全过程，不 利于面向计算机并集成到c a s e 环境，实现一定程度的自动化；极端向下方法会使设计 模式的抽象层次降低到普通程序设计语言一级，使模式难以与遇到的特定“问题”相匹 配( 因为模式中问题域知识通常具有不确定性) 。 所以，设计模式的表达迫切需要对上述两个冲突的目标进行折衷，既要有一定的严 格性，又有一定的可行性或柔性。而x 札的表示方法正是实现这种折衷的有效方法。这 是用x m l 来描述设计模式有以下优点： ( 1 ) 可以将设计模式与c a s e 环境紧密地集成在一起，为计算机所存储、表示和管理，从 而使设计模式面向计算机，实现一定程度的自动化。 ( 2 ) 可提高设计模式的表达能力，便于设计人员问地传播和交流，从而被广为应用，进 一步发挥它在软件工程中应有的作用。 关于用x m l 方法来表示设计模式的具体细节请参阅本文第四章第2 节“p e 系统的 m o d e l 层”。 1 4 第二章u m l 和设计模式的理论基础 2 4 本章小结 本章主要对u m l 和设计模式的理论基础进行了简单的介绍，并把当前存在的对设计 模式的语义描述方法一一做了分析，指出这些方法各自存在的优点和缺点。本章主要为 本毕业设计奠定了理论基础，提出了改进原有方法的努力方向。 1 1 5 华南理工大学硕士学位论文 第三章p a t t e r ne x p io r e r 的总体设计 3 1 开发平台介绍 3 1 1r a t j o f l q ir o s e 和r e i 简介 有很多工具可以帮助用户画出u m l 图。其中有些是纯粹的绘图工具，另外的一些则 是有代码生成功能的0 0 设计工具。一个好的o o 设计工具甚至可以双向工作，既可以从 代码生成u m l 图，也可以从u m l 图生成代码：根据时序图自动给出合作交互图，或者根 据合作交互图自动给出序列交互视图等。这样的工具包括如下的内容： r a t i o n a lr o s e t o g e t h e r v i s u a lu m l m i c r o s o f tv i s i o m o d e lb r i d