Tool Support for Instantiating UML Models from Domain Models

Transcription

1 Tool Support for Instantiating UML Models from Domain Models Dae-Kyoo Kim 1 Suntae Kim 2 Vanitha Sathyanarayanan 3 Oakland University, U.S.A Sogang University, South Korea Oakland University, U.S.A Abstract A domain model captures concepts that are common to applications in the domain. The development of an application model can be greatly eased if domain models are efficiently reused. In this work, we present a metamodeling approach to developing domain models and its tool support for automatic instantiation of application models from a domain model. We use the Role-Based Metamodeling Language (RBML) to define a domain model at the metamodel level. With the structural constraints of the application under development, the domain model is instantiated to generate an initial model for the application. The generated model is then completed by adding application specific properties which are not captured in the domain model. To demonstrate the approach, we consider the CheckIn-CheckOut (CICO) domain to build a domain model and use the domain model to develop a library system and a vehicle rental system. Keywords: Domain model, design pattern, UML model, Model Instantiation. 1. Introduction A domain model captures concepts that are common to applications in a specific domain. Systematic use of a domain model can reduce development time of applications in the domain [11]. A common use of a domain model is model instantiation. However, instantiating a domain model without tool support often becomes time-consuming and complicated, especially when the application is large and complex. Current tool support for domain models is limited to either simple introduction of pattern elements for a typical realization (e.g., IBM Rational Rose) or primitive customization via a tool-specific scripting language (e.g., Gentleware s Poseidon) which requires learning a new language. In this paper, we present a prototype tool, RBML Pattern Instantiator (RBML-PI), which automatically instantiates an application model from a domain model. Automatic instant- 1,3 Computer Science and Engineering Department Rochester Hills MI 48309, USA 1 kim2@oakland.edu, 3 vsathyan@oakland.edu 2 Computer Science and Engineering Department Seoul, South Korea 2 jipsin08@sogang.ac.kr iation requires a rigorous specification of a domain model. For precision and rigor of a domain model, we use the Role- Based Metamodeling Language (RBML), a metamodeling language developed in our previous work [4, 5, 6]. A major benefit of the RBML is that it is based on the Unified Modeling Language [14], and thus does not require the learning of a new language and can benefit from existing UML tools. In fact, RBML-PI itself is developed based on Rational Rose, a popular UML modeling tool from IBM, and domain models can use the UML drawing features provided by Rose to build an RBML domain model. There are several tools (e.g., see [2, 10, 12]) that support model instantiation from design templates. While template based tools makes instantiation process simpler by stamping out parameters, it is difficult to instantiate structural variations of different applications. For instance, one model may require two instances of a domain concept, while another model may be satisfied with a single instance. RBML-PI addresses this limitation by using the notion of roles in the RBML. RBML-PI allows one to specify the number of instances of a role that needs to be created via realization multiplicity constraint. Using this feature, the developer can instantiate various structures of applications by further constraining the structural constraints of the domain model specific to the application being developed. To describe the RBML-PI, we make use of the CheckIn- CheckOut (CICO) domain model developed in our previous work [7]. The CICO domain model characterizes applications that provide services for checking in and out items. We use the CICO domain model to create models of library system and a car rental system using RBML-PI. We give an overview of related work in Section 2 and a background of the RBML in Section 3. We describe the CICO domain model in Section 4. We present RBML-PI in Section 5 and demonstrate how the tool can be used to instantiate models of a library and car rental system from the CICO domain model in Section 6. We conclude the paper in Section Related Work After an intensive search, we have not found any tool support for instantiating a UML model from a domain model. There are several tools that support model instantiation from reusable artifacts such as design patterns.

