Table of Contents
Regions or no regions
For some systems you want to model certain parts which run independently from each other but react on the same set of events. These independent parts can be modelled using regions in UML state diagrams. Another term often used are orthogonal states or AND states (model is in state A and state B at the same time).
Let's take a microwave oven as an example. The model above is designed around the states that can be perceived from the outside (i.e. the user). Either the oven is on or off or paused. All other elements in the oven (lamp, timer …) are handled in these states and the transitions between them.
- compact diagram
- Eventually easier to understand for an outsider (e.g. customer) not knowing or interested in the internal organisation of the device.
- the individual parts of the system are not represented and separated clearly
Model with regions
Introducing regions separates the parallel running parts of a system in an own region of the model. A region has a name and should focus on one part of the system. A state can contain two or more regions which are executed in parallel. Each region receives the same events that are sent to the containing state. Entering a state with regions enters all regions at the same time. Leaving a state with regions leaves all regions at the same time.
- Clear separation of parallel running parts of the system
- Reuse is simpler because different parts of the system are not mixed with each other.
- Slightly bigger model and more states to model
Both models creates the same output. So it is not about right or wrong but more what is more appropriate for the current case. If reuse is a design goal regions can have a benefit. If a most compact design is a design goal regions have a slight drawback.
Send us a mail in case you want receive the model and test bench to get an own impression.