Was ist neu in der SysML 1.4 – Modellelemente gruppieren

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Dieser Blogbeitrag wurde zuerst in meinem englischsprachigen MBSE-Blog veröffentlicht. Daher ist dieser Beitrag in englischer Sprache.

The second part of the blogpost series about the changes in SysML 1.4 presents the new concept to group elements.

The use case is simple: Create a group of model elements:

[caption id="attachment_820" align="aligncenter" width="300"] SysML 1.4 ElementGroup Use cases (click to enlarge)[/caption]

Okay, on the second thought there are some more: Update a group and Delete a group. And I’m sure that you’ll find some more use cases on the third thought. It also depends on your personal definition of a use case. I won’t start that discussion here.

Surprisingly it is not possible to simply group model elements with SysML until version 1.4 or with UML. The first pick would probably be the package. Looks like a perfect grouping element. However there is another important requirement for our grouping element: It must not add any semantics to the members of the group. A package adds a very strong semantic to the members. It is a namespace.

The requirement Semantic free contains several more requirements on the next level of detail:

[caption id="attachment_821" align="aligncenter" width="300"] SysML 1.4 ElementGroup Requirements (click to enlarge)[/caption]

• A model element could member of any number of groups (#2.1). That – for instance – is not possible with a package as a grouping element. A model element could only be a member of one package (namespace).
• The group may contain arbitrary elements (#2.3). Again that is not possible for packages that could only contain packageable elements like blocks or use cases, but not ports or properties.
• The group does not change the members (#2.2, #2.4), i.e. it does not change any property of the elements or create relationships between them.

SysML 1.4 provides the new model element ElementGroup that satisfies the given requirements:

[caption id="attachment_823" align="aligncenter" width="300"] SysML 1.4 ElementGroup Stereotype (click to enlarge)[/caption]

Since SysML is a profile of UML it is not possible to create a new model element out of the scratch. You must define a stereotype that extends a given UML model element without contradicting the semantics of the UML element. The challenge was that UML has no semantic-free grouping element. The solution is the comment. ElementGroup is a stereotype that extends the UML element Comment.

A Comment is nothing more than a text – the comment – and a set of annotated arbitrary model elements. It does not have any semantics and does not any semantics to the model elements. It is just a comment like a sticky yellow note attached to a document. The comment is shown in a note symbol. The annotated element could be shown by dashed lines between the comment symbol and the element. The following figure shows a example of a comment:

[caption id="attachment_826" align="aligncenter" width="300"] SysML 1.4 Comment example (click to enlarge)[/caption]

The lower left annotated element is not the block, but the operation probeInput().

A ElementGroup adds a name property to the comment to give the group a name. The text of the comment element is used to describe the criterion that an element is a member of the group. The criterion is also a derived property of the element group, i.e. it is derived from the body text of the comment. Another derived property is the size of the group. The members of the groups are also a derived property. They are derived from the annotated element property of the comment. Since the set of annotated elements allows no order, the ElementGroup has an additional optional property to define a order of the group members.

The notation is the same as the comment, stereotype and tagged value notation. The following diagram shows the element group Revenue with 3 members that are in particular relevant for the revenue of the product vendor of the forest fire detection system (FFDS).

[caption id="attachment_827" align="aligncenter" width="300"] SysML 1.4 ElementGroup example (click to enlarge)[/caption]

The big disadvantage of using the Comment as the base element for the ElementGroup is that it is not possible that a ElementGroup is a participant in a relationship. For instance you cannot model a trace relationship from or to an element group or a refine relationship from our Revenue element group to a appropriate requirement. There is no simple solution for this issue except a new first class model element. For that we must wait for UML 3.0.

Now you know the new SysML ElementGroup. Would you use it? I’m interested in your applications of the ElementGroup. I hope there are not so many, but I’m also in your issues with the ElementGroup. Please let me know. Write a public comment to this blogpost or send me a private note.