focusmodel-driven development A Metamodeling Approach to Pattern-Based Model Refactoring Robert France, Sudipto Ghosh, Eunjee Song, and Dae-Kyoo Kim, Colorado State University he success of model-driven architecture methods hinges on the support they provide for three things: creating meaningful mod- els in a timely way; specifying and applying patterns that reflect T useful and reusable design abstractions; and defining and sys- tematically applying model transformations that support model evolution, refinement, and code generation. Model transformation occurs when we modify a source model to produce a target model. Applying a well-defined design pattern is one way to transform a model. Pattern-based model refactoring For example, a developer might modify an ex- The process of transforming a model using isting design using a pattern to produce a target a design pattern is called pattern-based refac- model in which the pattern is realized.1,2 This toring. We can achieve rigorous pattern-based article shows how to define and apply design refactoring by developing metamodels called patterns in the context of model transforma- transformation specifications that characterize tions. The design models we discuss, both families of transformations. Or, you might source and target, are expressed in the Unified think of metamodels as defining a transforma- Modeling Language.3 tion language; the characterized transformations are “sentences” in this language. The meta- models act as points against which we can Design patterns capture some of the best software development check model transformations for conformance. solutions to design problems in forms that are intended to facilitate Figure 1 shows an example of pattern-based model refactoring using the Gang of Four’s reuse. The authors’ metamodeling approach to pattern-based Bridge pattern.1 (The Gang, also known as refactoring incorporates the precise specification of design patterns “GoF,” includes Erich Gamma, Richard Helm, and transformation rules. Their example uses the Abstract Factory Ralph Johnson, and John Vlissides.) The pattern and a small UML model. Bridge pattern shown in Figure 2 describes 52 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE displayed_on Refactoring displayed_on implemented_by Display ImageImpl1 Display Image ImageImp (applying the Bridge pattern) Abstract class ImageImpl1 Figure 1. An example of how to separate an abstraction from its imple- patterns across a design. Such tools must be pattern-based model mentations so that you can vary the abstrac- pattern-aware—that is, the tools must embed refactoring. tions and implementations independently. The codified knowledge of patterns that the sys- UML design model in Figure 1 has a Display tem’s users can access. Pattern-aware tools class associated with an ImageImpl1 class present patterns as abstraction units that de- that defines a class of image implementations. velopers can use to construct models. This model is refactored so that the Display Popular descriptive forms of design pat- class is now associated with an Image class terns, although effective at communicating de- structure that allows image implementations sign experiences to software developers, are linked to the display to be varied at runtime. too informal to use as a basis for developing The refactoring shown in Figure 1 might pattern-aware modeling tools. We need pre- proceed as follows: cise forms of patterns, called pattern specifica- tions, to codify them in tools. Transformation 1. Identify the design elements in the source rules also must be precisely specified if these model that will participate in the pattern tools are to support them. We use a metamod- solution. Modify them so that they can eling approach to specify both patterns and participate as the pattern specifies. In this transformation rules. Because we probably case, we identify the Display class as the can’t capture all the variations of a pattern in client (not shown in Figure 2) using the one specification, we can associate a single Abstraction, and the ImageImpl1 class pattern with many pattern specifications, each as a ConcreteImp participant. representing a pattern variation. Each pattern 2. Add new model elements as needed to realize specification in turn can be associated with the behavior specified by the pattern. Create multiple transformation specifications, where two new classes representing image abstrac- each specification characterizes a different way tions (the Abstraction participant in the of embedding a pattern into a design. pattern description) and implementation in- terfaces (the Implementor participant). The Our approach Image class plays the role of Abstraction, To support pattern-based UML model refac- and the ImageImp class plays the role of toring, a pattern specification should include Implementor in the refactored model. Cre- ate an association (implemented_by) be- I Problem specification: a precise specifica- tween the Abstraction and Implementor tion of the family of UML design prob- classes, as the pattern requires. The design lems that the pattern addresses class ImageImpl1 becomes a subclass of Im- I Solution specification: a precise specifica- Figure 2. A diagram of ageImp in the refactored model—that is, it the Bridge pattern. plays the role of an Implementor subclass. implemented_by We can do this refactoring manually with Abstraction Implementor relatively little effort on small models. How- ever, the process can become tedious and error- prone when we apply it to larger models. Tools that automate the process of applying RefinedAbstraction ConcreteImpA ConcreteImpB pattern-based transformations help reduce the effort of consistently and correctly realizing September/October 2003 IEEE SOFTWARE 53 M1 model transformations are characterized by a transformation specification at the M2 Pattern problem Transformation Pattern solution level that includes a pattern problem specifica- M2 specification specification specification tion for the source models and a pattern solu- tion specification for the target models. We can also view the transformation specification at Instance-of Instance-of Instance-of M2 as defining a transformation language for dependency dependency dependency the pattern, and the transformations at M1 as statements of the language. A UML model that conforms to a pattern problem or solution M1 Source model T1 Target model specification is said to be an instance of the specification. Similarly, a model transforma- tion that conforms to a transformation specifi- Model transformation cation is said to be an instance of the transfor- mation specification. Pattern problem and pattern solution spec- Figure 3. Metamodeling ifications characterize a subset of UML mod- approach to specifying tion of the UML designs representing so- els characterized by the UML metamodel, so transformations. lutions of the pattern we can view the specifications as defining I Transformation specification: a specifica- UML metamodel specializations. UML tool tion of problem-to-solution transformations developers can embed patterns by appropri- ately specializing their representations of the Figure 3 presents an overview of our meta- UML metamodel. modeling approach to specifying transforma- Figure 4 illustrates how we can represent tions. The M2 level is an extension of the UML the pattern solution specification for a simpli- metamodel level that supports the definition of fied form of the Observer pattern as a spe- Figure 4. (a) A pattern a transformation language. The M1 level is an cialized form of the UML metamodel. The solution specification extension of the UML model level that sup- Observer pattern specification characterizes for an Observer ports representation of model transformations. UML class diagrams that model structural pattern; (b) the A model transformation at the M1 level trans- aspects of Observer pattern solutions. Each specialized UML forms a source model to a target model. The target class diagram characterized by the spec- metamodel. Class Role |Subject StructuralFeature Role Association AssociationEnd |SubjectState BehavioralFeature Role |Attach (|o:|Observer) 1 1 1 1 AssocEndSub Observes AssocEndObs AssociationEnd Role |AssocEndSub 1 1 Represents 1 1 Association Role Subject Observer Class |Observes 1 1 1 1 1 1 AssociationEnd Role Attach o ObserverState |AssocEndObs Class Role |Observer StructuralFeature Role BehavioralFeature Parameter StructuralFeature |ObserverState BehavioralFeature Role |Update (|s:|Subject) (a) (b) 54 IEEE SOFTWARE http://computer.org/software Figure 5. A realization Class Role 1..* of the Observer |Subject Conforms to Kiln solution specification StructuralFeature Role in Figure 4a: (a) temp:Int |SubjectState 1..1 Conforming class ready:Int BehavioralFeature Role diagram; (b) Observer AttachTempObs (o:TempObs) |Attach (|o:|Observer) 1..1 pattern specification. 1..1 AssociationEnd Role |AssocEndSub 1..1 obsTemp Association Role |Observes 1..1 AssociationEnd Role * |AssocEndObs 1..1 TempObs Class Role 1..* |Observer currTemp: Temp StructuralFeature Role UpdateTemp (k:Kiln) |ObserverState 1..1 BehavioralFeature Role |Update (|s:|Subject) 1..1 (a) (b) ification consists of a Subject class (with an design pattern, first check the design model Attach operation and an attribute represent- against the pattern problem specification to ing its state) that can be associated with an determine if you can apply the chosen design Observer class containing a state attribute pattern