How-to: Modelling Static OO-Models

Type: Rules


Good practice guidelines in case you want to model the static view of a system, on business level

Principles and Notes

R1: Only model what you think is really important to say. There are a thousand ways of modelling some part of reality.

R2: Don't put more than 5-9 important elements on a page. Go to a hardware store if you need new wall papers.

R3: Each model should not exceed one physical DIN A4 page (US: letter format; some say DIN A3, which is twice the US letter format). Use multiple models of you really need them.

R4: Model cohesive parts as one unit (class). Parts are cohesive if they are (almost) always together, like user first name and user family name

R5: Loosely couple non-cohesive parts

R6: Every class, every association and every generalization has a business requirement that makes it necessary
Note: Careful here, you have to decide whether you want to model "the world" in general, or with the specific system in mind. Don't mix up things you know about the world with something you need because you have requirements stated for it. If you feel you really need a relationship, go and find that requirement. This is called the art of leaving things out of the model. (<- Guido Zokoll of

R7: Think twice before using aggregation and composition. As Rumbaugh put it, aggregation is a way of saying something about your personal point of view

R8: Think twice before using a generalization if you cannot come up with a discrimminator for it within 30 seconds.

R9: Be extra careful with multiple inheritance.

R10: A lot of «include»s are a symptom of functional decomposition (<- Ivar Jacobson)

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License