SUPPORTING MODEL ANIMATION METHODS WITH GRAPH TRANSFORMATION MODELLANIMÁCIÓS ELJÁRÁSOK MEGVALÓSÍTÁSA GRÁFTRANSZFORMÁCIÓVAL. Ph.D.

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "SUPPORTING MODEL ANIMATION METHODS WITH GRAPH TRANSFORMATION MODELLANIMÁCIÓS ELJÁRÁSOK MEGVALÓSÍTÁSA GRÁFTRANSZFORMÁCIÓVAL. Ph.D."

Átírás

1 Budapest University of Technology and Economics Department of Automation and Applied Informatics SUPPORTING MODEL ANIMATION METHODS WITH GRAPH TRANSFORMATION MODELLANIMÁCIÓS ELJÁRÁSOK MEGVALÓSÍTÁSA GRÁFTRANSZFORMÁCIÓVAL Ph.D. Thesis Tamás Mészáros Advisors: Gergely Mezei Ph.D., Tihamér Levendovszky Ph.D. January 2011

2 Abstract With the raising popularity of domain-specic modeling, there is an increasing need for sophisticated domain-specic environments. The aim of this thesis is to facilitate the rapid generation of domain-specic infrastructures - including domain-specic languages, model processors and other tool support. The novel results of the thesis can be divided into three main parts. The rst contribution deals with the visual specication of the dynamic behavior (animation) of metamodeled languages. We provide (i) an event-based conceptual architecture to support animation and (ii) a set of visual languages to describe the animation of the models and their execution. A transformation is also elaborated that converts executable source code from the animation models. Our solution clearly separates the domain knowledge and the animation description both on the conceptual and the realization level. Thus, our approach oers a concise and systematic solution to provide a highly customizable animation framework for metamodeled languages with strong integration support to external systems such as simulation engines. In order to decrease the execution time of model simulations, the second contribution focuses on the performance optimization of graph rewriting-based model transformation systems. We provide an overlapped matching technique for control ow-based model transformation systems. Our technique harnesses the similarity of consecutively executed rules by matching common parts of the patterns at once. In addition to the rst-t execution, we specialize the base algorithm for exhaustive and iterative execution as well. We provide another optimization technique for exhaustively executed rules, which technique reuses partial matches from the previous execution of the same rule. We introduce the combination of the two approaches as well. In the third contribution, we provide a complete framework based on model transformation to dene and apply various model patterns with arbitrary intention in a domain-specic environment. We provide the formal description of the execution logic of the transformation engine and analyze the correctness of the logic and the expression power of the solution. The introduced transformation system serves as the execution engine for the operational aspect of Active Model Patterns (AMPs) that describe frequently used complex model manipulations and refactoring operations in Domain-Specic Modeling. With the specialization of the operational aspect, we can easily realize the static aspect of AMPs as well. Here we provide the formal specication of the requirements against the static approach. We present a transformation realizing the static aspect and prove its correctness. The introduced approach is motivated by case studies from the VMTS Animation Framework and other domains. We illustrate the applicability of the theoretical results by realizing them in VMTS. Based on the VMTS Animation Framework, we have realized an interactive model transformation debugger. Furthermore, we have adapted the MATLAB Simulink simulation engine to the VMTS Animation Framework and performed the animation of models in VMTS based on Simulink simulation results. Moreover, we have realized the VMTS Transformation Framework component, and integrated it into MATLAB Simulink as well to facilitate the application of model transformations on Simulink models. Using the Active Model Pattern approach of VMTS, we have created patterns for various domains including state-chart models, electric circuit, Symbian user interface, and model transformation specication languages. ii

3 Összefoglaló A szakterületi modellezés növekv népszer ségével együtt egyre nagyobb igény mutatkozik a mindinkább kinomult szakterületi környezetek iránt. Ezen munka célja el segíteni az ilyen környezetek gyors, generatív el állítását - beleértve a szakterületi nyelveket, modell feldolgozókat és egyéb eszközöket. A kutatás eredményei három f bb részre oszthatók. Az els rész metamodellezett nyelvek dinamikus viselkedésének (animációjának) vizuális deniálásával foglalkozik. Kidolgoztuk (i) egy animációk támogatására szolgáló eseményvezérelt architektúra koncepcióját és (ii) egy szakterületi nyelv családot, amivel vizuális modellek animációját lehet leírni. Modelltranszformációt készítettünk, amely az animációs modellekb l futtatható kódot generál, ezáltal a modellek végrehajthatóvá válnak. Megoldásunk el nye, hogy mind koncepcionális mind megvalósítás szintjén élesen szétválasztja a szakterületi tudást és az animáció leírását. Mindemellett hathatós támogatást nyújt küls szimulációs rendszerek integrációjához is. A modell szimulációk futásidejének csökkentése érdekében a második témakör a gráfújraírás alapú modelltranszformációk sebességoptimalizálására fókuszál. Kidolgoztunk egy átlapolt szabályvégrehajtási módszert, amit vezérlésfolyam alapú transzformációk esetén lehet alkalmazni: megoldásunk kihasználja az egymás után végrehajtott szabályok közötti hasonlóságot azáltal, hogy a keresett minták hasonló részeit egyszerre keresi a hoszt gráfban. Az alap algoritmust specializáltuk kimerít és iteratív szabály végrehajtás esetére is. Kidolgoztunk egy második optimalizációs módszert is, ami szabályok kimerít futtatása során ugyanazon szabály korábbi részeredményeit hasznosítja újra. Bemutatjuk a két módszer egy lehetséges egyesítését is. A harmadik téziscsoportban bemutatunk egy modelltranszformáció alapú keretrendszert, aminek a segítségével mintákat deniálhatunk és alkalmazhatunk szakterület-specikus környezetben. Formálisan specikáljuk a transzformációs rendszer m ködését és elemezzük annak kifejez erejét. Az ismertetett transzformációs környezet az Active Model Pattern (AMP) koncepció m veleti aspektusának végrehajtási rétegeként funkcionál. Az AMP célja gyakran használt, összetett modellszerkesztési m veletek megfogalmazása és automatizálása. Az AMP infrastruktúra m veleti aspektusa segítségével a statikus aspektust már mint egy mintát deniáljuk és valósítjuk meg. A megoldás szükségességét animációs és más szakterületekhez kapcsolódó esettanulmányokkal indokoljuk. Az elméleti eredmények gyakorlati alkalmazhatóságát VMTS-beli megvalósításukkal és gyakorlati példákkal igazoljuk. A VMTS Animation Frameworkre építve elkészítettünk egy interaktív modell transzformáció debuggert. Továbbá, a MATLAB Simulink szimulációs rendszer integrációjával VMTS-ben megjelenített modellek animációját tettük lehet vé küls szimulációs eredmények alapján. Elkészítettük a VMTS Transformation Framework komponenst. A MAT- LAB Simulink környezethez történ illesztéssel képessé tettük a Simulink modellez környezetét gráfújraírás alapú modelltranszformációk alkalmazására. Az Active Model Pattern VMTS-beli megvalósítása segítségével számos mintát készítettünk különböz szakterületekhez, például állapot gép, transzformációs nyelvek, elektromos áramkörök vagy éppen Symbian mobil felhasználói felület. iii

4 Acknowledgments First of all, I am thankful to my family for always standing by me and helping me in every manner. I am also thankful to my girlfriend Reni for her tolerance and continous support. I would like to express my thanks to Gergely Mezei for his conscientious work. I am indebted to him for the great amount of proofread papers, the long conversations and the encouragement he gave me. I am not less thankful to Tihamér Levendovszky exactly for the same reasons. He always had good visions and knew the right direction even if I did not see it that time. Without their support, this thesis could not have been written. I am also grateful to Hassan Charaf and István Vajk for providing me the nancial and human conditions for my research. I'm thankful to Márk Asztalos, László Lengyel, István Madari and Tamás Vajk for the inspiring conversations, the common research, and last but not least for the good morale. iv

5 Preface Dedication The content of this thesis is a product of the author's original work except where explicitly stated otherwise. Nyilatkozat Alulírott Mészáros Tamás kijelentem, hogy ezt a doktori értekezést magam készítettem, és abban csak a megadott forrásokat használtam fel. Minden olyan részt, amelyet szó szerint, vagy azonos tartalomban, de átfogalmazva más forrásból átvettem, egyértelm en, a forrás megadásával megjelöltem. Budapest, Január (Mészáros Tamás) A bírálatok és a védésr l készült jegyz könyv a kés bbiekben a Dékáni Hivatalban elérhet ek. v

6 Table of Contents Acknowledgments List of Figures List of Tables iv x xii Chapter 1 Introduction Software Modeling Model-Driven Engineering Motivations and Open Problems Thesis Outline Chapter 2 Background Category Theory Graphs and category theory Algebraic graph transformation Concurrency Theorem Computational completeness of graph transformation Graph transformation in the Visual Modeling and Transformation System Abstract State Machines An overview of ASM Mathematical Denition of ASM Bisimulation Simulation Systems Classic DEVS System Specication Discrete Time System Specication vi

7 Chapter 3 Dening the dynamic behavior of metamodeled languages Introduction Related work Problem statement The VMTS Animation Framework Architecture Events and event handlers Animation description language The animation engine Operational Semantics of the Animation Models Universes ASM functions for VAF ASM rules of the expected behavior Concrete behavior of the implementation Processing Animation Models Transformation Models Verication of the input model Processing the state machines Generating the conguration class le Verication of the transformation Equivalence of the Specication and the Implementation Bijective relation between the states of the two systems Bisimulation of the two systems Expressiveness of the Animation Language Expressing DEVS with VAF Expressing DTSS with VAF Conclusions Chapter 4 Compile-time performance optimization of model transformation systems Introduction Related Work Graph transformation engines Problem Statement Basics Denitions Overlapping First-Fit Executed Rules Overlapping Exhaustively Executed Rules Overlapping Iteratively Executed Rules Heuristics to Estimate the Total Cost of the Overlapped Matching Deep Exhaustive Execution vii

8 4.9.1 Example Overlapped Matching with Deep Exhaustive Execution Practical Evaluation of the Results Benchmark description Measurement results Conclusions Chapter 5 Realizing the Active Model Pattern Framework with Interactive Model Transformation Introduction Related Work Background and Problem Statement Realizing Operational Patterns with Interactive Graph Transformation Requirement specication Graph rewriting-based model transformation engines Realization of the AMP approach in a model transformation environment Realizing Static Model Patterns with Operational Patterns Requirement specication Semantic verication of the requirements, multi-typed graphs Generating the static pattern insertion rule Realization and Analysis of Practical Operational Patterns Unattening a state chart animation model Exhaustive set for control ow-based model transformation systems Rewriting rule concatenation Conclusions Chapter 6 Practical Application of the Scientic Results The Visual Modeling and Transformation System User Interface Model Transformation Model Animation Model Pattern Support Chapter 7 Conclusions Thesis I Thesis II Thesis III Practical Validation of the Novel Scientic Results Framework Applications viii

9 7.5 Future work Acknowledgements Appendix A Detailed Proofs 124 Appendix B Formalizing the execution semantics of the VMTS Transformation Framework133 B.1 Universes B.2 ASM functions for VTF B.3 Rewriting phase B.4 Execution Logic of Control Flow Models Bibliography 152 ix

10 List of Figures 1.1 The basic concepts of MIC A diagram representation of pushout Direct graph transformation with double pushout E-dependency production E-related transformation Concurrency Theorem VTF control ow language metamodel An example VMTS transformation denition Overview of the animation languages Event handler metamodel Petri-net event handler model Metamodel of the animation language A high-level animation model Petri-net animator The control sequence of the transformation rules Verifying the input model Creating the skeleton of the animation source code Processing states Processing transitions Generating the conguration class le One-slot toaster VAF model Simulating DTSS with VAF Overlapped matching of rules Overlapped matching of iterative rules Deep exhaustive execution Deep exhaustive execution with overlapped matching Social network metamodel and rewriting rules Overlapping rewriting rules on two levels x

11 5.1 The architecture of the Active Model Pattern Infrastructure Optional caption for list of gures Static pattern to highlight element under mouse cursor Static pattern requiring multi-typed matching Execution of the rewriting rule inserting a static pattern Optional caption for list of gures State chart unattening example Control ow graph of the state chart unattening transformation Optional caption for list of gures Exhaustive set example Exhaustive set with precedences The control ow model of the exhaustive set pattern Optional caption for list of gures Concatenating two rewriting rules Rule concatenation process Optional caption for list of gures The architecture of VMTS Ant World simulation Rewriting rules of the Ant World simulation Animation Framework architecture Animating model transformation Integrating Simulink simulations into VMTS Symbian domain and patterns The metamodel of schematic models Schematic model patterns Buered inverting amplier A.1 E-concurrent production of consecutive executions of the same rule code B.1 Nondeterministic choice in VMTS B.2 Sequencing programs B.3 Iteration of a program xi

12 List of Tables 4.1 Measurement results for the exhaustive execution Measurement results for the iterative execution Deep exhaustive execution with overlapping xii

13 Chapter 1 Introduction Recently, modeling has become an essential tool in software engineering. With the help of models, we can raise the level of abstraction and improve the reusability of software components at the same time. Visual modeling can also help illustrate software systems in a well understandable manner. It is a fact that modeling languages have a great role in the drastic improvement of software complexity in the last decades [Jézéquel, 2003]. 1.1 Software Modeling The Unied Modeling Language (UML)[UML, 2010, Miles and Hamilton, 2006] has become the de-facto standard to describe general software models. It provides languages to dene both the static structure of the systems and also their dynamic behavior in a unied way. Due to the fact that UML provides the same set of languages to describe any system, it has many users and serves as a common interface between software engineers. However, because of the generality it is often complicated to use, as the application logic or the components of the application-specic concept are often not simple to express using general languages. The resulting models are often far from the natural language of the domain that they are intended to describe. In contrast to UML, an other popular modeling approach is Domain-Specic Modeling (DSM) [Kelly and Tolvanen, 2008, Stahl and Völter, 2006]. The essence of DSM is to use specialized modeling languages called Domain-Specic Modeling Languages (DSMLs) for each possible application domain instead of using general purpose languages such as UML. A DSML includes both an individual notation for the target domain and the topological constraints between the elements of the language. The notations of a good DSML should follow the notations (either graphical or textual) used by the experts of the target domain. Due to the fact that a DSML is specialized for one domain, it can be extremely ecient [Kelly and Tolvanen, 2008] compared to other solutions. Another adventage of DSM is that tool support can also be customized for each domain thus further increasing productivity. These facts have also been recognized by the leaders of the software industry, and they have also built their own DSM environments [Cook et al., 2007, Gronback, 2009]. The high customizability has drawbacks as well: a new

14 Chapter 1. Introduction 2 modeling environment must be built for each and every application domain along with the related generators. 1.2 Model-Driven Engineering Model-Driven Engineering (MDE, [Poole, 2001]) uses models as primary engineering artifacts in the engineering lifecycle. MDE is not restricted to software modeling, it can also be applied to system and data engineering. MDE is a very large family of modeling and model transformation initiatives, for example Model-Driven Architecture (MDA) [Fowler and Scott, 2000, Kleppe et al., 2003, Mellor and Balcer, 2002, Mellor et al., 2004, MDA, 2003] and Model Integrated Computing (MIC) [Sztipanovits and Karsai, 1997, Sztipanovits and Karsai, 1997, Sztipanovits et al., 2003]. One of the most popular technologies in model-oriented software development is the Model- Driven Architecture dened by the Object Management Group (OMG) [OMG, 2010]. MDA facilitates the design and development of systems in a platform independent way, the key of which is the separation of platform-dependent and platform-independent models. OMG denes three dierent modeling levels for MDA: the rst is called Computational Independent Model (CIM) that contains the business model of the system. The second one is called Platform-Independent Model (PIM) which models the system functions, the third one is the Platform-Specic Model (PSM). The PSM completes the PIM with platform-specic details: PSMs are generated based on the PIM using model processors. Figure 1.1. The basic concepts of MIC Another popular technology of model-oriented development is Model Integrated Computing (MIC). The essence of MIC is to extend the role of the model by using it as the base of the entire development process (Figure 1.1). The modeling environment of a specic domain is dened with the help of the metamodel of the domain, and the environment is automatically generated by Meta-Level Translation. With the help of the environment, one can create models, and turn them into executable applications using Model Interpreters. MIC supports the evolution of both the environment and the modeled application by automatic code generation from the model artifacts. The aim of this thesis is to promote the creation of domain-specic environments in a faster, richer and more reliable way.

15 Chapter 1. Introduction Motivations and Open Problems A domain-specic environment can be regarded as a special generative programming environment [Czarnecki and Eisenecker, 2000], where the input of the generators is a set of models. The most valuable asset in this infrastructure is the domain-specic generator as well as the domain-specic environment. This infrastructure must be built for each application environment separately. In order to accelerate this reoccurring phase, the aim of current research is to facilitate the rapid generation of domain-specic infrastructures including DSMLs, model processors and other tool support. One of the most popular forms to dene visual DSMLs is metamodeling [Nordstrom, 1999]. Metamodeling means using a specic DSML to model the elements and constraints of a language. This model is called the metamodel of the language and the models created using this language are referred to as the instances of the metamodel. Since metamodels are intended to specify only the structural properties ( abstract syntax ) of the language, other techniques are necessary to dene the visual appearance ( concrete syntax ) of the specic elements. The most basic solution for this issue is to assign an icon to each element somehow, e.g. with an additional conguration le, or storing the path of the related image into the metamodel [Lédeczi et al., 2001]. A more advanced approach is to hard-code the visualization of the elements, thus, one can customize and dynamically change the appearance based on the current properties of the model. The Generic Modeling Environment [Lédeczi et al., 2001, GME, 2010] also support this approach using Decorators [Molnár et al., 2007]. To avoid hardcoding at least in many practical cases, AToM 3 [de Lara and Vangheluwe, 2002] had improved existing solutions, and facilitated the visual denition of the visualization: the language of their metamodel provides a graphical editor with primitives, and stores the visualization info in the metamodel. The Visual Modeling and Transformation System (VMTS) [Mezei et al., 2006] and the Eclipse [GMF, 2010] approaches can be considered the most exible solutions at the moment: they provide a separate DSML for the specication of the concrete syntax and to assign it to the elements of the abstract syntax. Typically, domain-specic models are usually built not only with documentation purposes, thus, mechanisms are required to process them. Here we usually distinguish two dierent approaches: traversal-based model processors and graph rewriting-based model processors. Model traversing [Vajk et al., 2009, VMTS, 2010] usually uses the API of the modeling environment to traverse the host model, and it generates some sort of output. This processes is often supported with script or template-based languages [Tolvanen, 2006, Cook et al., 2007]. The other popular approach is the graph rewriting-based model transformation [Ehrig et al., 2006]. This technique searches for patterns in models represented as graphs, and replaces the found matches with other patterns. Thus, the mathematical model of graph transformation that has been researched since the '70s [Claus et al., 1979] has found a practical application. Since graph transformation is intended to process models, a straightforward idea is to describe also the steps (rules) of the graph transformation system using modeling. Many tools (e.g. VIATRA [Varró, 2004a], PROGRES [Zündorf, 1996] or AToM 3 [de Lara and Vangheluwe, 2002]) started to incorporate graph transformation engines with modeling support in the early times as well. Since the early attempts, many specialized kinds of graph transformation approaches have been evolved (e.g. Pair Graph Grammars [Pratt, 1971] or Tripple Graph Grammars [Schürr, 1995, Königs, 2005] for model synchronization ).

16 Chapter 1. Introduction 4 Recall that there are numerous approaches to dene the abstract and concrete syntax of metamodeled languages. However, there is no integrated solution to describe the dynamic behavior animation of the languages. As we have shown, the tendency is to solve DSMrelated maintenance issues with modeling, it is an open question whether we can describe the dynamic behavior of DSMLs with DSMLs. Most tools (e.g. AToM 3 or AGG [Taentzer, 2004]) use graph transformation to animate models, however, similar approaches are lack of the capability to interact with their environment. Graph transformation can be considered a useful mean to describe dynamic behavior as it has been illustrated by international contests ([GraBaTs08, 2008, GraBaTs09, 2009, TTC2010, 2010]). Since model animation methods are often demanding, it is important to optimize the transformations as much as possible to save time and resources. Since the algorithmic complexity of isomorphic subgraph matching is NP-complete in general ([Garey and Johnson, 1990, Flores et al., 1977]), the overall performance can be improved only by heuristics. A straightforward idea is to achieve some kind of parallelism during the execution of the rules: this parallelism may be either multi-threaded or single-threaded which means that similar parts of the dierent rewriting rules are evaluated at once and reused by all the related rules. For both approaches, there are numerous related work ([Mezei et al., 2007, Taentzer, 1996, Varró and Varró, 2004, Dörr, 1995]), however, there are other possibilities, for which the optimization is still an open question. Provided that such a system incorporating model animation capabilities and a fast transformation engine exists, designing animations still remains an engineering task. To accelerate this process, the software engineering community has a proven solution: dening patterns and solve recurring problems with the help of them. It is an open question if and how the animation environment can be prepared to support the application of patterns. This thesis presents theoretical and practical answers for the aforementioned questions. The main topic of the presented research is supporting model animation with model transformation. The open issues related to the topic are as follows: 1. Dynamic behavior denition of visual languages. In order to facilitate the animation of visual languages, a fundamental concept should be elaborated, and a set of domainspecic languages that are capable of describing the dynamic behavior of metamodeled languages. The operational semantics of the new languages should be formalized, the expression power of the solution should be analyzed. Furthermore, transformations should be provided that make the automated execution of the animation models possible. 2. Optimized execution of model transformations. In order to optimize the performance of control ow-based model transformations, an overlapping technique should be elaborated that exploits the structural similarity of consecutively executed rules. The matching algorithm should perform the matching of the common parts of the dierent rules at once, thus reducing execution time. It should be examined whether and how the idea could be specialized to the exhaustive execution, i.e. the same rule is applied as long as possible. The semantic preserving property of the algorithms should be ensured. The achieved gains should be veried with measurements. 3. Supporting model patterns. The purpose is to support the denition and application of patterns describing often recurring editing operations. Thus, the fundamental concepts

17 Chapter 1. Introduction 5 that facilitate the precise description of model patterns should be elaborated. The solution should be generic enough to express any possible operation. The approach should be generalized to domain-specic design patterns, i.e. the insertion of incomplete model fragments. 1.4 Thesis Outline The organization of this thesis is as follows. In Chapter 2, we summarize the main concepts and notations used through this thesis. Chapter 3 introduces a framework suitable for describing the dynamic behavior of visual languages. We provide a set of visual languages, the formal description of their operational semantics, and automated solutions to process the models. Chapter 4 focuses on the performance optimization of model transformation systems. We provide two dierent approaches and their combination to improve the overall performance of graph rewriting-based model transformations. In Chapter 5, we introduce a model transformation-based framework to formalize and execute model patterns with arbitrary intentions in arbitrary domains. We illustrate the approach with practical case studies. Chapter 6 highlights the applicability of the theoretical results with examples from the real work where they were used. Finally, Chapter 7 summarizes the results.

18 Chapter 2 Background This chapter introduces the main concepts and the fundamentals of the notation system used throughout this work. Firstly, we provide the basic constructs of category theory that is used to formalize algebraic graph transformations. Secondly, we provide a short description about the applied graph formalisms (graph, labeled graphs, typed graphs, typed graphs with attributes) and the basic denitions of the related categories. Thirdly, we discuss the fundamentals of the algebraic graph transformation including its current realization in the framework that we use. In the following section we present the Abstract State Machine formalization technique used for the precise description of the contributed algorithms. We summarize the essential denitions of bisimulation, the technique is used to prove the equivalence of two dierent systems. Finally, we introduce the basic denitions of Discrete Event System Specication and Discrete Time System Specication. 2.1 Category Theory Category theory [Pierce, 1991] [Barr and Wells, 1990] [Sabetzadeh and Easterbrook, 2003] [Segura ML, 2001] is a relatively young branch of algebraic topology. The main advantage of category theory is that it produces compact descriptions of problems without loosing preciseness [Ehrig, 1979b]. Category theory mainly focuses on functions while their domains and ranges are of less importance. The basic constructs used in category theory are morphisms (arrows), which lend themselves to a composition operator in an associative way. A category consists of arrows, their domains, and ranges that are called objects. Denition 2.1 (Category). A category C comprises: 1. Objects 2. Arrows (morphisms) 3. Operations assigning to each arrow f an object, an object dom f, its domain, and an object cod f, its codomain (denoted with f : A B, if dom f : A and cod f : B). The collection of all arrows with domain A and codomain B is denoted with C(A, B). 4. A binary composition operator assigning a composite arrow g f : dom f cod g to each pair of arrows f and g with cod f = dom g, satisfying the following associative law:

19 Chapter 2. Background 7 for any arrows f : A B, g : B C and h : C D(with A, B, C, D not necessarily distinct), h (g f) = (h g) f. 5. For each object A, there is an (identity) arrow id A : A A, satisfying the following identity law: for any arrow f : A B, id B f = f, and f id A = f. Denition 2.2 (Diagram). A diagram in a category C is a collection of vertices and directed edges, consistently labeled with objects and arrows of C (i.e. if an edge in the diagram is labeled with an arrow f, and f has a domain A and a codomain B, then the endpoint of this edge must be labeled with A and B). The diagrams make the statements more comprehensible in category theory. The next step is to provide a mechanism to express equations with diagrams. Denition 2.3 (Pushout). Let C be a category, with two given arrows b : A B, c : A C. The triple is called the pushout of if the following conditions hold: (i) g b = f c (commutative property) (ii) For any object D and arrows g : B D, and f : C D if g b = f c, there is a unique arrow h : D D such that h g = g and h f = f (universal property). The triple C, c : A C, f : C D is called the pushout complement of b, g, while D is called the pushout object of b, c. Fig. 2.1 shows the diagram representation of pushout. The pushout object (D) emerges from gluing two objects (B and C) along a common subobject (A). A b B c g C f D g f h D Figure 2.1. A diagram representation of pushout 2.2 Graphs and category theory In this section, we summarize the basic denitions of graphs, their extensions (labeled, typed, attributed graphs) and their relation with category theory. Denition 2.4 (graph). A graph G = (N, E, s, t) consists of a set N of nodes, E of edges and two functions s, t : E N, the source and target functions that assign the source and target nodes to each edge of the graph. Denition 2.5 (elements of a graph). Given a graph G, the elements of G are its nodes and edges and are denoted by L G, i.e. L G = N G E G. To form the Graph category [Pierce, 1991] the morphism between two graphs is dened as follows:

20 Chapter 2. Background 8 Denition 2.6 (graph morphism). Given graphs G 1 = (N 1, E 1, s 1, t 1 ), G 2 = (N 2, E 2, s 2, t 2 ), a graph morphism f : G 1 G 2, f = (f N, f E ) consists of two functions f N : N 1 N 2 and f E : E 1 E 2 that preserve the source and target functions, i.e. f N s 1 = s 2 f E and f N t 1 = t 2 f E. Labeled graphs can be considered a simple extension of basic graphs by attaching additional information called label to their nodes and edges. Denition 2.7 (labeled graphs). A label alphabet C = C V, C E is a pair of nite sets of node labels and edge labels. A labeled graph over C is a system G = V G, E G, s G, t G, l G, m G consisting of two nite sets V G and E G of nodes and edges, two source and target functions s G, t G : E G V G, and two labelling functions l G : V G C and m G : E G C E. We denote the set of all graphs over C by A C. Denition 2.8 (labeled graph morphism). Given labeled graphs G 1, G 2. A labeled graph morphism f : G 1 G 2, f = (f N, f E ) consists of two functions f N : N 1 N 2 and f E : E 1 E 2 that preserve the source and target functions and labels i.e. l 1 f N = l 2 and m 1 f E = m 2. Another, more sophisticated extension of graphs is assigning a type to their elements: the possible types are dened with the help of a so-called type graph, the nodes of which can also be connected with inheritance edges. Thus, if a node is typed by a type node, then it is also typed by the ancestor nodes of that node. Denition 2.9 (Type graph with inheritance). [Ehrig et al., 2006] A type graph with inheritance is a double (G T, I) consisting of a type graph G T = (N, E, s, t) (with a set N of nodes, a set E of edges, a source and a target function s, t : E N), and inheritance graph I = (N, E I, s I, t I ) sharing the same set of nodes N. Denition 2.10 (Inheritance clan). [Ehrig et al., 2006] Given a type graph with inheritance T = (G T, I) For each node n in N (N N I N GT ), the inheritance clan is dened by clan I (n) = {n N path n n in I} where path of length 0 is included, i.e. n clan I (n). In other words, given a node n in the type graph, clan I (n) is the set of nodes that are inherited from n and n itself. Denition 2.11 (clan morphism). [Ehrig et al., 2006] Given a type graph T = (G T, I), and a graph H, a clan morphism type : H T consists of two functions type N : N H N GT, type E : E H E GT such that (i) e E H : type N s H (e) clan I (s GT type E (e)), and (ii) e E H : type N t H (e) clan I (t GT type E (e)). Denition 2.12 (Instance graph of a type graph with inheritance). [Ehrig et al., 2006] Given a type graph (with inheritance) T, a double (G, type) of a graph G along with a clan morphism type : G T is called an instance of T. G is also said to be typed over T. Denition 2.13 (typed morphism). [Ehrig et al., 2006] Given type graph T and two instance graphs (G 1, type 1 ), (G 2, type 2 ), a graph morphism f : G 1 G 2 is a graph morphism typed over T if type 2 f = type 1. Theorem 2.14 (category Graph TG ). [Ehrig et al., 2006] Typed graphs over a type graph (with inheritance) and typed graph morphisms form the category Graph TG.

21 Chapter 2. Background Algebraic graph transformation The algebraic graph transformation approach has been invented to generalize Chomsky grammars from strings to graphs [Ehrig et al., 1973]. The main idea behind the approach is to use the similarities of string concatenation and gluing construction of graphs. Based on these similarities, graph rewriting steps can be formulated by one or two gluing constructions. The transformation approach [Ehrig, 1979a] [Ehrig, 1986] is referred to as algebraic, because the underlying graphs are handled as algebraic constructions and gluing is dened by pushout in the category of graphs and total graph morphisms. There are two main branches of algebraic graph rewriting, namely the double pushout (DPO) [Rozenberg, 1997] and the single pushout (SPO) [Ehrig et al., 1999b] approaches. In the following, we introduce the essential denitions and operations of algebraic graph transformation. Graph transformations consist of rewriting rules, also referred to as productions containing a left-hand side (LHS) and a right-hand side (RHS) graphs. Denition 2.15 (graph production). A typed graph production, or "production" for short, p = (L l K r R) consists of typed graphs L, K, R and injective typed graph morphisms l : K L and r : K R. Denition 2.16 (Match). The match m of graph L in the host graph G is an injective morphism m : L G. Namely a match denes a subgraph isomorphic to L in G. When applying the production, the pattern dened in LHS is matched against the host graph forming a match, also referred to as the redex of the production rule. Then, this pattern is replaced by the pattern dened in the RHS. There are two well-accepted ways to replace the matched pattern with the pattern dened in the RHS. The rst (referred to as gluing approach) applies the replacement by gluing RHS model items to the common vertices. The other approach (connecting approach) adds edges to the disjoint union of the context graph and RHS. To specify the placement of these additional edges, embedding rules are accompanied with the rewriting rule [Janssens and Rozenberg, 1980]. This second approach is not as popular as the rst one, because it cannot specify rules like containing all outgoing edges of a node. Using category theory in describing graph transformation results in a compact yet precise denition of the approach. Most of the results and constructs can be easily reused by extending the original underlying structures. This exibility is exploited for example in case of High-Level Replacement Systems [Ehrig et al., 1994]. Denition 2.17 (direct graph transformation). Given a production p = (L l K r R) and a typed graph G with a typed graph morphism m : L G, a direct typed graph transformation or graph transformation for short, G p,m H from G to a typed graph H is given by the a double pushout (DP O) diagram in Figure 2.2, where (1) and (2) are pushouts. The context graph D is obtained from the host graph G by deleting all elements, which have pre-image in L but not in K. Then, items are added (glued), which are included in R without having pre-image in K. In the DPO approach, the match m must satisfy the gluing condition consisting two parts: The identication condition states that dierent vertices in the rewriting rule cannot match the same vertex in the host graph on deletion. The dangling edge condition requires that if the rule species the deletion of a vertex, then it must delete all edges connected to the vertex as well. Related to the DPO approach, tutorials can be found in

22 Chapter 2. Background 10 L l K r R m (1) k (2) n G f D g H Figure 2.2. Direct graph transformation with double pushout [Ehrig, 1979b] [Ehrig, 1986] [Ehrig et al., 1991] [Corradini et al., 1993] and a more complete summary in [Ehrig et al., 1999a] [Rozenberg, 1997]. Denition 2.18 (graph transformation system). A graph transformation system GT S = (P ) consists of a set of graph production rules P. Denition 2.19 (input/output models). Assume that a T transformation is applied on a typed G host graph. We refer to G as the input model of the T transformation. Those elements that are created by the transformation together are called as the output model. In the following, we denote the output model of the transformation T applied to the G input model as Output T (G). Since we transform graphs with attributes, instead of graph productions, we use typed attributed graph productions. These productions consist of graphs attributed over a term algebra T DSIG (X) with variables X [Ehrig et al., 2006]. Denition An E-graph EG = (V G, V D, E G, E NA, E EA, (src j, tar j ) j {G,NA, EA}) consists of graph and data nodes V G and V D, and graph, node attribute and edge attribute edges E G, E NA and E EA, respectively. The domains and codomains of the source and target functions src j and tar j for the corresponding edges E j are depicted below. V G src NA src G tar G E G src EA E NA tar NA E EA tar EA V D Given a signature DSIG = (S, OP ) with attribute value sorts S D S, an attributed graph AG = (EG, D) is an E-graph EG together with a DSIG-algebra D such that V D = D s. s S D Given an attributed graph T G as type graph, a (typed attributed) graph G = (AG, t) is an attributed graph AG together with a typing morphism t : AG T G. Typed attributed graphs and the corresponding morphisms form the category AGraph ATG. Denition 2.21 (typed, attributed graph production). Given an attributed type graph AT G with a data signature DSIG. A typed, attributed graph production p = (L l K r R) consists of typed attributed graphs L, K, R with a common DSIG-algebra T DSIG (X). Also, the morphisms l and r are injective. A production p = (L l K r R) is applicable to a typed attributed graph G via the match m if there is a context graph D such that (1) is a pushout.

23 Chapter 2. Background 11 L l K r R m G (1) f k D Denition 2.22 (sequential independence). Two direct graph transformations G p 1,m 1 H p 2,m 2 G are sequentially independent, if there are morphisms e : R 1 D 2 and f : L 2 D 1 such that f 2 e = n 1 and g 1 f = m 2 : L 1 l K 1 r 1 1 R 1 L 2 l 2 K 2 r 2 R 2 m 1 k 1 n 1 m 2 e f k 2 n 2 f 1 f 2 g 2 G G D g 1 1 H D 2 This means that p 1 and p 2 are sequentially independent if they may be swapped, i.e. if p 2 can be applied to G, and p 1 to the resulting graph. Therefore p 2 at match m 2 cannot delete anything that has been explicitly preserved by the application of p 1 at match m 1, and, moreover, it cannot use (neither consuming nor preserving it) any element generated by p 1 ; this implies that the overlapping of R 1 and L 2 in H 1 must be included in the intersection of the interface graphs K 1 and K Concurrency Theorem The Concurrency Theorem [Ehrig et al., 2006] handles graph transformations that may be sequentially dependent. Using an E-concurrent production p 1 E p 2 it is possible to apply the productions concurrently. l Denition E-dependency relation Given two productions p 1 = (L 1 r 1 1 K1 R1 ) and l p 2 = (L 2 r 2 2 K2 R2 ), an E-dependency relation (E, e 1, e 2 ) is given by a graph E and injective morphisms e 1 : R 1 E, e 2 : L 2 E, which are jointly surjective. l Denition E-dependency production Given two productions p 1 = (L 1 r 1 1 K1 l R 1 ) and p 2 = (L 2 r 2 2 K2 R2 ), the E-concurrent production p 1 E p 2 is a production p = (L l K r R) computed based on the following diagram, where double squares (1)(2) and (3)(4) form double pushouts, and (5) is a pullback. Note that the injectivity of e 1 and e 2 implies that of k 1, m 1, k 2, and n 2. L 1 m 1 l 1 (1) K 1 k 1 r 1 (2) R 1 e 1 L l K 1 E k (5) l 1 K L 2 l 2 K 2 r 2 R 2 e 2 (3) k 2 (4) n 2 K 2 r R k 2 r Figure 2.3. E-dependency production This denition can be applied recursively, using an E-concurrent production for p 1.

