Search-Based Techniques in Model-Driven Engineering

(1)

Budapest University of Technology and Economics Department of Measurement and Information Systems

Search-Based Techniques in Model-Driven Engineering

PhD Thesis

Ákos Horváth

MSc in Technical Informatics

Supervisor:

Dr. Dániel Varró, PhD

associate professor

Budapest, February 2013

(2)

(3)

i

Nyilatkozat önálló munkáról, hivatkozások átvételéről

Alulírott Horváth Ákos 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 tartalom- ban, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem.

Declaration of own work and references

I, Ákos Horváth, hereby declare, that this thesis, and all results claimed therein are my own work, and rely solely on the references given. All segments taken word-by-word, or in the same meaning from others have been clearly marked as citations and included in the references.

Budapest, 2013. 02. 19.

Ákos Horváth

A dolgozat bírálatai és a védésről készült jegyzőkönyv a későbbiekben a Budapesti Műszaki és Gaz- daságtudományi Egyetem Villamosmérnöki és Informatikai Karának Dékáni Hivatalában elérhetők.

(4)

(5)

iii

Summary

The growing complexity of system development demands for the widespread use of design automation in order to continuously improve productivity, achieve better quality and lower maintenance and documentation costs.

Model-Driven Engineering (MDE) has recently become a key technique in systems engineering with the goal to provide these automations. MDE facilitates the systematic use of models and implies thatmodels play a central rolethat encompasses the entire system development lifecycle. These models can be used in design automation fordocumentation,early model-based validationandgener- ative development. Common in these automation techniques that they are heavily relying on model transformation as it provides their foundations of effective manipulation and querying of models.

Usually in early phases of designing complex systems models are not sufficiently detailed to serve as an input for design automation approaches. Instead, a design space is constituted by multiple models representing different valid design candidates. Design Space Exploration (DSE) aims atsearching and constructing such candidatesdefined in the design space which satisfy all structural and numeric design constraints based on various quality metrics such as performance, cost, power, reliability, etc.

Unfortunately, despite the significant investment of research and development into the application of MDE for the development of complex system there have been very few methods directly aiming to define automated model-based techniques that can solve complex structural constraints over the system design already captured by a set of models. Moreover, as complexity of systems are rising, scaling model transformations capable of handling models ranging in the millions of elements is becoming a crucial problem for supporting such advanced MDE based techniques.

Therefore, this thesis is centered around the concept of providing novel search-based techniques in model-driven engineering for both (i)high-level design automation basedon design space exploration for solving complex structural constraints and (ii)scalable model transformation combining different model querying approaches for effective graph pattern matching.

I propose a general framework for uniformly representing arbitrary search operations by expressing them as cost-weighted predicates that allows to uniformly guide the graph pattern matching process. Built on top of this general representation, I propose a hybrid pattern matching approach which enables the transformation designer to combine different graph pattern matching approaches to adapt to memory and performance constraints.

I present a model-driven design space exploration technique defined as an extension to finite- domain constraint satisfaction problems by using graph patterns to define structural (first-order logic) constraints, and graph transformation rules as labeling operations. However, instead of simple variable substitution, the labeling phase applies graph transformation rules to carry out model manipulations on the underlying graph domain.

As a motivating example in the context of the DIANA EU FP6 project for practical application of the contributions of the thesis, I designed and participated in the development of a complete MDE based development framework for systematically designing configuration tables for civil avionics real-time operating systems. My research in the context of this work was focused on three topics: (i) adaptation of MDE techniques for defining a specific development process for avionics configuration design that is in-line with the DO-178B certification requirements (ii) definition and reuse of model- based validation techniques for early error detection and localization and (iii) implementation of end-to-end traceability from high-level models to generated artifacts through the complete process that conforms to DO-178B.

(6)

iv

Összefoglaló

A rendszerek komplexitásának növekedésével azonos ütemben egyre széles körben kezdenek elter- jedni a különféle tervezésautomatizálási módszerek, melyek célja a termelékenység és a minőség növelésével párhuzamosan a karbantartási és a dokumentációs költségek csökkentése.

A modellvezérelt fejlesztés (MDE) egyik kitűzött célja ezen automatizálási módszerek hatékony megvalósítása. Az MDE szerint minden, a tervezésautomatizálás szempontjából releváns informá- ciót absztrakt modellekben tárolunk. E modellek segítségével automatizálható (i) a tervezés alatt álló rendszerstrukturált dokumentálása, (ii) a valós implementációt megelőzőmodell alapú validációjaés (iii) a cél platform elemeinekautomatikus generálása. Közös ezekben az automatizálásokban, hogy legnagyobbrészt modelltranszformációkra támaszkodnak a modellek hatékony lekérdezésére és ma- nipulációjára.

Egy MDE folyamat kezdetén a modellek jellemzően még nem eléggé specifikusak az automatikus kódgeneráláshoz, azok egy tervezési teret feszítenek ki. Ilyenkor a kifeszített térben megtalálható modellek közöttkeresünk egy olyan megoldást(design space exploration DSE), amely teljesíti a rend- szerrel szemben támasztott követelményeket és kielégítő megoldást ad az összes minőségi metrikára (teljesítmény, megbízhatóság, stb.).

Azonban annak ellenére, hogy igen széleskörű kutatásokat végeztek komplex rendszerek modell- alapú fejlesztésével kapcsolatban, kevesen foglalkoztak specifikusan modellek felett definiált komplex strukturális kényszerek automatikus kielégítésével. Másfelől, az ilyen modellvezérlet technikákra épülő alkalmazások esetén kulcsfontosságú a modelltranszformációk skálázódása a több százezres vagy akár milliós modellméretekre.

Az értekezés fő célkitűzése, hogy olyan újszerű, keresés alapú módszereket dolgozzon ki a model- lvezérelt fejlesztés számára, amelyekkel: (i) hatékonyan lehet kezelni a tervezési tér felderítési prob- lémákban megjelenő komplex strukturális kényszereket és (ii) képesek több százezres vagy akár mil- liós gráf modelleken hatékonyan modelltranszformációt végrehajtani.

Kidolgoztam egy keretrendszert a különböző mintaillesztési műveletek egységes kezelésére, amely egy általános célú keresési-gráfot definiál a lokális keresésen alapuló megközelítések optimal- izálására. E keretrendszerre építve továbbá kidolgoztam egy hibrid gráfmintaillesztési algoritmust, amely képes a lokális keresésen alapuló és inkrementális megközelítések együttes alkalmazására.

Kidolgoztam egy modellvezérlet tervezési tér felderítési módszert, amelynek keretében kiter- jesztettem a kényszerkielégítési problémák definícióját úgy, hogy gráfmintákat vezettem be a struk- turális (elsőrendű logikai) kényszerek definiálására és gráftranszformációs szabályokkal specifikáltam a lehetséges címkézési műveleteket. Ennek előnye, hogy az egyszerű változó címkézéssel szemben az állapotot reprezentáló gráf modellt a dedikált gráftranszformációs szabályok módosítják ezzel érve el az állapotváltozásokat.

