Principles of Modelling Static OO-Models

Name:Principles of Modelling Static OO-Models
Type: Principles
Status: Draft
Version 2007-05-24
Gist: good practice guidelines in case you want to model the static view of a system, on business level

P1: Only model what you think is really important to say. There are a thousand ways of modelling some part of reality.
P2: Don't put more than 5-9 important elements on a page. Go to a hardware store if you need new wall papers.
P3: 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.
P4: Model cohesive parts as one unit (class). Parts are cohesive if they are (almost) always together, like user first name and user family name
P5: Loosely couple non-cohesive parts
P6: 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 www.OOSE.de)

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

P8: Think twice before using a generalization if you cannot come up with a discrimminator for it within 30 seconds.
P9: Be extra careful with multiple inheritance.
P10: A lot of <<include>>s are a symptom of functional decomposition (<- Ivar Jacobson)