Generalisation does not work as intended in SYSML

[danieldd0]

Using SYSML a generalisation to a block does not work as intened:

Expected Behaviour :
The father block has a port, expectation is that the child Block will show up the port as well after generalisation (and of course any depth of itteration)

Faulty Behavior:
The child block does not get any port from father visible

Tests i did:
It does not make an difference if the father block has the port before or after adding the generalisation.
Checked also older version of modelio (5.0 / 5.3) no difference. => generalisation is just a arrow on the sketch.
Also no effect on the two different generalisations....

Side effect noted:
If a Block gets a port on different diagram it will not show on the others unless you move manually the port from the left tree on the diagramm (anywhere) then it "falls" to the owners block. (sometimes this behavior is ok)

Solving suggestions:
1.) repair the generalisation to make them generalize all properties comming from the source.
2.) Probably make an (context) menue to the block to control when port updates shall appear and when not..

[etiennebrosse]

Hi,

I am not sure that you described the expected UML/SysML generalization behaviour, and I will try to explain my point of view.

Let's say that you are defining an object A and its child an object B (so you have a generalization from A to B).
For me, you do not want to see all inherited properties on B (including ports, attributes, operations, associations, behaviour, etc. coming from A). When I am modelling B, I just want to focus on B definition only, and I do not want to be polluted by all the parent definition. It will be confusing, and I will not be able to know from where a property comes from.

But when I instantiate (use) B, in this case, I do want to see or access to all B properties (from its proper definition or coming from its generalizations).

So in SysML, when I am modeling Block Definition Diagram (BDD), I just only want to see B properties (not those coming from A) to focus on B definition.
But when I am modeling an Internal Block Diagram (IBD) in which I instantiate B, I do want to be able to see all B properties (including ports) even those coming from A, to be able to connect them for example.

Does it clarify my point?
BTW are you aware of any SysML tool implementing your expectation? I would be curious to test it.

[danieldd0]

Etienne,
I work since years with IBM Rhapsody 8.2.x / 8.3.x / 8.4.x / 9.0.x in combination with EWM, Doors NG etc... at work.
Please do not get upset with long text and my comments here... ;)

I'm Senior Expert for System Architectures in the company and Yes Rhapsody implements the generalization exact like that.

A Object (A) which is specialized down to B(the child) will cause the child ALL properties inherited as described - including its ports.

Of course you can hide the objects inherited or even overwrite (polymorphism) as well. Sometimes this is a natural need.

It has nothing to do with "pollution" it has to do what you generate with the generalization. At least you should let the user decide if the want or not. In a C++ Class also the children see the properties and Methods of the base class - here we don't call that pollution.

Also a Tool like Modelio should implement basics of SYSML correct and not patronize the user.

I was on the search for suitable replacement of Rhapsody and this first simple test failed for Modelio.

Of course i can add the ports manually on the child's (an in my case the child has child's as well). This manual action will cost me extra time and a loss of accuracy. Because a property of the Father (in A) must go straight through because the dependency otherwise the generalization rule is broken. I had the hope that there is a difference in Modelio from drawing diagrams with DIA or VISIO.

Unfortunately i don't have my screenshots at hand (made in RPY)

Its Like that :

RUT (a Router) <--RUT X11 (Family)
RUT (Same as above) <-- RUT950 (Family)

RUT X11<-- RUT_TRUCK
RUT950<-- RUT_CABIN
RUT950<-- RUT_TRAILER

CONTEXT composes RUT_TRUCK,RUT_CABIN,RUT_TRAILER (on a BDD) and in IBD i can link the Parts of RUT_TRUCK,RUT_CABIN,RUT_TRAILER

Benefit of that:
1.) i define a RUT has in general a Power Supply => so all get a power supply and indeed they are of same type. No changes need on the childrens, but deployed data at once on all devices.
Same the 4 Ethernetports (all have them) Plus 2 WIFIs
2.) ON X11 Router additiona GPS and Bluetooth are present
3.) ON RUT950's (all of them) there is additional GPIO Port.

So it's a mixture of generalizations to a certain level and then do directed compositions. Why ? - I want to express the chain of technical properties correct a generic definition of a RUT, or X11 or 950 family is not a physical device you can have, a named Router (RUT_TRUCK) is one and has a "path" the RUT(root object) at all. This technique speed up maintenance extreme. Of course it as drawbacks because you really need to model careful.

Thanks for understanding that windy mind of me.....

Greets Daniel

[etiennebrosse]

Hi Daniel,

First of all, thanks for all, we will try to see what Rhapsody is capable of and what we can learn from it.

Now let's try to summarize your point, Modelio implements SysML generalisation correctly (your are able to create it, modify it, etc. ) but you expect, from the tool, particular facilities, features, shortcuts, which are not part of SysML specification but made System Architect life easier or more productive. Am I right?

The good news is that possible under Modelio!!! And you can ask more like creating a IBD from a composition set for example.
I attached two simple diagrams to show you what is possible within Modelio with, maybe, less click than you think.

Of course, Modelio can be better.
That's why we will happy to have more constructive feedback.

Best Regards,
Etienne

[danieldd0]

getting closer,
even Enterprise architect can do that (please take a look ; https://sparxsystems.com/enterprise_architect_user_guide/16.0/guide_books/other_block_relationships.html )

"One of the useful language mechanisms that results from Generalization is for the specialized elements to inherit the structural and behavioral features from the generalized element. So far in the example diagrams the engineer has chosen not to display these inherited features, but they can be set to be displayed using the compartments sections of the element's Property sheet."

So it's definitly part of the SYSML and not a optional ;)

Greets Daniel

[etiennebrosse]

That's definetly a nice feature but its comes from a tool documentation and not from any standard specification like UML or SysML, am I right?
If Yes, you described a wonderful Enterprise Architect fonctionality not the SysML or UML Generalisation...
Here are my references:
https://www.omg.org/spec/UML/2.5.1/About-UML/
https://www.omg.org/spec/SysML/1.7/Beta1

[feuertier]

I think I see what @danieldd0 is getting at. when I use a generalization relationship between two blocks, I don't see that the specialized block inherits any properties or features of the general block. Per the UML specification, I would expect at least that the inheritedMembers attribute is synchronized:

The set of members that are inherited is called the _inheritedMembers_. Unless specified differently for a particular kind of Classifier, the _inheritedMembers_ are members that do not have private visibility. --UML 2.5.1, pg 100.

I would also expect to see an attribute indicating the generalizations:
Given a Classifier, the transitive closure of its general Classifiers is often called its generalizations -- same page

Right now, I see no indication in the attributes that anything is inherited. @etiennebrosse , are you suggesting that this is something the modeler should maintain manually? It's definitely nice if Modelio could automatically provide the features and properties to the specialized elements, and indicate (with the ^) that they are inherited properties and features. The only way I see to indicate that something is inherited is to manually enter the ^ in the name of the element.