How to make generalizations with the type "Class", not "Block"?

[FocusOnSysML]

Hi

I am using EA 13.5.1351 to work with a SysML 1.4 model. (I do have the option of upgrading to a later EA release if that would help with my issue.)
My short-form question is: How do I make generalizations to be of the "Class" type, instead of the "Block" type?

Some background:
I have a SysML model with an system architecture representation in a BDD (standard SysML blocks and part association connectors),
and I want to make a very similar model of an actual realization of that architecture, in a way that will not affect
the architecture model regardless of how the realization model diverges. (To clarify, all of this is in the same EA file.)

To do this, and to maintain traceability, I intend to keep the overall structure of the architecture, but rename
blocks to match this particular realization, and use generalization connectors between my realization and the
architecture where appropriate.

I have done exactly this before, and the name of the connected block from the architecture model showed up
in italics at the top of the realization block, and under the Properties->Related->Links dialog for the
realization block, the architecture block showed up with the type "Class" and connection "Generalization".
This is exactly how I want it to work.


But: When I tried to do it later, for new blocks, the block I wanted to define a generalization to ended
up in the same dialog with the type "Block" and connection "Generalization". The connection is there in the
model, but the "parent" block does not show up in italics in the BDD. As far as I can remember, I did it the
same way but got a different result.

I looked at the properties for both "Class generalization" and "Block generalization" blocks as I described above,
but could not find any other difference (nor could I change type "Type" manually).

Any idea why that is? How do I make a generalization end up as the type "Class" in the "child" block? At the
moment, my model appears inconsistent.

[Geert Bellekens]

A few image of the diagrams you are making would help greatly for anyone trying to understand your issue.

Geert

[FocusOnSysML]

A few image of the diagrams you are making would help greatly for anyone trying to understand your issue.

Yes, probably.

Here is the result that I can replicate, but do not want: https://imgur.com/a/2ghxf3a

And here is the result I cannot replicate, but want: https://imgur.com/a/i5VlmzA

Note the yellow highlights, and the class name in italics...

[qwerty]

Not firm with SysML but when you generalize from a «block» then this is not a class, is it? So WHY do you want a class to appear there?

q.

[Geert Bellekens]

I'm guessing the fact whether it's "Class" or "Block" is not really relevant.

If you remove the parent Class/Block from the diagram, it will show up in italics at the top of your child block.
(you might need to reload the diagram after removing the parent)

Geert

[FocusOnSysML]

I'm guessing the fact whether it's "Class" or "Block" is not really relevant.

If you remove the parent Class/Block from the diagram, it will show up in italics at the top of your child block.
(you might need to reload the diagram after removing the parent)

That worked, thanks. The type field was still "Block", not "Class", but I got the effect I was looking for, so I do not really care about the type field here.


(This kind of shows the dangers of assumptions...  I assumed the block/class type was the cause, because it was the only difference I could find.)

[FocusOnSysML]

Not firm with SysML but when you generalize from a «block» then this is not a class, is it? So WHY do you want a class to appear there?

Answer to my actual question in the reply above...

To answer your question of why, not that it is really relevant for the issue I had: Fundamentally, I want to be able to see directly from the block symbol itself which type of block it is (and this is now solved regardless of if it's a label or an explicit connector, but non-SysML-familiar persons might still find it inconsistent).

A way to put this more generally is: It is a modeling decision to visualize which blocks that have some common characteristics, which (as I wrote in the original post) was made by first defining an overall architecture, upon which one (out of possibly several) realization was based.

[qwerty]

That happens. Note that the notation with the italics top right is a pure Sparx invention. It's not an UML standard!

q.