[ 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. |