RTC — RTC lifecycle state machine

Source: Technologic Arts (Takeshi Sakamoto, <tsakamoto AT SPAMFREE tech-arts DOT co DOT jp>)

Severity: Minor

Disposition: Resolution Proposed

Summary

The state machine diagram and the sequence diagram are related as follows.

[attachment:sequence-with-fsm.png]

Transition (Event) in the state machine diagram responds to operation called by other elements, and actions in the state respond to operation calls other elements operation. In Figure 7.4 RTC lifecycle, it describes operation that owned ExecutionContextEntity for Transition (Event) among Inactive state and Active states. Also, there is an explanation: "When an RTC is in Error, it may be reset. If resetting is successful, the RTC shall return to the Inactive state. If resetting is unsuccessful, it shall remain in the Error state" (Page 14). But Figure 5 describes that whenever "LifeCycle::reset" is called, it should transition from Error state to Inactive state for sure. Considering these points, I think that state machine diagram (part) about RTC becomes the following.

Proposed Resolution

[attachment:rtc-lifecycle3.png]

Discussion

I agree with the movement of the reset operation from LifeCycle to ExecutionContext. However, the updated diagram implies some behaviors that seem unusual to me. Are these intended?

*

When a component first enters the Alive state, it will receive an on_deactivate message even though it has never been Active.
*

A component leaving the Active state for the Error state will not receive an on_deactivate message.
*

on_reset occurs only when exiting the Error state, meaning after reset_component() has returned successfully. But the result from reset_component() should be based on the result from on_reset().

The only transition in the original lifecycle diagram that looks problematical to me is the reset transition. What if we keep the original diagram with the following two small changes:

*

change LifeCycle::reset to ExecutionContext::reset_component
*

add a guard condition [return == OK]

Would that address the concerns?

– RickWarren, 2006/12/1

Yes. The state machine diagram included some mistakes. Sakamoto-san corrected it. The state machine diagram was updated.

*

on_deactivate was moved from Inactive entry action to Active exit action.
*

Therefore, when a component does transition from "Active" state to "Error" or to "Inactive", now the component receives on_deactivate message.
*

If on_reset() returns error, "Error" state would not move to "Inactive" state.

– NoriakiAndo, 2006/12/4

The lifecycle is currently modeled as belonging to a component itself and having parallel regions corresponding to the execution context in which the component participates. This relationship should be reversed. The lifecycle should belong to the execution context and have parallel regions for the participating components. That change will give the transitions the correspondence to sequence diagram messages that is described above.