Object Design Quality

Starting off with a call for participation. I'll add my current thoughts next, and post results of the OOPSLA Workshop later...

CALL FOR PARTICIPATION IN OOPSLA WORKSHOP, OCT 5 - 97 (from http://www.iro.umontreal.ca/~keller/Workshops/OOPSLA97/) Despite the burst in the availability of OO analysis and design methodologies, languages, ..., relatively little work has been done in the area of OO design quality... . We badly need a better understanding of the properties of OO system design, in the small and in the large, and their effect on quality factors such as maintainability, evolvability, and reusability.... We seek participants to cover practical and theoretical issues related to the quality of OO designs, addressing the two key questions: (1) What makes a good OO design? (2) How do we achieve a good OO design?

Theme topics are the following, as they help resolve those two key questions: (1) Examples of good OO design; (2) Conflicts and contradictions in asking for "good" OO designs; (3) Characteristics of good OO designs; (4) Design techniques to obtain good designs; (5) Evaluation experiences of existing proposed OO design metrics; (6) New design metrics (only if attached to motivating examples); (7) Relationship between good OO analysis and good OO design; and (8) Testing OO designs for quality. The workshop activities will include pre-distribution of position papers, round-table discussion, short presentations, discussions of selected topics in work groups, and final gathering to compare impressions and identify consensus, issues and directions of the topic.

Submit position paper, ASCII or Postscript, by Aug 4, addressing one of the two key questions, of no more than 1,000 words plus figures. We strongly encourage the inclusion of a sample "good" design fragment to motivate or illustrate the participant's ideas.

Organizers: RudolfKeller?, University of Montreal, Montreal, Quebec, Canada. mailto:keller@iro.umontreal.ca, web http://www.iro.umontreal.ca/~keller and AlistairCockburn, HumansAndTechnology?, Salt Lake City. mailto:arc@acm.org, web http://members.aol.com/acockburn

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 rethink 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