Az értekezés eredményeinek gyakorlati alkalmazására az Európai Unió által finanszírozott, DI- ANA kutatási program keretében megterveztem és megvalósítottam egy komplett modellvezérelt fejlesztési paradigmára épülő keretrendszert, ami képes az ARINC 653-as platformhoz konfigurá- ciós leírók szisztematikus tervezésére. Ennek a munkának a keretében a saját kutatásaim az alábbi témákra koncentrálódtak:(i) egy MDE alapú fejlesztési folyamat kidolgozása specifikusan ARINC 653-as konfigurációs leírók tervezésére a DO-178B szabvánnyal konform módon, (ii) modell-alapú hi- badetektáló és lokalizáló módszerek adaptálása és kidolgozása, és (iii) a tanúsítványozásnak megfelelő nyomonkövethetőség biztosítása a magas szintű modellekből kiindulva a származtatott konfigurációs leírókig az egész fejlesztési folyamaton keresztül.

(7)

v

Acknowledgements

I wish to express my gratitude, first and foremost, to my supervisor, Dr. Dániel Varró. Without his continuous support, ideas, enormous patience and valuable insight over the past seven years years, I would have never succeeded.

I am also thankful to my colleagues in the Fault Tolerant Systems and Research Group, especially Prof. Dr. András Pataricza and Dr. István Majzik for their trust, friendly advices and support for my research. I am also very grateful to my close colleagues who cooperated in the development of the VIATRA2 and EMF-IncQuery projects, namely Dr. István Ráth, Gábor Bergmann, Ábel Hegedüs, Zoltán Ujhelyi, Zoltán Balogh, András Ökrös and Dr. Gergely Varró for their kind support and productive collaborative research work, and all the fun we have together over these years.

Additionally, many thanks goes to research associates Máté Kovács, Dr. Balázs Polgár, Dr. András Balogh, Péter Bokor, Benedek Izsó, András Vörös, Zoltán Micskei, Zoltán Szatmári, András Kövi, Imre Kocsis, László Gönczy, Áron Sisak, István Szombath, János Oláh, Gergely Paljak, Dániel Tóth and my former MSc student Dénes Monostori. Moreover, I wish to thank all the project partners I worked together as they provided me with many good ideas and problems to work on, namely Tobias Schoofs, Eric Jenn, Ivo Viglietti, Klaas Wiegmink, Marc Richard-Foy, Damien Carbonne, Dr. Christian Engel, Zoltán Matisa Gábor Gregus, Rodrigo Rizzi Starr, Andrea Barp, Márcio Bento Viventini, José Ricardo Parizi Negrão and all the others for their suggestions, ideas, long discussions and hard work that formed my thesis work.

The current work was partially supported by the Hungarian CERTIMOT (ERC_HU-09-01-2010- 0003) project, the European Union DIANA (AERO1-030985), SecureChange (ICT-FET-231101) and SENSORIA (IST-3-016004) research projects and a collaborative project with Embraer. Additionally, this work is connected to the scientific program of the "Development of quality-oriented and coop- erative R+D+I strategy and functional model at BME" project. Finally, the thesis is also supported by the New Hungary Development Plan (Project ID: TÁMOP-4.2.1/B-09/1/KMR-2010-0002).

Finally, I get to those people for acknowledgement who did the most to establish a stable background for me, and gave encouragement and support and did not let me to surrender even if it seemed very far to finish my thesis: my parents Zsuzsanna and László, my brother Bálint and finally, Linda.

(8)

(9)

-

1

-

Introduction

1.1 Model-Driven Engineering

Models are prime artifacts of engineering. In system development, they have played an important role as a way to capture real world notions as well as abstract constructs. In fact, system architects have been using models and modeling techniques long before model-driven engineering emerged as a trend, e.g. in the form of entity-relationship diagrams, graph-like data structures, abstract syntax trees etc. However, the term Model-Driven Engineering (MDE) [BCW12] implies thatmodels play a central rolethat encompasses the entire system development lifecycle, starting from requirement analysis to system design, to implementation, to verification, maintenance and even documentation or certification.

Model-driven engineering aims to increase the efficiency and productivity of the system development process by introducing precise engineering practices based on modeling techniques, automated code generation and precise model refinement. It is based on the paradigm that the developer should workfrom the beginning of the development with high abstraction level models and through well- defined steps the complete process should be automated to the highest possible degree using various MDE techniques.

By this approach, design intelligence is applied to capture all relevant information in the form of abstract models. These models can be used fordocumentationpurposes to store well-structured information about the system-under-design. Models can also be used for early validation, where important properties of the systems (such as performance, robustness, security, complexity) can be evaluated before actual implementation begins. Moreover, models can also serve as source forgener- ative development, where target design artifacts (source code, configuration tables, test cases, textual documentation, etc.) is (semi-)automatically derived by tools. All of these techniques aim at reducing costs and improving modularity and quality.

1

(14)

2 CHAPTER 1. INTRODUCTION

1.2 Design Space Exploration

In early phases of designing complex systems, models are not sufficiently detailed to serve as an input for automated synthesis tools. Instead, a design space is constituted by multiple models representing different valid design candidates. Design space exploration (DSE) aims atsearching and constructing such candidatesdefined in the design space that satisfy all design constraints.

DSE is a process to quickly obtain feasible, “good enough” solutions which meet all structural and numeric design constraints in order to identify the most suitable design chosen by system architects based on various quality metrics such as performance, cost, power, reliability, etc. Typically, the best solution isflexible in the sense that it provides a trade-off between the optimal solutions with respect to a single quality metrics. Design space exploration is thus a challenging problem in many application areas including the design of critical embedded systems or dynamic reconfiguration of complex IT infrastructures, where MDE techniques have already been quite popular. These problems in an MDE context are frequently addressed as a specific sort of constraint satisfaction problem [Nee01].

Traditionally, most of these constraints and quality attributes were numeric in nature for expressing time, throughput, budget, memory limits, etc. However, the birth of modular software architectures in critical systems (like AUTOSAR [AUT] in the automotive domain or Integrated Modular Avionics (IMA) [RTCd] in the aeronautical domain) introducedcomplex structural constraints, which express connectivity restrictions for the graph-based model of the system under design. In addition, in many practical scenarios (like IT systems management), design space exploration is further complicated by thecontinuous evolution of the system, which imposes further constraints and quality metrics.

1.3 Model Transformation

