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)

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.