SysMLv1: Why ParticipantProperty is needed for an AssociationBlock. (And why you should NOT use the optional Cameo Systems Modeler variant with owned ends.)

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
TIP
TOOL
Policy level
INFORMATIVE
Specification keywords
SysML-1.2
SysML-1.3
SysML-1.4
SysML-1.5
SysML-1.6
UML keywords
AssociationClass
Association::ownedEnd
Association::memberEnd
SysMLv1.x keywords
AssociationBlock
ParticipantProperty
Keywords
Click on the image to view it full size

Here we examine an advanced SysMLv1 topic, the gory details of ParticipantProperty, and learn exactly why it is needed to support AssociationBlocks.

Firstly, note that "association block" is an informal term, there is no AssociationBlock stereotype in SysMLv1:

SysMLv1.7: 'The Block stereotype extends Class, so it can be applied to any specialization of Class, including Association Classes. These are informally called "association blocks." An association block can own properties and connectors, like any other block.'

Our aim is to fully understand the following:

SysMLv1.7: 'Each instance of an association block can link together instances of the end classifiers of the association. To refer to linked objects and values of an instance of an association block, it is necessary for the modeler to specify which (participant) properties of the association block identify the instances being linked at which end of the association.'

By default an AssociationBlock has member ends but no owned ends (as shown for AssociationBlock AB between blocks A and B), which turns out to be significant.

If you look at the IBD for AB it can display the "extra" ParticipantProperty items. But it doesn't have direct access in the IBD to a:A and b:B. Without the ParticipantProperty items, there would be no way of connecting anything up to represent sub-structure within a connection, which is the primary purpose of the SysMLv1 AssociationBlock.

An AssociationBlock can carry values, such as abVal, which already offers some advantages. But the real action happens with you introduce additional parts for representing fine-grained sub-structure of a connection in a reusable way. The block Internal and the part it:Internal with AssociationBlock are used to demonstrate that here. Note also that the block Internal can also carry values such as itVal (which may have defaults), and it could itself have sub-structure.

Take some time to inspect how the Slots on the instances (including the Slots of the “link” instances typed by AssociationBlocks) not only carry specific values, but how those instances can then be used as defaults for properties within the other Blocks. For example, two different instances of Internal are assigned to AssociationBlock AB and CD respectively, with the values displayed under the initialValues (aka context-specific values) compartments in the IBDs.

An AssociationBlock can then also be used to type a Connector:

Visit also: SysMLv1.6: HOWTO: Use an AssociationBlock with a Connector and ConnectorProperty «connector» in Cameo Systems Modeler

Recommend NOT use AssociationBlocks with owned ends

So you might be asking: "What if you just let the AssociationBlock have owned ends? Then you could just use those in the IBD".

It turns out that Magic Cyber-Systems Engineer® (Cameo Systems Modeler®) does optionally offer to create an Association block with owned ends (as shown for AssociationBlock CD between blocks C and D, but it not a good idea to use that owned ends approach, because it violates some SysMLv1 constraints and modelling rules.

Yes, you can then indeed show c:C and d:D in the IBD for AssociationBlock CD, but if you connect them up you'll get a validation error in Cameo:

Invalid Connector! Connector owner is wrong or Connector ends specified in the model are changed!

In fact, you already get a validation warning on the properties c:Cand d:D:

Property metaclass that is typed by a block and is owned by an Association may not have a name and may not be defined as a navigable owned end of the association.
Because they break these SysMLv1 rules:

SysMLv1.7: 'SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. '
SysMLv1.7: 'SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.'
Relates to
Related notes
[] SysMLv1.6: HOWTO: Use an AssociationBlock with a Connector and ConnectorProperty «connector» in Cameo Systems Modeler
[FEATURE, TIP, TOOL] SysMLv1.6: MagicDraw/Cameo: HOWTO get a ConnectorProperty to show with a dashed line to its Connector in an IBD (or in the structure compartment of a Block symbol).
[WARNING]{INFORMATIVE} SysMLv1: The SysMLv1.6 ConnectorProperty was DEPRECATED in SysMLv1.7. see SysMLv1.7 formal/24-01-07: Annex C: Deprecated Elements and Migration: C.1.3 ConnectorProperty. Use AdjunctProperty with a connector as principal instead.
[CONSTRAINT, PROPOSAL, WISHLIST]{STRICT} Webel: SysML-1.7/SysMLv2: WISHLIST: Constraint: A BindingConnector used for pure proxying MUST NOT be typed by an AssociationBlock by definition, because the associated information can be mis-appropriated to undermine the proxy equality!
Related notes (backlinks)
Related snippets (extracts)
  [SysML-1.7] The Block stereotype extends Class, so it can be applied to any specialization of Class, including Association Classes. These are informally called "association blocks." An association block can own properties and connectors, like any other block.
  [SysML-1.7] Each instance of an association block can link together instances of the end classifiers of the association.
  [SysML-1.7] To refer to linked objects and values of an instance of an association block, it is necessary for the modeler to specify which (participant) properties of the association block identify the instances being linked at which end of the association.
  [SysML-1.7] The value of a participant property on an instance (link) of the association block is the value or object at the end of the link corresponding to this end of the association.
  [SysML-1.7] Participant properties can be the ends of connectors owned by an association block. The association block can be the type of multiple other connectors to reuse the same internal structure for all the connectors.
  [SysML-1.7] The keyword «participant» before a property name indicates the property is stereotyped by ParticipantProperty. They are always the same as the corresponding association end type.
  [SysML-1.7] SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block.
  [SysML-1.7] The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity ...
  [SysML-1.7] SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.
Visit also
Figure 2: Association block with internal structure and connector properties in SysML (and Figure 3)
Figure 9-14: Water Delivery association block with internal Plumbing connector
Figure 9-13: Internal structure of Plumbing association block
Figure 9-12: Plumbing association block
Visit also (backlinks)