The state of OO -development in 2017

I have started this blog on OO application development in 2009 and posted the last post on this issue in 2014.

The core of my approach is centered on abstract domain OO – model. To created these models one needs deep understanding of the underling theoretical concept. This can not be achieved just following a set of rules. The divider is the abstraction level and thus the model size. If the abstraction level is too high the model has no value. It dos not promote the understanding of the domain. If the abstraction level is too low, it is even worse because too much detail prevent the possibility to separate important from unimportant and the just isn’t a way to return. So too detail model poisons the whole process.

A just right model create a great opportunity not just a good and flexible domain implementation but also for user interface part of the application, because early separation of concerns will dramatically reduce complexity of both sides.

I started to write the posts at late 2009. It has gathered 48 000 hits all together. I have posted my last OO article early 2014. The OO did not concur the world as I and Gready Booch predicted around 1995. For this reason I am gladly surprised the current hits at my blog currently. For most of the time my readers came from US, Canada and India, but almost the whole world was covered.

I have retired 3 years ago and I don’t have a hands on touch in the current development trends. My current surprise is the activity around my blog in 2015 and 2016 there were about 4300 views and 2000 visitor yearly and most visitor came from US, Canada and India. Even this year there has been about 1000 views and 580 visitor from the same countries. I am both happy and honored about this.

I would be curious to know the motives for these visits and the current state of OO development in the field.

How to learn object-oriented domain modeling?

I have taught quite many people their first steps on their path to domain modeling ( more that 1000 persons).

These students have had very many kinds of backgrounds. More that have have been IT-people and majority of them have had high education in computing. The rest of them have been the becoming users of those target organization developing their applications. The education and profession among these people varies a lot. So I have very wide spectrum of experiences trying to explain what an object-oriented mode is.

The fundamental requirement to start the journey is the basic understanding of OO. These are “the rules of the game” like the basic moves of the piece types in chess. If you don’t know these you just can not play!

In OO the most fundamental aspect is the concept of object. Object is a “whole” is has to sides structure and behavior. In OO there is no behavior without at least one object. There is no action or behavior outside objects! If one doesn’t get this then there is no hope. It seems that there is small part of people, for whom this is too much or too difficult!

When one has accepted this, then the journey can begin. The first and most fundamental feature of and object is that they all are unique in the whole timespan of the universe. This fact is reflected in the identity attribute of an object. We could agree, that the ID attributes are never shown in the model but every class have one. It is also important that the ID attribute is not combined with and other natural attribute. The second thing that I always teach to my student is that all object has a life span. So what all objects have in common are birth and death. Actually in OO the biggest issue is how and why objects are born and die. When one masters this then the rest is really easy.

When we start to create an OO- model it is easiest and most natural start from static features and start to create class model. It is always easiest to start from concrete sustainable things like house or person.

When we start to create a class model with class diagram before drawing the first class box just list a few names of the most obvious class candidates. The very first crucial thing is the name of the class! I should always be chosen with care.

At this point one should also name a few ( 2- 6) most relevant attributes to give shape for the class with a brief description of class. In most obvious cases the description in unnecessary – like class Person, but if there is any doubt or the usage is in any way restricted then write the description.

Almost immediately after you have a few class in your diagram you should add all necessary relation between classes. Most important of these is association. These give the world semantic shape.

Now it is time to open up our example model. This is the simples possible model and I have used this for modeling trainings as well as for Java-trainings.

The domain is is a classical bookstore. The model will be quite abstract to keep it simple. Let’s start with very concrete classes. The fist one is a class that I have had in almost every model that I have done. It is Person- class. In this class belongs about 7 billion individuals on this planet. The other completely obvious class in this domain is Book. If we want to lift the level of abstraction we could have chosen the name Publication for this class also. I will use Peter Coad’s color notation in my UML- diagrams.


I have left the ID attributes out from this model.

When my students have worked with this model the Book class has proved to be somewhat confusing. The type of objects that belongs to my Book class here are the contents of the books. In concrete terms one could think that my book is actually the original manuscript of the book or the copyright of that book and not a single print or other kind of representative of that content. This is why I have an attribute inStock, which is the number of copies of that particular book in my shop.

The next thing to consider is perhaps the most challenging aspect of OO- modeling. Jim Rumbaugh described it: “objectified events”. This means that when OO model consists only objects and to enable us to include event also in the model, we have to change event to objects. Well there is no magic in this. Event/moment object is an object which is an abstraction of time slot. This means that every event-class has two attributes: start time and end time (sometimes this can degenerate to time). The color for moment/event is pink. More advance is to model behavior for this events.


