UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 14—Modeling the Functional View: The Activity Diagram 151 Taking a Look at Activity Diagram Notation In this section, I give you a quick tour of the notation. A lot of this may be familiar if you’ve used flowcharts, so feel free to skim over the session until you spot something that looks new. Activities and transitions An activity is a step in a process where some work is getting done. It can be a calculation, finding some data, manipulating information, or verifying data. The activity is represented by a rounded rectangle containing freeform text. An Activity diagram is a series of activities linked by transitions, arrows connecting each activity. Typically, the transition takes place because the activity is completed. For example, you’re currently in the activity “reading a page.” When you finish this activity, you switch to the activity “turning page.” When you are done turning the page . . . well, you get the idea. Figure 14-1 shows this idea graphically. Read a page Turn a page Figure 14-1 Activities and transitions This notation starts to show the overlap between the Activity diagram and the Statechart diagram. In fact, the Activity diagram is a subset of the Statechart diagram. Each Activity is an action state where the object is busy doing something (as opposed to waiting). Each transition is a change in state, a change from one activity or active state to the next. So as you learn the Activity diagram, you are well on your way toward understanding the Statechart diagram as well. You’ll see and use the Statechart diagram in Sessions 20 through 23. Tip You may sometimes see the word “Do:” preceding the name of an activity. This is a common and valid notation to distinguish an activity from other state-related behaviors defined by the UML. Guard condition Sometimes the transition should only be used when certain things have happened. A guard condition can be assigned to a transition to restrict use of the transition. Place the condition within square brackets somewhere near the transition arrow. The condition must test true before you may follow the associated transition to the next activity. The Activity diagram segment in Figure 14-2 tells you that you can’t leave the table when you’ve finished your dinner unless you have finished your vegetables.
152 Saturday Afternoon Eat your dinner [Finished your vegetables] Leave the table Figure 14-2 A guard condition on a transition Decisions The Activity diagram diamond is a decision icon, just as it is in flowcharts. In either diagram, one arrow exits the diamond for each possible value of the tested condition. The decision may be as simple as a true/false test (for example, the left-hand illustration in Figure 14-3 asks, “Are there sufficient funds in the customer’s account to cover the withdrawal”). The decision may involve a choice between a set of options. For example, the right-hand illustration in Figure 14-3 asks, “Would you like chocolate, vanilla, strawberry, or rocky road ice cream” Each option is identified using a guard condition. Each guard condition must be mutually exclusive so that only one option is possible at any decision point. The guard is placed on the transition that shows the direction that the logic follows if that condition is true. If you write code, then you have probably used a case statement to handle this same type of problem. [sufficient funds] [insufficient funds] [chose chocolate] [chose vanilla] [chose strawberry] [chose rocky road] Give the customer the money Shake your finger at the customer Serve up chocolate ice cream Serve up vanilla ice cream Serve up strawberry ice cream Serve up rocky road ice cream Figure 14-3 Making a decision Because every choice at a decision point is modeled with a guard condition, it is possible to use the conditional logic on transitions leaving an activity as well. For example, in Figure 14-4 the activity of computing the new account balance reveals whether the account is overdrawn. All the information needed to make the choice is provided by the activity. To show the choices resulting from an activity, simply model the transitions exiting the activity, each with a different guard condition.
- 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
- 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 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
- Page 213 and 214: 190 Saturday Evening 7:addProduct(c
- Page 215 and 216: 192 Saturday Evening REVIEW The Col
- Page 217 and 218: 194 Saturday Evening Scenario 1 Get
- Page 219 and 220: 196 Saturday Evening pointing towar
- Page 221 and 222: 198 Saturday Evening :OrderFullfill
- Page 223 and 224: 200 Saturday Evening Scenario 5, in
Session 14—Modeling the Functional View: The Activity Diagram 151<br />
Taking a Look at Activity Diagram Notation<br />
In this section, I give you a quick tour of the notation. A lot of this may be familiar if<br />
you’ve used flowcharts, so feel free to skim over the session until you spot something that<br />
looks new.<br />
Activities and transitions<br />
An activity is a step in a process where some work is getting done. It can be a calculation,<br />
finding some data, manipulating information, or verifying data. The activity is represented<br />
by a rounded rectangle containing freeform text. An Activity diagram is a series of activities<br />
linked by transitions, arrows connecting each activity. Typically, the transition takes place<br />
because the activity is completed. For example, you’re currently in the activity “reading a<br />
page.” When you finish this activity, you switch to the activity “turning page.” When you are<br />
done turning the page . . . well, you get the idea. Figure 14-1 shows this idea graphically.<br />
Read a page<br />
Turn a page<br />
Figure 14-1 Activities and transitions<br />
This notation starts to show the overlap between the Activity diagram and the Statechart<br />
diagram. In fact, the Activity diagram is a subset of the Statechart diagram. Each Activity is<br />
an action state where the object is busy doing something (as opposed to waiting). Each transition<br />
is a change in state, a change from one activity or active state to the next. So as you<br />
learn the Activity diagram, you are well on your way toward understanding the Statechart<br />
diagram as well. You’ll see and use the Statechart diagram in Sessions 20 through 23.<br />
Tip<br />
You may sometimes see the word “Do:” preceding the name of an activity.<br />
This is a common and valid notation to distinguish an activity from other<br />
state-related behaviors defined by the <strong>UML</strong>.<br />
Guard condition<br />
Sometimes the transition should only be used when certain things have happened. A guard<br />
condition can be assigned to a transition to restrict use of the transition. Place the condition<br />
within square brackets somewhere near the transition arrow. The condition must test<br />
true before you may follow the associated transition to the next activity. The Activity diagram<br />
segment in Figure 14-2 tells you that you can’t leave the table when you’ve finished<br />
your dinner unless you have finished your vegetables.
Change language