Composition
A Composition is a stronger specialization of an AssociationRelation, i.e., it is a part-of relationship. To realize this binding strength, Compositions follow particular principles:
A Composition starts from a Node "A" and targets a Node "B". The composition relation is unidirectional and owned by Node "A". It means "B's" can be part of "A".
In this case, "A" and "B" must be part of the same Model.
Composition loops are forbidden and invalidate the Model.
Compositions can be private or public. The instance objects of a public composite element are visible from outside the resulting Instance. Consequently, they can become a concrete target for AssociationRelations. If this is not desired, i.e., the composite element should exclusively exist within its "wrapping" element, then the Composition must be private. Note that Nodes in Compositions can have Compositions and so on...: The privacy acts in this case like a filter and is parsed starting from the root of an Instance. So the first "private" Compositions makes all subsequent ones private as well.
Because a Node can occur in different Compositions, the Composition has a role that serves as named handle of the composite instances (just like a relation name).
See also
Constructors
Properties
Technical database (JPA) identifier used for relation joins. The dataID is system specific and not exported to XML. It must not be used to identify elements in distributed use-cases. It should not be used to identify elements from outside the service. All model elements provide other suitable identifiers to be used.
Boolean value if the Composition is public or private. See the Composition class documentation for more information. Public Composition types and their instances are listed in the Fragments Header.