On the Semantics of Real-Time Domain Specific Modeling Languages

(1)

On the Semantics of Real-Time

Domain Specific Modeling Languages

PhD Thesis of:

Jose E. Rivera

Advisors:

Dr. Antonio Vallecillo

Dr. Francisco Dur´an

To obtain the degree of:

Doctor por la Universidad de M´alaga

Dept. Lenguajes y Ciencias de la Computaci´on

Universidad de M´alaga

(2)

(3)

D. Antonio Vallecillo Moreno, Catedrático de Universidad del Departamento de Lenguajes y Ciencias de la Computación de la E.T.S. de Ingenier´ıa Informática de la Universidad de Málaga, y D. Francisco Javier Durán Muñoz, Profesor Titular de Universidad del Departa-mento de Lenguajes y Ciencias de la Computación de la E.T.S. de Ingenier´ıa Informática de la Universidad de Málaga

Certifican

Que D. José Eduardo Rivera Cabaleiro, Ingeniero en Informática, ha realizado en el Depar-tamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga, bajo nuestra dirección, el trabajo de investigación correspondiente a su Tesis Doctoral titulada

On the Semantics of Real-Time Domain Specific Modeling Languages

Revisado el presente trabajo, estimamos que puede ser presentado al tribunal que ha de juz-garlo, y autorizamos la presentaci´on de esta Tesis Doctoral en la Universidad de M´alaga.

M´alaga, 27 de Julio de 2010

Fdo.: Antonio Vallecillo Moreno

Catedr´atico de Universidad del Departamento de Lenguajes y Ciencias de la Computaci´on.

Fdo.: Francisco Javier Durán Muñoz Titular de Universidad del Departamento de Lenguajes y Ciencias de la Computación.

(4)

(5)

No hay hechos, s´olo interpretaciones de los hechos. [...]

No hay una realidad en s´ı misma, s´olo maneras de observarla.

Silvia Salinas: Todo (no) termin´o.

(6)

(7)

A mi madre, a mi hermana y a mi t´ıa, las mujeres de mi vida a las que las quiero con locura.

A mi padre, del que me hubiera gustado aprender mucho.

A mi abuela. Te lo regalo abuela. Pienso que nadie habr´ıa sido m´as feliz en este momento.

A m´ı.

(8)

(9)

Agradecimientos

Gracias a todas las personas que de una forma u otra han colaborado en el desarrollo de esta tesis, ya sea de forma personal o laboral.

Gracias a los Atenea boys (Fer, Jose, Javi y Dani) por su ayuda con el desarrollo de la herramienta e-Motions, y por las interacciones en el laboratorio. Gracias a Raúl y Nathalie por el empujoncillo inicial. Gracias a Cristina Vicente por enseñarme GMF, a validar, y a jugar al billar. Gracias a Cristina Cachero por ser una fuente de motivación. Gracias a Antonio, por saberme guiar en todo, y a Paco, por su ayuda incondicional. Ambos han sido para m´ı más que un referente profesional. Gracias a Francis, sin el que no podr´ıa haber aprendido tanto, y a Antonio de Dios, por guiarme en esas enseñanzas. Y gracias al resto de mis familiares (entre los que incluyo a Nuria Vázquez) y amigos :). Un abrazo muy grande.

(10)

(11)

List of Figures

1.1 Simple definition of a DSML. . . 2

1.2 Mapping a DSML to different semantic domains. . . 4

2.1 MDA four-level architecture. . . 12

2.2 The Author metamodel. . . 12

2.3 An Author model (abstract syntax). . . 12

2.4 An overview of model transformation. . . 14

2.5 The Ecore metamodel. . . 15

2.6 An Author model (edited with the sample Ecore editor). . . 16

2.7 The GMF process to define a visual concrete syntax for a DSML. . . 17

2.8 The Person metamodel. . . 19

3.1 Definition of a DSML. . . 34

3.2 Metamodel of a DSML for production systems. . . 35

3.3 A production system model (abstract syntax). . . 35

3.4 A concrete syntax for the DSML for production systems. . . 36

3.5 A production system model (concrete syntax). . . 36

3.6 Semantic bridges across different domains. . . 39

3.7 Mapping a DSML to different semantic domains. . . 39

3.8 Definition of a DSML (revisited). . . 40

3.9 Structural View of a DSML for Production Systems. . . 41

3.10 Behavioral View of a DSML for Production Systems. . . 42

4.1 The Maude metamodel. . . 54

4.2 The EObject interface. . . 61

5.1 The Difference metamodel. . . 75

5.2 The Match Metamodel. . . 77

(18)

5.3 Example of package refactorization. . . 80

5.4 Another production system model (concrete syntax). . . 83

5.5 The Maudeling tool. . . 88

5.6 The higher-order transformation process. . . 90

5.7 Correspondences between Maude and EMF specifications. . . 91

6.1 The GenHandle in-place rule. . . 113

6.2 The Assemble in-place rule. . . 114

6.3 Further in-place rules of the production system DSML. . . 116

6.4 Reachability analysis with the AToM3tool. . . 118

7.1 The e-Motions metamodel. . . 125

7.2 A metamodel for MPNs. . . 126

7.3 A concrete syntax for the MPN language. . . 127

7.4 A mobile phone network model. . . 127

7.5 The SwitchOn atomic rule. . . 129

7.6 The BatteryOff instantaneous rule. . . 129

7.7 The RemoveOffPhones scheduled rule. . . 130

7.8 The Coverage periodic rule. . . . 131

7.9 The distance helper. . . 131

7.10 The BatteryConsumptionRule ongoing rule. . . 132

7.11 The Moving ongoing rule. . . 133

7.12 The correctPos, correctV and power helpers. . . . 133

7.13 The Call atomic rule. . . 136

7.14 The TalkingBatteryConsumption and StandbyBatteryConsumption ongoing rules.138 7.15 The InitialModel instantaneous rule. . . 139

7.16 The BatteryOffCaller instantaneous rule. . . 140

7.17 The BatteryOffCallee instantaneous rule. . . 140

7.18 The BatteryOff instantaneous rule (revisited). . . 141

7.19 A metamodel for a simple RTTP. . . 142

7.20 A concrete syntax for the RTTP language. . . 142

7.21 The Request periodic rule. . . 143

7.22 The Response atomic rule. . . 144

7.23 The LocalTimeElapse ongoing rule. . . 144

7.24 The InitialModel instantaneous rule. . . 145

(19)

7.25 A gcs model for the MPN example. . . . 180

7.26 The GCS metamodel. . . 181

7.27 The behavior and rule editors of the e-Motions tool. . . 182

7.28 The simulation window of the e-Motions tool. . . 182

