High productivity in software development

It is relatively easy to show that abstract domain model driven agile application development is at the absolute complexity minim within all know application development methods for von Neumann computers.

This means of cause that this is most productive way to do it.

This method starts with creating an abstract domain model for the organization from scratch. This activity can takes up to 15 working days from analyzing group but in average is less than 10 working days. The result is something that I call object-oriented abstract domain model. It consists of one class model (named classes, a few essential attribute, core business methods and all class relations: associations and inheritance trees).

This abstract model states the essential business process requirements in a very rigid object-oriented languages. This is actually the most compact and coherent presentation for these requirement.

The next step is to design the necessary work flows into GU-conversation that are based and supports the earlier created domain model.

The implementation follow the three-tier architecture, where the domain layer is completely separated from the rest of the code. The implementation start from selection the hardware and software platforms for this implementation. The next step is to generate the domain layer skeleton from the domain model. After this the implementation proceeds incrementally adding both application and domain behavior simultaneously. This all happens in close direction of product owner and the becoming user community.

The ratio of the code sizes between three layer are typically following. The domain layer including all business logic is between 10 – 20 % of the code. The size of persistence layer varies the most depending on selected db solution. This depend heavily on the environment. If one has several old databases behind the new solution, this will require substantially code between domain objects and databases. If one can use one new relational db, then one can use JPA framework and reduce this work. My favorite is object database, which end up with least work. So this layer can be from a few percentage up to max perhaps 40 %. The application will then fill up the 100%.

The model generation will create in average 50 – 90 % of the final domain layer code. So if your ready application consists of 100 000 lines of Java then the business layer take 20 000 lines and all business logic methods about 4000 lines.

I have published here business line abstract domain model. Still I insist on doing it “ from scratch”. The model I have provided here should be used to guideline the modeling and they can be used for jump start for a novice modeling group to avoid very drastic mistakes. The model is after all the hart of the system and its design. Its influence to the whole system is many time more important than its ratio in code lines.

In may next post I will tell my experiences on how to learn to analyze reality and create these models. When I start doing this 20 years ago I thought that this is very easy for all of us but I proved bitterly to be wrong in this!

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.