contents
previous
V. Object design
A. Overview
During the activity known as object design
we strive to identify all of the classes of objects that will wind up in
the system, and to come to a detailed understanding of their interfaces.
We might also be interested in identifying specific instances of a class,
that is, special objects. Understanding the interface means considerably more
that just knowing the methods that can be use, and the nature of their
parameters and return values. Besides having a return value, a given method
can also have side effects that alter the state of the object or the
system at large. We need to understand such things. Basically, we need to
understand the postconditions. But it is also important to understand any
preconditions to using a method. That is we need to understand and conditions
that should hold in order to legitimately use the method.
State diagrams can be very helpful in identifying detailed object behavior, by
regarding an object as being in any of several possible states. Another useful
tool for expressing detailed requirements placed on classes and methods is the
Object Constraint Language (OCL). This is a
formal specification language whose
notation can be attached to UML diagrams to indicate
invariants (constraints) that must be placed on various pieces of the
system (like objects and methods). We will study OCL in more detail than is
presented in Bruegge-Dutoit.
Another issue is the fact we must now start thinking about classes and objects in
a fairly implementational, as opposed to conceptual, sense. This results in the
need to resolve a number of issues. For example, until now it was OK to talk about
things like "object A send a message to object B", when what we're really going to
end up with is object A calling some method of object B. Even worse, we may have
discussed some vague "associations" between classes. We'll consider such issues
in the next section.
Considerable time might be spent during object design visiting and revisiting
the choices of classes used in the system. Restructuring
can result in merging classes together or splitting up a class, much
as we discussed such things in connection with subsystems during system design.
Associations can be changed as well (and as already mentioned, implementation details
need to be considered). Restructuring is concerned with finding better logical
organization, with the possibility of designing classes that might be reused
elsewhere. Optimization is important too.
For example, some non-functional requirement might lead us to introduce an
association between classes that is not strictly needed, but which would enhance
performance.
next