UEML facilitates integrated model use by first making interoperable the languages in which the models are expressed. A central part of UEML is therefore a standard, integrative and evolvable approach to describing enterprise and IS modelling constructs. By standard we mean that the approach provides a structured path to describing modelling languages, diagram types and constructs. By integrative we mean that as soon as the languages, diagram types and constructs have been described according to the approach, they have also become well prepared for integration with one another, possibly across languages. And by evolvable we mean that UEML will be able to grow and adapt by incorporation and modification of additional modelling languages and constructs without becoming overly complex and thus unmanageable.
The descriptions of modelling constructs are particularly important, as they are more complex than those of languages and diagram types. Specifically, for each of the constructs in an enterprise modelling language, UEML separates the description of:
- Presentation (or 'concrete syntax'), which deals with the visual presentation of the modelling construct in diagrams.
- Representation (or 'semantics'), which accounts for which enterprise phenomena the construct is intended to represent (in particular covering reference, a central aspect of semantics). In the UEML approach, it is described by a representation mapping to a common ontology.
Whereas a construct can have many presentations, or concrete syntaxes, it can have only one representation (or semantics). The presentation here will focus on the representation part, which has so far been most developed in the UEML work (Opdahl 2006).
The UEML approach uses separation of reference to break individual modelling constructs into their ontologically atomic parts along six axes, where the two first axes deal with structure:
- Which class of things is the construct intended to represent? Most modelling constructs somehow represent one or more classes of things. Even if the primary purpose of a construct is to represent certain properties, states, events or processes, the construct implicitly also represents a property of, state of, event in, or process in, one or more classes of things.
- Which properties and relationships is the construct intended to represent? Most modelling constructs somehow represent one or more types of properties. Even if the primary purpose of a construct is to represent classes, states, events or processes, it represents a class, state, event or process that involves one or more property types.
The next two axes are similar, but deal with behaviour as opposed to structure:
- Which states is the construct intended to represent? Some constructs are intended to represent a more or less restricted state in one or more classes of things, the state restriction being describable in terms of the properties of those classes.
- Which transformations is the construct intended to represent? Some constructs are intended to represent a simple or complex transformation of one more more classes of things from one state to another. Again, the transformation can be described in terms of the properties of those classes.
Although some constructs are apparently not intended to "represent behaviour" at all, other constructs represent particular states or transformations or chains of alternating states and transformations, i.e., processes. Hence, together the two previous entries describe whether the modelling construct is intended to represent only the existence of some classes/properties or more specific behaviour.
The final two axes deal with instantiation level and with modality/mode:
- To which instantiation level does the modelling construct belong? A modelling construct represents classes, properties, states and transformations at either the instance or type level or both.
- What modality (or mode) is the modelling construct intended to represent? We usually think of enterprise models as assertions of facts about a domain, e.g., assertions that something is the case or is not the case in the enterprise. But some model elements may instead state that someone wants something to be the case, or that someone is not permitted to do something, or that someone knows something is the case¸ or that something will be the case some time in the future. We call such statements modal (as opposed to regular) assertions, i.e., we use the term "modal" pretty much in the "modal logic" sense.
Together, the six axes can be used to describe the semantics of an enterprise or IS modelling construct by describing the state-of-affairs that the construct is intended to represent, in terms of classes, properties, states and transformations, along with information about the construct's intended instantiation level and modality/mode. The representation meta-meta model in the figure (still missing) illustrates how languages and modelling constructs are described using separation of reference. The meta-meta model is based on earlier work by Opdahl & Henderson-Sellers (2004, 2005). The top layer of the meta-meta model deals with modelling languages, their diagram types and their modelling constructs. The bottom layer shows how individual constructs are broken down into their semantically atomic parts.
References
- Opdahl, A.L. & Henderson-Sellers, B. (2004). A Template for Defining Enterprise Modelling Constructs. Journal of Database Management 15(2).
- Opdahl, A.L. and Henderson-Sellers, B. (2005). Template-Based Definition of Information Systems and Enterprise Modelling Constructs. In Ontologies and Business System Analysis, Peter Green and Michael Rosemann (eds.). Idea Group Publishing, 2005.
- Opdahl, A.L. (2006). The UEML Approach to Modelling Construct Description. Proceedings of the 2nd International Conference on Interoperability for Enterprise Software and Applications (I-ESA 2006).