Sequence Diagram is still alive!

In the modern industry, one of the most crucial components of Business Analysis (BA) is the Sequence Diagram. It is considered one of the most challenging parts of the Unified Modeling Language (UML), yet it is quite effective and necessary for business analysis and planning.

To create a Sequence Diagram, several components are required:

• In-depth analysis and exploration of a specific topic.
• Understanding the principles and rules of diagram construction.
• Practice: the more, the better the result will be in the end.

Even experts with years of experience sometimes make mistakes, primarily related to logic when dealing with the complexity of the Sequence Diagram as a tool for comprehensive Business Analysis (BA). Such mistakes are normal, as they provide opportunities for learning and self-improvement.

Therefore, there’s no need to worry if you can’t immediately sit down and draw a Sequence Diagram. Learn its principles, basics, practice, and enhance your knowledge. It will get easier with time, especially since our specialists have prepared an article detailing this type of diagram for you.

The material covers the following topics:

• What a Sequence Diagram is in general.
• The elements and rules within it.
• The optimal situations for using this diagram.
• The rules for constructing a Sequence Diagram.
• Why a Sequence Diagram is more beneficial than Activity and Use Case diagrams.
• The advantages of Sequence Diagrams for projects in an active development phase.

We hope that the information provided in this article will be useful to you.

Briefly about the main points: the goals and purposes of Sequence Diagrams.

In any industry, work begins with the formation of value. This applies to the value of products, services, various upgrades, and so on. The construction of a Sequence Diagram in the context of Business Analysis is no exception. Therefore, a professional should understand for whom and, in general, why they are creating this diagram.

To initiate modeling, it’s necessary to thoroughly study:

• Canon,
• Rules,
• Templates,
• Specifics,
• Standards of other diagram systems.

Additionally, one needs to learn to experiment, not be afraid of challenges, and be open to potential scenarios where you may have to combine several types of visualization for analysis.

The key goal of a Sequence Diagram is to convey ideas (thoughts, proofs) to the team and the client as quickly as possible. In achieving this, all methods are valid. It’s important to disregard rules or conventions if needed – we do it without hesitation.
Next, let’s discuss when it’s appropriate to use a Sequence Diagram, why Business Analysis experts may not favour it, and how to effectively apply this type of modelling to address the needs of a company or client.

What is a Sequence Diagram?

In the canonical sense, it is a model of a sequence where objects are arranged chronologically. In the field of Business Analysis, the concept of a Sequence Diagram takes on new nuances and looks as follows:

• It is a model of a sequence, but in it, objects (or processes) interact.
• The diagram includes classes and activities that also interact.
• The overall concept demonstrates the principle of interaction, sequence, causes/effects, etc.
• Sequence steps are variable and can change under certain conditions.
• The entire diagram plays the role of a specific scenario, modelling variations in events, actions, and their consequences.

In general, a Sequence Diagram depicts the activity of specific objects within defined time intervals (both long-term periods and short ones, such as development sprints). The emphasis is on time rather than the activities of classes, and each diagram is oriented towards a single Use Case.

How does the architecture of a Sequence Diagram look in practice (simplified)

Let’s break down the key elements:

1. Object (Actor): This is not necessarily a physical entity; it can be program classes, specific functions, or system modules.
2. Lifeline: Each object has this definition, reflecting the actor’s level of involvement in a Use Case or usage scenarios.
3. Activation Box (Call): This block shows how long an object will exist in the diagram. To initiate the block, a specific trigger (condition) and call are used, activating the next action.
4. Synchronous Messages: When there is a specific request and an expected response, the process will pause until that response is received. Such a call is executed only once.
5. Asynchronous Messages: A command or information entry into another object without waiting for feedback. There can be an unlimited number of such requests (regardless of the order of object priority).
6. Responses: There are also two types, namely synchronous and asynchronous. In the first case, the system waits for confirmation to proceed with the action, while in the second case, it simply logs the actions without disrupting the process of resource utilization.
7. Termination (end of the object’s lifecycle): Some actors have only one specific function, after the completion of which they become unnecessary and need to be closed.

As you can see, a Sequence Diagram is modeled only in cases when the described fragment is 100% functional and free of errors. A Sequence Diagram is never created to visualize errors. However, this statement is not always true.

Nuances of Sequence Diagram

We offer you a more detailed example of a diagram that illustrates how similar BA models can be ambiguous.

It consists of the following elements:

