3 Possible Guide
By Haytham Allos
Keep in mind that conceptual modelling is
aimed for modelling for understanding, not modelling for implementation.
Identify Objects and Classes
The first step in constructing a class diagram
is to identify the relevant classes from the requirements or application
domain. Objects include physical entities, such as houses, employees, and
machines, as well as concepts, such as seating assignments and payment
schedules. Classes often correspond to nouns. An approach is in a first step to
search the nouns in the text and to write them down. Donít be too selective.
Donít worry much about inheritance or high-level classes; first get specific
classes right. An examination of the nouns in the ATM problem statement yields
the following classes:
A second step is to discard unnecessary and
incorrect classes. This can be done using the following criteria:
- Redundant classes
If two classes express the same information the
one with the most descriptive name should be kept. In this exercise Customer
and User are redundant; Customer is retained because it
is more descriptive.
- Irrelevant classes
If a class has little or nothing to do with
the problem, it should be eliminated. This involves judgment, because in
another context the class could be important. In the ATM example, Cost is
outside the scope of the ATM transaction software.
- Vague classes
A class should be specific. Some tentative
classes may have ill-defined boundaries or be too broad in scope. For
example, Recordkeeping provision is vague. In the ATM it is part of
Transaction. Other vague classes are System, Security
provision, Banking network.
Names that primarily describe individual
objects should be restated as attributes. If independent existence of a
property is important, then make it a class and not an attribute. In the
ATM example Account data is under specified but in any case
probably describes an account. An ATM dispenses cash and receipts, but beyond
that cash and receipts do not affect the problem, so they should be
treated as ATM attributes.
If a name describes an operation that is
applied to objects and not manipulated in its own right, then it is not a
class. However, an operation that has features of its own should be
modelled as a class.
The name of a class should reflect its
intrinsic nature and not a role that it plays in an association.
- Implementation constructs
Constructs extraneous to the real world should
be eliminated from the analysis model.
Any dependency between two or more classes
is an association. Associations can be implemented in various ways, but such
implementation decisions should be kept out of the conceptual and specification
Associations often correspond to static
verbs or verb phrases. These include physical location, directed actions,
communication, ownership, or satisfaction of some condition. Extract all the
candidates from the problem statement and get them down on paper. Discard
unnecessary and incorrect associations, using the following criteria:
- Associations between eliminated classes.
If one of the classes in the association has been eliminated, then the
association must be eliminated or restated in terms of other classes.
- Irrelevant or implementation associations
Eliminate any associations that are outside
the problem domain.
An association should describe a structural
property of the application domain, not a transient event. For example, ATM
accepts cash card describes part of the interaction cycle between an
ATM and a customer, not a permanent relationship between ATMs and cash
cards. Sometimes, a requirement expressed as an action implies an
underlying structural relationship and should be rephrased accordingly.
- Derived associations
Omit associations that can be defined in terms
of other associations because they are redundant. However, be careful
because not all associations that form multiple paths between classes
indicate redundancy. Sometimes the existence of an association can be
derived from two or more primitive associations and the multiplicity
cannot. Although derived associations add no information, they can be
useful in the real world and in design. UML has a special notation to
annotate derived associations.
- Role names
Add role names where appropriate. The role
name describes the role that a class in the association plays from the
point of view of the other class. If the name of a class adequately
describes its role, you may omit role names. An association between two
instances of the same class (a reflexive association) requires role names
to distinguish the instances.
- Qualified associations
Usually a name uniquely identifies an object
in some context. For example, a bank is uniquely identified by a bank code
in the context of a consortium. The bank code qualifies the association Consortium
consists of banks; Consortium and Bank code identify Bank.
Specify multiplicity. Remember that putting no
multiplicity value on a role means that the multiplicity is undetermined.
For multiplicity values of ďmanyĒ, consider whether a classifier is
needed; also ask if the objects need to be ordered in some way.
- Missing Associations
Add any associations that are missing.
Attributes are properties of individual
objects, such as name, weight, and colour. Attributes of associations should
also be identified. They give rise to the existence of association classes.
Refining with inheritance
The next step is to organize classes using
inheritance to share common structures. Inheritance can be added in two
directions: by generalization of some aspects of existing classes into a
superclass (bottom up) or by refining existing classes into specialized
subclasses (top down).
Attributes and associations must be
assigned to specific classes in the class hierarchy. Each one should be
assigned to the most general class for which it is appropriate. Some
adjustments may be needed to get everything right.