Enacting with states (Car parking example)

A state-based enaction is one in which events are availed depending on the states of the actors that take part in the execution of those events.

For example, consider the car parking description augmented with states as follows:

In the above description, the Driver actor is at some initial state, then drives to the ticket machine and ends up in at machine state.  The second event cannot be performed by the driver if he is not at machine state. Clearly, it does not matter whether this was written as the second, third or fourth event. What matters here is the state of the actor triggering the event.

A state-based enaction displays the state of the triggering actor before initiating the event, and the state of a secondary actor (if any) after responding to the event.

Figure1:Driver at initial state.

Figure 2: Driver at machine and Ticket machine at initial state

Figure 3: Both actors at ticket requested state.

Figure 4: Driver at ticket dispensed state and Ticket machine at ticket dispensed state

get pic for this!!!

Figure 5: Both actors at ticket taken state

To emphasise the role of states, we swap states of event two with those of event 4, so that we determine whether the fourth event will be availed upon the processing of the first event. Doing this would allows us (description authors) to reason whether the use case events can proceed in that fashion (and change the description as appropriate).

The enaction will proceed as follows:

Then...

Which is logically incorrect (why?...a driver can not take a ticket before it is dispensed...unless am the driver in question!)....this is the type of description validation that we are supporting!