Budapest University of Technology and EconomicsDepartment of Measurement and Information Systems

Automated Model Transformations in Domain

Specific Visual Languages

Scientific Students’ Associations Report

Istvan Rath

Andras Schmidt

David Vago

Supervisors:

Dr. Daniel Varro, assistant professor

Andras Balogh, PhD student

Budapest, October 2005

The authors would like to thank Dr. Daniel Varro and Andras Balogh for their continuedsupport, friendly advice, and enthusiasm. We would also like to thank all fellow colleagues andfriends who participated in the Viatra2 project by providing valuable testing and feedback.

Contents

1 Introduction 51.1 Multi-Domain Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Models in software engineering . . . . . . . . . . . . . . . . . . . . . . 51.1.2 The evolution of approaches . . . . . . . . . . . . . . . . . . . . . . . . 61.1.3 Problems with MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.4 Domain-specific modeling . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.5 MDSE = MDA + DSM . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.6 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 The State of the Art of Language Engineering 172.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Language engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.2 Domain integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Basis of comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Language engineering criteria . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 Integration criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 Architectural properties . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4 Typical workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Commercial products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1 MetaCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.2 Microsoft DSL Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 VMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.5 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5.1 The Eclipse Integrated Development Environment . . . . . . . . . . . 292.5.2 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . 292.5.3 Graphical Editing Framework . . . . . . . . . . . . . . . . . . . . . . . 302.5.4 Domain-specific editors with EMF and GEF . . . . . . . . . . . . . . 322.5.5 Eclipse GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.6 openArchitectureWare . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.7 Tiger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.6 Our approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.6.1 Example: Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3 Interpreter-based model transformation in VIATRA2 473.1 Metamodeling: Definition of Abstract Syntax . . . . . . . . . . . . . . . . . . 47

3.1.1 Visual and Precise Metamodeling . . . . . . . . . . . . . . . . . . . . . 47

2

3.1.2 The VTML language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.2 The VTCL language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1 Graph patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.2.2 Graph transformation rules . . . . . . . . . . . . . . . . . . . . . . . . 523.2.3 Control Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.2.4 Caching program models . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3 Code templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4 Implementing the pattern matcher . . . . . . . . . . . . . . . . . . . . . . . . 59

3.4.1 Building constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.2 Matching patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.3 Caching the pattern search plan . . . . . . . . . . . . . . . . . . . . . 613.4.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.5 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5.1 The VIATRA2 framework . . . . . . . . . . . . . . . . . . . . . . . . . 623.5.2 The GTASM interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6 Language Engineering in VIATRA2 . . . . . . . . . . . . . . . . . . . . . . . 653.6.1 Petri net metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.6.2 Petri net simulation with GTASM . . . . . . . . . . . . . . . . . . . . 663.6.3 Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.6.4 Checking a constraint on the model . . . . . . . . . . . . . . . . . . . 72

3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 The DSM Framework 744.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2.1 Editor generation or runtime framework? . . . . . . . . . . . . . . . . 774.2.2 Domain specific graphical representation . . . . . . . . . . . . . . . . . 794.2.3 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.4 Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.2.5 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.3.1 DSM framework and domain plugins . . . . . . . . . . . . . . . . . . . 894.3.2 VIATRA2 as the model container . . . . . . . . . . . . . . . . . . . . . 914.3.3 Graphical representation . . . . . . . . . . . . . . . . . . . . . . . . . . 954.3.4 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.4 Transformations, simulation and code generation . . . . . . . . . . . . . . . . 1004.4.1 Requirements of transformation support . . . . . . . . . . . . . . . . . 1004.4.2 Describing transformations . . . . . . . . . . . . . . . . . . . . . . . . 1014.4.3 Running transformations . . . . . . . . . . . . . . . . . . . . . . . . . 1014.4.4 Transformations overview . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.5 Multi-domain editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.6 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.6.1 Logical model view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.6.2 Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.7 Example: Petri Net editor and simulator . . . . . . . . . . . . . . . . . . . . . 1114.8 Future goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

3

5 Conclusions 1195.1 The transformation framework . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.2 DSM framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

A ASM Example: Traffic Lights 126

4

Chapter 1

Introduction

1.1 Multi-Domain Systems Engineering

Models are projections of reality. In engineering, they are used to capture concepts related tothe engineer’s task: the product that is being designed, its environment, and processes thatmay be involved in its life cycle. Models are attractive because they allow a problem to beprecisely grasped at the right level of abstraction without unnecessarily delving into detail.

1.1.1 Models in software engineering

In software development, models are used to represent data structures, communication be-tween agents, algorithms, or at a higher abstraction level, entities in a complex system, e.g.organisational units or products in an e-commerce application.

The software development industry has been using high level models at the core of de-velopment for more than a decade now, because it is widely believed that software systemsof large complexity can only be designed and maintained if the level of abstraction is setconsiderably higher than that of conventional programming languages. On the other hand,computers can only operate at the lowest possible level of abstraction (machine code consist-ing of elementary operations and data primitives), thus our models need to be translated intothe language that the target platform can understand and run. By platform we mean thelow level software and hardware architecture that executes application code (which includessoftware libraries, operating systems, a computer architecture, or even a virtual machine witha runtime framework, such as Sun’s Java or Microsoft’s .NET).

For low level models, this translation is usually called compilation (in this context, aprogramming language construct, i.e. source code is also considered a model); while for highlevel models, the term model transformation is frequently used. This is traditionally calledmodel-to-model transformation. In contrast, a special case of model transformation is referredto as code generation, where source code is generated from a (graphical) model, using a codegenerator (model-to-code transformation).

The model based software development paradigm is based on the idea that the developershould work with high abstraction level models during most of the development cycle. For thisto work in practice, model transformations are required. Source code, the ’traditional’ productof software development, should be generated to the largest possible extent, to minimize theamount of business logic that is outside of the scope of modeling, and is only represented byhandwritten code.

5

1.1.2 The evolution of approaches

CASE

Whilst all aspects of the software development process could be supported by software tools,computer aided software engineering (CASE) tools are usually used to assist software designand analysis. Historically, CASE emerged during the 1980’s, when many software develop-ment companies realised that meeting increased demand for high quality and complex softwarerequired more sophisticated development methods than those used previously. These toolsarose out of developments such as Jackson Structured Programming and the software mod-elling techniques promoted by researchers like Ed Yourdon, Chris Gane and Trish Sarson(SSADM: Structured Systems Analysis and Design Methodology). CASE is a very broadconcept, and in that sense even modern integrated develoment environments, such as Eclipse,or Visual Studio can be considered CASE tools. In this historical context, however, theterm ’CASE tool’ refers to the earliest programs designed to assist software development andanalysis.

The problem with early CASE tools stems from the fact that they lacked a commonapproach. Although the methodologies they were built to support shared similar concepts,on the implementation level they differed substantially. Due to the lack of a common graphicalnotation system, even development documentation was hardly reusable.

UML

The Unified Modeling Language was conceived to provide a common framework for specifica-tion, modeling, and documentation in the software development process. In many senses, itwas a spectacular success, because it established a visual, easy to use notation system whichwas comprehensive enough to capture all major aspects of software engineering. Today, UMLis the industry standard for modeling and specification. It’s use is not restricted to modelingsoftware, it is also widely used for business process modeling, organizational structure mod-eling, and even hardware design. UML represents a compilation of best engineering practiceswhich have proven to be successful in modeling large, complex systems, especially at thearchitectural level.

History UML was developed by Grady Booch, James Rumbaugh, and Ivar Jacobson. Itwas first standardized in 1997 under the supervision of the Object Management Group, aconsortium, including industry heavyweights such as IBM, Hewlett-Packard, Apple Computer,and Sun Microsystems, formed in 1989 to set standards in object-oriented programming andsystem modeling. Along with the standardization of UML, the OMG’s most important work isCORBA (Common Object Request Broker Architecture), an architecture designed to enableapplications on heterogenous platforms to interoperate using a common set of applicationprogramming interfaces (APIs), communication protocols and information models. CORBAwas a very ambitious project, but it is a debated issue whether it can be considered successful.However, it fits well into the pattern of technologies promoted by the OMG: all are fairlylarge and complicated, of in-width nature, trying to achieve very ambitious goals by being”everything to everyone”.

Aspects UML handles three domains of system modeling: requirement, static, and dy-namic models. Requirement modeling employs concepts which are related to how the system

6

interacts with its surroundings (Use Case Diagrams). Static modeling deals with the structureof the system, and uses concepts such as classes, objects, attributes, operations, and associ-ations (Class and Deployment Diagrams). Dynamic modeling captures the behaviour of thesystem with concepts like activities, messages, function calls, states, concurrency, transitions(Activity Diagrams, Sequence Diagrams, State Chart Diagrams).

Apparently, UML is intended to be a general-purpose modeling language, which is inde-pendent of the application domain - even if some of the diagrams evolved from languagesalready being used before in certain domains (e.g. statecharts in embedded systems).

Model Driven Architecture

The Model Driven Architecture (MDA) is OMG’s newest approach to model-based softwaredevelopment. MDA is essentially an approach to model-based software development utiliz-ing OMG’s flagship techonogies, UML, the Meta Object Facility (MOF), XML MetadataInterchange (XMI), and the Common Warehouse Metamodel (CWM).

MDA is a visionary concept: it is a model-based software development paradigm to sup-port evolving standards in application domains as diverse as enterprise resource planning, airtraffic control and human genome research; standars that are tailored to the need of these di-verse organizations, yet need to survive changes in technology and the proliferation of differentkind of middleware. The OMG Model Driven Architecture addresses the complete life cycleof designing, deploying, integrating, and managing applications as well as data using openstandards. MDA-based standards enable organizations to integrate whatever they alreadyhave in place with whatever they build today and whatever they build tomorrow[41].

Design goals MDA was designed with the following goals in mind:

• Portability and reusability, increasing application reuse and reducing the cost and com-plexity of application development and management.

• Cross-plaform interoperability, using rigorous methods to guarantee that standardsbased on multiple implementation technologies all implement identical business func-tions.

• Platform independence, greatly reducing the time, cost and complexity associated withretargeting applications for different platforms.

• Domain specificity, through domain-specific models that enable rapid implementationof new, industry-specific applications over diverse platforms (the term domain will beexplained in detail in 1.1.4).

• Productivity, by allowing developers, desingers and system administrators to use lan-guages and concepts they are comfortable with, while allowing seamless communicationand integration across the teams. Moreover, a significant reduce in costs is attained bymodels of the target application that can be directly tested and simulated.

Development steps As it can be seen on Figure 1.1, MDA emphasizes the clear dis-tinction between Platform Independent Models (PIM) and Platform Specific Models (PSM),thus, software development in MDA is envisioned as a three-step process. First, the Plaform

7

PlatformIndependent

Model

CORBAmodel

J2EEmodel

Othermodel

CORBA J2EE OtherLegacy

application

Reverse engineering

PlatformIndependent

Model

PlatformSpecificModel

Softwareapplication

Modeltransformation

Codegeneration

Figure 1.1: Model Driven Architecture

Independent Model is designed, which is supposed to use modeling concepts which are notplatform specific. The PIM is a pure UML model, with constraints specified in the ObjectConstraint Language (OCL), and behavioral semantics described in Action Semantics (AS)language.

The second step is to generate a Plaform Specific Model, which contains additional UMLmodels, and represents an implementation of the system under design which can run on thetarget platform. The transition between PIM and PSM should typically be facilitated usingautomated model transformation technology. The most important keyword of this phase is”standard mappings”, i.e. it is very important that this transformation step be agile, meaningthat it should require the smallest possible amount of human interaction (otherwise, there isno point in wasting lots of time on platform independent designs).

Finally, application code is generated from the Platform Specific Model. Again, codegeneration should be as extensive as possible, in order to minimise the amount of necessarilyslow and error-prone manual coding. This, in turn, requires PSMs that are expressive enough,not only from a static, but also from a dynamic point of view of the system, to produce allof the application code.

1.1.3 Problems with MDA

Domains in MDA

In MDA, initial system design was carried out on the first, plaform independent level. ”Do-main knowledge” appears here as UML profiles, or applied in-house design patterns (general,best-practice solutions to common domain-specific problems). The platform specific modelwas automatically generated using a standard mapping. As PIM is one level of abstractionhigher than the PSM, for the PSM to be as comprehensive as possible, all necessary infor-mation should be provided in these standard mappings. This information, in MDA terms,is platform-specific, rather than domain-specific. Therefore, as MDA is based on UML, thesuccess of an MDA design highly depends on how expressively a domain can be modeled usinga general-purpose modeling language, on a platform-independent level.

8

PlatformIndependent

View 1

CORBAmodel

J2EEmodel

Othermodel

CORBA J2EE OtherLegacy

application

PlatformIndependent

Models

PlatformSpecificModel

Softwareapplication

Modeltransformation

Codegeneration

PlatformIndependent

View 2

PlatformIndependent

View n

Reverse engineering

Intermediatemodels

Figure 1.2: Model Driven Architecture - in reality

From the late 1990’s, UML rapidly gained industry-wide acceptance, many software housesbegan to experiment with using UML not only for documentation, but for real model-drivensoftware development. New technologies, such as extensive code generation and model verifi-cation were found to be difficult to implement with UML models. At the end of the decade,several shortcomings in UML have been pinpointed, in surveys such as [22]. The most im-portant weaknesses of UML are identified in [42] as:

...its imprecise semantics, and the lack of flexibility in domain specific applica-tions. In principle, due to its in-width nature, UML would supply the user withevery construct needed for modeling software applications. However, this leads toa complex and hard-to-implement UML language, and since everything cannot beincluded in UML in practice, it also leads to local standards (profiles) for certaindomains.

Thus, the two key points, where UML needed improvement, were: (i) precise semantics,and (ii) flexibility to integrate domain-specific concepts.

The Object Management Group has partially succeded in identifying these problem areas,as considerable efforts have been made towards an in-depth evolution of the UML standardfor version 2.0. According to these ideas, UML 2.0 would consist of a core kernel language(UML Infrastructure 2.0), and an extensible family of distinct languages (UML Superstruc-ture). Each UML sublanguage would have its own (individually defined) semantics, whichfundamentally requires an appropriate and precise metamodeling technique.

Transformations in MDA

Such a metamodeling-based architecture of UML highly relies on transformations within andbetween different models and languages. In practice, transformations are necessitated for atleast the following purposes [42]:

9

• model transformations within a language should control the correctness of consecutiverefinement steps during the evolution of the static structure of a model, or define a(rule-based) operational semantics directly on models;

• model transformations between different languages should provide precise means toproject the semantic content of a diagram into another one, which is indispensable fora consistent global view of the system under design;

• a visual UML diagram (i.e., a sentence of a language in the UML family) should betransformed into its (individually defined) semantic domain, which process is calledmodel interpretation (or denotational semantics).

The crucial role of model transformation (MT) languages and tools for the overall successof model-driven system development have been revealed in many surveys and papers duringthe recent years. To provide a standardized support for capturing queries, views and transfor-mations between modeling languages defined by their standard MOF metamodels, the ObjectManagement Group is soon to issue the QVT standard.

QVT provides an intuitive, pattern-based, bidirectional model transformation language,which is especially useful for synchronization kind of transformations between semanticallyequivalent modeling languages. The most typical example is to keep UML models and targetdatabase models (or UML models and application code) synchronized during model evolutionin a bidirectional way.

However, there is a large set of model transformations, which are unidirectional by na-ture, especially, when the source and target models represent information on very differentabstraction levels (i.e. the model transformation is either refinement or abstraction). Unfor-tunately, the current QVT Mapping Language is far less intuitive and easy-to-use in case ofunidirectional transformations.

The Viatra2 model transformation framework primarily aims at designing model trans-formations to support the precise model-based system development with the help of invisibleformal methods[3].

It is important to recognize that UML is intended to be the one and only language, auniversal standard. There are, however, domains where engineers either do not understandUML, or the general concepts of UML are simply inappropriate for modeling effectively - infact, they might already have their own standard languages or tools which are.

1.1.4 Domain-specific modeling

What makes a model domain specific? A domain can be defined as the set of concepts andtheir relations within a specialized problem field. This definition implies that all softwareis built to solve domain-specific problems, since software engineering is all about providingsoftware solutions to problems in specialized problem fields (e.g. pharmaceutical, businessprocesses, civil engineering). Even software design is a domain in this sense. On the otherhand, in software design, the term application domain refers to a knowledge base that isoutside of the scope of software development. For example, if an application for managinga book shop is being designed, all information that describes actual business processes andproducts, how they interact, what their attributes are, etc. constitutes domain knowledge.Domain knowledge can only be obtained from domain experts, and it is therefore one of themost valuable assets of software development.

10

Domain-specific (programming) languages (DSLs) are specialised languages, suitablefor efficiently writing programs to solve problems that are specific to an application domain.In contrast to general-purpose programming languages, DSLs are much more expressive andcomprehensive for the experts in their own domain. For example, when using SQL, it isvery easy to write database queries, but it is impossible to implement an operating systemkernel. In the C language, it is possible to do both, but a single line of SQL code is likely tocorrespond to tens, even hundreds of lines of C code.

Intentional Programming (IP) by Charles Simonyi [37], shares similar concepts withdomain-specific programming languages. However, IP is more like a bottom-up approach,in contrast to the top-down nature of DSLs, where the languages are specifically tailored tothe needs of the target domain. IP was envisioned to be an evolution of general-purposeprogramming languages. In IP, the level of abstraction is raised by introducing to notion ofintention, the abstract concept behind common programming language constructs such asiteration, recursion, variable, function calls etc. Intentional programmers create source codeby glueing together their intentions into a coherent logical structure which represents thefunctionality of the system under design. This approach combines the flexibility of textuallanguages with the visual and abstract nature of model-based development.

Aspect-oriented Programming (AOP) by Gregor Kiczales et al[20], was also meantto be an evolution of conventional procedural and object-oriented programming paradigms.However, instead of raising the level of abstraction above the source code level, AOP is ahorizontal approach. In AOP, the most important goal was the separation of concerns bysplitting the logical structure of application source code into aspects, which are later joinedat the designated join points by an automated process called weaving.

Note that both IP and AOP are targeted towards programmers, not domain experts,which is a crucial difference.

Domain-specific modeling languages Analogously to domain-specific textual languages,domain-specific modeling languages are modeling languages which operate with elements andrules that are special to the target domain. For example, if one wants to design user interfacesfor mobile phones, domain-specific model elements could include Menu, MenuItem, DialPad,SMS etc. Domain-specific modeling languages are, just as DSLs, much more expressivein their domain, than general-purpose modeling languages, such as the Unified ModelingLanguage (UML).

Domain-specific modeling (DSM) is a new approach to model-based software develop-ment. In contrast to IP and AOP, DSM is a top-down and vertical approach: instead oftrying to create high abstraction level ”interfaces” to source code, DSM gives the designerthe freedom to use structures and logic that is specific to the target application domain, andthus, completely independent of programming language concepts and syntax. Similarly toMDA, DSM is a model-based approach, however, while MDA emphasizes the importance of asingle and universal modeling language at the center of the development process, proponentsof domain-specific modeling argue that flexibility and ease of use by domain experts is moreimportant than sticking to (pure) UML.

11

PlatformPlatform

Generated code

DS ModelGenerated code

PS ModelDomain

framework

PI Model

DS Model

DSM DSMwith

framework

MDA

Level of abstraction Code

Platform

Figure 1.3: The difference between various DSM and MDA appoaches

As it can be seen on Figure 1.3, in current domain-specific modeling technology, sourcecode is generated directly from domain-specific models, instead of going through the platform-independent and platform-specific abstraction levels found in MDA. While it is often claimedthat it is exactly this difference which makes 100% code generation possible[18], this approachcan make the implementation of platform-specific code generators difficult. Thus, recent DSMapproaches, such as the one presented in [34], emphasize the importance of a domain frame-work, which makes code generation easier by ensuring portability across various platforms(thus, this domain framework has to be implemented on various architectures, similarly tothe Java or .NET idea).

Motivation for DSM

If the model-based software development paradigm is to succeed on a wider scale, effectivemethods for rapid, productive and agile modeling and code generation need to be established.As it has been previously concluded, UML is a general-purpose modeling language, and assuch, it is rather limited in integrating domain-specific modeling concepts. Recent articles,such as [13], see domain-specific modeling languages as ”...the next step towards developinga technology for software manufacturing”. Others, like [18], claim that a pure DSM-basedapproach consistently results in productivity increases of 500-1000%, compared to the mere35% found with MDA (interestingly, all the articles refer to one and the same study[5]).Steven Kelly, the Chief Technical Officer of MetaCase1, a company that produces a popularDSM framework, recently wrote[19]:

While good, that [35% increase in productivity] is far from the 500%-1000%consistently found with DSM. MDA proponents envisage higher forms of MDAincorporating elements of DSM, and these may offer some more hope. In these, thebase UML can be extended with domain-specific enhancements, or even replacedwith new MOF-based metamodels. However, experiences with the former havefound current tools lacking the necessary extensibility, and no tools support thelatter.

It is important to clarify that this paper is not intended to be biased towards or againstMDA in any way. Moreover, it is also not the purpose of this paper to come to a definite

1http://www.metacase.com

12

CASE

UML

MDA

DSM

MDSE

Figure 1.4: Multi-Domain Systems Engineering as a synthesis of MDA and DSM

conclusion as to whether UML is suitable for full code generation, an issue that is frequentlybrought up by DSM proponents. As stated earlier, from their point of view, the main advan-tage of domain-specific modeling over MDA is that DSM allows 100% of application code tobe generated, while typical UML-based MDA tools are less effective in this respect[18].

1.1.5 MDSE = MDA + DSM

From our perspective, MDA and DSM are complementary concepts rather than rivals. Bothemphasize the importance of reusable and verifiable design based on models of a high ab-straction level. What OMG seems to fail to realise with MDA is that in order to integratedevelopment from the widest possible range of application domains into a single framework,the standard needs to be as flexible as possible on the highest abstraction level (PIM), whilebeing as precise as possible concerning the automated transformations between the abstrac-tion levels. If these two requirements are met, it does not really matter what modelinglanguage is used for documentation (UML was a good choice in this respect).

In this paper, we propose a synthesis of the Model Driven Architecture and Domain-specific Modeling approaches based on a robust model transformation framework (Figure1.4).

Multi-Domain Systems Engineering (MDSE) can be considered an MDA variant, butalso a DSM variant. As it can be seen on Figure 1.5, our approach recognizes (i) providingsupport for translation between domain-specific modeling languages, and (ii) generating aglobal and coherent system model from small domain specific submodels as the most criticalaspects of utilizing DSM technology in MDA.

A domain-specific modeling environment is only effective if its visual languages are suf-ficiently expressive, intuitive and easy-to-use. This is only possible if the system providessupport to all aspects of language engineering:

• Concrete syntax, so that designers can use familiar visual symbols;

• Abstract syntax, to make efficient and precise model transformations possible;

13

Domain-specificView 1

CORBAmodel

J2EEmodel

Othermodel

CORBA J2EE Other

PlatformSpecificModel

Softwareapplication

Modeltransformation

Codegeneration

Domain-specificView 2

Domain-specificView n

Intermediatemodels

Domain-SpecificModels

PIM

Figure 1.5: Model Driven Systems Engineering

• Well-formedness rules, to integrate domain-specific constraints into high-level models;

• Dynamic semantics (simulation), to enable the designer to visualize the system as itinteracts with its environments;

• Transformations, to facilitate the automated translation of high-level models into alow-level representation (PSMs, or application source code).

1.1.6 Objectives

In this report, we present a general and flexible domain-specific modeling and transformationenvironment, which forms the central component of the VIATRA2 framework. Our approachenables the handling of all critical aspects of language engineering (abstract syntax, concretesyntax, well-formedness constraints, model simulation and transformations) within a singleframework.

Our approach (Figure 1.6) integrates a mathematically precise model transformation en-gine with an easy-to-use domain-specific modeling interface, in order to:

(i) enable language engineers to design domain-specific languages utilising all aspects oflanguage engineering;

(ii) provide support for precise model-to-model and model-to-code transformations, usinga powerful domain-specific programming language;

(iii) integrate the system into an existing model-driven development infrastructure throughimport and export capabilities;

(iv) so that domain experts can use an intuitive graphical user interface to create multi-domain models with support for interdomain translations and simulation, seamlesslyintegrated into a model transformation framework; thereby facilitating the automatic

14

Platform

Model transformation framework

PIM

Generated code

DSM framework

Import

Externalmodels

Domain-SpecificViews

Domain expert

GUI

PSM

Export / Code generation

GUI, DSL

Language engineer

ExportPSM

Execution

Figure 1.6: Our approach to MDSE

15

generation of documentation, low-level models, and application source code from highabstraction level models.

In the current report, we present the following results:

• We evaluate the state-of-the-art of language engineering by comparing various academicand commercial domain-specific visual environments (2.2);

• We elaborate a method for the precise specification of domain-specific visual languagesusing a high-level formal language ( 2.6 and 3.6);

– We propose the use of visual and precise metamodeling techniques for the definitionof the abstract syntax of these languages (2.6, 4);

– We uniformly specify modeling constraints, model transformations, model simula-tion and code generation by a combination of graph transformation and abstractstate machines (3.6);

• While participating in the development of a model transformation framework (Viatra2),we developed and implemented an efficient algorithm based on local search techniquesto support the interpreter-based execution of model transformations (Sec 3.4).

• We designed and implemented a domain-specific modeling environment to support theprevious concepts, which is integrated into the Eclipse Framework in the form of anextensible plug-in (Sec 4). The main advantages of our implementation are:

– it can be adapted to arbitrary modeling frameworks

– it is a memory efficient implementation

– it supports modeling and mode transformation in multiple domains

– it enables the model-based development of domain-specific visual languages (with-out manual coding) but also provides a flexible solution for language engineers bymanual coding.

• We demonstrate the feasibility of our approach with a simple, but descriptive example(domain-specific Petri net editor and simulator) (3.6).

16

Chapter 2

The State of the Art of LanguageEngineering

2.1 Goals

Our approach, Multi-Domain Systems Engineering, intends to integrate the Model DrivenArchitecture and Domain-Specific Modeling development paradigms. The success of such anapproach is highly dependent on two key aspects: (i) domain language engineering and (ii)domain integration.

2.1.1 Language engineering

With models, we can capture static attributes, as well as dynamic behaviour, i.e. it is notonly possible to describe the structure, but how this structure changes as the representedsystem operates. To construct models, modeling languages are used. For textual languages,one can think of an alphabet and a grammar. In this paper, the term modeling languagerefers to a visual (graphical) language. The rules and elements for modeling languages aredefined by metamodels. These are also models, constructed using a metamodeling language.A metamodeling language is defined by the following features:

• Concrete syntax, which is a specification of all the visible features of a modelinglanguage. In textual languages, complex expressions in concrete syntax may be fasterto write in a compact form, but this also means that they can be difficult to read abovea certain level of complexity. In contrast, visual languages are generally easier to read,and, more importantly, safe to write, because a good visual editor does not allow tocreate models with syntax errors. (Note however, that semantic mistakes are muchharder to eliminate - DSM tools can be good at making such faults more apparentbecause these can be easier to detect on a higher abstraction level).

• Abstract syntax defines the vocabulary of language concepts and how these can becombined in models. The abstract syntax is also called the language metamodel. Apartfrom the definition of language concepts and their relationships, metamodels also con-tain information concerning taxonomy and ontology (abstraction and specialization).Metamodels are constructed using core metamodeling languages, which are one met-alevel higher, and specify what concepts can be used for language specification. Anexample of a core metamodeling language is MOF , or VPM (3.1.1).

17

• Well-formedness rules are constraints which must be satisfied by models. Typical ex-amples are multiplicity constraints, aggregation (e.g. ”at most one parent for each modelelement”), or language/domain specific constraints. In UML, such well-formedness rulesmay be expressed as part of the model (multiplicity), or using a separate constraint de-scription language (OCL).

• Dynamic (operational) semantics, in contrast to the previous three features, mod-els the operational behaviour of language concepts. In design, simulators are just asimportant as static descriptions because they allow the modeler to view the system as itwill effectively behave and interact with its surroundings, at a high level of abstraction.

• Transformations (Denotational/Translational semantics) specify how the ab-stract syntax can be translated into a semantic domain (e.g. programming language).This is important from a practical point of view, since models on their own are not veryuseful, they need to be transformed to a lower level of abstraction so that the platformcan execute the represented system.

The special importance of transformations As it can be seen on Figure 1.5, our ap-proach integrates domain-specific models as various views of the plaform independent modelstructure. It is also important to emphasize the possiblity of translations between these views,which makes it possible to design one and the same system from different (requirement) do-mains (multi-domain modeling). This is only possible if automated tool support is available toall five aspects of domain specific metamodeling and model transformation. Current technol-ogy, however, only covers the first three, with a separate code generator used for specifyingdenotational semantics. Simulation (operational semantics) support is limited, as UML’sstandardized solution, Action Semantics is not precise enough, many tool providers experi-ment with complicated Application Programming Interfaces, or other custom, non-intuitivetechniques.

2.1.2 Domain integration

