UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 21—Applying the Basic Statechart to the Case Study 219 The same simplification may be used for actions associated with events that leave a state. These are called exit actions and are modeled in the same manner as entry actions. If you refer back to Figure 21-1, you will see two events leaving the Placed state. Both events have the same associated action, issueCustomerStmt(). Figure 21-3 shows the exit/action(s) notation added to the internal transitions compartment of the Placed state and the actions removed from the event arrows. Compare Figure 21-1 with 21-3 to appreciate the simplification. receive pmt Order is filled Filled Tentative Placed entry/issueConf() exit/issueCustomerStmt() authorize override cancel Cancelled Figure 21-3 Consolidating the exit actions Entry and exit action notations provide a nice simplification for the Statechart diagram. Just remember that they may only be used when the action takes place every time you enter (for entry actions) or every time you exit (for exit actions) the state. If there is even one exception, the notation may not be used for that action. Defining Send Events Figure 21-4 introduces the send event. A send event is used when the object in the Statechart diagram needs to communicate with another object. On a Statechart diagram, the source of the incoming events is not shown because the same event may come from any number of other objects and the response must be the same. But an outgoing event must define the receiving object whether it is only one object or a broadcast to many objects. It works in the same way you use your phone. You can receive calls without knowing who is calling. But you cannot place a call without the number you want to call.
220 Sunday Morning receive pmt Order is filled Filled Tentative Placed entry/issueConf() exit/CustomerStmt.issue() authorize override cancel Cancelled Figure 21-4 Modeling an action invoked on another object In the example in Figure 21-3, when the Order is cancelled, the Order is supposed to issue a customer statement. But the customer statement is another object that takes care of issuing itself. The Order just needs to tell it that it’s time to do so. All the actions modeled so far were actions on the same object. To show that the action is invoked on a different object, simply provide the object name followed by a period before the action expression. This is often referred to as the dot notation. See the exit action notation in Figure 21-4 where the issue() action is now being sent to the CustomerStmt object. Order of Events With all these events, you could end up with a tangled mess of event actions, entry actions, exit actions, and activities. So how do you process all this behavior in a sane fashion When an event occurs, the order of execution runs like this: 1. If an activity is in progress in the current state, interrupt it (gracefully if possible). 2. Execute the exit: action(s). 3. Execute the actions associated with the event that started it all. 4. Execute the entry: action(s) of the new state. 5. Execute the activity or activities of the new state.
- 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
- Page 226 and 227: SESSION 20 Modeling the Dynamic Vie
- Page 228 and 229: Session 20—Modeling the Dynamic V
- Page 230 and 231: Session 20—Modeling the Dynamic V
- Page 232 and 233: Session 20—Modeling the Dynamic V
- Page 234: Session 20—Modeling the Dynamic V
- Page 238 and 239: Part V — Sunday Morning Session 2
- Page 240 and 241: SESSION 21 Applying the Basic State
- Page 244 and 245: Session 21—Applying the Basic Sta
- Page 246 and 247: Session 21—Applying the Basic Sta
- Page 248: Session 21—Applying the Basic Sta
- Page 251 and 252: 228 Sunday Morning receivePmt(amt)[
- Page 253 and 254: 230 Sunday Morning Figure 22-4 repr
- Page 255 and 256: 232 Sunday Morning A substate is a
- Page 257 and 258: 234 Sunday Morning Monitor when tem
- Page 260 and 261: SESSION 23 Applying the Extended St
- Page 262 and 263: Session 23—Applying the Extended
- Page 264 and 265: Session 23—Applying the Extended
- Page 266 and 267: Session 23—Applying the Extended
- Page 268 and 269: SESSION 24 Modeling the Development
- Page 270 and 271: Session 24—Modeling the Developme
- Page 272 and 273: Session 24—Modeling the Developme
- Page 274 and 275: Session 24—Modeling the Developme
- Page 276 and 277: Session 24—Modeling the Developme
- Page 278 and 279: SESSION 25 Modeling the Static View
- Page 280 and 281: Session 25—Modeling the Static Vi
- Page 282 and 283: Session 25—Modeling the Static Vi
- Page 284 and 285: Session 25—Modeling the Static Vi
- Page 286 and 287: SESSION 26 Modeling the Static View
- Page 288 and 289: Session 26—Modeling the Static Vi
- Page 290 and 291: Session 26—Modeling the Static Vi
Session 21—Applying the Basic Statechart to the Case Study 219<br />
The same simplification may be used for actions associated with events that leave a state.<br />
These are called exit actions and are modeled in the same manner as entry actions. If you refer<br />
back to Figure 21-1, you will see two events leaving the Placed state. Both events have the<br />
same associated action, issueCustomerStmt(). Figure 21-3 shows the exit/action(s) notation<br />
added to the internal transitions compartment of the Placed state and the actions removed<br />
from the event arrows. Compare Figure 21-1 with 21-3 to appreciate the simplification.<br />
receive pmt<br />
Order is filled<br />
Filled<br />
Tentative<br />
Placed<br />
entry/issueConf()<br />
exit/issueCustomerStmt()<br />
authorize override<br />
cancel<br />
Cancelled<br />
Figure 21-3 Consolidating the exit actions<br />
Entry and exit action notations provide a nice simplification for the Statechart diagram.<br />
Just remember that they may only be used when the action takes place every time you<br />
enter (for entry actions) or every time you exit (for exit actions) the state. If there is even<br />
one exception, the notation may not be used for that action.<br />
Defining Send Events<br />
Figure 21-4 introduces the send event. A send event is used when the object in the<br />
Statechart diagram needs to communicate with another object. On a Statechart diagram,<br />
the source of the incoming events is not shown because the same event may come from any<br />
number of other objects and the response must be the same. But an outgoing event must<br />
define the receiving object whether it is only one object or a broadcast to many objects. It<br />
works in the same way you use your phone. You can receive calls without knowing who is<br />
calling. But you cannot place a call without the number you want to call.
Change language