Pattern-based design evolution using graph transformation

ARTICLE IN PRESS

Journal ofVisual Languages & ComputingJournal of Visual Languages and Computing

18 (2007) 378–398

1045-926X/$

doi:10.1016/j

�CorrespoE-mail ad

www.elsevier.com/locate/jvlc

Pattern-based design evolution usinggraph transformation

Chunying Zhaoa,�, Jun Kongb, Jing Donga, Kang Zhanga

aUniversity of Texas at Dallas, Richardson, TX 75083, USAbNorth Dakota State University, Fargo, ND 58105, USA

Abstract

In recent years, design patterns gain more interest in software engineering communities for both

software development and maintenance. As a template to solve a certain recurring problem, a design

pattern documents successful experiences of software experts and gradually becomes the design

guidelines of software development. Applying design patterns correctly can improve the efficiency of

software design in terms of reusability and enhance maintainability during reverse engineering.

Software can be evolved when developers modify their initial designs as requirements change. For

instance, a developer may add/delete a set of design elements, such as classes and methods.

Modifications on software artifacts can introduce conflicts and inconsistencies in the previously

applied design patterns, which are difficult to find and time-consuming to correct. This paper

presents a graph-transformation approach to pattern level design validation and evolution. Based on

a well founded formalism, we validate a given design by a graph grammar parser and automatically

evolve the design at pattern level using a graph-transformation system. Rules for potential pattern

evolutions are predefined. The graph-transformation approach preserves the integrity and

consistency of design patterns in the system when designs change. A prototype system is built and

a case study on the Strategy pattern demonstrates the feasibility of pattern-based design validation

and evolution using graph transformation techniques.

Published by Elsevier Ltd.

Keywords: Design pattern; Graph transformation; Graph grammar; Visual language; Software evolution

- see front matter Published by Elsevier Ltd.

.jvlc.2007.07.004

nding author.

dresses: [email protected] (C. Zhao), [email protected] (J. Kong).

www.elsevier.com/locate/jvlc

dx.doi.org/10.1016/j.jvlc.2007.07.004

mailto:[email protected]

mailto:[email protected]

ARTICLE IN PRESSC. Zhao et al. / Journal of Visual Languages and Computing 18 (2007) 378–398 379

1. Introduction

Software systems become increasingly complicated and hard to maintain due to themassive information in the system and complex system structure. There has been an urgentneed for an efficient and effective method to ease the tedious work at softwaredevelopment and maintenance stages. The emergence of object-oriented design patterns[1] makes software development more efficient in terms of reusability because designpatterns document the successful experience of experts and provide solutions to certainreoccurring problems in particular contexts. Application of design patterns facilitatessoftware development in that it allows software engineers to communicate and collaboratewith each other efficiently. Well documented design patterns also assist the comprehensionof legacy programs in reverse engineering.

In addition to efficient software development methodologies, software systems shouldalways be adaptable to evolve upon modification requests from users or designers. Thisrequires a system to be extensible and flexible since we cannot know all the requirementsand build a perfect system at the beginning [2]. Arthur et al. [3] defined software evolutionas ‘‘a continuous change from a lesser, simpler, or worse state to a higher or better state’’for software system. To efficiently achieve such an evolution, modifications to a systemgenerally start from the design level that hides massive programming information becausethe size of a design is typically much smaller and more manageable than that of codes.

Since Gamma et al. [1] first introduced the well recognized design patterns, intensiveresearch has been carried out on the application of design patterns. The wide use of designpatterns requires an effective mechanism to validate software designs and allow designersto make modifications on them as system requirements change. On one hand, it isnecessary to guarantee that a design complies with the structural integrity of the designpatterns that have been applied. On the other hand, any change on the design should notviolate the structural properties of existing design patterns in the system, since a localmodification may have a chain effect on the whole system. Manually checking the impactof a single modification, however, is a time-consuming and error-prone process. In general,design evolutions that happen at pattern level includes refactoring [4] and design patternevolution [5]. Refactoring is to find the ‘‘bad smell’’ in the system and reconstruct it inorder to achieve better efficiency with external behaviors preserved. Design patternevolution is to refine a design pattern according to requirements changes while maintainingthe pattern’s properties. A design pattern normally includes changeable and stable parts.The changeable part of a design pattern can be potentially adapted to several differentapplications, while the stable part will remain. More specifically, pattern participants,e.g. classes and relationships, may be added to/removed from a particular design patternwithout violating the pattern’s structural properties and constraints. We defined sucha process as a pattern level design evolution, in which pattern participants in a systemdesign are modified but the fundamental properties of the design are preserved at thepattern level.

As a de facto standard to visually modeling software systems, UML provides a set ofintuitive notations to represent design patterns and corresponding designs. The lack offormal semantics, however, prevents UML from automatic validation and evolution.Dong et al. [5] automated the design evolution process as XSLT transformations that cantransform the UML model of a design pattern application into the evolved UML model ofthe pattern. Both the original and evolved UML models are represented in an XMI format

ARTICLE IN PRESSC. Zhao et al. / Journal of Visual Languages and Computing 18 (2007) 378–398380

to facilitate the transformations. To take advantage of the graphical characteristics UMLdiagrams, we explore a graph-transformation approach to pattern level design validationand evolution.Graph transformation, which offers a computational paradigm of mathematical

