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.

Advertisements