On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages

SpringerBriefs in Computer Science

For further volumes: http://www.springer.com/series/10028

Brian Henderson-Sellers

On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages

123

Brian Henderson-Sellers School of Software University of Technology, Sydney Sydney NSW 2007 Australia

ISSN 2191-5768 ISBN 978-3-642-29824-0 DOI 10.1007/978-3-642-29825-7

ISSN 2191-5776 (electronic) ISBN 978-3-642-29825-7 (eBook)

Springer Heidelberg New York Dordrecht London Library of Congress Control Number: 2012938863 ACM Computing Classification (1998): D.2, H.1, I.2, F.1, F.4 Ó The Author(s) 2012 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)

Preface

Computing as a discipline is maturing rapidly. However, with maturity can come a plethora of subdisciplines, which, as time progresses, can become isolationist. Within the broad remit of software engineering have emerged the subdisciplines of modelling, metamodelling, ontologies and modelling languages to support a more disciplined approach to software development. Many of the ideas are argued in words; here, we collect together mathematical ideas that either already do underpin modelling or will do so in the near future. In particular, we seek a mathematical underpinning that will provide a solid link between ideas in these various subdisciplines. Introducing set theory as a consistent underlying formalism, we show how a coherent framework can be developed that clearly links these four, previously separate, areas of software engineering. In particular, we show how the incorporation of a foundational ontology can be beneficial in resolving a number of controversial issues in conceptual modelling, especially with regard to the perceived differences between linguistic metamodelling and ontological metamodelling. We also suggest that the focus on the model–metamodel ‘instantiation’ linkage, common in the mindset of those using standards produced by the Object Management Group, could be replaced by a model-modelling language linkage. In other words, a shift in thinking from ‘a model is an instance of a metamodel’ or, more accurately, ‘a model conforms to a metamodel’ to one where the metamodel’s role is secondary to that of the modelling language. Ideally, that modelling language should have an ontological basis, which is where the foundational ontology provides concepts such as sortals, rigidity and identity that are typically not present in today’s (object-oriented) modelling languages could provide a next generation of modelling languages that are less easily open to misuse and abuse. Finally, consideration of domain-specific modelling languages is also included in this mathematical analysis of models, metamodels, ontologies and modelling languages. Although I take responsibility for the contents of this book, I should acknowledge some personal influences on this work from my collaborators, in particular Drs. Cesar Gonzalez-Perez, Giancarlo Guizzardi and Owen Eriksson and Professors Graham Low and Pär Ågerfalk. v

vi

Preface

Lastly, I wish to thank Cesar Gonzalez-Perez, Stijn Hoppenbrouwers, Owen Eriksson and Graham Low for comments on the first draft of the manuscript for this book. This is contribution 12/05 of the Centre for Object Technology Applications and Research within the Human Centred Technology Design research centre at the University of Technology, Sydney. This research was supported by the Australian Research Council under grant DP0878172.

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

Mathematics for Modelling . . . . . . . . . . . . . . . . . . . . . . 2.1 Morphisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Abstraction Relationship . . . . . . . . . . . . . . . . 2.3.3 Representation and Interpretation Relationships 2.3.4 Classification and Generalization . . . . . . . . . . 2.3.5 Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6 Relating Classification, Generalization and Instantiation . . . . . . . . . . . . . . . . . . . . . . 2.3.7 Conformance . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

3

Models . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Token and Type Models. . . . . . . . . 3.2 Descriptive or Prescriptive? . . . . . . 3.3 Interpretive Mappings . . . . . . . . . . 3.4 Theories and Layered Architectures . 3.5 Types of Models: Summary . . . . . .

. . . . . . . . .

11 11 15 17 18 18 24 25 26

....... .......

27 28

. . . . . .

. . . . . .

31 33 35 36 37 38

4

Metamodels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5

Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Linguistic and Ontological Metamodelling . . . . . . . . . . . . . . . .

47 54

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . .

1

. . . . . .

vii

viii

Contents

6

Modelling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7

Linking Models, Metamodels, Ontologies and Modelling Languages. . . . . . . . . . . . . . . . . . . . . 7.1 Metamodels and Modelling Languages. . . . . . . . . 7.1.1 First School of Thought . . . . . . . . . . . . . . 7.1.2 Second School of Thought . . . . . . . . . . . . 7.1.3 Reconciliation of Two Schools of Thought 7.2 Augmentation by the Introduction of Ontologies . . 7.3 Incorporating DSMLs. . . . . . . . . . . . . . . . . . . . .

. . . . . . .

75 75 76 77 80 82 93

8

Other Related Work and Further Discussion . . . . . . . . . . . . . . . .

95

9

Conclusions and Further Work . . . . . . . . . . . . . . . . . . . . . . . . . .

97

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

99

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Abstract

The subdisciplines of modelling, metamodelling, ontologies and modelling languages within software engineering have, to some degree, evolved separately and without any underpinning formalisms. Introducing set theory as a consistent underlying formalism, we show how a coherent framework can be developed that clearly links these four, previously separate, areas of software engineering. In particular, we show how the incorporation of a foundational ontology can be beneficial in resolving a number of controversial issues in conceptual modelling, especially with regard to the perceived differences between linguistic metamodelling and ontological metamodelling. We also suggest the focus on the modelmetamodel ‘instantiation’ linkage can be replaced by a model-modelling language linkage. Consideration of domain-specific modelling languages is also included in this mathematical analysis of models, metamodels, ontologies and modelling languages.




Keywords Mathematical models Metamodelling languages Ontologies Software engineering










Modeling




Modelling

ix

Chapter 1

Introduction

Modelling (and hence metamodelling as a special kind of modelling) focusses on linking symbolic representations to elements within a specific part of reality. For most software engineering models, we delimit this reality as the ‘system under study’ or SUS for short, while recognising that, while Hesse (2006) argues against its use, here we use the word system in a generic sense to mean the ‘original’ or ‘target’ of our modelling exercise. This target may be (a part of) reality or an artificial system (e.g. conceptual or design models). In ontological modelling, the part of reality being examined is typically that of a coherent body of knowledge, often called a domain of interest, a material domain or simply a domain. This leads to three viewpoints on reality: the totality, a domain and a specific, relatively small, system (Fig. 1.1). Modelling each of these has many similarities but each gives rise to important differences that are often obfuscated. Furthermore, we aim to elucidate also the differences in terms of metamodelling (especially as related to systems modelling), modelling languages and ontologies and the links between them. Consequently, our focus is primarily on conceptual modelling, as opposed to solution-focussed or technology-specific design and implementation models and modelling languages (e.g. Guizzardi 2005, p. 3), although the use of modelling languages for design specifications will necessarily be considered. It is important to recognise that the linking of symbol and things present in the SUS is not direct. There is a long history (see, e.g. Baldinger 1980; Sowa 2000), dating back to Aristotle and summarised more recently by Ogden and Richards (1923), that acknowledges that there is a mediating role of the human brain. Figure 1.2a illustrates the well-known ‘meaning triangle’ (a.k.a. Ullmann triangle: Ullmann 1972) linking an object or thing in the real world to a concept or thought to a symbol. For a given domain (part or all of reality), the set of all the individual concepts abstracted from that domain is called the conceptualization (Fig. 1.2b). Guizzardi (2007) also uses the term ‘abstraction’ to mean the combination of the concepts and their relationships. A different set of terms is used by de Saussure et al. (1964):

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_1,  The Author(s) 2012

1

2

1 Introduction

Fig. 1.1 Three areas of interest: a single system, a larger domain of interest (a specific technical domain, for instance) and reality. Any of these could be called the system under study (SUS)

• signified—the concept; • signifier—the sign or string of letters as written; • referent—the actuality to which the sign refers. The incorporation in the Ullman triangle of an abstraction function immediately introduces the possibility of type–instance ‘pairings’, which, as we shall see later (Fig. 1.9), become a basis for object-oriented modelling and metamodelling, especially as undertaken under the auspices of the object management group (OMG). An OMG (meta) model is expressed using types, called classes in their Unified Modeling Language (UML) (OMG 2010a, b). Such a model is a visualisation or communication of the mental model (e.g. Wilmont et al. 2010; Jackson 2009)—called here the cognitive model (Fig. 1.3)—See also Gonzalez-Perez and Henderson-Sellers (2007). Guizzardi (2005), later in his thesis, calls this ‘domain abstraction’ in preference to ‘model’. Communication of a cognitive model needs a language (Guizzardi 2005, p. 2). In software engineering/modelling terms we can translate this as relating the SUS (a portion of reality in Fig. 1.2b, which may be either a specific system or a (larger) domain of interest: Fig. 1.1) to a cognitive model or mental model (in the brain) by the use of an abstraction process followed by the communication of that cognitive model to others by means of a concrete syntax (a visualisation or a communication through another natural sense, e.g. oral/aural1) (Fig. 1.3). Thus, the direct linkage is from SUS to cognitive model to communicated model.2 Names for this ‘communicated model’ differ widely (e.g. Aßmann et al. 2006, p. 253). For example, from an ontological standpoint, Guizzardi (2005, p. 27) calls this a ‘model specification’ or a ‘specification’ or simply a ‘model’ (Guizzardi 2007). Since the word

1

A good example of this is the talking drums of Africa (e.g. Clarke 1934). Hesse (2008) also notes the explicit representation of the human ‘actor’ in the FRISCO framework. Here, however, we imply the existence of a person by use of the term cognitive model (Hoppenbrouwers 2011).

2

1 Introduction

3

Fig. 1.2 Ogden and Richards’ ‘meaning triangle’ (a.k.a. Ullmann’s triangle) for a an individual Thing and b reality (or a specific reality domain such as banking or telecommunications, i.e. a universe of discourse (UoD) (modified from Guizzardi 2005)

Fig. 1.3 Ogden and Richards’ triangle applied to modelling

‘specification’ in software engineering has a more prescriptive or forward-looking contextual inference (see later discussion in Sect. 3.2), we eschew these terms in favour of ‘communicated model’ or, where is no ambiguity with the cognitive model, simply ‘model’. Since this book attempts to bring together a wide range of the modelling literature (in the same vein as classic texts such as Brodie et al. 1984), we need to note the differences in terminology in the published literature as well as the terminology used herein. In Fig. 1.3, we illustrate the terms typically used in semiotics and ontology viz. that the cognitive model abstracts (a) information from the SUS and this is then represented in the Communicated model by using symbols from some chosen (modelling) language (Fig. 1.4). This terminology, however, is not reflected in much of the software engineering literature wherein the implicit refers-to link is generally named represents (e.g. Seidewitz 2003; Aßmann et al. 2006, p. 253) (Fig. 1.5) and the represents and abstracts functions in Fig. 1.3 are typically confounded into a single abstraction notion between two representations. We thus propose herein to use the terminology shown in Fig. 1.6, substituting reifies (d) as the name for the link between (communicated) model and cognitive model. Consequently, there is a potential ambiguity with the term ‘represents’ or

4

1 Introduction

Fig. 1.4 The communicated model consists of the cognitive model communicated (depicted) using the modelling language (in part (a), white diamond has the semantics of a whole-part relationship; in part (b) we extend the triangle of Fig. 1.3)

Fig. 1.5 Relationships between a model and the SUS

Fig. 1.6 Merging the Ogden and Richards’ triangle of Fig. 1.3 with the terminology of e.g. Seidewitz (2003)

‘RepresentationOf’ (l)—as used in the literature. It may refer to the Communicated model to Cognitive model link as in Fig. 1.3 or to the Communicated model to SUS link as in Fig. 1.6. For example, Gaševic´ et al. (2007) use it to describe both (a) the model to system link and (b) the conceptualisation to communicated model link. In the first case, the link is shorthand for an abstraction (which may be one to one or many to one—Fig. 1.7) followed by a one-to-one representational mapping (noting that, although there are many possible representations for each model, only one is used at any one time); in the second case, it is merely a one-toone mapping (see further discussion on morphisms below). In other words, although l = d o a (=d (a)), l is often equated to a with the reifies function, d, being implied by the abstraction function, a (see further discussion in Sect. 2.3.3). In the software engineering literature, there is almost no discussion of the reifies

1 Introduction

5

Fig. 1.7 Simplistic example of one-to-one and many-toone abstraction mappings. Both diagrams show a loss of detail, but in different ways

Fig. 1.8 Ogden and Richards’ triangle applied to metamodels and foundational ontologies

link of Fig. 1.6 (but see Hoppenbrouwers et al. 2005a as one of the very few papers to include this)—we discuss the link here primarily in terms of ‘a model of a model’ (see further discussion in Chap. 6). We saw earlier (Fig. 1.2a) that a concept abstracted a thing and a conceptualisation abstracted reality (Fig. 1.2b). Although the abstraction mechanism has many facets (see Sect. 2.3.2), it does typically underpin the linking of a type to its instances. It is widely argued that types and instances are on different levels conceptually such that a two-layer architecture is appropriate for discussion of types, instances and their conjoining relationship of instanceof. It is thus argued, at least in classical OO modelling, that a model consists of types, themselves abstracted from instances. It is then possible to construct a third layer related to the second layer also in terms of type-instance. Now, the instances are the second-layer models and the ‘type’ in the third layer is called a metamodel (Fig. 1.8) or, when focussed on the ontology area, a foundational ontology (see Chap. 5) and so on. For practical reasons, only one more layer is added to create a four-layer architecture (Fig. 1.9). This leads to a chain of representation

6 Fig. 1.9 OMG’s four-layer hierarchy (after HendersonSellers and Unhelkar 2000)  Pearson Education Limited

1 Introduction M3 (MOF) Metametamodel instance_of

M2 Metamodel instance_of

M1 Model instance_of

M0 Data

relationships. While there are many possible such representational relationship choices, the OMG made a strong choice: to equate ‘represents’ (as in Fig. 1.6) with ‘instance-of’. Thus, in the multilayer hierarchy of Fig. 1.9, the link between layers is always ‘instance-of’ (see further discussion below). The inverse of the represents link in Fig. 1.5 is ‘interprets’ (sometimes said to be the inverse of abstraction, e.g. Algar and Periyasamy 1998, p. 35). Interpretation is the means by which the validity of the model is examined in the context of its relevant SUS (see further discussion in Sect. 2.3.3). Seidewitz (2003) notes that, ‘‘In terms of the OMG metamodelling layers, interpretation crosses metalayers’’. Figure 1.5 consequently implies that, by symmetry, representation must also cross metalayers. As we have seen above in discussing Fig. 1.9, this concurs with the type–instance underpinning to the OMG multilayer hierarchy. Using the terminology of Guizzardi (2005), we can say that abstracting from (several) models of reality leads to a ‘meta-conceptualization’ (Fig. 1.8), which can be depicted using either a metamodel or a foundational ontology, which, as we will see, leads to the notion of modelling/ontology representation languages including domain-specific modelling languages (DSMLs) (see later sections for a full discussion on these terms). The OMG went further and insisted that (a) the only relationship permitted between layers is instance-of and (b) that instance-of is not permitted within a single layer. This was given the name ‘strict metamodelling’ (Atkinson 1997, 1998), which is now regarded as a critical and inviolate cornerstone for OMG standards such as the Unified Modelling Language (UML) (Atkinson et al. 2009). Although initially appealing and appropriate when dealing with simple product modelling languages such as the UML, when applied to the wider domain of software methodologies/software engineering, many problems arise (Atkinson and Kühne 2000a, b, 2001a, b; 2002, 2003, 2005; Gonzalez-Perez and Henderson-Sellers 2007, 2008). As an alternative, Gonzalez-Perez and HendersonSellers (2006b) propose the use of powertypes (Odell 1994) allied with a revised metalayer3 hierarchy as shown in Fig. 1.10. In this hierarchy, there is no rigid 3

Layer and level are both used, as synonyms, in OMG documents. We have mainly used ‘layer’ here but in some cases, the use of level is retained.

1 Introduction

7

endeavour

method methodologies

assessment

quality

tools

WorkUnit

metamodel Activity

Task

Technique *

*

Fig. 1.10 Revised metalevel hierarchy based on practice rather than theory (after HendersonSellers 2006)

statement about the interlayer relationship. Rather, the layers (renamed ‘domains’4 in Fig. 1.10) are determined by observation of the realities of software developments: people effect real processes on real projects (in the endeavour domain); they use the advice of methodologies (a.k.a. methods) and associated tools (the method domain), each of which is defined (in the metamodel domain). These three domains are used in ISO/IEC 24744 (ISO/IEC 2007) to replace the Mx architecture of Fig. 1.9 because of the difficulties in fitting methodology elements into the OMG strict metamodelling architecture (see discussions in Atkinson and Kühne 2000a, b; 2001a, b; 2002; Gonzalez-Perez and HendersonSellers 2008). Figure 1.11 links these domains directly to different stages in the life cycle of a methodology: from its definition by means of a metamodel through its use in process modelling (i.e. the creation of an ‘on-paper’ methodology) to its enactment on real projects. In this context, the term ‘process’ is reserved for this enactment in the Endeavour Domain whereas the process model (a.k.a. methodology) is in the Method Domain. It should be noted that these two architectures (Figs. 1.9 and 1.10) are not commensurate. Figure 1.9 mandates strict metamodelling; Fig. 1.10 does not. Much of the literature on modelling and metamodelling attempts to fit their ideas into the architecture of Fig. 1.9, often without success. And, as we shall see, some

4

It could be argued that domain is not the best term but we retain it here since this is the term used in ISO standards and other relevant literature. Note that it also adds ambiguity to the use of the word domain in Fig. 1.1 and, later, in our discussion of domain-specific modelling languages—a typical problem when subdisciplines collide.

8

1 Introduction

Domain Name

Metamodel

Method

Methodology Metamodel

Methodology a.k.a. Process Model

Process

Endeavour

Static aspects Enactment

Dynamic aspects

Language for describing methodologies

Both a methodology and a model for enactment of processes

As enacted by real people on a specific project or endeavour

Performance

Fig. 1.11 Three domains corresponding to people’s actions (Endeavour Domain), their advice/ tools (Method Domain) and the necessary definitions (Metamodel Domain) (adapted from Henderson-Sellers and Gonzalez-Perez 2010)

ontologists who are attempting to align their work with software engineering’s modelling languages, also introduce Mx-style labelling. In other publications, these Mx labels, widely understood, are merely indicative—even when the architecture of Fig. 1.10 is actually being used. Care must therefore be taken in evaluating metamodelling ideas in the context of the more appropriate multi-level architecture. Furthermore, modelling and metamodelling terminology can per se also be initially confusing. In the OMG space of Fig. 1.9, the UML metamodel belongs to M2 (usually called the ‘metamodel’ layer) whereas a UML model belongs to M1. Although in much of software engineering, modelling and metamodelling, which is today heavily influenced by the OMG architecture of Fig. 1.9, are regarded as absolutes (e.g. ‘metamodel’ implies M2, always), in fact the prefix ‘meta’ is relative not absolute. This is seen more clearly in the ontological literature. For example, in Guizzardi (2007), a model of an abstraction of the state of affairs in a real situation is represented by a ‘model’ (which is actually at the M0 level in the architecture of Fig. 1.9)—see Figure 1.12. This contrasts with the more normal expectation in software engineering that models reside in the M1 layer. Consequently, the language used to describe this model is one (OMG) layer higher and can arguably be called a ‘metamodel’. However, this ‘metamodel’ (and the affiliated language) resides, perhaps surprisingly, on the OMG M1 layer rather than the expected M2 layer—thus emphasising the relative rather than the absolute use of ‘meta’. Guizzardi (2007) then equates this language metamodel to a domain ontology (a kind of model) such that the language used to describe it is defined at the next higher layer (‘M20 ), a language with a metamodel that is elsewhere described (Guizzardi 2005) in terms of enhancements to the UML metamodel

1 Introduction Fig. 1.12 A domain ontology has a duality in that it acts as a model to a language and metamodel at OMG M2 but also language and metamodel for the description of individuals at M0

9 Language and metamodel to describe (M1) domain ontology

M2

M1

Language and metamodel to describe (M0) individuals

M0

Model (representation) of individuals

Domain ontology (a kind of model)

(also see later, more detailed discussion and justification). In summary, care must be taken to differentiate between (a) the use of the term ‘metamodel’ in OMG/ MDA-based literature when it always refers to M2 and (b) the use of the term ‘metamodel’ in the ontological literature (e.g. Guizzardi 2005, 2007; Laarman and Kurtev 2010) when it may refer (approximately) to either as M2 or to M1. Furthermore, it should be noted that ‘UML model’ is short for ‘model that conforms to UML’ or ‘model expressed using the UML’. Similarly, while MOF belongs to M3, a MOF model is an M2 metamodel conformant to MOF (M3)— Guizzardi and Wagner (2005) use the terms MOF model and also ‘MOF as a metamodelling language’ (to parallel the statement that UML is a modelling language). However, other authors use different and essentially contradictory terms to describe the M3–M2 connection. For example, Colomb et al. (2006) describe an M2 metamodel that is conformant to MOF as a ‘MOF metamodel’. Care must therefore be taken in assigning Mx layers across various papers in the literature. In this book, we investigate the utilisation of mathematics for models, metamodels and ontologies in software engineering. The approach taken is to base our mathematics on logic, in particular on propositional logic, by which means a given statement can be unequivocally assessed as being either true (T) or false (F). It uses well-formed formulae (wffs) made from atomic formulae and logical connections (Fig. 1.13). When T/F values are assigned to the atomic formulae, the true value of more complex expressions can be evaluated using truth tables. The addition of universal quantifiers, predicates, variables and functions to propositional logic leads to the language of first-order predicate logic/calculus (Fig. 1.14) as well as other types of logic, such as temporal logic, that are not discussed here. This then allows us to create semantic meanings and to apply logical consequences and deductive reasoning. While there are many logic-based structures, the two of most relevance to software engineering are set theory and category theory. Predicate logic is the language, set theory is the theory expressed by this language—although it is

10

1 Introduction

Fig. 1.13 Well-formed formulae using propositional logic (after Alagar and Periyasamy, Fig. 6.1, 1998) (With kind permission of Springer Science+Business Media.)

Fig. 1.14 Well-formed formulae using first-order predicate logic (after Alagar and Periyasamy, Fig. 6.2, 1998) (With kind permission of Springer Science+Business Media.)

possible to eschew predicate logic and describe theory with a class-based metamodel using UML. Once we have a model describing the SUS, a set of statements can be made about the part of reality being modelled. This set of statements is usually called the ‘theory’ for the model (e.g. Alagar and Periyasamy 1998, p. 42; Seidewitz 2003), It should also be noted here that the scope of our discussion here has some limitations. For instance, we do not cover the various domains of modelling—nor the process of modelling, e.g. Hoppenbrouwers et al. (2005a; Bézivin 2005; Muller et al. 2009). The rest of the book is arranged as follows. Chapter. 2 introduces the basic mathematical concepts in terms of morphisms and relationships. Chapters 3–5 discuss the basic characteristics of models, metamodels and ontologies, respectively. Chapter 6 describes modelling languages, commencing the analysis of their relationships to metamodels and to modelling concepts introduced earlier. Chapter 7 brings together all the earlier sections by investigating how models, metamodels, ontologies and modelling languages relate to each other. A final discussion section (Chap. 8) is followed by an overall conclusion in (Chap. 9).

Chapter 2

Mathematics for Modelling

In the following subsections, we introduce the mathematical formalisms that underpin modelling, metamodelling and ontologies. Basic to a mathematical formalism are set theory and morphisms. First we consider, in Sect. 2.1, how set theory can represent modelling concepts. In Sect. 2.2, we look at mappings (functions) between pairs of sets–whether such a mapping is one-to-one, onto or both can be critical in understanding many of the ‘problems’ identified in the software engineering modelling literature. Mappings leads to the notions of relationships, discussed in Sect. 2.3, in which we show how the various modelling relationships (including abstraction, representation, instantiation, classification and conformance) can be represented mathematically. Critical to modelling is the notion of abstraction and, more importantly for metamodelling, that the abstraction is between type models, usually employing two distinct modelling languages. Abstractions are needed to create concepts–usually represented as classes in modelling, classes being essentially sets with both an extension and an intension, given by an appropriate predicate. Other important relationships for modelling include classification, generalization and instantiation. Finally, and of relevance when linking models and metamodels, is the relationship now known as conformance–a model is said to conform to its metamodel.

2.1 Morphisms To understand these concepts further, let us begin by considering how set theory may be used in our particular context of modelling. A set is a collection of individuals. If the collection is ‘accidental’, we talk of a set defined ‘by extension’. If all the members of the set have a characteristic in common (defined by a predicate), we say the set is defined ‘by intension’. In other words, intensionality

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_2,  The Author(s) 2012

11

12

2 Mathematics for Modelling

Fig. 2.1 A set and its members

set

x

x x

x

x x

x x x

x

x

x x

x

individual members of the set

defines all possible members that may legitimately belong to that set whereas extensionality defines the actual members that do belong to that set. A set A has members a1 … an (Fig. 2.1) and can be expressed as ai 2 A

for

i ¼ 1 to n

ð2:1Þ

or A ¼ fa1 ; a2 ; . . .an g

ð2:2Þ

and is used to represent an individual as belonging to a set. As noted above, the extension of a set is the totality of all the members of that set. A set (A) can be defined alternatively by ‘intension’ i.e. the predicate (or property), p, of a set that must be satisfied before any individual, x, can be considered to be a member of that set i.e. A ¼ fx j pðxÞg

ð2:3Þ

8x; ðx 2 AÞ , pðxÞ

ð2:4Þ

which stands for

(Denning et al. 1978, p. 13) who relate this to the concept of abstraction (see Sect. 2.3.2). Thus ‘‘each property defines a set, and each set defines a property’’. The test for set membership is therefore pðxÞ ) x 2 A