Some of present domain-specific modeling tools are custom solutions, not designed to beintegrated into an existing model-driven development architecture. In many cases, exist-ing metamodels or code generators are hard to be reused. Moreover, although most DSMproviders criticize UML-based approaches, the reality is that UML is so widespead today thatit simply cannot be ignored. Thus, along with domain-specific code generators/serializers,support for UML export is necessary as well.

2.2 Basis of comparison

As already discussed in 2.1, the usability of domain-specific visual languages in Model-DrivenSystems Engineering depends on how well DSM can be integrated into development processes.This, in turn, stems from two key factors: (i) what aspects of language engineering can beused to customize the DSM layer, and (ii) how can the DSM tools be seamlessly integratedinto the existing toolchain.

18

Although domain-specific modeling is not a new idea, a breakthrough such as UML’s rapidadoption is still to come. However, there has been a consideable rise in interest as influentialsoftware development houses realised the potential of DSM.

In the next section of the paper, we give a brief cross-sectional view of the current state ofthe art in DSM technology. We proceed roughly in a cronological order, comparing variouosapproaches using the following evaluation system:

2.2.1 Language engineering criteria

1. Concrete syntax

(a) Automated support for specifying the visual appearance of language elements(visual editors)

Templates: Optional pre-defined visual elements for common concepts cansignificantly speed up the creation of domain-specific editors.

(b) Multi-domain visualization: Support for visualization of model elements fromdifferent domains in a single view. This is important because in many cases complexsystems need to be modeled in multiple domains, and it can be convenient tovisualize the various aspects in a single diagram.

(c) Diagram modeling support

i. Diagram-model separation: Support for editing models independently fromconcrete syntax representation. This means that the modeling environmentshould support the editing of models independently from diagrams, which canspeed up the development process significantly in certain scenarios.

ii. Diagram-model mapping: Support for multiple concrete syntax representa-tions, possibly using a custom mapping of model elements to diagram elementsusing some flexible rule definiton language. This means that instead of stickingto the ”node → figure, edge → arrow” concept, the modeling software allowsfor more complex mappings, e.g. displaying aggregate information in specialdiagram elements.

2. Abstract syntaxThe core metamodeling approach of the modeling environment is important, since (i) itshould be as concise as possible to support mathematically precise transformations; (ii)while being as flexible as possible to support integration of arbitrary (non-MOF/UMLbased) models.

3. Well-formedness rules

(a) Static constraints: Modeling environments generally support simple static con-straints such as multiplicity or type-correctness at relationship endpoints.

(b) Language-specific constraints: These typically specify higher-level constraints suchas ”every model element has a unique name” etc. These constraints can be de-scribed using a constraint descripton language or a special model transformationfrom the modeling language to boolean values.

19

(c) Enforcement: Well-formedness constraints can be either enforced in an on-linefashion, while the user is editing the model (in some cases, this is called syntax-driven editing, whereby syntactically incorrect models cannot be constructed). Theother method, batch mode evaluation means that users are free to create models,and the satisfaction of well-formedness constraints is evaluated at the user’s request- e.g. with the model elements that violate constraints being highlighted.

4. Dynamic (operational) semanticsSupport for model simulation at editing time. For example, if the system under designhas distinct states, a simulator could be used to visualize how the system variableschange as a state transition occurs.

5. Transformations (Denotational/Translational semantics)

(a) Model-to-model:Support for translation between multiple domains. In the Multi-Domain SystemsEngineering approach, systems can be modeled in multiple domains simultaneously.This requires translations between models representing various domains.Note that model simulation is also model-to-model transformation.

(b) Model-to-code: Code generatorsMany programs provide template engines and a programming interface to traversethe model space and generate formatted code output.

2.2.2 Integration criteria

1. Modeling

(a) PersistenceSupport for storing models in relational databases, external model containers, var-ious standard – XMI/XML – formats.

2. DocumentationSupport for automated documentation generation, in various standars (UML for models,JavaDoc for generated code, for example).

3. Advanced featuresSupport for the integration of DSM technology into the model-based development pro-cess using run-time dynamic techniques, for examle a Web Service interface, or a rela-tional database backend.

2.2.3 Architectural properties

1. Generated editors or runtime frameworkMany DSM frameworks use code generation to create domain-specific editors, whileothers present a domain-specific view at run-time. The former approach is generallyeasier to implement (and may be somewhat faster), while the latter is considered moreagile, especially for the language engineer, since changes in the domain metamodelimmediately effect the behaviour of the domain-specific editor without waiting for a(long) code regeneration to finish.

20

2. Editor capabilitesThis category is hard to approach objectively. Apart from standard graphical editingfeatures, such as move/resize/zoom/property grid, many tools support more advancedtechniques.

3. AccessibilityIn this context, accesibility means how the tool can be tailored to the needs of a spe-cific domain. While in most cases a (visual) modeling-based approach is used for thedefinition of at least the abstract syntax, some solutions provide extensive Applica-tion Programming Interfaces (API) for the definition of code generators, simulators,etc. These APIs, while definitely flexible, can also be considered rather cumbersome,especially in contrast to a pure modeling-based approach.

2.2.4 Typical workflow

In this part, the typical workflow to create a domain-specific editor and an application codegenerator is described (as performed by the language engieer).

The results of the evaluation are summarized on Table 2.1.

2.3 Commercial products

2.3.1 MetaCase

Note: this short review of MetaCase technology is based on the official MetaCase homepage[25],the official MetaEdit+ Technical Summary[26] and various publications by MetaCase employ-ees ([34, 19]).

History MetaCase is a Finnish-American company involved in model-based developmentsoftware design since 1991. Their main product, MetaEdit+, dates back to 1995, and has wonmultiple awards (Best Application Development Software at CeBIT ’95, Finnish NationalPrize for Innovation in 2000, Best Commercial Tool at Net.Object Days / GPCE 2003).Nowadays, MetaEdit+ is regarded as the leading DSM implementation. MetaEdit+ can beregarded as a proven, mature product, which makes it unique since all the other implementa-tions examined in this part of the paper have not progessed beyond a prototype status (withthe possible exception of openArchitectureWare).

Architecture MetaEdit+ consists of three major components: (i) the Method Workbenchfor domain metamodeling, (ii) the MetaEdit+ Framework for modeling, and (iii) the Ob-ject Repository server, which serves as the model container. MetaEdit+ is a multi-platformproduct: every component has been ported to major operating systems including MicrosoftWindows, Linux, Solaris, and other commercial Unix variants.

Typical workflow The typical workflow is the following: (1) first, a domain languageis designed by the language engineer in the Method Workbench; (2) this language descrip-tion is imported into the MetaEdit+ Framework through the Object Repository, and usedto create domain-specific models by designers; (3) a code generator is constructed using a

21

Figure 2.1: MetaCase MetaEdit+

custom domain-specific textual language; (4) documentation (reports) and application sourcecode is generated from the models stored in the Object Repository using the pre-defined doc-umentation generator and the custom-made code generator. MetaEdit+ does not use codegeneration for domain-specific editors; instead, the framework generates an interface from thedomain language description at runtime.

Language Engineering support

Concrete syntax As MetaEdit+ is a commercial product with a relatively long history,considerable effort was put into making the tool as user friendly as possible. Thus, this is thecategory where MetaEdit+ is way ahead: with a built-in library for basic graphical elements,and an intuitive Symbol Editor (for drawing and importing graphical symbols), users candesign complex concrete syntax elements without writing any code. Symbol elements canbe conditional on property values and can display values calculated by generators, allowingdynamic graphical behavior. Commonly used symbols or parts of symbols can be stored inthe Symbol Library for reuse.

Multi domain visualization MetaEdit+ appears to be restricted to editing in onedomain per project (but supports multiple views per domain).

Diagram modeling Apart from the traditional graphical views, MetaEdit+ offers thecapability to view the same models as matrices, or tables, changing the view according to theusers’ needs. Thus, diagrams are conceptually separated from logical models.

Abstract syntax MetaEdit+ uses an own core metamodel, which basically describes adirected graph with typed nodes and edges; nodes are called ’Objects’ and edges are called

22

’Relationships’. Properties of arbitrary types can be assigned to both Objects and Relation-ships. Type constraints for Relationship endpoints can also be specified.

Well-formedness rules Both static and language-specific well-formedness constraints aresupported. With the ’Port Tool’, possible interfacing constraints when connecting objects canbe defined (although it is rather unclear how complex these constraints can be). MetaEdit+identifies rules inside and between models. For one modeling language you can define howits concepts can be related to each other and how many connections (of certain type) areallowed between each instance. For example, it may be defined that an instance of ’InitialState’ may have only one triggering connection and that the instance must send the samenotification event to at least two places. This type of rule forces then all developers usingMetaEdit+ to make correct definitions for initial states. It is unclear whether all constraintsare enforced during editing in an event-driven manner (in effect making syntactic errorsimpossible), because it is also mentioned that it is possible to make reports which checkthe consistency of the models, which suggests a batch-mode type constraint enforcementapproach.

Dynamic semantics MetaEdit+ provides an API to read, create, and update model ele-ments, as well as control MetaEdit+ for scripting or simulation support. Moreover, a model-based approach to simulation can also be used: with the ’Graph Tool’, ”it is possible tomanage specifications of whole modeling techniques, such as State Diagram and ComponentDiagram. Techniques are composed of the Objects, Relationships and Roles defined with othertools, together with bindings and rules on how these can be connected. Different techniquescan be integrated with explosions, decompositions and reusable modeling concepts.”

Thus, as we understand, MetaEdit+ provides a mechanism for ”subtyping” your con-cepts with pre-defined dynamic semantics (e.g. State Machines), and the code generator willgenerate code based on the generic template defined for the dynamic semantics description.However, customized model simulation support is NOT present in MetaEdit+, only some kindof code execution tracking mechanism is provided (which shows the ’Active State’, for exam-ple, if the generated source code is step-debugged in a separate view). Note that availabledocumentation on this topic is rather unclear.

Transformations

Model-to-model MetaEdit+ was not designed to be a (mathematically precise) model-to-model transformation system. Although the documentation mentions the possibility ofcreating rules that define how the concepts of one modeling language can be related to conceptsin another, all publications suggest that MetaCase’s approach is based on the idea that codeshould be generated directly from domain-specific models, instead of going through severalintermediate levels of abstraction (e.g. PIM and PSM in MDA).

Model-to-code MetaEdit+ supports automatic code generation for predefined anduser-defined programming languages. The possibilities for automatically generating the codedepend on the methods used and target programming languages. Predefined code generatorsare available for Smalltalk, C++, Java, Delphi (Object Pascal), SQL, CORBA IDL.

23

In MetaEdit+, a code generator is constructed using a domain-specific textual language[19],based on a graph traversal approach.

Integration All the tools are integrated through the Object Repository, which maintainsand enforces the consistency between the tools. Apparently, there is no support for external orrelational database model containers. MetaEdit+ offers pre-built reports for model analysis,checking and documentation in Word, RTF, HTML, XML and XMI.

MetaEdit+ allows the user to build sophisticated tool integration between MetaEdit+and other tools. Alternative tool integration approaches include:

• Programmatic access to model data and MetaEdit+ functions via API

• Model importing and exporting as XML

• Command line parameters for automating MetaEdit+ operations

• Executing external commands via generators

With MetaEdit+, it is possible to make reports which check the consistency of the models,analyse model linkages, create data dictionaries, produce documentation, generate code orconfiguration information and export models to other programs, such as simulators, versionmanagement, external solvers etc. The advanced scripting commands allow the user to printdesigns in various formats, handle output to several files, and even call external programs.

Advanced features The Object Repository can be integrated into the existing designenvironment using SOAP/Web Services.

Success stories According to the official MetaCase homepage, MetaEdit+ has already beensuccessfully used in the following target application domains: Mobile devices, Embedded soft-ware, Financial applications, Industrial automation, Web applications, Workflow applications,IP Telephony services.

2.3.2 Microsoft DSL Tools

Note: this short review is based on the official Microsoft DSL Tools homepage[28], the officialDSL Tools Walkthroughs[29], and various publications by the designers ([16, 17, 13]).

The Microsoft Tools for Domain-Specific Languages is a suite of tools for creating, editing,visualizing, and using domain-specific data for automating the enterprise software develop-ment process. These new tools are part of a vision for realizing Software Factories, a newdevelopment concept by Microsoft. In a nutshell, a Software Factory is a development en-vironment configured to support the rapid development of a specific type of application,thus, it is, in essence, Microsoft’s approach to model-driven software development based ondomain-specific modeling.

24

Figure 2.2: Microsoft DSL Tools, September 2005

History In recent years, Microsoft has given indications of increased interest in model-driven software development. Even Bill Gates stated that the most important innovation inthe next 10 years is going to be visual modeling tools, ”that will reduce software coding by afactor of five.”[36]

Microsoft’s vision of model-driven software development, Software Factories, was laid outin a book[17] in 2004. In a nutshell, this approach argues that the software developmentindustry is in a desperate need of a paradigm shift, because, although the added value insoftware production is tremendous, the production costs are at an unacceptably high level.Software production needs to be industrialized, just like car production was at the beginning ofthe past century. The key to this, as they conclude, is a model-driven development approachbased on domain-specific modeling.

As a result, Microsoft began developing technologies that would turn this vision intoreality. The result, a suite called Microsoft DSL Tools, was released to the public in late2004.

Architecture The DSL Tools suite integrates into the powerful Visual Studio developmentplatform as a set of development environment plug-ins. The suite of tools is supported bya code framework that makes it easier to define domain models and to construct a customgraphical designer hosted in Visual Studio. The suite consists of:

• A new project wizard for creating a fully configured solution in which you can definea domain model that consists of a designer and a textual artifact generator. Runninga completed solution from within Visual Studio opens a test solution in a separateinstance of Visual Studio, allowing you to test the designer and artifact generator.

• A format and an updated graphical designer for defining and editing domain models.

• An XML format for creating designer definitions, from which the code for implementingdesigners is generated. This allows you to define a graphical designer hosted in VisualStudio without any hand coding.

25

• A set of code generators, which take a domain model definition and a designer definitionas input, and produce code that implements both of the components as output. Thecode generators also validate the domain model and designer definition, and raise errorsand warnings accordingly (code generators for generating domain-specific editors).

• A framework for defining template-based artifact generators, which takes data (mod-els) conforming to a domain model as input, and outputs text based on the template.Parameters in the template are substituted using the results of running a C# scriptembedded in the template (code generators for domain-specific output).

Thus, the DSL Tools suite employs code-generated editors running in a separate VisualStudio instance.

Typical workflow The typical workflow is the following: (1) define the domain metamodel(which is called ”domain model” in the documentation) using the Domain Model Designer,starting from a minimal language template, using the project wizard; (2) create the designerdefinition; (3) create the text templates for the domain-specific output code generators; (4)define concrete syntax representation using the provided graphical designer; (5) generate codeand resources for the domain-specific editor plug-in; (6) launch the created plug-in in a newVisual Studio instance and edit domain-specific models; (7) use the domain-specific outputcode generator templates to generate application source code.

Language Engineering support

Concrete syntax The DSL Tools suite provides a built-in graphical designer; the suiteuses an own metamodel for the description of shapes and decorators, which is rather limitedin the September 2005 release.

Multi-domain visualization Apparently, there is no planned support for this feature,as the editors generated by the toolkit are currently meant to be standalone features (so thereis no domain editor framework within Visual Studio), bound to a single modeling language.However, support for multiple diagram types per domain is planned.

Diagram modeling The DSL Tools suite supports the conceptual separation of Dia-grams from logical models using diagram maps, which are embedded into the designer defini-tion XML file.

Abstract syntax There are six predefined templates, and the generator wizard requiresthe user to choose one as a starting point for the newly defined domain-specific modelinglanguage. However, there is no need to code view classes in C#, as these graphic artifactscan be designed using the provided graphical designer tool. The speciality of the DSL Toolssuite is that not only the appearance of the diagram elements can be customized, but theviews, palettes, and other components of the generated editor plug-ins as well.

• Minimal Language - A simple template that creates a very small, generic language tobuild upon, including only two domain concepts, and a notation comprising one boxand one line (this is the generic directed graph with assigned types and properties).

26

• Simple Architecture Chart - A template that includes an example of each of the nota-tional elements currently supported.

• Entity Relationship - A template that can be used to create compartment shapes.

• Activity Diagrams - A template that demonstrates UML activity diagram notation.

• Class Diagrams - A template for UML class diagram notation.

• Use Case Diagrams - A template for UML use cases notation.

According to the documentation, the internal core metamodel is Microsoft’s own work,this is also supported by their statements criticizing MOF and XMI [13].

Well-formedness rules At this state of development, only simple static constraints (e.g.type and containment) are supported; only batch mode evaluation is available.

Dynamic semantics There is no current, nor planned support for dynamic semantics.

Transformations There is no current, nor planned support for model-to-model transfor-mations. Model-to-code transformations are supported through a template engine, based onC# scripts.

Integration The DSL Tools suite is integrated into Microsoft’s leading development plat-form, Visual Studio. However, as the DSL Tools suite is essentially a technological demonstra-tion, no other integration options have been implemented (and the documentation is ratherself contradictory on this topic).

Persistence Models are stored and exported in XML files.

2.4 VMTS

Note: this short review is based on the official VMTS homepage[48], and a study comparingdifferent prototype model transformation tools[10].

The Visual Modeling and Transformation System (VMTS) is an integrated metamodelingand model transformation system, developed at the Department of Automation and AppliedInformatics of the Budapest Univertity of Technology and Economics. For model visualisationand domain-specific modeling, a tool called Adaptive Modeler is available. As of October 2005,the current version of the suite is 0.95.

Architecture The VMTS is a client-server application with a relational database backend.On the server side, the metamodeling core and the rewriting engine reside, while client sideconsists of the Rule Editor, Modelers and other applications.

Typical workflow As of now, automatic generation of domain-specific editors for VMTS isonly partially supported, manual coding is required for visual syntax and editing functionality.

27

Figure 2.3: VMTS Presentation Framework - Adaptive Modeler 0.95

Concrete syntax The VMTS Presentation Framework is a class library which supplies: (i)built-in base classes for the general presentation facilities of shapes (nodes) and lines (edges).(ii) Automatic event handling for the common functionalities such as resizing, moving and se-lecting model elements. (iii) Automatic serialization for the properties of the model elements.(iv) Sophisticated presentation of attributes, model structure, visualization information andediting features[10].

Abstract syntax VMTS uses Attributed Graph Arhitecture Supporting Inheritance (AGSI)as its core metamodel, which basically describes a directed labeled graph.

Well-formedness rules OCL constraints (compiled into a .NET assembly) are supported,with static constraints enforced at editing time.

Dynamic semantics None.

Transformations As VMTS was primarily intended to be a metamodeling and modeltransformation framework, a powerful, graph transformation-based model transformation en-gine is provided, using a UML-like notation.

Integration VMTS offers a Traversing Model Processor interface, where the model elementsappear as regular objects in a programming language, and traversing classes are also providedby the framework. The types of these objects are obtained from the metamodel[10].

28

2.5 Eclipse

2.5.1 The Eclipse Integrated Development Environment

The Eclipse Project[6] is an open source software development project dedicated to providinga robust, full-featured, commercial-quality, industry platform for the development of highlyintegrated tools. It was developed by IBM from 1999, and a few months after the first versionwas shipped, IBM donated the source code to the Eclipse Foundation.

The Eclipse project consists of many subprojects, the most important being the EclipsePlatform, that defines the set of frameworks and common services that collectively make up”integration-ware” required to support a comprehensive tool integration platform. These ser-vices and frameworks represent the common facilities required by most tool builders, includinga standard workbench user interface and project model for managing resources, portable na-tive widget and user interface libraries, automatic resource delta management for incrementalcompilers and builders, language-independent debug infrastructure, and infrastructure fordistributed multi-user versioned resource management.

The Eclipse Platform has an easily-extendable modular architecture, where all function-ality is achieved by plugins, running over a low-level core called Platform Runtime. Thisruntime core is only responsible for loading and connecting the available plugins, every otherfunctionality, such as the editors, views, project management, is handled by plugins. Theplugins bundled with Eclipse Platform include general user interface components, a commonhelp system for all Eclipse components, project management and team work support.

2.5.2 Eclipse Modeling Framework

The Eclipse Modeling Framework (EMF)[7] is a Java framework and code generation facilityfor building tools and other applications based on a structured model. EMF is also maintainedby the Eclipse Foundation within the scope of Eclipse Tools Project. EMF started out as animplementation of the OMG Meta Object Facility (MOF) specification, and evolved into ahighly efficient product for model-based software design.

EMF requires a metamodel as an input; it can import metamodels from different sources,such as Rational Rose, XMI or XML Schema documents, or a special syntax can be used toannotate existing Java source files with EMF model properties. Once an EMF model is speci-fied, the built-in code generator can create a corresponding set of Java implementation classes.These generated classes can be edited to add methods and instance variables; additions willbe preserved during code-regeneration. In addition to simply increasing productivity, build-ing an application using EMF provides several other benefits like model change notification,persistence support including default XMI and schema-based XML serialization, a frameworkfor model validation, and a very efficient reflective API for manipulating EMF objects gener-ically. Most important of all, EMF provides the foundation for interoperability with otherEMF-based tools and applications.

EMF consists of two fundamental frameworks: the core framework and EMF.Edit. Thecore framework provides basic generation and runtime support to create Java implementationclasses for a model.

EMF has a built-in serialization facility, which enables the developer to save (and load) in-stances of the model into industry-standard XMI format. EMF also provides a notational andpersistence mechanism, on top of which model-manipulating tools can easily be constructed.

29

EMF.Edit is a framework which includes generic reusable classes for building editors forEMF models. It provides content and label provider classes, property source support, andother convenience classes that allow EMF models to be displayed using standard Eclipse userinterface views and property sheets. It also provides a command framework, including a setof generic command implementation classes for building editors that support fully automaticundo and redo for models. Finally, it provides a code generator capable of generating every-thing needed to build a complete editor plugin for an EMF model. It produces a properlystructured editor that conforms to the recommended style for Eclipse EMF model editors.The code can then be customized without losing connection to the model. For example, usingGEF, a graphical editor can be created.

EMF and EMF.Edit together implement the Model-View-Controller (MVC) design scheme,where EMF serves as the model, EMF.Edit serves as a controller and the user can freely de-cide how the view is implemented. The connection between the controller and the model usesthe aforementioned EMF notification mechanism. EMF.Edit can also automatically generatea tree-view based editor, which integrates into the Eclipse platform as a plugin.

2.5.3 Graphical Editing Framework

The Graphical Editing Framework (GEF) for Eclipse is an open source framework dedicatedto providing a rich, consistent graphical editing environment for applications on the EclipsePlatform. In other words, it is a complex system, or graphical library, designed to makedeveloping graphical editors for Eclipse easy and quick. Eclipse is, apart from being a greatIntegrated Development Environment, a general design tool in the sense that its modularplugin centered design enables the user to integrate graphical modeling tools, interface editorsand other GUI-driven components into this rich environment, and have these work togetherflawlessly. In order to avoid confusing the users with numerous different-looking and workinginterfaces, and to enable developers to create graphical plugins quickly and efficiently, thisframework was developed by the Eclipse Project.

The word Graphical in GEF is provided by Draw2D, a lightweight graphical componentlibrary. Lightweight means that Draw2D elements (unlike SWT1 widgets) do not require aseparate handle from the operating system window manager. The advantage of a lightweightsystem is that an entire element hierarchy is seen as a single element from the outside, thereforethe management of the elements lies completely in the hands of the lightweight framework.That means an increase of speed in case the number of elements is large. The lightweightlibrary can generally optimize the management of its elements at a greater extent than an”outsider” window manager could. Draw2D elements are called figures, and any Draw2Dfigure may contain other figures. The only constraint imposed on a figure hierarchy is thatchild figures must lie entirely within the boundaries of their parent. Draw2D includes a basicset of predefined figures (polygons, labels, borders, buttons, arrows, ...) but developers mightcreate their own user-drawn figures.

The Editing capabilities of GEF are very similar to the Eclipse Platform itself. It usesthe request-command abstraction scheme. That means that every user activity (keystrokes,mouse operations) is first translated to requests. Such a request is more abstract than anOS-level mouse of keyboard message. An example of a GEF request would be something like:Model object Place0 has been dragged from position (15, 21) to position (42, 7). These requests

1Standard Widget Toolkit, the default widget library of Eclipse Platform products.

30

MODEL

VIEWVIEW

GEF EditPart(Controller)User

sees

acts

modifies

updates

queries

notifies

Figure 2.4: MVC scheme inside the Graphical Editing Framework

are received by the model elements involved and translated to one or more commands. Acommand is responsible for the effective modification of the model.

Actions

Actions are very similar to requests, they represent certain user activity. The major differencebetween actions and requests are that requests are generated by GEF internally (eg. when themouse is dragged on a GEF-handled area of the screen), while actions can be generated pro-grammatically. Generally graphical editing operations create requests, whereas menu items,toolbar buttons generate actions. Both requests and actions create commands to modify themodel.

GEF follows the Model-View-Controller (MVC) pattern. MVC divides the responsibilitiesof an editor and assigns them to three distinct elements. The model is solely responsible forrepresenting the data being displayed. That includes serialization (if required) and modelmanipulation. The model itself is not required to be aware that there is a graphical editorbuilt upon it. The view, on the other hand, is only responsible for the visualization of themodel. The view does not care about model manipulation, it just simply updates itself fromtime to time to reflect changes in the model. What forms the bridge between the two isthe controller. The controller is responsible both for modifying the model according to useractivities, and for updating views when the model changes. The controller is the element,which accepts editing requests and modifies the model. After the model has been modified,the controller asks the affected view elements to refresh themselves. GEF does not careabout what kind of model we are using, the views are required to be Draw2D figures and thecontroller is provided by GEF, it is called EditPart.

However from the developers perspective, it is the Framework that makes the difference:although one can create a general purpose graphical interface with Draw2D or any othergraphical library, GEF was specifically designed for graphical editors. Thus, if the goal isto not only display data, but also be able to manipulate it, one should consider using GEFinstead of implementing everything from scratch. GEF provides ready solutions for a list ofcommon editor problems (drag-and-drop, property sheet handling, tree-based visualization,clipboard support, ...) and the parts of GEF are closely related to each other, and beentested together. GEF has already been successfully used for commercial applications, like

31

UML editors, GUI builders and workflow management software.

2.5.4 Domain-specific editors with EMF and GEF

Using EMF and GEF, editors for domain-specific visual languages can be implemented -although not very easily. EMF has a lot of automated features, but connecting a GEF-based visualisation layer to an EMF model is a tough job, certainly not suited for non-programmers/domain experts, as demonstrated by [19, 30].

Typical workflow The typical workflow for creating an EMF-GEF-based editor couldbe the following: (1) first, the domain metamodel is defined in some UML tool; (2) thismetamodel is imported into EMF, and EMF generates all the necessary implementationclasses with notification and serialisation support, etc; (3 - optional) using EMF.Edit, a tree-view based editor can be generated - at this point, a usable, tree-based domain-specific editor,in the form of an Eclipse plugin, is ready to be used (and it was automatically generated); (4)the necessary classes for GEF are implemented manually; (5) a code generator is implementedmanually, for instance with the powerful Java Emitter Templates API (JET)[8].

Concrete syntax Automated support is only available for a tree-view based editor, every-thing else has to be implemented manually. Draw2D includes a fairly rich set of commongraphics primitives.

Abstract syntax EMF uses an own core metamodel called ECore, which is almost identicalto Essential MOF (MOF 2.0). Every imported metamodel is mapped onto ECore concepts.

Well-formedness rules Only simple static constraints are supported, as EMF currentlylacks OCL support.

Dynamic semantics Since there is no automated support, dynamic semantics, and modeltransformations in general can only be implemented using EMF’s model manipulation API.

Transformations As EMF is only a model container, no model-to-model transformationis supported. Code generation has to be implemented manually, however, the Java EmitterTemplates API is a very powerful template engine using a special template language (withJSP-like syntax).

Integration EMF supports XMI serialization, and can import metamodels from XMLSchema Descriptions, Rational Rose models, and XMI files.

2.5.5 Eclipse GMF

Even though both EMF and GEF are fairly powerful tools in the hands of a professionalJava programmer, the Eclipse developers have realised that, in their current from, thesetechnologies are simply inadequate for rapid language engineering. Thus, an intermediateframework was drafted, which would serve as a generative bridge between EMF and GEF,

32

whereby a diagram definition would be linked to a domain model as input to the generation ofa visual editor. This is The Graphical Modeling Framework[14] project, which aims to providethe fundamental infrastructure and components for developing visual design and modelingsurfaces in Eclipse.

The Graphical Modeling Framework is currently a draft, with a set of project requirements[15]and a project plan published on the website, on which our review is based on.

Architecture GMF uses generated editors, which are planned to support the followingfeatures: Palette, Properties, Overview (bird’s eye view), Zoom, Navigator, Outline, Decora-tors, Keyboard bindings, Direct editing, Drag and drop, Layout, Support standard graphi-cal editor facilities (actions, rulers, guides) provided by GEF, Provide support for compart-ments/subcompartments, Feedback (in status line) for constraint violation, advice; and Filterviews.

