Techniques for Deriving Good Mental Models

Giving software components descriptions that evoke effective mental models in their clients is a tough job. Nevertheless, it is a critical issue in design for reuse, because people are likely to pass by (or misuse) components that are not easy to understand. Of course, both component specifications and component implementations have mental models associated with them. The model the specification presents is intended for clients of the component to use, while the one that the implementation presents is intended for the implementer and maintainer(s) to use. The small collection of techniques we noted split along these lines:

1. Developing good specification models for clients:
   1. Concentrate on small-effect operations where possible, since operations that do many things in one step are more difficult to model, understand, and use correctly.
   2. For modeling the state of objects, choose models that can be drawn and/or visualized easily.
   3. Evaluate models and specifications: try to teach them to both novices and experts.
   4. Write formal specifications, at least to try to validate a model's elegance for the purpose at hand.
   5. Try to write two or more implementations for the specification you are defining. This helps to ensure that the specification is not overconstraining, among other things.
   6. Write programs that display model-like values of object state and allow exercising of all the operations in the specification. Then use interactive sessions with such a program to ``explore'' the functionality and behavior of your model, and to visualize conceptual model trajectories in the abstract state space.
2. Developing good representation models for implementers:
   1. Write programs that display model-like values of object representations and allow exercising of all the operations in the specification. Use interactive sessions with them to explore representation trajectories, compared with conceptual model trajectories.
   2. There are possibly ``intermediate'' levels of abstraction between a raw representation and the abstraction in the specification. These intermediate levels can provide more abstract views of the representation for use by implementers/maintainers. Recognize and document these where appropriate.