Model transformation is considered as the backbone of MDE. It aims to carry outautomated trans- lation within and between modeling languagesto propagate information along the complete development process on all abstraction levels. As MDE is becoming a dominant development method in several novel application domains from automotive design to service management, it urges the need for fast execution of general model transformations handling models up to the size of ten millions of elements as only dedicated solutions exit e.g., in the reverse engineering domain [NFB11].

Additionally, as a trend in state-of-the-art model-driven engineering, modeling tools rely on a variety of execution scenarios applied in different application domains such (i) as contract based early validation over models in the safety critical domain [BHCGR09], (ii) as a synchronization technique between modeling languages [RÖV10, GW09], (iii) as an abstract monitoring layer for complex systems [SWWM10] and (iv) as a constraint solving engine for complex structural constraints [SDB10]

in design space exploration problems for embedded system design.

Over the years a large variety of different tool emerged (e.g., Epsilon [RPKP08], ATL [ATL], etc.) using different concepts and techniques. Among those, one of the most popular approach is the declarative rule-based graph transformation paradigm (e.g., VMTS [VS], ATOM3 [dLV02], MOFLON [AKRS06], AGG [Tae00], GROOVE [Ren04a], FUJABA [NNZ00] or Viatra2 [Via].

Graph transformation (GT) provides a declarative language for defining the manipulation of graph models by means of GT rules. A GT rule consists of (i) a left-hand side (LHS), (ii) a right- hand side (RHS) graph. Model manipulations are carried out by replacing a match of the LHS in the model by an image of the RHS. This is performed in two phases. In the performance critical pattern

(15)

1.4. A MOTIVATING APPLICATION DOMAIN 3

matching phase, matches of the LHS are searched in the underlying model. In the updating phase, the selected matching parts are modified based on the difference of LHS and RHS.

Tools based on graph transformation already integrate research results of several decades [Zün96, Dör95, MMLA10, KKS07] for searching matches of LHSs. In the recent years, the need for fast and effective execution of various model transformations defined by graph transformation rules on models ranging in the millions of elements has become a major challenge due to the widespread use of MDE approaches in different application domains.

1.4 A Motivating Application Domain

MDE for safety critical aeronautical systems As MDE is attracting increasing attention in the aeronautical safety-critical system development [CRH], it needs to be adapted to be in-line with the rig- orous DO-178B [RTCe] certification requirements imposed by civil aviation authorities like FAA and EASA. These require (i) V&V activities to be tightly integrated into the dev process, (ii) continuous verification activity from early specification to design and development and (iii) end-to-end traceability through the complete development process [Ste]. Moreover, the revisited DO-178C [RTCf]

certification guidelines has a dedicated subgroup (SWG4) and supplement (DO-333) forModel-Based Development and Verification, which aims to define the specific certification requirements for model- driven engineering approaches based on the already available experience and considerations from DO-178B.

Similar work has already been carried out specifically in the automotive domain and in general for embedded systems:

• The AUTOSAR [AUT] standard explicitly defined model-based development techniques for the semi-automated design of embedded software and hardware [KBFL⁺] for automotive. How- ever, one key difference is that in the automotive domain there is no such strict verification and validation certification process as for the civil avionics systems defined by DO-178B.

• The INDEXYS [IND] project built upon the results of the DECOS [DECb] and GENESYS [GEN]

project within the European ARTEMIS framework specified a general architectural principle for embedded system design based on time-triggered architecture. Additionally, it also envisaged an iterative model-based development process that can be adopted to the needs of its application domain.

Although, many of the envisaged techniques within the project are general in principle and can be easily adapted to other model-driven processes, however, due to its general nature it does not take into account the specific requirements of civil avionics system development such as its conservative design methodology and rigid certification principles.

1.5 Challenges and Contributions

My research has been motivated by the practical challenge to adapt model-driven engineering to safety-critical civil avionics systems. I aimed to tackle the development of configuration artifacts for integrated modular avionics systems using a systematic model-driven development process.

Unfortunately, despite the significant investment of research and development into the application of model-driven techniques for the development of embedded software [KSLB03, Bal, CCF⁺06]

there have been very few methods [KG08] directly aiming configuration development. Lack of techniques in this direction started my research inmodel-driven design space explorationas certain parts

(16)

of the configuration development for civil avionics system required automated techniques that can solve complex structural constraints over the system design already captured by a set of models.

As a prerequisite for applying any advanced MDE based technique for the automated generation of configuration artifacts in the selected avionics domain is the ability to handle huge models in the range of millions of elements. However, at the start of my research ingraph pattern matching(2005) model transformation tools were just beginning to scale up to problem sizes of a few ten thousand or hundred thousand model elements, while complex industrial problems were at least an order of magnitude larger. This hindered their use not only for direct, batch model-to-model and model-to-code transformations but also their future application in different execution scenarios such as my model- driven design space exploration approach or model-based validation techniques like on-the-fly design contract evaluation. These applications do not only require fast model transformation executions but also immediate re-evaluation of model queries in case changes occur in their underlying model.

1.5.1 Challenges

Based on these consideration my research challenges are formulated as follows:

• Challenge 1: How to speed up graph pattern matching to large industrial size problems?

In order to provide acceptable performance in real-world application scenarios, graph transformation tools apply sophisticated pattern matching algorithms. These are mostly based on two conceptually different approaches: (i) local searches driven by search plans (like FU- JABA [NNZ00] or GrGen [JBK10]) and incremental graph pattern matching [JT10, BOR⁺08]

using caching mechanisms to store partial matches.

However, when I investigated existing tools for different implementations [Zün96, GSR05, GBG⁺06, VVF05, Ren04a, Uni, VVS06a] of both local search and incremental pattern matching, I found that in general, (i) local search based approaches provide a good overall runtime performance on all different execution scenarios [27,21] using relatively low amount of memory compared to the underlying model, while (ii) incremental approaches has shown that in many application scenarios 17] – relevant to my other research directions – they lead to orders- of-magnitude increases in speed, for the price of using increased amount of memory especially when caching large fragments of the underlying model.

Unfortunately, several applications and industrial case studies revealed [16] that available memory can be insufficient (e.g., on restricted virtualized desktop environment) for caching match sets in case of the incremental approach. This problem is especially severe in design space exploration, where the traversed design space also needs to be stored in the memory.

• Challenge 2: How to support structural constraint solving in evolutionary design space exploration problems?

Design space exploration problems in an MDE context are mainly tackled as specific sort of constraint satisfaction problem (CSP). However, advanced constraint solvers typically apply certain restrictions for the CSP problem: (i) the domains of variables are required to be (a priori) defined, (ii) the number of variables are also a priori defined and finally, (iii) most approaches disallow the dynamic addition or retraction of constraints [MS00]. Furthermore, mapping graph models obtained in model-driven engineering to variables with finite domain can be a non-trivial task, especially when considering the evolution of models.