24 Chapter 2. Background 12 Denition E-related transformation A transformation G p 1,m 1 H p 2,m 2 G is called E- related to p 1 E p 2 if there are morphisms h : E H 1, c 1 : K 1 D 1 and c 2 : K 2 D 2 such that h e 1 = n 1, h e 2 = m 2, (6) and (7) commute and (8) and (9) are pushouts. L 1 m 1 l 1 K 1 k 1 (6)K 1 c 1 r 1 R 1 (8) e 1 n 1 L 2 e 2 E m1 h l 2 K 2 k 2 K (7) 2 r 2 R 2 n 2 (9) c 2 G G D 1 H D 2 Figure 2.4. E-related transformation Using the denition above, an algorithm can be constructed to compute E-concurrent productions. Algorithm 2.1 Rule composition 1: Find an E-dependency relation (E, e 1, e 2 ). 2: Compute the pushout complement K 1 that makes (2) a pushout, otherwise go to Step 1. 3: Compute the pushout object L that makes (1) a pushout. 4: Compute the pushout complement K 2 that makes (3) a pushout, otherwise go to Step 1. 5: Compute the pushout object R that makes (4) a pushout. 6: Compute the pullback object K that makes (5) a pullback. Proposition 2.26 (Concurrency Theorem). Let (E, e 1, e 2 ) be an E-dependency relation for the productions p 1 and p 2 leading to the E-concurrent production p 1 E p Synthesis: Given an E-related transformation sequence G H G via p 1 and p 2, then there is a synthesis construction leading to a direct transformation G G via p 1 E p Analysis: Given a direct transformation G G via p 1 E p 2, then there is an analysis construction leading to an E-related transformation G H G via p 1 and p Bijective correspondence: The synthesis and analysis constructions are inverse to each other up to isomorphism. G p 1 H p 2 p 1 E p 2 G Figure 2.5. Concurrency Theorem

25 Chapter 2. Background Computational completeness of graph transformation Habel at al. [Habel and Plump, 2001] have proved that graph transformation of labeled graphs is Turing-complete [Weihrauch, 1987], and provided a construction to represent every computable graph function with graph rewriting rules. Here, we shortly summarize the basic denitions and the main result of their research. Denition Let's denote G R H a nondeterministic relation if exists G r,m H direct graph transformation, where r = (L K R) R and m : L G is a match. Denition 2.28 (Program). Programs over a label alphabet C are inductively dened as follows: (1) Every nite set of R of rules over C is a program. (2) If P 1 and P 2 are programs, then P 1 ; P 2 is a program. (3) If P is a program occording to (1) and (2), then P is a program. Programs according to (1) are elementary, the program P 1 ; P 2 is the sequential composition of P 1 and P 2 and P is the iteration of P. Denition 2.29 (Semantics of programs). Given a program P over a label alphabet C, the semantics of P is a binary relation P on A C which is inductively dened as follows: (1) P = P if P is an elementary program R. (2) P1 ;P 2 = P1 P2. (3) P = { G, H G P H and I A C such that H P I ( P closure of P ). denotes the reexive transitive Theorem 2.30 (Computational completeness of graph transformation). For every computable partial function f : A C1 A C2, there is a program that computes it. [Habel and Plump, 2001] Graph transformation in the Visual Modeling and Transformation System In the VMTS Transformation Framework (VTF), the LHS and the RHS of the production rules are not separated. They are dened in the same transformation model and the role of the elements (i.e. matched or deleted for elements in the LHS; and created for the RHS) is specied with the Action attribute of the rule items: (i) an element x of the LHS graph which element is not deleted in the RHS graph is marked as x.action = match, (ii) elements created by the RHS graph are marked as x.action = create and (iii) elements deleted by the RHS graph are marked as x.action = delete. Formally, the topology of a p = (L l K r R) rewriting rule in VMTS is dened by the P V pushout object of l and r: K r R l n L m P V

26 Chapter 2. Background 14 If we denote the range of an x morphism as R x, then the elements matched by R m R n are not deleted. Elements matched by R m \R n are deleted and a subgraph isomorphic to subpattern R n \R m is created by the rule. In VMTS, one can attach textual constraints to the production rules as well. A graph production can be applied if the match of the rule satises the constraints. The application of additional conditions is formalized in Denition Denition 2.31 (typed, attributed graph production with constraints). Given an attributed type graph AT G with a data signature DSIG. A typed, attributed graph production with constraints p = (L l K r R, X ) consists of a typed, attributed graph production and a set of constraints X. Also, we have injective l, r. A production p = (L l K r R, X ) is applicable to a typed, attributed graph G via the match m if there is a context graph D such that (1) is a pushout and m satises constraints X, i.e. m = X. L l K r R m G (1) f k D In our implementation the set of constraints X is expressed using the Object Constraint Language (OCL, [OMG, 2006]). With OCL, we can describe both structural constraints and conditions on the attributes of the matched elements. Production rules in VMTS [Asztalos and Madari, 2009] do not use the abstract syntax of the host model but a custom DSML to be dened. The type of the model element created/matched by a rule element is dened by the T argett ypes attribute of the rule element. As it is allowed to specify multiple possible types for a single rule element to be matched, the T argett ypes attribute can hold more than one type identier as well. The execution sequence of rewriting rules in VMTS can be dened using a control ow language[asztalos and Madari, 2009]. With a control ow model, one can exactly dene the execution order of the individual rewriting rules. The metamodel of the VMTS Transformation Framework control ow language can be seen in Figure 2.6. We have the following elements in the metamodel: Figure 2.6. VTF control ow language metamodel The node Any serves as a base node for all other nodes in the control ow, it is abstract and cannot be instantiated.

27 Chapter 2. Background 15 The StartNode denes the entry point of a transformation control ow. In a control ow model, there must be exactly one entry point. The EndNode denes the exit point of a transformation control ow. The RuleContainer node represents the application of an already existing rule. FlowEdges dene the execution order of the rewriting rules. A RuleContainer node references the model of the rewriting rule that should be applied. There are three ways to apply a rule: first-fit, exhaustive and iterative. Denition 2.32 (rst-t execution of a production rule). Assume a host graph G and a production rule p : (L K R). p is executed in the rst-t manner on the G host graph, if p rule is applied on one arbitrary m : L G match, provided that m exists. First-t execution simply means that after applying a specic rule, the control ow proceeds to the next rule. Denition 2.33 (exhaustive execution of a production rule). Given a G host graph and a p : (L K R) production rule. p is executed in the exhaustive manner on the G host graph, if direct graph transformations with p production rule and arbitrary m i matches are applied until no further match can be found, i.e. G p,m 1 G 1 p,m 2... p,mn G n, and m n+1 : L G n. Iterative execution of a rule means that a rule is applied once for each element of an initial match set: a predened subpattern of the LHS matches an initial match from the set, and the transformation engine tries to extend this initial match to a complete one. Denition 2.34 (iterative execution of a production rule). Assume a host graph G, production rule p : (L K R), an L I subgraph with an i : L I L morphism and an M I = {m I : L I G} initial match set. The p production rule is executed iteratively on the M I initial match set, if it is applied for each m I M I initial match on an arbitrary m : L G match for that m i = m I (provided that m). VMTS supports iterative execution only for a single item at the moment: using the IteratedElement attribute of the rule container one can select an element of the rewriting rule, and the rule is executed in the rst t manner for each possible item for the selected element. FlowEdges have three attributes. (i) The Guard attribute denes a guard condition that must be evaluated to true to follow an edge and then (ii) the imperative code described by the Code attribute is executed as well. (iii) By using the Success attribute we can add further constraints to the application of an edge: if Success is set to true, the edge is only followed, if the preceding rule has been successfully applied; if it is set to false, the edge is followed only if the preceding rule had no matches. By default, the attribute is not set, meaning that the edge is followed unconditionally. After the execution of a node, the execution engine selects one of the outgoing edges to be followed. If there are multiple possible edges to be followed, one is selected nondeterministically. In the model itself, we can dene global variables of primitive types (numeric and textual) and model element types; these variables can be used by both the constraints and the imperative code of the rewriting rules, as well as by the guard expressions of the ow edges. Figure 2.7 illustrates an example transformation denition in VMTS. The control ow model contains a start node, an end node and a RuleContainer element referencing the Sample_Rule

28 Chapter 2. Background 16 Figure 2.7. An example VMTS transformation denition rule. The icon in the upper right corner of the container denotes that the referenced rule is executed exhaustively. The Sample_Rule rule matches two nodes of type P ort connected with an arbitrary edge, and deletes that edge. Consequently, by executing the transformation on an appropriate host model, the rule deletes all the edges connecting two ports. 2.4 Abstract State Machines Abstract State Machines (ASMs) formerly known as evolving algebras have been introduced by Yuri Gurevich [Böerger and Stärk, 2003] as an attempt to bridge the gap between formal models of computation and practical specication methods. The main idea behind ASMs is that any algorithm can be modeled at its natural abstraction level by an appropriate evolving algebra. Built upon this idea, a methodology based upon mathematics was dened. The result is a simple methodology for describing simple abstract machines that correspond to the algorithms. According to [Abstract State Machines, 2010], ASMs have been used in many applications such as formalizing model transformations [Varró, 2004b], the semantics of the C++ language [Wallace, 1995], the Java Virtual machine [Stärk et al., 2001], or the UML Statechart diagram [Compton et al., 2000] An overview of ASM ASMs are nite sets of transition rules of the form if Condition then U pdates, which transform abstract states, where Condition (referred to as guard) under which a rule is applied is an arbitrary predicate logic formula without free variables. The formula of Condition evaluates to true or false. Updates is a nite set of assignments in the form of f(t 1,..., t n ) := t, whose execution is understood as changing (or dening, if there was not dened before) the value of the occurring function f at the given arguments. Each function of an ASM has a xed arity, which is a non-negative integer. Nullary functions are called constants, however they can change their values, thus, they are handled more similarly to variables of a programming language. By denition, all ASMs contains certain nullary function names (true, false, undef), as well as the names of the usual Boolean operations and the equality sign. The notion of ASM states is the classical notion of mathematical structures where data is represented as abstract objects, i.e., as elements of sets (domains, universes, one for each category of data) which are equipped with basic operations (partial functions) and predicates (attributes or relations). Without loss of generality, one can treat predicates as characteristic functions.

29 Chapter 2. Background 17 The notion of an ASM run is the classical notion of computation in transition systems. An ASM computation step in a given state consists of executing simultaneously all updates of all transition rules whose guard is true in the state, if these updates are consistent. Therefore, transition rules describe how states of an ASM change over time. A set of updates is called consistent if it contains no pair of updates with the same location, but with dierent results. If we would like to perform the P and Q state transitions sequentially, we must explicitly dene it by P seq Q For the evaluation of terms and formulas in an ASM state, the standard interpretation of function symbols by the corresponding functions in that state is used. Simultaneous execution provides a convenient way to abstract from irrelevant sequentiality and to make use of synchronous parallelism. This mechanism is enhanced by the following concise notation for the simultaneous execution of an ASM transition rule R for each x satisfying a given condition ϕ: forall x with ϕ R, where ϕ is a Boolean-valued expression and R is a rule. Similarly, non-determinism as a convenient way to abstract from details of scheduling of rule executions can be expressed by rules of the form choose x with ϕ R, The meaning of such an ASM rule is to execute rule R with an arbitrary x chosen among those satisfying the selection property ϕ. If there exists no such x, nothing is done. We freely use abbreviations, such as where, let, if then else, case and similar standard notations which are easily reducible to the basic denitions above [Böerger and Stärk, 2003]. A priori no restriction is imposed either on the abstraction level or on the complexity or on the means of the function denitions used to compute the arguments and the new value denoted by t i, t in function updates. The major distinction made in this connection for a given ASM M is that between static functions which never change during any run of M and dynamic ones that typically do change as a consequence of updates by M or by the environment. The dynamic functions are further divided into four subclasses. Controlled functions are dynamic functions which can directly be updated by and only by the rules of M. Monitored functions are dynamic functions which can directly be updated by and only by the environment. Interaction or shared functions are dynamic functions which can directly updated by rules of M and by the environment. Derived functions are functions which cannot be directly updated either by M or by the environment, they inherit the properties of the functions they are dened with Mathematical Denition of ASM In an ASM state, data is available as abstract elements of domains which are equipped with basic operations represented by functions. Without loss of generality, relations are treated as Booleanvalued functions and view domains as characteristic functions, dened on the superuniverse which represents the union of all domains. Denition 2.35 (Vocabulary). A vocabulary (signature) Σ is a nite collection of function names. Each function name f has an arity, which is a non-negative integer. The arity of a function name is the number of arguments that the function takes. Function names can be

30 Chapter 2. Background 18 static or dynamic. Nullary function names are often called constants; but the interpretation of dynamic nullary functions can change from one state to the next, such that they correspond to the variables of programming. Every ASM vocabulary is assumed to contain the static constants undef, True and False. Example The signature Σ bool of Boolean algebras contains two constants 0 and 1, a unary function name '-' and two binary function name '+' and '*'. Denition 2.37 (State, Superuniverse). A state A of the vocabulary Σ is a non-empty set X, together with the interpretations of the function names of Σ, where X means the superuniverse of A. If f is an n-ary function name of Σ, then its interpretation f A is a function from X n into X; if c is a constant of Σ, then its interpretation c A is an element of X. The superuniverse X of the state A is denoted by A. The elements of the state are the elements of the superuniverse of the state, and according to the denition the parameters of the functions are also elements of the superuniverse. If, for example, an ASM formalizes a graph rewriting technique, then the superuniverse is the set of IDs of all potential model elements as used in [Varró, 2004b]. Denition 2.38 (Sequential abstract state machine). A sequential abstract state machine M consists of a vocabulary Σ, an initial state A for Σ, a rule denition for each rule name, and a distinguished rule name called the main rule name of the machine. More information on the mathematical representation and the notation of ASMs can be found in [Böerger and Stärk, 2003]. 2.5 Bisimulation Bisimulation [Milner, 1971, Park, 1981] is generally considered one of the most important contributions of Concurrency Theory to Computer Science. In concurrency, the bisimulation equality, called bisimilarity, is the most studied form of behavioral equality for processes and is widely used [Sangiorgi, 2009]. Intuitively, bisimulation is a binary relation between the states of two state transition systems that associates the states of the two systems so that they match each other's moves. If two systems are bisimilar the one system can simulate the other and vica versa, they cannot be distinguished by an external observer. Here, we present the basic denitions related to bisimulation. Denition 2.39 (Labeled Transition System). A Labeled Transition System (LTS) is a triple (W, Act, ) µ with W set of states, set of labels Act, and µ set of relations where = µ { : a W a W, a Act} for each label a. is called the transition relation. We write s µ t when (s, t). µ Denition 2.40 (Bisimulation). A binary relation R on the states (S) of a Labeled Transition System (LTS) is a bisimulation if whenever s 1 Rs 2 (s 1, s 2 S): for all s 1 with s 1 µ s 1, there is s 2 such that s 2 µ s 2 and s 1Rs 2; the converse, on the transitions emanating from s 2. Denition 2.41 (Bisimilarity). Two Labeled Transition Systems (L 1, L 2 ) with state sets S 1, S 2 are bisimilar, if exists R (S 1 S 2 ) binary relation that is a bisimulation.

31 Chapter 2. Background Simulation Systems In this section, we present two basic simulation systems: the Discrete Event System Specication (DEVS) [Zeigler et al., 2000, Concepcion and Zeigler, 1988] and the Discrete Time System Specication (DTSS) [Zeigler et al., 2000]. We use them to express the expression power of modeling languages and their operational semantics Classic DEVS System Specication A Discrete Event System Specication is a structure M = X, S, Y, δ int, δ ext, λ, ta where X is the set of input values, S is the set of states, Y is the set of output values, δ int : S S is the internal transition function, δ ext : Q X S is the external transition function, where Q = {(s, e) s S, 0 e ta(s)} is the total state set, e is the time elapsed since last transition, λ : S Y is the output function, ta : S R + 0, is the set positive reals with 0 and. At any time the system is in a certain state s. If no external event occurs, the system will stay in state s for time ta(s). Notice that ta(s) could be a real number as one would expect. But it can also take the values 0 and. In the rst case, the time spent in a state s is so short that no external event can intervene we say that s is a transitory state. In the second case, the system will stay in s forever, unless an external event interrupts its slumber. We say thats is a passive state in this case. When the resting time expires, i.e., when the elapsed time, e = ta(s), the system outputs the value λ(s), and changes to the state δ int (s). Note that output is only possible immediately before internal transitions. If an external event x X occurs before this expiration time, i.e., when the system is in total state (s, e) with e ta(s), the system changes to the state δ ext (s, e, x). The internal transition function dictates the new state of the system when no events occurred since the last transition. The external transition function dictates the new state of the system when an external event occurs this state is determined by the input (x), the current state (s), and how long the system has been in this state (e). In both cases, the system is in some new state s with some new resting time ta(s ), and the same conditions apply again Discrete Time System Specication A Discrete Time System Specication is a structure DT SS = X, Y, Q, δ, λ, c where X is the set of input values Y is the set of output values Q is the set of states

32 Chapter 2. Background 20 δ : Q X Q is the state transition function λ : Q Y (Moore-type) or λ : Q X Y (Mealy-type) is the output function c is a constant employed for the specication of the time base c J. The system is in a state q at a time t 1. It remains in the state q for time c. At the time t 1 + c it changes to the state q = δ(s, x) and outputs the value λ(q ) (Moore-type) or λ(q, x) (Mealy type). The same procedure repeats with time period c. With the help of DTSS, one can simulate any continuous system with an arbitrary small error. [Zeigler et al., 2000].

33 Chapter 3 Dening the dynamic behavior of metamodeled languages 3.1 Introduction There are well-known techniques (e.g. [Mezei et al., 2006, de Lara and Vangheluwe, 2002, Lédeczi et al., 2001]) to dene the abstract and concrete syntax of visual languages. However, it is often necessary to dene the visual behavior of a language as well. A typical example for that is the animation of the model, which means changing model properties and visualization over the time. For example, animating a model transformation denition by tracing the execution of the transformation or to animate user interface models by illustrating dierent workows. Recent solutions usually achieve animation by hard-coded solutions or binding visualization properties to model properties and performing model transformation on the host model. Hard-coded solutions need deep knowledge about the underlying API of the modeling environment and are hard to modify, while model transformation-based solutions usually lack the possibility to interact with their environment. In this thesis, we provide a model-based solution for this problem: we support the denition of the visual behavior and the interaction with the environment with domain-specic modeling languages. 3.2 Related work The system that mostly inuenced our approach is AToM 3 [de Lara and Vangheluwe, 2002], which is a general purpose metamodeling environment with simulation and model animation features. AToM 3 models can be animated either by handling predened events or by model transformation. Visual elements provide several events (e.g CREATE, CONNECT, MOVE) that can be handled by implementing their handlers in Python. Using this approach, one can dene the dynamic behavior of model elements. Event handlers are dened in the metamodels. An event handler overrides the handlers of the possible parent element in the inheritance hierarchy of the metamodel, thus, the inherited handler is executed in case of a missing child level implementation. Another possibility in AToM 3 for model animation is executing graph transformation on the model and updating the visualization based on the modications performed by the transformation. Note that graph transformations can also be executed as a response to the previously mentioned events. AToM 3 provides a visual designer to build graph rewriting

34 Chapter 3. Defining the dynamic behavior of metamodeled languages 22 based transformations. AToM 3 also supports user interface modeling to a certain extent: custom toolbars can be attached to metamodels; the toolbars are visible if an instance of the metamodel is edited. The buttons of the toolbar are modeled, their event handler methods are implemented in Python. The main drawback of the AToM 3 approach is that it can react to only a small predened set of user events, and cannot process events simultaneously. Custom events are not supported. It does not support the modeling of the animation logic either, it can be dened with direct API programming. The integration of external components or simulation frameworks is supported on language level by Python. Ptolemy II [Brooks et al., 2008, T et al., 2003, Eker et al., 2003] is a modeling and simulation environment with a history of more than ten years. It provides numerous predened models of computation to create the models in, including, but not limited to Discrete Event, Continuous Time, Distributed Discrete Event, Finite State Machine, and Process Networks. The strength of Ptolemy is that models created in dierent domains can be integrated in a hierarchical way. Most domains in Ptolemy II (except for the FSM domain) have a data-ow characteristic. The results of a simulation can be visualized on plotters of several types. Plotters are controls that can visualize data in various formats including continuous and discrete diagrams as well as textual controls. The content of plotters is updated implicitly based on the values received on its input ports. Ptolemy II provides a exible simulation framework for a wide range of domains and their combinations, however, the animation of the models must be written manually. The base elements of Ptolemy models are the actors. Actors are communicating, concurrently executed components. Actors can also be implemented in JAVA by subclassing an existing actor class instead of modeling, thus, they can embed arbitrary components and provide their services through the unied interface of actors. MATLAB/Simulink [MATHWORKS, 2010] is a complex modeling and simulation environment which also facilitates the combination of models from dierent domains. Most Simulink domains are based on either continuous or discrete time dataow languages. MATLAB models can be animated using proprietary textual language. All the graphical elements in MATLAB have a handle, which can be used to reference the owner element. The properties of the referenced objects can be changed through the MATLAB API. The visualization of the elements is updated automatically on changing the model properties. Similarly to AToM 3, nodes (blocks) in Simulink models also provide a predened set of editing events, which can be handled by writing Callback Routines using the MATLAB Programming Language. The result of model simulations is usually visualized with the help of plotters (similar approach to the one presented in connection with Ptolemy II). However, MATLAB plotters have to be updated explicitly through the API when the underlying data changes, there is no built-in notication support. MATLAB does not support the visual denition of model animations; furthermore, automatic change notication is not provided in all cases either. The MATLAB Programming Language also provides basic constructs to load and invoke methods of external components (binary libraries, and Windows COM components). MetaEdit+ [Tolvanen, 2006] is a general purpose metamodeling tool. It supports model animation through its Web Service API. Model elements in MetaEdit+ can be animated by inserting API calls into the code generated from the model, or by modifying the code generator to automatically insert these calls. If the attributes of a model element are changed, its visualization is automatically updated. The update mechanism can be inuenced by constraints written in the proprietary textual script language of MetaEdit+. MetaEdit+ does not provide a graphical

35 Chapter 3. Defining the dynamic behavior of metamodeled languages 23 notation to dene animation or for the integration of external components, all these issues can be solved with API programming. The TIGER [Ehrig et al., 2005] (transformation-based generation of environments) tool generates visual editor plugins for Eclipse [Eclipse, 2010] from typed grammar-based visual language specications. The generated plugins are based on the Eclipse Graphical Editing Framework (GEF) [GEF, 2004], which is an open source infrastructure for creating and using graphical editors based on Eclipse. In contrast to VMTS Presentation Framework (VPF) [Mészáros et al., 2008b], the underlying architecture of GEF is the Model-View-Controller (MVC) [Buschmann et al., 1996] pattern. Both the manageable data (model) and the visualization (view) and the interaction features (controller) are separated into dierent classes. The model classes can be arbitrary Java classes (POJO), however, the controller classes should be derived from the common EditParts class. The visualization can be performed by an arbitrary Java class by following the restriction that it should implement a predened interface ( IF igure). GEF itself does not support automatic change-notication services, due to the underlying arbitrary model object. Notication support for model property changes is provided by the Eclipse Modeling Framework (EMF) [Budinsky et al., 2003] which is used by Tiger to dene the model layer of the MVC pattern. Similarly to AToM 3, animation of models in TIGER can be achieved by performing graph transformation on the model, and due to the MVC architecture, the applied modications are also reected in the visualization. In contrast to VMTS, this approach requires the visualization properties to be modeled. TIGER provides visual modeling techniques to dene graph transformation rules, and uses AGG (Attributed Graph Grammar System) [Taentzer, 2004] to execute algebraic graph transformations. Graphical Modeling Framework [GMF, 2010] (GMF) is also an Eclipse project, and it utilizes GEF. Compared to GEF, GMF uses the EMF models as the underlying model object by default. EMF facilitates the serialization of models in various formats and the change notication mechanism is also a built-in feature. The editor environments in GMF are generated. The code generation is based on four models: (i) the EMF model (domain model) which serves as the model of the visual language; (ii) the Graphical Denition Model that denes the visualization of each model element; (iii) the Tooling Denition Model, which describes the additional visual elements required for the user interface (including editor palettes, menus), and (iv) the Mapping Denition Model, which realizes the mapping between the domain model and the visual models. The creation of models (ii)-(iv) and the generation of the editor from the input models is supported by the GMF Dashboard wizard. However, this tool provides very basic features only in dening visual models. Complex visualization requires to be dened using Java. The Generic Modeling Environment (GME) [Lédeczi et al., 2001] is a general purpose metamodeling and program synthesis environment. GME provides two ways to animate models: (i) with the help of executing graph rewriting-based model transformations or (ii) by transforming models with custom traversing processors. Both approaches build on the fact that on updating model elements in the object space (MGAMultiGraph Architecture) of GME, the presentation layer is notied about the changes and the visualization of elements also updates. The GReAT toolkit [Vizhányó et al., 2004] of GME is used to model graph rewriting-based transformations in a visual way and to execute the transformations. GReAT uses the UDM (Universal Data Model) data access layer over MGA to manipulate model elements. MGA is responsible for notifying subscribed components about changes. In addition to visually modeled transformations, arbitrary transformation can be implemented by hand using the UDM and the BON (Builder Object Network) interfaces. The graph transformation-based approach of GME to animate models is

36 Chapter 3. Defining the dynamic behavior of metamodeled languages 24 similar to the one presented in connection with AToM 3 and TIGER, but similarly to TIGER GME does not support modeling user interactions. The visual modeling of animations is limited to the description of a closed graph rewriting algorithm. The visual modeling of adapting external components to GME is also not supported. DiaMeta [Minas, 2006] is a framework for generating graphical diagram editors. It uses hypergraph grammars to specify visual languages. Editors generated with DiaMeta are capable of running online structural and syntactic analysis on the edited models. DiaMeta also employes EMF to dene visual languages. Thus, it provides a similar approach to the one presented in connection with TIGER: change notication events are generated by the underlying EMF model on attribute changes, and the generated view and controller objects update the visualization as response to these events. In contrast with TIGER, DiaMeta uses custom classes for model visualization instead of utilizing GEF. The dynamic metamodeling approach [Engels et al., 2000] denes the operational semantics of behavioral UML diagrams by extending them with UML collaboration diagrams. Collaboration diagrams are used as elementary deduction rules for a domain-specic interpreter. They are executed as graph transformation rules thus facilitating the formal analysis of the described semantics. 3.3 Problem statement The motivation of our work was to provide an integrated solution to describe the dynamic behavior of the models in a generic and visual way. In order to prepare a metamodeling environment to animate visual models, we have outlined the following requirements: A simple, easy-to-use DSML that is capable of describing the dynamic behavior of visual languages. Because of the possibly complex DSMLs, it is important to separate the description of the dynamic behavior from the denition of the abstract and concrete syntax. Formal description of the language to facilitate formulating precise and exact propositions about the language. We expect the language and the framework to be adaptable to any discrete event system and to be able to describe at least quantized simulations (Discrete Time Specied Systems (DTSS) [Zeigler et al., 2000] domain). Automated mechanisms to generate source code from the behavioral models, thus, we can execute the animation models. Proof of the fact that the generated code and the input model are semantically equivalent (i.e. the executable code is correct). The language should provide a possibility to integrate external simulation engines (e.g. MATLAB).

37 Initialize ProcessNextCFEdge ProcessStartNode Matching ApplyCurrentMatch ApplyInternalCausalities ApplyInternalCausality AgsiCFEdge EH_GT PortGT InternalCausalityResult AgsiCFEndNode TrafoOutputPlaces AgsiInternalCausality IAgsiCFNode AgsiRuleExecutionResults. Initialized PreNextCFEdge PostNextCFEdge PreStartNode PostStartNode PreDecision PreEndNode PreRuleNode PreInitMatch PreMatching PreApplyMultipleMatch PreApplyCurrentMatch PreInternalCausalities PreInternalCausality PostInternalCausality PostInternalCausalities PostApplyCurrentMatch PostApplyMultipleMatch PostRuleNode PNAnimator PortModels PortViews PortPN PortTimer PortPN PortTimer PortViews PortModels GetDiagramView PortViews:UnHighlight PortPN:EventFire Default Firing [PortTimer:Tick] [PortTimer:Tick] Selecting GettingView Highlighting PortPN:EventGetFireableTransition [fireable transition] PortViews:EventGetView [PortViews:EventGetView_] PortViews:EventHighlight [no fireable transitions]. Chapter 3. Defining the dynamic behavior of metamodeled languages The VMTS Animation Framework As a result of our work, we provide an integrated solution called VMTS Animation Framework (VAF) for model and user interface animation, embedded in the VMTS modeling environment. The strength of our approach lies in the fact that we support the denition of animations with visual languages on both the low-level event denition and on the high-level animation description Architecture We have designed three visual languages to model the animation of the models and the user interface. Figure 3.1 summarizes the languages of the animation framework and their application. ENVIRONMENT Domain knowledge and simulation engines Event handler implementation gen. ref. Event handler model High level animation model EH_UI ( ) PortViews PortModels EH_Timer ( ) EH_PetriNet ( ) PortTimer PortPN Animator state machine Animation engine Animated model Figure 3.1. Overview of the animation languages The animation logic can be described with a state machine (called Animator in our terminology) that communicates via events (Animator state machine block). The environment of the state machine (referred to as ENVIRONMENT in the gure) including the user interface (VPF), the modeling space, and the domain-specic extensions are also wrapped with event-based interfaces, called event handlers (Event handler model ). By domain-specic extensions, we mean any component that realizes domain-specic simulation logic. Examples for this component are simulation engines (e.g. MATLAB) and other services such as the Runge-Kutta methods [Runge, 1895, Kutta, 1901] for solving ordinary dierential equations or the algorithm of performing algebraic graph transformation. Event handlers convert the events of the environment to modeled events, thus providing the input for the animation. An event handler model denes the events the handler can interpret and their parameters (entities). The default implementation of an event handler can be generated, but the handler methods of the specic events must be implemented manually (Event handler implementation block). The event handlers and the state machines can be connected in a high-level model (High level animation model ). The communication between components is established through ports. The source code generated from the animation model at runtime relies on a proprietary DEVS-based (Discrete Event System Specication) [25] simulation framework that schedules and processes events in a deterministic order.

38 Chapter 3. Defining the dynamic behavior of metamodeled languages Events and event handlers The focus of our approach is on the events. Events are the exclusive facilities to keep the connection between the animation engine and its environment, including both the user interface and the underlying model. Events are generated when interacting with the user interface (e.g. pressing a mouse button), and they are also used to establish a connection between the animation engine and the domain-specic extension components for dening model semantics. Events can be either built-in already provided by the animation framework or custom. The animation logic can be described using a graphical extended nite state machine formalism (Section 3.4.3). The inputs and the outputs of the state machine are events. Event handlers dene the connection point between the animation logic and its environment. The purpose of event handlers is to wrap the environment of the animation logic into an event-based interface. The methods and properties of the wrapped object are hidden, and can be reached only through events. The event handlers and the events that they can interpret are tightly related. The denition of events and event handlers is supported by a visual language whose metamodel is depicted in Figure 3.2 EventHandler CodeBehind Parameter Port Handles Event Parameter OperatesOn Entity Parameter RealClass Figure 3.2. Event handler metamodel The meta-element of the event handler (EventHandler ) denes two attributes for its instances: CodeBehind and Parameter. The CodeBehind attribute is used to reference a binary class library (dll). This class library contains the implementation of event handler methods for the events of this handler, the event interpreter and the possible initialization and destruction methods. The skeleton of the CodeBehind le is automatically generated based on the event handler model; the developer only has to complete the body of the event handler methods. In case of wrapping external.net libraries with event handlers, the generation of the events and the wrapper code is automated by discovering the public interface of the component with the help of reection [Liberty, 2001]. Custom parameters can also be assigned to event handlers using the Parameter attribute. Event handler instance models can only dene the possible parameters and their default values but not their concrete values, as they are determined during a concrete application. For example, the Timer event handler res a Tick event periodically, after a specied time elapses. This interval is the parameter of the event handler, and its value is not known by the design time of the event handler, because it depends on its application. The Parameter attribute is a compound attribute, meaning that it has subelds: ParameterName, ParameterType and ParameterDefaultValue. In case of the Timer event handler, ParameterName is set to 'frequency', ParameterType is set to 'int', and ParameterDefaultValue is set to 500 (msec). The communication between the event handlers and the animation engine is port-based. Ports (the Port element in Figure 3.2) dene the connection points for an event handler: we have the possibility to dene several ports for the same event handler and to distinguish the handled events or the way in which we handle a specic event based on the receiver port. Ports and events (dened by the Event element) are coupled with the instances of the Handles edge. Events can be customized with the help of Entities. Entities are supposed to be the parameters of events. After the code

