${taskforce.name} Avatar
  1. OMG Task Force

Precise Semantics of UML Composite Structures 1.0 FTF — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

CS_Reference shall redefine Reference::copy

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

    CS_Reference shall redefine operation Reference::copy, otherwise, when a copy of a CS_Reference is made, a Reference is returned while a CS_Reference should be.

  • Reported: PSCS 1.0b1 — Thu, 17 Jul 2014 15:32 GMT
  • Disposition: Resolved — PSCS 1.0
  • Disposition Summary:

    Add missing operation

    Add the missing operation on CS_Reference

    Update Figure 21 accordingly.

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

Invalid assertions in SysML test case 11.2.2.3

  • Key: PSUCSF-2
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. 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:

Clarify use of test suite to demonstrate conformance

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

    The specification shall clarrify if passing the test suite is a necessary or sufficient condition to demonstrate conformance with the specification

  • Reported: PSCS 1.0b1 — Thu, 11 Dec 2014 21:49 GMT
  • Disposition: Resolved — PSCS 1.0
  • Disposition Summary:

    Add text to clause 2 (conformance)

    In the clause 2 (conformance), add “Semantic Conformance. A conforming execution tool must provide execution semantics for a conforming model consistent with the semantics specified in clause Semantics of this document. Passing all the tests of the test suites in clause 9 are sufficient to demonstrate conformance with the semantics specified in clause 8.”

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

Section 2.2 - Editorial

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

    In Section 2.2, Second bullet, the text mentions « 2 new semantic variation points » but there are actually 3 semantic variation points.

  • Reported: PSCS 1.0b1 — Thu, 11 Dec 2014 21:56 GMT
  • Disposition: Resolved — PSCS 1.0
  • Disposition Summary:

    Update the text to say "three" instead of "two"

    In clause 2.2, second bullet, replace "two" by "three" in the sentence:

    "In addition, this specification introduces two new semantic variation points and corresponding default strategies for them:"

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