Typical workflow The typical workflow to create a domain-specific editor and a code gen-erator is the following: (1) create an ”EMF model” (which is actually the domain metamodel);(2) create diagram metamodels; (3) refine the domain metamodel on a graphical interface, addOCL constraints; (4) design the visual representations for diagram elements using a graphicalinterface; (5) generate the domain-specific visual editor; (6) use the generated Eclipse plug-infor modeling; (6) manually implement a JET-based code generator; (7) generate applicationcode.

Concrete syntax The GMT project plans a full-fledged visual toolkit based on Draw2Dprimitives, using an intuitive graphical interface integrated into Eclipse.

Multi-domain visualisation A diagram definition may be mapped to zero or moredomain models. In other words, a digram may contain elements which represent informationfrom multiple domain models.

Diagram modeling support A diagram may contain multiple references to a singledomain model element, potentially with each having a different diagram representation. Adiagramming metamodel will be provided to allow for diagram definitions. A mapping meta-model will be provided to allow for diagram to domain model mapping definitions. Diagramelements may not map directly to domain model elements, but rather be a derived value ofsome expression or query. For example, a hierarchical or flat view representation of a UMLclass as defined in ”The UML Profile for Framework Architectures” requires information froman entire class hierarchy for representation on a diagram.

Abstract syntax The GMF allows for the creation of a new EMF model using a graphiceditor, leveraging an ECore modeling surface.

Well-formedness rules Diagram and/or domain models may have constraints added whichneed to be manifested as feedback in the graphical editor. For example, a constraint indicat-ing that circular relationships are not allowed should be indicated in the UI while attemptingto make such a connection (editing time enforcement). Constraints may be defined in the dia-gram and/or domain models that are more appropriately checked in a batch mode, as is done

33

with the EMF validation framework. GMF should allow for constraints to be enforced usingthis or similar framework. GMF will provide support for the Object Constraint Language(OCL).

Dynamic semantics None.

Transformations Only model-to-code generation using JET.

Integration

Persistence Diagrams are stored in files using XML/XMI capability of EMF. Alterna-tive persistence mechanisms are planned to be made available via extension points. Export:Printing, Images; UML Diagram export support via Diagram Interchange Specification; Teamintegration support.

2.5.6 openArchitectureWare

Note: this short review is based on the official openArchitectureWare homepage[32], and apublication by the principal authors, Markus Volter and Bernd Kolb[23].

The openArchitectureWare framework is a suite of tools and components assisting model-driven software development. It is an open source project with around 10 active developers.

History Originally, the framework was developed as a commercial product by a Germancompany called b+w GmbH [2]. As of 14 September 2003, the b+w Generator Framework isdeveloped as an open source project, hosted at SourceForge. Since the original code commit,many features have been added. The openArchitectureWare framework has been successfullyused in a wide spectrum of industrial applications.

Architecture The openArchitectureWare framework (oAW) is a comprehensive tool suitefor model-driven software development. The project is made up of several components (allwritten in Java):

• Core: A modular MDA/MDD generator framework supporting arbitrary import for-mats, meta models, and output formats.

• Utilities: A lot of useful utilities for the generator.

• Eclipse Plugin: Eclipse IDE support for openArchitectureWare.

• Metamodel Generator: Automating the manual development of Java metaclasses.

• Feature Modeling: Integrating openArchitectureWare with the pure::variants featuremodeling tool.

• GEF Editors: Generating GEF Editors for oaW models.

• Visio Integration: Reading visio models into oAW.

34

Figure 2.5: openArchitectureWare

Typical workflow The typical workflow for creating a domain-specific visual editor andcode generator in oAW is the following:

1. The metamodel is created, either by manually coding Java classes or using the Meta-model Generator (which can generate these Java classes from a UML model).

2. Java classes responsible for visual representation are implemented manually by thelanguage engineer.

3. The visual editor generator creates a GEF-based editor.

4. Models are created using this visual editor.

5. The templates are written in oAW-s own domain-specific template language (there isan intelligent editor available with Code completion and syntax-highlighting supportavailable).

6. An existing model is imported and instantiated, which can be validated against thedomain metamodel.

7. The Generator will create an Eclipse editor, based on the domain metamodel.

8. Code can be generated using this editor and the templates.

Concrete syntax

Automated support Although there is a thin component library for GEF visualisationclasses available, concrete syntax representation classes have to be implemented manually.

35

Multi-domain visualisation Not supported. All editors generated in oAW are logi-cally bound to one metamodel.

Diagram-model mapping As the graphical editor generator is in a very early stage ofdevelopment, there is absolutely no automated support for a custom diagram-model mapping.The generated GEF editors are rather simple, there is no conceptual separation betweendiagrams and models.

Abstract syntax openArchitectureWare uses a very flexible approach, as there is no fixedcore metamodel, instead any Java class can be used as a metamodel element. This has obviousadvantages, but can be cumbersome because knowledge of the Java programming languageis required even for a basic metamodel definiton. Thus, a Metamodel Generator feature wassoon added, which can generate classes based on a UML model, in which case, stereotypesand tagges values are required (there is a pre-defined base UML model).

Well-formedness rules Static constraints from UML models are supported. The staticconstraints can only be evaluated in batch mode. There is preliminary support for declarativemetamodel constraints.

Dynamic semantics There is no support for dynamic semantics.

Transformations Only model-to-code transformations are supported, using the powerfuloAW template engine and a domain-specific textual language for creating templates.

Integration

• UML tool support

– MagicDraw

– Enterprise Architect

– Poseidon

– Together/J

• Generator Utilities

– ANT integration

– Integration with JUnit

– Event-Based Modelmodifiers to update dependent parts of a model

– various frontends (instantiators), e.g. a generic XML reader, an instiator to readMicrosoft Visio models

– a generic XML writer

– Invokers to handle ”cross-cutting concerns” in the generator

36

Figure 2.6: Petri net editor generated with Tiger

2.5.7 Tiger

Note: this section is based on the official Tiger website[39], the User Documentation[40], anda publication by the authors[11].

The Tiger Project (Transformation-based generation of modeling environments) is a toolenvironment that allows to generate an Eclipse editor plugin based on the Graphical EditingFramework (GEF) from a formal, graph-transformation based visual language specification.

At the current stage of development, the Tiger framework can generate GEF-based dia-gram editors using combined domain and diagram metamodels, with a tool called AttributedGraph Grammar System (AGG-Engine)[1]. Tiger’s approach is quite interesting for two rea-sons: (i) some of GEF’s graphical concepts (such as drawing primitives, layout constraints)have been included in the metamodel and thus Tiger is able to generate code which usesGEF’s advanced graph layout algorithms to generate diagrams in an elegant fashion; (ii) indomain-specific editors generated with Tiger, all editing actions are translated into high-levelgraph-transformation rules which are executed within the model container - in other tools,basic editing functionality uses API calls. The authors call this syntax-directed editing, whichbasically means the on-line enforcement of well-formedness constraints, in effect making thecreation of syntactically incorrect models impossible. Note, however, that for simple staticconstraints this can be and actually is guaranteed in most other tools using the traditionalapproach.

Architecture The Tiger project uses generated Eclipse plug-in editors, which currentlyprovide very basic editing capabilities. Models are stored in the AGG graph-transformationcore.

Typical workflow The typical workflow to create a visual editor is the following: (1)create a Visual Language specification (which includes both abstract and concrete syntax)using the provided Java classes (tiger.vlspec) - this currently requires manual coding; (2) loadthe Visual Language into a separate software component and edit the syntax grammar; (3)use the tiger.generator component to generate the GEF-based editor.

37

Concrete syntax Tiger provides a basic set of ShapeFigures which can be assigned tomodel elements (these include Ellipse, Circle, RoundedRectangle, RectangleFigure, Polygon).Additional attributes like color and size can be assigned to these ShapeFigures. Layoutconstraints (e.g. ”a token is inside a place”) can be defined between ShapeFigures using Javalanguage constructs.