39 Chapter 3. Defining the dynamic behavior of metamodeled languages 27 generation, both entities and events are mapped to object-oriented (C# [Archer, 2001]) classes. The elds of the entity classes are modeled with the help of the Parameter attribute, which denes the name and the type of the referenced parameter. Instead of code generation, entities can also be bound to already existing types, which is useful if we have to interact with existing software components. Entities also support to be connected with other entities with the help of relations already known from UML class diagrams, including containment, generalization, and association. The generalization edge is mapped to class-level inheritance, while the association and containment edges result in the creation of member variables in the entities. Relations with many multiplicities are implemented with the help of generic lists. An entity can be assigned to an event with the OperatesOn edge. Entity references in an event are also implemented with member variables and generic lists. The name of the generated member variable matches the name of the OperatesOn edge instance An example: event handler model for the Petri-net domain An event handler instance model with a concrete syntax can be seen in Figure 3.3. The gure depicts an event handler for Petri-net [Murata, 1989] models. The event handler provides one port (called PortPN ) for sending and receiving events. EHPetriNet can handle four types of events, namely, EventGetEnabledTransition, EventFireTransition, EventGetEnabledTransition_, and EventFireTransition_. EventGetEnabledTransition is sent to the event handler to obtain a transition to be red from a specic Petri-net model. The subject model has a type of ModelDocument (a VPF entity representing the diagram, an already existing type in VPF), and is referenced with the PNModel edge. This edge is mapped to a member variable during code generation. During the processing phase of EventGetEnabledTransition events, the event handler nds the subject model for an enabled transition, and responds an EventGetEnabledTransition_ event parameterized by the transition found (it is of the type of the external NodeDocument that is the document component in the Document-View [Shepherd and Wingo, 1996] architecture for shapes in VPF). EventHandler Handles Port EH_PetriNet PortPN Event OperatesOn Entity EventGetEnabledTransition PNModel ModelDocument EventGetEnabledTransition_ Transition EventFireTransition Transition NodeDocument Transition EventFireTransition_ Figure 3.3. Petri-net event handler model The event handler is manually implemented in the CodeBehind le. This logic is considered to be the service of the environment as it must incorporate the special knowledge how Petri nets work. Similarly, the EventFireTransition event instructs the event handler to modify the container model of the referenced transition (Transition parameter) by ring the transition, and the event handler res an EventFireTransition_ event on the completion of this operation.

40 Chapter 3. Defining the dynamic behavior of metamodeled languages Animation description language We have designed another visual language for the denition of the animation logic. This language describes which event handlers to use during the animation, and what actions to perform after receiving a specic event. The animation description language is usually not intended to describe the simulation of a model in a specic domain the simulation business logic is more likely to be dened in an external component wrapped with an event handler. The animation description language is rather used to dene the transformation between events of the simulation business logic and the events of the user interface. The described intelligence converts complex simulation events into rudimentary user interface events or, on the contrary, collects events and propagates complex events towards the simulation business logic. However as we will show in Section 3.9 the language itself is also able to dene nite state DEVS and arbitrary DTSS simulations without external components. Figure 3.4 depicts the metamodel of the animation language. The language can be used to create state machines which can react to events and re new events. Recall that the state machine component is called Animator. Transition EventHandler Port Animator State Link Parameter Link Buffer Variables Action Timeout StartState StopState Figure 3.4. Metamodel of the animation language An animator may contain input and output ports (Port instances), which dene the interface of the animator. The ports in our approach are buers, which means that they may store a predened number of events until processing them. The Buer attribute denes the maximum length of the FIFO-based waiting queue. If the port is full, the incoming event is dropped. The applied event handlers are represented in the animation model as well. The EventHandler objects on this level provide a reference to event handlers modeled in the event handler models. The coupling between the reference and the modeled event handler is established using the Link attribute of the element reference. The Link attribute contains the unique identier of the event handler in the event handler model. Event handlers in the animation models also contain ports to facilitate bi-directional communication with them. Similarly to the event handlers, the ports contained by an event handler reference also serve as a reference to the real ports of the real event handler models: the Link attribute of the ports refers to the ports in the event handler model. Using the event handler references and ports in the animation models, we can create customized instances of the event handlers already modeled. The Parameter attributes of the event handler reference elements are automatically generated after selecting the referenced event handler model, based on the same attributes of the referenced element. With the help of the Parameter attributes of the event handler reference, we can customize the predened set of parameters of the event handler. The Parameter attribute denes the ParameterName and ParameterValue elds. The value of the ParameterValue eld is lled with a default value set in the ParameterDefaultValue eld of the original Parameter. Two ports (contained by either an event handler or an animator) can be connected by EventRoute edges. The existence of an EventRoute edge between two ports indicates that the outgoing events of the port on the left

41 Chapter 3. Defining the dynamic behavior of metamodeled languages 29 side of the edge are forwarded to the port on the right side. If the Direction property of the edge is set to BOTH, the events from the right side are also forwarded to the left. Animator Port PNAnimator PortModels PortViews PortPN PortTimer EH_UI ( ) PortModels EH_Timer ( ) PortTimer PortViews EventRoute EventHandler PortPN EH_PetriNet ( ) Figure 3.5. A high-level animation model In Figure 3.5, an animator and three event handlers can be seen. The user interface event handler (EH_UI ) and the timer event handler (EH_Timer) are provided by the framework, while the implementation of the domain-specic event handler (EH_Petrinet) is generated based on the model depicted in Figure 3.3, and the event handler methods are implemented manually. For example, the EH_Petrinet and PortPN model elements reference the elements with the same name in the model depicted in Figure 3.3. As the model in Figure 3.5 has an attribute reference to the underlying event handler implementation, the implementation can also be referenced from the code generated from the animation model. The ports of the animator and the event handlers are connected by EventRoute edges specifying exactly the way of the event streams. Recall that an animator element wraps a state machine. The most fundamental element of this state machine is the State node (instance of the State node ). The transition between two states is described by the Transition edges. There are two special types of states: the Start state and the Stop state. The state space of the state machine is dened not only by the contained state nodes: the animator may also have local variables (Variables attribute). Furthermore, the actual state of the ports also aects the number of possible states in the state machine. A Transition edge between two states denes a guard and an action expression (Guard and Action properties) in a textual language. The guard condition must be able to evaluate to a Boolean value. It may test the ports of the animator and its local variables. The guard conditions of the outgoing transitions of the actual state are tested every time a new event is enqueued in either port of an animator. If a guard condition can be satised, then the topmost events of all ports tested by the actual guard condition are removed. The contents of the non-tested ports are not modied, provided that they have a maximum possible buer size larger than 0. Ports with a buer of 0 length cannot store events: such ports are emptied even if no active transition has occurred. If a guard condition can be evaluated to true, the state transition is performed, and the next actual state will be the target state of the transition edge. When performing a state transition, the action expression of the transition edge is executed before removing the topmost element of the referenced ports. The action expression can contain three types of operations:

42 Chapter 3. Defining the dynamic behavior of metamodeled languages 30 the instantiation, customization and ring of an event on a specic port, or the manipulation of local variables, or the mixture of these operations. Each state has an Action property as well, which may contain program code similar to the code stored in the same attribute of the Transition edges. This code snippet is executed after running the Action script of the active Transition edge. The containment loop edge on the State node expresses the capability of building compound states. If a nested state does not have any transitions triggering the actual input, the transitions of the container state are veried, and if either of them can be red the control is taken from the nested state, and returned to the container state. PortPN PortTimer PortViews PortModels GetDiagramView Default [PortTimer:Tick] PortPN:EventGetEnabledTransition PortViews:UnHighlight Selecting [no enabled transitions] [enabled transition] PortViews:EventGetView PortPN:EventFire Firing [PortTimer:Tick] GettingView [PortViews:EventGetView_] PortViews:EventHighlight Highlighting Figure 3.6. Petri-net animator Figure 3.6 depicts an example animator which animates Petri-net models. The presented animator represents the internals of the animator depicted in Figure 3.5. In fact, the two gures visualize dierent aspects of the same model according to the metamodel illustrated in Figure The animation engine The animation model introduced in Section is transformed to executable source code using model transformations (Section 3.7). The events red by the animators and the event handlers are processed by a proprietary DEVS-based simulator. After ring events, they are enqueued into a global ordered event queue, and are processed in a synchronized way. Each event has a timestamp that represents the logical time to be processed at. This timestamp is used to keep the queue ordered. By default, the timestamp is set to the global animation time that equals to the timestamp of the last processed event. The timestamp of an event can be set to an arbitrary value after instantiating the event. If two events have the same timestamp, they are ordered based on a unique identier that is generated according the instantiation order. Events dened by event handler models can be considered external event s in the DEVS terminology. VAF also supports internal event s of DEVS: The TimeOut property of the State nodes denes a time interval: if there is not any enqueued event in the global event queue with a time stamp smaller than the current animation time increased by TimeOut, an internal event is red, and the global animation time is increased by TimeOut. Internal events are not enqueued in the ports of the animators, they only activate the animator, and instruct them to perform the transition whose IsInternal attribute is set to true. The presented state machine implementation provides a deterministic behavior in sense of producing always the same output event sequence for the same start state and input event sequence. However, the determinism of the entire animation also depends on the determinism of

43 Chapter 3. Defining the dynamic behavior of metamodeled languages 31 the adapted external components. In case of real-time events (including timer events and user inputs) the deterministic behavior is not necessarily guaranteed. 3.5 Operational Semantics of the Animation Models In this section, we formalize the operational semantics of the animation models with the Abstract State Machine formalism. This can be considered a "requirement specication" for the behavior of the models Universes Firstly, we dene the universes that are used by the rules and functions of the ASM describing the animation framework. Denition 3.1 (superuniverse of the animation framework). The superuniverse A of a state A of the animation framework is the union of the following universes: U int : Universe of integer numbers U real : Universe of real numbers U bool = {true, false} U string : Universe of string literals U ID : Universe of unique identiers, exactly ordered items U variable : Universe of states dened by global variables U animator : Universe of animators attributes : ID : U ID : unique identier V ariables : U variable U port : Universe of ports ID : U ID : unique identier Owner : U animator : Container animator U stamp : Universe of timestamps T ime : U int : Logical/physical time Index : U int : Additional index to make stamps unique U event : All the possible events handled by the animation logic Stamp : U stamp : Scheduling time of the event IsInternal : U bool : Indicates, if the event internal is T ype : U string : Denes the type of the event U statetype = {start, general, end} : Possible state types U state : Universe of animation model states ID : U ID : unique identier Owner : U animator : Container animator T ype : U statetype : Type of the state T imeout : U real : if greater than or equals to 0, then an internal transition is performed after this timeout from the current state U edge : Universe of animation model transitions

44 Chapter 3. Defining the dynamic behavior of metamodeled languages 32 ID : U ID : unique identier IsInternal : U bool :Indicates if this is an internal transition Right : U state : The edge is coming from this state Left : U state : The edge is leading to this state Guard, Action : U string : Guard and action expression assigned to the transition transition ASM functions for VAF Denition 3.2 (vocabulary of the animation framework). The vocabulary Σ of the ASM formalism of the animation framework is assumed to contain the following characteristic functions (arities are denoted by dashes): Monitored functions: MappedTo/1, Animators/0, TestGuard/1, TestedPorts/1, PerformActions/1, ContainerState/1, Clone/1, FiredEvents/1, IsTransient/1 CurrentTime/0, CurrentState/1, LastTime/1, Length/1, Ele- Controlled functions: ment/2, LastIndex/0 Derived functions: opset/2, opst/2, oplt/2, opeq/2, Peek/1, StartState/1, OutEdges/1, Top/1, StateInternalDelay/1, InternalDelay/1, NextInternal/1, NextExternal/1, MinExternal/0, MinInternal/0 We consider the following monitored functions to be the services of the environment. They dene the structure of the processed animation models and wrap elemental processing steps (e.g. T estguard). MappedT o(port) : U port Uport : The input ports assigned to the output port port with EventRoute edges in the high-level model Animators : Uanimator : returns the collection of all the animators in the animation model T estguard(edge) : U edge U bool : true if the guard expression assigned to edge is evaluated to true (considering the current content of the ports as well and the variables of the animator), f alse otherwise. T estedp orts(edge) : U edge Uport : returns the collection of ports tested by the guard expression of edge (for which T estguard(edge) evaluates to true). P erformactions(entity) : (U edge U state ) undef : Performs the imperative code assigned to an edge or a state as entering action, modies the variables of the related animator. ContainerState(state) : U state U state : returns the container state of state, or undef if state does not have a container state. Clone(event) : U event U event : creates a new event instance, and copies all the properties of the argument event into it. F iredevents(edge) : U edge (U event U port ) : Set of events with target ports, these events are red to the corresponding port on performing the edge transition The controlled functions listed below are used as helper variables that dene the state of the animation logic. CurrentT ime : U stamp : stores the current animation time CurrentState(animator) : U animator U state : the current state of the animator. By default has the value of StartState(animator).

45 Chapter 3. Defining the dynamic behavior of metamodeled languages 33 LastT ime(animator) : U stamp : represents the last activation time of animator i.e. the animation time when the transitions of the current state of the animator were tested. Length(port) : U port U int : stores the number of events stored on port. Element(port, index) : (U port U int ) U event : returns the event stored in port at the indexth position LastIndex : U int : index of the last event enqueued to a port. The opset, opst, oplt and opeq derived functions dene comparator operators for time stamps: true, if stamp1.t ime < stamp2.t ime stamp1.t ime = stamp2.t ime opset(stamp1, stamp2) = stamp1.index <= stamp2.index opst(stamp1, stamp2) = oplt(stamp1, stamp2) = opeq(stamp1, stamp2) = f alse, true, f alse, true, f alse, true, f alse, otherwise if stamp1.t ime < stamp2.t ime stamp1.t ime = stamp2.t ime stamp1.index < stamp2.index otherwise if stamp1.t ime > stamp2.t ime stamp1.t ime = stamp2.t ime stamp1.index > stamp2.index otherwise if stamp1.t ime = stamp2.t ime stamp1.index = stamp2.index otherwise The StartState derived function returns a start state that does not have container states in a specic animator, the OutEdges function calculates the set of transitions leaving a specic node. StartState(animator) = OutEdges(state) = s U state, s.t ype = start s.owner = animator ContainerState(s) = undef {t t U edge, t.left = state} The Peek, Top, StateInternalDelay, InternalDelay, NextInternal, NextExternal, MinExternal, and MinInternal derived functions are used to test the content of the ports and to calculate the time of the nearest external and internal transitions.

46 Chapter 3. Defining the dynamic behavior of metamodeled languages 34 P eek(port) = T op(port) = StateInternalDelay(state) = InternalDelay(state) = N extinternal(animator) = N extexternal(animator) = M inexternal = M ininternal = { Element(port, 1) if Length(port) > 0, undef otherwise. P eek(port) if P eek(port) undef opset( P eek(port).stamp, CurrentT ime) undef otherwise. min(stateinternaldelay(containerstate( state)), s.t imeout) if state undef inf otherwise. StateInternalDelay(CurrentState(animator)), LastT ime(animator).t ime + InternalDelay(animator). min({element(p, i).stamp p P orts(animator), i {1..Length(p)}, oplt(element(p, i).stamp, CurrentT ime})) if any inf otherwise min({n extexternal(a) a Animators}). min({n extinternal(a) a Animators}). P eek returns the event at the 0th position in a port without removing the event from the queue. The T op function returns the event at the 0th position in a port if the event is scheduled before CurrentT ime. StateInternalDelay calculates the delay until the next internal transition in the specied state, considering the container states of the state as well. The InternalDelay function evaluates StateInternalDelay on the current state of the specied animator. While NextInternal calculates the time stamp for which the next internal transition of the specication is scheduled, M ininternal evaluates N extinternal for each animator, and returns the smallest time stamp. Namely, it nds the earlies time stamp when either of the animators should perform an internal transition. N extexternal and M inexternal have a similar purpose, but they operate on external transitions ASM rules of the expected behavior The following ASM rules dene the core logic of the animation models. In this section, we present the rules that describe the expected behavior of the models as a requirement specication. The Sort rule sorts the events stored in a specic port according to the time stamps of the events. Algorithm 3.1 The Sort rule 1: rule Sort(port) = 2: choose i, j in {1..Length(port)} with i > j and opst(element(port, i).stamp, Element(port, j).stamp) 3: seq 4: Element(port, i) := Element(port, j) 5: Element(port, j) := Element(port, i) 6: seq 7: Sort(port) P ush inserts an event into a specic port keeping the order of the events and it assigns a unique index to the event if the index has already been used by another event. It can happen

47 Chapter 3. Defining the dynamic behavior of metamodeled languages 35 if the same event is forwarded to multiple ports, thus, by assigning a new Index to the cloned instance of the event we can maintain the unique ordering of the events. Algorithm 3.2 The P ush rule 1: rule Push (port, event) = 2: if port.buf f er > Length(port) then 3: seq 4: //if the same event is forwarded to several places 5: if event.stamp.index <= LastIndex then 6: seq 7: event := Clone(event) //copy the existing event 8: seq 9: event.stamp.index := LastIndex + 1 //assign a new index 10: seq 11: LastIndex = event.stamp.index 12: //store the index of the last forwarded event 13: Element(port, Length(port) + 1) := event 14: Length(port) := Length(port) : seq 16: Sort(port) P op removes and retrieves the topmost event of a port, if the event is scheduled before CurrentT ime. Algorithm 3.3 The P op rule 1: rule Pop(port) = 2: if T op(port) = undef then 3: return undef 4: else 5: forall i in 2..Length(port) 6: Element(port, i 1) := Element(port, i) 7: Length(port) := Length(port) 1 8: return T op(port) F ire forwards an event to all the ports mapped to the outp ort port of an animator Algorithm 3.4 The F ire rule 1: rule Fire (event, outport) = 2: forall inp ort in MappedT o(outp ort) 3: P ush(inp ort, event) The P opp orts rule applies the P op rule on each ports received as the parameter.

48 Chapter 3. Defining the dynamic behavior of metamodeled languages 36 Algorithm 3.5 Executes a Pop on all the ports received as the parameter 1: rule PopPorts(ports) = 2: forall port in ports 3: P op(port) The Step rule performs the specied transition of the specied animator. Then it also performs all the enabled external transitions without changing the current time, nally, res the generated new events. Algorithm 3.6 The Step rule 1: rule Step(a, out) = 2: seq 3: P erf ormactions(out) 4: P opp orts(t estedp orts(out)) 5: seq 6: if out.right.t ype = end and not ContainerState(out.Right) = undef then 7: CurrentState(a) := ContainerState(out.Right) 8: else 9: seq 10: choose s in U State with ContainerState(s) = out.right and s.t ype = start 11: CurrentState(a) := s 12: ifnone 13: CurrentState(a) := out.right 14: seq 15: P erf ormactions(out.right) 16: seq 17: //process remaining external events if possible 18: StepExternal(a) 19: seq 20: //Fire new external events after processing the available ones 21: forall (event, port) in F iredevents(out) 22: F ire(event, port) StepExternal executes an applicable external transition of the specied state. If there is not any, it navigates upwards in the containment hierarchy and checks the container states as well. Algorithm 3.7 The StepExternal rule 1: rule StepExternal(a, s) = 2: choose out in OutEdges(s) with (not out.isinternal and T estguard(out)) 3: Step(a, out) 4: ifnone 5: if not (ContainerState(s) = undef) then 6: StepExternal(a, ContainerState(s))

49 Chapter 3. Defining the dynamic behavior of metamodeled languages 37 StepInternal performs the executable internal transition of the specied state. It recursively checks the container states of the state as well, if there is not any executable internal transition. Algorithm 3.8 The StepInternal rule 1: rule StepInternal(a, s) = 2: choose out in OutEdges(s) with out.isinternal and s.t imeout = InternalDelay(a) 3: Step(a, out) 4: ifnone 5: if not ContainerState(s) = undef then 6: StepInternal(a, ContainerState(s) GlobalStep is intended to dene the core execution logic of the animation framework. It selects the animator with the earliest scheduled event or internal transition, and performs the available transitions. Algorithm 3.9 The GlobalStep rule 1: rule GlobalStep = 2: //the next external event is scheduled before the next internal. In case of the same time component, external events have precedence. 3: if M inexternal.t ime <= M ininternal then 4: choose a in Animators with N extexternal(a) = M inexternal 5: seq 6: CurrentT ime = M inexternal 7: seq 8: LastT ime(a) = CurrentT ime 9: StepExternal(a) 10: else 11: //the next internal event is scheduled before the next external 12: choose a in Animators with N extinternal(a) = M ininternal 13: seq 14: //Index component does not need to be changed 15: CurrentT ime.t ime = M ininternal 16: seq 17: LastT ime(a) = CurrentT ime 18: StepInternal(a) The Animation rule executes GlobalStep until all the animators reach their end state. This rule can be considered the entry point of the animation. Algorithm 3.10 The Animation rule 1: rule Animation = 2: while a in Animators where not CurrentState(a).T ype = end 3: GlobalStep

50 Chapter 3. Defining the dynamic behavior of metamodeled languages 38 Denition 3.3 (behavior of an animation specication). The behavior of a VAF animation is specied by the vocabulary of the animation framework (Denition 3.2) and the ASM rules Sort, Push, Pop, Fire, Step, StepExternal, StepInternal, GlobalStep, Animation. By the rules we assume that the choose operator deterministically selects the element with the smallest ID. 3.6 Concrete behavior of the implementation On executing an animation, both the high-level model and the low-level state machines are converted into source code that highly builds on the DEVS-based simulation engine. Consequently, the implementation does not exactly match the specication. In this section, the rules and functions that describe the behavior of the implementation are presented. This description provides a basis to make the specied and implemented behavior comparable, and thus, we will be able to show that even if the specication and the implementation use dierent rules, the behavior they describe is the same. In the following, only the dierences compared to the specication are shown, the functions and rules shared by the two ASMs are not enlisted again. These are the monitored, controlled and derived functions except for the T op/1 function. Furthermore, the realization of the Sort I, P op I, Step I, StepExternal I, StepInternal I, and Animation I rules are also equivalent with the rules of the specication. Denition 3.4 (vocabulary of the animation framework implementation). The vocabulary Σ I of the ASM formalism for the implementation of the animation framework is assumed to contain the following characteristic functions: Monitored functions: MappedT o I /1, NewInternal I /1, Animators I /0, T estguard I /1, T estedp orts I /1, P erformactions I /1, ContainerState I /1, Clone I /1, F iredevents I /1, IsT ransient I /1 Controlled functions: CurrentT ime I /0, CurrentState I /1, LastT ime I /1, Length I /1, Element I /2, LastIndex I /0, ElementGlobal I /1, LengthGlobal I /0 Derived functions: opset I /2, opst I /2, oplt I /2, opeq I /2, StartState I /1, OutEdges I /1, P eek I /1, T op I /1, StateInternalDelay I /1, InternalDelay I /1, NextInternal I /1, NextExternal I /1, MinExternal I /0, MinInternal I /0, RealLength I /1 As in case of the implementation the execution is coordinated by a global event queue, we dene the ElementGlobal I /1 and LengthGlobal I /0 controlled functions and RealLength I /1 derived function to realize the queue: ElementGlobal I (index) : U int (U Event U animator U port ) : Event, target animator and port in the global event queue at the position index LengthGlobal I : U int : Length of the global event queue RealLength I (port) = { Length I (port) + {e (e, a, p) = ElementGlobal I (i) p = port, i {1..LengthGlobal I }} The RealLength I /1 function evaluates the total number of events assigned to a specic port. The NewInternal I (time) : U int U event monitored function returns a new instance of event with its IsInternal attribute set to true and Stamp.T ime set to time.

51 Chapter 3. Defining the dynamic behavior of metamodeled languages 39 Algorithm 3.11 The P opglobal I rule 1: rule P opglobal I = 2: if LengthGlobal I = 0 then 3: return undef 4: else 5: forall i in {2..LengthGlobal I } 6: ElementGlobal I (i 1) := ElementGlobal I (i) 7: LengthGlobal I = LengthGlobal I 8: return ElementGlobal I (1) The following rules realize the operations of the global queue: The P opglobal I rule removes and returns the topmost element of the global event queue. If the queue is empty, the rule returns undef. Algorithm 3.12 The RemoveGlobal I rule 1: rule RemoveGlobal I (event) = 2: choose i in {1..LengthGlobal I } where ElementGlobal I (i) = event 3: forall j in {i + 1..LengthGlobal I } 4: ElementGlobal I (j 1) := ElementGlobal I (j) 5: LengthGlobal I := LengthGlobal I 1 RemoveGlobal I removes the specied event from the global queue, and shifts the remaining elements to maintain the continuity of the queue. Algorithm 3.13 The SortGlobal I rule 1: rule SortGlobal I = 2: choose i, j in {1..LengthGlobal I (port)} with i > j and (e, a, p) = ElementGlobal I (i), (e, a, p ) = ElementGlobal I (j) and (opst I (e.stamp, e.stamp) or e.stamp.t ime = e.stamp.t ime and e.isinternal and e.isinternal) 3: seq 4: ElementGlobal I (port, i) = ElementGlobal I (port, j) 5: ElementGlobal I (port, j) = ElementGlobal I (port, i) 6: seq 7: SortGlobal I Similarly to Sort I, SortGlobal I orders the events in the global event queue. Note that external events always precede internal events with the same T ime components of their Stamp. P ushglobal I inserts a new element into the global event queue. If the new event is an internal one scheduled after an existing external one for the same animator, the event is dropped. If the new event is an external one, then the rule also removes the internal event for the same animator scheduled after the external one (if there is such an event). Because of the application of a global event queue, we slightly modify the denition of the port-handling rules and functions as well: T op I (port) P eek I (port)

52 Chapter 3. Defining the dynamic behavior of metamodeled languages 40 Algorithm 3.14 The P ushglobal I rule 1: rule P ushglobal I (event, animator, port) = 2: if not event.isinternal and RealLength I (port) < port.buffer or {i i in {1..LengthGlobal I }, (e, a, p) = ElementGlobal I (i) where not e.isinternal and a = animator and e.stamp.t ime <= event.stamp.t ime} = 0 then 3: seq 4: if not event.isinternal then 5: seq 6: //the same event is forwarded to multiple ports 7: if event.stamp.index <= LastIndex then 8: seq 9: //create a new instance 10: event = Clone I (event) 11: seq 12: event.stamp.index = LastIndex I : seq 14: //drop invalidated internal events 15: choose i in {1..LengthGlobal I } where (e, a, p) = ElementGlobal I (i) and a = animator and e.isinternal and e.stamp.t ime >= event.t ime 16: RemoveGlobal I (i) 17: seq 18: LastIndex I = event.stamp.index 19: seq 20: ElementGlobal I (LengthGlobal + 1) := (event, animator, port) 21: LengthGlobal I := LengthGlobal I : seq 23: SortGlobal I As in case of the implementation the ports of the animators contain only active events, the T op I function does not have to lter the returned events by their scheduling time. Algorithm 3.15 The P ush I rule 1: rule P ush I (port, event) = 2: Element I (port, Length I (port) + 1) := event 3: Length I (port) := Length I (port) + 1 Similarly, as the global queue contains the events ordered and forwards the events to the target port following the order, the P ush I rule of the implementation does not need to perform additional ordering on the ports. The EnqueueNextInternal I rule generates an internal event for the earliest internal transition in the specied state or its container states, and puts the generated event into the global event queue. The realization of the F ire I rule has also changed compared to the specication: instead of forwarding an event to all the ports connected to the target port of the event, it is enqueued into the global event queue.

53 Chapter 3. Defining the dynamic behavior of metamodeled languages 41 Algorithm 3.16 The GlobalStep I rule 1: rule GlobalStep I = 2: if not P eekglobal I = undef then 3: seq 4: (event, a, port) = P opglobal I 5: seq 6: //internal events are not forwarded 7: if not event.isinternal then 8: P ush I (port, event) 9: CurrentT ime I := event.stamp 10: else 11: CurrentT ime I.T ime := event.stamp.t ime 12: seq 13: LastT ime I (a) := CurrentT ime I 14: if not event.isinternal then 15: StepExternal I (animator) 16: else 17: StepInternal I (animator, event.state) 18: seq 19: EnqueueNextInternal I (animator, CurrentState I (animator), undef) Algorithm 3.17 The EnqueueNextInternal I rule 1: rule EnqueueNextInternal I (animator, state, next) = 2: if s = undef and next undef then 3: P ushglobal I (NewInternal I (CurrentT ime.t ime + next.left.t imeout, next), animator, undef) 4: else if state undef then 5: choose outint in OutEdges I (state) with outint.isinternal 6: if next = undef or state.t imeout < next then 7: next := outint 8: EnqueueNextInternal I (animator, ContainerState I (state), next) Denition 3.5 (behavior of an animation implementation). The implementation behavior of a VAF animation is specied by the vocabulary of the animation framework implementation (Denition 3.4) and the ASM rules Sort I, P ush I, P op I, F ire I, Step I, StepExternal I, StepInternal I, GlobalStep I, Animation I, P ushglobal I, P opglobal I, RemoveGlobal I, and EngueueNextInternal I. By the rules we assume that the choose operator deterministically selects the element with the smallest ID. Algorithm 3.18 The F ire I rule 1: rule F ire I (event, outp ort) = 2: forall inport in MappedT o I (outp ort) 3: P ushglobal I (event, Container I (inport), inport)

54 Chapter 3. Defining the dynamic behavior of metamodeled languages Processing Animation Models Recall that the animation models of VAF are processed using graph rewriting-based model transformation, and executable source code is generated. Our implementation is based on the C# language, however, the presented solution can be easily adapted to an arbitrary object-oriented programming language. As one can see, the additional or modied rules of the implementation (Section 3.6) compared to the specication (Section 3.5) can be considered to be the part of the execution engine, and are not related to the generated code. The generated source code only congures the execution engine by establishing an optimized object hierarchy isomorphic to the input VMTS animation model. From each state machine model (from each Animator) an individual class is generated that implements the behavior described by the state machine. Furthermore, a Conguration class is also generated from the high-level model, this class wires the animator classes and the eventhandler instances together, and initializes the animation framework. The structure of the animation les is listed below: namespace VMTS.VAF { public class <AnimatorName> : Simulator { //Ports of the animator implemented by properties public Port <PortName> {get; private set;}... public <AnimatorName>(Coordinator coordinator) : base(coordinator) { } <Variables of the animator> public override void Init() { //Initialization of the ports <PortName> = new Port(this); <PortName>.Buffer = <buffersize>;... public override void BuildUp() { startstate = new VMTS.VAF.State(this, null, null); currentstate = startstate; //Initialization of the states State <statename> = new State(this, <entering action>, <container state>, <timeout>);... //Initialization of the transitions <fromstate>.addtransition(new Transition(this, <tostate>, <guard condition>, <action>), <isinternal>); }}} As one can see, the Init method initializes the ports, the BuildUp method creates the states and connects them with transitions. The guard condition and the action assigned to a transition is expressed using anonymous methods [Thai and Lam, 2003]. The structure of the conguration les is the following: namespace VMTS.VAF { class Configuration { public Configuration() { coordinator = new Coordinator(); Init(); } public Configuration( Coordinator _coordinator) { coordinator = _coordinator; Init(); } private void Init() { //instantiation of generated animator classes <animator field> = new <animator type>(coordinator);... coordinator.simulators.add(<animator field>);... //instantiation of event handler classes <event handler field> = new <event handler type>(coordinator);

55 Chapter 3. Defining the dynamic behavior of metamodeled languages 43 coordinator.eventhandlers.add(<event handler field>);... <setting event handler parameters> //registering connections coordinator.addmapping(<from>.<fromport>, <to>.<toport>);... } <Animator field declarations> <Event handler field declarations> }} The Coordinator class instantiated in the constructor represents the interface used by the DEVS-based simulation engine. In the Init method the animators and event handlers are instantiated, and registered in the coordinator, furthermore, the connections between the components (animators and event handlers) are also registered Transformation Models The model of the generated source code uses the VMTS implementation of a source code DOM, which is very similar to the CodeDOM [Thai and Lam, 2003, CODEDOM, 2010] provided by Microsoft. Our DOM implementation builds on a general code generation and parsing technique presented in [Angyal and Lengyel, 2009]. The control ow of the VAF transformation is depicted in Figure 3.7. The sequence can be divided into three well-separated parts: part (1) performs the verication of the input model, part (2) creates the individual animation classes for each Animator element and its contained state machine, while part (3) generates the conguration class Verication of the input model We do not verify the validity of the required event sequences to reach a state, but only the topological structure of the input model is analyzed. If a specic state is topologically unreachable, it indicates a design aw. Figure 3.8 illustrates the T raversem odel and CheckDeadState rules. T raversem odel matches a statef rom state that is (i) either a start state without a container or (ii) it is marked as processed or (iii) it is a start state with a marked container. The rule also matches a statet o state that is not a start state, is not marked and is connected with an arbitrary edge (either transition or containment) to the statef rom node. The rule marks statet o as processed, and the rule is applied exhaustively. CheckDeadState matches a single state that is not marked. Figure 3.7. The control sequence of the transformation rules

56 Chapter 3. Defining the dynamic behavior of metamodeled languages 44 (a) TraverseModel (b) Check- DeadState Figure 3.8. Verifying the input model Proposition 3.6. Given an animation model as a state chart A = (V, T, C, S, s A, t A ) where the V nodes represent the states of the animation (V > 1), S V identies the start states (both top level and contained), T denes the transitions and C the containment edges between the states with the usual s A, t A : T C V source and target functions. Let v start denote the only top-level start state i.e. v start S, c C : tgt(c) = v start. The transformation processing an animation model A terminates without modifying its input or output model if v V \S state, for which (P (T {c c C, t A (c) S})) : start v directed path. Namely, the transformation terminates if there is a state in the input model that cannot be reached from the start state not using containment edges with a start state as their target node. Proof. P denotes the set of processed states that is initially empty (P 0 ). Assume that for each v P i : v start v directed path (that applies to P 0 ). The T raversemodel rule matches a t T C edge, for which (s A (t) P {v start } {s s S, c C : s A (c) P t A (c) = s}) (t A (t) V \S\P ). If exists such t, then T raversemodel is applied, and P i+1 = P i {t A (t)}. It is clear that v start t A (t) directed path, thus, the same applies for each v P i+1 as well. T raversemodel is applied exhaustively. If after the jth application it cannot be matched anymore, it means that t T C : (s A (t) P {v start } {s s S, c C : s A (c) P t A (c) = s}) (t A (t) V \S\P ), i.e. v V \P j with v start v directed path. CheckDeadState matches a v V \P j \{v start } node. If the match succeeds ( v ) then v start v directed path, and the transformation terminates as well Processing the state machines The GenerateSkeleton ( Figure 3.9(a)) rule creates the model for the source le, the default namespace (VMTS.VAF ), and the necessary namespace references. The rule ags the matched animator to avoid matching the same one again. The rule is executed exhaustively, which means that it is repeated until no valid match (an unprocessed animator) is found. After nishing this rule, an output le with default content is generated for each animator. The GenerateClass rule is illustrated in Figure 3.9. The rule matches an Animator and its connecting namespace element (the relation between the Animator and the namespace is expressed by not an edge, but with an attribute reference). Then the rule creates a class (class_anim) element in the output model, and adds a constructor with a base constructor call, and the skeleton of the Init method. The rule is executed in an exhaustive manner again. Afterwards, the Property_Ports (Figure 3.9(c)) rule matches each Port inside an animator and generates a property for each of them within the appropriate class. Furthermore, it also creates the initialization code for each port within the Init method of the class element. The Method_BuildUp (Figure 3.9(d)) rewriting rule matches each Animator and their connecting

57 Chapter 3. Defining the dynamic behavior of metamodeled languages 45 (a) The GenerateSkeleton rule (b) The GenerateClass rule (c) The P roperty_p orts rule (d) The M ethod_buildup rule Figure 3.9. Creating the skeleton of the animation source code class again, and creates a BuildUp member method beginning with the initialization of the startstate and currentstate member variables Processing the states The following two rules (TopLevelStates and SubLevelStates) are depicted in Figure They are used to generate the model of the connecting code for the states contained directly by the Animator (top-level) and for the states contained by another states (sub-level). The TopLevelStates rule generates the model of the following code-fragment for each top-level state: State statexxxx; statexxxx = new State(this, null, null, <timeout>); or statexxxx = new State(this, delegate() { <action script> }, null, <timeout>); If an action is dened for the state, the second version is selected, in which case the action is specied with the help of an anonymous method. The selection is ensured by assigning inverted application conditions to the nullexp1 and anonymdelegate rule nodes: the aected elements are created only if the condition can be satised. The anonymous method version is selected in case of top-level Stop nodes as well: the animation engine is stopped by sending a stop event

58 Chapter 3. Defining the dynamic behavior of metamodeled languages 46 (a) TopLevelStates (b) SubLevelStates Figure Processing states to the framework. The stopfiring node is conditionally created as well. Note that the last null parameter in the constructor call of the State class denotes that the states do not have a container state. Processing the SubLevelStates is somewhat similar to the top-level version. One dierence is that at Stop states, we do not have to stop the animation, but to notify the framework to check the outgoing transitions of the container state as well. This is done in the conditionaly created performtrans node. Another dierence is that the container state parameter is set (containerstateref ) in the constructor call. Furthermore, if a contained Start node is processed, the ContainedStart property of the container state object is set to the internal start state object (assigncontainedstart branch in the gure). Both rules are executed exhaustively. When a State is processed, the rule creates an attribute-level reference from the State element to the class_anim element. The existence of this reference is set as a negative application condition for the rule, therefore, each State is processed exactly once, and the execution terminates. We also require the existence of this reference as a positive application condition between the containerstate and the class_anim element, thus, we can ensure that the code model for a contained state is generated only if its container state is already processed Processing transitions The transition edges between two states are processed by the ProcessTransitions and the PopEvents rules (depicted in Figure 3.11). The ProcessTransitions rule matches transitions in an exhaustive manner, and generates the following code fragment for each of them inside the BuildUp method of the connecting class: <statefrom>.addtransition(new Transition(this, <stateto>, delegate(){ return <guard condition>;}, delegate(){ <action script> }), false); We can obtain the container class easily, as we have created a reference between each state and the connecting class_anim node. The last parameter (isinternal = f alse) denotes that this transition is an internal one (triggered by a timer), or an external one, triggered by external events. At each execution of the rule, the selected transition edge is agged, such that it cannot be processed twice. The PopEvents rule generates a portxxxx.drop(); call for each port triggered by the selected transition. The rule receives the transition to be processed as a parameter from the previous rule, and checks each port in an exhaustive way whether it is used in the guard

59 Chapter 3. Defining the dynamic behavior of metamodeled languages 47 (a) ProcessTransitions (b) PopEvents Figure Processing transitions script of the actual transition. The Drop method call consumes the topmost event from the target port, and only from those ports, which were triggered by the transition. As one can see, the ProcessTransitions and the PopEvents rule forms a loop: this loop exits if each transition has been processed, including the verication of each port for each transition Generating the conguration class le The conguration class is generated by the rules in the block (2) in Figure 3.7. The CO_Skeleton rule generates the skeleton of the class: type declaration, two constructors, and an empty Init method. The CO_InitAnim (Figure 3.12(a)) rule creates a member variable for each Animator element, and initializes them in the Init method. Similarly, the CO_InitEH rule creates member variables for the event handler elements, and initializes them. Finally, the CO_EventRoutes processes the EventRoute edges, registers the connections between the ports of the connected components: coordinator.addmapping( <sourcecontainer>.<sourceport>, <targetcontainer>.<targetport>); The CO_EventRoutes rule is illustrated in Figure 3.12(b). Note that in Figure 3.12(b) the AddM apping method call is modeled twice. As the EventRoutes can be bi-directional as well (depending on their Direction property), a reverse direction P ortm apping can also be added. The reverse direction is created conditionally based on the settings of the EventRoute edge Verication of the transformation Recall that the aim of the transformation is to generate source code that establishes an object hierarchy isomorphic to the input animation model. The interface for this object hierarchy are the monitored functions of the implementation (Denition 3.4). In the following, we assume that the object hierarchy can be modied with the help of the following monitored functions:

60 Chapter 3. Defining the dynamic behavior of metamodeled languages 48 (a) The CO_InitAnim rule (b) The EventRoutes rule Figure Generating the conguration class le Denition 3.7 (structure builder functions). The CreateAnimator I /0, CreateState I /5, CreateT ransition I /6, CreateP ort I /1, SetBufferSize I /2, AddMapping I /2 monitored functions are used to exclusively edit the structure of the animation model of the implementation. In the following, we assume that they perform the operation declared by their postcondition only. CreateAnimator I /0 : U animator precondition: x = CreateAnimator I / Animators I postcondition: x Animators I CreateState I /5 : (U animator U State U Int U string {state, start, end}) U State precondition: s = CreateState I (animator, container, timeout, action, type), s.owner = undef ContainerState I (s) = undef postcondition: s.owner = animator s.t imeout = timeout ContainerState I (s) = container s.t ype = type (T op, animator.v ariable) P erformactions(s) (T op, animator.v ariable ) P erformactions I (s) (T op I, animator.v ariable) (T op I, animator.v ariable ), where we assume the same port and variable conguration for the specication and the implementation before and after applying P erformactions( I ). Namely, the operation dened by the script action performs the same changes in case of the specication and the implementation. CreateT ransition I /6 : (U State U State U String U String U Bool ) U Edge precondition: t = CreateT ransition I (animator, from, to, guard, action, isinternal), t.left = t.right = undef postcondition: t.left = from t.right = to, t.isinternal = isinternal T estguard(t) (T op,animator.v ariable) = T estguard I (t) (T op I,animator.V ariable) : considering the same return values for the T op and T op I functions and the same variable conguration, the guard condition specied by guard evaluates to the same value in case of the specication and the implementation.

61 Chapter 3. Defining the dynamic behavior of metamodeled languages 49 T estedp orts(t) (T op,animator.v ariable) = T estedp orts I (T op I,animator.V ariable): considering the same visible events (T op/t op I ) and variable conguration, the specied and implemented T estedp orts( I ) functions return the same ports for the same transition. F iredevenes(t) (T op,animator.v ariable) = F iredevents I (T op I,animator.V ariable): considering the same visible events (T op/t op I ) and variable conguration, the specied and implemented F iredevents( I ) functions return the same event sets for the same transitions. (T op, animator.v ariable) (T op I, animator.v ariable) corresponds to T op again. P erformactions(t) (T op, animator.v ariable ) P erformactions I (t) (T op I, animator.v ariable ), where T op I CreateP ort I /1 : U animator U port precondition: p = CreateP ort I (animator), p.owner = undef postcondition: p.owner = animator SetBufferSize I /2 : (U port U int ) undef postcondition: SetBufferSize I (port, size) port.buffer = size AddMapping I /2 : (U port U port ) undef precondition: fromp ort, top ort U port : top ort / MappedT o I (fromp ort) postcondition: AddMapping I (fromp ort, top ort) top ort MappedT o I (fromp ort) In the following, we will map the structure builder functions to the C# operations generated by the transformation and show that the output of the transformation establishes a structure isomorphic to the input model. Proposition 3.8. By executing the VAF transformation on a G animation model, the generated source code builds up an object hierarchy not distinguishable from the model based on the Animators( I )/0, ContainerState( I )/1, MappedT o( I )/1, T estguard( I )/1, P erformactions( I )/1, F iredevents( I )/1 and T estedp orts( I )/1 monitored functions, and the initial value (StartState( I )) of the CurrentState( I )/1 controlled function. Proof. Appendix A Proposition 3.9. The VAF transformation terminates on arbitrary input animation model. Proof. Appendix A 3.8 Equivalence of the Specication and the Implementation In the following, we provide the proof for the equivalence of the ASM described by the speci- cation and the implementation by bisimulating the two systems. Firstly, we dene a binary relation between the states of the two ASM-s, and show that the relation is a bijection. Secondly, we prove that the relation is a bisimulation between the two systems. The current state of the specication and the implementation can be exactly identied by one-one tuple containing the current values of the controlled ASM functions and an IsT ransient : U animator U bool ag:

62 Chapter 3. Defining the dynamic behavior of metamodeled languages 50 for the specication: S =< CurrentT ime, CurrentState, IsT ransient, LastT ime, Element, Length > (3.1) and for the implementation: S I =< CurrentT ime I, CurrentState I, IsT ransient I, LastT ime I, Element I, Length I, ElementGlobal I, LengthGlobal I > (3.2) The IsT ransient(a) ag is used to indicate, whether a StepExternal or StepInternal rule is in progress on the a animator, thus, CurrentState(a) may change before the control returns to GlobalStep. State transitions of the state machines are dened by the transitions of the animator (both external and internal), and by the changing of the IsT ransient(a) ag of either animator (i.e. entering and leaving the StepExternal or StepInternal rules during the execution of the GlobalStep rule) Bijective relation between the states of the two systems We provide a construction how to map the states of the specication to the states of the implementation, and another mapping for the reverse direction, then we prove that the two mappings are the inverse of each other. In the following, we have the assumption that the choose operator deterministically selects the element with the smallest ID, otherwise the two systems would have nondeterministic behavior. Note that we only deal with states that can occur during the execution of the specication and the implementation. These states are specied as follows: Denition (Valid specication state) An S = <CurrentT ime, CurrentState, IsT ransient, LastT ime, Element, Length> state of an animation specication is valid if the following conditions hold: (ϱ 1 ) (ϱ 2 ) (ϱ 3 ) (ϱ 4 ) CurrentState(a) undef, a U animator (3.3) LastT ime(a) <= CurrentT ime(a), a U animator (3.4) Element(p, i) undef, p U port, i N, 0 < i <= Length(p) (3.5) Element(p, i).stamp < Element(p, i + 1).Stamp, p U port, i N, 0 < i < Length(p) (3.6) (ϱ 5 ) Element(p, i).stamp Element(p, j).stamp, p p U port, i j N, 0 < i, j =< Length(p) (3.7)

63 Chapter 3. Defining the dynamic behavior of metamodeled languages 51 Note: Property ϱ 1 expresses that the animators always have a current state. ϱ 2 states that the last activation time of the animators cannot be after the global animation time. Properties ϱ 3..ϱ 5. express that the events on the ports are strictly ordered according to their Stamp, and the numbering sequence of the events of the ports is continuous. Corollary Assume that the state machine according to the specication is in a valid state based on Denition Having the set of events E enqueued in ports p P ort(ei ), e i E, the value of the Element and Length functions is exactly dened because of the strict ordering of the events. Denition (Active event) An event is active if it is scheduled to a time stamp smaller than or equals to the current time. Namely, an e event is active if opset(e.stamp, CurrentT ime). Denition (Valid implementation state) An S I = < CurrentT ime I, CurrentState I, IsT ransient I, LastT ime I, Element I, Length I, ElementGlobal I, LengthGlobal I > state of an animation implementation is valid, if the following conditions hold: (ϱ I 1) (ϱ I 2) (ϱ I 3) (ϱ I 4) CurrentState I (a) undef, a U animator (3.8) LastT ime I (a) <= CurrentT ime I (a), a U animator (3.9) Element I (p, i) undef, p U port, i N, 0 < i <= Length I (p) (3.10) (ϱ I 5) Element I (p, i).stamp <= CurrentT ime I, p U port, i N, 0 < i <= Length I (p) (3.11) Element I (p, i).stamp < Element I (p, i + 1).Stamp, p U port, i N, 0 < i < Length I (p) (3.12) (ϱ I 6) GlobalElement I (i) undef, 0 < i <= GlobalLength I, i N (3.13) (ϱ I 7) i, j N, 0 < i < j < LengthGlobal I, (e i, p i, a i ) = ElementGlobal I (i), (e j, p j, a j ) (ϱ I 8) = ElementGlobal I (j) e i.stamp < e j.stamp (e i.t ime = e j.t ime e i.p ort = ø (e j.p ort ø a i.id < a j.id)) (3.14) p p i j Element I (p, i).stamp Element I (p, j).stamp, p, p U port, i, j N (3.15) (ϱ I 9) i, j N, p U port : (e, p, a ) = ElementGlobal(i), p ø e.stamp = Element I (p, j).stamp (3.16)

64 Chapter 3. Defining the dynamic behavior of metamodeled languages 52 (ϱ I 10) (ϱ I 11) i N : (e, p, a) = ElementGlobal I (i), e.isinternal e.stamp > CurrentT ime I (3.17) CurrentT ime I.T ime <= NextInternal I (a) NextInternal I (a) < NextExternal I (a).t ime IsT ransient I (a) i N : (e, ø, a) = ElementGlobal I (i) e.isinternal, a U animator (3.18) Properties ϱ I 3..ϱ I 7 express that the numbering sequence of the events in the ports and the global queue is continuous, and the events (both external and internal) are strictly ordered according to their Stamp and Animator Id. Properties ϱ I 8-ϱ I 9 formalize that there cannot be two external events in the system with the same stamp. Property ϱ I 10 expresses that external events in the global queue are scheduled after CurrentT ime I, and the value of the T ime eld of the internal event stamps is at least the value of that of CurrentT ime I. Property ϱ I 11 formalizes that if an animator is not in a transient state, and its current state has an internal transition scheduled after the current time but before the next external event, then a corresponding internal event must exist in the global queue (the position of which is determined by ϱ I 7 as well). Corollary Assume that an animation implementation is in a valid state based on Denition Having the set of external events E enqueued in ports p P ort(ei ), e i E (p P ort(ei ) = ø in case of internal events), the value of the Element I, Length I, GlobalElement I and GlobalLength I functions is exactly dened for each CurrentT ime I value because of the strict ordering of the events. Now we dene the mapping between the states of the specication and the implementation in the following way: ϕ 1 : ϕ 2 : ϕ 3 : ϕ 4 : CurrentState(a) = CurrentState I (a), a U animator (3.19) LastT ime(a) = LastT ime I (a), a U animator (3.20) IsT ransient(a) = IsT ransient I (a), a U animator (3.21) CurrentT ime = CurrentT ime I (3.22) Namely, the LastT ime, CurrentState, IsT ransient and CurrentT ime functions provide the same values for the same parameters. We still need to map the Element( I ), Length( I ), ElementGlobal I and LengthGlobal I functions. In the following, we map those events of the Element function that are scheduled to a time stamp smaller than CurrentT ime: ϕ 5 : Element(p, i) = e e.stamp <= CurrentT ime Element I (p, i) = e, p U port, i N (3.23)

65 Chapter 3. Defining the dynamic behavior of metamodeled languages 53 and in the reverse direction: ϕ 5 : Element I (p, i) = e Element(p, i) = e, p U port, i N (3.24) Intuitively, if an active event can be found on a port p at the position i in the specication, then the same event is at the same position on the same port in the implementation as well. And the same in the reverse direction, with the slight dierence that in the implementation there are only active events on the ports. Now we map those events of the Element function that are scheduled to a time stamp greater than CurrentT ime: ϕ 6 : Element(p, i) = e e.stamp > CurrentT ime ElementGlobal I ( {e e = Element(p, j) e.stamp < e.stamp e.stamp > CurrentT ime, p U port, j N} + {a CurrentState(a).T imeout+lastt ime(a) < e.stamp IsT ransient(a), a U animator } +1) = (e, p, p.owner), p U port, i N (3.25) Namely, non-active events on a port in the specication correspond to an event in the global queue in the implementation, where the event is positioned to follow all the external and internal events with a smaller timestamp, but precede internal events with a smaller time stamp but that with the same time part. In the reverse direction we map the tuples of the global event queue to events in the ports: ϕ 6 : ElementGlobal I (i) = (p I, a I, e I ) p I ø Element(p I, Length I (p I ) + {(p, a, e) (p, a, e) = ElementGlobal I (j), j < i p = p I, a U animator } + 1) = e I (3.26) Namely, an external event in the global queue corresponds to an event on a port in the specication, and the position of the event is calculated to follow all the events scheduled to a smaller time stamp. ϕ 7 : CurrentT ime < NextInternal(a) < inf IsT ransient(a) NextExternal(a).T ime > NextInternal(a).T ime ElementGlobal I ( {e e = Element(p, j) e.stamp > CurrentT ime e.stamp.t ime < NextInternal(a).T ime, p U port, j N} + {a a U animator : NextInternal(a ).T ime < NextInternal(a).T ime NextInternal(a ).T ime = NextInternal(a).T ime a.id > a.id} + 1) = (NewInternal I (NextInternal(a)), ø, a), a U animator (3.27) Namely, if the current (non-transient) state of an animator has an internal transition scheduled after CurrentT ime but before the following external event for that animator, then a corresponding internal event is scheduled after the events with a smaller time stamp, and internal events with a time stamp with the same T ime part, but smaller animator id.

66 Chapter 3. Defining the dynamic behavior of metamodeled languages 54 (The reverse direction is meaningless, because the current state is exactly dened) and The length of the global event queue and the ports is mapped in the following way: ϕ 8 : LengthGlobal I = {e e = Element(p, j) e.stamp > CurrentT ime, p U port, j N} + {a (CurrentState(a).T imeout < inf IsT ransient(a) CurrentState(a).T imeout+ LastT ime(a) > CurrentT ime), a U animator } (3.28) Length I (p) = {e e = Element(p, i) e.stamp <= CurrentT ime, i N}, p U port. (3.29) Namely, the length of the global event queue corresponds to the number of non-active external events in the system and the number of animators that have a current state with a scheduled internal transition. The length of a port in the implementation corresponds to the number of active events in the specication on the same port. ϕ 8 : Length(p) = Length I (p) + {(p I, a I, e I ) (p I, a I, e I ) = ElementGlobal I (j) p I = p, j N}, p U port (3.30) In the reverse direction, the number of events stored on a port in the specication equals to the number of active events on the same port in the implementation and the number of non-active events scheduled for the same port in the global event queue. Denition 3.15 (Bidirectional mapping between the specication and the implementation). We refer to the {ϕ i i} mappings together as ϕ and similarly, to the {ϕ i i} mappings together as ϕ, where 1 i 4 : ϕ i = ϕ i = ϕ i. The mappings ϕ 1, ϕ 2, ϕ 3 and ϕ 4 are bijections between the corresponding elements of the state tuples. Based on Corollaries 3.11 and 3.14, the set of events in a valid state exactly denes the values of the Element, Length, Element I, Length I, GlobalElement I and GlobalLength I functions. Thus, if we can prove that the construction maps a valid animation implementation state to a valid state of the animation specication, and an external event in the implementation corresponds to one in the specication with the same stamp, and vice-versa, the mappings are inverse of each other. Proposition The ϕ construction assigns a valid animation implementation state to each valid specication state and vice-versa for ϕ. Proof. Appendix A Proposition Given an animation specication A and its implementation A I. The same external events exist in both A and A I, i.e. neither ϕ nor ϕ assigns two dierent events to the same position of either port (Element(p, i)) or the global queue (ElementGlobal I (i)). Proof. Appendix A

67 Chapter 3. Defining the dynamic behavior of metamodeled languages Bisimulation of the two systems Having the bijective relation dened between the two ASMs, now we prove that the relation is a bisimulation of the two systems, thus, their behavior cannot be distinguished by an external observer. The essence of the proof is as follows: (i) We assume that both the specication and the implementation are in valid states corresponding to each other up to ϕ. (ii) Then, we proove that the following states of both the animation specication and the implementation are valid, and they correspond to each other up to ϕ again. Note, that we assume deterministic execution (deterministic choose operator), and because of the bijective property of ϕ, the proof is applicable in any valid state of both the specication and the implementation. Proposition Given an animation specication A and its implementation A I. If they are in the valid states S and S I = ϕ (S), respectively, and IsT ransient(a), a Animators, then the same animator is activated (i.e. called with StepExternal or StepInternal), and for the following S and S I ' states it holds that they are valid and S I = ϕ (S ). Proof. Appendix A Proposition Given an animation specication A and its implementation A I. If they are in the valid states S and S I = ϕ (S), respectively, and the animator a has been activated with a StepInternal( I ) call (IsT ransient( I )(a) = true), then, for the following S and S I states, it holds that they are valid and S I = ϕ (S ). Proof. Appendix A Proposition Given an animation specication A and its implementation A I. If they are in the valid states S and S I = ϕ (S), respectively, and a StepExternal( I ) call is in progress, then for the following S and S I states it holds that they are valid and S I = ϕ (S ). Proof. Appendix A Proposition Given an animation specication A and its implementation A I. If they are in the valid states S and S I = ϕ (S), respectively, and the last StepExternal( I ) call (at the bottom of the recursion chain) within one GlobalStep( I ) call has just been nished, then after nishing the caller GlobalStep( I ) rule, the state machines will be in an S and S I state that are valid and S I = ϕ (S ). Proof. Appendix A Proposition The ϕ bijective relation (ϕ and ϕ ) is a bisimulation between the animation specication and the implementation. Proof. Consider that the state machines of the specication and the implementation are in the valid states S and ϕ (S). According to Propositions 3.19, 3.20 and 3.21, starting from compatible valid states, the state machines perform the same transitions (external and internal), re the same events, and reach valid, compatible states, for that the same propositions apply again. The same proof is applicable in the reverse direction (ϕ (S I ) and S I ) as well because of the bijection of ϕ and the deterministic execution.

68 Chapter 3. Defining the dynamic behavior of metamodeled languages Expressiveness of the Animation Language Having a DSML designed to dene application logic, it is an important question what exactly we can describe with the language, and how expressive it is. In this section, we provide answers for this question. We show which subset of the DEVS specication can be simulated using the languages of VAF, and we also show that the any system specied with DTSS can also be simulated with VAF Expressing DEVS with VAF Since the state machine formalism of VAF is capable of expressing only a nite number of internal transitions, we cannot simulate DEVS in general with VAF. However, a subset that is limited to a nite number of states can be simulated. Proposition Given a deterministic DEVS M = X, S, Y, δ int, δ ext, λ, ta, with a nite number of states (i.e. S < ) there is a (not necessarily unique) VAF animation that simulates it. Proof. We provide a construction to build a VAF animation simulating M. We create a single port to send and receive events. To each x X Y value, we assign an event (e x ) in the animation system, and to each s S state, we assign an s animation state. Furthermore, we also create a StartState node with a T imeout of 0 and connect it with an internal transition to the animation state corresponding to the start state of the DEVS simulation. The internal transition function (δ int ) denes at most one mapping for each s i S state by the denition of DEVS, thus, each of them can be represented by a t i internal transition: t i.left.t imeout = ta(s i ). When performing the internal transition t i the corresponding output event (e λ(si )) is red, thus, t i.action = F ire < e λ(si ) > (p). We still have to represent the external transitions of the DEVS system in VAF. As the number of states is assumed to be nite by the proposition, the possible external transitions of the DEVS system can be represented by a nite number of external transitions in VAF: we create a t x : s 1 s 2 external transition for each corresponding s 1, s 2 S state pair, for which e R + 0,ta(s1), x X : δ ext((s1, e), x) = s2. The guard condition of the t x external transition should be: t x.guard = p.p eekoft ype < e x > () lastt ime(a) {e e [0, ta(s1)] : δ ext ((s1, e), p.p eekas < e x >) = s2}. This means that the transition is performed if an event of type e x arrived, and the time e elapsed since the last state transition is such that δ ext ((s1, e), e x ) = s Example In the following, we present the DEVS specication of a one-slot toaster and the corresponding VAF model that represents it. The DEVS specication is: X = {push, pull}, Y = {pop}, S = {up, down}, δ ext (up, < any >, push) = down δ ext (down, < any >, pull) = up

69 Chapter 3. Defining the dynamic behavior of metamodeled languages 57 Port xtr1 itr1 Up Down xtr2 itr2 Figure One-slot toaster VAF model AnimDTSS PortInOut PortTick PortTick AnimScheduler Guard: PortInOut.Any() Action: lastevent=portinout.top() t1 State2 TimeOut=c <<internal>> State1 Action: Fire<Tick>(PortTick) Guard: PortTick.Any() t2 Action: <<perform state change, fire events>> Figure Simulating DTSS with VAF δ int (down) = up ta(up) =, ta(down) = 40, Y (down) = pop The toaster has two states: up and down. If it receives a push event when it is in the up state, then it goes to the down state and stays there until it receives a pull event or the timeout (40) expires. If the state changes from down to up after the timeout, then it emits a pop event. Figure 3.13 presents the corresponding VAF model provided that the start state is up. The external transitions are xtr1 and xtr2, while the internal transitions are itr1 and itr2. According to the construction, itr1.delay = 0 and based on the specication, itr2.delay = 40 and itr2.action = F ire < EventP op > (P ort). The guard expressions of the external transitions test the existence of appropriate events on the port: xtr1.guard = P ort.p eekisoft ype < EventP ush > () and xtr2.guard = P ort.p eekisoft ype < EventP ull > () Expressing DTSS with VAF By exploiting the fact that we can dene global variables in VAF animations, we can model a (potentially) innite number of states. Since the DTSS specication does not need an innite number of internal events (compared to the DEVS specication), we can simulate it with VAF provided that the state space of the DTSS can be modeled by the global variables of VAF. Proposition Given a DTSS M = X, Y, Q, δ, λ, c there is a (not necessarily unique) VAF animation that simulates it. Proof. In the following, we show how we can construct a VAF animation simulating M. Let us build the animation model depicted in Figure We can simulate a DTSS system with two animators: the one (AnimScheduler) is used to generate scheduling events periodically and the other (AnimDT SS) is used to realize the state

70 Chapter 3. Defining the dynamic behavior of metamodeled languages 58 transitions of the original system. To each x X Y value we assign an event (e x ) in the animation system. In AnimScheduler, there is a single state (State2) with a T imeout of c and an internal event connecting the state with itself. This animator is activated with a c interval periodically, and sends a T ick event to AnimDT SS. In AnimDT SS, the input values of the simulation are expected on the P ortinout port. AnimDT SS contains a single State (State1) connected to a start state. State1 has two external transitions t1 and t2. The transition t1 triggers input events on P ortinout and always stores the received input in a lastevent global variable, thus, when performing the periodic state transition of the DTSS system, the input value will be available. However, the corresponding event has already been removed from the port. The t2 transition triggers the emission of the T ick event, and performs the state transition corresponding to that of the DTSS system on the global variables of the animation. Note that we need to remove and store the input events regularly, otherwise the incoming values would be collected on the port even if we always need the last one Example As an example, consider a stopper that emits a time stamp on its output every time unit ( c ) after receiving the start signal on its input, and stops working after receiving a stop signal. The corresponding DTSS system is: X = {start, stop}, Y = N (natural numbers), Q = N, δ(x, start) = x + 1 δ(x, stop) = 0 λ(x) = x c = 1 In the corresponding VAF model, we should have three types of events: (i) T ick with a T imestamp integer property (thus, we can model the output events of the DTSS system), (ii) Start and (iii) Stop. The T imeout of State2 should be set to c, and the animator should have a q global variable with integer type to model the possible states. Finally, the Action property of the t2 transition should be set as follows. if (lastevent is Start) { q = q + 1; Fire(PortInOut, new Tick() { TimeStamp = q }); } else { q = 0; } 3.10 Conclusions This thesis focuses on the denition of animation of visual languages. In contrast to other tools, we made a considerable eort to model and visualize the animation logic. We have presented an architectural concept, where the animation is separated from the domain-dependent knowledge.

71 Chapter 3. Defining the dynamic behavior of metamodeled languages 59 The event-based integration of the separated components incorporating the domain knowledge is supported via visual modeling techniques. We have contributed two visual languages to describe the dynamic behavior of a metamodeled model, and their processing via an event-based concept. The services of the presentation framework and the domain-specic extensions are wrapped with event handlers. Event handlers can also be used to integrate external components, simulation engines into our environment. The denition of event handlers is supported with visual languages and code generation facilities. The other visual language is used to describe the animation logic with the help of a state chart-like formalism and to connect event handlers and state machines. On executing an animation, the state machines are transformed into executable source code. The events produced by the event handlers and the state machines are scheduled and processed by a DEVS-based simulator engine. We have formalized the operational semantics of animation models with ASM formalism. We have shown that by using VAF, we can simulate arbitrary DTSS and deterministic nite state DEVS formalized systems. We have proved that the transformation processing the models always terminates and processes only connected models whose states are reachable from the start states. We have formalized the concrete behavior of the execution framework and the generated code with ASM. We have dened a bijection between the states of the two ASMs, and proved that it is a bisimulation of the two systems, i.e. the implementation tightly corresponds to the specication. The feasibility of the presented concepts is illustrated by building a Petri-net animator based on VAF.

72 Chapter 4 Compile-time performance optimization of model transformation systems 4.1 Introduction Using model transformation is a popular technique to simulate domain-specic models. However, this is often a computationally intensive process. Motivated by this fact, the modeling community regularly organizes competitions that, among others, target the performance optimization of simplied simulation exercises ([GraBaTs08, 2008, GraBaTs09, 2009, TTC2010, 2010]). Furthermore, model transformation is also widely used to process models and convert them into other domains in the MDE. As presented earlier, we use model transformation to process Animation Framework models and produce executable source code. Although, the code generation phase is performed independently from the animated models, increasing the speed of the generation would make testing and debugging animation models more comfortable. The execution of graph rewriting rules can be divided into two main phases: the matching phase (searching for the LHS in the host graph) and the rewriting phase (replacing the found match with the RHS). The execution time of the rewriting phase can be considered constant (i.e. it does not depend on the size of the host graph but on the size of the changed parts of the RHS). Thus, from the performance's point of view the bottleneck of a rule application is the matching phase: it determines the speed of the overall transformation. Unfortunately, the problem of matching an isomorphic subgraph is NP-complete [Garey and Johnson, 1990, Flores et al., 1977] in the size of the subgraph. However, heuristic methods produce reasonably fast solutions in many practical cases. Although, there are several dierent graph transformation tools available [Varró, 2004a, Geiÿ et al., 2006, Klein et al., 1999, Zündorf, 1996, Taentzer, 2004, Vizhányó et al., 2004], they usually follow the same rule application principle: the execution of the production rules is completely separated. The matching phase of various, structurally similar rules is not connected. After the execution of a production rule, the information regarding the match is dropped, the matching phase of the next production rule starts from scratch. This fact has motivated our work to elaborate techniques that target these shortcomings.

73 Chapter 4. Compile-time performance optimization of model transformation systems Related Work The matching algorithm itself is usually very simple. It iterates through the elements of the pattern graph in an appropriate order, and searches for a matching element satisfying the following conditions for each of them. (i) The type of the matched element should be equal to (or in case of inheritance or compatible with) the type of the pattern element, (ii) it should satisfy the individual constraints of the related pattern element, and (iii) of course, the found element should satisfy the context requirements specied by the rule. Condition (iii) expresses that if a node and an edge is connected in the pattern graph, then their images in the host graph should be connected as well. The execution of a typical rewriting rule is illustrated by Algorithm 4.1. EXECUT E p Algorithm 4.1 Typical execution of a rewriting rule 1: function EXECUT E p (G) 2: for all e 1 T 1 (G) : γ p 1(e 1 ) do 3: for all e 2 T 2 (G) : γ p 2(e 2 ) do 4:... 5: for all e n T n (G) : γ p n(e n ) do 6: if γ p (< e 1,..., e n >) then 7: REW RIT E p (< e 1,..., e n >, G) 8: return true 9:... 10: return false 11: end function realizes the p rewriting rule executed over the G host graph. The algorithm consists of nested loops: one loop is assigned for each p i element in the pattern graph. T i (G) denotes those elements of the G host graph whose types are compatible with the p i pattern element in the p rule. γ p i(e i ) summarizes the conditions (ii) and (iii). Namely it returns true, if e i satises the individual constraint assigned to it in the p rule, and if e 1.. e i elements preserve the edges of p. If a matching element has been found for each element of the pattern graph, then the global constraint for the pattern is veried (γ p (<e 1,..., e n >), and the rewriting is performed (REW RIT E p (<e 1,..., e n >, G)). If there is no matching element in G for the ith element of the pattern, a backtrack is performed, and the (i 1)th loop continues the matching. Recall that most graph transformation engines apply an algorithm similar to the presented one. The main dierences in the concrete realizations are the order of the pattern elements processed during the matching and the data structures they use to represent the graphs. The order of the matched pattern elements is often referred to as the search plan of the rule. The search plan highly inuences the overall speed of the matching phase. [Batz et al., 2007] and [Zündorf, 1996] present dierent cost models and heuristics to make dierent search plans comparable to each other and facilitate the selection of an optimal search plan according to the heuristics. The VF2 [Cordella et al., 2001] algorithm proposes ecient data organization for Algorithm 4.1 to improve performance that way. The graph and model transformation community usually applies [Varró, 2008] the variants of the Ullmann [Ullmann, 1976] and the VF2 algorithms that conform to the matching phase of Algorithm 4.1. There are several other approaches (e.g. [Valiente and Martinez, 1997]) that optimize the execution only for special cases (e.g. not connected patterns), while other algorithms

74 Chapter 4. Compile-time performance optimization of model transformation systems 62 [Chen et al., 2005, Fu, 1997, Gupta and Nishimura, 1996, Lingas, 1989, Lingas and Syslo, 1988, Shamir and Tsur, 1999, Verma and Reyner, 1989] provide ecient solutions for only a restricted class of graphs (e.g. for directed acyclic graphs, or trees) Graph transformation engines VIATRA2 [Varró, 2004a] uses a cost model [Varró et al., 2006a] to generate a search plan for the execution of a rule. Cost calculation is based on the creation of a search graph that models the basic operations (element enumeration, navigation) of the matching as nodes. Nodes in the search graph are connected with weighted edges, which weight is derived from the number of potential backtracks originated in matching an element. The search plan generation is originated in nding a minimum directed spanning tree (DST) in the search graph using the Edmonds algorithm [Edmonds, 1967]. [Varró et al., 2006] presents an approach that dynamically selects the most appropriate search plan at run-time, based on statistical data collected from the modied host graph. GrGen.NET [Geiÿ et al., 2006, Batz et al., 2007] is a graph transformation tool implementing the SPO (single pushout) [Ehrig et al., 2006] approach. The cost model of GrGen.NET extends the solution of VIATRA2 by considering the cost of performing a primitive step in the matching as well. Furthermore, instead of optimization by searching for a minimum directed spanning tree in the plan graph, the solution searches for a minimum multiplicative directed spanning tree, thus minimizing the product of the costs instead of their sum, therefore, they can reach more accurate solutions. The cost model utilizes not only static information and information derived from the metamodel, but also the statistics derived from the current host model. GrGen.NET does not use xed matching strategies, instead it optimizes the matching strategy at runtime depending on the actual host graph. In FUJABA (From UML to Java and Back Again) [Klein et al., 1999], the combination of activity diagrams and collaboration diagrams are used to express control structures. A storydiagram [Fischer et al., 2000] is written in a visual programming language that facilitates the specication of complex application-specic object structures. FUJABA uses a breadth-rst search strategy to nd a match in the host graph. The matching starts from a pivot node xed by the designer. The matching strategy is generated at compile time for each rule. PROGRES [Zündorf, 1996] uses a sophisticated operation graph to describe each primitive step of the matching including the enumeration of nodes, navigation along edges or even the verication of attribute constraints. PROGRES also provides a cost model to estimate the overall cost of valid search plans. However, cost calculation does not take the statistics of the current host graph or the properties of the metamodel of the host graph into account, but uses the assumptions based on a typical domain the tool is planned to be used on. AGG [Taentzer, 2004] is a development environment for attributed graph transformation systems supporting algebraic approaches to graph transformation. It aims at specifying and rapid prototyping applications with complex, graph structured data. AGG graphs may be attributed by Java objects and types. The graph rules may be attributed by Java expressions which are evaluated during rule applications. Additionally, rules may have attribute conditions as Boolean Java expressions. The Graph Rewriting and Transformation (GReAT ) [Vizhányó et al., 2004] framework is a transformation system for domain-specic modeling languages built on metamodeling and graph rewriting concepts. The control structure of the GReAT allows specifying an initial context for

75 Chapter 4. Compile-time performance optimization of model transformation systems 63 the matching to reduce the complexity of the general matching case. The pattern matcher returns all the possible matches to avoid the inherent non-determinism in the matching process. The execution engine chooses a path nondeterministically, and the chosen path is executed completely before the next path is selected. The attribute transformation is specied by a proprietary attribute mapping language whose syntax is close to C. LHS of the rules can contain OCL constraint to rene the structure but postconditions are not supported. GReAT uses breadth- rst traversal to nd a match. The traversal starts from nodes initially matched (referred to as pivoted pattern matching [Vizhányó et al., 2004]). Amalgamated rules describe the synchronized application of two derivations. This is achieved by identifying a common subproduction. The subproduction species the shared eect of the original production rules. Given two rules p 1 and p 2, their synchronized production is denoted by g 1 g 2 p 1 p0 p2. The productions may be glued together by using p 0 leading to the amalgamated production p 1 p0 p 2. A direct derivation G p 1 p0 p 2 = H is called amalgamated derivation. Note that this derivation means the simultaneous application of p 1 and p 2, where the common actions (p 0 ) are applied only once. Therefore, if p 0 is empty, we receive the parallel production p 1 + p 2. The concept of this synchronization was rstly introduced in [Boehm et al., 1987]. Note that by gluing p 1 and p 2 together along p 0 we restrict the application of both rules to matches sharing the same common match. This restriction means a limitation for optimization in contrast with our approach. Varró et al. have published a technique called Incremental pattern matching [Varró and Varró, 2004, Varró et al., 2006b] that stores parts of the matches and reuses them in other rewriting rules within the same transformation. Their approach is based on the RETE algorithm [Forgy, 1974], it uses sophisticated data structures and algorithms to store matches and to update the data structures during the transformation. The approach is particularly ecient in case of query-intensive transformations with only a few updates. Based on measurement results, it can improve the overall speed of the transformation by orders of magnitude. The drawback of this approach is that it performs much of its computation at runtime. In case of transformations that intensively modify the host graph, the overhead of maintaining these data structures may slow down [Varró et al., 2006b] the transformation compared to the non-optimized version as well. Furthermore, the approach stores each possible match for the selected common patterns of the rules, which solution may highly increase the memory requirement of the transformation. [Bergmann et al., 2009] introduces the combination of the incremental and the search plan-based approach in VIATRA2. An overlapping approach exploiting the structural similarity of rewriting rules was published in [Dörr, 1995]. The presented solution discovers the largest common subgraph of the overlapped rewriting rules, and after nding a match for the common subgraph, it tries to complete the partial match for a complete match for either of the participant rules. In case of overlapping more than two rules, the common subgraph may be extended to a larger common subgraph for a subset of the rules. The approach has several weaknesses, though. It is designed for layered rule execution only: it applies either applicable rule, and proceeds to the following rule. It does not support control-ow like rule ordering and precedence among the rules. Nor does it support the rst-t (Denition 2.32) and the iterative execution (Denition 2.34) of consecutive rules. After applying a single rule, it drops all partial matches, and starts the matching from scratch. Furthermore, its heuristics selects the largest common subgraphs that is not necessarily optimal, as it does not consider the cost of primitive matching steps.

76 Chapter 4. Compile-time performance optimization of model transformation systems Problem Statement As already shown, existing solutions are limited to restricted classes of graphs or control sequences. Since the speed of the matching phase determines the overall performance of a graph transformation system, the aim of this thesis is to provide an compile-time technique that optimizes the execution of the matching phase of the rules without structural limitations on them or on the host graph. In our approach, we assume deterministic ordering of the rules: the rules follow each other according to a strict order, however, the matches of an individual rule are chosen arbitrarily. This section provides solutions for the following problems: Optimize the matching phase of exhaustively executed rules by preserving partial matches of the previous execution of the same rule. Elaborate a matching technique that exploits the structural similarity of rewriting rules by overlapping common subgraphs of consecutively executed rules in control ow-based graph transformation engines. Provide solutions for the following matching techniques of control ow-based graph transformation systems: rst-t, exhaustive, and iterative methods. Overlapping the execution of dierent rules should not change the semantics of the transformation, i.e. it should produce the same resulting host graph as without the optimization. The technique should be applicable to any host graphs and patterns without any structural restrictions. The technique should not cause noticeable additional memory or administration overhead at runtime. As heuristic optimizations may not improve performance in all the possible cases, the achieved performance gain/loss should be estimated to decide about the application of the technique. 4.4 Basics Our overlapped matching technique harnesses the similarity of consecutively executed rules: it interleaves the matching phase of dierent rules by matching the common subgraphs only once. Since this common subgraph is a subset of the individual LHSs, our algorithm tries to complete it for each rule. If a match on the common subgraph can be extended to a complete match, the rewriting phase of that rule can be executed. Overlapping can be applied several times in a hierarchical way as well: the idea is that overlapped rule sets can be overlapped again. For a better understanding, the algorithm is presented rst in an intuitive manner through a concrete example. We assume a graph transformation system GT S = (T G, P ) with rules P = {p 1, p 2, p 3 }. The respective LHS graphs L 1, L 2, L 3, and the host graph G are depicted in Figure 4.1. We would like to point out that the subgraphs (1) (a) (2) of L 1, (1 ) (a ) (2 ) of L 2, and (1 ) (a ) (2 ) are isomorphic. Furthermore, this common subgraph can be extended in the case of L 2 and L 3 with (1 ) (b ) (3 ) and (1 ) (b ) (3 ), respectively. Instead of executing the three rules independently, it would be more ecient to search for all the subgraphs in G isomorphic to (1) (a) (2) and extend the matches found (if possible). If the (1) (b) (3) submatch is found, matching of L 2 has been nished. However, the match still can be reused: if it can be extended with a submatch (1 (c ) (4 ), then a match for L 3 is also

77 Chapter 4. Compile-time performance optimization of model transformation systems 65 (4' ) (3' ) (3') (1) (2) (a) (c ) (b ) (1' ) (a ) (2' ) L 3 (H) (J) (K) (I) (i) (ii) (iii) (iv) (b ) (1') (a ) (2') (b) (L) L 2 (3) L 1 (iv) G:Host graph Figure 4.1. Overlapped matching of rules found. The matching of L 1 can be nished if the (1) (a) (2) submatch can be extended with a match (2) (b) (3). We do not claim that the submatches found are applicable to all the participating rules, only that we do not have to calculate the same submatch several times for dierent rules. Considering the single execution of consecutive rules, the main dierence compared to [Dörr, 1995] is that we reuse existing partial matches for consecutive rules as well, while the [Dörr, 1995] approach restarts the matching if either of the overlapped rules is successfully executed Denitions In this section, we present the necessary denitions that are used when formalizing the algorithms. Denition 4.1 (Match Set). Given a typed attributed graph G and a rewriting rule p : (L K R, X ). Match set Match(L, G) is the set of all matches for L in G, i.e. the set of all injective homomorphisms m : L G for that m = X. Let m i mean an injective partial homomorphism m i : L G (i.e. an initial match) which binds several elements of L to the elements of G. Then MatchI(m i, L, G) Match(L, G) means the set of those matches in Match(L, G), for which m i (x) = m(x), m MatchI(m i, L, G). It is possible that the overlapped matching technique nishes the matching of the rules in an order dierent from the predened application order. Given two rules p i, p j suitable for overlapped matching, we expect that a match m j : L j G of p j exists before and after the execution of p i. However, we do not expect p i to preserve the attributes selected by m j. Only the attribute conditions X j on m j have to be satised both before and after executing p i. We will show later that this is a satisfactory condition for the rst-t algorithm, as we preserve the execution order of the rewriting phase of the rules. Denition 4.2 (OLRA Enabledness). Given a typed attributed graph transformation system GT S = (AT G, P ), P = {p i : (L i K i R i, X i )}. Two graph productions p i, p j P are overlapped rewriting algorithm enabled, if direct graph transformations t 1 : G m i,p i = H1 and t 2 : m j,p j H 1 = X are sequentially independent for all G, mi, m j, and the status of X i and X j is not inuenced by the prior execution of p j and p i. That is, if m i = X i before executing p j, then m i = X i after executing p j as well. Similarly, if m i = X i before executing p j, then m i = X i after executing p j either (i j) for all possible m i matches.

78 Chapter 4. Compile-time performance optimization of model transformation systems 66 Denition 4.3 (Overlappable LHS Set). Given a typed attributed graph transformation system GT S = (AT G, P ) with pairwise OLRA enabled rules P = {p i : (L i K i R i, X i )}. We denote an arbitrary subset of LHS graphs with LSet l {L i i 1..n}, and LSet 0 is the set containing all the overlappable rules, i.e. LSet 0 = {L i i 1..n}. We would like to point out that the overlapped matching can be hierarchical: the idea is to overlap the matching phase of several rules along a common sub-pattern, then overlap several overlapped rules again. Therefore, we introduce the P art function which partitions an overlappable LSet into disjoint real subsets. These subsets contain the rules that can be overlapped along a (probably larger than the previous) common pattern again. Denition 4.4 (LHS Set Partitioner Function). Denoting the powerset of S with P(S), let P art (k) : P(LSet 0 ) P(P(LSet 0 )) be the LHS set partitioner function, such that LSet i P art (k) (LSet) LSet i = LSet and LSet i, LSet j P art (k) (LSet) : LSet i LSet j =Ø, i j. The (k) index identies one such function among the various possibilities. Denition 4.5 (Common Subgraph, overlapping). A possible common subgraph of LSet l is denoted by L (k) l, i.e. there exist common (k) l i : L (k) l L i injective homomorphisms for each L i LSet l. Furthermore, considering LSet m LSet l, exists map (k) l m : L(k) l L (k) m injective homomorphism, such that common (k) l i = common(k) m i map(k) l m. Namely, the common subgraph of a subset contains the common subgraph of the container set. P art (k), L (k), common (k) and map (k) together dene an overlapping. The index (k) identies one common subgraph of the various possibilities. This common subgraph is not necessarily the maximal one, it is selected based on the heuristics to minimize the overall cost of the transformation. 4.5 Overlapping First-Fit Executed Rules In this section, we introduce the rst-t execution algorithm that serves as the basis for the exhaustive and the iterative version as well. We assume in the following (based on the problem statement Section 4.3) that the execution order of the graph production rules p 1, p 2... p n is xed, i.e. p i is always followed by p i+1. The core of the algorithms is as follows: Having an arbitrary LSet l set for which there is L (k) l, we generate the m l matches for L (k) l. We split LSet l into smaller subsets using P art (k), and try to extend the m l matches to valid matches for each L (k) m, LSet m P art (k) (LSet l ). Then, we apply the algorithm recursively for each LSet m again, until LSet m = 1, when the algorithm has nished the matching of a particular L i (LSet m = {L i }). To be able to overlap rst-t executed rules, it is expected that the rules are pairwise OLRA enabled. Algorithm 4.2 realizes the method that overlaps the matching phase of rst-t executed rules. The core of the algorithm is realized in the SubMatch function. It searches for matches for the current common subgraph L (k) l, and calls itself recursively for each pattern subset P art (k) (LSet l ) to extend the common match. When the matching of a rule has been nished successfully, the corresponding ism atch ag is set. In this way we can control the recursive calls, and perform them only if the matching phase of either rule in the parameter set has not been successfully nished earlier.

79 Chapter 4. Compile-time performance optimization of model transformation systems 67 Algorithm 4.2 Overlapped rewriting rule for rst-t execution 1: ismatch Li := false, i := 1..n //reset ags 2: SubMatch({LSet 0 }, ø) //start matching 3: //perform rewriting 4: for i := 1 to n do 5: G := REW RIT E pi (m Li, G) 6: 7: proc SubMatch(LSets, m LSet ) 8: for all LSet l LSets do 9: for all m l MatchI(m LSet, L (k) l, G) do 10: //if LSet l contains only one element 11: if LSet l = {L i } then 12: m Li := m l 13: ismatch Li := true 14: //else if the LHS set contains non-matched LHSs: 15: else if L i LSet l : not ismatch Li then 16: SubMatch(P art (k) (LSet l ), m l ) 17: if L i LSet l : ismatch Li then 18: break forall 19: end proc As the set of rewriting rules is nite, and the application order of the rules is xed, the P art (k) function calls can be evaluated independently of the host graph. The recursive algorithm can be "attened", thus specializing it for a specic graph transformation system (for one of its overlappable segments). Note that the algorithm may nd the matches for the rules in an order dierent from their original order. However, the execution order of the rewriting phases is preserved. Proposition 4.6. Given a typed attributed graph transformation system GT S = (AT G, P ). For all rules (p i, X i ) P, if p i has matches m 1 L i...m k i L i, then the overlapped algorithm (Algorithm 4.2) nds the same m 1 L i...m k i L i matches for p i as well. Proof. (With induction) The following diagram illustrates the overlapped matching process. L (k) 0 = map 0 1 L (k) 1 = m 0 m 1... L (k) x m x = common x i L i m Li G The map x y and common x y mappings are unambiguously dened. Thus, m Li nes the m 0..m x partial matches. exactly de- 1. If LSet 0 = {L i } then the algorithm enumerates each match for L i, thus, it can nd m Li.

80 Chapter 4. Compile-time performance optimization of model transformation systems If {L i } P art (k) (LSet 0 ) (L i is overlapped with other rules on one level), the algorithm rst searches for each m 0 match (for L (k) 0 ), these matches include m Li common 0 i. If a match is found it tries to extend m 0 to a complete match for L i. If another match for L i is not found before, it tries to extend common x i m Li as well, thus, it nds m i. 3. Assume that the algorithm can nd a match for a rule overlapped with other rules on n level. 4. If we have rules overlapped on n + 1 levels, then the algorithm rst searches for matches for L (k) 0. These matches include map map n 1 n common n i m Li. Then it tries to extend it to an m 1 match for L (k) 1. This can succeed with map map n 1 n common n i m Li. This match can be considered a partial match for L (k) 1 in an n-level overlapping, and the algorithm - based on the inductive hypothesis - can extend this match to m i. Because of the OLRA enabledness of the overlapped rules, a production rule p j cannot create a new or disable an existing match for another p i rule ( i j), thus, the same m Li matches of p i exist before and after executing a p j rule. Even if the overlapped algorithm nishes the matching of the rules in P in a dierent order compared to the predened, the set of possible matches does not change. m Proposition ,p 1 m 2,p 2 m n,p n Given a graph transformation sequence G 0 = G1 =... = Gn. If the overlapped algorithm nds m 1 for p 1... m n for p n as well, then after the overlapped execution ( G 0 m 1...m n,p 1...p n G n ) the resulting G n and G n are both structurally and attributewise isomorphic. Proof. Since the structure of the matches are the same, the structure of G n and G n are isomorphic. Although we expect the rules not to modify the matches of another rule structurally, the attributes of the matched elements may be changed in an arbitrary way by the rules. The rewriting phase is separated from the matching phase in case of the overlapped execution, and they are executed in the original sequential order (1..n). Thus, the resulting attribute conguration of the graph elements matches that of the elements after executing the rules without overlapping. 4.6 Overlapping Exhaustively Executed Rules With the trivial extension of Algorithm 4.1, we can produce the exhaustive execution as illustrated by Algorithm 4.3. Here we execute the EXECUT E p function in a loop until it returns f alse, i.e. it cannot nd any match. We consider this algorithm to dene the default behavior of the exhaustive execution in the following. Algorithm 4.3 Exhaustive rewriting rule execution 1: function EXHAUST IV E p (G) 2: ismatched = true 3: while ismatched do 4: ismatched = EXECUT E p (G) 5: end function If we overlap exhaustively executed rules, we cannot preserve the execution order of the rewriting phase of the rules (as we cannot cache the matches like in case of the rst-t execution

81 Chapter 4. Compile-time performance optimization of model transformation systems 69 because of their large number), thus, we need a stricter condition compared to OLRA enabledness. We not only need the rules to preserve the matches of other rules, but also the commutativity of the attribute operations of the rules, i.e. executing them in an arbitrary order results the same nal attribute conguration of the processed elements. Denition 4.8 (strong OLRA enabledness). Given a typed attributed graph transformation system GT S = (AT G, P ) with OLRA enabled production rules p i p j P. If for all direct graph transformations t 1 : G m i,p i m j,p j = H1 and t 2 : H 1 = X the transformations can be applied in the reverse order without changing the resulting graph then p i and p j are strongly OLRA enabled. Algorithm 4.4 illustrates a matcher which executes exhaustive rewriting rules in the overlapped way. The overlapped application of exhaustive rules requires the component rules to be strongly OLRA enabled and the overlapping to be strongly executable. The algorithm is based on the one presented for the rst-t execution. The dierences are summarized in the following three points: (i) The core of the algorithm (SubMatchX) is executed repeatedly in a loop while it is successfully executed on any of the overlapped rules. (ii) Instead of caching the matches of the rules, they are executed as soon as a match is found. This is necessary: because of the possible large number of matches, the original execution order cannot be preserved by caching the matches. (iii) If none of the overlapped rules have successfully been executed in the previous iteration of the topmost loop, a recursive call of SubM atchx is not performed. Algorithm 4.4 Overlapped execution of exhaustively applied rules 1: ismatch Li := true, i := 1..n 2: //repeat until no match is found for the LHSs 3: while L LSet 0 : ismatch L do 4: prevismatch L = ismatch L, L LSet 0 5: ismatch L := false, L LSet 0 6: SubMatchX({LSet 0 }, ø) 7: 8: proc SubMatchX(LSets, m LSet ) 9: for all LSet l LSets do 10: for all m l MatchI(m LSet, L (k) l, G) do 11: //if LSet l contains only one element 12: if LSet l = {L i } then 13: G := REW RIT E pi (m l, G) 14: 15: ismatch Li := true else if L i LSet l : not ismatch Li and prevismatch Li then 16: //continue recursion only if there is a non-matched LHS which was successfully executed the last time 17: SubMatchX(P art (k) (LSet l ), m l ) 18: if L i LSet l : ismatch Li then 19: break forall 20: end proc Proposition 4.9. The depth of the applied recursion in Algorithm 4.4 is at most the number of the overlapped rules ( LSet 0 ).

82 Chapter 4. Compile-time performance optimization of model transformation systems 70 Proof. Based on the denition of the P art function, it partitions its parameter set into disjoint real subsets, thus, LSet l LSets = P art(lset l) : LSet l < LSet l provided that LSet l > 1. The recursive calls terminate as soon as LSet l LSets : LSet l = 1. In an extreme case, P art always divides its parameter into two sets: one containing one item, and the other the rest. In this way, the halting condition of the recursion will be satised after LSet 0 calls. We expect the optimized algorithm to realize exhaustive behavior, thus, when it nishes there should not be any other matches for either of the rules: Proposition When the overlapped exhaustive algorithm (Algorithm 4.4) nishes, there are no matches left for p i, i.e. Match(L i, G) = ø, i. Proof. The algorithm executes successfully if ismatch L = false, L LSet 0. ismatch L is set to false the rst time when no match for L can be found. It is clear that if ismatch L is set to false, then the algorithm does not try to nd another match for L anymore. However, since the overlapped rules are strongly OLRA enabled, the execution of other rules cannot create a match for L either. Proposition If each individual rule terminates, then the overlapped execution terminates as well. Proof. The presented algorithm can run innitely because of three reasons: (i) an innite recursion occurs, or (ii) either of the for loops never exits or (iii) the while loop never exits. (i) can be excluded based on Proposition 4.9. (ii) can be excluded, because that would mean that for either subpattern, an innite number of matches can be found in the host graph, thus, the host graph itself would be innite as well (because of the strong OLRA enabledness of the rules they cannot generate matches for each other). (iii) is not possible, because it would mean that L : ismatch L = true in each round, thus, either of the rules could be executed for an innite number of times, which contradicts the initial condition of the proposition. In the following, we show that the basic exhaustive algorithm is universal, and can produce all the possible correct execution sequences: Proposition Assume that a p production rule is applied to a G 1 host graph in an exhaustive m 1,p m 2,p manner. Then for each exhaustive G 1 = G 2 =... m k,p = G k graph rewriting sequence ( m : L p G k ), Algorithm 4.3 produces the same execution sequence. Proof. As the enumeration order of the for all loops is not dened and is not expected to be deterministic, the EXECUT E p (Algorithm 4.1) function has an execution (among others) that nds the m i match in G i for each i. Thus, Algorithm 4.3 has an execution sequence that is equal m i,p to the...g i 1 = G i... sequence. No we show that the overlapped execution always produces one of the possible correct execution sequences: Proposition Given a GT S = {p 1,..., p n } consisting of strongly OLRA enabled exhaustive m k 1,p ik 1 = m 1,p i1 m 2,p i2 rules applied sequentially to a G 1 host graph. Assume that G 1 = G2 = G3... G k is an exhaustive execution sequence (i.e. m : L p G k, p) performed by Algorithm 4.4. m 2,p i 2 m 1 Then there exists a G,p i m 1 1 = G 2 = G 3... k 1,pi k 1 = Gk execution sequence performed by the consecutive execution of Algorithm 4.3 with the dierent p i rules: EXHAUST IV E p1 (G), EXHAUST IV E p2 (G),..., EXHAUST IV E pn (G).

83 Chapter 4. Compile-time performance optimization of model transformation systems 71 Proof. Because of the strong OLRA enabledness of the p i rules, exists π : {1..k 1} {1..k 1} m π(1),p iπ(1) permutation, so that G 1 = G m π(2),p iπ(2) 2 = G m π(k 1),p iπ(k 1) 3... = G k graph transformation sequence exists, and i π(x) i π(x+1), 1 x k 1 and 1 x < y k 1 : i π(x) = i π(y) π(x) < π(y). This means that we can reorder the individual transformations to have all the executions of each production rule in one group but keeping the original order of the m π(x),p iπ(x) transformations inside the group. Based on Proposition 4.12, for each exhaustive G x =... m π(y),p iπ(y) = G y+1 transformation sequence ( 1 x < y k 1, (x = 1 i π(x) i π(x 1) ) (y = k 1 i pi(y) i π(y+1) ) (x < x y i π(x) = i π(x ))) there is an equivalent execution of Algorithm 4.3, thus, the complete execution sequence with all the rules can also be realized with the consecutive applications of Algorithm Overlapping Iteratively Executed Rules Iterative execution is usually applied, when we have a set of elements, and we would like to execute a specic rule exactly once on each of them. In order to be able to overlap iteratively executed rules, in addition to strong OLRA enabledness, additional conditions must also be satised: Denition 4.14 (overlappable iterative rules). Assume P = {p 1..p n } strongly OLRA enabled rules executed iteratively by their L I i sub pattern over the corresponding Mi I initial match set. The p i rules are overlappable if (i) Mi I = Mj I = M I, and (ii) there exist li I, lj I bijective homomorphisms and li,, I lj, I injective homomorphisms for i, j 1..n, such that the following diagram commutes: L i L j map (k) 0 i map (k) 0 j l L I i,i I i = li, I li I = L (k) l 0 I L I = = lj, I lj I l I j,j Thus, the initially bound elements of each rule can be found in the L (k) 0 intersection of the LHS patterns as well, and the bound elements are iterated over the same M I initial match set. Figure 4.2 illustrates the overlapped execution of three iterative rules on the same M I initial match set. The execution iterates through the elements of the M I initial match set. After selecting an m I initial match from the set, a match is tried to be found for L 1, L 2 and L 3 by completing the m I initial match. In the presented example, L 2 and L 3 can be matched, thus, the related rules can be executed. However, L 1 cannot be matched with the given m I, thus, the related rule is not applied in the current iteration. Algorithm 4.5 illustrates the rewriting algorithm used for the overlapped execution of iterative rules. It extends Algorithm 4.2 at two points: (i) m I initial matches are selected in a loop from the M I initial match set, and the rst-t approach is executed for each of them, (ii) the rewriting is performed as soon as a match is found. Proposition By applying iteratively executed production rules satisfying Denition 4.14 in the overlapped manner, the resulting host graph will match that of the non-overlapped execution. L I j

84 Chapter 4. Compile-time performance optimization of model transformation systems 72 m I L 3 L 2 M I Initial match set Fragment of G host graph (1) L 1 Figure 4.2. Overlapped matching of iterative rules Algorithm 4.5 Overlapped execution of iteratively applied rules 1: for all m I M I do 2: ismatch Li := false, i := 1..n 3: SubMatchI({LSet 0 }, m I ) 4: 5: proc SubMatchI(LSets, m LSet ) 6: for all LSet l LSets do 7: for all m l MatchI(m LSet, L (k) l, G) do 8: //if LSet l contains only one element 9: if LSet l = {L i } then 10: G := REW RIT E pi (m l, G) 11: ismatch Li := true 12: else if L i LSet l : ismatch Li then 13: SubMatchI(P art (k) (LSet l ), m l ) 14: if L i LSet l : ismatch Li then 15: break forall 16: end proc Proof. The enumeration order of the m I initial matches is the same for each p i production as in case of the sequential execution. This is an important property of the algorithm. Although, p i and p j are strongly OLRA enabled for each i j, p i applied at m I k initial match may inuence the execution of p i at m I l initial match. The execution of graph production p i may precede the execution of p j (i > j) having an initial match m I, however because of the strong OLRA enabledness of p i and p j this is equivalent to the reversed execution. Consequently, the execution of p i rules on m I initial matches in an overlapped way can always be reordered to match the execution order of the non-overlapped processing.

85 Chapter 4. Compile-time performance optimization of model transformation systems Heuristics to Estimate the Total Cost of the Overlapped Matching It is important to estimate the matching cost of overlapped rules in order to decide whether to perform overlapped matching, or execute the rules separately. To estimate the cost of matching for a single rule, we use the BacktrackingOnly heuristics presented in [Geiÿ et al., 2006]. It tries to minimize the overall cost of the execution of a rule by minimizing the possible backtracks when matching an element. We have extended this heuristics with the estimation of matching cost of overlapped rules. We denote the matching cost of a single L pattern by C L. Assume that L i LSet l, and we have already found an m l match for L (k) l m Li C (k) L l match for L i is denoted by C Li L (k) l C Li L (k) l in C (k) L time. Then the cost of extending m l to an l. The overall cost of matching L i in two parts is thus. Assume that L j LSet l as well, and we perform an overlapped matching of L i and L j along L (k) l. As the cost model presented in [Geiÿ et al., 2006] can be considered a worst-case calculation for an average host graph, we may decrease the total cost of matching the two rules in an overlapped way by C (k) L. The idea behind this is that we do not have to generate the matches l for the common parts twice. Thus, the total cost is C {Li,L j } = C (k) L (C l Li + C L (k) l Lj 1). By L (k) l extending this formula to n rules overlapped along the same common pattern, the cost can be n calculated as C LSetl = C (k) L (1 n + C l Li ). If we allow the rules to be overlapped on an L (k) l arbitrary level, the result is a recursive expression: CLSet P art(k) l L C P art(k) ), where C P Q L (k) art(k) := C l Q L (k) (k) q L l l Q P art (k) (LSet l ) i, if Q = {q}. C P art(k) LSet l L = C (k) L (1 P art (k) (LSet l L l ) + denotes the total cost of matching the patterns in LSet l provided that their L common part has already been matched, and the P art (k) partitioning function is used to partition pattern sets. The cost of matching all the patterns in LSet 0 using the P art (k) function is CLSet P art(k) 0 = CLSet P art(k). The applied overlapping strategy (P 0 ø art(k) and L (k) common subgraphs) is selected such that CLSet P art(k) l is minimal among all, and CLSet P art(k) l < C Li i 4.9 Deep Exhaustive Execution A drawback of Algorithm 4.3 is that after nding a match for p, and performing the rewriting phase, the EXECUT E p function immediately returns, and the current state of the forall loops is dropped. A straightforward idea is to discover, when and which loops could continue searching provided that the remaining matches are still valid in the host graph. The rewriting phase (REW RIT E p ) of a rule may modify the host graph in the following six ways, or their combination: (ϕ 1 ) Create a new element that cannot be matched by either p i pattern element. (ϕ 2 ) Modify the attributes of an existing e i element without inuencing the evaluation of either γ p j (the constraints attached to the jth pattern element) or γ p (the constraints attached to the rule).

86 Chapter 4. Compile-time performance optimization of model transformation systems 74 (ϕ 3 ) Delete an e i element from the host graph. (ϕ 4 ) Modify the attributes of a matched e i element, and change thus γ p i or γ p from true to false. (ϕ 5 ) Create a new element that can be matched by either p i. (ϕ 6 ) Modify the attributes of a matched e i element, with the possibility to change either γ p j or γ p that was previously false to true (for the current or for any other match). Note that ϕ x properties are veried not for a specic < e 1,..., e n > match and G host graph, but independently from them. The matcher algorithm is created based on the transformation denition only, thus, no further overhead is necessary at runtime. However, it will not be able to exactly evaluate each property without the host graph and the match. We have created a reference implementation that veries the ϕ x properties. It is capable of handling simple cases only (with simple attribute modications, and attribute relations). If the heuristics cannot evaluate a ϕ x unambiguously, then it assumes the worst case: namely in case of ϕ 4, ϕ 5 and ϕ 6 it considers that they apply to REW RIT E p. Thus, we do not to lose matches or nd invalid ones. The properties ϕ 1 and ϕ 2 are irrelevant to the matcher algorithm. Cases ϕ 3 and ϕ 4 express that the current < e 1,..., e n > match became invalid, because e i has been changed (or deleted) in a way that it cannot be part of a valid match anymore. Thus, because e i+1...e n are matched after e i, they are considered to be invalid as well. If there are several invalid e i elements, and the one with the smallest i index is e min, then < e 1,..., e min 1 > partial match may still be extended to a valid < e 1,..., e min 1, e min,..., e n > match. This idea is called deep matching and is illustrated by Algorithm 4.6. The dierence from the original exhaustive algorithm is that after performing the rewriting phase, instead of leaving the function, the control jumps to the end of the forall loop body for matching e min. The < e 1,..., e min 1 > partial match is kept, and the matching continues with the following element for p min. ϕ 5 and ϕ 6 express that the modication of the host graph may produce further matches by creating new elements or modifying attributes of existing elements. If REW RIT E p has the ϕ 5 or ϕ 6 properties, then no further modication of Algorithm 4.6 is needed, as the possible new matches are discovered in the next turn of the top level while loop. In the following, we prove that the matches found by the algorithm are valid, and that it can nd all of them. Proposition If Algorithm 4.6 nds an m =< e 1,..., e min 1, e min,..., e n > match, then it is a valid match, i.e. there is a subgraph isomorphic to the graph dened by m, and satises the constraints of p. Proof. Provided that the original algorithm was correct, we have to prove that e 1...e min 1 is still a valid submatch. That is true, as the rewriting phase has not modied those elements, the γ i constraints do not refer elements in e min..e n and γ p is veried again for m =< e 1,..., e min 1, e min,..., e n > as well. Proposition Assume that a p production rule is applied on a G 1 host graph in the exhaustive manner. For each G 1 = G 2 =... m k 1,p m 1,p m 2,p = G k graph rewriting sequence of Algorithm 4.6 there exists the same execution sequence for Algorithm 4.3.

87 Chapter 4. Compile-time performance optimization of model transformation systems 75 Algorithm 4.6 Exhaustive rewriting rule execution with deep matching 1: function EXHAUST IV Ep deep (G) 2: ismatched = true 3: while ismatched do 4: ismatched = EXECUT E deep p 5: end function 6: (G) 7: function EXECUT Ep deep (G) 8: foundone := false 9: for all e 1 T 1 (G) : γ p 1(e 1 ) do 10:... 11: for all e min T min (G) : γ p min(e min ) do 12:... 13: for all e n T n (G) : γ p n(e n ) do 14: if γ p (< e 1,..., e n >) then 15: REW RIT E p (< e 1,..., e n >, G) 16: foundone := true 17: goto nextturn 18:... 19: label nextturn: 20:... 21: return foundone 22: end function Proof. Based on Proposition 4.16, for each m i match found by Algorithm 4.6 exists an isomorphic subgraph in the current G i host graph. Thus, we can apply Proposition In the following, we show that the algorithm has an exhaustive behavior, thus, it nds all the matches. Proposition Assume that a p production rule is applied on a G 1 host graph in the deep m 1,p m 2,p exhaustive manner using Algorithm 4.6: G 1 = G 2 =... m k 1,p = G k. If the algorithm terminates at the kth iteration m : L p G k match. Proof. Note that until applying the REW RIT E p instruction, EXECUT Ep deep is identical with Algorithm 4.1, thus, if m : L p G k match, it can nd it. As EXECUT Ep deep is applied exhaustively by EXHAUST IV Ep deep, when the algorithm nishes, there cannot be other matches for L p. Note that the EXECUT Ep deep function is applied at least twice if there is at least one match for the rule, even if at the second application it cannot nd any other match. If we can ensure that the rewriting phase does not generate new matches, this second execution can be omitted. Proposition If REW RIT E p satises ϕ 3 ϕ 5 ϕ 6, then the topmost while loop can be removed, and a single call to EXECUT E p (G) provides all the matches. Proof. After REW RIT E p, the e min item (matched for p min ) is deleted, thus, there is no match containing e min. Therefore, the algorithm can exit loops matching e min+1... e n, and match the

88 Chapter 4. Compile-time performance optimization of model transformation systems 76 next element for p min without skipping a possible match. Based on ϕ 5 ϕ 6, REW RIT E p does not modify the host graph such that a new match for p is created in it, the loops for p 1...p min do not need to be restarted Example Figure 4.3 illustrates the deep exhaustive execution of a P rule on a G host graph (for the sake of simplicity, the edges are not typed and labeled in this case). Considering that for the node (A) we match node (1), we can match (2) for (B) and (1 ) for (C). Then the rule deletes node (1 ) (and the connecting edge). Now, we do not have to restart the matching of rule P, but we invalidate the match of (C) and the connecting edge, and repeat the matching only of these two elements. Now we can nd (2 ) for (C), and perform the rewriting again. We invalidate the match for (C) again, but the (1) (2) match part cannot be completed anymore. However, we still do not have the restart the matching of P : we can step back to the phase, when only (A) was matched, and nish the matching with (3) (4 ), and similarly with (4) (3 ). (1') (4') (2) (2') (C) (3) (1) (B) (4) (3') (A) G: host graph P: rule Figure 4.3. Deep exhaustive execution 4.10 Overlapped Matching with Deep Exhaustive Execution Deep matching optimizes the execution of a single rule while overlapped execution exploits the similarity of consecutively executed rules. A further optimization is the combination of the two techniques: overlap the execution of exhaustive rules, and perform as much matching and rewriting as possible before restarting the overlapped rule. The outline of the algorithm is presented by Algorithm 4.7. We have attened the recursion of Algorithm 4.4, and the M atch function is realized with concrete for all loops. Lines represent the matching of the common parts, while lines and perform the matching of the remaining parts for p i and p j. Note that because of the strong OLRA enabledness of the rules, the application of the rewriting phase of a rule cannot invalidate partial matches in the commonly matched parts. Thus, the goto instruction can terminate loops belonging to exactly one rule. Figure 4.4 illustrates deep exhaustive execution with overlapped matching. Consider host graph G and rules P 1 and P 2. Both rules simply delete the matched (C) and (C ) nodes with

89 Chapter 4. Compile-time performance optimization of model transformation systems 77 Algorithm 4.7 Overlapped execution with deep matching 1: ismatch Li := true, i := 1..n 2: //repeat until no match is found for the LHSs 3: while L LSet 0 : ismatch L do 4: prevismatch L = ismatch L, L LSet 0 5: ismatch L := false, L LSet 0 6: SubMatchX deep () 7: end while 8: 9: proc SubMatchX deep () 10: for all e 1... do 11:... 12: if prevismatch Li or... prevismatch Lj... then 13:... 14: if prevismatch Li then 15: for all e i,1... do 16:... 17: REW RIT E pi (...) 18: 19: ismatch Li := true goto nextturn_i 20:... 21: label nextturn_i: 22:... 23: end for 24: end if 25:... 26: if prevismatch Lj then 27: for all e j,1... do 28:... 29: REW RIT E pj (...) 30: ismatch Lj := true 31: goto nextturn_j 32:... 33: label nextturn_j: 34:... 35: end for 36: end if 37:... 38: end if 39:... 40: end for 41:... 42: end proc

90 Chapter 4. Compile-time performance optimization of model transformation systems 78 (C) (1') (B) (1) (1'') (A) P1: rule (2) (C ) (3'') (3) (3') (B ) (A ) G: host graph P2: rule Figure 4.4. Deep exhaustive execution with overlapped matching the related edges. It is obvious that the LHSs of P 1 and P 2 can be overlapped by the (A) (B) and the (A ) (B ) subgraphs. By matching (2) for (A) and then (1) for (B), we can nd a match for P 1 by matching e.g. (1 ) for (C). After the deletion of (1 ) the matching of P 1 can continue, and without a restart it can match (1 ) for (C), and perform the rewriting again. At this point, no more match can be found for P 1 with the (1) (2) common match. Now, the engine tries to nish the matching of P 2, but no appropriate element is found for (C ) (considering (1) (2) to be xed). The matcher performs a backtrack to the point, when only (A) (and (A )) is matched, and nds (3) for (B) (and (B ) respectively). By extending (2) (3) with (3 ), a match is found for P 1, and the rule is applied again. As there is not any other node corresponding to (C) in the host graph, the engine continues with P 2, and nishes its matching with (3 ) for (C ). In the following, we prove the correctness of the algorithm: we show that it nds all the matches, and it has an output equivalent with the one produced by the non-optimized execution. Proposition Assume that P = p 1..p n strongly OLRA enabled production rules are applied m 1,p i1 on a G 1 host graph in the deep exhaustive and overlapped manner using Algorithm 4.7: G 1 = m 2,p i2 m k 1,p ik 1 G 2 =... = Gk. If the algorithm terminates at the kth iteration m i : L pi G k match for either p i P. Proof. Similarly to that of Proposition 4.18, until applying the rst REW RIT E pi instruction, the algorithm behaves identically to Algorithm 4.1 (prevismatch Li = true, L i ). After REW RIT E pi, ismatch Li is set to true, thus, prevismatch Li will be set to true at the following iteration of the while loop (Line 3) as well, and the algorithm will nd the next possible match for the same p i rule then, if it exists. The same applies to each p i, and note that the goto instructions terminate the matching of the related rule only, consequently, it is not possible that SubMatchX deep would exit before nding at least one match for each p i rule, if the match exists. Proposition Given a GT S = {p 1,..., p n } consisting of strongly OLRA enabled exhaustive m 1,p i1 m 2,p i2 rules applied sequentially on a G 1 host graph. Assume that G 1 = G2 = G3... m k 1,p ik 1 = Gk is an exhaustive execution sequence (i.e. m : L p G k, p) performed by Algorithm 4.7. Exists

91 Chapter 4. Compile-time performance optimization of model transformation systems 79 m 2,p i 2 m 1 G,p i m 1 1 = G 2 = G 3... k 1,pi k 1 = Gk execution sequence performed by the consecutive execution of Algorithm 4.1 with the dierent p i rules: EXHAUST IV E p1 (G), EXHAUST IV E p2 (G),..., EXHAUST IV E pn (G). Proof. Follows from that of Proposition We only have to prove that each m pi match found by the algorithm is valid, i.e. exists a subgraph in G j isomorphic to the match dened by m pi. It is trivial, because if REW RIT E pi modies an e k element and thus invalidates an existing partial match <e 1..e k >, then it terminates the matching of p i using e k Practical Evaluation of the Results We have implemented the overlapped matching algorithms and a case study using VMTS. In the case study, we present a simplied model of a social network, where we model people and relationships between them Benchmark description Figure 4.5. Social network metamodel and rewriting rules The metamodel of the social network is presented in Figure 4.5 a. The primary entities in the model are people, the instances of P erson that are connected with the Knows edge representing an existing relationship between two people. The IsSibling edge symbolizes that the connected people are siblings. The City in which people live is also modeled and connected with a LivesIn edge to the P erson nodes. The rewriting rules of the transformation search for potential relationships (which are not expressed by the model, but might exist with a certain probability in the real world) based on the structure of the host model. If a potential relationship between two people is found, a MightKnow edge is created between the two P erson nodes. Figure 4.5 illustrates three rewriting rules that search for potential relationships in the host model in an exhaustive way. The SN_School rule in Figure 4.5 b searches for two person nodes that have a common acquaintance, live in the same city and their School attribute is set to the same value. Furthermore, the two people do not know each other directly (according to the model), and there is not another MightKnow edge created between them with the Reason attribute School. If such a pattern is found, a MightKnow edge with the Reason attribute School is created between the two nodes. The intuitive meaning of this rule is that two people, who visit(ed) the same school, live in the same city and have a common acquaintance are likely to know each other.

92 Chapter 4. Compile-time performance optimization of model transformation systems 80 The SN_Company rule in Figure 4.5 c diers from SN_School at three points: (i) it searches for potential relationships based on the comparison of the Company attribute, and if found, (ii) it creates a MightKnow edge with Company specied as Reason, (iii) and of course, the related negative application condition (NAC) also lters on this value. The SN_Sibling rule (Figure 4.5 d) searches for two people, who have a common acquaintance which is the sibling of either P erson. This rule creates a MightKnow edge with Sibling specied as Reason. The rule expresses that people usually know the siblings of their acquaintances. Figure 4.6. Overlapping rewriting rules on two levels As shown in Figure 4.6, the submodel dened by person1, person3, city, k1, l1, l2 is a common pattern among all the rules. Furthermore, SN_School and SN_Company also share the edges k2, l2, the person3 node and the nack NAC. Thus, we can overlap the matching phase of the rules on two levels, as presented in Figure 4.5 e). Actually, all the three rules could share l2 edge and the person3 node with the nack NAC as well, however, then the matching of the k2 and is1 edges would be postponed, which is estimated a slower solution by the heuristics Measurement results The rules are executed in the exhaustive manner rst sequentially, then in the overlapped manner as well. Semantically, this means searching for all the possible relationships for all people. Furthermore, we also execute the rules iteratively and iteratively with overlapping, which nds at most one possible relationship for each user and each type of relationship (school, company, sibling). The tests are performed on pseudo-random host models with variable parameters ( P erson count, number of connecting Knows edges per P erson and the number of Schools, Companies and Cities. The acquaintances of each P erson are selected in a random way, as well as their school and company and city. 5% of the Knows edges is replaced with IsSibling. The tests were executed on an 3GHz Intel Core 2 Duo CPU-based hardware with 2GB operational memory,

93 Chapter 4. Compile-time performance optimization of model transformation systems 81 Windows 7 64-bit operating system and Microsoft.NET Framework 3.5 SP1 execution framework. Knows/Person Sequential execution (ms) T School T Company T Sibling Σ T Overlapped (ms) Gain ,9% ,2% ,5% ,4% ,3% Table 4.1. Measurement results for the exhaustive execution Table 4.1 summarizes the measurement results for the exhaustive execution, while the results for the iterative execution are listed in Table 4.2. The measured values are presented at the Knows/Person Sequential execution (ms) T School T Company T Sibling Σ T Overlapped (ms) Gain ,4% ,2% ,0% ,3% ,5% Table 4.2. Measurement results for the iterative execution greatest number of Person nodes (200 for exhaustive and 1000 for the iterative), with the smallest number of Cities (2), Schools (5) and Companies (5) as these congurations turned out to be the most computation-intensive cases. Based on the measurement results, we have achieved about 20-30% reduction of the total execution time in case of the exhaustive execution and about 8-15% in case of the iterative execution. Table 4.3 summarizes the measurement results for the deep exhaustive execution and that with overlapping. As the results show, deep matching itself improves the overall performance with about two orders of magnitude, while the combination with overlapping results in an additional 10-12% speed advance Conclusions Graph transformation has become a popular form to process models represented as graphs. This includes both conversion between dierent domains and in-place model refactorings or even the animation of a graph-based model. Although the isomorphic subgraph searching problem is NPcomplete in the size of the pattern to nd, by using heuristics, the total execution time can be noticeably decreased in practical cases. Knows T Sch Sequential (ms) Deep exhaustive (ms) Overlapped (ms) T Comp T Sib Σ T Sch T Comp T Sib Σ Gain T Ovr Gain ,1% 20 13,7% ,8% 37 13,7% ,4% 58 12,8% ,7% 85 12,8% ,0% ,2% Table 4.3. Deep exhaustive execution with overlapping

94 Chapter 4. Compile-time performance optimization of model transformation systems 82 This chapter focuses on the performance optimization of control ow-based graph transformation systems. We have proposed algorithms that share the matching phase of consecutively executed rewriting rules and reuse the partial matches of a rule during the matching phase of other rules. The basic algorithm is specialized for both iteratively and exhaustively applied rules. We have also proposed an algorithm to reuse partial matches of a rule during the application of the same rule, and we have presented its combination with the overlapping technique. The optimization techniques are applicable to any host graphs and rewriting rules without structural restrictions. We have examined the application conditions of the algorithms and proved that they do not change the result of the overall transformation. We support the verication of OLRA enabledness and the application conditions of deep matching for simple cases (structural constraints and primitive arithmetic operations on the attributes) with automated solutions. We have performed measurements with and without the optimization techniques and realized a noticeable performance gain compared to the non-optimized execution.

95 Chapter 5 Realizing the Active Model Pattern Framework with Interactive Model Transformation 5.1 Introduction Using OO patterns such as design patterns [Gamma et al., 1995], architectural patterns [Buschmann et al., 1996], refactoring operations [Fowler, 1999] has considerably simplied the design process of software systems. Patterns provide proven solutions for frequently recurring problems. They are usually described in an intuitive and informal way. For instance, many design patterns can be described as an incomplete UML model fragment that needs to be inserted into the destination class diagram. Code refactoring operations, however, are usually represented with example code fragments and textual explanations. With the proliferation of Domain-Specic Languages, the generalization of OO patterns is a natural demand. Nowadays, as Domain-Specic Modeling is gaining an increased popularity, a noticeable amount of experience and knowledge have been collected among the experts of the dierent domains. A straightforward idea is to adapt OO patterns with automated tool support to the practice of DSM as well. As DSMLs are meant to be used in arbitrary domains, thus, in accordance with [Levendovszky et al., 2009a], DSML patterns are referred to as model patterns. 5.2 Related Work In [Levendovszky and Karsai, 2009], the basics of the Active Model Pattern (AMP) concept were introduced. An AMP can be regarded as the combination of design patterns and refactoring operations in a domain-specic environment. [Levendovszky and Karsai, 2009] proposes two dierent approaches to realize design pattern support for arbitrary DSMLs: the one is based on the modication of the target metamodel, the other extends usual instance models with special ags. To the best of our knowledge, besides VMTS, only GME has published its tool support for DSM patterns to a certain extent. However, there are several tools that support some sort of interactive model transformation.

96 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 84 [Zhang et al., 2005] introduces a GME solution: the Embedded Constraint Language (ECL) is based on OCL [OMG, 2006] but has imperative features as well. Using ECL, one can describe model refactorings imperatively. The transformation framework also supports localized execution (i.e. selecting those elements of the host model that are involved in the transformation), however, this approach is rather close to direct API programming. AToM 3 [de Lara and Vangheluwe, 2002] provides a visual designer to build graph rewritingbased transformations, and facilitates the immediate visualization of the changes performed on the models. Furthermore, we can also access the UI through the API from the rules. However, AToM 3 does not support localized transformations, and one cannot inuence the pattern matching process directly. The system does not provide a built-in support for static patterns either. AGG [Taentzer, 2004] also supports the visual specication of graph rewriting-based model transformations, furthermore, it facilitates the step-by-step execution of both the individual rules and the whole transformation. One can initialize or modify a match manually, and select the rules to execute. An AGG-based solution [Biermann et al., 2006] applies graph rewriting to describe inplace model refactorings as well. As AGG has a layered, sequential control ow that does not support user interactions and conditional branchings, the engineer has much less inuence on the execution order compared to VMTS. Static model pattern support is also a missing feature of AGG. [Taentzer et al., 2007] suggest graph rewriting-based model transformation for refactoring operations. The solution generates executable code from the visual specication of the rewriting rules. However, it lacks the possibility to model the execution order of the rules, thus, it needs to be written in plain JAVA. Siikarla [Siikarla and Systa, 2008] introduces another approach, where the transformation steps are organized by an automatically generated task graph, the state of which can be persisted and reloaded. A task graph may contain automatable tasks and tasks that require human interaction as well. In this approach, we have less inuence on the control ow of the transformation. It is similar to the layered approach that describes some sort of precedence of the rules. There are several design pattern description languages. Most of them aim at their formal, and more precise description than it can be achieved with UML. A comparative discussion of formal pattern languages can be found in [Flores and Fillottrani, 2003]. The primary target of these specication languages is limited to object-oriented design patterns only. [Lauder and Kent, 1998] presents a precise diagrammatic description of design patterns. [Albin-amiot et al., 2001] contributes a metamodel for describing patterns. [Mak et al., 2004] proposes a similar approach with more precise assignment constructs and constraint specications. [Taibi, 2007] proposes a formalization language, it rather extends the informal UML models. It oers rst order logic to the static structure constraints, and temporal logic of actions (TLA). These models form a language referred to as balanced pattern specication language (BPSL). [Mapelsden et al., 2002] proposes a language called design pattern modeling language (DPML), which can be considered a DSML describing OO design patterns. [Kim, 2007] describes a UML-based language, namely, the Role-Based Metamodeling Language (RBML), which is able to specify UML design patterns. This approach treats domain patterns as templates, where the parameters are roles. A tool generates models from this language.

97 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 85 The language RSL [Flores et al., 2007] is a formal language to specify design patterns. This language is used to specify OO design patterns. In this case, the common formal language is the root metamodel equipped with an instantiation relationship. The metamodel, which can be derived across multiple levels, serves as an indirection that provides more exibility and scalability in the pattern description language. The case studies and the tool support (DePMoVe) of this approach targets OO design patterns, while our approach facilitates arbitrary domain-specic design patterns. The method proposed by [Dong et al., 2007] species design patterns in logic theorems using rst-order logic, TLA, and Prolog. The formalization method targets OO design patterns only. The work presented in [Lano, 2007] oers a ner-grained formalization of design patterns than that can be achieved with OCL. The proposed language is VDM++ with object calculus. The application of the method is not extended to arbitrary design patterns. LePUS [Eden et al., 1999][Gasparis, 2007] is a formal language with tool support to describe and verify patterns and their applications. The application area of LePUS has been OO design patterns. The tool support targets the Java programming language. [Dietrich and Elgar, 2009] also contributes a metamodeling approach. A ve-layer metamodel architecture is provided with the following layers: (i) web ontology layer, object design ontology, pattern description language, application classes, and application objects. The latter two layers correspond to the MOF M1 and M0 layers, the others facilitate a platform independent pattern description language suitable for dening an ontology for patterns. 5.3 Background and Problem Statement Recall that AMP can be regarded as the combination of design patterns and refactoring operations in a domain-specic environment. The architecture of AMP is illustrated in Figure 5.1. Static aspect Operational aspect Tracing aspect Figure 5.1. The architecture of the Active Model Pattern Infrastructure The AMP approach has three orthogonal aspects. The static aspect of AMP realizes the domain-specic, static model pattern support. Static model pattern is the common name of domain-specic design patterns, architectural patterns, and patterns in general with arbitrary intention. They can be considered incomplete model fragments that are inserted into the target model. The AMP concept also includes universal design-time model manipulations, which are referred to as the operational aspect of AMP. Often recurring operation sequences during editing or model refactorings usually cannot be expressed with an incomplete model fragment with the static aspect. The operations can be considered on-demand, localized model transformations applied interactively. They can be realized either by a model transformation environment or by programming the modeling API directly (optionally supported with a proprietary DSL). The third aspect of AMP is the tracing aspect. It covers the detailed logging of model manipulations for certain operations, such as undo/redo purposes, or the recognition of the places where static patterns were applied to be able to update the instance model on changes to the pattern denition.

98 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 86 Recall that [Levendovszky and Karsai, 2009] presented two approaches and their realization in the Generic Modeling Environment (GME) [Lédeczi et al., 2001] for the application of static model patterns. (i) The rst one is based on the extension of the metamodel of the application domain. The pattern infrastructure generates an extended metamodel which is able to store pattern operations (insert/bind/ignore) in addition to the original properties of model elements. Pattern designers must use this specialized metamodel to dene patterns. (ii) The other approach uses the original metamodel and DSL to build the patterns, and assigns tags to the model elements to mark the model as a pattern. This solution requires the modeling environment to be able to tag its modeling elements with arbitrary information, even if the structure of the tag is not dened in the metamodel. To summarize, existing AMP realization focuses on the static aspect only, and requires the extension of either the target metamodel or the instance model. The aim of the research covered by this thesis is to build an integrated framework that supports both the operational and the static aspect of Active Model Patterns with the help of model transformations. The reason to propose model transformations to realize the AMP approach is that graph rewiring-based transformations provide a precise, formal description of the requirement and the realization of a pattern at the same time. Thus, the properties and the correctness of the patterns can be more easily veried. Furthermore, as numerous metamodeling environments have built-in model transformation support, they can be easily extended to support the AMP approach as well. The goals can be summarized as follows: Examine how graph rewriting-based model transformations could describe operational patterns of arbitrary DSML domains. The solution should be generic enough to be able to describe any practical editing operation. The solution should not require the modication of either the instance or the metamodel of the target domain. Elaborate a solution to support static patterns as the specialization of operational patterns. Provide practical operational patterns that could serve as the basis for other patterns, examine the application conditions and the correctness of the solutions. 5.4 Realizing Operational Patterns with Interactive Graph Transformation In this section, we present how model transformations can be used to formalize and to realize model patterns. We use interactive graph transformation as the execution framework for AMP. By interactive we mean that the domain engineer executing the pattern application can visually trace and actively inuence the behavior of the transformation. [Habel and Plump, 2001] shows what a graph transformation engine should fulll to be Turing-complete, i.e. be universal enough to be able to express any possible operation on graphs. In Appendix B we also show how the VMTS realization of graph transformations satises these requirements. In the following, we summarize the requirements and the realization of such a transformation system.

99 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation Requirement specication We expect an interactive transformation engine to meet the following requirements to facilitate the implementation of the AMP approach. 1. The interactive selection of the model elements that should be involved in the transformation. The input of a usual transformation engine is a set of models. Therefore, we need to identify those elements of these models which may be used during the transformation. 2. The engineer should be allowed to edit the rewriting rules at runtime: both their attributes, and the structure of the rule. 3. The engineer should be allowed to modify the matches of the rewriting rules interactively. Thus, we can rene the match and exactly select which elements of the host graph is to be deleted or created. 4. If a complex model transformation (e.g. a model refactoring) is executed on the host model, it is possible that several branches of the transformation should be applied according to the intentions of the domain expert. Here we assume that the execution order of the rewriting rules in the transformation is controlled by a control structure. For this purpose, the transformation control should be prepared to mark those branches where the user may have inuence on the execution. For example in the state chart unattening example (Section 5.6.1), we may ask the engineer whether to create an explicit start node in the composite state, or rather connect to the rst child state of it directly. Depending on the selection of the engineer additional rewriting rules might be executed. 5. The transformation engine should provide a facility to ask for optional parameters from the domain engineer during the execution of the transformation: e.g. if the transformation creates new elements, several properties of the new elements (e.g. their name) should be asked instead of generating a default property value. 6. Finally, it is not enough to modify the underlying model repository, the changes should be reected by the visualization as well: obviously, deleted elements should be removed from the view, new elements should be displayed, and the changes in the attribute congurations should also be reected in the visualization Graph rewriting-based model transformation engines If we examine the way of execution, graph rewriting-based model transformation engines can usually be categorized into two groups: generated and interpreted. The input in both cases is the specication (either visual or textual) of the operations to be performed on the model. The dierence is how and when the engines process these specications. Generated transformation engines usually read and process the entire specication before the execution phase and generate a specialized model processor optimized for the transformation. In contrast, the interpreted approach does not generate a specialized executable, but evaluates the transformation specication at runtime. The main drawback of the generated solution is that the model processor needs to be regenerated every time the transformation is modied, and the regeneration may take long time. Furthermore, if the model processor is regenerated and reloaded at runtime, the state of the old

100 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 88 processor must be saved and restored in the new version. In case of an interpreted transformation engine, such information is stored in the general stores of the interpreter, which are not aected by the changes in the specication. There is a wide range of operations that force the rebuilding of a generated model processor. This includes: (i) changing the topology of the rewriting rules (as described in requirement (2)), because it modies the matching and the rewriting logic; (ii) binding several elements of the LHS model to the elements of the host graph right before performing the matching phase also modies the matching logic (requirement (2)); (iii) if we bind several elements of the RHS model to the elements of the host model, it can be considered changing both the LHS and the RHS of the rule, thus, the regeneration is necessary again (requirement. (2)); nally, (iv) if the execution of the transformation is controlled by a control ow, the runtime modications in the control sequence also result in the regeneration of the transformation (requirement (4)). Based on the requirements outlined in the previous section, we have found that the interpreted approach is more appropriate to realize an interactive model transformation compared to the generated approach Realization of the AMP approach in a model transformation environment In addition to the compiled transformation engine, VMTS also provides an interpreted solution ideal for the implementation of an interactive transformation engine. In the following, we guide through the requirements specied in Section 5.4.1, and illustrate with the help of the case studies how we have realized operational active model patterns in VMTS. 1. The interactive selection of those model elements that should be involved in the transformation. Recall that we propose localized graph transformations to describe operational patterns. It is localized, because only several (selected) elements are involved in the transformation, and not the entire model. In VMTS, the model elements selected in the view are marked with a "selected" ag. This ag can then be tested in the transformation, and the matcher can be restricted to nd the marked elements only. In our case the ag is stored in a general T ag property, which is the member of each model element and is reserved to store arbitrary runtime meta information that is not persisted. In the textual constraints of the rules we may simply test this property. But, because this is a frequently used feature, we have extended the transformation specication language with a ag for the nodes and the edges: if the ag is set on an LHS element, only the elements from the current selection are matched there. 2. The engineer should be allowed to edit the rewriting rules at runtime. Note that, because of the interpreted feature of the transformation engine, we may modify the production rules any time during the transformation (if the transformation is paused or waiting for user input), because the rule specications are processed at the same time when they are executed. 3. The engineer should be allowed to modify the matches of the rewriting rules interactively. We facilitate the modication of the matching phase on two levels: (i) bind several elements of the rewriting rule to the elements of the host graph, and let the engine nish the match, (ii) modify a successful match manually. We provide a visual solution for both cases.

101 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 89 Figure 5.2(a) illustrates a rewriting rule that matches two consecutive states connected with a transition edge (matchn ode1, matcht ransition1, and matchn ode2), and inserts a new state between the two existing nodes. (a) Visualizing and modifying a match (b) Editing attributes Figure 5.2. Match visualization and attribute editing The rule element matchnode1 is bound to the node State2 in the host graph. The binding is visualized with the "0" tag next to the elements (a unique index starting from 0 is assigned to each pattern-host graph binding), and a blue outline highlights the matched element as well if one hovers the mouse over the pattern item. An existing match can be modied, or an initial match can be dened with the help of the mouse: by clicking on the rule element while holding the Alt button, the pattern element (_matchn ode1) receives the focus which is expressed with a red outline. Those elements of the host graph which have a type compatible with that of the pattern element are highlighted with green. By clicking on one of them, the match is changed. Note that even those elements of the pattern that dene the creation of a new element ( createnode1 and the connecting edges in the gure) can be bound to existing elements of the host graph this way. Thus, the matcher and the rewriting logic is congured to use them instead of creating a new element. 4. Inuencing the execution order of the transformation rules. We have two possibilities to inuence the execution order of the rules interactively: (i) because of the interpreted feature of the engine, we can create/delete/reconnect edges in the control ow, provided that the execution is waiting for input or is paused. However, this is not a typical use case, as usually the transformation control should not be directly edited by the user. Instead, (ii) by assigning guard expressions and action scripts to the edges of the control ow, the user can be asked and the engine proceeds with the execution based on the answer. 5. Asking for optional parameters. If a transformation creates new elements in the host graph, several properties of these elements may be required to be customized by the user. E.g. the

102 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 90 default name of new elements is typically changed right after creation. In order to support this requirement, we have slightly modied the transformation denition language and the transformation engine. A new attribute called P ostconf iguration is added to the possible attributes of the rewriting rule elements. P ostconf iguration is list-typed and each item of it couples an attribute name and a default value. After performing a rewriting rule, the marked attributes are listed in a popup window where the user can set all the selected attributes at once (Figure 5.2(b)). 6. Changes in the model should be reected in the visualization. As in case of numerous other model transformation environments, the model transformation engine of VMTS modies the model objects only, but not their visualization. Therefore, we had to extend the interpreted transformation engine to (i) remove deleted edges and nodes, (ii) display newly created edges and nodes and (iii) to place the new elements in a way to follow the layout of the rewriting rule. We also made the coordinates of the model elements accessible in the textual constraints and the imperative code assigned to the rules, thus, they can be used both in the matching phase and edited in the rewriting phase. Furthermore, we apply the data binding features of the underlying UI framework (Windows Presentation Foundation - WPF) of VMTS to reect attribute changes in the visualization as well. 5.5 Realizing Static Model Patterns with Operational Patterns Recall that static model patterns can be considered incomplete model fragments that can be inserted into other models. For example, Figure 5.3 illustrates a static pattern for VAF state charts: a frequently used feature is the highlighting of a model element in a specic state of the state chart if the mouse hovers over the element. [Mészáros and Levendovszky, 2008] presents a visual model transformation debugger that highlights the match for a rule element under the mouse cursor after the successful match. Figure 5.3. Static pattern to highlight element under mouse cursor BaseState can be considered the default state without highlighting, and if a M ouseenter event is received, a Highlight event is sent to the framework, and the state machine proceeds to the M ouseover state. The corresponding guard condition is PortPeripherals.PeekIsOfType<EHUI.EventMouseEnter>(), and the action script is Fire(new EHUI.EventHighlight(this, PortPeripherals. PeekAs< EHUI.EventMouseEnter>().View, Colors.Green), PortViews).

103 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 91 The target of the Highlight event in the action script is the V iew property of the received M ouseenter event: it identies the visual object under the mouse cursor. Similarly, if a M ouseleave event is received, then the respective transition emits an U nhighlight event, and the BaseState becomes active again. Note that P ortp eripherals and P ortv iews are the conventional names of the ports to send and receive events to/from peripheral devices and the UI in VAF. In this section, we present how static patterns can be realized as the specialization of the operational aspect. We provide the formal description of the operation and prove the correctness of the solution Requirement specication In the following, we show how to calculate the derived metatypes of a node. By derived metatypes of a node we mean a node type set: a node typed with either element of the set may replace the original node, provided that the same edges can be connected to it. We expect the set to be the smallest possible, but to cover all the possible types either directly or through inheritance (i.e. the instances of an A descendant B class are covered by A). Namely, the derived metatypes are distilled from the types of the connecting edges. Denition 5.1 (derived metatypes). Having a typed graph G = (N, E, s, t, type) typed over type graph with inheritance T = (G T, I), the derived metatype of an n N node with an E E set of connecting edges is n E T (n) = {n T n T NT E (n) : n NT E (n) and n n edge in I} where NT E (n) = clan I (s(type(e))) clan I (t(type(e))). e E,s(e)=n e E,t(e)=n We expect an operational pattern consisting of a single rewriting rule the following to realize static pattern insertion on execution: Denition 5.2 (Valid static model pattern rule). Assume that a static model pattern is dened by marking one or several elements of the G = (N, E, s, t, type) host graph: L sel N N, Lsel E E. And L sel = L sel N Lsel E. We say that the VMTS rewriting rule model p = (N p, E p, s p, t p, type p ) realizes the static pattern dened by L sel if map E : L sel E E p and map N : {n n L sel N {s(e), t(e)}} N p injective functions that satisfy the following requirements: e L sel E (ϕ 1 ) n L sel N : map N(n).T argett ypes = {type(n)} map N (n).action = create. (ϕ 2 ) e L sel E : map E(e).T argett ypes = {type(e)} map E (e).action = create. (ϕ 3 ) n e L {s(e), t(e)}/l sel sel N E match. : map N(n). T argett ypes = N Lsel E T (n) map N (n).action = (ϕ 4 ) e L sel E : s(map E(e)) = map N (s(e)) and t(map E (e)) = map N (t(e)) The requirements above describe that (ϕ 1, ϕ 2 ) the rule elements related to selected elements should be marked as 'created' and their T argett ype attribute should match the type of the related items; (ϕ 3 ) rule nodes related to not selected nodes connecting to selected edges should be marked as 'matched' and their target types should be the derived metatypes of the related node; (ϕ 4 ) expresses that the mapping is endpoint-preserving.

104 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 92 E A G F B H g:g c:c e:e C D h:h f:f a) Metamodel b) Instance model Figure 5.4. Static pattern requiring multi-typed matching Semantic verication of the requirements, multi-typed graphs The production rules used in VMTS allow multiple types to be matched for the same rule element as well as matching elements with a descendant type of the rule element. Consider the metamodel and instance model illustrated in Figure 5.4. If we dene a static pattern as illustrated in Figure 5.4 b) without the c node, then it is clear that we may match nodes with type either C or D in place of the c node. The e and f edges can be connected to nodes with either of those types. Thus, the Graph TG category is not able to describe the application of such a rule. This is why we introduce the multi-typed graphs (Graph MTG ) category that can handle both inheritance and multiple types for the same element. Using the multi-typed graphs formalism, we can interpret the T argett ypes attribute of the rewriting rule elements as if they were all the types of the corresponding element, and describe the execution of the rule as a double pushout. Denition 5.3 (derived set function). Let ϕ : A B be a function. π ϕ : P(A) P(B) denotes the set function which is interpreted as: π ϕ (X) = {ϕ(x) x X}, X P(A) Denition 5.4 (multi-clan morphism). Given a type graph T = (G T, I), and a graph H, a multi-clan morphism type : H T consists of two functions type N : N H P(N GT ), type E : E H P(E GT ) such that (i) e E H : type N s H (e) π clani (π sgt type E (e)), and (ii) e E H : type N t H (e) π clani (π tgt type E (e)). Denition 5.5 (Multi-instance graph of a type graph with inheritance). Given a type graph (with inheritance) T, a double G T = (G, type) of a graph G along with a multi-clan morphism type : G P(T ) is called multi-instance of T. G is also said to be multi-typed over T. Denition 5.6 (multi-typed graph morphism). Given a type graph T, and multi-typed graphs G T 1 = (G 1, type 1 ) and G T 2 = (G 2, type 2 ), a multi-typed graph morphism f : G T 1 G T 2 is a graph morphism f : G 1 G 2 such that l N 1 E 1 : type 2 f(l) π clani type 1 (l). Theorem 5.7 (category Graph MTG ). Given a type graph T, the category Graph MTG of multityped graphs consists of multi-instance graphs of T as objects and multi-typed graph morphisms as morphisms. Lemma 5.8 (relation of clans). Given a type graph T, and two nodes n, n N T such that n clan I (n). In this case, clan I (n ) clan I (n). Proof of Lemma 5.8. Let n N T be a node such that n clan I (n ). By denition, path p 1 from n to n through edges in I. n clan I (n) path p 2 from n to n through edges in I. Therefore, path p 1 + p 2 is a path from n to n. Since there is a path from n to n, it

105 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 93 means that n clan I (n) by denition. Since n N T clan I (n ) clan I (n). : n clan I (n ) n clan I (n), Lemma 5.9 (relation of clan sets). Given a type graph T, and node sets N, N N T such that N π clani (N). In this case, π clani (N ) π clani (N). Proof of Lemma 5.9. Follows from that of Lemma 5.8: for each n N : n π clani (N) n N : n clan I (n). Thus, for each n N : n N so that clan I (n ) clan I (n). Consequently n N : clan I (n ) π clani (N). Lemma 5.10 (composition of multi-typed morphisms). Given a type graph with inheritance T, three instance graphs A, B, C. The composition of multi-typed morphisms f : A B and g : B C is a graph morphism g f : A C. g f is also multi-typed. Proof of Lemma Let the type morphisms of A, B, and C be type A = (type N A, typee A ), type B = (type N B, typee B ), and type C = (type N C, typee C ) respectively. g f is a graph morphism, because it is composed by traditional graph morphisms by the composition operator, we need to prove that it satises the conditions of a multi-typed morphism, i.e. n N A : type N C (g f(n)) π clani (type N A (n)) and (5.1) e E A : type E C(g f(e)) type E A(e)) (5.2) n N A : type N B (f(n)) π clani (type N A (n)) (5.3) type N C (g(f(n)) π clani (type N B (f(n)) (5.4) By Lemma 5.9, πclani (type N B (f(n)) π clani (type N A (n)), thus (5.5) type N C (g(f(n))) π clani (type n A(n). (5.6) e E A : type E B(f(e)) type E A(e) (5.7) therefore type E C(g(f(e))) type E B(f(e)) (5.8) typed E C(g(f(e))) type E A(e) (5.9) Proof of Theorem 5.7. The composition of two multi-typed morphisms f : A B and g : B C is also a multi-typed morphism g f : A C based on Lemma The associativity law h (f g) = (h f) g for multi-typed morphisms is true, since it is true for ordinary graph morphisms. Similarly, the identity morphism i A for each object A is the ordinary identity graph morphism of A. id A is also a multi-typed morphism. For any ordinary typed graph morphism

106 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 94 L (1) G Selected K (2) R H D H Figure 5.5. Execution of the rewriting rule inserting a static pattern f : A B, the identity morphisms on A and B satisfy the identity axiom: id B f = f f id A = f. Having the Graph MTG category, we can prove that a rewriting rule fullling the requirements of a static pattern insertion rule really inserts a model fragment isomorphic to the pattern. Proposition Having a p rewriting rule realizing a static model pattern dened by Selected in the G host graph (Denition 5.2) typed over T. Assume that we complete Selected to a valid subgraph Selected, i.e. for each n (N G /Selected) e E G Selected : s(e) = n t(e) = n we add a new n node typed with all the nodes of the T type graph and s(e) (or t(e)) to n'. The execution of the p rule on the H host graph produces a model fragment that is topologically isomorphic to the extended pattern Selected model pattern, provided that we allow injective matches only. Furthermore, the type of the newly created elements equals that of the corresponding elements in Selected. Remark The extension of Selected is necessary because isomorphism is dened on valid (sub)graphs only. Proof. The execution of the p = (L K R) rule is illustrated in Figure 5.5 ((1) and (2) are pushouts). According to Denition 5.2 injective morphism Selected R exists (note that the type of the extension nodes of Selected is the superset of that of the corresponding elements in R). Thus Selected H injective morphism exists as well. (The existence of the morphism implies topological isomorphism and matching types for newly created elements.) Generating the static pattern insertion rule In the following, we present a transformation: by applying this transformation on the source model, we can dene a mapping map that fullls the requirements outlined in Denition 5.2. The static pattern generator transformation (SPG) consists of three rules (illustrated in Figure 5.6) that are executed exhaustively. The rselectedn ode rule matches all the selected nodes (selectedn ode) once and creates the corresponding rule node (rulecreatedn ode) in the target model. The rule nodes are congured to perform the insertion (Action = create ) of a node with the appropriate type. Similarly, rn otselectedn ode matches all of those not selected nodes in the host model (notselectedn ode) that have a connecting selected edge. The rule creates a node in the target model with the derived metatype as target type, and congures the node to be matched during the execution (Action = match ). Similarly, rselectededge matches all the

107 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 95 (a) rselectedn ode rule (b) rn otselectedn ode rule (c) rselectededge rule Figure 5.6. Rewriting rules to generate a static pattern insertion rule selected edges once (selectededge), and creates the related rule edge (rulecreatededge) in the target model. As rselectedn ode and rn otselectedn ode store the mapping between the elements of the source model and the elements of the target rewriting rule by creating a temporary reference between the corresponding nodes in the two dierent models. rselectededge can identify the related endpoints to be connected in the target model. The metatype of the created edge matches that of the selected edge in the host model. In the following, we verify each requirement dened in Denition 5.2 if and how the transformation satises them. Proposition Having a typed graph G = (N, E, s, t, type) typed over T, applying the SPG transformation on the host graph G the resulting H graph satises requirement ϕ 1 of Denition 5.2. Proof. With the single execution of the rule CreatedNode, we match an n L sel N node for nodecreated and create a corresponding n rule element, for that n.t argett ypes = {type(n)} n.action = create. The rule also creates a reference between n and n, which reference appears as a NAC on the left side of the rule. Thus, the same n node cannot be matched twice for nodecreated, i.e. it cannot be modied during a repeated execution. The exhaustive execution of the rule terminates based on [Levendovszky et al., 2007]: with the repetitive joining of the LHS graph and the RHS graph of the resulting rule based on the Concurrency Theorem, the number of elements of the resulting LHS graph will be strictly monotonic increasing. Consequently, the exhaustive execution processes each n L sel N n.t argett ypes = type(n) n.action = create. node, and creates a corresponding n node with Proposition Having a typed graph G = (N, E, s, t, type) typed over T, applying the SPG transformation on the host graph G the resulting H graph satises requirement ϕ 3. Proof. The proof follows that of Proposition 5.13: rules M atchedn ode and M atchedn ode2 match non-marked nodes with marked incoming or outgoing edges and create a corresponding rule node (nodematchedrule) for each such node. The rules also set the T argett ype attribute to N Lsel E T (n), and the Action attribute to match.

108 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 96 Proposition Having a typed graph G = (N, E, s, t, type) typed over T, applying the SPG transformation on the host graph G the resulting H graph satises requirements ϕ 2 and ϕ 4. Proof. Rule CreatedEdge matches each e L sel E edge and creates a corresponding rule edge with the requested T argett ype and Action attributes. Similarly to rules CreatedN ode, M atchedn ode and M atchedn ode2, CreatedEdge is executed exhaustively and the already processed edges are excluded from the following match because of the reference created between the matched and the created rule edge. As ϕ 1 and ϕ 3 are satised by the other rewriting rules, matches for the pnodef rom (=map N (nodef rom)) and pnodet o (=map N (nodet o)) rule elements in the output model should exist for each match for nodef rom and nodet o. creatededgerule corresponds to map E (creatededge), thus map N and map E functions are edge preserving (ϕ 4 ). 5.6 Realization and Analysis of Practical Operational Patterns In this section, we present three operational patterns often used during editing models. We describe the requirements against each pattern in both a formal and an informal way. We present possible realizations and prove the correctness of them. The rst one is based on the state machine language of the VMTS Animation Framework presented in Chapter 3. It performs the unattening of the selected segment of the model. The other two is related to editing graph rewriting rules Unattening a state chart animation model The aim of the unattening pattern is to reduce the size of the state chart model by introducing composite states. The outgoing transitions of a composite state behave as f allback transitions that are performed if a contained state is active, and neither of its outgoing transitions can be performed. The pattern is illustrated in Figure 5.7. It wraps the selected states with a composite state, and optionally creates a start state inside the new composite state, if exactly one selected element has incoming edges from outside the selection. For each guard, action, target state triplet that is used for one transition for each selected state, a new transition is created with the same properties starting from the new composite state. Furthermore, the transitions with the same properties leaving the selection are removed. Figure 5.7. State chart unattening example Requirement specication First we dene an extended class of labeled graphs that is used to describe state chart models:

109 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 97 Denition 5.16 (state chart graph). A state chart graph is a G = (N, E, s, t, type, g, a) labeled graph where N and E denote the node and edge sets of the state chart, s, t : E N denote the source and target functions. The type : (N E) {state, start, trans, cont} function denes the type of the graph elements: nodes can be states or start states while an edge may be either a transition or a containment edge. The g, a : E string labels describe the related guard and action expressions for each transition-typed edge, for containment-typed edges the value of these labels is undened. Denition 5.17 (application conditions of the state chart unattening pattern). To unatten an A 1 = (N 1, E 1, s 1, t 1, type 1, g 1 ) state chart model along an L sel N 1 state subset it is required that: (γ 1 ) the selected states have a common container: c N 1 : v L sel N 1 : e E 1, type 1 (e) = cont s 1 (e) = c t 1 (e) = v. In the following, we enumerate those essential properties that are required to say that the pattern realizes unattening without changing the semantics of the state chart model. Denition 5.18 (correctness requirements of the state chart unattening pattern). Assume two state chart graphs A 1 = (N 1, E 1, s 1, t 1, type 1, g 1 ) and A 2 = (N 2, E 2, s 2, t 2, type 2, g 2 ) according to Denition Let A 1 denote the source graph describing the input state machine and L sel N 1 means the set of selected states in A 1. A 2 is the unattened version of A 1 along L sel N 1 if we hierarchize the nodes dened by L sel N 1. (ϕ 1 ) The pattern should preserve states, i.e. map n : N 1 N 2 injective mapping. Based on map n we dene the image of the selected states in N 2 as L sel N 2 = {vs vs = map n (v ), v L sel N 1 } (ϕ 2 ) The pattern should preserve those transitions that connect either two selected or two not selected states. Namely, e 1 E 1 : type 1 (e 1 ) = trans (s(e 1 ) L sel N 1 t(e 1 ) L sel N 1 ) = e 2 E 2 : s 2 (e 2 ) = map n (s 1 (e 1 )) t 2 (e 2 ) = map n (t 1 (e 1 )) type 2 (e 2 ) = trans g 1 (e 1 ) = g 2 (e 2 ) a 1 (e 1 ) = a 2 (e 2 ). ( represents the exclusive or operation) (ϕ 3 ) A new composite animation state should be created that contains all the selected states and has the common container of the selected states as its container: n c N 2 /R mapn : (i) n L sel N 2 : e c E 2, type 2 (e c ) = cont, s 2 (e c ) = nc, t 2 (e c ) = n and e c e c E 2 : type 2 (e c) = cont t 2 (e c) = n and (ii) ( e c E 1, type 1 (e c ) = cont t 1 (e c ) L sel N 1 ) = ( e c E 2, type 2 (e c) = cont s 2 (e c) = map n (s 1 (e c )) t 2 (e c) = n c ). The later condition expresses that the previous container node of the selected nodes will be the container of the newly inserted container. (ϕ 4 ) If there is a guard and action script pair that is used for an outgoing transition with the same target state for each selected state, then these transitions should be removed and a new one should be created with the same guard, action expressions and target state and the new composite state should be its source state: Let T common = {e e E 1 type 1 (e) = trans : ( v L sel N 1 : e E 1 s 1 (e ) = v type 1 (e ) = trans t 1 (e ) = t 1 (e) g 1 (e) = g 1 (e ) a 1 (e) = a 1 (e ))}

110 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 98 (i) e T Common : e 2 E 2 : type 2 (e 2 ) = trans t 2 (e 2 ) = map n (t 1 (e)) g 1 (e) = g 2 (e 2 ) a 1 (e) = a 2 (e 2 ) s 2 (e 2 ) L sel N 2 and (ii) e 2, c E 2 : type 2 (e 2 ) = trans type 2 (c) = cont t 2 (e 2 ) = map n (t 1 (e)) a 2 (e 2 ) = a 1 (e) g 2 (e 2 ) = g 1 (e) t 2 (c) = map n (s 1 (e)) s 2 (e 2 ) = s 2 (e) and e 2 is unique i.e. there is not any other e 2 e 2 with the same properties. (ϕ 5 ) All the remaining transitions connecting a selected and a not selected state should be preserved: e E 1 /T common : (s 1 (e) L sel N 1 t 1 (e) L sel N 1 ) type 1 (e) = trans = e E 2 : s 2 (e ) = map n (s 1 (e)) t 2 (e ) = map n (t 1 (e)) type 2 (e ) = trans a 1 (e) = a 2 (e ) g 1 (e) = g 2 (e ) (ϕ 6 ) All the remaining containment edges should be preserved: c E 1, type 1 (c) = cont t 1 (c) / L sel N 1 = c E 2 : type 2 (c ) = cont s 2 (c ) = map n (s 1 (c)) t 2 (c ) = map n (t 1 (c)) (ϕ 7 ) A 2 does not contain any other states or edges than the ones referenced in points ϕ 1..ϕ 6 : N 2 = N (+1 represents the new composite state) E 2 = E 1 + T common (1/ L sel N 1 1) + 1 T common (1/ L sel N 1 1) represents the removed transitions with common action and guard expressions and the added transitions for the new container state. +1 denotes the additional containment edge for the new container. Note that the constraints on the number of the nodes and edges together with the previous requirements imply the non-existence of any other nodes or edges in the unattened model. The following requirement is considered to be optional, it is not denitely required, however, it can further optimize the state chart model: (ϕ 8 ) If there is exactly one state that has incoming transitions from not selected states among the selected states, then the target site of the incoming transitions can be set to the new composite state. A new start node should be created within the composite state and a single transition pointing from the new start state to the original target of the redirected transition. Namely, if we denote the only state with incoming edges from outside the selection as q 0 (q 0 L sel N 1, e E 1 : type 1 (e) = trans s 1 (e) / L sel N 1 t 1 (e) = q 0 and e E 1 : type 1 (e ) = trans s 1 (e ) / L sel N 1 t 1 (e ) L sel N 1 /{q 0 }) and the new composite state as n c (n c N 2 : c E 2 type 2 (c) = cont s 2 (c) = n c t 2 (c) L sel N 2 ) then q 0 = (1) ( e 1 E 2 : type 2 (e 1 ) = trans s 2 (e 1 ) / L sel N 2 t 2 (e 1 ) L sel N 2 ), and (2) e 1 E 1, s 1 (e 1 ) / L sel N 1, t 1 (e 1 ) = q 0 type 1 (e 1 ) = trans: e 2 E 2 : type 2 (e 2 ) = trans s 2 (e 2 ) = map n (e 1 ) t 2 (e 2 ) = n c a 1 (e 1 ) = a 2 (e 2 ) g 1 (e 1 ) = g 2 (e 2 ), and (3) v N 2, c 2, e 2 E 2 : type 2 (v) = start type 2 (e 2 ) = trans type 2 (c 2 ) = cont s 2 (c 2 ) = n c t 2 (c 2 ) = v s 2 (e 2 ) = v t 2 (e 2 ) = q 0 a 2 (e 2 ) = ø g 2 (e 2 ) =ø. If an internal start state node is also created, then requirements ϕ 5 and ϕ 7 should be updated. ϕ 5 should be limited to the transitions leaving the selection except for T common :

111 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 99 e E 1 /T Common /{e t 1 (e ) L sel N 1 }. In case of requirement ϕ 7 we have to consider an additional node (the internal start state) with a container edge and the transition connecting the start state to the selected elements Realization In the following, we present how we have realized the state chart unattening operational pattern, using the interactive model transformation system. Figure 5.8 illustrates the control ow graph of the transformation. Figure 5.8. Control ow graph of the state chart unattening transformation The transformation works as follows: the CountStart rule (Figure 5.9(a)) matches all the states in the selection (innern ode) that have an incoming transition from a node outside the current selection, and puts those state nodes into a list. This is necessary, because if the list contains only one element (i.e. one selected node has one incoming edge), we may oer to create a start node inside the composite node, and redirect the incoming edges to the composite node (as shown in Figure 5.7). The SelectOne rule (Figure 5.9(c)) selects an arbitrary node (containedn ode, called reference node from now on) within the selection, and places it into a newly created container (newcontainer). Both the containedn ode and the newcontainerstate nodes are agged in order to be identied later. In addition, the container state is positioned and sized to cover the rectangle of the selection, and containedn ode keeps its original absolute position inside it. The SelectOne rule is left by two ow edges: the guard condition of the one (askstart) leading to CreateStart (Figure 5.9(d)) asks the user whether to create an explicit start state within the new composite state. This question is asked only if CountStart found only one selected node with an incoming edge from outside the selection. If there is more than one such node or the user answers 'No', the execution proceeds to SelectN extt ransition (Figure 5.9(b)). Otherwise, CreateStart creates a new start state within the composite state and creates a transition within the start node and the state marked by CountStart. CreateStart is followed by the ReconnectStart (Figure 5.9(e)) rule that sets the target node of each transition entering the selection to the new container state. The SelectN extt ransition, CheckT ransitionsw ithsameguard (Figure 5.9(f)) and CreateF allbackedge rules iterate through the edges of the reference node, and if the guard and action expression of either outgoing transition is used for one outgoing transition for each

112 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 100 (a) CountStart rule (b) SelectN extt ransition rule (c) SelectOne rule (d) CreateStart rule (e) ReconnectStart rule (f) CheckT ransitionsw ithsameguard rule (g) CreateF allbackedge rule (h) SinkStates rule (i) RemoveRedundantT ransitions rule Figure 5.9. Rewriting rules to unatten a state chart diagram other selected state, then that transition is pushed one level up to the composite state. This means that a transition can be pushed up without changing the semantics of the state chart, if all the selected states have an outgoing transition with the same guard expression. The SelectN extt ransition (Figure 5.9(b)) selects and marks one non-marked outgoing transition of the reference node, then CheckT ransitionsw ithsameguard tries to match another selected state without an outgoing transition with the same guard and action expression (phrased in the textual constraints of the rule). If it fails, the transition can be pushed up ( CreateF allbackedge in Figure 5.9(g)). Otherwise, (and also after CreateF allbackedge) a new transition is searched for by SelectN extt ransition. If there is not any non-marked outgoing transitions for the reference node, then the remaining selected states are moved into the composite state (SinkStates - Figure 5.9(h)). Finally, the rule RemoveRedundantT ransitions (Figure 5.9(i)) removes those outgoing transitions of the selected nodes that have a corresponding outgoing transition on the composite node with the same guard and action expression and target state. Proposition The statechart unattening transformation satises the requirements ϕ 1..ϕ 8 provided that γ 1 applies to the L sel N 1 Proof. Appendix A selection.

113 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation Exhaustive set for control ow-based model transformation systems In control ow based model transformation systems, if there is no built-in support for the exhaustive execution of a set of rewriting rules (i.e. execute all the rules until neither of them can be applied), a possible realization of this feature is to cascade the rewriting rules and add additional feedback edges to them. An example of this can be seen in Figure 5.10 Figure Exhaustive set example After the exhaustive execution of the R1 rule, R2 is applied exhaustively. If it has been applied ot least once, R1 is applied again, as R2 may have produced new matches for R1. Otherwise, R3 is executed exhaustively. The same check is performed for R3 and R4 as well. The rule sequence is nished as soon as neither of the rules can be applied. Note that in the presented example the processed rules of the original control ow were not connected with edges. However, it is possible that some of the rules have precedence over the others because of semantic or performance issues, and these precedences should be kept by the pattern. Figure Exhaustive set with precedences This is illustrated in Figure 5.11: R3 should be applied right before R2 and R1 should be applied right before R4 (the precedence between the R3-R2 and R1-R4 rule sets is undened) Requirement specication Denition 5.20 (control ow graph). A control ow graph is a G = (N, E, s, t, type 1, g) labeled graph where N and E denote the node and edge sets of the graphs, s, t : E N denote the source and target functions. The type : (E) {succ, fail, both} function denes the type of the control ow edges: succ means that the edge is followed, if the preceding rule was successfuly applied at least once, the edge with fail is followed otherwise. both means that the edge can be followed in both cases. The g : E string labels describe the related guard expressions for each ow edge: before following the edge, the guard expression is evaluated.

114 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 102 Denition 5.21 (application conditions of the exhaustive set pattern). Assume a control ow graph A 1 = (N 1, E 1, s 1, t 1, type 1, g 1 ) and a set L sel N 1 N1 of selected nodes. To be able to apply the exhaustive set patter we expect L sel N 1 to satisfy the following conditions: (γ 1 ) there is no directed circle of ow edges in the selection : e 1...e n E 1 : s 1 (e i ) = t 1 (e i 1 ) L sel N 1, i {2..n} s 1 (e 1 ) = t 1 (e n ) (γ 2 ) there cannot be brances in the ow edges of the selected rules: e 1 e 2 E 1 : s 1 (e 1 ) = s 1 (e 2 ) L sel N 1 Denition 5.22 (correctness requirements of the exhaustive set pattern). Assume two control ow graphs: A 1 = (N 1, E 1, s 1, t 1, type 1, g 1 ) and A 2 = (N 2, E 2, s 2, t 2, type 2, g 2 ) respectively. Let A 1 denote the source graph describing the input control ow and L sel N 1 N 1 the set of selected nodes in A 1. A 2 is the resulting control ow in that the rules referenced by L sel N 1 are applied exhaustively. We expect the exhaustive set pattern: (ϕ 1 ) The pattern should preserve nodes, i.e. map n : N 1 N 2 injective mapping. Based on map n we dene the image of the selected nodes in N 2 as L sel N 2 = {v s v s = map n (v ), v L sel N 1 } (ϕ 2 ) The pattern should preserve ow edges: 1) e E 1 : e E 2 : map n (s 1 (e)) = s 2 (e ) map n (t 1 (e)) = t 2 (e ) 2) s 1 (e) / L sel N 1 t 1 (e) / L sel N 1 = type 1 (e) = type 2 (e ) g 1 (e) = g 2 (e ). Namely, the type and expression of edges connecting a not selected state to any other are not changed. (ϕ 3 ) π permutation of the n 1..n k nodes in L sel N 1 ( L sel N 1 = k), so that 1) e 1 E 2 : type 2 (e 1 ) = both s 2 (e 1 ) = n π(1) t 2 (e 1 ) = n π(2) g 2 (e 1 ) =ø 2) e i E 2 : type 2 (e i ) = fail s 2 (e i ) = n π(i) t 2 (e i ) = n π(i+1) g 2 (e i ) =ø, i {2..k} 3) e i E 2 : type 2 (e i) = succ s 2 (e i) = n π(i) t 2 (e i) = n π(1) g 2 (e i) =ø, i {2..k} (ϕ 4 ) The pattern should not create additional nodes or edges compared to the ones treated in ϕ 1...ϕ 3. Namely, N 2 = N 1 and E 2 = {e e E 1 : s 1 (e) / L sel N 1 t 1 (e) / L sel N 1 } + ( L sel N 1 1) Realization Figure 5.12 illustrates the control ow graph of the transformation realizing the exhaustive set operational pattern. Rules T estbranch1 and T estbranch2 (Figure 5.13(a), 5.13(b)) check the validity of precondition γ2: if either rule nds a match, then the transformation terminates. The rules F indf irst and ExtendLast (Figure 5.13(c), 5.13(d)) match a non-extensible directed path in the selection: F indf irst matches two selected nodes as well as a connecting edge and marks them. The start node of the edge cannot have incoming edges from within the selection (expressed in the textual constraints of F indf irst). ExtendLast extends the edge previously found by F indf irst with another one. The rule marks the target node of edge and removes the mark from the previous one, thus, at the repeated execution it will extend the edge found by itself in the previous round.

115 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 103 Figure The control ow model of the exhaustive set pattern Because of the exhaustive execution of the rule, when it terminates, we can identify the start and end nodes of a rule sequence. (Note that branches in the selection are denied.) Rule F indnext (Figure 5.13(e)) searches for a node (nextf irst) that starts another rule sequence (does not have incoming edges from within the selection), and connects it to the end of the previous sequence. Then ExtendLast is applied again, to traverse the connected sequence as well. If F indn ext cannot be applied, then we have connected all the (not cyclic) directed paths of the selection. If CheckRemaining (Figure 5.13(f)) can match an edge between two not yet marked but selected nodes, then there is a directed cycle between several of the selected elements and the transformation terminates. At this point, there may exists still several selected nodes not connected to any other selected node. They are matched by CheckRemaining, and connected to the end of the previously generated rule sequence. M atchf irst (Figure 5.13(i)) matches the rst edge of the resulting rule sequence, and creates the feedback edge from the second one to the rst one. It also updates the properties of the ow edges to execute the second rule unconditionally after the rst one, but jump back to the rst only if the second rule was successfully applied. The F eedback rule (Figure 5.13(j)) performs a similar operation: It matches the remaining rules of the rule sequence in an exhaustive way, and creates the feedback edges to the rst node. Note that the rule congures the ow edges leading from rule n i to n i+1 to be followed only if n i cannot be applied. Proposition The exhaustive set transformation satises requirements ϕ 1..ϕ 4 provided that the γ 1, γ 2 application conditions apply to the L sel N 1 Proof. Appendix A Rewriting rule concatenation selection. When editing graph transformation rules, an often used operation is concatenating two consecutive rewriting rules along a common subgraph of the LHS and the RHS of the two rules. An example for this is shown in Figure In the example Node5 is mapped to Node2, Node4 to Node3 and e2 edge to e1. Thus, the concatenated rule is generated by connecting a copy of the e3 edge and the Node6 node to the Node2 node of the rst rule.

116 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 104 (a) rule T estbranch1 (b) T estbranch2 rule (c) F indf irst rule (d) ExtendLast rule (e) F indnext rule (f) CheckRemaining rule (g) SelectF irstn odes rule (h) ConnectRemaining rule (i) MatchF irst rule (j) F eedback rule Figure Rewriting rules realizing the exhaustive set pattern Figure Requirement specication Although VMTS has a graph transformation engine and language for attributed graphs, in this pattern we deal with topologic issues only. Merging attribute conditions and operations attached to the rules would require additional research. Correctness requirements: The requirements against the rule concatenation pattern are summarized in Figure The E interface graph denes the model fragment along which the two rules are concatenated. (1) and (3) are pushouts and p 1, p 2, P V is also the pushout of e 1 n 1 and e 2 n 2. Intuitively, this means that P V is generated by gluing P1 V and P2 V together along subgraphs isomorphic to the E interface graph, provided that we select the isomorphic subgraph in P1 V from the notdeleted elements and in P2 V from the not created ones (this condition is ensured by the modeling environment) Realization The control ow model of the transformation realizing rule concatenation is depicted in Figure 5.16(a). The action MappingInput does not apply a rewriting rule, but it asks the user to input a partial mapping between the elements of the two rewriting rules (as shown in Fig-

117 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation 105 L 1 K 1 l 1 r 1 m 1 (1) R 1 n 1 P V 1 p 1 E e 1 e 2 (2) L 2 K 2 l 2 r 2 m 2 P V p P2 V 2 Figure Rule concatenation process (3) R 2 n 2 ure 5.16(b)). The mapping is stored in an associative store that is available for all the rewriting rules of the transformation. (a) The control ow model of the rule concatenation pattern (b) Visual denition of the interface graph (c) AddNewNode rule (d) AddNewEdge rule Figure Rule AddNewNode (Figure 5.16(c)) matches each node (Node1) of the second model except for the ones in the mapping, and creates a new node (Node2) in the rst model with the same target type and action (match, create or delete). A reference from Node1 to Node2 is also created so that we can identify the origin of the new nodes later in the transformation. Namely, AddNewNode copies the nodes of the second model except for the ones used in the mapping to the rst model. The AddNewEdge (Figure 5.16(d)) rule is used to copy the edges as well. It matches each e1 edge of the second model that edge is not used in the mapping. For the endpoints (Node0, Node1) of each of these edges, we can nd the corresponding endpoints (Node2, Node3) in the rst model as either there is a reference between them (created by AddNewNode) or the pairing is stored in the mapping. The rule then creates the edge e2 in the rst model with the same target type as e1 and the same action. Proposition Having P1 V, P 2 V rewriting rules and E interface graph with e 1 n 1 : E P1 V, e 2 m 2 : E P2 V morphisms, the rule concatenation transformation generates the pushout of of E, e 1 n 1, e 2 m 2 : E P2 V. Proof. Appendix A

118 Chapter 5. Realizing the Active Model Pattern Framework with Interactive Model Transformation Conclusions In this thesis, we have provided a complete framework to dene and apply various model patterns with arbitrary intention in a domain-specic environment. We have presented the requirements and the realization of an interactive graph rewriting-based model transformation framework. We facilitate to interactively inuence the execution both on high (control ow) and on low (rewriting rule) level at runtime. We have provided the formal description of the execution logic of the transformation engine and analyzed the correctness of the logic and the expression power of the solution. The introduced transformation system serves as the execution engine for the operational aspect of AMPs that describe frequently used complex model manipulations and refactoring operations in Domain-Specic Modeling. With the specialization of the operational aspect, we can easily realize the static aspect of AMPs as well. Here we have formulated the formal specication of the requirements against the static approach. We have presented a transformation, realized it and proved its correctness. The introduced approach is motivated and illustrated with case studies from the VMTS Animation Framework and other domains.

119 Chapter 6 Practical Application of the Scientic Results The theoretical results of our research (i) visual model animation, (ii) optimized model transformation execution and (iii) model pattern support have been realized in the Visual Modeling and Transformation System and applied in industrial and research projects. In this chapter, we introduce VMTS and present the main applications of the theoretical results of the theses. 6.1 The Visual Modeling and Transformation System VMTS is an n-level metamodeling and model transformation environment. "N-level" means that any model can be used as a metamodel, thus, the instantiation chain is theoretically innite. In the last three years, with the VMTS team, we have completely redesigned and implemented VMTS from the ground. The vision was to build a modeling environment with extreme customizability and extensibility supporting the (partial) integration into standalone business applications. The architecture of VMTS is illustrated in Figure 6.1. The bottom-most level is the Data Repository that represents the dierent data persisting stores that can be connected to the system. Above the repositories, the VMTS Exchange Framework (VXF) and VMTS Modeling Framework (VMF) can be found. The role of VXF is to wrap each type of repository with a uniform interface, thus, we can use e.g. le-based or database-based repositories at the same time or even switch between them at runtime. The in-memory objects representing a model are part of the VMF. The class denitions together with the corresponding VXF wrappers (exim EXportIM port) for each domain are generated based on the metamodel. Note that the class denitions corresponding to the domains can be specialized for dierent purposes, e.g. to support change notication for the UI or rather be as thin and fast as possible for computational purposes. Such a specialization is called Object Space (OS). As we use object hierarchies customized both for the domain and for the purpose of use, the resulting applications can be very ecient, and as we generate both the OSs and the corresponding exims, this does not mean additional work for the domain engineer.

120 Chapter 6. Practical Application of the Scientific Results User Interface Figure 6.1. The architecture of VMTS One of the most important user requests was to support multiple views of models and to provide extensibility so that dierent models can be visualized in a customizable way. Dierent views are required to be able to focus simultaneously on dierent aspects of models, while customization is needed to support domain-specic languages. The Document-View architecture is an appropriate choice to satisfy this requirement. For each model element, VMTS associates exactly one Document and an arbitrary number of V iews. To facilitate the customization of the appearance, we have designed a exible plugin system. Each plugin is attached to a metamodel with the help of the unique identier of the metamodel. However, metamodels can have more than one plugins attached, the user can select the plugin to use, or even switch from one plugin to another at runtime. The framework used to visualize models is Windows Presentation Foundation. The visual appearance of model elements can be dened in two ways: (i) creating a V iew descendant class implementation, where we can describe the appearance and the behavior as well or (ii) using XAML [Nathan, 2006] code. The XAML textual language is capable of describing customized appearance based on simple graphical constructs (e.g. rectangle, lines) and hierarchical control structures (e.g. tree control). Furthermore, it is also appropriate to create responsive user interfaces with the help of storyboard-based animations. XAML documents can be processed at runtime and do not need to be compiled into binary format. The visualization of model properties relies on the data binding [Nathan, 2006] capabilities of WPF. With the help of data binding we can bind the properties of the visualization objects to the properties of the underlying data objects. Thus, any changes occurring in the data will be immediately reected in the visualization. Data binding can also be described using XAML in a declarative way. Data binding requires class properties to be dened as dependency

121 Chapter 6. Practical Application of the Scientific Results 109 (1) CreateAnts CreateMap UpdatePheromon MapProcessed (3) (2) OnFood FinishLevel MoveBack NewAnt MoveFromCenter Move6 fail CreateCorner CreateExtension CreateAxis succ Move4 fail succ AntProcessed BorderCheck (a) Ant World illustration (b) The controlow of the submitted solution Figure 6.2. Ant World simulation properties [Nathan, 2006], however, dependency properties can also be wrapped with the same general interfaces used for the current domain, and only a specialized OS generator is required to perform this step Model Transformation We have redesigned and reimplemented the model transformation framework of VMTS to support compiled, and consequently much faster execution. As a result, we have achieved about three orders of magnitude performance improvement with decreasing memory assumption at the same time. Instead of the interpreted behavior like the previous realization [Lengyel et al., 2006], we prefer compiled execution: based on the transformation models introduced in Section and [Asztalos and Madari, 2009], we generate executable source code and a binary class library from it. This transformation implementation can be executed from within VMTS, or it can be used in other applications building on VMTS components Ant-World Contest As already mentioned, the model transformation community organizes tool contests regularly to compare the usability and performance of the dierent approaches with various case studies. On the GraBaTs 2008 contest [GraBaTs08, 2008], the exercise was to simulate an anthill (Figure 6.2(a)) using model transformation. The map where the ants can move are built from nodes connected with concentric circles of edges. The nodes are also connected radially. The anthill itself can be found in the center of the map. Two concentric circles and eight ants in the center are created at the beginning of the simulation. When the simulation is started, the ants start searching for food. The movement of the ants can be considered random in this state. If an ant reaches the border of the map, another concentric circle must be created and 100 pieces of food are created on every 10th new node. If an ant reaches a node with food, it picks up one piece of food, and moves backward to the center. On its way backward, the ant drops 1024 pheromone on each node. If the ant reaches the center and drops the food, a new ant is born in the center. If pheromone is placed on the map, it inuences the movement of the ants searching

122 Chapter 6. Practical Application of the Scientific Results 110 CreateAxis CreateExtension CreateCorner FinishLevel MapProcessed UpdatePheromon CreateAnts NewAnt CreateMap MoveFromCenter Move4 OnFood Move6 MoveBack Figure 6.3. Rewriting rules of the Ant World simulation for food, as they prefer nodes with at least ten pieces of pheromone to nodes with less or none. The simulation is executed in separate rounds: each ant moves once in a round to an adjacent node. The number of pheromone should evaporate by 5% at the end of each round. We have prepared our solution using the VMTS transformation framework for the contest, and won an award in the "Best submitted performance" category. In the following, we shortly introduce our approach [Mészáros et al., 2008a]. Figure 6.2(b) depicts the control ow of our Ant World solution, while Figure 6.3 illustrates the rewriting rules in a simplied form. Rules in block (1) are used to build the initial map including the two levels of the map and the eight ants in the center. Rules in block (2) are responsible to perform ant movement, in order: picking up food, moving an ant with food back to the center, creating a new ant in the center, moving an ant without food out of the center, moving an ant if it stands on a node with six adjacent nodes, moving an ant with four adjacent nodes (not the center), and enabling the movement of the ants in a next round. The BorderCheck rule validates if there is an ant already at the edge of the map. If not, a new round begins, otherwise a new level of the map is built in block (3). In block (3), we create the upper right corner (CreateAxis), then build one side of the map (CreateExtension), and nally, we try to build another corner of the map. If possible, we continue to build another side, otherwise we nish building the new level. The UpdatePheromon rule evaporates the pheromone placed on the map-nodes at the end of each round MATLAB Integration In cooperation with MathWorks, our exercise was to adopt the VMTS model transformation technology from prototype research tools to Simulink, a tool which is widely used by the industry in model-based design. With some modications to the Simulink user interface, the core transformation technology can be made available for Simulink models. The exercise was realized in three main parts: 1. Transform the Simulink visual language denitions into VMTS metamodels, 2. adapt the Simulink model storage system to VMTS, 3. extend the Simulink model editor UI for the fast application of transformations. Since languages in Simulink are not metamodeled but use a proprietary denition system that is accessible through the API of MATLAB, rst we had to generate in VMTS a metamodel containing a corresponding element for each Simulink language item. VMTS assumes the presence of a model database interface implemented by arbitrary storage adapters, thus, we have realized a storage adapter for Simulink models. With the help of the generated metamodel and the storage adapter, we were able to open and edit simulink models inside VMTS. As the VMTS

123 Chapter 6. Practical Application of the Scientific Results 111 transformation engine also relies on the mentioned adapter, this allowed us to execute transformations on Simulink models. Finally, with a new menu item in Simulink, we facilitated to apply model transformations on Simulink models in place Model Animation We have realized the VAF concept in VMTS. In Figure 6.4, we illustrate how it is integrated into the modeling environment. The Modeling space block represents the model repository and the data access objects for creating and editing models and model elements. Static models VMTS Studio Dynamic models Animation engine VPF Animation Business Logic Modeling space Figure 6.4. Animation Framework architecture The VMTS Presentation Framework is a graphical modeling layer that is based on the Windows Presentation Foundation framework and applies its data binding mechanism to keep the visualization and the underlying model synchronized. Any change performed in the model (e.g. made by model transformation) is immediately reected in the visualization as well. Data binding can be manipulated with the help of converters. Converters are used to transform the data represented by model element properties into another or an aggregated form before presenting them on the screen. The visualized data can be but is not limited to alphanumeric text, color, position information, arbitrary transformation or even visibility property. The domain knowledge, the business logic of the animated model is implemented in the Animation Business Logic component. The component may operate on VMTS models, and it may also communicate with external components and applications such as MATLAB. The Animation engine denes the reactions to events coming from the business logic and from the VPF components. It updates model and visualization properties based on the messages coming from the business logic, and it may also control the business logic by sending events to that in response to user events events from VPF. Static and dynamic models are the concrete applications of the presentation framework extended with the animation engine Visual Transformation Debugger Using VAF, we have extended the model transformation engine of VMTS to support debugging i.e visualy tracing the transformation process. Using the transformation debugger, we can (i) see the status of the control ow, i.e. the currently active ow edge or node is highlighted; (ii) verify the matches during the execution of a specic rule: by hovering the mouse over an element in the rewriting rule model, the corresponding element of the match is highlighted in the host graph; (iii) see the result of executing a rule: new elements are added, deleted elements are removed from the diagram; (iv) and we are also able to place breakpoints into the control ow, thus, the

124 E Chapter 6. Practical Application of the Scientific Results 112 SIM_GT EH_GT PortModels PortLayout PortPeripher PortViews PortGT PortTimer Initialize ProcessNextCFEdge ProcessStartNode Matching ApplyCurrentMatch PortGT CFEdge StartNode EndNode RuleNode RuleExecutionResults Initialized PreNextCFEdge PostNextCFEdge PreStartNode PostStartNode PreEndNode PreRuleNode PreInitMatch PreMatching EH_UI ( ) PortViews PortPeripher PortLayout PortModels PortPeripher PortViews PortGT PortPeripher PortTimer PortGT Port EH_GT ( ) EH_Timer ( ) PreApplyCurrentMatch PostApplyCurrentMatch PostRuleNode (a) Event handler model for the model transformation engine ANIM_Highlighter ANIM_Shortcut (b) High-level animation model PortGT PortViews PortModels PortLayout PortTimer (1) (5) Initializing (3) ShowResults ApplyLayout GetWindowContent ApplyCurrentMatch OpenHostAndCF ProcessingStart HighlightMatch GetCFDiagram HighlightStartNode HighlightRuleNode GetHostDiagram (2) Executing (6) ProcessEndNode HighlightEdge PortViews PortPeripher PortGT (4) CheckBreakpoint PreApplyCurrentMatch Matching MouseEnter MouseOver GetNewCFEdge ApplyBreakpoint ProcessEdge PostApplyCurrentMatch MouseLeave (c) ANIM_GT Animator (d) ANIM_Highlighter Animator Figure 6.5. Animating model transformation transformation is paused if an edge with a breakpoint is found (for that purpose we have added a BreakP oint attribute to ow edges in the control ow metamodel). The rst step was to extend the model transformation engine with callbacks to provide information about its internal state, and we have wrapped it with an event handler. The corresponding event handler model is depicted in Figure 6.5(a). On the right hand side of the gure the events sent by the event handler are depicted (e.g. before and after processing a specic node or edge), while the left side depicts those events that can be sent to the transformation engine to process the next element in the control ow or e.g. to start the matching phase. In Figure 6.5(b), one can see three animators: AN IM_GT, AN IM_M atchhighlighter, and AN IM_Shortcut. AN IM_GT (Figure 6.5(c)) animates the control ow model, initiates the execution of the match and rewriting operations. AN IM_Shortcut catches the key-presses, and instructs the EH_T imer to re a T ick event if the F11 key was pressed. This feature is useful, if the timer is paused, and the user can execute the transformation step-by-step by hitting the F11 key. AN IM_M atchhighlighter (Figure 6.5(d)) catches the mouse events, and highlights the matched and created elements in the host and the output model of the transformation if the mouse hovers over an element in the rewriting rule. Thus, we can check which elements were

125 Chapter 6. Practical Application of the Scientific Results 113 matched by which item in the LHS of the rule, and which new elements were created after the application of the rule. Using several animators to provide a solution, we can clearly separate the orthogonal aspects of the problem space. A more complex scenario is implemented by the ANIM_GT animator. It is responsible for (i) animating the control ow model including the detection of breakpoints, (ii) initiating the execution of rewriting rules, and (iii) visualizing the changes of the output model. The internal structure of the animator is depicted in Figure 6.5(c). The states and transitions in block (1) are used to initialize the transformation, to open the host, to create the output model and to obtain a reference to the opened diagrams. The Executing state can be considered a default state of the animation, processing the individual elements of the control ow model is initiated and nished in this state. Blocks (3), (4), (5), and (6) are similar in the sense that they are responsible for processing and highlighting the elements of the control ow, namely, the start node, edges, rule nodes, and the stop node. Block (4) is entered after receiving a P renextcf Edge event. At this point, we have the possibility to parameterize the P rocessn extcf Edge event with another edge, and step to an arbitrary point in the control ow model. This parameter can be set after testing whether an Alt+click event is received (Alt+click on an edge is used to jump to the edge). Due to the interpreted feature of the graph rewriting engine of VMTS, one can freely edit the control ow as well as the host and output models during the debug process Model Animation-Based on MATLAB Simulation To illustrate how we can adapt external simulation engines to the animation framework, we have integrated the MATLAB API into VMTS, we simulated a Simulink model and presented its results in VMTS. The event handler model for MATLAB contains a single EventHandler node and three events: Execute, GetMatrix and GetMatrix_. Execute and GetMatrix correspond to the methods with the same name on the MATLAB API, these events are used to instruct the event handler to call the methods with the same name. The Execute method is used to apply an arbitrary MATLAB command using its interpreter. It does not have a return value and expects a single string parameter. The GetMatrix method returns a oating point matrix identied by its name parameter. The return value of GetM atrix is wrapped by the GetMatrix_ event. The simulated Simulink model (called sldemo_autotrans, Figure 6.6 c) is shipped with the MATLAB installation, and models an automatic transmission controller. If we execute the simulation in Simulink, we can inspect the parameters of the car (including speed, engine rotationper-minute, and throttle state) at dierent conditions. In the following example, we present these parameters on diagrams and also on monitors in VMTS. For this purpose, we have created a very simple visual language which can model indicators: numeric and stripe (Figure 6.6 d). Each indicator has a name, a range, and a value, the modeled indicators are animated according to the results received from MATLAB. Figure 6.6 a and b present the high-and low-level (state machine) animation models. As it can be seen in the high-level animation model, the animator is connected to (i) the UI event handler (EH_UI ), (ii) to the generated EngMATLib event handler and (iii) to a Timer that schedules the animation by sending a Tick event every 0.1 secs. The state machine model consists of the following steps: (1) query the active diagram, which contains the indicators to be animated (Figure 6.6 e); (2) execute the simulation by sending an Execute event with a "sim('sldemo_autotrans')" command to MATLAB; (3) query the time, speed, RPM, and throttle state vectors using GetMatrix on the signal logging structure called sldemo_autotrans_output ;

126 Chapter 6. Practical Application of the Scientific Results Figure Integrating Simulink simulations into VMTS (4) obtain a reference to the indicators using their names; (5) present the data-vectors on a diagram; (6) animate the indicators by iterating through the vectors, and updating the property of the indicators based on the data-vectors. Ticks Value Note that the loop is controlled by the of the timer event handler Model Pattern Support In addition to the domains and patterns presented in Chapter 5, we have de ned static model patterns in various other domains as well Mobil UI Patterns The VMTS group has been researching the modeling facilities of mobil user interfaces for years. We have built domain-speci c environments to model interfaces for Symbian, Windows Mobile, and the Java ME platforms. In the following, we present two often-recurring patterns for Symbian-based mobil user interfaces. Frame UI Pattern: controls. The frame of a basic mobile user interface model contains several Figure 6.7(a) presents the VMTS Symbian resource metamodel, and Figure 6.7(b) depicts the Frame UI Pattern. An additional constraint implied by the cardinality property (not shown in the gure) is that a valid resource model should contain exactly one element. Furthermore, there must be at least one element, and an optional number of control. This restriction is due to the design of Symbian, because the simple data controls (e.g. T imeeditor, elements. Each T exteditor, DateEditor) F orm F orm P age additional Control Application element must contain at least one can be inserted only onto a P age element. In order to de ne a frame for the user interface models when beginning the user interface development for the Symbian platform, the structure presented in Figure 6.7(b) is almost always prepared. The motivation to build this pattern is to save this work and provide the same structure with the help of a few mouse clicks. Contact Control Pattern: There are several basic controls that can be used to build user interfaces. In addition, there are several applications both on mobile and other platforms, which use compound user interface elements more than once or in more than one application. Such

127 Chapter 6. Practical Application of the Scientific Results 115 Application Form Page MenuBar MenuPane TextListBox MenuPaneItem ListBox Control HierarchicalList Box Label Dialog ProgressBar TextEditor Image CheckBox (a) Symbian metamodel (b) The Frame UI pattern (c) The Contact Control pattern Figure 6.7. Symbian domain and patterns Operational Amplifier PowerLine Power Resistor Element Junction Capacitor Ground Figure 6.8. The metamodel of schematic models a compound user interface element is a control that facilitates to collect contact information: name, phone number, fax number, address (zip code, city, street), address, etc. To make the user interface development ecient, we should provide similar compound controls in the user interface and other DSL modeling tools. Figure 6.7(c) presents the Contact Control Pattern with its application that contains the most common elds used to query user information Circuit Schematic Patterns We have built an environment to model electric circuits with primitive elements. The metamodel of the language is depicted in Figure 6.8. The aim of the Element node is to serve as an abstract root element for all the other items, thus by dening the P owerline relationship as a loop-edge on Element, all the non-abstract elements can be connected with the same type of relation. The instantiatable elements are Resistor, Capacitor, JunctionP oint (to connect lines), P owersupply, Ground, and OperationalAmplif ier a) Voltage follower b) Non-invering amplifier c) Invering amplifier d) High-pass filter e) Low-pass filter Figure 6.9. Schematic model patterns

