Smalltalk and Object Orientation: an Introduction - Free

19.3.2.2 Prepare a data dictionary
A data dictionary provides a definition for each of the terms / words being used in the evolving analysis
models. Each entry precisely describes each objec t class, its scope, any assumptions or restrictions on
its use and its attributes and operations (once they are known).
19.3.2.3 Identify associations between objects
The next step is to identify any (and all) associations between two or more classes. This is done by
looking for references between two classes. OMT suggests that a good place to look for these
relationships is to examine the problem description for verbs or verb phrases between known objects. In
particular it identifies the following types of relationships:
• physical location (next to, part of, contained in)
• directed actions (drives)
• communication (talks to)
• ownership (has, part of)
• satisfaction of some condition (works for, married to, manages)
Again OMT exhorts you to identify all possible relationships and not to worry at this point about getting
it right.
If you have used a method such as OOA you might already have some knowledge about the
relationships between the classes in the domain, if not then considering which classes are likely to need
to work with which other classes (i.e. the accounts clerk may need to work with the salaries clerk) is
also a good place to start. This process will be simplified if you have performed a use case analysis.
Once you have a set of candidate associations, OMT pr ovides a detailed set of criteria to help in
refining them. The criteria are:
Is the association one which is between eliminated classes ? If one of the classes involved in the
association has been eliminated then the association should be eliminated.
Are any of the associations irrelevant or implementation associations ? Eliminate any associations
that are outside the scope of the application domain (including implementation related associations).
Are any associations transient ? An association should be a s tructural property of the applications
domain. For example, interacts with user is a temporary association in a hotel booking system.
Are any of the associations ternary ? Although the OMT notation and indeed the UML notation
allow ternary associations, the y are not encouraged. Instead you are encouraged to decompose these
associations into binary ones (they are easier to implement, maintain and understand!).
Are any of the associations derivable ? OMT suggests that you should remove any associations
which ca n be derived from other associations. However you should be wary of removing such
associations as they may be critical to understanding the domain relationships. That is, if an association
can be replaced by two existing associations, only do so if the semantic meaning of the two associations
can be combined to provide the same semantic meaning as the one to be removed. A good example of
this is that a GrandparentsOf relationship can be replaced by two ParentOf relationships.
Having removed inappropriate associations, you can now consider the semantics of the associations
you have left. To do this you should use these criteria:
Are any of the associations misnamed ? That is, do they actually reflect what they represent? Are
they named after their use or the relationship they indicate?
Add role names where appropriate . As described in the last chapter, role names describe the role
that a class plays in the associations from the point of view of the other class.
Are there any qualified associations? That is, are there any associations which require a qualifier to
identify a unique object.
Specify multiplicity on the associations . That is, indicate how may objects are involved in the
association. By default all associations are 1 to 1 associations. Where no multip licity is specified check
that these really are 1 to 1 links.
Are there any missing associations ? Check that all reasonable associations are present. This may
need to be done in consultation with the domain expert.
159