In state diagrams usually only one state is active at a time. In UML state diagrams regions also allow to model concurrency - i.e. more than one state is active at a time (AND states). This article explains why it can be tricky to use regions.

Notation

A UML state may be divided into regions containing sub-states that exist and execute concurrently. The diagram below (Fig. 1) shows that within the state "Run", four regions with two states each run simultaneously and independently. Dashed lines are used to divide a state into regions.

Using multiple regions

Consider a microwave oven. The lamp, door, timer and microwave radiator can be modelled as independent (concurrent) parts of the oven, each with its own states. The door can be in state “Closed” and in parallel the lamp can be “On” or “Off” depending on the “Timer”. Transitions can be triggered from events (e.g. door closed). The sender might be outside or inside the state diagram. Transitions can also be triggered depending of the state of another region. For example the radiator can only be switched on if the door is closed.

As you can see multiple concurrent regions are useful to model the states of different parts of a device. And all the states are shown in the same diagram.

Fig. 1: Oven design with concurrent regions.

Alternative design

The microwave oven can also be modelled in a different way as shown below (the example is taken from the manual). Not the states of the different parts of the oven are modelled but the overall oven behavior. No concurrent regions are used in this design. This makes it usually easier to undertand the diagram and follow the event flow during debugging and simulation.

Fig. 2: Alternative oven design not using regions.

Problems with regions

In the first diagram state transitions do not cross region boundaries and therefore the modeller’s intension is quite clear. But look at the next diagram which is a valid diagram too. Now it is not clear anymore what the modeller had in mind. And it is also not very obvious what a code generator would/should generate. A tool might generate the following sequence:  Ev1 triggers a state change from S1A1 to S1B2. As reaction the exit code of S1A1, the upper region and S1 has to be called. Then the enter code of S1, S1A1 (it is the default state in the upper region) plus the enter code of the lower region and S1B2 has to be called. Then in a next step the same happens for the transition from S1B1 to S1A2. This means the entry and exit codes of the regions and S1 are called twice. Most developers do probably not expect this.

    Fig. 3: Problematic design using regions.

And the conclusions?

To avoid the complexity of concurrent regions and the difficult interactions that has to be generated from diagrams as shown above it is recommend to avoid the usage of regions. When regions are used the execution sequence is often not obvious and the generated code difficult to understand. Usually there is also another way to model the problem avoiding regions. For that reasons the sinelaboreRT code generator does not allow code generation of states containing concurrent regions!

If regions looks like a promising solution for your problem think about to create a separate state diagram (i.e. a separate modul) which models a certain aspect of the device.