Domain Specific Languages with Graphical and Textual ... - CiteSeerX

Domain Specific Languages with Graphical and Textual Views Francisco P´erez Andr´es1 , Juan de Lara1 , and Esther Guerra2 1

2

Polytechnic School, Univ. Aut´ onoma de Madrid (Spain) (francisco.perez, jdelara)@uam.es Computer Science Department, Univ. Carlos III de Madrid (Spain) [email protected]

Abstract. We show our approach for the definition of Domain Specific Languages integrating both graphical and textual views. The approach is based on the meta-modelling concepts provided by the AToM3 tool. In this way, the language designer starts building the meta-model of the complete language. Then, he can select (possibly overlapping) subsets of the meta-model to define the different diagram types (i.e. language viewpoints). By default, the viewpoint is assigned a graphical concrete syntax, although a textual one can also be given. This is performed by selecting (or creating) triple graph grammar rules to translate from the viewpoint meta-model to a DSL called Textual that contains the most common elements of textual languages (such as expressions or operators). From a Textual model, a parser is automatically generated, where the semantic actions of the EBNF grammar are graph grammar rules, derived from the viewpoint meta-model. In this way, the parsing results in a model conformant to the viewpoint meta-model, which can be seamlessly integrated with other graphical and textual views.

1

Introduction

Domain Specific Languages (DSLs) are becoming increasingly popular in order to capture high-level, powerful abstractions of well-studied application domains. They are at the core of recent software engineering paradigms, like Model Driven Development. In this paradigm, models are the primary asset, from which code is generated, and DSLs are frequently used in order to configure the variable part of the final application. Specialized formalisms also proliferate in areas like modelling and simulation [7]. The increasing complexity of the systems to be described makes a common practice to split their specification into smaller, more comprehensible parts that use the most appropriate notation. We call Multi-View DSLs [8] to DSLs which are made of a family of graphical and/or textual notations each one of them used to describe the system under a different perspective or viewpoint. A prominent example of this kind of languages is the UML (but for a broader domain) [22]. In many cases, the multi-view language contains some portions that are more naturally expressed using text, while some others are inherently graphical. For

2

example the UML meta-model contains parts that are graphical (e.g. the portions corresponding to state machines or sequence diagrams), while others are more suitable for a textual representation (e.g. the part dealing with action semantics). Moreover, UML diagrams are usually enriched with constraints expressed in the textual language OCL [22], also defined through a MOF compliant meta-model, which in fact can be thought as a part of the UML infrastructure meta-model. The meta-modelling tool AToM3 [4] allows the description of Domain Specific Visual Languages (DSVLs) by means of meta-modelling and their manipulation by means of graph transformation. It has been recently enhanced in order to enable the definition of multi-view DSVLs [10]. This is done by first defining the meta-model of the complete language, and then selecting subsets of it (i.e. defining projections), corresponding to different viewpoints. The concrete syntax of the viewpoints (i.e. the visualization) is given by assigning graphical icons to each element in the meta-model. In this paper we present an improvement to this approach with the possibility of defining textual views. Following the meta-model centric approach of AToM3 , this is done by translating the meta-model of the viewpoint into a DSVL that we call Textual (by means of a Triple Graph Transformation System, TGTS). This language contains the main concepts for the specification of textual concrete syntax, such as expressions, operators or functions. From a Textual model, a parser is automatically derived that, given a textual specification, generates a model conformant to the original viewpoint meta-model. This is done by means of semantic actions which are indeed graph transformation rules derived from the meta-model. This is similar to the classical concept of pair grammars [19]. From these specifications, a customized environment is generated that allows the creation of instances of the different (graphical or textual) viewpoints. The tool creates a repository (an instance of the complete language meta-model) in the background that contains the gluing of all the views the user has created. In this way, both the textual and the graphical views can be seamlessly integrated for later manipulations. Paper organization. Section 2 introduces TGTSs. Section 3 overviews our approach for the definition of multi-view DSVLs. It introduces an example that is used throughout the paper, a DSL for object-oriented simulation [7]. Section 4 shows our approach for adding textual concrete syntax to meta-models, and for adding textual views to multi-view languages. Section 5 enhances the previous example with textual views. Section 6 compares with related research and section 7 ends with the conclusions.