(17)

1.5. CHALLENGES AND CONTRIBUTIONS 5

Figure 1.1: Overview on the Challenges and Contributions

As a summary, existing constraint solvers fail to adequately handle flexible and dynamic structural constraints over graph-like models, which is necessitated for evolutionary design space exploration. Additionally, handling graph models directly in model-driven design space exploration problems necessitate both fast (i) graph pattern matching and (ii) manipulation, which emphasizes challenge 1.

• Challenge 3: How to support the systematic configuration design of civil avionics systems?

The ARINC 653 standard [ARIb] has taken a leading role within the aeronautical industry in the development of safety-critical systems based on the Integrated Modular Avionics (IMA) concept. One of the main promises of IMA is saving cost by reducing development, integration and verification and validation effort. In case of ARINC 653 compliant platforms, many deployment and implementation details are defined in configuration tables.

Despite the inherent complexity of avionics systems based on the ARINC 653 platform, current tools supporting configuration design offer very low-level support directly on the XML representation level. Existing tools lack support for (1) capturing the development process for configurations, (2) validating design constraints for configurations on-the-fly and (3) providing traceability between high-level requirements and the configuration tables, which require hand-crafted traceability lists. As a result, finding configuration design flaws early to reduce certification costs is a tedious design task.

1.5.2 Contributions

Figure 1.1 gives an overview on the structure how my different research directions are related to my thesis contributions.

Contribution 1: A general search plan representation for advanced graph pattern constructs. I propose a general framework [4,18] for uniformly representing a large variety of search plan operations in graph pattern matching by expressing them as cost-weighted predicates. As an appropriate ordering of these predicates defines an executable search plan, this approach allows to uniformly

(18)

guide the pattern matching process for advanced graph patterns regardless of how the actual costs to different search plan operations are assigned.

As a result, the different phases of pattern matching (e.g. cost assignment, generation of search plans, execution of search plans etc.) are fully separated and independent, thus they can be adapted to different graph transformation engines and strategies (metamodel-based vs. model-based search plans [VVF05]). Furthermore, new types of predicates can be introduced easily by assigning appropriate costs without altering the algorithms for search plan generation.

Contribution 2: Combining local and incremental graph pattern matching algorithms for hybrid strategies. I propose a hybrid pattern matching approach [16,2], which enables the transformation designer to combine local search based and incremental pattern matching to adapt to memory constraints. My approach is based on the general search plan representation, where incremental pattern matching is introduced as a separate search plan operation. I demonstrate that in certain application scenarios [2] the hybrid approach outperforms the other two approaches and provides a good bal- ance between memory consumption and runtime performance and can support different execution scenarios that are relevant to my other research direction in design space exploration.

However, I notice that selecting the appropriate matching strategy for complex model transformation programs requires a deep understanding of both pattern matching algorithms. Therefore, I examine typical transformation scenarios from the literature [VSV05] [24, 17, 27] and define guidelines [2] for transformation designers to be able to exploit the advantages of the hybrid approach.

Contribution 3: Defining and implementing a graph transformation based constraint solver for structural constraint problems. In my research, I aim to tackle [1]evolutionary design space ex- plorationto flexibly identify the most suitable design meeting complex structural constraints and numeric constraints where the underlying constraints may evolve in time, and the evolution of the best design is also restricted by allowed operations and/or quality metrics.

I propose an extension to the definition of constraint satisfaction problems [1, 15] by using graph patterns to define structural (first-order logic) constraints, and graph transformation rules as labeling operations. Informally, all graph pattern constraints need to be satisfied by the underlying model when searching for a specific goal. However, instead of simple variable substitution, the labeling phase applies graph transformation rules to carry out model manipulations on the underlying graph domain. As an analogy, my approach allows to (i) dynamically add/remove constraints from the problem domain, (ii) modify the domain of the variables during search and (iii) define structural constraints in a more natural way.

I demonstrate that model transformation technology can efficiently contribute to formulate and solve certain constraint satisfaction problems with complex structural constraints and dynamic labeling rules. Additionally, apart from the static problem definitions it can also provide a natural way for handling problems in the models@Runtime domain [11]).

Contribution 4: Model-Driven development of configuration of civil avionics systems. I designed and participated in the development of the DIANA mapping framework [14] for systematically designing standard ARINC 653 configuration tables in the context of the DIANA EU FP6 project [DIA].

The framework is based on a platform independent architectural modeling language (PIADL) [DECa]

that allows integration of industry leading architectural language AADL [SAEb] and system simulation language Matlab Simulink [Mat]. The precise low-level details of a specific configuration for the ARINC 653 platform are captured by a platform specific Integrated Architecture Model (IAM).

(19)

1.6. THE STRUCTURE OF THE THESIS 7

Mapping the PIADL to the IAM is handled by a complex interactive model transformation process that needs to bridge a large abstraction gap where critical design decisions are made by the system architect; thus it cannot be fully automated. Therefore, the mapping process is subdivided into well- defined design steps and precisely defined the contracts, interactions and interfaces of each step. In- dividual design steps are then organized into complex workflow-driven transformation chains, which are closely aligned with the designated development process followed by the airframer or function provider. Finally, configuration tables for the standard ARINC 653 and VxWorks specific Module descriptions are generated based on the IAM models.

Additionally, to support certification, end-to-end traceability links from the PIALD to the generated configuration files are instantiated using both (i) inter-model traceability based on an integration model and (ii) model-to-configuration traceability with XMI files connecting generated configuration elements to their corresponding model representation.

My research in the context of DIANA was focused on three topics: (i) adaptation of MDE techniques for defining a specific development process for ARINC 653 configuration design that is in-line with DO-178B (ii) definition and reuse of model-based validation techniques for early error detection and localization and (iii) implementation of end-to-end traceability from high-level models to generated artifacts through the complete process that conforms to the certification requirements.

As a summary, the relevance of my contributions to model-driven engineering is twofold 1. My first three contributions define two search-based techniques for design automation in

model-driven engineering that can be applied independently of the application domain.

2. While my fourth contribution proposes and adapts MDE based techniques for safety-critical civil avionics configuration development.

1.6 The Structure of the Thesis

The thesis is structured into five parts containing ten chapters that contain overviews and new results, and four appendices complementing the main contributions of the thesis with additional information.

• Part 1: Model-Driven Engineering

– Chapter 2 overviews the foundation of metamodeling and describes our AntWorld running example.

– Chapter 3 introduces the basics of graph transformation based querying and modifica- tions of models.

• Part 2: Advances in Graph Pattern Matching

– Chapter 4 gives an overview on trends and techniques used for graph pattern matching in the model transformation literature.

– Chapter 5 presents the concepts of local search based graph pattern matching based on search graphs and search plan.

