Grouping model elements (issue #13928)

1. Grouping model elements(issue #13928) (RTF online meeting, July 11)

2. Issue #13928 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 criteria. 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.

3. Element Group Purpose • A mechanism providing a way to specify groups of elements. A given element can be member of more than one group. Example of usage for element groups: • Elements that are grouped based on some common characteristic such as electrical vs. mechanical only parts • Elements that are grouped based on a property value such as risk (high risk elements vs. low or medium risk elements) • Elements that are grouped based on work package or delivery package (work sharing management) • A mechanism for element selection and extraction to support view generation

4. Element Group Requirements Mandatory: A group shall have a name Ability to group any elements (including unpackageables, element groups, unnamed ones deep nested) An element can belong to more than one Element Group (no ownership) Provide a description/rationale for membership in the group. The grouping mechanism shall not have side-effects (i.e. no semantic or syntactic impact) Establish a standard mechanism to determine which groups an element belongs to Establish a standard mechanism to determine what elements belongs to a group Nice to have: Notation with closed boundary around selected items as part of existing diagram. Notation available in any kind of diagrams (TBC) Ability to apply set-like operation to groups (union, intersection, difference, …) (TBC) Element groups as ordered set Element shall be aware of the groups they are members of (TBC)

5. Questions list • Is the membership computed or (arbitrary) stated?How to use a Boolean expression to describe a group?Do we need a default criterion?How to determine the context of the query? Its scope? • How to group deep-nested elements, if required? • Do we want a Venn-like notation (discuss pros & cons)? • Do we need to implement the algebra of sets? • Is it related to the concept of view? • What element kind can own a group? Relationships between member of a group and elements owned by the owner of the group? What are the constraints on ownership of the group? • Do we want transitivity? • Does this concept exist in other languages?

6. 1) Is the membership computed or (arbitrary) asserted? • Computed = Membership to the group resultsfrom the compliance with the group criteria. • Asserted = Membership to the group asserts the criteria applies. The group and its members are persistent in the model => This approach is selected. “Computed” groups are in the scope of the Views generation WG.

7. 2) How to group deep-nested elements, if required? (1/2) • Referring to deep-nested elements is not specific to the ElementGroup. This point shall be addressed through the Common reference path WG. Related issues: • #14447 “Ambiguous block hierarchy”: resolution voted in ballot4 • #18407 “Element path should be defined once…”: resolution voted in ballot4 • #18168 “How to refer to properties of an extension?”: no resolution so far • Proposal: • Use the nested reference/binding concept, as discussed by the Variant WG • Pb: this would implies modifying the owner of the element for the only purpose of grouping, which is against Req. #5 Element Group

8. 2) How to group deep-nested elements, if required? (2/2) • Deep-nested elements other than properties • Operations/Receptions, Actions, States, connector:Decision made with the whole RTF at Berlin meeting: to provide a generic reference mechanism based on comment • Note that the notation can avoid showing the path as a regular comment. A <<ElementGroup>> {name=MyGroup} b1:B b2:B B <<Path>> {path=A, b1,c} c:C <<Path>> {path=A, b2,c}

9. 3) Do we want a Venn-like notation? • Issue(s): • Clarify the meaning of overlapping boundaries (when no element in this area?). The notation needs to describe how the dashed line boxes can overlap • Pros: • User friendly • Implementation issue already resolved with activity regions (TBC) • Cons: • Tricky implementation for vendors? (TBC) • The «Venn-like» notation may be ambiguous when a group A is shown inside a group B since it doesn’t specify inclusion (i.e. subgroup) but membership (group A is member of group B). • Proposal: give up the Venn-like notation as a standard notation but vendors can create their own viewpoints based on this mechanism. This include for instance using color codes and/or some other indicator that an element is a member of a group, such as a key word with the name of the group

10. 4) Do we need to implement the algebra of sets? • Algebra includes: intersection, complement, union, … • Proposal: Since the groups are “stated” operation on sets could be applied on collection resulting from a “get members” query, e.g. using OCL => we don’t need to implement anything specific.

11. 5) Relations to the View/viewpoint concepts • Proposal:The concept of element group is not directly related to that of view. Referring to question #1, we can say that views ElementGroups can be used to select elements to be extracted for view generation. • Discussion: Tim: Basically a view could be a specialization of ElementGroup. However I would separate the concepts to simplify it. Proposal to answer question #5: The ElementGroup is not related to the View concept. Sandy: From slide 6, View represents a set of elements that result from some computation to some criteria (i.e., query), where-as an element group is a collection of elements that are asserted to be a member of a group. => they are disjoint concepts

12. 6) Which can own a group? • Note that the deletion semantics will applies. • Options: • Any element (i.e. like a comment) • Only Packages (i.e. is a kind of PackageableElement) • Something else? • Proposal:Option 1. • Discussion: Tim: I agree! Sandy: I see no obvious reason to restrict ownership, so I agree as well.

