Allocation: Linking behavior and structure in SysML
Two key aspects of MBSE are the modeling of behavior and structure. With SysML, the structure is modeled with blocks and the behavior with activities. Allocation is the process of linking behavior and structure. Here is a small example.
Changing the behavior of the world
As a rule, the development of systems is interested in changing the behavior of the world. So it's all about functionality. A charger ensures that the smartphone's charge level increases. That would be a simple use case: "Charging a smartphone".
But this use case does not take place in a vacuum. Therefore, we first need a Context that we model with SysML blocks. For this simple example, our context consists of a smartphone, charger and socket (we'll leave out the cables for simplicity's sake).
Allocation: Viewing the use case in context
At the use case level, this takes place in context. This is therefore our first allocation. The other blocks support the use case, which we can express via an association. We can visualize this in a use case diagram:
However, before we refine the "smartphone charging" use case further, we should define the charging context more precisely. In particular, the blocks have standardized interfaces (except "User"), namely Schuko (socket outlet) and USB-C (smartphone). The Charger has the counterpart to both. We can visualize this in the context digram (idb) as follows:
The user is part of the "Phone is Charging" context, but has no interfaces that we need to model explicitly.
With this understanding, we can now break the use case down further into activities, which manifest themselves as actions in the activity diagram. However, the actions must be linked to a structural element. This is done visually by assigning them to a "swimlane", as shown in the following diagram:
Realizing black box thinking through allocation
The purpose of the previous one is to break down our system into components that we can consider independently of each other. In other words, we want each component to be seen as a Black Box can be considered. A black box has two important properties: (1) It can be installed without the consumer needing to know anything about the implementation; and (2) The implementation of a black box does not need to know anything about its use in the system. Both presuppose that both the installing system and the implementation adhere to the interface specification.
By allocating to swimlanes, we recognize interfaces with regard to the process (control flow) as well as flows (stream), which can represent material (including energy) or information. Each crossing of a swimlane by an arrow thus represents an interface.
In the specific example, we now have the activity "Perform charging", for example, which is assigned to the "Charger". We can now break this activity down further without having to know anything about the wider context.
That makes sense: Our charger can now charge all sorts of things via any socket - as long as the interfaces shown in Fig. 2 are connected correctly (Schuko and USB-C).
In reality, of course, it is a little more complicated. Specifically, not only do the interfaces have to fit, but non-functional requirements also have to be met, such as providing and maintaining maximum performance. Furthermore, the interfaces can also be further nested in order to retain more detail. Fig. 4 shows an example of how we could model the Schuko port:
Continue to operate any deep allocation
We have just seen how we have mapped behavior and structure (use case and context) to the next level down via allocation. We can continue to do this at any depth. I find Fig. 5 from the MagicGrid Book of Knowledge useful in this regard:
As you can imagine, the number of model elements can quickly explode here. It is therefore important to create scalable structures for the model tree in the tool. In addition to the convention in the MagicGrid book, the SYSMOD book good recommendations.
Only work with sensible methodology!
Correct allocation is not an end in itself. It helps us in practice:
- Decouple subsystems from each other
- Ensure completeness of the subsystem specifications
- Enable variant and product lines
- ... and much more
What is shown here is only one aspect of SysML modeling. To use allocation effectively in MBSE, we need the appropriate working context (tool and methodology).
Conclusion
Allocation is an important concept in MBSE to link structures and behavior. SysML provides us with the means for allocation. Anyone interested in MBSE should understand how allocation works and why it is important.