8.1 Our approach to define DSMLs. . . 188

8.2 General view of our approach. . . 189

(20)

(21)

Chapter 1 Introduction

Over the past five decades, software researchers and developers have been creating abstractions that help them to program in terms of their design intent rather than constrained by the underly-ing computunderly-ing environment—for example, CPU, memory, and network devices—abstractunderly-ing them away from the complexities of these environments. From the early days of comput-ing, these abstractions included both language and platform technologies. For example, early programming languages, such as Assembly and Fortran, shielded developers from the com-plexities of programming directly with machine code.

Advances in these languages and platforms during the past two decades have raised the level of software abstractions available to developers. However, although these languages and platforms raised the level of abstraction, they still had a distinct computing-oriented focus: they provided abstractions of the solution space rather than abstractions of the problem space [115].

Model Driven Engineering (MDE) emerges as a promising approach to address the

inabil-ity of third-generation languages to (a) express domain concepts effectively and (b) alleviate the complexity of platforms. MDE advocates the use of models as first class entities throughout the software engineering life cycle, making use mainly of two technologies: Domain Specific

Modeling Languages (DSMLs) and Model Transformation. DSMLs are used to represent the

various facets of a system in terms of models. Such languages tend to support higher-level ab-stractions than general-purpose modeling languages, and are closer to the problem domain than to the implementation domain. Thus, a DSML follows the domain abstractions and semantics, allowing modelers to perceive themselves as working directly with domain concepts. Model Transformations analyze certain aspects of models and then automatically synthesize various types of artifacts, such as source code, simulation inputs, or alternative model representations. In MDE, models are not to be used as mere documentation, but key artifacts from which

(22)

2 CHAPTER 1. INTRODUCTION

the whole system can be derived and implemented. Therefore, a precise and formal basis will significantly help us in their definition not to produce unexpected results. Since models are defined with DSMLs, we need to provide DSMLs with semantics to avoid, e.g., semantic ambiguities and conflicting results across different tools. In this thesis, we will focus on the definition of the semantics of DSMLs, covering those that include real-time aspects.

1.1 Problem Statement

The definition of a language involves at least three aspects: the domain concepts and rules (abstract syntax); the notation used to represent these concepts—let it be textual or graphical (concrete syntax); and the semantics of the language. In MDE, the structure of a DSML is usu-ally defined by means of a metamodel. A metamodel can be seen as a UML class diagram—a metamodel is itself a model—on which we describe the concepts of the language, the rela-tionships between them, and the structuring rules that constrain the model elements and their combinations in order to respect the domain rules. Then, a metamodel is usually provided with a concrete syntax by mapping the metamodel concepts to a textual or graphical notation (see Figure 1.1). This concrete syntax allow us to write models in our DSML. We normally say that a model conforms to the metamodel that represents the concepts of the DSML the model is written in [20].

Figure 1.1:Simple definition of a DSML.

Defining a DSML only by means of its structural aspects (with its corresponding abstract and concrete syntaxes) allows the rapid development of languages and some of their associated tools, such as editors or browsers. However, if we want to perform real engineering tasks, we also need to count on model analyzers, simulators, matchmakers, quality evaluators, etc.

(23)

1.1. PROBLEMSTATEMENT 3

since the lack of explicit semantics presents a possibility for semantic mismatch between design models and modeling languages of analysis tools [73]. While this problem exists in virtually every domain where DSMLs are used, it is more common in domains in which behavior needs to be explicitly represented, as it happens in most industrial applications of a certain com-plexity. This issue is particularly important in safety-critical real-time and embedded system domains, where precision is required and where semantic ambiguities may produce conflicting results across different tools. Furthermore, the lack of explicit behavioral semantics strongly hampers the development of formal analysis and simulation tools, relegating models to their current common role of simple illustrations.

One way of specifying the semantics of a DSML is by defining a (semantic) mapping between the language itself and another language with well-defined semantics, such as Abstract State Machines [37], Petri Nets [49], or rewriting logic [104]. This method, which is also proposed by other authors (e.g. [18, 40, 73]), is usually called translational semantics. The advantage of using a model-driven approach is that these mappings can be defined in terms of model transformations. If the chosen target semantic domain includes mechanisms to specify the behavior of the system, the behavior of the DSML is usually encoded in the semantic domain directly. However, this approach has several disadvantages: it requires specialized knowledge and expertise on the target formalism, and it restricts the model simulation and analysis operations that can be performed over the models to those that the target tool we are encoding our behavior provides. Furthermore, not many formalisms can deal with real-time system, i.e., they do not provide specialized mechanism to specify time-dependent behavior.

Another common formalism used to represent a DSML (including the behavioral specifica-tions) is graph transformation [111, 49, 125]. Graph transformation allows users to describe the permitted actions of the system and how the model elements evolve as a result of these actions, working directly with domain specific concepts. This approach is quite intuitive, especially when it enables the use of the graphical concrete syntax of the language [102]. However, graph transformation—in its basic form—do not include a quantitative model of time. When time is needed, it is usually modeled by adding some kind of clocks to the DSML’s metamodel. These clocks are handled in the same way as common objects, which (a) forces designers to mod-ify the DSML’s metamodel (the structure of our DSML) to include (behavioral) time aspects, and (b) does not constrain designers from unwillingly defining time-inconsistent sequences of states. In critical domains, such as real-time and embedded systems, timeouts, timing con-straints and delays are essential concepts. Therefore, these concepts should be explicitly mod-eled in their behavioral specification to enable a proper analysis and simulation [99].

(24)

Finally, current graph transformation approaches only allow users to model state-based properties. When we want to observe an action, we have to unnaturally extend our DSML’s metamodel again with the state of the actions that should be observed.

1.2 Contribution of this Thesis

In this thesis, we clearly identify two different views in the definition of a DSML: structure and behavior. We propose defining them as models independently of any semantic domain. Then, since each semantic domain is more appropriate to represent and reason about certain prop-erties, and to conduct certain kinds of analysis, we propose transforming these specifications into different semantic domains (see Figure 1.2) depending on the kind of formal analysis we require (of course, not all the transformations can always be accomplished: it depends on the expressiveness of the semantic domain).

Figure 1.2:Mapping a DSML to different semantic domains.

We will define the structural model, as commonly agreed by the MDE community, with a metamodel. However, there is no such agreement in the definition of the dynamic behavior. We think that in MDE, where DSMLs and model transformations are the key artifacts, model transformations are the natural way. In particular, model transformation languages that sup-port in-place update are perfect candidates for the job. They follow the semantics of graph transformation, and they benefit from the same advantages: they allow modelers to perceive themselves as working directly with domain concepts, especially when it enables the use of the graphical concrete syntax of the language.

