SYSML12 — Section: 7/Table 7.1, 7,3,1, 7.3.2, 7.4, -- partition construct

Partition Construct. It is often convenient to partition model elements without imposing ownership or containment constraints. In particular, this partitioning construct would enable any set of named elements to be grouped based on some set of partitioning crtieria. The group of elements would be named. The could be used to name a group of classifiers, properties, instances, or any other model elements or combination of model elements without modifying where they fit within an ownership or containment hierarchy. A possible approach would be to extend this construct, which will be referred to as a Partition, from a Named Element. The Named Element could represent the client for the series of model elements that it wishes to partition. The partition could own a constraint that specifies the criteria for an element to be a client of the partition. Various notational options could be used to show the group of elements in the partition. It could be a rectangle with the stereotype <<partition> with the model elements enclosed, or it could leverage the SysML callout notation as an example.

It is convenient to be able to group model elements based on modeler-defined
criteria. Simple examples are groups of elements that may be associated with a
particular release, or with a legacy design. Unfortunately, there is no metaclass in
UML that supports such a concept of collection. The word “group” is preferred to
“partition” in the resolution since the concept of partition would suggest that
participations in those groups are mutually exclusive while this limitation is not
desirable.
UML packages are a means to organize model elements. They have the convenient
semantics except that they imply ownership, whereas it is requested to have no
limitation on the number of groups an element can belong to. Instead, this proposal
extends the UML::Comment metaclass for that purpose. The provided mechanism is
intended to specify groups of model artifacts and should not be extrapolated for
representing groups of runtime elements.
A Comment may be owned by any kind of element and has no semantic side-effect.
It can designate grouped elements using its annotatedElement association, and the
criterion applicable to any element of the group can be defined via its body property. Annotated elements are not owned by the Comment. Thus, built on a
UML::Comment, an ElementGroup does not own its members. There is no limitation
on the number of Comments that can annotate a given element. Thus, any element
can participate in an unlimited number of groups.
Adding an element to a group does not modify it. Then, an element cannot hold any
information about the groups it is member of. Instead a static query
allGroups(e:Element) is provided for that purpose. It returns the set of
ElementGroups a given element is member of.
Note that a group may have some groups among its elements (annotated elements
may be any kind of element, including UML::Comment).
The members of an ElementGroup may optionally be ordered.
The resolution to issue #18653 provides through the concepts of “View and
Viewpoint” the means to compute collections of element as the result of an arbitrary
query applied to a model or to a part of a model. An element group is distinct from
view and viewpoint in that a) element groups provide a means to create persistent
collections of elements, and b) membership of an ElementGroup is asserted rather
than computed. The ElementGroup::member property is derived from the collection
of annotated element. The way this property is derived cannot be modified by the
modeler. Thus, View/Viewpoints and ElementGroup are disjoint concepts. However,
View/Viewpoints can leverage ElementGroup for constructing views.
Since an element group is expected to have a name, and the proposed base class
(i.e., comment) is not a named element, an ElementGroup::name property is added
to the ElementGroup stereotype.