How to create a OO-model

OO-model consists of class model and a set of collaboration diagrams.
I like to emphasize that classes form a model not a diagram and collaboration forms diagram. This means that one can have several class diagrams, but only one model. In the case of collaboration models equals diagrams – so they are one-to-one.
Modelling is pure analysis. When we model is about some no-existing future then question of analysis and design is more complicated. Still to keep things strait and simple I would like to call modelling analysis.
These outcomes are both necessary and sufficient. So nothing else is required. They together are a simulation model of the target reality. This means that the class model gives the static form of the world and names the most important distribution of business responsibilities. The collaboration diagrams give the objects cooperation aspect to the model.
I get a task to create an OO-model with a group of business people from some organisation.
The steps:
First we get introduced. I start telling how I am, why I here and what is my background concerning OO-modelling. First I ask everyone to introduce themselves. If there is the luxury to star with the team form a modelling training, then we spend two consecutive days in training mode. Well in most cases this is too much! So Normally I give an about 3 hour super-rapid introduction to OO-modelling. The goal of this intro is to give the modelling group the most basic skills to read class- and collaboration diagrams and to have enough understanding about the mapping between the model and reality.
Then we start the modelling. The first thing here is to have someone who deeply understand the business and the current operation describes the operation in his own words. Then it is fairly easy for me to tack a catch from this and list a few most obvious candidates for classes. Here I try to choose businesswise most fundamental concepts. At the beginning of the modelling it is good to get the participant start to think very precisely and define these very familiar concepts. It is very important that the classes are clear, distinct and crisp edged.
Here is a simplified example to illustrate this. Let’s have a book shop that need to have a new operation control system that enables the business to extend to web also. We start to create an object model of the business. The owner of the shop tells us that this is a street level shop: They have separate section for different book categories like: Fiction, Non-fiction, Hobbes, Cooking, Travelling, etc. We have a few customer types. Someone comes in and want just a particularly book from a given author. Some regular customer comes periodically and asks new books from their favourite authors. Other regular customers come in and just wanders here between shelves and pick up interesting book and buys some of them.
Now we start with the class definition part. Let’s pick class candidates like: Person, Book, BookCategory Purchase. Now we add corresponding associations. Our starting class diagram looks following:

Next thing is to add attributes and descriptions for these classes.

Here we actually have the business core of a CMR application. One sidestep on our path, a remark about CMR. Here everyone can clearly see that a minim set of classes required is actually what you see here. The important thing here is that something to be CMR (ie. customer something..) needs both the customer either role, person or organisation and a set of products. A customership concept is not a specialized subset of role concept. It is actually a relationship between a role entity and a set of products (or product description). The essential thing here is that the whole product catalog is needed within the CRM application! Without it is worthless. But let’s get back to our business.
Now we have each person’s purchase history. So this information gives us some means to categorize a buyer. At this point the shop owner turns the focus elsewhere. He starts to talk about customers visit in the shop. He says that the personnel have some time been talking of interesting information that they don’t have. This is the books that the customer have picked up and scanned trough but decided not to buy.
Then I will interrupt and say that this is very important finding about the business. Let’s put that into our model. But how is that done? Well we are modeling reality and we are emphasizing important aspects of it. This mean that we need an event that catches this behavior. Let’s call in Walk. This is an event that starts when the person enter the shop and it end when he/she reaches the cash. Now we will associate all the books that the person pick up during his/hers walk.

If this would be a model of an electronic shop, then it would be very easy to collect this information. Actually this Walk is very close to Shopincart consept implemented in most web-shop implementations. Expandind the shopincart to walk gives us menthaly easier way to all aspects of the Walk thap could also called Visit. Now you can start to ask question like: How the visit are distriputed timewise? What is the time distripution of these visit? What is the ratio between visit length and total purchase and so on.
Now how does this model behave. He I will add a collaboration diagram without any explination:

The nextextention of this model could be the quetion of customers loger term behaviour, vip-customer and so on. Adding here a Role class add alot of these possibilities.


