Before technical discussions: a terminology

Before going further, I realised that it may be better for us to share basic terminology. Our purpose is practical: we wish to exchange concepts clearly, with the following two practical ends: understanding each other, either in agreement or in disagreement; and positioning scribble in the global picture of MDA artifacts, in particular in the UML/MOF infrastructure.

There are three basic terms we treat: model, metalevel hierarchy, and model transformation.

(1) Model

In the UML/MOF literature, we often say "models". If you happen to know about mathematical logic, you will soon find out that "models" in the UML/MOF sense is different from those in logic. For example, a standard notion of a model in first-order logic (FOL) means an interpretation of a syntactic formula in the concrete universe of sets and relations (predicate symbols are interpreted as relations).

So, for example, a formula Eq(1+1, 2) (which we usually write as 1+1=2) is interpreted as the equality relation (interpreting the predicate Eq) between an interpretation of 1+1 and that of 2: constant symbols 1 and 2 are interpreted as the obvious natural numbers and + as an addition function.

Practically, when you do such a modelling, you first decide what is the target of interpretation (which we often call universe of discourse, or UoD) and then consider an appropriate map from each syntactic construct to an element/function/relation in UoD.

I wrote a bit about this since the idea of UoD and its relationship to syntax is often useful when thinking about UML and related models. But at this point we just note the following: this logical notion of models is not the notion of models in UML/MOF. There, a model means:

A description of a piece of software abstracting away some of its features in which we are not interested for our present purpose.

The idea is that for many kinds of business communication, many kinds of decision making, and in general through many stages of software development, we do not wish to go into all the details. Or from a different viewpoint when you wish to design software, either a huge information system or a small application, you start from some vague ideas which may not be fully specified but will nevertheless tell us what it is about. So we need a model --- and we need to scribble a model for interaction.

From now on when we simply say "model" it is used with this UML sense, not in the logical sense. But we shall also keep the logical idea of models in mind.

(2) Metalevel Hierarchy

The next is a review of the standard metalevel hierarchy in UML/MOF. People interpret this in varied ways, but let's be practical, from the viewpoint of how we use it. In essence:

Fix a level of your modelling: then its meta-model gives you a set of rules how you can describe (scribble with pencil, draw a picture with CAD, type up using a linear syntax, ....) your model in that level.

Well this is not the whole story in UML/MOF: we usually assume a stronger relationship between entities in two levels in that each node/association in a model often has its meta-node/association in the meta-level, which allows us to have a very good way for transformation and also a good way to bootstrap (once you understand UML, you can understand the format of MOF). So our definition is a bit loose: and perhaps this is not too bad after all given we after all need a bit of OCL to define well-formedness of UML models (as this document says: the main point is that the definition of UML demands not only syntax but also static semantics, or well-formedness rules).

Now onto the hierarchy, given below in the concrete case of UML.

• M3:this is the meta-metamodel level, giving rules for specifying M2. Concretely this is MOF, offers a grammar and constraint to define the specification rules for UML.


• M2: this is the metamodel level, giving rules for specifying M1. Concretely this is the UML itself, including its syntax and semantics, offering specification rules for UML models which are at M1 (M2 is often called UML metamodel).


• M1: this is the model level, which is our target: we wish to have a model of software, or a description of a model of software. Concrete UML models reside in this level, for your pet application or a large corporate system.


• M0: this is the instance level w.r.t. M1, in which realisation of models in M1 at specific space-time reside. If we have a model in M1 it may be realised in a memory electronically as a linear syntax or graphically or perhaps you will write it down by pencil and these instances relates to a UML model residing in its metalevel, M1.

Our interpretation of M0 may not be agreed upon by all: people often say that this level is about "execution". Let's not worry too much about this point however since what really matters is done at M1 and above. Here a crux (for practical convenience!) is to put UML models in their concrete syntax in M0, while keeping those in abstract syntax in M1. This fits well in practice when we wish to treat extra information such as geometric information UML models in graphical syntax have (such as position of nodes) in addition to what their representation in abstract syntax says: you do not want an up-side-down diagram even if their abstract syntax is the same, don't you? Yet all in all what essentially matters is M1 which is transformed by the rules stipulated w.r.t. metamodels at M2.

So we are taking M1 to be described in abstract syntax: this makes our discussions simple and precise.

Observe that the same meta-level hierarchy can be considered for other languages than UML, which is precisely why we have M3: in particular, we can consider each programming language , say Java, as making up such a hierarchy.

(This view is not so strange since any programming language is also a modelling language except that a PL usually demands us to specify all details except with respect to some feature such as abstract classes, interfaces and such. And some language is even equipped with an assertion method, or DBC as is seemingly more popular in MDA community. This viewpoint becomes important when we consider model transformation in the next item.)

Finally: from the viewpoint of the logical notion of models mentioned earlier, we can consider each level in the hierarchy as either containing syntactic entities or as being a UoD: one of the useful formal discussions of relationship among four levels in the latter's viewpoint can be found in the work written by Bezivin and Gerbe in 2001.

(3) Model Transformation

Model transformation is at the heart of MDA. We consider only a specific case:

• Assumption: We have two metalevel hierarchies which shares the identical M3 (say MOF), say source and target respectively (source hierarchy and target hierarchy can be identical, since we wish to do for example UML to UML transformation).


• Transformation: This is specified at M2 once and for all, so that it maps each M1-model in the source to a M1-model in the target. This in effect also induces a transformation at the level of M0, perhaps with a minor elaboration. The transformation function stipulated at M2-level is helped by two meta-models sharing M3, but can be highly non-trivial.
  

So we can have transformation from UML to Java, UML to XML, etc. as far as their metamodels are specified in MOF. Having the same M3 gives common foundation to related metamodels.

In practice what is important for such a transformation is to be meaningful (or useful): should preserve certain structure and meaning. This notion of meaningfulness can however be discussed only for each concrete case (even if UML is fullly formalised there is no way to have general criteria for meaningfulness).

In practical MOF-oriented transformations, we also need be concerned how features and classifiers relate with each other: we shall discuss such aspects as needed. Also it is M2-level mapping (hence operating on M1-level entities) that we care: and we are most concerned with the mapping from a high-level modelling towards implementation.

* * *

Now we are ready to go back to the questions we asked in my previous post (link). We shall start from clarifying our first criteria, why it matters to describe operational behaviour in interactions in concurrency unlike in the modelling of sequential programs.