2 These tools and the notations implemented in the tools can be used for domain models which are another type of reusable artifacts. We give an overview of some these tools. Florijn et al. [2] demonstrate a tool that instantiates program elements from a pattern template. Generated elements are integrated with an existing program by binding program elements to the generated pattern elements. The tool also checks whether the integrated program satisfies the properties of the patterns. Unlike RBML-PI which supports the model-level use of patterns, their tool is intended to support the programming-level use of patterns. Limitations of their tool are the lack of support for specifying behaviors and the learning requirement of their notations. Eden [1] presents tool support for a pattern specification language called LePUS developed in his previous work. Le- PUS defines patterns in terms of program properties, and the tool is used to apply pattern properties to programs written in Eiffel. The tool can find pattern instances in a program by checking the conformance of the program to the pattern. Like Florijn et al. s tool, Eden s tool is also intended for the programming-level use of patterns. Pagel and Winter [12] propose a tool that implements a metamodel developed in their previous work to describe patterns in Object Modeling Technique (OMT) [13]. Their tool can select a pattern from a pattern repository and instantiate a model from the pattern. Their approach lies along the same line as ours in that their focus is on the model-level use of patterns. However, their work mainly focuses on structural properties of patterns, and pattern s behaviors are not considered. Mapelsden et al. [10] demonstrate a tool that allows one to build UML design models from a pattern specification described in their own pattern specification language called DPML. In their work, a pattern is defined at the object level where pattern participants are bound to objects, not classes. Although actual binding occurs between objects and pattern elements at runtime, we argue that classes should be first class citizens during modeling. Rational Rose supports design patterns by instantiating a basic structure of a pattern with a minimum number of instances for pattern participants. For instance, the number of instances of the participants in the Observer pattern is set to one. However, an instantiation without considering the application context is basically impractical. In the example of the Observer pattern, it is often be the case where a subject is monitored by multiple observers. Also, Rose does not support pattern behaviors. 3. Overview of the RBML The RBML is a role-based metamodeling language developed in our previous work for specifying design patterns [5]. In this work, we use the RBML to design domain models as metamodel artifacts. The RBML specifies a domain model in terms of roles where a role defines a set of constraints. A role has a base metaclass in the UML metamodel, and is played by the instances of the metaclass that satisfy the properties specified in the role 1. A model is said to conform to a domain model if the model has elements that play the roles defined in the domain model. Class Role RoleA SRole: Int 1..* 1..* AssocRole 1..* EndA 1..1 EndB 1..* Class Role 1..* RoleB BRole ( o: RoleA) 1..* Figure1. A Static RBML Specification Figure 1 shows an example of a static RBML specification where roles are denoted by symbol. The specification has two class roles RoleA and RoleB whose base is the Class metaclass (as denoted above role s name). Therefore, only instances of the Class metaclass can play the roles. RoleA has a structural feature role SRole whose data type is integer. This further restricts the instances that can play RoleA in that they must possess a structural feature with integer data type. RoleB has a behavioral feature role BRole with a parameter role o whose type is RoleA. The class roles are connected by the association role AssocRole that has two association end roles EndA and EndB. Each role defines a realization multiplicity (shown near the role name) constraining the number of elements that can play the role. For instance, RoleB has 1..* realization multiplicity constraining that there can be one or more elements playing the role. A role is associated with a set of metamodel-level constraints and constraint templates. Metamodel-level constraints specialize the UML metamodel to restrict the type of model elements that can play the role. They are represented graphically or textually in the Object Constraint Language (OCL) [16]. For example, in Figure 1, RoleA has two metamodel-level constraints represented graphically the base metaclass Class and the realization multiplicity 1..*. The role may also be defined with the following OCL metamodel-level constraint specifying that classes playing the role must be concrete: context RoleA inv: self.isabstract = false Constraint templates are parameterized OCL expressions that define model-level constraints (e.g., pre- and postconditions) that must be satisfied by the model elements 1 Note that the notion of roles in the RBML is different from the one in the UML. RBML roles are defined at the metamodel level played by model elements, while UML roles are defined at the model level played by objects (for details, see [8])

