10. State Machine Diagrams

Business process models do not lend themselves to implementation in an object-oriented way. If you go the UML way, you will break down the business process and express it in terms of states for each object involved in the process. Numerous other systems, real-time systems for example, also have great need to plan the states of objects. State Machine diagrams (also referred to as State Diagrams) are used to illustrate the possible states of an object and the causes and effects of those state changes within the object.

In UML 2.0, a BehavioredClassifier such as a Class, UseCase, Collaboration, Component or Node may have 0..n state machines. These state machines are displayed in the Package Centric and State Centric views as subnodes of the owning BehavioredClassifier.

Each state machine may have 0..n state machine diagrams that can depict all or part of the state machine. State machines imported from XMI without related diagram information are added to the model and are accesible from the model navigation tree. State machine diagrams exist in their state machine's namespace and are therefore displayed as subnodes of the state machine.

Figure 10.6. Class with two state machines, State machine with two state machine diagrams.

Class with two state machines, State machine with two state machine diagrams.

A state machine in Poseidon has exactly one region, which is referred to as the top region. With UML 2.0, this region replaces the UML 1.4 top-level state. All of the states and transitions of the state machine reside in this top region, regardless of the diagram in which they appear.

Figure 10.7. A State Machine diagram

A State Machine diagram

10.1. States

In a state machine diagram, each state has at least two compartments, the top one always keeping the name of the state. The name usually is an adjective describing the recent object.

The states' properties are a lot more meaningful and complex than they are in the activity diagrams. Not only does a state have ingoing and outgoing transitions, but also different activities that are to be taken with it.

Let's take a look at the states themselves. In the diagram toolbar you'll find four different symbols. State types can be distinguished by their regions and connection to submachines:

  • Simple State

    Simple state has no regions and is not associated to a state machine. The region list and submachine list in the property panel is always empty.

  • Composite State

    Composite States make visual use of the second compartment that encloses refinements of the given state. Enclosed states don't have to have an initial state. Ingoing as well as outgoing transitions might be connected directly to one of them. When the corresponding object is in the composite state, it is exactly in one of the sub-states (OR relation).

    In a composite state, the second compartment of the state has exactly one region

  • Orthogonal State

    Orthogonal States are, like the above, refinements; therefore, they are focused in the second compartment. When the corresponding object enters the concurrent state, all initial sub-states all are enabled at once (AND relation).

    An orthogonal state has more than one region in the second compartment of the state. The regions are divided with dashed lines.

  • Submachine State

    A submachine state is similar to a simple state in that it has no regions, but it is associated to another state machine.

10.2. Creating Diagrams

State Machine diagrams can be created in three ways. The way the state diagram is created and where it is placed in the model depends on the model element currently selected.

  1. With the context menu - Right click on a BehavioredClassifier, then select 'State Diagram'.

    This context menu item is available only for BehavioredClassifiers in the navigation tree and in the diagrams.

  2. From the toolbar - Click the 'State Machine Diagram' button in the toolbar. This option is available regardless of the selected element.

  3. With a quick-key - Use 'Ctrl-T' to create a new diagram. This option is available regardless of the selected element.

The selected element determines how the state machine diagram is added:

  • BehavioredClassifier (Class, UseCase, Collaboration, Component or Node) selected - a new StateMachine is added as a subnode to the selected element, and a new diagram is created as a subnode of the new state machine.

  • State Machine selected - A new state machine diagram is added as a subnode of the selected StateMachine.

  • State Machine Diagram selected - A new state machine diagram is added as a subnode to the owning StateMachine of the selected state machine diagram.

  • Any other model element selected - A new Collaboration is created in the currently selected namespace, a new StateMachine is added as a subnode of the new Collaboration, and a new state diagram is added as a subnode of the new StateMachine.

