Simulation and transformation of domain-specific languages. Master s Thesis

Átírás

1 Budapest University of Technology and Economics Department of Measurement and Information Systems Simulation and transformation of domain-specific languages Master s Thesis Dávid Vágó Supervisor: Dr. Dániel Varró, assistant professor Budapest, 2006

2 I would like to thank Dr. Dániel Varró for his continued support and helpful advices. I would also like to thank András Schmidt and István Ráth, since my work could not have been completed without their contributions to their own researches. Finally I would also like to thank all colleagues, who participated in the various Viatra-related project for their valuable feedback.

3 Simulation and transformation of domain-specific languages Dávid Vágó Contents 1 Domain-specific Modeling Models in software engineering The evolution of approaches Domain-specific modeling Objectives Language engineering State-of-the-art of DSM tools MetaCase Microsoft DSL Tools VMTS Eclipse-based tools The Eclipse Integrated Development Environment Eclipse Modeling Framework Graphical Editing Framework Eclipse GMF Tool summary Example: Petri Net Viatra2: VIsual Automated TRAnsformations Metamodeling: Definition of abstract syntax Visual and Precise Metamodeling The VTCL language Graph patterns Graph transformation rules Control structures Architectural overview The VIATRA2 framework Summary ViatraDSM: Domain-specific modeling for Viatra Goals

4 CONTENTS Architecture Editor generation or runtime framework? Domain specific graphical representation Modeling Diagrams Implementation DSM framework and domain plugins Viatra2 as the model container Graphical representation Implementation summary Example: Petri Net editor ViatraDSM simulation module Goals Approaches Declarative vs. Java-based simulation Debuggable interpreter vs. separate steps Overview Implementation Simple implementations Declarative parameter mapping Simulation step enablement Simulation use-cases Summary Future enhancements Simulation examples Simple example: Petri nets Viatra2 GTASM machines Declarative mapping User interface Complex example: capacities and weights Advanced graph patterns and transformation rules Advanced ASM constructs Conclusions ViatraDSM simulation module Future work

5 Simulation and transformation of domain-specific languages Dávid Vágó Nyilatkozat Alulírott Vágó Dávid, a Budapesti Műszaki és Gazdaságtudományi Egyetem műszaki informatika szakos hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem.... Vágó Dávid 4

6 Simulation and transformation of domain-specific languages Dávid Vágó Összefoglalás A domain-specifikus modellezés (DSM) napjaink egyik legdinamikusabban fejlődő fejlesztési módszertana. Ezen módszert követve a felmerülő üzleti problémákat, illetve azok megoldásait magának az üzleti környezetnek a nyelvezetén lehet megfogalmazni, és a tényleges feladatot elvégző informatikai rendszert ebből a magasszintű leírásból lehet szinte teljesen automatikusan származtatni. Egyes kutatások szerint ez akár többszörös termelékenységet is eredményezhet a manapság elterjedt MDA/UML alapú módszertanokhoz képest. Jelenleg több eszköz is létezik domain-specifikus modellek készítésére, ezek közül a legismertebbeket a diplomamunkámban is bemutatom. A meglévő eszközök közös jellemzője, hogy az adott célterült metamodelljének elkészítése után nyújtanak egy grafikus felületet a modellek szerkesztésére. A meglévő eszközök nagy részének hátránya a szimuláció támogatásának a hiánya, a legtöbb eszközben a modellek dinamikus viselkedésének vizsgálata kimerül abban, hogy kapunk egy programozói interfészt (API-t), amin keresztül a modelleket lekérdezhetjük és módosíthatjuk. A dolgozatomban elsőként bemutatom a Viatra2 keretrendszert, a Méréstechnika és Információs Rendszerek Tanszéken fejlesztett modelltranszformációs eszközt. Ezen rendszer szolgáltatásaira épülve készítettük el önálló labor keretében Ráth Istvánnal közösen a ViatraDSM keretrendszert, ami lehetővé teszi domain-specifikus modellek szerkesztését a Viatra2 modellterének használatával. Az elmúlt félévben pedig ezen ViatraDSM keretrendszerhez készítettem egy szimulációs környezetet. Megvizsgáltam, hogy a jelenlegi DSM eszközök milyen szimulációs módszereket támogatnak, illetve kísérleteztem a Viatra2 keretrendszer transzformációs eszközeivel. Ezeket felhasználva elterveztem egy, gráftranszformáción és absztrakt állapotgépeken alapuló szimulációs környezetet. Ennek segítségével a ViatraDSM eszközzel létrehozott domain-specifikus modellek dinamikus viselkedését deklaratív eszközökkel lehet leírni, és közvetlenül a keretrendszerből lehet az elkészített szimulációkat futtatni. 5

7 Simulation and transformation of domain-specific languages Dávid Vágó Abstract Domain specific modeling (DSM) is one of the most active research areas in software development. Following its ideas, business problems and their solutions should be expressed using the language of the target application domain. The actual software system, which solves the problem would be automatically generated from this high level description by the means of DSM tools. According to various studies, DSM could bring a large increase in productivity compared to currently widespread MDA/UML-based development processes. At present, there are multiple tools for domain-specific modeling, and in the following report, I will introduce some of the most important ones. A common feature of existing tools is that after the design of the domain metamodel, they provide a graphical environment for model editing. However most tools lack simulation support, i.e. the dynamic behavior of models cannot be expressed easily. Generally, the tools only give a programming interface (API), which enables querying and manipulating the models. In my thesis, I first introduce the Viatra2 framework, a model transformation system developed at the Department of Measurement and Information Systems. Based on the facilities of this tool, István Ráth and myself have developed the ViatraDSM framework, which supports the editing of domain-specific models using the model space of the Viatra2 framework. In the last semester, I have built a simulation module for our ViatraDSM framework. I have examined the simulation support in existing DSM tools, and I also experimented with the transformation capabilities of the underlying Viatra2 framework. Using these results, I designed a simulation environment based on graph transformation and abstract state machines (the transformation technology used by Viatra2). My module enables the declarative description of dynamic behavior for models inside the ViatraDSM framework, and the designed simulations can be interactively run from our tool. 6

8 Simulation and transformation of domain-specific languages Dávid Vágó Chapter 1 Domain-specific Modeling Models are projections of reality. In engineering, they are used to capture concepts related to the engineer s task: the product that is being designed, its environment, and processes that may be involved in its life cycle. Models are attractive because they allow a problem to be precisely grasped at the right level of abstraction without unnecessarily delving into detail. 1.1 Models in software engineering In software development, models are used to represent data structures, communication between agents, algorithms, or at a higher abstraction level, entities in a complex system, e.g. organizational units or products in an e-commerce application. The software development industry has been using high level models at the core of development for more than a decade now, because it is widely believed that software systems of large complexity can only be designed and maintained if the level of abstraction is set considerably higher than that of conventional programming languages. On the other hand, computers can only operate at the lowest possible level of abstraction (machine code consisting of elementary operations and data primitives), thus our models need to be translated into the language that the target platform can understand and run. By platform we mean the low level software and hardware architecture that executes application code (which includes software libraries, operating systems, a computer architecture, or even a virtual machine with a runtime framework, such as Sun s Java or Microsoft s.net). For low level models, this translation is usually called compilation (in this context, a programming language construct, i.e. source code is also considered a model); while for high level models, the term model transformation is frequently used. This is traditionally called model-to-model transformation. In contrast, a special case of model transformation is referred to as code generation, where source code is generated from a (graphical) model, using a code generator (model-to-code transforma- 7

9 1.1. MODELS IN SOFTWARE ENGINEERING 8 tion). The model based software development paradigm is based on the idea that the developer should work with high abstraction level models during most of the development cycle. For this to work in practice, model transformations are required. Source code, the traditional product of software development, should be generated to the largest possible extent, to minimize the amount of business logic that is outside of the scope of modeling, and is only represented by handwritten code 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 design and analysis. Historically, CASE emerged during the 1980 s, when many software development companies realized that meeting increased demand for high quality and complex software required more sophisticated development methods than those used previously. These tools arose out of developments such as Jackson Structured Programming and the software modeling techniques promoted by researchers like Ed Yourdon, Chris Gane and Trish Sarson (SSADM: Structured Systems Analysis and Design Methodology). CASE is a very broad concept, and in that sense even modern integrated development environments, such as Eclipse, or Visual Studio can be considered CASE tools. In this historical context, however, the term CASE tool refers to the earliest programs designed to assist software development and analysis. The problem with early CASE tools stems from the fact that they lacked a common approach. 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 graphical notation system, even development documentation was hardly reusable. UML The Unified Modeling Language was conceived to provide a common framework for specification, modeling, and documentation in the software development process. In many senses, it was a spectacular success, because it established a visual, easy to use notation system which was comprehensive enough to capture all major aspects of software engineering. Today, UML is the industry standard for modeling and specification. It s use is not restricted to modeling software, it is also widely used for business process modeling, organizational structure modeling, and even hardware design. UML represents a compilation of best engineering practices which

10 1.1. MODELS IN SOFTWARE ENGINEERING 9 have proven to be successful in modeling large, complex systems, especially at the architectural level. History UML was developed by Grady Booch, James Rumbaugh, and Ivar Jacobson. It was first standardized in 1997 under the supervision of the Object Management Group, a consortium, including industry heavyweights such as IBM, Hewlett- Packard, Apple Computer, and Sun Microsystems, formed in 1989 to set standards in object-oriented programming and system modeling. Along with the standardization of UML, the OMG s most important work is CORBA (Common Object Request Broker Architecture), an architecture designed to enable applications on heterogenous platforms to interoperate using a common set of application programming interfaces (APIs), communication protocols and information models. CORBA was 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 fairly large and complicated, of in-width nature, trying to achieve very ambitious goals by being everything to everyone. Model Driven Architecture The Model Driven Architecture (MDA) is OMG s newest approach to model-based software development. MDA is essentially an approach to model-based software development utilizing OMG s flagship techonogies, UML, the Meta Object Facility (MOF), XML Metadata Interchange (XMI), and the Common Warehouse Metamodel (CWM). Design goals MDA was designed with the following goals in mind: Portability and reusability, increasing application reuse and reducing the cost and complexity of application development and management. Cross-plaform interoperability, using rigorous methods to guarantee that standards based on multiple implementation technologies all implement identical business functions. Platform independence, greatly reducing the time, cost and complexity associated with retargeting applications for different platforms. Domain specificity, through domain-specific models that enable rapid implementation of new, industry-specific applications over diverse platforms (the term domain will be explained in detail in 1.1.2).

11 1.1. MODELS IN SOFTWARE ENGINEERING 10 Reverse engineering Platform Independent Model Platform Independent Model Model transformation CORBA model J2EE model Other model Platform Specific Model Code generation CORBA J2EE Other Legacy application Software application Figure 1.1. Model Driven Architecture Productivity, by allowing developers, desingers and system administrators to use languages and concepts they are comfortable with, while allowing seamless communication and integration across the teams. Moreover, a significant reduce in costs is attained by models 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 distinction between Platform Independent Models (PIM) and Platform Specific Models (PSM), thus, software development in MDA is envisioned as a three-step process. First, the Platform Independent Model is designed, which is supposed to use modeling concepts which are not platform specific. The PIM is a pure UML model, with constraints specified in the Object Constraint Language (OCL), and behavioral semantics described in Action Semantics (AS) language. The second step is to generate a Platform Specific Model, which contains additional UML models, and represents an implementation of the system under design which can run on the target platform. The transition between PIM and PSM should typically be facilitated using automated model transformation technology. Finally, application code is generated from the Platform Specific Model. 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 all of the application code Domain-specific modeling What makes a model domain specific? A domain can be defined as the set of concepts and their relations within a specialized problem field. This definition implies that all software is built to solve domain-specific problems, since software engineering is all about providing software solutions to problems in specialized problem fields

12 1.1. MODELS IN SOFTWARE ENGINEERING 11 (e.g. pharmaceutical, business processes, civil engineering). Even software design is a domain in this sense. On the other hand, in software design, the term application domain refers to a knowledge base that is outside of the scope of software development. For example, if an application for managing a book shop is being designed, all information that describes actual business processes and products, 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 the most valuable assets of software development. Domain-specific (programming) languages (DSLs) are specialized languages, suitable for 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 and comprehensive for the experts in their own domain. For example, when using SQL, it is very easy to write database queries, but it is impossible to implement an operating system kernel. In the C language, it is possible to do both, but a single line of SQL code is likely to correspond to tens, even hundreds of lines of C code. Domain-specific modeling languages Analogously to domain-specific textual languages, domain-specific modeling languages are modeling languages which operate with elements and rules that are special to the target domain. For example, if one wants to design user interfaces for mobile phones, domain-specific model elements could include Menu, MenuItem, DialPad, SMS etc. Domain-specific modeling languages are, just as DSLs, much more expressive in their domain, than generalpurpose modeling languages, such as the Unified Modeling Language (UML). Domain-specific modeling (DSM) is a new approach to model-based software development. DSM gives the designer the freedom to use structures and logic that is specific to the target application domain, and thus, completely independent of programming language concepts and syntax. Similarly to MDA, DSM is a modelbased approach, however, while MDA emphasizes the importance of a single and universal modeling language at the center of the development process, proponents of domain-specific modeling argue that flexibility and ease of use by domain experts is more important than sticking to (pure) UML. As it can be seen on Figure 1.2, in current domain-specific modeling technology, source code 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 claimed that it is exactly this difference which makes 100% code generation possible[18], this approach can make the implementation of

13 1.1. MODELS IN SOFTWARE ENGINEERING 12 DS Model Level of abstraction DS Model Generated code Generated code Domain framework PI Model PS Model Code Platform Platform Platform DSM DSM with framework MDA Figure 1.2. The difference between various DSM and MDA appoaches platform-specific code generators difficult. Thus, recent DSM approaches, such as the one presented in [34], emphasize the importance of a domain framework, which makes code generation easier by ensuring portability across various platforms (thus, this domain framework has to be implemented on various architectures, similarly to the Java or.net idea). Motivation for DSM If the model-based software development paradigm is to succeed on a wider scale, effective methods 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 as such, 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 developing a technology for software manufacturing. Others, like [18], claim that a pure DSM-based approach consistently results in productivity increases of %, compared to the mere 35% found with MDA (interestingly, all the articles refer to one and the same study[5]). Steven Kelly, the Chief Technical Officer of MetaCase 1, a company that produces a popular DSM 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 MDA incorporating elements of DSM, and these may offer some more hope. In these, the base UML can be extended with domain-specific enhancements, or even replaced with new MOF-based metamodels. However, experiences with the former have found current tools lacking the necessary extensibility, and no tools support the latter. 1

