On the Semantics of Real-Time Domain Specific Modeling Languages

Transcription

1 On the Semantics of Real-Time Domain Specific Modeling Languages PhD Thesis of: Jose E. Rivera Advisors: Dr. Antonio Vallecillo Dr. Francisco Durán To obtain the degree of: Doctor por la Universidad de Málaga Dept. Lenguajes y Ciencias de la Computación Universidad de Málaga Jose E. Rivera, 2010

2

3 D. Antonio Vallecillo Moreno, Catedrático de Universidad del Departamento de Lenguajes y Ciencias de la Computación de la E.T.S. de Ingeniería Informática de la Universidad de Málaga, y D. Francisco Javier Durán Muñoz, Profesor Titular de Universidad del Departamento de Lenguajes y Ciencias de la Computación de la E.T.S. de Ingeniería Informática de la Universidad de Málaga Certifican Que D. José Eduardo Rivera Cabaleiro, Ingeniero en Informática, ha realizado en el Departamento de Lenguajes y Ciencias de la Computación de la Universidad de Málaga, bajo nuestra dirección, el trabajo de investigación correspondiente a su Tesis Doctoral titulada On the Semantics of Real-Time Domain Specific Modeling Languages Revisado el presente trabajo, estimamos que puede ser presentado al tribunal que ha de juzgarlo, y autorizamos la presentación de esta Tesis Doctoral en la Universidad de Málaga. Málaga, 27 de Julio de 2010 Fdo.: Antonio Vallecillo Moreno Catedrático de Universidad del Departamento de Lenguajes y Ciencias de la Computación. Fdo.: Francisco Javier Durán Muñoz Titular de Universidad del Departamento de Lenguajes y Ciencias de la Computación.

4

5 No hay hechos, sólo interpretaciones de los hechos. [...] No hay una realidad en sí misma, sólo maneras de observarla. Silvia Salinas: Todo (no) terminó. v

6 vi

7 A mi madre, a mi hermana y a mi tía, las mujeres de mi vida a las que las quiero con locura. A mi padre, del que me hubiera gustado aprender mucho. A mi abuela. Te lo regalo abuela. Pienso que nadie habría sido más feliz en este momento. A mí. vii

8 viii

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

10

11 Contents 1 Introduction Problem Statement Contribution of this Thesis Outline of this Thesis Background Model Driven Engineering in a Nutshell Origins of Model Driven Engineering Model Driven Engineering and Model Driven Architecture Main Technologies of MDE Model Driven Engineering in the Eclipse Platform The Eclipse Modeling Framework The Graphical Modeling Framework Textual Concrete Syntax The ATLAS Transformation Language Rewriting Logic and Maude Rewriting Logic and (Core) Maude Object-Oriented Specifications: Full Maude Object-Oriented Modules in (Core) Maude Real-Time Maude Timed Modules in (Core) Maude The modcl Tool Defining a Domain Specific Modeling Language Introduction Abstract Syntax of a DSML xi

12 3.3 Concrete Syntax of a DSML Semantics of a DSML Semantics Is Not Behavior Defining a DSML (Revisited) Defining the Structural View of a DSML Defining the Behavioral View of a DSML Structural Semantics of DSMLs MEL Representation of Models and Metamodels Representing Metamodels with Maude Representing Models with Maude The Conformance Relationship Structural Semantic Mappings Maude s Metamodel, Parser and Serializer The Metamodel Definition The Maude Code Generator The Maude Parser Encoding EMF Models and Metamodels into Maude Encoding EMF Metamodels Encoding EMF Models Related Work Model Management Model Subtyping Motivation Subtyping Algorithm Kinds of Subtyping The Subtyping Operation in Maude Model Difference Representing Differences The Difference Operation Matching Elements Computing Differences An Example of Model Difference xii

13 5.2.4 Related Operations The do Operation The undo Operation Sequential Composition of Differences Further Operations Tool Support with Maudeling The Way Back to EMF Adapting Difference Models to the Eclipse Platform Related Work Behavioral Semantics of DSMLs Representing DSMLs Behavior with Maude Formal Analysis of Domain Specific Models with Maude Simulation Reachability Analysis LTL Model Checking Representing DSML s Behavior with In-Place Model Transformation In-Place Model Transformation In-Place Rules for the Production System DSML Behavioral Semantic Mappings and Tool Support Related Work Real-Time Behavioral Semantics of DSMLs Motivation The e-motions Language A DSML for Mobile Phone Networks A Model of Time Atomic Rules Ongoing Rules Global Time Elapse Action Statements Concurrency Separation of Concerns Past Actions xiii

14 Exceptions in Actions A Simple Round-Trip Time Protocol Real-time Behavioral Semantic Mappings A General View of the Encoding Encoding of Atomic Rules The Triggering Rule The Realization Rule Encoding of Periodic Rules Encoding of Instantaneous Rules Encoding of Ongoing Rules The Initial Rule The applyongoingrules Operator Encoding of Rule Execution Modes Pass of Time The delta Function The mte Function Formal Analysis of Real-Time Domain Specific Models with Maude Initial Considerations Simulation Querying the Result of a Simulation Reachability Analysis The Role of Tick Modes in the Analysis Reasoning about Action Executions LTL Model Checking The e-motions Tool Related Work Conclusions and Future Work Conclusions Future Work List of Publications Projects A Maude Definitions for Models and Metamodels 199 xiv

15 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

16 xvi

17 List of Figures 1.1 Simple definition of a DSML Mapping a DSML to different semantic domains MDA four-level architecture The Author metamodel An Author model (abstract syntax) An overview of model transformation The Ecore metamodel An Author model (edited with the sample Ecore editor) The GMF process to define a visual concrete syntax for a DSML The Person metamodel Definition of a DSML Metamodel of a DSML for production systems A production system model (abstract syntax) A concrete syntax for the DSML for production systems A production system model (concrete syntax) Semantic bridges across different domains Mapping a DSML to different semantic domains Definition of a DSML (revisited) Structural View of a DSML for Production Systems Behavioral View of a DSML for Production Systems The Maude metamodel The EObject interface The Difference metamodel The Match Metamodel xvii

18 5.3 Example of package refactorization Another production system model (concrete syntax) The Maudeling tool The higher-order transformation process Correspondences between Maude and EMF specifications The GenHandle in-place rule The Assemble in-place rule Further in-place rules of the production system DSML Reachability analysis with the AToM 3 tool The e-motions metamodel A metamodel for MPNs A concrete syntax for the MPN language A mobile phone network model The SwitchOn atomic rule The BatteryOff instantaneous rule The RemoveOffPhones scheduled rule The Coverage periodic rule The distance helper The BatteryConsumptionRule ongoing rule The Moving ongoing rule The correctpos, correctv and power helpers The Call atomic rule The TalkingBatteryConsumption and StandbyBatteryConsumption ongoing rules The InitialModel instantaneous rule The BatteryOffCaller instantaneous rule The BatteryOffCallee instantaneous rule The BatteryOff instantaneous rule (revisited) A metamodel for a simple RTTP A concrete syntax for the RTTP language The Request periodic rule The Response atomic rule The LocalTimeElapse ongoing rule The InitialModel instantaneous rule xviii

19 7.25 A gcs model for the MPN example The GCS metamodel The behavior and rule editors of the e-motions tool The simulation window of the e-motions tool Our approach to define DSMLs General view of our approach xix

20 xx

21 Chapter 1 Introduction Over the past five decades, software researchers and developers have been creating abstractions that help them to program in terms of their design intent rather than constrained by the 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

22 2 CHAPTER 1. INTRODUCTION the whole system can be derived and implemented. Therefore, a precise and formal basis will significantly help us in their definition not to produce unexpected results. Since models are defined with DSMLs, we need to provide DSMLs with semantics to avoid, e.g., semantic ambiguities and conflicting results across different tools. In this thesis, we will focus on the definition of the semantics of DSMLs, covering those that include real-time aspects. 1.1 Problem Statement The definition of a language involves at least three aspects: the domain concepts and rules (abstract syntax); the notation used to represent these concepts let it be textual or graphical (concrete syntax); and the semantics of the language. In MDE, the structure of a DSML is 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,

23 1.1. PROBLEM STATEMENT 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].

24 4 CHAPTER 1. INTRODUCTION 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-

25 1.2. CONTRIBUTION OF THIS THESIS 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 e- Motions, see Chap. 7) as models, we are able to transform them into different semantic domains to (a) provide our DSML with (structural and behavioral) semantics, and (b) take advantage of the analysis tools they provide. In this thesis, we have implemented these semantic bridges to Maude. Maude [4, 42, 41] is a wide-spectrum programming language based on rewriting logic, with membership equational logic as its underlying equational theory. Maude has already been successfully used in software engineering tools and several applications; it is efficient enough to be of a practical use; and has already been integrated in the Eclipse platform. Furthermore, the use of Maude as a target semantic domain brings us more interesting benefits: Maude performs simplification of terms modulo equational theories such as associativity, commutativity and identity (see Section 2.2.1), which enables the specification of many model operations at a very high level of abstraction. Once the system specifications are written using Maude, what we get is a rewriting logic specification of the system. Since the rewriting logic specifications produced are 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,

26 6 CHAPTER 1. INTRODUCTION a termination tool, etc. 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++. The semantic bridges we have defined are composed of a mapping from EMF models and metamodels to membership equational logic theories in Maude, and a mapping from the e- Motions language to rewriting logic theories in Maude. This mechanism allow us to 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.

27 1.3. OUTLINE OF THIS THESIS 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 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, and we show how this automatic model transformation provides a way to give semantics to the behavioral parts of real-time DSMLs, preventing the DSML designer from explicitly defining the behavioral semantics of his/her DSML. Furthermore, we show how these semantic mappings allow us to specify the behavior of real-time DSMLs in a graphical and intuitive way (using the e-motions tool), and perform

28 8 CHAPTER 1. INTRODUCTION 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. encoding of the Ecore metamodel. This appendix presents the Maude Appendix C: Maude Definitions for Time and Action Properties. This appendix presents the algebraic specifications we have developed to support the representation of time and action properties in Maude. Appendix D: Maude Operations for Querying a Simulation. This appendix presents the operations we have defined in Maude to query the result of a timed-simulation, and to present it in a more readable way.

29 Chapter 2 Background This thesis tries, among other things, to bring closer two usually separated worlds: modeling and formal languages. This chapter briefly introduces (parts of) both. 2.1 Model Driven Engineering in a Nutshell This section presents the main principles and technologies of Model Driven Engineering (MDE), an approach that advocates the use of models as first class entities throughout the software 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 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

30 10 CHAPTER 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 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

31 2.1. MODEL DRIVEN ENGINEERING IN A NUTSHELL 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

