1. OMG Mailing List
  2. Precise Semantics of UML Composite Structures (PSCS) 1.1 Revision Task Force

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: pscs-rtf
  • Issues Count: 4

Issues Descriptions

Any EventOccurrence should be associatable as an interaction point.

  • Key: PSCS11-6
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    The EventOccurrence class was introduced in fUML 1.2, with SignalEventOccurrence as a subclass. However, PSCS 1.0 only allows a SignalInstance to be associated with the InteractionPoint of the port through which it was sent. This should be changed to allow any EventOccurrence to be associated with an InteractionPoint, so that other types of EventOcurrences may be identified as sent through ports (which is necessary to properly handle them on Triggers with port references).

  • Reported: PSCS 1.0 — Thu, 8 Dec 2016 20:09 GMT
  • Disposition: Resolved — PSCS 1.1
  • Disposition Summary:

    Any EventOccurrence should be associatable as an interaction point.

    Note: The technical changes proposed to PSCS are dependent on issues resolved for fUML 1.3:

    ­FUML13-23: Enable any kind of event occurrence to be exchanged between active objects.

    ­FUML13-25: Enable EventOccurrence and its subclasses to provide operations to define trigger matching as well as data extractions semantics.

    Proposal: In order to introduce the possibility to send any EventOccurrence through ports and connectors in PSCS, four different groups of changes shall be performed:

    1. Classes CS_Object, CS_InteractionPoint and CS_Reference contribute to the event based communications propagation mechanism limited to SignalInstance. These classes must have their send(…), sendIn(…) and sendOut(…) operation signatures and specifications changed to make sure it is allowed to propagate EventOccurrence (cf. section 8.4.3.2.3 in fUML 1.2.1) instead of CS_SignalInstance. These changes directly rely on those proposed in resolution FUML13-23.
    2. In PSCS 1.0 only signal instances where intended to be propagated through ports and connectors, hence an extension to SignalInstance was provided. This extension (i.e., CS_SignalInstance) captures the port through which a signal instance was received. The problem here is that this information is not specific to signal instances but general to any kind of event occurrence that might be propagated along ports and connectors. Hence, CS_SignalInstance shall be removed and replaced by CS_EventOccurrence, which must reference an EventOccurrence (i.e., the event occurrence actually propagated) and a CS_InteractionPoint (i.e., the port instance through which the propagated event occurrence has arrived). CS_EventOccurrence must also override operations getParameterValues and match inherited from EventOccurrence.
    3. The above two groups of changes imply modifications of the specifications of both CS_AcceptEventActionActivation and CS_SendSignalActionActivation. The changes to CS_AcceptEventActionActivation consist in:
      • Removing the match operation that does not need to be overridden since its specification was changed in FUML13-25 to rely on the matchAny operation provided in EventOccurrence.
      • Overriding the accept operation in order to make sure that if a CS_eventOccurrence is received then the event occurrence that is finally accepted is the wrapped event occurrence.
        The changes to CS_SendSignalActionActivation consist in:
      • Removing the doActionDefault operation which does not need to exist since it does not change the semantics provided by SendSignalActionActivation doAction operation and CS_SignalInstance is removed from the PSCS semantic model.
      • Updating the definition of the doAction operation in order to account for the usage of EventOccurrence instead of SignalInstance or CS_SignalInstance.
    4. In FUML13-25, the implementation of ReadIsClassifiedObjectAction doAction operation has changed. Type checking semantics now relies on operations instanceOf and checkAllParents which are both provided by the Value class. This change implies that it is not anymore required for PSCS to provide an extension to ReadIsClassifiedObjectAction. Indeed operations (checkAllParents, isDescendant and realizesInterface) provided in this extension must be moved to CS_Object (which is a kind of Value) to ensure specific type checking semantics related to interfaces is preserved. Since CS_ReadIsClassifierObjectActionActivation does not add semantics to ReadIsClassifierObjectActionActivation it must be removed from the PSCS semantic model.
  • Updated: Thu, 22 Jun 2017 16:46 GMT

