UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 10—The Class Diagram: Associations 111 Customer 0..* orders 0..* Product Order - quantity: integer = 0 - orderdate: Date = today - terms: Terms = null Figure 10-6 Association class notation Tip Be on the lookout for association classes when you see a multiplicity of more than one on both ends of the association. You don’t always need an association class on these many-to-many associations, but it is a common place to find them. Reflexive association Reflexive association is a fancy expression that says objects in the same class can be related to one another. The entire association notation you’ve learned so far remains exactly the same, except that both ends of the association line point to the same class. This is where the reflexive association gets its name. The association line leaves a class and reflects back onto the same class. Both examples in Figure 10-7 are equivalent expressions. The only difference is that one uses roles and the other uses an association name. Using role names Using an association name 0..1 supervisor Employee 0..* subordinate 0..1 Employee 0..* supervises Figure 10-7 Two ways to model a reflexive association A reflexive association is a very common way to express hierarchies. The example in Figure 10-7 models a hierarchical reporting structure. I could use the same technique for companies owned by other companies. Qualified association Qualified associations provide approximately the same functionality as indexes, but the notation has a bit of a twist. To indicate that a customer can look up an order using the order’s ordernumber attribute, place the ordernumber attribute name and data type in a rectangular box on the Customer end of the association. The rest of the association notation remains intact but is pushed out to the edge of the rectangle.
112 Saturday Morning The placement of the qualifier is sometimes confusing. The best way I have found to remember it is to think of it like this (refer to Figure 10-8): “The Customer uses the ordernbr to look up an Order.” or “One type of object uses the qualifier to access the other (qualified) type of object.” The qualifier goes next to the class of objects that will use the value to do the look up. It is not exactly intuitive but it works. Without a qualifier Customer 1..1 places 0..* Order With a qualifier Customer Figure 10-8 places ordernbr: integer 1..1 1..1 Qualified association Order - ordernbr: integer - quantity: integer = 0 - orderdate: Date = today Tip Typically the qualifier is an attribute of the class on the opposite end of the association, so make certain that the two names and data types agree. Use qualifiers to reduce the multiplicity in the same way you would use indexes in a database to reduce the search time for a specific row or subset of rows. For example, in Figure 10-8, note how the multiplicity for the Order end of the association changed from 0..* to 1..1. This is because the qualifier provided a unique key for Order objects. Before the qualifier was established, navigation across the association would result in a list of all orders associated with that Customer, because the Customer relationship was the only reference available to select the Orders. REVIEW Associations define how objects will be allowed to work together. An association is named to describe the purpose of the relationship. Role names may be used with or in place of the association name to describe how the objects participate in the relationship.
- Page 85 and 86: 62 Saturday Morning Order Fulfillme
- Page 87 and 88: 64 Saturday Morning What does the
- 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 136 and 137: Session 10—The Class Diagram: Ass
- Page 138 and 139: Part II — Saturday Morning Part R
- Page 140 and 141: SESSION 11 The Class Diagram: Aggre
- 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
112<br />
Saturday Morning<br />
The placement of the qualifier is sometimes confusing. The best way I have found to<br />
remember it is to think of it like this (refer to Figure 10-8):<br />
“The Customer uses the ordernbr to look up an Order.”<br />
or<br />
“One type of object uses the qualifier to access the other (qualified) type of<br />
object.”<br />
The qualifier goes next to the class of objects that will use the value to do the look up. It<br />
is not exactly intuitive but it works.<br />
Without a qualifier<br />
Customer<br />
1..1<br />
places<br />
0..*<br />
Order<br />
With a qualifier<br />
Customer<br />
Figure 10-8<br />
places<br />
ordernbr: integer<br />
1..1 1..1<br />
Qualified association<br />
Order<br />
- ordernbr: integer<br />
- quantity: integer = 0<br />
- orderdate: Date = today<br />
Tip<br />
Typically the qualifier is an attribute of the class on the opposite end of the<br />
association, so make certain that the two names and data types agree.<br />
Use qualifiers to reduce the multiplicity in the same way you would use indexes in a<br />
database to reduce the search time for a specific row or subset of rows. For example, in<br />
Figure 10-8, note how the multiplicity for the Order end of the association changed from<br />
0..* to 1..1. This is because the qualifier provided a unique key for Order objects. Before the<br />
qualifier was established, navigation across the association would result in a list of all<br />
orders associated with that Customer, because the Customer relationship was the only reference<br />
available to select the Orders.<br />
REVIEW<br />
Associations define how objects will be allowed to work together.<br />
An association is named to describe the purpose of the relationship.<br />
Role names may be used with or in place of the association name to describe how<br />
the objects participate in the relationship.
Change language