3 <<RoleA>> ClassA <<SRole>> att: Int <<RoleA>> ClassA <<SRole>> att: Int <<AssocRole>> <<AssocRole>> <<AssocRole>> <<RoleB>> ClassB <<RoleB>> ClassB <<RoleB>> ClassC <<BRole>> op(c:classa) <<BRole>> op(c:classa) <<BRole>> op(c:classa) (a) (b) Figure 2. Different Model Structures Generated from RBML Specification in Figure 1 playing the role. As an example, the BRole behavioral role may be defined with the following constraint template: context RoleB :: BRole( o: RoleA) pre: o. SRole = 0 post: true The template specifies that objects playing RoleA must have an SRole structural feature set to 0. The template gets instantiated when the specification is realized. RBML specifications can instantiates various model structures. Figure 2 shows two instantiations of the RBML specification in Figure 1 having different structures. Figure 2(a) shows a simple structure that is instantiated with the upper bound of the realization multiplicity of all the roles set to exactly 1. Stereotypes denote the role from which the element is instantiated. For instance, RoleA in ClassA denotes that the class is instantiated from RoleA. Figure 2(b) shows a more complex structure that is generated by constraining the lower bound and upper bound of realization multiplicity of AssocRole and RoleB to 2 and the upper bound of the rest of the roles to 1. The RBML provides three types of RBML specifications to capture various perspectives of domain model properties: Static Pattern Specifications (SPSs), Interaction Pattern Specifications (IPSs), and Statemachine Pattern Specifications (SMPSs). In this work, we use only SPSs and IPSs. Readers interested in the full description of the RBML are referred to [5]. An SPS characterizes a structure of a family of design models in a class diagram view. An SPS consists of classifier and relationship roles whose bases are Classifier and Relationship metaclasses in the UML metamodel. A classifier role is associated with a set of feature roles that determines the characteristics of the classifier role and is connected to other classifier roles by relationship roles. An IPS defines interactions of domain participants in a sequence diagram view. An IPS consists of lifeline and message roles whose bases are the Lifeline and Message metaclasses. A lifeline role characterizes lifelines that are instances of a classifier that plays a classifier role in the SPS for which the IPS is described. We use the UML 2.0 sequence diagram notation to describe IPSs for a richer set of constructs, including constructs for packaging (e.g., loop) and referencing (e.g., ref) interactions [15]. 4. Domain Modeling: The CICO Domain The CICO domain model characterizes a family of checkin-checkout applications that manage item check in or check out. Applications within this domain include video rental, car rental and library systems. Some features of CICO applications characterized by the domain model are given below: Items that can be checked in and out have unique identifiers. Items are maintained in one or more collections (e.g., a library system can have a collection of journals, a collection of references, and a collection of general books). CICO applications maintain a list of registered users, that is, users that are authorized to check in or out items. Users can be grouped into different categories (e.g., a university library system may group users into faculty and student categories). A user can checkout an item (referred to as lending in this section) if it is available and the check out does not violate lending policies (e.g., a policy may constrain the number of items a user in a particular category can have checked out at any time). A checked out item can be checked in. The CICO domain model covers only those applications in which an item can be checked in only if it was previously checked out.

4 Figure 3. CICO Structural Pattern Specification 4.1 CICO SPS Figure 3 shows the SPS of the CICO domain model. The SPS consists of roles that define domain concepts, registered user (User), collection of registered users (CollectionUser), item check out details (Lending), item (Item), item description (Description), and checkin/checkout manager (Controller). can be zero or more (0..*) generalizations playing the role, and they must be instances of the Generalization metaclass. This constraint determines the generalization structure of items in an instantiated model. For instance, increasing the lower bound from 0 to 2 results in an item hierarchy consisting of two specializations. A behavioral feature role may be associated with a constraint template specifying the semantics of the behavior. The following constraint templates define the postcondition of the CheckIn and CheckOut behavior in Controller: context Controller :: CheckIn ( id : ID) post: For each message in the sequence of messages sent that matches a FindItem operation, the message returns an item, and the status of the item is false meaning that the item is not available for checkout, and the status of the item is false meaning that the item is not available for checkout, and the status of the item is set to available. let message: OclMessage = CollectionItemˆˆ FindItem( id) any(true) in message.hasreturned() and message.result() = item and item@pre. VerifyStatus() = false and itemˆ UpdateStatus( AVAILABLE) Figure 4. A Metamodel Constraint for ItemGeneralization Figure 4 shows a metamodel-level constraint for the ItemGeneralization relationship role constraining that there context Controller :: CheckOut ( uid: ID, iid: ID) post: The FindUser and FindItem operations are called. If the retrieved user is eligible to checkout the item and the item is available, a record of the checkout is