– Chapter 6 describes the use of hybrid pattern matching combining local search based and incremental pattern matching techniques through the proposed search graph concept.

(20)

– Chapter 7 concludes the work done in graph pattern matching and gives an overview on related work.

• Part 3: Design Space Exploration

– Chapter 8 proposes a novel constraint satisfaction programming approach directly over graph models, which can be used to solve MDE based design space exploration problems.

Additionally, the chapter gives a comparison with related DSE approaches on different case studies.

• Part 4: Model-Driven Development for Avionics Systems

– Chapter 9 describes preliminaries and concepts to civil aeronautical development and certification with a special focus on integrated modular avionics.

– Chapter 10 presents a model-driven development workflow as realized in the DIANA project for the semi-automated generation of ARINC 653 configuration artifacts.

• Part 5: Conclusions and Appendix

– Chapter 11 concludes the main contributions and parts of this thesis and gives an overview on the different applications of the results and finally, outlines future research directions.

– Appendix A contains the Viatra2 source code of the complete AntWorld case study.

– Appendix B describes the computational complexity analysis of the AntWorld case study with regards to the correlation between its parameters and runtime characteristics.

– Appendix C describes the advantages of the hybrid pattern matching – as implemented in Viatra2 – approach on the object-to-relational database schema model transformation case study.

– Appendix D contains listings of the different XML configuration files automatically derived using the tool-chain developed for the DIANA project.

Notational guide

In order to maintain a consistence appearance of the thesis, the following rules are followed:

• The thesis is mainly written in third person singular. In conclusions after each chapter, I emphasize my own contributions by using first person singular or plural.

• Terms in formal definitionsare printed inboldletters.

• New concepts, informal definitions are typeset initalics.

• Code extracts always appear astypewritten textin listings with grey background.

• For referring totexts in figures, slantedfonts are used.

• References to own publications appear as numbers (e.g., [10]), while citations from the bibliog- raphy are formatted alphanumerically (e.g., [VVF05]).

(21)

Part I

Model-Driven Engineering

9

(22)

(23)

Chapter

2

-

Modeling Preliminaries

In the current chapter, we introduce the basics of modeling languages specification and follow the definitions defined in [Var08] and [R´10]. Throughout this and the following chapters on graph pattern matching we use the AntWorld [RG10] simulation benchmark as our running example. We follow the description of the case study as defined in [RG10].

2.1 Running Example: AntWorld

2.1.1 Motivation of the Case Study

This section will introduce the AntWorld case study, which will serve as the running example for the graph pattern matching related parts of the thesis. This choice was made based on the following considerations:

• It was an official graph-pattern matching performance evaluation case study, proposed at the 2008 Grabats (Graph-Based Tools) conference [Gra08].

• The pattern matching characteristic of the case study [2] is similar to my model-driven design space exploration (see in Chapter 8) and on-the-fly design contract validation (see in Sec- tion 10.6.2) thesis contributions.

It can be summarized as follows: (i) the graph pattern matching tasks are part of an in-place transformation (the source and target models are the same), (ii) graph patterns are medium sized consisting of up to fifteen model elements, (iii) a significant portion of model manipulations are concentrated on a restricted subset of the underlying model and finally, (iv) most of the model is a quasi-inmutable structure (either present in the initial model or created in a later phase but never modified during the complete execution process).

11

(24)

12 CHAPTER 2. MODELING PRELIMINARIES

• Finally, the AntWorld simulation is considered by many as one of the best case study for sheer graph pattern matching performance evaluation as it provides a fine-grain scaling from small to large input models and evades the problem of synthetic input model generation.

2.1.2 Overview of the AntWorld Simulation

The AntWorld case study simulates the life of a simple ant colony. The AntWorld simulation consists of anant hillsitting in the middle of a large area. The ants are moving around searching for food. If anAntfinds food, it brings the food home to its ant hill in order to grow new ants. On its way home, the ant dropspheromonesmarking the path to the food reservoir. If an Ant without food leaves the hill or if a searching ant hits a pheromone mark, the ant follows the pheromone path to the food.

This behavior already results in the well knownant trails.

As a simulation benchmark for model transformation tools the area in which the ants can move is modelled by a grid of nodes, which is constructed in a spider web shape so that the ants can travel back to the ant hill on a straight path. In the center of the grid there is theant hill. The first circle around the ant hill consists of 4 exit fields. In the second circle, each exit field has three child fields.

In the next circle, the 4 fields on the main axis have three child fields while the normal fields have just one child field. This scheme creates a quite regular grid where each field has a quite straight path to the hill in the center of the grid. An example ant hill with its surrounding is depicted in Figure 2.2.

The rules of the simulation are divided into two parts:area managementandant movement.

2.1.3 Ant Movement

The AntWorld simulation works in rounds. Within each round, each ant does one movement and it depends on the following rules:

• If the ant has no food and it ison a field with food, it takes one piece of food and enters the food carrying mode. It may still move within the current round.

• If the ant carries food, it follows the links towards theinner circle. Thus, the ant moves towards the ant hill by one circle. During its way home, on each visited grid node – including thefood node – the ant drops 1024 parts ofpheromones. This guides other ants to the food place. Note that if an ant drops new pheromones on an already marked grid node, this new pheromone parts are added to the already existing parts.

• If ant with food ison the hill node, it drops the food and enters the search mode. It may leave the hill within the same round.

• An ant without food is insearch mode. In search mode, the ant checks the neighbor node(s) of the next outer circle for pheromones. If there are neighbor nodes on the next outer circle with more than 9 parts of pheromones, the ant chooses one of these fields, randomly.

• If the ant is in search mode and no outer neighbor has sufficient pheromones, the ant moves to any of its neighbor fields based on a fair random choice. However, an ant without food shall not enter the ant hill.

2.1.4 Area Management

• Initially, the area grid shall consist only of the hill and the first two circles. In addition, the hill shall contain 8 ants and there shall be no food on the gird.

(25)

2.2. OVERVIEW OF MODELS AND METAMODELS 13

• Whenever an antenters the currently out most circle(i.e. the border of the yet known area), a new circle of nodes shall be created. During the creation of this next circle, every 10th node shall carry 100 parts of food. If a circle has e.g. 28 nodes, node 10 and node 20 of that circle shall have food. Thus, this circle would need just 2 more nodes to create a third food place.

Therefore, across circles, every 10th node becomes a food place.

• After each round, thepheromones shall evaporate. This is needed in order to erase an old ant trail once the food has drained. Thus, after each round, on each grid node, the number of pheromones shall be multiplied by 0.95. In case of a fraction, the number shall be rounded to the next smaller natural number. Note that using the factor 0.95 and 1024 start pheromones per drop, the number of pheromones on a grid node drop below 10 roughly within 100 rounds.

Note that food places with a distance of more than 50 circles need the collaboration of multiple ants that pick up the ant trail and refresh it, continuously.

