现在的位置: 首页 > 综合 > 正文

如何在类图中标注设计模式(一)

2012年09月24日 ⁄ 综合 ⁄ 共 2540字 ⁄ 字号 评论关闭

       随着设计模式的广泛使用,如何在结构图(主要是UML类图)中标注设计模式成为大家讨论的一个热点话题。设计模式是软件设计中的一些微结构,通过一种合理的方法来标注设计模式既有助于开发人员更好地进行设计软件系统,也有利于理解一些遗留系统,具体来说,设计模式的标注具有以下意义:
      (1) 在系统设计和实现阶段,如果能够通过一种简单易懂的方式来标注相应的模式角色,将有助于开发人员开发和设计软件时记录所采用的解决方案,便于及时修改和完善设计方案,也有助于更好地理解和修改源代码;
      (2) 在系统维护阶段,由于软件文档的缺失或核心开发人员的离职等原因将导致遗留系统的代码阅读和维护任务非常艰巨,一个复杂的系统往往包含成百上千个文件,这些文件之间的关系错综复杂,很难在较短的时间内理解它们之间的关系,明确设计人员的设计思想和意图,如果能够在设计文档和源代码中对软件中所使用设计模式进行标注,无疑会大大简化对系统的理解难度。

      UML只能以可视化的方式描述系统的组成元素以及它们之间的关系,并不能揭示其中蕴含的设计模式相关信息。如图1所示的某图表显示系统设计结构图,在该结构图中使用了两个设计模式,分别是桥接模式(Bridge Pattern)适配器模式(Adapter Pattern),其中抽象图表类Chart充当桥接模式中的抽象类(Abstraction)角色,饼状图类PieChart和柱状图类BarChart充当扩充抽象类(RefinedAbstraction)角色,数据读取接口DataReader充当实现类接口(Implementor)角色,数据库读取类DBReader和Excel读取类ExcelReader充当具体实现类(ConcreteImplementor)角色;同时,由于ExcelReader重用了现有类ExcelAPI,因此在设计方案中又使用了适配器模式,DataReader充当适配器模式中的目标抽象类(Target)角色,ExcelReader充当适配器(Adapter)角色,ExcelAPI充当被适配的适配者(Adaptee)角色。如果没有相应的文字说明和丰富的设计模式使用经验,从图1中要准确而又快速地识别出其中使用的模式和每一个模式角色的难度较大。因此,对于系统的设计人员、实现人员和维护人员而言,如何在软件设计方案中标注设计模式意义重大

      近年来,陆续诞生了一些设计模式标注方法,各具特色,也都存在一些问题和不足,下面我对这些标注方法做一个简单的介绍:

      1. 维恩图风格模式标注  

      维恩图风格模式标注(Venn Diagram-Style Pattern Annotation)是最早的设计模式标注方法之一,它由设计模式先驱John Vlissides提出,其表示方式如图2所示。在图2中,通过实线框和不同的阴影颜色来区分不同的设计模式,这种标注方式简单易懂,但存在很多问题,例如当一个类在多个设计模式中都扮演相应的角色时,将导致实线框的多次重叠,影响结构图的可读性;此外使用不同的阴影颜色来代表不同的模式也将导致颜色的多层重叠和文档打印的不便;这种方式还有一个缺点是只能标注使用了哪些设计模式,而不能对其中的模式元素进行标注,不能标注类模式角色、方法、属性等重要信息。

    个人观点:该方法简单,但是模式太多就会很乱!

     

      2. 虚线边界模式标注

      虚线边界模式标注(Dotted Bounding Pattern Annotation)方法由德克萨斯大学达拉斯分校的Jing Dong等提出,如图3所示。这种方法通过虚线框来解决维恩图风格模式标注方法中存在的阴影重叠问题,但是对于标注信息太过简单、模式重叠区域线段较多等问题仍然无法解决。

     个人观点:该方法也比较简单,但模式太多还是会很乱!

      

      3. UML协作标注

      UML协作标注(UML Collaboration Notation)方法最早由UML创始人Grady Booch等提出,最开始是用于对通用UML图形中的一些元素进行描述,John Vlissides将其引入设计模式标注,在这种标注方式中,将所使用的设计模式名称放在虚线椭圆符中,再通过虚线指向具体的模型元素,在虚线上注明该模型元素对应的模式角色名,如图4所示。但是在这种标注方式中,大量虚线的使用将让整个结构图变得非常凌乱,同时由于模式信息和类结构信息混合在一起,导致这两类信息都难以理解和识别,此外,这种方法虽然可以标注每一个类所扮演的模式角色信息,但是不能标注属性、方法等模式信息。

    个人观点:模式不多时还不错,清晰明了,但模式较多时会很乱,线太多了!

       

      4.  “模式:角色”标注

     “模式:角色”标注(Pattern : Role Annotations)方法由设计模式先驱Eric Gamma等提出,该方法通过阴影框来标注模式名称和模式角色名称,为了节省篇幅,如果某个元素只在一个模式中充当某个角色,则可省略模式名,直接用“模式角色名”的方式来标注角色,如图5所示。这种模式标注方式直观易懂,但是在复杂结构中,“模式:角色”标注方法将会导致结构图变得非常复杂,每一个与模式相关的类都需要对应增加一个阴影框,导致结构图中充斥太多图形元素,N个类可能需要2N个阴影框,而且阴影框的位置也很重要,不合适的位置将导致结构图非常拥挤;此外,该方法也没有考虑到方法和属性等细节信息的标注;同时,如果某一个类在同一模式的多个实例中都扮演了某个角色,该方法不能明确标识出不同模式实例中的不同角色。

个人观点:元素太多,布局太麻烦,如果类图太复杂该方法不合适,在Joshua Kerievsky的《重构与模式》一书中,很多图就是用这种方式来标注的(注:图都不是很复杂)!

小结:以上几个标注图(初始类图用PowerDesigner绘制)都是我用Visio一个个画的,很费时间,如果结构图较为复杂,我个人觉得这些标注方式都不太好!下一篇文章将介绍一些更好的标注方式,敬请关注!微笑

【作者:刘伟  http://blog.csdn.net/lovelion

抱歉!评论已关闭.