From UML statecharts to Database Schema

Transcription

1 From UML statecharts to Database Schema 1. Introduction This Statechart to Database Schema example describes a set of schema mappings from a statechart model to a set of SQL code files which create a database which will store the trace of the statechart execution. From now on we will refer to this database as the trace database. This model to text transformation problem has arisen in the development of a larger project. This project consists of developing Ubiquitous Decision Support Systems (UDSS) for clinical guidelines in the healthcare context (see [12,13] for further information). By following our approach the dynamics of each clinical guideline is represented by using a UML statechart. Then, given the statechart representing the dynamics of a guideline, a database schema for storing the trace of the guideline application is automatically generated. The transformation process is carried out by following a set of successive schema mappings [4] and has been implemented in a MDD setting using two different MDA based tools: (1) (ATL [14], which is a model to model transformation tool and (2) MOFscript [6]), which is a model to text transformation tool. EMF SQL M3 MOF M2 UML UML + SEP Profile UML + SEP Profile* M1 Statechart model 1 PIM 2 PSM 3 Stereotyped Stereotyped Class Diagram Class Diagram* SQL Source Code StatechartToClass.atl ExogenTransformation.atl transformations.m2t Multiplicities.atl Profile.atl Legend conforms to ATL transformation ATL Library MOFScript transformations Fig. 1. Overview of the transformations.

2 1.1. Transformations Overview The transformation process is depicted in Fig. 1. Firstly, the statechart is translated into a stereotyped class diagram, which will be used as the conceptual model of the trace database. Then, from this conceptual model, a set of schema mappings are carried out in order to translate that stereotyped class diagram into the final SQL code which create the tables, constraints (such as primary and foreign keys), and triggers that constitute the trace database. As for the schema mappings, they are carried out by following a MDA approach. Based on the stereotyped class diagram, and taking into account the target platform, not all constructs available in that class diagram (such as association classes or composite attributes) may be directly implemented on it. The Model Driven Architect (MDA) approach [10] addresses this problem by defining Platform Independent Models (PIMs) and Platform Specific Models (PSMs), which are automatically obtained from PIMs. Then, the PSMs will be implemented in the target platform. In order to create the trace database from the stereotyped class diagram (hereafter PIM class diagram), we carry out two schema transformations: (i) the automatic transformation of this PIM class diagram into another stereotyped class diagram closer to the target platform (hereafter PSM class diagram) and (ii) the transformation of this PSM class diagram to the SQL source code which will generate the trace database. Regarding the implementation of the transformation process in a MDA setting, as we have commented previously, we have used two different MDA based tools with support for customizable model to model and model to text transformations respectively. On the one hand, to perform the specific model to model transformations of our approach (that is, from the UML statechart to the PIM class diagram and from this class diagram to the PSM class diagram) we have used the ATL tool [14]. ATL is a model transformation language development to answer the QVT Request for Proposal [9] issued by OMG. ATL is a hybrid model transformation language (it provides both declarative and imperative constructs) and allows developers to design three different kinds of ATL units, of which we use ATL modules and ATL libraries [14]. ATL defines two types of constructs, rules and helpers, and depending on the chosen programming mode, it distinguishes two different kinds of rules: the matched rules (declarative programming) and the called rules (imperative programming). ATL is implemented as an Eclipse plug in [14]. On the other hand, to carry out the model to text transformation of our approach (that is, from the PSM class diagram to the SQL source code) we have chosen the MofScript tool [6]. MOFScript is, like ATL, another Eclipse plug in which implements the MOFScript language, which is currently a candidate in the OMG RFP process on MOF Model to Text Transformation [8]. Each MOFScript transformation consists of transformation rules which are basically the same as functions, and which define the behavior of the transformation.

3 By using these two MDA based tools, we are able to automatically generate the trace database from a statechart. Next, we explain in detail these transformations and how we have used these tools to implement them. First Step: From the statechart to the PIM class diagram. To our knowledge, there is no criteria to follow for creating a class diagram from a statechart. Our proposal is based on the definition of (1) a UML profile [11] and (2) a set of transformation patterns to assist in the transformation process. In particular, the defined profile, called the UML Profile for statechart execution persistence (SEP profile), consists of a set of stereotypes which allows us to know, for each class in the class diagram, the type of UML statechart element to which it corresponds. The main aim of this profile is to give, by using its stereotypes, a simple mechanism to identify, for each class in the class diagram, the type of UML statechart element to which it corresponds. Then, these stereotypes will be implemented as triggers in the trace database. Each of those triggers will allow us to control the way in which the information is recorded by following the semantics of the UML statechart element to which each trigger corresponds. In order to carry out the transformation from the statechart to the stereotyped class diagram, we have implemented our transformation patterns into the ATL language. The result of such implementation is the definition of an ATL module (StatechartToClassDiagram.atl in Fig. 1) together with two ATL libraries. The defined StatechartToClassDiagram module is composed of a set of seventeen helpers, five matched rules and twelve called rules. In particular, helpers are used as global variables distinguishing: (1) those which value is assigned during the execution of a rule and its information is used in another rule to generate a target UML element, (2) those which traverse the source model, collect the information in it, and later they are used to generate target elements, and (3) those which value is static throughout the execution of the transformation. There is one matched rule which creates a UML package for the target class diagram and calls the rest of matches rules which will create the concrete classes that constitute the target class diagram (the context class and state, transition and region classes). The two called rules are used (1) to create associations between the created classes (including the transition association classes) and (2) to apply stereotypes to the created classes. The defined libraries are related with the application of the multiplicity constraints and the SEP profile to the class diagram respectively. The helpers that compose these libraries have been extracted of the StatechartToClassDiagram module in order to have related helper methods together. Then, the defined ATL units take the statechart and the SEP profile as source models. Both models conform to the UML 2.0 metamodel and have been created using the UML 2.0 Eclipse plug in [3] as.uml2 extension files. By using the defined ATL module together with the two libraries, the statechart is translated into the PIM class diagram which also conforms to the UML 2.0 metamodel.