On The Number Of Slim Semimodular Lattices

On The Number Of Slim Semimodular Lattices On The Number Of Slim Semimodular Lattices Gábor Czédli, Tamás Dékány, László Ozsvárt, Nóra Szakács, Balázs Udvari Bolyai Institute, University of Szeged Conference on Universal Algebra and Lattice Theory

Részletesebben

Széchenyi István Egyetem www.sze.hu/~herno

Széchenyi István Egyetem www.sze.hu/~herno Oldal: 1/6 A feladat során megismerkedünk a C# és a LabVIEW összekapcsolásának egy lehetőségével, pontosabban nagyon egyszerű C#- ban írt kódból fordítunk DLL-t, amit meghívunk LabVIEW-ból. Az eljárás

Részletesebben

Performance Modeling of Intelligent Car Parking Systems

Performance Modeling of Intelligent Car Parking Systems Performance Modeling of Intelligent Car Parking Systems Károly Farkas Gábor Horváth András Mészáros Miklós Telek Technical University of Budapest, Hungary EPEW 2014, Florence, Italy Outline Intelligent

Részletesebben

Using the CW-Net in a user defined IP network

Using the CW-Net in a user defined IP network Using the CW-Net in a user defined IP network Data transmission and device control through IP platform CW-Net Basically, CableWorld's CW-Net operates in the 10.123.13.xxx IP address range. User Defined

