What’s new in SysML 1.4 – Grouping of Elements
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:
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:
- 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:
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:
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).
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.
2 Responses
Thank you Tim, for this valuable SysML 1.4 beforehand information.
Regarding this Grouping of element concept, your description raised to me some questions.
As it is a comment based artifact, should we understand that must be present on the same diagram, all elements we want to add in the group ? Or would it be possible to define a Group element through different diagrams ? In Enterprise Architect tool I use, comment is not a visible artifact in the model browser, guess it is the same with other tools. Should we conclude that Group Element concept is reserved to diagrams ?
To be honest, so far I don’t see any real added value to the simple comment notation except that it structures the content of it.
I am wondering how could I use it. Hum, may be a silly idea, but in some way I could perhaps use it as an pragmatic alternative to Views/Viewpoint SysML concept that I find impossible to use with EA tool. A Group Element could link together all elements satisfying the same viewpoint. As a result the diagram would represent the view. But I guess that it would be difficult to generate a document which content would be structured by this Group
Br
Frederic
A comment can be linked to any element in the model. There is no need that they are in the same diagram. The comment element is part of the model and should be in listed in a model browser. Enterprise Architect seems to have a bad implementation of the comment model element.
You could use the element group to put any model element in a group for any reason. Of course that is also possible with a standard comment element. The element group adds the semantic of a group, some derived properties and tool vendors can easily provide convenience functions for the modeler to create groups or special views for groups.
Sorry for my late reply. Your comment was marked as spam by my wordpress system. You can contact me if you have further questions or comments. I’ll watch more on my spam folder.
BR, Tim