5 included in CollectionLending and the item status is updated to indicate that it has been checked out. let itemmessage: OclMessage = CollectionItem^^ FindItem(jiid) any(true), usermessage: OclMessage = CollectionUser^^ FindUser( uid) any(true) in usermessage.hasreturned() and usermessage.result() = user and user@pre.jverifystatus() = true and itemmessage.hasreturned() and itemmessage.result() = item and item@pre.jverifystatus() = true and Collectionlending exists (lendinfo lendinfo.oclisnew() and lendinfo. User = user and lendinfo. Item = item) and item^ UpdateStatus( CHECKEDOUT) Figure 5 shows the template specified in RBML-PI. The constraint template is used to generate post conditions for a CheckIn operation by instantiating the roles in the template. However, due to the inherent lack of support for the OCL in Rose, RBML-PI does not support instantiation of constraint templates. Instead, RBML-PI copies constraint templates into an instantiated model, so that developer can manually instantiate them. Figure 6. CICO CheckIn IPS Figure 7 shows an IPS for a check-out scenario. An instance of a Controller classifier invokes FindUser with the user ID uid to obtain a matching user u from a collection of users. The status of the user is verified. If the user is allowed to check out the item, the requested item is retrieved. The status of the item is queried to determine if it can be checked out. If the item can be checked out, a lending record is created. The record is then added to a collection of lendings (CollectionLending), and the status of the item is updated to unavailable. Figure 7. CICO CheckIn IPS Figure 5. A Constraint Template for the CheckIn Behavior in Controller Figure 6 shows an IPS for a check-in scenario. It describes that the item is found in the item collection, and its status is checked to determine whether it was checked out before. If the item was checked out before, the return date is set and the status of the item is updated to available. It should be noted that, for any domain, there is no such a thing as definite scope, and the same is true for a domain model. Therefore, domain models should be developed to be extensible and customizable as needed. From this point of view, the concept of roles in the RBML is suitable for domain modeling. By relaxing or constraining the realization multiplicity of roles, the scope of a domain model may be extended or narrowed down.

