The core of things

The OOA-paradigm has been around for 20 years. It merged at the switch of the decades from 80’s to 90’s. The first three books that I know from that time were Peter Coad: “Object oriented analysis”, Grady Booch: Object-Oriented Design and Jim Rumbaugh: OMT.

All of these presentation clearly emphasized the difference between procedural and OO: the analysis of behavior and its place was profoundly different. The two important things here are encapsulation and collaboration!  These things doesn’t exist in procedural. This is totally crucial.

My approach and these early writes approaches differ also. These writers quite unanimously model the system ( the 3-tier system) with OO-model. My approach starts with creation of only the domain model with little or no knowledge about the application. When done in this way we need nearly no requirements of the application. The only thing that we need is the business focus in the reality – the interesting structural and behaviour subset of the world. This will postpone the digging of most of the details connected to application usage and workflows and takes it up at much later state in the agile development process.

When you read my model examples and if you catch up the idea in my collaboration diagram then you have seen the light.

The collaboration diagrams are the core of the core!


Domain model for car retail and maintenance

Here is a new business line domain model example. This time the business is car sales and car life cycle maintenance. This is again a business line model and it will require further development if one really wants to use it for a car retail chain.  The class diagram is here:

Here are a couple of collaboration diagrams just to give a hint in which direction I would like to see the responsibilities distributed.

Car maintenance

Car sell

The difficult concept of MODEL

The concept of model has become very popular and thus the meaning of the term has be contaminated or at least watered down. The more general and fuzzy meanings are associated with a term the less that terms really  communicates anything. (see wiki:

A Oxford dictionary entry of the term model:

  • a simplified description, especially a mathematical one , of a system or process, to assist calculations and predictions:

So (at least for me) a model is a simplification of some part of reality. In this way there is some kind of mapping from reality into the model. This contains model “semantic” or “meaning”. So formally

For all x from {SubReality} is f: f(x)-> m from {Model} ; where f is a homomorphism but not isomorphism onto Model.

If the mapping is allowed to be isomorphic then the model is without simplification (1:1). This could theoretically be possible but gives no real value as model.

Thus this axiom implies disappearance of detail. This way we lose the part of semantic information that we have. The amount of the lost information is controlled by the level of abstraction of the model. The whole point of modeling is this reduction of detail. This is done to understand the structure and the behavior of a complex target domain. In this is vitally crucial to destroy part of the detail to reduce the complexity of the essential things.

A user has to understand the relationship between application window and reality. This is exactly the domain model. When I am making a flight reservation I must understand the correspondence between an airplane leaving from Helsinki airport to London and the following text:
AY5905 HEL 07:50 LHR 09:00
This means that I have to have the model in my head.
Now from a model like this about 50% of the middle tier implementation can be generated. The reason is most simple: because that is all the information that this model has! The entire application tier have to be understood, design and implemented. Here the model has nothing to offer.