Broadcast date: December 5th, 2021
Welcome to the 5th door of our MBSE Podcast Advent Calendar. Today, we take a look at the system context.
We already defined a context for the base architecture behind door #4 of our Advent calendar. The base architecture context constrains the context of our system of interest. We model it by defining a generalization relationship from the system context to the base architecture context. Let’s check that out in the model:
The part property “The MBSE Podcast Christmas Tree” is a redefinition of the inherited system property base_tmpct from the base architecture context.
In addition to the inherited actors from the base architecture context, the TMPCT system context has an additional actor Christmas Tree Seller.
The system context elements are SysML blocks with applied stereotype “systemContext” from the SYSMOD profile. It is just a marker profile that introduces a new name and additional semantics, but no new properties.
The internal block diagram of the system context element depicts the well-known system context diagram:
The inherited elements from the base architecture contexts have a circumflex prefix symbol. In our system context, all actors are inherited except the seller.
SysML provides only the general concept of an actor. It is useful to define different actor kinds to emphasize the different methodological approaches. At least you should differentiate between humans and non-humans. In the shown context diagram, you can see four different actor kinds:
- Human users of the system, for example, Santa Claus.
- External systems, for example, the power supply.
- A mechanical system is a special kind of external system that has only mechanical interactions with the system. Here, it is the floor of the room.
- The Planet Environment to consider the impact of the system on the planet.
All actors have some kind of interaction with the system, and you could specify the interaction point by ports.
And here we have the little surprise learning in this episode: stakeholders are not in context or only when they interact with the system. For example, we MBSE podcast hosts are stakeholders of the system, but not actors. Of course, as people, we could take on the role of user-actor. But the MBSE podcast host role is not an actor and thus the system does not provide any special interfaces or functions for us.
Vice versa all actors are stakeholders of the system. Sometimes they are not directly stakeholders, but representatives. For example, things like the floor are not a stakeholder, but the owner of the floor is a stakeholder.
So much for the fifth door of our MBSE Podcast Advent Calendar. We wish you a great 5th of December.