Model Transformation (MT) is an important operation in the domain of Model-Driven Engineering (MDE). While MDE continues to be further adopted in the design and development of systems, MT programs are applied to more and more complex con gurations of models and relationships between them and grow in complexity. Structured techniques have proven to be helpful in design and development of programming languages. In this paper, using an example, we explain an approach in which MT speci cations are de ned in a structured manner, by distinguishing queries as their main building blocks. We call the approach Query Structured Transformation (QueST). We demonstrate that the contents of individual queries used in QueST to de ne a transformation are dispersed all over the entire corresponding MT de nition in ETL or QVT-R. Our claim is that the latter two languages are less supportive of a structured approach than QueST. Finally we discuss the promising advantage of QueST in MT de nition, and possible obstacles towards using it.
As the adaption of Model-Driven Engineering (MDE) in the design and
development of systems increases in industry, the complexity of Model
Transformation (MT) programs |basic MDE operations which transform models to other
models| also increases. Structured approaches already have proven to be
successful in managing the complexity of systems; for example, the shift from
programming with goto statements to the structured programming paradigm has
proven to be a good design decision, which undoubtedly improved the quality of
the software produced. Following this principle, we propose a Query Structured
Transformation (QueST1) approach for de ning model transformations which
are translating source models to target models. QueST approach is originated
from [
The paper is organized as follows: in the next section we introduce the metamodels for the class-to-table example, and informally describe the transformation rules. In Section 3, we explain the structural components of the class-to-table example in QueST, and provide a mathematical de nition for a number of these components. Then, we explain how the QueST engine would execute the MT definition. In Section 4, we brie y discuss program building blocks in QVT-R and ETL, and demonstrate the dispersal of the contents of the QueST components (i.e., queries) in the MT de nitions corresponding to the same class-to-tables example in these languages. In Section 5, we brie y discuss the reasons for the query dispersals, and also promising advantages of using QueST. Section 6 concludes the paper and mentions potential future research. 2
Class diagram to database schema MT Metamodels specify valid instances of domains, and are the focal point of MT de nitions in QueST. We rst brie y describe the source and target metamodels of the class-to-table example and then de ne the MT in QueST based on them. 2.1
Metamodels Metamodels of the class diagram (CD) and database schema (DBS) specify the valid model spaces of the CDs and DBSs, respectively. Fig. 1(a) exhibits the CD metamodel. Each class contains some attributes associated to it by atts; each attribute has a type and a multiplicity (Lbound and Ubound). Each class might inherit at most one class (parent arrow). Associations have multiplicity like Attributes and connect src classes to trg classes.
Fig. 1(b) shows the metamodel of the DBS. Each Table has at least one Column (see cols in the gure). Some columns are primary keys for the table (pKeys). A table might also have some foreign keys (Fkey). fKeys associate these foreign keys to tables. Each FKey refers to one table (refs) and some columns (fCols).
The constraints associated with the metamodels are exhibited using red labels with enclosing brackets. The multiplicities on the arrows are also constraints and therefore they are in red and are included inside brackets. Constraints can be written in any suitable language by interpreting squares as sets and arrows as binary relations. [isAbstract] speci es that NamedElement is abstract. [noLoop] speci es that there is no loop in the inheritance hierarchy of classes. [pKeysInCols] states that the primary keys are columns of the same tables. [FKeyColIsValid] states that the columns to which each foreign key refers are subset of table columns of which they are a part (i.e., fKeys;fCols cols).
[isAbstract]+
There are di erent ways to translate a CD to a corresponding DBS [
Fig.2(a) shows a class diagram and Fig.2(b) shows its corresponding DB schema, following the rules speci ed above. In Fig.2(b), FK in parenthesis in front of a column indicates that the column is a foreign key and its outgoing arrow is referring to the table that this foreign key is referring to. As exhibited in the gure, the two tables takes and teaches are created due to the corresponding two multi-valued associations and the table telephone is created due to the corresponding multi-valued attribute. 3
QueST: Query Structured Transformation approach In a typical MT language, like ETL or even QVT-R, the MT designer thinks in the following way: how does each pattern in the source model produce a collection of elements in the target model? But QueST assumes a di erent manner of thinking. The question that the MT designer is required to think about when SID& Student& parent:PersonPK&&&&(FK)& StudentPK' (a)& (b)&
Fig. 2. A class diagram and its corresponding DB schema starting to specify an MT in QueST is the following: from which elements of the source model is each element of the target model generated? This arises from the observation that the target model information is somehow hidden inside the source model and the model transformation program functionality's purpose is to reveal this information by manipulating the information inside the source model and creating the target elements out of the resulting information; for example, according to the MT rules speci ed in Sec. 2.2, tables in DBS are generated in three di erent cases: 1) for each class 2) for each multi-valued attribute and 3) for each multi-valued association. This can be speci ed by de ning a query on the CD metamodel. The blue square with a diagonal corner named QTable in the right hand side of Fig.4 represents this query and Fig.3(a) exhibits this query de nition in mathematical notation. The plus notation in the query means disjoint union. After this query de nition, we associate the Table element in the target to this query (the green arrow from Table to QTable in Fig. 4).
QTable⌅$ Class+&mvA*&+&mvAssoci,&& & & & & where& & & & & & & & &mvA*={A*:&A*ribute&|&A*.Ubound&>&1}& & & & & & & & &mvAssoci={&Associ:&AssociaAon&|&Associ.Ubound&>&1}&
QColumn=&Class&+&svA*&+&CoParent&+&svAssoci&+& &&&&&&&&&&&&&&mvA*&+&mvA*&+&mvAssoci&+&mvAssoci&& & & & &where& & & & & & & & &coParent=CoDomain&(parent)& & & & & & & & &mvA*={A*:&A*ribute&|&A*.Ubound&>&1}& & & & & & & & &mvAssoci={&Associ:&AssociaAon&|&Associ.Ubound&>&1}& & (a)$ (b)$
QTable& From the transformation specreistr(cR)a$:=t$reisotrnicB,onw$of$eR$onvere$speedcifietd$ocodomgaiun.$re out how the columns inv(R)$:=$inversion$of$relaBonq$R.$uestions for all the other entities are generated, and continue to anid$:s=$wideenBrty$fsuinmcBoni.l$ar (including squares and arrows) in the target metamodel. This method of thinking is the cornerstone in writing an MT in QueST. Therefore, based on the MT speci cation, we write a query like the one shown in Fig. 3(b) for the Column entity and name it QColumn. This query is simply specifying all the possible ways leading to the generation of a column based on the MT speci cation rules. Then we associate the Column in the target metamodel to this query (see Fig. 4).
We apply the same method for the associations between the squares in the target metamodel. Hence we draw an arrow between the QTable and QColumn (see purple arrow called Qcols in Fig.4) and associate a query to this arrow. The query de nition for this arrow is de ning the relation between the elements of the QTable and QColumn. That is the disjoint union of all the arrows which are indexed from one to eight in Fig.3(c); restr(atts) is restriction of the atts relation over the svAtt co-domain; inv(src) is the inverse of the src relation, and id arrows are the identity relQatiuonesoSveTr &their domains. The , and F signs on the Qtable, Qcol(QanuedryQ&SCtorulcutumrnedin&Trtahnissformgua3reonw)&ill be used for comparison purposes in Section 4.
If we continue the above process of query de nition and linking, for the other elements of the DBS metamodel, we will arrive at the structure shown in Fig.4. The entire gure shows the de nition of the class-to-table MT in QueST. The new green elements called QFKey, QpKeys, Qrefs, QfKeys, and Qfcols are all new queries. Their de nitions are not shown in the gure due to space limitations, but they are de ned in a similar way to the queries de ned in Fig. 3. We call the source metamodel with query annotations an augmented source metamodel. The augmented CD metamodel is shown in the left hand side of the Fig. 4. As it is shown by the dotted enclosing polygon in the gure, the structure of the target metamodel is somehow replicated in the source metamodel. The association links from the DBS to the CD metamodel show how the DBS metamodel is associated to the augmented CD metamodel. Not all the individual links are shown in the gure; instead a large blank green arrow is used to represent all the links. This linking from the target to the source is total.
From the MT de nition in Fig. 4, it is seen that the building blocks of an MT de nition in QueST are the queries on the source metamodel, and the links which associate the elements of the target metamodel to these queries (like QTable) or the source metamodel elements (like NamedElement). This provides a wellformed structure for the model transformation de nition; the query de nitions are encapsulated inside the squares and arrows, and are independent of each other, and tracing back (by the association links) from the target elements to the augmented metamodel shows how the transformation de nition for each entity in the target metamodel is de ned. In Section 4 we show how these queries are represented in ETL and QVT-R. For a given class diagram, like the one in Fig.2(a), the QueST engine rst starts executing the queries of the augmented CD metamodel over the given class diagram. The order in which the queries are executed does not matter semantically, so the execution of the queries can be scheduled in any order by the QueST execution engine. This enables the engine implementation with the possibility of applying any appropriate optimization mechanism over the execution of the queries at the implementation level.
The collected elements from the execution of each query are then typed over that query. For example, Fig 5 shows the elements generated by execution of the QTable query that are typed over it (see :QTable square in Fig 5). The incoming dotted arrows to the :QTable square show from where each element of the square is coming. After all queries are executed, the next step for the QueST engine is to produce the taget elements. This is done by replicating the elements collected by the queries and changing their types according to the association links in the MT de nition; for example, for the QTable query, the engine rst duplicates all the elements collected inside the :QTable square and changes their types to Table, since the Table entity is associated to the QTable by a link in the MT de nition, as in the previous section. The outgoing dotted arrows from :QTable connect the elements to their replicated versions which are all typed over the Table element (or simply are tables in DBS).
The process described for the QTable query in the previous paragraph continues for all other queries and its completion leads to the generation of the target model shown in Fig 2(b) .
Person'
((((((((((((((((((((((((((('
name:'String'[
Query dispersal in ETL An MT in ETL is speci ed by a set of rules. Each rule de nes how an element of a speci c type is translated to one or more elements (not all necessarily having pre { Clas Diagram To DB Schema MT in ETL.etl "Run ing ETL".println(); } var dbschema : myDB!DBSchema; rule Clas Schema2DBSchema transform c : myO !Schema r}uttloreadtCnb:lssmafcysohDreB2mm!TacDa=Bbt:Sl;cemhyeOma!{Clas to t:myDB!Table, pk:myDB!Column{ dbschema.tables.ad (t); dbschema.tables.ad (pk); t.name=c.name; pk.name=c.name+"PK"; pk.type="INT"; t.cols.ad (pk); t.pKeys.ad (pk); if (not (c.parent=nul ) { var col:new myDB!Column; col.name="parent-"+c.parent.name+"PK"; col.type="INT"; t.cols.ad (col); var f:new myDB!Fkey; f.fCols.ad (col); t.fKeys.ad (f); } f.ref=c.parent.getCor Table(); for i(fa (:a.muybOou!nAdt =ri1bu)t{e in c.at s) {
Page 1 1" 1" ⌅ F 3" F 1" 3" ⌥ ⌥ the same typ e) in the target mo del. The rules might have guard expressions that constrain their application.
Fig. 6 shows the co de for de ning the class-to-table example in ETL. Intentionally, the co de font size used is very small in the gure, since we will not discuss in detail each part of the de nition, and instead, we only take into account the entire transformation de nition to show the disp ersal of the QueST queries all over it. The parts in Fig. 6 that corresp ond to the queries in Fig.3 are marked: 1) marking the parts corresp onding to the generation of tables ( QTable query); 2) F marking the parts corresp onding to the generation of columns ( QColumn query) and 3) marking the parts which asso ciate the columns to the tables (Qcols Query). The numb ers ab ove the markings corresp ond to the numb ers in Fig. 3(c) for each marking; for example, 2 refers to the mvAtt comp onent of the QTable, and 3 and F3 refer to the parent arrow of Qcols, and the coParent comp onent of QColumn, resp ectively.
As the gure shows, each marking sign is disp ersed over the entire co de. This means that di erent comp onents of the queries in Fig 3 are disp ersed all over the co de in ETL; for example the eight comp onent of the Qcols which are indexed from one to eight are scattered throughout the entire de nition and among the di erent rules.
We avoided marking all the queries that are generating the target elements
in the de nition of Fig. 6 to keep the gure simple. However, by rep eating the
marking pro cedure for all of the other queries, we would get a similar disp ersal of
their content over the entire co de. One immediate consequence of these disp ersals
is the di culty that o ccurs during the debugging pro cess in the development of
the mo del transformation; since the user needs to check di erent parts of the
co de, if he gets some errors regarding generation of sp eci c element in the target.
4.2 Query disp ersal in QVT-R
An MT de nition in QVT-R is comp osed of a set of top and non-top relations.
The di erence is that the latter relations are invoked by the former ones. Each
relation de nition sp eci es how some elements in the source mo del are related
to some elements in the target mo del. There are when and where clauses which
act as pre- and p ost-conditions for the execution of the corresp onding relation
[
Clas Diagram To DB Schema MT in ETL.etl a.src.getCor Table().cols.ad (c); f1.fCols.ad (c); f1.ref=a.trg.getCor Table(); o}o}ppreeerr/vtaaaautt.trriisbnoortsnncmb..mmyspgyyO:reBOOita!nCg!!Cto=CAllrltansas(Tesr)ali.;bfbal.guleeet(qte()uC).iog.fvresKateelTOlyeawesnbnc.tlitasenOd((gn")Ce(C:l(flac1ams|)syc;D(.2B)aT!taT:baslbm.elyi"eOn)c.{!lfCulldaaetss(seen{l(f)); ; var t:myDB!Table=nul ; for (k in tbs){ if (k.isTypeOf(myDB!Table) { } } t=k; } return t; 4" ⌥ Page 4 wrote a transformation in for the same class-to-table example, and perform the same analysis over the code as we did in the previous section for the ETL de nition. the queries generating the elements of a speci c type are spread between di erent rules/relations.
Arrows are secondary elements.
References to arrows in
MT de nitions in ETL and QVT-R happen by means of nodes; queries only de ne nodes, and arrow de
nitions are implicit inside these queries. More concretely, it is not possible to or de ne an arrow as a target of an ETL rule (i.e., as a rule header parameter), as a domain of a relation in
QVT-R. This means that if the queries generating nodes are dispersed, then the queries for generating the arrows which are referenced by these nodes everywhere close to the F signs in Fig. 7 show this phenomenon. Flattening the graphical structure. ETL and QVT-R are textual languages, while as it may be seen from the Fig. 4, MT de nitions contain graphical constructs. A representation of a graphical construct in a textual format causes a scattering of references to the graphical elements, inside the representation; for example a node with several incoming edges in a graph would be inevitably referenced in di erent places in the graph's textual representation. MT design and development. As is shown in Section 3, QueST provides well structured de nitions by encapsulating queries inside squares and arrows, i.e., the rst class elements of the metamodeling language. All the target elements of a speci c type (type could be an arrow or a square) are generated by one, and only one, query. We believe that this is helpful in development and debugging of MT de nitions, because it follows the well-known principle of separation of concerns, where the concern is the production of elements of speci c type. Further, each query de nition is fairly independent in QueST, i.e., square queries are independent, and arrow queries are only dependent on their corresponding source and target queries; Hence, QueST's structural construct, the query, suitably provides a pattern to decompose complex MT de nition tasks into small fairly independent de nitions.
Semantic foundations. The mathematical foundation of the QueST approach
is already discussed in some other work [2{4, 6]. This ensures that there is a
clear and formal understanding of QueST. This would prevent some ambiguity
and semantic issues like the ones investigated for the QVT-R speci cation [
Flexibility in query language. Theoretically, any query language can be used for de ning the queries in QueST. The expressive power of QueST depends on the expressive power of the chosen query language. We insist that the chosen query language should consider the arrows as equally as important as the nodes; the experiments of using QueST for MT de nitions have shown that de ning the square queries are easy in some query languages like OCL, but de ning arrow queries are fairly complicated, because they necessarily include many references to the source and target of the arrow.
Declarative vs. imperative. QueST is declarative: the de nitions of its structural building blocks (i.e., queries) provide speci cations rather than implementations for the generation of the target elements. Further, the queries could be executed in any order in QueST. The advantages of declarative approaches in programming languages is less debatable now; even though the traditional challenges of training MT programers to think declaratively might still be an obstacle, considering the number of people who are trained to write queries declaratively, in the database community, it might be plausible enough to follow a similar pathway in the MT community as well.
Conclusion From one perspective, the intent of MT programs is to collect information from the source model by executing some queries, and, then, to build up the target model elements. Formalizing this procedure suggests a structural pattern for model transformation which we call QueST. In QueST, the MT de ner should think in a target-oriented manner, in the sense that he should de ne a query for each individual element in the target metamodel, during the MT development process. These queries de ne the generation of target model elements, and are encapsulated inside the fairly independent components which make up the structural building blocks of an MT de nition in QueST. We used a well-known class-to-table example to explain these structural components (i.e., queries) and their de nitions. We also demonstrated that the contents of these queries are necessarily dispersed all over the entire MT de nitions written with ETL and QVT-R. Subsequently, we discussed how the dispersal of each query is not a speci c property of the implemented examples and could be generalized to any programs written in QVT-R and ETL. Finally, we discussed the advantages of QueST from di erent perspectives. A deeper examination and evaluation of QueST, regarding the aspects discussed in the previous section, is the subject for our future work.