focusmodel-driven development

A 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. 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- .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 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- 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- 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 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 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 to the source model. If so, develop the and an update operation. transformation steps using the transformation The specialized UML metamodel classes language defined by the transformation speci- shown in the blue box in Figure 4b (this is only fication at the metamodel level. Then apply a partial view) define the family of UML class di- the transformations to the source model to agrams that represents solutions of the produce a target model. Observer pattern. The pattern specification in Figure 4a represents the specialized metamodel Example that more clearly reflects the structure of pattern We illustrate the refactoring process using solutions. This specification is expressed in the maze game model described by the GoF.1 terms of pattern roles that define participants in To simplify the presentation, we describe only pattern solutions. Each role defines a specializa- the refactoring of class diagrams. Figure 6 tion of a UML metamodel class. For example, shows the maze game class diagram. The Subject and Observer define specializations MazeGame class is responsible for creating the of the Class metamodel class named Subject different types of mazes (there are two, and Observer, respectively, and the Observer BombedMaze and EnchantedMaze) and their role defines a specialization of the UML meta- parts. A maze consists of rooms with doors and model class Association. (Detailed descrip- walls. If a new type of maze or maze part were tions of the pattern specification notation are added, MazeGame would have to change signif- available elsewhere.4–6) Figure 5 presents a sim- icantly. Incorporating the Abstract Factory pat- ple class diagram that is an instance of the Ob- tern into the design results in a more flexible de- server pattern solution specification shown in sign, in which the maze creation aspects are Figure 4. Dashed arrows show a mapping be- localized in factories that the MazeGame class tween conforming model elements in Figure 5a can access. and roles in Figure 5b. For example, the At- Figure 7 shows the Abstract Factory prob- tachTempObs operation plays the Attach role. lem specification for the pattern used to refac- To refactor a design model using a selected tor the maze game design (we omitted the

September/October 2003 IEEE SOFTWARE 55 <> sides 4 MapSite Enter()

1.* <> <> <> Room Door Wall roomNumber Maze made-of Enter() isOpen Enter() RoomNo() 1 1.* SetSide() Enter() AddRoom() GetSide() <> 0..4 1

RoomWithBomb EnchantedRoom DoorNeedingSpell OrdinaryWall BombedWall

BombedMaze 1 * 1.* 1.* * 1.* 1.* 0..40..4 0..4

1 EnchantedMaze 1

MazeGame

Figure 6. The maze game, adapted from structural and behavior details inside the pat- tion for the Abstract Factory pattern. The Design Patterns: tern roles for simplicity). The specification specification characterizes solutions in which Elements of Reusable characterizes models that include a Client a client is associated with a hierarchy of facto- Object-Oriented class (an instantiation of the metamodel class ries that are responsible for creating products Software (Addison- specialization Client) that is connected to associated with the client. Wesley, 1995). one or more primary product classifier hierar- The transformation specification defines chies and in which each primary product clas- operation templates characterizing the follow- sifier is associated with zero or more subprod- ing transformations (the formal form of the uct classifier hierarchies. The Hierarchy templates is beyond this article’s scope): pattern roles define generalization or realiza- tion hierarchies of classifiers. (More details on 1. Create factory hierarchies. The instantiated how hierarchy roles are represented in the form of this template creates a hierarchy UML metamodel are available elsewhere.4) that matches the structure of a conforming An example is the hierarchy in Figure 6 PrimaryProduct. For example, substitut- consisting of Wall, OrdinaryWall, and ing a hierarchy consisting of MazeFactory BombedWall. Figure 7’s source maze model and its subclasses BombedMazeFactory conforms to this pattern problem specifica- and EnchantedMazeFactory results in tion: MazeGame plays the role of Client (that operations that create the MazeFactory is, it is an instance of the specialized meta- hierarchy shown in Figure 9. model class Client); the Maze hierarchy 2. Migrate the Create operations in MazeGame plays the role of the PrimaryProduct; and to appropriate factories. When instantiated the Room, Door, and Wall hierarchies each for the maze model, the result is an opera- play the role of SubPart. tion that moves the maze creation opera- Figure 8 shows a pattern solution specifica- tions out of MazeGame and places them into

Figure 7. An Abstract Factory pattern problem Class Role Hierarchy Hierarchy specification. |Client |PrimaryProduct |SubPart |ClientProduct |ConsistsOf

56 IEEE SOFTWARE http://computer.org/software Hierarchy Class Role Hierarchy Hierarchy |Factory |Client |PrimaryProduct |SubPart |ClientFactory|ClientProduct |ConsistsOf

Figure 8. An Abstract the appropriate factories. The associations when developing model refactoring techniques: Factory pattern solution between the primary product classes and specification. their subparts are used to determine where Preserving properties. A refactoring pre- the Create operations should reside. serves functional properties. When defin- For example, Create operations for ing a refactoring, we must specify the RoomWithBomb, Door, and BombedWall properties that are unchanged when the objects (parts of BombedMaze objects) are transformations are completed. In our ap- placed in the BombedMazeFactory. proach, these properties are defined as 3. Link the client to factories. The pattern part of the problem and solution specifi- user can use associations or dependencies cations (that is, the invariant properties to link the client to the factories. In this are those that are common to both speci- case, we chose to use an association to link fications). We are developing tools that MazeGame to MazeFactory. can help establish conformance of models to the specifications. Figure 9 shows the result of the refactoring. Identifying and resolving pattern interfer- ence. Composing two or more design pat- terns could lead to conflicts that must be resolved, and this process could involve e are now providing tool support trade-off analysis. Functional validation for our approach. The tool pro- for models that contain composed pat- W vides two interfaces, one for the terns is necessary. pattern engineer to evolve and manipulate the tool’s representation of the UML metamodel, Clearly, it is possible to use well-defined and the other for the application engineer to transformations to support systematic appli- create, manipulate, and evolve UML models cation of patterns. Tools that support pattern- using patterns. based model transformations provide develop- Figure 9. The maze There is significant potential for further re- ers with abstraction building blocks that go game refactored with search. Two major concerns must be addressed beyond those provided by general modeling the Abstract Factory pattern.