where Eq. 2:3 holds

ð2:5Þ

It can then be argued, using de Saussure’s terminology, that ‘‘Intension is analogous to the signified extension to the referent’’ (Wikipedia accessed 20.3.11). Intension thus provides meaning to words and model signs (signifiers). The use of these equations for conceptual modelling is elaborated in Sect. 2.3; we note that to do so we must insist on intensionality (Eq. 2.4)—which will be assumed in all the following discussions unless stated otherwise. However, before entering that discussion, we need to introduce more basic set theory considerations. Consider two sets: A and B The Cartesian product, A 9 B is a set fðx; yÞj x 2 A; y 2 Bg

2.1 Morphisms

13

A relation is a subset of this Cartesian product (Denning et al. 1978, p. 22) from the domain (related to a subset of A) to the range or co-domain (related to a subset of B). For a single set, A, a relation, q, may also be characterized as being • reflexive • symmetric

8x 2 A; x q x (the negation is called irreflexive) 8x; y 2 A; x q y ) y q x (the negation is called asymmetric)

 antisymmetric 8x; y 2 A; x q y ^ y q x ) x¼y  transitive

ð2:6Þ

8x; y; z 2 A; x q y ^ y q z ) x q z

If the relation is reflexive, antisymmetric and transitive, the relation is called a partial ordering (Denning et al. 1978, p. 23). If the relation is reflexive, symmetric and transitive, it is called an equivalence relation, usually written as *. Typically, an equivalence relation partitions a set into disjoint subsets (Denning et al. 1978, p. 25). The set of elements equivalent to x is written as [x] where ½x ¼ fy 2 Aj y  xg

ð2:7Þ

Set theory differentiates between membership and inclusion (Denning et al. 1978, pp. 14, 15)—useful for instantiation and generalization, respectively, in modelling, as discussed below. Set inclusion is useful to formalize the notion that A is a subset of B written as AB

ð2:8Þ

8x; ðx 2 AÞ ) ðx 2 BÞ

ð2:9Þ

which stands for

Furthermore, if Eq. 2.8 holds and A = B, then B contains at least one element not in A and we write AB

ð2:10Þ

which states that A is a proper subset of B. Equation 2.10 is usually implied in object-oriented modelling rather than Eq. 2.8 (Fig. 2.2). Often we need to discuss proper subsets of B such that Ai  B

ði ¼ 1 to nÞ

ð2:11Þ