2

Triple Graph Transformation

Graph transformation [6] is being intensively used for in-place transformations, like model animation and refactoring. In model-to-model transformation, a source model conforming to a source meta-model is transformed into a target model conforming to a different meta-model. For this kind of transformation, it is usu-

3

ally preferred a means to cleanly separate source and target models (as well as the meta-models), which allows establishing mappings between both models. Triple graph grammars (TGGs) [21] were invented by Andy Sch¨ urr as a means to translate and synchronize two different graphs (called source and target graphs) related by an intermediate graph (the correspondence graph). The nodes in the correspondence graph have morphisms to nodes in the source and target graphs. This structure is called triple graph and is represented as G = (Gs ← Gc → Gt ). TGG rules allow rewriting triple graphs, and are useful for modelto-model transformation, allowing incrementality and a certain degree of bidirectionality. This is possible as, starting from high-level, declarative TGG rules (like a creation grammar for a triple graph language) it is possible to derive so called operational rules with different purposes: source-to-target or target-tosource translation, incremental updates or model synchronization [15]. In [9] we used the idea of TGGs with a more complex graph concept, demonstrating that it forms an adhesive HLR category and thus can be used with the DPO approach to graph transformation [6]. In particular, we allow morphisms from nodes in the correspondence graph to reach nodes or edges in the other two graphs, or to be undefined. We also introduced the concept of meta-model triple, which allows typing a triple graph. We took advantage of the inheritance hierarchy (of nodes and edges) in the meta-model triple to define abstract rules, where an element in a rule can get instantiated with elements in the host triple graph having a concrete subtype of the original element’s classifier. In this paper, we use TGG rules, but we are not interested in bi-directionality, thus we work with operational rules. In order to avoid confusion we call these systems Triple Graph Transformation Systems (TGTSs). As an example, Fig. 1 shows a TGTS rule. The rule checks for a top-class (i.e. with no superclass, controlled by NAC1 ) in one of the graphs of the triple graph. If it is not related to an Abstract Expression instance in the other graph (NAC2 ), it creates one with the same name related with the class through a node of type Class2AbstractExpression in the correspondence graph. DSL Meta− NAC1 c:Class Model name = y (Abstract Syntax) abstract = true Corr. Graph Textual Concrete Syntax

:Class

NAC 2 c:Class name = y abstract = true

LHS

c:Class name = y abstract = true

:Class2AbstractExpression

RHS c:Class name = y abstract = true :Class2AbstractExpression

:Abstract_Expression

:Abstract_Expression

name = y

name = y

Fig. 1. Example TGTS Rule.

3

Multi-View DSVLs in AToM3

This section presents an overview of the AToM3 approach for defining multi-view DSVLs. In the first step, the designer defines the complete language meta-model,

4

and gives a graphical concrete syntax to its elements (i.e. icon-like appearance to classes and arrow-like to associations). Then, he defines the different viewpoints (diagram types) of the language. For each viewpoint, the multiplicity (i.e. number of allowed diagrams of this type) as well as the meta-model should be specified. The latter must be a subset of the complete meta-model. Thus, viewpoints are projections of the global meta-model containing a part of the classes, associations and attributes of classes and associations in it. A different concrete syntax (that overwrites the one given when defining the complete language meta-model) can be assigned to the elements in the viewpoint, and additional constraints can be given. Overlapping of different viewpoints is allowed, and consistency mechanisms based on TGTSs are provided by the tool [8]. A special viewpoint called “repository” contains the whole meta-model and is used for consistency checking purposes. Fig. 2 shows the definition of a multi-view DSVL in the object-oriented continuous simulation domain (i.e. a continuous simulation language, CSL). This kind of languages is made of classes representing entities in the system under study. Classes in a CSL may have properties, whose time evolution is specified by some simulation formalism. Traditionally, this specification has been made with textual equations. In our example CSL, the evolution is specified by combining state automata and textual equations. Window 1 at the background in Fig. 2 shows its complete meta-model, which defines simulation classes (class CSL Class) that can be connected through binary associations (association CSL association) and may form inheritance hierarchies (through association CSL parent). Associations in our CSL have role names and multiplicities for the endpoints. CSL Classes may have properties (i.e. attributes, class CSL Property) with a name, a type and an initial value. The behaviour of classes (abstract class CSL Behaviour) may be represented in the form of state machines (CSL StateAutomaton) or equations (CSL Equation). State automata contain states related through transitions that can be fired when one boolean property of the corresponding class becomes true. Equations are made of a left and a right hand side, both containing expressions (abstract class CSL Expression) made of binary operators (CSL BinOperator), functions with two (CSL Function2Parameters) or three parameters (CSL Function3Parameters), class properties and numeric values (CSL Value). Operators and functions have an enumerate attribute value with the possible operators and functions. We have included common arithmetic binary operators like “+”, “-”, “*” and “/”. For functions with two parameters, we have included as an example the “integral” function, which takes two expressions representing the initial value and the expression to be integrated. For functions with three parameters, we have included “instate”, which returns one of two expressions depending if the class is in a certain state (defined by a state machine), given by the third parameter. The tool shown in window 2 of Fig. 2 allows the declaration of the DSVL viewpoints. For the example, we have declared four viewpoints to describe the structure (classes, inheritance relations, associations and references to the behaviours they implement), the class properties, the state machines and the equa-