precision and visual specification [6], provides an intuitive yet formal means to interpretand manipulate visual languages. In general, graph transformation defines computationin a multi-dimensional fashion based on a set of rewriting rules, i.e. productions.Each production consists of two parts: a left graph and a right graph, the differencebetween which visually indicates the changes generated by a computation. By representinga design as a graph, the problem of design evolution is converted to graph evolution, whichcan be naturally realized through graph transformation: the left graph of a productionindicates the pre-condition of an evolution and the right graph represents the post-condition after an evolution. Applying graph transformation to design evolution canguarantee that the design after evolution still observes the structural properties of itsunderlying patterns. A graph grammar system [7] extends a graph transformation systemby (1) defining an initial graph and (2) classifying terminal and non-terminal objects. Inthis way, a graph grammar abstracts the essential structures shared by a set of graphs.Therefore, we formalize the structure of a design pattern into a graph grammar, andcorrespondingly validate the structural integrity of a design through a parsing process, i.e.a sequence of graph-transformations. Using visual representation to interpret softwareevolution and validation improves the expressiveness to human’s understanding andcommunication.In summary, this paper presents a graph-transformation framework for pattern level

design validation and evolution, which is characterized by a syntax-oriented graphicaldesign environment facilitated by an automatic design evolution tool. The graphical designenvironment can verify whether a design observes the structural integrity of a designpattern while the evolution tool can guarantee that a design after evolution is stillconsistent with the structural properties of its underlying patterns. Validation of a design isa parsing process on a graph representing the design. In order to improve the performanceof the parsing process, each design pattern defines one key structure. We first locate the keystructure in a design and then initiate a parsing process from the key structure. The keystructure can narrow down the parser’s searching scope and thus achieve a betterperformance. Based on the characteristics of GoF design patterns, we categorize patternlevel design evolutions into five types [11] (e.g. independent evolution and packagedevolution), which are applicable to different design patterns. Each evolution style in aspecific design pattern is defined through graph-transformation. When an evolution iscarried out through graph transformation, the syntactic correctness of the evolved design isguaranteed with respect to a design pattern.The contributions of this paper are threefold:

�
Formalizing design pattern structures using graphical representation. � Validating patterns in a design by the spatial graph grammars. � Realizing pattern-based design evolutions through graph-transformations.
The rest of the paper is organized as follows. Section 2 briefly introduces the Spatial
Graph Grammar (SGG) [8] formalism and concepts of graph transformation. Section 3explains the classification of design pattern evolutions. Section 4 presents the overview ofour framework and investigates a graph-transformation approach to design pattern


validation and evolution. Section 5 shows a prototype system and illustrates an exampleusing the Strategy pattern. Section 6 reviews related work. Section 7 concludes this paperand discusses the future work.

2. The spatial graph grammar and graph-transformation

Graph grammars extend Chomsky’s generative grammars into the domain of graphs.Different from string grammar expressing sentences in a sequence of characters, graphgrammars are suitable for specifying information in a multidimensional fashion.

The SGG formalism [8] is a context-sensitive graph grammar formalism, which allowsthe left graph to have multiple nodes, and is expressive in specifying various types ofgraphs. The SGG formalism is expressed in a node-edge format as presented in Fig. 1. Inan SGG, nodes are organized into a two-level hierarchy, where a large rectanglerepresenting the node itself is the first level with embedded small rectangles as the secondlevel called vertices. Fig. 1(a) depicts a typical SGG node, which includes various vertices.In a node, each vertex is uniquely labeled. A node can be viewed as a module, a procedureor a variable, etc., depending on the design requirement and object granularity. A vertexfunctions as a port to connect other nodes by an edge. Edges denote communications orrelationships between nodes.

With a well-established theoretical background a graph grammar can be used as anatural and powerful syntax-definition formalism [7] to specify visual languages and theparsing algorithm based on a graph grammar may be used to check the syntacticcorrectness. More specifically, applying a production to a host graph can be classified as anL-application (i.e. replacing the left graph of a production with the right graph of theproduction) or R-application (i.e. a replacement from the right graph to the left graph).The visual language, defined by a graph grammar, can then be derived by usingL-applications from an initial graph. On the other hand, R-applications are used to verifythe membership of a graph. If a host graph is eventually transformed into an initial graph,i.e. a special symbol l, the parsing process is successful and the host graph is considered torepresent a type of design sharing the structural properties specified by the graph grammar.

Due to the multi-dimensional nature of graphs, some mechanisms are needed to addressthe embedding issue in a graph transformation [9], i.e. establishing relationships betweenthe surrounding of a replaced graph and its replacing graph in the host graph. Inheritedfrom the reserved graph grammar [10], the SGG addresses the embedding issue by themarking technique. In a production, a vertex is marked by prefixing its label with a unique

Pic

N

P

Vertex

Node

:= Pics2

1:D

2:N

Pics1

1:D

N

Pic

2:N

P

Fig. 1. Spatial graph grammar representation: (a) A node; (b) A production.

ARTICLE IN PRESS

PicsD

N

PicP

N

PicP

N

D

N

PicP

N

PicsD

N

PicP

N

Fig. 2. The marking technique: (a) before transformation; (b) preserve context information; (c) after

transformation.

C. Zhao et al. / Journal of Visual Languages and Computing 18 (2007) 378–398382

integer. For example, in the production of Fig. 1(b), vertex D of Pics1 is marked while thevertex N is unmarked. If a vertex v in a replaced sub-graph (i.e. a redex) maps to a markedvertex in a production, v will be preserved during graph-transformation to establishconnections between the surrounding of the replaced sub-graph and a new replacing sub-graph. As the sub-graph (the dotted rectangle) in Fig. 2(a) is isomorphic to the rightgraph of the production in Fig. 1(b), the vertices in Fig. 2(a) that map to the markedvertices in Fig. 1(b) are highlighted with gray color. Those highlighted vertices will bepreserved in a graph-transformation as shown in Fig. 2(b), and the transformed graph isshown in Fig. 2(c).

3. Pattern based design evolution

3.1. Problem statement

Design patterns have been widely accepted as guidelines documenting the design of anobject-oriented system since Gamma et al. [1] introduced the popular 23 design patterns.Each design pattern has a structure, behavior and semantic meaning. The structureindicates the structural relations among pattern elements; the behavior tells how patternparticipants interact with each other and the semantic meaning defines the context of aproblem addressed by the design pattern.Therefore, each design pattern has some essential properties. For example, the Mediator

