SDMN — Connector types rationalisation possible?

See previous issues.

If CompositionConnector and ContainmentConnector were collapsed to just one type, and DataAssociation was modelled as a complex N:N relationship, and ReferenceConnector considered the equivalent of a UML association (call it AssociationConnector), then we would just have:

• CompositionConnector
• AssociationConnector

as descendants of Connector.

This simplification would imply that the subtyping approach could be removed altogether, and Connector be a concrete type with a boolean such as isComposition to indicate that it is a Composition; if False, it is an association.

The class currently called DataAssociation could be modelled as a new class Mapping, probably just inheriting from SCEElement, with multiple source items and one target i.e. an N:1 mapping, plus a transformation function taking the N source items as arguments.

No changes to the Connectors for SDMN

Based on discussion from other issues, we will be retaining the composition and container connectors (with better documentation) and will retain the DataAssociation. Thus, this issue can be closed.