This article provides an overview of UML sequence diagrams, explaining their notation, strengths, and limitations in modeling dynamic system interactions. It also demonstrates their practical application through a detailed case study of a doctor-patient examination workflow within a Hospital Management System, including a corresponding class diagram and pseudocode.
Alexander S. Ricciardi
January 31, 2025
Unified Modeling Language (UML) sequence diagrams are extensively used in Software Engineering (SE) to model the dynamic interactions of objects within systems. They illustrate a sequence of messages between objects within an interaction (IBM, 2021). This essay provides an overview of UML sequence diagrams and a UML sequence diagram, along with its related pseudocode and class diagram, illustrating a doctor-patient examination interactions workflow within a hospital management system.
UML Sequence Diagrams Overview
UML Sequence Diagrams “are usually based on UML class diagrams and are used primarily to show the interactions between objects (classes) in the chronological order in which those interactions occur” (Ricciardi, 2025, p. 1). They provide a dynamic illustration of the interactions between classes (objects) within a given period of time. In SE, they are used, in the problem space, to analyze and model system behavior from the actor’s (user’s) viewpoint (Unhelkar, 2018). In the solution space, they are used to illustrate interactions within a system in more detail, such as the sequence of the inquiry messages illustrating method calls, the parameter messages within those methods, and the value returned by those methods. The diagram uses a system of notation such as actors (classes), lifelines (timelines), arrows denoting messages or method calls between these lifelines, activation bars indicating method execution, and optional annotations for conditions, loops, or return values. These elements work together to illustrate the flow interaction within a system. The elements are arranged vertically to illustrate the chronological order of interactions and horizontally to reflect the direction of the interactions between objects. The figure below, Figure 1, depicts the main elements of a UML sequence diagram.
Figure 1
UML Sequence Diagram Notation Elements
Note: The figure illustrates the elements that can be found in UML sequence diagrams and how they may interact within a diagram. From “A Guide to UML Sequence Diagrams: Notation, Strengths, and Limitations” by Ricciardi (2025).
It is important to note that classes’ and objects' names are underlined and they can be illustrated by a stick figure for outside actors and internal actors can be encapsulated in a rectangle or represented by various circular shapes or icons representing specific stereotypes (e.g. boundary, control, and entity). A stereotype in UML “denotes a variation on an existing modeling element with the same form but with a modified intent” (Agile Modeling, 2023, p.1). Usually, stereotypes are represented using guillemets (<< >>) encapsulating a keyword; for instance, the specific stereotypes of a sequence diagram, represented by the circular shapes, are <<boundary>>, <<control>>, and <<entity>>. The table below, Table 1, provides detailed descriptions of the notation elements depicted in Figure 1, including the sequence diagram icon stereotypes.
Table 1
UML Sequence Diagram Notation Descriptions
Note: The table describes the notation elements that can be found in UML sequence diagrams. From “A Guide to UML Sequence Diagrams: Notation, Strengths, and Limitations” by Ricciardi (2025).
Sequence diagrams have advantages and disadvantages, they are well-suited for modeling the dynamic behavior of a system by illustrating interactions between different actors or classes over a period of time. They help identify missing elements in class diagrams and they can be used for documentation (Ricciardi, 2025). On the other hand, they struggle to represent parallel processes or complex conditional flows. This is especially true for parallel interactions, as the dynamic and sequential nature of sequence diagrams makes it difficult to depict concurrent events within a system. Furthermore, trying to illustrate multiple concurrent and complex conditional flows using frames (or fragments) in a single diagram can make it cluttered and ultimately it may require the generation of several additional sequence diagrams. See Table 2 for a list of the main advantages and disadvantages of sequence diagrams. To summarize UML sequence diagrams are useful for illustrating dynamic interactions of objects within a system that have their advantages and disadvantages. The next section of this paper explores a hospital management system UML sequence diagram, including its related pseudocode and a UML class diagram.
Table 2
Strengths and Limitations of UML Sequence Diagrams
Note: The table describes the main advantages and disadvantages of UML sequence diagrams.
Hospital Management System (HMS) is a digital application that helps hospitals manage daily operations efficiently (History Medical History, 2024). It is a platform that connects and manages all departments within a hospital, including medical, financial, patient, and administrative departments. As it will be nearly impossible to illustrate every interaction happening within the HSM using a single sequence diagram, this section explores through a sequence diagram how a doctor and a patient may interact with an HMS during an appointment. In other words, the sequence diagram illustrates a doctor-patient examination workflow within an HMS, showing how a doctor and a patient may interact with the HMS interfaces during an appointment.
Figure 2
Doctor-Patient Examination HMS Class Diagram Version-2
Note: This UML class diagram, version 2, illustrates a doctor-patient examination system within a Hospital Management System (HMS). Made with Lucidchart app.
As noted earlier in this paper sequence diagrams are usually based on UML class diagrams. Figure 2 depicts the class diagram that models the static structure of a doctor-patient examination system within a HMS. In Agile-Scrum methodology, this second iteration (version 2) of the class diagram, along with its associated pseudocode and sequence diagram, indicates that the doctor-patient examination feature was refined or modified during the design phase based on usage scenarios captured in the previous sequence diagram version. Below is the pseudocode associated with the feature.
Code Snippet 1
HMS Doctor-Patient Examination System Pseudocode Version-2
Note: The pseudocode provides a code description of the interfaces and classes for the HMS Doctor-Patient Examination System. The full code can be found on GitHub here: HMS Doctor-Patient Examination System Pseudocode
The HMS Doctor-patient examination system pseudocode comments label the Patient Class and the Patient Class as external actors as the objects instantiated by those start their interactions with the system by creating DoctorSysInterface and PatientSysInterface objects allowing them to interface with the HSM. Note that the PatientSysInterface Class and PatientSysInterface Class extend the HospitalSysManager Class. These relationships are illustrated in the class diagram by the aggregation and inheritance relationships, and it is these relationships that enable the Doctor and Patient actors to interact with the HMS Doctor-patient examination system as illustrated in the following sequence diagram.
Figure 3
Doctor-Patient Examination HMS Sequence Diagram Version-2
Note: This UML sequence diagram, version 2, illustrates a doctor-patient examination interaction within a Hospital Management System (HMS). Made with Lucidchart app.
The doctor-patient examination system HMS version-2 sequence diagram is a design level (solution space) UML sequence diagram that models the interactions between the external actors, a doctor and a patient, and a doctor-patient examination HMS. The interaction workflow initiates with the message from a found message represented by the method examine(Patient patient), a found message, in this context, is a message generated outside of the system. Similarly, the docApp(Doctor doctor) message initiates the workflow from the perspective of the patient. Note that this interaction could be represented as a parallel interaction in the diagram using a parallel (par) frame creating an interaction fragment within the diagram. However, this is not necessary as it will unnecessarily complicate the diagram and add cluttered to it without adding significant value to the understanding and illustration of the interaction.
Additionaly, the diagram illustrates boundaries in the form of the interface "patInterface : PatienSysInterface", "docInterface : DoctorSysInterface", and "diagnosisManager : DiagnosisManagerInterface" showing the layers of abstraction between the external actors themself (the doctor and the patient) and between them and the HMS core system ("aHospitalSysManager : HospitalSysManager"), as well as with the schedule manage ("scheduleManager : ScheduleManagerInterface"). The external also used those boundaries as interfaces to interact with the system. The diagram also illustrates combined fragments; for instance, the loop frame ("isSymptomDiagonsisDrugProcedure[0] = true") encapsulating the option frame "isSymptomDiagonsisDrugProcedure[0] = true" which further encapsulates the option frame "isSymptomDiagonsisDrugProcedure[1] = true".
Furthermore, the sequence diagram illustrates well internal and external actors, objects, timelines, focus of controls, messages, self-messages, return messages, asynchronous messages, object destruction, steps (in a sequence), and notes effectively modeling the dynamic interactions within the doctor-patient examination process of the HMS.
Conclusion
UML sequence diagrams are useful for illustrating dynamic interactions of objects within a system. Sequence diagrams help in identifying missing elements, detailing object interactions, and modeling object destruction. However, they are less effective at representing parallelism, complex conditional logic, or entire complex systems in a single diagram. This essay has also explored the utility of UML sequence diagrams in modeling the dynamic behavior of systems, using a Hospital Management System's doctor-patient examination scenario. It provided a detailed sequence diagram, class diagram, and pseudocode demonstrating how these different tools can be used in the design phase to effectively represent complex interactions, and refine system requirements. As shown by the provided example, in software engineering, they are essential for designing, analyzing, and documenting interactions within a system.
References:
Agile Modeling. (2023, November 23). UML Stereotypes: Diagramming style guidelines. The Agile Modeling (AM) Method - Effective Strategies for Modeling and Documentation. https://agilemodeling.com/style/stereotype.htm
IBM (2021, March 5). Sequence diagrams. Rational software modeler. IBM Documentation. https://www.ibm.com/docs/en/rsm/7.5.0?topic=uml-sequence-diagrams
Ricciardi, A. (2025, January 27). A Guide to UML Sequence Diagrams: Notation, strengths, and Limitations. Code Chronicles - Omegapy. https://www.alexomegapy.com/post/a-guide-to-uml-sequence-diagrams-notation-strengths-and-limitations
Medical History (2024, November 1). What is a hospital management system and how is
HMS good for businesses? Smart Medical History. https://smartmedhx.ai/trends/what-is-a-hospital-management-system/
Unhelkar, B. (2018 ). Chapter 12 — Interaction modeling with sequence diagrams. Software engineering with UML. CRC Press. ISBN 9781138297432