pattern should have a concrete mediator referred to each of its concrete colleagues whileconcrete colleagues do not have references between each other. In real modeling, a designcan evolve with variations to satisfy application requirements without violating thepattern’s essential properties. For example, we introduce a new concrete colleague class tothe mediator pattern as shown in Fig. 3. Such an evolution is not trivial since any localmodification may cause the evolved design violating some underlying essential properties.If a designer ignores the neighboring elements influenced by the modification, the changecan lead to inconsistency and a consequent malfunction. For instance, in Fig. 3, theintroduction of class ConcreteColleague3 requires to establish one inheritance and oneassociation with Colleague and ConcreteMediator (highlighted with dotted circles),respectively, in order to maintain the essential properties of the mediator pattern. Missing

ARTICLE IN PRESS

ColleagueMediator

ConcreteColleague1

ConcreteColleague2ConcreteMediator

ConcreteColleague3

Fig. 3. The Mediator pattern.

Contex Strategy/Target

ConcreteStrategy/

AdapterAdaptee

Contex1

ConcreteStrategy

Contex2Strategy

Fig. 4. Overlapping patterns.

C. Zhao et al. / Journal of Visual Languages and Computing 18 (2007) 378–398 383

any of these elements violates the constraints of the mediator pattern. However, it istedious and error-prone to require designers to perform all the required modificationspropagated within the design.

This paper aims at developing a graphical design environment that supports automatedpattern-based design evolutions, in which two challenging issues will be addressed: (1) thepattern structural integrity of a design needs to be validated since a syntactically correctdesign is the prerequisite of a successful pattern-based design evolution; (2) an automaticmechanism is desirable to perform pattern-based design evolution while keeping theevolved design correct and consistent.

There are some issues that need special attention when we perform pattern-based designvalidation and evolution. For instance, design elements, e.g. a class, may participate inmultiple design patterns. Patterns sharing common elements can be the same or differentas shown in Figs. 4(a) and (b) respectively. In Fig. 4(a), the Strategy pattern overlaps withthe adapter pattern. In Fig. 4(b) two Strategy patterns share the same ‘‘strategy’’ and‘‘concreteStrategy’’. If a modification occurs to the shared elements of multiple designpatterns we need to consider the influences to all patterns involved.

3.2. Classification of pattern-based design evolution

The pattern-based design evolution involves the modifications of pattern participants.Pattern participants of a software system include classes, attributes, operations and


relationships, e.g. association and generalization. For example, a designer may introduce anew class to extend the original design. As discussed in Section 3.1, the modification to apattern element may affect other pattern participants. In real world modeling, designpatterns are applied in the system with variants to meet various application requirements.We explore the changeable part in each design pattern that allows future extensions.Pattern level design evolutions could change the structure and behavior of a system bymeans of addition/deletion of software artifacts while keeping the fundamental propertiesof its underlying pattern invariant.Although different patterns have different properties, they share some common

evolution requirements and actions. From this perspective, we summarize five patternlevel evolutions that are recurring in different design patterns. For each evolution style, thechanges will not violate the properties and constraints of the original design. We classifypattern-based design evolution into five main categories [11] as follows:

�

C

C

Independent: The addition or removal of one independent class and the correspondingrelationships between this class and the classes in the original pattern. The added orremoved class is independent in the sense that the addition or removal of the class doesnot cause any effects on the existing classes of the design. For example, in Fig. 5(a), aconcrete class with a generalization and an association to other classes in the dashedarea can be added to the mediator pattern without changing the structural integrity ofthis pattern.

ConcreteFactory1

+CreateProductA()

+CreateProductB()

AbstractFactory

ConcreteFactory2

+CreateProductA()+CreateProductB()

ProductA1 ProductA2 ProductB1 ProductB2

AbstractProductA AbstractProductB

ConcreteFactory1


AbstractFactory

ConcreteFactory2

ProductA1 ProductA2 ProductB1 ProductB2

AbstractProductA AbstractProductB


Mediator Colleague

oncreteMediator ConcretColleage ConcreteColleague

Subject

oncreteSubject

+Attribute: A1

Observer

ConcreteOberver

+Attribute: A1

ConcreteObserver

+Attribute: A1

Subject

ConcreteSubject

+Attribute:A1

+Attribute:A2

Observer

ConcreteObserve ConcreteOberver

+Attribute:A1

+Attribute:A2

+Attribute:A1

+Attribute:A2

Fig. 5. Classification of possible evolutions.


�

Ta

Po

Ty

1

2

3

4

5

Packaged: The addition or removal of one independent class and the correspondingrelationships between this class and the classes in the original pattern. In addition,certain attributes and/or operations of this class are added and removed accordingly.Fig. 5(b) shows the observer pattern. The dashed rectangle shows the addition of oneConcreteObeserver class with one attribute.
� Class group: The addition or removal of one attribute/operation in several different
classes consistently. In this case, a certain set of classes, instead of a single class, areaffected by the addition or removal of the attribute or operation. Fig. 5(c) shows theobserver pattern with an additional set of attributes that are highlighted in the dashedrectangle. This pattern indicates that a new data is observed by all the observers.
� Correlated class: The addition or removal of a group of correlated classes. When certain
classes are added or removed, some other classes have to be added or removedaccordingly. Fig. 5(d) shows an AbstractFactory pattern. Adding one ConcreteFactoryclass is accompanied by the addition of two product classes with the correspondingrelationships as shown in the dashed areas.
� Correlated attribute/operation: The addition or removal of a group of classes, that
requires the addition or removal of some attributes or operations in the classes of theoriginal pattern applications. As shown in the dashed part of Fig. 5(e), adding ProductBclasses has to be accompanied by the addition of two correlated CreateProductB()methods to the classes in the original design.

