Sequences and States

Objective

1. Use sequences to model flow of events.
2. Use state machines to encode state and apply transitions.

Sequences

Sequence diagrams are a type of interaction diagram that visualize the sequence of messages exchanged between objects or components within a system over time. They help illustrate how objects interact and the temporal order of these interactions, making them particularly useful for understanding both high-level system behavior and intricate object interactions.

Sequence diagrams are widely used in software engineering, particularly for modeling the dynamic behavior of complex systems such as user interfaces, web applications, or distributed systems. They are commonly applied during the design and analysis phases of software development, facilitating the planning, validation, and refinement of interactions between system components. Additionally, they assist in communicating design choices among stakeholders and serve as a foundation for testing.

Lifelines

Lifelines represent the individual objects or actors involved in the interaction. Each lifeline is depicted as a vertical dashed line extending from the top of the diagram, representing the object’s lifespan throughout the interaction. Time progresses from top to bottom, and the position of the lifeline conveys the relative presence and involvement of each object over the course of the system’s operation.

Lifelines can represent both external actors (such as users or external systems) and internal objects within the system. An actor’s lifeline typically begins with the initiation of an interaction, while an object’s lifeline may start when it is instantiated.

Messages

Messages represent the communication between objects and are shown as arrows connecting the lifelines. The message name is placed above the arrow to describe the specific action or request being made. There are different types of messages in sequence diagrams, each indicating a specific interaction.

Synchronous

A solid line with a filled arrowhead. The sender waits for the receiver to process the message and return control. It is used when an operation must complete before the next one begins.

Asynchronous

A solid line with an open arrowhead. The sender does not wait for the receiver to process the message. Both the sender and receiver can continue independently after the message is sent.

Reply

A dashed line with an open arrowhead. It shows the return of control from the receiver back to the sender, indicating that the requested operation has completed. This message is typically used after a synchronous message.

Create

A dashed line with a solid arrowhead, indicating that a new object is being created. It starts a new lifeline for the receiving object.

Destroy

A dashed line with a solid arrowhead, followed by an at the end of the lifeline. It indicates that the receiving object is being destroyed or terminated at that point in the interaction.

Self

A looped arrow returning to the same lifeline. It shows that an object is calling one of its own methods or performing an internal action.

Found

An arrow starting from an open circle at the edge of the diagram. This message indicates that the interaction starts from an unknown or unspecified source outside the system.

Lost

An arrow ending with an open circle at the edge of the diagram. It indicates that a message is sent but the recipient is outside the system or not specified.

Time Signal

Typically marked with a clock symbol, it represents a message that is triggered by a specific time or timing event, for example, a timeout or scheduled event.

These message types provide nuanced ways to represent complex system interactions, ensuring clarity in the modeling of both internal and external behaviors.

Activation Elements

Activation Intervals

Activation intervals, also known as activation bars, are vertical rectangular boxes on top of the lifeline that represent the time during which an object is actively processing or executing an operation. These bars visually depict when an object is involved in the interaction, making it clear when and for how long an object is engaged in sending or receiving messages.

Execution Occurrences

Execution occurrences, also called execution specifications, are thin rectangles on the lifeline that indicate when an object is performing a specific action or operation. They are typically used alongside activation intervals but more explicitly focus on a particular point in time when an object is engaged in an execution.

Destruction Occurrences

Destruction occurrences represent the termination of an object’s life in a sequence diagram, typically marked with an at the bottom of a lifeline. This notation shows that an object is no longer part of the interaction, often used when the object is deleted or its role ends after a specific operation.

Interaction Organization

Gates

Gates act as entry and exit points for messages into or out of a fragment or diagram. They are useful in breaking down complex diagrams by organizing related interactions and maintaining clarity. Gates can represent messages sent to or received from external systems or actors, making them vital for handling multi-layered or distributed systems.

Reference Fragments

Reference fragments (ref frames) are used to reference another sequence diagram from within the current diagram. Similar to interaction uses, ref frames simplify large diagrams by encapsulating commonly used interactions into a separate diagram. The referenced diagram is displayed in a smaller frame with the ref label, indicating that the interaction continues in another diagram.

Interaction Fragments

Interaction fragments are powerful mechanisms for organizing and representing complex interactions within a sequence diagram. They allow sub-interactions to be encapsulated and managed efficiently, making the diagram easier to comprehend and modify.

Interaction Use

An interaction use fragment references another sequence diagram, effectively allowing you to call or reuse a pre-defined sequence of interactions within a larger diagram. This technique is particularly useful for simplifying large, complex diagrams by avoiding redundancy and promoting reusability.

Combined Fragments

Combined fragments allow for modeling more complex scenarios through interaction operators, such as:

