Issue 13039: Strange relation between methods and transitions (amsm-ftf) Source: THALES (Mr. Willy Boenink, willy.boenink(at)nl.thalesgroup.com) Nature: Enhancement Severity: Significant Summary: Strange relation between methods and transitions. The expected state and the methods to use to reach the state depend on the previous state. That is very strange and error prone. e.g. if the wanted state is STOPPED, case the current state is RUNNING, ShutDown must be called. In case the state is HALTED, Stop must be called.The method should denote the wanted state with this limitation that only specified state transitions are possible. Note that there is no operation to enter the HALT state. " Resolution: Agree. Let's summarize: the StartUp methods are for reaching state "RUNNING" (transitions LOAD_START, START, LOAD_START_DIRTY; CONTINUE is lacking here), the Shutdown methods are for reaching state "EXECUTABLE" (transitions UNLOAD, RECOVER, RECOVER_DIRTY; STOP have to be removed here), the Load method reaches the state "LOADED" (transitions LOAD, LOAD_DIRTY), the Stop method reaches the "STOPPED" state (transitions HALT, STOP_HALTED; HALT should be replaced by STOP here), and the "Continue" method is a shorthand to reach the state "RUNNING" from the state "HALTED". Eventually, the state "HALTED" is no more reachable and a method "halt" has so to be added to reach it". Revised Text: Page 37: Replace the figure 7.7 ("Application class diagram (1/3)") with the following: Page 44: In the table of the section 7.1.4.3, add the following line just after the "Operations" line: halt return type unit16 And add a new paragraph 7.1.4.3.1 "Halt ()" (and rename the following ones 7.1.4.3.x): This operation stops the executable software element. It shall return: o AMS_RESOURCEERROR if the element could not be stopped on account of an OS resource starvation error (lack of memory, disk) when performing one of the actions of the associated specification. o AMS_RIGHTERROR if the element could not be stopped on account of an OS right error when performing one of the actions of the associated specification. o AMS_BADSTATE if the element is not in a state in which it could be halted. o AMS_HALTFAILED if the element could not be halted for any other reason. In all case of error, a full explanation of the cause of the error shall be logged. After an error, the executable software element remains in which it was before the execution of the method. Page 121: Replace the table 7.5 ("Mapping between ESE methods and transitions) of the section 7.1.14.2 ("Mapping between ESE transitions and methods") with the following one: Methods Transitions StartUp, StartUpOnSpec, StartUpOnHost LOAD_START, START, LOAD_START_DIRTY ShutDown, ForceShutDown UNLOAD, RECOVER, RECOVER_DIRTY Load LOAD, LOAD_DIRTY Stop STOP, STOP_HALTED Continue CONTINUE Halt HALT Page 116: In the Table 7.4 ("Error Codes"), add the following ones between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED The AMS_ExecutableSoftwareElement::Halt method failed for an unknown reason (see log). Page 129: In section 8.6.1 ("AMS_Util.idl"), in the enum "AMS_ErrorCode", add the following snippet between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED, Page 139: In section 8.6.4 ("AMS_Application.idl"), in the interface "AMS_ExecutableSoftwareElement", after the line "void Continue ( ) raises (AMS_Util::AMS_Error);", add the following snippet: void Halt ( ) raises (AMS_Util::AMS_Error); Page 241: In section 10.1.4.2 ("Application"), after the line "uint16 Continue();", add the following snippet: [Description ("This operation halts the executable software" "element.")] uint16 Halt(); Page 282: In section 11.1.6 ("Mapping"), in the enum "AMS_ErrorCode", add the following snippet between the AMS_BADSTATE and AMS_STARTFAILED lines: AMS_HALTFAILED, Page 285: In section 11.1.6 ("Mapping"), after the line "#pragma keylist AMS_CT_Continue Element", add the following snippet: // struct AMS_CT_Halt { // identifier of the request long request_id; // the element to be controled string Element; // the attributes (cf. PIM) }; #pragma keylist AMS_CT_Halt Element Actions taken: October 31, 2008: received issue October 31, 2008: received issue July 23, 2009: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 31 Oct 2008 07:48:05 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Willy Boenink Company: Thales Nederland mailFrom: willy.boenink@nl.thalesgroup.com Notification: No Specification: AMSM Section: 7.1.14.2 FormalNumber: dtc/2008-02-02 Version: Beta 2 RevisionDate: 02/02/2008 Page: 121 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008051206 Firefox/3.0 Description Strange relation between methods and transitions. The expected state and the methods to use to reach the state depend on the previous state. That is very strange and error prone. e.g. if the wanted state is STOPPED, case the current state is RUNNING, ShutDown must be called. In case the state is HALTED, Stop must be called.The method should denote the wanted state with this limitation that only specified state transitions are possible. Note that there is no operation to enter the HALT state. "