Abstract syntax Tiger’s core metamodel describes a directed labeled graph. Nodes arecalled NodeSymbolType, edges are called EdgeSymbolType; attributes (AttributeType) can beassigned to both edges and nodes. In the Tiger core metamodel, nodes and edges need to beconnected through links (LinkType - these are the definitons for simple type constraints foredges.

Well-formedness rules Tiger uses grammar syntax to capture both static and language-specific well-formedness rules (these are basically graph transformation rules).

Dynamic semantics Although support is planned, currently the specification and execu-tion of dynamic semantics is not supported.

Transformations As Tiger is based on a graph transformation engine, there is a possiblityto support both model-to-model and model-to-code transformations; at the current stage,however, none of them are.

Integration Not applicable due to the early stage of development; however as Tiger gener-ates Eclipse plug-ins,all standard integration features of Eclipse (e.g. Team Synchronizationsupport) are available.

Summary

The summary of our reviews can be seen on Table 2.1.

38

Ecl

ipse

yes

own

AP

Ipl

anR

un-t

ime

yes

GT

AS

Mye

son

line

batc

hye

sye

sV

PM

yes

yes

yes

plan

Via

tra2

DS

M

Ecl

ipse

Ecl

ipse

Ecl

ipse

no

Ecl

ipse

Vis

ual

Stu

dio

SO

AP

14

no?*?yes

noyes

13

?

XM

I

XM

I

Rel

.D

BM

S

XM

L

XM

L

own

12

Inte

gra

tio

n

basi

c

Pro

f.

*

Bas

ic

Bas

ic

Pro

f.

Pro

f.

108

7

3

Arc

hit

ectu

reL

ang

uag

e E

ng

inee

rin

g

119

Tra

nsf

orm

atio

ns

Dyn

a-m

icS

eman

tic

s

Wel

l-fo

rmed

nes

s

Ab

st-r

act

Syn

-tax

Co

ncr

ete

syn

tax

?G

ene-

r ate

dye

sG

Tpl

anO

nlin

e?

yes

yes

AG

Gno

no?

No*

*T

iger

AP

IG

ene-

rate

dJE

Tno

noon

line

batc

hye

sye

sE

Cor

eye

sye

sye

sye

sG

MF

AP

I*

JET

**

*no

yes

EC

ore

**

*no

EM

F/G

EF

AP

IN

on-

gen.

yes

GT

no?

yes

yes

AG

SI

?ye

s?

noV

MT

S

AP

IG

ene-

r ate

dye

sno

noba

tch

?ye

sJ a

va

clas

sno

nono

nooA

W

AP

IG

ene-

r ate

dye

sno

noba

tch

noye

scu

stom

yes

yes

noye

sD

SL

Too

ls

AP

IR

un-

time

yes

?no

onlin

eba

tch

yes

yes

cust

om?

yes

noye

sM

etaE

dit+

65

43/

23/

12

1

Tab

le2.

1:T

hesu

mm

ary

ofou

rre

sear

ch

39

Legend to Table 2.1 See also 2.2 for detailed explanation.1 - graphical syntax designer; 2 - multi-domain design; 3/1 - diagram-model conceptual separation;3/2 - arbitrary diagram-model mapping; 4 - static constraints; 5 - language-specific constraints; 6- constraint enforcement; 7 - model-to-model transformations; 8 - model-to-code transformations;9 - runtime framework or generated editors; 10 - editing capabilities; 11 - accessbility; 12 -persistence; 13 - documentation generation; 14 - integration (advanced features)‘*’: as EMF/GEF are not suited for automatic editor generation, most of the categories are leftblank because they all depend on the individual implementations.‘**’: although Tiger has no automated support for the interactive design of concrete syntaxrepresentation, an easy to use (albeit limited in capabilities) library is provided.

Evaluation

By looking at Table 2.1, the following conclusions can be drawn:

• Concrete syntaxEasy-to-use graphical syntax designers require a lot of effort to implement well. Incommercial products, such as MetaEdit+ or DSL Tools, this is considered a very impo-rant feature because it ”sells” the software better, however, in research projects this isusually one of the last development targets.

• Abstract syntaxAll projects use a core metamodel which describes a typed, labeled graph with at-tributes (in some cases, this core metamodel is an ECore or MOF model). This is fairlystraightforward because visual languages are, in essence, typed and labeled graphs withattributes.

• ConstraintsFor simple constraints, all approaches use an on-line evaluation scheme, while languge-specific constraints, if supported, are usually handled by a batch-mode OCL evaluator.

• Dynamic semantics / SimulationIt is apparent that - with the exception of Tiger - no project supports (or even plansto support) dynamic semantics modeling. In some cases, this feature could be addedusing the application programming interface; the lack of a model-based approach todynamic semantics specification can be explained by the fact that it would require amodel transformation infrastructure, which only Tiger and VMTS use.

• Model-to-model transformationsModel-to-model transformations, if supported, are based on a graph transformationtechnique.

• Model-to-code transformationsCode generation is usually implemented with a template engine (e.g. JET), or a cus-tom domain-specific programming language, suited for easy modelspace traversal andformatted code output.

• Architecture

40

– Most approaches use code-generated domain-specific editors because they are usu-ally easier to implement (although usually limited in capabilities, e.g. no multi-domain support).

– With the exception of professional products, currently all projects provide fairlylimited editing cabilities, in spite of the powerful integrated environments theseeditors run in.

– Persistence: most projects use in-memory modelspace containers, with the excep-tion of VMTS (RDBMS backend), and MetaEdit+ (custom Object Repositoryserver). All products support serialization and model export into some standardXMI or XML format.

• IntegrationWhile many projects support (on even rely on) external (meta)models for editor codegeneration, some require manual Java coding, or non-automatic model conversion by aprofessional. Documentation generation, similarly to visual syntax editors, is unique tocommercial products (MetaEdit+, DSL Tools). Many projects integrate into popularIntegrated Development Environments (Visual Studio, Eclipse), which can be considereda must since nowadays most software developer houses use these even for the smallestprojets.

2.6 Our approach

It is clear from our review that while many initiatives provide support for some aspects oflanguage engineering, a comprehensive domain-specific modeling environment that integratesall aspects of language engineering and provides efficient ways of domain integration is not yetexistent. The Multi-Doman Systems Engineering approach requires all of the above conditionsto be met.

To provide this all-round solution, we propose a domain-specific modeling frameworkbuilt on top of a powerful model transformation architecture. With this approach, all aspects(with the exception of concrete syntax) of language engineering can be handled within thesame (programming) domain (i.e. a high-level domain specific language suitable for definingmetamodels and model transformations).

In our approach,

• the precise specification of domain-specific visual languages can be described using ahigh-level formal language;

• the abstract syntax of these languages can be defined using visual and precise meta-modeling techniques;

• modeling constraints, model transformations, model simulation and code generationcan be uniformly specified by a combination of graph transformation and abstract statemachines.

An overview of our approach is presented on Fig 2.7.The implementation criteria for our system are as follows (see also the last row of Ta-

ble 2.1):

41

Platform

VPM Modelspace

Domainmetamodel(s)

Domainmodel(s)

DSM coremetamodel

Conceptualmetamodel

Conceptualmodel

GTASM

Generated code

GTASM

DSM framework

GTASM -simulation

Domain editor / simulator

Import

Externaltool

GTASM

Export

Figure 2.7: Our framework in the DSM approach

42

Architecture The system consists of two main components: (i) a model transforma-tion framework; and (ii) a domain-specific modeling environment. The model transforma-tion framework provides the necessary infrastructure model persistence, model-to-model andmodel-to-code transformations, and model import/export. The domain-specific modelingenvironment presents domain-specific views of the integrated modelspace, and provides richediting and simulation facilities, based on the services of the model transformation framework.

Runtime domain-specific editors Our approach uses a runtime framework for sup-porting domain-specific editors, because this facilitates a more rapid development process fordomain-specific editors and simulators. This approach also makes supporting a multi-domainmodeling environment easier.

Editing capabilities The system is integrated into the Eclipse development environ-ment. The domain-specific editors make use of the standard workbench features (Propertiesview, undo-redo support, copy-cut-paste support) as well as some advanced techniques (in-telligent text completion and validation).

Accessibility In our approach, the domain-specific editors can be tailored to the needsof the target application domain in various ways:

• an Application Programming Interface (API) is provided for the implementation ofconcrete syntax, based on the GEF and Draw2D libraries;

• a set of powerful domain-specific programming languages (Viatra2 languages, see 3 fordetails) for specifying modeling constraints, model transformations, model simulationand code generation;

• the system can also adapt to other model containers and model transformations envi-ronments as necessary.

Concrete syntax

Visual editors We use a highly customizable and platform independent graphical ap-plication programming interface (GEF), which enables language engineers to create arbitraryconcrete syntax representations. We do not consider the automated visual support for con-crete syntax design a high priority, but our flexible implementation allows for the integrationof easy-to-use visual syntax designers at a later stage of development.

Multi-domain visualisation We consider multi-domain modeling and visualisationcrucial, therefore our approach provides full support for the integration of multiple domain-specific editors into a single environment, with the possibility of switching between variousviews instantly. Moreover, our design allows for model and diagram elements from differentdomains be handled within the same editor (e.g. a graphical interdomain model transforma-tion designer).

43

Diagram modeling support We consider the full conceptual separation of diagramsand models a must, because a tree-based (or even textual) modeling environment can befaster to work with in many scenarios. Moreover, the performance of the whole system canbe improved drastically if the user is free to decide what to visualise graphically. Furthermore,we also consider a flexible approach to model-diagram mapping a necessity, because complexmodels can be visualised in a more intuitive manner if for example aggregate informationcan be mapped to special diagram elements. Our system provides support to both of theserequirements with a flexible application programming interface.

Default concrete syntax representations While our approach relies on manual cod-ing for many aspects concerning the definition of concrete syntax, we provide support fora default, UML-like graphical notation for models so that domain-specific editors can bedeveloped rapidly without any manual coding.

Abstract syntax Our approach is based on the Viatra2 framework, which provides aflexible core metamodeling language (VPM, 3.1.1). We define a core metamodel for domain-specific visual languages using VPM concepts, which is used by the runtime domain-specificeditor framework to provide model editing capabilities to various concrete domain editorsand simulators. As the system is to be integrated into an existing model-based developmentenvironment, existing domain metamodels can be imported using the native import facilitiesof the Viatra2 framework (see 3.5), which can then be mapped automatically to our coredomain metamodel, thereby facilitating the generation of domain-specific editors for domainsthat are external to the system.

Well-formedness rules As the model transformation language of the Viatra2 frameworkis powerful enough to express arbitrary static and language-specific constraints in an intuitiveway (as demonstrated by the example in 3.6.4), our approach uses read-only transforma-tions evaluated in a batch-mode fashion for the enforcement of complex constraints. Staticconstraints that can be handles by the VPM metamodel (containment, type correctness,multiplicity) are enforced in an on-line fashion.

Dynamic semantics As the model transformation language of the Viatra2 frameworkis expressive and intuitive enough for the specification of dynamic semantics (3.6.2), andthe interpreter-based execution of these model transformations is sufficiently efficient, ourapproach provides full support for interactive model simulation.

Transformations As demonstrated in Chapter 3, the Viatra2 framework provides a ro-bust and efficient environment for the specification and execution of model-to-model andmodel-to-code transformations. In the current paper, only intradomain transformations arediscussed, however it can be easily seen that the basic ideas can be adapted to interdomaintransformations (as emphasized by the Multi-Domain Systems Engineering concept). In 3.6.3,we give a simple example for model-to-code transformations.

Integration

44

Persistence Our approach is based on the Viatra2 modelspace container, which pro-vides support for a wide range of output formats, including tagged formats (XML variants)and textual languages.

Documentation With the powerful transformation and template languages of Via-tra2(3.3), development documentation can be generated on-the-fly from models of variousabstraction levels.

Flexibility As our domain-specific modeling framework can be adapted to any modelcontainer, the code generation facilities of EMF (JET) and other technologies can also beintegrated into our concept.

Typical workflow A language engineer would have to perform the following tasks to createa domain-specific editor, simulator, and code generator:

1. Create a domain metamodel using an external tool, the VPM editor of our modelingenvironment, or the Viatra2 Textual Metamodeling Language.

2. Project this metamodel onto the core domain metamodel of the DSM framework (byspecifying an appropriate transformation in the Viatra2 Textual Command Language,or designing one with the model transformation editor).

3. The DSM framework will instantly provide a domain-specific editor with a tree viewand a basic UML-like syntax for diagrams.

4. Using the API of the DSM framework, and Draw2D primitives, create a customizedconcrete syntax representation.

5. Define dynamic semantics using the Viatra2 Textual Command Language, or themodel transformation editor.

6. Define a code generator using the Viatra2 Textual Command Language, or the modeltransformation editor.

Note that the language engineer only has to learn one expressive domain-specific languagefor all aspects of language engineering.

2.6.1 Example: Petri Net

In the next two chapters, the following simple but descriptive domain-specific visual languageexample will be used for demonstrating the feasibility of our approach.

Petri nets (abbreviated as PN) are widely used to formally capture the dynamic semanticsof concurrent systems due to their easy-to-understand visual notation and the wide range ofavailable analysis tools. From a system modelling point of view, a Petri net model is frequentlyused for correctness, dependability and performance analysis in early stages of design. Petrinets are bipartite graphs, with two disjoint sets of nodes: Places and Transitions. Places maycontain an arbitrary number of Tokens. A token distribution defines the state of the modelledsystem. The state of the net can be changed by firing enabled transitions. A transition is

45

Figure 2.8: A sample Petri net with place capacities and arc weights

enabled if each of its input places contains at least one token (if no arc weights are considered).When firing a transition, we remove a token from all input places (connected to the transitionby InArcs) and add a token to all output places (as defined by OutArcs).

46

Chapter 3

Interpreter-based modeltransformation in VIATRA2

3.1 Metamodeling: Definition of Abstract Syntax

In this section, we conceptually follow [3].

3.1.1 Visual and Precise Metamodeling

Currently, most widely used metamodeling languages (e.g. ECore) are derived (with slightvariations) from the Meta Object Facility (MOF) [27] metamodeling standard issued by theOMG. However, as stated in [42], the MOF standard fails to support multi-level metamod-eling, which is typically a critical aspect for integrating different technological spaces wheredifferent metamodeling paradigms (e.g. EMF, XML Schemas) are used.

Therefore, the VPM (Visual and Precise Metamodeling) [42] metamodeling approach waschosen in the Viatra2 framework, which can support different metamodeling paradigms bysupporting multi-level metamodeling with explicit and generalized instance-of relations.

The VPM language consists of two basic elements: the entity (a generalization of MOFpackage, class, or object) and the relation (a generalization of MOF association end, attribute,link end, slot). Entities represent basic concepts of a (modeling) domain, while relationsrepresent the relationships between other model elements1. Furthermore, entities may alsohave an associated value which is a string that contains application-specific data.

Model elements are arranged into a strict containment hierarchy, which constitutes theVPM model space. Within a container entity, each model element has a unique local name,but each model element also has a globally unique identifier which is called a fully qualifiedname (FQN).

Fully qualified names are constructed in a different way for entities and relations:

• an Entity’s fully qualified name is the fully qualified name of its parent and the nameof the entity concatenated (separated with a dot).

• a Relation’s fully qualified name is the fully qualified name of source and the name ofthe relation concatenated (separated with a dot).

1Most typically, relations lead between two entities to impose a directed graph structure on VPM models,but the source and/or the target end of relations can also be relations.

47

Entity

ModelElement

Relation

instanceOf supertypeOf

containment

from

to

multiplicity: enumisAggregation: boolean

ID: stringName: stringisFinalType: boolean

inverse

value: string

Figure 3.1: The VPM Metamodel

• There is an entity with no parent: the root entity is the root of name hierarchy. Thefully qualified names of the children of the root entity equal the name of the child entity.

The construction of the fully qualified name imposes an important constraint on theVPM modelspace: the containment hierarchy for entities must not contain loops, and forevery relation, it must be true that a finite traversal along the source endpoints ends up atan entity (otherwise, the fully qualified name would be infinite). This constraint is enforcedby the runtime VPM core implementation.

All elements have a globally unique ID, which can not change during the life cycle of themodel element (in contrast, names are free to change).

There are two special relationships between model elements: the supertypeOf (inheri-tance, generalization) relation represents binary superclass-subclass relationships (like theUML generalization concept), while the instanceOf relation represents type-instance rela-tionships (between meta-levels). By using an explicit instanceOf relationship, metamodelsand models can be stored in the same model space in a compact way.

The formal transitivity rules of instantiation and inheritance are the following:

instanceOf(a, b) ∧ subtypeOf(b, c) ⇒ instanceOf(a, c)subtypeOf(a, b) ∧ subtypeOf(b, c) ⇒ subtypeOf(a, c)

instanceOf(a, b) ∧ instanceOf(b, c) 6⇒ instanceOf(a, c)

If the isFinalType attribute of a VPM element is set to true, then only instances of thatmodel element can be created (i.e. the model element cannot be subtyped).

Relations have additional properties:

(i) Property isAggregation tells whether the given relation represents an aggregation inthe metamodel, when an instance of the relation implies that the target element of therelation instance also contains the source element.

48

(ii) The inverse relation points to the inverse of the relation (if any). In a UML analogy,a relation can be considered as an association end, and thus the inverse of a relationdenotes the other association end along an association.

(iii) Relations also have multiplicities, which impose a restrictions on the model struc-ture. Allowed multiplicity kinds in VPM are one-to-one, one-to-many, many-to-one,and many-to-many. This information can be used by the pattern matcher search plangenerator.

3.1.2 The VTML language

In Viatra2, the textual metamodeling language supporting VPM is called VTML (ViatraTextual Metamodeling Language). The technicalities of VTML are demonstrated in Fig. 3.2on a simplified UML metamodel presented originally in the model transformation benchmarkof [10].

Figure 3.2: Sample UML metamodel

The VTML equivalent of the metamodel is as follows.

entity(UML)

{

entity(Class);

entity(Association);

entity(Attribute);

relation(src,Association,Class);

relation(dst,Association,Class);

relation(parent,Class,Class);

relation(attrs,Class,Attribute);

multiplicity(attrs,many-to-many)

relation(type,Attribute,Class);

}

The basic elements of the language are the element declarations defined as Prolog-likefacts. An entity can be declared in the form <type>( <name>), where type is the type ofthe given entity and name is the name of the new entity. Type declarations are mandatory,because all entities must have a type. If an entity has no definite type, it is instantiated fromthe basic VPM entity model element. As entities may contain other model elements, thecontainment is done similarly to the C language, where the program blocks are marked withbraces ({}). Here, the contained elements are represented in a block surrounded by bracesafter the container entity.

49

A relation can be defined similarly, but the source and target model elements must alsobe marked. The syntax of relation definition is the following: <type>(<name>, <source>,<target>). A relation is always contained by its source entity.

The containment hierarchy defines namespaces in the model space. This enables thedefinition of the fully qualified name (FQN) of model elements. The FQN is equal to the listof containers of a given model element from the model space root to the element, separatedby dots. For example, the FQN of the entity Association in the example is UML.Association,while the FQN of the relation src is UML.Association.src. The local (short) name of a modelelement must be unique in its container, this also ensures the uniqueness of FQNs.

Special relationships can be represented by the keywords supertypeOf, and subtypeOf forgeneralization, and typeOf, and instanceOf for instantiation. The syntax is the following:<relationship>( <supplier>, <client>). For example, typeOf(UML.Class, Dog) defines thatthe entity Dog is an instance of the metamodel element UML.Class. This way, a modelelement may have multiple types to support multi-domain modeling.

The VTML language has also a namespace import definition that can be used to importnamespaces for the given VTML file. Model elements that are in the imported namespacescan be referred to using their local names instead of the default fully qualified names foruser’s convenience. Namespace import has the following syntax: import <namespace>; Forexample, if we want to create an instance model using the simplified UML metamodel above,we can use the import UML; command to import the UML namespace. After that, elementsof the metamodel (like UML.Association) can be referred to using their local names (asAssociation).

3.2 The VTCL language

Transformation descriptions in Viatra2 consist of several constructs that together form anexpressive language for developing both model to model transformations and code generators.Graph patterns (GP) define constraints and conditions on models, graph transformation(GT) [9] rules support the definition of elementary model manipulations, while abstract statemachine (ASM) [4] rules can be used for the description of control structures.

The language that is created to implement all these concepts is the Viatra Textual Com-mand Language (VTCL). This language is primarily textual, but it will soon be extended bya graphical editor that will support the graphical definition of model transformations.

3.2.1 Graph patterns

Graph patterns, negative patterns

Graph patterns are the atomic units of model transformations. They represent conditions (orconstraints) that have to be fulfilled by a part of the model space in order to execute somemanipulation steps on the model.

A model (i.e. part of the model space) can satisfy a graph pattern, if the pattern can bematched to a subgraph of the model using a generalized graph pattern matching techniquepresented in [41].

In the following example, a simple pattern can be fulfilled by class instances that do nothave parent classes.

/* C is a class without parents and

50

with non-empty name */

pattern isTopClass(C) =

{

UML.Class(C);

neg pattern negCondition(C) =

{

UML.Class(C);

UML.Class.parent(P,C,CP);

UML.Class(CP);

}

check (name(C)!="")

}

Patterns are defined using the pattern keyword. Patterns may have parameters that arelisted after the pattern name. The basic pattern body contains model element and relationshipdefinitions, which are identical to the VTML language constructs.

The keyword neg marks a subpattern that is embedded into the current one to representa negative condition for the original pattern. The negative pattern in the example can besatisfied, if there is a class (CP) for the class in the parameter (C) that is the parent of C.If this condition can be satisfied, the outer (positive) pattern matching will fail. Thus thepattern matches to top-most classes in parent hierarchy.

There are also check conditions that are Boolean formulae which must be satisfied in orderto make the pattern true. In our example, we check whether the name of the class is empty.The pattern can be matched to classes with non-empty names only.

A unique feature of the VTCL pattern language among graph transformation tools is thatnegative conditions can be embedded into each other in an arbitrary depth (e.g. negations ofnegations), where the expressiveness of such patterns converges to first order logic [35].

Pattern calls, OR-patterns, recursive patterns

In VTCL, a pattern may call another pattern using the find keyword. This feature enablesthe reuse of existing patterns as a part of a new (more complex) one. The semantics of thisreference is similar to that of Prolog clauses: the caller pattern can be fulfilled only if theirlocal constructs can be matched, and if the called (or referenced) pattern is also fulfilled.

Alternate bodies can be defined for a pattern by simply creating multiple blocks after thepattern name and parameter definition, and connecting them with the or keyword. In thiscase, the pattern is fulfilled if at least one of its bodies can be fulfilled. The two features(pattern call and alternate (OR) bodies) can be used together for the definition of recursivepattern. In a typical recursive pattern, one of the bodies contains a recursive call to itself,and the other defines the stop condition for the recursion. The following example illustratesthe usage of recursion.

// Parent is an ancestor (transitive parent) of Child

pattern ancestorOf(Parent,Child) =

{

UML.Class(ParentClass);

UML.Class.parent(X,Child,Parent);

UML.Class(Child);

}

or

51

{

UML.Class(Parent);

UML.Class.parent(X,C,Parent);

UML.Class(C);

find parentOf(C,Child);

UML.Class(Child);

}

A class Parent is the parent of an other class Child, if it is a direct parent of the childclass (first body), or it has a direct child (C), which is the parent of the child class (secondbody). The pattern uses recursion for traversing multi-level parent-child relationships, anduses multiple bodies to create a halt condition (base case) for the recursion.

The semantics of graph patterns

When a predefined graph pattern is called using the find keyword, this means that a substi-tution for the free (unbound) parameters of the specified graph pattern has to be found thatsatisfies the pattern. If there are bound variables passed as parameters, they are treated asadditional constraints, and they remain substituted (bound) throughout the pattern matchingprocess. By default, the free variables will be substituted by existential quantification, whichmeans that only one (non-deterministically selected) matching will be generated. If a variableis universally quantified by the external forall construct (see Sec. 3.2.3), the matching will bedone (in parallel) for all possible values of the given variable.

3.2.2 Graph transformation rules

While graph patterns define logical conditions (formulas) on models, the manipulation ofmodels is defined by graph transformation rules [9], which heavily rely on graph patternsfor defining the application criteria of transformation steps. The application of a GT ruleon a given model replaces an image of its left-hand side (LHS) pattern with an image of itsright-hand side (RHS) pattern.

Figure 3.3: Sample graph transformation rule

The sample graph transformation rule in Figure 3.3 defines a refactoring step of lifting anattribute from child to parent classes. This means that if the child class has an attribute, itwill be lifted to the parent.

The VTCL language allows both popular notation for defining graph transformation rules.The first syntax of a GT rule specification corresponds to the traditional notation: it containsa precondition pattern for the LHS, and a postcondition pattern that defines the RHS of therule. Elements that are present only in (the image of) the LHS are deleted, elements that arepresent only in RHS are created, and other model elements remain unchanged.

gtrule liftAttrsR(in CP, in CS, in A) =

{

52

precondition pattern cond(CP,CS,A,Attr) =

{

UML.Class(CP);

UML.Class(CS);

UML.Class.parent(Par,CS,CP);

UML.Attribute(A);

UML.Class.attrs(Attr,CS,A);

}

postcondition pattern rhs(CP,CS,A,Attr) =

{

UML.Class(CP);

UML.Class(CS);

UML.Class.parent(Par,CS,CP);

UML.Attribute(A);

UML.Class.attrs(Attr2,CP,A);

}

}

The graph transformations rules are defined using the gtrule keyword, and they are allowedto have directed (in/out/inout) parameters. The LHS and RHS patterns share informationon matchings by parameter passing.

The second format directly corresponds to the graphical (FUJABA [31]) notation as shownin the following example.

gtrule liftAttrsR(in CP, in CS, in A) =

{

condition pattern cond(CP,CS,A) =

{

UML.Class(CP);

UML.Class(CS);

UML.Class.parent(Par,CS,CP);

UML.Attribute(A);

del UML.Class.attrs(Attr,CS,A);

new UML.Class.attrs(Attr2,CP,A);

}

}

The rule contains a simple pattern (marked with the keyword condition), that jointlydefines the left hand side (LHS) of the graph transformation rule, and the actions to becarried out. Pattern elements marked with the keyword new are created after a matchingfor the LHS is succeeded (and therefore do not participate in the pattern matching), andelements marked with the keyword del are deleted after pattern matching.

In both cases, further actions can be initiated by calling any ASM instructions within theaction part of a GT rule, e.g. to report debug information or to generate code.

There is also a third format of graph transformation definition that is more likely to theprocedural programming languages. The rule contains a precondition (LHS), like the previousone, but instead of defining the RHS pattern we have to define the actions to be executed.The actions can be any ASM instructions (see Section 3.2.3). The actions that are definedafter the action keyword are executed sequentially. It is important to note that the actionsection can also be used with the other two forms of graph transformation definition, forexample to create debug outputs or generate code.

gtrule liftAttrsR(in CP, in CS, in A) =

53

{

precondition pattern cond(CP,CS,A,Attr) =

{

UML.Class(CP);

UML.Class(CS);

UML.Class.parent(Par,CS,CP);

UML.Attribute(A);

UML.Class.attrs(Attr,CS,A);

}

action

{

new(UML.Class.attrs(Attr2,CP,A));

delete(Attr);

}

}

The interpreter of the Viatra2framework supports all these formats simultaneously, sodevelopers can choose the rule format that is more suitable for them.

Generic and meta-transformations

To provide algorithm-level reuse for common transformation algorithms independent of acertain metamodel, Viatra2supports generic and meta-transformations, which are built onthe multilevel metamodeling support. For instance, we may generalize rule liftAttrsR aslifting something (e.g. an Attribute) one level up along a certain relation (e.g. parent). Thefollowing example is the generic equivalent of the previous GT rule parameterized by typestaken from arbitrary metamodels during execution time.

gtrule liftUp(in CP, in CS, in A,

in ClsE, in AttE, in ParR, in AttR) =

{

condition pattern transClose(CP,CS,A,

ClsE, AttE, ParR, AttR) =

{

// Pattern on the meta-level

entity(ClsE);

entity(AttE);

relation(ParR,ClsE,ClsE);

relation(AttR,ClsE,AttE);

// Pattern on the model-level

entity(CP);

// Dynamic type checking

instanceOf(CP,ClsE);

entity(CS);

instanceOf(CS,ClsE);

entity(A);

instanceOf(A,AttE);

relation(Par,CS,CP);

instanceOf(Par,ParR);

del relation(Attr,CS,A);

del instanceOf(Attr,AttR);

new relation(Attr2,CP,A);

new instanceOf(Attr2,AttR);

}

}

54

Compared to liftAttrsR, this generic rule has four additional input parameters: (i) ClsEfor the type of the nodes containing the thing to be lifted (Class previously), (ii) AttE forthe type of nodes to be lifted (Attribute previously), and (iii) ParR (ex-parent) and (iv) AttR(ex-attrs) for the corresponding for edge types.

When interpreting this generic pattern, the VIATRA engine first instantiates the typeparameters (ClsE, ParR, etc.) and then queries the instances of these types. As a result, thesame rule can be applied in various modeling languages.

Invoking graph transformation rules

To execute graph transformation rules they have to be invoked from a transformation program.The basic invocation is done using the apply keyword. In this case, the actual parameter listof the transformation has to contain a valid value for all input parameters, and an unboundvariable for all output parameters. A rule can be executed for all possible matches (in parallel)by quantifying some of the input parameters using the forall construct. The following exampleillustrates some possible invocations of our sample rule.

//simple execution of a GT rule

//all variables must be bound

apply liftAttrsR(Class1,Class2,Attrib);

//calling the rule for all attributes of a class

//variables Class1 and Class2 must be bound

forall A do apply liftAttrsR(Class1,Class2,Attrib);

//calling the rule for all possible matches

forall C1, C2, A do apply liftAttrsR(C1,C2,A);

3.2.3 Control Structure

To control the execution order and mode of graph transformation the VTCL language includessome concepts that support the definition of complex control flow. As one of the main goalsof the development of VTCL was to create a precise formal language, we included the basicset of Abstract State Machine (ASM) language constructs [4] that have formal semantics andcorrespond to the constructs in conventional programming languages.

The basic elements of an ASM program are the rules (that are analogous with methodsin OO languages), variables, and ASM functions. ASM functions are special mathematicalfunctions, which store values in arrays. These values can be updated from the ASM program.These functions are called dynamic. There are also static functions, which means that theycannot change their values. For example, the basic mathematical functions (+,-,*,/) arestatic.

In VTCL, a special class of functions, called native functions, is also defined. Nativefunctions are user-defined Java methods that can be called from the transformations. Thesemethods can access any Java library (including database access, network functions, and so on),and also the Viatra2 model space. This allows the implementation of complex calculationsduring the execution of model transformations.

ASMs provide complex model transformations with all the necessary control structuresincluding the sequencing operator (seq), rule calls to other ASM rules (call), variable declara-tions and updates (let and update constructs) and if-then-else structures, non-deterministically

55

selected (random) and executed rules (choose), iterative execution (applying a rule as longas possible iterate), and the deterministic parallel rule application at all possible matchings(locations) satisfying a condition (forall).

These basic instructions, combined with graph patterns and graph transformation rules,form an expressive, easy-to-use, yet mathematically precise language where the semantics ofgraph transformation rules are also given as ASM programs. The following example demon-strates the main control structures.

pattern isClass(C) =

{

//simple pattern that recognizes classes

UML.Class(C);

}

rule main() = seq

{

//Print out some text

print("The transformation begins...");

//Call a GT rule for all matches

forall C1, C2, A do apply liftAttrsR(C1,C2,A);

//Call other rule

call printFormatted(123);

//Iterate through all classes

forall Cl with find isClass(Cl) do seq

{

print("Found a class: "+name(Cl));

}

//Write to log

log(info,"transformation done");

}

rule printFormatted(in C) =

{

//Print out the value

print("Value is : "+C);

}

The semantics of some ASM rules are the following:

skip

This rule always succeeds.

return succeed

fail

This rule always fails.

return fail

call

This rule calls an other rule. Parameters of rules are defined in the rule head.

56

create a new context (stack frame)copy input variables of called ruleflag=run called rule with the new contextif(flag==succeed)

copy output variables of called rule into old contextreturn flag

seq

Run all sub rules in the given order.

foreach ( sub-rule: sub rules ){

flag=run(sub-rule)if(flag==fail)

return fail}return succeed

iterate

The iterate rule runs the sub-rule until once it returns with fail.

do-forever{

flag=run(sub-rule)if(flag==fail)

return succeed}

random

Random rule tries to run each sub-rules in random order. When one sub-rule succeeds returnswith succeed. If all fails the entire rule fails.

create random ordering of sub-rulesforeach ( sub-rule: sub rules ){

flag=run(sub-rule)if(flag==succeed)

return succeed}return fail

forall and choose

Forall and choose rules are entirely ASM rules. In GTASM the value universe is the VPMmodel on which the interpreter is working. The forall rule finds all model elements whichsatisfy the given formula. The choose finds the first model element which satisfies the formula

57

Interpreter

Rule interpreter Program cacher Program reader

VPM modelspaceProgram model

Figure 3.4: Caching

(the ordering of model elements is not definite, but need not be random, so two consecutivechoose rules with the same formula may or may not return the same element).

forall X with formula(X) do rulechoose X with formula(X) do rule

Formula of a forall and choose rules can be a graph pattern or a graph transformationrule. In this case, the pattern matcher is used to find matching model elements. For forallcase, parallel pattern matching is performed.

Interpreting the forall and choose rules means:

1. Build constraint model of the pattern (set find all flag for variables in forall case) or getit from the cache (see later)

2. create a new context for matcher

3. copy input parameters

4. call pattern matcher

5. copy output parameters

6. do action with found parameters

print, log

There are two textual outputs of a transformation. These rules put the parameter string tothe output. These outputs are not streams, but the strings are passed as objects to the codeformatter plugins.

3.2.4 Caching program models

The interpreter reads the program from the VPM model. Reading the program from thatmodel is slow. As the GTASM program model is not directly interpretable, so the reader alsoperforms transformations on the program, which can also slow down the program reader.

Caching the program model is the obvious solution to this problem, thus we implementeda program cache module for the Viatra2 interpreter (Fig. 3.4).

58

3.3 Code templates

An important type of model transformations are model-to-code transformations. These trans-formations generate textual output (for example, source code for a programming language,or XML-based descriptors) from models. To support these transformations, VTCL includesthe print instruction that prints out text to the output. This floating text can be formattedby the VIATRA code output formatter modules. For example, Java requires the separationof classes into files, and building a directory structure that reflects the package structure. Aspecial code output module can render the source code to the required format.

While using print is easy, it may be inconvenient in cases where the code generation in-cludes large blocks of static text (that is unchanged), and small amount of dynamic data,which is typical to many code generation problems. To ease the job of code generator design-ers, Viatra2includes the concepts of code templates. This language extension is called ViatraTextual Template Language (VTTL). A template is a text block that can include referencesto ASM variables and instructions. The pattern concept is very similar to the one introducedin the Apache Velocity [45] language, but uses the formal ASM and GT paradigms as thecontrol language. The next example gives a bried insight into the code template language.

template printClass(in C) =

{

public class $C {

#(forall At,Typ with attrib(C,At,Typ) do seq{)

private $Typ $At;

#(})

}

}

The sample template receives an input parameter (that points to a class instance). Itcreates the skeleton of the class in Java. ASM variables can be referred to in templates usingthe $ character. ASM instructions (as the forall that iterated through all attributes of theclass) can be referenced using the #() marking. All possible ASM constructs can be used intemplates.

3.4 Implementing the pattern matcher

3.4.1 Building constraints

The patterns of a GTASM program have the same internal representation as their intendedmatches (patterns and model graphs are stored in the same model space). The first task inmatching such a pattern is to construct a constraint satisfaction problem.

The following is an example for building constraints from a pattern:

ASM.metamodel.machine(Machine);

ASM.metamodel.ASMRules.ruleDefinition(Main);

ASM.metamodel.machine.mainRule(MR,Machine,Main);

This pattern generates the following constraint model:

Variables:Machine, Main, MR

Constants:ASM.metamodel.machine, ASM.metamodel.ASMRules.ruleDefinition,

ASM.metamodel.machine.mainRule

Constraints:

59

Machine is an entity

Machine is an instance of ASM.metamodel.machine

Main is an entity

Main is instance of ASM.metamodel.ASMRules.ruleDefinition

MR is a relation

MR is instance of ASM.metamodel.machine.mainRule

Machine is source of MR

Main is target of MR

3.4.2 Matching patterns

Pattern matching techniques of existing graph transformation tools can be grouped into twomain categories:

• Algorithms based on constraint satisfaction. Constraint satisfaction algorithms interpretthe pattern as variables and constraints between them.

• Algorithms based on local search start from matching a single node and then extendingthe matching step-by-step with neighboring nodes and edges. If more than one possiblematching nodes exist, a choice-point is generated. The search plan determines the num-ber of choice-points. The search plan is the key of efficiency of local search algorithms,because the number of choice-points has to be minimised.

In the case of pattern matching, constraints are the edges of the graph pattern. In thissense the two approaches have many analogous concepts.

A local search algorithm tries to predict the effect of the constraints, and builds the searchplan in a certain manner to keep the number of choice-points as low as possible. A constraintbased algorithm has current information on the effect of the constraints and generates thesearch plan in a real-time fashion. Although the constraint based implementations may beable to recognize failing branches of the search space sooner, on the other hand, the constraintbased implementations have an overhead of maintaining the constraints and the current setof possible matches for each variable.

The Viatra2 interpreter uses a constraint satisfaction model for defining patterns, butour pattern matcher has a local search algorithm.

The search plan is essentially an ordering of the variables (the pattern matcher will tryto bind the variables in this order). The generation of the search plan uses heuristics forpredicting the cost of selecting a variable as the next choice-point. The search plan generatorprefers edges with more substituted variables (source and target nodes) to edges where allthe variables are unbound. As a result, there are less early decisions in the search tree, whichis a common technique in artificial intelligence.

With the search plan constructed, the search itself is simple:

1. Use one of the constraints to enumerate all possible matches for the current variable;

2. Check all constraints which have all variables matched;

3. With matches go on with the next variable to 1.

The generation of the search plan on the example pattern is the following:

60

Variables:Machine, Main, MR

Constants:ASM.metamodel.machine,

ASM.metamodel.ASMRules.ruleDefinition,

ASM.metamodel.machine.mainRule

Constraints:

Machine is an entity

Machine is an instance of ASM.metamodel.machine

Main is an entity

Main is instance of ASM.metamodel.ASMRules.ruleDefinition

MR is a relation

MR is instance of ASM.metamodel.machine.mainRule

Machine is source of MR

Main is target of MR

1. Machine, Main and MR are the variables. First their type is defined, so the orderer willchoose one of them to be the first. Let’s assume that Machine is the first.

2. MR has the source defined, so MR will be the second.

3. There is only one variable left, so Main is the third in the order.

3.4.3 Caching the pattern search plan

Pattern matching starts with generating a search plan, and the subsequent use of one patternmay generate statistical information or modify the initial search plan. To avoid the unneces-sary regeneration of search plans for identical patterns, the interpreter uses the same patterninstance when the program calls the same pattern with the same type of parameters.

3.4.4 Related work

All graph transformation based tools use some clever strategies for pattern matching. Sincean intensive research has been focused to graph transformation for a couple of decades, severalpowerful methods have already been developed.

While many graph transformation approaches (such as [24] in AGG [12]) use algorithmsbased on constraint satisfaction, here we focus on the three most advanced compiled ap-proaches with local searches using search plans.

Fujaba [21] performs local search starting from the node selected by the system designerand extending the matching step-by-step by neighbouring nodes and edges. Fujaba fixes asingle, breadth-first traversal strategy at compile-time (i.e. when the pattern matching codeis generated) for each rule. Fujaba uses simple rules of thumb for generating search plans.A sample rule is that navigation along an edge with an at most one multiplicity constraintprecedes navigations along edges with arbitrary multiplicity.

PROGRES [49] uses a very sophisticated cost model for defining costs of basic operations(like enumeration of nodes of a type and navigation along edges). These costs are not domain-specific in the sense that they are based on assumptions about a typical problem domain onwhich the tool is intended to be used. Operation graphs of PROGRES, which are similar tosearch graphs in the current paper, additionally support the handling of path expressions andattribute conditions. The compiled version of PROGRES generates search plan at compile-time by a greedy algorithm, which is based on the a priori costs of basic operations.

The pattern matching engine of GReAT [47] uses a breadth-first traversal strategy startingfrom a set of nodes that are initially matched. This initial binding is referred to as pivoted

61

pattern matching in GReAT terms. This tool uses the Strategy design pattern for the purposeof future extensions and not for supporting different pattern matching strategies like in ourapproach.

Object-oriented database management systems also use efficient algorithms [38] for queryoptimization, but their strategy significantly differs as queries are formulated as object algebraexpressions, which are later transformed to trees of special object manager operations duringthe query optimization process.

3.5 Architectural overview

3.5.1 The VIATRA2 framework

The Viatra2 system is a standalone model container and transformation framework, whichcan be integrated into the Eclipse IDE as a plug-in. In stand-alone mode, the Viatra2system runs as a console application with a command-line console.

Within the Eclipse environment, additional integration components are available:

• a tree-view modelspace editor component, supporting the standard Properties view andundo-redo functionality;

• an Eclipse view which provides an interface to the import/export/parser facilities;

• a Code output view component to visualize the textual output generated by code gen-erators.

The current implementation of the system allows for multiple framework instances withina single Eclipse workbench, thereby enabling users to work with multiple VPM model spaces(and editors) simultaneously.

As it can be seen on Fig. 3.5, the internal structure of the Viatra2 framework can besplit up into four major components:

1. VPM modelspace container and VPM core interfaces

2. Pattern matcher

3. GTASM interpreter

4. Import/export facilities

Our development work consisted of the implementation and optimization of the VPMcore, the pattern matcher, and the GTASM interpreter (marked with red on Fig 3.5).

VPM Core The VPM Core implementation defines a low-level, simple interface. Thisinterface ensures the integrity of the model. All other components, including the editors andimporters, use this interface for queries and modifications. The VPM Core also supports anotification mechanism, an arbitrary depth undo/redo interface, and a simple global lockingmechanism to provide preliminary support for concurrent modifications and asynchronoustransformations.

62

VPM Modelspace ModelGTASM models

Core interfaces

VTMLparser

VTCLparser

VPML

Native importerinterface

GTASMinterpreter

Patternmatcher

Importers

Eclipse integration components

editor GUIOutputformatter

VIATRA2 Framework

Figure 3.5: The architecture of the Viatra2 framework

Import/export facilities To facilitate the integration of the Viatra2 framework intoan existing model-driven development infrastructure, the native importer interface providessupport for the construction of import plug-ins which read native formats and instantiatemodels in the VPM modelspace. The Viatra2 language (VTML and VTCL) parsers arealso implemented as native importers (by Andras Balogh).

Pattern matcher Pattern matching is an experimental subject. The efficiency of the wholemodel transformation system highly depends on the efficiency of model storage and patternmatching. Therefore, we designed the Viatra2 system so that it can be used as a frameworkof future pattern matchers. There are experiments with different matchers (such as [44]). Ifthey were inserted into the Viatra2 framework then all features of the GTASM languagewould automatically work with that implementation (eg. recursive pattern matching andmerging sub-patterns).

3.5.2 The GTASM interpreter

The model transformation interpreter is a complex system (see Fig 3.6). The modular imple-mentation we designed makes it possible to have modules with diverse implementations.

The pattern matcher interface

A higher level VPM model query interface is the pattern matcher. This interface requires amodel of patterns and methods to manipulate them.

The interpreter defines a constraint based pattern definition. Over this model the patternmatcher interface defines a pattern builder. The pattern builder accepts variables, constants

63

GT rules

Program reader

Simple model manipulation rulesASM rules

Find matches or check pattern

Interpreter

Pattern matcher

RHS Solver

Pattern builder interface

Match collector interface

Do action interface

VPM model

Query interface Modification interface

Domain model Program model

Figure 3.6: The architecture of the Viatra2 GTASM interpeter

and constraints between them.For each variable its type must be specified. There are three types of variables:

1. ”find all” output variables (to be bound to all matches)

2. ”find one” output variables (to be bound to the first possible match)

3. input variables (caller must bind to a model element before calling pattern match)

The pattern matcher will return all matches where the ”find all” variables are matchedto different model elements.

The Java interface of pattern matcher allows the following types of constraints:

• constraint on one variable that defines the main type of the element (entity or relation)

• constraint on two variables (these constraint types cover all types of relations betweenmodel elements in a VPM model)

• client defined constraints on one or more variables: these constraints are checked by amethod provided by the client of the module

The constraint based pattern definition is handy for client programs and for patternmatcher implementations as well. The user defined constraints make the system easily con-figurable.

The RHS solver interface

Graph transformation rules have a right hand side (RHS) pattern. This pattern is the goalof the transformation. The graph transformation technique finds all matches of the left hand

64

side (LHS) pattern and changes them to be like the RHS pattern. The RHS solver modulecomputes the difference between the LHS and RHS modules and applies the required actionon the matching of the LHS pattern.

The RHS solver module interface accepts the two patterns of the same model as thepattern matcher. The additional information required for building a list of actions is to bindthe variables of LHS to the variables of RHS.

Let’s assume that the LHS and RHS are identical:

Variables:Machine, Main, MR

Constants:ASM.metamodel.machine, ASM.metamodel.ASMRules.ruleDefinition,

ASM.metamodel.machine.mainRule

Constraints:

Machine is an entity

Machine is an instance of ASM.metamodel.machine

Main is an entity

Main is instance of ASM.metamodel.ASMRules.ruleDefinition

MR is a relation

MR is instance of ASM.metamodel.machine.mainRule

Machine is source of MR

Main is target of MR

If we bind the variables with same name together, the RHS solver will do nothing (asthe LHS and RHS are identical). If LHS:Machine is bound to RHS:Machine but no othervariables are bound to them, the RHS solver will create a new Main rule, and a new MRrelation. The elements matched with LHS:Main and LHS:MR will not change as they arenot bound to RHS variables.

3.6 Language Engineering in VIATRA2

In this section, we propose to use the formal specification language of the VIATRA2 frameworkfor precise language engineering. As a case study, we define the visual modeling language ofPetri nets including its abstract syntax by VPM metamodels (written in VTML), dynamicsemantics for model simulation by a combination of graph transformation and abstract statemachine rules (written in VTCL) and code generation to derive a standard PNML of Petrinet models (written in VTCL). The main advantage of the approach is that a single modeltransformation technology is used for the dynamic issues in language engineering.

3.6.1 Petri net metamodel

The following VTML code defines a simple Petri net metamodel. The metamodel defines threetypes of Petri net elements. They are all subtypes of the abstract type petriNetElement.

entity(petriNet)

{

entity(petriNetElement);

entity(place);

supertypeOf(petriNetElement,place);

entity(transition);

supertypeOf(petriNetElement,transition);

entity(token);

supertypeOf(petriNetElement,token);

relation(inArc,transition,place);

relation(outArc,place,transition);

65

relation(mark,place,token);

}

The following VTML code instantiates a concrete Petri net with two places and two transi-tions.

petriNet(net1)

{

petriNet.place(p1);

petriNet.place(p2);

petriNet.transition(t1);

petriNet.transition(t2);

petriNet.token(token);

petriNet.place.outArc(out1,p1,t1);

petriNet.place.outArc(out2,p2,t2);

petriNet.transition.inArc(in1,t1,p2);

petriNet.transition.inArc(in2,t2,p1);

petriNet.place.mark(mark,p1,token);

}

3.6.2 Petri net simulation with GTASM

The following example is a simple Petri net simulator. It simulates one atomic transition ofa Petri net. The graph transformation rule that finds an enabled transition has a negativecondition as well.

The following code snippet is the frame of the simulation program. The program findsone transition that can be fired at the state that is represented by the model. The secondstep is to delete tokens from the input places. Then tokens on the output places are created,and last the mark from the transition to be fired is deleted. The whole procedure is an atomicstep of the Petri net.

machine psim

{

rule main()=seq

{

// Find a transition and mark it

choose T below Model do apply mark_fireable(T);

// Delete tokens from in places

forall P do apply delete_in_tokens(P);

// Create tokens at out places

forall P do apply create_out_tokens(P);

// Delete the mark from fireable token

forall T do apply delete_fireable(T);

}

...

}

A transition can be fired if it has no input places (the first negative pattern means this).Input places do not block the transition if they are marked. This rule is represented by thesecond negative pattern (double negation). The transition that can be fired at the state ismarked with relation that connects the transition with itself. This new relation is generatedby the RHS of the following transformation rule (see Fig 3.7).

66

Mark_place : GTRule

LHS : pattern RHS : pattern

P : place

T : transition

P : place

T : transition

Tok : token: inArc : inArc

: mark

Figure 3.7: Example Petri net transformation rule

{

...

gtrule mark_fireable(inout T) =

{

precondition pattern lhs(T) =

{

petriNet.transition(T);

// Transition is allowed if it has no in places

neg pattern t_neg(T)=

{

petriNet.transition(T);

petriNet.place(P);

petriNet.place.outArc(Out,P,T);

// Or if all in places has a token

neg pattern t_negneg(P)=

{

petriNet.place(P);

petriNet.token(Tok);

petriNet.place.mark(Mark,P,Tok);

}

}

}

// Mark the transition we found with an edge from and to it

postcondition pattern rhs(T) =

{

petriNet.transition(T);

petriNet.transition.markTransable(M,T,T);

}

}

...

}

The following rule deletes one token from each in place of the firing transition. This ruleis called with forall semantics on variable P, so all in places will match this rule once. Thevariable Tok will match for each place one token that is on that place. This variable has noforall semantics, so only one token will be selected for each place.

gtrule delete_in_tokens(inout P) =

67

{

precondition pattern lhs(P, Tok) =

{

petriNet.transition(T);

petriNet.transition.markTransable(M,T,T);

petriNet.place(P);

petriNet.place.outArc(Out,P,T);

petriNet.token(Tok);

petriNet.place.mark(Mark,P,Tok);

}

// Tok is not part of RHS pattern, so it will be deleted.

postcondition pattern rhs(P, Tok) =

{

petriNet.place(P);

}

}

An additional rule creates one token on each output place of the transition.

gtrule create_out_tokens(inout P) =

{

precondition pattern lhs(P) =

{

petriNet.transition(T);

petriNet.transition.markTransable(M,T,T);

petriNet.place(P);

petriNet.transition.inArc(In,T,P);

}

// Tok is not part of LHS pattern, so it will be created.

postcondition pattern rhs(P) =

{

petriNet.token(Tok);

petriNet.place(P);

petriNet.place.mark(Mark,P,Tok);

}

}

}