The category of design pattern evolution offers a guideline for developers as they evolvea software system and guarantees pattern consistency. Table 1 summarizes the relation-ships between the pattern evolutions and GoF design patterns. For example, theCorrelatedClass and CorrelatedAttribute/Operation evolutions can be applied to theadapter pattern.

Based on the classification of pattern evolutions, this paper presents a graphicalenvironment with a graph-transformation engine that supports an automatic designevolution. Given a design pattern, each applicable evolution is specified through asequence of graph-transformation rules. By explicitly representing the changes caused by adesign evolution in the graph-transformation process, a complete evolution can be carriedout without missing any modifications on the affected pattern participants. Therefore weavoid the tedious work of manually checking each evolved design.

ble 1

tential evolutions of design patterns [11]

pe Evolution name Design pattern name

Independent Mediator, Fac-ade

Packaged Prototype, Bridge, Composite, Decorator, Interpreter, Observer, State,

Strategy, TemplateMethod, Visitor, Chain of responsibility

ClassGroup Decorator, Observer

CorrelatedClass AbstractFactory, Builder, FactoryMethod, Adapter, Proxy, Command,

Iterator

CorrelatedAttribute/

Operation

AbstractFactory, Builder, Adapter, Visitor


4. Graph-transformation approach to design pattern evolution

4.1. Overview

This section describes a general framework of our approach as shown in Fig. 6. Given adesign, a graph-transformation-based design pattern evolution proceeds in three steps [12]:

Design representation: Using a graphical design environment, a designer can applydesign patterns to a system design represented in UML class diagrams. Alternatively,design patterns can be retrieved from source codes using reverse engineering techniques. Ineither case, a design pattern expressed in a UML class diagram can be automaticallytransformed into a node-edge representation, which can be recognized by the SGG parser.Then, a design pattern in a node-edge format can be validated and evolved through graph-transformation in the next two steps.

Design validation: Since a syntactic-correct design pattern is the prerequisite for asuccessful evolution, we need to validate the structural and behavioral properties of thegiven pattern. An SGG based parsing approach is used to examine the fundamentalproperties of a pattern. More specifically, we formalize the fundamental properties of adesign pattern into a graph grammar. Based on the graph grammar, if a design pattern canbe finally reduced to an initial graph, i.e. a special symbol l, through a parsing process, thedesign satisfies all essential properties enforced by the pattern. Given a host graphrepresenting a design, the start point of a parsing is essential to a successful designvalidation. For example, based on the graph grammar in Fig. 9, the parser will fail in thevalidation of a design in Fig. 8 if the first class analyzed is not the ‘‘Strategy’’. One brutal-force approach is to start the parsing process exhaustively for each symbol in the hostgraph once [13]. In order to improve the parsing performance, we employ the key structurein each design pattern, which characterizes the essential property in a design pattern. Tovalidate the structure and behavior properties of a design, we first locate the key structurein the design and then start the parsing process from the key structure. In summary, thevalidation module consists of two steps:

1.
Locate the key structure in a design. 2. Start parsing from the key structure.
The first step can be realized by a linear searching algorithm which will be explainedshortly. The searching space is small since there are normally a limited number of nodes in

Design in a UMLdiagram Evolution

RequestConsistent

Design

Node-Edgediagram

Graph Editor

Environment

SGG Parser

KeyStructure

DesignPattern

Transformation Engine

ValidatedDesign

EvolvedDesign

Rules

Searchalgorithm

SGG

Fig. 6. Overall framework.


each pattern. At the second step, we apply a graph grammar to a node-edge diagramcorresponding to the user-defined design.

Design evolution: The graph-transformation engine consists of a set of predefined graph-transformation rules for each type of pattern evolutions. The input to the transformationengine includes the node-edge diagram of a design, which has been verified in the secondstep, and the modification request specified by the user, e.g. adding/removing aclass. According to the modification request, a set of predefined graph-transformationrules are selected to evolve the design. The graph-transformation rules apply all thechanges to the evolving design in order to keep its fundamental properties invariant.In order words, the productions define both the changes to the design elements specifiedby a user and other related changes caused by the user’s changes. Therefore, using thegraph-transformation engine for the evolution will guarantee the consistency of theevolved pattern.

4.2. Design representation

As described in Section 2, we employ the SGG formalism to specify pattern-based designvalidation and evolutions. Both the system under study and the evolving design arerepresented as graphs. This section introduces preliminary concepts that are intrinsic tograph grammars and design representations.

Class diagram, one of the most popular diagrams in UML, visually models the staticstructure of a system in terms of classes and their relationships. In order to verify thestructure of a class diagram, we translate a class diagram (Fig. 7(a)) into a node-edgeformat (Fig. 7(b)), on which the SGG parser operates. Nodes denote classes andrelationships, e.g. Association in a UML class diagrams. Each node includes a set ofvertices. Each node and vertex has a label to represent its meaning.

In class diagrams, classes are represented by compartmentalized rectangles includingclasses, attributes and operations. In a node-edge diagram, a node labeled Class denotesthe first compartment containing the class name. A set of nodes labeled Attri representsattributes in the second compartment. These nodes are sequenced by linking two adjacentattributes in the order as they are displayed in the compartment, and the sequence ofattributes is attached to a class name by linking the first Attri node with the Class node.

Target

Request()

Adapter

Request()

Adaptee

SpecificRequest()

Target

MI

OpR

C

Inhe PC

Adapter

M

IA

Op R

C

Adaptee

A

IM

Op R C

Asso L

R

Fig. 7. The adapter pattern and its node-edge representation.


Operations in the third compartment are processed in the same way as attributes byreplacing Attri with Oper nodes.