6 5. RBML Pattern Instantiator (RBML-PI) RBML-PI is a tool that automatically instantiates a UML model of application from an RBML specification. RBML- PI is developed as an add-in to IBM Rational Rose. We chose Rose as a base tool after a careful evaluation of other UML modeling tools including Together, ArgoUML, Poseidon and Microsoft Visio for the following reasons: RBML-PI was developed in collaboration with NASA Ames Research Center for an Air Traffic Control System project [17]. NASA uses a tool set developed based on Rose for generating statemachines from scenarios (i.e., sequence diagrams). We chose Rose for high compliance with the tool set of NASA. With the same base tool, models instantiated RBML-PI can be directly used as input to the NASA tool set. Rose provides a convenient API called Rose Extensibility Interface that allows one to access Rose s internal UML metamodel. This facilitates instantiating model elements from RBML roles. Rose is the leading CASE tool for developing UML diagrams in practice. We found that many other tools do not fully support sequence diagrams. For example, redirecting message source and target is often not allowed or is very limited. Figure 8. RBMLPI Class Diagram RBML-PI benefits from Rose as its base tool as follows: 1) RBML specifications can be built using the modeling features in Rose, and 2) the consistency between generated diagrams is automatically maintained by Rose. For instance, a change in a generated class diagram automatically triggers a corresponding change in related sequence diagrams. The core structure of RBML-PI is shown in Figure 8. It consists of EventHandler, RBMLHandler, SPSHandler, IPSHandler, MetaConstraintsHandler, and OperatorInfo. EventHandler is responsible for handling the event that starts off and initializes RBML-PI. Once the tool is initialized, EventHandler passes the control to RBMLHandler which initiates calls to SPSHandler and IPSHandler. Then, SPSHandler and IPSHandler generate a class diagram and sequence diagrams based on the metamodellevel constraints manipulated by MetaConstraintHandler. OperatorInfo handles sequence diagram operators such as loop, opt, alt as metamodel-level constraints. For instance, if a loop operator is used in an IPS, the message roles in the loop fragment are repeatedly instantiated until the condition of the loop is met. The current version of RBML-IP supports only the loop operator. Domain Engineering Pattern Author Application Engineering Application Developer build pattern specifications build model from pattern Rose select pattern Rose pattern exported instantiate pattern model generated Figure 9. Overview of Tool Use Pattern Library pattern imported RBML Pattern Instantiator Figure 9 shows the process of model development using RBML-PI. There are two stakeholders involved domain modelers who are responsible for defining domains in RBML and application developers who are responsible for customizing and applying patterns. A domain modeler uses Rose to build an RBML domain model specification and exports it into a domain model repository. An application developer chooses from the repository the domain model for the domain of which the current development is concerned with and imports the model into Rose. After importing, the developer may tailor the properties of the domain model (e.g., realization multiplicities) specific to the requirements of the application. In tailoring, the developer is assumed to have knowledge of the domain model. The current version of RBML-PI requires tailoring to be made directly to the domain model where the developer is exposed to the details of the model including those that are not related to the tailoring. We plan to provide in the next version an interface that hides details of the domain model other than tailoring points. Note that the amount of RBML knowledge required for the application developer to tailor a domain model is minimal. In many cases, realization multiplicities would be the only tailoring points. After tailoring, the domain model is instantiated to generate a UML model. The elements in the instantiated model are given a name generated by RBML-PI. The name is then renamed to be specific to the application by the developer. The generated application elements are stereotyped with the name of the role for which they are playing. This binds the application elements to the domain concepts. After the instantiation, elements that are specific to the application and not part of the domain model can be added to complete the model.

7 Figure 10. Library Class Diagram 6. Instantiating Domain Models Building a design model from an RBML pattern specification involves 1) instantiating the pattern specification using RBML-PI, 2) renaming the instantiated model elements specific to the application, and 3) detailing the instantiated model by adding application-specific model elements to complete the model. RBML-PI instantiates a domain model based on the metamodel-level constraints in the specification, which determines the structure of the model being generated. Specifically, RBML-PI uses the lower bound of role realization multiplicity to determine the number of instances to create for the role. For instance, the ItemGeneralization role in Figure 4 has the lower bound of its realization multiplicity set to zero, and thus no instance will be created for the role. The upper bound is not used in instantiation, but used in checking conformance of the completed model to the domain model [9]. Completing an instantiated model might add application-specific elements or remove instantiated elements. Both cases may violate the conformance to the domain model, and if conformance is crucial for the development, then it should be checked. Realization multiplicities may be further constrained by the application developer during instantiation, but cannot be weakened for the sake of conformance. 6.1 Case Example 1: Library System Figure 10 shows a class diagram for a library system built from an instance of the CICO SPS in Figure 3. The stereotypes in the diagram indicate the role that the model element plays, binding the application elements to the CICO domain concepts. They are also used to verify the conformance of the completed model to the CICO pattern [9]. The model elements were renamed after instantiation specific to the application. The following are some points to be noted in the diagram: The class Description contains four instantiated attributes which result from the realization multiplicity