When we consider what are relevant events in our domain considering the business in this context. When I have asked this question from my students almost always the answer is purchase. Well this is really the most prominent event and right answer, but here is also an other not so oblivious but from the sale point of view more interesting event is Walk. This is an event that enclose the customer’s visit to the shop from the event of entrance until he arrives to the cash. Here are the two events:

The behaviors of a Walk object are for instance pickup a book, end the walk, return a book that has earlier been picked up. A purchase is responsible to carry out the transaction.

The last step with class model (and diagram as well) is to add all the relation between classes. In this case we don’t have any inheritance so all the relations are associations. The digest category of association between entity classes and collections. For this reason this type has a graphical notation (a diamond). An association between a entity object and an event object is almost always participation. So the associations in our model between entity objects and event object are participations and then there is an association between two events. The type of that is creation or “mother”. Here the walk object creates the purchase object. So our full class diagram is following:


Now we move deeper into the dynamic of the model. The tool that we use is collaboration diagram. The name here is important because the diagram presents the process the sequence of action where a set of these objects in collaboration with each other achieve some important goal. Here the key process start from entering the shop and end at the payments of book bought. So this is the process that we have to cover and describe with objects. The steps in this process briefly: 1) entering the shop: the person object creates new walk object. When the person finds an interesting book and takes it with him: person object sends a message pickUp( the book) to the walk object. When the person decides to end the walk: The person object sends end() message to walk. This will create the purchase object and finalize the purchase.


Now our abstract object model for our bookstore is ready to launch the next step. These model are never finished but they are ready for advance. Modeling is both incremental and iterative process.

This process cannot be automated and there is no set of rules that would change this process routine or trivial.

This all means that it is quite easy to create some OO model representing reality, but the quality of the model can vary dramatically. To archive a meaningful abstraction that really help understanding the reality requires very high skill and experienced modeler.

The walk objects are actually the strongest tool for sales promotion. They can also give weak indications very early where the market is going. When I am giving my two day training after going though bookstore I will give the first exercise for my student. That is following: Create a model of library, so that it cover lending a book and returning it. The first question here is what is the most important event in this domain. In many cases the students quite well learn from the webstore and bring in walk event. But in the library model (at least if we think it is a public and free service like in Finland) the walk is a possible event in the model but of course the loan event is actually the most interesting one(and actually the only necessary event).

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!

The three gems of software development

Buddhists talk about Three Gems:

  • Buddha: the enlighten one
  • Dhamma: teaching
  • Sangha: literally means ‘community’ or ‘assembly.’

Here are similar thing for Object- Orientation. The difference is the later are strictly non religious, but there in spite of this some similarity and that is the belief in one’s own case. These are:

  • The paradigm
  • The abstract business model
  • The agile incremental 3-tier application development

The paradigm: To know and understand the OO- principles and also to understand it paradigmatic nature. This means that the world is perceived abstractly as a set of objects such that:
* all of them have two aspects: structure ans behavior

* they can collaborate with ease other

* there is no other kind of action possible in the world

The abstract business model: The development has to be started with creating an abstract domain model from scratch. Of cause one can use for this something like the business line models as I have presented here as a starting point. But even then every class have to be evaluated and checked that it is defined to this company and describes the current reality correctly. The model have to have all essential business behavior embedded in the model. The most important aspects in the model are objectified events, there behavior and object associations.

The agile incremental 3-tier application development: To succeed in this phase is crucial.

To continue this line of simplicity the architectural structure is the final cornerstone of this application. The maxim simplicity is achieved when the implementation keeps the three aspect: 1) application functionality, 2) domain functionality and 3) object persistence as separate as possible. Here a must is that domain objects have no functional references anywhere outside the domain itself. There are minimal references from application layer to into the domain. And the domain objects should have one references each to outside service that provide the persistence. The optimal solution would be such that the object virtual machine provides that service automatically into an object database.

This is the final phase to really deliver the concrete application. Next important aspect is to create the application incrementally and iteratively. One mustunderstand that the abstract domain model from previous steps is more of a starting point than end result which will grow in size during the development. On the other hand it is vitally important the first model is relatively small and thus will clearly describe the most important structures and behavior. This means that this model should have most of the structures present ie. most classes and associations are present but major part of attributes can still be lacking.