An association denoted by straight or diagonal lines in UML carries information aboutreference relationships between two classes. In a node-edge diagram, a node labeled Asso isused to symbolize an association between two nodes. To indicate the navigability ofassociation, there are two vertices labeled L and R inside the node Asso. The verticeslabeled L and R inside an Asso node are connected to a referencing Class node and areferenced Class node, respectively. On the other hand, if a relationship is undirected in therepresentation of a design pattern, we ignore the difference between L and R. Aggregation

and Composition, two special types of associations, are translated in the same way asassociations.

A generalization specifies a hierarchical relationship between a general description and aspecific description. In the node-edge representation, a node Inhe is used to denote thegeneralization between two classes. Similarly to the Asso node, there are two vertices insideInhe labeled P and C, which are used to connect the parent class and the child class,respectively.Definition 1. Given a vertex set O, a node is 3-tuple N ¼ (V, l, name), where V is a set of

vertices, l: V-O is an injective function to label vertices, and name is the node label.In particular, there are two kinds of vertices in a node that represent a class in a design

pattern: relationship vertex and method call vertex. As shown in Fig. 7, the graph definesthe adapter pattern. The node named ‘‘adapter’’ represents a class name and has twovertices labeled ‘I’ and ‘A’ to connect with the generalization and association relationships,respectively. The vertex ‘M’ connects to a method call node.Definition 2. A directed host graph is a 4-tuple G ¼ (N, E, s, t), where N is the node set,

EAN�N is the edge set, and s, t: E-V.N are two functions that specify the source andtarget points of an edge. V.N is the set of vertices within N.Fig. 7 is a host graph instance representing the adapter pattern in the node-edge format.

Nodes denote classes, relationships and interacting method calls. Vertices imply directionsof relationships. For instance, the inheritance node named Inhe has two vertices P and C

that connect to a superclass and a subclass, respectively, impling a class ‘adapter’ inherits aclass ‘target’.Definition 3. Two nodes n1 and n2 are isomorphic, denoted as n1En2, iff

9f ððf : n1:V ! n2:V Þ ^ 8v 2 n1:V ðn1:lðvÞ ¼ n2:lðf ðvÞÞÞ ^ n2:s ¼ f ðn1:sÞÞ.

The definition requires that two nodes are isomorphic if and only if they have the samevertices and node labels. For instance, the node ‘‘class’’ in the production /1S of theStrategy pattern in Fig. 9 and the node ‘‘class’’ in the node-edge representation of theStrategy pattern in Fig. 8 are isomorphic.

4.3. Design validation

4.3.1. Key structure

We first need to validate if a user-defined pattern instance complies with somefundamental structural properties before it evolves. In general, there exists a key structure[14] in each design pattern that plays an essential role in gluing different design elementsinto a complete pattern. For instance, in the adapter pattern in Fig. 7, the class ‘adapter’with an association and inheritance relationships is the key structure for the adapter

ARTICLE IN PRESS

Strategy MI

A

Inhe P

C

ClassM

IA Class

M

IA

OpR

COp R

C

Op R

CClassM

IA

Contex1

ConcreteStrategy1

Strategy

ConcreteStategy2

Key structure

Fig. 8. The Strategy pattern and its node-edge representation.


pattern. For the Strategy pattern, the class ‘‘Strategy’’ is the key structure. The keystructure functions as a nexus in a design with the highest number of connections withpattern participants. Moreover, its behavior shows the major semantic meanings thatdistinguish the pattern from other patterns. A key structure can comprise more thanone node.

We develop a linear searching algorithm to locate the key structure in a design pattern.A key structure is characterized by: (1) the number and type of its connections withneighboring elements; (2) the types and names of nodes. For instance, the key structure inthe Strategy pattern is a non-abstract class with one aggregation, at lease onegeneralization and at least one connection to a method call. This information is thecriterion to identify the key structure of a design pattern in the linear search.

In the implementation of the linear searching algorithm, the node-edge graph is a 2-tupleG (V, E) and a class is represented in as a 2-tuple (N, R). N and R are one-dimensionalarrays that store the class information and its neighboring relationships, respectively.Relationships are distinguished by the weights of edge. As each host graph has a limitednumber of nodes, the two-dimensional graph can be stored in a one-dimensional arraywith all the node information recorded in an arbitrary order. The algorithm examineseach node and its connections. If a node that satisfies the property of a key structureis identified, we will mark it. The process continues until all nodes are scanned once.The pseudocode of the algorithm is shown as follows:

Algorithm KEYSTRUCTURE_SEARCHInput: A graph G (V, E)Output: A sub-graph of GCreate a Queue QEnqueue (Q, V)While Q is not empty do

for each vertex v in Q dofor all edges e incident on v do

Add edge e’s type to v


If v ‘edge types satisfy those of a key node in key structureMark v and mark its edges.

Dequeue(Q,v)

4.3.2. Graph grammar parsing

