In the previous post i described a state diagram for a Sales Order Processing system that was based on the availability of stock items. In practice we would almost certainly requre state that were dependent on payment authorisation as well as item availablity. This leads to the notion of concurrent states, where one group of states in a diagram model the stock item availability and a separate group of states model the payment authorisation process.
The diagram below illustrates this concept of concurrent states. These concurrent states are represented in two distinct swimlanes. The concurrent sections of the state diagram a places in which, a given order can be in two different states. When an order leaves a concurrent state it will be i a single state only.
The concurrent state diagrams are useful where a given object has multiple sets of independent behaviours. In practice, I prefer to limit the number of concurrent states to a small number, usually two or three, and when I have more than three I would normally split out the independent behaviours into separate objects as I find that this improves diagram clarity and readability, as well as improving the integrity of subsequent code.
State diagrams are useful for describing the behaviour of objects that often span more than one Use case. For models that describe the interaction of several objects I prefer to use the UML Interaction Diagram.
In the next blog post I will describe the UML Interaction Diagram, and provide some examples of its use to describe the interplay of messaging and events between co-operating groups of objects.
James Goode, Tendron Systems Ltd