Részletesebben

Construction of a cube given with its centre and a sideline

Construction of a cube given with its centre and a sideline Transformation of a plane of projection Construction of a cube given with its centre and a sideline Exercise. Given the center O and a sideline e of a cube, where e is a vertical line. Construct the projections

Részletesebben

Szoftver-technológia II. Tervezési minták. Irodalom. Szoftver-technológia II.

Szoftver-technológia II. Tervezési minták. Irodalom. Szoftver-technológia II. Tervezési minták Irodalom Steven R. Schach: Object Oriented & Classical Software Engineering, McGRAW-HILL, 6th edition, 2005, chapter 8. E. Gamma, R. Helm, R. Johnson, J. Vlissides:Design patterns: Elements

Részletesebben

STUDENT LOGBOOK. 1 week general practice course for the 6 th year medical students SEMMELWEIS EGYETEM. Name of the student:

STUDENT LOGBOOK. 1 week general practice course for the 6 th year medical students SEMMELWEIS EGYETEM. Name of the student: STUDENT LOGBOOK 1 week general practice course for the 6 th year medical students Name of the student: Dates of the practice course: Name of the tutor: Address of the family practice: Tel: Please read

Részletesebben

Supporting Information

Supporting Information Supporting Information Cell-free GFP simulations Cell-free simulations of degfp production were consistent with experimental measurements (Fig. S1). Dual emmission GFP was produced under a P70a promoter

