State Diagram

A state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many forms of state diagrams, which differ slightly and have different semantics.
State diagrams are used to give an abstract description of the behavior of a system. This behavior is analyzed and represented in series of events, that could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and track the different states of its objects through the system".^[1]
State diagrams can be used to graphically represent finite state machines. This was introduced by Taylor Booth in his 1967 book "Sequential Machines and Automata Theory". Another possible representation is the State transition table.
Newcomers to the state machine formalism often confuse state diagrams with flowcharts  For a long time, the UML specification didn’t help in this respect because it used to lump activity graphs in the state machine package (the new UML 2^[6] has finally separated activity diagrams from state machines). Activity diagrams are essentially elaborate flowcharts.
The figure below shows a comparison of a state diagram with a flowchart. A state machine (panel (a)) performs actions in response to explicit events. In contrast, the flowchart (panel (b)) does not need explicit events but rather transitions from node to node in its graph automatically upon completion of activities.^[8]

Graphically, compared to state diagrams, flowcharts reverse the sense of vertices and arcs. In a state diagram, the processing is associated with the arcs (transitions), whereas in a flowchart, it is associated with the vertices. A state machine is idle when it sits in a state waiting for an event to occur. A flowchart is busy executing activities when it sits in a node. The figure above attempts to show that reversal of roles by aligning the arcs of the state diagrams with the processing stages of the flowchart.
You can compare a flowchart to an assembly line in manufacturing because the flowchart describes the progression of some task from beginning to end (e.g., transforming source code input into object code output by a compiler). A state machine generally has no notion of such a progression. The door state machine shown at the top of this article, for example, is not in a more advanced stage when it is in the "closed" state, compared to being in the "opened" state; it simply reacts differently to the open/close events. A state in a state machine is an efficient way of specifying a particular behavior, rather than a stage of processing.

The distinction between state machines and flowcharts is especially important because these two concepts represent two diametrically opposed programming paradigms: event-driven programming (state diagrams) and structured programming (flowcharts). You cannot devise effective UML state machines without constantly thinking about the available events. In contrast, events are only a secondary concern (if at all) for flowcharts.

State diagrams are used to describe the behavior of a system.  State diagrams describe all of the possible states of an object as events occur.  Each diagram usually represents objects of a single class and track the different states of its objects through the system. Use state diagrams to demonstrate the behavior of an object through many use cases of the system.  Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system.  Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case.  State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams. ¹

State diagrams have very few elements.  The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state.  The activity section of the state symbol depicts what activities the object will be doing while it is in that state.   

All state diagrams being with an initial state of the object.  This is the state of the object when it is created.  After the initial state the object begins changing states.  Conditions based on the activities can determine what the next state the object transitions to.

Below is an example of a state diagram might look like for an Order object.  When the object enters the Checking state it performs the activity "check items."  After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available].  If an item is not available the order is canceled.  If all items are available then the order is dispatched.  When the object transitions to the Dispatching state the activity "initiate delivery" is performed.  After this activity is complete the object transitions again to the Delivered state.

State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to the a certain state.  Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state.  This helps make the state diagram easier to read.
The diagram below shows a super-state.  Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown  from a super-state named Active to the state Cancel.  By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state.