UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
SESSION 11 The Class Diagram: Aggregation and Generalization Session Checklist ✔ Explaining the concepts of aggregation and composition ✔ Illustrating the use of the notation for aggregation and composition ✔ Explaining the concepts of generalization and inheritance ✔ Illustrating the use of generalization In Session 10, you learned about associations. An association describes a set of rules regarding how objects may be related to one another. But associations can be a bit more restrictive. In this session, I describe two common subtypes of association, called aggregation and composition. Then I explain how you can refactor your design using generalization (inheritance). Modeling Aggregation and Composition Figure 11-1 outlines the relationships among the concepts of association, aggregation, and composition. Later in this session, I explain the contents of this graphic more fully. But right now I want to make two points as clear and strong as possible: Every aggregation relationship is a type of association. So every aggregation relationship has all the properties of an association relationship, plus some rules of its own. Every composition relationship is a form of aggregation. So every composition relationship has all the properties of an aggregation, plus some rules of its own.
118 Saturday Afternoon Association Objects are aware of one another so they can work together Aggregation 1. Protects the integrity of the configuration 2. Functions as a single unit 3. Control through one object – propagation downward Composition Each part may only be a member of one aggregate object Figure 11-1 composition The relationship between association, aggregation, and Elements of aggregation Aggregation is a special type of association used to indicate that the participating objects are not just independent objects that know about each other. Instead, they are assembled or configured together to create a new, more complex object. For example, a number of different parts are assembled to create a car, a boat, or a plane. You could even create a logical assembly like a team where the parts are not physically connected to one another but they still operate as a unit. To model aggregation on a Class diagram: 1. Draw an association (a line) between the class that represents the member and the class that represents the assembly or aggregation. In Figure 11-2, that would mean a line between the Team class and the Player class. 2. Draw a diamond on the end of the association that is attached to the assembly or aggregate class. In Figure 11-2, the diamond is next to the Team class that represents a group of players. 3. Assign the appropriate multiplicities to each end of the association, and add any roles and/or constraints that may be needed to define the rules for the relationship. Figure 11-2 shows that a Player may be a member of no more than one Team, but a Player does not have to be on a Team all the time (0..1). The Team is always comprised of exactly nine Players (9..9 or just 9). A Player is considered a member (role name) of a Team. Every Player is constrained by the fact that she must have a current contract in order to be a member of a Team. {must have a current contract} Team member Player Figure 11-2 0..1 9..9 How to represent an aggregation relationship in the UML
- Page 89 and 90: 66 Saturday Morning For example, th
- Page 91 and 92: 68 Saturday Morning REVIEW The goal
- Page 93 and 94: 70 Saturday Morning Much of this la
- Page 95 and 96: 72 Saturday Morning You reply that
- Page 97 and 98: 74 Saturday Morning Writing a Use C
- Page 99 and 100: 76 Saturday Morning Use Case dialog
- Page 101 and 102: 78 Saturday Morning Table 7-7 The F
- Page 104 and 105: SESSION 8 Identifying the Use Case
- Page 106 and 107: Session 8—Identifying the Use Cas
- Page 108 and 109: Session 8—Identifying the Use Cas
- Page 110 and 111: Session 8—Identifying the Use Cas
- Page 112 and 113: Session 8—Identifying the Use Cas
- Page 114: Session 8—Identifying the Use Cas
- Page 117 and 118: 94 Saturday Morning The Class diagr
- Page 119 and 120: 96 Saturday Morning Attribute visib
- Page 121 and 122: 98 Saturday Morning In a modeling t
- Page 123 and 124: 100 Saturday Morning Table 9-2 Cont
- Page 125 and 126: 102 Saturday Morning Operation comp
- Page 128 and 129: SESSION 10 The Class Diagram: Assoc
- Page 130 and 131: Session 10—The Class Diagram: Ass
- Page 132 and 133: Session 10—The Class Diagram: Ass
- Page 134 and 135: Session 10—The Class Diagram: Ass
- Page 136 and 137: Session 10—The Class Diagram: Ass
- Page 138 and 139: Part II — Saturday Morning Part R
- Page 142 and 143: Session 11—The Class Diagram: Agg
- Page 144 and 145: Session 11—The Class Diagram: Agg
- Page 146 and 147: Session 11—The Class Diagram: Agg
- Page 148 and 149: Session 11—The Class Diagram: Agg
- Page 150: Session 11—The Class Diagram: Agg
- Page 153 and 154: 130 Saturday Afternoon or not. Each
- Page 155 and 156: 132 Saturday Afternoon 5. “Any it
- Page 157 and 158: 134 Saturday Afternoon designed to
- Page 159 and 160: 136 Saturday Afternoon Table 12-3 T
- Page 161 and 162: 138 Saturday Afternoon REVIEW The C
- Page 163 and 164: 140 Saturday Afternoon Introducing
- Page 165 and 166: 142 Saturday Afternoon Table 13-1 C
- Page 167 and 168: 144 Saturday Afternoon 28: VendorPr
- Page 169 and 170: 146 Saturday Afternoon 0..* VendorP
- Page 172 and 173: SESSION 14 Modeling the Functional
- Page 174 and 175: Session 14—Modeling the Functiona
- Page 176 and 177: Session 14—Modeling the Functiona
- Page 178: Session 14—Modeling the Functiona
- Page 181 and 182: 158 Saturday Afternoon Table 15-1 T
- Page 183 and 184: 160 Saturday Afternoon Figure 15-1
- Page 185 and 186: 162 Saturday Afternoon More product
- Page 187 and 188: 164 Saturday Afternoon start (merge
SESSION<br />
11<br />
The Class Diagram: Aggregation<br />
and Generalization<br />
Session Checklist<br />
✔ Explaining the concepts of aggregation and composition<br />
✔ Illustrating the use of the notation for aggregation and composition<br />
✔ Explaining the concepts of generalization and inheritance<br />
✔ Illustrating the use of generalization<br />
In Session 10, you learned about associations. An association describes a set of rules<br />
regarding how objects may be related to one another. But associations can be a bit<br />
more restrictive. In this session, I describe two common subtypes of association, called<br />
aggregation and composition. Then I explain how you can refactor your design using generalization<br />
(inheritance).<br />
Modeling Aggregation and Composition<br />
Figure 11-1 outlines the relationships among the concepts of association, aggregation, and<br />
composition.<br />
Later in this session, I explain the contents of this graphic more fully. But right now I<br />
want to make two points as clear and strong as possible:<br />
Every aggregation relationship is a type of association. So every aggregation relationship<br />
has all the properties of an association relationship, plus some rules of its own.<br />
Every composition relationship is a form of aggregation. So every composition<br />
relationship has all the properties of an aggregation, plus some rules of its own.
Change language