Model semantics and abstraction level

The key success factor in modelling and model value is the chosen abstraction level.  The next diagram is one of my favourites and it indicates the relationship between the concepts and the model’s chosen level of abstraction.

This way of drawing the triangle shape gives actually somewhat wrong idea of change of semantics when moving up in the triangle. The right shape is step triangle :

This actually means that the very tip of the triangle is semantically empty. I come very often across model which level of abstraction is in that area an which thus are meaningless.

When we consider the theoretic OO approach, then we start be defining our presentation (see. Axiomatic  OO  ) The next class diagram describes this:

The domain of this model is an object class model. This gives the form that the model has to confirm. This doesn’t say anything about semantic – this is a possibility of semantics.

Then we have a semantic aspect to the model. Here we also have a form for that, but it is considerable looser construct that the previous is. I have created a diagram of this too, but it’s form is my creation and it is not UML :

Here the meaning of the used signs are following:  This rectangle with its background colour presents a class category – a set of similar type of classes. The meaning of the category is shown in its name (this is by the way Peter Coads class colour categorisation).

The other used sign is a dotted line and a text these describes a possible association type between two classes from same or different categories. This also gives the model high level possibility for semantics.

A real OO-class diagram is a utilisation of this two possibilities such as the following:

All the semantic – this is actually the real beef of the model – is expressed in natural language. This materialize in class names, method names , attribute names and association names.

The trouble often with novice modellers is that they somehow wrongly think that the higher the abstraction is the more effective (the horrible term is reuse ) the model is. The sad thing is that the truth is almost exact opposite!  In these models class names a very generic and sometimes cryptic. A good sanity check is to take the class names to a business professional, that has not been in any contact with this modelling and ask him or her to explain these concepts. If the person either says that she or he doesn’t know or fails otherwise in more than 20% of the name, then there is something terribly wrong with the only valuable thing in the model namely semantics!

So if you come across following “domain model” or similar:

you will now know that this is a sad misunderstanding, a bluff or a lie and you are not misled or confused any more.

Advertisements