Thus, we present in this thesis e-Motions [100, 99, 107], a formalism that extends in-place model transformation with a model of time and a mechanism to state action properties, eas-ing the specification of real-time DSMLs’ behavior. Our approach avoids unnaturally

(25)

mod-1.2. CONTRIBUTION OF THISTHESIS 5

ifying the DSML’s metamodel—which defines the structural concepts of our language—to include time and action properties—which are related to the behavior of the language—and thus promoting a separation of concerns. The e-Motions formalism is developed as a mod-eling language, i.e., its specifications can be easily integrated in MDE processes, and is sup-ported by a graphical framework that enables the use of the concrete syntax of the DSML to define its corresponding behavior, making this task quite intuitive. Contrary to other in-place model transformation-like approaches (specially graph transformation approaches), the

e-Motions tool supports attribute computations and ordered collections, which are specified

by means of OCL expressions. The e-Motions graphical framework has been defined for the Eclipse platform. The choice of Eclipse has been motivated by its open source policy, its in-creasing use by the MDE community, and specially for the wide spectrum of modeling tools that it provides: the Eclipse Modeling Framework (EMF) [9], the Eclipse Graphical Modeling Framework (GMF) [8], the Atlas Transformation Language (ATL) [3, 71], etc., some of which have been used in the development of the tool support of this thesis, as we shall see throughout this document.

Once we have a way to specify the structure (by means of a metamodel defined using Ecore, see Chap. 4) and the behavior (by means of in-place model transformations defined with

e-Motions, see Chap. 7) as models, we are able to transform them into different semantic domains

to (a) provide our DSML with (structural and behavioral) semantics, and (b) take advantage of the analysis tools they provide. In this thesis, we have implemented these semantic bridges to Maude. Maude [4, 42, 41] is a wide-spectrum programming language based on rewriting logic, with membership equational logic as its underlying equational theory. Maude has already been successfully used in software engineering tools and several applications; it is efficient enough to be of a practical use; and has already been integrated in the Eclipse platform. Furthermore, the use of Maude as a target semantic domain brings us more interesting benefits:

• Maude performs simplification of terms modulo equational theories such as associativity,

commutativity and identity (see Section 2.2.1), which enables the specification of many model operations at a very high level of abstraction.

• Once the system specifications are written using Maude, what we get is a rewriting logic

specification of the system. Since the rewriting logic specifications produced are exe-cutable, this specification can be used as a prototype of the system, which allows us to simulate and analyze it. Maude offers an interesting set of analysis tools, such as an LTL satisfiability and tautology checker, a Church-Rosser checker, a coherence checker,

(26)

a termination tool, etc.

We show how our notation for models and metamodels, together with the powerful match-ing facilities that Maude provides, enables the specification of these model operations at a very high level of abstraction, which has allowed us to complete our tool with a relatively short development time when compared with approaches using conventional languages like Java or C++.

The semantic bridges we have defined are composed of a mapping from EMF models and metamodels to membership equational logic theories in Maude, and a mapping from the

e-Motions language to rewriting logic theories in Maude. This mechanism allow us to

auto-matically transform the structural and behavioral specifications of our DSMLs into Maude, providing our DSMLs with semantics. Furthermore, we have also developed a model trans-formation to transform models specified in Maude into its original EMF notation. Altogether, these mappings allows us to take advantage of both platforms: an intuitive way to define (the structure and behavior of) DSMLs with Eclipse tools, and a powerful mechanism to provide models with semantics and to simulate and analyze them in a transparent way.

1.3 Outline of this Thesis

The present document is structured as follows:

Chapter 2: Background. This chapter briefly introduces some parts of two usually separated worlds: modeling and formal languages. Firstly, we present the main concepts of Model Driven Engineering and the Model Driven Architecture, and some of the tools available for them in the Eclipse platform. Secondly, we introduce the rewriting logic formalism, and the Maude language and tool including two of its extensions: Full Maude and Real-Time Maude.

Chapter 3: Defining a Domain Specific Modeling Language. In this chapter we present the elements that are involved in the definition of a DSML: abstract syntax, concrete syntax and semantics. We show the need of formally defining the semantics of a DSML, and we show how it can be separated from the definition of the behavior of the DSML. We present an approach for defining a DSML based on the specification of two different views: the structural view and the behavioral view. Furthermore, we give some hints on how the DSML designer can be kept from explicitly defining the semantics of his/her DSML.

(27)

1.3. OUTLINE OF THISTHESIS 7

Chapter 4: Structural Semantics of DSMLs. In this chapter we approach the definition of the structural semantics of DSMLs. We show how models and metamodels can be formalized into Membership Equational Logic (MEL), and we specify semantic mappings (by means of automatic model transformations) between EMF models and metamodels and MEL, or, to be more precise, to the Maude implementation of MEL. We also present the Maude metamodel, parser and serializer that we have defined for this purpose.

Chapter 5: Model Management. In this chapter we present several model operations— namely model subtyping, model difference, and metric evaluation—that we have defined in Maude. We show how our notation for models and metamodels, together with the powerful matching facilities that Maude provides, enables the specification of these model operations at a very high level of abstraction, which has allowed us to complete our tool with a relatively short development time when compared with approaches using conventional languages like Java or C++. Furthermore, we present the model transformation we have defined from Maude specifications to EMF models. This transformation, together with the transformations defined from EMF to Maude, allows Eclipse users to use the defined model operations without being aware of Maude at all.

Chapter 6: Behavioral Semantics of DSMLs. In this chapter we approach the definition of the behavioral semantics of DSMLs. We show how the behavior of a DSML can be specified in Maude by means of rewrite rules, and how we can perform simulation, reachability and model-checking analysis on the domain specific models using the tools and techniques that Maude provides. We also propose defining the behavior of a DSML in a graphical and more intuitive way by means of in-place model transformations, and we show the similarity between the two approaches.

Chapter 7: Real-Time Behavioral Semantics of DSMLs. In this chapter we present a lan-guage and a tool, called e-Motions, that extends in-place model transformation with a model of time and a mechanism to state action properties. We formalize this language into Rewrit-ing Logic (RL) by means of model transformation, and we show how this automatic model transformation provides a way to give semantics to the behavioral parts of real-time DSMLs, preventing the DSML designer from explicitly defining the behavioral semantics of his/her DSML. Furthermore, we show how these semantic mappings allow us to specify the behavior of real-time DSMLs in a graphical and intuitive way (using the e-Motions tool), and perform

(28)

simulation and reachability and model-checking analysis on the models using some of the tools and techniques that Maude provides.

