April 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

State Diagram in UML

  • July 21, 2003
  • By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy
  • Send Email »
  • More Articles »

In the previous article, we saw what Object diagrams are, the notations to be used in Object diagrams, their significance, and how to make an Object diagram using Poseidon. We then made an Object diagram for our Courseware Management System. By the end of this article, you will know what a State diagram is, what its elements are, and you will be able to create State diagrams for your system.

The Basics

Until now, we have seen Use Cases, Class diagrams, and Object diagrams. These diagrams give an architectural and high-level view of a system. In a typical software life cycle, the business or functional domain experts define Use Case diagrams. The Class diagrams and Object diagrams are made by senior-level developers, with the help of system architects. Once this has been accomplished, and the system design and architecture is in place, these artifacts are passed on to the developer, who actually codes the system. All the above diagrams are static diagrams, which means that they help in visualizing what the elements of the complete system would be, but do not say anything about the flows any object of the system can have when an event occurs. Structural elements are used to depict static diagrams.

While coding, it is necessary to understand the details of the modes an Object of a Class can go through and its transitions at time intervals with the occurrence of any event or action.

State diagrams (also called State Chart diagrams) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with the help of Behavioral elements.

It is important to note that having a State diagram for your system is not a compulsion, but must be defined only on a need basis.

Defining a State diagram

Just as we define classes for a Class diagram, it is necessary to define the elements of a State diagram. Let us first see what the elements of a State diagram are.

Elements of a State diagram

A State diagram consists of the following behavioral elements:

Element and its DescriptionSymbol
Initial State: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is also called as a "pseudo state," where the state has no variables describing it further and no activities.
State: Represents the state of object at an instant of time. In a state diagram, there will be multiple of such symbols, one for each state of the Object we are discussing. Denoted by a rectangle with rounded corners and compartments (such as a class with rounded corners to denote an Object). We will describe this symbol in detail a little later.
Transition: An arrow indicating the Object to transition from one state to the other. The actual trigger event and action causing the transition are written beside the arrow, separated by a slash. Transitions that occur because the state completed an activity are called "triggerless" transitions. If an event has to occur after the completion of some event or action, the event or action is called the guard condition. The transition takes place after the guard condition occurs. This guard condition/event/action is depicted by square brackets around the description of the event/action (in other words, in the form of a Boolean expression).
History States: A flow may require that the object go into a trance, or wait state, and on the occurrence of a certain event, go back to the state it was in when it went into a wait state—its last active state. This is shown in a State diagram with the help of a letter H enclosed within a circle.
Event and Action: A trigger that causes a transition to occur is called as an event or action. Every transition need not occur due to the occurrence of an event or action directly related to the state that transitioned from one state to another. As described above, an event/action is written above a transition that it causes.
Signal: When an event causes a message/trigger to be sent to a state, that causes the transition; then, that message sent by the event is called a signal. Represented as a class with the <<Signal>> icon above the action/event.
Final State: The end of the state diagram is shown by a bull's eye symbol, also called a final state. A final state is another example of a pseudo state because it does not have any variable or action described.
Note: Changes in the system that occur, such as a background thread while the main process is running, are called "sub states." Even though it affects the main state, a sub state is not shown as a part of the main state. Hence, it is depicted as contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within a state, its Name, variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

Creating a State Diagram

Let us consider the scenario of traveling from station A to station B by the subway. Figure 6.2 would be a state diagram for such a scenario. It represents the normal flow. It does not show the sub states for this scenario.

Click here for a larger image.

Figure 6.2: an example flow in a state diagram

Things to Remember

Create state diagrams when the business logic for a particular flow is very complex, or needs greater understanding by the developer to be coded perfectly.

Arrange the states and transitions to ensure that the lines that cross each other are minimal. Criss-crossing lines are potential sources of confusion in conveying the diagram's meaning.

Page 1 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Sitemap | Contact Us

Rocket Fuel