SysML 1.2 RTF Avatar
  1. OMG Issue

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

  • Key: SYSML12-23
  • Legacy Issue Number: 13928
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    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.

  • Reported: SysML 1.1 — Sat, 9 May 2009 04:00 GMT
  • Disposition: Resolved — SysML 1.2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT