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

All Issues

  • All Issues
  • Name: pssm-ftf
  • Issues Count: 4

Issues Descriptions

PSSM shall be aligned with fUML 1.3 and PSCS 1.1

  • Key: PSSM_-4
  • 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: Fri, 19 Jan 2018 01:17 GMT

PSSM implementation shall conform to bUML

  • Key: PSSM_-3
  • 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.


    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: Fri, 19 Jan 2018 01:17 GMT

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

  • Key: PSSM_-2
  • 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: Fri, 19 Jan 2018 01:16 GMT
  • Attachments:

Tests that send multiple signals are not correct

  • Key: PSSM_-1
  • Status: open  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    Any test in the PSSM test suite with a test driver that sends multiple signals to the model being tested may not currently be properly allowing all possible execution traces. This is because itt cannot, in general, be presumed that event occurrences are received in the order they are sent, even if they are all sent from the same thread. This was always true in fUML (per the statement of “the semantics of inter-object communications mechanisms” in subclause 2.4 of the spec), but it is completely, formally clear in fUML 1.3, in which EventOccurrence is an active class, such that all event occurrences are sent concurrently with each other.

    For example, consider test Transition 007 (described in subclause of the PSSM beta spec). The tester behavior for this test sequentially sends three signal instances: AnotherSignal, Continue and Continue again. However, while these signals are sent sequentially, there is no guarantee they will be received by the tested state machine in the same order. For example, one of the Continue signal instances could be received before the AnotherSignal instance, which would cause the state machine (as shown in Fig. 9.12) to take transition T3 to S2 and never get to S3.

    Rather than try to capture all the possible traces that should be allowed by the such tests a s currently modeled, it would be better to modify the tests so that they should only produce the trace that is currently suspected. This can be done by having the state machine under test send signals back to the tester, in order to coordinate the sending of sequential signals. For example, in the case of Transition 007, the state machine could send signals back to the tester as part of the doTraversial behaviors for transitions T1 and T2. The test behavior would then have to include accept event actions in order to wait between the send signal actions. (Of course, to allow the test to send signals back to the tester, either the Tester/Target association in the test architecture would need to be made bidirectional, or some signaling mechanism would need to be provided through the SemanticTest class.)

  • Reported: PSSM 1.0b1 — Tue, 5 Dec 2017 23:11 GMT
  • Updated: Fri, 19 Jan 2018 01:14 GMT