5

Fig. 2. Defining a Multi-View DSVL.

tions. Arrows from each viewpoint to the repository viewpoint contain automatically generated TGTS rules that will be used in order to build the latter from the viewpoint instances in the generated environment. Arrows from the repository to the viewpoints contain TGTS rules that propagate changes from the repository to the views when necessary. Thus, the working scheme of the final multi-view environment is similar to the model-view-controller pattern. Window 3 shows the attributes assigned to the structure viewpoint, such as its name and multiplicity (minCardinality and maxCardinality). One of the attributes is the viewpoint meta-model (shown in window 4), which is a subset of the whole meta-model in window 1. Fig. 3 shows (in window 1) the generated environment from the previous definition, which allows building instances of the defined viewpoints. For example, windows 3 and 4 show the editing of a state machine and an equation, respectively. Note that in the equation model we use class CSL Property without attributes pr type and initial value, as these make sense when declaring the properties but not when using them. Moreover, the name of a property is keyword (i.e. unique value) in property diagrams but not in equation diagrams or in the repository. The reason is that the properties of a class are declared in property diagrams – the fact that only one class can be included is a constraint of the viewpoint – and names should be unique. On the contrary, in the repository,

6

Fig. 3. Generated Multi-View Environment.

different classes may have equal names for attributes. Moreover, in one equation the name of a property can be referenced several times. Note also that in the equations viewpoint, we have changed the visualization of states and properties with respect to other viewpoints. Notice that in order to describe an equation a much more natural approach is to use a textual notation. Next section presents an improvement to the previous ideas in order to define multi-view DSLs supporting also textual viewpoints.

4

Specifying Viewpoints with Textual Concrete Syntax

This section presents our approach for providing a textual concrete syntax to meta-models. The overall architecture is shown in Fig. 4. The DSL designer starts by defining the language structure by means of a meta-model in step 1. If he wants to assign the DSL (or some of its viewpoints) a textual concrete syntax, he follows steps 2-9. With this purpose, we have defined a DSL called Textual with the most common concepts of textual languages (see section 4.1). In order to create a textual concrete syntax, a model conformant to the Textual metamodel should be provided (step 4 in the figure), together with a mapping to the DSL meta-model. This can be seen as annotations (expressed in Textual) for the DSL meta-model elements in order to produce the parser. This is similar to the concept of model marking proposed by the MDA [16]. The designer can either build the Textual model manually (together with mappings to the meta-model) or it can be automated with the help of predefined transformations (steps 2 and 3 in the figure) in the form of TGTSs (see section 4.2). In both cases,

7

the target Textual model contains mappings to the DSL meta-model elements from which the textual elements are derived. For this we use the concept of TGTS explained before. Once the textual model is obtained, an EBNF grammar for PLY (a lex-yacc parsing tool for Python)[18] is generated (step 5) using a code generator we have built (see section 4.3). The grammar contains semantic actions which are graph grammar rules derived from the original meta-model. From the EBNF specification, PLY generates a parser (step 6). In the generated environment, a textual program can be input (step 7), and once parsed, a model is produced (step 9) conformant to the original DSL meta-model by using the semantic actions (step 8).