Chapter 8: Conclusions and Future Work. This chapter presents the main contributions, results and publications of this thesis, and outlines some future research activities.

Appendix A: Maude Definitions for Models and Metamodels. This appendix presents the algebraic specifications we have developed to support the definition of models and metamodels in Maude.

Appendix B: Maude Encoding of the Ecore Metamodel. This appendix presents the Maude encoding of the Ecore metamodel.

Appendix C: Maude Definitions for Time and Action Properties. This appendix presents the algebraic specifications we have developed to support the representation of time and action properties in Maude.

Appendix D: Maude Operations for Querying a Simulation. This appendix presents the operations we have defined in Maude to query the result of a timed-simulation, and to present it in a more readable way.

(29)

Chapter 2 Background

This thesis tries, among other things, to bring closer two usually separated worlds: modeling and formal languages. This chapter briefly introduces (parts of) both.

2.1 Model Driven Engineering in a Nutshell

This section presents the main principles and technologies of Model Driven Engineering (MDE), an approach that advocates the use of models as first class entities throughout the software en-gineering life cycle. Firstly, we discuss the problems that caused its origin; then, we introduce the MDE basic concepts and technologies; finally, we present some of the MDE tools provided by the Eclipse platform that we have used to develop the tool support of this thesis.

2.1.1 Origins of Model Driven Engineering

Over the past five decades, software researchers and developers have been creating abstractions that help them to program in terms of their design intent rather than constrained by the under-lying computing environment—for example, CPU, memory, and network devices—abstracting them away from the complexities of these environments.

From the early days of computing, these abstractions included both language and platform technologies. For example, early programming languages, such as Assembly and Fortran, shielded developers from the complexities of programming directly with machine code. Like-wise, early operating system platforms, such as OS/360 and Unix, shielded developers from the complexities of programming directly with hardware devices [115].

Advances in these languages and platforms during the past two decades have raised the

(30)

10 CHAPTER2. BACKGROUND

level of software abstractions available to developers. For instance, developers today typically use more expressive object-oriented languages, such as C++, Java, or C#, rather than Fortran or C. Likewise, today’s reusable class libraries and application framework platforms minimize the need to reinvent common and domain-specific middleware services, such as transactions, fault tolerance, event notification, and security.

However, although these languages and platforms raised the level of abstraction, they still had a distinct computing-oriented focus. In particular, they provided abstractions of the so-lution space—that is, the domain of computing technologies themselves—rather than abstrac-tions of the problem space that express designs in terms of concepts in application domains, such as telecom, aerospace and biology.

Furthermore, platform complexity is evolving faster than the ability of general-purpose languages to mask it. For example, popular middleware platforms, such as J2EE, .NET, and CORBA, contain thousands of classes and methods with many intricate dependencies and sub-tle side effects that require considerable effort to program and tune properly. Thus, develop-ers have to pay close attention to numerous tactical imperative programming details and they often cannot focus on strategic architectural issues such as system-wide correctness and per-formance. Moreover, since these platforms often evolve rapidly—and new platforms appear regularly—developers also expend considerable effort manually porting application code to different platforms or newer versions of the same platform.

2.1.2 Model Driven Engineering and Model Driven Architecture

Model Driven Engineering (MDE). MDE emerges as a promising approach to address the inability of third-generation languages to (a) express domain concepts effectively and (b) alle-viate the complexity of platforms [115]. MDE advocates the use of models as first class entities throughout the software engineering life cycle. Each model usually addresses one concern, in-dependently from the rest of the issues involved in the construction of the system. Thus, the basic functionality of the system can be separated from its final implementation; the business logic can be separated from the underlying platform technology, etc.

Although considered as first class citizens in MDE, there is no common agreement about what a model is [112]. Thus, we can find several definitions of a model, such as:

• A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. This purpose determines what is to be included in the model

(31)

2.1. MODELDRIVEN ENGINEERING IN ANUTSHELL 11

and what is irrelevant. Thus the model completely describes those aspects of the phys-ical system that are relevant to the purpose of the model, at the appropriate level of detail [94].

• A model represents some concrete or abstract thing of interest, and does so with a specific purpose. A model is related to the thing it represents by explicit or implicit dences between the elements of that model and the parts of that thing. This correspon-dence enables understanding the intended meaning of that model [93].

• A description of (part of) a system written in a well-defined language [74].

Independently of the definition we like the most, what we know is that, in MDE, models are not considered as mere documentation, but key artifacts from which the whole system can be derived and implemented. Thus, a precise and formal basis will significantly help us in their definition not to produce unexpected results.

Model Driven Architecture (MDA). MDA is the Object Management Group’s (OMG) par-ticular vision of MDE that relies on the use of OMG standards to represent (among oth-ers) models, model relationships, and model-to-model transformations. These standards in-clude UML (Unified Modeling Language), MOF (Meta-Object Facility), OCL (Object Con-straint Language), XMI (XML Metadata Interchange) and MOF/QVT (Query/View/Transfor-mations), whose specifications can be found in the OMG’s website [11].

MDA presents a four-level architecture based on the idea of metamodeling (see Figure 2.1). In this architecture, a model is used to represent some concrete or abstract thing of interest (with a specific purpose) of the system under modeling. A model is written in the language defined by its metamodel. A metamodel describes the concepts of the language, the relationships among them, and the structuring rules that constrain the model elements and their combinations in or-der to respect the domain rules. We normally say that a model conforms to its metamodel [20]. Metamodels are also models, and therefore they need to be written in another language, which is described by its meta-metamodel. This recursive definition normally ends at such meta-metalevel, since meta-metamodels conform to themselves.

An example of a meta-metamodel is the OMG standard Meta-Object Facility (MOF) [92], which can be basically seen as a subset of the UML Class Diagram—it is composed mainly of packages, classifiers and structural features. MOF enables the definition of metamodels, such as, e.g., the one shown in Figure 2.2. This figure shows a metamodel of a DSML for

(32)

Figure 2.1:MDA four-level architecture.

Figure 2.2:The Author metamodel.

authors and books. In this metamodel, named Author, authors can write several books. Authors are described by their name and surname, and books are described by their name and ISBN. Figure 2.3 shows an Author model example (conforming to the previous Author metamodel) using an object diagram. Note that a metamodel only define the concepts of the language, not a notation for it. We will use object diagrams as the “abstact” notation for models. The model consists of two authors,Paulo CoelhoandSilvia Salinas, and three books,O Alquimista,

Veronika decide morrer and Todo (no) termin ´o. The first two books were written by Paulo Coelho, while the last one was written bySilvia Salinas.

(33)

2.1.3 Main Technologies of MDE

MDE makes use mainly of two technologies: Domain Specific Modeling Languages and Model Transformations.