• Action Description: A brief explanation of the user’s action algorithm (in this case, searching for something). It also includes the main sequence of events, the algorithm that the system should follow in response to the request.
• Alternative Scenario: A somewhat atypical solution for this type of diagram, as it describes an alternative to the main algorithm in case a critical error was made when formulating the request.
• User as a Trigger for Object Invocation: The key actor initiating the data processing process, sequentially activating several objects and manipulating them.
• Four Actors: These include search and search results pages, a catalog (database), and search results. They are all interconnected and actively exchange requests/responses.
• Requests/Responses: Interactions between actors aiming to specify what the user intended and to find the information they need.

Specifically, in this case, two system operation algorithms are considered: one when the author of the book is entered in the search, and the other when such information is absent.
In this scenario, alternatives are used, meaning conditions under which the system can execute a different algorithm to provide relevant results for the query.

In addition to the example provided, in a Sequence Diagram, there are the following concepts:

• LOOP: Represents a loop, i.e., an action that is continuously performed at specific intervals in the actor’s lifecycle.
• OPT: Stands for optional algorithm, where the user can choose how a particular process will be executed (a typical example is search filters).
• ALT: Describes a scenario where in the classical algorithm an error may occur, but it won’t be visible to the user. Instead, it triggers an alternative system scenario to mitigate this error.

However, the more intricate the diagram, the harder it is to read, and it becomes less user-friendly for stakeholders and the team. That’s why, when creating any diagram, not just a Sequence Diagram, it is recommended to simplify it as much as possible and describe only one use case.

Generally speaking, models of this kind are typically oriented towards describing (schematically visualizing) a small fragment (conditionally – the functionality) of the software. Therefore, within a project, there may be even hundreds of such diagrams, but each of them will provide a highly detailed description of a specific component, usually an action and its result.

The difference between Sequence and Activity diagrams: each has its own use case.

If you work in the field of Business Analysis (BA), you often face the question of which diagram to choose to represent a particular component. Yes, there are numerous options, but the most common choice comes down to Sequence and Activity diagrams. Let’s try to understand when and which one is more appropriate.
Take a close look at the table:

As you can see, both diagrams fundamentally describe different aspects. Sequence diagrams focus on actions over a period of time, while activity diagrams concentrate on depicting the overall functioning of the system (functions) in a general sense.

Regarding the scope of visualization, even the examples provided in the material do not fully capture the extent of a classic Sequence Diagram. Typically, the number of objects in such a visualization can be up to 100, along with the calls between them.

The relevance of Sequence Diagrams in 2023 is driven by the increasing demand for Business Analysis (BA), but in a more classical understanding of the term. To elaborate: until recently, the role of BA was considered almost a hybrid, where the expert acted as a sort of translator between the business and technical implementers.

Now, this role has returned to its original form, transforming into a foundational BA with traditional tools. However, it doesn’t mean that the expert shouldn’t have an understanding of technical matters. To some extent, they should.

Pros, cons, and pitfalls of Sequence Diagrams.

This type of diagram is not a panacea for addressing every aspect of the current BA needs, but they are quite versatile in the sense that you can specify a particular fragment. In other words, these diagrams are concise, comprehensible, and detailed enough.

Among the key advantages of Sequence Diagrams are:

• Visualization of actions in chronological order: Each call and response has its moment in the lifecycle of a specific actor. You can show when, how, and where a request should arrive, what action will be performed, and what the result will be. Additionally, you can indicate alternatives or optional algorithm variations.
• Visualization of sequence (steps): Schematic representation of the interaction model with a connection to the timeline allows tracking what and in what order is executed at a given stage. It illustrates the direction of the call, when it is directed, what precedes it, and what happens next.
• Visualization of alternatives: This diagram can be used as a canvas within one User Case or divided into smaller parts describing highly specified actions. Using OPT or ALT, you can show potential variants and how the system should behave in such cases.

That covers the bright sides of Sequence Diagrams. However, even ideal systems have drawbacks, so it’s worth paying attention to these aspects.

Regarding the drawbacks of Sequence Diagrams:

