UML diagrams are classified into:

  • Static model: defines the structure of classes and objects.
  • Dynamic model: defines the interrelationships between objects.
  • Implementation model: describes the software in terms of components and application.

When an object changes its behavior over time, it is said to have states.

In real-time applications, state diagrams are very important.

We can find other languages such as PetriNets and SDL (Specification and Description Language).

Concepts

  • Objects and systems are always in a state.
  • The current state of an object or system determines its future.
  • State changes are possible; in UML we call them transitions.
  • The transition between states is due to an event.
  • State diagrams are used to model the (complex) behavior of objects and systems.
  • The state diagram is documented in the analysis phase.
  • Recently, Harel statecharts have been incorporated into UML, allowing an object or system to be in two states at once.

Notation

States are represented by rounded rectangles:

*

The state name cannot be repeated anywhere in the diagram. It must be unique, even though an object can reach a particular state multiple times during its lifespan.

They can have three compartments:

  • The first is the state name.
  • The second is for characteristic values of the system or object when it is in that state.
  • The third is for actions executed upon entering, while in, or upon exiting the state.

The initial state is symbolized by a solid black circle and the final state by a black-and-white circle.

Transitions are represented by arrows going from one state to another:

The name of the event triggering the transition is written next to the arrow.

A transition may carry an action, which is indicated with /action.

An action may be preceded by a guard condition, represented as [condition]. The text accompanying a transition has the following format:

event [condition] / action.

We can have one, several, or no actions, and their order is important because it specifies the execution order.

An object's state is determined by the values of its attributes. State diagrams help us specify all the states an object can pass through over its lifespan.

For example, the process of possible states for an email object.

The dynamics of a system are determined by:

  • All the possible states that its objects can have.
  • All possible event sequences.
  • All possible transitions from one state to another as a result of events affecting the objects.

We can use a state diagram to model system dynamics. For example:

A ticket vending machine.

Another example would be:

The example shows a state diagram modeling much of the "login" process for an online banking system. To log in to the system, a social security number (SSN) and a personal identification number (PIN) must be entered, which then have to be validated. The logging process can be factorized into four system states:

  • GettingSSN.
  • GettingPIN.
  • Validating.
  • Rejecting.

From each state, a complete set of transitions is obtained that determines the next state.

There are two self-transitions: GettingSSN and GettingPIN. In the Validating state, the object does not wait for an event to trigger a transition, but executes an activity instead. The outcome of this activity is determined by the state itself.

State: a given situation during the life of an object. It can also be the duration of an interaction during which a condition is met, an action is carried out, or an event is awaited. It does not necessarily correspond to a single instant in time (it can have a duration).

Simple transition: a simple transition consists of an object or interaction passing from one state to another, which can even be the same state. The transition occurs when an event plus a "guard" condition are present. Every state can have incoming and outgoing transitions.

Internal transition: pseudo-transitions in which there is no state change. They serve to specify actions that must be executed in response to events that do not cause any state change in the object.

Action: the specification of an atomic process (it either executes completely or not at all). One or more actions can be executed from a transition. Actions can be described using procedures.

Signals: objects can receive operation requests or signals via messages. Signals differ from operations in that they do not perform any processing and can only produce events. In turn, events trigger transitions that are capable of calling actions.

Signal → event → transitions → actions

Events: occurrences that trigger transitions from one state to another and can also cause certain actions to occur. Events are not bound to any specific object, but are part of the package. Each event has a name and parameters. When an event occurs, it must be handled; otherwise it is lost, unless declared deferred. Events can be synchronous (the transmitter must coordinate with the receiver before sending data) or asynchronous.

Types of events:

  • Call events: occur when an operation of an object is called.
  • Signal events: occur when a signal is received.
  • Change events: a notification that a specific condition has occurred.
  • Time events: represent that either a certain amount of time has elapsed or a specific time has arrived.

There are events called internal events, which are pseudo-events because they are bound to a state rather than a transition. They serve to trigger actions that are not linked to any state change. They can be entry, exit, or do-activity (action):

  • Entry events occur when the object enters the corresponding state. They have no parameters or guard and are identified by the word "entry".
  • Exit events occur upon exiting the state and are identified by the word "exit".
  • Do-activity events specify actions generated when entering a specific state, which stop the moment it exits. They are declared with the word "do".

