UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
SESSION 13 Modeling the Static View: The Object Diagram Session Checklist ✔ Explaining the purpose and notation of the Object diagram ✔ Comparing and contrasting the Object and Class diagrams ✔ Explaining how to use the Object diagram to test a Class diagram The Object diagram is primarily a tool for research and testing. It can be used to understand a problem by documenting examples from the problem domain. It can also be used during analysis and design to verify the accuracy of Class diagrams. Understanding the Object Diagram The Object diagram models facts about specific entities, whereas the Class diagram models the rules for types of entities. Objects are real things, like you and me, this book, and the chair you’re sitting in. So an Object diagram would represent, for example, the fact that you own this copy of UML Weekend Crash Course. In contrast, a Class diagram would describe the rule that people can own books. To come up with a set of rules that describe objects and their relationships, you must have real things on which to base the rules. The qualities of each real object are compared to identify common properties that support a common description. If an object is encountered that does not fit the description, either the current description must change or a new description must be created to support the new facts. Earlier in this book, you started with a problem domain that you described using the Use Case view. Use Cases described interactions between the actors and the system. From those Use Cases, you found scenarios. Now scenarios become your source for test cases to verify every behavior that your system needs to support. Scenarios are also the source for the facts you’ll use to build your Object diagrams.
140 Saturday Afternoon Introducing Elements of the Object Diagram Notation The Object diagram consists of just two elements: objects and links. You know already that an object is a real entity created from a class, a definition of a type of object. In the same way, a link is created from an association, the definition of a type of relationship. A link represents a relationship between two objects. An association defines a type of relationship and the rules that govern it. Figure 13-1 shows an object called Tom. Like the Class notation, the Object notation has a name compartment at the top of the box. The name includes the name of the object and the name of the class to which the object conforms: “Customer.” This helps distinguish the object Tom of type Customer from the object Tom of type Employee. This notation also allows you to model an example or test case in which many objects of the same class participate (for example, one employee supervises another employee). Tom: Customer custID = 123456 name = Tom Pender address = 1234 UML Ave Figure 13-1 UML Object notation Use the format object name : class name to fully define the object name. Then the entire expression is underlined. You may also use the abbreviated form, : class name, without the object name. This form is called an anonymous object. It is used when you want to draw an example where it doesn’t really matter which specific object participates in the example because any object of the named class would behave in exactly the same way. The second compartment in the object box contains facts about the attributes. Each attribute is named and assigned a value. In Figure 13-1, you see name = Tom Pender. An object is real. It exists. So it can have values assigned to each attribute. Even a value of blank or null is a value that distinguishes the condition of the object from other possibilities. Note how different this is from the class attribute compartment. The class contained definitions for each attribute and contained no values. Again, the class is a set of rules where the object is a set of facts. The class says that an Employee object may have a name attribute that contains a String value 20 characters long. The object says that the name attribute does contain the value “Tom Pender.” Comparing the Object Diagram and the Class Diagram Notations Figure 13-2 contains a Class diagram showing the rules regarding Shipment and Product and the relationship between the two objects. The Class diagram defines the attributes that must be used to define each type of object and the behaviors that each type of object must support.
- 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 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: 138 Saturday Afternoon REVIEW The C
- 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
- Page 190 and 191: SESSION 16 Modeling the Dynamic Vie
- Page 192 and 193: Session 16—Modeling the Dynamic V
- Page 194 and 195: Session 16—Modeling the Dynamic V
- Page 196 and 197: Session 16—Modeling the Dynamic V
- Page 199 and 200: PART III # Saturday Afternoon Part
- Page 201 and 202: PART IV Saturday Evening Session 17
- Page 203 and 204: 180 Saturday Evening Scenario 1 Get
- Page 205 and 206: 182 Saturday Evening The next step
- Page 207 and 208: 184 Saturday Evening For Scenario 2
- Page 209 and 210: 186 Saturday Evening For subsequent
- Page 211 and 212: 188 Saturday Evening 6:addProduct(c
140<br />
Saturday Afternoon<br />
Introducing Elements of the Object Diagram Notation<br />
The Object diagram consists of just two elements: objects and links. You know already that<br />
an object is a real entity created from a class, a definition of a type of object. In the same<br />
way, a link is created from an association, the definition of a type of relationship. A link<br />
represents a relationship between two objects. An association defines a type of relationship<br />
and the rules that govern it.<br />
Figure 13-1 shows an object called <strong>To</strong>m. Like the Class notation, the Object notation has a<br />
name compartment at the top of the box. The name includes the name of the object and the<br />
name of the class to which the object conforms: “Customer.” This helps distinguish the object<br />
<strong>To</strong>m of type Customer from the object <strong>To</strong>m of type Employee. This notation also allows you to<br />
model an example or test case in which many objects of the same class participate (for example,<br />
one employee supervises another employee).<br />
<strong>To</strong>m: Customer<br />
custID = 123456<br />
name = <strong>To</strong>m Pender<br />
address = 1234 <strong>UML</strong> Ave<br />
Figure 13-1 <strong>UML</strong> Object notation<br />
Use the format object name : class name to fully define the object name. Then the entire<br />
expression is underlined. You may also use the abbreviated form, : class name, without the<br />
object name. This form is called an anonymous object. It is used when you want to draw an<br />
example where it doesn’t really matter which specific object participates in the example<br />
because any object of the named class would behave in exactly the same way.<br />
The second compartment in the object box contains facts about the attributes. Each<br />
attribute is named and assigned a value. In Figure 13-1, you see name = <strong>To</strong>m Pender. An<br />
object is real. It exists. So it can have values assigned to each attribute. Even a value of<br />
blank or null is a value that distinguishes the condition of the object from other possibilities.<br />
Note how different this is from the class attribute compartment. The class contained<br />
definitions for each attribute and contained no values. Again, the class is a set of rules<br />
where the object is a set of facts. The class says that an Employee object may have a name<br />
attribute that contains a String value 20 characters long. The object says that the name<br />
attribute does contain the value “<strong>To</strong>m Pender.”<br />
Comparing the Object Diagram and the Class Diagram Notations<br />
Figure 13-2 contains a Class diagram showing the rules regarding Shipment and Product<br />
and the relationship between the two objects. The Class diagram defines the attributes that<br />
must be used to define each type of object and the behaviors that each type of object must<br />
support.