This is the transcript:
Hi, in this 5th in my series of videos about the different diagrams in the Unified and the Systems Modeling Languages, I thought I’d cover Block Definition Diagrams in SysML.
This is really a follow on from my second video in the series which was on UML Class diagrams. This is because BDDs in SysML do for systems engineer’s what class diagrams in UML do for software engineers. They both involve the classification of structural elements and the establishment of relationships between them.
The key difference is that SysML uses a stereotyped class called a Block, and of course, Blocks conceptually will often be non-coding things such as organisational structures, physical elements, or systems, subsystems & components.
Each block defines a collection of features to describe a system or other element of interest.
As well as showing Block's features, Block Definition Diagrams, or BDDs for short, allow us to define and show relationships between blocks such as associations, compositions, aggregations, generalizations, and dependencies.
Although Class diagrams share the same relationships, it’s very likely that you would end up using different types of relationship when you build a SysML model than you might with a class diagram in UML.
For example, associations which are central to defining communication paths between collaborating objects in an OO design, are not something you’d use very often in a SysML BDD. Their predominance is replaced instead by one of composition relationships to enable hierarchical decomposition of types.
The composition relationship can be read as a “has a” relationship and is denoted with a filled in diamond.
Systems engineering is really about building highly cohesive and loosely decoupled components. As such BDDs tend to look like trees of Blocks and other classifiers.
This diagram is telling me that the Automotive Domain is an assembly of a system than comprises among other things of a Block representing a Hybrid Sports Utility Vehicle and a Block representing the Environment.
Furthermore, the Environment is decomposed into blocks representing Weather, a Road and an External Object.
The Hybrid SUV is further decomposed into parts typed by Blocks that represent subsystems of a vehicle such as the Body Subsystem and the Brake Subsystem.
I could show these by dragging on the Blocks from the browser, and Rhapsody would auto-populate existing relations on the diagram when I do this.
As with class diagrams, it’s the modelers choice what the scope of the BDD is. In this instance the BDD is nested under the Hybrid SUV and hence the frame tells us that the scope is the Package called the HSUVStructure.
You could also nest BDDs under a Block, if you want and this would be represented in the diagram frame. Diagram frames are a mandated part of SysML and convey the scope and context of the diagram. This is a bdd of a Block called the Hybrid SUV and the diagram is called the Hybrid SUV Breakdown.
Notice in this diagram there is an aggregation between the Power Subsystem and a Block called the Brake Pedal. This represents a SysML concept called a reference part. This is because the Brake Pedal is not owned by the Power Subsystem. However it is referenced and connected to it in the internal block diagram.
If I go to the IBD then you can see this reference part is linked with the owned parts, but that it’s represented by a dashed line because it’s not owned by the Power Sub system block. Note how this IBD is where the wiring between ports or parts is made, not on the BDD.
This can sometimes be a challenge for new users. The key things is that Blocks are types of things. If I had a Car with 4 wheels, then my BDD would define a Block representing a Car and a Block representing a Wheel. If I have 4 wheels then I don’t have a Block for each wheel, I have 4 parts typed by the same Wheel block.
Let’s go back to the BDD. I just want to cover a few things about Rhapsody’s implementation of SysML.
Block Definition Diagrams in Rhapsody, like Class Diagrams are defined by New Term stereotypes applied to Rhapsody’s base Object Model Diagram type.
But here's a thing, there’s a lot more diagram tools in the BDD toolbar than there are with a Class Diagram. Immediately it becomes apparent therefore that a BDD offers more choice than a Class diagram because SysML has lots of stereotyped element types. Some of these are legacy elements.
This is perhaps against the original intent of SysML which, if you recall with it’s Venn diagram overlapping with UML, had a smaller SysML circle to represent that SysML was smaller than UML.
It’s worth noting that Rhapsody has kept pace with SysML, including adding new concepts such as proxy, full ports and Interface Blocks.
Rather than manage multiple versions of SysML, there is a single SysML profile with the super-set of concepts. This has the benefit of supporting existing models without changing them, while allowing modelers to utilize the new concepts such as proxy ports, if they want to in either new or existing models.
It does mean that there’s a lot of things in the BDD toolbar though.
To get around this issue the Rhapsody development team added a customization feature called the Perspectives Toolbar. The perspectives toolbar enabled you to have a pull-down list that filters the Rhapsody menus, including the drawing toolbar. It enables you to change the palette to only a subset of the types in the profile. Reducing the menus makes it’s a bit simpler for users who are not SysML experts, but does - of course -mean than someone needs to make a choice on what tools you want.
For example, if I know that my modeling approach is not going to use associations and flow specifications, then it’s better to remove them from the toolbar before anybody see the tool, otherwise you have to tell people not to use it.
Here I’ve added a perspective toolbar to that hides some of the legacy tools from users.
Personally, I’ve seen a lot of companies benefit from simplifying Rhapsody menus upfront to reduce the training needs and improve modeling consistency. This is a greater challenge when when rolling out Rhapsody to a wider audience with less knowledge and experience of SysML and it's partly a challenge caused by using a generic language like SysML.
A second thing worth noting in Rhapsody's BDD implementation is more fundamental to SysML which is that when you draw a composition relationship then Rhapsody will create a part automatically in the browser based on the composition's role name. This is enabled by a property called RepresentParts. The same behavior can be added to Rhapsody class diagrams but does require a little property-magic up front, if this is the behavior you want.
Importantly for understanding BDDs, I just want to emphasize that you can’t draw connectors between ports on a BDD. The diagram you should use to do this is an Internal Block Diagram in SysML, which is known as a composite structure diagram in UML. Essentially, it’s an IBD where we do the wiring in SysML and connectors go between parts, rather than blocks.
Finally, SysML also puts a lot of emphasis of the use of compartments to show the features of a Block, and Rhapsody is very powerful in allowing you to choose which compartments you want to show, the order of compartments, and also what things to show in the compartments. To do this, you need to set the graphical node to specification view, and go to the Display Options dialog.
Rhapsody’s Display Options dialog isn’t bad at allowing multi-selection either. I’ll add a compartment that shows the parts on all of these Blocks.
Anyway, I hope that helps to give at least an overview of Rhapsody's implementation of the Block Definition Diagram in SysML.