Try it Yourself - Create A State Machine for a Class
  1. Open a class diagram.

  2. Create a new class by clicking the 'New Class' button on the toolbar, then click anywhere in the class diagram.

  3. With the new class still the selected element, click the 'New State Machine Diagram' button. A new state machine is created for the class, and a state machine diagram is created for the state machine.

The new state machine is best seen in the 'Package Centric' or 'State Centric' view of the Navigator pane:

State Machines for Elements other than BehavioredClassifiers

Use cases and collaborations are among the BehavioredClassifiers and can thus have their own state machines. But what about other elements? Interfaces are not BehavioredClassifiers in UML 2.0, for example; if an interface needs a state machine, it must first be implemented in a collaboration or class, which can then have state machines. In the following example, the operations of the implemented interface are then available to the triggers of the collaboration's state machine.

Conversion to UML 2.0

The statechart diagrams of UML 1.4 have notations and organizations that are different from the UML 2.0 state machine diagrams. Poseidon 3.1 is the first version of Poseidon for UML to implement the state machine diagram, and it will automatically convert the older statechart diagrams to the new state machine diagrams.

For example, interfaces were allowed to have state machines in UML 1.4, but they are not BehavioredClassifiers and so they are no longer permitted in UML 2.0. In this case, a new collaboration is created and the state machine of the interface is added to this collaboration. The collaboration will get all of the operations specified in the triggers in the state machine. The same conversion is done for Classifier Role, Exception, Subsystem, Signal, and DataType.

10.3. Editing Diagrams

States

For more information about the specific fields, see the Element section Section 4, “States”.

  • Region - A region is a part of a composite state, orthogonal state, or state machine that contains states and transitions.

    In orthogonal states, they are used to indicate concurrency. Reordering regions in orthogonal states in the Property panel reorders them in the diagram display as well.

    As of Poseidon 3.1, regions can be added and removed from states using the 'Add' and 'Delete' buttons in the Property panel or rapid buttons. The number of regions determines the type of state, so removing a region from a composite state transforms it into a simple state, and so on.

  • Activities - Activities are elements in themselves, just like any other part of the model. As such, editing them is done in the same way as any other element - just like an attribute is a part of a class.

    Activities are added from within the state's Property tab using the 'Add' button. Whenever you add an activity, Poseidon will automatically navigate to the new element. Upon return to the parent element, the 'Add' button will no longer be visible, rather it will be the 'Delete' button, indicating that the element has been successfully added.

    To remove an existing element, use the 'Delete' button. Note that this will delete the element entirely from the model.

    In Poseidon 3.1, the 'Asynchronous' option in Actions (now renamed Activities) has been replaced by the tagged value 'isAsynchronous'.

  • Submachines - A submachine is used to hide or extract details of a state machine. The submachine state is similar to a simple state in that it has no regions, but unlike a simple state, it is associated to a state machine that belongs to the same BehavioredClassifier.

    References are used to indicate the entry and exit points of the submachine, which can optionally be displayed in a state machine diagram. Deleting the reference does not delete the entry and exit points of the submachine, it only removes their display in the upper-level diagram.

    To directly navigate from a submachine to the diagram(s) for the submachine, use the 'Go To Contained Diagram' rapid button.

    Try it Yourself - Create A Submachine with Entry and Exit Points
    1. In a state machine diagram, click the 'New Submachine State' button, then click anywhere in the diagram. A new state machine is created for the submachine and a diagram is created for the new state machine.

    2. Navigate to the new diagram by hovering over the submachine state to display the rapid buttons, then click 'Go To Contained Diagram'.

    3. Click the 'New Simple State' button in the toolbar, then click anywhere in the submachine state machine diagram to add a state.

    4. Click the 'New Entry Point' button in the toolbar, then click anywhere in the submachine state machine diagram.

    5. Hover over the entry point to activate the rapid buttons, then click and drag the 'Outgoing Transition' button to the simple state.

    6. Click the 'New Exit Point' button in the toolbar, then click anywhere in the submachine state machine diagram.

    7. Return to the first state machine diagram by clicking its tab at the top of the diagram pane.

    8. Select the submachine state. Connect the entry and exit points by clicking their checkboxes in the property pane of the submachine state.

    The submachine state now displays references to entry and exit points:

    Converting From One State to Another

    As of Poseidon 3.1, it is possible to convert one type of state to another, e.g. from a simple state to a composite state.

    Delete regions to change, for example, an orthogonal state to a composite state or a composite state to a simple state.

    Simple states can be converted to submachine states - simply select a submachine from the list of available submachines in the Property panel. Likewise, a submachine state can be converted to a simple state by deleting the association to the state machine. This is done by selecting <none> from the list of state machines.