14 1.1. MODELS IN SOFTWARE ENGINEERING 13 Domain specific language engineering A domain-specific modeling environment is only effective if its visual languages are sufficiently expressive, intuitive and easy-to-use. This is only possible if the system provides support 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; Well-formedness rules, to integrate domain-specific constraints into high-level models; Dynamic semantics (simulation), to enable the designer to visualize the system as it interacts with its environments; Transformations, to facilitate the automated translation of high-level models into a low-level representation (PSMs, or application source code). Simulation is a key aspect in domain specific modeling. It enables the verification of the dynamic behavior of developed system. Each domain specific model corresponds to some part of the application code, and in order to test the correctness of the application, we must examine the run-time behavior of its components. In the area of domain specific modeling, simulation is just as important as testing and debugging in traditional programming languages Objectives From the comparison (section 1.3) of four existing DSM tools (both commercial and academic) I have concluded that the simulation (in other words model-to-model transformation) support in the majority of DSM tools is a basic set of interfaces, which may be used from external application to access and modify domain specific models. My approach was that instead of those interfaces (which requires intensive Java or C# coding), simulation should be described in a declarative form. By that I mean that concepts which describe the simulation itself should be at the same level of abstraction as the domain metamodel. Thus language engineers may focus their attention at the problem to solve (describing semantics precisely) instead of tackling with low-level programming questions. My goal was to provide a fully declarative description, which could be used both to describe actual model manipulation steps, and also different execution path (non-deterministic choice points). In my thesis, I accomplished the following tasks.

15 1.1. MODELS IN SOFTWARE ENGINEERING 14 Model transformation framework DSM framework GUI Domain- Specific Views GUI, DSL Domain expert PIM Language engineer PSM PSM Import Export External models Export / Code generation Generated code Execution Platform Figure 1.3. ViatraDSM as an approach to MDSE I evaluate the state-of-the-art of language engineering by comparing various academic and commercial domain-specific visual environments (section 1.3). I overview the Viatra2 framework, a modeling and model transformation engine made by Dániel Varró, András Balogh and András Schmidt, which may be used as a model container for domain specific models (chapter 2). I introduce the ViatraDSM framework, a general and flexible domain-specific modeling and transformation environment, which forms the central component of the Viatra2 framework (chapter 3). ViatraDSM was designed by István Ráth and myself, and its role in a model-based development process can be seen on figure 1.3. The ViatraDSM framework integrates a mathematically precise model transformation engine (Viatra2) with an easy-to-use domain-specific modeling interface in order to handles the most critical aspects of language engineering (abstract syntax, concrete syntax and certain well-formedness constraints). I design and implement a simulation module for the ViatraDSM framework, which makes use of the transformation capabilities of the Viatra2 engine to allow a declarative description of model semantics (chapter 4).

16 1.2. LANGUAGE ENGINEERING 15 I present an example using the domain of Petri nets to demonstrate both the usage of the ViatraDSM framework and the capabilities of the simulation modules (sections 3.4 and 5.1). 1.2 Language engineering With models, we can capture static attributes, as well as dynamic behavior, i.e. it is not only possible to describe the structure, but how this structure changes as the represented system 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 language refers to a visual (graphical) language. The rules and elements for modeling languages are defined 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 modeling language. In textual languages, complex expressions in concrete syntax may be faster to write in a compact form, but this also means that they can be difficult to read above a 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 to create models with syntax errors. (Note however, that semantic mistakes are much harder to eliminate - DSM tools can be good at making such faults more apparent because these can be easier to detect on a higher abstraction level). Abstract syntax defines the vocabulary of language concepts and how these can be combined in models. The abstract syntax is also called the language metamodel. Apart from the definition of language concepts and their relationships, metamodels also contain information concerning taxonomy and ontology (abstraction and specialization). Metamodels are constructed using core metamodeling languages, which are one metalevel higher, and specify what concepts can be used for language specification. An example of a core metamodeling language is MOF, or VPM (2.1.1). Well-formedness rules are constraints which must be satisfied by models. Typical examples are multiplicity constraints, aggregation (e.g. at most one parent for each model element ), or language/domain specific constraints. In UML, such well-formedness rules may be expressed as part of the model (multiplicity), or using a separate constraint description language (OCL).

17 1.3. STATE-OF-THE-ART OF DSM TOOLS 16 Dynamic (operational) semantics, in contrast to the previous three features, models the operational behaviour of language concepts. In design, simulators are just as important as static descriptions because they allow the modeler to view the system as it will effectively behave and interact with its surroundings, at a high level of abstraction. Transformations (Denotational/Translational semantics) specify how the abstract 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 very useful, they need to be transformed to a lower level of abstraction so that the platform can execute the represented system. Although domain-specific modeling is not a new idea, a breakthrough such as UML s rapid adoption is still to come. However, there has been a considerable rise in interest as influential software development houses realited the potential of DSM. In the next section, I give a brief cross-sectional view of the current state of the art in DSM technology, examining their support for each of the aforementioned aspects of language engineering. 1.3 State-of-the-art of DSM tools 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 employees ([34, 19]). History MetaCase is a Finnish-American company involved in model-based development software design since Their main product, MetaEdit+, dates back to 1995, and has won multiple awards (Best Application Development Software at CeBIT 95, Finnish National Prize for Innovation in 2000, Best Commercial Tool at Net.Object Days / GPCE 2003). Nowadays, MetaEdit+ is regarded as the leading DSM implementation. MetaEdit+ can be regarded as a proven, mature product, which makes it unique since all the other implementations examined in this part of the paper have not progessed beyond a prototype status. Architecture MetaEdit+ consists of three major components: (i) the Method Workbench for domain metamodeling, (ii) the MetaEdit+ Framework for modeling, and (iii) the Object Repository server, which serves as the model container. MetaEdit+ is a multi-platform product: every component has been ported to major

18 1.3. STATE-OF-THE-ART OF DSM TOOLS 17 Figure 1.4. MetaCase MetaEdit+ operating systems including Microsoft Windows, Linux, Solaris, and other commercial Unix variants. Typical workflow The typical workflow is the following: (1) first, a domain language is designed by the language engineer in the Method Workbench; (2) this language description is imported into the MetaEdit+ Framework through the Object Repository, and used to create domain-specific models by designers; (3) a code generator is constructed using a custom domain-specific textual language; (4) documentation (reports) and application source code is generated from the models stored in the Object Repository using the pre-defined documentation generator and the custom-made code generator. MetaEdit+ does not use code generation for domainspecific editors; instead, the framework generates an interface from the domain 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 the category 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 can design complex concrete syntax elements without writing any code. Symbol elements can be conditional on property values and can display values calculated by generators, allowing dynamic graphical behavior. Commonly used symbols or parts of symbols can be stored in the Symbol Library for

19 1.3. STATE-OF-THE-ART OF DSM TOOLS 18 reuse. Abstract syntax MetaEdit+ uses an own core metamodel, which basically describes a directed graph with typed nodes and edges; nodes are called Objects and edges are called Relationships. Properties of arbitrary types can be assigned to both Objects and Relationships. Type constraints for Relationship endpoints can also be specified. Well-formedness rules Both static and language-specific well-formedness constraints are supported. With the Port Tool, possible interfacing constraints when connecting objects can be 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 how its concepts can be related to each other and how many connections (of certain type) are allowed between each instance. For example, it may be defined that an instance of Initial State may have only one triggering connection and that the instance must send the same notification event to at least two places. This type of rule forces then all developers using MetaEdit+ to make correct definitions for initial states. It is unclear whether all constraints are enforced during editing in an event-driven manner (in effect making syntactic errors impossible), because it is also mentioned that it is possible to make reports which check the consistency of the models, which suggests a batch-mode type constraint enforcement approach. Dynamic semantics MetaEdit+ provides an API to read, create, and update model elements, 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 to manage specifications of whole modeling techniques, such as State Diagram and Component Diagram. Techniques are composed of the Objects, Relationships and Roles defined with other tools, together with bindings and rules on how these can be connected. Different techniques can be integrated with explosions, decompositions and reusable modeling concepts. Thus, as I understand, MetaEdit+ provides a mechanism for subtyping your concepts with pre-defined dynamic semantics (e.g. State Machines), and the code generator will generate code based on the generic template defined for the dynamic semantics description. However, customized model simulation support is NOT present in MetaEdit+, only some kind of code execution tracking mechanism is provided (which shows the Active State, for example, if the generated source code is step-debugged in a separate view). Note that available documentation on this topic is rather unclear.

20 1.3. STATE-OF-THE-ART OF DSM TOOLS 19 Transformations Model-to-model MetaEdit+ was not designed to be a (mathematically precise) model-to-model transformation system. Although the documentation mentions the possibility of creating rules that define how the concepts of one modeling language can be related to concepts in another, all publications suggest that MetaCase s approach is based on the idea that code should be generated directly from domainspecific models, instead of going through several intermediate levels of abstraction (e.g. PIM and PSM in MDA). Model-to-code MetaEdit+ supports automatic code generation for predefined and user-defined programming languages. The possibilities for automatically generating the code depend on the methods used and target programming languages. Predefined code generators are available for Smalltalk, C++, Java, Delphi (Object Pascal), SQL, CORBA IDL. 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 maintains and enforces the consistency between the tools. Apparently, there is no support for external or relational database model containers. MetaEdit+ offers prebuilt 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 or configuration information and export models to other programs, such as simulators, version management, external solvers etc. The advanced scripting commands allow the user to print designs in various formats, handle output to several files, and even call external programs.

21 1.3. STATE-OF-THE-ART OF DSM TOOLS 20 Advanced features design environment using SOAP/Web Services. The Object Repository can be integrated into the existing Success stories According to the official MetaCase homepage, MetaEdit+ has already been successfully used in the following target application domains: Mobile devices, Embedded software, Financial applications, Industrial automation, Web applications, Workflow applications, IP Telephony services Microsoft DSL Tools Note: this short review is based on the official Microsoft DSL Tools homepage[28], the official DSL 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 development process. These new tools are part of a vision for realizing Software Factories, a new development concept by Microsoft. In a nutshell, a Software Factory is a development environment 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 on domain-specific modeling. 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 in the next 10 years is going to be visual modeling tools, that will reduce software coding by a factor of five. [36] Microsoft s vision of model-driven software development, Software Factories, was laid out in a book[17] in In a nutshell, this approach argues that the software development industry is in a desperate need of a paradigm shift, because, although the added value in software 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 of the past century. The key to this, as they conclude, is a model-driven development approach based on domain-specific modeling. As a result, Microsoft began developing technologies that would turn this vision into reality. The result, a suite called Microsoft DSL Tools, was released to the public in late Architecture The DSL Tools suite integrates into the powerful Visual Studio development platform as a set of development environment plug-ins. The suite of

22 1.3. STATE-OF-THE-ART OF DSM TOOLS 21 Figure 1.5. Petri net modeling with Microsoft DSL Tools (beta) tools is supported by a code framework that makes it easier to define domain models and to construct a custom graphical designer hosted in Visual Studio. The suite consists of: A new project wizard for creating a fully configured solution in which you can define a domain model that consists of a designer and a textual artifact generator. Running a completed solution from within Visual Studio opens a test solution in a separate instance 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 implementing designers is generated. This allows you to define a graphical designer hosted in Visual Studio without any hand coding. A set of code generators, which take a domain model definition and a designer definition as input, and produce code that implements both of the components as output. The code generators also validate the domain model and designer definition, and raise errors and warnings accordingly (code generators for generating domain-specific editors). A framework for defining template-based artifact generators, which takes data

23 1.3. STATE-OF-THE-ART OF DSM TOOLS 22 (models) 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# script embedded in the template (code generators for domainspecific output). Thus, the DSL Tools suite employs code-generated editors running in a separate Visual Studio 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 designer definition; (3) create the text templates for the domain-specific output code generators; (4) define concrete syntax representation using the provided graphical designer; (5) generate code and resources for the domainspecific editor plug-in; (6) launch the created plug-in in a new Visual Studio instance and edit domain-specific models; (7) use the domain-specific output code generator templates to generate application source code. Language Engineering support Concrete syntax The DSL Tools suite provides a built-in graphical designer; the suite uses an own metamodel for the description of shapes and decorators, which is rather limited in 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 there is 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 Diagrams from logical models using diagram maps, which are embedded into the designer definition XML file. Abstract syntax There are six predefined templates, and the generator wizard requires the user to choose one as a starting point for the newly defined domainspecific modeling language. However, there is no need to code view classes in C#, as these graphic artifacts can be designed using the provided graphical designer tool. The speciality of the DSL Tools suite is that not only the appearance of the diagram elements can be customized, but the views, palettes, and other components of the generated editor plug-ins as well.

24 1.3. STATE-OF-THE-ART OF DSM TOOLS 23 Minimal Language - A simple template that creates a very small, generic language to build upon, including only two domain concepts, and a notation comprising one box and one line (this is the generic directed graph with assigned types and properties). Simple Architecture Chart - A template that includes an example of each of the notational 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 transformations. Model-to-code transformations are supported through a template engine, based on C# scripts. Integration The DSL Tools suite is integrated into Microsoft s leading development platform, Visual Studio. However, as the DSL Tools suite is essentially a technological demonstration, no other integration options have been implemented (and the documentation is rather self contradictory on this topic). Persistence Models are stored and exported in XML files.

25 1.3. STATE-OF-THE-ART OF DSM TOOLS 24 Figure 1.6. VMTS Presentation Framework - Adaptive Modeler VMTS Note: this short review is based on the official VMTS homepage[48], and a study comparing different prototype model transformation tools[10]. The Visual Modeling and Transformation System (VMTS) is an integrated metamodeling and model transformation system, developed at the Department of Automation and Applied Informatics of the Budapest Univertity of Technology and Economics. For model visualisation and domain-specific modeling, a tool called Adaptive Modeler is available. As of October 2005, the current version of the suite is 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 side consists of the Rule Editor, Modelers and other applications. Typical workflow As of now, automatic generation of domain-specific editors for VMTS is only partially supported, manual coding is required for visual syntax and editing functionality. 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 selecting model elements. (iii) Automatic serialization for the properties of the model elements. (iv) Sophisticated presentation of attributes, model structure, visualization information and editing features[10].

26 1.4. ECLIPSE-BASED TOOLS 25 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 model transformation framework, a powerful, graph transformation-based model transformation engine is provided, using a UML-like notation. Integration VMTS offers a Traversing Model Processor interface, where the model elements appear as regular objects in a programming language, and traversing classes are also provided by the framework. The types of these objects are obtained from the metamodel[10]. 1.4 Eclipse-based tools The Eclipse Integrated Development Environment The Eclipse Project[6] is an open source software development project dedicated to providing a robust, full-featured, commercial-quality, industry platform for the development of highly integrated tools. It was developed by IBM from 1999, and a few months after the first version was shipped, IBM donated the source code to the Eclipse Foundation. The Eclipse Platform has an easily-extendable modular architecture, where all functionality is achieved by plugins, running over a low-level core called Platform Runtime. This runtime core is only responsible for loading and connecting the available plugins, every other functionality, such as the editors, views, project management, is handled by plugins. The plugins bundled with Eclipse Platform include general user interface components, a common help system for all Eclipse components, project management and team work support Eclipse Modeling Framework The Eclipse Modeling Framework (EMF)[7] is a Java framework and code generation facility for building tools and other applications based on a structured model. EMF is also maintained by the Eclipse Foundation within the scope of Eclipse Tools

27 1.4. ECLIPSE-BASED TOOLS 26 Project. EMF started out as an implementation of the OMG Meta Object Facility (MOF) specification, and evolved into a highly 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 to annotate existing Java source files with EMF model properties. Once an EMF model is specified, 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 will be preserved during code-regeneration. In addition to simply increasing productivity, building an application using EMF provides several other benefits like model change notification, persistence support including default XMI and schema-based XML serialization, a framework for model validation, and a very efficient reflective API for manipulating EMF objects generically. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications. EMF consists of two fundamental frameworks: the core framework and EMF.Edit. The core framework provides basic generation and runtime support to create Java implementation classes for a model. EMF has a built-in serialization facility, which enables the developer to save (and load) instances of the model into industry-standard XMI format. EMF also provides a notational and persistence mechanism, on top of which model-manipulating tools can easily be constructed. EMF.Edit is a framework which includes generic reusable classes for building editors for EMF models. It provides content and label provider classes, property source support, and other convenience classes that allow EMF models to be displayed using standard Eclipse user interface views and property sheets. It also provides a command framework, including a set of generic command implementation classes for building editors that support fully automatic undo and redo for models. Finally, it provides a code generator capable of generating everything needed to build a complete editor plugin for an EMF model. It produces a properly structured 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, using GEF, 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 decide how the view is implemented. The connection between the controller and the model uses the aforementioned EMF notification mechanism. EMF.Edit can also automatically generate a tree-view based editor, which integrates

28 1.4. ECLIPSE-BASED TOOLS 27 into the Eclipse platform as a plugin Graphical Editing Framework The Graphical Editing Framework (GEF) for Eclipse is an open source framework dedicated to providing a rich, consistent graphical editing environment for applications on the Eclipse Platform. In other words, it is a complex system, or graphical library, designed to make developing graphical editors for Eclipse easy and quick. Eclipse is, apart from being a great Integrated Development Environment, a general design tool in the sense that its modular plugin centered design enables the user to integrate graphical modeling tools, interface editors and other GUI-driven components into this rich environment, and have these work together flawlessly. In order to avoid confusing the users with numerous different-looking and working interfaces, and to enable developers to create graphical plugins quickly and efficiently, this framework was developed by the Eclipse Project. The word Graphical in GEF is provided by Draw2D, a lightweight graphical component library. Lightweight means that Draw2D elements (unlike SWT 2 widgets) do not require a separate handle from the operating system window manager. The advantage of a lightweight system is that an entire element hierarchy is seen as a single element from the outside, therefore the 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 lightweight library 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 Draw2D figure may contain other figures. The only constraint imposed on a figure hierarchy is that child figures must lie entirely within the boundaries of their parent. Draw2D includes a basic set of predefined figures (polygons, labels, borders, buttons, arrows,...) but developers might create their own user-drawn figures. The Editing capabilities of GEF are very similar to the Eclipse Platform itself. It uses the 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 an OS-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 are received by the model elements involved and translated to one or more commands. A command is responsible for the effective modification of the model. GEF follows the Model-View-Controller (MVC) pattern. MVC divides the responsibilities of an editor and assigns them to three distinct elements. The model 2 Standard Widget Toolkit, the default widget library of Eclipse Platform products.

29 1.4. ECLIPSE-BASED TOOLS 28 User acts GEF EditPart (Controller) notifies updates sees modifies VIEW VIEW queries MODEL Figure 1.7. MVC scheme inside the Graphical Editing Framework is solely responsible for representing the data being displayed. That includes serialization (if required) and model manipulation. The model itself is not required to be aware that there is a graphical editor built upon it. The view, on the other hand, is only responsible for the visualization of the model. The view does not care about model manipulation, it just simply updates itself from time to time to reflect changes in the model. What forms the bridge between the two is the controller. The controller is responsible both for modifying the model according to user activities, 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 care about what kind of model we are using, the views are required to be Draw2D figures and the controller 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 other graphical library, GEF was specifically designed for graphical editors. Thus, if the goal is to not only display data, but also be able to manipulate it, one should consider using GEF instead of implementing everything from scratch. GEF provides ready solutions for a list of common 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 been tested together. GEF has already been successfully used for commercial applications, like UML editors, GUI builders and workflow management software Eclipse GMF Even though both EMF and GEF are fairly powerful tools in the hands of a professional Java programmer, the Eclipse developers have realized that, in their current from, these technologies are simply inadequate for rapid language engineering. Thus,

30 1.4. ECLIPSE-BASED TOOLS 29 an intermediate framework was drafted, which would serve as a generative bridge between EMF and GEF, whereby a diagram definition would be linked to a domain model as input to the generation of a visual editor. This is The Graphical Modeling Framework[14] project, which aims to provide the fundamental infrastructure and components for developing visual design and modeling surfaces in Eclipse. Architecture GMF uses generated editors, which are planned to support the following features: Palette, Properties, Overview (bird s eye view), Zoom, Navigator, Outline, Decorators, Keyboard bindings, Direct editing, Drag and drop, Layout, Support standard graphical editor facilities (actions, rulers, guides) provided by GEF, Provide support for compartments/subcompartments, Feedback (in status line) for constraint violation, advice; and Filter views. Typical workflow The typical workflow to create a domain-specific editor and a code generator 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, add OCL constraints; (4) design the visual representations for diagram elements using a graphical interface; (5) generate the domain-specific visual editor; (6) use the generated Eclipse plug-in for modeling; (6) manually implement a JET-based code generator; (7) generate application code. Concrete syntax The GMT project plans a full-fledged visual toolkit based on Draw2D primitives, using an intuitive graphical interface integrated into Eclipse. Diagram modeling support A diagram may contain multiple references to a single domain model element, potentially with each having a different diagram representation. A diagramming metamodel will be provided to allow for diagram definitions. A mapping metamodel will be provided to allow for diagram to domain model mapping definitions. Diagram elements may not map directly to domain model elements, but rather be a derived value of some expression or query. For example, a hierarchical or flat view representation of a UML class as defined in The UML Profile for Framework Architectures requires information from an entire class hierarchy for representation on a diagram. Abstract syntax The GMF allows for the creation of a new EMF model using a graphic editor, leveraging an ECore modeling surface. Well-formedness rules Diagram and/or domain models may have constraints added which need to be manifested as feedback in the graphical editor. For example, a constraint indicating that circular relationships are not allowed should be

31 1.5. EXAMPLE: PETRI NET 30 indicated in the UI while attempting to make such a connection (editing time enforcement). Constraints may be defined in the diagram and/or domain models that are more appropriately checked in a batch mode, as is done with the EMF validation framework. GMF should allow for constraints to be enforced using this or similar framework. GMF will provide support for the Object Constraint Language (OCL). Dynamic semantics None. Transformations Only model-to-code generation using JET Tool summary Four major DSM tools have been examined, and it can be concluded that current domain specific frameworks do a great job in terms of model visualization and editing, but they tend to lack simulation support. The only exception was VMTS, where a powerful graph-based transformation engine is present, allowing simulation to be expressed declaratively. The three other tools (MetaEdit+, Microsoft DSL Tools and Eclipse/GMF) only provide a programming interface, through which models may be queried and modified externally. In the area of my research, which focuses on simulation support for domain specific languages, transformation play a key role, since it is them, which allow domain semantics to be described in a simple way. Clearly, a language engineer may encode the simulation rules using Java (Eclipse/GMF) or C#(DSL Tools), but his job is facilitated, if he may operate at a much higher level of abstraction. In the following chapters, I introduce the Viatra2 framework, which has a powerful transformation engine based on graph patterns and abstract state machines, both of these concepts represent model manipulation at a high level of abstraction. I also introduce the ViatraDSM framework, allowing domain specific model access using the general (domain-independent) model space of the underlying Viatra2 tool. Finally, I elaborate a simulation module for the ViatraDSM framework, allowing domain semantics to be described in a declarative way using the GTASM language of the Viatra2 system. 1.5 Example: Petri Net In the coming chapters, the following simple but descriptive domain-specific visual language example will be used for demonstrating the feasibility of the research.

32 1.5. EXAMPLE: PETRI NET 31 Petri nets are widely used to formally capture the dynamic semantics of concurrent systems due to their easy-to-understand visual notation and the wide range of available analysis tools. From a system modeling point of view, a Petri net model is frequently used for correctness, dependability and performance analysis in early stages of design. Petri nets are bipartite graphs, with two disjoint sets of nodes: Places and Transitions. Places may contain an arbitrary number of Tokens. A token distribution defines the state of the modeled system. The state of the net can be changed by firing enabled transitions. A transition is 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 transition by InArcs) and add a token to all output places (as defined by OutArcs).

