Handling Concurrency with States

Some of your objects can (in effect) walk and chew gum at the same time. Think of the objects you have that are aggregations: They include the whole object (the aggregate), and all the individual part objects contained within the whole. The parts of your aggregate work independently of each other, a situation called concurrency. So you need a way to show that some states in your objects are concurrent—they don’t depend on each other, and can (but don’t have to) happen at the same time.

Remember Concurrent objects have causally independent behavior; in object-oriented systems, concurrent doesn’t mean “simultaneous.” Concurrent independent behavior among concurrent objects can be simultaneous—but it doesn’t have to be.

Diagramming concurrent states

As an illustrative example, consider an air-filter machine. It’s composed of several parts, among them are the controller for the air-filter machine, the ultraviolet lamp, the filter to clean air, and the fan to move air through the filter. Figure 18-7 illustrates this aggregation relationship between the AirFilterMachine class and its parts.

Figure 18-7: Air-filter machine aggregation.

Remember The diamond shape in Figure 18-7 represents aggregation. If the diamond is filled in, that represents the stronger form of aggregation known as composition. For more details see Chapter 5.

Tip When you want to show the concurrent states for the class playing the role of the whole in an aggregation, just show a state diagram for every part of the whole. Figure 18-8, for example, combines the state diagrams for the AirFilterController, the Fan, the Filter, and the UVLamp. The state of one instance of AirFilterMachine is a combination of current states—one for each of its parts.

You can also think of an object as having the state of being itself (as an instance of its class). Figure 18-8 shows the states of the object inside a superstate. Thus you see the superstate AirFilterController containing Off, On, and Standby substates.

Figure 18-8: Composite states for the air-filter machine.

Notice that the superstates in Figure 18-8 have little tabs attached to them—that’s just another minor variation on UML state-diagram notation: the name of a state in a small box attached to the top of the state.

You can also show concurrent states within an object. In the example of the air-filter machine, concurrent states across objects are all part of one aggregation. But some states have concurrency—independent behavior—within themselves. The On state for the AirFilterController (for example) is more complex that you might first realize. When you turn on the air-filter machine, you’re telling an instance of AirFilterController to perform the following tasks, all at the same time:

Check sensors: Keep an eye on all the sensors to make sure they’re working properly. If a sensor isn’t working, go into a service mode.
Monitor air quality: Check the air quality through the air quality sensor. When the air quality is less than the desired level, increase the fan speed. When the air filter achieves the right level of air quality, decrease the fan speed and return to simply monitoring air quality.
Monitor motion: Using a sensor, check for motion. If there is motion (such as a person walking by), go into cleaning mode: increase the fan speed and turn on the ultraviolet lamp. When there is no motion (or a certain amount of time has passed), return to simply sensing motion.

The AirFilterController must perform each of these tasks when it’s in the on state and it must perform them independent of each other. To show concurrency within a state, divide the state into regions. Each region is separated from the others by a dashed line. a mini state diagram is placed into each region showing the concurrent behavior. Figure 18-9 contains the concurrent states for the AirFilterController’s On state. To keep this state diagram simple, we have not shown you the substates of the CleaningAir, Servicing and Cleaning states. (Details for the CleaningAir substate are discussed in the section “Using pseudostates with concurrent substates” later in this chapter.)

Figure 18-9: Concurrent states.

Using pseudostates with concurrent substates

A couple of handy pseudostates can help you construct states that have concurrent substates:

Fork: The fork pseudostate enables you to take a single event transition and split it into several parallel control paths.
Join: The join pseudostate merges multiple transition paths into one transition.

The UML notation for a pseudostate (whether a fork or a join) is a short, thick line that shows transitions coming in or going out. Figure 18-10 shows an example of how to use the fork and join pseudostates.

Here’s what’s happening in Figure 18-10:

Figure 18-10: Using fork and join pseudostates to manage complex control paths.

If the AirFilterController is in the CheckingAir state and the when(quality < selected) time comes, then the object makes a transition to the CleaningAir state.
In the CleaningAir state, the fork pseudostate (the thick line at the left of the diagram) splits the just-completed when transition into two parallel control paths.

Both control paths lead to the HandleEquipment substate.
HandleEquipment has two concurrent regions, to which control flows as needed:
- In one region, the HandleFan state is executed.
- In the other region, the HandleLamp state is executed.
- HandleFan and HandleLamp are independent of each other.
At this point, while control is in the HandleEquipment region, the object receives the next event:
- If the increased event is received, then the object leaves the HandleFan state and makes a transition to the join pseudostate (the thick line at the right of the diagram).
- If the on event is received, then the object leaves the HandleLamp state and makes a transition to the join pseudostate.
The join pseudostate makes no transition to the Wait for better Air Quality state until the object receives both the increased and on events.

These two events may arrive in any order. The object simply waits until both arrive before moving on.