On the Semantics of Real-Time Domain Specific Modeling

Transcripción

On the Semantics of Real-Time
Domain Specific Modeling Languages
PhD Thesis of:
Jose E. Rivera
Advisors:
Dr. Antonio Vallecillo
Dr. Francisco Durán
To obtain the degree of:
Doctor por la Universidad de Málaga
Dept. Lenguajes y Ciencias de la Computación
Universidad de Málaga
Jose E. Rivera, 2010
D. Antonio Vallecillo Moreno, Catedrático de Universidad del Departamento de Lenguajes
y Ciencias de la Computación de la E.T.S. de Ingenierı́a Informática de la Universidad de
Málaga, y D. Francisco Javier Durán Muñoz, Profesor Titular de Universidad del Departamento de Lenguajes y Ciencias de la Computación de la E.T.S. de Ingenierı́a Informática de la
Universidad de Málaga
Certifican
Que D. José Eduardo Rivera Cabaleiro, Ingeniero en Informática, ha realizado en el Departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga, bajo nuestra
dirección, el trabajo de investigació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 juzgarlo, y autorizamos la presentación de esta Tesis Doctoral en la Universidad de Málaga.
Málaga, 27 de Julio de 2010
Fdo.: Antonio Vallecillo Moreno
Fdo.: Francisco Javier Durán Muñoz
Catedrático de Universidad del Departamento
Titular de Universidad del Departamento
de Lenguajes y Ciencias de la Computación.
de Lenguajes y Ciencias de la Computación.
No hay hechos, sólo interpretaciones de los hechos. [...]
No hay una realidad en sı́ misma, sólo maneras de observarla.
Silvia Salinas: Todo (no) terminó.
v
vi
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 más feliz en este momento.
A mı́.
vii
viii
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 Raúl y Nathalie por
el empujoncillo inicial. Gracias a Cristina Vicente por enseñarme GMF, a validar, y a jugar al
billar. Gracias a Cristina Cachero por ser una fuente de motivación. Gracias a Antonio, por
saberme guiar en todo, y a Paco, por su ayuda incondicional. Ambos han sido para mı́ má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 enseñanzas. Y gracias al resto de mis familiares (entre
los que incluyo a Nuria Vázquez) y amigos :). Un abrazo muy grande.
Contents
1
2
Introduction
1
1.1
Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Contribution of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Outline of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Background
9
2.1
Model Driven Engineering in a Nutshell . . . . . . . . . . . . . . . . . . . . .
9
2.1.1
Origins of Model Driven Engineering . . . . . . . . . . . . . . . . . .
9
2.1.2
Model Driven Engineering and Model Driven Architecture . . . . . . . 10
2.1.3
Main Technologies of MDE . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.4
Model Driven Engineering in the Eclipse Platform . . . . . . . . . . . 14
2.2
2.1.4.1
The Eclipse Modeling Framework . . . . . . . . . . . . . . 14
2.1.4.2
The Graphical Modeling Framework . . . . . . . . . . . . . 16
2.1.4.3
Textual Concrete Syntax . . . . . . . . . . . . . . . . . . . . 16
2.1.4.4
The ATLAS Transformation Language . . . . . . . . . . . . 17
Rewriting Logic and Maude . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1
Rewriting Logic and (Core) Maude . . . . . . . . . . . . . . . . . . . 20
2.2.2
Object-Oriented Specifications: Full Maude . . . . . . . . . . . . . . . 24
2.2.2.1
2.2.3
Real-Time Maude . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.3.1
2.2.4
3
Object-Oriented Modules in (Core) Maude . . . . . . . . . . 25
Timed Modules in (Core) Maude . . . . . . . . . . . . . . . 28
The mOdCL Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Defining a Domain Specific Modeling Language
33
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2
Abstract Syntax of a DSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
xi
3.3
Concrete Syntax of a DSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4
Semantics of a DSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1
3.5
4
Semantics Is Not Behavior . . . . . . . . . . . . . . . . . . . . . . . . 38
Defining a DSML (Revisited) . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.1
Defining the Structural View of a DSML . . . . . . . . . . . . . . . . 40
3.5.2
Defining the Behavioral View of a DSML . . . . . . . . . . . . . . . . 41
Structural Semantics of DSMLs
4.1
MEL Representation of Models and Metamodels . . . . . . . . . . . . . . . . 43
4.1.1
Representing Metamodels with Maude . . . . . . . . . . . . . . . . . 44
4.1.2
Representing Models with Maude . . . . . . . . . . . . . . . . . . . . 48
4.1.2.1
4.2
4.2.2
5
The Conformance Relationship . . . . . . . . . . . . . . . . 49
Structural Semantic Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1
4.3
43
Maude’s Metamodel, Parser and Serializer . . . . . . . . . . . . . . . 52
4.2.1.1
The Metamodel Definition . . . . . . . . . . . . . . . . . . 53
4.2.1.2
The Maude Code Generator . . . . . . . . . . . . . . . . . . 56
4.2.1.3
The Maude Parser . . . . . . . . . . . . . . . . . . . . . . . 57
Encoding EMF Models and Metamodels into Maude . . . . . . . . . . 57
4.2.2.1
Encoding EMF Metamodels . . . . . . . . . . . . . . . . . . 57
4.2.2.2
Encoding EMF Models . . . . . . . . . . . . . . . . . . . . 61
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Model Management
5.1
Model Subtyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.2
Subtyping Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.2.1
5.1.3
5.2
67
Kinds of Subtyping . . . . . . . . . . . . . . . . . . . . . . 71
The Subtyping Operation in Maude . . . . . . . . . . . . . . . . . . . 72
Model Difference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.1
Representing Differences . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2
The Difference Operation . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3
5.2.2.1
Matching Elements . . . . . . . . . . . . . . . . . . . . . . 77
5.2.2.2
Computing Differences . . . . . . . . . . . . . . . . . . . . 80
An Example of Model Difference . . . . . . . . . . . . . . . . . . . . 83
xii
5.2.4
The do Operation . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.4.2
The undo Operation . . . . . . . . . . . . . . . . . . . . . 86
5.2.4.3
Sequential Composition of Differences . . . . . . . . . . . . 86
Further Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4
Tool Support with Maudeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.4.1
The Way Back to EMF . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4.2
Adapting Difference Models to the Eclipse Platform . . . . . . . . . . 92
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Behavioral Semantics of DSMLs
97
6.1
Representing DSMLs’ Behavior with Maude . . . . . . . . . . . . . . . . . . 97
6.2
Formal Analysis of Domain Specific Models with Maude . . . . . . . . . . . . 102
6.3
7
5.2.4.1
5.3
5.5
6
Related Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2.1
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.2
Reachability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.3
LTL Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Representing DSML’s Behavior with In-Place Model Transformation . . . . . . 112
6.3.1
In-Place Model Transformation . . . . . . . . . . . . . . . . . . . . . 113
6.3.2
In-Place Rules for the Production System DSML . . . . . . . . . . . . 115
6.4
Behavioral Semantic Mappings and Tool Support . . . . . . . . . . . . . . . . 117
6.5
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Real-Time Behavioral Semantics of DSMLs
123
7.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.2
The e-Motions Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.2.1
A DSML for Mobile Phone Networks . . . . . . . . . . . . . . . . . . 126
7.2.2
A Model of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.2.3
7.2.2.1
Atomic Rules . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.2.2.2
Ongoing Rules . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.2.2.3
Global Time Elapse . . . . . . . . . . . . . . . . . . . . . . 134
Action Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.2.3.1
Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.2.3.2
Separation of Concerns . . . . . . . . . . . . . . . . . . . . 137
7.2.3.3
Past Actions . . . . . . . . . . . . . . . . . . . . . . . . . . 138
xiii
7.2.3.4
7.2.4
7.3
7.4
A Simple Round-Trip Time Protocol . . . . . . . . . . . . . . . . . . . 142
Real-time Behavioral Semantic Mappings . . . . . . . . . . . . . . . . . . . . 144
7.3.1
A General View of the Encoding . . . . . . . . . . . . . . . . . . . . . 145
7.3.2
Encoding of Atomic Rules . . . . . . . . . . . . . . . . . . . . . . . . 147
7.3.2.1
The Triggering Rule . . . . . . . . . . . . . . . . . . . . . . 147
7.3.2.2
The Realization Rule . . . . . . . . . . . . . . . . . . . . . 151
7.3.3
Encoding of Periodic Rules . . . . . . . . . . . . . . . . . . . . . . . 153
7.3.4
Encoding of Instantaneous Rules . . . . . . . . . . . . . . . . . . . . . 155
7.3.5
Encoding of Ongoing Rules . . . . . . . . . . . . . . . . . . . . . . . 156
7.3.5.1
The Initial Rule . . . . . . . . . . . . . . . . . . . . . . . . 156
7.3.5.2
The applyOngoingRules Operator . . . . . . . . . . . . 158
7.3.6
Encoding of Rule Execution Modes . . . . . . . . . . . . . . . . . . . 160
7.3.7
Pass of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.3.7.1
The delta Function . . . . . . . . . . . . . . . . . . . . . 161
7.3.7.2
The mte Function . . . . . . . . . . . . . . . . . . . . . . . 161
Formal Analysis of Real-Time Domain Specific Models with Maude . . . . . . 163
7.4.1
Initial Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.4.2
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.4.2.1
7.4.3
7.4.4
8
Exceptions in Actions . . . . . . . . . . . . . . . . . . . . . 139
Querying the Result of a Simulation . . . . . . . . . . . . . 171
Reachability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.4.3.1
The Role of Tick Modes in the Analysis . . . . . . . . . . . 174
7.4.3.2
Reasoning about Action Executions . . . . . . . . . . . . . . 177
LTL Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
7.5
The e-Motions Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
7.6
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Conclusions and Future Work
187
8.1
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.2
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.3
List of Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.4
Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
A Maude Definitions for Models and Metamodels
xiv
199
B Maude Encoding of the Ecore Metamodel
211
C Maude Definitions for Time and Action Properties
217
D Maude Operations for Querying a Simulation
227
Bibliography
229
xv
xvi
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
xvii
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 AToM3 tool. . . . . . . . . . . . . . . . . . . . 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
xviii
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
xix
xx
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 underlying 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.
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 inability 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 abstractions 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
1
2
C HAPTER 1. I NTRODUCTION
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 usually 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 relationships 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.
Explicit and formal specification of model semantics is receiving more attention recently,
1.1. P ROBLEM S TATEMENT
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 complexity. 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 specifications) 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 modify 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 constraints and delays are essential concepts. Therefore, these concepts should be explicitly modeled in their behavioral specification to enable a proper analysis and simulation [99].
4
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 properties, 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 support 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, easing the specification of real-time DSMLs’ behavior. Our approach avoids unnaturally mod-
1.2. C ONTRIBUTION OF THIS T HESIS
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 modeling language, i.e., its specifications can be easily integrated in MDE processes, and is supported 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 inplace 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 increasing 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 eMotions, 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 executable, 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,
6
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 eMotions language to rewriting logic theories in Maude. This mechanism allow us to automatically transform the structural and behavioral specifications of our DSMLs into Maude,
providing our DSMLs with semantics. Furthermore, we have also developed a model transformation 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.
1.3. O UTLINE OF THIS T HESIS
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 Rewriting 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
8
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.
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 engineering 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 underlying 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. Likewise, 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
9
10
C HAPTER 2. 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 solution space—that is, the domain of computing technologies themselves—rather than abstractions 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 subtle side effects that require considerable effort to program and tune properly. Thus, developers 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 performance. 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) alleviate 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, independently 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
2.1. M ODEL D RIVEN E NGINEERING IN A N UTSHELL
11
and what is irrelevant. Thus the model completely describes those aspects of the physical 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 correspondences between the elements of that model and the parts of that thing. This correspondence 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) particular vision of MDE that relies on the use of OMG standards to represent (among others) models, model relationships, and model-to-model transformations. These standards include UML (Unified Modeling Language), MOF (Meta-Object Facility), OCL (Object Constraint Language), XMI (XML Metadata Interchange) and MOF/QVT (Query/View/Transformations), 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 order 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
12
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 Coelho and Silvia Salinas, and three books, O Alquimista,
Veronika decide morrer and Todo (no) terminó. The first two books were written by Paulo
Coelho, while the last one was written by Silvia Salinas.
Figure 2.3: An Author model (abstract syntax).
13
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 represent 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 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. 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 information associated with functional and QoS requirements captured by models.
The most common type of model transformation is the so called model-to-model transformation. 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 model Ma conforming 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-metamodel MMM (see Figure 2.4).
14
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 endogenous 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 platform comprised of extensible frameworks, tools and support for building, deploying and managing software across the life cycle. It is becoming a widely used platform in the MDE community, 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.
15
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 diagramlike 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.
16
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 instance, the graphical concrete syntax of our e-Motions language (see Section 7.2). More information 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 metamodels. 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 highlighting, 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 information about the tool.
17
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 constructs 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
18
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 ) ] ?
[ using {
var1 : var_type1 = init_exp1 ;
...
varn : var_typen = init_expn ; } ] ?
to
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 keyword using. 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 keyword from. 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
19
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 keyword to. It specifies the elements 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 declaration 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 transformation.
Finally, the optional imperative section, introduced by the keyword do, enables the specification 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
to
p : MMPerson ! Person (
name <− a . name ,
surname <− a . surname )
}
IN and OUT are 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
20
to will be assigned when running the transformation. The same applies for the MMAuthor
and MMPerson variables, which represent the metamodels these models conform to. The rule,
called Author, transforms Author source model elements to Person target model elements. The
source pattern defines no filter, which means that all Author elements of the source MMAuthor model 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, Book source 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 systems. 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 introduce 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].
Rewriting logic (RL) [30, 83] is a logic of change that can naturally deal with state and
2.2. R EWRITING L OGIC
AND
M AUDE
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 4tuple (Σ, E, Φ, R) where (Σ, E) is an equational theory, Φ is the function specifying the frozen
arguments of each operator in Σ, and R is a collection of rewrite rules. Rewrite rules are of the
form [t]E → [t′ ]E , where t and t′ are Σ-terms, and [t]E denotes the equivalence (or congruence)
class of the term t 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 metalanguage 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 several 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 module NATURAL defines the natural numbers (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 the ctor
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 (underscores 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
22
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 operator 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,
with E 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 specifications as parameters. The requirements that a datatype must satisfy are described by theories.
Theories may include declarations of sorts, subsorts, operations, membership axioms and equations 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
module SET provides a sort Set{X} of sets over a given sort of elements (specified by the Elt
sort in the TRIV theory) with the empty constant as the empty set, and , the associative and
commutative union operator, with identity element empty.
f t h TRIV i s
s o r t Elt .
endfth
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 ] .
var E : X$Elt .
eq E , E = E .
endm
The parameter X ::
TRIV indicates that X is the label of the formal parameter, which
must be instantiated with modules satisfying the requirements expressed by the theory TRIV.
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 parameter Elt
becomes X$Elt in the SET module.
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 view Nat maps the theory TRIV to the Maude’s predefined
module NAT of natural numbers.
view Nat from TRIV t o NAT i s
s o r t Elt t o Nat .
AND
M AUDE
23
endv
Then, the module expression SET{Nat} denotes the instantiation of the parameterized module SET with the above view Nat. Notice that the name of the sort Set{X} makes explicit the
label of the parameter. In this way, when the module is instantiated with a view, like for example the Nat view above, the sort name is also instantiated becoming Set{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 functional module plus rules. Unconditional rules are written using the syntax
rl [l] :
t => t′ .
and conditional rules using the syntax
crl [l] :
t => t′ if Cond .
where l is the rule label and Cond its 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 1 /\ ... /\ EqC n where each of the EqC i
is either an ordinary equation t = t′ , a matching equation t := t′ , or a term t of sort Bool,
abbreviating t = true.1 In the execution of a matching equation t := t′ , the variables of the
term t, which may not appear in the lefthand side of the corresponding conditional equation,
become instantiated by matching the term t against the canonical form of the bounded term t′ .
For example, given the quotient operator quo , the following BOARD system module defines a rule replace that 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 equations. 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 rewrite command 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
1
Maude supports other kind of rule conditions, such as, e.g., rewrite conditions of the form t => t′ [42].
24
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 term 4.
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 syntax class C | a1 :S1 , ..., an :Sn , where C is the name of the class, ai are 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, and vi are the current values of its attributes ai . Objects can interact in a number of
different ways, including message passing. Messages are declared in Maude in msg clauses, 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 sort Configuration 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
declaration C < 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: A is a subtype of B if every
<X> that satisfies A also satisfies B (in some contexts, this also means that objects of class A can
AND
M AUDE
25
safely replace objects of class B). Multiple inheritance is also supported in Maude [42, 41].
For instance, the following Maude module EMPLOYEE2 specifies two classes: Person and
Employee. The Person class has an attribute name of sort string (String). The Employee
class extends the Person class and has an attribute salary of sort integer (Int). The String
sort is predefined in the STRING module, and the Int sort 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 | a1 :S1 , ..., an :Sn 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
Person and Employee classes specifications can be rewritten in (Core) Maude (importing the
CONFIGURATION module) 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].
2
Any module, theory, view, or command intended for Full Maude has to be enclosed in parentheses [42]
26
2.2.3 Real-Time Maude
Real-Time Maude [89, 91] is a language and tool for the high-level formal specification, simulation, 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 (although users can define their own time domain);
• a sort TimeInf, which extends the sort Time with the infinite value INF;
• a built-in constructor { } of sort GlobalSystem, with the intended meaning that, given
a term t of sort System, {t} denotes the whole system in state t;
• 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 sort Time that 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 example, 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
module NAT-TIME-DOMAIN to 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 ] .
var 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 every system element; and the mte (maximal time elapse) function, that defines the maximum
amount of time that can elapse before any action can take place. Then, time advances nondeterministically by any amount τ , which must be less or equal than the maximum time elapse
of the system.
AND
M AUDE
27
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
16
{SYSTEM} => {delta ( SYSTEM , R ) } in time R
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
25
eq mte ( SYSTEM SYSTEM ’ ) = min ( mte ( SYSTEM ) , mte ( SYSTEM ’ ) ) .
endtm )
Since the state of the system is now a multiset of clocks, time elapse must be specified
over every clock. The delta operation 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.
The nonexec attribute (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,
the frozen attribute (line 18 and 22) forbids rewriting with rules in all proper subterms of mte
and delta operators to avoid “aged” rewrites [89].
Real-Time Maude identifies two types of tick rules: time-deterministic and time-nondeterministic. Tick rules in which the time increment is explicitly given are called time-deterministic.
This is the case, e.g., of the tick rule described in the CLOCK module, on which we specify that
time advances by 1 time unit. All other tick rules are called time-nondeterministic. In this kind
28
of rules, the time increment is not explicitly specified, but may be restricted (see below). An
example of this kind of tick rules can be found in the CLOCKS module, in which we specify
that time advances by any amount equal or less than the maximum time elapse of the system.
This is the kind of time-nondeterministic tick rule we are going to focus on in this thesis.
Time-nondeterministic tick rules are not directly executable in Maude, since it is not clear
which values to assign to τ (the R variable in the presented example) in a rewrite step. RealTime Maude allows the user to choose from a set of predefined time sampling strategies (also
called tick modes), whose precise meaning is described in [91], for instantiating the variable
R in each application of the tick rule. We present in what follows the tick modes applicable to
the type of time-nondeterministic rule we have selected:
• Default mode. The default mode is parameterized by a time increment value ∆. Time is
advanced by the smallest value of the maximum time elapse of the system and ∆.
• Maximal mode. Time is advanced by the maximal time elapse of the system.
• Maximal/default mode. The maximal/default mode is parameterized by a time value ∆.
Tick rules are applied using a maximal time advance strategy if possible, and by trying
to advance time by the default value ∆ if the maximal time increase is the infinite value
INF.
The tick mode stays unchanged until another tick mode is selected. All applications of
nondeterministic tick rules—be it for rewriting, search, or model checking—are performed using the strategy corresponding to the current tick mode. The user has to note that using either
of these strategies when applying the tick rules means that some potential behaviors in the
system, namely those obtained by applying the tick rules differently, are not analyzed. The discretization provided by the time sampling strategies does not in general preserve all interesting
properties of the system, and all analysis results should be understood in this light [91].
2.2.3.1
Timed Modules in (Core) Maude
Similarly to object-oriented modules, the semantics of a timed module can also be reduced
to that of system modules. In fact, each timed module can be translated into a corresponding
system module whose semantics is by definition that of the original timed module. In this
section, we will focus on the translation of tick rules into rewrite rules. Further details on the
translation performed from Real-Time Maude to (Core) Maude can be found in [91].
AND
M AUDE
29
Let us show how tick rules are encoded in (Core) Maude by presenting the translation of
the time-nondeterministic tick rule used in the previous example for clocks. The original tick
rule is specified as follows:
1
var R : Time .
2
var SYSTEM : System .
3
4
5
c r l [ tick ] : {SYSTEM} => {delta ( SYSTEM , R ) } in time R
i f R <= mte ( SYSTEM ) [ nonexec ] .
Several changes are applied to a tick rule to obtain the final rewrite rule. For instance, we
have to take into account that internally Real-Time Maude adds a clock component to each
state of the system. This component represents the time on which the state was reached.
1
s o r t ClockedSystem .
2
op _in time_ : GlobalSystem Time −> ClockedSystem
[...]
.
Therefore, if we want to find a system state that fits the left-hand side of our rule, we must
include a clock component on it:
1
var T TE : Time .
2
3
4
5
c r l [ tick ] : {SYSTEM} in time T => {delta ( SYSTEM , TE ) } in time ( T plus TE )
i f TE <= mte ( SYSTEM ) [ nonexec ] .
Note that now time will advance TE time units with respect to the time T assigned to the global
SYSTEM state.
Another change is performed depending on the tick mode selected by the user: the nonexec
attribute is removed and the time elapse is set to a specific value, not being nondeterministic
anymore. For instance, if we consider the maximal mode, the previous tick rule will be finally
translated into the following rewrite rule:
1
var T TE : Time .
2
3
4
5
c r l [ tick ] : {SYSTEM} in time T => {delta ( SYSTEM , TE ) } in time ( T plus TE )
i f TE : = mte ( SYSTEM ) / \ TE =/= zero .
Note that TE is assigned the maximal time elapse of the system (computed by the mte operation). Furthermore, we include the TE =/= zero condition. This is a pragmatic choice based
on the fact that advancing time by zero units using this kind of tick rules does not change the
state, but leads to unnecessary looping during executions [91].
Of course, the resulting rewrite rule will represent the original tick rule whenever we import
in our specifications the system modules on which Real-Time Maude defines the time domains
and the built-in constructor for global systems.
30
2.2.4 The mOdCL Tool
mOdCL [108] is an OCL validation tool based on Maude. The tool allows us to validate OCL
expressions on concrete UML object diagrams. However, its implementation is not tied to its
internal representation of the UML metamodel, and therefore it can be adapted to be applied
over other DSMLs. In this section, we sketch the mOdCL representation of the main OCL
concepts in Maude that we are going to use throughout this thesis. The complete mOdCL
specification is available at [10]. The complete set of renamings that we have performed over
the sorts and operators defined in mOdCL to adapt them to our Maude infrastructure to represent models and metamodels can be found in Appendix A, although those that affect the
comprehension of this thesis will be presented throughout this document as needed.
In mOdCL, OCL expressions are represented as terms of the OCL-Exp sort. The basic OCL
types Boolean, Integer, Real and String are, respectively, mapped into the Maude predefined
sorts Bool, Int, Float and String, whereas the user defined types are mapped on the Maude
predefined sort Oid. OCL predefined collection types are built over the generic sorts List{X}
an MSet{X}, which represent ordered and non-ordered collections of elements, respectively.
1
mod CONTAINER{X : : OCL−TRIV} i s
2
s o r t s List{X} MSet{X} .
3
s u b s o r t X$Elt < List{X} .
4
s u b s o r t X$Elt < MSet{X} .
5
op mt−ord : −> List{X} [ ctor ] .
6
op _ , _ : List{X} List{X} −> List{X} [ ctor assoc id : mt−ord . . . ] .
7
op mt : −> MSet{X} [ ctor ] .
8
op _ ; _ : MSet{X} MSet{X} −> MSet{X} [ ctor assoc comm id : mt . . . ] .
9
10
...
endm
Each type of collection (Set, Bag, OrdSet and Sequence) is then built by wrapping its corresponding type of collection of elements (ordered or non-ordered), with the suitable constant:
1
2
mod COLLECTION i s
pr CONTAINER{OCL−Exp} .
3
4
op Set{_} : MSet{OCL−Exp} −> Set [ ctor ] .
5
op Bag{_} : MSet{OCL−Exp} −> Bag [ ctor ] .
6
op OrderedSet{_} : List{OCL−Exp} −> OrdSet [ ctor ] .
7
op Sequence{_}
8
op Set{} : −> Set .
9
op Bag{} : −> Bag .
: List{OCL−Exp} −> Sequence [ ctor ] .
10
op Sequence{} : −> Sequence .
11
op OrderedSet{} : −> OrdSet .
12
eq Set{} = Set{mt} .
13
eq Bag{} = Bag{mt} .
14
eq Sequence{}
= Sequence{mt−ord} .
15
16
17
AND
M AUDE
31
eq OrderedSet{} = OrderedSet{mt−ord} .
...
endm
Set{}, Bag{}, Sequence{} and OrderedSet{} operators are defined as syntactic sugar to
represent the empty collection of its corresponding type. The Set{ } and Bag{ } operators
are built over non-ordered collections, while OrderedSet{ } and Sequence{ } are built over
ordered collections. Contrary to bags and sequences, sets and ordered sets cannot have duplicated elements. These elements are removed (by further mOdCL equations) when the OCL
expression is evaluated.
mOdCL provides syntax for all OCL operators. OCL expressions written using these declarations follow very closely the original OCL syntax. Only some differences apply: the =
operator is represented as the .=. operator, the elements of sets and bags are separated by a
semicolon instead of a comma, and every subexpression of an OCL expression must be separated by a space. As we will see in Chapter. 7, OCL expressions written in e-Motions are
transparently mapped into the mOdCL notation, so the user is not aware of these syntactic
mismatches.
mOdCL also provides several operators to evaluate well-formed OCL expressions. The
following is an example on how we can evaluate a context-free OCL expression in Maude by
means of the << >> operator:
1
Maude> r e d u c e << Sequence{1 , 3 , 4} −> size ( ) >> .
2
3
r e s u l t NzNat : 3
32
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 separate it from the definition of its behavior. Thus, we identify two views in
the definition of a DSML: the structural view and the behavioral view. We give some hints on
how the DSML designer can be kept from explicitly defining the semantics of his/her DSML.
3.1 Introduction
Domain-Specific Modeling Languages (DSMLs) formalize the application structure, behavior,
and requirements within particular domains. Such languages tend to support higher level abstractions 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. Furthermore, the rules of the domain can be included into the language as constraints, disallowing the
specification of illegal or incorrect models.
The definition of a DSML 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 (see Figure 3.1). Most of the MDE
community efforts have been focused on the definition of the structural parts of DSMLs, i.e.,
on the definition of models and metamodels, and some graphical o textual syntax for them—
this is what is usually called the metamodeling technique. This approach enables the rapid
33
34
C HAPTER 3. D EFINING A D OMAIN S PECIFIC M ODELING L ANGUAGE
Figure 3.1: Definition of a DSML.
development of languages and some of their associated tools, such as editors or browsers.
However, the idea of MDE is not to use models 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. Since models
are defined with DSMLs, we should not avoid the definition of the semantics of a DSML,
specially when we need to explicitly describe its behavior.
3.2 Abstract Syntax of a DSML
The abstract syntax of a DSML is usually specified by a metamodel, which describes the concepts of the language, the relationships among them, and the structuring rules that constrain the
model elements and their combinations in order to respect the domain rules. We normally say
that a model conforms to the metamodel that represents the concepts of the DSML the model
is written in [20].
Figure 3.2 shows a metamodel of a DSML for production systems defined with the Ecore
language. In this metamodel, a production system is made of plants that are composed of
machines: generators (HeadGen and HandleGen) and assemblers; containers, which can be
trays, conveyors and users; and parts: heads, handles and hammers. Trays can be connected to
machines; machines are connected to conveyors, and conveyors are connected to trays. Trays,
conveyors, and users can hold different parts (heads, handles and hammers). Note that no
information is included about the behavior of these elements.
Figure 3.3 shows a production model example (conforming to the metamodel in Figure 3.2)
3.3. C ONCRETE S YNTAX OF A DSML
35
Figure 3.2: Metamodel of a DSML for production systems.
Figure 3.3: A production system model (abstract syntax).
using an object diagram. The model consists of a plant with two generators, each one connected
to a different conveyor. These conveyors are connected to the same tray, which is connected
in its turn to an assembler. The assembler is connected to a third conveyor, which is also
connected to another tray.
3.3 Concrete Syntax of a DSML
The concrete syntax of a DSML provides a realization of its abstract syntax as a mapping
between the metamodel concepts and their textual or graphical representation (see Figure 3.1).
For visual languages, it is necessary to establish links between these concepts and the visual
symbols that represent them—as done, e.g, with GMF (see Section 2.1.4.2). Similarly, with
textual languages links are required between metamodel elements and the syntactic structures
36
of the textual DSML. An example of this approach is TCS (see Section 2.1.4.3). Of course, a
language can have several concrete syntaxes.
Figure 3.4: A concrete syntax for the DSML for production systems.
Figure 3.4 shows a simple visual concrete syntax for the DSML for production systems.
We have associated an image to each class of the metamodel. For instance, machines are
represented as cogwheels with an icon showing the kind of part they generate.
Figure 3.5: A production system model (concrete syntax).
Once we have defined a concrete syntax for a DSML, we can make use of it, e.g., to define
visual models. Figure 3.5 shows the model depicted in Figure 3.3 using the above concrete
syntax. In this case, we have represented references between objects as directed arrows, and
attribute-value pairs textually, except the position of each element, which is dictated from its
position in the plant (depicted as the background grid).
3.4. S EMANTICS OF A DSML
37
The graphical concrete syntax can also be used in the definition of the behavioral rules of a
DSML, as we shall see in Chapters 6 and 7.
3.4
Semantics of a DSML
Defining a DSML only by means of its abstract and concrete syntaxes allows the rapid development of languages and some 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.
Explicit and formal specification of model semantics is receiving more attention recently,
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 complexity. 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.
In general, DSMLs have not been given semantics or has been done using natural languages. Although users can normally guess the meaning of most terms of a DSML (a good
language designer probably chooses keywords and special symbols with a meaning similar to
some accepted norm), a computer cannot act on such assumptions [66]. To be useful in the
computing arena, any language (let it be textual or visual or used for programming, requirements, specification, or design) must come with rigid rules that clearly state allowable syntactic
expressions and give a rigid description of their meaning.
A formal description of a language’s semantics has been usually done using an operational,
denotational or axiomatic style (see, e.g., [128] for a comprehensive survey of semantic description frameworks). Operational semantics involves the specification of an abstract machine
or transition system, the computations of which represent possible executions of a language expression. A denotational semantics is given by a mathematical function which maps the syntax
of the language to a semantic value (a denotation). Axiomatic semantics involves rules for deducing assertions on the correctness or equivalence of language expressions and corresponding
parts [128]. Each of these frameworks have particular properties, but the distinction between
38
them is seldom sharp: they frequently borrow features from each other.
In MDE, the definition of the semantics of a DSML can be also accomplished through the
definition of a mapping between the language itself and another language with well-defined
semantics (see Figure 3.1) such as Abstract State Machines [37], Petri Nets [49], or rewriting
logic [104]. This method, which is also proposed by other authors (see, e.g., [18, 40, 73]), it
is usually called translational semantics. The advantage of using a model-driven approach is
that these semantic mappings can be defined in terms of model transformations.
Semantic mappings can be defined to more that one semantic domain, providing the DSML
with alternative semantic representations. Each semantic domain is more appropriate to represent and reason about certain properties, and to conduct certain kinds of analysis. Therefore,
these semantic mappings are very useful not only to provide precise semantics to the DSMLs,
but also to be able to simulate, analyze or reason about them using the logical and semantical framework available in the target domain [45]. Of course, not all the transformations can
always be accomplished: it depends on the expressiveness of the semantic domain.
Note that when the semantic mappings can automatically be derived, the underlying semantic domain(s) as well as the semantic mappings themselves can be completely transparent
to the DSML designer. This mechanism has several advantages: the DSML designer do not
need to know the semantic domain(s), nor the relationship between the concepts of his/her
DSML and the concepts of the semantic domain, and he/she can still being benefited from its
analysis tools. We call semantic bridges to those general mappings between different domains
from which DSML-specific semantic mappings can be automatically derived (see Figure 3.8).
Models can then cross these bridges to benefit from each world without being aware of how
they were constructed (see Figure 3.6).
3.4.1 Semantics Is Not Behavior
A common misconception in modeling languages is to confuse semantics with behavior [66].
Some of the most intricate languages deal with behavior, especially reactive behavior. Their
semantics must prescribe the system’s behavior for each allowed model, so that for such languages, behavior and semantics are closely related. However, even structure description languages such as entity-relationship diagrams or UML class diagrams also need semantics so that
users know exactly what the language is defining. Hence, semantics and behavior are not to be
confused. Both a system’s behavior and its structure are important views in system modeling:
Both are represented by syntactic concepts, and both need semantics.
3.5. D EFINING A DSML (R EVISITED )
39
Figure 3.6: Semantic bridges across different domains.
Semantic domains normally include mechanism to specify the behavior of systems, and
therefore the behavior of a DSML is usually encoded in the semantic domain directly [37, 104].
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. If we define the behavior as a model in a separate way (as usually done with the structure), we can define an intuitive graphical notation for it, and we can transform it into different
semantic domains by using semantic bridges (see Figure 3.7), alleviating these disadvantages.
Figure 3.7: Mapping a DSML to different semantic domains.
3.5 Defining a DSML (Revisited)
Once we have clarified the difference between behavior and semantics, we propose defining
a DSML by means of two views: the structural view and the behavioral view. The elements
40
involved in the definition of a DSML (abstract syntax, concrete syntax and semantics, see
Figure 3.8) will then be specified for both of them (note the * upper bound for the cardinality
of the specification association). However, as we shall see in the next chapters, our approach
keeps the DSML designer from explicitly defining the elements involved in the definition of
the semantics of the DSML (namely semantic mappings and semantic models), since they are
automatically derived from the model transformations we have developed.
Figure 3.8: Definition of a DSML (revisited).
3.5.1 Defining the Structural View of a DSML
In MDE, there is already a common agreement on how to specify the structure of a DSML:
by means of a metamodel (see Section 3.2). The structural concepts defined in the metamodel
can be provided with a concrete syntax by mapping them to their corresponding (graphical or
textual) symbols (see Section 3.3). The same concepts can also be provided with semantics by
mapping them to a semantic domain, such as Membership Equational Logic (MEL) in Maude
(see Chap. 4).
Figures 3.9 shows the models we identify in our approach in the definition of the structural
view of a DSML for a particular example: the DSML for production systems (see Section 3.2).
As we shall see in Chap. 4, the structural semantic mappings and the structural semantic model
do not need to be explicitly defined: they are derived from the model transformation we have
defined between Ecore and Maude.
3.5. D EFINING A DSML (R EVISITED )
41
Figure 3.9: Structural View of a DSML for Production Systems.
3.5.2 Defining the Behavioral View of a DSML
There is no common agreement on how to specify the dynamic behavior of a DSML. One particular way to do it is by describing the evolution of the state of the modeled artifacts along
some time model. In MDE, where models, metamodels and model transformations are the
key artifacts, model transformations seem to be the natural way. In particular, model transformation languages that support in-place update [46] are perfect candidates for the job. This
kind of transformations allow users to describe the permitted actions and how the model elements evolve as a result of these actions. Furthermore, they also 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 (see Section 6.3.1 for more information about
in-place model transformation and Section 6.5 for related work).
Once we have defined the possible actions of our system, we could provide them with a
specific notation by defining a mapping between the actions and their corresponding (graphical
or textual) symbols. Note that at a particular moment of time, some model elements can be
involved in an action (or in some of them), specially when these actions have a specific duration
(see Chap. 7), and a user can be interested in representing these action occurrences explicitly.
Normally, modeling tools do not allow users to explicitly represent action executions, they
only allow us to represent system states. As we shall see in Section 7.5, our e-Motions tool
42
does enable the representation of action executions in a general way in the specification of the
behavior of a DSML.
The possible actions of the system can also be provided with semantics by mapping them
to a semantic domain, such as RL in Maude (see Chap. 6).
Figure 3.10: Behavioral View of a DSML for Production Systems.
Figures 3.10 shows the models we identify in our approach in the definition of the behavioral view of a DSML for the same particular example: the DSML for production systems.
Again, the behavioral semantic mappings and the behavioral semantic model do not need to be
explicitly defined: they are derived from the model transformation we have defined between
e-Motions and Maude (see Chap. 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 model transformation) between EMF models and
metamodels and MEL, or, to be more precise, to the Maude implementation of MEL. These
model transformations will prevent the DSML designer from explicitly defining the structural
semantics of his/her DSML. We also present the Maude metamodel, parser and serializer that
we have defined for this purpose.
4.1 MEL Representation of Models and Metamodels
As we previously mentioned, models are written in the language described by their metamodels. Metamodels define the concepts of the language, the relationships among them, and the
structuring rules that constrain the model elements and their combinations in order to respect
the domain rules. So, the question is, can these three elements be represented in Maude? Of
course they can, and many choices exist for this (see Section 4.3).
In this section we show how MEL is a suitable formalism to represent models and metamodels. Among all the possible representations, we have defined a specific one and we show
its benefits—the following chapters will also presents more advantages related to the use of
this formalism and this specific representation.
43
44
C HAPTER 4. S TRUCTURAL S EMANTICS OF DSML S
4.1.1 Representing Metamodels with Maude
A metamodel can be specified in Maude as a MEL theory. This theory should include the
algebraic representation for all the corresponding object types and model types. As a first attempt, one could think about making a direct use of Full Maude classes and attributes to specify
these object types in object-oriented modules. However, although this being a completely valid
solution, there are some issues that made us decide to build a new infrastructure:
• This representation does not consider some metamodel elements such as packages or the
metamodel itself, but just classes and attributes. Furthermore, the definitions of classes
and attributes do not include all the information related to these elements in a metamodel,
such as whether a class is abstract or not, or the types of the references.
• The common object representation used in Full Maude [42] forces us to access Maude’s
metalevel to perform some common tasks in metamodel-independent operations, something that degrades performance when dealing with large models. These tasks include
checking whether a class inherits from another, or accessing an attribute value independently of its attribute name.
Our infrastructure then refines the algebraic representation of classes and objects in Core
Maude (see Section 2.2.2.1) to (a) include more metamodel-related properties and (b) avoid
accessing Maude’s metalevel when dealing with common tasks. To support the features expressed in (a), we include in our Maude specifications a sort for every metamodel element: a
sort @Class for classes, a sort @Attribute for attributes, a sort @Reference for references,
etc. In particular, we have defined nine sorts: @NamedElement, @Metamodel, @Package,
@Classifier, @StructuralFeature, @Attribute, @Reference, @DataType and @Enumeration. The relationships among these sorts can be found in Appendix A, and they cor-
respond to the relationships between the Ecore classes (see Figure 2.5) that each of these
sorts represent. In fact, this initial infrastructure can be seen as the representation of a metametamodel, such as Ecore.
To support the features expressed in (b), we include a set of operations defined over the
sorts that represent metamodel elements. The equations that define these operations will gather
all the information related to the properties of metamodel elements. For instance, we gather
the superclasses relationships, the name of every class, the cardinality of structural features, the
type of references, etc. These equations will allow users to get all the metamodel information
from a model conforming to it, and therefore it makes it unnecessary to access to Maude’s
4.1. MEL R EPRESENTATION OF M ODELS AND M ETAMODELS
45
metalevel for, e.g., checking whether a class inherits from another or not.
Thus, we represent a metamodel MM as a MEL theory T on which each class of the metamodel is represented by a constant of a sort named after the class. This sort, which will be
declared as subsort of sort @Class, is defined to support class inheritance through Maude’s
order-sorted type structure. Attributes, references, packages and the metamodel as an element itself are represented by constants of sorts @Attribute, @Reference, @Package and
@Metamodel, respectively. The properties of all these elements will be represented by means
of Maude equations defined over their corresponding constants (see below).
To illustrate our proposal, let us introduce the fragment of Maude specification that describes the elements of the production system metamodel depicted in Figure 3.2:
1
mod PRODUCTION−SYSTEM i s
2
p r o t e c t i n g @ECORE@ .
3
4
op ProductionSystem : −> @Metamodel .
5
op PS : −> @Package .
6
7
s o r t Plant .
8
s u b s o r t Plant < @Class .
9
op Plant : −> Plant .
10
op els : −> @Reference .
11
12
s o r t PositionedEl .
13
s u b s o r t PositionedEl < @Class .
14
op PositionedEl : −> PositionedEl .
15
op xPos : −> @Attribute .
16
op yPos : −> @Attribute .
17
18
s o r t Machine .
19
s u b s o r t Machine < PositionedEl .
20
op Machine : −> Machine .
21
op in : −> @Reference .
22
op out : −> @Reference .
23
24
s o r t Assembler .
25
s u b s o r t Assembler < Machine .
26
op Assembler : −> Assembler .
27
op counter : −> @Attribute .
28
29
s o r t Generator .
30
s u b s o r t Generator < Machine .
31
op Generator : −> Generator .
32
33
s o r t s HandleGen HeadGen .
34
s u b s o r t s HandleGen HeadGen < Generator .
35
op HandleGen : −> HandleGen .
36
op HeadGen : −> HeadGen .
46
37
38
s o r t Container .
39
s u b s o r t Container < PositionedEl .
40
op Container : −> Container .
op parts : −> @Reference .
41
42
43
s o r t Tray .
44
s u b s o r t Tray < Container .
45
op Tray : −> Tray .
op capacity : −> @Attribute .
46
47
48
s o r t Conveyor .
49
s u b s o r t Conveyor < Container .
50
op Conveyor : −> Conveyor .
op out : −> @Reference .
51
52
53
s o r t User .
54
s u b s o r t User < Container .
55
op User : −> User .
56
57
s o r t Part .
58
s u b s o r t Part < PositionedEl .
59
op Part : −> Part .
60
61
s o r t Head Handle Hammer .
62
s u b s o r t s Head Handle Hammer < Part .
63
op Head : −> Head .
64
op Handle : −> Handle .
65
op Hammer : −> Hammer .
66
67
68
...
endm
Predefined sorts @Class, @Attribute, etc. are imported from the @ECORE@ module, which
also includes the definition of the Ecore metamodel (see Appendix B).
Note that this representation is quite similar to that presented in Section 2.2.2.1 for objectoriented features in Maude. In fact, our infrastructure just refine it (by adding more metamodel
elements and several operations to gather their corresponding properties). The way we have
performed the refinements together with some renamings (see Appendix A) enable the interoperability between these two representations, and therefore we can make use of the tools
defined for the common representation suggested in [42] (such as the mOdCL tool) with our
specifications.
The properties of metamodel elements, such as whether a class is abstract or not, the opposite of a reference (to represent bidirectional associations), or attributes and reference types,
are expressed by means of Maude equations defined over the constant that represents the cor-
47
responding metamodel element. Basically, we gather every metamodel element property reflected in the Ecore metamodel except those that refer to Java properties, which are not inherent
in a metamodel description but specific to the EMF capability of generating Java code from the
metamodel specification.
The following fragment of Maude code includes the equations defined for some of the elements of the production system metamodel, namely the metamodel itself, the package on which
all the classes are defined, the class Tray, and two of its structural features: the capacity attribute and the in reference. The specification of all the operations defined for this purpose can
be found in the METAMODEL-PROP module in Appendix A.
mod PRODUCTION−SYSTEM i s
...
--- metamodel ProductionSystem
eq name ( ProductionSystem ) = "ProductionSystem" .
eq packages ( ProductionSystem ) = PS .
--- package PS
eq name ( PS ) = "PS" .
eq metamodel ( PS ) = ProductionSystem .
eq superPackage ( PS ) = null .
eq subPackages ( PS ) = nil .
eq classes ( PS ) = PositionedEl Plant Machine Container Part HandleGen HeadGen
Generator Assembler Tray Conveyor User Head Handle Hammer .
--- class Tray
eq name ( Tray ) = "Tray" .
eq package ( Tray ) = PS .
eq superTypes ( Tray ) = Container .
eq isAbstract ( Tray ) = false .
eq references ( Tray ) = nil .
eq attributes ( Tray ) = capacity .
--- attribute capacity (of class Tray)
eq name ( capacity ) = "capacity" .
eq type ( capacity ) = @Int .
eq lowerBound ( capacity ) = 1 .
eq upperBound ( capacity ) = 1 .
eq containingClass ( capacity ) = Tray .
eq isOrdered ( capacity ) = true .
eq isUnique ( capacity ) = true .
eq isId ( capacity ) = false .
--- reference in (of class Machine)
eq name ( in ) = "in" .
eq type ( in ) = Tray .
eq opposite ( in ) = null .
eq lowerBound ( in ) = 0 .
48
eq upperBound ( in ) = 1 .
eq containingClass ( in ) = Machine .
eq isOrdered ( in ) = true .
eq isUnique ( in ) = true .
eq isContainment ( in ) = false .
...
endm
Classes, attributes and references are qualified with their containers’ names, so that classes
with the same name belonging to different packages, as well as attributes and references of
different classes, are distinguished. For example, assuming that all the classes in the model
are included in a package PS, identifiers Machine and out would really be Machine@PS and
out@Machine@PS (or out@Conveyor@PS). These qualifications are omitted here to improve
readability. The interested reader is referred to Appendix B to see an example of a metamodel
definition (namely, the Ecore metamodel) where these qualifications are shown.
4.1.2 Representing Models with Maude
Once we have described a metamodel in Maude as a MEL theory, we can represent models
conforming to it by means of Maude terms that belong to this MEL theory. In particular, we
represent models as structures of sort @Model of the form mm{obj1 obj2 ... objN }, where mm
is the constant that represent the metamodel, and obji are the objects that constitute the model.
Objects are record-like structures of the form < o : c | a1 :v1 # ...# an :vn >, where o is the
object identifier (of sort Oid), c is the class the object belongs to (a subsort of sort @Class),
and ai : vi are attribute-value pairs (of sort @StructuralFeatureInstance). Attributevalue pairs, which represent both (Ecore) attributes and references, are constructed in such a
way that attribute names (of sort @Attribute or @Reference, respectively) are distinguished
from attribute values (of sort OCL-Type), and therefore, they can be accessed independently
with a simple Maude match instead of making use of metalevel operations—as done when
using the representation suggested in [42].
For instance, the following Maude specification describes the production system model
depicted in Figures 3.3 and 3.5:
op psModel : −> @Model .
eq psModel
= ProductionSystem {
< ’p : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u } >
< ’heg : HeadGen | in : null # out : ’c1 # counter : 10 # xPos : 1 # yPos : 3 >
< ’hag : HandleGen | in : null # out : ’c2 # counter : 10 # xPos : 1 # yPos : 1 >
49
< ’c1 : Conveyor | parts : Sequence{} # out : ’t1 # xPos : 2 # yPos : 3 >
< ’t1 : Tray | parts : Sequence{} # capacity : 4 # xPos : 3 # yPos : 2 >
< ’a : Assembler | in : ’t1 # out : ’c3 # xPos : 4 # yPos : 2 >
< ’t2 : Tray | parts : Sequence{} # capacity : 4 # xPos : 6 # yPos : 2 >
< ’u : User | parts : Sequence{} # xPos : 6 # yPos : 3 >
} .
References are represented by object identifiers, which are in turn represented by quoted
identifiers (identifiers prefixed by a quote). Attribute and reference values are specified by OCL
expressions, which are fully supported thanks to mOdCL. We have applied some renamings to
the original mOdCL specifications to adapt it to our Maude representation of model and metamodels. For instance, the , operator is now named # , and therefore elements of sequences
and ordered sets are now separated by hash marks. The interested reader is referred to Appendix A for more details on our algebraic constructors and the renamings we have applied to
mOdCL specifications.
Finally, note that metamodels can also be seen as models that conform to meta-metamodels,
and therefore they can be represented as Maude terms of sort @Model too. The MEL theory
that defines their constructors will represent a meta-metamodel, such as the MOF or Ecore
metamodel.
4.1.2.1
The Conformance Relationship
As we previously mentioned, once we have described a metamodel in Maude as a MEL theory,
we can represent models conforming to such a metamodel by means of Maude terms that
belong to the @Model sort, but it does not mean that all the terms of this sort will represent
models which really conform to the metamodel that the MEL theory describes. If we want to
ensure this, we have to check that the term of sort @Model obeys the structuring rules specified
by the properties of the metamodel elements, such as the types of the objects being referenced,
or the cardinality of the structural features.
The correct construction of the objects in a model is checked by the Maude type system. In
addition, other metamodel properties (such as the valid types of the objects being referenced)
is expressed in terms of the validModel predicate that define the well-formedness rules that
any valid model should conform to. Thus, given a variable OBJSET of sort Set{@Object},
we define a sort for every model type by means of membership axioms as follows:
s o r t PS@Model .
s u b s o r t PS@Model < @Model .
50
cmb ProductionSystem { OBJSET } : PS@Model i f validModel ( ProductionSystem { OBJSET } ) .
Membership axioms (mb) and conditional membership axioms (cmb) assign sorts to terms.
Thus, a term of sort @Model becomes also of sort PS@Model if its metamodel is ProductionSystem and the objects that constitute it fulfills all the metamodel properties. This last require-
ment is checked with the validModel operation; the following is an excerpt of its specification:
1
mod MODELCONFORMANCE i s
2
pr METAMODEL−PROP .
3
4
v a r s MM : @Metamodel .
5
v a r s MODEL : @Model .
6
v a r s C C ’ : @Class .
7
v a r s O SRC : Oid .
8
v a r s OBJSET : Set{@Object} .
9
v a r s SFS SFS ’ : Set{@StructuralFeatureInstance} .
10
v a r s ATTIS : Set{@AttributeInstance} .
11
v a r s REFIS : Set{@ReferenceInstance} .
12
var ATT : @Attribute .
13
var REF : @Reference .
14
var VALUE : OCL−Type .
15
var LO : List{OCL−Exp} .
16
v a r s ATTS REFS : MyList .
17
var SEQ : Sequence .
18
19
op validModel : @Model −> Bool .
20
eq validModel ( MODEL ) = validModelAux ( MODEL , MODEL ) .
21
22
op validModelAux : @Model @Model −> Bool .
23
eq validModelAux ( MM { none } , MODEL ) = true .
24
eq validModelAux ( MM { < O : C | ( ATTIS # REFIS ) > OBJSET } , MODEL ) =
25
( ( metamodel ( C ) == MM ) or−else isEcore ( metamodel ( C ) ) )
26
and−then validReferences ( allReferences ( C ) , < O : C | REFIS >, MODEL )
27
and−then validAttributes ( allAttributes ( C ) , < O : C | ATTIS >)
28
and−then validModelAux ( MM { OBJSET } , MODEL ) .
29
eq validModelAux ( MM { OBJSET } , MODEL ) = false [ owise ] .
30
31
op validAttributes : MyList @Object −> Bool .
32
eq validAttributes ( nil , < O : C | empty >) = true .
33
eq validAttributes ( ( ATT ATTS ) , < O : C | ( ATT : VALUE # ATTIS ) >) =
34
( isUnique ( ATT ) == isUnique ( VALUE ) )
35
and−then ( isOrdered ( ATT ) == isOrdered ( VALUE ) )
36
and−then ( isMany ( ATT ) == isMany ( VALUE ) )
37
and−then ( lowerBound ( ATT ) <=Card size ( VALUE ) )
38
and−then ( size ( VALUE ) <=Card upperBound ( ATT ) )
39
and−then (<< VALUE −> asSequence ( ) −> isEmpty ( ) >> or−else
40
41
42
subTypeOf ( meta ( VALUE ) , type ( ATT ) ) )
and−then validAttributes ( ATTS , < O : C | ATTIS >) .
eq validAttributes ( ATTS , < O : C | ATTIS >) = false [ owise ] .
51
43
44
op validReferences : MyList @Object @Model −> Bool .
45
eq validReferences ( nil , < O : C | empty >, MODEL ) = true .
46
eq validReferences ( ( REF REFS ) , < O : C | ( REF : VALUE # REFIS ) >, MODEL ) =
47
( isUnique ( REF ) == isUnique ( VALUE ) )
48
and−then ( isOrdered ( REF ) == isOrdered ( VALUE ) )
49
and−then ( isMany ( REF ) == isMany ( VALUE ) )
50
and−then ( lowerBound ( REF ) <=Card size ( VALUE ) )
51
and−then ( size ( VALUE ) <=Card upperBound ( REF ) )
52
and−then validRefType ( << VALUE −> asSequence ( ) >>, type ( REF ) , MODEL )
53
and−then ( ( opposite ( REF ) == null ) or−else
validOpposites(<< VALUE −> asSequence ( ) >>, opposite ( REF ) , O , MODEL ) )
54
and−then validReferences ( REFS , < O : C | REFIS >, MODEL ) .
55
56
eq validReferences ( REFS , < O : C | REFIS >, MODEL ) = false [ owise ] .
57
58
op validRefType : Sequence @Class @Model −> Bool .
59
eq validRefType ( Sequence{mt−ord } , C , MODEL ) = true .
60
eq validRefType ( Sequence{O # LO } , C ’ , MM { < O : C | SFS > OBJSET } ) =
isSubClass ( C , C ’ )
61
and−then validRefType ( Sequence{LO } , C ’ , MM { < O : C | SFS > OBJSET } ) .
62
63
eq validRefType ( SEQ , C , MODEL ) = false [ owise ] .
64
65
op validOpposites : Sequence @Reference Oid @Model −> Bool .
66
eq validOpposites ( Sequence{mt−ord } , REF , SRC , MODEL ) = true .
67
eq validOpposites ( Sequence{O # LO } , REF , SRC ,
MM { < O : C | ( REF : VALUE # SFS ) > OBJSET } ) =
68
69
<< VALUE −> asSequence ( ) −> includes ( SRC ) >>
70
and−then validOpposites ( Sequence{LO } , REF , SRC ,
MM { < O : C | ( REF : VALUE # SFS ) > OBJSET } ) .
71
72
eq validOpposites ( SEQ , REF , O , MODEL ) = false [ owise ] .
73
74
75
...
endm
The validModelAux operation is recursively applied over every object of the model. It
checks whether the object class belongs to the specified metamodel or to the Ecore metamodel, since this one is imported in every metamodel. Then, it checks with the auxiliary
validReferences and validAttributes operations (a) that every reference and attribute
value fulfills the properties of the structural feature specified in the metamodel, such as its
cardinality or type; and (b) that no attribute or reference is missing or borrowed from another
class. Metamodel properties can be accessed directly from the model thanks to the equations
we define for every metamodel. Most of the equations defined for attributes and references,
such as isOrdered and isUnique, are defined over attributes and references values (of sort
OCL-Type) too, in order to check their correspondence (see Appendix A). The meta operator
(see line 40 in the above excerpt of code) obtains from a term of sort OCL-Type its primitive
52
data type. The <=Card operator is used to check whether a cardinality value is less or equal
than another (it considers the * symbol).
Note that we do not need to access Maude’s metalevel in any moment. Furthermore, our
notation allows to easily separate attributes and references in a match (see line 24), and attribute
and reference names from their values (see lines 33 and 46), thus facilitating the specification
of model operations.
Further structural constraints can also be checked with the mOdCL tool (see Section 2.2.4).
The mOdCL tool allows us to specify OCL invariants and then check them on any specific
model. For instance, the following invariant specifies that the capacity of any tray is not exceeded:
1
op noCapacityExceeded : −> OCL−Exp .
2
eq noCapacityExceeded = context Tray inv ( self . parts −> size ( ) <= self . capacity ) .
This invariant can be checked over the psModel model we defined in Section 4.1.2 by typing:
1
Maude> r e d u c e << noCapacityExceeded ; psModel >> .
2
3
r e s u l t Bool : true
The << ; >> operator evaluates the OCL expression given as the first argument in the context
of the model given as the second argument.
4.2 Structural Semantic Mappings
As we mentioned in Section 3.4, the definition of the semantics of a language can be accomplished through the definition of a mapping between the language itself and another language
with well-defined semantics. Thus, once we have defined a way to specify models and metamodels in the semantic domain of MEL, we can define mappings from other languages such as
MOF or Ecore, providing them with semantics. Furthermore, the advantage of using a modeldriven approach is that these mappings can be defined in terms of model transformations [123].
4.2.1 Maude’s Metamodel, Parser and Serializer
The first step to specify a model transformation between two languages is to define their corresponding metamodels. Since MOF and Ecore metamodels are already defined (see Section 2.1.4.1), we just need to create a metamodel for Maude. Thus, we provide a Maude
metamodel (implemented as Ecore and KM3 [21] models), a model-to-text transformation to
serialize Maude models (i.e., to get the corresponding Maude code), and a Maude parser for
4.2. S TRUCTURAL S EMANTIC M APPINGS
53
models specified with Maude code. This allows Maude specifications to be represented as
models and fully integrated into MDE processes. The specifications of all these artifacts are
included in our e-Motions tool, which can be download from our group’s website [2].
4.2.1.1
The Metamodel Definition
The Maude metamodel [98] is shown in Figure 4.1. It is based on the Maude language definition, whose grammar can be found in [42]. The metamodel does not cover the whole Maude
language, it is restricted to the elements needed in our formalization of models and metamodels
with Maude. The interested reader is referred to [42] for a description of the Maude language
concepts.
Specifying a metamodel implies the choice between different design options. Some of these
choices introduce new constraints to the language that must be considered in the metamodel
definition. For instance, in the Maude metamodel diagram shown in Figure 4.1, we do not
distinguish the type of elements that every kind of module can have; therefore, we include an
OCL invariant to forbid the inclusion of rewrite rules (Rule) in functional modules (FModule).
Another example is the relationship between a recursive term (RecTerm) and an operation
(Operation): we have not specified a link between them because Maude allows overloading
of operators and there are recursive terms on which we cannot figure out the specific operator
it refers to without previous evaluation of the subterms. However, we can force that at least
there exists one operation that makes the recursive term a valid term by including another OCL
invariant (see the fifth invariant below). The following constraints have been then added to the
metamodel definition:
-- Membership axioms cannot have rewrite conditions
c o n t e x t Membership i n v :
s e l f . conds−>forAll ( c | c . oclIsKindOf ( EquationalCond ) )
-- Equations cannot have rewrite conditions
c o n t e x t Equation i n v :
s e l f . conds−>forAll ( c | c . oclIsKindOf ( EquationalCond ) )
-- Functional modules cannot have rules
c o n t e x t FModule i n v :
not s e l f . els−>exists ( e | e . oclIsTypeOf ( Rule ) )
-- Constant terms must be declared (by an operation)
c o n t e x t Constant i n v :
Operation . AllInstances ( )−>exists ( o | o . name = s e l f . op and
s e l f . type . isSubsortOf ( o . coarity ) )
54
Figure 4.1: The Maude metamodel.
-- Recursive terms must be declared (by an operation)
c o n t e x t RecTerm i n v :
Operation . allInstances ( )−>exists ( o | o . name = s e l f . op and
s e l f . type . isSubsortOf ( o . coarity ) and s e l f . args−>forAll ( a |
a . type . isSubsortOf ( op . arity−>at ( s e l f . args−>indexOf ( a ) ) ) ) )
-- The sort of boolean conditions is sort (or subsort of) ’Bool’
c o n t e x t BooleanCond i n v :
let boolSort : Sort = Sort . allInstances−>select ( s | s . name = ’Bool’ )
−>first ( ) in s e l f . lhs . type . isSubsortOf ( boolSort )
-- View’s operation mappings’ attributes cannot be specified.
c o n t e x t View i n v :
s e l f . els−>select ( e | e . oclIsTypeOf ( OpTypedMapping ) )−>forAll ( m |
m . atts . oclIsUndefined ( ) )
-- Every module expression must refer to a theory or a module
c o n t e x t ModExpression i n v :
s e l f . getBaseModExps ( )−>forAll ( me | me . oclIsTypeOf ( TheoryIdModExp )
or me . oclIsTypeOf ( ModuleIdModExp ) )
-- Module expressions that refer to modules cannot be composed with those
-- that refer to theories
c o n t e x t CompModExp i n v :
s e l f . getBaseModExps ( )−>forAll ( me | me . oclIsTypeOf ( TheoryIdModExp ) )
or s e l f . getBaseModExps ( )−>forAll ( me | me . oclIsTypeOf ( ModuleIdModExp ) )
-- The source module expression of a view must refer to a theory
c o n t e x t View i n v :
s e l f . from . getBaseModExps ( )−>forAll ( me | me . oclIsTypeOf ( TheoryIdModExp ) )
-- A module parameter must refer to a theory
c o n t e x t Parameter i n v :
s e l f . modExp . getBaseModExps ( )−>forAll ( me | me . oclIsTypeOf ( TheoryIdModExp ) )
These invariants make use of the following OCL auxiliary operations:
c o n t e x t InstModExp : : getBaseModExp ( ) : Bag ( ModExpression )
body : s e l f . modExp . getBaseModExp ( )
c o n t e x t RenModExp : : getBaseModExp ( ) : Bag ( ModExpression )
body : s e l f . modExp . getBaseModExp ( )
c o n t e x t ModuleIdModExp : : getBaseModExp ( ) : Bag ( ModExpression )
body : Bag{ s e l f }
c o n t e x t TheoryIdModExp : : getBaseModExp ( ) : Bag ( ModExpression )
body : Bag{ s e l f }
c o n t e x t CompModExp : : getBaseModExp ( ) : Bag ( ModExpression )
body : s e l f . modExps−>collect ( me | me . getBaseModExp ( ) )−>flatten ( )
55
56
c o n t e x t Kind : : isSubsortOf ( st : Type ) : B o o l e a n
body : ( s e l f = st )
c o n t e x t Sort : : isSubsortOf ( st : Type ) : B o o l e a n
body : ( s e l f = st ) or s e l f . getAllSupersorts ( )−>exists ( s | s = st )
c o n t e x t Sort : : getAllSupersorts ( ) : S e t ( Sort )
body : s e l f . getSupersorts ( )−>union ( s e l f . getSupersorts ( )−>collect ( s |
s . getAllSupersorts ( ) )−>flatten ( ) )
c o n t e x t Sort : : getSupersorts ( ) : S e t ( Sort )
body : s e l f . supersortRels−>collect ( sr | sr . supersorts )−>flatten ( )
4.2.1.2
The Maude Code Generator
We have developed a set of model-to-text transformations, using TCS (see Section 2.1.4.3),
that allow Maude models to be serialized into the corresponding Maude code. The following
is a fragment of these transformations:
1
2
t e m p l a t e FModule :
"fmod" name
( i s D e f i n e d ( params ) ? "{" params{ s e p a r a t o r = "," , autoCreate = never} "}" ) "is"
3
( i s D e f i n e d ( els ) ? [ els{ s e p a r a t o r = "."} "." ] )
4
5
"endfm" ;
6
7
8
t e m p l a t e Sort :
"sort" name ;
9
10
11
t e m p l a t e SubsortRel :
"subsorts" subsorts{ r e f e r s T o = name} "<" supersorts{ r e f e r s T o = name ) ;
12
13
14
t e m p l a t e Operation :
"op" name ":" arity{ r e f e r s T o = name} "->" coarity{ r e f e r s T o = name}
( i s D e f i n e d ( atts ) ? "[" atts "]" ) ;
15
16
...
TCS’s main elements are class templates. Class templates specify how classes are represented, and they are associated to their corresponding metaclass by their names. For instance,
the TCS template Sort corresponds to the class Sort of the Maude metamodel. These templates can be composed of the language keywords, which are specified between double quotes
(such as ”sort” in line 8 in the above excerpt of code), or properties, which corresponds to a
metamodel structural feature (i.e., attribute or reference) of the class associated to the contextual template or one of its super classes (such as name in line 8). Other TCS features include
separator, which defines a character to separate multi-valued properties (line 3), the isDefined
operation, which checks whether a property has been defined or not (line 3), and refersTo to
57
indicate the structural feature that we want to serialize when accessing a reference (line 11).
The complete TCS transformation can be found in our website [2].
4.2.1.3
The Maude Parser
Maude is a very complex language, and defining a parser for it from scratch may result in a
very difficult task. With TCS, it is possible to parse (text-to-model) and pretty-print (modelto-text) DSML sentences. However, there are some properties of the Maude language that
TCS cannot handle, such as synonym keywords (for instance, var and vars are different
keywords in Maude that have the same functionality). Therefore, we have defined a Maude
operation that uses its metalevel capabilities to obtain the corresponding EMF notation of a
Maude model from a Maude term that represent any model, i.e., any term of sort @Model. The
implementation of the operation can be accessed through our e-Motions tool [2]. We are now
working on defining a complete Maude language parser with the new tool Gra2Mol [69].
4.2.2 Encoding EMF Models and Metamodels into Maude
Once we count on a metamodel for Maude, we can define model transformations from other
languages to it. In this section, we show how we provide the Ecore language with semantics by defining a semantic mapping—by means of model transformations—from the Ecore
language to its corresponding MEL specifications in Maude. Since Ecore is a language for
specifying metamodels, what we are doing is to provide a way to formalize metamodels defined in the Eclipse Platform in MEL. Note that our approach does not prevent the user from
defining metamodels using a different language from Ecore, such as KM3, MOF or UML Class
diagrams, since there are already defined model transformations from/to this technical spaces
and Ecore [3]. Furthermore, we also present a general model transformation that transforms
models conforming to metamodels defined using Ecore into its corresponding representation
in Maude. In this way, what we finally get is a formalization of the structural parts of a DSML,
i.e., models and metamodels. The definition of these model transformations allows us to benefit from both platforms: the friendly interface of Eclipse, and the formal basis provided by
Maude.
4.2.2.1
Encoding EMF Metamodels
EMF supports the specification of metamodels through the Ecore language (see Section 2.1.4.1).
The Ecore language is provided with different graphical editors to define metamodels. No mat-
58
ter the editor we choose, the resulting metamodel will be specified as an Ecore model, i.e., as
a model conforming to the Ecore metamodel (see Figure 2.5). In this section, we present an
ATL transformation that we have defined from the Ecore metamodel to the Maude metamodel.
This model transformation provides as a result a Maude model that describes the MEL theory
that represents our metamodel defined using Ecore. This Maude model can then be serialized
into Maude code with our Maude code generator.
In the following, we will introduce some fragments of the aforementioned model transformation. The first fragment correspond to the creation of all Maude elements that will be used
throughout the entire transformation. For this purpose, we make use of module attributes and
an entrypoint rule [3]:
h e l p e r d e f : mSpec : Maude ! Sort = OclUndefined ;
h e l p e r d e f : sModule : Maude ! SModule = OclUndefined ;
h e l p e r d e f : sModuleEcore : Maude ! SModule = OclUndefined ;
h e l p e r d e f : sortClass : Maude ! Sort = OclUndefined ;
h e l p e r d e f : sortPack : Maude ! Sort = OclUndefined ;
...
entrypoint r u l e Initialize ( ) {
to
mSpec : Maude ! MaudeSpec (
els <− S e q u e n c e {sModule , sModuleEcore ,
...
sModule : Maude ! SModule (
name <− thisModule . metamodelName . toUpper ( ) ,
els <− mImport ) ,
mImport : Maude ! ModImportation (
mode <− #protecting ,
imports <− moduleIdModExp ) ,
moduleIdModExp : Maude ! ModuleIdModExp (
” module ” <− sModuleEcore ) ,
sModuleEcore : Maude ! SModule (
name <− ’@ECORE@’ ) ,
sortClass : Maude ! Sort (
name <− ’@Class’ ,
sortPack : Maude ! Sort (
name <− ’@Package’ ,
...
do{
thisModule . mSpec <− mSpec ;
thisModule . sModule <− sModule ;
thisModule . sModuleEcore <− sModuleEcore ;
thisModule . sortClass <− sortClass ;
thisModule . sortPack <− sortPack ;
...
}
}
59
Module attributes can be seen as constants specified within the context of the module (see
the thisModule context needed to refer to them). An entrypoint rule is a rule that is implicitly
invoked at the beginning of the transformation execution. This kind of rule is very useful to
create elements (in its to block) that will be needed throughout the entire transformation. Once
these elements are created, they can be assigned to module attributes in the do block, so that
the elements will be accessible from any point of the transformation. For instance, in this rule
we create the Maude model root element (mSpec), the module in which all the metamodel
specifications will be included (sModule), the @ECORE@ module imported by every metamodel
specification, and several predefined Maude sorts, such as @Class (sortClass) and @Package
(sortPack).
Then, we specify a matched rule for every Ecore element, such as EPackage, EClass or
EAttribute, and we define the corresponding Maude elements that should be generated for each
of them. For instance, the following rule Class2Sort generates a Maude sort, a subsort relation
and a constant per each class EClass element:
1
r u l e Class2Sort{
from
2
class : Ecore ! EClass
3
to
4
sort : Maude ! Sort (
5
name <− class . maudeName ( ) ,
6
” module ” <− thisModule . sModule ) ,
7
ssort : Maude ! SubsortRel (
8
” module ” <− thisModule . sModule ,
9
supersorts <− if class . eSuperTypes . isEmpty ( )
10
then thisModule . sortClass
11
else class . eSuperTypes endif
12
subsorts <− Set{sort } ) ,
13
cte : Maude ! Operation (
14
name <− class . maudeName ( ) ,
15
16
17
coarity <− sort )
do{
18
19
thisModule . EqName ( class ) ;
20
thisModule . ClassEqIsAbstract ( class ) ;
21
thisModule . EqPackage ( class ) ;
22
thisModule . ClassEqSuperTypes ( class ) ;
23
thisModule . ClassEqReferences ( class ) ;
24
thisModule . ClassEqAttributes ( class ) ;
}
25
26
27
}
...
The sort and the constant (cte) are named after the class; the subsort relation (ssort) is
specified from this sort to the sorts that represent their superclasses (if applicable, otherwise
60
it will be a subsort of the predefined sort @Class); and the type of cte is sort (i.e., its coarity
refers to sort). These three elements will be contained in the Maude module that represent the
metamodel (thisModule.sModule, see lines 7, 9 and 16). Constants are represented in Maude
as operations with no arguments (i.e., operations with an undefined arity). The maudeName
helper obtains the name given to an Ecore element in Maude by qualifying it with their containers’ names (see Section 4.1.1).
Note that elements of the source model could not be assigned directly to elements of the
target model; for instance, you could not assign a set of EClasses (the eSuperTypes reference,
see line 12) to a set of Maude sorts (the supersorts reference, see line 10). When we try to do
this, ATL does not assign the corresponding source model but the first element placed in the to
block of the rule that this source element matches. Thus, lines 10 to 12 will assign, for each
superclass of class, the corresponding sort element created by another match of this same rule
(Class2Sort).
The do block specifies the creation of all the Maude equations that will gather each property
of the class (see Section 4.1.1). These equations will be created by means of called rules. A
called rule is a special kind of rule that enables the generation of target elements from imperative code [3]. For instance, the following called rule EqName generates the Maude equation
that encodes the name of any ENamedElement (the Ecore class from which the remaining
Ecore classes inherits from):
r u l e EqName ( namedElement : Ecore ! ENamedElement ) {
to
eqName : Maude ! Equation (
lhs <− lhsEqName ,
rhs <− rhsEqName ) ,
lhsEqName : Maude ! RecTerm (
op <− ’name’ ,
type <− thisModule . sortString ,
args <− cteName ) ,
cteName : Maude ! Constant (
op <− namedElement . maudeName ( ) ,
type <− namedElement . maudeSort ( ) ) ,
rhsEqName : Maude ! Constant (
op <− namedElement . normalizedName ( ) ,
type <− thisModule . sortString )
}
The Maude equation is composed of a left-hand side lhsEqName and a right-hand side
rhsEqName. lhsEqName represents the application of the operation name over the constant
cteName that refers to the namedElement, and rhsEqName is the string constant that gathers
61
its name. The normalizedName helper adds double quotes to the string constant and replaces
special characters used in our Maude infrastructure.
4.2.2.2
Encoding EMF Models
Once we have defined a model transformation from metamodels defined with EMF to a MEL
theory in Maude, the following step is to transform models that conform onto these metamodels
to the same semantic domain. For this purpose, we have defined a general model transformation
that transforms models conforming to metamodels defined using Ecore into their corresponding
representation in Maude. This general model transformation makes use of the EMF EObject
interface and all its meta-capabilities, i.e., all the operations that allow us to obtain metamodel
properties from a model conforming to it (see Figure 4.2). Since all the objects specified in
EMF implement the EObject interface, we can define a model transformation independently of
the source metamodel by defining it in terms of EObject.
Figure 4.2: The EObject interface.
The following ATL code is an excerpt of this model transformation:
62
1
h e l p e r d e f : objectOperator : S t r i n g = ’<_:_|_>’ ;
2
h e l p e r d e f : setOperator : S t r i n g = ’_‘,_’ ;
3
h e l p e r d e f : objectSort : Maude ! Sort = OclUndefined ;
4
h e l p e r d e f : objSet : Maude ! RecTerm = OclUndefined ;
5
h e l p e r d e f : sfiSetSort : Maude ! Sort = OclUndefined ;
6
h e l p e r context OclAny d e f : atts ( ) : S e q u e n c e ( Ecore ! EAttribute ) =
self . eClass ( ) . eAllAttributes ;
7
8
h e l p e r context OclAny d e f : refs ( ) : S e q u e n c e ( Ecore ! EReference ) =
self . eClass ( ) . eAllReferences ;
9
10
...
11
12
entrypoint r u l e Initialize ( ) {
to
13
...
14
objSet : Maude ! RecTerm (
15
op <− thisModule . objSetOperator ,
16
type <− objectSetSort ,
17
...) ,
objectSort : Maude ! Sort (
18
name <− ’@Object’ ,
19
” module ” <− auxiliaryModule ) ,
20
sfiSetSort : Maude ! Sort (
21
name <− ’Set{@StructuralFeatureInstance}’ ,
22
” module ” <− auxiliaryModule ) ,
23
...
24
do{
25
26
thisModule . objSet <− objSet ;
27
thisModule . objectSort <− objectSort ;
28
thisModule . sfiSetSort <− sfiSetSort ;
...
29
}
30
31
}
32
33
34
r u l e Object{
from
o : Ecore ! EObject
35
36
37
to
obj : Maude ! RecTerm (
38
op <− thisModule . objectOperator ,
39
type <− thisModule . objectSort ,
40
41
42
43
44
args <− S e q u e n c e {thisModule . MaudeOid ( o ) , class , sfs } ) ,
class : Maude ! Constant (
op <− o . eClass ( ) . maudeClassifierName ( ) ,
type <− thisModule . MaudeClassSort ( o . eClass ( ) ) ) ,
sfs : Maude ! RecTerm (
45
op <− thisModule . setOperator ,
46
type <− thisModule . sfiSetSort ,
47
args <− o . atts ( )−>collect ( a | thisModule . MaudeAttributeInstance ( o , a ) )
48
49
50
51
−>union ( o . refs ( )−>collect ( r | thisModule . MaudeReferenceInstance ( o , r ) ) )
−>union ( S e q u e n c e {emptySfs1 , emptySfs2 } ) ) ,
emptySfs1 : Maude ! Constant (
op <− thisModule . emptySetOperator ,
4.3. R ELATED W ORK
type <− thisModule . sfiSetSort ) ,
52
emptySfs2 : Maude ! Constant (
53
op <− thisModule . emptySetOperator ,
54
type <− thisModule . sfiSetSort )
55
do{
56
thisModule . objSet . args <− thisModule . objSet . args−>append ( obj ) ;
57
}
58
59
60
63
}
...
The Object rule transforms any object defined in EMF to their corresponding Maude representation. As we mentioned in Section 4.1.2, we represent a Maude object (obj) as a term
< : | > of sort @Object whose arguments are its identifier, its class, and its structural feature-
value pairs (sfs). The object identifier is defined depending on the position of the object in the
tree of the EMF model. It is generated by means of the MaudeOid lazy rule. A lazy rule is a
kind of rule that needs to be explicitly invoked from declarative code [3]. The class element
is the Maude constant that represents the object’s class. This constant is an invocation of the
corresponding cte operation created in the Class2Sort rule (see above). The structural featurevalue pairs constitute a set of structural feature instances, i.e., a term which name is , , its sort
is Set@StructuralFeatureInstance, and whose elements are defined with the MaudeAttributeInstance and MaudeReferenceInstance lazy rules. These rules perform like the Object
rule but acting on attributes and references; they use the operation eGet (see Figure 4.2) to get
the value of all the references and attributes of the object’s class (see the atts and refs helpers in
lines 6 to 9). The emptySfs1 and emptySfs1 constants represent two instances of the identity
element of the set operator. They are included in the arguments of sfs in order to make it valid
in the case the object has no attributes (and references) or just has one, since the set operator ,
needs two or more arguments (it is declared associative [42]). Finally, in the do block, we add
the Maude object obj to the set of objects that represents the whole model (thisModule.objSet).
4.3 Related Work
There are some works that propose different formalisms to represent models, metamodels and
their behavior. In this section we will introduce those that focus on the structural parts of a
DSML, i.e., on models and metamodels. Those that includes behavioral specifications (such as
graph transformation) will be discussed in Chap. 6.
Batory [17] describes a set of concepts on which MDE, Software Product Lines (SPL), and
Computation Design (CD) are founded. In particular, he shows how MDE and SPL ideas map
64
to categorical concepts, and he explains the benefits in making a connection (at a theoretical
level).
Poernomo [95] uses Constructive Type Theory (CTT) and a related synthesis formal method
known as proofs-as-programs to formalize MOF-based metamodels and model transformations, and to develop model transformations that are provably correct with respect to a given
functional specification (by making use of a theorem prover). Models are defined as terms
(token models), that can also be represented as types (type models) by means of a reflection
mechanism. Models, metamodels and model transformation are specified directly in the logic
that is built into CTT, i.e., the author do not provide any intuitive front-end from which transform these specification into the CTT formalism.
Boronat and Meseguer [25] propose an algebraic semantics in MEL for the MOF metamodeling framework, giving an explicit formal representation for each of the different notions
that may be involved in a metamodeling framework: model type, metamodel realization, and
metamodel conformance. Their encoding of models and metamodels shares many similarities
with our previous representation [110]. We abandoned this representation for the reasons that
we presented in Section 4.1.1, mainly to (a) include more metamodel-related properties (that
can be accessible from the model level), and (b) avoid accessing Maude’s metalevel when dealing with common tasks (something that degrades performance when dealing with large models). They have defined the Algebraic MOF Framework [5], a reflective, algebraic, executable
framework for metamodeling that provides support for the MOF and the OCL standards. This
framework provides an executable environment that is plugged into EMF and that constitutes
the kernel of a model management framework (see Section 5.5). Contrary to our approach,
they do not follow a full MDE process to define the semantic mappings: they directly serialize
EMF models into Maude instead of defining a Maude metamodel and model transformation
between both platforms.
Other works also try to formalize the concepts of concrete metamodeling languages, such
as UML or OCL. There is a great number of contributions trying to attribute a rigorous meaning
to specific (or a small set of) UML diagrams, especially UML class diagrams, by translating
them into a language with well-defined semantics. For instance, in [72] UML class diagrams
are formalized into the Object Z language; in [96] a more general schema of the semantics of
UML is presented by using the algebraic language Casl-LTL, where the modeling of behavior
is handled by means of labeled transition sytems; in [75] UML diagrams are formalized in
terms of state predicates to check their consistency with the theorem prover PVS (Prototype
Verification System); in [28], a modeling technique based on UML is provided with semantics
4.3. R ELATED W ORK
65
by using the Mathematical System Model (MSM); and in [36] the authors propose to formalize
each UML diagram with an appropriate institution and the relationship between them by an
institution comorphism.
Other works which can be considered more closely related to ours are those that formalize these concrete metamodeling languages into Maude. For instance, Toval-Álvarez and
Fernández-Alemán propose in [120] an algebraic formalization of UML that supports the UML
extension mechanism. The approach is in accordance with the four-layer metamodeling architecture on which the UML definition is based. In this work the authors focus on UML Class
diagrams. RIVIERA [114] is a framework for the verification and simulation of UML class
diagrams and statecharts. It is based on the representation of class and state models as terms in
Maude modules that specify the UML metamodel. MOVA [12] is another Maude-based modeling framework for UML, which provides support for OCL constraint validation, OCL query
evaluation, and OCL-based metrication. In MOVA, both UML class and object diagrams are
formalized as MEL theories. Note that these approaches define models in a fixed formalism
(mainly UML) directly instead of explicitly discussing the metamodel definition too.
The aforementioned approaches that make use of Maude (i.e., [120], RIVIERA, MOVA
and MOMENT) have a different model representation. In fact, Maude offers several options
to represent and manipulate object-oriented systems, depending on the way in which objects,
attributes and references are represented; whether reflection is used or not, etc. For instance,
in [120] the authors exploit the reflective capabilities of Full Maude to formalize the four-layer
metamodel architecture of UML, and in MOMENT attribute-value pairs are constructed in
such a way that an attribute value cannot be accessed independently of its attribute name (a
pretty common task when defining metamodel-independent operations) with a simple match—
the reflective capabilities of Maude would be needed for that purpose. Using the reflective
capabilities of Maude have several drawbacks: it increases the complexity of the specifications,
makes them much more difficult to write and to maintain, and also has a significant impact on
performance. This is the reason why we changed the representation we used in our initial
proposals [104, 110] to improve the efficiency of the operations and of the analysis tools.
66
Chapter 5
Model Management
Once we have described how models and metamodels can be represented in Maude, this chapter
shows how some of the basic operations on models—namely model subtyping, model difference, and metric evaluation—can be then specified. We will see 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 two transformations presented in last chapter (from EMF to Maude),
allow Eclipse users to use the defined model operations without being aware of Maude at all.
5.1 Model Subtyping
With the increasing adoption of MDE, there are more and more model operations that are being
defined: model transformation, metrics, composition, etc. Generally, the specification of these
operations depends on the metamodels to which the operand models conform. Thus, it would
be interesting to define another operation, model subtyping, that tries to maximize the reuse of
these already defined operations [103].
In this section, we introduce a definition of model subtyping that guarantees type safety and
introduce polimorfism in MDE. In particular, we distinguish four different kinds of subtyping
depending on the relaxation of the relationships between the operand metamodels: strict subtyping, subtyping with renaming, flattened subtyping and flattened subtyping with renaming.
67
68
C HAPTER 5. M ODEL M ANAGEMENT
5.1.1 Motivation
Model typing is a critical issue for MDE, specially for describing the input and output parameters of model operations and services. For instance, model transformations are defined in terms
of the metamodels of their input and output models, and therefore we need to know whether a
given model (conforming to a metamodel) is a valid input for that transformation. This situation is even more justified in the case of initiatives such as the Model Bus [22], which allows
modeling services to be connected. For connecting them, it is essential to check the type substitutability between the output of a service and the input of another, in such a way that type
safety is guaranteed.
Another situation which requires type checking happens when looking for metamodels in a
given repository (this is called metamodel matchmaking, a key mechanism for enabling reuse).
For instance, suppose that you want to work with state machines, and want to know if there are
already metamodels in a repository that deal with them. The easiest way to proceed would be
to provide a very simple initial metamodel and then look for subtypes of such a metamodel.
Finally, metamodels, as every software artifact, evolve with time in every phase of its life
cycle. Another interesting use of the subtyping operation would be to know which kind of
metamodel modifications will invalid (or not) the operations already defined over a metamodel.
5.1.2 Subtyping Algorithm
Despite being a core concept, a definition of the term model type is not widely agreed by the
MDE community yet. However, due to the similarities between the structures used in MDE
(as defined by MOF) and in object-oriented paradigms, its reasonable to expect that theories
developed for type systems of object-oriented languages will apply or adapt well for models.
In [116] and [117], Steel and Jézéquel extended the notion of object subtyping to the realm
of models, providing an algorithm for model subtyping (i.e., safe replaceability). This algorithm tries to be generic, and provides an elegant approach to address the problem of model type
conformance, i.e., to check whether a required model type may be satisfied by a provided model
type. In this thesis, we adapt their algorithm to the Ecore structure (see Figure 2.5), i.e., we
consider a metamodel as a model type. We selected this choice for practical reasons: (a) a metamodel considers the MDE metalevel hierarchy; (b) there are many languages and operations
defined for them that we can make use of; and (c) they are used in model transformation—the
model operation par excellence—to describe the input and output parameters type.
5.1. M ODEL S UBTYPING
69
Definition. Given two model types M and M′ (i.e., two metamodels), we say that M′ is subtype
of M (M′ ≤ M) whenever we can ensure that if we substitute M by M′ , the operations defined
over M are also applicable to M′ , guaranteing type safety.
When M and M′ are defined with the Ecore language (see Figure 2.5), this gives place to the
following definitions:
• Metamodel M′ is subtype of metamodel M (M′ ≤ M) iff:
∀(EPackage)P ∈ M • ∃(EPackage)P′ ∈ M′ • (P′ ≤ P)
• EPackage P′ is subtype of EPackage P (P′ ≤ P) iff:
isRelated(P′ .name, P.name)∧
∀ C ∈ P.eClassifiers • ∃ C′ ∈ P′ .eClassifiers • (C′ ≤ C)
• EClass C′ is a subtype of EClass C (C′ ≤ C) iff:
isRelated(C′ .name, C.name) ∧ (C′ .abstract → C.abstract)∧
∀ SC ∈ C.eSuperTypes • ∃ SC′ ∈ C′ .eSuperTypes • (SC′ ≤ SC)∧
∀ SF ∈ C.eStructuralFeatures • ∃ SF′ ∈ C′ .eStructuralFeatures • (SF′ ≤ SF)
• EDataType D′ is a subtype of EDataType D (D′ ≤ D) iff:
if (D.oclIsTypeOf (EEnum) ∧ D′ .oclIsTypeOf (EEnum))
then (E.eLiterals ⊆ E′ .eLiterals)
otherwise (not D.oclIsTypeOf (EEnum) ∧ not D′ .oclIsTypeOf (EEnum))∧
((D′ = D) ∨ ((D′ .name = EDouble) ∧ (D.name = EInt)))
• EAttribute A′ is subtype of EAttribute A (A′ ≤ A) iff:
isRelated(A′ .name, A.name) ∧ (A′ .eType ≤ A.eType) ∧ (A′ .unique = A.unique)∧
((A.upperBound = A′ .upperBound) ∨ (2 ≤ A.upperBound ≤ A′ .upperBound))∧
(A.lowerBound ≤ A′ .lowerBound) ∧ (A′ .ordered = A.ordered)
• EReference R′ is a subtype of EReference R (R′ ≤ R) iff:
isRelated(R′ .name, R.name) ∧ (R′ .eType ≤ R.eType) ∧ (R′ .unique = R.unique)∧
70
((R.upperBound = R′ .upperBound) ∨ (2 ≤ R.upperBound ≤ R′ .upperBound))∧
(R.lowerBound ≤ R′ .lowerBound) ∧ (R′ .ordered = R.ordered)∧
(R′ .eOpposite ≤ R.eOpposite)
The subtyping algorithm establishes the relationship that must exist between the elements
of two different metamodels (M′ and M) to ensure that the operations defined over M to be
also applicable to M′ . We consider every metamodel element property reflected in the Ecore
metamodel except those that refer to Java properties, which are not inherent to a model type
description but specific to the EMF capability of generating Java code from the metamodel
specification. Initially, we assume the isRelated operation defined as the equality relationship
(see Section 5.1.2.1).
Let us illustrate the above definition with an example. We will retake the ATL transformation presented in Section 2.1.4.4, and consider this model transformation as an example of
model operation applied over the Author metamodel. Recall that, in this metamodel, authors
have a single name and a single surname.
module Author2Person ;
c r e a t e OUT : MMPerson from IN : MMAuthor ;
r u l e Author {
from
a : MMAuthor ! Author
to
p : MMPerson ! Person (
name <− a . name ,
surname <− a . surname )
}
Now, suppose that we create a new metamodel Author2 on which we consider that an
author can have two surnames, i.e., we set the upper bound value of the surname attribute
to two. Would this model operation be applicable to the new metamodel? According to the
above definition, the Author2 metamodel is not subtype of the Author metamodel, so we cannot
ensure that the transformation will be applicable to the Author2 metamodel. In fact, if we
define a model conforming to this new metamodel with an author whose name is Jose and
whose surnames are Rivera and Cabaleiro, and we run the transformation, what we get is an
ATL error, because we are trying to assign a collection of strings (a.surname) to a single string
(p.surname).
Since a structural feature is usually accessed differently when its value is a single element
and a collection of them, we include in our subtyping algorithm cardinality restrictions to
71
distinguish both cases. For the same reason, we force ordered and unique properties to be equal
(note that operations defined over sequences are not the same that those defined over sets, for
instance). However, there are other properties, such as containment, that do not usually affect
to the way an element is accessed in a model operation, and therefore we do not include any
restriction about it in our algorithm.
Regarding data types, we consider the Ecore EString, EBoolean, EInt and EDouble data
types. The operations defined over integer numbers (except the modulo operation) are also
defined over the sort EDouble, and this is why we consider that EDouble ≤ EInt. Note that
our context is replaceability or substitution in the application of operations, and therefore, the
direction of our subtyping relationship ≤ is opposite to the normal direction (EInt ≤ EDouble).
The presented subtyping algorithm is also useful in the context of metamodel evolution. It
allows us to know what kind of metamodel modifications will invalidate (or not) the operations
defined over a metamodel. For instance, we know that any element (package, class, reference,
attribute, etc.) can be added to a metamodel and the operations defined over it will remain
applicable. On the contrary, we cannot delete a metamodel element, since this action will
usually invalidate the operation. Regarding modifications of elements, we have to perform
them in such a way that the restrictions specified in the algorithm remain fulfilled.
5.1.2.1
Kinds of Subtyping
The above subtyping algorithm guarantees that, whenever a metamodel M′ is subtype of another metamodel M, we can substitute M by M′ and the operations defined over M will be
directly applicable over M′ , i.e., we do not need to perform any modification to the operations
to apply them over M′ . For this purpose, we assume the isRelated operation defined as the
equality relationship, i.e., we force subtype elements to have the same name as their supertypes. This kind of subtyping is called strict subtyping.
However, there are cases in which two elements may represent the same element but they
have different names: think for instance on spelling mistakes, upper and lower cased differences, or synonyms. Thus, we have also identified another kind of subtyping, subtyping with
renaming, that implements the isRelated operation by means of a model that links words that
are synonyms, or by defining an operation to compute the distance between two strings. Note
that by forcing a relationship between the element names we promote class identity conservation. Specifically, we have implemented the Levenshtein distance [76], a metric that represents
the minimum number of operations needed to transform one string into the other, where an op-
72
eration is an insertion, deletion, or substitution of a single character. If the Levenshtein distance
is lower than a fixed bound, two names can be considered to be related.
Another issue related to the subtyping algorithm is the metamodel package structure, which
can be considered not relevant to what a model type refers to. In fact, Steel and Jézéquel [116]
consider a model type as the set of object types for all the objects contained in a model, i.e.,
they basically consider as model type a metamodel without its package structure. To cover
this case, we have identified two additional kinds of subtyping, namely flattened subtyping
and flattened subtyping with renaming. These kinds of subtyping are unaware of the package
structure, i.e., they do not consider metamodel packages in their calculations: they compare
classifiers independently of the package they belong to. The latter, flattened subtyping with
renaming, also allows related elements to have different names.
Finally, note that when the subtype relationship is relaxed by using one of the alternative
types: subtyping with renaming, flattened subtyping or flattened subtyping with renaming, we
will usually need to adapt the model operations to make them applicable to the new metamodel
M′ . We believe that this adaptation can be automatically generated by means of a model
transformation that renames the affected elements (in case of subtyping with renaming) or
modifies the classifiers package if an ambiguity is possible (in case of flattened subtyping).
5.1.3 The Subtyping Operation in Maude
One of the benefits of using Maude for representing models and metamodels is that this subtyping algorithm can be easily implemented. In fact, the above clauses can be naturally specified in
Maude using its equational logic capabilities. For instance, given M and M’ Ecore models (i.e.,
models that represent metamodels defined using Ecore), and operations arePackagesSubtypeOf
and areClassifiersSubtypeOf described below, the following Maude specifications define the four kinds of subtyping:
v a r s M M ’ : @Model .
var RENTYPE : String .
op isStrictSubtypeOf : @Model @Model −> Bool .
eq isStrictSubtypeOf ( M ’ , M )
= arePackagesSubtypeOf ( allPackages ( M ’ ) , allPackages ( M ) , "Equal" , M ’ , M ) .
op isRenSubtypeOf : @Model @Model String ˜> Bool .
eq isRenSubtypeOf ( M ’ , M , RENTYPE )
= arePackagesSubtypeOf ( allPackages ( M ’ ) , allPackages ( M ) , RENTYPE , M ’ , M ) .
op isFlatSubtypeOf : @Model @Model −> Bool .
73
eq isFlatSubtypeOf ( M ’ , M )
= areClassifiersSubtypeOf ( allClassifiers ( M ’ ) , allClassifiers ( M ) , "Equal" , M ’ , M ) .
op isFlatRenSubtypeOf : @Model @Model String ˜> Bool .
eq isFlatRenSubtypeOf ( M ’ , M , RENTYPE )
= areClassifiersSubtypeOf ( allClassifiers ( M ’ ) , allClassifiers ( M ) , RENTYPE , M ’ , M ) .
Note that the isStrictSubtypeOf and isRenSubtypeOf operations start traversing
all packages, while the isFlatSubtypeOf and isFlatRenSubtypeOf operations handle
classifiers directly, independently of the package they belong to. On the other hand, the
isStrictSubtypeOf and isFlatSubtypeOf operations force the relationship between the
names of the metamodel elements to be the equality relation ("Equal" as their third argument), while the isRenSubtypeOf and isFlatRenSubtypeOf operations admit a parameter
to specify the kind of relationship to be used on these names. Currently, only the Levenshtein
distance is available, and it is defined with a maximal distance of two units.
The auxiliary operation arePackagesSubtypeOf traverses all the packages in M to check
if, for every package P in M, there exists a package P’ in M’ which is a subtype of P, i.e., their
names are related, and their corresponding classifiers are also subtypes.
v a r s MM MM ’ : @Metamodel .
v a r s PACKS PACKS ’ : Set .
v a r s CLASSFS CLASSFS ’ : OrderedSet .
v a r s LPACKS LPACKS ’ : MSet{OCL−Exp} .
v a r s N N ’ STRCOMP : String .
v a r s P P ’ : Oid .
v a r s OBJSET OBJSET ’ : Set{@Object} .
op arePackagesSubtypeOf : Set Set String @Model @Model ˜> Bool .
eq arePackagesSubtypeOf ( PACKS ’ , Set{mt } , STRCOMP , M ’ , M ) = true .
ceq arePackagesSubtypeOf ( Set{P ’ ; LPACKS ’ } , Set{P ; LPACKS } , STRCOMP ,
MM ’ { OBJSET ’ } ,
MM { OBJSET } )
= true
if
isRelated ( N ’ , N , STRCOMP )
/ \ areClassifiersSubtypeOf ( CLASSFS ’ , CLASSFS , STRCOMP , MM ’ { . . . } , MM { . . . } )
/ \ arePackagesSubtypeOf ( Set{P ’ ; LPACKS ’ } , Set{LPACKS } , STRCOMP , MM ’ { . . . } , MM { . . . } )
eq arePackagesSubtypeOf ( PACKS ’ , PACKS , STRCOMP , M ’ , M ) = false [ owise ] .
The remaining subtype operations are implemented in a similar way: Maude equations are
used to specify the subtyping algorithm until reaching the most primitive metamodel elements,
i.e., the structural features (attributes and references).
With these operations, checking, e.g., whether a metamodel M′ is strict subtype of another
metamodel M (M′ ≤ M), i.e., M can be directly replaced by M′ , is just a matter of reducing the
74
term isStrictSubtypeOf(M’, M), where both M and M’ are expressed as (Ecore) @Model
terms.
Maude> r e d u c e isStrictSubtypeOf ( M ’ , M ) .
5.2 Model Difference
Model difference is an essential operation in several software development processes [38], including version and change management, software evolution, model/data integration, etc. Most
of the current techniques for visualizing and representing model differences are mainly based
on edit scripts and coloring techniques [14, 81, 88]. These approaches do not produce models as results of their calculations, and therefore cannot be fully integrated within other MDE
processes. Furthermore, most of them do not fulfill other interesting properties required in
MDE environments, such as composability [29]. Other techniques based on text, data structure or models also exist, but are usually restricted to a specific metamodel (namely UML)
[14, 87, 127].
In this section we present an approach to compare models which conform to arbitrary metamodels. For this purpose we have defined a Difference Metamodel so that differences are represented as models, too, that conform to such a metamodel. We have also defined a set of
operations on models and on differences that provide support for the calculation of differences,
their application and composition.
5.2.1 Representing Differences
Our first requirement is that the results of a model difference operation can be expressed as
a model, so they can be fully integrated into other MDE processes. Since models conform to
metamodels, we have to define a Difference metamodel with the elements that a difference may
contain, and the relationships between them. Furthermore, this Difference metamodel should
be general enough to be independent of the metamodel of the source models.
Taking into account these requirements, we have developed the Difference metamodel depicted in Figure 5.1. A difference model will contain all the changes from a subtrahend model
to a minuend model. As usual, we can distinguish three different kinds of changes: element addition, element deletion, and element modification. Thus, every element of a difference model
(DiffElement) will belong to the ModifiedElement metaclass, the DeletedElement metaclass, or
5.2. M ODEL D IFFERENCE
75
Figure 5.1: The Difference metamodel.
the AddedElement metaclass, depending on whether the element has been added, deleted or
modified, respectively. Elements which do not suffer from any changes will not be reflected in
the difference model.
Every difference element DiffElement will have a reference (element) to the element that
has suffered the change. In case of element modification (ModifiedElement), the difference element will refer to both the element of the minuend model (after the modification, element) and
the element of the subtrahend model (before the modification, oldElement). Modified, deleted
and added elements from both operand models are added to the difference model too, so that
it is self-contained [29], that is, the difference model will contain all the changes, not relying
on external sources of information (such as the operand models). Since these elements can
belong to any metaclass—model difference can be applied to models conforming to arbitrary
metamodels—we make use of the (Ecore) EObject metaclass, which all metaclasses inherits
from.
The Difference Metamodel can be specified in Maude, following the conventions explained
in Section 4.1.1, as follows:
mod @DIFFERENCE@ i s
p r o t e c t i n g @ECORE@ .
op @Difference@ : −> @Metamodel .
op Difference : −> @Package .
s o r t DiffElement .
s u b s o r t DiffElement < @Class .
op DiffElement : −> DiffElement .
op element : −> @Reference .
s o r t AddedElement .
s u b s o r t AddedElement < DiffElement .
op AddedElement : −> AddedElement .
s o r t DeletedElement .
s u b s o r t DeletedElement < DiffElement .
76
op DeletedElement : −> DeletedElement .
s o r t ModifiedElement .
s u b s o r t ModifiedElement < DiffElement .
op ModifiedElement : −> ModifiedElement .
op oldElement : −> @Reference .
--- METAMODEL PROPERTIES
--- Equations for the "@Diference@" metamodel
op @Difference@ : −> @Metamodel .
eq name ( @Difference@ ) = "Difference" .
eq packages ( @Difference@ ) = Difference .
...
--- Equations for the "DiffElement" class
eq name ( DiffElement ) = "DiffElement" .
eq isAbstract ( DiffElement ) = true .
eq package ( DiffElement ) = Difference .
eq superTypes ( DiffElement ) = nil .
eq references ( DiffElement ) =
element .
eq attributes ( DiffElement ) = nil .
--- Equations for the "element" reference
eq name ( element ) = "element" .
eq type ( element ) = EObject .
eq opposite ( element ) = null .
eq lowerBound ( element ) = 1 .
eq upperBound ( element ) = 1 .
eq containingClass ( element ) = DiffElement .
eq isContainment ( element ) = true .
...
endm
The EObject class (as every Ecore element) is defined in the @ECORE@ module (see Appendix B).
5.2.2 The Difference Operation
Given a minuend model Mm and a subtrahend model Ms , both conforming to some metamodels
(not necessary the same), the result of applying the model difference operation to them is
another model Md conforming to the Difference Metamodel presented above, in such a way
that modelDiff(Mm ,Ms ) = Md .
The global comparison process is generally admitted as being composed of two main parts:
matching and differencing [29]. The latter makes use of the former to decide whether an
element in the minuend model is the same (although possibly modified) as another in the subtrahend model. Decomposing the difference operation in these two parts allows the reuse of
77
both algorithms in different applications, such as, e.g., model patching [29]. Thus, we will
firstly show how elements are matched, and secondly how the difference is computed using
this information.
5.2.2.1
Matching Elements
Matching two models M1 and M2 conforming to some (not necessarily the same) metamodels
means finding different objects from both models that represent the same elements. The result
of applying the match operation to M1 and M2 is a match model MM that conforms to the
Match Metamodel, depicted in Figure 5.2.
Figure 5.2: The Match Metamodel.
Match model elements (of class Match) symbolize links between two objects that represent
the same elements. Thus, a match model element will refer to both objects (leftEl and rightEl)
and will rate their similarity (expressed in terms of a ratio between zero and one).
In this work, we will consider two different types of model matching: identifier-based
matching and structural matching.
Matching objects using persistent identifiers.
Since Maude objects have persistent iden-
tifiers, and there cannot be two objects with the same identifier in the same model, checking
whether two objects represent the same element can be easily accomplished by comparing their
identifiers. If their identifiers are the same, the two objects can be said to represent the same
element; otherwise, the two objects represent different elements.
The idMatch operation can be specified in Maude as follows:
v a r s MM MM ’ : @Metamodel .
v a r s OBJSET OBJSET ’ : Set{@Object} .
v a r s O O ’ : Oid .
v a r s C C ’ : @Class .
op idMatch : @Model @Model −> @Model .
eq idMatch ( MM { OBJSET } , MM ’ { OBJSET ’ } ) = @Match@ { idMatch ( OBJSET , OBJSET ’ ) } .
op idMatch : Set{@Object} Set{@Object} −> Set{@Object} .
eq idMatch(< O : C | SFS > OBJSET , < O : C ’ | SFS ’ > OBJSET ’ )
78
= < O : Match | leftEl : O # rightEl : O # rate : 1 . 0 ) >
idMatch ( OBJSET , OBJSET ’ ) .
eq idMatch ( OBJSET , OBJSET ’ ) = none [ owise ] .
For every object of M1 with the same identifier as another object of M2 , a match object that
relates them is added to the resulting model. Since [owise] equations are only executed if no
other equation holds, when no objects with the same identifier are found nothing else is added
to the match model. Note that the union operator for sets of objects is declared associative,
commutative, and with identity element none (see Appendix A), and therefore the sets of
objects are matched modulo these axioms.
Matching objects using structural similarities.
Using persistent universal identifiers makes
the matching process simple and robust. However, counting on this kind of identifiers is not always possible: if the two models to compare conform to different metamodels, or have evolved
independently, there is little chance that an element being the “same” in the two models has
the same identifier. In addition, when comparing models not originally specified in Maude
but, e.g., in MOF or Ecore, we cannot assume that the model transformations from MOF or
Ecore to Maude will assign the same identifier to two different objects that represent the same
element.
A more sophisticated matching algorithm is therefore needed. This kind of matching algorithm should compare two elements by their structural similarities. There are several structural
matching algorithms described in the literature that can be used (see, e.g., [119, 77]). One of
the advantages of using Maude is that its powerful matching facilities enables the specification
of this kind of algorithms at a very high level of abstraction.
We have implemented a structural matching algorithm in our Maudeling framework (see
Section 5.4). The algorithm, which was published in [105], starts by comparing every object of
a model with every object of the other one. Comparing two objects means obtaining a match
rate that represents their similarity. In case two objects are identified by the same attribute (i.e.,
their corresponding metaclass have the same attribute set as identifier), this rate is computed
by comparing them, otherwise the rate will be computed by comparing their metaclasses and
structural features. Then, two objects are said to potentially match when the rate is greater than
a given threshold (Th). At the end of the process, a sieve is applied to all potential matches in
order to pair only those objects that together obtain the biggest rate, taking into account that a
specific object can only belong to one match relationship.
In case two objects cannot be compared by their identifier attributes, class and structural
79
features match rates are obtained in the following way:
• Two metaclasses match if they are the same, or there exists an inheritance relation between them.


1.0 if C1 = C2



classRate(C1 , C2 ) =




0.9 if isSubtype(C1 , C2 ) or isSubtype(C2 , C1 )
0.0 otherwise
• Structural features are compared taking into account their names and types. The structural feature rate sfRate is computed by comparing each single structural feature and
assigning a weight to them—boolean attributes have a weight lower than structural features of other types. If a structural feature is defined only in one of the objects (i.e., a
structural feature with the same name and type cannot be found in the other object), a
penalty is applied to the final sfRate. If a structural feature’s upper cardinality is greater
than 1 (i.e., if its value is a collection), the average rate is calculated.
– Boolean attributes and enumerations match (with rate = 1.0) if they have the same
value (otherwise rate = 0.0).
– String attribute values distances are calculated using the Levenshtein algorithm.
Depending on the resulting distance, a different rate is given.



1.0 if levenshteinDist(S1 , S2 ) = 0









nameRate(S1 , S2 ) = 0.5 if levenshteinDist(S1 , S2 ) = 2










0.0 otherwise
– Numerical attribute values match rate is computed with a relative distance function
(1 −
|N1 −N2 |
|N1 +N2 |
limited to [0..1])
– References are matched recursively, i.e., objects referenced are compared using the
same match operation but without taking into account their own references (to avoid
cycles).
Once the class and structural features match rates are calculated, the final joint rate is
obtained as follows:
80
finalRate = wc ∗ classRate + wsf ∗ sfRate
where finalRate, classRate, sfRate ∈ [0..1], and the weights that we have initially considered
are wc = 0.66, wsf = 0.34. The threshold value we normally use is Th = 0.88, although the
weights and threshold are of course user-defined and easily configurable. It is worth noting that
the weights and threshold values specified above do not allow elements to potentially match if
their metaclasses are not related, since in that case the finalRate could not be greater than wsf
(and wsf is lower than the threshold Th).
In case two objects have the same identifier attribute, they will be compared just by them,
i.e., finalRate = idRate. This comparison will be computed depending on the type of the
attribute (boolean, string or numerical) by using one of the above equations. In these cases, we
normally use the same threshold Th = 0.88.
Contrary to other approaches (e.g., [119]) in which a model is seen as a tree (levels are determined by the containment relationship), and only objects at the same level are compared, our
approach compares every object independently of its depth in the tree. This decision implies
more comparisons, but also brings along interesting advantages: (a) moved elements through
different levels can be detected; and (b) failing to identify a match does not condition other
potential matches below in the tree hierarchy.
For example, refactoring is a common technique used for making models evolve. One usual
refactorization step is to add packages to improve the grouping structure of the model. This is
the kind of change that affects the containment tree, as depicted in Figure 5.3, and that can be
missed by those approaches that compare elements only at the same level of the tree.
Figure 5.3: Example of package refactorization.
5.2.2.2
Computing Differences
As previously mentioned, the model difference operation makes use of the match model in
order to decide whether one element in the minuend model is the same (although possibly
modified) as another in the subtrahend model. Thus, in the global comparison process the
match model is calculated before the differencing part starts:
81
v a r s M1 M2 : @Model .
v a r s MM1 MM2 : @Metamodel .
v a r s OBJSET1 OBJSET2 : Set{@Object} .
op difference : @Model @Model −> @Model .
--- Using Structural matching algorithm
eq difference ( M1 , M2 ) = difference ( M1 , M2 , match ( M1 , M2 ) ) .
op idDifference : @Model @Model −> @Model .
--- Using Identifier matching
eq idDifference ( M1 , M2 ) = difference ( M1 , M2 , idMatch ( M1 , M2 ) ) .
op difference : @Model @Model @Model −> @Model .
eq difference ( MM1 { OBJSET1 } , MM2 { OBJSET2 } , MATCHM )
= @Difference@ { difference ( OBJSET1 , OBJSET2 , MATCHM ) } .
op difference : Set{@Object} Set{@Object} @Model −> Set{@Object} .
In order to specify the differencing part, we have identified four different situations that
may happen when calculating a model difference operation on an element: (1) the element
appears in both models (minuend and subtrahend) and has not been modified; (2) the element
appears in both models but has been modified; (3) the element only appears in the minuend
model; and (4) the element only appears in the subtrahend model.
The four Maude equations below specify the difference operation in each of these cases.
In all of them we will use the following variable declarations:
v a r s M MATCHM : @Model .
v a r s OBJSET OBJSET1 OBJSET2 : Set{@Object} .
v a r s O O1 O2 : Oid .
v a r s C C1 C2 : @Class .
v a r s SFS SFS1 SFS2 : Set{@StructuralFeatureInstance} .
In the first case, we have to check whether two objects (one belonging to the minuend
model, the other belonging to the subtrahend model) match, i.e., they represent the same element, and belong to the same class and have the same structural feature values. If this situation
occurs, we have found an element that has not been modified, and therefore no evidence of the
element is stored in the difference model:
ceq difference(< O1 : C | SFS > OBJSET1 , < O2 : C | SFS > OBJSET2 , MATCHM )
= difference ( OBJSET1 , OBJSET2 , MATCHM )
i f match ( O1 , O2 , MATCHM ) .
The match operation checks whether the corresponding match object that relates O1 and
O2 exists in the match model.
op match : Oid Oid @Model −> Bool .
eq match ( O1 , O2 , @Match@ { < O : Match | leftEl : O1 # rightEl : O2 # SFS > OBJSET } )
= true .
eq match ( O1 , O2 , M ) = false [ owise ] .
82
In the second case, two objects represent the same element, but the element has been mod-
ified, i.e., the two objects match, but either they belong to different classes (Maude allows the
dynamic reclassification of objects), or their attributes have different values. In this case, we
create an object instance of class ModifiedElement with references to both the object of the
subtrahend model (before the modification, oldElement) and the object of the minuend model
(after the modification, element). Both operand models’ objects are added to the difference
model, but only with the relevant attributes, i.e., those that have different values in both objects
(storing both values, the old one and the new one). The identifiers of the two added objects are
modified (with newId and oldId operations) to distinguish them, since Maude objects should
have unique identifiers in the same Maude configuration. Modifications to object identifiers are
performed in such a way that it is possible to “undo” them to get the original identifiers (with
the originalId operation, which will be introduced later).
ceq difference(< O1 : C1 | SFS1 > OBJSET1 , < O2 : C2 | SFS2 > OBJSET2 , MATCHM )
= < newModId ( O1 ) : ModifiedElement | element : newId ( O1 ) # oldElement : oldId ( O2 ) >
< newId ( O1 ) : C1 | attsDiff ( SFS1 , SFS2 ) >
< oldId ( O2 ) : C2 | attsDiff ( SFS2 , SFS1 ) >
difference ( OBJSET1 , OBJSET2 , MATCHM )
i f match ( O1 , O2 , MATCHM ) / \ not ( SFS1 == SFS2 ) or not ( C1 == C2 ) .
Note that every element modification is treated in the same way, i.e., the ModifiedElement metaclass is used for all kinds of possible modifications: from a modification in
a String attribute value to a change in the order of elements in collections. This decision was
made for the sake of simplicity, although, of course, the Difference Metamodel could be easily
extended to explicitly distinguish between different kinds of element modifications, if required.
In the third and fourth cases, one element in one of the models does not match any element
of the other model. If the object only appears in the minuend model, the element has been
added; otherwise (i.e., the object only appears in the subtrahend model) the element has been
deleted. Thus, we just have to create an object AddedElement (or DeletedElement, respectively) with a reference to the element in question, which will be also added to the difference
model (modifying its identifier as previously described):
eq difference ( < O1 : C1 | SFS1 > OBJSET1 , OBJSET2 , MATCHM )
= < newAddId ( O1 ) : AddedElement | element : newId ( O1 ) >
< newId ( O1 ) : C1 | SFS1 >
difference ( OBJSET1 , OBJSET2 , MATCHM )
[ owise ] .
eq difference ( OBJSET1 , < O2 : C2 | SFS2 > OBJSET2 , MATCHM )
= < newDelId ( O2 ) : DeletedElement | element : oldId ( O2 ) >
< oldId ( O2 ) : C2 | SFS2 >
difference ( OBJSET1 , OBJSET2 , MATCHM ) [ owise ] .
83
The reader should notice the existence of a final fifth case where both the minuend and
subtrahend models are empty. In this case, the result of the modelDiff operation will be an
empty difference model, as expected:
eq difference ( none , none , MATCHM ) = none .
Finally, note that these specifications do not force both operand models to conform to the
same metamodel, i.e., this difference operation can be applied to minuend and subtrahend
models conforming to different metamodels. Thus, in some situations in which models and
metamodels are evolving at the same time, models can be compared as well.
5.2.3 An Example of Model Difference
For illustration purposes, let us introduce a simple example to show how the model difference
works, and the results that it provides. Given the production system model depicted in Figure 3.5, suppose that we add another user (u2) with position (6,1). As a result, the following
model (depicted in Figure 5.4) is obtained:
Figure 5.4: Another production system model (concrete syntax).
ProductionSystem {
< ’p : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u # ’u2} >
< ’heg : HeadGen | in : null , out : ’c1 , xPos : 1 , yPos : 3 >
< ’hag : HandleGen | in : null , out : ’c2 , xPos : 1 , yPos : 1 >
< ’c1 : Conveyor | parts : Sequence{} , out : ’t1 , xPos : 2 , yPos : 3 >
< ’t1 : Tray | parts : Sequence{} , capacity : 4 , xPos : 3 , yPos : 2 >
< ’a : Assembler | in : ’t1 , out : ’c3 , xPos : 4 , yPos : 2 >
< ’t2 : Tray | parts : Sequence{} , capacity : 4 , xPos : 6 , yPos : 2 >
< ’u : User | parts : Sequence{} , xPos : 6 , yPos : 3 >
< ’u2 : User | parts : Sequence{} , xPos : 6 , yPos : 1 >
} .
84
Note that plant ’p is also modified, since it has a reference to the elements that it contains.
Now, if we take the modified model as the minuend model, and the initial model as the
subtrahend model, the result of applying the difference operation is the following difference
model:
< ’p@MOD : ModifiedElement | element : ’p@NEW # oldElement : ’p@OLD >
< ’p@NEW : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u # ’u2} >
< ’p@OLD : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u} >
< ’u2@ADD : AddedElement | element : ’u2@NEW >
< ’u2@NEW : User | parts : Sequence{} , xPos : 6 , yPos : 1 >
As we can see, the added user and the plant reference modification are both represented in the
difference model (elements were matched as expected).
5.2.4 Related Operations
Model difference is probably the main operation for dealing with model evolution and for
handling model versions, but it is not the only one required to achieve such processes. There
are other related operations that need to be considered too, such as those that do and undo the
changes, compose several differences, etc. For instance, operations do and undo will allow us
to obtain the minuend model from the subtrahend model, and viceversa, respectively.
In fact, one of the current limitations of other proposals that implement model comparison
and difference (e.g., [88]) is that their results cannot be effectively composed, and that these
additional operations are hard to define. In our approach, given the way in which the differences
have been represented (as models) and the modelDiff operation has been specified (as an
operation on models), they become natural and easy to define [105].
5.2.4.1
The do Operation
Given a model Ms conforming to an arbitrary metamodel MM and a difference model Md
(conforming to the Difference Metamodel), the result of applying operation do to them is
another model Mm so that: do(Ms ,Md ) = Mm and modelDiff(Mm ,Ms ) = Md .
Operation do applies to a model all the changes specified in a difference model. Basically, it
adds to the model all elements referred to by AddedElements of the difference model; deletes
from the model all elements referred to by DeletedElements of the difference model; and
modifies those elements of the model which are referred to by ModifiedElements.
In Maude, this operation can be specified by three equations (described below) that correspond, respectively, to the addition, deletion and modification of elements. A fourth equation
85
is also included to deal with the empty difference:
1
v a r s MM1 MM2 : @Metamodel .
2
v a r s OBJSET1 OBJSET2 : Set{@Object} .
3
v a r s O1 O2 OLDO NEWO : Oid .
4
v a r s C1 NEWC OLDC : @Class .
5
v a r s SFS1 OLDSFS NEWSFS : Set{@StructuralFeatureInstance} .
6
7
op do : @Model @Model ˜> @Model .
8
eq do ( MM1 { OBJSET1 } , MM2 { OBJSET2 } ) = otherMM ( MM1 , OBJSET2 ) { do ( OBJSET1 , OBJSET2 ) } .
9
10
op do : Set{@Object} Set{@Object} ˜> Set{@Object} .
11
eq do ( OBJSET1 , < O2 : AddedElement | element : NEWO >
12
13
14
15
< NEWO : NEWC | NEWSFS > OBJSET2 )
= < originalId ( NEWO ) : NEWC | NEWSFS >
do ( OBJSET1 , OBJSET2 ) .
ceq do(< O1 : C1 | SFS1 > OBJSET1 ,
17
18
19
< O2 : DeletedElement | element : OLDO >
< OLDO : OLDC | OLDSFS > OBJSET2 )
16
= do ( OBJSET1 , OBJSET2 )
i f O1 = originalId ( OLDO ) .
ceq do(< O1 : C1 | SFS1 > OBJSET1 , < O2 : ModifiedElement | element : NEWO #
20
oldElement : OLDO >
21
< NEWO : NEWC | NEWSFS >
22
23
24
25
26
= < originalId ( NEWO ) : NEWC | ( excludingAll ( SFS1 , OLDSFS ) , NEWSFS ) >
do ( OBJSET1 , OBJSET2 )
i f O1 = originalId ( OLDO ) .
eq do ( OBJSET1 , OBJSET2 ) = OBJSET1 [ owise ] .
Operation otherMM gets the metamodel of the minuend model by looking for it through
the classes of the difference model (note that model difference can be applied over models conforming to different metamodels). The auxiliary operation originalId recovers the original
identifier of the object that was modified, i.e., reverts the changes done by operations newId
or oldId in the model difference. Operation excludingAll deletes from a set of structural feature instances SFS1 all the structural feature instances that have the same name of any
structural feature instance of the OLDSFS set. This operation is used in line 23 to remove from
SFS1 the structural features that have the old values (OLDSFS), to add them again but with the
corresponding new values (contained in NEWSFS).
Note that a matching between both models (Ms and Md ) is not needed, because operation do is supposed to be applied to the original model of the difference, and original object
identifiers can be recovered from the difference model.
The resulting model Mm will usually conform to the same metamodel MM of Ms . However, model difference can be applied to models conforming to different metamodels. In general, model difference will be applied to models conforming to the same metamodel, or meta-
86
models that are related by the sybtyping relationship. Therefore, we could usually affirm that
the resulting model Mm will conform to a metamodel which is a subtype [116] (or, in special
cases, supertype) of the metamodel MM of the original subtrahend Mm .
5.2.4.2
The undo Operation
Given a model Mm conforming to a metamodel MM and a difference model Md (conforming
to the Difference Metamodel), the result of applying operation undo to them is another model
Mm so that: undo(Mm ,Md ) = Ms and modelDiff(Mm ,Ms ) = Md . As well as in operation
do, the resulting model Ms will usually conform to the same metamodel MM of Mm (if this
was true when the difference was done).
This operation reverts all the changes specified in a difference model. Operation undo
can be considered as the inverse operation of do. Basically, it adds to the model all elements
referred to by DeletedElements of the difference model; deletes from the model all elements
referred to by AddedElements of the difference model; and modifies those elements of the
model that are referred to by ModifiedElements (but in the opposite way of operation do).
Since the equations for the undo operation are analogous to the equations for the do operation,
we will not include them here.
5.2.4.3
Sequential Composition of Differences
Another important operation provides the sequential composition of differences. In general,
each difference model represents the changes in a model from one version to the next, i.e.,
a delta (∆). The diffComposition operation specifies the composition of deltas, so that
individual deltas can be combined into a single one.
This operation is very useful, for instance, to “optimize” the process of applying successive modifications to the same model, which might introduce complementary changes. For
example, if one element is added in one delta and then deleted in another, the composed delta
does not need to store both changes. In this way, this operation not only composes deltas,
but also eliminates unnecessary changes and provides more compact model differences, hence
improving efficiency.
The following Maude equations are a fragment of the diffComposition operation specification. The first equation corresponds to the composition of an addition and a deletion of
the same element. In this case, as mentioned before, there will be no evidence of the element
in the resulting difference model. The second equation corresponds to the composition of an
5.3. F URTHER O PERATIONS
87
addition and a modification of the same element. In this case, an AddedElement that refers to
the element with its attributes properly modified, and the element itself, will be included in the
resulting difference model.
op diffComposition : @Model @Model ˜> @Model .
eq diffComposition ( @Difference@ { OBJSET1 } , @Difference@ { OBJSET2 } )
= @Difference@ { diffComposition ( OBJSET1 , OBJSET2 ) } .
op diffComposition : Set{@Object} Set{@Object} −> Set{@Object} .
ceq diffComposition(< O1 : AddedElement | element : NEWO >
< NEWO : NEWC | NEWSFS > OBJSET1 ,
< O2 : DeletedElement | element@DiffElement : OLDO >
= diffComposition ( OBJSET1 , OBJSET2 )
i f originalId ( OLDO ) = originalId ( NEWO ) .
ceq diffComposition(< O1 : AddedElement | element : O >
< O : C | SFS > OBJSET1 ,
< O2 : ModifiedElement | element : NEWO # oldElement : OLDO ) >
< OLDO : OLDC | OLDSFS >
< NEWO : NEWC | NEWSFS > OBJSET2 )
= < newAddId ( originalId ( O2 ) ) : AddedElement | element : NEWO >
< NEWO : NEWC | ( excludingAll ( SFS , OLDSFS ) , NEWSFS ) >
diffComposition ( OBJSET1 , OBJSET2 )
i f originalId ( O ) = originalId ( OLDO ) .
...
eq diffComposition ( OBJSET1 , OBJSET2 ) = OBJSET1 OBJSET2 [ owise ] .
When no correspondences are found between the two difference models, i.e., when the difference models do not contain more DiffElements that refer to the same element, all their
remaining elements (DiffElements) are just included in the composition (as specified by the
last equation).
5.3
Further Operations
Model subtyping and model difference are quite helpful operations in MDE processes. However, there are many other operations that can also benefit from our models and metamodels
representation. For instance, one of the interesting applications of the proposed Maude formalization is the simplicity of the computation of metrics, both on models and metamodels. Thus,
e.g., most of the quality metrics for models defined in [35] can be easily formalized in Maude,
and therefore automatically computed. These metrics include, e.g., the number of classes, associations and inheritance relationships, the maximum DIT (Depth of Inheritance Tree), or the
average number of attributes, references or children per class.
88
For instance, the number of classes (EClasses) of an Ecore model coincides with the num-
ber of Maude objects of class EClass in its representation as an instance of the Ecore metamodel. This metric can be specified in Maude as follows:
var O : Oid .
var SFS : Set{@StructuralFeatureInstance} .
var OBJSET : Set{@Object} .
op NoOfClasses : @Model −> Nat .
eq NoOfClasses ( @Ecore { < O : EClass | SFS > OBJSET } )
= 1 + NoOfClasses ( @Ecore { OBJSET } ) .
eq NoOfClasses ( @Ecore { OBJSET } ) = 0 [ owise ] .
5.4 Tool Support with Maudeling
One of the main advantages of using Maude is the possibility of using its execution environment, able to provide efficient implementations of the specifications—comparable in resource consumption to most commercial programming languages’ environments. In addition,
the Maude environment is integrated in Eclipse, which has provided a very convenient working
environment for model management.
Figure 5.5: The Maudeling tool.
5.4. T OOL S UPPORT WITH M AUDELING
89
As part of this thesis, we have developed an Eclipse plug-in, called Maudeling [101], that
allows users to perform some of the previously described operations on EMF models, i.e.,
on models defined in the Eclipse platform.1 In this way, the user can define their models
and metamodels with the Eclipse tool of choice, and then execute the model management
operations in Maude being completely unaware of it (Maude is kept completely transparent to
the user). Both versions of the tool (1.0 [101] and 2.0) can be downloaded from our website [2].
The version 2.0 includes model validation, subtyping and difference related operations.
Its main component is the Maude perspective, which includes several buttons to perform the
corresponding operations. In addition, the user can also invoke the model validation operation
directly from a contextual menu.
Whenever an operation is invoked, Maudeling performs as follows: it encodes EMF models
and metamodels into Maude, executes the corresponding operation in the Maude environment,
and transforms back the resulting Maude specifications into the original notation (see below).
The final result of applying the model difference operation (or one of its related operations) is
an EMF model, while the final result of applying model subtyping and validation is a boolean
value.
5.4.1 The Way Back to EMF
In Section 4.2 we showed how we encode EMF models (and metamodels) into Maude. Once
we count on the Maude representation of these models, we can make use of the model operations presented in previous sections. However, some of these operations return a model as a
result. Since we want users to be completely unaware of Maude, we have developed a model
transformation to transform models specified in Maude into the EMF notation. In what follows,
we present the steps that are involved in this process.
Firstly, we have to parse the Maude term that represent a model (a term of sort @Model) into
a Maude model (see Section 4.2.1.3). This Maude model, which will conform to the Maude
metamodel, will also contain the specification of the @Model term.
Then, this Maude model is transformed into the corresponding EMF model that represents
the term it contains. For instance, if the Maude term represents an Author model, we have to
transform it to an EMF model conforming to the Author metamodel (see Figure 2.2). Note
that this transformation depends on the metamodel the @Model term conforms to. Thus, we
cannot achieve this process with a simple transformation: we need a Higher-Order Transfor1
Maudeling uses our previous Maude representation for models and metamodels, which is described in [106].
90
mation (HOT). A HOT is a model transformation whose output is another transformation, i.e.,
whose output is a model that conforms to a metamodel that represents a model transformation
language. In our case, the HOT (named Ecore2ATL) will take as input the metamodel MM
(defined as a Ecore model) to which the final model will conform, and produce as output a
model transformation (an ATL model) that will transform the Maude specifications to a model
conforming to MM. For instance, if the Maude term represents an Author model, the input of
this HOT will be the Author metamodel, and its output an ATL model (Maude2Author) which
transforms Maude specifications into Author models. Figure 5.6 shows an overview of this
transformation.
Figure 5.6: The higher-order transformation process.
Figure 5.7 shows the correspondences between a Maude model containing a @Model term
that represents a particular author model, and its corresponding EMF representation. The resulting Maude2Author transformation is specified in ATL as follows.
1
module Maude2Ecore ;
2
c r e a t e OUT : MM from IN : Maude ;
3
4
u s e s Maude2ModelLib ;
5
6
r u l e ”Author : : Book” {
from
7
8
rt : Maude ! RecTerm
9
( rt . op = thisModule . objectOperator and rt . isTypeOf ( ’@Object’ )
and rt . belongsTo ( ’Book@Author’ ) )
10
to
11
cl : Author ! Book (
12
name <− rt . getAttValue ( ’name’ ) . attToString ( ) ,
13
ISBN <− rt . getAttValue ( ’ISBN’ ) . attToString ( ) )
14
15
}
16
17
18
19
r u l e ”Author : : Author” {
from
( rt . op = thisModule . objectOperator and rt . isTypeOf ( ’@Object’ )
20
and rt . belongsTo ( ’Author@Author’ ) )
21
using{
22
books : OrderedSet ( Maude ! Constant ) = rt . getAttValue ( ’books’ ) . toOrdSet ( ) ; }
23
to
24
cl : Author ! Author (
25
26
name <− rt . getAttValue ( ’name’ ) . attToString ( ) ,
27
surname <− rt . getAttValue ( ’surname’ ) . attToString ( ) ,
28
books <− Maude ! RecTerm−>allInstances ( )−>select ( rt | rt . isTypeOf ( ’@Object’ ) )−>
select ( obj | books−>exists ( oid | oid . op = obj . oid ( ) . op ) ) )
29
30
91
}
Figure 5.7: Correspondences between Maude and EMF specifications.
The Author::Book rule transforms every Maude recursive term (Maude!RecTerm) that represent a book object (a < : | > term of sort @Object whose class is Book@Author) into an
object (cl) of the Author!Book class. The attribute values of cl are set by using the getAttrValue
operation. This operation traverses all the structural features of a Maude object to get the value
of the one whose name is specified as parameter.
The Author::Author rule is similar to the Author::Book rule. The attribute values of cl are set
by using the getAttrValue operation, and its reference values (in this case, the books reference)
are set by searching in the entire model those Maude recursive terms that represent the referred
objects. Since there exists a rule (the Book rule) which transforms these recursive terms into
book objects, the books reference will be correctly set.
By observing these two rules, we notice that they follow the same structure. This design
has been chosen to facilitate its automatic generation through a HOT transformation. Furthermore, both of them use general helpers, i.e., helpers whose definitions are completely independent of the metamodel, such as belongsTo or getAttrValue. These helpers are defined in
the Maude2ModelLib library, which will be imported by every transformation generated by the
92
Ecore2ATL transformation. Additionally, Ecore2ATL generates an ATL match rule per metaclass following the mentioned structure. The interested reader is referred to our website [2] to
find the specification of the Ecore2ATL transformation in our tool e-Motions.
Finally, we would like to clarify that in the encoding of EMF models into Maude (the
reverse transformation) a simple transformation is enough: thanks to the meta-capabilities of
the EObject interface, we can access any model object and obtain its metaclass independently
of the metamodel the model conforms to. However, the inverse process is not feasible: we
cannot create a general object with ATL, look for its class in the Maude model, and then assign
it. This is the reason why we have accomplished this process by defining a HOT.
5.4.2 Adapting Difference Models to the Eclipse Platform
In Maude, objects may have references to non-accessible elements. For instance, modified,
added and deleted elements of difference models (contained by the element and oldElement
references) may refer to other objects that are not contained in the difference model but in
one of the operand (subtrahend or minuend) models. If we remove, for example, the minuend
model, and keep the subtrahend and difference models, the references from difference elements
to objects of the minuend model will be kept. Then, whenever we apply the do operation to
the subtrahend and difference models, we will recover the minuend model and the dangling
references will become valid references again.
However, EMF editors do not work like that: they do not allow editing models with dangling references. If we, e.g., delete one of the difference operand models, the difference model
may become invalid, and therefore we need to maintain minuend and subtrahend models in
order to have a valid difference model.
Thus, we have defined a mechanism to adapt our difference approach to the Eclipse platform taking into account these considerations. We have created a new Difference metamodel
where difference elements will not contain the modified, added, and deleted elements anymore
but they will have just an (intermodel) reference to them (note that in Eclipse we will have
to maintain the difference operand models, so it makes no sense for the difference model to
contain these elements too). In fact, the only difference with respect to the Difference metamodel shown in Figure 5.1 is that the element and oldElement references are not containments.
Then, to transform models conforming to the previous Difference metamodel (specified in the
Maude platform) to this new one (specified in the Eclipse platform), we have specified an ATL
model transformation from Maude to EMF that adapt difference models to this new represen-
93
tation. This transformation has been defined making use of the Ecore2ATL transformation: we
selected the previous Difference metamodel as input, and we adapted the resulting transformation to set these new intermodel references properly:
module DifferenceRepresentation ; -- Module Template
c r e a t e OUT : Difference from IN : Maude , SUB : Ecore1 , MIN : Ecore2 ;
u s e s Maude2ModelLib ;
...
r u l e ”Difference : : ModifiedElement” {
from
( rt . op = thisModule . object and
rt . isTypeOf ( ’@Object’ )
and rt . belongsTo ( ’ModifiedElement@Difference’ ) )
using{
oid_element : S t r i n g = rt . listVariable ( ’element’ )−>first ( ) . originalOid ( ) ;
oid_oldElement : S t r i n g = rt . listVariable ( ’oldElement’ )−>first ( ) . originalOid ( ) ;
}
to
cl : Difference ! ModifiedElement ( )
do{
cl . refSetValue ( ’element’ , Ecore2 ! EObject . getInstanceById ( ’MIN’ , oid_element ) ) ;
cl . refSetValue ( ’oldElement’ , Ecore1 ! EObject . getInstanceById ( ’SUB’ , oid_oldElement ) ) ;
}
}
r u l e ”Difference : : DeletedElement” {
from
( rt . op = thisModule . object and rt . isTypeOf ( ’@Object’ )
and rt . belongsTo ( ’DeletedElement@Difference’ ) )
using{
}
to
cl : Difference ! DeletedElement ( )
do{
cl . refSetValue ( ’element’ , Ecore1 ! EObject . getInstanceById ( ’SUB’ , oid_element ) ) ;
}
}
r u l e ”Difference : : AddedElement” {
from
( rt . op = thisModule . object and rt . isTypeOf ( ’@Object’ )
and rt . belongsTo ( ’AddedElement@Difference’ ) )
using{
}
to
94
cl : Difference ! AddedElement ( )
do{
cl . refSetValue ( ’element’ , Ecore2 ! EObject . getInstanceById ( ’MIN’ , oid_element ) ) ;
}
}
Note that we have added two additional input models: MIN and SUB, that represent the minuend and subtrahend models, respectively. They are needed to get their corresponding added,
deleted or modified objects. These objects will be obtained by means of the getInstanceById
ATL operation, which looks for them by their identifiers. Once we get these objects, we can
set the value of the element reference of the created difference elements (and the value of the
odlElement reference in case of ModifiedElements) properly by making use of the refSetValue
ATL operation.
5.5 Related Work
There is quite a large number of contributions about the importance of model management, the
operations required to deal with models and metamodels, and about algorithms to implement
such operations. For instance, there is the work by X. Blanc on the Model Bus [22], or the
work by Bernstein on Model Management [19] on how model operations can help addressing
classical meta-data management problems such as schema integration, schema evolution, and
round-trip engineering. Many people have mentioned the importance of counting on model
management operations such as model subtyping, match, merge, diff, compose, or apply, and
some other people have developed algorithms for implementing some of these operations. Most
of these implementations have been independently developed, although some of them have
tried to deal with them on a unified and general way (e.g., [13, 63]), but mostly at a very high
level, using category theory and institutions. What we are presenting here is an integrated environment to both formally specify these operations, and to provide efficient implementations
for them, which has been integrated into an Eclipse model engineering environment.
In this sense, MOMENT [23, 5, 24] is a generic model management framework integrated
in Eclipse which provides a reflective, algebraic, and executable framework for metamodeling,
with support for MOF and OCL, and partial support for the QVT Relations language. It also
uses Maude modules to automatically serialize software artifacts, but the kind of operations
they provide are different. They do not provide model subtyping These operations rely on the
definition of the Equal operation for matching two elements. The semantics of this operation
coincides with the syntactical equivalence, although this generic semantics can be enriched by
5.5. R ELATED W ORK
95
means of OCL expressions that take into account the structure and semantics of a specific metamodel. The latest internal encoding of models and metamodels in MOMENT was presented
in [25], and shares many similarities with our previous representation [110] (see Section 4.3 for
a comparison between the two representations). The tool does not follow a full MDE process
to define the semantic mappings: they directly serialize EMF models into Maude instead of
defining a Maude metamodel and model transformation between both platforms.
Model Subtyping. One of the most relevant works in model subtyping was presented by
Steel and Jézéquel in [117]. They introduced a model type definition as an extension of object
type, i.e., as the set of objects types for all the objects contained in a model (basically a metamodel without its packages structure). The reason not to consider the metamodel as the model
type is attributed to the increasing abundance of models that refer to other models, that causes
that we can no longer guarantee that the classes of all objects within a model will be contained
by a single package. However, we think that the problem lies on the metamodel definition
they adopt, assuming a metamodel as a single MOF package and not considering the different
package relationships (such as importation) that may exist. Our flattened subtyping covers the
subtyping relationship they propose.
There are other approaches that propose to check type conformance from a set of restrictions. For instance, in [56], a type system for object models is described that supports subtypes
and allows overloading of relation names. The work is focused on type conformance, which
is checked using the Alloy language. Model operations defined over the object models are not
considered.
Finally, in [126], metamodel evolution is also handled, but they focus on the adaption of
the models that conforms to the metamodels instead of on their operations.
Model Difference. There are several proposals that address the problems of comparing models and calculating their difference. Firstly, we have the works that describe how to compute
the difference of models that conform to one specific metamodel, usually UML [14, 87, 127].
Their specificity and strong dependence on the elements and structure of the given metamodel
hinders their generalization as metamodel-independent approaches that can be used with models that conform to arbitrary metamodels.
Secondly, there are several techniques that allow to compute the difference between models
using edit scripts, which are based on representing the modifications as sequences of atomic
actions specifying how the initial model is procedurally modified. These approaches are more
96
general and powerful, and have been traditionally used for calculating and representing differences in several contexts. However, edit scripts are intrinsically not declarative, lengthy and
very fine-grained, suitable for internal representations but quite ineffective to be adopted for
documenting changes in MDE environments, and difficult to compose. Furthermore, the results of their calculations are not expressed as a model conforming to a specific metamodel,
and therefore they cannot be processed by standard modeling platforms [39].
Other works, such as [39], [77] and [119], are closer to ours. In [39], a metamodelindependent approach to difference representation is presented, but with the particularity that
the Difference Metamodel is not fixed, but created in each case as an extension of the operands’
metamodel. This approach is agnostic of the calculation method, so it does not introduce any
model difference operation, and also requires a complex model transformation process to create
the specific Difference Metamodel and to calculate the differences. Matching is based on name
comparison: the proposal assumes that a specific attribute called name always exists. This
may hinder its application in some contexts, such as for instance those in which metamodels
are defined in languages different to English.
The work described in [77] introduces an algorithm for calculating and representing model
differences in a metamodel-independent manner, but the result is not compact (it contains more
information than required) and it is more oriented towards graphically representing and visualizing the differences.
Thirdly, EMFCompare [119] is an interesting approach that uses complex and sophisticated algorithms to compute the structural matching between model elements. However, this
proposal makes heavy use of the hierarchical tree for matching the elements, restricting the
comparisons to elements in the same level. As discussed in Section 5.2.2, this restriction may
not be effective in some cases, including those in which the changes affect the tree structure
(something common in several model refactoring operations). Furthermore, difference models
are not self-contained in EMFCompare, and therefore the minuend and subtrahend models are
required in order to operate with the differences.
Finally, none of these approaches currently provide good support for composing the deltas
and implementing further operations on them.
Chapter 6
Behavioral Semantics of DSMLs
Once we count on a formalization of models and metamodels in MEL, we can provide them
with behavioral specifications by using Rewriting Logic (RL). In this chapter we present a way
to specify the behavior of DSMLs by means of rewriting rules in Maude. This allows us to, e.g.,
perform simulation and reachability and model-checking analysis on the domain specific models using the tools and techniques that Maude provides. However, we do not expect a DSML
designer to learn Maude for specifying the behavior of his/her DSML. Therefore, we introduce
a graphical and more intuitive way to do it by means of in-place model transformation, and we
show the similarity between the two approaches.
6.1 Representing DSMLs’ Behavior with Maude
In Section 4.1 we showed how we represent the structural parts of a DSML (namely models and
metamodels) in Maude. This section introduces how we represent DSMLs’ dynamic behavior.
Dynamic behavior is usually specified in Maude in terms of rewrite rules. These rules,
of the form [t]E → [t′ ]E , 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 . Thus, given a Maude module with the specification of a MEL theory that
represent a metamodel, we can “extend” it with behavioral information by adding the appropriate rewrite rules. Therefore, the complete specification of the system (including the structural
and behavioral views) will now be represented with a rewrite theory.
To illustrate this approach, consider again the production system example in Section 3.2.
Figure 3.2 shows the Production System (PS) metamodel. Note that it is not clear from this
metamodel when are handles and heads generated, or what is the precise behavior of the sys97
98
C HAPTER 6. B EHAVIORAL S EMANTICS OF DSML S
tem when one of the trays is full. Can we execute the system for simulating different trays
capacities, in order to find the most efficient production line? These are the sort of issues that
need to be precisely clarified by a behavioral specification.
The following Maude module PRODUCTION-SYSTEM-WITH-BEHAVIOR extends the PRODUCTION-SYSTEM module (see Section 4.1.1) with five rules:
mod PRODUCTION−SYSTEM−WITH−BEHAVIOR i s
p r o t e c t i n g PRODUCTION−SYSTEM .
v a r s U P C T HEG HAG HA HE HAM A PL : Oid .
v a r s PARTS PARTS ’ : Sequence .
v a r s SFS SFS ’ SFS ’ ’ SFS ’ ’ ’ SFS ’ ’ ’ ’ : Set{@StructuralFeatureInstance} .
v a r s CONT CAP XPOS
XPOS ’ YPOS YPOS ’ : Int .
var PART : Part .
c r l [ GenHead ] :
ProductionSystem {
< HEG : HeadGen | counter : CONT # out : C # SFS >
< C : Conveyor | parts : PARTS # xPos : XPOS # yPos : YPOS # SFS ’ >
OBJSET }
=>
ProductionSystem{
< HEG : HeadGen | counter : << CONT − 1 >> # out : C # SFS >
< C : Conveyor | parts : << PARTS −> append ( HE ) >> # xPos : XPOS # yPos : YPOS # SFS ’ >
< HE : Head | xPos : XPOS # yPos : YPOS >
OBJSET }
i f << CONT <> 0 >>
/ \ HE : = headId ( CONT ) .
c r l [ GenHandle ] :
ProductionSystem {
< HAG : HandleGen | counter : CONT # out : C # SFS >
< C : Conveyor | parts : PARTS # xPos : XPOS # yPos : YPOS # SFS ’ >
OBJSET }
=>
ProductionSystem{
< HAG : HandleGen | counter : << CONT − 1 >> # out : C # SFS >
< C : Conveyor | parts : << PARTS −> append ( HA ) >> # xPos : XPOS # yPos : YPOS , SFS ’ >
< HA : Handle | xPos : XPOS # yPos : YPOS >
OBJSET }
i f << CONT <> 0 >>
/ \ HA : = handleId ( CONT ) .
c r l [ Transfer ] :
ProductionSystem {
< C : Conveyor | parts : PARTS # out : T # SFS >
< T : Tray | capacity : CAP # parts : PARTS ’ # xPos : XPOS ’ # yPos : YPOS ’ # SFS ’ >

OBJSET }
6.1. R EPRESENTING DSML S ’ B EHAVIOR WITH M AUDE
99
=>
ProductionSystem{
< C : Conveyor | parts : << PARTS −> excluding ( P ) >> # out : T # SFS >
< T : Tray | capacity : CAP # parts : << PARTS ’ −> append ( P ) >> #
xPos : XPOS ’ # yPos : YPOS ’ # SFS ’ >

OBJSET }
i f << PARTS −> first ( ) . = . P >>
/ \ << PARTS ’ −> size ( ) < CAP >> .
c r l [ Assemble ] :
ProductionSystem {
< HA : Handle | SFS >
< HE : Head | SFS ’ >
< T : Tray | parts : PARTS # SFS ’ ’ >
< A : Assembler | in : T # out : C # SFS ’ ’ ’ >
< C : Conveyor | parts : PARTS ’ # xPos : XPOS # yPos : YPOS # SFS ’ ’ ’ ’ >
OBJSET }
=>
ProductionSystem{
< T : Tray | parts : << PARTS −> excluding ( HE ) −> excluding ( HA ) >> # SFS ’ ’ >
< A : Assembler | in : T # out : C # SFS ’ ’ ’ >
< C : Conveyor | parts : << PARTS ’ −> append ( HAM ) >> # xPos : XPOS #
yPos : YPOS # SFS ’ ’ ’ ’ >
< HAM : Hammer | xPos : XPOS # yPos : YPOS >
OBJSET }
i f << PARTS −> includes ( HE ) >>
/ \ << PARTS −> includes ( HA ) >>
/ \ HAM : = hammerId ( HE , HA ) .
c r l [ Collect ] :
ProductionSystem {
< T : Tray | parts : PARTS # xPos : XPOS # yPos : YPOS # SFS >

< HAM : Hammer | xPos : XPOS ’ ’ # yPos : YPOS ’ ’ # SFS ’ ’ >
OBJSET }
=>
ProductionSystem{
< T : Tray | parts : << PARTS −> excluding ( HAM ) >> # xPos : XPOS # yPos : YPOS # SFS >
 append ( HAM ) >> # xPos : XPOS ’ # yPos : YPOS ’ # SFS ’ >
< HAM : Hammer | xPos : XPOS ’ # yPos : YPOS ’ # SFS ’ ’ >
OBJSET }
i f << PARTS −> includes ( HAM ) >>
/ \ << ( XPOS − XPOS ’ ) . abs ( ) <= 1 >>
/ \ << ( YPOS − YPOS ’ ) . abs ( ) <= 1 >> .
endm
The GenHead and GenHandle rules specify the behavior of head and handle generators,
respectively. Since with these rules the value of the generator attribute counter is decreased
every time a part is generated, a head (or handle) is created and placed in the out conveyor
100
provided that the number of parts already generated is smaller than its upper bound (i.e., its
attribute counter is different from zero). The headId (resp. handleId) function returns a
new identifier of the form ’hen (resp. ’han) given a natural number n.
The Transfer rule specifies the behavior of conveyors. If there are parts in a conveyor, it
will place the first one in its out tray provided that there is enough space in it (i.e., the number
of parts in the tray is smaller than its capacity). Note the use of the variable PART, of sort Part,
to represent any of its subclasses.
The Assemble rule specifies the behavior of assemblers. If there is an assembler with
a head and a handle in its in tray, it will consume such a head and a handle and will put a
hammer in its out conveyor. Given identifiers ’hen and ’ham, for natural numbers n and m,
the hammerId function returns a new identifier ’hen.ham .
The Collect rule represents hammer collection. When there is a hammer on a tray, a
nearby user—an user who has an adjacent position to the tray—collects it with this rule.
Note that the dynamic semantics of the model is precisely specified by these rewrite rules.
For instance, if the counter of a generator is set to zero, it will generate no more parts; in case
that an user can collect several hammers, only one (at a time) will be collected in an nondeterministic way; etc. Moreover, this specification can be used for simulation and execution
purposes, as well as for formal analysis.
Finally, please note that several alternative behaviors can be specified by defining other
modules extending the original PRODUCTION-SYSTEM module with different rules. This, together with the module inheritance that Maude supports [42], provides a very powerful mechanism for refining and extending behavioral specifications.
For instance, suppose that we want to define two different behaviors for tray overflow: when
there is a conveyor with parts and its out tray is full, we want the first part of the conveyor
to be (a) assigned to the plant floor (the Drop rule), or (b) removed from the system (the
Remove rule). Thus, we define two new modules PRODUCTION-SYSTEM-WITH-BEHAVIOR-1
and PRODUCTION-SYSTEM-WITH-BEHAVIOR-2, that extend the above module with the Drop
and Remove rules, respectively:
mod PRODUCTION−SYSTEM−WITH−BEHAVIOR−1 i s
p r o t e c t i n g PRODUCTION−SYSTEM−WITH−BEHAVIOR .
v a r s C T P PL : Oid .
v a r s SFS SFS ’ SFS ’ ’ SFS ’ ’ ’ : Set{@StructuralFeatureInstance} .
v a r s PARTS ELS : Sequence .
var CAP : Int .
var PART : Part .
6.1. R EPRESENTING DSML S ’ B EHAVIOR WITH M AUDE
c r l [ Drop ] :
ProductionSystem {
< T : Tray | capacity : CAP # parts : PARTS ’ # SFS ’ >

< PL : Plant | els : ELS # SFS ’ ’ ’ >
OBJSET }
=>
ProductionSystem{

< PL : Plant | els : << ELS ’ −> append ( P ) >> # SFS ’ ’ ’ >
OBJSET }
i f << PARTS −> first ( ) . = . P >>
/ \ << PARTS ’ −> size ( ) >= CAP >> .
endm
mod PRODUCTION−SYSTEM−WITH−BEHAVIOR−2 i s
p r o t e c t i n g PRODUCTION−SYSTEM−WITH−BEHAVIOR .
v a r s C T P : Oid .
v a r s SFS SFS ’ SFS ’ ’ : Set{@StructuralFeatureInstance} .
v a r s PARTS : Sequence .
var CAP : Int .
var PART : Part .
c r l [ Remove ] :
ProductionSystem {

OBJSET }
=>
ProductionSystem{
OBJSET }
i f << PARTS −> first ( ) . = . P >>
/ \ << PARTS ’ −> size ( ) >= CAP >> .
endm
101
102
6.2 Formal Analysis of Domain Specific Models with Maude
Once the system specifications are written using Maude and the modeling approach presented
in this thesis, what we get is a rewriting logic specification of the system. Since the rewriting
logic specification produced in this way is executable, it can be used as a prototype of the
system, which allows us to simulate and analyze it.
Maude offers tool support for interesting possibilities such as model simulation, reachability analysis and model checking. We focus here on these three facilities, which will be
described with the help of examples that illustrate Maude’s possibilities in this context. Detailed descriptions of the commands and tools used here can be found in [42]. In addition,
models can be further analyzed using other available tools in Maude’s formal environment: the
LTL satisfiability and tautology checker [59], the Church-Rosser checker [53], the coherence
checker [54], the termination tool [52], etc. We also refer the interested reader to [42, 43] for
details on these tools.
6.2.1 Simulation
Given a Maude specification as the one described in the previous sections, it can be executed
by just successively applying equations and rewrite rules on an initial term (representing a
model). Maude provides two different rewrite commands, namely rewrite and frewrite,
which implement two different execution strategies, a top-down rule-fair strategy, and a depthfirst position-fair strategy, respectively (cf., [42]).
The rewrite and frewrite commands explore a possible execution for a given initial
model. However, a rewrite system do not need to be Church-Rosser and terminating,1 and
there might be many different execution paths. Although these commands are enough in many
practical situations where an execution path is sufficient for testing executability, the user might
be interested in exploring all possible execution paths from the starting model, a subset of these,
or a specific one.
There are currently three ways of controlling the execution process in Maude, which, ordered from the more complex to the easiest to use, are:
• Using the reflective capabilities of Maude, with built-in metalevel functions such as
1
For MEL specifications, being Church-Rosser and terminating means not only confluence—so that a unique
normal form will be reached—but also a sort decreasingness property, namely that the normal form will have the
least possible sort among those of all other equivalent terms.
6.2. F ORMAL A NALYSIS OF D OMAIN S PECIFIC M ODELS WITH M AUDE
103
metaReduce, metaApply, etc., which provide absolute control over the execution pro-
cess (see [42] for additional details).
• Using the Maude strategy language [58] to define strategy expressions that control the
way terms are rewritten.
• Using invariant-driven strategies for executing specifications complying with given invariants [55, 109].
We illustrate here the use of the Maude’s strategy language proposed in [58] as a mechanism
to guide the execution process. In this language, a strategy is described as an operation that,
when applied to a given term, produces a set of terms as a result (since in general this is a
nondeterministic process). The basic strategies consist of the application of a rule (identified by
the corresponding rule label) to a given term, and allowing variables in a rule to be instantiated
before its application with a specific substitution. Basic strategies are combined by means of
operators such as concatenation (;), union (|), iteration (* for zero or more times and + for
one or more times), if-then-else, etc.
For example, we can use the Maude srewrite using command to find all possible applications of the rules included in the PRODUCTION-SYSTEM-WITH-BEHAVIOR-1 module (see
Section 6.3) from the psModel initial model (see Section 4.1.2) as follows:
Maude> s r e w r i t e psModel u s i n g all ∗ .
In this case the number of possible executions is huge, and although may be helpful for
some automatic checking, the result is not very useful here. More interesting is the result given
by the following command:
Maude> s r e w r i t e psModel
u s i n g ( GenHead ; Transfer ; GenHandle ; Transfer ; Assemble ; Transfer ; Collect ) + .
In this case, the following sequence is enforced: firstly, a head is generated and moved to
the in tray of the assembler; then, a handle is generated and moved as well; afterwards, both
the head and the handle are assembled to generate a hammer; finally, this hammer is moved
to the final tray and collected by the user. Ten solutions are found, one for each possible time
that the sequence can be repeated before the generators reach their limit. For instance, the last
solution found, where ten hammers are created and stored, is the following:
r e s u l t @Model : ProductionSystem {
< ’p : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u} >
< ’heg : HeadGen | in : null # out : ’c1 # counter : 0 # xPos : 1 # yPos : 3 >
< ’c1 : Conveyor | parts : Sequence{mt−ord} # out : ’t1 # xPos : 2 # yPos : 3 >
104
< ’t1 : Tray | parts : Sequence{mt−ord} # capacity : 4 # xPos : 3 # yPos : 2 >
< ’u : User | parts : Sequence{ ’he10 . ha10 # he9 . ha9 # ’he8 . ha8 # ’he7 . ha7 # ’he6 . ha6 #
’he5 . ha5 # ’he4 . ha4 # ’he3 . ha3 # ’he2 . ha2 # ’he1 . ha1} # xPos : 6 # yPos : 3 >
< ’he1 . ha1 : Hammer | xPos : 6 # yPos : 3 >
...
}
The number of solutions to be shown can be limited using the corresponding (optional)
argument of the srewrite command. Thus, for example, we can ask for the first fifteen
executions, using a less strict strategy (applying some of the rules with some freedom), as
follows:
Maude> s r e w r i t e [ 1 5 ] psModel
u s i n g ( ( GenHead ; Transfer ) | ( GenHandle ; Transfer )
| ( Assemble ; Transfer ) | Collect ) + .
Among the solutions obtained we get the one above (together with many others). The rewrite
and frewrite commands also allow users to specify an upper bound for the number of rule
applications. This upper bound can be very useful to simulate non-terminating system, or to
execute a simulation step by step.
6.2.2 Reachability Analysis
Executing the system using the rewrite and frewrite commands means exploring just
one possible behavior of the system. As shown in Section 6.2.1, this can be partially improved
by using rewriting strategies. However, it does not allow us to analyze the solutions found.
The Maude search command allows us to explore (following a breadth-first strategy) the
reachable state space in different ways.
Let us start by looking for deadlock states. Although in this example we may easily guess
how the deadlock states look like, let us be a bit naive and look for final states (states on which
no further rewrite may take place), using the =>! variant of the search command, with no
hammers in the final container. For instance, starting from our initial model, and given variables
SFS of sort Set{@StructuralFeatureInstance} and OBJSET of sort Set{@Object}, we
can use the search command as follows:
105
Maude> s e a r c h [ 1 0 ] psModel =>!
ProductionSystem { < ’t2 : Tray | parts : Sequence{mt−ord} # SFS > OBJSET } .
Please note that we have limited the number of solutions to 10, otherwise it gives hundreds
of solutions. By observing them we realize that a possible source of deadlock is that the ’t1
tray may be full of parts of the same type, not allowing the assembler machine to proceed. Let
us look now for states satisfying this condition. For instance, starting from our initial model,
and given variables O1, O2, O3 and O4 of sort Oid; P of sort Part; SFS, SFS1, SFS2, SFS3 and
SFS4 of sort Set{@StructuralFeatureInstance}; and OBJSET of sort Set{@Object},
we can search for states on which the tray ’t1 contains four parts of the same type, using the
search command as follows:
Maude> s e a r c h [ 1 ] psModel =>∗
ProductionSystem { < ’t1 : Tray | parts : Sequence{O1 ; O2 ; O3 ; O4} # SFS >
< O1 : P | SFS1 >
< O2 : P | SFS2 >
< O3 : P | SFS3 >
< O4 : P | SFS4 >
OBJSET } .
Note the use of the =>* variant of the search command to look for any state, final or not.
Note as well that we have requested only the first solution. The result given by Maude is the
following:
Solution 1 ( state 1 8 2 )
OBJSET −−>
< ’heg : HeadGen | in : null , out : ’c1 # counter : 6 # xPos : 1 # yPos : 3 >
< ’u : User | parts : Sequence {mt−ord} # xPos : 6 # yPos : 3 >
SFS −−> xPos : 3 # yPos : 2 # capacity : 4
O1 −−> ’he10
O2 −−> ’he9
O3 −−> ’he8
O4 −−> ’he7
P −−> Head@ps
SFS1 −−> xPos : 3 # yPos : 2
SFS2 −−> xPos : 3 # yPos : 2
SFS3 −−> xPos : 3 # yPos : 2
SFS4 −−> xPos : 3 # yPos : 2
As result, a collection of solutions (variable substitutions) that fulfil the given search pattern is
obtained. In this case, a state with four heads placed in the tray ’t1 is found.
106
The shortest sequence of rewrites followed to reach this model (one of them in case of existing more than one with the same length) can be displayed by typing show path n, where
n is the number of a state (notice that it is 182 for the model shown). If we are only interested
in the labels of the applied rules, the command show path labels n can be used instead.
In this case, show path labels 182 produces the sequence GenHead GenHead GenHead
GenHead Transfer Transfer Transfer Transfer, which is one of the possible (short-
est) paths leading to this state.
Upper bounds for the number of rule applications (maximum depth) and solutions can also
be specified in the search. For instance, let us consider a new initial model, infPsModel,
with the counters of generators set to −1. Since counter attributes are decremented each
time a part is generated, and generators stop when its value is equals to zero, it can result in
a nonterminating execution if hammers are correctly produced (users do not have an upper
bound for contained parts). Then, it could be interesting to know, for example, whether a
model on which the user contains at least three hammers can be reached. Given variables
PARTS of sort Sequence, SFS of sort Set{@StructuralFeatureInstance} and OBJSET
of sort Set{@Object}, we can check it (by searching for only one solution) in the following
way:
Maude> s e a r c h [ 1 ] infPsModel =>∗
ProductionSystem { < ’u : User | parts : PARTS # SFS >
OBJSET }
such that << PARTS −> size ( ) >= 3 >> .
Note the use of the such that clause to look for states matching the specified pattern and
satisfying the given condition. Although the number of states reachable from the initial state is
infinite, a solution was found:
Solution 1 ( state 3 0 9 9 8 8 )
OBJSET −−>
< ’heg : HeadGen | in : null , out : ’c1 # counter : −4 # xPos : 1 # yPos : 3 >
< ’hag : HandleGen | in : null # out : ’c2 # counter : −4 # xPos : 1 # yPos : 1 >
<
’he1 . ha1 : Hammer | xPos : 6 # yPos : 3>
<
<
SFS −−>
xPos : 6 # yPos : 3
PARTS −−>
Sequence{ ’he1 . ha1 # ’he2 . ha2 # ’he3 . ha3}
107
We can also use the search command to check safety properties. For instance, given variables O of sort Oid, CAP of sort Int, PARTS of sort Sequence, OBJSET of sort Set{@Object},
and SFS of sort Set{@StructuralFeatureInstance}, we can check whether starting from
psModel the capacity of any tray is exceeded:
Maude> s e a r c h psModel =>∗
ProductionSystem { < O : Tray | capacity : CAP # parts : PARTS # SFS >
OBJSET }
such that << PARTS −> size ( ) > CAP >> .
No solution .
Since no solutions are found, we can state that (starting from psModel) the capacities of the
trays are never exceeded.
Whenever an invariant is violated, we are guaranteed to get a counterexample (up to time
and memory limitations). However, when the number of states reachable from the initial state is
infinite, and the invariant holds, we will search forever, never finding it. In these cases, bounded
search (a search with a maximum number of rule applications) is a widely used procedure that:
(a) together with a big depth can greatly increase the confidence that the invariants hold, and
(b) can still be quite effective in finding counterexamples, where applicable.
We can do the same check for infPsModel with a bound on the depth of the search of,
e.g., 1000, as follows.
Maude> s e a r c h [ 1 , 1 0 0 0 ] infPsModel =>∗
ProductionSystem { < O : Tray | capacity : CAP # parts : PARTS # SFS >
OBJSET }
such that << PARTS −> size ( ) > CAP >> .
No solution .
With the information provided by the performed analysis, we could modify the dynamic
behavior of our model to avoid deadlocks. For example, we could modify the behavior of
conveyors in such a way that a part is never put in the output tray if the capacity of the tray is
about to be filled with parts of the same type. The following two rules substitutes the Transfer
rule to model this behavior:
v a r s P P ’ C T : Oid .
v a r s PARTS PARTS ’ : Sequence .
v a r s SFS SFS ’ SFS ’ ’ SFS ’ ’ ’ : Set{@StructuralFeatureInstance} .
v a r s CAP XPOS
XPOS ’ YPOS YPOS ’ : Int .
var PART PART ’ : Part .
c r l [ Transfer1 ] :
ProductionSystem {
108
OBJSET }
=>
ProductionSystem{
OBJSET }
i f << PARTS −> first ( ) . = . P >>
/ \ << PARTS ’ −> isEmpty ( ) >> .
c r l [ Transfer2 ] :
ProductionSystem {

OBJSET }
=>
ProductionSystem{

OBJSET }
i f << PARTS −> first ( ) . = . P >>
/ \ << PARTS ’ −> includes ( P ’ ) >>
/ \ << ( PARTS ’ −> size ( ) < ( CAP − 1 ) ) or
( ( PARTS ’ −> size ( ) . = . ( CAP − 1 ) ) and ( PART =/= PART ’ ) ) >> .
The Transfer1 rule models the movement of the first part of a conveyor to its empty
output tray. The Transfer2 rule models the movement of the first part of a conveyor to its
non-empty output tray whenever a) the capacity of the tray is not going to be filled or b) it is
going to be filled but at least there exists a part on the tray which is of a different type from the
part which is being transferred.
6.2.3 LTL Model Checking
Maude offers a linear temporal logic explicit-state model checker [59], which allows us to
check whether every possible behavior starting from a given initial model satisfies a given
temporal logic property. Maude’s model checker can be used to prove safety and liveness
properties of rewriting systems when the set of states reachable from an initial state is finite.
109
Full verification of invariants in infinite-state systems can be accomplished by verifying the
invariants on finite-state abstractions (see, e.g., [85]) of the original infinite-state system, that
is, on an appropriate quotient of the original system whose set of reachable states is finite [42].
In order to specify safety and liveness properties, state predicates are needed. For instance,
suppose that we want to check that a hammer that has been created is eventually collected by
the user. In this case, we can introduce two different state predicates: exist and collected,
that will reflect whether a part exists and is collected, respectively.
State predicates are defined as operators of sort Prop, and their semantics are given by
means of a set of equations that specify for what model pattern a given state predicate evaluates
to true. In Maude, opposite to standard LTL propositional logic, we can define parametric state
predicates, that is, operators of sort Prop which need not be constants, but may have one or
more sorts as parameter arguments. The exist and collected prepositions can be specified
as follows:
ops exist collected : Oid −> Prop .
v a r s O P : Oid .
var PART : Part .
var PARTS : Sequence .
eq ProductionSystem { < O : PART | SFS > OBJSET } | = exist ( O ) = true .
ceq ProductionSystem { < O : User | parts : PARTS # SFS > OBJSET }
| = collected ( P ) = true
i f << PARTS −> includes ( P ) >> .
Note that we have only specified for what model patterns given state predicates evaluate to true.
The remaining case is already included in our Maude specifications.
var MODEL : @Model .
var PROP : Prop .
eq MODEL | = PROP = false [ owise ] .
After defining these state predicates, we are ready to model-check different LTL properties.
Making use of the eventually <> and henceforth [] LTL connectives, we can model check, for
instance, that a created hammer (say ’he10.ha10) is collected at some time, by typing:
Maude> r e d u c e modelCheck ( psModel , [ ] ( exist ( ’ he10 . ha10 ) −> <> collected ( ’ he10 . ha10 ) ) ) .
Of course, this property is not very useful, but it becomes a bit more interesting if we check
it for all possible hammers. Given the exist and stored propositions above, the following
110
formula allHammers express the same property for all possible hammers, with identifiers
created as in the above rules:
v a r s N M K : Nat .
op allHammers : Nat Nat −> Formula .
op allHammers : Nat Nat Nat −> Formula .
eq allHammers ( N , M ) = allHammers ( N , M , M ) .
eq allHammers ( s N , 0 , K )
= [ ] ( exist ( ID ) −> <> collected ( ID ) )
/ \ allHammers ( N , K , K )
i f ID : = hammerId ( headId ( s N ) , handleId ( 0 ) ) .
eq allHammers ( N , s M , K )
/ \ allHammers ( N , M , K )
i f ID : = hammerId ( headId ( N ) , handleId ( s M ) ) .
eq allHammers ( 0 , 0 , K )
i f ID : = hammerId ( headId ( 0 ) , handleId ( 0 ) ) .
We can now check it as follows:
Maude> r e d u c e modelCheck ( psModel , allHammers ( 1 0 , 1 0 ) ) .
Of course, not all properties are true. For example, if we model-check that a created head,
say ’he10, is consumed at any time (to form a hammer) by typing:
Maude> r e d u c e modelCheck ( psModel , [ ] ( exist ( ’ he10 ) −> <> ˜ exist ( ’ he10 ) ) ) .
we get a counterexample showing why it fails (in this case due to deadlock states).
r e s u l t ModelCheckResult : counterexample (
{ ProductionSystem {
< ’a : Assembler | out : ’c3 # in : ’t1 # xPos : 4 # yPos : 2 >
< ’hag : HandleGen | out : ’c2 # in : null # xPos : 1 # yPos : 1 # counter : 10 >
< ’heg : HeadGen | out : ’c1 # in : null # xPos : 1 # yPos : 3 # counter : 10 >
< ’t1 : Tray | parts : Sequence{mt−ord} # xPos : 3 # yPos : 2 # capacity : 4 >
< ’u : User | parts : Sequence{mt−ord} # xPos : 6 # yPos : 3 >},
’GenHead}
< ’c1 : Conveyor | parts : Sequence{ ’he10} # out : ’t1 # xPos : 2 # yPos : 3 >
< ’he10 : Head | xPos : 2 # yPos : 3 >
111
’GenHead}
...
< ’c2 : Conveyor | parts : Sequence{ ’ha1} # out : ’t1 # xPos : 2 # yPos : 1 >
< ’ha1 : Handle | xPos : 2 # yPos : 1 >
< ’he1 : Head | xPos : 2 # yPos : 3 >
< ’he10 : Head | xPos : 3 # yPos : 2 >
< ’he2 : Head | xPos : 2 # yPos : 3 >
< ’he3 : Head | xPos : 2 # yPos : 3 >
< ’he4 : Head | xPos : 2 # yPos : 3 >
< ’he5 : Head | xPos : 2 # yPos : 3 >
< ’he6 : Head | xPos : 2 # yPos : 3 >
< ’he7 : Head | xPos : 3 # yPos : 2 >
< ’he8 : Head | xPos : 3 # yPos : 2 >
< ’he9 : Head | xPos : 3 # yPos : 2 >
< ’p : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u #
’he6 # ’he5 # ’he4 # ’he3 # ’he2 # ’he1 # ’ha10 # ’ha9 # ’ha8 # ’ha7 # ’ha6 # ’ha5 #
’ha4 # ’ha3 # ’ha2} >
< ’t1 : Tray | parts : Sequence{ ’he10 # ’he9 # ’he8 # ’he7} # xPos : 3 # yPos : 2 #
capacity : 4 >
’Drop } ,
112
< ’he1 : Head | xPos : 2 # yPos : 3 >
< ’he10 : Head | xPos : 3 # yPos : 2 >
< ’he2 : Head | xPos : 2 # yPos : 3 >
< ’he3 : Head | xPos : 2 # yPos : 3 >
< ’he4 : Head | xPos : 2 # yPos : 3 >
< ’he5 : Head | xPos : 2 # yPos : 3 >
< ’he6 : Head | xPos : 2 # yPos : 3 >
< ’he7 : Head | xPos : 3 # yPos : 2 >
< ’he8 : Head | xPos : 3 # yPos : 2 >
< ’he9 : Head | xPos : 3 # yPos : 2 >
< ’p : Plant | els : Sequence{ ’heg # ’hag # ’c1 # ’c2 # ’t1 # ’a # ’c3 # ’t2 # ’u #
’he6 # ’he5 # ’he4 # ’he3 # ’he2 # ’he1 # ’ha10 # ’ha9 # ’ha8 # ’ha7 # ’ha6 # ’ha5 #
’ha4 # ’ha3 # ’ha2 # ’ha1} >
< ’t1 : Tray | parts : Sequence{ ’he10 # ’he9 # ’he8 # ’he7} # xPos : 3 # yPos : 2 #
capacity : 4 >
deadlock } )
A counterexample is a pair consisting of two lists of transitions, where the first corresponds
to a finite path beginning in the initial state, and the second describes a loop. This is because
if an LTL formula is not satisfied by a finite structure, it is always possible to find a counterexample for the formula having the form of a path of transitions followed by a cycle [42]. Each
transition is represented as a pair, consisting of a state and the label of the rule applied to reach
the next state.
6.3 Representing DSML’s Behavior with In-Place Model Transformation
Maude offers a comprehensive toolkit for performing simulation and analysis, efficient enough
to be of practical use, and easy to integrate with software development environments such as
Eclipse. However, one of its drawbacks is that it requires specialized knowledge and expertise, something that may hinder its usability by the average DSML designer. In MDE, where
models, metamodels and model transformations are the key artifacts, model transformations
6.3. R EPRESENTING DSML’ S B EHAVIOR WITH I N -P LACE M ODEL T RANSFORMATION113
that support in-place update seem to be the natural way to specify the dynamic behavior of
DSMLs. This kind of transformation allows users to describe the permitted actions of the system and how the model elements evolve as a result of these actions, allowing designers to work
with domain specific concepts and their concrete syntax for describing the rules [49]. In the
following, we will show that in-place model transformation represents an intuitive approach to
model the dynamic behavior of DSMLs by presenting some examples.
6.3.1 In-Place Model Transformation
An in-place model transformation is an endogenous model-to-model transformation where
source and target models are the same: this kind of model transformation does not create
new models but just modify the source ones. They are composed of a set of transformation
rules that typically represent the possible actions of the system. Such rules are of the form
l : [NAC]∗ × LHS → RHS, where l is the rule’s label (its name); and LHS (Left-Hand Side),
RHS (Right-Hand Side), and NAC (Negative Application Conditions) are model patterns that
represent certain (sub-)states of the system. The LHS and NAC patterns express the precondition for the rule to be applied, whereas the RHS one represents its postcondition, i.e., the
effect of the corresponding action. Thus, a rule can be applied, i.e., triggered, if an occurrence
(or match) of the LHS is found in the model and none of its NAC patterns occurs. Generally,
if several matches are found, one of them is non-deterministically selected and applied, producing a new model where the match is substituted by the appropriate instantiation of its RHS
pattern (the rule’s realization). The model transformation proceeds by applying the rules in a
non-deterministic order, until none is applicable—although this behavior can be modified by
some execution control mechanism (see Section 6.2.1 for some examples).
Figure 6.1: The GenHandle in-place rule.
Figure 6.1 shows an example of an in-place transformation rule specified with the e-Motions
114
tool (see Section 7.5). This tool allows users to use the graphical concrete syntax of the user’s
DSML for defining visual in-place transformation rules. The rule models the behavior of the
handle generators of the production system DSML, whose metamodel is depicted in Figure 3.2.
It can be applied if an occurrence of the LHS is found in the model. Then, the elements in the
LHS that do not appear in the RHS are deleted, whereas the elements in the RHS that do not
appear in the LHS are created. In the e-Motions tool, LHS and NAC rule patterns may include
conditions (see the WITH clause in the LHS of the rule in Figure 6.1) and RHS patterns may
include attribute computations. In this case, a handle can be generated if the handle generator’s
upper bound (i.e., its attribute counter) is different from zero. Then, if the rule is applied, the
value of the generator attribute counter is decreased and the position of the handle set to the
conveyor’s position. (OCL is fully supported in e-Motions [99].)
Figure 6.2: The Assemble in-place rule.
Another example of in-place rule is shown in Figure 6.2. This rule, named Assemble,
models the assembling of parts: if there is an assembler with a head and a handle in its in tray,
the rule will consume such a head and a handle and will put a hammer in its out conveyor. The
position of the hammer is set to the conveyor’s position.
In place-model transformation usually admits two different kinds of formalization, which
are taken from algebraic graph transformation [102]: Double Pushout (DPO) and Single Pushout
(SPO). From a practical point of view, their difference is that in DPO, deletion has no side effects. When an object is deleted by a rule, it can only be connected with other objects through
the links explicitly deleted by the rule. For example, if we try to apply the Assemble rule,
and ha is matched to a handle connected to more than one tray (should it be allowed by the
metamodel), then the rule cannot be applied with such a match as otherwise some links would
become dangling in the model. In SPO, dangling references are removed by the rewriting step.
Therefore in DPO, in addition to positive pre-conditions, a LHS also imposes implicit negative
6.3. R EPRESENTING DSML’ S B EHAVIOR WITH I N -P LACE M ODEL T RANSFORMATION115
pre-conditions in case the rule deletes some object. In the e-Motions tool, these formalizations
have been adapted to the tree-structure of EMF models:
• In EMF, links are not considered first class citizens: they are defined by means of references, which are object properties. Thus, in our formalization, we consider dangling
references only those that refer to a deleted element. Those references that belong to
a deleted element and that refer to any model object are not considered dangling, and
therefore they are always removed when its corresponding object is so (no matter if we
choose the DPO or SPO formalization).
• The tree-structure of EMF models is given by the containment relation between their
classes, and the deletion of a containment reference implies the deletion of all the elements it refers to. Therefore, when an object is deleted by a rule, all the contained
objects (by means of containment references) are removed too. This new situation has
impact over DPO and SPO formalizations: in DPO, when a rule specifies the deletion of
an object, it cannot be applied to a specific match if the deletion of the object and all of
its containing objects would result in dangling references; however, in SPO, the rule can
be applied in this situation and all the dangling references caused by the deletion of the
object and all of its containing objects are removed too.
Furthermore, we can usually identify two different kinds of matches: injective and noninjective. Injective matches are those on which each object of a pattern has to be matched with
a different object in the model, while non-injective matches are those in which two or more
objects with compatible classes in a pattern may be matched to a single object in the model. In
a non-injective match, e.g., of two pattern objects with one model object, if the rule specifies
that one of the pattern objects is deleted and the other one preserved, DPO forbids applying
such a rule to such a match, while SPO allows its application and deletes both objects.
6.3.2 In-Place Rules for the Production System DSML
Figure 6.3 shows the remaining in-place rules that define the behavior of the DSML for production systems. They model the same behavior that was specified with rewrite rules in Section 6.3.
Specifically, each in-place rule specifies the same behavior than the corresponding rewrite rule
with the same name. In this example, we consider SPO formalization and injective matches.
Similarly to Maude, the e-Motions tool allows pattern objects to be assigned an abstract
class (see, e.g., the Transfer rule). Of course, no object with an abstract class, such as Part, can
116
Figure 6.3: Further in-place rules of the production system DSML.
be found in the models, but the abstract pattern object in the rule can get instantiated to objects
of any concrete subtype [47] (namely Head, Handle or Hammer). In addition, in e-Motions
6.4. B EHAVIORAL S EMANTIC M APPINGS AND T OOL S UPPORT
117
links can be assigned a natural number to represent the position of the target element in the
collection of object reference values owned by the source element. For instance, the Transfer
rule specifies that if there are parts in a conveyor (at least one), the first one will be placed in
its out tray provided that there is enough space in it.
6.4
Behavioral Semantic Mappings and Tool Support
After the discussion in the previous sections, we can note the similarity between the two approaches presented to specify the behavior of DSMLs: in-place transformation rules can be
naturally formalized as rewrite rules. Thus, to take advantage of both worlds, we have defined
a mapping from in-place model transformation to the Maude semantic domain. This allows us
to specify the dynamic behavior of a DSML in a graphical and intuitive way, and conduct simulation and reachability and model-checking analysis using the tools and techniques already
available for Maude as explained in Section 6.2.
As part of this work we have integrated Maude with the e-Motions [100, 99, 107] and
AToM3 [124, 48, 102] tools. We want users to benefit from Maude simulation and analysis
capabilities, but working with their favorite notation and tools.
The e-Motions tool is a language and graphical framework developed for Eclipse that supports the specification of graphical in-place model transformation rules. Moreover, it extends
in-place model transformation with a model of time and a mechanism to state action properties.
The language, the tool and the semantic mappings defined from its behavioral specification to
Maude are presented in the next chapter.
AToM3 is a tool for multi-paradigm modeling based on graph grammars [111]. With
AToM3 , we can specify the behavior of our DSML by means of graphical graph transformation
rules [57]. In collaboration with Juan De Lara and Esther Guerra, we have built a Maude parser
and code generator, and integrated them in the AToM3 tool. Thus, AToM3 is now provided with
the analysis capabilities of Maude, and, on the other hand, it can be used as a visual front-end
for Maude.
The code generator synthesizes Maude specifications from the DSML’s metamodel, the
graph transformation rules describing its behavior and its models. Properties to be checked
using reachability analysis can be specified by means of graph constraints [57, 65], which constitute a graphical and formal way to specify model properties. We use graph constraints to
specify the search pattern when performing reachability analysis in Maude. The result of a
reachability analysis is parsed and presented back in the AToM3 tool in terms of the origi-
118
nal DSML, thus hiding the formal methods used for the analysis. Further visual support for
defining model checking predicates and showing model execution paths are future work.
Figure 6.4: Reachability analysis with the AToM3 tool.
Figure 6.4 shows the state of the AToM3 environment for a DSML similar to the production
system DSML presented in Section 3.2. The initial model is shown in the main window. The
lower three buttons on the left side of the main window allow, respectively, simulating the
model using the graph transformation rules, performing reachability analysis, and generating
plain Maude code, so that for example model checking can be performed. The window in
the middle shows a screenshot during the specification of the reachability analysis, and the
right-most window shows the specification of a graphical constraint.
The way we encode the DSML’s metamodel, the graph transformation rules describing its
behavior, and the models from AToM3 to Maude are presented in [102]. We do not introduce
them here because of its similarity with the semantic mappings that we have defined from the
e-Motions tool to Maude, which will be presented in the next chapter.
6.5
Related Work
One way to specify the semantics of a language is to define a translation from expressions
in that language into expressions in another language with well defined semantics (cf, e.g.,
[66]). These semantic mappings between semantic domains are very useful, not only to provide
6.5. R ELATED W ORK
119
metamodels with semantics, but also to be able to simulate, analyze or reason about them using
the logical and semantical framework available in the target domain (in general, each semantic
domain is more appropriate to represent and reason about certain properties, and to conduct
certain kinds of analyses).
The most common formalization of graph transformation is the so-called algebraic approach, which uses category theory to express the rewriting [57]. This approach supports a
number of interesting analysis techniques, such as detecting rule dependencies [57] or calculating critical pairs (minimal context of pairs of conflicting rules) [67]—usually with simple
type graphs [47].
However, graph transformation offers limited support for other kinds of analyses, such as
reachability analysis, model checking, etc. This is why some authors define semantic mappings
between graph transformation and other semantic domains, and then back-annotate the analysis
results to the source notation [34, 48, 49, 67]. This possibility allows one to use the techniques
specific to the target semantic domain for analyzing the source models. For example, in [16]
rules are translated into Alloy in order to study the applicability of sequences of rules and the
reachability of models; in [15] rules are translated into Petri nets to check safety properties;
in [125] they are transformed into Transition Systems (TS) for model-checking; and in [33,
34] rules are transformed into OCL pre- and postconditions for rule analysis (e.g., conflict
detection) using standard OCL tools.
One of the problems of these approaches is due to the fact that they require, from the DSML
designer, deep knowledge of the target language in order to specify the transformations. However, this problem can be partially overcome if the transformations are automated, using, e.g.,
model transformation techniques. For example, in [49] the authors are able to generate the
transformations from rule-based Domain-Specific Visual Languages (DSVLs) into semantic
domains with an explicit notion of transition, such as Place-Transition Petri Nets. The generated transformation is expressed in the form of operational triple graph grammar rules that
transform the static information (initial model) and the dynamics (source rules and their execution control structure). Similarly, in [34] the authors describe how graph transformation rules
can be mapped into OCL pre- and postconditions for rule analysis. However, as the authors
describe in their paper, not all kinds of graph transformations can be automatically transformed
into OCL, and the analyses that can be conducted are somehow limited.
Another problem of these approaches is that they are usually restricted in the kind of graphs
and attributes they can handle, so they cannot deal with, e.g., some DSMLs that can be defined
with Ecore. For instance, the work of [125] does not allow unbounded attributes in metamodel
120
elements, and the Groove tool [97], a tool that incorporates a built-in explicit model checker
for graph transformation systems, works with simple graphs with edge labels, i.e., it cannot
analyze models that have multiple edges between the same two nodes.
The use of Maude as a semantic domain in which DSMLs can be mapped has enabled the
use of more powerful analysis on the source models. First, Maude we can deal with more
complex structural and behavioral specifications (i.e., not limited to place/transition systems);
and second, it offers an integrated environment and a toolkit for conducting different kinds of
analysis, such as reachability and model checking analysis, so we do not need to define several
semantic mappings to different domains to perform each of them.
Other approaches use UML behavioral models to represent system dynamics. For example,
in [60] operational semantics are represented using UML collaboration diagrams, which are
then formalized into graph transformation rules. In [61], Story Diagrams are presented as a
new graph rewrite language based on UML and Java. More precisely, the authors propose
the use of UML together with pieces of Java code to express a graph rewrite language mixed
with object-oriented data concepts. The whole specification (including dynamic behavior) is
then transformed into Java classes and methods, although not all kinds of story patterns can be
translated automatically. Again, the kind of analysis is limited in these approaches, and they
do not use the concrete syntax of the DSML, but an object diagram-like structure.
Other works propose model transformation languages to specify the behavioral semantics
of DSMLs. For example, in [79], QVT is proposed to specify the semantics of OCL, but analysis capabilities are not provided. The MOMENT-QVT tool [24] is a model transformation
engine that provides partial support for the QVT Relations language. The behavioral specifications are also transformed into Maude in order to perform reachability and model checking
analysis. These specifications, as well as the properties to be analyzed, are expressed in a textual fashion (by means of QVT rules and model patterns, and boolean OCL expressions). This
proposal does not support the use of the graphical concrete syntax of his/her DSML to express
them in a more intuitive way.
Kermeta [86] is an extension of EMOF (part of the MOF 2.0 specification) for specifying
operational semantics. It enriches the EMOF metamodel with an action specification metamodel, introducing another new language to express specifications of algorithms. Simulation
and execution possibilities are available for this approach.
Di Ruscio et al. [113] presents an approach for specifying dynamic semantics of Domain
Specific Languages in the context of MDE. In particular, they extend KM3 [21] (a textual
language for describing metamodels) with the Abstract State Machines (ASM) formalism to
6.5. R ELATED W ORK
121
specify its dynamic behavior. Simulation and analysis capabilities are not provided although,
as the authors point out, it could be possible to use other existing ASM tools for that purpose.
Another interesting approach for defining semantic mappings in order to specify the behavioral semantics of a language is the semantic anchoring method developed at the Vanderbilt
University [37]. Semantic anchoring relies on the use of well-defined “semantic units” of simple, well-understood constructs and on the use of model transformations that map higher level
modeling constructs into configured semantic units. The approach uses UML Class Diagrams
and OCL to represent the structure of a DSML, and ASM as the semantic framework. In particular, the structural specifications are transformed into ASM to make use of the Abstract State
Machine Language (AsmL) and associated tools for enabling the programming, simulating and
model checking of ASM models [37]. One of the drawbacks of this approach is that it requires
specialized knowledge and expertise on the ASM formalism and AsmL tools, since behavior
and analysis are specified directly in this formalism.
122
Chapter 7
Real-Time Behavioral Semantics of
DSMLs
In-place model transformation provides an intuitive way to represent the dynamic behavior of
DSMLs, especially when it enables the use of the graphical concrete syntax of the language.
However, in its basic form, it cannot deal with time-dependent behavior, hampering, e.g., the
modeling of real-time DSMLs. Furthermore, current approaches do not allow users to model
action-based properties, lacking enough expressive power and forcing unnatural changes to
the system specification. In this chapter, we present a language 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 Rewriting Logic (RL) by means of model
transformation. 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 semantic mappings and the behavioral semantic model of his/her DSML.
Furthermore, these semantic mappings allow us to specify real-time DSMLs’ behavior in a
graphical and intuitive way (using the e-Motions tool), and perform simulation and reachability and model-checking analysis on the models using some of the tools and techniques that
Maude provides.
7.1 Motivation
In critical systems, such as real-time and embedded systems, timeouts, timing constraints and
delays are essential concepts. Therefore, these concepts should be modeled in their behavioral
specification to enable proper analysis and simulation. In-place model transformation (in their
123
124
C HAPTER 7. R EAL -T IME B EHAVIORAL S EMANTICS OF DSML S
basic form) are not provided with 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 forces designers to modify the DSML’s
metamodel (the structural model of the DSML) to include time aspects (which are related to
behavioral aspects). Furthermore, this does not constrain designers from unwillingly defining
time-inconsistent sequences of states.
Furthermore, current 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 states of the actions that should be observed. The need for action-based specifications
has been recently acknowledged, showing that this kind of specifications are more natural and
expressive in many different situations [84].
In this chapter, we present e-Motions, a DSML that extends in-place model transformation
with a model of time and a mechanism to state action properties, easing the specification of
real-time DSMLs’ behavior. Our approach tries to allow users to focus on the complexity of the
system instead of focusing on the complexity of the specification of time and actions properties. Furthermore, it avoids unnaturally modifying 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. This promotes separation of concerns. We provide e-Motions
with semantics by defining a semantic mapping (by means of model transformation) to rewriting logic in Maude. As we discussed in the case of untimed specifications in Chapter 6, the
use of Maude as a target semantic domain brings very interesting benefits, because it enables,
e.g., simulation of the real-time specifications and the conduction of reachability analysis and
model checking.
7.2 The e-Motions Language
Figure 7.1 shows the e-Motions metamodel, which describes the main concepts of our approach
to model time-dependent behavior.
In e-Motions, the behavior of a DSML is specified by a set of in-place rules and an optional
set of helpers. We differentiate between two types of in-place rules to specify time-dependent
behavior, namely atomic and ongoing rules. Atomic rules represent atomic actions with a
specific duration, while ongoing rules represent actions that progress continuously with time.
Atomic rules can be periodic. Atomic and ongoing rules can be scheduled or be given an
execution interval by rules’ lower and upper bounds. We also distinguish between normal
7.2. T HE e-Motions L ANGUAGE
125
Figure 7.1: The e-Motions metamodel.
rules, which are triggered as soon as possible, and soft rules, which are not necessarily triggered
immediately but in a non-deterministic moment in time in the near future. Helpers, expressed
as OCL operations, are library functions which are useful for specifying some of the rule
parameters or object attributes. They can be used throughout the behavioral specifications.
Rules are composed of patterns (one LHS, one RHS and zero or more NACs) and an optional set of variable definitions. The context of a variable is the rule in which it is defined, and
their values are computed (only once) when the rule is triggered. Rule patterns may contain
objects, links and action execution elements (see the ActionExec metaclass), which represent
action occurrences. LHS and NAC patterns may also include conditions. Objects can be com-
126
posed of slots (structural feature-value pairs). When an object is placed in a LHS or NAC
pattern, its slots represent attribute conditions. When an object is placed in a RHS pattern, its
slots represent attribute computations. Slot values and conditions are specified with OCL expressions. We include a special kind of object, named Clock, that represents the current global
time elapse.
We consider discrete and dense time [89], injective rules, and the two main formalizations
of algebraic graph transformation: Double Pushout (DPO) and Single Pushout (SPO), although
adapted to the tree-structure of EMF models (see below). We also consider the graphical concrete syntax of the DSML in the specification of the visual rules (MetamodelGD and ClassGD
metaclasses are defined for this purpose, see Section 7.5).
The following subsections describe the main concepts of our approach with more detail on
an example describing a modeling language for mobile phone networks.
7.2.1 A DSML for Mobile Phone Networks
Let us introduce a simple modeling language for mobile phone networks (MPNs), which will
serve as the motivating example to show the expresiveness of our approach to specify timeddependent behavior. This subsection focuses on the structural parts of the language; next subsections will focus on its behavioral aspects.
Figure 7.2: A metamodel for MPNs.
The MPN metamodel is shown in Figure 7.2. An MPN has cell phones and antennas.
Antennas provide coverage to cell phones, depending on their relative distance. Phones and
antennas have a position (they are positioned elements). A cell phone is identified by its number, and can perform calls to other phones of its contact list. Dialed and received calls are
127
registered. Phone’s attribute bps represents the battery consumption per time unit, and vx and
vy define its velocity vector.
Figure 7.3: A concrete syntax for the MPN language.
Figure 7.3 shows a simple visual concrete syntax for our DSML for MPNs. In e-Motions,
we can associate every metamodel class with a picture (see Section 7.5). This concrete syntax
will be used in next subsections for the definition of the behavioral rules.
Figure 7.4: A mobile phone network model.
Figure 7.4 represents a MPN model example. This model consists of a mobile phone network composed of four cell phones and two antennas. Phones consume one battery unit per
time unit (i.e., their bps attribute value is set to 1), are initially off, and have all the other phones
in their contact list. In this model, we have represented a phone’s velocity vector with an arrow
associated to the phone: phone 444 has a left arrow that represents a (-1,0) vector, phone 111
has a right arrow that represents a (1,0) vector, phone 333 has an up arrow that represents a
(0,1) vector, and phone 222 has a down arrow that represents a (0,-1) vector.
Once we have specified a metamodel for MPNs, we can complement it with in-place model
transformation rules to describe the dynamic behavior of the language. In the specification of
the behavior rules for this example, we will consider discrete time and a SPO formalization
(see Section 6.3.1).
128
7.2.2 A Model of Time
In this subsection we show how time-related attributes can be added to rules to represent features like duration, periodicity, etc. We identify two types of rules to specify time-dependent
behavior, namely atomic and ongoing rules, and we include a special kind of object, Clock,
that represents the current global time elapse.
7.2.2.1
Atomic Rules
One natural way to model time-dependent behavior quantitatively consists in decorating the
rules with the time they consume, i.e., by assigning to each action the time it takes. Thus, we
[t,t′ ]
define atomic rules as in-place transformation rules of the form l : [NAC]∗ × LHS → RHS,
where [t, t′ ] expresses the duration interval of the action modeled by the rule, i.e., the minimum
and the maximum amount of time needed to perform the action.
As normal in-place transformation rules, an atomic rule can be triggered whenever an occurrence (or match) of its LHS, and none of its NAC patterns, is found in the model. Then, the
action specified by such rule is scheduled to be realized between t and t′ time units later. At
that time, the rule is applied by substituting the match by its RHS and performing the attribute
computations.
Since actions have now a duration, elements can be engaged in several actions at the same
time. The triggering of an atomic rule is only forbidden if another occurrence of the same rule
is already being executed with the same participants,1 to avoid non-terminating executions.
Note that the states of the elements that participate in a timed action may vary during the
action’s time elapse, since the states of the elements may be modified by other actions. The
only condition for the final application of an atomic rule is that the elements involved are still
there; otherwise the action will be aborted. If we want to make sure that something happens
(or does not happen) during the execution of an action, we can make use of action execution
elements to model the corresponding exceptional behavior (see below).
As an example, Figure 7.5 shows the SwitchOn atomic rule. When a phone is off and has
enough battery, it is switched on in five time units. More precisely, if a phone p which is off
and has more than five times bps battery units is found in the model, after five units of time it
is switched on and its battery decreased five times bps battery units, whenever p still remains
in the model; otherwise, the action is simply aborted. Note that, in this case, the minimal
1
We call participants of a rule to those objects and ActionExec elements that instantiate the rule’s LHS
pattern.
129
Figure 7.5: The SwitchOn atomic rule.
and maximal duration of the rule coincide, so the rule duration is deterministic. The attribute
computation p.battery - 5 * p.bps is performed at the moment of the finalization of the rule, and
therefore property values (p.batery and p.bps) are accessed at this moment of time (but previous
to any computation performed by the RHS pattern). If the value of the properties at the moment
of the triggering of the rule were needed, variables could be used (see Section 7.2.3).
Instantaneous rules. Atomic rules extend in-place transformation rules with the time they
consume. Therefore, standard in-place rules can be modeled as atomic rules with no duration.
We named this kind of rules instantaneous rules, and they are modeled with atomic rules
which take zero time units. No other action may occur during the execution of this kind of
actions.
Figure 7.6: The BatteryOff instantaneous rule.
The BatteryOff rule, which is depicted in Figure 7.6, is an example of instantaneous rule:
whenever a phone p that is on and has no battery, it is switched off.
130
Rule execution modes.
We distinguish normal rules, which are triggered as soon as possi-
ble, from soft rules, which are not necessarily triggered immediately, but in a non-deterministic
moment in time in the near future (e.g., next time the clock is stopped because some event happens). Contrary to normal rules, soft rules are not forced to be applied whenever its LHS
pattern (and none of the NACs) occurs in the model.
The SwitchOn action in Figure 7.5 is modeled by a soft rule (notice the soft label in the
rule’s header): we allow phones to be switched on at a non-deterministic moment in time.
However, the BatteryOff action in Figure 7.6 is modeled by a normal (non-soft) rule: mobile
phones must go off as soon as they run out of battery.
The e-Motions language also supports the definition of scheduled actions, which are actions that are tried to be triggered at a specific moment in time (and only at that moment in
time). This kind of actions will be actually triggered if their preconditions hold at that moment
of time, i.e., if an occurrence of their LHS, and none of their NAC patterns, is found in the
model. They are modeled by normal (non-soft) atomic rules whose lower and upper bounds
(lowerBound and upperBound attributes, see Figure 7.1) coincide with the moment in time at
which the rules are scheduled.
Figure 7.7: The RemoveOffPhones scheduled rule.
The RemoveOffPhones rule, which is depicted in Figure 7.7, is an example of scheduled
rule: we plan to remove from the system all the phones that are off at the moment of time 150
(notice this value specified as the rule’s lower and upper bounds between the square brackets
in the right-hand side of the header of the rule).
These rule execution modes are also applicable to ongoing rules.
Periodicity. Another essential aspect for modeling time-dependent behavior is periodicity.
Atomic rules admit a parameter that specifies the period of an action. We distinguish between
131
normal periodic rules and soft periodic rules: both kinds of rules are triggered as soon as
possible, but normal periodic rules can only be triggered at the beginning of the period—if
they cannot be triggered at that moment of time they will not be enable until the next period—,
while soft periodic rules can be triggered at any time within the period—if they cannot be
triggered at the beginning of the period they will be tried to be triggered at any other time
within the period (but only once per period).
Figure 7.8: The Coverage periodic rule.
Figure 7.8 shows the Coverage atomic periodic rule, which specifies the way in which
antenna coverage changes. Coverage is updated every five time units (notice the loop icon in
the header of the Coverage rule). Each cell phone is covered by its closest antenna: as specified
in its NAC pattern, the rule cannot be applied if there exists another antenna closer to the phone.
Figure 7.9: The distance helper.
To compute the distance between an antenna and a phone, we have defined the distance
helper (see Figure 7.9). A helper is defined as an OCL operation. Helper invocations in LHS
and NAC patterns are computed at the triggering of actions, while helper invocations in RHS
patterns are computed at their realization. Thus, note that the distance between the antenna and
the phone may vary on these two different moments of time. If the same value were needed, a
variable could be used (see below).
The e-Motions tool is designed to provide useful predefined helpers. For instance, it currently supports, by means of the emotions.random(b : Int) : Int helper, the generation of a
pseudo-random number between zero and the given bound b.
132
7.2.2.2
Ongoing Rules
In addition to atomic rules, e-Motions also provides rules to model actions that are continuously
progressing and require to be continuously updated. Think for instance of an action that models the consumption of a phone battery, whose level decreases continuously with time. This
property must be always updated, since most rules (such as SwitchOn and BatteryOff) depend
on its value.
Ongoing rules model this kind of behavior. They are used to model actions that a) do not
have a priori duration time—they progress with time while the rule preconditions (LHS and
NACs) hold, or until the time limit (maxDuration) of the action is reached—and b) are required
to be continuously updated— their effects are always computed before the triggering of any
atomic rule.
Figure 7.10: The BatteryConsumptionRule ongoing rule.
For example, Figure 7.10 shows the BatteryConsumption ongoing rule, which models
phone battery consumption (note the use of the purple background for the arrow in the rule
to distinguish ongoing actions from atomic ones, on the blue background). According to this
rule, the battery power is decreased bps battery units per time unit. To explicitly identify the
state in which a phone runs out of battery, and not to decrease the battery power below zero,
we limit the duration of the rule (see the expression on the right-hand side of symbol ≤). Since
the effects of ongoing actions are always realized before the triggering of atomic rules, phone
batteries will always be updated whenever an atomic rule is tried to be triggered.
Phones moving can also be modeled by an ongoing rule, which is shown in Figure 7.11.
In this case, the position of each phone will be updated according to its velocity vector and
time elapse. We suppose that phones can only move inside the limits of the MPN they belong
to, and therefore positions and velocity vector are always corrected according to these limits,
which are given by xSize and ySize MPN’s attributes. Notice that the Moving rule has no
133
Figure 7.11: The Moving ongoing rule.
maximum duration, that means that phones will keep moving for ever. The correctPos and
correctV helpers, shown in Figure 7.12, are defined for this purpose.
Figure 7.12: The correctPos, correctV and power helpers.
Note that, by using ongoing rules, we have modeled battery consumption and phone movement separately from the other behavior rules, avoiding concern tangling. Even if the battery
consumption or phones moving would depend on the execution of other actions, we could
define their behavior in a separate way by using action executions, as we shall see below.
Atomic rules versus ongoing rules.
Our approach provides two different kind of rules: on-
going and atomic. These two types of rules are provided to model different kind of actions.
Of course, we could try to model ongoing actions using periodic atomic actions, by somehow
“discretizing” them and using the minimum time elapse as the period (e.g., one time unit).
However, this solution becomes quite inefficient in a simulation (or analysis) scope: the rule
would be applied at every time unit. Furthermore, if the rule is used to model a property that
must be updated at every time moment, we should explicitly force the rule to be executed at
every time unit before the triggering of any other rule, complicating the design of the rule by introducing some control mechanisms. As we shall see in Section 7.3, ongoing rules are updated
134
according to time elapse as needed, and previously to the triggering of any atomic rule.
Moreover, ongoing rules can hardly model some atomic actions. In the best case, we could
modify the DSML’s metamodel to include some kind of timer that represent a countdown to
the finalization of the atomic action, together with some links to gather the information about
the rule instantiation. The idea would be then to use three ongoing rules per each atomic action: an initial rule that set two different timers t1 and t2 to the minimal and maximal duration
of the action, respectively; another rule that decreases the timers; and a third rule that checks
whether t1 has been consumed and t2 has not been so, and if so substitutes the corresponding
match by its RHS. However, this approach has several drawbacks: a) it does not have exactly
the same semantics as a single atomic rule (if the same semantics were required, more control mechanisms need to be included); b) it cannot model instantaneous rules (ongoing rules
progress with time, and they require time to elapse to be executed); and c) this mechanism
would imply breaking our principle of separation of concerns, since we have to modify the
DSML’s metamodel to include action properties.
Therefore, we strongly recommend the use of both kinds of rules (atomic and ongoing)
were needed, avoiding the artificial (and probably incorrect) design of actions by using only
one kind of rule.
7.2.2.3
Global Time Elapse
We provide a special kind of object, named Clock, that represents the current global time elapse.
A unique and read-only Clock instance is provided by the system (i.e., it does not need to
be created by the user) to model time elapse through the underlying platform. This allows
designers to use the Clock in their timed rules to get the current time (using its attribute time)
to model, e.g., time stamps (as we shall see later on with the Call rule). Provided that the clock
behavior cannot be modified, users cannot drive the system to time-inconsistent sequences of
states (even unwillingly).2
7.2.3 Action Statements
In in-place model transformation approaches, LHS, RHS, and NAC patterns are defined in
terms of system states. This is a strong limitation in those situations in which we need to
2
Of course, users can define their own clocks to model other aspects of distributed systems (such as distributed
clocks) and specify how they individually evolve. In this case, the user is responsible for the correct modeling and
use of these clocks.
135
refer to actions currently under execution, or to those that have been executed in the past. For
example, we can be interested in knowing whether an object is currently performing a given
action to take some decision, e.g., to interrupt the action (e.g., in case an exception occurs),
or not to allow the object to perform another action. We can also be interested in reasoning
about the performed actions so far (e.g., to be able to search for undesirable action occurrences
or invalid sequences of action executions). Note that a given system state may usually be
reached by performing different sequences of actions, and checking only system states will not
always give us information about the performed actions. In general, the inability of modeling
and dealing with action occurrences hinders the specification of some useful action properties,
unless some unnatural changes are introduced in the system model—such as extending the
system state (i.e., the metamodel of the DSML) with information about the actions currently
happening.
In order to be able to model both state-based and action-based properties, we propose extending model patterns with action executions to specify action occurrences. These action
executions will contain information on the type of the action (given by the name of the atomic
rule that represents the action); its status, i.e., if the action is unfinished, realized, interrupted or
aborted (see below); and its identifier. They may also specify its starting and ending time—the
latter one can only be specified for non-unfinished actions—, its execution time, and the set of
participants involved in it. These participants are specified by object mappings, which are sets
of pairs (o → r). Each pair identifies the object that participates in the action (o) and one of the
roles it plays in the rule (r). For instance, the Call rule in Figure 7.13 defines five roles: two
phones (p1 and p2), the clock instance (cl), and two call records (c1 and c2), which correspond
to the identifiers of the elements placed in LHS and RHS patterns. When using action execution in patterns, we can also leave unspecified the type of the rule and the role of an object to
represent whatever rule instantiation or object role, respectively.
Action executions whose status is unfinished refer to actions that are currently happening,
i.e., actions which have been triggered but its duration time has not been consumed yet. Action
executions whose status is realized refer to actions that were already performed (i.e., the effects
specified in their RHS were already applied). Action executions whose status is interrupted refer to actions that were triggered but not realized because their corresponding action executions
were deleted by a rule explicitly modeled by the user for that purpose (see below). And finally,
action executions whose status is aborted refer to actions that were triggered but not realized
because any of its participants were removed from the system before the duration time of the
action was consumed, i.e., actions that were automatically discarded because they could not be
136
completed.
7.2.3.1
Concurrency
Atomic rules have a duration, and they can be applied whenever an occurrence of the LHS
pattern and none of the NAC patterns are found in the model. Therefore, elements can be
engaged in several actions at the same time. This is very useful for modeling realistic situations
in a natural way, e.g., a phone can be involved in a talk while its coverage is being updated, its
battery decreased, and it is receiving a message. As we previously mentioned, the triggering
of an atomic rule is only forbidden if another occurrence of the same rule is already executing
with the same participants. However, there are some situations on which we want to forbid (or
enforce) the execution of a rule if one of its participants is already performing the same action
with different participants, or simply one of its participants is performing any other action.
Figure 7.13: The Call atomic rule.
As an example, Figure 7.13 shows the Call atomic rule, which models the behavior of a
call from a cell phone to one of its contacts. To make a call, both phones must be on and have
coverage. Furthermore, we do not allow call waiting: we want to forbid the execution of the
rule whenever one of the phones (p1 or p2) is participating in another call. For this purpose,
we make use of action executions in NAC patterns. These action executions explicitly specify
that phone p1 and p2 are currently participating (notice the unfinished status label in the action
execution’s header) in a Call action. Note that there is no role specified for p1 nor for p2 in
the action execution, and therefore it refers to any instantiation of the Call rule where p1 or p2
is participating, no matter if the phone is the caller or the callee. For the same reason, since
137
no other participant is specified in the action execution, it refers to any instantiation of the Call
rule independently of the remaining participants, i.e., no matter if p1 (or p2, respectively) is in
a Call with p2 (or p1, respectively) or with any other phone.
At the end of the talk, the call is registered in both phones (as a dialed call in phone p1
and as a received call in phone p23 ) including the duration of the call (T) and its starting time
(initTime). Note that T refers to the duration of the current rule execution, which will vary
between 20 and 30 time units. The starting time of the call is computed by using the clock
instance together with a variable. Variables are computed when the rule in which they are
defined is triggered, and they can be used in all the patterns (LHS, RHS and NACs) defined for
the rule. In this case, we use the initTime variable to store the value of the clock at the moment
of the triggering of the rule, and then assign it to the startingTime attribute of the call records
at the moment of the finalization of the rule.
7.2.3.2
Separation of Concerns
Ongoing rules usually model system properties that must be continuously updated. However,
the updating of these properties can also depend on the realization of other actions of the
system. Think for instance on battery consumption, which could be greater while we are
engaged in a call; or the position of the phones: some people stop moving when they are
in a talk; etc. As a first attempt, the user can try to include the adjustment of these system
properties in every atomic rule that interferes with them. However, the properties will not be
properly updated until the actions are completely performed, and therefore it can lead to some
inconsistent states in the meantime. Thus, the best way to do this is by using ongoing rules
together with action executions to model separately the continuous updating of this kind of
properties.
As an example, let us revisit the modeling of the battery consumption, and let us replace the
rule in Figure 7.10 with the following rules. Figure 7.14 shows the TalkingBatteryConsumption
and StandbyBatteryConsumption ongoing rules, which models the battery consumption while
phone p is involved in a Call action and when it is not, respectively. Since a phone consumes
more battery when it is participating in a call, we will duplicate (two times bps battery units
per time unit) its battery consumption. Note that ongoing actions are always updated before
3
Although the e-Motions tool does not show in its diagrams the type of the links, every link is associated
with a specific reference (EReference) defined in the metamodel of the DSML for which we are specifying its
behavior. In this example, the links between the p1 and p2 phones and their corresponding call records c1 and
c2 refer to the dialedCalls and receivedCalls references of the MPN metamodel, respectively.
138
Figure 7.14: The TalkingBatteryConsumption and StandbyBatteryConsumption ongoing rules.
the triggering of any atomic rule, and therefore these two rules will never be executing at the
same time for the same phone.
7.2.3.3
Past Actions
There are some situations in which the triggering of an action may depend on the previous
realization (or not) of another action. For instance, there are actions that must be realized just
once; some others can only be triggered after the realization of another action (e.g., a sequence
of action must be somehow enforced); etc. Reasoning about past actions usually allows us to
take better decisions about future actions. Thus, action execution can also refer to past actions.
Figure 7.15 shows the InitialModel rule, which creates the initial configuration of the system.
In particular, it creates all the model objects specified in Figure 7.4. The NotExecutedBefore
NAC pattern forbids the triggering of the rule if it was already performed before (note the
realized status label in the action execution’s header), independently of its participants. No
other condition is required: the LHS pattern is empty, and therefore it is always fulfilled.
Note that this mechanism allows us to create models conforming to our DSML’s metamodel, which is specially relevant when our DSML is not supported by a more sophisticated
graphical concrete syntax.
139
Figure 7.15: The InitialModel instantaneous rule.
7.2.3.4
Exceptions in Actions
Atomic rules are realized at a non-deterministic moment of time between t and t′ time units
after its triggering, where t and t′ represent its duration interval of time. The only condition
for their final application is that the elements involved are still there; otherwise the action will
be aborted. Nothing is assumed about what happens while the action is being executed: if
we want to make sure that something happens or does not happen, we can make use of action
execution elements to model the corresponding exceptional behavior. In particular, we can add
new rules that model action interruptions by deleting their corresponding action executions,
i.e., by including them in a rule’s LHS pattern but not in its RHS pattern. Their effects will be
then defined in the rule’s RHS pattern.
Consider, for instance, the BatteryOffCaller atomic rule in Figure 7.16, which models the
behavior of a caller phone when it runs out of battery in the middle of a conversation. The
instantaneous rule is triggered whenever two phones p1 and p2 are participating in a Call action,
and the caller phone p1 has no battery. In this case, the Call action is interrupted, the call
registered in both phones, an the caller phone p1 is switched off. Note the use of object roles
140
Figure 7.16: The BatteryOffCaller instantaneous rule.
in the action execution element to identify the caller and the callee phones (i.e., the roles that
p1 and p2 play in the Call action), which allow us to properly register the call: as a dialled call
for the caller phone p1, and as a received call for the callee phone p2.
Figure 7.17: The BatteryOffCallee instantaneous rule.
Analogously, the BatteryOffCallee atomic rule shown in Figure 7.16 models the behavior
of a callee phone when it runs out of battery in the middle of a conversation.
Note that the BatteryOffCaller and BatteryOffCallee rules consider that a phone runs out
of battery in the middle of a talk to switch off the phone and record the call. However, as
141
Figure 7.18: The BatteryOff instantaneous rule (revisited).
currently modeled, the BatteryOff rule could be applied instead, and the call would not be
registered. Therefore, we modify the BatteryOff rule to forbid its application whenever the
phone p is participating in a Call action. The resulting BatteryOff rule is shown in Figure 7.18.
Finally, note that it only makes sense to interrupt actions that are currently happening. We
do not allow to “delete” (include in the LHS pattern and not in the RHS one) action executions
whose status is other than unfinished. Note also that action executions placed in a rule’s LHS
(or RHS) pattern become also participants in the rule when it is executed. Therefore, in the
same way in which atomic rules are aborted when any of its participant objects is removed
from the system before their duration time is consumed, they will be aborted when any of its
participant action executions is removed (by explicit deletion or because the action is realized)
as well. This means that if an action execution in a LHS pattern refers to an unfinished action, the referred action must be still unfinished at the moment of the finalization of the rule,
otherwise the rule application will be aborted.4 This has to be taken into account only for
action executions that refer to unfinished actions, since the status of finished actions (whether
realized, interrupted or aborted) will never change, and they cannot be interrupted.
The deletion of action executions is included in our proposal to model the interruption
of actions in an intuitive way. However, action executions are not defined to handle them as
common model objects. For instance, we cannot force the triggering of an action by creating an
action execution (by including it in a RHS pattern and not in its corresponding LHS pattern).
We only allow rules to be triggered when a match of its LHS pattern (and none of its NAC
patterns) is found in the model. In the same way, we do not allow users to explicitly modify
any of the action execution properties by modeling the corresponding behavior in a rule. Action
execution elements are included in our approach only for (a) reasoning about the existence of
4
Action interruptions should be modeled as instantaneous rules to avoid this situation.
142
(past or present) action occurrences, and (b) interrupting actions in the way we have described
in this section.
7.2.4 A Simple Round-Trip Time Protocol
Once we have shown the expressiveness of the e-Motions language by presenting a DSML for
MPNs, let us introduce another example of a real-time DSML that will be used in Section 7.4
to show the kind if real-time analysis we can perform over real-time systems: a language to
model a simple Round-Trip Time Protocol (RTTP).
Round-Trip Time (RTT), also called round-trip delay, is the time required for a signal pulse
or packet in a network to travel from a specific source to a specific destination and back again.
In our context, a RTTP may be composed of several rounds. In a single round, every node
will send a message to each of its neighbors. This message will contain the initiator node, the
responder node, and the time at which the message was sent (i.e., the request time). Once a
responder receives a message, it retransmits it back to the initiator node. When the initiator
node gets the response message, it computes the round-trip time by using its local clock, and
stores the result together with the response message. Figure 7.19 shows a metamodel for this
simple RTTP.
Figure 7.19: A metamodel for a simple RTTP.
Figure 7.20: A concrete syntax for the RTTP language.
The visual concrete syntax we have defined for the RTTP example is shown in Figure 7.20.
143
In the following, we will use this visual concrete syntax to define the timed rules that model
the dynamic behavior of the language.
Figure 7.21: The Request periodic rule.
Figure 7.21 shows the Request periodic rule. Notice the link from the n2 node to the
message in the RHS pattern, modeling that the message has arrived to its destination. This rule
models the sending of a message m from a node n1 to one of its neighbors n2. This action
takes between 5 and 20 time units. The message includes information about the initiator n1,
the responder n2, and the time at which the message was originally sent (the requestTime).
This latter value is computed by using the initTime variable, which gathers the value of the
local clock at the triggering of the action. A different round of the RTTP will start every 100
time units.
Figure 7.22 shows the Response atomic rule. When a node n2 receives a message m whose
initiator is a different node n1, it retransmits the message back to the n1 node. The initiator
will receive the message between 5 and 20 time units after, and will store it and compute its
RTT by using the value of its local clock.
To model time elapse of local clocks, we have defined the LocalTimeElapse ongoing rule,
which is shown in Figure 7.23. Clocks increase their time value with the corresponding time
elapse T. Note that we could have used the clock provided by the system instead for modeling
this behavior. However, we have selected this option to show how easy an user can define
his/her own (distributed) clocks.
Finally, the InitialModel rule in Figure 7.24 generates a possible initial configuration for the
system. This rule will be executed just once (the NAC pattern forbids the application of the
144
Figure 7.22: The Response atomic rule.
Figure 7.23: The LocalTimeElapse ongoing rule.
rule if it was already realized before). The rule creates a network composed of two nodes n1
and n2, and their corresponding local clocks c1 and c2. In our case, we only consider n1 as an
initiator node.
7.3 Real-time Behavioral Semantic Mappings
In the previous sections, we have introduced the e-Motions language in an intuitive and informal manner, by means of descriptions of its main features in natural language. However, this
lack of rigorous definitions may lead to imprecisions and misunderstandings that might hinder
the proper usage and analysis of the language. In this section, we provide a precise semantics
to this behavioral language by providing a representation of it in terms of Maude constructs,
i.e., we formalize this language into rewriting logic by means of model transformation [100].
7.3. R EAL - TIME B EHAVIORAL S EMANTIC M APPINGS
145
Figure 7.24: The InitialModel instantaneous rule.
This model transformation provides a way to give semantics to the behavioral parts of realtime DSMLs, preventing the DSML designer from defining the behavioral semantics of his/her
DSML explicitly. Furthermore, this semantic mapping allows us to specify real-time DSMLs’
behavior in a graphical and intuitive way (using the e-Motions tool), and perform simulation,
reachability and model-checking analysis on the models using the tools and techniques that
Maude provides.
7.3.1 A General View of the Encoding
We follow the guidelines of [89] to model time elapse in Real-Time Maude, but adapted to its
corresponding encoding in (Core) Maude (see Section 2.2.3.1). The choice of (Core) Maude
instead of Real-Time Maude as the target domain is based on the fact that a) Real-Time Maude
specifications can be translated to their corresponding (Core) Maude ones without altering their
semantics [91]; b) Maude specifications will remain transparent to the user, so the syntactic
sugar provided by Real-Time is not relevant; and c) handling Maude specifications directly is
more efficient that handling Real-Time Maude specifications.
Basically, we define a single rule tick that makes use of two functions: the delta function, which defines the effect of time elapse over the model elements, and the mte (maximal
time elapse) function, which defines the maximum amount of time that can elapse before any
action can take place. Originally, time advances non-deterministically by any amount T, which
must be equal or less than the maximum time elapse of the system. However, since we are
146
working directly with (Core) Maude (instead of Real-Time Maude), the tick mode selected by
the user has to be considered in the specification of the tick rule (see Section 2.2.3.1). At
this moment, our tool supports two of the three Real-Time Maude tick modes applicable to
the tick rule we have defined: maximal and default (see Section 2.2.3). We will consider the
maximal mode in the encoding presented in this section; the default mode will be presented
in Section 7.4, and the maximal/default mode is left as future work. In maximal mode, time
advances then deterministically by the maximum time elapse of the system.
var MODEL : @Model .
v a r s T TE : Time .
c r l [ tick ] :
{MODEL} in time T
=> {delta ( MODEL , TE ) } in time ( T plus TE )
i f TE : = mte ( MODEL )
/ \ TE =/= zero .
One of the main goals of our encoding is to make DSML objects as unaware of time as
possible. With this goal in mind, we introduce in our underlying platform several classes to
represent time and action properties. For instance, a Clock instance will represent the current
time elapse (by means of its time attribute), while ActionExec objects will represent the
execution of an action, gathering all the information related to it (such as the participants of the
rule, its starting time, etc.). The complete Maude specification of this classes can be found in
Appendix C. As we shall see later, time elapse will have to be defined only over these objects.
We show in what follows a more specific encoding of the main features of our approach. In
all of them we will use the following variable declarations:
v a r s MODEL MODEL@ : @Model .
v a r s MM MM@ : @Metamodel .
v a r s OBJSET OBJSET@ : Set{@Object} .
var C : @Class .
v a r s O O ’ O ’ ’ OR p1 p2 cl c1 c2 a CLK@ ACTEXC@ OR1@ OR2@ OR3@ OR4@ VAR1@ : Oid .
v a r s SFS SFS ’ SFS ’ ’ p@SFS p1@SFS p2@SFS ACTEXEC@SFS a@SFS : Set{@StructuralFeatureInstance} .
v a r s PHONE@p1@CLASS PHONE@p2@CLASS PHONE@p@CLASS : Phone .
var ANTENNA@a@CLASS : Antenna .
v a r s ON@p@ATT ON@p1@ATT ON@p2@ATT BATTERY@p@ATT DIALEDCALLS@p1@ATT RECEIVEDCALLS@p2@ATT
CONTACTS@p1@ATT : OCL−Type .
v a r s OIDSET@ SET SET ’ : Set .
v a r s T T ’ T ’ ’ T ’ ’ ’ TE TIME@CLK@ MINDURATION@ MAXDURATION@ : Time .
v a r s VALUE@ids@ VALUE@rdm@ : Nat .
The @ character is used to qualify generated variable names so that they can be distinguished.
Recall that classes, attributes and references are also qualified with their containers’ names;
147
however, these qualifications will be omitted here to improve readability.
7.3.2 Encoding of Atomic Rules
An atomic rule can be triggered whenever an occurrence (or match) of its LHS, and none of its
NAC patterns, is found in the model. Then, the action specified by such rule is scheduled to be
realized at a non-deterministic moment of time between t and t′ time units after. Such behavior
can be naturally encoded in Maude with two rewrite rules, one modeling the triggering of the
atomic action, and one modeling its actual realization.
7.3.2.1
The Triggering Rule
When the precondition of an atomic rule is satisfied, i.e., when an occurrence of the LHS that
does not fulfill any of the NAC patterns is found in the model, an object of the AtomicActionExec class (which inherits from the ActionExec class) is created. The AtomicActionExec
object will represent the execution of the atomic rule, acting as a countdown to the finalization
of the action (mintimer and maxtimer attributes). This object gathers all the information
needed for its instantiation, such as the name of the rule (action attribute), the identifiers of
the elements involved in the action (participants attribute), the status of the action (status
attribute), the starting time (startingTime attribute), the ending time (endingTime attribute), and the execution time (executionTime attribute). Initially, the status of the action
is set to unfinished; the mintimer and maxtimer attributes are set to the given minimal
and maximal duration of the rule, respectively; the execution time is set to zero; the starting
time is set to the value of the Clock instance; and the ending time is left undefined.
For instance, the following Maude rule corresponds to the encoding of the Call action’s
triggering rule (see Figure 7.13):
v a r s initTime : OCL−Type .
c r l [ Call@Triggering ] :
MM@ { --- LHS elements
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # on : ON@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | on : ON@p2@ATT # p2@SFS >
< cl : Clock | time : TIME@CLK@ >
--- Further elements
< ’ids@ : Counter | value : VALUE@ids@ >
< ’rdm@ : Counter | value : VALUE@rdm@ >
OBJSET }
=>
148
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT # on : ON@p1@ATT # p1@SFS >
--- Action execution
< ACTEXC@ : AtomicActionExec | action : "Call" # participants : Set{OR1@ ; OR2@} #
minTimer : MINDURATION@ # maxTimer : MAXDURATION@ # status : unfinished #
startingTime : TIME@CLK@ # endingTime : null # executionTime : 0 #
variables : Set{VAR1@} >
< OR1@ : ObjectRole | actualObject : p1 # role : "p1" >
< VAR1@ : Variable | name : "initTime" # value : initTime >
< ’ids@ : Counter | value : ( VALUE@ids@ + 4 ) >
OBJSET@ }
i f MODEL@ : = MM@ { < p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT #
on : ON@p1@ATT # p1@SFS >
OBJSET }
/ \ not currentExec@Call ( Set{p1 ; p2 } , MODEL@ ) .
--- Rule variables
/ \ initTime : = eval ( cl . time , env ( empty ) , MODEL@ )
--- LHS slots
/ \ ON@p1@ATT : = eval ( true , env ( self <− p1 ) , MODEL@ )
/ \ ON@p2@ATT : = eval ( true , env ( self <− p2 ) , MODEL@ )
--- LHS links
/ \ p2 in CONTACTS@p1@ATT
--- LHS conditions
/ \ eval ( p1 . coverage > 0 and p2 . coverage > 0 , env ( empty ) , MODEL@ )
--- Identifiers of the new elements
/ \ ACTEXC@ : = newId ( VALUE@ids@ )
/ \ OR1@ : = newId ( VALUE@ids@ + 1 )
/ \ VAR1@ : = newId ( VALUE@ids@ + 3 )
--- Rule duration
/ \ MINDURATION@ : = toRat ( eval ( 2 0 , env ( empty ) , MODEL@ ) )
/ \ MAXDURATION@ : = toRat ( eval ( 3 0 , env ( empty ) , MODEL@ ) )
--- NAC patterns
/ \ not p1isNotInACall@Call ( Set{p1 ; p2 } , < VAR1@ : Variable | name : "initTime" #
value : initTime >, MODEL@ )
/ \ not p2isNotInACall@Call ( Set{p1 ; p2 } , < VAR1@ : Variable | name : "initTime" #
value : initTime >, MODEL@ ) .
Note the use of the MODEL@ variable matched in the condition of the rule to avoid repeating
the configuration in the remaining conjuncts of the condition. In the rules below, we will write
dots to abbreviate their presentations.
Objects of transformation rules’ LHS patterns are encoded as Maude objects placed in the
149
left-hand side of the Maude rule; they are also included in the right-hand side so that they
remain as such. LHS conditions and slots are encoded as rule conditions, which are computed
by the eval operation. The eval operation evaluates the OCL expression given as its first
argument in the context specified by its second and third arguments. The second argument
represents a set of variable-value bindings of the form env(var1 ← val1 , ..., varN ← valN ),
while the third argument represents the model on which we want the expression to be evaluated.
LHS links are encoded as rule conditions too by means of invocations to the in operation. This
operation checks whether an object identifier is included in a given collection of references.
The toRat operation converts a possible float number into a rational number. This operation
is applied to every value of the e-Motions language that represents a time value so that they can
be handled by our (discrete or dense) model of time. The participants of the rule are specified
by means of ObjectRole elements. An ObjectRole object represents a pair object-role:
the object that is involved in an action (actualObject attribute) and the role that it plays on
it (role attribute). Variables are computed in rule conditions and their values are stored in
Variable objects so that they can be accessed from the realization rule (see below).
The Clock instance is included in the Maude rule (no matter if is explicitly specified in
the in-place rule or not) to set the starting time of the AtomicActionExec element ACTEXC@
that represents the rule execution. Two Counter objects are included too. The ids@ counter
is used to compute the identifiers of the new created objects by using the newId operation,
which creates an object identifier from a given natural number. The rdm@ counter is used
when the predefined e-Motions helper random is invoked to perform successive calls to the
Mersenne twister random number generator that Maude provides [42].5 Additionally, the
currentExec@Call operation is included to forbid the triggering of the rule whenever an-
other occurrence of the same rule is already being executed with the same set of participants.
This operation checks the existence of an AtomicActionExec object that refers to the rule
(Call) with the same set of participants (Set{p1 ; p2}) and with an undefined endingTime
in the model (@MODEL).
var L@TIMER@ : MSet{OCL−Exp} .
op currentExec@Call : Set @Model −> Bool .
eq currentExec@Call ( Set{p1 ; p2 } ,
MM@ { < ACTEXEC@ : AtomicActionExec | action : "Call" # endingTime : null #
participants : Set{OR1@ ; OR2@ ; L@TIMER@} # ACTEXEC@SFS >
5
The ids@ and rdm@ counters are always included in the rule, no matter if they are used or not.
150
OBJSET@ } )
= true .
eq currentExec@Call ( OIDSET@ , MODEL@ ) = false [ owise ] .
NAC patterns are encoded as predicates which are invoked from rule conditions (see the
p1isNotInACall@Call and p2isNotInACall@Call predicates). These predicates check
whether occurrences of the specified patterns are found in the model. Their first and second
parameters indicate the set of objects that are involved in the LHS pattern and the set of variables defined in the rule, respectively, so that they can be referred from the NAC pattern. For
instance, the following excerpt of code specifies the p1isNotInACall@Call predicate:
var initTime : OCL−Type .
var L@a : MSet{OCL−Exp} .
v a r s OR1@a : Oid .
v a r s OR1@a@SFS : Set{@StructuralFeatureInstance} .
op p1isNotInACall@Call : Set Set{@Object} @Model −> Bool .
eq p1isNotInACall@Call ( Set{p1 ; p2 } ,
< VAR1@ : Variable | name : "initTime" # value : initTime >,
MM@ { --- NAC elements
< a : AtomicActionExec | action : "Call" # status : unfinished #
participants : Set{OR1@a ; L@a} # a@SFS >
< OR1@a : ObjectRole | actualObject : p1 # OR1@a@SFS >
OBJSET@ } )
= true .
eq p1isNotInACall@Call ( OIDSET@ , OBJSET@ , MODEL@ ) = false [ owise ] .
In this case, the NAC pattern is only composed of an action execution element. Action execution elements are encoded as AtomicActionExec objects, while object mappings are encoded
as ObjectRole objects. Note that the ObjectRole does not restrict the role that object p1
plays in the rule, since it was left undefined in the specification of the atomic rule (see Figure 7.13).
DPO and SPO formalizations. The encoding of the atomic action’s triggering rule presented
above follows the SPO formalization. However, our tool also supports the DPO formalization.
When the DPO formalization is chosen, an invocation of the dpo predicate is added to the
conditions of the triggering rule. This predicate has three arguments: 1) the set of elements to
be deleted specified by the rule; 2) the list of links (of sort MyLinkList) to be deleted specified
by the rule; and 3) the model on which the condition required by the DPO formalization will be
checked. The dpo operation firstly deletes from the model all the links and objects (including
their contained objects) specified by the rule to be deleted (lines 4 to 6), and then checks
151
whether no references to these deleted elements are left in the model (lines 8 to 17). If any
dangling reference is found, the DPO condition is not satisfied and the rule will not be applied.
1
v a r s L L ’ : MSet{OCL−Exp} .
2
v a r s LO LO ’ : List{OCL−Exp} .
3
4
op dpo : Set MyLinkList @Model −> Bool .
5
eq dpo ( SET , MLL , MODEL ) = dpo ( union ( SET , getAllContainedOids ( SET , MODEL ) ) ,
deleteEls ( SET , deleteLinks ( MLL , MODEL ) ) ) .
6
7
8
9
op dpo : Set @Model −> Bool .
eq dpo ( Set{mt } , MODEL ) = true .
10
--- Possible references to deleted elements
11
eq dpo ( Set{O ; L } , MM {< O ’ : C | ( REF : Sequence{LO # O # LO ’ } # SFS ) > OBJSET } ) = false .
12
eq dpo ( Set{O ; L } , MM {< O ’ : C | ( REF : Set{O ; L ’ } # SFS ) > OBJSET } ) = false .
13
eq dpo ( Set{O ; L } , MM {< O ’ : C | ( REF : OrderedSet{LO # O # LO ’ } # SFS ) > OBJSET } ) = false .
14
eq dpo ( Set{O ; L } , MM {< O ’ : C | ( REF : Bag{O ; L ’ } # SFS ) > OBJSET } ) = false .
15
eq dpo ( Set{O ; L } , MM {< O ’ : C | ( REF : O # SFS ) > OBJSET } ) = false .
16
--- Otherwise
17
eq dpo ( Set{O ; L } , MODEL ) = true [ owise ] .
The getAllContainedOids operation obtains from a set of objects (SET) the set of identifiers of the objects recursively contained by them. The deleteEls and deleteLinks operations remove a set of objects (including their contained objects) and a list of links from a
model, respectively.
7.3.2.2
The Realization Rule
Once an atomic action’s minimum timer is consumed (i.e., there is an AtomicActionExec
object whose minTimer attribute’s value is 0) the corresponding action can be performed if its
participants are still there. Then, the matching of the LHS is substituted by the corresponding
instantiation of the RHS and the attribute computations are realized. To keep track of the
performed actions, the AtomicActionExec objects are not deleted, but their ending times
are set, and their corresponding status and participants are updated instead. For instance, the
following Maude rule corresponds to the encoding of the Call action’s realization rule:
var initTime : OCL−Type .
c r l [ Call@Realization ] :
< p1 : PHONE@p1@CLASS | contacts : CONTACTS@p1@ATT #
dialedCalls : DIALEDCALLS@p1@ATT # p1@SFS >
< p2 : PHONE@p2@CLASS | receivedCalls : RECEIVEDCALLS@p2@ATT # p2@SFS >
--- Action execution with minimum timer consumed
< ACTEXEC@ : AtomicActionExec | action : "Call" # participants : Set{OR1@ ; OR2@} #
152
minTimer : 0 # status : unfinished # endingTime : null # executionTime : T #
variables : Set{VAR1@} # ACTEXC@@SFS >
< VAR1 : Variable | name : "initTime" # value : initTime >
OBJSET@ }
=> readjust ( ACTEXEC@ , Set{mt } ,
MM@ { --- RHS elements
< p1 : PHONE@p1@CLASS |
contacts : update ( contacts , CONTACTS@p1@ATT , nil , link ( p2 , null ) ) #
dialedCalls : update ( dialedCalls , DIALEDCALLS@p1@ATT , nil , link ( c1 , null ) ) #
p1@SFS >
< p2 : PHONE@p2@CLASS | receivedCalls : update ( receivedCalls ,
RECEIVEDCALLS@p2@ATT , nil , link ( c2 , null ) ) # p2@SFS >
complete(< c1 : CallRecord | duration : eval ( T , env ( self <− c1 ) , MODEL@ ) #
contact : update ( contact , null , nil , link ( p2 , null ) ) #
startingTime : eval ( initTime , env ( self <− c1 ) , MODEL@ ) >)
complete(< c2 : CallRecord | duration : eval ( T , env ( self <− c2 ) , MODEL@ ) #
contact : update ( contact , null , nil , link ( p1 , null ) ) #
startingTime : eval ( initTime , env ( self <− c2 ) , MODEL@ ) >)
--- Action execution updated
< ACTEXEC@ : AtomicActionExec | action : "Call" #
participants : Set{OR1@ ; OR2@ ; OR3@ ; OR4@} # minTimer : 0 #
status : realized # endingTime : TIME@CLK@ # executionTime : T #
variables : Set{VAR1@} # ACTEXEC@SFS >
< OR3@ : ObjectRole | actualObject : c1 # role : "c1" >
< OR4@ : ObjectRole | actualObject : c2 # role : "c2" >
< VAR1 : Variable | name : "initTime" # value : initTime >
OBJSET@ }
i f MODEL@ : = MM@ { . . . OBJSET }
/ \ c1 : = newId ( VALUE@ids@ + 2 )
/ \ c2 : = newId ( VALUE@ids@ + 3 ) .
Objects that are specified by the rule to be created are added to the right-hand side of
the Maude rule and included as new participants of the action execution. The complete
operation adds to a new object all the structural feature-value pairs (with their default value)
that are not explicitly specified within the object’s slots in the rule. RHS slots are encoded as
computations in the right-hand side of the rule. The final duration of the rule T is obtained
153
from the AtomicActionExec object’s executionTime attribute. Links that are specified by
the rule to be created or deleted are so by means of the update operation. The first parameter
of this operation is the reference that the link represents; the second parameter represents the
previous value of the reference; the third parameter represents the list of links to be deleted;
and the fourth parameter represents the list of links to be added. For this operation, we specify
links as pairs (o, p), where o represents the target object identifier and p its possible position in
the source collection of references (null if not specified).
The readjust operation performs the deletion of objects (second parameter) that are specified in the in-place rule to be deleted (an empty set in this case). These deletions are handled
with an equation (instead of simply not including the objects in the right-hand side pattern of
the rewrite rule) because further processing is usually needed. In particular, once an object is
deleted, all its contained objects and the set of all possible dangling references that its deletion
may cause should be deleted as well.
6
The readjust operation is also responsible for abort-
ing all the current action executions on which any of the elements that are specified by the rule
to be deleted are involved in. Similarly, it aborts all unfinished actions in which the current
finished action execution ACTEXEC@ specified by this rule participates (see Section 7.2.3.4).
7.3.3 Encoding of Periodic Rules
Periodic rules are atomic rules that can be triggered only once in a given period of time. Therefore, they can be encoded as atomic rules (by means of two Maude rewrite rules, one modeling
its triggering and one modeling its actual realization) but adding the corresponding rule conditions to fulfill this requirement. In fact, only the triggering rule is affected: the encoding of
the realization rule remains unchanged. For instance, the following rewrite rule corresponds to
the encoding of the Coverage action’s triggering rule (see Figure 7.8):
1
2
c r l [ Coverage@Triggering ] :
3

4
< a : ANTENNA@a@CLASS | a@SFS >
5
6
< CLK@ : Clock | time : TIME@CLK@ >
7
8
OBJSET@ }
9
10
=> MM@ { --- LHS elements
6
Note that dangling references are only deleted with the spo formalization, since dpo forbids the application
of rules (by means of a rule condition) that may result in dangling references.
154
11

12
< a : ANTENNA@a@CLASS | a@SFS >
13
14
< ACTEXEC@ : AtomicActionExec | action : "Coverage" # status : unfinished #
15
participants : Set{OR1@ ; OR2@} # minTimer : MINDURATION@ #
16
maxTimer : MAXDURATION # startingTime : TIME@CLK@ # endingTime : null #
17
executionTime : 0 # variables : Set{mt} >
18
19
< OR1@ : ObjectRole | actualObject : p # role : "p" >
< OR2@ : ObjectRole | actualObject : a # role : "a" >
20
21
22
23
24
OBJSET@ }
25
26
--- Periodic condition
27
/ \ not alreadyTrigInPeriod@Coverage ( Set{p ; a } , MODEL@ , TIME@CLK@ , toRat ( 5 . 0 ) )
28
--- Normal periodic condition
29
/ \ multiple ( TIME@CLK@ , toRat ( 5 . 0 ) )
30
--- LHS slots
31
/ \ ON@p@ATT : = eval ( true , env ( self <− p ) , MODEL@ )
32
33
34
35
36
--- Rule duration
37
/ \ MINDURATION@ : = toRat ( eval ( 1 , env ( empty ) , MODEL@ ) )
38
/ \ MAXDURATION@ : = toRat ( eval ( 1 , env ( empty ) , MODEL@ ) )
39
--- NAC patterns
40
/ \ not nocloserantenna@Coverage ( Set{p ; a } , none , MODEL@ ) .
Two new conditions may appear in the triggering rule of periodic actions (see lines 26 to
29). The first condition is an invocation to the alreadyExecInPeriod@Coverage opera-
tion, which checks whether the rule has already been triggered with the same set of participants
in the current period. This operation is included in the encoding of every periodic rule (normal
or soft). Note that the currentExec operation is not needed anymore. The second condition
is specific to normal periodic rules: since this kind of rules can only be triggered at the beginning of the period, we forbid applying the rule if the current moment of time is not multiple of
the period of the rule (5.0 in this example).
The alreadyExecInPeriod@Coverage auxiliary operation is encoded in Maude as follows. This operation checks the existence of an AtomicActionExec object that refers to
the rule (Coverage) with the same set of participants (Set{p ; a}) and with a starting time
allocated within the current period (condition that is checked by the inPeriod operation).
v a r s PERIOD@
: Time .
var L@ACTEXEC@ : MSet{OCL−Exp} .
155
op alreadyTrigInPeriod@Coverage : Set @Model Time Time −> Bool .
ceq alreadyTrigInPeriod@Coverage ( Set{p ; a} ,
MM@ < ACTEXEC@ : AtomicActionExec | action : "Coverage" #
participants : Set{OR1@ ; OR2@ ; L@ACTEXEC@} #
startingTime : STARTINGTIME@ #
ACTEXEC@SFS >
< OR2@ : ObjectRole | actualObject : a # role : "a" >
OBJSET@ } ,
TIME@CLK@ , PERIOD@ )
= true
i f inPeriod ( STARTINGTIME@ , TIME@CLK@ , PERIOD@ ) .
eq alreadyTrigInPeriod@Coverage ( OIDSET@ , MODEL@ , TIME@CLK@ , PERIOD@ )
= false [ owise ] .
As we shall see in Section 7.3.7, periods are also taken into account in the computation of
time elapses so that we can ensure that periodic rules are tried to be triggered at least once in
every period.
7.3.4 Encoding of Instantaneous Rules
In the e-Motions tool, we model instantaneous rules as atomic rules with minimal and maximal
duration equals to zero. However, they are not encoded in the same way as atomic rules: since
instantaneous rules do not have a duration to be consumed, the rule’s triggering and realization
do not need to be separated. Thus, we encode each instantaneous rule as a single rewrite
rule. In this way, no other action may occur during the execution of this kind of actions. This
rewrite rule will check whether the instantaneous rule’s precondition is satisfied, and if so, it
will substitute the instantiation of the LHS pattern by the corresponding instantiation of the
RHS, and will create an AtomicActionExec object to keep track of the performed action.
For instance, the BatteryOff rule (see Figure 7.6) is encoded in Maude as follows:
c r l [ BatteryOff@Instantaneous ] :

OBJSET@ }
=>
readjust ( Set{mt } ,
MM@ { --- RHS elements

< ACTEXEC@ : AtomicActionExec | action : "BatteryOff" # participants : Set{OR1@} #
156
minTimer : 0 # maxTimer : 0 # status : realized # variables : Set{mt} #
startingTime : TIME@CLK@ # endingTime : TIME@CLK@ # executionTime : T >
OBJSET@ }
--- LHS slots
/ \ BATTERY@p@ATT : = eval ( 0 , env ( self <− p ) , MODEL@ )
/ \ ACTEXEC@ : = newId ( VALUE@ids@ )
--- Rule duration
/ \ T : = eval ( 0 , env ( empty ) , MODEL@ )
--- NAC patterns
/ \ not pisNotInACall@BatteryOff ( Set{p } , none , MODEL@ ) .
Note that, since no other action can occur during the execution of an instantaneous rule, we
do not need to check whether the same rule is already being executed with the same set of
participants.
7.3.5 Encoding of Ongoing Rules
Ongoing rules are used to model actions that progress with time. Since the delta function
defines the effect of time over the model objects, we will encode ongoing rules into the delta
function itself. However, the maximal duration and time upper bounds of current executions of
ongoing rules also affect the maximal time elapse (mte) of the system (see Section 7.3.7). Since
the maximal time elapse is computed before the delta operation is, we also include a rewrite
rule per each ongoing rule that creates an object at the triggering of the ongoing action that
represent a possible execution of the action. This object will gather all the information about
the rule instantiation (including its maximal duration), which will make it accessible when the
mte operation is invoked (and in fact before the corresponding ongoing rule is realized).
7.3.5.1
The Initial Rule
The initial rule of an ongoing action is encoded as the triggering rule of an atomic action. When
the rule precondition is satisfied, an object of the OngoingActionExec class (which inherits
from the ActionExec class) is created, indicating that the corresponding ongoing rule can be
executed at that moment of time. This object gathers all the information about its instantiation,
157
including the OCL expression that represents the maximal duration (maxTimer attribute), and
a new timer that represents a countdown to the rule’s upper bound (upperBoundTimer attribute). This upperBoundTimer timer is only needed in ongoing action executions: since
ongoing rules do not have a specific duration, their upper bound also act as a maximal bound
for their duration.
As an example, the following Maude specification corresponds to the encoding of the BatteryConsumption action’s initial rule (see Figure 7.10):
1
2
c r l [ BatteryConsumption@Triggering ] :
3

4
5
6
7
OBJSET@ }
8
9
10
11
=>

12
--- Action execution representation
13
< ACTEXC@ : OngoingActionExec | action : "BatteryConsumption" ,
14
maxTimer : freeze ( p . battery / p . bps ) , variables : Set{mt } ,
15
startingTime : TIME@CLK@ , endingTime : null ,
16
participants : Set{OR1@ } , upperBoundTimer : null >
17
< OR1@ : ObjectRole | actualObject : p , role : "p"
18
19
20
21
22
>
OBJSET@ }
23
i f MODEL@ : = MM@ { . . . OBJSET@ }
24
/ \ not currentExec@BatteryConsumption ( Set{p } , MODEL@ )
25
/ \ toRat ( eval ( p . battery / p . bps , env ( empty ) , MODEL@ ) ) > 0
26
27
28
/ \ OR1@ : = newId ( VALUE@ids@ + 1 ) .
Ongoing rules’ maximal duration expressions are frozen (i.e., maintained unevaluated with
the freeze operation in the maxTimer attribute) to be later computed in the mte function to
get the current (real) values of the elements involved in the expression at that moment of time.
However, they are also computed in the rule (see line 25) to forbid its triggering in case the
maximal duration is not greater than zero. In the above rule, the upperBoundTimer attribute
is set to null, since the BatteryConsumption rule’s upper bound is not specified.
op freeze : OCL−Exp −> OCL−Type .
--- No equations, so the operation is not evaluated
158
Finally, note that Maude rules are applied in a non-deterministic order. Therefore, the
realization rule of an atomic action can be applied, e.g., after the execution of the initial rule
of an ongoing action. This application can make an OngoingActionExec object to represent
an invalid action execution: since the state of the system may change from the moment of the
generation of an OngoingActionExec object to the moment in which the ongoing action is
in fact realized (the moment in which the delta operation is applied), the precondition of
the action that represents the OngoingActionExec object may be violated. These invalid
OngoingActionExec objects will be removed from the specifications, as we shall see below.
7.3.5.2
The applyOngoingRules Operator
In the following time elapse, the delta equation calls the applyOngoingRules function.
One applyOngoingRules equation defining the operator is added for each ongoing rule.
This equation checks whether the ongoing rule’s precondition is satisfied (note that the system
state may have changed from the moment on which the OngoingActionExec object was
created), and if so, it substitutes the LHS matching by its RHS and sets the ending time and
maximal duration of the OngoingActionExec object.
op applyOngoingRules : @Model Time −> @Model .
ceq applyOngoingRules (

--- Ongoing action execution element
< ACTEXEC@ : OngoingActionExec | action : "BatteryConsumption" #
endingTime : null # participants : Set{OR1@} # variables : Set{mt} #
maxTimer : freeze ( MAXDURATION@ ) # ACTEXC@@SFS >
OBJSET } ,
T)
= applyOngoingRules (
readjust ( Set{mt } ,
MM@{ 
--- Ongoing action execution element
< ACTEXEC@ : OngoingActionExec | action : "BatteryConsumption" #
endingTime : ( T plus TIME@CLK@ ) # participants : Set{OR1@} #
variables : Set{mt} # maxTimer : toRat ( eval ( MAXDURATION@ , env ( empty ) ) #
ACTEXC@@SFS >
159
OBJSET } ,
T)
i f MODEL@ : = MM@ { . . .
OBJSET@ }
/ \ ON@p@ATT : = eval ( true , env ( self <− p ) , MODEL@ ) .
/ \ toRat ( eval ( MAXDURATION@ , env ( empty ) , MODEL@ ) ) > 0
--- Remaining applyOngoingRules equations...
eq applyOngoingRules ( MODEL , T )
= joinOngoingActionExecs ( deleteInvalidActionExecs ( MODEL ) ) [ owise ] .
The current system time elapse T is provided by the delta operation (see the second argument of the applyOngoingRule operation). This value is used to perform the attribute
computations that depend on it (such as the above expression (p . battery - T * p .
bps)), and set the rule’s ending time. The applyOngoingRule operation is recursively called
until every possible execution of an ongoing action is realized, and thus the endingTime of the
OngoingActionExec objects that represent them are set. Remaining OngoingActionExec
objects with an undefined endingTime represent current invalid actions, i.e., actions that cannot be performed in that moment of time. These invalid applyOngoingRules objects are
deleted (including the Variable and ObjectRole objects referred by them) in the owise
equation.
op deleteInvalidActionExecs : @Model −> @Model .
eq deleteInvalidActionExecs ( MM { < O : OngoingActionExec | endingTime : null #
participants : SET # variables : SET ’ # SFS ) >
OBJSET } )
= deleteInvalidActionExecs ( deleteEls ( << SET −> union ( SET ’ ) >>, MM { OBJSET } ) ) .
eq deleteInvalidActionExecs ( MODEL ) = MODEL [ owise ] .
The joinOngoingActionExecs operation joins ongoing action execution elements that
represent consecutive executions of the same ongoing action with the same set of participants.
In particular, it refines the information gathered by a previous-in-time OngoingActionExec
object with the information provided by the new occurrence. This operation has been defined to
prevent the model from being flooded with OngoingActionExec objects with short execution
times.
var ST : String .
v a r s MAXT MAXT ’ : Time .
op joinOngoingActionExecs : @Model −> @Model .
ceq joinOngoingActionExecs (
MM { < O : OngoingActionExec | action : ST # participants : SET # maxTimer : MAXT #
endingTime : T # SFS >
< O ’ : OngoingActionExec | action : ST # participants : SET ’ # maxTimer : MAXT ’ #
startingTime : T # variables : SET ’ ’ # endingTime : T ’ # SFS ’ >
160
OBJSET } )
= joinOngoingActionExecs (
deleteEls ( << SET −> union ( SET ’ ) >>,
MM { < O : OngoingActionExec | action : ST # participants : SET #
maxTimer : i f ( ( MAXT =/= null ) and−then ( MAXT ’ =/= null ) )
then ( MAXT plus MAXT ’ ) else MAXT fi #
endingTime : T ’ # SFS >
OBJSET } ) )
i f sameParticipantsAndRoles ( SET , SET ’ , MM { . . . OBJSET } ) .
eq joinOngoingActionExecs ( MODEL ) = MODEL [ owise ] .
The sameParticipantsAndRoles operation checks whether two set of ObjectRole elements refer to the same set of action participants playing the same role.
7.3.6 Encoding of Rule Execution Modes
As we mentioned in Section 7.2, we distinguish normal rules, which are triggered as soon
as possible, from soft rules, which are not necessarily triggered immediately, but in a nondeterministic moment in time in the near future. The only difference in their encoding is
that we do not allow time to elapse if a normal (non-soft) rule can be triggered, i.e., if the
precondition of any normal rule is satisfied. Since the elapse of time depends on the maximal
time elapse defined by the mte function, we include an extra mte equation for every normal
rule that forbids time to elapse whenever the rule can be applied and it has not been so (see
Section 7.3.7 for an example of such kind of equation). This mechanism is also used with
normal and soft periodic rules, since both kinds of rules are triggered as soon as possible too.
Regarding scheduled actions, they are modeled by normal atomic rules whose lower and
upper bounds coincide with the moment in time at which the rules are scheduled. Lower and
upper bounds are encoded as rule conditions that forbid the triggering of the rule out of its
interval of time. In ongoing rules, upper bounds are also encoded as timers (see Section 7.3.5).
Lower bounds are also considered in the computation of time elapse so that we can ensure that
scheduled and time-bounded rules are tried to be applied at least once in their corresponding
interval (see Section 7.3.7).
7.3.7 Pass of Time
We model time elapse with one tick rule by using the delta and mte functions. The rule,
which was already introduced in Section 7.3.1, is the following:
c r l [ tick ] :
{ MODEL } in time T
161
=> { delta ( MODEL , TE ) } in time ( T plus TE )
/ \ TE =/= zero .
The delta function defines the effect of time elapse T over the model elements, and the
mte function the maximum amount of time that can elapse before any action is performed. Our
approach makes DSML objects unaware of time, and therefore both functions need to be defined only over time-dependent elements, namely the Clock instance, and AtomicActionExec
and OngoingActionExec objects.
7.3.7.1
The delta Function
The delta function applies ongoing actions (with the applyOngoingRules auxiliary operation), and then updates the Clock and AtomicActionExec instances. In particular, it
increases the clock value and the execution time of action executions, and decreases the timers
of action executions. The DSML objects remain unchanged.
op delta : @Model Time −> @Model [ frozen ] .
op deltaAux : @Model Time −> @Model [ frozen ] .
op delta : Set{@Object} Time −> Set{@Object} [ frozen ] .
eq delta ( MODEL , T ) = deltaAux ( applyOngoingRules ( MODEL , T ) , T ) .
eq deltaAux ( MM { OBJSET } , T ) = MM { delta ( OBJSET , T ) } .
eq delta(< O : AtomicActionExec | endingTime : null , minTimer : T ’ , maxTimer : T ’ ’ ,
executionTime : T ’ ’ ’ ,
SFS > OBJSET , T )
= < O : AtomicActionExec | endingTime : null , minTimer : ( T ’ monus T ) ,
maxTimer : ( T ’ ’ monus T ) , executionTime : ( T ’ ’ ’ plus T ) , SFS >
delta ( OBJSET , T ) .
eq delta(< O : Clock | time : T ’ , SFS > OBJSET , T )
= < O : Clock | time : ( T ’ plus T ) , SFS > delta ( OBJSET , T ) .
eq delta ( OBJSET , T ) = OBJSET [ owise ] .
Note the use of the owise attribute: we act on time-dependent elements and we leave the rest
unaffected. Note as well that the frozen attribute guarantees that no rule is applied on any of
the arguments of a delta function (see [89]).
7.3.7.2 The mte Function
The mte function defines the maximum amount of time that can elapse before any action is
performed. Therefore, this function must take into account the maximal duration of atomic
and ongoing action executions, the beginning of periods of periodic rules, the upper bound
for ongoing actions, etc. Thus, the mte function is defined as the minimum of (a) maxTimer
values of current AtomicActionExec objects, (b) maxTimer and upperBoundTimer values
162
of current OngoingActionExec objects, and (c) for each rule, the difference between the
following beginning of rule period or lower bound and the current time elapse. Furthermore,
we add extra equations defining the mte operator per each normal and (normal or soft) periodic
rule. These equations forbid time to elapse, i.e., define the maximal time elapse of the system
as 0 time units, if any of these rules can be applied and it has not been so. Note also the use of
the owise attribute.
var OCLEXP : OCL−Exp .
op mte : @Model −> TimeInf [ frozen ] .
op mteAux : @Model @Model −> TimeInf [ frozen ] .
---- mte equation for the BatteryOff normal rule
ceq mte ( MM@ { 
OBJSET@ }
= 0
/ \ BATTERY@p@ATT : = eval ( 0 , env ( self <− p ) , MODEL@ )
/ \ not pisNotInACall@BatteryOff ( Set{p } , none , MODEL@ ) .
---- mte equations for remaining normal and (normal or soft) periodic rules
...
eq mte ( MODEL@ ) = mteAux ( MODEL@ , MODEL@ ) [ owise ] .
eq mteAux ( MM@ { < O : AtomicActionExec | maxTimer : T , endingTime : null , SFS ) > OBJSET@ } ,
MODEL@ )
= minimum ( T , mteAux ( MM@ { OBJSET@ } , MODEL@ ) ) .
eq mteAux ( MM@ { < O : OngoingActionExec | maxTimer : freeze ( OCLEXP ) ,
endingTime : null , upperBoundTimer : T ’ , SFS > OBJSET@ } ,
MODEL@ )
= i f ( toRat ( eval ( OCLEXP , env ( empty ) , MODEL@ ) ) <= 0 ) )
then minimum ( T ’ , mteAux ( MM { OBJSET@ } , MODEL@ ) )
else minimum ( toRat ( eval ( OCLEXP , env ( empty ) , MODEL@ ) ) ,
minimum ( T ’ , mteAux ( MM { OBJSET@ } , MODEL@ ) ) )
fi .
eq mteAux ( MM@ { < O : Clock | time : T > OBJSET@ } , MODEL@ )
= minimum ( minimum ( nextLowerBound ( T , rulesInformation ) ,
nextPeriod ( T , rulesInformation ) ) monus T ,
mteAux ( MM@ { OBJSET@ } , MODEL@ ) ) .
eq mteAux ( MODEL@ , MODEL@ ’ ) = INF [ owise ] .
The rulesInformation constant is defined as a model that gathers all the rule properties, such as their periodicity and lower and upper bounds (see Appendix C). Operations
nextPeriod and nextLowerBound make use of it to compute the following beginning of
rule’s period and lower bound, forcing time to stop in these moments in time. In this way, we
can ensure that periodic and time-bounded rules will be tried to be triggered at least once in
7.4. F ORMAL A NALYSIS OF R EAL -T IME D OMAIN S PECIFIC M ODELS WITH M AUDE 163
their corresponding interval and period, respectively.
7.4 Formal Analysis of Real-Time Domain Specific Models
with Maude
Once we encode the structural and time-dependant behavioral specifications of our DSML in
Maude, what we get is a rewriting logic specification of the system. Since the rewriting logic
specification produced in this way is executable, it can be used as a prototype of the real-time
system, which allows us to simulate and formally analyze it.
In Section 6.2 we showed how we can make use of Maude’s rewriting, search, and model
checking facilities for untimed rewrite theories. However, in real-time systems it is often natural to relate rewriting, search, and model checking to the time elapsed in the system. Furthermore, time-bounded search and model checking is a reasonably natural way of restricting the
possibly infinite number of reachable states in a system to the finite subset which is reachable
within a given time. In this section we will show then how we can apply these mechanisms to
make use of the tools already presented in Section 6.2 with timed rewrite theories.
7.4.1 Initial Considerations
Real-Time Maude (see Section 2.2.3) extends Maude’s rewriting, search, and model checking facilities to perform analysis and simulation over real-time systems. Real-Time Maude is
designed to take maximum advantage of the high performance of the Maude engine. Most
Real-Time Maude analysis commands are therefore executed by first transforming the current
timed module into a Maude module, followed by the execution of a corresponding Maude command [91]. In fact, a large majority of Real-Time Maude commands can be executed directly
using the Maude engine. Only a few of them are only available for Real-Time Maude, such
as the find latest and find earliest commmands [89]. Since in this thesis we encode
e-Motions rules directly into (Core) Maude, we will make use of the (Core) Maude commands
that represent the corresponding equivalent Real-Time Maude commands, following the directions given in [91].
The execution of a specific Real-Time Maude command in (Core) Maude, as well as the
tick mode selected by the user, will affect the rewrite rule that we define to model time elapse.
In Sections 7.3.1 and 7.3.7 we presented the default rule that models time elapse. This rule
164
follows the maximal time sampling strategy (see Section 2.2.3), i.e., with this rule time will
advance deterministically by the maximum time elapse of the system.
c r l [ tick ] :
{MODEL} in time T
/ \ TE =/= zero .
However, other tick modes can also be considered. For instance, our e-Motions tool also
supports the default tick mode. This tick mode is applied when the user specify a default time
elapse for a specific simulation. If the user selects a default time value of, for instance, 2 time
units, the rewrite rule that models time elapse will be defined as follows:
c r l [ tick ] :
{MODEL} in time T
i f TE : = minT ( mte ( MODEL ) , toRat ( 2 ) )
/ \ TE =/= zero .
where the minT operation computes the minimum of two time values.
Note that in this case, time is advanced by the smallest value of the maximum time elapse
of the system and the default time elapse value specified by the user.7 The user has to consider
that all rewriting will be performed according to the chosen time sampling strategy, which of
course impacts search and model checking [91].
Together with the tick mode selected by the user, the execution of a specific Real-Time
Maude command in (Core) Maude usually places additional constraints to the tick rule. For
instance, the tick rule should not tick the time beyond the time bound specified for any command. These additional constrains will be usually encoded as further rule conditions. For
instance, if we specify a time bound of 100 time units, the tick rule will be described as
follows (this rule consider maximal tick mode):
c r l [ tick ] :
{MODEL} in time T
/ \ TE =/= zero
/ \ ( T plus TE ) le toRat ( 1 0 0 ) .
where the le operation checks whether the first argument is less or equal than the second
one.
7
The toRat operation invocation is not needed in this case, but it is automatically included by our tool to
cover the case on which the user considers dense time and specifies a float number as the default time elapse value.
In the next subsections, we will present several applications of (Core) Maude’s simulation
and analysis commands. In most of these applications we will consider the maximal tick mode
(otherwise it will be clearly stated), and we will refer explicitly to the additional constraints
imposed on the tick rule by the corresponding Real Time Maude command. Note that these
constraints, together with the tick rule, will be automatically generated by the e-Motions tool
(see Section 7.5). For simulation purposes, we will use the MPN and RTTP examples. For
analysis purposes, we will only use the RTTP example.8
Regarding the RTTP example, we will consider all the rules described in Section 7.2.4.
Regarding the MPN example, we will consider all the rules described in Section 7.2 but the
RemoveOffPhones rule and a) battery consumption will be modeled by the BatteryConsumption ongoing rule (see Figure 7.10), and b) the SwitchOn atomic rule (see Figure 7.5) will
be turned into a normal (non-soft) rule—we will make phones to be switched on as soon as
possible. These considerations have been taken into account to ease the interpretation of the
simulation results. Finally, since both examples have a rule to generate the initial configuration of the system, the initial model that we will specify in the application of simulation and
analysis commands will be in both cases empty.
op mpnModel : −> @Model .
eq mpnModel = @MPNs@ { none } .
op rttpModel : −> @Model .
eq rttpModel = @rttp@ { none } .
7.4.2 Simulation
Given a Maude specification as the one described in the previous sections, it can be executed
by just successively applying equations and rewrite rules on an initial term. For this purpose,
we can make use of Maude’s rewrite and frewrite as done with untimed specification.
However, in real-time systems it is often more natural to measure and control the rewriting by
the total duration of a computation than by the number of rewrites performed. In this section
we will show how we can specify a time bound for a simulation.
For instance, let us explore a possible execution for the MPN system in six time units. To
specify this time bound, we have to add the following condition to the tick rule: (T plus
8
The MPN example is composed of a large number of rules. This issue, together with the high freedom that
the system offers (calls do not have a specific duration, they can be performed to any phone at almost any moment
of time, etc.), results in a high number of reachable states.
166
TE) le toRat(6). This condition will forbid time to elapse beyond six time units. Then,
we use the rewrite command as follows:
Maude> r e w r i t e init ( mpnModel ) .
The init operation adds to the model the clock and counter objects used by our infrastructure (see Section 7.3), and the time stamp associated to each real-time state (see Section 2.2.3.1).
op init : @Model −> ClockedSystem .
eq init ( MM { OBJSET } )
= { MM { < ’ids@ : Counter | value : 0 >
< ’rdm@ : Counter | value : 0 >
< ’clk@ : Clock | time : zero >
OBJSET } } in time zero .
As a result of the rewriting, Maude provides the following term:
{ @MPNs@ {
< ’0 : AtomicActionExec | participants : Set{ ’1 ; ’2 ; ’3 ; ’4 ; ’5 ; ’6 ; ’7} #
variables : Set{mt} # startingTime : 0 # endingTime : 0 # action : "InitialModel" #
maxTimer : 0 # minTimer : 0 # executionTime : 0 # status : realized >
< ’1 : ObjectRole | actualObject : ’8 # role : "p1" >
< ’5 : ObjectRole | actualObject : ’12 # role : "a1" >
< ’6 : ObjectRole | actualObject : ’13 # role : "a2" >
< ’7 : ObjectRole | actualObject : ’14 # role : "mpn" >
< ’8 : Phone | dialedCalls : OrderedSet{mt−ord} # receivedCalls : OrderedSet{mt−ord} #
contacts : OrderedSet{ ’10 # ’11 # ’9} # number : 111 # on : true # battery : 94 #
coverage : 1 # bps : 1 # vx : 1 # vy : 0 # xPos : 11 # yPos : 45 >
contacts : OrderedSet{ ’10 # ’11 # ’8} # number : 222 # on : true # battery : 44 #
coverage : 1 # bps : 1 # vx : 0 # vy : −1 # xPos : 45 # yPos : 29 >
contacts : OrderedSet{ ’11 # ’8 # ’9 } # number : 333 # on : true # battery : 94 #
coverage : 1 # bps : 1 # vx : 0 # vy : 1 # xPos : 15 # yPos : 21 >
contacts : OrderedSet{ ’10 # ’8 # ’9 } # number : 444 # on : true # battery : 44 #
coverage : 2 # bps : 1 # vx : −1 # vy : 0 # xPos : 59 # yPos : 25 >
< ’12 : Antenna | xPos : 25 # yPos : 35 >
< ’14 : MPN | els : OrderedSet{ ’10 # ’11 # ’12 # ’13 # ’8 # ’9} # xSize : 80 #
ySize : 50 >
< ’15 : AtomicActionExec | participants : Set{ ’16} # variables : Set{mt} #
startingTime : 0 # endingTime : 5 # action : "SwitchOn" # maxTimer : 0 #
minTimer : 0 # status : realized >
< ’16 : ObjectRole | actualObject : ’10 # role : "p" >
< ’17 : OngoingActionExec | participants : Set{ ’18 ; ’19} # variables : Set{mt} #
startingTime : 0 # endingTime : 6 # action : "Moving" # maxTimer : null #
upperBoundTimer : null >
< ’35 : AtomicActionExec | participants : Set{ ’36 ; ’37} # variables : Set{mt} #
startingTime : 5 # endingTime : 6 # action : "Coverage" # maxTimer : 0 #
< ’37 : ObjectRole | actualObject : ’12 # role : "a" >
< ’38 : OngoingActionExec | participants : Set{ ’39} # variables : Set{mt} #
startingTime : 5 # endingTime : 6 # action : "BatteryConsumption" # maxTimer : 95 #
startingTime : 5 # endingTime : 6 # action : "BatteryConsumption" #
maxTimer : 45 #
168
startingTime : 6 # endingTime : null # action : "BatteryConsumption" #
maxTimer : freeze ( ’ 1 0 . battery / ’10 . bps ) # upperBoundTimer : null >
startingTime : 6 # endingTime : null # action : "Moving" # maxTimer : freeze ( null ) #
maxTimer : freeze ( ’ 1 1 . battery / ’11 . bps ) # upperBoundTimer : null >
< ’80 : AtomicActionExec | participants : Set{ ’81 ; ’82} # variables : Set{ ’83} #
startingTime : 6 # endingTime : null # action : "Call" # maxTimer : 30 # minTimer : 20 #
executionTime : 0 # status : unfinished >
< ’83 : Variable | name : "initTime" # value : 6 >
maxTimer : freeze ( ’ 8 . battery / ’8 . bps ) # upperBoundTimer : null >
maxTimer : freeze ( ’ 9 . battery / ’9 . bps ) # upperBoundTimer : null >
< ’94 : AtomicActionExec | participants : Set{ ’95 ; ’96} # variables : Set{ ’97} #
startingTime : 6 # endingTime : null # action : "Call" # maxTimer : 30 #
minTimer : 20 # executionTime : 0 # status : unfinished >
< ’clk@ : Clock | time : 6 >
< ’ids@ : Counter | value : 98 >
}}
in time 6
The resulting term includes the model objects of our MPN example (see objects whose identifiers go from ’8 to ’14) as well as the objects included by our e-Motions infrastructure (see
the remaining objects). All performed ongoing and atomic actions are captured by their corresponding AtomicActionExec and OngoingActionExec objects, respectively. Actions that
have been triggered but not finalized are also captured (see those atomic and ongoing action
executions whose endingTime is set to null). We can see by having a look at the ’ids@
counter object that 98 objects have been created. However, not all of them will be found in
the final result: ongoing action execution elements that represent consecutive executions of the
same ongoing action with the same set of participants are combined (see Section 7.3.5.2). In
six time units, all model objects have been created (by the InitialModel action), the four phones
have been switched on, and their coverage and position have been updated. Furthermore, two
calls have started (see atomic action executions ’80 and ’94) but not finished.
More interesting is the result given by simulating the system for 100 time units. This result
can be obtained following the same procedure: firstly, we add a condition to the tick rule ((T
plus TE) le toRat(100)), and secondly, we use the rewrite command as follows:
Maude> r e w r i t e init ( mpnModel ) .
In this case, Maude provides the following result:
{ @MPNs@ {
< ’8 : Phone | coverage : 0 # bps : 1 # vx : −1 # vy : 0 # xPos : 55 # yPos : 45 #
dialedCalls : OrderedSet{ ’309 # ’536} # receivedCalls : OrderedSet{mt−ord} #
170
contacts : OrderedSet{ ’9 # ’11 # ’10} # number : 111 # on : false # battery : 0 >
< ’9 : Phone | coverage : 2 # bps : 1 # vx : 0 # vy : −1 # xPos : 45 # yPos : 35 #
dialedCalls : OrderedSet{mt−ord} # receivedCalls : OrderedSet{ ’310 # ’537} #
contacts : OrderedSet{ ’10 # ’8 # ’11} # number : 222 # on : false # battery : 0 >
< ’10 : Phone | coverage : 0 # bps : 1 # vx : 0 # vy : 1 # xPos : 15 # yPos : 15 #
dialedCalls : OrderedSet{ ’296 # ’523 # ’561} # receivedCalls : OrderedSet{mt−ord} #
contacts : OrderedSet{ ’8 # ’9 # ’11 } # number : 333 # on : false # battery : 0 >
< ’11 : Phone | coverage : 2 # bps : 1 # vx : 1 # vy : 0 # xPos : 35 # yPos : 25 #
dialedCalls : OrderedSet{mt−ord} # receivedCalls : OrderedSet{ ’297 # ’524 # ’562} #
contacts : OrderedSet{ ’9 # ’8 # ’10 } # number : 444 # on : false # battery : 0 >
< ’14 : MPN | els : OrderedSet{ ’10 # ’11 # ’12 # ’13 # ’8 # ’9} # xSize : 80 #
ySize : 50 >
< ’296 : CallRecord | contact : ’11 # startingTime : 6 # duration : 20 >
...
}} in time 100
We only show the model objects of our MPN example for readability reasons. In 100 time
units, all phones are off (they all have run out from battery), phone ’8 has performed two calls
to phone ’9, and phone ’10 has performed three calls to phone ’11. All calls have had a
duration of twenty time units except the last one, which was performed from phone ’10 to
phone ’11 after 46 time units of simulation, and had a duration of four time units. Since
phone ’11 had only 50 battery units when it was created, we can see that the call has been
interrupted by the BatteryOffCallee rule, i.e., the callee ran out out battery after four time units
participating in the call.
Let us now explore a possible execution for the RTTP system in 500 time units. Again, we
add the corresponding tick rule condition (in this case (T plus TE) le toRat(500)), and
we use the rewrite command as follows:
Maude> r e w r i t e init ( rttpModel ) .
The result of the simulation is the following Maude term:
{ @rttp@ {
< ’6 : Node | receivedMessages : Sequence{ ’21 # ’45 # ’69 # ’93 # ’117} #
localClock : ’8 # neighbors : Set{ ’7} >
< ’7 : Node | receivedMessages : Sequence{mt−ord} # localClock : ’9 #
neighbors : Set{mt} >
< ’8 : Clock | time : 500 >
< ’9 : Clock | time : 500 >
< ’10 : Network | nodes : Set{ ’6 ; ’7} >
< ’21 : Message | initiator : ’6 # responder : ’7 # requestTime : 0 # rtt : 40 >
...
}} in time 500
As expected, we can see that five rounds of the protocol has been successfully realized. Node
’6 has been the initiator, while node ’7 has been the responder (they correspond to the n1 and
n2 nodes depicted in Figure 7.24, respectively). In this case, all the RTT values are of 40 time
units. Recall that classes, attributes and references are qualified with their containers’ names
(although not shown here for readability reasons), and therefore clocks defined for the RTTP
example (of class Clock@rttp) will not be confused with the clock instance provided by our
infrastructure (of class Clock@MGBehavior).
Finally, we can also simulate a system with no time limit by simply not adding a time bound
constraint to the the tick rule. In both of our examples, this will result in a non terminating
execution. The reason is that we have a periodic action without a defined time upper bound:
the Coverage (in the MPN system) and the Request (in the RTTP system) rules will be tried
to be triggered every 5 and 100 time units, respectively. If we do not want to add a time bound
for the simulation, we can define a time upper bound for these periodic rules, or we can specify
an upper bound for the number of rule applications in the rewrite or frewrite commands
as we have done for untimed specifications.
7.4.2.1
Querying the Result of a Simulation
As previously mentioned, the result of a simulation includes the model objects of the DSML,
and the objects included by our e-Motions infrastructure, such as the objects that represent the
performed actions. This result gives us a lot of useful information about the simulation, which
can be further analyzed to reason about the behavior of the system. However, the way in which
this information is presented (as a term of sort @Model) makes it hard for users to analyze
it. To mitigate this, our infrastructure provides then several operations to query the result of a
simulation, and to present it in a more readable way. The complete list of these operations can
be found in Appendix D.
For instance, the finalizedActions operation returns information on the actions that
172
have been triggered and finalized (either realized, interrupted, or aborted); the currentActions
operation returns information on the actions that have been triggered but not finalized. Assuming that we have stored the result of the simulation of the MPN system in six time units in a
Maude constant named resultMPNIn6, the result of the command:
Maude> r e d u c e currentActions ( resultMPNIn6 ) .
is the following:
( "BatteryConsumption" started at 6 with ’ 1 0 )
( "Moving" started at 6 with ( ’ 1 0 ;
’14) )
( "BatteryConsumption" started at 6 with ’ 1 1 )
( "Call" started at 6 with ( ’ 1 0 ;
’14) )
’11) )
( "BatteryConsumption" started at 6 with ’ 8 )
’8) )
( "BatteryConsumption" started at 6 with ’ 9 )
( "Call" started at 6 with ( ’ 8 ;
’9) )
’9) )
The result is a list of elements composed of the name of the action, the time at which the action
was triggered, and the set of the identifiers of the participant elements.
In a similar way, if we type:
Maude> r e d u c e finalizedActions ( resultMPNIn6 ) .
we obtain a list with the finalized actions of the system:
( "InitialModel" performed in [ 0 , 0 ] with ( ’ 1 0 ; ’11 ; ’12 ; ’13 ; ’14 ; ’8 ;
’9) )
( "SwitchOn" performed in [ 0 , 5 ] with ’ 1 0 )
( "Moving" performed in [ 0 , 6 ] with ( ’ 1 0 ;
’14) )
( "SwitchOn" performed in [ 0 , 5 ] with ’ 1 1 )
’14) )
( "SwitchOn" performed in [ 0 , 5 ] with ’ 8 )
’8) )
( "SwitchOn" performed in [ 0 , 5 ] with ’ 9 )
’9) )
( "Coverage" performed in [ 5 , 6 ] with ( ’ 1 0 ;
’12) )
( "BatteryConsumption" performed in [ 5 , 6 ] with ’ 1 0 )
’13) )
( "BatteryConsumption" performed in [ 5 , 6 ] with ’ 1 1 )
’8) )
( "BatteryConsumption" performed in [ 5 , 6 ] with ’ 8 )
’9) )
( "BatteryConsumption" performed in [ 5 , 6 ] with ’ 9 )
’9) )
The elements of this list also include the time at which the action was finalized. By carefully
observing this list, we realize that the Coverage rule has been applied for phone ’9 (whose
number is 222) twice at the same moment of time 5. The reason is that after five time units the
phone is at the same Manhattan distance from both antennas, and therefore the rule is applied
once per each antenna. Notice that this behavior is perfectly valid. However, if we would want
to avoid this kind of situations, we could, e.g., include another NAC pattern in the Coverage
rule that forbids (by means of an action execution element) the application of the rule it is
already being applied to the same phone p.
7.4.3 Reachability Analysis
The Maude search command allows us to explore (following a breadth-first strategy) the
reachable state space in different ways. In Section 6.2.2, we showed how this command may
be parameterized by an upper bound on the number of solutions to look for. We also showed
how it can be bounded by a maximum number of rule applications. In this section, we will
show how the search command can be used to look for states which are reachable in a certain
time interval (starting from the initial state).
As a first example, let us check that the local clocks of the RTTP example are always
synchronized. Since we know that the Request periodic rule will be tried to be triggered
every 100 time units (i.e., the number of states reachable from the initial state is infinite), we
want to bound the search to 500 time units. Following the same procedure applied in the
previous subsection, we will add the following condition to the tick rule: (T plus TE) le
toRat(500). Then, we will look for a state that does not satisfy the invariant, i.e., we will
look for a state on which two clocks have a different time value. If no solution is found, we
are guaranteed that (starting from the initial model) clocks will always be synchronized. Given
variables O1 and O2 of sort Oid, CT1 and CT2 of sort Int, OBJSET of sort Set{@Object},
and T of sort Time, we can look for the undesired state by issuing the following command:
Maude> s e a r c h init ( rttpModel ) =>∗
{ @rttp@ { < O1 : Clock | time : CT1 >
< O2 : Clock | time : CT2 >
OBJSET }} in time T
such that CT1 =/= CT2 .
No solution .
As expected, no solution is found.
A search can also be bounded with a lower bound limit, i.e., we can look for states that are
reachable in a certain time interval. For instance, we may be interested in knowing whether
the RTT value of any message may exceed 40 time units in the second round, i.e., between 100
and 199 time units. To specify the upper time bound, we add the condition (T plus TE) le
174
toRat(199) to the tick rule. To specify the lower time bound, we will include an additional
condition to the search command. Given variables O of sort Oid, RTT of sort Int, OBJSET
of sort Set{@Object}, SFS of sort Set{@StructuralFeatureInstance}, and T of sort
Time, we can look for the mentioned state as follows:
Maude> s e a r c h [ 1 ] init ( rttpModel ) =>∗
{ @rttp@ { < O : Message | rtt : RTT # SFS >
OBJSET }} in time T
such that ( RTT > 4 0 ) / \ ( 1 0 0 le T ) .
No solution .
Again, Maude does not find any solution. In fact, an RTT value, as defined by the behavioral
rules, will always range from ten to forty time units. We can also check this new property, e.g.,
for the five first rounds, by adding the (T plus TE) le toRat(500) condition to the tick
rule:
OBJSET }} in time T
such that ( RTT > 4 0 ) or ( RTT < 1 0 ) .
No solution .
7.4.3.1
The Role of Tick Modes in the Analysis
As we already mentioned, the user has to consider that all rewriting will be performed according to the chosen time sampling strategy (tick mode). There is in general no guarantee that
all “interesting” behaviors are covered by a time sampling strategy, which of course impacts
search and model checking [91].
To illustrate this issue, let us consider again the RTTP example, and let us search for a
state in the first round of the protocol in which a message has a RTT of twenty time units. As
modeled with our behavioral rules, the user could think that this state is reachable. To verify
it, we add the (T plus TE) le toRat(99) condition to the tick rule, and we use the
search command as follows:
OBJSET }} in time T
such that RTT == 20 .
No solution .
Maude does not find any solution. In fact, if we have a look at the result of the simulation
performed in Section 7.4.2, we see that every message has an RTT of 40 time units. If we try
to look for a state that contains a message with an RTT different from 40, we do not find any
solution again.
OBJSET }} in time T
such that RTT =/= 40 .
No solution .
The reason is that we are using the maximal tick mode when performing the analysis. With
this tick mode, time will advance by the maximum time elapse of the system, which is computed by the mte operation. Since both Request and Response rules have a maximal duration
of 20 time units, and no other event will cause that time advances using a different granularity,
the result of the mte function will always make these actions to consume its maximal duration.
If we want time to elapse with a smaller granularity we can, e.g., use the default tick mode to
specify a default time elapse. With the default tick mode, time will advance by the smallest
value of the maximum time elapse of the system and the specified default value. For instance,
if we specify a value of five time units, we ensure that time will advance five time units at most.
Let us we perform the same analysis again but taking into account this default tick mode, which
will be dictated by the following tick rule in our analysis:
c r l [ tick ] :
{MODEL} in time T
i f TE : = minT ( mte ( MODEL ) , toRat ( 5 ) )
/ \ ( T plus TE ) le toRat ( 9 9 )
/ \ TE =/= zero .
Now, we obtain the following result:
Solution 1 ( state 2 0 8 3 )
OBJSET −−> < ’0 : AtomicActionExec | participants : Set{ ’1 ; ’2 ; ’3 ; ’4 ; ’5} #
variables : Set{mt} # startingTime : 0 # endingTime : 0 #
action : "InitialModel" # maxTimer : 0 # minTimer : 0 # executionTime : 0 #
status : realized >
< ’1 : ObjectRole | actualObject : ’6 # role : "n1" >
< ’3 : ObjectRole | actualObject : ’8 # role : "c1" >
< ’4 : ObjectRole | actualObject : ’9 # role : "c2" >
< ’5 : ObjectRole | actualObject : ’10 # role : "net" >
< ’6 : Nodep |
receivedMessages : Sequence{ ’21} # localClock : ’8 #
neighbors : Set{ ’7} >
< ’7 : Node | receivedMessages : Sequence{mt−ord} # localClock : ’9 #
176
neighbors : Set{mt} >
< ’8 : Clock | time : 20 >
< ’9 : Clock | time : 20 >
< ’10 : Network@rttp | nodes@Network@rttp : Set{ ’6 ; ’7} >
< ’11 : AtomicActionExec | participants : Set{ ’12 ; ’13 ; ’14 ; ’20} #
variables : Set{ ’15} # startingTime : 0 # endingTime : 5 # action : "Request" #
maxTimer : 15 # minTimer : 0 # status : realized >
< ’14 : ObjectRole | actualObject : ’8 # role : "c" >
startingTime : 0 # endingTime : 20 # action : "LocalTimeElapse" #
maxTimer : null # upperBoundTimer : null >
startingTime : 0 # endingTime : 20 # action : "LocalTimeElapse" #
maxTimer : null # upperBoundTimer : null >
< ’20 : ObjectRole | actualObject : ’21 # role : "m" >
< ’22 : AtomicActionExec | participants : Set{ ’23 ; ’24 ; ’25 ; ’26} #
variables : Set{mt} # startingTime : 5 # endingTime : 20 # action : "Response" #
maxTimer : 5 # minTimer : 0 # status : realized >
< ’26 : ObjectRole | actualObject : ’21 # role : "m" >
< ’clk@ : Clock | time : 20 >
< ’ids@ : Counter | value : 39 >
O −−> ’21
SFS −−> initiator : ’6 # responder : ’7 # requestTime : 0
RTT −−> 20
T −−> 20
As expected, now Maude does find a solution. Note that we searched for only one solution.
Without this restriction all possible solutions given the specified tick size would have been
shown.
In summary, by changing the tick mode, we can cover different “interesting” behaviors. In
particular, making time to elapse using a smaller granularity, we ensure that more behaviors
may be covered, although of course at the expense of a greater memory and time usage. For
discrete domains, we can select one time unit as the default time elapse value to cover all the
possible behaviors. For dense time domains, if the search command does not find any solution,
we cannot conclude that a state satisfying the search pattern is not reachable. In these cases,
the search command analyzes all behaviors up to the given strategy for advancing time, and
we could only say that such a state is not reachable taking into account only the behaviors that
the selected tick mode covers. On the other hand, if a counterexample is found, it is always a
real counterexample. The same applies to model checking analysis. The interested reader is
referred to [90] for general criteria ensuring that maximal time sampling analyses are indeed
complete. In these cases, the completeness results shown in this work justify using the maximal
time sampling strategy instead of exhaustively visiting each time instant.
7.4.3.2
Reasoning about Action Executions
Another interesting property of our approach is that we can reason not only about system states
but also about action executions. Note that a same system state may usually be reached by performing different sequences of actions, and checking only system states will not always give us
information about the performed actions. With our approach, we can look for, e.g., undesirable
action occurrences, actions that has been interrupted or aborted, or invalid sequences of action
executions.
For example, let us show how the search command can be used to look for actions that have
been aborted. In this case, we are going to look for a state in the first two rounds of the protocol
on which a Request action has been aborted. We add the (T plus TE) le toRat(199)
condition to the tick rule, and we use the search command as follows:
{ @rttp@ { < O : AtomicActionExec | action : "Request" # status : aborted # SFS >
OBJSET }} in time T .
Maude does not find any solution. In fact, an action is aborted when one of its participants is
removed from the system, and there is no rule in the system that may lead to this situation.
Our approach also allow us to look for, e.g., specific sequences of actions. For instance,
we can be interested in knowing whether a responder always retransmits a message at the
same moment of time at which it receives it. Given variables T, T1 and T2 of sort Time, O,
O1, O2, OR1 and OR2 of sort Oid, OBJSET of sort Set{@Object}, SFS1 and SFS2 of sort
Set{@StructuralFeatureInstance}, and ORS1 and ORS2 of sort MSet{OCL-Exp}, we
can look for a counterexample by using the search command as follows:
Maude> s e a r c h [ 1 ] init ( rttpEmptyModel ) =>∗
{ @rttp@ { < O1 : AtomicActionExec | action : "Request" # participants : Set{OR1 ; ORS1} #
endingTime : T1 # SFS1 >
< OR1 : ObjectRole | actualObject : O # role : "m" >
< O2 : AtomicActionExec | action : "Response" # participants : Set{OR2 ; ORS2} #
startingTime : T2 # SFS2 >
< OR2 : ObjectRole | actualObject : O # role : "m" >
OBJSET }} in time T such that T1 =/= T2 .
178
Maude does not find any solution. Note that we are looking for a state on which a Request and a
Response action executions are applied over the same message O but they are not consecutive,
i.e., the ending time of the Request action execution do not coincide with the starting time
of the Response action execution. Since the maximal tick mode does not cover all possible
behaviors, the fact that no state is found starting from our initial model does not allow us to
extract any final conclusion on the property we are tying to verify. However, if we perform the
same analysis but using the default tick mode to specify a default time elapse of one time units,
we obtain the same result, and therefore we can conclude that (starting from our initial model)
a responder always retransmits a message at the same moment of time at which it receives it.
7.4.4 LTL Model Checking
Maude offers a linear temporal logic explicit-state model checker [42, 59], which allows us to
check whether every possible behavior starting from a given initial model satisfies a given temporal logic property. As we mentioned in Section 6.2.3, Maude’s model checker can be used to
prove safety and liveness properties of rewriting systems when the set of states reachable from
an initial state is finite. In this section we will show how adding a time bound to consider only
behaviors up to the bound provides us a way to restrict a potentially infinite set of reachable
states to a finite set which can then be model checked.
In [91], the authors describe the changes that must be performed to a timed module to
make the specifications susceptible to model checking. Considering the encoding presented in
Section 7.3, these modifications only affect the tick rule, but it differs from the modifications
shown in previous sections. In this case, we need to add a self-loop for each state which could
tick beyond the time bound in one step. Assuming that we want to consider a time bound of
500 time units, the corresponding tick rule will be modeled as follows:
c r l [ tick ] :
{MODEL} in time T
=> i f ( ( T plus TE ) le toRat ( 5 0 0 ) )
then {delta ( MODEL , TE ) } in time ( T plus TE )
else {MODEL} in time T fi
/ \ TE =/= zero .
Note that in this tick rule we have considered the maximal tick mode. Of course, the default tick mode could be considered instead by modifying the value assigned to TE (as shown
previously).
Once we have the appropriate rewrite system on which we can perform model checking,
we are ready to define the predicates that will be involved in the specification of safety and liveness properties (see Section 6.2.3). In our example, we define three predicates: requested,
responded and stored. They refer, respectively, to whether a message has been sent (the
request), retransmitted (the response), or it is currently stored. Note that the first two predicates refer to performed actions, i.e., they refer to whether a message has been a participant of
a realized Request or Response action execution, respectively.
v a r s O O ’ OR : Oid .
var L L ’ : List{OCL−Exp} .
var S : MSet{OCL−Exp} .
var T : Time .
ops stored requested responded : Oid −> Prop .
eq { @rttp@ { < O : Node | receivedMessages : Sequence{ L # O ’ # L ’ } # SFS >
< O ’ : Message | SFS ’ >
OBJSET } } in time T
| = stored ( O ’ ) = true .
eq { @rttp@ { < O : AtomicActionExec | action : "Request" # status : realized #
participants : Set{OR ; S} # SFS >
< OR : ObjectRole | actualObject : O ’ # role : "m" >
| = requested ( O ’ ) = true .
eq { @rttp@ { < O : AtomicActionExec | action : "Response" # status : realized #
participants : Set{OR ; S} # SFS >
< OR : ObjectRole | actualObject : O ’ # role : "m" >
| = responded ( O ’ ) = true .
We have only specified for what ClockedSystem patterns the given state predicates evaluate
to true, since the remaining case is already included in our Maude infrastructure.
var CS : ClockedSystem .
var PROP : Prop .
eq CS | = PROP = false [ owise ] .
After defining these predicates, we are ready to model check different LTL properties.
Making use of the henceforth LTL connective ([]), we can model check, for instance, that
once a message (say ’21) is stored, it will not be removed (i.e., it will remain stored), as
follows:
Maude> r e d u c e modelCheck ( init ( rttpModel ) , [ ] ( stored ( ’ 2 1 ) −> [ ] stored ( ’ 2 1 ) ) ) .
180
Or, if we make use of the eventually LTL connective (<>) too, we can model check, for example, that a message that is sent as a request, it will be retransmitted (as a response) at any
time:
Maude> r e d u c e modelCheck ( init ( rttpModel ) , [ ] ( requested ( ’ 2 1 ) −> <> responded ( ’ 2 1 ) ) ) .
7.5 The e-Motions Tool
The e-Motions tool [99, 100, 107] is a language and a graphical framework developed for
Eclipse that supports the specification, simulation, and formal analysis of real-time systems.
The dynamic behavior of a DSML is specified by means of graphical in-place model transformation. In particular, the tool supports the two extensions presented in this chapter: the model
of time and the mechanism to state action properties.
There are two models involved in the definition of the behavior of a DSML: a graphical
concrete syntax (gcs) model and a behavior model. The gcs model defines the graphical appearance of the concepts of the DSML’s metamodel, and the behavior model makes use of it to
define the behavioral rules of the system. The gcs model is automatically generated from the
definition of our DSML’s metamodel. Once created, we only have to assign a picture to each
metaclass of our metamodel. Objects whose metaclasses do not have assigned any picture will
be drawn as yellow rectangles (the default shape). Figure 7.25 shows the gcs model we have
defined for the MPN example.
Figure 7.25: A gcs model for the MPN example.
Gcs models conforms to the GCS metamodel, which is depicted in Figure 7.26. The root
of gcs models is a MetamodelGD (metamodel graphical definition) element. Then, it contains
as many PackageGD and ClassGD elements as EPackage and EClass elements belong to the
DSML’s metamodel. Each PackageGD and ClassGD element will refer to the corresponding
7.5. T HE e-Motions T OOL
181
EPackage and EClass element for which they are defining its graphical appearance. The user
has only to set the figurePath attribute of the ClassGD elements, which refers to the path of the
picture that we want to assign to the corresponding class.
Figure 7.26: The GCS metamodel.
The behavior model uses the gcs model to graphically represent the behavioral rules of our
DSML. A behavior model is associated with two editors: the behavior editor, and the rule
editor. The behavior editor is used to define the set of rules and helpers that constitute the
behavior of the DSML. The rule editor is used to define the components of a specific rule: its
variables, its patterns, the elements contained in the patterns, etc. Figure 7.27 shows the two
editors for the MPN example.
Once we have defined the behavioral specifications of our DSML, we can perform simulation and analysis over our DSML models. The e-Motions tool automatically generates the
Maude specifications of the DSML’s metamodel, DSML’s behavior, and an initial model, following the Maude encoding presented in this thesis. Currently, simulation can be performed
directly in the Eclipse platform without being aware of Maude at all. However, in order to
perform reachability and model checking analysis we need to move to the Maude environment
(which is also available for the Eclipse platform [5]).
Figure 7.28 shows the simulation window of the e-Motions tool. To perform a simulation,
we have to select the structural and behavioral specifications of our DSML (i.e., the DSMLs’
metamodel and behavior model), and the file where we want the resulting EMF model to be
stored. Additionally, we may specify a default time elapse, a time bound for the simulation,
and an initial model for it. The resulting model will conform to the DSML’s metamodel, i.e.,
182
Figure 7.27: The behavior and rule editors of the e-Motions tool.
Figure 7.28: The simulation window of the e-Motions tool.
it will only contain DSML model objects (all the objects generated by our infrastructure in
the process of the simulation will be ignored). If the default time elapse is left undefined, the
maximal tick mode will be considered; otherwise, the default tick mode will be applied. In
case we do not specify an initial model, the tool will consider an empty model (note that we
can create a model by means of a rule, see Section 7.2.3).
The e-Motions tool as well as its documentation and several examples defined with it can
be downloaded from our website [2].
7.6. R ELATED W ORK
183
7.6 Related Work
As we mentioned in Section 6.5, there are several approaches that propose in-place model
transformation to deal with the behavior of DSMLs, from textual to graphical. However, none
of them includes a quantitative model of time. When time is needed, it is usually modeled
in an intrusive way, by adding clocks or timers to the DSML’s metamodel. This is, for example, the approach followed in [64], where graph transformation systems are provided with
a model of time by representing logical clocks as a special kind of node attributes. These
clocks are handled in the same way as common objects, which forces designers to modify the
DSML’s metamodel to include time aspects. Furthermore, this does not constrain designers
from unwillingly defining time-inconsistent sequences of states. This work, based on Time
Environment-Relationship (TER) nets [62] (an approach to modeling time in high-level Petri
nets) does not extend the base formalism but specializes it (as its predecessor), and enables the
incorporation of the theoretical results of graph transformation. The verification of the system time-consistency is achieved by introducing several semantic choices and a global monotonicity theorem, which provides conditions for the existence of time ordered transformation
sequences.
Syriani and Vangheluwe propose in [118] to complement graph grammar rules with the
Discrete EVent system Specification (DEVS) formalism to model time-dependent behavior.
In particular, they embed graphs in DEVS events and individual transformation rules in DEVS
blocks. This embedding allows users to describe how many time units are consumed to execute
a rule. Other time properties such as periodicity or a non-deterministic duration of a rule are
not considered. The approach requires specialized knowledge and expertise on the DEVS formalism, and does not provide analysis capabilities: system evaluation is accomplished through
simulation.
Boronat and Ölveczky have recently proposed in [26] a collection of built-in timed constructs for defining the timed behavior of model-based systems that are specified with in-place
model transformations. These timed constructs are basically clocks and timers, and can be
added to the DSML’s metamodel itself, or separately defined in another metamodel (in a nonintrusive way). In-place model transformations are formalized into (a simplified version of)
Real-Time Maude, where the behavioral semantics of these timed constructs is predefined.
The model of time they use can be considered as a straightforward translation from the RealTime Maude model of time: opposite to our approach, in which in-place rules are extended
with time-related constructs and then transparently encoded in Real-Time Maude with timer
184
objects, they propose handling these timers directly in the model transformation. They provide tool support by means of the MOMENT [5, 24] tool, where in-place model transformation are specified textually. As the authors point out, the current MOMENT implementation
only allows untimed analysis, although Real Time-Maude-style time-bounded analysis could
be achieved by manually modeling a timer for that purpose. Finally, note that our approach
subsumes the definition of their timed constructs by simply defining ongoing rules that model
the corresponding behavior of the clocks and timers (by increasing and decreasing their values,
respectively).
Lara and Vangheluwe has also very recently proposed in [50] a model of time for graph
transformation. Using the analogy of their base formalism, Time Petri Nets (TPNs, [82]), they
provide graph transformation rules with a time interval. Similarly to our approach, this time
interval represents the minimum and the maximum amount of time that the action may take.
However, there are two main differences with respect to the time interval that we propose for
atomic actions: a) their time interval is static, i.e., the duration of the rule cannot depend, for
instance, on properties of the matched objects, and b) an occurrence of a rule (a match) must be
continuously maintained in order for the rule to be finally applied, i.e., LHS and NAC patterns
act as an “invariant” of the rule instead of as a precondition. In a previous work [107], we
gave LHS and NAC patterns the same semantics. Rules that were triggered but which LHS or
NAC patterns were not satisfied at some moment of time during its execution were canceled by
the system. This resulted in many unexpected rule abortions when the user simulate him/her
system. For instance, a phone needs coverage to perform a call, but if it runs out of coverage in
the middle of a conversation, the call has not to be necessary aborted immediately (the phone
may not receive voice signal for a while, but the communication can be recovered). In the work
presented in this thesis, LHS and NAC patterns act as a precondition, and the user can explicitly
model any abnormal situation (exception) by using action executions. Furthermore, we also
provide another type of timed rules to model ongoing actions. Their approach also supports
on-the-fly model-checking of reachability properties by encoding the DSML specifications into
TPNs. This encoding is not performed automatically: the user has to select which elements
may be encoded as places and which elements may be encoded as tokens.
None of the mentioned extensions for in-place model transformation provides a mechanism
to state action properties, i.e., to refer to and reason about actions as first class citizens.
Further works make use of an MDE methodology different from in-place model transformation for modeling real-time systems, such as Real-Time Fujaba, MARTE or AADL. RealTime Fujaba [31, 32] aims at supporting the model-driven development of correct software for
7.6. R ELATED W ORK
185
safety-critical, networked, real-time systems. The tool supports the modeling of the system
structure by means of UML component diagrams, and the modeling of real-time behavior by
means of real-time extended UML state machines. These state machines extensions comprise
time invariants, clock resets associated with entry and exit methods, worst case execution times
for the entry, do and exit methods, and a period for the do method. The resulting specifications
may drive the system to time-inconsistent executions. To partially solve it, they provide (incomplete) algorithms to check the temporal consistency. A way to define incremental model
checking has also been developed to complete this verification.
The Architecture Analysis and Design Language (AADL) [1] is a textual and graphic language used to design the software and hardware architectures of embedded and real-time systems. The language is used to describe the structure of such systems as an assembly of software
components that are mapped to an execution platform. It is based on the component-connector
paradigm. Component descriptions are used to describe functional interfaces of components
(e.g., data inputs and outputs, event inputs and outputs) and performance-related aspects (such
as latency and error handling). Connection characteristics (i.e., asynchronous or synchronous)
among software components have precise operational semantics and are enforced by the AADL
modeling environment.
MARTE [6] is an UML profile that adds capabilities to UML for model-driven development
of real-time and embedded systems. The profile is structured around two concerns, one to
model the features of real-time and embedded systems, and the other to annotate application
models so as to support analysis of system properties. MARTE focuses on performance and
schedulability analysis, although it defines also a general framework for quantitative analysis
which intends to refine/specialize any other kind of analysis. Just like with AADL, when
analysis of non-functional requirements is required, we need to translate the model of a system
into an external formalism that provides verification techniques.
186
Chapter 8
Conclusions and Future Work
8.1 Conclusions
This thesis tries to promote the definition of Domain Specific Modeling Languages (DSMLs)
in a formal and precise way. We want the Model Driven Engineering (MDE) community to
take a step forward and focus beyond purely structural aspects (i.e., models and metamodels).
We want MDE to become a real engineering, where not only model browsers and editors are
needed, but also model analyzers, simulators, matchmakers, quality evaluators, etc. This thesis
tries, among other things, to bring closer two usually separated worlds: modeling and formal
languages.
In this thesis, we have shown how a DSML can be defined in terms of two views: structure
and behavior. We have identified the elements that are involved in the definition of these
views: abstract syntax, concrete syntax and semantics; and we have presented an approach
that prevent the DSML designer from explicitly defining the semantics of the DSML (see
Figure 8.1). Defining the structure and behavior as models separately from a semantic domain
bring several advantages:
• several DSMLs can be defined to specify the structure and behavior of a DSML in a
graphical and intuitive way;
• we can make use of the analysis tools provided by different semantic domains (if we
properly define semantic bridges between the DSMLs used to represent the structure and
behavior of a DSML and the semantic domains themselves); and
• we do not need to be aware of the semantic domains, i.e., if the semantic bridges are
defined in an proper way (by means of automatic model transformations), the DSML
187
188
C HAPTER 8. C ONCLUSIONS AND F UTURE W ORK
designer do not need to have a deep knowledge on the target formalisms, but he/she can
still use their analysis tools.
Figure 8.1: Our approach to define DSMLs.
To define the structural model of a DSML, we have selected the Ecore language, an implementation of the (meta-metamodel) MOF specification developed for the Eclipse platform.
Eclipse is an open source community platform widely used in the MDE community due to
the wide spectrum of (open) modeling tools that it provides, such as model transformation
languages and tools for developing textual and graphical concrete syntaxes for DSMLs.
To define the behavioral model of a DSML, we have developed our own DSML and tool
(for the the Eclipse platform too), called e-Motions, that supports the specification, simulation,
and formal analysis of real-time systems. The e-Motions tool extends in-place model transformation with a model of time and a mechanism to state action properties, easing the specification
of real-time DSMLs’ behavior. In-place model transformation provides a quite intuitive way to
represent the behavior of DSMLs (especially when it enables the use of the graphical concrete
syntax of the language), allowing modelers to perceive themselves as working directly with
domain concepts. The presented extensions were defined to cope with real-time and complex
systems too, and they promote the separation of concerns between the structural and behavioral
specifications: they avoid unnaturally modifying the DSML’s metamodel—which defines the
structural concepts of a DSML—to include time and action properties—which are related to
the behavior of the language—, as done by most of current approaches.
8.1. C ONCLUSIONS
189
Figure 8.2: General view of our approach.
Then, as a proof of concept, we have selected a particular formalism, namely rewriting
logic in Maude, and we have developed all the infrastructure necessary to use it as the target domain on which to provide DSMLs with semantics (see Figure 8.2), and perform model
simulation and (reachability and model checking) analysis. In particular, we have developed
semantic bridges between the Ecore and e-Motions languages and Maude by means of model
transformations. These semantic bridges allow us to benefit from both platforms: an intuitive
way to define the structure and behavior of DSMLs with the Eclipse tools, and a powerful
mechanism to provide models with semantics and to simulate and analyze them with Maude.
The developed infrastructure has also served to provide formal support for other paradigms,
such as Feature-Oriented Software Development [78].
The use of Maude as a semantic domain brings several advantages. With Maude we can
deal with complex structural and behavioral specifications (i.e., not limited to place/transition
systems), and conduct reachability and model-checking analysis on the systems. In addition,
Maude offers an integrated environment and a toolkit for conducting several different kinds
of analysis [42, 43], such as the Church-Rosser checker [53], the coherence checker [54], the
termination tool [52], etc., so we do not need to define several semantic mappings to different
domains to perform each of these analyses. Furthermore, Maude has already been successfully used in software engineering tools and several applications (see, e.g., [80]); it is efficient
enough to be of practical use, able to execute more than three million rewriting steps per second on standard PCs; it has already been integrated in the Eclipse platform; and it performs
simplification of terms modulo equational theories such as associativity, commutativity and
identity, which enables the specification of many model operations at a very high level of ab-
190
straction, and 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 work presented in this thesis has given raise to the development of two tools, the
Maudeling and e-Motions tools, and the integration of our approach with a third one, AToM3 .
• Maudeling is a model management tool that allows users to perform model validation,
subtyping and difference related operations on EMF models, i.e., on models defined in
the Eclipse platform. Model management operations are computed in Maude in a completely transparent way to the user. The development of these tools involved, among
other things, the definition of a metamodel, a parser and a serializer for Maude; model
transformations from EMF models and metamodels to their corresponding Maude representation; and a model transformation from the resulting Maude models to their original
notation in EMF.
• e-Motions is a DSML and graphical framework developed for the Eclipse platform that
supports the specification, simulation and analysis of real-time DSMLs. It enables the
use of the concrete syntax of the DSML to define its corresponding time-dependant behavior, making this task quite intuitive. Contrary to other in-place model transformation
approaches (especially graph transformation ones), the e-Motions tool supports attribute
computations and ordered collections, which are specified by means of OCL expressions.
OCL is fully supported thanks to the mOdCL tool [10]. The current version of the tool
allows us to perform simulation over DSML models being completely unaware of its
target semantic domain (Maude). However, to perform reachability and model checking
we still need to move to the Maude environment. The development of this tools has also
involved (together with the infrastructure already mentioned for the Maudeling tool) the
definition of a model transformation from OCL to the mOdCL tool, the definition of a
model transformation from the e-Motions language to its corresponding Maude encoding, and the integration of the tool with the Maude’s simulation facilities.
• AToM3 is a tool for multi-paradigm modeling based on graph grammars. With AToM3 ,
we can specify the behavior of our DSML by means of graphical graph transformation rules. In collaboration with Juan De Lara and Esther Guerra, we have built a
Maude parser and code generator, and integrated them in AToM3 to provide the tool with
Maude’s reachability analysis capabilities (the integration of the Maude’s LTL model
checking tool is left for future work).
8.2. F UTURE W ORK
191
The development of these tools has involved the use of many other current MDE tools, such
as model transformation languages, code generators, metamodeling tools, etc. Most of these
tools have been evolving at the same time that this thesis was being developed, so we have
been witnesses of the considerable advance of the MDE tool support. In summary, many of
these tools have really helped us in the development of the tool support for this work, and we
may say that some of them are mature enough to be of a great help (e.g., ATL). However, even
being of a great help, there are some tool-related problems that still remain. Some of these
issues follow:
• There is a big amount of modeling tools developed for the Eclipse platform. However,
each of these tools usually has different dependencies with different versions of other
tools. This fact usually makes the user to end up installing different Eclipse configurations to be able to make use of a subset of them.
• One of the tools that really helped us in the definition of the graphical framework developed for the e-Motions tool is GMF. However, when the user tries to provide the graphical
framework with interesting capabilities, he/she has to still manipulate (and understand)
the Java code that GMF generates. Moreover, when the metamodel of his/her DSML
evolves, because of the way that EMF assigns identifiers to objects (by their position in
the tree of the model), the user has not only to add or modify the elements related to this
evolution, but has also to check the correctness of almost every reference of the mapping
model.
8.2 Future Work
There are several lines of work in which we are currently engaged, or that we plan to address
in the near future. In what follows, we present them grouped by topic.
Model management.
So far, our subtyping algorithm takes into account the properties that
we specify per each metamodel element. However, a metamodel can also be enriched with
invariants, by making use, e.g., of OCL. We plan to extend our subtyping algorithm to take
into consideration these invariants. This extension will imply the study of the several possible
relationships between OCL constraints, such as contradiction, inclusion, etc.
In Section 5.1.2.1, we showed how we can apply different relaxations to the subtyping
algorithm to obtain the different kinds of subtyping relationships. When one of these kinds
192
of subtyping, namely subtyping with renaming, flattened subtyping or flattened subtyping with
renaming, is considered, we will usually need to adapt the model operations defined over a
metamodel to make them applicable to any of its subtype metamodels. Therefore, we also
plan to implement a transformative approach to adapt these model operations. In particular,
we would like to define a model transformation that renames the affected elements (in case
of subtyping with renaming) or modifies the classifiers package if an ambiguity is possible (in
case of flattened subtyping).
In Section 5.1.2.1 we presented the do and undo operations. The do operation applies
to a model all the changes specified in a difference model. The undo operation reverts all the
changes specified in a difference model. Intuitively, the undo operation is the inverse operation
of the do operation. We leave as future work the formal proof of the formulas undo(do(Ms ,
Md ), Md ) = Ms and do(undo(Mm , Md ), Md ) = Mm , that implies the formal proof of,
given modelDiff(Mm ,Ms ) = Md , do(Ms ,Md ) = Mm and undo(Mm ,Md ) = Ms . Given
the complexity of the implementation of the difference operation, the use of Maude’s built-in
primitive data types [42], and other features not currently supported by the tools in Maude’s
formal environment [43], they, and in particular its inductive theorem prover [44, 68], cannot be
directly used over the current specifications. We would like to study the possibility of adapting
(or simplifying) our specifications of the model difference to make them a valid input for the
Maude’s theorem prover.
The e-Motions tool.
We are currently working on several extensions for the e-Motions tool.
In the first place, we are in the process of automating the interaction with Maude and its analysis
tools using the native visual notation of the DSML. This will make the use of Maude completely
transparent to users. Regarding reachability analysis, we will reuse the e-Motions rule editor
for defining a search pattern, which will be composed of a LHS pattern and zero or many NAC
patterns. Regarding LTL model checking, we are now studying an intuitive way to represent
state predicates and LTL properties.
We are also working on refining the internal Maude encoding to improve the performance
of real-time simulation and analysis, by reducing the time and memory consumption. In particular, we are studying new mechanisms to decrease the number of generated objects, equations
and rule conditions.
• We are currently integrating in our tool a new mode that do not keep track of realized
actions. In cases where reasoning about realized actions is not needed, this mode will
decrease the number of generated objects substantially. Furthermore, this mode will
8.2. F UTURE W ORK
193
not prevent users from referring to actions that are currently being performed in the
specifications of the behavioral rules, nor to reason about interrupted or aborted actions.
• We are studying a new encoding for normal (non-soft) rules that avoids the generation of
the related mte equation. For this purpose, we are studying how to apply some priority
control mechanisms.
• We are adding more “intelligence” to the model transformation defined from the eMotions language to Maude to reduce the number of generated rule conditions, since
in Maude unconditional rules are notably more efficient. For instance, we want to avoid
the inclusion of attribute conditions that compute (evaluate through mOdCL) basic values
(such as true, 0, etc.) and specify them in the left-hand sides of the rules directly.
Further extensions of the tool include a) to integrate an OCL tool with OCL expression
completion and validation facilities to ease the specification of behavioral rules; b) to integrate
the facilities presented in Section 7.4.2.1 to query the result of a simulation; and c) to support
the definition of non-injective rules, as already done by the AToM3 tool [102]: by generating
different Maude rules for each match possibility.
Untimed search and untimed model checking. In Section 7.4 we showed how we can perform timed simulation, search and model checking over real-time systems. We showed how
time-bounded search and model checking is a reasonably natural way of restricting the possibly
infinite number of reachable states in a system to the finite subset which is reachable within a
given time. However, the set of states reachable from an initial state in a timed specification
may well be finite, in which case the search and model checking should terminate. Currently,
our internal representation of time and action properties adds time information (such as the
starting time of an action or the value of the clock instance) to each system state, making the
reachable state space infinite, unless the specification is terminating. We are studying an alternative encoding that avoids the inclusion of such information to preserve the finiteness of the
reachable state space, being able in that way to perform untimed search and untimed model
checking.
Analysis of behavioral rules.
We have shown how we can make use of the simulation, search
and model checking facilities that Maude provides. However, Maude also offers a powerful set
of analysis tools that we do not have exploited yet, as its termination checker [52] or its confluence checker [53]. By using these and other tools, some of them currently under development,
194
we plan to study the possibility of accomplishing other kinds of analyses over the behavioral
specifications of DSMLs, not only over domain specific models themselves, but also over behavioral rules. For instance, we would like to reason about whether all the models reachable
by the application of a model’s rules satisfy the constraints established by its metamodel.
Non-functional properties and QoS requirements. Once we have provided a way to specify time properties in the behavioral specifications of a DSML, we are studying the integration
of more non-functional properties and QoS requirements into our in-place model transformation. Our first attempts can be found in [122] and [121]. In these works we present an approach
to specify QoS requirements based on the observation of the system actions and of the state of
its objects. For this purpose, we define a metamodel for observer objects whose objective is to
monitor the value of one of these parameters. The observer metamodel can be reused across
different DSMLs, and the behavior of these observers is specified together with the behavioral
rules of the DSML. We show how the approach enables the natural specification of other important features of systems, such as the automatic reconfiguration of the system when the value
of some of the QoS properties change.
8.3 List of Publications
The development of this thesis have given rise to the following publications (listed by category
and in reverse chronological order):
Journal papers
• J. E. Rivera, A. Vallecillo, and F. Durán. Formal specification and analysis of domain
specific languages using Maude. Simulation: Transactions of the Society for Modeling
and Simulation International, 85(11/12):778–792, 2009.
• J. R. Romero, J. E. Rivera, F. Durán, and A. Vallecillo. Formal and tool support for
model driven engineering with Maude. Journal of Object Technology, 6(9):187–207,
Oct. 2007.
Book chapters
8.3. L IST OF P UBLICATIONS
195
• J. E. Rivera, N. Moreno, and A. Vallecillo. Desarrollo de Software dirigido por Modelos.
Chapter 2 of Fábricas de Software: Experiencias, Tecnologı́as y Organización, pages 2960. RAMA, Madrid, July 2007.
International conferences
• J. Troya, J. E. Rivera, and A. Vallecillo.
by observation.
Simulating domain specific visual models
In Proc. of the Symposium on Theory of Modeling and Simulation
(DEVS’10), Orlando, Florida (US), Apr. 2010.
• J. E. Rivera, F. Durán, and A. Vallecillo.
A graphical approach for modeling time-
dependent behavior of DSLs. In Proc. of the IEEE Symposium on Visual Languages and
Human-Centric Computing (VL/HCC’09), pages 51–55, Sept. 2009. IEEE Computer
Society.
• J. E. Rivera, E. Guerra, J. de Lara, and A. Vallecillo. Analyzing rule-based behavioral
semantics of visual modeling languages with Maude. In Proc. of the 1st International
Conference on Software Language Engineering (SLE’08), volume 5452 of LNCS, pages
54–73, 2008. Springer-Verlag.
• J. E. Rivera and A. Vallecillo. Representing and operating with model differences. In
Proc. of the 46th International Conference on Objects, Models, Components, Patterns
(TOOLS’08), volume 11 of Lecture Notes in Business Information Processing, pages
141–160. Springer, 2008.
• J. E. Rivera and A. Vallecillo.
Adding behavioral semantics to models.
In Proc.
of the 11th IEEE International Enterprise Distributed Object Computing Conference
(EDOC’07), pages 169–180. IEEE Computer Society, Oct. 2007.
International workshops
• J. E. Rivera, F. Durán, and A. Vallecillo. On the behavioral semantics of real-time domain specific visual languages. In P. C. Ölveczky, editor, Proc. of the 8th International
Workshop on Rewriting Logic and its Applications (WRLA’10), to appear in LNCS, Paphos, Cyprus, Mar. 2010. Springer-Verlag.
• J. Troya, J. E. Rivera, and A. Vallecillo. On the specification of non-functional properties
of systems by observation. In Proc. of the 2nd International Workshop of Non-functional
196
System Properties in Domain Specific Modeling Languages (NFPinDSML’09), Denver,
Colorado (US), Oct. 2009.
• J. E. Rivera, J. R. Romero, A. Vallecillo. Behavior, Time and Viewpoint Consistency:
Three Challenges for MDE. In Proc. of the ChaMDE Workshop at MODELS 2008,
pages 60-65, volume 5421 of LNCS, Tolouse, France, Sep. 2009. Springer-Verlag.
Iberoamerican conferences
• J. E. Rivera, C. Vicente-Chicote, and A. Vallecillo. Extending visual modeling languages
with timed behavioral specifications. In Proc. of the XII Workshop Iberoamericano de
Ingeniera de Requisitos y Ambientes de Software (IDEAS’09), pages 87–100, Medellı́n,
Colombia, Apr. 2009.
• J. E. Rivera and N. Moreno. Subtipado de modelos: Una definición basada en la sustitución entre tipos y en la aplicabilidad de operaciones. In Proc. of the XI Workshop
Iberoamericano de Ingeniera de Requisitos y Ambientes de Software (IDEAS’08), pages
375–380, Recife, Brasil, Feb. 2008.
Spanish conferences
• R. E. Lopez-Herrejon and J. E. Rivera. Realizing feature oriented software development
with equational logic: An exploratory study. In Proc. of the XIV Jornadas de Ingenierı́a
del Software y Bases de Datos (JISBD09), pages 269–274, Sept. 2009.
• J. E. Rivera and A. Vallecillo. Un acercamiento a la representación e implementación
de la diferencia entre modelos. In Proc. of the IV Taller sobre Desarrollo de Software
Dirigido por Modelos (DSDM’07), pages 1–10, Sept. 2007.
• J. E. Rivera, F. Durán, A. Vallecillo, and J. R. Romero. Maudeling: Herramienta de
gestión de modelos usando Maude.
In Proc. of the XII Jornadas de Ingenierı́a del
Software y Bases de Datos (JISBD’07), pages 409–410, Sept. 2007.
Technical reports
• J. E. Rivera, F. Durán, and A. Vallecillo. A metamodel for Maude. Technical report, University of Málaga, 2008. Available at http://atenea.lcc.uma.es/images/
e/e0/MaudeMM.pdf.
8.4. P ROJECTS
197
8.4 Projects
This thesis has been developed in the context of the following projects:
• MDD-MERTS: Diseño y monitorización dirigido por modelos de sistemas empotrados
y de tiempo real. Funded by MICINN (TIN2008-03107).
• MOVIS: Modernización y visualización de sistemas de información complejos. Funded
by Junta de Andalucı́a (P07-TIC-03184).
198
Appendix A
Maude Definitions for Models and
Metamodels
mod MGmOdCL i s
pr mOdCL ∗ ( --- Renamings of CONFIGURATION module elements
s o r t Cid
t o @Class ,
s o r t Object
t o @Object ,
s o r t Attribute
t o @StructuralFeatureInstance ,
s o r t AttributeSet
t o Set{@StructuralFeatureInstance } ,
op none : −> AttributeSet t o empty ,
--- Renamings of mOdCL elements
s o r t AttributeName t o @StructuralFeature ,
s o r t Enum t o @EnumerationInstance ,
s o r t BasicType t o @DataTypeInstance ,
--- Renamings of _,_ due to conflict with prefix notation
op _ ‘ , _ t o _#_ ,
op _ : _ t o _ : _ [ prec 20 gather ( e &) ] ) .
--- Relationship established by Ecore
s u b s o r t @EnumerationInstance < @DataTypeInstance .
--- OrderedSet operations that are not defined in OCL
eq asSequence ( OrderedSet{L : List{OCL−Exp } } ) = Sequence{L : List{OCL−Exp}} .
eq exclude ( I : OCL−Type , OrderedSet{L : List{OCL−Exp } } )
= OrderedSet{delete−all$L ( I : OCL−Type , L : List{OCL−Exp } ) } .
endm
mod METAMODEL−CTORS i s
pr MGmOdCL .
*** METAMODEL ELEMENTS ***
--- We create a sort for every (Ecore) metamodel element
--- We use CONFIGURATION (and mOdCL) elements renamed where possible
--- Sorts not included in mOdCL
199
200
A PPENDIX A. M AUDE D EFINITIONS FOR M ODELS AND M ETAMODELS
s o r t @NamedElement .
s o r t @Metamodel .
s o r t @Package .
s o r t @Classifier .
s o r t @Attribute .
s o r t @Reference .
s o r t @DataType .
s o r t @Enumeration .
--- Subsort relationships
s u b s o r t s @Metamodel @Package @Classifier @StructuralFeature < @NamedElement .
s u b s o r t s @Class @DataType < @Classifier .
s u b s o r t s @Attribute @Reference < @StructuralFeature .
s u b s o r t @Enumeration < @DataType .
--- Basic data types
op @String : −> @DataType .
op @Int : −> @DataType .
op @Bool : −> @DataType .
op @Float : −> @DataType .
op @DataType : −> @DataType .
*** MODEL ELEMENTS ***
s o r t @Model .
op _ ‘ { _ ‘ } : @Metamodel Set{@Object} −> @Model [ ctor ] .
s o r t Set{@Object} .
s u b s o r t @Object < Set{@Object} < Configuration .
op __ : Set{@Object} Set{@Object} −> Set{@Object} [ ctor ditto ] .
op none : −> Set{@Object} [ ctor ditto ] .
s u b s o r t @AttributeInstance @ReferenceInstance < @StructuralFeatureInstance .
s o r t @AttributeInstance .
op _ : _ : @Attribute OCL−Type −> @AttributeInstance [ ctor ditto ] .
s o r t @ReferenceInstance .
--- OCL-Type includes collections defined over BasicTypes and Oids
op _ : _ : @Reference OCL−Type −> @ReferenceInstance [ ctor ditto ] .
s o r t Set{@AttributeInstance} .
s u b s o r t @AttributeInstance < Set{@AttributeInstance} < Set{@StructuralFeatureInstance} .
op _#_ : Set{@AttributeInstance} Set{@AttributeInstance}
−> Set{@AttributeInstance} [ ctor ditto ] .
s o r t Set{@ReferenceInstance} .
s u b s o r t @ReferenceInstance < Set{@ReferenceInstance} < Set{@StructuralFeatureInstance} .
op _#_ : Set{@ReferenceInstance} Set{@ReferenceInstance}
−> Set{@ReferenceInstance} [ ctor ditto ] .
201
s o r t EmptySet .
s u b s o r t s EmptySet < Set{@ReferenceInstance} Set{@AttributeInstance} .
op _#_ : EmptySet EmptySet −> EmptySet [ ctor ditto ] .
op empty : −> EmptySet [ ctor ditto ] .
--- Operator @Object (equivalent to (Ecore) EObject)
op @Object : −> @Class .
endm
mod MYQID i s
pr MGmOdCL .
pr QID ∗ ( --- Same renamings as in mOdCL
op _ | _
: Nat Nat −> Nat
t o _ | N_ ,
op _xor_ : Nat Nat −> Nat t o _nxor_ ,
op _<_
: Nat Nat −> Bool t o _<N_ ,
op _<=_
: Nat Nat −> Bool t o _<=N_ ,
op _>_
: Nat Nat −> Bool t o _>N_ ,
op _>=_
: Nat Nat −> Bool t o _>=N_ ,
op _∗_
: Nat Nat −> Nat t o _∗N_ ,
op _+_
op _<_
: Nat Nat −> Nat t o _+N_ ,
: String String −> Bool t o _lt_ ,
op _<=_ : String String −> Bool t o _leq_ ,
op _>_
: String String −> Bool t o _gt_ ,
op _>=_ : String String −> Bool t o _geq_ ,
op _+_
: String String −> String t o _++_ ,
--- Renamings of Qid
op string : Qid −> String t o toString ) .
--- We use quoted identifiers as object identifiers
s u b s o r t Qid < Oid .
endm
mod MGMAYBE{X : : TRIV} i s
pr MGmOdCL .
s o r t Maybe{X} .
s u b s o r t X$Elt OclVoid < Maybe{X} .
endm
--- List defined for gathering the properties of metamodel elements
fmod MGLIST{X : : TRIV} i s
s o r t MGNeList{X} MGList{X} .
s u b s o r t X$Elt < MGNeList{X} .
s u b s o r t EmptyList MGNeList{X} < MGList{X} .
s o r t EmptyList .
op nil : −> EmptyList [ ctor ] .
op __ : EmptyList EmptyList −> EmptyList [ ctor assoc id : nil prec 2 5 ] .
op __ : MGList{X} MGList{X} −> MGList{X} [ ctor ditto ] .
var E E ’ : X$Elt .
202
v a r s A L : MGList{X} .
op append : EmptyList EmptyList −> EmptyList .
op append : MGList{X} MGList{X} −> MGList{X} .
eq append ( A , L ) = A L .
op occurs : X$Elt MGList{X} −> Bool .
eq occurs ( E , nil ) = false .
eq occurs ( E , E ’ L ) = i f E == E ’ then true else occurs ( E , L ) fi .
op _in_ : X$Elt MGList{X} −> Bool .
eq ( E in L ) =
occurs ( E , L ) .
op reverse : EmptyList −> EmptyList .
op reverse : MGList{X} −> MGList{X} .
eq reverse ( L ) = $reverse ( L , nil ) .
op $reverse : EmptyList EmptyList −> EmptyList .
op $reverse : MGList{X} MGList{X} −> MGList{X} .
eq $reverse ( nil , A ) = A .
eq $reverse ( E L , A ) = $reverse ( L , E A ) .
endfm
view @NamedElement from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @NamedElement .
endv
view @Reference from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @Reference .
endv
view @Attribute from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @Attribute .
endv
view @Metamodel from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @Metamodel .
endv
view @Package from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @Package .
endv
view @DataType from TRIV t o METAMODEL−CTORS i s
s o r t Elt t o @DataType .
endv
mod METAMODEL−PROP i s
pr METAMODEL−CTORS .
pr MYQID .
pr MGLIST{@NamedElement} ∗ ( s o r t MGList{@NamedElement} t o MyList ) .
203
pr MGMAYBE{@Package} + MGMAYBE{@Metamodel} + MGMAYBE{@DataType} + MGMAYBE{@Reference}
+ MGMAYBE{@Attribute} .
var MM : @Metamodel .
var P : @Package .
var CLF : @Classifier .
var C C2 : @Class .
var OBJ : @Object .
var O : Oid .
var SF SF2 : @StructuralFeature .
var ATT : @Attribute .
var SFI : @StructuralFeatureInstance .
var SFIS : Set{@StructuralFeatureInstance} .
var ATTIS : Set{@AttributeInstance} .
var REFIS : Set{@ReferenceInstance} .
v a r s DT DT2 : @DataType .
v a r s DTI DTI1 DTI2 : @DataTypeInstance .
v a r s I1 I2 : Int .
var L : MyList .
var LO : List{OCL−Exp} .
var OCLTYPE : OCL−Type .
var CONF : Configuration .
var VALUE : OCL−Type .
*** METAMODEL PROPERTIES ***
--- NamedElement
op name : @NamedElement −> String .
--- Metamodel
op packages : @Metamodel −> MyList . --- Of @Package
--- Packages
op metamodel : @Package −> @Metamodel .
op superPackage : @Package −> Maybe{@Package} .
op subPackages : @Package −> MyList . --- Of @Package
op classes : @Package −> MyList . --- Of @Class
--- Classifiers
op package : @Classifier −> Maybe{@Package} .
--- For data types that are not enumerations
eq package ( DT ) = null [ owise ] .
--- Classes
op superTypes : @Class −> MyList . --- Of @Class
op references : @Class −> MyList . --- Of @Reference
op attributes : @Class −> MyList . --- Of @Attribute
op isAbstract : @Class −> Bool .
204
--- StructuralFeatures
op type : @StructuralFeature −> @Classifier .
op type : @Attribute −> @DataType [ ditto ] .
op type : @Reference −> @Class [ ditto ] .
op lowerBound : @StructuralFeature −> Int .
op upperBound : @StructuralFeature −> Int .
op containingClass : @StructuralFeature −> @Class .
op isOrdered : @StructuralFeature −> Bool .
op isUnique : @StructuralFeature −> Bool .
--- Attributes
op specificDefaultValue : @Attribute −> OCL−Type . --- Of @DataTypeInstance
eq specificDefaultValue ( ATT ) = null [ owise ] .
op isId : @Attribute −> Bool .
--- References
op opposite : @Reference −> Maybe{@Reference} .
op isContainment : @Reference −> Bool .
--- Enumerations
op defaultValue : @Enumeration −> @EnumerationInstance . --- [ditto] .
op literals : @Enumeration −> List{OCL−Exp} . --- Of @EnumerationInstance .
--- List{OCL-Exp} is taken from mOdCL
--- Enumeration Instances
op meta : @EnumerationInstance −> @Enumeration .
*** METAMODEL DERIVED PROPERTIES AND OPERATIONS ***
--- Metamodels
op allClasses : @Metamodel −> MyList . --- Of @Class
eq allClasses ( MM ) = classesAux ( allPackages ( MM ) ) .
op allPackages : @Metamodel −> MyList . --- Of @Package
eq allPackages ( MM ) = ( packages ( MM ) allSubPackages ( packages ( MM ) ) ) .
--- Packages
op allSubPackages : MyList −> MyList . --- Of @Package (both) .
eq allSubPackages ( nil ) = nil .
eq allSubPackages ( P ) = ( subPackages ( P ) allSubPackages ( subPackages ( P ) ) ) .
eq allSubPackages ( ( P L ) ) = ( allSubPackages ( P ) allSubPackages ( L ) ) .
op allClasses : @Package −> MyList . --- Of @Class
eq allClasses ( P ) = ( classes ( P ) classesAux ( allSubPackages ( P ) ) ) .
op classesAux : MyList −> MyList . --- Of @Package, @Class
eq classesAux ( nil ) = nil .
eq classesAux ( P L ) = ( classes ( P ) classesAux ( L ) ) .
--- DataTypes
--- This operation is also defined for enumerations in the metamodels equations
205
op defaultValue : @DataType −> @DataTypeInstance .
eq defaultValue ( @String ) = "" .
eq defaultValue ( @Int ) = 0 .
eq defaultValue ( @Bool ) = false .
eq defaultValue ( @Float ) = 0 . 0 .
eq defaultValue ( DT ) = null [ owise ] .
--- DataTypes and DataTypesInstances
--- This operation is also defined for enumerations in the metamodels equations
op metaAux : @DataTypeInstance −> @DataType .
eq metaAux ( S : String ) = @String .
eq metaAux ( I : Int ) = @Int .
eq metaAux ( B : Bool ) = @Bool .
eq metaAux ( S : Float ) = @Float .
eq metaAux ( DTI ) = @DataType [ owise ] .
op subTypeOf : @DataType @DataType −> Bool .
eq subTypeOf ( DT , @DataType ) = true .
eq subTypeOf ( DT , DT ) = true .
eq subTypeOf ( DT , DT2 ) = false [ owise ] .
--- Classifiers
op metamodel : @Classifier −> Maybe{@Metamodel} .
eq metamodel ( CLF ) = i f ( package ( CLF ) == null ) then null else metamodel ( package ( CLF ) ) fi .
eq metamodel ( CLF ) = metamodel ( package ( CLF ) ) .
--- Classes
op structuralFeatures : @Class −> MyList . --- Of @StructuralFeature
eq structuralFeatures ( C ) = attributes ( C ) references ( C ) .
op allSuperTypes : MyList −> MyList . --- Of @Class (both)
eq allSuperTypes ( nil ) = nil .
eq allSuperTypes ( C ) = ( superTypes ( C ) allSuperTypes ( superTypes ( C ) ) ) .
eq allSuperTypes ( C L ) = ( allSuperTypes ( C ) allSuperTypes ( L ) ) .
op allReferences : MyList −> MyList . --- Of @Class, @Reference
eq allReferences ( nil ) = nil .
eq allReferences ( C ) = ( references ( C ) allReferences ( superTypes ( C ) ) ) .
eq allReferences ( C L ) = ( allReferences ( C ) allReferences ( L ) ) .
op containmentReferences : @Class −> MyList . --- Of @References
eq containmentReferences ( C ) = containmentReferences ( allReferences ( C ) ) .
op containmentReferences : MyList −> MyList . --- Of @References (both)
eq containmentReferences ( nil ) = nil .
eq containmentReferences ( REF L )
= i f ( isContainment ( REF ) )
then ( REF containmentReferences ( L ) )
else containmentReferences ( L ) fi .
op allAttributes : MyList −> MyList . --- Of @Class, @Attribute
eq allAttributes ( nil ) = nil .
206
eq allAttributes ( C ) = ( attributes ( C ) allAttributes ( superTypes ( C ) ) ) .
eq allAttributes ( C L ) = ( allAttributes ( C ) allAttributes ( L ) ) .
op allStructuralFeatures : @Class −> MyList . --- Of @StructuralFeature
eq allStructuralFeatures ( C ) = ( allAttributes ( C ) allReferences ( C ) ) .
op superTypeOf : @Class @Class −> Bool .
eq superTypeOf ( @Object , C2 ) = true .
eq superTypeOf ( C , C2 ) =
( name ( C ) == "EObject" and−then name ( package ( C ) ) == "ecore" )
or−else C in allSuperTypes ( C2 ) [ owise ] .
--- This equation is equivalent to:
--- eq subTypeOf(C, EObject@ecore) = true .
--- However, the Ecore Metamodel is not imported yet
op subTypeOf : @Class @Class −> Bool .
eq subTypeOf ( C , C2 ) = superTypeOf ( C2 , C ) .
op idAttribute : @Class −> Maybe{@Attribute} .
eq idAttribute ( C ) = idAttribute ( allAttributes ( C ) ) .
op idAttribute : MyList −> Maybe{@Attribute} . --- Of @Attribute
eq idAttribute ( nil ) = null .
eq idAttribute ( ATT L ) = i f isId ( ATT ) then ATT else idAttribute ( L ) fi .
--- StructuralFeatures
op isMany : @StructuralFeature −> Bool .
eq isMany ( SF ) = ( 2 <=Card upperBound ( SF ) ) .
op isRequired : @StructuralFeature −> Bool .
eq isRequired ( SF ) = ( 1 <=Card lowerBound ( SF ) ) .
op metamodel : @StructuralFeature −> @Metamodel .
eq metamodel ( SF ) = metamodel ( package ( containingClass ( SF ) ) ) .
op defaultValue : @StructuralFeature −> OCL−Type .
--- Attributes
op defaultValue : @Attribute −> OCL−Type [ ditto ] . --- Of @DataTypeInstance
eq defaultValue ( ATT )
= i f not ( specificDefaultValue ( ATT ) == null )
then specificDefaultValue ( ATT )
else i f ( isMany ( ATT ) and−then isRequired ( ATT ) )
then i f isOrdered ( ATT )
then i f isUnique ( ATT )
then OrderedSet{ defaultValue ( type ( ATT ) ) }
else Sequence{ defaultValue ( type ( ATT ) ) } fi
else i f isUnique ( ATT )
then Set{ defaultValue ( type ( ATT ) ) }
else Bag{ defaultValue ( type ( ATT ) ) } fi fi
else i f isMany ( ATT )
207
then i f isOrdered ( ATT )
then i f isUnique ( ATT )
then OrderedSet{ mt−ord }
else Sequence{ mt−ord } fi
else i f isUnique ( ATT )
then Set{ mt }
else Bag{ mt } fi fi
else i f ( isRequired ( ATT ) )
then defaultValue ( type ( ATT ) )
else null fi fi fi fi .
--- References
op defaultValue : @Reference −> OCL−Type [ ditto ] . --- Of Oid
eq defaultValue ( REF )
= i f isMany ( REF )
then i f isOrdered ( REF )
then i f isUnique ( REF )
then OrderedSet{}
else Sequence{} fi
else i f isUnique ( REF )
then Set{}
else Bag{} fi fi
else null fi .
op isContainer : @Reference −> Bool .
eq isContainer ( REF ) = isContainment ( opposite ( REF ) ) .
--- DataType Instances
op meta : OCL−Type −> Maybe{@DataType} . --- Of @DataTypeInstance
eq meta ( VALUE ) = metaListAux(<< VALUE −> asSequence ( ) >>) .
op metaListAux : Sequence −> Maybe{@DataType} . --- Of @DataTypeInstance
eq metaListAux ( Sequence{mt−ord } ) = null .
eq metaListAux ( Sequence{DTI1 } ) = metaAux ( DTI1 ) .
eq metaListAux ( Sequence{DTI1 # DTI2 # LO } )
= i f ( metaAux ( DTI1 ) == metaListAux ( Sequence{DTI2 # LO } ) )
then metaAux ( DTI1 )
else null fi .
--- StructuralFeature Instances
op meta : @StructuralFeatureInstance −> @StructuralFeature .
eq meta ( SF : VALUE ) = SF .
op isOrdered : @StructuralFeatureInstance −> Bool .
eq isOrdered ( SFI ) = isOrdered ( meta ( SFI ) ) .
op isUnique : @StructuralFeatureInstance −> Bool .
eq isUnique ( SFI ) = isUnique ( meta ( SFI ) ) .
op isOrdered : OCL−Type −> Bool .
eq isOrdered ( B : Bag ) = false .
208
eq isOrdered ( S : Set ) = false .
eq isOrdered ( VALUE ) = true [ owise ] .
op isUnique : OCL−Type −> Bool .
eq isUnique ( S : Sequence ) = false .
eq isUnique ( B : Bag ) = false .
eq isUnique ( VALUE ) = true [ owise ] .
op isMany : OCL−Type −> Bool .
eq isMany ( COL : Collection ) = true .
eq isMany ( VALUE ) = false [ owise ] .
op atts : Set{@StructuralFeatureInstance} −> Set{@AttributeInstance} .
eq atts ( ( ATTIS # REFIS ) ) = ATTIS .
op refs : Set{@StructuralFeatureInstance} −> Set{@ReferenceInstance} .
eq refs ( ( ATTIS # REFIS ) ) = REFIS .
op get : Set{@StructuralFeatureInstance} @StructuralFeature −> OCL−Type .
eq get ( ( SF : VALUE # SFIS ) , SF ) = VALUE .
eq get ( SFIS , SF ) = null [ owise ] .
--- Objects
op meta : @Object −> @Class .
eq meta(< O : C | SFIS >) = C .
op get : @Object @StructuralFeature −> OCL−Type .
eq get(< O : C | ( SF : VALUE # SFIS ) >, SF ) = VALUE .
eq get ( OBJ , SF ) = null [ owise ] .
--- The complete operation adds to a object all the structural features-value pairs (with
--- their default value) that are missing
op complete : @Object −> @Object .
eq complete(< O : C | SFIS >) = complete(< O : C | SFIS >, allStructuralFeatures ( C ) ) .
op complete : @Object MyList −> @Object .
eq complete(< O : C | SF : VALUE # SFIS >, ( SF L ) )
= complete(< O : C | SF : VALUE # SFIS >, L ) .
eq complete(< O : C | SFIS >, ( SF L ) )
= complete(< O : C | SF : defaultValue ( SF ) # SFIS >, L ) [ owise ] .
eq complete(< O : C | SFIS >, nil ) = < O : C | SFIS > .
--- Model
op meta : @Model −> @Metamodel .
eq meta ( MM { OBJSET } ) = MM .
op objectsSet : @Model −> Set{@Object} .
eq objectsSet ( MM { OBJSET } ) = OBJSET .
--- Cardinality
op ∗ : −> Int .
eq ∗ = −1 .
209
op maxCard : Int Int −> Int [ comm ] .
eq maxCard( −1 , I1 ) = −1 .
eq maxCard ( I1 , I2 ) = max ( I1 , I2 ) [ owise ] .
op minCard : Int Int −> Int [ comm ] .
eq minCard( −1 , I1 ) = I1 .
eq minCard ( I1 , I2 ) = min ( I1 , I2 ) [ owise ] .
op _<=Card_ : Int Int −> Bool .
eq I1 <=Card −1 = true .
eq −1 <=Card I2 = ( I2 == −1) .
eq I1 <=Card I2 = I1 <= I2 [ owise ] .
*** mOdCL OPERATION ADAPTATIONS ***
--- Eval now can be applied over @Model terms
op eval : OCL−Exp Msg @Model −> OCL−Exp .
eq eval ( EXP : OCL−Exp , env ( VARS : Set{VarPair } ) , MM { OBJSET } ) =
i f ( VARS : Set{VarPair} == empty )
then eval−aux ( EXP : OCL−Exp , env ( self <− foo−self ) OBJSET , none )
else eval−aux ( EXP : OCL−Exp , env ( VARS : Set{VarPair } ) OBJSET , non ) fi .
op <<_ ; _>> : OCL−Exp @Model −> OCL−Exp .
--- We cannot use the same <<_:_>> mOdCL operator due to conflicts
--- (it returns the invalid value)
eq << EXP : OCL−Exp ; MM { OBJSET } >> = ---<< EXP:OCL-Exp : OBJSET >> .
eval−aux ( EXP : OCL−Exp , env ( empty ) OBJSET , none ) .
--- The second argument are the context avriables
op <<_ ; _ ; _>> : OCL−Exp Msg @Model −> OCL−Exp .
eq << EXP : OCL−Exp ; env ( VARS : Set{VarPair } ) ; MM { OBJSET } >> =
eval−aux ( EXP : OCL−Exp , env ( VARS : Set{VarPair } ) OBJSET , none ) .
--- Operation required by mOdCL
--- Note that for this OCL operation a class is subclass of itself
--- op isSubClass : Cid Cid -> Bool .
eq isSubClass ( C , C2 ) = ( C == C2 ) or−else subTypeOf ( C , C2 ) .
--- To handle not (name-)qualified attributes in OCL expressions
--- op getAttr : Universal Configuration -> Universal [poly (1 0)] .
ceq get−attr ( O ( . SF ) . OCL−Attr , < O : C | SF2 : OCLTYPE # SFIS > CONF )
= OCLTYPE
i f ( name ( SF ) == name ( SF2 ) ) .
endm
210
Appendix B
Maude Encoding of the Ecore Metamodel
mod MAUDELING i s
pr MODELCONFORMANCE .
...
endm
mod @ECORE@ i s
pr MAUDELING .
op @Ecore@ : −> @Metamodel .
eq name ( @Ecore@ ) = "Ecore" .
eq packages ( @Ecore@ ) = ecore .
op ecore : −> @Package .
eq name ( ecore ) = "ecore" .
eq metamodel ( ecore ) = @Ecore@ .
eq superPackage ( ecore ) = null .
eq subPackages ( ecore ) = nil .
eq classes ( ecore ) = EAttribute@ecore EAnnotation@ecore EClass@ecore EClassifier@ecore
EDataType@ecore EEnum@ecore EEnumLiteral@ecore EFactory@ecore EModelElement@ecore
ENamedElement@ecore EObject@ecore EOperation@ecore EPackage@ecore EParameter@ecore
EReference@ecore EStructuralFeature@ecore ETypedElement@ecore
EStringToStringMapEntry@ecore EGenericType@ecore ETypeParameter@ecore .
s o r t EAttribute@ecore .
s u b s o r t s EAttribute@ecore < EStructuralFeature@ecore .
op EAttribute@ecore : −> EAttribute@ecore .
eq name ( EAttribute@ecore ) = "EAttribute" .
eq isAbstract ( EAttribute@ecore ) = false .
eq package ( EAttribute@ecore ) = ecore .
eq superTypes ( EAttribute@ecore ) = EStructuralFeature@ecore .
eq references ( EAttribute@ecore ) = eAttributeType@EAttribute@ecore .
eq attributes ( EAttribute@ecore ) = iD@EAttribute@ecore .
s o r t EAnnotation@ecore .
211
212
A PPENDIX B. M AUDE E NCODING OF THE E CORE M ETAMODEL
s u b s o r t s EAnnotation@ecore < EModelElement@ecore .
op EAnnotation@ecore : −> EAnnotation@ecore .
eq name ( EAnnotation@ecore ) = "EAnnotation" .
eq isAbstract ( EAnnotation@ecore ) = false .
eq package ( EAnnotation@ecore ) = ecore .
eq superTypes ( EAnnotation@ecore ) = EModelElement@ecore .
eq references ( EAnnotation@ecore ) = details@EAnnotation@ecore eModelElement@EAnnotation@ecore
contents@EAnnotation@ecore references@EAnnotation@ecore .
eq attributes ( EAnnotation@ecore ) = source@EAnnotation@ecore .
s o r t EClass@ecore .
s u b s o r t s EClass@ecore < EClassifier@ecore .
op EClass@ecore : −> EClass@ecore .
eq name ( EClass@ecore ) =
"EClass" .
eq isAbstract ( EClass@ecore ) =
false .
eq package ( EClass@ecore ) = ecore .
eq superTypes ( EClass@ecore ) = EClassifier@ecore .
eq references ( EClass@ecore ) = eSuperTypes@EClass@ecore eOperations@EClass@ecore
eAllAttributes@EClass@ecore eAllReferences@EClass@ecore eReferences@EClass@ecore
eAttributes@EClass@ecore eAllContainments@EClass@ecore eAllOperations@EClass@ecore
eAllStructuralFeatures@EClass@ecore eAllSuperTypes@EClass@ecore
eIDAttribute@EClass@ecore eStructuralFeatures@EClass@ecore
eGenericSuperTypes@EClass@ecore eAllGenericSuperTypes@EClass@ecore .
eq attributes ( EClass@ecore ) = abstract@EClass@ecore interface@EClass@ecore .
s o r t EClassifier@ecore .
s u b s o r t s EClassifier@ecore < ENamedElement@ecore .
op EClassifier@ecore : −> EClassifier@ecore .
eq name ( EClassifier@ecore ) = "EClassifier" .
eq isAbstract ( EClassifier@ecore ) = true .
eq package ( EClassifier@ecore ) = ecore .
eq superTypes ( EClassifier@ecore ) = ENamedElement@ecore .
eq references ( EClassifier@ecore ) = ePackage@EClassifier@ecore
eTypeParameters@EClassifier@ecore .
eq attributes ( EClassifier@ecore ) = instanceClassName@EClassifier@ecore
instanceClass@EClassifier@ecore defaultValue@EClassifier@ecore
instanceTypeName@EClassifier@ecore .
s o r t EDataType@ecore .
s u b s o r t s EDataType@ecore < EClassifier@ecore .
op EDataType@ecore : −> EDataType@ecore .
eq name ( EDataType@ecore ) = "EDataType" .
eq isAbstract ( EDataType@ecore ) = false .
eq package ( EDataType@ecore ) = ecore .
eq superTypes ( EDataType@ecore ) = EClassifier@ecore .
eq references ( EDataType@ecore ) = nil .
eq attributes ( EDataType@ecore ) = serializable@EDataType@ecore .
s o r t EEnum@ecore .
s u b s o r t s EEnum@ecore < EDataType@ecore .
op EEnum@ecore : −> EEnum@ecore .
213
eq name ( EEnum@ecore ) = "EEnum" .
eq isAbstract ( EEnum@ecore ) = false .
eq package ( EEnum@ecore ) = ecore .
eq superTypes ( EEnum@ecore ) = EDataType@ecore .
eq references ( EEnum@ecore ) = eLiterals@EEnum@ecore .
eq attributes ( EEnum@ecore ) = nil .
s o r t EEnumLiteral@ecore .
s u b s o r t s EEnumLiteral@ecore < ENamedElement@ecore .
op EEnumLiteral@ecore : −> EEnumLiteral@ecore .
eq name ( EEnumLiteral@ecore ) = "EEnumLiteral" .
eq isAbstract ( EEnumLiteral@ecore ) = false .
eq package ( EEnumLiteral@ecore ) = ecore .
eq superTypes ( EEnumLiteral@ecore ) = ENamedElement@ecore .
eq references ( EEnumLiteral@ecore ) = eEnum@EEnumLiteral@ecore .
eq attributes ( EEnumLiteral@ecore ) = value@EEnumLiteral@ecore instance@EEnumLiteral@ecore
literal@EEnumLiteral@ecore .
...
s o r t EObject@ecore .
s u b s o r t s EObject@ecore < @Class .
op EObject@ecore : −> EObject@ecore .
eq name ( EObject@ecore ) = "EObject" .
eq isAbstract ( EObject@ecore ) = false .
eq package ( EObject@ecore ) = ecore .
eq superTypes ( EObject@ecore ) = nil .
eq references ( EObject@ecore ) = nil .
eq attributes ( EObject@ecore ) = nil .
...
op eAttributeType@EAttribute@ecore : −> @Reference .
eq name ( eAttributeType@EAttribute@ecore ) = "eAttributeType" .
eq type ( eAttributeType@EAttribute@ecore ) = EDataType@ecore .
eq opposite ( eAttributeType@EAttribute@ecore ) = null .
eq lowerBound ( eAttributeType@EAttribute@ecore ) = 1 .
eq upperBound ( eAttributeType@EAttribute@ecore ) = 1 .
eq containingClass ( eAttributeType@EAttribute@ecore ) = EAttribute@ecore .
eq isContainment ( eAttributeType@EAttribute@ecore ) = false .
eq isOrdered ( eAttributeType@EAttribute@ecore ) = true .
eq isUnique ( eAttributeType@EAttribute@ecore ) = true .
op details@EAnnotation@ecore : −> @Reference .
eq name ( details@EAnnotation@ecore ) = "details" .
eq type ( details@EAnnotation@ecore ) = EStringToStringMapEntry@ecore .
eq opposite ( details@EAnnotation@ecore ) = null .
eq lowerBound ( details@EAnnotation@ecore ) = 0 .
eq upperBound ( details@EAnnotation@ecore ) = ∗ .
eq containingClass ( details@EAnnotation@ecore ) = EAnnotation@ecore .
eq isContainment ( details@EAnnotation@ecore ) = true .
eq isOrdered ( details@EAnnotation@ecore ) = true .
eq isUnique ( details@EAnnotation@ecore ) = true .
214
op eModelElement@EAnnotation@ecore : −> @Reference .
eq name ( eModelElement@EAnnotation@ecore ) = "eModelElement" .
eq type ( eModelElement@EAnnotation@ecore ) = EModelElement@ecore .
eq opposite ( eModelElement@EAnnotation@ecore ) = eAnnotations@EModelElement@ecore .
eq lowerBound ( eModelElement@EAnnotation@ecore ) = 0 .
eq upperBound ( eModelElement@EAnnotation@ecore ) = 1 .
eq containingClass ( eModelElement@EAnnotation@ecore ) = EAnnotation@ecore .
eq isContainment ( eModelElement@EAnnotation@ecore ) = false .
eq isOrdered ( eModelElement@EAnnotation@ecore ) = true .
eq isUnique ( eModelElement@EAnnotation@ecore ) = true .
op contents@EAnnotation@ecore : −> @Reference .
eq name ( contents@EAnnotation@ecore ) = "contents" .
eq type ( contents@EAnnotation@ecore ) = EObject@ecore .
eq opposite ( contents@EAnnotation@ecore ) = null .
eq lowerBound ( contents@EAnnotation@ecore ) = 0 .
eq upperBound ( contents@EAnnotation@ecore ) = ∗ .
eq containingClass ( contents@EAnnotation@ecore ) = EAnnotation@ecore .
eq isContainment ( contents@EAnnotation@ecore ) = true .
eq isOrdered ( contents@EAnnotation@ecore ) = true .
eq isUnique ( contents@EAnnotation@ecore ) = true .
op references@EAnnotation@ecore : −> @Reference
.
eq name ( references@EAnnotation@ecore ) = "references" .
eq type ( references@EAnnotation@ecore ) = EObject@ecore .
eq opposite ( references@EAnnotation@ecore ) = null .
eq lowerBound ( references@EAnnotation@ecore ) = 0 .
eq upperBound ( references@EAnnotation@ecore ) = ∗ .
eq containingClass ( references@EAnnotation@ecore ) = EAnnotation@ecore .
eq isContainment ( references@EAnnotation@ecore ) = false .
eq isOrdered ( references@EAnnotation@ecore ) = true .
eq isUnique ( references@EAnnotation@ecore ) = true .
op eSuperTypes@EClass@ecore : −> @Reference .
eq name ( eSuperTypes@EClass@ecore ) = "eSuperTypes" .
eq type ( eSuperTypes@EClass@ecore ) = EClass@ecore .
eq opposite ( eSuperTypes@EClass@ecore ) = null .
eq lowerBound ( eSuperTypes@EClass@ecore ) = 0 .
eq upperBound ( eSuperTypes@EClass@ecore ) = ∗ .
eq containingClass ( eSuperTypes@EClass@ecore ) = EClass@ecore .
eq isContainment ( eSuperTypes@EClass@ecore ) = false .
eq isOrdered ( eSuperTypes@EClass@ecore ) = true .
eq isUnique ( eSuperTypes@EClass@ecore ) = true .
...
op iD@EAttribute@ecore : −> @Attribute .
eq name ( iD@EAttribute@ecore ) = "iD" .
eq type ( iD@EAttribute@ecore ) = @Bool .
eq lowerBound ( iD@EAttribute@ecore ) = 0 .
eq upperBound ( iD@EAttribute@ecore ) = 1 .
215
eq containingClass ( iD@EAttribute@ecore ) = EAttribute@ecore .
eq isId ( iD@EAttribute@ecore ) =
false .
eq isOrdered ( iD@EAttribute@ecore ) = true .
eq isUnique ( iD@EAttribute@ecore ) = true .
op source@EAnnotation@ecore : −> @Attribute .
eq name ( source@EAnnotation@ecore ) = "source" .
eq type ( source@EAnnotation@ecore ) = @String .
eq lowerBound ( source@EAnnotation@ecore ) = 0 .
eq upperBound ( source@EAnnotation@ecore ) = 1 .
eq containingClass ( source@EAnnotation@ecore ) = EAnnotation@ecore .
eq isId ( source@EAnnotation@ecore ) = false .
eq isOrdered ( source@EAnnotation@ecore ) = true .
eq isUnique ( source@EAnnotation@ecore ) = true .
op abstract@EClass@ecore : −> @Attribute .
eq name ( abstract@EClass@ecore ) = "abstract" .
eq type ( abstract@EClass@ecore ) = @Bool .
eq lowerBound ( abstract@EClass@ecore ) = 0 .
eq upperBound ( abstract@EClass@ecore ) = 1 .
eq containingClass ( abstract@EClass@ecore ) = EClass@ecore .
eq isId ( abstract@EClass@ecore ) = false .
eq isOrdered ( abstract@EClass@ecore ) = true .
eq isUnique ( abstract@EClass@ecore ) = true .
op interface@EClass@ecore : −> @Attribute .
eq name ( interface@EClass@ecore ) = "interface" .
eq type ( interface@EClass@ecore ) = @Bool .
eq lowerBound ( interface@EClass@ecore ) = 0 .
eq upperBound ( interface@EClass@ecore ) = 1 .
eq containingClass ( interface@EClass@ecore ) = EClass@ecore .
eq isId ( interface@EClass@ecore ) = false .
eq isOrdered ( interface@EClass@ecore ) = true .
eq isUnique ( interface@EClass@ecore ) = true .
op instanceClassName@EClassifier@ecore : −> @Attribute .
eq name ( instanceClassName@EClassifier@ecore ) = "instanceClassName" .
eq type ( instanceClassName@EClassifier@ecore ) = @String .
eq lowerBound ( instanceClassName@EClassifier@ecore ) = 0 .
eq upperBound ( instanceClassName@EClassifier@ecore ) = 1 .
eq containingClass ( instanceClassName@EClassifier@ecore ) = EClassifier@ecore .
eq isId ( instanceClassName@EClassifier@ecore ) = false .
eq isOrdered ( instanceClassName@EClassifier@ecore ) = true .
eq isUnique ( instanceClassName@EClassifier@ecore ) = true .
...
endm
216
Appendix C
Maude Definitions for Time and Action
Properties
1
--- We import Real-Time Maude modules TIMED-PRELUDE, LTIME-INF, NAT-TIME-DOMAIN-WITH-INF
2
--- and POSRAT-TIME-DOMAIN-WITH-INF. They provide support for different time domains,
3
--- such as discrete and dense time domains.
4
5
6
fmod MGTIMED−PRELUDE i s
pr TIMED−PRELUDE ∗ ( --- Time renamings
7
--- (to be consistent with dense and discrete time renamings)
8
op _gt_ : Time Time −> Bool t o _gtT_ ,
op _lt_ : Time Time −> Bool t o _ltT_ ) .
9
10
endfm
11
12
13
fmod MGLTIME−INF i s
pr LTIME−INF ∗ ( --- Time renamings
--- (to be consistent with dense and discrete time renamings)
14
15
op _gt_ : TimeInf TimeInf −> Bool t o _gtT_ ,
16
op _lt_ : TimeInf TimeInf −> Bool t o _ltT_ ,
17
op min : TimeInf TimeInf −> TimeInf t o minT ,
op max : TimeInf TimeInf −> TimeInf t o maxT ) .
18
19
endfm
20
21
22
23
24
mod MGTIME i s
pr MGTIMED−PRELUDE .
pr MGLTIME−INF .
endm
25
26
27
fmod DISCRETE_TIME i s
pr NAT−TIME−DOMAIN−WITH−INF ∗ ( --- Same renamings as in mOdCL
28
op _xor_ : Nat Nat −> Nat
t o _nxor_ ,
29
op _ | _
: Nat Nat −> Nat
t o _ | N_ ,
30
op _<_
31
op _<=_
217
218
A PPENDIX C. M AUDE D EFINITIONS FOR T IME AND ACTION P ROPERTIES
32
op _>_
33
op _>=_
34
op _−_
: Nat Nat −> Nat
t o _−N_ ,
35
op _∗_
: Nat Nat −> Nat
t o _∗N_ ,
36
op _+_
: Nat Nat −> Nat
t o _+N_ ,
37
--- Time renamings
38
39
40
41
42
endfm
43
44
45
fmod DENSE_TIME i s
pr POSRAT−TIME−DOMAIN−WITH−INF ∗ ( --- Same renamings as in mOdCL
46
op _xor_ : Nat Nat −> Nat
t o _nxor_ ,
47
op _ | _
: Nat Nat −> Nat
t o _ | N_ ,
48
op _<_
49
op _<=_
50
op _>_
51
op _>=_
52
op _−_
: Nat Nat −> Nat
t o _−N_ ,
53
op _∗_
: Nat Nat −> Nat
t o _∗N_ ,
54
op _+_
: Nat Nat −> Nat
t o _+N_ ,
55
op −_ : Int −> Int t o −I_ ,
56
op _ / _
57
op floor : PosRat −> Nat t o floorR ,
: Rat Rat −> Rat
to _ / / _ ,
58
op ceiling : PosRat −> Nat t o ceilingR ,
59
--- Time renamings
60
61
62
63
64
endfm
65
66
mod MGBEHAVIORMM i s
67
pr @ECORE@ .
68
pr MGTIME .
69
70
--- We include Time as a data type
71
op @Time : −> @DataType .
72
--- subsorts OclVoid < Time < @DataTypeInstance .
73
s u b s o r t s TimeInf < @DataTypeInstance .
74
eq defaultValue ( @Time ) = zero .
75
eq metaAux ( T : Time ) = @Time .
76
77
*** BEHAVIOR METAMODEL ***
78
79
op @MGBehavior@ : −> @Metamodel .
80
eq name ( @MGBehavior@ ) = "MGBehavior" .
81
eq packages ( @MGBehavior@ ) = MGBehavior .
82
219
83
op MGBehavior : −> @Package .
84
eq name ( MGBehavior ) = "BehaviorMG" .
85
eq metamodel ( MGBehavior ) = @MGBehavior@ .
86
eq superPackage ( MGBehavior ) = null .
87
eq subPackages ( MGBehavior ) = nil .
88
eq classes ( MGBehavior ) = ActionExec@MGBehavior AtomicActionExec@MGBehavior
89
OngoingActionExec@MGBehavior Variable@MGBehavior Clock@MGBehavior Counter@MGBehavior
90
ObjectRole@MGBehavior .
91
92
--- Classes to represent rule properties
93
s o r t Rule@MGBehavior .
94
s u b s o r t Rule@MGBehavior < @Class .
95
op Rule@MGBehavior : −> Rule@MGBehavior .
96
eq name ( Rule@MGBehavior ) = "Rule" .
97
eq isAbstract ( Rule@MGBehavior ) = false .
98
eq package ( Rule@MGBehavior ) = MGBehavior .
99
eq superTypes ( Rule@MGBehavior ) = nil .
100
eq references ( Rule@MGBehavior ) = nil
101
eq attributes ( Rule@MGBehavior ) = name@Rule@MGBehavior lowerBound@Rule@MGBehavior
102
.
upperBound@Rule@MGBehavior soft@Rule@MGBehavior .
103
104
op name@Rule@MGBehavior : −> @Attribute .
105
eq name ( name@Rule@MGBehavior ) = "name" .
106
eq type ( name@Rule@MGBehavior ) = @String .
107
eq lowerBound ( name@Rule@MGBehavior ) = 1 .
108
eq upperBound ( name@Rule@MGBehavior ) = 1 .
109
eq containingClass ( name@Rule@MGBehavior ) = Rule@MGBehavior .
110
eq isId ( name@Rule@MGBehavior ) = true .
111
eq isOrdered ( name@Rule@MGBehavior ) = true .
112
eq isUnique ( name@Rule@MGBehavior ) = true .
113
114
op lowerBound@Rule@MGBehavior : −> @Attribute .
115
eq name ( lowerBound@Rule@MGBehavior ) = "lowerBound" .
116
eq type ( lowerBound@Rule@MGBehavior ) = @Time .
117
eq lowerBound ( lowerBound@Rule@MGBehavior ) = 0 .
118
eq upperBound ( lowerBound@Rule@MGBehavior ) = 1 .
119
eq containingClass ( lowerBound@Rule@MGBehavior ) = Rule@MGBehavior .
120
eq isId ( lowerBound@Rule@MGBehavior ) = false .
121
eq isOrdered ( lowerBound@Rule@MGBehavior ) = true .
122
eq isUnique ( lowerBound@Rule@MGBehavior ) = true .
123
124
op upperBound@Rule@MGBehavior : −> @Attribute .
125
eq name ( upperBound@Rule@MGBehavior ) = "upperBound" .
126
eq type ( upperBound@Rule@MGBehavior ) = @Time .
127
eq lowerBound ( upperBound@Rule@MGBehavior ) = 0 .
128
eq upperBound ( upperBound@Rule@MGBehavior ) = 1 .
129
eq containingClass ( upperBound@Rule@MGBehavior ) = Rule@MGBehavior .
130
eq isId ( upperBound@Rule@MGBehavior ) = false .
131
eq isOrdered ( upperBound@Rule@MGBehavior ) = true .
132
eq isUnique ( upperBound@Rule@MGBehavior ) = true .
133
220
134
op soft@Rule@MGBehavior : −> @Attribute .
135
eq name ( soft@Rule@MGBehavior ) = "soft" .
136
eq type ( soft@Rule@MGBehavior ) = @Bool .
137
eq lowerBound ( soft@Rule@MGBehavior ) = 1 .
138
eq upperBound ( soft@Rule@MGBehavior ) = 1 .
139
eq containingClass ( soft@Rule@MGBehavior ) = Rule@MGBehavior .
140
eq isId ( soft@Rule@MGBehavior ) = false .
141
eq isOrdered ( soft@Rule@MGBehavior ) = true .
142
eq isUnique ( soft@Rule@MGBehavior ) = true .
143
144
s o r t AtomicRule@MGBehavior .
145
s u b s o r t AtomicRule@MGBehavior < Rule@MGBehavior .
146
op AtomicRule@MGBehavior : −> AtomicRule@MGBehavior .
147
eq name ( AtomicRule@MGBehavior ) = "AtomicRule" .
148
eq isAbstract ( AtomicRule@MGBehavior ) = false .
149
eq package ( AtomicRule@MGBehavior ) = MGBehavior .
150
eq superTypes ( AtomicRule@MGBehavior ) = Rule@MGBehavior .
151
eq references ( AtomicRule@MGBehavior ) = nil
152
eq attributes ( AtomicRule@MGBehavior ) = periodicity@AtomicRule@MGBehavior .
.
153
154
op periodicity@AtomicRule@MGBehavior : −> @Attribute .
155
eq name ( periodicity@AtomicRule@MGBehavior ) = "periodicity" .
156
eq type ( periodicity@AtomicRule@MGBehavior ) = @Time .
157
eq lowerBound ( periodicity@AtomicRule@MGBehavior ) = 0 .
158
eq upperBound ( periodicity@AtomicRule@MGBehavior ) = 1 .
159
eq containingClass ( periodicity@AtomicRule@MGBehavior ) = AtomicRule@MGBehavior .
160
eq isId ( periodicity@AtomicRule@MGBehavior ) = false .
161
eq isOrdered ( periodicity@AtomicRule@MGBehavior ) = true .
162
eq isUnique ( periodicity@AtomicRule@MGBehavior ) = true .
163
164
--- Classes to represent action executions
165
s o r t ActionExec@MGBehavior .
166
s u b s o r t ActionExec@MGBehavior < @Class .
167
op ActionExec@MGBehavior : −> ActionExec@MGBehavior .
168
eq name ( ActionExec@MGBehavior ) = "ActionExec" .
169
eq isAbstract ( ActionExec@MGBehavior ) = true .
170
eq package ( ActionExec@MGBehavior ) = MGBehavior .
171
eq superTypes ( ActionExec@MGBehavior ) = nil .
172
eq references ( ActionExec@MGBehavior ) = participants@ActionExec@MGBehavior
173
174
.
variables@ActionExec@MGBehavior
eq attributes ( ActionExec@MGBehavior ) = startingTime@ActionExec@MGBehavior
175
endingTime@ActionExec@MGBehavior action@ActionExec@MGBehavior
176
maxTimer@ActionExec@MGBehavior
.
177
178
op participants@ActionExec@MGBehavior : −> @Reference
179
eq name ( participants@ActionExec@MGBehavior ) = "participants" .
180
eq type ( participants@ActionExec@MGBehavior ) = ObjectRole@MGBehavior .
181
eq opposite ( participants@ActionExec@MGBehavior ) = null .
182
eq lowerBound ( participants@ActionExec@MGBehavior ) = 0 .
183
eq upperBound ( participants@ActionExec@MGBehavior ) = ∗ .
184
eq containingClass ( participants@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
.
221
185
eq isContainment ( participants@ActionExec@MGBehavior ) = true .
186
eq isOrdered ( participants@ActionExec@MGBehavior ) = false .
187
eq isUnique ( participants@ActionExec@MGBehavior ) = true .
188
189
op variables@ActionExec@MGBehavior : −> @Reference
190
eq name ( variables@ActionExec@MGBehavior ) = "variables" .
191
eq type ( variables@ActionExec@MGBehavior ) = Variable@MGBehavior .
192
eq opposite ( variables@ActionExec@MGBehavior ) = null .
193
eq lowerBound ( variables@ActionExec@MGBehavior ) = 0 .
194
eq upperBound ( variables@ActionExec@MGBehavior ) = ∗ .
195
eq containingClass ( variables@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
196
eq isContainment ( variables@ActionExec@MGBehavior ) = true .
197
eq isOrdered ( variables@ActionExec@MGBehavior ) = false .
198
eq isUnique ( variables@ActionExec@MGBehavior ) = true .
.
199
200
op startingTime@ActionExec@MGBehavior : −> @Attribute .
201
eq name ( startingTime@ActionExec@MGBehavior ) = "startingTime" .
202
eq type ( startingTime@ActionExec@MGBehavior ) =
203
eq lowerBound ( startingTime@ActionExec@MGBehavior ) = 1 .
204
eq upperBound ( startingTime@ActionExec@MGBehavior ) = 1 .
205
eq containingClass ( startingTime@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
206
eq isId ( startingTime@ActionExec@MGBehavior ) = false .
207
eq isOrdered ( startingTime@ActionExec@MGBehavior ) = true .
208
eq isUnique ( startingTime@ActionExec@MGBehavior ) = true .
@Time .
209
210
op endingTime@ActionExec@MGBehavior : −> @Attribute .
211
eq name ( endingTime@ActionExec@MGBehavior ) = "endingTime" .
212
eq type ( endingTime@ActionExec@MGBehavior ) =
213
eq lowerBound ( endingTime@ActionExec@MGBehavior ) = 0 .
214
eq upperBound ( endingTime@ActionExec@MGBehavior ) = 1 .
215
eq containingClass ( endingTime@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
216
eq isId ( endingTime@ActionExec@MGBehavior ) = false .
217
eq isOrdered ( endingTime@ActionExec@MGBehavior ) = true .
218
eq isUnique ( endingTime@ActionExec@MGBehavior ) = true .
@Time .
219
220
op action@ActionExec@MGBehavior : −> @Attribute .
221
eq name ( action@ActionExec@MGBehavior ) = "action" .
222
eq type ( action@ActionExec@MGBehavior ) =
223
eq lowerBound ( action@ActionExec@MGBehavior ) = 1 .
224
eq upperBound ( action@ActionExec@MGBehavior ) = 1 .
225
eq containingClass ( action@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
226
eq isId ( action@ActionExec@MGBehavior ) = false .
227
eq isOrdered ( action@ActionExec@MGBehavior ) = true .
228
eq isUnique ( action@ActionExec@MGBehavior ) = true .
@String .
229
230
op maxTimer@ActionExec@MGBehavior : −> @Attribute .
231
eq name ( maxTimer@ActionExec@MGBehavior ) = "maxTimer" .
232
eq type ( maxTimer@ActionExec@MGBehavior ) =
233
eq lowerBound ( maxTimer@ActionExec@MGBehavior ) = 0 .
234
eq upperBound ( maxTimer@ActionExec@MGBehavior ) = 1 .
235
eq containingClass ( maxTimer@ActionExec@MGBehavior ) = ActionExec@MGBehavior .
@Time .
222
236
eq isId ( maxTimer@ActionExec@MGBehavior ) = false .
237
eq isOrdered ( maxTimer@ActionExec@MGBehavior ) = true .
238
eq isUnique ( maxTimer@ActionExec@MGBehavior ) = true .
239
240
s o r t AtomicActionExec@MGBehavior .
241
s u b s o r t AtomicActionExec@MGBehavior < ActionExec@MGBehavior .
242
op AtomicActionExec@MGBehavior : −> AtomicActionExec@MGBehavior .
243
eq name ( AtomicActionExec@MGBehavior ) = "AtomicActionExec" .
244
eq isAbstract ( AtomicActionExec@MGBehavior ) = false .
245
eq package ( AtomicActionExec@MGBehavior ) = MGBehavior .
246
eq superTypes ( AtomicActionExec@MGBehavior ) = ActionExec@MGBehavior .
247
eq references ( AtomicActionExec@MGBehavior ) = nil
248
eq attributes ( AtomicActionExec@MGBehavior ) = minTimer@AtomicActionExec@MGBehavior
249
executionTime@AtomicActionExec@MGBehavior status@AtomicActionExec@MGBehavior .
.
250
251
op minTimer@AtomicActionExec@MGBehavior : −> @Attribute .
252
eq name ( minTimer@AtomicActionExec@MGBehavior ) = "minTimer" .
253
eq type ( minTimer@AtomicActionExec@MGBehavior ) =
254
eq lowerBound ( minTimer@AtomicActionExec@MGBehavior ) = 0 .
255
eq upperBound ( minTimer@AtomicActionExec@MGBehavior ) = 1 .
256
eq containingClass ( minTimer@AtomicActionExec@MGBehavior ) = AtomicActionExec@MGBehavior .
257
eq isId ( minTimer@AtomicActionExec@MGBehavior ) = false .
258
eq isOrdered ( minTimer@AtomicActionExec@MGBehavior ) = true .
259
eq isUnique ( minTimer@AtomicActionExec@MGBehavior ) = true .
@Time .
260
261
op executionTime@AtomicActionExec@MGBehavior : −> @Attribute .
262
eq name ( executionTime@AtomicActionExec@MGBehavior ) = "executionTime" .
263
eq type ( executionTime@AtomicActionExec@MGBehavior ) =
264
eq lowerBound ( executionTime@AtomicActionExec@MGBehavior ) = 1 .
265
eq upperBound ( executionTime@AtomicActionExec@MGBehavior ) = 1 .
266
eq containingClass ( executionTime@AtomicActionExec@MGBehavior )
267
@Time .
= AtomicActionExec@MGBehavior .
268
eq isId ( executionTime@AtomicActionExec@MGBehavior ) = false .
269
eq isOrdered ( executionTime@AtomicActionExec@MGBehavior ) = true .
270
eq isUnique ( executionTime@AtomicActionExec@MGBehavior ) = true .
271
272
op status@AtomicActionExec@MGBehavior : −> @Attribute .
273
eq name ( status@AtomicActionExec@MGBehavior ) = "status" .
274
eq type ( status@AtomicActionExec@MGBehavior ) = ActionStatus@MGBehavior .
275
eq lowerBound ( status@AtomicActionExec@MGBehavior ) = 1 .
276
eq upperBound ( status@AtomicActionExec@MGBehavior ) = 1 .
277
eq containingClass ( status@AtomicActionExec@MGBehavior ) = AtomicActionExec@MGBehavior .
278
eq isId ( status@AtomicActionExec@MGBehavior ) = false .
279
eq isOrdered ( status@AtomicActionExec@MGBehavior ) = true .
280
eq isUnique ( status@AtomicActionExec@MGBehavior ) = true .
281
282
s o r t ActionStatus@MGBehavior .
283
op ActionStatus@MGBehavior : −> @Enumeration .
284
s u b s o r t ActionStatus@MGBehavior < @EnumerationInstance .
285
286
--- An atomic action execution can be
223
287
--- a) Unfinished
288
--- b) Realized
289
--- c) Interrupted (deleted explicitly by a rule)
290
--- d) Aborted (the realization rule cannot be applied)
291
op unfinished@ActionStatus@MGBehavior : −> ActionStatus@MGBehavior .
292
op realized@ActionStatus@MGBehavior : −> ActionStatus@MGBehavior .
293
op interrupted@ActionStatus@MGBehavior : −> ActionStatus@MGBehavior .
294
op aborted@ActionStatus@MGBehavior : −> ActionStatus@MGBehavior .
295
296
s o r t OngoingActionExec@MGBehavior .
297
s u b s o r t OngoingActionExec@MGBehavior < ActionExec@MGBehavior .
298
op OngoingActionExec@MGBehavior : −> OngoingActionExec@MGBehavior .
299
eq name ( OngoingActionExec@MGBehavior ) = "OngoingActionExec" .
300
eq isAbstract ( OngoingActionExec@MGBehavior ) = false .
301
eq package ( OngoingActionExec@MGBehavior ) = MGBehavior .
302
eq superTypes ( OngoingActionExec@MGBehavior ) = ActionExec@MGBehavior .
303
eq references ( OngoingActionExec@MGBehavior ) = nil
304
eq attributes ( OngoingActionExec@MGBehavior )
305
.
= upperBoundTimer@OngoingActionExec@MGBehavior .
306
307
op upperBoundTimer@OngoingActionExec@MGBehavior : −> @Attribute .
308
eq name ( upperBoundTimer@OngoingActionExec@MGBehavior ) = "upperBoundTimer" .
309
eq type ( upperBoundTimer@OngoingActionExec@MGBehavior ) =
310
eq lowerBound ( upperBoundTimer@OngoingActionExec@MGBehavior ) = 0 .
311
eq upperBound ( upperBoundTimer@OngoingActionExec@MGBehavior ) = 1 .
312
eq containingClass ( upperBoundTimer@OngoingActionExec@MGBehavior )
313
@Time .
= OngoingActionExec@MGBehavior .
314
eq isId ( upperBoundTimer@OngoingActionExec@MGBehavior ) = false .
315
eq isOrdered ( upperBoundTimer@OngoingActionExec@MGBehavior ) = true .
316
eq isUnique ( upperBoundTimer@OngoingActionExec@MGBehavior ) = true .
317
318
s o r t Variable@MGBehavior .
319
s u b s o r t Variable@MGBehavior < @Class .
320
op Variable@MGBehavior : −> Variable@MGBehavior .
321
eq name ( Variable@MGBehavior ) = "Variable" .
322
eq isAbstract ( Variable@MGBehavior ) = false .
323
eq package ( Variable@MGBehavior ) = MGBehavior .
324
eq superTypes ( Variable@MGBehavior ) = nil .
325
eq references ( Variable@MGBehavior ) = nil .
326
eq attributes ( ObjectRole@MGBehavior ) = name@Variable@MGBehavior
327
value@Variable@MGBehavior .
328
329
op name@Variable@MGBehavior : −> @Attribute .
330
eq name ( name@Variable@MGBehavior ) = "name" .
331
eq type ( name@Variable@MGBehavior ) =
332
eq lowerBound ( name@Variable@MGBehavior ) = 1 .
333
eq upperBound ( name@Variable@MGBehavior ) = 1 .
334
eq containingClass ( name@Variable@MGBehavior ) = Variable@MGBehavior .
335
eq isId ( name@Variable@MGBehavior ) = false .
336
eq isOrdered ( name@Variable@MGBehavior ) = true .
337
eq isUnique ( name@Variable@MGBehavior ) = true .
@String .
224
338
339
op value@Variable@MGBehavior : −> @Attribute .
340
eq name ( value@Variable@MGBehavior ) = "value" .
341
eq type ( value@Variable@MGBehavior ) =
342
eq lowerBound ( value@Variable@MGBehavior ) = 1 .
343
eq upperBound ( value@Variable@MGBehavior ) = 1 .
344
eq containingClass ( value@Variable@MGBehavior ) = Variable@MGBehavior .
345
eq isId ( value@Variable@MGBehavior ) = false .
346
eq isOrdered ( value@Variable@MGBehavior ) = true .
347
eq isUnique ( value@Variable@MGBehavior ) = true .
@DataType .
348
349
s o r t ObjectRole@MGBehavior .
350
s u b s o r t ObjectRole@MGBehavior < @Class .
351
op ObjectRole@MGBehavior : −> ObjectRole@MGBehavior .
352
eq name ( ObjectRole@MGBehavior ) = "ObjectRole" .
353
eq isAbstract ( ObjectRole@MGBehavior ) = false .
354
eq package ( ObjectRole@MGBehavior ) = MGBehavior .
355
eq superTypes ( ObjectRole@MGBehavior ) = nil .
356
eq references ( ObjectRole@MGBehavior ) = actualObject@ObjectRole@MGBehavior
357
eq attributes ( ObjectRole@MGBehavior ) = role@ObjectRole@MGBehavior .
.
358
359
op actualObject@ObjectRole@MGBehavior : −> @Reference .
360
eq name ( actualObject@ObjectRole@MGBehavior ) = "actualObject" .
361
eq type ( actualObject@ObjectRole@MGBehavior ) =
362
eq opposite ( actualObject@ObjectRole@MGBehavior ) = null .
363
eq lowerBound ( actualObject@ObjectRole@MGBehavior ) = 1 .
364
eq upperBound ( actualObject@ObjectRole@MGBehavior ) = 1 .
365
eq containingClass ( actualObject@ObjectRole@MGBehavior ) = ObjectRole@MGBehavior .
366
eq isContainment ( actualObject@ObjectRole@MGBehavior ) = false .
367
eq isOrdered ( actualObject@ObjectRole@MGBehavior ) = true .
368
eq isUnique ( actualObject@ObjectRole@MGBehavior ) = true .
@Object .
369
370
op role@ObjectRole@MGBehavior : −> @Attribute .
371
eq name ( role@ObjectRole@MGBehavior ) = "role" .
372
eq type ( role@ObjectRole@MGBehavior ) =
373
eq lowerBound ( role@ObjectRole@MGBehavior ) = 1 .
374
eq upperBound ( role@ObjectRole@MGBehavior ) = 1 .
375
eq containingClass ( role@ObjectRole@MGBehavior ) = ObjectRole@MGBehavior .
376
eq isId ( role@ObjectRole@MGBehavior ) = false .
377
eq isOrdered ( role@ObjectRole@MGBehavior ) = true .
378
eq isUnique ( role@ObjectRole@MGBehavior ) = true .
@String .
379
380
--- The Clock
381
s o r t Clock@MGBehavior .
382
s u b s o r t Clock@MGBehavior < @Class .
383
op Clock@MGBehavior : −> Clock@MGBehavior .
384
eq name ( Clock@MGBehavior ) = "Clock" .
385
eq isAbstract ( Clock@MGBehavior ) = false .
386
eq package ( Clock@MGBehavior ) = MGBehavior .
387
eq superTypes ( Clock@MGBehavior ) = nil .
388
eq references ( Clock@MGBehavior ) = nil .
225
389
eq attributes ( Clock@MGBehavior ) = time@Clock@MGBehavior .
390
391
op time@Clock@MGBehavior : −> @Attribute .
392
eq name ( time@Clock@MGBehavior ) = "time" .
393
eq type ( time@Clock@MGBehavior ) =
394
eq lowerBound ( time@Clock@MGBehavior ) = 1 .
395
eq upperBound ( time@Clock@MGBehavior ) = 1 .
396
eq containingClass ( time@Clock@MGBehavior ) = Clock@MGBehavior .
397
eq isId ( time@Clock@MGBehavior ) = false .
398
eq isOrdered ( time@Clock@MGBehavior ) = true .
399
eq isUnique ( time@Clock@MGBehavior ) = true .
@Time .
400
401
--- Counters: to create new identifiers and count the random operation invocations
402
s o r t Counter@MGBehavior .
403
s u b s o r t Counter@MGBehavior < @Class .
404
op Counter@MGBehavior : −> Counter@MGBehavior .
405
eq name ( Counter@MGBehavior ) = "Counter" .
406
eq isAbstract ( Counter@MGBehavior ) = false .
407
eq package ( Counter@MGBehavior ) = MGBehavior .
408
eq superTypes ( Counter@MGBehavior ) = nil .
409
eq references ( Counter@MGBehavior ) = nil .
410
eq attributes ( Counter@MGBehavior ) = value@Counter@MGBehavior .
411
412
op value@Counter@MGBehavior : −> @Attribute .
413
eq name ( value@Counter@MGBehavior ) = "value" .
414
eq type ( value@Counter@MGBehavior ) =
415
eq lowerBound ( value@Counter@MGBehavior ) = 1 .
416
eq upperBound ( value@Counter@MGBehavior ) = 1 .
417
eq containingClass ( value@Counter@MGBehavior ) = Counter@MGBehavior .
418
eq isId ( value@Counter@MGBehavior ) = false .
419
eq isOrdered ( value@Counter@MGBehavior ) = true .
420
eq isUnique ( value@Counter@MGBehavior ) = true .
@Int .
421
422
--- To get Clock and ActionExec properties through OCL expressions
423
op startingTime@OCLSf : −> @StructuralFeature .
424
eq name ( startingTime@OCLSf ) = "startingTime" .
425
op endingTime@OCLSf : −> @StructuralFeature .
426
eq name ( endingTime@OCLSf ) = "endingTime" .
427
op executionTime@OCLSf : −> @StructuralFeature .
428
eq name ( executionTime@OCLSf ) = "executionTime" .
429
op time@OCLSf : −> @StructuralFeature .
430
431
eq name ( time@OCLSf ) = "time" .
endm
226
Appendix D
Maude Operations for Querying a
Simulation
The following Maude operations have been defined to query the result of a simulation, and
to present it in a more readable way. In these operations, oid, name and t represent variables
of sort Oid, String and Time, respectively, while system represents a variable of sort either
ClockedSystem or @Model.
• finalizedActions(system)
Displays information on the actions that are finalized (either realized, interrupted, or
aborted) in the system. The result is a list of elements composed of the name of the
action, the time at which the action was triggered, the time at which the action was
finalized, and the set of the identifiers of the participant elements.
• currentActions(system)
Displays information on the actions that are triggered but not finalized (i.e., the unfinished actions) in the system. The result is a list of elements composed of the name of
the action, the time at which the action was triggered, and the set of the identifiers of the
participant elements.
• finalizedOccurrencesOf(name, system)
Displays information on the occurrences of the name rule that are finalized in the system.
The result is a list of elements composed of the time at which the rule was triggered,
the time at which the rule was finalized, and the set of the identifiers of the participant
elements.
227
228
A PPENDIX D. M AUDE O PERATIONS FOR Q UERYING
A
S IMULATION
• finalizedOccurrencesOf(oid, name, system)
Displays information on the occurrences of the name rule that are finalized in the system
in which oid is one of the participants. The result is a list of elements composed of the
time at which the rule was triggered and the time at which the rule was finalized.
• finalizedActionsOf(oid, system)
Displays information on the actions in the system in which oid is a participant that are
finalized. The result is a list of elements composed of the name of the action, the time at
which the action was triggered, and the time at which the action was finalized.
• actionsAt(t, system)
Displays information on the actions in the system that are under execution at time t. The
result is a list of elements composed of the name of the action and the set of the identifiers
of the participant elements.
• actionsAt(oid, t, system)
Displays information on the actions in the system in which oid is a participant that are
under execution at time t. The result is a list of elements composed of the name of the
action and the set of the identifiers of the remaining participant elements.
• occurrenceAt?(oid, name, t, system)
Displays a boolean value stating whether an occurrence of the rule with label name in
which oid is a participant is under execution at time t in the system or not.
• startingActionsAt(t, system)
Displays information on the actions that start at time t in the system. The result is a
list of elements composed of the name of the action and the set of the identifiers of the
participant elements.
• finalizedActionsAt(t, system)
Displays information on the actions that are finalized at time t in the system. The result
is a list of elements composed of the name of the action and the set of the identifiers of
the participant elements.
Bibliography
[1] The AADL web site.
currentsite/.
Available at http://www.aadl.info/aadl/
[2] Atenea group. Available at http://atenea.lcc.uma.es.
[3] The ATLAS Transformation Language (ATL) web site. Available at http://www.
eclipse.org/m2m/atl/.
[4] Maude manual and examples.
maude2-manual/.
Available at http://maude.cs.uiuc.edu/
[5] The MOMENT web site. Available at http://moment.dsic.upv.es.
[6] The official OMG MARTE web site. Available at http://www.omgmarte.org/.
[7] Textual Concrete Syntax (TCS).
index.php/TCS.
Available at http://wiki.eclipse.org/
[8] The Eclipse Graphical Modeling Framework (GMF). Available at http://www.
eclipse.org/modeling/gmf/.
[9] The Eclipse Modeling Framework (EMF). Available at http://www.eclipse.
org/modeling/emf/.
[10] The mOdCL tool. Available at http://maude.lcc.uma.es/mOdCL.
[11] The Object Management Group (OMG). Available at http://www.omg.org/.
[12] The MOVA tool: a validation tool for UML, 2006. Available at http://maude.
sip.ucm.es/mova/.
[13] S. Alagic and P. Bernstein. A model theory for generic schema management. In G. Ghelli
and G. Grahne, editors, Proc. of the 8th International Workshop on DataBase Programming Languages (DBPL’01), volume 2397 of LNCS, pages 228–246. Springer-Verlag,
2002.
[14] M. Alanen and I. Porres. Difference and union of models. In Proc. of the 6th International Conference on the Unified Modeling Language: Modeling Languages and
Applications (UML’03), volume 2863 of LNCS, pages 2–17. Springer-Verlag, 2003.
229
230
BIBLIOGRAPHY
[15] P. Baldan, A. Corradini, and B. König. A static analysis technique for graph transformation systems. In Proc. of the 12th International Conference on Concurrency Theory
(CONCUR’01), volume 2154 of LNCS, pages 381–395. Springer-Verlag, 2001.
[16] L. Baresi and P. Spoletini. On the use of Alloy to analyze graph transformation systems.
In Proc. of the 3rd International Conference on Graph Transformation (ICGT’06), volume 4178 of LNCS, pages 306–320. Springer-Verlag, 2006.
[17] D. Batory, M. Azanza, and J. Saraiva. The objects and arrows of computational design.
In Proc. of the 11th International Conference on Model Driven Engineering Languages
and Systems (MoDELS’08), pages 1–20. Springer-Verlag, 2008.
[18] D. F. Bender, B. Combemale, X. Crégut, J. M. Farines, B. Berthomieu, and F. Vernadat. Ladder metamodeling and PLC program validation through time Petri nets. In
Proc. of the 4th European Conference on Model Driven Architecture: Fondations and
Applications (ECMDA-FA’08), pages 121–136. Springer-Verlag, 2008.
[19] P. Bernstein. Applying model management to classical metadata problems. In Proc. of
the 1st Conference on Innovative Database Research (CIDR’03), pages 209–220, 2003.
[20] J. Bézivin. On the unification power of models. Journal on Software and Systems
Modeling, 4(2):171–188, 2005.
[21] J. Bézivin and F. Jouault. KM3: a DSL for metamodel specification. In Procs. of the 8th
IFIP International Conference on Formal Methods for Open Object-based Distributed
Systems (FMOODS’06), volume 4037 of LNCS, pages 171–185. Springer-Verlag, Apr.
2006.
[22] X. Blanc, M.-P. Gervais, and P. Sriplakich. Model bus: Towards the interoperability of modelig tools. In U. Aßmann, M. Aksit, and A. Rensink, editors, Proc. of the
2th Working Conference on Model Driven Architecture: Foundations and Applications
(MDA-FA’04), volume 3599 of LNCS, pages 17–32. Springer-Verlag, 2005.
[23] A. Boronat, J. A. Carsı́, and I. Ramos. Automatic support for traceability in a generic
model management framework. In Proc. of the 1st European Conference on Model
Driven Architecture: Fondations and Applications (ECMDA-FA’05), volume 3748 of
LNCS, pages 316–330. Springer-Verlag, 2005.
[24] A. Boronat, R. Heckel, and J. Meseguer. Rewriting logic semantics and verification of
model transformations. In Proc. of the 12th International Conference on Fundamental
Approaches to Software Engineering (FASE’09), pages 18–33, 2009.
[25] A. Boronat and J. Meseguer. An algebraic semantics for MOF. In Proc. of the 11th International Conference on Fundamental Approaches to Software Engineering (FASE’08),
volume 4961 of LNCS, pages 377–391. Springer-Verlag, 2008.
BIBLIOGRAPHY
231
[26] A. Boronat and P. C. Ölveczky. Formal real-time model transformations in MOMENT2.
In D. S. Rosenblum and G. Taentzer, editors, Proc. of the 13th International Conference on Fundamental Approaches to Software Engineering (FASE’10), volume 6013 of
[27] A. Bouhoula, J.-P. Jouannaud, and J. Meseguer. Specification and proof in membership
equational logic. Theoretical Computer Science, 236(1):35–132, 2000.
[28] R. Breu, R. Gosu, F. Huber, B. Rumpe, and W. Schwerin. Towards a precise semantics for object-oriented modeling techniques. In Proc. of Object-Oriented Technology:
ECOOP’97 Workshops, volume 1357 of LNCS, pages 205–210. Springer-Verlag, 1998.
[29] C. Brun and A. Pierantonio. Model differences in the Eclipse Modeling Framework.
Upgrade, Special Issue on Model-Driven Software Development, IX(2), Apr. 2008.
[30] R. Bruni and J. Meseguer. Semantic foundations for generalized rewrite theories. Theoretical Computer Science, 360(1-3):386–414, 2006.
[31] S. Burmester and H. Giese. The Fujaba real-time statechart plugin. In H. Giese and
A. Zündorf, editors, Proc. of the 1st International Fujaba Days, pages 1–8. University
of Paderborn, 2003.
[32] S. Burmester, H. Giese, M. Hirsch, D. Schilling, and M. Tichy. The Fujaba real-time
tool suite: model-driven development of safety-critical, real-time systems. In Proc. of
the 27th International Conference on Software Engineering (ICSE’05), pages 670–671.
ACM, 2005.
[33] F. Büttner and M. Gogolla. Realizing graph transformations by pre- and postconditions
and command sequences. In Proc. of the 3rd International Conference on Graph Transformation (ICGT’06), volume 4178 of LNCS, pages 398–413. Springer-Verlag, 2006.
[34] J. Cabot, R. Clarisó, E. Guerra, and J. de Lara. Analysing graph transformation rules
through OCL. In Proc. of the 1st International Conference on Model Transformation
(ICMT’08), volume 5063 of LNCS, pages 225–239. Springer-Verlag, 2008.
[35] C. Calero, M. Genero, and M. Piattini. Metrics for Software Conceptual Models. Imperial College Press, 2005.
[36] M. V. Cengarle, A. Knapp, A. Tarlecki, and M. Wirsing. A heterogeneous approach
to uml semantics. In H. Hussmann, editor, Concurrency, Graphs and Models: Essays
dedicated to Ugo Montanari on the occasion of his 65th birthday, volume 2029 of LNCS,
pages 383–402. Springer-Verlag, 2008.
[37] K. Chen, J. Sztipanovits, S. Abdelwalhed, and E. Jackson. Semantic anchoring with
model transformations. In Proc. of the 1st European Conference on Model Driven Architecture: Fondations and Applications (ECMDA-FA’05), volume 3748 of LNCS, pages
115–129. Springer-Verlag, 2005.
232
BIBLIOGRAPHY
[38] A. Cicchetti, D. D. Ruscio, and A. Pierantonio. A domain-specific modeling language
for model differences. Technical report, Università di L’ Aquila, 2006.
[39] A. Cicchetti, D. D. Ruscio, and A. Pierantonio. A metamodel independent approach to
difference representation. Journal of Object Technology, 6(9):165–185, Oct. 2007.
[40] T. Clark, P. Sammut, and J. Willans. Applied Metamodelling. Ceteva, 2 edition, 2004.
[41] M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Martı́-Oliet, J. Meseguer, and J. Quesada.
Maude: specification and programming in rewriting logic. Theoretical Computer Science, 285:187–243, Aug. 2002.
[42] M. Clavel, F. Durán, S. Eker, P. Lincoln, N. Martı́-Oliet, J. Meseguer, and C. Talcott.
All About Maude – A High-Performance Logical Framework, volume 4350 of LNCS.
Springer-Verlag, 2007.
[43] M. Clavel, F. Durán, J. Hendrix, S. Lucas, J. Meseguer, and P. Ölveczky. The Maude
formal tool environment. In T. Mossakowski, U. Montanari, and M. Haveraaen, editors, Proc. of the 2nd Conference on Algebra and Coalgebra in Computer Science
(CALCO’07), volume 4624 of LNCS, pages 173–178. Springer-Verlag, Aug. 2007.
[44] M. Clavel, M. Palomino, and A. Riesco. Introducing the ITP tool: a tutorial. Journal of
Universal Computer Science, 12(11):1618–1650, 2006.
[45] A. Cuccuru, C. Mraidha, F. Terrier, and S. Grard. Enhancing UML extensions with
operational semantics: Behaviored profiles with templates. In Proc. of the 10th International Conference on Model Driven Engineering Languages and Systems (MoDELS’07),
volume 4735 of LNCS, pages 271–285. Springer-Verlag, 2007.
[46] K. Czarnecki and S. Helsen. Classification of model transformation approaches. In
OOPSLA’03 Workshop on Generative Techniques in the Context of Model-Driven Architecture, 2003.
[47] J. de Lara, R. Bardohl, H. Ehrig, K. Ehrig, U. Prange, and G. Taentzer. Attributed graph
transformation with node type inheritance. Theoretical Computer Science, 376(3):139–
163, 2007.
[48] J. de Lara and H. Vangheluwe. Defining visual notations and their manipulation through
meta-modelling and graph transformation. Journal of Visual Languages and Computing,
15(3–4):309–330, 2006.
[49] J. de Lara and H. Vangheluwe. Translating model simulators to analysis models. In
Proc. of the 11th International Conference on Fundamental Approaches to Software
Engineering (FASE’08), volume 4961 of LNCS, pages 77–92. Springer-Verlag, 2008.
[50] J. de Lara and H. Vangheluwe. Automating the transformation-based analysis of visual
languages. Formal Aspects of Computing, 22(3-4):297–326, May 2010.
BIBLIOGRAPHY
233
[51] F. Durán. A Reflective Module Algebra with Applications to the Maude Language. PhD
thesis, Universidad de Málaga, Spain, June 1999. Available at http://maude.csl.
sri.com/papers.
[52] F. Durán, S. Lucas, and J. Meseguer. MTT: The Maude Termination Tool (system
description). In Proc. of the 4th International Joint Conference on Automated Reasoning
(IJCAR ’08), pages 313–319. Springer-Verlag, 2008.
[53] F. Durán and J. Meseguer. A Church-Rosser checker tool for conditional order-sorted
equational Maude specifications. In P. C. Ölveczky, editor, Proc. of the 8th International
Workshop on Rewriting Logic and its Applications (WRLA’10), LNCS. Springer-Verlag,
Mar. 2010.
[54] F. Durán and J. Meseguer. A Maude coherence checker tool for conditional order-sorted
equational Maude specifications. In P. C. Ölveczky, editor, Proc. of the 8th International
Mar. 2010.
[55] F. Durán, M. Roldán, and A. Vallecillo. Invariant-driven strategies for Maude. In Proc. of
the 4th International Workshop on Reduction Strategies in Rewriting and Programming
(WRS’04). Elsevier, June 2005.
[56] J. Edwards, D. Jackson, and E. Torlak. A type system for object models. SIGSOFT
Software Engineering Notes, 29(6):189–199, 2004.
[57] H. Ehrig, K. Ehrig, U. Prange, and G. Taentzer. Fundamentals of algebraic graph transformation. Springer-Verlag, 2006.
[58] S. Eker, N. Martı́-Oliet, J. Meseguer, and A. Verdejo. Deduction, strategies, and rewriting. Electron. Notes Theor. Comput. Sci., 174(11):3–25, 2007.
[59] S. Eker, J. Meseguer, and A. Sridharanarayanan. The Maude LTL model checker.
In Proc. of the 4th International Workshop on Rewriting Logic and its Applications
(WRLA’02), volume 71 of ENTCS, pages 115–142. Elsevier, Sept. 2002.
[60] G. Engels, J. H. Hausmann, R. Heckel, and S. Sauer. Dynamic meta modeling: A graphical approach to the operational semantics of behavioral diagrams in UML. In Proc. of the
3th International Conference on the Unified Modeling Language: Modeling Languages
and Applications (UML’00), volume 1939 of LNCS, pages 323–337. Springer-Verlag,
2000.
[61] T. Fischer, J. Niere, L. Torunski, and A. Zündorf. Story diagrams: A new graph rewrite
language based on the unified modeling language. In Proc. of the 6th International
Workshop on Theory and Application of Graph Transformation (TAGT’98), 1998.
[62] C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezzè. A unified high-level petri net
formalism for time-critical systems. IEEE Trans. Softw. Eng., 17(2):160–172, 1991.
234
BIBLIOGRAPHY
[63] J. A. Goguen. Data, schema, ontology and logic integration. Logic Journal of the IGPL,
13(6):685–715, Nov. 2005.
[64] S. Gyapay, R. Heckel, and D. Varró. Graph transformation with time: Causality and
logical clocks. In Proc. of 1st International Conference on Graph Transformation
(ICGT’02), pages 120–134. Springer-Verlag, 2002.
[65] A. Habel and K.-H. Pennemann. Satisfiability of high-level conditions. In Proc. of
the 3rd International Conference on Graph Transformation (ICGT’06), volume 4178 of
[66] D. Harel and B. Rumpe. Meaningful modeling: What’s the semantics of “semantics”?
Computer, 37(10):64–72, 2004.
[67] R. Heckel, J. M. Küster, and G. Taentzer. Confluence of typed attributed graph transformation systems. In Proc. of 1st International Conference on Graph Transformation
(ICGT’02), volume 2505 of LNCS, pages 161–176. Springer-Verlag, 2002.
[68] J. D. Hendrix. Decision procedures for equationally based reasoning. PhD thesis,
University of Illinois at Urbana-Champaign, 2008. Technical Report: UIUCDCS-R2008-2999.
[69] J. L. C. Izquierdo and J. G. Molina. Gra2mol: Una herramienta para la extraccin demodelos en modernizacin de software. In A. Vallecillo and G. Sagardui, editors, Proc. of the
XIV Jornadas de Ingenierı́a del Software y Bases de Datos (JISBD’09), pages 162–165,
Sept. 2009.
[70] F. Jouault, J. Bézivin, and I. Kurtev. TCS: a DSL for the specification of textual concrete
syntaxes in model engineering. In Proc. of the 5th International Conference on Generative Programming and Component Engineering (GPCE’06), pages 249–254. ACM,
2006.
[71] F. Jouault and I. Kurtev. Transforming models with atl. In Satellite Events at the MoDELS 2005 Conference, volume 3844 of LNCS, pages 128–138. Springer-Verlag, 2006.
[72] S.-K. Kim and D. Carrington. Formalizing the UML class diagram using Object-Z. In
R. B. France and B. Rumpe, editors, Proc. of the 2nd International Conference on the
Unified Modeling Language (UML’99), volume 1723 of LNCS, pages 83–98. SpringerVerlag, 1999.
[73] A. Kleppe. A language description is more than a metamodel. In Proc. of 4th International Workshop on Software Language Engineering (ATEM’07), Oct. 2007.
[74] A. G. Kleppe, J. Warmer, and W. Bast. MDA Explained: The Model Driven Architecture:
Practice and Promise. Addison-Wesley Longman Publishing Co., Inc., 2003.
[75] P. Krishnan. Consistency checks for uml. In Proc. of the 7th Asia-Pacific Software
Engineering Conference (APSEC’00), pages 162–169. IEEE Computer Society, 2000.
BIBLIOGRAPHY
235
[76] V. I. Levenshtein. Binary codes capable of correcting deletions, insertions, and reversals.
Soviet Physics Doklady, 10:707, 1966.
[77] Y. Lin, J. Gray, and F. Jouault. DSMDiff: A differentiation tool for domain-specific
models. European Journal of Information Systems, 16:349–361, 2007.
[78] R. E. Lopez-Herrejon and J. E. Rivera. Realizing feature oriented software development
with equational logic: An exploratory study. In A. Vallecillo and G. Sagardui, editors,
Proc. of the XIV Jornadas de Ingenierı́a del Software y Bases de Datos (JISBD’09),
pages 269–274, Sept. 2009.
[79] S. Marković and T. Baar. Semantics of OCL Specified with QVT. Journal of Software
and Systems Modeling (SoSyM), 2008.
[80] N. Martı́-Oliet and J. Meseguer. Rewriting logic: roadmap and bibliography. Theoretical
Computer Science, 285(2):121–154, 2002.
[81] T. Mens. A state-of-the-art survey on software merging. IEEE Transactions on Software
Engineering, 28(5):449–462, 2002.
[82] P. M. Merlin. A study of the recoverability of computer systems. PhD thesis, University
of California, Irvine, Apr. 1974.
[83] J. Meseguer. Conditional rewriting logic as a unified model of concurrency. Theoretical
Computer Science, 96:73–155, 1992.
[84] J. Meseguer. The temporal logic of rewriting: A gentle introduction. In Concurrency,
Graphs and Models, volume 5065 of LNCS, pages 354–382. Springer-Verlag, 2008.
[85] J. Meseguer, M. Palomino, and N. Martı́-Oliet. Equational abstractions. In Proc. of the
19th International Conference on Automated Deduction (CADE’03), volume 2741 of
[86] P.-A. Muller, F. Fleurey, and J.-M. Jézéquel. Weaving executability into object-oriented
meta-languages. In Proc. of the 8th ACM/IEEE International Conference on Model
Driven Engineering Languages and Systems (MoDELS’05), volume 3713 of LNCS,
pages 264–278. Springer-Verlag, 2005.
[87] D. Ohst, M. Welle, and U. Kelter. Difference tools for analysis and design documents.
In Proc. of the International Conference on Software Maintenance (ICSM’03), page 13.
IEEE Computer Society, 2003.
[88] D. Ohst, M. Welle, and U. Kelter. Differences between versions of uml diagrams. SIGSOFT Software Engineering Notes, 28(5):227–236, 2003.
[89] P. C. Ölveczky. Real-Time Maude 2.3 Manual, 2007. Available at http://www.
ifi.uio.no/RealTimeMaude/.
[90] P. C. Ölveczky and J. Meseguer. Abstraction and completeness for real-time maude.
Electron. Notes Theor. Comput. Sci., 176(4):5–27, 2007.
236
BIBLIOGRAPHY
[91] P. C. Ölveczky and J. Meseguer. Semantics and pragmatics of Real-Time Maude.
Higher-Order and Symbolic Computation, 20(1-2):161–196, 2007.
[92] OMG. Meta Object Facility (MOF) 2.0 Core Specification. OMG, 2003. OMG doc.
ptc/03-10-04, available at http://www.omg.org/docs/ptc/03-10-04.pdf.
[93] OMG. Model Driven Arquitecture Guide. OMG, Nov. 2005. OMG doc. formal/05-1103.
[94] OMG. Unified Modeling Language 2.1.1 Superstructure Specification. OMG, Feb.
2007. OMG doc. formal/07-02-05.
[95] I. Poernomo. Proofs-as-model-transformations. In Proc. of the 1st International Conference on Model Transformation (ICMT’08), volume 5063 of LNCS, pages 210–224.
Springer-Verlag, 2008.
[96] G. Reggio, M. Cerioli, and E. Astesiano. Towards a rigorous semantics of uml supporting its multiview approach. In H. Hussmann, editor, Proc. of the 4th International
Conference on Fundamental Approaches to Software Engineering (FASE’01), volume
2029 of LNCS, pages 171–186. Springer-Verlag, 2001.
[97] A. Rensink. Explicit state model checking for graph grammars. In Concurrency, Graphs
and Models, volume 5065 of LNCS, pages 114–132. Springer-Verlag, 2008.
[98] J. E. Rivera, F. Durán, and A. Vallecillo. A metamodel for maude. Technical report, University of Málaga, 2008. Available at http://atenea.lcc.uma.es/images/
e/e0/MaudeMM.pdf.
[99] J. E. Rivera, F. Durán, and A. Vallecillo. A graphical approach for modeling timedependent behavior of DSLs. In Proc. of the IEEE Symposium on Visual Languages and
Human-Centric Computing (VL/HCC’09), pages 51–55. IEEE Computer Society, Sept.
2009.
[100] J. E. Rivera, F. Durán, and A. Vallecillo. On the behavioral semantics of real-time
domain specific visual languages. In P. C. Ölveczky, editor, Proc. of the 8th International
Mar. 2010.
[101] J. E. Rivera, F. Durán, A. Vallecillo, and J. R. Romero. Maudeling: Herramienta de
gestión de modelos usando Maude. In Proc. of the XII Jornadas de Ingenierı́a del
Software y Bases de Datos (JISBD’07), pages 409–410, Sept. 2007.
[102] J. E. Rivera, E. Guerra, J. de Lara, and A. Vallecillo. Analyzing rule-based behavioral
semantics of visual modeling languages with Maude. In Proc. of the 1st International
Conference on Software Language Engineering (SLE’08), volume 5452 of LNCS, pages
BIBLIOGRAPHY
237
[103] J. E. Rivera and N. Moreno. Subtipado de modelos: Una definición basada en la sustitución entre tipos y en la aplicabilidad de operaciones. In Proc. of the XI Workshop
Iberoamericano de Ingeniera de Requisitos y Ambientes de Software (IDEAS’08), pages
375–380, Feb. 2008.
[104] J. E. Rivera and A. Vallecillo. Adding behavioral semantics to models. In Proc.
of the 11th IEEE International Enterprise Distributed Object Computing Conference
(EDOC’07), pages 169–180. IEEE Computer Society, Oct. 2007.
[105] J. E. Rivera and A. Vallecillo. Representing and operating with model differences. In
Proc. of the 46th International Conference on Objects, Models, Components, Patterns
(TOOLS’08), volume 11 of Lecture Notes in Business Information Processing, pages
[106] J. E. Rivera, A. Vallecillo, and F. Durán. Formal specification and analysis of domain
specific languages using Maude. Simulation: Transactions of the Society for Modeling
and Simulation International, 85(11/12):778–792, 2009.
[107] J. E. Rivera, C. Vicente-Chicote, and A. Vallecillo. Extending visual modeling languages
with timed behavioral specifications. In Proc. of the XII Workshop Iberoamericano de
Ingeniera de Requisitos y Ambientes de software (IDEAS’09), pages 87–100, Apr. 2009.
[108] M. Roldán and F. Durán. Representing UML models in mOdCL. Manuscript. Available
at http://maude.lcc.uma.es/mOdCL, 2008.
[109] M. Roldán, F. Durán, and A. Vallecillo. Invariant-driven specifications in maude. Science of Computer Programming, 74(10):812–835, Aug. 2009.
[110] J. R. Romero, J. E. Rivera, F. Durán, and A. Vallecillo. Formal and tool support for
model driven engineering with Maude. Journal of Object Technology, 6(9):187–207,
Oct. 2007.
[111] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformations, Volume 1: Foundations. World Scientific, 1997.
[112] D. D. Ruscio. Specification of model transformation and weaving in Model Driven
Engineering. PhD thesis, Università del l’Aquila, 2007.
[113] D. D. Ruscio, F. Jouault, I. Kurtev, J. Bézivin, and A. Pierantonio. Extending AMMA
for supporting dynamic semantics specifications of DSLs. Technical Report 06.02, Laboratoire d’Informatique de Nantes-Atlantique (LINA), Apr. 2006.
[114] J. Sáez, A. Toval-Álvarez, and J. L. Fernández-Alemán. Tool support for transforming
UML models to a formal language. In Proc. of Workshop on Transformations of UML
Models (WTUML’01), pages 111–115, Apr. 2001.
[115] D. C. Schmidt. Model-driven engineering. IEEE Computer, 39(2), February 2006.
BIBLIOGRAPHY
238
[116] J. Steel and J.-M. Jézéquel. Model typing for improving reuse in model-driven engineering. In L. Briand and C. Williams, editors, Proc. of the 8th ACM/IEEE International
Conference on Model Driven Engineering Languages and Systems (MoDELS’05), volume 3713 of LNCS, pages 84–96. Springer-Verlag, July 2005.
[117] J. Steel and J.-M. Jézéquel.
6(4):401–413, Dec. 2007.
On model typing.
Software and Systems Modeling,
[118] E. Syriani and H. Vangheluwe. Programmed graph rewriting with time for simulationbased design. In Proc. of the 1st International Conference on Model Transformation
(ICMT’08), volume 5063 of LNCS, pages 91–106. Springer-Verlag, 2008.
[119] A. Toulmé. The EMF compare utility, 2007. Available at http://www.eclipse.
org/modeling/emft/.
[120] A. Toval-Álvarez and J. L. Fernández-Alemán. Formally modeling uml and its evolution: a holistic approach. In Proc. of the 4th International Conference on Formal
Methods for Open Object-based Distributed Dystems (FMOODS’00), pages 183–206.
Kluwer Academic Publishers, 2000.
[121] J. Troya, J. E. Rivera, and A. Vallecillo. On the specification of non-functional properties
of systems by observation. In Proc. of the 2nd International Workshop of Non-functional
System Properties in Domain Specific Modeling Languages (NFPinDSML’09), Oct.
2009.
[122] J. Troya, J. E. Rivera, and A. Vallecillo. Simulating domain specific visual models by observation. In Proc. of the Symposium on Theory of Modeling and Simulation (DEVS’10),
Apr. 2010.
[123] A. Vallecillo. A journey through the secret life of models. In U. As̈mann, J. Bézivin,
R. Paige, B. Rumpe, and D. C. Schmidt, editors, Perspectives Workshop: Model Engineering of Complex Systems (MECS), number 08331 in Dagstuhl Seminar Proceedings,
2008.
[124] H. Vangheluwe and J. de Lara. Automatic generation of model-to-model transformations
from rule-based specifications of operational semantics. In Proc. of the 7th OOPSLA
Workshop on Domain-Specific Modeling (DSM’07), Oct. 2007.
[125] D. Varró. Automated formal verification of visual modeling languages by model checking. Software and System Modeling, 3(2):85–113, 2004.
[126] G. Wachsmuth. Metamodel adaptation and model co-adaptation. In E. Ernst, editor,
Proc. of the 21st European Conference on Object-Oriented Programming (ECOOP’07),
volume 4609 of LNCS, pages 600–624. Springer-Verlag, July 2007.
[127] Z. Xing and E. Stroulia. Umldiff: an algorithm for object-oriented design differencing. In Proc. of the 20th IEEE/ACM International Conference on Automated Software
Engineering (ASE’05), pages 54–65. ACM Press, 2005.
BIBLIOGRAPHY
239
[128] Y. Zhang and B. Xu. A survey of semantic description frameworks for programming
languages. SIGPLAN Not., 39(3):14–30, 2004.
240
BIBLIOGRAPHY
Cuando tomamos conciencia de que no hay una sola interpretación,
que hay múltiples puntos de vista y ninguna representa “la verdad”,
también descubrimos que podemos elegir nuestra manera de observar,
de ver el punto de vista que nos destruye y encontrar el que nos enriquece.
Silvia Salinas: Todo (no) terminó.
i

On the Semantics of Real-Time Domain Specific Modeling

Transcripción

Documentos relacionados

ARCHITECTURE - Sam Fox School | Sam Fox School

A Review of Architecture Tools for the Australian Defence Force