33 Simulation and transformation of domain-specific languages Dávid Vágó Chapter 2 Viatra2: VIsual Automated TRAnsformations The Viatra2 framework is a general modeling (and metamodeling) and model transformation tool, developed by András Balogh and András Schmidt (original version was developed by Dániel Varró). My research uses both the modeling capabilities and the transformation engine of that tool. Domain specific models are stored in the Viatra2 model space (chapter 3), and simulations are described as model transformation sequences (chapter 4). This chapter is based on the works of Dániel Varró concerning the VPM (meta)modeling language and the GTASM tutorial written by András Balogh and others. 2.1 Metamodeling: Definition of abstract syntax In this section, I conceptually follow [3] Visual and Precise Metamodeling Currently, most widely used metamodeling languages (e.g. ECore) are derived (with slight variations) from the Meta Object Facility (MOF) [27] metamodeling standard issued by the OMG. However, as stated in [42], the MOF standard fails to support multi-level metamodeling, which is typically a critical aspect for integrating different technological spaces where different metamodeling paradigms (e.g. EMF, XML Schemas) are used. Therefore, the VPM (Visual and Precise Metamodeling) [42] metamodeling approach was chosen in the Viatra2 framework, which can support different metamodeling paradigms by supporting multi-level metamodeling with explicit and generalized instance-of relations. 32