Done this way yield to minim solution thus minim amount of work and this enables indirectly maxim quality through simplicity.

The most is achieved when the model covers all activities of the company and the application layer is a comprehensive operation management and control of the company ( like ERPs today)

The simplicity of business logic in models and implementation

For a long time this simple fact has been very obvious for me and my colleges when we have modeled business and implemented these as part of application development.

I think that the procedural paradigm has left a strong but false myth about complex business logic with a lots of code to implement it. I would like to open your eyes to see the truth. For some persons this might be embarrassing inconvenient in many ways because some people are billing lots of money based on this belief.

Lets start our tour from a small domain model that I will then somewhat extend and lets look what the deepest business processes really consists of.

This is of course a WepShop. This is extremely simple business domain ( and the model is still strongly abstracted) so this serves nicely as the first example.

All businesses live in time cycles. Then typically there are a few sets of this cycles according to their typical cycle length. Here we have two. The radius of the smaller and more active one is from a few minutes to typically less than hour. The radius of the second bigger circle is for weeks to years. Lets start from this. This is the process of acquiring book to the shop. When we talk of a real old style bookstore, the cycle was ( still is) from week to month sometimes years. The publishers send out catalogs and the shop owner chooses his selection and makes an order. Then the copies are printed and deliver. If the are not soled from the shop they must finally be dumped somewhere.

In a webshop the situation is of course somewhat changed. The physical copies don’t even necessarily have to be move to any “store facilities” but can the sent directly from the publisher to the customer. The other option is (like Amazon) that the webstore actually have some distribution center that serves as intermediate warehouse and the logistic center between producers and consumers. In this case the business process is to create the agreements and create the mechanism to choose the right products and deliver them to the distribution centers. So the only thing that shows up here in our abstracted business logic is the method newBook() in person. Even this class in a bit wrong place to put it, but in this case we have no better.

The other cycle ( the one the emphasis in the model is ) is on the selling side. In short the process is following: 1) the customer enter the shop 2) he/she asks for a set of books or stars to wander around to see if there is anything interesting. He/she pick up books. 3) He/she ends the visit at the cashier and makes the purchases.

In the model this is show in the nutshell as creation of two event-objects namely the walk and the purchase. So the process is totally contained in the following chain of method executions. 1) Person-object creates new walk and sets its parameters. 2) The walk send a message pickUp() to each interesting book. 3) Person-object sends endWalk() to the Walk-object when he/she in done. This method creates new Purchase-object and move the selected pick-ups to the Purchase-object, which finalize the process by collecting the payment.

All these methods are highly trivial. This ends the business behavior.