Részletesebben

Cloud computing. Cloud computing. Dr. Bakonyi Péter.

Cloud computing. Cloud computing. Dr. Bakonyi Péter. Cloud computing Cloud computing Dr. Bakonyi Péter. 1/24/2011 1/24/2011 Cloud computing 2 Cloud definició A cloud vagy felhő egy platform vagy infrastruktúra Az alkalmazások és szolgáltatások végrehajtására

Részletesebben

Bevezetés a kvantum-informatikába és kommunikációba 2015/2016 tavasz

Bevezetés a kvantum-informatikába és kommunikációba 2015/2016 tavasz Bevezetés a kvantum-informatikába és kommunikációba 2015/2016 tavasz Kvantumkapuk, áramkörök 2016. március 3. A kvantummechanika posztulátumai (1-2) 1. Állapotleírás Zárt fizikai rendszer aktuális állapota

Részletesebben

Cloud computing Dr. Bakonyi Péter.

Cloud computing Dr. Bakonyi Péter. Cloud computing Dr. Bakonyi Péter. 1/24/2011 Cloud computing 1/24/2011 Cloud computing 2 Cloud definició A cloud vagy felhő egy platform vagy infrastruktúra Az alkalmazások és szolgáltatások végrehajtására

Részletesebben

Cluster Analysis. Potyó László