32 12 CHAPTER 2. BACKGROUND 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) terminó. 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).

33 2.1. MODEL DRIVEN ENGINEERING IN A NUTSHELL 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 application 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).

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

35 2.1. MODEL DRIVEN ENGINEERING IN A NUTSHELL 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.

36 16 CHAPTER 2. BACKGROUND 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) 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] 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 ). The interested reader is referred to TCS s website [7] for more information about the tool.

37 2.1. MODEL DRIVEN ENGINEERING IN A NUTSHELL 17 Figure 2.7: The GMF process to define a visual concrete syntax for a DSML 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

38 18 CHAPTER 2. BACKGROUND 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

39 2.1. MODEL DRIVEN ENGINEERING IN A NUTSHELL 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 specification to refer to the input and output models, respectively. The specific models they refer

40 20 CHAPTER 2. BACKGROUND 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 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

41 2.2. REWRITING LOGIC AND MAUDE 21 with highly nondeterministic concurrent computations. In RL, the state space of a distributed system is specified as an algebraic data type in terms of an equational specification, i.e., RL is parameterized by the choice of its underlying equational logic. The dynamics of a system in RL is then specified by rewrite rules. To be more precise, a RL specification R is a 4- tuple (Σ, E, Φ, R) where (Σ, E) is an equational theory, Φ is the function specifying the frozen arguments of each operator in Σ, 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]. vars M N : Nat. eq s M + s N = s s ( M + N ). endfm Functional modules are required to be terminating and Church-Rosser [27]. Computation in a functional module is accomplished by using equations as simplification rules from left to

42 22 CHAPTER 2. BACKGROUND 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 to NAT s o r t Elt to Nat. i s

43 2.2. REWRITING LOGIC AND MAUDE 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 endm i s p r o t e c t i n g SET{Nat}. vars N M : Nat. r l [ replace ] : N, M => ( N + M ) quo 2. 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].

44 24 CHAPTER 2. BACKGROUND 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 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 a 1 :S 1,..., a n :S n, where C is the name of the class, a i are attribute identifiers, and S i are the sorts of the corresponding attributes. Objects of a class C are then record-like structures of the form < O : C a 1 :v 1,..., a n :v n >, where O is the object identifier, and v i are the current values of its attributes a i. 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

45 2.2. REWRITING LOGIC AND MAUDE 25 safely replace objects of class B). Multiple inheritance is also supported in Maude [42, 41]. For instance, the following Maude module EMPLOYEE 2 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 ) Object-Oriented Modules in (Core) Maude Although object-oriented modules provide convenient syntax for programming object-oriented systems, their semantics can be reduced to that of system modules. We can regard the special syntax reserved for object-oriented modules as syntactic sugar. In fact, each object-oriented module can be translated into a corresponding system module whose semantics is by definition that of the original object-oriented module. This is precisely what Full Maude does to handle object-oriented modules [42, 51]. For instance, each class declaration of the form class C a 1 :S 1,..., a n :S n can be specified in (Core) Maude as a subsort C of sort Cid (class identifier), a constant C of sort C, and declarations of operations a i : : S i -> Attribute for each attribute a i ; 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]

46 26 CHAPTER 2. BACKGROUND 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.

47 2.2. REWRITING LOGIC AND MAUDE 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 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 ] Variables 9 vars R R : Time. 10 vars SYSTEM SYSTEM : System The instantaneous transitions: 12 r l [ reset ] : clock ( 2 4 ) => clock ( 0 ) Tick the whole system: 14 c r l [ tick ] : 15 {SYSTEM} => {delta ( SYSTEM, R ) } in time R 16 i f R <= mte ( SYSTEM ) [ nonexec ] 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 ) Maximum Time Elapse allowed in a system before a clock must be reset: 22 op mte : System > Time [ frozen ( 1 ) ]. 23 eq mte ( clock ( R ) ) = 24 monus R. 24 eq mte ( SYSTEM SYSTEM ) = min ( mte ( SYSTEM ), mte ( SYSTEM ) ). 25 endtm ) Since the state of the system is now a multiset of clocks, time elapse must be specified over every clock. The 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

48 28 CHAPTER 2. BACKGROUND 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. Real- Time 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] 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].

49 2.2. REWRITING LOGIC AND MAUDE 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 c r l [ tick ] : {SYSTEM} => {delta ( SYSTEM, R ) } in time R 5 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 var SYSTEM : System. 3 4 c r l [ tick ] : {SYSTEM} in time T => {delta ( SYSTEM, TE ) } in time ( T plus TE ) 5 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 var SYSTEM : System. 3 4 c r l [ tick ] : {SYSTEM} in time T => {delta ( SYSTEM, TE ) } in time ( T plus TE ) 5 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.

50 30 CHAPTER 2. BACKGROUND 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... ] 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 mod COLLECTION i s 2 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{_} : List{OCL Exp} > Sequence [ ctor ]. 8 op Set{} : > Set. 9 op Bag{} : > Bag. 10 op Sequence{} : > Sequence. 11 op OrderedSet{} : > OrdSet. 12 eq Set{} = Set{mt}. 13 eq Bag{} = Bag{mt}. 14 eq Sequence{} = Sequence{mt ord}.

51 2.2. REWRITING LOGIC AND MAUDE 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> reduce << Sequence{1, 3, 4} > size ( ) >>. 2 3 r e s u l t NzNat : 3

52 32 CHAPTER 2. BACKGROUND

53 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

54 34 CHAPTER 3. DEFINING A DOMAIN SPECIFIC MODELING LANGUAGE 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)

55 3.3. CONCRETE SYNTAX 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 ). Similarly, with textual languages links are required between metamodel elements and the syntactic structures

56 36 CHAPTER 3. DEFINING A DOMAIN SPECIFIC MODELING LANGUAGE of the textual DSML. An example of this approach is TCS (see Section ). 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).

57 3.4. SEMANTICS 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 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

58 38 CHAPTER 3. DEFINING A DOMAIN SPECIFIC MODELING LANGUAGE 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) 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.

59 3.5. DEFINING A DSML (REVISITED) 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

60 40 CHAPTER 3. DEFINING A DOMAIN SPECIFIC MODELING LANGUAGE 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) 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.

61 3.5. DEFINING A DSML (REVISITED) 41 Figure 3.9: Structural View of a DSML for Production Systems 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 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

62 42 CHAPTER 3. DEFINING A DOMAIN SPECIFIC MODELING LANGUAGE 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).

63 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

64 44 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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 ) 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 for classes, a for attributes, a for references, etc. In particular, we have defined The relationships among these sorts can be found in Appendix A, and they correspond 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

65 4.1. MEL REPRESENTATION OF MODELS AND METAMODELS 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 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 @Package 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 3 4 op ProductionSystem : 5 op PS : 6 7 s o r t Plant. 8 s u b s o r t Plant 9 op Plant : > Plant. 10 op els : s o r t PositionedEl. 13 s u b s o r t PositionedEl 14 op PositionedEl : > PositionedEl. 15 op xpos : 16 op ypos : s o r t Machine. 19 s u b s o r t Machine < PositionedEl. 20 op Machine : > Machine. 21 op in : 22 op out : s o r t Assembler. 25 s u b s o r t Assembler < Machine. 26 op Assembler : > Assembler. 27 op counter : s o r t Generator. 30 s u b s o r t Generator < Machine. 31 op Generator : > Generator 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.

66 46 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS s o r t Container. 39 s u b s o r t Container < PositionedEl. 40 op Container : > Container. 41 op parts : s o r t Tray. 44 s u b s o r t Tray < Container. 45 op Tray : > Tray. 46 op capacity : s o r t Conveyor. 49 s u b s o r t Conveyor < Container. 50 op Conveyor : > Conveyor. 51 op out : s o r t User. 54 s u b s o r t User < Container. 55 op User : > User s o r t Part. 58 s u b s o r t Part < PositionedEl. 59 op Part : > Part 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 endm etc. are imported from 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 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-

67 4.1. MEL REPRESENTATION OF MODELS AND METAMODELS 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 ) 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.

68 48 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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 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 of the form mm{obj 1 obj 2... obj N }, where mm is the constant that represent the metamodel, and obj i are the objects that constitute the model. Objects are record-like structures of the form < o : c a 1 :v 1 #...# a n :v n >, where o is the object identifier (of sort Oid), c is the class the object belongs to (a subsort of and a i : v i are attribute-value pairs (of Attributevalue pairs, which represent both (Ecore) attributes and references, are constructed in such a way that attribute names (of 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 : 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 >

69 4.1. MEL REPRESENTATION OF MODELS AND METAMODELS 49 < c1 : Conveyor parts : Sequence{} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{} # out : t1 # xpos : 2 # ypos : 1 > < t1 : Tray parts : Sequence{} # capacity : 4 # xpos : 3 # ypos : 2 > < a : Assembler in : t1 # out : c3 # xpos : 4 # ypos : 2 > < c3 : Conveyor parts : Sequence{} # out : t2 # xpos : 5 # 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 too. The MEL theory that defines their constructors will represent a meta-metamodel, such as the MOF or Ecore metamodel 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 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 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

70 50 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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 becomes also of sort PS@Model if its metamodel is Production- System and the objects that constitute it fulfills all the metamodel properties. This last requirement 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 vars MM 5 vars MODEL 6 vars C C 7 vars O SRC : Oid. 8 vars OBJSET : Set{@Object}. 9 vars SFS SFS : Set{@StructuralFeatureInstance}. 10 vars ATTIS : Set{@AttributeInstance}. 11 vars REFIS : Set{@ReferenceInstance}. 12 var ATT 13 var REF 14 var VALUE : OCL Type. 15 var LO : List{OCL Exp}. 16 vars ATTS REFS : MyList. 17 var SEQ : Sequence op validmodel > Bool. 20 eq validmodel ( MODEL ) = validmodelaux ( MODEL, MODEL ) op > 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 ] op validattributes : > 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 subtypeof ( meta ( VALUE ), type ( ATT ) ) ) 41 and then validattributes ( ATTS, < O : C ATTIS >). 42 eq validattributes ( ATTS, < O : C ATTIS >) = false [ owise ].