Behavior Ports should be able to handle CallEventOccurrences

  • Key: PSCS11-7
  • Status: closed  
  • Source: nMeta ( Ed Seidewitz)
  • Summary:

    In PSCS 1.0, when an Operation is dispatched to a behavior Port, it is ignored, because fUML 1.2 does not support CallEvents. However, PSSM allows StateMachines to have CallEvents on Triggers, and it should be possible to dispatch an Operation call through a behavior Port, as a CallEventOccurrence to be handled by a classifierBehavior that is a StateMachine.

  • Reported: PSCS 1.0 — Thu, 8 Dec 2016 20:14 GMT
  • Disposition: Resolved — PSCS 1.1
  • Disposition Summary:

    Behavior Ports should be able to handle CallEventOccurrences

    Note: The technical changes proposed to PSCS are dependent on issues resolved for fUML 1.3:

    FUML13-16: Support for synchronous call of operations on active objects.
    FUML13-1: SendSignalAction completion semantics.
    ­FUML13-60: Simplification to resolution of issue FUML13-1.

    It also relies on the resolution specified for PSCS11-6. This resolution introduces the possibility to have any event occurrence associable with an interaction point.

    Proposal: Enabling the possibility to dispatch an operation call on a behavior port requires to allow the creation of an execution when the dispatched operation arrives at a CS_InteractionPoint which is a manifestation of a behavior Port. The created execution must be a CS_CallEventExecution (a specialization of CallEventExecution – see FUML13-16). This latter is an execution that describes the production and the sending of a CS_EventOccurrence wrapping a CallEventOccurrence. The target of the sending is the owner of the interaction point which is the manifestation of the behavior port. The CS_EventOccurrence that is added to the event pool of the active object references this interaction point. This enables the classifier behavior that may accept this event occurrence to declare a trigger that identifies a Port from which the event occurrence might be accepted.

    The introduction of such changes require to update both AcceptCallActionActivation (see FUML13-16) and CS_SendSignalActionActivation. Hence, a CS_AcceptCallActionActivation must be provided in order to enable a CallEventOccurrence to be unwrapped in the case a CS_Eventoccurrence is accepted. In the case of CS_SendSignalActionActivation, only an update to the doAction operation is required. This update enables the possibility to wrap the SignalEventOccurrence to a CS_EventOccurrence, to initialize this latter with the Port and the direction to which the event occurrence shall be propagated and to make this event occurrence responsible for the effective sending to the target. The sending will occur using specific operations sendInTo and sendOutTo provided by CS_EventOccurrence.

    As CS_EventOccurrence is an active object (it specializes EventOccurrence – see FUML13-1 and FUML13-60). In order to specialize the classifier behavior inherited from EventOccurrence the doSend operation must be overridden in CS_EventOccurrence. The behavior specified for this operation enables to account for the direction and the port through which the event occurrence must be forwarded.

  • Updated: Thu, 22 Jun 2017 16:46 GMT

Problem with access to the context object in CS_SendSignalActionActivation

  • Key: PSCS11-4
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    CS_SendSignalActionActivation has to retrieve the context object, in order to determine how to propagate the signal instance. This is done with the following statement :
    Object_ executionContext = this.group.activityExecution.context;

    This statement does not cover all possible cases. The correct statement is :
    Object_ executionContext = this.getActivityExecution().context ;

  • Reported: PSCS 1.0 — Mon, 29 Feb 2016 13:03 GMT
  • Disposition: Resolved — PSCS 1.1
  • Disposition Summary:

    Problem with acces to the context object CS_SendSignalActionActivation

    Agreed. The usage of statement this.group.activityExecution.context prevents to return the activity execution to which the group may indirectly belong.

  • Updated: Thu, 22 Jun 2017 16:46 GMT

Incorrect SysML term used in SysML Annex

  • Key: PSCS11-5
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The term "behavior proxyport" isn't in SysML, but is used in Annex B many times. Ports can't be both behavioral and proxy. Informally, both kinds of port "stand in" for other objects, but behavior ports stand in for the owning object, while proxy ports stand in for internal parts. I think the Annex is referring to behavior ports, at least I recall Clause 11.2.2.3 (Block with Multiple Behavior ProxyPorts) is. The error seems to be causing some of the SysMLers to think the annex applies to proxy ports.

  • Reported: PSCS 1.0 — Thu, 22 Sep 2016 13:37 GMT
  • Disposition: Deferred — PSCS 1.1
  • Disposition Summary:

    Incorrect SysML term used in SysML annex

    Consensus could not be reached during the RTF due to lack of time. We proposed to defer the issue for the next RTF.

  • Updated: Thu, 22 Jun 2017 16:46 GMT