Fig. 4. Architecture for Assigning Textual Concrete Syntax to Meta-Models.

Rationale of the Approach. The proposed process is very different from the one for textual languages, where the starting point is the definition of an EBNF grammar. On the contrary, we follow a meta-model centric approach, more in the style of the MDA paradigm [16], where the EBNF grammar is automatically generated from a higher-level model. According to [14], a number of arguments can be given to support this approach. First, in DSL engineering, one usually starts by working in the DSL abstract syntax, i.e., the meta-model. Later, it is decided whether a graphical or textual concrete syntax (or both) is appropriate. Starting with an EBNF from the beginning means starting from the concrete syntax. Second, the structure of the abstract syntax tree (AST) produced from parsing is not usually formally defined. This presents problems if such AST is to be integrated with a multi-view DSL, where other viewpoints are conformant to a meta-model. Certainly, we could left the DSL designer to

8

write the EBNF grammar (this in fact can be done in our approach by manually modifying the grammar produced in step 5). However, our aim is to provide higher-level mechanisms and automate the process, so that ideally, the DSL designer only has to “push a button” to obtain the textual concrete syntax (i.e. all steps in the definition of the DSL in Fig. 4 are automatic). The remaining of this section explains these steps in detail. First, subsection 4.1 introduces our Textual DSL. Subsection 4.2 explains the automation of the transformation from a meta-model into a Textual model. Subsection 4.3 explains how the parser is generated. Finally, subsection 4.4 shows how these ideas have been integrated with our multi-view approach. 4.1

The “Textual” DSL

The main idea for providing a textual concrete syntax to a DSL is to associate a Textual model to the DSL meta-model. The Textual DSL contains the most common concepts of textual languages. Its meta-model is shown in Fig. 5 and also considers the requirements for building a parser, e.g. the need for a grammar axiom and the representation of the elements making a textual expression (tokens in the parser), which are instances of Regular Expression subclasses.

ignored_symbols

Grammar_Specification

{ordered}

−name:string

Sequence

*

seq_delimiter

final_symbol

Expression

associates

Association initial_symbol

{ordered} sentences

*

1..* {ordered} Fixed RE

Concrete_Expression

type

−rexp:regularExpression −case_sensitive:bool 1..* Regular Expression

Abstract_Expression −name:string

args * arg1 arg2

pexpression *

Predicate

expressions

Operator −type:{prefix, infix, suffix} * −associativity:{left,right,nonassoc}

Real RE

Precedence

arg

Function −position:{in,out} −args_num:int

−type:{smaller,equal,greater} Integer RE

Boolean RE

oexpression

Binary Unary

Identifier RE f_initial_symbol String RE

f_delimiter f_final_symbol

Fig. 5. Meta-Model of the Textual DSL.

A valid Textual model consists of a unique instance of class Grammar Specification, which specifies a name for the textual syntax, and represents the axiom in the textual parser; a set of symbols to be ignored in the parsing process such as spaces or tabs (ignored symbols relation); and an ordered sequence of Sequence

9

objects. These represent a sequence of expressions detached by a delimiter, given by a fixed regular expression (Fixed RE, through association seq delimiter). Expressions can be concrete (Concrete Expression, an abstract class) or abstract (Abstract Expression). The latter can group different Concrete Expressions under the same type. Concrete Expressions can be Predicates or Operators, and are always represented by Regular Expressions, but Operators have always a fixed representation (Fixed RE). Depending on the number of arguments, an Operator can be Unary, Binary or Function. Moreover, it is possible to specify the operator’s precedence, associativity (left, right and nonassoc), and its location with respect to operands (prefix, infix, suffix). Operands are instances of Expression or of its subclasses. Predicates are represented by one or more predefined Regular Expressions (i.e. concrete subtypes of it). Note that it is a parser requirement that there is only one instance of each type of Regular Expression, apart from Fixed RE. However, that does not mean that it is only possible to assign one different subtype of Regular Expression to each different Predicate. 4.2

Transformation into “Textual”