Domain-Specific Modeling Languages (DSMLs). DSMLs are defined to formalize the ap-plication structure, behavior, and requirements within particular domains, such as avionics mission computing, online financial services or warehouse management. They are used to rep-resent the various facets of a system in terms of models. Such languages tend to support higher level abstractions than general-purpose modeling languages, and are closer to the problem do-main than to the implementation dodo-main. Thus, a DSML follows the dodo-main abstractions and semantics, allowing modelers to perceive themselves as working directly with domain con-cepts. Furthermore, the rules of the domain can be included into the language as constraints, disallowing the specification of illegal or incorrect models. In the next chapter, we will present how a DSML can be defined.

Model transformation. Model Transformation provides a means to analyze certain aspects of models and then automatically synthesize various types of artifacts, such as source code, simulation inputs, or alternative model representations. The ability to synthesize artifacts from models helps to ensure the consistency between application implementations and analysis in-formation associated with functional and QoS requirements captured by models.

The most common type of model transformation is the so called model-to-model transfor-mation. A model-to-model transformation specifies a way to produce a set of target models from a set of source models. For this purpose, it should enable developers to define the way source model elements must be matched and navigated in order to initialize the target model elements [3]. When a model-to-model transformation is composed of a single input model and a single output model, we call it simple model-to-model transformation.

Formally, a simple model-to-model transformation has to define the way for generating a model Mb, conforming to a metamodel MMb, from a modelMaconforming to a metamodel

MMa. Since in MDE a major feature is to consider, as far as possible, all handled items as models, the model transformation itself has to be defined as a model. This transformation model Mt has to conform to a transformation metamodel MMt whose language defines the model transformation semantics. As other metamodels, the transformation metamodel has, in turn, to conform to the considered meta-metamodelMMM(see Figure 2.4).

(34)

Figure 2.4:An overview of model transformation.

An in-place model transformation is a special kind of model-to-model transformation where source and target models are always instances of the same metamodel (i.e., they are

endoge-nous transformations). In fact, source and target models are the same: this kind of model

transformation is not used to create new models but just to modify the source ones. As we will see in Section 6.3.1, they present a very intuitive way to represent the behavior of DSML.

2.1.4 Model Driven Engineering in the Eclipse Platform

Eclipse is an open source community project focused on building an open development plat-form comprised of extensible frameworks, tools and support for building, deploying and man-aging software across the life cycle. It is becoming a widely used platform in the MDE com-munity, since several modeling tools have been developed for it. In the next subsections, we will mention those that have been used to develop the tool support of this thesis.

2.1.4.1 The Eclipse Modeling Framework

The Eclipse Modeling Framework (EMF) [9] is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose, and then imported into EMF. Most important of all, EMF provides the foundation for interoperability with other EMF-based tools and applications, such as, e.g., the Graphical Modeling Framework (GMF), the Textual Concrete Syntax (TCS) tool, and the ATLAS Transformation Language (ATL)— see the next subsections for more details about these tools.

(35)

EMF started out as an implementation of the MOF specification. It evolved from there based on the experience of implementing a large set of tools using it. EMF can be thought of as a highly efficient Java implementation of a core subset of the MOF API. However, to avoid any confusion, the MOF-like core metamodel in EMF is called Ecore, whose metamodel is described in Figure 2.5. In the current proposal for MOF 2.0, a similar subset of the MOF model, which is called EMOF (Essential MOF), is separated out. Although there are small, mostly naming differences between Ecore and EMOF, EMF can transparently read and write serializations of EMOF.

Figure 2.5:The Ecore metamodel.

All the metamodels produced in this thesis have been defined using the class diagram-like editor that EMF provides (see, for instance, Figure 2.2). EMF also provides a sample Ecore editor (tree editor) to define models that conform to metamodels specified using Ecore.

(36)

Figure 2.6 shows the definition of the model depicted in Figure 2.3 using the EMF sample Ecore editor.

Figure 2.6:An Author model (edited with the sample Ecore editor).

2.1.4.2 The Graphical Modeling Framework

The Eclipse Graphical Modeling Framework (GMF) [8] provides a generative component and runtime infrastructure for developing graphical concrete syntaxes (notations) for DSMLs. It automatically generates an Eclipse plugin with a DSML diagram editor from (1) the DSML’s metamodel (abstract syntax); (2) a graphical definition model (i.e., the shapes that will be associated to the domain elements); (3) a tooling definition model (namely the buttons that enable the creation of the model elements); and (4) a mapping model relating the three previous artifacts (see Figure 2.7).

GMF significantly reduces the cost of DSML tooling. We have used it to define, for in-stance, the graphical concrete syntax of our e-Motions language (see Section 7.2). More infor-mation about GMF can be found in [8].

2.1.4.3 Textual Concrete Syntax

Textual Concrete Syntax (TCS) [70] is an Eclipse component that enables the specification of textual concrete syntaxes (notations) for DSMLs by attaching syntactic information to meta-models. With TCS, it is possible to parse (text-to-model) and pretty-print (model-to-text) DSML sentences. Moreover, TCS provides an Eclipse editor which features syntax highlight-ing, hyperlinks, and hovers for every DSML which syntax is represented in TCS.

We use TCS, for instance, to define the model-to-text transformation from Maude models (see Section 4.2.1.2). The interested reader is referred to TCS’s website [7] for more informa-tion about the tool.

(37)

Figure 2.7:The GMF process to define a visual concrete syntax for a DSML.

2.1.4.4 The ATLAS Transformation Language

The Atlas Transformation Language (ATL) [3, 71] is the ATLAS INRIA & LINA research group’s answer to the OMG MOF /QVT RFP. It is a model transformation language specified as both a metamodel and a textual concrete syntax. In the field of MDE, ATL provides developers with a mean to specify the way to produce a number of target models from a set of source models.

The ATL language is a hybrid of declarative and imperative programming. The preferred style of transformation writing is the declarative one: it enables to simply express mappings between the source and target model elements. However, ATL also provides imperative con-structs in order to ease the specification of mappings that can hardly be expressed declaratively. ATL uses OCL for specifying both its data types and its declarative expressions. Besides basic model transformations, ATL defines an additional model querying facility that enables to specify requests on models (including code generation). ATL also allows code factorization through the definition of ATL libraries [3].

ATL Modules and Rules. An ATL module corresponds to a model-to-model transformation. This kind of ATL unit allows ATL developers to specify the way to produce a set of target models from a set of source models. Both source and target models of an ATL module must be “typed” by their respective metamodels. Moreover, an ATL module accepts a fixed number of models as input, and returns a fixed number of target models: it cannot generate an unknown

(38)