1 1 <> MazeGame Maze sides 4 MapSite * 1 Enter() * 1.* <> <> <> MazeFactory Room made-of Wall Door CreateRoom() BombedMaze 1.* roomNumber CreateDoor() Enter() isOpen Enter() CreateWall() SetSide() Enter() GetSide() <> EnchantedMaze 0..4

1 * BombedMazeFactory RoomWithBomb EnchantedRoom DoorNeedingSpell OrdinaryWall BombedWall 1..* 1..* * 1..* 1..* 0..4 0..4 0..4 1 EnchantedMazeFactory

September/October 2003 IEEE SOFTWARE 57 About the Authors languages. Using domain-specific patterns in particular can result in order-of-magnitude sav- Robert France is an associate professor at Colorado State University. His research inter- ings in development cost and time. We have ests are , object-oriented analysis and design methods, aspect-oriented modeling, and development of complex systems. He was a member of the OMG’s task force used this pattern specification technique to de- for UML 1.3 and 1.4 and is involved with evaluating UML 2.0 submissions. He is also coeditor fine not only general-purpose design patterns in chief of the Journal of Software and System Modeling. He received his PhD in computer sci- but also domain-specific patterns. Our current ence from Massey University in Palmerston North, New Zealand. Contact him at the Dept., Colorado State Univ., Fort Collins, CO 80523; [email protected]. work focuses on extending the transformation approach to support the application of prod- uct-line architectures. Sudipto Ghosh is an assistant professor in the Computer Science Department at Colorado State University, Fort Collins. His teaching and research interests include modeling, designing and testing of object-oriented software, distributed object systems, and aspect-oriented and com- References ponent-based . He received his PhD in computer science from Purdue Uni- 1. E. Gamma et al., Design Patterns: Elements of Reusable versity. He is a member of the IEEE Computer Society and the ACM. Contact him at the Com- Object-Oriented Software, Addison-Wesley, 1995. puter Science Dept., Colorado State Univ., Fort Collins, CO 80523; [email protected]. 2. W. Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, 1995. 3. The Unified Modeling Language: Version 1.4, tech. report Eunjee Song is a PhD candidate and a member of the Software Assurance Laboratory in formal/2001-09-67, , 2001. the Computer Science Department at Colorado State University. Her research interests include 4. R. France et al., “Using Roles to Characterize Model and specification, model refactoring, and design patterns. She received an MS Families,” Practical Foundations of Business and Sys- in computer science from Colorado State University and is a student member of the IEEE. Con- tem Specifications, Haim Kilov, ed., Kluwer Academic tact her at the Computer Science Dept., Colorado State Univ., Fort Collins, CO 80523; song@cs. Publishers, 2002. colostate.edu. 5. R.B. France, D.K. Kim, and E. Song, Patterns as Precise Characterizations of Designs, tech. report 02-101, Com- puter Science Dept., Colorado State Univ., 2002. 6. D. Kim et al., “Using Role-Based Modeling Language Dae-Kyoo Kim is a PhD candidate in computer science at Colorado State University. His (RBML) as Precise Characterizations of Model Fami- research interests are pattern formalization, model refactoring, aspect-oriented modeling, se- lies,” Proc. 8th IEEE Int’l Conf. Eng. of Complex Com- curity, and component-based software development. He received his MS in computer science puter Systems (ICECCS 2002), IEEE CS Press, 2002 from Western Michigan University. He is a member of the IEEE and the International Systems . Security Association. Contact him at the Computer Science Dept., Colorado State Univ., Fort Collins, CO 80523; [email protected]. For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.

SOFTWARE ENGINEERING Reviews joint acquirer-supplier review: Evaluation of an activity’s status GLOSSARY and products, conducted jointly between the system’s ac- quirer (representing the user) and the supplier (represent- review: A process or meeting during which a work product, or ing the developer), at the completion of a major software set of work products, is presented to project personnel, development milestone. Usually thought of as visibility and managers, users, customers, or other interested parties for status mechanisms, but its gate-keeping and action item [email protected] comment or approval. Types include joint acquirer-supplier aspects are also powerful control mechanisms. reviews (sometime called milestone reviews), management system requirements review (SRR): A system milestone review that reviews, technical reviews, peer reviews (includes inspec- ascertains the adequacy of the developer’s efforts in defining tions and walkthroughs), and audits. [IEEE Std 1028-1997] system requirements. Conducted when a significant portion of architectural design review (ADR): Evaluation of the technical the system’s functional and performance requirements have adequacies of the software architectural design as de- been established, normally in the definition phase. picted in the software design descriptions. Sometimes syn- technical review: Evaluation of products or services under consider- onymous with preliminary design review. ation to provide evidence that they are complete, comply with formal qualification review (FQR): The test, inspection, or ana- standards and specifications, and are ready for the next activity. lytical process by which a group of configuration items test readiness review (TRR): Determination that software test comprising a system are verified to have met specific con- procedures are complete and the developer is prepared tractual performance requirements. [ANSI/IEEE Std. for formal software performance testing; results of informal 610.12 1990] testing also are reviewed. [Military Std. 1521B-1985] California State University, Sacramento California State University,

Richard H. Thayer

58 IEEE SOFTWARE http://computer.org/software