1. OMG Mailing List
  2. Precise Semantics for UML State Machines (PSSM) 1.0 Finalization Task Force

Open Issues

  • Issues not resolved
  • Name: pssm-ftf
  • Issues Count: 3

Issues Descriptions

Synchronous operation call on an active object ends if the corresponding call event occurrence was deferred

  • Key: PSSM-4
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Jeremie Tatibouet)
  • Summary:

    FUML 1.3 provides a support for the CallEvent semantics. When an object performs a synchronous operation call on an active object then a call event occurrence is placed in the event pool of the target (i.e. the active object that is the target of the call). While the target has not accepted the call and the RTC initiated by the acceptance is not completed, the execution thread in which the caller executes remains suspended.

    In PSSM context, the target of the call can be an active object whose executing a classifier behavior described thanks to a state machine. This state machine can have states that declare a call event as being deferred. This means that when the state is active and such call event is dispatched then it is going to be accepted by the state machine. The acceptance leads the call event occurrence to be placed in the deferred event pool of the active object.

    The problem here is that since the call event was deferred, this implies the operation call was not performed by the target. Hence the caller shall not be released before the call event gets "undeferred" (i.e., return back to the regular event pool). However, this is not what is specified in the StateMachineEventAccepter (see section 8.5.2 in [PSSM 1.0b]) semantics. Indeed, the acceptance of the call event occurrence systematically leads to release the caller. Instead, the caller shall only get released if the call event occurrence is used to trigger one to many transitions.

    The problem can be highlighted through the test case Deferred007_Test provided through the PSSM test suite.

    In this test, the call event occurrence corresponding to the op operation is dispatched when in configuration S1. This implies the state machine accepts and defers the event occurrence. At the end of the RTC step, the tester (i.e., the object that emitted the call) shall remain suspended. This shall be maintained until the end of the RTC in which the transition T6 is fired. To demonstrate this semantics, Deferred007 Test shall be refactored.

  • Reported: PSSM 1.0b1 — Mon, 15 May 2017 15:47 GMT
  • Updated: Tue, 13 Jun 2017 11:20 GMT
  • Attachments:

PSSM shall be aligned with fUML 1.3 and PSCS 1.1

  • Key: PSSM-1
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Jeremie Tatibouet)
  • Summary:

    PSSM is not compatible with fUML 1.3 and PSCS 1.1. This is the consequence of the changes introduced by FUML13-23, FUML13-25, FUML13-16, FUML13-1, FUML13-60 and PSCS11-6. The description below provides an overview of the changes that must be performed in the PSSM semantic model in order to make PSSM comptabile with fUML 1.3 and PSCS 1.1. Note that these changes will also require an update of the PSSM document.

  • Reported: PSSM 1.0b1 — Thu, 13 Apr 2017 12:24 GMT
  • Updated: Mon, 15 May 2017 07:45 GMT

PSSM implementation shall conform to bUML

  • Key: PSSM-2
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Jeremie Tatibouet)
  • Summary:

    The behavioral part of the PSSM semantic model is specified using Java syntax. The subset of Java that is used does not always conform to the mapping rules defined in Annex A of fUML between Java and Activities.

    Examples:

    1. Usage of index starting from 0 instead of 1 in StateActivation::hasCompleted operation.
    2. Constructor call with arguments in StateMachineEventAccepter::accept operation.
    3. Usage of an iterative for loop instead a parallel for loop in StateActivation::enterRegion operation.
  • Reported: PSSM 1.0b1 — Thu, 13 Apr 2017 13:02 GMT
  • Updated: Thu, 13 Apr 2017 13:02 GMT