[ fromfile: relationships.xml id: relationships ]
When there is a one-to-one or a one-to-many correspondence between objects of certain types, we use a variety of connecting lines to describe a relationship between them in a UML class diagram.
In Figure 4.1, the line connecting the classes expresses a particular relationship between them.
In the context described by this diagram, there can be many Person
instances working
for exactly one Employer
.
This can be denoted by the multiplicity specifier at each end of the relationship: 1
at the Employer
end, and *
at the Person
end.
The *
takes on its regular expression definition, of "0 or more" (Section 14.3).
Revisiting Figure 2.6, another set of relationships is revealed when you look at
the company from the Employer's
viewpoint. Figure
4.2 shows three kinds of relationships.
There is a composition relationship (the filled
diamond) between Employer
and Position
.
It indicates that the Employer
owns or manages the Position
,
and the Position
should not exist without the Employer
.
There is an aggregation relationship (the empty
diamond) from the Employer
to its employees.
The Employer
groups together a collection of Person
s and gets them to do things during working hours.
In an aggregation relationship, the lifetimes of the objects on either end are not related to one other.
The Person
and the Position
have a bidirectional
assocation between them.
An association is a bidirectional relationship, and does not specify anything about implementation,
ownership, or management between objects. It is possible that there is no actual pointer in Person
that points to its Employer
because it can be
calculated by going to its Position
and calling Position::getEmployer()
.
Although the diagram indicates a 1:1 relationship between Person
and Position
, it is possible that a Person
can hold
multiple Position
s, or an Employer
may hire many
Person
s for the same Position
. If you want to
describe a system that can handle such cases, then the cardinality of this association should be
many-to-many.
Generated: 2012-03-02 | © 2012 Alan Ezust and Paul Ezust. |