UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
SESSION 9 Modeling the Static View: The Class Diagram Session Checklist ✔ Explaining the two diagrams in the Object Model ✔ Explaining and illustrating the Class diagram notation ✔ Explaining and illustrating attribute specifications ✔ Explaining and illustrating operation specifications ✔ Explaining and illustrating the different ways to represent a class The Class diagram is by far the most used and best known of the object-oriented diagrams. It is the source for generating code and the target for reverse engineering code. Because the Class diagram is the primary source for code generation, the other diagrams tend to serve as tools of discovery that add to your knowledge about how to build the Class diagram. Use Cases identify the need for the objects as resources used by the system to achieve its goals. The Sequence and Collaboration diagrams are excellent tools for discovering object interactions and, by inference, defining interfaces. The Activity diagram is very good for discovering the behavior implemented by objects and so helps to define the logic of operations on the objects. The Object Model The phrase object model has been the source of some confusion. Object Model is often used as a synonym for Class diagram. In this book, object model is used to mean the set of diagrams used to model objects, namely the Class and Object diagrams. The Class diagram is the more recognized and used of the two diagrams. The Object diagram is often implemented within the Class diagram, not as a separate diagram. In fact, the UML specification does not actually define the Object diagram. It is simply a Class diagram that contains only objects.
94 Saturday Morning The Class diagram The Class diagram represents classes, their component parts, and the way in which classes of objects are related to one another. A class is a definition for a type of object. It’s really not much different from what you find in a dictionary. If you want to find out what a widget is, you look up the word widget. You would find a description of what a widget looks like, its purpose, and any other pertinent information for understanding widgets. There are no actual widgets in the dictionary, only descriptions. There are no real objects in a class, only descriptions of what a particular type of object looks like, what it can do, and what other objects it may be related to in some way. To document this information, the Class diagram includes attributes, operations, stereotypes, properties, associations, and inheritance. Attributes describe the appearance and knowledge of a class of objects. Operations define the behavior that a class of objects can manifest. Stereotypes help you understand this type of object in the context of other classes of objects with similar roles within the system’s design. Properties provide a way to track the maintenance and status of the class definition. Association is just a formal term for a type of relationship that this type of object may participate in. Associations may come in many variations, including simple, aggregate and composite, qualified, and reflexive. Inheritance allows you to organize the class definitions to simplify and facilitate their implementation. Together, these elements provide a rich set of tools for modeling business problems and software. However, the Class diagram is still limited in what it can show you. Generally speaking, it is a static view of the elements that make up the business or software. It’s like a blueprint for a building or a piece of machinery. You can see the parts used to make it and how they are assembled, but you cannot see how the parts will behave when you set them into motion. This is why we need other diagrams to model behavior and interactions over time (that is, modeling the objects in motion). Figure 9-1 shows how all the other diagrams support the Class diagram. Use Case Model Activity Diagram Class Diagram Object Diagram Statechart Diagram Sequence Diagram Collaboration Diagram Figure 9-1 All diagrams support the Class diagram.
- Page 65 and 66: 42 Friday Evening Performance How
- Page 67 and 68: 44 Friday Evening In the effort to
- Page 70 and 71: Part II — Saturday Morning Sessio
- Page 72 and 73: SESSION 5 Understanding the Use Cas
- Page 74 and 75: Session 5—Understanding the Use C
- Page 76 and 77: Session 5—Understanding the Use C
- Page 78 and 79: Session 5—Understanding the Use C
- Page 80 and 81: Session 5—Understanding the Use C
- Page 82: Session 5—Understanding the Use C
- 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 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 and 162: 138 Saturday Afternoon REVIEW The C
- Page 163 and 164: 140 Saturday Afternoon Introducing
94<br />
Saturday Morning<br />
The Class diagram<br />
The Class diagram represents classes, their component parts, and the way in which classes of<br />
objects are related to one another. A class is a definition for a type of object. It’s really not<br />
much different from what you find in a dictionary. If you want to find out what a widget is,<br />
you look up the word widget. You would find a description of what a widget looks like, its<br />
purpose, and any other pertinent information for understanding widgets. There are no<br />
actual widgets in the dictionary, only descriptions. There are no real objects in a class, only<br />
descriptions of what a particular type of object looks like, what it can do, and what other<br />
objects it may be related to in some way.<br />
<strong>To</strong> document this information, the Class diagram includes attributes, operations, stereotypes,<br />
properties, associations, and inheritance.<br />
Attributes describe the appearance and knowledge of a class of objects.<br />
Operations define the behavior that a class of objects can manifest.<br />
Stereotypes help you understand this type of object in the context of other classes<br />
of objects with similar roles within the system’s design.<br />
Properties provide a way to track the maintenance and status of the class definition.<br />
Association is just a formal term for a type of relationship that this type of object<br />
may participate in. Associations may come in many variations, including simple,<br />
aggregate and composite, qualified, and reflexive.<br />
Inheritance allows you to organize the class definitions to simplify and facilitate<br />
their implementation.<br />
<strong>To</strong>gether, these elements provide a rich set of tools for modeling business problems and<br />
software. However, the Class diagram is still limited in what it can show you. Generally<br />
speaking, it is a static view of the elements that make up the business or software. It’s like<br />
a blueprint for a building or a piece of machinery. You can see the parts used to make it and<br />
how they are assembled, but you cannot see how the parts will behave when you set them<br />
into motion. This is why we need other diagrams to model behavior and interactions over<br />
time (that is, modeling the objects in motion). Figure 9-1 shows how all the other diagrams<br />
support the Class diagram.<br />
Use Case<br />
Model<br />
Activity<br />
Diagram<br />
Class<br />
Diagram<br />
Object<br />
Diagram<br />
Statechart<br />
Diagram<br />
Sequence<br />
Diagram<br />
Collaboration<br />
Diagram<br />
Figure 9-1<br />
All diagrams support the Class diagram.
Change language