FUML12 — 7.4.2.2.12 JoinNode & clarifying the confusing terminology between conformance and compliance

Specification: Semantics of a Foundation Subset for Executable UML Models, FTF – Beta 1 (ptc/08-11-03)

Section: 2 (Conformance)

Since fUML is a subset of the UML, there are two possible kinds of syntactic conformance issues:

a) Checking whether an M1 model written in a superset of fUML (e.g., the UML) conforms to the fUML subset.

b) Checking whether an M2 extension of fUML (e.g., SysML, UML) complies with the fUML subset

Proposed resolution:

1) Clarify the meaning of the confusing terminology:

• Syntactic conformance is a criteria for M1 models, i.e., (a) above.

• Syntactic compliance is a criteria relative to a compliance level of an M2 metamodel, i.e. (b) above or to a package unit defined in an M2 metamodel.

This proposed resolution is consistent with the current terminology of compliance levels for metamodels including fUML, UML, UML4SysML, etc…

2) Distinguish in the specification document conformance vs. compliance constraints.

For example, per 12.3.34 of the UML 2.2, a JoinNode as a required ValueSpecification:

JointNode::joinSpec : ValueSpecification[1..1] with a default value: “and”

Clearly, the fUML subset does not support M1 models with a JointNode whose joinSpec is anything except the default “and” value specification. This is an M1 conformance constraint that can be specified in OCL.

Extensions of fUML such as the UML itself should not have this constraint because it is not a compliance requirement for any extension of fUML such as the UML which specifically allows join specification values other than “and”.

Compliance constraints should be constraints that fUML and any M2 extension of fUML satisfy.

Conformance constraints are more restrictive; they specify how to verify that an M1 model written in a given superset of fUML (e.g., UML) is still within the fUML subset.

7.4.2.2.12 JoinNode

Add a comformance constraint:

[1] conformance relative to UML::Activities::CompleteActivities (unmerged) or to UML L3 (merged)

– The join specification must be “and”

self.joinSpec.oclIsTypeOf(LiteralString) and self.joinSpec.oclAsType(LiteralString).value = 'and'

Out of scope

This is an important issue. However. It is more than can be dealt with in the context of the fUML RTF. A general strategy is needed in the context of other standards extending fUML, which are now already emerging (such as PSCS and PSSM). Perhaps this can be done as part of the transition of fUML to UML 2,5, which is also beyond the scope of this issue.

In addition, the proposed conformance/compliance terminology is probably not consistent with ISO practice.