Grouping model elements issue 13928
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Grouping model elements (issue #13928) PowerPoint PPT Presentation


  • 36 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Grouping model elements (issue #13928)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Grouping model elements issue 13928

Grouping model elements(issue #13928)

(RTF online meeting, July 11)


Issue 13928

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.


Element group purpose

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


Element group requirements

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)


Questions list

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?


1 is the membership computed or arbitrary asserted

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.


2 how to group deep nested elements if required 1 2

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


2 how to group deep nested elements if required 2 2

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}


3 do we want a venn like notation

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


4 do we need to implement the algebra of sets

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.


5 relations to the view viewpoint concepts

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


6 which can own a group

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.


7 do we want transitivity

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.


8 does a similar concept exit in other languages

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.


Transitivity vs theory of sets

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


Notation

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


Resolution proposals

Resolution proposals

Baseline


Proposed baseline

Proposed BASELINE


Universal reference proposal

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


A comment based proposal 1 2

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


A comment based proposal 2 2

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.


Alternative proposals

Alternative Proposals


B constraint based proposal 1 2

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


B constraint based proposal 2 2

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


C package import proposal

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


D package constraint proposal

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


E package dependency proposal 1 2

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


E dependency based proposal 2 2

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


Archive

Archive


How to implement the algebra of sets

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}


Uml concrete metaclass that are not namedelements

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)


  • Login