Cluster Analysis. Potyó László Cluster Analysis Potyó László What is Cluster Analysis? Cluster: a collection of data objects Similar to one another within the same cluster Dissimilar to the objects in other clusters Cluster analysis

Részletesebben

Computer Architecture

Computer Architecture Computer Architecture Locality-aware programming 2016. április 27. Budapest Gábor Horváth associate professor BUTE Department of Telecommunications ghorvath@hit.bme.hu Számítógép Architektúrák Horváth

Részletesebben

Statistical Dependence

Statistical Dependence Statistical Dependence Petra Petrovics Statistical Dependence Deinition: Statistical dependence exists when the value o some variable is dependent upon or aected by the value o some other variable. Independent

Részletesebben

Pletykaalapú gépi tanulás teljesen elosztott környezetben

Pletykaalapú gépi tanulás teljesen elosztott környezetben Pletykaalapú gépi tanulás teljesen elosztott környezetben Hegedűs István Jelasity Márk témavezető Szegedi Tudományegyetem MTA-SZTE Mesterséges Intelligencia Kutatócsopot Motiváció Az adat adatközpontokban

Részletesebben

Correlation & Linear Regression in SPSS

Correlation & Linear Regression in SPSS Petra Petrovics Correlation & Linear Regression in SPSS 4 th seminar Types of dependence association between two nominal data mixed between a nominal and a ratio data correlation among ratio data Correlation

