Book a Demo

Author Topic: Incorrect SysML IBD Connector Behavior  (Read 7587 times)

rothnic

  • EA User
  • **
  • Posts: 91
  • Karma: +0/-0
    • View Profile
Incorrect SysML IBD Connector Behavior
« on: October 25, 2013, 11:32:32 am »
This is related to: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1374248326 . See it for example diagrams.

Issue:
EA doesn't interpret an IBD associated with a Block to be defining the internal structure of the Block. Instead the connectors created within the EA IBD, are treated as if they are defining instance/object specific connections. This is not within the intent of SysML.

Additionally, there is no way to use Association Blocks to type a connection between two Blocks, then show that detail within an IBD.

Rationale:
SysML Distilled Section 4.1:
Quote
An IBD conveys how the parts of a block must be assembled to create a valid instance of the block. It also shows how an instance of that block must be connected to external entities (reference properties) to create a valid instance of the system as a whole.

A Practical Guide to SysML 2nd Edition:
Quote
The whole end or composite (block) is designated by the diagram frame on the internal block diagram with the block name in the diagram header. It provides the context for all the diagram elements on the diagram.

So, since the IBD frame represents the boundary of the block, and the elements in the diagram represent the internal structure of that block, any time that block is used within another higher level context, the structure and connections internal to it are still valid.

In EA, when the Block is used in another context the connections no longer exist when the part properties are added to the higher level IBD. It makes no sense that the defined structure of the Block changes from one context to another (at least from a systems engineering perspective). It seems to go against the reusability principles that SysML was designed to support.


Impact:
I did more research into this since it is a significant issue towards our modeling at work where we are considering expanding our modeling to include the network engineers to incorporate network connectivity. I believe this is a show-stopper type issue for us.

We develop our system architecture at various levels starting from a common System Architecture (Domain-like) Context. If we decide that we want to show a high detail view for one building within that context, which contains 2 or more of these reusable deployment nodes, then internal detail of the deployment nodes would have to be manually recreated. The other option would be for them to reference the deployment node ibd when they want that specific detail, but this does not allow us to seamlessly replace a traditional artifact as it exists today. This severely hampers the benefit of developing a system model.

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Re: Incorrect SysML IBD Connector Behavior
« Reply #1 on: October 29, 2013, 09:39:52 am »
While I understand where you are coming from, I disagree.

EA showing relationships between a child element not currently shown as coming from the parent is deceptive at best, wrong at worst (with the possible exception of dependency)

I don't see why you believe that no showing relationships to children when the children aren't showing means that EA is treating it as an instance. EA is allowing you to define the internal structure of the block, you're defining ports/properties. That's what they are.

rothnic

  • EA User
  • **
  • Posts: 91
  • Karma: +0/-0
    • View Profile
Re: Incorrect SysML IBD Connector Behavior
« Reply #2 on: October 30, 2013, 01:28:21 am »
Quote
While I understand where you are coming from, I disagree.

EA showing relationships between a child element not currently shown as coming from the parent is deceptive at best, wrong at worst (with the possible exception of dependency)

I don't see why you believe that no showing relationships to children when the children aren't showing means that EA is treating it as an instance. EA is allowing you to define the internal structure of the block, you're defining ports/properties. That's what they are.

I'm not sure what you mean by "not currently shown as coming from the parent". I don't have an issue with EA not showing a relationship. I think that when you define the connections between parts on an IBD, in the context of a block, that those connections should persist in whatever other context that block is used.

So if block1.block2.port1 has a connection to block1.block3.port1, then if I show the levels of structural elements required the connections should also exist within the context of block0. So block0.block1.block2.port1 would have a connection to block0.block1.block3.port1 without having to recreate the connection.

Take the EA example model. It contains a portable audio player sysml model. It has an IBD that defines the connections internal to the portable audio player. It doesn't matter whether I put the portable audio player in my pocket, my house, my car, whatever, the internal connections still are the same in any other context.

The behavior I describe I have confirmed to exist in both Rhapsody and Magicdraw. I'd definitely suggest taking a look at them for comparison.