• After each round, thehillshallconsume the food broughtto it and it shallcreate one new antper delivered food part. These new ants spread out in the next round.

Goal of the Simulation

The goal of the simulation is to simulate the largest ant colony possible demonstrating the pattern matching capability of the underlying model transformation tool as the size of the model describing the actual state of the simulation is considerably smaller compared to the number of simulation rules needed to be executed.

2.2 Overview of Models and Metamodels

Metamodeling is a fundamental part of model transformation design as it allows the structural definition of modeling languages. The abstract syntax of a modeling language is defined by themetamodel.

Metamodels are expressed using a metamodeling language that itself is a modeling language. Nodes of the metamodels are called entities and essentially they represent basic concepts of a modeling domain. Attributesmay be defined for entities to represent content information using simple types (e.g., integer, double, string)Inheritancemay be defined between entities, which means that the in- herited entity has all the attributes and properties of its parent and may contain additional ones.

Relationsdefine connections between entities and define a relationship between the entities. They may havemultiplicityconstraints attached to both end of a relation, which restricts the number of model entities in the instance model.

Theinstance model is a graph that describes concrete systems defined in a modeling language.

Its nodes and edges are called objects and links, respectively. The instance model is a well-formed instance of the metamodel, which means the fulfillment of a set of criteria, described in Def. 3.

Example 1 The metamodelof the AntWorld case study used in our experiments is shown in Fig- ure 2.1.

The entityField represents a field of AntWorld (grid node in the original specification, but we use the term field to avoid confusion); CornerField entities are fields that are located on the axis, and theAntHill is the central field. Fields are connected by paths. Each circular path formed by circlePath relations connects the set of fields that were created in a single round. Except for the anthill, each field has a single outgoingreturnPathrelation pointing towards a field in the previous circle; most fields have a single incomingreturnPath as well, but corner fields have three, and the

(26)

Figure 2.1: Metamodel of the AntWorld case study

anthill has four. Theboundary relation is used to ease the search for the actual boundary fields of the grid by pointing them directly from the ant hill. Fields may be associated with an integer number offooditems orpheromonesassociated with them. Finally, a field may contain two kinds of ants:

SearcherAntentities represent ants that do not carry food but are in search of a food bundle, while CarrierAntentities represent ants that carry a food item, modeled by theFoodBiteentity, and are on their way to return to the anthill.

Example 2 Figure 2.2 shows an example area of the ant colony, where the ants have not yet found any food, thus none of the fields has pheromone and all ants areSearcherAnts. The example instance model shows the state of the simulation in the end of a round. However, as ants have reached the boundary of the “known” world the round finishes with the generation of the next circle of the grid according to the defined rules (see in Section 2.1.4).

2.3 Modeling Environments

There is already a large set of metamodeling environments used by both the research community and the industry. In the current section, we give a brief overview on the most widely accepted approaches.

2.3.1 MOF - Meta Object Facility

TheMeta Object Facilityis astandardof the Object Management Group (OMG). It was designed to be the basis for all UML and related languages (e.g., CWM, SysML) and serves as a platform-independent metamodeling framework and a general mapping platform between various languages. Its current version is called MOF 2 version 2.4.1 [Obj11].

MOF has a core sub-language called Essential MOF (EMOF) that defines the minimal number of concepts required for the building of metamodels. EMOF has been inspired by the Eclipse Model- ing Framework an open source project aimed the development of a metamodeling framework for

(27)

2.3. MODELING ENVIRONMENTS 15

Figure 2.2: Example instance model for the AntWorld case study

the Eclipse tool platform. However, only a subset of the MOF language has been used during the implementation of the final ECore modeling core that proved to be sufficient for practical modeling scenarios (see in Section 2.3.2).

Figure 2.3 illustrates the main concepts of EMOF without many auxiliary elements. The central element is theClassthat can haveProperties. Properties can be typed by primitive types defining a simple value slot resulting in an attribute, while inter-class relations are defined by uni-directional Associations, with the ability to define multiplicity constraints on their both end and paired using the opposite relation. Additionally,Operationscan be defined for classes to capture domain specific func- tions. One of its main drawback is it lacks formal semantics and thus different communities interpret certain part of the standard in different way, resulting in lack of compatibility and reusability.

2.3.2 Ecore - Eclipse Modeling Framework

The Ecore metamodeling language is the hearth of theEclipse Modeling Framework[Thea] (EMF). It has been developed to provide a method for metamodel definition that directly supports the implementation of models using conventional programming languages. Introducing the Ecore separately resulted in that the language became thede factometamodeling standard of the industry definition and several other standards [SAEb] and domain specific languages [Joh09] are defined using this formalism. As mentioned earlier in Section 2.3.1 the Ecore language is almost identical to the EMOF language. The core concepts of the Ecore language are depicted in Figure 2.4.

EClassmodels classes (nodes) themselves. Classes are identified by their name and can contain a number of attributes and references. In Ecore multiple inheritance is allowed. EAttribute models

(28)

Figure 2.3: MOF Core Metamodel

Figure 2.4: The Ecore kernel

attributes that contain the data elements of an EClass. They are identified by their name, and they have a data type. EDataTypeis used to represent simple data types that are stored as atomic values (their internal structure is not modeled). They are also identified by their names.EReferenceis used in modeling associations between EClasses. It can be constrained by multiplicity constraints. It is also possible to mark a reference as containment that represents composition relation between elements.

Bidirectional association are modeled as two EReference instances that are mutually connected via their opposite references.

These four elements define the kernel of the Ecore language, however, it contains many auxiliary classes for the organization of the models.

Additionally, EMF supports a wide range of functionality for easing the integration of the defined models to any Java program. This includes automated Java representation generation from Ecore, reflective model manipulation, notification mechanism, dynamic model creation, XMI import and many more. All these add-ons and binary compatibility made EMF one of the most widely accepted and used modeling environment by the industry. Its only drawback is again the lack of formal

(29)

2.4. CONCEPTS OF METAMODELS AND INSTANCE MODELS 17

semantics and poor specification, which in many cases results in “specification by implementation”.

2.3.3 VPM - Visual and Precise Metamodeling

Visual and precise meta-modeling framework (VPM) (the built-in metamodeling framework of Via- tra2) is a meta-modeling language, which is capable of defining models and meta-models in a single model space. The VPM framework has amathematically precise notation, which eases model check- ing and validation. A VPM model has a graph-based structure facilitating the design and maintenance with visual tools. VPM maintains explicit instanceOf relationship supporting the storage of meta-models and models in the same model space resulting in easy multi-level metamodeling and multi-domain integration. Additionally, it allows dynamic typing of entities.

Figure 2.5: The VPM language