Now lets jump to me healthcare model ( see :

Here the core business process is:

  • patient reserve a visit from a doctor.
  • the visit is started

  • the doctor create a patients status

  • based on this and the patients heath history the doctor creates a diagnoses

  • in some cases doctor needs some laboratory results to reach a diagnosis.

  • and start to treat the discovered disease.

  • finally doctor schedules an control visit.

This will show up as the following sequence of method calls:

It start at doctor-object with method newVisit(). This will create a visit and associate it doctor and patient. This visit then creates a new status with newStatus() and populates its attributes and bind its associations. Finally it will call this new object with diagnose() method to create a new event-object in the class on Disease. Next it will call disease-object with treate() method. This will create a new treatment-object and the circle is closed.

The conclusion is that all the business logic of all current businesses, when we talk about operation management and control is purely question of logistics. This is in most cases transformed in a sequence of creation of event-objects. So finally the businesses logic boils down very simple sequence of creation. This actually repeats over all typical business. When we look at the total business function this operation control and managements is only the simplest part of it. The in many cases there is what I would call “intelligent part”. In the question of healthcare this is all the accumulated knowledge of human physiology, chemistry and diseases and the deduction process to healing a sick person. An other example is insurance. The operation management cover the business from a insurance agreement through its life cycle events and this is very simple logically. This doesn’t include the complex risk analysis of the products and individual agreements.

These these real intelligence part are way out of the scope of von Neumann computing, but currently people are creating learning highly complex neural nets that potentially in future can accomplish these kind of tasks.

Domain model for person’s social life

This is a domain model for SoMe type of applications. In the center of this model is quite obviously class Person. This differ from typical business model because it is much harder to decide what to include and what to exclude. Also the level of abstraction need consideration. Here I have stayed on a pretty high abstraction level to give my readers most clear picture of the most essential structures.

There are a few very concrete entity classes: Person, Place and Building ( which can be a subclass of place). Then there is also a more abstract entity class Organization, which can be for instance a company in which one works at or a club where one belongs to. At first the class Place looks very innocent, but after consideration one find out that it is a tricky one. Basically it is a geographical spot or an area. How ever it must be able to handle well-defined distinct areas like an named city: Helsinki of a square: Trafalgar  square and on the other hand it must cope with more fuzzy are like southern Helsinki  of western Kent.

Then we have these most essential events around the person. This list start with simple things like where person is or is heading. At the other end of that spectrum are events like activity and participation.

Here is the class diagram:


The human social networks are all take care with event call relationship. I have added here also a classifying description type class Circle.

Here are an object diagram and a collaboration diagrams. The object diagram is a case with part of John’s social network. The other one have two short collaborations where Jim creates an activity and buyes a concert ticket.

Social network (object diagram)

Collaboration to create an activity and buying an ticket.








Difficult OO concepts: type, class and object

I have just read an article from a Finnish magazine about Scala. It contained confusing claims about OO implementation with OO languages. It have come across this argumentation earlier but it still remains as mystic to me as on previous occasions. I am convinced that it is a complete misunderstanding. The line of thought is combining OO- programming and functional programming in a way that is not even in theory possible. Similar lines of argumentation were earlier present wit OO- programming languages and SOA and this of course proved to be false too.

I must start once again from the very beginning. When we create an operational business application the domain model is the core of that. The business layer is typically only 10 – 20 % of the whole application code but the importance of it is in most cases 80 – 90 %. The implementation of this business layer is almost automatic generation of the OO domain model.

The domain object web is a many to one mapping from reality to the model. This means that the objects in the business layer has their corresponding objects in reality. This way ever real object and its corresponding model object has an identity and thus a life cycle. This means that all business object in the implementation are born and die according their counterparts in reality.

Let’s expand from object web to analysis and domain class model. Classes are classification instrument for real objects. Class gives a simplification of a category of real object. Is kind of minim commonality among objects that belong to this category. This way the classification gives an object a type.

Now when we have finalized our abstract analysis of reality and we have created the domain class model as an highest level abstraction and a few object level fragments (called collaboration diagrams), the implementation reverses the order and start from classes in the implementing code.

Sometimes when people come from strong programming background and the modelling and reality for application mapping is not that strongly emphasized, they loose this visibility. Somehow the techniques of language structure confuses these persons. This way the crucial fundamental of an identity gets lost. This way someone quite sincerely uses complex number as an example of an object. The fact is that it is NOT an object! In an OO- programming language we use class definition for two different purposes:

1) to describe object type (classification) or

2) to create “object like” structures that are NOT object!

The second choice is actually a misuse! It is quite convenient to use this structure in this way and it is quite OK, if the users understands these two aspects and don’t confuse them.

Day is a type for an event but it is not an object. Every technical event object requires at least one binding association to some real object to become a real object! We can of course technically create “an day-object”: myDay = new Day(); . But myDay is not an object because it doesn’t have an identity and there is no real thing that this artefact maps to. The only thing that can be said about this thing is that it is “an object-like structure”. This means that it has private attributes and public methods, but it still is not an object! The time semi object is transformed into a real object when it is associated with a real object. This gives the time object indirectly an identity. After this an event is not any more a template but a real event (in past, present or future). Then it is identifiable and unique in the universe.

A third way of misuse is to create a class and on object that has only behaviour. Here the confusion steams from something like sub function or a procedure. This is a fatal confusion and indicates that the designer has not cached up the object idea at all. Disconnecting a functionality from its context will definitely destroy the whole OO paradigm and its benefits.

Eric Evans in his book Domain-Driven Design in the chapter Services warn about this thing in the beginning of the chapter, but surprisingly he then accepts “Manager” or “Control” type of classes. My strong opinion has always been that this is a fatal mistake. Everywhere that I have seen this done it has lead to complete procedural programming with OO- language and this has always let to dome sort of disaster. One of the reason explaining Evans position is the week separation of implementation layers: application and domain. For instance value-objects belong to the realm application implementation. There are quite a lot of trick that we still have to do during implementation – sometimes for instance value-objects. The reason behind this is the extremely poor implementation platforms. Such problems should be take care of in the platform “operating system layer”, but this is not the case today far from it!