In Model Driven Engineering (MDE), models and mappings play a key role in system design. However, in practice, models and mappings do not exist in isolation, but are combined to form systems of interrelated models. We call the trace of operations, such as model transformations or model merges, between an initial con guration of a system of interrelated models to a nal one, a work ow. Current approaches for using work ows in MDE exist, but are generally informal and do not properly address traceability and veri cation. In this work, we propose a structured method for de ning work ows for model management, which automatically ensures traceability and inherently enables veri cation. This approach also sets the stage for de ning a declarative work ow language, which we believe can aid in validation. Through this framework, comparison and optimization of work ows is possible, as they are represented as algebraic terms in a mathematically de ned language. Finally, the framework gives rise to multiple levels of abstraction, making it exible enough to be used at di erent stages of the system design, while enabling better work ow readability and maintainability.
Model Driven Engineering (MDE) focuses on the use of models and
mappings between them to drive the software development cycle. However, models
and mappings do not exist in isolation, but are combined to form systems of
interrelated models, that are chained through the use of operations, to form
workows that ful ll a given intention in the software design. Forming such chains
is therefore a natural step in MDE to enable the description of the composition
of activities in software construction and provide explicit means for MDE
automation [
Zinovy Diskin, and Dr. Richard Paige for their supervision in this work.
However, in order to stay faithful to the MDE philosophy, work ows should
also be modelled before implementation [
As was recently stated in an article by Whittle et al.: \It turns out that the
main advantages are in the support that MDE provides in documenting a good
software architecture. Most would agree that a clearly described software
architecture is one of the key ingredients for successful software development" [
The current way work ows are modelled is via diagrams that contain only unstructured nodAes(sanimdupnslteru(cstcureednaarrroiwos(. However, this makes the work ow A(simple(scen de nitions too abstract, which does not lend itself to their disciplined implementation, or checking their correctness. To further motivate the importance of this ! Usperro:!“bIl!ehmav,e!ctownos!imdoedretlhs:e!Mfo1l!laonwd!iMng2.!I!wouldm!likaen!agement scenario:
model to!merUgese!trh:em\I!ahnadv!tehetwn!ogemneordaetels!:coMde1!fraonmd!tMhe2!. I would like to me!rg eUthseemr:!“aI!nhdavthee!tnwo!models:!M1!and!M2.!I!woul resguelnt.e!Ir!watoeulcdo!dtheefnr!olikme!ttoh!etrarecesu!blat.ckI!two!oseueld!wthhaetn! like to trace back to steoe!mwehargtep!athrte mof!and!then!generate!code!from! patrht!eofc!tohdee!ccoadme!ceafmroem!froMm1!M."1.”! result.!I!would!then!like!to!trace!back!to!see! part!of!the!code!came!from!M1.”! ! import!models!M1,!M2! import!overlap!O=O(M1,!M2)! merge!(M1,M2)!into!M3!using!O! 1:overlap! import!transformaPon!t! apply!t!to!M3!to!produce!Code! Intersect!(M1,Code)!into!M14!
M1! M2!
M14! 4:intersect!
3:transform! 2:merge!
M3!
M4! (Code)! 5" given! heurisPcs!
This can be depicted graphically in Fig. 1, and a script implementing this work ow scenario is shown in Fig. 2. We start with two input models M 1 and M 2, de ne their overlap in the rst step of the work ow, then merge these two models into a third model M 3 via a merge operation. Afterwards, some transform operation is used to generate code (M 4). In order to nd which part of the code came from M 1, an intersect operation is used, which yields M14.
The main issue with the current way the work ow is represented is that there exists a very large gap between the diagram and the code that would implement it. We would therefore like to propose a way to model the work ow that is still abstract, but not too abstract to be too far from the semantics of the operations and how they are composed.
Traceability is increasingly required in software development at the
stakeholder level (e.g., to ensure a given requirement has been implemented in the
system), but also at the software development level (e.g., to ensure traceability as
high level models are re ned along the development process) [
Finally, it is known that the presence of errors in models and model management operations risks both the reliability of MDE-based processes and the soundness of the resulting products. For this reason, there is a great need for mechanisms to ensure quality and the absence of errors in models and model management operations. This propagates to the work ow level as well, creating a need for mechanisms to ensure quality and absence of errors in the model management work ows. To do this, veri cation and validation techniques are typically used, but as far as we know, none exist in the area of modelling workows in MDE. For veri cation, what is needed is a mechanism to ensure that the work ows satisfy one or more correctness properties. For validation, mechanisms to check whether the work ows meet the user requirements are needed. The latter is typically done through testing, but some formal methods, like model checking, can also aid in validation.
In this work, we propose a method that we argue will improve how work ows are modelled in MDE. We see this work being useful in both theory and practice and of interest to audiences from both academia and industry that are generally interested in specifying their model management tools and reasoning about their model management chains. 2
In this section we provide an overview of current approaches in the area of work ows for MDE, and summarize with a list of problems.
Epsilon is a suite of languages that are used for modeling and applying
operations on models, such as comparison, validation, transformation, merge, etc.
[
The Formalism Transformation Graph (FTG) and its complement, the
Process Model (PM) as presented in [
Model Transformation Chain (MTC) Flow is a tool that allows MDE
developers to design, develop, test and deploy MTCs [
UML Activity Diagrams are used for specifying work ows and takes into
account both data and control ow [
In summary, below are the issues we have identi ed and plan to address: { Modeling: Work ows are not always modelled before implementation, and if they are, it is not in a structured way that enables reasoning. { Expressiveness: Many languages/tools support sequential composition only and do not support more interesting work ow combinators such as parallel composition and branching. { Traceability: As far as we understand, traceability is either implicit or nonexistent. A way to automatically ensure traceability, or use it for reasoning and analysis, is not possible with current approaches. { Veri cation: This cannot be done without the notion of data ow, and requires a grammar from which to build terms and the ability to check whether a term is correct or not. { Validation: In general, this is not straightforward, but we think it can be achieved with the help of a proper declarative work ow language.
3.(Diagrammatic(Workflow(
Proposed Solution 3.(Diagrammatic(Workflow( ! TUsheirs:!“sIe!hcatvioe!ntwpor!movoiddeelss:!aMh1!iagnhd!lMev2e.!lI!wovoeurldv!liiekwe! of our proposed solution to modelling wtoo!mrkergoew!thseimn!aMndD!thEe.nW!geeneprartoep!coosdee!afro!s mt r!tUuhcseet!ru:!r“eI!dhaavpe!pt wrooa!mcho,dealns:d!Mf1o!rantdh!Me2p.u!I!rwpoousleds!likoef! result.!I!would!then!like!to!trace!back!to!see!wthoa!mt! erge!them!and!then!generate!code!from!the! this paper, we use diagrams to exhibit this structure. part!of!the!code!came!from!M1.”! result.!I!would!then!like!to!trace!back!to!see!what! part!of!the!code!came!from!M1.”! ! M14! !
! ! M14! 4:INTERSECT! ! Source&MM& Q(Source&MM)& target&MM& 1:!MATCOH! M12!:!MERGeE1!! M3! 3:TRANSFORM!CMod4e:!! !!!!1:!MATCH! M1! :qExe& e1! :relab& 4:INTERSECT!
M2! e2! traceability! !! O 2:!MERGE! M3! 3:TRANSFORM!CMod4e:!! given! heurisPcs! automaPc! !! Sourc(Ce&DM)&odel&M2! e2![[Q]](CD)& traceab(TiDalBritg&Seyct!h&Memodae)&l& 7" Fig. 3. Structured work ow through diagrams.
given! heurisPcs! Fig. 4. Transformation diagrammatically.
Typing(for(operations( automaPc!
Back to our example from Section Name! Input!Arity! Output!Arity! 1, we model our work ow once again p R q using a diagram as depicted in Fig. Match! A B A B t3dh.iaeNgcroahwme,vmtrhoaentsiocpaalerlerya.ttFhiooenmrsesaxeplavpmeespalrdeie,ngcnooendn- Merge! A p R q B A pr RC sq B sider the transformation operation, Transform! A A p tR qB swhhoiwchn winasFigrs.t4p.rTohpeosterdaninsfo[3r]maantdioins Intersect! A p R q B A r C s B is de ned through the tiling (composition via a common edge) of two op- Fig. 5. Typing system for a subset of model erations: qExe, which speci es query management operations. execution, and relab, which relabels the query result in terms of the target metamodel. Note that the output of one operation (qexe), namely the vertical blue arrow, becomes part of the input to the next operation (relab). Also, notice two types of output mappings from the generated target model; the vertical blue arrow which represents a typing mapping to the target metamodel, and the horizontal blue arrow which represents a traceability mapping. This way of de ning the transformation automatically ensures traceability in the system, as the traceability mapping is explicit in the arity of the operation, or, in other words, the typing of its parameters and outputs; when the parameter or output is a graph, the type is a graph shape. We can then de ne a typing system for the operations (i.e., prescribing their (graphical) arities), which is also diagrammatic in its nature. This is shown for a subset of model management operations, namely, match, merge, transform and intersect, in Fig. 5.
Work ow de nitions de ned in this manner can then be parsed into a Directed Acyclic Graph (DAG) which can be used to verify correctness of the terms. Some properties that can be checked are lack of cycles in the DAG and that each operation satis es its typing, presented in Fig. 6.
Finally, we can construct a work ow lanMgMuaTgeis ( Wthe s=igna(turMe MoTf; mCo)d),el wmhaenre- Mt4!p!roject% intersect% spanp!roject% M14! agement operations and C is the sig- transform% nature of work ow combinators. For our M3! cbuerrsetnrtucstiumrepdle assceannariaol,geabrwaiocrkteromw wWoul=d CoIproject% project% e1! (match; merge; transf orm; intersect), where spanm!erge% match; merge; transf orm; intersect are from span!
MMT and ; is sequential composition from
C . This algebraic term represents the intent M1! match% M2!
of Fig. 3, and the meaning of sequential
composition is given by the tiling explained in [
We envision our framework supporting Fig. 6. Parsing the algebraic workthe full range of model management opera- ow using a DAG. tions supported by standard model management tools, and containing work ow combinators that we will derive from common model management scenarios.
In summary, we specify our system of interrelated models via graphs and graph mappings, constraints on such a system via diagram predicates, and operations on these systems via diagram operations. The latter are then composed (tiled) to form complex chains which de ne work ows in our language. 4
This work started by examining the emerging concept of \megamodeling" in
MDE. We quickly realized that the way megamodeling is discussed in most
papers lacks a theoretical foundation and therefore is not amenable for veri cation
or reasoning. We decided to look at megamodeling from a more formal view,
and we presented \Mapping-Aware Megamodels" in [
In related work done within our group [
The main contributions of this work will be: { A structured speci cation of megamodels: Models and mappings as rst class citizens modelled via graphs and graph mappings, respectively, the constraints on them modelled via diagram predicates, and the operations on them modelled via diagram operations. { A work ow language for megamodeling that is built via the composition (tiling) of diagram operations. { Evaluation of the work ow language and a set of suggested improvements to the state-of-the-art in the area of work ows in MDE.
We expect that our work will serve as a framework on which model
management languages, and model transformation chain tools can build speci cations
for their tools and verify correctness of their chains. In addition to addressing
the issues in the state-of-the-art (refer to Section 2), we believe our work will
provide the following advantages to the way work ows are modelled in MDE.
{ Readability and Maintainability: Work ows that are easier to read and
write, and are therefore more maintainable. Early work showing this with
regards to using a declarative model transformation approach shown in [
For validation, we plan to build our work ow language by example. What this means is that we will start with simple case studies to help de ne what model management operations and work ow combinators will form our language, and then work our way up to more complex examples while expanding our language.
For evaluation, the plan is to compare our approach to similar approaches
by taking a practical model management scenario1, modelling it in the various
approaches (including ours), and performing analysis with respect to prede ned
criteria. For example, readability, ease of use and maintainability of the work ow
de nitions can be achieved through a usability study that would reveal how much
the various approaches aid in improving communication and help in di erent
1 We plan to conduct an industry case study from the automotive domain which has
been used in the NECSIS project, namely the power window case study used in [
The remainder of the PhD will take our work in [