The VPM language consists of two basic elements: theEntity(a generalization of MOF package, class, or object) and theRelation(a generalization of MOF association end, attribute, link end, slot).

Both element have a common abstract supertype calledModelthat defines thenameString attribute that can be used to be the identifier of the model elements. Entities represent basic concepts of a (modeling) domain, whilerelationsrepresent the relationships between other model elements. Fur- thermore, entities may also have an associated Stringvaluethat contains application-specific data.

The are three special relationships defined betweenModels: (i) thesupertypeOfrelation represents generalization relationship between Models, (ii)theinstanceOfrelations expresses instantiation be- tweenModelelements and explicitly stored allowing direct manipulation, and (iii) theownerrelation that arranges the model elements into a strict tree containment hierarchy. Its main advantage is that it helps human readers to understand the model and can be used to reduce the scope of queries.

VPM has two advantage over MOF and Ecore: (i) its precise formal semantics that further analysis over the defined model and (ii) its ability through the direct instanceOf relation of multiple typing and thus multi-level metamodeling. However, as one of its main drawback VPM is far more verbose compared to MOF and Ecore and thus require far more elements to define the same domain.

2.4 Concepts of Metamodels and Instance Models

A description of the most important formal concepts of modeling and metamodeling is presented following the notation of [Var08] and [R´10].

(30)

Definition 1 A directed attributed graph (denoted by G =

(V_G, E_G, src_G, trg_G, A_G, attr_G, value_G) is a 7-tuple, where V_G and E_G denote nodes and edges of the graph, respectively. FunctionssrcG : EG →VGandtrgG : EG → VGmap edges to their source and target node, respectively.A_Gdenotes to the attributes of the nodes with a name and type pair, where types are considered simple atomic types (for simplicity in our case: string, integer or double),attrG:VG → AG is a function that map nodes to their attributes and finally, thevalue function denotes the value of an attribute of a given node, formally,value_G : V_G×A_G→value.

Although, to ease the understating this is a simplified representation of attribute graphs it is still suitable for demonstrating the pattern matching results of this thesis.

Definition 2 A metamodel M M = (M, supertypeOf, multiplicity)) is a triple, defined by a directed attributed graph M, the supertypeOf : M × M → Boolean predicate denoting supertyping relationship and the multiplicity : EM M → one-to-one, one-to-many, many-to-one, many-to-many function denoting the multiplicity type of the relations, where

• VM M andEM Mdenote nodes and edges of the metamodel.

• AnentityEis a node of the metamodel, formally,E∈V_{M M}.

• ArelationRis an edge of the metamodel, formallyR∈EM M

• Inheritance (generalization) (denoted as in UML by C_s ^ C_t) is represented by the supertypeOf predicate, whereE_super is a supertype ofE_subiffsupertypeOf(E_super, E_sub) holds and there is no other entityEx between Esuper andEsub in the inheritance hierarchy, formally,@E_x :supertypeOf(E_super, E_x)∧supertypeOf(E_x, E_sub). Note that multiple inheritance is allowed.

• Inheritance is transitive along the supertypeOf relationship, ∀Sub, S₁, S2 ∈ M M : supertypeOf(Sub, S₁)∧supertypeOf(S₁, S₂)⇒supertypeOf(Sub, S₂).

• Relations have multiplicity constraints, which impose a restriction on the instance model.

Formally,∀R∈E_{M M} :multiplicity(R). For detailed definition see in Def. 3

• Attribute values are not allowed in metamodels, formally, @E ∈ VM M,@Attr ∈ AM M : attrM M(E) =Attr∧ ∃value_{M M}(E, Attr)

Definition 3 Given a metamodelM M, a (well-formed)instance modelM of the metamodelM M is a directed attributed graph together with adirect type predicate instanceOf : M ×M M → boolean, which denotes instantiation relationship betweenM andM M, according to the following rules

• All element of the instance model (objects) are mapped to metamodel entities, formally,

∀object∈V_M,∃T ype∈V_{M M} :instanceOf(object, T ype).

• All objects can only have attributes that are defined in type metamodel entity, formally,∀obj∈ VM,∀att ∈ AM,∃E ∈ VM M,∃AT T ∈ AM M : attrM(obj) = att∧attrM M(E, AT T) = att∧instanceOf(obj, E).

(31)

2.5. SUMMARY 19

