A state diagram consists of states, transitions, events, and activities. You use state diagrams to illustrate the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration. State diagrams emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.
You use state machines to model the behavior of any modeling element, although, most commonly, that will be a class, a use case, or an entire system which focuses on the event-ordered behavior of an object, which is especially useful in modeling reactive systems.
The Figure below shows the key elements of a state diagram in UML. This notation permits you to visualize the behavior of an object in a way that lets you emphasize the important elements in the life of that object.
A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events.
A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
An event is the specification of a significant occurrence that has a location in time and space. In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition.
A guard condition is evaluated after the trigger event for the transition occurs. It is possible to have multiple transitions from the same source state and with the same event trigger, as long as the guard conditions don’t overlap. A guard condition is evaluated just once for the transition at the time the event occurs. The boolean expression may reference the state of the object.
A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter the second state when a specified event occurs and specified conditions are satisfied. Activity is an ongoing non-atomic execution within a state machine.
An action is an executable atomic computation that results in a change in the state of the model or the return of a value.
Graphically, a state is rendered as a rectangle with rounded corners. A transition is rendered as a solid directed line.
In UML semantics, Activity Diagrams are reducible to State Machines with some additional notations that the vertices represent the carrying out of an activity and the edges represent the transition on the completion of one collection of activities to the commencement of a new collection of activities.
Activity Diagrams capture high-level activities aspects. In particular, it is possible to represent concurrency and coordination in Activity Diagrams.
Take a look at the Activity Diagram which models the flow of actions for an incident. Such an Activity Diagram focuses on the flow of data within a system.
In State Machines the vertices represent states of an object in a class and edges represent occurrences of events. The additional notations capture how activities are coordinated. Objects have behaviors and states. The state of an object depends on its current activity or condition. A State Machine Diagrams shows the possible states of the object and the transitions that cause a change in state.
Take a look at the State Machine Diagram below. It models the transitioning of states for an incident. Such a state diagram focuses on a set of attributes of a single abstraction (object, system).
Suppose you’re designing a toaster. You would build plenty of UML diagrams, but here only state diagrams will be of our interest. Suppose we are interested to model
“What are the steps of making a toast?”
First of all we must turn on the toaster, put in the bread and wait for several minutes to bake it. The initial state diagram is shown below:
Let’s refine the state machine example above to prevent burning out the bread, heater of the toaster must produce heat in temperature interval (upper and lower temperature limits).
With this new state, the extended state diagram will be:
We can partition working and idle as state and encapsulate the detailed state inside each of them. The transition will be made between working and ideal state:
Sub-states in working and idle states are very similar. Both of them measure and compare states, but differentiates in the process of temperature comparison.
In the toaster example above:
Concurrent Sub-states are independent and can complete at different times and each sub-state is separated from the others by a dashed line
Unless otherwise specified, when a transition enters a composite state, the action of the nested state machine starts over again at the initial state (unless the transition targets a sub-state directly). History states allow the state machine to re-enter the last sub-state that was active prior to leaving the composite state. A history state is indicated by a circle with an H inside it that allows the re-entering of a composite state at the point which it was last left.
An example of history state usage is presented in Diagram below.
You can associate a state machine with a class, which is especially useful when modeling event-driven systems or when modeling the lifetime of a class. In these cases, you can also show the state of this machine for a given object at a given time. For example, as class shows below, the object c (an instance of the class Phone) is indicated in the state WaitingForAnswer, a named state defined in the state machine for Phone.
