Smalltalk and Object Orientation: an Introduction - Free

car, truck and bus under a superclass vehicle makes sense. However, adding the class student just
because they all share the attribute registrationNumber does not make sense!
Identifying specializations can be more difficult, however if you find a class playing a number of
specific roles then specialization may be appropriate. Note that you should be wary of specialization as
you do not want to over specialize the classes in your object model. This is because you may actually be
talking about separate instances of the same class, rather than subclasses.
19.3.2.6 Testing access paths
This step involves checking that paths in the model make sense, are sufficient and are necessary. O MT
suggest that you trace access paths through the object model to see if they yield sensible results. The
sorts of issues you might wish to consider are:
• Where a unique value is expected, is there a path yielding a unique result?
• For multiplicity “many” is there a way to pick out a unique value when needed?
• Are there any useful (domain specific/application specific) questions which can’t be answered?
19.3.2.7 Iterate and refine the model
There are two things you will come to learn about object design, firstly it i s still more of an art than a
science and secondly (unless the problem is trivial) the first version of the object model will probably
not be correct (or complete). Object oriented design is far more iterative in nature than some other
design methods and it therefore acknowledges that you will need to iterate over the whole of the above
process a number of times to get a reasonable object model. Indeed some changes will be initiated by
the development of the dynamic model and the functional model which you have not even considered
yet (for example we have not attempted to identify any operations for the object model at this point).
At this point some of the questions you can ask yourself about the object model are:
• Are there any missing objects (does one class play two roles)?
• Are there any unnecessary classes (such a class might possess no attributes)?
• Are there any missing associations (such as a missing access path for some operation)?
• Are there any unnecessary associations (such as those that are not used by anything)?
• Are all attributes in the correct class?
• Are all associations in the correct place?
Cross referencing the object model with the use case model may help answer some of the above
questions.
19.3.2.8 Group classes into modules/packages
The final step associated directly with the object model is to group classes into packages. Packages
should be identified by looking for classes which work together. Do not base the packages purely on
system functionality as this is likely to change and will result in inappropriate packaging. OMT suggests
that you ensure that a package can be fitted onto a single drawing surface (be that paper or the screen)
as this aids comprehensibility. In addition, packages can be hierarchical and can be a very useful way of
partitioning the design of the system amongst a number of designers.
161