PSCS 1.0 FTF Avatar
  1. OMG Issue

PSUCSF — Invalid assertions in SysML test case 11.2.2.3

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

    In test case 11.2.2.3:
    b0.b1.p1_1.fp1 = b3 ;
    b0.b1.fp1 = b3 ;
    => Shall have the same effect at runtime, but currently don’t have

    In addition, according to SysML 1.4, assertions in test case 11.2.2.3 are wrong.
    It shall propagate in all cases.
    Currently says:
    b0.b1.p1_1.fp1 = b3 ;
    AssertTrue("Value successfully propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b3) ;
    AssertTrue("Value NOT propagated to b0.b2_2.p2", ! (b0.b2_2.p2.fp2 == b3)) ;
    b0.b1.fp1 = b4 ;
    // Multiple matching flow properties. Shall not propagate.
    AssertTrue("Value NOT propagated to b0.b2_1.p2", !(b0.b2_1.p2.fp2 == b4)) ;
    AssertTrue("Value NOT propagated to b0.b2_2.p2", !(b0.b2_2.p2.fp2 == b4)) ;

    Should say:
    b0.b1.p1_1.fp1 = b3 ;
    AssertTrue("Value successfully propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b3) ;
    AssertTrue("Value SUCCESSFULLY propagated to b0.b2_2.p2", b0.b2_2.p2.fp2 == b3) ;
    b0.b1.fp1 = b4 ;
    AssertTrue("Value SUCCESSFULLY propagated to b0.b2_1.p2", b0.b2_1.p2.fp2 == b4) ;
    AssertTrue("Value SUCCESSFULLY propagated to b0.b2_2.p2", b0.b2_2.p2.fp2 == b4) ;

    Also, the rule for « multiple matching flow properties » is not correctly implemented.

    => Changes are required in the extended execution model

  • Reported: PSCS 1.0b1 — Tue, 9 Dec 2014 17:24 GMT
  • Disposition: Resolved — PSCS 1.0
  • Disposition Summary:

    Changes required in the SysML test suite and the semantics

    11.2.2.3 is actually B.2.2.3.
    The extended execution model does not correctly implement SysML execution semantics.
    Indeed, a behavior proxy port is a proxy to the owning block. In terms of instances and objects in the locus, a port object (represented by a SysML_InteractionPoint) and the object owning the SysML_InteractionPoint are the same object. Modifying property values either by accessing a property by navigation from an object, or from an interaction point of thsi object, should have the same effect. This is not currently the case, as was reflected by the assertions in the test case B.2.2.3.
    The specific (and invalid) semantics were implemented in operations SysML_InteractionPoint::setFeatureValue and SysML::setFeatureValueOnInteractionPoint. These two operations can be removed. Note that SysML_InteractionPoint::setFeatureValue was the only operation of SysML_InteractionPoint, which means that this class is not really required anymore. However, other kinds of SysML ports (i.e., not behavior proxy ports) may require particular semantics. In order to ease possible future extension (that would address the other kinds of ports), the class can be kept.
    An other error in the currently implemented semantics is related to the case where there are multiple matching flow properties for propagation of a value assigned to a source flow property. The current semantics does not distinguish the case where multiple potential target flow properties belong to multiple objects or to a single objects. If there is one matching flow property per target object, there is no conflict and the propagation shall happen on each object. The body of SysML_Object::doPropagation shall be updated to reflect this.

  • Updated: Tue, 14 Jul 2015 05:53 GMT
  • Attachments: