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).