71 4.1. MEL REPRESENTATION OF MODELS AND METAMODELS op validreferences > 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 54 validopposites(<< VALUE > assequence ( ) >>, opposite ( REF ), O, MODEL ) ) 55 and then validreferences ( REFS, < O : C REFIS >, MODEL ). 56 eq validreferences ( REFS, < O : C REFIS >, MODEL ) = false [ owise ] op validreftype > Bool. 59 eq validreftype ( Sequence{mt ord}, C, MODEL ) = true. 60 eq validreftype ( Sequence{O # LO}, C, MM { < O : C SFS > OBJSET }) = 61 issubclass ( C, C ) 62 and then validreftype ( Sequence{LO}, C, MM { < O : C SFS > OBJSET }). 63 eq validreftype ( SEQ, C, MODEL ) = false [ owise ] op validopposites : > Bool. 66 eq validopposites ( Sequence{mt ord}, REF, SRC, MODEL ) = true. 67 eq validopposites ( Sequence{O # LO}, REF, SRC, 68 MM { < O : C ( REF : VALUE # SFS ) > OBJSET }) = 69 << VALUE > assequence ( ) > includes ( SRC ) >> 70 and then validopposites ( Sequence{LO}, REF, SRC, 71 MM { < O : C ( REF : VALUE # SFS ) > OBJSET }). 72 eq validopposites ( SEQ, REF, O, MODEL ) = false [ owise ] 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

72 52 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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 by typing: 1 Maude> reduce << 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] 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 ), 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

73 4.2. STRUCTURAL SEMANTIC MAPPINGS 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] 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 inv : s e l f. conds >forall ( c c. ocliskindof ( EquationalCond ) ) -- Equations cannot have rewrite conditions c o n t e x t Equation inv : s e l f. conds >forall ( c c. ocliskindof ( EquationalCond ) ) -- Functional modules cannot have rules c o n t e x t FModule inv : 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 inv : Operation. AllInstances ( ) >exists ( o o. name = s e l f. op and s e l f. type. issubsortof ( o. coarity ) )

74 54 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS Figure 4.1: The Maude metamodel.

75 4.2. STRUCTURAL SEMANTIC MAPPINGS Recursive terms must be declared (by an operation) c o n t e x t RecTerm inv : 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 inv : 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 inv : 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 inv : 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 inv : 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 inv : 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 inv : 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 ( )

76 56 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS c o n t e x t Kind : : issubsortof ( st : Type ) : Boolean body : ( s e l f = st ) c o n t e x t Sort : : issubsortof ( st : Type ) : Boolean 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 ( ) The Maude Code Generator We have developed a set of model-to-text transformations, using TCS (see Section ), that allow Maude models to be serialized into the corresponding Maude code. The following is a fragment of these transformations: 1 template FModule : 2 "fmod" name 3 ( i s D e f i n e d ( params )? "{" params{ s e p a r a t o r = ",", autocreate = never} "}" ) "is" 4 ( i s D e f i n e d ( els )? [ els{ s e p a r a t o r = "."} "." ] ) 5 "endfm" ; 6 7 template Sort : 8 "sort" name ; 9 10 template SubsortRel : 11 "subsorts" subsorts{ r e f e r s T o = name} "<" supersorts{ r e f e r s T o = name ) ; template Operation : 14 "op" name ":" arity{ r e f e r s T o = name} "->" coarity{ refersto = name} 15 ( i s D e f i n e d ( atts )? "[" atts "]" ) ; 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

77 4.2. STRUCTURAL SEMANTIC MAPPINGS 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] 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 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] 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 Encoding EMF Metamodels EMF supports the specification of metamodels through the Ecore language (see Section ). The Ecore language is provided with different graphical editors to define metamodels. No mat-

