OO model driven application development; the state of art and for the foreseeable future

OO model driven application development; the state of art and for the foreseeable future

Purpose of a model

There is (and has been) a dream of creating “application from models”. The trouble has been that the meaning of this phrase has not been analyzed at all. There is a serious mistake in OMG’s approach. For some curious unknown reason the concept of model is not clearly understood. The serious misunderstanding is about role of a model and then the subsequent amount of detail in the model. The main purpose of a model (even quite theoretically taken) is to simplify the part of reality that the model models. This is done by reducing the reality’s amount of detail to a manageable amount. This is as it should be and a good thing. But because of this fact a reverse is not (even theoretically) possible. Once the detail is gone there cannot be any way to return it back just working from the model itself.  This means that there is no way in which generation from more abstract model could produce (or generate) richer and less abstract models or code. This means that first we work hard to get rid of detail and then we work hard to return the necessary detail for each application. Now someone could ask: “isn’t it then more effective to work with the detail rather than go back and forth?” The answer is definitively no! As the complexity of the target domain grows the benefits of doing this grows exponentially!

The process is the following:

  1. Create an abstract domain model. This model simplifies the realty. The level of abstraction ( read simplification) is a controlled process. One can say that there is almost a natural constant (like for instance Plank’s constant in physics) for the number of classes in best models and this optimal number is between 30 and 60 classes. This number has nearly nothing to do with the particularly domain in question. This number mostly reflects human capacity to manipulate complexity in one shot. This domain model have to be a simulation model that fully (but simplified) describes the target domain both essential structure as well as behavior.
  1. 2. Use ALWAYS the following 3-tier architecture

  1. 3. Implement the domain model almost one-to-one. Of course the number of attributes have to increase because in analysis state we deliberately take only the most important ones not all.

  1. Design the required GUI conversations for all the necessary workflows
  2. Use some good OO-database to implement the persistence. Actually the wording here is wrong because the term OO-database is contradicting concept: (seeJ

The role of code generation during this process

The MDA’s false idea is that you can “generate more than you actually have”. This thinking somehow bypasses or confuses the simplification that is the core of abstraction. When you abstract you definitely simplify. This means that more or less detail is ignored and thus the model doesn’t contain this. Then there is no way bringing that back without human effort that knows it and places it back again.

There is definitely a role for generation from abstract domain model. But a proper scope of it has to be understood. From the model’s point of view everything in the domain layer can and should be generated. Of course this will still lack majority of attributes and consequently the corresponding methods as well. We can generate the class structure, all the navigation throughout the network, all the identified method signatures and getter and setter for identified attributes. This is substantial but of course lacks a lot. The most efficient way to implement the method bodies is to write the for example in Java. The implementation of persistence layer is rabidly chancing and SQL databases are becoming obsolete. So in most cases the persistence base solution can be generated but it can require so tuning at the volume testing and when starting production. The situation is worst in application layer. The first and a crucial point here is that the designing of a good implementation for a workflow is a difficult task and it have to be done very with implementing various solution.  This task is so complex that to achieve a good solution the only proper way to do it is an agile iterative and incremental. Of course one big drawback here is the primitiveness of all the current tools and development environments.

About understanding and communicating an object model

A model by definition is a simplification of reality. The main reason for model is always a simplification of existing or a design of something to be. Sometimes as an extreme a model can be one-to-one, but calling that a “model” is actually somewhat misleading.

The reason to have a simplification of something in most cases is the fact that the total amount of detail would be unmanageable and not understandable and for this most general reason we use models.

As we model concrete 3D things like houses we can have the model in 3D also, but the size of the model is far smaller than the size or the real thing. The downsizing evidently will disregard or destroy some amount of detail and simplify the model compared with reality . Another way of modelling these things is a mapping done from reality (current or future) to some kind of language. In the case of building this language consists of geometrical figures, which maps to realty. For instance a floor plan consists of together joined rectangles and a set of other graphical signs like door and windows.

To understand meaning of a model implies that the person in question is able to “see” the corresponding reality trough the model. If we use a mapping from reality to not self-evident language (like in case of house plans or maps), then the prerequisite for understanding the model is the knowledge of the discreption language.

Understanding is not a two-value function (on ; off) but a complex multi value thing. Thus it is very risky to say that a person doesn’t or a group do don’t understand the model. Rather we should consider to what extent someone understands the model.

It is obvious that the more complex the model is the more difficult it is to understand all aspects of the model. Even the “understanding” concept is difficult. The complexity of a model depends on two independent sources: 1) the domain in concern intrinsic complexity and 2) the chosen abstraction level of the model.