where the Ai are non-overlapping and provide a complete coverage i.e. [Ai  B

ð2:12Þ

where the extension of each subset, Ai, is given by Eq. 2.7. These equations (Eqs. 2.8–2.12) provide the mathematical underpinning for the generalization relationship of object modelling (see further discussion in Sect. 2.3.4).

14

2 Mathematics for Modelling

Fig. 2.2 Set representation of a proper subset that forms a specialization

Set B

x

x x

x

x x

x x

x x x

x x

individual members of the specialized Subset A

Fig. 2.3 Powertype pattern

classification

B

(B)

instance-of

Ai

A further mathematical construct of use in modelling is that of the powerset, which is the set of all subsets (including the set itself and the empty set) and is usually written as PðBÞ or 2B (since it has 2B elements): PðBÞ ¼ fA j A  Bg

ð2:13Þ

In modelling in software engineering, a subset of the powerset is used; officially named a family of sets over B, it is more usually (mis)named a ‘powertype’ (Odell 1994; Gonzalez-Perez and Henderson-Sellers 2006b) and is useful for both modelling (in a single layer e.g. Martin and Odell 19981) and metamodelling (e.g. Henderson-Sellers and Gonzalez-Perez 2005b). The elements, Ai, of a powertype, PðBÞ; form a complete and exhaustive partition (Eqs. 2.11 and 2.12) of the superset (B) (Fig. 2.3). Thus, by applying Eq. 2.7 to sets rather than members of sets we get a number of partitions Ai given by PðBÞ ¼ fAi g

ð2:14Þ

where the equivalence relation is given by the intension of each partition: ½Ai  ¼ fx 2 B j PðxÞg where Pð xÞ ¼ iðAi Þ

ð2:15Þ

or, by analogy with Eqs. 2.3, 2.8 and 2.9, the superset B contains all the elements in the disjoint sets (partitions) that together cover set B i.e. B ¼ f xj 2 Ai ; 8ig

1

ð2:16Þ

Although Halpin (2005) suggests that most of the examples in the literature showing modelling use of powertypes are not optimal and that powertype-based modelling is rarely needed.

2.1 Morphisms

15

Fig. 2.4 The class and object facets of a clabject alternatively visualized as a class-object pair

Table 2.1 Formalisms (equations and figures) relating to three key relationships

Is-instance-of Is-kind-of (gen/spec) Powertype

Equation

Figure

2.3/2.4 2.7/2.10 2.14/2.16

2.1 2.2 2.3

Thus, PðBÞ is a set that contains elements, each of which is a partition of B. This, then, suggests that partitioning is what the classification relationship in Fig. 2.3 between a set B and its powerset PðBÞ means. A question arises from Fig. 2.3 regarding the nature of the ‘box’ labelled Ai. It represents a subtype of B yet an instance of PðBÞ: This was given the name ‘clabject’ by Atkinson (1998) and defined as a composite entity that has a class facet, [Ai], plus an object facet, Ai. To some, this is seen as controversial, requiring some sort of implicit mapping between the class aspects and the object aspects of the clabject (see later discussion of Fig. 4.4). To others, it simply is a shorthand for a pair of entities: one class plus one object i.e. a class-object pair, as described in Gonzalez-Perez and Henderson-Sellers (2007)—example in Fig. 2.4. This ‘ambiguity’ is also seen in natural languages. For example, the string ‘dog’ might be interpreted as referring to an individual, as in ‘‘This is my dog, Bran’’; or understood in terms of its dictionary entry, which clearly refers to the type characteristics defining all dogs. Having identified some key elements of set theory that we will show are of relevance to modelling and metamodelling (Table 2.1), we now turn our attention to relationships between sets in terms of formal mappings (a.k.a. functions).

2.2 Functions A function, U (as opposed to just a relation) between two sets A and B, such that U ( A 9 B, has the property that it maps every element in the domain (A or a subset of A) into exactly one element in the range (B or a subset of B) i.e.

16

2 Mathematics for Modelling

Fig. 2.5 One-to-one mapping x

x

x

x

x

x

x

x

Set A

ðx; yÞ 2 U and (x; zÞ 2 U

Set B

then this implies that y ¼ z:

ð2:17Þ

We then say that the function U maps A into B, often written as U:A!B

ð2:18Þ

y ¼ UðxÞ

ð2:19Þ

or

The source and target sets in the above discussion need only to be subsets of the full domain/co-domain. However, more generally, the mapping is between sets where the domain/range are identical with the actual sets. A function is a total function if the domain of U is equal to the set A (see Denning et al. 1978, p. 26). Generally, functions are assumed to be total functions—this will be implicitly assumed for the rest of the discussion here. A function is one-to-one or injective (Fig. 2.5) if each element of B has at most one element of A mapped to it (Fraleigh 1967, p. 33) i.e. UðxÞ ¼ z and UðyÞ ¼ z implies

x ¼ y

ð2:20Þ

A function is said to be onto or surjective (Fig. 2.6) if each element of B has at least one element of A mapped to it (Fraleigh 1967, p. 33) i.e. 8b 2 B; 9a 2 A

s:t: UðaÞ ¼ b

ð2:21Þ

If a function is both one to one and onto, it is called a bijection (Fig. 2.7). A set that has an operation (for instance, the operation plus on the set of nonzero integers) is called a group. In this case, maps that preserve structure are called homomorphisms. A homomorphism (for groups) is defined as U:A!C

such that

Uða  bÞ ¼ UðaÞ 0 UðbÞ 8a, b 2 A

ð2:22Þ

[also written as ðabÞU ¼ (a UÞ (b UÞ (Fraleigh 1967, p. 106)] where * is a binary operation in A and *0 is a binary operation in C. Since, strictly, homomorphisms can be defined only between groups or more complicated algebraic structures, we should not describe mappings between sets as

2.2 Functions

17

Fig. 2.6 Onto mapping x

x

x

x

x x

x

Set A

Set B

Fig. 2.7 Mapping that is both one-to-one and onto x

x

x

x

x x

x x

Set A

Set B

homomorphisms. However, Wikipedia (2010) also suggests that these ideas of homomorphism can indeed be used in modelling. In this approach, we consider that models can be represented as structures. The elements of those structures are nodes (e.g. classes) and relationships (that establish the structure). Then, by representing these model elements as sets together with their relationships, we can look at mappings from this set of model elements to a second set. Alternatively, Fiadeiro (2005, p. 18) defines a graph homomorphism in which the nodes of the graph are mapped to nodes and the (category-theory) arrows to arrows, preserving sources and targets. If a mapping is a bijection, (Fig. 2.7), then the homomorphism is called an isomorphism (a bijective homomorphism).

2.3 Relationships Although in formal terms, the word ‘relationship’ is an English word whereas ‘relation’ and ‘function’ are mathematical terms (Denning et al. 1978, p. 21), in software engineering and software modelling the word relationship is often used (e.g. Rumbaugh et al. 1999, pp. 411, 412) as a technical synonym for both terms (relation and function) thus obfuscating the mathematical distinction between the two terms. We will follow this latter tradition.

18

2 Mathematics for Modelling

2.3.1 Definition A definition or a defines relationship is a mapping from a concept (usually in its representation form e.g. symbol, word) to a sentence that allocates semantics to the syntax (abstract and concrete). This mapping is ideally one-to-one (an isomorphism) although in many natural languages there is often a one-to-many relationship between the representation and the concept i.e. one word may have multiple meanings.

2.3.2 Abstraction Relationship Many authors (e.g. Ludewig 2003) stress the importance of abstraction (for example, classification, generalization, aggregation) as important for the creation of models (as shown in Fig. 1.3). Roughly speaking (Giunchiglia and Walsh 1992), the technique allows one to focus on relevant attributes of the problem whilst discarding those that are ‘irrelevant details’2 (see also, for example, Keet 2007). These authors propose three informal properties: 1. abstraction maps a representation3 of the problem to a new, more ‘abstract’ representation. (This is the essence of modelling). 2. by preserving relevant, desirable properties, the abstraction process allows one to solve the original problem 3. by throwing away details, the result of the abstraction process provides a simpler problem to be solved than the original. Since, as noted above (property 3), an abstraction necessarily loses detail, this may result in several entities in the SUS being mapped to a single one in the model (Alagar and Periyasamy 1998, p. 31) i.e. aðe1 Þ ¼ aðe2 Þ: ) e1 ¼ e2

ð2:23Þ

(Kühne 2006a), where a is the abstraction function. This loss of detail creates a more simple system from the SUS for the purposes of understanding the original SUS (e.g. Giunchiglia and Walsh 1992; Ghidini and Giunchiglia 2004), although this property is excluded from the formal developments of Giunchiglia and Walsh (1992) on account of its complexity.

2

Some authors use the term ‘generalize’ to mean ignore details (see, for example, Alagar and Periyasamy 1998 p. 40). Here, the term generalize, and particularly ‘generalization’, is used in the object-oriented sense of a relationship between type and subtype (see later discussion). 3 Thus confounding the abstraction and representation links depicted in the ‘meaning triangle’ (Fig. 1.3).

2.3 Relationships

19

Next, we formalize the idea of an abstraction function, a; from a notion4 S to a notion M (e.g. from a SUS/domain to a cognitive model as in Fig. 1.3) where a:S)M

ð2:24Þ

As noted earlier, in much of the literature, abstraction is compounded with its representation (Fig. 1.3) to become a single mapping from SUS/domain to the (communicated) model. Referred to often as simply ‘representation’ (Fig. 1.6 and e.g. Seidewitz 2003) or as ‘abstraction’, this shorthand meaning of ‘abstraction’ can be defined formally as a mapping between two formal systems,P which may be similar or dissimilar (e.g. Mani 1998). Here, a formal system, ; is a set of formulae, H; written in a language K i.e. X ¼ ðK; HÞ ð2:25Þ Giunchiglia and Walsh (1992) then equate the set of formulae, H; with the language, K: Then an abstraction is the mapping between two formal systems, P ¼ ðKÞ: The definition (which addresses property 1 above) given by Giunchiglia and Walsh (1992) is: X X f : ) ð2:26Þ 1 2 P P  where the mapping is between a pair of formal systems 1; 2 with languages K1 and K2 respectively and there is an effective total function, fK ; that maps ‘ground language’ K1 to ‘abstract language’ K2 i.e. fK : K1 ! K2

ð2:27Þ

Equation 2.27 is given by Ghidini and Giunchiglia (2004) as the basic definition of abstraction. They note that this mapping needs to be both total and surjective (or onto—see Fig. 2.6) so that, respectively, for each element of K1 ; fK ; is defined and that Eq. 2.21 holds. The second of Giunchiglia and Walsh’s (1992) properties (above) can be formally described in terms of axiomatic formal systems. Since that is most relevant to automated reasoning (not the topic of this book), we exclude its mathematical presentation from this book and instead refer readers to the extensive discussions in Giunchiglia and Walsh (1992). However, there is one particular kind of abstraction of interest here—called domain abstraction by Giunchiglia and Walsh (1992): fdom ðpðaÞÞ ¼ pðvðaÞÞ

ð2:28Þ

This restates the set theoretic interpretation of abstraction (Denning et al. 1978, p. 13) given above (Eqs. 2.4 and 2.5) where a is an element and vðaÞ its equivalent

4

Although we do not discuss notions here, we follow Kashek (2004) in assuming models to be implicitly systems of notions.

20

2 Mathematics for Modelling

in the abstract language that represents the equivalence class with respect to the indistinguishability relation, where vðxÞ ¼ fy : x  yg

ð2:29Þ

(a similar statement to Eq. 2.7) and 8x; y:x  y $ 8p 2 R:pðx) $ pðyÞ

ð2:30Þ

where R is a subset of predicates (of the theory) identified as being of relevance. Alternatively, two entities, x and y, are said to be indistinguishable if and only if for all relevant predicates p pðxÞ , pðyÞ

ð2:31Þ

(Hobbs 1985) i.e. Eqs. 2.30 and 2.31 offer two alternative formalisms for indistinguishability. This then constrains the theory that is applicable to the situation. For example, using a theory in which air temperatures are measured with a precision of 0.1 C is then mapped using an indistinguishability relation to a theory in which temperatures are only distinguished to the nearest degree, we find a temperature of 20.1 and one of 20.3 to be indistinguishable in the latter theory. This is a surjective mapping (Eq. 2.21). Abstraction can also create a concept, C, (Fig. 1.2) which has an extension eðCÞ and an intension iðCÞ; which is a (set of) predicates that characterize the same elements i.e. the extensional elements eðCÞ; in a description-independent manner (Kühne 2006a, p. 374; Kühne 2009, Eq. 2.2). Hence eðCÞ ¼ fxjPðxÞg; where P ¼ iðCÞ

ð2:32Þ

which is equivalent to the set-theoretic Eq. 2.3. Giunchiglia and Walsh (1992) introduce three kinds of abstraction, which they call TD, TI and TC (where a TC abstraction is both a TD and a TI abstraction). These are picture in Fig. 2.8. In a TD abstraction, some elements of the base situation are deleted; TI abstractions are when the abstract language has additional axioms or inference rules; and TC abstractions are effectively bijective mappings (Fig. 2.7). Of particular relevance to modelling are atomic abstractions. These are classified by Ghidini and Giunchiglia (2004) as symbol abstractions, arity abstractions and truth abstractions. Symbol abstractions can operate on constants, functions and predicates and are thus the most relevant to our present discussion. For example, for a symbol abstraction, a, we have x1 ; . . .. . . xn 2 Lo ;

x 2 L1 and aðxi Þ ¼ x for all

i 2 ½1; n

ð2:33Þ

(where x is either a constant, a function or a predicate). Based on Hobbs (1985), Ghidini and Giunchiglia (2004) suggest that symbol abstractions are in fact granularity abstractions. An abstraction F is a granularity abstraction iff

2.3 Relationships

21

Fig. 2.8 Three kinds of abstraction of Guichiglia and Walsh (1992)

Base language

Abstract language

TD

TI

TC

1. F maps individual constants in K to their equivalence class under the indistinguishability relation * in K. [Thus, for an individual x in K, FðxÞ ¼ vðxÞ where vðxÞ is given by Eq. 2.29.] 2.

F maps everything else; including the predicates in K; to itself :

ð2:34Þ

(Mani 1998; citing Hobbs 1985 and Giunchiglia and Walsh 1992). Keet (2007) proposes a set of abstractions similar to the TC, TD and TI abstractions of Giunchiglia and Walsh (1992) but couched in terms more accessible to conceptual modelling and ontologies as follows: R-abs: An abstraction is said to be an Rabs abstraction if and only if the more detailed type / abstracts into its related parent type w

ð2:35Þ

This makes an isomorphic mapping (Fig. 2.7) that loses detail only; for example, it could be the basis for subtyping (see below) or for token models (Sect. 3.1). F-abs: An abstraction is said to be an Fabs abstraction if and only if a more detailed theory T0 ðwith /1 . . ./n entity types; relations and constraints among themÞ abstracts into a single related parent type; w; in T1 that is distinct from any /i ð2:36Þ This makes F-abs an on to morphism (Fig. 2.6 and Eq. 2.21) D-abs: An abstraction is said to be a Dabs abstraction if and only if a more detailed theory T0 with /1 . . ./n entity types; relations and constraints abstracts into theory T1 with /01 . . ./0m entity types; relations and constraints; and with m\n through deletion of elements either from T0 to obtain T1 or from T00 s user interface

ð2:37Þ

22

2 Mathematics for Modelling

Fig. 2.9 Abstraction relation R-abs modelled as a function (mapping)

X

R-abs

X

Abstraction layer : Given a base theory T0 and a simpler theory T1 into which T0 is abstracted; then the abstraction layer; denoted by li ; is the surrounding frame that contains Ti ; which form a tuple hL; si where li 2 L and Ti 2 s and where l0 l1

ð2:38Þ

where Ti is any logical theory—in our case this could be either a metamodel, an ontology or a conceptual model. These definitions are not incompatible with those of, for example, Giunchiglia and Walsh (1992), but give a more immediately usable framework to explain mathematically typical modelling concepts such as generalization (is-a-kind-of), aggregation and abstraction layers that are both a foundation for modelling and metamodelling and for explaining the difference (see below) between token models and type models. Importantly, the R-abs function maps between elements that belong to the same theory and therefore use the same language, K (Fig. 2.9). For example, generalization is a kind of R-abs when the abstraction mapping is between two types, / and w, one of which is a subtype of the other (cf. Eq. 2.10) such that (Keet 2007) aisa ð/Þ ¼ w /w aL ð/Þ ¼ li aL ðwÞ ¼ lj li  lj

ð2:39Þ

aL : s ! L

ð2:40Þ

where

retrieves the layer in which the theory or its entity types reside. (A set theory formula for generalization is presented in Sect. 2.3.4). Secondly, the D-abs abstraction permits a formalization for the removal of types during abstraction (and hence during modelling). aL ð/Þ ¼ li li  lj

ð2:41Þ

2.3 Relationships

23

Thirdly, a combination of F-abs (which maps several entities to one) and D-abs (which removes entities during the abstraction process) is a useful representation for creating abstraction hierarchies. af ð/; wÞ ¼ n

ð2:42Þ

aL ðwÞ ¼ li aL ð/Þ ¼ li aL ð nÞ ¼ l j li  lj

ð2:43Þ

where

together with the so-called folding constraint, that for each /; w where ap3 ð/; wÞ ¼ n or ap4 ð/; wÞ ¼ n; aL ðnÞ ¼ lj ; there must be either (i) a predicate p such that pð/; wÞ 2 T1 that is contained in li or ðiiÞ / is an endurant ED; w ¼ p0 and 8x

ð2:44Þ

ðED(x) ! 9yðp0 ðx; yÞÞÞ in Ti Then, with these abstraction functions and Eq. 2.38 for abstraction layer, a multi-layer abstraction hierarchy can be defined as follows (Keet 2007): Let s be the set of theories; = denote the set of abstraction functions and L the set of layers obtained by using ai 2 = on a theory T0 2 s; then an abstraction hierarchy H 2 H is the ordered sequence of layers; l0 . . . ln 2 L with n [ 1; obtained from enabling ai 1 times successively on T0 ; T1 . . . Tn 1 such that l0 l1 . . . ln 1  l and aL ðT0 Þ ¼ lo . . .aL ðTn Þ ¼ ln

n

ð2:45Þ

Keet (2007) strongly recommends the use of only one type of abstraction function in creating the hierarchy—as used for instance in the so-called strict metamodelling hierarchy (Atkinson 1997, 1998) used by the Object Management Group (also see earlier discussion). She also points out that Eq. 2.40 is analogous to similar functions for granularity (Keet 2006) e.g. aL ðT1 Þ ¼ l1

with

l1 2 L

ð2:46Þ

and, hence, if /i [ T1, then aL ð/1 Þ ¼ l1

ð2:47Þ

Granularity abstractions as applied to metamodels are discussed in HendersonSellers and Gonzalez-Perez (2010) where the values of granularity for several current metamodels are given. An application to method fragments (for situational method engineering) is examined in Henderson-Sellers and Gonzalez-Perez (2011).

24

2 Mathematics for Modelling

Granularity abstractions are the basis for token models (Sect. 3.1) wherein the theories T1 and T2 are the same, as are the associated languages K1 and K2. In the case where K1 = K2 and where the abstraction is not merely of granularity but is an F-abs, it is possible to create multiple layer hierarchies (Eq. 2.45) and hence type models (Sect. 3.1) that form the basis for software engineering metamodelling (Gonzalez-Perez and Henderson-Sellers 2008). Finally, we note that Kühne argues that (based on Stachowiak 1973) abstraction can be decomposed into three distinct steps: projection (p), followed by (optional) further abstraction (a0 ) then translation (s) into a modelling language (typically) i.e. a ¼ s o a0 o p

ð2:48Þ

Kühne (2006a) states that projection is an injective homomorphism (see Eq. 2.22) because it preserves structure and maps a (subset) of the domain to the target (or range). Projection as used by this author would seem to be equivalent to the ontological abstracts relationship as depicted in Fig. 1.3—see also next subsection. The function s is a one-to-one mapping between elements of the cognitive model and elements of the communicated model i.e. the ‘reifies’ relationship of Fig. 1.6 (or the represents relationship of Fig. 1.3). It is represented mathematically by Eq. 2.20 (Fig. 2.5).

2.3.3 Representation and Interpretation Relationships As noted earlier, the RepresentationOf (and name variants) relationship is ambiguously used in the literature. Although the representation relationship exists strictly between a Cognitive Model and its Model Representation (Fig. 1.3), when it is a simple isomorphic mapping (Eq. 2.20), several authors (e.g. Seidewitz 2003; Aßmann et al. 2006) state that the representation relation (and its inverse the interpretation relation) (e.g. Wand 1996) link a model directly to an SUS (as depicted in Fig. 1.6 and discussed in Chap. 1). In this latter case, it refers to an abstraction plus a visualization, where the abstraction may be an R, F or D abstraction (Eqs. 2.35–2.37) which can be transitive or non-transitive. Gaševic´ et al. (2007) state clearly that it is non-transitive, which suggests that they have made further, unstated assumptions— see also discussion below on type and token models. Furthermore, within one single paragraph these authors clearly use RepresentationOf, first as used in Fig. 1.6 and then as used in Fig. 1.3—another ambiguity.] Wand (1996) is more specific and proposes these two mappings (representation and interpretation) as being between ‘ontological constructs’ and ‘grammar constructs’, where the ‘ontological constructs’ are linked to reality and the grammar refers to the constructs in a modelling technique or modelling language. The represents relationship of Fig. 1.6 is crucial to a clear understanding of modelling and metamodelling. Its definition in terms of an appropriate abstraction type is explored further in Sect. 3.1 with respect to token and type models.

2.3 Relationships

25

However, the interprets relationship of Fig. 1.5 is observed by Seidewitz (2003) in the context of the UML to be ‘‘not as conventionally fixed as in the case of Newtonian models’’. For this reason, and for an aim of simplicity, we will omit this from our later diagrams, leaving it as an implicit inverse of the represents relationship.

2.3.4 Classification and Generalization Classification and generalization can both be considered as kinds of abstractions (e.g. Kühne 2009) since they both lose information/detail. Classification is expressed as an F-abs abstraction (Eq. 2.36) whereas generalization is an R-abs abstraction (Eq. 2.35). Classification refers to the allocation of individuals into a set defined by a set of predicates. Eq. 2.32 links the extensional and intensional definitions of a set that thus permits an answer to the question whether a specific instance, e, does or does not belong to the set; in other words whether e is classified by concept C. From an extensional viewpoint, we have: e C C , e 2 eðCÞ

ð2:49Þ

where e(C) is given intensionally by Eq. 2.32 and C is the symbol for the classification abstraction which is a non-transitive relationship and which is also a granularity abstraction. This parallels the set-member relationship of Eq. 2.1. In object modelling, such a set, defined intensionally, is regarded as a type or class. Although these terms are not synonymous, they are often treated as such unless one wishes to specifically accept or avoid the Liskov substitution principle (Liskov 1987; Liskov and Wing 1994) to undertake subtyping or subclassing (respectively). In contrast, in set theory terms, generalization denotes the relationship between a set B and a subset A where, analogously to Eq. 2.8, we can write 8ai 2 A

and

A  B;

ai 2 B

ð2:50Þ

or, in terms of extensions eðAÞ  eðBÞ

ð2:51Þ

(Kühne 2009, Eq. 2.3). Furthermore, predicates defined for B are also valid in A, although the set of predicates for A may be larger i.e. from Eq. 2.3 8x ðx 2 BÞ , pðxÞ and 8y ðy 2 AÞ , qðyÞ

26

Z Z

Z X X

Y

X

Fig. 2.10 Venn diagram representation of the generalization relationship

2 Mathematics for Modelling

Y

Y

Z

Z

Y X

X X

Y

Y

where pðxÞ  qðyÞ

ð2:52Þ

The generalization (subtyping) relation is transitive since it involves the subsetting notion of Eq. 2.50 (Fig. 2.10). It is called IncludedIn (f) by Favre (2004) and Gaševic´ et al. (2007).

2.3.5 Instantiation The relation (mapping) between set and set member is the instantiation, or instance-of, relation (Eq. 2.1). Its inverse maps several instances to one set; where the set is actually a concept (Fig. 1.2a and Sect. 2.3.2) and thus Eq. 2.32 holds, this inverse is the classification relationship of Eq. 2.49. It is also self evident that since properties p(x) are defined for the set, then each member of the set must possess the property and, furthermore, not merely the existence of the property per se but also a value of that property—so-called slot values or property values (which could also be null values). A consequence of this is non-transitivity for the instance-of relation (Eq. 2.1) which links type instances to the type. Two kinds of instanceOf are discussed by Laarman and Kurtev (2010). The ontological instanceOf is said to occur within a single metalayer (Fig. 1.8) and to partition a model. It is said by these authors to be treated as a UML association. In contrast, the linguistic instanceOf is used to define the various metalayers. To avoid this terminological overloading, the second usage is often relabelled ‘conformsTo’ (see Sect. 2.3.7). The instantiation relationship is often written as is-a; but this is ambiguous as many authors have pointed out (e.g. Bézivin and Lemesle 1998; Atkinson et al. 2000). For example, consider the statement of Laarman and Kurtev (2010) that ‘‘UML classes, for example, the Crocodile, are substantial universals’’ where SubstantialUniversal is an element (class) in the foundational ontology (metamodel).

2.3 Relationships

27

Three meanings were identified by Atkinson et al. (2000): • is an instance of (see above) • is a kind of (see below) and, specifically in UML (OMG 2005a), the most commonly used modelling language in software engineering • a stereotype label used to ‘brand’ a class in a model with another class (Atkinson et al. 2003). This third interpretation is strictly a misuse of the UML’s modelling rules (e.g. Henderson-Sellers and Gonzalez-Perez 2006) and thus outside the scope of our current theoretical analysis. The second interpretation is highly relevant to our discussion since it represents the abstraction relationship more typically called generalization (or its inverse of specialization) which, in object-oriented programming languages, is usually implemented using the inheritance capability of the language.

2.3.6 Relating Classification, Generalization and Instantiation Generalization thus relates entities within the same theory and thus within the same metamodelling layer. It is therefore only relevant to token models (see Sect. 3.1). In contrast, instantiation may be either within a single theory (see later discussion on token models) or involve two theories and two (meta)modelling layers (see later discussion on type models). Instantiation and classification are clearly related, as noted above. Strictly, classification provides a test regarding whether an individual satisfies the intension of a class (set). Instantiation, on the other hand, selects an individual from a preexisting set or creates an individual by using the criteria given by the set’s intension as a template and is therefore more relevant to the current discussion. Indeed, Abadi and Cardelli (1996, Sect. 2.1, 3.1) suggest that the major difference between type and class is that a type is simply about conformance to a signature (more or less like a set defined by intension), whereas a class gives you a templating mechanism, a ‘creation machine’ capable of instantiation. In summary, classification determines if an individual belongs to an intensionally-defined set, instantiation relates individuals to sets (types) and generalization relates types to (super)types (A more detailed comparison of classification and generalization has been undertaken recently by Kühne 2009.) A highly relevant question to be addressed here is which of these (if any) is useful in relating models to metamodels. As noted above, and by e.g. Seidewitz (2003), instanceOf links two entities within a single theory. Consequently, it is not appropriate to link, in this way, models and metamodels, which, by definition, utilize two different theories. Despite this, much of the literature expresses the linkage as ‘a model is an instance of a

28

2 Mathematics for Modelling

metamodel’ e.g. Atkinson et al. (2000); Frank (2008) Laarman and Kurtev (2010) although the former authors only use it as a shorthand for ‘elements of a model are instances of elements in a metamodel’. Over the past decade, a number of authors (e.g. Bézivin 2005) have begun to explicitly question the use of instanceOf in this context—although Kühne (2006a), whilst accepting Bézivin’s argument, chooses to stick with instanceOf simply to align with the literature majority. If instanceOf was valid for model-metamodel links, then every model, Mi, ever constructed (and those still to be constructed) would be a member of the (extension) of the metamodel expressed as a set, MM, i.e. Mi 2 MM8i

ð2:53Þ

However, to check if any (new) model belonged to the set MM, we would need to know the intensional definition of the MM set. In both extensional and intensional assessment, the finest granularity is that of ‘model’. In other words, there is absolutely no information about the details inside the model. But this ‘inside information’ is precisely what is needed in order to assess if a given model is valid in the context of the metamodel. The conformance test must be that all elements (nodes and edges) of the model (expressed as a diagram/graph) must each be correctly defined by an element in the metamodel. This means that there must be a classification mapping from all classes to the metaclass Class, from all associations to the metaclass Association and so on. The mapping must be a homomorphism that is on to. This leads to the notion of conformance of a model to its metamodel, beyond the use of simple instantiation and/or generalization. Gaševic´ et al. (2007) state that MDE is characterized by two main relations: representation (as used here) and conformance. Conformance is defined and discussed in more detail in the following subsection.

2.3.7 Conformance Two kinds of instantiation, as used for instance in the OMG metamodelling suite, are identified initially by Bézivin and Lemesle (1998). In investigating underlying theories for model-driven engineering (MDE) and particularly the MDA version of MDE (which uses the multilayer architecture of Fig. 1.8), Bézivin and Gerbé (2001) also discuss the two different ‘isA’ relationships of (1) an object is an instance of a class and (2) a model is an instance of a metamodel (as often stated in the OMG-related metamodelling literature and used by e.g. Saeki and Kaiya (2007) and by Atkinson (1997, 1998) in his discussions of ‘strict metamodelling’). To make this distinction clearer, they call the type-instance relationship ‘meta’. These authors then introduce the ‘sem’ relationship to express the link between a model, X, and its metamodel, Y, such that, if entities of X have a meta relationship to entities in Y, then there is a sem relationship between X and Y i.e. sem links a model and metamodel pair whereas meta links individual entities within those two

2.3 Relationships Fig. 2.11 A model has a ‘sem’ (or conformant to) relationship to its metamodel whereas elements in that model are related to elements in the metamodel by ‘meta’ (a classification relationship)

29

meta

meta

meta

sem

modelling layers (Fig. 2.11). Bézivin and Gerbé (2001) note that the sem relationship corresponds to the layer-to-layer relationship of the OMG multi-layer hierarchy. A consequence of this is that the instance-of relationship (as in the traditional OO relationship of ‘an object is an instance of a class’) is now restricted to within a layer (within a theory), as discussed by Seidewitz (2003) who stresses that instance-of only has meaning within a theory (e.g. an OMG meta-layer) and not between layers. Indeed, Bézivin and Gerbé (2001) stress the importance of preventing the instance-of relationship from crossing layer boundaries. In later publications, the sem relationship is renamed ‘conformantTo’ (Bézivin 2004, 2005). Although Bézivin (2004) noted that he expected the precise definition to take some time before complete agreement could be reached, his example (Bézivin 2005) sheds some light by demonstrating that a model conformsTo its metamodel when there is a ‘meta’ relation (Fig. 2.11) between each model element and its corresponding metamodel element (where ‘meta’ is equivalent to the classification relationship of Eq. 2.49), remembering that the elements of a metamodel are themselves classes i.e. sets. We thus propose a formalization here between a metamodel, MM (={mmi}), and a model, M (={mi}): conformsToðM; MM Þ ¼ 8mi 2 M; 9mmi 2 MM

s:t: metaðmi ; mmi Þ8i ð2:54Þ

where meta(mi, mmi) is a classification abstraction given by Eq. 2.49. Bézivin (2005) informally notes that this parallels the statement that ‘a map conformsTo its legend’ as meaning the map is written in the graphical language defined by its legend. Thus we can say that the statement that a model conformsTo its metamodel means that the model is depicted in the language defined by its metamodel. This agrees completely with the commonly quoted statement that a metamodel is a model of models (see Chap. 4). Joualt and Bézivin (2006) propose a mathematical definition for conformsTo based on the notion of a so-called ‘reference model’.5 A model, M, is said to conform to its reference model, x, where M is a triplet (G, x, l) in which 5

Note that this is a very different meaning from the use of ‘reference model’ in software engineering standards published by ISO’s SC7 committee.

30

2 Mathematics for Modelling

classified by Partitioned type

Powertype

instanceOf one of several subtypes

Subtype

clabject

Fig. 2.12 The elements of a powertype pattern. The ‘Subtype’ is a clabject that inherits from the ‘Partitioned type’ and is an instance of the ‘Powertype’. (Only a single subtype is depicted although there are likely to be several.) (after Henderson-Sellers 2011b)

 G ¼ ðNG ; EG ; CG Þ is a directed multigraph consisting of a finite set of nodes; NG ; a finite set of edges; EG ; and a function CG : EG to NG  NG i.e. mapping each edge to its source and its target node.  is associated to a graph Gx ¼ ðNx ; Ex ; Cx Þ:  there is a function that associates nodes and edges of G to nodes of G given by l : NG [ EG ! Nx

ð2:55aÞ ð2:55bÞ ð2:55cÞ

Joualt and Bézivin (2006) note that l is neither injective (Fig. 2.5 and Eq. 2.20) nor surjective (Fig. 2.6 and Eq. 2.21). Note that the use of conformsTo by Favre (2004) is somewhat different and can only be utilized in the context of a modelling language (see discussion in later section). Also, Kühne (2006a) chooses to confound the meta and sem relationships calling it ‘instance-of’ despite the assertion by Bézivin (2004) that ‘‘stating that a model is an instance of a metamodel often leads to much confusion’’. As seen above (Fig. 2.11), there is an instantiation relationship between individual elements (one in each layer i.e. a type-instance relationship) but not between models. Powertype conformance requires definition. This can be accomplished by extending Bézivin’s (2005) definition by enforcing Method Domain clabjects to map to both a powertype (an instance-of/classification mapping) and a partitioned type (a generalization mapping) (Fig. 2.12—see also Fig. 2.3 and Eq. 2.13).

Chapter 3

Models

A model is ‘‘an abstraction of reality according to a certain conceptualization’’ (Guizzardi 2005) and is therefore a set of statements about some ‘system under study’ (SUS) (Seidewitz 2003)—although note that Hesse disputes with Kühne the use of the word ‘system’. Statements can be shown to be either true or false (see also Gonzalez-Perez and Henderson-Sellers 2007). Stachowiak (1973)—quoted by many authors such as Ludewig (2003), Kühne (2006a) and Gonzalez-Perez and Henderson-Sellers (2007)—suggests that all models must meet three criteria: • A mapping to a SUS, i.e. there is a representational relationship between model and SUS • Some kind of reduction from the SUS to the model—it is thus an abstraction (e.g. Kühne 2006a) • The model should be able to act as a surrogate for the SUS (e.g. Bézivin and Gerbé 2001; Jackson 2002) These three criteria are recast by Kühne (2006a) as • Mapping feature • Reduction feature • Pragmatic feature and by Gonzalez-Perez and Henderson-Sellers (2007) as: • Homomorphism • Abstraction • Purpose The first two points of each of these authors underlines the use of the ‘represents’ shortcut of Fig. 1.6, with the oft-used synonym of ‘abstracts’. In software engineering, the term ‘model’ is implicitly the ‘communicated model’ of Fig. 1.3 and not the ‘(cognitive) model’.

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_3,  The Author(s) 2012

31

32

3 Models

Introducing the abstraction function a (e.g. Eq. 2.33 or 2.48) between model M and SUS S, we can rewrite Eq. 2.24 (Kühne 2006a) as M ¼ aðSÞ

ð3:1Þ

As discussed earlier, a model is said to ‘describe’ an SUS (Seidewitz 2003) or that a model represents the SUS (in the Stachowiakian sense). We can thus take ‘describes’ and ‘represents’ as synonyms in our context of modelling. Thus, when authors (e.g. Aßmann et al. 2006, p. 253) state that ‘models represent reality’ or that a model describes an SUS, e.g. Aßmann et al. (2006), they are effectively utilizing the ‘shortcut’ shown in Fig. 1.6, i.e. l & a. This modelling abstraction (cf. Eq. 3.1) is alternatively written by Kühne (2006a, b) as qðS; MÞ ! S / M

ð3:2Þ

(i.e. q is a subset of /), where q is the representational relationship between model M and SUS S and /, the ‘modelled-by’ (the representation relationship of Fig. 1.6) relationship, indicates a potentially many-to-many relationship between model and SUS. While Kühne notes that two relationships are needed because some model pairs may not correspond to a representation, he presents much of his argument using the / relationship rather than the (anticipated) q. [We will therefore here confound these as either ‘models’ or ‘represents’, i.e. taking them as synonyms.] Seidewitz (2003) states this as ‘‘a model is a representation of an SUS’’ and that ‘interpretation’ is the inverse of representation (Fig. 1.5). In mathematical logics, interpretation is the assignment of semantic meaning (see also Wand 1996; Jackson 2009). Meaning is embedded in the particular representational choice and therefore the language used; this should be made explicit via an ontological commitment, such as by use of a foundational ontology (Guizzardi 2005, p. 89). Interpretation of a model is thus a mapping of the model’s elements to the SUS elements that thus also permits model validation (with respect to the SUS) (Seidewitz 2003). Interpretation is important as it is a mapping from the model elements to ‘reality’ (the SUS) and thus provides a means to check the correctness of the model [but note that the correctness of the model depends upon its interpretation in either a prescriptive or a descriptive role—see below]. Seidewitz (2003) also notes (p. 31, col. 2) that this is often replaced by the ‘instance-of’ relationship, which is only formally defined within the theory of the modelling language (i.e. not between model and SUS or between model and metamodel) (see also earlier discussion on Instantiation in Sect. 2.3.5). Seidewitz stresses two interpretations for the ‘meaning of models’, while noting that the reflexive nature of the UML (or similarly constructed language) tends to conflate the two aspects of meaning: 1. The meaning of the model in terms of the elements of the SUS that it represents—he calls this the ‘interpretation’ of the model; and notes that it is possible for multiple interpretations to exist, depending upon the context.

3 Models

33

Fig. 3.1 Six modes (in 3 pairs) of a model, giving eight categories of models (see detailed discussion in the following subsections)

2. The deductions possibly from the existing elements and ideas to new ones—he calls this the ‘theory’ of the modelling language—others call it the semantics of the language. Both interpretation and representational mappings as described by Seidewitz (2003) relate elements of the SUS to elements of a model. Consequently, we can here equate these to the ‘meta’ relationship of Bézivin (see Fig. 2.11 and Eq. 2.36). And, since Seidewitz (2003) notes that when a model is a representation of an SUS, all statements in the representation are true for the SUS under the interpretation mapping, we can conclude that the representational mapping is a more general case of the conformsTo mapping of Eq. 2.54. Or, in other words, the conformsTo mapping is a representational mapping in which the SUS is a model and the model is a metamodel. Many authors differentiate between various kinds of models, often really different roles of models (Fig. 3.1). The most relevant discriminations are outlined below. However, although Bézivin (2005) notes a widespread distinction between process and product models in the computing literature (as exemplified in the OMG standards by UML (OMG 2005a, 2010b) and SPEM (OMG 2002, 2008) as distinct metamodels), the advent of standards such as ISO/IEC 24744 (ISO/IEC 2007) as an International Standard for metamodels that combines not only these two methodological aspects but also the important involvement of people (as Producers), we will not introduce a process/product discriminator in the discussion below. Of critical importance for our analysis here is the difference between type and token models (e.g. Kühne 2005, 2006a). A token model is a granularity abstraction (Sect. 2.3.2), where the SuS and the model both use the same language and the same vocabulary for their description. In contrast, a type model creates a type– instance relationship that is important for linking models and their corresponding metamodel and modelling language.

3.1 Token and Type Models An important but frequently neglected characteristic of models is whether they capture singular or universal aspects of the SUS. The former are referred to as token models and can form an isomorphic chain of models exhibiting transitivity.

34

3 Models

In contrast, type models are non-transitive and use the kind of abstraction known as classification (see Sect. 2.3.4). They are thus often referred to as classification models or schema models (Kühne 2005). However, this differentiation must be identified within the constraints of a specific context—Kühne (2006a, p. 374) notes that a model may play the role of a token model or a type model, perhaps both under two different sets of circumstances. Token models are probably the more common understanding for the concept of ‘model’ (Kühne 2005) although the assertion by Gaševic´ et al. (2007) that RepresentationOf is nontransitive strongly suggests that they assume all models to be type models. For a token model, Kühne (2006a) modifies the model-of notation (Eq. 3.2) such that1 qðS; MÞ ! S /i M

ð3:3Þ

where q is a granularity abstraction (Eqs. 2.46 and 2.47). The corresponding expression for type models is given by qðS; MÞ ! S /t M

ð3:4Þ

where q is a classification abstraction (Eq. 2.49). In addition, a0 in Eq. 2.48 (the additional abstraction) is the identity function, which means that the mapping is one-to-one. A token model could be said to refer to ‘a model of a model’ and, as noted above, is transitive since a chain of token models is always valid. For type models, a0 is given as C which is the (nontransitive) classification function (Eq. 2.49), which Kühne (2006a) claims to be a homomorphism, although it seems to have a 1:m cardinality on the mapping. A type model could be said to refer to ‘a model of models’ (a commonly used definition of the term ‘metamodel’). Kühne (2006a, p. 375) notes that if M is a token model of system S and if there is an instance Si of S, then M is a type model for Si. With respect to the three forms of abstraction discussed in Sect. 2.3.4, generalisation only relates to token models. Hesse (2006) discriminates between feature projection (w.r.t. token models) and placeholder projection (w.r.t. type models). Hesse also notes that type/token are roles that a model may play not an intrinsic property of the model. Kühne’s response (Kühne 2006b) equates feature projection with p followed by optional a0 = id (token model) or else C (type model). Following Hesse (2006), we can thus both simplify Eq. 2.48 and give it direct relevance as a discriminant of type and token models as follows. The decomposition advocated by Eq. 2.48 introduces a second function a0 , which permits the creation of distinct model strategies (especially type and token models— see below), and a s mapping that supports the visualization of the resulting model elements. However, Hesse (2006) suggests instead amalgamating a’ and p such that either a ¼ s o pp

ð3:5Þ

3.1 Token and Type Models

35

where pp is called placeholder projection given by pp ¼ Co p

ð3:6Þ

a ¼ s o pf

ð3:7Þ

or

where pf is called feature projection given by pf ¼ p

ð3:8Þ

Placeholder projection is equivalent to the classification abstraction, leading to type models; whereas feature projection relates to token models via the use of the R-abs abstraction (Eqs. 2.35 and 3.3). Finally, it should be noted that token models necessarily involve one-to-one mappings and use the same language, K; while type models rely on a one-to-many mapping and typically the source and target use different languages, K1 and K2 (Eq. 2.27).

3.2 Descriptive or Prescriptive? Whether a model is descriptive or prescriptive is seen by Aßmann et al. (2006, p. 253) as being a fundamental feature of a model—here, we will show that this dichotomy is better thought of as a role rather than as a permanent feature or characteristic. Seidewitz (2003) differentiates between models used to describe1 an existing SUS and models used to depict an SUS-to-be. The latter role of a model is called by Seidewitz (2003) a specification model and this is the more usual appellation in software engineering (e.g. Alagar and Periyasamy 1998, p. 6) (and engineering in general). Another common term is a prescriptive model; coupled with the term descriptive for a model of an existing SUS. Alternative terminology of analytical (for descriptive) and synthetical (for prescriptive) are used by Muller et al. (2009), who define these two terms, respectively, as x ! y : 9Ta j x ¼ Ta ðyÞ la

x ! y : 9Tc j y ¼ Tc ð xÞ

ð3:9Þ

lc

Aßmann et al. (2006) discriminate between the way in which a representation relationship (e.g. Fig. 1.5) is used for prescriptive and descriptive models. They argue that an ‘is-described-by’ relationship is appropriate for descriptive models

1

We can thus equate the term ‘describes’ with the more formal term ‘represents’ (in the Seidewitz sense).

36

3 Models

Fig. 3.2 Backward-looking model (top) and forwardlooking model (bottom)

x

x

x

x

x

x

x

SUS

Model

x

x

x x

x

x

x

x

x

SUS

Model Time

such as ontologies whereas, for prescriptive models, which are typically used to generate instances rather than merely describe them, an ‘instance-of’ relationship is more appropriate (see also later discussion with respect to Figs. 7.16–7.18). These terms (descriptive, prescriptive) are widely used (e.g. Rothenberg 1990; Bézivin 2005; Hesse 2006) but are really roles (e.g. Ludewig 2003). A better binary classification would be (Gonzalez-Perez and Henderson-Sellers 2007) backward-looking or forward-looking (Fig. 3.2). Hesse (2006) suggests notation that would improve Kühne’s (2006a) in this regard. Seidewitz (2003) talks of a specification model or just a specification—which relates to the prescriptive role. He also notes the descriptive role of a model but comments that this is less common than its use as a specification (p. 27). Any one model may be used descriptively or prescriptively for different contexts and different purposes (e.g. Seidewitz 2003).

3.3 Interpretive Mappings The interpretive mapping proposed by Gonzalez-Perez and Henderson-Sellers (2007)—see Fig. 3.3—is different since it refers to whether any particular mapping from element a in set A to set B results in a single element b (isotypical) or to a set whose elements exemplify the kind of SUS entities that can be mapped to the model element (prototypical) or in a set B0 given declaratively, i.e. an intensional definition (metatypical).

3.3 Interpretive Mappings

Model

37

pentagon

SUS

Fig. 3.3 Examples of isotypical, prototypical and metatypical interpretive mappings. A circle is shown to have an isotypical mapping. The shaded square on the model is an example (prototype) for any square in the SUS. The declaration of pentagon in the model is metatypically mapped to all possible pentagons in the SUS (after Gonzalez-Perez and Henderson-Sellers 2007)

Gonzalez-Perez and Henderson-Sellers (2007) comment that, in the UML, for example, isotypical and prototypical mappings are sometimes confounded. Between layers, OMG products generally adopt metatypical mappings (GonzalezPerez and Henderson-Sellers 2007)—actually a specific kind of metatypical mapping: the instance-of relationship.

3.4 Theories and Layered Architectures A theory is a means of deducing new statements about the SUS from statements already in the model (Seidewitz 2003). This can be considered either to extend the model or to determine whether the model conforms to the theory, i.e. all statements in the model are consistent with each other. Seidewitz also notes that for a modelling language (ML) the ‘theory’ is the semantics of the ML, while Ludewig (2003) suggests that ‘‘A theory is a special kind of model’’. Seidewitz notes that a model conforms to a theory and that a theory must reside within a single metalayer. In particular, he stresses that the instance-of relationship only has meaning with a theory, i.e. within a specific layer. This totally contradicts the basic notion of strict metamodelling unless we interpret ‘instance-of’ from that strict metamodelling literature by ‘conforms-to’. Layered architectures require a relation or mapping between pairs of layers. As noted in Sect. 2.3.7, the OMG’s use of instance-of between layers is easily confused with the intralayer instantiation relationship. Bézivin (2004) and Gaševic´ et al. (2007) emphasize that the two basic relationships for metamodelling (i.e. multilayer modelling) are representedBy (as in Figs. 1.5 and 1.6) and conformsTo—paralleling the two basic OO modelling relationships of instanceOf and inherits. This leads Bézivin (2004) to propose an MDA-related multi-layer architecture of ‘3 ? 1’ (Fig. 3.4) rather than the traditional four-layer, so-called ‘strict metamodelling’ architecture used in all OMG standards. He notes also that this parallels the 3 ? 1 layers of a programming language, as shown in Fig. 3.4.

38

3 Models

Programming language parallel conformsTo

metametamodel

EBNF

conformsTo

Modelling world

metamodel

Grammar for programming language PL

conformsTo

model

Program P using programming language PL

representedBy

Real world

system

An execution of program P

Fig. 3.4 Bézivin’s (2004) proposal for a 3 ? 1 architecture for modelling/metamodelling together with the parallel in the programming language domain

3.5 Types of Models: Summary While there is some truth in Bézivin’s (2004, 2005) statement that ‘‘everything is a model’’2—aimed at (a) paralleling and updating the old OO adage that ‘‘everything is an object’’ and (b) urging a shift in focus in software engineering to modelling and MDE—such a statement clearly is hard to use in a discriminatory way. A major characteristic of models (in the modelling/metamodelling/ontology context discussed here) is that of type versus token models. In metamodelling, we are seldom concerned with token models whereas in everyday life the opposite is true. Type models change the language of discourse and the level of abstraction; token models do not. Ambiguity often arises in the literature when the simplified phrase ‘is a model of’ is used. Some readers immediately interpret this to mean a type model, often in the context of a multi-layer architecture (Sect. 3.4), while others may read it as a token model. In either case, the writer’s semantics may be contrary to the reader’s. Such misunderstandings have led to many errors and apparent inconsistencies in the modelling literature (see also discussion in Chap. 6).

2

Model here is taken to be what we have called ‘(communicated) model’ rather than (cognitive) model.

3.5 Types of Models: Summary

39

role

Model

Backward looking/ forward-looking

Ontology

System model

open world assumption Role=backward-looking

closed world assumption

Token model backward-looking

Type model

Specification model

Analysis model

forward-looking

backward-looking

Fig. 3.5 A summary of various model types

Secondly, a model may describe an existing state of affairs (backward looking role a.k.a. descriptive) or be a specification of something not yet built (forward looking or prescriptive). Software engineering models are used extensively for both these purposes, sometimes, perhaps confusingly, at the same time. The third characteristic of models is always couched in terms of metamodelling (and hence its discussion is deferred until Chap. 4). The ontological/linguistic debate is often seen as somewhat contentious since it seems to pitch ontological thinking against modelling language approaches, spawning papers on elucidating the differences or on attempts to reconcile what has often been offered as two disparate viewpoints. These characteristics are summarized in Fig. 3.5, which also includes a partition between system models and ontologies (see further discussion in Chaps. 5 and 7). Typically, an ontology has an underlying open-world assumption whereas a system model utilises a closed-world assumption. System models may then be either token models or type models (a disjoint partition), the former usually being backwardlooking while type models (the core of UML designs) can be either forward-looking or backward-looking. Type models are fundamental to understanding metamodels and metamodelling.

Chapter 4

Metamodels

A metamodel has been defined as an explicit specification of an abstraction (e.g. Bézivin and Gerbé 2001) expressed in a specific language. This is similar to Seidewitz’s (2003) definition of a metamodel as a specification model for a class of SUSs, where each SUS is no longer a part of reality but is itself a valid model, i.e. ‘‘a metamodel makes statements about what can be expressed in the valid models of a certain modelling language’’ (Seidewitz, p. 28). It should be stressed that the abstraction needed here is the F-abs kind of abstraction (given in Eq. 2.36) since it creates type rather than token models (see also Eq. 3.4). Thus, the key to metamodels is not simply abstraction (as sometimes suggested in discussions regarding the OMG standards and the OMG architecture of Fig. 1.9) but is the use of a type model (i.e. the abstraction links instances to types not instances to less detailed instances viz. a token model). For modelling languages, this is also equivalent to the linguistic metamodelling discussed in Sect. 5.1. Seidewitz (2003) states the UML standard is a metamodel and that, altogether, the (UML) metamodel includes notation,1 abstract syntax and semantics. Here, we purposefully omitted notation since, for example, the methodology metamodel of ISO/IEC 24744 (2007) and the metamodel that describes the agent-oriented modelling language FAML (Beydoun et al. 2009) both provide a metamodel without a notation (see also Greenfield and Short 2004, Chap. 6; Gonzalez-Perez and Henderson-Sellers 2007). Kühne (2006a) argues that the definition of a metamodel might in the future be extended to include all these things. The authors cited in the preceding two paragraphs all assume an absolute definition of ‘metamodel’ as an M2 layer entity. As noted in Chap. 1, the ontological literature, in contrast, uses the term metamodel in a relative way. For example, Laarman and Kurtev (2010) link a domain ontology (OMG layer M1) with a so-called ‘language metamodel’ (also effectively at M1). This M1 language metamodel is then described by these authors as being an instance of a 1

Although it is common to represent a metamodel by using a graphical notation such as UML, typically as a class diagram, there are other possibilities; for instance, Walter et al. (2009) use text. B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_4, Ó The Author(s) 2012

41

42

4 Metamodels

Fig. 4.1 Ontologies and conceptualizations. The vertical arrows represent instanceOf relationships and the horizontal arrows represent relationships (after Laarman and Kurtev, Fig. 3, Ó2010). Note that the prefix ‘meta’ is used here in a relative sense (in contrast to its use in Fig. 1.9) (With kind permission of Springer Science ? Business Media.)

metametamodel (correct if the term meta is used in a relative sense) (Fig. 4.1). But this metametamodel is clearly equivalent to a ‘metaconceptualization’ or a ‘foundational ontology’ (Fig. 1.8), i.e. OMG layer M2, whereas most software engineers would expect the term ‘metametamodel’ to refer to the M3 layer (e.g. ISO/IEC 1998; Flatscher 2002). Again this clash of subcultures could be one contributory factor to the ontological/linguistic debate described in Sect. 3.1. A metamodel defines a set of concepts and relationships between those concepts. Kühne (2006a) explains meta in terms of an additional application of the operator to which it is a prefix—noting the need for nontransitivity. Thus, a metamodel is a model of models (i.e. the modelling abstraction of Eq. 3.1 is applied twice): MM ¼ aðMÞ ¼ aðaðSÞÞ

from Eq: 3:1

ð4:1Þ

and is essentially two m:1 mappings and is therefore not transitive. An alternative representation, from Eq. 3.4, would be (substituting M for S and MM for M): qðM; MMÞ ! M /t MM

ð4:2Þ

thus, stressing the type model nature of such a classification relationship. While the definition, oft-quoted, of a metamodel as a ‘model of models’ (or ‘‘a model of models expressed in a given language’’ e.g. Laarman and Kurtev 2010) is useful, an additional constraint is that all modelling activities must use type models not token models since we need to exclude transitivity (e.g. Kühne 2006a, p. 378). Kühne (2005) offers a useful heuristic to test the appropriateness of the appellation ‘metamodel’: ‘‘Are the instances of their models not instances of them?’’ In order to formalise Eq. 4.1 further and to define multiple metalayers, Kühne (2006a, p. 377) introduces a relation R that is acyclic (= both irreflexive and asymmetric: Eq. 2.6) and antitransitive with an additional layer-respecting constraint that is needed if strict metamodelling is to be used (see Chap. 1). Keet’s (2007) abstraction layers (Eq. 2.38) have a similar aim.

4 Metamodels

43

Fig. 4.2 Metamodelling stack using reference models (modified from Joualt and Bezivin 2009)

Fig. 4.3 A megamodel representation (after Gaševic´ et al., Fig. 1 Ó2007) (With kind permission of Springer Science ? Business Media.)

RepresentationOf

System {incomplete}

Physical System

Digital System

Abstract System

Using the relation that a model conforms to its reference model (as defined in Eq. 2.55a–c), Joualt and Bézivin (2006) then show how this leads to a multi-layer representation in which a model (called by them a terminal model) ‘‘is a model such that its reference model is a metamodel’’; ‘‘a metamodel is a model such that its reference model is a metametamodel’’; and ‘‘A metametamodel is a model that is its own reference model’’ (Fig. 4.2). Gonzalez-Perez and Henderson-Sellers (2007) formulate a model as being composed of entities called model units, where each entity belongs to a specific model unit kind. Model unit kinds are generally defined as a metamodel. Thus, this approach, too, concludes that UML is a metamodel—although Kühne (2006a) argues the opposite. There is another, specialised type of metamodel, introduced in the literature primarily in the context of model-driven engineering (MDE). A megamodel (Fig. 4.3) is defined as ‘‘a model of which at least some elements represent and/or refer to models or metamodels’’ (Bézivin et al. 2004). This leads Gaševic´ et al. (2007) to propose that a megamodel can also be regarded as an ontology of MDE.

44

4 Metamodels

Fig. 4.4 On the left-hand side, Book is shown as a class that is also an instance of Class, which is impossible within the conventional object-oriented paradigm. On the right-hand side, Book is shown as a class that is specified by the objects obj1 through a forward-looking isotypical interpretive mapping (depicted as a solid arrow) (modified from Gonzalez-Perez and HendersonSellers 2007)

In essence, a megamodel is simply a model at the same level of abstraction as what we have been referring to as a metamodel (M2). The difference is the scope—a megamodel may contain as one of its elements a ‘metamodel’. Favre (2006) describes it as ‘‘modelling-in-the-large’’ and as an ‘‘essential concept to model MDE itself’’. Indeed, some of the diagrams we have used in Chap. 3 (such as Fig. 4.2) are in fact megamodels. However, all of these metamodelling approaches face the same challenge since they all depend axiomatically upon type–instance relationships. Each instance that conforms to class (in the M2 metamodel of UML, for instance) is depicted in a UML class diagram as a class. Yet it is not a class (Fig. 4.4a), it is an instance (Fig. 4.4b). Thus, although in traditional OO modelling, one would assume that a diagram fragment such as Fig. 4.4a would accurately reflect the modelling of books in a library, say, it is not mathematically correct. The Book–Class relationship is described by Eq. 2.3 a set–member or type–instance relationship. For an individual book to be related to the ‘class’ (really instance) called Book in Fig. 4.4, we need one of two additional mathematical features. What appears to occur in practice (Gonzalez-Perez and Henderson-Sellers 2007) is that developers insert an implicit mapping from this instance (called obj1:Class in Fig. 4.4b) to a Book class in the model (M1) domain. Since Book is now a class, it can be instantiated and create a number of objects, book1, book2, etc. of type Book. The other alternative is to abandon the constraints of a type–instance mapping and substitute instead the

4 Metamodels

45

notion of a family of sets, i.e. consider Class not as a set but as a ‘set of sets’, those members (like Book in Fig. 4.4a) being both instances of Class and also types for their own instances (like book1). A set of sets is effectively a powerset, or more likely a family of sets that can be described by Eqs. 2.13 and 2.14 and Book becomes a clabject (Fig. 2.4).

Chapter 5

Ontologies

Aßmann et al. (2006, p. 253), quoting Gruber (1993), state that an ontology is a formal specification of a shared conceptualisation. Since it is both an abstraction and a simplification of some reality (domain of interest), an ontology is also a model (e.g. Nirenburg 2004; Guizzardi 2005, p. 6; Aßmann et al. 2006, p. 256) but one that is descriptive, domain-relevant and static as opposed to a system-focussed model, which does not require any shared understanding nor does it model the whole of the domain (Fig. 5.1). It is widely stated that, while an ontology uses an open-world assumption, a model uses a closed-world assumption (e.g. Aßmann et al. 2006; Atkinson et al. 2006) although some ontologies are based on a closedworld assumption (e.g. Wang et al. 2006). Furthermore, ontologies are always descriptive, never prescriptive (Aßmann et al. 2006, p. 256; Walter et al. 2009) whereas system models may be descriptive or prescriptive or both (see Sect. 3.2 for these definitions). Hence, we can draw an ontology-focussed version of Fig. 1.6 (see Fig. 5.2). The literature on ontologies is diverse and frequently contradictory. In an analysis of the links between metamodels and ontologies (discussed further in Chap. 7), Henderson-Sellers (2011b) concludes that the term ‘ontology’ is variously used to describe a domain-layer ontology or a metaontology a.k.a. foundational ontology. Thus, a foundational ontology is at an equivalent metalevel to a metamodel such as that of the UML; whereas a domain ontology creates a hierarchical description of concepts within a specific domain and is therefore a ‘model’ rather than a metamodel. Henderson-Sellers (2011b) also identifies a number of papers in which, arguably, these two aspects are inappropriately intertwined (e.g. Falbo et al. 2005; Pastor et al. 2008; Dillon et al. 2008). Various authors identify a disparate number of categories and roles for ontologies. For example, Ruiz and Hilera (2006, p. 51), following Guarino (1998), differentiate between high-level ontologies, domain ontologies, task ontologies and application ontologies; whereas Fensel (2004) discusses generic (or common sense) ontologies and representational ontologies rather than high-level ontologies

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_5,  The Author(s) 2012

47

48

5 Ontologies

Fig. 5.1 Ontologies and system models can both be considered as kinds of models

Fig. 5.2 Ogden and Richards’ triangle applied to domain ontologies

Cognitive ontology

reifies

Ontology representation or Domain Ontology

abstracts

represents

SUS=domain (Figure 1.1)

(see Ruiz and Hilera 2006, p. 52, Fig. 5.3). Nodine and Unruh (1998) propose the use of a service ontology (containing ‘nouns’ to indicate what an agent can do and ‘adjectives’ further describing and constraining the capabilities of an agent) for designing agent-oriented systems. Other classification structures are to be found in the discussion of Ruiz and Hilera (2006) and are outside the scope of this book. Task, service, application, etc. ontologies are all fine-grained and are not discussed further here, since the mathematics applicable to them can be directly deduced from the mathematics of domain ontologies. High-level ontologies were argued by Henderson-Sellers (2011b) to be at a different metalayer and will thus be discussed here along with domain ontologies. A (domain) ontology is a model of the knowledge in a specific domain of interest, e.g. the domain of wine (Noy and Musen 2004), genes (Smith et al. 2003). Tairas et al. (2009) distinguish two properties: a vocabulary on entities in the domain and a body of knowledge about the domain (obtained from the relationships between the entities represented in the vocabulary) A domain ontology is typically represented by a hierarchically organised class diagram (Fig. 5.4) or an indented list (Fig. 5.5), as in Noy and Musen (2004) or as a list of names and definitions in plain text, as in, for example, Needleman (1998). Other means of representation include a language like RDF or OWL. It should also be stressed that the ontology refers to the concepts, which should be language (or representation)

5 Ontologies

49 Guarino

Domain independents

of High Level

Fensel

Generic Representational

of Domain Domain dependents

of Domain

of Tasks

of Applications

of Methods & Tasks

+ G e n e r a l i t y -

Fig. 5.3 Kinds of ontologies according to the generality level (after Ruiz and Hilera, Fig. 2.1  2006) (with kind permission of Springer Science ? Business Media.)

Fig. 5.4 Version of Noy and Musen’s (2004) wine hierarchy

Wine Maker:Winery

Blush wine

White wine

Red wine

Merlot

Chianti

independent; the representation in English or French or … words is merely a convenience (e.g. Nirenburg 2004). Some ontologies can be very large—for example, the gene ontology in 2003 contained nearly 14,000 terms and over 11,000 informal definitions (Smith et al. 2003). These sets of terms are sometimes called ‘metadata’ (e.g. Needleman 1998), thus implying (in the context of Fig. 1.9) that data belong to M0 and thus metadata to M1, i.e. equivalent to a class model in

50 Fig. 5.5 As Fig. 5.4 but expressed as an indented list

5 Ontologies Wine White wine Blush wine Red wine Merlot Chianti

object-oriented terminology. The use of the prefix meta here simply implies relative and not absolute level naming in contrast to OMG standards, which tend to a more absolute naming of M2 as the metamodel layer. High-level ontologies, also known as ‘foundational ontologies’ or ‘upper ontologies’ or ‘metaontologies’, are specification models1 of domain-independent ontological categories that form a basis for more detailed domain analysis (Guizzardi and Wagner 2005, p. 110). Examples are the Bunge-Wand-Weber (BWW) ontology (Wand and Weber 1988, 1990, 1993, 1995; Wand 1996) and the Unified Foundational Ontology (UFO) (Guizzardi and Wagner 2005; Guizzardi et al. 2007). That these correspond roughly to the OMG M2 metamodel layer is evidenced by (1) the use of the BWW model, with its definitions of Thing, Property, Class, etc. (Wand and Weber 1995; Weber and Zhang 1996), to evaluate the ontological quality of modelling languages (Opdahl et al. 2000; Opdahl and Henderson-Sellers 2002) in which direct equivalences were sought between BWW constructs and the modelling language (UML and OML) constructs; and (2) the statements by the originators that UFO is a MOF/UML model, i.e. a model within the M2 layer of Fig. 1.9. A portion of the UFO is shown in Fig. 5.6, clearly showing the high-level (metamodel) elements of Entity type, Sortal type and so on. Viewed as class diagrams, and remembering that an ontology is a (specialised) kind of model (Fig. 5.1), we can seek a relationship between a high-level ontology and a domain ontology. The ontological literature remains somewhat equivocal. For example, Kiryakov et al. (2001), while recognising ‘‘a significant real difference between the two types of ontologies’’ (viz. domain-specific and upper level), note that this separation relies more on intuition than formal mathematics, citing OntoMap as possessing an ‘‘unfixed meta-modelling architecture’’. They, and others (e.g. Aßmann et al. 2006), attempt to use a combination of inheritance and instantiation, claiming that extensive use of instantiation avoids several multiple inheritance structures, thus adding clarity to the ontology’s depiction. However, it is unclear whether such simplifications are advocated just within a single domain ontology or between domain and upper level ontologies. The OMG Ontology Definition Metamodel (ODM) standard (OMG 2005b, 2009) gives reasons why UML is unsatisfactory for documenting ontologies (see also Djuric´ et al. 2005; Colomb et al. 2006; OMG 2009)—hence it needs to create a new standard: viz. ODM. It notes some missing concepts in the UML—in 1

Note that the modes of depiction of a high-level ontology are the same as noted above for a domain ontology: as a class diagram, an indented list or plain text.

5 Ontologies

51

Fig. 5.6 Elements from the UFO of Guizzardi and Wagner (2005). All partitions are disjoint but not complete (in this diagram fragment)

Universal a.k.a. Entity type

Endurant universal

Perdurant universal

Moment universal

Substantial universal

Sortal Type

Mixin Type

Rigid Sortal

Anti Rigid Sortal

BaseType

RoleType

particular, the treatment of disjoint classes, set intersection and set complement. This, they argue, prevents the use of automated reasoning for UML models, which (they argue) is important for ontologies. They argue that ontology instances may also be required without the prior definition of a class—not permissible when using UML, since UML depicts classes primarily and only secondarily supports the notion of an object. ODM is an M2 layer model, as illustrated in Fig. 5.7 from which can be created a large number of domain-specific ontologies (M1). In parallel to the MOF/UML hierarchy, the lowest layer (M0) contains instances of those (M1) domain-specific ontologies. A particular kind of domain ontology is a reference ontology (Guizzardi 2005, p. 90—see also Guarino 1998)—also known as a domain reference ontology. In contrast, Kazmierczak and Milton (2005) use the term reference ontology for the philosophical meaning of ontology, i.e. the shared conceptualisation (using ‘conceptualization’ in the ontological sense as also used here), as noted above (Guarino 1998). In a very different vein, Menzel (2003) equates a reference ontology with a foundational ontology, thus illustrating once again the very disparate semantics of terms used in this research area. Figure 5.6 is essentially a UML class diagram in which the partitions are disjoint. It can also be regarded as the ontological parallel of a linguistic

52

5 Ontologies

Ontology metamodel a.k.a. foundational ontology

M2

e.g. OMG ODM

a.k.a. upper-level ontology

Generic ontology; Domain-specific ontology

M1 e.g. hierarchy for banking

= schema/model

Instances of domain-

M0

specific ontology

Fig. 5.7 Three-layer ontology architecture suggested by the ontology definition metamodel of the object management group (after Henderson-Sellers 2011b)

Fig. 5.8 Euler diagram showing several instances of the BaseType partition, which is disjoint to the RoleType partition

metamodel such as that of the UML. Thus, we can apply type–instance semantics, which allow us to generate instances of these like Person:BaseType and Customer:RoleType. Figure 5.8 shows how these instances belong to different partitions of the Sortal Type (expressed as a set), although instances, we wish to interpret them as ‘M1’-level sets (model-level classes). To do this, we effectively map the Person:BaseType (an instance) to a Person class, using the ‘pattern’ depicted in Fig. 4.4.

5 Ontologies

53

Fig. 5.9 The necessary introduction of a SubTypeOf relationship to the UFO (diagram kindly supplied by C. Gonzalez-Perez)

In much of the ontological literature, it is argued that it should be valid to have a subsumption relationship between a role type such as Student and a base type such as Person—a proposal also found in ER modelling. The argument seems to rest on both ‘common sense’ and/or a common use of language point of view (Guizzardi, 2011, ‘‘personal communication’’) and the important need for a student to have an identity. The RoleType of the UFO, for instance, can carry but not supply identity whereas the BaseType can provide it. In this example, students need to have identity not because they are students but because they are necessarily also persons (or another appropriate base type) in addition to their role as students. This desire can lead to a simplistic acquisition of identity, by permitting a role type to be able to be a subtype of base type. Thus, in the UFO, we have a definition for RoleType as ‘‘sortal type that is anti-rigid and for which there is a relationship type such that it is the subtype of a base type formed by all instances participating in the relationship type [OntoClean:role].’’. Although only stated textually by these authors, this definition requires an addition in the metamodel of a subsumption relationship between the metaclasses (Fig. 5.9). This then permits the subsumption relationship from Student to Person, as shown. Without such a relationship, we can use set theory to investigate other options. If we wish to have Student as a subtype of Person (as in Fig. 5.9 bottom), then we conclude that an individual student (who is also a person) is a member of the set

54

5 Ontologies

Fig. 5.10 Class diagram depicting student as an instance of RoleType and person as an instance of BaseType together with mappings from these instances to corresponding classes

Fig. 5.11 Euler diagram mappings from the student: RoleType instance to the student subset of the person set, itself mapped to the person: BaseType instance

defined by Person. However, Person is an instance of BaseType, i.e. it is both an instance and a class (in these two different contexts). In contrast, Student is an instance of RoleType (Fig. 5.10). For Student (as a class) to be a subtype of Person (as a class), we need some mapping from the Student instance in the RoleType set to the subset of Person representing the Student subtype (Fig. 5.11)—as well as the aforementioned mapping between Person as a set (class) and Person as an instance (i.e. a member of the BaseType set). A resolution might be to discard the axioms of OO modelling, particularly the insistence on type–instance relationships, and consider, either as extensions or as new theory of metamodelling, constructs based on the acceptance of sets of sets (families of sets) which are outside of the type–instance constructs currently used or to include language use concerns (see Chap. 7) that link models to language elements rather than to metamodel elements.

5.1 Linguistic and Ontological Metamodelling The proposed orthogonality of linguistic and ontological metamodelling, nicely described in, for instance, Atkinson and Kühne (2003) has spawned great debate (e.g. Gaševic´ et al. 2007; Gonzalez-Perez and Henderson-Sellers 2008; Atkinson et al. 2009; Laarman and Kurtev 2010). Linguistic metamodelling derives from the

5.1 Linguistic and Ontological Metamodelling

55

Fig. 5.12 Typical framework proposed in the literature to explain ontological versus linguistic metamodelling. Here L denotes linguistic layers and O ontological layers

adoption (in software engineering circles) of the four-layer architecture of Fig. 1.9, in which instanceOf is said to relate elements in two adjacent layers (a type modelling approach—Sect. 3.1). Since the M2-M1 type–instance relationships were embodied in the development of the UML—a modelling language—this soon gained the appellation of linguistic metamodelling. This is in contrast to examples such as those first expounded by Atkinson and Kühne (2003) that described a kind of metamodelling that could not be fit into the OMG architecture (Fig. 5.12). In this kind of metamodelling, it is argued by these authors, Breed is ‘meta’ to Collie. At the same time, it is generally agreed that Collie is a class, i.e. an (linguistic) instance of the class Class in the UML (itself a M2 metamodel). What is controversial is the logical supposition (Fig. 5.12) that Breed should be a linguistic instance of the class Class (a.k.a. Metaclass) in the M3 model (in OMG parlance, the MOF). Alternatively, one might suppose that if Breed is meta to Collie, then Breed is a metaclass. In UML, a metaclass belongs to the M2 layer and would be commensurate with M2-level classes such as Class, Association, etc. Clearly, no one could expect to find a class such as Breed as part of a general purpose language like the UML. This paradox has been explored most recently from a language use perspective by Eriksson et al. (2012). One consequence of the ontological hierarchy of Fig. 5.6 is that a moment universal type, defined as a non-sortal type that cannot have direct instances (Guizzardi and Wagner 2005), cannot be the super type of a base type and, furthermore, that an

56 Fig. 5.13 Double instance of chain of three classes from Atkinson et al. (2009) IEEE reproduced with permission

5 Ontologies

ITProfessional

Profession instanceOf

BillGates instanceOf

instance must be that of a sortal type, not of a moment universal type. Thus, Lassie (Fig. 5.12) cannot be an instance of Collie since these are moment universal types and not sortal types. In other words, what is missing in diagrams such as Fig. 5.12 is a base class—here, Dog. Instead, a Moment Universal masquerades (inappropriately) as a Base class. Neglect of such ontological and language use basics has led modellers to highly inappropriate arguments and positions. Figure 5.12 depicts the need in ‘ontological metamodelling’ for a ‘chain’ of two (or more) type models. This introduces a serious concern: that a type model links a type and objects conformant to that type—a relationship only valid over two contiguous metalayers (as discussed earlier with respect to Fig. 4.4) unless traditional OO modelling is replaced by, for instance, powertype modelling. Furthermore, the semantics of any such three classes must be checked for consistency. An example where such checking has been erroneously omitted is found in Kühne (2006a, Fig. 4) and in Atkinson et al.’s (2009) Fig. 1—the latter reproduced here as Fig. 5.13. The right-hand instanceOf is clearly correct but one must challenge the proposal that an IT Professional is an instance of Profession. Clearly, one could accept as an alternative that an IT Professional is an instance of a set of Professionals; or that an instanceOf Profession could be the IT Profession—but then clearly Bill Gates would not be an instance of this modified ITProfession class. Furthermore, if we now introduce the foundational ontological classes of Fig. 5.6, we can see that Person is a base type and Profession is a mixin type whereas Professional (and hence IT Professional in Fig. 5.13) is a role type. One differentiating test for a base type is to ask if all the characteristics of an individual conforming to the definition of the type in question will persist for the individual’s lifetime. If so, it is likely to be a base type; if not, it is a non-sortal type and thus cannot be definitional of instances. Thus, in Fig. 5.13, the individual (Bill Gates) can only be an instance of a base type (such as Person) not an instance of a non-sortal type (here, IT Professional). Secondly, we have in this figure a statement that IT Professional (a person taking this role) is an instance of a type called Profession (a non-person). Again, the base types are not compatible. Thirdly, as noted above, we have a double-instance link, which is not possible since, even if the sortal/non-sortal issue were to be fixed, an instance of an instance has no meaning when interpreted with normal type–instance semantics. Figure 5.14 redraws Fig. 5.13 in an ontologically acceptable manner. Typical examples, even for ontological metamodelling (Fig. 5.15), appear to ignore this problem. Despite two type model relationships, visually we see that Collie (a class) is an ontological instance of Breed (also a class). In set theoretic terms, this can only be valid if Breed is a power set (or more strictly a family of

5.1 Linguistic and Ontological Metamodelling

57

Fig. 5.14 Redrawing of Fig. 5.13

has a

Profession

Person

Instance of

Instance of

has as a role

Bill Gates

IT Profession

sets2—see Sect. 2.1) (Fig. 5.16) such that each element of the Breed set is a partition of a Dog set (Fig. 5.17). The Breed set in this example has only three elements—but each element is itself a set containing other elements satisfying the set’s predicate—see Eq. 2.4. Figure 5.18 summarises this using class notation. The left-hand side corresponds to the (ambiguous) Fig. 5.15 whereas the powertype structure that is implicit in Fig. 5.16 together with Fig. 5.17 is shown explicitly on the right-hand side of this diagram. Although such powertype patterns (HendersonSellers and Gonzalez-Perez 2005a) are seen more frequently in metamodelling treatises (e.g. Gonzalez-Perez and Henderson-Sellers 2006b, 2008), they have in fact a long history in object modelling (e.g. Martin and Odell 1998), as noted earlier, where they are used to represent relationships between modelling elements within a single (meta)-layer. Notwithstanding the concerns raised in the previous paragraph, several authors attempt to formalise the difference between linguistic metamodelling and ontological metamodelling, as first described by Atkinson and Kühne (2003). For example, based on the type modelling as expressed in Eq. 4.2 and the introduction of l as the interpretation function (mapping) (see Fig. 1.5), Kühne (2006a) gives formulae for both linguistic and ontological metamodelling (see also Fig. 5.19): (a) linguistic

eClt T , e 2 eðlðTÞÞ

ð5:1Þ

which states that the instance is an element of a set which is (part of) the extension of a representation of the type eClt T , iðlðTÞÞ ðeÞ

2

ð5:2Þ

In software engineering, this is referred to as a powertype, based on Odell’s (1994) original nomenclature plus the observed consistent usage of this terminology, even if marginally inaccurate, in the decades since.

58

5 Ontologies typeModelOf

typeModelOf

O0

O1

t Lassie

ontological instanceOf

O2

t Collie

Breed

ontological instanceOf

Fig. 5.15 Ontological metamodelling (after Kühne 2006a, Fig. 4 2006) (with kind permission of Springer Science ? Business Media.)

Fig. 5.16 The three elements of the Breed set, i.e. Breed = {Collie, Dachshund, Labrador} or, more strictly, Dog/Breed = {CollieDog, DachshundDog, LabradorDog} which more clearly suggests a generalisation from Collie, Dachshund and Labrador to the Dog class (set)—see Fig. 5.17

Set: Collie

X

Set: Labrador

Dachshund partition Collie partition

Dachshund instances

X X

X

X X

X

Collie X instances

X

X

X

X

Fig. 5.17 The Dog set with its three partitions. Each partition contains many instances that belong both to that partition and to the overall Dog set

Set:

X Dachshund

X

X Labrador instances

X X

X

Labrador partition

which states that the model element satisfies the intension of the referenced concept (b) ontological

eCot T , l ðeÞ 2 eðlðTÞÞ

ð5:3Þ

which states that the referenced domain element must be in the extension of the concept referenced by the type eCot T , iðlðTÞÞðlðeÞÞ

ð5:4Þ

5.1 Linguistic and Ontological Metamodelling oft-quoted Breed

59

is really Breed

Dog

Instance - of

Collie

Collie

Lassie

Lassie

clabject

Fig. 5.18 A typical model used to explain ontological metamodelling (left-hand side) and an alternative using powertypes (right-hand side)

Fig. 5.19 Ontological versus linguistic instantiation (after Kühne 2006a, Fig. 5 2006) (with kind permission of Springer Science ? Business Media.)

which states that the referenced domain element satisfies the intension of the referenced concept. We should also note that Eqs. 5.3 and 5.4 were independently derived by Gaševic´ et al. (2007) by extending Favre’s (2004) megamodel (Fig. 4.3) to explicitly include extensional and intensional systems (Fig. 5.20).

60

5 Ontologies RepresentationOf

System {incomplete}

extension

Physical System

Digital System

intension

Abstract System

1

{intension=null}

Set (Extensional) System

0..1

Intensional System

Fig. 5.20 Extended megamodel to include extensional and intensional systems (after Gaševic´ et al., Fig. 8 2007) (with kind permission of Springer Science ? Business Media.)

However, as noted above, linguistic metamodelling is really a conformance issue, where the instantiation would be better replaced by the sem and meta relationships (Fig. 2.11). True instantiation, here called ontological metamodelling, is within a single (linguistic) metalayer because (1) all elements (e.g. dog, breed) use the same domain ontology (2) all elements are describable with the one language (3) all have meaning within the one theory, i.e. a single semantics The linguistic definitions (Eqs. 5.1 and 5.2) were derived by assuming that the Object class in Fig. 5.19 represents the language, K, which in turn has an extension consisting of software objects (instances)—this assumption appears not to be valid in the light of our earlier discussion. Furthermore, if we apply the mathematical thinking of these two equations to the upper part of Fig. 5.19, we find that, in parallel with Lassie [ e (l (Object)), we must deduce that Collie [ e (l (Class)), Since the representation of both Class and Object is the language, K, we deduce that the language has in its extension both Lassie and Collie (i.e. ontological type and ontological instance). In general, the identification of a type–instance pairing suggests ‘metamodelling’—but this is clearly not the case here in the sense of the OMG metamodelling hierarchy of Fig. 1.9 since there is no change of domain. Finally, ontologically, Collie is an instance of Breed, which is itself a Moment Universal, a non-sortal type (Fig. 5.6). It therefore cannot be instantiated to Lassie since Lassie is an instance of a sortal type; sortal and nonsortal types being distinct partitions in a set (Fig. 5.8). A resolution is obtained when we introduce theories of language use (see later discussion of Fig. 7.8). Thus, an ontological ‘metaclass’ actually belongs to the same domain as the ontological ‘classes’, i.e. they all represent concepts in the (single) domain

5.1 Linguistic and Ontological Metamodelling

61

Fig. 5.21 Portion of the UFO high-level ontology of Guizzardi and Wagner (2005). Note that in the UFO, Entity Type and Entity are related through a generalisation relationship and an association

Universal

Substantial Universal

Moment Universal

Individual

Substantial

Moment

Fig. 5.22 The four-category ontology of Laarman and Kurtev (Fig. 4, 2010) (with kind permission of Springer Science ? Business Media.)

ontology. This means that not only classes but also metaclasses in any ontological model/metamodel (such as in Fig. 5.18) are all equally needful of conformance to some element in the linguistic metamodel—a conclusion also of the study of Gaševic´ et al. (2007). It should be noted that conformance is the critical defining relationship between model and metamodel—no such relationship exists for any example, such as that on the left-hand side of Fig. 5.18, utilised in support of ontological metamodelling. Several authors (e.g. Kühne 2006a, p. 380; Laarman and Kurtev 2010) note that linguistic metamodelling defines the form while ontological metamodelling is concerned with content. However, based on the new analysis provided here, it would appear to be a furphy. It revolves around a confounding of instantiation and conformance (see Sect. 2.3.5) and a neglect of the work of ontologists, such as Guizzardi (2005), Guizzardi and Wagner (2005), who describe a metaontology (a metamodel for use in describing ontologies). The elements of such an ontology must include concepts such as perdurant, endurant, set, sortal type and mixin type

62

5 Ontologies

(Fig. 5.21) or, more simplistically, Substantial and Moment as applied to Individuals or Universals (Fig. 5.22: Laarman and Kurtev 2010) whereas Atkinson and Kühne would have these metaontologies to also include Breed and all classes of that ilk, which is clearly undesirable. Furthermore, since true instantiation (as here) must be confined within a single (linguistic) metalayer, it is clear that ALL classes in published examples, such as in Fig. 5.18, belong to the model domain (M1: Fig. 1.9) or the Method Domain of Fig. 1.10. True ontological modelling is described at the beginning of this chapter). In contrast, Bézivin and Gerbé (2001) describe these two kinds of model as either local or global, where the latter corresponds to the meta relationship (see above). In summary, we recommend the use of Bézivin’s ‘sem’ relationship for conformance between a model and its metamodel; Kühne’s linguistic instantiation for the classification (type–instance) relationship between metamodel and model; and InstanceOf for Kühne’s ontological instantiation. We also need to ensure that the foundational ontology of, for instance, Fig. 5.6, is used in order to avoid incorrect generalisation/specialisation hierarchies and incorrect type–instance relationships from being incorporated into any model.

Chapter 6

Modelling Languages

For a (conceptual) model to be communicated to others, it is necessary to represent it in some way (Fig. 1.3). In much of software engineering and conceptual modelling, such a representation is through the application of a graphically based modelling language (ML)—a language appropriate for each of the three domains shown in Fig. 1.10 (see Fig. 6.1). Such an artificial language has many of the attributes of a natural language in terms of possessing both syntax and semantics. Together these form the specification or definition of the modelling language. The modelling language can then be used to generate ‘modelling sentences’, i.e. models that conform to both syntax and semantics. In some authors’ view, the language specification is purely a collection (set) of these models; while others view a language as a combination of specification and sentences (Fig. 6.2). These two conceptualisations of a language, be it natural or artificial (e.g. modelling), effectively create two schools of thought (see also later discussion with respect to metamodels in Sect. 7.1). Figure 6.2 summarises the two approaches: (1) that a language comprises its specification and is used to specify a set of sentences; (i) that a language is defined solely in terms of the set of all possible sentences it can be used to create. Which of these assumptions is being used in any particular presentation in the literature is often not stated so that the reader may not be aware of which megamodel of Fig. 6.2 is being built upon. For a natural language, assumption (ii) may be appropriate since natural language researchers are trying to elucidate the ‘rules’ of a language from its existence whereas for modelling languages, we are designing these languages ab initio. We identify/create the ruleset before identifying particular models (the ML parallel to sentences in a natural language) Indeed, language in broad terms can be considered as either language rules (definitional) or language-in-use (empirical/observational). In the context of software engineering languages, Eriksson et al. (2012) combine these two usages of the word ‘language’ such that when we discuss modelling languages below we can sometimes mean the combination and sometimes language definition or language

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_6,  The Author(s) 2012

63

64

6 Modelling Languages

Fig. 6.1 Three domains defined by the category of users. For models created in any one of these domains, a modelling language (ML) is used. That ML is often the same for the three layers and can be defined in one of a number of ways

Fig. 6.2 A (modelling) language may be considered a to consist of both a language specification and a set of sentences or else, b, the language could be envisaged as a synonym for its specification such that the language is defined s a set of sentences

use. Figure 6.3 also notes that there is a conformance or linguistic-instance-of between these two ‘parts’ of language and, importantly, that it is symbols in the language-use portion that have a correspondence to things in the real world. One consequence is that we can consider that a language, K, has both an intension, i(K), defined by its specification or language definition, and an extension, e(K), in which the modelling language is equivalent to ‘the set of all sentences’ in Figs. 6.2 and 6.3.

6 Modelling Languages Fig. 6.3 A basic multi-level framework based on language use rather than on the strict metamodelling embodied in the architecture of Fig. 1.9

65

Language definition a.k.a. ‘language’ as in UML

Language use a.k.a. ‘language’ as in a set of sentences as in Chomsky

conformance or linguistic instance -of relationship

correspondence relationship

Real world ‘Things ’

A modelling language is thus a means of expressing statements in the model (Seidewitz 2003, p. 28), where we make the assumption that ‘expressing’ means ‘visualizing’ or otherwise ‘communicating’ (Fig. 1.6). It is generally defined to consist of an abstract syntax and semantics (e.g. Alagar and Periyasamy 1998, p. 13; Frank 2008, 2010) and (arguably) pragmatics and concrete syntax a.k.a. notation (e.g. Karagiannis and Kühn 2002; Seidewitz 2003). Many authors exclude the notation from being an intrinsic part of a modelling language, arguing that concepts are independent of any particular mode of representation, e.g. Sowa (2010). However, Silva Parreiras et al. (2007) then break down the syntax into (1) concrete, (2) abstract and (3) notation (graphical or lexical) and identify semantics as being either (a) formal (e.g. denotational) or (b) informal (e.g. natural language). The (abstract) syntax of a formal language, such as an ML, can be described in one of several ways, e.g. by a metamodel (e.g. Greenfield and Short 2004, Chap. 8; Saeki and Kaiya 2007; Laarman and Kurtev 2010) or as a grammar. A grammar, for example, represents a set of rules to illustrate how its basic elements, called the ‘alphabet’, are used to construct ‘sentences’—use is often made of ‘rewrite rules’ for formal grammars. We could therefore draw a megamodel (as in Fig. 6.4) depicting a natural language as consisting of a number of linguistic concepts and grammatical rules. (Two exemplar concepts of Noun and Verb are shown in this figure.) Figure 6.4 could be regarded as placing some of its classes at the OMG M2 level and some at M1. However, the OMG Mx levels refer to the relative positioning of various kinds of models (Fig. 1.9) and not any language elements or characteristics. Nevertheless, there is some parallel in terms of language use versus language definition (Fig. 6.3) such that allocation to a ‘layer’ could be useful to aid the reader’s comprehension. Consequently, rather than labelling these

66

6 Modelling Languages

Fig. 6.4 Megamodel of the component parts of languages

language-related layers as Mx, we will refer to them as Lx. This L2 megamodel (in Fig. 6.4) can then be used to create conformant nouns, verbs (etc.) and grammatical valid sentences (L1). Bézivin (2005) notes that ‘‘[s]ome metamodels may be similar to grammars’’ while noting (as do Greenfield and Short 2004, p. 298) that metamodels are generally more versatile than grammars. Greenfield and Short (2004, Chap. 8) compare metamodels with context-free grammars (often represented in BNF notation) as two options for defining the abstract syntax of a language. Indeed, they note (p. 291) that a ‘‘metamodel mimics the BNF definition’’. More complex constructions are called well-formed formulae (wffs) (Alagar and Periyasamy 1998, p. 43) and figure in the definitions of several logics (see Figs. 1.13 and 1.14). Condensing the main elements of Fig. 6.4 into a format more like our other diagrams, we can see that a language syntax consists of a set of symbols plus a set of rules (e.g. grammar). The set of symbols is used to create words and sentences that can be confirmed as valid only if they conform to the rules (Fig. 6.5). If we interpret Figs. 6.4 and 6.5 in terms of (software engineering/information systems) modelling languages, such that ‘Valid sentences’ is replaced by ‘Valid models’ and the Context-Free Grammar may have a metamodel as an alternative (see also later discussion of Fig. 7.4), then we can argue that a modelling language (at least the specification of its syntax) is actually a set of predicates (rules) that define whether or not any individual model can validly be accepted as a member of the set of all possible models (Fig. 6.6). Let Q be the set of all valid models and

6 Modelling Languages

67

Fig. 6.5 Natural language syntax as a set of symbols and rules

Fig. 6.6 Modelling language syntax viewed as a set of symbols and associated rules (a modelling parallel to Fig. 6.5)

R be the set of all modelling language predicates (rules in Fig. 6.6). Then we can rewrite Eq. 2.32 as eðQÞ ¼ fxjPðxÞg; where PðxÞ ¼ iðQÞ  R

ð6:1Þ

Furthermore, we can embed Fig. 6.6 into Fig. 6.3 such that the modelling language definition is linked to its syntax augmented by its semantics and the set of

68

6 Modelling Languages

Fig. 6.7 Two facets of a modelling language: definition and use. The language is defined in terms of syntax plus semantics. Syntax consists of rules and symbols, the rules being defined by a metamodel or a grammar (or equivalent). Language use is of a number of symbols put together in such a way as to conform to the rules of the language

valid models is equated to the language use partition shown in Fig. 6.3—this is depicted graphically in Fig. 6.7. The semantics of a language give meaning to the symbols (i.e. alphabet) and hence to sentences, wffs, etc. The vocabulary of the language may be supplied by the ontology and/or the metamodel (e.g. Aßmann et al. 2006, p. 257). Guizzardi (2005, p. 36) describes this in terms of the ‘ontological commitment’ of a given language; that is, a description of the specification of the conceptual model underpinning the language. This represents the world view or Weltanshauung embodied in the language. Without semantics, the appellation of ‘modelling language’ is difficult to justify—one reason that several authors (e.g. Harel and Rumpe 2004) argue that UML is not a modelling language. Although Corcho et al. (2006) quote Neches et al. (1991) as describing an ontology in terms of its vocabulary, Ruiz and Hilera (2006, p. 51) stress that, since it is essential that an ontology is natural language independent, it should not be equated with a vocabulary (or any other construct in a particular natural language). On the other hand, as noted by Gruber (1993) a vocabulary is useful to represent an ontology. Guarino (1998) uses this notion to differentially describe an ontology linked to a representation in a specific vocabulary. An ontology could also be extended to provide the facilities of a thesaurus (e.g. Saeki and Kaiya 2007). Aßmann et al. (2006) also note that an ontology has the property of upholding the so-called open-world assumption, i.e. anything not explicitly expressed by an ontology is unknown. Following the discussion of model units and model unit kinds above, a modelling language is defined (Gonzalez-Perez and Henderson-Sellers 2007) as

6 Modelling Languages

69

Fig. 6.8 Connections between cognitive constructs and their depiction. (Rectangles indicate concrete artefacts and clouds cognitive entities)

‘‘an organized collection of model unit kinds that focus on a particular modelling perspective’’.1 This is said to be a similar definition to that of an idealised cognitive model (Lakoff 1990, Chap. 4). Gonzalez-Perez and Henderson-Sellers (2007) show that there is a metatypical mapping such that the model unit kinds in a language actually represent the associated model units in the model. Thus, a modelling language not only visualises but also represents all possible models that can be constructed from these model kinds. However, as noted earlier, it is easy to confuse a model (concepts/statements) with the visual representation (or ‘visualization’) of that model (e.g. class diagrams, differential equations, graph), e.g. Gonzalez-Perez and Henderson-Sellers (2007). Clarification can be gained by reconsidering Figs. 1.6 and 1.2b and focussing on the reifies relationship. Figure 1.2b states that a conceptualisation is depicted by the use of a (modelling) language (Fig. 6.8) or, equivalently when using the terminology of Fig. 1.6 that a conceptualization ‘is reified by’ the modelling language. Similarly, Fig. 1.6 states that a cognitive model (an abstraction of the SUS: Fig. 1.3) is reified by a communicated model (Fig. 6.8). In both cases the ‘reifies’ relationship is given by Eq. 2.20 (and depicted in Fig. 2.5). In the former case, we are setting the context (SUS), from Fig. 1.1, as the totality of reality (for a general-purpose modelling language) or a specific domain of interest (for a domain-specific modelling language). In the latter case, the SUS is that of a single system. A conceptualisation, as in Fig. 6.8, refers to the scope of reality or a domain (as depicted in Fig. 1.1) whereas a cognitive model refers to one particular situation, i.e. a single system. It is thus tempting to invoke a type–instance relationship between the conceptualisation (the ‘type’) and the cognitive model (the ‘instance’)—and similarly for modelling language and communicated model. Indeed, an instance-of relationship is depicted by Guizzardi (2005, 2007), 1

This particular modelling perspective could be equated to the idea of an ontological commitment, as discussed above.

70

6 Modelling Languages

Fig. 6.9 Relations between Conceptualisation, Abstraction (Cognitive model), Model and Modelling Language (after Guizzardi 2007). Reprinted with permission from IOS Press

Fig. 6.10 Relationships between conceptualisation, cognitive and communicated models and the model language. We should note here that, while this is similar to Figs. 1-1 and 2-6 of Guizzardi (2005), the instance-of relationship only works in a set-theoretical context if ‘modelling language’ is taken to mean a set of models. We also use ‘is reified by’ (Fig. 1.6) rather than ‘isrepresented by’ (Fig. 1.3)

reproduced here as Fig. 6.9. However, from a set theory viewpoint, this is only really tenable if a language use meaning for ‘language’ is adopted (Chomsky 1956, 1959 and see Figs. 6.2 and 6.3). Figure 6.10 redraws Fig. 6.9 with the reification terminology of Fig. 6.8 and omitting (simply for clarity as discussed earlier in the book) the inverse interpreted-by associations. Figure 6.10 is a pattern initially created to link models and modelling languages in the software engineering sense (layers M1 and L2). However, from an ontological viewpoint, this pattern is equally applicable at the OMG M0/L1 layer (Fig. 6.11). For a specific real-world genealogy domain, Guizzardi (2005, 2007) takes, as an example, the model of the state of affairs (a model of the individuals in

6 Modelling Languages

71

Fig. 6.11 Applying the pattern of Fig. 6.10 to the application domain of genealogy (modified from Guizzardi 2005)

Fig. 6.12 Differentiating between a model and its visualisation (the ‘communicated model’)

the real world) and its specification [labelled ‘(communicated) model’ in Figs. 6.10 and 6.11] as instances of a domain conceptualisation and a language, respectively. Figure 6.11 is therefore analogous to Fig. 6.10 but the layer names are different. (See also later discussion in Chap. 7 when ontologies are added to this diagram). An object-oriented (class model) representation of the meaning triangle of Fig. 1.3 is shown in Fig. 6.12, which elaborates slightly on Fig. 1.4. These diagrams illustrate the connections between language, models and conceptualisations. Following the genealogical example of Guizzardi (2005), a conceptualisation would consist of the concepts of Man, Mother, Offspring, etc. with relationships of being-the-mother-of, being-the-father-of etc. Visualising these concepts and relationships gives us essentially the definition of a language that can be used to create specific models that are valid in that genealogical

72

6 Modelling Languages

Fig. 6.13 Domain ontology (domain of genealogy) (after Guizzardi 2005)

domain. While this language can be presented in many forms, in Fig. 6.13 it is depicted as a class diagram using a UML-like notation. Guizzardi (2005, p. 37) notes that this figure ‘‘depicts a domain ontology representing a possible conceptualization in this domain’’. In other words, the model seen in Fig. 6.13 can be understood as both (1) a modelling language used to describe mother/father/ offspring configurations in the real-world domain (M0 in OMG-parlance) and (2) a domain ontology. While it is easy to acknowledge that a domain ontology is OMG M1, it is harder for MDE researchers to accept that a language—here an ontological language—can exist at M1. In fact, this may be a partial resolution to the issues raised in Chap. 4 since, from an ontological view point, the domain ontology is both a model and a metamodel. As discussed earlier, an SUS may relate to reality (OMG M0) or to a model (OMG M1) and hence its conceptual model may be M1 or M2, respectively. But this cannot mean that the Language (class) is at M1 or M2 as this would not be consistent or permit unique definition. It must remain at a single level, most likely M1 (or possibly M0). This leads to a multi-layer model that expands on Fig. 6.12 [and is shown in Fig. 6.14, which could be described as a ‘megamodel’ (Favre 2004)]. Figure 6.14 is a simple result of model chaining (as discussed in GonzalezPerez and Henderson-Sellers 2007) whereby the model of an SUS is itself treated

6 Modelling Languages

73

Fig. 6.14 Application of pattern of Fig. 6.12 twice to create a conceptual metamodel, its visualization and the languages used to support this. Note that the two occurrences of Language may be different or may be the same [this agrees with Seidewitz p. 29 col 1]

Communicated metamodel

Cognitive metamodel

Language

1

Communicated model *

Treat as SUS for metamodel

Cognitive model

Language

1 *

SUS

as an SUS for the construction of an additional model, i.e. the model of a model (of the original SUS). There is an additional link between conceptualisation and languages. Hoppenbrouwers et al. (2005a) discuss the influences of the personal biases and interests of the viewer, arguing for the sometimes discredited Sapir-Whorf hypothesis (e.g. Whorf 1941) that suggests that the elements of a language constrain the cognitive models that can be constructed. Similarly, in their study of the representation of time in different cultures, Boroditsky and Gaby (2010) conclude that their study group ‘‘think about time in ways that other groups cannot (because they lack the necessary spatial knowledge).’’ One particular kind of language, gaining much credence and interest recently, is the Domain-Specific Language (DSL). While it is sometimes equated to a Domain-Specific Modelling Language (DSML), the term DSL is more generic and can be applied at any metalevel. For example, Jouault and Bézivin (2006) discuss a language KM3 as being a DSL for specifying metamodels while others discuss a domain-specific language for describing M0 level entities (see later discussion of Fig. 7.14). In another application area, Cˇeh et al. (2010) argue that DSLs are programming languages. When a DSL is equated to a DSML, we can envisage it as a special kind of ML. However, as the name suggests, DSMLs are focussed on a restricted domain of interest that is typically smaller than the totality of reality but larger than a specific SUS (Fig. 1.1). A typical example is found in the use of a UML profile, which is described as specialising the UML metamodel as a ‘metamodel extension’ (OMG

74

6 Modelling Languages

2010a, pp. 177–178) using stereotypes as specific metaclasses, tagged values as standard meta-attributes and profiles as specific kinds of packages. Kelly and Pohjonen (2009) identify a number of ‘worst practices for domainspecific modelling’—although many of these also relate to the kind of broader scale, general modelling languages discussed above. These worst practices include, inter alia: • • • • • •

Lack of domain understanding Extending large, general-purpose modelling practices (like UML) Letting a software tool’s technical limitations dictate language development Creating a language with too few generic or too many specific concepts Viewing the initial language version as unalterable Using symbols that are too simple, too similar (see also Moody 2009) or just ugly

Chapter 7

Linking Models, Metamodels, Ontologies and Modelling Languages

In his investigation of the correspondences of terminology in the metamodelling and the ontology subdisciplines, Henderson-Sellers (2011b) concludes, as here, that there is a correspondence between a domain-specific ontology and the method domain in Fig. 1.10 (roughly OMG layer M2 in the architecture of Fig. 1.9). This ontology must be represented by a language, where this language may itself be defined by a metamodel (OMG M2 or ISO Metamodel Domain). This is named, variously, meta-ontology, ontology specification language, foundational ontology or higher level ontology (see Fig. 5.7 and previous discussion). Such a language provides reasoning support not possible in software modelling languages such as UML or ER, which many researchers are tempted to use and/or extend for this purpose. Despite it being said (e.g. Silva Parreiras et al. 2007) that metamodels in software engineering are closely associated with the UML environment, it is reasonable to analyse metamodel links to ontologies and modelling languages in a much broader context.

7.1 Metamodels and Modelling Languages In Chap. 6, we discussed two distinct approaches to define the notion of, firstly, ‘language’ and then ‘modelling language’. In this section, we investigate the relation between metamodels and modelling languages, first by retaining the two schools of thought introduced in Chap. 6 and, second, by seeking a rationalisation across the two approaches. We begin by restating the two schools of thought: (i) language is the metamodel (e.g. Gonzalez-Perez and Henderson-Sellers 2007) (ii) language is the set of all ‘sentences’ (models) that are conformant to the metamodel (Aßmann et al. 2006, p. 261; Favre and NGuyen 2005 based on Chomsky 1959); in other words, the metamodel is the ‘model of the language’ (e.g. Seidewitz 2003; Favre 2004) B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_7,  The Author(s) 2012

75

76

7 Linking Models, Metamodels, Ontologies and Modelling Languages

More colloquially, these two schools of thought can be expressed by (i) the metamodel is (defines) the language (ii) the metamodel is a model of the language Let us examine this apparent contradiction in more detail.

7.1.1 First School of Thought Aßmann et al. (2006, p. 260), in describing metametamodels, say that a metametamodel is a language for specifying languages a.k.a. language specification language or metalanguage. In that case, the language being specified is the metamodel and hence we can equate ‘metamodel’ with ‘modelling language’. Walter et al. (2009) echo this in their statement that ‘‘metamodelling is used as (a) well-known way to describe language’’, citing Bézivin and Gerbé (2001) as justification. Similarly, Saeki and Kaiya (2007) state that metamodels ‘‘define (the) abstract syntax of the model description language’’; Laarman and Kurtev (2010) state that ‘‘Metamodels are often regarded as definitions of the language abstract syntax’’; while Höfferer (2007) states that ‘‘A modelling language is described by a metamodel’’ and, in a similar vein, Boronat and Meseguer (2008) state that ‘‘A metamodel is a model specifying a modeling language’’. Similarly, Kühne (2006a, p. 379, col 2) states that the instantiation of model elements from an element in the metamodel assumes that the latter (which is a type) represents part of a language ‘‘defining which expressions are valid sentences of it’’; although here represents is used in the English sense rather than the sense it was used in either Figs. 1.2 or 1.6. Kühne (2006a, p. 382) examines the validity of using the terminology of ‘model’ for the language specification. Such a model, more commonly referred to in software engineering as a metamodel (but see earlier discussion of Fig. 6.13), can be argued to be a type model that defines all models expressible using it whereas Kühne (2006a) argues that it is a token model of the language specification (Fig. 7.1). He also notes that a slightly different argument leads to the conclusion that the metamodel is in fact the same as the language specification. (Of course, it is also possible to argue that a metamodel primarily defines only the abstract syntax and less so the semantics1 of the modelling language (Fig. 7.2) and that this is therefore an information reduction, i.e. there is a token model of relationship between metamodel and language. However, as Kühne (2006a) points out, this may be a transitory constraint that may be changed in the future. He concludes his discussion on languages and metamodels; thus, ‘‘A language metamodel therefore does not deserve its name for what it means (a language) but 1

We have already excluded concrete syntax (notation) as a necessary part of a language—in contradiction to the assumption made by Kühne (2006a).

7.1 Metamodels and Modelling Languages

77

Fig. 7.1 Linking models, metamodels and languages. Some authors argue that the metamodel—language specification association is an isomorphism; others that the metamodel is a token model of the language specification

for what it classifies (linguistic instances of it).’’ Consequently, we can assert that, for this author, a metamodel is/defines the language and is not a model of the language—but see further discussion below. The language, K, is often said to be the ‘meaning of the metamodel’, i.e. K ¼ lðMMÞ

ð7:1Þ

such that a model is a member of the set defined by this metamodel viz. M 2 eðKÞ ¼ eðlðMMÞÞ

ð7:2Þ

Kühne (2006a, p. 381). These relationships are depicted in his Fig. 1.8, reproduced here, with slight modifications, as Fig. 7.3, which incorporates the lefthand side of Fig. 6.2. The language specification may utilise one of many options for its formalisation—three possibilities are shown in Fig. 7.4. Equating ‘modelling language’ with a metamodel is common in software engineering—as evidenced in the naming of the Unified Modeling Language (OMG 2005a), which is essentially the description of a metamodel. GonzalezPerez and Henderson-Sellers (2007) explain, in the context of UML, that since the UML metamodel is a specification model, this means not that it specifies UML but rather that it specifies all possible UML models (see also earlier discussion in Chap. 1), i.e. UML is the modelling language. The specification of UML (i.e. a type model with UML as an instance thereof) must be a forward-looking model that represents UML—MOF is the supposed answer.

7.1.2 Second School of Thought Several authors are of the opinion that ‘a metamodel is a model of a modelling language’ for example Karagiannis and Kühn (2002); Aßmann et al. (2006, p. 259); Seidewitz (2003, p. 29).

78

7 Linking Models, Metamodels, Ontologies and Modelling Languages

Fig. 7.2 A modelling language is defined here as possessing both (abstract) syntax and semantics, both of which are likely to be contribute to the metamodel that is used to define the modelling language

Fig. 7.3 Linking models, metamodels and the intension and extension of modelling languages. Some authors (e.g. Kühne 2006a) see the metamodel—language specification association as denoting a token model whereas others (e.g. Guizzardi 2007) see them as equivalent

Fig. 7.4 Implementation options for a language specification

7.1 Metamodels and Modelling Languages

79

Fig. 7.5 Interpretation mapping from metamodel to modelling language (cf. also Figs. 1.5 and 3.2)

The notion of a metamodel as a model of a modelling language seems to derive from Chomsky’s (1956) statement that language can be equated to a (possibly infinite) set of (valid) sentences. Favre and NGuyen (2005), for example, state that UML ‘‘is the set of all UML models’’. This would appear largely to be an ‘M1’ layer definition, as in Fig. 6.4. This is elaborated by Favre (2004) into ‘‘a modelling language is a set of models’’ leading naturally to ‘‘a metamodel is a model of modelling languages’’ (assuming a Chomsky-like definition of ‘language’). However, since UML, as defined by the OMG (e.g. OMG 2005a, 2010a), is obviously not a set of UML models (since the UML documentation is a singleclass model—albeit fragmented), this approach must be questioned in the context of software engineering. Notwithstanding, this approach is also followed in Gaševic´ et al. (2007). (It should be noted that although they analyse the ontological/linguistic metamodelling divide issue, this underlying assumption (ii above) is in contradiction to the axioms in the original papers of Atkinson and Kühne (2003) and Kühne (2006a) who use option i above—hence the conclusions of these two papers are not commensurate.) Furthermore, it is a mapping of the elements of the metamodel to the elements of the modelling language and is a specification model (Fig. 7.5). This suggests that, from an alternative viewpoint, the ‘model’ part of this definition is in fact a token model. However, while the mapping is clearly an injection (Fig. 2.5), one must enquire what information is lost in order to justify an abstraction and hence a model. If we express these relationships by using the classification mapping (Eq. 2.49) for type models and the granularity abstraction mapping (Eqs. 2.46 and 2.47) for token models (see also Eqs. 3.3 and 3.4), then we have qðK; MMÞ and CðM; MMÞ ð7:3Þ Equating a metamodel with a model of a modelling language leads to the interpretation of UML as the set of all possible models. In this case, the language, K, is not said to be the meaning of the metamodel (Eq. 7.1) but it is the extension of the language that is equated to the metamodel, i.e. eðKÞ ¼ lðMMÞ

ð7:4Þ

together with Eq. 7.2. This is depicted in Fig. 7.6. This diagram, which is supported by the work of Favre (2004), essentially confounds language and language

80

7 Linking Models, Metamodels, Ontologies and Modelling Languages

Fig. 7.6 Linking models, metamodels, languages and sentences/models

Fig. 7.7 Relationship between metamodel and language (an alternative megamodel). This holds not only for metamodels but for all types of model as shown earlier in Fig. 6.1

specification with its more significant focus on the language sentences. In the context of modelling languages, the set of language sentences is equated to the set of models.

7.1.3 Reconciliation of Two Schools of Thought Based on the above comparison of assumptions (i) and (ii), then perhaps, like ‘ontologies’ (Henderson-Sellers 2011b), one might surmise that ‘language’ spans across or includes both (i) and (ii). Option (i) focusses on language in terms of its definition (essentially OMG level M2), whereas option (ii), based on Chomsky (1956), defines language empirically in the method domain (OMG level M1)— often called the ‘language use’—as compared to the ‘language definition’ domain of option (i). Furthermore, once it is recognised that the phrase ‘a model of’ in ‘a metamodel is a model of a language’ is in fact a token model and thus implies no change of abstraction layer (in the sense of Fig. 1.9), we can see that Fig. 7.7 could be a useful depiction of the relationships involved for both options. This is a representation of option ii above; whereas authors who opt for option (i) are in fact labelling this relationship as ‘is’ rather than ‘is a model of’. While option (ii) (with a token model) is therefore feasible, option (i) is more commonly accepted in the software engineering literature.

7.1 Metamodels and Modelling Languages

81

Fig. 7.8 Complete multi-level framework based on language use—to replace the strict metamodelling architecture of Fig. 1.9 when modelling in software engineering. In addition to the ‘language hierarchy’, which is entirely within the linguistic/modelling domain, we need a connection from this conceptual world to the real world and ‘things’ in it; the example here is that of Fido—an instance in the modelling context linked with a correspondence relationship to a real, individual, living dog (modified from Eriksson et al. 2012)

Fig. 7.9 Two facets of a modelling language in terms of a metamodel as its definition and models as its use (cf. Fig. 6.7)

If we now introduce the language use framework (Fig. 7.8) of Eriksson et al. (2012), we focus not on a hierarchy of models, as in Figs. 1.9 or 6.1, but on language definition and use (Fig. 6.3). We see clearly that one school of thought relates to the definition of language and one to the use of language. Now, rather than starting with Fig. 1.9 and asking how can one link in modelling languages (e.g. Henderson-Sellers 2011b), we start with Fig. 6.3 and ask how we can link in metamodels. The answer is straightforward—as shown in Fig. 7.8. The language may be linked to a metamodel or an ontology or a grammar or … (Fig. 7.4). For the special case when only a metamodel and nothing else is linked in, then it is reasonable to equate metamodel and language definition, resulting in the Fig. 1.9 architecture. But in a more general case, Fig. 7.8 allows a greater flexibility. We can thus depict a modelling language as having two elements (Fig. 7.9)—a language definition and a language use—the models (depicting types and instances)

82

7 Linking Models, Metamodels, Ontologies and Modelling Languages

that are conformant to the language definition. It can be readily seen that Fig. 7.9 can equally be seen as being derived by collapsing the detail in Fig. 6.7.

7.2 Augmentation by the Introduction of Ontologies In comparing models and ontologies, it should also be remembered (see Chap. 5) that an ontology is valid with an open-world assumption, whereas a model is often discussed as having a context given by the closed-world assumption; although the exact opposite is stated by Silva Parreiras et al. (2007), i.e. ontology = closed; model = open. These latter authors suggest that, although the historical literature treats these two very differently, it is now acceptable to consider them together (cf. Motik et al. 2007 in their studies of OWL and databases). Bézivin and Gerbé (2001) note the strong relationship between metamodels and ontologies, as do Gonzalez-Perez and Henderson-Sellers (2006a) in their explication of the ISO/IEC 24744 metamodel/ontology (ISO/IEC 2007). Devedzˇic´ (2002) states that ‘‘Generally, an ontology is a metamodel describing how to build models’’. However, whether metamodels and ontologies are at the same ‘layer’ of abstraction (in, e.g., Fig. 1.9) has led to much disagreement. For example, Ruiz and Hilera (2006, p. 65) conclude that the real distinction is that a (domain) ontology is descriptive and is relevant to the problem domain, whereas a metamodel is prescriptive and belongs to the solution domain. In contrast, HendersonSellers (2011b) argues that this only applies to high-level/foundational ontologies and not to the lower level ones advocated by Ruiz and Hilera (2006, p. 64). A model (and hence a metamodel) can be either static or dynamic. It only addresses a part of the domain of knowledge, i.e. a system. Bézivin et al. (2004) note that the language used to define metamodels is a metametamodel. Hence, we can state by analogy that the language used to define models is a metamodel. Kühne (2006a, p. 381) notes that an ontological model does not define a language, whereas there are strong links between linguistic metamodels and modelling languages. Atkinson et al. (2006) note that ‘‘all ontologies are models, but not all models are ontologies’’. Consequently, while an ontology is a model, it is a special kind of model in which it is generally descriptive (and a domain ontology is always descriptive); it is also static and describes one whole domain of knowledge. It could be regarded as a structured vocabulary expressed in a chosen language. Indeed, several authors (e.g. Tairas et al. 2007) stress that, while an ontology represents structure, an object-oriented approach usually has an operational bias. This could perhaps be best related to Fig. 1.1 such that we can associate models with the SUS and ontologies with the domain of interest. Since an ontology is structural in nature, it is of course possible to represent it in a structural way— UML class diagrams are one common representation (e.g. Fig. 2 of Tairas et al. 2007) as are branch-tree structures (e.g. Fig. 2 of Silva Parreiras et al. 2007) and Fig. 5.4 here—see also earlier discussion).

7.2 Augmentation by the Introduction of Ontologies

83

Fig. 7.10 Adaptation and extension of Fig. 3.5 results in the identification of an ontological metamodel and a linguistic metamodel

Since a metamodel is also a model, then it is appropriate to apply the hierarchy of Fig. 3.5 but prefacing the names by ‘meta’. In addition, since metamodels, as used in software engineering, are generally prescriptive we can eliminate the optional descriptive role. Token models are therefore eliminated and the three ‘levels’ of system/type/analysis model of Fig. 3.5 thus collapse into the single entity named, in Fig. 7.10, as Linguistic metamodel. Furthermore, the ontology element thus becomes a (forward looking or prescriptive) ontological metamodel. Since a domain ontology is also a model (Fig. 3.5 and Guizzardi and Halpin 2008), it can be linked to a language specification in a manner similar to that given in Fig. 6.1. In other words, an ontology is a conceptualization rendered with some language specification (Fig. 7.4). Thus, one possibility is for this language specification to be given by a metamodel (Fig. 7.11). This is the foundational ontology discussed in Chap. 5. However, as noted above (Chap. 5), a domain ontology represents structured and shared knowledge in a specific area of interest (e.g. wine, genes, banking). The language used to describe this must, by definition, be linguistic. This representation (language) may be the same or different to that used to depict a conceptual model (e.g. a system model as in Fig. 3.5) or a metamodel (for foundational ontologies). Merging the results of applying Fig. 7.11 first to domain ontologies and then, by analogy, to foundational ontologies and incorporating the fact of a metamodel representing the meta-ontology shows (Fig. 7.12) that an upper ontology (a.k.a. high-level ontology, foundational ontology or meta-ontology) is essentially equivalent to a modelling language which is itself (a token model of) a language specification (Fig. 7.12). Mathematically, we then have the following mappings: CðDO; MOÞ

and qðMO; MMÞ

and qðK; MMÞ

ð7:5Þ

Figure 7.12 demonstrates how a foundational ontology/metamodel is a type model with respect to all the models (i.e. the domain ontology) that can be

84

7 Linking Models, Metamodels, Ontologies and Modelling Languages

Fig. 7.11 A model uses a modelling language (Fig. 6.1). Since a domain ontology is a kind of model, it too uses an (appropriate) modelling language, possibly defined in terms of a metamodel/foundational ontology

Fig. 7.12 Relationship between metamodels, meta-ontologies, domain ontologies and language specifications

expressed and that are each conformant to it; while it is also a token model with respect to the language specification (Kühne 2006a, p 382, col 2—see also Fig. 7.3). Guizzardi (2007) clearly differentiates between a cognitive framework and a modelling framework and discusses how these are linked. Figure 6.10 shows that real-world abstractions (mental models for specific problems) are specific instances of very broadly applicable conceptualisations and that these are represented by a model and a modelling language, respectively, wherein the abstract syntax of the modelling language is a metamodel. He further argues that this approach allows the comparison of conceptualisations as intensional structures and metamodels as represented by logical theories. The real world abstractions (a.k.a. material domain conceptualizations) are related to a domain ontology while the conceptualisations can be depicted using a foundational ontology. Figure 7.13 illustrates the merger of Fig. 4.1, relabelling the ontologically focussed terms of

7.2 Augmentation by the Introduction of Ontologies

85

Fig. 7.13 Addition of domain ontology and foundational ontology to Fig. 6.10

Fig. 7.14 Overall schematic showing cognitive artefacts in relation to languages and ontologies

metametamodel and language metamodel by the relative modelling terminology, with the pattern expressed in Fig. 6.10. Layering is denoted by Ox (to parallel Mx for models and Lx for languages). Figure 7.13 relates layers 1 (O1 and M1) and 2 (O2 and L2); yet as noted above in the discussion of Fig. 6.11, this pattern can be applied at other abstraction layers. Figure 7.14 extends Fig. 6.11 by analogy with Fig. 7.13 by the addition of ontological ideas to the modelling ideas of Fig. 6.11. Furthermore, in the domain ontology, each class is conformant to a class in a version of UML 2.0 that Guizzardi (2005) has redesigned based on his foundational ontology. From this (domain) ontology, he then creates a number of valid models. This can be pictured as a double application of Fig. 6.10 (as shown in Fig. 7.15); which is equivalent to a merger of Figs. 7.13 and 7.14 in which the language to specify the M0 model (Fig. 7.14) is identical to the (communicated) model of Fig. 7.13. This figure (Fig. 7.15) and the discussion on DSMLs both exemplifies and clarifies the terminological confusion between ontology researchers and software engineers—as reported in Henderson-Sellers (2011b) in which the term ‘model’ was assumed to mean a conceptual model (e.g. a UML class model) of reality (the software engineer’s viewpoint) when in fact it is a representation of individuals in the domain. In other words, while Henderson-Sellers (2011b) tried to interpret his

86

7 Linking Models, Metamodels, Ontologies and Modelling Languages

Fig. 7.15 Extension of Fig. 7.14 to include the ‘metalevel’

Fig. 17 in terms of only two OMG metalayers, in fact, using these new insights reported here, we can interpret the double application of these patterns in terms of three layers, the lowest (unusually in the software engineering and conceptual modelling literature) being that of the individual. In Figs. 7.13–7.15, we can represent the various relationships shown as follows: • ‘instance of’ is the C(x,y) mapping (Eqs. 2.49 and 2.54) • ‘is reified by’ is the inverse of d (Fig. 1.6), approximated (Sect. 2.3.3) by the representational relationship q Other authors have addressed the alignment of these ontological approaches with the software engineering viewpoint, as exemplified by the OMG architecture (Fig. 1.9). For example, Aßmann et al. (2006) argue that a philosophically focussed ‘world ontology’ encompasses both the conceptualisation layer (upper level ontology) as well as domain ontologies at a lower layer in this pyramid. They depict the relationship between the two as a specialisation relationship rather than the expected instantiation relationship (Fig. 7.16). They suggest (but without citation) that this has an historical basis,2 perhaps linked to the difference between descriptive versus prescriptive modelling. They then argue that specialisation may well be an unnecessary constraint, suggesting instead the use of a ‘described-by’ relationship. This links well to the modelling-focussed arguments of, e.g. (Gonzalez-Perez and Henderson-Sellers 2007; Seidewitz 2003) that the OMG’s use of strict metamodelling and its insistence on only using ‘instance-of’

2

Possibly based on a statement such as ‘bank is a kind of noun’ being interpreted as a generalisation relationship.

7.2 Augmentation by the Introduction of Ontologies Design Solution Domain Prescriptive (Specifications)

Analysis Problem Domain Descriptive

M3 metametamodel level

87

Metametamodels (specification concepts) instance-of instance-of

M2 metamodel level

Metamodels (languages, language concepts)

Upper ontologies (description concepts)

instance-of

M1 model level Domain ontologies

M0 object level

described by

Real-world objects described by

Models

instance-of

Software objects

Fig. 7.16 Proposed integration of an ontological view with a four-layer metamodel architecture (after Aßmann et al. 2006, Fig. 9.7 2006). (With kind permission of Springer Science ? Business Media)

relationships between the layers of this pyramid is overly restrictive. They then change this inheritance link to a ‘described-by’ relation (between domain ontologies and upper ontologies) without giving a formal definition of ‘described-by’, which, as we noted earlier, is said to be a subtype of the representation relationship (Fig. 7.17). As noted earlier, these authors advocate the use of ‘is-described-by’ when dealing with ontologies (because they are descriptive not prescriptive models). Consequently, they propose an ‘is-described-by’ relationship both between real-world objects and domain ontologies and between real-world objects and software objects. Furthermore, they (oddly) neither make connections between domain ontologies and models nor between upper ontologies and metamodels (in contrast to Gonzalez-Perez and Henderson-Sellers 2006a). Indeed, it may be that a combination of instance-of and specialisation, in the form of the powertype relationship (Gonzalez-Perez and Henderson-Sellers 2006b) may be useful here. Figure 6.10 shows a first proposal (Henderson-Sellers 2011b) in which it was postulated that a ‘classification’ relationship might exist between the elements in an upper ontology and the corresponding elements in the metamodel. Completing the powertype pattern requires also the addition of an instantiation relationship from domain ontologies to metamodels. For example, in ISO/IEC 24744, there are classes (in the metamodel) such as Task and TaskKind; Phase and PhaseKind; Team and TeamKind. The latter of each of these pairs is needed to hold attributes applicable to all Tasks, Phases, Teams, etc.; whereas the former (here, example of Task, Phase, Team) describes not model-level attributes but attributes relating to real-world entities, be they

88

7 Linking Models, Metamodels, Ontologies and Modelling Languages Design Solution Domain Prescriptive (Specifications)

Analysis Problem Domain Descriptive

M3 metametamodel level

Metametamodels (specification concepts) instance-of instance-of

M2 metamodel level

Metamodels (languages, language concepts)

Upper ontologies (description concepts)

described by

instance-of

M1 model level Domain ontologies

M0 object level

described by

Real-world objects described by

Models

instance-of

Software objects

Fig. 7.17 Replacement of the inheritance relationship in Fig. 7.16 by a ‘described-by’ relationship (adopted from Aßmann et al.; Fig. 9.8, 2006). (With kind permission of Springer Science ? Business Media)

social/organisational or real entities (cf. Eriksson and Ågerfalk 2010). These therefore form the domain ontology modelling language creating/describing elements in the domain ontology such as WriteUseCaseModelTask, BuildClassModelTask, etc. (Fig. 7.18). These entities are of course clabjects (Atkinson 1998), since they possess both an object facet and a class facet (Fig. 2.4). While this example is not a formal proof of the powertype in Fig. 7.19, it is supportive of such an addition to the original meta-pyramid of Aßmann et al. (2006) shown in Fig. 7.16. If this can be substantiated by further research then the hybrid proposal of Aßmann et al. (2006) will have been reconciled with the powertype pattern as used in ISO/IEC 24744 (ISO/IEC 2007). Additionally, the underpinning rationale of Figs 7.16 and 7.18 provides an alternative avenue of reconciliation between the ontological and the linguistic metamodelling approaches promulgated by Atkinson and Kühne (2002, 2003), for instance as synopsised in Gonzalez-Perez and Henderson-Sellers (2008). A modelling language has been shown above (Chap. 6) to be equated, with certain assumptions, to a (linguistic) metamodel. However, a modelling language like UML is focussed on providing the infrastructure to depict systems and thus lacks elements, such as in its treatment of disjoint classes, set intersection and set complement, needed to fully describe ontologies (e.g. Djuric´ et al. 2005; OMG 2005b). We can thus postulate the need for an ontology-specialised modelling language. The metamodel for such a modelling language needs to include metalayer classes such as Sortal and its subtypes. These classes are found in a so-called foundational ontology (Guizzardi and Wagner 2005 and see Fig. 5.21 here)—an

7.2 Augmentation by the Introduction of Ontologies

89

Ontology modelling language

Task

TaskKind

instance-of

Domain ontology WriteUseCaseModelTask

Just one example of tasks within the domain ontology

Fig. 7.18 An example of the powertype pattern depicted generically in Fig. 5.21

Design Solution Domain Prescriptive (Specifications)

Analysis Problem Domain Descriptive

M3 metameta model level

Metametamodels (specification concepts) instance-of instance-of

M2 metamodel level

classified by

Upper ontologies (description concepts)

M1 model level Domain ontologies

M0 object level

f -o ce an t s in

described by

Real-world objects described by

Metamodels (languages, language concepts) instance-of

Models

instance-of

Software objects

Fig. 7.19 Revision of Fig. 7.16 to include a powertype representation (after Henderson-Sellers 2011b)

incorporation of these into a proposed revision for UML that will support both system and domain/ontology modelling is given by Guizzardi (2005, Chap. 8) and elaborated in more detail by Guizzardi et al. (2004, 2005). Figure 7.20 depicts how this idea would work. The classes in a foundational ontology (here, the UFO) add rules that discriminate between different sorts of model class types based upon

90

7 Linking Models, Metamodels, Ontologies and Modelling Languages

Fig. 7.20 Part of the UFO showing how it can be included in a modelling language (here using classes from the UML as an example)

Fig. 7.21 Example from the literature showing an arguably ontologically poor model and an ontologically correct model (after Guizzardi and Wagner, Fig. 5 2005) (With kind permission of Springer Science ? Business Media)

ontological modelling. Thus, these ontological foundational classes become subtypes of the class Class in the UML. Thus, in this abbreviated example, when one draws a class diagram using a UML extended as per Fig. 7.20, we would need to show classes as being either rigid sortals, anti-rigid sortals or mixins. In current UML, these could be shown as class stereotypes, where the definition of the stereotype is given by the definitions associated with the various classes in Fig. 7.20. Adoption of an ontologically based metamodel for UML would mean that tools implementing it would prevent the drawing of ontologically incorrect UML diagrams (such as that depicted in Fig. 7.21a).

7.2 Augmentation by the Introduction of Ontologies

91

Fig. 7.22 Revision of Fig. 7.21 employing role playing relationships between the two base types and the role type Fig. 7.23 The role of domain-specific modelling languages

Model

Domain ontology

uses

uses

Modelling language

Domain-specific modelling language =?UML profile

Figure 7.21 argues that Person and Corporation should not be subtypes of Customer since Customer is a mixin type3 and cannot therefore supply identity whereas Person and Corporation, as sortal types, can do this; in other words, an anti-rigid type cannot be a super type to a rigid type (e.g. Guizzardi et al. 2004). Thus, based on Fig. 5.6, the generalisation relationship in Fig. 7.21a cannot be valid since mixin types and sortal types are disjoint in the UFO. Guizzardi’s solution (2005) is shown in the lower diagram where, he argues, the ontologically poor representation in part (a) should be replaced by what he proposes as an ontologically correct solution, as shown in part (b) of Fig. 7.21. We propose the model in Fig. 7.22 as an alternative solution, which does not need to use a subsumption relationship but instead uses two plays-the-role-of associations4 between the three classes. This model does not transgress the set theory interpretation of a foundational ontology but rather uses associations between the roletype and the basetype (indicated here as UML stereotypes). Thus, the amendment that needs to be made is not an override on the generalisation hierarchy (as discussed in Chap. 5 with respect to Figs. 5.8 and 5.9); rather, an association needs to be added (here between BaseType and RoleType, i.e. modelling role as a substantial universal) in Fig. 5.6 (and similarly for any other connections between foundational ontology classes for which their instances needs to be interrelated (qua Fig. 7.22)). Figure 7.22 does, however, introduce a ‘point of contention’. Since it is an instance of Person, say Brian:Person, that plays the role of a customer, it could be reasonably argued that customer in Fig. 7.22 should in fact be role with an instance of customer, which is then linked to the instance of Person (e.g. Halpin and 3 4

In various publications, Customer is sometimes a mixin type and sometimes a role type. ‘Can play the role of’ is materialised as an existential dependence relation at the instance level.

92

7 Linking Models, Metamodels, Ontologies and Modelling Languages

DSML = Ontologically-enhanced modelling language

(General purpose) modelling language Conceptualization

Foundational ontology

defines Metamodel

instance of

is used to compose instance of/ conforms to

is used to compose

Model Material domain conceptualization Domain ontology

uses DSML

Fig. 7.24 Schematic to include DSML

Morgan 2008). This effectively moves the role playing from the relationship (as in Fig. 7.22) to the class. Alternatively, we could retain Fig. 7.22 and implement customer as a singleton class. This has the advantage that if we wish Brian to play the role not just of customer but of, say, customer3 and customer8 in different contexts, Fig. 7.22 is equally implementable with multiple members of the Customer class/set. Advances in ontologically based modelling languages await further research into the mathematics of foundational ontology hierarchies like Fig. 7.20, possibly by replacing type—instance semantics by the mathematics of sets of sets (also see earlier discussion). There arises the further question as to whether ontologies are equivalent to the semantics of a modelling language (cf. Fig. 6.1) presumably by offering a vocabulary to the language. Authors are indecisive—for example, Ruiz and Hilera (2006, p. 51) state that domain ontologies ‘‘describe the vocabulary related to a generic domain’’ while, on the same page, stating that ‘‘the ontology is not the vocabulary itself, but what the vocabulary represents, since the translation of this vocabulary into another language will not change the ontology’’. This last statement can be readily understood in the context of Fig. 5.2 by equating ‘vocabulary’ here with ‘cognitive ontology’. Wand (1996), quoting Neches et al. (1991), states that ‘‘An ontology defines the basic terms and relations comprising the vocabulary of a topic area’’. Similarly, statements linking an ontology with the provision of a vocabulary are made by Guarino (1998) and Corcho et al. (2006).

7.3 Incorporating DSMLs Fig. 7.25 Linking DSML to general-purpose languages and the various scales of applicability (Fig. 1.1)

93

General purpose modelling language

is used to model

is used to model DSML

Reality

Domain of interest

is used to model SUS

7.3 Incorporating DSMLs We have seen that a domain ontology is a kind of model and that models are described using a modelling language Then by analogy, since a model uses a modelling language and a domain ontology is a kind of model, then the domain ontology must also use a special kind of modelling language viz. a domain-specific modelling language or DSML (Fig. 7.23). Some source suggest that this DSML could be described with a UML profile (e.g. Silva Parreiras et al. 2007), although this imposes some highly specific constraints. Another strong link is in the use of a domain ontology to assist in the creation of a DSL (e.g. Tairas et al. 2009; Walter et al. 2009). Enhancing this diagram with cognitive concepts from Fig. 7.13 and with Guizzardi’s (2005, 2007) proposal to add concepts from his foundational ontology into a (software engineering) modelling language like UML (Fig. 7.24) shows that a DSML is a kind of ontologically enhanced modelling language, which itself is a merger of a general-purpose ML and a foundational ontology. Typically, this DSML will be used to specify a restricted domain of interest, while the general-purpose language may be used for broader purposes, although in reality only used for designing models of an SUS. Figure 7.25 shows how these uses relate to the three scopes shown in Fig. 1.1.

Chapter 8

Other Related Work and Further Discussion

Several authors discuss styles of SUSs, application domains and the strengths and weaknesses of models (e.g. Mellor et al. 2004; Hoppenbrouwers et al. 2005b; Jackson 2009; Hoppenbrouwers and Wilmont 2010). Selic (2003) proposes five characteristics for all engineering models: abstraction, understandability, accuracy, predictiveness and inexpensive. Seidewitz (2003) and Muller et al. (2009) examine how model truth can be ascertained from both forward-looking and backwardlooking models. Henderson-Sellers (2011a), based on an overview of conceptual modelling, concludes with recommendations for enhancing research programmes in quality assessment of conceptual models (including metamodels). Since these are not strictly mathematically-related, we have deemed such discussions out of scope for this present discussion but encourage its adoption in a more mathematical format in future research. Furthermore, although model transformations are a key idea (e.g. Bézivin 2004) for model-driven engineering (MDE), including the OMGs MDA (OMG 2003), they are consequent on the mathematics presented here but are not discussed further in this book. As discussed in part above, the several recent papers on ontological versus linguistic metamodelling have provoked much discussion. Despite these publications and as a consequence of some reservations identified during the course of this research, a final conclusion has not been reached. Indeed, some publications seem to add obfuscation to the discussion with poor and semantically-invalid examples (e.g. Gaševic´ et al. 2007; Atkinson et al. 2009 and Fig. 5.13).

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_8, Ó The Author(s) 2012

95

Chapter 9

Conclusions and Further Work

Although much has been analyzed regarding the relationships between models, metamodels, ontologies and modelling languages, without a mathematical underpinning, these analyses can be readily influenced by the imprecision of the natural language (usually English) used in their exposition. The introduction of simple set theory mathematical representations can aid researchers in understanding better the links between the various elements of the modelling scene and, especially in our context, how it all relates to modelling in software engineering. In our analysis presented here, we have taken a first step to binding together the various mindsets of the onotological literature with software engineering modelling and metamodelling. Whilst several loose threads have been tied up, there still remain several questions and paradoxes–notably the whole linguistic/ontological metamodelling debate, which, although we have addressed here in Sect. 5.1 and in some tentative steps to a resolution in Eriksson et al. (2012), still leaves a plethora of inconsistencies and contradictions. For example, here we identified an apparent contradiction in some of the arguments and diagrams relating to the ontological versus linguistic metamodelling debate as well as related conceptual modelling concerns in the examples of Atkinson et al. (2009). The value of powertypes is still the subject of some debate (as noted by Halpin 2005 and Eriksson et al. 2012) although in other software engineering areas they have proved invaluable (see, e.g. Gonzalez-Perez and Henderson-Sellers 2008). Domain-specific modelling languages have attracted significant attention over the last few years. Here, we have only outlined some of the connections of the mathematical underpinnings for software engineering modelling in general to DSMLs—there is still much to be discovered. Finally, there is the opportunity to replace the set theory as presented here by the more sophisticated (and hopefully more useful) category theory (e.g. Fiadeiro 2005), which could provide a rich avenue for further exploration of this topic. This has had some minimal usage to date. For instance, (Muller et al. 2009) use category theory to represent objects and morphisms, Graham et al. (1997) use it in an analysis of associations in object

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7_9, Ó The Author(s) 2012

97

98 Fig. 9.1 A categorical representation of the RepresentationOf relationship, l

9 Conclusions and Further Work A

B

modelling and Whitmire (1997) applies it in his study of object-oriented metrics, including a ‘theory of objects’. A simple RepresentationOf relationship is shown in Fig. 9.1 and is used not only by Muller et al., but also by Kühne (2006a) and by Gaševic´ et al. (2007). Categories can be said to have specific intentions (e.g. Yu and Mylopoulos 1994). Various intentional situations are presented by Muller et al. (their Table 2).

References

Abadi, M., & Cardelli, L. (1996). A theory of objects. New York, USA: Springer. Alagar, V. S., & Periyasamy, K. (1998). Specification of software systems. Berlin: Springer. Aßmann, U., Zschaler, S., & Wagner, G. (2006). Ontologies, meta-models, and the model-driven paradigm. In C. Calero, F. Ruiz, & M. Piattini (Eds.), Ontologies for software engineering and software technology (pp. 239–273). Berlin: Springer. Atkinson, C. (1997). Metamodelling for distributed object environments. In 1st International Enterprise Distributed Object Computing Workshop (EDOC’97), Brisbane, Australia. Atkinson, C. (1998). Supporting and applying the UML conceptual framework. In J. Bézivin & P.-A. Muller (Eds.), The Unified Modeling Language. «UML» 1998: Beyond the notation, LNCS 1618 (pp. 21–36). Berlin: Springer. Atkinson, C. & Kühne, T. (2000a). Strict profiles: Why and how. In Proceedings of 3rd International Conference on the Unified Modeling Language, LNCS1939 (pp. 309–322). Springer. Atkinson, C., & Kühne, T. (2000b). Meta-level independent modelling. In International Workshop on Model Engineering at the 14th European Conference on Object-Oriented Programming 2000. Sophia Antipolis and Cannes, France. Atkinson, C., & Kühne, T. (2001a). The essence of multilevel metamodelling. In: M. Gogolla & C. Kobryn (Eds.), «UML»2001—The Unified Modeling Language. Modeling languages, concepts and tools, LNCS 2185 (pp. 19–33). Berlin: Springer. Atkinson, C., & Kühne, T. (2001b). Processes and products in a multi-level metamodelling architecture. International Journal of Software Engineering and Knowledge Engineering, 11(6), 761–783. Atkinson, C., & Kühne, T. (2002). Rearchitecting the UML infrastructure. ACM Transactions on Modeling and Computer Simulation, 12(4), 290–321. http://doi.acm.org/10.1145/643120. 643123. Atkinson, C., & Kühne, T. (2003). Model-driven development: A metamodelling foundation. IEEE Software, 20, 36–41. Atkinson, C., & Kühne, T. (2005). Concepts for comparing modeling tool architectures, model driven engineering languages and systems, LNCS 3713 (pp. 398–413). Berlin: Springer. Atkinson, C., Gutheil, M., & Kennel, B. (2009). A flexible infrastructure for multilevel language engineering. IEEE Transactions on Software Engineering, 35(6), 742–755. Atkinson, C., Gutheil, M., & Kiko, K. (2006) On the relationship of ontologies and models. In Meta-Modelling and Ontologies. Proceedings of the 2nd Workshop on Meta-Modelling, WoMM 2006, LNI Volume P-96, pp. 47–60.

B. Henderson-Sellers, On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science, DOI: 10.1007/978-3-642-29825-7, Ó The Author(s) 2012

99

100

References

Atkinson, C., Kühne, T., & Henderson-Sellers, B. (2000). To meta or not to meta—that is the question. JOOP/ROAD, 13(8), 32–35. Atkinson, C., Kühne, T., & Henderson-Sellers, B. (2003). Systematic stereotype usage. Software and System Modelling, 2(3), 153–163. Baldinger, K. (1980). Semantic theory: Towards a modern semantics. New York: Palgrave Macmillan. Beydoun, G., Low, G., Henderson-Sellers, B., Mouratidis, H., Gomez-Sanz, J., Pavon, J., et al. (2009). FAML: A generic metamodel for MAS development. IEEE Transactions on Software Engineering, 35(6), 841–863. Bézivin, J. (2004). In search of a basic principle for model-driven engineering. Upgrade, 5(2), 21–24. Bézivin, J. (2005). On the unification power of models. Software and Systems Modeling, 4, 171–188. Bézivin, J. & Gerbé, O. (2001, November). Towards a precise definition of the OMG/MDA framework. In Automated Software Engineering Conference. Bézivin, J., & Lemesle, R. (1998). Ontology-based layered semantics for precise OA&D modeling. In J. Bosch & S. Mitchell (Eds.), Object-oriented technologys: ECOOP’97 workshop reader, LNCS 1357 (pp. 287–292). Berlin: Springer. Bézivin, J., Joualt, F., & Valduriez, P. (2004, October 25). On the need for megamodels. In Proceedings of Workshop on Best Practices for Model-Driven Software Development at the 19th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications. Boroditsky, L., & Gaby, A. (2010). Remembrances of times east: Absolute spatial representations of time in an Australian aboriginal community. Psychological Science, 21(11), 1635–1639. Boronat, A., & Meseguer, J. (2008). An algebraic semantics for MOF. In J. Fiadeiro & P. Inverardi (Eds.), FASE 2008, LNCS 4961 (pp. 377–391). Berlin: Springer. Brodie, M. L., Mylopoulos, J., & Schmidt, J. W. (Eds.). (1984). On conceptual modelling: Perspectives from artificial intelligence, databases, and programming languages (topics in information systems). Berlin: Springer. Cˇeh, I., Cˇrepinšek, M., Kosar, T., & Mernik, M. (2010, September 9–10). Using ontology in the development of domain-specific languages. In L. S. Barbosa & M. P. Correia (Eds.), Proceedings of INFORUM 2010, pp. 185–196. Chomsky, N. (1956). Three models for the description of language. IRE Transactions on Information Theory, IT-2(3), 113–124. Chomsky, N. (1959). On certain formal properties of grammars. Information and Control, 2(2), 137–167. Clarke, R. T. (1934). The drum language of the Tumba people. American Journal of Sociology, 40(1), 34–48. Colomb, R., Raymond, K., Hart, L., Emery, P., Welty, C., Xie, G. T., et al. (2006). The object management group ontology definition metamodel. In C. Calero, F. Ruiz, & M. Piattini (Eds.), Ontologies for software engineering and software technology (pp. 217–247). Berlin: Springer. Corcho, O., Fernandez-Lopez, M., & Gomez-Perez, A. (2006). Ontological engineering: Principles, methods, tools and languages. In C. Calero, F. Ruiz, & M. Piattini (Eds.), Ontologies for software engineering and software technology (pp. 1–48). Berlin: Springer. Denning, P. J., Dennis, J. B., & Qualitz, J. E. (1978). Machines, languages, and computation (601 pp.). Englewood Cliffs: Prentice-Hall. Devedzˇic´, V. (2002). Understanding ontological engineering. Communications of the ACM, 45(4), 136–144. Dillon, T. S., Chang, E., Wongthongtham, P. (2008). Ontology-based software engineering— software engineering 2.0. In Proceedings of 19th Australian Software Engineering Conference ASWEC 2008, Perth, Australia. Djuric´, D., Gaševic´, D., & Devedzˇic´, V. (2005). Ontology modelling and MDA. Journal of Object Technology, 4(1), 109–128.

References

101

Eriksson, O., & Ågerfalk, P. (2010). Rethinking the meaning of identifiers in information infrastructures. Journal of AIS, 11(8), 433–454. Eriksson, O., Henderson-Sellers, B, & Ågerfalk, P. J. (2012) Ontological and linguistic metamodelling revisited—a language use approach, submitted for publication. Falbo, R. A., Ruy, F. B., Moro, R. D. (2005). Using ontologies to add semantics to a software engineering environment. In Proceedings of SEKE 2005, Skokie, IL, USA. Favre, J.-M. (2004). Foundations of meta-pyramids: languages vs. metamodels. Episode II. Story of Thotus the Baboon. In Proceedings of Dagstuhl Seminar 04101 ‘‘Language Engineering for Model-Driven Software Development’’. Favre, J.-M. (2006). Metamodelling and etymology. A story of words: From MED to MDE via MODEL in five millenniums. In J. R. Cordy, R. Lämel & A. Winter (Eds.),Transformation Techniques in Software Engineering. Dagstuhl Seminar Proceedings 05161. Favre, J.-M., & NGuyen, T. (2005). Towards a megamodel to model software evolution through transformations. Electronic Notes in Theoretical Computer Science, 127(3), 59–74. Fensel, D. (2004). Ontologies: A silver bullet for knowledge management and electronic commerce (2nd ed.). Berlin: Springer. Fiadeiro, J. L. (2005). Categories for software engineering (250 pp.). Berlin: Springer. Flatscher, R. G. (2002). Metamodeling in EIA/CDIF – meta-metamodel and metamodels. ACM Transactions on Modeling and Computer Simulation, 12(4), 322–342. Fraleigh, J. B. (1967). A first course in abstract algebra (447 pp.). Reading, MA: AddisonWesley Publishing Company. Frank, U. (2008) (with revised version 2010). The MEMO meta modelling language (MML) and language architecture, ICB-research report no. 24, August 2008/April 2010. Institut für Informatik und Wirtschaftsinformatik, Universität Duisburg-Essen, Germany. Gaševic´, D., Kaviani, N., & Hatala, M. (2007). On metamodeling in megamodels. In G. Engels, et al. (Eds.), MoDELS 2007, LNCS 4735 (pp. 91–105). Berlin: Springer. Ghidini, C., & Giunchiglia, F. (2004). A semantics for abstraction. In R. Lopez de Mantaras & L. Saitta (Eds.), Proceedings ECAI2004. IOS Press, pp. 343–352. Giunchiglia, F., & Walsh, T. (1992). A theory of abstraction. Artificial Intelligence, 57(2–3), 323–390. Gonzalez-Perez, C., & Henderson-Sellers, B. (2006a). Chapter 4: An ontology for software development methodologies and endeavours. In C. Calero, F. Ruiz & M. Piattini (Eds.), Ontologies in software engineering and software technology (pp. 123–152). Berlin: Springer. Gonzalez-Perez, C., & Henderson-Sellers, B. (2006b). A powertype-based metamodelling framework. Software and System Modeling, 5, 72–90. Gonzalez-Perez, C., & Henderson-Sellers, B. (2007). Modelling software development methodologies: A conceptual foundation. Journal of Systems and Software, 80(11), 1778–1796. doi: 10.1016/j.jss.2007.02.048. Gonzalez-Perez, C., & Henderson-Sellers, B. (2008). Metamodelling for software engineering (p. 210). Chichester: Wiley. Graham, I. M., Bischof, J., & Henderson-Sellers, B. (1997). Associations considered a bad thing. Journal of Object-Oriented Programming, 9(9), 41–48. Greenfield, J., & Short, K. (2004). Software factories. New York: Wiley. Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199–220. Guarino, N. (1998). Formal ontology and information systems. In Proceedings of International Conference on Formal Ontology in Information Systems—FOIS’98, Trento, Italy. Guizzardi, G. (2005). Ontological foundations for structural conceptual models. CTIT PhD Thesis Series, No. 05-74, Enschede, The Netherlands. Guizzardi, G. (2007). On ontology, ontologies, conceptualizations, modeling languages, and (meta)models. In Frontiers in artificial intelligence and applications (Vol. 155, pp. 18–39). Proceedings of the 2007 Conference on Databases and Information Systems IV: Selected papers from the Seventh International Baltic Conference DB&IS2006, IOS Press, Amsterdam.

102

References

Guizzardi, G., & Halpin, T. (2008). Ontological foundations for conceptual modelling. Applied Ontology, 3, 1–12. Guizzardi, G., & Wagner, G. (2005). Towards ontological foundations for agent modelling concepts using the Unified Foundational Ontology (UFO). In P. Bresciani, P. Giorgini, B. Henderson-Sellers, G. Low & M. Winikoff (Eds.), Agent-oriented information systems II LNAI 3508 (110-124). Berlin: Springer. Guizzardi, G., Wagner, G., Guarino, N., van Sinderen, M. (2004). An ontologically well-founded profile for UML conceptual models. In A. Persson & J. Stirna (Eds.) 16th International Conference on Advances in Information Systems Engineering (CAiSE’04), Latvia. LNCS (Vol. 3084, pp. 112–126). Berlin: Springer. Guizzardi, G., Ferreira Pires, L., van Sinderen, M. (2005) An ontology-based approach for evaluating the domain appropriateness and comprehensibility appropriateness of modeling languages. In L. Briand & C. Williams (Eds.),Model driven engineering languages and systems. LNCS (Vol. 3713, pp. 691–705). Berlin: Springer. Guizzardi, R. S. S., Guizzardi, G., Perini, A., & Mylopoulos, J. (2007). Towards an ontological account of agent-oriented goals. In R. Choren et al. (Eds.), SELMAS 2006. LNCS 4408 (pp. 148-164). Berlin: Springer. Halpin, T. (2005). Chapter X: Higher order types and information modeling. In K. Siau (Ed.), Advanced topics in database research (Vol. 4, pp. 218–237). Idea Group. Halpin, T., & Morgan, T. (2008) Information modeling and relational databases. Massachusetts: Morgan Kaufmann. Harel, D., & Rumpe, B. (2004). Meaningful modeling: What’s the semantics of ‘‘semantics’’? IEEE Computer, 37(10), 64–72. Henderson-Sellers, B. (2006, May 30–31). Method engineering: Theory and practice. In D. Karagiannis & H. C. Mayr (Eds.), Information systems technology and its applications. 5th International Conference ISTA 2006. Klagenfurt, Austria. Lecture Notes in Informatics (LNI)—Proceedings (Vol. P-84, pp. 13–23). Bonn: Gesellschaft für Informatik. Henderson-Sellers, B. (2011a). Random thoughts on multi-level conceptual modelling. In L. Delcambre & R. Kaschek (Eds.), The evolution of conceptual modeling. LNCS 6520 (pp. 93–116), Berlin: Springer. Henderson-Sellers, B. (2011b). Bridging metamodels and ontologies in software engineering. Journal of Systems and Software, 84(2), 301–313. Henderson-Sellers, B., & Gonzalez-Perez, C. (2005a). Connecting powertypes and stereotypes. Journal of Object Technology, 4(7), 83–96. Henderson-Sellers, B., & Gonzalez-Perez, C. (2005b). The rationale of powertype-based metamodelling. In Second Asia-Pacific Conference on Conceptual Modelling, 30 January–4 February 2005. Australian Computer Science Communications (Vol. 7, no. 6, pp. 7–16). Australian Computer Society. Henderson-Sellers, B., & Gonzalez-Perez, C. (2006, October). Uses and abuses of the stereotype mechanism in UML1.4 and 2.0. In O. Nierstrasz, J. Whittle, D. Harel & G. Reggio (Eds.), Model driven engineering languages and systems, 9th International Conference, MoDELS 2006, Genoa, Italy, LNCS 4199 (pp. 16–26). Berlin: Springer. Henderson-Sellers, B., & Gonzalez-Perez, C. (2010). Granularity in conceptual modelling: Application to metamodels. In J. Parsons et al. (Eds.), Proceedings of ER2010. LNCS 6412 (pp. 275–288), Berlin: Springer. Henderson-Sellers, B., & Gonzalez-Perez, C. (2011, April). Towards the use of granularity theory for determining the size of atomic method fragments for use in situational method engineering. In J. Ralyté, I. Mirbel & R. Deneckère (Eds.), Engineering methods in the service-oriented context. 4th IFIP WG8.1 Working Conference on Method Engineering, ME 2011, Paris France, Proceedings (pp. 49–63). Heidelberg: Springer. Henderson-Sellers, B., & Unhelkar, B. (2000). OPEN modeling with UML (245 pp.). Harlow, UK: Addison-Wesley.

References

103

Hesse, W. (2006). More matters on (meta-)modelling: Remarks on Thomas Kühne’s ‘‘matters’’. Software & Systems Modeling, 5, 387–394. Hesse, W. (2008). From conceptual models to ontologies. Presentation at Dagstuhl Seminar on Conceptual Modelling. Hobbs, J. (1985). Granularity. In Proceedings of International Joint Conference on Artificial Intelligence, IJCAI-85. Höfferer, P. (2007). Achieving business process model interoperability using metamodels and ontologies. In Proceedings of the 15th European Conference on Information Systems (ECIS 2007), pp. 1620–1631. Hoppenbrouwers, S. J. B. A. & Wilmont, I. (2010). Focused conceptualisation: Framing questioning and answering in model-oriented dialogue games. In Proceedings POEM 2010. Hoppenbrouwers, S. J. B. A., Proper, H. A. & van der Weide, Th. P. (2005a). A fundamental view on the process of conceptual modelling. In L. Delcambre et al. (Eds.), ER 2005, LNCS 3716 (pp. 128–143). Berlin: Springer. Hoppenbrouwers, S. J. B. A., Proper, H. A., Weide, T. v. d. (2005b). Formal modelling as a grounded conversation. In M. Goldkuhl, G Lind & S. Haraldson (Eds.), Proceedings of the 10th International Working Conference on the Language Action Perspective on Communication Modelling (LAP05), Kiruna, Sweden. Linkopings Universitet and Hogskolan I Boras, Linkoping, Sweden, pp. 139–155. ISO/IEC. (1998). CDIF Framework. ISO/IEC 15474, International Organization for Standardization, Geneva. ISO/IEC. (2007). Software engineering—metamodel for software development. ISO/IEC 24744, Geneva, Switzerland. Jackson, M. (2002). Some basic tenets of description. Software & System Modeling, 1, 5–9. Jackson, M. (2009). Some notes on models and modelling. In A. T. Borgida et al. (Eds.), Mylopoulos Festschrift. LNCS 5600 (pp. 68–81). Berlin: Springer. Joualt, F., & Bézivin, J. (2006) KM3: a DSL for metamodel specification. In R. Gorrieri & H. Wehrheim (Eds.) Formal methods for open object-based distributed systems, LNCS 4037 (pp. 171–185). Berlin: Springer. Karagiannis, D., & Kühn, D. (2002) Metamodelling platforms. In K. Bauknecht, A. Min Tjoa & G. Quirchmayer (Eds.), Proceedings 3rd International Conference EO-Web2002-Dexa2002, LNCS 2455 (pp. 182–195). Berlin: Springer. Kaschek, R. (2004). A little theory of abstraction. In B. Rumpe, W. Hesse (Eds.), Modellierung 2004, GI Edition Lecture Notes in Informatics, P 45 (pp. 75–92). Bonn, Germany: Gesellschaft f}ur Informatik. Kazmierczak, E., & Milton, S. (2005). Using a common-sense realistic ontology: making data models better map the world. In P. Green & M. Rosemann (Eds.), Business systems analysis with ontologies (pp. 218–248). Hershey, PA: IGI Group Publishing. Keet, M. (2006). A taxonomy of types of granularity. In IEEE Conference on Granular Computing (GrC2006) (Vol. 1, pp. 106–111). Atlanta, USA. Keet, M. (2007). Enhancing comprehension of ontologies and conceptual models through abstractions. In R. Basili, M. T. Pazienza (Eds.), AI*IA 2007, LNAI 4733 (pp. 813–821), Berlin: Springer. Kelly, S., & Pohjonen, R. (2009). Worst practices for domain-specific modelling. IEEE Software, July/Aug 2009, 22–29. Kiryakov, A., Simov, K. I. & Dimitrov, M. (2001, October 17–19). OntoMap: Portal for upperlevel ontologies. In Proceedings FOIS’01 (pp. 47–58). ACM Press: Ogunquit, Maine, USA. Kühne, T. (2005). What is a model? Dagstuhl seminar proceedings 04101, (http://drops.dagstuhl. de/opus/volltexte/2005/23). Kühne, T. (2006a). Matters of (meta-)modeling. Software & Systems Modeling, 5, 369–385. Kühne, T. (2006b). Clarifying matters of (meta-)modeling: an author’s reply. Software & Systems Modeling, 5, 395–401.

104

References

Kühne, T. (2009). Contrasting classification with generalization. In M. Kirchberg & S. Link (Eds.), Proceedings of 6th Asia-Pacific Conference on Conceptual Modelling, Conferences in Research and Practice in Information Technology (Vol. 96, pp. 71–78). Laarman, A., & Kurtev, I. (2010). Ontological metamodelling with explicit instantiation. In M. van den Brand, D. Gaševic´ & J. Gray (Eds.), SLE2009, LNCS 5969 (pp. 174–183). Berlin: Springer. Lakoff, G. (1990). Women, fire, and dangerous things. Chicago: University of Chicago Press. Liskov, B. (1987). Data abstraction and hierarchy. In Addendum to the Proceedings OOPSLA (Addendum), ACM, pp. 17–34. Liskov, B., & Wing, J. (1994). A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems (TOPLAS), 16(6), 1811–1841. Ludewig, J. (2003). Models in software engineering—an introduction. Software & System Modeling, 2, 5–14. Mani, I. (1998). A theory of granularity and its application to problems of polysemy and underspecification of meaning. In A. G. Cohn, L. K. Schubert, & S. C. Shapiro (Eds.), Principles of knowledge representation and reasoning: Proceedings of the 6th International Conference (KR’98) (pp. 245–257). San Mateo, USA: Morgan Kaufmann. Martin, J., & Odell, J. J. (1998) Object-oriented methods: A foundation. UML Edition (408 pp.). Upper Saddle River, NJ: Prentice Hall PTR. Mellor, S. J., Scott, K., Uhl, A., & Weise, D. (2004). MDA distilled: Principle of model driven architecture. Reading, MA: Addison-Wesley. Menzel, C. (2003). Reference ontologies—application ontologies: Either/or or both/and?, from http://www.bioontology.org/wiki/images/d/d9/Menzel (last accessed 26/5/2010). Moody, D. L. (2009). The ‘‘physics’’ of notations: Towards a scientific basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering, 35(5), 756–778. Motik, B., Horrocks, I., & Sattler, U. (2007). Bridging the gap between OWL and relational databases. In Proceedings of WWW’07 (pp. 807–816). New York: ACM Press. Muller, P.-A., Fondement, F., & Baudry, B. (2009). Modeling modelling. In A. Schürr & B. Selic (Eds.), MODELS 2009, LNCS 5795 (pp. 2–16). Berlin: Springer. Neches, R., Fikes, R. E., Finin, T., Gruber, T., Patil, R., Senator, T., et al. (1991). Enabling technology for knowledge sharing. AI Magazine, 12(3), 36–56. Needleman, M. (1998). Standards update: Dublin core metadata element set. Serials Review, 24(3–4), 131–135. Nirenburg, S. (2004). Ontology tutorial, from http://ilit.umbc.edu/Ontology-tutorial-content.pdf (last accessed 25/5/2010). Nodine, M. H. & Unruh, A. (1998). Facilitating open communication in agent systems: The InfoSleuth infrastructure. In M. P. Singh, A. Rao & M. J. Wooldridge (Eds.), Intelligent agents IV agent theories, architectures, and languages 4th International Workshop, ATAL’97 Providence, Rhode Island, USA, July 24–26, 1997 Proceedings, LNCS 1365 (pp. 281–295), Berlin: Springer. Noy, N. F., & Musen, M. A. (2004). Ontology versioning in an ontology management framework. IEEE Intelligent Systems, 19(4), 6–13. Odell, J. (1994). Power types. Journal of Object-Oriented Programming, 7(2), 8–12. Ogden, C. K., & Richards, I. A. (1923). The meaning of meaning. Brace and World, New York: Harcourt. OMG. (2002). Software process engineering metamodel specification, version 1.0, formal/02-11-14. OMG. (2003). MDA guide, omg/2003-06-01, Object Management Group. OMG. (2005a). OMG: Unified Modeling Language superstructure, version 2.0, formal/05-07-04. OMG. (2005b). Ontology definition metamodel, ad/2005-08-01. OMG. (2008). Software & systems process engineering meta-model specification, version 2.0, formal/2008-04-01. OMG (2009). Ontology definition metamodel version 1.0, formal/2009-05-01.

References

105

OMG. (2010a). OMG Unified Modeling LanguageTM (OMG UML), infrastructure, version 2.3, formal/2010-05-03. OMG. (2010b). OMG Unified Modeling LanguageTM (OMG UML), superstructure, version 2.3, formal/2010-05-05. Opdahl, A., Henderson-Sellers, B., & Barbier, F. (2000). An ontological evaluation of the OML metamodel. In E. D. Falkenberg, K. Lyytinen & A. A. Verrijn-Stuart (Eds.), Information system concepts: An integrated discipline emerging (pp. 217–232). Boston: Kluwer. Opdahl, A. L., & Henderson-Sellers, B. (2002). Ontological evaluation of the UML using the Bunge-Wand-Weber model. Software & Systems Modeling, 1, 43–67. Pastor, O., España, S., & Gonzalez, A. (2008). An ontological-based approach to analyze software production methods. In R. Kaschek, C. Kop, C. Steinberger & G. Fliedl (Eds.), UNISCON 2008 (Vol. LNBIP 5, pp. 258–270). Berlin: Springer. Rothenberg, J. (1990, July). Prototyping as modeling: What is being modeled? Rand Note N3191-DARPA. Ruiz, F., & Hilera, J. R. (2006). Using ontologies in software engineering and technology. In C. Calero, F. Ruiz, & M. Piattini (Eds.), Ontologies for software engineering and software technology (pp. 49–102). Berlin: Springer. Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modeling Language reference manual. Reading, MA: Addison-Wesley. 550 pp. Saeki, M., & Kaiya, H. (2007). On relationships among models, meta models and ontologies. In Proceedings of 6th OOPSLA Workshop on Domain-Specific Modeling. de Saussure, F., Bally, C., Sechehaye, A., & Reidæinger, A. (1964). Course in general linguistics. London: Owen. Seidewitz, E. (2003). What models mean. IEEE Software, 20, 26–31. Selic, B. (2003). The pragmatics of model-driven development. IEEE Software, 20(5), 19–25. Silva Parreiras, F., Staab, S., & Winter, A. (2007, September 3–7). On marrying ontological and metamodeling technical spaces. In Proceedings 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT International Symposium on Foundations of Software Engineering, Dubrovnik, Croatia, ACM Press, pp. 439–448. Smith, B., Williams, J., & Schulze-Kremer, S. (2003). The ontology of the gene ontology. In Proceedings of 2003 Annual Symposium of the American Medical Informatics Association. Sowa, J. F. (2000). Ontology, metadata, and semiotics. In B. Ganter & G.W. Mineau (Eds.), Conceptual structures: Logical, linguistic, and computational issues, LNAI 1867 (pp. 55–81). Berlin: Springer. Sowa, J. F. (2010). Email to [email protected] on 9 December 2010. Stachowiak, H. (1973). Allgemeine modelltheorie. Wien: Springer. Tairas, R., Mernik, M., & Gray, J. (2009). Using ontologies in the domain analysis of domainspecific languages. In M. R. V. Chaudron (Ed.), MODELS 2008 Workshops, LNCS 5421 (pp. 332–342). Berlin: Springer. Ullmann, S. (1972). Semantics: An introduction to the science of meaning. Oxford, UK: Basil Blackwell. Walter, T., Silva Parreiras, F., & Staab, S. (2009). OntoDSL: An ontology-based framework for domain-specific languages. In A. Schürr & B. Selic (Eds.) MODELS 2009, LNCS 5795 (pp. 408–422). Berlin: Springer. Wand, Y. (1996). Ontology as a foundation for meta-modelling and method engineering. Information & Software Technology, 38, 281–287. Wand, Y., Weber, R. (1988). An ontological analysis of some fundamental information systems concepts. In Proceedings of the 9th International Conference on Information Systems, Minneapolis, 30 November–3 December 1988. Wand, Y., & Weber, R. (1990). An ontological model of an information system. IEEE Transactions on Software Engineering, 16(11), 1282–1292. Wand, Y., & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3, 217–237.

106

References

Wand, Y., & Weber, R. (1995). On the deep structure of information systems. Information Systems Journal, 5, 203–223. Wang, H.,Noy, F. N., Rector, A., Musen, M. A., Redmond, R., Rubin, D., Tu, S., Tudorache, T., Drummond, N., Horridge, M., Seidenberg, J. (2006). Frames and OWL side by side. In Proceedings 9th International Protégé Conference, Standford University, Stanford, CA, USA. Weber, R., & Zhang, Y. (1996). An analytical evaluation of NIAM’s grammar for conceptual schema diagrams. Information Systems Journal, 6, 147–170. Whitmire, S. A. (1997). Object oriented design measurement (452 pp.). New York: Wiley, Inc. Whorf, B. (1941). The relation of habitual thought and behaviour to language. In L. Spier (Ed.), Language, culture, and personality, essays in memory of Edward Sapir (pp. 75–93). Mensasha, Wisconsin: Sapir Memorial Publication Fund. Wikipedia. (2010). Homomorphism (accessed 2 August 2010). Wilmont, I., Brinkkemper, S., van de Weerd, I., Hoppenbrouwers, S. J. B. A. (2010). Exploring intuitive modelling behaviour. In I. Bider, T. Halpin, J. Krogstie, S. Nurcan, E. Proper, R. Schmidt & R. Ukor (Eds.), Enterprise, business-process and information systems modeling. Proceedings of the 11th International Workshop, BPMDS 2010, and 15th International Conference, EMMSAD 2010, held at CAiSE 2010, Hammamet, Tunisia, June 7–8, 2010, LNBIP (Vol. 50, pp. 301–313). Berlin: Springer. Yu, E., & Mylopoulos, J. (1994, May 16–21). Understanding ‘‘why’’ in software process modelling, analysis, and design. In Proceedings of International Conference on Software Engineering (ICSE), Sorrento, Italy, pp. 159–168.