设计模式识别的特征信息分类研究

肖卓宇 何 锫 徐运标 陈 果 郭 杰 王林春

1(湖南工业职业技术学院信息工程学院 湖南 长沙 410208) 2(广州大学计算机科学与教育软件学院 广东 广州 510006)

0 引 言

设计模式是一种可复用的设计经验总结，在软件生命周期的设计阶段担任重要角色[1]，有助于提升面向对象的软件开发质量[2-3]。设计模式识别有助于程序的理解，并为软件系统重构[4]与维护[5]降低成本，减少研发时间[6-7]。由此可见，设计模式识别对遗产系统重构有着积极的意义[8-9]。Zhu等[10]基于符号逻辑，通过谓词表示设计模式，为自动识别设计模式提供了理论基础。Zanoni等[11]提出将设计模式特征以向量的形式进行表示，进而通过机器学习的形式识别设计模式。Chihada等[12]通过学习问题映射设计模式检测，提出了46种特征指标。Fontana等[13-14]提出基于EDP等微结构表示设计模式参与者特征，并进而实现设计模式识别。肖卓宇等在之前工作关注了设计模式变体识[15-16]、设计模式参与者角色间的附加关系[17]、设计模式实例共享问题[18]。文献[19]与文献[20]以图论为基础，通过子图同构，以相似积分来检测设计模式。

综上所述，现有设计模式识别相关工作存在如下主要问题：

(1) 对设计模式特征表示不够完善；

(2) 较少对设计模式按结构型、行为型、创建型进行特征分类研究；

(3) 仅针对Jhotdraw 7、Junit 3.7、Quickuml 2001等基准系统进行了设计模式识别，而较少针对已上线真实系统的识别研究。

为此，本文针对设计模式识别精确性不够理想的问题，以Erich Gamma提出的设计模式分类为原则，基于本文先前工作[21]，提出一种基于特征分类表示的设计模式识别方法，分类归纳了设计模式的特征信息，并以Adapter模式、Command模式、Factory Method模式为例，通过4个经典测试案例进行设计模式识别实验。

本研究主要贡献如下：

(1) 提出依据Erich Gamma设计模式分类对设计模式特征信息进行表示；

(2) 进行了深入的设计模式识别结果研究，发现了影响识别结果精确率的重要原因变体、附加关系，设计模式共享，为后续优化工作奠定了基础；

(3) 提出了基于特征表示的设计模式识别方法。

1 设计模式实例分类研究

先前工作[21]对设计模式进行了识别，并基于设计模式识别工具EA[22]，归纳了47条特征信息，见表1。本文工作将基于该条特征信息按照结构型、行为型与创建型3类进行设计模式分类特征表示，并分别以结构型设计模式对象Adapter、行为型设计模式Command、创建型设计模式Factory Method为例进行具体描述。

1.1 结构型设计模式—对象Adapter设计模式

图1描述了对象Adapter设计模式，包括Target、Adapter、Adaptee三个主要参与者及其之间存在的关系。具体特征表示见表2。表2中01行表示图1对象Adapte设计模式中存在Target、Adapter、Adaptee三个主要参与者，其中Adapter、Adaptee为类，而Target为接口；02行表示Adapter与Target间存在泛化关系；03行表示Adapter与Adaptee间存在关联关系；04行表示Adapter类的request方法与Adaptee类的Specific request方法间存在代理关系；05行表示Adaptee类存在一个SpecificRequest方法，且SpecificRequest是一个具体的方法；06行表示Adapter类的request方法与Adaptee类的Specificrequest方法不存在共同接口；07表示Client不能对Adaptee类进行直接访问；08行表示Adapte类与Adaptee类间不能存在继承关系；09行表示Adapte类与Target类间不能存在继承关系。

图1 对象Adapter设计模式

1.2 行为型设计模式—Command设计模式

图2描述了Command设计模式，包括Invoker、Command、ConcreteCommand、Receive四个主要参与者及其之间存在的关系。具体特征表示见表3。表3中01行表示图2 Command设计模式中存在Invoker、Command、ConcreteCommand、Receiver四个主要参与者；02行表示Invoker与Command间存在关联关系；03行表示ConcreteCommand与Command间存在继承关系；04行表示Command类与ConcreteCommand类有共同方法Execute；05行表示ConcreteCommand类与Receiver类间存在关联关系；06行表示ConcreteCommand类的Execute方法与Receiver类的Action方法不存在代理关系；07表示Client类可以对Receiver类进行直接访问。

图2 Command设计模式

表3 对象Command模式特征表示

1.3 创建型设计模式—Factory Method设计模式

图3描述了Factory Method设计模式，包括Creator、ConcreteCreator、Product、ConcretProduct四个主要参与者及其之间存在的关系。具体特征表示见表4。表4中01行表示图3Factory Method设计模式中存在Creator、ConcreteCreator、Product、ConcretProduct四个主要参与者；02行表示ConcreteCreator类与Creator类间存在泛化关系；03行表示存在FactoryMethod类，且Factory不是抽象类；04行表示Creator类与ConcreteCreator类有共同方法FactoryMethod；05行表示Factory Method有一个ConcreteProduct返回类型；06行表示Factory Method方法存在一个返回值ConcreteProduct；07表示Factory Method类与ConcreteProduct类存在依赖；08表示Concrete Product类与Product类存在继承关系；09行表示Product与ConcreteProduct不能通过FactoryMethod方法形成继承关系。

