Ontological and linguistic metamodelling revisited: A language use approach
Introduction
Conceptual modelling is used in information systems and software development to enable conceptual understanding of the systems, the information they contain, and the processes by which they come about. Conceptual models facilitate the understanding of information systems requirements and, more generally, enhance the quality of information systems development. Conceptual modelling is a term commonly used to indicate modelling in the software context that is independent of the constraints of programming languages. It focuses on the description of real-world (business-focused) problems and how to represent them in models and could therefore be loosely related to requirements engineering, business systems analysis, and enterprise engineering.
Modelling uses a modelling language to communicate information about the models, be they for system design or for processes and methodologies. A modelling language consists of, inter alia, an abstract syntax, a concrete syntax (notation)1 and semantics. To ensure quality and consistency, modelling languages need to be clearly defined so that their use is consistent across development teams, countries, etc. Much of the work in modelling languages for computing contexts (software engineering, information systems) over the last several decades has been focused on ‘general purpose modelling languages’, such as the now standard Unified Modeling Language™, UML® [1], [2]. More recently, domain-specific modelling languages (DSMLs) have been intensively researched and developed to practical solutions [3]. Here, we focus on general purpose modelling languages and eschew discussions about DSMLs.
Although there are several ways of writing down formal definitions of modelling languages, one frequently used is that of the metamodel, defined as ‘a model of models’, which defines the abstract syntax, often itself expressed using UML’s notation (typically a class diagram) together with additional behavioural and semantic constraints (perhaps using OCL or a similar logic-based language). Metamodels focus on the concepts and rules of the methods and models used in information systems development and software engineering [4]. Metamodelling, i.e. how to create metamodels, is an important research area because there is a need for shared conceptualisations in software and systems engineering in order to avoid misunderstandings and barriers of communication in the development of IT systems [5]. Consequently, the application of metamodels is increasingly recommended. The use of metamodels for conceptual modelling, especially in the context of software engineering, has a relatively short history, in comparison to its much longer use in database modelling. The (early, 1991) CDIF standard was based on a three-level hierarchy (as summarised more recently in [6]). A few years later, suggestions by Carmichael [7] and Henderson-Sellers [8] led to the proposal to use this approach to bring together the plethora of object-oriented modelling notations then extant [9], [10]. The first standard to utilise this idea of metamodelling for object technology standards was the UML [1], standardised by the Object Management Group (OMG), which introduced the four-level hierarchy of Fig. 1, with an expressed aim of providing an infrastructure “to support the creation, manipulation and interchange of meta models” [11]. It provides a metametamodel at the top layer, called the M3 layer (or MOF: Meta-Object Facility). An M3-model defines the language that is used for building metamodels, which are understood to define modelling languages at the M2 layer. The most prominent example of a Layer 2 metamodel is the model that defines the UML. These M2-models describe elements of the M1-layer, which are thus models written in UML. The elements in these M1 models each represent concepts pertinent to the real-world (or computer world) domain under investigation. Individuals classified as conforming to a concept are often called ‘instances’. An instance is seen to be atomic, as compared to concepts and classes that can be represented mathematically by sets or categories e.g. [12]. (Other multilevel constructions are well presented in [13], wherein the linking of language-based and model-based approaches is similar to that in [14].) However, in the end (p. 290), the author [13] eschews a language use focus in favour of the (to-date) traditional structural (a.k.a. linguistic) metamodelling framework, as employed by the OMG.
“The primary responsibility of the metamodel (M2) layer is to define a language for specifying models” whereas the purpose of the M1 layer is said to be to define a language that describes an information domain [1, pp. 7–8]. Thus, Class belongs to the M2 layer and Horse (an instance of Class) is part of the M1 domain language. The last layer is the M0-layer, said to describe run-time instances [15, p. 17] or objects of the model – thus emphasising UML’s focus on software objects rather than objects in the real world. Notwithstanding, some authors interpret ‘M0’ as being the ‘real world’ – as seen in some diagrams abstracted from extant literature.
In the first versions of UML, there was an M2 class called Object, which led to confusion as to whether instances of this class existed at level M1 or at the more natural M0 [16]. Consequently, in Version 2, the M2 Object class was replaced by InstanceSpecification. This allows for instances of InstanceSpecifiation to be created as part of the M1 model, despite referring to an M1 entity. The UML documentation [15] thus notes that the instances at the M0 level should not be confused with an instance of an InstanceSpecification, which is used simply as an illustration (a snapshot) of the class, e.g. Prancer:Horse (or the more anonymous:Horse) at the M1 level is not an instance of the class (type) Horse – according to the OMG documentation of the UML. This is obviously confusing, and the problem occurs because of the use of ‘strict metamodelling’, which is the basic principle in the linguistic metamodelling utilised by the OMG. This principle states that the <<instanceOf>> relationship is always between adjacent meta layers, and that it cannot exist within any single layer. The ‘strict metamodelling’ principle also states that if a model A is an instance-of another model B then every element of A must be an instance-of some element in B [17]. Thus the <<instanceOf>> relationship is a type–instance relationship between a model element at the type level (classifier) and its instances. However, it is unclear how the objects at the M0 relate to the world. According to [15, p. 16] “The things that are being modeled reside outside the metamodel hierarchy” but nothing is said about how they relate to real-world things. In other words, the focus of the M2 layer is said to be that of ‘language’ and that of the M1 layer to be a ‘domain language’; there is nothing said about how language relates to the world. As a consequence, confusion prevails as modellers believe, contrary to the above quotations from the OMG literature, that M0 model elements are real world entities rather than models (or run-time instances of model elements) of the real world entities (see Fig. 1 above which is an adapted version of [15, Fig. 7.8]. We will later show that the relationship between the model ‘objects’ at the M1 level and the real world things is not that of type–instance but is a correspondence relationship (see also later discussion of Fig. 12).
Another modelling domain in which instanceOf relationships between layers have been adopted is that of domain ontologies. Domain ontologies are frameworks for organising information and are used in, for example, the Semantic Web, systems engineering, software engineering, information architecture and information standardisation as a form of representation about the world or some part of it. Domain ontology engineering aims to make explicit the knowledge contained within a specific area of interest, typically in the real world e.g. newspaper industry, wine industry. Establishing such a domain ontology both advises and constrains the modeller to using only concepts of the domain ontology in their (conceptual) model.
The creation of domain ontologies is often labelled ontological metamodelling in software engineering [18]. In a nutshell, Fig. 2 shows a typical example of so-called ontological metamodelling in which a class in a (say UML) model (here Shetland Pony) is argued to be an instance of another class (here Breed) that is therefore ‘meta’ to the first class (Shetland Pony) but, paradoxically, cannot be considered to be part of the underpinning metamodel (right hand side of Fig. 2) [18]. In a number of papers, possible resolutions of the so-called ‘linguistic versus ontological metamodelling’ debate [4] are explored. For example, Atkinson and Kühne [19] analyse various multi-dimensional representations that combine ontological and linguistic modelling styles into one diagram – an example, called by them the ‘Orthogonal Classification Architecture’ [20], is shown in Fig. 2, later developed into the Level-agnostic Modelling Language (LML) [21].
Fig. 2 also perpetuates the ambiguity problem noted above regarding whether the symbol labelled ‘Object’ is an M2 class that is an ontological instance-of Class (which it must be if both Object and Class are in the same linguistic level) or whether ‘objects’ (perhaps by definition) belong to level M1 (as depicted in Fig. 1). In the latter case, we can take the Object–Class–Metaclass chain as illustrating the core of the M0–M1–M2 chain of Fig. 1. Thus, considering the problem posed by Fig. 2 in more detail, we could interpret the Prancer–Shetland Pony–Breed chain2 of instanceOf relationships as paralleling this M0–M1–M2 chain. Thus, if the latter three concepts denote three different metamodel levels (M0, M1, M2 in the OMG hierarchy of Fig. 1) then, it is argued by several authors, surely the former chain can be interpreted in the same way, i.e. the Breed class is a metatype with respect to the Shetland Pony class. But clearly such a Breed metatype could not be expected to be part of the M2 layer defining the UML, i.e. one would not expect nor wish to find a Breed class alongside a Class class in an M2-level metamodel of a general purpose modelling language like the UML.3 This wish to create a parallelism between the O0–O1–O2 chain of Fig. 2 and the M0–M1–M2 chain of Fig. 1 in which Breed (O2) is somehow regarded as ‘meta’ to the Shetland Pony class creates a paradox since clearly Breed can never be a metaclass in a MOF-based modelling language (such as UML).
Since contemporary metamodelling uses a type–instance pattern as its core technique, a further serious theoretical problem can be identified with the architecture of Fig. 1 [14]. Accepting that multi-level modelling involves a ‘chain’ of two (or more) type models introduces a serious concern, since this is contradictory to the set-based rules of modelling by which a type model links a type with objects conformant to that type – a relationship that is only valid over a single pair of contiguous metalayers (Fig. 3), since an instance (e.g. Horse as an instance of Class in Fig. 3) cannot be further instantiated since it is already an individual (an object – an object is an instance of a class in object-oriented modelling). In other words, a concept cannot be an instance of another concept – an assertion also strongly supported by theories of language use, such as speech act theory [23] (see also later discussion in Sections 4 and 5). What appears to occur in practice is that developers insert an isotypical mapping from this instance (called obj1:Class in the right hand side of Fig. 3) to a Horse class in the model (M1) domain [14]. Since Horse is now a class, according to this argument it can be instantiated and create a number of objects of type Horse at the M0 level e.g. Prancer:Horse, Dobbin:Horse.4 However, this is argued [14] to be ‘only a trick’ that is ‘far from acceptable as part of the foundational ideas of an engineering discipline.’ There are two arguments proposed in [14]: (1) ‘The real classes are not derived from UML but from the objects derived from UML, by developers that use their subjective judgment to synthesise them as necessary’; and (2) ‘modelling tools implemented as software systems (as most are) need to implement a fully formalised modelling infrastructure in order to support the necessary functionality. In our experience as both modellers and modelling tool implementers, using instance-of relationships only is not enough to achieve this, and additional workarounds must be added to traverse the “hidden” isotypical mapping’ – as described in [14].
The problems described above can be related to the nature of meaning, language use, and the relationship between language and world, which are the main topics in speech-act theory, one of the core theories in the philosophy of language. In this theory, the focus is on analysing what speakers and listeners do with language in communication and a distinction is made between sentences and speech acts (utterances). However, they are dependent on each other if we want to understand the notion of meaning. For example, the sentence “Prancer is a horse” can be used to perform a speech act in a specific context and then (1) the pragmatic meaning of the sentence is established by the performance and interpretation of a speech act in that context. This means that the same sentence, when uttered, could have a different meaning in different contexts. However, the speech act performed is also dependent on (2) the linguistic meaning (semantic or standard meaning) of the sentence used [24, p. 69]. We claim that the problems described above arise because the domain language at the M1 level has not been analysed in terms of speech acts used in a context, but only as a formal sentence detached from its actual use. To quote Searle [23, p. 17] “It would be as if baseball was only studied as a formal system of rules without the game”. This means that if we analyse the M1 level based on speech-act theory, we can better explain how a language at the M1 level is related to the world, i.e. to its problem domain, and thus resolve these problems. Furthermore, to date, the focus of modelling languages such as UML has been the description and definition of that (artificial) language by use of a metamodel at the M2 level (often with additional OCL constraints). Little attention has been paid to our understanding of natural languages and language use, and how this natural language-focused knowledge may be useful for defining and using artificial modelling languages for software modelling at the M2 level.
Language philosophers and linguists analyse natural languages and their usage in their search for underpinning rules, under which conditions a given utterance or sequences of utterances are meaningful (i.e. acceptable to all concerned) [23], [25], [26], [27]. This is based on reconstructive analysis of language use. Thus, the analysis is based on utterances and the rules that people must follow in order to succeed with these speech acts and is essentially a reconstruction exercise. This analysis discloses that there are general functions in language, and that people must comply with certain general rules and conventions in order to be able to use these functions when they communicate. These functions are quite independent of national differences and contexts, despite the fact that the concepts and terms used differ, which implies that language and its underlying rules are dependent on local variations and on different contexts of use [28], [29]. Thus the conventions and rules of natural language are implicit and in constant flux under the pressure of the language use in different contexts [e.g. 30]. In contrast, modelling languages, and domain ontologies are artificial and, although they too evolve, they only do so by someone explicitly and formally changing the underpinning rules – the reverse of how natural spoken languages evolve. Those modelling language rules may be embodied in a Prolog-style set of rules, in an ontology, in a metamodel, or some combination thereof [31]. Thus, the contrast between natural languages and modelling languages is that the rules used in natural language are much more implicit and are learned and changed over the years as people use them in everyday life. Modelling the requirements for an IT system, which then have to be translated into formal language systems such as programming and database languages, implies that, by using a modelling language, it must be possible to bridge the gap between informal and formal languages as well as between reality and the conceptual model that forms the basis for the design model. Indeed, a modelling language like the UML purports to span both conceptual models and design models. This implies that, during the development process, different user groups and system developers have to come to an agreement about how the rules of the M1 level language should be designed and implemented in a formal language system. This also implies that the metamodels used to define and analyse modelling languages should also be based on an understanding of natural language use, and not only on formal languages. Our approach is based on the assumption that the problems described above could be the result of omitting the language use aspect in traditional metamodelling.
In this paper, we therefore start to examine the traditional, metamodel-focused construction of modelling languages (cf. Fig. 1) in the context of language use, and specifically speech act theory. We adopt a conceptual–analytical research approach [32] and apply these language use ideas to the problems introduced by the “Orthogonal Classification Architecture” (OCA) (cf. Fig. 2) that is often called the ontological/linguistic paradox. As noted above, the paradox is that it is assumed that (1) Breed is a metaclass of Shetland Pony, and that (2) Prancer is an instance of Shetland Pony, and Shetland Pony is an instance of Breed, which involves a chain of two or more type models. The aim of the paper is to solve these problems and to present an alternative metamodelling architecture based on language use. In the analysis, we draw on typical modelling examples from the literature [5], [18], [33].
The paper proceeds as follows. In Section 2, we explain in more detail the ontological/linguistic paradox. Section 3 describes the powertype pattern upon which the OCA (Fig. 2) is based (although this is typically not explicitly acknowledged by MOF-based modelling approaches). In Section 4, we then describe concepts used in foundational ontologies, a pragmatic theory of meaning and speech act theory. Based on this understanding, an alternative approach to metamodelling is proposed, and the problems of the OCA architecture are solved in Section 5. In Section 6, the ontological/linguistic paradox is reassessed – especially with respect to the views propounded in [33], and the powertype pattern. Section 7 concludes our analysis and the solution to the ontological/linguistic paradox is elaborated upon in more detail and a tentative metamodelling architecture is presented. We illustrate the practicalities of our language use based approach over those previously proffered using OCA and powertypes. Finally, in Section 8, we provide some pointers for possible follow-up research.
Section snippets
The linguistic/ontological metamodelling ‘paradox’
All modelling and metamodelling (the latter just a specific application of modelling techniques to a more abstract domain e.g. page 290 of [13]) relies on the notion of a model representing a set of entities (often called a ‘system’) by means of an abstraction mapping [34]. Linguistic metamodelling (i.e. the modelling of languages, see Fig. 1) focuses on the use of an abstraction mapping that is many-to-one, creating a type–object relationship, and one in which the language used at the type
A possible resolution – using powertypes
Powertypes were introduced to software engineering to help address the concerns of representing classes, their subtypes and their instances [35], essentially from a set-theoretic viewpoint. In particular, the use of powertypes for modelling software development methodologies provides support not only for method design but also for method enactment [36].
Although powertype patterns [37] are seen more frequently in metamodelling treatises (than in modelling), they have in fact a long history in
The need for a foundational ontology and a pragmatic theory of meaning
Sections 2 and 3 have shown that there are no immediately satisfactory solutions to the ontological/linguistic metamodelling paradox. In Sections 5.3 and 7.1, we will present improved solutions to the ontological/linguistic metamodelling paradox, based on a language use understanding of metamodelling. However, in order to do that, we have to pave the way by describing the need for a foundational ontology (Section 4.1), a pragmatic theory of meaning (Section 4.2) and an understanding of natural
The Breed–Collie–Fido relationships analysed from a language use viewpoint
The purpose of this section is to analyse metamodelling from a language use perspective. The basic idea behind the analysis is, rather than to try to map domain languages and ontologies into the OMG four-layer hierarchy (see Fig. 2, Fig. 4), we investigate first how language operates (Section 5.1) and how we can use that knowledge to propose an alternative metamodelling approach based on speech act theory (Section 5.2); and later show how the problems of the Orthogonal Classification
Other proposed solutions
A number of scholars have previously attempted to analyse and explain the linguistic/ontological paradox that arises from OMG’s four-layer hierarchy (Fig. 1) and the Orthogonal Classification Architecture (Fig. 2). In this section we will reassess these solutions especially with respect to the views propounded in [33]. These authors deduce correctly that the distinction between the intension and the extension of a class is important to consider. Hence, Gašević et al. [33, p. 11] conclude that
Metamodelling based on language use
The analyses of the metamodelling literature presented in this paper have identified a number of problems. A basic problem is that the architectures (OMG and OCA) analysed do not provide any explicit theoretical foundation based on foundational ontologies or meaning/language theories. In particular, they do not relate to language use theories. It is also unclear how these architectures relate to set theory and formal languages used in mathematics, programming and database languages. This is the
Conclusions and future work
In this paper, we have analysed typical modelling examples [5], [18], [33] by using speech act theory and foundational ontological concepts to show how semantics (linguistic meaning) can be explained in terms of pragmatics; i.e. how sentences are used in acts of speech. Based on this analysis, we have resolved the linguistic/ontological paradox, which is the main contribution of the paper. We have also proposed a tentative metamodelling architecture based on language-use, thus offering a
Acknowledgements
We wish to thank the extensive and very helpful comments of the anonymous reviewers of the original draft of this paper.
References (82)
- et al.
Modelling software development methodologies: a conceptual foundation
Journal of Systems and Software
(2007) Bridging metamodels and ontologies in software engineering
Journal of Systems and Software
(2011)- OMG, UML Semantics Version 1.1 (ad/97-08-04) and UML Notation Version 1.1 (ad/97-08-05),...
- ISO/IEC 19505, OMG Unified Modeling Language (UML2.1.2) – Part 1 Infrastructure and Part 2 Superstructure,...
- et al.
Metamodelling for Software Engineering
(2008) Matters of (meta-) modelling
Software and Systems Modeling
(2006)Metamodeling in EIA/CDIF – meta-metamodel and metamodels
ACM Transactions on Modeling and Computer Simulation
(2002)Towards a common object-oriented meta-model for object development
Methodologies – frameworks for OO success
American Programmer
(1994)
Object-Oriented Metamethods
On the Mathematics of Modelling, Metamodelling, Ontologies and Modelling Languages, SpringerBriefs in Computer Science
Model-driven development: a metamodelling foundation
IEEE Software
Rearchitecting the UML infrastructure
ACM Transactions on Modeling and Computer Simulation
Concepts for comparing modeling tool architectures
The level-agnostic modeling language
On the search for a level-agnostic modelling language
Speech Acts. An Essay in the Philosophy of Language
What is universal pragmatics?
How To Do Things With Words
Explorations in the Functions of Language
The Theory of Communicative Action
The relation of habitual thought and behaviour to language
Quantitative analysis of culture using millions of digitized books
Science
An ontology for software development methodologies and endeavours
On metamodeling in megamodels
Granularity in conceptual modelling: application to metamodels
Power types
Journal of Object-Oriented Programming
Connecting powertypes and stereotypes
Journal of Object Technology
Object-Oriented Methods: A Foundation. UML Edition
Machines, Languages, and Computation
Cited by (42)
PRISE: A process to support iStar extensions
2020, Journal of Systems and SoftwareMulti-level ontology-based conceptual modeling
2017, Data and Knowledge EngineeringA conceptual framework for large-scale ecosystem interoperability and industrial product lifecycles
2017, Data and Knowledge EngineeringIn defence of deep modelling
2015, Information and Software TechnologyCitation Excerpt :Eriksson et al. therefore relegate such types to a kind of property or label attached to instances of the supertype (c.f. the “functional relationship” between “Fido” and “Collie” in Fig. 11). In the example, therefore, Eriksson et al. view “ShetlandPony” as “a moment individual of the Breed class” [18, p. 2112] so that “Prancer” essentially has a “Breed” feature whose value is “ShetlandPony” [18, Table 4]. We note that, if true, the criticism by Eriksson et al. would have far and widespread consequences.
Understanding supply chain resilience through conceptual modelling techniques
2023, Journal of Modelling in ManagementOn Abstraction in the OMG Hierarchy Systems, Models, and Descriptions
2022, Proceedings - ACM/IEEE 25th International Conference on Model Driven Engineering Languages and Systems, MODELS 2022: Companion Proceedings