UML Weekend Crash Course™ - To Parent Directory

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.