Research Report
Total Page:16
File Type:pdf, Size:1020Kb
RZ 3621 (# 99631) 07/18/2005 Computer Science 10 pages Research Report A Systematic Approach to Designing Model Transformations Jochen M. Kuster,¨ Ksenia Ryndina and Rainer Hauser IBM Research GmbH Zurich Research Laboratory 8803 Ruschlikon¨ Switzerland {jku,ryn,rfh}@zurich.ibm.com LIMITED DISTRIBUTION NOTICE This report will be distributed outside of IBM up to one year after the IBM publication date. Some reports are available at http://domino.watson.ibm.com/library/Cyberdig.nsf/home. Research IBM Almaden · Austin · Beijing · Delhi · Haifa · T.J. Watson · Tokyo · Zurich A Systematic Approach to Designing Model Transformations Jochen M. Kuster¨ , Ksenia Ryndina and Rainer Hauser IBM Zurich Research Laboratory 8803 R¨uschlikon Switzerland jku,ryn,rfh ¡ @zurich.ibm.com Abstract forming them into a formal language [9]. Currently, a great deal of research is focused on the expression of model transformation Design and implementation of model transformations is one designs and appropriate tool support for model transformation de- key prerequisite for the vision of model driven development to be- velopers. This has led to the Query/Views/Transformation (QVT) come true. However, model transformations are quite different proposal by the Object Management Group (OMG) [21], which from other software artifacts since a model transformation design aims to provide a standardized framework for model transforma- typically consists of a set of transformation rules instead of object- tion development. oriented models such as class diagrams and statecharts. There- fore traditional software engineering approaches are not directly Many existing model transformation approaches favor that applicable for the development of model transformations. Never- transformations are captured in a rule-based way by a set of trans- theless, in the line of existing software engineering practice, model formation rules (see VIATRA [5], GReAT [13], UMLX [26], transformations must be developed in a systematic way in order to BOTL [4] and work by Milicev [17]). Although the actual form ensure their quality. In this paper, we present a systematic method of rules and rule application varies, the general idea is that a rule for designing model transformations, based on a case study ex- consisting of a left side and right side describes how a model is perience. In our approach, the developer initially produces high- supposed to be transformed. The left side is to be matched in the level transformation rules and then refines these to a complete low- source model and then this part is replaced by the right side of the level transformation design according to detailed guidelines. Fol- rule. Defining rules and in which order they should be applied can lowing our method allows systematic and iterative development of be considered as designing a model transformations. model transformations, resulting in quality implementations. In practice, software developers need more than a notation and tool support for capturing model transformation designs. A systematic process guiding the developer from the initial phases 1. Introduction of model transformation development all the way through to im- plementation is required. Traditional software engineering ap- The objective of the Model Driven Architecture (MDA) initia- proaches are not directly applicable, because model transforma- tive [1] is to make development of large and complex software sys- tions differ significantly from other software artifacts. While con- tems more efficient. This objective is achieved through increased ventional software designs usually comprises class and behavioral use of modelling during all software development activities. One diagrams, a model transformation design typically consists of a set important aspect of MDA is the widespread use of model transfor- of transformation rules. The primary challenge for the developer is mations between models constructed during system development. concerned with how to systematically design transformation rules, ensuring their completeness and correctness. Completeness en- Existing examples of model transformations include refactor- sures that all valid input models are considered by the transforma- ing [23, 25], transforming business process models into Business tion. Correctness includes syntactic correctness of the transformed Process Execution Language (BPEL) [10] and establishing con- models and also the preservation of semantic properties during a sistency of Unified Modeling Language (UML) models by trans- transformation. Further, systematic testing of the final transfor- mation implementation is also required. However, despite the de- mand for software engineering approaches tailored to the develop- ment of model transformations, almost no research work has been reported in this area. In this paper, we present a solution to the systematic design of model transformations. We distinguish between high-level, low-level design and design validation of model transformations. Within high-level design, the main ingredients of the transforma- 1 tion rules are captured informally and different cases for each rule the other parts of the business process. After receipt of this signal are discovered. These cases are divided into supported and unsup- at the accept event node, the token flow is passed to the action ¥ ported cases. In low-level design, the supported cases are grouped node ¥ . Action has the special feature that it has a streaming to low-level design rules which are subsequently expressed in a output pin, i.e. tokens are released already while it is executing. model transformation language. Design validation focuses on val- The business process terminates once a token reaches the global idation of syntactic and semantic correctness of the model trans- termination node. formation developed. The evaluation of our approach has been done using a significant model transformation that removes un- If business processes are to be deployed, their design models structured cycles from business process models as a case study. have to be transformed into an executable specification in a nota- tion such as BPEL [18]. Edges in activity diagrams can be used to The paper is organized as follows. First, we briefly describe the create so-called unstructured cycles or arbitrary jumps of control case study that we use for illustrating our technique. Then, we pro- flow, such as in the example. However, BPEL only supports struc- vide an overview of the development process for model transfor- tured flow constructs such as while-loops. As a solution to this mations. Thereafter we elaborate both on high-level and low-level problem, a model transformation removing all unstructured cycles design of model transformations. from activity diagrams needs to be performed before a BPEL spec- ification can be generated. For the basis of this transformation, a traditional compiler theory technique of T1-T2 analysis can be 2. Case Study: Transforming Business Pro- adapted to such normalization of activity diagrams [14]. cess Models Originally, T1-T2 analysis was introduced in order to detect Business processes are usually represented with graphical whether a directed graph is reducible [11]. It is based on two re- models using notations such as UML 2.0 activity diagrams [20]. duction rules [2]: Figure 1 shows a simple example of a business process. The busi- ness process shows simple action nodes ¢¤£¦¥ , a structured activ- 57685 T1: If 5 is a node with a loop, i.e. there exists an edge , ¨ © ity node (SAN) § containing actions and . Further, the pro- cess contains the usual start and end nodes, fork, join and decision delete that edge. nodes. Nodes within a business process are connected by edges via pins, which are organized into pin sets (also known as parameter T2: If there is a node 5 that is not the initial node and that has a 9 5 sets). This business process also makes use of advanced features unique predecessor 9 , then may consume by deleting 5 9 of UML activity diagrams such as a broadcasting, shown with the 5 and making all successors of (including , possibly) be broadcasting node sending a Cycle ended signal and the corre- successors of 9 . sponding accept event node labelled with Receive Cycle ended. These rules can be applied in any order until the so-called “limit # $ % & ' ( ) ! + , - . * flow graph” has been reached and none of the rules are applicable / 0 1 2 3 anymore. If the limit graph consists of a single node, the original graph is reducible, and otherwise the graph is irreducible. " The task of developing the required cycle-removal transforma- tion is to make the T1-T2 analysis applicable to activity diagrams. This means that the rules have to be adapted to preserve the be- havior captured in the activity diagram and must be described in terms of the syntax of activity diagrams, defined by the metamodel Figure 1. Example of a business process shown in Figure 2. Note that this figure shows a UML activity dia- The semantics of activity diagrams is based on token flow, the grams metamodel that was abridged and adapted for our purposes. basic idea of which is that an action receives tokens on its input The most essential elements of activity diagrams are ActivityN- pins and it starts to execute once all the pins in a pin set have odes and ActivityEdges that connect the nodes. We distinguish tokens available. During the execution of an action, the tokens between three different types of ActivityNodes, ControlNodes, from the complete input pin set are removed, an instance of the Actions and Pins. Actions are either simple such as CallAction action is created and executed, after which the results are placed or structured actions called SANs. A BroadcastAction and an on the pins of one of the output pin sets. Tokens are then released AcceptAction can be used to broadcast and receive signals, re- to the edges connected to that output pin set and the flow continues spectively. Pins are connection points for ActivityEdges and are through the rest of the process in this manner. In the example grouped into PinSets (instead of ParameterSets as in the origi- shown in Figure 1, the business process begins execution at the nal metamodel).