• alt (Alternative): Represents conditional branches, allowing you to model if-else logic within the interaction.
• opt (Optional): Denotes an optional interaction that only occurs under certain conditions.
• loop: Models iterative behavior, where a set of messages is repeated a specific number of times or until a condition is met.
• break: Represents an interruptive condition that exits the interaction prematurely.
• par (Parallel): Models parallel processing, where multiple messages can be sent simultaneously across different lifelines.
• strict: Ensures strict sequencing of messages within the fragment.

Constraints and Conditions

State Invariants

State invariants are constraints or conditions that must hold true at a specific point in the sequence diagram. They are typically placed on a lifeline between two messages, representing a condition that the object must satisfy before the next interaction occurs. State invariants are useful for enforcing specific system states or validating certain behaviors during the interaction.

Duration and Timing

Duration constraints indicate how long an interaction between two objects should take. This is shown with a double-headed arrow labeled with a time duration between two messages. Timing constraints define conditions related to the timing of message exchanges and can be used to specify deadlines, maximum allowable delays, or synchronization requirements.

Exercise 1

Design a sequence diagram for a primary flow and an alternate flow of your choice. Use at least 3 Entity-Control-Boundary (ECB) stereotypes, include at least 1 actor, 4 objects, and 10 messages, and at least one sequence sub-diagram as an interaction use (reference).

State Machines

State machines, also known as statecharts or state diagrams, are used to model the behavior of a system by showing the states and transitions between those states. They are particularly useful for representing the dynamic behavior of an object over time, including the conditions that cause state transitions and the actions that occur during or after the transition. This is particularly useful for event-driven systems like embedded systems, protocols, or user interfaces. State diagrams are most commonly used for system behavior modeling, object lifecycle tracking, concurrency and synchronization, and error handling.

State diagrams track the entire lifecycle of an object, illustrating how the object evolves through different stages. They help visualize complex systems where objects may have concurrent states or where certain states can only be entered after multiple conditions are fulfilled. This is helpful when you need to monitor object states in real-time systems. State diagrams are also useful for modeling error conditions and recovery strategies.

States

Initial and Final States

The initial state is the starting point of the object when it is instantiated. It is represented as a filled black circle The final state is the end of the object’s lifecycle or the completion of its behavior. It is represented as a circle with a surrounding ring.

Pseudostates

Pseudostates are used to model different types of transitions and behaviors in a state machine. They are not real states but represent specific conditions or actions that occur during the transition between states.

Composite States

A composite state is a state that contains other states (substates) and transitions. This allows for hierarchical representation and helps model complex behaviors.

History States

History states are used to remember the last active substate of a composite state when it was interrupted or exited. There are shallow and deep history states.

Orthogonal Regions

Orthogonal regions are regions within a composite state that represent independent, concurrent activities. They allow a system or object to be in multiple states simultaneously, with each orthogonal region having its own state machine that operates independently of others.

Transitions

A transition is the movement from one state to another, triggered by events. It shows how the system or object changes states in response to an external event or internal condition.

Events

An event is a trigger that causes a transition between states. It can be an external input, a time-based condition, or a specific change in system data.

Guards

Guard conditions are boolean expressions that must evaluate to true for a transition to occur. They act as a gatekeeper for transitions.

Actions

Actions are activities that occur as a result of a transition or while the system is in a state. These could be internal operations, interactions with other objects, or external outputs.

Self-Transitions

A self-transition occurs when an object transitions from a state back to the same state. It may still perform some internal actions during this transition.

Fork and Join

A fork splits one state into two or more parallel states. A join combines multiple parallel states into one state.

State diagrams (FSMs) are the basic type of state machine where an object can be in one state at a time. Each state is connected to other states through transitions. States are represented by rounded rectangles and the transitions between states are shown as arrows. Statecharts (Harel charts) extend the basic state diagrams to include substates, compound states, and more complex behaviors. They are more expressive and can represent hierarchical and concurrent behaviors.

Exercise 2

Design a state machine for a traffic light. Include the following states: red, amber, and green.

Exercise 3

Design a state machine for an elevator. Include the following states: idle, moving, opening, closing, maintenance, and out of service.

Exercise 4

Design a state machine for a vending machine. Include the following states: idle, selecting, dispensing, maintenance, and out of service.

Structure

Resources

• Visual Paradigm: Choosing the right diagram: Sequence or activity for use case elaboration (opens in a new tab), Numbering sequence messages (opens in a new tab)
• Activity vs. sequence diagrams: What’s the difference? (opens in a new tab)
• Differences between sequence diagram and activity diagram (opens in a new tab)
• Awesome finite state machines (opens in a new tab)
• Sequence diagram (opens in a new tab), State diagram (opens in a new tab)
• UML diagrams (opens in a new tab)