4 Second Step: From the PIM class diagram to the PSM class diagram. This transformation is an exogen transformation [5] since the PIM and the PSM models conform to two different profiled metamodels. For each PIM class diagram created from a statechart, we have identified several types of elements (association classes, composite attributes and inheritance hierarchies) which have to be replaced with other more suitable UML elements in order to obtain the PSM class diagram closer to the target platform. See [2] for further information. As for the implementation of this transformation, we have defined another ATL module (ExogenTransformation.atl in Fig. 1). This ATL module replaces association classes, composite attributes and inheritance hierarchies from the PIM class diagram with other more suitable UML elements. On the one hand, we consider that the definition of the ATL rules related with the removal of composite attributes and inheritance hierarchy is straightforward and does not require further discussion. Inn the case of the removal of association classes, we have taken, as a starting point, the predefined RemovingAssociationClass ATL transformation from the catalogue of ATL model transformations of [1]. This predefined transformation replaces an association class by a class and two non directional associations. So, since following our transformation patterns, associations in the class diagram are defined as bi directional associations, we have modified the rules in the RemovingAssociation- Class transformation so that the new defined associations are bi directional. Then, this ATL module takes, as source models, the PIM class diagram created previously and the SEP profile (slightly modified, as we have explained previously), and return the PSM class diagram as a.uml2 extension file. Concerning the exogen transformation from the PIM class diagram to the PSM class diagram, we would like to note that the standard definition of ATL proposes a specific execution mode for this kind of transformations in which source and target models are very similar. This mode is called refining execution mode and enables developers to only specify the modifications that have to be carried out between the source and target models. Nevertheless, the used ATL version (for Eclipse 3.1) does not support refining mode, which has made us to use the default mode, specifying not only the rules that generate the modified model elements, but also all the rules that only copy source to target model elements. Third Step: From the PSM class diagram to the SQL code. As we have remarked previously, in order to perform the final schema mapping from the PSM class diagram to the SQL source code of the trace database, we have used the MOFScript [6,7] tool. The SQL code generator is defined as a set of transformations in the MOFScript language (transformations.m2t in Fig. 1). In particular, we have defined three MOFScript files concerning the creation of tables (tables.m2t), constraints (constraints.m2t) and triggers (triggers.m2t) respectively. The rules defined in these transformation files are divided into (1) those which traverse the model and collect the information in it and (2) those which generate actual SQL code. We have created another MOFScript trans-

5 formation (the main one, main.m2t) which calls those specific rules in order to return the specific SQL statements as.sql files. In particular, to develop the rules concerning the definition of the tables, we have followed the approach of [9] for UML to RDBMS mapping. For almost each rule proposed in [9] we have defined another rule with the same purpose and functionality. In addition, we have defined other rules to carry out the complete transformation considering specific multiplicities of our PSM class diagram. Regarding the creation of triggers, the defined rules translate each applied stereotype of the SEP profile into the corresponding trigger by following the specific semantics of the corresponding UML statechart element. The defined MOFScript transformations take the UML 2.0 metamodel as metamodel and the PSM class diagram as the source model and return several.sql files with the SQL statements which create the tables, constraints (such as primary and foreign keys), and triggers that finally constitute the trace database. 2. Configuration Details The transformations have been created with the following configuration: Eclipse EMF UML ATL 1.0 MOFScript1.1.7 References 1. ATL Transformations. Webpage atltransformations/. 2. E. Domínguez, B. Pérez, and M. A. Zapata. Tracing the Application of Clinical Guidelines Submitted for Publication. 3. EMF-based UML 2.0 Metamodel Implementation. The Eclipse UML2 project website, 4. P. G. Kolaitis. Schema mappings, data exchange, and metadata management. In Proceedings of the 24th Annual ACM symposium on Principles of database systems (PODS 2005), pages 61 75, New York, NY, USA, T. Mens and P. V. Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci., 152: , MOFScript Eclipse plug in. Website, Last visited: October J. Oldevik. MOFScript Eclipse Plug-In: Metamodel-Based Code Generation. In Proceedings of the Eclipse Technology exchange workshop (etx) at the ECOOP 2006 Conference, Nantes, France, OMG. Mofscript Second Revised Submission to the MOF Model to Text Transformation RFP. OMG document ad/ Available at 9. OMG. MOF 2.0 Query / Views / Transformations RFP, October ad/ Available at

6 10. OMG. OMG Model Driven Architecture, June Document omg/ Available at OMG. UML 2.0 Superstructure Specification, August Document formal/ Available at I. Porres, E. Domínguez, B. Pérez, A. Rodríguez, and M. A. Zapata. A Model Driven Approach to Automate the Implementation of Clinical Guidelines in Decision Support Systems Submitted for Publication. 13. I. Porres, E. Domínguez, B. Pérez, A. Rodríguez, and M. A. Zapata. Development of an Ubiquitous Decision Support System for Clinical Guidelines using MDA. In Proceedings of the CAiSE 07 Forum, Trondheim, Norway, June The ATL User Manual, version 0.7, February Available at eclipse.org/m2m/atl/doc/.