Issue 10478: RTC lifecycle state machine (rtc-ftf) Source: Technologic Arts (Mr. Takeshi Sakamoto, tsakamoto@tech-arts.co.jp) Nature: Uncategorized Issue Severity: Minor Summary: 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 Resolution: 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. Revised Text: · Remove Figure 7.4, RTC Lifecycle, from section 7.2.2.3, LifeCycle. · In the same section, "Initialization" subsection, remove last sentence. ("This composite state incorporates a number of concurrent and non-concurrent sub-states described below.") · In the same section, at the end of the "Initialization" subsection, add the following figure: Figure 7.4 - Lightweight RTC Lifecycle · In the same section, the first paragraph under "Execution Context" should be replaced: An RTC in the Alive state may participate in any number of execution contexts (see Section <cross reference to ExecutionContext >). These contexts shall be represented to an RTC as distinct instances of the ExecutionContext class. The ExecutionContext manages the behavior of each RTC that participates in it. This relationship is defined by the following state machine, which is embedded within the ExecutionContext's own lifecycle (see Figure <cross reference to ExecutionContext-Managed Lifecycle >). Each participating RTC is represented as a separate parallel region. Figure 7.5 - Execution Context-Managed Lifecycle · In the same section, "Execution Context" subsection, remove the last paragraph. · In the same section, add the following figure to the end of the "Error Handling" subsection: Figure 7.6 - Error Recovery · In section 7.2.2.6, ExecutionContext, replace Figure 7.5, ExecutionContext states, with the following: Figure <number> - ExecutionContextThe state machine of an ExecutionContext has two parts. The behavior of the ExecutionContext itself is defined by the upper region in the above figure. The behavior of the RTCs that participate in the context is defined by the lower region. The contents of that region are displayed in more detail in Figure <cross reference to ExecutionContext-Managed Lifecycle > in Section <cross reference to LightweightRTObject section>. Actions taken: December 5, 2006: received issue January 15, 2008: closed issue Discussion: End of Annotations:===== ource: Technologic Arts (Takeshi Sakamoto, ) 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