http://www.developer.com/

Back to article

State Diagram in UML


July 21, 2003

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.

Case Study—Courseware Management System

Because our Courseware Management System case study does not undergo any noticeable state changes, we will drill down our attention to the Course object in the system. Recall that a state diagram can be defined not only for a system or subsystem, but also for an object in the system.

Identifying states and events of the Course object

The Course object does undergo state changes during its lifecycle, right from course creation to deleting a course. Let us depict the Course object's lifecycle by using a state diagram to understand it better. The events that occur in the lifecycle of the Course object are listed below:

  • Create new course—add information for the course or update an existing course; update information for the course
  • Add topics—add topics to the course
  • Assign tutors—assign the available tutors for the course
  • Close—finished adding or updating the course

Consider the event of adding a new course to the Courseware Management System by the course administrator. The course administrator fills in the course information, thus initiating the creation of the Course object.

This event kicks off two events that change the state of the Course object, but are part of the new course event. These two events contained within the new course creation event are adding topics to the Course object and assigning tutors for the course. This results in the Topic objects getting associated with the Course object. Next, the course administrator may wish to assign tutors to teach the course by identifying the tutors that teach this course (based on their specialty/preferences) and checking the availability of the tutors for a given period of time.

This completes the lifecycle Course object until the time an update course event occurs.

Figure 6.3 shows the state diagram for the Course object. The state diagram depicts the changes in the state of the Course object as it transitions through the various events in its lifecycle.



Click here for a larger image.

Figure 6.3: the state diagram of the Course object

Summary

This article covered the first of the series of dynamic diagrams in UML. The state diagram is one of the simplest ways to represent the lifecycle of an entire system or a subsystem or even an object of a system. In the next article of this series, we will learn about Activity diagrams.

About the Authors

Mandar S. Chitnis, Lakshmi Ananthamurthy, and Pravin S. Tiwari are the co-founders of Novusware, Inc. They have co-authored the book Sans Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS Publishing, Oct 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems, Inc.

For any questions or queries regarding the article contents, please contact articlewriters@novusware.com.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date