8 4..* (not shown) of the DetailOfItem role in Figure 3. The multiplicity further constrains the original multiplicity of 1..* to address the application requirement for which copies are described in terms of name, author, producer, and product date. The class Controller contains two instances (checkout, reserve) of the CheckOut behavioral role to support two types of check out (regular check-out, reservation). The two instances are created by further constraining the original realization multiplicity 1..* of the role to 2..*. The realization multiplicity of ItemGeneralization role is set to 2..* to create two specializations Multimedia and Book of Copy. Application-specific elements, which are not stereotyped, are added to complete the model. They include the Reservation class and the name and address attributes in the Member class. The Reservation class is added to provide reservation service, and name and address are added to maintain the contact information of members. Figure 13 shows another instantiation of the CICO domain model for a vehicle rental system that allows a customer to make reservations for rental and rents truck and leisure vehicles. Both registered and non-registered customers can make a reservation and rent vehicles. Notable points in the class diagram are that 1) a user hierarchy is created specializing Customer into RegisteredCustomer and UnregisteredCustomer, and 2) two separate item collections (CollectionTruck, CollectionLeisure) are created, each for trucks and leisure vehicles (Truck and Leisure). Figure 12. Library CheckOut Sequence Diagram Figure 11. Library CheckIn Sequence Diagram Figure 11 shows a sequence diagram which is instantiated from the CICO CheckIn IPS in the context of the library system to checkin a copy. The sequence diagram has the same message sequence as in the IPS with corresponding participants. This is because the CICO CheckIn IPS has no variation point in the library system. Figure 12 shows a reservation scenario which is a kind of check-out. Note that in the sequence diagrams, an instance of the Copy class (i.e., the c:copy lifeline) is used instead of an instance of the Multimedia and Book classes which are child classes of the Copy class. This is the result of implementing the concept of polymorphism which allows an instance reference of a parent class to be used to reference an instance of child classes of the parent class. This also simplifies the sequence diagrams. 6.2 Case Example 2: Vehicle Rental System Figure 14 and Figure 15 show check-in and check-out sequence diagrams for the vehicle rental system generated from the CICO IPSs. Note that there are two instances (ct:collectiontruck and cl:collectionleisure) of the ci: CollectionItem lifeline role, which correspond to the two instances (CollectionTruck and CollectionLeisure) of the CollectionItem role in Figure 12. This shows that the consistency among diagrams is maintained in RBML-PI. 7. Conclusions and Further Work We have presented a prototype tool, RBML-Pattern Instantiator (RBML-PI), for instantiating UML models from RBML domain models. We have demonstrated use of RBML-PI for instantiating UML class diagrams and sequence diagrams of a library system and a vehicle rental system from the CICO domain model. The same examples were used in our previous work [7] where the models were manually instantiated, which was very time- consuming and tedious. We have also conducted one more case study with the financial domain. In the study, we developed a domain model for stock trading systems, and used the model to create two application models. Technically RBML-PI can generate models with any number of model elements using realization multiplicity. However, we have not tried more than ten instances for a single classifier role.

9 Figure 13. Vehicle Class Diagram Figure 14. Vehicle CheckIn Sequence Diagram There is still much work left to be done. The following describes the limitations of RBML-PI that need to be addressed in the future: The current version of RBML-PI supports only singlelevel hierarchies. In some cases, a class structure might have a multi-level hierarchy of generalizations, realizations, or a combination of both. For instance, the Copy hierarchy in Figure 10 may be further extended to the second-level by specializing Book into ScientificBook and HistoricalBook. Supporting multilevel hierarchies requires developing a scripting language to specify the information of the hierarchy (e.g., the number of levels, the number of classes at each level, etc.) Support for OCL constraint templates is limited. The current version of RBML-PI simply copies OCL constraint templates into the application model during instantiation. This requires the developer to manually bind the parameters in the template. We are currently investigating OCL tools that can be integrated with Rose.