The last rule deletes the marking relation from the marked transition. After deleting themark from the firing transition the petri net is in consistent state again and the atomic stepof simulation is ready.

{

...

gtrule delete_fireable(inout T) =

{

precondition pattern lhs(M,T) =

{

petriNet.transition(T);

petriNet.transition.markTransable(M,T,T);

}

// The mark is not part of RHS so it will be deleted.

postcondition pattern rhs(M,T) =

68

{

petriNet.transition(T);

}

}

...

}

3.6.3 Code generation

The following example generates a (domain-specific) Petri Net Markup Language[33] file fromthe Petri net in the VPM model.

machine petri2pnml

{

// This ASM function is a mapping from the VPM entity

// that represents a place

// to the count of tokens at that place

asmfunction tokenCount/1;

rule main(in ModelName) = seq

{

let Model=ref(ModelName) in seq

{

// Count tokens at all places

iterate choose P below Model with find place(P) do seq

{

forall Tok do apply count_token(P,Tok);

}

// print the heading of the PNML file (open tags)

call print_head();

// print all places

forall P below Model do apply print_place(P);

// print all transitions

forall T below Model do apply print_transition(T);

// pring all edges

forall I below Model do apply print_in_arc(I);

forall O below Model do apply print_out_arc(O);

// print tail of the PNML file (close tags)

call print_tail();

}

}

The following simple print rules match on various model elements and print XML tagswith appropriate attributes.

rule print head() = seq

{

// print static header

print("<pnml><net><name><text>example net</text></name>");

}

rule print tail() = seq

{

// print static footer

print("</net></pnml>");

}

69

gtrule print_place(P) =

{

// print a place

precondition lhs(P) =

{

petriNet.place(P);

}

action

{

print("<place id=\"");

print(name(P));

print("\">");

print("<name><text>");

print(name(P));

print("</text></name>");

print("<initialMarking><text>");

print(tokenCount(P));

print("</text></initialMarking>");

print("</place>");

}

}

gtrule print_transition(T) =

{

// print a transition

precondition lhs(T) =

{

petriNet.transition(T);

}

action

{

print("<trnsition id=\"");

print(name(T));

print("\">");

print("<name><text>");

print(name(T));

print("</text></name>");

print("</transition>");

}

}

gtrule print_in_arc(I) =

{

// print an inArc

precondition lhs(I) =

{

petriNet.transition(T);

petriNet.place(P);

petriNet.transition.inArc(I,T,P);

}

action

{

print("<arc"

print(" id=\"");

print(name(I));

print("\"");

print(" source=\"");

print(name(T));

print("\"");

70

print(" target=\"");

print(name(P));

print("\"");

print(">");

print("<inscription><text>1</text></inscription>");

print("</arc>");

}

}

gtrule print_out_arc(O) =

{

// print an outArc

precondition lhs(O) =

{

petriNet.transition(T);

petriNet.place(P);

petriNet.place.outArc(O,P,T);

}

action

{

print("<arc"

print(" id=\"");

print(name(O));

print("\"");

print(" source=\"");

print(name(P));

print("\"");

print(" target=\"");

print(name(T));

print("\"");

print(">");

print("<inscription><text>1</text></inscription>");

print("</arc>");

}

}

Our model stores each token as a separate entity, but PNML requires the number of them,so they must be counted. The following rule matches on a place with a token, and updatesthe appropriate entry in the tokenCount/1 ASMFunction.

gtrule count_token(in P, inout Tok) =

{

precondition lhs(P, Tok) =

{

petriNet.place(P);

petriNet.token(Tok);

petriNet.place.mark(Mark,P,Tok);

}

action

{

if(tokenCount(P)==undef) tokenCount(P)=0;

update tokenCount(P)=tokenCount(P)+1;

71

}

}

}

3.6.4 Checking a constraint on the model

If the metamodel of Petri nets also supports place capacity, which is a positive integer, as-signed to places, it is logical to enforce the validity of this language-specific constraint usingthe functionality provided by the modeling environment.

The constraint on the model is to have a less or equal number tokens at each place thanthe capacity of the given place.

The following VTML snippet extends our previous Petri net metamodel with the conceptof place capacity:

entity (petriNet)

{

// define the additional elements of the metamodel

entity(capacity);

relation(capacityOf, place, capacity);

}

Here, the capacity of places is stored in the values of special auxiliary entites, assigned toplaces with a special capacityOf relation.

The following code can be used to check the constraint:

[...]

rule main(in ModelName) = seq

{

let Model=ref(ModelName) in seq

{

// Count tokens at all places

forall P below Model with find place(P) do seq

{

// the count_token rule from the previous

// example is called at this point.

forall Tok do apply count_token(P,Tok);

call checkPlace(P);

}

}

}

The following rule checks whether the condition specified by the constraint holds on thematched place-capacity subgraph:

rule checkPlace(in P) = seq

{

choose C with find capacity(P, C) do seq

{

// this machine uses the same tokenCount/1 ASMFunction

// as the previous example

72

if(value(C)<tokenCount(P)) do

print("Error: too many tokens on place: "+name(P)+"\n");

}

}

Note: instead of printing an error, the checker could create a special model elementsignaling the editor that a constraint was violated, or create an appropriate entry in thesystem log using the log rule.

This pattern selects the appropriate place-capacity pairs from the modelspace:

pattern capacity(P, C) =

{

petriNet.place(P);

petriNet.capacity(C);

petriNet.place.capacityOf(CO,P,C);

}

}

3.7 Summary

In this section, we introduced the Viatra2 framework, which supplies the modeling andtransformation infrastructure of our Multi-Domain Systems Engineering approach. We gavethe detailed description of our research and development efforts concerning the implemen-tation and optimization of the framework. After establishing the theoretical and practicalbackground necessary to understand how Viatra2 can be used to provide language engineer-ing and domain integration support, we demonstrated the feasibility of our approach by givingconcrete Viatra2-specific implementations of various engineering aspects of a domain-specificPetri net editor and simulator.

In the next section, we describe our implementation of the domain-specific modeling frame-work based on Viatra2, and how the examples provided in this section can be used on anintuitive graphical user interface.

73

Chapter 4

The DSM Framework

In the introduction of our paper and in chapter 2, we were discussing domain specific modeling,a software development methodology which offers a large increase in developer productivity.That is achieved by reducing the development process to simple model manipulation. A do-main specific application model is no longer just part of the system documentation but it isthe primary development product. Source code, which is entirely generated using that model,becomes nothing more than a temporary step in the application deployment process.

The major problem of DSM is the design of the domain specific editor itself. Unlike UML,which covers basically everything that is object-oriented, a given domain in DSM covers onlya narrow, specialized set of applications. So an out-of-the-box editor satisfying the require-ments of a company can hardly be found. Therefore when a software developer companydecides to switch to DSM method, the first step is to create a domain specific editor, whichcovers the domain of their products. That job is done by the domain language engineers, ateam od experienced developers who have a broad knowledge of the domain itself and alsoknow the patterns and best practices of coding.

Creating an editor from scratch is however a very difficult job to do. The languageengineer would have to take care of model representations, graphical editing, source codegeneration, and so on. We want to facilitate the job of language engineers by providing asolution for the common problems that arise during the development of a domain specificeditor. Such a framework allows engineers to focus on the domain language itself instead ofdealing with various implementation specific questions. In chapter 2 we examined multipleexisting DSM frameworks (tools), and compared them according to various aspects, likesyntax representation (both abstract and concrete) or transformation support. Along withthat comparison we established some basic ideas about our own DSM framework. Since wealready have a modeling and transformation engine, Viatra2, it seems a straightforward ideato build such a framework on top of that tool, and make use of its capabilities. In this sectionof our paper, we will introduce our DSM framework, a tool which uses Viatra2 as a modelcontainer, and provides domain specific editing functions, together with simulation and codegeneration support based on graph transformation.

74

4.1 Goals

Our comparison of existing DSM tools in chapter 2 included various criteria. Concrete syntax,which in other words means graphical model representation, is essential in the success of aDSM tool, since it is that what defines mostly how user-friendly the given tool is. A user-friendly tool should support customizable concrete syntax, ie. let the language engineer definehow model elements are being display. Also, in case of modeling complex systems made up ofheterogeneous components, a DSM tool should enable the creation of multi domain diagrams.It is possible that one part of the system is modeled using state machines, whereas an otherpart is modeled with data flow networks. To be able to visualize the interaction between thetwo parts, the DSM tool should support diagrams, where elements from multiple domain maybe displayed at the same time. A third important requirement in terms of concrete syntax isthe separation of model and diagram elements. That separation permits to have diagrams,which only include certain parts of the entire model. In a complex system, we generally donot want to have diagrams containing thousand of model elements, rather we only want todisplay one or more certain sections of the model.

An other comparison criteria was abstract syntax representation. That means how themodels are actually stored within the DSM framework. Most tools use their own built-inmodeling framework (like ECore for EMF), while others (like openArchitectureWare) leavethe problem of model representation to the user. What is important about abstract syntaxis to support the import of metamodels from other modeling tools. DSM tools in generalsupport the import of UML-based metamodels, so a language engineer may reuse an existingmetamodel of the domain.

Finally the third important criteria was dynamic behaviour and transformation support.Dynamic behaviour support means that the language engineer may define how models of theconstructed domain should be run. Dynamic behaviour is essentially a set of rules, whichgovern how the state of the model may change step by step. The reason that support fordynamic behaviour is important is that it enables the simulation of a system without codegeneration. Typically, the way a domain specific editor works is first generating code fromthe model using transformation, then executing that code. Advanced DSM systems provide afeedback, whereby the execution of the generated code can be followed on the model itself, butin most cases the generated code runs independently of the DSM framework. Nevertheless, ifthe dynamic behaviour of the model is given, and the editor supports simulation, the modelcan be executed directly, without code generation. That gives developers a simpler and fasterway to test and debug their models, thus it contributes to the increase in productivity.

On the other hand, transformation support is a must, because without that, not even codegeneration would be possible. However there are multiple levels of transformation support.The lowest is support for code generation only, in that case the only possible transformationis converting the domain specific model to some kind of (typically textual) code. This conver-sion is generally based on patterns, rules and templates, specific to each DSM tool itself. Amore advanced level of transformation support is the support for model transformations. Un-like code generation, which did not affect the model itself, model transformation means thatthe structure of the model is modified when the transformation is executed. To outline thedifference we would bring an example from the area of compiler construction. When we have

75

an abstract syntax tree (AST)1, and we simply output the source code it represents, it is codegeneration. However if we take this AST and perform some kind of optimization (like loopunrolling or constant propagation) resulting in a different AST, that is model transformation.There is also a third level of transformation support, the possibility of multi domain trans-formations. Multi domain transformations are similar to simple model transformations, butthey may affect models from multiple domains. This is essential, when complex, heterogenoussystems are being modeled, and we want to perform transformations, which overlap multiplecomponents of this system.

After we have given a set of important criteria about a DSM tool, we should talk abouthow our DSM framework is going to fulfill all these requirements. In our tool, the abstractsyntax representation is handled by the Viatra2 framework. In our conception, domainspecific models (as well as metamodels which describe them) are stored inside the Viatra2model space, which allows us to benefit from the powerful transformation capabilities of theViatra2 tool. With that we have already answered the third criteria, the dynamic behaviourand transformation support. Since our model are stored inside the Viatra2 framework,a language engineer may use the transformation engine of Viatra2 to describe both thedynamic behaviour of domain specific models and the transformations, which perform codegeneration or model transformation.

Since models of all the supported domains are stored within the same Viatra2 framework,multi domain transformations become feasible. An other advantage is that unlike many otherDSM tools, where dynamic behaviour and transformations shall be implemented using somekind of scripting language or API, the Viatra2 framework allows the language engineers touse a graphical - graph transformation based - description of these transformations.

Only the question of concrete syntax has been left out. In the area of graphical represen-tation, our tool uses a GEF-based graphical editor. Our framework provides a basic set ofconcrete syntax elements (simple rectangular box and arrows), but it enables the languageengineer to defined his own graphical element, moreover, the entire graphical editor may bereplaced by some custom implementation, if needed. Our tool supports editing of multi-ple domains at the same time, and that also allows the creation of multi domain diagrams.Besides this customizable graphical editor, our framework provides a simple, perspicuous,tree-structured representation of the model. Naturally all editing actions may also be carriedout on that tree-structured (logical as opposed to graphical) model representation. To sum-marize our goals in a single line, we plan to create a DSM framework which supports multidomain modeling, simulation (dynamic behaviour), all three levels of transformation, cus-tomizable concrete syntax and all that using the Viatra2 framework as the model containerand transformation engine.

4.2 Architecture

Figure 4.1 shows the overall architecture of our DSM framework. At first sight it looks com-plex and hard to understand. In the next few sections we will elaborate the concepts of thatfigure, giving detailed descriptions of every major component of our framework. But beforegoing into details about that architecture, we will examine what other architectures could

1Tree-based representation of processed source code inside the compiler.

76

Modelspace Model

DSM ThinWrapper

DSM metamodelmapping

Notificationmapping

Diagram ManagerInterface

Diagram model

Tree EditPartsDiagram EditParts

Plugin View Classes

Domain actions

and commands

Icons Labels, tooltips

Custom plugin components

Other

DSM core metamodel Domain metamodel

Eclipse Extension Point

GEFVIATRA2

DSM Framework

Figure 4.1: Detailed architecture of the DSM framework

have been possible, and why did we choose this particular version.

4.2.1 Editor generation or runtime framework?

The first question which arises when creating a DSM framework is how actual domain spe-cific editors will function. There are two major approaches, editor generation and runtimeframework. Editor generation means that based on the metamodels, the code of the domainspecific editors are generated by the DSM tool. This approach is used for example by theEclipse Modeling Framework (EMF). Using EMF, the domain metamodel is specified usingan UML diagram or an XML schema definition. From the definition the EMF generatesboth Java classes, which implement elements of the metamodel, and a simple tree-structurededitor, which allows the editing of models.

The other approach is runtime framework, which means that there is a general (domainindependent) model editor, which takes the metamodel as one of its inputs, and uses thatmetamodel to validate model editing actions. An example of this second approach could bethe MetaEdit+ tool.

Let us get back to our well-known Petri net example to see the difference between theseapproaches. If we model Petri nets using EMF, the framework will generate Java classes suchas Place, Transition, which implement the metamodel (eg. class Place will have meth-ods like getCapacity()). A simple Eclipse-based editor is also generated, which allows theediting of models. The domain rules (eg. places have capacities, transitions do not) cannotbe violated, since the structure of the generated classes cannot be changed (generated class

77

Metamodel 2

Generated editorDomain-specific

DS model 2

DSM frameworkDomain-independent

Metamodel 1

Generated editorDomain-specific

DS model 1

Metamodel 2Metamodel 1

DS model 2DS model 1

Figure 4.2: Difference between editor generation and runtime framework

Transition will not have a getCapacity() method, whereas class Place will).

On the other hand, if we model Petri nets using MetaEdit+, we first design the meta-model and domain rules within that tool. Upon the creation and editing of models, the toolwill not generate a separate editor, but it will constantly check the provided metamodel todecide whether a certain editing action is allowed or not. For example in case of Petri nets,when we want to add capacity to a given model element, the editor will check on-the-fly in themetamodel, whether the selected element can have a property called capacity or not. Givinga different example for comparison, the difference between the two approaches is similar tothe difference between compiled (EMF) and interpreted (MetaEdit+) program execution.

Before designing our DSM framework, we studied both approaches, evaluating the advan-tages and disadvantages. Editor generation (just like compiled program execution in general)has an advantage in terms of speed. The metamodel is processed only once, when the imple-mentation classes and editor are generated. After code generation, the metamodel might bethrown away, since everything it describes (model structure and constraints) is reflected inthe generated code. That gives also one of the most important weakness of editor generation,the difficulty of tracking metamodel changes.

A domain language is not a static concept, it evolves and changes to keep up with changingbusiness processes. That means the domain language has to be updated from time to time.When we have our domain specific editors generated, every (even the smallest) change in themetamodel must be followed by the regeneration of the entire editor. That means a problem,if some custom functionality been added to the original editor after code generation. Sincea DSM framework must be general and should accept a large scale of different metamodels,generated editor tend to be simple, providing only basic editing functions. Therefore a lan-guage engineer usually adds more advanced features to the generated editor code to increaseits usability and thus its effect on productivity. However when the metamodel changes, anew editor will be generated and all the extra features have to be added again to the freshlygenerated editor code. EMF has some mechanism to detect user-made (in this case language

78

engineer) changes in the generated code, and keep the changed part intact when regeneratingcode, but that requires placing special tags in the source code. Therefore it is uncomfortableand more importantly, if not handled correctly, it might cause serious and hardly detectablefaulty behaviour in generated editors.

On the other hand, a runtime framework approach can get rid of this problem by having adomain independent general editor and making use of the domain metamodel during editing.When the metamodel changes, code need not be generated, just the editor must be told touse the updated metamodel. Just like the difference between fat and thin client software. Forfat clients (generated editors), an update must be distributed to each client (adding all extrafeatures again), providing numerous steps for errors. For thin clients (runtime framework),only the software on the server side must be updated (change the metamodel), and the clientswill automatically adapt to the modified system. The drawback of this runtime frameworkapproach is reduced speed, since the metamodel must be checked at every editing action toensure the fulfillment of domain constraints.

After looking at both approaches closely, we decided to use the runtime framework methodin our DSM tool implementation. It is true, that the constant processing of the metamodelrequires some additional time at editing, but editing is in general carried out by a humanuser, therefore the time required by checking domain constraints is negligible compared tothe time needed by the user to press keys and drag the mouse. However this time penaltyhas a greater impact on the performance while running automated transformations. But withadvanced techniques like metamodel caching and notification collecting (see section 4.3.2 onimplementation for details) that problem can also be surmounted.

On our architectural diagram (figure 4.1) this runtime framework approach is reflect bythe element DSM metamodel mapping. That component is responsible for mapping a do-main metamodel inside the Viatra2 model space to our internal metamodel representation,which is then used to verify the fulfillment of domain constraints during editing. A detailedexplanation of that component will be given in section 4.3.2.

4.2.2 Domain specific graphical representation

The main benefit of domain specific modeling is that source code can be entirely replacedby an application model. Since the key motive behind this idea is to increase productiv-ity, we want to present these models to designers in a form as human-readable as possible.The obvious choice is some kind of graphical representation. But since a DSM tool, likeour framework, should assist to the creation of new domain specific languages, we cannotpossible include the set of all required graphical elements. For certain common domains, likestate machines or Petri nets, we could provide the graphical model representations, however,a language engineer might decide to create a language for mouse trap design and requiresgraphical representations of a mouse and cheese. It is very unlikely that he would find theseelements in any of the existing DSM tools.

To support user-made graphical elements, there are two major ways, drawing and cod-ing. In case of drawing, the DSM tool provides a simple drawing module where the usercan create the required element by combining shapes, texts, colors and other graphical prim-

79

itives. The alternative way, coding, requires the user to effectively write some code, usingthe programming interface (API) of the graphical library used by the DSM tool. The majordifferences between the two alternatives are the level of user influence and the required usereffort. Drawing is clearly simpler for the users. A few mouse clicks and keystrokes requireway less work then writing code using an API previously unknown to the user. But withdrawing, we only have the set of basic elements provided by the DSM tool vendor, and thatmay greatly limit our possibilities. Writing code requires more work from the user, but hewill have a total control of what will appear in the editor. Looking back at our mouse trapexample, building the figure of a mouse from separate lines, circles and polygons (say theseare the only elements provided by the DSM tool) requires much more work than writing afew lines of code, which displays a bitmap image.

The aforementioned tool MetaEdit+ has a module called Symbol Editor which is a simpledrawing application, so the people at MetaCase2 opted for the drawing approach. Their toolprovides about a dozen of different graphical primitives (including custom bitmap), thereforea greater variety of figures can be drawn. We found that approach really helpful for the users,but finally we decided to use the coding alternative. Since we were focusing at the Viatra2tool and the base of the DSM framework, we decided that implementing a drawing applicationwas not necessary for the time being. Our tool requires users to create the implementationof their graphical figures themselves. We definitely do not rule out the possibility, that inthe future our tool will incorporate its own drawing module. Writing Java code instead ofdrawing surely decreases user-friendliness, but as our tool is still at prototype stage we donot think tha a built-in drawing module is a necessity at present.

Another interesting idea in the area of domain specific graphical elements is the conceptof element catalogs. That brings the conception of reusability into the world of graphicalelements. These catalogs enlist graphical elements already designed by some developer. Foreach element, a list of properties is also supplied. If a language engineer wants to use an itemfrom this catalog, he simply chooses it from the list. Then each property of the graphicalelement must be bound to some model property.

Let us have a look at an example. Say we have a graphical element, whose visual ap-pearance is a circle, which can display some text in the middle, and some text outside thecircle. We would like to use that element as a graphical representation for Petri net places.The Petri net language engineer has a simple job, he selects this element from the graphicalcatalog, binds the text inside the circle to the model property capacity and the text outsidethe circle to the model property name, and the work is done.

Graphical element reuse (like component reuse in general) is an important step towardsproductivity increase. Our framework follows the idea of assigning properties to graphicaland logical model elements, so the architectural background for binding graphical and modelproperties together is already present in our tool. However our framework does not yet havea simple interface to support the creation of bindings between those properties. In our cur-rent implementation link between graphical and model properties can only be established bywriting some (fairly short) code. This will definitely change in the future, we plan to supportthe creation of model-to-graphical property links through a user-friendly graphical interface.

2Company which develops MetaEdit+.

80

Our choice about graphical model representation is reflected by the component PluginView Classes on figure 4.1. These view classes are the short pieces of code a languageengineer has to write to provide a custom (domain specific) graphical representation formodel elements. Details about these view classes will be given in section 4.3.3.

4.2.3 Modeling

After we have made our choice concerning the two major architectural questions, which affectsthe usability of our framework, the next question to deal with was model (abstract syntax)representation. We needed a method both for describing the domain metamodel (domainlanguage structure) and the domain specific models, which are instances of the domain meta-model. Since the metamodel and the actual models are quite different, most tools use differentrepresentation formats. EMF for example requires the metamodel to be present as an XMLschema or a UML class diagram, whereas EMF models are plain Java objects. However if wewant to make multi domain transformations (required for multi domain simulations) possible,it is a good idea to choose a common representation for both the metamodels and the mod-els. In order to describe multi domain transformations, we need to refer to both metamodeland model elements from multiple domains. If the metamodels are represented in differentformats, such a transformation would be extremely difficult to create. Since we wanted toexploit the transformation capabilities of the Viatra2 tool, we opted for VPM3 as a commonrepresentation format both for domain metamodels and for domain specific models. We willsee in section 4.3.2 how other metamodel and model representations may be incorporatedinto our DSM framework.

Metamodel structure

Up to this point, we have been talking about two levels of modeling, the domain metamodel(language structure and constraints) and the domain specific model. Now we introduce a newlevel, the core domain metamodel, which is in certain ways more abstract than the domainmetamodel, but in a strictly mathematical sense they are both at the same metalevel.

The first question to examine is why such a core metamodel is needed. We we tellingbefore, that language engineers only have to create a domain metamodel for DSM in generalto work. Why is then a concept more abstract needed? Since our DSM framework wantsto support a wide range of different domains, we have to impose certain restrictions on thedomain metamodels. Just like a simple calculator, which imposes the restriction that allnumbers entered must be decimal. That restriction decreases the generality by some factor(an alien from Mars might be more familiar with base thirteen mathematics), but that re-striction is required, otherwise the calculator could not do any meaningful work. The conceptwhat we call core domain metamodel is simply a set of constraints posed upon the domainmetamodels. It defines the set of elements the language engineer may use to build up themetamodel of his own domain.

Figure 4.3 shows the structure of our simple core domain metamodel, and below wedescribe the elements of this metamodel.

3Internal model representation of the Viatra2 system.

81

Editor

Node

Property

topNodes

contains Edge

propertiesproperties

Figure 4.3: Core domain metamodel of our DSM framework

Editor is the topmost element in every domain. There exists only one single instance ofEditor, it serves as a model container for each domain. The relation topNodes links thetopmost nodes to this single container.

Node represent an entity in the domain metamodel. Nodes may arbitrarily be nested intoeach other by the contains relation. The only constraint about containment is that everynode must have exactly one parent (topmost nodes have Editor as their parent).

Edge is a relation that links two nodes together. At present no multiplicity constraints canbe assigned to edges, but we plan to include that in future releases. The underlying Viatra2framework already supports relation multiplicities, therefore implementing that in our DSMframework does not require architectural changes, just some additional coding.

Properties are simple (name, value) pairs, which may be assigned to any model element4.On diagram 4.3 only one Property entity and two properties relations are present for sim-plicity, but in the actual implementation both have various subtypes. The entity Propertyhas three subtypes, TextProperty is a property, whose value can be any textual data (domainplugins may implement custom property validators to restrict the value). ColorProperty is aproperty, which represents a color in RGB format. It is used mainly as a property of customdiagram elements. Finally, MultiProperty is a property, whose value may be only one of apredefined set of possible values (eg. a boolean property which may have only true or falseas its value). The relation properties has two subtypes both for nodes and edges. Any definedproperty can either be required or optional (having relation names requiredProperties and op-tionalProperties respectively). When a new model element is created, its required propertiesare created automatically, and a default value is assigned. Optional properties can be addedand removed from a model element at any time.

These four concepts are the basic elements a language engineer may use to build up acustom domain metamodel. Exactly one Editor element must be used as a top-level modelcontainer. Arbitrary hierarchies of nodes might be contained in that Editor container. Edgesmay run between any two nodes, and both nodes and edges may have any number of required

4Model element is a common name for nodes and edges.

82

Petri net Domain[Editor]

Petri net[Node]

Place[Node]

Transition[Node]

Arc weight[Property]

Place capacity[Property]

petriNets[topNodes]

places[contains]

transitions[contains]

weight[properties]

capacity[properties]

OutArc[Edge]

InArc[Edge]

Token[Node]

tokens[contains]

Figure 4.4: Example of a domain metamodel (Petri net domain)

or optional properties. Anything which is built using these abstract elements and the fewaforementioned rules is a valid domain metamodel. The core metamodel defines the abstractentities, which may appear in domain metamodels, that is why we said at the beginning ofthis section, that the core metamodel is somewhat more abstract than domain metamodels.

However in a mathematical sense, the domain metamodel is not an instance, but a sub-type of the core domain metamodel. That means the element Place of a Petri net metamodelis not the instance of the core metamodel element Node rather its subtype. It makes sense,since the concept Place is not a node itself, but it is a special kind of node. So strictly math-ematically, the core metamodel and domain metamodels are at the same meta-level, but theydescribe domain specific concepts at a different level of detail.

On figure 4.4 we can see an example domain metamodel, a simplified metamodel for Petrinets. The names inside the square brackets give the core metamodel supertypes of each ele-ment. There is one Editor on the top, and the only topmost nodes may be Petri nets. EachPetri net may contain Places and Transitions. Places may contain Tokens and may have aproperty called capacity. There are two kind of edges, OutArc, which goes from a Place to aTransitions, whereas InArc is the opposite, and edge from a Transition to a Place. Both kindof edges may have a property entitled weight.

Our assumptions about abstract syntax representantion are summarized by the bottompart of the detailed architecture diagram (figure 4.1). It shows the Viatra2 model space,which contains both the domain metamodels and the domain specific models. Also, therelation between the core domain metamodel, the domain metamodels and the domain specificmodels can be seen. The core domain metamodel defines basic concepts about abstract

83

syntax, the domain metamodels refine these concepts to create domain specific elements,finally domain specific models are simply instances of the domain metamodel.

4.2.4 Diagrams

In the last three sections we were discussing architectural and model representation ques-tions. Those three are the most important areas in terms of efficiency and transformationsupport, but in terms of usability, they are overshadowed by the questions of graphical modelrepresentation (concrete syntax). A developer sitting in front of our domain specific editorwill not care about its internal architecture, nor how models are being represented, the onlyimportant thing for him is how easily can he use that tool to design models. So the questionof diagrams, the graphical representation of models, becomes quite an important matter ifwe plan to make our tool prevalent.

Diagrams are graphical representations of certain domain specific model elements. How-ever diagrams themselves can be regarded as some kind of domain specific model, where thedomain is that of diagrams. For example, if we design a Petri net, that will be a model inthe Petri net domain, however if we draw that Petri net using circles, rectangles and arrow,that picture will be a model in the Petri net diagram domain. There is one one-way map-ping between domain specific models and domain specific diagrams. Every diagram defines amodel (or model part) by itself, however a model does not necessarily define a diagram (butin most cases diagram may be automatically generated from models). If we take the pictureof the Petri net, it obviously defines a Petri net, we just need to build up the model fromthe diagram step by step. However if we just have a (not empty) Petri net model, we haveinfinite ways of drawing a diagram, which corresponds to this model. Therefore we can saythat domain specific models and domain specific diagrams are two distinct concepts, withcertain links between the two.

Our DSM framework supports such separation of models and diagrams. In our frame-work, each domain can have its own diagrams, each domain specific diagram is describedby a domain diagram metamodel. One domain may contain multiple diagram metamodels,which is helpful, when a given model can be depicted in various formats. For example in thedomain of UML, the same complex UML model might be represented as a class diagram,a sequence diagram, or maybe some other format. With multiple diagram metamodels foreach domain, creating various kinds of diagrams from the same model is a straightforward job.

Diagram metamodel structure

In order to support various domain specific diagrams in our DSM framework, we have to firstprovide a way of describing domain specific diagrams. As we said above, a domain specificdiagram is described by a domain diagram metamodel. Such a metamodel defines the struc-ture of a diagram, describes what kind of model elements can be displayed on the particulardiagram, and how those elements should be displayed. For example a diagram metamodel fora UML class diagram would say that this kind of diagram may display classes, associationsand class fields in a structure, where fields are displayed within the classes and associationsare displayed as some kind of connection between classes. It is important to note that a

84

Diagram

DiagramElement

NodeFigureEdgeFigure RootFigureedges nodes

rootcurrentRoot

subNodes

NodeEdge

model model

Figure 4.5: Diagram metamodel of the DSM framework.

diagram metamodel does not say anything about the actual graphical representation of themodel element. In case of UML, it does not say that classes are boxes and fields are lines oftext, it just states that fields are displayed within the classes.

Now that we explained the role of the domain diagram metamodel, the similarities betweenthis concept and the domain metamodel are conspicuous. Both serve to describe some kind ofstructure, one describes the structure of model, the other describes the structure of diagrams.In case of domain metamodels, we have introduced a so-called core domain metamodel, whichdescribed the basic concept that might be used to build domain metamodels. That was neededso that metamodels of different domains may be handled commonly by our framework. Incase of diagrams, we have to do the same. In order to support various domain diagrammetamodels, we have to define some basic concepts, out of which diagram metamodels maybe constructed. That set of basic concepts is called the core diagram metamodel.

This metamodel describes our idea about how a domain specific diagram should be struc-tured. It is very similar to the core domain metamodel, basically every core diagram meta-model element is mapped to one core domain metamodel element. Figure 4.5 shows thestructure of this core diagram metamodel.

Diagram is the element which represents a single diagram in our framework. It is notbound to any model objects, it just joins the elements of the diagram into a single entity.

DiagramElement represents a graphical element on the diagram. It has three subtypes,NodeFigure, EdgeFigure and RootFigure.

EdgeFigures are the graphical representation of edges in the domain specific model. Theycontain a reference (the relation model) to the Edge model object they represent.

NodeFigures represent the nodes of the model. Just like EdgeFigures, they are also linkedto the model object they represent. Each node figure may contain other node figures. Gener-

85

Petri net diagram[Diagram]

Petri net root[RootFigure]

Place[Node]

Transition[Node]

root[root]

OutArc[Edge]

InArc[Edge]

ArcFigure[EdgeFigure]

PlaceFigure[NodeFigure]

TransitionFigure[NodeFigure]

model model

tfigures[nodes]

pfigures[nodes]

arcfigures[edges]

model model

Figure 4.6: Example of a diagram metamodel (Petri net domain).

ally (but not necessarily) the children of a NodeFigure are the figures representing the childrenof its model object.

RootFigure is the graphical representation of the diagram as a whole. All the edge figuresand all the top-level node figures are linked to the root figure. At the first glance, differenti-ating between the Diagram and the RootFigure seem superfluous. Both appear exactly onceat every diagram and both has the responsibility to represent the diagram as a whole. Thedifference is that a Diagram represent the diagram as a logical entity, whereas the RootFigureis a visual concept, the visual container of all other graphical element. The root figure islinked to its logical diagram entity via a root relation.

There is one more thing to talk about, that is diagram element properties. We mentionedduring the architectural description of graphical representation(section 4.2.2) that in thefuture we plan to support the idea that properties of diagram elements can be bound tomodel properties. Looking at figure 4.5 we see properties nowhere. The explanation liesin our conception of how these properties are handled. In our concept, properties are notlinked directly to diagram element but rather to view objects. View objects serve as theactual graphical representation of a diagram element. It is the diagram element, which storesthose properties, but actually the set of properties depend on the view behind that diagramproperties. In the next example, we will see why that is important.

On figure 4.6 we can see an example of a domain specific diagram metamodel. We can seethat there is one logical Diagram entity, and one RootFigure, which serves as a container forgraphical elements. There are two kinds of NodeFigures, one for the places and the other forthe transition. However in case of edges, both InArcs and OutArcs are represented with thesame figure. As you can see, it is possible that a given diagram element has multiple models.

86

It is useful when you have multiple domain elements whose graphical representation is thesame. In case of Petri nets, both arc types are represented as a simple arrow, the distinctionis only needed at modeling level to prevent two places or two transitions from being connected.

One might notice the absence of the model element Token from this diagram metamodel.The reason for that is in our idea, the graphical representation of a token is simply a numberwritten inside the little circle representing the place. Therefore it is the figure of the place,which should take care of displaying the number of tokens.

A few paragraphs above we promised to clarify the question of diagram properties. Nowlook at diagram metamodel of Petri nets and imagine that diagram properties are assigned tothe diagram elements themselves. What properties should we assign to the diagram elementPlaceFigure. If we use the built-in figure of our DSM framework, that would be some kindof rectangular box, it should have properties like x, y, width and height. However if we usea custom figure, a little circle for example, then instead of width and height, we should havesomething like radius. Would diagram properties be bound to diagram elements, we hadto redesign our diagram metamodel every time there is a change in the view figures. Thatis why we have decided that the set of properties will be provided by the view object, andthe diagram element will just act as a mediator to make these properties accessible for thirdparties (a GEF EditPart or the Eclipse property sheet for example).

Changeable root concept

The listing of core diagram metamodel elements above does not mention the relation curren-tRoot, which leads from a Diagram to a NodeFigure. We have just said that every diagramhas exactly one root figure, why should then exist a current one? The reason for that wassomething we call logical zooming. If we have a complex, highly hierarchical diagram, it isvery difficult to find something we need. Logical zooming enables the user to ”zoom into”any selected node, and display only the contents of that node. It is similar to the currentdirectory concept of file systems. Without logical zoom, it would be hardly impossible to findanything on a diagram containing hundreds or even much more element. Analogously, findinga file in a file system without directory structure is also a tedious job to do.

In our diagram metamodel the relation currentRoot points always to the actual node theuser has zoomed into. The reason why this relation is included in the metamodel (comparedto being stored in some local variable during editing) is that when a diagram is saved, wewould like to retain that zooming information. Therefore if the users saves a diagram andloads it back later on, the zoom settings will not be lost (as opposed to our former VPMeditor, which was designed for the first release of the Viatra2 framework).

4.2.5 Architecture overview

In the previous four sections, we analyzed the four major questions about the architecture ofa DSM tool. First, we examined the difference between editor generation and the runtimeframework approach. Both are used in the industry, and both have their advantages anddrawbacks. Editor generation results in faster domain specific editors (and simulators), but

87

reacting to the changes of the metamodel is difficult. On the other hand, a runtime frame-work can follow changes in the metamodel easily, but it queries the metamodel during editing,therefore the execution of editing actions (and transformations or simulations) is slower be-cause of the constant metamodel processing.

In the second section, we discussed the question of domain specific graphical model rep-resentation. We introduced two approaches, one being drawing, where the custom graphicalfigures can be creates using the internal drawing module of the DSM tool. The second ap-proach was coding, where the language engineer must define his custom graphical elementsby writing code using some kind of graphical API. Drawing is simpler from the languageengineers point of view, but coding gives a finer degree of influence over what will appearon the screen. Because of that greater influence, and because of the additional work that isrequired by implementing a separate drawing module, we decided that our DSM frameworkwill follow the coding approach. We did not rule out the possibility that in the future our toolwill contain a drawing module. Such a module would permit language engineers to designgraphical elements the same way as in an ordinary drawing application, and the Draw2D-based code of the drawn figures would be automatically generated. But at the time being,the Java code of custom graphical figures must be written by the language engineer himself,using the Draw2D graphical library.

In the third section we were talking about model representations. Since most DSM toolsuse their own, proprietary model representation formats, there was no need to support somekind of de facto standard. Since we have a powerful modeling and transformation framework,Viatra2, we decided to use it as the model container for domain specific models. We definedthe core domain metamodel, which gives a set of concepts for designing domain metamodels.In order to support metamodels of various domains, we had to define these basic elements,only then can different metamodels be treated in some common way. The only constraintposed upon the domain metamodels is that they should be constructed from these basicelements defined by the core domain metamodel. If that constraint is satisfied, our DSMframework will fully support that domain.

Finally in the forth section we reviewed the problem of concrete syntax representation.Concrete syntax, in other words domain specific graphical model representation, is essentialfor the usability of a DSM tool. We decided that our tool should support multiple kindsof diagrams for each domain, each kind of diagram being defined by a domain diagrammetamodel. Such a metamodel describes the structure (and not the actual visualization) ofdomain specific diagrams, giving the set of model elements that may appear on the diagram,and some basic relations between them. In order to support various diagram metamodels, weneeded again a set of basic elements, which we called in this case core diagram metamodel.That core diagram metamodel describes the basic elements of a diagram metamodel, justlike the core domain metamodel described the basic elements of a domain metamodel. If adiagram metamodel is made up using these basic concepts, our DSM framework will supportit, allowing the creation and editing of such diagrams in a user-friendly way.

88

4.3 Implementation

Now that the architectural questions of our framework has been settled, we may focus on theactual implementation of the aforementioned ideas. First, we will introduce the concept ofa domain plugin, and show how our framework and these domain plugins interact to forma multi domain editor. Following that, we will write about our default implementation of adomain plugin. Our implementation uses Viatra2 as a model and diagram container, andprovides a GEF-based graphical editor.

4.3.1 DSM framework and domain plugins

As we described in the Goals section of this chapter, we aimed at a multi domain frame-work. Unlike MetaEdit+, where the domains defined by language engineers are completelyindependent, we wanted to create a framework, where models from different domains can becombined to permit the simulation of complex systems. If we have a system which is builtfrom heterogeneous components, each component begin modeled using a different domain,only a multi domain environment would allow the simulation and verification of the entiresystem. A single domain tool like MetaEdit+ would only permit the simulation of the sepa-rate components, but that is not sufficient, since the entire modeled system becomes uselessif the interaction between the different (and otherwise flawless) components is failing. Andto simulate and verify these interactions, we need a multi domain environment.

We have already introduced the Eclipse platform in chapter 2. Our DSM framework isbuilt on top of Eclipse, it is an Eclipse plugin, which implements a multi page editor. A multipage editor is one of the default editors of Eclipse, it is basically a container for multipleeditors, its actual appearance will be shown in section 4.6. In our case, the different pages ofthat container will correspond to the editors of the different domains. In our vision a multidomain editor still separates the domains at the editing phase, multi domain functionalityonly means that multi domain diagrams may be created, and multi domain transformationsmay be executed.

In order to support multiple domains at the same time, our DSM framework must have amechanism to detect what are the domains, which are present. When the user starts our DSMframework, it should somehow find information about the available domains. Our solution forthat problem was a plugin-oriented architecture. Our DSM framework itself does not knowabout any domains, but separate domains can make the framework aware of themselves byconnecting to the framework and providing information. A domain plugin is an Eclipse plu-gin, which implements a certain domain. So when the framework starts, it does nothing, butwaits for separate domain plugins to log in. Figure 4.7 shows this plugin-oriented architecture.

A domain plugin may log in to the DSM framework by providing four different pieces ofinformation. First, it must supply the domain metamodel. Since it is the DSM framework,which actually carries out the editing actions, it must be aware of the domain metamodelin order to verify the domain constraints during editing. Second, a domain plugin must alsoprovide the root of the actual domain specific model. Each domain has a single root element,from which every other model element of the domain is accessible by navigating throughcontainment relations, edges and properties. Third, a domain plugin must also provide a list

89

DSM Framework plugin

Domain X plugin

Basic implementation

Domain Y plugin

Extended implementation

- Domain-specific graphics

- Custom tree icons

- Complex editing actions

- Derived properties

Domain Z plugin

Basic implementation

- Custom tree icons

Figure 4.7: Plugin-oriented architecture of the DSM framework

of domain diagram metamodels, and the available diagrams (diagram models), which corre-spond to these metamodels. Finally, the domain plugin must provide its own domain specificgraphical editor, since our framework only support a simple, tree-structured visualization ofmodels. If we want our domain to be supported by the DSM framework, we must create adomain plugin, which can provide these information about our domain.

Naturally, a language engineer do not have to code those four things himself, since ourDSM framework contains a default domain plugin implementation. Our default implemen-tation uses Viatra2 as a model (and metamodel) container and also as a diagram model(and metamodel) container. It also provides a GEF-based editor with some basic graphicalfigures (rectangular boxes and arrows). Generally a language engineer do not create the entiredomain plugin himself, but uses our extensible implementation. Then he only need to writecode for the extensions of that default implementation.

Besides those four things, which must be provided by a domain plugin, there are also otherpossible extensions, which are optional. As you can see on figure 4.7, the DSM frameworkcan be extended to provide our own icons in the tree view, we may add optional, derivedproperties, and so on. Our default domain plugin implementation will use built-in icons, noadditional properties, and therefore even if a language engineer does not want to code, he cancreate a functional domain plugin. But since virtually every small piece of our default imple-mentation may be changed by the language engineer (or even a language engineer may createhis own domain plugin from scratch), our framework is completely customizable. Thereforeour framework provides both a quick way to create domain languages, but it also lets thelanguage engineer tailor the editor to his own ideas.

90

4.3.2 VIATRA2 as the model container

As we mentioned before, our default domain plugin implementation uses Viatra2 as a con-tainer for metamodels and models. In order our DSM framework to function properly, boththe core metamodels (both domain and diagram) and the metamodel of the used domainsmust be present in the initial model space. The models being edited are also stored withinthe same model space. The first implementation problem we encountered was how to mapViatra2 model objects to core metamodel object, and how to navigate in a domain specificmodel.

Within the DSM framework, there are multiple places, where we need to refer to somemodel object (generally in the GEF EditParts). Whatever reference we store, it must supportnavigation within the model. For example GEF EditParts must be capable of returning thelist of their children, therefore whatever object we store in there, it must have some kind ofgetContainedNodes() method.

Our problem was that Viatra2 model objects (IEntity and IRelation) have VPM-specific query methods, which are not aware of our core metamodel. However we wantedobjects, where we can easily navigate along core metamodel relation (eg. have meth-ods like getRequiredProperties() or getContainedNodes()). Our first approach wasto use Viatra2 model objects as references and created a mapper utility, which canperform these DSM-specific navigational queries. So instead of an object, which has agetContainedNodes() method, we had a mapper utility, which had a getContainedNodes(IEntity) method, which required a Viatra2 model object as an argument.

There were three major problems with this approach. First, it was completely type-unsafe. Since we stored Viatra2 model objects as references, we could not tell, whetherthat object corresponds to a Node, a Property or the global Editor. This was not a majorproblem itself, but because of the lack of type-safety, queries within this mapper utilitywere rather slow. Since the methods of the mapper utility could be called with any kindof Viatra2 model element, it was possible for example that someone issued a query forthe contained nodes of a property. These queries are not valid, because properties may notcontain nodes in our core domain metamodel. The mapper could detect invalid queries, butthat was slow (detecting invalid queries needed multiple checks within the model and thecorresponding domain metamodel), and the correct handling of invalid queries required extracoding in the methods which called the mapper. The third problem with storing Viatra2model object references throughout the entire DSM framework was that thus we would bindour framework very closely to Viatra2 . In the paragraphs about extensibility we will seewhy that would be a problem.

Considering all these drawbacks, we rejected this approach. Another approach could havebeen building up all the domain specific models within our framework. That would mean wewould have a class DSMNode, which has fields like Collection<DSMNode> containedNodes,and so on. Using this approach solves all the problems we had. It is type-safe, every coremetamodel element has its own type. It is fast, since everything is stored within our ownmodel representation and we are completely independent of the Viatra2 model space. Theproblem with this approach is memory usage, and synchronization. If we build up the entiremodel within our framework, we will have identical information represented in two different

91

formats. Models will be there inside the Viatra2 model space, but they will be presentalso in our framework. Synchronizing these two different representations for complex modelscan be a very laborious task, most probably by the time required to synchronize the tworepresentations we lose all the processing time gained. Also copying the entire model nearlydoubles the memory usage of our framework, that would also cause serious problems for largemodels.

Thin wrapper implementation

We have concluded that using Viatra2 references has multiple problems, most importantlybecause of the lack of type-safety. Copying the entire domain specific model using custom(type-safe) classes raises memory usage and synchronization problems. We decided togo for the middle, and created an implementation, which combines the two, a type-safeimplementation which does not create a copy of the model. We call this approach thinwrapper. The idea was that we should create interfaces for each core metamodel entity,but the implementation of these interfaces does not copy the model (thus being thin),rather it stores a reference to a Viatra2 model object (thus being a wrapper), and uses amapper utility to extract information upon queries. So we have interfaces like IDSMNode orIDSMEdge, and the implementation of these interfaces stores a Viatra2 reference. When thegetContainedNodes() method is called upon an IDSMNode object, the implementation usesa mapper utility to extract the information from the Viatra2 model space.

If we have a mapper utility again, why is this any better than our first, rejected approach.Using these interfaces introduces type-safety to the implementation, and thus the mapperutility does not have to check the validity of the queries. We moved those checks fromrun-time to compile-time. This approach also allows us to deal with models outside theViatra2 model space, since these core metamodel interfaces might be implemented by athird party to support EMF models for example.

One drawback of this thin wrapper implementation is that it still uses a mapper utility.A lot of processing time is spared due to type-safety, but a thin wrapper still lags behindcomplete model copy in terms of speed. A function which queries the Viatra2 model spacecould not possibly be as fast as just checking a few local variables. We tried a few optimizationtricks, the most promising was metamodel caching. It is sure that the entire domain specificmodel cannot be copied, such a model might contain hundreds of complete Petri nets forexample. However we may copy the domain metamodel. No matter how large the modelbecomes, the metamodel remains the same (generally small) size. Why would that increasethe performance when the queries are run on model element? Simply because most modelqueries begin with a metamodel query as a first step. For example, if we want to read all thechildren nodes of a Petri net instance, first we have to read the metamodel to find out thata Petri net has two kinds of children, places and transitions. Without optimization, readingthe children of a node requires two queries into the Viatra2 model space, one about themetamodel and a second about the model itself. If we cache the metamodel within our DSMframework, we can spare one of those queries. Caching the metamodel requires a negligiblememory compared to model sizes, but the speed gain approximates twofold.

Even with metamodel caching the thin wrapper is still slower than the complete modelcopy approach, but the difference in speed is now reduced to marginal. Since complete model

92

copy is not an option at all due to its enormous memory requirements, this thin wrapperwith metamodel caching became our choice for mapping Viatra2 model objects into domainspecific ones.

Notification support

Using a thin wrapper with metamodel caching we found a rather efficient way of navigatingin the model along core metamodel relations. But the DSM framework was not just madefor looking at domain specific models, but also for editing them. As we saw on figure 2.4, ina GEF-based editor, the model must be capable of notifying its EditPart. These notificationmessages are sent to the EditPart when something about the model changes (eg. a new placeis added to the Petri net or simply one of the edge weights are changed). One would ask, if itis the EditPart, which modifies the model, why is this whole notification stuff needed. Whyshould the model tell the EditPart what has changed, if it was the EditPart that made thosechanges at the first place? The answer is one word, transformations. The fact that only theEditPart modifies the model only holds true for editing actions initiated by the user. When atransformation (or simulation) runs on the model inside the Viatra2 framework, the modelis changed by the transformation engine. If we want to follow the run of a simulation on theuser interface, there must be a mechanism to propagate the changes from the model towardsthe views. That mechanism is the notification support.

Viatra2 has built-in notification support, so for every Viatra2 model object(IModelElement) we can register listeners. The registered listeners will be notified whenthat model object is changed.

The problem is, we have just said that we cannot use Viatra2 model references insideGEF EditParts, but will use thin wrappers instead. So we must implement a notificationsupport for the thin wrappers, but that implementation should be based on the Viatra2notification mechanism. The major difficulty was that one domain specific element (eg. anode) is made up of multiple Viatra2 model elements. Thus an event at DSM-level (eg.a new child node has been created) are made up by a sequence of multiple Viatra2-levelnotifications. The creation of a new child node for example requires four basic Viatra2operations to be carried out in a defined order.

Our solution was very similar to the thin wrapper conception. We created a notificationdispatcher class, which has the sole responsibility of turning Viatra2 notifications to DSMnotifications (like the thin wrapper turned domain specific queries into Viatra2-specificones). We defined a pattern for each DSM notification. Such a pattern describes whatViatra2 notifications should occur and in what order to induce a DSM event. An examplefor such a pattern could be: if a new entity (at VPM-level) is created, then it becomesinstance of a domain metamodel element, and then a relation is created linking this entityto another model object of the same domain, this sequence means that at DSM-level a newchild node has been created. The notification dispatcher listens to every Viatra2 modelobjects in a given domain, and checks the incoming Viatra2notification sequence for thesepatterns, and when it finds one, it emits the corresponding DSM notification. The way itworks is much simpler than it sounds, it basically converts a sequence of low-level events(coming from the Viatra2 framework) into another sequence of higher-level events (sent toGEF EditParts) based on predefined patterns.

93

With that event dispatcher, the notification problem is solved, however performancequestions are raised. While we are stuck at a human user editing the model, there is noperformance issue. Processing of the model and notification events are quick compared tothe response time of the user. However when we consider transformations running in theViatra2 framework, that is another pair of shoes. Imagine a transformation which causesa lot of model changes. Simulating a Petri net would be a good example, where tokens areflowing all around the model. When this transformation is running, notifications are comingconstantly from the Viatra2 framework, and our notification dispatcher constantly convertsand transfers them to the appropriate EditParts. Now that is a problem, because constantlyupdating the EditParts and the view now requires a lot of time. What was negligible timecompared to human response times becomes a very serious performance penalty comparedto transformation execution speeds.

We worked out a simple solution we called notification collection. The idea is that duringtransformations we disable notifications in our dispatcher. That means the dispatcher willlisten to Viatra2 notifications and it will convert them to DSM notifications, but those DSMnotifications will not be sent to the EditParts. Rather, these DSM events are collected withinthe dispatcher. The collected notifications are forwarded to the EditParts at the end of thetransformation.

Well, simply doing only that does not mean any speed increase, since the amount of viewrefreshes did not get reduced. The key factor in efficient notification collection is detectingconfronting notifications. Two notifications confront, when they attempt to change the samemodel element. When two notifications confront, we can simply replace them by one (ormaybe none) notification, which covers both events. For example if a token moves from placeA to B then from B to C, the notifications new token for place B and token deleted from placeB may cancel each other.

So in order to run transformations efficiently, we must modify our dispatcher to disableoutgoing notifications, collect notifications during the run, and at the end, transform thecollected notifications to decrease their amount, and finally send the (now reduced) set ofcollected notifications to the EditParts. The reduction of collected notifications is not asimple task, and our current implementation is not yet optimized to do that efficiently, butthat reduction is necessary to permit complex transformations, like system verification.

Extensibility

In the previous paragraphs we summarized how the handling of domain specific models canbe performed when those models are stored within the Viatra2 model space. Our DSMframework is however not bound to Viatra2 . Since our framework uses the aforementioneddomain specific model interfaces (IDSMNode and others) everywhere as references, if somebodycreates a Viatra2-independent implementation of those interfaces, that would work withoutproblem.

If we look back at the overall architecture of the DSM framework (figure 4.7), we see thatdomain plugins may extends the functionality of the DSM framework in numerous ways. Oneof these possible extensions (which is not shown on the diagram) is the domain representation.The DSM framework provides one default domain representation, one where both the domain

94

metamodel and domain specific models are stored in the Viatra2 model space. However ev-ery domain plugin may provide its own implementation, enabling the use of a great varietyof model containers, like EMF or even EJBs5.

Implementing these domain specific model interfaces requires lots of work and great carenevertheless. Basically there are four major components to implement. First, metamodeland model query functions (get children nodes, and others) must be implemented. Second,model manipulation function (add new child node, etc.) must also be implemented. Third,notification support required by GEF EditParts must be added to model objects. Finally,a simple domain manager class should be implemented. That domain manager is responsi-ble for initializing the domain model, finding the model and metamodel root elements andcoordinating the work of the other three components. Therefore the possibility is given byour framework to use a custom model representation, however if we plan to include domainspecific simulation and code generation support, we advise to use our default, Viatra2-basedimplementation, where one can make use of the transformation capabilities of the underlyingViatra2 framework.

Model representation summary

For the representation of metamodels and models, our framework gives complete freedomto the language engineer. We define a set of Java interfaces (called domain specific modelinterfaces) and our framework uses only the methods of these interfaces for model displayand manipulation. Every domain plugin must contain an implementation of these interfaces.A language engineer has the freedom to implement these interfaces himself, thus completelyhiding the metamodel and model representation from the DSM framework.

However, if the language engineer does not want to implement his own model represen-tation, he may use the default implementation of our framework, which uses the Viatra2model space for storing metamodels and models. Our Viatra2 implementation tries to beboth fast and memory-saving, therefore it uses a thin wrapper conception, which combines thelow memory usage of the wrapper-less approach (using Viatra2 reference inside the DSMframework) and the fast processing speed of ”fat” wrappers (copying the entire domain spe-cific model). Our implementation also supports the notification mechanism required by GEFby converting incoming Viatra2 notifications to DSM-specific ones based on a few simplerules. Both the thin wrapper and the notification dispatcher includes certain optimizationtechniques which enable a smoother run of complex transformations and simulations.

4.3.3 Graphical representation

Our default domain plugin implementation provides also functions for graphical model repre-sentation and editing. As we have already mentioned, our implementation uses the Viatra2model space not just for storing the domain metamodel and domain specific models, but alsothe domain diagram metamodels and domain specific diagrams are stored there as well. Asa domain specific graphical editor, it provides a GEF-based extensible editor, where actualgraphical figures may be easily replaced by any custom figure.

5Entreprise JavaBeans: a object-relational persistence technology from Sun.

95

VIATRA2 as the diagram container

In case of diagrams we also faced the problem of transforming Viatra2 model objects (likeIModelElement) to core diagram metamodel objects, which describe diagrams. A Viatra2model element has VPM-specific query functions (we may navigate between elementsaccording to the VPM metamodel), but we needed query functions, which enable navigatingalong relations defined by our core diagram metamodel (an object, which represents aRootFigure should thus have query methods like getEdgeFigures() or getNodeFigures()).That is the same problem, which we have already encountered when we were trying to mapViatra2 model objects to core domain metamodel objects. As we described in the previoussection our implementation of the core metamodel interfaces used a so-called thin wrappermethod. The reason for such a thin wrapper was that copying the entire model would largelyincrease memory use and it would also raise synchronization problems.

However in case of diagrams we decided to perform a full copy, for various reasons. First,the reason which prohibited full copy in case of models was memory usage. Neverthelessdiagrams are much smaller than entire models. It is very unlikely that the entire model ap-pears on the diagram, generally only a certain few model elements are displayed. Besides,for every displayed element, the memory requirement of the view object (Draw2D figures)is greater by an order of magnitude than the memory needed by the copy of that element.So the memory usage of the model copy is negligible compared to the memory usage of theactual graphical display. Synchronization issues do not emerge neither, since there is no needto continuously synchronize our diagram representation and the Viatra2 model space. Wedo not run transformations on diagrams, therefore it is a completely acceptable solution toload all diagrams from the Viatra2 model space at the start of the editor into some kindof internal diagram representation, carry out the modifications on this duplicate and whenthe user clicks on the Save button, we write back the modifications into the Viatra2 modelspace before the actual file save operation. That is exactly what our diagram model imple-mentation does. When a Viatra2 model space is loaded into our DSM framework, we findall diagrams stored in that model space, and we create a deep copy of them using a repre-sentation, which supports diagram-level queries. So instead of referring to Viatra2 modelobjects (IRelation and IEntity), we create a copy using classes specific to our core diagrammetamodel (IDiagram, IRootFigure, INodeFigure and IEdgeFigure). Every editing actionis carried out on this type-safe internal representation, and when the model space is saved,this internal representation is again converted back to a set of VPM-level IRelations andIEntitys.

As we mentioned before, in case of the core metamodel implementation, we were forcedto use optimization tricks like metamodel caching and notification collection to provide anagreeable speed. Since a full copy is a much simpler approach than a thin wrapper, andwe do not need synchronization, we did not encounter any of those performance-specificimplementation problems.

To outline the difference between the approaches used for models and for diagrams, wegive here a simple example. Say we have to process an XML document for some reason,and we need to execute multiple queries on it. One approach could be to parse the entiredocument, build up its tree-structured representation in the memory. Once such a structureis built up, we can quickly execute queries, using this internal representation. Also, editing

96

actions are carried out on this internal tree representation, then at the end of editing, the treeis serialized back to an XML file. That would be the full copy approach, what we have usedin case of diagrams. However building up the entire XML structure requires a lot of memoryfor complex, long XML documents. Our thin wrapper implementation would do somethinglike reading in the entire XML document into a large string (that requires way less memorythan building up a tree), and to reference to one element of the XML document, it wouldonly store an integer index into this string, where the definition of that element begins. Sucha representation definitely needs less memory, but it is also much slower. Since when we wantto read the children of one element, we have to parse the same string over and over again,every time a query is issued. In case of domain specific model, we could not use the full copyapproach, since models may be very complex (which corresponds to a very complex XMLdocument in our example). Therefore we used the thin wrapper approach, which stores onlyreferences to Viatra2-level model objects (like integer indices in our example), and whena domain-specific query (something like getRequiredProperties()) is executed, we use amapper utility (that would correspond to an XML parser in our example) and the domainmetamodel to find the requested information.

GEF-based extensible editor

Our implementation includes a GEF-based editor to edit these domain specific diagrams.GEF has already been introduced in chapter 2, it is an editor framework for Eclipse, whichfacilitates the creation of graphical editors, which follow the Model-View-Controller (MVC)scheme. In chapter 2 we described certain details of GEF, and we concluded that it hasalready been successfully used in various commercial applications.

But that does not mean that GEF is perfect. It tries to be as general as possible, whichresults in certain drawbacks. Because of that generality, GEF has a rather complicated pro-gramming interface, even the implementation of the most simple functions require lots ofcoding. GEF has some problems with visualizing arrows (arrows are supported, but graph-ical clipping is not, resulting in strange diagrams for highly hierarchical models) and imagefile export is also missing. However, with all those drawbacks taken into account, we stilldecided to use GEF, because implementing a custom graphical framework from scratch (oreven just on top of Draw2D) would have required a great amount of extra work. Certain GEFdrawbacks, like image export, can be solved programmatically, the effect of certain others,like arrow display problems, can be diminished by careful design, and for the rest, we can stillhope to be fixed in future GEF releases.

In the MVC scheme of GEF, the model may be any arbitrary Java class, the only re-quirement is that model change notifications should be supported. The views are requiredto be Draw2D figures, whereas the controller, called EditPart, is supplied by GEF. TheseGEF EditParts contain the essence of GEF functionality, they transform basic user actions(keyboard and mouse events) to a higher abstraction level, called requests, which are thentransformed again to commands, which are the placeholders for model manipulation activities.

As the model for GEF, we will use use our internal diagram representation, which weexplained in the previous sections. Now, we will talk about our default view implementation.

97

We had to define a view for every graphical diagram concept. That gives use three viewsto create, one for RootFigure, one for NodeFigure and finally one for EdgeFigure. Our im-plementation for each of them is simple, providing only basic visualization features. In ourimplementation the RootFigure is a plain white infinite canvas, where top-level node figurescan be placed. Our NodeFigure is a resizable rectangular box with the name of the repre-sented model element in the header. In conclusion, our EdgeFigure is a simple arrow leadingbetween nodes. You can see screenshots of these figures in section 4.6.

Extensibility

Just like in the case of model representation, the language engineer is not bound to our GEF-and Viatra2-based implementation. Actually, in case of diagrams there are multiple waysof extending the basic functionality provided by our framework.

First, the language engineer may decide to implement the diagram metamodel fromscratch. That means, first he has to implement the management of the diagram modelhimself. By diagram model management we mean to create classes, which correspont to theconcepts on our diagram metamodel (like NodeFigure), and has the required functions (likegetCurrentRoot() for Diagram) which are defined on our diagram interfaces. Also, the lan-guage engineer must design his entire graphical editor. He may choose to use GEF, but thatis not a necessity, he may write his own Eclipse-based editor.

Requiring the language engineer to do all that just to have custom figures is not viable.So we made another way of extending our basic implementation. In this second case, thelanguage engineer keeps our Viatra2-based diagram representation, and our GEF editor,and he may only change the views. That means, he may only replace our rectangular boxes(NodeFigure) and simple edges (EdgeFigure). In most cases, changing only the views issufficient for customizing the editor, and also that is what we will demonstrate in our Petrinet example in section 4.7.

Graphical representation summary

The language engineer has three options concerning graphical model representation. First,the most simple option would be to use our built-in implementation. That means diagramsare stored inside the Viatra2 model space, the graphical editing is carried out by a GEF-based editor, and the views are simple rectangular boxes and arrows. That results in ratherugly editors, but require no additional work from the language engineer. Our implementationfor model representation differs from our implementation for diagrams in that the first usesa so-called thin wrapper architecture, which spares memory, but the processing of domainspecific queries and editing actions requires some extra time. However our implementationfor diagram representation makes a deep copy of the diagrams inside the Viatra2 modelspace, and performs editing on this duplicate. This approach means faster processing, buthas a heavy memory requirement.

The second option of a language engineer is using our default implementation but withcustom figures. In that case, the diagrams are still stored inside the Viatra2 model space,the editor is still based on GEF, but our default views are replaced by the figures created

98

by the language engineer. This second option requires the language designer to build customDraw2D figures by Java coding, but it enables the diagram to have a domain-specific look(eg. for Petri nets, use a circle as the representation of a place).

Finally the third option is have the language engineer implement the entire graphicaleditor himself. That includes management of the diagram entities, the graphical visualizationand the editing functions. That third option requires a massive amount of work on the partof the language designer, but it also enables a total customization of the graphical editor.

4.3.4 Implementation overview

The last three bigger section dealt with the actual implementation of our DSM framework.We stated that in order to support multiple domains our DSM framework follows a plugin-oriented architecture. That is like the structure of Eclipse itself, where the Platform Core justmanages the different plugins, and every functionality (like Java editing, user interface, CVSsupport) is carried our by external plugins connected to the that core. Following this schemeour DSM framework just provides some basic services, but is not operable by itself. In orderto use it, we must provide a domain plugin for every domain which we plan to use. OurDSM framework provides two sets of Java interfaces (one set for model management, calledthe model interfaces, the other is for diagram management, called intuitively the diagraminterfaces), and each domain plugin must provide an implementation of these interfaces.Besides the implementation of these interfaces, there are certain optional extension points,for example custom icons in the tree view, property validators or custom entries in thecontext menu.

So there are two set of interfaces, which the plugin must implement in order toconnect to our DSM framework. However we also provide a default implementation forthese interfaces, so that language engineers may create domain specific editors withoutexcessive Java coding. Our default implementation for the model interfaces uses theViatra2 framework to store domain metamodel and domain specific models. Since themodel interfaces define functions, which requires navigation along core domain metamodelrelations (eg. getRequiredProperties()), we faced the problem of translating those queriesto VPM-level ones. One solution could be copying the entire domain specific model fromthe Viatra2 representation to some internal representation, which supports those queriesnatively. That approach requires an enormous amount of memory for large model, thereforeit is not viable for model. Our solution was a thin wrapper architecture, where we used aseparate mapper utility to convert domain-level queries to VPM-level ones on-the-fly. Thatresults in greater processing time for queries and editing, but its memory requirements areminimal. Using such a wrapper also solve the questions about synchronization, since themodel are not duplicated, they are only stored at one place, within the Viatra2 model space.

Besides the model interfaces, we also provide an implementation of the diagram interfaces.Our implementation uses the Viatra2 model space again to store diagrams. Therefore wefaced the same problem again, translating diagram-level queries (like getSubNodeFigures())to VPM-level ones. But the diagrams in general are much smaller than models, therefore herewe do not meet the problem of exorbitant memory usage. So in case of diagrams, we choseto copy the Viatra2 representation to an internal format, where diagram-specific queriescan be executed natively (so a class representing a NodeFigure would store reference to all

99

its subnodes in a member variable). Copying the diagrams into an internal format also raisessynchronization issues (the information within the Viatra2 model space and our within ourcopy becomes different during editing), our solution to that problem was not to synchronize.Synchronization is only important for models, where executed transformations operate onthe information within the Viatra2 model space. We do not plan to run transformationson diagrams, therefore it is a viable option to load all diagrams from the Viatra2 modelspace into our internal representation at startup, use only our internal format for queriesand editing, and before the Viatra2 model space is saved, we convert the diagrams fromour internal format back to their Viatra2 representation.

The diagram interfaces also require the implementer to define his own graphical editor.Our implementation uses a GEF-based editor, which uses the aforementioned internal copyof the diagrams as a model. As for the view, we creates a basic view implementation forall three kinds of graphical elements (RootFigure, NodeFigure and EdgeFigure). Usingthese figures lets the language engineer get along without any coding, however these basicimplementations do not provide a domain specific appearance. However our implementationis extensible, and the domain designer may provide his own Draw2D figures, which shall beused for displaying diagrams. That requires some (small) amount of coding, but the visualappearance can thus be tailored to the designers needs.

As we said above, these are just our default implementations of the model and domaininterfaces, the language engineer may provide his own versions. Implementing these interfacesis a rather laborious work, but it enables the designer to use an arbitrary model or diagramrepresentation and any custom graphical editor.

4.4 Transformations, simulation and code generation

An essential concept in our DSM framework is the support for transformations, both modeltransformations and code generators. Basically every existing DSM tool provides code gen-eration functions, but only a few support model transformations. The advantage of modeltransformations is that using them, the models can be simulated with the DSM tool. Simu-lations is just one use of model transformation (however the most frequent use), but modeltransformations are more powerful than just a plain simulation engine. Using model transfor-mations, automated model manipulation becomes possible. An example could be automatedoptimization, which we have already mentioned as an example in the introduction of thischapter.

4.4.1 Requirements of transformation support

Our DSM framework does not have a built-in transformation engine, its only support fortransformations is the possibility to add a new item to the context menu, which would callan external transformation engine with certain arguments.

Such an external transformation engine can be the Viatra2 tool, and when we talk abouttransformation support in our framework, we generally mean the use of that tool. Since Via-tra2-based transformations may only be executed on models stored inside its model space, we

100

may conclude that (Viatra2-based) transformations are only supported, when the domainspecific models are stored within the Viatra2 model space. In section 4.3.2 we mentionedthat a language engineer may use any custom model representation, the Viatra2-based oneis nothing more than our implementation of the so-called model interfaces. However whenwe want to support Viatra2 transformations, then we do not a choice, Viatra2 transfor-mations can only work with models withing the Viatra2 model space, so we are required touse our Viatra2-based model implementation. Naturally that does not affect our choice ofthe diagram implementation. For diagrams we still have the choice between our GEF-basedapproach, or any custom Eclipse-based graphical editor.

4.4.2 Describing transformations

Since we use the Viatra2 tool for transformation, naturally we have to describe these trans-formations by graph transformation rules and abstract state machine programs. These tech-nologies have already been introduced in chapter 3.1. Transformations may be divided intotwo groups, the ones which does not affect the model structure, and the ones which effectuallymodify the model. The first group contains mostly code generators, but model checkers alsobelong there. Code generators are transformations, which simply walk through the entiremodel, and at each model element, they emit some kind of textual information. Most proba-bly at the end of the round trip, these snippets of texts assemble into some kind of meaningfulsource code of some kind. In chapter 3.1 we have already seen an example for such a codegenerator, a transformation which generates PNML code from a Petri net model.

Model checkers are transformations, whose task is to check the fulfillment of certain well-formedness rules. Certain wellformedness rules be expressed at metamodeling level (for ex-ample our metamodel of Petri nets contained the wellformedness rule that two places maynot be connected), but certain others cannot (or would require heavy modification of themetamodel). To check complex wellformedness rules, we can design a transformation, whichwalks throught the entire model, just like a code generator, and checks the given rules forevery model element. One example for wellformedness rules, which may not (in our actualimplementation) be expressed in metamodels are relation multiplicities. If we want to intro-duce multiplicity constraints in our domain specific editor, we must build a transformation,which check the entire model, and verifies multiplicities.

4.4.3 Running transformations

Our DSM frameworks support the possibility to assign certain transformations for every kindof model elements, and thus the execution of these transformation may be initiated from theuser interface. The question is how the feedback of these transformations can be processed.For code generators we have a simple job, the generated text must be displayed in some sep-arate view or written to an external file. Displaying the result of a model checkers is a moreinteresting question.

First, it is possible that a model checker only returns a boolean result, true, if the modelis well-formed, false, if not. That result can be displayed easily. However it is possible that a

101

Figure 4.8: Three steps of a Petri net simulation in the DSM framework (step 1)

model checker does not only return a true or false value, but it gives the list of ”bad” modelelements, the ones where the wellformedness rules are not satisfied. An expected feedbackwould be something visual, like marking these bad elements somehow on the user interface.That is unfortunately not the case in our actual implementation. At present our DSM frame-work cannot capture and analyze the results of executed transformations. That is partly alimitation of the transformation engine of Viatra2, but in the future we plan to supportdirect feedbacks from transformations to the user interface.

The most interesting question is running simulations, since those transformations actuallymodify the model. In section 4.3.2 we mentioned notification support as a necessity to providea feedback of model changes for the users. So simply running a simulation poses no prob-lems, we start the transformation, and when the execution terminates, we update the treeand graphical views, and thanks to the notification support, we will see the changes made onthe model. Figures 4.8-4.10 show the three successive steps in an example Petri net simulation.

However if we want to debug our models, we might want to influence the execution ofthe simulation. For example in the Petri net example, if we simply launch the simulation,we have no means to decide whether the top or the bottom transition will fire. To providecomplex debugging services, we should provide a mechanism which enables the user to chooseany arbitrary execution path himself whenever the simulation arrives at a decision point.We need the interaction of multiple components to provide that functionality. First, weneed a debugging interpreter inside the Viatra2 transformation engine. Such an interpreterwould allow to place breakpoint in the simulation, and whenever a transformation reachesa breakpoint, the execution is suspended, and the control is given back to the caller. Sucha debugging interpreter is already at an advanced stage of development, however it still

102

Figure 4.9: Three steps of a Petri net simulation in the DSM framework (step 2)

Figure 4.10: Three steps of a Petri net simulation in the DSM framework (step 3)

103

Figure 4.11: Guided simulation of Petri nets (conceptual figure)

requires extensive testing before its integration into the Viatra2 framework. Besides adebugging interpreter we also need a special mapping utility, which could resolve the internalstate of the interpreter (which is basically a set of VPM-based constraints), and convert theseconstraints to a domain-specific representation. These components are not yet present in theViatra2 or our DSM framework, but we definitely plan to develop them, since such a guidedsimulation would greatly facilitate the debugging process. On figure 4.11 we give an exampleof how we would imagine such a guided simulation. This image was just made to demonstrateour ideas, there is not working functionality behind this. It shows the first step of a Petri netsimulation, where the possible execution path (fireable transitions) are marked with red, andthe user could choose the desired one by simple clicking on the chosen one.

4.4.4 Transformations overview

We may conclude that supporting transformations is essential for the usability of a DSMtool. Most DSM tools only support code generation, which is a special kind of transforma-tion, which does not affect the model itself, just generates some kind of textual output basedon that model. An other kind of transformations are model checkers, whose job is to check agiven wellformedness rule on the model. Our DSM framework also supports transformations,using the Viatra2 tool as a transformation engine. However if we want to use transforma-tions in our domain, we lose the possibility of a custom model representation, we must useour built-in, Viatra2-based implementation.

In addition to code generators and model checkers, a third kind of transformations aresimulators, which effectually change the model itself. They are used to describe the dynamicbehaviour of models, thus they can be used to test the models within the DSM editor it-self. Most DSM tools, for example MetaEdit+, do not support model transformation based

104

simulation, therefore if we want to test a model, we have to generate code, and execute thegenerated code outside the DSM framework. Our DSM framework however uses the Viatra2transformation engine, which is not limited to code generation, but also supports complexmodel transformations. Therefore simulation is also possible, where we can follow the exe-cution of our model within the domain specific editor. A still missing feature in our DSMframework is the possibility of guided simulations, but development has already been madetowards that goal, and in a future release, we plan to integrate that functionality completelyinto our modeling tool.

4.5 Multi-domain editing

In the introduction of this chapter, we mentioned that our goal is to provide a multi do-main editor. Since then, we have not dealt with that question, we just mentioned few timesits importance. Multi domain support is essentially the possibility to combine models fromdifferent domain to build complex systems. Imagine a situation, where one module of oursystem is modeled using Petri nets, whereas some other module is modeled with data flownetworks, and there is an interaction between these modules. Most DSM tools do not sup-port multi domain editing, therefore they only permit to edit the two modules separately,generate code separately and run model simulations separately. However from the point ofview of the correctness of the entire system, the flawless interaction between the two mod-ules is also as important as the correctness of the modules themselves. Therefore we needa modeling tool, which allows us to simulate that interaction between the modules. But inorder to do that, we need a multi domain modeling tool, since that interaction points involveselements from multiple domain. If models of all the concerned domains are stored withinthe Viatra2 mode space, our DSM framework can support multi domain simulations. It isjust as easy as single domain simulations, the language engineer just has to write the appro-priate graph transformation and ASM rules, that will handle elements from multiple domains.

Another interesting question about multi domain editing is the support for multi domaindiagrams. That is simply a diagram, which may contain elements from multiple domains, forexample a Petri net and a UML statechart appearing on the same diagram is a simple but fineexample of a multi domain diagram. But in section 4.2.4 we have said that diagrams are de-fined by diagram metamodels, and diagram metamodel are associated to domains. Thereforewe have a problem with multi domain diagrams. Designing a metamodel for such diagram isnot difficult, we just have to take the diagrams from the different domains, and unite theminto one single metamodel. In section 4.2.4 we mentioned that every diagram metamodelhas a logical root (Diagram) and a graphical root (RootFigure). To create a multi domaindiagram metamodel out of a set of domain specific diagram metamodels, simply create anew logical and graphical root, those will be the roots of the multi domain diagram. Thanfor each domain specific diagram metamodel, take its RootFigure and add it as a top levelchildren of RootFigure of the multi domain diagram. In that section about diagrams, we didnot give a clear answer to the question why the concepts Diagram and RootFigure must beseparated. Now we have another justification for that separation, since it makes the creationof multi domain diagrams easy. By separating the logical and the graphical roots, we cansimply combine multiple diagrams by just combining their graphical roots and create a newlogical root for the result.

105

One more question about multi domain diagrams is where should they belong. We saidthat each diagram metamodel belongs to a domain, but where should a multi-domain diagrambelong. There can be two answers to this question. First, we could say that multi domaindiagrams should belong to every domain they cover. There is nothing conceptually wrongwith that, it would simply mean, that we would be able to create multi domain diagrams fromevery domain it covers. However there is major problem with this approach. We have saidbefore that diagram handling is implemented by the separate domain plugins (even if theyall use our built-in implementation). So if a diagram metamodel is associated with multipledomains, the diagrams of that kind will be duplicated in every domain plugin. So if we havea multi domain diagram, which covers three domains, each of those diagrams will be presentin all three domain plugins. That also means a waste of memory, but more importantly, syn-chronization will be needed. We have mentioned before that (at least in our implementation)diagrams are copied, and editing is carried out on that local copy, and the representationwithin the Viatra2 model space is only updated right before a file save operation. So ifa multi domain diagram is copied in multiple domain plugins, and the diagram is edited indifferent ways in the different plugins, that would result in unresolvable conflicts when theuser wishes to save his work. In our present implementation, different domains are registeredusing a hash table in the DSM framework, so the order of diagram save operations may becompletely random. This is the same situation, which may happen using CVS6. If a file storedin the CVS repository is checked out by multiple developers, each of them applies changeson their local copies, when they wish to commit their changes, the CVS server faces witha set of different files, which should somehow combined to contain all changes. Unlike ourDSM framework, a CVS system has elaborate merging algorithms, but it can still encounteran unresolvable conflict.

We have said above that there is also second option. That would be to create a separatedomain just for multi domain diagrams. Such a domain would be virtual, it would have nodomain metamodel, just a number of diagram metamodels. In this case, every diagram iscopied only once, by the domain plugin of this virtual domain, therefore there will be no wasteof memory, and also no need for synchronization. If there is only one local copy of the dia-grams, we cannot create conflicting changes. And in fact this is the idea our DSM frameworkfollows. We have a virtual domain for multi domain diagrams, which has no metamodel, onlydiagrams. This virtual domain is just an ordinary domain from the DSM frameworks pointof view, but it has an empty domain metamodel, it just has diagram metamodel. When thelanguage engineer creates a multi domain diagram metamodel, he should assign that meta-model to this virtual domain.

To summarize this short section, we concluded that multi domain editing is essential for thesimulation of complex, heterogenous systems. Since our tool uses the Viatra2 transformationengine, it can easily support multi domain transformations, if all concerned domains use theViatra2 model space to store their domain specific model. Our framework also supportsthe creation of multi domain diagrams. Diagram metamodel need to be created for thosediagrams as well, but they can easily be formed by combining existing (single domain) diagrammetamodels. These multi domain diagram metamodels are then assigned to a special, virtual

6Concurrent Versions System, a versioning system for source codes.

106

Figure 4.12: Overall appearance of our DSM framework.

domain, so that diagram instances are not duplicated in multiple domain plugins, which wouldraise severe synchronization problems.

4.6 User Interface

Up to this point we were only writing about the internal structure of our framework, andexcept for a few hints in the section about diagrams, we did not show how it is presented tothe user. User interface is however a key point in success, since developer productivity canonly be increased, if the modeling tool has a simple, clear and usable interface.

On figure 4.12 the entire DSM framework is shown as it appears inside the Eclipse plat-form. The appearance of our framework can be divided into three major components. Inthe middle we see the graphical representation of the domain specific model. On the right,in an Eclipse view entitled Outline we see a tree-structured representation of our model andour diagrams. Finally at the bottom, we see the Eclipse Properties view, where model and

107

Figure 4.13: Example of context menus (left: PetriNet, right: Place)

diagram properties may be changed.

Another important part are the little tabs at the bottom of the graphical editor. Thereare two tabs there on this picture, Petri net and State machine. These are the domain,which are created within the DSM framework. Unlike most of the existing DSM tools, ourframework supports multi domain editing, where models from different domain can be editedat the same time, multi domain diagrams can be drawn or heterogeneous systems may besimulated. With those little tabs we may instantly jump from one domain to another. User-initiated editing operations do not affect domains other than the selected one, but multidomain transformations may cause model from multiple domain to change.

4.6.1 Logical model view

We will describe the logical model editing at the first place. As written above, we can foundthe logical structure of our model in the Outline view in the form of a tree. In this sectionwe will only talk about the upper half of the tree, the part which describes the model, notthe diagrams.

Every item in the tree represents one model element. Each node is contained by its parentnode, and edges are contained by their source node. In the example on figure 4.16 we havetwo Petri nets (pn0 and pn1 ), and the latter has three places, two tokens (both in place p1 )and two transition and some arcs linking them together.

To edit our model in the tree view, we have to use the context menu. Figure 4.13 showstwo examples, the left one appears, when a Petri net is selected, the right one appears, when aplace is selected. The context menu will contain only the appropriate actions for the selectedelement. You can see on the example, that Petri nets have places and transition as possible

108

Figure 4.14: Toolbar for undo/redo, delete and clipboard operations.

Figure 4.15: Property sheet views (top: Place, bottom: OutArc)

children, whereas places may contain tokens or outarcs.

For the creation and deletion of model elements, we may use the context menu (actuallydeletion also works with the Del key), but it is also possible to move elements from theirparent into an other element. That can be done by simple drag-and-drop, the framework willcheck whether the operation is valid (eg. dragging tokens into a transition would be invalid).Clipboard operations (copy, cut and paste) are also supported, and every actions (or actionsequence), which modifies the model may be undone step by step. Each supported domainhas its own clipboard and undo stack, therefore you may comfortably work with multipledomains at the same time. At present, undoing transformations (thus also simulations) is notsupported, due to the different notification handling (during transformation runs notificationsare collected and then filtered before processing). The undo and redo operations, along withthe clipboard functions are available through the Eclipse toolbar (see figure 4.14).

An other important feature in terms of editing is the property sheet (figure 4.15). Thisview is provided by the Eclipse platform, and editors and other views may populate it withany set of properties. As you can see in our example, it displays both modeling and diagramproperties. Every Property in our domain metamodel will be displayed on this property sheet,and the value (which is in general an ordinary text value) can be edited there. Naturally,property change actions can also be undone. For edges, the source and target endpoints mayalso be edited through the property sheet (the other way of changing them is drag-and-dropin the tree view).

109

Figure 4.16: Petri net editor with custom graphical elements

4.6.2 Diagrams

A developer may access every possible editing action through the property sheet and thetree view, but diagrams offer a more spectacular way of modifying the model. An examplegraphical editor is shown on figure 4.16. On the left it contains a palette, which list thepossible graphical editing actions. Its main part is the actual graphical display of certainmodel elements.

Our framework (like many other modeling tools) separates the concepts of model and dia-gram. The model includes every element, which is present in our domain, whereas a diagramonly displays a subset of these elements. This introduces certain ambiguity, since when theuser deletes something on the graphical view, should it be only removed from the diagram, orshould it be also deleted from the model. Despite this small problem, separating the modeland the diagrams is a good idea, since it lets users show only parts of the model. A com-plex web-base application might be modeled with a statechart, which contain thousands ofstates and transition. If that entire statechart would be represented as one single diagram,it would be impossible to find any particular information on it. Separating the model fromthe diagrams enables to have a large, complex model, but create diagrams only of certainsmall submodels, in case of our web application example, the few dozen states, which areresponsible for user authentication for example.

Graphical diagrams are also displayed in the bottom half of the tree view. That wouldseem superfluous at first sight, since for every item in that tree, there exists a node or edgeon the diagram. That is true, but on the graphical view, it may be hard to find. We mayhave diagram of arbitrary size, and finding one particular item becomes very tedious oncescrolling is involved. Also, we have the changeable root concept, which allows the user to

110

zoom in to any selected node, hiding everything, which is outside that particular node. Butin the tree view, every diagram element can be found easily, no matter whether that ele-ment is actually visible or not. The property sheet can also be useful in graphical editing,because by them we may precisely position and resize our objects (see example on figure 4.15).

4.7 Example: Petri Net editor and simulator

In the previous sections we introduced the ideas, the architecture and certain implementa-tion details of our DSM framework, and we gave a description of how that whole thing isdisplayed for the users. We mentioned at each section, what options a language engineer hasin designing a domain specific language. There were certain areas, like modeling, where thelanguage engineer could get away with virtually no coding by using our Viatra2-based modelrepresentation. In other areas, like diagrams, the language engineer must do some amount ofcoding to be able to customize our editor to his ideas. Finally, for transformations (requiredfor both simulation and code generation) the language engineer must implement the dynamicbehaviour of the domain models using graph transformation and abstract state machine rules.

Just by listing that, it is difficult to decide whether all those tasks mean a lot of work, orjust a few clicks. In this section, we will examine in detail how the design of a new domainlanguage occurs using our DSM framework. Our example domain - what a surprise - will bethe domain of Petri nets. Let’s get started.

Step 1 Examine the domain in detail!Get a few Petri net experts together to work out the basic domain structure and domain

rules. During the design of a domain specific editor it is always important to have an expertof the given domain working on the project. His knowledge and expertise is a key factorin successfully adopting the DSM method within a company. Most probably you are notdesigning the editor for fun, rather you want to use it to increase the productivity of yourdevelopers. Therefore the usability and correctness of a domain specific editor and codegenerator is an essential point. If the editor is difficult to use, its model structure is incoherentor the code generated contains faults, the productivity would rather drop than increase.Only with a deep understanding of the domain can we assure that our editor gets a positiveapproval. Therefore an expert with a good understanding and deep knowledge of the domainis indispensable.

Step 2 Decide what do you want!Our DSM framework offers a wide range of possibilities from a simple editor using built-in

implementations for model representation and diagrams up to fully customizable editor withcustom model representation, custom graphical elements and so on. We must choose fromthese possibilities, which is the one, which covers all our requirements. If we plan to use theeditor only for modeling and graphical display (eg. only for documentation and not for codegeneration), the default implementation classes are sufficient for us. However if we need toaccess models outside the Viatra2 framework and our graphical representation requires 3Drendering, we need to forget the built-in classes and provide our own implementation of the

111

domain metamodel and diagram interfaces.

In case of our example Petri net editor, as we said before, we would like to support thesimulation of Petri nets, and also the generation of PNML code. Since transformations areonly available for Viatra2-based models, we will use the default implementation for modelrepresentation. However we want our editor to look familiar for users who have experiencewith other Petri net tools, so we decide to have custom graphical elements (using a little circlefor Petri net places instead of built-in rectangular boxes). We will still use the built-in GEF-based graphical editor, we will only replace the standards boxes-and-arrows visualization.

Now that we have defined exactly what functionality do we expect from the editor, wecan make the first step in the actual implementation.

Step 3 Design the domain metamodel!The first step in the implementation is the construction of the domain metamodel, that

is, the structure and rules of our domain specific language. Since in the last step we voted forthe built-in Viatra2-based model representation, we have to create that metamodel insidethe Viatra2 model space.

This task should be carried out by the domain experts, since it is them, who fully under-stand the structure of the given domain. When designing the domain metamodel, we havequite a bit of freedom, the only thing we need to take care of is to use only the conceptsdefined by our core domain metamodel. Therefore we must build up such a Petri net meta-model, where all entities are either nodes, edges or properties. Our core domain metamodelcan be seen on figure 4.3, and the Petri net domain metamodel, which we created is presentedon figure 4.17.

The domain expert has multiple ways of inputting this metamodel into the Viatra2model space. First, he may design it using our own Viatra2-specific graphical editor. Or ifthe expert is more familiar with textual languages, he may create a VTML file which containsthe metamodel. Finally, if a metamodel of the required domain exists already in some othermodeling tool, he can use the various importers supplied with the Viatra2 framework. Inthis latter case, after the import, the expert must ”tag” the elements of his metamodel usingour core metamodel concepts. That means, for every element of his metamodel, he must tellwhether that should be a node, an edge or a property.

Step 4 Design the required diagrams!Now that the structure of our domain is defined, we could already use the tree-structured

editor of our DSM framework. But we also want to support graphical editing of Petri net,therefore we must design our diagram metamodels.

Each domain has exactly one domain metamodel (what we designed in step 3), but itmay have numerous diagram metamodels. Each diagram metamodel describes one kind ofdiagram, which may be constructed using the element of the given domain. For Petri nets wewill have only one diagram, which may contain places and transitions. However for examplein case of UML, it would be logical to have multiple diagram metamodels, one for class dia-

112

Petri net Domain[Editor]

Petri net[Node]

Place[Node]

Transition[Node]

Arc weight[Property]

Place capacity[Property]

petriNets[topNodes]

places[contains]

transitions[contains]

weight[properties]

capacity[properties]

OutArc[Edge]

InArc[Edge]

Token[Node]

tokens[contains]

Figure 4.17: Step 3: Petri net domain metamodel

grams, one for collaboration diagrams, one for sequence diagrams and so on. They would alluse the same model, but they provide different visualizations.

To design our Petri net diagram, we have to look back to figure 4.5, which shows ourso-called core diagram metamodel. Just like the core domain metamodel in step 3, that de-scribes the basic concepts, which may be used to build custom diagram metamodels. So eachdiagram we define must consist of one logical and one graphical root element (Diagram andRootFigure), a custom hierarchy of nodes, and edges leading between those nodes.

Figure 4.18 shows our Petri net diagram metamodel. By comparing it to figure 4.17 onemay notice the similarities. Generally a diagram metamodel has a very similar structure tothe domain metamodel itself, simply because of the fact, that on diagrams we would like to seethe same hierarchy than in the model. Being aware of those similarities, we plan to provide asimple tool, which will translate a given domain metamodel to a diagram metamodel, whichhas the same hierarchical structure. That is not yet supported by our framework, but usingthe transformation engine of the Viatra2 framework, that automatic generation of diagrammetamodels could be implemented with a reasonable amount of work.

In general automatically generated diagram metamodels are not useful by themselves, butgive a convenient starting point. Even in such a simple example like our Petri nets certainmodification would be needed. Looking at figure 4.18 we see that InArcs and OutArcs donot have a separate diagram element, but they are both covered by ArcFigure. Naturally,an automatic generation would create two separate figures for them, but still modifying agenerated diagram metamodel would be less work, than building it up from scratch.

113

Petri net diagram[Diagram]

Petri net root[RootFigure]

Place[Node]

Transition[Node]

root[root]

OutArc[Edge]

InArc[Edge]

ArcFigure[EdgeFigure]

PlaceFigure[NodeFigure]

TransitionFigure[NodeFigure]

model model

tfigures[nodes]

pfigures[nodes]

arcfigures[edges]

model model

TokenFigure[NodeFigure]

tkfigures[subNodes]

Token[Node]

model

Figure 4.18: Step 4: Petri net diagram metamodel

Step 5 Implement custom graphical elements!Arriving at step 5, we already have our domain metamodel and diagram metamodels, de-

scribing both the structure of our domain and the various graphical representations we planto provide. Up to this point, we needed no to write any code, we just designed metamodelsinside the Viatra2 framework.

If a language engineer decides to stop here, and he does not want to do any Java coding, hehas the option to use our default implementation for the views and the graphical editor. Thatwould result in a user interface shown on figure 4.19. All nodes are represented as rectangularboxes, and neither the tools on the palette nor the entries in the tree editor have custom icons.

Our example language engineer is not as lazy as to leave the editor in that format, so hedecides to create custom graphics. First, he designs little icons, that will be used in the treeand on the palette. That is not difficult job to do, any application may be used, which cansave images in a format understood by Eclipse SWT (that can be PNG, GIF, BMP and mayothers).

The second thing to do is creating a custom graphics editor, where model elements arenot represented as boxes, rather something more domain specific. In case of Petri nets, wewant little circles for places, where the number of tokens in that place is written inside thecircle, and for transition we want small filled black rectangles. Since we do not want to createan entire graphical editor ourselves, we use the GEF-based one supplies as a default by ourDSM framework (we decided that in step 2). But using a GEF-based editor, that requires usto implement these custom figures as Draw2D classes.

Up to this point, the language engineer could have avoided any kind of Java coding, but

114

Figure 4.19: Step 5: Petri net editor without custom graphical elements

to implement his own Draw2D figures, he has to write code. Our tool does not (yet) providea built-in figure drawing module, like the Symbol Editor in MetaEdit+. Admittedly, codingrequires a greater effort from the language engineer than drawing the figures in some kind ofeditor, but it also provides a greater degree of freedom. The language engineer is not restrainedby a set of symbols provided by us (as in the case of MetaEdit+ Symbol Editor), rather hecan implement anything he images. Besides providing a large set of pre-defined symbols,Draw2D allows its figures to be completely user-drawn, so every pixel of the graphical editormay be under the control of the language designer. We do not want to go into Draw2D codingdetails here, but just to have an idea of how much coding is required, our implementation ofthe custom place and transition figures required about 20-25 lines of Java code each.

Step 6 Build the editor!We arrive at step 6, where we have our nice, little, custom icons, and our nice, not-so-little,

custom Draw2D figures ready, and we want to build our domain specific editor. We need alittle bit of Java coding to do here, but nothing complicated, only a few methods must beimplemented, which serve to inform the DSM framework to use our custom graphics insteadof the built-in one.

In the API documentation of our DSM framework we give detailed examples of how towrite these methods. Even if the language engineer is not familiar with the Eclipse en-vironment and GEF, but has a basic understanding of Java, he will find no difficulty inimplementing these methods.

After the code of those methods is written following the examples in our API documen-tation, our DSM editor is ready to use (see figure 4.20. Comparing it to figure 4.19 you can

115

Figure 4.20: Step 6: Petri net editor with custom graphical elements

see that the icons in the tree and on the palette are replaced by our custom ones, and nodesand transition have a custom figure. Starting from scratch, we have arrived to this workingdomain specific editor only by drawing a domain and a diagram metamodel, and writing somesmall (less than a hundred lines) Java code. But as we have seen in step 5, we can have aworking editor even without Java coding, if we do not wish to use custom graphical elements.

Step 7 Design dynamic behaviour of the model!The editor we built in step 6 does an excellent job in creating and editing Petri nets.

However in step 2, we decided to support simulation as well. In order to do that, the lan-guage engineer must describe the dynamic behaviour of Petri nets. Since we use the Viatra2transformation engine, these rules must be given as a set of graph transformation rules andabstract state machine programs.

The syntax and semantics of these rules have been detailed in chapter 3.2. There wehave already presented an example transformation rule which covers the firing of Petri nettransitions The language engineer must design those rules, and implement them inside theViatra2 model space. At present, transformation rules may only be written using the textualVTCL format, however a graphical transformation designer interface is under construction atour Department.

After the transformation rules have been designed and implemented within the Viatra2framework, the DSM framework must be told to use them. Just like for custom graphics,that means a few lines of Java code extending the existing editor. That Java code merelyserves to assign ASM rules to certain model elements. In our case, there will be one mainASM rule, the simulation of the Petri net, which fires transitions as long as it is possible.

116

That main ASM rule will be assigned to the model element PetriNet, since that is the onlyelement, where simulation is meaningful. Certainly the language engineer could decide toimplement an ASM rule, which coves the firing of one single transition, and assign that ruleto the model element Transition. That would allow firing transitions one at a time.

The Java code the language engineer has to write at this step simply assigns transforma-tions to model elements. Clearly, that could be done with some user-friendly interface, wherethe designer would only have to drag little icons on top of each other. Providing such a userinterface is included in our roadmap, but at present, the language engineer must content withthe necessity of writing Java code.

Step 8 Design transformations for code generation!As we said in 4.4, in our DSM framework code generation is also based on Viatra2

transformations. So in order to generate code, the language engineer must do pretty muchthe same as in step 7. Viatra2 transformations written there served to simulate the model,whereas transformations designed in this step serve to generate code.

Code generator transformations were also mentioned in chapter 3.2, our language engineermust follow the guideline written there in order to create his own code generator. In case ofPetri nets, one kind of code generation could be PNML7. Such a code generator transforma-tion would iterate over the entire Petri net structure, and at each node (place or transition)it would emit snippets of PNML code.

Code generator transformation may be taken into the DSM framework the same way assimulator transformations. Some short Java code must be written (we also plan to eliminatethe need for that some time in the future), and the code generation will become availablethrough the context menu of the editor.

Step 9 Use your new domain specific editor!Our domain specific editor is now ready. We can easily create and edit Petri nets, using

domain specific graphical elements. By default our Petri nets are saved along with the entiremodel space in VPML, the native format of Viatra2 models. However if we had written thecode generator transformations in step 8, we can simply generate standard PNML descriptionwith a single click. If we want to simulate our Petri net, we have to write the transformationfor its dynamic behaviour (step 7), and if that is done, we can run simulations also from themenu. We have a complex domain specific editor in our hands.

4.8 Future goals

In this last section, we will just give a list of some of the possible extensions, which are notyet implemented, but if they were, they would greatly increase its usability.

The most important thing to mention here would be the support for guided simulations.We have seen in section 4.4, that the availability of guided simulations would permit the

7Petri Net Markup Language: XML-based description of Petri nets

117

debugging of models within the DSM framework, by following the execution directly on thegraphical model representation. In order to support that, we first have to complete the debug-aware interpreter within the Viatra2 transformation engine, then we should create a reversemapping, which could convert VPM-level patterns back to domain-level model objects. Thedebugging interpreter is already at advanced stage of implementation, and we also have a fewidea about how such a reverse mapper should work, but we still have quite a bit of work todo before we could make it into a well functioning component of our framework.

Another important advancement would be the total elimination of Java coding. Thatis already possible, but editors without coding will use our built-in view objects, which areacceptable for prototyping editors, but far from perfect for an actual working domain specificeditor. At present custom graphical elements may only be included if the language engineerbuilds them using the Draw2D graphical library of the GEF framework. We plan to offer twodistinct solutions for this problem. First, we plan to have a separate drawing application,where custom graphical figure could be built using basic elements like lines, rectangles, label,etc., and this drawing application would then generate the code for the corresponding Draw2Dfigure. Our second idea is not exactly a solution for this problem, but an idea which focuseson the reusability of graphical elements. Our idea is the create a catalog, where graphicalelements are listed, and each element has some kind of documentation a set of properties.Using this catalog the specification of graphical appearance would be assigning one elementfrom this catalog to every kind of model element, and providing a mapping, which connectsthe properties of the graphical element with the properties (including derived properties) ofthe model element. For example we have a Petri net place, which has properties name andcapacity and may contain any number of tokens. Also, we have a graphical element, whichis a circle with a changeable radius (property radius) and has two labels, one is positionedjust above the circle (property title) the other label is positioned at the center of the circle(property content). To bind this graphical element to the model element kind Place wewould first create a derived property tokens, which would mean the number of containedtoken elements. Then we would link properties name and title, also tokens and content andfinally we would bound the constant 25 to radius and that would result in an appearancelike on figure 4.20. To support these catalogs, we have already implemented the conceptof properties for both diagram elements and model elements, we also support that domainplugins may supply custom (possibly derived) properties, so the only thing left to do is auser-friendly interface, which would allow the creation of these bindings.

Besides these two, there are certainly many other areas, where our framework could beimproved. Our vision is to provide a framework, which given both a comfortable and fast wayof editing models and a powerful transformation support, which - through guided simulations- enables the graphical debugging of domain specific models. There is still a lot of work todo, before we may declare it finished, but the actual implementation is already a workingprototype, and it is a good basis for further improvements. Besides improvement within theframework itself we also plan to improve its interoperability with other modeling tools, es-pecially in the area of model and metamodel import from other tools. We also have someimplementation improvements to do, notably in our technique of notification collection, sinceimproving that would result in a faster execution for transformations, which is a key factor inuser productivity. Our other future plans include export of diagrams in some kind of imagefile format (most probably the SVG and PNG formats would be supported), printing sup-port, greater extendibility and support for custom wellformedness constraints with graphicalfeedback.

118

Chapter 5

Conclusions

We may conclude that at present day domain specific modeling (DSM) gathers ground in thearea of software development. Unlike UML, which tries to be a single modeling language asgeneral as possible, DSM follows the idea of creating separate modeling languages for everyspecialized application domain. As we explained before, that results in a more comprehensive(generally hundred per cent) code generation, consequently a leap in developer productivity.For UML modeling there are a number of industrial tools available, but since DSM is notbased on one single modeling language, therefore DSM does not only require a modeling tool,but it requires a framework for building such tools.

In the current report, we first examined the existing DSM frameworks available in theindustry, and elaborated our own framework. We may conclude the following.

• Most of existing DSM tools separate the models of the distinct domains, therefore mod-eling the interaction between heterogenous components - modeled in different domains- of a complex system becomes very difficult.

• In addition, most DSM tools provide only basic transformation support. Code genera-tion is ubiquitous, but the simulation of a domain specific model within the framework(without code generation) is rarely supported.

In our own DSM framework, we were focusing on these two weaknesses. We created aframework, which support multi domain modeling and has advanced transformation capabili-ties, which support code generation, simulation using a formal language. Our implementationis composed of two loosely connected components.

5.1 The transformation framework

Viatra2 is the foundation of our DSM framework, it is a (domain independent) modelingtool with a highly evolved transformation engine.

• It uses Visual and Precise Metamodeling (VPM) as its core modeling language, whicheliminates the ambiguities and limitations of MOF-based languages[42].

119

• To describe transformations, Viatra2 uses graph transformation and abstract statemachine rules. These two abstractions enable the language engineer to describe trans-formations in a graphical, pattern-oriented way.

Our implementation of the Viatra2 tool, which consists of more than 150,000 lines ofJava code, incorporates an model container for VPM models, a pattern matching algorithmbased on local search trees and an ASM interpreter. All three components can be accessedthrough documented APIs, therefore building custom modules, which utilize its modeling andtransformation capabilities, is largely supported. These custom modules include importer andexporters, which provide integration with other UML modeling tools such as IBM RationalSoftware Architect or Rational XDE as well as business modeling tools such as IBM BusinessIntegration Modeler.

Based on our implementation, the Viatra2 framework has recently became an officialsubproject of the Eclipse Generative Model Transformers project [46] since September, 2005.This open source contribution is dominantly based on the results of the current report.

5.2 DSM framework

Our other achievement is the DSM framework itself, which is build on top of Viatra2 .

• For model representations, it uses VPM to represent domain metamodels and domainspecific models, but it can be extended to also work with different representations, suchas EMF, even to work with multiple representation format at the same time.

• Our tool provides a tree-structured and a graphical model editor, where the latter isimplemented using the Eclipse GEF framework. A language engineer may create hisown visual elements for this graphical representation, however at present that must becomplemented with writing some Java code as well.

• Since our tool is based on Viatra2, it also supports transformations of any kind, thatincluding code generation and simulation as well.

• For simulation, the dynamic behaviour of the model must be given using graph trans-formation and ASM, and our framework can run these simulations on selected modelparts.

By comparing our DSM framework to the existent ones, we may conclude that in mostareas of functionality we have attained the ”industry average”, and in certain others, like thesupport of multi domain support and model transformations, we have even surpassed it.

5.3 Future work

Further future work is required for more extensive support for graphical element design andinteractive simulations.

Concerning graphical element design, our tool currently requires the language engineerto implement his custom graphical elements by some Java coding, whereas some industrialDSM tools (e.g. MetaEdit) provide easy-to-use, built-in drawing modules. A first idea toovercome this problem is to use our own DSM framework to implement a graphical editor to

120

design custom graphical elements and to use Viatra2 code generation features to derive thecorresponding GEF source code.

For interactive simulations, which is not supported even in industrial tools (only an APIis provided), the critical underlying infrastructure is already provided in the current report.However, first a general graphical user interface is still required, furthermore, we also plan todesign an interactive graphical debugger for transformations, which could be directly used inDSM model simulators as well. This way the user may select any arbitrary execution pathduring the run of a simulation.

On the conceptual side, the precise formal semantics of the transformation language en-ables the verification of model transformations, which is a necessary step to guarantee thecorrectness of generated code. This is also a great future challenge.

121

Bibliography

[1] AGG Project websitehttp://tfs.cs.tu-berlin.de/agg/

[2] b+w GmbH websitehttp://www.architectureware.de

[3] Andras Balogh, Daniel Varro: Advanced Model Transformation Language Constructs inthe VIATRA2 Framework, September 2005, Accepted to SAC 2006, Model TransformationTrack

[4] E. Borger and R. Sark: Abstract State Machines. A method for High-Level System Designand Analysis, Springer-Verlag, 2003.

[5] Compuware: Landmark Study Reveals 35 per cent Productivity Gains for BusinessesUsing Model-Driven Architecture, 21 July, 2003http://www.compuware.co.uk/pressroom/news/21072003_02.htm

[6] Eclipse Project websitehttp://www.eclipse.org

[7] Eclipse Modeling Framework websitehttp://www.eclipse.org/emf

[8] Eclipse Corner Articles: Introduction to Java Emitter Templates (JET)http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html

[9] H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg (eds.): Handbook on GraphGrammars and Computing by Graph Transformation, vol. 2: Applications, Languages andTools, in: World Scientific, 1999.

[10] Karsten Ehrig, Esther Guerra, Juan de Lara, Laszlo Lengyel, Tihamer Levendovszky,Ulrike Prange, Gabriele Taentzer, Daniel Varro, and Szilvia Varro-Gyapay: Model Trans-formation by Graph Transformation: A Comparative Study, Model Transformations inPractice Workshop, 2005. In press.

[11] Karsten Ehrig, Claudia Ermel, Stefan Hansgen, Gabriele Taentzer: Towards GraphTransformation Based Generation of Visual Editors using Eclipsehttp://tfs.cs.tu-berlin.de/~karstene/public/gEEHT04.pdf

[12] C. Ermel and M. Rudolf and G. Taentzer: In [9], chapter The AGG-Approach: Languageand Tool Environment, World Scientific, 1999, pages 551–603.

122

[13] David S. Frankel - Steve Cook: Domain-Specific Modeling and Model Driven Architec-ture, in: MDA Journal, January 2004http://www.bptrends.com/publicationfiles/01-04COLDomSpecModelingFrankel-Cook.pdf

[14] General Modeling Framework websitehttp://www.eclipse.org/gmf

[15] GMF Project Requirementshttp://www.eclipse.org/gmf/requirements.html

[16] Jack Greenfield: The Case for Software Factories, in: ITArchitect Magazine, August 24,2004http://www.itarchitect.co.uk/articles/display.asp?id=96

[17] Jack Greenfield: Software Factories: Assembling Applications with Patterns, Models,Frameworks, and Tools, in: Microsoft Developer Network Technical Articles, November2004http://msdn.microsoft.com/library/en-us/dnbda/html/softfact3.asp

[18] Martijn Iseger: Domain-specific modeling for generative software development, April 17,2005http://www.itarchitect.co.uk/articles/display.asp?id=161

[19] Steven Kelly: Comparison of Eclipse EMF/GEF and MetaEdit+ for DSM, in: OOPSLA:19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, andApplications, 2004http://www.softmetaware.com/oopsla2004/kelly.pdf

[20] Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Videira Lopes, C., Loingtier, J.-M., and Irwin, J: Aspect-oriented Programming, in: Proceedings of ECOOP, 1997http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf

[21] Thomas Klein and Ulrich Nickel and Jorg Niere and Albert Zundorf: From UML to JavaAnd Back Again, University of Paderborn, 2000, tr-ri-00-216

[22] Kobryn, C.: UML 2001: A standardization Odyssey. Communications of the ACM,42(10), 1999

[23] Bernd Kolb, Markus Volter: openArchitectureWare and Eclipse, 2004http://architecturware.sourceforge.net/data/oawEclipse.pdf

[24] J. Larrosa and G. Valiente: Constraint Satisfaction Algorithms for Graph Pattern Match-ing, in: Mathematical Structures in Computer Science, Vol. 12, No. 4, 2002, pages 403–422.

[25] MetaCase websitehttp://www.metacase.com

[26] MetaEdit+: Technical Summaryhttp://www.metacase.com/papers/MetaEditPlus.pdf

[27] Meta Object Facility Specificationhttp://www.omg.org/docs/formal/02-04-03.pdf

123

[28] Microsoft DSL Tools websitehttp://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx

[29] Microsoft DSL Tools Walkthroughshttp://go.microsoft.com/fwlink/?LinkId=43636

[30] William Moore, David Dean, Anna Gerber, Gunnar Wagenknecht, Philippe Vanderhey-den: Eclipse Development using the Graphical Editing Framework and the Eclipse Model-ing Framework, in: IBM RedBooks, 17 February 2004http://www.redbooks.ibm.com/abstracts/sg246302.html

[31] U. Nickel, J. Niere, and A. Zundorf: Tool demonstration: The FUJABA environment,in: The 22nd Int. Conf. on Software Engineering (ICSE), ACM Press, Limerick, Ireland,2000.

[32] openArchitectureWare websitehttp://www.openarchitectureware.org

[33] The Petri Net Markup Language Specificationhttp://www.informatik.hu-berlin.de/top/pnml/pnml.html

[34] Risto Pohjonen: Boosting Embedded Systems Development with Domain-Specific Mod-eling, 2004http://www.metacase.com/papers/RTC04_Pohjonen.pdf

[35] A. Rensink: Representing first-order logic using graphs, in: H. Ehrig, G. Engels, F.Parisi-Presicce, and G. Rozenberg (eds.), Proc. 2nd Int. Conf. on Graph Transformation(ICGT 2004), Rome, Italy, vol. 3256 of LNCS, pp. 319335. Springer, 2004.

[36] Rich Seeley: ADT at Gartner ITxpo: Gates sees more modeling, less coding, 30 March,2004http://www.adtmag.com/article.asp?id=9166

[37] Charles Simonyi: The Death of Computer Languages, The Birth of Intentional Program-ming, 1995http://research.microsoft.com/research/pubs/view.aspx?type=TechnicalReport&id=4

[38] Dave D. Straube and M. Tamer Ozsu: Query Optimization and Execution Plan Gener-ation in Object-Oriented Data Management Systems, Knowledge and Data Engineering,1995, Vol. 7, No. 2, pages 210–227.

[39] Tiger Project websitehttp://tfs.cs.tu-berlin.de/tigerprj/

[40] Tiger User Documentationhttp://tfs.cs.tu-berlin.de/tigerprj/papers/userdoc.pdf

[41] Daniel Varro: Automated Model Transformations for the Analysis of IT Systems, PhDThesis, 2004http://www.inf.mit.bme.hu/FTSRG/Publications/varro/2004/phd_thesis.zip

124

[42] Daniel Varro, Andras Pataricza: VPM: A visual, precise and multilevel metamodelingframework for describing mathematical domains and UML (The Mathematics of Meta-modeling is Metamodeling Mathematics), in: Journal of Software and Systems Modeling,October, 2003

[43] Daniel Varro and Gergely Varro and Andras Pataricza: Designing the Automatic Trans-formation of Visual Languages, Vol. 44, No. 2, Elsevier, pages 205–227, in: Science ofComputer Programming, August 2002

[44] Gergely Varro, Katalin Friedl, Daniel Varro: Graph Transformation in RelationalDatabases, In Proc. GraBaTs 2004: International Workshop on Graph Based Tools. Inpress.

[45] Apache Velocity Projecthttp://jakarta.apache.org/velocity

[46] VIATRA2 Framework. An Eclipse GMT Subproject (http://www.eclipse.org/gmt/).

[47] Attila Vizhanyo and Aditya Agrawal and Feng Shi: Towards Generation of EfficientTransformations, Proc. of 3rd Int. Conf. on Generative Programming and Component En-gineering (GPCE 2004), pages 298–316, October 2004, editors: Gabor Karsai and EelcoVisser, Vol. 3286, Ser. LNCS, Vancouver, Canada, Springer-Verlag

[48] VMTS Websitehttp://avalon.aut.bme.hu/~tihamer/research/vmts

[49] A. Zundorf: Graph pattern-matching in PROGRES, Proc. 5th Int. Workshop on GraphGrammars and their Application to Computer Science, pages 454–468, 1996, Vol. 1073,Ser. LNCS, Springer-Verlag

125

Appendix A

ASM Example: Traffic Lights

This section introduces an example GTASM program. This program has no graph transfor-mation rule and pattern so it is pure ASM. The example simulates two traffic lights at onecrossing. The example program is written in VTCL language.

machine traffic_lights

{

// An ASM function (a mapping) which maps light number(identifier) to

// the given light’s state

// This mapping will change as the system changes its state.

asmfunction light2state/1 {(1)="red";(2)="red";}

// An ASM function (a mapping) which maps light number(identifier) to

// the other light’s identifier

// This mapping will not change in this example

asmfunction otherLight/1 {(1)=2;(2)=1;}

rule main (in Limit) = seq

{

// print the starting state

call printState();

// set a counter. The system will stop simulating when

// counter reaches limit.

let I=0 in seq

{

// Iterate until one rule fails.

// When one rule fails iterate exits, but iterate rule

// does not fail.

iterate seq

{

// change the state of either the light 1 or light 2

// This rule will define an order eg 2,1

// and tries to run that rule.

// assume that state of light 1 is green, and state of

// light 2 is green.

// changing state of light 2 will fail so interpretion

// of random rule

// will go on with changing state of light 1

random {

call changeState(1);

call changeState(2);

}

// Print the new state of system

call printState();

126

print("number of chages:"+I+"\n");

update I=I+1;

// This rule will fail, if we have rached the preset limit.

// Failing this rule causes the iterate seq rule to exit

call isReady(I, Limit);

}

}

}

// this rule will try to change state of given light

// chooses one of applicable changes random

// will fail if the given light can not change state

// (eg other light is green)

rule changeState(in X) = random

{

call yellow_blink2red(X);

call red2yellow_red(X);

call yellow_red2green(X);

call green2yellow(X);

call yellow2red(X);

}

...

}

This is the core of the traffic lights example. The example uses an ASM function to storethe state of the traffic lights. The two lights are coded as 1 and 2. The states are coded as”red”, ”yellow”, ”blink-yellow” and so on. The light2state ASM function maps the identifierof the light to the state of the light.

The main iteration loop is stopped by a counter that reaches the preset count value. Thisway the simulator will simulate the given number of state changes.

The rules to change the state of the system are called inside a random block. The randomblock work in a way that it calls all sub rules in a random order, and and does not go on untilone rule succeeds. Rule that fail do not change the state of the system. So the program itselfis declarative in the sense that the interpreter will choose the applicable rule, that takes thesystem to a new state.

The rules which take the system to a new state are the following:

machine traffic_lights

{

...

// this rule defines the limit of iteration

rule isReady(in I, in Limit) = if(I>Limit) fail;

// this rule prints the current state of lights

rule printState ()= seq

{

print("current state:\n");

print("light 1:"+light2state(1)+"\n");

print("light 2:"+light2state(2)+"\n");

}

// one rule to change state of given light

rule yellow_blink2red(in X)=seq

{

if(light2state(X)=="blink_yellow") seq

{

update light2state(X)="red";

};

127

else fail;

}

// one rule to change state of given light

rule red2yellow_blink(in X)=seq

{

if(light2state(X)=="red") seq

{

if(light2state(otherLight(X))=="blink_yellow"

||light2state(otherLight(X))=="red") seq

{

update light2state(X)="blink_yellow";

};

else fail;

};

else fail;

}

// one rule to change state of given light

rule red2yellow_red(in X)=seq

{

if(light2state(X)=="red"&&light2state(otherLight(X))=="red")

seq

{

update light2state(X)="yellow_red";

};

else fail;

}

// one rule to change state of given light

rule yellow_red2green(in X)=seq

{

if(light2state(X)=="yellow_red") seq

{

update light2state(X)="green";

};

else fail;

}

// one rule to change state of given light

rule green2yellow(in X)=seq

{

if(light2state(X)=="green") seq

{

update light2state(X)="yellow";

};

else fail;

}

// one rule to change state of given light

rule yellow2red(in X)=seq

{

if(light2state(X)=="yellow") seq

{

update light2state(X)="red";

};

else fail;

}

}

128