Definition 4. Two graphs G1 and G2 are homomorphic, denoted as G1EG2, iff (f: G1-G2,where f is a mapping such that 8n 2 G1:N : n � f ðnÞ and 8e ¼ ðv1; v2Þ 2 G1:E : f ðeÞ ¼

ðf ðv1Þ; f ðv2ÞÞ 2 G2:E.Graph homomorphism is an essential concept in graph parsing. When the parser

matches a redex G1 (a subgraph of a host graph) with a graph G2 of a rule, the redex G1

and the graph G2 must be homomorphic. A graph grammar includes a set of productions,which formally summarizes the essential properties of a design pattern. Staring from thekey structure located in the first step, we apply the graph grammar to the user-definedpattern. If the pattern can be reduced to an initial graph, i.e. l, by a sequence ofproductions, the pattern conforms to the structural properties of a particular designpattern.Fig. 8(a) shows the Strategy pattern and Fig. 8(b) is its corresponding node-edge

representation, in which operations are explicitly added in order to validate theinteractions between classes. The syntax productions are defined based on the node-edgerepresentations. Pattern participants such as classes, attributes and operations arerepresented as non-terminal symbols with respect to their syntactic meanings. Fig. 9illustrates the productions for the Strategy pattern. In this grammar, production /1S (forbrevity P/1S) reduces the operations in a connected structure composed of a Strategyclass and a ConcreteStretegy class. P/1S further eliminates the ConcreteStrategy nodethat connects to an inheritance node and the operation node attached to the Strategy node.P/3S reduces the last ConcreteStrategy node in the structure. P/4S indicates that aContext-Strategy structure can be generated from the structure produced by P/3S. Thelast production specifies the context-strategy structure can be reduced to l. Reaching thestate l implies a successful parsing. Fig. 10 illustrates a parsing process that initiates fromthe class ‘‘strategy’’ on the Strategy pattern with predefined productions.

4.4. Design evolution

As both the original design pattern and evolved design pattern are represented asgraphs, a pattern level design evolution can be naturally interpreted as a graph-transformation: the left graph defines the precondition before an evolution while the rightgraph specifies the postcondition after evolution. The graph-transformation processproceeds by finding a redex in a host graph and replacing it with the right graph of atransformation rule.According to the definition and classification of pattern evolutions described in

Section 3, each design pattern has certain types of potential evolutions. Each evolution isuniquely determined by two factors: the desired type of evolution and the pattern name.Definition 5. A pattern level design evolution E is a partial function of type T and

Pattern P: T�P-E, where T ¼ {Independent, Packaged, ClassGroup, CorrelatedClass,CorrelatedAttribute/Operation}, and P ¼ {GoF design patterns}For instance, according to Table 1 the Strategy pattern may be changed in a Packaged

evolution. In this type of evolution, developers can add or remove an independent class

ARTICLE IN PRESS

P<1>

P<5> P<4> P<2> P<3>

P<1>

Fig. 10. A paring process of the Strategy pattern.

Strategy MI

1:A

InheP

2:C

Class

M

I

A

Op

R

C

Op

3:RCStrategy M

I 1:A

Inhe P

2:C

Op

3:R C

ConcreateStrateg

M

I

A

:= Strategy M

I 1:A

Inhe P

2:C

Op

RC

ConcreateStrateg

M

I

A

:=

Strategies MI

1:A

Inhe

P

2:C

Strategies M I

1:A

Inhe P

2:C

ConcreateStrateg

M

I

A

Strategies M I

1:A

Inhe P

2:C

:=

<1> <2>

<3>

<4>

<5>

M

Strategies MI

AContex

M

I

Aλ := Asso RL

Inhe

C

Contex

M

I

A StrategiesI

A

P

:= ClassM

I

AStrategies MI

A Asso RL Asso R L

Fig. 9. Graph grammars for the Strategy pattern.


(e.g. the ConcretateStrategy2 class in Fig. 11) with its corresponding method or attributes(e.g. the AlgorithmInterface method) and relationships with other classes (e.g. theinheritance relationship with strategy) as well. Fig. 12 gives the production to realize a

ARTICLE IN PRESS

Contex

ContextInterface()

ConcreteStrategy1

AlgorithmInterface()

Strategy


ConcreteStategy2


Fig. 11. Packaged evolution on the Strategy pattern.

Strategy M I

1:A

Inhe P

2:C

Op

3:RC

:=

Class

M

I

A

Op R

C

Strategy MI

1:A

Inhe P

2:C

Op

3:RC

Fig. 12. A production for packaged evolution on the Strategy pattern.


Packaged evolution for the Strategy pattern. Before applying the production to a hostgraph representing the original design pattern, the transformation controller will first finda match of the left graph of the production, i.e. a redex, in the host graph. In this case, theredex consists of an inheritance node, a strategy node and an operation node. Once theredex is found, it will be replaced by the right graph of the production. As the productionsencapsulate all necessary modifications, all the elements can be changed together to keepthe fundamental properties invariant. Otherwise, manually performing the modificationwill cause some potential problems. Moreover, a manual modification requires a deepunderstanding of the evolved pattern since missing modification on any affected patternparticipant will violate the structural integrity.

5. A prototype system

This section shows a prototype system for an automated design pattern evolution basedon SGG. At the system level, the graph-transformation approach described above isrealized by four modules as shown in Fig. 13: node editor, production editor, graph-transformation engine and graphical editing tool in the node-edge format.

ARTICLE IN PRESS

UML Graphical Editing Tool

Source codes

Reverse Engineering

Users

Edit

Convert

Pattern validation and evolution

Graphical Editing Tool in the Node-Edge

Node Editor Production Editor

Productions

Graph Transformation Engine

DesignPatterns

Fig. 13. System architecture.

Fig. 14. SGG production editor.


The node editor and production editor provide an easy-to-use user interface to definegraph grammar and graph-transformation rules. A graph grammar formalizes the essentialproperties of a design pattern while graph-transformation rules specify design evolutions.Designers can use a graphical editing tool to edit design patterns in the node-edgerepresentation. Alternatively, designers can also specify design patterns in the form ofUML, which are automatically converted to a node-edge representation. The graph-transformation engine is the kernel of the system, which validates the structure of a designpattern and evolves a design upon users’ requests. The graphical design system allows usersto define nodes, edit host graphs, customize production rules and automatically parse hostgraphs. If a host graph can be parsed successfully, the system will report a valid result andshow the parsing path.

In the case study, we use the Strategy pattern as a host graph and illustrate its parsingprocess. Fig. 14 is the screenshot of the production editor. All productions of the Strategy

ARTICLE IN PRESS

Fig. 15. A valid Strategy pattern.


pattern are listed in the leftmost column. The two columns on the right show the left graphand right graph of production /2S, respectively, as defined in Section 4.3 (Fig. 9). Shadedvertices are marked. We can also import predefined productions. Fig. 15 illustrates thehost graph of the Strategy pattern and a valid parsing result. The popup shows a validparsing result on the host graph and a tree structure that indicates how the host graph isconstructed by the grammar. The host graph in Fig. 16 is not valid since the connectionbetween nodes 7 and 9 is missing, which violates the structural properties of the Strategypattern.Similarly, design pattern evolutions can also be conducted by this system after minor

modifications to the parser and applying the rules differently. This case study shows thefeasibility of using SGG formalism to represent and validate design patterns.

6. Related work

Design pattern becomes popular in OO software research communities since Gammaet al. [1] proposed the catalog of design patterns. Research on design patterns mainlyfocuses on the techniques for pattern application, pattern recovery and pattern evolution.With the development of visual language applications [15–17], many research work havetaken advantage of the formal foundation of visual languages, i.e. graph grammars andtransformations, to address issues in the area of design patterns.Radermacher [18] used graph queries and graph rewriting rules to specify design

patterns. In his work, applications were reconstructed to meet certain prerequisites of amiddleware for distribution purpose. Systems were represented as graphs using

ARTICLE IN PRESS

Fig. 16. An invalid Strategy pattern.


PROGRES schema. Graph queries were used to detect violations to the distributionprerequisites. A supporting tool was built to transform a system in a way suchthat it conforms to a specific pattern. His work defined the system transformation aspatterns based on the prerequisites of distribution, which is an application of designpattern and different from out work that uses graph-transformation to realize patternevolution.

Another pattern application is refactoring. One aim of refactoring is to apply a suitabledesign pattern to enhance software flexibility. Mens et al. [19] adopted typed graph torepresent source codes and formalized two refactorings: encapsulated field and pull upmethod. The result showed that graphs rewriting rules could specify the source-codetransformation implied by a refactoring and the formalism guarantees the behaviorpreservation. The two refactoring reconstructed the system by implicitly applying a designpattern. Their work was the transformation from a design without a design pattern to adesign with design patterns.

Costagliola et al. [13] proposed a design pattern recovery approach using visuallanguages. Patterns were expressed in terms of visual grammars and retrieved by a patternrecognition parser. This parser used an attributed-based representation of XPG grammar,which is not as expressive as the SGG. The SGG keeps structural information byrepresenting classes and relationships as nodes and linking them via edges. Moreover, toparse a graph they exhaustively examined every node as a start point. On the contrary, weused a linear searching algorithm as a preprocessing to locate a key structure as the startsymbol, which greatly improves the parsing efficiency step.


There are also many design pattern recovery techniques that do not employ visual languageconcepts. Shull et al. [20] proposed an inductive method to manually discover customized,domain specific patterns from OO software systems. They tried to find out recurring patternsthat solved some specific problems by mining common structures from students’ assignments.Antonial et al. [21] presented a multi-stage reduction strategy using software metrics andstructural properties to extract design patterns from OO designs or codes. In their work,codes and designs were mapped into an intermediate representation, called Abstract ObjectLanguage. Ferenc et al. [22] presented the Columbus framework to recognize design patternsfrom C++ source code. They build an abstract semantic graph that contains all theinformation about the source code. Columbus uses a XML-based DPML (Design PatternMakeup Language) file to depict a design pattern and matches the graph of DPML to theASG to find patterns represented by DPML. Tsantails et al. [23] developed a patterndetection methodology based on a similarity scoring algorithm between graph representationsof the pattern to be detected and the system under study. This approach allows the detectionof customized patterns. These work mine patterns from systems mainly based on patternstructures. The evolution of patterns was, however, not addressed.Dong et al. [11] defined the classification of pattern evolutions and proposed an

XMI-based approach to design pattern evolutions. Different from our work, both theoriginal and evolved UML models were presented in XMI format. The evolution wasperformed as XSLT transformation with a set of user predefined rules. Java TheoremProver (JTP) was deployed to verify the system. The XMI files had to be converted to anRDF/RDFS format before validation. In contrast, our approach specifies all the necessarymanipulations in graph grammar rules, which enhances the expressiveness and accuracy ofthe evolution. Furthermore, design representation conversions between validation andevolution stages are avoided in our system since we use the same graphical format todenote a system design.Ciraci et al. [24] formalized software evolution using algebraic graph rewriting. They

modeled software architecture as a colored graph that combined the information fromUML class diagrams and interaction diagrams. The evolution requests were viewed asmorphisms on the components of the software system. They use transformation rules forevolution requests and argue that these rules can be combined to realize various evolutionrequests. Indeed, graph rewriting techniques can formalize software evolution; Ciraci et al.,however, did not apply them to the design pattern level software evolution, nor to thevalidation any structure in the system.Kobayashi et al. [25] considered pattern evolutions from the perspective of software

development. They evolved the analysis patterns that represent system requirements to thedesign patterns at the design level. The evolved patterns do not necessarily maintain thestructural properties of the original pattern because the analysis patterns and the designpatterns serve for different purposes. In their work, the evolution of patterns was totransform the artifacts in previous stages into new ones during a software developmentcycle. The evolution target was different from ours and the consistency issue of thisapproach had not been addressed.

7. Conclusion and future work

Evolution of design patterns represented in UML diagrams is an important issue insoftware development. This paper has presented a graph-transformation approach to


pattern-based design validation and evolution, which helps developers to validate theirpattern level designs and allows further consistent modifications. We defined a set ofproductions for each design pattern based on its fundamental structure and behaviorproperties. We examined the characteristics of design pattern and summarized thepotential evolutions for each pattern. Based on the classification of design patternevolutions, we specified graph-transformation rules to manipulate the pattern participantswhile maintaining the underlying pattern properties of the design. As the transformationrules for each evolution include all the influenced pattern participants, the evolved design isconsistent with the original one.

Based on the SGG formalism, we implemented a syntax-oriented graphical designenvironment facilitated by an automatic design evolution tool. A design is validated bySGG parser in the graphical environment and the syntax-correctness of the evolved patternis guaranteed by the evolution tool. We investigated the applicability of our approach byrunning an example of the Strategy pattern.

As the future work, we will incorporate the approach to UML modeling tools byautomatically converting UML diagrams to node-edge diagrams. Productions for eachdesign pattern will be semi-inducted automatically from given software systems [26]. Theconcept of pattern evolution defined in this paper can be extended if we can deriveproductions for customized patterns. The behavior aspect of a design pattern will also beformalized.

Acknowledgments

The authors would like to thank the Guest Editors and the anonymous reviewers fortheir insightful and constructive comments that have helped us to significantly improve thepaper.

References

[1] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design patterns: Elements of Reusable Object-oriented

software, Addison-Wesley, Reading, MA, 1995.

[2] M. O Cinneide, P. Nixon, Automated software evolution towards design patterns, in: Proceedings of the

fourth International Workshop on Principles of Software Evolution, 2001, pp. 162–165.

[3] L.J. Arthur, Improving Software Quality: An Insider’s Guide to TQM, Wiley, New York, 1993.

[4] J. Zhang, Y. Lin, J. Gray, Generic and domain-specific model refactoring using a model transformation

engine, Model-driven Software Development-Research and Practice in Software Engineering, Springer,

Berlin, 2004.

[5] J. Dong, S. Yang, Y. Sun, E. Wong, QVT based model transformation for design pattern evolutions, in:

Proceedings of the 10th IASTED international conference on Internet and multimedia systems and

applications (IMSA), 2006, pp.16–22.

[6] D. Varro, A formal semantics of UML statecharts by model transition systems, in: Proceedings of ICGT

2002, Lecture Notes in Computer Science, vol. 2505, 2002, pp. 378–392.

[7] G. Rozenberg (Ed.), Handbook of graph Grammars and Computing by Graph-Transformation:

Foundations, vol. 1 (1), World Scientific, Singapore, 1997.

[8] J. Kong, K. Zhang, X. Zeng, Spatial graph grammars for graphical user interfaces, ACM Transactions on

Computer–Human Interaction (TOCHI) 13 (2) (2006) 268–307.

[9] J. Rekers, A. Schurr, Defining and parsing visual languages with layered graph grammars, Journal of Visual

Languages and Computing 8 (1) (1997) 27–55.

[10] D.Q. Zhang, K. Zhang, J. Cao, A context-sensitive graph grammar formalism for the specification of visual

languages, Computer Journal 44 (3) (2001) 187–200.


[11] J. Dong, S. Yang, K. Zhang, A model transformation approach for design pattern evolutions, in:

Proceedings of the 13th Annual IEEE International Conference and Workshop on Engineering of Computer

Based Systems, 2006, pp. 80–92.

[12] C. Zhao, J. Kong, K. Zhang, Design pattern evolution and verification using graph-transformation, in:

Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS’07), 2007,

