Echoes from the golden age of OO

OO-languages rules the programming language domain sovereignly. OOA method is quite evidently far the best way to begin application development process. How ever this fact was somehow lost in the middle of 2000’s.

Here is a short a retrospective of application analysis development methodologies from 1980 onwards. Behind this development and the case of it is the ultra rapid development of computers. Computers are latest category of technic evolutions and its rate of change has been phenomenal. Following this exponential technical development and understanding the development as a howle is extremely difficult because all the development in the past seems quite minimal compared to recent. So it is very difficult to give real credit to those steps in past as they seems so tiny compared to later ones.One example of this development is the following: IBM PC publisti in 1980 had a processor with 4,5 MHz clock rate and today the PC:s clock rates are around 2 GHz  ( =2000 MHz). This is about 500 time the original speed. This enormous change has very significant impact on the methods of working.

The development took us from relational databases to object-orientation. In late 1970’s Allan Kay and his colleagues created the first object-oriented language Smalltalk in Xerox’s development center Park Place. The language was commercialized in early 1980’s. This created development was continued with the rise of Object-Oriented Analysis. In this approach the world was viewed in terms of object and their relations.This phase started at early 1990’s. Among the first pioneers were Grady Booch, Peter Coad, Adele Goldberg and Jim Rumbaugh just to name a few.

I run into OOA in October 1989 in Peter Coad’s 2 day training in Stockholm. This occasion changed the course of my professional life. After half day’s lecture I realized that these people had understood something fundamentally important. Something that solves easily most of the acute application problems and this first impression proved to be true.

A couple years went and then we acquired the only solid commercial Smalltalk language from ParcPlace. We started to study OO-programming with Smalltalk. It wasn’t quite easy because it was very difficult to get any training, so the advance was based on selfstude.

When we developed our Smalltalk I continue to study OOA. To the end of 1990’s when I had  stated to work in software house and I started to give trainings on OOA. During the first half of 2000 decade I created a lot of AAO-models and develop the process to more abstract and agile direction.


My ADDD ( Abstract Domain Driven Development )

The OOA/OOD mature during first half of 1990’s. ( see: ) One of the latest and best book on this field is Grady Boosh’s Object Solution (1996). This is more or less a testament and of that whole field.

As a whole this was one of the greatest achievement in the history of computing. In spite of this I saw there a significant weakness that was revealed be the efforts to use this brand new methodology. That is the lack of separation of concerns. This methodology analysed application as a whole. This will increase complexity enormously. When OO-application development method on the other hand emphasised the 3-tier architecture where the domain and the application views were considered as separate layer. This led my to experiment to do the separation wright at the beginning of the analysis. That is why I called my method Domain Analysis. The difference was considering the domain – the interesting part of reality – as the object of the analysis. This way the application part was completely dropped. Then the second step is to create the object model of the application and this model was connected to the domain model by messages – as object always do. This allowed the domain analysis – and also the implementation – to be done without any knowledge. This meant a significant reduction of the overall complexity. This also allowed several application layer designs and implementation for instance for separate usages or implementation technologies.


Situation today

I wrote my my blog a tutorial covering ADDD : IT-Dinosaurus in WordPress from 2009 to 2014  I got a considerable amount of readers during those years. The peak number of visitor came between 2010 and 2014. One notable thing is also that most visitors came from India, US and Canada! Very surprising is the fact that there was still in 2016 the number of visitor was still 4500 and ranking of the countries was Canada, US and India.

In mid 1990’s I ( and also Grady Booch) thought that OOA/OOD/OOP would by the standard most common way to develop application, but it didn’t turn out that way. In early 2000’s the big database companies were afraid of losing their businesses to OO-databases and they started a big campaign to stop OOA usage and they came out with SOA, which was devastating for software industry development and took us backwards several step to history, but the old dinosauruses – the relational databases were able to maintain the market shares.

The thing that surprises me today is the amount of visitor to my old blog. It shows me that there are still a lot of enlightened persons in this field, that has rediscovered the true value and meaning of OO today.

Echoes from the golden age of OO

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.