On Model Typing Jim Steel, Jean-Marc Jézéquel

On Model Typing Jim Steel, Jean-Marc Jézéquel To cite this version: Jim Steel, Jean-Marc Jézéquel. On Model Typing. Software and Systems Modeling, Springer Verlag, 2007, 6 (4), pp.401–414. inria-00477547 HAL Id: inria-00477547 https://hal.inria.fr/inria-00477547 Submitted on 29 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Softw Syst Model DOI 10.1007/s10270-006-0036-6 REGULAR PAPER On model typing Jim Steel · Jean-Marc Jézéquel Received: 31 January 2006 / Revised: 23 May 2006 / Accepted: 29 May 2006 © Springer-Verlag 2007 Abstract Where object-oriented languages deal with 1 Introduction objects as described by classes, model-driven development uses models, as graphs of interconnected objects, From the perspective of the data structures involved, described by metamodels. A number of new languages model-driven computing can be seen as a progression have been and continue to be developed for this model- from object-oriented computing. Models are, in essence, based paradigm, both for model transformation and for composed of objects linked together using first-class general programming using models. Many of these use bidirectional relationships, where the structure of the single-object approaches to typing, derived from solu- objects and the relationships between them are typi- tions found in object-oriented systems, while others use cally defined by a MOF, or MOF-like, metamodel. The metamodels as model types, but without a clear notion of presence of these relationships has the effect that model polymorphism. Both of these approaches lead to brittle structures are much more tightly coupled than object and overly restrictive reuse characteristics. In this paper structures. we propose a simple extension to object-oriented typing Given this heritage, it is hardly surprising that the to better cater for a model-oriented context, including majority of approaches to developing languages for a simple strategy for typing models as a collection of manipulating models have adopted formalisms based on interconnected objects. We suggest extensions to exist- those found in object-oriented programming languages. ing type system formalisms to support these concepts The study of languages for manipulating these model and their manipulation. Using a simple example we show structures is active. In 2001, the OMG issued an RFP how this extended approach permits more flexible reuse, soliciting languages for defining model transformations, while preserving type safety. as mappings between models. In response, many languages have been developed, using variously logic-based Keywords MDA · MOF · Metamodelling · Type [13], pattern-based [17], and graph-transformation [18] systems · Typing · Model transformation approaches. Concurrently, a number of efforts are being undertaken to develop or extend programming languages to better deal with models as data structures [15]. The vast majority of these efforts have chosen to use type systems developed for use within object-oriented Communicated by Dr. Lionel Briand. development. However, as discussed in [11] and mentioned in [19], the use of such type systems in a model- J. Steel (B) · J.-M. Jézéquel oriented context renders programs somewhat brittle Irisa (INRIA & University of Rennes), with respect to changes in the metamodel, often fail- Campus Universitaire de Beaulieu, 35042 Rennes Cedex, France ing in response to changes that ought not to affect their e-mail: [email protected] operation. J.-M. Jézéquel Most important, however, is that these systems do not e-mail: [email protected] truly allow the user to specify their transformations or J. Steel, J.-M. Jézéquel programs in terms of models and types of models, but that type checking becomes mostly a large bookkeeping rather in terms of objects within models. This is counter- process). intuitive to the user. Type checking is said to be static when it is performed To resolve this, we discuss necessary extensions to without program execution (typically at compile-time object-oriented typing to deal with the relationships or bind-time). It aims at ensuring once and for all that defined in MOF metamodels. Using this extended notion there is no possibility of interaction errors (of the kind of object typing, we propose a definition of a model type, addressed by the type system). Not all errors can be including a definition of substitutability of model types addressed by type systems, especially since one usually and a discussion of reflection and inference of model requires that type checking is easy; e.g., with static type types. checking it is difficult to rule out in advance all risks of In Sect. 2, we provide a background on typing and division-by-zero errors. models and the role of typing in model-driven engineer- Type systems allow checking substitutability when ing, including a motivating example. Following this, in services are combined: by comparing the data types in a Sect. 3 we present a definition of model types with a rule service interface, and the data types desired by its caller, for model type substitutability, based on intuitive con- one can predict whether an interaction error is possi- cepts from model-driven engineering and building upon ble (e.g., producing a run-time error such as “Method research from object-oriented type systems. In Sect. 4 not understood”). Conformance is generally defined as we show how a language and type system supporting the weakest (i.e., least restrictive) substitutability rela- these concepts might be built as an extension of exist- tion that guarantees type safety. Necessary conditions ing formalisms. Section 5 discusses several further issues (applied recursively) are that a caller must not invoke related to model typing, including reflection and type any operation not supported by the service, and the ser- inference. Section 6 discusses a number of related works vice must not return any exception not handled by the from the domains of both MDE and type systems. caller. Conformance has a property called contravari- ance: the types of the input parameters of a service must vary (as either supertypes or subtypes) in the opposite 2 Background direction to those of its result parameters. Generally speaking, a type can be understood as a set of values on which a related set of operations can be per- 2.1 Example formed successfully. Once types have been defined, it is possible to use them in operation specifications of the We consider as a motivating example a simple model form: if some input of type X is given, then the output transformation that takes as input a state machine and will have type Y. Type safety is the guarantee that no produces a lookup table showing the correspondence run-time error will result from the application of the between the current state, an arriving event, and the operation to the wrong object or value. A type system resultant state. The input metamodel for this transfor- is a set of rules for checking type safety (a process usu- mation is presented in Fig. 1. The output metamodel, ally called type checking since it is often required that not shown, can be assumed to be a simple database lan- enough information about the typing assumptions has guage, but in any case we will focus on the conformance been given explicitly by the designer or programmer, so of the input type. Fig. 1 Simple state machine metamodel On model typing Fig. 2 State machine metamodel with multiple start states Fig. 3 State machine metamodel with mandatory start states Fig. 4 Composite state machine metamodel The choice of which language is used to implement one start state (Fig. 3). Alternatively, we might apply the transformation, and even of which paradigm of lan- the composite pattern by adding an inheritance of State guage to use, is immaterial. Also immaterial is the choice by StateMachine, for composite state machines (Fig. 4). as to whether the input and output types of the trans- Finally, we might consider the addition of a FinalState formation are derived (inferred) or explicitly declared. class as a new subclass of State (Fig. 5). (This choice is discussed further in Sect. 5). The question is, then, does the initial transformation Having given this metamodel as the nominal input for written for models conforming to Figure 1 still work with the transformation, we consider that there are a number models conforming to these variant metamodels? of variants of state machines whose instances might also be interesting as potential inputs to the transformation. 2.2 Objects, and their types Initially, we might consider changing the multiplic- ity of the “initial” reference from 0..1 to 0..*, for state Although research is ongoing into the fine details, the machines with multiple start states (Fig. 2), or from 0..1 basic notions of objects and the type systems that to 1..1, mandating that each state machine have exactly describe them are by now reasonably well-understood J. Steel, J.-M. Jézéquel Fig. 5 With final states [1]. As mentioned briefly above, the main difference Beyond these conventions, there are two general between the objects seen in classical object-oriented sys- approaches to defining a concept of a model. The first, tems and the objects used within models is the presence that taken by UML, is to designate some class as being of (potentially) bidirectional relationships.

Load more