Next: Summary and Conclusions
Up: A (Brief!) Catalog
Previous: Techniques for Generalizing
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:
-
Developing good specification models for clients:
-
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.
-
For modeling the state of objects, choose models that can be
drawn and/or visualized easily.
-
Evaluate models and specifications: try to teach them to both
novices and experts.
-
Write formal specifications, at least to try to validate a
model's elegance for the purpose at hand.
-
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.
-
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.
-
Developing good representation models for implementers:
-
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.
-
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.
Next: Summary and Conclusions
Up: A (Brief!) Catalog
Previous: Techniques for Generalizing
Larry Latour
Sun Sep 17 21:09:35 EDT 1995