This video covers an area where new users of SysML often struggle, i.e. understanding the differences between Blocks and Parts, and the role played by the diagram frame of an internal block diagram. Fundamentally, in SysML the frame of the ibd is normally a block and the ibd represents an assembly of parts owned by that block. Within my old friend Rhapsody, unlike Cameo, there's not a context selection method on a diagram that defines the context of its frame. The context of the diagram is determined rather by the ownership of the diagram. This means that diagram ownership is critical. This is why I normally recommend that new users are careful to create internal block diagrams as children of blocks rather than at package level. Related to this is that if you drag an element on to an internal block diagram and it is out of context, then it will be displayed with a dashed line, something new users often struggle to understand. This is because it's not owned by the element that the frame represents. This is video #95 of my Rhapsody tips and tricks video channel that I started 6 years ago.
So what we have here is essentially an internal structure with parts. The block definition diagram defines the relationship between blocks but blocks are types of things and parts are named usages of those types, usually within the context of another block.
If I create an internal block diagram where I want to show these parts, then normally the frame of that diagram would represent the element, i.e. Block, that owns those parts. So, if I create an internal block diagram at package level, then we can see in the frame that this is a package diagram of a package called default.
I can put the parts in it and you can see that the dotted notation will tell me where in its nested structure it is.
But the frame here, doesn't represent system A. It doesn't represent anything that's a classifier. Let me just add a port on the boundary of System A here, and another port with a connector.
Now, if I create an internal block diagram underneath the System A block then the frame tells us that this is an internal block diagram of a block called system A.
That means that the frame represents the block System A. This means that you can show a port of System A on the frame, and the things inside that frame then would normally represent parts that are owned by System A.
So the Block Definition Diagram is a diagram that shows relationships between Blocks and blocks are types of things.
Let's see what happens if I have a nested hierarchy that goes deeper. Maybe component C is a child part typed by Subsystem A and component D has a child part typed by subsystem B.
If I put part D here on the internal block diagram, then you can see that it's dashed because part D is not directly owned by subsystem A, rather part D is owned by subsystem B.
So, if I drag something on to an internal block diagram, for example a Block, then it's dashed because it's not owned by the element that the frame of the ibd is representing.
There's two fundamental things here really. One is that blocks are types of things and that parts are named usages of blocks, usually within the context of another block.
In Rhapsody, there's no context setting on the internal block diagram. The internal block diagram frame is determined by the ownership of the diagram. So the internal block diagram here is owned by system A which means that its frame will represent system A. This is why I always create an internal block diagram underneath a block, rather than at package level (unless you have parts which are global - which I tend to avoid anyway).