To model parallel behaviors effectively, you must split the state diagram into distinct vertical zones called orthogonal regions. Each region operates independently but synchronously within the composite state. You define these regions using vertical split bars that separate concurrent activities while maintaining a unified state lifecycle.

Core Concepts of Orthogonal Composition

Definition and Purpose

Orthogonal regions allow a composite state to encapsulate multiple independent state machines. In complex system design, entities often need to perform distinct tasks simultaneously, such as a robot monitoring sensors while moving its arms. Without orthogonal regions, you must flatten the diagram, leading to exponential state explosion and reduced readability. Using orthogonal regions UML simplifies the hierarchy by organizing concurrent threads of control within a single visual container.

The primary goal is to manage concurrency without creating a tangled web of transitions. Each region maintains its own history and responds to events independently. However, the composite state only enters a final configuration when all sub-regions reach their own final states. This structural approach is essential for real-time systems and embedded controllers.

Structural Setup and Syntax

Creating the Composite State

Begin by drawing a standard composite state. This state acts as a container for the concurrent processes. It must have a name and can include an entry action or exit action that applies to all contained regions collectively. The composite state effectively pauses while the internal parallel processes run.

Applying Split Bars

To divide the internal area, insert a vertical split bar. This line runs from the top border to the bottom border of the composite state. The placement of this bar determines the number of regions. A single bar creates two regions; multiple bars create more. All regions must align vertically between the top and bottom boundaries to ensure proper connectivity.

Labeling Regions

Label each region clearly to denote its specific responsibility. Common labels include “Sensor Monitoring,” “Motor Control,” and “User Interface.” Clear labeling is crucial for maintenance teams to understand the partitioning logic. Avoid placing transition lines that cross the split bar, as this is a syntax violation in standard UML.

Step-by-Step Modeling Procedure

Step 1: Identify Concurrent Activities

Analysis Phase: Review the requirements to identify activities that must run at the same time. If two tasks do not depend on the completion of the other, they are candidates for orthogonal regions. Distinguish between sequential dependencies and truly independent loops.

Step 2: Draw the Composite Container

Construction Phase: Draw the rectangular composite state frame. Ensure the size is sufficient to accommodate the number of regions you plan to create. A cramped container often leads to overlapping lines and confusion later. Leave ample margin inside the frame.

Step 3: Insert the Split Line

Partition Phase: Draw the vertical line down the center or at the required interval. If you have three distinct processes, draw two split bars. Ensure the lines are straight and connect the top and bottom borders without gaps. This establishes the boundary of the orthogonal regions UML.

Step 4: Place Sub-States

Organization Phase: Place specific states or sub-machines within the newly created regions. Ensure that each region contains at least one active state initially. You can nest composite states within these regions if the behavior is complex.

Step 5: Define Internal Transitions

Logic Phase: Draw transitions within each specific region. These transitions trigger events relevant to that specific context. Avoid drawing arrows that cross from one region to another. Cross-region communication must happen via shared events or signals at the composite level.

Step 6: Connect Entry and Exit Points

Integration Phase: Draw the entry transition pointing to the initial state of the composite. Define where the exit points lead based on when the internal processes are complete. The exit condition usually requires all regions to be in a specific state.

Splitting Criteria and Decision Making

Criteria for Separation

Not all concurrent activities require orthogonal regions. Use this separation only when the activities are truly independent. If the progress of Activity A depends on Activity B finishing, use a sequence of states instead. Splitting creates overhead in state checking, so unnecessary partitions complicate the logic.

Handling Synchronization

When regions need to coordinate, use synchronization events. An event broadcast to the parent composite state can trigger a transition in multiple regions simultaneously. This ensures that all orthogonal regions UML respond to system-wide triggers at the same logical time step.

Boundary Drawing Best Practices

Visual Clarity: Keep the vertical split lines straight and centered. Do not create angled splits as this violates standard notation. Ensure that no state crosses the boundary of a region. If a state needs to influence another region, use a guard condition or signal rather than a direct transition.

Validation and Troubleshooting

Common Modeling Errors

Transition Crossing: A frequent error involves drawing a transition line that passes directly through a vertical split bar. This is invalid syntax. If a transition must affect a different region, it should stop at the boundary, and a new transition should start in the target region based on a synchronized event.

State Overlap: Ensure no states physically overlap the split lines. Every state must reside entirely within one region. Overlapping states make it ambiguous which region owns the state logic and can lead to undefined behavior during simulation.

Validation Checklist

• Does every region have a defined entry point?
• Are there any transitions crossing the vertical split lines?
• Do the internal transitions form valid cycles within each region?
• Is the exit condition defined for the composite state?
• Are the regions logically independent in terms of execution flow?

Advanced Configuration Scenarios

Nested Orthogonality

Complex systems often require parallel behavior within parallel behavior. You can nest orthogonal regions inside one of the sub-states of a composite state. This creates a deep hierarchy where specific sub-processes are also concurrent. Ensure that the nesting levels do not exceed three to maintain readability.

Handling Asynchronous Events

When events arrive asynchronously, use history states to remember previous positions within orthogonal regions. A deep history state preserves the exact sub-state configuration upon entry, even if the event arrives while the system is in a different region. This preserves context for complex recovery logic.

Key Takeaways

• Orthogonal regions allow independent execution paths within a single composite state.
• Use vertical split bars to divide the state container into distinct regions.
• Transitions must never cross the vertical split boundaries directly.
• Synchronization is achieved through shared events at the composite level.
• Validate that all regions are truly independent before applying this pattern.