Smalltalk and Object Orientation: an Introduction - Free

6. Verify that access paths exist for likely queries.
7. Iterate and refine the model.
8. Group classes into modules.
However, you should not take the sequence of these steps too strictly: remember analysis and design
are rarely completed in a truly linear manner. It is likely that some steps will be performed to greater
depths as the whole process proceeds. In addition, so me steps may (will) lead to revisions in other steps
and once an initial design is produced it will doubtless require revisions. Therefore you should consider
that they are a sequence of processes which should be performed. The order of which may be influenced
by the domain, the expertise available, the application etc. However it is probably a good idea always to
start with the process of identifying objects and classes.
We will consider each of the above steps in more detail below.
19.3.2.1 Identify objects and classes
The first step in constructing the object model is to identify the objects in the domain and their classes.
Such objects may include:
• physical entities such as petrol pumps, engines and locks
• logical entities such as employee records, purchases and speed
• soft entities such as token, expression or data stream
• conceptual entities such as needs, requirements or constraints.
As long as they make sense for the application and the domain then they are a candidate object or class.
The only things you shoul d avoid are objects which might relate to the proposed computer
implementation.
OMT suggests that you start identifying these candidate objects by looking in the textual problem
description. It indicates that classes are often found by identifying nouns in the description and making
them into classes. However, if you have a more formal problem specification it might be easier to
identify a set of potential classes. If you have used the use case analysis method you may also be able to
identify the top most objects directly from the use case diagrams.
Do not worry about getting it right at this point or about identifying classes which should not be
there. Inappropriate classes will be filtered out later on - for the moment, attempt to find anything which
could be a class.
Once you have a comprehensive list of candidate classes you can discard any unnecessary and
incorrect ones. This is done by using the following criteria:
Are any of the classes redundant ? That is, two or more classes express the same informat ion. For
example, customer and user might just be different names for the same thing.
Are any of the classes irrelevant ? That is, are they outside the scope of the system to be built even
though they are part of the domain. For example, although porters wo rk in a hospital they are probably
not relevant to a hospital bed allocation system.
Are any of the classes vague ? That is, do they represent ill defined concepts? For example, history
provision is vague - what is it a history of?
Are any of the classes really attributes of other classes? For example, name, address, salary, job title
tend to be attributes of an object employee rather than objects in their own right.
This can be a tricky one as it is often possible to represent something as both a class or a n attribute.
One way of handling this is to leave the decision until later. If the class possesses only one type of
information and has no operations then it should probably have been an attribute.
Are any of the classes really operations? If a class appears to describe an operation that is applied to
objects and not manipulated in its own right then it is not a class. For example, a telephone call is a
sequence of actions performed by a caller. In the implementation you may wish to make this an object,
however at this point in the design we are trying to produce a model of the application domain (i.e. not
an implementation model).
Does the name of the class represent its intrinsic nature and not its role in the application ? For
example, the class Person mig ht represent an object in a restaurant booking system, but the class
Customer is a better representation of its role in the system.
Is a class really an implementation construct ? For example, things such as process, algorithm,
interrupt, exception are implementation concepts and tend not to be related to the application domain.
158