Engineering the Dynamic Semantics of Domain Specific Languages › ws › files › 81094978 ›...

Engineering the dynamic semantics of domain specificlanguagesCitation for published version (APA):Tikhonova, U. (2017). Engineering the dynamic semantics of domain specific languages. Technische UniversiteitEindhoven.

Document status and date:Published: 21/11/2017

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.

Download date: 27. Jul. 2020

https://research.tue.nl/en/publications/engineering-the-dynamic-semantics-of-domain-specific-languages(1290af0e-1700-4160-8222-03af1e03d03e).html

Engineering the Dynamic Semanticsof Domain Specific Languages

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan deTechnische Universiteit Eindhoven, op gezag van derector magnificus, prof.dr.ir. F.P.T. Baaijens, voor een

commissie aangewezen door het College voorPromoties in het openbaar te verdedigen

op dinsdag 21 november 2017 om 16.00 uur

door

Ulyana Tikhonova

geboren te Leningrad, Rusland

Dit proefschrift is goedgekeurd door de promotoren en de samenstelling van de promotiecom-missie is als volgt:

voorzitter: prof.dr. M.A. Peletierpromotor: prof.dr. M.G.J. van den Brandcopromotoren: dr.ir. T.A.C. Willemse

dr.ir. R.R.H. Schiffelersleden: prof.dr. J.J. Vinju

prof.dr. M. Butler (University of Southampton)prof.dr. B. Combemale (University of Toulouse)prof.dr.ir. M. Aksit (University of Twente)

Het onderzoek of ontwerp dat in dit proefschrift wordt beschreven is uitgevoerd in overeenstem-ming met de TU/e Gedragscode Wetenschapsbeoefening.


Ulyana Tikhonova

Promotor: prof.dr. M.G.J. van den Brand(Eindhoven University of Technology)

Copromotoren: dr.ir. T.A.C. Willemse(Eindhoven University of Technology)

dr.ir. R.R.H. Schiffelers(ASML)

Additional members of the core committee:

prof.dr. J.J. Vinju (Eindhoven University of Technology)prof.dr. M. Butler (University of Southampton)prof.dr. B. Combemale (University of Toulouse)prof.dr.ir. M. Aksit (University of Twente)

The work in this thesis has been carried out under the auspices of the research school IPA (Insti-tute for Programming research and Algorithmics).IPA dissertation series 2017-10

The work in this thesis has been carried out as part of the COREF project (Common ReferenceFramework for Executable Domain Specific Languages) with ASML as the industrial partner.The COREF project (PNU 10C19) is part of the Point-One University-Industry Interaction pro-gram.

A catalogue record is available from the Eindhoven University of Technology LibraryISBN: 978-90-386-4381-6

Cover design: Karina Vasileva (Melanistic Kitsune)Printed by: Ipskamp Printing, Enschede, The Netherlands

c© U. Tikhonova, 2017.

Acknowledgements

It is many miles and many years that have brought me here.

Tenzing Norgay, Tiger of the Snows

The journey towards this PhD thesis was long and was influenced by a lot of people. First ofall, I thank Mark van den Brand, my promoter and supervisor, for inviting me to participate inthe COREF project and for providing me with his full support through these years. The topic ofmy PhD project perfectly fitted the object of my curiosity. Moreover, Mark gave me the freedomto choose directions of the research and to pursue my ideas. Mark, thank you for your trust andfor all honest discussions we had!

Any freedom implies responsibility and pursuing your own ideas can be a very lonely andpainful experience. I thank my daily supervisor, Tim Willemse, for guiding me through theseconsequences of freedom and for ensuring the best outcome out of this experience – both for mywork and for me. I always could burst into his office with another crazy idea, eureka moment, ora desperate problem. Tim, thank you for making time for me, for your thorough discussions andreviews, and for your attention to every detail! Your contribution made this work what it is.

My PhD study was conducted as part of the COREF project, in collaboration between TU/eand ASML. I thank everybody actively participating in the COREF project or related to it: TomVerhoeff for discovering with me the odds and evens of formal specifications; Suzana Andovafor being my daily supervisor and a friend in the beginning of the project; Wilbert Alberts, Ra-mon Schiffelers, Rogier Wester, Istvan Nagy for helping and guiding on the industry side; MarcHamilton for sharing his expertise, insights, and ideas about the world of industrial DSLs. Myspecial thanks go to my COREF buddy, Maarten Manders. I could always rely on his companyand back-up when working at ASML, preparing for conferences and schools, and discoveringlocal life and cuisine in various locations we had attended.

From the beginning of my PhD project I was inspired by the Event-B community, by thewelcoming atmosphere of their workshops and by how keen they are to share knowledge andprovide support. I would like to especially mention Michael Butler, Colin Snook, Thai SonHoang, and Lukas Ladenberger.

During my PhD research, I was fortunate to team up and collaborate with some of my col-leagues and students. I am grateful to Rimco Boudewijns for carrying out his master project withme. His work nicely complemented my research and provided an important support for presen-tations and demonstrations of Constelle. I thank Anton Wijs for experimenting with Constelle,

ii

despite all its clumsiness, and providing me with interesting insights into my own work. I amvery grateful to Alexander Serebrenik for providing his help and advice on various questions inall these years, and especially for guiding me through the topics of empirical methods in softwareengineering. Alexander, your help with setting up an empirical study greatly contributed to myresearch and this thesis.

I thank members of my defense committee: Ramon Schiffelers, Michael Butler, BenoitCombemale, Mehmet Aksit, and Jurgen Vinju. It is an honor for me to have my work reviewedand assessed by you! I also express my gratitude to Mark Peletier for chairing the defense cere-mony.

One of the joys of being a PhD student is to be in the company of other PhD students. I washappy to share my office hours, breaks, lunches, and after work drinks with Yanja Dajsuren, Mar-cel van Amstel, Luc Engelen, Zvezdan Protic, Arjan van der Meer, Bogdan Vasilescu, AminahZawedde, John Businge, Maarten Manders, Neda Noroozi, Ana-Maria Sutii, Dan Zhang, LunaLuo, Sjoerd Cranen, Maciek Gazda, Sarmen Keshishzadeh, Mahmood Talebi, Onder Babur,Sander de Putter, Josh Mengerink, Weslley Torres, Felipe Ebert, Thomas Neele, and others.I am especially grateful for all the fun times we had with fellow PhDs during various schools thatI attended: numerous IPA spring and fall days, GTTSE, SFM/MDE, and, of course, Maktober-dorf. As a nice distraction from my research, I had enjoyed setting up and running the M&CSPhD Council - together with Jaron Sanders, Serban Badila, Sarah Gaaf, Jorn van der Pol, Arthurvan Goethem, and Alok Lele.

The journey to this thesis started some years before I came to Eindhoven, when my Russiansupervisor Fedor A. Novikov introduced me to the field of domain specific language engineering.Фёдор Александрович, спасибо Вам за байки про программистов, за умение видетьвглубь и вширь и быть не таким как все. I am grateful to my senior colleagues from In-stitute of Applied Astronomy who inspired me with their romantic vision of research work, itscuriosity and beauty. СкрипниченкоВладимирИльич,НецветаеваГалинаАнатольевна,СвешниковМихаил Леонидович, спасибо вам за вашу романтику, за любовь к своейработе и за рассказы про созвездия.

Finally, I thank my friends both in Netherlands and in St. Petersburg, for not caring muchabout my PhD and all this research; Gar Oome for consulting me about mechanics of LEGOcars; my closest friends Yanja and Sibrecht for being my paranymphs. I thank my wise husbandGeert and my beautiful daughter Vasja, for special joys and challenges they always have for meand for the place I call my home. I thank my parents, who always support me, whatever I do andwherever I go. To them I devote this book.

Дорогие мама и папа, спасибо вам за вашу поддержку! Я знаю, что что бы я ниделала и где бы ни была, вы со мной и поддержите меня. Для меня это очень важно.А еще, эта книга про и для инженеров - таких какими я с детства видела вас.

Ulyana TikhonovaЗаозерье, July 2017.

To my parents, Elena and NykolaiПосвящается моим родителям,

Елене и Николаю

Table of Contents

Acknowledgements i

Table of Contents v

List of Acronyms vii

1 Introduction 11.1 Scope and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Research Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Outline and Origin of Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Defining the Dynamic Semantics of a DSL: a Case Study 112.1 A Definition of the Dynamic Semantics of a DSL . . . . . . . . . . . . . . . . . 122.2 The LACE DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Use Cases and User Roles of LACE Specification . . . . . . . . . . . . . . . . . 162.4 Event-B and Rodin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Specification of LACE Dynamic Semantics in Event-B . . . . . . . . . . . . . . 182.6 Visualization of LACE Specifications . . . . . . . . . . . . . . . . . . . . . . . 292.7 User Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 The Grand Vision 433.1 The Technology Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Defining the Structure of a DSL . . . . . . . . . . . . . . . . . . . . . . . . . . 453.3 Defining the Dynamic Semantics of a DSL . . . . . . . . . . . . . . . . . . . . . 473.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

vi Table of Contents

4 Specification Templates and Constelle for Defining the Dynamic Semantics of DSLs 514.1 LEGO Allegory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3 Reusable Specification Templates . . . . . . . . . . . . . . . . . . . . . . . . . 584.4 Constelle Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.5 Constraint Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 Designing and Describing Model Transformations 775.1 Introduction and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2 Notation for Describing Model Transformations . . . . . . . . . . . . . . . . . . 785.3 Design of Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . 815.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Mapping Constelle to Event-B 956.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.2 Model transformations from Constelle to Event-B . . . . . . . . . . . . . . . . . 976.3 Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.4 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.5 Gluing Guards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.6 Proof Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7 Implementation and Pragmatics of Constelle 1217.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217.2 Definition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237.3 Constelle Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.4 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8 Validation of Constelle 1338.1 Empirical Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.2 Setting up a Validation Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.3 Conducting the Validation Study . . . . . . . . . . . . . . . . . . . . . . . . . . 1418.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

9 Conclusions 1539.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1539.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Bibliography 159

A Event-B Specification Templates 167

B Event-B Specification of Robotic Arm Parallel 173

Table of Contents vii

C Questionnaires 177C.1 Baseline Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177C.2 Logbook Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178C.3 Final Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Summary 185

Curriculum Vitae 187

IPA Dissertation Series 189

Index 194

List of Acronyms

AOP Aspect Oriented ProgrammingATL Atlas Transformation LanguageCOREF Common Reference FrameworkDAG Directed Acyclic GraphDSL Domain Specific LanguageEMF Eclipse Modeling FrameworkGPL General Purpose LanguageGQM Goal Question MetricLAC Logical Action ComponentLACE Logical Action Component EnvironmentLOC Lines Of CodeMDE Model Driven EngineeringMOF Meta-Object FacilityMT Model TransformationOCL Object Constraint LanguageOMG Object Management GroupPO Proof ObligationQVT Query/View/TransformationSF Semantic FeatureSS SubsystemSSA Subsystem ActionUML Unified Modeling Language

Chapter 1

Introduction

"Look, old boy," said the machine, "if I could do everything startingwith ‘n’ in every possible language, I’d be a Machine That Could DoEverything in the Whole Alphabet, since any item you care to mentionundoubtedly starts with ‘n’ in one foreign language or another. It’s notthat easy. I can’t go beyond what you programmed. So no sodium."

Stanislaw Lem, How the World Was Saved

In this introduction chapter, we set the scope of our research, define the basic terms, andidentify the gaps that we aim to address in our work. We outline our exploration path by formu-lating a series of research questions and describe how these research questions are addressed inthe chapters of this thesis. Moreover, to set up the common ground for our reader, we identifyprinciples that we follow in our research by explicitly choosing a philosophical stance.

1.1 Scope and DefinitionsToday software controls a lot of aspects of our lives: from controlling our airplanes (autopi-lots) and driving our cars, to setting up temperature in our houses and running our washingmachines, from connecting us with our family and friends, to performing our money transactionsand handling our personal information. All types of software (realizing these and many otherfunctionalities) are created by people known as software developers. The work of a software de-veloper consists in mapping a concrete problem (such as navigating a car) to a solution (a piece ofsoftware, known as a program) that solves this problem. To capture such a solution, software de-velopers use programming languages. A programming language provides an intermediate layerbetween a software developer and an existing hardware and/or software platform (where the pro-gram is executed). To facilitate the work of a software developer, we can move this intermediatelayer closer to the developer, i.e. we can reduce the distance between a problem domain (deter-mined by the application of a program) and solution domain (determined by the programminglanguage). Programming languages that aim at such an improvement of the problem-to-solution

2 Introduction

mapping are known as domain-specific languages (DSLs) (in contrast to general purpose lan-guages, GPLs). The idea of moving an intermediate layer closer to the developer is illustrated inFigure 1.1.

execution platform

software developer

GPL

DSL

intermediate layeris closer to the developer

the translation of the DSLbridges a wider semantic gap

Figure 1.1: Domain specific language (DSL) versus general purpose language (GPL)

A domain-specific language (DSL) is a computer (programming) language specialized fora specific (application) domain. The idea of using DSLs for software development and/or soft-ware configuration is not new, and DSLs have been known and applied in various forms (such assubroutine libraries, frameworks, and dedicated languages) for a long time. Recently, DSLs be-came a central concept of Model Driven Engineering (MDE) [86]. In the context of MDE, a DSLdetermines a class of models that can be constructed in the domain; and model-to-model transfor-mations and code generators assign meaning to such models by automatically translating theminto programs and/or other (useful in software development) artifacts, such as: documentation,visualizations, formal specifications, etc.

As a programming language, a DSL is usually composed of the following three components:abstract syntax, concrete syntax, and semantics. The abstract syntax of a DSL introduces con-structs of the DSL and relationships between them. The concrete syntax of a DSL defines anotation for these constructs and relationships. Such a notation is used by a software developerto create (write down) and to read (understand) DSL models (programs developed using theDSL). For example, a DSL can have a textual notation, in which case its models appear as piecesof text. Or a DSL can have a graphical notation, in which case its models appear as diagrams.

The semantics of a DSL assigns a meaning to a DSL model. For example, a meaning ofa DSL model can be a value of an arithmetic expression, if we consider a DSL for expressingsuch arithmetic expressions. In this case, the semantics of the DSL is defined as an algorithmof computing such a value for an arbitrary DSL model. The dynamic semantics of a DSL mapseach DSL model (program) to the corresponding execution behavior. In this case, a meaning is asequence (or multiple interleaving sequences) of execution steps, which can dynamically includeor exclude certain steps as a response to an input stimulus and which might result in some sideeffects (such as a change of the state of some component). An example of an execution behavioris a sequence of steps performed by a washing machine (although we might never think aboutour washing machine in this way): the input stimulus is the choosing of a washing program, thechange of state is clothes getting washed by the machine.

A DSLs can be implemented in the form of an embedded (internal) DSL or in the form of anexternal DSL [29]. An embedded DSL is integrated into a host language (usually GPL), relyingon its existing constructs, notation, and semantics and extending it with domain-specific con-structs, notation, and semantics. An external DSL is an independent (programming) language,

1.2. Problem Statement 3

which introduces its own constructs, notation, and semantics (from scratch).Programming languages (both DSLs and GPLs) are meant for creating software, but they are

themselves software too. To be able to use a programming language, we first need to constructits components (syntax and semantics) in the form of software. The languages that are meantfor describing programming languages are known as meta-languages. If such a meta-language isimplemented by the corresponding software, then we can execute a description of a programminglanguage, for example, in order to execute programs written in this programming language (thisapproach is known as an interpreter). People who create new languages (by describing themin meta-languages and/or constructing them in the form of software) are known as languagedevelopers.

As shown in Figure 1.1, a DSL brings the intermediate layer (a solution domain) closer toa software developer. As a consequence, the gap between the DSL and the execution platformincreases. This gap is bridged in the semantics of the DSL and should be defined as such by thelanguage developer. Thus, we facilitate the work of a software developer by the cost of increasingthe workload of the language developer (who constructs the semantics of the DSL).

In this thesis we aim to facilitate the work of a language developer who constructs a DSL.In particular, we focus on the dynamic semantics of external DSLs in the context of MDE anddevelop a meta-language for defining the dynamic semantics of a DSL. In the next section wedescribe the motivation of this work and give an overview of the problems that we aim to solve.

1.2 Problem StatementIn the context of MDE, the development of a DSL usually includes its design via meta-modelingand its implementation via code generation and/or model transformation. A DSL metamodeldefines an abstract syntax of the DSL by capturing language constructs, their compositionalhierarchy, classification and cross references between them. A model transformation implementsa translation from the DSL metamodel to the input language of a target execution platform, and,thus, captures the dynamic semantics of the DSL. As stated in Section 1.1, from a semantics pointof view, the gap bridged by this translation can be quite wide. Such a translation addresses boththe problem and the solution domains and does it in terms of both high-level concepts of the DSLand low-level concepts of the execution platform. The complexity of the DSL translation, whichin the context of MDE is practically (hard)coded in model transformations and code generation,poses challenges for learning, debugging, understanding, maintaining, and updating the DSL.

To manage the complexity of the DSL translation, we want to have an explicit definitionof the dynamic semantics of a DSL. There exist a number of approaches for defining the dy-namic semantics of general purpose languages (GPLs), such as denotational and algebraic se-mantics [108, 73], action semantics [70], and structural operational semantics (SOS) [78]. Theseapproaches allow for formalizing the dynamic semantics of a programming language and forperforming various types of analysis of such a formal definition. However, there is no practicallyapplicable tool support for this work, which means that the formalization and analysis are doneon paper.

Compared to GPLs, DSLs are smaller languages: a DSL covers a smaller set of problemsand, as a consequence, has a smaller audience of practitioners (those who use the DSL) and/ora smaller group of developers (those who design and implement the DSL). Next to the knownadvantages of using such small languages [25], the main disadvantages are determined by thecosts of developing and learning a DSL. An explicit definition of the dynamic semantics of aDSL can help to mitigate these disadvantages by providing various practical outcomes of havinga formal specification of the dynamic semantics of a DSL.

4 Introduction

Recent approaches focus on defining the dynamic semantics of DSLs and on providing thecorresponding tool support. The existing meta-languages for defining the dynamic semanticsof DSLs include Kermeta Language [44], xMOF (eXecutable MOF) [67], K semantic frame-work [82], DynSem [106]. These meta-languages use a technique known as an operationalapproach, when the dynamic semantics of a DSL is defined in terms of the DSL itself. For this,the DSL metamodel is extended with additional constructs that are necessary for describing astate of a DSL model during execution. The tool support includes an interpreter that allows fornavigating through execution states of a DSL model, according to a given definition of the dy-namic semantics of the DSL. Thus, the main practical outcome of having such a definition ofthe dynamic semantics of a DSL is a reference interpreter that can be consulted on how a DSLprogram should behave.

In this thesis we strive towards having more practical outcomes of having a formal speci-fication of the dynamic semantics of a DSL. In [53] Kosar et al. review (perform a systematicmapping study of) 390 existing studies on DSLs in order to understand the DSL research field,identify research trends and open issues. According to this work, the number of DSLs whichhad formal descriptions of their (dynamic) semantics was low. Moreover, there was hardly anydiscussion on validation and maintenance of DSLs in the reviewed studies. This work showsa gap in the research field of DSLs: a formal description of the dynamic semantics of a DSL,which can be used for the wide variety of practical purposes (such as validation and maintenanceof the DSL).

For example, in practice a DSL implementation can include a number of DSL translations,targeting different execution platforms with the purpose of achieving diverse technological goals.In this case, one translation generates C/C++ or Java source code for execution of DSL pro-grams; another translation targets various formalisms for verification and formal analysis of DSLprograms; and a third translation constructs diagrams visualizing DSL programs (as it is donein [102]). Generally speaking, there is no guarantee that different translations implement theDSL dynamic semantics in a coherent way. For instance, there is no confidence that a verifiedDSL program is coherent with the corresponding executed source code; or that a visualization ofa DSL program captures the source code generated from this program and can be used as a ref-erence, for example, when testing the execution of the source code. The desire to have differenttranslations implemented in a consistent way, so that they support and compliment each other,poses a maintenance problem.

To manage the complexity of a DSL translation, to mitigate the costs of developing andlearning a new DSL, to provide a common ground for different DSL translations, and in this wayto facilitate their consistency, we want to have an explicit definition of the dynamic semanticsof a DSL that can be used for the wide variety of practical purposes and in the wide variety ofDSL translations. Therefore, we go for a technique known as a translational approach, whenthe dynamic semantics of a DSL is defined in terms of another language or formalism (whosesemantics is already defined). The known advantage of this approach is the possibility to applyvarious tools available for the target formalism. However, as Combemale et al. describe in theirsurvey in [19], the translational approach is also known for the complexity of a definition of thedynamic semantics, which is captured in the translation of the DSL to a target formalism. Forexample, in [18] Cleenewerck and Kurtev describe complexity of a translational semantics of aDSL caused by structural mismatches between the DSL and the target language/formalism. Sucha complexity can hinder usability of a resulting definition of the dynamic semantics of a DSL.

We need a meta-language for defining the dynamic semantics of a DSL, that is not onlysupported by an infrastructure for interpreting (using) such a definition of the dynamic semantics,but also allows for a usable (clear) definition of the dynamic semantics of a DSL. Thus, thecentral research question addressed in this thesis is the following:

1.3. Research Questions 5

RQ: How to define the dynamic semantics of a DSL in a usable and useful way?

In the next section, we refine (decompose) this central research question into a series of morespecific questions.

1.3 Research QuestionsTo define the dynamic semantics of a DSL, we first need to identify what we want to define, i.e.what we want to capture in such a definition. In search for the key components and variabilitypoints of a definition of the dynamic semantics of a DSL, we formulated the following researchquestion.

RQ1: What constitutes a definition of the dynamic semantics of a DSL?

The constitution of a definition of the dynamic semantics of a DSL (i.e. what do we want todefine) correlates with the purpose of such a definition (i.e. how do we want to use the definition).To capture such a purpose explicitly and to ensure that our solution fits the stated purpose, weaddress the following research question.

RQ2: What are the requirements for a definition of the dynamic semantics of a DSL?

After identifying what constitutes a definition of the dynamic semantics of a DSL and statingthe purpose of such a definition, we are ready to search for the means that allow for constructing adefinition with the formulated characteristics. In other words, we address the following researchquestion.

RQ3: What are the constructs for defining the dynamic semantics of a DSL?

As a solution for research question RQ3, we designed a domain-specific language calledConstelle. Constelle is a meta-language for defining the dynamic semantics of DSLs. To beable to interpret and use Constelle, one needs to know the meaning of a Constelle model, i.e. themeaning of a definition of the dynamic semantics of a DSL. We address the following researchquestion from two points of view. From a practical point of view, we aim to know how toimplement Constelle (in a model transformation). From a theoretical point of view, we aim togive a formal description of the semantics of Constelle.

RQ4: What is the semantics of the language for defining the dynamic semantics ofa DSL?

While defining the semantics of Constelle, we faced a challenge of designing a translation ofa high-level meta-language (Constelle) into an existing (reference) formalism. This translation israther complicated and includes a lot of mappings. The search for a guideline on how to do thiswork led us to the following research question.

RQ5: How to design and describe the semantics of the language for defining thedynamic semantics of a DSL?

As described in Section 1.2, one of the problems we aim to solve in this thesis is the practicalusage of a definition of the dynamic semantics of a DSL. The (methodological) knowledge onhow to use a (programming or meta) language and in what context to use it, is usually capturedin a (yet another) component of a language description: the pragmatics of the language. There-fore, to ensure that Constelle addresses the aforementioned problem of using a definition of thedynamic semantics of a DSL, we formulate the following research question.

6 Introduction

RQ6: What is the pragmatics of the language for defining the dynamic semantics ofa DSL?

Constelle is our solution to the central research question of this thesis (RQ on page 5). Thus,Constelle is meant for giving definitions of certain content and for a certain purpose. To ensurethat Constelle actually achieves these goals, i.e. that our solution is a valid solution, we conductits evaluation. In the process of designing such an evaluation, we formulated the followingresearch question.

RQ7: How can we evaluate the language (and the method) for defining the dynamicsemantics of a DSL?

1.4 Research MethodsIn our thesis we address the following two objects of research: a definition of the dynamicsemantics of a DSL and a meta-language (a method) for giving such a definition. In this section,we formulate the research principles that we follow in relation to these two research objects.For this, we explicitly choose philosophical stances that we adopt in our work. A philosophicalstance determines how we conduct our research in order to come up with an answer to a researchquestion and how we justify whether the gained knowledge is valid [26].

Our research is conducted in the collaboration with an industrial partner, who has experi-ence with developing and applying DSLs. To maximize the relevance of our research results toindustry and to address the practical challenges of developing and applying DSLs discussed inSection 1.2, we aim at having a practically useful and usable definition of the dynamic seman-tics of a DSL. Therefore, we follow the principles of a pragmatist stance when searching for ananswer for our research questions RQ1 and RQ2: what constitutes a definition of the dynamicsemantics of a DSL and what are the requirements for it? Pragmatism adopts an ‘engineeringapproach to research’ and judges knowledge (i.e. an answer to our research questions) by howuseful it is for solving practical problems [26]. As a consequence, pragmatism implies certainrelativism of the obtained knowledge: what is useful for one person might be not useful for an-other person. This means that we need to clearly identify our users, who will use a definition ofthe dynamic semantics of a DSL, and purposes of such use.

The second object of our research, a meta-language for defining the dynamic semantics of aDSL is addressed in the research questions RQ3, RQ4, RQ5, and RQ6. As described earlier inSection 1.2, one of the obvious approaches to describe the dynamic semantics of a DSL would beto use an existing method and/or formalism for defining the dynamic semantics of programminglanguages (GPLs). However, as shown in [53], formal specifications of the dynamic semanticsof DSLs are very rare in practice. To understand the causes of this gap and to propose a possiblesolution, we adopt the philosophical stance of Critical Theory [26]. Critical theory activelyseeks to challenge existing perceptions about software practice (in our case, about defining thedynamic semantics of a DSL) and judges scientific knowledge by its ‘ability to free people fromrestrictive systems of thought’. Moreover, this philosophical stance encourages to choose whatresearch to undertake based on whom it helps, which correlates with the pragmatic approach toour first object of research (a definition of the dynamic semantics of a DSL). Finally, we followthe critical theory stance when designing the evaluation of the proposed meta-language (the topicaddressed in our research question RQ7).

These two philosophical stances, critical theory and pragmatism, direct our research throughthe whole thesis. In particular, they influenced the decomposition of the main research questioninto the series of more specific research questions (as presented in Section 1.3) and the way we

1.5. Outline and Origin of Chapters 7

search for their answers (see Section 1.5). Moreover, to stress this close-to-practice nature of ourwork, we consider our research question (also) as design questions. That is, we aim at designinga method (a meta-language and/or framework and/or process) that (does not resolve from a strictpoint of view but) rather approximates a solution for the problems described in Section 1.2.

1.5 Outline and Origin of ChaptersIn this section, we give an outline of the structure of the remainder of this thesis. In particular,we describe chapters that constitute this thesis and how these chapters map to the formulatedresearch questions. Moreover, for each chapter that is based on an earlier publication, we indicatethe origin of the chapter.

Chapter 2: Defining the Dynamic Semantics of a DSL: a Case Study

In this chapter, we address research questions RQ1 and RQ2. We investigate the notions of thedynamic semantics of a DSL and its definition by conducting a case study. For this, we definethe dynamic semantics of the LACE DSL using the Event-B formalism and QVTo model trans-formations. Following our choice of the pragmatism stance, we identify user roles and discoverhow they can benefit from having an explicit formal definition of the dynamic semantics of theDSL, indicate limitations of the proposed approach and challenges emerging when applying it.Based on our observations from this case study and on the results of the user study conductedas part of this work, we formulate requirements for a definition of the dynamic semantics of aDSL and for a meta-language for giving such a definition (research question RQ2). This chapteris based on the following publications (for which the author was a main contributor).

[98] U. Tikhonova, M. Manders, M.G.J. van den Brand, S. Andova, and T.Verhoeff. Applying Model Transformation and Event-B for Specifyingan Industrial DSL. Proceedings of the 10th International Workshop onModel Driven Engineering, Verification and Validation, 2013.

[97] U. Tikhonova, M. Manders, and R. Boudewijns. Visualization of For-mal Specifications for Understanding and Debugging an Industrial DSL.Proceedings of the Third Workshop on Human Oriented Formal Methods,2016.

Chapter 3: Grand Vision

In this chapter, we ‘zoom out’ from the LACE case study and describe our vision on the DSL-based development approach. This vision is based on the knowledge gained during the LACEcase study and helps us to introduce our ideas on how to address the central research question ofthis thesis. Using the broad picture outlined in this chapter, we indicate the scope of our researchand give an overview on how we address the challenges described in Section 1.2.

Chapter 4: Specification Templates and Constelle for Defining the Dynamic Semantics ofDSLs

In this chapter, we address research question RQ3. We introduce reusable specification templatesand the Constelle meta-language and elaborate their design. For this, we use a small exampleDSL, demonstrate how we define its dynamic semantics using Constelle and specification tem-plates, and specify the corresponding metamodels of Constelle and specification templates. This

8 Introduction

chapter is based on (a part of) the following publication (which won the 2017 Best paper awardof Journal of Software and Systems Modeling and was presented at the ACM/IEEE 20th Inter-national Conference on Model Driven Engineering Languages and Systems, MODELS 2017).

[96] U. Tikhonova. Reusable Specification Templates for Defining DynamicSemantics of DSLs. Software and Systems Modeling (SoSyM), 2017.

Chapter 5: Designing and Describing Model Transformations

In this chapter, we address research question RQ5. Aiming at formulating the semantics of Con-stelle in the next chapter, in Chapter 5 we introduce a notation for describing and designing sucha semantics. In particular, we specify how we use the mathematical notation of set theory andfunctions in order to describe a QVTo model transformation. Moreover, we use this notation toformulate two design principles of developing QVTo transformations: structural decompositionand chaining model transformations. This chapter is based on the following publications.

[99] U. Tikhonova and T. Willemse. Designing and Describing QVTo ModelTransformations. Proceedings of the 10th International Joint Conferenceon Software Technologies, 2015.

[100] U. Tikhonova and T. Willemse. Documenting and Designing QVToModel Transformations Through Mathematics. Selected Papers of the10th International Joint Conference on Software Technologies, 2015.

Chapter 6: Mapping Constelle to Event-B

In this chapter, we address research question RQ4. We define the semantics of the Constelle lan-guage by mapping it to the Event-B formalism. In other words, a meaning of a Constelle modelis computed in the form of an Event-B specification. The definition of the semantic mappingof Constelle to Event-B corresponds to the actual implementation of Constelle, the Constelle-to-Event-B model transformation. Moreover, based on this definition, we derive certain theoreticalresults for a resulting (computed) Event-B specification. This chapter is based on (a part of) thefollowing publication (which is the same paper, that formed the basis of Chapter 4).

[96] U. Tikhonova. Reusable Specification Templates for Defining DynamicSemantics of DSLs. Software and Systems Modeling (SoSyM), 2017.

Chapter 7: Implementation and Pragmatics of Constelle

In this chapter, we address research question RQ6. To elaborate on the pragmatics of our ap-proach, we formulate a process of defining the dynamic semantics of a DSL using Constelle.We describe our implementation of Constelle, the Constelle workbench, and show how its com-ponents support different steps of the formulated process and fulfill the requirements listed inChapter 2.

Chapter 8: Validation of Constelle

In this chapter, we address research question RQ7. In order to evaluate whether Constelle is avalid solution to our central research question, we follow the critical theory stance and choose anempirical method that most closely reflects its philosophy, an action research. The main goal ofour action research is to learn new insights from applying Constelle to another DSL by another

1.5. Outline and Origin of Chapters 9

language developer. Based on the gained insights, we indicate both strong sides and limitationsof Constelle and propose directions for future work.

Chapter 9: Conclusions

This final chapter concludes this thesis. In this chapter, we summarize the main contributionsof our work and revisit our research questions. Moreover, we give an overview of the mostinteresting discussion points and outline directions for future research.

Chapter 2

Defining the Dynamic Semantics of a DSL:a Case Study

Real work is Brussels lace, the main thing in it is whatholds the pattern up: air, punctures, truancy.

Osip Mandelstam, The Fourth Prose

In this chapter we introduce and investigate the notion of the dynamic semantics of a DSLfrom a pragmatic point of view: what constitutes its definition, what are the challenges andoutcomes of the definition process? In particular, we strive to answer the following (research ordesign) questions.

• what are the benefits of constructing and/or having a formal specification of the dynamicsemantics of a DSL?

• how can these benefits be achieved for different roles of users in the development process?

• what are the requirements for a definition formalism (a formalism for defining the dynamicsemantics of a DSL) that allows for achieving practical benefits of constructing/having aspecification of the dynamic semantics of a DSL?

For this, we first introduce the notion of the dynamic semantics of a DSL and discuss the basiccriteria for a definition formalism (Section 2.1). In our investigation of the dynamic semanticsof a DSL from a pragmatic point of view we take a bottom-up approach: we define the dynamicsemantics of an existing DSL (LACE, introduced in Section 2.2) and generalize our observationsand experience in order to answer the listed above questions. The investigation is based on theviewpoints of two user roles of the (software) development process: a DSL developer and a DSLuser. We describe these user roles and how they can use a definition of the dynamic semantics ofthe DSL (i.e. the use cases) in Section 2.3.

As the existing formalisms for specifying the semantics of general purpose languages (GPLs)(such as Action Semantics [70] and Structural Operational Semantics [78]) do not have practi-cally applicable tool support, in order to realize the identified use cases, we choose a different

12 Defining the Dynamic Semantics of a DSL: a Case Study

specification formalism for our case study: Event-B (Section 2.4). As the chosen formalism isnot specifically designed for defining the dynamic semantics of DSLs (or GPLs), we face cer-tain challenges when applying it to the specification of our DSL. Section 2.5 describes how weovercome these challenges and align the specification formalism (Event-B) with the DSL devel-opment environment. In Section 2.6 we implement one of the previously identified use casesby providing a domain specific visualization for our Event-B specifications of LACE. The user-friendly visualization allows for performing a user study, described in Section 2.7. The feedbackprovided by the users during this study and lessons learned during the specification of LACE inEvent-B form the set of requirements for a definition formalism listed in Section 2.9. Thus, thischapter serves as a main source of motivation for the rest of the thesis.

2.1 A Definition of the Dynamic Semantics of a DSLIn our work we focus on domain-specific programming (or executable) languages. In otherwords, we restrict the scope of our research by DSLs that can be used for programming, i.e.for defining programs that can be executed. A DSL defines a set of executable programs, and thedynamic semantics of the DSL determines the behavior of such programs (i.e. the way in whicheach DSL program executes). A definition of the dynamic semantics of a DSL consists of thefollowing two components:

• a semantic domain providing terms to define the dynamic semantics;

• a semantic mapping mapping the DSL (metamodel or abstract syntax) to the semanticdomain.

AC

B

Figure 2.1: T-diagram

To depict a definition of the dynamic semantics of a DSL, we employ the notation of T-diagrams (or Tombstone diagrams) [5]. T-diagrams (Figure 2.1) are used in compiler theoryto represent that a translation from a source language A (left ‘wing’ of T) to a target languageB (right ‘wing’ of T) is realized in the implementation language C (the ‘basement’ of T). Ascompilers are a special case of a semantic mapping, we generalize this notation to illustratedefinitions of dynamic semantics: the DSL being defined is depicted as the left ‘wing’ of T; thesemantic domain is depicted as the right ‘wing’ of T; and the language or formalism employedfor defining the semantic mapping is represented by the ‘basement’ of T.

A definition of the dynamic semantics of a DSL should be [108]:

• precise, so that the definition can be interpreted unambiguously,

• intelligible, so that the definition can be interpreted by humans,

• executable, so that the definition can be interpreted by tools.

The criterion of an intelligible definition depends on the background of a particular reader. Inpractice, an intelligible definition can in most cases be achieved through a precise and executabledefinition, thus three criteria can be reduced to two criteria. Precision of a definition is achieved

2.2. The LACE DSL 13

by employing a formalism based on a solid mathematical theory. Executability of a precisedefinition is achieved by employing tools that implement this theory. Note that when employingsuch tools we have to rely on the level of preciseness that these tools provide to conform to thetheory.

When applying the criteria of a precise and executable definition to the two components of asemantics definition we get the following practical outcomes:

• A precise semantic mapping and semantic domain allow for reasoning and analysis of theDSL semantics in terms of the formalism of the semantic domain.

• An executable semantic domain allows for the execution of DSL programs in terms of thesemantic domain.

• An executable semantic mapping allows for automatic translation of DSL programs intomodels expressed in terms of semantic domain.

In current practice usually at least one of the three outcomes listed above is not attainable.For example, both semantic domain and semantic mapping are executable but not precise (Fig-ure 2.2(a) illustrates a common implementation of a DSL, the triangle on the bottom denotes thatthe ‘basement’ formalism is executable); or both the semantic domain and semantic mapping areprecise, but the semantic mapping is not executable (Figure 2.2(b) illustrates the work presentedin [94]); or both the semantic domain and semantic mapping are executable, but the semanticmapping is not precise (Figure 2.2(c) illustrates the work presented in [102]).

DSLJava

C

Java

(a)

DSLSOS

LTS

(b)

DSLXtend

POOSL

Xtend

(c)

Figure 2.2: T-diagrams of some existing dynamic semantics definitions

To achieve an unambiguous understanding of a DSL and to enhance the DSL developmentwith formal analysis and tool support, we would like to have both its semantic mapping andsemantic domain definitions to be precise and executable. To achieve this (in our case study andin the rest of the thesis), we employ a formalism that has both a solid theory and tool support (seeSection 2.4). In practice this means that our definition of the dynamic semantics of a DSL existsnext to an implementation of the DSL that is developed using imprecise tools (such as modeltransformation and/or code generation languages) and is actually used for the development ofDSL programs. In the next section we describe the DSL used for our case study and the softwarearchitecture that implements this DSL.

2.2 The LACE DSLOur case study was performed at ASML,1 the world-leading manufacturer of lithography sys-tems (called waferscanners) for the semiconductor industry. Waferscanners are complex ma-chines which participate in the production pipeline of integrated circuits or chips. LACE (Logi-cal Action Component Environment) is a DSL, used within ASML for describing logical action

1www.asml.com, http://en.wikipedia.org/wiki/ASML_Holding

www.asml.com

http://en.wikipedia.org/wiki/ASML_Holding


components and for using such descriptions to (automatically) generate software that controlsa waferscanner by invoking hardware drivers in a synchronized and effective way. The keyconcepts of LACE and the supporting software architecture have been introduced about twelveyears ago. Seven years ago the LACE DSL was developed to wrap the manual configuration ofthe source code into a graphical notation and to allow for the automatic generation of source codeconfigurations. LACE has a graphical notation based on UML activity diagrams and provides anenvironment for defining (and editing) LACE programs (models).

The main purpose of LACE is the coordination of machine parts of a waferscanner, i.e. phys-ical subsystems: actuators, projectors, sensors, etc. A LACE program (model) consists of oneor more logical actions, each of which defines how a set of subsystems operate in collaborationwith each other in order to perform a required (logical) function of the machine. An exampleof a logical action is shown in Figure 2.3. Note that although the graphical notation of LACE isbased on UML activity diagrams, the dynamic semantics of LACE does not follow the semanticsof UML activity diagrams.

take_a_snapshot

Laser Sensor Handler Projector

AdjustFrame PositionObject

MoveParking

Switch

ProduceLight GrabAFrame

objectPos

framePos

snapshot

Glass

Figure 2.3: An example of a logical action for taking a snapshot

A logical action describes desired behavior in terms of an abstract representation of sub-system functions – subsystem actions. In Figure 2.3 the subsystems participating in the logicalaction are represented as swimlanes (columns). Subsystem actions are represented as roundedrectangles. Each subsystem action belongs to the corresponding subsystem (column).

Subsystem actions, combined together into a so-called scan (visualized as a dashed roundedrectangle in Figure 2.3), are executed in unison, that is, the subsystem actions within such a groupwill start and end at the same time. Thus, the Sensor subsystem starts and stops executing theGrabAFrame action at the same moments as the Laser subsystem starts and stops executingthe ProduceLight action.2

Subsystem actions within a logical action can be executed sequentially or concurrently (vi-sualized as thick arrows and fork and join nodes). For example, the subsystem actions Adjust-FramePosition and PositionObject are independent actions that can be executed in anyorder or in parallel, but the GrabAFrame action can be performed only after both these actionsare finished. Finally, subsystem actions may require and produce data. The dataflow in a logicalaction is depicted by means of thin arrows, connected to input and output pins. For example,in Figure 2.3 the GrabAFrame action produces data, which is saved in the snapshot output

2In the rest of this thesis, we use this font convention when referring to elements of a LACE program.

2.2. The LACE DSL 15

parameter.The high-level description of the machine subsystems’ behavior, given in logical actions, is

translated into the invocations of hardware drivers and a synchronization driver in such a waythat the resulting execution matches the behavior specified in the logical actions. An overviewof the software architecture that realizes the LACE DSL is depicted in Figure 2.4.

Logical action model

LACsoftware

Synchronization driver

generate

LACE

SW A

HW A

SW B

HW B

SW C

HW C

SW D

HW D{subsystems layer

{LACs layer

logical actionsrequests

Controlling software

Figure 2.4: Software architecture for execution of logical actions

The architecture consists of three layers: controlling software, logical action components(LACs), and a subsystems layer. A LAC provides an interface for requesting the execution oflogical actions by controlling software. LAC translates requested logical actions into subsystemactions and requests the execution of these subsystem actions from the corresponding subsys-tems. The subsystems are responsible for the actual execution of subsystem actions. They storerequested subsystem actions in buffers and execute them in order of arrival. The subsystems runindependently from each other and from LACs. Moreover, the buffered execution of subsystemactions allows for the parallel (overlapped) execution of multiple logical actions. That is, a sub-system action from a next logical action can be executed while a subsystem action from the pre-vious logical action is still in the queue (unless this situation violates the execution order withinthe logical actions). For example, two instances of the logical action take_a_snapshot (de-fined in Figure 2.3) overlap while being executed, if the subsystem action MoveParking of thefirst instance is still (awaiting to be executed) in the queue of the Handler and the subsystemaction AdjustFrame of the second instance is already being executed by Sensor. Such anapproach is intended for improving the throughput of a machine.

The dynamic semantics of LACE determines the independent execution of subsystem actionson different subsystems and, at the same time, takes care of the proper order of their executionsand their synchronization. In order to modularize (and thus, to improve understandability of)the description of the dynamic semantics of LACE, we introduce semantic features (SFs). Asemantic feature is a module of the dynamic semantics description (informal or formal) whichcan be considered separately from or/and as an extension to other semantic features. Next tothe modularity introduced by the DSL syntax (DSL constructs, such as a logical action, or asubsystem action) and the modularity introduced by the DSL architecture (software components,such as LAC and subsystems), semantic features modularize the dynamic semantics, i.e. the(many-to-many) mapping of the DSL constructs to the DSL software components. For LACEwe distinguish the following semantic features.


Core SF The order of the execution of subsystem actions on each subsystem corresponds to (isa subset of) the order of requests of logical actions that have been translated into thesesubsystem actions. This is achieved in the LAC layer by processing logical actions oneby one: the next logical action can be requested only after the previous one has beencompletely translated into subsystem action requests.

Scan SF Subsystem actions, combined together into a scan, are executed simultaneously. Thismeans that if a subsystem needs to execute its subsystem action, which is a part of a scan,then this subsystem has to wait for the other subsystems, involved in this scan, to executethe scan together. The corresponding behavior is realized in the subsystems layer.

Order SF A partial order on the subsystem actions of a logical action determines parallel andsequential execution of the subsystem actions. This feature is implemented in the LACslayer: a subsystem action cannot be requested before the execution of the subsystem ac-tions that precede it has finished.

Data SF Subsystem actions in a logical action description may require and produce data. Thisimplies that a subsystem action that requires some data cannot be requested before theexecution of the subsystem action that produces this data. The dataflow is taken care of bythe LACs layer.

In our specification of the dynamic semantics of LACE we remain at a high level of abstrac-tion and do not describe the details of the interaction protocol and the synchronization mecha-nism.

2.3 Use Cases and User Roles of LACE SpecificationA high-level description of logical actions in a LACE program is translated into the invocationsof hardware drivers in such a way that the resulting execution matches the behavior defined inthe LACE program. The semantic gap between LACE and driver functions is wide, and thus, thetranslation is hard to develop, maintain, understand, and use. We aim at constructing a formalspecification of the dynamic semantics of LACE in order to enhance understandability, maintain-ability and usage of the DSL translation. This can be achieved through applying different kinds ofanalysis to the formal specification of LACE. In relation to the DSL-based development process,we can identify two different roles of users: a DSL developer and a DSL end-user. Figure 2.5depicts how these these two user roles can benefit from a formal specification of LACE.

Verify LACE design

LACE developer

LACE user

Event-B / Rodin

Animation

Visualization

Discharging POs

Model checking

«extends»

«implements»

«implements»

«implements»

«implements»

Validate LACEdesign

SimulateLACE program

AnalyzeLACE program

«implements»

Figure 2.5: Use cases and user roles of LACE specification

2.4. Event-B and Rodin 17

A DSL developer designs and develops the DSL by constructing its metamodel and imple-menting its dynamic semantics through various translations (for example, through code genera-tion). A formal specification of the DSL dynamic semantics can be used by the DSL developerto verify that the design of the DSL is consistent (non-contradictive), feasible, and complete (theleft top bubble in Figure 2.5). Moreover, the DSL developer can validate the dynamic semanticsof the DSL by executing various (sample) programs and ensuring that the observed behaviorcorresponds to his/her expectations (the left lower bubble in Figure 2.5).

A DSL user specifies DSL programs as instances of the DSL metamodel and executes thesource code generated from these programs. A DSL user usually does not know how the DSL isimplemented (i.e. how the translation works) and employs high-level user manuals to learn theDSL constructs and their (approximate) semantics. A formal specification of the DSL dynamicsemantics can be used by a DSL user to simulate the execution of his/her programs (the rightbottom bubble in Figure 2.5). In this way, a DSL user can obtain a better understanding ofthe dynamic semantics of the DSL and improve his/her programs according to this obtainedknowledge. Moreover, a (more advanced) DSL user can analyze behavior of his/her programs,for example by assessing their throughput or checking various (temporal) properties (the righttop bubble in Figure 2.5).

The described use cases and user roles determine the choice of a specification formalism fordefining the dynamic semantics of LACE. There exist a number of approaches for defining thedynamic semantics of general purpose languages (GPLs), such as denotational and algebraicsemantics [108, 73], action semantics [70], and structural operational semantics (SOS) [78].However, these formalisms do not have practically applicable tool support. At the same time,there exists quite a number of tools that support formalisms for specifying behavior of hard-ware and software systems, such as Z, B, Event-B, and Abstract State Machines (ASM). Theseformalisms are not designed for specifying the DSL semantics, but allow for specifying andanalyzing behavior in general.

Aiming for practical benefits of having a formal definition of the DSL dynamic semantics(i.e. for realizing the use cases listed above), we have chosen to perform our case study with theEvent-B formalism and the Rodin platform (Figure 2.5 in the middle). The next section brieflyintroduces this formalism and describes how the Rodin tool set implements the use cases.

2.4 Event-B and RodinEvent-B is an evolution of the B method, both introduced by Abrial [1, 2]. Event-B employsset theory and first-order logic for specifying software and/or hardware behavior. An Event-Bspecification consists of contexts and machines. A context describes the static part of a system:sets, constants, and axioms. A machine uses the context to specify behavior of a system via astate-based formalism. Variables of the machine define the state space. Events, which changevalues of these variables, define transitions between the states. An event consists of guardsand actions, and can have parameters. An event can occur only when its guards are true, andas a result of the event its actions are executed (in parallel). Parameters represent existentiallyquantified variables local to the event and are used in its guards and actions to represent an inputor auxiliary data. The properties of the system are specified as invariants, which should hold forall reachable states. Moreover, one can specify theorems based on the global axioms or invariantsof the specification or on the local guards of an event.

The Rodin platform [3] offers various tools (plug-ins) for Event-B:

• editors of Event-B specifications, that implement the familiar notation of set theory and


predicates in Unicode, supporting the what-you-see-is-what-you-get (WYSIWYG) princi-ple;

• syntactical analysis of Event-B specifications, that includes type checking of various for-mulas of set theory and first-order logic;

• automatic generation of proof obligations, that help to ensure that an Event-B specificationis (semantically) consistent (for example, that invariants are preserved and predicates arewell-defined);

• interactive and automatic provers, that facilitate discharging of proof obligations and/ortheorems of the specification;

• model checking, that can be used to verify if a specified behavior respects certain proper-ties;

• animation (i.e. execution of a specification), that allows for debugging of Event-B specifi-cations;

• a graphical editor for constructing domain-specific visualizations of Event-B specifica-tions.

Thus, Event-B and Rodin in principle allow for realizing the use cases described in Sec-tion 2.3 (Figure 2.5 in the center). Syntactical analysis of Event-B specifications and discharg-ing proof obligations ensure that an Event-B specification is correct-by-construction. This con-tributes to the verification of the DSL design (that it is consistent, feasible, and complete). Modelchecking allows for verification of more complicated properties of the dynamic semantics of theDSL. Animation of Event-B specifications can be used for validation of the DSL design by theDSL developers and for simulation of DSL programs by DSL users. Moreover, a domain specificvisualization can make the animation of Event-B specifications comprehensible for DSL users,who are not familiar with the formal notation of Event-B.

Another benefit of Event-B is that it has an active community of users and developers withannual (informal) workshops, where users’ experiences, newly developed tools and techniques,and functionality requests are presented, discussed, and picked up.3 We introduce the syntax andthe semantics of Event-B in the next section, as we apply it to the specification of the LACEDSL.

2.5 Specification of LACE Dynamic Semantics in Event-BLACE dynamic semantics is specified in Event-B as a set of Event-B contexts and machines.Event-B contexts represent data structures, which are used in Event-B machines for specifyingbehavior. This explicit separation of data structure from behavior is very useful for constructingEvent-B specifications for the different (meta-)levels of LACE.

In the MDE context a DSL resides in two abstraction levels: the DSL metamodel and DSLmodels (programs). The DSL is designed and implemented on the metamodel level, and it is usedvia instantiating DSL programs on the model level. On the metamodel level, a generic Event-Bspecification of the DSL can be created and analyzed once (for example, by discharging proofobligations generated for the specification). On the model level, Event-B specifications of DSLprograms need to be constructed many times, for each concrete DSL program (for example, to

3www.event-b.org, http://wiki.event-b.org/index.php/Main_Page

www.event-b.org

http://wiki.event-b.org/index.php/Main_Page

2.5. Specification of LACE Dynamic Semantics in Event-B 19

model check its state space or simulate its execution). In other words, the different use casesapplicable on these two levels (i.e. the different kinds of analysis of the corresponding Event-Bspecifications) require different levels of details in the specified LACE data structures. There-fore, we specify data structures from different levels in different Event-B contexts: a metamodelcontext and a model context (see Figure 2.6). In Section 2.5.1 we describe the details of thistechnique.

LACEmetamodel

LACEprogram

Simulation

Discharging POs

Model checking

metamodelcontext

modelcontext

conceptualmachine

sees

sees

Event-BDSL / EMF

M2M«instantiate»

Rodin

compositemachine

M2M

input

input

M2M

Figure 2.6: Instantiation and composition of Event-B specifications of LACE

The specification of the dynamic semantics of LACE in Event-B is not trivial: the constructsof LACE do not map one-to-one to the constructs of Event-B. Therefore, to make the specifica-tion clear and comprehensible, we strive towards a modular design of the specification. For this,we identify two dimensions of modularity that are present in the dynamic semantics of LACE:architectural modularity and semantic modularity. The first dimension is formed by the com-ponents of two layers of the LACE software architecture: subsystems and LACs. The seconddimension consists of the semantic features, listed in Section 2.2. We specify these modules inEvent-B in separate conceptual machines using the metamodel context of LACE. Using one ofthe (de)composition techniques of Event-B, we compose conceptual machines together into acomposite machine that specifies the behavior of a concrete LACE program (see Figure 2.6). InSection 2.5.2 we describe the details of this technique.

To automate construction of model contexts and of composite machines for an arbitraryLACE program, we developed a model transformation from LACE to Event-B (M2M in Fig-ure 2.6). The LACE-to-Event-B model transformation implements both the modularity of thedynamic semantics of LACE, and two (meta-)levels of its specification as described further inSections 2.5.1 and 2.5.2. The technical details and the results are given in Section 2.5.3. Thework presented in this section is published in [98].

2.5.1 Specification of LACE Structure in Event-B2.5.1.1 Event-B contexts

To specify the dynamic semantics of LACE in Event-B, we first need to specify the structure ofLACE in Event-B. This is done in Event-B contexts. As we mentioned above, the structure ofLACE (as of any other DSL in MDE) takes two different forms: the metamodel and a model.The metamodel of LACE describes the constructs of the language and how these constructs canbe combined together. A model instantiates the language constructs for a concrete application ofLACE. In Event-B we specify both these forms of the LACE structure – in a metamodel contextand in a model context.

The metamodel context captures the structure specified in the LACE metamodel. For exam-ple, Figure 2.7(a) shows the metamodel context for the two semantic features of LACE: Core


SF and Order SF. The DSL constructs are introduced via Event-B sets (the ‘SETS’ section):SSAction for subsystem actions, LogicalAction for logical actions, and Occurrence to modeloccurrences of subsystem actions within a logical action.4 The relationships between the DSLconstructs are introduced via Event-B constants (the ‘CONSTANTS’ section): LALabelDef,LAOrderDef, and SS1. Event-B axioms specify the structure (types) of these relationships anddefine additional properties for them (i.e. static semantics). For example, LALabelDef is spec-ified in axm1 in Figure2.7(a): LALabelDef associates each logical action (LogicalAction →)with a subset of occurrences of subsystem actions (modeled as a partial function Occurrence 7→SSAction). The relation LAOrderDef introduces a partial order on this subsets of occurrences(separately for each logical action): axm3 associates each LogicalAction with a relation of Oc-currences; axm4 ensures that this relation is in the scope of the LALabelDef of this logicalaction; axm5 forbids cycles in this relation. The constant SS1 is used to distinguish subsys-tem actions of a separate subsystem: axm2 defines it as a subset (⊆) of all available subsystemactions SSAction. As on the level of the LACE metamodel we do not know which particularsubsystems participate in a concrete logical action (specified on the model level), we use SS1as a placeholder, which is instantiated for each concrete subsystem of a LACE model – in thecorresponding model context.

CONTEXT lace metamodel order context

SETSSSAction, LogicalAction, Occurrence

CONSTANTSLALabelDef, LAOrderDef, SS1

AXIOMS

axm1 : LALabelDef ∈ LogicalAction→(Occurrence 7→ SSAction)

axm2 : SS1 ⊆ SSAction

axm3 : LAOrderDef ∈ LogicalAction→(Occurrence↔Occurrence)

axm4 : ∀la·la ∈ LogicalAction⇒(dom(LAOrderDef(la)) ⊆ LALabelDef(la) ∧ran(LAOrderDef(la)) ⊆ LALabelDef(la))

axm5 : ∀la, s·la ∈ LogicalActions ∧LAOrderDef(la) 6= ∅ ∧

s ⊆ dom(LAOrderDef(la)) ∧ s 6= ∅⇒s * LAOrderDef(la)[s]

END

(a) Metamodel context

CONTEXT takeasnapshot model order context

SETSSSAction, LogicalAction, Occurrence

CONSTANTSLALabelDef, LAOrderDef,laTAS, Laser, Sensor, Handler, Projector,ssaPL, ssaAF, ssaGAF, ssaPO, ssaMP, ssaSG,o1, o2, o3, o4, o5, o6

AXIOMS

axm1 : partition(SSAction, {ssaPL}, {ssaAF},{ssaGAF}, {ssaPO}, {ssaMP}, {ssaSG})

axm2 : partition(Laser, {ssaPL})axm3 : partition(Sensor, {ssaAF}, {ssaGAF})axm4 : partition(Handler, {ssaPO}, {ssaMP})axm5 : partition(Projector, {ssaSG})axm6 : partition(LogicalAction, {laTAS})axm7 : partition(Occurrence,

{o1}, {o2}, {o3}, {o4}, {o5}, {o6})axm8 : partition(LALabelDef, {laTAS 7→ {o1 7→ ssaPL,

o2 7→ ssaAF, o3 7→ ssaGAF, o4 7→ ssaPO,o5 7→ ssaMP, o6 7→ ssaSG}})

axm9 : partition(LAOrderDef, {laTAS 7→ {o1 7→ o2,o1 7→ o4, o3 7→ o2, o3 7→ o4, o6 7→ o1, o6 7→ o3, o5 7→ o6}})END

(b) Model context

Figure 2.7: Contexts of the specification of Core SF with Order SF

In a model context, the sets and constants, introduced in the metamodel context, are assignedconcrete values. These values represent (correspond to) the concrete LACE model (program).For example, Figure 2.7(b) shows the model context that instantiates the metamodel context forthe LACE program depicted in Figure 2.3. For this, the LACE-to-Event-B model transforma-

4In the rest of this thesis, we use this font convention when referring to elements of an Event-B specification.


tion generates extra constants to represent concrete values (i.e. objects) appearing in the LACEprogram in Figure 2.3:

• the constant laTAS represents the logical action take_a_snapshot;

• the constants Laser, Sensor, Handler, and Projector represent the subsystems Laser,Sensor, Handler, and Projector;

• the constants ssaPL, ssaAF, ssaGAF, etc. represent the subsystem actions Produce-Light, AdjustFrame, GrabAFrame, etc.;

• the constants o1, o2, o3, etc. represent occurrences of the subsystem actions in the logicalaction.

The axioms of the model context (Figure 2.7(b)) assign values to the constructs and structuralrelations, introduced in the metamodel context. For example, axm1 assigns SSAction to a set ofthe elements ssaPL, ssaAF, ssaGAF, ssaPO, ssaMP, and ssaSG (i.e. to the constants representingsubsystem actions). Axioms axm2-5 split this set into the subsets representing the subsystemsLaser, Sensor, Handler, and Projector.

As depicted in Figure 2.6, a conceptual machine uses the metamodel context to specify thedynamic semantics of LACE in terms of the metamodel. Based on the structural properties,specified in the axioms of the metamodel context, the Rodin tool set generates proof obligationsfor the conceptual machines. By discharging these proof obligations, a DSL developer can ensurethat the Event-B specification of LACE is consistent and complete. In this way, the dynamicsemantics of LACE is specified and analyzed on the metamodel level. The metamodel contextand the conceptual machines for a specific DSL are constructed manually and only once.

When the Event-B sets and relations instantiated in the model context are used instead ofthe abstract sets and relations of the metamodel context, the Event-B machine (a composite ma-chine in Figure 2.6) specifies the behavior of a concrete LACE program. Such a specificationcan be model checked and animated, allowing for the analysis of a particular LACE program.Model contexts are generated automatically from LACE programs by the LACE-to-Event-Bmodel transformation.

2.5.1.2 Generic instantiation

In the context of MDE, the MOF standard defines the conformance relationship between a modeland a metamodel. When one creates a LACE model, this model conforms to the LACE meta-model, i.e. instantiates its syntax constructs and obeys the rules of its static semantics. In Event-B we can connect the model and the metamodel contexts with a relationship, parallel to theconformance relationship between a model and the metamodel using generic instantiation [4].Comparing to the MOF conformance relationship, the Event-B generic instantiation ensures thestructural conformance (of a model to the metamodel) in order to reuse the Event-B specificationand its discharged proof obligations.

According to the generic instantiation technique, if all structural properties that are defined inthe metamodel context can be derived for the structure that is instantiated in the model context,then the discharged proof obligations for the Event-B machine can be extended straightforwardlyfrom the metamodel level to the model level [4]. In other words, if we show that the sets andconstants of the model context conform to the axioms of the metamodel context (for example,that axm4 of the metamodel holds for the LALabelDef and LAOrderDef as specified in axm8and axm9 of the model context); then we can reuse the proof obligations, discharged for the


conceptual machines on the metamodel level, for the composite machine on the model level(Figure 2.6).

In [88] and [10] it is proposed to use theorem proving to show that the metamodel propertiescan be derived for the model context. However, due to the large sizes of our model contexts(generated from LACE programs), the automatic provers of Rodin fail to discharge such (in-stantiation) theorems. For example, if a LACE model consists of three logical actions, each ofwhich consists of six to ten subsystem actions, then the structural properties defined in axioms inFigure 2.7(a) can not be automatically proved for the corresponding model context using Rodinprovers. On the other hand, we do not expect an average DSL user to prove these theorems usingRodin interactive provers, as it requires knowledge of propositional calculus and understandingof proof strategies. Therefore, instead of the theorem proving, we employ evaluation of the pred-icates that capture structural properties in the ProB animator integrated in Rodin [60]. Thus,we check the conformance relationship between a model context and the metamodel context inEvent-B for each concrete LACE program (in a semi-automatic way).

Such a check might seem superfluous, as each LACE model already conforms to the LACEmetamodel. However, the metamodel context for LACE and the LACE-to-Event-B model trans-formation are constructed manually. Checking that a model context, that is generated by thetransformation, instantiates the metamodel context can reveal potential errors (such as inconsis-tencies or gaps) in these manually constructed artifacts. Therefore, such a check is useful.

2.5.2 Composition of LACE Behavior in Event-BAs we mentioned before, we employ a modular approach in order to facilitate developmentand understandability of the Event-B specification of the LACE dynamic semantics. For this,we identify two types of modules (dimensions of modularity) in the LACE dynamic semantics:architectural components (such as LACs and subsystems) and semantic features (such as Core SFand Scan SF). These two different types of modularity require different techniques for composingconceptual machines (that specify separate modules) into the composite Event-B machine (thatspecifies the dynamic semantics of LACE): viz. the shared event composition technique [89] andweaving of Event-B code.

2.5.2.1 Event-B machines

As mentioned earlier, each module of the Event-B specification of the LACE dynamic semanticsis represented in a separate Event-B machine. For example, the core semantics (Core SF) of alogical action component (LAC) and of a subsystem (SS) is specified in the machines depictedin Figures 2.8(a) and 2.8(b) correspondingly. Each of these machines uses (‘SEES’) the sameEvent-B context lace_metamodel_core_context, which is a subset of the metamodel context dis-cussed in Section 2.5.1. Below we explain the details of the Event-B syntax using the exampleof the LAC machine.

LAC is responsible for processing a requested logical action through translating it into re-quests of the corresponding subsystem actions. In the machine lace_LAC_core the variablecurr_la represents the logical action that is currently being processed; and the variable curr_jobstores the (occurrences of) subsystem actions that still need to be requested (from the correspond-ing subsystems). The invariants specify the corresponding types of the variables: inv1 definescurr_job as a subset of subsystem actions occurrences; inv2 defines curr_la as a logical action.In the (standard for Event-B) special event Initialisation, we assign the default values to the vari-ables according to their types: curr_job is empty (act1 ); curr_la is any logical action from theset LogicalAction (act2 ).


MACHINE lace LAC core

SEES lace metamodel core context

VARIABLEScurr job, curr la

INVARIANTS

inv1 : curr job ∈ P(Occurrence)

inv2 : curr la ∈ LogicalAction

EVENTS

Initialisation

beginact1 : curr job := ∅act2 : curr la :∈ LogicalAction

end

Event request la =

any la

wheregrd1 : la ∈ LogicalActiongrd2 : curr job = ∅thenact3 : curr job := dom(LALabelDef(la))act4 : curr la := la

end

Event request ssa =

any occurrence, ssaction

wheregrd3 : curr job 6= ∅grd4 : occurrence ∈ curr jobgrd5 : occurrence 7→ ssaction ∈

LALabelDef(curr la)thenact5 : curr job := curr job \ {occurrence}

end

END

(a) Event-B machine specifying the behavior of LAC

MACHINE lace SS1 core


VARIABLESss1 buffer

INVARIANTS

inv1 : ss1 buffer ∈ N 7→ (SS1)

inv2 : finite(ss1 buffer)

EVENTS

Initialisation

beginact1 : ss1 buffer := ∅

end

Event request ssa =

any ssaction, ss1 index

wheregrd1 : ssaction ∈ SS1grd2 : ss1 index ∈ Ngrd3 : ss1 buffer 6= ∅⇒(∀i·i ∈ dom(ss1 buffer)⇒ ss1 index > i)

thenact2 : ss1 buffer := ss1 buffer ∪

{ss1 index 7→ ssaction}end

Event execute ssa =

any ssaction, ss1 index

wheregrd4 : ss1 buffer 6= ∅grd5 : ss1 index 7→ ssaction ∈ ss1 buffergrd6 : ∀i·i ∈ dom(ss1 buffer)⇒

ss1 index ≤ ithenact3 : ss1 buffer := ss1 buffer \

{ss1 index 7→ ssaction}end

END

(b) Event-B machine specifying the behavior of SS

Figure 2.8: Event-B machines specifying the core dynamic semantics of LAC and SS1

The (major part of the) dynamic semantics of Core SF for LAC is defined in the events of themachine: request_la and request_ssa. The request_la event is used for requesting a logical action.The logical action being requested is represented by the (local) parameter la (‘any’ section). Theguards (‘where’) check the type of the local parameter (grd1 ) and ensure that the previous logicalaction has been processed (i.e. that curr_job is empty, grd2 ). As a result of this event (‘then’),curr_job is assigned the subset of occurrences that constitute the logical action la accordingto the structure defined in LALabelDef (act3 ); and curr_la is updated to the requested logicalaction (act4 ). The request_ssa event empties curr_job by removing one-by-one subsystem actionoccurrences from it (act5 ).

Figure 2.8(b) shows the Event-B machine specifying a subsystem (SS). Each subsystemstores the requested subsystem actions in its buffer (in the request_ssa event) and executes themone-by-one in a first-in-first-out (FIFO) order (in the execute_ssa event). To respect the FIFO or-der of requested subsystem actions, the variable ss1_buffer is modeled as a partial function from


natural numbers to subsystem actions of this subsystem (N 7→ SS1). When a new subsystemaction is requested, it is added to the buffer coupled with an index that is bigger than any otherindex in the buffer (grd3 in the request_ssa event). Correspondingly in the execute_ssa event,the subsystem action with the lowest number is executed (grd6 ).

2.5.2.2 Architectural modularity

The LAC and SS components, described above, interact with each other using the request_ssaevent: LAC sends the request for the execution of a subsystem action to SS. To model thisinteraction, we use the Event-B shared event composition technique [89]. This technique allowsfor constructing an Event-B machine from constituent machines (modules) by synchronizing(weaving/composing together) their events (with no common variables allowed in the constituentmachines). Thus, in a composite machine lace_LACxSS_core the events request_ssa of the LACand SS machines are composed together (synchronized) into a new composite event request_ssa.Figure 2.9 shows the corresponding fragment of the composite machine. The (not overlapping,independent) variables of the constituent machines are conjoined in the composite machine, theinvariants are conjuncted, and the other (non-synchronized) events are copied to the compositemachine without any change.

MACHINE lace LACxSS1 core


VARIABLEScurr job, curr la, ss1 buffer

INVARIANTS

lac inv1 : curr job ∈ P(Occurrence)

lac inv2 : curr la ∈ LogicalAction

ss1 inv1 : ss1 buffer ∈ N 7→ (SS1)

ss1 inv2 : finite(ss1 buffer)

EVENTS...

Event request ssa =

any occurrence, ssaction, ss1 index

wherelac grd1 : curr job 6= ∅lac grd2 : occurrence ∈ curr joblac grd3 : occurrence 7→ ssaction ∈ LALabelDef(curr la)ss1 grd1 : ssaction ∈ SS1ss1 grd2 : ss1 index ∈ Nss1 grd3 : ss1 buffer 6= ∅⇒ (∀i·i ∈ dom(ss1 buffer)⇒ ss1 index > i)thenlac act1 : curr job := curr job \ {occurrence}ss1 act1 : ss1 buffer := ss1 buffer ∪ {ss1 index 7→ ssaction}

end

...

Figure 2.9: Event-B machine composed of LAC and SS1

The composite event request_ssa in Figure 2.9 uses the conjunction of the guards of theconstituent events (request_ssa in Figures 2.8(a) and 2.8(b)). The actions of the constituentevents are combined (and are executed in parallel). The parameters of the constituent events arejoined with respect to the shared parameter ssaction, which is used for the exchange of the data(synchronization) between the interacting components. Thus, ssaction requested by LAC (in the


request_ssa event in Figure 2.8(a)) is the same as ssaction accepted by SS for the execution (inthe request_ssa event in Figure 2.8(b)).

In this way, we use the Event-B shared event composition technique to specify the archi-tectural modularity of LACE. The composition of the LAC and SS machines is implementedusing the model transformation LACE-to-Event-B (the M2M arrow from conceptual machines tocomposite machines in Figure 2.6). Note that, while each subsystem can be specified using thesingle Event-B machine (such as depicted in Figure 2.8(b)), on the model level this machine isinstantiated for each concrete subsystem that participates in a logical action. This is necessaryin order to model the execution of LACE programs on a real-life waferstepper, where each LACinteracts with multiple subsystems in parallel. As a result, the generated composite machine canbe composed of one LAC machine and multiple SS machines. We use the ss1_ prefix to highlightthe specification elements that are instantiated (i.e. renamed) on the model level.

2.5.2.3 Semantic modularity

Compared to the architectural components, semantic features do not have clearly defined bound-aries and interaction interfaces. Instead, we specify Scan SF, Order SF, and Data SF (introducedin Section 2.2) as independent or gradual extensions of Core SF, as schematically depicted inFigure 2.10(a). The specifications of different SFs can use different data types; can introduce dif-ferent variables, invariants, guards, and actions; and even can change (adapt) invariants, guards,and actions. This results in a tangled composition of SFs together, as presented in Figure 2.10(b).

coredataorder scan scan

scandata

order

order

Event-B machines

(a) Configurations of machines

datacore scanorder LACE SFs

LACE-to-EventBtransformation

Event-B code

(b) Weaving semantic features

Figure 2.10: Composition of LACE semantic features in Event-B

For example, Figure 2.11 shows the (simplified) specification of Order SF for LAC. Here, thevariable wait_exe stores the subsystem actions (i.e. their occurrences) that should precede othersubsystem actions. This variable is initialized when a new logical action is requested (act6 in therequest_la event). A subsystem action is removed from wait_exe as soon as it is executed (theexecute_ssa event in Figure 2.11). The order of the execution of subsystem actions is achievedthrough the following specification. A subsystem action can not be requested (for the executionby the corresponding SS) if it depends on (follows) a subsystem action that is still present in thewait_exe subset (grd5 of the request_ssa event).

Thus, Order SF adds new elements to the specification of Core SF. Compared to Order SF,Scan SF changes the type of the parameters in one of the events of Core SF. In particular, in thespecification of Scan SF depicted in Figure 2.12(a), LAC requests not single subsystem actions,but sets of those. The sets of subsystem actions with more than one action represent scans. Thecomposition of Scan SF and Order SF is depicted in Figure 2.12(b). The change of the parametertype in Scan SF (compared to Core SF) requires a different way of using this parameter in thespecification of Order SF (grd5 in Figure 2.12(b)).

This semantic modularity currently cannot be implemented via the composition techniquesof Event-B (without changing/adapting the Event-B specifications of SFs). Instead we weave


MACHINE lace LAC order

SEES lace metamodel order context

VARIABLEScurr job, curr la, wait exe

INVARIANTS



inv3 : wait exe ∈ P(Occurrence)

EVENTS

Initialisation

beginact1 : curr job := ∅act2 : curr la :∈ LogicalActionact3 : wait exe := ∅

end

Event request la =

any la

wheregrd1 : la ∈ LogicalActiongrd2 : curr job = ∅thenact4 : curr job := dom(LALabelDef(la))act5 : curr la := laact6 : wait exe := ran(LAOrderDef(la))

end

Event request ssa =

any occurrence, ssaction

wheregrd3 : occurrence ∈ curr jobgrd4 : occurrence 7→ ssaction ∈ LALabelDef(curr la)grd5 : LAOrderDef(curr la)[{occurrence}] ∩ wait exe = ∅thenact7 : curr job := curr job \ {occurrence}

end

Event execute ssa =

any ssaction, occurrence

wheregrd6 : occurrence 7→ ssaction ∈ LALabelDef(curr la)thenact8 : wait exe := wait exe \ {occurrence}

end

END

Figure 2.11: Event-B machine specifying Order SF for LAC

semantic features together by configuring the generation of Event-B source code in the LACE-to-Event-B model transformation (the self-referential M2M arrow in Figure 2.6).

2.5.2.4 Intersection of two dimensions of modularity

The intersection of the two types of modularity results in eight conceptual machines and fourcomposition schemes: for each semantic feature we specify a conceptual machine of each soft-ware module (LAC and SS) and a scheme of the interaction of LAC with SS. An interaction


MACHINE lace LAC scan...

Event request ssa =

any scan, ssactions

wheregrd1 : curr job 6= ∅grd2 : scan ⊆ curr jobgrd3 : scan ∈ LAScansDef(curr la)grd4 : ssactions = LALabelDef(curr la)[scan]thenact1 : curr job := curr job \ scan

end

...

(a) Event-B machine specifying Scan SF for a LAC

MACHINE lace LAC order scan...

Event request ssa =

any scan, ssactions

wheregrd1 : curr job 6= ∅grd2 : scan ⊆ curr jobgrd3 : scan ∈ LAScansDef(curr la)grd4 : ssactions = LALabelDef(curr la)[scan]grd5 : LAOrderDef(curr la)[scan] ∩

wait exe = ∅thenact1 : curr job := curr job \ scan

end

...

(b) Event-B machine composing Scan SF and Order SF fora LAC

Figure 2.12: Fragments of Event-B machines for Scan SF and for Order SF

scheme determines how the LAC and SS machines are composed together. The examples of twointeraction schemes are depicted in Figure 2.13.

LAC

request_la

SsB

request_ssa

SsC

request_ssa

request_ssa

execute_ssaexecute_ssa

request_SsB request_scanCD

execute_scanCD

SsD

request_ssa

execute_ssa

request_SsC

(a) Core + Scan SFs

LAC

request_la

SsB

request_ssa

SsC

request_ssa

request_ssa

execute_ssaexecute_ssa

request_SsB

request_SsC

notify_ssa_execution

execute_SsBexecute_SsC

(b) Core + Order SFs

Figure 2.13: Architectural composition of Event-B machines for different configurations of se-mantic features

In Figure 2.13, events of the Event-B machines are represented as interaction interfaces (de-picted by lollipops). For example, in Figure 2.13(a) the LAC machine has two events: request_laand request_ssa – for requesting a logical action and for requesting a subsystem action respec-tively. Machines SsB, SsC and SsD are the instantiations of the conceptual machine SS. Thus,all of them have two events: request_ssa and execute_ssa. Different styles of dashed lines depictthe interaction between machines via composition of events. The names of the resulting compos-ite events (interactions) are typeset slanted. For example, in Figure 2.13(a) event request_scanCDis a composition of the request_ssa event of the LAC machine and the request_ssa events of theSsC and SsD machines.

The interaction schemes for the LACE semantic features are specified in the LACE-to-EventB transformation. For example, the interaction scheme for Scan SF that generates a network


depicted in Figure 2.13(a) consists of the following rules:

1. for each subsystem SS, required to execute subsystem actions in the logical actions of theLAC, compose the LAC.request_ssa event with the SS.request_ssa event;

2. for each combination of the subsystems SSs, required to execute scans in the logical actionsof the LAC, compose together the LAC.request_ssa event and the SS.request_ssa eventsof all the subsystems from SSs (see request_scanCD Figure 2.13(a));

3. for the same combinations of the subsystems SSs compose their SS.execute_ssa eventstogether (see execute_scanCD in Figure 2.13(a)).

An Event-B machine that specifies the LACE semantics as a whole is composed of LAC andSS machines, that include Event-B code for all four semantic features, according to the com-positional schemes of all four semantic features. Two dimensions of the modularity presentedabove simplify creation of Event-B components and their validation through the animation, im-proves automatic discharging of proof obligations, and enhances the maintenance of the LACE-to-Event-B model transformation.

2.5.3 Implementation and ResultsThe LACE-to-Event-B transformations, described in Sections 2.5.1 and 2.5.2, were implementedusing the Operational QVT (Query/View/Transformation) language [74] in the Eclipse environ-ment. The input for the transformation is provided directly by the LACE implementation soft-ware, which employs model transformation and code generation techniques in the Borland To-gether environment, and therefore is compatible with EMF (Eclipse Modeling Framework). Asa target metamodel for the transformation we use the Event-B Ecore implementation providedby the EMF framework for Event-B [92]. The LACE-to-Event-B transformation is designed in amodular way, which follows the logic of instantiation and composition techniques as describedin Sections 2.5.1 and 2.5.2.

Table 2.1: Characteristics of the LACE-to-Event-B transformation

Event-B Semantic features core+scan+components core scan order data order+dataMetamodel

context3 constants5 axioms

4 constants8 axioms

5 constants9 axioms

11 constants22 axioms –

Model context 20 constants7 axioms

21 constants8 axioms

23 constants10 axioms

37 constants17 axioms –

LAC machine3 events21 POs40 LOC

3 events23 POs41 LOC



4 events34 POs

105 LOC

SS machine3 events7 POs

40 LOC


3 events7 POs

45 LOC

3 events7 POs

45 LOC


compositionof LAC and SS

machines

10 events70 POs

220 LOC


10 events82 POs

261 LOC

10 events89 POs

258 LOC

30 events491 POs

1184 LOC

Table 2.1 shows the representative characteristics of the transformation: the sizes of the meta-model contexts vs. model contexts and the sizes of the conceptual machines (the LAC and SS

2.6. Visualization of LACE Specifications 29

machines for Core SF, Scan SF, Order SF and Data SF semantic features) vs. composite ma-chines (bottom row).5 The automatically generated Event-B components are shaded. As aninput for the automatic generation (model transformation) we used the LACE program depictedin Figure 2.3. All proof obligations (POs) of the LAC and SS machines are discharged by in-vocation of the automatic provers in Rodin. The proof obligations of the composite machines(bottom row) can be left undischarged, as these are inherited proof obligations of the LAC andSS machines (according to the shared event composition approach [89]). The Event-B machinethat specifies the behavior of the LACE program is located in the bottom right cell of the table.One can observe that this machine is much larger and has much more proof obligations, than theconceptual machines, of which this machine is composed.

2.6 Visualization of LACE SpecificationsIn this section, we study one of the use cases of having a formal specification of the dynamicsemantics of a DSL: understanding the execution (i.e. the dynamic semantics) of DSL programsthrough the animation of their Event-B specifications. This use case is mainly meant for DSLusers (DSL engineers, or domain experts), who apply the DSL to solve various tasks and prob-lems, while having a restricted knowledge of the DSL dynamic semantics (obtained from a userguide or a tutorial). The work, presented in this section and in Section 2.7.1, was (in part) imple-mented by Rimco Boudewijns within his Master project [14] and is published in [97].

2.6.1 Designing LACE VisualizationsIn order to understand how LACE programs are executed, to learn the LACE semantics, and evento debug the programs, we simulate LACE programs using their Event-B specifications. Thesimulation of a LACE program is achieved through the execution of the Event-B specification(generated for this program) in an animation tool, for example in the ProB animator. However,DSL engineers usually do not know the formal notation of Event-B employed by the animationtools. Moreover, they are hardly familiar with the semantics of the DSL as it is specified in Event-B, and thus, have problems connecting Event-B specifications generated from their programs totheir original programs.

For example, Figure 2.14(c) shows a fragment of the screen shot of how the Event-B specifi-cation, which is generated from the LACE program depicted in Figure 2.14(a), is executed in theProB animator. This Event-B specification is composed of the four instances of the same concep-tual machine representing a subsystem (for Laser, Sensor, Handler, and Projector) andof one instance of the LAC machine for Order SF. The events of these instantiated specificationsand their combinations can be seen on the left side of Figure 2.14(c) (see the tab ‘Events’). Thevariables of the instantiated specifications and their values can be seen on the right side of Fig-ure 2.14(c) (see the tab ‘State’). It is hard to trace these events and variables back to the originalLACE program without understanding the conceptual machines and how they are instantiatedand composed.

Consequently, while such a simulation might be useful for a designer who creates Event-Bspecifications of the DSL; one cannot expect engineers, who program using the DSL notation, tobe able to use such a simulation. Therefore, we create a domain-specific visualization for Event-B specifications of LACE. For this we employ BMotion Studio [55], that provides a graphicaleditor for creating such visualizations and uses Event-B notation for specifying various details,

5The size of an Event-B context is represented by the number of its constants and axioms. The size of an Event-Bmachine is represented by the number of its events, proof obligations (POs), and lines of code (LOC).


take_a_snapshot

Laser Sensor Handler Projector

AdjustFrame PositionObject

MoveParking

Switch

ProduceLight GrabAFrame

objectPos

framePos

snapshot

Glass

(a) Original DSL program

(b) Visualized animation in ProB: (1) subsystem buffers, (2) highlightedactions, (3) buttons for executing events

(c) Animation in ProB (running underneath the visualization)

Figure 2.14: An example of the LACE DSL program and its visualized animation in ProB

such as predicate and value expressions.6 As BMotion Studio is integrated into ProB, a visual-

6In this work we use the first version of BMotion Studio. Currently the new version, BMotionWeb, is available.


ization runs together with (or on top of) the ProB animator.A visualization provides a graphical user interface (GUI) for animating an Event-B specifi-

cation. For creating such a GUI, BMotion Studio offers a palette of various graphical elements(shapes, connectors, text fields, buttons, etc.) and two concepts responsible for the animation:controls and observers. Controls are used to execute events of the specification. Observers areused to visualize the current state (i.e. current values of the variables). Below we discuss howsuch a GUI can be designed for a DSL.

The main goal of our DSL visualization is to help a DSL user to grasp how a DSL programis executed. For this, we start from what a user already knows: the DSL concrete syntax. Weadd to it what a user aims to discover: the DSL dynamic semantics. In other words, we base ourvisualization on the graphical syntax of LACE; and we project the concepts of the LACE dynamicsemantics on it. In general, such concepts represent an execution state and operations that canchange this execution state. However, it is not obvious how such concepts can be visualized ontop of the graphical syntax of LACE.

For textual programming languages, such as C or Java, an established way to visualize anexecution state on top of the program text is to highlight the code line that is being executed.Moreover, additional views, such as call stack, memory, variables, etc. allow for inspecting otheraspects of the execution state. The execution of a program is done step by step using variousplay-buttons. This way of visualizing a program execution directly links to the concepts that areusually used in descriptions of the dynamic semantics of such languages: execution of a programline-by-line, function calls, memory management, etc.

However, graphical languages and methods of visualizing their execution are not so estab-lished. An example of a graphical language is considered in [9]. In this work the execution of aUML activity diagram is visualized by projecting its dynamic semantics on the diagram. As thedynamic semantics of UML activity diagrams is described using the concept of token (adoptedfrom Petri nets), the visualization consists of tokens (filled black circles) moving between activ-ity nodes. Thus, the design principle is the same as for textual programming languages: addingthe visualization of (the run-time state of) the dynamic semantics of a language to the concretesyntax of the language.

The dynamic semantics of LACE is defined as a set of Event-B conceptual machines repre-senting architectural components and semantic features of LACE (as described in Section 2.5).Therefore, we visualize these modules and project them on the LACE concrete syntax. By fo-cusing on the visualization of separate modules rather than on the visualization of the dynamicsemantics as a whole, we design our visualization in a modular way. Below we demonstratethis approach on the examples of two modules (introduced in Section 2.5): the subsystem (SS)component and Order SF.

SS component realizes the buffered execution of subsystem actions on a subsystem. An actionis added to the buffer as a result of executing a LACE program, and removed from thebuffer when this action is actually executed by the subsystem. We visualize a buffer foreach subsystem participating in a LACE program as a column showing all elements ofthe buffer (see (1) in Figure 2.14(b)). We position the buffers above the correspondingsubsystems and let them ‘grow’ downwards: a new element is added to the bottom of thecolumn, and all elements are shifted up when an old element is removed. In the screenshot in Figure 2.14(b), the buffers of Laser and Projector are empty, the buffer ofSensor has one element, and the buffer of Handler has two elements.

Order SF represents (models) a mutual dependency between subsystem actions (imposed bythe control flow of a LACE program). Such a dependency influences the throughput of aprogram and combined with a slow execution on a subsystem can cause an (unforeseen)


execution delay. We do not model time in our specification of the dynamic semanticsof LACE, thus, we cannot detect such situations automatically (for example, using modelchecking). To facilitate (manual) detection of such situations, we visualize the partial orderin the interaction with the subsystem buffers (where removing an action from a buffercan model such a slow execution). For this visualization we use color highlighting ((2)in Figure 2.14(b)): red rectangles highlight subsystem actions that are blocked from theexecution, and green rectangles highlight subsystem actions that are being executed (i.e.are situated at the front/top of the corresponding buffers).

To be able to execute the underlying Event-B specification of a LACE program we use buttonsintegrated into its visualization ((3) in Figure 2.14(b)). Such buttons get enabled and disabledbased on the current state of the execution, letting a DSL user study the DSL semantics. Eachbutton is attached to a graphical element of the LACE program in such a way that the user canintuitively associate the enabled or disabled behavior with the corresponding construct of LACE.For example, each subsystem in Figure 2.14(b) has two corresponding buttons attached to itsgraphical representation (column): "Request SS action" (for adding an action to the buffer) and"Execute next SS action" (for removing an action from the buffer).

2.6.2 Generating LACE VisualizationsThe resulting visualization mimics an (arbitrary) LACE program, and thus, needs to be con-structed for each concrete LACE program. To make such a visualization design feasible, weautomate the construction of LACE visualizations using a model-to-model transformation fromLACE to BMotion Studio. The transformation automatically derives graphical elements andtheir layout from an original DSL program and generates the corresponding observers (buttons),controls (shapes, labels, and their attributes), and the layout of a visualization. For example,the BMotion Studio visualization depicted in Figure 2.14(b) is automatically generated from theLACE program depicted in Figure 2.14(a). Moreover, the LACE-to-BMS transformation con-nects elements of the visualization with elements of the underlying Event-B specification (alsogenerated from the LACE program, as described in Section 2.5).

A BMotion Studio visualization runs on top of an Event-B specification. This means thatcontrols and observers of the visualization query variables and events of the underlying Event-Bspecification. As the visualization design is determined (shaped) by the concrete syntax ratherthan by the dynamic semantics of the DSL, querying data from the Event-B specification requiresrather non-trivial predicate and value expressions.

For example, to realize highlighting of subsystem actions in green and red (as depicted inFigure 2.14(b)), we need to specify two observers for each subsystem action of a LACE diagram.Figure 2.15 shows the BMotion Studio wizard configuring such observers: an observer sets thebackground color to red or green when the corresponding predicate is true. The predicates checkthe mutual dependency between subsystem actions and the execution state of the correspondingsubsystem buffer. Obviously, writing such predicates manually for all subsystem actions of theLACE program is quite tedious.

Buttons (controls) do not map one-to-one on the events either. As described above, to makethe semantics of buttons intuitively clear to DSL users, we attach them to the graphical elementsof a LACE diagram. For example, in Figure 2.14(b) there are eight buttons attached to the foursubsystem columns, and thus, representing the behavior of each of the subsystems. However,according to the interaction scheme of Scan SF, such a behavior of a subsystem can be executedin multiple events and in combination with the same behavior of another subsystem. For exam-ple, in Figure 2.14(c) "request_ssa_ss1" appears four times in different combinations with other


Figure 2.15: Screen shot of the BMotion Studio wizard for configuring an observer

subsystems ("ss2" and "ss3"). This means, that a subsystem button should be able to triggerdifferent events depending on the current execution state, and moreover, some of these eventsshould be triggered by a combination of multiple subsystem buttons. In other words, we need toimplement a many-to-many relation between buttons and events.

The LACE-to-BMS transformation overcomes these technical challenges by specifying themapping between the concrete syntax (shaping the visualization) and the dynamic semantics(driving the visualization) on the level of the LACE metamodel. Thus, all predicate and valueexpressions and many-to-many relations between elements of the visualization and elements ofthe Event-B specification are generated automatically for each concrete LACE program.

The scheme of the LACE-to-BMS transformation is depicted in Figure 2.16. Within theLACE development environment, a graphical LACE program is parsed into the correspondingLACE model. This model is used as an input for the LACE-to-Event-B transformation describedin Section 2.5 (the right part of Figure 2.16). Besides a LACE model, the LACE-to-Event-B transformation takes as an input a set of LACE conceptual machines. As an output, thistransformation generates an Event-B specification of the LACE program (bottom right cornerof Figure 2.16) and the corresponding mapping information. The latter is in fact the log of atransformation execution and captures the links between the elements of the resulting Event-B specification and of the original LACE model. The mapping information is necessary forconnecting LACE visualizations with the underlying Event-B specifications.

LACEprogram

LACEmodel

Intermediatevisualization

model

B-Motion Studiovisualization

Event-Bspecification

LACE conceptual machine

mappinginformation

transformation

dependency

parse

uses

uses LACE-to-Event-B

LAC

E-t

o-B

MS

LACE syntax

LACE semantics

(1)

(2)

Figure 2.16: Transformations from LACE to Event-B and BMotion Studio

A LACE visualization is generated from the original graphical LACE program (the left part ofFigure 2.16), as the essential model abstracts from (thus, leaves out) the notational details of theLACE diagram. The LACE-to-BMS transformation uses an intermediate visualization model,


which splits the transformation into two separate steps. The first step captures the graphicaldesign of the visualization, i.e. the graphical elements and their layout. The second step takescare of the mapping between Event-B events and variables and BMotion Studio observers andcontrols. For example, in the second step of the transformation concrete elements of the Event-B specification are substituted into predicates of the observers and controls. In this way wemodularize the transformation and decouple the DSL from the visualization platform, allowingfor potential reuse of our approach for employing other visualization platforms.

2.7 User StudyEarlier in Section 2.3 we introduced the user roles and the (potential) use cases of constructingand analyzing an Event-B specification of the dynamic semantics of LACE. Below we elaborateon the (actual) experience of these two user roles with our Event-B specification of LACE. InSection 2.7.1 we describe the user study that we performed with end-users of LACE. In Sec-tion 2.7.2 we discuss an interesting insight that we got from one of the developers of LACE.

2.7.1 Interviews with LACE End-UsersTo validate the visualization design and to discover use cases for its application, we performed auser study among LACE end-users (ASML engineers who develop software using LACE). Theuser study consisted of interviews (with an engineer) and of brainstorming sessions (with fewengineers at once). During such an interview or a brainstorming session, we would demonstrateour LACE visualization by animating five existing LACE programs and then collect the feedbackusing the questionnaire form and personal communication. Ten ASML engineers participated inthe user study. Note that as LACE is a programming language specialized to a specific domain,the community of LACE users is not big. We estimate that the response rate for our user studywas 50%. The participants had different levels of expertise in LACE and were from variousapplication and/or system subdomains.

During the user study we were aiming to achieve the following goals:

• to validate our rationale for designing a DSL visualization;

• to assess how well the level of details is balanced;

• to discover opportunities for applying the visualization in the development process.

Using the GQM (Goal, Question, Metric) method [93], we refine these goals to a more oper-ational level as a set of questions which we need to answer in order to draw conclusions from theresults of the user study. Such questions allow for interpreting the data collected during the study.In Table 2.2 these study questions are shown in the second column next to the goals that theyrefine. The questions that were asked to the LACE end-users correspond to the Metric categoryof the GQM method. We show (examples of) these end-user questions in the third column of Ta-ble 2.2. The corresponding feedback of the users is presented in the rightmost column. Most ofthe questions in our questionnaire form were closed questions with a grade in the interval [0..4]to indicate the certainty and/or relevance of an answer. In Table 2.2 we indicate the mean valueof the answers, given by the respondents to the corresponding question. The detailed descriptionof the questionnaire and the collected answers can be found in [14].

2.7.U

serStudy35

Table 2.2: The structure and the results of the user study

Goals Questions (subgoals) Metrics (questions asked to the end-users) Outcome/feedback

Validate Design is intuitive and understandable Do you understand the visualization of the LACE model? yes (3.3 out of 4)the visualization Observers represent the execution state Is the visualization intuitive to find the desired information? yes (2.9 out of 4)design Semantics of controls (buttons) is clear Is the visualization intuitive to execute the desired actions? yes (2.9 out of 4)

Choice of the semantics concepts What part of LACE should be visualized? two moreconcepts wereproposed

Assess the level Overview of an animated diagram Are you happy with the level of details? rather no than yes(1.8 out of 4)

of the details Insights provided by the visualization Is highlighting of blocked and queued actions helpful? yes (3 out of 4)Do queues help to see which actions need to be executed? yes (3 out of 4)

Insights missing in the visualization Would you find a log of all processed SS actions helpful? rather yes than no(2.6 out of 4)

Would you find the visualization of the data values helpful? indifferent(2.1 out of 4)

Discover There is a lack of support for Did you have problems learning LACE? four people – yesopportunities understanding the LACE semantics Do you still have problems understanding some LACE models? mostly not,

one person – yesfor applying The visualization can close this gap Would this visualization help understanding those models? yes (2.9 out of 4)the visualization How much time would this kind of visualization save you? 15-20%

What are potential use case scenarios? How would you apply the visualization in practice? Prototyping andvalidation,impact analysis,replay ofexecution logsand predefinedsequences


Based on the results of the user study presented in Table 2.2 and on other feedback of theLACE users, we draw the following conclusions.

• The visualization design is in general acceptable. Using the feedback provided by theLACE users, it is possible to make the visualization design more intuitive and user-friendly.However, such a fine tuning is beyond the scope of our work.

• The approach would benefit from the possibility to configure the level of details of theLACE visualization. For example, a LACE user might want to specify which elementsof a LACE program (and/or which semantic features of the dynamic semantics of LACE)should appear in the visualization. This can be achieved through an explicit configurationof the LACE-to-BMS model transformation.

• The LACE users believe that they can use the visualization for understanding and test-ing behavior of their LACE programs; for replaying real-life system executions; and forchecking changes after LACE gets updated (impact analysis).

Moreover, according to the LACE end-users, a crucial requirement of the proposed approachis that the DSL formal specification should be consistent with the actual implementation of theDSL. Without this consistency DSL end-users cannot benefit from the visualized animation ofDSL specifications. In the next section we describe an example of such consistency.

2.7.2 The True Face of LACELACE is implemented as a chain of model transformations and code generations, targeting anexecution platform that wraps the lower level components (such as hardware drivers, buses, etc.).In Figure 2.4 we denoted this execution platform as Synchronization driver. The interface pro-vided by this execution platform is relatively limited. As a result, the translation of LACE to theexecution platform (i.e. the implementation of LACE) does not follow an optimal and the mostsensible design. It turns out that this results in differences between our formal specification ofthe dynamic semantics of LACE and the actual implementation of LACE.

For example, Scan SF is implemented in the same way as we specify it in Event-B. That is,each logical action consists of intermediate constructs (so-called physical actions), which canconsist of one or multiple subsystem actions. This corresponds to our way of specifying scans assubsets of SSAction constituting a LogicalAction.

However, Order SF is implemented in a different way. In our Event-B specification, wedefine Order SF as a partial order on the occurrences of subsystem actions of a logical action(see Figure 2.7(a)). A next subsystem action cannot be requested by LAC if it (its occurrence)precedes a subsystem that has not been executed yet (see Figure 2.11). This design is not possibleto implement using the interface provided by the target execution platform of LACE. Therefore,we modified the specification of Order SF so that it adheres to its actual implementation in LACE:see Figures 2.17 and 2.18.

In LACE Order SF is implemented using a combination of the following two mechanisms.

• A (linear) order of the (occurrences of) subsystem actions within a logical action deter-mines in which order these subsystem actions should be requested for the execution bythe LAC component. The corresponding relation ocrRequestOrder is introduced in themetamodel context in Figure 2.17(a) and is instantiated for the example LACE program inFigure 2.17(b). The guard grd7 of the event request_ssa in Figure 2.18 ensures that therequested subsystem action (ssaction) has the smallest numerical order (ocr_order) amongall the subsystem actions that still need to be requested (curr_job ).

2.7. User Study 37

CONTEXT lace metamodel order context

EXTENDS lace metamodel core context

CONSTANTSocrRequestOrder, ocrWaitForResult

AXIOMS

axm3 : ocrRequestOrder ∈ LogicalAction→ (Occurrence 7→ N)axm4 : ocrWaitForResult ∈ LogicalAction→ P(Occurrence)

END

(a) Metamodel context

CONTEXT takeasnapshot model order context

EXTENDS takeasnapshot model core context

CONSTANTSocrRequestOrder, ocrWaitForResult

AXIOMS

axm1 : partition(ocrRequestOrder, {laTAS 7→ {o1 7→ 4, o2 7→ 1, o3 7→ 3, o4 7→ 2, o5 7→ 6, o6 7→ 5}})axm2 : partition(ocrWaitForResult, {laTAS 7→ {o1, o4, o6}})END

(b) Model context

Figure 2.17: Contexts of the Event-B specification for the implementation of Order SF

• A subset of the (occurrences of) subsystem actions within a logical action determineswhich subsystem action blocks processing of the logical action. In other words, no othersubsystem action can be requested until these subsystem actions have been executed. Wemodel such subsets as the relation ocrWaitForResult (see Figure 2.17(a) and the examplein Figure 2.17(b)). The corresponding behavior is specified in the event request_ssa inFigure 2.18 using the wait_exe variable: if the subsystem action being requested belongsto the blocking subset of the logical action (ocrWaitForResult(curr_la) ), then it is includedinto the wait_exe variable (act7 ). No other subsystem action can be requested until thewait_exe variable is empty (grd5 ). The emptying of the latter happens in the event exe-cute_ssa (act8 ).

The two Event-B specifications of Order SF presented in Figure 2.11 and in Figure 2.18 arejust two possible solutions out of many possible. Moreover, we do not discuss the fact, that thelatter specification might fail to realize the desired behavior (for example if PositionObjectis executed earlier than AdjustFrame, then the scan ProduceLight/GrabAFrame can bealready requested, which might result in the violation of the execution order). The focus hereis on the question, what solution (or design) out of many possible solutions (designs) should bespecified. According to the LACE developer and LACE end-users, whom we have interviewed,the specification should follow the actual implementation of the DSL. Then DSL developers candiscover problems in their implementation, and DSL users can get aware of potential problemsand develop their DSL programs correspondingly.


MACHINE lace LAC order

SEES lace metamodel core context, lace metamodel order context

VARIABLEScurr job, curr la, wait exe

INVARIANTS



inv3 : wait exe ∈ P(Occurrence)

EVENTS

Initialisation

beginact1 : curr job := ∅act2 : curr la :∈ LogicalActionact3 : wait exe := ∅

end

Event request la =

any la

wheregrd1 : la ∈ LogicalActiongrd2 : curr job = ∅thenact4 : curr job := dom(LALabelDef(la))act5 : curr la := la

end

Event request ssa =

any occurrence, ssaction, ocr order

wheregrd3 : occurrence ∈ curr jobgrd4 : occurrence 7→ ssaction ∈ LALabelDef(curr la)grd5 : wait exe = ∅grd6 : occurrence 7→ ocr order ∈ ocrRequestOrder(curr la)grd7 : ∀oc·oc ∈ curr job ∧ oc ∈ dom(ocrRequestOrder(curr la))

⇒ ocrRequestOrder(curr la)(oc) ≥ ocr orderthenact6 : curr job := curr job \ {occurrence}act7 : wait exe := ocrWaitForResult(curr la) ∩ {occurrence}

end

Event execute ssa =

any ssaction, occurrence

wheregrd8 : occurrence 7→ ssaction ∈ LALabelDef(curr la)thenact8 : wait exe := wait exe \ {occurrence}

end

END

Figure 2.18: Event-B machine specifying the implementation of Order SF for LAC

2.8 Related Work

2.8.1 Modular Specification of the Dynamic Semantics of a DSLThere exist a number of studies in which Event-B is applied to specify the dynamic seman-tics of a DSL. Aït-Sadoune and Aït-Ameur employ Event-B and Rodin for proving properties

2.8. Related Work 39

and animation of BPEL processes [6]. Hoang et al. use Event-B and Rodin to automate anal-ysis of Shadow models [37]. In both studies, DSL program descriptions are translated intoEvent-B specifications. The translations are implemented in the Java programming language.These works do not use generic instantiation and composition techniques, but apply refinementof Event-B machines [4] to implement modularity of the programs. Based on our experience,refinement restricts semantics definitions and can be rather complicated for automatic proving.Moreover, we use model transformations to implement the generation of Event-B specifications,which increases the abstraction level of the LACE-to-Event-B translation.

In [105] van Gool et al. describe a DSL that is a prototype of LACE. The authors definethe dynamic semantics of this DSL through the model transformation from a PIM (platform-independent model) to a PSM (platform-specific model). The PIM consists of the LACE(-like)constructs, such as abstract behaviors (i.e. logical actions), concurrent and sequential execu-tion of resource behaviors (i.e. subsystem actions), passive behavior (we did not include thisconstruct into our specification), and assigning values to variables (i.e. data flow). The PSM isrepresented by the scheduling component, which executes abstract behaviors (i.e. logical actions)in an optimal manner by determining what and when resources (i.e. subsystems) are needed forthe execution. The PSM that is used by van Gool et al. is of higher abstraction level than thetarget execution platform that we considered in our specification of LACE. The model transfor-mation from the PIM to the PSM is described in [105] schematically as a set of transformationrules, one for each DSL construct. Thus, their definition of the dynamic semantics follows thesemantic modularity of the DSL. In contrast to our specification of LACE semantic features, theirsemantic modules (defined in separate transformation rules) do not influence each other, i.e. canbe clearly separated from each other. This might be due to the higher abstraction level of theirtarget execution platform.

2.8.2 Domain-Specific Visualization of Formal SpecificationsThere exist various approaches for visualizing a formal specification and its execution (anima-tion). It can be a visualization of a state space, or wrapping a formalism into the (standard)graphical notation of UML (such as [91]). In our work we focus on a domain-specific visualiza-tion – on a graphical representation tailored for a specific (engineering or application) domain. Anumber of case studies have demonstrated that a domain-specific visualization of a formal spec-ification can be very useful for creating, validating, and applying the specification by humans,especially by domain experts. For example, in [35] Hansen et al. state that a graphical repre-sentation of their Event-B specification of a landing gear system was crucial for its developmentand validation. In [65] Mathijssen and Pretorius use a visualization of their mCRL2 specificationof an automated parking garage to discover and fix a number of bugs in the specification. Theyconclude that compared to the standard simulation of mCRL2, the visualization projected on thetop of this simulation is more intuitively clear and easy to understand, and thus, helps to identifyissues that may not have been noted otherwise.

In [95] Stappers specifies the behavior of an industrial wafer handler using mCRL2, obtainsa trace to a deadlock state using the mCRL2 toolset, and visualizes this trace using a CAD(Computer Aided Design) model of the wafer handler in a kinematic 3D visualizer. In otherwords, the visualization animates the 3D virtual model of the physical system by moving itsparts along the predefined motion paths. As a result, engineers of the wafer handler can identifythe problem that leads to the deadlock state and find a proper solution. Stappers presents hisapproach from a general point of view, describing the components that are required to realizesuch a visualization and their architecture. For our work we draw inspiration from his motivationon how system development can benefit from formal specifications and their visualization, and


from his overview of how various technological fields connect and interact with each other inorder to achieve these benefits.

While most of the domain-specific visualizations are implemented in an ad-hoc way (for ex-ample, a traffic light system presented in [66] is visualized in a prototype simulator developed inJava specifically for this case study); recent developments facilitate the creation of visualizationsusing dedicated graphical editors integrated with a formalism toolset. For instance, in BMotionStudio [55] one can create an interactive domain-specific visualization for a (single) B or Event-Bspecification. BMotion Studio has been successfully applied to a number of case studies (see forexample [35] and [56]). In our work we lift this successful tool support to the level of DSLs, au-tomating the creation of BMotion Studio visualizations for multiple (or for a family of) Event-Bspecifications.

To date, there is a lack of tool support for understanding and debugging an executable DSL onthe level of its domain rather than on the level of its target execution platform (such as generatedC or Java code). One of the early studies that recognize and address this problem is presentedin [104]. In this work Olivier et al. describe TIDE, a framework that allows for instantiating a setof generic debugging facilities (such as stepping through the program and setting breakpoints)for an arbitrary DSL based on its formal specification in ASF+SDF. More specialized behavior,such as language specific visualizations, require extending the implementation of TIDE in Java.

In [17] Chis et al. propose the Moldable Debugger framework for developing domain-specificdebuggers. The Moldable Debugger allows for configuring a domain-specific debugging viewas a collection of graphical widgets, such as stack, code editor, and object inspector. In order tovisualize the execution of a DSL program in such widgets, a DSL developer needs to specify so-called debugging predicates (capturing an execution state) and debugging operations (controllingthe execution of a program). To realize this approach, the Moldable Debugger builds on top of,and extends an existing IDE (integrated development environment). In our work we build on topof formal methods, making use of the DSL formal specification. Moreover, we discuss how todesign the visualization of a DSL program (i.e. domain-specific graphical widgets) based on anexplicit definition of the DSL dynamic semantics.

In [9] Bandener et al. visualize behavior of a graphical language in the form of the animatedconcrete syntax using the Dynamic Meta Modeling (DMM) technique. In DMM, a so-calledruntime metamodel enhances the language metamodel with concepts that express an executionstate. The dynamic semantics of the language is specified as a set of graph transformation rulesfor deriving instances of the runtime metamodel. When applied to a program (i.e. instance of thelanguage metamodel), these rules iteratively generate a state space representing the behavior ofthe given program. Each of these states is an instance of the runtime metamodel. Bandener et al.enhance the language’s concrete syntax with the graphical representation of the runtime meta-model. As a result, a graphical representation (i.e. a diagram) can be generated for each state ofthe state space. Their front-end tool allows for choosing a path in such a visualized state space.In our work we also strive for the effect of the animated concrete syntax of the DSL.

2.9 ConclusionsIn this chapter we described our case study on defining the dynamic semantics of the LACEDSL. In our case study, we investigated the definition of the dynamic semantics of LACE fromthe viewpoints of two user roles: a DSL developer and a DSL user. These two different user rolescan both benefit from constructing and/or having a formal specification of the dynamic semanticsof LACE, but in different ways (i.e. different use cases). DSL developers benefit from the explicitspecification of their design of the DSL and from the possibility to analyze its consistency and

2.9. Conclusions 41

check various properties. DSL users benefit from the animation of DSL programs wrapped into adomain specific visualization. Moreover, two different user roles work with the different (meta-)levels of the DSL: the DSL metamodel and a DSL model. Thus, the corresponding use cases areapplied to two different types of specifications: a specification of the dynamic semantics of theDSL on the metamodel level, and a specification of the behavior of a DSL program on the modellevel. Construction, analysis, and maintenance of these two different types of specificationsare realized using different technologies (such as modular specification of LACE in conceptualmachines and model transformation that generates composite machines from LACE models).

Our experience of applying Event-B to the specification of LACE and developing the LACE-to-Event-B model transformation leads to the following observations. The level of the statemachines based formalism (such as Event-B) for the specification of the dynamic semantics of aDSL is rather low (even on the high abstraction level that captures only essential details): writingthe specification code and ensuring its coherency can be tedious work that requires precision ina lot of small details and copy-pasting of reappearing common solutions. The process and theresult of the formal specification of the dynamic semantics of a DSL can be improved using amodular approach. We identified two dimensions of the modularity in our DSL: architecturaland semantic. However, in our solution the composition of the specification modules is hard-coded into the DSL specific (LACE-to-Event-B) model transformation. The semantic mappingof LACE hard-coded into the model transformation limits the flexibility of the formalization,complicates the maintenance and understandability of the definition of the dynamic semanticsof LACE. Moreover, the model transformation maps various small details of the metamodel ofLACE to the Event-B specification of LACE. This complicates the reuse of our implementationfor the definition of the dynamic semantics of new versions (evolution) of LACE.

In relation to the notion of the dynamic semantics of a DSL as it is introduced in Section 2.1,the specification of LACE in Event-B consists of the following semantic domain(s) and semanticmapping(s). Conceptual machines of the LACE specification introduce an intermediate semanticdomain, which consists of architectural modules and semantic features. The specification of thesemachines in Event-B represents a semantic mapping from the intermediate semantic domain toEvent-B (i.e. the back-end formalism). The LACE-to-Event-B model transformation representsa semantic mapping from LACE to the intermediate semantic domain. Thus, our definition ofthe dynamic semantics of LACE is realized through a two-steps semantic mapping. In this waywe can effectively deal with the low abstraction level of the back-end formalism.

The nature of the intermediate semantic domain, that we used in our definition of the dy-namic semantics of LACE, is determined by the ‘domain specificity’ of the DSL, in particular,by one of its two roles (as explained below). On the one hand, a DSL captures domain knowl-edge, which supports its reuse via domain notions and notation and raises the abstraction levelof solving problems in a particular domain. In other words, the DSL realizes a so-called verti-cal domain [51]. On the other hand, the implementation of the DSL (such as its translation tothe source code, or via interpretation) captures software solutions (algorithms, architecture, andtechniques) that are commonly used in the domain, which supports their reuse and, thus, raisesthe efficiency of the software development process. In this way, the DSL realizes a so-calledhorizontal domain [51]. We observed that when specifying the dynamic semantics of LACE, wewere identifying and (re)using such horizontal concepts of LACE: partial order and linear order,multi-layered architecture, request-notify mechanism, FIFO.

Based on the conclusions described above, we formulate the following requirements for aformalism and a suite of tools for defining the dynamic semantics of a DSL.

Req-1 A definition of the dynamic semantics of a DSL should allow for the implementation ofvarious use cases, such as verification and validation of the DSL design, and simulation


of DSL programs.

Req-2 A definition of the dynamic semantics of a DSL should describe how DSL programs areexecuted on a (real) machine (according to the actual implementation of the DSL), ratherthan how DSL programs are expected to behave (according to the user guide or otherinformal description of the DSL).

Req-3 The definition formalism should provide DSL-independent means for specifying the dy-namic semantics of a DSL on the metamodel level (in terms of the DSL metamodel).

Req-4 The definition formalism should allow for the introduction and invocation of an additional(new) semantic domain, such as an intermediate semantic domain that uses concepts ofhigher abstraction level (comparing to the existing semantic domain). For example, itshould be possible to use concepts of the DSL horizontal domain.

Req-5 The definition formalism should support different types of modularity of the dynamicsemantics of a DSL, such as architectural modules and semantic features.

Req-6 The definition formalism should support a clear description of the DSL design, that is theinteraction between and/or composition of separate modules of the dynamic semanticsshould be described in a clear and explicit way.

Req-7 Formal specifications of DSL programs should be generated automatically on the modellevel. The automatic generator should be DSL-independent and configured according thedefinition of the dynamic semantics of a DSL that has been constructed on the metamodellevel.

Note that these requirements are orthogonal to the research (design) questions that determineand guide our study. The formulated above list of the requirements is in itself an answer to oneof the research questions (formulated in the introduction of this chapter). The list of explicitlyidentified requirements gives a pragmatic focus to the other research questions that we considerfurther in this work.

Chapter 3

The Grand Vision

"We create a general theory of the slaying of electrodragons, of which thelunar dragon will be a special case, its solution trivial." "Well, create such atheory!" said the King. "To do this I must first create various experimentaldragons." "Certainly not! No thank you!" exclaimed the King. "A dragonwants to deprive me of my throne, just think what might happen if youproduced a swarm of them!"

Stanislaw Lem, The Tale of Machine that Fought a Dragon

In this chapter we outline our vision on how our research fits into the perspective of the DSL-based development approach, its challenges and potentials. First we describe the technologyspace of the DSL-based development approach by aligning the formalisms, tools, and platformsthat support the development and usage of DSLs (Section 3.1). Then we use the terms of thistechnology space to introduce a Common Reference Framework (COREF) – a framework fordefining, developing, and using DSLs. The aim of this framework is not to introduce new for-malisms and tools, but rather to bridge existing formalisms and tools.

Based on the high-level discussion of our experience of the LACE case study, we introducethe idea of structural and semantic templates and describe our vision on how such templates canbe used for achieving the goals of COREF (Sections 3.2 and 3.3). On the one hand, structuraland semantic templates can be used for defining a DSL on a higher abstraction level, supportingreuse of the DSL definitions. On the other hand, structural and semantic templates can bridge theformalisms and tools (of the technology space), facilitating the correspondence between them.

Our research on defining the dynamic semantics of DSLs is performed within COREF andrealizes a part of the proposed generic framework. In particular, in the rest of the thesis, weelaborate on the idea of semantic templates and how they can be applied to a definition of thedynamic semantics of DSLs.

44 The Grand Vision

3.1 The Technology SpaceFigure 3.1 depicts an (approximate) technology space common for the DSL-based developmentapproach. We organize this technology space along the following two dimensions: MOF meta-levels (vertical axis) and different technologies/platforms (horizontal axis). MOF consists offour layers: the top layer M3 provides a meta-metamodel (or meta-language) for defining DSLs;on the M2 layer DSLs are defined and developed; on the M1 layer DSLs are used, i.e. DSLprograms are specified; on the M0 layer DSL programs are executed. In Figure 3.1 we do notdepict the conformance relationships between the models of different MOF layers in order tonot overly complicate the picture. However, we imply that each model conforms to the modelfrom the same column from the layer above. For example, a DSL metamodel conforms to theMeta-metamodel (Ecore); a DSL model conforms to the DSL metamodel; etc.

DSLprogram

DSLmodel

DSLconcrete syntax

DSLmetamodel

parse

Meta-metamodel(Ecore)

modelimplementation

modelspecification

modelvisualization

programexecution

modelanimation

DSL formalspecification

C++/Java

M3

M2

M1

M0

Textual/graphical notation

EMF (MDE) C++, Java, etc.(GPL source code)

Event-B(formal methods)

BMotion Studio(debugging GUI)

M2Mgeneratecode

uses

Event-Bmetamodel

uses

reference

translation (DSL-specific)

translation, automated via the corresponding reference

Figure 3.1: Technology space for the DSL based development approach

We consider the technologies/platforms that support the development and usage of DSLs. Forexample, EMF (Eclipse Modeling Framework) realizes the principles of the MDE approach byproviding the means for metamodeling a DSL (i.e. defining the DSL metamodel as an instance ofthe Ecore meta-metamodel) and for specifying DSL models as instances of the DSL metamodel.A DSL model cannot be executed by means of the EMF tool set (in Figure 3.1 the correspondingsquare is empty). The common approach is to generate GPL source code from a DSL model(model implementation in Figure 3.1) and run this code using the corresponding compiler and/orinterpreter (program execution in Figure 3.1). The code generation is usually developed for eachseparate DSL (i.e. it is DSL-specific).

The same scheme applies to our specification of the LACE DSL in Event-B, described inChapter 2. The model transformation (M2M in Figure 3.1) from a DSL model to the corre-sponding model specification has been developed particularly for the LACE DSL, and, as it is,cannot be applied to another DSL. The LACE-to-Event-B transformation composes a LACEmodel specification out of the conceptual machines of the DSL formal specification, and in this

3.2. Defining the Structure of a DSL 45

way instantiates the latter. On the M0 layer such a model specification can be animated using theRodin tool set. A model visualization is generated from the graphical representation of the DSLmodel (DSL program in the left-most column) and runs on top of (wraps) the animation.

Note, that formally speaking, the Event-B column in Figure 3.1 should take three cells insteadof four: the Event-B metamodel is an instance of Ecore, i.e. a M2-model. Moreover, in the contextof the Event-B language, the DSL formal specification and a model specification are both Event-B specifications (i.e. M1-models). We organize this column differently in order to align ourEvent-B specifications with the DSL meta-levels. In particular, in this way we stress the fact thatLACE conceptual machines (forming the DSL formal specification for LACE) are constructed onthe meta-model level (i.e. in terms of the LACE meta-model); and LACE composite machines(model specifications) are generated on the model level for concrete LACE models.

In Figure 3.1 we depict the DSL-specific translations as white (hollow) arrows. In contrast,hatched (dashed) arrows show the DSL-independent translations, such as parsing a DSL programinto a DSL model. A DSL parser is generated automatically based on the definition of the DSLconcrete syntax (the DSL grammar) and the definition of how this concrete syntax uses (mapsto) the DSL metamodel (the DSL abstract syntax), i.e. how elements of the concrete syntaxcorrespond to the elements of the DSL metamodel. The mapping between the DSL concretesyntax and the DSL metamodel is described by means of the corresponding meta-language (notshown in Figure 3.1), which are the same for (generic throughout) different DSLs. The examplesof such meta-languages are Xtext grammars for defining textual syntaxes1 and Sirius editors forcreating graphical syntaxes2.

Thus, in parsing, a DSL-independent meta-language (from M3) allows for configuring vari-ous DSL-specific translations (in terms of M2), which are then applied to DSL models (on M1).This approach has two important benefits. First, this approach (together with the supportingmeta-language) is reusable for many DSLs. Second, the mapping between a DSL concrete syn-tax and a DSL metamodel is described explicitly (whereas in DSL-specific translations it is hard-coded in a translation).

The various translations discussed above (code generation, parsing, model transformation)realize the bridges between the technological platforms. We observe that most of the bridgesare defined in a DSL-specific manner, i.e. for each particular DSL. The goal of the CommonReference Framework (COREF) is to generalize such bridges by making them reusable for manyDSLs, trying to achieve the same generic solution as there exists for parsing. Below we discusshow this goal can be achieved by giving an explicit high-level definition of a DSL, in particularthe high-level definition of its two components: the structure and the dynamic semantics.

3.2 Defining the Structure of a DSLThe structure of a DSL captures language constructs, their compositional hierarchy, their classi-fication (or taxonomy), and cross-references between them. The structure of a DSL is a centralpoint of the DSL design and development. Therefore, its specification appears in some form inall platforms of the technology space depicted in Figure 3.1. Following the experience of ourcase study, we discuss here the following two platforms: EMF and Event-B.

In our case study we bridged these two platforms via the LACE-to-Event-B model transfor-mation that generates Event-B contexts from a concrete LACE model. The input of this transfor-mation is the LACE structure captured through Ecore constructs. The output of the transforma-tion is the LACE structure captured through set theory and first-order predicates. The mapping

1http://www.eclipse.org/Xtext/2http://www.eclipse.org/sirius/

http://www.eclipse.org/Xtext/

http://www.eclipse.org/sirius/

46 The Grand Vision

realized by the LACE-to-Event-B transformation is quite fine-grained and very LACE-specific:it maps small details from an input model to small details of an output specification accordingto the way the LACE structure is specified (modeled) in Ecore and in Event-B. Reimplementingsuch a transformation for another DSL is tedious work, that requires expertise in both formalisms(Ecore and Event-B) and in the DSL under construction. The aim of COREF is to facilitate thiswork by generalizing the LACE-to-Event-B transformation and bridging the Ecore and Event-Bformalisms on the higher abstraction level (in the DSL-independent way).

When specifying LACE in Event-B, we noticed that we first describe the structure of LACEusing coarse-grained (informal) statements, such as ‘a logical action consists of subsystem ac-tion occurrences’, ‘occurrences are partially ordered’, etc. As a second step, we translate each ofthese statements into a piece of Event-B code and/or into a fragment of the Ecore model. More-over, in this translation we establish and reapply certain Ecore and Event-B constructions thatcapture typical phrases reappearing in the coarse-grained statements. For example, after we havespecified ‘a logical action consists of subsystem action occurrences’, we reuse the same Ecoreand Event-B constructions for specifying the ‘consists of’ phrase appearing in the statement ‘alogical action consists of data nodes’. In case the Ecore model (the DSL metamodel) alreadyexists, we do not need to translate the coarse-grained statements into the Ecore model, but werather need to decipher the existing Ecore model into a set of such statements (i.e. to performreverse engineering).

The observation that we reuse the same Ecore and Event-B constructions gave us the ideaof structural templates. Such structural templates can represent constructs (re)appearing in acoarse-grained description of the DSL structure. Typical examples of structural templates are‘A consists of B’, ‘partial order on A’, ‘A relates to B’. Each of these structural templates has acorresponding representation (implementation) in Event-B and in Ecore (see Figure 3.2, the toplayer), and thus, bridges these two platforms. Figure 3.2 depicts our vision on how structuraltemplates can be used for bridging Ecore and Event-B.

DSLprogram

DSLmodel

DSLconcrete syntax

DSLmetamodel

parse modelspecification

M2

M1

Textual/graphical notation

EMF (MDE) COREF Event-B(formal methods)

uses

referencetranslation, automated via the corresponding reference


metamodeltemplates

Event-Btemplates

DSL structuraldefinition

structuraltemplates

structureinstantiation

Figure 3.2: Structural templates for bridging EMF and Event-B

As each structural template is implemented both in Ecore and Event-B, a DSL structural defi-nition composed of such structural templates can be used as a source for the automatic generationof the DSL metamodel in Ecore and the DSL formal specification in Event-B (M2 layer in Fig-ure 3.2). That is, we do not create a DSL metamodel in Ecore, but we generate it automaticallyfrom the DSL structural definition using the library of metamodel templates (the top layer in Fig-

3.3. Defining the Dynamic Semantics of a DSL 47

ure 3.2). The corresponding DSL formal specification is generated using the library of Event-Btemplates.

On the M1 level, the translation from EMF to COREF can be used to trace how the DSL struc-ture is instantiated in a particular DSL model. The resulting structure instantiation can be used forconstructing the corresponding model specification in Event-B. Thus, the DSL structural definitionconfigures the translation from DSL models to the corresponding Event-B specifications.

The feasibility of the approach depicted in Figure 3.2 and its applicability to various DSLsare not self-evident and require further investigation. Within the COREF project, the first stepof the study on structural templates was done by Zhang within her Master project [109]. Zhanginvestigated how a structural template can be implemented in Ecore and weaved into a DSLmetamodel. Further, the following research questions should be addressed: what is the natureof structural templates; how structural templates can be parameterized, applied (invoked), andweaved together in a DSL structural definition; and how can these mechanisms (structural tem-plates separately and their composition together) be translated into Ecore and Event-B. However,in our work we focus on the dynamic semantics of DSLs (see the next section) and discuss thestructure of DSLs as a necessary context of our study. Therefore, we consider the listed questionsout of scope of this thesis.

In our work, as an approximation of the proposed concept of structural templates, we employUML-B [91]. UML-B wraps Event-B code into the graphical notation of UML class diagrams(and UML state machine diagrams, which we do not consider here). For this, UML-B maps(translates) the standard constructs of UML class diagrams to the corresponding Event-B (or B)constructions. As Ecore is a subset of UML class diagrams, we use this translation to bridgeEcore and Event-B. We consider the basic constructs of Ecore (a class, an argument of a class, anassociation between classes, etc.) to be structural templates and use UML-B to translate them tothe corresponding Event-B constructions. The translation of such structural templates to Ecoreis trivial. On the one hand, this implementation has certain restrictions. For example, it doesnot allow to capture various properties of the DSL structure in the DSL structural definition: weneed to specify them separately in Ecore (for example, using OCL) and in Event-B (for example,using axioms). On the other hand, we can use (a subset of) an existing DSL metamodel as aninput for the UML-B translation to Event-B.

3.3 Defining the Dynamic Semantics of a DSLAs described in Chapter 2, the dynamic semantics of the LACE DSL is defined by the set of con-ceptual machines and the LACE-to-Event-B model transformation that instantiates and composesthese conceptual machines for each concrete LACE model (program). Note that the examplesof such conceptual machines, presented in Section 2.5, use known mechanisms of program-ming and/or reuse mechanisms from each other. For example, the Event-B machine specifyingthe behavior of a subsystem component implements the FIFO (first-in-first-out) mechanism (seeFigure 2.8(b)). The Core SF of the LAC component (Figure 2.8(a)) and the ‘aligned-with-the-implementation’ version of the Order SF of the LAC component (Figure 2.18) use the samemechanism for processing a (sub)set of (requested) elements one-by-one blocking any upcomingrequest till the current request is processed: compare the usage of the variables curr_job andwait_exe in Figure 2.18.

Thus, we observe that major parts of our Event-B machines specifying LACE are not LACE-specific and in principle can be used for defining other DSLs as well. However, the LACE-to-Event-B model transformation, that instantiates and composes these machines, is LACE-specific.Therefore, to be able to reuse our Event-B specifications of LACE for defining the dynamic se-

48 The Grand Vision

mantics of other DSLs (or an evolution of LACE), we need to generalize both components of thespecification of the dynamic semantics of LACE: conceptual machines and the LACE-to-Event-B model transformation. Such a generalization is achieved by extracting the LACE-specificinformation (from the conceptual machines and the transformation) and lifting this informationuntil we find a suitable abstraction for expressing (part of) the dynamic semantics of a DSL in aDSL-independent way.

The result of the generalization of LACE conceptual machines is a library of semantic tem-plates. In particular, the two example mechanisms given above are generalized as the Queuespecification template and the Request specification template. Each of the semantic templates hasa corresponding representation (implementation) in Event-B (see Figure 3.3, the top layer). Theresult of the generalization of the LACE-to-Event-B model transformation is a meta-languagethat allows for describing a DSL semantics definition in terms of semantic templates and forautomatic generation of the corresponding DSL formal specification in Event-B (M2 layer in Fig-ure 3.3). These two generalizations form the core of our research work. The rest of Figure 3.3depicts our vision on the potential usage of semantic templates. Figure 3.4 connects our vision ofa definition of the dynamic semantics of a DSL (from Figure 3.3) with our vision of a definitionof the structure of the DSL (presented in Figure 3.2).

modelimplementation

modelspecification

modelvisualization

programexecution

modelanimation


source codetemplates

M2

M1

M0

C++, Java, etc.(source code)

Event-B(formal methods)

BMotion Studio(debugging GUI)

Event-Btemplates

uses

referencetranslation, automated via the corresponding reference

DSL semanticsdefinition

semantictemplates

semanticsapplication

executiontrace

visualizationtemplates

COREF

Figure 3.3: Semantic templates and their application

In the LACE case study, the Event-B conceptual machines specify the dynamic semanticsof LACE and get instantiated and composed (invoked and weaved together) into a compositemachine for each concrete LACE model. In the same way, in Figure 3.3 the Event-B DSLformal specification is instantiated into an Event-B model specification for each concrete DSLmodel on the M1 layer. In contrast with the LACE case study, this instantiation is realized bya DSL-independent translation. First, a DSL model is translated into the corresponding struc-ture instantiation (see Figure 3.2). Then, according to this structure instantiation, we constructa semantics application (using the connections between the definition of the dynamic semanticsand the structure of the DSL, as depicted in Figure 3.4). Such a semantics application is stillcomposed of semantic templates, but invokes them using more detailed (concrete) DSL struc-

3.3. Defining the Dynamic Semantics of a DSL 49

Figure 3.4: Connections between semantics definition and structural definition

ture (M1-model vs. M2-model). On the M1 layer three different platforms can be (potentially)bridged via the invoked semantic templates: source code, formal methods, and domain-specificvisualization (see Figure 3.3).

For example, for each semantic template of our library we can assign the correspondingsource code template that implements it. A translation from a semantic application to a modelimplementation would compose these implementations of the semantic templates and, thus, con-struct the corresponding source code of the DSL model. In order to be able to use source codeas a target platform, we need to answer the following questions: how to compose fragments ofsource code according to a DSL semantics definition; and more particularly, does the order, inwhich code fragments are composed, influence the behavior of the resulting program.

Bridging an actual implementation of a DSL (in GPL source code) and a formal specificationof the dynamic semantic of the DSL on the M0 layer is investigated within COREF by Man-ders [63]. In his work, Manders uses execution traces to investigate and compare behavior ofDSL models and their implementations in different target platforms. Potentially, such executiontraces can use semantic templates to decipher the low-level information of execution logs (fromthe program execution or from the model animation) into the higher-level concepts specified inthe DSL semantics definition. This will allow for high-level domain-specific debugging of DSLprograms (in contrast to low-level GPL-based debugging of the source code generated from aDSL model).

An example of another platform is BMotion Studio, that we used in our case study to createa domain-specific visualization of the Event-B specifications of LACE. As this visualizationis designed following the same modules of the LACE specification that we aim to generalizeinto semantic templates, we can potentially identify and collect visualization templates (rightmost column in Figure 3.3). If each of the semantic templates in our library is coupled witha corresponding visualization template, then the construction of a domain-specific visualization

50 The Grand Vision

for an arbitrary DSL can be supported with a (higher-level) palette consisting of the visualizationtemplates instantiated for (and based on) the DSL semantics definition.

In this way, a library of semantic templates can serve as a common semantic domain, whichis used as a (common) source of semantic mappings targeting various execution platforms. Asa result, the consistency between different DSL translations is handled within these semanticmappings and can be reused for different DSLs. However, the feasibility of these ideas requiresfurther research.

3.4 ConclusionsIn this chapter we elaborated on the lessons learned during the LACE case study and describedour vision on how a generic framework for defining DSLs can look like. We discussed ourobservations and generalized the results obtained for the LACE DSL, and proposed an approach(a framework) that will support reuse of these results for other DSLs. The proposed approach isbased on the idea of structural and semantic templates. In the remainder of the thesis we realizethis idea by designing and developing the concept of specification templates.

In particular, in the next chapter we design a language that allows for the introduction andapplication of specification templates, i.e. realizes the following two relations depicted in Fig-ure 3.3: semantic templates implemented as Event-B templates (the arrow in the top layer), anda DSL semantics definition given in terms of semantic templates (the arrow between the M2 layerand the top layer). Further, we develop the semantics of this language by specifying the semanticmapping from an arbitrary DSL semantics definition to the corresponding DSL formal specifica-tion in Event-B (the dashed transformation arrow in the M2 layer in Figure 3.3). Finally, weinvestigate the applicability of the proposed idea and its realization through a validation study ondefining the dynamic semantics of a DSL.

Chapter 4

Specification Templates and Constellefor Defining the Dynamic Semantics of DSLs

The constellations are totally imaginary things that poets, farmers and as-tronomers have made up over the past 6000 years. The real purpose for theconstellations is to help us tell which stars are which, nothing more. On areally dark night, you can see about 1000 to 1500 stars. Trying to tell whichis which is hard. The constellations help by breaking up the sky into moremanageable bits. They are used as mnemonics, or memory aids.

What Are Constellations? - on the Internet

Following the requirements formulated in Chapter 2, in this chapter we design and developthe Constelle language. Constelle implements the idea of reusable specification templates, intro-duced in Chapter 3.

Constelle introduces an intermediate semantic domain for defining the dynamic semantics ofa DSL. The first step of the semantic mapping maps DSL constructs to specification templates.The second step of the semantic mapping implements specification templates using the back-endformalism. From the technological point of view, Constelle wraps a back-end formalism (such asEvent-B) into specification templates and uses them as building blocks for defining the dynamicsemantics of a DSL. In relation to the LACE case study (described in Chapter 2), specificationtemplates generalize the conceptual machines that we used for the LACE specification; and Con-stelle results from lifting up and abstracting the LACE-specific information extracted from theLACE-to-Event-B transformation.

In Chapter 2 based on our LACE case study, we suggested a hypothesis that in a definition ofthe dynamic semantics of a DSL an intermediate semantic domain is determined by the ‘domainspecificity’ of the DSL. In particular, an intermediate semantic domain consists of common soft-ware (design) solutions that reappear in the implementation of the DSL and form its horizontaldomain. According to this hypothesis, the dynamic semantics of a DSL is defined by a (semantic)mapping of DSL vertical concepts (i.e. its language constructs) to DSL horizontal concepts.

Using Constelle, we aim to support this hypothesis. For this, we use specification templatesto capture software (design) solutions that reappear in the implementation of different DSLs (i.e.

52 Specification Templates and Constelle for Defining the Dynamic Semantics of DSLs

the DSL horizontal domain). Constelle allows for mapping constructs of the DSL (i.e. the DSLvertical domain) to such specification templates. As a result, Constelle supports the reuse of(formal specifications of) common software (design) solutions throughout the family of DSLsthat apply the same implementation techniques. Moreover, Constelle facilitates a clear definitionof the dynamic semantics of a DSL in terms of its horizontal concepts.

Throughout the chapter we use a LEGO allegory to explain our ideas and design decisions.The LEGO allegory is a metaphor for the dynamic semantics of a DSL defined following the ac-tual implementation of the DSL (rather than according to a set of requirements), see Section 4.1.In Section 4.2 we define the notion of reusable specification templates and discuss how theyare invoked and composed together. In Section 4.3 we develop a metamodel of specificationtemplates. In Section 4.4 we describe the Constelle language and its metamodel. Section 4.5introduces the technique of reusable constraint templates that we use in Constelle to ‘glue’ thespecification templates invoked in a definition of the dynamic semantics of a DSL.

4.1 LEGO Allegory

4.1.1 Dynamic semantics of a DSL: requirements vs. solutionsIn analogy with software, a DSL can be explored, designed, and described in the form of twodifferent artifacts:

• requirements that define expected (or intended) behavior of DSL programs;

• solution that defines the actual implementation (or software architecture) of the DSL.

Ideally, each possible solution refines the (predefined) requirements (in the general mean-ing of the refinement relation as the implication of properties). To check whether this relationactually holds, one can apply manual and automatic techniques – validation and verification cor-respondingly. For performing automatic verification of this refinement relation, one needs tohave a formal specification of the requirements. Manual validation involves a human who caninterpret the informal description of requirements. In this case a misinterpretation is possibleand there exist a number of studies that aim to mitigate this drawback, see for example [62]. Inpractice, requirements are specified formally if it is required by a standard of the developmentprocess – for example, for critical or life-threatening systems, such as railway signaling (theCENELEC standards) or automotive systems (the ISO 26262 standard).

Classical approaches of algebraic and denotational semantics allow for formally specifyingthe dynamic semantics of a programming language in the form of requirements rather than in theform of a solution. An operational semantics gives more insight in how a program is executed,but still abstracts from implementation strategies and machine architectures [73]. Using theseformal techniques requires scientific expertise and, thus, is not expected from an average softwareengineer. At the same time, the costs of employing scientific expertise might not be justified ifa DSL is used in a non-critical domain. Thus, the usual situation, that the dynamic semanticsof a DSL is not specified formally, might be the common software development practice of nothaving a formal specification of requirements.

In our approach we specify the dynamic semantics of a DSL as a solution rather than require-ments. To stress the difference between a specification of requirements and a specification of asolution, we illustrate our approach using a tangible and domain-independent analogy: the LEGOTechnic construction kit. LEGO Technic allows for constructing models of moving mechanismsusing LEGO pieces such as gears, pins, axles, pneumatic systems, motors, etc. and principlesof mechanical engineering to assemble them. An example of such a LEGO Technic model is

4.1. LEGO Allegory 53

presented in Figure 4.1.1 When considering requirements of the system modeled by this LEGOconstruction, one can think about the following requirement: the car should make a smoothleft (or right) turn when the car is moving and the steering wheel is turned left (or right). Theconstruction presented in Figure 4.1 is a model of a real-life solution: it abstracts from someimplementation details and captures the key elements of the solution, which guarantee the real-ization (refinement) of the requirements listed above. The key elements of the pictured solutionare: bevel gears steering system, two differentials that enable the car to turn smoothly, etc.

(a) Side view (b) Bottom view

Figure 4.1: Example of a LEGO Technic model

In the same way as a LEGO model captures the principal mechanical solution, a definitionof a DSL implementation captures the DSL dynamic semantics as a principal design solution. Ifsuch a definition is precise and executable (as defined in Section 2.1), then we can use it in thefollowing use cases:

• to prototype the DSL implementation (in LEGO: let’s construct a Jeep-like car);

• to validate the prototyped DSL implementation against (informal) requirements by exe-cuting the definition (in LEGO: does the car drive? does the steering mechanism work asexpected?);

• to check consistency of the prototyped DSL by analyzing the definition (in LEGO: how aretwo differentials combined in a four-wheel drive without blocking the car from moving?);

• to verify the prototyped DSL against formalized requirements (or other high-level proper-ties that the DSL should fulfill) by analyzing the definition (in LEGO: a combination ofgears meshed together support the speed and/or friction ratio as specified in requirements);

• to simulate and debug DSL programs by executing the definition (in LEGO: debug whythe gears get loose after 10 minutes of usage).

Note, that for all these use cases it is essential that the definition of the DSL dynamic semantics(that is used for analysis and execution) is consistent with and reflects the actual DSL imple-mentation. Without this consistency we cannot extend the results of analyzing and executing thedefinition to the actual DSL implementation and its DSL programs.

1Pictures of LEGO models used in the thesis are taken from the web-sites brickshelf.com and sariel.pland from the book [52].

brickshelf.com

sariel.pl


4.1.2 Reusable specification templatesWhen defining a DSL dynamic semantics as a design solution rather than requirements, we targeta semantic domain that is sufficiently rich to model the programming language (or environment,or system, or platform) in which DSL programs are executed. Thus, this semantic domain rep-resents concepts that are commonly used in software development practice (rather than in a par-ticular DSL). In our LEGO allegory this means, that the same semantic domain of plastic LEGOpieces (which model real-life details: gears, axles, pneumatic systems, etc.) is used to constructmechanisms (i.e. DSLs) from various domains - from cars and trucks, to robotic arms. This isdifferent to the definition of the dynamic semantics of a DSL (or mechanisms) in the form ofrequirements: then we target the semantic domains that are (substantially) different from eachother. For example, for cars we would model concepts of speed, acceleration, and caster angle;and for robotic arms we would model concepts of gripping, spinning, and positioning.

On the one hand, this kind of semantic domain is low level, which can result in a relativelycomplex semantic mapping that bridges the semantic gap between a DSL and the semantic do-main. On the other hand, the commonality of the semantic domain makes it possible to reusecommon, reappearing solutions. We will explain this observation using the LEGO allegory.When constructing LEGO mechanisms, one does not need to reinvent the wheel. There is a set ofcustom mechanical solutions (built of LEGO pieces), patterns, and principles that one can reusefor constructing linkages, transmissions, suspensions, pneumatic devices, etc. For example, acollection of such patterns is provided in the book by P. Kmiec [52]. Note, that these mechanicalsolutions are not restricted to LEGO constructions, but are rather distilled and explained in termsof LEGO (Figure 4.2(b)). The same idea can be applied to defining a DSL dynamic semanticsvia introduction of reusable specification templates.

(a) Differential pattern (b) Function of the dif-ferential pattern

�� (c) Application of the differential pattern

Figure 4.2: Example of a LEGO pattern

4.2 Approach

4.2.1 Reusable specification templatesSpecification templates are introduced for the reuse of common (successful) design solutions,which appear when constructing (defining or prototyping) DSL implementations (solutions). Inour work we concentrate on reusable specification templates for defining the dynamic semanticsof DSLs. However, similar ideas can be applied to the definition of other aspects of DSLs:abstract syntax (metamodel), concrete syntax (grammar), or static semantics (type system). Abrief overview on the existing research of such a possibility is given in Section 4.6.

4.2. Approach 55

1 t empla te <typename Type >2 Type max ( Type a , Type b ) {3 re turn a > b ? a : b ;4 }5 . . .6 i n t z = max< i n t >( x , y ) ;

Listing 4.1: Example of a C++ template and its invocation

Reusable specification templates realize the well-known approach of generic programming,first defined by Musser and Stepanov in [72]. In generic programming, many concrete imple-mentations of the same algorithm are captured in the form of a generic algorithm via abstractingfrom the concrete data types appearing in the algorithm. Such an abstraction is expressed asrequirements on the parameters of a generic algorithm. For example, Listing 4.1 (lines 1–4)depicts a generic algorithm implemented as a C++ function template for calculating the larger oftwo objects, a and b. The only parameter of this generic algorithm is the data type Type. Fromthe source code, we can infer that the requirements on this parameter are as follows: this typeshould support copying of an object value and the operator greater-than (>). 2 Line 6 of List-ing 4.1 demonstrates how this template can be (re)used: for this, the type parameter is specified(int) and the resulting specialized template is invoked as a usual C++ function (in the example,we calculate it for the variables x and y).

With regard to our LEGO example depicted in Figure 4.2(a), we can consider the differentialpattern as a generic mechanical template parameterized by the gears used in its construction. Themajor requirement on these parameters can be that the gears should fit together. After specializingthis template with concrete gears, we can invoke it by connecting with other parts of the vehiclevia input (green) and output (red) axles (in the example depicted in Figure 4.2(c), the output axlesare connected to the wheels, and the input axles are connected to the engine).

Similar to a source code template, a specification template is a piece of specification codeparameterized for reuse via abstracting from the concrete data types and/or data. Unlike a tem-plate written in a programming language, a specification template is written in a formalism thatis based on a solid mathematical theory. Therefore, we identify the following key features thatcharacterize reusable specification templates.

• A specification template is a specification where some specification elements are consid-ered as template parameters and thus can be substituted by other elements of the samenature. (In our LEGO example depicted in Figure 4.2(a), the driver gear mounted on thegreen axle is considered as a template parameter and, thus, can be replaced by anothergear).

• Requirements on template parameters are specified explicitly as a part of the specificationtemplate. (In Figure 4.2(a), the driver gear should be a bevel gear, which means that it canbe meshed with other gears in a perpendicular manner).

• A specification template can be reused together with the results of its verification, suchas: proof of the specification consistency and/or proof of some properties holding for thisspecification. (The main property of the differential pattern is depicted in Figure 4.2(b):it balances the drive between output axles allowing for a smooth turn [52]; this property

2Note, that in some programming languages it is possible to specify such requirements explicitly, for example, as aninterface that should be realized by the type parameter.


holds for any specialization of the template that fulfills the requirements imposed on thetemplate parameters).

• After specializing a specification template, it can be invoked as a building block for con-structing another (composite) specification. The verification results of the specificationtemplate hold after composing the template with other parts of the composite specification.(In Figure 4.2(c), both applications of the differential hold the "smooth turn" property).

While specification templates can be a part (i.e. a language construct) of a specification for-malism, we decide not to develop such a formalism from scratch, but rather base our solutionon an existing formalism. The existing formalism provides its tool support (verification andvalidation tools), thus fulfilling the requirement Req-1 formulated in Chapter 2. And our frame-work wraps the formal methods allowing for composing a design solution using specificationtemplates, according to the requirement Req-3. In order to support all features of specificationtemplates listed above, the ingredients of such a framework should fulfill the following require-ments

• The specification formalism provides the possibility to parameterize specifications. Suchparametrization allows for specialization of a specification into another one with the pos-sibility to reuse its verification results.

• The specification formalism provides the possibility to compose specifications in such away, that the constituent specifications hold their verification results after being composedtogether.

• The front-end provides a language that allows for describing a design by configuring theparametrization and composition of reusable specification templates. Moreover, the front-end supports feedback from the formal methods tools to the language level.

The first two requirements are fulfilled by the Event-B formalism and the techniques of genericinstantiation (implementing the first requirement), shared event composition, and refinement(both implement the second requirement). The third requirement is partially contributed by thischapter: the Constelle language.

4.2.2 Specification templates for composing DSL semanticsFollowing the requirements Req-4 and Req-5 formulated in Chapter 2, we aim to use specifi-cation templates as the semantic domain, and Constelle as the language for defining a semanticmapping (from a DSL to the semantic domain). In the classical approaches of denotationalsemantics or operational semantics [73], a semantic mapping is defined as a set of so-calledsemantic functions, each of which gives a meaning to a separate construct (statement) of the lan-guage being defined. A meaning of a language construct determines how this construct changesthe state of the program being executed. In other words, the semantics of each of the languageconstructs is defined separately and independently from other language constructs in terms ofchanges to the program state. This style of a semantic mapping is known as a compositionalsemantics [73] and can be characterized as a one-to-many relation (from DSL constructs to statechanges).

However, our decision to define a DSL dynamic semantics as a solution (or implementation,as described in Section 4.1) leads to the following situation. In a solution, multiple DSL con-structs (statements) can be implemented via the same specification template invocation; and oneDSL construct can be implemented by multiple specification template invocations. In this case,

4.2. Approach 57

1 void P o i n t : : moveBy ( i n t dx , i n t dy ) {2 x = x + dx ; y = y + dy ;3 d i s p l a y . u p d a t e ( ) ;4 l o g (MOVE_BY, t h i s , dx , dy ) ;5 }6

7 void P o i n t : : s e t C o l o r ( i n t c ) {8 c o l o r = c ;9 d i s p l a y . u p d a t e ( ) ;

10 l o g (SET_COLOR , t h i s , c ) ;11 }

Listing 4.2: Example of a C++ code with different aspects

the meaning of a DSL construct determines how multiple template invocations change the stateof the program being executed. For example in our LEGO allegory (in Figure 4.2(c)), two dif-ferent ‘DSL constructs’: driving and turning - are implemented by the following common set ofmechanical templates: the differential pattern (invoked twice) and the drive-train. The state of thecar is changed via interaction of these template invocations. This style of a semantic mapping canbe characterized as a many-to-many relation (from invocations of specification templates to statechanges). As a consequence, when defining a semantic mapping we may face the problem ofscattering and tangling: the definition of a DSL construct is scattered over multiple invocationsof specification templates, and an invocation of a specification template participates in definitionsof multiple DSL constructs (and, thus, tangles them). Note that whether such a decompositionof the dynamic semantics (into template invocations) is always feasible is the question that weaddress in Chapter 9 as a future work. Here we focus on the design of the proposed approach.

The problem of scattering and tangling of software code is considered and managed by As-pect Oriented Programming (AOP) [49]. The AOP technique allows for the modularization ofaspects that cross-cut a system’s basic functionality. Examples of such aspects are synchroniza-tion, memory management, localization, logging, etc. For example, in the C++ code depictedin Listing 4.2 the basic functionality of updating a point’s color and changing its coordinates iscross-cut by the aspect of notifying the display about the point’s new state (lines 3 and 9) andby the aspect of logging (lines 4 and 10). According to the AOP paradigm, these aspects can beextracted into separate (explicit) modules and then weaved into the basic functionality.

Following the requirement Req-6 formulated in Chapter 2, we use the AOP approach toexpress how a DSL dynamic semantics is composed of specification templates. We consider(specialized) specification templates as aspects and weave (i.e. compose) them together to formthe functionality (i.e. behavior) of DSL constructs. In other words, the dynamic semantics of aDSL is defined by composing aspects, each of which is a specialized specification template. Themajor difference between our approach and the classical AOP is that we define the DSL semanticmapping only in terms of aspects, i.e. the basic functionality is a composition of aspects.

As it was discussed earlier, such a definition can be characterized as a many-to-many relation.A natural way to depict such definition is to use the matrix notation: the basic functionality(state changes) is represented in rows, the aspects (invocations of specification templates) arerepresented in columns, and the intersections of these represent the composition (semantics ofDSL constructs). For example, Table 4.1 represents the composition of aspects for the code inListing 4.2.

Compared to the classical AOP realized in programming languages, aspects in our approachare formal specifications. Thus, the compatibility of aspects composed together can be analyzedusing tools that support the specification formalism. For example, two differential patterns can


Table 4.1: Mapping of aspects on the basic functionality

Point Display LoggingmoveBy update MOVE_BYsetColor update SET_COLOR

be composed together into a 4× 4 vehicle’s drive-train, as shown in Figure 4.2(c). To ensure thecompatibility of these two template invocations, the front and rear differentials must be orientedin opposite directions so that the front and rear wheels rotate in the same direction. This can bechecked by executing the LEGO model, i.e. by executing (animating) the formal specification ofthe dynamic semantics.

4.3 Reusable Specification TemplatesIn this section we develop a (meta)model of reusable specification templates. As a carrier formal-ism to express specification templates we use Event-B. However, we strive towards a mechanismthat is formalism-independent, that is, we wish to be able to use another back-end formalism.The metamodel of specification templates allows for configuring the parametrization of Event-Bcode for further (re)use in a definition of the dynamic semantics of a DSL.

4.3.1 The Event-B formalism

Machine Context

Event InvariantVariable Axiom CarrierSet Constant

Action GuardParameter

EventBNamedCommentedDerivedPredicateElement

EventBNamedCommentedElement

EventBNamedCommentedActionElement

EventBNamedCommentedPredicateElement

[0..*] refines

[0..*] sees

[0..*] variables[0..*] invariants

[0..*] events

[0..*] extends

[0..*] refines

[0..*] sets[0..*] constants[0..*] axioms

[0..*] parameters[0..*] guards

[0..*] actions

Figure 4.3: Metamodel of an Event-B specification

As we explained in Chapter 2, Event-B employs set theory and first-order logic for specifyingsoftware and/or hardware behavior. The metamodel of an Event-B specification is depicted in

4.3. Reusable Specification Templates 59

Figure 4.3. This is an essential subset of the Event-B metamodel provided by the EMF frameworkfor Event-B, one of the Rodin plug-ins [92]. Recall that, an Event-B specification consists ofContexts and Machines.3 A context describes the static part of a system using sets, constants,and axioms. A machine uses (sees) the context to specify behavior of a system via a state-basedformalism. Variables of the machine define the state space. Events, which change values of thesevariables, define transitions between the states. An event consists of guards and actions, and canhave parameters. The properties of the system are specified in invariants of the machine.

CONTEXT template queue context

SETS

ElementType

END

(a) Event-B context for the Queue specification template

CONTEXT template request context

SETS

ElementType

END

(b) Event-B context for the Request specifica-tion template

MACHINE template queue machine

SEES template queue context

VARIABLESqueue

INVARIANTS

inv1 : queue ∈ N 7→ ElementType

EVENTS

Initialisation

beginact1 : queue := ∅

end

Event enqueue =

any element, index

wheregrd1 : element ∈ ElementTypegrd2 : index ∈ Ngrd3 : queue 6= ∅⇒

(∀i·i ∈ dom(queue)⇒ index > i)thenact2 : queue := queue ∪ {index 7→ element}

end

Event dequeue =

any element, index

wheregrd4 : index 7→ element ∈ queuegrd5 : ∀i·i ∈ dom(queue)⇒ index ≤ ithenact3 : queue := queue \ {index 7→ element}

end

END

(c) Event-B machine for the Queue specification template

MACHINE template request machine

SEES template request context

VARIABLESrequest body

INVARIANTS

inv1 : request body ∈ P(ElementType)

EVENTS

Initialisation

beginact1 : request body := ∅

end

Event request =

any elements

wheregrd1 : elements ∈ P(ElementType)grd2 : request body = ∅thenact2 : request body := elements

end

Event process =

any element

wheregrd3 : element ∈ request bodythenact3 : request body :=

request body \ {element}end

END

(d) Event-B machine for the Request specifica-tion template

Figure 4.4: Event-B code of two specification templates: Queue and Request

Figure 4.4 shows the Event-B contexts and machines of two specification templates that3In the rest of this thesis, we use this font convention when referring to elements of a metamodel.


we use as examples in this chapter: Queue and Request. In the Queue specification (Fig-ure 4.4(c)), the collection of elements is modeled as a partial function queue from natural num-bers to ElementType (see invariant inv1 ), where ElementType is a set of all possible elementsthat can be stored in the queue (see the Event-B context in Figure 4.4(a)). The possible opera-tions on the collection are specified as the events enqueue and dequeue. In the enqueue event,a new pair index 7→ element is added to the collection (see the action act2 ) if the index is big-ger than any other index used in the queue (see the guard grd3 ). In the dequeue event, a pairindex 7→ element is removed from the collection (see the action act3 ) if the index is smaller thanany other index used in the queue (see the guard grd5 ). In this way, the First-In-First-Out (FIFO)property of the data structure is realized.

4.3.2 Metamodel of a specification templateTo consider Event-B code as a specification template, we need (1) a mechanism to parameterize itas a generic template and (2) a mechanism to invoke this template when defining the dynamic se-mantics of a DSL. To keep the approach universal, we separate these mechanisms from a concretecarrier formalism (in our case, from Event-B). For this, we introduce the concept of Template In-terface, that supports the mechanisms of parametrization and invocation, independently from theconcrete specification formalism. A Specification Template connects a template interface and thespecification code that implements this interface.

In the metamodel depicted in Figure 4.5, concepts related to the template interface are shownon the left; concepts of the formalism (Event-B) are shown on the right; and concepts of thespecification template that connect these two parts are shown in the middle. The right part ofFigure 4.5 uses a subset of the Event-B metamodel depicted in Figure 4.3.

SpecificationElement

Machine

Context

CommentedElement

PublicElement PrivateElement

SpecificationTemplate

SemanticTemplate

StructuralTemplate

TemplateInterface

SemanticInterface

StructuralInterface

Operation

DynamicParameter

StaticParameter

Constant

InterfaceElement

Relation

Type

[1..1] eventbElement

[1..1] eventbmachine

[1..1] eventbcontext

[1..1] implements

[1..1] implements

[1..1] uses

[0..*] elements

[0..*] _interface

[0..*] signature

[0..*] _interface

[1..1] implements

[1..1] uses

EventBNamed

Figure 4.5: Metamodel of a specification template

To realize the listed mechanisms, we distinguish two possible template interfaces: StructuralInterface and Semantic Interface. To realize the parameterization mechanism, a structural in-

4.3. Reusable Specification Templates 61

terface defines a collection of template parameters that generalize the template and that can besubstituted by concrete data when specializing the template. As these parameters do not changetheir values during the execution of a composed system, we name them Static Parameters. Inour LEGO example depicted in Figure 4.2(a), the static parameters are the sizes of the gearsused in the differential: after the sizes are chosen and the corresponding gears are assembledinto the mechanism, they are not changed any more (during driving). Choosing different sizesof the gears allows for configuring the so-called axle ratio, which determines how the torquemultiplication and top speed are changed (decreased or increased).

The Queue specification template depicted in Figure 4.4(c) is generic with respect to the typeof elements stored in the queue. Thus, the corresponding structural interface includes one staticparameter: ElementType (see Listing 4.3, structural interface template_basic).4 In themetamodel depicted in Figure 4.5, we distinguish three possible static parameters: Constant,Type, and Relation. For example, ElementType is an instance of the meta-class Type. Ifwe consider a finite queue with a fixed capacity, then we can parameterize this capacity usingan instance of the meta-class Constant. We note that the completeness of such a classificationwith respect to various specification formalisms and metamodeling languages requires furtherinvestigation. Therefore, we leave a possibility to extend our metamodel by adding new kinds ofstatic parameters.

1 s t r u c t u r a l i n t e r f a c e t e m p l a t e _ b a s i c {2 t y p e s ElementType3 }4

5 semant ic i n t e r f a c e t e m p l a t e _ q u e u e uses t e m p l a t e _ b a s i c {6 o p e r a t i o n enqueue ( e l e m e n t )7 o p e r a t i o n dequeue ( e l e m e n t )8 }9

10 semant ic i n t e r f a c e t e m p l a t e _ r e q u e s t uses t e m p l a t e _ b a s i c {11 o p e r a t i o n r e q u e s t ( e l e m e n t s )12 o p e r a t i o n p r o c e s s ( e l e m e n t )13 }

Listing 4.3: Structural and semantic interfaces of the specification templates Queue and Request

To realize the invocation mechanism, a semantic interface defines a set of signatures viawhich one can invoke the behavior that is specified in the template. In the metamodel depictedin Figure 4.5, a behavior signature is modeled as an Operation. For connecting the behavior withother sub-behaviors of the system, an operation uses DynamicParameters. Dynamic parametersallow for transferring data to and from the template behavior. In our LEGO example depicted inFigure 4.2(a), the red and green axles are dynamic parameters: they connect the differential withother parts of a system and transfer the rotation to (the green axle) and from (the red axles) thedifferential.

The behavior specified in the Queue specification template can be invoked via operationsenqueue and dequeue. The data that is transferred into and from these operations is anelement that should be added to or has been removed from the queue. Thus, the correspondingsemantic interface consists of two operations: enqueue and dequeue, with elements astheir dynamic parameters (see Listing 4.3, semantic interface template_queue).

Not all elements of the specification template should appear in the template interface. Someelements are encapsulated in order to hide details of the template design. For example, the indexparameters of the events enqueue and dequeue, that are used for determining a position of the

4In the rest of this thesis, we use this font convention when referring to elements of a listing.


element being added/removed, are specific to the way the queue is modeled (a partial functionfrom natural numbers to ElementType). Therefore, we encapsulate index and do not add it to thedynamic parameters of the semantic interface. The same applies to the Initialisation event of theEvent-B specification.

Finally, a specification template as such lists the elements of the Event-B code that constitutethe template, and defines which of these elements can be substituted and/or invoked when apply-ing the template. For this, a SpecificationTemplate stores a collection of SpecificationElements,each of which references an EventBNamedCommentedElement (see the metamodel depicted inFigure 4.5). An EventBNamedCommentedElement can be an Event-B variable, an event, a pa-rameter, etc. (according to the Event-B metamodel in Figure 4.3). All these specification ele-ments constitute the template, and therefore, are explicitly referenced in it.

A specification element can be either public (PublicElement) or private (PrivateElement), seeFigure 4.5. A public element links an element of the template interface (InterfaceElement) withan element of the Event-B code that implements this interface element. When the specificationtemplate is applied, this Event-B element is substituted by another element of the same kind ac-cording to the specialization and invocation of the interface element. For example, the enqueueoperation of the semantic interface template_queue (Listing 4.3) is linked to the event en-queue of the Event-B machine template_queue_machine (Figure 4.4(c)); and the Element-Type type of the structural interface template_basic is linked to the set ElementType ofthe Event-B context template_queue_context. The elements of the Event-B specification whichdo not appear in the template interface, are referenced through PrivateElements. For example, theindex parameters of the events enqueue and dequeue are not included in the template interface,and thus, are referenced through the corresponding objects of the class PrivateElement.

As an Event-B specification is organized as a context for the static part and a machine forthe dynamic part, it is natural to split a specification template into a StructuralTemplate linking astructural interface and an Event-B context, and a SemanticTemplate linking a semantic interfaceand an Event-B machine. Theoretically, the right part of the metamodel depicted in Figure 4.5can be replaced by concepts of another specification formalism, with a necessary adjustment ofthe middle part (practically, this possibility requires further investigation). In the next section wedescribe how a DSL can be defined in terms of structural and semantic interfaces. Using onlyinterfaces for a DSL definition (i.e. only the left part of Figure 4.5) allows for a potential replace-ment of Event-B by another specification formalism without changing the DSL definition.

4.4 Constelle LanguageAs introduced in Section 4.2.1, the contribution of this chapter is the Constelle language thatallows for defining the dynamic semantics of a DSL using specification templates. Constelleapplies the ideas of generic programming and aspect oriented programming described in Sec-tion 4.2.2. Namely, in Constelle the dynamic semantics of a DSL is defined as a compositionof aspects, each of which is a specification template specialized by substituting its (static) pa-rameters with the DSL constructs. The semantics of Constelle maps such a definition to thecorresponding (Event-B) specification of the dynamic semantics of the DSL by substituting andcomposing the specification templates. Such substitutions and compositions raise certain proofobligations in the resulting specification. We discuss the Constelle-to-Event-B mapping and howthe corresponding proof obligations can be identified and discharged in Chapter 6.

To realize our approach, we need to have a library of specification templates, which we canuse in a definition. This library can exist beforehand or can be created and extended during theprocess of designing the DSL. The purpose of such a library is to collect and store the knowledge

4.4. Constelle Language 63

and expertise of designing and developing a DSL (for a concrete domain or for a general broadusage).

4.4.1 Design of the Constelle languageWe explain and design the Constelle language through the following example: we consider a DSLfor controlling an industrial robot and define (a subset of) its dynamic semantics in Constelleusing a library of two specification templates, Queue and Request. The industrial robot andan example of a DSL program for controlling it are depicted in Figure 4.6. The specificationtemplates Queue and Request were introduced in Section 4.3.1.

(a) Robotic arm

1 ta sk Demo {2 arm a c t i o n ( t u r n r i g h t , 6 0 ) ;3 arm a c t i o n ( movedown , 1 0 ) ;4 hand a c t i o n ( g r ab ) ,5 arm a c t i o n ( moveup , 1 0 ) ;6 hand a c t i o n ( r o t a t e l e f t , 1 8 0 ) ;7 arm a c t i o n ( t u r n l e f t , 6 0 ) ;8 arm a c t i o n ( movedown , 1 0 ) ;9 hand a c t i o n ( r e l e a s e ) ;

10 }

(b) A DSL program

Figure 4.6: An industrial robot and a DSL program that controls it

The industrial robot consists of two major mechanical parts: a hand, responsible for ma-nipulating objects, and an arm, responsible for moving the hand to a certain position. Ourexample DSL allows for programming tasks for such a robot using a set of actions that canbe performed by these parts, such as: actions turn left, turn right, move up, movedown performed by the arm; and actions grab, release, rotate left, rotate rightperformed by the hand. The DSL program in Listing 4.6(b) specifies the task Demo that shouldbe executed by the robotic arm. While some actions in a task should be performed in a certainorder, some other actions can be performed in parallel, as the arm and the hand can operate inde-pendently. For example, in lines 5-7 in Listing 4.6(b), the actions move up and turn leftof the arm can be performed in parallel with the action rotate left of the hand. However,the action release of the hand should be performed only after the action move down of thearm.

The dynamic semantics of the example DSL realizes the parallel execution of mutually inde-pendent actions of the robot parts, and the sequential execution of mutually dependent actions.In Constelle we define these two types of execution in two separate semantic modules. First wedefine the parallel (independent) execution of actions in the semantic module Robotic Arm Paral-lel using the specification templates Queue and Request. Then we define the sequential executionof actions in the semantic module Robotic Arm Sequential using the module Robotic Arm Paralleland other specification templates.5

In other words, in Constelle the dynamic semantics of a DSL is split into separate semanticmodules, each of which encapsulates a behavioral aspect and/or certain design decision(s) andhides it from the rest of the semantics definition. Each of these semantic modules is split into

5In the rest of this thesis, we use this font convention when referring to elements of a Constelle definition.


Table 4.2: Semantic module Robotic Arm Parallel

Robotic Arm Parallel driver1 : Queue driver2 : Queue distributor : Request

taskStm request• task •elementsarmActionStm enqueue process•action •element •elementhandActionStm enqueue process•action •element •elementexecuteArm dequeue•action •elementexecuteHand dequeue•action •element

Actions ElementTypeArmActions ElementTypeHandActions ElementType

smaller semantic modules – and so on till we arrive at the library of specification templates, whichhave the corresponding (Event-B) implementations. Thus, a definition is structured as a directedacyclic graph (DAG) of semantic modules, where the edges represent the relation ‘composedof’ and the graph sinks represent the semantic interfaces of the specification templates from thelibrary. Such a design allows for a scalable, modular, and formalism-independent definition ofthe dynamic semantics of a DSL. To make the definition uniform with respect to the ‘composedof’ relation, we consider other nodes of the graph as semantic interfaces, too. That is, eachsemantic module is a semantic interface, composed of other semantic interfaces.

Table 4.2 introduces the semantic interface of the semantic module Robotic Arm Parallel, andshows how this semantic module is composed of the semantic interfaces of the templates Queueand Request. The semantic interface of Robotic Arm Parallel is shown in the leftmost column ofthe table. The other columns show the aspects which Robotic Arm Parallel is composed of: theaspects driver1 and driver2 both invoke the Queue template, and the aspect distributor invokes theRequest template. Each column contains elements of the corresponding semantic interface. Therows of the table show different elements of these interfaces: operations (non-shaded rows) andtheir parameters (shaded rows). The intersections of the rows and the columns show the mappingof the elements of the semantic module to the elements of the constituent semantic interfaces.The bottom part of the table shows the mapping of the structural interfaces used in these semanticinterfaces. Below we explain this Constelle definition in detail.

As we stated in the introduction of this chapter, the main idea behind our approach is to definethe dynamic semantics of a DSL as a two-steps semantic mapping: first, from the DSL constructsto an intermediate semantic domain; second, from the intermediate semantic domain to the targetexecution platform. The choice of such an intermediate semantic domain is not arbitrary: it isformed by the typical (design) solutions that are used for handling the target execution platform(in other words, by concepts of the horizontal domain of the DSL). For example, a robotic armis typically controlled via the drivers of its parts. In our semantics definition, we represent suchdrivers as queues to emphasize that the drivers have buffers for storing actions that should beexecuted. The third aspect of the Robotic Arm Parallel is a distributor, responsible for assigning


actions to the drivers.A Constelle table, such as Table 4.2, represents a mapping from the DSL (vertical) concepts,

depicted in the leftmost column, to the intermediate semantic domain (i.e. the DSL horizontalconcepts), depicted in the other columns. For the example DSL we distinguish the following DSLconcepts: the task statement, two types of action statements, and two types of action executions(by the arm and by the hand). In other words, we separate the concept of an action statement in aDSL program from the concept of the resulting execution of the action by the robotic arm. These(vertical) concepts appear in the semantic interface of Robotic Arm Parallel (leftmost column inTable 4.2) as the operations taskStm, armActionStm, handActionStm, executeArm, and execute-Hand.

The operation taskStm is a starting point of an execution and is responsible for initializing atask. We define this operation as the request operation of the Request template. The elementsparameter of the request operation (the right column in Table 4.2) corresponds to the task thatis requested for the execution (parameter task in the left column). According to the Event-Bspecification of the Request template depicted in Figure 4.4(d), this means that the task is savedin the internal variable request_body; and a new task can be requested only after the current taskis processed (see grd2 in Figure 4.4(d)).

After initializing a task, we process it action by action (or statement by statement) usingthe process operation of the Request template. Each action is assigned for execution to thehand or to the arm – depending on the type of the action. Thus, the operations armActionStmand handActionStm are composed of the enqueue operation of the corresponding driver and theprocess operation of the distributor. Moreover, the action that is processed in the distributor aspectis the same action that is queued in a driver aspect. This is depicted by putting the parameterselement of enqueue and process in the same row as the parameter action of armActionStm orhandActionStm.

An execution of an action corresponds to the dequeuing of this action. Therefore, the opera-tions executeArm and executeHand are defined as the operations dequeue of the aspects driver1and driver2 correspondingly.

Finally, we specialize static parameters of the invoked specification templates. For this, weuse the following constructs of the example DSL. The set Actions contains all the predefinedactions of the DSL. As actions can be performed either by the arm or by the hand, the set Actionsis partitioned by the sets ArmActions and HandActions:

Actions = ArmActions ∪ HandActions,ArmActions ∩ HandActions = ∅

The substitution of the static parameters is depicted in the bottom rows of Table 4.2. Namely,the Actions type substitutes the ElementType of the distributor aspect. This means that the re-quest_body of the Request template invoked in this aspect becomes a subset of Actions. More-over, the task parameter of the taskStm operation is a subset of Actions too:

task ∈ P(Actions)

The ArmActions type substitutes the ElementType of the driver1 aspect. The HandActions typesubstitutes the ElementType of the driver2 aspect. These mean that only the actions of the corre-sponding type are stored in the queues: ArmActions are stored in driver1:Queue, and HandActionsare stored in driver2:Queue (see guard grd1 in Figure 4.4(c)).

In the resulting semantics of the example DSL, actions of the arm and the hand are executedindependently from each other in order of arrival to a corresponding queue. Moreover, accordingto the way actions are processed, the order of actions within a task does not matter. However, the


order of requesting tasks does matter, as a new task cannot be initialized until all the actions ofthe current task are sent to the queues.6

As described earlier, the definition of the dynamic semantics of the example DSL consists oftwo semantic modules, Robotic Arm Parallel and Robotic Arm Sequential. Robotic Arm Sequen-tial extends Robotic Arm Parallel with the specification template Partial Order. The correspond-ing structure of the definition of the dynamic semantics (i.e. DAG of the semantic modules) isdepicted in Figure 4.7.

Robotic Arm Parallel

Queue Requestlibrary

Partial Order

Robotic Arm Sequential

Figure 4.7: DAG of the semantic modules of the example DSL

Table 4.3 defines the semantic module Robotic Arm Sequential. In this module we use thesame names of operations and parameters (the leftmost column in Table 4.3) as we used inthe semantic module Robotic Arm Parallel. The semantic module Robotic Arm Sequential iscomposed of the semantic module Robotic Arm Parallel (the second column of the table) and thetemplate Partial Order (the rightmost column). The latter imposes a partial order on the actionsforming a task.7 This aspect restricts processing of actions to the maximal elements of the orderand removes the executed actions from the order. For the sake of brevity, we do not discuss thedetails of this table here.

4.4.2 Metamodel of the Constelle languageIn this section we develop the metamodel that allows for such a Constelle definition as describedabove. The resulting metamodel of the Constelle language is depicted in Figure 4.8: the partdepicted on the left duplicates the (sub-)metamodel of a template interface from Figure 4.5; andthe part depicted on the right shows concepts related to the definition of DSL semantic modulesvia composition of semantic interfaces.

In the metamodel depicted in Figure 4.8, a DSL SemanticDefinition consists of a collectionof SemanticModules, each of which is an instance of the Semantic Interface class (see the gen-eralization relation). A semantic module is composed of aspects, each of which is a Template-Invocation that invokes a SemanticInterface. An invoked semantic interface can be another se-mantic module or it can be implemented as an Event-B specification template. In this way werealize the graph structure of the semantics definition – the DAG of semantic modules, as intro-duced in Section 4.4.1.

To implement the ideas of generic programming and aspect oriented programming, the Con-stelle language realizes the following two mechanisms: (1) a mechanism to specialize a spec-ification template and (2) a mechanism to invoke the specialized template as an aspect in thecomposition with other specialized templates. For both mechanisms we use substitution of theinterface elements of constituent semantic interfaces with the interface elements of the composite

6The complete Event-B specification of the semantic module Robotic Arm Parallel can be found in Appendix B.7The Event-B specification of the Partial Order template can be found in Appendix A.


Table 4.3: Semantic module Robotic Arm Sequential

Robotic Arm Sequential core : Robotic Arm Parallel sequential : Partial Order

taskStm taskStm NewPartialOrder• task • task •poset•order •orderarmActionStm armActionStm GetMaximalElement•action •action •maximalhandActionStm handActionStm GetMaximalElement•action •action •maximalexecuteArm executeArm RemoveElement•action •action •elementexecuteHand executeHand RemoveElement•action •action •element

Actions Actions PosetElementArmActions ArmActionsHandActions HandActions

SemanticDefinition

SemanticModule

TemplateInvocation

InterfaceElementSubstitution

SemanticInterface

Operation

StructuralInterface

StaticParameter

DynamicParameter

InterfaceElement

Type

Relation

Constant

TemplateInterface

[1..*] semanticModules

[0..*] elementsSubstitution

[1..1] owner

[0..*] aspects

[1..1] invokes

[0..*] _interface

[1..1] uses[0..*] _interface

[0..*] signature

[1..1] formal

[1..1] actual

Figure 4.8: Metamodel of the Constelle language

semantic interface. This means that in a Constelle table, an interface element from the leftmostcolumn substitutes all interface elements situated in the same row in other columns.

When substituting an interface element of a constituent semantic interface with an interface


element of the composite semantic interface, we specialize the template that implements the con-stituent semantic interface with the elements of the DSL definition (i.e. of the semantic modulebeing composed). For example in Table 4.2, the parameter task of the operation taskStm substi-tutes the parameter elements of the constituent operation request, i.e. specializes the code of theRequest specification template.

When substituting interface elements of several constituent semantic interfaces with the sameinterface element of the composite semantic interface, we link the constituent semantic interfacesvia this common (shared) interface element. In other words, the semantic interfaces are com-posed through substitution of the linking elements with one shared element that fixes this link.The concept of sharing an interface element is illustrated in our LEGO allegory (Figure 4.2(c))in the following way: the differential pattern is fit into the whole mechanism via sharing its axleswith other parts of the system. In Table 4.2, the parameter action of the operation armActionStmsubstitutes the parameters element of the constituent operations enqueue and process, i.e. linksthe interfaces of the templates Queue and Request. In the DSL definition this means that theaction that is processed in the Request template is the same action that is queued in the Queuetemplate.

In the metamodel depicted in Figure 4.8, a TemplateInvocation consists of InterfaceElement-Substitutions, each of which substitutes a formal interface element of the invoked (constituent)semantic interface with an actual interface element of the semantic module (i.e. composite se-mantic interface). This applies to all interface elements introduced earlier: static parameters (thatare used in the semantic interfaces), operations, and dynamic parameters. By substituting staticparameters we specialize the templates with the DSL constructs and synchronize them with re-spect to the data types. By substituting operations we invoke these templates and weave themtogether in an aspect oriented style (as discussed in Section 4.2.2). By substituting dynamic pa-rameters we realize transferring of data between the templates. As mentioned earlier, all thesesubstitutions raise certain proof obligations in the resulting formal specification. In Chapter 6 wediscuss how such proof obligations can be identified and discharged.

4.5 Constraint TemplatesIn the previous section, we discussed the composition (weaving) mechanism of Constelle, whichuses substitution of interface elements to link elements of semantic interfaces (aspects) beingcomposed together. In particular, such linking of dynamic parameters realizes transferring ofdata between the templates. For example, in Table 4.2 in the operation armActionStm an action istransferred (requested) from the distributor aspect to the driver1 aspect. However, such a mecha-nism is very restrictive: it can link only the dynamic parameters of the same type (otherwise thesubstitution will lead to type errors, which can be detected for the resulting Event-B specificationusing Rodin tools). To allow for linking dynamic parameters that do not share the same type,we introduce the construct of gluing guards into Constelle and implement it using constrainttemplates.

4.5.1 Gluing GuardsTo demonstrate the purpose of gluing guards, we use Constelle to define a subset of the dynamicsemantics of the LACE DSL. The dynamic semantics of LACE was specified using Event-Bduring our case study described in Chapter 2. Here we do reverse engineering of the Event-Bspecification of the LACE Core SF (core semantic feature) given in Section 2.5.2 and define itin a Constelle table. In Section 2.5.2 the dynamic semantics of the LACE Core SF is defined by

4.5. Constraint Templates 69

Table 4.4: Semantic module for LACE Core SF

LACE Core SF LAC: Request curr_la: Query SS1: Queue Gluing Guards

request_la request assign• la •value curr_job =

•curr_job •elements dom(LALabelDef(la))request_ssa process query enqueue•occurrence •element occurrence 7→• ssaction •element ssaction ∈•curr_la •value LALabelDef(curr_la)execute_ssa dequeue• ssaction •element

SS1 ElementTypeOccurrence ElementTypeLogicalAction VariableType

two conceptual machines, LAC and SS, and the description of how these machines interact witheach other. However, in our explanation of gluing guards we do not consider the LAC and SScomponents separately (in separate semantic modules), but rather show how they contribute tothe dynamic semantics of the LACE Core SF in one semantic module.

Table 4.4 shows the semantic module for LACE Core SF. We distinguish three aspects thatconstitute this semantic module: Request, Queue, and Query. The Request and Queue specifica-tion templates are introduced earlier in Section 4.3.1. The Query specification template allowsfor the introduction of a variable in a Constelle definition. For this, Query wraps an Event-Bvariable and provides two operations (i.e. methods): for assigning a new value to the variable(assign(value)) and for querying the current value of the variable (query(value)). The corre-sponding Event-B specification is rather trivial and can be found in Appendix A.

The semantic module LACE Core SF invokes the listed specification templates to model thedynamic semantics of LACE according to its specification given in Section 2.5.2. SS1: Queuerepresents the buffered execution of subsystem actions by a subsystem. LAC: Request modelsprocessing of a requested logical action by the LAC component. The aspect curr_la: Query isused to save the value of the currently requested logical action.

In Table 4.4, the operation request_la is used for requesting a new logical action. This oper-ation is composed of the request operation of the aspect LAC: Request and the assign operationof the aspect curr_la: Query. The request operation starts processing the elements of the logicalaction, stored in the parameter curr_job. The assign operation updates the value of the curr_la bythe requested logical action la. Here the aspects LAC: Request and curr_la: Query should be con-nected (linked) in the following way. The curr_job that is processed in the LAC: Request aspectconsists of the subsystem action occurrences that belong to the logical action la that is storedin the curr_la: Query aspect. This fact is captured in the predicate appearing in the rightmostcolumn of Table 4.4: curr_job = dom(LALabelDef(la)).

We use this gluing guard to connect the dynamic parameters of the request_la operation, asthese parameters have different types: curr_job is a set of subsystem action occurrences (see thestatic type Occurrence that substitutes ElementType for the aspect LAC: Request in Table 4.4);and la is a logical action (LogicalAction substitutes VariableType for the aspect curr_la: Query).


To connect these dynamic parameters, we use the LALabelDef relation specified in the structure(metamodel) of LACE. According to the specification of the LACE metamodel given in Sec-tion 2.5.1, LALabelDef associates each logical action with a subset of occurrences of subsystemactions:

LALabelDef ∈ LogicalAction→ (Occurrence 7→ SSAction)

The same mechanism of gluing guards is employed for the request_ssa operation in Ta-ble 4.4. This operation processes (process) one-by-one the subsystem action occurrences (occur-rence) of the current logical action (curr_la) and requests execution of the corresponding sub-system action (ssaction) from the subsystem (enqueue). Thus, to connect the dynamic pa-rameters of this operation we use the following gluing guard for the request_ssa operation:occurrence 7→ ssaction ∈ LALabelDef(curr_la) (the rightmost column of Table 4.4).

4.5.2 Metamodel of a Constraint TemplateTo introduce gluing guards in the Constelle language, we follow the same methodology as weapplied to the definition of the dynamic semantics of a DSL. Namely, we avoid constructing anew formalism for capturing gluing guards, but rather we build on top of the back-end formalism(Event-B) and introduce the notion of constraint templates. A constraint template is a predicateparameterized in such a way that it can be instantiated using concrete data structures and variablesand, thus, (re)used for a concrete domain (in a Constelle definition).

Following the same style that we used to design specification templates (in Section 4.3) andtheir invocation in Constelle (Section 4.4), we distinguish a ConstraintInterface, a Constraint-Invocation, and a ConstraintTemplate. ConstraintInterface represents an abstract constraint anddefines its signature (i.e. a set of template parameters). ConstraintInvocation invokes a constraintinterface by specifying (substituting) its template parameters. ConstraintTemplate assigns animplementation (i.e. an Event-B predicate) to a constraint interface.

For example, the gluing guard of the request_ssa operation of LACE Core SF (shown inTable 4.4) is implemented by the following constructs:

• constraint template: x 7→ y ∈ f(z);

• constraint interface: (x, y, f, z);

• constraint invocation: occurrence 7→ ssaction ∈ LALabelDef(curr_la), where occurrencesubstitutes x, ssaction substitutes y, LALabelDef substitutes f , and curr_la substitutes z.

Note, that here the constraint invocation uses two types of (template) parameters (supportedin Constelle): dynamic parameters (such as occurrence, ssaction and curr_la) and static parame-ters (such as LALabelDef ). Correspondingly, a constraint interface should declare x, y, and z asdynamic parameters and f as a static parameter. We capture this observation in the metamodel ofa constraint interface, constraint invocation, and constraint template, shown in two separate partsin Figures 4.9 and 4.10. Figure 4.9 depicts the metamodel of the Constelle language extendedwith the ConstraintInvocation class. Figure 4.10 depicts the metamodel of a constraint templateput into the context of a specification template (a structural template, in particular). These twometamodels are related via the common ConstraintInterface part (on the left in both figures).Below we discuss the details.

A ConstraintInterface defines a signature of a constraint template by specifying a set of its(template) parameters. As we noted above, these template parameters can include both static anddynamic parameters. To declare those, the ConstraintInterface class uses the corresponding as-sociations: staticInterface and dynamicInterface (see Figure 4.9). Note, that in order to facilitate

4.5. Constraint Templates 71

SemanticDefinition

SemanticModule

TemplateInvocation


SemanticInterface

Operation

StructuralInterface

StaticParameter

DynamicParameter

InterfaceElement

Type

Relation

Constant

ConstraintInvocationConstraintInterface

TemplateInterface



[1..1] owner

[0..*] aspects

[1..1] invokes[0..*] _interface

[0..*] _interface

[0..*] signature

[1..1] formal

[1..1] actual

[1..1] restricts

[1..1] invokes

[1..1] uses


[1..1] owner

[0..*] gluingGuards

[0..*] dynamicInterface

[0..*] staticInterface

Figure 4.9: Metamodel of the Constelle language with gluing guards


Context




StructuralTemplate

TemplateInterface

StructuralInterface

DynamicParameter

StaticParameter

Constant

InterfaceElement

Relation

Type

ConstraintInterfaceConstraintTemplate


[1..1] eventbElement

[1..1] eventbcontext[1..1] implements

[0..*] elements

[0..*] _interface

[1..1] implements

[1..1] uses

[1..1] implements [1..1] eventbpredicate

[1..1] uses



Figure 4.10: Metamodel of a constraint template implemented in Event-B

reuse of structural interfaces, we model the staticInterface as a non-containment relation, imply-ing that a ConstraintInterface references StaticParameters from an existing StructuralInterface.

As introduced earlier in Section 4.5.1, a gluing guard connects (links) dynamic parametersof an operation in a Constelle semantic module. Correspondingly, in the metamodel in Fig-


ure 4.9 a gluing guard is modeled by a ConstraintInvocation, which belongs to a SemanticModule.Each ConstraintInvocation is associated with (restricts) an Operation of this SemanticModule. AConstraintInvocation invokes a ConstraintInterface by substituting its dynamic parameters withthe dynamic parameters of the restricted operation and its static parameters with the DSL con-structs (declared in the structural interface of the semantic module). The corresponding substitu-tions are stored in the elementsSubstitution list.

Finally, in the metamodel in Figure 4.10 a ConstraintTemplate implements a Constraint-Interface by connecting it to the corresponding EventBNamedCommentedDerivedPredicateEle-ment (introduced in the Event-B metamodel in Figure 4.3). The dynamic and static parame-ters of the constraint interface are associated with the corresponding EventBNamedCommented-Elements through the (public) SpecificationElements of the constraint template.

4.6 Related WorkThe concepts of templates and/or patterns have been applied to various components of DSLs inorder to facilitate reuse of their design. The existing work includes studies on metamodel tem-plates (such as [11] and [84]); composition and reuse of concrete syntax (both for textual [69]and graphical notations [77]); and reuse of definitions of the dynamic semantics. For specify-ing reusable fragments (building blocks) of dynamic semantics and/or weaving/composing themtogether, some of the studies use informal (or semi-formal) notations: transformation languages(such as Epsilon Object Language, EOL, in [69]), UML activity diagrams (in [85]), and UMLstate and sequence diagrams (in [50]). In [18] Cleenewerck and Kurtev investigate the prob-lem of scattering and tangling of DSL concerns (modules) in a translational semantics. Theydiscover that this problem is related to the two major challenges of model-to-model transfor-mations, global-to-local and local-to-global transformations, and conclude that the semantics ofa DSL should be defined using a specially designed meta-language, rather than using existinggeneral purpose transformation languages.

There exist a number of formal notations that allow for modular definition of the dynamic se-mantics of general purpose programming languages (GPLs) using (existing or to-be-established)libraries of reusable modules. For example, TinkerType [61], Modular SOS (MSOS) [71],DynSem [106], K framework [82] achieve an AOP-like modularity for term reduction (rewritingor inference) rules. The latter two formal notations allow for automatic generation of an AST(abstract syntax tree) interpreter, which can be used as a reference implementation of the pro-gramming language or for formal analysis of the specified dynamic semantics. In [19] Combe-male et al. advocate for a thorough method of defining the dynamic semantics of a DSL, wheretwo types of the dynamic semantics should be explicitly specified: a reference semantics (welldefined requirements) and a translational semantics (for enabling various use cases through thetools of a target semantic domain). Moreover, these two types of the dynamic semantics shoulddescribe the same behaviors, which, for example, can be ensured through a bisimulation proof.

In our approach we aim for a precise and executable definition of the dynamic semantics ofa DSL and employ the translational technique. As a target semantic domain we use a formalismthat has a solid theory and extensive tools support, but is not specifically designed for defining thedynamic semantics of GPLs or DSLs. To manage the resulting complexity of a semantic map-ping, in this chapter we propose and design Constelle, a meta-language that allows for definingthe dynamic semantics of a DSL using specification templates and uses the principles of AOP toexpress how invoked specification templates interact with each other. In Section 4.6.1 we discussin detail the existing work that uses various formal methods for defining reusable (intermediate)building blocks for composing the dynamic semantics of DSLs. In the relation to the concept


of specification templates, in Section 4.6.2 we look into existing techniques for reusing formalspecifications of software systems.

Note, that here we do not consider reuse of a DSL and its formal analysis via embeddingthis DSL into another DSL, as it is done by Ratiu et al. in [81]. In their work, the reuse of thesemantic mapping of a DSL to a verification formalism is achieved through the clear separationof the DSL concepts from its environment, rather than through the composition of the embeddedDSL (sub-language) with the hosting DSL (which realizes its environment).

4.6.1 Reusable building blocks for specifying dynamic semantics of DSLsIn [22] Dagand et al. propose Filet-o-Fish (FoF) as a semantic language for composing a DSLout of semantically-rich building blocks. Technically, FoF is a ‘safe abstraction of C embeddedin a functional language’ (in their case, Haskell). For this, Haskell functions wrap various stringconcatenations that can generate fragments of C code. As a result, FoF abstracts from the detailsof the C syntax and provides building blocks for specifying the dynamic semantics of a DSL.Such building blocks are invoked and composed together in the form of (higher-order) functionsusing the standard combinators of Haskell (such as folding for traversing an abstract syntax tree,AST). Thus, in FoF the dynamic semantics of a DSL is defined as a Haskell program usingavailable code generators. On the one hand, the FoF-to-C compiler generates the correspondingC code from such a definition. On the other hand, various techniques and tools for Haskellallow for validation (for example, random testing) and verification (i.e. proofs of correctness) ofthe definition of the DSL dynamic semantics at the level of this definition. Unfortunately, theauthors do not discuss the nature of their building blocks. Therefore, it is not clear if we can useFoF to introduce and to invoke the building blocks proposed in our approach: software designsolutions commonly used in the implementation of DSLs.

In [16] Chen et al. propose semantic units as an intermediate common language for definingdynamic semantics of DS(M)Ls. Semantic units capture the formal operational semantics fora set of basic models of computations. These can be either basic behavioral categories, suchas Finite State Machine (FSM), Timed Automaton (TA), and Hybrid Automaton (HA); or basiccomponent interaction categories, such as Synchronous Data Flow (SDF), Communicating Se-quential Process (CSP) and Process Networks (PN). The semantic units are specified using theAbstract State Machines (ASM) formalism. The dynamic semantics of a DSL is defined as amodel transformation between the metamodel (abstract syntax) of the DSL and the metamodelthat captures the syntax of the ASM Abstract Data Model of a selected semantic unit. The au-thors call such a technique semantic anchoring. Comparing to our semantic templates, semanticunits are general purpose computation models, rather than specific software solutions formingthe horizontal domain of a DSL or a family of DSLs.

In [15] Chen et al. develop a method for the composition of semantic units. In the same wayas in our approach, the dynamic semantics of a DSL is built hierarchically as a composition ofprimary semantic units and newly derived semantic units (composed of the primary ones). Tospecify such a composition the authors use the composition mechanisms of the ASM formalism,such as invocations of primary ASM specifications and adding new (ad-hoc) constraints. As aresult, the interaction of constituent semantic units and the mapping between their data structuresare tangled over the ASM code. In our approach we overcome this issue by using the tablenotation for composing specification templates when defining the dynamic semantics of a DSL.

Mannadiar and Vangheluwe in their position paper [64] elaborate on the work by Chen et al.and describe an idea of a semantic template – a combination of a metamodel template (i.e. aparametrized metamodel fragment) with its semantic anchoring (i.e. its model transformation tothe ASM formalism). The authors propose to define a DSL as a combination of such seman-


tic templates, thus automatically constructing the DSL metamodel and the dynamic semanticsspecification. However, there is no follow-up work and/or proof of concept for the proposedapproach.

In [90] Simko extends the approach of semantic anchoring to denotational specification ofthe dynamic semantics of CPS (Cyber-Physical Systems) modeling languages. The author iden-tifies the following semantic units, typical for the CPS domain: differential algebraic equations,difference equations, and finite state machines. Comparing to the FORMULA formalism used inthis work, Event-B does not allow for expressing differential algebraic and difference equations.Our approach is based on providing an operational specification of the dynamic semantics ofDSLs. In particular, we specify a DSL dynamic semantics as a solution rather than requirements(as discussed in Section 4.1.1).

In [76, 75] Pedro et al. propose a compositional and incremental approach for prototypingDS(M)Ls, where they focus on reuse of metamodel fragments (which they call domain con-cepts) together with the model transformations that capture the dynamic semantics of these frag-ments. A domain concept is a brick that represents a basic idea that can appear in one or severalDS(M)Ls. A domain concept is defined as a metamodel, a set of the metamodel elements that canbe parameterized (i.e. replaced by effective parameters), and a model transformation to a formalexecutable language (in their case, to Concurrent Object Oriented Petri Nets, CO-OPN) that cap-tures the dynamic semantics of this domain concept. The definition of a DS(M)L consists of themetamodel composition and the transformation composition. The metamodel composition is aniterative replacement of formal parameters of some domain concept with elements (i.e. classes,attributes, etc.) of another metamodel. In this way, various domain concepts can be composedwith each other or with specific constructs of the DS(M)L being defined. The corresponding re-placement of parameters (i.e. instantiation) takes place in the model transformation of the originaldomain concept. Moreover, the instantiated transformation is extended with additional transfor-mation rules that capture a more precise and more specific semantics of the DS(M)L. As a result,the transformation language (in their case, ATL) serves as a main formalism for specifying thedynamic semantics of a DSL. Moreover, different from Constelle, this approach does not provideany formal theory behind the instantiation and composition of dynamic semantics of constituentbuilding blocks (in their terms, domain concepts). We discuss this aspect in detail in Chapter 6,where we present the semantic of the Constelle language.

In [23] Degueule proposes a meta-language for modular and reusable development of DSLs,Melange. The motivation for Melange is drawn from the idea similar to our idea of reusing com-mon solutions appearing in the implementation of DSLs: ‘many DSLs, despite being targeted atspecialized domains, share common paradigms and constructs’. Melange is build on top of theK3 language, a meta-language for operational semantics definition. In K3 an operational seman-tics is defined as a set of aspects, each of which adds an execution information (a current stateand executable methods) to one of the constructs of the DSL abstract syntax. Melange allows forcomposing such definitions of the operational semantics by ensuring structural interoperabilityof DSLs being composed. For example, if two DSLs have different metamodels, Melange allowsfor merging their sets of K3 aspects by introducing structural interfaces that wrap and abstractaway these different metamodels. Such structural interfaces of Melange are of similar purposeand nature as structural templates of Constelle. Different from Melange, Constelle allows fordirect composition (weaving) of operations of aspects (semantic modules). Moreover, the tablenotation of Constelle captures the many-to-many relation between DSL constructs and aspectsof the dynamic semantics in an explicit way.


4.6.2 Composition and reuse of formal specificationsThe idea of applying the principles of AOP to the formal specification of software systems ap-peared shortly after the introduction of AOP. In [48] Kellomaki and Mikkonen not only proposethe gradual introduction of aspects of collective behavior in a specification of reactive distributedsystem, but also describe how such aspects can be stored as generic templates, allowing for reuseof both design and verification effort.

Kellomaki and Mikkonen use the DisCo specification language and in their later studies in-troduce the Oscid specification language [47], an experimental variant of DisCo. An aspect isdefined as a superposition step, which refines an existing specification by introducing new statevariables, invariants, and actions. Comparing to Event-B, the superposition mechanism resem-bles shared-event composition, rather than the Event-B refinement. Particularly, superpositionpreserves safety properties by construction. To be able to archive and reuse such a superpositionstep, the authors turn it into a template by introducing template parameters and specifying whatbehavior these parameters should realize. In Constelle only static parameters (of a structural in-terface) can be used for instantiating a template. In contrast, Kellomaki and Mikkonen includeactions into their template parameters and specify these actions. As a result, an instantiatedtemplate (an aspect) can be imposed (applied) only if the original specification realizes certainbehavior.

Using templates of superposition steps, one can design a distributed system adding new as-pects to it one-by-one, forming a specification branch. In [46] Kellomaki extends this approachwith the possibility to merge (compose) specification branches together. Comparing to the tablenotation of Constelle, both DisCo and Oscid use the ’...’ symbol as a weaver notation: to indicatewhere the old code appears in the new specification. In [36] the Oscid specification languageis applied for specifying and instantiating two (OOP) design patterns: Observer and Memento.Unfortunately, there is no follow-up work.

In [38] Hoang et al. propose a concept of the Event-B pattern, which is similar to the su-perposition step of Kellomaki and Mikkonen. An Event-B pattern is a (generic and/or reusable)refinement step that introduces new details to the abstract machine of the pattern. An applicationof the pattern (i.e. of the instantiated refinement step) requires syntactical matching the abstractmachine of the pattern with the Event-B machine under construction. The authors identify thefollowing patterns of communication protocols: Single Message Communication, Request/Con-firm/Reject, and Asynchronous Multiple Message Communication (with or without Repetition).Comparing to the approach of Kellomaki and Mikkonen (and to Constelle), an Event-B pat-tern does not have an explicit description of template parameters, as Hoang et al. use purely theEvent-B notation. The syntactic matching of the pattern is semiautomated. This makes it hard toreuse patterns in other formalisms, and to capture design of a specification (i.e. of a system underspecification) in terms of pattern applications (as it is done in Constelle tables).

The ancestor of the Event-B formalism, the B method, is used in [13] to specify (OOP)design patterns and to realize different reuse mechanisms for them. Particularly, instantiation ofa design pattern is implemented in B by the inclusion of the machine specifying the design patternand by redefining (in essence, renaming) its variables. Composition of multiple design patternsis achieved through the invocation of the operations of different patterns in a new (composite)operation and/or linking or merging the variables of the patterns. Extension of a design patternis realized using the B refinement mechanism. This study shows that, in principle the designpatterns based approach can be realized in formal methods through proper code conventions, inthe same way as it is done in software development for general purpose programming languages.The practice shows that this approach requires discipline and good understanding of a chosenformalism.


4.7 ConclusionsIn this chapter, we developed and demonstrated a new method for defining the dynamic seman-tics of DSLs. The key point of our method is an intermediate semantic domain, that splits thesemantic mapping from a DSL to an execution platform (or a specification formalism) into twosteps. As the intermediate semantic domain we use software design solutions that are typicallyused in the DSL implementation, i.e. concepts that form the horizontal domain of the DSL. Thus,we define the dynamic semantics of a DSL as a mapping from the language constructs (formingthe vertical domain of the DSL) to the horizontal concepts. In this way, we do not propose a (yetanother) intermediate language, universal for defining dynamic semantics of all possible DSLs;but we rather propose an intermediate step in the definition of the dynamic semantics of a DSLand support this step with the corresponding expressive means.

To capture the mapping from the DSL constructs to the intermediate semantic domain, weuse the notation of a table: the DSL vertical domain is represented in the table rows, the DSLhorizontal domain is represented in the table columns, and the mapping is represented in theirintersections. The second step of the semantic mapping, from the intermediate semantic domainto the specification formalism, is realized through specification templates.

We implemented this method in the form of the Constelle language and employed the Event-B formalism as a carrier for specifying behavior. Constelle applies ideas of generic programmingand aspect oriented programming to the world of formal methods and provides a front-end thatwraps the Event-B formalism. In this way, Constelle fulfills the following requirements formu-lated in Chapter 2: Req-3, Req-4, Req-5, and Req-6 (as described in Section 4.2).

As a next step, we define the semantics of Constelle in the form of semantic mapping ofConstelle to Event-B. The semantic mapping from Constelle to Event-B assigns a correspondingEvent-B specification to a definition of the dynamic semantics of a DSL. In order to follow ourgeneral requirement that both a semantic mapping and semantic domain should be precise andexecutable (formulated in Section 2.1), we design the Constelle-to-Event-B semantic mappingusing Event-B techniques that are theoretically solid: generic instantiation, shared-event com-position, and refinement. To make the Constelle-to-Event-B semantic mapping executable, weimplement it in a (QVTo) model-to-model transformation.

In order to design and describe the Constelle-to-Event-B mapping (model transformation),we introduce a method for describing model transformations and formulate a number of designprinciples for developing model transformations. These are demonstrated in the next chapter(Chapter 5). The results of applying these techniques to the Constelle-to-Event-B mapping canbe found in Chapter 6.

The implementation, pragmatics, and evaluation of the proposed method are addressed inChapters 7 and 8. The questions for future work are discussed in Chapter 9.

Chapter 5

Designing and Describing Model Transformations

The basic principle of mathematics: reduce an expressionby two, increase the explanation by eight.

The students humor

The main contribution of our work is the Constelle language (described in Chapter 4). Weimplement Constelle as a model transformation to the back-end formalism (Event-B). The roleof this model transformation is twofold. On the one hand, it allows for automatic generationof Event-B specifications based on a definition of the dynamic semantics of a DSL in Constelle(according to the requirement Req-7 formulated in Chapter 2). On the other hand, this modeltransformation formulates and captures the semantics of Constelle itself. Therefore, we aim todesign and describe the Constelle-to-Event-B model transformation in a clear, maintainable andintelligible, way (and thus, apply the requirement Req-2 to Constelle itself).

A problem that we face when describing the semantics of Constelle is the lack of commonnotations for describing (documenting) model transformations and the lack of common pragmat-ics explaining how to use (design) model transformations. To overcome this challenge, in thischapter we propose to use the mathematical notation of set theory and functions to give an in-formal description of a model transformation. Moreover, we use this notation to formulate twodesign principles of developing QVTo transformations: structural decomposition and chainingmodel transformations. In the next chapter we apply this methodology to design and describe theConstelle-to-Event-B semantic mapping. The work presented in this chapter is published in [99]and [100].

5.1 Introduction and MotivationModel transformations are the key technology of Model Driven Engineering (MDE). Modeltransformations make models meaningful and exploitable and, thus, allow for (software) de-velopment using models as first-class artifacts. Employing model transformations as the keydevelopment technology poses challenges typical for software engineering, such as design, doc-

78 Designing and Describing Model Transformations

umentation, and maintenance. To address these challenges one needs to be able to describe modeltransformations in an unambiguous and clear way.

Nowadays, there exist a number of languages specifically devoted for implementing modeltransformations, such as: ATL (Atlas Transformation Language)1, QVT (Query/View/Transfor-mation)2 family of languages, ETL (Epsilon Transformation Language)3, etc. These languagescan be viewed as DSLs for model transformations. Consequently, a notation for designing anddocumenting programs written in such languages should be specifically tailored to describingmodel transformations, more or less disqualifying general purpose notations such as UML. Inthe current practice there exists no specific notation for describing model transformations (ex-cept those provided by the model transformation languages themselves). The common approachfor documenting and/or explaining model transformations is to use concrete examples of theirinputs and the corresponding outputs. Clearly, this approach provides an incomplete picture ofthe transformation and it fails to provide an overview of the transformation design, which are es-sential for describing complex model transformations bridging big semantic gaps and/or havingcomplex organizational structures.

In our work we use QVT-Operational (QVTo), that was introduced as part of the MOF (MetaObject Facility) standard [74]. QVTo allows for imperative implementations of model transfor-mations using various tool support, such as plug-ins of Eclipse Modeling Project. The languagecomprises both high-level concepts specific for model transformation development, such as con-structs of the Object Constraint Language (OCL), traceability, inheritance of subroutines; andlow-level concepts of the imperative languages, such as loops, conditional statements, explicitinvocation of subroutines. Consequently, using QVTo requires strong expertise in programminglanguage technologies. However, when interviewing QVTo practitioners we discovered that theyare mostly engineers who are experts in their own domains but typically have little to no com-puter science training and lack the required language expertise. Moreover, gaining the requiredexpertise in QVTo is hampered by the fact that the language is poorly documented and especiallylacks documentation on its pragmatics.

In this chapter, we propose to adopt functions and set theory as a notation-independentand informal approach for documenting, explaining, and designing QVTo model transforma-tions. Typically such mathematical concepts are familiar to most engineers. In what follows, wedemonstrate how this notation can be aligned with the QVTo concepts, and thus can be used forexplaining QVTo concepts and for documenting model transformations (Section 5.2). Moreover,using this notation we formulate two common design principles of developing model transfor-mations and show how the corresponding organization structure and information flow can bedescribed (Sections 5.3). In Section 5.4 we discuss and assess the proposed approach based oninterviews with QVTo practitioners. Related work is discussed in Section 5.5. Conclusions anddirections for future work are given in Section 5.6.

5.2 Notation for Describing Model TransformationsA model transformation takes as an input one or more source models and generates as an outputone or more target models. An algorithm for such generation is defined in terms of source andtarget metamodels. In particular, the smallest units of a model transformation (such as mappingsin QVTo, or rules in ATL and ETL) are defined in terms of classes and associations specified inthe source and target metamodels. In order to provide a description of a model transformation

1http://www.eclipse.org/atl/2http://www.omg.org/spec/QVT/3http://www.eclipse.org/epsilon/doc/etl/

http://www.eclipse.org/atl/

http://www.omg.org/spec/QVT/

http://www.eclipse.org/epsilon/doc/etl/

5.2. Notation for Describing Model Transformations 79

using the mathematical notation of set theory, we need to specify how we refer to the metamodelconcepts in this notation.

5.2.1 Describing Metamodel ConceptsIn the context of MDE, a metamodel is usually defined using the MOF standard. This standardcan be seen as a subset of UML class diagrams. There have been a number of studies on formal-izing UML class diagrams, see e.g. [91]. A common approach is to view a class as a set of objectsthat instantiate this class, and the associations between classes as relations on the correspondingsets of objects. Following this approach, we represent classes as sets and objects of classes aselements of sets. For instance, the example metamodel depicted in Figure 5.1 introduces the setsStateMachine, State, Transition, CompositeState, etc. In model transformations, associations areused as references to access and assign the associated objects, rather than elements of relationson the sets of objects. Therefore, we do not use the notation of relations, but stick to the notationcommon in object-oriented languages (including QVTo), and refer to the associated classes usingassociation names and dot notation; for instance s.states where s ∈ StateMachine.

StateMachine

name : EString

Transition

TriggerConstraintBehavior

State

name : EString

CompositeState

/isSequential : EBoolean = true/isOrthogonal : EBoolean = false

[0..*] transitions

[0..*] trigger[0..1] guard[0..*] effect

[1..*] submachine

[1..*] states

[0..*] in[1..1] target

[0..*] out[1..1] source

[1..1] initial

[0..*] final

Figure 5.1: Metamodel of the UML state machine

Associations between classes are the key metamodel elements that determine the structure ofthe resulting models. From the point of view of a model structure, we may treat an object as atuple of its referenced objects and its attributes. This permits a different view on classes: a classcan be seen as a relation on the classes it is associated with. For example, the class StateMachineis determined by a relation on the classes with which it is associated through the associationsstates, transitions, initial, and final:

StateMachine ⊆ P(State)× P(Transition)× State× P(State) (5.1)

Note that here we use the powerset P(S) of a set S to indicate that multiplicity of an associationend has an upper bound greater than one. We will use the inclusion relationship (5.1) as arewriting rule when constructing transformations in Section 5.3.1.

5.2.2 Describing Model TransformationsIn general, a model transformation defines a relation between a set of source models and a set oftarget models [21]. A QVTo mapping is more restrictive, realizing a function that maps one or


1 mapping T r a n s i t i o n : : C l o n e T r a n s i t i o n ( ) : T r a n s i t i o n { . . . }2

3 mapping T r a n s i t i o n : : M u l t i p l y T r a n s B y S t a t e ( in s t a t e : S t a t e )4 : T r a n s i t i o n { . . . }5

6 mapping Tuple ( s1 : S t a t e , s2 : S t a t e ) : : M u l t i p l y T w o S t a t e s ( )7 : S t a t e { . . . }8

9 mapping Set ( S t a t e M a c h i n e ) : : Mult iplySTMs ( )10 : S t a t e M a c h i n e { . . . }

Listing 5.1: Mapping declarations of the example QVTo transformation

1 mapping T r a n s i t i o n : : C l o n e T r a n s i t i o n ( ) : T r a n s i t i o n {2 r e s u l t . t r i g g e r := s e l f . t r i g g e r −> map C l o n e T r i g g e r ( ) ;3 r e s u l t . gua rd := s e l f . gua rd . map C l o n e C o n s t r a i n t ( ) ;4 r e s u l t . e f f e c t := s e l f . e f f e c t −> map CloneBehav io r ( ) ;5 r e s u l t . s o u r c e := s e l f . s o u r c e . map C l o n e S t a t e ( ) ;6 r e s u l t . t a r g e t := s e l f . t a r g e t . map C l o n e S t a t e ( ) ;7 }

Listing 5.2: QVTo code of the CloneTransition mapping

more source model objects into one or more target model objects. Thus, we can denote a QVTomapping as a function from a set representing the source class to a set representing the targetclass. For example, the simple mapping depicted in the line 1 of Listing 5.1 can be viewed as afunction with the following signature:

CloneTransition : Transition→ Transition (5.2)

Mappings with multiple inputs and/or outputs can be treated in the same way, using Cartesianproducts of sets to indicate these inputs and/or outputs; e.g. the QVTo mappings of lines 3 and 6in Listing 5.1 can be represented as follows:

MultiplyTransByState : Transition× State→ Transition (5.3)

MultiplyTwoStates : State× State→ State (5.4)

Note that in QVTo multiple inputs and outputs for a mapping can be realized in two differentways: using in/out parameters of the mapping (lines 3-4 in the Listing 5.1) or using tuples assource/target types (lines 6-7 in the Listing 5.1). This syntactic difference influences results ofthe traceability and resolving mechanisms of QVTo, as only the object before the symbol ’::’ istraced and resolved.

QVTo also allows a collection of objects to be used as an input and/or output of a mapping(line 9 in Listing 5.1). We treat an instance of a collection defined on a class as a set of objects ofthis class, meaning that we treat the collection class as a powerset (P) of the set that represents theclass of the collection elements. Strictly speaking, a collection can be realized as a list or a bag,and thus cannot be formally specified as a set. We use this notation rather as an approximationin order to describe a transformation conceptually:

MultiplySTMs : P(StateMachine)→ StateMachine (5.5)

Function signatures allow us to concisely capture the purpose of a mapping in terms of sourceand target metamodels, and in line with the QVTo code. However, they do not suffice to describe

5.3. Design of Model Transformations 81

what a mapping actually does. For this, we need to describe how elements of target objects arecalculated from the elements of source objects. We use formulas of the following form (whichwe explain below) to achieve this:

CloneTransition(self) : trigger =⋃

t∈self.trigger

{CloneTrigger(t)},

guard = CloneConstraint(self.guard),

effect =⋃

e∈self.effect

{CloneBehavior(e)},

source = CloneState(self.source),

target = CloneState(self.target)

(5.6)

Formula 5.6 describes the QVTo mapping depicted in Listing 5.2. It shows how each elementof the target object is calculated by the invocation of other mappings on elements of the sourceobject. In QVTo invocation of a mapping on a collection is denoted by arrow (lines 2 and 4 inListing 5.2), while invocation on a single object uses dot-notation (lines 3, 5, and 6 in Listing 5.2).In Formula 5.6, we indicate the invocation of a mapping by the application of the correspondingfunction, such as CloneConstraint(self.guard). A calculation that is performed on a collectionis denoted by a quantified union over elements of the collection (lines 1 and 3 of the formula).Such a formula, moreover, specifies the order of invocation of the mappings, which might beessential due to the operational nature of QVTo. According to the execution semantics of QVToimplemented in the Eclipse project, the result of a mapping invocation is the correspondingtarget object, which is newly constructed or resolved depending on whether this mapping hasbeen already invoked on this source object.

5.3 Design of Model TransformationsDesigning model transformations is a challenging part of the model transformation developmentprocess. When designing a model transformation one must answer questions such as ‘what arethe mappings that constitute a model transformation?’ and ‘how are these mappings related toeach other, i.e. invoked by each other?’. In practice, there exist a number of design principlesthat developers can follow when creating their model transformations [31, 58]. In this section wedemonstrate how the presented mathematical notation can facilitate application of some of thesedesign principles.

5.3.1 Structural Decomposition of Model TransformationsModel transformations construct target models from source models. Such models typically con-sist of objects connected with each other by associations. Therefore, mappings that constitutea model transformation should construct both target objects and the associations between them.In QVTo each mapping constructs a new object via assigning values to its properties, i.e. byconstructing objects associated with this object. This observation is captured by the followingprinciple for designing model transformations:


mappings should be related to (invoked by) each other in the same way as the objectsthat they construct are associated with (composed of) each other.

In other words, the structure of a model transformation follows the structure defined by the targetmetamodel. In [31], this was identified as one of the best practices for understandability andmaintainability of transformations. To apply this principle in our design process we take thefollowing steps:

1. We identify the inputs and outputs of the transformation and define their structures.

2. We establish the correspondence between the elements in input and output structures.

3. We capture these correspondences in signatures of the constituent mappings.

4. We decompose the transformation into constituent mappings.

In what follows, we illustrate and explain these steps through the following example: we showhow these steps help in designing a mapping that takes two state machines and constructs a statemachine representing their product. The source and target metamodel of this transformation isdepicted in Figure 5.1. The function signature of the mapping is as follows.

MultiplyTwoSTMs : StateMachine× StateMachine→ StateMachine (5.7)

The task of writing such a transformation may not seem challenging, taking into account thatwe know the definition of a product of two state machines: a product machine simultaneouslysimulates the behavior of the two state machines of which it is constructed. Figure 5.2 shows anexample of applying such a transformation to two simple state machines. However, it might benot so obvious how to implement the MultiplyTwoSTMs transformation in QVTo code, as we needto decide how to compute a product machine according to its definition, i.e. we need to constructan imperative algorithm based on the declarative definition.

s4 s5c d s6

s1 s2a b s3

(a) Two state machines

c

d

s3, s6

s1,s4a b

s2,s4

s2,s5s1,s5

s1,s6 s2,s6

s3,s5

s3,s4

a b

a b

c

d

c

d

(b) Product of the state machines

Figure 5.2: An example of applying the MultiplyTwoSTMs model transformation

5.3.1.1 Identifying the structure of the inputs and outputs.

As a first step, we establish what kind of objects we have for the transformation. For this we‘rewrite’ each class in the initial function signature with the classes that are associated with thisone. The rule we use to rewrite is based on the inclusion relation captured in Formula (5.1).According to this formula, an object of the class StateMachine can be viewed as a tuple ofobjects referenced through the associations states, transitions, initial, and final, i.e. as an object


that belongs to P(State) × P(Transition) × State × P(State). Thus, as a result of rewritingsignature (5.7), we obtain the following:

(P(State)× P(Transition)× State× P(State))×(P(State)× P(Transition)× State× P(State))→P(State)× P(Transition)× State× P(State)

(5.8)

5.3.1.2 Connecting elements in input to output structures.

Compared to signature (5.7), signature (5.8) is much richer, but it is still very ‘monolithic’. Wenext strive towards breaking down the structure in the formula, allowing for a modular solution.To this end, we redistribute the inputs on the left of the arrow and the outputs on the rightof the arrow according to our understanding of which input elements are required to constructwhich output elements. For example, we know that the states of the resulting state machine areconstructed from the states of the input machines (see Figure 5.2). We capture this knowledgeby grouping the input collections of States and the output collection of States in a separate sub-signature in Formula (5.9).

(P(State)× P(State)→ P(State))×(P(State)× P(Transition)× P(State)× P(Transition)→ P(Transition))×(State× State→ State)×(P(State)× P(State)→ P(State))

(5.9)

We do the same for the output transitions, the initial state, and the final states. The resultinginitial state is composed of the input initial states, see the third sub-signature in Formula (5.9).The same holds for the collection of final states, see the fourth sub-signature in Formula (5.9).

The collection of output transitions is computed based on the input transitions and the inputstates, thus we duplicate the collections of the input states for the second sub-signature (see thesecond sub-signature in Formula (5.9), on the left of the arrow). Note that in the process ofstructural decomposition (described here), we do not use the inner structure of the input andoutput elements. For example, we do not refer to the source and target states of a transition, butwe rather use the collection of all states of a state machine as it appears in the structure of thestate machine (see metamodel in Figure 5.1).

5.3.1.3 Deriving signatures of the constituent mappings.

Each sub-signature, underlying the signature obtained in the previous step, captures a correspon-dence between source and target objects. We decompose the mapping MultiplyTwoSTMs intoinvocations of the constituent mappings according to these correspondences. This means that,as a first approximation, each sub-signature of signature (5.9) corresponds to an invocation of aconstituent mapping.

To derive signatures of the constituent mappings, we consider each sub-signature separately.The first sub-signature of Formula (5.9) is

P(State)× P(State)→ P(State) (5.10)

In QVTo a P-symbol that appears evenly on both sides of an arrow corresponds to the invocationof a mapping on an input collection and assigning the result of this mapping to an output collec-tion. If the mapping operates on elements of the collections rather than on the collections, then


we can reduce the corresponding collection symbols P that appear evenly on both sides of an ar-row. Mathematically, such a reduction of P-symbols corresponds to an inverse of function lifting.After applying this technique to signature (5.10), we derive the following underlying signature:

MultiplyTwoStates : State× State→ State (5.11)

The resulting mapping MultiplyTwoStates constructs a state of the target state machine as a pair ofstates from the two source machines (see Figure 5.2). The initial and final states are constructedin the same way. Thus, the signature of MultiplyTwoStates can be derived from the first, third,and fourth sub-signatures of formula (5.9).

Using our knowledge of what the transformation should do, we can further refine the sub-signature from the second line of Formula (5.9). Each output transition is a copy of an inputtransition duplicated as many times as its source and target states have been duplicated to con-struct the output states (see Figure 5.2). As each state of an input machine is paired with all statesof the other input machine, we conclude that each transition of an input machine is paired with allstates of the other input machine. This knowledge is captured by regrouping the correspondingcollections in the second line of formula (5.9):

(P(Transition)× P(State))× (P(Transition)× P(State))→ P(Transition) (5.12)

The described pairing of transitions with states is applied symmetrically to both input machines.The target collection of transitions is constructed as the union of the two resulting collections.Therefore, we reduce signature (5.12) to the following underlying signature:

P(Transition)× P(State)→ P(Transition) (5.13)

Observing that we can once more use a reverse function lifting, we finally arrive at the followingsignature for a constituent mapping:

MultiplyTransByState : Transition× State→ Transition (5.14)

5.3.1.4 Describing the implementation of a mapping.

Function signature (5.9) helps to identify signatures of the mappings that compose the MultiplyT-woSTMs mapping, but it does not capture how this composition is implemented. Therefore, as afinal step of the design procedure, we describe the implementation the MultiplyTwoSTMs mappingin a formula using the notation we introduced in Section 5.2.2:

MultiplyTwoSTMs(m1,m2) :

states =⋃

s1∈m1.states

⋃

s2∈m2.states

{MultState(s1, s2)},

transitions =⋃

t∈m1.transitions

⋃

s∈m2.states

{MultTrans(t, s)} ∪⋃

t∈m2.transitions

⋃

s∈m1.states

{MultTrans(t, s)},

initial = MultState(m1.initial,m2.initial),

final =⋃

f1∈m1.final

⋃

f2∈m2.final

{MultState(f1, f2)}

(5.15)


1 mapping Tuple ( stm1 : S ta t eMach ine , stm2 : S t a t e M a c h i n e )2 : : MultiplyTwoSTMs ( ) : S t a t e M a c h i n e3 {4 r e s u l t . s t a t e s := stm1 . s t a t e s −> c o l l e c t ( s1 |5 stm2 . s t a t e s −> c o l l e c t ( s2 |6 Tuple { s t 1 =s1 , s t 2 =s2 } . map M u l t i p l y T w o S t a t e s ( ) ) ) ;7

8 r e s u l t . t r a n s i t i o n s := stm1 . t r a n s i t i o n s −> c o l l e c t ( t |9 stm2 . s t a t e s −> c o l l e c t ( s |

10 t . map M u l t i p l y T r a n s B y S t a t e ( s ) ) )11 −> un ion (12 stm2 . t r a n s i t i o n s −> c o l l e c t ( t |13 stm1 . s t a t e s −> c o l l e c t ( s |14 t . map M u l t i p l y T r a n s B y S t a t e ( s ) ) ) ) ;15

16 r e s u l t . i n i t i a l := Tuple { s t 1 =stm1 . i n i t i a l , s t 2 =stm2 . i n i t i a l } .17 map M u l t i p l y T w o S t a t e s ( ) ;18 r e s u l t . f i n a l := stm1 . f i n a l −> c o l l e c t ( f1 |19 stm2 . f i n a l −> c o l l e c t ( f2 |20 Tuple { s t 1 =f1 , s t 2 = f2 } . map M u l t i p l y T w o S t a t e s ( ) ) ) ;21 }22

23 mapping Tuple ( s t 1 : S t a t e , s t 2 : S t a t e ) : : M u l t i p l y T w o S t a t e s ( )24 : S t a t e25 { . . . }26

27 mapping T r a n s i t i o n : : M u l t i p l y T r a n s B y S t a t e ( in s t a t e : S t a t e )28 : T r a n s i t i o n29 { . . . }

Listing 5.3: QVTo code of the MultiplyTwoSTMs transformation

This formula captures our knowledge of the transformation functionality discussed above us-ing invocations of the constituent mappings MultState (5.11) and MultTrans (5.14). For example,the target collection of transitions is constructed as the union of the two collections resulting frompairing (multiplying) transitions of one state machines with the states of another state machine(lines 3-4 in Formula (5.15)).

After we have come up with the design of the mapping and captured it in a formula, we writethe QVTo code according to this formula. Listing 5.3 corresponds to formula (5.15).

In this section, we derived the structured design of a mapping by gradual refinement of ourknowledge about the mapping implementation. The same procedure can be applied recursivelyfor designing the constituent mappings MultiplyTwoStates and MultiplyTransByState. The re-sulting process of the structural decomposition of a model transformation is common to themethod of syntax-directed translation. In syntax-directed translation, a compiler implementationis driven by the grammar of its input language [5].

5.3.2 Chaining Model TransformationsIn the previous section we discussed how a model transformation can be decomposed into con-stituent mappings by following the structure of the target model(s) and matching it with thecorresponding elements of the source model(s). However, this principle is difficult to apply ifsource and target models have very different structures; for example, if mappings that matchsource and target elements are scattered over the metamodels structures, or if there are mutualdependencies between constructed objects. This type of situation is described in the literature


as structure clash [42], or semantic gap [103]. Such a design difficulty is usually solved usinga chain of model transformations. One or more intermediate structures (or metamodels) are in-troduced to split a model transformation into two or more steps (links of the chain). In this way,a structure clash is managed in a chain of separate model transformations each of which with aminimal clash.

Using our notation this design principle can be explained as follows. Consider a modeltransformation f : A → B, where the gap between structures A and B is too wide to managein a one-step transformation. Therefore, we split this model transformation by introducing anintermediate structure C that mediates between A and B. We develop two model transformationsf1 : A → C and f2 : C → B. Then we connect those into a chain using function composition:f(m) = f2(f1(m)). A function composition can be denoted in a more ‘chain-like’ style usingthe ’◦’ operator, allowing us to write f(m) = (f1 ◦ f2)(m). We prefer to use the latter notation,as it is more readable when we have more than two steps in a transformation chain. Functioncomposition cannot always be applied immediately. For instance, if the result of a functionapplication is of a form that is different from the form that is accepted by the next function, thenthe function composition fails. An indispensable tool in many such cases is to use currying.Currying basically entails the translation of a function of the form f : A×B → C to a functionof the form g : A→ (B → C), by setting g(a)(b) = f(a, b).

Below, we illustrate through an example transformation how the concepts of function com-position and currying can be used to design a transformation chain. The example transformationflattens a UML state machine (specified by the metamodel in Figure 5.1) by removing its compos-ite states and replacing them with equivalent sets of simple states and transitions. The mappingthat performs such replacement can be described by the following signature:

SimplifyComposite : CompositeState→ P(State)× P(Transition) (5.16)

According to our metamodel in Figure 5.1, each composite state can be either sequential ororthogonal. A sequential composite state contains only one submachine, while an orthogonal (orparallel) composite state contains more than one submachine. Intuitively, when transforming asequential state, we can simply substitute its submachine into the parent machine by ‘erasing’borders of the submachine and redirecting and adding the necessary transitions. When transform-ing an orthogonal state, we need to consider its parallel nature and express it in terms of simplestates. In other words, we first need to transform parallel submachines into one sequential subma-chine. After this we can apply the same transformation as for a sequential state. This is a simpleexample of a transformation chain that constitutes the mapping (5.16). The transformation chainwill therefore consist of two mappings: Orthogonal2Sequential and SubstituteMachine. Fig-ure 5.3 shows an example of applying such a chain of model transformations to an orthogonalcomposite state.

The first mapping transforms a collection of parallel state machines (such as an exampledepicted in Figure 5.3(a)) into one state machine (such as an example depicted in Figure 5.3(b)).Thus, we describe this mapping as follows:

Orthogonal2Sequential : P(StateMachine)→ StateMachine (5.17)

The second mapping substitutes a nested state machine (Figure 5.3(b)) into the parent state ma-chine (Figure 5.3(c)). When substituting a nested machine from a composite state we need toupdate two sets of transitions: those that have the composite state as a target, and those that havethe composite state as a source. The former should be redirected to the initial substate of thecomposite state; the latter should be exiting from all substates of the composite state (see Fig-ure 5.3(c)). Therefore, we consider these sets of transitions as an input of the mapping. As an


s4 s5c d s6

s1 s2a b s3

s8s7

e f

f

s9

(a) Orthogonal composite state

c

d

s3, s6

s1,s4a b

s2,s4

s2,s5s1,s5

s1,s6 s2,s6

s3,s5

s3,s4

a b

a b

c

d

c

d

s8s7

e f

f

s9

(b) Sequential composite state

c

d

s1,s4a b

s2,s4

s2,s5s1,s5

s1,s6 s2,s6

s3,s5

s3,s4

a b

a b

c

d

c

d

s8

s7

f

s9

e

s3,s6

f ff

(c) Substituted composite state

Figure 5.3: An example of applying the chain of transformations SimplifyComposite

output, the mapping thus creates a set of new states and a set of new and updated transitions:

SubstituteMachine : P(Transition)× P(Transition)× StateMachine→P(State)× P(Transition)

(5.18)

Observe that the output of the Orthogonal2Sequential mapping does not directly match withthe input of the SubstituteMachine mapping. Therefore, we cannot connect these two mappingsusing a function composition. To overcome this problem, we apply currying: we rewrite Func-tion (5.18), which takes a tuple of inputs, as a sequence of functions, each of which takes a singleinput. In other words, we replace the Cartesian products on the left of the arrow with a sequenceof arrows to obtain the following:

SubstituteMachine : P(Transition)→ P(Transition)→ StateMachine→P(State)× P(Transition)

(5.19)

When calculating such a function, we calculate each of the functions in the sequence sepa-rately and as a result of each separate calculation we get a new function. For example, if we cal-culate Function (5.18) for a tuple (x, y, z), we start from the first function in the sequence (5.19)


1 he lp er C o m p o s i t e S t a t e : : S i m p l i f y C o m p o s i t e ( )2 : s t a t e s : Set ( S t a t e ) , t r a n s i t i o n s : Set ( T r a n s i t i o n )3 {4 re turn s e l f . submachine −> map O r t h o g o n a l 2 S e q u e n t i a l ( ) .5 map S u b s t i t u t e M a c h i n e ( s e l f . _ in , s e l f . _ou t ) ;6 }

Listing 5.4: QVTo code of the SimplifyOrthogonal transformation

and apply it for the first argument of the tuple. As a result we get a new function:

SubstituteMachine(x) : P(Transition)→ StateMachine→P(State)× P(Transition)

(5.20)

Then we do the same for function (5.20) and the rest of the tuple (y, z). As a result we get a newfunction:

SubstituteMachine(x, y) : StateMachine→ P(State)× P(Transition) (5.21)

Note that input of function (5.21) matches with the output of function (5.17). Therefore, wecan apply function composition to these two functions. The resulting definition of the Simplify-Composite mapping connects the mapping SubstituteMachine (with two fixed inputs) and themapping Orthogonal2Sequential into a transformation chain:

SimplifyComposite(state) = ( Orthogonal2Sequential(state.submachine)

◦ SubstituteMachine(state.in, state.out))(5.22)

Formula (5.22) demonstrates how the notation of function composition can enhance the de-scription of a model transformation chain and the flow of information through the separate stepsof this chain. The corresponding QVTo code is depicted in Listing 5.4.

5.3.3 Combining Structural Decomposition and Transformation ChainsIn the previous sections we demonstrated how the mathematical notation of set theory and func-tions can accompany the design process of a model transformation. In particular, we use re-grouping of function signatures to represent the structural decomposition of a model transforma-tion along the structure of the input and/or output metamodels; and function composition andcurrying – to capture the information flow in chains of model transformations. The purpose ofthese two design principles of developing a model transformation is to guide the application ofthe modular approach, i.e. to split the model transformation into modules.

In practice, these design principles are often applied simultaneously, resulting in a mixtureof transformation modules of two different kinds (sub-signatures and steps of a transformationchain). To manage the combination of these two types of modularity (i.e. to organize applicationof two design principles), we propose the following iterative process of developing a modeltransformation.

1. We choose a structure along which to decompose our model transformation. This structureis most probably the input metamodel or the output metamodel of the transformation. Ourexperience is that this choice depends on the granularity of the metamodels: we choose themost ‘dense’ structure, i.e. the structure whose content is modeled (captured) in smallerconstructs (granules), such as classes and associations between them.

5.4. Validation 89

Table 5.1: Feedback received from the QVTo practitioners

SituationsExpertisein QVTo

Expertise inmathematics

Mathematical notationfor documenting QVTo

Formulateddesign principles

Long-termdevelopment

+++ +/– +– – –

Prototyping + + – –Developinga DSL

– + +/– ++

2. We identify the delta(s) between the chosen structure and the input/output metamodel.Each delta corresponds to a (meaningful or structural) difference between the input andoutput metamodels. For each of the identified deltas we aim to develop a (separate) modeltransformation.

3. We split (or compose) our model transformation into a chain of transformations (if possibleand necessary). For this, we identify the flow of the information between the input and theoutput metamodels and connect links of the chain according to this flow (so that output ofone link serves as an input for the next link).

Note that, the described process is purely empirical and should be considered as a recom-mendation on a possible approach, rather than an attempt to generalize the development processof all possible model transformations.

5.4 ValidationIn this chapter we proposed and demonstrated an approach of using the mathematical notationof set theory for describing QVTo mappings, their signatures and implementations, for deriv-ing organizational structure of mappings, and for describing the information flow in chains ofmodel transformations. While this approach is applied to implement the Constelle-to-Event-Bmodel transformation (as described in the next chapter), further investigation and experiments areneeded to validate that the approach is feasible, useful, and consistent in a more general scope(i.e. can be applied to other model transformations). To estimate the potentials of this researchdirection, we performed an early evaluation of the proposed approach by consulting with QVTopractitioners through interviews.

5.4.1 InterviewsWe conducted four interview sessions with seven developers from three different affiliations anddifferent engineering domains. During an interview we first presented our approach (as donein Sections 5.2 and 5.3), and then collected the feedback using a questionnaire form consistingof 25 open questions. The goal of the questionnaire was to (1) assess an interviewee’s expe-rience of developing and maintaining QVTo transformations, (2) gauge his/her understandingof the employed mathematical notation, and (3) get the interviewee’s feedback on the usabil-ity and usefulness of the proposed approach. An overview of the feedback collected during theinterviews is presented in Table 5.1.


We classify the collected feedback along the following situations, in which the intervieweesused QVTo (left most column in Table 5.1):

1. developing large-scale software systems for further industrial usage in a team of softwaredevelopers that also continues to maintain and extend the QVTo source code;

2. prototyping software architectures for further delegation of found solutions to softwaredevelopers, without need for documentation and long-term maintenance of the QVTo code;

3. developing a DSL for conducting research in the field of electrical engineering by an en-gineer without computer science expertise.

In the first situation (second row in Table 5.1), the developers find the maintenance anddocumentation of their model transformations especially important. However, they are satisfiedwith the QVTo code documenting itself and use certain code conventions to improve readabilityof their model transformations. This corresponds to the high expertise level in QVTo of theseinterviewees. In this situation, the developers would not employ the proposed notation for doc-umenting their model transformations, but rather for the formal specification of (the most trickyparts of) their model transformations (‘+/–’ in Table 5.1). This feedback is partially determinedby the fact that some of these developers do not have a background in mathematics, and thuscannot understand the notation of set theory describing QVTo model transformations. As for theformulated design principles, the interviewees recognize them and already apply them in theirdevelopment process. However, the interviewees that lack the required mathematical backgroundcannot follow formulas that accompany application of these design principles in our approach.

In the second situation (third row in Table 5.1), the architect does not see the need for notationfor describing his transformations and, moreover, presumes that the proposed design guidelinesmight restrict his experiments. Thus, we conclude that our proposed approach may not be suitedfor situations such as this one.

In the third situation (bottom row in Table 5.1), the (non-software) engineer finds it especiallyimportant to discover the pragmatics of QVTo and to have guidelines on how to design a modeltransformation. Such an engineer starts the development of a DSL without having expertise inQVTo and obtains this expertise during the development process, usually by the ‘trial and error’.The interviewed engineer believes that the decomposition principle and the corresponding designprocess can be very useful and finds it helpful to have them formulated explicitly (‘++’ in thebottom right cell in Table 5.1). This third situation corresponds to our own experience of usingQVTo for designing and implementing the Constelle-to-Event-B model transformation.

5.4.2 Constelle-to-Event-BAccording to the taxonomy proposed in [68], the Constelle-to-Event-B model transformation canbe classified as an exogenous vertical semantical transformation with multiple source and targetmodels; and it can be characterized as a fully automated and complex transformation (about 40mappings and one thousand lines of code). This means that the transformation is objectivelysophisticated, which corresponds to our subjective experience. The approach proposed in Sec-tion 5.3 helped us in streamlining the development of this transformation.

Applying the proposed approach, we found that:

• the described design principles can assist in the creative process of designing model trans-formations;

• designing a model transformation in the form of formulas prior to coding it in QVToimproves readability and understandability of the resulting code;


• describing a model transformation using the proposed notation facilitates explaining itsmeaning to peers.

5.4.3 Results and Future WorkFrom our experience and from the feedback of the QVTo practitioners, we conclude that theproposed notation is usable and useful for research-oriented projects which involve design ofnontrivial model transformations and their further description and explanation (for example, inthe form of a publication). As the group of interviewed QVTo practitioners was rather small(seven developers), conducting additional interviews is an important step for future validation.Moreover, for the successful application of the proposed notation the following questions requirefurther investigation.

• Does the proposed notation restrict the resulting design of a model transformation?

• What are the limits of the proposed notation, i.e. can all essential situations and QVToconstructs be naturally described using mathematical concepts? For instance, there is nomathematical operator that naturally matches the QVTo concept of inheritance of map-pings.

• How scalable is the proposed approach, how much effort does it require in general to applythe proposed notation for describing and designing a complete complex transformation?

• Is the proposed approach language independent, i.e. can it be used for developing a modeltransformation using another model transformation languages, for example ATL?

• Do the formulated design principles improve efficiency of the resulting model transforma-tion and enhance its reuse (through its modules)?

5.5 Related WorkThe broad problem of supporting the whole life-cycle of the model transformation developmentwith a proper description notation is raised by Guerra et al. in [33]. In their study they propose afamily of different visual languages for various phases of the development process: requirements,analysis (testing), architectural design, mappings overview and their detailed design. Althoughthe authors state that the resulting diagrams should guide the construction of the software arti-facts, there is no discussion in the paper on how to design model transformations. In contrast,in our approach we use a single mathematical notation for describing three of the listed phases:architectural design (transformation chains), mappings overview (function signatures) and theirdetailed design (formulas). The mathematical notation of function signatures applied in our paperis close to the notation of rewrite rules of the ASF+SDF [12, 24] and Stratego [107] languages.

The earlier works on a notation for describing and designing model transformations, suchas [28] and [79], propose graphical representations that are based on UML class diagrams. Themajor disadvantage of such approaches is the difficulty to describe the organizational structureof a transformation and the information flow through this structure from source to target models.This challenge is managed in the visual notation of the MOLA transformation language [45],that combines ‘structured flowcharts’ for describing a transformation algorithm with (model)patterns for defining input and output of a transformation. Though MOLA aims for describingmodel transformations in a ‘natural and easy readable way’, it introduces a number of specificvisual means, which might require certain experience from a user.


The existing studies that specify model transformations using mathematical formalisms, suchas [40], mostly aim for formal analysis of transformations rather than for designing and main-taining them. An exception to this is [58, 80] by Lano and Rahimi, who define a systematicdevelopment process for model transformations with the focus on their formal specification andfurther verification. They propose to describe a model transformation as a set of abstract con-straints on the relation between source and target models that is realized by this transformation.For this, they identify and classify common patterns for specifying constraints on model transfor-mations [57]. The authors also give guidelines on how the (implementation) design of a modeltransformation can be derived based on the pattern that has been applied for its specification -using one of the proposed implementation patterns, or implementation strategies. The structuraldecomposition approach—the design principle that we discuss in Section 5.3.1—is similar to therecursive pattern in [58]. In particular, our decomposition method can be used to determine thestructural dependency ordering of the target model, which is required when applying this imple-mentation pattern. Chaining of model transformations—our second design principle, discussedin Section 5.3.2—is similar to the auxiliary metamodels pattern in [58].

The principle of structuring a program (or in our case, a transformation) according to thestructure of its input and/or output goes back to the method proposed by M. Jackson in 1970sand known as Jackson Structured Programming (JSP) [41, 42]. This method was developed inthe domain of data processing systems, where an input data stream is processed and an outputdata stream is produced as a result. JSP gives guidelines on how to decompose, i.e. to design, aprogram that performs such processing. According to JSP, program structure should be dictatedby the structure of its input and output data streams. The JSP method uses diagrams to representstructures of input and output streams, to merge them and to derive a corresponding programstructure. We apply ideas, similar to those of the JSP method, to structure model transformationsalong the structure of its input and output metamodels (Section 5.3.1).

Several aspects of our approach are indirectly supported by the results of the exploratorystudy performed by Gerpheide et al. [31] for constructing a QVTo quality model. In this workthey formalize a quality model for QVTo based on the interviews with four QVTo experts. Ac-cording to their results, understandability and maintainability are the most ubiquitous qualitygoals for QVTo experts. Moreover, among the best practices that address these goals are (1) thepreference for a declarative style of programming over an imperative style (for example, avoid-ing loop-statements); and (2) structuring a transformation along the hierarchy of either the inputor output metamodel. According to our experience, both these best practices can result fromusing the notation and the design principles described in this chapter. This indicates that theproposed approach can contribute to improving the quality of QVTo code with respect to theunderstandability and maintainability.

5.6 ConclusionsAccording to Kurtev [54], the current QVT standard lacks a formal basis, which causes riskswhen using model transformations designed and implemented in QVTo. These risks are ampli-fied by the current lack of documentation on the QVT execution semantics and pragmatics.

In this chapter we showed how the mathematical notation of set theory and functions can beused to explain QVTo concepts, to facilitate and organize the design process of model transfor-mations, and to document model transformations. The resulting formulas give an overview ofthe organizational structure and the information flow of a transformation in an unambiguous andconcise way.

We applied the proposed notation and the formulated design principles to design, develop,

5.6. Conclusions 93

and to do code refactoring of two model transformations: the state machine model transformationused as an example in this chapter and the Constelle-to-Event-B model transformation (describedin the next chapter). Moreover, we used the notation and design principles for teaching QVTo tostudents.

The approach described in this chapter requires further investigation and experiments. InSection 5.4.3 we highlight directions for future work. The quality of model transformations ingeneral is an important concern in the context of MDE and has been addressed in a number ofstudies (see for example the PhD dissertation by van Amstel [101]). In this respect, we believethat the most interesting research questions are (1) whether the described approach improves thequality of a resulting model transformation and (2) whether the proposed notation can be usedwith different transformation languages (such as Xtend, ETL and ATL).

Chapter 6

Mapping Constelle to Event-B

The best language for writing informal specifications is the language ofordinary math, which consists of precise prose combined with mathe-matical notation. The math needed for most specifications is quite sim-ple: predicate logic and elementary set theory. This math should be asnatural to a programmer as numbers are to an accountant.

Leslie Lamport, Who Builds a House without Drawing Blueprints?

In this chapter, we define the semantics of the Constelle language by mapping it to the Event-B formalism. On the one hand, in this way we answer the research question: what is the seman-tics of a definition of the dynamic semantics of a DSL? On the other hand, when specifying thesemantics of Constelle, we follow a pragmatic approach, guided by the requirements formulatedin Chapter 2. In particular, we refine the stated research question into the following (design orresearch) (sub)questions.

• How to achieve both a precise and executable semantic mapping from Constelle to Event-B?

• How do the constructs and mechanisms of Constelle map to the constructs and mechanismsof Event-B?

• What is generated from a Constelle model that defines the dynamic semantics of a DSL?

• What is the added value of having a precise semantic mapping from Constelle to Event-B?

The first of these questions is highlighted in Section 6.1, which gives an overview of thesemantic mapping from Constelle to Event-B from a pragmatic point of view. The next twoquestions are answered in the rest of the chapter (Sections 6.2, 6.3, 6.4, and 6.5) through thedescription of the Constelle-to-Event-B model transformation. For this description we rely onthe mathematical notation of set theory and functions introduced in Chapter 5. The last of thelisted questions is addressed in Section 6.6, where we identify proof obligations for the Event-Bspecifications generated from a Constelle model (i.e. a definition of the dynamic semantics of aDSL given in Constelle).

96 Mapping Constelle to Event-B

6.1 OverviewIn the Constelle language the dynamic semantics of a DSL is defined using semantic interfaces ofthe specification templates. Such templates are collected in a library, which facilitates the reuseof design solutions. As a carrier of such design solutions, i.e. as an implementation formalismfor our specification templates, we use Event-B. This means that Constelle realizes a semanticmapping of the DSL to the semantic domain of Event-B (according to the definitions given inChapter 2). In Figure 6.1 this process is represented as the leftmost T-diagram: the semanticmapping of the DSL to Event-B is realized in Constelle.

ConstelleEvent-B*

Event-B

DSLConstelle

Event-B DSLEvent-B

Event-B

QVTo

Figure 6.1: T-diagrams of the Constelle semantics definition

In Constelle the dynamic semantics of a DSL is defined as a composition of specialized spec-ification templates. The engine of the Constelle language realizes code substitution in the tem-plates and composes the resulting specifications into the Event-B specification(s) of the dynamicsemantics of the DSL. The semantics of Constelle defines such a translation from a compositionof specialized specification templates to the corresponding Event-B code. In Figure 6.1 the defi-nition of the Constelle semantics is represented as the middle T-diagram: the semantic mappingof Constelle to Event-B.

To benefit from a semantics definition in practice and to implement the use cases discussedin Chapter 2, we aim to have the semantic mapping of Constelle to Event-B both precise andexecutable. Precision of the semantic mapping from Constelle to Event-B is achieved through theuse of three Event-B techniques: generic instantiation, shared event composition and refinement– depicted as Event-B∗ in Figure 6.1. These techniques have a solid theory [4] and make itpossible to reuse proof obligations discharged for the specification templates in a specification ofthe DSL dynamic semantics generated from its Constelle definition. The detailed explanationsof these techniques and how they allow for the reuse of proof obligations are given further in thischapter.

According to our definition of executability given in Chapter 2, an executable semantic map-ping can be interpreted (i.e. executed) by tools. Executability of the semantic mapping from Con-stelle to Event-B is achieved through its implementation using the MDE technique of model-to-model transformation. Namely, we implement the Event-B∗ techniques in a Constelle-to-Event-Btransformation using the QVTo model transformation language [74]. In Figure 6.1 this imple-mentation is represented as the triangle on the bottom of the middle T-diagram.

The semantic mapping from a DSL to Event-B realized in Constelle (leftmost T-diagram inFigure 6.1) combined with the semantic mapping from Constelle to Event-B result in (generate) asemantic mapping from the DSL to Event-B realized in Event-B. This mapping is represented asthe rightmost T-diagram in Figure 6.1. In the resulting definition of the dynamic semantics of aDSL, both the semantic mapping and semantic domain are precise and executable, thus fulfillingour basic requirement stated in Chapter 2.

6.2. Model transformations from Constelle to Event-B 97

6.2 Model transformations from Constelle to Event-BThe definition of the Constelle semantic mapping follows its actual implementation, the Constelle-to-Event-B transformation coded in QVTo. Thus, by defining the semantic mapping we also de-scribe how the implemented QVTo model transformation works. In this description we use themathematical notation of set theory and functions, aligned with the concepts and notation of theQVTo language – as introduced in Chapter 5. In particular, we define the Constelle-to-Event-Bsemantic mapping as a set of functions, capturing QVTo model transformations, and defined interms of the metamodels introduced in Chapter 4.

Figure 6.2 reproduces and combines all the metamodels introduced in Chapter 4. The Con-stelle metamodel is depicted on the left, with the dedicated Constelle constructs depicted on theshaded background and the basic constructs related to the notion of template interface depictedon the white background. The metamodel of a specification template is depicted in the mid-dle on the shaded background. The Event-B metamodel is shown on the right. The relationsthat connect these four metamodels are highlighted using labels that are typeset in bold (such asimplements that links elements of specification templates with the corresponding elements oftemplate interfaces).

According to the description method introduced in the previous chapter, each class depictedin Figure 6.2 is viewed as a set of objects that instantiate this class, and as such is used in the defi-nitions of the QVTo functions that are given further in this chapter. Note that as we use set theoryand functions, we do not discuss some trivial details, such as formal applicability of functionsor additional constraints that should be fulfilled. This is done for the sake of brevity. However,the actual Constelle-to-Event-B transformation performs all necessary checks. In Section 6.6 wediscuss proof obligations that result from (or correspond to) the Constelle-to-Event-B functions.

The model transformation Constelle-to-Event-B transforms (maps, translates) a Constelledefinition of the DSL dynamic semantics to a corresponding Event-B specification of this DSLdynamic semantics. For this, the transformation consumes a Constelle model (instance of theConstelle metamodel) and a library of the specification templates invoked in this Constellemodel. As in Constelle the dynamic semantics of a DSL is defined through a DAG of semanticmodules (see Chapter 4), the transformation produces an Event-B specification that consists ofmultiple Event-B machines: an Event-B machine for each semantic module of the definition.Each of these resulting Event-B machines is wrapped into a specification template. This is donefor the sake of uniformity (of semantic modules and semantic templates) and for the possibilityto construct new specification templates from existing ones using Constelle.

Consequently, we describe the Constelle-to-Event-B transformation by the following func-tion:

Constelle-to-Event-B :

P(SpecificationTemplate)→ SemanticDefinition→ P(SemanticTemplate)(6.1)

Here the transformation applies a library (a set) of SpecificationTemplates to a SemanticDefinitionof a DSL; and generates as an output a collection of SemanticTemplates that implement all se-mantic modules of the input semantic definition. All constructs used in the formulas of thischapter correspond to the similarly-named classes depicted in Figure 6.2, such as Semantic-Template and SemanticDefinition. Figure 6.2 should be consulted in order to understand whichclasses participate in a transformation and how these classes are related to each other.

98M

appingC

onstelleto

Event-B


SemanticTemplate Machine



StructuralTemplate

ConstraintTemplate


Context


Event

InvariantVariable

Action

GuardParameter

Axiom

CarrierSet

Constant

EventBNamedCommentedPredicateElement

EventBNamedCommentedActionElement

InterfaceElement

DynamicParameter

Operation

StaticParameter

StructuralInterface

ConstraintInterface

SemanticInterface

SemanticDefinition

SemanticModule

TemplateInvocation


ConstraintInvocation

[1] eventbmachine

[0..*] elements

[1] uses

[1] uses

[1] eventbElement

[0..*] sees

[1] eventbcontext

[1] eventbpredicate

[0..*] variables [0..*] invariants

[0..*] events

[0..*] parameters [0..*] guards[0..*] actions

[0..*] sets

[0..*] constants

[0..*] axioms

[1] implements

[0..*] signature

[1] implements

[0..*] _interface

[1] implements


[1] uses


[1] implements

[0..*] _interface

[1] uses

[0..*] aspects [1] invokes


[1] formal

[1] actual


[1] restricts


[0..*] gluingGuards

[1] invokes

[1] dslStructure

Figure 6.2: Metamodels of Constelle, specification templates, and Event-B combined together

6.2. Model transformations from Constelle to Event-B 99

As described in Chapter 4, each semantic module of a Constelle model substitutes static pa-rameters of the invoked specification templates with the static parameters representing the DSLconstructs – such as the types Actions, ArmActions, and HandActions in the DSL used as anexample in Chapter 4. According to the Constelle metamodel depicted in Figure 6.2, such Static-Parameters are contained in a StructuralInterface, used by a SemanticModule (as a subclass of aSemanticInterface). For the sake of simplicity, we assume that all semantic modules of a Con-stelle model use the same structural interface, which introduces all necessary DSL constructs(types, relations, and constants). In Figure 6.2 we depict such an interface through the referencedslStructure from SemanticDefinition to StructuralInterface. To ensure that the resulting Event-Bmachines specify the DSL semantics in terms of these concepts, we assume that this structuralinterface is implemented in an Event-B context beforehand. In practice such an Event-B con-text can be automatically generated from the DSL metamodel, for example using the UML-Bapproach [91]. As all other Event-B code in Constelle, such an Event-B context is wrapped inthe corresponding structural template. We treat such a structural template as a global constant(or environment) of the Constelle-to-Event-B transformation, and, therefore, do not include it inthe function definitions discussed in this section.

Transformation (6.1) can be implemented using the following (sub-)transformation that con-siders a single SemanticModule of a semantic definition and results in a single SemanticTemplatecorrespondingly:

ExpandDefinition :

P(SemanticTemplate)→ SemanticModule→ SemanticTemplate(6.2)

To transform all semantic modules of a semantic definition using their dependencies on (invoca-tions of) each other, we apply transformation (6.2) to the nodes of the DAG of semantic modulesstarting from the sinks towards the sources. In this way we ensure that when a semantic moduleis to be transformed, all its aspects (invocations of SemanticInterfaces, see Figure 6.2) have thecorresponding implementations in the form of semantic templates.

The transformation ExpandDefinition realizes the key function of the Constelle semantic map-ping. It implements the two mechanisms of the specification templates approach: substitution ofparameters in a generic template, and invocation (composition) of specialized templates. Thesemechanisms are implemented as two (separate) steps: Substitute and Compose – which are con-nected into a chain of model transformations. The third step of the transformations chain, Glue-Operations, adds the gluing guards to the composition of the specialized templates.

ExpandDefinition(lib)(module) = Compose(module)({Substitute(a, t) | a ∈ module.aspects ∧ t ∈ lib ∧ t.implements = a.invokes}

)

◦ GlueOperations(module.gluingGuards, lib ∩ ConstraintTemplate)

(6.3)

We discuss the details of the function application of Substitute, Compose, and GlueOperations(i.e. arguments of the mappings appearing in formula (6.3)) and their signatures in the followingsections.

As discussed earlier in Section 6.1, we define the semantic mapping from Constelle to Event-B in terms of the Event-B∗ techniques. As specification templates wrap Event-B code, the trans-formations Substitute, Compose, and GlueOperations build on top of (or wrap) the Event-B∗

techniques, which manipulate the back-end Event-B code. Thus, we give the definition of thefunctions Substitute, Compose, and GlueOperations in terms of the functions of the Event-B∗

techniques (formulas (6.5), (6.14), and (6.23) see Sections 6.3, 6.4, and 6.5).


Figure 6.3 provides an overview of the mappings discussed in this chapter and how they arerelated with each other. Each of the mappings in Figure 6.3 has a reference to its signature and/orto its formula (for example, Substitute (6.4, 6.5)). The functions of the Event-B∗ techniques arehighlighted in green color. The organization structure of the Constelle-to-Event-B transforma-tion depicted in Figure 6.3 shows how composite mappings are decomposed into transformationchains of constituent mappings. Such a decomposition is depicted using the ‘◦’ symbol.

Figure 6.3: Structure of the Constelle-to-Event-B model transformation

Note that every decomposition of a mapping into a chain of mappings (i.e. every step to theright along the structure depicted in Figure 6.3) is accompanied by a step towards using a morefine-grained structure (i.e. a top-down step along the class hierarchy of the metamodel depictedin Figure 6.2). In other words, constituent mappings use more details of the Constelle structurethan composite mappings. Therefore, we do not describe signatures of constituent mappings atthe same place where a composite mapping applies (invokes) these constituent mappings (i.e. inthe subsection that describes the composite mapping), but rather explain each of the constituentmappings in a subsection dedicated to it.

6.3 SubstitutionSubstitution of parameters in an invoked semantic template is the first step of the transforma-tion ExpandDefinition. It takes a SemanticTemplate from the library and performs its Template-Invocation by transforming it into a new SemanticTemplate. The resulting SemanticTemplate im-plements the semantic interface of the semantic module being composed (compared to the inputSemanticTemplate that implements a generic SemanticInterface from the library). The Substitutetransformation can be described by the following function:

Substitute : TemplateInvocation→ SemanticTemplate→ SemanticTemplate (6.4)

Correspondingly, the transformation ExpandDefinition (6.3) applies Substitute (6.4) to all as-pects of its input semantic module: Substitute(a, t) for a ∈ module.aspects (see the second lineof formula (6.3)). For this, ExpandDefinition finds a corresponding template in the library, i.e. the

6.3. Substitution 101

template that implements the semantic interface invoked in the aspect: t ∈ lib ∧ t.implements =a.invokes.

The Substitute transformation realizes four objectives:

• duplication of the specification elements (in particular, template Operations) that are in-voked (i.e. substituted) several times;

• specialization of the template parameters with the DSL constructs using InterfaceElement-Substitutions of StaticParameters;

• preparation for further composition of the template by assigning new identifiers to its Op-erations and DynamicParameters – according to InterfaceElementSubstitutions of these el-ements with elements of the target (composite) specification;

• encapsulation of the specification elements that do not implement any interface elements(PrivateElements) through extending their identifiers with a proper namespace identifier(to avoid possible name conflicts in the target specification) – using as the namespace theaspect that invokes this template.

These objectives are realized in the four consecutive steps connected into a chain of transfor-mations:

Substitute(inv, tmpl) =Normalize(inv.elementsSubstitution, tmpl.elements ∪ tmpl.uses.elements)

◦ ComposeRenaming(inv.name)

◦ GenericInstantiation(tmpl.eventbmachine)

◦ ReconstructInstantiatedTemplate(inv.elementsSubstitution, tmpl)

(6.5)

The first step normalizes the invocation of the specification template by ensuring that each Oper-ation of the semantic module substitutes the corresponding unique Operation of the specificationtemplate. For example, in the Constelle definition of the semantic module Robotic Arm Paral-lel (see Table 4.2 on page 64), the operation process of the Request template is substituted bytwo operations of the semantic module: armActionStm and handActionStm. This means thatthe Event-B code and the specification elements wrapping this code into the operation processshould be duplicated in order to implement these two separate operations of the semantic module.

The other three steps of the Substitute mapping realize the actual substitution of the templateparameters (i.e. static and dynamic interface elements) by renaming Event-B elements in theback-end specification code. For this, ComposeRenaming configures the renaming scheme. Themapping GenericInstantiation performs generic instantiation of the Event-B machine accordingto this renaming scheme. The mapping ReconstructInstantiatedTemplate is an auxiliary transfor-mation that wraps the resulting Event-B machine into the corresponding semantic template. Wediscuss these steps in the next four subsections.

6.3.1 Normalization of an invocationAs discussed above, the Normalize transformation updates an invocation of a specification tem-plate in such a way, that each of the operations of the semantic module invokes a unique (sepa-rate) operation of the specification template. This means, that each InterfaceElementSubstitutionof the input TemplateInvocation should substitute exactly one SpecificationElement of the in-put SemanticTemplate; or that the substitution relation (realized by the set of InterfaceElement-Substitutions, see Figure 6.2) should be injective. The corresponding update of the set of Interface-ElementSubstitutions and the set of SpecificationElements is captured in the following signature


of the Normalize transformation:

Normalize : P(InterfaceElementSubstitution)× P(SpecificationElement)→P(InterfaceElementSubstitution)× P(SpecificationElement)

(6.6)

For each SpecificationElement that is invoked (substituted) several times, the Normalize trans-formation creates its copy (clone) and updates the references from the corresponding Interface-ElementSubstitution. For example, in the Constelle definition of the example DSL presented inChapter 4 (see Table 4.2 on page 64), the template invocation distributor: Request (the right-most column in Table 4.2) has the following set of InterfaceElementSubstitutions (here eachInterfaceElementSubstitution is presented in the form of an ordered pair of its actual and formalInterfaceElements, i.e. an element that substitutes and an element that is should be substituted):

{(taskStm 7→ request), (task 7→ elements),(armActionStm 7→ process), (action 7→ element),(handActionStm 7→ process), (action 7→ element),(Actions 7→ Elements)

}

Here the operation process is invoked (substituted) two times: by armActionStm and hand-ActionStm. The same holds for the dynamic parameter of this operation: element is substitutedby two different parameters action. To ensure that in the resulting Event-B specification botharmActionStm and handActionStm are implemented properly and include the functionality ofthe process operation, we need to duplicate (clone) the process operation and the Event-B codethat implements it. Thus, a new set of InterfaceElementSubstitutions (i.e. substitution relation)should realize an injective relation:

{(taskStm 7→ request), (task 7→ elements),(armActionStm 7→ process), (action 7→ element),(handActionStm 7→ process2), (action 7→ element),(Actions 7→ Elements)

}

Moreover, the new (normalized) Event-B machine should contain two corresponding events:process and process2. However, the bodies (code) of these events should be the same (i.e. clonesof each other), including their parameters element.

The Normalize mapping, that realizes such a transformation, is captured in the followingformula:

Normalize(substset, specset) =(specset ∪ {c | c 7→ s ∈ clones},(substset \ {s | c 7→ s ∈ clones}

)∪ {c.implements 7→ s.actual | c 7→ s ∈ clones}

)

where clones = {Clone(el, s1) 7→ s1 |el ∈ specset ∩ PublicElement ∧ el.implements /∈ StaticParameter

∧ s1 ∈ substset ∧ s1.formal = el.implements

∧ ∃s2 ∈ substset : s1 6= s2 ∧ s1.formal = s2.formal}

(6.7)

Here for each PublicElement of the input set of specification elements (el ∈ specset ∩PublicElement, line 5 of the formula) we check if it is substituted in several InterfaceElement-Substitutions (s1 and s2, last two lines of the formula). For example, s1 can be (armAction-Stm 7→ process) and s2 can be (handActionStm 7→ process). For such s1 and s2 we duplicate


(clone) the specification element (Clone(el, s1)) and collect the cloned element and the originalInterfaceElementSubstitution (s1) paired together in an intermediate variable ‘clones’. The con-dition el.implements /∈ StaticParameter ensures that we consider (duplicate) only Operations andDynamicParameters of the specification template (so we do not consider pairs like (Actions 7→Elements) in the example above).

The intermediate variable ‘clones’ is used to update the input sets of InterfaceElementSubstitu-tions (substset) and of SpecificationElements (specset) in the following way. The cloned spec-ification elements (c) are added to the set ‘specset’ (second line of the formula). In the set‘substset’ (third line of the formula), the InterfaceElementSubstitutions that substitute the sameSpecificationElements are replaced (we remove the set {s | c 7→ s ∈ clones}) with the Interface-ElementSubstitutions that substitute the corresponding clones instead (we add the set {c.imple-ments 7→ s.actual | c 7→ s ∈ clones}).

The Clone mapping (which is used in formula (6.7)) clones (i.e. constructs a copy of) aspecification element for an input InterfaceElementSubstitution. The resulting clone includescopies of the Event-B and interface counterparts of the input SpecificationElement (i.e. objectsreferenced through the eventbElement and implements associations of the SpecificationElementare also cloned). The Clone mapping is described in the following signature:

Clone : SpecificationElement× InterfaceElementSubstitution→ SpecificationElement (6.8)

6.3.2 Configuration of renamingThe configuration of a renaming scheme is generated in a transformation ComposeRenaming.This transformation applies a set of InterfaceElementSubstitutions to a set of SpecificationElements(of the invoked semantic template). A namespace extension (String) is used for the encapsulationof the PrivateElements (i.e. SpecificationElements that are not referenced by InterfaceElement-Substitutions). The result of the transformation, EventBNamedCommentedElement 7→ String, isa partial function of renamings for the Event-B elements of the specification. The transformationis described by the following function:

ComposeRenaming :

String→(P(InterfaceElementSubstitution)× P(SpecificationElement)

)→

(EventBNamedCommentedElement 7→ String)

(6.9)

The transformation ComposeRenaming prepares the substitution of public specification ele-ments and encapsulation of private specification elements. For this, the transformation is imple-mented in the following way:

ComposeRenaming(nmspc)(substset, specset) ={s.eventbElement 7→ x.actual.name |

s ∈ specset ∩ PublicElement ∧ x ∈ substset ∧ x.formal = s.implements} ∪{s.eventbElement 7→ nmspc + s.eventbElement.name |

s ∈ specset ∩ PrivateElement}

(6.10)

In other words, the ComposeRenaming transformation considers public and private specificationelements (s ∈ specset) separately. For the former, it finds an interface element substitution(x) that substitutes the interface element implemented by this specification element (x.formal =s.implements); and uses the name of the target interface element for renaming (x.actual.name).


For the private specification elements, the transformation simply extends their names with thenamespace: s.eventbElement 7→ nmspc + s.eventbElement.name.

For example, when we apply this function to the template invocation driver1: Queue ofthe semantic module Robotic Arm Parallel defined in Table 4.2 (on page 64), we use Interface-ElementSubstitutions depicted in the table lines to substitute (i.e. rename) elements from thesecond column with elements from the leftmost column. As a namespace extension we use theaspect name, i.e. ‘driver1’. The input set of specification elements is taken from the specificationtemplate Queue. As a result we get the renaming function depicted in Figure 6.4(a).

ElementType 7→ ‘ArmActions’,queue 7→ ‘driver1_queue’,enqueue 7→ ‘armActionStm’,(enq)element 7→ ‘action’,(enq)index 7→ ‘driver1_index’,dequeue 7→ ‘executeArm’,(deq)element 7→ ‘action’,(deq)index 7→ ‘driver1_index’

(a) Renaming function

MACHINE driver1 queue machine

SEES dsl context

VARIABLESdriver1 queue

INVARIANTS

inv1 : driver1 queue ∈ N 7→ArmActions

EVENTS

Initialisation

beginact1 : driver1 queue := ∅

end

Event armActionStm =

any action, driver1 index

wheregrd1 : action ∈ ArmActionsgrd2 : driver1 index ∈ Ngrd3 : driver1 queue 6= ∅⇒

(∀i·i ∈ dom(driver1 queue)⇒ driver1 index > i)thenact2 : driver1 queue :=

driver1 queue ∪ {driver1 index 7→ action}end

Event executeArm =...

(b) Fragment of the instantiated Event-B machine

CONTEXT dsl context

SETSActions, ArmActions, HandActions

AXIOMS

axm1 : partition(Actions,ArmActions,HandActions)

END

(c) Event-B context that implements structuralinterface of the example DSL

Figure 6.4: Substitution of the Queue template for the arm aspect

6.3.3 Generic instantiationAs described in Chapter 2, generic instantiation is introduced by Abrial et al. in [4] and is de-veloped in detail by Silva and Butler in [88]. Generic instantiation realizes reuse of an Event-Bspecification by considering it as a generic model and instantiating it into a more specific model.For this, the context of an Event-B specification C(s, c) is considered as its parameterization.The sets s and the constants c introduced in the context play the role of parameters of the genericmodel; and the axioms A(s, c) capture their properties, i.e. requirements on the parameters. Aninstantiation of such a specification uses an Event-B context D(ds, dc) with more specific setsds and constants dc, featuring more specific properties captured in the axioms DA(ds, dc). Aninstantiation of the generic Event-B machine is performed by replacing its parameters s and cwith the instance elements ds and dc. Moreover, the variables, events, and parameters of thegeneric machine can be renamed in the instantiated machine.


In practice, generic instantiation is implemented by syntactically replacing generic elementswith instance elements (sets, constants, variables, events, and their parameters), or renaminggeneric elements into instance elements. For example, Figure 6.4(b) shows an Event-B machineconstructed as a result of generic instantiation of the Queue (template) machine (depicted inFigure 4.4(c) on page 59). For this generic instantiation we used the renaming configurationdepicted in Figure 6.4(a).

According to [88], the resulting instantiated machine is correct by construction if the follow-ing conditions hold.

• The requirements on the parameters of the generic specifications hold for its instantiation.This means that the properties A(ds, dc) of the generic specification can be derived fromthe properties DA(ds, dc) of the specific (instantiated) specification. In practice, this isdone by stating the generic properties A(ds, dc) as theorems, and thus triggering the gen-eration of the corresponding proof obligations. In our example, the context of the Queuetemplate (Figure 4.4(a)) does not contain axioms. Therefore, no generic properties need tobe proved.

• Each set (in the generic specification) must be replaced by a set or by a valid type expres-sion (in the instantiated specification); and each constant must be replaced by a constant. Inour approach we ensure that this requirement is met by providing a proper implementationof the structural interface used in the Constelle definition (an Event-B context wrapped ina structural template, as discussed earlier in this section). An example of such a contextfor Robotic Arm Parallel is depicted in Figure 6.4(c).

To apply (call) generic instantiation in our definition of the semantics of Constelle, we repre-sent it by the following function:

GenericInstantiation :

Machine→ (EventBNamedCommentedElement 7→ String)→ Machine(6.11)

Here a Machine (for example, the Queue machine from Figure 4.4(c) on page 59) is instanti-ated using a partial function of renaming Event-B elements EventBNamedCommentedElement7→ String (for example, the renaming function from Figure 6.4(a)), and as a result a new (instan-

tiated) Machine is generated (such as a machine depicted in Figure 6.4(b)).

6.3.4 Substitution: chain of transformationsAs specified earlier in formula (6.5) (and repeated here for convenience of reading), the Substitutemapping is defined as a function composition of the transformations Normalize (6.6), Compose-Renaming (6.9), GenericInstantiation (6.11), and an auxiliary transformation ReconstructInstan-tiatedTemplate (which is discussed further):

Substitute(inv, tmpl) =Normalize(inv.elementsSubstitution, tmpl.elements ∪ tmpl.uses.elements)

◦ ComposeRenaming(inv.name)

◦ GenericInstantiation(tmpl.eventbmachine)

◦ ReconstructInstantiatedTemplate(inv.elementsSubstitution, tmpl)(6.5 revisited)

Here the Normalize transformation takes as an input InterfaceElementSubstitutions of the tem-plate invocation (inv.elementsSubstitution) and SpecificationElements of both semantic template


(tmpl.elements) and of its static template (tmpl.uses.elements). The resulting normalized setsof InterfaceElementSubstitutions and SpecificationElements are used directly (◦) as an input forComposeRenaming. As a namespace extension we use the name of the template invocation (i.e.the name of the aspect in the semantic module): inv.name. The resulting renaming is applieddirectly (◦) to instantiate the Event-B machine of the template (tmpl.eventbmachine).

The output of GenericInstantiation is translated into the output of Substitute using the auxil-iary transformation ReconstructInstantiatedTemplate described by the following function:

ReconstructInstantiatedTemplate :

P(InterfaceElementSubstitution) × SemanticTemplate

→ Machine→ SemanticTemplate

(6.12)

The transformation ReconstructInstantiatedTemplate (6.12) generates a SemanticTemplatethat wraps the newly generated (instantiated) Event-B Machine. This step is necessary becausegeneric instantiation is an Event-B∗ technique implemented by one of Rodin plug-ins. To be ableto build on top of this Rodin plug-in, we need to translate the output of GenericInstantiation intothe constructs of Constelle. For this, ReconstructInstantiatedTemplate (6.12) takes the original(invoked) SemanticTemplate and traces back its specification elements to the Event-B elementsof the machine through the set of InterfaceElementSubstitutions that have been applied to theoriginal template (inv.elementsSubstitution in the Substitute mapping (6.5)).

To match all inputs and outputs of the functions being composed (transformations beingchained) in function composition (6.5), we use currying according to the technique described inChapter 5. Currying realizes the translation of a function of the form f : A × B → C to afunction of the form g : A→ (B → C), by setting g(a)(b) = f(a, b):

Normalize : P(InterfaceElementSubstitution)× P(SpecificationElement)→P(InterfaceElementSubstitution)× P(SpecificationElement)

ComposeRenaming(nmspc) :P(InterfaceElementSubstitution)× P(SpecificationElement)→(EventBNamedCommentedElement 7→ String)

GenericInstantiation(machine) :(EventBNamedCommentedElement 7→ String)→ Machine

ReconstructInstantiatedTemplate(substset, tmpl) :Machine→ SemanticTemplate

6.4 CompositionComposition of the substituted semantic templates is the second step of the transformationExpandDefinition. According to the design of Constelle, introduced in Chapter 4 and realizedin the metamodel depicted in Figure 6.2, composition of semantic templates is defined throughsharing interface elements of the (composite) semantic module between (constituent) semantictemplates (or template instances). In other words, the SemanticModule has a SemanticInterface(see Figure 6.2); the aspects of this module invoke SemanticTemplates, each of which imple-ments this SemanticInterface. Therefore, the Compose transformation takes as an input the(shared) SemanticInterface and the set of (constituent) SemanticTemplates and constructs a new(composite) SemanticTemplate:

Compose : SemanticInterface→ P(SemanticTemplate)→ SemanticTemplate (6.13)

6.4. Composition 107

The configuration when all SemanticTemplates implement the same SemanticInterface re-sults from the previous step of the transformation, the Substitute mapping, where specificationtemplates from the library are substituted with the elements of the SemanticInterface of the in-put semantic module. This is captured in the formula (6.3) that describes the transformationExpandDefinition (reappearing here for convenience of a reader):


)

◦ GlueOperations(module.gluingGuards, lib ∩ ConstraintTemplate)(6.3 revisited)

ExpandDefinition applies Compose to its input semantic module (as it is a semantic interfaceitself, see Figure 6.2) and to the semantic templates resulting from the Substitute mapping appliedto the aspects of the module (the first and second lines of the formula).

The composition of semantic templates builds on top of an Event-B∗ technique, shared eventcomposition (see Figure 6.1). This means that an Event-B machine of the resulting semantictemplate is composed of the Event-B machines of the input semantic templates using sharedevent composition:

Compose(module)(tmplts) =SharedEventComposition({t.eventbmachine | t ∈ tmplts})(config)◦ ReconstructComposedTemplate(module)

where config ={ ({x.eventbElement | x.implements = op ∧ x ∈ t.elements ∧ t ∈ tmplts},{{x.eventbElement | x.implements = dp ∧ x ∈ t.elements ∧ t ∈ tmplts}| dp ∈ op.signature

} )

| op ∈ module.interface}

(6.14)

In the next two subsections we present SharedEventComposition and discuss how it is configured(intermediate variable ‘config’) and how the resulting (composite) Event-B machine is wrappedinto a specification (semantic) template (using the ReconstructComposedTemplate mapping).

6.4.1 Shared event compositionAs we explained earlier in Chapter 2, shared event (de)composition was introduced as one of themechanisms to support modularity of Event-B specifications [89]. Shared event (de)compositionallows for decomposing an Event-B specification into a collection of independent sub-componentsthat interact with each other. Each sub-component is specified in a separate constituent Event-B machine, which does not share its state (i.e. its variables) with the constituent machines ofother sub-components. The sub-components interact with each other by sharing (synchroniz-ing) events of the corresponding constituent machines. The synchronized events can exchangedata via shared parameters. This mechanism is similar to the exchange of messages betweensynchronized input and output channels in Communicating Sequential Processes (CSP) [39].

Figure 6.5 shows an example of a machine composed for the semantic module Robotic ArmParallel according to its definition given in Table 4.2 on page 64. This machine is composed ofthree machines: two instances of template_queue_machine (introduced in Figure 4.4(c)) – forthe aspects driver1 and driver2, – and one instance of template_request_machine (introduced inFigure 4.4(d)) – for the aspect distributor.


MACHINE robotic arm parallel

SEES dsl context

VARIABLESdriver1 queue, driver2 queue, distributor request body

INVARIANTS

driver1 inv1 : driver1 queue ∈ N 7→ArmActions

driver2 inv1 : driver2 queue ∈ N 7→HandActions

distributor inv1 : distributor request body ∈ P(Actions)

EVENTS...

Event taskStm =

any task

wheredistributor grd1 : task ∈ P(Actions)distributor grd2 : distributor request body = ∅thendistributor act2 : distributor request body := task

end


any action, driver1 index

wheredriver1 grd1 : action ∈ ArmActionsdriver1 grd2 : driver1 index ∈ Ndriver1 grd3 : driver1 queue 6= ∅⇒ (∀i·i ∈ dom(driver1 queue)⇒ driver1 index > i)distributor grd3 : action ∈ distributor request bodythendriver1 act2 : driver1 queue := driver1 queue ∪ {driver1 index 7→ action}distributor act3 : distributor request body := distributor request body \ {action}

end

...

Figure 6.5: Fragment of the composed Event-B machine

To apply shared event composition in our definition of the Constelle semantics, we representit by the following function:

SharedEventComposition :

P(Machine)→ P(P(Event)× P(P(Parameter)))→ Machine(6.15)

Here a set of constituent Machines is composed into a new (composite) Machine using a configu-ration of type P(P(Event)× P(P(Parameter))). A configuration is formed as a set of compositeevents of the resulting machine. Each of these composite events is composed of a pair consist-ing of a set of synchronized events P(Event) coming from different constituent machines andof sets of sets of parameters P(P(Parameter)) shared by these events. Thus, an element of typeP(Parameter) represents overlapping parameters of constituent events that form a single (shared)parameter in the resulting composite event.

For example, the machine depicted in Figure 6.5 is composed of the machines driver1_queue,driver2_queue, and distributor_request using the following configuration (here we use prefixesof the form ‘machine_name/’ to show from which constituent machine each event or parameter

6.4. Composition 109

is taken):{

({distributor_request/taskStm},∅),( {driver1_queue/armActionStm, distributor_request/armActionStm},

{{driver1_queue/action, distributor_request/action}}),

( {driver2_queue/handActionStm, distributor_request/handActionStm},{{driver2_queue/action, distributor_request/action}}

),

...}

The resulting composite machine is constructed in the following way. The composite ma-chine sees the contexts of all constituent specifications. In the example all constituent ma-chines see the same context, dsl_context, that implements the structural interface of the Con-stelle definition. The list of variables of the composite machine is a concatenation of (not over-lapping) lists of variables of the constituent machines: driver1_queue, driver2_queue, and dis-tributor_request_body. Possible overlapping of variables, i.e. name conflicts (for example, thevariable queue appears in two instances of the same template), are avoided via namespace exten-sion (such as driver1_queue) performed during generic instantiation of the constituent machines(see Section 6.3). The invariants of the composite machine are a conjunction of the invariants ofthe constituent machines. These transformations are captured by the following formula:

SharedEventComposition(machines, configuration) :sees = {m.sees | m ∈ machines}

variables = {m.variables | m ∈ machines}invariants = {m.invariants | m ∈ machines}

events = {ComposeEvent(ce, cp) | ce 7→ cp ∈ configuration} ∪{e ∈ m.events | m ∈ machines ∧

(¬∃ce 7→ cp ∈ configuration : e ∈ ce)}

(6.16)

Each set of synchronized events is composed into one composite event (such as armAction-Stm in Figure 6.5) using mapping ComposeEvent:

ComposeEvent : P(Event)× P(P(Parameter))→ Event (6.17)

This mapping conjuncts guards of the constituent events and concatenates actions of the con-stituent events. The parameters of a composite event are a union of the parameters of the con-stituent events with respect to shared (overlapping) parameters, such as action in armActionStm(p ∈ s | s ∈ sharedset in the following formula):

ComposeEvent(events, sharedset) :guards = {e.guards | e ∈ events}actions = {e.actions | e ∈ events}

parameters = {p ∈ s | s ∈ sharedset ∧ (∀x ∈ s · p.name = x.name)}∪ {p ∈ e.parameters | e ∈ events ∧ (¬∃s ∈ sharedset · p ∈ s)}

(6.18)

The not shared (overlapping) parameters, such as driver1_index in armActionStm, are copiedto the composite event unmodified (see the last line of Formula (6.18)). The same applies tothe not synchronized (i.e. not interacting) events of the composite machine, such as taskStm in


Figure 6.5: they are copied from the constituent machines without modifications (see the last lineof Formula (6.16)).

According to [89], the resulting composed machine is correct by construction (provided thatall proof obligations of the constituent machines are discharged). In other words, the results ofdischarging proof obligations (ensuring consistency, feasibility, and well-definedness) of the con-stituent machines can be directly extended to the composite machine (as we do not consider here amore complicated case of combining (de)composition and refinement). However, this importanttheoretical outcome does not exclude a possible incompatibility of constituent machines. For ex-ample, a shared parameter might have different (and incomparable) types in different constituentmachines. Such a situation is possible, as constituent machines are generated as instantiations oftemplate machines according to a Constelle definition. Thus, the corresponding (compatibility)checks should be performed for a Constelle definition. In our approach we delegate such check-ing to the Event-B tool support, Rodin. It identifies such incompatibilities as syntactical and typeerrors in the resulting composed machine.

6.4.2 Composition of semantic templatesAs specified earlier in formula (6.14), the Compose transformation uses (applies) shared eventcomposition in the following way:

Compose(module)(tmplts) =SharedEventComposition({t.eventbmachine | t ∈ tmplts})(config)◦ ReconstructComposedTemplate(module)

where config ={ ({x.eventbElement | x.implements = op ∧ x ∈ t.elements ∧ t ∈ tmplts},{{x.eventbElement | x.implements = dp ∧ x ∈ t.elements ∧ t ∈ tmplts}| dp ∈ op.signature

} )

| op ∈ module.interface}

(6.14 revisited)Here the resulting machine is composed of the machines of the input semantic templates (t.eventb-machine | t ∈ tmplts). The configuration of the composition (config) is derived from the interfaceof the semantic module (module), which is implemented (i.e. shared) by all semantic templates(tmplts). Namely, for each operation of the interface (op ∈ module.interface) we select from dif-ferent templates (t ∈ tmplts) specification elements (x ∈ t.elements) that implement this opera-tion (x.implements = op). Event-B elements of these specification elements (x.eventbElement)determine which events should be synchronized (i.e. composed). The configuration of sharingEvent-B parameters is derived in the same way for each dynamic parameter of the operation({x.eventbElement | x.implements = dp} | dp ∈ op.signature).

The resulting composite Event-B machine is wrapped into a semantic template using an aux-iliary transformation ReconstructComposedTemplate:

ReconstructComposedTemplate : SemanticInterface→ Machine→ SemanticTemplate (6.19)

To wrap all Event-B elements of the composite Machine, this transformation generates spec-ification elements of the resulting SemanticTemplate based on the SemanticInterface that thismachine implements. In particular (see Formula 6.20), all variables of the input machine arewrapped into PrivateElements of the output SemanticTemplate. The special Initialisation event

6.5. Gluing Guards 111

is wrapped into a PrivateElement too. All other events (e ∈ machine.events) of the machine arematched with the corresponding operations of the SemanticInterface (op ∈ si.interface∧op.name =e.name) and connected to them via PublicElements (x ∈ PublicElement). Each parameterof a machine’s event that appears in the interface (i.e. is matched with a dynamic parameterdp ∈ op.signature) is wrapped into a PublicElement. The Event-B parameters that do not havematching dynamic parameters are wrapped into PrivateElements (x ∈ PrivateElement in the lastlines of formula (6.20)).

ReconstructComposedTemplate(si)(machine) :uses ∈ {x ∈ StructuralTemplate | x.implements = dslStructure ∧

x.eventbcontext ∈ machine.sees},elements = {x ∈ PrivateElement | x.eventbElement ∈ machine.variables}

∪ {x ∈ PrivateElement | x.eventbElement ∈ machine.events ∧x.eventbElement.name = "Initialization"}

∪ {x ∈ PublicElement | op ∈ si.interface ∧ e ∈ machine.events ∧op.name = e.name ∧x.eventbElement = e ∧ x.implements = op}

∪ {x ∈ PublicElement | op ∈ si.interface ∧ e ∈ machine.events ∧op.name = e.name ∧p ∈ e.parameters ∧ dp ∈ op.signature ∧p.name = dp.name ∧x.implements = dp ∧ x.eventbElement = p}

∪ {x ∈ PrivateElement | op ∈ si.interface ∧ e ∈ machine.events ∧op.name = e.name ∧ p ∈ e.parameters ∧(¬∃dp ∈ op.signature · p.name = dp.name)

∧ x.eventbElement = p}

(6.20)

The first line of formula (6.20) makes an explicit use of the (implicit) global constant (orenvironment) that we discussed earlier in Section 6.2: the structural template that wraps an Event-B specification of the DSL constructs used in the Constelle model (i.e. an Event-B context thatintroduces the corresponding sets, relations, and axioms). This structural template implementsthe structural interface dslStructure (see Figure 6.2), which is used by all semantic modulesof the Constelle model for substituting static parameters in the invoked templates. To ensureconsistency of the resulting Event-B specification, the corresponding Event-B context should beused by the generated composite machine (x.eventbcontext ∈ machine.sees).

6.5 Gluing GuardsThe final step of the transformation ExpandDefinition (6.2) adds gluing guards (i.e. instantiatedconstraint templates) to the specification of the semantic module using the transformation Glue-


Operations (third line of formula (6.3) reappearing here):


)

◦ GlueOperations(module.gluingGuards, lib ∩ ConstraintTemplate)(6.3 revisited)

GlueOperations takes a set of gluing guards (which are realized in Constelle as Constraint-Invocations) and a set of ConstraintTemplates (that provide concrete predicates, see Figure 6.2)and applies them to a SemanticTemplate:

GlueOperations : P(ConstraintInvocation)× P(ConstraintTemplate)

→ SemanticTemplate→ SemanticTemplate(6.21)

The resulting SemanticTemplate has its aspects glued together by extra predicates that link dy-namic parameters of (within) their operations. For this, GlueOperations adds extra Event-Bguards to the events of the Event-B machine of the SemanticTemplate. To represent such a mod-ification of the underlying Event-B machine in a precise manner, we use the Event-B refinementtechnique.

6.5.1 RefinementRefinement is an Event-B language construct that establishes a relation between two Event-B machines, where a concrete machine refines an abstract machine. Refinement allows forthe gradual introduction of details into an Event-B specification by modifying or adding newvariables and events [4]. A concrete machine can have a completely different (from an abstractmachine) set of variables, invariants, events, guards, and actions; or the concrete machine canadd new variables, invariants, events, guards and actions to the abstract machine; or the concretemachine can modify the elements of the abstract machine partially. Independent from a particulartype of modification, the concrete machine should obey (conform to) the behavior specified inthe abstract machine. In other words, both the abstract and concrete machines should specifythe same behavior (or system), but at different levels of detail. This is ensured whenever thecorresponding proof obligations generated for all refinement relations are discharged.

To define the GlueOperations transformation, we use a small subset of the refinement capa-bilities. In particular, we use refinement only to add new guards to the events of a machine:

Refinementguards : Machine→ P(Event× P(Guard))→ Machine (6.22)

Here the configuration P(Event×P(Guard)) indicates which guards (P(Guard)) should be addedto which events (Event × ...). No other modifications of the input machine are possible withinRefinementguards.

Figure 6.6 shows an example of Refinementguards applied to the Event-B machines generatedfor (and from) the semantic module LACE_Core_SF, defined in the previous chapter in Table 4.4.The LACE_Core_SF_interm machine depicted in Figure 6.6(a) is generated using SharedEvent-Composition (6.16) from the machines instantiated for the following three aspects of the LACE_Core_SF semantic module: LAC: Request, curr_la: Query, and SS1: Queue. The prefixes ofthe Event-B elements in Figure 6.6 determine their origin: for example, lac_request_body is thevariable of the Request template instantiated for the LAC aspect.

The Event-B machine depicted in Figure 6.6(b) adds gluing guards to the composite ma-chine depicted in Figure 6.6(a), such as, glue_grd1 in the event request_la. This modifica-tion is performed within refinement of the machine LACE_Core_SF_interm by the machineLACE_Core_SF (see the sections ‘refines’).

6.5. Gluing Guards 113

MACHINE LACE Core SF interm

SEES lace core context

VARIABLESlac request body, curr la variable, ss1 queue

INVARIANTS

lac inv1 : lac request body ∈ P(Occurrence)

curr la inv1 : curr la variable ∈ LogicalActions

ss1 inv1 : ss1 queue ∈ N 7→ (SS1)

EVENTS...

Event request la =

any la, curr job

wherelac grd1 : curr job ∈ P(Occurrence)lac grd2 : lac request body = ∅curr la grd1 : la ∈ LogicalActionsthenlac act1 : lac request body := curr jobcurr la act1 : curr la variable := la

end

...

(a) Machine composed of the constituent aspects

MACHINE LACE Core SF

REFINES LACE Core SF interm

SEES lace core context

VARIABLESlac request body, curr la variable, ss1 queue

INVARIANTS

lac inv1 : lac request body ∈ P(Occurrence)

curr la inv1 : curr la variable ∈ LogicalActions

ss1 inv1 : ss1 queue ∈ N 7→ (SS1)

EVENTS...

Event request la =

refines request la

any la, curr job

wherelac grd1 : curr job ∈ P(Occurrence)lac grd2 : lac request body = ∅curr la grd1 : la ∈ LogicalActionsglue grd1 : curr job = dom(LALabelDef(la))

thenlac act1 : lac request body := curr jobcurr la act1 : curr la variable := la

end

...

(b) Machine with the gluing guard

Figure 6.6: Fragment of the LACE_Core_SF machine

6.5.2 Gluing operationsThe transformation GlueOperations uses the mapping Refinementguards to add gluing guardsto the events of the machine representing (wrapped into) the semantic template that we con-struct for our semantic module. However, the gluing guards that are added to the machine areEvent-B predicates (EventBNamedCommentedDerivedPredicateElements, see Figure 6.2), whilethe gluing guards that appear in the Constelle definition of the semantic module are Constraint-Invocations. To translate ConstraintInvocations into the proper Event-B predicates, we need to un-fold each ConstraintInvocation, that is: to find a ConstraintTemplate that implements the invokedConstraintInterface and to substitute its InterfaceElements according to the InterfaceElement-Substitutions of the ConstraintInvocation. In other words, we unfold ConstraintInvocations forgluing guards in the same way as we unfold TemplateInvocations for aspects.

The following formula describes the transformation GlueOperations, including the details of


the invocation of ConstraintTemplates.

GlueOperations(constrset, lib)(tmplt) :uses = tmplt.uses,

elements = tmplt.elements,

implements = tmplt.implements,

eventbmachine = Refinementguards(tmplt.eventbmachine)({el.eventbelement 7→ grds(el) | el ∈ tmplt.elements ∧

el.implements ∈ Operation})

where grds(el) = {SubstituteConstraint(ci)(ct) | ci ∈ constrset ∧ ct ∈ lib ∧ci.restricts = el.implements ∧ ci.invokes = ct.implements}

(6.23)

Here only the Event-B machine of the input semantic template (tmplt.eventbmachine) isupdated using the Refinementguards mapping. To construct the configuration of Refinementguards,we go through all specification elements that implement an operation of the semantic module:{... | el ∈ tmplt.elements ∧ el.implements ∈ Operation}. Each of these elements referencesan event of the underlying Event-B machine, and this event is taken as a part of the refinementconfiguration (el.eventbelement 7→ ...).

For the operation referenced by the specification element (el.implements) we select Constraint-Invocations from the input set of gluing guards (constrset): ci ∈ constrset ∧ ci.restricts =el.implements. For each of this ConstraintInvocations (ci) we find in the input library of tem-plates (lib) the corresponding ConstraintTemplate: ct ∈ lib ∧ ci.invokes = ct.implements. TheEvent-B predicate for the refinement configuration is constructed using an auxiliary mappingSubstituteConstraint: {SubstituteConstraint(ci)(ct) | ...}. This mapping substitutes Interface-Elements in the ConstraintTemplate (ct) according to its ConstraintInvocation (ci) and generatesthe corresponding Event-B predicate:

SubstituteConstraint : ConstraintInvocation→ ConstraintTemplate

→ EventBNamedCommentedDerivedPredicateElement(6.24)

The substitution of InterfaceElements in a ConstraintTemplate is performed in (almost) thesame way as it is done for the SemanticTemplates as described in Section 6.3. In particular, wefirst compose the renaming scheme using the mapping ComposeRenaming (6.9), and then useits output to instantiate the Event-B predicate in the mapping InstantiateEventBPredicate:

SubstituteConstraint(inv, tmplt) =ComposeRenaming("")(inv.elementsSubstitution, tmplt.elements ∪ tmplt.uses.elements)

◦ InstantiateEventBPredicate(tmplt.eventbpredicate)(6.25)

The mapping InstantiateEventBPredicate simply replaces entries of the Event-B elements inthe predicate with the new names. The transformation is described by the following signature:

InstantiateEventBPredicate :

EventBNamedCommentedDerivedPredicateElement→(EventBNamedCommentedElement 7→ String)→EventBNamedCommentedDerivedPredicateElement

(6.26)

6.6. Proof Obligations 115

Note, that when composing the renaming scheme in the SubstituteConstraint mapping, we usean empty namespace (ComposeRenaming("")). This is possible because a ConstraintTemplatedoes not have PrivateElements, i.e. it does not encapsulate any Event-B element (parameter,set, or constant) appearing in the template predicate, but rather explicitly lists all of them in itsConstraintInterface.

6.6 Proof ObligationsIn this section we discuss proof obligations (POs) of the Event-B specification generated from aConstelle model by the Constelle-to-Event-B model transformation. Proof obligations determinewhat should be proven for an Event-B specification in order to ensure that the specified (system)design is consistent, feasible, and complete. Discharging (i.e. proving) such proof obligations re-alizes the semantic analysis of an Event-B specification in a static manner (i.e. it does not requirean execution of the specification). Proof obligations are generated for each Event-B specificationaccording to the set of proof obligation rules, which constitute a part of the mathematical model(theory) of Event-B (i.e. the dynamic semantics of Event-B) [2].

One of the key features of a specification template (as defined in Section 4.2) is the possibilityto reuse its verification results. That is, if we have discharged proof obligations for an Event-Bspecification template, we do not need to discharge them again for the Event-B specificationthat is constructed using this specification template. To implement this feature of a specificationtemplate in Constelle, we base our definition of the Constelle-to-Event-B semantic mapping onthe Event-B∗ techniques that include a mathematical reasoning (theorems) of how proof obliga-tions can be reused. In this section we provide the details of this approach. For this we identifywhich proof obligations can be ignored and which proof obligations should be discharged forthe Event-B specification generated by the Constelle-to-Event-B model transformation. Notethat we do not construct such proof obligations from scratch, but we rather select them from the(existing) set of POs generated by the Rodin tools. Moreover, we identify subsets of POs (POsthat can be ignored and POs that should be discharged) in terms of a Constelle model; that is wemap elements (i.e. identifiers) of the input Constelle model onto (labels/identifiers of) POs of theoutput Event-B machine.

6.6.1 Event-B proof obligation rulesAs mentioned above, the mathematical model of Event-B defines a set of PO rules [2]. Usingthese rules, one of the Rodin tools (PO generator) generates POs for each concrete Event-Bmachine (and context) [43, 34]. These POs are then sent to the Rodin provers for automatic orinteractive proving. Table 6.1 gives an overview of different types of Event-B PO rules.

Each PO of an Event-B specification is identified (labeled) by its type (an abbreviation inthe left-most column of the table) and by the (tuple of) Event-B constructs for which this POhas been constructed (the PO domain in the right-most column of the table). For example, a POlabeled as armActionStm/driver1_inv1/INV is a PO that ensures that the invariant driver1_inv1is preserved by the event armActionStm (for the Event-B machine robotic_arm_parallel depictedin Figure 6.5).

The INV PO ensures that each invariant is preserved by each event, that is, the invariant stillholds after the event is executed. This should be proven based on (derived from) the axioms andtheorems of the Event-B context, the invariants and theorems of the Event-B machine, the guardsof the event, and the before-after predicate composed out of the assignment expressions of the


Table 6.1: Overview of different types of proof obligations for an Event-B machine

Type Description Domain

INV Each invariant is preserved by each event Event × Invariant

WD An expression is well definedAxiom ∪ Invariant

∪ Event × Guard

∪ Event × Action

THM A theorem is provableAxiom ∪ Invariant

∪ Event × Guard

FIS A non-deterministic action is feasible Event × Action

GRDGuards of a concrete event are strongerthan the guards of the abstract event

Event × Guard

SIMActions of an abstract event aresimulated in the concrete event

Event × Action

EQLThe values of the abstract and concretevariables with the same names are equal

Event × Variable

event’s actions. This type of PO is generated (defined) for each couple of the machine’s eventsand invariants: Event × Invariant.

A WD PO ensures that all Event-B expressions are well defined, that is, that the mathematicallanguage of set theory and first-order logic (employed by Event-B) is used properly. For example,if we use a function application f(x) and f is a partial function, then f should be defined for x,that is, we need to prove that x ∈ dom(f). A potential division by zero is also checked by a WDPO. The WD POs are generated for (potentially ill-defined) elements of an Event-B specificationthat include an expression: axioms, invariants, guards, and actions.

The POs shown in the bottom part of Table 6.1 (under the double line) are related to therefinement of Event-B machines. Note that, in this table we omit PO kinds that are not relevantfor our work as we do not use (and do not discuss in this thesis) the corresponding Event-Bconstructs. For example, we do not use variants in our Event-B machines and, therefore, wedo not consider termination POs, such as: VAR (each convergent event decreases the proposedvariant), or VWD (a variant is well defined). When applying refinement, we do not use witnessesand merged events and, thus, do not list POs determined by these Event-B constructs, such as:WWD (a witness is well defined), or MRG (the guard of a concrete event merging two abstractevents is stronger than the disjunction of the guards of the abstract events).

6.6.2 Constelle proof obligation rulesIn our library of reusable specification templates each template captures a common software (de-sign) solution in the corresponding Event-B specification. As a successful and reusable piece ofcode, such a specification should be consistent and well defined, that is all POs of the correspond-ing Event-B machine (and the used context) should be discharged. To avoid re-proving thesePOs, we identify what happens with them through GenericInstantiation (6.11), SharedEvent-Composition (6.15), and Refinementguards (6.22), which are applied to the Event-B machines ofthe specification templates invoked in a Constelle semantic module.

To capture the results of this process for each of the transformations ExpandDefinition (6.3),

6.6. Proof Obligations 117

Substitute (6.5), Compose (6.14), and GlueOperations (6.23) we extend their functions of theform f : X → Y with the corresponding functions POf : X → P(PO). Such an (extension)function indicates which POs (i.e. a subset of the generated PO set) should be discharged by theuser for the Event-B machine generated for (from) a Constelle semantic module. In other words,we indicate the relevant POs and can ignore all other POs generated for this Event-B machine. Toindicate a PO, we use a tuple consisting of the PO type (left-most column in Table 6.1) and Event-B constructs of the corresponding PO domain (right-most column in Table 6.1). For example,the tuple (INV, armActionStm, driver1_inv1 ) indicates the INV PO generated for the invariantdriver1_inv1 and the event armActionStm.

6.6.2.1 Substitution

As mentioned earlier in Section 6.3.3, an Event-B machine constructed from another machineusing GenericInstantiation is correct by construction. In other words, all POs of a generic ma-chine can be reused in the instantiated machine. This theoretical result is proved by Silva inhis PhD dissertation [87], see Section 3.3.4. However, the reuse of POs is possible only if thefollowing condition holds: the structural properties of the generic sets and constants substitutedas the result of the generic instantiation should hold for concrete sets and constants substitutingthe generic ones. Such structural properties are defined in the axioms of the context used by thegeneric machine.

To ensure the described condition, the transformation GenericInstantiation (6.11) introducesnew POs – theorems formed on the basis of generic axioms by substituting generic sets andconstants with concrete sets and constants. The following formula identifies such POs in thecontext of the mapping Substitute (6.5), that applies (invokes) generic instantiation.

POSubstitute(inv)(tmpl) ={(THM,

ComposeRenaming(inv.name)(inv.elementsSubstitution, tmpl.uses.elements)

◦ InstantiateEventBPredicate(a)) | a ∈ tmpl.eventbmachine.sees.axioms}

where POSubstitute : TemplateInvocation→ SemanticTemplate→ P(PO)

(6.27)

Here POSubstitute takes the same input as the mapping Substitute and constructs a set of POsthat should be proved in order to reuse POs of the SemanticTemplate that is being substitutedin the Substitute mapping. These are the THM POs (theorems), constructed by instantiating(InstantiateEventBPredicate) axioms of the Event-B context which is used by the machine of thesemantic template (a ∈ tmpl.eventbmachine.sees.axioms). The instantiation follows the samerenaming scheme as the instantiation of the semantic template (ComposeRenaming(inv.name)(inv.elementsSubstitution, tmpl.uses.elements) – compare formulas (6.5) and (6.27)).

6.6.2.2 Composition

A composite Event-B machine constructed from constituent machines using SharedEventComposi-tion is correct by construction. According to the proofs by Silva in his PhD dissertation [87] (seeSection 2.3.3) POs of the kinds INV, FIS, and WD of constituent machines can be directly reusedin the composite machine. The reasoning for the reuse of THM POs is analogous to the reason-ing behind the reuse of WD POs: if no new invariants are introduced in the composite machine,then all theorems in invariants and guards are proved (individually) for each constituent machine.However, refinement POs should be re-proved for a composite machine.

The reuse of POs in a composite machine does not require any additional POs. Therefore,considering that an (intermediate) composite machine generated during the Constelle-to-Event-B


transformation does not refine any other Event-B machine, we define the corresponding mapping(or Constelle PO rule) POCompose by the following formula:

POCompose(si)(tmplts) = ∅

where POCompose : SemanticInterface→ P(SemanticTemplate)→ P(PO)

(6.28)

6.6.2.3 Gluing guards

The transformation GlueOperations (6.23) applies the mapping Refinementguards, which doesnot change anything in the underlying Event-B machine, but only adds a refinement relationshipand new guards to its events. Thus, we deduce that the set of POs of the resulting machineconsists of the POs of the original machine, the POs related to the refinement relationship, andthe POs defined (generated) for the added guards. In other words, the POs of the intermediate(i.e. composite) machine can be reused in the modified (final) machine. The new (additional) POsintroduced by GlueOperations can be considered as two separate groups: POs for the refinementand POs for gluing guards.

We consider three kinds of refinement POs: GRD, SIM, and EQL (other types of refinementPOs do not apply due to our way of using refinement). Each of these POs can be proved easilybecause of our way of using refinement.

For example, the GRD PO ensures that concrete guards in a concrete event are stronger thanthe abstract guards in an abstract event. This is required for the abstract event to be enabled if theconcrete event is enabled. In the mathematical model of Event-B this PO rule is described usingthe following form: A∧ Iabstract∧ Iconcrete∧Gconcrete∧W ` Gabstract – which means that guards ofan abstract event (Gabstract) should be derived (`) from axioms (A) specified in the context used(seen) by the concrete machine, invariants of the abstract machine (Iabstract), invariants of theconcrete machine (Iconcrete), guards of the concrete event (Gconcrete), and witnesses for parameters(W , not used in our transformation). As Refinementguards only adds new guards, we concludethat Gabstract ⊆ Gconcrete and thus the GRD PO rule is proved. The same reasoning applies to theSIM PO rule: A∧Iabstract∧Iconcrete∧Gconcrete∧W ∧BAconcrete ` BAabstract – where BA stands forbefore-after predicate of the event’s actions (which are copied unchanged in Refinementguards).

The EQL PO considers a situation when the abstract and the concrete machine use the samevariable and the concrete machine updates this variable in an action that does not exist in theabstract machine. Clearly, this situation does not apply to the mapping Refinementguards, as allactions are copied unchanged from the abstract machine to the concrete machine.

The POs for gluing guards can be identified by choosing PO kinds from Table 6.1 that arerelated to Event-B Guards. These are WD and THM POs. As we do not introduce gluing guardsas theorems, the only type of POs that is left is WD. The following formula specifies how thesePOs are identified in the context of the mapping GlueOperations, which substitutes Constraint-Templates into gluing guards and adds them to the events of the underlying machine.

POGlueOperations(constrset, lib)(tmplt) ={(WD, el.eventbelement, g) | el ∈ tmplt.elements ∧ el.implements ∈ Operation

∧ g ∈ grds(el)}

where POGlueOperations : P(ConstraintInvocation)× P(ConstraintTemplate)→SemanticTemplate→ P(PO)

(6.29)

6.7. Conclusions 119

According to this formula, the output WD POs are identified for the Operations of the se-mantic module paired with the ConstraintInvocations that restrict them. The semantic moduleis implemented by the input argument ‘tmplt’, thus, its elements el ∈ tmplt.elements link theoperations of the semantic module with the corresponding events of the underlying Event-B ma-chine: el.implements ∈ Operation. Therefore, we use el.eventbelement as a second element ofa PO tuple. Each ConstraintInvocation is unfolded and substituted into an Event-B guard usingthe mapping SubstituteConstraint (third element of the PO tuple). The scheme of its applicationhere (ci, ct) is the same as in the definition of GlueOperations given in (6.23).

For example, the Event-B machine depicted in Figure 6.6(b) is generated for (from) thesemantic module LACE_Core_SF defined in Table 4.4 on page 69. This semantic module uses agluing guard to restrict its operation request_la:

curr_job = dom(LALabelDef(la))

Let’s assume that in the Constelle model this gluing guard is realized by the ConstraintInvocationx. Then we select the Event-B guard generated from this ConstraintInvocation by applying themapping SubstituteConstraint to x:

y = SubstituteConstraint(x)(t), t ∈ lib ∧ x.invokes = t.implements

As a result, out of all guards of the event request_la (depicted in Figure 6.6(b)) we select y =glue_grd1. After indicating this Event-B guard, we can indicate the PO that should be dischargedfor the original gluing guard: (WD, request_la, glue_grd1). This PO checks if the expressioncurr_job = dom(LALabelDef(la)) is well defined.

6.6.2.4 Proof obligations for a Constelle semantic module

All the POs identified above for the intermediate steps of the Constelle-to-Event-B transforma-tion constitute the set of POs that should be discharged for a semantic template (i.e. Event-Bmachine) generated by this transformation (i.e. ExpandDefinition). In particular, the POSubstituteare constructed (as theorems in auxiliary Event-B contexts) for all aspects of an input semanticmodule and POGlueOperations are identified for all gluing guards of the semantic module. Thecorresponding definition is captured in the following formula.

POExpandDefinition(lib)(module) ={po ∈ POSubstitute(a, t) | a ∈ module.aspects ∧ t ∈ lib ∧

t.implements = a.invokes}

∪ POGlueOperations(module.gluingGuards, lib ∩ ConstraintTemplate, impl)

where impl ∈ SemanticTemplate ∧ impl.implements = module;POExpandDefinition : P(SemanticTemplate)→ SemanticModule→ P(PO)

(6.30)

Here, the auxiliary variable ‘impl’ represents an (intermediate) implementation of the seman-tic module (module) constructed during the transformation ExpandDefinition.

6.7 ConclusionsIn this chapter we gave a precise and executable definition of the semantic mapping of Constelleto Event-B. This definition allows for achieving the following three results.


1. The precise definition documents and explains the semantic mapping in a clear way, whichis crucial for understanding and maintenance (evolution) of the semantics of Constelle.

2. The precise definition provides a transparent description of how Constelle applies theEvent-B∗ techniques, which allows for optimizing the verification of the resulting Event-B machine by reusing proof obligations that are already discharged for the specificationtemplates invoked in the Constelle model.

3. The executability of the definition is achieved by implementing the Constelle-to-Event-Bmodel transformation according to the given definition, which is possible because of align-ing the mathematical notation with QVTo constructs described in the previous chapter.

The Constelle-to-Event-B model transformation (semantic mapping) generates an Event-Bmachine for each semantic module of a definition of the dynamic semantics of a DSL. Thismachine can be analyzed and animated using the Rodin tool set. In this way, the Constelle-to-Event-B transformation fulfills the requirement Req-1 formulated in Chapter 2: a definition ofthe dynamic semantics of a DSL should allow for the implementation of various use cases, suchas verification and validation of the DSL design, and simulation of DSL programs.

The generated Event-B machine is wrapped into a specification template, which allows forconstructing new specification templates from existing ones, and thus fulfills the requirementReq-4: the definition formalism should allow for the introduction and invocation (by using itsconstructs in a semantic mapping) of an additional (new) semantic domain.

The Constelle-to-Event-B model transformation generates Event-B machines wrapped intospecification templates for all possible Constelle models (allowed by the Constelle metamodel).In other words the transformation fulfills the requirement Req-7: the automatic generator shouldbe DSL-independent and configured according the definition of the dynamic semantics of a DSLthat has been constructed on the metamodel level.

In the next chapter we provide the implementation details of the Constelle-to-Event-B modeltransformation and discuss how it can fit into the process of designing and developing a DSL.Moreover, we set up a controlled experiment to validate the language, process, and tool supportprovided by Constelle.

Chapter 7

Implementation and Pragmatics of Constelle

Deep Blue: Bishop to knight 4.Gore: Not all missions can be solved with chess, Deep Blue.Someday you’ll understand that.

Futurama, Season 2, Episode 20

In this chapter, we present the implementation of the proposed approach of defining the dy-namic semantics of a DSL using specification templates and Constelle. In particular, we addressthe following (design and research) questions.

• How to organize the implementation of Constelle so that it supports the use cases that weproposed in Chapter 4?

• How to use Constelle for defining the dynamic semantics of a DSL? What process shoulda DSL developer follow in order to define the dynamic semantics of his/her DSL usingConstelle?

The first of the listed questions is addressed in Section 7.1, where we describe the architectureof the (prototype) implementation of Constelle. Based on this description, we formulate aniterative process of defining the dynamic semantics of a DSL using specification templates andConstelle (Section 7.2). To explain the process in detail and to demonstrate how the use casesproposed in Chapter 4 can be realized using our implementation, in Section 7.3 we present thetool set that supports our approach.

7.1 ArchitectureWe implement Constelle following its definition presented in Chapters 4 and 6. In order tocombine the formats (i.e. bridge the platforms) of the Event-B formalism and of an arbitraryDSL, we use MDE techniques. In particular, we fit all the components of our implementationtogether using the Ecore format of Eclipse Modeling Framework (EMF)1. To reference Event-B

1www.eclipse.org/modeling/emf

www.eclipse.org/modeling/emf

122 Implementation and Pragmatics of Constelle

specifications we use the (Ecore) metamodel of the Event-B formalism provided by the EMFframework for Event-B, the Rodin plug-in2. A DSL is represented by the Ecore metamodelthat captures the domain model and/or the abstract syntax of the DSL. The Ecore metamodelsof Constelle and of a specification template are constructed according to their definitions givenin Chapter 4. The semantic mapping of Constelle to Event-B is implemented in the form ofthe QVTo3 model transformation that uses these Ecore metamodels as the types of its input andoutput. An overview of our implementation is presented in Figure 7.1.

Meta-model(dsl.ecore)

DSL model(model.dsl)

Event-Btemplates

(library.eventb)

Event-Bspecification

(model.eventb)

DSL Rodin platform

Specification templates

(library.constellecore,impl.templateslibrary)

Semantics definition(dsl.constelle)

execution of Constelle-to-Event-B

Constelle DSL(Constelle.ecore)

Event-B formalism(eventb.ecore)

Constelle-to-Event-Bmodel transformation

composed of

instance of

uses

Constelle workbench

legend

Event-Bspecification(dsl.eventb)

execution of Constelle-to-Event-B

Figure 7.1: The architecture of the Constelle implementation

The key components of our implementation (Figure 7.1, on the top) are the Constelle DSL,which comprises the metamodels of a specification template and of Constelle (defined in Chap-ter 4), and the Constelle-to-Event-B model transformation, which follows the definition given inChapter 6. The library (in the middle) includes both semantic interfaces (library.constellecore)and specification templates (impl.templateslibrary), which implement these semantic interfacesin the form of Event-B code (library.eventb on the right). The dynamic semantics of a DSL isdefined in Constelle as a composition of the semantic interfaces (dsl.constelle), which are spe-cialized using the DSL constructs introduced by the DSL metamodel (dsl.ecore on the left). Theexecution of the Constelle-to-Event-B model transformation uses this definition to automaticallygenerate the corresponding Event-B specification (dsl.eventb).

The bottom part of Figure 7.1 is related to the possibility to extend the current Constelle-to-Event-B model transformation, so that we can generate Event-B specifications not only for

2wiki.event-b.org/index.php/EMF_framework_for_Event-B3projects.eclipse.org/projects/modeling.mmt.qvt-oml

wiki.event-b.org/index.php/EMF_framework_for_Event-B

projects.eclipse.org/projects/modeling.mmt.qvt-oml

7.2. Definition Process 123

the DSL metamodel, but also for (from) DSL models. For example, in our definition of theLACE DSL (see Table 4.4 on page 69) we use the placeholder SS1 to represent an arbitrarysubsystem, to define the dynamic semantics of LACE on the metamodel level. However, onthe model level, a LACE program can include multiple subsystems (see for example Figure 2.3on page 14). Thus, an Event-B specification for a LACE program should be composed out ofmultiple instances of the SS1 aspect – a separate instance for each of the (concrete) subsystemsparticipating in the LACE program. We can achieve this by updating the Substitute and Composesteps of the Constelle-to-Event-B model transformation. We foresee no (technical) difficulties inimplementing such an extension and we leave it for future work.

Another extension point of our architecture, that follows from our vision presented in Chap-ter 3, is the possibility to have multiple back-end formalisms and/or platforms. In Figure 7.1 wedepict this as multiple components representing the Rodin platform (on the right of Figure 7.1).As described in Chapter 3, such a target formalism and/or platform can be C-code or BMotionStudio visualization.

7.2 Definition ProcessFollowing our general idea to not only give an explicit definition of the dynamic semantics of aDSL, but also to bridge various technological platforms (as introduced in Chapter 3), Constelleuses (bridges) different technologies. In particular, our implementation of Constelle includesartifacts of very different natures: multiple Ecore metamodels, Event-B specifications, and QVTomodel transformations. Therefore, in order to explain the role of each of these artifacts and torelate them with each other, we formulate the process of defining the dynamic semantics of aDSL using specification templates and Constelle. This process is defined using the notation ofUML activity diagrams, depicted in Figure 7.2.

In Figure 7.2 the activities that use and update the structure of a DSL are depicted in theright column (swimlane). In a Constelle model the structure of a DSL (the DSL metamodel orabstract syntax) is represented by the structural template (Event-B context and the correspondingstructural interface) that captures the DSL constructs and relationships between them. We needto prepare such a structural template before we start defining the dynamic semantics (step (0) inFigure 7.2). However, we might need to add extra constructs (types, constants, or relations) tothis structure during the definition process (step (5.b)). For example, if we decide to restrict thecapacity of buffers that are used in the example DSL of Robotic Arm by n = 5 (which means,that we cannot store more than 5 actions in a driver’s buffer); then we need to introduce thecorresponding constant n and add it to the (global) structural template of the DSL, so that wecan use it in our Constelle model. Note that we do not consider a more sophisticated situation ofthe DSL evolution, when the metamodel and/or the dynamic semantics of the DSL change, forexample, as a result of receiving feedback from applying the DSL in practice.

The activities related to the specification of the dynamic semantics of the DSL are shownin the left column of Figure 7.2. We start from gathering (obtaining) the information about thedynamic semantics of the DSL (step (1)). This preparatory work can include brainstorming (incase we create a DSL from scratch), examining existing documentation and implementation (incase we define the dynamic semantics of an existing DSL), interviewing existing or potentialend-users of the DSL, etc. The collected information will be formalized in the definition of thedynamic semantics of the DSL.

As a second step, we identify semantic modules, i.e. decompose the dynamic semantics of theDSL. For example, in our LACE case study (described in Chapter 2) we identified the followingsemantic modules: semantic features (Core SF, Scan SF, Order SF, and Data SF) and architecture


Specification of the dynamic semantics of the DSL Specification of the DSL structure

«parallel»

0. Prepare the

structural interface and template

that capture constructs

of the DSL (metamodel)

1. Gather information about

the dynamic semantics of the DSL

2. Identify semantic modules

(decompose the dynamic semantics)

semantic modules

3. Construct an Event-B

specification

4. Derive semantic and structural

interfaces

5.b. Add static parameters

to the DSL structure

[no]

[the module can

be decomposed]

5.a. Compose the dynamic semantics

out of the specified semantic modules

6. Generate Event-B specification

of the dynamic semantics

7. Validate (run/analyze)

the generated Event-B specification

[the definition

can/should

be improved/

extended]

[the definition is

satisfactory]

[Structural interfaces of

all aspects can be substituted]

[no]

semantic templates

[the module is

a template

in the library]

Figure 7.2: The process of defining the dynamic semantics of a DSL using Constelle

components (SS and LAC). Then we consider each of the semantic modules in parallel withothers: in Figure 7.2 the corresponding steps are visualized in the expansion region (dashedrounded rectangle) with the keyword «parallel».

If a semantic module can be decomposed into smaller semantic modules, then we return

7.3. Constelle Workbench 125

to the decomposition step. If we can find in the library a specification template that realizesthis semantic module, then we can proceed with other semantic modules or to the next step ofthe definition process. Otherwise, each semantic module is specified in Event-B (step (3)) andwrapped into a specification template using the corresponding structural and semantic interfaces(step (4)). Note, that during step (3) we might realize that we can decompose the semanticmodule and, therefore, return back to the preceding decision node: the process is not a strict setof rules, but rather a recommendation on how to use Constelle.

After we have constructed (or found in the library) Event-B specifications and interfaces forall semantic modules identified earlier, we can compose them together in a Constelle table (step(5.a)). At this stage we might need to add missing static parameters to the structural template ofthe DSL (step (5.b)). From a Constelle model (visualized as a table) we automatically generatethe corresponding Event-B specification (step (6)) and use it to validate the defined (formalized)dynamic semantics of the DSL (step (7)). The feedback collected as the result of such a validationcan lead us back to step (1), i.e. trigger another iteration of defining the dynamic semantics ofthe DSL.

Note that the steps (1)-(7) can also be performed not for the whole dynamic semantics ofthe DSL, but for one of its semantic modules. In other words, we first decompose the dynamicsemantics into coarse-grained modules, and then consider them in separate iterations and de-compose into more fine-grained semantic modules (i.e. follow the steps (1)-(7) for each of thecoarse-grained modules). This facilitates scaling the approach. For example, in our LACE casestudy (described in Chapter 2), we consider each of the LACE semantic features in a separateiteration, decomposing its specification into architectural components. Thus, we first specify SSand LAC for Core SF, then SS and LAC for Scan SF, and so on.

7.3 Constelle WorkbenchThe process described in the previous section uses various tools: those that already exist (suchas Rodin and EMF) and those that we have developed specifically for Constelle (such as theConstelle-to-Event-B model transformation). The set of tools that we developed for Constelleis referred to as the Constelle workbench in Figure 7.1. The Constelle workbench supports the(automatic) creation of specification templates on the basis of Event-B specifications, editing ofa Constelle definition in the form of the table notation, and automatic generation of the corre-sponding Event-B specifications. To implement this tool set, we employed the following MDEtechniques provided in the Eclipse platform: Ecore metamodeling tools (EMF), the QVTo modeltransformation language, Xtext text editor framework4, and the Sirius graphical editor genera-tor5.

In this section we introduce the Constelle tools and explain how they contribute to the processof defining the dynamic semantics of a DSL described in the previous section. In particular, step(0) is discussed in Section 7.3.1. Steps (1)-(2) are informal and do not have any tool support. Thetools that support steps (3)-(4) are described in Section 7.3.2. In Section 7.3.3 we describe theConstelle editor for step (5) of the definition process. Section 7.3.4 gives an overview of steps(6)-(7).

4www.eclipse.org/Xtext5www.eclipse.org/sirius

www.eclipse.org/Xtext

www.eclipse.org/sirius


7.3.1 Structure definitionWe assume that when we start defining the dynamic semantics of a DSL, the structure of theDSL is already defined (in the form of an Ecore metamodel). In practice, however, the DSLmetamodel might evolve along with the definition of the dynamic semantics. We believe thatit is a natural process and do not see restrictions for using an evolving DSL metamodel. Incontrast, we strive to build the Constelle workbench in such a way that it does not depend on afinal version of the DSL metamodel, but rather facilitates working with a changing metamodel.For example, we provide the Ecore-to-Structure model transformation that constructs a structuralinterface from an Ecore metamodel automatically. Every time the DSL metamodel is updated,we run the Ecore-to-Structure transformation to generate the corresponding structural interface,so that we can use this new version in the definition of the dynamic semantics in Constelle.

Figure 7.3 demonstrates an example of an Ecore metamodel and the corresponding structuralinterface generated for (from) it. The Ecore metamodel of the Robotic Arm DSL (an exampleintroduced in Chapter 4) is shown in the EMF tree editor (tab ‘roboticarm.ecore’ on the left).The structural interface generated from this metamodel is shown in the tree editor in the tab‘roboticarm_struct.constelle’ on the right. The Ecore-to-Structure transformation that generatessuch a structural interface from an Ecore metamodel is quite straightforward:

• classes and data types are transformed into types (such as Task and Actions in Figure 7.3),

• references and attributes of classes are transformed into relations (such as program andparameters in Figure 7.3),

• enumeration literals are transformed into constants (such as turnright and turnleft in Fig-ure 7.3).

The mapping realized by the Ecore-to-Structure transformation is saved in a set of elementsMetamodel Element Substitution (highlighted in the tab ‘roboticarm_struct.constelle’ on the rightof Figure 7.3). Each Metamodel Element Substitution connects (links) an element of the struc-tural interface with the corresponding element of the Ecore metamodel. For example, the tab‘Properties’ on the bottom of Figure 7.3 shows the link generated for the structural element Ac-tions: the property Actual references the Ecore class Actions and the property Formal referencesthe Constelle type (i.e. static parameter) Actions.

7.3.2 Specification templatesIn order to construct a specification template, we first construct an Event-B specification andthen wrap it into the corresponding template interface. This applies to all types of specificationtemplates: structural, semantic, and constraint templates. For example, Figure 7.4 shows (thefragment of) the Event-B specification of the Queue template (described in detail in Chapter 4).This specification is constructed using the Event-B editor provided by the Rodin platform (itsscreen-shot is depicted in Figure 7.4). The Rodin tool set generates proof obligations (POs) forthis specification (depicted on the left in Figure 7.4) and runs automatic provers to dischargethose. All proof obligations in Figure 7.4 are highlighted in green color, which means that theyall have been successfully discharged.

After specifying our template in Event-B, we continue with step (4) and define an interfacefor the template. For this we use the textual editor that we have developed within the Constelleworkbench. Figure 7.5 depicts a screen shot of a set of different template interfaces defined inour textual editor.


Figure 7.3: Screen shot of the Ecore metamodel of the example DSL

In order to connect the Event-B specification and the (semantic, or structural, or constraint)interface through a corresponding specification template, we execute the Event-B-to-Templatemodel transformation. This transformation matches Event-B elements with interface elementsby their names and generates intermediate elements of the specification template to connect them(i.e. to wrap the Event-B code into the interface). For example, the operation enqueue of thesemantic interface template_queue from Figure 7.5 is matched with (connected to) the eventenqueue of the machine template_queue_machine depicted in Figure 7.4.

7.3.3 Constelle editorThe constructed specification templates are composed together to form the definition of the dy-namic semantics of a DSL. For this activity we provide a Constelle table editor. This editorallows for constructing a semantic module using the table notation that we defined earlier inChapter 4. In such a table, the interface elements of the semantic module (its operations, dy-namic and static parameters appearing in the leftmost column of the table) are mapped to theinterface elements of the invoked semantic templates (appearing in other columns of the table).For example, Figure 7.6 shows the semantic module Robotic Arm Parallel in the table editor ofthe Constelle language. Compare this screen shot with Table 4.2 on page 64.


Figure 7.4: Screen shot of the Event-B specification of the Queue template

Figure 7.5: Screen shot of library interfaces in the textual editor

Gluing guards can be added to a semantic module using the wizard depicted in Figure 7.7.The layout of this dialog follows the structure of the class ConstraintInvocation (from the Con-stelle metamodel, see Figure 6.2): the fields Name, Restricts, and Invokes represent theattributes and associations of the class (i.e. name, restricts, and invokes). Other fields are up-dated dynamically according to the operation and the constraint template chosen in the fieldsRestricts and Invokes. For example, x, y, TypeB, TypeA, and functionAB corre-


Figure 7.6: Screen shot of the Constelle table editor

Figure 7.7: Screen shot of the wizard for constructing a gluing guard

spond to the static parameters of the constraint template template_IsFunctionOf chosenin the field Invokes.

7.3.4 Generating and validating Event-B specificationsAfter defining semantic modules in the Constelle table editor, we generate an Event-B specifi-cation for each of the semantic modules using the Constelle-to-Event-B model transformation(described in detail in Chapter 6). We use the generated Event-B specifications and Rodin toimplement the use cases that we identified in Chapter 4 and explained in terms of the LEGOallegory (see page 53):

• to prototype the DSL implementation in Constelle by generating the corresponding Event-B specifications (using the Constelle-to-Event-B model transformation);

• to check applicability and compatibility of invoked specification templates by ensuring


syntactic and logical correctness of the generated Event-B specifications (the logical cor-rectness of an Event-B specification is defined in the form of proof obligations);

• to validate the prototyped DSL implementation against (informal) requirements by execut-ing the generated Event-B specification (for example, using the ProB animator);

• to verify that the prototyped DSL fulfills certain properties by analyzing the generatedEvent-B specification using (automatic) provers and/or model checkers of Rodin;

• to simulate DSL programs by executing the generated Event-B specifications (and possiblyenhance such a simulation with a domain-specific visualization using BMotion Studio).

Thus, the Constelle DSL combined with the tool support of the Event-B formalism, Rodin,implements the use cases of defining the dynamic semantics of a DSL according to the actualimplementation of the DSL (i.e. the principal design solution vs. the requirements of the DSL).For example, Figure 7.8 shows the ProB animation of the Event-B machine generated for thesemantic module Robotic Arm Parallel.

Figure 7.8: Screen shot of the ProB animation of the generated Event-B machine

Note that the second of the listed use cases implies checking consistency of the prototypedDSL through two different techniques: ensuring syntactic correctness of the generated Event-Bspecifications and discharging proof obligations. For the latter, we do not need to discharge allproof obligations generated by Rodin tools, but only its subset that can be identified using thetechnique described in Chapter 6 (see Formula (6.30)). However, our prototype implementationof Constelle does not yet support (automatic) filtering (identification) of proof obligations thatshould be discharged for the generated Event-B specifications. Such a functionality is describedin Section 7.4 as a part of future work.

Besides discharging proof obligations, we use the Event-B syntactic analyzer provided byRodin to identify potential type mismatches in our Constelle models. For example, let’s assumethat we want to modify the semantic module Robotic Arm Parallel in the following way (seeFigure 7.9(a)). We introduce a new construct ActionStatement representing an occurrence of anaction in a task. Thus, in this new version, the task of the operation taskStm consists of Action-Statements, rather than of simple Actions. Correspondingly, we change the invocation of theRequest template (the distributor aspect/column): the static parameter ElementType is substitutedby the type ActionStatement (rather than by the type Actions as in the previous version). Now wewant to check that this modified definition is still consistent.

Figure 7.9(b) shows a fragment of the Event-B machine generated for/from this modifiedsemantic module. We see that there is a syntactic error in the event handActionStm: ‘Types


(a) Constelle table of the modified Robotic Arm Parallel

(b) A fragment of the generated Event-B specification: the syntactic error is highlighted

Figure 7.9: Screen shot of the ProB animation of the generated Event-B machine

Actions and ActionStatement do not match’ (all three appearances of the parameter action arehighlighted by the same error). This means that the two template invocations driver2 and dis-tributor of the modified semantic module are incompatible. These template invocations overlapin (i.e. share) the dynamic parameter action of the operation handActionStm (that is transformedinto the event handActionStm, depicted in Figure 7.9(b)). According to the Event-B specificationof the template Queue (invoked in driver2), action is of the type HandActions (substituting thestatic parameter ElementType of driver2 in Figure 7.9(a)). According to the Event-B specifica-tion of the template Request (invoked in distributor), action is of the type ActionStatement (seethe Event-B machine for the Request template on page 59: request_body ∈ P(ElementType)).Thus, two template invocations assign two different types to the shared parameter action. Thesyntactic analyzer of Rodin helps to identify such inconsistencies in a Constelle model.

Note that in the use cases listed above, Constelle plays a role only in prototyping the DSLimplementation and creating the corresponding specification of the dynamic semantics. All typesof the analysis are carried out by the back-end formalism: from the syntactic analysis of thegenerated Event-B code to model checking. As a result, to benefit from having a definition ofthe DSL dynamic semantics, one needs to be able to work with the back-end formalism.


7.4 Conclusions and Future WorkIn this chapter we described the Constelle workbench, that implements our design presented inChapters 4 and 6 and supports the process of defining the dynamic semantics of a DSL usingspecification templates. The architecture of the Constelle workbench allows for its extensionaccording to our long-term vision outlined in Chapter 3. In the next chapter we use the Constelleworkbench in order to perform a validation study.

The Constelle workbench is a proof of concept rather than a self-contained workbench thatsupports the complete process of developing and maintaining the dynamic semantics of a DSL. Inparticular, we can identify the following functionality that is missing to make our implementationmature enough for practical usage.

• Filtering proof obligations that should be discharged for a generated Event-B specification,according to the identification scheme defined in Chapter 6.

• An inverse mapping from compilation and/or analysis results provided by Rodin tools(such as syntactic errors and undischarged proof obligations) to the concepts and constructsused in a Constelle definition. Such a mapping will facilitate interpreting the feedbackprovided by Rodin tools in terms of the definition of the dynamic semantics of a DSL and,thus, support a DSL developer who does not know the Event-B formalism and the specificsof its tool set.

Nevertheless, as we will demonstrate in the next chapter, the Constelle workbench can be suc-cessfully used for defining the dynamic semantics of a DSL, prototyping a (new) implementationof the DSL, and getting extra insights into the resulting design of the DSL.

Chapter 8

Validation of Constelle

There is nothing magical about specification. It will not eliminate allerrors. Thinking does not guarantee that you will not make mistakes.But not thinking guarantees that you will.

Leslie Lamport, Who Builds a House without Drawing Blueprints?

In this chapter, we validate the proposed approach for defining the dynamic semantics of aDSL using specification templates and Constelle. In particular, we address the following (vali-dation) question: is the proposed approach usable and useful? For answering this question, wefirst design a validation study, i.e. answer the following (design) question: how can we find outwhether the proposed approach is usable and useful? (Section 8.2). Then we apply this design ofa validation study for conducting a particular experiment and analyzing its results (Section 8.3).

The definition process and the Constelle workbench (both described in Chapter 7), resultfrom an iterative application of our ideas (formulated in Chapter 4 using the LEGO allegory) tothree different DSLs. In particular, we can identify the following three milestones of designingConstelle and the corresponding definition process.

• We used the LACE case study (presented in Chapter 2) as our main source of inspira-tion and motivation. In particular, the design of Constelle is the result of generalizingthe LACE-to-Event-B model transformation that constructs Event-B specifications of thedynamic semantics of LACE.

• Manders applied Constelle (the first raw version of its implementation) to define the dy-namic semantics of the Shot puzzle (the DSL that he uses as a running example in his PhDdissertation [63]). This case study revealed a number of programming and design mistakesin the metamodel and implementation of Constelle, which we have corrected since then.Moreover, this case study identified a number of restrictions imposed by Constelle, whichwe discuss in Chapter 9.

• In the validation experiment (presented further in this chapter), the dynamic semanticsof SLCO (Simple Language of Communicating Objects) [27] was (partly) defined using

134 Validation of Constelle

Constelle by an external researcher. This case study resulted in formulating a clear processof defining the dynamic semantics of a DSL using Constelle (described in Chapter 7) andprovided a number of interesting insights (which we discuss further in Section 8.3).

The first two of the listed milestones were performed in an ad-hoc manner, i.e. we did notplan them thoroughly in advance, but rather improvised in response to the available and non-structured feedback. In order to get an objective outcome and to mitigate the potential bias, inthe third experiment we explicitly choose and follow an empirical research method. As a result,the design of the validation study (presented in this chapter) can be applied (reused) in futureexperiments on defining the dynamic semantics of a DSL using Constelle. An overview of theempirical methods that we use in our validation study is given in Section 8.1

8.1 Empirical MethodsIn empirical research, one gains knowledge by means of observation or experience (comparedto theoretical research, where one develops theories to support observed phenomena). In thecontext of software engineering, most empirical methods study human activities of softwaredevelopment process. Many of these methods are drawn from disciplines that study humanbehavior and, as such, ‘have known flaws and can only provide limited, qualified evidence aboutthe phenomena being studied’ [26]. The key focus of empirical methods is to manage informalityof an empirical study, mitigate possible flaws and misinterpretations resulting from the humanbias, and to enhance clarity and transparency of conclusions drawn from the study.

In our validation study we use the following empirical methods.

Qualitative study explores a phenomenon rather than measures it (in contrast to a quantitativestudy). In particular, a qualitative study examines the ‘why’ and ‘how’ of decision making,and thus, provides insights into the underlying reasons, opinions, and motivations. Incontrast, a quantitative study uses statistical data to prove hypotheses formulated as a resultof a qualitative study.

Action research combines conducting research on the process (of solving a problem) with ac-tively participating in improving (or changing) this process [26]. In comparison, the well-known empirical method of a case study focuses on studying the effects of a change (i.e.of applying our method) and has an observational (rather than influential) nature [83].

GQM (Goal/Question/Metric) method has a long history of usage in the context of improvingsoftware quality and provides a structured approach to identify which metrics should bemeasured [93]. GQM defines a study model on three levels (i.e. in three consecutive steps):goals, questions, and metrics.

Concurrent triangulation strategy implies that different methods are used concurrently to sup-port, corroborate, and cross-validate findings of the study [26].

8.2 Setting up a Validation StudyTo evaluate our method of defining the dynamic semantics of a DSL, we perform a validationstudy. The validation study has a corresponding object and subject: a DSL, whose dynamicsemantics is defined, and a DSL developer, who uses Constelle to define the dynamic semanticsof the DSL. Based on the nature of our method, we can distinguish the following characteristicsof such a study.

8.2. Setting up a Validation Study 135

• To be representative, the study should use a DSL with a non-trivial dynamic semantics (toincrease the likelihood that the dynamic semantics is composed of more than one semanticmodule).

• A subject has to know and/or learn the DSL, the Event-B formalism, and Constelle. Thus,such a study is a resource-intensive task for the subject.

• As our method is novel and possibly not yet optimal, we aim to learn new insights and im-prove our method, rather than to measure its impact and compare it with existing methodsand practices.

Taking into account these characteristics, we choose to perform a qualitative study. Applyinga qualitative study to Constelle allows for using a small data set (i.e. number of subjects andobjects) and for validating our method by comparing the insights gained during the study withour prior assumptions, motivation, and vision. The possibility to use a small data set makes thevalidation study feasible, as we need to find a non-trivial DSL and invite a DSL developer toperform a resource-intensive task for us.

In our validation study, a DSL developer uses Constelle to define the dynamic semantics ofa DSL. This means that the DSL developer needs to learn how to use Constelle. To make theprocess of learning and adopting Constelle more efficient, and at the same time to learn from thisprocess, we choose to perform an action research. Note that we choose an action research ratherthan a case study, as our method is not yet at the stage where we want to analyze how it affectsdesign, development, and usage of a DSL.

For the study of our method an action research means that we teach the DSL developer howto use Constelle and Event-B, help the DSL developer in applying our method to the concreteDSL throughout the whole study, and even update our implementation and our definition processon-the-fly using the feedback obtained from the DSL developer. However, at the same time westrive to validate our ideas by learning new insights from the DSL developer, from difficultiesthat they experience, and from their way of applying our method.

According to [26], the biggest challenge of performing an action research is that it is notsupported with an established evaluation framework. Such an evaluation framework ensuresthat the conducted research is rigorous and reduces the potential researcher bias. For this, anevaluation framework helps researchers to position their experiment within the field of study andto consider carefully the nature and assumptions underlying their work [20].

To establish an evaluation framework for our validation study, we draw inspiration from theGQM method and organize the structure of our study following its steps. As GQM is meant fordesigning a quantitative study but we conduct a qualitative study, we adapt the last step of thismethod: instead of deriving which metrics should be measured, we define how we collect dataduring the qualitative study (Section 8.2.3). Overall, we follow steps of GQM to identify aspectsthat we should look at (activities, decisions, artifacts, etc.) and the corresponding details that weshould not miss (to check our assumptions and reduce our biases).

In the following three subsections we present the three steps of GQM: goals, questions, andmetrics. In Section 8.3 we use the design captured in these three steps to analyze the collecteddata and to derive conclusions from the validation study.

8.2.1 Goal DefinitionThe GQM method starts top-down with the definition of an explicit measurement goal (or in ourcase, a goal of the qualitative study). In order to clarify what constitutes a study goal and tostructure its definition, GQM provides a template for a goal definition. Table 8.1 captures the


application of such a template to our study. In particular, this table captures the purpose (whatobjects we analyze and why), the perspective (what we focus on and from whose point of view),and the context characteristics (what are the specifics of the process under study).

Table 8.1: GQM goal definition for the validation study

Analyze(i.e. the objects under study)

• the definition process (as defined in Chapter 7),• Constelle (and the supporting tool set),• the hypothesis of reusable specification templates.

For the purpose of• checking the applicability of the proposed method,• improving Constelle and the definition process,• assessing usefulness of the proposed method.

With respect to(i.e. the study focuses on)

• a complete and clear definition of the dynamic semantics,• modularity of the definition of the dynamic semantics,• reusability (i.e. genericity) of semantic modules.

From the viewpoint of a DSL designer (developer)In the context of(i.e. the environment in whichthe study takes place)

• defining the dynamic semantics of an existing DSL• by a person, who did not participate in the developmentof this DSL in the first place.

In principle, in our validation study we aim to answer the three following questions: does ourmethod work? how can we improve our method? and is our method useful? For this, we lookinto the ideas that form our method (reusable specification templates and their composition fordefining the dynamic semantics of a DSL).

Based on the identified goals (the objects under study in the top row of the table), we definethe following criteria of failure and/or success of our validation study.

Criteria of failure of the validation study

• the definition process is not applicable and it is not clear how to improve it,

• Constelle is not applicable and it is not clear how to improve it,

• no candidates for reusable specification templates were found,

• Constelle and Event-B are not applicable for expressing reusable specification tem-plates proposed (identified) by the DSL developer.

Criteria of success of the validation study

• the definition process is applicable and/or can be improved,

• Constelle is expressive enough to support the definition process,

• a number of improvements and insights are identified,

• a number of candidates for reusable specification templates were found.

8.2.2 QuestionsAccording to GQM, each goal is refined into a set of questions that break down the studiedissue into its main components. Questions do not only provide an intermediate step between


abstract goals and concrete techniques for collecting data, but also support interpretation of thedata (gathered during the study) when we draw conclusions about the goals of the study (i.e.when we decide whether the goals are reached). We formulate the following questions for ourstudy.

1. What kind of information about the DSL is necessary to define its dynamic semantics?

2. What are the steps that one follows when defining the dynamic semantics of the DSL?

3. How does the decomposition of the dynamic semantics happen?

4. What are the guidelines for recognizing a semantic module?

5. What changes in the definition of the dynamic semantics of the DSL between the iterationsof the definition process?

6. How to compose the dynamic semantics of the DSL out of semantic modules through theirsemantic interfaces?

7. Are there reusable specification templates emerging as a result of the definition?

8. What the DSL developer can learn from defining the dynamic semantics of the DSL?

9. How can one use the resulting definition of the dynamic semantics?

10. What is the scope of Constelle, what are its expressiveness power and limitations?

11. What can we change in Constelle to improve the design of Constelle (the Constelle lan-guage)?

12. How does the connection with the back-end formalism (Event-B) influence the definitionprocess and the resulting definition of the dynamic semantics of the DSL?

Following the qualitative nature of our study, we formulate most of these questions as openquestions (examining ‘what’ and ‘how’ of the subject’s experience). Figure 8.1 shows the mindmap (or concept map) of how the goals of our study are related to (refined into) the formulatedquestions. First (see Figure 8.1 on the left), we instantiate the study goals into a set of conceptsusing combinations of the objects, purposes, and focuses of the study (stated in Table 8.1): suchas ‘applicability of the definition process’ (combination of a purpose and an object) and ‘modu-larity of the definition’ (a focus). Then we derive study questions from these concepts using ourknowledge of the method under study. For example, the definition process is analyzed throughstudying its steps. Modularity of the definition is analyzed through studying the (de)compositionof the dynamic semantics. Improvement of Constelle (Figure 8.1 on the bottom) addresses itsweak sides in the context of its strong and bad sides addressed in the applicability of Constelle(‘the good, the bad, and the ugly’).

Some of the formulated questions have hypothetical answers: such as ‘if not possible todecompose’ (Figure 8.1, on the right). Such hypotheses stimulate thinking about potential de-viations of the results (obtained during the study) from our expectations and capture knowledge(and assumptions) that we currently have about our method [93]. Stating hypotheses can helpto not miss some important details (data) that should be collected (observed) during the study.We relate the emerging hypotheses to other study questions from the list or formulate auxiliaryquestions in order to address a hypothesis.

138V

alidationofC

onstelle

Figure 8.1: Mind map of refining the goals into the study questions


8.2.3 QuestionnairesAfter refining the goals into the list of questions, we need to define how to collect all necessaryinformation in order to answer these questions in a satisfactory way. In a quantitative study,information is collected in the form of metrics. According to GQM, metrics are designed as arefinement of questions (listed in Section 8.2.2) into a quantitative process and/or a set of mea-surements. As we perform a qualitative study, we refine our questions into a set of questionnairesthat allow for collecting empirical data during our study (such as experience and feedback of theDSL developer).

When formulating questionnaires, we map our study questions onto the context and experi-ence of the DSL developer (our study subject). For example, knowing that our DSL developerwill be using the Constelle workbench to define the dynamic semantics of their DSL, we canrelate to the tools, formalisms, and artifacts that they will be using: Constelle, Event-B, Ecore,DSL metamodel. To capture the experience (emotions) of the DSL developer we use such no-tions: problem, challenge, hard, happy, trick, recommendation. Moreover, the relation betweenthe study questions to the questionnaires is many-to-many: the same study question can be ad-dressed in multiple places in multiple questionnaires, and the same question of a questionnairecan be addressing multiple study questions. The reason for this is that we need to translate ourvision of the validation study into the set of questions for the DSL developer in such a way thatwe do not influence (direct) answers of the DSL developer and the questions are clear to the DSLdeveloper. An example of such a relation between the study questions and the questionnaires isdepicted in Figure 8.2. Here in brackets we refer to the index numbers of the questions (see Ap-pendices C.2 and C.3 for the questionnaires). For the sake of understandability, we use differentstyles of lines.

Next to the study questions listed above in Section 8.2.2, we identify factors that can influencethe results of our study (i.e. determine the utility of the knowledge gained in the study). Forexample, for applying our method to define the dynamic semantics of a DSL, the DSL developerneeds to learn and/or know the DSL, the Event-B formalism, and Constelle. Thus, an importantfactor for our study is the knowledge (and skills) that the DSL developer possesses before thestudy, such as their experience with formal methods and with developing and designing DSLs.Such a starting set of existing knowledge and skills is known as a baseline of a study. FollowingGQM, we include these influencing factors into the questionnaires (i.e. assess them within thesame study, among the questions that aim to address the main goals of the study).

Our validation study includes the following three questionnaires.

1. A baseline questionnaire is filled in the beginning of the study and is meant for identifyingthe input (the baseline) of the study.

2. A logbook questionnaire is filled regularly during the study and is meant for logging theprogress of the definition process. In particular, we ask the DSL developer to trace theirprogress using a version control system and to fill in the logbook questionnaire when com-mitting (checking in) a new version of their files (i.e. artifacts, such as Event-B specifica-tions, the Constelle model, etc.).

3. A final questionnaire is filled out at the end of the study and is meant for capturing themajor impression and experience of the DSL developer.

140V

alidationofC

onstelle

Figure 8.2: Mind map of refining (some of) the study questions into the questionnaires

8.3. Conducting the Validation Study 141

The questionnaires can be found in Appendix C. Note that in our questionnaires we use bothopen questions to the DSL developer, such as

How many iterations did you make when specifying the dynamic semantics of the DSL?

and questions accompanied with a list of possible answers, such as

This semantic module appeared as a result of learning from:(a) the DSL metamodel;(b) the example models;(c) the DSL (concrete) syntax definition;...

We include possible answers (i.e. apply a style of a survey) when we assume that a DSL developermight perform certain steps (activities) naturally, without thinking, and thus, not realizing thatthese steps are important for us to observe. For example, when defining the dynamic semantics ofa DSL, the DSL developer might be studying various sources of information about the DSL (itsmetamodel, example models, etc.). However, this process can be so natural to the DSL developer,that he/she would not recall all these sources of information, unless asked explicitly (as we do inthe latter question given as an example above).

To support the data collected via the questionnaires with an objective input (as the question-naires capture a subjective view of the DSL developer), we apply the concurrent triangulationstrategy (described in Section 8.1). As an extra source of information for such a triangulation,we use a version control system for the artifacts created by the DSL developer during the defi-nition process. In particular, we set up a repository where the DSL developer stores all artifactscreated during the validation study. As a result we can access and examine created artifacts, andmoreover, keep track of the evolution of these artifacts.

8.3 Conducting the Validation StudyIn this section, we describe (a concrete case of) the validation study that we conducted andanalyze it according to the design presented in the previous section.

8.3.1 Methodology and Collected DataAs we discussed earlier, in our validation study we perform action research. This empiricalmethod requires close cooperation between a researcher and a participant of the study (a DSLdeveloper). Together with the resource-intensive task for the DSL developer to manage (under-stand and/or use) three different languages (the DSL, the Event-B formalism, and Constelle), thisspecificity of the chosen empirical method results in high organizational costs of the validationstudy.

We mitigate the high organizational costs by conducting the study with one of our colleagues(a researcher) who has the expertise in formal methods. Thus, it is easier for us to organizecollaboration, we have a common understanding of the motivation for conducting such a study,and it is easier for the DSL developer to learn another formal method (Event-B) and to relate itto his experience with other formal methods. For example, our DSL developer “can read, write,and apply analysis tools to specifications in UML, process algebra, timed automata, and petrinets”1 . This setting determines the baseline of our study.

1In the rest of this chapter, we use the double quotation marks when quoting answers given by our DSL developer.


During the validation study, we had five sessions with the DSL developer (lasting for aboutan hour each) in order to:

• teach (by demonstration) how to use Event-B, Rodin, and the Constelle workbench,

• solve appearing (mostly technical) issues, and

• give advice on how to apply Constelle in various (concrete) situations.

All these sessions were documented in our notebook. The final, sixth session, lasted for 1,5hour and was used for filling in the final questionnaire. In this way we could capture additionalremarks by our DSL developer and discuss some of the emerging results in more detail.

In total, during the definition process the DSL developer made 15 commits to the (Git2)repository, filled in one baseline, one final and 7 logbook questionnaires. Moreover we received13 e-mails from our DSL developer requesting various types of help (mostly technical problems).

8.3.2 Analyzing Results of the Validation StudyTo interpret (analyze) the collected data, we use the study questions formulated in the secondstep of the GQM method (see Section 8.2.2). In particular, we use our mapping between studyquestions and questionnaires (discussed in Section 8.2.3) to do (reverse) mapping of answersgiven by our DSL developer onto our study questions. In this way we answer the study questions,i.e. analyze results of the study.

Moreover, following the concurrent triangulation strategy (described in Section 8.2.3), werelate the answers given by the DSL developer to the Git repository. For this, we manually readthe source code of the artifacts constructed by the DSL developer (Constelle tables, Event-Bspecifications, structural and semantic interfaces) and study how these artifacts evolve during thedefinition process. For the latter, we use the EMF model compare plug-in.3

In what follows (Sections 8.3.2.1–8.3.2.12), we answer our study questions one-by-one using(and referring to) the data collected during the study (i.e. to the filled in questionnaires and theGit repository).

8.3.2.1 What kind of information about the DSL is necessary for defining its dynamicsemantics? (study question 1)

During the validation study, Constelle was used to define the dynamic semantics of the SLCODSL (Simple Language of Communicating Objects) [102]. Our DSL developer did not partic-ipate in the development of SLCO in the first place. His main goal during our validation studywas to “rethink the design of SLCO”, as he wanted to “change how the DSL is implemented”.

As a source of information and a reference implementation (or design) of the dynamic se-mantics of SLCO our DSL developer was using the definition of SLCO in ASF+SDF givenin [7]. According to the filled logbook questionnaires, the most common sources of acquiringinformation about the dynamic semantics of the DSL were “the DSL metamodel” and “the ex-ample models” (mentioned in 6 out of 7 log entries). The metamodel of SLCO and the informaldescription of its dynamic semantics were provided in [27].

2https://git-scm.com/3www.eclipse.org/emf/compare/

https://git-scm.com/

www.eclipse.org/emf/compare/


8.3.2.2 What are the steps that one follows when defining the dynamic semantics of theDSL? (study question 2)

As a result of the validation study, our (recommended) definition process was reconsidered. Inparticular, the definition process described in Chapter 7 reflects the actual way in which our DSLdeveloper was defining SLCO in Constelle. For example, he was considering multiple semanticmodules in parallel, first specifying them in Event-B and only then connecting them together in aConstelle table. This differs from our initial proposal to define semantic modules in the form oftheir interfaces, then compose them in a Constelle model, and only then to implement them in theEvent-B specifications. Note though, that this outcome might be determined by the backgroundof our DSL developer (i.e. formal methods). Thus, we formulate our definition process rather asa recommendation, one of the possible ways of applying Constelle.

8.3.2.3 How does the decomposition of the dynamic semantics happen?(study question 3)

The final Constelle model of SLCO includes four semantic modules: state machine, sm data,channel, and sequential control flow. The semantic module state machine defines the structureof a state machine (states and transitions) and updates its current state according to the takentransitions. The semantic module sm data is responsible for executing statements associatedwith the taken transitions and for assigning values to the local variables of the state machines (asa result of such an execution). The semantic module channel defines communication channelsbetween state machines and takes care of delivering messages through these channels. Finally,the semantic module sequential control flow ensures that statements of the taken transition areexecuted in sequential order (for example, guards of a transition, realized in SLCO in the formof blocking statements, should be executed first in order to enable the transition, i.e. before thetransition can be taken).

Moreover, the DSL developer considers a subset of certain gluing guards as another mod-ule (which is strictly-speaking in terms of Constelle not a semantic module). This set of gluingguards, appearing under the common name object, is used to link elements of the state machinemodule with elements of the channel module, and with elements of the sm data module. Fromthis we conclude that the notion of the semantic module should be revisited: for example, re-named and/or generalized so that it can capture a set of (logically connected) gluing guards.

We discuss the criteria used for the decomposition of the dynamic semantics into semanticmodules in the next subsection (see Section 8.3.2.4), together with the guidelines for recogniz-ing a separate semantic module. According to the feedback received from our DSL developer,decomposing the dynamic semantics of the DSL into semantic modules is the most difficult partof the whole definition process. For designing such a decomposition, one needs at the same timeto come up with a set of constituent modules and to design how these constituent modules areconnected. Gluing guards play an essential role in these connections. However, these Constelleconstructs are the hardest for understanding.

8.3.2.4 What are the guidelines for recognizing a semantic module?(study question 4)

Five out of 7 logbook questionnaires were devoted to the introduction of a new semantic module(i.e. one logbook per module). According to these logbook questionnaires, the major criteria thatwere used to identify (introduce) a semantic module were:


• independence of the semantics when being implemented by a DSL developer (mentionedin three out of 5 log entries),

• independence of the semantics specified for a subset of the DSL metamodel (mentioned intwo out of 5 log entries),

• independence of the semantics when being used by a DSL practitioner (mentioned in twoout of 5 log entries),

• hiding a (difficult) design decision (mentioned in one log entry and related to the sequentialcontrol flow semantic module).

Thus, separate semantic modules are implemented and/or used independently from each other.This confirms our prior assumption of and motivation for having different types of modularityof a definition of the dynamic semantics of a DSL (such as architectural modules and semanticfeatures in the LACE case study, see Chapter 2).

In relation to the sizes of the semantic modules of SLCO, there are two or three operationsin their interfaces (each operation with only one dynamic parameter). Event-B specificationsthat implement these semantic modules are quite compact (for example, three out of the fourspecifications can fit separately on one screen). As neither of these (rather small) sizes wasmentioned as one of the guidelines for identifying a semantic module, we conclude that our DSLdeveloper did not consider sizes of his Event-B specifications important.

8.3.2.5 What changes in the definition of the dynamic semantics of the DSL between theiterations of the definition process? (study question 5)

When filling in the final questionnaire, our DSL developer identified three iterations (or mile-stones) in the definition process that he followed: (1) defining the basic concepts of a statemachine; (2) adding data and its processing to the state machine; (3) introducing communicationbetween state machines. However, as the time for the validation study was limited, the definitionof the dynamic semantics of SLCO was not finished. Our DSL developer foresees that there arestill two to three iterations required to achieve his goal of redesigning SLCO. For example, onemore iteration is necessary for extending a channel with a buffer of messages.

Figure 8.3 captures the evolution of defining the dynamic semantics of SLCO in Constellederived from the Git repository. This graph shows semantic modules (depicted as blue circles),operations of the semantic interface (depicted as orange diamonds), and gluing guards (depictedas green squares) along the versions of the Constelle model (the horizontal axis of the graph). InFigure 8.3 we group the versions of the Constelle model into iterations as they were identifiedby our DSL developer. In what follows we describe some details of this evolution derived froma more close inspection of the Constelle model and its successive versions.

In the first iteration two semantic modules, state machine and sm data, define the basic struc-ture of the state machine (including statements on transitions and local variables) and its basicbehavior. This basic behavior is projected on (represented by) two operations of the semanticinterface (two orange diamonds at the version 1 in Figure 8.3): to check whether a transition isenabled and to fire (take) an enabled transition.

The second iteration adds the semantic module sequential control flow. Along with the intro-duction of this semantic module, two new operations appear (see Figure 8.3). The newly addedcomponents (the semantic module sequential control flow and two new operations) define thesequential execution of statements on a transition. Figure 8.4 shows details of this change (fromright to left: step from version 1 to version 2). From this figure we see that adding new operationsresults in a more fine-grained semantic interface of the dynamic semantics. In other words, we


versions

model

iteration 1 iteration 2 iteration 3

1 2 3 4 5 6 7

semantic module(template invocation)

operation of the semantic interface

gluing guard

pins illustrate the number ofinterface element substitutions

pins illustrate the number of dynamic parameters

Figure 8.3: Evolution of the Constelle model of the SLCO dynamic semantics

can consider this change as a split of operations: both the meaning and the dynamic parametersof the ‘old’ operations are divided among ‘new’ operations. This more fine-grained interfaceresults in more connections between the interface elements and semantic modules (template in-vocations), see Interface Element Substitutions in Figure 8.4.

Note that an interesting design choice was made during the second iteration. In version 4versus version 3 (see Figure 8.3), there are fewer gluing guards (green squares on the top of thecolumn) but more interface element substitutions (pins of blue circles). Both Constelle constructsof gluing guards and interface element substitutions can be used to connect (or relate) separatetemplate invocations (or semantic modules) to compose the dynamic semantics of a DSL. Herethe DSL developer was choosing a more suitable way of connecting three semantic modules. Inthe later versions (see versions 6 and 7) both interface element substitutions and gluing guardsare used extensively. Thus, we do not conclude that one of the constructs is more preferable than


Figure 8.4: Constelle model of SLCO: version 1 on the right and version 2 on the left

another.In the third iteration the semantic module channel is introduced (new blue circle in version 5),

then the set of gluing guards object are added (new green squares in version 6), and finally boththese concepts are connected to the existing model (more pins and more squares in version 7).Moreover, as a projection of these changes to the semantic interface, a new operation is added(new orange diamond in version 7).

An important observation that we make from the definition process of SLCO, is the wayhow new semantic modules appear. Neither of the semantic modules appears as a result of split-


ting a semantic module into (smaller) semantic modules. In other words, we can characterizethe definition process as an iterative composition (adding functionalities one-by-one to the ba-sic functionality) rather than iterative decomposition (splitting one monolithic functionality intosmaller functionalities) of the dynamic semantics.

8.3.2.6 How to compose the dynamic semantics of the DSL out of semantic modules throughtheir semantic interfaces? (study question 6)

The semantic interface of the Constelle definition of SLCO has five operations (depicted as or-ange diamonds in Figure 8.3). As we see from the evolution of the Constelle model, these five op-erations were introduced not at once, but were added along with the semantic modules (aspects)of the SLCO definition. As we discussed above (in the relation with Figure 8.4), operations ofthe semantic interface are decomposed into new operations that represent more fine-grained stepsof the execution.

This observation helps us to relate constructs of Constelle to the existing techniques of defin-ing the dynamic semantics of GPLs. In particular, we can compare the observed decompositionof the semantic interface into more fine-grained operations with a conversion from the style ofnatural (or big-step) semantics [73] towards the style of structural operational (or small-step)semantics [73]. Big-step semantics describes results of the overall execution of a (DSL) pro-gram. Small-step semantics describes the individual steps of the computations. In the definitionprocess of SLCO depicted in Figure 8.3, introduction of more semantic modules corresponds toa more detailed description of steps of the computations.

8.3.2.7 Are there reusable specification templates emerging as a result of the definition?(study question 7)

Our DSL developer recognizes the semantic modules state machine and channel as generic soft-ware design solutions that can be applied in a scope broader than the dynamic semantics ofSLCO. Moreover, he foresees that he can reuse state machine (without channel) in one of his(other) running projects. Note that, the remark that our DSL developer can reuse “state machinewithout channel” confirms the common knowledge that the possibility to separate modules fromeach other facilitates their reuse.

The semantic module sequential control flow captures a technique that is not specific forSLCO, but is specific for applying Event-B and Constelle. In particular, there is no way to restrict(impose a sequential order on) the control flow of operations in a Constelle model and/or eventsin an Event-B specification. As a workaround for this limitation, we proposed our DSL developerto introduce the semantic module sequential control flow. We consider sequential control flow asa specification trick reusable in other specifications.

As such, all these three semantic modules can be considered as reusable specification tem-plates and can be included in our library. However, neither of these specification templates hasbeen reused within the definition of SLCO. Moreover, the DSL developer did not use our speci-fication templates presented in Chapter 4 (Queue, Request, and Partial Order). Therefore, moreexperiments are necessary to evaluate (assess and measure) how reusable all these specificationtemplates are.

8.3.2.8 What the DSL developer can learn from defining the dynamic semantics of theDSL? (study question 8)

The dynamic semantics of SLCO has been formalized before (see the PhD dissertation of Enge-len [27]). Therefore, its definition does not reveal any gaps and/or inconsistencies (in contrast


with our hypothesis of possible outcomes of the definition process). However, the existing formalspecification of SLCO is “hard to read”. Defining the dynamic semantics of SLCO in Constellehelped our DSL developer to understand the existing formalization and to gain extra insights inthe DSL. For example, the DSL developer was “forced to think” about the concept of atomicstatements and as a result gained understanding of an effect of transitions on the global stateof a system (the most complex and “most dynamic” part of the DSL, according to our DSLdeveloper).

All Event-B specifications of the resulting specification of SLCO have their proof obligations(POs) discharged. According to our DSL developer, the feedback that he got from the tools (suchas Rodin automatic provers) when discharging proof obligations was helpful for constructing theEvent-B specifications.

8.3.2.9 How can one use the resulting definition of the dynamic semantics?(study question 9)

From the point of view of defining the dynamic semantics of SLCO in Constelle (i.e. complete-ness of the definition), our DSL developer was able to express what he intended to express withinthe time period of our validation study and up to the created version. He has not finished the defi-nition of his design though and was aiming to continue later. Moreover, he had not yet performedany type of analysis of the resulting definition.

From the point of view of the clarity and intelligibility of the definition, our DSL devel-oper believes that he would be able to use the resulting definition as documentation for his ownreference, but not for communicating with other interested participants. In other words, the defi-nition of SLCO in Constelle can not be used per se, without any additional documentation and/orexplanation (both of SLCO and Constelle).

8.3.2.10 What is the scope of Constelle, what are its expressiveness power and limitations?(study question 10)

In general, our DSL developer was satisfied with the expressive means of Constelle. He es-pecially found the table notation of Constelle very useful: “the Constelle table gives a goodoverview of the DSL specification”. Except for finding it hard to learn Constelle and applyinga modular approach to the specification (as described above in Section 8.3.2.3), he encounteredthe following two limitations, with which he was not satisfied. The first limitation is in the scopeof the Event-B formalism: it is not possible to specify functions for returning a value in Event-B.As a workaround, one needs to use guards of an event to calculate the value of a parameter. As aresult, the formalism “forces to specify a DSL concept in a different way, it is restrictive”.

The second limitation is determined by Constelle. As described in Section 8.3.2.7, there isno way to restrict the control flow in a Constelle model or in an Event-B specification. Thesemantic module sequential control flow was used to overcome this limitation in the definition ofthe dynamic semantics of SLCO. When discussing the semantic module sequential control flowwith our DSL developer, we suggested that in the actual implementation of SLCO there shouldbe a corresponding (software) construction or component that implements sequential control flow(for example, a program counter). Our DSL developer agreed, but considered sequential controlflow “auxiliary on this conceptual level of defining the DSL”. He would prefer not to include thissemantic module in the definition of SLCO if it was possible to use other means of Constelleinstead.

However, we do not consider the latter limitation to be a flaw in Constelle. As discussed inChapters 2 and 4, we deliberately chose to define the dynamic semantics of a DSL according to its


actual implementation, capturing all design decisions explicitly. These include a design decisionon how to implement the sequential control flow. Our DSL developer would prefer to have animplicit description of the sequential control flow, which contradicts with the described principleof Constelle. Note though that this contradiction might be determined by the background of ourDSL developer (formal methods). Therefore, we conclude that more studies (or experiments) arenecessary to validate the described principle and/or evaluate its usefulness in practice.

8.3.2.11 What can we change in Constelle to improve the design of Constelle?(study question 11)

An important insight that we gained from the validation study and managed to improve (on-the-fly) concerns the Constelle construct of different template parameters and their relations witheach other. In particular, in our previous version of Constelle, each DynamicParameter of anOperation had an explicit association with its type, which could be one of the StaticParameters(all from the same scope determined by the SemanticInterface and its StructuralInterface). Inpractice this meant, that our DSL developer could choose (or even should have defined) a typefor each dynamic parameter in his semantic interfaces (for example, as it is done in Figure 8.5(a)).

1 semant ic i n t e r f a c e t e m p l a t e _ q u e u e2 uses t e m p l a t e _ b a s i c3 {4 o p e r a t i o n enqueue ( e l e m e n t : ElementType )5 o p e r a t i o n dequeue ( e l e m e n t : ElementType )6 }

(a) Old design



VARIABLESqueue

INVARIANTS


EVENTS

Initialisation


end

Event enqueue =

any element, index



end

Event dequeue =

any element, index


end

END

(b) Fragment of the Event-B code

1 semant ic i n t e r f a c e t e m p l a t e _ q u e u e uses t e m p l a t e _ b a s i c {2 o p e r a t i o n enqueue ( e l e m e n t )3 o p e r a t i o n dequeue ( e l e m e n t )4 }

(c) New design

Figure 8.5: An example of the change of the Constelle design

However, a semantic interface is implemented in the corresponding Event-B specification,where such a dynamic parameter is implemented as an Event-B parameter (of an event). The typeof this parameter is specified in the Event-B specification (see Figure 8.5(b)). This Event-B typecan correspond to one of the static parameters of the StructuralInterface, but still the associationbetween the parameter and its type is already specified in the Event-B code. Thus, the semanticinterface wrapping this Event-B code should not redefine such an association (in a redundantor even conflicting way). After realizing this, we removed the association between a Dynamic-Parameter and a StaticParameter from the Constelle metamodel and updated user interfaces ofthe Constelle workbench (table editor and the textual syntax for defining semantic interfaces, seeFigure 8.5(c)). The described realization came to us as a result of observing our DSL developerstruggling to understand how to use the Constelle table editor, in particular, how to substituteboth a dynamic parameter and its type in a consistent way.

Another possible improvement in the design of Constelle is related to the encapsulation ofa current state (i.e. Event-B variables) of a semantic module (invoked specification template).In Constelle, it is not possible to access the current state of a semantic module. However, the


possibility to examine the current state of a semantic module and to restrict its value using (aninvocation of) a constraint template would improve the experience of a DSL developer. More-over, such a change would fit in our Constelle-to-Event-B semantic mapping that is based onthe Event-B∗ techniques of generic instantiation, shared event composition, and refinement. Weconsider such an improvement in the design of Constelle as future work.

8.3.2.12 How does the connection with the back-end formalism (Event-B) influence thedefinition process and the resulting definition of the dynamic semantics of theDSL? (study question 12)

When answering the final questionnaire, our DSL developer recommended us to improve theconnection of semantic and structural interfaces with the back-end Event-B code by making itmore clear. As mentioned above, gluing guards of Constelle were especially hard to grasp. Fromthe artifacts created by our DSL developer when defining the dynamic semantics of SLCO inConstelle (and stored in the repository), we observe that he did not use private specification el-ements. In other words, all elements of his Event-B specifications (in particular, parameters ofthe events) appear in the semantic interfaces of the specification templates. On the one hand,such a lack of encapsulation might be caused by the complexity of the tool provided for con-necting semantic (and structural) interfaces to the back-end Event-B code. On the other hand, alloperations and the corresponding events of the Event-B specifications have only one (dynamic)parameter. Thus, the encapsulation was not necessary.

In the context of the Event-B∗ techniques used in the Constelle-to-Event-B model transfor-mation, the DSL developer foresees that he could apply other decomposition mechanisms ofEvent-B, for example, shared variable decomposition [4]. He also believes that Constelle can beused with other back-end formalisms, for example, with mCRL2 (the formalism that is based onAlgebra of Communicating Processes) [32].

8.3.3 Concluding on the Study GoalsBased on the described findings, we conclude that the validation study was successful and mostof the goals of the study were achieved (see the list of criteria in Section 8.2.1):

• the definition process was applicable for defining the dynamic semantics of SLCO;

• Constelle was expressive enough for defining the dynamic semantics of SLCO;

• the usefulness of applying Constelle was confirmed;

• a number of improvements for Constelle were indicated and partly realized;

• a number of candidates for reusable specification templates were defined.

At the same time, the focuses of the study (see third line in Table 8.1) were not fully covered:

• The definition of the dynamic semantics of SLCO was not complete (i.e. not finished dueto the time restrictions) and was not judged to be clear by our DSL developer (i.e. one cannot use it as a documentation per se).

• Applying the “modular specification” approach required quite some effort from our DSLdeveloper. He suggested that a more insightful tutorial and documentation are necessary.However, no specific recommendations have been derived.


• Neither of the candidates for reusable specification templates have been actually reused.This might be due to the (still too) small size of the constructed definition of the dynamicsemantics of SLCO.

The validation study was not without flaws. Due to the time restrictions, the definition of thedynamic semantics of SLCO was not finished. Moreover, the first steps of the definition processwere not tracked in the version control system (i.e. the Git repository). Therefore, the overviewof the evolution of defining the dynamic semantics of SLCO (presented in Section 8.3.2.5) is notcomplete.

Furthermore, there were a number of technical problems with our tool support, the Constelleworkbench. From these observations we conclude that our choice for an action research wasjustified: we could update the definition process and tooling on-the-fly and we could advise oncertain design decisions (such as the introduction of sequential control flow).

In the context of an action research, the most important outcome of our study are the changesthat happened with a subject (our DSL developer), an object (Constelle), and a technologyprovider (us) as a result of the study. We identify the following changes resulting from ouraction research.

• As a result of our validation study, the DSL developer experienced a “shorter feedbackloop” when specifying the dynamic semantics of a DSL. That is, he could get a feedback(from tools) and update his specification correspondingly on an earlier stage than he wasused to (traditionally, a formal specification is constructed on paper and then encoded intoa formalism that has a tool support). We consider such an experience as agile formalmethods.

• As a result of the preparation for our validation study, the pragmatics of Constelle wasconsidered and the definition process was formulated. As a result of conducting the study,the design of Constelle was improved and the definition process was reconsidered. In otherwords, our method and Constelle matured. Moreover, more specification templates wereidentified.

• As a result of our validation study, we learned that one of the main focuses of our research(i.e. this thesis) - the modularity of a definition of the dynamic semantics of a DSL - mightbe one of the main challenges of applying our method. Thus, the design of a decompositionshould be addressed with more care (in the design and/or in the pragmatics of Constelle).

8.3.4 Threads to ValidityIn relation to the generality of the obtained results, an action research usually concerns threatsto utility of the knowledge gained [26]. In other words, the assessment of validity of an actionresearch focuses on the practical outcome of the study, rather than on the repeatability of thestudy. From this point of view, the specifics of the profile of our DSL developer do not violatevalidity of the results of our validation study.

For example, our DSL developer has a strong background (a PhD degree) in formal methods,which we usually do not expect from an average DSL developer. This is a threat to validity ofour results, as we might not get the same results if we repeat our study with a DSL developerwithout a strong background in formal methods. However, from the point of view of an actionresearch, the strong background in formal methods of our DSL developer helped us to get certaininsights, which we otherwise would not get (such as comprehensive usage of Event-B and themodular approach to formal specification). Thus, we consider the obtained results valid, as theyare useful.


8.3.5 Future WorkOur study triggered a number of new questions and revealed a number of gaps in our knowledgeabout experience of a DSL developer and the definition process that they follow. In this relation,we identify the following questions that can be addressed in the future (both qualitative andquantitative) studies and/or related to existing empirical studies in software engineering:

• Is a modular approach a common challenge in software engineering and, more specifically,in MDE? Or is the decomposition of the dynamic semantics of a DSL difficult (only) inthe context of our method?

• Does the definition process (such as depicted in Figure 8.3) correspond to any evolutionaryprocess known for MDE/software in general (for example, to Lehman’s laws of softwareevolution [59])?

• How does our method improve the resulting design of a DSL (and its dynamic semantics)?

• How can we assess the quality of the decomposition/modularization (of the dynamic se-mantics) enhanced by Constelle?

• How does Constelle perform compared to existing (baseline) methods for defining thedynamic semantics of DSLs (or GPLs)?

• How reusable are the specification templates? I.e. how often are they reused in otherdefinitions of the dynamic semantics of DSLs?

• What should be the methodology for introducing (teaching and applying) Constelle inpractice?

8.4 ConclusionsThe validation study revealed a number of challenges of applying Constelle and a number ofbenefits resulting from applying Constelle. Some of them correlate with our previous experience,for example, with the insights gained from defining the Shot puzzle in Constelle by Manders(mentioned in the introduction of this chapter). On the whole, the validation study answeredour initial question: for the specific case of SLCO, the proposed approach is usable (applicable)and in general is useful for defining the dynamic semantics of a DSL in an iterative fashion.Moreover, we learned an important insight about applying our method in practice: a modularapproach might require a change in the mindset of a DSL developer, from thinking about thedynamic semantics of a DSL as a whole to thinking about the dynamic semantics of the DSL asa composition of reusable building blocks.

Chapter 9

Conclusions

In Section 9.1 we give an overview of how our work contributes to the research questions formu-lated in the introduction. In Section 9.2 we propose directions for future work.

9.1 ContributionsIn this thesis we focused on one of the components of a DSL design, its dynamic semantics, andon practical advantages of having its explicit formal definition. In particular, we addressed thefollowing central research question.

RQ: How to define the dynamic semantics of a DSL in a usable and useful way?

This central research question is decomposed into seven more specific questions, addressed inthe chapters of this thesis. The first of these questions deals with the content and structure ofa definition of the dynamic semantics of a DSL, i.e. explores what type of content should becaptured in such a definition and in which form:

RQ1: What constitutes a definition of the dynamic semantics of a DSL?

The second question is closely related to the first one, as it deals with the purpose of adefinition of the dynamic semantics of a DSL, i.e. explores how we aim to use such a definition:

RQ2: What are the requirements for a definition of the dynamic semantics of a DSL?

We addressed these two research questions in Chapter 2. We took a bottom-up approachand defined the dynamic semantics of an existing DSL, called LACE. In this LACE case studywe followed the principles of the pragmatist stance. For this, we first identified our user roles,i.e. who can work with (make use of) a definition of the dynamic semantics of a DSL. Thenwe formulated our use cases, i.e. how our users can make use of a definition of the dynamicsemantics of a DSL. Aiming at realizing these use cases, we chose a specification formalism thathas an extensive tool support: Event-B and Rodin. We implemented the semantic mapping from

154 Conclusions

LACE to Event-B in the form of a QVTo model transformation, which automatically generates anEvent-B specification for an arbitrary LACE model (program). Enhancing such a definition of thedynamic semantics of LACE with the domain-specific (LACE-alike) visualization of resultingEvent-B specifications allowed for demonstrating it to LACE engineers (who cannot use Event-B and Rodin per se) and for conducting the user study. As a result, we got hands-on feedbackfrom both of our user roles.

Based on the feedback of our user roles and based on our own experience and insights gainedduring the case study, we came to conclusions on what should be captured in a definition of thedynamic semantics (i.e. answer research question RQ1) and formulated a list of requirementsboth for such a definition and for a meta-language that allows for such a definition (answer re-search question RQ2). Namely, we identified that a definition of the dynamic semantics of aDSL is usable when it allows for the implementation of various use cases, such as validation andverification of the DSL design, and simulation of DSL programs (models). We identified that adefinition of the dynamic semantics of a DSL is useful when it corresponds to (captures) howDSL programs are actually executed (rather than how DSL programs are expected to behave).The meta-language for constructing such a definition should allow for a DSL-independent mod-ular definition of the dynamic semantics of a DSL given on the level of the DSL metamodel withthe possibility to automatically generate artifacts (specifications) on the model level.

The design of such a meta-language for defining the dynamic semantics of a DSL is addressedin the third research question of this thesis:

RQ3: What are the constructs for defining the dynamic semantics of a DSL?

During our LACE case study we observed that we reuse pieces of our Event-B specifications.Moreover, such pieces, when considered separately, correspond to (software) design solutionsthat appear in the implementation of LACE. From this observation we got the idea of reusablespecification templates that capture typical (software) design solutions. We discuss the broad pic-ture originating from this idea in Chapter 3. In Chapter 4 we use reusable specification templatesas constructs of our meta-language for defining the dynamic semantics of a DSL, Constelle.In this way, we do not propose a (yet another) meta-language, universal for defining dynamicsemantics of all possible DSLs; but we rather propose an intermediate semantic domain, thatsplits the semantic mapping from a DSL to an execution platform (or a specification formalism)into two steps, and support this intermediate semantic domain with the corresponding expressivemeans (Constelle).

The design of Constelle is based on the ideas of the following two approaches well-knownin software engineering: generic programming and aspect oriented programming (AOP). Weuse principles of generic programming to introduce the notion of specification templates andtemplate parameters. We use principles of AOP to express how the dynamic semantics of a DSLis composed of specification templates. In particular, in Constelle the dynamic semantics of aDSL is defined as a composition of aspects, each of which is a specification template specializedby substituting its template (i.e. static) parameters with the constructs of the DSL (defined in itsmetamodel).

To capture the specialization of specification templates and their composition, we introduce atable notation. A Constelle table naturally represents the mapping from the DSL to our interme-diate semantic domain, specification templates: notions and constructs of the DSL (forming theDSL vertical domain) are represented in the table rows, common software solutions (forming theDSL horizontal domain) are represented in the table columns, and the mapping is represented intheir intersections.

Finally, in order to relate invoked (specialized and composed) specification templates in amore sophisticated manner, we introduce gluing guards. We design gluing guards in the same

9.1. Contributions 155

way as specification templates: as constraint templates.Such a (sophisticated) design of our meta-language (Constelle) requires a clear explanation

of its meaning. The fourth research question of our thesis deals with the definition of such ameaning:

RQ4: What is the semantics of the language for defining the dynamic semantics ofa DSL?

We specify the semantics of Constelle in Chapter 6. For this, we describe the (semantic) map-ping of Constelle to Event-B. This semantic mapping is implemented in the Constelle-to-Event-Bmodel transformation that (automatically) transforms a (Constelle) definition of the dynamic se-mantics of a DSL into the corresponding Event-B specification of this dynamic semantics. Thesemantic mapping from Constelle to Event-B builds on top of (wraps) three Event-B techniques:generic instantiation, shared event composition, and refinement. These techniques have a solidtheory and make it possible to reuse proof obligations discharged for the specification templatesin a specification of the DSL dynamic semantics generated from its Constelle definition. As a re-sult, we can identify which proof obligations should be discharged and which proof obligationscan be ignored (reused from the invoked specification templates) in the resulting (generated)Event-B specification of the dynamic semantics.

When designing and describing the semantic mapping from Constelle to Event-B we facedthe following question:

RQ5: How to design and describe the semantics of the language for defining thedynamic semantics of a DSL?

We wanted to have a description of the semantic mapping that is clear (to us and our peers)and that corresponds to (i.e. documents) the actual implementation of this semantic mapping,the QVTo model transformation. Moreover, we wanted to use such a description for (during)developing (designing) our model transformation. Inspired by the ‘mapping nature’ of model-to-model transformations, we adopted the notation of functions (function signatures) and set theoryin order to (informally) describe and design QVTo model transformations. In Chapter 5 wedescribe how we align concepts and constructs of QVTo with the mathematical concepts of settheory and functions. Building on the latter, we formulate two design principles of developingQVTo model transformations: structural decomposition and chaining model transformations.

Our implementation of Constelle includes (Ecore) metamodels of Constelle and specificationtemplates, an editor for the library of specification templates, an editor for Constelle tables,and the Constelle-to-Event-B model transformation. Moreover, we use Rodin for constructingEvent-B specifications, discharging their proof obligations, and simulating (debugging) Event-Bspecifications. Such a combination of various techniques, tools, and formalisms posed a questionof how to use them when defining the dynamic semantics of a DSL. Thus, we faced the followingresearch question:

RQ6: What is the pragmatics of the language for defining the dynamic semantics ofa DSL?

We address this question in Chapter 7 by explicitly formulating a process of defining thedynamic semantics of a DSL using Constelle and specification templates. We relate all the listedtools and techniques to the steps of this definition process and demonstrate how these tools andtechniques can contribute to the iterative design of the dynamic semantics of a DSL.

In the final chapter of this thesis we strive to explore whether our ideas (of reusable specifi-cation templates), our meta-language (Constelle), and our method (the definition process) makesense. For this, we need to design a validation study, i.e. answer the following research question:

156 Conclusions

RQ7: How can we evaluate the language (and the method) for defining the dynamicsemantics of a DSL?

We design a validation study using a number of techniques of empirical methods: actionresearch, the GQM method, and a triangulation strategy. This design of a validation study can beused for conducting validation studies on Constelle in future. In Chapter 8 we describe a concreteinstance of such a validation study and analyze insights gained from it. In particular, we observethe process of defining the dynamic semantics of the SLCO DSL in Constelle by an externalDSL developer. Analyzing our observations allowed for improving the design of Constelle, forhighlighting both limitations and benefits of applying Constelle, and for learning that the keycharacteristic of our method, modular approach for specifying the dynamic semantics, mightrequire a change in the mindset of a DSL developer: from thinking about the dynamic semanticsof a DSL as a whole to thinking about the dynamic semantics of the DSL as a composition ofreusable building blocks.

This outlines our answer to the central research question of this thesis, revisited in the be-ginning of this section. The contribution of our work can be characterized by the combinationof the following features. In order to realize the use cases of having a definition of the dynamicsemantics of a DSL, we adopted the translational approach and targeted a formalism with anextensive tool support. Our meta-language, Constelle, mitigates the known complexity of thetranslational approach by adopting ideas of aspect oriented programming and by using the tablenotation to express the interaction of aspects. Moreover, Constelle introduces an intermediatesemantic domain in the DSL translation: specification templates that capture design solutionsreappearing in the implementation of different DSLs. The well defined semantics of Constelleallows for the reuse of specification templates together with the proof obligations that have beenalready discharged for them. Finally, our work is complimented by the design of a validationstudy that allows for investigating and evaluating the proposed method.

9.2 Future WorkWe drew the inspiration and motivation for our research from the LACE case study presentedin Chapter 2. However, we haven’t applied Constelle to (re)define the dynamic semantics ofLACE. An interesting direction for future work would be to give such a definition of the dynamicsemantics of LACE using Constelle and to explore how it is different compared to our experiencedescribed in Chapter 2 and how often we actually reuse the specification templates identified forLACE (such as Queue and Request).

In Chapter 3 we outline our vision on how the notion of reusable specification templatescan fit into the perspective of the DSL-based development approach: from defining the structureof a DSL using structural templates to generating source code of a DSL model using semantictemplates. Constelle realizes a (core) part of this vision. A logical direction for future workwould be to extend Constelle (its design and implementation) in order to realize other parts ofthe described vision. For example, we could extend the Constelle metamodel with constructs thatrepresent a semantics application - an instance of a definition of the dynamic semantics of a DSLinstantiated for a concrete DSL model. Using such an extension, we could extend the Constelle-to-Event-B transformation in order to generate an Event-B specification for each concrete DSLmodel. This would allow for fulfilling the requirement Req-7 formulated in Chapter 2: formalspecifications of DSL programs should be generated automatically on the model level.

Our main solution, the approach of reusable specification templates for defining the dynamicsemantics of a DSL, is developed in Chapter 4. This approach triggers a number of important

9.2. Future Work 157

research questions that we leave for future work. First, we need to investigate whether a decom-position of the dynamic semantics of a DSL into invocations of reusable specification templatesis always feasible. Note that this question can be related both to the scope (what kind of DSLs aredecomposable into reusable specification templates?) and to the pragmatics (how to decomposethe dynamic semantics of a DSL?) of our method.

Second, we need to build the library of reusable specification templates. The potential candi-dates for specification templates can be found using various methods and empirics. First of all,these can be well-known software design patterns and architecture styles [30], such as Observerand Blackboard patterns, Multi-layered and Peer-to-Peer architectures, etc. Another source ofestablished software development practice is peer-reviewed source code libraries, such as theBoost libraries of C++ code1. For example, such components as Boost Flyweight and BoostGraph Library can be investigated as candidates for specification templates. Following our ideathat specification templates capture a DSL horizontal domain, candidates for specification tem-plates can be derived from constructs of horizontal DSLs. For example, the Reo language [8]uses a common set of primitive communication channels, typical for concurrent applications:synchronous, lossy, buffered, etc. These can be added to our library of specification templates.

Constelle is designed (in Chapter 4), developed, and specified (in Chapter 6) using Event-Bas a back-end formalism. However, in our design we strive to provide a possibility for futurereplacement of Event-B by another specification formalism. This would be beneficial, for ex-ample, for conducting different type of analysis of the dynamic semantics of a DSL. Thus, avaluable direction for future research would be to connect Constelle with and map it to anotherspecification formalism, such as: mCRL2, Uppaal.

In relation to the pragmatics of Constelle and to the definition process (presented in Chapter 7and further studied in Chapter 8), it would be interesting to investigate how Constelle contributesnot only to making design decisions about the dynamic semantics of a DSL, but also to document-ing such decisions. In other words, it would be interesting to see if we could extend Constellewith proper expressive means and incorporate the corresponding steps into the definition processin order to allow for capturing what has changed in a definition of the dynamic semantics of aDSL and why it has changed.

In Chapter 7 we highlight a number of challenges of more technical nature, such as: filteringproof obligations that should be discharged for a generated Event-B specification, according tothe scheme defined in Chapter 6; development of an inverse mapping from compilation and/oranalysis results provided by Rodin tools to the concepts and constructs used in a Constelle defi-nition.

Finally, the validation study presented in Chapter 8 is a first step of validating and evaluatingour method. More validation studies and further evaluation are necessary. Next to the questionslisted in Chapter 8, we consider the following research questions as the most important for fu-ture research: how to identify specification templates and how reusable are these specificationtemplates across various application domains; what is the scope of Constelle, i.e. what kind ofDSLs can be defined using Constelle and specification templates; how scalable is the proposedapproach, i.e. whether the benefits of applying it to a real (industrial-size) DSL are worth theeffort.

1www.boost.org

www.boost.org

Bibliography

[1] Jean-Raymond Abrial. The B-book: Assigning Programs to Meanings. Cambridge Uni-versity Press, 1996.

[2] Jean-Raymond Abrial. Modeling in Event-B: system and software engineering. Cam-bridge University Press, 2010.

[3] Jean-Raymond Abrial, Michael Butler, Stefan Hallerstede, Thai Son Hoang, FarhadMehta, and Laurent Voisin. Rodin: An Open Toolset for Modelling and Reasoningin Event-B. International Journal on Software Tools for Technology Transfer (STTT),12(6):447–466, 2010. URL: http://eprints.soton.ac.uk/271058/.

[4] Jean-Raymond Abrial and Stefan Hallerstede. Refinement, Decomposition, and Instanti-ation of Discrete Models: Application to Event-B. Fundam. Inform., 77(1-2):1–28, 2007.

[5] Alfred Aho, Ravi Sethi, and Jeffrey Ullman. Compilers: Principles, Techniques, andTools. Addison-Wesley, 1986.

[6] Idir Ait-Sadoune and Yamine Ait-Ameur. Stepwise Design of BPEL Web Services Com-positions: An Event-B Refinement Based Approach. In Roger Lee, Olga Ormandjieva,Alain Abran, and Constantinos Constantinides, editors, Software Engineering Research,Management and Applications 2010, pages 51–68. Springer Berlin / Heidelberg, 2010.URL: http://dx.doi.org/10.1007/978-3-642-13273-5_4.

[7] Suzana Andova, Mark van den Brand, and Luc Engelen. Prototyping the semantics of aDSL using ASF+SDF: link to formal verification of DSL models. In Francisco Durán andVlad Rusu, editors, Proceedings Second International Workshop on Algebraic Methods inModel-based Software Engineering, AMMSE 2011, Zurich, Switzerland, 30th June 2011,volume 56 of EPTCS, pages 65–79, 2011.

[8] Farhad Arbab. Proper protocol. In Erika Ábrahám, Marcello Bonsangue, and Broch EinarJohnsen, editors, Theory and Practice of Formal Methods: Essays Dedicated to Frank deBoer on the Occasion of His 60th Birthday, pages 65–87. Springer, 2016.

[9] Nils Bandener, Christian Soltenborn, and Gregor Engels. Extending DMM BehaviorSpecifications for Visual Execution and Debugging. In Brian A. Malloy, Steffen Staab,

http://eprints.soton.ac.uk/271058/

http://dx.doi.org/10.1007/978-3-642-13273-5_4

160 Bibliography

and Mark van den Brand, editors, Software Language Engineering (SLE), pages 357–376,2010.

[10] David A. Basin, Andreas Fürst, Thai Son Hoang, Kunihiko Miyazaki, and Naoto Sato.Abstract Data Types in Event-B – An Application of Generic Instantiation. In Workshopon the experience of and advances in developing dependable systems in Event-B, CoRR,pages 5–16, 2012.

[11] Henning Berg and Birger Møller-Pedersen. Type-Safe Symmetric Composition of Meta-models Using Templates. System Analysis and Modeling: Theory and Practice, pages160–178, 2013.

[12] J. A. Bergstra, J. Heering, and P. Klint, editors. Algebraic Specification. ACMPress/Addison-Wesley, 1989.

[13] Sandrine Blazy, Frédéric Gervais, and Régine Laleau. Reuse of Specification Patterns withthe B Method. In ZB 2003: Formal Specification and Development in Z and B, volume2651 of Lecture Notes in Computer Science, pages 40–57. Springer Berlin Heidelberg,2003.

[14] Rimco C. Boudewijns. Graphical simulation of the execution of DSL models. Master’sthesis, Eindhoven University of Technology, 2013.

[15] Kai Chen, Joseph Porter, Janos Sztipanovits, and Sandeep Neema. Compositional Spec-ification Of Behavioral Semantics For Domain-Specific Modeling Languages. Int. J. Se-mantic Computing, 3:31–56, 2009.

[16] Kai Chen, Janos Sztipanovits, Sherif Abdelwalhed, and Ethan Jackson. Semantic Anchor-ing with Model Transformations. European Conference on Model Driven Architecture -Foundations and Applications, pages 115–129, 2005.

[17] Andrei Chis, Tudor Gîrba, and Oscar Nierstrasz. The Moldable Debugger: A Frameworkfor Developing Domain-Specific Debuggers. In Software Language Engineering (SLE),pages 102–121, 2014.

[18] Thomas Cleenewerck and Ivan Kurtev. Separation of concerns in translational semanticsfor dsls in model engineering. In Yookun Cho, Roger L. Wainwright, Hisham Haddad,Sung Y. Shin, and Yong Wan Koo, editors, Proceedings of the 2007 ACM Symposiumon Applied Computing (SAC), Seoul, Korea, March 11-15, 2007, pages 985–992. ACM,2007.

[19] Benoît Combemale, Xavier Crégut, Pierre-Loïc Garoche, and Xavier Thirioux. Essay onsemantics definition in MDE - an instrumented approach for model verification. JSW,4(9):943–958, 2009.

[20] Julie Wolfram Cox. Action Research, pages 371–388. SAGE, 2012.

[21] K. Czarnecki and S. Helsen. Feature-based Survey of Model Transformation Approaches.IBM Syst. J., 45(3):621–645, July 2006.

[22] Pierre-Evariste Dagand, Andrew Baumann, and Timothy Roscoe. Filet-o-Fish: Practicaland Dependable Domain-Specific Languages for OS Development. In Proceedings ofthe 5th Workshop on Programming Languages and Operating Systems, PLOS ’09, pages5:1–5:5. ACM, October 2009.

Bibliography 161

[23] Thomas Degueule. Composition and Interoperability for External Domain-Specific Lan-guage Engineering. (Composition et interopérabilité pour l’ingénierie des langages dédiésexternes). PhD thesis, University of Rennes 1, France, 2016.

[24] A. van Deursen, J. Heering, and P. Klint, editors. Language Prototyping: An AlgebraicSpecification Approach, volume 5 of AMAST Series in Computing. World Scientific, 1996.

[25] Arie Van Deursen, Paul Klint, and Joost Visser. Domain-specific languages: An annotatedbibliography. ACM SIGPLAN NOTICES, 35:26–36, 2000.

[26] Steve Easterbrook, Janice Singer, Margaret-Anne Storey, and Daniela Damian. SelectingEmpirical Methods for Software Engineering Research. Guide to Advanced EmpiricalSoftware Engineering, pages 285–311, 2008.

[27] Luc Engelen. From Napkin Sketches to Reliable Software. PhD thesis, Eindhoven Univer-sity of Technology, 2012.

[28] Anne Etien, Cedric Dumoulin, and Emanuel Renaux. Towards a Unified Notation toRepresent Model Transformation. Research Report 6187, INRIA, May 2007.

[29] Martin Fowler. Domain-Specific Languages. Addison-Wesley Signature Series, 2010.

[30] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Ele-ments of Reusable Object-Oriented Software. Addison Wesley, 1994.

[31] Christine M. Gerpheide, Ramon R. H. Schiffelers, and Alexander Serebrenik. A Bottom-Up Quality Model for QVTo. In QUATIC, pages 85–94. IEEE, 2014.

[32] Jan Friso Groote and Mohammad Reza Mousavi. Modeling and Analysis of Communicat-ing Systems. MIT Press, 2014.

[33] Esther Guerra, Juan de Lara, Dimitrios Kolovos, Richard Paige, and Osmar dos San-tos. Engineering model transformations with transML. Software and Systems Modeling,12(3):555–577, 2013.

[34] Stefan Hallerstede. The Event-B Proof Obligation Generator.

[35] Dominik Hansen, Lukas Ladenberger, Harald Wiegard, Jens Bendisposto, and MichaelLeuschel. Validation of the ABZ Landing Gear System Using ProB. In ABZ 2014: TheLanding Gear Case Study, pages 66–79, 2014.

[36] Joni Helin, Pertti Kellomäki, and Tommi Mikkonen. Patterns of Collective Behavior inOcsid. In Toufik Taibi, editor, Design Pattern Formalization Techniques, pages 73–93,Hershey, PA, USA, 2007. IGI Global.

[37] T. Hoang, A. McIver, L. Meinicke, C. Morgan, A. Sloane, and E. Susatyo. Abstractions ofnon-interference security: probabilistic versus possibilistic. Formal Aspects of Computing,pages 1–26, 2012.

[38] Thai Son Hoang, Andreas Fürst, and Jean-Raymond Abrial. Event-B patterns and theirtool support. Software and System Modeling, 12(2):229–244, 2013.

[39] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.

162 Bibliography

[40] Akram Idani, Yves Ledru, and Adil Anwar. A Rigorous Reasoning about Model Trans-formations Using the B Method. In BPMDS, pages 426–440, 2013.

[41] Michael Jackson. Designing and Coding Program Structures. In Henry P Stevenson, ed-itor, Proceedings of a Codasyl Programming Language Committee Symposium on Struc-tured Programming in COBOL - Future and Present, pages 22–53, 1975.

[42] Michael Jackson. JSP in Perspective. In Manfred Broy and Ernst Denert, editors, SoftwarePioneers, pages 480–493. Springer-Verlag New York, Inc., 2002.

[43] Michael Jastram. Rodin User’s Handbook. 2012.

[44] Jean-Marc Jézéquel, Benoît Combemale, Olivier Barais, Martin Monperrus, and FrançoisFouquet. Mashup of metalanguages and its implementation in the kermeta language work-bench. Software and Systems Modeling, 14:905–920, May 2015.

[45] Audris Kalnins, Janis Barzdins, and Edgars Celms. Model Transformation LanguageMOLA. In MDAFA, pages 62–76, 2004.

[46] P. Kellomaki. Composing distributed systems from reusable aspects of behavior. In Dis-tributed Computing Systems Workshops, IEEE Press, pages 481–486, 2002.

[47] Pertti Kellomäki. A Formal Basis for Aspect-Oriented Specification with Superposition.In The FOAL workshop on Foundations of Aspect-Oriented Languages, pages 27–32,2002.

[48] Pertti Kellomäki and Tommi Mikkonen. Design Templates for Collective Behavior. InECOOP 14th European Conference on Object-Oriented Programming, pages 277–295,2000.

[49] Gregor Kiczales, John Lamping, Anurag Mendhekar, Chris Maeda, Cristina VideiraLopes, Jean-Marc Loingtier, and John Irwin. Aspect-Oriented Programming. In ECOOP,pages 220–242, 1997.

[50] Jörg Kienzle, Wisam Al Abed, and Jacques Klein. Aspect-oriented Multi-view Modeling.In Proceedings of the 8th ACM International Conference on Aspect-oriented SoftwareDevelopment, AOSD ’09, pages 87–98, 2009.

[51] Anneke Kleppe. Software Language Engineering: Creating Domain-Specific LanguagesUsing Metamodels. Addison-Wesley, 2008.

[52] Pawel Kmiec. The Unofficial LEGO Technic Builder’s Guide. No Starch Press, 2013.

[53] Tomaz Kosar, Sudev Bohra, and Marjan Mernik. Domain-specific languages: A system-atic mapping study. Information & Software Technology, 71:77–91, 2016.

[54] Ivan Kurtev. State of the Art of QVT: A Model Transformation Language Standard. InAndy Schürr, Manfred Nagl, and Albert Zündorf, editors, AGTIVE, Lecture Notes in Com-puter Science, pages 377–393, 2008.

[55] Lukas Ladenberger, Jens Bendisposto, and Michael Leuschel. Visualising Event-B Mod-els with B-Motion Studio. In Formal Methods for Industrial Critical Systems, FMICS2009, pages 202–204, 2009.

Bibliography 163

[56] Lukas Ladenberger, Ivaylo Dobrikov, and Michael Leuschel. An Approach for CreatingDomain Specific Visualisations of CSP Models. In Software Engineering and FormalMethods - SEFM 2014 Collocated Workshops: HOFM, SAFOME, OpenCert, MoKMaSD,WS-FMDS, Grenoble, France, September 1-2, 2014, Revised Selected Papers, pages 20–35, 2014.

[57] Kevin Lano. Model transformation design pattern catalogue. http://www.dcs.kcl.ac.uk/staff/kcl/mtdp, Date of access August 2015.

[58] Kevin Lano and Shekoufeh Kolahdouz Rahimi. Model-Transformation Design Patterns.IEEE Trans. Software Eng., 40(12):1224–1259, 2014.

[59] Meir M. Lehman. On understanding laws, evolution, and conservation in the large-program life cycle. Journal of Systems and Software, 1:213–221, 1980.

[60] Michael Leuschel and Michael J. Butler. ProB: A Model Checker for B. In InternationalSymposium of Formal Methods Europe (FME), Pisa, Italy, pages 855–874, 2003.

[61] Michael Y. Levin and Benjamin C. Pierce. Tinkertype: a language for playing with formalsystems. J. Funct. Program., 13(2):295–316, 2003.

[62] Yaping Luo, Mark van den Brand, Luc Engelen, John M. Favaro, Martijn Klabbers, andGiovanni Sartori. Extracting models from ISO 26262 for reusable safety assurance. InSafe and Secure Software Reuse - 13th International Conference on Software Reuse, ICSR2013, Pisa, Italy, June 18-20. Proceedings, pages 192–207, 2013.

[63] Maarten Manders. Understanding Execution. PhD thesis, Eindhoven University of Tech-nology.

[64] Raphael Mannadiar and Hans Vangheluwe. Domain-specific Engineering of Domain-specific Languages. In Proceedings of the 10th Workshop on Domain-Specific Modeling,DSM ’10, pages 11:1–11:6. ACM, 2010.

[65] Aad Mathijssen and A. Johannes Pretorius. Verified Design of an Automated ParkingGarage. In Formal Methods: Applications and Technology, 11th International WorkshopFMICS, Revised Selected Papers, pages 165–180, 2006.

[66] Sjouke Mauw, Wouter T. Wiersma, and Tim A. C. Willemse. Language-driven sys-tem design. International Journal of Software Engineering and Knowledge Engineering,14(6):625–663, 2004.

[67] Tanja Mayerhofer. Defining Executable Modeling Languages with fUML. PhD thesis,Vienna University of Technology, 2014.

[68] Tom Mens and Pieter Van Gorp. A Taxonomy of Model Transformation. Electr. NotesTheor. Comput. Sci., 152:125–142, 2006.

[69] Bart Meyers, Antonio Cicchetti, Esther Guerra, and Juan de Lara. Composing textualmodelling languages in practice. In Proceedings of the 6th International Workshop onMulti-Paradigm Modeling, MPM@MoDELS 2012, Innsbruck, Austria, October 1-5, 2012,pages 31–36, 2012.

[70] Peter Mosses. Theory and practice of action semantics. In Wojciech Penczek and AndrzejSzalas, editors, Mathematical Foundations of Computer Science 1996, volume 1113 ofLecture Notes in Computer Science, pages 37–61. Springer Berlin / Heidelberg, 1996.

http://www.dcs.kcl.ac.uk/staff/kcl/mtdp

http://www.dcs.kcl.ac.uk/staff/kcl/mtdp

164 Bibliography

[71] Peter D. Mosses. Modular structural operational semantics. J. Log. Algebr. Program.,60-61:195–228, 2004.

[72] David Musser and Alexander A. Stepanov. Generic Programming. In Symbolic and alge-braic computation: ISSAC 88, pages 13–25. Springer, 1988.

[73] Hanne Riis Nielson and Flemming Nielson. Semantics with Applications: A Formal In-troduction. Wiley, 1992.

[74] OMG. Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, Febru-ary 2015. Version 1.2.

[75] Luís Pedro. A Systematic Language Engineering Approach for Prototyping Domain Spe-cific Modelling Languages. Phd dissertation, University of Geneva, January 2009.

[76] Luís Pedro, Vasco Amaral, and Didier Buchs. Foundations for a Domain Specific Mod-eling Language Prototyping Environment: A compositional approach. In Proceedings ofthe 8th OOPSLA ACM-SIGPLAN Workshop on Domain-Specific Modeling (DSM), 2008.

[77] Luis Pedro, Matteo Risoldi, Didier Buchs, Bruno Barroca, and Vasco Amaral. ComposingVisual Syntax for Domain Specific Languages. In Human-Computer Interaction. NovelInteraction Methods and Techniques, 13th International Conference, HCI International2009, San Diego, CA, USA, July 19-24, 2009, Proceedings, Part II, pages 889–898, 2009.

[78] Gordon D. Plotkin. A Structural Approach to Operational Semantics. The Journal ofLogic and Algebraic Programming, 60-61:17–139, 2004.

[79] Lukman Ab. Rahim and Sharifah Bahiyah Rahayu Syed Mansoor. Proposed Design No-tation for Model Transformation. In ASWEC, pages 589–598. IEEE Computer Society,2008.

[80] Shekoufeh Kolahdouz Rahimi and Kevin Lano. A Model-Based Development Approachfor Model Transformations. In Fundamentals of Software Engineering - 4th IPM Interna-tional Conference, FSEN 2011, Tehran, Iran, April 20-22, 2011, Revised Selected Papers,pages 48–63, 2011.

[81] Daniel Ratiu, Markus Voelter, Zaur Molotnikov, and Bernhard Schaetz. ImplementingModular Domain Specific Languages and Analyses. In Proceedings of the Workshop onModel-Driven Engineering, Verification and Validation, pages 35–40, 2012.

[82] Grigore Rosu and Traian-Florin Serbanuta. An overview of the K semantic framework. J.Log. Algebr. Program., 79(6):397–434, 2010.

[83] Per Runeson and Martin Höst. Guidelines for conducting and reporting case study researchin software engineering. Empirical Softw. Engg., 14(2):131–164, April 2009.

[84] Christian Schäfer, Thomas Kuhn, and Mario Trapp. A Pattern-based Approach to DSL De-velopment. In Proceedings of the Compilation of the Co-located Workshops on DSM’11,TMC’11, AGERE!’11, AOOPES’11, NEAT’11, & VMIL’11, SPLASH ’11 Work-shops, pages 39–46. ACM, 2011.

[85] Markus Scheidgen and Joachim Fischer. Human Comprehensible and Machine Process-able Specifications of Operational Semantics. In Model Driven Architecture- Foundationsand Applications, volume 4530 of Lecture Notes in Computer Science, pages 157–171.Springer Berlin Heidelberg, 2007.

Bibliography 165

[86] Douglas C. Schmidt. Guest editor’s introduction: Model-driven engineering. IEEE Com-puter, 39(2):25–31, 2006.

[87] Renato Silva. Supporting Development of Event-B Models. PhD thesis, University ofSouthampton, UK, 2012.

[88] Renato Silva and Michael Butler. Supporting Reuse of Event-B Developments throughGeneric Instantiation. In Karin Breitman and Ana Cavalcanti, editors, 11th InternationalConference on Formal Engineering Methods, ICFEM, volume 5885 of Lecture Notes inComputer Science, pages 466–484. Springer, 2009.

[89] Renato Silva and Michael Butler. Shared Event Composition/Decomposition in Event-B.In Bernhard K. Aichernig, Frank S. de Boer, and Marcello M. Bonsangue, editors, FormalMethods for Components and Objects (FMCO), pages 122–141. Springer, 2010.

[90] Gabor Simko. Formal Semantic Specification of Domain-Specific Modeling Languages forCyber-Physical Systems. Phd dissertation, Vanderbilt University, Nashville, Tennessee,August 2014. Chapter 6: Reusable Semantic Units for Formalizing the Denotational Se-mantics of CPS Modeling Languages, pages 59–75.

[91] Colin Snook and Michael Butler. UML-B: Formal Modeling and Design Aided by UML.ACM Trans. Softw. Eng. Methodol., 15(1):92–122, 2006.

[92] Colin Snook, Fabian Fritz, and Alexei Illisaov. An EMF framework for Event-B. InWorkshop on Tool Building in Formal Methods – ABZ Conference, 2010.

[93] Rini Van Solingen and Egon Berghout. Goal/Question/Metric Method: A Practical Guidefor Quality Improvement of Software Development. McGraw-Hill, 1999.

[94] Frank P. M. Stappers, Sven Weber, Michel A. Reniers, Suzana Andova, and Istvan Nagy.Formalizing a Domain Specific Language Using SOS: An Industrial Case Study. In Soft-ware Language Engineering - 4th International Conference, SLE 2011, Braga, Portugal,July 3-4, 2011, Revised Selected Papers, pages 223–242, 2011.

[95] Frank Petrus Maria Stappers. Bridging Formal Models: An Engineering Perspective. PhDDissertation, Eindhoven University of Technology, November 2012. Chapter 6: Dissemi-nating Verification Results, pages 109–125.

[96] Ulyana Tikhonova. Reusable Specification Templates for Defining Dynamic Semantics ofDSLs. Software and Systems Modeling (SoSyM), 2017.

[97] Ulyana Tikhonova, Maarten Manders, and Rimco Boudewijns. Visualization of FormalSpecifications for Understanding and Debugging an Industrial DSL. In Human OrientedFormal Methods (HOFM), 2016.

[98] Ulyana Tikhonova, Maarten Manders, Mark van den Brand, Suzana Andova, and TomVerhoeff. Applying Model Transformation and Event-B for Specifying an Industrial DSL.In MoDeVVa@MoDELS, pages 41–50, 2013.

[99] Ulyana Tikhonova and Tim Willemse. Designing and Describing QVTo Model Trans-formations. In ICSOFT-EA 2015 - Proceedings of the 10th International Conference onSoftware Engineering and Applications, Colmar, Alsace, France, 20-22 July, 2015, pages401–406.

166 Bibliography

[100] Ulyana Tikhonova and Tim A. C. Willemse. Documenting and Designing QVTo ModelTransformations Through Mathematics. In Software Technologies - 10th InternationalJoint Conference, ICSOFT 2015, Colmar, France, July 20-22, 2015, Revised SelectedPapers, pages 349–364, 2015.

[101] Marcel van Amstel. Assessing and Improving the Quality of Model Transformations. PhDthesis, Eindhoven University of Technology, 2012.

[102] Marcel van Amstel, Mark van den Brand, and Luc Engelen. An exercise in iterativedomain-specific language design. In Proceedings of the Joint ERCIM Workshop on Soft-ware Evolution (EVOL) and International Workshop on Principles of Software Evolution(IWPSE), IWPSE-EVOL ’10, pages 48–57, 2010.

[103] Marcel van Amstel, Mark G. J. van den Brand, Zvezdan Protic, and Tom Verhoeff. Trans-forming Process Algebra Models into UML State Machines: Bridging a Semantic Gap?In Antonio Vallecillo, Jeff Gray, and Alfonso Pierantonio, editors, ICMT, volume 5063 ofLecture Notes in Computer Science, pages 61–75. Springer, 2008.

[104] Mark van den Brand, B. Cornelissen, Pieter A. Olivier, and Jurgen J. Vinju. TIDE: Ageneric debugging framework - tool demonstration. Electr. Notes Theor. Comput. Sci.,141(4):161–165, 2005.

[105] Louis van Gool, Teade Punter, Marc Hamilton, and Remco van Engelen. CompositionalMDA. In Model Driven Engineering Languages and Systems, 9th International Confer-ence (MoDELS), pages 126–139, 2006.

[106] Vlad A. Vergu, Pierre Neron, and Eelco Visser. DynSem: A DSL for Dynamic SemanticsSpecification. In 26th International Conference on Rewriting Techniques and Applica-tions, RTA, pages 365–378, 2015.

[107] Eelco Visser. Program transformation with stratego/xt: Rules, strategies, tools, and sys-tems in stratego/xt 0.9. In Domain-Specific Program Generation, International Seminar,pages 216–238, 2003.

[108] David A. Watt and Thomas Muffy. Programming Language Syntax and Semantics. Pren-tice Hall International Series in Computer Science, 1991.

[109] Jia Zhang. Pattern specification and application in meta-models in Ecore. Master’s thesis,Eindhoven University of Technology, 2016.

Appendix A

Event-B Specification Templates

168 Event-B Specification Templates

CONTEXT template variable context

SETSVariableType

END

(a) Event-B context for the Variable specification template

MACHINE template variable machine

SEES template variable context

VARIABLESvariable

INVARIANTS

inv1 : variable ∈ V ariableType

EVENTS

Initialisation

beginact1 : variable :∈ V ariableType

end

Event assign =

any value

wheregrd1 : value ∈ V ariableTypethenact1 : variable := value

end

Event query =

any value

wheregrd1 : value = variablethen

skipend

END

(b) Event-B machine for the Variable specification template

Figure A.1: Specification template Query/Variable

169

CONTEXT template queue context

SETS

ElementType

END

(a) Event-B context for the Queue specification template



VARIABLESqueue

INVARIANTS


EVENTS

Initialisation


end

Event enqueue =

any element, index



end

Event dequeue =

any element, index


end

END

(b) Event-B machine for the Queue specification template

Figure A.2: Specification template Queue

170 Event-B Specification Templates

CONTEXT template request context

SETS

ElementType

END

(a) Event-B context for the Request specification template

MACHINE template request machine

SEES template request context

VARIABLESrequest body

INVARIANTS

inv1 : request body ∈ P(ElementType)

EVENTS

Initialisation

beginact1 : request body := ∅

end

Event request =

any elements

wheregrd1 : elements ∈ P(ElementType)grd2 : request body = ∅thenact2 : request body := elements

end

Event process =

any element

wheregrd3 : element ∈ request bodythenact3 : request body :=

request body \ {element}end

END

(b) Event-B machine for the Request specification template

Figure A.3: Specification template Request

CONTEXT template partialorder context

SETS

PosetElement

END

(a) Event-B context for the Partial Order specification template

171

MACHINE template partialorder machine

SEES template partialorder context

VARIABLESposetBody, posetOrder

INVARIANTS

inv1 : posetBody ⊆ PosetElement

inv2 : posetOrder ∈ posetBody↔ posetBody

inv3 : ∀x, y ·x 7→ y ∈ posetOrder⇒ x 6= y

inv4 : ∀x, y ·x 7→ y ∈ posetOrder⇒ y 7→ x /∈ posetOrder

inv5 : ∀a, b, c·a 7→ b ∈ posetOrder ∧ b 7→ c ∈ posetOrder⇒ a 7→ c ∈ posetOrder

EVENTS

Initialisation

beginact1 : posetBody := ∅act2 : posetOrder := ∅

end

Event NewPartialOrder =

any poset, order

wheregrd1 : poset ⊆ PosetElementgrd2 : order ∈ poset↔ posetgrd3 : ∀x, y ·x 7→ y ∈ order⇒ x 6= ygrd4 : ∀x, y ·x 7→ y ∈ order⇒ y 7→ x /∈ ordergrd5 : ∀a, b, c·a 7→ b ∈ order ∧ b 7→ c ∈ order⇒ a 7→ c ∈ orderthenact1 : posetBody := posetact2 : posetOrder := order

end

Event GetMaximalElement =

any maximal

wheregrd1 : maximal ∈ posetBodygrd2 : ∀x·x ∈ posetBody ∧ x 6= maximal⇒maximal 7→ x /∈ posetOrderthen

skipend

Event RemoveElement =

any element, elementRelations

wheregrd1 : element ∈ PosetElementgrd2 : elementRelations = {x, y ·x 7→ y ∈ posetOrder ∧ (x = element ∨ y = element)|x 7→ y}thenact1 : posetBody := posetBody \ {element}act2 : posetOrder := posetOrder \ elementRelations

end

END

(b) Event-B context for the Partial Order specification template

Figure A.3: Specification template Partial Order

Appendix B

Event-B Specification of Robotic Arm Parallel

CONTEXT roboticarm structure context

SETSActions

CONSTANTS

HandActions

ArmActions

TURN LEFT

TURN RIGHT

MOV E UP

MOV E DOWN

GRAB

RELEASE

ROTATE LEFT

ROTATE RIGHT

AXIOMS

axm1 : partition(Actions,ArmActions,HandActions)

axm2 : partition(ArmActions, {TURN LEFT}, {MOV E UP},{TURN RIGHT}, {MOV E DOWN})

axm3 : partition(HandActions, {GRAB}, {RELEASE},{ROTATE LEFT}, {ROTATE RIGHT})

END

Figure B.1: Event-B context for the Robotic Arm DSL

174 Event-B Specification of Robotic Arm Parallel

MACHINE RoboticArmParallel machine

SEES roboticarm structure context

VARIABLESdriver1 queue, driver2 queue, distributor request body

INVARIANTS

distributor inv1 : distributor request body ∈ P(Actions)

driver2 inv1 : driver2 queue ∈ N 7→HandActions

driver1 inv1 : driver1 queue ∈ N 7→ArmActions

EVENTS

Initialisation

begindriver1 act1 : driver1 queue := ∅driver2 act1 : driver2 queue := ∅distributor act1 : distributor request body := ∅

end

Event taskStm =

any task

wheredistributor grd1 : task ∈ P(Actions)distributor grd2 : distributor request body = ∅thendistributor act1 : distributor request body := task

end

Event handActionStm =

any driver2 index, action

wheredistributor grd1 : action ∈ distributor request bodydriver2 grd1 : action ∈ HandActionsdriver2 grd2 : driver2 index ∈ Ndriver2 grd3 : driver2 queue 6= ∅⇒ (∀i·i ∈ dom(driver2 queue)⇒ driver2 index > i)driver2 grd4 : {driver2 index 7→ action} ∈ N 7→HandActionsdriver2 grd5 : driver2 index /∈ dom(driver2 queue)thendistributor act1 : distributor request body := distributor request body \ {action}driver2 act1 : driver2 queue := driver2 queue ∪ {driver2 index 7→ action}

end



wheredistributor grd1 : action ∈ distributor request bodydriver1 grd1 : action ∈ ArmActionsdriver1 grd2 : driver1 index ∈ Ndriver1 grd3 : driver1 queue 6= ∅⇒ (∀i·i ∈ dom(driver1 queue)⇒ driver1 index > i)driver1 grd4 : {driver1 index 7→ action} ∈ N 7→ArmActionsdriver1 grd5 : driver1 index /∈ dom(driver1 queue)thendistributor act1 : distributor request body := distributor request body \ {action}driver1 act1 : driver1 queue := driver1 queue ∪ {driver1 index 7→ action}

end

Event executeArm =


wheredriver1 grd1 : driver1 index 7→ action ∈ driver1 queuedriver1 grd2 : ∀i·i ∈ dom(driver1 queue)⇒ driver1 index ≤ i

(a) part 1

175

An Event-B Specification of RoboticArmParallel machine Page 2 of 2

thendriver1 act1 : driver1 queue := driver1 queue \ {driver1 index 7→ action}

end

Event executeHand =


wheredriver2 grd1 : driver2 index 7→ action ∈ driver2 queuedriver2 grd2 : ∀i·i ∈ dom(driver2 queue)⇒ driver2 index ≤ ithendriver2 act1 : driver2 queue := driver2 queue \ {driver2 index 7→ action}

end

END

(b) part 2

Figure B.1: Event-B machine for the semantic module Robotic Arm Parallel

Appendix C

Questionnaires

C.1 Baseline Questionnaire

Questions Choices for answers1.a Have you been developing domain specific languages

(DSLs) before?yes/no

1.b How many DSLs have you implemented and/orparticipated in the implementation of?

open question

2. For how many DSLs have you defined a formal(mathematically rigorous) specification of

2.a • DSL (abstract) syntax? open question2.b • DSL (execution/behavioral) semantics? open question

3. Which specification formalisms do you know for specifyingsoftware? And to which extent do you know theseformalisms?

3.a • You can read specifications in: open question3.b • You can write specifications in: open question3.c • You can apply analysis tools to a specification in: open question4. To which extent do you know the Event-B formalism?4.a • You can read Event-B specifications4.b • You can write Event-B specifications yes/no4.c • You can simulate (animate/execute) an Event-B specification yes/no4.d • You can model check an Event-B specification yes/no

178 Questionnaires

4.e • You can interpret proof obligations generated for an Event-Bspecification

yes/no

4.f • You can use interactive prover to discharge proof obligationsthat were not discharged automatically by the Rodin tools

yes/no

5. How well do you know and/or understand the SLCO DSL(that you are going to specify)?

5.a • You have clear understanding of the application domain ofthe DSL (who, when, and how is going to use this DSL)

to the extent of100%(yes) – 0%(no)

5.b • You have clear understanding of the DSL (what are the DSLconcepts and what are the relations between them)

for 100% – 0%of the DSL concepts

5.c • You have clear understanding of the DSL graphical syntax(how DSL concepts are represented in the graphical notation)


5.d • You have clear understanding of the DSL textual syntax(how DSL concepts are represented in text)


5.e • You have clear understanding of the intended behaviorof the DSL concepts (how they are applied in practice)


5.f • You have clear understanding of the DSL implementationdesign (how the intended behavior of the DSL concepts isimplemented)


5.g • How many example DSL programs have you considered(looked into or written)?

open question

Table C.1: Baseline Questionnaire

C.2 Logbook Questionnaire

C.2.1 Add new semantic module <put name here>1. Criteria that were used to identify this semantic module: <delete inapplicable>

(a) independence of the semantics when being used by a DSL practitioner

(b) independence of the semantics when being implementated by a DSL developer

(c) independence of the semantics specified for a subset of the DSL concepts (subset ofthe DSL metamodel)

(d) hiding a (difficult) design decision <specify which design decision>

(e) other, please specify:

2. This semantic module appeared as a result of learning from: <delete inapplicable>

(a) from the DSL metamodel

(b) from the example models

(c) from the DSL (concrete) syntax definition

C.2. Logbook Questionnaire 179

(d) from the transformations of the DSL to other languages <specify to which lan-guages>

(e) from comparing with other DSLs <specify with which DSLs>

(f) from a talk with the DSL author

(g) from validation of the Constelle definition using <specify which tool you used forthe validation (Constelle table editor, Rodin animator, etc.)>

(h) from inconsistencies found out when defining the DSL in Constelle

(i) other, please specify:

3. There were alternative design solutions that were discarded because: <delete inapplicable>

(a) No alternative solutions were considered

(b) The alternative solution was not possible to implement in Constelle

(c) The alternative solution was not correct according to the knowledge obtained aboutthe DSL

(d) The alternative solution was not considered optimal/efficient/elegant

(e) Other <please specify>

C.2.2 Change semantic module <put name here>1. This semantic module was: <delete inapplicable>

(a) decomposed into other semantic modules

(b) replaced by another semantic module(s)

(c) merged with another semantic module(s)

(d) identified as a specification template and specified in Event-B

(e) other <please specify>

2. The changes were made as a result of learning from: <delete inapplicable>

(a) from the DSL metamodel

(b) from the example models

(c) from the DSL (concrete) syntax definition

(d) from the transformations of the DSL to other languages <specify to which lan-guages>

(e) from comparing with other DSLs <specify with which DSLs>

(f) from a talk with the DSL author

(g) from validation of the Constelle definition using <specify which tool you used forthe validation (Constelle table editor, Rodin animator, etc.)>

(h) from inconsistencies found out when defining the DSL in Constelle

(i) other <please specify>

3. There were alternative design solutions that were discarded because: <delete inapplicable>

(a) No alternative solutions were considered

180 Questionnaires

(b) The alternative solution was not possible to implement in Constelle

(c) The alternative solution was not correct according to the knowledge learnt about theDSL

(d) The alternative solution was not considered optimal/efficient/elegant

(e) Other <please specify>

C.2.3 Apply workaround for <put name here>1. The problem/challenge that is solved has: <delete inapplicable>

(a) technical nature

(b) conceptual nature

2. The problem/challenge is: <please describe the problem/challenge>

3. The workaround was found as a result of: <delete inapplicable>

(a) experience (try and fail)

(b) investigation of the source code of the Constelle tools

(c) reading documentation of the tool

(d) consultation provided by Ulyana

C.3 Final Questionnaire

Questions Choices for answers

0.a. How would you classify the dynamic semanticsof the DSL, that you have been specifyingin Constelle

• Operational (Mapping DSLconcepts to operations)• Denotational (Mapping DSLconcepts to concepts)• Axiomatic (axioms andtheorems)

0.b. Do you know how this dynamic semantics isimplemented? (as a translator or an interpreter)

yes/no

C.3. Final Questionnaire 181

0.c. Is your specification coherent with the actualimplementation of the DSL dynamic semantics?

• Yes, completely coherent;• The specification abstractsaway certain details;• Certain details are specifieddifferently than actuallyimplemented;• The specification specifiesrather abstract propertiesthan the actual implementation• The specification is notcoherent with the actualimplementation

1.a. How many iterations did you make whenspecifying the dynamic semantics of the DSL?

open question

1.b. If more than two, can you name these iterations?(i.e. what determined each of these iterations)

open question

1.c. Would be there more iterations if you continuedspecifying the DSL dynamic semantics?How many?

open question

2. Assess the following activities on how well you could perform them whenspecifying the DSL semantics:

2.a. • expressing the DSL semantics in the providedformalisms (Event-B, constellecore, and Constelle)

• Naturally, without problems;• Somewhat convenient;• Possible, requires somelearning;• Possible, but notconvenient/natural;• Doable, but very hard;• Impossible at all

2.b. • determining the borders of the semantic modules(i.e. decomposing the definition)

∼"∼

2.c. • connecting the semantic modules together intoa whole system

∼"∼

2.d. • using tools ∼"∼2.e. • other: Please specify ∼"∼3.a. How close your Constelle specification of the DSL

dynamic semantics to what you had in your mindbefore you started to specify the DSL semantics?

10 (exactly the same) -0 (completely different)

182 Questionnaires

3.b. How close your Constelle specification of the DSLdynamic semantics to what you have in your mindnow, after you finished specifying the dynamicsemantics of the DSL?

10 (exactly the same) -0 (completely different)

3.c. If there is a difference between these two mentalpictures (before and after specifying the DSL),then what did cause this change?

open question

4. List the DSL concepts, with the specification of which you are not happy:4.a. • you failed to specify these at all list the concepts4.b. • you had to come up with a specification trick list the concepts4.c. • you had to introduce undesirable

auxiliary/intermediate conceptslist the concepts

4.d. • the specification of these concepts does notcorrespond to the actual implementation

list the concepts

4.e. • other: Please specify list the concepts4.f. List the DSL concepts, which were hard to specify

due to the limitations of Event-Blist the concepts

4.g. List the DSL concepts, which were hard to specifydue to the limitations of constellecore (semanticinterfaces: operations with parameters)

list the concepts

4.h. List the DSL concepts, which were hard to specifydue to the limitations of Constelle (composing andspecializing semantic interfaces in a table)

list the concepts

5. List the DSL concepts, with the specification of which you are satisfied:5.a. • the specification corresponds to how you

originally wanted to specify the conceptlist the concepts

5.b. • the specification omits some details, but ingeneral it is good enough

list the concepts

5.c. • the specification adds some auxiliary details,but in general it is good enough

list the concepts

5.d. • the specification uses a trick, but this trickcorresponds to the actual implementation

list the concepts

5.e. • other: Please specify list the concepts5.f. In case your specification uses some tricks and/or

auxiliary elements, on which level (i.e. in whichformalism: Event-B, constellecore, or Constelle)did you add them?

open question

C.3. Final Questionnaire 183

6. Which of the Event-B specifications, that you have created, capture softwareengineering techniques that are more generic (have a broader scope) than thedynamic semantics of the DSL that you have specified?

6.a. • Techniques specific for formal specification(for example, Event-B tricks)

list the specifications

6.b. • Known design patterns, algorithms, protocols,and architecture styles

list the specifications

6.c. • Language engineering technology list the specifications6.d. • Other: Please specify list the specifications6.e. Which of these specifications you will be able to

(re)use in your future work?list the specifications

6.f. Why did you use these software engineeringtechniques in your specification?

open question

6.g. Do you think the amount of reusable/genericEvent-B specifications in your Constellespecification could be increased by:• Increasing the amount of details(i.e. lowering the level of abstraction)

yes/no

• Making the decomposition more finegrained (introducing more semantic modulesin your specification)

yes/no

7.a. Was it useful to specify the dynamic semantics ofthe DSL in Constelle?

5 (very useful) -0 (not useful at all)

7.b. Have you found any gaps and/or inconsistenciesthat you were not aware of before?

open question

7.c. Did you manage to do any type of analysis ofthe resulting specification?

open question

7.d. Will you be able to use this Constelle specificationas reference documentation for (learning and/orunderstanding) the DSL?• For yourself yes/no• For other interested participants yes/no

7.e. In case of using this Constelle specification asdocumentation, will be there any extradocumentation necessary?• To explain the Constelle specification yes/no• Independent from the Constelle specification(but the same content-wise)

yes/no

184 Questionnaires

7.f. What else was the Constelle specificationuseful for?

open question

8. What would you do differently in the definition process proposed for specifying thedynamic semantics of DSLs?(0. Preparation — 1.a. Obtain information about the DSL — 1.b. Recognizesemantic modules (decompose) — 1.c. Specify their semantic interfaces —1.d. Implement them as Constelle tables — 1.e. Classify the constituent aspects assemantic modules or as specification templates — 2. Write constituent Event-Bspecifications — 3. Validate the resulting specification)

8.a. • Change order of steps open question8.b. • Omit some steps open question8.c. • Add extra steps open question9. What recommendations do you have? open question9.a. • for the semantic and/or structural interfaces open question9.b. • for the Constelle language open question9.c. • for the back-end formalism

(not restricted to Event-B)open question

9.d. • for the tool support open question9.e. • other open question10.a. Does this questionnaire adequately capture your

feedback?yes/no

10.b. Do you miss some questions?If yes, please specify:

open question

Table C.2: Final Questionnaire

Summary


Domain Specific Languages (DSLs) are a central concept of Model Driven Engineering (MDE).They are considered to be very effective in software development and are being widely adoptedby industry nowadays. A DSL is a (small) computer language specialized for a specific (appli-cation) domain. In the context of MDE, a DSL is usually implemented as a translation to theinput language of a target execution platform, such as C/C++ or Java code. As a consequence,the semantics of the DSL is (hard)coded in model transformations and code generation. Thissituation poses challenges when designing, learning, and evolving the DSL. In this work we in-vestigated how an explicit definition of the dynamic semantics of a DSL can facilitate design anddevelopment of the DSL, and support understanding and debugging of DSL programs.

In order to gain insight into a real-life experience of working on and with DSLs, we per-formed a case study at ASML, a producer of complex lithography machines for the semiconduc-tor industry. In our case study we defined the dynamic semantics of the LACE DSL (LogicalAction Component Environment), which is used for generating fragments of the source code thatcontrols lithography machines. Aiming for practical benefits of having a formal definition of theDSL dynamic semantics, we employed a formalism that has extensive tool support: the Event-Bformalism. The Rodin platform offers a wide range of functionality that can be applied to anEvent-B specification of the DSL: editing, automatic generation of proof obligations, automaticand interactive proving, animation, model checking, etc. To be able to apply these tools to a DSLspecification, we used Event-B as a back-end formalism for defining the dynamic semantics ofthe DSL and developed a model-to-model transformation from the DSL to Event-B. To engageDSL engineers who are not familiar with the notation of Event-B, we created a domain-specificvisualization of the Event-B specifications of the DSL. The visualization mimics the originalgraphical notation of the DSL and runs on top of the animation of an Event-B specification. Us-ing this visualization, we investigated the needs and the perception of DSL engineers by meansof a user study. Based on the lessons learned during the case study and on the results of the userstudy, we formulated the use cases for a definition of the dynamic semantics of a DSL and identi-fied the corresponding requirements. For example, we have observed that although the availabletools facilitate design and usage of the DSL, the semantic gap between the DSL and Event-B isquite wide, and the definition of the dynamic semantics is kept (coded) in the DSL-to-Event-Btranslation. Thus, the abstraction level of Event-B is not enough for defining the dynamic se-mantics of DSLs. An example of an important requirement, indicated by the DSL engineers, isthat the DSL specification should be (kept) consistent with the actual implementation of the DSL(which evolves over time).

186 Summary

To bridge the wide semantic gap between a DSL and a specification formalism and to fa-cilitate consistency between the specification and the implementation of a DSL, we introducean intermediate semantic domain, that splits the semantic mapping from a DSL to an executionplatform (or a specification formalism) into two steps. As such an intermediate semantic domainwe use software design solutions that are typically used in the DSL implementation, i.e. conceptsthat form the horizontal domain of the DSL. Thus, we propose to define the dynamic semanticsof a DSL as a mapping from the language constructs (forming the vertical domain of the DSL)to the horizontal concepts. We realized the proposed idea in the form of the Constelle languageand reusable specification templates. Specification templates realize the generic programmingparadigm for (thorough mathematical-based) formal specifications. They capture software de-sign solutions of the DSL horizontal domain in the form of generic (Event-B) specifications thatcan be specialized for a concrete domain. Constelle allows for defining the DSL dynamic seman-tics as a composition of such specification templates and, in this way, implements the two-steptranslation of the DSL to the back-end formalism. For invoking and weaving templates, Con-stelle applies ideas of aspect oriented programming and uses the notation of a table: the DSLvertical domain is represented in the table rows, the DSL horizontal domain is represented in thetable columns, and the mapping from the vertical to the horizontal domain is represented in thetable intersections.

The semantics of the Constelle language is implemented as a model-to-model transformationfrom Constelle to Event-B. We describe this transformation informally through the mathematicalnotation of set theory and functions. While designing the Constelle-to-Event-B transformation,we used this notation to formulate and to apply two design principles of developing (QVTo)model transformations: structural decomposition and chaining model transformations.

To evaluate our approach, we designed and conducted a validation study on defining thedynamic semantics of a DSL using Constelle. The validation study was designed as an actionresearch, following the steps of the GQM (Goal, Question, Metric) method. The validation studyrevealed both strong sides and limitations of applying Constelle. Moreover, based on the insightsgained during the study we formulated a number of interesting directions for future work.

Curriculum Vitae

Ulyana Tikhonova was born on October 7th, 1985 in Leningrad (now St.Petersburg), Russia.From 2002 till 2008 she studied Applied Mathematics and Informatics at St.Petersburg StatePolytechnic University, combining her studies with a part-time work as a Software Developer.She did her Bachelor and Master projects in the field of Software Language Engineering andgraduated in 2008 with honors. In July 2008 she received Google Europe Anita Borg MemorialScholarship.

From 2008 till 2010 Ulyana was working as a Software Developer and a Junior Researcherat the Institute of Applied Astronomy of Russian Academy of Science. At the same time shewas working on her PhD project and teaching at St.Petersburg State Polytechnic University. In2010 she was awarded the Russian Federation President Scholarship for studying abroad and did10 months internship at the SET (Software Engineering and Technology) group in EindhovenUniversity of Technology.

In December 2011 Ulyana started her PhD research at Eindhoven University of Technology inthe collaboration with ASML within the Common Reference Framework (COREF) project. Theresults of this research are presented in this dissertation. In July 2016 Ulyana received the STWtake-off grant for the project titled “Harnessing formal methods for practical use in industry”.

IPA Dissertation Series

Titles in the IPA Dissertation Series since 2014

J. van den Bos. Gathering Evidence:Model-Driven Software Engineering in Auto-mated Digital Forensics. Faculty of Science,UvA. 2014-01

D. Hadziosmanovic. The Process Matters:Cyber Security in Industrial Control Systems.Faculty of Electrical Engineering, Mathemat-ics & Computer Science, UT. 2014-02

A.J.P. Jeckmans. Cryptographically-Enhanced Privacy for Recommender Systems.Faculty of Electrical Engineering, Mathemat-ics & Computer Science, UT. 2014-03

C.-P. Bezemer. Performance Optimizationof Multi-Tenant Software Systems. Facultyof Electrical Engineering, Mathematics, andComputer Science, TUD. 2014-04

T.M. Ngo. Qualitative and Quantitative In-formation Flow Analysis for Multi-threadedPrograms. Faculty of Electrical Engi-neering, Mathematics & Computer Science,UT. 2014-05

A.W. Laarman. Scalable Multi-Core ModelChecking. Faculty of Electrical Engi-neering, Mathematics & Computer Science,UT. 2014-06

J. Winter. Coalgebraic Characterizationsof Automata-Theoretic Classes. Faculty ofScience, Mathematics and Computer Science,RU. 2014-07

W. Meulemans. Similarity Measures andAlgorithms for Cartographic Schematization.

Faculty of Mathematics and Computer Sci-ence, TU/e. 2014-08

A.F.E. Belinfante. JTorX: Exploring Model-Based Testing. Faculty of Electrical Engi-neering, Mathematics & Computer Science,UT. 2014-09

A.P. van der Meer. Domain SpecificLanguages and their Type Systems. Fac-ulty of Mathematics and Computer Science,TU/e. 2014-10

B.N. Vasilescu. Social Aspects of Collabo-ration in Online Software Communities. Fac-ulty of Mathematics and Computer Science,TU/e. 2014-11

F.D. Aarts. Tomte: Bridging the Gap be-tween Active Learning and Real-World Sys-tems. Faculty of Science, Mathematics andComputer Science, RU. 2014-12

N. Noroozi. Improving Input-Output Confor-mance Testing Theories. Faculty of Mathe-matics and Computer Science, TU/e. 2014-13

M. Helvensteijn. Abstract Delta Modeling:Software Product Lines and Beyond. Fac-ulty of Mathematics and Natural Sciences,UL. 2014-14

P. Vullers. Efficient Implementations ofAttribute-based Credentials on Smart Cards.Faculty of Science, Mathematics and Com-puter Science, RU. 2014-15

190 IPA Dissertation Series

F.W. Takes. Algorithms for Analyzing andMining Real-World Graphs. Faculty of Math-ematics and Natural Sciences, UL. 2014-16

M.P. Schraagen. Aspects of Record Linkage.Faculty of Mathematics and Natural Sciences,UL. 2014-17

G. Alpár. Attribute-Based Identity Manage-ment: Bridging the Cryptographic Design ofABCs with the Real World. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2015-01

A.J. van der Ploeg. Efficient Abstractions forVisualization and Interaction. Faculty of Sci-ence, UvA. 2015-02

R.J.M. Theunissen. Supervisory Control inHealth Care Systems. Faculty of MechanicalEngineering, TU/e. 2015-03

T.V. Bui. A Software Architecture for BodyArea Sensor Networks: Flexibility and Trust-worthiness. Faculty of Mathematics andComputer Science, TU/e. 2015-04

A. Guzzi. Supporting Developers’ Teamworkfrom within the IDE. Faculty of Electrical En-gineering, Mathematics, and Computer Sci-ence, TUD. 2015-05

T. Espinha. Web Service Growing Pains: Un-derstanding Services and Their Clients. Fac-ulty of Electrical Engineering, Mathematics,and Computer Science, TUD. 2015-06

S. Dietzel. Resilient In-network Aggregationfor Vehicular Networks. Faculty of ElectricalEngineering, Mathematics & Computer Sci-ence, UT. 2015-07

E. Costante. Privacy throughout the DataCycle. Faculty of Mathematics and ComputerScience, TU/e. 2015-08

S. Cranen. Getting the point — Obtainingand understanding fixpoints in model check-ing. Faculty of Mathematics and ComputerScience, TU/e. 2015-09

R. Verdult. The (in)security of proprietarycryptography. Faculty of Science, Mathemat-ics and Computer Science, RU. 2015-10

J.E.J. de Ruiter. Lessons learned in the anal-ysis of the EMV and TLS security protocols.Faculty of Science, Mathematics and Com-puter Science, RU. 2015-11

Y. Dajsuren. On the Design of an Ar-chitecture Framework and Quality Evalua-tion for Automotive Software Systems. Fac-ulty of Mathematics and Computer Science,TU/e. 2015-12

J. Bransen. On the Incremental Evaluationof Higher-Order Attribute Grammars. Fac-ulty of Science, UU. 2015-13

S. Picek. Applications of Evolutionary Com-putation to Cryptology. Faculty of Sci-ence, Mathematics and Computer Science,RU. 2015-14

C. Chen. Automated Fault Localization forService-Oriented Software Systems. Facultyof Electrical Engineering, Mathematics, andComputer Science, TUD. 2015-15

S. te Brinke. Developing Energy-AwareSoftware. Faculty of Electrical Engineer-ing, Mathematics & Computer Science,UT. 2015-16

R.W.J. Kersten. Software Analysis Methodsfor Resource-Sensitive Systems. Faculty ofScience, Mathematics and Computer Science,RU. 2015-17

J.C. Rot. Enhanced coinduction. Fac-ulty of Mathematics and Natural Sciences,UL. 2015-18

M. Stolikj. Building Blocks for the Internetof Things. Faculty of Mathematics and Com-puter Science, TU/e. 2015-19

D. Gebler. Robust SOS Specifications ofProbabilistic Processes. Faculty of Sci-ences, Department of Computer Science,VUA. 2015-20

M. Zaharieva-Stojanovski. Closer to Reli-able Software: Verifying functional behaviourof concurrent programs. Faculty of ElectricalEngineering, Mathematics & Computer Sci-ence, UT. 2015-21

191

R.J. Krebbers. The C standard formalizedin Coq. Faculty of Science, Mathematics andComputer Science, RU. 2015-22

R. van Vliet. DNA Expressions – A FormalNotation for DNA. Faculty of Mathematicsand Natural Sciences, UL. 2015-23

S.-S.T.Q. Jongmans. Automata-TheoreticProtocol Programming. Faculty of Mathe-matics and Natural Sciences, UL. 2016-01

S.J.C. Joosten. Verification of Interconnects.Faculty of Mathematics and Computer Sci-ence, TU/e. 2016-02

M.W. Gazda. Fixpoint Logic, Games, andRelations of Consequence. Faculty of Mathe-matics and Computer Science, TU/e. 2016-03

S. Keshishzadeh. Formal Analysis and Veri-fication of Embedded Systems for Healthcare.Faculty of Mathematics and Computer Sci-ence, TU/e. 2016-04

P.M. Heck. Quality of Just-in-Time Require-ments: Just-Enough and Just-in-Time. Fac-ulty of Electrical Engineering, Mathematics,and Computer Science, TUD. 2016-05

Y. Luo. From Conceptual Models to SafetyAssurance – Applying Model-Based Tech-niques to Support Safety Assurance. Fac-ulty of Mathematics and Computer Science,TU/e. 2016-06

B. Ege. Physical Security Analysis of Embed-ded Devices. Faculty of Science, Mathemat-ics and Computer Science, RU. 2016-07

A.I. van Goethem. Algorithms for CurvedSchematization. Faculty of Mathematics andComputer Science, TU/e. 2016-08

T. van Dijk. Sylvan: Multi-core Deci-sion Diagrams. Faculty of Electrical Engi-neering, Mathematics & Computer Science,UT. 2016-09

I. David. Run-time resource management forcomponent-based systems. Faculty of Mathe-matics and Computer Science, TU/e. 2016-10

A.C. van Hulst. Control Synthesis us-ing Modal Logic and Partial Bisimilarity –

A Treatise Supported by Computer VerifiedProofs. Faculty of Mechanical Engineering,TU/e. 2016-11

A. Zawedde. Modeling the Dynamics ofRequirements Process Improvement. Fac-ulty of Mathematics and Computer Science,TU/e. 2016-12

F.M.J. van den Broek. Mobile Communica-tion Security. Faculty of Science, Mathemat-ics and Computer Science, RU. 2016-13

J.N. van Rijn. Massively Collaborative Ma-chine Learning. Faculty of Mathematics andNatural Sciences, UL. 2016-14

M.J. Steindorfer. Efficient Immutable Col-lections. Faculty of Science, UvA. 2017-01

W. Ahmad. Green Computing: Efficient En-ergy Management of Multiprocessor Stream-ing Applications via Model Checking. Fac-ulty of Electrical Engineering, Mathematics& Computer Science, UT. 2017-02

D. Guck. Reliable Systems – Fault tree anal-ysis via Markov reward automata. Faculty ofElectrical Engineering, Mathematics & Com-puter Science, UT. 2017-03

H.L. Salunkhe. Modeling and Buffer Anal-ysis of Real-time Streaming Radio Applica-tions Scheduled on Heterogeneous Multipro-cessors. Faculty of Mathematics and Com-puter Science, TU/e. 2017-04

A. Krasnova. Smart invaders of private mat-ters: Privacy of communication on the Inter-net and in the Internet of Things (IoT). Fac-ulty of Science, Mathematics and ComputerScience, RU. 2017-05

A.D. Mehrabi. Data Structures for Analyz-ing Geometric Data. Faculty of Mathematicsand Computer Science, TU/e. 2017-06

D. Landman. Reverse Engineering SourceCode: Empirical Studies of Limitationsand Opportunities. Faculty of Science,UvA. 2017-07

W. Lueks. Security and Privacy via Cryptog-raphy – Having your cake and eating it too.Faculty of Science, Mathematics and Com-puter Science, RU. 2017-08

192 IPA Dissertation Series

A.M. Sutîi. Modularity and Reuse ofDomain-Specific Languages: an explorationwith MetaMod. Faculty of Mathematics andComputer Science, TU/e. 2017-09

U. Tikhonova. Engineering the Dynamic Se-mantics of Domain Specific Languages. Fac-ulty of Mathematics and Computer Science,TU/e. 2017-10

Index

abstract syntax, 2action research, 134

baseline, 139

concrete syntax, 2concurrent triangulation strategy, 134Constelle workbench, 125critical theory, 6

definition formalism, 11definition process, 123domain specific language, 2DSL developer, 17DSL user, 17dynamic semantics, 2

embedded DSL, 2executable definition, 12executable DSL, 12external DSL, 2

GQM method, 134

horizontal domain, 41

philosophical stance, 6pragmatism, 6precise definition, 12

qualitative study, 134

semantic domain, 12semantic feature, 15semantic mapping, 12

specification template, 55

T-diagram, 12technology space, 44template parameter, 55

vertical domain, 41

Engineering the Dynamic Semantics of Domain Specific Languages › ws › files › 81094978 ›...

Documents

Transcript of Engineering the Dynamic Semantics of Domain Specific Languages › ws › files › 81094978 ›...