4 Responses

  1. Here you describe OO-model creation from business point of view. It is important aspect but not only one. Yet, the mindset you have tend to show different picture of world: one sees trees when looking a forest, another sees flavors of green. So let me say few words from implementation (technology) point of view.

    A couple of days ago I end up writing code to handle electronic books (ebooks) and do some things with them. I thought that it would be nice to build a OO-model to clarify programs structure – well shame on me but I actually didn’t do. Instead I started to write code and experience with it. In my mind I had a clear vision of “Book” class, and i wrote code for it. But soon I realized that ebooks are packed in zip format and most of code relates to extraction of content. That lead me to split Book class to two: Book containing something and Container containing zip stuff. So, the conclusion is that I found need for a need class during coding – as can be expected when doing iterative development. And that information would never come up by doing OO-modelling from business point of view. It would have required long prestudy of technology involved, which is against agile principles (IMHO).

    Now what I like to ask you, is this valid way of doing OO-modelling? If so, should one try to include all aspects of problem in same model; meaning this kind of technological aspects that have nothing to do with actual business cases, or would it be wiser to start aspect orient OO-modelling? “This means that one can have several class diagrams, but only one model” is an answer, but is there real benefits for doing so or is just a dogmatic approach.

    And thanks for the nice article.

    • The modeling approach preached here, on this website, is *abstract* domain modeling. Abstract in contrast to concrete, or “implementation” model.

      The abstract domain does not care whether you store you’re books as ZIP files or in XML. That’s part of the implementation phase.

      This means that the model is on higher semantical level, and does not take into account the format or packaging of the book. Just the Book.

      You describe the thing you’re working on in very general terms, so it’s a bit difficult to help you out, but the name of your class (“Container”) sounds too generic. Container of what? It could be anything. The semantic level is too high.

      Anyway, it sounds like a case for the Factory pattern. You would have a BookFromZIPFactory that would take as input the path of the ZIP file, and return a Book object with all the attributes filled with the ZIP contents.

      Single Responsibility Principle states that one class should only handle one responsibility. So, you have correctly separated the code that handles the extraction of ZIP contents into another class. Good.

      I’ve done only a couple of models, but my understanding is that the pre-study does not have to be a long one, and does not conflict with agile principles.

      • Thanks for your advices as3contrarian.

        My models are very simple and there is no need to focus on semantics that much. Factory pattern is definitely a better way to handle that, so should fix this. Still, the open question is: Should I add BookFromZipFactory to the model? Or should there be a different model for *implementation*? I have always done one-to-one mapping with classes in the model (the one and only model) and classes in the code. Are you saying that this is no-good?

      • Dear Friends

        The initial question from Ilpo (istenber) is valid and very good! Basically Mikko (as3contrarian) with his answer is on the right track about the level of abstraction and the semantics.

        My answer here is twofold.
        The two sized of this issue are
        1) the incremental agile approach and its influence on the way model is handled
        2) The logical 3-layer “canonical architecture”. ( see: chaper 3)

        So lets start with the 3-layer. Here the meaning and responsibility of the model and finally the model layer is to be a picture of the world ie. the reality. This means that no part of my domain layer is the real think but a picture – a reference – to that real thing. In this way an implementation of a book in the domain layer is always a reference to the book in reality. Earlier the was no danger of confusion as the book was a set of paper pages tied between the covers, but when the book becomes a digital thing it can be save and handled in the computer in an very similar way as its reference. However I urge you to keep the concepts crisp and sharp edged! This digital thing is not any content! It is the book. So this book digital or physical it should be technically placed in the application (ie. left-most) layer and not in the model layer.

        The other aspect is the agile incremental approach. This requires that the first model to be most effective must miss quite amount of the details. Of course this amount in practise is heavily influenced by the size of the system, but by experience it has become clear that through increments as the amount of detail increases it is good to have actually also two models of domain: the initial “abstract” one and an other one “technical” or domain implementation model. In most cases the number of classes increases very little if at all but the number of attributes an methos in the class will definitely increase

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: