PSCS updates the semantics for ClearStructuralFeatureValueAction, so that, "when a StructuralFeature is cleared, any links representing an instance of a Connector in which the StructuralFeature is involved are destroyed" (see 8.2.2.2.2 CS_ClearStructuralFeatureActionActivation).

However, there is no similar update to the semantics for RemoveStructuralFeatureValueAction. So, if a single value is removed from a StructuralFeature, it is possible that this value will still have links to it that are instances of Connectors from within the composite. This violates the semantics of Connectors, whose instances are only supposed to link values within properties of the containing composite object.

Recommendation: Add a CS_RemoveStructuralFeatureValueActionActivation to destroy relevant connector links to a value when the value is removed from a structural feature.

RemoveStructuralFeatureValueAction should destroy constructor links

As suggested in the issue description, PSCS is required to provide an extension to the semantics defined by fUML for RemoveStructuralFeatureValueAction (see section 8.6.3.2.12 in [fUML 1.2.1]). The defined extension will be in charge, when a value is removed from a feature value, to destroy all links (i.e., instances of connectors) in which the removed value is involved.

In order to capture the new semantics, CS_RemoveStructuralFeatureValueActionActivation visitor is required to be included in the PSCS semantic model. This visitor class must be defined as a specialization of RemoveStructuralFeatureValueActionActivation. It overrides the doAction operation of its superclass. The doAction operation captures the exact same semantics than the one defined in fUML however it add the possibility to propagate the impact of the removed value(s) to the relevant connectors. This propagation is ensured in getLinkToDestroy and propagateDestructionToLinks which respectively find the connectors instances to destroy and perform the actual destruction.

As a side adjustment, CS_ExecutionFactory instantiateVisitor operation is updated to enable the creation of a CS_RemoveStructuralFeatureValueActionActivation.

ad-13-11-08.xmi - parse error on line 19, xsi namespace not defined (SysML Semantics)
ad-13-11-09.xmi - parse error on line 2248, xsi namespace not defined (SysML test suites)

Remove xsi:nil

The indicated files have several cases in which xsi:nil=true is used to indicates empty values. These should all be removed.

In addition, the SysML Test Suite XMI contains XMI extensions that are Ecore specific. While these can be ignored by a non-Ecore tool, they are really not appropriate for a clean XMI file (even if it is just informative) and should be removed.

Machine readable files are currently not in canonical XMI format. They shall be.

Regenerate normative XMI files

Agreed, all the normative XMI files should be in canonical XMI format. It is less important that the informative XMI files be in canonical XMI, except for the Generic Association model, which may actually be used be user models conforming to PSCS.

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

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.

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

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.”

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

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:"