图3 Factory Method设计模式

表4 Factory Method模式特征表示

续表4

2 设计模式分类识别步骤

设计模式识别的框架见图4，主要分为5个步骤：

图4 设计模式识别流程

步骤1用本文先前工作[21]对源码进行抽取；

步骤2将抽取源码结果进行特征表示；

步骤3通过EA[22]工具进行设计模式识别；

步骤4将设计模式进行定义及特征表示；

步骤5将设计模式识别结果与P-Mart案例库[23]进行匹配。

3 实验设计与分析

实验采用先前已实现的四个MIS系统进行测试，其具体指标见表5。其中，KLOC表示程序代码行数，每个测试系统中的Adapter模式、Command模式、Factory Method模式基准已通过人工的形式增加了标签。如测试系统A中的代码数量KLOC为87.73千行，类的数目为167，其中有Adapter模式5个、Command模式2个、Factory Method模式1个。

表5 测试系统指标基准

续表5

Erich Gmma[24]将GOF设计模式分为结构型、行为型、创建型3个大类，共计23种设计模式。作者在先前工作中对设计模式进行了初步的识别，但是缺乏对三类设计模式进行具体的分类归纳与表示[21]。为此，本实验以先前工作为基础展开，并获取了表6所示的结果。

表6 设计模式识别精确率

由表6可见，在测试系统A中对于Adapter模式、Command模式识别效果较好，识别精确率为100%，而对Factory Method模式识别精确率为0%。在测试系统B中对于Adapter模式、Command模式识别效果较好，分别为100%与66.7%，而对于Factory Method模式识别精确率为50%。在测试系统C中也对于Adapter模式、Command模式识别效果较好，分别为91.7%与83.3%，而对于Factory Method模式识别精确率为50%。在测试系统D中对于Adapter模式、Command模式识别效果较好，分别为95.5%与77.8%，而对于Factory Method模式识别精确率为71.4%。

探究其原因归纳为如下几点：

(1) 创建型设计模式识别难度高于行为型设计模式，而行为型设计模式难于结构型设计模式。由表7可知，Adapter模式识别的平均精确率最高，为96.8%；Command模式识别的平均精确率次之为81.95%；而Factory Method模式的平均精确率仅为42.85%。究其原因，Adapter模式属于结构型设计模式，Command模式属于行为型模式，Factory Method模式属于创建型模式。结构性模式没有涉及到动态的时序机制，故识别难度较低，识别效果较好；行为型模式要涉及动态时序机制，故识别难度要高于结构型模式，故识别效果居中；而Factory Method模式属于创建型设计模式，除开动态时序机制，还需要考虑代理机制等居多问题，故识别难度最大，平均识别精确率最低。

表7 三个测试系统平均精确率

(2) 设计模式变体易导致识别结果不精确。对实验结果进行深入分析之后发现，测试系统中一个标准设计模式存在多个版本的问题，即设计模式变体[15-16]。设计模式变体能够降低研发成本，缩短研发时间，故目前研发人员通常会在不改变设计意图的前提下用设计模式变体进行程序设计，而目前设计模式识别方法或工具对变体的识别效果考虑不够深入，这可视为设计模式识别的重要挑战。

(3) 设计模式参与角色间的附加关系干扰了识别结果。同样，设计模式变体是在不改变设计意图的前提下对标准设计模式进行了演化，但这种演化可能导致严重的后果。通过实验研究，发现一些设计模式变体通过增加参与者角色间多余的关系会改变设计意图，即附加关系[17]，从而导致实现程序与目标需求的差异，这部分改变了设计意图的变体难以识别。

(4) 设计模式实例共享问题。通过研究设计模式识别结果，发现存在部分设计模式参与者角色同时承担两个或多个设计模式的参与者问题，而这类问题易导致只能随机识别一个先检测到参与者角色的设计模式，而与其承担角色相关的其余设计模式却难以识别成功。

本文先前工作[2,3,15-18]通过Jhotdraw 7、Junit 3.7、Quickuml 2001等基准系统进行了设计模式识别，部分效果要优于本文工作。分析其原因发现：

(1) 设计模式识别在训练阶段效果较好，而在验证阶段略不足，说明存在过拟合问题。识别效果在迁移、普适性等方面需要进一步加强。

(2) 数据集不够大，尤其在测试系统A中Factory Method设计模式基准数量为1，由于识别未成功，导致对于Factory Method设计模式识别精确率为0%，以至于表6的4个测试系统中的Factory Method模式平均识别精确率仅为42.85%。为此，还需要通过更多的设计模式实例或系统进行大规模的验证。

(3) 通过研究发现，大部分测试系统中创建型设计模式在软件设计中使用频率少于行为型设计模式，而行为型设计模式在软件设计中使用频率少于结构型设计模式。

4 结 语

依据Erich Gamma[24]提出的设计模式分类标准，对结构型、行为型及创建型设计模式进行了深入研究，归纳了设计模式的特征信息表示，以Adapter模式、Command模式、Factory Method模式为例，通过本文先前工作[21]对4个经典测试系统进行了设计模式识别实验，实验结果表明对结构型Adapter模式与行为型Command模式取得了较好的识别效果。未来工作将致力于创建型设计模式的识别，以及对设计模式变体、设计模式附加关系、设计模式共享等领域前沿问题的追踪。