78 58 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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]: hel pe r def : mspec : Maude! Sort = OclUndefined ; hel pe r def : smodule : Maude! SModule = OclUndefined ; hel pe r def : smoduleecore : Maude! SModule = OclUndefined ; hel pe r def : sortclass : Maude! Sort = OclUndefined ; hel pe r def : sortpack : Maude! Sort = OclUndefined ;... entrypoint r u l e Initialize ( ) { to mspec : Maude! MaudeSpec ( els < Sequence {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 ), sortclass : Maude! Sort ( name module < smoduleecore ), sortpack : Maude! Sort ( name module < smoduleecore ),... do{ thismodule. mspec < mspec ; thismodule. smodule < smodule ; thismodule. smoduleecore < smoduleecore ; thismodule. sortclass < sortclass ; thismodule. sortpack < sortpack ;... } }

79 4.2. STRUCTURAL SEMANTIC MAPPINGS 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), module imported by every metamodel specification, and several predefined Maude sorts, such (sortclass) (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{ 2 from 3 class : Ecore! EClass 4 to 5 sort : Maude! Sort ( 6 name < class. maudename ( ), 7 module < thismodule. smodule ), 8 ssort : Maude! SubsortRel ( 9 module < thismodule. smodule, 10 supersorts < if class. esupertypes. isempty ( ) 11 then thismodule. sortclass 12 else class. esupertypes endif 13 subsorts < Set{sort}), 14 cte : Maude! Operation ( 15 name < class. maudename ( ), 16 module < thismodule. smodule, 17 coarity < sort ) 18 do{ 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 } 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

80 60 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS it will be a subsort of the predefined 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 ( module < thismodule. smodule, 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

81 4.2. STRUCTURAL SEMANTIC MAPPINGS 61 its name. The normalizedname helper adds double quotes to the string constant and replaces special characters used in our Maude infrastructure 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:

82 62 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 1 h e l p e r def : objectoperator : S t r i n g = <_:_ _> ; 2 h e l p e r def : setoperator : S t r i n g = _,_ ; 3 hel pe r def : objectsort : Maude! Sort = OclUndefined ; 4 hel pe r def : objset : Maude! RecTerm = OclUndefined ; 5 hel pe r def : sfisetsort : Maude! Sort = OclUndefined ; 6 hel pe r context OclAny def : atts ( ) : Sequence ( Ecore! EAttribute ) = 7 self. eclass ( ). eallattributes ; 8 hel pe r context OclAny def : refs ( ) : Sequence ( Ecore! EReference ) = 9 self. eclass ( ). eallreferences ; entrypoint r u l e Initialize ( ) { 13 to objset : Maude! RecTerm ( 16 op < thismodule. objsetoperator, 17 type < objectsetsort,... ), 18 objectsort : Maude! Sort ( 19 name 20 module < auxiliarymodule ), 21 sfisetsort : Maude! Sort ( 22 name < Set{@StructuralFeatureInstance}, 23 module < auxiliarymodule ), do{ 26 thismodule. objset < objset ; 27 thismodule. objectsort < objectsort ; 28 thismodule. sfisetsort < sfisetsort ; } 31 } r u l e Object{ 34 from 35 o : Ecore! EObject 36 to 37 obj : Maude! RecTerm ( 38 op < thismodule. objectoperator, 39 type < thismodule. objectsort, 40 args < Sequence {thismodule. MaudeOid ( o ),class, sfs}), 41 class : Maude! Constant ( 42 op < o. eclass ( ). maudeclassifiername ( ), 43 type < thismodule. MaudeClassSort ( o. eclass ( ) ) ), 44 sfs : Maude! RecTerm ( 45 op < thismodule. setoperator, 46 type < thismodule. sfisetsort, 47 args < o. atts ( ) >collect ( a thismodule. MaudeAttributeInstance ( o, a ) ) 48 >union ( o. refs ( ) >collect ( r thismodule. MaudeReferenceInstance ( o, r ) ) ) 49 >union ( Sequence {emptysfs1, emptysfs2}) ), 50 emptysfs1 : Maude! Constant ( 51 op < thismodule. emptysetoperator,

83 4.3. RELATED WORK type < thismodule. sfisetsort ), 53 emptysfs2 : Maude! Constant ( 54 op < thismodule. emptysetoperator, 55 type < thismodule. sfisetsort ) 56 do{ 57 thismodule. objset. args < thismodule. objset. args >append ( obj ) ; 58 } 59 } 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 whose arguments are its identifier, its class, and its structural featurevalue 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

84 64 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS 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

85 4.3. RELATED WORK 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-Álvarez and Fernández-Alemá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.

86 66 CHAPTER 4. STRUCTURAL SEMANTICS OF DSMLS

87 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

88 68 CHAPTER 5. MODEL MANAGEMENT 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 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 Jézé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.

89 5.1. MODEL SUBTYPING 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)

90 70 CHAPTER 5. MODEL MANAGEMENT ((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 ). Let us illustrate the above definition with an example. We will retake the ATL transformation presented in Section , 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

91 5.1. MODEL SUBTYPING 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 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-

92 72 CHAPTER 5. MODEL MANAGEMENT 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 Jézé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) 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: vars M M var RENTYPE : String. op > Bool. eq isstrictsubtypeof ( M, M ) = arepackagessubtypeof ( allpackages ( M ), allpackages ( M ), "Equal", M, M ). op String > Bool. eq isrensubtypeof ( M, M, RENTYPE ) = arepackagessubtypeof ( allpackages ( M ), allpackages ( M ), RENTYPE, M, M ). op > Bool.

93 5.1. MODEL SUBTYPING 73 eq isflatsubtypeof ( M, M ) = areclassifierssubtypeof ( allclassifiers ( M ), allclassifiers ( M ), "Equal", M, M ). op 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. vars MM MM vars PACKS PACKS : Set. vars CLASSFS CLASSFS : OrderedSet. vars LPACKS LPACKS : MSet{OCL Exp}. vars N N STRCOMP : String. vars P P : Oid. vars SFS SFS : Set{@StructuralFeatureInstance}. vars OBJSET OBJSET : Set{@Object}. op arepackagessubtypeof : Set > Bool. eq arepackagessubtypeof ( PACKS, Set{mt}, STRCOMP, M, M ) = true. ceq arepackagessubtypeof ( Set{P ; LPACKS }, Set{P ; LPACKS}, STRCOMP, MM { < P : EPackage name : N # eclassifiers : CLASSFS # SFS > OBJSET }, MM { < P : EPackage name : N # eclassifiers : CLASSFS # SFS > OBJSET }) = true i f 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

94 74 CHAPTER 5. MODEL MANAGEMENT term isstrictsubtypeof(m, M), where both M and M are expressed as terms. Maude> reduce 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 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

95 5.2. MODEL DIFFERENCE 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: i s p r o t e c t i n : op Difference : s o r t DiffElement. s u b s o r t DiffElement op DiffElement : > DiffElement. op element : 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.

96 76 CHAPTER 5. MODEL MANAGEMENT op DeletedElement : > DeletedElement. s o r t ModifiedElement. s u b s o r t ModifiedElement < DiffElement. op ModifiedElement : > ModifiedElement. op oldelement : --- METAMODEL PROPERTIES --- Equations for the "@Diference@" metamodel : eq name ) = "Difference". eq packages ) = 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 module (see Appendix B) The Difference Operation Given a minuend model M m and a subtrahend model M s, both conforming to some metamodels (not necessary the same), the result of applying the model difference operation to them is another model M d conforming to the Difference Metamodel presented above, in such a way that modeldiff(m m,m s ) = M d. 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

97 5.2. MODEL DIFFERENCE 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 Matching Elements Matching two models M 1 and M 2 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 M 1 and M 2 is a match model M M 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 identifiers, 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: vars MM MM vars OBJSET OBJSET : Set{@Object}. vars O O : Oid. vars C C vars SFS SFS : Set{@StructuralFeatureInstance}. op eq idmatch ( MM { OBJSET }, MM { OBJSET }) { idmatch ( OBJSET, OBJSET ) }. op idmatch : Set{@Object} Set{@Object} > Set{@Object}. eq idmatch(< O : C SFS > OBJSET, < O : C SFS > OBJSET )

98 78 CHAPTER 5. MODEL MANAGEMENT = < O : Match leftel : O # rightel : O # rate : 1. 0 ) > idmatch ( OBJSET, OBJSET ). eq idmatch ( OBJSET, OBJSET ) = none [ owise ]. For every object of M 1 with the same identifier as another object of M 2, 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

99 5.2. MODEL DIFFERENCE 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 C 1 = C 2 classrate(c 1, C 2 ) = 0.9 if issubtype(c 1, C 2 ) or issubtype(c 2, C 1 ) 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(s 1, S 2 ) = if levenshteindist(s 1, S 2 ) = 1 namerate(s 1, S 2 ) = 0.5 if levenshteindist(s 1, S 2 ) = if levenshteindist(s 1, S 2 ) = otherwise Numerical attribute values match rate is computed with a relative distance function (1 N 1 N 2 N 1 +N 2 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:

100 80 CHAPTER 5. MODEL MANAGEMENT finalrate = w c classrate + w sf sfrate where finalrate, classrate, sfrate [0..1], and the weights that we have initially considered are w c = 0.66, w sf = 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 w sf (and w sf 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 = 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 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:

101 5.2. MODEL DIFFERENCE 81 vars M1 M2 vars MM1 MM2 vars OBJSET1 OBJSET2 : Set{@Object}. op --- Using Structural matching algorithm eq difference ( M1, M2 ) = difference ( M1, M2, match ( M1, M2 ) ). op --- Using Identifier matching eq iddifference ( M1, M2 ) = difference ( M1, M2, idmatch ( M1, M2 ) ). op @Model eq difference ( MM1 { OBJSET1 }, MM2 { OBJSET2 }, MATCHM ) { difference ( OBJSET1, OBJSET2, MATCHM ) }. op difference : Set{@Object} > 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: vars M MATCHM vars OBJSET OBJSET1 OBJSET2 : Set{@Object}. vars O O1 O2 : Oid. vars C C1 C2 vars 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 > Bool. eq match ( O1, { < O : Match leftel : O1 # rightel : O2 # SFS > OBJSET } ) = true. eq match ( O1, O2, M ) = false [ owise ].

102 82 CHAPTER 5. MODEL MANAGEMENT In the second case, two objects represent the same element, but the element has been modified, 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 Modified- Element 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 ].

103 5.2. MODEL DIFFERENCE 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 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 > < c2 : Conveyor parts : Sequence{}, out : t1, xpos : 2, ypos : 1 > < t1 : Tray parts : Sequence{}, capacity : 4, xpos : 3, ypos : 2 > < a : Assembler in : t1, out : c3, xpos : 4, ypos : 2 > < c3 : Conveyor parts : Sequence{}, out : t2, xpos : 5, 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 > }.

104 84 CHAPTER 5. MODEL MANAGEMENT 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) 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] The do Operation Given a model M s conforming to an arbitrary metamodel MM and a difference model M d (conforming to the Difference Metamodel), the result of applying operation do to them is another model M m so that: do(m s,m d ) = M m and modeldiff(m m,m s ) = M d. 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

105 5.2. MODEL DIFFERENCE 85 is also included to deal with the empty difference: 1 vars MM1 MM2 2 vars OBJSET1 OBJSET2 : Set{@Object}. 3 vars O1 O2 OLDO NEWO : Oid. 4 vars C1 NEWC OLDC 5 vars SFS1 OLDSFS NEWSFS : Set{@StructuralFeatureInstance}. 6 7 op 8 eq do ( MM1 { OBJSET1 }, MM2 { OBJSET2 }) = othermm ( MM1, OBJSET2 ) { do ( OBJSET1, OBJSET2 ) } op do : Set{@Object} Set{@Object} > Set{@Object}. 11 eq do ( OBJSET1, < O2 : AddedElement element : NEWO > 12 < NEWO : NEWC NEWSFS > OBJSET2 ) 13 = < originalid ( NEWO ) : NEWC NEWSFS > 14 do ( OBJSET1, OBJSET2 ). 15 ceq do(< O1 : C1 SFS1 > OBJSET1, < O2 : DeletedElement element : OLDO > 16 < OLDO : OLDC OLDSFS > OBJSET2 ) 17 = do ( OBJSET1, OBJSET2 ) 18 i f O1 = originalid ( OLDO ). 19 ceq do(< O1 : C1 SFS1 > OBJSET1, < O2 : ModifiedElement element : NEWO # 20 oldelement : OLDO > 21 < NEWO : NEWC NEWSFS > 22 < OLDO : OLDC OLDSFS > OBJSET2 ) 23 = < originalid ( NEWO ) : NEWC ( excludingall ( SFS1, OLDSFS ), NEWSFS ) > 24 do ( OBJSET1, OBJSET2 ) 25 i f O1 = originalid ( OLDO ). 26 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 (M s and M d ) 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 M m will usually conform to the same metamodel MM of M s. 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-

106 86 CHAPTER 5. MODEL MANAGEMENT models that are related by the sybtyping relationship. Therefore, we could usually affirm that the resulting model M m will conform to a metamodel which is a subtype [116] (or, in special cases, supertype) of the metamodel MM of the original subtrahend M m The undo Operation Given a model M m conforming to a metamodel MM and a difference model M d (conforming to the Difference Metamodel), the result of applying operation undo to them is another model M m so that: undo(m m,m d ) = M s and modeldiff(m m,m s ) = M d. As well as in operation do, the resulting model M s will usually conform to the same metamodel MM of M m (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 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

107 5.3. FURTHER OPERATIONS 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 eq diffcomposition { OBJSET1 { OBJSET2 }) { 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 > < OLDO : OLDC OLDSFS > OBJSET2 ) = 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.

108 88 CHAPTER 5. MODEL MANAGEMENT For instance, the number of classes (EClasses) of an Ecore model coincides with the number 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 > Nat. eq NoOfClasses { < O : EClass SFS > OBJSET }) = 1 + NoOfClasses { OBJSET }). eq NoOfClasses { 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.

109 5.4. TOOL SUPPORT WITH MAUDELING 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 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 into a Maude model (see Section ). This Maude model, which will conform to the Maude metamodel, will also contain the specification of 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 term conforms to. Thus, we cannot achieve this process with a simple transformation: we need a Higher-Order Transfor- 1 Maudeling uses our previous Maude representation for models and metamodels, which is described in [106].

110 90 CHAPTER 5. MODEL MANAGEMENT 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 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 uses Maude2ModelLib ; 5 6 r u l e Author : : Book { 7 from 8 rt : Maude! RecTerm 9 ( rt. op = thismodule. objectoperator and rt. istypeof ) 10 and rt. belongsto ( Book@Author ) ) 11 to 12 cl : Author! Book ( 13 name < rt. getattvalue ( name ). atttostring ( ), 14 ISBN < rt. getattvalue ( ISBN ). atttostring ( ) ) 15 } r u l e Author : : Author { 18 from 19 rt : Maude! RecTerm

111 5.4. TOOL SUPPORT WITH MAUDELING ( rt. op = thismodule. objectoperator and rt. istypeof ) 21 and rt. belongsto ( Author@Author ) ) 22 using { 23 books : OrderedSet ( Maude! Constant ) = rt. getattvalue ( books ). toordset ( ) ; } 24 to 25 cl : Author! Author ( 26 name < rt. getattvalue ( name ). atttostring ( ), 27 surname < rt. getattvalue ( surname ). atttostring ( ), 28 books < Maude! RecTerm >allinstances ( ) >select ( rt rt. istypeof ) ) > 29 select ( obj books >exists ( oid oid. op = obj. oid ( ). op ) ) ) 30 } 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 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

112 92 CHAPTER 5. MODEL MANAGEMENT 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 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-

113 5.4. TOOL SUPPORT WITH MAUDELING 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 ; uses Maude2ModelLib ;... r u l e Difference : : ModifiedElement { from rt : Maude! RecTerm ( rt. op = thismodule. object and rt. istypeof ) 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 : Maude! RecTerm ( rt. op = thismodule. object and rt. istypeof ) and rt. belongsto ( DeletedElement@Difference ) ) using { oid_element : S t r i n g = rt. listvariable ( element ) >first ( ). originaloid ( ) ; } to cl : Difference! DeletedElement ( ) do{ cl. refsetvalue ( element, Ecore1! EObject. getinstancebyid ( SUB, oid_element ) ) ; } } r u l e Difference : : AddedElement { from rt : Maude! RecTerm ( rt. op = thismodule. object and rt. istypeof ) and rt. belongsto ( AddedElement@Difference ) ) using { oid_element : S t r i n g = rt. listvariable ( element ) >first ( ). originaloid ( ) ; } to

114 94 CHAPTER 5. MODEL MANAGEMENT } 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

115 5.5. RELATED WORK 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 Jézé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

116 96 CHAPTER 5. MODEL MANAGEMENT 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.

117 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 sys- 97

118 98 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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 PRO- DUCTION-SYSTEM module (see Section 4.1.1) with five rules: mod PRODUCTION SYSTEM WITH BEHAVIOR p r o t e c t i n g PRODUCTION SYSTEM. i s vars U P C T HEG HAG HA HE HAM A PL : Oid. vars PARTS PARTS : Sequence. vars SFS SFS SFS SFS SFS : Set{@StructuralFeatureInstance}. var OBJSET : Set{@Object}. vars 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 > < P : PART xpos : XPOS # ypos : YPOS # SFS > OBJSET }