Részletesebben

LÉTRADIAGRAM FORDÍTÓK ELMÉLETE PLC VEZÉRLÉSEK SZÁMÁRA II.

LÉTRADIAGRAM FORDÍTÓK ELMÉLETE PLC VEZÉRLÉSEK SZÁMÁRA II. V. Évfolyam 1. szám - 2010. március Deák Ferenc deak@nct.hu LÉTRADIAGRAM FORDÍTÓK ELMÉLETE PLC VEZÉRLÉSEK SZÁMÁRA II. Absztrakt A létradiagram egyszerű, programozási képzettséggel nem rendelkező szakemberek

Részletesebben

Eladni könnyedén? Oracle Sales Cloud. Horváth Tünde Principal Sales Consultant 2014. március 23.

Eladni könnyedén? Oracle Sales Cloud. Horváth Tünde Principal Sales Consultant 2014. március 23. Eladni könnyedén? Oracle Sales Cloud Horváth Tünde Principal Sales Consultant 2014. március 23. Oracle Confidential Internal/Restricted/Highly Restricted Safe Harbor Statement The following is intended

Részletesebben

A logaritmikus legkisebb négyzetek módszerének karakterizációi

A logaritmikus legkisebb négyzetek módszerének karakterizációi A logaritmikus legkisebb négyzetek módszerének karakterizációi Csató László laszlo.csato@uni-corvinus.hu MTA Számítástechnikai és Automatizálási Kutatóintézet (MTA SZTAKI) Operációkutatás és Döntési Rendszerek

Részletesebben

Web Services. (webszolgáltatások): egy osztott alkalmazásfejlesztési plattform

Web Services. (webszolgáltatások): egy osztott alkalmazásfejlesztési plattform (webszolgáltatások): egy osztott alkalmazásfejlesztési plattform Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem A Web Service Web Service definíciója Számos definíció létezik. IBM [4] A Web

Részletesebben

Genome 373: Hidden Markov Models I. Doug Fowler

Genome 373: Hidden Markov Models I. Doug Fowler Genome 373: Hidden Markov Models I Doug Fowler Review From Gene Prediction I transcriptional start site G open reading frame transcriptional termination site promoter 5 untranslated region 3 untranslated

Részletesebben

Felnőttképzés Európában

Felnőttképzés Európában Felnőttképzés Európában Nincs szükség annyi diplomásra, amennyit képeznek Helyettük szakképzett emberekre lenne kereslet Az itthon OKJ-s képzés európai hagyományában két vonal érvényesül: - dán - német

Részletesebben

Mapping Sequencing Reads to a Reference Genome

Mapping Sequencing Reads to a Reference Genome Mapping Sequencing Reads to a Reference Genome High Throughput Sequencing RN Example applications: Sequencing a genome (DN) Sequencing a transcriptome and gene expression studies (RN) ChIP (chromatin immunoprecipitation)

Részletesebben

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

Simulation and transformation of domain-specific languages. Master s Thesis 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

Részletesebben

SQL/PSM kurzorok rész

SQL/PSM kurzorok rész SQL/PSM kurzorok --- 2.rész Tankönyv: Ullman-Widom: Adatbázisrendszerek Alapvetés Második, átdolgozott kiadás, Panem, 2009 9.3. Az SQL és a befogadó nyelv közötti felület (sormutatók) 9.4. SQL/PSM Sémában

Részletesebben

KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA

KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA System Design Wahl István 2019.03.26. BME FACULTY OF TRANSPORTATION ENGINEERING AND VEHICLE ENGINEERING Tartalomjegyzék Rövidítések A rendszer definiálása

Részletesebben

EN United in diversity EN A8-0206/419. Amendment

EN United in diversity EN A8-0206/419. Amendment 22.3.2019 A8-0206/419 419 Article 2 paragraph 4 point a point i (i) the identity of the road transport operator; (i) the identity of the road transport operator by means of its intra-community tax identification

Részletesebben

EN United in diversity EN A8-0206/473. Amendment

EN United in diversity EN A8-0206/473. Amendment 21.3.2019 A8-0206/473 473 Recital 12 d (new) (12d) Since there is no sufficient link of a driver with a territory of a Member State of transit, transit operations should not be considered as posting situations.

Részletesebben

EEA, Eionet and Country visits. Bernt Röndell - SES

EEA, Eionet and Country visits. Bernt Röndell - SES EEA, Eionet and Country visits Bernt Röndell - SES Európai Környezetvédelmi Ügynökség Küldetésünk Annak elősegítése, hogy az EU és a tagállamok a szükséges információk alapján hozhassák meg a környezet

Részletesebben

Adatbázisok 1. Rekurzió a Datalogban és SQL-99

Adatbázisok 1. Rekurzió a Datalogban és SQL-99 Adatbázisok 1 Rekurzió a Datalogban és SQL-99 Expressive Power of Datalog Without recursion, Datalog can express all and only the queries of core relational algebra. The same as SQL select-from-where,

Részletesebben

Dependency preservation

Dependency preservation Adatbázis-kezelés. (4 előadás: Relácó felbontásai (dekomponálás)) 1 Getting lossless decomposition is necessary. But of course, we also want to keep dependencies, since losing a dependency means, that

Részletesebben

ios alkalmazásfejlesztés Koltai Róbert

ios alkalmazásfejlesztés Koltai Róbert ios alkalmazásfejlesztés Koltai Róbert robert.koltai@ponte.hu Mi az a block? Utasítások sorozata { }-ek között, amit egy objektumként tuduk kezelni. ios 4.0 és Mac OSX 10.6 óta 2 Egy példa a felépítésére

Részletesebben

Declarative Specification of Domain Specific Visual Languages. Master s Thesis. Dr. Dániel Varró assistant professor

Declarative Specification of Domain Specific Visual Languages. Master s Thesis. Dr. Dániel Varró assistant professor Budapest University of Technology and Economics Department of Measurement and Information Systems Declarative Specification of Domain Specific Visual Languages Master s Thesis Supervisor: Dr. Dániel Varró

Részletesebben

This document has been provided by the International Center for Not-for-Profit Law (ICNL).

This document has been provided by the International Center for Not-for-Profit Law (ICNL). This document has been provided by the International Center for Not-for-Profit Law (ICNL). ICNL is the leading source for information on the legal environment for civil society and public participation.

Részletesebben

Rezgésdiagnosztika. Diagnosztika 02 --- 1

Rezgésdiagnosztika. Diagnosztika 02 --- 1 Rezgésdiagnosztika Diagnosztika 02 --- 1 Diagnosztika 02 --- 2 A rezgéskép elemzésével kimutatható gépészeti problémák Minden gép, mely tartalmaz forgó részt (pl. motor, generátor, szivattyú, ventilátor,

Részletesebben

Az Open Data jogi háttere. Dr. Telek Eszter

Az Open Data jogi háttere. Dr. Telek Eszter Az Open Data jogi háttere Dr. Telek Eszter Egy kis ismétlés Open Data/Open Access/Open Knowledge gyökerei Open Source Software FLOSS (Free Libre Open Source Software) Szoftver esetében egyszerű alapok:

Részletesebben

FOSS4G-CEE Prágra, 2012 május. Márta Gergely Sándor Csaba

FOSS4G-CEE Prágra, 2012 május. Márta Gergely Sándor Csaba FOSS4G-CEE Prágra, 2012 május Márta Gergely Sándor Csaba Reklám helye 2009 óta Intergraph szoftverek felől jöttünk FOSS4G felé megyünk Békés egymás mellett élés több helyen: Geoshop.hu Terkep.torokbalint.hu

Részletesebben

Skills Development at the National University of Public Service

Skills Development at the National University of Public Service Skills Development at the National University of Public Service Presented by Ágnes Jenei National University of Public Service Faculty of Public Administration Public Ethics and Communication 13. 12. 2013

Részletesebben

USER MANUAL Guest user

USER MANUAL Guest user USER MANUAL Guest user 1 Welcome in Kutatótér (Researchroom) Top menu 1. Click on it and the left side menu will pop up 2. With the slider you can make left side menu visible 3. Font side: enlarging font

Részletesebben

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet. Correlation & Linear. Petra Petrovics.

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet. Correlation & Linear. Petra Petrovics. Correlation & Linear Regression in SPSS Petra Petrovics PhD Student Types of dependence association between two nominal data mixed between a nominal and a ratio data correlation among ratio data Exercise

Részletesebben

Correlation & Linear Regression in SPSS

Correlation & Linear Regression in SPSS Correlation & Linear Regression in SPSS Types of dependence association between two nominal data mixed between a nominal and a ratio data correlation among ratio data Exercise 1 - Correlation File / Open

Részletesebben

Longman Exams Dictionary egynyelvű angol szótár nyelvvizsgára készülőknek

Longman Exams Dictionary egynyelvű angol szótár nyelvvizsgára készülőknek Longman Exams Dictionary egynyelvű angol szótár nyelvvizsgára készülőknek Egynyelvű angol nagyszótár haladó nyelvtanulóknak és nyelvvizsgázóknak 212,000 szócikkel A szótárban minden definíció egyszerű

Részletesebben

Modellalkotás UML-ben

Modellalkotás UML-ben Modellalkotás UML-ben Modellalkotás UML-ben A Unified Modeling Language (UML) egy grafikus modellező nyelv, amely lehetőséget nyújt egy megoldandó probléma specifikációjának leírására absztrakt szinten,

Részletesebben

A modern e-learning lehetőségei a tűzoltók oktatásának fejlesztésében. Dicse Jenő üzletfejlesztési igazgató

A modern e-learning lehetőségei a tűzoltók oktatásának fejlesztésében. Dicse Jenő üzletfejlesztési igazgató A modern e-learning lehetőségei a tűzoltók oktatásának fejlesztésében Dicse Jenő üzletfejlesztési igazgató How to apply modern e-learning to improve the training of firefighters Jenő Dicse Director of

Részletesebben

Abigail Norfleet James, Ph.D.

Abigail Norfleet James, Ph.D. Abigail Norfleet James, Ph.D. Left side of brain develops first in girls, right in boys o Probably source of girls verbal skills o And source of boys spatial skills Pre-frontal lobes Control impulses and

Részletesebben

Utolsó frissítés / Last update: február Szerkesztő / Editor: Csatlós Árpádné

Utolsó frissítés / Last update: február Szerkesztő / Editor: Csatlós Árpádné Utolsó frissítés / Last update: 2016. február Szerkesztő / Editor: Csatlós Árpádné TARTALOM / Contents BEVEZETŐ / Introduction... 2 FELNŐTT TAGBÉLYEGEK / Adult membership stamps... 3 IFJÚSÁGI TAGBÉLYEGEK

Részletesebben

± ± ± ƒ ± ± ± ± ± ± ± ƒ. ± ± ƒ ± ± ± ± ƒ. ± ± ± ± ƒ

± ± ± ƒ ± ± ± ± ± ± ± ƒ. ± ± ƒ ± ± ± ± ƒ. ± ± ± ± ƒ ± ± ± ± ƒ ± ± ± ƒ ± ± ƒ ± ç å ± ƒ ± ± ± ± ± ± ± ± ± ± ± ƒ ± ± ± ä ± ± ± ± ƒ ± ± ± ± ƒ ± ± ± ± ƒ ± ± ± ± ƒ ± ± ± ± ± ± ± ± ± ± ± ± ± ± ƒ ± ± ± ± ± ƒ ± ± ± ± ƒ ± ± ± ƒ ± ± ƒ ± ± ± ± ± ± ± ± ± ± ± ± ± ±

Részletesebben

ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN

ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN ÉRETTSÉGI VIZSGA 2008. május 26. ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN KÖZÉPSZINTŰ ÍRÁSBELI VIZSGA 2008. május 26. 8:00 Az írásbeli vizsga időtartama: 180 perc Pótlapok száma Tisztázati Piszkozati OKTATÁSI

Részletesebben

BKI13ATEX0030/1 EK-Típus Vizsgálati Tanúsítvány/ EC-Type Examination Certificate 1. kiegészítés / Amendment 1 MSZ EN 60079-31:2014

BKI13ATEX0030/1 EK-Típus Vizsgálati Tanúsítvány/ EC-Type Examination Certificate 1. kiegészítés / Amendment 1 MSZ EN 60079-31:2014 (1) EK-TípusVizsgálati Tanúsítvány (2) A potenciálisan robbanásveszélyes környezetben történő alkalmazásra szánt berendezések, védelmi rendszerek 94/9/EK Direktíva / Equipment or Protective Systems Intended

Részletesebben

A forrás pontos megnevezésének elmulasztása valamennyi hivatkozásban szerzői jogsértés (plágium).

A forrás pontos megnevezésének elmulasztása valamennyi hivatkozásban szerzői jogsértés (plágium). A szakirodalmi idézések és hivatkozások rendszere és megadásuk szabályai A bibliográfia legfontosabb szabályai Fogalma: Bibliográfiai hivatkozáson azoknak a pontos és kellően részletezett adatoknak az

Részletesebben

EN United in diversity EN A8-0206/445. Amendment

EN United in diversity EN A8-0206/445. Amendment 21.3.2019 A8-0206/445 445 Title Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL amending Directive 2006/22/EC as regards enforcement requirements and laying down specific rules with

Részletesebben

KELET-ÁZSIAI DUPLANÁDAS HANGSZEREK ÉS A HICHIRIKI HASZNÁLATA A 20. SZÁZADI ÉS A KORTÁRS ZENÉBEN

KELET-ÁZSIAI DUPLANÁDAS HANGSZEREK ÉS A HICHIRIKI HASZNÁLATA A 20. SZÁZADI ÉS A KORTÁRS ZENÉBEN Liszt Ferenc Zeneművészeti Egyetem 28. számú művészet- és művelődéstörténeti tudományok besorolású doktori iskola KELET-ÁZSIAI DUPLANÁDAS HANGSZEREK ÉS A HICHIRIKI HASZNÁLATA A 20. SZÁZADI ÉS A KORTÁRS

Részletesebben

Cashback 2015 Deposit Promotion teljes szabályzat

Cashback 2015 Deposit Promotion teljes szabályzat Cashback 2015 Deposit Promotion teljes szabályzat 1. Definitions 1. Definíciók: a) Account Client s trading account or any other accounts and/or registers maintained for Számla Az ügyfél kereskedési számlája

Részletesebben

ANGOL NYELV KÖZÉPSZINT SZÓBELI VIZSGA I. VIZSGÁZTATÓI PÉLDÁNY

ANGOL NYELV KÖZÉPSZINT SZÓBELI VIZSGA I. VIZSGÁZTATÓI PÉLDÁNY ANGOL NYELV KÖZÉPSZINT SZÓBELI VIZSGA I. VIZSGÁZTATÓI PÉLDÁNY A feladatsor három részbol áll 1. A vizsgáztató társalgást kezdeményez a vizsgázóval. 2. A vizsgázó egy szituációs feladatban vesz részt a

Részletesebben

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet Factor Analysis

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet Factor Analysis Factor Analysis Factor analysis is a multiple statistical method, which analyzes the correlation relation between data, and it is for data reduction, dimension reduction and to explore the structure. Aim

Részletesebben

Dr. Sasvári Péter Egyetemi docens

Dr. Sasvári Péter Egyetemi docens A KKV-k Informatikai Infrastruktúrájának vizsgálata a Visegrádi országokban The Analysis Of The IT Infrastructure Among SMEs In The Visegrád Group Of Countries Dr. Sasvári Péter Egyetemi docens MultiScience

Részletesebben

Kvantum-informatika és kommunikáció 2015/2016 ősz. A kvantuminformatika jelölésrendszere szeptember 11.

Kvantum-informatika és kommunikáció 2015/2016 ősz. A kvantuminformatika jelölésrendszere szeptember 11. Kvantum-informatika és kommunikáció 2015/2016 ősz A kvantuminformatika jelölésrendszere 2015. szeptember 11. Mi lehet kvantumbit? Kvantum eszközök (1) 15=5 3 Bacsárdi Képek forrása: IBM's László, Almaden

Részletesebben

Az M2M szabványosítási helyzete

Az M2M szabványosítási helyzete Az M2M szabványosítási helyzete Dr. Bartolits István Főosztályvezető Nemzeti Média- és Hírközlési Hatóság Technológia-elemző főosztály HTE Infokom 2014 Kecskemét, 2014. október 8-10. HTE Infokom 2014,

Részletesebben

Néhány folyóiratkereső rendszer felsorolása és példa segítségével vázlatos bemutatása Sasvári Péter

Néhány folyóiratkereső rendszer felsorolása és példa segítségével vázlatos bemutatása Sasvári Péter Néhány folyóiratkereső rendszer felsorolása és példa segítségével vázlatos bemutatása Sasvári Péter DOI: http://doi.org/10.13140/rg.2.2.28994.22721 A tudományos közlemények írása minden szakma művelésének

Részletesebben

KÖZGAZDASÁGI ALAPISMERETEK (ELMÉLETI GAZDASÁGTAN) ANGOL NYELVEN BASIC PRINCIPLES OF ECONOMY (THEORETICAL ECONOMICS)

KÖZGAZDASÁGI ALAPISMERETEK (ELMÉLETI GAZDASÁGTAN) ANGOL NYELVEN BASIC PRINCIPLES OF ECONOMY (THEORETICAL ECONOMICS) ÉRETTSÉGI VIZSGA 2005. május 20. KÖZGAZDASÁGI ALAPISMERETEK (ELMÉLETI GAZDASÁGTAN) ANGOL NYELVEN BASIC PRINCIPLES OF ECONOMY (THEORETICAL ECONOMICS) KÖZÉPSZINTŰ ÍRÁSBELI VIZSGA MEDIUM-LEVEL WRITTEN EXAM

Részletesebben

3. MINTAFELADATSOR KÖZÉPSZINT. Az írásbeli vizsga időtartama: 30 perc. III. Hallott szöveg értése

3. MINTAFELADATSOR KÖZÉPSZINT. Az írásbeli vizsga időtartama: 30 perc. III. Hallott szöveg értése Oktatáskutató és Fejlesztő Intézet TÁMOP-3.1.1-11/1-2012-0001 XXI. századi közoktatás (fejlesztés, koordináció) II. szakasz ANGOL NYELV 3. MINTAFELADATSOR KÖZÉPSZINT Az írásbeli vizsga időtartama: 30 perc

Részletesebben

FAMILY STRUCTURES THROUGH THE LIFE CYCLE

FAMILY STRUCTURES THROUGH THE LIFE CYCLE FAMILY STRUCTURES THROUGH THE LIFE CYCLE István Harcsa Judit Monostori A magyar társadalom 2012-ben: trendek és perspektívák EU összehasonlításban Budapest, 2012 november 22-23 Introduction Factors which

Részletesebben

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet Nonparametric Tests

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet Nonparametric Tests Nonparametric Tests Petra Petrovics Hypothesis Testing Parametric Tests Mean of a population Population proportion Population Standard Deviation Nonparametric Tests Test for Independence Analysis of Variance

Részletesebben

Mérnök informatikus (BSc) alapszak levelező tagozat (BIL) / BSc in Engineering Information Technology (Part Time)

Mérnök informatikus (BSc) alapszak levelező tagozat (BIL) / BSc in Engineering Information Technology (Part Time) Mérnök informatikus (BSc) alapszak levelező tagozat (BIL) / BSc in Engineering Information Technology (Part Time) (specializáció választás a 4. félévben, specializációra lépés feltétele: az egyik szigorlat

Részletesebben

Professional competence, autonomy and their effects

Professional competence, autonomy and their effects ENIRDELM 2014, Vantaa Professional competence, autonomy and their effects Mária Szabó szabo.maria@ofi.hu www.of.hu The aim and the planned activities at this workshop Aim: To take a European survey on

Részletesebben

Website review acci.hu

Website review acci.hu Website review acci.hu Generated on September 30 2016 21:54 PM The score is 37/100 SEO Content Title Acci.hu - Ingyenes apróhirdető Length : 30 Perfect, your title contains between 10 and 70 characters.

Részletesebben

SZAKMAI BESZÁMOLÓ EVK SZAKKOLLÉGIUM. BESZÁMOLÓ: A 2014/2015 A Pallas Athéné Domus Scientiae Alapítvány pályázatára 2014/2015-ÖS TANÉV

SZAKMAI BESZÁMOLÓ EVK SZAKKOLLÉGIUM. BESZÁMOLÓ: A 2014/2015 A Pallas Athéné Domus Scientiae Alapítvány pályázatára 2014/2015-ÖS TANÉV SZAKMAI BESZÁMOLÓ EVK SZAKKOLLÉGIUM BESZÁMOLÓ: A 2014/2015 A Pallas Athéné Domus Scientiae Alapítvány pályázatára 2014/2015-ÖS TANÉV 1 Tőzsdekurzus A kurzus fókuszában - az elméleti bevezetőt követően

Részletesebben

2. Local communities involved in landscape architecture in Óbuda

2. Local communities involved in landscape architecture in Óbuda Év Tájépítésze pályázat - Wallner Krisztina 2. Közösségi tervezés Óbudán Óbuda jelmondata: Közösséget építünk, ennek megfelelően a formálódó helyi közösségeket bevonva fejlesztik a közterületeket. Békásmegyer-Ófaluban

Részletesebben

9el[hW][e\L;BI IjWdZWhZi

9el[hW][e\L;BI IjWdZWhZi 9el[hW][e\L;BI IjWdZWhZi The content and activities in Alive 3 and Alive 4 have been prepared to allow students to achieve the Victorian Essential Learning Standards (VELS) for Level 6. The key elements

Részletesebben

építészet & design ipari alkalmazás teherautó felépítmény

építészet & design ipari alkalmazás teherautó felépítmény A Design-Composit egy kompozitpaneleket gyártó vállalat, mely teherautó felépítményekhez, az építészet számára és design termékekhez készít paneleket. We are an innovative manufacturer of composite panels

Részletesebben

DANS és Narcis. Burmeister Erzsébet. HUNOR találkozó, Budapest 2013. március 13.

DANS és Narcis. Burmeister Erzsébet. HUNOR találkozó, Budapest 2013. március 13. DANS és Narcis Burmeister Erzsébet HUNOR találkozó, Budapest 2013. március 13. DANS DANS (Data Archiving and Network Services) http://www.dans.knaw.nl Kutatási adatok archiválása a saját fejlesztésű EASY

Részletesebben

A controlling és az értékelemzés összekapcsolása, különös tekintettel a felsőoktatási és a gyakorlati alkalmazhatóságra

A controlling és az értékelemzés összekapcsolása, különös tekintettel a felsőoktatási és a gyakorlati alkalmazhatóságra A controlling és az értékelemzés összekapcsolása, különös tekintettel a felsőoktatási és a gyakorlati alkalmazhatóságra Dr. Szóka Károly Nyugat-magyarországi Egyetem Közgazdaságtudományi Kar Egyetemi docens

Részletesebben

Phenotype. Genotype. It is like any other experiment! What is a bioinformatics experiment? Remember the Goal. Infectious Disease Paradigm

Phenotype. Genotype. It is like any other experiment! What is a bioinformatics experiment? Remember the Goal. Infectious Disease Paradigm It is like any other experiment! What is a bioinformatics experiment? You need to know your data/input sources You need to understand your methods and their assumptions You need a plan to get from point

Részletesebben

RÉZKULTÚRA BUDAPESTEN

RÉZKULTÚRA BUDAPESTEN RÉZKULTÚRA BUDAPESTEN A rezet megmunkálhatósága és idôtállósága miatt évszázadok óta használjuk. Alkalmazása egyértelmûen megbízható és gazdaságos. Színe, diszkrét fénye, a belôle készült tárgyak eleganciája

Részletesebben

ENROLLMENT FORM / BEIRATKOZÁSI ADATLAP

ENROLLMENT FORM / BEIRATKOZÁSI ADATLAP ENROLLMENT FORM / BEIRATKOZÁSI ADATLAP CHILD S DATA / GYERMEK ADATAI PLEASE FILL IN THIS INFORMATION WITH DATA BASED ON OFFICIAL DOCUMENTS / KÉRJÜK, TÖLTSE KI A HIVATALOS DOKUMENTUMOKBAN SZEREPLŐ ADATOK

Részletesebben

A vitorlázás versenyszabályai a 2013-2016. évekre angol-magyar nyelvű kiadásának változási és hibajegyzéke

A vitorlázás versenyszabályai a 2013-2016. évekre angol-magyar nyelvű kiadásának változási és hibajegyzéke A vitorlázás versenyszabályai a 2013-2016. évekre angol-magyar nyelvű kiadásának változási és hibajegyzéke A dokumentum A vitorlázás versenyszabályai a 2013-2016. évekre angol-magyar nyelvű kiadásában

Részletesebben

NYOMÁSOS ÖNTÉS KÖZBEN ÉBREDŐ NYOMÁSVISZONYOK MÉRÉTECHNOLÓGIAI TERVEZÉSE DEVELOPMENT OF CAVITY PRESSURE MEASUREMENT FOR HIGH PRESURE DIE CASTING

NYOMÁSOS ÖNTÉS KÖZBEN ÉBREDŐ NYOMÁSVISZONYOK MÉRÉTECHNOLÓGIAI TERVEZÉSE DEVELOPMENT OF CAVITY PRESSURE MEASUREMENT FOR HIGH PRESURE DIE CASTING Anyagmérnöki Tudományok, 39/1 (2016) pp. 82 86. NYOMÁSOS ÖNTÉS KÖZBEN ÉBREDŐ NYOMÁSVISZONYOK MÉRÉTECHNOLÓGIAI TERVEZÉSE DEVELOPMENT OF CAVITY PRESSURE MEASUREMENT FOR HIGH PRESURE DIE CASTING LEDNICZKY

Részletesebben

Emelt szint SZÓBELI VIZSGA VIZSGÁZTATÓI PÉLDÁNY VIZSGÁZTATÓI. (A részfeladat tanulmányozására a vizsgázónak fél perc áll a rendelkezésére.

Emelt szint SZÓBELI VIZSGA VIZSGÁZTATÓI PÉLDÁNY VIZSGÁZTATÓI. (A részfeladat tanulmányozására a vizsgázónak fél perc áll a rendelkezésére. Emelt szint SZÓBELI VIZSGA VIZSGÁZTATÓI PÉLDÁNY VIZSGÁZTATÓI PÉLDÁNY A feladatsor három részből áll 1. A vizsgáztató társalgást kezdeményez a vizsgázóval. 2. A vizsgázó egy vita feladatban vesz részt a

Részletesebben

Statistical Inference

Statistical Inference Petra Petrovics Statistical Inference 1 st lecture Descriptive Statistics Inferential - it is concerned only with collecting and describing data Population - it is used when tentative conclusions about

Részletesebben

Utolsó frissítés / Last update: Szeptember / September Szerkesztő / Editor: Csatlós Árpádné

Utolsó frissítés / Last update: Szeptember / September Szerkesztő / Editor: Csatlós Árpádné Utolsó frissítés / Last update: 2018. Szeptember / September Szerkesztő / Editor: Csatlós Árpádné TARTALOM / Contents BEVEZETŐ / Introduction... 2 FELNŐTT TAGBÉLYEGEK / Adult membership stamps... 3 IFJÚSÁGI

Részletesebben

Angol Középfokú Nyelvvizsgázók Bibliája: Nyelvtani összefoglalás, 30 kidolgozott szóbeli tétel, esszé és minta levelek + rendhagyó igék jelentéssel

Angol Középfokú Nyelvvizsgázók Bibliája: Nyelvtani összefoglalás, 30 kidolgozott szóbeli tétel, esszé és minta levelek + rendhagyó igék jelentéssel Angol Középfokú Nyelvvizsgázók Bibliája: Nyelvtani összefoglalás, 30 kidolgozott szóbeli tétel, esszé és minta levelek + rendhagyó igék jelentéssel Timea Farkas Click here if your download doesn"t start

Részletesebben

Formula Sound árlista

Formula Sound árlista MIXERS FF-6000; FF6000P Formula Sound 160 6 channel dual format DJ mixer with removable fader panel. (Supplied with linear faders) Formula Sound 160P As above but with PRO X crossfade fitted. Formula Sound

Részletesebben

Unit 10: In Context 55. In Context. What's the Exam Task? Mediation Task B 2: Translation of an informal letter from Hungarian to English.

Unit 10: In Context 55. In Context. What's the Exam Task? Mediation Task B 2: Translation of an informal letter from Hungarian to English. Unit 10: In Context 55 UNIT 10 Mediation Task B 2 Hungarian into English In Context OVERVIEW 1. Hungarian and English in Context 2. Step By Step Exam Techniques Real World Link Students who have studied

Részletesebben

Characterizations and Properties of Graphs of Baire Functions

Characterizations and Properties of Graphs of Baire Functions Characterizations and Properties of Graphs of Baire Functions BSc Szakdolgozat Szerz : Témavezet : Maga Balázs Buczolich Zoltán Matematika BSc Matematikus Egyetemi tanár Analízis Tanszék Eötvös Loránd

Részletesebben

Ister-Granum EGTC. Istvan FERENCSIK Project manager. The Local Action Plans to improve project partners crossborder

Ister-Granum EGTC. Istvan FERENCSIK Project manager. The Local Action Plans to improve project partners crossborder Expertising Governance for Transfrontier Conurbations Ister-Granum EGTC Istvan FERENCSIK Project manager The Local Action Plans to improve project partners crossborder governance «EGTC» URBACT Final conference

Részletesebben

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet. Nonparametric Tests. Petra Petrovics.

Miskolci Egyetem Gazdaságtudományi Kar Üzleti Információgazdálkodási és Módszertani Intézet. Nonparametric Tests. Petra Petrovics. Nonparametric Tests Petra Petrovics PhD Student Hypothesis Testing Parametric Tests Mean o a population Population proportion Population Standard Deviation Nonparametric Tests Test or Independence Analysis

Részletesebben

MATEMATIKA ANGOL NYELVEN MATHEMATICS

MATEMATIKA ANGOL NYELVEN MATHEMATICS ÉRETTSÉGI VIZSGA 2005. május 10. MATEMATIKA ANGOL NYELVEN MATHEMATICS EMELT SZINTŰ ÍRÁSBELI VIZSGA HIGHER LEVEL WRITTEN EXAMINATION Az írásbeli vizsga időtartama: 240 perc Time allowed for the examination:

Részletesebben

Sebastián Sáez Senior Trade Economist INTERNATIONAL TRADE DEPARTMENT WORLD BANK

Sebastián Sáez Senior Trade Economist INTERNATIONAL TRADE DEPARTMENT WORLD BANK Sebastián Sáez Senior Trade Economist INTERNATIONAL TRADE DEPARTMENT WORLD BANK Despite enormous challenges many developing countries are service exporters Besides traditional activities such as tourism;

Részletesebben

MULTI-ÁGENS SZIMULÁCIÓK

MULTI-ÁGENS SZIMULÁCIÓK KMOP-1.1.2-08/1-2008-0002 pályázat A kutatás-fejlesztési központok fejlesztése és megerősítése Záró rendezvény Budapest, MULTI-ÁGENS SZIMULÁCIÓK Gulyás László, AITIA International Zrt. Szimuláció 2 Nagy

Részletesebben

GEOGRAPHICAL ECONOMICS B

GEOGRAPHICAL ECONOMICS B GEOGRAPHICAL ECONOMICS B ELTE Faculty of Social Sciences, Department of Economics Geographical Economics "B" KRUGMAN (1991) MODEL: EXTENSIONS Authors: Gábor Békés, Sarolta Rózsás Supervised by Gábor

Részletesebben

Create & validate a signature

Create & validate a signature IOTA TUTORIAL 7 Create & validate a signature v.0.0 KNBJDBIRYCUGVWMSKPVA9KOOGKKIRCBYHLMUTLGGAV9LIIPZSBGIENVBQ9NBQWXOXQSJRIRBHYJ9LCTJLISGGBRFRTTWD ABBYUVKPYFDJWTFLICYQQWQVDPCAKNVMSQERSYDPSSXPCZLVKWYKYZMREAEYZOSPWEJLHHFPYGSNSUYRZXANDNQTTLLZA

Részletesebben

ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN

ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN ÉRETTSÉGI VIZSGA 2013. május 23. ELEKTRONIKAI ALAPISMERETEK ANGOL NYELVEN KÖZÉPSZINTŰ ÍRÁSBELI VIZSGA 2013. május 23. 8:00 Az írásbeli vizsga időtartama: 180 perc Pótlapok száma Tisztázati Piszkozati EMBERI

Részletesebben

TÉRGAZDÁLKODÁS - A TÉR MINT VÉGES KÖZÖSSÉGI ERŐFORRÁS INGATLAN NYILVÁNTARTÁS - KÜLFÖLDI PÉLDÁK H.NAGY RÓBERT, HUNAGI

TÉRGAZDÁLKODÁS - A TÉR MINT VÉGES KÖZÖSSÉGI ERŐFORRÁS INGATLAN NYILVÁNTARTÁS - KÜLFÖLDI PÉLDÁK H.NAGY RÓBERT, HUNAGI TÉRGAZDÁLKODÁS - A TÉR MINT VÉGES KÖZÖSSÉGI ERŐFORRÁS INGATLAN NYILVÁNTARTÁS - KÜLFÖLDI PÉLDÁK H.NAGY RÓBERT, HUNAGI TÉRADAT PONTOS FRISS ELÉRHETŐ CÉL Elvárások FELHASZNÁLÓ Helytállóság Elégedettség ESZKÖZ

Részletesebben

EBBEN A VIZSGARÉSZBEN A VIZSGAFELADAT ARÁNYA

EBBEN A VIZSGARÉSZBEN A VIZSGAFELADAT ARÁNYA Az Országos Képzési Jegyzékről és az Országos Képzési Jegyzékbe történő felvétel és törlés eljárási rendjéről szóló 133/2010. (IV. 22.) Korm. rendelet alapján. Szakképesítés, szakképesítés-elágazás, rész-szakképesítés,

Részletesebben

- eqµah ³. -ry³eblbmebjkargar³

- eqµah ³. -ry³eblbmebjkargar³ : : krmgsmnyrsmöasemxum eyig TaMgGs;Kña CanisSitmkBIsaklviTüayl½yebolR)aysaxaextþesomrab kmbugsiksa RsavRCavGMBI RbFanbT kargpivdæskáanubletscrn_enaxumkmbg;xøamg smrab;sarnabba b;fñak; bribaøab½rt CMnaj

Részletesebben

DR. BOROMISZA ZSOMBOR. A zalakarosi termáltó tájbaillesztése

DR. BOROMISZA ZSOMBOR. A zalakarosi termáltó tájbaillesztése DR. BOROMISZA ZSOMBOR A zalakarosi termáltó tájbaillesztése A zalakarosi Termáltó és Ökopart projekthez kapcsolódóan a tájépítészeti eszköztár szinte minden elemére szükség volt, hiszen védett növények

Részletesebben

Contact us Toll free (800) fax (800)

Contact us Toll free (800) fax (800) Table of Contents Thank you for purchasing our product, your business is greatly appreciated. If you have any questions, comments, or concerns with the product you received please contact the factory.

Részletesebben

PIACI HIRDETMÉNY / MARKET NOTICE

PIACI HIRDETMÉNY / MARKET NOTICE PIACI HIRDETMÉNY / MARKET NOTICE HUPX DAM Másnapi Aukció / HUPX DAM Day-Ahead Auction Iktatási szám / Notice #: HUPX-MN-DAM-2018-0001 Dátum / Of: 26/01/2018 Tárgy / Subject: Hatályos díjszabás és kedvezmények

Részletesebben

Decision where Process Based OpRisk Management. made the difference. Norbert Kozma Head of Operational Risk Control. Erste Bank Hungary

Decision where Process Based OpRisk Management. made the difference. Norbert Kozma Head of Operational Risk Control. Erste Bank Hungary Decision where Process Based OpRisk Management made the difference Norbert Kozma Head of Operational Risk Control Erste Bank Hungary About Erste Group 2010. 09. 30. 2 Erste Bank Hungary Erste Group entered

Részletesebben

Ensemble Kalman Filters Part 1: The basics

Ensemble Kalman Filters Part 1: The basics Ensemble Kalman Filters Part 1: The basics Peter Jan van Leeuwen Data Assimilation Research Centre DARC University of Reading p.j.vanleeuwen@reading.ac.uk Model: 10 9 unknowns P[u(x1),u(x2),T(x3),.. Observations:

Részletesebben