1

Grouping model elements(issue #13928)

(RTF online meeting, July 11)

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

2

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:

1. A group shall have a name

2. Ability to group any elements (including unpackageables, element groups, unnamed ones

deep nested)

3. An element can belong to more than one Element Group (no ownership)

4. Provide a description/rationale for membership in the group.

5. The grouping mechanism shall not have side-effects (i.e. no semantic or syntactic impact)

6. Establish a standard mechanism to determine which groups an element belongs to

7. Establish a standard mechanism to determine what elements belongs to a group

Nice to have:

1. Notation with closed boundary around selected items as part of existing diagram.

2. Notation available in any kind of diagrams (TBC)

3. Ability to apply set-like operation to groups (union, intersection, difference, …) (TBC)

4. Element groups as ordered set

5. Element shall be aware of the groups they are members of (TBC)

5

Questions list1. 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?

2. How to group deep-nested elements, if required?

3. Do we want a Venn-like notation (discuss pros & cons)?

4. Do we need to implement the algebra of sets?

5. Is it related to the concept of view?

6. 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?

7. Do we want transitivity?

8. Does this concept exist in other languages?

1) Is the membership computed or (arbitrary) asserted?

Computed = Membership to the group results from 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.

6

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

7

Element Group

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.

8

A

b1:B

B

c:C

<<ElementGroup>>{name=MyGroup}

b2:B

<<Path>>{path=A, b1,c}

<<Path>>{path=A, b2,c}

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

9

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.

10

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

11

6) Which can own a group?

Note that the deletion semantics will applies. Options:

1. Any element (i.e. like a comment)

2. Only Packages (i.e. is a kind of PackageableElement)

3. Something else?

Proposal:Option 1.

Discussion:Tim: I agree!

Sandy: I see no obvious reason to restrict ownership, so I agree as well.

12

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.

13

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.

14

15

S1B1

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

S2

Transitivity vs theory of sets

Notation 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

DiscussionSandy.: 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.

16

<<ElementGroup>>{name=GroupName}

{/size=<N>}

Group criterion

Element1

Element2

Element3

Element4

{path=x, y, z}

Element5

<<path>>{path=x,y,z}

Resolution proposals

17

OptionsRequirements

A: Comment-based

B: Constraint-based

C: Package-based

D: “Pointer”-based

E: Dependency-based

MR1 having a name Yes Yes Yes Yes Yes

MR2Group any element

Yes Yes No No No

MR3 no ownership Yes Yes Yes Yes Yes

MR4 criterion/description

Yes Yes Yes Yes Yes

MR5 no side effect Yes No(adds constraints)

Yes No Yes

MR6 get members Yes Yes Yes Yes Yes

MR7 get groups Yes Yes Yes Yes Yes

NR1 Venn-like notation -- -- -- -- --

NR2 notation for any diagrams (TBC)

Yes Yes No No No

NR3 operations on sets (TBC)

N/A N/A N/A N/A N/A

NR4 ordered members No Yes No Yes No

NR5 membership navigable (TBC)

Yes Yes Yes Yes Yes

Baseline

PROPOSED BASELINE

18

Universal reference proposal

Implementation– Associations

path : 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

19

<<metaclass>>

UML4SysML::Comment

<<stereotype>>

Path

<<metaclass>>

UML4SysML::NamedElement

path* {ordered}

Element1{path=x, y, z}

Element1<<path>>{path=x,y,z}

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

20

<<metaclass>>

UML4SysML::Comment

<<stereotype>>

ElementGroup

name:String[1..1]

<<ElementGroup>>{name=“GroupName”}

{/size=<N>}

Group criterion

Element1

Element2

Element3

Element4

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.

21

ALTERNATIVE PROPOSALS

22

B - « Constraint-based » proposal (1/2)

Implementation– Group name => Constraint::name– Criterion => Constraint::specification – Members => Constraint::constrainedElement– OperationsElementGroup::allGroups(e:Element):Set(ElementGroup) {query, static} =

ElementGroup.allInstances()->select(annotatedElement->includes(e))

– Constraints:(none)

Standard notation

23

<<metaclass>>

UML4SysML::Constraint

<<stereotype>>

ElementGroup

<<ElementGroup>>GroupName

{Group criterion}

Element1

Element2

Element3

Element4

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

24

C - « Package+Import » proposal

Implementation– Group name => Package::name– Criterion => ElementGroup::criterion : Constraint– Members => Package::elementImport, if stereotyped by <<Member>>– OperationsElementGroup::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

25

<<metaclass>>

UML4SysML::ElementImport

<<stereotype>>

Member

<<metaclass>>

UML4SysML::Package

<<stereotype>>

ElementGroup

<<metaclass>>

Constraint

1..1criterion

/member:PackageableElements[*]

D - « Package+constraint » proposal

Implementation– Group name => Package::name– Criterion => ElementGroup::criterion : Constraint– Members => ElementGroup::criterion.constrainedElement– OperationsElementGroup::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)

26

<<metaclass>>

UML4SysML::Package

<<metaclass>>

Constraint

1..1criterion

<<stereotype>>

ElementGroup

/member:Elements[*]

Implementation– Group name => Package::name– Criterion => criterion : String– Members => Package::clientDependency if stereotyped by <<Member>>– OperationsElementGroup::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)

E - « Package+dependency » proposal (1/2)

27

<<metaclass>>

UML4SysML::Package

<<metaclass>>

UML4SysML::Dependency

<<stereotype>>

Member

criterion:String[1]

<<stereotype>>

ElementGroup

<<ElementGroup>>GroupName

{criterion=“Group criterion”}Element1

Element2

Element3

Element4<<Member>>

<<Member>><<Member>>

<<Member>>

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

28

ARCHIVE

29

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}

30

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)

31