pp. 290a.

[13] G. Costagliola, A. De Lucia, V. Deufemia, C. Gravino, M. Risi, Design pattern recovery by visual language

parsing, in: Proceedings of the Ninth European Conference on Software Maintenance and Reengineering,

2005, pp. 102–111.

[14] I. Philippow, D. Streitferdt, M. Riebisch, S. Naumann, An approach for reverse engineering of design

patterns, Software System Model 4 (2005) 55–70.

[15] J. Kong, G. Song, J. Dong, Specifying behavioral semantics through graph-transformation, in: Proceedings

of Workshop on Visual Modeling for Software Intensive Systems, 2005, pp. 51–58.

[16] D. Le Metayer, Describing software architecture styles using graph grammars, IEEE Transaction on

Software Engineering 24 (5) (1998) 521–533.

[17] R. Bardohl, G. Taentzer, M. Minas, A. Schurr, Application of graph-transformation to visual languages,

Handbook on Graph Grammars and Computing by Graph-Transformation: Applications, Language and

Tool, vol. 2, World Scientific, Singapore, (1999) 105–180.

[18] A. Radermacher, Support for design patterns through graph-transformation Tools, in: Proceedings of

International Workshop and Symposium on Applications of Graph-Transformation with Industrial

Relevance (AGTIVE), 1999, pp. 111–126.

