The description of the Testcase says:

an operation or is called in synchronous manner through the port pp

However the corresponding Activity Diagram in Figure 9.20 doesn't show the "via pp" string, that would signify that this port is to be used for the call.

The notation for the Pins is wrong: They are shown as filled squares, which would mean, that they are referring to streaming Parameters.

Also there are errors in the Class-Diagram Figure 9.18

• The usage on the left is missing the guillemets around «use»
• The dependency on the right should be an InterfaceRealization
• Reception Start and Operation P() should be shown in separate compartments
• The ports are listed in the compartment for attributes. While this is allowed, it is unusual. It would be better to show the ports as squares. At least the conjugated port should show a "~" (this is not defined for attributes, but when a port is shown as attribute, it should also use the port's notation).

Update Figures 9.18 and 9.20

Both diagrams should be updated as indicated in the issue, except that:

• The tooling used for the diagram in Figure 9.18 does not put receptions and operations in different compartments. Receptions and operations also appear together on other class diagrams in Clause 9. Nevertheless, it is still clear what is being specified as a reception and what is being specified as an operation. Therefore, it is not worth manually correcting Figure 9.18 in a way that would be inconsistent with other existing diagrams, or trying to update all diagrams where this occurs.

• In general, the overview class diagrams for test cases in Clause 9 do not show ports at all. These are only shown on the internal structure diagrams. Therefore, it is sufficient to simply remove the port declarations from Figure 9.18, since they are shown on Figure 9.19.

Subclause 6.2 Changes to Adopted OMG Specifications of the Precise Semantics for UML State Machines (PSSM) Beta 1 specification document (ptc/17-04-04) states:

The PSSM syntax is a subset of the UML 2.5.1 abstract syntax metamodel, and the required functionality formalized in PSSM is taken from that specified in UML 2.5.1. However, PSSM is also semantically based on fUML and PSCS. But the current versions of these standards, fUML 1.2.1 and PSCS 1.0 are based on UML 2.4. In order to avoid inconsistency, particularly given the sweeping reorganization of the UML abstract syntax metamodel adopted in UML 2.5, the fUML and PSCS syntax and semantics models have been migrated to UML 2.5.1 for use with PSSM, but with no change to their functionality. In addition, the fUML and PSCS models have been updated to use an approach for identifying and constraining their syntax subsets that is consistent with that used in PSSM.

In adopting this specification, the PSCS RTF was directed to update the PSCS specification consistent with the migration of fUML syntax and semantics models top UML 2.5.1. Since the adoption of PSSM, PSCS 1.1 has been approved as the current version of PSCS, so the PSCS 1.2 RTF now needs to carry out the migration of PSCS 1.1 to UML 2.5.1 for PSCS 1.2.

Migrate PSCS to UML 2.5.1

Migrating PSCS to UML 2.5.1 and adopting the new approach for identifying and constraining their syntax subsets (but with no change to PCSC functionality), requires the following updates to the PSCS specification document:

• Remove subclause 2.2 on conformance levels.
• Update the normative references to UML 2.5.1 and fUML 1.4 and remove any references to the infrastructure/superstructure separation..
• Update subclause 6.1 Changes to Adopted Specifications to remove the reference to UML 2.4.1..
• Update Clause 7 Abstract Syntax to reflect the UML 2.5.1 package structure and the new approach for specifying the PSCS abstract syntax subset.
• Update Clause 8 Semantics to reflect the UML 2.5.1 package structure.

The normative syntax and semantics XMI also need to be updated to reflect the new approach for specifying the abstract syntax subset and for the UML 2.5 reorganization.

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.

Annex B is correct

Annex B does in fact apply specifically to ProxyPorts, and only to ProxyPorts. And it also only applies to ProxyPorts with isBehavior = true, that is, "behavior" ProxyPorts. Note that, in UML, a behavior Port does not actually have its own behavior, but has its behavior handled by the classifier behavior of its owning object, rather than via a delegation connector. (See the definition of Port::isBehavior and the corresponding semantics specification in subclause 9.3.12 of the UML 2.4.1 specification or subclause 11.3.3.1 of the UML 2.5.1 specification.)

Further, SysML does in fact allow behavior ProxyPorts. According to he SysML 1.4 specification (on which the Annex is based), subclause 9.3.2.12 (emphasis added),

Completely specified proxy ports must be connected to internal parts or be behavioral, to enable the owning block or connected internal parts to handle or initiate any interactions through the port.

"Being behaviorial" is interpreted here as meaning isBehavior = true. This is as opposed to FullPorts, which "cannot be behavioral (isBehavior = false)" according to constraint [3] of subclause 9.3.2.8 of the SysML 1.4 specification.

There for, the Annex is essentially correct in discussing "behavior ProxyPorts". The SysML 1.4 specification actually uses the term "behavioral port", but the more proper term according the UML specification is really "behavior port".

Figure 9.66 was exported with tool focus which looks odd in the specification document. In addition, this figure looks hard to read due to the small font size.

Figure 9.66 includes user tool focus and is hard to read

The resolution consists in replacing Figure 9.66 by the one provided in the proposed resolution

CS_OpaqueExpressionEvaluation is a specialization of the absract Evaluation (see section 8.4.2.1 in [fUML 1.4]) class. It provides the capability to execute the behavior (see section 8.6.16.5 in [UML 2.5.1]) associated with an opaque expression.

Signature of the evaluate operation is incorrect. Indeed, the signature specifies that a Value is always returned while in the implementation of that operation clearly state that null can be returned. This implies the operation signature should be updated to be:

evalute() : Value [0..1]

CS_OpaqueExpressionEvaluation evaluate operation return parameter has invalid multiplicities

The resolution consists in updating the operation signature as well as the diagram showing this signature.