Tuesday 16 March 2021

New IBM Engineering Lifecycle Management (ELM) User Group page

IBM have set a new User Group page for Engineering Lifecycle Management (aka Jazz Continuous Engineering platform). They're saying this will be the central point of all IBM ELM activities, hence you may want to check it out:

https://ibm.biz/elmusergroup

There will be features allowing IBM to communicate to the user groups and register to events.

It is open to the public. IBM encourages partners and clients to join. 

Academia is also welcome.

Tuesday 9 March 2021

IBM Engineering Rhapsody Tip #95 - Why diagram ownership is important for Internal Block Diagrams

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.


Here's the transcript:

Hi, in this short video I'm going to show why it's important to have Internal Block Diagrams owned by Blocks rather than being children of packages.

So, I'll start by creating a quick SysML project and I'll create a classic Block Definition Diagram with a structure. I'll create a System A which has a Subsystem B and Subsystem A. The way I create a structure is with Directed Compositions. I'll create a part A and a part B. 


By default, Rhapsody will name the part with the word "its" followed by the name of the Block but I can name it what I like. 


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.

... although Rhapsody does allow you to also have parts which are global, i.e. owned by a package.


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.



Of course, I could put the part into the System A block here and that removes the dotted notation.


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.

The internal block diagram is a diagram that shows me the relationships between parts which are usages and the frame represents the block that owns these parts.


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.


If I move it into the correct context then it's boundary is no longer dashed.


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.

Internal block diagrams are diagrams of the internal structure of a block, so things that are not in that internal structure are going to have dashed lines on them.


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. 

Secondly, an internal block diagram is a diagram of those usages and how they're connected within the context of a a block, and that the frame of the ibd normally represents that owning 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).

I hope that helps. Don't forget that I have a business that can deliver customised training in Rhapsody that suits your needs and your budget, so feel free to email me if you want more information on ways of accelerating your adoption of successful model-based systems engineering with Rhapsody.