number of similar target models (e.g., models that conform to the same metamodel). An ATL module is composed of the following elements:

• a header section that defines some attributes that are relative to the transformation module

(such as the input and output models and the metamodels they conform to);

• an optional import section that enables to import some existing ATL libraries; • a set of helpers (that can be viewed as the ATL equivalent to Java methods);

• and a set of rules that defines the way target models are generated from source ones.

There are several types of transformation rules, namely called, lazy and match rules. In this section we focus on the main ones: match rules. This kind of rules have the following syntax:

r u l e rule_name { from in_var1 : in_type1 , . . . in_varn : in_typen [ ( condition ) ] ? [u s i n g {

var1 : var_type1 = init_exp1 ; . . .

varn : var_typen = init_expn ; }]?

t o out_var1 : out_type1 ( bindings1 ) , . . . out_varn : out_typen ( bindingsn) [do { statements }]? }

A match rule is identified by its name. It matches one or more given types of source model elements, and generates one or more kinds of target model elements. The rule specifies the way generated target model elements must be initialized from each matched source pattern. It is composed of two mandatory (the source and the target patterns) and two optional (the local variables and the imperative) sections. When defined, the local variables section is introduced by the keywordusing. It allows us to locally declare and initialize a number of local variables (that will only be visible in the scope of the current rule). The source pattern of a matched rule is defined after the keywordfrom. It allows us to specify a set of model element variables that corresponds to the types of source elements the rule has to match—these types correspond

(39)

to some entities of one of the source metamodels of the transformation. This means that the rule will generate target elements for each occurrence of the source pattern. In many cases, the developer will be interested in matching only a subset of the source elements that conform to the matching type. This is simply achieved by specifying an optional condition (expressed as an OCL expression) within the rule’s source pattern. In this way, the rule will only generate target elements for the source model elements that both conform to the matching types and verify the specified condition.

The target pattern of a matched rule is introduced by the keywordto. It specifies the ele-ments to be generated when the source pattern of the rule is matched, and how these generated elements are initialized. A target pattern element corresponds to a model element variable dec-laration associated with its corresponding set of initialization bindings. This model element variable declaration has to correspond to an entity of the target metamodels of the transforma-tion.

Finally, the optional imperative section, introduced by the keyword do, enables the spec-ification of some imperative code that will be executed after the initialization of the target elements generated by the rule.

Figure 2.8:The Person metamodel.

As an example, the following is an ATL module (Author2Person) that transforms a model conforming to the Author metamodel (see Figure 2.2) to a model conforming to the Person metamodel (see Figure 2.8):

module Author2Person;

c r e a t e OUT : MMPerson from IN : MMAuthor ;

r u l e Author { from a : MMAuthor ! Author t o p : MMPerson ! Person ( name<− a . name , surname<− a . surname ) }

IN andOUTare the variables that will be used throughout the whole transformation spec-ification to refer to the input and output models, respectively. The specific models they refer

(40)

to will be assigned when running the transformation. The same applies for the MMAuthor

andMMPersonvariables, which represent the metamodels these models conform to. The rule, calledAuthor, transformsAuthorsource model elements toPersontarget model elements. The source pattern defines no filter, which means that all Author elements of the source MMAu-thormodel will be matched by the rule. The rule target pattern contains a single simple target pattern element (called p). This target pattern element will allocate a Person element of the

MMPerson target model for each source model element matched by the source pattern. The features of the generated model element are initialized with the corresponding features of the matched source model element. In this case,Booksource model elements are simply ignored.

ATL also supports other features not presented in this brief introduction, such as other types of transformation rules, rule inheritance, superimposition mode, etc. The interested reader is referred to [3] for more details about these features.

2.2 Rewriting Logic and Maude

There are several formalisms that enable the specification of the structure and behavior of sys-tems. In this work, we will focus on rewriting logic, a logic of change that can naturally deal with state and with highly nondeterministic concurrent computations. In particular, we intro-duce Maude [42], a programming language based on rewriting logic, and two of its extensions: Full Maude, that allows users to specify object-oriented systems, and Real-Time Maude, an extension of the former to specify real-time systems. We will also present the mOdCL tool, an OCL validation tool based on Maude that has been used to develop the tools support of this thesis.

2.2.1 Rewriting Logic and (Core) Maude

Membership equational logic (MEL) [27] is a Horn logic whose atomic sentences are equalities

t = t′ and membership assertions of the form t : S, stating that a term t has sort S. A MEL

theory Γ is a tuple (Σ,E) where Σ is its signature, which specifies its sorts, subsorts, kinds

and overloaded operators, and E is a collection of equations and memberships. Such a logic

extends order-sorted equational logic, and supports sorts, subsort relations, subsort overloading of operators, and the definition of partial functions with equationally defined domains. MEL has sound and complete rules of deduction, and initial and free algebras [27].

(41)

2.2. REWRITINGLOGIC ANDMAUDE 21

with highly nondeterministic concurrent computations. In RL, the state space of a distributed system is specified as an algebraic data type in terms of an equational specification, i.e., RL is parameterized by the choice of its underlying equational logic. The dynamics of a system in RL is then specified by rewrite rules. To be more precise, a RL specification R is a

4-tuple (Σ,E, Φ, R) where (Σ, E) is an equational theory, Φ is the function specifying the frozen

arguments of each operator in Σ, andR is a collection of rewrite rules. Rewrite rules are of the

form [t]E → [t′]E, wheret and t′ are Σ-terms, and [t]E denotes the equivalence (or congruence)

class of the termt modulo the equations E. These rules describe the local, concurrent transitions

possible in the system, i.e., when a part of the system state fits any pattern in [t]E then it can

change to a new local state fitting pattern [t′]E. The model theory of RL has been developed in

detail in [83], where initiality, soundness and completeness theorems are proved.

Maude [4, 41, 42] is a wide-spectrum programming language based on RL, with MEL as its underlying equational theory. Thus, Maude integrates an equational style of functional programming with RL computation. Because of its efficient rewriting engine and its metalan-guage capabilities, Maude turns out to be an excellent tool to create executable environments for different logics, models of computation, theorem provers, or even programming languages. In addition, Maude has already been successfully used in software engineering tools and sev-eral applications (see, e.g., [80]). We informally describe in this section those Maude features needed for understanding our approach; the interested reader is referred to [42] for details.

For example, the following Maude functional moduleNATURALdefines the natural num-bers (with sorts Nat of natural numbers and NzNat of nonzero natural numbers), using the Peano notation, with the zero (0) and successor (s_) operators as constructors (note thector

attribute). The addition operation (_+_) is also defined, being its behavior specified by one equational axiom. Note that the operators s_ and _+_ are defined using mixfix syntax (under-scores indicate placeholders for arguments).

