What is a block in SysML? Why is it important?

This is not about just any block, but specifically about the "Block" model element of SysML. This is the most important structuring element of SysML.

At first glance, a block looks banal - visually, it's a simple box. But even when we work conceptually on the whiteboard, we often start with boxes and lines. So why not use the correct notation right away?

The diagram is not the model

Even if we often start with the diagram: We must not forget that the visual representation is merely a view of the model. When I talk about a block here, I mean what is behind it. And not just what we see on the diagram.

Back to the block. A block is a modular unit of the system description. The block collects the properties of this unit. These can be properties such as color or shape, but also behavior.

We use this flexibility on the whiteboard, and it is also retained in SysML. Blocks are therefore useful in every phase of development.

Create boundaries

A block draws a clear boundary between "inside" and "outside". This is useful for many activities, for example the distribution of Responsibilities ("Is the power supply part of the system or not?").

Furthermore, the Decomposition of the system and helps, Complexity under control. This also ensures a systematic and reliable Reuse possible.

The borders result in two views. The View from the outside is the Black box-view. This describes the behavior of the system without us being able to understand its inner workings. A classic example is a computer monitor. It has a certain behavior (when I connect a video signal I see a picture), but we are not interested in how this works. And the black box has also survived the change in technology from picture tubes to LCD and LED.

The View from the inside is the glass box view, where we see how the system works. What is important here is that we are not really interested in anything outside the block. To stay with the monitor: The white box doesn't care whether the video signal comes from a computer, a games console or a Blu-Ray player.

And now a little more formally

Even if these concepts are simple, they are also very powerful. However, an informal approach scales neither on the whiteboard nor with PowerPoint: if a few boxes and lines are created by hand, there is no clear semantics. This can be done in a small brainstorming session, but within a week the participants will have forgotten whether the line is supposed to represent a decomposition or a common interface.

SysML solves this dilemma by formalizing these concepts. SysML is a language that allows us to capture these things cleanly and without contradictions.

The downside is complexity. In SysML, there are 12 relationships with a total of 24 variations between two blocks alone. Therefore, we should definitely limit the elements used. What these are, of course, depends on the use case. There are good approaches in the literature. Bruce Douglas, for example, presents a minimal SysML profile in his book Agile Systems Engineering.

BDD: Working with Black Box

The Block Definition Diagram (BDD) shows the blocks that exist. For example, computer and monitor:

The line is an association. There are numerous variations here, but I don't want to go into them here. What is more important is that these blocks are not yet concrete instances, but types. There are computers and monitors.

IBD: Working with Glass Box

If we now look at the system as a glass box, things look different: Because now we are dealing with concrete instances. There is exactly one (unnamed) computer and two monitors, m1 and m2.

Furthermore, interface modeling has already begun here: We can see that ports have been introduced for the energy supply (the green squares). These are labeled "e" on all blocks and have the type "Energy".

This example is definitely not yet fully developed. For example, the interface between the computer and monitors should also be worked out with ports.

Model explosion

This can be seen in the second image: If you want to model "really formally", then the model explodes very quickly: interfaces are introduced, these are typified, and suddenly we get lost in the details. While the BDD is still intuitively understandable, we have to take our time with the IDB in order to understand it.

This is not to say that such a model is not useful. But it is important to be clear beforehand whether the modeling effort is worthwhile.

I would therefore like to give the following advice:

• Articulate the goal of the modeling
• Do not model more than necessary for the goal
• Ensure that everyone involved can read and understand the model
• If informal modeling is used, still use the correct notation.

I find the last point in particular important: when we discuss a model on the whiteboard, for example, we should use the colon when we talk about specific instances.

Conclusion

Blocks are one of the most important model elements of SysML. We should all be able to read block diagrams (IBDs and BDDs). Even when informally "modeling" on the whiteboard, we should not grossly violate the SysML notation.

And finally: Blocks are excellent for describing structures. But without a description of the behavior of the system, they are of little use. This will be the subject of a future article.