Transitions

  • Triggers - If present, a trigger initiates a state change from the source to the target of the transition. A trigger can be a signal, an event, a change of condition, or the passage of time.

    The Property panel of the trigger contains a dropdown list with the available operations for the trigger. These are the operations of the owning BehavioredClassifier, the inherited operations of any superclasses, or operations of an implemented interface.

  • Guards - Guards, if present, must be satisfied in order for the transition to occur.

    If the name and expression are empty, nothing will be displayed in the guard portion of the transition label. If the name is present, the name will be displayed, regardless of whether or not there is an expression. If no name is present but the expression is present, the expression will be displayed.

    In UML 2.0, the guard element has been replaced by the constraint element. The guard association remains, however. This change only affects the appearance of the property panel of the guard itself, which now displays a property panel for a constraint.

  • Effects - An effect is an Activity that will be invoked as a result of the transition.

    The effect activity is the same as an entry, do, or exit activity, except that it must be triggered.

  • Inline Editing - Transitions can be edited inline as with other diagram elements. When the transition is selected but does not have a trigger, guard, or effect, the diagram and property panel are displayed as such:

    Double-click the text above the trigger to enable inline editing. You may then enter any combination of triggers, guards, and events. Text appearing before the square brackets [ ] will be entered as the trigger, text between the brackets as the guard, and text after the slash / as the effect, and will also be available in the Property panel.

Drag and Drop, Copy and Paste

While editing a state machine diagram is similar to editing any other diagram in Poseidon, there are a few exceptions you should be aware of.

  • The drag and drop of elements from the navigation panel to the diagram panel is available only for elements of the same state machine.

  • Complete state machines can be cut and/or copied to another BehavioredClassifier. However, all operations of the trigger of the state machine and its states are deleted if they do not belong to the new BehavioredClassifier.

  • An operation can belong to the new BehavioredClassifier if the new BehavioredClassifier is a parent of the old one.

10.4. Diagram Elements

  • Initial States and Final States - Indicate the beginning and end of the observed process.

  • Action States - Specific activities that comprise the process. They must be executed in a specified chronological order. Sometimes you may want to split the sequence. Therefore, you have two different possibilities: Branches (choice) and Forks (concurrency).

  • Forks and Joins - Forks divide the sequence into concurrent sub-sequences. Joins merge the sub-sequences.

  • Transitions - The ingredient that keep states active and the model elements together. Each transition can be given guards , triggers , and activities as properties to describe its behavioral details.

  • Choices and Junctions - Both elements are used in sequential systems to define decision points. The difference between them is that choices are dynamic and junctions are static.

  • Shallow History and Deep History - History states are used to memorize past active states so that you can return to a marked point and don't have to start again from the beginning. A deep history allows you to return from any sub-state, whereas a shallow one only remembers the initial state of a composite state.

10.5. Toolbar

Select
Add or remove space between elements
Simple State
Composite State
Orthogonal State
Submachine State
Transition
Initial State
Final State
Deep History
Shallow History
Choice
Junction
Entry Point
Exit Point
Terminate Point
Fork
Join
Comment
Connect Comment to Element
Text
Circle
Rectangle
Polygon
Polyline
Repaint