UML Weekend Crash Course™ - To Parent Directory

138
Saturday Afternoon
REVIEW
The Class diagram models the resources of the problem domain. Associations represent the
rules that govern the relationships between the resources. Multiplicity defines the allowable
combinations of objects in a relationship. Qualified associations provide a means to access
one or more objects with an identifier, thus reducing search time and complexity.
To build the Class diagram, follow the steps described in Sessions 9 through 11:
1. Identify the classes, name them, and define them so you know why they are
part of the model.
2. Identify, name, and define the associations between pairs of classes. Watch
out for reflexive associations as well. Assign multiplicity and constraints
where needed. If naming an association is difficult, try role names.
3. Evaluate each association to determine whether it should be defined as
aggregation. If it is aggregation, then could it be composition
4. Evaluate the classes for possible specialization or generalization.
Patterns define a common solution to a common problem. Patterns identify the
problem needing a solution, the resources to solve the problem, the rules for how
the resources should be used to solve the problem, and when it is and is not appropriate
to apply the pattern. Patterns are not code.
The notation for applying patterns to a Class diagram is an oval collaboration icon
with the pattern name. Dashed lines connect the pattern to the participating
classes. The role names are placed at the ends of the dashed lines near the class
that plays the role.
QUIZ YOURSELF
1. How would you use multiplicity to say that a Shipment must contain at least
one Product but can contain as many Products as you like (See “Modeling the
Inventory Control System for the Case Study.”)
2. What notation would you use to indicate that there are two different types of
Shipments (See “Modeling the Inventory Control System for the Case Study.”)
3. What is a pattern (See “Understanding UML Notation for Design Patterns.”)
4. What is the notation for a pattern (See “Understanding UML Notation for
Design Patterns.”)
5. How do you indicate the way in which a class participates in a pattern
(See “Understanding UML Notation for Design Patterns.”)