Porting Over From Rhapsody, Struggling with Usage/Definition Relationships

[BenEC]

Hi All,

I'm a relatively experienced IBM Rhapsody user of SysML for modelling systems and I am now presented with Sparx Enterprise Architect and cannot yet grasp the basic Usage/Definition relationships. Can anyone help? Example below. Note I am using version 15.2.1554

I have started by creating simple test diagrams using the familiar process of create BDD, add Blocks, define their composition relationships (create part properties), create an IBD for the top Block in the composition hierarchy, add the relevant parts to the IBD (note I have mulitple levels of block/part compositions and therefore have nested parts in my IBD) etc.

The trouble I start to encounter is around the final step in this list. There seem to be various ways to encourage EA to create duplicate parts breakdowns. For example, if when I create an IBD I use the check box in the features window to show a nested part on an IBD, EA creates a 'part of a part' in the model browser. So I end up with duplicate parts, i.e. the original part created using the composition relationship in the BDD, correctly sat under its owning block in the browser, then a duplicate 'part of a part' in the model browser window, sat under the part in which it is nested in the IBD. This is strange to me as 1. Rhapsody never allowed this and 2. I don't believe its in line with SysML 'rules' (for parts to own parts?). It also appears to cause future issues with not having a single source of 'truth' for a particular part, since its duplicated in various places within the model.

I hope this is understandable, I can provide more detail and images if necessary. I can only imagine im doing something fundamentally wrong, or my expectations are tainted by working with Rhapsody.

Note: I can get around the above problem simply by avoiding use of the check boxes in the Features window. However, I have the same (worse) problem when it comes to creating ports, they become duplicated in the model browser across the owning block but also appear separately as owned by the part (the latter appears to be wrong to me?). I can not yet avoid this issue.

Kind Regards,

Ben

[Guillaume]

Hi Ben,

I don't have any experience with Rhapsody. Having have multiple levels of composition links between blocks on the BDD (e.g. B1 to B1.1 & B1.2, B1.1 to B1.1.1 & B1.1.2), when you start the IBD for a given block e.g. B1, then you indeed choose the level of parts you need to connect e.g. you can stop with parts of B1.1 and B1.2 to connect them directly or via ports, or you could add parts of B1.1.1 and B.1.2.
As you probably noticed it, using the checkbox in the Features view will create additional parts under parts since they are specific to this IBD. In all cases, you can always go back to the linked block and the ports definition on the block is always sync with the part.
I don't see this as an issue with the single source of truth since a part "roleA:B1.1.1" under the B1 ibd analysis is different from the "rôleA:B1.1.1" under B1.1 should this block have its own ibd.

I've seen users of other SysML tools with similar differences in the way each tool behaves in specific needs.

[BenEC]

Hi Guillaume, thank you for the reply and your view on this topic. Are you essentially saying that the behaviour I am observing in EA i.e. EA creates 'parts of parts' when nesting parts in an IBD, is normal behaviour for EA?

The issue I have is with the single source of truth. In my model, in fact in all previous (IBM) models ive worked on in different contexts, partA:A1.1.1 should refer to the same model element in all IBD contexts.

Adding a practical example: if I have a 'System' Block which is composed of a 'Computer' Block, which is composed of a 'Circuit Board' Block, I want the Circuit Board to be represented by the same part in the browser under all circumstances. It becomes confusing if in some contexts the circuit board is sometimes represented by a part of the Computer and in others a part of a Computer which is a part of a System. And these 'two' circuit boards are respresented by different model elements in the browser.

Perhaps this is just how things work in the EA world, but it is new and jarring to me. Is there any way to avoid this or is it just a case of acceptance?

Another practical example: I want to know which diagrams my Circuit Board appears in, I get a different answer depending on which Part I interrogate in the model browser, since there are 2 'duplicate' parts representing the Circuit Board. I believe I have also observed scenarios in models built by others where the various duplicate parts are not synchronised in terms of which ports they own, I need to do further investigation as to how this happened but I suspect it is due to users deleting ports at the 'part of a part' level and not the part or Block level. This may be considered simple bad practice rather than an EA issue?

[Takeshi K]

Hi BenEC,

It is an interesting topic. I have not used Rhapsody, but I can understand BenEC's confusion. First, Parts under parts in the Browser are some kinds of 'instances' or 'usages' of the definition. So, the definitions are not duplicated. (But we cannot distinguish definition parts and instance (usage) parts in the Browser.)

When we change e.g. name of a part, the name of all parts including instances will be changed (synchronized). I think Rhapsody does not show these instances in the model browser, but EA does. SysML does not define how to show a model structure including usages in a modeling tool, so we cannot determine which is correct or wrong. If we use Rhapsody first, EA might seem odd, and vice versa.

I am afraid that you need to accept this is a manner of EA. I think this manner has not only cons but pros, for example, this is a nice structure for redefinition and overriding part values.

About your second practical example, yes, some current EA features cannot treat this SysML structure model well. We cannot know the correct placement in diagrams by using the built-in feature for these parts (and also ports). That is why I offer the ElementUsageEx add-in (paid add-in).

[BenEC]

Thank you to Takeshi K and Guillaume for your inputs. I will persevere with EAs implementation of SysML and see how I can adapt my modelling approach. I will report back if I discover any issues.