In this paper we apply the UML-RSDS notation and tools to the "Hello World"
case studies and explain the underlying development process for this model
transformation approach.Comment: In Proceedings TTC 2011, arXiv:1111.440

K. Lano

Louis Rose

Pieter Van Gorp

S. Kolahdouz-Rahimi

Steffen Mazanek

Electronic Proceedings in Theoretical Computer Science

English

arXiv

Crossref

Saying Hello World with UML-RSDS – A Solution to the 2011 Instructive Case

In this paper we apply the UML-RSDS notation and tools to the ``Hello World" case studies and explain the underlying development process for this model transformation approach

Directory of Open Access Journals

Van Gorp, Mazanek and Rose (Eds.):Fifth Transformation Tool Contest (TTC 2011)EPTCS 74, 2011, pp. 325–331, doi:10.4204/EPTCS.74.26Saying Hello World with UML-RSDS – A Solution to the 2011Instructive CaseK. Lano, S. Kolahdouz-RahimiDept. of Informatics, King’s College London, Strand, Londo, UK∗kevin.lano@kcl.ac.ukIn this paper we apply the UML-RSDS notation and tools to the “H llo World” case studies andexplain the underlying development process for this model transformation approach.1 Specification of model transformationsIn UML-RSDS a transformation specification is written in first-order logic and OCL, and consists of thefollowing predicates:1. A global specification,Cons, of a model transformation, expresses in a platform-independent man-ner the overall effect of the transformation, as a relation between the source and target models. Itis intended to hold true at termination of the transformation.2. A predicateAsmexpresses the assumptions made about the source and target models at the startof the transformation, for example, that the target model ismpty and that the source model issyntactically correct wrt the source language.The specification is therefore independent of any specific model transformation implementation lan-guage, and can be used as the basis for development in many such languages. By making explicit thesemantic assumptions on source and target models, the specification assists in the verification (formal orinformal) of model transformations.Conscan often be written inconjunctive-implicative form[3], as a conjunction of constraints of theform∀s : S·SCond implies∃ t : T ·PostwhereS is a source language entity andT is a target language entity. This pattern is applicable to re-expression transformations such as model migrations, and to abstraction and refinement transformations.The patterns assist in the derivation of explicit PSM designs from the specification, consisting ofa sequence ofphases, which apply specific rules or operations to achieve the specification constraints.Provided that the updates defined inPostdo not affect the data read inSCondor Post, and that the extentof S is fixed throughout the transformation(∗), then a constraint of the above form can be implementedby an iterationfor s : S do s.op()whereop implements the constraint for a particularSobject.This iteration constitutes a single phase in the design. Thepossible orderings of phases are deter-mined by defining a partial order over the target language entities: T1 < T2 if T1 is used inConsto define∗Research supported by the HoRTMoDA EPSRC project326 Hello World Case in UML-RSDSa feature ofT2 (or a feature of a subclass ofT2). Any phase that createsT2 instances must therefore bepreceded by all phases that createT1 instances.The restriction(∗) is termed thenon-interferencecondition.The iterative phase activities derived from the constraints are also terminating and they establish thetruth of their corresponding constraint, by construction.The PSM design is derived from the constraints,together with an executable Java implementation, using theUML-RSDS toolset [2]. The resulting ex-ecutable is a stand-alone implementation of the transformation, operating upon simple text format filesdefining input and output models.2 Simple transformation tasksHere we give the specifications and implementations of the simple transformation tasks in [1]. All ofthese tasks satisfy the restrictions described above, so they can be specified and designed directly inUML-RSDS.2.1 Hello world transformationThis has the global specification (Conspredicate):∃g : Greeting·g.text= “Hello” and∃p : Person·g.whom= p and p.name= “World”This predicate is coded in UML-RSDS as the only postconditionGreeting→exists( g | g.text = ‘‘ Hello” &Person→exists( p | g.whom = p & p.name = ‘‘ World” ) )of a use case which represents the transformation. From thisan implementation is automatically gener-ated in Java.2.2 Graph propertiesFigure 2 shows the basic graph metamodel in the UML-RSDS tools, and the generated design and Javacode of the specification.We assume that the following constraintAsm0 of the source model holds:∀g : Graph· g.edges.src ⊆ g.nodes and g.edges.trg ⊆ g.nodesThe queries are simple examples of abstraction transformations, and can be specified as follows:The constraintIntResult→exists( r | r.num = nodes→size() )on Graph expresses that for each graph there is a result object recording the number of nodes in thegraph. An operationop1() is generated to implement the constraint.Likewise for the other queries:IntResult→exists( r | r.num = edges→select(src = trg & trg 6= {})→size() )counts the number of looping edges in each graph, and is implemented by an operationop2().K. Lano, S. Kolahdouz-Rahimi 327IntResult→exists( r | r.num = g.edges→select(src = {} or trg = {})→size() )counts the number of dangling edges and is implemented by an iteration of an operationop3() on graphs.IntResult→exists( r | r.num = (g.nodes − (g.edges.src ∪ g.edges.trg))→size() )counts the number of nodes that are not the source or target ofany edge.− denotes set subtraction and∪ set union. This is implemented by an operationop4().We extend the final query problem by defining an auxiliary entity which records the 3-cycles in thegraph (Figure 1).GraphEdgeNode ThreeCyclename : String elements**cycles*111*edgesnodes*src 0..10..1trg* *Figure 1: Extended graph metamodelThe specificationConsof this transformation then defines how unique elements ofThreeCyclearederived from the graph, and returns the cardinality of this type in the end state of the transformation:(C1) :e1 : edges& e2 : edges& e3 : edges&e1.trg = e2.src & e2.trg = e3.src & e3.trg = e1.src &(e1.src∪e2.src∪e3.src)→size() = 3 ⇒ThreeCycle→exists1(tc | tc.elements= (e1.src∪e2.src∪e3.src) & tc : cycles)(C2) : IntResult→exists(r | r.num= cycles→size())Both constraints are onGraph.The order of nodes in a cycle is not distinguished byC1, if this was required thenelementsshouldbe ordered (a sequence). Because ofAsm0, each three-cycle will consist of nodes in a single graph. Theunique existential quantifier∃1 specifies that there must exist exactly one object satisfying the quantifiedproperties, ie, duplicated cycles are not included incycles.Each constraint is refined by a specific phase in the design. Theexists1 quantifier is implemented bychecking that there is no existingThreeCyclewith the required property, before creating such an element.An alternative approach would be to evaluate the set of threecycl s in a single expression:edges→collect(e1,e2,e3 | {e1,e2,e3})→asSet()→select(s |s→size() = 3 & s.src= s.trg)→size()but we consider that the approach usingThreeCycleis more clear.328 Hello World Case in UML-RSDS2.3 Reverse edgesThe global specificationConsfor this transformation is:src= trg@pre& trg = src@preon Edge. The suffix @pre denotes the value of the expression at the start of the transformation. This isthe usual style of specification for update-in-place transformations.2.4 Simple migrationThe metamodels for this re-expression transformation are shown in Figure 3, together with extracts fromexample input and output models (on the left and right hand sides, respectively).We make the additional assumptionAsm1 that the target model is empty at the start of the transfor-mation:ModelElement2= {}We can specify this transformation by three constraints, defined as the postconditions of a single usecase of the system:(C1) : Node2→exists(n2 | n2.id2= id1 & n2.text= name)(C2) : Edge2→exists(e2 | e2.id2= id1 & e2.text= “” &e2.src2= Node2[src1.id1] and e2.trg2= Node2[trg1.id1])C1 is a constraint onNode1, andC2 onEdge1. Node2[src1.id1] denotes the set ofNode2 objects withprimary keyid2 value in the setsrc1.id1.(C3) : Graph2→exists(g2 | g2.id2= id1 &g2.gcs= Node2[nodes.id1] ∪ Edge2[edges.id1])C3 is a constraint onGraph1. A design can be automatically generated from these constrai ts, thisimplements each constraint by a separate phase in a three-phas algorithm. The ordering of the phasesfollows from the ordering of the entitiesNode2 < Edge2 < Graph2 in the target language, based uponthe dependencies between these entities in the specification constraints (Edge2 instances depend uponNode2 instances, etc).2.5 Delete nodesThe global specification of this update-in-place transformation can be written as:edges→select(src.name= n1 or trg.name= n1)→isDeleted() &nodes→select(name= n1)→isDeleted()on Graph. The predicate also serves as the definition of an operationremove(s : String) of Graph thatimplements the transformation. Since edges depend on nodes, e ges are deleted before nodes (the reverseto the ordering used in construction of a model).K. Lano, S. Kolahdouz-Rahimi 3292.6 Insert transitive edgesThis can be considered as a simple example of a quality-improvement model transformation. Suchtransformations are typically update-in-place transformations, and have an associated quality measureQ : N on the models, used to show termination of the transformation. The transformation aims to reduceQ to 0 in the target model. In this caseQ is the number of pairs of distinct non-dangling edgese1, e2 ofthe source model withe1.trg = e2.src and with no existing edge frome1.src to e2.trg.Under the assumptionAsm2 that there are not already any duplicate edges in the graph:∀e1,e2 : Edge·e1.src= e2.src implies e1.trg 6= e2.trgthe specification of this transformation can be written as:(Cons) :e1 : edges@pre& e2 : edges@pre&e1.trg = e2.src & e1.src 6= {} &e1.trg 6= {} & e2.trg 6= {} ⇒Edge→exists1(e3 | e3.src= e1.src & e3.trg = e2.trg & e3 : edges)onGraph. This satisfies the non-interference condition (since the createde3 edges are distinct and are notincluded in the sets of edges being iterated over), so permitting an implementation using fixed iterations.If instead thetransitive closure R+ of R was required,Conswould useedgesinstead ofedges@pre, anda more complex implementation strategy would be required, using repeated iteration until a fixed pointis reached [3].3 ConclusionWe have shown that UML-RSDS can specify the case study transformations in a direct manner as high-level specifications, from which designs and executable imple entations can be automatically generated.UML-RSDS has the advantage of using standard UML and OCL notations to specify transformations,reducing the cost of learning a special-purpose transformation language. Our method also has the advan-tage of making explicit all assumptions on models (eg,Asm0 above) and providing global specifications(Cons, Asm) of transformations, independent of specific rules.Further work includes linking UML-RSDS to Eclipse/EMF to enable the use of ecore metamodelsand import/export of Eclipse/EMF models.References[1] S. Mazanek,Hello World: an instructive case for the Transformation Tool C ntest, in [5], 2011.[2] K. Lano, S. Kolahdouz-Rahimi,Specification and Verification of Model Transformations using UML-RSDS,IFM 2010.[3] K. Lano, S. Kolahdouz-Rahimi,Model Transformation Design Patterns, ICSEA 2011.[4] K. Lano, S. Kolahdouz-Rahimi,Model-Driven Development of Model Transformations, ICMT 2011.[5] Van Gorp, Pieter, Mazanek, Steffen, and Rose, Louis,TTC 2011: Fifth Transformation Tool Contest, Zürich,Switzerland, June 29-30 2011, Post-Proceedings, EPTCS, 2011.330 Hello World Case in UML-RSDSAppendix A: Transforming specific modelsSource and target metamodels are defined using the visual class di gram editor of UML-RSDS (Figures 2 and 3).Metamodels cannot contain multiple inheritance, and all non-leaf classes must be abstract. Metamodels can besaved to a file by theSave datacommand.Figure 2: Graph metamodel and queries in UML-RSDSSource models can be defined in text files, which are then read by the executable implementation of thetransformation metaclass, in a textual form. For example, at st model of the simple graph metamodel can bedefined as follows:g : Graphn1 : Noden1.name = "n1"n1 : g.nodesn2 : Noden2.name = "n2"n2 : g.nodese : Edgen1 : e.srcn2 : e.trge : g.edgesThis defines a single edge from the first to the second node. Altrna ive models can be defined in a similar way.The UML-RSDS toolset is located ath tp://www.dcs.kcl.ac.uk/staff/kcl/uml2web. UML-RSDScan be executed by the commandjava UmlTool. The directoryoutput is used to store metamodels, input andoutput models, and the generated Java code. The commandLo d dataloads a metamodel from a file (eg,mig2.txtfor the migration metamodel). The commandSynthesis Javagenerates the Java executable of a transformation,this generated executable is theController.java file in the outputdirectory. This can be compiled and usedindependently of the toolset.K. Lano, S. Kolahdouz-Rahimi 331Figure 3: Graph migration metamodels

http://doaj.org/search?source=%7B%22query%22%3A%7B%22bool%22%3A%7B%22must%22%3A%5B%7B%22term%22%3A%7B%22id%22%3A%22b391f91b2e75442b899a1d41456965dd%22%7D%7D%5D%7D%7D%7D

Saying Hello World with UML-RSDS - A Solution to the 2011 Instructive Case

Abstract

Similar works

Full text

Available Versions

Crossref

Directory of Open Access Journals