13. 7) Do we want transitivity? • Transitivity:A member of B AND B member of C => A member of C N.B.: Transitivity is inconsistent with the theory of sets (see next slide) • Options: • Transitive membership: this will have impact on the groups description which should take this transitivity into account. High risk of inconsistency. How to create groups of groups (cf. mandatory req. #2)? • Intransitive membership: the simplest solution. Can be seen as limited but there is a safe workaround using union operation. Note that “intransitive” means that transitivity is not implied. I does not means that it is not allowed. • Optional • Proposal:Intransitive membership • Discussion:Sandy: I think many users will intuitively assume the groups are transitive. Can you clarify that the proposal includes the workaround as a standard option. Yves: we could provide an explicit transitive closure for membership but it is easily done in OCL. I propose not adding this. Tim: At least transitivity should not be forbidden, i.e. a methodology could force transitivity and add the semantics for example with a specialized stereotype.

14. 8) Does a similar concept exit in other languages? • UML: • ActivityGroup: no ownership of members but can only group: activity nodes, activity edges and others activity groups • BPMN • Defines a similar concept of Group where the criterion is given by a link to a CategoryValue. However in BPMN this concept of group appears to be restricted to a diagram annotation since there no serializable relationships identifying the members of the groups.

15. Transitivity vs theory of sets S1 B1 S2 S2 B2 S2 is member of S1 (S2 Î S1) does not implies B2 is a member of S1 S2 is a subset of S1 (S2 Ì S1) implies B2 is member of S1

16. Notation Element4 • Do we specify a standard notation? • Proposal: to be decided once the implementation has been selected (call-out notation ?) • Standard tag: {/size=<n>}, {path=<p>} (on paths only) • Presentation options: do we specify presentation options? • Color? • Venn-like notation (area)? • Tabular notation • Others? • If yes, are the presentation options normative? • Proposal: Yes • Discussion Sandy.: I believe we should include one standard normative notation but allow for others. I like the one shown in this slide. Tim: Tricky is the notation for elements that are not allowed in the current diagram type, e.g. Action in a package diagram, or elements that are part of a notation like parameters. Yves: the tabular notation is the only one I see that can provide a complete view of any element group. Anyway, number of partial views of a group can be used if required. More advanced notation could be defined in a later ballot. {path=x, y, z} <<ElementGroup>> {name=GroupName} {/size=<N>} Group criterion <<path>> {path=x,y,z} Element1 Element3 Element2 Element5

17. Resolution proposals Baseline

18. Proposed BASELINE

19. Universal reference proposal • Implementation • Associationspath : NamedElement [*] {ordered} • Operations Path::getPathString():String {query} = self.path->iterate(e:NamedElement; acc:String=‘’ | if acc = ‘’ then e.name else acc.concat(‘, ‘).concat(e.name)) endif • Constraints: Only_one_reference [1] inv: self.base_class_comment.annotatedElement->size() =1 • Standard notation <<metaclass>> UML4SysML::Comment <<path>> {path=x,y,z} <<stereotype>> Path path* {ordered} <<metaclass>> UML4SysML::NamedElement {path=x, y, z} Element1 Element1 19

20. A - « Comment-based » proposal (1/2) • Implementation • Group name => ElementGroup::name • Criterion => Comment::body • Members => Comment::annotatedElement • /size => Comment::annotatedElement->size() • Operations ElementGroup::allGroups(e:Element):Set(ElementGroup){query, static} = ElementGroup.allInstances()->select(annotatedElement->includes(e)) • Constraints: (none) • Standard notation <<metaclass>> UML4SysML::Comment <<ElementGroup>> {name=“GroupName”} {/size=<N>} Group criterion <<stereotype>> ElementGroup name:String[1..1] Element4 Element3 Element1 Element2

21. A - « Comment-based » proposal (2/2) • Open issues/ limitations: • Has a name but is not a kind of NamedElement (just like a Connector has a type but is not a kind of TypedElement) • The “Venn-like” notation is already provided by the tools, but with another semantics • Members are not ordered • Tim: Several years ago I’ve proposed to make Comment a NamedElement. The issue was closed w/o change. A comment is not allowed to have semantics. It is only a useful information for the reader of the model. An ElementGroup has semantics. Therefore it could be problematic to use the Comment as a base class. • Yves: No such a constraint in the UML spec. The UML specification says that adding a Comment add no semantics to the owning element (i.e. no semantics side effects) but it says as well that: “[it] may represent information useful to the reader of the model => exactly what we are looking for. SysML already uses specializations of Comment (cf. <<Problem>> and <<Rationale>>) • Tim: From my point of view it is ok to use Comment. We must be prepared for a discussion about the semantics of a comment and elementgroup. • Sandy: I prefer comment as a solution if it can be made to work for the reasons stated on the next slide. I believe the anchors from a comment to an element have no semantic, since there is no relationship between the comment and the element that it is attached to. They are just a notation. We would need ask tools to be able to display the anchors on demand. For example, if I delete the element group from the diagram, and then add the element group back to the diagram, I would like the tool to restore the anchors without requiring the user to have to reenter them. I assume this would be done by querying the model to find the members of the elemennt group on this diagram.