The complexity of the domain cannot directly be influenced. Indirectly this can be influenced by limiting size of reality to be modelled. The level of abstraction is completely in hands of the modellers. The semantic descriptiveness of a class and its level of abstraction has the following dependency with ease other:

This means that when chosen the level of abstraction of a class this with determine the semantic content or richness of the concept. So the lower the level of abstraction is the more semantic meaning the class name (&definition) will have. Of course it is good to have as much semantics as possible but the contradicting demand is to reduce the amount of less important details to promote understanding.

To balance the model between these demands the most effective choice is somewhere in between the extremes (the orange line in the figure). A very important aspect of OO-model creation is that towards the end of modelling a given domain the emphasis is on simplifying the model as much as possible without losing its semantic weight or value. This means that we approach a point where leaving something away will have a dramatic effect on the model collapsing it totally. Here the model has reached its complexity minim (at a given semantic level). If someone then demands to reduce the complexity of the model being too complex to understand this will mean no model at all!

The abstract object model consists of a class model and a set of collaboration diagrams. Class model contain all the classes ( concepts) found during the domain analysis and all the relationships between the classes. This class model can be represented in one or several class diagrams. Even if the model is represented in more than one class diagram the model itself is always one and connected. It is moderately ease to show that this model if it is correctly done is in the complexity minim of all models.

I will continue with understanding the model. First we have several different methods to model reality. Some of them are structurally simpler than OO-models like for instance use cases which have hardly any structure at all. Then we can move the whole model (ie. all classes) up and down the semantic-abstraction triangle. If we chose very high abstraction level we loosed a lot of detail and we will have a simple model. So simple models are far easier to understand than the models that have more structure, semantics and more fine grain behaviour defined.

The best OO-model in the middle of the triangle is most effective model. Thus it leads to most effective implementation as an application.

The model include also a set of collaboration diagrams describing a few cases with the deepest and most important sequences, which describes some instances of  creation of the most important event object of the business cycle. These diagrams consists of objects not classes. For this reason the are very concrete and far easier to understand. Sometime we can draw additional static object diagrams to explain complex structure without any messaging.

Stubborn confusion with behavior

All the way from the early days of OOA (late 80’s and early 90’s ) it was crystal clear the description of procedural  and object behavior are strikingly different.  There is no right or wrong, they just are the same thing from completely different viewpoints. They are orthogonal abstraction of the same thing.

The most significant thing that created object paradigm was just this difference. This is a paradigm issue and thus the difference has a strong antagonistic nature. This means that you must choose and there is now way of mixing these together.

The big step in deeper understanding simulation modeling was that object collaboration yield to a magnitude simpler model than the corresponding procedural one.

This is a simple fact of reality and it can never change. This means that it is logically impossible that ever anywhere could come any new information that could change this.

Somehow most of IT community lost this crown gemstone of OO. First came use cases as Ivar Jacobsson introduced them. He had actually good intentions but he was misinterpreted and his idea was turned upside down. Then came components and after this activity diagrams. Now the newest names for procedural description are processes and SOA!

I saw somewhere an article where the writer praised “the blessing” of the fact that we “get rid of spreading the behavior and we can collect that all in one place”. This very thing was just the reason or drawback which was cured be bringing the structure and behavior together and distribute responsibilities between object. In this way we got two layers of behavior with first layer encapsulated within the objects. Then the second layer is the collaborations between objects.

We can actually prove this reduction of complexity today with the huge help from microbiologist Stuart Kauffman. Our practical experience tells us that the simplification ratio in average case is 1: 10.      

My motto.: The Use Cases (by whatever name) are evil so retreat  to collaboration.


Unambiguous language and DDD

The real purpose of OO-modeling is  – as modeling as whole – to create abstract simulation of the world. The closer the model follows the structures of reality and the corresponding behavior of the associated parts the better the model simulates reality.

For this reason it is vitally important that all the concepts are clearly define and unambiguous.

I have been developing Smalltalk and Java application since 1994. All of these have been built starting from scratch an abstract domain model and finally implementing this as the middle tier of and application. In my experience the most crucial thing here is right model of the world itself. This means that the business understanding is crystallized in the model. This means that the understanding, the language it is expressed is equivalent with the model. These are the same thing. Thus you don’t actually need a separate glossary because your class and attribute definitions is that glossary!

Yes! This is the most crucial thing of all. When this is right everything else goes smoothly if this is wrong there is very little to be done to correct the situation. More of this at my web-site and of course in Grady Booch excellent book:  Object Solutions ISBN:

Finally a quote from that book:

 The center of gravity of an object-oriented information system should be its domain model.

·         Get this model right, and your task will be much easier.

·         Get this model wrong, and abandon all hope.