34 2.1. METAMODELING: DEFINITION OF ABSTRACT SYNTAX 33 instanceof ModelElement ID: string Name: string isfinaltype: boolean supertypeof to from value: string Entity Relation multiplicity: enum isaggregation: boolean containment inverse Figure 2.1. The VPM Metamodel The VPM language consists of two basic elements: the entity (a generalization of MOF package, 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 relations represent the relationships between other model elements 1. Furthermore, entities may also have an associated value which is a string that contains application-specific data. Model elements are arranged into a strict containment hierarchy, which constitutes the VPM 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 qualified name (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 name of the entity concatenated (separated with a dot). a Relation s fully qualified name is the fully qualified name of source and the name of the relation concatenated (separated with a dot). There is an entity with no parent: the root entity is the root of name hierarchy. The fully 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 the VPM modelspace: the containment hierarchy for entities must not contain loops, and for every relation, it must be true that a finite traversal along the source 1 Most 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.

35 2.2. THE VTCL LANGUAGE 34 endpoints ends up at an entity (otherwise, the fully qualified name would be infinite). This constraint is enforced by the runtime VPM core implementation. There are two special relationships between model elements: the supertypeof (inheritance, generalization) relation represents binary superclass-subclass relationships (like the UML generalization concept), while the instanceof relation represents type-instance relationships (between meta-levels). By using an explicit instanceof relationship, metamodels and 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) instanceof(a, c) If the isfinaltype attribute of a VPM element is set to true, then only instances of that model 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 in the metamodel, when an instance of the relation implies that the target element of the relation instance also contains the source element. (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 relation denotes the other association end along an association. (iii) Relations also have multiplicities, which impose a restrictions on the model structure. 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 plan generator. 2.2 The VTCL language Transformation descriptions in Viatra2 consist of several constructs that together form an expressive 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 state machine (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 Command Language (VTCL). This language is primarily textual, but it will soon

36 2.2. THE VTCL LANGUAGE 35 be extended by a graphical editor that will support the graphical definition of model transformations Graph patterns Graph patterns, negative patterns Graph patterns are the atomic units of model transformations. They represent conditions (or constraints) that have to be fulfilled by a part of the model space in order to execute some manipulation steps on the model. A model (i.e. part of the model space) can satisfy a graph pattern, if the pattern can be matched to a subgraph of the model using a generalized graph pattern matching technique presented in [41]. In the following example, a simple pattern can be fulfilled by class instances that do not have parent classes. /* C is a class without parents and 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 ); } } Patterns are defined using the pattern keyword. Patterns may have parameters that are listed after the pattern name. The basic pattern body contains model element and relationship definitions, which are identical to the VTML language constructs. The keyword neg marks a subpattern that is embedded into the current one to represent a negative condition for the original pattern. The negative pattern in the example can be satisfied, 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 the pattern matches to top-most classes in parent hierarchy. There are also check conditions that are Boolean formulae which must be satisfied in order to 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 that negative conditions can be embedded into each other in an arbitrary

37 2.2. THE VTCL LANGUAGE 36 depth (e.g. negations of negations), 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 enables the reuse of existing patterns as a part of a new (more complex) one. The semantics of this reference is similar to that of Prolog clauses: the caller pattern can be fulfilled only if their local 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 the pattern name and parameter definition, and connecting them with the or keyword. In this case, 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 recursive pattern. 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 illustrates the 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 { 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 child class (first body), or it has a direct child (C), which is the parent of the child class (second body). The pattern uses recursion for traversing multi-level parentchild relationships, and uses 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 substitution for the free (unbound) parameters of the specified graph pattern has to be found that satisfies the pattern. If there are bound variables passed as parameters, they are treated as additional constraints, and they remain substituted (bound) throughout the pattern matching process. By default, the free variables

38 2.2. THE VTCL LANGUAGE 37 will be substituted by existential quantification, which means that only one (nondeterministically selected) matching will be generated. If a variable is universally quantified by the external forall construct (see Sec ), the matching will be done (in parallel) for all possible values of the given variable Graph transformation rules While graph patterns define logical conditions (formulas) on models, the manipulation of models is defined by graph transformation rules [9], which heavily rely on graph patterns for defining the application criteria of transformation steps. The application of a GT rule on a given model replaces an image of its left-hand side (LHS) pattern with an image of its right-hand side (RHS) pattern. Figure 2.2. Sample graph transformation rule The sample graph transformation rule in Figure 2.2 defines a refactoring step of lifting an attribute from child to parent classes. This means that if the child class has an attribute, it will 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 contains a precondition pattern for the LHS, and a postcondition pattern that defines the RHS of the rule. Elements that are present only in (the image of) the LHS are deleted, elements that are present only in RHS are created, and other model elements remain unchanged. gtrule liftattrsr ( in CP, in CS, in A) = { 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);

39 2.2. THE VTCL LANGUAGE 38 } } UML. Class. attrs ( Attr2,CP,A); The graph transformations rules are defined using the gtrule keyword, and they are allowed to have directed (in/out/inout) parameters. The LHS and RHS patterns share information on matchings by parameter passing. The second format directly corresponds to the graphical (FUJABA [31]) notation as shown in 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 jointly defines the left hand side (LHS) of the graph transformation rule, and the actions to be carried out. Pattern elements marked with the keyword new are created after a matching for the LHS is succeeded (and therefore do not participate in the pattern matching), and elements marked with the keyword del are deleted after pattern matching. In both cases, further actions can be initiated by calling any ASM instructions within the action 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 the procedural programming languages. The rule contains a precondition (LHS), like the previous one, 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 2.2.3). The actions that are defined after the action keyword are executed sequentially. It is important to note that the action section can also be used with the other two forms of graph transformation definition, for example to create debug outputs or generate code. gtrule liftattrsr ( in CP, in CS, in A) = { precondition pattern cond (CP,CS,A, Attr ) = { UML. Class (CP ); UML. Class (CS );

40 2.2. THE VTCL LANGUAGE 39 } 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 Viatra2 framework supports all these formats simultaneously, so developers 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 a certain metamodel, Viatra2 supports generic and meta-transformations, which are built on the multilevel metamodeling support. For instance, we may generalize rule liftattrsr as lifting something (e.g. an Attribute) one level up along a certain relation (e.g. parent). The following example is the generic equivalent of the previous GT rule parameterized by types taken 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 ); }

41 2.2. THE VTCL LANGUAGE 40 } Compared to liftattrsr, this generic rule has four additional input parameters: (i) ClsE for the type of the nodes containing the thing to be lifted (Class previously), (ii) AttE for the 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 Viatra2 engine first instantiates the type parameters (ClsE, ParR, etc.) and then queries the instances of these types. As a result, the same rule can be applied in various modeling languages Control structures To control the execution order and mode of graph transformation the VTCL language includes some concepts that support the definition of complex control flow. As one of the main goals of the development of VTCL was to create a precise formal language, we included the basic set of Abstract State Machine (ASM) language constructs [4] that have formal semantics and correspond to the constructs in conventional programming languages. The basic elements of an ASM program are the rules (that are analogous with methods in OO languages), variables, and ASM functions. ASM functions are special mathematical functions, 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 they cannot change their values. For example, the basic mathematical functions (+,-,*,/) are static. In VTCL, a special class of functions, called native functions, is also defined. Native functions are user-defined Java methods that can be called from the transformations. These methods 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 calculations during the execution of model transformations. ASMs provide complex model transformations with all the necessary control structures including the sequencing operator (seq), rule calls to other ASM rules (call), variable declarations and updates (let and update constructs) and if-thenelse structures, non-deterministically selected (random) and executed rules (choose), iterative execution (applying a rule as long as 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 of graph transformation rules are also given as ASM programs.

42 2.2. THE VTCL LANGUAGE 41 The following example demonstrates 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, and does not do anything else. If may be used in a choose or forall loop, when actions are performed using graph transformation rules. fail This rule always fails. It can be used to either exit from a ASM subroutine (rule) or to cancel an iterate loop. call This rule calls an other rule. Parameters of rules are defined in the rule header (just like in any traditional programming languages). seq The rule denotes a sequential list of other rules, which are executed one after the other. If any rule in the sequence fails, the seq rule itself also fails. iterate This rule iterates its argument until it fails. iterate may be thought of as an infinite loop, whereby fail serves as a kind of break possibility from this loop.

43 2.3. ARCHITECTURAL OVERVIEW 42 random The rule executes the rules listed in its body in a (pseudo-)random order. The random rule fails only if all rules in its body fail. forall, choose These rules are the most common iteration rules. They have unbound arguments, a target formula and a rule body. The body rule is executed for all possible binding of arguments which satisfy the formula. In most cases, the formula is a graph pattern (or a graph transformation rule), in that case, the body of the loop is executed for all possible matches of the pattern (or the precondition pattern of the graph transformation rule). The unbound arguments may be bound only to model elements, and with in and below qualifiers we may limit the range of checked model elements. print, log These rules write an arbitrary string to either the code output (in case of print), or the log file of Viatra2 (in case of log). The print rule may be used for code generation, since its output is passed on the optional code formatter plugins. 2.3 Architectural overview The VIATRA2 framework The Viatra2 framework is a stand-alone model container and transformation framework, which can be integrated into the Eclipse IDE as a plug-in. In stand-alone mode, the Viatra2 system 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 and undo-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 generators. The current implementation of the system allows for multiple framework instances within a single Eclipse workbench, thereby enabling users to work with multiple VPM model spaces (and editors) simultaneously. As it can be seen on Fig. 2.3, the internal structure of the Viatra2 framework can be split up into four major components: 1. VPM modelspace container and VPM core interfaces

44 2.3. ARCHITECTURAL OVERVIEW 43 Eclipse integration components editor GUI Output formatter VIATRA2 Framework VPML VTML parser VTCL parser Native importer interface Importers GTASM interpreter Pattern matcher Core interfaces VPM Modelspace GTASM models Model Figure 2.3. The architecture of the Viatra2 framework 2. Pattern matcher 3. GTASM interpreter 4. Import/export facilities The development work of András Schmidt consisted of the implementation and optimization of the VPM core, the pattern matcher, and the GTASM interpreter (marked with red on Fig 2.3). VPM Core The VPM Core implementation defines a low-level, simple interface. This interface ensures the integrity of the model. All other components, including the editors and importers, use this interface for queries and modifications. The VPM Core also supports a notification mechanism, an arbitrary depth undo/redo interface, and a simple global locking mechanism to provide preliminary support for concurrent modifications and asynchronous transformations. Import/export facilities To facilitate the integration of the Viatra2 framework into an existing model-driven development infrastructure, the native importer interface provides support for the construction of import plug-ins which read native formats and instantiate models in the VPM modelspace. The Viatra2 language (VTML and VTCL) parsers are also implemented as native importers (by András Balogh).

45 2.4. SUMMARY 44 Pattern matcher Pattern matching is an experimental subject. The efficiency of the whole model transformation system highly depends on the efficiency of model storage and pattern matching. Therefore, we designed the Viatra2 system so that it can be used as a framework of future pattern matchers. There are experiments with different matchers (such as [44]). If they were inserted into the Viatra2 framework then all features of the GTASM language would automatically work with that implementation (eg. recursive pattern matching and merging sub-patterns). GTASM interpreter That component is responsible for running abstract state machines. It relies heavily on the pattern matcher for resolving the formulae of choose and forall loops. 2.4 Summary This section introduced the Viatra2 framework, which supplies the modeling and transformation infrastructure of our Multi-Domain Systems Engineering approach. After establishing the theoretical and practical background necessary to understand how Viatra2 can be used to provide language engineering and domain integration support, the next chapter will show how our conception of a domain specific modeler tool is implemented. Finally, chapter 4 will show how to use graph transformation rules and abstract state machines to describe domain semantics in a declarative and precise way.

46 Simulation and transformation of domain-specific languages Dávid Vágó Chapter 3 ViatraDSM: Domain-specific modeling for Viatra2 The ViatraDSM framework is an extension to the Viatra transformation system, which enables the editing of domain-specific models and (as the goal of my research) their simulation. This chapter introduces the basic concepts of the ViatraDSM framework based on a Scientific Students Report written by András Schmidt, István Ráth and myself in November Domain specific modeling is 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 domain specific application model is no longer just part of the system documentation but it is the 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 only a narrow, specialized set of applications. So an out-of-the-box editor satisfying the requirements of a company can hardly be found. Therefore when a software developer company decides to switch to DSM method, the first step is to create a domain specific editor, which covers the domain of their products. That job is done by the domain language engineers, a team of experienced developers who have a broad knowledge of the domain itself and also know the patterns and best practices of coding. Creating an editor from scratch is however a very difficult job to do. The language engineer would have to take care of model representations, graphical editing, source code generation, and so on. We want to facilitate the job of language engineers by 45

47 3.1. GOALS 46 providing a solution for the common problems that arise during the development of a domain specific editor. Such a framework allows engineers to focus on the domain language itself instead of dealing with various implementation specific questions. In chapter 1 multiple existing DSM frameworks (tools) were examined, and compared by various aspects, like syntax representation (both abstract and concrete) or transformation support. We used this comparison to find the best part of existing solutions, and integrate them into a single framework. Since we already have a modeling and transformation engine, Viatra2, it seems a straightforward idea to build such a framework on top of that tool, and make use of its capabilities. In this section, the DSM framework will be discussed, a tool which uses Viatra2 as a model container, and provides domain specific editing functions, together with simulation and code generation support based on graph transformation. 3.1 Goals The comparison of existing DSM tools in chapter 1 included various criteria. Concrete syntax, which in other words means graphical model representation, is essential in the success of a DSM 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 define how model elements are being displayed. Also, in case of modeling complex systems made up of heterogeneous 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 other part is modeled with data flow networks. To be able to visualize the interaction between the two parts, the DSM tool should support diagrams, where elements from multiple domain may be displayed at the same time. An other comparison criteria was abstract syntax representation. That means how the models are actually stored within the DSM framework. Most tools use their own built-in modeling framework (like ECore for EMF), while others (like openarchitectureware) leave the problem of model representation to the user. What is important about abstract syntax is to support the import of metamodels from other modeling tools. DSM tools in general support the import of UML-based metamodels, so a language engineer may reuse an existing metamodel of the domain. Finally the third important criteria was dynamic behavior, in other words simulation support. That means, that domain-specific models may be executed within the DSM framework, and the user can examine how the actual software based on that model will operate. My ongoing research focuses on this area, and the results

48 3.2. ARCHITECTURE 47 will be presented in chapter 4. In our tool, the abstract syntax representation is handled by the Viatra2 framework. In our conception, domain specific models (as well as metamodels which describe them) are stored inside the Viatra2 model space, which allows us to benefit from the powerful transformation capabilities of the Viatra2 tool. Chapter 4 will show how to use those transformation capabilities to describe domain semantics in a simple, declarative way. In the area of graphical representation, our tool uses a GEF-based graphical editor. Our framework provides a basic set of concrete syntax elements (simple rectangular box and arrows), but it enables the language engineer to define his own graphical elements, moreover, the entire graphical editor may be replaced by some custom implementation, if needed. Besides this customizable graphical editor, our framework provides a simple, perspicuous, tree-structured representation of the model. 3.2 Architecture Figure 3.1 shows the overall architecture of our DSM framework. At first sight it looks complex and hard to understand. In the next few sections we will elaborate the concepts of that figure, giving detailed descriptions of every major component of our framework. But before going into details about that architecture, we will examine what other architectures could have been possible, and why did we choose this particular version Editor generation or runtime framework? The first question which arises when creating a DSM framework is how actual domain specific editors will function. There are two major approaches, editor generation and runtime framework. Editor generation means that based on the metamodels, the code of the domain specific editors are generated by the DSM tool. This approach is used for example by the Eclipse Modeling Framework (EMF). Using EMF, the domain metamodel is specified using an UML diagram or an XML schema definition. From the definition the EMF generates both Java classes, which implement elements of the metamodel, and a simple tree-structured editor, which allows the editing of models. The other approach is runtime framework, which means that there is a general (domain independent) model editor, which takes the metamodel as one of its inputs, and uses that metamodel to validate model editing actions. An example of this sec-

49 3.2. ARCHITECTURE 48 Plugin View Classes Custom plugin components Icons Labels, tooltips Other GEF VIATRA2 DSM Framework Diagram EditParts Diagram model Diagram Manager Interface Modelspace DSM Thin Wrapper DSM core metamodel Eclipse Extension Point Tree EditParts DSM metamodel mapping Domain metamodel Domain actions and commands Notification mapping Model Figure 3.1. Detailed architecture of the DSM framework ond approach could be the MetaEdit+ tool. Let us get back to our well-known Petri net example to see the difference between these approaches. If we model Petri nets using EMF, the framework will generate Java classes such as Place, Transition, which implement the metamodel (eg. class Place will have methods like getcapacity()). A simple Eclipse-based editor is also generated, which allows the editing of models. The domain rules (eg. places have capacities, transitions do not) cannot be violated, since the structure of the generated classes cannot be changed (generated class 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 metamodel and domain rules within that tool. Upon the creation and editing of models, the tool will not generate a separate editor, but it will constantly check the provided metamodel to decide 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 the metamodel, whether the selected element can have a property called capacity or not. Giving a different example for comparison, the difference between the two approaches is similar to the difference between compiled (EMF) and interpreted (MetaEdit+) program execution. Before designing our DSM framework, we studied both approaches, evaluating

50 3.2. ARCHITECTURE 49 Metamodel 1 Metamodel 2 Metamodel 1 Metamodel 2 Generated editor Domain-specific Generated editor Domain-specific DSM framework Domain-independent DS model 1 DS model 2 DS model 1 DS model 2 Figure 3.2. Difference between editor generation and runtime framework the advantages 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 implementation classes and editor are generated. After code generation, the metamodel might be thrown away, since everything it describes (model structure and constraints) is reflected in the 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 changing business 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 the metamodel 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. Since a 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 language engineer usually adds more advanced features to the generated editor code to increase its usability and thus its effect on productivity. However when the metamodel changes, a new editor will be generated and all the extra features have to be added again to the freshly generated editor code. EMF has some mechanism to detect user-made (in this case language engineer) changes in the generated code, and keep the changed part intact when regenerating code, but that requires placing special tags in the source code. Therefore it is uncomfortable and more importantly, if not handled correctly, it might cause serious and hardly detectable faulty behavior in generated editors.

51 3.2. ARCHITECTURE 50 On the other hand, a runtime framework approach can get rid of this problem by having a domain 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 to use the updated metamodel. Just like the difference between fat and thin client software. For fat clients (generated editors), an update must be distributed to each client (adding all extra features 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 clients will automatically adapt to the modified system. The drawback of this runtime framework approach is reduced speed, since the metamodel must be checked at every editing action to ensure the fulfillment of domain constraints. After looking at both approaches closely, we decided to use the runtime framework method in our DSM tool implementation. It is true, that the constant processing of the metamodel requires some additional time at editing, but editing is in general carried out by a human user, therefore the time required by checking domain constraints is negligible compared to the time needed by the user to press keys and drag the mouse. However this time penalty has a greater impact on the performance while running automated transformations. But with advanced techniques like metamodel caching (see section on implementation for details) the effect of that problem can greatly be reduced. On our architectural diagram (figure 3.1) this runtime framework approach is reflect by the element DSM metamodel mapping. That component is responsible for mapping a domain 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 detailed explanation of that component will be given in section Domain specific graphical representation The main benefit of domain specific modeling is that source code can be entirely replaced by an application model. Since the key motive behind this idea is to increase productivity, we want to present these models to designers in a form as humanreadable as possible. The obvious choice is some kind of graphical representation. But since a DSM tool, like our framework, should assist to the creation of new domain specific languages, we cannot possible include the set of all required graphical elements. For certain common domains, like state machines or Petri nets, we could provide the graphical model representations, however, a language engineer might

52 3.2. ARCHITECTURE 51 decide to create a language for mouse trap design and requires graphical representations of a mouse and cheese. It is very unlikely that he would find these elements in any of the existing DSM tools. To support user-made graphical elements, there are two major ways, drawing and coding. In case of drawing, or in other word figure modeling, the DSM tool provides a simple drawing module where the user can create the required element by combining shapes, texts, colors and other graphical primitives. For example a basic class figure for an UML class diagram can be assembled from a few rectangles, lines and text labels. The alternative way, coding, requires the user to effectively write some code, using the programming interface (API) of the graphical library used by the DSM tool. The major differences between the two alternatives are the level of user influence and the required user effort. Drawing is clearly simpler for the users. A few mouse clicks and keystrokes require way less work then writing code using an API previously unknown to the user. But with drawing, we only have the set of basic elements provided by the DSM tool vendor, and that may greatly limit our possibilities. Writing code requires more work from the user, but he will have a total control of what will appear in the editor. Looking back at our mouse trap example, building the figure of a mouse from separate lines, circles and polygons (say these are the only elements provided by the DSM tool) requires much more work than writing a few lines of code, which displays a bitmap image. In terms of existing tools, the first option (drawing) is used by MetaEdit+, which incorporates a module called Symbol Editor for building complex figures from geometric primitives. On the contrary, Eclipse/GMF uses the coding approach, that framework requires domain designers to create figures as Java classes based on Eclipse s Draw2D graphics library. Even though a drawing-based approach is simpler to use, our tool requires users to create the Java implementation of their graphical figures themselves. Since our framework is based on GEF, just like the Eclipse/GMF, we are using the same Draw2D library, therefore figures between the two DSM tools can easily be exchanged. Since GMF already possesses a great number of pre-made figure galleries, those figures may be used in our framework as well. Writing Java code instead of drawing surely decreases user-friendliness, but as our tool is still at a prototype stage we do not think that a built-in drawing module is a necessity at present. We definitely do not rule out the possibility, that in the future our tool will incorporate its own drawing module, declarative diagram modeling is the main research area of István Ráth, and his future work will definitely come up with a simpler solution than the actual one.

53 3.2. ARCHITECTURE 52 Our choice about graphical model representation is reflected by the component Plugin View Classes on figure 3.1. These view classes are the short pieces of Java code a language engineer has to write to provide a custom (domain specific) graphical representation for model elements. Details about these view classes will be given in section Modeling After we have made our choice concerning the two major architectural questions, which affects the 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 (domain language structure) and the domain specific models, which are instances of the domain metamodel. Since the metamodel and the actual models are quite different, most tools use different representation formats. EMF for example requires the metamodel to be present as an XML schema or a UML class diagram, whereas EMF models are plain Java objects. Since we wanted to exploit the transformation capabilities of the Viatra2 tool, we opted for VPM 1 as a common representation format both for domain metamodels and for domain specific models. Metamodel structure Since our DSM framework supports a wide range of different domains, we have to impose certain restrictions on the domain metamodels. Just like a simple calculator, which imposes the restriction that all numbers 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 restriction is required, otherwise the calculator could not do any meaningful work. The concept what we call core domain metamodel is simply a set of constraints posed upon the domain metamodels. It defines the set of elements the language engineer may use to build up the metamodel of his own domain. It is shown on figure 3.3, and its element are described below. Editor is the topmost element in every domain. There exists only one single instance of Editor, it serves as a model container for each domain. The relation topnodes links the topmost nodes to this single container. 1 Internal model representation of the Viatra2 system.

54 3.2. ARCHITECTURE 53 Editor contains topnodes Edge Node property property Property Figure 3.3. Core domain metamodel of the DSM framework Node represent an entity in the domain metamodel. Nodes may arbitrarily be nested into each other by the contains relation. The only constraint about containment is that every node must have exactly one parent (topmost nodes have the Editor as their parent). Edge is a relation that links two nodes together. It is not shown on the figure above, but each edge may has a property called multiplicity, having four values, one-to-one, many-to-one, one-to-many and many-to-many. These multiplicities are interpreted the same way as in UML, and they are enforced at editing, thus additional constraints can be posed upon models. Properties are simple (name, value) pairs, which may be assigned to any model element 2. On diagram 3.3 only one Property entity and two properties relations are present for simplicity, but in the actual implementation both have various subtypes. Properties may be either required or optional, and its value type can either be an ordinary string, an RGB color, or one of a predefined list of possible values (enumeration). These four concepts are the basic elements a language engineer may use to build up a custom domain metamodel. Exactly one Editor element must be used as a top-level model container. Arbitrary hierarchies of nodes might be contained in that Editor container. Edges may run between any two nodes, and both nodes and edges may have any number of required or optional properties. Anything which is built using these abstract elements and the few aforementioned rules is a valid domain metamodel. 2 Model element is a common name for nodes and edges.

55 3.2. ARCHITECTURE 54 Petri Net domain petrinets Token PetriNet tokens places transitions Place OutArc InArc Transition capacity weight weight Capacity (property) Weight (property) Figure 3.4. Example of a domain metamodel (Petri net domain) On figure 3.4 we can see an example domain metamodel, a simplified metamodel for Petri nets. There is one Editor on the top, and the only topmost nodes may be Petri nets. Each Petri net may contain Places and Transitions. Places may contain Tokens and may have a property called capacity. There are two kind of edges, OutArc, which goes from a Place to a Transitions, whereas InArc is the opposite, and edge from a Transition to a Place. Both kind of edges may have a property entitled weight Diagrams Model representation is one of the most important areas in terms of efficiency and transformation support, but in terms of usability, it is overshadowed by the question of graphical model representation (concrete syntax). A developer sitting in front of our domain specific editor will not care about its internal architecture, nor how models are being represented, the only important thing for him is how easily can he use that tool to design models. Diagrams are graphical representations of certain domain specific model elements. However diagrams themselves can be regarded as some kind of domain specific model, where the domain is that of diagrams. For example, if we design a Petri net, that will be a model in the Petri net domain, however if we draw that Petri

56 3.2. ARCHITECTURE 55 Diagram Edge root model Node model NodeFigure fromedges toedges EdgeFigure DiagramElement subelements modelbindings Figure 3.5. Diagram metamodel of the DSM framework. net using circles, rectangles and arrow, that picture will be a model in the Petri net diagram domain. There is one one-way mapping between domain specific models and domain specific diagrams. Every diagram defines a model (or model part) by itself, however a model does not necessarily define a diagram (but in most cases diagram may be automatically generated from models). If we take the picture of the Petri net, it obviously defines a Petri net, we just need to build up the model from the diagram step by step. However if we just have a (not empty) Petri net model, we have infinite ways of drawing a diagram, which corresponds to this model (corresponding to various arrangement of places and transitions). Therefore we can say that domain specific models and domain specific diagrams are two distinct concepts, but they are tightly bound by modeling rules. Diagram metamodel structure The concept core domain metamodel was introduced in section 3.2.3, describing a set of common supertypes for domain metamodel elements. This concept is also present in diagram modeling, this time it is called the diagram core metamodel. Each ViatraDSM diagram is a model stored in the Viatra2 model space, and each diagram type has its own metamodel. One domain may contain multiple diagram types, just like the domain of UML has class diagrams, sequence diagrams, state charts, etc. Each of these diagrams operate on the same logical model, but each shows the model in a different perspective. In order to describe diagrams in a common format, the core diagram metamodel was introduced, which serves as a base for all domainspecific diagram metamodels and is shown on figure 3.5, whereas an example domain specific diagram metamodel (that of Petri nets) will be shown in section 3.4.

57 3.3. IMPLEMENTATION 56 Diagram is the element which represents a single diagram in our framework. It is not bound to any model objects, it just joins the elements of the diagram into a single entity. Each diagram has exactly one NodeFigure as its root. DiagramElement represents a graphical element on the diagram. It has two subtypes, NodeFigure and EdgeFigure, but it is possible to have just a DiagramElement instance (it is not abstract) to describe model-independent decorators, like notes or titles. Each diagram element may contain subelements. The modelbindings relation is used for connecting decorator diagram elements to model-related diagram elements, whose state affect them. That relation is used for declarative diagram-to-logical model mapping and discussed in the thesis of István Ráth. EdgeFigures are the graphical representation of edges in the domain specific model. They contain 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 linked to the model object they represent. Architecture summary The ViatraDSM framework extends the Viatra2 framework by providing simple means for domain specific modeling. Unlike Microsoft DSL Tools or Eclipse/GMF, which both use code generation to create editors, ViatraDSM follows a runtime framework approach, which enables it to follow metamodel changes easily, without having to regenerate and re-enrich editor code. It models both models and diagrams, but for concrete syntax representation, it requires domain engineers to create view (figure) classes using Java code. It provides a common starting point for metamodel, the core domain metamodel is the base for logical metamodels, whereas the the core diagram metamodel acts as a common ancestor for all diagram metamodel. 3.3 Implementation In this section, a few implementation details about the ViatraDSM framework will be discussed. Firt, the concept of a domain plugin is introduced, and it is shown how our framework and these domain plugins interact to form a domain specific editor. Following that, the default implementation of a domain plugin is shown. The limitations of this thesis does not allow for a detailed description, that can be found in our earlier report.

58 3.3. IMPLEMENTATION DSM framework and domain plugins As we described in the Goals section of this chapter, we aimed at a multi domain framework. Unlike MetaEdit+, where the domains defined by language engineers are completely independent, we wanted to create a framework, where models from different domains can be combined to permit the simulation of complex systems. If we have a system which is built from heterogeneous components, each component begin modeled using a different domain, only a multi domain environment would allow the simulation and verification of the entire system. A single domain tool like MetaEdit+ would only permit the simulation of the separate components, but that is not sufficient, since the entire modeled system becomes useless if the interaction between the different (and otherwise flawless) components is failing. And to simulate and verify these interactions, we need a multi domain environment. We have already introduced the Eclipse platform in chapter 1. Our DSM framework is built on top of Eclipse, it is an Eclipse plugin, which implements a multi page editor, each page of the editor corresponding to a different domain. The actual appearance of these multiple pages can be seen in section In our vision a multi domain editor still separates the domains at the editing phase, multi domain functionality only means that multi domain diagrams may be created, and multi domain transformations may be executed. A domain plugin (figure 3.6) is also an Eclipse plugin, which serves as a domain implementation for the ViatraDSM framework. Each domain plugin contributes a logical model and a diagram model, and optionally other extensions, such as simulation support, derived properties, etc. This is simply an implementation of the Delegate design pattern, the framework provides some basic services (outline view, property handling), but the actual model manipulations, outline view icons, simulation support is delegated to the separate plugins for better extensibility. There are four required delegation points, and numerous optional ones. First of all, a plugin 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 metamodel in order to verify the domain constraints during editing. Second, a domain plugin must also provide 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 through containment relations, edges and properties. Third, a domain plugin must also provide a list of domain diagram metamodels, and the available diagrams (diagram models), which correspond to these metamodels. These

59 3.3. IMPLEMENTATION 58 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 3.6. Plugin-oriented architecture of the DSM framework three contributions together are called domain implementation, and beside that the domain plugin must provide its own domain specific graphical editor, since our framework only support a simple, tree-structured visualization of models. Naturally, a language engineer do not have to code those four things himself, since our DSM framework contains a default domain plugin implementation. Our default implementation uses Viatra2 as a model (and metamodel) container and also as a diagram model (and metamodel) container. It also provides a GEF-based graphical editor with some basic figures (rectangular boxes and arrows). Generally a language engineer do not create the entire domain plugin himself, but uses our default implementation. In that case, all the engineer needs to do is one logical and an arbitrary number of diagram metamodels in the Viatra2 framework. Optionally, the engineer may extend the default plugin implementation using Java, that is needed for advanced contributions such as outline view coloring, derived properties or additional (not modeled) language constraints Viatra2 as the model container The default domain plugin implementation uses Viatra2 as a container for metamodels and models. In order for our DSM framework to function properly, both the core metamodels (both domain and diagram) and the metamodel of the used domains must be present in the initial model space. The models being edited are also stored within the same model space. The first implementation problem we encountered was how to map Viatra2 model objects to core metamodel object, and how to navigate in a domain specific model.

60 3.3. IMPLEMENTATION 59 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 wanted objects, where we can easily navigate along core metamodel relation (eg. have methods like getrequiredproperties() or getcontainednodes()). Our first approach was to use Viatra2 model objects as references and created a mapper utility, which can perform these DSM-specific navigational queries. So instead of an object, which has a getcontainednodes() method, we had a mapper utility, which had a getcontainednodes (IEntity) method, which required a Viatra2 model object as an argument. This approach is similar to reflection in programming languages like Java or C#. 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, whether that object corresponds to a Node, a Property or the global Editor. This was not a major problem itself, but because of the lack of type-safety, queries within this mapper utility were rather slow. Since the methods of the mapper utility could be called with any kind of Viatra2 model element, it was possible for example that someone issued a query for the contained nodes of a property. These queries are not valid, because properties may not contain nodes in our core domain metamodel. The mapper could detect invalid queries, but that was slow (detecting invalid queries needed multiple checks within the model and the corresponding domain metamodel), and the correct handling of invalid queries required extra coding in the methods which called the mapper. Considering all these drawbacks, we rejected this approach. Another approach could have been building up all the domain specific models within our framework, ie. copying the Viatra2 model space into a set of typed variables. That would mean we would 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 core metamodel element has its own type. It is fast, since everything is stored within our own model representation and we are completely independent of the Viatra2 model space. The problem with this approach is memory usage, and synchronization. If we build up the entire model within our framework, we will have identical information represented in two different formats. Models will be there inside the Viatra2 model space, but they will be present also in our framework. Synchronizing these two different representations for complex models can be a very laborious task, most probably by the time required to synchronize the two representations we lose all the processing time gained. Also copying the entire model nearly doubles the memory usage of our framework, that would also cause

61 3.3. IMPLEMENTATION 60 serious problems for large models. Thin wrapper implementation We have concluded that using Viatra2 references has multiple problems, most importantly because 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 to go for the middle, and created an implementation, which combines the two, a type-safe implementation which does not create a copy of the model. We call this approach thin wrapper. 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 a mapper utility to extract information upon queries. So we have interfaces like IDSMNode or IDSMEdge, and the implementation of these interfaces stores a Viatra2 reference. When the getcontainednodes() method is called upon an IDSMNode object, the implementation uses a mapper utility to extract the information from the Viatra2 model space. 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 behind complete model copy in terms of speed. A function which queries the Viatra2 model space could not possibly be as fast as just checking a few local variables. We tried a few optimization tricks, the most promising was metamodel caching. It is sure that the entire domain specific model cannot be copied, such a model might contain hundreds of complete Petri nets for example. However we may copy the domain metamodel. No matter how large the model becomes, the metamodel remains the same (generally small) size. Why would that increase the performance when the queries are run on model element? Simply because most model queries begin with a metamodel query as a first step. For example, if we want to read all the children nodes of a Petri net instance, first we have to read the metamodel to find out that a Petri net has two kinds of children, places and transitions. Without optimization, reading the children of a node requires two queries into the Viatra2 model space, one about the metamodel and a second about the model itself. If we cache the metamodel within our DSM framework, we can spare one of those queries. Caching the metamodel requires a negligible memory compared to model sizes, but the speed gain approximates twofold.

62 3.3. IMPLEMENTATION Graphical representation Our default domain plugin implementation provides also functions for graphical model representation and editing. As we have already mentioned, our implementation uses the Viatra2 model space to store domain diagram metamodels and domain specific diagrams. It was stated before, that a domain plugin must provide its own graphical editor. The default plugin implementation provides a GEF-based extensible editor, where actual graphical figures may easily be replaced by any custom figure. GEF-based extensible editor GEF has already been introduced in chapter 1, it is an editor framework for Eclipse, which facilitates the creation of graphical editors. GEF follows the Model-View- Controller (MVC) scheme, and essentially the GEF framework itself provides only the Controller part of that design. Diagram models are stored in the Viatra2 model space, GEF take the role of the controller, all that is left from the MVC pattern are the views. Our plugin implementation contains a default view both for nodes and edges, providing only basic visualization features. Our NodeFigure view is a resizable rectangular box with the name of the represented model element in the header and our EdgeFigure view is a simple arrow leading between nodes. There are multiple ways of extending this default editor. The most simple is just to provide custom figures for model visualization. In case of Petri net, that means the places and transitions are not displayed just as a plain rectangle (that would be the default view implementation), but the places are shown as circles and transitions are shown as filled rectangles. In order to change figures that way, the domain engineer must create the implementation of these custom view objects as Java classes using the Draw2D library. This requires coding, but pre-made figure catalogs, and declarative figure-to-model mappings (research of István Ráth) can reduce the amount of coding theoretically to zero. A more complex way of extending the editor is to get rid of GEF entirely, and a use a fully customized visualization environment. Although GEF is quite generic, and may be used for the majority of the domains, it has some limitations, notably in the area of performance. It is perfectly suitable for simple, 2D models, but when advanced image processing or 3D visualization is needed, GEF becomes either useless

63 3.4. EXAMPLE: PETRI NET EDITOR 62 or extremely slow. The ViatraDSM framework enables domain engineer to replace the GEF-based editor of the default plugin implementation with any specialized code (well, Eclipse-conformance is still required), therefore even an OpenGL-based three dimensional model visualization module may be used Implementation summary The ViatraDSM framework uses the Delegate pattern to enable the editing of multiple domains within the same Eclipse window. It provides some general functions, and all the rest is delegated to the so-called domain plugins. Each domain plugin makes required and optional contributions towards the framework, the required ones involve model representation, the optional ones generally involve visual enrichments (outline icons, coloring) or complex model manipulations (derived properties). The framework also contain a default implementation for such a domain plugin, and language engineers should use that instead of creating one on their own. The default implementation is tied to the Viatra2 framework, both the logical and the diagram models are stored in its model space. This default plugin implementation also contains a GEF-based graphical editor, which is both extensible and changeable. The basic appearance of nodes and edges is rather simple (rectangles and undecorated arrows), but these view classes can easily be replaced by any custom figure, yet making custom figures requires Java coding. 3.4 Example: Petri Net editor In the previous sections the goals, the ideas, the architecture and certain implementation details of our DSM framework were shown. It was pointed out a few time, that the language engineer has very little work to do, and he can make a working domain specific editor without coding at all. This section describes that design process, through an example, namely the domain of Petri nets. This example is carried on in section 5.1, where the construction of a domain simulator is shown. 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 expert of the given domain working on the project. Most probably you are not designing the editor for fun, rather you want to use it to increase the productivity of your developers. Therefore the usability and correctness of a domain specific

64 3.4. EXAMPLE: PETRI NET EDITOR 63 editor and code generator is an essential point. If the editor is difficult to use, its model structure is incoherent or 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 positive approval. Therefore an expert with a good understanding and deep knowledge of the domain is indispensable. Step 2 Decide what do you want! Our DSM framework offers a wide range of possibilities from a simple tree editor up to fully customizable graphical model editing. We must choose from these possibilities, which is the one, which covers all our requirements. If we plan to use the editor only for modeling and graphical display (eg. only for documentation), the default implementation classes are sufficient for us. However if the graphical representation requires 3D rendering, we need to forget the built-in classes and provide our own implementation of the graphical editor. In case of our example Petri net editor, we want our editor to look familiar for users who have experience with other Petri net tools, so we decide to have custom graphical elements (using a little circle for Petri net places instead of builtin rectangular boxes). We will still use the built-in GEF-based graphical editor, we will only replace the standards boxes-and-arrows visualization. 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. This task should be carried out by the domain experts, since it is them, who fully understand the structure of the given domain. When designing the domain metamodel, we have quite a bit of freedom, the only thing we need to take care of is to use only the concepts defined by the core domain metamodel. Therefore we must build up such a Petri net metamodel, where all entities are either nodes, edges or properties. Our core domain metamodel can be seen on figure 3.3, and the Petri net domain metamodel, which we created is presented on figure 3.7. Step 4 Design the required diagrams! Now that the structure of our domain is defined, we could already use the treestructured 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 may have numerous diagram metamodels, but in case of Petri net, we will only have one.

65 3.4. EXAMPLE: PETRI NET EDITOR 64 Petri Net domain PNDiagram Token petrinets PetriNet placefigures PetriNetFigure transitionfigures tokens Place places OutArc InArc transitions Transition PlaceFigure outarcs TransitionFigure capacity weight weight outarcs inarcs inarcs Capacity (property) Weight (property) OutArcFigure InArcFigure Figure 3.7. Step 3-4: Petri net domain and diagram metamodels To design our Petri net diagram, we have to look back to figure 3.5, which shows our so-called core diagram metamodel. Just like the core domain metamodel in step 3, that describes the basic concepts, which may be used to build custom diagram metamodels. Figure 3.7 shows our Petri net diagram metamodel. By comparing it to figure 3.7 one may notice the similarities. Generally a diagram metamodel has a very similar structure to the domain metamodel itself, simply because of the fact, that on diagrams we would like to see the same hierarchy than in the model. The only difference seen is the lack of Tokens on the diagram metamodel. The reason is that in our case the token count for each place is shown as a single number, therefore we do not want to represent each individual token with a separate graphical element. Step 5 Implement custom graphical elements! Arriving at step 5, we already have our domain metamodel and diagram metamodel, describing both the structure of our domain and the various graphical representations we plan to provide. Up to this point, we needed nor to write any code, we just designed metamodels inside the Viatra2 framework. If a language engineer decides to stop here, and he does not want to do any Java coding, he has the option to use our default implementation for the views and the graphical editor. That would result in a user interface shown on figure 3.8. All nodes are represented as rectangular boxes, 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 he decides to create custom graphics. First, he designs little icons, that will be used in the tree and on the palette. That is not difficult job to do, any application

66 3.4. EXAMPLE: PETRI NET EDITOR 65 Figure 3.8. Step 5: Petri net editor without custom graphical elements Figure 3.9. Step 6: Petri net editor with custom graphical elements

67 3.4. EXAMPLE: PETRI NET EDITOR 66 may be used, which can save images in a format understood by Eclipse SWT (that can be PNG, GIF, BMP and many others). The second thing to do is creating a custom graphical editor, where model elements are not represented as boxes, rather something more domain specific. In case of Petri nets, we want little circles for places, where the number of tokens in that place is written inside the circle, and for transition we want small filled black rectangles. That requires us to implement these custom figures as Draw2D-based Java classes. There is no place here to discuss Draw2D implementation details, but to have an example of the effort needed, the place and transition figures shown on figure 3.9 require about lines of Java code to implement. Step 6 Design domain simulation! Domain specific simulations will be discussed in section 5.1. Step 7 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. We can simulate them interactively, and optionally we may also add code generation or model checking features. The entire design process is based on declarative descriptions (metamodels, graph transformation rules), and the only coding-intensive part is the creation of domain specific figures.

68 Simulation and transformation of domain-specific languages Dávid Vágó Chapter 4 ViatraDSM simulation module I have mentioned in the previous chapters, that many of the existing DSM tools lack the support for simulation. There is generally a programming interface (eg. a set of Java interfaces for Eclipse/GMF or C# classes for Microsoft DSL Tools) which can be used to access the models from an external program, but there is no intended support for model semantics. However, I believe that model simulation is an important requirement for any modeling tool. When a designer builds a model, (s)he should have some kind of feedback, which shows how the software generated from this model would work. It is rather difficult to design a dynamic system using only snapshots, without any information about actual state changes. Just like in traditional software development, where continuous debugging and unit testing is an essential part of the process, a domain-specific model should also provide feedback about its own behavior to the developer. In this section the background of the ViatraDSM simulation module will be described, its ideas and certain implementation details, and in the next chapter, some examples will be shown to demonstrate its capabilities and ease-of-use. 4.1 Goals My research goal for the last semester was to develop a simulation module for the ViatraDSM framework, which would allow dynamic behavior to be described using graph transformation rules and abstract state machines. These two concepts form the key components of the transformation engine of Viatra2, and they are both considered to be declarative languages. My primary goal was to keep the simulation support as declarative as possible, i.e. minimize the amount of actual source code the simulation designer has to write. 67

69 4.1. GOALS 68 Declarative model semantics Designing the various simulation scenarios for a domain-specific language is the responsibility of the language engineer. That person has a broad knowledge about the target application domain (eg. Petri nets for our example of the next section), but may have limited knowledge about various programming languages. Tools, which only provide a programming interface will require the domain expert to implement model semantics using a programming language (Java and C# in general), thus forcing him/her onto a territory (s)he is not confident in. This could result in simulations being incorrect, since the domain expert has to express his ideas using a tool (s)he does not know well, so his/her chance of committing a mistake increases. In this regard, declarative approaches are better than traditional programming languages, because a declarative description is easier to verify and also to implement. For example, a simulation step expressed in a imperative form would consist of model manipulation commands, which should be executed in the given order to achieve the result. However, a declarative description (like a graph transformation rule) would just require to describe the initial and final state of the model, and the actual model manipulation steps are automatically generated. So to facilitate the work of the language engineer, I believe a DSM tool should provide fully declarative means to describe model semantics. The goal of the research was to achieve that, and I cannot say that I arrived at a 100% declarative description, but the most important aspects of the simulation can be given in that way. Interactive execution The second major goal was to introduce interactivity to simulation runs. That means that every time the simulation arrives at a choice point, the user could decide, which of the possible execution paths should be followed. As opposed to the abstract state machines implemented by the Viatra2 transformation engine, traditional programming languages tend to be deterministic, so this interactivity could be compared to actual user input in everyday programming tasks. Interactivity is essential for simulations, since that gives the model designer the possibility to play through all possible paths, and check that the model does what it is intended to do for every possible inputs. The goal of interactivity also included the visual representation of choice points, so that simulation runs can fully be inte-

70 4.2. APPROACHES 69 grated into the ViatraDSM tool. More information about the visual appearance of the simulation module will be given in section Approaches Since ViatraDSM is based on the Viatra2 framework, which already has a powerful transformation engine, it was unquestionable that the simulation module will be based on those transformations. The graph transformation and abstract state machines behind that engine would provide a declarative way of expressing the simulation. The other options was the same as used by many other tools, programmingbased simulation. The ViatraDSM framework already provides a set of Java interfaces, which make domain-specific models visible from the outside and also allow consistent model manipulation. Those interfaces may be used to write external Java plugins, which query and modify the model, thus implement simulation Declarative vs. Java-based simulation Both approaches (declarative and Java-based) has advantages. A declarative approach is more user-friendly, because the language engineer could focus on the problems to solve, and does not need to deal with implementation details of the underlying DSM tool. For example in case of Eclipse/GMF, in order to write simulations, the language engineer has to master both the Java language and the EMF model representation format. In the case of ViatraDSM, the simulation uses graph transformation rules (which has the same level of abstraction as the domain metamodel itself) and abstract state machines (which are not fully declarative, but they represent programs at a higher abstraction level than traditional languages). The disadvantage of the declarative approach is that it narrows the range of possibilities of the language engineer. Graph transformation rules and abstract state machines provide a simple way of expressing simple model manipulations, but they cannot efficiently be used for complex algorithmic computations. If the dynamic behavior of the target domain requires complex calculations (mathematical formulae, advanced string manipulation), the declarative approach may become useless. There are certain additions to the GTASM interpreter of Viatra2, like native Java functions, which could provide a workaround for these problems, but still, we could find cases where GTASM programs simply cannot describe the model manipulations needed by the domain semantics. On the other hand, if simulations are written in

71 4.2. APPROACHES 70 Java using the ViatraDSM modeling API, the possibilities of the language engineer are unlimited. Through the model manipulation interface, any model element of the given domain may be accessed from the Java code, any kind of complex calculations can be performed. My choice was a sort of trade-off between the two approaches. The ViatraDSM simulation module clearly prefers declarative, GTASM-based simulations, but the module also contains few Java interfaces, which may be used to integrate Java simulation classes into the system. GTASM transformations can be used without any coding, but if greater control is needed over the model, custom Java classes can be introduced to encode the simulation steps. It is as flexible as to allow simulation with both declarative and Java-based simulation steps at the same time. A more detailed description will be given about the difference between a simulation and a simulation step in section Debuggable interpreter vs. separate steps The second question about the simulator was how to implement interactivity. The requirement was simple. The simulations have to stop at each choice point, waiting for the input of the user. This question concerns only the declarative simulation steps, since for Java-coded steps, it is completely the responsibility of the simulation designer to provide support for interactivity. In other words, the Java interface, which Java-coded simulations must implement, simply contains a method, which is called to collect possible choice point, and the simulation module does not engage any further in providing interactivity for those (Java-based) steps. However, for declarative, GTASM-based steps, interactivity is entirely the responsibility of the framework. Two approaches was considered, the first could be called the debuggable interpreter, whereas the second I entitled separate steps. The debuggable interpreter approach assumes that the GTASM interpreter in the Viatra2 framework has debugging capabilities, for example its users (in this context users refers not to actual persons, but other software using Viatra2 s services) could set breakpoints, modify the outcome of non-deterministic choices or query matched patterns. Along with this research, the debuggable interpreter was a research project of a fellow colleague and his first results were promising enough to let me believe that interactive simulations could be based on his debuggable interpreter. However as he encountered a few difficult problems, and the interpreter he developed was still not supporting the influencing of non-deterministic choice points, I decided to look for an alternative until his work is completed.

72 4.2. APPROACHES 71 P2 P3 P1 P4 P5 Figure 4.1. Example model semantics The alternative idea was slightly more complicated for the language engineer s point of view, but it could be easily implemented with the existing interpreter. That idea was simply to make the language engineer decide exactly what is a simulation step, and what are the choice points. So instead of creating one large GTASM machine, which simulates the model by itself, the domain engineer is required to cut that large machine into pieces himself along choice points, and create separate machines for each deterministic code block. To illustrate the difference between the two approached, look at figure 4.1. In case of a debugging interpreter, all the language engineers have to do is a large GTASM machine, which implements the entire cycle depicted by this simple flow chart. The debugging support in the interpreter would allow the ViatraDSM framework to stop the execution, when it reaches the decision point, show the possible choices to the user via the user interface, take the user choice, then modify the internal state of the debugger so that it will choose the path given by the user and continue execution until the next break or choice point is reached. This is simple for the language engineer, since all he has to do is a single machine, and the debuggable interpreter would automatically suspend execution, when a choice point is reached. In contrast to this, the other, slightly complicated, idea would require the domain engineer to split the semantics along choice points, and implement the various deterministic sequences as separate machines. In the example shown on the figure above, it would mean that the language engineer would have to create four separate machine, one which executes P1, and returns a set a choice points, a second which executes P2 and P3, a third which executes P4 and a fourth executing P5. Clearly, this approach requires more work from the language engineer, but these separate machines would enable interactive simulation even without debug support in the

73 4.3. OVERVIEW 72 Simulation module ViatraDSM GTASM Interpreter Viatra core Figure 4.2. Simulation module environment interpreter. In this second question, the obvious choice would have been the debuggable interpreter, since the primary goal is to keep the language engineer s job as simple as possible. But difficulties that have arisen with that interpreter forced me to follow the second idea. A simulation based on a debuggable interpreter is clearly the only possible way for future enhancements, but for the time being, language designers have to contend with the other, more complex solution. 4.3 Overview Figure 4.2 shows the position of the simulation module relative to other parts of the ViatraDSM framework. The simulation module is tightly coupled with the ViatraDSM framework itself, but it also has a direct access to the GTASM interpreter of the Viatra2 tool. In the current implementation the arrow, which goes from the simulation engine to the GTASM interpreter should rather be unidirectional, since at present, the GTASM interpreter does not provide any feedback for us, a real bidirectional link would only be present in case of the debuggable interpreter. The simulation module uses the ViatraDSM framework to provide feedback about the possible choice points, both on the user interface and on the programming interface. The GTASM interpreter is used to execute separate, deterministic simulation steps. Section will describe in detail the control and data flow between the various components. On the other hand, figure 4.3 shows the internal structure of the simulation module, and that diagram will be used to introduce its basic concepts.

74 4.3. OVERVIEW 73 ViatraDSM domain Simulation Manager Running simulation Simulation Type Simulation step Figure 4.3. Simulation module architecture Simulation Manager Every ViatraDSM domain has exactly one simulation manager, and it is that component, which is responsible for launching new simulation instances and manage running ones. At present, a simulation manager is tied to a single domain, therefore simulations which affect multiple domains cannot be executed. This limitation is due to the limitations of the ViatraDSM framework itself, and a possible enhancement for the future would be overcoming this limitation. But at present, only simulations affecting a single domain can be handled. Simulation Type Each simulation manager (domain) can handle multiple kinds of simulations. These simulation kinds represent various different model semantics. As it is shown in the next chapter, Petri nets may have different semantics, for example whether place capacities are enforced or discarded. An analogy to multiple simulation kinds in terms of traditional programming could be the debug and release mode execution. The first may contain additional checks, like array indexing, or null pointer references, while the later skips these checks to deliver a better performance. Similarly, we could create two different model semantics for our domain-specific language. One would use GTASM s print() command to display debug information, while the second would only transform the model. At the early stages of development the user could use the first semantics for simulations to get more information about the execution (just like a debug-mode execution), while actual code generation could be based on the second (release-mode) semantics. Each simulation type contains a reference to a domain metamodel element (for example, Place or Transition in case of Petri nets), which is called the simulation target. It means that the simulation can only be run on model elements, which has that target metaelement as their type.

75 4.4. IMPLEMENTATION 74 Simulation Step Every simulation is a sequence of atomic, deterministic sequences, and such a sequence is called a simulation step. Each simulation step may have optional arguments, which govern how the step is executed. In case of Petri nets, a simulation step would be the firing of a transitions, and an argument of this step would be the transition to fire. Running simulation In order to launch a simulation, there are two requirement. First, a simulation type must be chosen from the list of types supported by the simulation manager of the domain, and a target element also has to be selected. That target element must naturally conform to the simulation target property of the chosen simulation type. If both are chosen, a new simulation may be launched. A running simulation has one important property, the set of possible steps, which may be executed from the current state. The running simulations are managed by the simulation manager, we may stop any running simulation using the manager. These are the four basic concepts of the simulation framework, in the next section, implementations of these concepts will be elaborated. A language engineer need not to understand the actual inner structure of the simulation module, all he has to do is to be familiar with these four concepts, the GTASM transformation language and the mapping (see section 4.4.2) which allows choice points to be described in a declarative way. 4.4 Implementation The four concepts described above appear as four Java interfaces in the ViatraDSM framework simulation module. However, I stated in the objectives that my goal is to eliminate all programming requirement for the part of the language engineer. The solution is rather straightforward. The simulation module already contains simple implementations of the aforementioned interfaces. They are suitable for most simulation scenarios, and in case they would not satisfy the language engineer s needs, he may decide to implement the Java interfaces himself, giving him unlimited flexibility and performance Simple implementations Simulation Manager The internal implementation of the simulation manager is nothing special. Since the role of the simulation manager is only to keep track of the registered simulation types and running simulation, the default implementation

76 4.4. IMPLEMENTATION 75 does exactly this. One improvement is that it contains a notification mechanism, whereby outsider components may register themselves at the manager, and they will be notified (via callback methods) of changes in the simulation state. A change could mean a new running simulation, a stopped one or just a change in the possible steps of any running simulation. This notification mechanism is very important in order to increase user satisfaction. It allows the user interface to respond to model changes instantaneously. It means that the model may be changed during a running simulation by the user, and his changes will be reflected immediately in the possible choice points. For example, in case of Petri nets, the user may modify the marking, or even create or delete places and transitions, and the list of choice points would follow model changes in real time. Such a real time feedback for model changes could be compared to the functionality that some advanced IDEs have, on-the-fly code replace at debugging. The majority of traditional programming tools require recompiling the code and restarting the debug process at model (code) changes, but the ViatraDSM simulation module is capable of following model changes without suspending the debug procedure. This is useful when fixing bugs, which appear only at a later stage of the model execution. Imagine the scenario, that a bug appears only after 5-10 minutes of initial calculation. Every time a change is made in the code trying to fix that bug, debugging has to be restarted, and that 5-10 minutes must pass until the program reaches the critical state, and only after that shall the user know if his fixing attempt succeeded or not. With the notification system present in the simulation module, the user does not have to restart debugging after every small modification to the model, but he may continue his work, trying different solutions one by one until he finally succeeds. Simulation Type The simulation type is a rather simple concept, it just stores the target model element type, and the set of possible steps for the simulations. Its implementation is therefore a simple Java class, which stores the required information. Running simulation Internally in the simulation module, each running simulation is represented as a small state machine. After creation, each simulation gets into an initial state (specified by the designer). Every executed step does some change on the model, and may alter the internal state of the simulation. It is important to note that simulation state and model state are two completely different things, they both affect what steps may be executed, but while model state is saved with

77 4.4. IMPLEMENTATION 76 Simulation Started Init Environment initialized Simulating control flow ChooseCtrl ChooseData Simulating data flow Figure 4.4. Simulation as state machine the model itself, simulation state is just a run-time property. One may ask what is the motivation behind this state machine. It is just a temporary solution, it will be deprecated when the debuggable interpreter will be fully operational. It is all about storing some information between simulation steps. When I first envisaged this simulation module using the debuggable interpreter, the concept running simulation was nothing more than a running GTASM machine. Therefore a simulation would have had a state, for example the set of bound ASM variables. But when I changed my approach to the separate steps conception, this simple way of storing simulation state has vanished. In the present simulation architecture, there would be no way of exchanging information between subsequent steps other than using the model space. But that would be very uncomfortable for the language engineer, since he would be required to manage these state variables from the GTASM transformations. So the problem was given. There must be a way to save simulation state across distinct steps. I could have chosen to completely ignore the problem, and leave the simulations stateless. That would have resulted in each simulation step being active at every model state, which might not be convenient for certain usages. Figure 4.4 describes a system, where the control and data flow are meant to be simulated separately, and most importantly, before any simulation steps occur, some initial properties of the model must be set (the thinner blue arrows refer to actual model transformation steps). In a stateless simulation environment, it would be possible to execute some of the model transformation part of the simulation (thin

78 4.4. IMPLEMENTATION 77 blue arrows) before setting up the environment and choosing whether we are examining control or data flow. That would result in both inconsistent models and invalid simulation results, which we want to avoid as much as possible. Therefore a stateless simulation is a simple approach, and is suitable for example in case of Petri nets, but in general it is not enough to express domain semantics precisely. Simulation step The most important part of the default implementation is the simulation step, since the most challenging task was to translate a simulation step, which is essentially a series of commands, to a declarative description. The GTASMbased transformation engine was a great help for the actual model manipulation, its graph transformation rules and abstract state machines represent a language, which is declarative enough to let domain engineers express their ideas with simplicity, but precisely. However, one difficult point in the research was how to handle choice points in a declarative way. Using a debuggable interpreter would not pose such questions, since in that case, the interpreter would clearly present the possible choices, and the selection of the user could simply be returned to the debugger. But since the debuggable interpreter is still a future goal, a different solution had to be found. There were basically two approaches I experimented with, the first called next choice points, while the name of the other could be enablement test. The common between the two is that they both serve to enable users choose between different execution paths. The difference is, which step is responsible for finding the possible choices. Before going any further, the exact meaning of the term choice point will be defined. Model semantics are the rules that govern model changes during the execution. One simulation step is one of these rules, denoting an atomic, deterministic list of model manipulation commands. But a simulation step is only a rule, not an application of a rule, it needs (optionally) arguments to actually know what to modify. For example, in the domain of Petri nets, firing a transition would be a simulation step. But this step cannot be translated into an exact model manipulation without knowing which transition to fire. So a simulation step is a kind of template for altering the model, which becomes a meaningful set of commands only when all its arguments are substituted with actual values. The term choice point refers to the possible set of (simulation step, arguments) pairs, which may be executed from the actual model state. The semantics of many domains can be expressed using only one single step. In

79 4.4. IMPLEMENTATION 78 case of Petri nets, that would be transition firing, for state machines, that would be one state transition. An example for a domain with multiple simulation steps could be the model of a complex system made up of heterogeneous components. Each component is modeled using different abstractions (state machines, data flow networks, etc.) and each component has different semantics, so the entirety of the system needs multiple steps, at least one for simulating every components. This idea is essentially multi-domain simulation, which is not yet supported. So why bother with multiple steps, if their main usage scenario is not supported by the underlying ViatraDSM tool. Well, multi-domain support is definitely one of the major future goals for the ViatraDSM framework (both modeling-wise and simulation-wise), therefore I decided to support multiple steps even in this early, single domain, version. First, multiple steps may be useful also for single-domain simulations, to simplify complex steps by decomposing them into a series of simpler sub-steps. Second, future enhancement (multi-domain support) would require multiple steps anyway, so it is easier to include its support at this stage, while the simulation module has a simple structure, than later, when much of the code would have to be changed. After this short by-pass about the importance of multiple steps, let s get back to the question of choice points. The declarative handling of choice point can be carried out in two different ways. The next choice point approach assumes that a simulation step is responsible for finding the possible paths, which may follow its execution. In that approach each simulation step would consist of some model manipulation and after that, it would check the model for possible follow-ups. The great disadvantage of this approach is that it requires each simulation step to know about the entire model semantics. Since each simulation step would need to recognize every other, the same choice point recognition code would be duplicated in every step giving a lot of extra work for the simulation designer. Looking back at figure 4.1, this approach would require P1 to check the model after its execution, and return the three possible steps (along with all possible arguments for them) which may be executed after itself. The other idea, enablement test, would do right the opposite. Instead of steps determining the possible follow-ups, each step should only decide whether itself is applicable at the current model state. Using the simple example on figure 4.1, this approach would mean, that P1 knows nothing about P2, P4 and P5, rather each of P2, P4 and P5 would be able to determine about itself, whether it is applicable or not, and if applicable, what are the possible values of the arguments. This approach requires much less effort from the simulation designer, since he only has to write a kind of enablement test for each step. The drawback of this approach is that it requires much more time to gather choice points. In the other approach,

80 4.4. IMPLEMENTATION 79 we just have to run one check routine, which gathers all possible choice points, but in this second case, the simulation module has to run the check routine for each of the steps, and each check routine is likely to browse through the entire model, so if there are N steps in the simulation, the model gets examined N times. This time increase is generally negligible if the checks have to be evaluated only once every step (that is the case for ordinary simulation runs), but with the advanced real-time model change listening (which makes it possible to react to model changes during a simulation run), these checks have to be evaluated after every model manipulation by the user. For small number of simple steps, that is still acceptable, but in a domain with complex semantics it may unbearably slow down model editing during simulations. Even considering its weak performance, the choice was this later, enableness test, approach. It is much simpler to implement, therefore it facilitates the domain engineer s job (and simple simulation designing was the main goal). Besides, the Viatra2 team already prepares enhancements to the graph pattern matcher (such as incremental matching), which would speed up GTASM execution for slowly changing models (simulation is good example). These enhancements would diminish the performance penalty, therefore beside simplicity that gives another vote for the enablement test approach. After all this discussion about different approaches and requirement, it s time to introduce the default simulation step implementation, since that is the key component of the simulation module, that is what makes it possible to describe choice points in a declarative way. The implementation requires two GTASM machines, the first called the check machine, the second called the execution machine. The execution machine is simply a GTASM machine, which takes a number of input arguments and it performs a well-defined model manipulation operation. The machine itself corresponds to the concept simulation step and its arguments are the simulation arguments. For example the execution machine for the Petri net transition firing step would have one argument, TransitionToFire. Executing this GTASM machine with TransitionToFire being equal to fork would fire the transition named fork in the model. But how does the user know which are the possible values for the arguments of the execution machine? That is where the check machine enters the scene. As its name suggests, its role is to check the model state and return all possible choice points. Actually, the check machine is an ordinary GTASM machine, but beside input arguments, it also has output arguments, and each output argument corresponds the an input argument

81 4.4. IMPLEMENTATION 80 of the execution machine (in reality things are a bit more complicated, see next section (4.4.2) for detailed description about how the results of the check machine are mapped to the inputs of the execution machine). Designer tasks After the discussion about the implementation details of the simulation module, the most important question, the question of usability, will be elaborated. And by usability, I mean how simple it is for the language engineer to describe the dynamic semantics of the designed domain. As a first step, he should decide whether the default implementations of simulation concepts are sufficient to describe the semantics precisely. If the answer is no, the designer can make his own simulation and simulation step implementations in Java, but in general the default implementations are sufficient. The default implementation contains a simple state machine for simulations, and a simulation step solution, which uses two GTASM machines to gather choice points and modify the model. If the designer is satisfied by that, he should first create a state machine, which serves as first-level filter for step enablement (see section for details). Each state in that state machine corresponds to a state of the running simulation, and for each separate simulation step, we can both decide in what states is it active, and what is the resulting state after its execution. Generally, this state machine part of the simulation is omitted, in simple domains (like our example of Petri nets) every step is active at every time. The third task of the simulation designer is to create the individual steps. For each step, he has to develop two GTASM machines, one, which actually modifies the model (optionally based on some arguments), and a second, which examines the model, and returns the possible combination of arguments for the first machine. Finally, for every step, the designer has to establish a mapping between the output arguments of the check machine and the input arguments of the execution machine. The next part of this thesis describes this argument mapping in detail, whereas section 5.1 will guide through the entire simulation development process using the domain of Petri nets as an example.

82 4.4. IMPLEMENTATION Declarative parameter mapping The previous section described the default implementation of a simulation step, which requires two GTASM machines, the check machine gathering the possible choices for the given step, while the execution machine actually executing one of the choices. It was also said, that the check machine has some output arguments, which should be mapped to certain input arguments of the execution machine. This mapping will be elaborated in this section, giving the possible mapping types, whereas section 5.1 will show an actual example of such a mapping. Before going into mapping details, a few words must be said about the requirements this mapping poses towards check and execution machines. GTASM machines support various types of arguments, but in order to make the mapping simpler, the simulator supports only String arguments. All other native types of the GTASM interpreter (boolean, integer, double) can easily be converted to strings, and for model elements, the use of their fully qualified names is advised. This constraint means that the simulation designer has to design his machines so that they accept (and return) strings. So an execution machine, whose job is to fire a Petri net transition, would get the transition by its fully qualified name, and the other way around, the check machine, whose job is to gather the fireable transitions will return a list of fully qualified names. Talking about lists, since the GTASM interpreter does not support collections as arguments, the decision was made that all lists should be represented as comma separated strings. These two assumptions (everything is represented as strings and lists are comma separated strings) are just small technical details, which do not decrease the expressiveness of the machines, but make the implementation simpler and faster. The mapping itself is defined as a set of mapping rules, each rule having four properties: check machine argument name, execution machine argument name, optional string value, mapping rule type. The first two of these properties refer to arguments of the GTASM machines, the third property may be a fixed string value (see the FixedValue mapping type), and the mapping type is one of the ten following types: CopyObject, FixedValue, CopyTarget, InitialState, EndState, NonEmpty, ObjectChoice, ElementChoice, ObjectChoiceHideSingle, ElementChoiceHideSingle. Here is the semantics of all of these mapping types, with a short example for each of them. CopyObject Copies an output argument of the check machine into an input argument of the execution machine. This mapping type is special in terms of that

83 4.4. IMPLEMENTATION 82 it is capable of transferring non-string values, since the value copied is not interpreted by the simulator. Example: CopyObject( CheckDistance, ExecuteDistance ). This rule would copy the value from the output variable of the check machine called CheckDistance into the input variable ExecuteDistance of the execution machine. It can be used when the check machine calculates some kind of information, which is required for the model manipulation, but is independent of the values of other arguments. FixedValue Copies a fixed value into an input argument of either the check or the execution machine. Example: FixedValue( Debug, CheckMode, ExecuteMode ). This rule would copy the string "Debug" into the input variable CheckMode of the check machine and into the input variable ExecuteMode of the execution machine. Either of the variable names may be empty, in that case the fixed value is used only in one of the machines. As this example demonstrates, this can be used to differentiate between debug and release mode executions. Earlier I mentioned, that two different semantics require different simulation types, this mapping rule makes it possible to reuse the same machines in multiple simulation types. CopyTarget Copies the target of the simulation into an input argument of either the check or the execution machine. Example: CopyTarget( PetriNetFQN, none). This rule would copy the fully qualified name of the simulation target into the input variable PetriNetFQN of the check machine. The target element of the simulation is the element on which the simulation was executed, so this rule should be used (like in our example) to differentiate between parallel simulations running on different Petri nets. InitialState Copies the initial simulation state into an input argument of either the check or the execution machine. Example: InitialState( SimState, Sim- State ). This rule copies the actual state of the simulation into the input argument SimState of both machines. This rule is generally used together with the EndState rule to let the execution machine decide, which will be the final state of the simulation after its execution. In the basic implementation of the simulation, final state is determined only by the initial state and the step chosen, these two rules makes this idea more flexible, allowing the final state to be determined at run-time. EndState Acquires the final state of the simulation from an output argument of either the check or the execution machine. Example: EndState(none, Sim- FinalState ). This rule would read the output argument SimFinalState of the execution machine, and if it is a valid state name, the simulation would

84 4.4. IMPLEMENTATION 83 move into that state after the execution of the step. If both arguments of the EndState rule are valid, it is the output argument of the execution machine, which will be taken into account. If the specified output variable of the machine does not contain a valid simulation state, a warning is emitted and the simulation state changes according to the state machine rules. NonEmpty Marks an output variable of the check machine, which must be nonempty in order the step to be enabled. More information about step enablement can be found below. Example: NonEmpty( ValidState ). This rule would check the output argument "ValidState" of the check machine, and the step would only be enabled, if the value of that argument is not empty. An argument is empty, if it is unbound after the execution of the machine, or its value is equal to null or the empty string. This rule can be used for steps, which contain intentional nondeterminism, for example a step, which fires a random enabled transition of a Petri net. We only want to enable this step if there are actually fireable transitions, but we cannot use the...choice... mapping types, because we do not want feedback from the user. ObjectChoice Shows that the value of an input argument of the execution machine must be one element from an output argument of the check machine. Example: ObjectChoice( NumberList, Number ). This rule means that the output argument NumberList of the check machine is interpreted as a comma separated list of strings, and the user has to choose exactly one element of that list, and the choice would be put into the Number input argument of the execution machine. For example, if the value of the output argument is "1,2,3,4,5", the user will have to choose between the five possible numbers, and the input argument of the execution machine will be one of those five values. ObjectChoiceHideSingle This is a variation of the ObjectChoice mapping type. If the value of the specified output argument of the check machine contains one single element (no commas in the value), the ObjectChoice mapping requires the user to confirm that one value, whereas the ObjectChoiceHideSingle in the same case copies that value automatically to the specified input argument (of the execution machine). Mainly the difference between the two mapping type is visible only on the user interface, section 5.1 will show the actual difference with screen shots. ElementChoice This mapping type is very similar to the ObjectChoice one, the difference is between the processing of the elements of the choice list. ObjectChoice treats the elements of the comma separated string as ordinary

85 4.4. IMPLEMENTATION 84 strings, it does not try to interpret them, just displays the strings on the user interface. On the contrary, ElementChoice interprets the elements of the comma separated string as fully qualified model element names, and tries to find the actual DSM model elements, which correspond to those names. The difference is again in the visual representation of choice point, see the examples section (5.1) for details. ElementChoiceHideSingle This is a variation of the ElementChoice mapping type, and just like the ObjectChoiceHideSingle type, the difference is that this type automatically substitutes the value if there is only one choice, whereas the ElementChoice type also need a user confirmation for a single choice. The list above is not a formal definition for the mapping types, but it is detailed enough to demonstrate their capabilities, their usage and differences between the various choice mapping types will be presented in the examples section. These ten mapping types certainly do not cover all possible scenarios, but they are flexible enough to be used for the majority of simulations. For example, one scenario could be given, which is not covered by the actual implementation, but would be useful in some cases. That is the case of dependent argument. For example, if the simulation step needs a country and a city name, one cannot express the dependency between countries and cities (ie. a given city may only be selected along with a given country). In the current implementation this scenario would be handled with two ObjectChoice rules, one for the country and one for the city. That would allow invalid combinations (eg. Hungary - New York), since each of the two rules would be evaluated independently. There is a workaround for this problem, namely to use one single variable, which stores both country and city name, but that would require some more processing in the GTASM machines, thus more effort from the language engineer. I agree that this mapping have certain weaknesses, as a future work, I will examine how this could be improved, to allow more complex structures with keeping the simplicity of use it already possesses Simulation step enablement Along with the NonEmpty mapping type, the term enablement of steps was mentioned without actually describing what that means. What exactly defines whether a step is enabled or not? It is calculated using very simple rules, but combining all the rules, it may be difficult to understand at first glance. The first step in calculating the enablement of a step is checking the simulation state. When I was writing about simulations being small state machines, I mentioned that for every step, one may define a set of states, where that step is enabled. This is the rule

86 4.4. IMPLEMENTATION 85 which is evaluated first for enablement calculations, so for each step, the simulation manager first checks whether that step is included in the list of enabled steps for the actual simulation state. If not, that step will definitely be disabled, if it is included, it may proceed to stage two. Now, for every step, which is allowed by the underlying state machine, the simulation manager executes the check machine, and examines the return values of output arguments. Every output argument, whose name appears in at least one NonEmpty, ObjectChoice, ObjectChoiceHideSingle, ElementChoice or ElementChoiceHideSingle rule, must have a non-empty value (see the description of the NonEmpty mapping type for details). That is the only requirement for enablement, so if every argument, which is referenced by a choice or NonEmpty rule, contains at least one element, the step will be enabled. The possible argument combinations for the execution machine is simple determined by the cross product of the separate choices. So if we have three choice rules, the first having three options, the second having seven option an the last one having two options, the execution machine of that step will have = 42 different valid invocations Simulation use-cases In section 4.4.1, a detailed description was given about the implementation difficulties during the development of the simulation module and various possible solutions. Together with section 4.4.2, the entirety of the simulation module has been described. Until now the emphasis was on the structure of the different elements, and there was little about how the different elements of the simulation module (simulation manager, running simulations, simulation steps) interact with each other. On the following pages I try to compensate for that deficiency. Two major use cases of the simulator, starting a new simulation and executing a step, will be discussed in terms of interactivity between components. Starting a new simulation Figure 4.5 shows the interaction between various components of the simulation module when a new simulation is created. 1. The user chooses a simulation type and a target element (generally by selecting a simulation type from the context menu of the target element), and passes these two pieces of information to the simulation manager, asking it the create a new simulation.

87 4.4. IMPLEMENTATION 86 User Simulation Manager Simulation Type Simulation create(type, Target) findtype(type) newsimulation(target) <<create>>(target) return(simulation) updatesteps() Enabled steps notification Figure 4.5. Sequence of new simulation creation 2. The simulation manager executes some internal checks (that is not shown on the sequence diagram above for sake of simplicity) which assures that two different simulation instances would not be executed on the same part of the model. After this check, it searches its internal store for registered simulation types (the domain plugins must register each simulation type at the initialization stage of the ViatraDSM framework). 3. If the simulation manager finds the given type, it uses it as a factory to instantiate a running simulation. After the new simulation has been created and initialized, the simulation manager invokes a method called updatesteps(), thus assuring itself that the enablement of the simulation steps would accurately reflect the model state. A detailed description of the updatesteps() method is given in the next scenario. Executing a simulation step Figure 4.6 describes what is actually happening inside the simulation module when the user executes a simulation step. 1. As a first step, the user (in this context, user is for example the outline view of the ViatraDSM framework) queries the running simulations from the simulation manager. The simulation manager can already filter the returned list based on a given model element. If we use this filter, we will only get the running simulations, which are affected by the given model element. A running simulation is affected by a model element, if the element is either its target, or

88 4.4. IMPLEMENTATION 87 User Simulation Manager Simulation Simulation Step GTASM Interpreter getrunningsimulations() Simulations getactivesteps() Active Steps executestep(arguments) runmachine() updatesteps() update() runmachine() Output arguments processmappings() enablement, arguments Enabled steps notification Figure 4.6. Sequence of simulation step execution is one of the possible choices in a ElementChoice mapping rule. This filtering makes it possible that when the user right-clicks on the element representing the Petri net, he will see all fireable transition (since the petri net element is affected by each step), whereas when he right-clicks on an actual transition, he will only see the possible simulation steps concerning that transition. 2. The user iterates through the running simulations returned by the manager, and for each simulation, it queries the active steps, and also the possible argument combinations (eg. for Petri nets, this call would return that the Fire step is active, and it would also return the list of fireable transitions). 3. After the user has chosen which step (and with what arguments) is to be executed, that step is run. Internally the simulation step converts the given arguments to strings, and runs the execution machine using the GTASM interpreter. The sequence diagram does not show, but the interpreter may return output arguments (eg. final simulation state for EndState rules) to the step. Now the model manipulation is complete, but since the model has changed, we have to update all steps of all running simulations to synchronize the enablement of steps with the new model state. 4. This synchronization is done using the updatesteps() method, which simple

89 4.5. SUMMARY 88 delegates this call to the separate steps. For an update, each steps executes its check machine, and processes the mapping rules. 5. The method processmappings() has two roles. First, it must determine the enablement of the step (as described in section 4.4.3). Additionally, it also gathers the possible argument combinations. That is done by examining each...choice... mapping rule and parsing the output argument corresponding to that rule (simply split the value of the argument along commas). The cross product of possibilities for each individual argument will be the set of possible argument combinations. 6. Each step returns its enablement state and possible argument combinations to the simulation instance (naturally, argument combinations are not needed for disabled steps). The simulation object processes this information, and issues the appropriate notifications. These notification permit the user interface to reflect simulation state in real time, thus providing a feedback to the actual (human) user about the effects of the simulation. The description above is only valid for the default implementation of the simulation concepts. Since the simulator is extensible, the simulation designer is allowed to make his own Java implementation for both the simulation class (thus replacing the built-in state machine with some more advanced construct) and simulation step class, giving him the opportunity to get rid of the limitations of the GTASM interpreter or the argument mapping model. Therefore any custom-made Java class can replace the Simulation and Simulation Step objects in the sequence diagram above, this diagram only describes the declarative case, where the simulation designer does not write Java code himself, just designs two GTASM machines and establishes an argument mapping between the two. 4.5 Summary The simulation module of the ViatraDSM framework combines flexibility and easeof-use. This module has two different kinds of users, language engineers and end users, and the need of both are satisfied by its capabilities. A language engineer, expert in a given domain, prefers a simple way of expressing the semantics of his domain. He would like to design simulations, he has a vast knowledge of the target domain, and he would like to work at a high abstraction level in order to express his ideas precisely. The simulation module supports his work by providing declarative, yet expressive means to describe domain semantics. One element of this description language is the transformation engine of the Viatra2 framework, based on graph

90 4.6. FUTURE ENHANCEMENTS 89 patterns and abstract state machines. My addition to the GTASM language is a set of general simulation concepts and a basic implementation for these concepts, which combines the power of the GTASM interpreter with a declarative mapping description. The GTASM language alone permits only to define model transformations, but it does not provide any option for user interactivity (user-defined evaluation of nondeterministic control structures). The mapping concepts (and the implementation of those concepts) allows language engineers to express domain semantics as a sequence of atomic steps, and let the end user (who runs the simulation on an arbitrary model) choose at each nondeterministic choice point, which of the possible execution paths will be followed. Combining GTASM and that mapping gives an expressive tool to describe model semantics with interactivity support, but if the simulation designer is not satisfied by its capabilities or performance, he may also decide to override the built-in structures and make his own simulation step implementation in Java. Even, it is possible to create simulations with contain both declarative and Java-based steps. This allows domain engineer to choose between flexibility (Java) or a little bit limited, but declarative approach (GTASM + mapping), requiring no coding at all from his part. For the end user s point of view, it does not matter, whether designing simulations is an easy or difficult job. His primary concern is to run simulations interactively, and be able to influence the execution. As it is stated above, the simulation module is capable of this, but it is capable of even more. Using a real-time notification mechanism, the simulation module continuously monitors the model, and at every change, it reevaluates step enablement constraints. This functionality allows the end user to modify the model (even structurally) during ongoing simulation runs, and his modifications will immediately be reflected in the simulation. This is analogous to modifying the source code of a program during debugging thus that the modifications are effective without having to restart the debug process. Also, a simulation step is just as undoable as any other kind of model manipulation, so it is easy to test multiple execution paths starting from the same point. This undo functionality, Step back, is not an option I see often in the debuggers of traditional programming languages. 4.6 Future enhancements Even though the simulation module gives a flexible yet simple way to describe interactive model simulations, it also has a few weak points. One of them is the fact, that

91 4.6. FUTURE ENHANCEMENTS 90 instead of creating one large GTASM machine, which describes the entire domain semantics, the language engineer has to create separate machines for every deterministic step. Hopefully, the debug support in the GTASM interpreter (see section 4.2.2) will soon be fully operational, and that would solve this problem, since the debuggable interpreter would automatically slice complex GTASM machines along choice points. Another weakness of the default step implementation may be its bad performance. In order to follow model changes real-time, each check machine of every running simulation must be reevaluated at model changes. The time required for that is not noticeable in simple domains, such as Petri nets or state machines, but for complex systems, the performance penalty could easily become painful. As an answer, the user could disable that feature, but that would mean that the simulator loses its ability to track model changes during simulations. The promised incremental matching in the GTASM interpreter could solve this problem, or alternatively, the simulator could analyze steps in order to determine, if a given step should be reevaluated for a specific model change. More details about possible future work will be described in chapter 6.

92 Simulation and transformation of domain-specific languages Dávid Vágó Chapter 5 Simulation examples The last chapter described the simulation module of the ViatraDSM framework in detail. I believe the best way to understand those concepts is by the means of a few examples. The example shown here will be the domain of Petri nets, simple enough to introduce the basic concepts of simulation in practice. Since it is a simple domain, it will not cover all tiny details about the simulation module, but it is sufficiently complex to demonstrate the most important features, and the easiness of describing domain semantics within the ViatraDSM framework. 5.1 Simple example: Petri nets Figure 5.1 shows the structure of Petri nets as represented within the ViatraDSM framework, and a sample instance of that domain metamodel. The nodes are PetriNet, Place, Transition and Token, the edges are InArc and OutArc. Places have one property, their capacity, whereas each arc may be assigned a weight. The goal in this section is to use the simulation module in order to construct a simulator for this domain. Simulation steps In order to simplify things, the first example will disregard place capacities and arc weights. This allows for the model manipulation steps to be described in a very simple way using just a few graph transformation rules and basic ASM constructs. The example simulation will have two steps, both will fire a transition. The first version lets the user choose which transition to fire, while the second will fire a random (but enabled) transition. 91

93 5.1. SIMPLE EXAMPLE: PETRI NETS 92 pn0 :PetriNet Petri Net domain petrinets p0 : Place token0 : Token Token PetriNet p0_t0 : OutArc t1_p0 : InArc tokens Place places OutArc InArc transitions Transition t0: Transition t1 : Transition capacity weight weight t0_p1 : InArc p1_t1 : OutArc Capacity (property) Weight (property) p1: Place Figure 5.1. Domain metamodel and example model instance of Petri nets Viatra2 GTASM machines Two simulation steps mean altogether four GTASM machines, since both steps need a check machine and an execution machine. In our case, we can spare one of them. The enablement of both steps pose the same constraint towards the model, namely there must be at least one fireable transition. Section describes in detail how to use the NonEmpty mapping type to allow this simplification. Advised design pattern However we will have four machines at the end. I believe that the transformation code is more perspicuous, if all patterns, graph transformation rules and abstract state machine rules concerning a given domain are collected in a separate, library-like machine. This is the same concept as that of programming libraries (XXX.dll or libxxx.so depending on your favorite platform), it allows code for the same domain to be kept together, and reduces the chance of overwhelming code duplication. Therefore there will be four machines, PetriNetLibrary will contain all patterns and rules, and the three separate machines will just make calls into this library. The three individual machines are required only because of the limitation of the GTASM interpreter, which allows the execution of entire machines only, an ASM rule cannot be executed by itself. Graph patterns and rules Altogether three patterns and two graph transformation rules will be used for the simulation. Pattern istransitionfireable will match

94 5.1. SIMPLE EXAMPLE: PETRI NETS 93 Pattern istransitionfireable Negative pattern sourceplacewithouttoken X : PetriNet Y :Transition Negative pattern placetoken Z : Place transitions OutArc tokens Y :Transition Z : Place Token Pattern sourceplace Pattern targetplace X : PetriNet places Z : Place X : PetriNet places Z : Place transitions OutArc transitions InArc Y :Transition Y :Transition Figure 5.2. Three patterns for Petri net simulation against fireable transitions of a given Petri net. Patterns sourceplace and target- Place are used to find the predecessor and successor places for a given transition. Finally the two graph transformation rules are addtoken and removetoken, they respectively add and remove one token from a given Petri net place. Figure 5.2 shows the three mentioned graph patterns. Even without deep understanding of graph transformation, sourceplace (bottom, left) and targetplace (bottom, right) do not need further explanation. The istransitionfireable pattern uses the negative pattern structure of the Viatra2 pattern matcher to find enabled transition. The innermost negative pattern matches every place, which has at least one token. Therefore its negation is a place without any tokens, therefore the outermost negative pattern matches a transition, which has at least one place without tokens. As a consequence, its opposite is a transition, which does not have a place without tokens, in other word, a transition, whose all source places contain at least one token. That is the definition of a fireable transition (this time we are neglecting place capacities and arc weights), so the pattern is expected to work correctly. Figure 5.3 shows the removetoken graph transformation rule. Its left hand side is a place with a token, the the right hand side is the place alone, thus this rule,

95 5.1. SIMPLE EXAMPLE: PETRI NETS 94 Graph transformation rule (removetoken ) LHS (source) pattern RHS (target) pattern Token Place tokens Place Figure 5.3. removetoken graph transformation rule when applied to a place, will remove one token from that place. There is no figure representing the addtoken transformation rule, but it is essentially the same as removetoken with the left and right hand sides switched. After the patterns and GT rules, the abstract state machines used will be presented. Three ASM rules must be designed in order to simulate Petri nets. The first ASM rule, entitled getfireabletransition will receive the fully qualified name of a Petri net as an input, and it will return the list of fireable transitions (as a large string, containing the names of fireable transitions separated by commas, see for argument formatting requirements of the simulation module). This simple code below first finds the actual Petri net model element referenced by the PetriNetFQN input argument, then using a forall construct, enumerates all matches of the istransitionfireable pattern, and collects the fully qualified names of the transitions in a temporary variable (that cannot be an ordinary ASM variable due to the semantics of the forall construct, so a temporary entity is used, which is deleted afterwards). At the end, this list is copied to the output argument TransitionList. rule getfireabletransitions (in PetriNetFQN, out TransitionList ) = seq { let PetriNet = ref ( PetriNetFQN ) in seq { new ( entity ( Temp )); forall Transition with find istransitionfireable ( PetriNet, Transition ) do seq { if ( value ( Temp ) == "") setvalue ( Temp, fqn ( Transition ));

96 5.1. SIMPLE EXAMPLE: PETRI NETS 95 } } else setvalue (Temp, value ( Temp ) + "," + fqn ( Transition )); } update TransitionList = value ( Temp ); delete ( Temp ); The second ASM rule written fires one given transition. It will receive the fully qualified name of the transition to fire, and it will remove one token from each source place, and add one to each target. We use the patterns sourceplace and targetplace (figure 5.2) in a forall loop to enlist all source/target places, and we will invoke the removetoken and addtoken GT rules (figure 5.3 to adjust token counts. Do not get disturbed by this choose X with apply... command, it is just the standard way of invoking a graph transformation rule when its arguments are known in advance (when no graph pattern matching is needed). Hopefully, the VTCL language will introduce some sort of syntactic sugar for GT calls (like a gtcall command), because the current syntax is capable of misinterpretations. rule firetransition ( in TransitionFQN ) = seq { let Transition = ref ( TransitionFQN ) in seq { forall Place with find sourceplace ( Transition, Place ) do choose X with apply removetoken ( Place ) do skip ; forall Place with find targetplace ( Transition, Place ) do choose X with apply addtoken ( Place ) do skip ; } } Finally, the third ASM rule fires a random transition, it resembles to getfireable- Transitions in finding a fireable transition, the use of the choose construct instead of a forall loop enables to choose one random fireable transition. After that, it simply calls the previous firetransition rule to actually fire the chosen transition, and its name is printed to the code output (a standard view in the Eclipse framework) to give the user some feedback. rule firerandomtransition ( in PetriNetFQN ) = seq { let PetriNet = ref ( PetriNetFQN ) in seq { choose Transition with find

97 5.1. SIMPLE EXAMPLE: PETRI NETS 96 } } { } istransitionfireable ( PetriNet, Transition ) do seq call firetransition ( fqn ( Transition )); print (" Transition fired : " + fqn ( Transition )); Declarative mapping After creating the required patterns, graph transformation rules and ASM rules, a mapping must be constructed, which connects check machines and execution machines together to form one simulation step. For the remaining part of this section, let us assume that we have already created the three individual machines that call the ASM rules described above. Let us assume that the names of the machines are GetFireableTransitions, FireTransition and FireRandomTransition. In order to make these machines visible to the ViatraDSM simulation module, we have to define the steps (each step requires a check machine, an execution machine and an arbitrary number of mapping rules), and finally define the simulation as the collection of possible steps. The first step to construct will be the random transition firing. Its check machine is the one called GetFireableTransitions and its execution machine is FireRandomTransition. All that is needed is a few mapping rules. Let us examine, what exactly is needed. First, the check machine needs the fully qualified name of the Petri net, which is being simulated. In the previous chapter, it was mentioned that each running simulation has a target, which is the model element, the simulation was executed upon. In section all mapping types were described, and it seems that right now, it is the CopyTarget rule, which is needed. In order to make the target Petri net, available for both the check machine and the execution machine, the mapping rule CopyTarget( PetriNetFQN, PetriNetFQN ) will be used. The two strings refer to the PetriNetFQN input arguments of the machines. We also want our random firing step to be disabled, when there are no fireable transitions. The check machine can be used to perform that, if it returns an empty string in the TransitionList output argument, there are no fireable transitions. Looking back at the possible mapping types, one may notice that it is the one called NonEmpty, which is capable of checking this, so the complete mapping rule would be NonEmpty( TransitionList ). With these two simple rules, the random firing of transitions was described precisely.

98 5.1. SIMPLE EXAMPLE: PETRI NETS 97 Simulation target Domain simulation Name = Petri Net Simulation step Fire random Check machine = GetFireableTransitions Execution machine = FireRandomTransition CopyTarget ( PetriNetFQN, PetriNetFQN ) Domain metamodel Petri Net domain NonEmpty( TransitionList ) Token petrinets PetriNet tokens places transitions Simulation step Fire Check machine = GetFireableTransitions Execution machine = FireTransition Place capacity Capacity (property) OutArc InArc weight weight Weight (property ) Transition CopyTarget ( PetriNetFQN, none) ElementChoice ( TransitionList, TransitionFQN ) Figure 5.4. Constructing simulation from machines and mapping rules The second (and last) simulation step is also transition firing, but this time, we would like to allow the user the choose which transition is fired. The check machine remains the same (GetFireableTransitions), but the execution machine this time is FireTransition. Different mapping rules are needed, since FireTransition needs different arguments than FireRandomTransition. For example, this time, the simulation target must not be passed to the execution machine (a transition unambiguously defines its parent Petri net), so the first mapping rule changes to CopyTarget( PetriNetFQN, none). Thus the check machine still gets the target Petri net, but the execution machine does not. Now comes the more interesting part, defining a choice point. The list of fireable transitions is returned from the check machine by the TransitionList argument, and the user needs to choose one element of that list, and pass it as the TransitionFQN argument of the execution machine. Looking at the mapping types, there are four alternatives, [Object Element]Choice[ɛ HideSingle]. Since a transition is actually a DSM model element, the use of an Element version of the possible mapping types is favored, and since we do not want to hide a single choice from the user, the final choice is ElementChoice. The complete mapping rule would read ElementChoice( TransitionList, TransitionFQN ). All that remains is the definition of the simulation itself. First, the name of the

99 5.1. SIMPLE EXAMPLE: PETRI NETS 98 simulation and of all the steps is given, and one element of our domain metamodel shall be chosen, which specifies the required type for the simulation target. Since this simulation is meant to be executed on Petri nets, this target element type will be the PetriNet element of the metamodel. Figure 5.4 shows the entire simulation description in a graphical form. That was it, going through the steps above, one could quickly implement simulation support for an arbitrary domain. Section will show how all that is actually represented on the user interface, but before showing some nice-looking screenshots, think about how easy it was to design simulations. Graph patterns and transformation rules operate with concepts of the domain metamodel (Place, Transition, OutArc, etc.), therefore they represent the same level of abstraction. One needs not to call various Java or C# functions to query or modify the model as an Eclipse/GMF or Microsoft DSL Tools framework would require. True, those three abstract state machine rules may not be completely declarative (even though it tries to be). But with the forall and choose constructs and pattern matching, it definitely describes problems at a higher level than Java or C#. The GTASM interpreter still has some minor discommodities, like the obscure way of calling a graph transformation rule, or the difficulty of enumerating matches in a list, but a transformation step requires still way less coding than it would do in traditional programming languages. The handling of choice point also becomes a straightforward job with the mapping rules described in section 4.4.2, one just has to specify a source list, and a target argument, and the simulation module handles the rest. As a conclusion, I may say that the simulation module is an efficient tool for describing dynamic behavior of domain specific languages. Combining the powerful transformation engine of the Viatra2 framework, the modeling capabilities and user interface of the ViatraDSM framework with a declarative, mapping-based choice point description allows language engineers without advanced programming experience to focus on the domain itself, and quickly describe domain semantics at a high level User interface Up to this point the user interface of the simulation module was not mentioned at all. That was intentional, I believe that the user interface should be presented with screenshots, but those shots can only be fully understood with a proper introduction of the simulation system itself. But now, as all the theoretical background was elaborated in the last chapter, and a simple example was presented in the previous sections, it is time to see the simulator at work.

100 5.1. SIMPLE EXAMPLE: PETRI NETS 99 The simulator module is connected to the ViatraDSM framework user interface at three points. First, the context menu is expanded to contain the possible simulationrelated operations of the given element. Second, the outline (tree) view listens to simulation notification events, and updates its visuals at changes. The simulation module contains a few helper classes, which makes it easy to add coloring to tree elements, but arbitrary other modifications to the outline are also possible. The third connection point involves the graphical visualization, the helper classes also allow for graphical elements to query, how the model element they are representing is involved in various simulations. But it is important to note that the simulation module only offers helper classes, actual coloring and modification (both in the outline and in the diagram view) should be done by some Java coding. In case of the tree, the most simple coloring scheme (which is used in our example), which uses just one color to differentiate between choice point elements and others, is two lines of Java code. That is not much, and future work will definitely involve some sort of declarative description for more advanced tree coloring. In case of diagrams, it is the designer of the various domain-specific figures, who should handle simulation visualization. He can use the helper class to find out how that element is involved in simulations, but the actual visual difference between an ordinary and a simulated state of the element (like the red color of fireable transitions) should be coded by the figure designer himself. My colleague István Ráth conducts research in the area of declarative graphical description of domain-specific models, I believe his future work will also include the area of simulations. Figure 5.5 shows an example Petri net of four places and four transitions, which we will use for the simulation demo. On the left of figure 5.6 we can see the context menu corresponding to the pn0 Petri net instance. Our freshly made simulation, entitled Petri net, is ready to launch, and the simulation framework also displays the simulation target just for the sake of unambiguity (since the simulation target is always the element, whose context menu contains the Simulation start operation). By starting the simulation, the outline view changes its appearance as shown on the right of the same figure. There is one fireable transition (fork), and it is highlighted with red (later we will see, that it is also highlighted on the graphical view). Also as a consequence of the simulation start, the context menu of the pn0 element changes, its new appearance is shown on figure 5.7. One can notice that the simulation start item has disappeared, yielding the place to the stop action and the various simulation steps. By activating the Fire [fork] action, the model arrives to a state shown on figure 5.8. Here the graphical model view can be seen, which also

101 5.1. SIMPLE EXAMPLE: PETRI NETS 100 Figure 5.5. Example Petri net, before the simulation Figure 5.6. Initial context menu of the pn0 element, outline appearance after start)

102 5.1. SIMPLE EXAMPLE: PETRI NETS 101 Figure 5.7. Context menu of the pn0 element after the simulation has started Figure 5.8. Example Petri net, at the middle of the simulation reacts to simulation changes, fireable transitions are encircled and displayed in red on the diagram view as well. At this stage, I can demonstrate that the context menu actually filters for available actions. Figure 5.9 shows that the context menu of the Petri net itself contains all available transitions, whereas the context menu of the exit transition contains only the firing of itself and the global (not transition-dependent) actions. As a final step of this simulation example, a random transition is fired. This leads to a screen shown on figure The code output view indeed displays the name of the transition fired (thanks to that print command in the ASM rule), which happened to be the join one. Difference between various choice point mappings Up to this point, the ElementChoice mapping rule was used to manage choice point. In this section, a demonstration of two other choice point mapping types, ObjectChoice and ElementChoiceHideSingle, will be given. As section described, the only difference between the ElementChoice and the ObjectChoice types is that

103 5.1. SIMPLE EXAMPLE: PETRI NETS 102 Figure 5.9. Differences in the context menu for pn0 (left) and exit (right) Figure Random transition firing displays transition name in code output

104 5.1. SIMPLE EXAMPLE: PETRI NETS 103 the later does not try to interpret the elements of the returned list (in the example case that is the TransitionList argument of the GetFireableTransitions rule) as fully qualified element names. Figure 5.11 shows the appearance of the ViatraDSM user interface, when the ElementChoice( TransitionList, TransitionFQN ) rule is replaced with ObjectChoice( TransitionList, TransitionFQN ). The model is in a state where both fork and join may fire, but since the returned strings are not interpreted as model elements, they are not highlighted neither in the outline, nor in the diagram view. With that rule, firing actions are accessible only from the context menu of the Petri net pn0 itself, and instead of short names, we see the entire fully qualified names of the transitions. Figure Effects of the ObjectChoice and ElementChoiceHideSingle mappings On the other hand, mapping type ElementChoiceHideSingle keeps the fully qualified name lookup functionality of the ElementChoice type, but when only one possibility exists, it is hidden from the user. The bottom of the same figure (5.11 shows an example of that, here the simulation step Fire stands for the firing of the fork transition (one can see from the token marking that only fork is enabled), but neither is the transition name displayed in the context menu, nor is it highlighted with