How to Create a State Diagram

State Diagrams are commonly used when designing an object-oriented program. In this article, we’ll dig deeper into what a state diagram is and how to prepare one.

Figure 1: The State Diagram of a Door

Did you know that there are actually fourteen (14) types of UML diagrams? Well, now you do! Depending on the program you are developing, one or the other might suit your needs. For example, if your program heavily relies on class structures, you might benefit more from using a class diagram. On the other hand, if timing is very important for your program, you might want to use a timing diagram. Similarly, if your program is built of a limited number of states in which an object can exist, you will need a state diagram.

A state diagram is a type of diagram that is used to graphically represent the finite-state machines, otherwise called, automata. Automata is, on the other hand, basically a mathematical model of computation that is composed of a finite number of states, relations, and actions between those states.

A state diagram basically is the description of the states of each object within a computer program graphically and controls these states with different incidents. As an example, you can think of the program of an elevator. Someone who’s riding the elevator can be in four states: entering the elevator, waiting inside the elevator, leaving the elevator, and reaching the destination.

Activity diagrams area type of behavioral diagram just like the state diagrams and are very similar, but don’t be mistaken! These two differ in the sense that the state diagrams represent states while activity diagrams represent activities of an object.

State diagrams represent each state an object can exist in within its life cycle, and once the states end, so does the life cycle of that certain object. Therefore, we can also say that a state diagram will represent the life expectancy of an object. State diagrams include how an object switches from a state to another as well as what those states are, through a flow mechanism. A state can only exist when there’s an object present and that object is triggered by an incident. For example, for the housekeeper to be in the state of being inside the elevator, you’ll first need a “housekeeper” object and then affect it with some activities such as “getting inside the elevator” and “waiting inside the elevator”.

Similarly, let’s work on the example we see on Figure 1 above. Figure 1 holds the state diagram of a door. There, the states a door can be in are represented in boxes: open, closed, locked. The actions a door can take are written on arrows that connect said states: open, close, lock, unlock. Note how each state is not available at all instances: for example, you can’t lock the door if it’s open and you would need to close it first. See how, if necessary, we can add some conditions for an action to be taken as well: in order to close the door you must first ensure that the doorway is empty.

In summary, we can say that the three main goals of a state diagram are;

• Modelling the dynamic structure of a system
• Modelling the life cycle of a reagent system
• Modelling the different states an object exists within through it’s life cycle

In that sense, we can deduce that each state diagram:

• Represents the behavior of a single object
• Determines the order of events that will occur within the life cycle of said object

Figure 2: Basic State Diagram Structure

Through Figure 2 above we can deduce that while designing a state diagram we:

• Write the name of the state within rectangle boxes with oval corners
• Mark the start of an object’s life cycle with a whole dark circle, and the end of the program with a dark circle within a light circle.
• May or may not label the start and the end marks
• We represent the transition from one state to another with arrows. These arrows can have 3 attributes:

— Trigger: the cause of transition. It could be a signal, an incident, a change or simply the time passing by.

— Guard: The condition of which should be granted in order for the transition to be triggered.

— Effect: The action that will be invoked directly on the object as a result of the transition.

• We write over the transition arrow the attributes in a certain grammar: Trigger[Guard]/Effect (or otherwise Cause[Condition]/Result)
• When a state consists of actions, we represent it as shown above: With the state name separated from the actions within the same state box, and below the input and output actions are listed, each separated with a slash (“/”).
• When a state transitions into itself again, ie. when you’re waiting in an elevator for a minute and the waiting state refreshes itself in every two seconds, and we represent that case we make the transition arrow exit and arrive at the same state box.
• When a state covers one or more other states, we call it a composite state. And if a composite state includes another composite state, since it’s a bit too big to represent within the same state box, we simply create the state box with the state name and put a sign of “<>-<>” to note that the content will be drawn on another diagram.
• In some cases, you might want not to enter a state from the initializing point but from another: for example, within a soda automat you will first ask the customer to place some money in the machine but if they’ve already used the automat once and still got money in for another soda, you might want to skip the initializing step where the machine asks for money. In such cases, we create two initializing points: one for if there’s money in and one for if there isn’t. The original initializing point is represented with a filled in black circle whereas the second initializing point will be represented with a clear, empty circle.
• Exit points can be placed within many places in a program. In such cases, you should label all exit points with the same name.

Choice Pseudo-State

• When a single state can transition into two or more states based on the condition of transition (Guard), that’s called a Choice Pseudo-State.

Junction Pseudo-State

• When multiple transitions connect on one effect, we call that Junction Pseudo-State. In such states, one single junction can have one or more entering transitions and one or more exiting transitions. Some or all the transitions can have Guards. If, within a Junction Pseudo-State diagram, one entering transition breaks into multiple exiting transitions we call that a static conditioned branching and although it’s similar to a Choice Pseudo State, a Choice Pseudo-State will realize a dynamic conditional branch.

Terminate Pseudo-State

• In order to show that the lifecycle of the automata ends within some place inside the program, we use the terminate sign: s singe big “X”.

History States

• Imagine you’ve put your laundry in the washing machine and just as it was almost finished, the power went off. Now after the power is back, do you have to go through the entire washing process again? Not if you use the history state architecture. This type of architecture is used in order to keep a memory of a previous state in case of a power cut. While modeling, we simply create a transition that uses the case of “power cut” as a Guard and returns back to the “History” state (shown with an H above) within the original state. The history state will keep a log of the latest actions taken and through that, the machine will continue the program starting from the point the power went off.

Concurrent Regions

• Sometimes, within a single state, we might have multiple states that work simultaneously but independently. We call such states “Concurrent Regions”. In such cases, we create regions within the state for each concurrent state and we use fork and join instead choice and merge pseudo-states as shown at the example above, in order to model the fact that they are synchronized states. The example above shows how, when brakes are applied while driving, the front and rear brakes will work simultaneously but independently.