Thoughts on the Workshop Topic by Alistair Cockburn


At last year's OOPSLA workshop on teaching OO, I got around to deciding that
   talking about OO design quality is a matter of 
   talking about the futures the design supports.

I have not changed my opinion recently, but added these five tests to walk through on an OO design. I have been applying the tests lately, and fairly content with the results:

1. DataConnectednessTest?. Aimed primarily at evaluating whether a (domain) model supports the use cases. Surprisingly, I saw a master design for a large project fail this.

2. AbstractionTest?. Does the name of the object convey its abstraction, does the abstraction named have a natural meaning and use in the language of the experts? Very many objects do not do well in this test. It is highly subjective, but everyone gets a sort of "ahh" feeling when you improve this.

3. ResponsibilityAlignmentTest?. Do the name, main responsibility statement, and data and functions align? During design evolution, usually the latter fattens up way past the point of what the name or primary responsibility call for. That is often time to split the object, but sometimes it is time to rething what abstraction you really have in front of you.

4. VariationsTest?. Two parts: DataVariationsTest? and EvolutionTest?. The first checks that the design naturally handles all the sorts and shapes of data the system will encounter. The second asks, what changes are likely in the business rules, assumptions, use cases, etc. How does the design handle these?

5. CommunicationsPatternsTest?. Run-time communications patterns. Particularly looks for cycles, but possibly other odd shapes. Nothing is "wrong", but you may get suspicious.

You can see that the "talking about the futures" is 4(b). However, experience is that 2 and 3 help 4(b). Also note the depressing thing about the futures test - it means you cannot satisfactorily talk about quality of a design without postulating a future! Argh! The other tests indicate that the design is "well-centered" in some way, but the quality you are really after only shows up (a) if the design is well centered, and (b) the future that happens to you is one the design naturally supports.

comments welcome - AlistairCockburn


EditText of this page (last edited June 2, 1997)
FindPage by browsing or searching



< retour à (back to) OOPSLA'97. Workshop on Object-Oriented Design Quality
Dernière mise à jour par (last update by):
keller@iro.umontreal.ca,
Sat Jun 14 15:32:08 EDT 1997.