A constructive model of OO design


By Rob Rist rist@socs.uts.EDU.AU
Computing Sciences, University of Technology, Sydney
PO Box 123 Broadway, Sydney, NSW 2007 Australia

This year, I have used the framework I developed for empirical analysis of software design to teach (simple) OO design. I teach the OO language Eiffel as a first language. I've found that I can do this best by separating the syntax and mechanism of Eiffel from the process of design, allowing me to treat design as an explicit topic.

My basic approach is (what else?) focal or bottom-up design, where goals and objects are orthogonal. I divide the subject into three parts: design based on data flow, control flow, and inheritance.

The steps in the model I teach are:

1. Identify and list the goals in the specification.

For each goal:

2. Write down the focus

The focus is the "meaning" of the goal. If the goal is to produce a value (function), it is the line that produces the value. If the goal is to change a value (procedure), the focus is the line that changes the value. If the goal is a restriction on a value (see 4 below) such as "maximum" or "valid", then the focus is the line that tests for that restriction on the value.

3. Add the data (control) flow that supports the focus.

This is the constructive equivalent of backward slicing, that identifies all and only the data (control) that is needed. As Francoise has shown, novices tend to infer features from object names with little concern for their relevance.

4. For each node in the data (control) flow, expand its name to the form

<goal, object>, <role, object>,
<role, goal, object>, or
<role, goal, object, class>, or permutations on these.

A role is a restriction on a value, such as "highest" or "first"; it can also be seen as a filter on a set.

5. From the expanded names, use the goal and object to locate each node on a system structure chart.

6. Code each node as a routine; the "source" data values are usually attributes, that may be set with inputs, arguments, constants, or literals.

When my students adopt this approach, they get about 90% of the structure of the OO system "for free". The hardest part is (1) to convince them that it is better to follow a method than to wing it, and (2) to get them to listen to what the method tells you (use the expanded names as a design heuristic).

A longer, but still very rough, description with examples may be found by clicking on "Design Studies" in http://www-staff.socs.uts.edu.au/~rist