The signature of events will then depend on their type:

  • Call or signal: EventName(ParameterName:type_exp,...)*
  • Time: after(time_expression) After is the duration, or for example, when(time/date)
  • Change: when(boolean_expression)

Syntax

  • The guard condition is an expression that can evaluate to true or false, written in pseudocode, and determines when the event condition is satisfied.
  • The action is a pseudocode specification indicating which procedures must be executed when the event occurs.
  • A send expression takes the form destination '.' message'(argument', '...')', where destination can be one or more objects, and message is an operation of the destination object or a signal.

In UML, if we need to define a signal, we can do so as a class that has no operations or relationships (only inheritance), and whose attributes are only signal parameters (with the stereotype <<signal>>). Special behavior can be added to the class symbol to indicate which signals it is sensitive to.

An example would be:

insert_card[card=valid]/open_door^register_entry

Or

insert_card[card=valid]/defer open_door^register_entry.

(this one defers it for later: deferred)

Examples:

Complex transitions: An object or interaction can be in more than one state at the same time, and there can be more than one transition leaving a state and more than one transition entering a state. These are called complex transitions. An intermediate pseudo-state called synchronization or fork/join is used. Another example involving invoices:

Composite states: A composite state is one in which there are several possible substates, each of which can also be composite or simple. Every composite state has a substate diagram, which can be concurrent (at the same time) or sequential (one after another). It is represented like a simple state but with 2 compartments. Within a composite state, there can be transitions going from substate to substate; transitions entering or leaving the composite state; or transitions targeting a state history indicator, which is a pseudo-state that remembers the state it left. A transition can leave the history indicator toward a substate, which will be the destination if the transition takes place without having entered the composite state before.

Finally, there are transitions called stubbed transitions, whose destination or origin is a substate of a composite state that is not identified in the diagram.

Exercises

  1. Design the state diagram for a worker object, keeping in mind that the worker can be unemployed, active, or retired. The diagram must show the possible state changes of the worker when hired, retired, or when an employment relationship ends.
  1. In a library, we want to keep track of existing books, library members, and loans that have been made. There can be one or many copies of each book, and each copy must be listed in a catalog. Therefore, a copy can be added to or removed from the catalog. Each copy is in a possible state:
  1. Available
  1. On loan
  1. Unavailable

When making a loan, it will be necessary to validate that there is a member requesting it and that the copy is available. The actions to perform can be lending a book and returning it. Each element of the system will have its own attributes, which are left to the student's choice. For this scenario, create the UML class diagram involved and the state diagram of a copy.

3.a) Specify a state diagram for an automatic car gearbox. b) Specify a state diagram for a manual car gearbox.

  1. A European university has the following enrollment process: "When a student passes high school, they can pre-register for up to eight university options and take the entrance exams to pass them. If they do not pass, they can retake them the following year, but the pre-registration is retained. If they pass the entrance exams, they enter the place allocation process, and according to their grade, they are assigned their first option or one of the others. In the case of being allocated a place in their first option, they enter the July enrollment process. If assigned options 2 through 8, they enter the September enrollment process. If no place can be allocated, they remain in a 'not admitted' status. The July and September enrollment processes have two successive stages: enrolling and paying. If a student needs to enroll and fails to do so (deadline is August 1st and October 1st, respectively), they transition to 'not admitted'." Create the student state diagram, using an undetailed composite state diagram to represent the enrollment and payment process once a place is allocated. Improve the diagram by thoroughly specifying the state diagram with the substates included in the composite state diagram.

  1. A company is developing software to manage advertising campaigns. Represent the state diagram for the Campaign object, considering the following: We are considering the operation of the Campaign class. A campaign starts the moment personnel are assigned to it. At this point, a manager is assigned to the campaign and it becomes "commissioned". When authorization is given by the company and the client signs the contract, the campaign becomes active. Once the campaign ends, it is marked as completed and a final statement is made. Only if the client pays the full amount defined in the campaign contract does it become paid, and after 30 days have elapsed, it is archived and the assigned personnel and manager are unassigned.