The process of generating the Textual model associated to the DSL is shown in steps 2 and 3 of Fig. 4. In step 2 the designer selects a Textual transformation among the ones predefined in the transformation data-base. This data-base can be extended with new transformations. These can be adapted to better fit the source meta-model and consist of a set of TGTS rules, appropriate for different kinds of languages. In step 3, the application of the transformation results in the Textual model associated with the DSL meta-model through a correspondence graph. By now, we have defined two kinds of transformations. The first one, is a generic transformation called Constructor/Connector, which for each class creates a constructor function with as many arguments as attributes the class has (the textual language it generates is similar to HUTN-like languages [11], see section 6). The result of these functions is stored in variables. For each association (i.e. connection) another function is created with two arguments for the source and target and an extra one for each attribute the association has. The second transformation is specific for languages containing expressions composed of operands and operators (e.g. mathematical or logical expressions, like the meta-model of the equation viewpoint in the example). Expressions can be seen as hierarchical trees, where leaves contain the relevant data in a particular attribute. In the case of operators, the relevant attribute contains the allowed operators (a single value or an enumerate type). In the case of operands, the type of the attribute gives us the kind of operand. These classes can also have connections with other classes (usually the root expression class), which determine whether they are considered predicates (zero connections) or operators (one or more connections). This way, this second transformation creates Abstract Expressions for each abstract class which is not a leaf of the hierarchical tree, and Predicates, Unary Operators, Binary Operators or Functions, depending on the number of output

10

NAC 1

c1:Class

NAC 2

:Class

LHS

c1:Class

RHS

c1:Class

c2:Class

c2:Class

c0:Class

c2:Class

c0:Class

c2:Class

name = y abstract = false

name = x

name = y abstract = false

name = x

name = y abstract = false

name = x

name = y abstract = false

c2a:Class2 AbstractExpression

:Class2 ConcreteExpression

c2a:Class2 AbstractExpression

c2a:Class2 AbstractExpression

:Class2 ConcreteExpression proc = 0

Text.Conc. Syntax DSL Meta−Model (Abstract Syntax)

c1:Class

c0:Class

Corr. Graph

DSL Meta−Model (Abstract Syntax)

connections. These languages frequently associate expressions, so we have included a rule to generate an instance of Association over the main Abstract Expression. We now show some sample rules for this transformation. For clarity, we have used a simplified concrete syntax for the DSL meta-model and not the abstract syntax of the UML meta-model (e.g. we include inheritance relations, instead of meta-class “generalization” and so forth). The first rule was shown in Fig. 1 and creates an abstract expression in the Textual model for each abstract class in the DSL meta-model. The upper rule in Fig. 6 creates a unary operator for each class in the DSL meta-model which has a unique association (NAC1 ) and which is the child of a class related to an abstract expression. The rule at the bottom creates a semantic action (i.e. a graph grammar rule) for each possible value of the unary operator (i.e. for each value of its x property). Each semantic action is associated to the mapping in the correspondence graph, and identified by attribute order. The rule implementing the action semantics has been depicted using a compact notation with its LHS and RHS together (the created elements are marked as “{add}”). It creates an instance of the class “y” (i.e. the class with role unary operator), and initializes the value of the attribute (named x). Moreover, the generated semantic action also connects the unary operator to the appropriate object (an instance of the class connected with class “y”). The semantic actions, stored in the correspondence graph nodes, will be used to build the parser. An example of generated semantic action is shown in Fig. 9. Note that in the correspondence graph, we may have nodes with attributes as well as relations between them. Therefore the implicit mappings of transformation language proposals like QVT [20] are not enough for us.

ae:Abstract_Expression

: type

:Unary

name = x

LHS

c2 :Class

p :Property name = x type = enum value = w

c1 :Class name = y : attribute abstract = false

name = z a :Association

ae:Abstract_Expression

ae:Abstract_Expression

name = x

name = x

RHS p :Property name = x type = enum value = w

: type :Unary associativity = left type = infix

c2 :Class c1 :Class name = y : attribute abstract = false

name = z a :Association name = v

name = v

Semantic Action Rule y+str(proc)

Textual Concrete Syntax

Corresp. Graph

:y c2c :Class2 ConcreteExpression proc = p

Attribute Condition p