End-to-End UML: State Diagram

About the Series

This series of articles is designed to present the set of core UML diagrams in a way that emphasizes the important relationships between the different diagrams and the logical progression from one diagram to another.

In this installment we progress from the UML Class Diagram and UML Sequence Diagram to the UML State Diagram.

The UML State Diagram, sometimes known as the Statechart Diagram or Static Transition Diagram, defines the entire lifecycle of a business entity or object in terms of the messages it receives and the responses it makes from the moment of creation until the moment of destruction. These diagrams were adopted into the UML from earlier work undertaken by David Harel on Statecharts.

The number and type of diagram elements will vary according to the UML diagramming tool, the version of UML, and the context in which the diagram is to be used. Our subsequent worked example will utilize the following diagram elements that should be available in most if not all UML tools.

	Most if not all state diagrams should begin with an Initial State: a filled circle representing the creation of a new instance of the class that is being modeled.
	Most state diagrams will conclude with a Final State: a filled circle with an outer ring marking the point at which an object instance is destroyed and no longer exists.
	At any given time an object instance will exist in a State represented by a lozenge shape; this state reflecting the combination of the object’s attributes and associations at the time. Every State will have incoming and outgoing Transitions (see below) including self-transitions that loopback to the same State.
	A Transition is represented by a line showing that the object is moving from one state to another. Whereas an object will exist in a State for a period of time, a Transition is usually considered to be instantaneous.
	Every Transition will be triggered by an Event which – depending on the level of abstraction – may or may not correspond with the invocation of an object operation.
	A [Condition] (yes, the square braces are important) determines whether or not the triggering event actually results in a transition to another State. If the condition is not met, the object remains in the original state.
	An Action, which is usually preceded by a “/” character on the transition line, represents an atomic unit of functionality that must be performed in order for the Transition to complete.
	An Action may be represented in the form of an Entry Action if all transitions into the State (without exception) require the action to be performed. Similarly an Exit Action (not shown) must be performed whenever an outward transition occurs.

While this table of diagram elements is informative, the only way to truly appreciate the role of the UML Class Diagram is via concrete worked examples.

The following worked example of a UML State Diagram provides a use-case-independent representation of how instances of the Bank Account class should behave over time. This is the Bank Account class from our running example, and this state diagram has been partially derived from information included in those sequence diagrams and class diagrams that include the Bank Account class.

When an account is first opened (by the Bank Manager actor, remember) a new instance of the BankAccount class is created in the InCredit state.

The UML Sequence Diagram(s) and UML Class Diagram(s) that were created in earlier articles tell us that two operations may be invoked on the BankAccount class: the credit operation and the debit operation.

When the credit operation event is invoked on a BankAccount that is in the InCredit state, the update balance action is performed and the account remains InCredit.

When the debit operation event is invoked on a BankAccount that is in the InCredit state, the account either transitions to the InDebit state (if the condition [balance<0] is true) or it stays in the InCredit state (if the condition [balance>=0] is true). Either way, the balance must be updated by performing the update balance action.

Whenever and however a BankAccount enters the InDebit state, the entry action ensures that we always mark account as overdrawn.

When the debit operation event is invoked on a BankAccount that is in the InDebit state, the update balance action is performed the account remains InDebit.

When the crebit operation event is invoked on a BankAccount that is InDebit, the account either transitions to the InCredit state (if the condition [balance>=0] is true) or it stays in the InDebit state (if the condition [balance<0] is true). Either way, the balance should be updated by performing the update balance action.

This state diagram ends with the Final Activity when the Bank Account is closed.

The UML State Diagrams form a vital link between the UML Sequence Diagram and the UML Class Diagram, and act as an important cross-checking mechanism. For every state transition that is triggered by a message, one would expect to see a corresponding object interaction on at least one sequence diagram. For every operation defined for an object on a class diagram, one might expect to see a state transition demonstrating how the object responds to the invocation of the operation.

When using a UML tool or other drawing tool that does not explicitly support the UML State Diagram it may be possible to adapt a UML Activity Diagram for the same purpose.

In some UML tools it may be possible to draw composite states that encapsulate a number of sub-states. For example: a newly opened Bank Account might transition from the initial state to an OpenAccount composite state that encapsulates the InCredit and InDebit sub-states along with their transitions.

Many of the object classes that you define will not have a lifecycle as such, or will have a trivial lifecycle, and therefore not every class requires a UML State Diagram. For example: a Customer class may have a meaningful lifecycle and may be responsive to different events in different states, but it is unlikely that this will be true of the Bank class that represents the bank as a whole.

Objects in states respond to Events which may or may not be in the form of synchronous and sequential operation invocations. The subtle distinction between Events and operations becomes important when we consider, for example, that most modern user interfaces are event-driven such that a UI element like a Window may at any time be subjected to user-driven events (including mouse clicks) that interrupt the current program flow.

NEXT STEP: Test your UML knowledge with a quick UML & Use Case Quizes.

Author :  Tony Loton, Author

Tony Loton has authored and co-authored the books "Professional UML with Visual Studio .NET", "Professional Visual Studio 2005 Team System", and "UML Software Design with Visual Studio 2010"