22. Alternative Proposals

23. B - « Constraint-based » proposal (1/2) • Implementation • Group name => Constraint::name • Criterion => Constraint::specification • Members => Constraint::constrainedElement • Operations ElementGroup::allGroups(e:Element):Set(ElementGroup) {query, static} = ElementGroup.allInstances()->select(annotatedElement->includes(e)) • Constraints: (none) • Standard notation <<metaclass>> UML4SysML::Constraint <<ElementGroup>> GroupName {Group criterion} <<stereotype>> ElementGroup Element4 Element3 Element1 Element2

24. B - « Constraint-based » proposal (2/2) • Open issues / limitations: • May have semantics side-effect, depending on the Constraint::context (i.e. its owner) • A group cannot be a member of itself

25. C - « Package+Import » proposal <<metaclass>> UML4SysML::Package • Implementation • Group name => Package::name • Criterion => ElementGroup::criterion : Constraint • Members => Package::elementImport, if stereotyped by <<Member>> • Operations ElementGroup::allGroups(e:Element):Set(ElementGroup) {query, static} = ElementGroup.allInstances()->select(annotatedElement->includes(e)) ElementGroup::allMembers():Set(Element) {query} = self.elementImport->select(i| i.extension_Member->notEmpty())->importedElement->asSet() • Constraints: • ? (TBD) • Standard notation (none) • Open issues / limitations • Requires 2 stereotypes • Higher memory footprint • For PackageableElements only <<stereotype>> ElementGroup /member:PackageableElements[*] criterion 1..1 <<metaclass>> Constraint <<metaclass>> UML4SysML::ElementImport <<stereotype>> Member

26. D - « Package+constraint » proposal <<metaclass>> UML4SysML::Package • Implementation • Group name => Package::name • Criterion => ElementGroup::criterion : Constraint • Members => ElementGroup::criterion.constrainedElement • Operations ElementGroup::allGroups(e:Element):Set(ElementGroup) {query, static} = ElementGroup.allInstances()->select(annotatedElement->includes(e)) • Constraints: • ? (TBD) • Standard notation (none) • Open issues / limitations • Requires 2 stereotypes • Might remove the semantic side-effects since the ElementGroup is the context (TBC) <<stereotype>> ElementGroup /member:Elements[*] criterion 1..1 <<metaclass>> Constraint

27. E - « Package+dependency » proposal (1/2) • Implementation • Group name => Package::name • Criterion => criterion : String • Members => Package::clientDependency if stereotyped by <<Member>> • Operations ElementGroup::allGroups(e:Element):Set(ElementGroup) {query, static} = ElementGroup.allInstances()->select(annotatedElement->includes(e)) ElementGroup::allMembers():Set(Element) {query} = self.clientDependency->select(d| d.extension_Member->notEmpty())->suppplier->asSet() • Constraints: (none) • Standard notation(s) <<metaclass>> UML4SysML::Dependency <<stereotype>> Member <<metaclass>> UML4SysML::Package Element3 Element4 <<Member>> <<stereotype>> ElementGroup criterion:String[1] <<ElementGroup>> GroupName {criterion=“Group criterion”} <<Member>> Element1 <<Member>> <<Member>> Element2

28. E - « Dependency-based » proposal (2/2) • Open issues / limitations: • Adds 2 new stereotypes • Higher memory footprint • For NamedElements only • Sandy: Concern that package notation will be misconstrued to imply ownership

29. Archive

30. How to implement the algebra of sets? Assume: Group A | A.criteria = {is an electrical device} • Subset: • Group B | B.criteria = {is a battery} • B Ì A • Group C | C.criteria = {A.criteria AND is cheaper than 10$} • C Ì A • Intersection: • Group D | D.criteria = {is a safety related item} • Group E = A Ç D => E.criteria = {A.criteria AND D.criteria} • Complement: • Group F = ­A D => F.criteria = {A.criteria AND NOT D.criteria} • Union: • Group G = A È D => G.criteria = {A.criteria OR D.criteria}

31. UML concrete metaclass that are not NamedElements • Comment • PackageImport, ElementImport, PackageMerge • Slot (of an InstanceSpecification) • Generalization • ConnectorEnd • LinkEndCreationData, LinkEndDestructionData, QualifierValue • Clause • ExceptionHandler • ProtocolConformance (not in SysML yet) • Several metaclasses from the UML::Templates package (but not used in SysML so far)