[19] T. Mens, S. Demeyer, D. Janssens, Formalizing behavior preserving program transformations, in:

Proceedings of International Conference on Graph-transformation, 2002, pp. 286–301.

[20] F. Shull, W.L. Melo, V.R. Basili, An inductive method for discovering design patterns from object-oriented

software systems, Technical Report, Computer Science Department, University of Maryland, 1996.

[21] G. Antoniol, G. Casazza, M.D. Penta, R. Fiutem, Object-oriented design pattern recovery, Journal of

Systems and Software 59 (2) (2001) 181–196.

[22] R. Ferenc, A. Beszedes, L. Fulop, J. Lele, Design pattern mining enhanced by machine learning, in:

Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM’05), 2005,

pp. 295–304.

[23] N. Tsantails, A. Chatzigeorgiou, Design pattern detection using similarity scoring, IEEE Transaction on

Software Engineering 32 (11) (2006) 896–909.

[24] S. Ciraci, P. Brook, Modeling software evolution using algebraic graph rewriting, in: Proceedings of

Workshop on Architecture-Centric Evolution (ACE 2006), 2006.

[25] T. Kobayashi, M. Saaki, Software development based on software pattern evolution, in: Proceedings of the

Sixth Asia–Pacific Software Engineering Conference, 1999, pp. 18–25.

[26] K. Ates, J.P. Kukluk, L.B. Holder, D. Cook, K. Zhang, Graph grammar induction on structural data for

visual programming, in: Proceedings of IEEE International Conference on Tools with Artificial Intelligence

(ICTAI), 2006, pp. 232–242.

Documents

Pattern-based design evolution using graph transformation