Requirements describe what a system should do.

Class diagrams describe what the system contains.

The next question is:

How do all of those pieces work together to accomplish a task?

A Sequence Diagram answers this question.

Sequence diagrams model how objects communicate while completing a particular activity. Rather than focusing on the overall structure of the software, they describe the sequence of interactions that occurs as a user completes a specific task.

Why Use Sequence Diagrams?

Modern software systems rarely complete a task using a single object.

Consider a user logging into a website.

Although the user sees only a login screen, the system may:

• receive the login credentials,
• validate the information,
• retrieve user information from a database,
• verify permissions,
• create a secure session, and
• display the appropriate dashboard.

Each of these actions may involve several different objects working together.

A sequence diagram helps us understand these interactions before implementation begins.

Like every prototype introduced in this textbook, sequence diagrams encourage discussion, reveal missing design decisions, and improve communication within the development team.

What Is A Sequence Diagram?

A Sequence Diagram is a UML diagram that illustrates how objects exchange messages while completing a particular task.

Unlike a class diagram, which presents a static view of the system, a sequence diagram represents behaviour over time.

Time progresses from the top of the page toward the bottom.

Each horizontal message represents one interaction between two objects.

Reading the diagram from top to bottom tells the story of how the task is completed.

Choosing A Scenario

Sequence diagrams are usually developed from an existing use case.

For example, you might create sequence diagrams for:

• Logging into the system
• Creating a user account
• Reserving a tennis court
• Submitting an expense claim
• Booking an appointment

Each sequence diagram should focus on one specific scenario.

Trying to describe every possible interaction in a single diagram quickly becomes confusing.

Instead, create separate diagrams for different use cases or for important alternative flows.

The Main Parts Of A Sequence Diagram

Although sequence diagrams can become quite detailed, most contain only a few key elements.

Actors

Many sequence diagrams begin with an actor.

The actor represents the person or external system that initiates the interaction.

For example:

• User
• Administrator
• Customer
• Payment Gateway

The actor begins the sequence by requesting that the system perform some task.

Objects

Across the top of the diagram are the objects that participate in the interaction.

These often correspond directly to classes identified in your class diagram.

For example:

• Login Screen
• Authentication Service
• User Database
• Session Manager

Each object is represented by a vertical dashed line called a lifeline, indicating that it exists throughout the interaction.

Messages

Objects communicate by sending messages to one another.

A message represents a request for another object to perform some action.

Examples include:

• validateCredentials()
• retrieveUser()
• createSession()
• displayDashboard()

Messages are drawn as arrows between lifelines.

Together, these arrows describe the order in which the system performs its work.

Activation

When an object is actively processing a request, a narrow rectangle is drawn on its lifeline.

This activation represents the period during which the object is carrying out some work before passing control elsewhere.

Although activation bars are a standard UML notation, the important concept is that only one object is performing a particular action at any given moment.

Reading A Sequence Diagram

Suppose a user logs into a system.

A simplified interaction might proceed as follows:

1. The user submits a username and password.
2. The login screen sends the credentials to the authentication service.
3. The authentication service requests the user’s information from the database.
4. The database returns the user record.
5. The authentication service validates the password.
6. If successful, a new user session is created.
7. The dashboard is displayed to the user.

Notice that every step describes communication between objects.

Unlike a use case, which alternates between the actor and the system, a sequence diagram shows the individual components inside the system working together.

Developing A Sequence Diagram

A useful approach is to begin with a completed use case.

Then ask:

Which objects must work together to complete each step?

For every interaction:

1. Identify who initiates the action.
2. Determine which object receives the request.
3. Decide whether additional objects are needed.
4. Continue following the flow until the use case reaches a stable conclusion.

As with other prototypes, sequence diagrams rarely emerge perfectly on the first attempt.

Creating the diagram often reveals missing classes, forgotten operations, or additional requirements that should be discussed with your team.

Keeping Diagrams Manageable

As systems become larger, sequence diagrams can quickly become difficult to read.

Several guidelines help keep them manageable.

• Focus on one use case at a time.
• Avoid including unrelated functionality.
• Use meaningful object names.
• Label messages clearly.
• Create separate diagrams for important alternative flows rather than forcing everything into a single figure.

Smaller, focused diagrams are almost always easier to understand than one extremely large diagram.

Sequence Diagrams And Other Design Tools

Sequence diagrams do not exist in isolation.

They build directly on work completed earlier in the design process.

Requirements define what the system must accomplish.

Use cases describe the interaction between users and the system.

Class diagrams identify the objects involved.

Sequence diagrams then show how those objects collaborate to complete the required behaviour.

Together, these tools provide complementary views of the same software system.

Looking Ahead

Class diagrams help us understand the structure of a software system.

Sequence diagrams help us understand its behaviour.

By combining these different perspectives, software teams develop a much richer understanding of the systems they are designing before implementation begins.

As you continue through CIS3750, you’ll use these diagrams together to refine your designs, communicate ideas with your teammates, and create software that more effectively meets the needs of your community partner.