Modeling behavior correctly

Systems are dynamic. Vehicles move, traffic lights change color. Describing dynamic behavior correctly is one of the challenges in systems engineering. This happens on many levels, right down to the smallest implementation detail, be it in the form of rotating gears or software functions.

In order to describe behavior, we first need a vocabulary. Traditionally, this is managed using a glossary. In modeling, SysML blocks, for example, or UML classes can be used for this. Blocks were recently described here. The also described here ICONIX process uses UML classes to describe the domain. The distinction between dynamic and static aspects can also be seen there.

Dynamic requirements

Classic text templates that can already be found in ISO standard 29148 (Requirements Engineering) and its predecessors:

This approach works, but does not scale particularly well. Modeling allows us to scale. For example, modeling can be used to ensure consistency.

Use cases

Dynamic requirements are typically modeled with use cases, which exist in both UML and SysML. The diagrams are well known:

But much more important are the tables that describe the exact behavior:

UC name	Logging out
Actors	Any logged in user
Description	As a user, I want to log out of the system, so that nobody can access my account from this browser session.
Preconditions	User is logged into the system
Activity	[User] initiates log out [System] logs the user out of the system and displays a corresponding message
Postconditions	User is logged out of the system

This example comes from a Article I published in the RE-Magazine of the IREB have.

Use cases are typically used for user requirements, but they can also be used for system requirements. The actuators do not have to be people, they can also be other systems.

Activities

The activities of a use case can be detailed using activity diagrams. This is overkill for a linear process, but is very useful if there are branches or loops in the process. Since an activity itself is a model element, it can contain information that cannot be found in a simple (informal) activity list. So here, too, we can increase the degree of formalization as required, which in turn gives us a benefit can bring.

States

There is also the state diagram, which is sometimes confusing for beginners as it is similar to the activity diagram.

However, the difference between activities and states is very important. Concrete example:

• The activity "Increase the variable by one" always leads to new states of the variable. 1 becomes 2, 2 becomes 3, etc.
• The "Traffic light is yellow" status can be reached in two ways: "From green to yellow" and "From red to yellow".

Sequences

Sequence diagrams are about the exchange of messages between objects. These are similar to activity diagrams, but are often found one level lower, i.e. closer to the solution.

Functions and methods

At the implementation level, in software code, there is of course also dynamic behavior. Depending on the programming language, this can be found in functions or methods.

The exciting thing here is that the included code describes the implementation. But where is the specification? There are various techniques for this, such as Programming by Contractwhich carefully defines pre- and postconditions and can also evaluate them. Another approach is the use of unit tests. These can also be combined with test case generation from the model.

Conclusion

There is a range of modeling techniques for dynamic behavior, and these can be applied at many levels. This is because dynamic behavior runs through the entire system.

In practice, less is more: when in doubt, it is better to have one model type less than one more. When in doubt, it is better to be a little more informal than too formal and too deep.

Nevertheless, at the end of the day, it is the behavior of the system that brings benefits. Capturing and implementing this correctly is an important task in system development.

Cover picture: Pixabay