fmod NATURAL i s s o r t s NzNat Nat .

s u b s o r t NzNat< Nat .

op 0 : −> Nat [ ctor ] .

op s_ : Nat−> NzNat [ ctor ] .

op _+_ : Nat Nat−> Nat [ assoc comm id : 0] .

v a r s M N : Nat .

eq s M + s N = s s ( M + N ) .

endfm

Functional modules are required to be terminating and Church-Rosser [27]. Computation in a functional module is accomplished by using equations as simplification rules from left to

(42)

right until a canonical form is found. Some equations, like those expressing the commutativity of binary operators, are not terminating but nonetheless they are supported by means of

opera-tor attributes, so that Maude performs simplification modulo the equational theories provided

by such attributes, which can be any combination of associativivity (assoc), commutativity

(comm) and identity (id). The equations in a MEL theory (Σ,E) are in fact divided as E∪ A,

withE equations and memberships, and A the axiom supported by equational attributes.

In Maude, specifications may be generic, that is, they may be defined with other specifica-tions as parameters. The requirements that a datatype must satisfy are described by theories. Theories may include declarations of sorts, subsorts, operations, membership axioms and equa-tions as can be done in modules. For example, sets can be constructed on top of any data, which means that its parameter could be a theory requiring only the existence of a sort. The following moduleSETprovides a sortSet{X}of sets over a given sort of elements (specified by theElt

sort in theTRIVtheory) with theemptyconstant as the empty set, and , the associative and commutative union operator, with identity elementempty.

f t h TRIV i s s o r t Elt .

e n d f t h

fmod SET{X : : TRIV} i s s o r t Set{X} .

s u b s o r t X$Elt< Set{X} .

op empty : −> Set{X} [ ctor ] .

op _, _ : Set{X} Set{X} −> Set{X} [ ctor assoc comm id : empty ] .

v a r E : X$Elt .

eq E, E = E .

endm

The parameter X :: TRIV indicates that Xis the label of the formal parameter, which must be instantiated with modules satisfying the requirements expressed by the theoryTRIV.

The sorts and operations of the theory are used in the body of the parameterized module, but sorts are qualified with the label of the formal parameter; thus, in this case, the parameterElt

becomesX$Eltin theSETmodule.

In Maude, parameterized modules are instantiated by means of views. A view shows how a particular module satisfies a theory by mapping sorts and operations in the theory to sorts and operations in the target module, in such a way that the induced axioms are provable in the target module. The following viewNat maps the theoryTRIVto the Maude’s predefined

moduleNATof natural numbers.

v i e w Nat from TRIV t o NAT i s s o r t Elt t o Nat .

(43)

endv

Then, the module expressionSET{Nat}denotes the instantiation of the parameterized

mod-uleSETwith the above viewNat. Notice that the name of the sortSet{X}makes explicit the

label of the parameter. In this way, when the module is instantiated with a view, like for exam-ple theNatview above, the sort name is also instantiated becomingSet{Nat}.

While functional modules specify membership equational theories, rewrite theories are specified by system modules. A system module may have the same declarations of a func-tional module plus rules. Uncondifunc-tional rules are written using the syntax

rl [l] : t => t′ .

and conditional rules using the syntax

crl [l] : t => t′ if Cond .

wherelis the rule label andCondits condition. The guards of conditional rules act as blocking pre-conditions, in the sense that a conditional rule can only be fired if its condition is satisfied. The form of rule conditions used in this thesis is EqC₁/\... /\ EqC_nwhere each of the EqC_i is either an ordinary equationt = t′, a matching equationt := t′, or a termt of sort Bool,

abbreviatingt = true.1 _{In the execution of a matching equation}_{t := t}′_{, the variables of the} termt, which may not appear in the lefthand side of the corresponding conditional equation,

become instantiated by matching the termt against the canonical form of the bounded term t′. For example, given the quotient operator quo , the followingBOARD system module

de-fines a rule replacethat takes any two numbers in a set of numbers and replaces them by their mean: mod BOARD i s p r o t e c t i n g SET{Nat} . v a r s N M : Nat . r l [ replace ] : N , M => ( N + M ) quo 2 . endm

Rewriting in a system module operates on congruence classes of terms module its equa-tions. When we rewrite a term like (6,3,2)we are rewriting in fact on its equivalent class (modulo equation E,E = E and associativity, commutativity and identity of , ). Thus, the

rule can be applied on subterms(6,3),(6,2),(3,2), or their permutations.

The rewritecommand can be used to execute the system, using the Maude interpreter, which applies the rules until none is applicable.

Maude> r e w r i t e 6 , 3 , 2 .

r e s u l t NzNat: 4

(44)

Note that the result depends on the numbers matched in each application of the rule. System rules are not required to be terminating nor confluent. In this case, subterm(3,2)(or(2,3)) has been rewritten first to term 2, and then the resulting term (6,2) (or (2,6)) has been

rewritten to term4.

2.2.2 Object-Oriented Specifications: Full Maude

Full Maude [42] is an extension of Maude (written in Maude itself) that provides a notation for object-oriented programming. In Full Maude, concurrent object-oriented systems are specified by object-oriented modules in which classes and subclasses are declared. A class is declared with the syntaxclassC|a1:S1,..., an:Sn, whereC is the name of the class, aiare attribute

identifiers, and Si are the sorts of the corresponding attributes. Objects of a class C are then

record-like structures of the form < O : C | a1:v1, ..., an:vn >, where O is the object

identifier, andvi are the current values of its attributesai. Objects can interact in a number of

different ways, including message passing. Messages are declared in Maude inmsgclauses, in which the syntax and arguments of the messages are defined.

In a concurrent object-oriented system, the concurrent state, which is called a configuration, has the structure of a multiset made up of objects and messages that evolves by concurrent rewriting, using rules that describe the effects of the communication events of objects and messages. The predefined sortConfiguration represents configurations of Maude objects and messages, with none as the empty configuration and the empty syntax operator __ as

union of configurations.

mod CONFIGURATION i s s o r t Configuration .

s u b s o r t s Object Message < Configuration .

op none : −> Configuration [ ctor ] .

op __ : Configuration Configuration−> Configuration

[ ctor assoc comm id : none ] . . . .

endm

Class inheritance is directly supported by Maude’s order-sorted type structure. A subclass declaration C < C’, indicating that C is a subclass of C’, is a particular case of a subsort

declarationC < C’, by which all attributes, messages, and rules of the superclasses, as well as

the newly defined attributes, messages and rules of the subclass characterize its structure and behavior. This corresponds to the traditional notion of subtyping: Ais a subtype ofBif every