9 Responses

  1. Hi Jukka,

    Interesting article. I’m just wondering… if you have a model on a higher abstraction level it doesn’t mean you have less semantic value in them. The semantics stay the same, it is only defined with less information. The abstract and concrete syntax are much smaller, but the semantics are actually the same. The model will lead to the same application. Hence, one element in your model has much more semantic meaning than a model on a lower abstraction level.

    In case of MDD most semantics are defined by the code generator or the model interpreter. But that doesn’t mean the model contains a “smaller amount of semantics”. A (modeling) language always consists of abstract syntax, concrete syntax, and semantics.

    Maybe this is just a word-game. What is your definition of “semantics”?

    • Hi
      Well this starts to be semantics about semantic. Actually I do not know the precise definition of semantics and there is still this language barrier from my mother tongue (Finnish) to English. But the point that I try to make is that the level of abstraction (that is indicated the preciousness of the words used and the number of those words ) will define the extent and the level of detail that the model describes its target reality. Thus two model at different levels of abstraction doesn’t end up the same application. The reason for this is that a model at lower level of abstraction includes more details. This will narrow the freedom of interpretation of those details. The point here is that the domain model is a description or analyse of the target reality not the application. This is way the level of the abstraction of the model determines the accuracy that the analysis is passing foreword.
      In this way if the level of abstraction is too high the model doesn’t give any practical analyse of the target reality thus being void.

      In the same way a mathematical equation being a tautologies with zero semantics.
      Here a two extracts from Ludwig Wittgenstein’s: Tractatus Logico-Philosophicus ( which by the way is the earliest book of object-orientation)

      4.462 Tautologies and contradictions are not pictures of reality. They do not represent any possible situations. For the former admit all possible situations, and the latter none.
      In a tautology the conditions of agreement with the world—the representational relations—cancel one another, so that it does not stand in any representational relation to reality.
      5.142 A tautology follows from all propositions: it says
      nothing.

    • The abstraction level and the associated ”semantic”
      I do want to continue and try to be more concrete.

      Let’s take an inheritance chain which gives as 3 layer of abstraction of the same base concept. I chose my bas concept a “bullet-train” ie. a train that goes very fast, examples in France (Paris-Lion) and Japan.
      Now let’s lift the abstraction to “train”, most of the information (that I call semantics) is still present, but we have now ignored the fastness of the train. Now we definitely know this but we have chosen not to communicate that. Here the read doesn’t know that any more even as it is there.
      Let’s continue and lift the level of abstraction again. Now we will replace the concept “train” with more general concept of “vehicle”. At this point the reader lose a lot of “semantics” and he or she doesn’t for instance know that this our vehicle requires rails specially constructed for it! The things that the reader can anticipate and deduct about the consent have been reduced dramatically.
      Here is an example what I am aiming at when I say: “ level of abstraction reduces the semantics”

  2. […] This post was Twitted by softmodeling […]

  3. Jukka, thanks for going to lengths to explain yourself. Both you and Johan are actually correct:

    You are correct that the higher the abstraction, the less semantics. However, the semantics that is lost is incidental (e.g. a train is a vehicle, a motorcycle is a vehicle, etc..). The essential semantics (e.g. a vehicle to transport goods) is defined by the problem domain (top of the abstraction pyramid) and is not/should not be lost. As Johan mentions, this semantics is extended as implementation choices are made (e.g. we do not have a good network of railways, so trains are out; motorcycles can’t carry heavy goods, so we will choose trucks – see how incidental details (no railways, ..) drive decisions and lead to new details being added). In the end, the application is still what the problem domain needs – transportation of goods.

    Actually, the abstraction is useful even in this example as it helps to recognize incidental details. Imagine that in 5 years, railway network is extended and trains become a viable solution for the client. If the only model we had was a detailed, low abstraction model that states that we need trucks, then a developer may overlook a new transportation possibility. If the developer had an abstract model (stating only the need to transfer goods) then s/he would recognize that trucks are incidental and trains are acceptable as well.

    I think that your and many similar reasonings due to a popular and too simplified definition of model: A model is a simplified representation of a reality.

    The problem with this definition is that it makes many simplifications (that is abstractions) possible and gives no guidelines which are good. This gives rise to questions such as yours and e.g.: which model is better? they say abstract is better, how far should i go? But the other say too many details is not optimal as well? etc..

    The part that is skipped is that simplifications are alway chosen to answer question/objectives of a specific user. A more complete definition is: A model is a simplified representation of a reality. A valid model represents a (part of) reality to the extend demanded by user objectives.

    It means that model semantics is subjective/depends on context. What is meaningless to one user, has meaning to another. So my advice would be:
    – be aware that there may be other users with different objectives (and do not expect their models to be meaningful for you perspective)
    – always understand what your objectives are and do not raise level of abstraction more then needed (if train experts draw vehicles in their models, then they went too abstract).

    • Hi Andriy

      I agree with most of you comment. There is though something that I don’t understand. The first when you say:

      However, the semantics that is lost is incidental (e.g. a train is a vehicle, a motorcycle is a vehicle, etc..).

      I don’t understand what you mean by incidental. To my mind it is not incidental at all as I understand it is systematic and structural and is actually a conscious decision of the abstraction level by the modelling team.

      The essential semantics (e.g. a vehicle to transport goods) is defined by the problem domain (top of the abstraction pyramid) and is not/should not be lost.

      Fully agree! The choice is critical and this is actually the chosen level of abstraction. If we go one step further into higher abstraction our Vehicle is replaced with Entity and here we have lost all the semantics and I cannot interpreted this to nothing else that mistake or error.
      Your following summary is precisely what we agree upon. The very reason to abstract (= simplify) is to emphasize some aspects of reality over others from some point of view. This point is chosen by the people for their practical reasons only!

      The part that is skipped is that simplifications are always chosen to answer question/objectives of a specific user. A more complete definition is: A model is a simplified representation of a reality. A valid model represents a (part of) reality to the extend demanded by user objectives.

      I remain also that I have been writing about these earlier in this blog. (see for instance:
      https://jukkatamminen.wordpress.com/2010/09/01/the-difficult-concept-of-model/)

      • Hi Jukka,

        Actually, the correct term I should have used is accidental complexity. To address this complexity, additional abstractions and models are needed (hence, what I a bit shortly called incidental semantics).

        In our logistics example, abstractions truck, highways, etc.. are accidental, because the reason why they exist in development of this logistic system is accidental. In words of the example: it happens so that we do not have good railways on a part of the required route and we do not want (for some reason) use multimodal transportation, hence we choose the truck alternative).

        Notice that the decision is conscious, and the approach by the modeling team may be systematic and structural.
        However, the complexity (and associated models) resulting from this decision are not inherent to the application. When railway network improves and logistics is moving to trains, this (accidental) details/complexity/decisions/models/abstractions are not reflecting the reality anymore. In contrast the essential complexity/abstractions will remain.

        You say: “Fully agree! The choice is critical and this is actually the chosen level of abstraction. If we go one step further into higher abstraction our Vehicle is replaced with Entity and here we have lost all the semantics and I cannot interpreted this to nothing else that mistake or error.”
        I agree with one reservation: Entities have too little semantics for developers of this logistics application. However, ontologists and e.g. developers of language workbenches may disagree.

        I followed your link and see that we actually agree on what is model 🙂

  4. “if the person either says that she or he doesn’t know or fails otherwise in more than 20% of the name, then there is something terribly wrong”

    strongly agree!

    brief remark: 0% wouldn’t be optimal either, since the wording in most companies needs some clean up. Think, 1% really adopted by the stakeholders would already be a success.

  5. […] This post was Twitted by modelpractice […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: