• Abstract and Figures
• Public Full-text

A Domain Specific Transformation Language Bernhard Rumpe and Ingo Weisem¨oller Software Engineering RWTH Aachen University, Germany http://www.se-rwth.de/ Abstract. Domain specific languages (DSLs) allow domain experts to model parts of the system under development in a problem-oriented no- tation that is well-known in the respective domain. The introduction of a DSL is often accompanied the desire to transform its instances. Although the modeling language is domain specific, the transformation language used to describe modifications, such as model evolution or refactoring operations, on the underlying model, usually is a rather domain inde- pendent language nowadays. Most transformation languages use a generic notation of model patterns that is closely related to typed and attributed graphs or to object di- agrams (the abstract syntax). A notation that reflects the transformed elements of the original DSL in its own concrete syntax would be strongly preferable, because it would be more comprehensible and easier to learn for domain experts. In this paper we present a transformation language that reuses the concrete syntax of a textual modeling language for hier- archical automata, which allows domain experts1 to describe models as well as modifications of models in a convenient, yet precise manner. As an outlook, we illustrate a scenario where we generate transformation languages from existing textual languages. Keywords: domain specific languages, model transformations. 1 Introduction and Problem Statement Domain specific languages (DSLs) have the advantage of allowing domain experts to model parts of the system in a problem-oriented notation that is well-known in the respective domain. Like most documents in software development processes, models in DSLs underly frequent changes. These may include refactorings, au- tomated modifications, or complex editing operations. Change operations on models can be described in explicitly defined model transformations. To define a model transformation, we need an appropriate transformation language. Today’s transformation languages [7] however operate on the abstract syntax and thus look very different from the DSL to be transformed. In the following sections, we are going to present an approach to close this gap. 1 In our wording, the term “domain” refers to application domains such as business processes or a discipline of engineering as well as to technical domains such as rela- tional databases or state based systems. [RW11] B. Rumpe, I. Weisemöller A Domain Specific Transformation Language In: ME 2011 - Models and Evolution, Wellington, New Zealand. Ed: B. Schätz, D. Deridder, A. Pierantonio, J. Sprinkle, D. Tamzalit, Wellington, New Zealand, Okt. 2011. www.se-rwth.de/publications If the user wants to keep the look-and-feel of the DSL within the transfor- mation language, then this language needs to embody elements of the concrete syntax of the underlying DSL, and is thus domain specific itself. Consequently, instead of having a single language for transformations of models in arbitrary DSLs, we would prefer a syntactically fitting transformation language that pro- vides the same look-and-feel as the DSL at hand. In this contribution, we state that the concrete syntax of a textual DSL can be reused to describe transformation rules, thus providing this look-and-feel. We substantiate our claim by the introduction of a transformation rule used in the process of flattening hierarchical automata and of the corresponding transfor- mation language. Because the elements of the transformation language depend on the elements of the automata language in a systematic manner, we believe it is possible to systematically if not automatically derive the transformation language from a given DSL. The following sections are outlined as follows: In Section 2 we provide a brief introduction to graph based model transformations, based on a rule used in the process of flattening hierarchical automata. We are going to reuse this example in the subsequent sections. Section 3 gives an introduction to existing approaches to the definition of model transformations in a domain specific notation. In Section 4 we explain what transformation rules in concrete syntax look like. In Section 5 we summarize the previous sections and give an overview of our ongoing and future work in this area. 2 Abstract and Concrete Syntax in Transformations In the following, we consider transformation rules to be small steps of transfor- mation in an appropriate language, which may be composed to more complex transformation sequences by control structures or rule application strategies. Composition mechanisms may vary (cf. [7, 17]), whereas we encounter some kind of transformation rules in almost any transformation language. Therefore and for reasons of space, we leave composition mechanisms out of consideration. Instead, we focus on the notation of transformation rules. In graph based transformation approaches, rules consist of a left hand side (LHS) and a right hand side (RHS), which describe excerpts from a model that the transformation can be applied to (see [15, 12]). Informally explained, the LHS describes a part of the model before the application of the transformation rule, whereas the RHS describes the same part of the model after the rule application. Because we basically describe excerpts from models, i.e. instances of a mod- eling language, in the LHS and RHS of a transformation rule, it seems natural to reuse the syntax of the modeling language when describing transformation rules. In current transformation approaches however, this reuse is limited to the abstract syntax for a variety of reasons, which means that the concrete syntax of the modeling language is not reflected in the transformation language. We are going to show the difference between reusing the abstract syntax only and reusing both abstract and concrete syntax based on a transformation rule for hierarchical automata. The rule we consider is used in the process of flattening hierarchical automata, which is a simplified case of the transformations for flattening UML state machines (cf. [18, pp. 227 ff.] for details). equivalent off off automata switchedOn switchedOn operating operating starting ⇔ starting 1 state off; state off; 2 3 state operating { state operating { 4 state starting <<initial>>; <=> state starting; 5 }} 6 7 off -switchedOn> operating; off -switchedOn> starting; Fig. 1. Equivalent automata in graphical and textual representation Before investigating the transformation rule itself, we take a look at the syntax of the DSL for hierarchical automata. Figure 1 shows both a graphical and textual representation of a hierarchical automaton on the left, and a graphical and textual representation of a semantically equivalent automaton on the right. The automaton on the right is obtained from the one on the left by forwarding the transition to the nested initial state. The upper part of the figure shows the automata in a graphical syntax, whereas the notation in the lower half is a textual representation of the same automata. A model transformation rule that can transform an automaton on the left into the equivalent automaton on the right consists of two parts: a LHS, which matches a part of the automaton similar to the left side of Figure 1, and a RHS, which specifies the replacement, and which is similar to the right side of Figure 1. We ignore the RHS of the rule for the moment and take a look at the pattern matching part on the left only: Figure 2 shows the difference between a pattern based on the abstract syntax of the textual DSL from Figure 1, and the same pattern in a notation based on the concrete syntax of that language. The language of the object diagram pattern in the upper part of the figure reuses the abstract syntax of the automata DSL. The same applies to the second notation (which we did not define explicitly, but is inspired by MOF QVT [11] and OCL [10]). Please note that these patterns are written in pseudocode rather than being executable by some tool, but they depict the general style of trans- formation languages based on the abstract syntax. UML object diagram s2: State : StateHasSubstates substates s1: State t1 : Transition s3: State :Outgoing :Incoming initial = true : TransitionHasLabel e: Label Automaton pattern in OCL-like abstract syntax 1 s1 : State; 2 s2 : State; 3 s3 : State; 4 t : Transition; 5 e : Label; 6 7 s2.substates->contains(s3); 8 s3.initial = true; 9 t.source = s1; 10 t.target = s2; 11 t.label = e; Automaton pattern in concrete syntax 1 state $source; 2 3 state $outer { 4 state $inner <<initial>>; 5 } 6 7 $source -$event> $outer; Fig. 2. Three variants of the LHS of a rule for transition forwarding The statements in this pattern are either declarations of typed objects (ll. 1-5), links (l. 7) or additional constraints for these objects (ll. 8-11). In comparison to this, the pattern based on the concrete syntax of the DSL, which is shown in the lower part of Figure 2, is more compact and easier to read. This is because the transformation language used here is close to the underlying modeling language rather than based on lists of objects, links and constraints. The pattern matching language differs from the modeling language itself mainly in the use of schema variables such as $source that act as placeholders for concrete elements from the model. 3 Related Work A number of publications addresses the specification of model transformations in a notation close to or identical to the corresponding modeling languages. This is usually referred to as transformations in concrete syntax, for instance by T. Baar and J. Whittle [3] as well as by M. Schmidt [19]. We will adopt this term for the remainder of this paper. Both publications mentioned above adapt the concrete syntax of visual mod- eling languages for the specification of transformation rules. In either approach, the adaption of the syntax is performed manually. To our best knowledge, there is no implementation of either of these approaches available.

Load more

  10

Copy Link