(45)

safely replace objects of classB). Multiple inheritance is also supported in Maude [42, 41]. For instance, the following Maude moduleEMPLOYEE2specifies two classes: Personand

Employee. ThePersonclass has an attributenameof sort string (String). TheEmployee

class extends thePersonclass and has an attributesalaryof sort integer (Int). TheString

sort is predefined in theSTRINGmodule, and theIntsort is imported in every Maude module.

(omod EMPLOYEE i s p r o t e c t i n g STRING .

c l a s s Person | name : String .

c l a s s Employee | salary : Int .

s u b c l a s s Employee < Person .

endom)

2.2.2.1 Object-Oriented Modules in (Core) Maude

Although object-oriented modules provide convenient syntax for programming object-oriented systems, their semantics can be reduced to that of system modules. We can regard the special syntax reserved for object-oriented modules as syntactic sugar. In fact, each object-oriented module can be translated into a corresponding system module whose semantics is by definition that of the original object-oriented module. This is precisely what Full Maude does to handle object-oriented modules [42, 51].

For instance, each class declaration of the form class C | a₁:S₁, ..., a_n:S_n can be specified in (Core) Maude as a subsort C of sort Cid (class identifier), a constant C of

sort C, and declarations of operations ai : : Si -> Attribute for each attribute ai; and

each subclass relation C < D as a subsort declaration subsort C < D. Thus, the above PersonandEmployeeclasses specifications can be rewritten in (Core) Maude (importing the CONFIGURATIONmodule) as follows:

s o r t Person .

s u b s o r t Person < Cid .

op Person : −> Person .

op name : _ : String−> Attribute .

s o r t Employee .

s u b s o r t Employee < Person .

op Employee : −> Employee .

op salary : _ : Int−> Attribute .

Further details on the translations performed from Full Maude to (Core) Maude can be found in [42].

(46)

2.2.3 Real-Time Maude

Real-Time Maude [89, 91] is a language and tool for the high-level formal specification, simu-lation, and formal analysis of real-time and hybrid systems. It is implemented in Maude as an extension of Full Maude. Real-Time Maude provides, among others:

• a sort Time to model the time domain, which can be either discrete or dense time

(al-though users can define their own time domain);

• a sortTimeInf, which extends the sortTimewith the infinite valueINF;

• a built-in constructor{ }of sortGlobalSystem, with the intended meaning that, given a termt of sortSystem,{t}denotes the whole system in statet;

• an extended form of rewrite rules, known as tick rules, whose concrete syntax is crl [l] : {t} => {t′} in time τ if Cond.

where τ is a term of sortTimethat denotes the duration of the rewrite, and that affects the global time elapse.

Real-time rewrite theories are described in Real-Time Maude as timed modules. For ex-ample, the following timed module (borrowed from [89]) specifies a simple discrete clock

which shows the time. Clocks count hours, so time advances by one time unit in each tick step until it reaches time 24. Since the example handles discrete time, we import the built-in

moduleNAT-TIME-DOMAINto use natural numbers as the time domain.

(tmod CLOCK i s

p r o t e c t i n g NAT−TIME−DOMAIN .

op clock : Time−> System [ ctor ] .

v a r N : Time .

c r l [ tick ] : {clock ( N ) } => {clock ( N + 1) } in time 1 i f N< 24 .

r l [ reset ] : clock ( 2 4 ) => clock ( 0 ) .

endtm)

As we previously mentioned, tick rules affect the global time. Therefore, when the system is composed of several timed elements, time elapse is usually modeled by one single tick rule, and the system dynamic behavior by instantaneous transitions [89]. The tick rule is defined by using two functions: the delta function, that defines the effect of time elapse over

ev-ery system element; and themte (maximal time elapse) function, that defines the maximum

amount of time that can elapse before any action can take place. Then, time advances non-deterministically by any amount τ , which must be less or equal than the maximum time elapse of the system.

(47)

The following timed module specifies the same system with several clocks (adapted from [89]). We let an associative and commutative operator __ be the constructor for multisets of single clocks.

1 (tmod CLOCKS i s

2 p r o t e c t i n g NAT−TIME−DOMAIN .

3 --- The sort System is a multiset of clocks:

4 s o r t Clock .

5 op clock : Time−> Clock [ ctor ] .

6 s u b s o r t Clock< System .

7 op __ : System System−> System [ ctor assoc comm ] .

8 --- Variables

9 v a r s R R’ : Time .

10 v a r s SYSTEM SYSTEM’ : System .

11 --- The instantaneous transitions:

12 r l [ reset ] : clock ( 2 4 ) => clock ( 0 ) . 13 --- Tick the whole system:

14 c r l [ tick ] :

15 {SYSTEM} => {delta ( SYSTEM , R ) } in time R 16 i f R <= mte ( SYSTEM ) [ nonexec ] .

17 --- Effect of time elapse on a system:

18 op delta : System Time−> System [ frozen ( 1 ) ] .

19 eq delta( clock ( R ) , R ’ ) = clock ( R plus R ’ ) .

20 eq delta( SYSTEM SYSTEM ’ , R ) = delta ( SYSTEM , R ) delta ( SYSTEM ’ , R ) .

21 --- Maximum Time Elapse allowed in a system before a clock must be reset:

22 op mte : System −> Time [ frozen ( 1 ) ] .

23 eq mte( clock ( R ) ) = 24 monus R .

24 eq mte( SYSTEM SYSTEM ’ ) = min ( mte ( SYSTEM ) , mte ( SYSTEM ’ ) ) .

25 endtm)

Since the state of the system is now a multiset of clocks, time elapse must be specified over every clock. The deltaoperation is defined over the whole system and increases every

clock time with time elapse R. The maximal time elapse of the system (specified by the mte

operation) defines the maximal amount of time that can elapse before a possible event (in this case the reset of a clock) may happen. Thus, it equals the time until the next moment in time when any clock must be reset. Note that time advance in the above tick rule is nondeterministic. Thenonexecattribute (line 16) specifies that the rule is not directly executable. This attribute will be “removed” when a time sampling strategy is applied to the rule (see below). Finally, thefrozenattribute (line 18 and 22) forbids rewriting with rules in all proper subterms ofmte

anddeltaoperators to avoid “aged” rewrites [89].

Real-Time Maude identifies two types of tick rules: time-deterministic and time-nondeter-ministic. Tick rules in which the time increment is explicitly given are called time-detertime-nondeter-ministic. This is the case, e.g., of the tick rule described in theCLOCKmodule, on which we specify that time advances by1time unit. All other tick rules are called time-nondeterministic. In this kind

On the Semantics of Real-Time Domain Specific Modeling Languages