10 Figure 15. Vehicle CheckOut Sequence Diagram Support for interaction operators in UML 2.0 is limited. This is due to the inherent lack of support for UML 2.0 in Rose which is based on an earlier version of UML 1.x. To address this, we have implemented the loop operator. We are investigating the migration of RBMLCC to an open source platform such as Eclipse where UML 2.0 could be better supported. Subsequent work will also consider support for verifying pattern conformance [9] and incorporating pattern properties into models (which is referred to as pattern-based model refactoring) [3]. Conformance verification can be performed to assure that the modifications made to complete the model after instantiation do not violate the conformance to the domain model. An RBML domain model can also be us to incorporate domain properties into an application model. The tool development presented in this paper has shown that automatic incorporation of domain properties is feasible. Acknowledgements This work is supported in part by the National Science Foundation under Grant No. CCF References [1] A. Eden. Precise Specification of Design Patterns and Tool Support in Their Application. PhD thesis, University of Tel Aviv, Israel, [2] G. Florijn, M. Meijers, and P. van Winsen. Tool Support for Object-Oriented Patterns. In Proceedings of the 11th European Conference on Object Oriented Programming, volume 1241 of Lecture Notes in Computer Science, pages Springer-Verlag, [3] R. France, S. Ghosh, E. Song, and D. Kim. A Metamodeling Approach to Pattern-Based Model Refactoring. IEEE Software, Special Issue on Model Driven Development, 20(5):52 58, [4] R. France, D. Kim, S. Ghosh, and E. Song. A UML-Based Pattern Specification Technique. IEEE Transactions on Software Engineering, 30(3): , [5] D. Kim. A Meta-Modeling Approach to Specifying Patterns. PhD thesis, Colorado State University, Fort Collins, CO, [6] D. Kim. The Role-Based Metamodeling Language for Specifying Design Patterns. In Toufik Taibi, editor, Design Pattern Formalization Techniques, pages Idea Group Inc., [7] D. Kim, R. France, and S. Ghosh. A UML- Based Language for Specifying Domain- Specific Patterns. Journal of Visual Languages and Computing, Special Issue on Domain Modeling with Visual Languages, 15(3-4): , June [8] D. Kim, R. France, S. Ghosh, and E. Song. A Role-Based Metamodeling Approach to Specifying Design Patterns. In Proceedings of the 27th IEEE Annual International Computer Software and Applications Conference, pages , Dallas, Texas, [9] D. Kim and W. Shen. An Approach to Evaluating Structural Pattern Conformance of UML Models. In Proceedings of the 22nd Annual ACM Symposium on Applied Computing, Software Engineering Track, Seoul, Korea,

11 , June 1997, pp [10] D. Mapelsden, J. Hosking, and J. Grundy. Design Pattern Modelling and Instantiation using DPML. In Proceedings of the 40th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS), pages ACS, [11] H. Mili, A. Mili, S. Yacoub, and E. Addy. Reuse-Based Software Engineering: Techniques, Organization, and Controls. John Wiley & Sons, 2002 [12] B.-U. Pagel and M. Winter. Towards patternbased tools. In Proceedings of EuropLop, M unchen, [13] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, [14] The Object Management Group (OMG). Unified Modeling Language. Version 1.5, OMG, [15] The Object Management Group (OMG). Unified Modeling Language: Superstructure. Version formal/ , OMG, November [16] J.Warmer and A. Kleppe. The Object Constraint Language Second Edition: Getting YourModels Ready formda. AddisonWesley, [17] J. Whittle, R. Kwan, and J. Saboo. From Scenarios to Code: An Air Traffic Control Case Study. Software and System Modeling, 4(1):71 93, Software Craft co. ltd, as a senior consultant and engineer for four years. His research focuses on the software architecture, design patterns and requirement engineering. Vanitha Sathyanarayanan is a graduate student at Oakland University. Her major is Software Engineering. She has received an award for outstanding academic achievement from Department of mathematics and statistics, Oakland University in She has completed BE degree in Electrical and Electronics engineering from Bharatiyar University, India, in Her research interests include model refactoring, design patterns, access control systems and service oriented architecture. Dae-Kyoo Kim is an assistant professor of the Department of Computer Science and Engineering at Oakland University. He received the Ph.D. in computer science from Colorado State University in He worked as a senior software engineer at McHugh Software International from 1997 till He has published more than thirty papers and regularly serves as a workshop chair, program committee member of numerous conferences and journals in the area of software engineering. He is currently serving on the editorial board of the International Journal of Pattern. His research interests include design pattern formalization, model refactoring, aspect-oriented modeling, software architecture modeling, access control modeling, and formal methods. He is a member of the IEEE Computer Society. Suntae Kim received his B.S degree at Chung-Ang University and his M.S degree at Sogang University in 2003 and He is currently a Ph.D. candidate at the Department of Computer Science and Engineering, Sogang University, Seoul, Republic of Korea. He worked in