methods for improving and applying graph rewriting-based model transformations m³dszerek

Budapest University of Technology and EconomicsDepartment of Automation and Applied Informatics

Doctor of Philosophy Dissertation

Methods for Improving and Applying GraphRewriting-Based Model Transformations

Módszerek Gráfújraírás-AlapúModelltranszformációk Fejlesztéséhez és

Alkalmazásához

by

Péter Fehér

Advisor:László Lengyel Ph.D.

Budapest, 2017.

AbstractIn software engineering, the quality of the products can be measured with such important, non-functional aspects like reliability, reusability, transparency. Therefore, methods offering these qualitiesare getting more and more popular. The help of model-based solutions offers the opportunity to use themost appropriate formalism for representing a problem at the most appropriate level of abstraction.

This thesis presents how the abstraction level in the process of elaborating Simulink models canbe increased, how to detect exact and inexact patterns in graphs with millions of elements usingthe MapReduce framework, and how to increase the efficiency of the VF2 algorithm with furtherheuristics.

The first contribution increases the level of abstraction of the model elaborating process inSimulink, a tool widely and frequently used in the industry. Throughout the model elaboration,such processing steps, like flattening the virtual subsystems, generating Sorted List in order to createthe Execution List, propagating data types are implemented in the Simulink code base. By providinga solution for these problems at a higher level of abstraction, the advantageous properties of thedomain-specific modeling can be utilized. The contribution is based on the approach using modeltransformations. The solution possesses all the advantageous characteristics of the model transforma-tion, it is reusable, transparent, and platform independent. Its declarative sense also allows the studyof potential performance improvements that derive from applying the transformations in differentorders.

As the modeled systems become larger, finding different patterns in the structures representing themodels requires more resources. In the second contribution, new approaches are presented that exploitthe computational power and storage space offered by the cloud providers. The algorithms are basedon the MapReduce framework and find all subgraphs that are isomorphic to a specific target graph.These approaches are capable of handling source graphs with millions of edges and vertices. Since theprovided solutions are based on the MapReduce technique, the space and memory requirements ofthe algorithms are critical. Therefore, the algorithms are analyzed and compared to each other basedon these aspects.

There are situations, where the patterns we are looking for are not completely known, or someaspects of it are incorrect. In these cases, the inexact pattern matching is an option to consider. Thethird contribution provides a cloud-based solution for finding inexact patterns in large graphs. In orderto define the patterns, there is a need for a pattern specifying language, which is also presented. As amodern language, it must be expressive enough to be able to specify possible matches in a concise way.Furthermore, in order to support the traditional algorithms finding graph-subgraph isomorphisms,optimization techniques are also provided to increase the performance of the VF2 algorithm.

For each contribution, the presented experimental results prove the applicability of the theoret-ical results. The model transformations provided in the first contribution are realized in the VisualModeling and Transformation System, and are applied on Simulink models. The algorithms presentedin the second and third contributions are executed on different RMAT graphs, which are stored in acloud containing a MapReduce cluster of 8 nodes and hosted in Windows Azure.

i

ÖsszefoglalóA szoftverfejlesztés során az elkészült termék minősége olyan nem funkcionális tulajdonságok vizs-gálatával mérhető, mint a megbízhatóság, újrafelhasználhatóság, transzparencia. Ezért egyre népsze-rűbbek az olyan metódusok, melyek ezeket a kvalitásokat biztosítani tudják. A modellalapú megoldá-sok segítségével lehetőség nyílik a problémát a legalkalmasabb formalizmussal a legalkalmasabb absz-trakciós szinten kezelni.

A disszertáció során bemutatásra kerül, miként lehet támogatni az absztraciós szint emelésétSimulink modellek feldolgozása során, hogyan lehet MapReduce eszközökkel egzakt és nem egzaktmintákat keresni milliós elemszámú gráfokban, illetve milyen további heurisztikákkal lehet növelni aVF2 algoritmus hatékonyságát.

A disszertáció első része a Simulink, egy, az iparban gyakran és széleskörűen használt eszközmodellfeldolgozási folyamatának absztrakciós szintjének növelésével foglalkozik. A modellfeldolgozásolyan lépései, mint a virtuális alrendszerek kilapítása, az Exection Listhez vezető Sorted List gene-rálása, vagy az adattípusok propagálása jelenleg mind a Simulink kódbázisában vannak implemen-tálva. Egy olyan megoldás segítségével, mellyel ezek a lépések magasabb absztrakciós szintre emel-hetők, a szakterület-specifikus modellezés előnyös tulajdonságai is elérhetővé válnak. A bemutatottmegoldás a modelltranszformációkon alapszik, ezáltal azoknak minden előnyös tulajdonságával ren-delkezik, újrafelhasználható, transzparens, platform-független. A megoldás deklaratív volta lehetővéteszi a transzformációk különböző sorrendbeli végrehajtásából adódó lehetséges teljesítménynövekedéstanulmányozását.

Ahogy a rendszerek egyre nagyobbak lesznek, egyre több erőforrást igényel a különböző mintákdetektálása. A disszertáció második részében olyan új megközelítések kerülnek bemutatásra, melyekkihasználják a felhő szolgáltatók által nyújtott számítási kapacitást, illetve tárhelyet. Az algoritmusoka MapReduce keretrendszerre épülnek, és minden olyan részgráfot megtalálnak, amely izomorf azadott mintával. Ezek a megoldások képesek az olyan nagy gráfokban is keresni, melyek több millió éllelés csomóponttal rendelkeznek. Mivel a bemutatott megoldások a MapReduce technikát használják,ezért az algoritmusok tárhely- és memóriaszükséglete kritikus. Ennek következtében az algoritmusokatezen szempontok alapján elemzem, és hasonlítom össze.

Vannak olyan helyzetek, amikor a keresett minta nem teljesen ismert, vagy bizonyos aspektu-sai hibásak. Ezekben az esetekben érdemes megfontolni a nem egzakt mintakeresés lehetőségét. Adisszertáció harmadik része egy olyan felhő alapú megoldást mutat be, mely nagyméretű gráfokbankeres nem egzakt mintákat. Annak érdekében, hogy lehetőség legyen ezeket a mintákat definiálni,bemutatásra került egy új nyelv is. Mint minden modern nyelv esetében, itt is fontos, hogy a speci-fikálandó mintákat tömören meg lehessen fogalmazni. Továbbá, a tradicionális izomorf részgráf keresőalgoritmusok támogatása végett, olyan optimalizációs technikák is bemutatásra kerülnek, melyek aVF2 algoritmus teljesítményét növelik.

Az elméleti eredmények alkalmazhatóságát esettanulmányokkal illusztráltam. Az első tézisbenbemutatott modelltranszformációkat a Visual Modeling and Transformation Systemben valósítottammeg, és így alkalmaztam Simulink modelleken. A második és harmadik tézisben bemutatott algorit-musokat különböző RMAT gráfokon futtattam, melyeket egy, a Windows Azure-ban létrehozott, 8csomóponttal rendelkező MapReduce klaszterben tároltam.

ii

DedicationThe content of this thesis is a product of the author’s original work except where explicitly statedotherwise.

NyilatkozatAlulírott Fehér Péter kijelentem, hogy ezt a doktori értekezést magam készítettem, és abban csak amegadott 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, 2017. március

(Fehér Péter)

iii

Contents

Contents iv

List of Figures vi

List of Tables ix

Acknowledgements xi

1 Introduction 11.1 Simulink Model Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Pattern Matching in Large Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 VMTS, The Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Communication between Simulink R© and VMTS . . . . . . . . . . . . . . . . . . . . . . 62.3 The MapReduce Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 The Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Sample Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Increasing the Abstraction Level of the Simulink Model Elaboration ProcessUsing Model Transformations 103.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Flattening Simulink R© Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 The TransFlattener Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 The TransFlattener Transformation . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Generating the Sorted List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.1 The Trans_SL Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.2 The Trans_SL Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Propagating Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4.1 The Trans_TypeProp Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 383.4.2 The Trans_TypeProp Transformation . . . . . . . . . . . . . . . . . . . . . 42

3.5 Flattened Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.5.1 The FlattenedScheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . 483.5.2 The FlattenedScheduling Transformation . . . . . . . . . . . . . . . . . . . 48

iv

Contents

3.6 Application of Custom Algorithms and Converting Data Types . . . . . . . . . . . . . 533.7 Examining the Efficiency of the Application Order . . . . . . . . . . . . . . . . . . . . 543.8 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.8.1 Flattening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8.2 Sorted List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.8.3 Data Type Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.8.4 Execution Order of Different Transformations . . . . . . . . . . . . . . . . . . . 62

3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4 Exact Pattern Matching with MapReduce 664.1 The MRSI Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1.1 Description of the Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . 674.1.2 Denotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.1.3 The MRSIH Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.1.4 The MRSIS Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Analysis of the MRSIH and MRSIS Algorithms . . . . . . . . . . . . . . . . . . . . . . 794.2.1 Denotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2.2 Space and Memory Requirements of MRSIH . . . . . . . . . . . . . . . . . . . . 804.2.3 Space and Memory Requirements of MRSIS . . . . . . . . . . . . . . . . . . . . 824.2.4 Time Complexity of the Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 87

4.3 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884.4 Related Work and Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5 Inexact Pattern Matching with MapReduce 975.1 The Pattern Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2 The Pattern Matching Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.3 Analysis of the MRMM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.3.1 Denotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.3.2 Space and Memory Requirements of the MRMM Algorithm . . . . . . . . . . . 104

5.4 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6 Optimizing the VF2 Algorithm 1126.1 The VF2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1126.2 Candidate Pair Number Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.3 Ordering the Candidate Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.4 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7 Conclusions 1217.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

List of Publications 125

Bibliography 127

v

List of Figures

2.1 An example transformation rule in VMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 An example control flow in VMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 The core Simulink metamodel in VMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 The structure of a MapReduce algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 The structure of a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Annotated structure of a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 The control flow of the TransFlattener transformation . . . . . . . . . . . . . . . . . . 193.4 The transformation rule RW_Matlab_Flattener_Get_OutEdges . . . . . . . . . 203.5 The transformation rule RW_Matlab_Flattener_OutBlock . . . . . . . . . . . . . 203.6 The transformation rule RW_Matlab_Flattener_GetAllEdges . . . . . . . . . . . 203.7 The transformation rule RW_Matlab_Flattener_InBlock . . . . . . . . . . . . . . 203.8 The transformation rule RW_Matlab_Flattener_ParentLevel . . . . . . . . . . . 213.9 The transformation rule RW_Matlab_Flattener_ConnectBlocks . . . . . . . . . 213.10 The coverages of the first two propositions regarding the structure of a Subsystem . . . . 223.11 A Sorted List for a model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.12 The control flow of the Trans_SL transformation . . . . . . . . . . . . . . . . . . . . . . 323.13 The transformation rule RW_Matlab_ProcessEdges . . . . . . . . . . . . . . . . . . 323.14 The transformation rule RW_Matlab_DeleteProcessed . . . . . . . . . . . . . . . . 323.15 The transformation rule RW_Matlab_CheckForSubsystem . . . . . . . . . . . . . . 333.16 The transformation rule RW_Matlab_TagTheInBlocks . . . . . . . . . . . . . . . . 333.17 The transformation rule RW_Matlab_ProcessFirstInSubsystem . . . . . . . . . . . 333.18 The transformation rule RW_Matlab_CheckForSubSubsystem . . . . . . . . . . . . 343.19 The transformation rule RW_Matlab_FinishSubSubsystem . . . . . . . . . . . . . . 343.20 The control flow of the Trans_TypeProp transformation . . . . . . . . . . . . . . . . . 433.21 The transformation rule RW_Matlab_SetConstant . . . . . . . . . . . . . . . . . . . 433.22 The transformation rule RW_Matlab_SetSimpleBlocks . . . . . . . . . . . . . . . . 433.23 The transformation rule RW_Matlab_SetSubsystemIn . . . . . . . . . . . . . . . . . 443.24 The transformation rule RW_Matlab_SetSubsystemOut . . . . . . . . . . . . . . . . 443.25 An example for the data type propagation transformation . . . . . . . . . . . . . . . . . . 463.26 The control flow of the FlattenedScheduling transformation . . . . . . . . . . . . . . 493.27 The transformation rules related to the breadth first search . . . . . . . . . . . . . . . . . 493.28 The transformation rule related to the TagDFBlock rule container . . . . . . . . . . . . . 503.29 The transformation rule related to the CreateInportBlock rule container . . . . . . . . . . 503.30 The transformation rule related to the ConnectSubsystem rule container . . . . . . . . . . 51

vi

List of Figures

3.31 The source model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.32 The model after the transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.33 Transformation rule replacing the square root blocks . . . . . . . . . . . . . . . . . . . . . 543.34 The models after applying the transformations . . . . . . . . . . . . . . . . . . . . . . . . 553.35 The resource requirements of the transformations . . . . . . . . . . . . . . . . . . . . . . . 573.36 The resource requirements of the transformations . . . . . . . . . . . . . . . . . . . . . . . 573.37 The resource requirements of the transformations . . . . . . . . . . . . . . . . . . . . . . . 583.38 The example Simulink R© model for the TransFlattener transformation . . . . . . . . . 583.39 The model after the TransFlattener transformation . . . . . . . . . . . . . . . . . . . 593.40 The example Simulink R© model for the Trans_SL transformation . . . . . . . . . . . . . 603.41 The resulting Sorted List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.42 The properties of the Add and In1 block before the Trans_TypeProp transformation . 613.43 The root level of the example Simulink R© model for the Trans_TypeProp transformation 613.44 The result of the Trans_TypeProp transformation . . . . . . . . . . . . . . . . . . . . 623.45 The structure of the root level and the virtual Subsystem . . . . . . . . . . . . . . . . . . 623.46 The properties of the Gain and Sum blocks before the transformations . . . . . . . . . . . 633.47 The model after the first transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.48 The model after the second transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.1 The EBNF of a data row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2 The visual and textual representation of a graph . . . . . . . . . . . . . . . . . . . . . . . 694.3 The different node sets in VF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4 The structure of the MRSIH algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.5 The example graph with a candidate node . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.6 The EBNF of a candidate row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.7 The structure of the MRSIH algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.8 The relation between the different states of the MRSIS algorithm . . . . . . . . . . . . . 784.9 The visual and textual representation of the source graph . . . . . . . . . . . . . . . . . . 804.10 The outputs after the first iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.11 The outputs after the second iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.12 The probabilities for edge generation in R-MAT graphs . . . . . . . . . . . . . . . . . . . 884.13 The target graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.14 The size of the outputs matching the TG5 in R-MAT-10-16-l . . . . . . . . . . . . . . . . 894.15 The size of the outputs matching the TG5 in R-MAT-12-16-l . . . . . . . . . . . . . . . . 904.16 The size of the outputs matching the TG5 in R-MAT-14-16-l . . . . . . . . . . . . . . . . 904.17 The size of the outputs matching the TG7 in R-MAT-10-16-l . . . . . . . . . . . . . . . . 904.18 The size of the outputs matching the TG7 in R-MAT-12-16-l . . . . . . . . . . . . . . . . 914.19 The size of the outputs matching the TG3 graph . . . . . . . . . . . . . . . . . . . . . . . 914.20 The required time for finding all TG3 subgraphs . . . . . . . . . . . . . . . . . . . . . . . 924.21 The required time for finding the target graphs in R-MAT-12-16-l . . . . . . . . . . . . . 93

5.1 Graph representing the Bank-Customer relationships . . . . . . . . . . . . . . . . . . . . . 975.2 The traditional patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.3 A simple pattern with optional blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.4 Language features of pattern matchers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.5 The EBNF of the language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.6 The target graphss with optional blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.7 The size of the outputs matching the TG5WO in R-MAT-10-16-l . . . . . . . . . . . . . . 1085.8 The size of the outputs matching the TG5WO in R-MAT-12-16-l . . . . . . . . . . . . . . 1095.9 The size of the outputs matching the TG7WO in R-MAT-10-16-l . . . . . . . . . . . . . . 109

vii

List of Figures

5.10 The size of the outputs matching the TG7WO in R-MAT-12-16-l . . . . . . . . . . . . . . 1105.11 The size of the outputs matching the TG3WO graph . . . . . . . . . . . . . . . . . . . . . 1105.12 The required time for finding all TG3WO subgraphs . . . . . . . . . . . . . . . . . . . . . 111

6.1 The different node sets in VF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.2 Partial mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.3 The example host graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.4 Example LHS graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

viii

List of Tables

3.1 Experimental results regarding to the application order . . . . . . . . . . . . . . . . . . . 56

4.1 Matching time to find all subgraphs isomorphic to TG3 . . . . . . . . . . . . . . . . . . . 924.2 Matching time to find all subgraphs isomorphic to TG5 . . . . . . . . . . . . . . . . . . . 924.3 Comparison of existing approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.1 Matching time to find all subgraphs isomorphic to TG3WO . . . . . . . . . . . . . . . . . 111

6.1 Comparison of the algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

ix

List of Algorithms

1 The algorithm of the transformation TransFlattener . . . . . . . . . . . . . . . . . 122 The algorithm of finding a virtual Subsystem in the model . . . . . . . . . . . . . . . . 133 The algorithm that flattens a virtual Subsystem . . . . . . . . . . . . . . . . . . . . . . 134 The algorithm that obtains the information about the outgoing edges of the Subsystem 155 The algorithm that moves the inner blocks of the Subsystem to the parent level . . . . 166 The algorithm that moves the inner blocks of the Subsystem to the parent level . . . . 167 The algorithm of the transformation Trans_SL . . . . . . . . . . . . . . . . . . . . . 278 The algorithm of processing blocks without incoming edges . . . . . . . . . . . . . . . 279 The algorithm of block processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2810 The algorithm of deleting processed elements . . . . . . . . . . . . . . . . . . . . . . . 2911 The algorithm of processing a Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . 2912 The algorithm of checking processable Subsystem . . . . . . . . . . . . . . . . . . . . . 2913 The algorithm of processing edges related to In- and Outport blocks . . . . . . . . . . 3014 The algorithm of processing blocks with incoming edges . . . . . . . . . . . . . . . . . 3015 The algorithm of the transformation SetTypes . . . . . . . . . . . . . . . . . . . . . . 3816 The algorithm of the transformation SetNextInherit . . . . . . . . . . . . . . . . . 3917 The algorithm of the transformation SetFirstInSubsystem . . . . . . . . . . . . . . 4018 The algorithm of the transformation SetTypeNextToSubsystem . . . . . . . . . . 4019 The algorithm of the transformation SetPreviousInherit . . . . . . . . . . . . . . . 4020 The algorithm of the transformation VerifyTypes . . . . . . . . . . . . . . . . . . . 4121 The algorithm of the transformation VerifySimpleBlock . . . . . . . . . . . . . . . 4122 The algorithm of the transformation VerifyFirstInSubsystem . . . . . . . . . . . . 4223 The algorithm of the transformation VerifyNextToSubsystem . . . . . . . . . . . 4224 The algorithm of the MRSIH mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . 7125 The algorithm of the MRSIH reducer . . . . . . . . . . . . . . . . . . . . . . . . . . . 7326 The algorithm of the first mapper (M ′

S) of the MRSIS . . . . . . . . . . . . . . . . . . 7527 The algorithm of the first reducer (R′

S) of the MRSIS . . . . . . . . . . . . . . . . . . 7628 The algorithm of the second mapper (M ′′

S ) of the MRSIS . . . . . . . . . . . . . . . . 7629 The algorithm of the second reducer (R′′

S) of the MRSIS . . . . . . . . . . . . . . . . 7730 The algorithm of selecting the next candidate node for a partial mapping in MRMM 10231 Generation of candidate pairs in the VF2 algorithm . . . . . . . . . . . . . . . . . . . 11432 Extension for the procedure that generates candidate node pairs . . . . . . . . . . . . 11633 Generate the candidate node pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11634 Generate the candidate node pairs with ordering function . . . . . . . . . . . . . . . . 117

x

Acknowledgements

This thesis could not have been written without the support of many people.First of all, I am truly grateful to my parents, my sister, and her family for their continuous

support. They always stood by me, and supported me in every possible way. I am greatly indebted toLilla who motivated me throughout this work, tolerated the hard work, and provided every conditionfor me to concentrate on my work. I would like to express my gratitude to my grandma to inspire meto finish this work. Without them, I could not succeed. I owe them so much.

I am thankful to my scientific advisor László Lengyel. I am indebted to him for his encouragement,friendly advice. I thank him all the inspiring and motivating conversations, the proofread papers, andpersonal time he has spent on me. Without his help, I could have never succeed. I would also like toexpress my gratitude to Pieter J. Mosterman. I thank him the tremendous patience, the proofreadpapers, and all the invaluable advice.

I am not less grateful to the members of our research group, Márk Asztalos, Gergely Mezei, TamásMészáros, and Tamás Vajk for their suggestions. Besides their professional support, I thank them thenever-ending good mood in the office, their friendship means a lot to me. The hours we spent togethermade this journey even more special.

I am grateful to István Vajk and Hassan Charaf for providing the human and financial conditionsfor my research, and making it possible to travel and attend many conferences. I am also thankful toall members of the Department of Automation and Applied Informatics for the good atmosphere.

Finally, I want to thank all my friends for their support.

xi

1

Introduction

1.1 Simulink Model ElaborationAdvances in electronics miniaturization combined with an understanding of computing are driv-ing an ever-increasing complexity of technical systems of truly all sorts (consumer electronics,defense, aerospace, automotive, industry, and others). Not only does the increasing capability ofelectronics enable more extensive logic to be implemented, the robustness and efficiency in com-munication protocols that it supports has been the driver of even more network connected sys-tems. The corresponding systems operate at the confluence of cyberspace, the physical world,and human participation. Recently, these next generation of embedded systems have been termedCyber-Physical Systems [PCA, 2007]. An important aspect of such systems is their collaborat-ing nature with ensembles of software-intensive systems, which comes with a specific set ofneeds [Mosterman and Zander, 2015a, Mosterman and Zander, 2015b].

Raising the level of abstraction is an important tool to manage the enormous complexityof such Cyber-Physical Systems. To this end, Model-Based Design (e.g. [Mosterman et al., 2005,Mosterman et al., 2004, Nicolescu and Mosterman, 2010]) introduces levels of abstraction in the formof computational models with executable semantics. At the various levels of abstraction, only con-cerns pertinent to the particular design task at hand are included while implementation aspects aredeferred to be addressed in more detailed models. Throughout the design of the embedded system partof a Cyber-Physical System, these models are then elaborated to include increasing implementationdetails. The elaboration terminates when a level of detail is arrived at from which an implementationcan be automatically generated. The implementation may be either in software by generating C codeor in hardware by generating HDL (Hardware Description Language).

The support for abstractions is important in formulating a design problem in the problem space.Design then concentrates on transforming the problem formulation into a solution formulation. Inthis context, it is of great value that the original problem formulation can be void of solution as-pects. This is why domain-specific modeling is becoming widely applied to describe complex systems.Domain-specific modeling is a powerful, but still understandable technique with its main strengththe application of the domain-specific languages. A domain-specific language is a specialized languagethat can be tailored to a certain problem domain; therefore, it is more efficient than the generalpurpose languages that often are tailored to a solution domain (and domain-specific in that sense)[Fowler, 2010, Kelly and Tolvanen, 2008].

Modern model transformation approaches are becoming increasingly valuable in software devel-opment because of the ability to capture domain knowledge in a declarative manner [Denil, 2013].This enables various steps in the software development to be specified separate from one anotherwith apparent advantages such as reuse. In the field of embedded system design, the computational

1

1. Introduction

functionality that is ultimately embedded moves through a series of design stages where differentsoftware representations are used. For example, before generating the code that is to run on the finaltarget, code may be generated that includes additional monitoring functionality. As another example,the software representation may be designed in floating point data types before being transformedinto fixed point data types [Mosterman et al., 2004].

Simulink R© [Sim, 2012a] is a popular tool for control system design in industry. Therefore, ap-plying model transformations for embedded software design purposes on Simulink models rendersthe developed technology easily adaptable and adoptable by industry. Though there have beenadvances in defining and modeling declarative model transformations inside the Simulink environ-ment [Denil et al., 2014], it is challenging to provide the full power of dedicated transformation en-gines in such a manner. In order to provide access to encompassing and powerful transformationtechnologies, a separate modeling and model processing framework is applied. The Visual Modelingand Transformation System (VMTS) [VMT, 2012, Angyal et al., 2009] framework has been preparedto be able to communicate with the Simulink environment. In this manner, with the help of modeledmodel transformation, problems can be solved at the most appropriate abstraction level. In this casethe most appropriate abstraction level means that the required model optimization, modification, ortraversing can be expressed in the Simulink domain. Since the Simulink metamodel, as a DSL, isdefined in the VMTS, therefore, during the transformation design, the Simulink users can refer totheir well-known Simulink language elements to specify the required model processing in the VMTSframework. This builds on the fundamental premise of Computer Automated Multiparadigm Model-ing; to use the most appropriate formalism for representing a problem at the most appropriate levelof abstraction [Mosterman and Vangheluwe, 2002, Mosterman and Vangheluwe, 2004].

1.2 Pattern Matching in Large GraphsCloud computing has received significant attention recently. Companies can store their data and per-form their computations off-premise in a highly available and scalable environment. Compared totraditional infrastructures that only use in-house resources, cloud computing has many advantagesthat have been transforming the computational solutions used at companies. Naturally, already ex-isting on-premise resources can still be used as part of the infrastructure by connecting them to cloudservices and forming a hybrid environment [Mulholland et al., 2010].

Nowadays, processing datasets of the order of terabytes and petabytes is a common task.Therefore, the problem today is often not a lack of information, but instead, information over-load [Coffman et al., 2004]. The analysis of these massive data sets requires appropriate tool support.

Graphs are commonly used to represent a variety of data structures. By attributing the nodes andedges, graphs are effectively used in modeling different states of a system, solving traffic problems,representing relationship between the different parts of the software and/or modeling the structureof chemical elements. Today, the social networks are extremely popular, and provide a great examplefor large scale data which can be represented as graphs as well. However, analyzing this size of datacannot be effective without parallelization.

The area of subgraph isomorphism deals with the problem of deciding whether a certain graphcan be found in another graph or not, i.e. if there is an injective morphism from one graph to another.Formally, consider graphs G= (V,E) and G′ = (V ′

,E′). There is a subgraph in G′ isomorphic to G if

there exists a function f :V →V′ such that (v1,v2)∈E⇔ (f(v1),f(v2))∈E′ . To decide such a question

and to find an appropriate f is difficult and is proven to be NP-complete in general [Plump, 1998] bythe reduction to another NP-complete problems like the maximum clique problem and the problemof finding Hamiltonian cycles. Fortunately, if the size of G is fixed, an appropriate f morphism canbe calculated in polynomial time, where the exponents depend on the size of the searched G graph([Ullmann, 1976, Cordella et al., 1998]). These exponents can be very large, though.

2

1.3. Motivation

Subgraph isomorphism has been intensively applied in numerous areas, e.g. in pattern discov-ery in large databases, such as the social networks [Snijders et al., 2006], in graph rewriting oreven in cheminformatics to find similarities between chemical molecules [Leach and Gillet, 2007].For example, subgraph isomorphism can be used to analyse metabolic networks by mapping theatoms between reactants and products involved in a reaction, or to find different chemical shapes inmolecules [Rahman et al., 2009]. Another interesting application area is the computer aided design ofelectric circuits [Ohlrich et al., 1993] where subgraph searching is utilized in numerous aspects.

Therefore, finding different patterns in large graphs is considered as a common task. There arecertain, not time critical circumstances, where showing all matches of the sought pattern is the mostimportant factor. Regarding to the approach used to detect the subgraph isomorphisms the important,advantageous factors are the following:

• The used approach must find all occurrences of the given pattern,

• The method must handle large datasets,

• There should be a possibility of using different heuristics.

Beside the field of detecting exact patterns in large graphs, the area of discovering inexact patternsgains more and more interest in the scientific community. To find a match, one needs a patternspecification language and a matcher algorithm that performs the actual searching. The languagecontains special features that make it possible to define not just a single graph but inexact patternsas well. An inexact pattern covers a set of possible exact graphs by using constraints. Being able todetect instances of inexact patterns might be critical in some cases, for example, when the analyzerneeds to match a general pattern without knowing all of the details, the host graph is not completelyknown, or some aspects of the searched pattern is incorrect [Coffman et al., 2004]. Moreover, inexactpatterns lead to more concise specifications that is an important aspect in graph rewriting-basedmodel transformations [Ehrig et al., 2006].

1.3 MotivationThe role of the model-driven engineering (MDE) in software development is similar to that of automa-tion in factories, the overall reliability and quality of the products can be improved, high complexitycan be handled efficiently, and development time can be reduced. This thesis strives to contribute toMDE by presenting how it can be applied in such a complex and popular tool, like Simulink.

MDE is often based on model transformation, which is used throughout a wide spectrum ofthe development phases. A few representative objectives, including examples, are as follows: (i) tocreate a higher level of abstraction in the development phase through the mapping of platform-independent models to platform-specific models, e.g., to increase the reusability and maintenanceof the systems and testing in smart home systems [Conejero et al., 2011]. (ii) Transforming modelsbetween different domains, e.g., transforming Cyber-Physical Systems into different mathematicalmodels to perform certain analysis. (iii) Refactoring purposes, i.e. improving model attributes andstructure, while preserving the semantic meaning.

Defining the most appropriate level of abstraction is important for solving the problems in an ef-ficient and convenient way. Raising the abstraction level of the model elaboration process of Simulinkhelps utilizing the value that a higher level of abstraction can offer, for example, reasoning aboutthe modularization of operations. The focus of the first thesis is the investigation how this higherabstraction level can be achieved by replacing the different model processing steps with model trans-formations. In this thesis numerous model transformation has been provided to increase the level ofabstraction in the model elaboration phase.

3

1. Introduction

The combination of pattern matching and cloud computing is a promising research field. Findingexact matches of a given pattern requires lots of resources, since the partial matches, the excludedand possible nodes have to be continuously maintained. Utilizing the immense computational power,and storage space given by the cloud providers leads to a set of new pattern matching approaches.New computational techniques, such as highly distributed graph algorithms based on MapReduce canaid the pattern matching. In this thesis, I have focused on providing algorithms that support findingexact patterns in graphs with millions of edges and vertices.

Often, the available information is not precise enough to perform searches for exact patterns.Therefore, there is a need for an approach that is usable in these situations. The complexity of theinexact pattern matching demands high computational power, which is an important argument forutilizing the potential of the cloud. In this thesis, I provide an algorithm based on the MapReduceframework that detects inexact patterns in large graphs. A language supporting the definition of suchinexact patterns is also presented.

However, the popularity of the cloud-based solutions does not remove the demand for increasingthe performance of the already proven techniques. This is particularly true in case of the algorithmsfor finding graph-subgraph isomorphisms. Therefore, in this thesis, I have focused on providing newtechniques to improve the efficiency of the popular VF2 algorithm [Cordella et al., 2004].

1.4 Thesis OutlineIn the following, the overall structure of this thesis is presented.

• Chapter 2 introduces the Visual Modeling and Transformation System, the communicationbetween the modeling framework and Simulink R©, and presents the MapReduce framework.

• Chapter 3 focuses on increasing the abstraction level of the Simulink model elaboration pro-cess. Different model transformations are given to utilize the advantageous properties of thedomain-specific modeling, for example, they are reusable, transparent, and platform indepen-dent. Moreover, the main attributes of the model transformations are also investigated.

• Chapter 4 is devoted to present two pattern matching algorithms. They are capable of findingall subgraphs that are isomorphic to the target pattern. The algorithms are designed to work ongraphs with millions of edges and vertices, thus they are based on the MapReduce technique. Thespace and memory requirements of the algorithms are presented, and performance evaluation isalso provided.

• Chapter 5 presents an algorithm that finds inexact patterns. In order to handle large sourcegraphs, the algorithm is based on the MapReduce technique. To specify the patterns, a newlanguage is provided. Analysis and performance evaluation are also presented.

• In Chapter 6, two optimization techniques are introduced for the VF2 algorithm. The presentedexperiments support the theoretical results.

• Finally, Chapter 7 summarizes the results and closes with future action points.

4

2

Background

In this chapter, a modeling and a computational framework are introduced. The model transforma-tions presented in Chapter 3 have been created in the Visual Modeling and Transformation System(VMTS). The way the VMTS supports the modeling with the familiar Simulink elements and thecommunication between the modeling framework and Simulink R© is introduced in this chapter. TheMapReduce framework, on which the algorithms presented in Chapter 4 and Chapter 5 are based, isalso introduced.

2.1 VMTS, The Modeling FrameworkThe Visual Modeling and Transformation System is a general purpose metamodeling environmentsupporting an arbitrary number of metamodel levels. Models in VMTS are represented as directed,attributed graphs. The edges of the graphs are also attributed. The visualization of models is supportedby the VMTS Presentation Framework (VPF) [Mészáros et al., 2008]. VPF is a highly customizablepresentation layer built on domain-specific plugins, which can be defined in a declarative manner.

VMTS is also a transformation system. It uses a graph rewriting-based model transformationapproach or a template-based text generation. Templates are used mainly to produce textual outputfrom model definitions in an efficient way, while graph transformation can describe transformationsin a visual and formal way.

In VMTS the Left-Hand Side (LHS) and the Right-Hand Side (RHS) of the transformation arerepresented together. In this manner, the transformation itself can be more expressive. In order todistinguish the LHS from the RHS in the presentation layer, the VMTS uses different colors. Theelements represented with the color blue are created by the transformation rule. This means that ifthe LHS and the RHS would be depicted in two separated graphs, these elements would be only partof the RHS graph. Similarly, the color red indicates that the given element will be deleted by thetransformation rule. The color yellow is used when an edge between two elements will be replaced. Inthis case the type and the attributes of the edge will not change. A background that is colored graymeans that the element will be modified. With the help of these colors, the transformation process iseasily understandable. An example of this method is depicted in Figure 2.1, where the simpleBlockblock is moved to a higher hierarchical level. There is always an option to apply imperative constraintsto each element, but this is not depicted separately.

The control flow language of the VMTS [Asztalos and Madari, 2009] contains exactly one startstate object and one or more end state objects. The applicable rules are defined in the rule containers.The rule containers determine which transformation rule must be applied at the given control flowstate. This means that exactly one rule belongs to each rule container. The application number of therule can also be defined here. By default, the VMTS attempts to find one and only one match for the

5

2. Background

Figure 2.1: An example transformation rule in VMTS

Figure 2.2: An example control flow in VMTS

LHS of the transformation rule. However, if the IsExhaustive attribute of the rule container is set totrue, then the rule will be applied repeatedly as long as its LHS pattern can be found in the model.An example control flow is shown in Figure 2.2.

The edges are used to determine the sequence of the rule containers. The control flow followsan edge based on the outcome of the rule application. In VMTS, the edge to be followed in case ofsuccessful rule application is depicted with a solid gray flow edge and in case of a failed rule applicationwith a dashed gray flow edge. Solid black flow edges represent the edges that can be followed in bothcases.

2.2 Communication between Simulink R© and VMTSSince the model to be transformed is created in Simulink, which is part of the MATLAB R© [Mat, 2012]technical computing environment and the transformation is created in another system (VMTS) it isnecessary to develop a communication method between the two systems.

To be able to represent Simulink models in VMTS, the metamodel of the Simulink languages,which are organized in various different libraries (also called blocksets), is required. Since in Simulinkthere is no strict boundary between the different languages, that is, a given block can be connectedto almost everything else, a common Simulink metamodel was created. This metamodel contains allthe elements of the Simulink library. The generation of this metamodel consists of two steps.

First, a core metamodel is created that contains a Block element, which is the common ancestorof all the nodes in Simulink models, and a descendant Subsystem node, which expresses the commonancestor of the different Simulink Subsystems. This metamodel also contains a Signal edge to reflectinput/output relations and a Containment edge to reflect containment hierarchy between nodes. The

6

2.3. The MapReduce Technique

Figure 2.3: The core Simulink metamodel in VMTS

metamodel is depicted in Figure 2.3.Second, by programmatically traversing the base Simulink library, this metamodel is extended with

the other nodes found in the different specialized libraries. For each Simulink element, exactly onenode is generated. The result of this generation process is several hundred new metamodel elements.

In addition to the metamodel, the VMTS must be prepared to read and write Simulink models.Thus, a new kind of data exchange layer was generated for communicating with MATLAB. To modifySimulink models, the P/Invoke technology [PIn, 2012] has been chosen. This has the advantage thatthe MATLAB interpreter can be called directly through DLL calls, instead of manipulating the textualmodel (mdl extension) files. In this manner the VMTS interacts with the MATLAB API for accessingSimulink model datastructures and this renders the interface independent of file format changes.Moreover, the changes to the Simulink model as performed by the VMTS can be made visible, liveduring the transformation execution, on the Simulink diagrams as well. Furthermore, the informationthat is otherwise only available during compile time and during simulation time of a Simulink modelcan be accessed as well.

2.3 The MapReduce TechniqueThe MapReduce framework is a parallel computing paradigm [Dean and Ghemawat, 2008]. Theframework was originally developed at Google, and today has become the de facto ap-proach for processing large-scale data. One of its open source implementations is the ApacheHadoop [Apache Hadoop, 2011]. The MapReduce framework was designed for utilizing distributedcomputing resources and for handling large data sets. Data is always assumed to be distributed, andthe data balancing is managed by the Hadoop Distributed File System (HDFS).

One of the biggest differences between the MapReduce and other parallel computing frameworksis that MapReduce implements both parallel and sequential computation: the framework calls themap and reduce functions sequentially, but in each phase the functions are executed in parallel.

2.3.1 The Basics

The structure of a MapReduce algorithm is illustrated in Figure 2.4. Basically, the MapReduce algo-rithm consists of three phases. First, the map function is executed. The framework assigns the samemapper task µ to several processes, but these processes take different inputs as the lone argumentof µ. The mapper function is stateless, because it does not have any information on the previously

7

2. Background

Figure 2.4: The structure of a MapReduce algorithm

processed data, nor can it communicate with other mapper tasks. In this manner, it only requires theinput value to compute its output value. This way the mapper function can be run against the valuesin parallel, which provides great efficiency. Generally, the mapper µ takes a single string input andproduces any number of <key, value> pairs as output.

The second phase is referred to as shuffle or as group. At this stage, the framework seamlesslysorts the outputs of the mappers by their keys. As a result, the values are grouped by their key values.

The shuffle step makes it possible to assign every value with the same key to the same reducer inthe final phase. A reducer ρ takes a single key and all the values associated with it as input. Afterprocessing, the reducer produces arbitrary number of <key, value> pairs, as output. Like the mappertasks, the reducers are stateless as well. An important attribute of the MapReduce framework is thatall mapper tasks must finish before the reducer tasks can begin. This aspect of the framework supportsthe sequential processing. However, by assigning different keys to different processes, the reducer taskalso supports parallelization.

The map, shuffle, and reduce phases constitute a MapReduce job. The MapReduce algorithm canbe implemented as a series of MapReduce jobs. In this case, the output of the λ1 job (i.e. the <key,value> pairs produced by the ρ1 reduces) is the input of the λ2 job (i.e. the string input of the µ2mapper)[Fehér et al., 2013b].

Based on [Karloff et al., 2010], the formal definition of the MapReduce programming paradigm isthe following.

Definition 2.1. A mapper is a function that takes a binary string (which might be a <key, value>pair) as input. As output, the mapper produces a finite set of <key, value> pairs.

Definition 2.2. A reducer is a function whose input is a binary string, a key (k), and a sequenceof values (v1,v2, . . .) that are also binary strings. As output, the reducer produces a finite multiset ofpairs of binary strings <k,vk,1>, <k,vk,2>, <k,vk,3>, . . . . The key in the output pair is identical tothe key in the input.

As it was mentioned before, the main strength of the MapReduce approach is the ease of paral-lelization. Since one mapper task processes one element from the input set at a time, the frameworkcan have multiple instances from the same map function assigned to different computing nodes in

8

2.3. The MapReduce Technique

parallel. Similarly, one reducer task operates on one key value and on the values associated with it.Therefore, if the number of different keys is denoted with n, then at most n different reducer instancescan be executed simultaneously.

2.3.2 Sample Application

In order to support understanding the potential of the model, consider the following simple, textbookexample of the MapReduce algorithm: there is an extra large log file, where each line contains thecreation time of the entry, the message of the request and the actual response time. The user wantsto know the average response time.

In this case the map function takes one line at a time from the textual file as its input. It splitsthe line into tokens separated by whitespace characters and emits the third token as the value of the<key, value> pair. The associated key is always “Response”, so the emitted line for each token is<Response, <time>>.

As it was mentioned, the shuffle phase groups the emitted lines by the keys. Since the mappersemit with the same key, all values are obtained by the same reducer. This means, the reducer justcalculates the average value of its input arguments and emits the result.

Of course, the output of the reducers may serve as the input of other map functions in case thereare other computations to do, but in this simple example there is no need to execute another mapperphase.

This chapter introduced the VMTS modeling environment, presented its support for modelingwith the familiar Simulink elements and the communication between the systems. The MapReduceframework and its properties has also been introduced. The next chapter presents, how model trans-formations can increase the abstraction level of the Simulink model elaboration process.

9

3

Increasing the Abstraction Level of theSimulink Model Elaboration Process UsingModel Transformations

A Simulink model comprises a set of blocks that each represent modeled computations with connec-tions between them. The connections are directed based on input and output of the computations.A block is called a subsystem if it is hierarchically decomposed into another set of blocks with con-nections between them. The connected blocks represent a set of declarative constraints that is madeoperational by the execution engine by determining a hierarchical execution list. To this end, theexecution of the blocks is ordered based on control and data dependencies that determine how thedifferent blocks can follow each other in an overall execution (see [Han and Mosterman, 2010] for de-tails on the execution constraints). Simulink supports two types of hierarchical decomposition: (i) aspurely graphical by means of virtual subsystems and (ii) as units of execution by means of nonvir-tual subsystems. Because the virtual subsystems are only graphical syntax and have no bearing onexecution semantics, they should not be part of the execution list. Therefore, to create this list, thesemantically superfluous hierarchical layers of virtual subsystems are eliminated (“flattened”) in thesorted order of blocks, the Sorted List, from which the execution list is computed [Sim, 2012d].

In Simulink, the data types of a model are inferred in a compilation stage, for example by usingforward and backward data type propagation rules [Sim, 2012d]. To explicitly indicate that a datatype should be inferred, it can be set to “Inherit.” In addition to propagation rules, further informationis utilized in the data type determination. For example, a default data type such as “double” may beset in case no other explicit resolution is inferred. As another example, given a number of availablebits per word on the computing platform, the design range of values for a variable may determine arepresentation in fixed point. Moreover, Simulink also checks the types of signals and input ports inorder to ensure that they do not conflict.

At present, flattening virtual subsystems, generating the Sorted List, and propagating data typesare implemented in the Simulink code base. Though efficient, this makes difficult or even preventsunlocking value for which a higher level of abstraction is more appropriate (e.g., reasoning aboutthe implementation and modularization of operations but also user configuration). Therefore, byimplementing these procedures at a higher level of abstraction, the advantageous properties of domain-specific modeling can be utilized.

This chapter focuses on a novel solution to raise the abstraction level of processing Simulink mo-dels. This approach is based on model-transformations created in VMTS. Using model transformationto flatten virtual subsystems, create a Sorted List, propagate or change data types, reduce the risk ofcreating artificial algebraic loops, and replace built-in solutions with custom algorithms helps raising

10

3.1. Related Work

the abstraction level from API programming to software modeling. The solution possesses all theadvantageous characteristic of the model transformation, for example, it is reusable, transparent, andplatform independent.

An important benefit of modeling transformations in a declarative sense is that the separatedfunctionality can be conveniently reordered. This allows the study of the context independence ofcaptured functionality as well as potential performance improvements that derive from different orders.This chapter also presents an analysis of the application order in case of applying both the flatteningand the data propagating transformations.

The rest of the chapter is organized as follows. Section 3.1 provides an overview of related work.Section 3.2 presents the model transformation responsible for flattening virtual subsystems. In Sec-tion 3.3, the model transformation generating Sorted List is introduced. The model transformationthat propagates data types in Simulink models is presented in Section 3.4. Section 3.5 describes themodel transformation dedicated to reduce the number of occurrences of artificial algebraic loops inSimulink models. Section 3.6 presents a model transformation applying custom algorithms to replacebuilt-in Simulink solutions. How the application order of the transformations affects the efficiencyis examined in Section 3.7. Examples for the transformations are presented in Section 3.8. Finally,Section 3.9 closes with concluding remarks.

3.1 Related WorkSimulink is very popular in the Engineering community, both academic and commercial as it is thetool of choice for many in control engineering, signal processing, system identification, and others.However, there is much less visibility in the Computer Science community and, consequently, theunderlying principles and mechanisms of Simulink have been studied much less from an informationtechnology perspective. As a consequence, there is little directly related work, though some moreindirectly related efforts are identified.

In related work [Agrawal et al., 2004], a formal description is given about a translation procedurethat can convert a well-defined subset of Simulink block diagram models and Stateflow R© [Sta, 2012]state transition diagram models into a standard form of hybrid automata [Alur et al., 1995]. Thistransformation is implemented with graph transformation. As a result, different verification toolsfor hybrid automata can operate on Simulink and Stateflow models that are proliferate in industry.Though this work also applies model transformation on Simulink models it differs from the workdiscussed in this chapter in that the desired results of flattening, sorting, and data propagating arean integral part of the execution processes of the Simulink models. Moreover, the transformationspresented in this chapter are endogenous (i.e., no change of formalism) [Mens and Van Gorp, 2006].

In other related work [Assmann, 1996], graph transformations were employed to model programtransformations such as optimizations. Because at the model level, the transformations could beequally well applied for analysis. This work differs from the approach presented in this chapter inthat its source graph is given either as an abstract syntax tree or as an intermediate code sequence.

Design patterns bear a similarity with the work presented here because of their value through-out the different design phases of software systems. As such, there is a benefit to not only formallyspecify pattern-based methodologies (instead of informal descriptions) but to do so at a high level ofabstraction. Related work [Radermacher, 1998] addresses this desideratum by utilizing graph trans-formations that allow modeling the specifications at the desired level of abstraction. The work differsfrom the documented effort in that the flattening, sorting, and data type propagation are related yetdistinctly different from design patterns because of their global application to model processing.

Another algorithm that applies to Simulink models is presented in [Caspi et al., 2003]. This algo-rithm is introduced to formally map an important subset of Simulink models, namely discrete-timemodels, to Lustre [Benveniste et al., 2003, Halbwachs et al., 1991] programs. Though formally spe-

11

3. Increasing the Abstraction Level of the Simulink Model Elaboration ProcessUsing Model Transformations

cified and analyzed, the transformation is not modeled at a declarative level (such as by a graphtransformation), and as such, lacks the corresponding benefits.

In remaining related work [Bredenfeld and Camposano, 1995], a data model for tool integrationis presented. This approach extends existing data models by an abstract graph model. In compari-son, the manipulation presented in this chapter is based on model transformation as formal graphtransformations.

3.2 Flattening Simulink R© ModelsAs it was previously introduced, Simulink flattens virtual Subsystems in order to create the SortedList, which eventually leads to the Execution List. To support analysis, modularization, etc., it iscrucial to specify the flattening at a sufficiently high level of abstraction. In this section an approachis proposed that can serve as the foundation of a solution based on model transformation. Thepresented algorithm is also discussed in [Fehér et al., 2013a], where it is compared with a basic, moregeneral approach.

In order to increase the efficiency of the flattening algorithm, it integrates optimizations thatexploit some of the properties of the virtual Subsystems in Simulink. These special properties are thefollowing:

• Each Outport block of a Simulink model has exactly one block that is connected to it, that is,it has one incoming edge.

• Each In port of a virtual Subsystem has exactly one incoming edge.

3.2.1 The TransFlattener Algorithm

The TransFlattener algorithm is responsible for flattening all virtual Subsystems in the model.Throughout the flattening, the transformation moves the contained elements (except for the Inportand Outport blocks) out of the Subsystems and connects them to other blocks in a way that thefunctionality of the Simulink model does not change.

The main part of the algorithm is shown in Algorithm 1. The TransFlattener algorithmcontains a while block. The iteration condition of this block calls the IsThereVS function, whosereturn value determines whether a virtual Subsystem is present in the model. If it returns true, thenthe vs variable stores the virtual Subsystem to process and the algorithm steps into the iteration.Otherwise, since there is no virtual Subsystem to process, it terminates. Inside the iteration, theProcessVirtualSubsystem function is called, which is responsible for the processing.

Algorithm 1 The algorithm of the transformation TransFlattener1: procedure TransFalttener(Model m)2: Subsystem vs← null3: while IsThereVS(m, vs) do4: ProcessVirtualSubsystem(vs)5: return

As mentioned, the IsThereVS function, depicted in Algorithm 2, is responsible for determiningwhether a model m contains a virtual Subsystem and it determines the particular Subsystem block toflatten. Since the other parts of TransFlattener process the given virtual Subsystem, the functionalso has to return the found subsystem in the parameter vs. Of course, this is just an implementationdetail, the same can be achieved, for example, by a common storage or a global variable. Supposethat the model has a property named Subsystems that lists all contained Subsystems. In this case,

12

3.2. Flattening Simulink R© Models

the function simply has to check if there is any item in this list with the IsVirtual attribute set totrue. This attribute is responsible for distinguishing between virtual and nonvirtual (e.g., Atomic)Subsystems. If the function finds such a Subsystem it stores it in the vs parameter and returns withtrue. Otherwise, the return value is false.

Algorithm 2 The algorithm of finding a virtual Subsystem in the model1: procedure IsThereVS(Model m, Subsystem vs)2: if ∃s|s ∈m.Subsystems,s.IsV irtual = true then3: vs← s4: return true5: return false

The ProcessVirtualSubsystem function is called directly from the TransFlattener proce-dure and is presented in Algorithm 3. The ProcessVirtualSubsystem function is responsible forprocessing the given virtual Subsystem, which is its only parameter. The method processes the virtualsubsystem in eight different steps. The first set of these steps concentrates on the edges between thecontained blocks. The next step concerns the position of the blocks. Finally, the last set of stepsdeletes the superfluous elements and recreates the edges between the blocks. In the following, someof these functions will be presented.

Algorithm 3 The algorithm that flattens a virtual Subsystem1: procedure ProcessVirtualSubsystem(

Subsystem vs)2: ProcessOutPortsAndBlocks(vs)3: ProcessInnerEdges(vs)4: ProcessInPortsAndBlocks(vs)5: MoveToParentLevel(vs, prefix)6: MoveToRootLevel(vs, prefix)7: DeleteContainmentEdges(vs)8: DeleteSubsystem(vs)9: ConnectBlocks()10: return

Flattening a Subsystem means that the blocks within the Subsystem (except the In and Outelements) are moved to the next (upper) hierarchy level (either a Subsystem or the root model) andthe flattened Subsystem is deleted. If a block is moved from a Subsystem to another hierarchy level,then the related edges are removed automatically by Simulink because edges that cross hierarchicallevels are not allowed. This means that there is no edge to or from the moved block at its new location.However, there is no guarantee that there are no dangling edges left inside the Subsystem. Therefore,the edges of the block must be deleted before the block is moved out of the Subsystem. Since theedges are lost at the moment when the block is moved, the algorithm must take care of the edgesconnected to this block as well.

When a Subsystem is flattened, its In and Out ports are deleted. Therefore, the algorithm mustknow which blocks were connected to these ports in order to maintain the original functionality. Afterthe transformation, the blocks that were contained by the subsystem must be reachable via the exactsame connections (except the aforementioned ports) as they were before. The first method addressesthe first part of this problem. In Simulink, each In and Out port is represented with an Inport andOutport block inside the subsystem. The elements connected to these blocks inside the subsystemare effectively connected to the elements connected to the appropriate port outside. At first, thealgorithm concentrates on the Out ports of the subsystem. Since there are elements connected to the

13


Figure 3.1: The structure of a Subsystem

ports and elements connected to the blocks, it is convenient to handle the problem in two separatemethods. However, as it was already mentioned, each Outport block has exactly one incoming edge,therefore one method is sufficient to store the information about the connection of the blocks. Previouswork [Wimmer et al., 2010] discusses how to deal with ports in composite elements in more detail.The different ports and blocks are depicted in Figure 3.1.

The ProcessOutPortsAndBlocks function, shown in Algorithm 4, stores for each block con-necting to an Outport block all elements that are connected to the corresponding Out port. To achievethis, the algorithm iterates through the outgoing edges of the given virtual Subsystem. The GetOut-Edges method of the Subsystem returns these edges. To be able to recreate the connection betweenthe blocks, the port numbers also must be stored for each edge. Moreover, the port number alsoidentifies the corresponding Outport block. In this manner, the algorithm obtains the actual Outportblock by calling the GetOutBlock method of the Subsystem with the appropriate port number. Afterthe Outport block is found, the algorithm identifies the only edge connecting to the Outport blockand thereby the source block. Next, the algorithm identifies the block at the opposite end of the edgepointing out from the virtual Subsystem, the target block. This block will be connected to the blocklinked to the actual Outport block, that is, the source block. To this end, the algorithm stores therelevant information in the Tag attribute of the source block temporarily. At the end of the iterationthe algorithm deletes the processed edges in order to avoid the occurrence of dangling edges after theSubsystem is deleted. After the method iterates through all outgoing edges, all source blocks have thenecessary information to create edges connecting to all blocks linked to the corresponding Out ports.

At this point, the algorithm must store the information about the remaining edges in the Sub-system. The ProcessInnerEdges function is responsible for this behavior. Note, that the edgesconnected to the Outport blocks are already deleted. ProcessSimpleEdges simply iterates throughevery outgoing edge of each block inside the Subsystem. The InnerBlocks property of the Subsystemreturns the list of the blocks contained by the Subsystem with the exception of the Inport and Outportblocks, while the GetOutEdges property returns the outgoing edges from the given block. Inside anembedded iteration the function identifies the block the edge is connected to and then stores thenecessary information in the Tag property of that block. Finally, the processed edge is deleted. Afterthe algorithm terminates, each block within the Subsystem stores all necessary information about theedges going out from them. In this manner, it is possible to correctly recreate these edges after the

14


Algorithm 4 The algorithm that obtains the information about the outgoing edges of the Subsystem1: procedure ProcessOutPortsAndBlocks(Subsystem vs)2: for all e in vs.GetOutEdges() do3: outBlock← vs.GetOutBlock(e.PortFrom)4: l← outBlock.Sources[0]5: fromBlock← l.BlockFrom6: toBlock← e.BlockTo7: info← new EdgeInfo(fromBlock,toBlock, l.PortFrom,e.PortTo)8: fromBlock.Tag.Add(info)9: e.Delete()10: l.Delete()11: return

blocks are moved out of the Subsystem.Finally, the algorithm must ensure that the functionality does not change after the In ports

and Inport blocks are deleted. This is achieved by the ProcessInPortsAndBlocks method. Themain principle of this algorithm is the same as the aforementioned ProcessOutPortsAndBlocksmethod. The algorithm iterates over the incoming edges of the Subsystem. Since each In port ofthe Subsystem has exactly one incoming edge, the iteration identifies each port only once. Thisidentification is accomplished by the GetInEdges method. The algorithm also determines the sourceblock of the edge, this block must store the edge information. Moreover, the method determines theactual port the edge is connected to as well. In this manner the corresponding Inport block can bedetermined. At this point the algorithm iterates through the outgoing edges of the Inport block. Ateach iteration, it determines the block connected to an edge, the target block. In this manner thesource block has sufficient information to be able to recreate the necessary edge after the flattening.The obtained information is stored in the Tag property of the source block and the processed edge isdeleted. After the inner iteration terminates, the method deletes the edges directed to the In port.

The algorithms described in this section so far are responsible for saving the necessary informationabout the edges related to the Subsystem. In this manner, the connection between its elements canbe reestablished after the blocks are moved to a higher level.

The next set of algorithms perform the actual flattening. These algorithms are responsible forreplacing the elements of a Subsystem, deleting its edges, and finally deleting the Subsystem as well.There are two separate methods responsible for moving the elements inside the Subsystem to a higherhierarchy level. The first one is the MoveToParentLevel method, which is shown in Algorithm 5.This method replaces the elements only if the Subsystem is a child element, that is, the Subsystemis an element of another Subsystem. The parent element is returned by the Parent property of theelements. If this property of a Subsystem is null, then it means the subsystem is not contained byanything, it is at the root level, thus the method terminates. Otherwise, it iterates through all blocksand resets their Parent and Name properties. The Inport and Outport blocks are excluded from theiteration since they are related to the Subsystem element. With the reset of the Parent property theblock is moved out of the Subsystem.

Simulink does not allow two different blocks at the same hierarchy level to have the same name,therefore, all blocks are prefixed with a Subsystem-specific name.

After the MoveToParentLevel method the algorithm calls the MoveToRootLevel. Thismethod moves the contained elements to the root level, that is, set their Parent property to null.Other than setting the Parent attribute to null, the iteration part is the same as it was presentedabove. Note, that the Blocks property of the Subsystem returns an empty list if the elements werealready replaced by the MoveToParentLevel method.

The DeleteContainmentEdges method sets the Parent property of the Subsystem to null. In

15


Algorithm 5 The algorithm that moves the inner blocks of the Subsystem to the parent level1: procedure MoveToParentLevel(Subsystem vs

String prefix)2: parent← vs.Parent3: if parent= null then4: return5: for all actualBlock in vs.Blocks do6: if actualBlock.GetType() < {InBlock,OutBlock} then7: actualBlock.Parent← parent8: actualBlock.Name← prefix+actualBlock.Name9: return

case the connection between the Subsystem and its parent is represented by a containment edge, itis important to delete this edge here.

The last method of this set is the DeleteSubsystem, which deletes the now empty Subsystem.Finally, the algorithm must reestablish the connection between the blocks. The ConnectBlocks

method, depicted in Algorithm 6, is responsible for this. It iterates through the blocks that have edgeinformation stored in their Tag property. Inside this iteration the method performs a new iterationover these items. In this embedded iteration the algorithm creates a new edge based on the actualedge information. After the edge is created, the edge information is removed from the Tag property.In this manner every edge will be recreated for which there is information stored in the blocks.

Algorithm 6 The algorithm that moves the inner blocks of the Subsystem to the parent level1: procedure ConnectBlocks()2: taggedNodes←∀n|n.Tag.Count > 03: for all actualBlock in taggedNodes do4: for all info in actualBlock.Tag do5: actualBlock.CreateEdge(info.ToBlock,

info.PortFrom,info.PortTo)6: actualBlock.Tag.Remove(info)7: return

Once there are no further edges to create, the algorithm has completed the flattening of theSubsystem. Next, the algorithm steps back to the main loop condition to determine whether there areany further Subsystems to process. If there are, the algorithm steps back into the iteration. Otherwise,the algorithm terminates.

Complexity Analysis

In order to use an algorithm in production applications its complexity has to be determined. In thissection the algorithm is examined based on how many times its main parts are called, that is, whichattributes determine its computational complexity, and, thereby, its execution time.

To distinguish the different types of elements contained by or connected to a Subsystem, a numberof sets are introduced. These sets are depicted in Figure 3.2. The different edge and block types arethe following:

• i= {The edges connected to the In ports (the round dotted edges in Figure 3.2).}

• f = {The edges emanating from the Inport blocks out (the square dotted edges).}

16


Figure 3.2: Annotated structure of a Subsystem

• l = {The edges going into the Outport blocks (the dashed edges).}

• r = {The edges contained by the Subsystem that are not part of the f or l sets (the solidedges).}

• o= {The edges connected to the Out ports (the dash dotted edges).}

• e= {All edges related to the Subsystem, that is, i+f + l+ r+o.}

• S = {The blocks connected to the In ports of the Subsystem.}

• I = {The In ports of the Subsystem.}

• IPB = {The Inport blocks of the Subsystem.}

• OPB = {The Outport blocks of the Subsystem.}

• O = {The Out ports of the Subsystem.}

• T = {The blocks connected to the Out ports of the Subsystem.}

• IB = {The other blocks contained by the Subsystem.}

The complexity of the TransFlattener algorithm depends on the complexity of the IsThereVSand ProcessVirtualSubsystem algorithms. The IsThereVS algorithm returns true as long asthere is a virtual Subsystem in the model. However, the complexity of the ProcessVirtualSubsys-tem is more complicated. It contains eight different algorithms that must be examined as well.

The first of these algorithms is ProcessOutPortsAndBlocks. The body of this algorithm isa for loop. The algorithm terminates as soon as there is no unprocessed edge from any Out portrelated to the given Subsystem. Since the edges connected to the Out ports are depicted with o, thecomplexity of the ProcessOutPortsAndBlocks algorithm is O(o).

The next algorithm is ProcessInnerEdges. This algorithm processes all edges in the Subsystemthat are connecting to inner elements. This means that the edges connected to the Inport blocks arenot processed in this step. In this manner the complexity of the method is O(r).

The ProcessInPortsAndBlocks algorithm processes the Inport blocks. Its structure is similarto the ProcessOutPortsAndBlocks algorithm. Although it contains two for loops, practicallyit iterates through the edges connected to the Inport blocks. In this manner the complexity of thisalgorithm is O(f).

17


After the edges are processed, the ProcessVirtualSubsystem algorithm moves to the Move-ToParentLevel algorithm. In case the given Subsystem is a child element of another Subsystemthen it moves each block (except the Inport and Outport ones) to a higher level. This means thatevery block in the IB set is moved out, which results in a complexity of O(IB). In case the Sub-system is at the root level then the replacing is done by the MoveToRootLevel algorithm. SinceMoveToRootLevel moves the same blocks its complexity is the same as MoveToParentLevel.Note, that only one of the algorithms moves the blocks, so the complexity of this part is O(IB) inboth cases.

The next task is the deletion of the Subsystem. This is performed by two algorithms, but boththe DeleteContainmentEdges and DeleteSubsystem algorithm delete at most one element, sotheir complexity can be approximated with O(1).

Finally, the edges must be recreated. This is the responsibility of the ConnectBlocks algorithm.Since the functionality of the model must be maintained, the blocks connected to the In ports musthave an edge to all blocks that were connected to the appropriate Inport blocks. This reasoning is truein case of the blocks connected to the Out ports. In this manner, the number of edges to be createdis f + r+ l. The method applies only these edges, so the complexity of it is exactly O(f + r+ l).

To summarize, considering only Simulink models and exploiting their connectivity restrictions thecomplexity of flattening a virtual Subsystem is O(o+r+f+IB+f+r+ l). Since a Subsystem alwayscontains more edges than blocks (not counting the Inport and Outport blocks), this equals to O(e).

Since the complexity of the IsThereVS method is O(1) the complexity of the algorithm in case ofSimulink models can be reduced to O(nvs ∗e), where nvs represents the number of virtual Subsystemscontained by the model.

3.2.2 The TransFlattener Transformation

This section introduces and discusses the details of the transformation TransFlattener that pro-cesses Simulink models and flattens their virtual subsystems.

Functionality of the Transformation

For a better understanding the final control flow is presented first, which is shown in Figure 3.3. Thismodel defines how the transformation rules follow one another.

At first, the transformation checks if there is a virtual Subsystem block in the model. So theRW_Matlab_TagVirtualSubsystem transformation rule attempts to match a simple Subsystemblock that has the IsVirtualSubsystem attribute set to true. If the transformation engine does notfind a match for this rule, then there is no virtual Subsystem in the model, thus the transformationterminates. Otherwise, the transformation steps into the loop that processes this Subsystem.

In Simulink, a block cannot be directly connected to a block on a different hierarchical level.When a block is moved out from a Subsystem, it loses all its edges automatically. This means thatthe transformation must take into account the connections between the blocks, and must take care ofcreating the necessary edges. Moreover, when a Subsystem is flattened, the Inport and Outport blocksof the Subsystem are deleted. So the transformation also must ensure that the blocks connected tothe appropriate ports will be connected to each other after the processing.

The Inport and Outport blocks represent the input and output ports of the Subsystem. Each portof the Subsystem is associated with an appropriate block in the Subsystem. For example if a Subsystemhas two input ports and three output ports, then there are two Inport and three Outport blocks inthe Subsystem, and these blocks have a reference number to the port they belong to∗. This behavioris presented in Figure 3.10.

∗This work does not consider the “port reuse” feature of Simulink, which allows multiple Inport blocks for a singleinput port.

18


Figure 3.3: The control flow of the TransFlattener transformation

In the aforementioned loop, which is responsible for processing the virtual Subsystem, the firstapplied rule is the RW_Matlab_Flattener_Get_OutEdges transformation rule. It is depictedin Figure 3.4. In order to handle the deletion of the ports this rule attempts to find matches foroutgoing edges of a Subsystem and deletes them if a match is found. Upon deletion, the identifier ofthe block connected to the Out port of the Subsystem (the toNode in Figure 3.4) and the port numberthat the edge is connected to are stored in the appropriate Outport block (the endNode in Figure 3.4).

After processing outgoing edges from all Subsystem type nodes, the transformation moves to thenext transformation rule: RW_Matlab_Flattener_OutBlock (Figure 3.5). This rule matchesblocks that have outgoing edges to an Outport block and if a match is found deletes the edge con-necting them. It also copies the information stored in the Outport block into the matched block (thesimpleNode in Figure 3.5) and extends this with the port number where the edge starts. This waythis block contains all the information about the edges that the transformation must create after theblock is moved out of the Subsystem. This information consists of the followings:

• The port number the edge starts from

• The identifier the edge is connected to

• The port number the edge ends at

• The necessary attributes of the edge

19


Figure 3.4: The transformation rule RW_-Matlab_Flattener_Get_OutEdges

Figure 3.5: The transformation rule RW_-Matlab_Flattener_OutBlock

Figure 3.6: The transformation rule RW_-Matlab_Flattener_GetAllEdges

Figure 3.7: The transformation rule RW_-Matlab_Flattener_InBlock

In the previous two steps the transformation focused on the blocks connected to the Out portsand Outport blocks of the Subsystem. The next rule embodies the same functionality for every blockin the Subsystem. The RW_Matlab_Flattener_GetAllEdges rule is depicted in Figure 3.6.It does not differentiate based on the type of the block, which means that it matches Inport blocks aswell as the blocks processed previously (i.e., the ones connected to the Outport blocks). The reason forthis is the possibility that a block may have multiple outgoing edges and the transformation requiresinformation about each edge. The rule is matched for each element in the Subsystem exactly once andstores all information about their outgoing edges.

After the first three rules of the loop, every block of the Subsystem contains the relevant informa-tion about their outgoing edges. Moreover, the blocks connected to the Outport blocks contain whichblocks are connected to the appropriate Out port as well. This means that the transformation candelete the edges inside the Subsystem, so if a block is moved out of it, then no dangling edges remains.The rule RW_Matlab_Flattener_DeleteEdges does just that (i.e., deletes the edges betweenthe blocks of the Subsystem).

In the next step the transformation processes the blocks connected to In ports. The transformationrule RW_Matlab_Flattener_InBlock is shown in Figure 3.7. It matches the incoming edgesof Subsystem nodes and if a match is found deletes them. As it has been mentioned, the RW_-Matlab_Flattener_GetAllEdges rule matches Inport blocks as well, so these elements containthe necessary information about their edges. In this manner the current rule can copy this information

20


Figure 3.8: The transformation rule RW_-Matlab_Flattener_ParentLevel

Figure 3.9: The transformation rule RW_-Matlab_Flattener_ConnectBlocks

to the blocks connected to the appropriate In ports. The information is also extended with the portnumber of the edge directed from the block to the Subsystem. Upon completion of this rule the blocksconnecting to the Subsystem know the characteristics of the edges that the transformation must createafter the Subsystem is deleted.

At this point the blocks related to the Subsystem store the necessary information about theiroutgoing edges. The transformation also deleted the edges connecting to the Subsystem and theones between its blocks. This means that the blocks are ready to be moved to a higher hierarchicallevel. The transformation rule RW_Matlab_Flattener_ParentLevel looks for the "parent"Subsystem. If it finds a match, then the blocks contained by the processed Subsystem, except theInport and Outport blocks, are placed into the parent. The rule is depicted in Figure 3.8. If theprocessed Subsystem still contains elements besides the Inport and Outport blocks after this rule,then it means, that the Subsystem is not contained by anything, it is at the root level. So the RW_-Matlab_Flattener_RootLevel rule must delete only the Containment typed edges betweenthe Subsystem and its blocks. In this manner all of the blocks that were originally in the Subsystemare now not contained by anything, they are moved to the root level as well.

Next, the transformation can safely delete the Subsystem. However, it cannot leave any danglingedges, so if it was contained by another Subsystem, then the transformation must delete the Contain-ment edge after which the Subsystem is deleted.

Finally, the transformation must recreate the edges between the moved blocks. This is basedon the information stored in the blocks. The transformation rule RW_Matlab_Flattener_-ConnectBlocks creates the necessary edges (Figure 3.9). The block storing the information is thesource block; the identifier provides the target block. The appropriate ports are also saved along withother relevant information.

With this rule the loop ends and the transformation returns to the RW_Matlab_Flattener_-TagVirtualSubsystem transformation rule, which checks for another virtual Subsystem. If there isone, then the engine steps into the loop again, otherwise it terminates.

Analysis of the Transformation

The previous section has presented the transformation TransFlattener and its rules. Before itsuse, it is important to analyze the transformation properties. This section summarize the propositionsthat can be verified.

The coverage of Proposition 3.2 and Proposition 3.3 is depicted in Figure 3.10. This picture mayalso help illustrate the relation of the different blocks.

21


Figure 3.10: The coverages of the first two propositions regarding the structure of a Subsystem

Definition 3.1 (inner elements). The inner elements of a Subsystem are all elements, except theInport and Outport typed blocks, contained by the Subsystem.

Proposition 3.2. After the transformation TransFlattener, the inner elements of the processedSubsystem are connected if and only if they were connected before the transformation.

Proof. Three transformation rules (RW_Matlab_Flattener_OutBlock, RW_Matlab_-Flattener_GetAllEdges and RW_Matlab_Flattener_ConnectBlocks are responsiblefor the connection between the blocks. First, the RW_Matlab_Flattener_OutBlock deletesthe edges pointing to the different Outport blocks, which represent the Out ports of the Subsystem. Therule also stores the identifiers of the blocks that had an edge pointing from the same Out port. (Theidentifiers of these blocks are already stored in the Out block because of the RW_Matlab_Flat-tener_Get_OutEdges rule.) Next, the RW_Matlab_Flattener_GetAllEdges stores foreach block the identifier of those blocks that the given block has an edge pointing to. It also storesthe details of the edges, that is, from which port point to which port. The rule examines every blockexactly once. Next, the other rules of the transformation place the elements onto a higher level in thehierarchy. Since it is not possible in Simulink that elements in different hierarchy level are directlyconnected, it is ensured that after the replacing there is no edge pointing to or from the moved block.The transformation also deletes all edges between the inner elements to avoid the dangling edges.Finally, when the elements of the Subsystem are already placed onto a higher hierarchical level, theRW_Matlab_Flattener_ConnectBlocks creates the edges based on the stored informationfor each block. Since this is the only rule that generates edges and does this based on the storedinformation in the different blocks, there will be no new edges between the inner elements of theSubsystem. Note that the information about the edges is stored for each and every inner element thathas outgoing edges, thus these edges will be regenerated.

In this manner the inner elements of the Subsystem are connected if and only if they were connectedbefore the transformation execution. �

In order to not change the functionality of a Simulink model it is required that after the trans-formation a block is in the transitive closure of another block if and only if it was in the transitiveclosure of the other block before the transformation.

22


Since the transformation cannot modify the functionality of a processed model, the following arerequired by the transformation:

• Let o denote the set of blocks outside of the Subsystem that have an outgoing edge to a givenIn port. Let i denote the set of inner elements that are connected to the Inport block relatedto the given In port. With this notation, after the transformation all elements in o must havean edge connected to all elements in i.

• Regarding the Out ports the same requirements can be stated. Let o denote the set of blocksoutside of the Subsystem that have an incoming edge from a given Out port; and i denote theset of inner elements that are connected to the Outport block related to the given Out port. Inthis case, after the transformation all elements in i must have an outgoing edge to all elementsin o.

Proposition 3.3. After the transformation TransFlattener deletes the ports of the processedSubsystem the functionality of the Simulink model does not change.

Proof. The RW_Matlab_Flattener_Get_OutEdges and the RW_Matlab_Flattener_-OutBlock transformation rules are responsible for not changing the functionality of the model whenthe Out ports are removed. First, the RW_Matlab_Flattener_Get_OutEdges rule storesinformation in each Out block. This information contains the identifier of the blocks to which anyedges point from the appropriate Out port. Moreover, the port attributes of these edges are also stored.The rule also deletes these edges. Next, the RW_Matlab_Flattener_OutBlock attempts tomatch those edges that are pointing from one of the inner elements of the Subsystem to one of theOutport blocks. For every match, the rule deletes the edge and copies the information stored in theOutport block to the matched element. It also extends this information with the number of the portfrom where the matched edge starts. With the help of these two transformation rules it is ensured thatthe blocks that have outgoing edges to one of the Outport blocks possess the proper information. Theproper information means the identifiers of the block, where the edges from the appropriate Out portpoint to. The edges based on this information will be recreated by the RW_Matlab_Flattener_-ConnectBlocks rule after the elements are placed to a higher hierarchical layer.

To ensure that the functionality of the model remains the same in case of the In ports, tworules are needed as well. These rules are the RW_Matlab_Flattener_GetAllEdges and theRW_Matlab_Flattener_InBlock. As it was described in the proof of the Proposition 1, theRW_Matlab_Flattener_GetAllEdges rule stores for each and every block, so for the Inportblocks as well, to which port of which blocks it has outgoing edges. Next, the RW_Matlab_-Flattener_InBlock matches each edge that points from a block outside of the Subsystem to oneof its In ports. The rule deletes this edge, since after deleting the Subsystem there cannot be anydangling edge. The rule also copies the stored information from the appropriate Inport blocks to thematched block and extends it with the number of the port the matched edge starts from. With the helpof these two transformation rules it is ensured that the blocks, which have outgoing edges to one ofthe In ports, have the information, where the appropriate Inport block has outgoing edges. The edgesbased on this information will be created by the RW_Matlab_Flattener_ConnectBlockstransformation rule after the elements are placed into a higher hierarchical layer.

It can thus be stated that after eliminating the ports of the Subsystem the functionality of theSimulink model does not change. �

Consequence of Proposition 3.3: The number of the edges in the Simulink model changes asfollows:

∑(−si−fi+(si ∗fi))+

∑(−so− lo+(so ∗ lo)), where si represents the number of edges going

into the ith In port of the Subsystem, fi represents the number of edges emanating from the ith Inportblock, so represents the number of edges emanating from the oth Out port of the Subsystem and lomeans the number of edges going into the oth Outport block.

23


Proposition 3.4. Proposition 3.2 and Proposition 3.3 together state that all inner elements of theprocessed Subsystem are connected if and only if they were connected before the iteration and thefunctionality of the model does not change. Considering the two propositions it can be stated, that thefunctionality of the model does not change after the Subsystem is flattened.

Proof. The proof follows from the proofs of Proposition 3.2 and Proposition 3.3. �

Proposition 3.5. Each iteration of the transformation TransFlattener moves the inner elementsof the processed Subsystem exactly one level higher.

Proof. The RW_Matlab_Flattener_ParentLevel and the RW_Matlab_Flattener_-RootLevel transformation rules are responsible for this behavior. The RW_Matlab_Flat-tener_ParentLevel attempts to find a match, where the processed Subsystem is a child elementof another Subsystem. If such a match is found then the rule deletes the Containment edge betweenthe processed Subsystem and its inner elements and also creates a Containment edge between theparent Subsystem and the aforementioned inner elements. If there is no match for this rule, then itcan be stated that the processed Subsystem is at the root level. So the RW_Matlab_Flattener_-RootLevel rule simply deletes the Containment edges of the processed Subsystem. This means thatits inner elements are moved to the root level. Neither of these two transformation rules match forthe Inport and Outport blocks of the Subsystem. �

Definition 3.6 (execution hierarchical levels). The execution hierarchical levels are levels creatednot for purely graphical purpose, but have a bearing on execution semantics.

This means that since the virtual Subsystems are created to help organize and understand themodels and do not have any additional role, the execution hierarchical levels are created only bynonvirtual Subsystems.

Proposition 3.7. The transformation TransFlattener does not move elements between executionhierarchical levels.

Proof. The RW_Matlab_TagVirtualSubsystem is the first rule of the transformation. The ruleattempts to match virtual Subsystems. At the beginning of each iteration, a virtual Subsystem is taggedas the Subsystem under processing. As a consequence, only the elements of a virtual Subsystem aremodified during the actual iteration. As a consequence none of the objects of a non-virtual Subsystemare moved to a higher hierarchical level. �

Proposition 3.8. The transformation TransFlattener flattens all virtual Subsystems.

Proof. The RW_Matlab_TagVirtualSubsystem transformation rule is the first rule of the iter-ation: This rule expresses the loop condition. At each time the rule is evaluated, it attempts to matcha virtual Subsystem. If such a match is found then the found Subsystem will be processed. The otherrules of the iteration move the inner elements of this Subsystem onto a higher hierarchical layer andalso delete this Subsystem. None of the rules creates any type of Subsystems. This means that everyiteration decreases the number of virtual Subsystems by one in the model. The iteration continuous tillthe RW_Matlab_TagVirtualSubsystem cannot find a successful match anymore. This meansthere are no remaining virtual Subsystems in the model. �

Proposition 3.9. The transformation TransFlattener always terminates.

Proof. To examine the termination of the transformation the following must be checked:

• The control flow cannot go into an infinite loop,

24


• The transformation rules, which are applied exhaustively, terminate in finite steps.

The control flow terminates if the RW_Matlab_TagVirtualSubsystem rule cannot find amatch. This happens if and only if there are no virtual Subsystems in the model. In case thereis no virtual Subsystem in the model at the starting point, the transformation terminates withoutstepping into the iteration. Otherwise a match is found and the transformation steps into the loop.Proposition 3.8 states that the transformation flattens all virtual Subsystem. Since in Simulink theSubsystems cannot be recursively defined (i.e. the containment loops are forbidden) there are finitelymany Subsystems in the model. This means that after finite number of iteration there will be noremaining virtual Subsystems in the model, so the RW_Matlab_TagVirtualSubsystem rulecannot find a successful match anymore, thus the control flow terminates.

In the transformation each rule is applied exhaustively except the RW_Matlab_TagVirtual-Subsystem rule. The exhaustively applied rules must be checked whether they terminate in finitesteps:

• RW_Matlab_Flattener_Get_OutEdges rule: This rule matches an edge between theOut port of a Subsystem and other blocks. If a match is found the rule deletes this edge. Thismeans that every application of the rule reduces the number of edges between the Out portsand other blocks, thus after finites steps it cannot be applied anymore.

• RW_Matlab_Flattener_OutBlock rule: This rule works by the same principle. The onlydifference between the two rules is that this one attempts to match an edge between an innerelement and the Outport block of the Subsystem. The deletion of the matched edge, withoutcreating any new, ensures its termination.

• RW_Matlab_Flattener_GetAllEdges rule: This rule marks the matched block at eachapplication. After several steps there is no remaining unmarked inner element in the Subsystem.Since there is a condition in the LHS of the rule that the block cannot be marked before therule is applied, the system cannot find a match.

• RW_Matlab_Flattener_DeleteEdges rule: The rule simply matches an edge betweenthe blocks of the Subsystem and if a match is found deletes it. After finite steps there are noedges left between the blocks, and the rule cannot be applied.

• RW_Matlab_Flattener_InBlock rule: This rule is equivalent to the RW_Matlab_-Flattener_Get_OutEdges, but this one operates between the In ports and the Subsystem.It deletes the matched edges as well, therefore cannot be applied after a certain number of steps.

• RW_Matlab_Flattener_ParentLevel rule: The rule matches and deletes the contain-ment edge between an inner element and the actual Subsystem. It is irrelevant that it createsa new edge between the parent Subsystem and the inner elements, since the LHS of the rulechecks containment edges between the actual Subsystem and other blocks. This ensures that therule cannot be applied indefinitely.

• RW_Matlab_Flattener_RootLevel rule: The rule simply deletes the containment edgebetween the actual Subsystem and its inner element. The deletion of the matched item withoutcreating any new items ensures its termination.

• RW_Matlab_Flattener_Delete_ContEdge rule: The principle is the same. The ruleattempts to match a containment edge between the actual Subsystem and a parent one. If itsucceeds, then it deletes this edge.

25


• RW_Matlab_Flattener_Delete_Subsystem rule: The rule deletes the actual Subsys-tem. The LHS checks that the Subsystem must be marked. This marking occurs in the RW_-Matlab_TagVirtualSubsystem rule, which is applied exactly once before every iteration.In this manner there is only one element that can be a match for this rule.

• RW_Matlab_Flattener_ConnectBlocks rule: The rule matches blocks that store infor-mation about edges to create. After the rule creates such an edge, it removes the informationfrom the block. Since the RW_Matlab_Flattener_GetAllEdges rule was applied for afinite number of times and this is the only transformation rule that stores information aboutthe edges to create, the RW_Matlab_Flattener_ConnectBlocks rule will be appliedfor a finite number of times as well.

Since both the control flow and the transformation rule terminate after finite number of steps, thetransformation terminates as well. �

3.3 Generating the Sorted List3.3.1 The Trans_SL Algorithm

It was previously discussed that Simulink creates the Sorted List based on the dependency of theelements. This work limits its scope to the large class of data dependencies (i.e., control dependenciesare not considered). In terms of data dependencies, a block b depends on a block a if the directfeedthrough (DF) property [Sim, 2012b] on its inport block obtaining the signal from a is set to true.In this case block a must appear before block b in the Sorted List. Else, there is no dependency, thatis, the output of the block b with the input port can be computed without knowing the value onthe input port. In this manner, there generally are many lists that satisfy the dependencies and thesemantics are invariant to the selected list.

At this phase of the processing, the virtual subsystems of a Simulink model have already beenflattened, and, therefore, only nonvirtual subsystems remain. Nonvirtual subsystems are, for example,the Enabled Subsystem, Triggered Subsystem, Atomic Subsystem, Function-call Subsystem, and others.These nonvirtual subsystems have their own Sorted List with the same principle discussed above.

The nonvirtual subsystems are treated as opaque blocks (in terms of execution) at the hierarchicallevel where they are present and so the input ports of a nonvirtual subsystem also are endowed with theDF attribute. The setting of this attribute is inferred from the content of the nonvirtual subsystem.Generally, for each input port of the nonvirtual subsystem the DF is set to be same as the DFattribute of the first block that the input connects to internally (to the nonvirtual subsystem). Notethat more sophisticated analyses may be applied to resolve some DF issues, as presented in otherwork [Denckla and Mosterman, 2004a, Mosterman and Ciolfi, 2004a].

It has to be mentioned that the scope of the algorithm presented here is limited in that it does notpertain to models with algebraic loops. An algebraic loop represents a strongly connected subgraphin the data dependency graph [Tarjan, 1972].

A model and a Sorted List generated based on the transformations presented in this section isdepicted in Figure 3.11. Note that in this model the Subsystem block is nonvirtual, and, therefore,cannot be flattened. As a result the Sorted List becomes of a hierarchical nature. The 0 : x conveysthat x is the position of the block in the Sorted List for hierarchical layer 0 (with 0 being the top).Similarly, 2 : y conveys that y is the position of the block in the Sorted List for hierarchical layer 2,which is chosen the same as the position of the block with the hierarchical layering in its parent’sSorted List. For example, 5 : 0 Gain conveys that the Gain block is at the first position for hierarchicallayer 5, which relates to the Subsystem element.

26

3.3. Generating the Sorted List

The main part of the Sorted List generation algorithm is shown in Algorithm 7. The Trans_SLalgorithm contains a Repeat-Until control structure with three algorithms. These three algorithms areresponsible for processing the blocks.

Algorithm 7 The algorithm of the transformation Trans_SL1: procedure Trans_SL()2: repeat3: ProcessFirstBlocks(null)4: until not ProcessSubsystem(null)

and not ProcessNormals(null)5: return

The three algorithms differ from each other in the type of block that they process. First, theProcessFirstBlocks algorithm processes only blocks without any incoming edge. Since withoutincoming edges a block cannot depend on any other block, the processing of these blocks does notrequire the examination of the DF properties. The ProcessFirstBlocks algorithm is presented inAlgorithm 8.

Algorithm 8 The algorithm of processing blocks without incoming edges1: procedure ProcessFirstBlocks(Subsystem sub)2: while ProcessBlock(sub, true) do3: DeleteBlocksAndEdges()4: return

The ProcessFirstBlocks algorithm obtains a parameter, which sets the actual subsystem thatcontains the blocks that are being processed. In case the current hierarchical level is the root of themodel, then the parameter is null. The ProcessFirstBlocks algorithm contains a while block. The

(a) The root level (b) The subsystem

(c) A possible Sorted List

Figure 3.11: A Sorted List for a model

27


condition of this loop is the return value of the ProcessBlock algorithm, which is responsible forthe processing itself. In case there was at least one block without incoming edges, the ProcessBlockreturns true and the DeleteBlocksAndEdges algorithm is called. Since the DeleteBlocksAnd-Edges deletes the processed blocks and their edges, the next time the ProcessBlock algorithmis called, there may be new blocks without incoming edges. If there is no such block, the algorithmterminates.

Algorithm 9 The algorithm of block processing1: procedure ProcessBlock(Subsystem sub, Boolean onlyF irsts)2: Boolean processedAny← false3: Block parent← null4: if sub not null then5: parent← sub6: for all b|b ∈ SimpleBlocks∧ b.Parent= parent∧ b.Tag , ”Processed” do7: if (onlyF irsts∧ b.Sources= ∅)∨ (¬onlyF irsts∧@e|e ∈ b.Source∧e.DF = true) then8: print CalculateIndent() + b.Name9: b.Tag = ”Processed”

10: if not processedAny then11: processedAny← true12: return processedAny

The ProcessBlock algorithm is shown in Algorithm 9. It has two parameters: the sub setsthe actual subsystem, while the onlyF irsts parameter determines whether only the blocks withoutincoming edges should be processed. Since each nonvirtual subsystem is basically an opaque block forexecution purposes, it has its own Sorted List. Therefore, if this parameter is set to a subsystem, thenonly those blocks should be processed that are contained by this subsystem. This containment canbe checked by the examination of the Parent property of the block to be processed. The algorithmonly processes “simple” blocks, it is referred to blocks that are not composite elements. Moreover, theInport and Outport blocks of the subsystems should not be processed, therefore, they are not part ofthe SimpleBlock set.

If the onlyF irsts parameter is set to true, the algorithm processes only the blocks without anyincoming edge, that is, the Sources property is empty. Otherwise, if the onlyF irsts parameter isfalse, the algorithm must check if the DF properties on the port of the incoming edges are set to false.

The actual processing of a block is straightforward. The CalculateIndent method determinesthe actual indent and position of the block. These values depend on the hierarchical level and thenumber of previously processed blocks. The name of the block is appended to the calculated value.After the list is maintained the algorithm depicts the block as “Processed”. If the algorithm processedat least one block, then it returns true.

As it was mentioned before, the DeleteBlocksAndEdges algorithm deletes the processedblocks and its edges. It is depicted in Algorithm 10.

After there are no remaining primitive blocks left in the model without incoming edges, theTrans_SL algorithm proceeds to process possible subsystems. This is achieved by the Process-Subsystem algorithm shown in Algorithm 11. Since it is possible in Simulink that a subsystemcontains another subsystem, the algorithm obtains the current subsystem as a parameter. If it is setto null then the algorithm attempts to identify a subsystem at the root level. The return value of theCheckForSubsystem algorithm determines if there is any processable subsystem on the given hier-archical level. If there is any, then it is stored in the newSub variable, and processed in a repeat-untilloop.

This loop is the same as the one in the Trans_SL algorithm but it has three additional commands.First, this algorithm sets the processedAny variable to true, which will be the return value. Next,

28


Algorithm 10 The algorithm of deleting processed elements1: procedure DeleteBlocksAndEdges()2: for all b|b ∈Blocks∧ b.Tag = ”Processed” do3: for all e ∈ b.InEdges do4: e.Delete()5: for all e ∈ b.OutEdges do6: e.Delete()7: b.Delete()8: return

it calls the DeleteBlocksAndEdges to delete the already processed elements if there are any.After this, the ProcessInOutPorts algorithm deletes the Inport and Outport blocks and the edgesconnecting to them. This is necessary, since the Sorted Lists do not contain these blocks. After thesesteps, the ProcessSubsystem algorithm processes the blocks in the same manner as the Trans_SLalgorithm. As it can be seen in the Algorithm 11, the ProcessSubsystem algorithm can be calledrecursively, in case the subsystem contains another subsystem. The algorithms are called with thenewSub parameter as the current hierarchical level.

Algorithm 11 The algorithm of processing a Subsystem1: procedure ProcessSubsystem(Subsystem sub)2: Subsystem actualSub← sub3: Subsystem newSub← null4: Boolean processedAny← false5: if CheckForSubsystem(actualSub,newSub) then6: repeat7: processedAny← true8: DeleteBlocksAndEdges()9: ProcessInOutPorts(newSub)10: ProcessFirsts(newSub)11: until not ProcessSubsystem(newSub) and not ProcessNormals(newSub)12: newSub.Tag = ”Processed”13: return processedAny

In order to determine if there is any processable Subsystem on the current hierarchical level, theCheckForSubsystem algorithm is used. The algorithm is shown in Algorithm 12. A Subsystem isprocessable, if it is contained by the appropriate parent element and does not have any input portwith the DF property set to true. In case the algorithm finds such a Subsystem, then it assigns theSubsystem to the newSub variable and returns true. Otherwise, the return value is false.

Algorithm 12 The algorithm of checking processable Subsystem1: procedure CheckForSubsystem(Subsystem actSub, Subsystem newSub)2: if ∃s|s ∈ Subsystems∧s.Parent= actSub∧@e|e ∈ s.Sources∧e.DF = true then3: print CalculateIndent() + s.Name4: newSub← s5: return true6: return false

As it was mentioned before, the Inport and Outport blocks of the Subsystem are not part of theSubsystem. Therefore, their outgoing edges should be deleted without processing the blocks, as it is

29


depicted in Algorithm 13. Note, that a nonvirtual Subsystem is only processable if none of its In portshas its DF property set to true. In case of virtual Subsystems this restriction does not hold, but thevirtual Subsystems must be flattened before the processing of the Sorted List begins. This makes itpossible to delete all edges connected to the Inport blocks.

Algorithm 13 The algorithm of processing edges related to In- and Outport blocks1: procedure ProcessInOutPorts(Subsystem sub)2: for all b|b ∈ InBlocks∧ b.Parent= sub do3: for all e ∈ b.OutEdges do4: e.Delete()5: for all b|b ∈OutBlocks∧ b.Parent= sub do6: for all e ∈ b.InEdges do7: e.Delete()8: return

The ProcessNormals algorithm (Algorithm 14) is called from the repeat-until block as well.This algorithm is responsible for processing those blocks that have an arbitrary number of incom-ing edges but none of its input ports has a DF property with a value of true. It is similar to theProcessFirstBlocks algorithm but calls the ProcessBlock algorithm with different parameter.

Algorithm 14 The algorithm of processing blocks with incoming edges1: procedure ProcessNormals(Subsystem sub)2: if ProcessBlock(sub, false) then3: DeleteBlocksAndEdges()4: return true5: return false

Note the condition of the until block in the Trans_SL algorithm. The algorithm continues inthe loop if either the ProcessSubsystem or the ProcessNormals algorithm returns true. In otherwords this means that either of these two algorithms processes at least one element. In this case, afterthe deletion of the related edges, there may be new, processable blocks. Otherwise, if there are noSubsystems and no primitive blocks to process, then either all elements have been processed or thereis an algebraic loop in the current hierarchical level. The Trans_SL algorithm terminates if thiscondition is met in the root level, that is, no elements are left in the model or there is an algebraicloop.

Complexity Analysis of the Trans_SL Algorithm

In order to use an algorithm in production applications its complexity must be established. In thissection the algorithms are examined based on their execution time. Therefore, the attributes thatdetermine their computational complexity must be determined.

To determine the complexity of the Trans_SL algorithm, the following algorithms must beexamined (the rest of the algorithms call these ones):

• ProcessBlock

• DeleteBlocksAndEdges

• CheckForSubsystem

• ProcessInOutPorts

30


The ProcessBlock algorithm is called from the ProcessFirstBlocks and the ProcessNor-malBlocks algorithms. This is the one and only algorithm that processes “simple” blocks. On theone hand, since the Sorted List must contain all of these blocks, the body of the ProcessBlockalgorithm is executed at least nsb times, where nsb means the number of “simple” block on thecurrent hierarchical level. On the other hand, since each processed block is deleted by the Delete-BlockAndEdges algorithm, the ProcessBlock algorithm is executed at most nsb times. Assume,that the complexity of the CalculateIndent method is O(1). In this manner, the complexity ofthe ProcessBlock algorithm is O(nsb).

The DeleteBlocksAndEdges algorithm deletes all processed elements and their edges. Basedon the previous reasoning, all “simple” blocks are processed, therefore the for loop in the algorithm isexecuted at least sb times. However, the algorithm is also called after a Subsystem is processed. Letnb denote the sum of the “simple” blocks and the Subsystem blocks. In this case the aforementionedfor loop is run exactly nb times. At each iteration the algorithm deletes the related edges as well.Assume, that the complexity of a deletion is O(1). In this manner, the complexity of the algorithmis O(nb ∗ (ei+eo)), where ei represents the average number of incoming edges to a processed elementand eo represents the average number of outgoing edges from a processed element. Let es denote alledges connected to either a “simple” block or a Subsystem. In this manner, the complexity of theDeleteBlocksAndEdges algorithm is O(nb+es), every element and edge is deleted exactly once.

The CheckForSubsystem algorithm simply examines whether there is a processable Subsystem.If there is, then the algorithm assigns it to the newSub variable, and adds it to the Sorted List withthe help of the CalculateIndent method. Therefore, the complexity of the algorithm is O(ns),where ns means the number of Subsystems in the model.

Finally, the ProcessInOutPorts algorithm deletes all edges connected to the Inport or Outportblocks. In this case the complexity of the algorithm is O(eio), where eio represents the edges connectedto the Inport or Outport blocks.

To summarize, the complexity of the Trans_SL algorithm is O(nsb+nb+es+ns+eio), which isequal to O(2∗nb+es+eio). Let e denote all edges in the model, that is, the sum of es and eio. In thismanner, the complexity of the algorithm is O(2∗nb+e), that is, each block (“simple” or Subsystem) isprocessed exactly once and all edges with the processed blocks are deleted. Since a Subsystem alwayscontains more edges than blocks (not counting the Inport and Outport blocks), this equals to O(e).

3.3.2 The Trans_SL Transformation

As it was mentioned, a control flow determines the application order of the rules. The control flow ofthe Trans_SL transformation is shown in Figure 3.12.

At first, the transformation attempts to apply the RW_Matlab_ProcessFirstBlocks rule.This transformation rule matches for “simple” blocks, which have no incoming edges, therefore theydo not depend on any other block. If a match is found, then the imperative code part of the rulewrites out the name of the block with the necessary indentation, hierarchical level, and positioning.In this manner, the CalculateIndent method of the ProcessBlock algorithm is implementedvia imperative code.

The rule is applied exhaustively, that is, as long the transformation finds an unprocessed “simple”block without incoming edges, and each processed block is tagged as “Processed”. In case there was atleast one successful match, the transformation moves to ProcessOutgoingEdges_1 rule container,which applies the RW_Matlab_ProcessEdges rule (depicted in Figure 3.13). This rule attemptsto find matches of the outgoing edges from the already processed elements and deletes them.

After there are no edges left to delete, the RW_Matlab_DeletePrcessed transformationrule (shown in Figure 3.14), which is contained by the DeleteProcessedBlock_1 rule container,deletes the appropriate elements.

31


Figure 3.12: The control flow of the Trans_SL transformation

Figure 3.13: The transformation rule RW_-Matlab_ProcessEdges

Figure 3.14: The transformation rule RW_-Matlab_DeleteProcessed

These three transformation rules are applied exhaustively, this way imitating the behavior of aforeach or while loop. The RW_Matlab_ProcessFirstBlocks implements the ProcessBlockalgorithm with the parameter list of (null, true); and the RW_Matlab_ProcessEdges with theRW_Matlab_DeleteProcessed correspond to the DeleteBlocksAndEdges algorithm. Al-though the transformation does not delete any incoming edges related to the processed elementsunlike the DeleteBlocksAndEdges algorithm, this is not necessary here, since these blocks do nothave any incoming edges. Moreover, since the transformation moves to the RW_Matlab_Process-FirstBlocks after deleting the already processed elements, the while loop of the ProcessFirst-Blocks algorithm is implemented as well.

When the application of the RW_Matlab_ProcessFirstBlocks transformation rule was un-successful, the transformation moves along the dashed grey line of the control flow, which leads tothe RW_Matlab_CheckForSubsystem rule. As it is shown in Figure 3.15, the rule attempts tofind a match for a Subsystem, an Inport block and an ordinary Block. In Simulink, the DF propertyis an attribute of the In port of the blocks. However, in VMTS, this property is moved, and is acharacteristic of the edges. In this manner, a Subsystem is processable, if the DF property of theFirstEdge edge (the edge starting from the Inport block) is set to false. In case such a Subsystem isfound, it is written out with the help of the imperative code, and the transformation starts processingits elements.

This processing starts with deleting the edges connected to the Inport and Outport blocks. Thesedeletions are accomplished in the RW_Matlab_TagTheInBlocks (depicted in Figure 3.16) andRW_Matlab_TagTheOutBlocks, respectively. The first rule may create blocks without anyincoming edge, which means they are independent from any other block. The latter is only necessaryto avoid any dangling edges after the transformation terminates.

32


Figure 3.15: The transformation rule RW_-Matlab_CheckForSubsystem

Figure 3.16: The transformation rule RW_-Matlab_TagTheInBlocks

Figure 3.17: The transformation rule RW_Matlab_ProcessFirstInSubsystem

The next three transformations are similar to the first three. The RW_Matlab_Process-FirstInSubsystem rule (contained by the ProcessFirstInSubsystem rule container), which isshown in Figure 3.17, processes the blocks without incoming edges. These blocks must be containedby the found Subsystem element, which is the only difference between this rule and the RW_-Matlab_ProcessFirstBlocks. In case the RW_Matlab_ProcessFirstsInSubsystem ruleis applied at least once, the transformation executes the same rules to delete the edges and blocks asin the beginning of the process. The application of a new rule container is necessary though, sincethe transformation now must move to the RW_Matlab_ProcessFirstInSubsystem instead ofthe RW_Matlab_ProcessFirstBlocks.

When there is no other processable block without incoming edges, the transformation attemptsto find a match for the RW_Matlab_CheckForSubSubsystem (presented in Figure 3.18) trans-formation rule. This rule basically attempts to find a Subsystem element inside the current one.Therefore, the applied rule is very similar to the already described one, the only difference is thepresence of a parent Subsystem, which needs to be the current one.

In case the transformation found a processable inner Subsystem, the transformation then startsto process with the already presented RW_Matlab_TagTheInBlocks rule. This is essentially

33


Figure 3.18: The transformation rule RW_-Matlab_CheckForSubSubsystem

Figure 3.19: The transformation rule RW_-Matlab_FinishSubSubsystem

the implementation of the recursive CheckForSubsystem algorithms in a model transformationenvironment.

However, if there is no processable inner Subsystem, the transformation attempts to process theremaining blocks with the help of the RW_Matlab_ProcessNormalInSubsystem rule. This ruleis exactly the same as the RW_Matlab_ProcessFirstInSubsystem but it allows the matchedblocks to have incoming edges, if their DF properties are set to false. In case the transformation pro-cessed any block here, then it moves to the RW_Matlab_ProcessIncomingEdges rule, whichdeletes the incoming edges of the processed elements. Next, the transformation returns to the RW_-Matlab_ProcessEdges rule. This structure corresponds to the repeat-until block of the Check-ForSubsystem algorithm.

In case there are no blocks to process in the actual Subsystem, the transformation applies theRW_Matlab_FinishSubSubsystem (shown in Figure 3.19) and RW_Matlab_FinishSubsys-tem rules. These are the exit points of the recursion and tag the found Subsystem as “Processed”.If the first rule can be matched, then it means that there was an inner Subsystem and the currentSubsystem must be set back to its parent. After this, the edges connected to this processed Subsys-tem and then the Subsystem itself is deleted. The transformation continues with the processing of theparent Subsystem. In case the second rule is matched, then it means the transformation returns tothe root level again. The applied transformation rules are the same, but the transformation returnsto the RW_Matlab_ProcessFirstBlocks instead of its equivalent rule in the Subsystem level.

The transformation terminates when there is no processable element in the root level. This meansthat the RW_Matlab_ProcessNormalBlock transformation rule does not find any match.

Analysis of the Trans_SL Transformation

First, the functionality of the transformation is examined and then its further attributes, such astermination and correctness, are verified.

Definition 3.10. The simple elements of a Simulink model are all elements, that are neither acomposite element (e.g. Subsystems) nor a mandatory element of a composite element (e.g. Inportand Outport block of a Subsystem).

34


Before the transformation is examined in detail, note, that the transformation rules can be dividedinto two parts. The first part consists of the following:

• RW_Matlab_ProcessFirstBlocks

• RW_Matlab_ProcessEdges

• RW_Matlab_DeletePrcessed

• RW_Matlab_ProcessIncomingEdges

• RW_Matlab_CheckForSubsystem

• RW_Matlab_FinishSubsystem

• RW_Matlab_ProcessNormalBlock

These transformation rules process the simple elements and find Subsystems on the root level.The second group contains the following:

• RW_Matlab_ProcessFirstInSubsystem

• RW_Matlab_ProcessEdges

• RW_Matlab_DeletePrcessed

• RW_Matlab_ProcessIncomingEdges

• RW_Matlab_CheckForSubSubsystem

• RW_Matlab_FinishSubSubsystem

• RW_Matlab_ProcessNormalInSubsystem

The rules contained by the second group behave exactly the same way as the ones in the first, butthey processes the elements in deeper levels. The transformation rules match the same pattern withthe exception of matching a parent Subsystem as well. So the reason behind the existence of the rulesin the second group is the need of parent matching.

By the examination of the transformation we assume there is no algebraic loop in the model.

Proposition 3.11. After the transformation Trans_SL, all simple elements and Subsystems of theSimulink model are processed, therefore they are contained by the Sorted List. These elements areprocessed exactly once.

Proof. The RW_Matlab_ProcessFirstBlocks transformation rule processes all simple elementswithout incoming edges. Throughout the process, its imperative code implements the Calculate_-Indent method, which inserts the block into the Sorted List in the appropriate format. Each processedelement is marked as “Processed”. Both the RW_Matlab_ProcessEdges and RW_Matlab_-DeletePrcessed rules match these marked blocks and delete their outgoing edges, moreover, therules delete the blocks themselves. This may results in other blocks without incoming edges, thereforethe RW_Matlab_ProcessFirstBlocks may be applicable again.

When these rules cannot be applied anymore, it means, that a nonvirtual Subsystem is in the way(which require special treatment) or there is a directed cycle in the model. If a Subsystem is found, theRW_Matlab_CheckForSubsystem rule puts the element into the list and the transformationstarts processing the elements of the Subsystem. This is achieved by the rules corresponding tothe ones on the root level, therefore they are not discussed in more detail. After a Subsystem is

35


processed, the transformation marks it as “Processed” and moves on to delete their edges, and finallythe marked Subsystem as well. The processing of the model continues with the RW_Matlab_-ProcessFirstBlocks again.

In case there is a directed cycle, the RW_Matlab_ProcessNormalBlock looks for blockswhich have none of their incoming edges marked with a DF property set to true. If the application ofthe rules was successful, then the rule inserts the found elements into the Sorted List and marks themas “Processed”. In this case, the transformation moves on to the rules responsible for deleting therelated edges. In case, however, the application of the rule is unsuccessful, then the transformationterminates. This means that either there are no elements left in the model, or there are no elementsleft without having at least one incoming edges with the DF property set to true. The first case meansthat the transformation successfully processed all simple elements of the model. However, the lattercase means that there is an algebraic loop in the Simulink model. Since it was assumed, there is noalgebraic loop in the source model, the transformation cannot come to this result. In this manner,the transformation terminates if and only if there is no element left to process. �

Proposition 3.12. The transformation Trans_SL processes the elements of the Simulink model inan appropriate order, that is, a block a is always processed later, than a block b, on which a is depend.

Proof. There are three rules on the root level, which insert elements into the Sorted List:

• RW_Matlab_ProcessFirstBlocks, which processes only simple blocks without any in-coming edges. A block without incoming edges does not depend on any other blocks, thereforeit can be placed into the Sorted List. If a block a had an incoming edge e with the DF propertyset to true, but this edge e has been deleted after processing its source block b, then it means,a is now processable, since its dependency has been processed already. In this manner, this rulecannot insert any block into the Sorted List, that has any unprocessed dependency.

• RW_Matlab_CheckForSubsystem, which processes Subsystem elements without incom-ing edges, or Subsystem elements with incoming edges with DF property set to false. Theseconditions ensure that the Subsystem is processable at the moment, it has no unprocesseddependency.

• RW_Matlab_ProcessNormalBlock, which has the same conditions:

1. The processed block has no incoming edges,2. The processed block has incoming edges, but none of them has its DF property set to true.

In this manner, these rules never insert any block into the Sorted List, that has any unprocesseddependency. These rules have their pairs in the Subsystem level, which behave the same in thisregard. This means, the transformation Trans_SL processes the elements of the Simulink model inan appropriate order. �

Proposition 3.13. The Sorted List created by the transformation Trans_SL is a valid Sorted Listfor the input Simulink model.

Proof. Proposition 3.11 states that every simple element is processed by the transformation, andProposition 3.12 state that the elements are processed in the right order. This means that the SortedList created by the transformation Trans_SL is a valid Sorted List of the model, since it containsall relevant elements in an appropriate order. �

Proposition 3.14. The transformation Trans_SL always terminates.

Proof. In order to prove the transformation always terminates, the following two statements have tobe proved:

36


1. Each transformation rule is applied only a bounded number of times,

2. The transformation does not contain any infinite loop.

In VMTS the application mode of a transformation rule is set to either “Once” or “IsExhaustive”.In case the rule is applied “Once” then after the transformation attempts to apply the rule, it moves onto the next rule. The result of the application defines only the direction of the movement. Therefore,these rules are only applied a bounded number of times.

However, this is not the case when the application mode is set to “IsExhaustive”. In this case thetransformation attempts to apply the LHS of the rule as long as there is a corresponding pattern inthe host graph. In this manner, it has to be checked whether the rules applied in this way terminates.These rules are the following:

• The RW_Matlab_ProcessFirstBlocks, where the rule attempts to match unprocessedsimple elements. Since it marks the elements as “Processed” after each application, the ruleis applied at most n times, where n means the number of simple elements in the Simulinkmodel. The Simulink models contain only a bounded number of blocks, therefore the numberof application of the rule is always bounded.

• The RW_Matlab_ProcessEdges rule attempts to match processed simple elements with atleast one outgoing edge, and deletes the matched edge. A block must have a bounded numberof edges, therefore the rule cannot be applied indefinitely.

• The RW_Matlab_DeletePrcessed rule is applied to process simple elements. Since therule deletes the matched block, and a Simulink model has a bounded number of blocks, the ruleis applied only bounded number of times.

• The RW_Matlab_ProcessIncomingEdges rule attempts to match processed elements withat least one incoming edge. Since the rule is the same as the RW_Matlab_ProcessEdges,but with incoming edges, the reasoning is analogous.

• The RW_Matlab_TagTheInBlocks, where the rule attempts to match Inport blocks anddeletes their outgoing edges. A Subsystem must have a bounded number of Inport blocks andan Inport block must have a bounded number of outgoing edges, the rule is applied a boundednumber of times.

• The RW_Matlab_TagTheOutBlocks is similar to the RW_Matlab_TagTheIn-Blocks, but it attempts to match Outport blocks with incoming edges. The same reasoningcan be applied here as well, that is, the Subsystem must have a bounded number of Outportblocks and an Outport block must have a bounded number of incoming edges. Therefore, therule is applied a bounded number of times.

• The RW_Matlab_ProcessFirstInSubsystem rule is the pair of the RW_Matlab_Pro-cessFirstBlocks rule at a deeper level. Since it looks for the same pattern with the extensionof a parent element, the same reasoning can be applied here as well.

Based on the previous, none of the rules in the Trans_SL can be applied an indefinite numberof times.

Now, it has to be checked, that the transformation does not contain infinite loops. It can bestated, that none of the transformation rules create any new element, that is no new edges or blocksare created throughout the process. However, every processed element (and its edges) is deleted by theappropriate rule. Since the Simulink model contains a bounded number of elements, the processingrules, and the related rules deleting elements, can be applied only a bounded number of types.

37


Furthermore, in Simulink models the number of Subsystems that can be used is limited andhierarchies of Subsystems cannot be created in a recursive manner. Moreover, it is not possible tocreate a hierarchy, where Subsystem SA contains Subsystem SB and SB also contains SA. Withthese restrictions it is ensured that the application of the RW_Matlab_CheckForSubsystemtransformation rule cannot lead to an infinite loop because each found Subsystem will be processedand deleted.

In this manner, since none of the transformation rules can be applied indefinitely and the transfor-mation does not contain an infinite loop, it is proven that the transformation always terminates. �

3.4 Propagating Data Types3.4.1 The Trans_TypeProp Algorithm

Whenever a simulation is started, the Simulink software performs a processing step called data typepropagation. This step involves determining the data types of signals whose data type is not otherwisespecified and checking the data types of signals and input ports to ensure that they do not conflict.If type conflicts arise, an error dialog is displayed that specifies the signal and port whose data typesconflict. The signal path that creates the type conflict is also highlighted [Sim, 2012c].

Blocks can inherit data types from a variety of sources, including signals to which they are con-nected and particular block parameters. In case the data type of a block is not set to a built-in datatype, or to an expression that evaluates it, then the type is calculated by inheritance. To this end,the data type of the block is marked as “Inherit: <rule>”, where the rule determines the mode ofthe inheritance. It can be, for example, via back propagation, or same as the input, etc. The aim of adata type propagation algorithm is to determine the data types of these blocks and revise the typesbased on the signal on the input port of the blocks.

The algorithm presented in this section performs these modifications. The Trans_TypePropalgorithm can be separated into two parts. The first part, the SetTypes algorithm sets the datatypes of the blocks, where the value of the data type is inherited. Next, the second part of it, which isthe VerifyTypes algorithm, verifies the data types, and if it is necessary, it changes the type basedon the value of the connected signals.

The SetTypes algorithm (shown in Algorithm 15) is responsible for setting the data types of theblocks that have this attribute set to “Inherited”. This procedure requires four different steps. First,it is possible to set the data types of the Constant blocks. Next, the base method of the SetTypesalgorithm sets the data type attribute of the appropriate blocks based on the data type of the previousblocks. Since the data type propagation through hierarchical levels may affect the applicability of thisrule, a repeat-until control structure is implemented in the algorithm, and the propagation throughthe hierarchical levels is realized in the until block. Moreover, since there is no guarantee that datatypes of the blocks without incoming edges are set properly, the algorithm must set the data typesof these blocks as well.

Algorithm 15 The algorithm of the transformation SetTypes1: procedure SetTypes()2: SetConstantType()3: repeat4: SetNextInherit()5: until not SetFirstInSubsystem() and not SetTypeNextToSubsystem() and not Set-

PreviousInherit()6: return

38

3.4. Propagating Data Types

Throughout the design of these algorithms, the existences of certain sets were assumed. These arethe following:

• The InheritConstants set contains all Constant blocks, which have the data types calculatedthroughout inheritance.

• The InheritSimpleBlocks set contains all non-composite elements (i.e. no Subsystems), whichhave the data types calculated throughout inheritance.

• The ConcreteSimpleBlocks set consists of the non-composite element, which have the datatype set to a built-in type.

• The InheritInportBlocks set contains all Inport blocks, which have the data types calculatedvia inheritance.

• The InheritOutportBlocks set contains all Outport blocks, which have the data types calculatedthroughout inheritance.

• The Subsystems set consists of all Subsystem elements in the model.

• The SimpleBlocks set contains all elements in the model but the Subsystems.

Based on these sets, the SetConstantType algorithm iterates through the InheritConstantsset, and calls the SetTypeBasedOnValue method on each item. This method sets the data typeattribute to the appropriate value based on the value of the Constant block.

After all Constant block is typed into a specific built-in type, the SetTypes algorithm startssetting the data-type of the non-composite elements. In the body of the aforementioned repeat-untilblock there is only one algorithm, the SetNextInherit. This is shown in Algorithm 16. This al-gorithm is responsible for the data type propagation on the same hierarchical level. In this manner,the algorithm iterates over all block pairs, where both blocks are non-composite elements and theyare connected. On one hand, the data type of the source block must be set to a built-in data type,therefore this block is an element of the ConcreteSimpleBlocks set. On the other hand, the datatype of the target block must be calculated throughout inheritance (otherwise there is no data typeto set), so it is part of the InheritSimpleBlocks set. At each iteration step, the algorithm sets theOutDataTypeStr attribute of the target block to the value of the same attribute of the source block.In Simulink, the value of data type of the actual element is stored in this attribute.

Algorithm 16 The algorithm of the transformation SetNextInherit1: procedure SetNextInherit()2: for all a|a ∈ ConcreteSimpleBlocks,b|b ∈ InheritSimpleBlocks∧ b ∈ a.Targets do3: b.OutDataTypeStr = a.OutDataTypeStr4: return

In case these block pairs are all set, the occurrence of data type propagation across hierarchicallevels must be identified. The SetFirstInSubsystem algorithm, which is depicted in Algorithm 17,is responsible for this behavior. The algorithm looks for block pairs, where the source block is part ofthe ConcreteSimpleBlocks and the target is a Subsystem, and iterates through these pairs. In thenext step, the algorithm checks, whether the data type of the appropriate Inport block is calculatedthrough inheritance. The appropriate Inport block is selected based on the Port numbers. The edgeshave the information about which port of the blocks they are connected to. This information is storedin the PortFrom and PortTo properties, respectively. The Port properties of the Inport and Outportblocks represent the port number of the Subsystem, they get or send their signals. This way the

39


Algorithm 17 The algorithm of the transformation SetFirstInSubsystem1: procedure SetFirstInSubsystem()2: Boolean processedAny← false3: for all e|e.Source ∈ ConcreteSimpleBlocks,s|s ∈ Subsystems∧s= e.Target do4: if ∃i|i ∈ s.InheritInportBlocks∧ i.Port= e.PortTo then5: a← e.Source6: i.OutDataTypeStr = a.OutDataTypeStr7: if not processedAny then8: processedAny← true9: return processedAny

connection of the blocks can be examined. In case the data type of the appropriate Inport block iscalculated via inheritance, the algorithm set it to the value of the data type of the source block.

The data type propagation must be implemented on the opposite direction as well. In this manner,the data type of the Outport block of a Subsystem is set, and the data type of the appropriate blockconnected to this port of the Subsystem is calculated. The SetTypeNextToSubsystem algorithm(shown in Algorithm 18) handles these situations, and sets the OutDataTypeStr attribute to thevalue of Outport block’s.

Algorithm 18 The algorithm of the transformation SetTypeNextToSubsystem1: procedure SetTypeNextToSubsystem()2: Boolean processedAny← false3: for all e|e.Target ∈ InheritSimpleBlocks,s|s ∈ Subsystems∧s= e.Source do4: if ∃o|o ∈ s.ConcreteOutportBlocks∧o.Port= e.PortFrom then5: a← e.Target6: a.OutDataTypeStr = o.OutDataTypeStr7: if not processedAny then8: processedAny← true9: return processedAny

Finally, as it was mentioned, there are cases, where the data type of a block cannot be calculatedvia propagation in this direction. In these cases, the data type is set based on the value of thenext block. The SetPreviousInherit algorithm is responsible for this behavior. As it is shown inAlgorithm 19, this algorithm differs from the SetNextInherit algorithm in only one aspect: inthis case the source block is from the InheritSimpleBlocks. This way the back-propagation can beaccomplished as well.

Algorithm 19 The algorithm of the transformation SetPreviousInherit1: procedure SetPreviousInherit()2: Boolean processedAny← false3: if a|a ∈ ConcreteSimpleBlocks,b|b ∈ InheritSimpleBlocks∧ b ∈ a.Sources then4: b.OutDataTypeStr = a.OutDataTypeStr5: if not processedAny then6: processedAny← true7: return processedAny

In case any of the three algorithms in the until statement returns true, the SetTypes algorithmapplies the SetNextInherit again. Otherwise, the algorithm terminates, and the Trans_Type-Prop algorithm moves on to the type verification part.

40


This verification part is contained by the VerifyTypes algorithm, shown in Algorithm 20. Itsstructure is very similar to the SetTypes algorithm, that is, it uses a repeat-until control structurein which it attempts to verify the data types of the connected block and the until block contains theverification throughout the hierarchical levels.

Algorithm 20 The algorithm of the transformation VerifyTypes1: procedure VerifyTypes()2: repeat3: VerifySimpleBlock()4: until not VerifyFirstInSubsystem() and not VerifyNextToSubsystem()5: return

The VerifySimpleBlock algorithm (depicted in Algorithm 21) checks every edge that connectsto non-composite elements. At each edge, the algorithm calls the CompatibleTypes method with thesource and target blocks as parameters. This method determines whether the data types of the blocksare compatible. In case they are, the algorithm does not modify them. Otherwise, the data type ofthe target block is set to the data type of the source block. The non-compatibility in this algorithm isinterpreted to effect arithmetic overflow. For example, if a block a has an incoming edge from a block,which has the OutDataTypeStr attribute set to int32, this a block cannot have its OutDataTypeStr setto, for example, int16. These conversion rules are implemented in the CompatibleTypes method. Ifany of the rules are violated by the blocks that are passed in as parameters, the algorithm, as it wasmentioned, modifies the data type of the target block to the data type of the source block. Since thealgorithm should not overwrite the manually added data type conversions (represented by Convertblocks), the target block of the edge cannot be a Convert element.

Algorithm 21 The algorithm of the transformation VerifySimpleBlock1: procedure VerifySimpleBlock()2: for all e|e.Source ∈ SimpleBlocks∧e.Target ∈ SimpleBlocks∧e.Target is not Convert do3: a← e.Source4: b← e.Target5: if ¬CompatibleTypes(a,b) then6: print b.Name−a.OutDataTypeStr7: b.OutDataTypeStr← a.OutDataTypeStr8: return

As the data types are propagated through hierarchical levels, the verification accomplished thisfeature as well. The VerifyFirstInSubsystem algorithm, which is shown in Algorithm 22, is verysimilar to the already discusses SetFirstInSubsystem algorithm. However, instead of checkingwhether the data type of the appropriate Inport block is calculated or not, this time its compatibilityis checked regarding to the block connecting to the Subsystem. In case there is a compatibility issue,the algorithm modifies the OutDataTypeStr attribute.

The last discussed algorithm is the VerifyNextToSubsystem, which is depicted in Algo-rithm 23. This algorithm responsible for the verification in the other hierarchical direction. Thistime the data type of the appropriate Outport block is examined. In case it is not compatible to thedata type of the block b connecting to the Subsystem, then OutDataTypeStr attribute of the b blockis modified.

As can be seen, the verification part of the algorithm relies heavily on the capability of theCompatibleTypes method. In case either the VerifyFirstInSubsystem or the VerifyNextTo-Subsystem algorithm returns true, the VerifyTypes algorithm must step into the repeat controlstructure again, since there may be new edges that meet the condition in the VerifySimpleBlock

41


Algorithm 22 The algorithm of the transformation VerifyFirstInSubsystem1: procedure VerifyFirstInSubsystem()2: Boolean processedAny← false3: for all e|e.Source ∈ SimpleBlocks,s|s ∈ Subsystems∧s= e.Target do4: a← e.Source5: b← i|i ∈ s.InportBlocks∧ i.Port= e.PortTo6: if ¬CompatibleTypes(a,b) then7: print b.Name−a.OutDataTypeStr8: b.OutDataTypeStr← a.OutDataTypeStr9: if not processedAny then

10: processedAny← true11: return processedAny

Algorithm 23 The algorithm of the transformation VerifyNextToSubsystem1: procedure VerifyNextToSubsystem()2: Boolean processedAny← false3: for all e|e.Target ∈ SimpleBlocks∧ e.Target is not Convert,s|s ∈ Subsystems∧ s = e.Source

do4: a← o|o ∈ s.OutportBlocks∧o.Port= e.PortForm5: b← e.Source6: if ¬CompatibleTypes(a,b) then7: print b.Name−a.OutDataTypeStr8: b.OutDataTypeStr← a.OutDataTypeStr9: if not processedAny then

10: processedAny← true11: return processedAny

algorithm. Otherwise, the two algorithms return false, the VerifyTypes algorithm terminates, and,therefore, the Trans_TypeProp algorithm terminates as well.

3.4.2 The Trans_TypeProp Transformation

The control flow of the Trans_TypeProp transformation, which implements the propagation algo-rithm, is shown in Figure 3.20.

The first thing one may recognize on the control flow is the number of directed cycles in themodel. These directed cycles implement the repeat-until control structures of the algorithms. In caseone of the transformation rules, which represent the until conditions in the algorithm, successfullyfinds at least one match, the transformation steps back to the transformation rule implementing thefirst statement of the repeat control structure.

Since the data types of the Constant blocks do not depend on any other block, the transformationstarts with setting the OutDataTypeStr attribute of the Constant blocks. This is achieved in theRW_Matlab_SetConstant transformation rule. The rule simply matches the Constant blocks, iftheir OutDataTypeStr attributes are start with “Inherit”. The imperative code of the transformationfinds the appropriate data type for the given value, and assigns it to the attribute. The transformationrule is applied as long as there is a Constant block without explicitly set data type. The model of thetransformation rule is shown in Figure 3.21.

Next, the transformation attempts to propagate the data types in case of blocks on the samehierarchical level. This is the responsibility of the RW_Matlab_SetSimpleBlocks transformation

42


Figure 3.20: The control flow of the Trans_TypeProp transformation

Figure 3.21: The transformation rule RW_Matlab_SetConstant

Figure 3.22: The transformation rule RW_Matlab_SetSimpleBlocks

rule, which is depicted in Figure 3.22. The matched blocks have the following constraints:

• The blocks cannot be composite elements.

• The data type of the source block, depicted as fromBlock in Figure 3.22, must be set explicitly.

• The OutDataTypeStr attribute of the target block, depicted as toBlock in Figure 3.22, must bestart with “Inherit”. As was mentioned, this means, the data type of the block is calculated.

In case the rule find a valid match, the OutDataTypeStr attribute of the target block is updatedwith the data type of the source block. The transformation applies this rule exhaustively, implementingthe propagation as long as possible. Actually, this transformation rule realizes the SetNextInheritalgorithm.

After there are no connected blocks, where the data type propagation can be applied, the trans-formation looks for data propagation through hierarchical levels. Therefore, it attempts to apply theRW_Matlab_SetSubsystemIn transformation rule, which is shown in Figure 3.23. This rule triesto find a match, where:

43


Figure 3.23: The transformation rule RW_-Matlab_SetSubsystemIn

Figure 3.24: The transformation rule RW_-Matlab_SetSubsystemOut

• A simple block is connected to a Subsystem element,

• The data type of the source block, depicted as fromBlock, is explicitly set,

• The Inport block (the inBlock in the Figure) of the Subsystem has its OutDataTypeStr attributeset to a calculated value, that is, it starts with “Inherited”.

In case a match is found with this structure, the rule propagates the data type of the source blockto the Inport block of the Subsystem, realizing the data type propagation through hierarchical levels.

This is the first rule in the transformation, where the applicability of the rule determines the nexttransformation rule. One hand, if the transformation rule was applied successfully, that is, at leastonce, there might be connected simple blocks, where the data type propagation would be appropriate.Therefore, the transformation steps back to the RW_Matlab_SetSimpleBlocks rule. On theother hand, in case the transformation does not find any match with the desired structure, therecannot be new block pairs, where the data type propagation on the same level would be possible.Therefore, the transformation moves on to the RW_Matlab_SetSubsystem_Out rule.

Note, that this is the implementation of the lazy evaluation [Hudak, 1989] of conditional structures.For example, in case the SetFirstInSubsystem algorithm returns true in the until control structureof the SetTypes algorithm, then the condition cannot be evaluated as true, therefore, the executionreturns to the body of the repeat-until control structure, that is, to the SetNextInherit algorithm,without checking the other conditions. This is implemented in the graph transformation-based solutionas well. If the RW_Matlab_SetSubsystemIn rule finds at least one match, then the control flowof the transformation navigates back to the RW_Matlab_SetSimpleBlocks rule.

The other direction of the hierarchical data type propagation is implemented in the RW_Mat-lab_SetSubsystemOut transformation rule. This rule is shown in Figure 3.24. This rule is similarto the one presented before. However, in this case, the rule attempts to find a graph with this structure:

• The direction of the edge between the Subsystem and the simple block is reversed, it leads fromthe Subsystem to the block.

• The data type of the Outport block of the Subsystem, depicted as outBlock, is explicitly set.

• The data type of the target block, depicted as toBlock in the Figure starts with “Inherited”,which means it is calculated.

If a match is found, then the OutDataTypeStr attribute of the target block is set to the samevalue as the data type of the Outport block. Note, that the applicability of the transformation ruledetermines the direction of the control flow as well. In case the rule was applied at least once, the

44


transformation goes back to the RW_Matlab_SetSimpleBlocks rule, otherwise, since there wasno propagation, moves on to the RW_Matlab_SetSimpleBlockBackward transformation rule.

The transformation focuses on the type of data type propagation, where the direction of thepropagation coincides with the direction of the connecting edge. This is called forward propagation.However, in some cases it is unavoidable to change the direction in order to specify the data type of ablock. For this reason, the transformation implements the RW_Matlab_SetSimpleBlockBack-ward transformation rule, which realizes the backward propagation of data types. Note, that thisrule is applied just once. If the match was successful, then the transformation returns to the RW_-Matlab_SetSimpleBlocks transformation rule (Figure 3.22), no matter how many more timesthe backward propagation could be applied. This behavior assigns precedence to forward propagationover backward propagation.

In case the transformation does not find any match for the RW_Matlab_SetSimpleBlocks,the transformation finished with specifying the data type of the blocks, where it would be calculated.However, this does not mean that every block in the model has its data type set explicitly. In casethere was not any block with set data type and there was no Constant block in the model, then thetransformation could not propagate any information. Moreover, since the transformation prefers theforward data type propagation, the backward hierarchical propagation was not implemented, whichmight lead to blocks with unspecified data type.

As the Trans_TypeProp algorithm suggests, after specifying the types of the blocks, theircompatibility should be checked. This is the responsibility of the three transformation rules locatedin the bottom row of the control flow. As for the structure, these three rules realize a lazy evaluatedrepeat-until control structure as well, where the RW_Matlab_VereifySimpleBlocks is the onlyrule in the body of the block.

As for the rules, each of the three rules corresponds with one of the already discussed rule, butwith different imperative code. These pairs are the following:

• The RW_Matlab_VerifySimpleBlock transformation rule corresponds with the RW_-Matlab_SetSimpleBlocks rule,

• The RW_Matlab_VerifyFirstInSubsystem rule falls in with the RW_Matlab_Set-SubsystemIn rule,

• The RW_Matlab_VerifyAfterSubsystem rule corresponds with the RW_Matlab_-SetSubsystemOut transformation rule.

The only differences between the setting and verifying rules are the constraints and the imperativecode.

The constraints have to be different, since at this stage of the transformation it does not look forinherited data types. Moreover, the data types must be explicitly set to examine their compatibility.This compatibility check is implemented via imperative code. If the two data types are not compatible,for example, the data type of the source block is “int32” and the data type of the target block is“int16”, there might be a possible arithmetic overflow. In these cases the transformation modifies theOutDataTypeStr attribute of the target block.

As their names suggest, the RW_Matlab_VerifySimpleBlock transformation rule is respon-sible for the compatible check on connected blocks in the same hierarchical level, and the RW_Mat-lab_VerifyFirstInSubsystem and RW_Matlab_VerifyAfterSubsystem rules implementthis check through hierarchical levels.

Since the direction of the signals correspond to the direction of the edges, there is no need forbackward checking.

It is worth mentioning that a verifying transformation rule is successful if there is at least one blockwhose data type is changed because of compatibility issues. The application of the RW_Matlab_-VerifyFirstInSubsystem and RW_Matlab_VerifyAfterSubsystem rules is not exhaustive.

45


(a) The model before type propagation

(b) The model after the propagation

Figure 3.25: An example for the data type propagation transformation

If either of these rules is applied successfully, the transformation returns to the RW_Matlab_-VerifySimpleBlocks to perform compatibility checks on the affected hierarchical level.

An example of this transformation is depicted in Figure 3.25. The values of the OutDataTypeStrattributes are presented above the blocks. Figure 3.25a shows the source model, where the attributeof the block Sqrt1 is not specified, that is, the value is calculated based on different properties ofthe other elements. The goal of the transformation is to specify the OutDataTypeStr attributes ofthe blocks such as Sqrt1. Because the value of this attribute of the Constant block is set, forwardpropagation is possible. Therefore, the transformation sets the OutDataTypeStr attribute of Sqrt1 todouble. Since there is no other block with unspecified OutDataTypeStr attribute, the transformationmoves on to its verification part. Because the transformation rules responsible for the verification donot find a matching pattern, the verification is completed without further modifying the model. Theresult is depicted in Figure 3.25b.

The Termination of the Trans_TypeProp Transformation

Before applying a graph transformation on a model, some of its properties must be examined. Thetermination of a transformation is definitely one of these important properties.

Proposition 3.15. The transformation Trans_TypeProp always terminates.

Proof. In order to prove the transformation always terminates, the following two statements have tobe proved:

1. Each transformation rule is applied only definite number of times,

2. The control flow of the transformation does not contain any infinite loop.

In VMTS, the application mode of a rule container, which contains the applicable rule, can be setto either “Once” or “Exhaustive”. In case this attribute is set to “Once”, then the VMTS attemptsto apply the rule exactly once and moves on in the control flow based on the result of the matching.Therefore, the transformation cannot apply the rule endlessly.

However, in case the transformation attempts to match a rule exhaustively, an infinite loop mightarise. Therefore, these rules must be examined, in order to avoid their infinite application. In theTrans_TypeProp transformation the following rules are applied exhaustively:

• The RW_Matlab_SetConstant rule sets the OutDataTypeStr rule based on the value ofthe Constant block. Since the constraint of the LHS states, that the OutDataTypeStr attributemust start with “Inherit”, but the rule sets this property to a valid data type, therefore the

46


rule cannot be applied on the matched block again. Considering that a Simulink model alwayscontains only finite number of elements, the rule can be applied only finite number of times.

• The RW_Matlab_SetSimpleBlocks transformation rule set the OutDataTypeStr attributeof a block based on one of its predecessor. In the LHS graph, the OutDataTypeStr attribute ofthe target block must start with “Inherited”. However, the transformation modify the value ofthis attribute to a valid data type. Therefore, this block cannot be matched as target block inthe LHS graph. In this manner, a block can be matched as target block at most once. Since aSimulink model contains finite number of blocks, the rule cannot be applied infinite number oftimes.

• The RW_Matlab_SetSubsystemIn rule is responsible for the data type propagationthrough hierarchical levels. The rule matches Inport blocks, which have their OutDataType-Str attribute set to “Inherit”. After the rule application, the value of the attribute is set basedon the data type of the block connecting to the appropriate port of the Subsystem. Since therule modifies the value of the attribute, which is the applicability condition, an Inport block canbe matched by this rule at most once. Considering the number of block in the Simulink modelis always finite, the rule cannot be applied infinite number of times.

• The RW_Matlab_SetSubsystemOut rule implements the data type propagation throughhierarchical levels as well, but this rule propagates the data type of the Outport block to theblock connecting to the Subsystem on a higher level. The reasoning behind the finite applicabilityof the rule is the same as before: each block can satisfy the constraint of the LHS graph at mostonce, and since there is only finite number of blocks in the model, the rule is applied finitenumber of times.

• The RW_Matlab_VerifySimpleBlocks transformation rule is very similar to the RW_-Matlab_SetSimpleBlocks rule, but it looks for incompatible data types. In case the rulefinds a match, the data type of the target block is modified. However, there might be loops inthe Simulink model, which makes it possible to apply the rule on the very same S (Source) andT (Target) blocks. This occurs, when the OutDataTypeStr of the S blocks is set to a type withbroader range after the first application. In this case, the OutDataTypeStr of the T block ismodified again. However, this cannot be repeated endlessly, since there is only finite number ofdata types in Simulink, and the transformation rule is applied only when the data type of S isbroader the data type of T .

After examining the exhaustively applied transformation rules, the loops must be checked. Boththe first and second part of the transformation implement loops. However, the rules in the firstpart, which set explicitly the data type of the blocks, cannot form an infinite loop. The reason of thisbehavior is the following: Each rule matches exactly one block, whose OutDataTypeStr attribute startswith “Inherit”. This value is then modified by the rule. However, there is no rule in the transformation,which set the OutDataTypeStr attribute to a value, which starts with “Inherit”. Therefore, the rulescannot be applied more that the number of blocks contained by the Simulink model.

This reasoning can be applied to the verification part of the transformation as well, but is mustbe extended. The successful application of either the RW_Matlab_VerifyFirstInSubsystemor the RW_Matlab_VerifyAfterSubsystem might cause the already matched S-T block pairto be matched again by the RW_Matlab_VerifySimpleBlocks rule. This happens, when theapplication of the rules changes the data type of the S block to a data type with broader range. Thisway the data type of the T block is going to change again. However, there are only finite number ofdata types, and the types are never narrowed by any of the transformation. In this manner, the rulescannot form an infinite loop, at some point there will be no incompatible block pairs.

47


Since none of the transformation rules can be applied indefinitely and the transformation doesnot contain any infinite loop, it is proven that the transformation always terminates. �

3.5 Flattened SchedulingIn Section 3.2, a transformation to flatten an entire virtual subsystem was presented. However,there are subsystems for which it may be sufficient to do partial flattening. This is especiallyuseful in case of atomic subsystems because these are nonvirtual, and, therefore, partial flatten-ing reduces the occasions where artificial algebraic loops occur [Denckla and Mosterman, 2004b,Mosterman and Ciolfi, 2004b, Pouzet and Raymond, 2010]. For example, consider a subsystem whereinside a Gain block has its input connected to an In port of the subsystem and its output connectedto a Unit Delay block. It may be practical to move the Gain block out of the subsystem. In partic-ular, unlike a Gain block, a Unit Delay block produces its state as output and so it has no inputdependency. Therefore, a Unit Delay block (and, conversely, the containing subsystem) can be movedanywhere in the execution order whereas a Gain block imposes additional constraints. The transfor-mation presented in this section implements this so-called flattened scheduling.

3.5.1 The FlattenedScheduling Algorithm

The transformation, named FlattenedScheduling, moves blocks out of an atomic subsystem inorder to avoid artificial algebraic loops. The goal of the transformation is to reduce the occasions forpotential algebraic loops while not losing the hierarchical structuring by flatting the entire atomicsubsystem.

Based on these principles, the transformation repeatedly moves blocks out of the atomic subsystemthat match the following requirements:

• They have a direct feedthrough (DF) property.

• They are not connected to a subsystem output, either directly or via other blocks with the DFproperty.

• They have incoming signals exclusively from the inport blocks of the subsystem.

The most interesting condition is the second one, which means there is a need for a specialmechanism that determines whether there is a path with only blocks with the DF property that leadsto an outport block. A possible solution for this problem is the breadth first search technique. At thestart, a set is created that contains only the outport blocks. Then, at each iteration, it is extendedwith the neighboring blocks having the DF property. Once the set cannot be extended with furtherblocks, it is easy to determine whether a block is connected to an output via other blocks with theDF property.

This means that the algorithm first performs the aforementioned breadth first search. Then, itchecks if there is a block that meets all requirements, that is, (i) the block has the DF property,(ii) it is not contained by the set created by the breadth first search, and (iii) it has incoming edgesonly from inport blocks.

If there is such a block, then the algorithm moves it out of the subsystem, and attempts to findother blocks meeting the requirements. In case there is no block to remove, the algorithm terminates.

3.5.2 The FlattenedScheduling Transformation

The control flow of the FlattenedScheduling transformation is depicted in Figure 3.26. As de-scribed in the previous section, the transformation first performs a breadth first search. Instead of

48

3.5. Flattened Scheduling

Figure 3.26: The control flow of the FlattenedScheduling transformation

(a) The rule for the BreadthSearch1 rule container

(b) The rule for the BreadthSearch2

Figure 3.27: The transformation rules related to the breadth first search

maintaining a list or set, the transformation simply tags the appropriate blocks. This search is accom-plished with two transformation rules. The first one, presented in Figure 3.27a, tags all blocks withthe DF property that have outgoing edges to at least one outport block. The second rule, which isdepicted in Figure 3.27b, exhaustively looks for blocks that are connected to already tagged blocks.These two transformation rules tag all blocks that are connected to the outport blocks either directlyor via other blocks with the DF property.

Next, the transformation attempts to find a block that meets the conditions specified in Sec-tion 3.5.1. This is the responsibility of the transformation rule contained by the TagDFBlock rulecontainer, which is shown in Figure 3.28. According to the imperative constraints of the rule, thedfBlock element does not have any incoming edges from any non-inport block while it does have theDF property. If this rule is successfully matched, then the found block (referred to as dfBlock in theremainder of this section) is tagged for processing.

In order to preserve the functionality, the transformation must maintain the edges of the dfBlock.First of all, when the dfBlock is placed outside of the subsystem, it must obtain signals from thesame sources. This means, the transformation must create edges between a block A and the replaceddfBlock if and only if there was an edge between the inport block representing the block A and thedfBlock before the moving. Therefore, the transformation checks from which inport block the dfBlockhas incoming edges. This challenge also appeared in case of the transformation that flattens virtualsubsystems. Since one of the main advantage of the model transformation-based solutions is thattheir transformation rules are reusable, the rule created for that transformation is applicable in thistransformation as well. The necessary modifications were the following: (i) removing the constrainfrom the Subsystem block that implies it is tagged to process, (ii) adding the constraint to the dfBlock

49


Figure 3.28: The transformation rule related to the TagDFBlock rule container

Figure 3.29: The transformation rule related to the CreateInportBlock rule container

that implies it is tagged to process, and (iii) marking the edge directed to the Subsystem block asnot to be deleted. Otherwise, the rule is completely the same, no new elements or logic are added toit.

Moreover, a new inport block must be created to represent the block that was placed outside ofthe subsystem and thus removed from the subsystem. All edges that originate at the dfBlock shouldbe replaced to start out from the new inport block. Therefore, the rule in the CreateInportBlockcontainer (depicted in Figure 3.29) creates a new inport block and tags the appropriate edge that itmust be replaced later. Since the other outgoing edges from the dfBlock must be connected to thisnewly created inport block as well, the transformation tags these edges also. This is the responsibilityof the rule contained by the MaintainInPort container.

When the necessary information is stored, the transformation deletes the edges connected to thedfBlock in the subsystem, and moves the block to the next hierarchical level. In case this next levelis the root level, then only the containment edge between the subsystem and the dfBlock is deleted,otherwise the source of this containment edge is reconnected to the parenting subsystem.

Finally, the transformation recreates the appropriate connections. Since all necessary informationhas been stored in the previous steps, these are straightforward transformation rules. First, the newlycreated inport block is connected to the blocks that remained in the subsystem, then the replaceddfBlock is connected to the subsystem (as it is depicted in Figure 3.30), and finally, the edges guar-anteeing the appropriate input signals are created. This last transformation rule is also reused fromthe transformation flattening virtual subsystems that was designed in previous work. However, in thiscase no modification is needed, the rule is reused in its entirety.

At this point, the block has been successfully replaced. Next, the transformation attempts tofind other blocks to move out of the atomic subsystems. Once it cannot find any proper blocks, itperforms some cleanup activity. Throughout the process, there might be inport blocks that lost allof their outgoing edges. These blocks become meaningless, therefore the transformation deletes these

50

3.5. Flattened Scheduling

Figure 3.30: The transformation rule related to the ConnectSubsystem rule container


Figure 3.31: The source model


Figure 3.32: The model after the transformation

inport blocks and the signals connecting to these subsystem ports.An example of the application of the transformation is shown in Figure 3.31 and Figure 3.32. After

the transformation was applied, the Product and Gain1 blocks were moved out of the Subsystem,because they both have the DF property and feed the Unit Delay1 that does not have this property.The Gain1 block is now connected to the new In7 port. Therefore, the In3 and In4 ports becamemeaningless, and were deleted. However, the Gain block of the Subsystem cannot be moved out,because there is a path from it to the out port (through the Sum blocks) that only contains blockswith the DF properties.

The Termination of the FlattenedScheduling Transformation

Proposition 3.16. The transformation FlattenedScheduling always terminates.

Proof. To examine the termination of the transformation the following must be checked:

• The control flow cannot go into an infinite loop,

• The transformation rules, which are applied exhaustively, terminate in finite steps.

Except for the last two transformation rules, the rules in the control flow implement a loop. Ateach iteration, the transformation places a block outside of the subsystem. This is achieved by the

51


rule applied in either the MoveBlockToRootLevel or the MoveBlockToParentLevel rulecontainer. The iteration condition is examined by the RW_Matlab_PF_TagDFBlock transfor-mation rule applied in the TagDFBlock rule container. The control flow exits the loop if and only ifthe RW_Matlab_PF_TagDFBlock cannot be matched, that is, no blocks meet the conditionsspecified in Section 3.5.1. Since in Simulink the Subsystems contain finitely many Block elements,after finite number of iteration there will be no remaining blocks in the Subsystem that meet thespecified conditions, so the RW_Matlab_PF_TagDFBlock rule cannot find a successful matchanymore, thus the control flow exits the loop.

In the transformation, most of the rules areapplied exhaustively. These rules must be checkedwhether they terminate in finite steps:

• RW_Matlab_PF_BSOut1 rule: The rule marks the unmarked blocks with the DF propertythat have outgoing edges to at least one outport block. Since a Subsystem element contains finitenumber of Block elements, after a finite number of steps there will be no unmarked blocks withDF property in the subsystem.

• RW_Matlab_PF_BSOut2 rule: This rule marks unmarked block with DF property thathave outgoing edges to at least one already marked block. After a finite number of steps therewill be no blocks that can be matched.

• RW_Matlab_PF_ClearInitialTag rule: The rule matches for blocks marked by either theRW_Matlab_PF_BSOut1 or the RW_Matlab_PF_BSOut2 rules and unmarks them.Since these rules were applied finite number of times, this rule is matched finite number of timesas well.

• RW_Matlab_PF_CheckSignals rule: This rule matches for an inport block, a block, andan unmarked edge between them. After storing the necessary information into the inport port,the rule marks the edge as "processed". This way, this edge cannot be matched again by thisrule. After finite steps there are no edges left between the blocks that can be matched, and therule cannot be applied.

• RW_Matlab_PF_MaintainInPort rule: The LHS of the rule contain an unmarked edgestarting from the block to be replaced. After the rule is applied, this edge is marked as "pro-cessed", therefore it cannot be matched again by the rule. This ensures that the rule is matchedfinite number of times.

• RW_Matlab_PF_ProcessInPort rule: The rule matches for the inport blocks that con-tains the information stored by the RW_Matlab_PF_CheckSignals rule. After a successfulmatch, the rule marks the matched inport block as "processed". This way, this inport block can-not be matched again by this rule, and the rule cannot be applied after a finite number ofsteps.

• RW_Matlab_PF_DeleteEdges and RW_Matlab_PF_DeleteEdges2 rule: The rulessimply match an edge connected to the block marked to be replaced, then the rules delete thematched edge. After finite steps there are no edges left connected to the block, and the rulescannot be applied.

• RW_Matlab_PF_ConnectInPort rule: The rule matches the inport blocks that storeinformation about edges to create. After the rule creates such an edge, it removes the informationfrom the inport block. Since the RW_Matlab_PF_CreateInPort and RW_Matlab_-PF_MaintainInPort rules were applied for a finite number of times and these are the onlytransformation rules that store information in inport blocks about the edges to create, theRW_Matlab_PF_ConnectInPort rule will be applied for a finite number of times as well.

52

3.6. Application of Custom Algorithms and Converting Data Types

• RW_Matlab_PF_ConnectSubsystem rule: The rule matches the replaced block that storeinformation about edges to create. After the rule creates such an edge, it removes the informationfrom the block. Since the RW_Matlab_PF_CreateInPort rule is applied only once andthis is the only transformation rule that store information in this block about the edges tocreate, the RW_Matlab_PF_ConnectSubsystem rule will be applied only once.

• RW_Matlab_PF_ConnectDFBlock rule: The rule matches blocks that store informationabout edges to create. After the rule creates such an edge, it removes the information from theblock. Since at this stage of the processing only the information stored by the RW_Matlab_-PF_ProcessInPort rule was not processed, and it was applied for a finite number of times,the RW_Matlab_PF_ConnectDFBlock rule will be applied for a finite number of timesas well.

• RW_Matlab_PF_ClearTag rule: The rule matches any block that are marked in any wayand unmarks them. Since the marking is accomplished by the previous rules, and they wereapplied only finite number of time, this rule cannot be matched more times.

• RW_Matlab_PF_DeletePossibleInPortEdges rule: The LHS of the rule contain anedge between a block and a subsystem. This edge is deleted, when the appropriate inport blockof the subsystem does not have any edges. Since there are finite number of edges in the model,the rule is applied only finite number of times.

• RW_Matlab_PF_DeletePossibleInPorts rule: Similarly, this rule matches inport blockswithout edges and deletes them. Since there are finite number of blocks in the model, the ruleis applied only finite number of times.

Since both the control flow and the transformation rule terminate after finite number of steps, thetransformation terminates as well. �

This section introduced a model transformation, which is a suitable solution to reduce the potentialfor artificial algebraic loops in a model. The next section presents how model transformations supportdesign aspects in a technical sense (data type assignment) as well as in an organizational sense(providing specific algorithmic implementations of functionality).

3.6 Application of Custom Algorithms and ConvertingData Types

Changing data types from floating point to fixed point is an important design step for many Simulinkusers. For example, users may wish to convert all doubles into signed integers of 16 bits (int16) and allsingles into signed integers of 8 bits (int8). Futhermore, a Boolean type may be converted to unsignedintegers of 8 bits (unit8), where on certain architectures it is quicker to fetch an 8 bit word over a 1bit value (which would technically suffice for a Boolean).

An important implication of converting to a fixed point data type is that the functionality of blocksmay also have to be transformed. With the help of model transformations, the blocks can be easilytransformed as well. For example, to compute the square root of a value, Simulink relies on a particularalgorithm, which in fixed point may be more delicate and important to capture explicitly at the modellevel. Thus, it is possible that in the process of transforming data types blocks may be replaced inaddition. In particular, Simulink uses its internal algorithms for fixed point approximations, but usersmay want to explicitly insert their own. This is not uncommon in the Electronics Design Automationindustry, where such an algorithm may be provided as an Intellectual Property (IP) block that isdirectly implemented in hardware.

53


Figure 3.33: Transformation rule replacing the square root blocks

This section presents a transformation that converts the data types of the blocks from floatingpoint into a fixed-point representation. Then, the transformation replaces square root blocks with thefirst two or three iterations of the Babylonian method. The number of inserted iterations is determinedbased on the data type of the square root block.

The transformation converts the data type with the help of a transformation rule. In this case,the rule matches for blocks whose data type is either double, single, or Boolean. If a match is found,then the transformation changes the data type to int16, to int8, or to uint8, respectively.

In order to replace the square root blocks, the transformation performs two rules, exhaustively. Thefirst rule matches for Sqrt blocks, where the OutDataTypeStr attribute is set to Int16 or UInt16. In thiscase, the matched block is replaced with blocks representing the first two iterations of the Babylonianmethod. If there are no further such Sqrt blocks, the engine moves on to the second transformationrule. This rule, depicted in Figure 3.33, matches for every square root elements without consideringtheir OutDataTypeStr attributes, deletes their edges and the block itself, then inserts the new setof blocks, which represents the first three iteration of the Babylonian method, into the place of thematched blocks. In this manner, if a Sqrt block has the OutDataTypeStr attribute set to Int16 orUInt16, then the block is replaced with the first two iterations of the Babylonian method, otherwisewith the first three iterations.

The transformations can form a chain as well, that is, the output of the first transformation canserve as the input model of the second transformation. Figure 3.34 shows an example, the transfor-mation presented in this section is applied to the model in Figure 3.25 that resulted from the datatype propagation transformation. The OutDataTypeStr attributes of the blocks are depicted over theblocks. First, the transformation converts the float data types into fixed points. Figure 3.34a showsthe result of this transformation rule. Then, the transformation replaces the Sqrt blocks. Note, thatthe corresponding custom algorithms are different for the Sqrt blocks, since their OutDataTypeStrattributes are different. The final model is presented in Figure 3.34b.

Note that more advanced methods can be used to replace the square root blocks, the purpose ofthis transformation rule is to demonstrate the utility.

The previous two sections presented new transformations to demonstrate how convenient the mo-del transformation can be with respect to manipulating Simulink models. The next section examineshow the application order of two already presented transformation affects the efficiency.

3.7 Examining the Efficiency of the Application OrderAs it was mentioned, both the flattening transformation and the type propagation transformationmodify the source model. Since the flattening transformation does not change the functionality of the

54

3.7. Examining the Efficiency of the Application Order

(a) The model after changing data types

(b) The model after applying the custom algorithms

Figure 3.34: The models after applying the transformations

source model, it can be applied before or after other transformations, in principle, without affectingthe resulting functionality. Therefore, the application order of the transformations is arbitrary.

However, the arbitrary application order does not mean that one order is not more efficientthan the other. It was concluded in the consequence of the Proposition 3.3 that after the flatteningtransformation, the number of edges in the Simulink model changes as follows: E∆ =

∑(−si− fi +

(si ∗ fi)) +∑

(−so− lo+ (so ∗ lo)). This means that the edges directed into the In ports and Outportblocks as well as the edges directed out of the Inport blocks and Out ports are deleted. In place of thedeleted edges, the transformation creates new edges to ensure the same functionality of the model.

Over the course of applying the data type propagation transformation, the processing of a sub-system takes place as follows. First, the data types of the Inport blocks are calculated based on oneof the relations of the related In port. Then, the neighbors of the Inport blocks are processed. Insidea subsystem, the data type propagation follows the already described logic, which leads to settingthe data types of the Outport blocks. Finally, the data types of the neighbors of each Out port arecalculated based on the data type of the related Outport blocks.

In a worst case scenario, no blocks have their data type set, there are no blocks having signals frommultiple Inport blocks, and there are blocks having signals from multiple Out ports. In such a worstcase scenario the data type propagation transformation applies

∑(1 +fi) +

∑(1 + lo) transformation

rules.The second part of the data type propagation transformation, the verification, also deals with

subsystems. In this case, the worst case scenario means that every edge connected to the In/Out portsand Inport/Outport blocks of the subsystem must be verified. This means

∑(si+fi)+

∑(so+ lo) rule

application.

55


In case the virtual subsystems are flattened before the execution of the type propagation trans-formation, then in a worst case scenario, the newly created model parts, that is, the newly creatededges, must be processed twice (once for determining the data type and once for the verification).This means, the transformation applies the appropriate rules 2∗ (

∑(si ∗fi) +

∑(so ∗ lo)) times.

In this manner, if 2 ∗ (∑

(si ∗ fi) +∑

(so ∗ lo)) <∑

(1 + fi) +∑

(1 + lo) +∑

(si + fi) +∑

(so + lo),that is 2 ∗ (

∑(si ∗ fi) +

∑(so ∗ lo)) <

∑(1 + 2 ∗ fi + si) +

∑(1 + 2 ∗ lo + so), then the execution of the

transformations is more efficient when the flattening transformation is executed first.To validate the role of the application order, the transformations were applied in different order on

a model with average complexity. The model has 174 blocks, from which 15 are virtual subsystems and15 are atomic subsystems. Each of the virtual subsystems has 2 In and 1 Out ports. The experimentalresults are shown in Table 3.1.

Table 3.1: Experimental results regarding to the application order

Executiontime (s)

Matchattempts (pc)

Successfulmatches (pc)

Flattening on the base model 161 614 433Type propagation on the base model 46 121 108Flattening on the type propagated model 166 614 433Type propagation on the flattened model 32 77 64

This means that the engine attempts to apply 36.36% (1− 77121) less transformation rules over the

course of applying the data type propagation transformation, in case the model is already flattened.The number of the successful matches decreases even more, with 40.74% (1− 64

108). Of course, thenumber of rule application required to flatten the source model does not change, since the flatteningdoes not depend on whether the data type of the blocks are determined. Figure 3.35 shows the resourcerequirements of the different cases. It can be seen, how the model on which the transformations areapplied affects the execution time of the transformation, the amount of the applied transformationrules, and the number of the successfully matched rules. Figure 3.36 depicts these resources in casethe flattening transformation is applied first, and the data type propagation transformation is appliedon the modified model (blue columns), and in case the data type propagation is the first appliedtransformation, and the model is flattened secondly (orange columns). Finally, in Figure 3.37 theblue columns show, how the required resources changes when the flattening transformation is appliedon the data type propagated model compared to the case, when the flattening transformation is thefirst one. The orange columns show that applying the data type propagation transformation on theflattened model requires far less resources compared to the other order.

3.8 Experimental ResultsTo test their behaviour, the presented model transformations were applied on various Simulink mo-dels. This section presents a number of paradigmatic examples to illustrate the functionality of thetransformations.

3.8.1 Flattening

One of these source models the TransFlattener transformation was applied to is depicted inFigure 3.38. The root level is shown in Figure 3.38a. This model contains a virtual Subsystem withone In port and two Out ports. The inner structure of this Subsystem is shown in Figure 3.38b. It

56

3.8. Experimental Results

Figure 3.35: The resource requirements of the transformations


57



(a) The root level of the SimulinkR© model(b) The model contained by the first Subsystem

(c) The containment of the nested Subsystem

Figure 3.38: The example Simulink R© model for the TransFlattener transformation

58


Figure 3.39: The model after the TransFlattener transformation

can be seen that each Inport/Outport block relates to exactly one In/Out port. This hierarchical levelalso contains a virtual Subsytem, which is presented in Figure 3.38c.

After the transformation TransFlattener terminates, the structure of the model changes, asit is shown in Figure 3.39. All inner elements were moved to the next level, and eventually, sincethe model did not contain any nonvirtual Subsystem, to the root level. The Subsystem blocks weredeleted with their Inport and Outport blocks. The connection within the blocks were correctly main-tained. The example also demonstrates that the transformation correctly processes an Out port of avirtual Subsystem that is connected to multiple blocks, which is a prerequisite to not changing thefunctionality of the source model.

In order to improve readability the position of the blocks was set up manually after the transfor-mation terminated. By default, the flattened blocks retain their relative positions.

3.8.2 Sorted List

Figure 3.40 shows an example Simulink model to which the Trans_SL transformation was applied.The top level of the model is depicted in Figure 3.40a and the elements contained by the nonvirtualSubsystem are shown in Figure 3.40b. It is a small example that contains only one nonvirtual Subsys-tem, and a number of primitive elements. The transformation was examined on more complex modelsas well, and produced the expected results.

The transformation for the model in Figure 3.40b resulted in the correct Sorted List depicted inFigure 3.41.

3.8.3 Data Type Propagation

Figure 3.42a shows the properties dialog of an Add block. This Add block is the Add block from themodel depicted in Figure 3.43. It can be seen that one of its input blocks is a Constant block andthe other is a Product block. Both of these blocks have their output data type set to be calculated.Moreover, the output data type of the In block, which is connected to the Product block, is int16. AsFigure 3.42a shows, the output data type of the Add block is set to uint8.

59


(a) The root level of the model (b) The Atomic Subsystem

Figure 3.40: The example Simulink R© model for the Trans_SL transformation

Figure 3.41: The resulting Sorted List

First, the Trans_TypeProp transformation calculates the output data types of the Constantblocks. In this implementation, the output data type of the Constant block is set to int8.

Next, the data type propagation commences. In this case, the output data type of the Productblock is set to int16 because one of its source blocks, that is, the In1 block, has this data type asshown in Figure 3.42b.

Finally, the verification part of the transformation changes the data type of the Add block fromuint8 to int16, as it is depicted in Figure 3.44a. This modification is based on the data type of theProduct block, which is one of the sources of the Add block. Note, that the other source of the Addblock, that is, the Constant block, would also imply a data type change. The order of the matches incase of the same rule is not deterministic in the VMTS, so the data type of the Add block might havechanged to int8 first, and then to int16.

Since logging functionality is also implemented in the Trans_TypeProp transformation, thedata type changes can be conveniently tracked in a clear listing. This logging is shown in Figure 3.44b.

Note, that the effectiveness of the transformation depends heavily on the implementation of theSetTypeBasedOnValue and the CompatibleTypes algorithms. Nevertheless, the presented ex-ample conveys the value and potential of graph transformations in software and system modeling. Forexample, it becomes straightforward to experiment with data type inferencing algorithms different

60


(a) The Add block(b) The In1 block

Figure 3.42: The properties of the Add and In1 block before the Trans_TypeProp transformation

Figure 3.43: The root level of the example Simulink R© model for the Trans_TypeProp transforma-tion

61


(a) The Add block after the transformation

(b) The change log of the transformation

Figure 3.44: The result of the Trans_TypeProp transformation

(a) The root level(b) The virtual Subsystem

Figure 3.45: The structure of the root level and the virtual Subsystem

from the built-in algorithms in Simulink, such as the one demonstrated here.

3.8.4 Execution Order of Different Transformations

In this final example it is shown that the application order of the flattening transformation and thedata type propagation does not matter. Figure 3.45 shows the source model. Its root level, depicted inFigure 3.45a, contains a virtual Subsystem, an atomic Subsystem, and a number of primitive elements.The structure of the virtual Subsystem is shown in Figure 3.45b.

In order to demonstrate the data type propagation, the output data type of the Gain block is setto the value of int16, in case of the Sum block it is set to “Inherited”. The properties of these blocksare shown in Figure 3.46.

62

3.9. Summary

(a) The Gain block

(b) The Sum block

Figure 3.46: The properties of the Gain and Sum blocks before the transformations

In case the flattening transformation is applied first, the virtual Subsystem is flattened, but theoutput data type property of the Sum block is still not set explicitly. The result is shown in Fig-ure 3.47a. If the data type propagating transformation is applied to the source model, the correctoutput data types are set, but the virtual Subsystem is not flattened. This is shown in Figure 3.47b.

However, in case the remaining transformations are applied to the models after the first step, theresults will be functionally the same models. This verifies that the application order is irrelevant, thetransformations result in the same models if they are applied to semantically the same models.

3.9 SummaryThe use of computation in technical systems has provide a level of flexibility in system functionalitythat was unimaginable before the formidable rise of integrating software. The unparalleled opportu-nity of embedding computation in technical systems for feature differentiation has quickly broughtabout a prolific use with resulting complexity that is difficult to negotiate using traditional softwareengineering methods.

Model-Based Design centers around using models of the computational functionality in manyof the system design efforts. These models raise the level of abstraction with respect to the useof programming languages with their incidental complexity because of the necessity to account forlow-level implementation aspects (such as memory management, execution ordering with destructivewrites, data type management, and so forth). As a design is being refined, models generally passthrough a series of stages where detail is increasingly added as a form of model elaboration. Modelelaboration can, at least in part, be automated by sophisticated software tools. As a popular tool forthe design of technical systems with embedded computation (embedded systems), industry relies onSimulink models for Model-Based Design. Simulink allows modeling with various amounts of detailand supports model elaboration by automating tasks necessary to gradually move a design closerto its implementation. Part of the elaboration involves removing hierarchical structures that haveonly a syntactic effect such as flattening of syntactic hierarchical layers, creating a Sorted List, which

63


(a) The model is flattened(b) The Sum block is set

Figure 3.47: The model after the first transformation

(a) Model after the flattening-propagating order (b) Model after the propagating-flattening order

Figure 3.48: The model after the second transformation

64

3.9. Summary

represents the dependency between the elements in the source model, specifying the data types of theblocks explicitly, or ordering the execution of an otherwise declarative set of functional blocks in amodel. Automated analyses aid in reducing the occurrence of so-called artificial algebraic loops thatmay emerge because of hierarchical grouping of functional blocks in so-called subsystems. Anotherpart of the elaboration is changing the built-in functionality to custom algorithms for a specific targettechnology (e.g., replacing a square root operation with its Babylonian approximation). Yet anotherpart of the elaboration is determining the appropriate data types for the various variables in themodel and its corresponding software implementation.

In this chapter, rather than programming the model elaboration between stages it is modeledexplicitly itself as a model transformation. The resulting modeled model transformation makes iteasier to reason about the particular elaboration, renders it more amenable to reuse, and allows effi-ciency gains by automatically generating an implementation tailored to a specific target technology.A detailed model transformation based solution has been presented for flattening virtual subsystemsin Simulink models, determining a Sorted List, and defining, verifying the data types of the differ-ent model elements by data propagation, minimizing the occurrence of artificial algebraic loops bypartial flattening of subsystems, replacing blocks with custom algorithms, and analyzing data typeassignments, which includes inferring data types, detecting possible conflicts, and potentially reme-dying issues. A number of paradigmatic examples were employed to test the transformations. Theapproach enables taking advantage of benefits of modeled model transformation such as reusabilityand platform independence (e.g., because of data structure independence, modularization, etc.). Inthis manner, the abstraction level of the model processing can be raised.

This work partially operates on the graphical syntax and so the results can be displayed back inthe same graphical syntax. For example, Simulink does the flattening on an in-memory representationand does not generally present the results back to the user in a graphical syntax (though some formof this is available by generating Simulink models that reflect operations in a hardware descriptionlanguage implementation).

The transformations were implemented in the Visual Modeling and Transformation System(VMTS), which enables modeling of model transformations. In order to transform Simulink modelsdirectly, the VMTS modeling framework communicates with the Simulink environment.

The reusability of the individual model transformations was exploited by studying the implicationsof different orders between the flattening of a subsystem and the data type analysis. In particular,the efficiency of the transformation process illustrates that significant benefit can be achieved by firstperforming the subsystem flattening followed by the data type analysis, as compared to the reverseorder.

65

4

Exact Pattern Matching with MapReduce

The MapReduce framework was designed to support processing massive data sets. It is a relatively newform of parallel computing that is easy-to-program, reliable, and supports scalability. Although theparadigm was originally developed at Google, it has a number of open source implementation. Oneof its open source version is the Hadoop [Apache Hadoop, 2011], which is extremely popular bothin industry and academic environment. Moreover, the Hadoop clusters are often used by differentuniversities for research [Hadoop wiki - Powered by, 2013].

Designing algorithms for the MapReduce framework is not trivial [Fehér, 2013]. Although theframework supports high level parallelizability, programmers are restricted to use only map andreduce functions in their programs [Dean and Ghemawat, 2008].

There are already a few MapReduce based approaches to detect subgraph isomorphism. However,those solutions are often limited in some respect. Some of the approaches produces good results,but cannot be used for finding arbitrary patterns, just, for example, triangles or trees. Others areuniversal regarding the target graph, but cannot be used on large source graphs, since they do notsupport scalability. There are solutions that do not find all matches, but produce "best effort" matchesbased on a "goodness function". We think, there is a need for a solution that (i) finds all isomorphicsubgraphs in the source graph, (ii) is able to find arbitrary target graphs, (iii) can be applied onvery large graphs, and (iv) do not need time-consuming preprocessing phases . The properties ofthe existing solutions are presented in Section 4.4, where they are also compared to the algorithmsintroduced in this chapter.

In this chapter, we present the MapReduce Subgraph Isomorphism (MRSI) algorithms, that is,the MRSIH and MRSIS , for finding isomorphic subgraphs in arbitrary graphs where the sourcegraph (i.e. in which the algorithm looks for patterns isomorphic to the target graph) may containmillions of vertices and edges. The algorithms are designed to utilize the capabilities of the MapReduceframework. The approaches are based on a special data structure, which makes chaining the map andreduce functions possible.

Nowadays, more and more cloud vendors offer different MapReduce services, thus the companiesand universities are able to utilize the advantageous properties of the MapReduce framework withoutthe cost of purchasing and maintaining their own clusters. Therefore, our main concern was to developsuch algorithms that produce perfect results on these common clusters within a reasonable time frame.This means, we did not want to optimize the algorithms to big clusters, for example with at least64 nodes where each node contains an extremely powerful CPU and 32GB memory, but we want tooffer algorithms that can be used on small and thereby cheaper clusters. Therefore, we developed thealgorithms in a way, where the amount of costly I/O operations and the memory intensive steps arereduced.

The purpose of this chapter is to present the MRSIH and MRSIS algorithms, which are ableto find arbitrary patterns in arbitrary large graphs. Moreover, the two algorithms are analyzed in

66

4.1. The MRSI Algorithms

respect of space and memory requirements as well, which is supported by experimental results.Comparing the two algorithms, the first one (MRSIH) might be a better choice for using different

heuristics, since its outputs contain more information about the given state of the processing. However,without any additional heuristics, the second algorithm (MRSIS) performs better, because it producessmaller outputs.

The presented approaches support the detection of isomorphic subgraphs in the cloud as well. Thestorage and processing of the large graphs might be a viable option in the cloud, since there are moreand more cloud computing providers. Therefore, no optimization was used that is specific to a singlecluster or cloud provider.

The rest of the chapter is organized as follows. Section 4.1 provides the used data structure andthe MRSI algorithms for subgraph isomorphism. The analyses of the algorithms are presented inSection 4.2. The experimental results are presented in Section 4.3. Section 4.4 provides an overviewof related work. Finally, Section 4.5 closes with concluding remarks.

4.1 The MRSI AlgorithmsThe MapReduce Subgraph Isomorphism (MRSI) algorithms are novel approaches to detect isomor-phic subgraphs in graphs with millions of edges and vertices. The algorithms are constructed to utilizethe advantageous properties of the MapReduce technique and make the usage of different heuristics,such as the VF2 [Cordella et al., 2001, Cordella et al., 2004, Cordella et al., 1998, Foggia et al., 2001]algorithm, possible. The MRSI algorithms offer the possibility to move the computing into the cloud,where even more benefits can be gained: (i) The source graph can be stored in the cloud (typicallyin a BLOB). (ii) The size of the Hadoop cluster can be dynamically changed. There are a coupleof different cloud vendors offering these possibilities, for example [Amazon Web Services, 2013] or[Windows Azure, 2013].

Although the source graphs are typically graphs with millions of nodes and edges, the targetgraphs are small ones, usually contain just a couple dozens of nodes. A common property of the twoalgorithms that they store the target graph in memory. This is convenient and advantageous sincethere is no need for any expensive I/O operation to get the next target graph node.

This section presents two new approaches, theMRSIH and theMRSIS algorithms, producing thevery same final output, for detecting isomorphic subgraphs with the MapReduce technique. Moreover,the data structure of the source graphs represented as textual files are also described.

The main difference between the two approaches is the amount of information they are rollingbetween the MapReduce jobs. On one hand, the MRSIH algorithm associates more data to thepartial mappings. This makes the usage of the possible heuristics more convenient, because thereis more information to select the next candidate node or to decide whether the candidate shouldbe mapped or not. However, the extra data increases the number of required I/O operations. Onthe other hand, the MRSIS algorithm deals with only the essential information, but this ultimatelyrestricts the number of possible heuristics. Another difference is the exact phase where the computingis performed. Because of the fewer data, the MRSIS algorithm can transform the textual files ina way that the complex computations are executed in the mapper phases of the jobs, which is thepreferred way in case of the MapReduce framework.

4.1.1 Description of the Data Structure

As it has been mentioned, the mapper function has only one input parameter, which is usually astring. The mapper tasks obtain this parameter, typically a line from the textual input, and, aftersome potential parsing methods, produce arbitrary number of <key, value> pairs. In order to detect

67

4. Exact Pattern Matching with MapReduce

row = ID, "\t", { NodeLabels }, ";", { IncomingEdges }, ";",{ OutgoingEdges }, ";", HelperBit;

ID = alphabetic char | digit, { alphabetic char | digit };NodeLabels = Label, { ",", NodeLabels };IncomingEdges = ID, { "-", EdgeLabels }, { ",", IncomingEdges };OutgoingEdges = ID, { "-", EdgeLabels }, { ",", OutgoingEdges };EdgeLabels = Label, { ":", EdgeLabels };HelperBit = "0" | "1";

Figure 4.1: The EBNF of a data row

subgraphs in a source graph represented as a textual file, The MapReduce algorithm must be awareof the data structure of the textual file, therefore, this must be defined first.

The following specialties of the mapper and reducer functions must be considered to define theappropriate data structure:

• Both the mapper and reducer functions are stateless. That is, the functions do not know aboutany other sequential or parallel processing.

• Each mapper function processes exactly one line at a time. This means, its knowledge of thesource graph is equal to all the information stored in the given input line.

Moreover, the algorithms need certain set of information to check the feasibility rules (i.e., whetherthe actual mapping is subgraph isomorphic to the target graph).

A plausible approach is that each line represents a vertex of the graph with all information relatedto it. The necessary information about the given node are the following:

• The identifier of the node,

• In case of labeled graph, the labels of the vertex (if there is any),

• The neighbors with outgoing edges to the node and the labels of these edges (if there is any),

• The neighbors with incoming edges from the node and the labels of these edges (if there is any).

Since the node may have multiple vertex labels and incoming/outgoing edges with multiple edgelabels, the information must be carefully separated. The final data structure in Extended Backus-NaurForm (EBNF) is depicted in Figure 4.1, where the rule of thumb is the following:

1. The identifier of the node is the most important information, therefore it is the first, and isfollowed by a tabulator that is typically used as the separator between the key and the valueemitted by either the mapper or the reducer.

2. The remaining sets, i.e. the labels, incoming edges and outgoing edges are separated by asemicolon character.

3. All items within an array (e.g. the different labels of the node) are separated by a commacharacter.

4. The end point of the edges are separated from their labels by a dash character.

5. All items within a subarray (e.g. the different labels of the edges) are separated by a coloncharacter.

68


A

B C

D

4 9

39 5

(a) An example graph

A Blue;;B-dashed:4,C-dashed:9;0B Red;A-dashed:4;C-dotted:3,D-solid:9;0C Green;A-dashed:9,B-dotted:3;D-solid:5;0D Blue;B-solid:9,C-solid:5;;0

(b) The data structure of the same graph

Figure 4.2: The visual and textual representation of a graph

MSMT

T InS

TOutS

TOutT

T InT

GS GT

Figure 4.3: The different node sets in VF2

A sample data structure is depicted in Figure 4.2. The colors and the linetypes with numbersrepresent different labels on the nodes and edges, respectively. The 0 at the end of each line is ahelper bit that determines whether the given node is already processed.

4.1.2 Denotations

This section introduces a couple of new data sets, which are utilized throughout the presentation ofthe algorithms in the next section.

The partial match (M), or partial mapping, is an ordered set of source graph nodes. These nodesare subgraph isomorphic to the target graph. Since the algorithms select the next target node tomatch based on an arbitrary, but predefined function (i.e. the order of the examined target nodes canbe determined at any point of the algorithm and it is always the same), the partial mapping onlycontains the matched source nodes. However, the order of the nodes is important, because the nodepairs are determined based on this order as the algorithm iterates over the target nodes.

The candidate node pair object always contains a partial mapping, the next target node to match,and a node from the source graph that is not contained by the given partial mapping. Based on thisinformation, the algorithm determines whether the partial mapping can be extended with the sourcegraph node.

The T In sets contains all nodes having outgoing edges to at least one of the nodes contained bythe partial mapping. Similarly, TOut contains all neighbor nodes of the partial mapping that haveincoming edges from at least one of the contained nodes. Although there are separate T InS and T InTsets, throughout the presentation of the algorithm, the T In refers to the T InS set.

These sets are depicted in Figure 4.3 as well. The solid lines represent the edges of the graphs andthe nodes are labelled with different colors. The mapped nodes are connected with dotted lines.

69


Figure 4.4: The structure of the MRSIH algorithm

4.1.3 The MRSIH Algorithm

This section introduces the MRSIH algorithm. This approach highly supports the utilization ofdifferent heuristics in order to reduce the searching space. Basically, in the kth iteration, the mappertasks emit all possible extensions to the partial mappings containing k−1 nodes, then the reducerscheck the feasibility rules, and leave out the nodes that failed the rules. This means, after the kth

reduce step, all emitted mappings contain k nodes and these nodes are subgraph isomorphic to thetarget graph. Figure 4.4 depicts the structure of the algorithm.

InMRSIH , the mapper tasks are responsible for generating all possible candidate node pairs thatmight be added to the given partial mapping. This candidate pair generation is based on the VF2algorithm. The VF2 algorithm selects the next pair to examine from the T In and TOut sets of thepartial mapping.

In this manner, the mapper function must construct a new candidate pair, where the source nodeis chosen from the appropriate sets (T In,TOut), and the next target node, which is calculated by afunction. To make it possible to use heuristics the basic data structure is extended with a new entity,the candidate node pair, which represent a potential match. This entity is responsible for providingthe data that is necessary for the feasibility rules:

• The identifier of the source node that might be added to the partial mapping (the target nodecan be deduced based on the cardinality of the partial mapping set),

• The source nodes contained by the partial mapping (as it was already defined, it is an orderedlist, the target nodes can be easily deduced),

• The nodes that have outgoing edges to the partial mapping,

• The nodes that have incoming edges from the partial mapping.

Note, that although the identifiers of the target graph nodes, i.e., the one to match and the alreadymapped ones, are not represented explicitly in the candidate pair, they can be deduced based on thecardinality of the partial mapping set and the function calculating the next target nodes to map.

The separators defined earlier can be applied here as well. This structure is also extended with ahelper bit that can be utilized in the processing. An example of the representation of the candidate

70


A Blue;;B-dashed:4,C-dashed:9;1B Red;A-dashed:4;C-dotted:3,D-solid:9;1C Green;A-dashed:9,B-dotted:3;D-solid:5;1C ;A,B;;D;D Blue;B-solid:9,C-solid:5;;1

Figure 4.5: The example graph with a candidate node

candidaterow = ID, "\t", ";", { SourceNodes }, ";",{ IncomingEdgesFrom }, ";", { OutgoingEdgesTo }, ";";

ID = alphabetic char | digit, { alphabetic char | digit };SourceNodes = ID, { ",", SourceNodes };IncomingEdgesFrom = ID, { ",", SourceNodes };OutgoingEdgesTo = ID, { ",", SourceNodes };

Figure 4.6: The EBNF of a candidate row

node pair entity can be seen in Figure 4.5, and the EBNF of a candidate pair entity is depicted inFigure 4.6.

Algorithm 24 The algorithm of the MRSIH mapperRequire: string input with the appropriate formatEnsure: < key,value > pairs1: string[] inputParts← input.Split(′;′ )2: if inputParts.Length= 4 then3: if input.HelperData= ”0” then4: Node node←GetNodeFromLine(input)5: CandidateNode candidate← CreateCandidateNode(node)6: node.HelperData← ”1”7: EmitKeyValue(node.ID,node.GetV alue())8: EmitKeyValue(candidate.ID,candidate.GetV alue())9: else10: EmitLine(input)11: else if inputParts.Length= 5 then12: Node node←GetCandidateNodeFromLine(input)13: for all c|c ∈ node.T In do14: CandidateNode candidate← CreateCandidateNode(node,c)15: EmitKeyValue(candidate.ID,candidate.GetV alue())16: for all c|c ∈ node.TOut do17: CandidateNode candidate← CreateCandidateNode(node,c)18: EmitKeyValue(candidate.ID,candidate.GetV alue())

The mapper algorithm is shown in Algorithm 24. The first thing to note is that the functionalityof this algorithm depends on the type of the input line. Since the input may stem from the reducerfunction, it is a textual representation of either a node or a candidate node pair. If the line contains4 semicolon, it represents a node, otherwise a candidate node pair.

If it is a node, the first thing to do is check whether it is already processed, that is, whetherthe algorithms generated candidate node pairs from the node in the previous iterations. This can bedetermined from the last character of the line (the helper bit). If it has not been processed before,then this is the first iteration of the algorithm, which means there are no candidate node pairs in the

71


text file. In this case, the mapper function instantiates a node object based on the input line, thengenerates a simple candidate node pair object from it (CreateCandidateNode command), where thesource node is the given node.

Note, that the other part of the node pair is not calculated from the input parameter. Since thetarget graphs are usually small (i.e. contain just a couple of nodes) it is much more efficient to storethem in the memory, which means that the mappers and reducers do not obtain the target graphthroughout parameters. This way the selection of the next target node is simpler and more advancealgorithms and heuristics can be used. The real benefit is, though, that the space requirements of theoutputs and the network traffic are decreased.

After the candidate node pair object is generated, the mapper function emits both the originalnode and the new object. The GetValue() function constructs the value part of the < key,value >pair. It is really important to emit the original node, since it contains essential information (e.g. thedifferent labels, neighbors, etc.) that will be used by the reducer.

If the node object is already processed at the time the mapper function obtains it as a parameter,i.e. after the first iteration, then the mapper simply emits the whole line (EmitLine), that is theoriginal node, without any modification. (The EmitLine function takes care for emitting the line as a< key,value > pair.)

Finally, when the input line is a candidate node pair the mapper function must generate thenew set of candidate node pairs. The node with the neighbors is parsed from the input line with theGetCandidateNodeFromLine command. At this stage, the algorithm knows that the candidate pairscontained in the object satisfy all feasibility rules, so the mapper does not check any other conditions.The new objects are constructed based on the nodes chosen from the sets T In and TOut of the sourcegraph and the next node of the target graph, which is calculated by another algorithm in the memory.This time only the new objects are emitted, since after the iteration i, eachcandidate node pair objectcontains i pair of objects: i− 1 in the partial mapping and 1 newly generated. The value to emit isgenerated by the GetValue command.

It can be stated that after all the mappers finished, the number of emitted lines is greater orequal to the number of lines of the input. This is because the mapper always emits at least the line itprocesses. The number of lines is increased by the number of newly generated candidate node pairs,if there is any.

After the shuffle stage, which is achieved seamlessly by the MapReduce framework, a reducerreceives all values related to a single key. In this manner, the reducer function obtains the valuedescribing the node and all candidates containing the given node. That is because the key field of theemitted candidate node pairs is the identity property of the node to examine. It can be seen that thereducer always possesses all information needed to check the feasibility rules. The reducer algorithmis shown in Algorithm 25.

The algorithm determines the identity of the given node and find the line representing it in thegraph. To achieve this, as the mapper algorithm, the reducer utilizes the information about thecontained semicolon characters as well. The candidates objects stores the list of the candidates nodepairs. After emitting the textual representation of the node, the algorithm iterates over the candidatenode pair objects to determine if the candidate pair satisfies the rules. The object on which the testof the feasibility rules can be examined is created by the CreateCandidateNode command.

Now, the algorithm is able to determine if the new candidate pair meets the necessary and sufficientconditions of subgraph isomorphism and may lead to further matches at all. This is the responsibilityof the IsValidMatch algorithm. Constructing the candidate pair based on the T In and TOut sets thenapplying the feasibility rules of the VF2 algorithm is a heuristic that narrows down the searchingspace by omitting the partial mappings that definitely cannot form a complete match. The IsValid-Match algorithm is the equivalent of the VF2 algorithm described in more details in Section 6.1. Ifthe conditions are met, then the reducer function adds the candidate pair to the partial mapping,

72


Algorithm 25 The algorithm of the MRSIH reducerRequire: string key as the key, string[] values as the related valuesEnsure: < key,value > pairs1: string nodeID = key2: string nodeData= n|n ∈ values∧n.Split(′;′ ).Length= 43: string candidates= c|c ∈ values∧ c.Split(′;′ ).Length= 54: Node node←GetNodeFromLine(nodeID,nodeData)5: EmitKeyValue(node.ID,node.GetV alue())6: for all c|c ∈ candidates do7: CandidateNode candidate← CreateCandidateNode(node,c)8: if IsV alidMatch(node,candidate) then9: candidate.MatchSucceeded(node)

10: EmitKeyValue(candidate.ID,candidate.GetV alue())

maintains the T In and TOut sets (candidate.MatchSucceeded(node)), and emits the candidate nodepair object.

In this manner, after all reducer tasks finished, the output only contains the original lines thatrepresent the source graph, and the candidate node pairs that are valid partial mappings.

The MRSIH algorithm creates a chain from the presented mapper and reducer functions. This isa for block from 0 to n−1, where n stands for the number of nodes in the target graph. In each step,the functions obtain each other’s output, and the initial input is the source graph.

Proposition 4.1. The MRSIH algorithm finds all subgraphs in GS(VS ,ES) that are isomorphic toGT (VT ,ET ).

Proof. Let R : VS×VT ×M →{0,1} be a predicate function implementing the feasibility rules of theVF2 algorithm. R takes nodes nS ∈ VS , nT ∈ VT , and partial mapping m ∈M as arguments, andreturns 1 if nS and nT form a match that can lead to a complete match with regard to the partialmapping m. Let E(cp) be a function that emits the cp candidate node pair taken as argumentsas a <cpS , cpT ,m> object, where cpS ∈ VS , cpT ∈ VT , and m is the partial mapping. Suppose thatthe first target graph node to find a pair for is x|x ∈ VT . The first mapper function generates cp1of the form <n,x,∅>,∀n ∈ VS . In this case the behavior of the first reducer is: E(cp1) if and onlyif R(vS ,vT ,m) = 1|vS ∈ cp1,S ∧ vT ∈ cp1,T . In this manner, exactly those candidate node pairs areemitted, which satisfy the feasibility rules.

In the second iteration, where the target graph node to find a pair for is y|y ∈ VT ∧x , y, themapper functions generate all cp2 :<s,y,m>,∀s ∈ T In ∪ TOut. Then, the reducer emits E(cp2)⇔R(vS ,vT ,m) = 1|vS ∈ cp2,S ∧ vT ∈ cp2,T . It means that all emitted candidate node pairs are validsubgraphs with regard to the x and y nodes. Moreover, since all permutation of the nodes werechecked (or more specifically, those, which met the feasibility rules), all possible partial mappings areemitted.

After the kth iteration, the output of the reducer contains exactly those candidate node pairs whereR(vS ,vT ,m) = 1|vS ∈ cpk,S ∧ vT ∈ cpk,T and the m partial mapping contains exactly k node pairs. Ifk = |VT | → ∀nT ∈ cpk|nT ∈ VT , that is, all candidate node pairs contain each and every node of thetarget graph. Since the reducers emit exactly those candidate node pairs that satisfy the conditions ofsubgraph isomorphism, theMRSIHalgorithm finds all subgraphs in GS that is isomorphic to GT . �

4.1.4 The MRSIS Algorithm

This section presents yet another approach to find subgraph isomorphisms. This is the MRSIS algo-rithm. The main differences between the MRSIH and the MRSIS algorithms are the following:

73


Figure 4.7: The structure of the MRSIH algorithm

• The MRSIS algorithm uses two MapReduce jobs in each iteration to extend the partial map-pings with a new item, and to determine the new candidates.

• The computing is performed by the mappers, the reducers only carry out the grouping andfiltering of the results. This approach is closer to the MapReduce paradigm, therefore, it leadsto better performance.

In the rest of the chapter the first mapper, first reducer, second mapper, and second reducer termsare frequently used. This does not mean that there are different mappers and reducers in the sameMapReduce job, they are just short terms indicting both the job number and the function. That is,the first mapper term stands for the mapper function applied by the first MapReduce job. Similarly,the second reducer refers to the reducer function in the second job.

In each iteration the control flow of the algorithm (depicted in Figure 4.7) can be described asfollows:

1. The first mapper (M ′S) is responsible for adding a new element to the partial mappings. Each

mapper instance starts with parsing its input line. The following cases are possible:

• The line contains no partial mapping, just represents the source graph, which was notprocessed before, that is, the algorithm did not attempt to pair the node defined in theinput line to any target node in the previous iterations. In this case, the mapper nowattempts to pair the node to the first node from the target graph. If the match is possible(IsValidMatch), then the mapper emits the ID of the node as the key, and the partialmapping (that contains only the given node) as the value. Moreover, the input line is alsoemitted.• The line contains no partial mapping, just represents the source graph, which was alreadyprocessed. In this case the mapper has nothing to do, simply emits the input line.• The line contains partial mappings. The second reducer (R′′

S) producing this output in theprevious iteration groups the data in such way, that all partial mappings appear in the rowof the node, which is a candidate to the given partial mappings. These partial mappings

74


are separated by a special delimiter character (referred to as PartialMappingDelimiter).In this manner, M ′

S obtains the node and the possible partial mappings. The M ′S then

attempts to pair the given node to the next node from the target graph in regard toeach partial mapping. If the match is possible, which is examined by the IsValidMatchalgorithm (applying the VF2 algorithm described in Section 6.1), then the partial mappingis extended with the node. The M ′

S algorithm emits this extended partial mapping as avalue for every node contained by the mapping. This is necessary, because this partialmapping must appear in each of the rows related to the nodes that has edges to or fromany node contained by the partial mapping. Finally, the M ′

S also emits the informationrelated to describing the source graph node.

The algorithm M′S is depicted in Algorithm 26.

Algorithm 26 The algorithm of the first mapper (M ′S) of the MRSIS

Require: string input with the appropriate formatEnsure: < key,value > pairs1: string[] inputParts← input.Split(′;′ )2: if inputParts.Length= 4 then3: if input.HelperData= ”0” then4: Node node←GetNodeFromLine(input)5: CandidateNode candidate← new CandidateNode(node)6: if IsV alidMatch(node,candidate) then7: PartialMapping pm←GetPartialMappingFromCandidate(candidate)8: for all m|m ∈ pm.Matches do9: EmitKeyValue(m.ID,pm.GetV alue())10: node.HelperData← ”1”11: EmitKeyValue(node.ID,node.GetV alue())12: else13: EmitLine(input)14: else if candidates.Length > 1 then15: string[] candidates← inputParts[4].Split(PartialMappingDelimiter)16: Node node←GetNodeFromLine(input)17: PartialMapping pm←∅18: for int i= 0 to candidates.Length−1 do19: pm.Add(GetPartialMappingFromString(candidates[i]))20: for all m|m ∈ pm do21: CandidateNode candidate← new CandidateNode(node,m)22: if IsV alidMatch(node,candidate) then23: m.AddMatch(node)24: for all t|t ∈m.Matches do25: EmitKeyValue(t.ID,m.GetV alue())26: EmitKeyValue(node.ID,node.GetV alue())

2. The first reducer (R′S) is responsible for moving each partial mapping to each node that

appears int the list. The MapReduce framework ensures that the reducers obtain all valuesrelated to the given key. This means that a given R′

S instance receives all partial mappings thatcontain the node obtained by the key. This is, because M ′

S emits the partial mapping as a valuefor all of its contained node. Moreover, R′

S also obtains the row representing the node in thesource graph. Since the same partial mapping might appear multiple times, the Distinct method

75


is called to omit the duplication. Then, each R′S instance emits a single line, which contains the

data representing the source graph node, and all partial mappings that contains the given node.The partial mappings are separated by the PartialMappingDelimiter character. The algorithmR

′S is depicted in Algorithm 27.

Algorithm 27 The algorithm of the first reducer (R′S) of the MRSIS

Require: string key as the key, string[] values as the related valuesEnsure: < key,value > pairs1: string nodeID← key2: string nodeData← n|n ∈ values∧n.Split(′;′ ).Length= 43: string pMappings←m|m ∈ values∧m.Split(′;′ ).Length= 14: pMappings← pMappings.Distinct()5: string output← nodeData6: for all m|m ∈ pMappings do7: output.Append(”|” +m)8: EmitKeyValue(node.ID,output)

3. The second mapper (M ′′S ) is responsible for generating the candidates for each partial map-

ping.M ′′S obtains the node data and all partial mappings that contain the given node. It iterates

through the partial mappings, and emits <key,value> pairs for each of them. In each iterationthe M ′′

S examines the neighboring nodes, and emits the node as a key if it is not contained bythe partial mapping, and the related value is the given partial mapping. The information relatedto the source graph node is also emitted. The algorithm M

′′S is depicted in Algorithm 28.

Algorithm 28 The algorithm of the second mapper (M ′′S ) of the MRSIS

Require: string input with the appropriate formatEnsure: < key,value > pairs1: if ”|” < input then2: EmitLine(input)3: else4: string[] inputData← input.Split(′|′)5: Node node←GetNodeFromLine(inputData[0])6: PartialMapping pm←∅7: for int i= 1 to inputData.Length−1 do8: pm.Add(GetPartialMappingFromString(inputData[i]))9: Node[] neightbors←GetNeighbors(node)

10: for all m|m ∈ pm do11: Node[] candidates← c|c ∈ neighbors∧ c < pm.Matches12: candidates← candidates.Distinct()13: for all c|c ∈ candidates do14: EmitKeyValue(c.ID,pm)15: EmitKeyValue(node.ID,node.GetV alue())

4. Finally, the second reducer (R′′S) is responsible for moving the partial mappings to the row

describing the candidate source graph node. After M ′′S , the partial mappings are assigned to

the possible candidates, therefore, R′′S obtains all partial mapping to which the node might be

an extension. In addition to the partial mappings, the reducer also obtains the value describing

76


the source graph node. Each R′′S instance emits a single line. Each of these lines contains data

representing the source graph node, and all partial mappings for which the node is a candidate.The partial mappings are separated by the PartialMappingDelimiter character. The algorithmR

′′S is depicted in Algorithm 29.

Algorithm 29 The algorithm of the second reducer (R′′S) of the MRSIS

Require: string key as the key, string[] values as the related valuesEnsure: < key,value > pairs1: string nodeID = key2: string nodeData= n|n ∈ values∧n.Split(′;′ ).Length= 43: string pMappings=m|m ∈ values∧m.Split(′;′ ).Length= 14: pMappings← pMappings.Distinct()5: string output← nodeData6: for all m|m ∈ pMappings do7: output.Append(”|” +m)8: EmitKeyValue(node.ID,output)

As it can be seen, although R′S and R′′

S work on different data, the logic of the algorithms are thesame.

The different states of the algorithm can be examined in Figure 4.8. In this example, the hostgraph is a K5, and the target graph is a K4. The connections between the partial mappings and thecandidate nodes are also highlighted.

The algorithm MRSIS , just as the algorithm MRSIH , finds all subgraphs in the source graphthat are isomorphic to the target graph.

Proposition 4.2. The algorithm MRSIS finds all subgraphs in GS(VS ,ES) that are isomorphic toGT (VT ,ET ).

Proof. Let R : VS × VT ×M → {0,1} be a predicate function implementing the feasibility rules ofthe VF2 algorithm. R takes nodes nS ∈ VS , nT ∈ VT , and partial mapping m ∈M as arguments,and returns 1 if nS and nT form a match that can lead to a complete match with regard to thepartial mapping m. Let E(cp) be a function that takes the cp candidate node pair as arguments asa <cpS , cpT ,m> object, where cpS ∈ VS , cpT ∈ VT , and m is the partial mapping. E(cp) emits the mpartial mapping extended with the <cpS , cpT> node pair.

Suppose that the first node to find a pair for in the target graph is x|x ∈ VT . In the first itera-tion, the M ′

S instances generate E(cp1) if and only if R(vS ,vT ,m) = 1|vS ∈ cp1,S ∧ vT ∈ cp1,T , wherecp1 =<n,x,∅>,∀n∈ VS . In this manner, exactly those partial mappings are emitted, which satisfy thefeasibility rules. Next, the R′

S , M′′S , and R

′′S instances reorders the partial mappings. After the R′′

S

phase, the partial mappings appear in a row, if the node described in the row has connecting edgesto at least one of the nodes contained by the partial mapping. Partial mappings are only omitted incase of duplication, thus the number of distinct partial mappings does not change.

Suppose that the next target graph node to find a pair for is y|y ∈ VT . In the second iteration theM

′S instances generate E(cp2)⇔ R(vS ,vT ,m) = 1|vS ∈ cp2,S ∧vT ∈ cp2,T , where cp2 =<s,y,m>,∀s ∈

T Inm ∪TOutm . It means that all emitted partial mappings are valid subgraphs with regard to the x andy nodes. Moreover, since all permutation of the nodes were checked, where the x node is successfullymatched, all possible partial mappings are emitted.

After the kth iteration, the output of the M ′S contains exactly those partial mappings where

R(vS ,vT ,m) = 1|vS ∈ cpk,S ∧vT ∈ cpk,T and the m partial mapping contains exactly k−1 node pairs.If k = |VT | → ∀nT ∈ cpk ∪mT |nT ∈ VT , where mT contains the target nodes already in the partial

77


Figure 4.8: The relation between the different states of the MRSIS algorithm

mapping. This means that the partial mappings emitted by the kth M′S contain each and every

node of the target graph. Since there is no other target node to find a pair for, after the kth M′Sthe

MRSISalgorithm finds all subgraphs in GS that is isomorphic to GT . �

Although MRSIS uses two MapReduce jobs in each iteration instead of one, it has the followingadvantageous properties compared to the MRSIH :

• The computing, that is determining whether the candidate nodes can be added to the partialmapping is accomplished by the mappers, which is the preferred structure of the MapReducealgorithms.

• The partial mappings do not have to contain their candidates, since the mappings are assignedto the nodes as possible partial mappings.

78

4.2. Analysis of the MRSIH and MRSIS Algorithms

• Since the first mapper adds the new nodes to the partial mappings, therefore, the process finishesafter the first mapper in the last iteration, there is no need to run the remaining mapper andreducer phases.

This section has presented two novel approaches for detecting subgraph isomorphism with MapRe-duce. The used data structure and algorithms were discussed in details. In the next section theapproaches are analyzed based on their space and memory requirements.

4.2 Analysis of the MRSIH and MRSIS AlgorithmsIn this section, the space/network and memory usage of the algorithms are analyzed. As noted inmany studies, one of the most expensive operations of the MapReduce framework is the transfer ofthe data between the instances of the different phases [Lee et al., 2012]. In this manner, the less theoutputs of the mapper/reducer phases are the quicker the algorithm is. Moreover, the shuffle phaseautomatically orders the outputs of the mapper instances, thus the less output is advantageous inregarding of the shuffle phase as well.

After the shuffle phase, the reducer instances obtain all data related to a given key, and an instancemust store all this data in its memory. Therefore, the reducer memory requirement of an algorithmis an important property.

In worst case scenario, when the most iterations and I/O operation are required, no new candidatenode pair fails the feasibility rules, thus each new candidate pair can be added to the partial mappings.Moreover, the degrees of the vertices are equal. In this manner, the length of each row is the same.In order to compute the upper bounds of the outputs, the analysis considers the worst case scenario.

In the following, the algorithms are examined in regard to the outputs of the mapper and reducerphases, and the maximum memory requirement of the reducers. Moreover, the time complexity of thealgorithms are also presented.

4.2.1 Denotations

Let GS = (V,E) and GT = (V,E) be the source and target graphs, respectively.Let LMj

i denote the length of each row generated by the jth mapper function after the ith iteration.Let NMj

i denote the number of rows generated by the jth mapper function after the ith iteration.Similarly, NRj

i and LRj

i stand for the number of rows and the length of each row generated by thejth reducer function after the ith iteration.

Moreover, let SMj

i and SRj

i denote the size of the output files generated by the jth mapper/reducerfunction after the ith iteration and can be calculated as follows:

SMj

i =NMj

i ·LMj

i

SRj

i =NRj

i ·LRj

i

Furthermore, let M∗ denote the description of the original data structure of the source graph, sbe the space required to represent the M∗, m be the number of nodes contained by the source graph,and f stand for the size required to represent a single node in a line without its incoming/outgoingedges, which is practically the size of the node identifier and an appropriate punctuation. Note, that inworst case scenario, which is the perfect graph, s=m ·m ·f , because the size required for representinga single node with its neighbors is m · f , where (m− 1) · f required for the neighbors and f for theidentity.

Since the number and the length of the rows depend on the number of successfully matchedcandidate pairs, the worst case scenario regarding to both the space and memory usage is when the

79


01

2

3 4

5

(a) The source K6 graph

0 Blue;1,2,3,4,5;01 Blue;0,2,3,4,5;02 Blue;0,1,3,4,5;03 Blue;0,1,2,4,5;04 Blue;0,1,2,3,5;05 Blue;0,1,2,3,4;0

(b) The data structure of the source graph

Figure 4.9: The visual and textual representation of the source graph

M*0 ;;;1 ;;;2 ;;;3 ;;;4 ;;;5 ;;;

(a) The output of the first MH

M*0 ;0;1,2,3,4,5;1 ;1;0,2,3,4,5;2 ;2;0,1,3,4,5;3 ;3;0,1,2,4,5;4 ;4;0,1,2,3,5;5 ;5;0,1,2,3,4;

(b) The output of the first RH

Figure 4.10: The outputs after the first iteration

algorithms look for the GT =Km−1 target graph in the GS =Km source graph, where Ki denotes thecomplete graph on i vertices.

As it has been mentioned, when analyzing MapReduce algorithms, an important aspect is theoccupied memory by the different reducer instances. Let ∆ρ

k denote the upper bound of the memoryused by a single ρ reducer in the kth iteration.

The following example presents the outputs of its first two iterations. In this example the GS isa K6 (denoted in Figure 4.9), and GT is a K5. This is also an example for the worst case scenario,since every subgraph with 5 nodes in a K6 is isomorphic to the K5, therefore, all new candidate pairsmeet the feasibility rules. Figure 4.10 denotes the output file after the first MH and RH phases, andthe different outputs after the second phase are illustrated in Figure 4.11.

For the sake of simplicity, the algorithm is analyzed for only undirected graphs. The undirectedgraphs result shorter and, in case of a complete graph, half as many lines in the output, since thereis no separate CandidateNodesIn.

4.2.2 Space and Memory Requirements of MRSIH

In case of theMRSIH algorithm both the mapper and the reducer phases emit the whole source graph.Therefore, during the course of the analysis, the rows that represent this graph are temporarily setaside. This means that the NMH

k and LMHk do not consider those rows, thus SMH

k = s+NMHk ·LMH

k .

Proposition 4.3. After the kth iteration, the size of the output in case of both the MH and the RHcan be estimated with the following:

SMHk = SRH

k ≤ s+ m!(m−k)! · (m+ 1) ·f

Proof. As it was described in Section 4.1.3, the mapper functions are responsible for generating allpossible candidate node pairs that can be possibly added to the given partial mappings. The first

80


MH phase is special, because this time the set containing the candidate nodes is empty. In the firstiteration, MH functions suggest ∀n ∈ VS as the candidate node for the first target graph node. Thisresults in m= |VS | new lines in the output file, where each line contains the identifier of the suggestednode (let us ignore the three semicolons in this case). Thus, after the first iteration:

NMH1 =m LMH

1 = f

The reducer phase of the MRSIH algorithm checks, whether the candidate node pairs can beadded to the partial match considering the different feasibility rules. The output file contains only therows related to the candidate nodes, where this examination was successful. In worst case scenariothis examination always returns true. Therefore, the number of rows in the output file do not differfrom number of rows generated by the MH functions. In case a candidate node pair can be added tothe partial mapping, the RH function also refreshes the set containing the related candidate nodeswith the neighbors of the newly added node, as Figure 4.10b denotes. Since the source graph is acomplete graph, each node appears in either the set of the candidate nodes or in the partial mapping.Plus, the newly added node also appears as the key of the line. This leads to the following:

NRH1 =m LRH

1 = (m+ 1) ·f

After the first iteration, the MH functions generate the candidate nodes for all partial mappings.This means that the mappers create m− 1 new rows for each row, because the cardinality of thecandidate node set equals to the number of nodes not contained by the partial mapping. Since thealgorithm orders the target graph nodes based on a predefined algorithm, there is no need to containthem in the output file. The only difference between a line generated by an MH function and onecreated by an RH is the key value. This means that the length of the row remains the same:

NMH2 =m · (m−1) LMH

2 = (m+ 1) ·f

The second RH checks the new candidate nodes and refreshes the candidate node sets. Since inthe worst case scenario all candidates satisfy the feasibility rules, the number of the emitted lines doesnot change. The length of a row does not change either, because the only difference between the inputand the output is that a candidate node is moved from the candidate set to the partial mapping. Thisleads to the following:

NRH2 =m · (m−1) LRH

2 = (m+ 1) ·fIn general, the output of the kth mapper phase generates all of the ordered set of permutations

for ∀m ∈ VGSwhere the partial mapping consists of k− 1 elements and does not contain the given

m. Each of these rows contains all nodes from the source graph, part of either the partial mappingor the candidate node set.

NMHk = m!

(m−k)! LMHk =

{f if k = 1(m+ 1) ·f otherwise

(4.1)

Since in worst case scenario all candidate node pairs satisfy the feasibility rule, RH emits all inputrows, thus the number of output rows remains the same. The length of the rows does not changeeither, since the candidate node set contains all neighbor nodes not contained by the partial mapping,which equals to m−k in case of a complete graph, where the partial mapping consists of k elements.

NRHk = m!

(m−k)! LRHk = (m+ 1) ·f (4.2)

This means that if k > 1, then NMHk = NRH

k and LMHk = LRH

k . Based on Eq. (4.1) and Eq. (4.2)the size of the output file after the kth iteration is the following:

SMHk = SRH

k = s+ m!(m−k)! · (m+ 1) ·f (4.3)

�

81


M*0 ;1;0,2,3,4,5; 3 ;0;1,2,3,4,5;0 ;2;0,1,3,4,5; 3 ;1;0,2,3,4,5;0 ;3;0,1,2,4,5; 3 ;2;0,1,3,4,5;0 ;4;0,1,2,3,5; 3 ;4;0,1,2,3,5;0 ;5;0,1,2,3,4; 3 ;5;0,1,2,3,4;1 ;0;1,2,3,4,5; 4 ;0;1,2,3,4,5;1 ;2;0,1,3,4,5; 4 ;1;0,2,3,4,5;1 ;3;0,1,2,4,5; 4 ;2;0,1,3,4,5;1 ;4;0,1,2,3,5; 4 ;3;0,1,2,4,5;1 ;5;0,1,2,3,4; 4 ;5;0,1,2,3,4;2 ;0;1,2,3,4,5; 5 ;0;1,2,3,4,5;2 ;1;0,2,3,4,5; 5 ;1;0,2,3,4,5;2 ;3;0,1,2,4,5; 5 ;2;0,1,3,4,5;2 ;4;0,1,2,3,5; 5 ;3;0,1,2,4,5;2 ;5;0,1,2,3,4; 5 ;4;0,1,2,3,5;

(a) The output of the second MH represented intwo columns

M*0 ;1,0;2,3,4,5; 3 ;0,3;1,2,4,5;0 ;2,0;1,3,4,5; 3 ;1,3;0,2,4,5;0 ;3,0;1,2,4,5; 3 ;2,3;0,1,4,5;0 ;4,0;1,2,3,5; 3 ;4,3;0,1,2,5;0 ;5,0;1,2,3,4; 3 ;5,3;0,1,2,4;1 ;0,1;2,3,4,5; 4 ;0,4;1,2,3,5;1 ;2,1;0,3,4,5; 4 ;1,4;0,2,3,5;1 ;3,1;0,2,4,5; 4 ;2,4;0,1,3,5;1 ;4,1;0,2,3,5; 4 ;3,4;0,1,2,5;1 ;5,1;0,2,3,4; 4 ;5,4;0,1,2,3;2 ;0,2;1,3,4,5; 5 ;0,5;1,2,3,4;2 ;1,2;0,3,4,5; 5 ;1,5;0,2,3,4;2 ;3,2;0,1,4,5; 5 ;2,5;0,1,3,4;2 ;4,2;0,1,3,5; 5 ;3,5;0,1,2,4;2 ;5,2;0,1,3,4; 5 ;4,5;0,1,2,3;

(b) The output of the second RH represented intwo columns

Figure 4.11: The outputs after the second iteration

Proposition 4.4. The memory used by a single RH in the kth iteration can be estimated as follows:

∆RHk ≤m ·f + (m−1)!

(m−k)! · (m+ 1) ·f

Proof. Each RH task obtains a key and all values related to this key. The worst case scenario is, whenthe MH generates a line with this key to all possible k-element permutations. Since the given nodecannot be part of the partial mapping, the number of these rows equals to (m−1)!

(m−k)! . Based on 4.2, thesize of each row is less or equal to (m+1) ·f . There is also a row, which is responsible for representingthe connections of the given node. The size of this row is m · f . Therefore, the memory used by asingle RH is no more than:

∆RHk =m ·f + (m−1)!

(m−k)! · (m+ 1) ·f (4.4)

�

4.2.3 Space and Memory Requirements of MRSIS

In contrast to MRSIH , in the algorithm MRSIS only the mappers emit the whole source graph asseparate rows. Therefore, the output sizes of the mappers are calculated as SM

′S

k = s+NM

′S

k ·LM′S

k and

SM

′′S

k = s+NM

′′S

k ·LM′′S

k . In case of the reducers, the output sizes are calculates as SR′S

k = NR

′S

k ·LR′S

k

and SM′′S

k =NM

′′S

k ·LM′′S

k . Moreover, another difference between the algorithms is that MRSIS appliestwo jobs to add a new pair to the partial mapping and to prepare the new candidate nodes.

In the following, the algorithm is examined with the worst case scenario. The worst case scenariois when no candidate node fails to satisfy the feasibility rules, and each node in the graphs have edgesto every other nodes. In this case, there are as many candidate node as possible, and each of themappears in the outputs. An example of the worst case scenario is when the algorithm looks for acomplete graph in another complete graph. Figure 4.8 might serve as a valuable resource to examinethe different propositions.

82


Proposition 4.5. After the kth iteration, the size of the output in case of the M ′S can be estimated

with the following:

SM

′S

k ≤ s+k · m!(m−k)! · (k+ 1) ·f

Proof. As it was already mentioned in Section 4.1.4, M ′S always checks whether the given candidate

node can be mapped to the next target node. The first step is always special, since there are nocandidates prepared to be examined. Therefore, in this case, all nodes of the source graph is examined.The output of this mapper contains the source graph as separate rows and a new row for each successfulmatch. The rows representing the successful match consist of the matched node as the key values andthe current state of the partial mapping.

NM

′S

1 =m LM

′S

1 = (k+ 1) ·f

If k > 1, then the lines to be processed by the M ′S contains not only the candidate node to

examine, but all partial mappings the new candidate node might be added to. The mapper emits acertain number of new line for each partial mapping. In this manner, the worst case scenario is, whenthe number of partial mapping contained by the given line is the maximum. The partial mappings donot contain the candidate node, and consist of k−1 nodes. Therefore, the number of possible orderedsets is equals to (m−1)!

(m−1−(k−1))! = (m−1)!(m−k)! .

The emitted lines are obtained by the reducer functions sorted by their keys, and M ′′S generates

the candidate nodes. This generation is based on the neighboring nodes. Therefore, the new partialmappings must be emitted as a value for each row contained by the partial mapping. This meansthat the same value is emitted k times (the partial mappings now contain the candidate node), sinceafter the kth iteration the cardinality of the partial mapping is k. In worst case scenario, the maximaloutput size of the M ′

S after the kth iteration becomes the following:

NM

′S

k = k ·m · (m−1)!(m−k)! = k · m!

(m−k)! LM

′S

k = (k+ 1) ·f (4.5)

Given the number of emitted lines and the length of each line, in the worst case scenario, the sizeof the output after the kth can be calculated as follows:

SM

′S

k = s+k · m!(m−k)! · (k+ 1) ·f (4.6)

�

Proposition 4.6. After the kth iteration, the size of the output in case of the R′S can be estimated

with the following:

SR

′S

k ≤ s+k2 · m!(m−k)! ·f

Proof. R′S is responsible for generating the appropriate input for M ′′

S , which creates the possiblecandidate nodes for the partial mappings. Therefore, the reducer collects all partial mappings withthe same key, and extends the row representing the node in the source graph with them. In thismanner, each output value of M ′

S is moved to the row representing the exact node that was its keyvalue. The maximum number of ordered sets with k-elements where the key node is contained isk · (m−1)!

(m−k)! . Each of these partial mappings contains k nodes.The row also describes the given node. Therefore, the identity and connections of the node is also

represented in the row. In worst case scenario, the node has an edge to all other source graph nodes.

83


Therefore, the size from the row dedicated to the representation of the node is m ·f . This means thatthe properties of the output are the following:

NR

′S

k =m LR

′S

k =m ·f +k2 · (m−1)!(m−k)! ·f

It has been shown that in case of the worst case scenario, that is, when the most number of rowsare emitted by the R′

S , the size of the output can be calculated as follows:

SR

′S

k =m ·m ·f +m ·k2 · (m−1)!(m−k)! ·f = s+k2 · m!

(m−k)! ·f (4.7)

�

Proposition 4.7. After the kth iteration, the size of the output in case of the M ′′S can be estimated

with the following:SM

′′S

k ≤ s+k · m!(m−k−1)! · (k+ 1) ·f

Proof. M ′′S obtains the output of the R′

S and attempts to create new candidate nodes for each partialmappings found in the given row. The new candidate nodes are generated based on the neighborsof the row. Each neighbor node that is not contained by the partial mapping is emitted with thewhole partial mapping as a new row. In this manner, each partial mapping of a row is emitted with aneighbor that is not yet contained. The number of the not contained neighbors is m−k. The emittedlines contain the candidate node and the partial mapping with k nodes. Therefore, the properties ofthe output are the following:

NM

′′S

k =m · (m−k) ·k · (m−1)!(m−k)! = k · m!

(m−k−1)! LM

′′S

k = (k+ 1) ·f (4.8)

Based on these properties, in the worst case scenario, where the number of the partial mappingsand the number of the neighbor nodes are the most, the size of the output can be calculated as follows:

SM

′′S

k = s+k · m!(m−k−1)! · (k+ 1) ·f (4.9)

�

Proposition 4.8. After the kth iteration, the size of the output in case of the R′′S can be estimated

with the following:SR

′′S

k ≤ s+ m!(m−k−1)! ·k ·f

Proof. R′′S is responsible for generating an output where each candidate node (with its partial map-

ping) is moved to the node representing the node in the source graph. Although M′′S might emit a

candidate node with the same partial mapping multiple times, R′′S emits each partial mapping re-

lated to the candidate node only once. In this manner, the output file consists of m rows where eachrow contains the connections of the node and the possible partial mappings consisting of exactly kelements. The number of the partial mappings equals to the number of ordered subset of k elementsfrom a set of m−1 elements, and each partial mapping contains k elements, therefore:

NR

′′S

k =m LR

′′S

k =m ·f + (m−1)!(m−k−1)! ·k ·f

This means that in the worst case scenario, the size of the output can be calculated as follows:

SR

′′S

k =m ·m ·f +m · (m−1)!(m−k−1)! ·k ·f = s+ m!

(m−k−1)! ·k ·f (4.10)

�

84


Proposition 4.9. The memory used by a single R′S in the kth iteration can be estimated with the

following:∆R

′S

k ≤m ·f + (k · (m−1)!(m−k)! ) · (k+ 1) ·f

Proof. Each reducer task obtains a key and all values related to this key. The worst case scenario isthe following:

On one hand, the reducer obtains the values, where the partial mappings are extended with thekey node. The partial mappings had k−1 nodes before the addition of the key node, therefore, themaximal number of these partial mappings equals to the number of ordered subset of k−1 elementsfrom a set of m−1 elements, i.e. (m−1)!

(m−k)! .On the other hand, the reducer also obtains the values, where the key node n was already part

of the partial mappings. This is required, because the algorithm must be able to extend these partialmappings with the neighbors of the n node as well. These values are created as follows: At the previousM

′S phase, the maximal number of partial mappings with k−1 elements, which already contain the

key node n but not contain the examined node is (k−1) · (m−2)!(m−k)! . (The formula calculating the number

of ordered sets of k elements from a set of m elements, that contains a marked element is k · (m−1)!(m−k)! .)

Since there are m−1 nodes that might extend the partial mappings already containing the n node,the maximal number of such values equals to (k−1) · (m−1)!

(m−k)! .To sum it up, a node can be a key of a row at the kth R

′S phase at most k · (m−1)!

(m−k)! times. Thisequals to the number of different ordered sets with k elements from a set of m elements, where theordered sets contain the n node. As it it described in Eq. (4.5), each row has the length of (k+1) ·f .Moreover, R′

S also obtains the row responsible for describing its connections, which has the length ofm ·f . This means that the input of a single R′

S has the maximum size of:

∆R′S

k =m ·f + (k · (m−1)!(m−k)! ) · (k+ 1) ·f (4.11)

�

Proposition 4.10. The memory used by a single R′′S in the kth iteration can be calculated with the

following:∆R

′′S

k ≤m ·f + (k · (m−1)!(m−k−1)!) · (k+ 1) ·f

Proof. Each reducer obtains all partial mappings related to a candidate node. M ′′S attach each candi-

date node to the partial mapping. The node n appears as a candidate node for each partial mappingswith k elements, where the mapping does not contain the node n. The number of ordered subset ofk elements from a set of m−1 elements equals to (m−1)!

(m−k−1)! .After M ′

S , a partial mapping appears k times, since the algorithm must examine all possibleneighbors as a candidate node. In this manner, the node n can be a key at most k · (m−1)!

(m−k−1)! times.As it has been described in Eq. (4.8), each row has the length of (k+ 1) ·f .

A reducer also obtains the row responsible for describing its connections, which has the length ofm ·f . This means that the input of a R′′

S has the maximum size of:

∆R′′S

k =m ·f + (k · (m−1)!(m−k−1)!) · (k+ 1) ·f (4.12)

�

Proposition 4.11. After the kth iteration, the order of magnitude of the output of the MRSISalgorithm is less or equal to the order of magnitude of the output of the MRSIH algorithm.

SMRSISk ≤ SMRSIH

k

85


Proof. Although s depends on m, since s ≤ m ·m · f , based on the output of the mapper/reducerfunction, s can be omitted from the calculation, if k ≥ 2, because m2 is only a small term in respectto the other addends. Moreover, f is practically a constant multiplier to represent the appropriateseparator character between the nodes.

The worst case scenario is when no candidate node fails to satisfy the feasibility rules. In this casethe order of magnitudes can be calculated as follows.

According to Eq. (4.3), the size of the output of the MRSIH algorithm is the following:

SMHk = SRH

k =O(s+ m!(m−k)! · (m+ 1) ·f) =O(mk+1) (4.13)

According to Eq. (4.6), the output of M ′S of the algorithm MRSIS equals to:

SM

′S

k =O(s+k · m!(m−k)! · (k+ 1) ·f) =O(mk ·k2) (4.14)

According to Eq. (4.7), the size of the output of R′S used in the algorithm MRSIS is:

SR

′S

k =O(s+k2 · m!(m−k)! ·f) =O(mk ·k2) (4.15)

The size of the output produced by the M ′′S of the MRSIS algorithm, based on Eq. (4.9), is the

following:

SM

′′S

k =O(s+k · m!(m−k−1)! · (k+ 1) ·f) =O(mk+1 ·k2) (4.16)

Finally, based on Eq. (4.10), the size of R′′S of the algorithm MRSIS is:

SR

′′S

k =O(s+ m!(m−k−1)! ·k ·f) =O(mk+1 ·k) (4.17)

Since the target graphs are small graphs — this makes it possible to store them in the memory —,and source graphs are greater by multiple order of magnitudes, it can be stated that k�m. Therefore,the order of magnitude of the output produced by theM ′

S and R′S of the algorithmMRSIS is smaller

than the order of magnitude of the output produced by the algorithmMRSIH . The size of the outputof M ′′

S and R′′S of the algorithm MRSIS have the same order of magnitude than the outputs of the

MRSIH algorithm.As for the general case, after k steps, both algorithms provide the same amount of partial map-

pings. However, the algorithm MRSIS checks the feasibility rules in M ′S in contrast to the MRSIH

algorithm that examines the partial mapping in RH . Let b denote the number of candidate node,partial mapping pairs that do not satisfy the feasibility rules in the kth step. The number of rows isdecreased by k · b, since each partial mapping is emitted with all of its nodes as a key.

This results in less data in the output of R′S as well, because all partial mapping appears in one

of the m rows.The output generated by M ′′

S is decreased by k · b · c, where c denotes the number of neighbors ofthe partial mappings rejected in the M ′

S .The output of R′′

S of theMRSIS algorithm consist of all partial mappings and the data responsiblefor describing the connections of the source graphs. This information can be found in the output ofthe RH of the algorithm MRSIH as well and are extended with the candidate nodes. Therefore, thesize of the output of the R′′

S is always smaller, than the output produced by the RH in the MRSIHalgorithm. �

86


The statement is based on the worst case. However, our experimental results show that in case ofthe more common scenarios the MRSIS algorithm produces way smaller outputs, which resulted infaster evaluation. The experimental results are discussed in Section 4.3.

Proposition 4.12. After the kth iteration, the order of magnitude of the memory used by the reducersof the MRSIS algorithm is less or equal to the order of magnitude of the memory used by the reducersof the MRSIH algorithm.

∆R′S

k ≤∆RHk and ∆R

′′S

k ≤∆RHk

Proof. Similarly to Proposition 4.11, the worst case scenario is when no candidate node fails to satisfythe feasibility rules. In this case, the used memory is calculated as follows.

According to Eq. (4.4), the memory used by a single reducer in MRSIH at the kth iteration is thefollowing:

∆RHk =O(m ·f + (m−1)!

(m−k)! · (m+ 1) ·f) =O(mk) (4.18)

The maximum memory used by a single R′S and R

′′S in MRSIS is calculated in Eq. (4.11) and

Eq. (4.12), respectively. Therefore, the orders of magnitude are the followings:

∆R′S

k =m ·f + (k · (m−1)!(m−k)! ) · (k+ 1) ·f =O(m(k−1) ·k2) (4.19)

∆R′′S

k =m ·f + (k · (m−1)!(m−k−1)!) · (k+ 1) ·f =O(mk ·k2) (4.20)

Since the target graphs are small graphs, it can be stated that k2�m. In this manner, the memoryused by a single reducer in MRSIS is smaller or is in the same order of magnitude than the memoryrequired for a reducer instance in MRSIH .

As for the general case, it has been already proven in Proposition 4.11 that the outputs of the M ′S

and M ′′S are smaller, than the output of the MH . Moreover, the candidates that fails to the feasibility

rules in the kth step are not emitted by M ′S , in contrast to the MH . This means that the memory

requirement of the R′S and R′′

S are decreased even further. �

It is important to note, that this regards to the worst case scenario. Since in case of the morecommon graphs the mappers of theMRSIS algorithm produces smaller outputs, its reducers requiresless memory.

Throughout the analysis, only graphs with undirected edges were considered. In case of a graphwith directed edges the following differences might occur:

• There are at most twice as much neighbor nodes, therefore s=m · (f +2 · (m−1) ·f) instead ofs=m ·m ·f .

• It takes f + 2 · (m−1) ·f to describe a node instead of m ·f .

• The maximal numbers of emitted candidates and feasible partial mappings are doubled becauseof the amount of neighbor nodes.

4.2.4 Time Complexity of the Algorithms

As it was mentioned, the primary developing goal was not concerned about the time required to findall isomorphic subgraphs, but to use the algorithms on common and relatively cheap clusters, thetime complexity is an important property of the algorithms.

87


Figure 4.12: The probabilities for edge generation in R-MAT graphs

Since the subgraph isomorphishm is an NP-complete problem in general [Plump, 1998], and theapproaches used in the algorithms do not reduce the searching space, the complexities of both MRSIalgorithms are NP-complete as well.

In general, the complexities of the MRSI algorithms are determined by the number of partialmappings and candidates. These values depend on the source graphs, the target graph, and the orderin which the target graph nodes are examined.

4.3 Experimental ResultsThis section illustrates the efficiency of the presented algorithms by analyzing the space requirementsin sample executions. As it was mentioned before, the algorithms were developed to find the appro-priate subgraphs on a common cluster within a reasonable time frame. Therefore, the results wereobtained on an 8-node cluster provided by the Windows Azure[Windows Azure, 2013]. The clusterwas running Hadoop version 3.1, and contained 40 cores and the total of 48GB memory.

The experiments were made on synthetic Recursive Matrix (R-MAT) graphs[Chakrabarti et al., 2004]. A recursive matrix is a matrix consisting of either terminal symbolsor recursive matrices (as elements). The R-MAT graphs are a special case of stochastic Kroneckergraphs [Leskovec et al., 2005].

R-MAT graphs contain randomly generated edges that link vertices based on a probabilistic model[Plantenga, 2012]. Each vertex identifier is associated to a binary number. The adjacency matrix ispartitioned into four quadrants, and the probabilities t1, t2, t3, and t4 are assigned to them, respectively.These values are recursively applied to the submatrices until two particular node identifiers are selecteddefining a directed edge. A possible division of the adjacency matrix with the probabilities is illustratedin Figure 4.12. The rows of the matrix represent the sources of the edges and the columns representthe targets. In this manner, the probability of having an edge between two nodes whose identifierassigned to numbers in the top half is exactly t1. Similarly, the probability there is an edge from anode assigned to the top half of the adjacency matrix and to a node assigned to the bottom half ofit is t2, and so on. In this manner, t1 + t2 + t3 + t4 = 1.

For example, suppose that the graph has eight nodes. In this case, the probability of having anedge from the third node to the seventh equals to t2 · t4 · t1.

R-MAT graphs are useful in testing because vertex degree exhibits an approximate power lawdistribution similar to many application networks [Plantenga, 2012]. The graphs used throughout thetest are directed graphs and do not contain self-looping edges.

Creating the R-MAT graphs, the probabilities specified by the Graph 500 benchmark[Graph 500 Steering Committee, 2014] are used. These are the following: t1 = 0.57, t2 = t3 = 0.19,and t4 = 0.05. The benchmark also specifies the average degree of a vertex in 16 edges.

88


X

YZ

(a) The TG3 target graph

X

VW

YZ

(b) The TG5 target graph

X

T

U

V W

Y

Z

(c) The TG7 target graph

Figure 4.13: The target graphs

Figure 4.14: The size of the outputs matching the TG5 in R-MAT-10-16-l

Although the data structure used by MRSIH allows of using different heuristics, the followingtests were performed without any additional heuristics.

The target graphs used in the experiment are depicted in Figure 4.13. The nodes are labeled withone of three colors, and the edges are either solid, dashed or dotted directed edges. The graphs containthree, five, and seven nodes, respectively.

The following diagrams present the size of the output generated by the different algorithms aftereach step. The values are the sum of the sizes of the outputs generated by the mapper and the reducerphases. In this manner, the value related to MRSIH in the kth step represents SMH

k +SRHk . Similarly,

SM

′S

k +SR′S

k is represented withMRSI′S , and S

M′′S

k +SR′′S

k withMRSI′′S . The vertical axes of the graphs

use logarithmic scales with base 10.Figure 4.14 depicts the produced outputs when the algorithms looked for the TG5 graph in the

generated R-MAT-10-16-l graph. As its name suggests, the source graph is an R-MAT graph with210 nodes and 16 · 210 = 214 edges, where both the nodes and the edges are labeled. It can be seenthat both MRSI

′S and MRSI

′′S produces smaller outputs than MRSIH , and their sum is smaller as

well. Moreover, since the MRSIS determines the matches in the M ′S phase, the difference between

the produced output in the last step is very large.Figure 4.15 and Figure 4.16 show the produced outputs when the size of the source graph is

increased. This time the source graphs contain 212 and 214 nodes, and 216 and 218 edges, respectively.With the expansion of the size, the gap between the produced outputs increases in each step. Forexample, the difference between the outputs after the third step is approximately 809MB in case ofthe R-MAT-12-16-l, but it is approximately 33GB in case of the R-MAT-14-16-l.

89





90



Figure 4.19: The size of the outputs matching the TG3 graph

Figure 4.17 and Figure 4.18 show the produced outputs when the size of the target graph isincreased. This time the applied target graph is the TG7 graph. The increased number of nodesresulted in more steps. As it can be seen, the sizes of the outputs do not change significantly afterthe third step, but it is probably because of the structure of the target graph.

Figure 4.19 shows the produced outputs when the size of the source graph is increased even further.This time, the test graph is the TG3, which is basically a labeled triangle. The algorithms are appliedon five different R-MAT graphs with the range from 214 to 222 nodes. In the latter case, the numberof the edges equals to 226. The MRSIH was applied only on the first three source graphs. It canbe seen, that the biggest output produced by the MRSIS (i.e. the MRSI

′′S in case of the R-MAT-

22-16-l graph) is way smaller than the biggest output produced by the MRSIH (i.e. in case of theR-MAT-18-16-l).

The experimental results proved that the MRSIS algorithm is more efficient in respect to spacerequirement, than the MRSIH algorithm. However, it is important to note that the experiments did

91


Figure 4.20: The required time for finding all TG3 subgraphs

not take into account the main advantage of the MRSIH , i.e. the application of different heuristicsis well supported, because there is more information available to decide whether the examined nodeshould be added to the partial mapping.

As for the time measurements, Table 4.1 shows the time required to find all subgraphs that areisomorphic to TG3. The experiments were applied on RMAT graphs with the range from 212 to 216

nodes. It can be seen, that the increment of the partial mappings and candidates have a lot moreeffect on the running time of the MRSIH than the MRSIS . This is because of the increment spaceand memory requirements. Figure 4.20 depicts this tendency graphically.

Table 4.1: Matching time to find all subgraphs isomorphic to TG3

MRSIH MRSI′S MRSI

′′S MRSIS

RMAT-12-16-l 243.2s 225.8s 148.4s 374.2sRMAT-14-16-l 785.7s 225.1s 147.1s 372.2sRMAT-16-16-l 5375.4s 258.8s 171.2s 430.0s

Table 4.2 shows the time required to find the subgraphs isomorphic to TG5 when the MRSISalgorithm is applied. This also depicts how the running time increases in case of the explosion of thepartial mappings, and thereby, the candidates.

Table 4.2: Matching time to find all subgraphs isomorphic to TG5

MRSI′S MRSI

′′S MRSIS Matches

RMAT-12-16-l 444.6s 379.1s 823.7s 3000RMAT-14-16-l 349.6s 1397.0s 1746.6s 21702RMAT-16-16-l 2987.5s 31007.1s 33994.6s 252948

Finally, Figure 4.21 presents the time required to find the subgraphs isomorphic to the differenttarget graphs in case of the RMAT-12-16-l source graph. The results show that the increased numberof the partial mappings and candidates, which resulted in greater outputs, has a lot more effect onMRSIH than on MRSIS .

92

4.4. Related Work and Comparison

Figure 4.21: The required time for finding the target graphs in R-MAT-12-16-l

It is important to note, that the measurements were applied on clusters in the cloud, which meansthat the results also contain the time needed to create the connection between the application andthe cluster, and the initialization of each MapReduce job.

4.4 Related Work and ComparisonThis chapter focuses on finding matching subgraphs in a large graph. There is no restriction on thesource graph, it may or may not contain one or more vertex labels or edge labels. The algorithmsdeal with both directed and undirected graphs as well. Although the source graph is not necessarily aconnected graph, the algorithms are capable to find only connected target graphs in the source graph.MRSIH and MRSIS find all matching pattern in the source graph without using random samplingor other approximations.

In order to compare the existing solutions to the MRSI algorithms, Table 4.3 depicts some of thealready published approaches and their main properties. Both MRSIH and MRSIS are representedas MRSI.

The standard method for subgraph isomorphism is the Ullmann algorithm[Ullmann, 1976]. Ituses a backtracking algorithm that significantly reduces the size of the search space. The algorithmis basically a tree-based search that considers all possible node pairings. During the process, thealgorithm allows the integrated comparison of semantic information. The algorithm is commonlyused because it is still one of the fastest and most effective algorithms[Messmer and Bunke, 1995].MRSIH and MRSIS use a different approach that is based on the VF2 algorithm, and are designedto support distributed processing.

Among graph isomorphism algorithms, it is also necessary to mention the Nauty algorithm[McKay, 1981], which transforms the graphs to be matched to a canonical form before checking forthe isomorphism. Even if it is considered one of the fastest graph isomorphism algorithms available,it has been shown that there are categories of graphs for which it employs exponential time. Further-more, it cannot be used for solving the graph-subgraph isomorphism problem. MRSIH and MRSIShandle the graph-subgraph isomorphism problem without transforming the original representation ofthe graphs.

The purpose of the solution presented in [Mezei et al., 2009] is to compute one of the possiblematches for a pattern. The algorithm is executed in a computing grid consisting of several worker

93


Table4.3:

Com

paris

onof

exist

ingap

proa

ches

Bröcheler

Berry

Planten

gaLiu

Zha

oMRSI

Env

iron

ment

Cloud

Cluster

with

shared

mem

ory

Map

Red

uce

Map

Red

uce

Map

Red

uce

Map

Red

uce

Possible

patterns

Arbitr

ary

patterns

Con

nected

compo

nents

st-con

nectivity

Arbitr

ary

patterns

Arbitr

ary

patterns

Trees

Arbitr

ary

patterns

Subg

raph

isom

orph

ism

Exact

Limite

dInexact

Exact

Exact

Exact

Exp

erim

ents

onmassive

data

sets

Yes

Yes

Yes

No

Yes

Yes

Adv

antages

Impressiv

etim

eresults

Heu

ristic

sfor

inexact

subg

raph

isomorph

ism

Walk-level

constraints

Impressiv

etim

eresults

Color-cod

ing

algo

rithm

Impressiv

etim

eresults

Goo

dresults

onsm

allerclusters

Supp

orts

heurist

ics

Disad

vantages

Tim

e-consum

ing

prep

rocessing

Shared

mem

ory

Look

ingfor

pathsthat

resulte

din

moreite

ratio

ns

Needs

the

who

lead

jacenc

ymatrix

The

subg

raph

smustbe

trees

Nosecond

ary

sorting

94

4.4. Related Work and Comparison

and a master node coordinating their operation. The individual worker nodes are performing thesame matching algorithm on the same graph, but the matching is started from different points of thehost graph. The selection of the starting point is coordinated by the master node. Once either of thenodes finds a match, it notifies the master node that lets the other worker nodes stop the algorithm. Incontrast, our algorithm is capable of computing all the possible matches. Another important drawbackof this approach is that it needs the complete host graph to be stored on each worker nodes, while ourapproach is more scalable since the workers always see only a small portion of the complete graph.

The incremental pattern matching introduced in VIATRA2 [Varró et al., 2006] and Inc-Query [Bergmann et al., 2010] utilize the RETE [Forgy, 1974] algorithm to speed up pattern match-ing. The approach is particularly useful if the host graph is changing in time. The main idea ofincremental matching is to store parts of all the possible matches and to reuse them in matchesperformed at a later point in time. In response to changes performed on the host graph, the cachedmatches are adapted to the changes, thus a match for a pattern query can be found in constant time.This solution also has the limitation that the host graph must fit into the memory of a single pc andalso does not utilize multi-core capabilities.

The pattern matching approach presented in [Dörr, 1995] can be used for matching multiple pat-terns having isomorphic sub-patterns at the same time. The algorithm runs on single-core environ-ments, but by discovering the identical parts of the different patterns and performing their matchingat once, it can achieve noticeable performance gain, since only the different parts of the patterns mustbe matched separately afterwards.

Designing multithreaded algorithms is a central part of the current researches in the field ofcomputer science. Bader and Madduri [Bader and Madduri, 2006] developed algorithms for Breadth-First Search, st-connectivity and shortest path for unweighted graphs. These algorithms are designedfor multithreaded architectures, such as the Cray MTA-2. Experimental results are given for graphswith 400 million vertices and 2 billion edges. The algorithms bear a similarity with the work presentedhere because of the used data structure.

The COSI algorithm [Bröcheler et al., 2010] is designed to find subgraphs in large social networks.Experimental results show that its respond time is one second on a graph with 778 million edges.However, the graphs must be partitioned and indexed before the COSI algorithm could be applied.The indexing mechanism is based on the DOGMA algorithm [Bröcheler et al., 2009].

In related work [Berry et al., 2007], Berry et al. developed a parallel implementation for supportingmassive multithreading. The implementation is based on the large shared memory of the machinesin the cluster. The algorithms are designed for finding connected components and st-connectivity.Experimental results were measured on a synthetic power law graph with 234 million edges. Berryalso developed heuristics for inexact subgraph isomorphism [Berry, 2010]. Our approach is capable ofhandling large problems as well with no need for large shared memory.

In [Plantenga, 2012], Plantenga presents a new algorithm, which finds inexact subgraph isomor-phisms. The main contribution of his work is a scalable MapReduce algorithm for finding all type-isomorphic matching subgraphs and also introduces the concept of walk-level constraints. The sug-gested algorithm adds new edges to the already matched ones at each iteration. Experimental resultsare also provided on graphs with size of billions of vertices and edges. The MRSIH and MRSISalgorithms add new node pairs to the already matched nodes, this way the iteration number can bedecreased.

In [Tong et al., 2007], Tong et al. suggest an algorithm that returns a specified number of “besteffort” matches. The complexity of the Graph X-ray algorithms is linear to the number of nodes inthe source graph. In contrast, the MRSIH and MRSIS algorithms return only the exact matchesand can handle not only vertex labels but edge labels as well. Moreover, the parallel implementationof the Graph X-ray algorithm is not presented.

In [Liu et al., 2009], Liu et al. present a MapReduce algorithm for “pattern finding”. Similarly toMRSIH and MRSIS , their algorithm increases the size of partial mappings. However, the algorithm

95


was used on a graph with 2000 edges with a cluster of 48 nodes. Since they assume the full adjacencymatrix is available at each cluster node, the usability of the algorithm in case of graphs with millions ofnodes and edges is questionable. TheMRSIH andMRSIS algorithms do not use the whole adjacencymatrix at each mapper, this way it is more scalable.

Zhao et al. present an algorithm using Hadoop for subgraph analysis in [Zhao et al., 2012]. Thealgorithm is based on a color-coding algorithm and produces good execution time on graph with 500million edges.

Park et al. suggest an efficient algorithm for counting triangles in [Park and Chung, 2013]. Thealgorithm is based on a partition technique that divides the graph into multiple overlapping subgraphsthat together cover all triangles in the graph. Although the algorithm performs good on very largegraphs, it cannot be used on arbitrary target graph, in contrast to the algorithms presented in thischapter.

In [Kim et al., 2013], Kim et al. developed a method to efficiently process multiple graph queriesbased on MapReduce. The method uses a filter-and-verify scheme to reduce the number of subgraphisomorphism test. In contrast to the MRSI algorithms, their work focuses on multiple graph queries.

In remaining related works, Tsourakakis et al. present a MapReduce algo-rithm [Tsourakakis et al., 2009] that counts the total number of triangles in the input graph.Another algorithm using the MapReduce framework is developed by Kang et al. [Kang et al., 2008].Their work shows how to compute diameters of large graphs, such as a webgraph with 1.5 billionnodes, with the MapReduce approach. Karloff et al. [Karloff et al., 2010] propose a model of efficientcomputation using the MapReduce paradigm. In this work the authors shows that a large subclassof PRAM algorithms can be efficiently simulated in their model using MapReduce.

4.5 SummaryNowadays, processing massive data sets is a common task. Since graphs are suitable for representingvariety of data structures, they are frequently used in these enormous data sets. Because of the sizeof the input graphs, the traditional graph algorithms cannot be used effectively. This means there isa need for algorithms that can be easily parallelized.

This chapter has presented the algorithmsMRSIH andMRSIS for finding isomorphic subgraphs.Both algorithms have been designed for the MapReduce framework, which is considered as the de factoplatform for processing large data sets. In order to use the MapReduce framework, an appropriatedata structure has been also developed and described. The data structure used by MRSIH supportsthe application of additional heuristics as well.

The presented algorithms have been compared to each other in regard to space and memoryrequirements. For all mappers and reducers, upper limits were determined for the size of the producedoutputs. Moreover, the maximal memory requirements were also specified for the reducer instances.Based on the analysis, it can be said, that, although the MRSIS uses two MapReduce jobs at eachstep, it turned out to be more efficient in respect of these resources, when no heuristics were applied.However, since MRSIH allows of using heuristics, with the application of the appropriate ones it canbe more efficient than MRSIS .

Since the MRSI algorithms are general in the types of subgraphs that can be matched, it mightlead to slower execution time in contrast to the specialized pattern matching algorithms.

96

5

Inexact Pattern Matching with MapReduce

Finding patterns efficiently in large graphs is a core challenge in the analysis of big data sets. Patternmatching is based on subgraph isomorphism that deals with the problem of deciding if there is aninjective morphism from one graph to another. It is already proven that finding such a morphism isNP-complete in general [Plump, 1998]. To perform the pattern matching efficiently, especially in theprocessing of big data sets, distributed algorithms such as MapReduce gain focus. To find a match,we need a pattern specification language and a matcher algorithm that performs the actual searching.The language may contain special features that make it possible to define not just a single graph butinexact patterns as well. An inexact pattern covers a set of possible exact graphs by using constraints.Being able to detect instances of inexact patterns might be critical in some cases, for example, whenthe analyzer needs to match a general pattern without knowing all of the details, the host graph isnot completely known, or some aspects of the searched pattern is incorrect [Coffman et al., 2004].Moreover, inexact patterns lead to more concise specifications that is an important aspect in graphrewriting-based model transformations [Ehrig et al., 2006].

As an example, consider the graph depicted in Figure 5.1. This graph illustrates the retail banksbelonging to the central bank. The graph also represents the different types of loans the retail banksoffered to their customers. Moreover, the dotted lines between the customers indicate personal rela-

Figure 5.1: Graph representing the Bank-Customer relationships

97

5. Inexact Pattern Matching with MapReduce

(a) (b)

Figure 5.2: The traditional patterns

tionships. Although this example contains only a several dozens of elements, it is easy to see, thata real life example from this field might consist of millions of elements, therefore, its analysis withdistributed methods such as MapReduce can be not only reasonable but inevitable.

Assume that the central bank wants to know the households, where at least two members of thefamily have mortgages. Since it does not matter to the central bank whether the relatives have theirmortgages at the same bank or not, there are two different patterns. In the first case (depicted inFigure 5.2a), the customers have their mortgages at different banks, therefore the pattern shouldmatch two bank elements. However, the family members might get their mortgages from the samebank, and in this case there should be only one bank element matched (depicted in Figure 5.2b). Theanswer is formulated from the union of the two cases.

By the usage of traditional pattern matching languages and solutions, the central bank needs tomatch two different patterns. However, with the help of inexact patterns, a simple pattern can beformulated to answer the question of the central bank. An inexact pattern to solve this problem ispresented in Figure 5.3 (the purpose of the labels is to identify the elements later). The optional blocks(depicted as dotted rectangles) are internal parts of the language our metamodel-based matcher relieson. The language makes it possible to not only use optional blocks, but to define logical relationsbetween them. In our example, the match is only complete if either one or both optional blocks fromthe block A and block B can be matched beside the block C.

In Chapter 4, we presented two MapReduce-based algorithms (MRSIH and MRSIS) that per-form the matching of exact graph patterns. This chapter introduces an adaptation of the MRSISalgorithm to handle inexact matches as well. Therefore, an improved pattern specification languageis introduced that can describe inexact matches, and the improved version of the MapReduce-basedmatcher algorithm, the MapReduce MetaMatcher (MRMM) is presented that is able to handle thenew language. In the design phase, the main goal was to provide advanced language features thatmake it possible to specify inexact pattern and still allow to provide efficient distributed algorithmsfor the matching.

The main contribution of this chapter is to provide an efficient solution for matching both exactand inexact patterns in large graphs. This solution is based on a MapReduce algorithm, which iscurrently the de facto framework for processing large sets of data.

98

5.1. The Pattern Specification Language

Figure 5.3: A simple pattern with optional blocks

5.1 The Pattern Specification LanguageIn this section, the concept to specify inexact graph patterns is introduced. Pattern specificationlanguages are developed with two important goals kept in mind: (i) the language should be expressiveenough to be able to specify possible matches in a concise way. (ii) Moreover, it is important to haveefficient algorithms that can search for the matches. Note, that such specification languages are alsoapplied in graph rewriting-based model transformations where the model transformation rules arespecified by graph patterns.

The most trivial specification language would simply allow us to specify exact patterns, i.e. eachelement that will be present in the match. In other words, a pattern is provided, where the types ofthe nodes and edges along with additional optional constraints are specified, and the actual matcheswill be isomorph occurrences of this pattern. In many cases, one may need more advanced languagefeatures (such as multiplicities, negative application conditions etc.) that lead to inexact patterns.Multiplicities (or cardinalities) added to the nodes and to the ends of the edges mean that the givenelement of the pattern may occur several times in the actual match. With this feature, the patterns ofthe specification language can be turned into small metamodels whose all possible instances that arepresent in the model are valid matches. Two sample patterns (with and without multiplicities) alongwith possible matches are depicted in the first and second columns of Figure 5.4. Colors denote thetypes of the elements. Negative application conditions (NACs) consists of additional elements thatwill not be matched, on the contrary, they must not be able to be found.

The language features detailed above obviously increase the expressiveness of the language, butalso make the match finder algorithms more complex and harder to be implemented. In the following,a pattern specification language is introduced. The goal is to find a good balance between thesetwo aspects. Therefore, this language contains several language features, but has a few limitationscompared to the previously mentioned fully metamodel-based approach.

In theory, patterns of the language consists of nodes and edges. Their types and additional con-straints on their attributes are defined in the usual way. Moreover, groups can be defined in a patternas well. A group is a set of connected nodes. Each node can be a member of at most one group, so thegroups are disjoint. Moreover, it is required that if two nodes are members of two different groups,they cannot have edges between them in the pattern. Multiplicity constraints can be also assignedto the groups. When searching for the possible matches of the pattern, each group can be presentmultiple times according to their multiplicity constraints. The nodes that are not members of anygroups represent single nodes in the matches just as in exact patterns. When an edge of the pattern

99


Figure 5.4: Language features of pattern matchers

rule = "rule", ID, "{", rulebody, "}";rulebody = rulebodyelement, { rulebodyelement };rulebodyelement = node | edge | block | with;node = "node", ID, { labels };labels = "[", ID, { ",", ID }, "]";edge = "edge", ID, "from", ID, "to", ID, labels;block = "block", ID, "(", ID, { ",", ID } ")", blockmultiplicity;with = "with", withexpression;withexpression = ID;blockmultiplicity = "+" | "*" | (INT ’..’ INT) | (INT ’..’ ’*’) ;ID = alphabetic char | digit, { alphabetic char | digit };INT = digit, { digit };

Figure 5.5: The EBNF of the language

connects a group member and a traditional node, this means that the instance of the exact node willbe connected to every instances of the group. The third column of Figure 5.4 shows a sample patternwhere there is one group and its multiplicity is 2..8. This means that at least 2, but at most 8 instancesof the group must be present in a possible match. The figure also presents an instance of the pattern.It can be seen that the node in the top left corner of the pattern is connected to all instances of thegroup. Application conditions (negative and positive) and logical statements on optional blocks canbe specified as well.

We have implemented a textual language. According to the previous concepts, nodes, edges, andblocks with multiplicities can be defined. Nodes and edges may have labels. Additionally, logicalstatements using block identifiers can be specified. The capabilities of the languages in ExtendedBackus-Naur Form (EBNF) is depicted in Figure 5.5. The code belonging to the inexact patternpresented in Figure 5.3 is as follows:

rule MultipleMortgages {node p1 [Person] node l1 [Loan] node b1 [Bank]node p2 [Person] node l2 [Loan] node b2 [Bank]node p3 [Person] node l3 [Loan]edge from p1 to l1 [Mortgage]edge from b1 to p1 [Customer]

100

5.2. The Pattern Matching Algorithm

edge from p1 to p2 [Relationship]edge from p2 to l2 [Mortgage]edge from b2 to p2 [Customer]edge from p1 to p3 [Relationship]edge from b1 to p3 [Customer]edge from p3 to l3 [Mortgage]block A (b2, p2, l2)?block B (b1, p3, l3)?block C (l1)1..*with A or B

}

5.2 The Pattern Matching AlgorithmThe MapReduce MetaMatcher algorithm (MRMM) is a novel approach to detect patterns speci-fied with the language presented above in graphs with millions of edges and vertices. The algorithmis constructed to extend the MapReduce Subgraph Isomorphism - version S algorithm (MRSIS),therefore the pattern matching utilizes the advantageous properties of the MapReduce framework. Inthis manner, the algorithms make it possible to move the pattern matching into the cloud, whichoffers the following benefits: (i) The graph can be stored in the cloud (typically in a BLOB),(ii) the size of the cluster can be dynamically changed depending on the graph and the patternto match. There are a number of different cloud vendors offering these possibilities, for example[Amazon Web Services, 2013] and [Windows Azure, 2013].

As it was mentioned, theMRMM algorithm is based on theMRSIS algorithm, which is presentedin details in Section 4.1.4. Therefore, this section focuses on the extensions, which enable theMRMMalgorithm finding inexact patterns in the source graph.

The main feature of the MRMM algorithm is being capable of detecting patterns with optionalparts. These parts are organized into blocks. The blocks have the following three properties:

• The identifier of the block, which must be unique.

• The identifiers of the nodes contained by the block. None of the nodes can be contained by morethan one block.

• The multiplicity of the block.

Since the algorithm supports optional blocks, that is, the final match is valid with and without thenodes contained by the block as well, the identifiers of the already examined blocks must be maintainedthroughout the MapReduce iterations. This is particularly important in those cases, when a blockcannot be part of a valid partial mapping, because otherwise the algorithm would repeatedly checkthe nodes of this block, causing an infinite loop.

The obligation of maintaining the block identifiers means that the data structure must be extended.The information about the examined blocks is related to the partial mapping, therefore, each partialmapping has an additional value in the outputs, which contains the identifier of the last unsuccessfullymatched block. This information is enough, because of the following:

• The identifier unambiguously determines the block.

• The identifiers of the successfully matched blocks can be deduced from the partial mapping.

• The algorithm orders the nodes of the target graph, therefore, if there are more than oneunsuccessfully matched blocks, the last one determines the previous ones as well.

101


Since theMRSIS algorithm detects isomorphic subgraph patterns, the number of nodes containedby the final match equals to the number of nodes contained by the target graph. However, in case ofthe inexact pattern matching this is not true anymore. Because of the multiplicity of the blocks, thenumber of nodes contained by the valid matches might differ from the number of nodes containedby the target graph. Therefore, the MRMM uses an indicator that signals when at least one partialmapping is extended with a new node pair. In this case, another iteration of MapReduce jobs isjustified. Otherwise, the algorithm terminates.

As it was mentioned, the MRSIS algorithm maintains a sorted list based on the nodes of thetarget graph, which is returned by the GetSortedNodes() method. The MRSIS algorithm simplychooses the first from this list that is not already contained by the partial mapping. In order to enabletheMRMM algorithm to match for blocks, the selection of the next candidate node algorithm appliedin MRSIS must be modified. It must take into consideration whether the last mapped node in thegiven match is part of a block, and if so, then is there any more unmapped node contained by thatblock. The new node selection algorithm is shown in Algorithm 30.

Algorithm 30 The algorithm of selecting the next candidate node for a partial mapping inMRMM

Require: the given partial mapping as actualMatch and the identifier of the last unsuccessfullymatched block as lastBlockId

Ensure: the identifier of the next candidate node1: if actualMatch.isEmpty then2: return GetFirstNode()3:4: Nodes[] sortedNodes← GetSortedNodes()5: Nodes[] possibleNodes← sortedNodes6: if not lastBlockId= null then7: Nodes[] blockNodes← GetUnusedBlockNodes(lastBlockId)8: possibleNodes.Remove(blockNodes)9:

10: Node lastNode← GetNodeById(actualMatch.Last.TargetNode)11: string lastNodeBlockId← lastNode.BlockId12: if not lastNodeBlockId.isEmpty∧ lastNodeBlockId , lastBlockId then13: Nodes[] blockNodes← GetNodesForBlock(lastNodeBlockId)14: if blockNodes.count > 0∧ lastNode , sortedNodes.LastInBlock(blockNodes) then15: return SortedNodes.GetNextFromBlock(lastNode).Id16: if blockNodes.count > 0∧ lastNode= sortedNodes.LastInBlock(blockNodes)

∧ IsBlockStillAnOption(lastNodeBlockId,actualMatch) then17: return sortedNodes.GetF irstInBlock(lastNodeBlockId).Id18:19: for all m|m ∈ actualMatch∧GetNodeById(m.TartgetNode)∈ possibleNodes do20: possibleNodes.Remove(m.TartgetNode)21: Node nextNode← possibleNodes.F irst()22: return nextNode.Id

The algorithm consists of four parts. First, if the partial mapping is empty, then the identifier ofthe first node in the sorted list is returned. The sorted list is created in a way that ensures the firstnode being a mandatory one.

The second part (lines 4–8) filters the possible nodes. The GetUnusedBlockNodes() methodreturns all nodes that are contained by any block that appears before the last unsuccessfully matchedblock in the sorted list. These nodes cannot be part of the candidate nodes because the sorted listalso determines the order of the blocks as well. Thus, the nodes contained by these blocks are either

102

5.3. Analysis of the MRMM Algorithm

already matched or determined as an unsuccessful match. Therefore, these nodes are removed fromthe possible nodes.

The third part (lines 10–17) is responsible for returning the next candidate node when the lastlymatched node was part of a block. In case there are still nodes contained by this block left in the sortedlist, the algorithm returns with the identifier of the first one of these. In case the lastly matched nodewas the last one contained by the block, but the multiplicity of the block indicates another matching,the algorithm returns the first node of the sorted list contained by the block.

Finally, the fourth part (lines 19–22) returns the identifier of the next possible node. This way thealgorithm handles all possibilities regarding to the defined language.

The first mapper function of the MRMM (M ′M ), which is responsible for adding new pairs to the

partial mappings, now might take an optional node as the candidate. In this case the candidate nodeeither extends an optional block currently contained by the partial mapping or not. If it is an extensionthen the algorithm runs as usual, that is, it checks whether the candidate can be mapped, and if so,then emits the extended partial mapping as a value for every node contained by the mapping.

However, if it is not an extension to the last block contained by the partial mapping, that is,this is a new block, then the algorithm emits the initial partial mapping as well, and sets its lastunsuccessfully matched block to the identifier of this block. The initial partial mapping is also emittedas a value for every node contained by the mapping. After the emission of the initial partial mapping,the algorithm checks the new candidate node, and emits the appropriate lines. With this technique,the partial mapping with and without the optional block constitutes two different branches that needto be maintained throughout the whole process.

The second mapper function (M ′′M ), which is responsible for moving the partial mappings to the

row of candidate source graph nodes, also checks, whether the partial mapping contains all non-optional nodes from the target graph. If so, and there is no candidate source node related to thismapping, then the mapping should be marked as a complete match.

The first and second reducer functions (R′M , R′′

M ) are the same that are applied in MRSIS . TheR

′M instances are responsible for moving the partial mappings emitted by the M ′

M instances to theirrelated nodes. In this manner, a R′

M instance emits only one line at a time. This line contains allinformation about the given node, and all partial mappings containing this node.

Since theM ′′M function emits each partial mapping as value for every node that is not contained by

the partial mapping but has at least one edge to/from one of the contained nodes, the R′′M instances

arrange these partial mappings to the appropriate node. In this manner, after the R′′M functions, the

partial mappings appear by every node, where the node might be a possible extension for the givenpartial mapping.

The modifications presented above makes the MRMM algorithm capable of detecting differentpatterns with optional parts. Moreover, the algorithm also possesses the advantageous properties ofthe MRSIS algorithm.

5.3 Analysis of the MRMM AlgorithmAs it was stated in Section 4.2, one of the most expensive operations of the MapReduce frameworkis the transfer of the data between the instances of the different phases. Moreover, regarding to theperformance, the size of the obtained data by a single reducer instance is an important aspect of thealgorithm. Therefore, this section presents the space and memory requirements of the MapReduceMetaMatcher algorithm.

103


5.3.1 Denotations

Like in case of the MRSI algorithms, in worst case scenario, no new candidate node pair fails thefeasibility rules, thus each new candidate pair can be added to the partial mappings, and the degrees ofthe vertices are maximal. In order to compute the upper bounds of the outputs, the analysis considersthe worst case scenario. Moreover, regarding to the size of the outputs, the worst case scenario is,when after one mandatory target graph node, the others are optional, because this way theM ′

M emitstwo kinds of partial mappings: partial mappings containing the optional node, and partial mappingswithout the optional node.

This section utilizes the same denotations that were introduced in Section 4.2.1. In this manner,let GS = (V,E) and GT = (V,E) be the source and target graphs, respectively, LMj

i denote the lengthof each row generated by the jth mapper function after the ith iteration, NMj

i denote the number ofrows generated by the jth mapper function after the ith iteration. Similarly, NRj

i and LRj

i stand for thenumber of rows and the length of each row generated by the jth reducer function after the ith iteration.SMj

i and SRj

i denote the size of the output files generated by the jth mapper/reducer function afterthe ith iteration. M∗ denote the description of the original data structure of the source graph, s bethe space required to represent the M∗, m be the number of nodes contained by the source graph,and f stands for the size required to represent a single node in a line without its incoming/outgoingedges, which is practically the size of the node identifier and an appropriate punctuation. Similarly toSection 4.2, in worst case scenario, which is the perfect graph, s=m ·m ·f , because the size requiredfor representing a single node with its neighbors is m ·f , where (m−1) ·f required for the neighborsand f for the identity. Moreover, ∆ρ

k denote the upper bound of the memory used by a single ρ reducerin the kth iteration.

Finally, let γ denote the number of mandatory elements contained by the given partial mapping.In this manner, the partial mapping with k nodes contains k−γ optional elements.

5.3.2 Space and Memory Requirements of the MRMM Algorithm

Since MRMM is based on MRSIS , only the mappers emit the whole source graph as separate rows.Therefore, the output sizes of the mappers are calculated as SM

′M

k = s+NM

′M

k ·LM′M

k and SM

′′M

k =

s+NM

′′M

k ·LM′′M

k . In case of the reducers, the output sizes are calculates as SR′M

k = NR

′M

k ·LR′M

k and

SM

′′M

k =NM

′′M

k ·LM′′M

k .

Proposition 5.1. After the kth iteration, the size of the output in case of the M ′M can be estimated

by the following inequality:

SM

′M

k ≤ s+k−1∑i=γ

m!(m− i−1)! · (i+ 1) · (2i+ 2) ·f

Proof. The M ′M algorithm is responsible for determining, whether the given candidate node can be

mapped to the next target node. When this mapping is a valid extension to the partial mapping, thenthe algorithm extends the partial mapping with the new node, and emits it. Each partial mapping isemitted for every contained node, where the partial mapping serves as the value and the containednodes as the keys. In this manner, a partial mapping containing k nodes is emitted k times, as avalue.

In case this next target node to map is an optional one, then the algorithm emits the initial partialmapping too, since it is valid without the optional node. The partial mapping without the extensionis emitted multiple times as well.

104


The maximal number of partial mapping waiting for extension equals to the number of possibleordered sets that have at least γ, but at most k− 1 nodes, and do not contain the candidate node.This equals to

∑k−1i=γ

(m−1)!(m−i−1)! . These ordered sets are emitted with and without the new node as well.

The length of each line depends on the partial mapping. Since the line contains the key node andthe partial mapping, thus the number of emitted nodes at each line is at least γ+ 1 and at most k.Therefore, in worst case scenario, the maximal output size of the M ′

M after the kth iteration becomesthe following:

NM

′M

k =m · (k−1∑i=γ

(m−1)!(m− i−1)! · (i+ 1) +

k−1∑i=γ

(m−1)!(m− i−1)! · i) =

k−1∑i=γ

m!(m− i−1)! · (2i+ 1)

LM

′M

k ={

(i+ 2) ·f, if the new optional pair is added to the partial mapping(i+ 1) ·f, if the new optional pair is not added to the partial mapping

Given the number of emitted lines and the length of each line, in the worst case scenario, the sizeof the output after the kth can be calculated as follows:

SM

′M

k = s+k−1∑i=γ

m!(m− i−1)! · (i+ 1) · (i+ 2) ·f +

k−1∑i=γ

m!(m− i−1)! · i · (i+ 1) ·f

= s+k−1∑i=γ

m!(m− i−1)! · (i+ 1) · (2i+ 2) ·f (5.1)

�

Proposition 5.2. After the kth iteration, the size of the output in case of the R′M can be estimated

with the following:

SR

′M

k ≤ s+k∑i=γ

i2 · m!(m− i)! ·f

Proof. A R′M instance collects all partial mappings with the same key, and extends the row repre-

senting the node in the source graph with them. In this manner, each output value of M ′M is moved

to the row representing the exact node that was its key value. The maximum number of ordered setswith at least γ and at most k-elements where the key node is contained is

∑ki=γ i ·

(m−1)!(m−i)! . Each of

these partial mappings contains i nodes.The row also describes the given node. Therefore, the identity and connections of the node is also

represented in the row. In worst case scenario, the node has an edge to all other source graph nodes.Therefore, the size from the row dedicated to the representation of the node is m ·f . This means thatthe properties of the output are the following:

NR

′M

k =m

LR

′M

k =m ·f +k∑i=γ

i2 · (m−1)!(m− i)! ·f

It has been shown that in case of the worst case scenario, that is, when the most number of rowsare emitted by the R′

M , the size of the output can be calculated as follows:

SR

′M

k =m ·m ·f +m ·k∑i=γ

i2 · (m−1)!(m− i)! ·f = s+

k∑i=γ

i2 · m!(m− i)! ·f (5.2)

�

105


Proposition 5.3. After the kth iteration, the size of the output in case of the M ′′M can be estimated

with the following:

SM

′′M

k ≤ s+k∑i=γ

m!(m− i−1)! · i · (i+ 1) ·f

Proof. The M ′′M instances are responsible for creating new candidate nodes for each partial mappings

found in the given row. The new candidate nodes are generated based on the neighbors of the row.Each neighbor node that is not contained by the partial mapping is emitted with the whole partialmapping as a new row. In this manner, each partial mapping of a row is emitted with a neighborthat is not yet contained. The number of the not contained neighbors is m− i, where i represents thenumber of node contained by the partial mapping. The emitted lines contain the candidate node andthe partial mapping with i nodes. Therefore, the properties of the output are the following:

NM

′′M

k =m ·k∑i=γ

(m− i) · i · (m−1)!(m− i)! =

k∑i=γ

i · m!(m− i−1)!

LM

′′M

k = (i+ 1) ·f

Based on these properties, in the worst case scenario, where the number of the partial mappingsand the number of the neighbor nodes are the most, the size of the output can be calculated as follows:

SM

′′M

k = s+k∑i=γ

i · m!(m− i−1)! · (i+ 1) ·f (5.3)

�

Proposition 5.4. After the kth iteration, the size of the output in case of the R′′M can be estimated

with the following:

SR

′′M

k ≤ s+k∑i=γ

m!(m− i−1)! · i ·f

Proof. The R′′M instances are responsible for generating outputs where each candidate node (with

its partial mapping) is moved to the node representing the node in the source graph. Although M ′′M

might emit a candidate node with the same partial mapping multiple times, R′′M emits each partial

mapping related to the candidate node only once. In this manner, the output file consists of m rowswhere each row contains the connections of the node and the possible partial mappings consisting ofγ–k elements. The number of the partial mappings equals to the number of ordered subset of γ–kelements from a set of m−1 elements, and each partial mapping contains γ–k elements, therefore:

NR

′′M

k =m

LR

′′M

k =m ·f +k∑i=γ

(m−1)!(m− i−1)! · i ·f

This means that in the worst case scenario, the size of the output can be calculated as follows:

SR

′′M

k =m ·m ·f +m ·k∑i=γ

(m−1)!(m− i−1)! · i ·f = s+

k∑i=γ

m!(m− i−1)! · i ·f (5.4)

�

106


Proposition 5.5. The memory used by a single R′M in the kth iteration can be estimated with the

following:

∆R′M

k ≤m ·f +k−1∑i=γ

(m−1)!(m− i−1)! · (i+ 1) · (2i+ 2) ·f

Proof. As Proposition 5.1 stated, in worst case scenario, the size of the output in case of the M ′M

can be estimated with s+∑k−1i=γ

m!(m−i−1)! · (i+ 1) · (2i+ 2) ·f . The worst case scenario means that the

degrees of the vertices are maximal and no new candidate node pairs fails the feasibility rules. In thismanner, the M ′

M instance emit the same number of lines for each node. Moreover, the number of anode emitted as key are the same as well. Therefore, the memory occupied by a single R′

M is thefollowing:

∆R′M

k =s+

∑k−1i=γ

m!(m−i−1)! · (i+ 1) · (2i+ 2) ·f

m

=m ·f +k−1∑i=γ

(m−1)!(m− i−1)! · (i+ 1) · (2i+ 2) ·f (5.5)

�

Proposition 5.6. The memory used by a single R′′M in the kth iteration can be calculated with the

following:

∆R′′M

k ≤m ·f +k∑i=γ

(m−1)!(m− i−1)! · i · (i+ 1) ·f

Proof. Proposition 5.3 stated, in worst case scenario, the size of the output in case of the M ′′M can be

estimated with s+∑ki=γ

m!(m−i−1)! · i · (i+1) ·f . The proposition assumed the worst case scenario, that

is, the degrees of the vertices are maximal and no new candidate node pairs fails the feasibility rules.This means, the number of a node emitted as a key is the same for each node. In this manner, thememory required by a single R′′

M instance can be calculated as follows:

∆R′M

k =s+

∑ki=γ

m!(m−i−1)! · i · (i+ 1) ·f

m

=m ·f +k∑i=γ

(m−1)!(m− i−1)! · i · (i+ 1) ·f (5.6)

�

Throughout the analysis, only graphs with undirected edges were considered. In case of a graphwith directed edges the following differences might occur:

• There are at most twice as much neighbor nodes, therefore s=m · (f +2 · (m−1) ·f) instead ofs=m ·m ·f .

• It takes f + 2 · (m−1) ·f to describe a node instead of m ·f .

• The maximal numbers of emitted candidates and feasible partial mappings are doubled becauseof the amount of neighbor nodes.

107


X

YZ

A

0..1

(a) The TG3WO target graph

X

VW

YZ

0..2

(b) The TG5WO target graph

X

T

U

V W

Y

Z0..1 0..1

(c) The TG7WO target graph

Figure 5.6: The target graphss with optional blocks

Figure 5.7: The size of the outputs matching the TG5WO in R-MAT-10-16-l

5.4 Experimental ResultsThis section illustrates the efficiency of the MRMM algorithm by analyzing the space requirementsin sample executions. The algorithm is based on the MRSIS algorithm, which was developed tofind the appropriate subgraphs on a common cluster within a reasonable time frame. Therefore, theresults were obtained on an 8-node cluster provided by the Windows Azure[Windows Azure, 2013].The cluster was running Hadoop version 3.1, and contained 40 cores and the total of 48GB memory,runningWindows Server 2012 R2 Datacenter. The experiments were carried out on synthetic RecursiveMatrix (R-MAT) graphs, which was presented in Section 4.3.

The target graphs are depicted in Figure 5.6. The nodes are labeled with one of three colors, andthe edges between the nodes are either solid, dashed or dotted. The optional blocks are depicted withsolid rectangles along with their multiplicity.

The following diagrams present the size of the output generated by the MRMM algorithm aftereach step. The values are the sum of the sizes of the outputs generated by the mapper and thereducer phases. In this manner, the value in the kth step represents SM

′M

k +SR

′M

k for MRMM′ , and

SM

′′M

k +SR

′′M

k for MRMM′′ . The vertical axes of the graphs use logarithmic scales with base 10.

Figure 5.7 depicts the produced outputs when the algorithms looked for the TG5WO graph inthe generated R-MAT-10-16-l graph. The source graph is an R-MAT graph with 210 nodes and16 · 210 = 214 edges, where both the nodes and the edges are labeled. It can be seen that after thesteps 4 and 6 the produced outputs are increased with an order of magnitude. This is because at these

108




steps the algorithm examines the first nodes of the optional blocks and emitted the partial mappingswith and without the addition of the new matches as well. After step 5, the size of the output doesnot change significantly, because the algorithm deals with only the partial mappings containing thefirst node of the given optional block.

Figure 5.8 shows the produced outputs when the size of the source graph is increased. This timethe source graphs contain 212 nodes, and 216 edges. With the expansion of the size, the gap betweenthe outputs produced when the algorithm examines mandatory elements and new optional blocksincreases even further. For example, in case of the MRMM

′′ , the difference between the outputsafter the third and fourth steps is approximately 240MB, but it is approximately 12GB between theoutputs after the fifth and sixth steps.

Figure 5.9 and Figure 5.10 show the produced outputs when the size of the target graph isincreased. This time the applied target graph is the TG7WO graph. The increased number of nodesresulted in more steps. As it can be seen, the sizes of the outputs do not change significantly betweenthe third and sixth steps, mainly because of the structure of the target graph. However, the appearanceof the optional blocks greatly increased the produced outputs.

Figure 5.11 shows the produced outputs when the size of the source graph is increased evenfurther. This time, the test graph is the TG3WO, which is basically a labeled triangle extended withan optional element. The algorithm was applied on five different R-MAT graphs with the range from214 to 222 nodes. In the latter case, the number of the edges equals to 226. It can be seen, that as

109



Figure 5.11: The size of the outputs matching the TG3WO graph

the size of the source graphs increases, the size of the output after the fourth step nears the otheroutputs.

The experimental results proved that the MRMM algorithm effectively finds all subgraphs thatare isomorphic to the inexact target graphs. However, since the algorithm must maintain both theinitial and the extended versions of the partial mappings, with the increasing size of the source and/ortarget graphs, the space and memory requirements might cause problems even in case of commonsized clusters.

As for the time measurements, Table 5.1 shows the time required to find all subgraphs that areisomorphic to TG3WO. The experiments were applied on RMAT graphs with the range from 212 to216 nodes. Figure 5.12 depicts this tendency graphically.

It is important to note, that the measurements were applied on clusters in the cloud, which meansthat the results also contain the time needed to create the connection between the application andthe cluster, and the initialization of each MapReduce job.

110

5.5. Summary

Table 5.1: Matching time to find all subgraphs isomorphic to TG3WO

MRMM′

MRMM′′

MRMM

RMAT-12-16-l 341,7s 257,0s 598,7sRMAT-14-16-l 346,3s 238,9s 585,2sRMAT-16-16-l 351,2s 271,3s 622,5sRMAT-18-16-l 477,0s 543,9s 1020,9sRMAT-20-16-l 1488,9s 1120,3s 2609,2sRMAT-22-16-l 3501,9s 5573,0s 9074,9s

Figure 5.12: The required time for finding all TG3WO subgraphs

5.5 SummaryIn this chapter, a new pattern specification language has been introduced. The presented conceptmakes it possible to define inexact patterns in a concise way. The algorithm MRMM has been alsopresented, which is a MapReduce-based method for detecting inexact patterns in large graphs. Thealgorithm finds all subgraphs corresponding to the defined pattern in the host graph.

The MapReduce framework is designed to support processing large data sets. Therefore, it canbe suitable for graph related algorithms if the graphs are represented as textual files. In this chapter,the applied data structure has also been described.

Since the MRSIS algorithm, on which the MRMM is based, was presented in Chapter 4, thischapter has focused on the description of the new language concept and the new matcher algorithm.

The chapter has also presented the detailed evaluation of the performance. Since the MapReduceframework is not optimized for I/O operations, the sizes of the produced outputs are critical.

The experiences collected during the application of this new approach have been also presented.The performed measurements showed that finding all possible matches, when the number of optionalblocks and the size of the source graph are getting higher and bigger, the space and memory re-quirements might cause problems in case of smaller clusters. However, the algorithm is proved to beeffective and usable.

111

6

Optimizing the VF2 Algorithm

It was mentioned that model-driven software engineering is a popular approach in the field of softwaredevelopment. It is often based on model transformation, which is used throughout a wide spectrumof the development phases. Since model transformations appear in numerous scenarios, there is anobvious need for tools and techniques regarding their operational support. There are research groupsconcentrating on how to express model transformations and how they can be supported appropri-ately using different tools [Lara and Guerra, 2010]. Other research results [de Lara and Varró, 2010][Koehler et al., 2007] analyze the different development phases of a model transformation and dealwith their specification and implementation [Fehér and Lengyel, 2012]. This chapter focuses on theefficiency of the model transformation process.

Graphs are commonly used to represent a variety of data structures. By attributing the nodes andedges, graphs are effectively used in modeling different states of a system, solving traffic problems,representing relationship between the different parts of the software and/or modeling the structureof chemical elements. Moreover, their strong mathematical background is another advantageous pro-perty. Therefore, graphs have gained significant attention within the scientific community.

There are several algorithms to identify graph-subgraph isomorphisms, which methods are essentialparts of the graph rewriting-based model transformation approaches. Since it is already proven thatsubgraph isomorphism is NP complete [Plump, 1998], the different approaches attempt to reduce thecomputational complexity. Therefore, some algorithms define restrictions towards the structure of thegraphs, others attempt to reduce the searching space at each iteration.

Currently the VF2 algorithm [Cordella et al., 2004] is a popular approach to locate complete orgraph-subgraph isomorphisms. Experimental results have shown their efficiency, particularly regard-ing large graphs [Foggia et al., 2001]. However, in the case of model transformation approaches, theperformance of the pattern matching algorithms has a significant influence on the entire transforma-tion process. Therefore, it remains essential to increase the performance of the matching.

The goal of the presented approach is to increase the efficiency of the development and quality ofthe software artifacts.

The rest of this chapter is organized as follows: Section 6.1 includes the introduction of theVF2 algorithm. Section 6.2 provides a method to increase the performance of the VF2 algorithm.Section 6.3 presents a supportive ordering function. Section 6.4 introduces our experimental results.Finally, concluding remarks are elaborated.

6.1 The VF2 AlgorithmThe VF2 algorithm presented in [Cordella et al., 2004] and [Cordella et al., 2001] is an updated ver-sion of the VF algorithm [Cordella et al., 1998] from the same authors. The main difference between

112

6.1. The VF2 Algorithm

MHost(s)MLHS(s)

T inHost(s)

T outHost(s)

T outLHS(s)

T inLHS(s)

GHost GLHS

Figure 6.1: The different node sets in VF2

the two versions is the applied data structure, but the generation of the candidate node pairs —whichis the scope of this chapter— remains the same.

Let us consider two graphs GHost = (NHost,EHost) and GLHS = (NLHS ,ELHS) as depicted inFigure 6.1 where the solid lines represent the edges of the graphs and the nodes are labelled withdifferent colors. During the matching process, the algorithm determines the mapping M , which as-sociates nodes from GHost to nodes of GLHS . These associations are depicted by the dotted lines.Basically, M is a set of (n,m) pairs, where n ∈ NHost and m ∈ NLHS and each pair represents amapping of a node n from GHost with a node m from GLHS .

The VF2 algorithm uses the State Space Representation (SSR) [Nilsson, 1982] to describe a givenstate of the matching process. Each state s is a partial mapping solution, which is a subset of the M .This partial mapping solution (M(s)) contains only some elements of M . In the SSR, the transitionbetween two states is the addition of a new (n,m) node pair.

In order to reduce the searching space, the algorithm applies some coherence conditions at eachstate – si (si ⊂M) – from s0 to the final, isomorphic state. For example, it is required that the partialmappings are isomorphisms between the subgraphs. If the addition of an (n,m) pair to the M(s)does not meet the coherence conditions, then the examination of that path is unnecessary becausethe path will not arrive at the final state.

The effectiveness of the VF2 algorithm is the ability to determine if the state s has no successors,i.e. further states, following a number of steps that meet the coherence conditions. This examinationof s is done by the, so called, feasibility rules. Naturally, these rules should detect if s has no coherentsuccessors as early as is possible. In doing so, the rules assist in reducing as much of the searchingspace as is possible. If the rule determines whether the given state s, with the addition of the pair(n,m), can establish coherence successors in the next k step, then the rule implements a k-look-ahead.

The VF2 algorithm specifies five feasibility rules to check isomorphism, each of which regards thesyntax of the graphs. Moreover, the two 0-look-ahead rules ensure necessary and sufficient conditionsfor coherence. The other rules’ main functions are to reduce the searching space. The feasibility rulesare the following [Cordella et al., 2004]:

• The RPred 0-look-ahead rule states that each predecessor n′ of n in the partial mapping belongsto the node m′, which is a predecessor of m. The inverse of this rule is also true, that is, eachpredecessor m′ of m in the partial mapping belongs to the node n′, which is a predecessor of n.

• The RSucc 0-look-ahead rule states that each successor n′ of n in the partial mapping belongsto the node m′, which is a successor of m. The inverse of this rule is also true.

• The RIn 1-look-ahead rule states that the number of predecessors (successors) of n that are inT inHost(s) is equal to the number of predecessors (successors) of m that are present in T inLHS(s).

• The ROut 1-look-ahead rule states that the number of predecessors (successors) of n that are inT outHost(s) is equal to the number of predecessors (successors) of m that are present in T outLHS(s).

113

6. Optimizing the VF2 Algorithm

• The RNew 2-look-ahead rule states that the number of predecessors (successors) of n that areneither in MHost(s) nor in THost(s) is equal to the number of predecessors (successors) of mthat are neither present in MLHS(s) nor in TLHS(s).

During the presentation of the feasibility rules, some new sets were introduced. The T inHost(s) andthe T inLHS(s) sets stand for the nodes that have ongoing edges to the two subgraphs in state s andare not in the MHost(s), MLHS(s) respectively. Similarly, the T outHost(s) and the T outLHS(s) sets containnodes that have incoming edges from the subgraphs in the given state and are not a part of the partialmappings. Moreover, THost(s) = T outHost(s)∪T inHost(s) and TLHS(s) = T outLHS(s)∪T inLHS(s). These sets aredepicted in Figure 6.1 as well.

In the case of graph-subgraph isomorphism, these original feasibility rules need to be slightlyaltered. Since the algorithm is looking for subgraph isomorphism, the RPred and RSucc rules cannotcheck whether all predecessor/successor n′ of n (n ∈GHost) in the partial mapping belongs to a nodefrom the LHS graph. This is due to the lack of certainty that the edge between n and n′ is part of thesubgraph as well. However, the other part of the rule has to be checked, i.e. all predecessor/successorm′ofm (m∈GLHS) in the partial mapping has to belong to the node n′, which is a predecessor/successorof n. This is upheld because every edge in the LHS graph has to appear in the host graph.

The only difference in the RIn and ROut rules, regarding subgraph matching, is the change of theequals (=) sign to a greater than (>) sign. The reason for this change is because a node in the hostgraph can have more predecessors/successors than its matched pair in the LHS graph.

The final feasibility rule is not applicable in case of graph-subgraph isomorphism and necessitatesa greater change; therefore it is not applied in the algorithms discussed in this chapter.

At each state the VF2 algorithm generates a set of candidate node pairs, denoted as P (s). Thesenode pairs are checking if the feasibility rules are met and can be added to the partial mappingM(s).Following each addition, the VF2 algorithm generates the candidate node pairs again and checksthem against the rules. If there is no candidate pair that meets the feasibility rules then the algorithmsimply backtracks and drops that candidate node pair.

The algorithm that constructs P (s) is shown in Algorithm 31. In this context, min refers to thenode in T outLHS(s), which contains the smallest label (actually, any other total ordering criterion couldbe applied) [Cordella et al., 2001].

Algorithm 31 Generation of candidate pairs in the VF2 algorithm1: procedure GenerateCandidatePairs()2: if T outHost(s) , ∅ and T outLHS(s) , ∅ then3: P (s)← T outHost(s)×{min(T outLHS(s))}4: else if T inHost(s) , ∅ and T inLHS(s) , ∅ then5: P (s)← T inHost(s)×{min(T inLHS(s))}6: else7: P (s)← (NHost−MHost(s))×{min(NLHS−MLHS(s))}8:9: return P (s)

It is important to note, in order to ascertain there is no match between the host and the LHSgraph, the VF2 has to check all candidate node pairs. This means that the efficiency of the algorithmcan be increased if the cardinality of the checked candidate node pairs is reduced.

It also worth mentioning that the rest of the chapter uses undirected graphs. However, this hasno effect on the operation of VF2 algorithm.

114

6.2. Candidate Pair Number Reduction

A

B

C D

EF

G

H I

J

(a) The Host graph (Petersen)

X Y

T

Z

Q

(b) 1st LHS graph

Figure 6.2: Partial mapping

6.2 Candidate Pair Number ReductionThe original construction of the candidate node pairs does not consider the success of the previouscandidates, nor the last added nodes. It simply creates the node pairs and selects one to check againstthe feasibility rules. Assume the following partial mapping : M(s) = {(A,X),(B,Y ),(C,Z)} as it isdepicted in Figure 6.2. The nodes contained by the partial mapping are blue and the ones in the Tsets are red. If the last added pair was (C,Z), the THost, TLHS sets and the candidate node pairs arethe following:

• THost = {D,E,F,G,H}

• TLHS = {Q,T}

• P (s) = {(D,Q),(D,T ),(E,Q),(E,T ),(F,Q),(F,T ),(G,Q),(G,T ),(H,Q),(H,T )}

Note that node Z has only one successor that is not part of the partial mapping (node Q). Thismeans that, if Q cannot be mapped, this path cannot lead to a complete match, regardless of whethernode T can be mapped or not. Moreover, there is no need to check the candidate node pairs thatcontain T if Q cannot be matched. This way the number of checks can be significantly reduced,depending on the graph structures.

Based on the example, it may be worthwhile to check the node pairs that contain the Q node.In this specific example, the (E,Q), (F,Q) and (G,Q) candidate pairs do not satisfy the feasibilityrules, whereas both the (D,Q) and (H,Q) pairs meet the feasibility rules and can be added to themappings. However, the algorithm then backtracks in both cases, since the last node (T ) cannot beadded without breaking the first two feasibility rules. This means that the algorithm returns to themapping defined above but P (s) does not contain any node pair containing the Q node. Thus, P (s)does not contain any node from the LHS graph that is a successor of the Z node. This means that thealgorithm cannot match the Q node to any node in the host graph in this partial mapping, thereforefurther examination of the other candidate pairs is unnecessary and the algorithm can backtrack.There is no need to check the other five candidate node pairs because they cannot lead to a finalstate. This way, the performance of the VF2 algorithm can be increased since fewer node pair checksare required.

The algorithm described above is shown in Algorithm 32. It first generates possible candidatenode pairs as it is created in the original VF2 algorithm; then creates the SuccList list. This contains

115


Algorithm 32 Extension for the procedure that generates candidate node pairsRequire: m ∈MLHS

1: procedure GenerateCandidatePairsExtended(Node m)

2: P (s)←GenerateCandidatePairs()3: SuccList←∅4: PredList←∅5:6: SuccList←∀n|n ∈ succ(GLHS ,m),n <MLHS

7: if #{SuccList}> 0 then8: return GetPairsFromLists(SuccList,P (s))9:

10: PredList←∀n|n ∈ pred(GLHS ,m),n <MLHS

11: if #{PredList}> 0 then12: return GetPairsFromLists(PredList,P (s))13:14: return P (s)

all nodes from the LHS graph that are successors of the given node m and not yet part of the partialmapping. The procedure gets the m node as a parameter, which is the last added LHS node. If thisSuccList variable is not an empty set, then GetPairsFromLists is used with the SuccList as wellas the list containing the original candidate node pairs as parameters. Finally, it returns with theresult of the method.

If the SuccList is empty, then the PredList is created. This list contains the predecessors of mthat are not part of the mapping. If PredList is not empty, then the GetPairsFromLists is usedbut this time the PredList is passed and its result is returned. If both lists are empty, then thealgorithm returns with the original list of candidate pairs and it cannot improve the efficiency. TheGetPairsFromLists is shown in Algorithm 33.

Algorithm 33 Generate the candidate node pairs1: procedure GetPairsFromLists

(NodeList Neighbors, NodePairList Candidates)2: Q←∅3: if ∃n|n ∈Neighbors,@n′ : (n′,n) < Candidates then4: return ∅5: else6: for all (l,n) ∈ Candidates do7: if n ∈Neighbors then8: add (l,n) to Q9: return Q

The GetPairsFromLists retrieves two parameters. The first is a list of nodes that containseither the successors or the predecessors of a LHS node that are not part of the current mapping.The second parameter contains the candidate node pairs. The algorithm simply checks if there existsa node in the successors/predecessors which is not part of any pairs of the candidate list. If thereis such a node then it is not worth examining this partial mapping further because there will exista node in the LHS graph that cannot be mapped. Thus, the procedure returns with an empty set.Otherwise, the algorithm creates a list that contains only the node pairs which have the LHS part

116

6.3. Ordering the Candidate Pairs

from the given successors or predecessors. When this list is created, the procedure returns with it.The VF2 algorithm examines the feasibility rules on these list items.

The modified generation algorithm, as it is presented in Section 6.4, improves the performance ofthe VF2 algorithm. Table 6.1 demonstrates that in this way, the number of required feasible checksis reduced significantly.

6.3 Ordering the Candidate PairsIn Section 6.1 it was mentioned that the VF2 algorithm uses an ordering function during the gener-ation of the candidate node pairs. Therefore, this ordering function also affects the efficiency of thealgorithm.

In the previous section, a modified algorithm was proposed in order to increase the performanceof the VF2 algorithm. The main objective of this approach is to ensure that the algorithm backtracksimmediately when there is a successor/predecessor of the last added LHS node, which is not a partof any candidate node pair. This means that the algorithm should systematically select the nextcandidate pair to achieve this state as soon as possible.

Algorithm 34 Generate the candidate node pairs with ordering function1: procedure GetPairsFromLists

(NodeList Neighbors, NodePairList Candidates)2: Q←∅3: if ∃n|n ∈Neighbors,(l,n) < Candidates then4: return ∅5: else6: z← GetMinOccurrence(Neighbors,Candidates)7: for all (l,n) ∈ Candidates do8: if n= z then9: add (l,n) to Q10: return Q

When a new node pair is added to the partial mapping, the cardinality of each LHS node in thecandidate node pairs is equal. Figure 6.2 shows that two LHS nodes are part of the candidate nodepairs: node Q and node T . Both nodes contain five candidate pairs. At this moment, any of the pairscould be selected. For example, assume that the (F,Q) node pair is selected. As was discussed earlier,this pair fails the first feasibility rule and, therefore, the algorithm drops it. In the next step thereare only nine different candidate node pairs. Five of them contains the T node, but only four the Qnode. Since the algorithm backtracks at the moment an LHS node is not contained by any candidatenode pair, it should attempt to reach such a state. In this particular example, this indicates that thealgorithm will select from the node pairs containing the Q node. Therefore, it is guaranteed to find,in four steps, a new feasible pair or it will backtrack. Considering this, the GetPairsFromLists ismodified as it is shown in Algorithm 34.

The second half of this algorithm differs from the previous one in the following ways. If all LHSnodes appear in the candidate pairs, then the algorithm select the node that has the fewest occurrencesin the set of candidate pairs. This is done by the GetMinOccurrence method. Finally, it returnsall pairs, which contain this particular node.

117


A

B

C D

EF

G

H I

J

(a) The Petersen graph

AB

C

D

E

FG

H

I

J

K

L

(b) A vertex-transitive graph

ABC

D

E

F

G

H

I

JK

L M NO

P

Q

R

S

T

U

VW

X

(c) A t-transitive graph (t>=2)

Figure 6.3: The example host graphs

6.4 Performance AnalysisThe previous two sections presented a modified algorithm to produce candidate node pairs and anordering function, which is well adjusted to this modified algorithm. To examine the effects of thenew approaches, experimental results have been measured.

In the examples below, the VF2 attempts to identify a match between three host graphs and fiveLHS graphs. In each case, the algorithm uses three different approaches:

• The first approach uses the default algorithm to generate candidate pairs without any orderingfunction.

• The second approach uses the modified algorithm, described in Section 6.2, and backtracks whena node from the LHS graph does not appear in the candidate pairs. It does not use any specificordering function.

118

6.4. Performance Analysis

X Y

T

Z

Q

(a) 1st LHS graph

X Y

Z

(b) 2nd LHS graph

X

Y

Z Q

T

W

(c) 3rd LHS graph

X

Y

Z

Q

W

(d) 4th LHS graph

X Y

T

Z

(e) 5th LHS graph

Figure 6.4: Example LHS graphs

Table 6.1: Comparison of the algorithms

Petersen Vertex-tran T-transitiveOrig. Mod. Ord. Orig. Mod. Ord. Orig. Mod. Ord.

1st LHS 12830 7465 6320 13764 5754 4344 19272 9636 79682nd LHS 210 180 120 3 3 3 504 432 2883rd LHS 39360 4970 6180 39168 6248 6048 29952 7574 64804th LHS 34850 27620 10280 29724 22986 8808 83640 66288 246725th LHS 7 7 7 5 5 5 7 7 7

• The third approach combines the modified approach with the ordering function presented inSection 6.3.

Some highly symmetric graphs have been chosen as host graphs to ensure the possibility of afrequent occurrence of backtracking. The host graphs are the followings:

• The Petersen graph: Figure 6.3a.

• A vertex-transitive graph: Figure 6.3b.

• A t-transitive graph: Figure 6.3c.

The LHS graphs are shown in Figure 6.4. Only the fifth LHS graph can be found in each hostgraph, and the second one is a subgraph of the vertex-transitive host graph.

Table 6.1 presents how often the feasibility rules are checked in the different cases: The Orig.columns regard the original VF2 approach, the Mod. columns to the algorithm including the modifiedcandidate pair generation and the Ord. columns refer to the modified algorithm with the presentedordering function.

The results indicate that the modified algorithm performs more efficiently, in every case when theLHS graph cannot be found in the host graph. Provided the ordering function, even better results are

119


possible. Although, as is the case in the third LHS graph – the Petersen graph – it does not necessarilyperform better. However, the Ordered version can perform as much as 6 times more effective than theOriginal.

Based on the results, the efficiency of the algorithm depends upon the graphs. The followingaspects have an impact on its improvement:

• The number of neighbors of the lastly added LHS node that are not part of the partial mapping.(More nodes can result in more significant decrease.)

• The cardinality of the THost set. (More nodes result in more significant decrease.)

• The selection of the next LHS node to map.

Proposition 6.1. The GenerateCandidatePairsExtended algorithm cannot perform morechecks than the default approach (GenerateCandidatePairs).

Proof. The GenerateCandidatePairsExtended reduces the number of checks through the im-plementation of backtracking, when an LHS node is absent from every candidate pairs. In these casesthere is no need to check the remaining nodes, because that particular LHS node cannot be mapped.However, in the worst case scenario, the algorithm cannot reduce the number of checks and needs toexamine all candidate pairs in the exact same way, as is the case in the GenerateCandidatePairsapproach. Since the original approach checks all pairs, the GenerateCandidatePairsExtendedcannot exceed this value. �

Proposition 6.2. If the primarily selected LHS node in the algorithm GenerateCandidatePair-sExtended cannot be matched, the VF2 with the GetPairsFromLists ordering function backtracksas soon as possible.

Proof. The GetPairsFromLists orders the candidate pairs based on the number of occurrencesof their LHS nodes. Following the first check with this ordering function, the candidate pairs withthe given LHS node are examined, because the pairs containing this node are atop the ordered list.Therefore, the algorithm initially checks only the pairs that contain the LHS node. Since this LHSnode cannot be mapped, the algorithm backtracks after all pair containing this node is observed. Thiscannot be achieved earlier, since the algorithm must first check these pairs. Better result cannot beachieved using another LHS node because, as a result of the candidate pair generation, all LHS nodesare contained by the same number of candidate pairs. �

6.5 SummaryThis chapter focuses on a popular graph matching approach, the VF2 algorithm. The algorithm,which is used to generate the set of candidate node pairs, has been discussed in details.

The chapter presented a new optimization criteria to generate the candidate node pairs. Thisalgorithm backtracks at the moment an LHS node does not appear in any candidate pairs and, indoing so, increase the efficiency of the algorithm. The method considers the last added LHS node andselects a new node from its neighbors if possible.

Moreover, an ordering function has been presented to support this algorithm. Using this method,the algorithm selects the next candidate pair with the LHS node, which occurs in the fewest pairs. Inthis way it assists the algorithm in reaching a state from it can backtrack.

Finally, some experimental results have been presented. It has been shown, that the application ofthese methods can greatly increase the performance of the VF2 algorithm. Although the host graphscontained only maximum 24 nodes and the LHS graphs at most 6, the difference between the originaland the modified algorithm is striking.

120

7

Conclusions

7.1 Summary of ContributionsThe scientific results of my research are summarized in three theses that are further divided intosubtheses. I proved the theoretical results by mathematical and engineering methods, and they areillustrated on experiments to prove their practical relevance. The theses are outlined in the following.

• The first contribution focuses on a novel solution that raises the abstraction level of process-ing Simulink models. The approach is based on model transformations defined in the VisualModeling and Transformation System (VMTS). Using model transformation technique to flat-ten virtual subsystems, create a Sorted List, propagate, or change data types, replace built-insolutions with custom algorithms, and reduce the risk of creating artificial algebraic loops helpsraising the abstraction level from API programming to software modeling. Both the algorithmsand the transformations are presented in details, and the main attributes of the transformationsare analyzed as well.

• The second contribution provides solutions for exact pattern matching using MapReduce tech-nique. Both the MRSIH and MRSIS algorithms find all subgraphs in the source graph thatare isomorphic to the target pattern. The introduced algorithms are analyzed and are comparedto each other based on their space and memory requirements. Experimental result are alsopresented to illustrate the applicability of the algorithms in real-world scenarios.

• In the third contribution, the approach to finding inexact patterns in large graphs using MapRe-duce technique is introduced. TheMRMM algorithm is analyzed based on its space and memoryrequirements, and experimental results show how the number of optional parts affect these at-tributes. Moreover, the third contribution also provides optimization techniques to increase theefficiency of the VF2 algorithm. The effect of the method is confirmed by experimental results.

Thesis I – Increasing the Abstraction Level of the Simulink Model ElaborationProcess Using Model Transformations

I have created several model transformations to process Simulink models. The transformations can belinked together and executed in different orders, therefore the performance derived from the differentorders of the processing steps can be analyzed. The transformations achieve the model processingin a declarative manner. The approach possesses all the advantageous characteristics of the modeltransformation, for example, it is reusable, transparent, and platform independent. Therefore, thefavorable properties of the domain-specific modeling can be utilized by this higher level of abstraction.

121

7. Conclusions

Thesis I is presented in Chapter 3 of the dissertation.Publications related to this thesis are: [6, 10, 11, 12, 13, 14].

Subthesis I.1

I have provided a detailed algorithm and a model transformation for flattening virtual subsystems inSimulink models. I have proved that the functionality of the model does not change after the trans-formation flattened the virtual subsystems. I have shown that the transformation flattens all virtualsubsystems in the Simulink model and I have proved that the transformation always terminates. Ihave provided an algorithm and a model transformation for creating Sorted List for Simulink models.I have proved that the transformation creates a valid Sorted List, which contains each element ex-actly once and represents the elements in an appropriate order. I have shown that the transformationalways terminates. I have provided an algorithm and a model transformation for propagating andvalidating data types in Simulink models, and proved that the transformation always terminates.

Subthesis I.2

I have provided an algorithm and a model transformation for partly flattening atomic subsystemsin Simulink models. The transformation moves all block out of the atomic subsystem, which have adirect feedthrough property, are not connected to a subsystem output either directly or via a chainof other blocks having direct feedthrough properties, and have incoming signals exclusively from theinport blocks of the subsystem. This transformation helps reducing the occasions where artificialalgebraic loops occur. I have proved that this algorithm always terminates. I have provided a modeltransformation for applying custom algorithms instead of the built-in Simulink solutions. I have showna model transformation for converting data types.

Subthesis I.3

An important benefit to modeling transformations in a declarative sense is that the separated function-ality can be conveniently reordered. This allows the study of the potential performance improvementsthat derive from different orders. Therefore, I have reasoned about how the different application orderof the model transformation affects the efficiency of the model processing.

Thesis II – Exact Pattern Matching with MapReduce

I have created multiple algorithms that are capable of finding all subgraphs in the source graph thatare isomorphic to the target pattern. To support this pattern matching in large graphs, that is, graphswith millions of edges and vertices, the algorithms are designed to utilize the MapReduce framework.To perform reasoning on the algorithms, their space and memory requirements are analyzed andcompared to each other.

Thesis II is presented in Chapter 4 of the dissertation.Publications related to this thesis are: [2, 7, 8, 15, 16].

Subthesis II.1

I have provided an algorithm (MRSIH) for finding subgraphs isomorphic to the target pattern ina graph possibly containing millions of elements. The algorithm is based on the VF2 algorithm andusing the MapReduce framework. I have proved that the algorithm finds all subgraphs isomorphic tothe target graph. I have presented an upper limit of the emitted outputs in cases of both the mapper

122

7.2. Future Work

and the reducer instances. I have shown the upper limit of the memory required by a single reducerinstance.

Subthesis II.2

I have provided an algorithm (MRSIS) for finding subgraphs isomorphic to the target pattern in agraph possibly containing millions of elements. The algorithm is designed to be more efficient in termsof I/O operations and memory requirements. I have proved that the algorithm finds all subgraphsisomorphic to the target pattern. I have presented the upper limit of the emitted outputs for allmappers and reducers. I have presented the upper limit of the memory required by single reducersfor both MapReduce jobs.

Subthesis II.3

I have provided a comparison of the MRSIH and MRSIS algorithms regarding their space andmemory requirements. I have proved thatMRSIS performs better in both aspects in case theMRSIHdoes not uses any additional heuristics. In order to support the theoretical results, I have presentedexperimental results.

Thesis III – Inexact Pattern Matching with MapReduce

This thesis provides an algorithm that is capable of matching inexact patterns in graphs containingmillions of edges and vertices. A language to define inexact patterns is also introduced. I have providedtwo optimization techniques to increase the efficiency of the VF2 algorithm.

Thesis III is presented in Chapter 5 and Chapter 6 of the dissertation.Publications related to this thesis are: [1, 2, 7, 8, 9, 15, 16, 17].

Subthesis III.1

I have worked out a pattern specification language that is capable of defining inexact patterns. I haveprovided an algorithm (MRMM) for finding inexact patterns in large graphs. To support graphswith millions of elements, the approach is based on the MapReduce framework. I have presented theupper limit of the emitted outputs for all mappers and reducers. I have shown the upper limit of thememory required by single reducer instances for both MapReduce jobs.

Subthesis III.2

I have provided an algorithm that increases the efficiency of the VF2 algorithm by reducing thenumber of required feasibility rules. I have proved that the algorithm cannot conduct more checksthatn the default approach. I have provided another method to increase the efficiency of the VF2algorithms by ordering the candidate pairs. I have proved that this ordering method makes the VF2backtrack as soon as possible. I have presented the performance analysis to support the theoreticalresults.

7.2 Future WorkIn this section, the known issues, as well as the possible future research directions are summarized.

• Future work intends to study whether with the help of these model transformations for Simulink,the execution list and the Hinldey-Milner algorithm [Hindley, 1969, Milner, 1978] can also be

123

7. Conclusions

implemented via model transformation. In this manner, a theoretic foundation can be formalizedsuch that it is amenable to analysis while being applicable to industry strength software modelingenvironments.

• Similarly, more advanced solutions for the partial flattening Simulink models should be studiedand the transformations regarding their resource requirements and performances should befurther examined.

• Although the MRSI algorithms makes it possible to find all subgraph isomorphic patters in largegraphs, their efficiency could be increased even further. Therefore, the possibility of decreasingthe output sizes should be investigated. Other optimization, such as extending the groupingphase or changing the algorithm for selecting the next target node also should be considered.

• As for the inexact pattern matching, it should be investigated, if there is a method to representthe optional partial mapping in a more concise way. This way the efficiency of the MRMMalgorithm could be greatly improved.

• Similarly, with the compression of the outputs the required I/O operations could be decreased,which might lead to a more efficient operation.

• The VF2 algorithm does not perform well in case every graph family. Therefor, new optimizationtechnique should be designed to improve its performance.

• It should be investigated, how the known VF2 heuristics would improve the performance of theMRSIH algorithm.

124

List of Publications

[1] Péter Fehér. Common graph rewriting techniques and their comparisons. In Proceedings of theAutomation and Applied Computer Science Workshop 2011 (AACS’11), 2011.

[2] Péter Fehér. Investigating the vf2 graph matching algorithm. In Proceedings of the Automationand Applied Computer Science Workshop 2012 (AACS’12), pages 117–128, 2012.

[3] Péter Fehér and László Lengyel. The challenges of a model transformation language. In The9th IEEE Workshop on Model-Based Development for Computer-Based Systems, pages 324–329,2012.

[4] Péter Fehér and László Lengyel. Introduction of the model transformation languages – a casestudy. In microCAD 2012: XXVII. International Scientific Conference, 2012.

[5] Péter Fehér and László Lengyel. The power of graph transformation – implementing a shadowcasting algorithm. In IEEE 10th Jubilee International Symposium on Intelligent Systems andInformatics (SISY 2012), pages 121–127, 2012.

[6] Péter Fehér, Pieter J. Mosterman, Tamás Mészáros, and László Lengyel. Processing Simulinkmodels with graph rewriting-based model transformation. Model Driven Engineering Languagesand Systems (MODELS 2012) - Tutorials, 2012.

[7] Péter Fehér. Cloud enabled model processing approaches. In Proceedings of the Automation andApplied Computer Science Workshop 2013 (AACS’13), pages 284–292, 2013.

[8] Péter Fehér and László Lengyel. Investigating the candidate pair generation of the vf2 algorithm.In The 12th IASTED International Conference on Software Engineering (SE 2013), pages 814–820, 2013.

[9] Péter Fehér and László Lengyel. Investigating the performance of the vf2 algorithm in case ofsymmetric graphs. In microCAD 2013: XXVII. International Scientific Conference, 2013.

[10] Péter Fehér, Tamás Mészáros, and László Lengyel. Flattening virtual Simulink R© subsystems - acase study. In IEEE 9th International Conference on Computational Cybernetics (ICCC 2013),pages 273–278, 2013.

[11] Péter Fehér, Tamás Mészáros, Pieter J. Mosterman, and László Lengyel. Creating sorted listfor Simulink R© models with graph transformation. In 25th European Modeling and SimulationSymposium (EMSS 2013), pages 142–152, 2013.

125

List of Publications

[12] Péter Fehér, Tamás Mészáros, Pieter J. Mosterman, and László Lengyel. Data type propagationin Simulink R© models with graph transformation. In 3rd Eastern European Regional Conferenceon the Engineering of Computer Based Systems (ECBS-EERC 2013), pages 127–137, 2013.

[13] Péter Fehér, Tamás Mészáros, Pieter J. Mosterman, and László Lengyel. Flattening virtualSimulink R© subsystems with graph transformation. In The 6th workshop on Complex SystemsModelling and Simulation (CoSMoS 2013), pages 39–60, 2013.

[14] Péter Fehér, Tamás Mészáros, Pieter J. Mosterman, and László Lengyel. A novel algorithm forflattening virtual subsystems in Simulink R© models. In IEEE International Conference on SystemScience and Engineering (ICSSE 2013), pages 369–375, 2013.

[15] Péter Fehér, Tamás Vajk, Hassan Charaf, and László Lengyel. Mapreduce algorithm for find-ing st-connectivity. In 4th IEEE International Conference on Cognitive Infococommunications(CogInfoCom 2013), pages 759–764, 2013.

[16] Péter Fehér. A map-reduce based algorithm detecting subgraph isomorphism. In Proceedings ofthe Automation and Applied Computer Science Workshop 2014 (AACS’14), pages 122–134, 2014.

[17] Péter Fehér, Márk Asztalos, Tamás Mśzáros, and László Lengyel. A mapreduce-based approachfor finding inexact patterns in large graphs. In Proceedings of the 3rd International Conferenceon Model-Driven Engineering and Software Development (MODELSWARD 2015), 2015.

[18] Péter Fehér, Márk Asztalos, Tamás Vajk, Tamás Mészáros, and László Lengyel. Detecting sub-graph isomorphism with MapReduce. The Journal of Supercomputing, pages 1–42, 2016.

[19] Tamás Mészáros, Péter Fehér, Márk Asztalos, and Tihamér Levendovszky. A challenge problemfor the verification and validation of model transformations. International Journal of AdvancedComputer Sciences, 3(5), 2013.

[20] Tamás Mészáros, Péter Fehér, and László Lengyel. Visual debugging support for graph rewrit-ingbased model transformations. In Proceedings of the International Conference on Computeras a Tool (EUROCON 2013), pages 482–487, 2013.

[21] Tamás Vajk, Péter Fehér, Kriszitán Fekete, and Hassan Charaf. Denormalizing data intoschema-free databases. In 4th IEEE International Conference on Cognitive Infococommunications(CogInfoCom 2013), pages 747–752, 2013.

126

Bibliography

[PCA, 2007] (2007). PCAST document. http://varma.ece.cmu.edu/InfoCPS/Readings.html.

[PIn, 2012] (2012). An introduction to P/Invoke and marshaling on the Microsoft .NET compactframework. http://msdn.microsoft.com/en-us/library/aa446536.aspx.

[Mat, 2012] (2012). Matlab R© 2012b user’s guide. http://www.mathworks.com/help/matlab/index.html.

[Sim, 2012a] (2012a). Simulink R© 2012b. http://www.mathworks.com/simulink/.

[Sim, 2012b] (2012b). Simulink R© 2012b - direct feedthrough. http://www.mathworks.com/help/simulink/sfg/s-function-concepts.html.

[Sim, 2012c] (2012c). Simulink R© 2012b - working with data types. http://www.mathworks.com/help/simulink/ug/working-with-data-types.html.

[Sim, 2012d] (2012d). Simulink R© 2012b user’s manual. http://www.mathworks.com/help/simulink/index.html.

[Sta, 2012] (2012). Stateflow R© user’s guide. www.imec.be/elela/HK19/background/stateflow_users_guide.pdf.

[VMT, 2012] (2012). VMTS website. http://vmts.aut.bme.hu/.

[Agrawal et al., 2004] Agrawal, A., Simon, G., and Karsai, G. (2004). Semantic translation ofsimulink/stateflow models to hybrid automata using graph transformations. Electron. Notes Theor.Comput. Sci., 109:43–56.

[Alur et al., 1995] Alur, R., Courcoubetis, C., Halbwachs, N., Henzinger, T. A., Ho, P.-H., Nicollin,X., Olivero, A., Sifakis, J., and Yovine, S. (1995). The algorithmic analysis of hybrid systems.THEORETICAL COMPUTER SCIENCE, 138:3–34.

[Amazon Web Services, 2013] Amazon Web Services (2013). http://aws.amazon.com.

[Angyal et al., 2009] Angyal, L., Asztalos, M., Lengyel, L., Levendovszky, T., Madari, I., Mezei, G.,Mészáros, T., Siroki, L., and Vajk, T. (2009). Towards a fast, efficient and customizable domain-specific modeling framework. In Software Engineering. ACTA Press.

[Apache Hadoop, 2011] Apache Hadoop (2011). Apache Hadoop Project. http://hadoop.apache.org/.

127

http://varma.ece.cmu.edu/InfoCPS/Readings.html

http://varma.ece.cmu.edu/InfoCPS/Readings.html

http://msdn.microsoft.com/en-us/library/aa446536.aspx

http://www.mathworks.com/help/matlab/index.html

http://www.mathworks.com/help/matlab/index.html

http://www.mathworks.com/simulink/

http://www.mathworks.com/help/simulink/sfg/s-function-concepts.html

http://www.mathworks.com/help/simulink/sfg/s-function-concepts.html

http://www.mathworks.com/help/simulink/ug/working-with-data-types.html

http://www.mathworks.com/help/simulink/ug/working-with-data-types.html

http://www.mathworks.com/help/simulink/index.html

http://www.mathworks.com/help/simulink/index.html

www.imec.be/elela/HK19/background/stateflow_users_guide.pdf

www.imec.be/elela/HK19/background/stateflow_users_guide.pdf

http://vmts.aut.bme.hu/

http://aws.amazon.com

http://hadoop.apache.org/

http://hadoop.apache.org/

Bibliography

[Assmann, 1996] Assmann, U. (1996). How to uniformly specify program analysis and transformationwith graph rewrite systems. In Compiler Construction (CC), pages 121–135. Springer.

[Asztalos and Madari, 2009] Asztalos, M. and Madari, I. (2009). An improved model transformationlanguage. In Automation and Applied Computer Science Workshop 2009.

[Bader and Madduri, 2006] Bader, D. A. and Madduri, K. (2006). Designing multithreaded algo-rithms for breadth-first search and st-connectivity on the cray mta-2. In Parallel Processing, 2006.ICPP 2006. International Conference on, pages 523–530. IEEE.

[Benveniste et al., 2003] Benveniste, A., Caspi, P., Edwards, S. A., Halbwachs, N., Guernic, P. L.,and de Simone, R. (2003). The synchronous languages twelve years later. Proceedings of the IEEE,91(1):64–83.

[Bergmann et al., 2010] Bergmann, G., Horváth, Á., Ráth, I., Varró, D., Balogh, A., Balogh, Z.,and Ökrös, A. (2010). Incremental evaluation of model queries over EMF models. In ModelDriven Engineering Languages and Systems, 13th International Conference, MODELS’10. Springer,Springer. Acceptance rate: 21%.

[Berry, 2010] Berry, J. W. (2010). Practical heuristics for inexact subgraph isomorphism.

[Berry et al., 2007] Berry, J. W., Hendrickson, B., Kahan, S., and Konecny, P. (2007). Softwareand algorithms for graph queries on multithreaded architectures. In International Parallel andDistributed Processing Symposium, pages 1–14. IEEE.

[Bredenfeld and Camposano, 1995] Bredenfeld, A. and Camposano, R. (1995). Tool integration andconstruction using generated graph-based design representations. In Design Automation, 1995.DAC ’95. 32nd Conference on, pages 94–99.

[Bröcheler et al., 2010] Bröcheler, M., Pugliese, A., and Subrahmanian, V. (2010). Cosi: Cloud ori-ented subgraph identification in massive social networks. In 2010 International Conference onAdvances in Social Networks Analysis and Mining (ASONAM), pages 248–255.

[Bröcheler et al., 2009] Bröcheler, M., Pugliese, A., and Subrahmanian, V. S. (2009). Dogma: Adisk-oriented graph matching algorithm for rdf databases. In Proceedings of the 8th InternationalSemantic Web Conference, ISWC ’09, pages 97–113, Berlin, Heidelberg. Springer-Verlag.

[Caspi et al., 2003] Caspi, P., Curic, A., Maignan, A., Sofronis, C., and Tripakis, S. (2003). Trans-lating discrete-time simulink to lustre. In In: Third International ACM Conference on EmbeddedSoftware, Lecture Notes in Computer Science, pages 84–99. Springer.

[Chakrabarti et al., 2004] Chakrabarti, D., Zhan, Y., and Faloutsos, C. (2004). R-mat: A recursivemodel for graph mining. In SDM, volume 4, pages 442–446. SIAM.

[Coffman et al., 2004] Coffman, T., Greenblatt, S., and Marcus, S. (2004). Graph-based technologiesfor intelligence analysis. Communications ACM, 47(3):45–47.

[Conejero et al., 2011] Conejero, J. M., Clemete, P. J., Rodrígez-Echeverría, R., Hernández, J., andSánchez-Figueroa, F. (2011). A model-driven approach for reusing tests in smart home systems.Personal and Ubiquitous Computing, 15(4):317–327.

[Cordella et al., 2004] Cordella, L., Foggia, P., Sansone, C., and Vento, M. (2004). A (sub)graphisomorphism algorithm for matching large graphs. Pattern Analysis and Machine Intelligence,IEEE Transactions on, 26(10):1367 –1372.

128

Bibliography

[Cordella et al., 1998] Cordella, L. P., Foggia, P., Sansone, C., Tortorella, F., and Vento, M. (1998).Graph matching: a fast algorithm and its evaluation. Proc. of the 14th International Conferenceon Pattern Recognition, pages 1582–1584.

[Cordella et al., 2001] Cordella, L. P., Foggia, P., Sansone, C., and Vento, M. (2001). An improvedalgorithm for matching large graphs. 3rd IAPR-TC15 Workshop on Graph based Representation(GbR2001).

[de Lara and Varró, 2010] de Lara, J. and Varró, D. (2010). Preface of the fourth international work-shop on graph-based tools. In GraBaTs 2010.

[Dean and Ghemawat, 2008] Dean, J. and Ghemawat, S. (2008). Mapreduce: simplified data process-ing on large clusters. Communications of the ACM, 51(1):107–113.

[Denckla and Mosterman, 2004a] Denckla, B. and Mosterman, P. J. (2004a). An intermediate repre-sentation and its application to the analysis of block diagram execution. In Proceedings of the 2004Summer Computer Simulation Conference (SCSC’04), pages 167–172.

[Denckla and Mosterman, 2004b] Denckla, B. and Mosterman, P. J. (2004b). An intermediate rep-resentation and its application to the analysis of block diagram execution. In Proceedings of the2004 Summer Computer Simulation Conference (SCSC’04), pages 167–172.

[Denil, 2013] Denil, J. (2013). Design, Verification and Deployment of Software Intensive Systems.PhD thesis, University of Antwerp, Antwerpen, Belgium.

[Denil et al., 2014] Denil, J., Mosterman, P. J., and Vangheluwe, H. (2014). Rule-based modeltransformation for, and in simulink. In Proceedings of the Symposium on Theory of Modeling& Simulation-DEVS Integrative, page 4. Society for Computer Simulation International.

[Dörr, 1995] Dörr, H. (1995). Efficient Graph Rewriting and Its Implementation. Springer-VerlagNew York, Inc., Secaucus, NJ, USA.

[Ehrig et al., 2006] Ehrig, H., Ehrig, K., Prange, U., and Taentzer, G. (2006). Fundamentals of Al-gebraic Graph Transformation (Monographs in Theoretical Computer Science. An EATCS Series).Springer-Verlag New York, Inc., Secaucus, NJ, USA.

[Fehér, 2013] Fehér, P. (2013). Cloud enabled model processing approaches. In Proceedings of theAutomation and Applied Computer Science Workshop 2013 (AACS’13).

[Fehér and Lengyel, 2012] Fehér, P. and Lengyel, L. (2012). The challenges of a model transformationlanguage. The 9th IEEE Workshop on Model-Based Development for Computer-Based Systems.

[Fehér et al., 2013a] Fehér, P., Mészáros, T., Mosterman, P. J., and Lengyel, L. (2013a). A novelalgorithm for flattening virtual subsystems in Simulink R© models. In IEEE International Conferenceon System Science and Engineering (ICSSE 2013), pages 369–375.

[Fehér et al., 2013b] Fehér, P., Vajk, T., Charaf, H., and Lengyel, L. (2013b). Mapreduce algorithm forfinding st-connectivity. In 4th IEEE International Conference on Cognitive Infococommunications- CogInfoCom 2013.

[Foggia et al., 2001] Foggia, P., Sansone, C., and Vento, M. (2001). A performance comparison offive algorithms for graph isomorphism. 3rd IAPR-TC15 Workshop on Graph based Representation(GbR2001).

[Forgy, 1974] Forgy, C. (1974). A network match routine for production systems. Working paper.

129

Bibliography

[Fowler, 2010] Fowler, M. (2010). Domain Specific Languages. The Addison-Wesley Signature Series.Addison-Wesley.

[Graph 500 Steering Committee, 2014] Graph 500 Steering Committee (2014). Graph 500 bench-mark. http://www.graph500.org/.

[Hadoop wiki - Powered by, 2013] Hadoop wiki - Powered by (2013). http://wiki.apache.org/hadoop/PoweredBy.

[Halbwachs et al., 1991] Halbwachs, N., Caspi, P., Raymond, P., and Pilaud, D. (1991). The syn-chronous dataflow programming language LUSTRE. Proceedings of the IEEE, 79(9):1305–1320.

[Han and Mosterman, 2010] Han, Z. and Mosterman, P. J. (2010). Detecting data store access conflictin Simulink by solving boolean satisfiability problems. In Proceedings of the 2010 American ControlConference (ACC’10), pages 5702–5707.

[Hindley, 1969] Hindley, R. (1969). The principal type-scheme of an object in combinatory logic.Transactions of the american mathematical society, 146:29–60.

[Hudak, 1989] Hudak, P. (1989). Conception, evolution, and application of functional programminglanguages. ACM Comput. Surv., 21(3):359–411.

[Kang et al., 2008] Kang, U., Tsourakakis, C., Appel, A. P., Faloutsos, C., and Leskovec, J. (2008).HADI: Fast diameter estimation and mining in massive graphs with Hadoop. Carnegie MellonUniversity, School of Computer Science, Machine Learning Department.

[Karloff et al., 2010] Karloff, H., Suri, S., and Vassilvitskii, S. (2010). A model of computation formapreduce. In Proceedings of the Twenty-First Annual ACM-SIAM Symposium on Discrete Algo-rithms, pages 938–948. Society for Industrial and Applied Mathematics.

[Kelly and Tolvanen, 2008] Kelly, S. and Tolvanen, J.-P. (2008). Domain-Specific Modeling: EnablingFull Code Generation. Wiley.

[Kim et al., 2013] Kim, S.-H., Lee, K.-H., Choi, H., and Lee, Y.-J. (2013). Parallel processing ofmultiple graph queries using mapreduce. In DBKDA 2013, The Fifth International Conference onAdvances in Databases, Knowledge, and Data Applications, pages 33–38.

[Koehler et al., 2007] Koehler, J., Gschwind, T., Küster, J. M., Pautasso, C., Ryndina, K., Vanhatalo,J., and VĂślzer, H. (2007). Combining quality assurance and model transformations in business-driven development. In AGTIVE, pages 1–16.

[Lara and Guerra, 2010] Lara, D. and Guerra (2010). Generic meta-modelling with concepts, tem-plates and mixin layers. In ACM/IEEE 13th International Conference on Model Driven EngineeringLanguages and Systems (MODELS 2010).

[Leach and Gillet, 2007] Leach, A. R. and Gillet, V. J. (2007). An introduction to chemoinformatics.Springer Science & Business Media.

[Lee et al., 2012] Lee, K.-H., Lee, Y.-J., Choi, H., Chung, Y. D., and Moon, B. (2012). Parallel dataprocessing with mapreduce: a survey. AcM sIGMoD Record, 40(4):11–20.

[Leskovec et al., 2005] Leskovec, J., Chakrabarti, D., Kleinberg, J., and Faloutsos, C. (2005). Real-istic, mathematically tractable graph generation and evolution, using kronecker multiplication. InKnowledge Discovery in Databases: PKDD 2005, pages 133–145. Springer.

130

http://www.graph500.org/

http://wiki.apache.org/hadoop/PoweredBy

http://wiki.apache.org/hadoop/PoweredBy

Bibliography

[Liu et al., 2009] Liu, Y., Jiang, X., Chen, H., Ma, J., and Zhang, X. (2009). Mapreduce-based patternfinding algorithm applied in motif detection for prescription compatibility network. In AdvancedParallel Processing Technologies, pages 341–355. Springer.

[McKay, 1981] McKay, B. D. (1981). Practical graph isomorphism. Congressus Numerantium, 30:45–87.

[Mens and Van Gorp, 2006] Mens, T. and Van Gorp, P. (2006). A taxonomy of model transformation.Electron. Notes Theor. Comput. Sci., 152:125–142.

[Messmer and Bunke, 1995] Messmer, B. T. and Bunke, H. (1995). Subgraph isomorphism in poly-nominal time. Lecture Notes in Computer Science Graph, pages 1–33.

[Mészáros et al., 2008] Mészáros, T., Mezei, G., and Levendovszky, T. (2008). A flexible, declarativepresentation framework for domain-specific modeling. In Proceedings of the working conference onAdvanced visual interfaces, AVI ’08, pages 309–312, New York, NY, USA. ACM.

[Mezei et al., 2009] Mezei, G., Levendovszky, T., Mészáros, T., and Madari, I. (2009). Towards trulyparallel model transformations: A distributed pattern matching approach. In EUROCON 2009,EUROCON ’09. IEEE, pages 403–410.

[Milner, 1978] Milner, R. (1978). A theory of type polymorphism in programming. Journal of com-puter and system sciences, 17(3):348–375.

[Mosterman and Ciolfi, 2004a] Mosterman, P. J. and Ciolfi, J. E. (2004a). Using interleaved execu-tion to resolve cyclic dependencies in time-based block diagrams. In Proceedings of 43rd IEEEConference on Decision and Control (CDC’04), pages 4057–4062.

[Mosterman and Ciolfi, 2004b] Mosterman, P. J. and Ciolfi, J. E. (2004b). Using interleaved executionto resolve cyclic dependencies in time-based block diagrams. In Decision and Control, 2004. CDC.43rd IEEE Conference on, volume 4, pages 4057–4062. IEEE.

[Mosterman et al., 2005] Mosterman, P. J., Ghidella, J., and Friedman, J. (2005). Model-based designfor system integration. In The Second CDEN International Conference on Design Education,Innovation, and Practice, pages TB3–1–TB3–10.

[Mosterman et al., 2004] Mosterman, P. J., Prabhu, S., and Erkkinen, T. (2004). An industrial em-bedded control system design process. In The Inaugural CDEN Design Conference (CDEN’04),pages 02B6–1–02B6–11.

[Mosterman and Vangheluwe, 2002] Mosterman, P. J. and Vangheluwe, H. (2002). Computer au-tomated multi-paradigm modeling. ACM Transactions on Modeling and Computer Simulation,12(4):249–255.

[Mosterman and Vangheluwe, 2004] Mosterman, P. J. and Vangheluwe, H. (2004). Computer auto-mated multi-paradigm modeling: An introduction. SIMULATION: Transactions of The Society forModeling and Simulation International, 80(9):433–450.

[Mosterman and Zander, 2015a] Mosterman, P. J. and Zander, J. (2015a). Cyber-physical systemschallenges—a needs analysis for collaborating embedded software systems. Software and SystemsModeling. in press.

[Mosterman and Zander, 2015b] Mosterman, P. J. and Zander, J. (2015b). Industry 4.0 as a cyber-physical system study. Software and Systems Modeling. in review.

131

Bibliography

[Mulholland et al., 2010] Mulholland, A., Pyke, J., and Fingar, P. (2010). Enterprise Cloud Comput-ing: A Strategy Guide for Business and Technology Leaders. Meghan-Kiffer Press.

[Nicolescu and Mosterman, 2010] Nicolescu, G. and Mosterman, P. (2010). Model-Based Design forEmbedded Systems. Computational Analysis, Synthesis, and Design of Dynamic Models Series.CRC Press.

[Nilsson, 1982] Nilsson, N. (1982). Principles of Artificial Intelligence. Symbolic Computation: Arti-ficial Intelligence. Springer.

[Ohlrich et al., 1993] Ohlrich, M., Ebeling, C., Ginting, E., and Sather, L. (1993). Subgemini: iden-tifying subcircuits using a fast subgraph isomorphism algorithm. In Proceedings of the 30th inter-national Design Automation Conference, pages 31–37. ACM.

[Park and Chung, 2013] Park, H.-M. and Chung, C.-W. (2013). An efficient mapreduce algorithm forcounting triangles in a very large graph. In Proceedings of the 22Nd ACM International Conferenceon Conference on Information & Knowledge Management, CIKM ’13, pages 539–548. ACM.

[Plantenga, 2012] Plantenga, T. (2012). Inexact subgraph isomorphism in mapreduce. Journal ofParallel and Distributed Computing.

[Plump, 1998] Plump, D. (1998). Termination of graph rewriting is undecidable. Fundamenta Infor-maticae, 33(2):201–209.

[Pouzet and Raymond, 2010] Pouzet, M. and Raymond, P. (2010). Modular static scheduling ofsynchronous data-flow networks. Design Automation for Embedded Systems, 14(3):165–192.

[Radermacher, 1998] Radermacher, A. (1998). Support for design patterns through graph transforma-tion tools. In In Applications of Graph Transformation with Industrial Relevance (Intl. WorkshopAGTIVE’99, Proceedings), LNCS 1779, pages 111–126. Springer.

[Rahman et al., 2009] Rahman, S. A., Bashton, M., Holliday, G. L., Schrader, R., and Thornton, J. M.(2009). Small molecule subgraph detector (smsd) toolkit. Journal of cheminformatics, 1(1):1–13.

[Snijders et al., 2006] Snijders, T. A., Pattison, P. E., Robins, G. L., and Handcock, M. S. (2006).New specifications for exponential random graph models. Sociological methodology, 36(1):99–153.

[Tarjan, 1972] Tarjan, R. (1972). Depth-first search and linear graph algorithms. SIAM journal oncomputing, 1(2):146–160.

[Tong et al., 2007] Tong, H., Faloutsos, C., Gallagher, B., and Eliassi-Rad, T. (2007). Fast best-effortpattern matching in large attributed graphs. In Proceedings of the 13th ACM SIGKDD internationalconference on Knowledge discovery and data mining, pages 737–746. ACM.

[Tsourakakis et al., 2009] Tsourakakis, C. E., Kang, U., Miller, G. L., and Faloutsos, C. (2009).Doulion: counting triangles in massive graphs with a coin. In Proceedings of the 15th ACM SIGKDDinternational conference on Knowledge discovery and data mining, KDD ’09, pages 837–846.

[Ullmann, 1976] Ullmann, J. R. (1976). An algorithm for subgraph isomorphism. Journal of theAssociation for Computing Machinery, 23:31–42.

[Varró et al., 2006] Varró, G., Varró, D., and Schürr, A. (2006). Incremental graph pattern matching:Data structures and initial experiments. In Karsai, G. and Taentzer, G., editors, Graph and ModelTransformation (GraMoT 2006), volume 4 of Electronic Communications of the EASST. EASST,EASST.

132

Bibliography

[Wimmer et al., 2010] Wimmer, M., Retschitzegger, W., Kappel, G., Schoenboeck, J., Kusel, A., andSchwinger, W. (2010). Plug & play model transformations: a dsl for resolving structural metamodelheterogeneities. In Proceedings of the 10th Workshop on Domain-Specific Modeling, DSM ’10, pages7:1–7:6.

[Windows Azure, 2013] Windows Azure (2013). http://www.windowsazure.com/en-us/.

[Zhao et al., 2012] Zhao, Z., Wang, G., Butt, A. R., Khan, M., Kumar, V., and Marathe, M. V.(2012). Sahad: Subgraph analysis in massive networks using hadoop. In Parallel & DistributedProcessing Symposium (IPDPS), 2012 IEEE 26th International, pages 390–401. IEEE.

133

http://www.windowsazure.com/en-us/

methods for improving and applying graph rewriting-based model transformations m³dszerek

Documents