119 6.1. REPRESENTING DSMLS BEHAVIOR WITH MAUDE 99 => ProductionSystem{ < C : Conveyor parts : << PARTS > excluding ( P ) >> # out : T # SFS > < T : Tray capacity : CAP # parts : << PARTS > append ( P ) >> # xpos : XPOS # ypos : YPOS # SFS > < P : PART 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 > < U : User 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 > < U : User parts : << PARTS > 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

120 100 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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. vars C T P PL : Oid. var OBJSET : Set{@Object}. vars SFS SFS SFS SFS : Set{@StructuralFeatureInstance}. vars PARTS ELS : Sequence. var CAP : Int. var PART : Part.

121 6.1. REPRESENTING DSMLS BEHAVIOR WITH MAUDE 101 c r l [ Drop ] : ProductionSystem { < C : Conveyor parts : PARTS # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # SFS > < P : PART SFS > < PL : Plant els : ELS # SFS > OBJSET } => ProductionSystem{ < C : Conveyor parts : << PARTS > excluding ( P ) >> # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # SFS > < P : PART SFS > < 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. vars C T P : Oid. var OBJSET : Set{@Object}. vars SFS SFS SFS : Set{@StructuralFeatureInstance}. vars PARTS : Sequence. var CAP : Int. var PART : Part. c r l [ Remove ] : ProductionSystem { < C : Conveyor parts : PARTS # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # SFS > < P : PART SFS > OBJSET } => ProductionSystem{ < C : Conveyor parts : << PARTS > excluding ( P ) >> # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # SFS > OBJSET } i f << PARTS > first ( ). =. P >> / \ << PARTS > size ( ) >= CAP >>. endm

122 102 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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 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.

123 6.2. FORMAL ANALYSIS OF DOMAIN SPECIFIC MODELS WITH MAUDE 103 metareduce, metaapply, etc., which provide absolute control over the execution process (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 using 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 using ( 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 : 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 > < hag : HandleGen in : null # out : c2 # counter : 0 # xpos : 1 # ypos : 1 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 >

124 104 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < t1 : Tray parts : Sequence{mt ord} # capacity : 4 # xpos : 3 # ypos : 2 > < a : Assembler in : t1 # out : c3 # xpos : 4 # ypos : 2 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < t2 : Tray parts : Sequence{mt ord} # capacity : 4 # xpos : 6 # 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 > < he2. ha2 : Hammer xpos : 6 # ypos : 3 >... < he10. ha10 : 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 using ( ( 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 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:

125 6.2. FORMAL ANALYSIS OF DOMAIN SPECIFIC MODELS WITH MAUDE 105 Maude> search [ 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> search [ 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 182) OBJSET > < p : Plant els : Sequence{ heg # hag # c1 # c2 # t1 # a # c3 # t2 # u} > < heg : HeadGen in : null, out : c1 # counter : 6 # xpos : 1 # ypos : 3 > < hag : HandleGen in : null # out : c2 # counter : 10 # xpos : 1 # ypos : 1 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < a : Assembler in : t1 # out : c3 # xpos : 4 # ypos : 2 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < t2 : Tray parts : Sequence{mt ord} # capacity : 4 # xpos : 6 # ypos : 2 > < 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.

126 106 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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 (shortest) 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> search [ 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 ) OBJSET > < p : Plant els : Sequence{ heg # hag # c1 # c2 # t1 # a # c3 # t2 # u} > < heg : HeadGen in : null, out : c1 # counter : 4 # xpos : 1 # ypos : 3 > < hag : HandleGen in : null # out : c2 # counter : 4 # xpos : 1 # ypos : 1 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < t1 : Tray parts : Sequence{mt ord} # capacity : 4 # xpos : 3 # ypos : 2 > < a : Assembler in : t1 # out : c3 # xpos : 4 # ypos : 2 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < t2 : Tray parts : Sequence{mt ord} # capacity : 4 # xpos : 6 # ypos : 2 > < he1. ha1 : Hammer xpos : 6 # ypos : 3> < he2. ha2 : Hammer xpos : 6 # ypos : 3> < he3. ha3 : Hammer xpos : 6 # ypos : 3> SFS > xpos : 6 # ypos : 3 PARTS > Sequence{ he1. ha1 # he2. ha2 # he3. ha3}

127 6.2. FORMAL ANALYSIS OF DOMAIN SPECIFIC MODELS WITH MAUDE 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> search 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> search [ 1, ] 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: vars P P C T : Oid. vars PARTS PARTS : Sequence. vars SFS SFS SFS SFS : Set{@StructuralFeatureInstance}. var OBJSET : Set{@Object}. vars CAP XPOS XPOS YPOS YPOS : Int. var PART PART : Part. c r l [ Transfer1 ] : ProductionSystem {

128 108 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS < C : Conveyor parts : PARTS # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # xpos : XPOS # ypos : YPOS # SFS > < P : PART xpos : XPOS # ypos : YPOS # SFS > OBJSET } => ProductionSystem{ < C : Conveyor parts : << PARTS > excluding ( P ) >> # out : T # SFS > < T : Tray capacity : CAP # parts : << PARTS > append ( P ) >> # xpos : XPOS # ypos : YPOS # SFS > < P : PART xpos : XPOS # ypos : YPOS # SFS > OBJSET } i f << PARTS > first ( ). =. P >> / \ << PARTS > isempty ( ) >>. c r l [ Transfer2 ] : ProductionSystem { < C : Conveyor parts : PARTS # out : T # SFS > < T : Tray capacity : CAP # parts : PARTS # xpos : XPOS # ypos : YPOS # SFS > < P : PART xpos : XPOS # ypos : YPOS # SFS > < P : PART SFS > OBJSET } => ProductionSystem{ < C : Conveyor parts : << PARTS > excluding ( P ) >> # out : T # SFS > < T : Tray capacity : CAP # parts : << PARTS > append ( P ) >> # xpos : XPOS # ypos : YPOS # SFS > < P : PART xpos : XPOS # ypos : YPOS # SFS > < P : PART SFS > 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 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.

129 6.2. FORMAL ANALYSIS OF DOMAIN SPECIFIC MODELS WITH MAUDE 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. vars O P : Oid. vars SFS SFS : Set{@StructuralFeatureInstance}. var OBJSET : Set{@Object}. var PART : Part. var PARTS : Sequence. eq ProductionSystem { < O : PART SFS > OBJSET } = exist ( O ) = true. ceq ProductionSystem { < O : User parts : PARTS # SFS > < P : PART 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 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> reduce modelcheck ( psmodel, [ ] ( exist ( he10. ha10 ) > <> collected ( he10. ha10 ) ) ). r e s u l t Bool : true 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

130 110 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS formula allhammers express the same property for all possible hammers, with identifiers created as in the above rules: vars 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 ) = [ ] ( exist ( ID ) > <> collected ( ID ) ) / \ allhammers ( N, M, K ) i f ID := hammerid ( headid ( N ), handleid ( s M ) ). eq allhammers ( 0, 0, K ) = [ ] ( exist ( ID ) > <> collected ( ID ) ) i f ID := hammerid ( headid ( 0 ), handleid ( 0 ) ). We can now check it as follows: Maude> reduce modelcheck ( psmodel, allhammers ( 1 0, 1 0 ) ). r e s u l t Bool : true 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> reduce 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 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # 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 > < p : Plant els : Sequence{ heg # hag # c1 # c2 # t1 # a # c3 # t2 # u} > < t1 : Tray parts : Sequence{mt ord} # xpos : 3 # ypos : 2 # capacity : 4 > < t2 : Tray parts : Sequence{mt ord} # xpos : 6 # ypos : 2 # capacity : 4 > < u : User parts : Sequence{mt ord} # xpos : 6 # ypos : 3 >}, GenHead} { ProductionSystem { < a : Assembler out : c3 # in : t1 # xpos : 4 # ypos : 2 > < c1 : Conveyor parts : Sequence{ he10} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < hag : HandleGen out : c2 # in : null # xpos : 1 # ypos : 1 # counter : 10 > < he10 : Head xpos : 2 # ypos : 3 >

131 6.2. FORMAL ANALYSIS OF DOMAIN SPECIFIC MODELS WITH MAUDE 111 < heg : HeadGen out : c1 # in : null # xpos : 1 # ypos : 3 # counter : 9 > < p : Plant els : Sequence{ heg # hag # c1 # c2 # t1 # a # c3 # t2 # u} > < t1 : Tray parts : Sequence{mt ord} # xpos : 3 # ypos : 2 # capacity : 4 > < t2 : Tray parts : Sequence{mt ord} # xpos : 6 # ypos : 2 # capacity : 4 > < u : User parts : Sequence{mt ord} # xpos : 6 # ypos : 3 >}, GenHead}... { ProductionSystem { < a : Assembler out : c3 # in : t1 # xpos : 4 # ypos : 2 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{ ha1} # out : t1 # xpos : 2 # ypos : 1 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < ha1 : Handle xpos : 2 # ypos : 1 > < ha10 : Handle xpos : 2 # ypos : 1 > < ha2 : Handle xpos : 2 # ypos : 1 > < ha3 : Handle xpos : 2 # ypos : 1 > < ha4 : Handle xpos : 2 # ypos : 1 > < ha5 : Handle xpos : 2 # ypos : 1 > < ha6 : Handle xpos : 2 # ypos : 1 > < ha7 : Handle xpos : 2 # ypos : 1 > < ha8 : Handle xpos : 2 # ypos : 1 > < ha9 : Handle xpos : 2 # ypos : 1 > < hag : HandleGen out : c2 # in : null # xpos : 1 # ypos : 1 # counter : 0 > < 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 > < heg : HeadGen out : c1 # in : null # xpos : 1 # ypos : 3 # counter : 0 > < 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 > < t2 : Tray parts : Sequence{mt ord} # xpos : 6 # ypos : 2 # capacity : 4 > < u : User parts : Sequence{mt ord} # xpos : 6 # ypos : 3 >}, Drop}, { ProductionSystem { < a : Assembler out : c3 # in : t1 # xpos : 4 # ypos : 2 > < c1 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 3 > < c2 : Conveyor parts : Sequence{mt ord} # out : t1 # xpos : 2 # ypos : 1 > < c3 : Conveyor parts : Sequence{mt ord} # out : t2 # xpos : 5 # ypos : 2 > < ha1 : Handle xpos : 2 # ypos : 1 > < ha10 : Handle xpos : 2 # ypos : 1 > < ha2 : Handle xpos : 2 # ypos : 1 > < ha3 : Handle xpos : 2 # ypos : 1 >

132 112 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS < ha4 : Handle xpos : 2 # ypos : 1 > < ha5 : Handle xpos : 2 # ypos : 1 > < ha6 : Handle xpos : 2 # ypos : 1 > < ha7 : Handle xpos : 2 # ypos : 1 > < ha8 : Handle xpos : 2 # ypos : 1 > < ha9 : Handle xpos : 2 # ypos : 1 > < hag : HandleGen out : c2 # in : null # xpos : 1 # ypos : 1 # counter : 0 > < 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 > < heg : HeadGen out : c1 # in : null # xpos : 1 # ypos : 3 # counter : 0 > < 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 > < t2 : Tray parts : Sequence{mt ord} # xpos : 6 # ypos : 2 # capacity : 4 > < u : User parts : Sequence{mt ord} # xpos : 6 # ypos : 3 >}, 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

133 6.3. REPRESENTING DSML S BEHAVIOR WITH IN-PLACE MODEL TRANSFORMATION113 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 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 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

134 114 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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

135 6.3. REPRESENTING DSML S BEHAVIOR WITH IN-PLACE MODEL TRANSFORMATION115 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 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

136 116 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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

137 6.4. BEHAVIORAL SEMANTIC MAPPINGS AND TOOL SUPPORT 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 AToM 3 [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. AToM 3 is a tool for multi-paradigm modeling based on graph grammars [111]. With AToM 3, 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 AToM 3 tool. Thus, AToM 3 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 AToM 3 tool in terms of the origi-

138 118 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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 AToM 3 tool. Figure 6.4 shows the state of the AToM 3 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 AToM 3 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

139 6.5. RELATED WORK 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

140 120 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS 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

141 6.5. RELATED WORK 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.

142 122 CHAPTER 6. BEHAVIORAL SEMANTICS OF DSMLS

143 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

144 124 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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

145 7.2. THE e-motions LANGUAGE 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-

146 126 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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

147 7.2. THE e-motions LANGUAGE 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).

148 128 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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 define atomic rules as in-place transformation rules of the form l : [NAC] LHS [t,t ] 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.

149 7.2. THE e-motions LANGUAGE 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.

150 130 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS Rule execution modes. We distinguish normal rules, which are triggered as soon as possible, 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

151 7.2. THE e-motions LANGUAGE 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.

152 132 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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

153 7.2. THE e-motions LANGUAGE 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: ongoing 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

154 134 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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) 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.

155 7.2. THE e-motions LANGUAGE 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

156 136 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS completed 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

157 7.2. THE e-motions LANGUAGE 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 p2 3 ) 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 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.

158 138 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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.

159 7.2. THE e-motions LANGUAGE 139 Figure 7.15: The InitialModel instantaneous rule 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

160 140 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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

161 7.2. THE e-motions LANGUAGE 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 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.

162 142 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS (past or present) action occurrences, and (b) interrupting actions in the way we have described in this section 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.

163 7.2. THE e-motions LANGUAGE 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 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

164 144 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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].

165 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 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 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 ). 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

166 146 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 ). 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 vars 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: vars MODEL MODEL@ vars MM MM@ vars OBJSET OBJSET@ : Set{@Object}. var C var REF vars O O O OR p1 p2 cl c1 c2 a CLK@ ACTEXC@ OR1@ OR2@ OR3@ OR4@ VAR1@ : Oid. vars SFS SFS SFS p@sfs p1@sfs p2@sfs ACTEXEC@SFS a@sfs : Set{@StructuralFeatureInstance}. vars PHONE@p1@CLASS PHONE@p2@CLASS PHONE@p@CLASS : Phone. var ANTENNA@a@CLASS : Antenna. vars ON@p@ATT ON@p1@ATT ON@p2@ATT BATTERY@p@ATT DIALEDCALLS@p1@ATT RECEIVEDCALLS@p2@ATT CONTACTS@p1@ATT : OCL Type. vars OIDSET@ SET SET : Set. vars T T T T TE TIME@CLK@ MINDURATION@ MAXDURATION@ : Time. vars VALUE@ids@ VALUE@rdm@ : Nat. 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;

167 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 147 however, these qualifications will be omitted here to improve readability 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 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 AtomicAction- Exec 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): vars 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 } => MM@ { --- LHS elements

168 148 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS < 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@ > --- 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" > < OR2@ : ObjectRole actualobject : p2 # role : "p2" > < VAR1@ : Variable name : "inittime" # value : inittime > --- Further elements < ids@ : Counter value : ( VALUE@ids@ + 4) > < rdm@ : Counter value : VALUE@rdm@ > OBJSET@ } i f MODEL@ : = MM@ { < 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@ > < ids@ : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > 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) / \ OR2@ : = newid ( VALUE@ids@ + 2) / \ 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

169 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 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(var 1 val 1,..., var N val N ), 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 another 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 : > Bool. eq currentexec@call ( Set{p1 ; p2}, MM@ { < ACTEXEC@ : AtomicActionExec action : "Call" # endingtime : null # participants : Set{OR1@ ; OR2@ ; L@TIMER@} # ACTEXEC@SFS > < OR1@ : ObjectRole actualobject : p1 # role : "p1" > < OR2@ : ObjectRole actualobject : p2 # role : "p2" > 5 The ids@ and rdm@ counters are always included in the rule, no matter if they are used or not.

170 150 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS }) = 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}. vars OR1@a : Oid. vars OR1@a@SFS : Set{@StructuralFeatureInstance}. op p1isnotinacall@call : Set > 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 > --- Further elements 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

171 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 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 vars L L : MSet{OCL Exp}. 2 vars LO LO : List{OCL Exp}. 3 4 op dpo : Set > Bool. 5 eq dpo ( SET, MLL, MODEL ) = dpo ( union ( SET, getallcontainedoids ( SET, MODEL ) ), 6 deleteels ( SET, deletelinks ( MLL, MODEL ) ) ). 7 8 op dpo : > Bool. 9 eq dpo ( Set{mt}, MODEL ) = true 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 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 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 ] : MM@ { --- LHS elements < p1 : PHONE@p1@CLASS contacts : CONTACTS@p1@ATT # dialedcalls : DIALEDCALLS@p1@ATT # p1@sfs > < p2 : PHONE@p2@CLASS receivedcalls : RECEIVEDCALLS@p2@ATT # p2@sfs > < cl : Clock time : TIME@CLK@ > --- Action execution with minimum timer consumed < ACTEXEC@ : AtomicActionExec action : "Call" # participants : Set{OR1@ ; OR2@} #

172 152 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS mintimer : 0 # status : unfinished # endingtime : null # executiontime : T # variables : Set{VAR1@} # ACTEXC@@SFS > < OR1@ : ObjectRole actualobject : p1 # role : "p1" > < OR2@ : ObjectRole actualobject : p2 # role : "p2" > < VAR1 : Variable name : "inittime" # value : inittime > --- Further elements < ids@ : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > 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@ ) >) < cl : Clock time : TIME@CLK@ > --- 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 > < OR1@ : ObjectRole actualobject : p1 # role : "p1" > < OR2@ : ObjectRole actualobject : p2 # role : "p2" > < OR3@ : ObjectRole actualobject : c1 # role : "c1" > < OR4@ : ObjectRole actualobject : c2 # role : "c2" > < VAR1 : Variable name : "inittime" # value : inittime > --- Further elements < ids@ : Counter value : ( VALUE@ids@ + 4) > < rdm@ : Counter value : VALUE@rdm@ > OBJSET@ } i f MODEL@ := MM@ {... OBJSET } / \ OR3@ : = newid ( VALUE@ids@ + 0) / \ OR4@ : = newid ( VALUE@ids@ + 1) / \ 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

173 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 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 aborting 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 ) 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 c r l [ Coverage@Triggering ] : 2 MM@ { --- LHS elements 3 < p : PHONE@p@CLASS p@sfs # on : ON@p@ATT > 4 < a : ANTENNA@a@CLASS a@sfs > Further elements 6 < CLK@ : Clock time : TIME@CLK@ > 7 < ids@ : Counter value : VALUE@ids@ > 8 < rdm@ : Counter value : VALUE@rdm@ > 9 OBJSET@ } 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.

174 154 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 11 < p : PHONE@p@CLASS p@sfs # on : ON@p@ATT > 12 < a : ANTENNA@a@CLASS a@sfs > Action execution 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 < OR1@ : ObjectRole actualobject : p # role : "p" > 19 < OR2@ : ObjectRole actualobject : a # role : "a" > Further elements 21 < CLK@ : Clock time : TIME@CLK@ > 22 < ids@ : Counter value : ( VALUE@ids@ + 3) > 23 < rdm@ : Counter value : VALUE@rdm@ > 24 OBJSET@ } 25 i f MODEL@ := MM@ {... OBJSET } Periodic condition 27 / \ not alreadytriginperiod@coverage ( Set{p ; a}, MODEL@, TIME@CLK@, torat ( 5. 0 ) ) Normal periodic condition 29 / \ multiple ( TIME@CLK@, torat ( 5. 0 ) ) LHS slots 31 / \ ON@p@ATT := eval ( true, env ( self < p ), MODEL@ ) Identifiers of the new elements 33 / \ ACTEXC@ := newid ( VALUE@ids@ ) 34 / \ OR1@ : = newid ( VALUE@ids@ + 1) 35 / \ OR2@ : = newid ( VALUE@ids@ + 2) Rule duration 37 / \ MINDURATION@ := torat ( eval ( 1, env ( empty ), MODEL@ ) ) 38 / \ MAXDURATION@ := torat ( eval ( 1, env ( empty ), MODEL@ ) ) 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 operation, 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). vars PERIOD@ : Time. var L@ACTEXEC@ : MSet{OCL Exp}.

175 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 155 op : Time Time > Bool. ceq ( Set{p ; a}, MM@ < ACTEXEC@ : AtomicActionExec action : "Coverage" # startingtime : STARTINGTIME@ # participants : Set{OR1@ ; OR2@ ; L@ACTEXEC@} # ACTEXEC@SFS > < OR1@ : ObjectRole actualobject : p # role : "p" > < 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 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 ] : MM@ { --- LHS elements < p : PHONE@p@CLASS on : ON@p@ATT # battery : BATTERY@p@ATT # p@sfs > --- Further elements < CLK@ : Clock time : TIME@CLK@ > < ids@ : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > OBJSET@ } => readjust ( Set{mt}, MM@ { --- RHS elements < p : PHONE@p@CLASS on : eval ( false, env ( self < p ), MODEL@ ) # battery : BATTERY@p@ATT # p@sfs > --- Action execution < ACTEXEC@ : AtomicActionExec action : "BatteryOff" # participants : Set{OR1@} #

176 156 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS mintimer : 0 # maxtimer : 0 # status : realized # variables : Set{mt} # startingtime : TIME@CLK@ # endingtime : TIME@CLK@ # executiontime : T > < OR1@ : ObjectRole actualobject : p # role : "p" > --- Further elements < CLK@ : Clock time : TIME@CLK@ > < ids@ : Counter value : ( VALUE@ids@ + 2) > < rdm@ : Counter value : VALUE@rdm@ > OBJSET@ } i f MODEL@ := MM@ {... OBJSET } --- LHS slots / \ ON@p@ATT := eval ( true, env ( self < p ), MODEL@ ) / \ BATTERY@p@ATT := eval ( 0, env ( self < p ), MODEL@ ) --- Identifiers of the new elements / \ ACTEXEC@ := newid ( VALUE@ids@ ) / \ OR1@ : = newid ( VALUE@ids@ + 1) --- 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 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) 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,

177 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 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 c r l [ BatteryConsumption@Triggering ] : 2 MM@ { --- LHS elements 3 < p : PHONE@p@CLASS on : ON@p@ATT, p@sfs > Further elements 5 < CLK@ : Clock time : TIME@CLK@ > 6 < ids@ : Counter value : VALUE@ids@ > 7 < rdm@ : Counter value : VALUE@rdm@ > 8 OBJSET@ } 9 => 10 MM@ { --- LHS elements 11 < p : PHONE@p@CLASS on : ON@p@ATT, p@sfs > 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" > Further elements 19 < CLK@ : Clock time : TIME@CLK@ > 20 < ids@ : Counter value : ( VALUE@ids@ + 2) > 21 < rdm@ : Counter value : VALUE@rdm@ > 22 OBJSET@ } 23 i f MODEL@ : = MM@ { < p : PHONE@p@CLASS on : ON, p@sfs >... OBJSET@ } 24 / \ not currentexec@batteryconsumption ( Set{p}, MODEL@ ) 25 / \ torat ( eval ( p. battery / p. bps, env ( empty ), MODEL@ ) ) > 0 26 / \ ON@p@ATT := eval ( true, env ( self < p ), MODEL@ ) 27 / \ ACTEXC@ := newid ( VALUE@ids@ ) 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

178 158 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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 Time ceq applyongoingrules ( MM@ { --- LHS elements < p : PHONE@p@CLASS on : ON@p@ATT # battery : BATTERY@p@ATT # p@sfs > --- Ongoing action execution element < ACTEXEC@ : OngoingActionExec action : "BatteryConsumption" # endingtime : null # participants : Set{OR1@} # variables : Set{mt} # maxtimer : freeze ( MAXDURATION@ ) # ACTEXC@@SFS > < OR1@ : ObjectRole actualobject : p # role : "p" > --- Further elements < CLK@ : Clock time : TIME@CLK@ > < ids@ : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > OBJSET }, T ) = applyongoingrules ( readjust ( Set{mt}, MM@{ < p : PHONE@p@CLASS on : ON@p@ATT # battery : eval ( p. battery T p. bps, env ( self < p ), MODEL@ ) # p@sfs > --- 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 > < OR1@ : ObjectRole actualobject : p # role : "p" > < CLK@ : Clock time : TIME@CLK@ >

179 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 159 < : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > OBJSET }, T ) i f MODEL@ := MM@ {... OBJSET@ } / \ ON@p@ATT := eval ( true, env ( self < p ), MODEL@ ). / \ torat ( eval ( MAXDURATION@, env ( empty ), MODEL@ ) ) > 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 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. vars MAXT MAXT : Time. op joinongoingactionexecs 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 >

180 160 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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 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) 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

181 7.3. REAL-TIME BEHAVIORAL SEMANTIC MAPPINGS 161 => { delta ( MODEL, TE ) } in time ( T plus TE ) i f TE := mte ( MODEL ) / \ 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 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 Time [ frozen ]. op deltaaux Time [ 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]) 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

182 162 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 > TimeInf [ frozen ]. op > TimeInf [ frozen ] mte equation for the BatteryOff normal rule ceq mte ( MM@ { < p : PHONE@p@CLASS on : ON@p@ATT # battery : BATTERY@p@ATT # p@sfs > < CLK@ : Clock time : TIME@CLK@ > < ids@ : Counter value : VALUE@ids@ > < rdm@ : Counter value : VALUE@rdm@ > OBJSET@ } = 0 i f MODEL@ := MM@ {... OBJSET } / \ ON@p@ATT := eval ( true, env ( self < p ), MODEL@ ) / \ 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

183 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 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 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 and we presented the default rule that models time elapse. This rule

184 164 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 => {delta ( MODEL, TE ) } in time ( T plus TE ) i f TE := mte ( MODEL ) / \ 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 => {delta ( MODEL, TE ) } in time ( T plus TE ) 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 => {delta ( MODEL, TE ) } in time ( T plus TE ) i f TE := mte ( MODEL ) / \ TE =/= zero / \ ( T plus TE ) le torat ( ). where the le one. operation checks whether the first argument is less or equal than the second 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.

185 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 165 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 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 : eq mpnmodel { none }. op rttpmodel : eq rttpmodel { none } 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.

186 166 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 ). op init > 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: { < 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" > < 2 : ObjectRole actualobject : 9 # role : "p2" > < 3 : ObjectRole actualobject : 10 # role : "p3" > < 4 : ObjectRole actualobject : 11 # role : "p4" > < 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 > < 9 : Phone dialedcalls : OrderedSet{mt ord} # receivedcalls : OrderedSet{mt ord} # contacts : OrderedSet{ 10 # 11 # 8} # number : 222 # on : true # battery : 44 # coverage : 1 # bps : 1 # vx : 0 # vy : 1 # xpos : 45 # ypos : 29 > < 10 : Phone dialedcalls : OrderedSet{mt ord} # receivedcalls : OrderedSet{mt ord} # contacts : OrderedSet{ 11 # 8 # 9 } # number : 333 # on : true # battery : 94 # coverage : 1 # bps : 1 # vx : 0 # vy : 1 # xpos : 15 # ypos : 21 > < 11 : Phone dialedcalls : OrderedSet{mt ord} # receivedcalls : OrderedSet{mt ord} # 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 > < 13 : Antenna xpos : 55 # ypos : 15 > < 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 #

187 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 167 upperboundtimer : null > < 18 : ObjectRole actualobject : 10 # role : "p" > < 19 : ObjectRole actualobject : 14 # role : "mpn" > < 20 : AtomicActionExec participants : Set{ 21} # variables : Set{mt} # startingtime : 0 # endingtime : 5 # action : "SwitchOn" # maxtimer : 0 # mintimer : 0 # status : realized > < 21 : ObjectRole actualobject : 11 # role : "p" > < 22 : OngoingActionExec participants : Set{ 23 ; 24} # variables : Set{mt} # startingtime : 0 # endingtime : 6 # action : "Moving" # maxtimer : null # upperboundtimer : null > < 23 : ObjectRole actualobject : 11 # role : "p" > < 24 : ObjectRole actualobject : 14 # role : "mpn" > < 25 : AtomicActionExec participants : Set{ 26} # variables : Set{mt} # startingtime : 0 # endingtime : 5 # action : "SwitchOn" # maxtimer : 0 # mintimer : 0 # status : realized > < 26 : ObjectRole actualobject : 8 # role : "p" > < 27 : OngoingActionExec participants : Set{ 28 ; 29} # variables : Set{mt} # startingtime : 0 # endingtime : 6 # action : "Moving" # maxtimer : null # upperboundtimer : null > < 28 : ObjectRole actualobject : 8 # role : "p" > < 29 : ObjectRole actualobject : 14 # role : "mpn" > < 30 : AtomicActionExec participants : Set{ 31} # variables : Set{mt} # startingtime : 0 # endingtime : 5 # action : "SwitchOn" # maxtimer : 0 # mintimer : 0 # status : realized > < 31 : ObjectRole actualobject : 9 # role : "p" > < 32 : OngoingActionExec participants : Set{ 33 ; 34} # variables : Set{mt} # startingtime : 0 # endingtime : 6 # action : "Moving" # maxtimer : null # upperboundtimer : null > < 33 : ObjectRole actualobject : 9 # role : "p" > < 34 : ObjectRole actualobject : 14 # role : "mpn" > < 35 : AtomicActionExec participants : Set{ 36 ; 37} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "Coverage" # maxtimer : 0 # mintimer : 0 # status : realized > < 36 : ObjectRole actualobject : 10 # role : "p" > < 37 : ObjectRole actualobject : 12 # role : "a" > < 38 : OngoingActionExec participants : Set{ 39} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "BatteryConsumption" # maxtimer : 95 # upperboundtimer : null > < 39 : ObjectRole actualobject : 10 # role : "p" > < 43 : AtomicActionExec participants : Set{ 44 ; 45} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "Coverage" # maxtimer : 0 # mintimer : 0 # status : realized > < 44 : ObjectRole actualobject : 11 # role : "p" > < 45 : ObjectRole actualobject : 13 # role : "a" > < 46 : OngoingActionExec participants : Set{ 47} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "BatteryConsumption" # maxtimer : 45 # upperboundtimer : null > < 47 : ObjectRole actualobject : 11 # role : "p" > < 51 : AtomicActionExec participants : Set{ 52 ; 53} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "Coverage" # maxtimer : 0 # mintimer : 0 # status : realized >

188 168 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS < 52 : ObjectRole actualobject : 8 # role : "p" > < 53 : ObjectRole actualobject : 12 # role : "a" > < 54 : OngoingActionExec participants : Set{ 55} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "BatteryConsumption" # maxtimer : 95 # upperboundtimer : null > < 55 : ObjectRole actualobject : 8 # role : "p" > < 59 : AtomicActionExec participants : Set{ 60 ; 61} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "Coverage" # maxtimer : 0 # mintimer : 0 # status : realized > < 60 : ObjectRole actualobject : 9 # role : "p" > < 61 : ObjectRole actualobject : 12 # role : "a" > < 62 : OngoingActionExec participants : Set{ 63} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "BatteryConsumption" # maxtimer : 45 # upperboundtimer : null > < 63 : ObjectRole actualobject : 9 # role : "p" > < 67 : AtomicActionExec participants : Set{ 68 ; 69} # variables : Set{mt} # startingtime : 5 # endingtime : 6 # action : "Coverage" # maxtimer : 0 # mintimer : 0 # status : realized > < 68 : ObjectRole actualobject : 9 # role : "p" > < 69 : ObjectRole actualobject : 13 # role : "a" > < 70 : OngoingActionExec participants : Set{ 71} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "BatteryConsumption" # maxtimer : freeze( 10. battery / 10. bps ) # upperboundtimer : null > < 71 : ObjectRole actualobject : 10 # role : "p" > < 72 : OngoingActionExec participants : Set{ 73 ; 74} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "Moving" # maxtimer : freeze ( null ) # upperboundtimer : null > < 73 : ObjectRole actualobject : 10 # role : "p" > < 74 : ObjectRole actualobject : 14 # role : "mpn" > < 75 : OngoingActionExec participants : Set{ 76} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "BatteryConsumption" # maxtimer : freeze( 11. battery / 11. bps ) # upperboundtimer : null > < 76 : ObjectRole actualobject : 11 # role : "p" > < 77 : OngoingActionExec participants : Set{ 78 ; 79} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "Moving" # maxtimer : freeze ( null ) # upperboundtimer : null > < 78 : ObjectRole actualobject : 11 # role : "p" > < 79 : ObjectRole actualobject : 14 # role : "mpn" > < 80 : AtomicActionExec participants : Set{ 81 ; 82} # variables : Set{ 83} # startingtime : 6 # endingtime : null # action : "Call" # maxtimer : 30 # mintimer : 20 # executiontime : 0 # status : unfinished > < 81 : ObjectRole actualobject : 10 # role : "p1" > < 82 : ObjectRole actualobject : 11 # role : "p2" > < 83 : Variable name : "inittime" # value : 6 > < 84 : OngoingActionExec participants : Set{ 85} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "BatteryConsumption" # maxtimer : freeze ( 8. battery / 8. bps ) # upperboundtimer : null > < 85 : ObjectRole actualobject : 8 # role : "p" > < 86 : OngoingActionExec participants : Set{ 87 ; 88} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "Moving" # maxtimer : freeze ( null ) # upperboundtimer : null >

189 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 169 < 87 : ObjectRole actualobject : 8 # role : "p" > < 88 : ObjectRole actualobject : 14 # role : "mpn" > < 89 : OngoingActionExec participants : Set{ 90} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "BatteryConsumption" # maxtimer : freeze ( 9. battery / 9. bps ) # upperboundtimer : null > < 90 : ObjectRole actualobject : 9 # role : "p" > < 91 : OngoingActionExec participants : Set{ 92 ; 93} # variables : Set{mt} # startingtime : 6 # endingtime : null # action : "Moving" # maxtimer : freeze ( null ) # upperboundtimer : null > < 92 : ObjectRole actualobject : 9 # role : "p" > < 93 : ObjectRole actualobject : 14 # role : "mpn" > < 94 : AtomicActionExec participants : Set{ 95 ; 96} # variables : Set{ 97} # startingtime : 6 # endingtime : null # action : "Call" # maxtimer : 30 # mintimer : 20 # executiontime : 0 # status : unfinished > < 95 : ObjectRole actualobject : 8 # role : "p1" > < 96 : ObjectRole actualobject : 9 # role : "p2" > < 97 : Variable name : "inittime" # value : 6 > < clk@ : Clock time : 6 > < ids@ : Counter value : 98 > < rdm@ : Counter value : 0 > }} 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 ). 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: { < 8 : Phone coverage : 0 # bps : 1 # vx : 1 # vy : 0 # xpos : 55 # ypos : 45 # dialedcalls : OrderedSet{ 309 # 536} # receivedcalls : OrderedSet{mt ord} #

190 170 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 > < 12 : Antenna xpos : 25 # ypos : 35 > < 13 : Antenna xpos : 55 # ypos : 15 > < 14 : MPN els : OrderedSet{ 10 # 11 # 12 # 13 # 8 # 9} # xsize : 80 # ysize : 50 > < 296 : CallRecord contact : 11 # startingtime : 6 # duration : 20 > < 297 : CallRecord contact : 10 # startingtime : 6 # duration : 20 > < 309 : CallRecord contact : 9 # startingtime : 6 # duration : 20 > < 310 : CallRecord contact : 8 # startingtime : 6 # duration : 20 > < 523 : CallRecord contact : 11 # startingtime : 26 # duration : 20 > < 524 : CallRecord contact : 10 # startingtime : 26 # duration : 20 > < 536 : CallRecord contact : 9 # startingtime : 26 # duration : 20 > < 537 : CallRecord contact : 8 # startingtime : 26 # duration : 20 > < 561 : CallRecord contact : 11 # startingtime : 46 # duration : 4 > < 562 : CallRecord contact : 10 # startingtime : 46 # duration : 4 >... }} 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: { < 6 : Node receivedmessages : Sequence{ 21 # 45 # 69 # 93 # 117} # localclock : 8 # neighbors : Set{ 7} > < 7 : Node receivedmessages : Sequence{mt ord} # localclock : 9 #

191 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 171 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 > < 45 : Message initiator : 6 # responder : 7 # requesttime : 100 # rtt : 40 > < 69 : Message initiator : 6 # responder : 7 # requesttime : 200 # rtt : 40 > < 93 : Message initiator : 6 # responder : 7 # requesttime : 300 # rtt : 40 > < 117 : Message initiator : 6 # responder : 7 # requesttime : 400 # 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 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 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

192 172 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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> reduce currentactions ( resultmpnin6 ). is the following: ( "BatteryConsumption" started at 6 with 10) ( "Moving" started at 6 with ( 10 ; 14) ) ( "BatteryConsumption" started at 6 with 11) ( "Moving" started at 6 with ( 11 ; 14) ) ( "Call" started at 6 with ( 10 ; 11) ) ( "BatteryConsumption" started at 6 with 8 ) ( "Moving" started at 6 with ( 14 ; 8 ) ) ( "BatteryConsumption" started at 6 with 9 ) ( "Moving" started at 6 with ( 14 ; 9 ) ) ( "Call" started at 6 with ( 8 ; 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> reduce finalizedactions ( resultmpnin6 ). we obtain a list with the finalized actions of the system: ( "InitialModel" performed in [ 0, 0 ] with ( 10 ; 11 ; 12 ; 13 ; 14 ; 8 ; 9 ) ) ( "SwitchOn" performed in [ 0, 5 ] with 10) ( "Moving" performed in [ 0, 6 ] with ( 10 ; 14) ) ( "SwitchOn" performed in [ 0, 5 ] with 11) ( "Moving" performed in [ 0, 6 ] with ( 11 ; 14) ) ( "SwitchOn" performed in [ 0, 5 ] with 8 ) ( "Moving" performed in [ 0, 6 ] with ( 14 ; 8 ) ) ( "SwitchOn" performed in [ 0, 5 ] with 9 ) ( "Moving" performed in [ 0, 6 ] with ( 14 ; 9 ) ) ( "Coverage" performed in [ 5, 6 ] with ( 10 ; 12) ) ( "BatteryConsumption" performed in [ 5, 6 ] with 10) ( "Coverage" performed in [ 5, 6 ] with ( 11 ; 13) ) ( "BatteryConsumption" performed in [ 5, 6 ] with 11) ( "Coverage" performed in [ 5, 6 ] with ( 12 ; 8 ) ) ( "BatteryConsumption" performed in [ 5, 6 ] with 8 ) ( "Coverage" performed in [ 5, 6 ] with ( 12 ; 9 ) ) ( "BatteryConsumption" performed in [ 5, 6 ] with 9 ) ( "Coverage" performed in [ 5, 6 ] with ( 13 ; 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

193 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 173 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 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> search init ( rttpmodel ) => { < 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

194 174 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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> search [ 1 ] init ( rttpmodel ) => { < O : Message rtt : RTT # SFS > OBJSET }} in time T such that ( RTT > 40) / \ (100 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: Maude> search [ 1 ] init ( rttpmodel ) => { < O : Message rtt : RTT # SFS > OBJSET }} in time T such that ( RTT > 40) or ( RTT < 10). No solution 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: Maude> search [ 1 ] init ( rttpmodel ) => { < O : Message rtt : RTT # SFS > OBJSET }} in time T such that RTT == 20. No solution.

195 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 175 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. Maude> search [ 1 ] init ( rttpmodel ) => { < O : Message rtt : RTT # SFS > 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 => {delta ( MODEL, TE ) } in time ( T plus TE ) 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 2083) 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" > < 2 : ObjectRole actualobject : 7 # role : "n2" > < 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 #

196 176 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 > < 12 : ObjectRole actualobject : 6 # role : "n1" > < 13 : ObjectRole actualobject : 7 # role : "n2" > < 14 : ObjectRole actualobject : 8 # role : "c" > < 15 : Variable name : "inittime" # value : 0 > < 16 : OngoingActionExec participants : Set{ 17} # variables : Set{mt} # startingtime : 0 # endingtime : 20 # action : "LocalTimeElapse" # maxtimer : null # upperboundtimer : null > < 17 : ObjectRole actualobject : 8 # role : "c" > < 18 : OngoingActionExec participants : Set{ 19} # variables : Set{mt} # startingtime : 0 # endingtime : 20 # action : "LocalTimeElapse" # maxtimer : null # upperboundtimer : null > < 19 : ObjectRole actualobject : 9 # role : "c" > < 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 > < 23 : ObjectRole actualobject : 6 # role : "n1" > < 24 : ObjectRole actualobject : 7 # role : "n2" > < 25 : ObjectRole actualobject : 8 # role : "c" > < 26 : ObjectRole actualobject : 21 # role : "m" > < clk@ : Clock time : 20 > < ids@ : Counter value : 39 > < rdm@ : Counter value : 0 > 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

197 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 177 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 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: Maude> search [ 1 ] init ( rttpmodel ) => { < 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> search [ 1 ] init ( rttpemptymodel ) => { < 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.

198 178 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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 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 ( ) ) then {delta ( MODEL, TE ) } in time ( T plus TE ) else {MODEL} in time T fi i f TE := mte ( MODEL ) / \ 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,

199 7.4. FORMAL ANALYSIS OF REAL-TIME DOMAIN SPECIFIC MODELS WITH MAUDE 179 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. vars O O OR : Oid. vars SFS SFS : Set{@StructuralFeatureInstance}. var OBJSET : Set{@Object}. var L L : List{OCL Exp}. var S : MSet{OCL Exp}. var T : Time. ops stored requested responded : Oid > Prop. eq { < O : Node receivedmessages : Sequence{ L # O # L } # SFS > < O : Message SFS > OBJSET } } in time T = stored ( O ) = true. eq { < O : AtomicActionExec action : "Request" # status : realized # participants : Set{OR ; S} # SFS > < OR : ObjectRole actualobject : O # role : "m" > < O : Message SFS > OBJSET } } in time T = requested ( O ) = true. eq { < O : AtomicActionExec action : "Response" # status : realized # participants : Set{OR ; S} # SFS > < OR : ObjectRole actualobject : O # role : "m" > < O : Message SFS > OBJSET } } in time T = 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> reduce modelcheck ( init ( rttpmodel ), [ ] ( stored ( 2 1 ) > [ ] stored ( 2 1 ) ) ). r e s u l t Bool : true

200 180 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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> reduce modelcheck ( init ( rttpmodel ), [ ] ( requested ( 2 1 ) > <> responded ( 2 1 ) ) ). r e s u l t Bool : true 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 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

201 7.5. THE e-motions TOOL 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.,

202 182 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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].

203 7.6. RELATED WORK 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 Ö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 Real- Time 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

204 184 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS 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. Real- Time Fujaba [31, 32] aims at supporting the model-driven development of correct software for

205 7.6. RELATED WORK 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.

206 186 CHAPTER 7. REAL-TIME BEHAVIORAL SEMANTICS OF DSMLS

207 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

208 188 CHAPTER 8. CONCLUSIONS AND FUTURE WORK 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.

209 8.1. CONCLUSIONS 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-