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.

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

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:

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:

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.

Editing Diagrams

Full-Screen Editing

Rapid buttons and inline editing make it possible to quickly and easily edit diagrams from within the Diagram pane only. The other panes can be hidden to provide a greater work area (see the Section called Full-Screen Editing in Chapter 11).

For example, guards and triggers can be added with a rapid button (effects are edited inline by double-clicking on the effect):

Some rapid buttons make multiple options available through a context menu. In State diagrams, this can be seen in the activities rapid button:

States

For more information about the specific fields, see the Element section the Section called States in Chapter 12.

Transitions

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.

Diagram Elements

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

Do layout

Update layout

Zoom to 100%

Zoom to Fit

Zoom to Selection