• Cumbersome Nature: Each diagram models a specific use case scenario, no more. Therefore, there can be a considerable number of such visualizations, automatically increasing the workload required for detailed modeling of everything. The flip side is that these diagrams may not always be necessary, risking a potential waste of time.
• Contextuality: Traditionally, these diagrams were used for modeling system flows. As of 2023, they might be considered less suitable for BA (though this directly depends on the company). Thus, there’s a risk that stakeholders may not appreciate such a model specifically from a BA perspective or may request a change to a more optimal diagram type.
• Complexity: Modeling these diagrams requires practice—lots of it—along with theory and more practice. Understanding the basics, canons, standards, adhering to them, and being able to go beyond traditional boundaries are crucial. Therefore, the entry barrier for engaging in the process of modeling Sequence Diagrams is quite high, posing challenges for BAs, especially in the early stages of their careers.

In summary, it’s worth noting that Sequence Diagrams are somewhat situational but effective, especially if they are well-received by all stakeholders. The pros and cons are also somewhat conditional, as not all experts may agree with them.

Having explored the specifics of Sequence Diagrams and their differences from Activity Diagrams, we can now move on to the key question: what to choose?

What to use for BA, Sequence Diagrams, or Activity Diagrams?

As you’ve already gathered from the material, there is a significant difference between these types of diagrams, specifically in terms of the aspects of development they cover and their characteristics. If Sequence Diagrams focus on describing the chronological order and linking actions to actors within a specific timeframe, Activity Diagrams emphasize the process and activities.

Regarding the choice of diagram type for BA needs, it’s quite situational. Primarily, it depends on the current task and its specifics. If the goal is to elucidate a specific interaction algorithm among components with a detailed breakdown of the sequence of requests and action intervals in the lifecycle of entities, then using a Sequence Diagram is optimal. This is under the condition that you are describing a particular process within a short scenario.

For example:

• User login, where there is a well-specified data exchange in the system.
• Search query, where there is specificity in both the call and the responses.
• Transaction authentication, where confirmation of access to funds and their availability is required.

In fact, there can be thousands of such cases, and the ones mentioned are just a typical example of where Sequence Diagrams are most commonly applied.

Activity Diagram is needed for modeling the interaction process among multiple actors within multiple scenarios. It is suitable for situations where it is not practical to detail a specific algorithm in the lifecycle of an entity, but instead, it is more beneficial to look at the process on a broader scale.

As for where and when to use one or the other diagram model, the answer is situational, considering the project’s needs, stakeholder requirements, and so on.

The principle of choosing Sequence Diagram and several recommendations for optimizing the visualization development process.

Before starting the modeling of any diagram, make sure that it meets your needs. To do this, you can answer a series of questions, such as:

• What am I modeling this for?
• Was I told to do this, or did I decide to do it myself?
• Are there any other reasons, hypothetically – customer requirements?

At this stage, you will already understand which specific diagram you need and how best to implement it. It is important that all stakeholders perceive it, and know how to read and understand such graphs.

In addition, it is important that someone checks your diagram before presenting it to the audience. Primarily for logical gaps and overall composition and detailing quality. This will help eliminate the “tunnel vision” effect and fill in logical gaps in the diagram.

Moreover, another recommendation: involve architects, developers, and QA specialists in reviewing your diagrams. They will help you break down the system and find optimization methods. Whether it’s reducing, expanding, or transforming, the crucial thing is that you can present the final iteration to all stakeholders, who will not find any nuances in it.

Another piece of advice: don’t stretch your diagram too much. An unwritten rule of Sequence Diagram modeling suggests that visualization should fit on a single A4 sheet. If necessary, use multiple levels of diagrams with references. This may take a bit more time, but you will get a concise and detailed result.

In conclusion

The Sequence Diagram is a type of visualization in UML that, in the context of Business Analysis (BA), allows the creation of clear and detailed charts suitable for working with clients and conveying ideas to the technical department.

These diagrams always represent a single User Case and are relatively short. However, their number can be significant, especially in large projects or for branching functionality. The distinctive feature of these diagrams lies in describing a specific action in chronological order and focusing on exclusively positive outcomes. Only in certain cases is the Sequence Diagram used to describe errors or inherently faulty algorithms as a whole.

The potential of these diagrams is particularly evident where there is a need to illustrate a scenario, such as the application of a conditional action and the expected behaviour of the system in response. Regarding other potential algorithms, Sequence Diagrams cover a substantial portion of project requirements. Therefore, it is worthwhile for Business Analysts to become proficient in this type of modeling.

To learn new techniques for working with Sequence Diagrams, you should join the E5 community, consisting of prominent experts in the IT industry, analysts, and marketers. Here, you will find not only up-to-date knowledge but also experience that will help you develop effectively.

Training sessions, courses, meetings, and many other relevant activities await you on the portal. Join and get to know your potential together with E5.