• All model edges (links) are mapped to relations, formally, ∀link ∈ E_M,∃T ype ∈ E_{M M} : instanceOf(link, T ype). Additionally, for all links it holds that theirsource end, the object is an instance ofT ype’s source entity, and itstarget end, the object is an instance ofT ype’s target entity. Formally,∀T ype, instanceOf(link, T ype) :instanceOf(src(link), src(T ype)∧ instanceOf(trg(link), trg(T ype)).

• TheinstanceOf relationship istransitive along supertyping:

∀Inst ∈ M ∧ ∀T ype, Super ∈ M M : instanceOf(Inst, T ype) ∧ supertypeOf(T ype, Super)⇒instanceOf(Inst, Super).

• Multiplicity criteria

– one-to-one:Two relations of the same type with the same source have to have the same target, formally, ∀T ype ∈ E_{M M},∀link₁, link₂ ∈ E_M : instanceOf(link₁, T ype)∧ instanceOf(link₂, T ype) ∧ src_M(link₁) = src_M(link₂) ⇔ trg_M(link₁) = trgM(link2)

– one-to-many : Two relations of the same type having the same target cannot come from different sources, formally, ∀T ype ∈ E_{M M},∀link₁, link₂ ∈ E_M : instanceOf(link₁, T ype)∧instance(link₂, T ype)∧trg_M(link₁) = trg_M(link₂) ⇒ srcM(link1) =srcM(link2)

– many-to-one : Two relations of the same type coming from the same source cannot go to different targets, formally, ∀T ype ∈ E_{M M},∀link₁, link₂ ∈ E_M : instanceOf(link1, T ype)∧instance(link2, T ype)∧srcM(link1) = srcM(link2) ⇒ trgM(link1) =trgM(link2)

– many-to-many:There is no restrictions on the multiplicity of the relation.

• No parallel edges are allowed, meaning that there cannot be any pair of links of the same type leading between the same pair of objects in a given direction. Formally,∀link₁, link₂ ∈ E_M, T ype ∈ E_{M M} : src_M(link₁) = src_M(link₂) ∧ trg_M(link₁) = trg_M(link₂) ∧ instanceOf(link1, T ype) =instanceOf(link2, T ype)⇒link1 =link2.

2.5 Summary

In the current chapter, the basis of modeling language specification has been overviewed by introducing metamodels for describing modeling domains and instance models for specifying concrete systems. These concepts have been formalized based on the notations of [Var08] and have been ex- emplified by using the AntWorld simulation case study as our running example. Finally, an overview on three widely accepted modeling environments has been given.

(32)

(33)

Chapter

3

-

Model Transformation

Model transformation is the backbone of model-driven engineering. It eases the automated manipulation of models to propagate information along the complete development process on all abstraction levels from the high-level design models down to the generated source code.

There are already a large set [CH03] of different dedicated model transformation tools: Ep- silon [RPKP08], VMTS [VS], ATOM3 [dLV02], ATL [ATL], AGG [Tae00], GROOVE [Ren04a] or FUJABA [NNZ00] just to name a few examples. All of these tools solve a common problem: the ease specification and fast execution of model transformation through declarative specification and optimized execution architectures. Many of them are based on the formal concept of graph transformation [Roz97].

In the current section, we present the basics of graph transformation a declarative formalism to define model transformation. Its concepts are presented using our AntWorld running example.

3.1 Modeling the AntWorld case study

The current chapter introduces our model transformation based simulation program for the AntWorld case.

As my research on graph pattern matching has been carried out in the context of our Viatra2 model transformation framework [Via], in Section 3.1.1, we will introduce the basics of the Viatra2 transformation language in order to become familiar with its notation and definitions [BV06, Var04].

This eases the understanding of our solution for the AntWorld case study as it was implemented in Viatra2.

3.1.1 The Viatra2 Transformation Language

In order to understand the concepts of Viatra2 graph transformation environment, we give a brief overview on the transformation language of the framework.

21

(34)

22 CHAPTER 3. MODEL TRANSFORMATION

The transformation language of Viatra2 (Viatra Textual Command Language –VTCL [VB07]) consists of several constructs that together form an expressive language for developing both model to model transformations and code generators. Graph patterns (GP) define constraints and conditions on models, graph transformation (GT) [EEKR99] rules support the definition of elementary model manipulations, while abstract state machine (ASM) [BS03] rules can be used for the description of control structures.

Readers familiar with graph patterns and transformation rules may directly check the GT rules and graph patterns defined for the AntWorld case study as depicted in Figure 3.1.

3.1.1.1 Graph patterns

Graph patternsrepresent conditions (or constraints) that have to be fulfilled by a part of the model space in order to execute some manipulation steps on the model. The basic pattern body contains model element and relationship definitions.

In VTCL, patterns may call other patterns using the find keyword. This feature enables the reuse of existing patterns as a part of a new (more complex) one. The semantics of this reference is similar to that of Prolog clauses: the caller pattern can be fulfilled only if their local constructs can be matched, and if the called (or referenced) pattern is also fulfilled. For complex pattern specification the VTCL language allows to definealternate(OR)pattern bodiesfor a pattern, with a meaning that the pattern is fulfilled if at least one of its bodies is fulfilled. Finally, the signature of a graph pattern is calledpattern head, which consist of its name and its input/output parameters.

Anegative application condition(NAC, defined by a negative subpattern following the negkey- word) prescribes contextual conditions for the original pattern which are forbidden in order to find a successful match. Negative conditions can be embedded into each other in an arbitrary depth (e.g. negations of negations), where the expressiveness of such patterns converges to first order logic [Ren04b].

Example 3 The VTCL definition of the anyNeighborButHome graph pattern (see in Figure 3.3) is shown in Listing 3.1.

pattern home ( Field2 ) = { AntHill ( Field2 );}

pattern

anyNeighborButHome ( Field1 , Field2 ) = {field ( Field1 );

field ( Field2 );

field . path (P, Field1 , Field2 );

neg find home ( Field2 );

} or {

field ( Field1 );

field ( Field2 );

field . path (P, Field2 , Field1 );

neg find home ( Field2 );

}

Listing 3.1: Viatra2 source code for the anyNeighborButHome pattern

Entitiesof a pattern body are defined using their type with the pattern node (variable) as their parameter. For example,field(Field1)represents that theField1node has to be matched to afield typed object. Relationsare defined as s triplet, where the first parameter is the pattern relation, the second defines the source of the relation while the third the target. For example, thefield.path(P,

(35)

3.1. MODELING THE ANTWORLD CASE STUDY 23

Field1, Field2)relation defines that thePpattern relation has to be matched to a link in the instance model that comes from the object that is matched to theField1pattern node and goes to an object that is matched toField2and finally, this relation has to havepathtype.

As already mentioned, the pattern uses alternate pattern bodies to represent moving in the for- ward or reverse direction of a path relation betweenField1and Field2. It also reuses the home pattern (called by theneg findconstruct) as its NAC to put the not AntHilltype constraint on Field2. The pattern head is the signature of the pattern itself: anyNeighborButHome(Field1, Field2).

3.1.1.2 Graph transformation rules

In VTCL, graph transformation rules may be specified by using aprecondition (LHS) pattern de- termining the applicability of the rule, and a postcondition pattern (RHS) which declaratively specifies the result model after rule application.

Elements that are present only in (the image of) the LHS are deleted, elements that are present only in the RHS are created, and other model elements remain unchanged. Further actions can be initiated by calling any ASM instructions within theactionpart of a GT rule, e.g. to report debug information or to generate code.

Example 4 For instance, the GT rule returndefines how food carrying ants take a step towards the hill, as shown in Listing 3.2 (graphical representation in Figure 3.2). The mechanism of leaving pheromones is omitted here for the sake of brevity.

Tha GT rule uses the precondition graph pattern called lhs to define that a Ant of type CarrierAntis standing on anOuterNeighbor Fieldelement connected through ahasCarrierAnt relation and this OuterNeighbor has a directed RP returnPath relation to the InnerNeighbor Field.

In itspostconditioncalledrhsit defines that theoldHArelation needs to be deleted ,thus it is not present in the pattern. On the other hand thenewHArelation between theOuterNeighborand theAntneeds to be created and thus it is present in therhspattern.

// Ant returns along returnpath . gtrule return (in Ant ) =

{precondition pattern lhs (Ant ,

InnerNeighbor , OuterNeighbor , Loc ) = { field ( InnerNeighbor );

field ( OuterNeighbor );

field . returnPath (RP , OuterNeighbor , InnerNeighbor );

carrierAnt ( Ant );

carrierAnt . hasCarrierAnt (oldHA ,Ant , OuterNeighbor ) // Deletes OldHA and creates NewHA}

postcondition pattern rhs (Ant ,

InnerNeighbor , OuterNeighbor , newHA ) = { field ( InnerNeighbor );

field ( OuterNeighbor );

field . returnPath (RP , OuterNeighbor , InnerNeighbor );

carrierAnt ( Ant );

carrierAnt . hasCarrierAnt ( NewLoc ,Ant , InnerNeighbor );

}}

Listing 3.2: VIATRA source code for graph transformation rules

Search-Based Techniques in Model-Driven Engineering

Budapest University of Technology and Economics Department of Measurement and Information Systems