[SysML] #23. Seq Diagram LifeLine and Message

In this article, we will explain the concept of sequence diagrams and specifically look at how they can be used in systems engineering.

쉬운 목차

Understanding Seq Diagram LifeLine and Message

Sequence diagrams in SysML provide a visual representation of how components interact within a system and how that interaction unfolds over time. Each component (lifeline) and the exchange of messages between them reveal how the system behaves over time. This allows developers to design the dynamic aspects of the system in detail and, if necessary, decompose and model the detailed behavior of the interactions.

The role of sequence diagrams

Sequence diagrams visualize the dynamic behavior of a system and are especially useful for clarifying synchronous and asynchronous interactions between components. These diagrams help you clearly understand and share complex system behavior, promoting effective communication and collaboration across teams.

When to use sequence diagrams

The right times to create a sequence diagram are:

Initial Concept Operating Document Development Phase : To clarify the key issues and requirements of the system.
Early stage of architecture design : To specify interactions between subsystems.
After architectural design is complete : To detail the interactions between components and provide clear guidance to the implementation team.
As a test case specification : To provide a clear interaction path during test planning and execution.

Advantages and limitations of sequence diagrams

Sequence diagrams are detailed design documents that enable automatic generation of source code and clearly communicate the order and structure of operations. However, readability may be reduced when dealing with the control logic of complex actions. In these cases, it is best to limit your use of a single scenario to a graphical test case.

Basic components of a sequence diagram

Interaction : The only type of model element allowed in a sequence diagram, representing the dynamic behavior of the system. Interactions are model elements that function as both a behavior and a namespace. This means that it can contain multiple elements defined within the interaction (e.g. lifelines, event firings, messages, etc.).
Diagram Frame : A sequence diagram is surrounded by a frame that represents specific interactions. A frame represents a single interaction defined within a system model, and all elements that appear within a frame are considered part of that interaction.
Diagram Header : The header indicates the name and type of interaction the diagram represents. The standard format is sd [interaction] interaction name [diagram name], where sd is the abbreviation for sequence diagram.

Lifelines

A lifeline is a key element in a sequence diagram that represents a participant in an interaction, that is, a single instance that participates in the interaction by exchanging messages with other lifelines. This section explains the concept of lifelines, their notation, and their role within interactions.

Lifeline definition and role

Definition : A lifeline corresponds to the properties of a part of a block that owns the interaction, which can be the system as a whole, a subsystem, or a single component.
Role : A lifeline represents the flow of an interaction through the exchange of messages between individual instances within the interaction. It provides a visual representation of the dynamic relationships and behaviors between interaction participants.

Lifeline notation

Basic form : The lifeline is shown as a rectangle connected by dotted lines, progressing downward through time.
Event Occurrence Order : Events that appear higher on the lifeline occur before events that appear lower. This indicates the relative time order between events.
Name expression : The head of the lifeline displays the name and type of the part property that the lifeline represents in the format <part property name> [<selector expression>] : <type>.

The Importance of Lifelines

Precise representation of interactions : Lifelines enable detailed representation of the structure and behavior of interactions in sequence diagrams. This is important to clearly understand the dynamic behavior of the system and the interactions between its components.
Selector Expression : You can use a selector expression to specify the specific instance that the lifeline represents. This can further clarify interactions by focusing on specific instances in a collection of instances.

Event occurrences and lifelines

Types of event occurrences : Events that can occur on a lifeline include sending and receiving messages, creating and destroying lifelines, and starting and ending action execution.
Narrative Formation : These event occurrences form an ordered sequence within a sequence diagram, telling a narrative, or story, of the interaction.

Lifelines and event occurrences are essential for precisely modeling the flow of interactions and sequences of actions in sequence diagrams. This allows system designers and developers to clearly understand the dynamic behavior of the system and effectively design the interactions between system components.

Messages

Messages are one of the key elements of interaction in a sequence diagram, representing communication between lifelines. This section explains the role of messages, their notation, and their meaning in SysML.

The role of the message

Communication expressions : Messages represent various forms of communication between lifelines. This can include calling actions, responding, creating or destroying lifelines, etc.
Structure of Interaction : Messages play an important role in defining the structure and flow of interaction within a sequence diagram. Messages help you understand system behavior by visually representing the logical flow of interactions.

Message notation

Lines and Arrowheads : Messages are usually expressed as lines with arrowheads connecting the sending and receiving lifelines. It has a structure that starts from the transmitting lifeline and ends with the receiving lifeline.
Line style and arrowhead style : Each message type has its own line style (dotted or solid) and arrowhead style (open or filled).
Name string : The name string floating above the message provides information such as the name of the message and optionally parameter names, argument values, and return values. The format of the name string varies depending on the message type.

Meaning of the message

Message in SysML : In SysML, a message is not just a data format or a representation of the data being conveyed. A message represents a call or communication of a specific action in the context of an interaction and can convey data as needed.
Internal Communication : Messages can model situations where a lifeline is sending communication to itself, or between parts internal to an entity. This is useful when representing behavior within a system or complex interactions between entities.

Message Occurrence

Message generation is an important concept in a sequence diagram that represents specific points in the transmission and reception of messages between interacting lifelines. This provides a way to specifically specify the start and end of a message in the flow of interaction.

Types of message occurrence

Message Send Occurrence : Indicates where the message begins on the send lifeline. This models the moment a message is created and sent to another lifeline.
Message Receive Occurrence : Indicates the point at which the message reaches the receive lifeline. This models the moment when a message arrives and triggers an action or reaction on the receiving lifeline.

Together, these two occurrences make up the overall flow of the message, with each occurrence located at a specific point along the message’s path in the sequence diagram.

Notation of message occurrence

The occurrence of a message exists implicitly at the point where the end of the message connects to the lifeline. That is, in a sequence diagram there is no separate notation to indicate the beginning and end of a message, which is expressed through the point where the message line meets the lifeline.

Types of messages

There are six message types in SysML’s Interactions:

asynchronous messages
synchronous messages
reply messages
create messages
found messages
lost messages

However, since found and lost messages have little use in everyday modeling, let’s look at the above four in more detail.

Asynchronous Messages

Asynchronous messages are an important mechanism used to model asynchronous communication between components within a system.

Features of asynchronous messages

Independent Execution : Asynchronous messages continue their execution after the sender sends the message without waiting for the receiver to finish processing the message. This represents a situation where the sender and receiver operate independently of each other, and the sender does not wait for a reply from the receiver.
Asynchronous communication : These messages are suitable for expressing asynchronous actions within a system and communication between processes. For example, data can be processed or updated in the background while the system performs other tasks.

Notation for asynchronous messages

Arrow : Asynchronous messages are represented by a solid line with an open arrowhead, usually drawn from the sending lifeline to the receiving lifeline.
Message Name and Arguments : The message name must match the Reception name owned by the receiving lifeline, and the input argument list is optional. The argument list is comma-separated, and each argument has the format <input parameter name> = <value specification>. The argument list represents the data passed with the message, and the input parameter names must match the input parameter names of the receiving being called.

Synchronous Messages

Synchronous messages are a type of message used when communication between components within a system occurs synchronously.

Characteristics of synchronous messages

Wait and Reply : A synchronous message is one in which the sender sends a message, waits for the receiver to complete execution of the called action, and then does not continue its execution until it receives a reply message indicating that execution is complete. .
Confirmation of completion of action : This message type is particularly suitable when the sender needs to proceed to the next step only after confirming that a specific action has been completed by the receiver.

Notation for synchronous messages

Arrows and Labels : Synchronous messages are represented by a solid line with a filled arrowhead, and a label containing the message name and optionally a list of input arguments appears above the message. The label format can be expressed as <message name>(<input argument list>), and the input arguments can be expressed in the form <input parameter name> = <value specification>.
Operation call matching : The name of the synchronous message must match the Operation name owned by the receiving lifeline, which reflects the nature of the operation being invoked.

Reply Messages

A reply message represents communication after a synchronously called action in the sequence diagram has completed, returning the result to the calling lifeline.

Features of Reply message

Communication of action completion : The reply message indicates that the called action has been completed and conveys the result of this action to the calling lifeline.
Passing of return value : If the called action has a return value, this value is passed to the sender through the reply message.

Notation of Reply message

Line Style and Label : The reply message is displayed as a dotted line with an open arrowhead, and can optionally contain a label containing the message name, a list of output arguments, and a return value.
Label Format : Labels can take the form <assigned to> = <message name>(<output argument list>): <specify value>. Here, the message name must match the name of the called Operation, and the output argument list can optionally detail the results of the operation.

Use of Reply messages

reply messages are used especially in sequence diagrams when the result of an action is important. Combined with synchronous messages, this clearly indicates the start and completion of the called operation and accurately represents the flow of operations and data transfer within the system.

Optional expression of Reply message

Omission of reply message : The reply message can be optionally displayed in the sequence diagram. Modelers may sometimes decide to omit reply messages to reduce the complexity of the diagram and improve readability. However, the omission of the reply message means that completion of the called operation and delivery of the result is still implicit.

Create Messages

Creation messages are one of the message types that play an important role in sequence diagrams. They represent interactions that create new instances.

Characteristics of generated messages

Create new instance : The create message represents communication that creates a new instance within the system. This instance can participate in future interactions.
Indication of starting point : The creation message clearly indicates where the lifeline of the instance being created begins. This indicates when the activity for that instance begins in the sequence diagram.

Notation for generated messages

Connect with arrow: The generated message is represented by a dotted line with an open arrowhead, the tip of the message is connected to the sending lifeline, and the tip of the arrowhead is connected to the head of the generating lifeline.
Lifeline creation occurs: Lifeline creation occurs at the point where the end of the arrowhead of the creation message meets the head of the lifeline. This means that a new instance will become active within the system.

Use of generated messages

Create messages are especially used when the creation of a new entity or component is important as part of the interaction. For example, when modeling a system initialization process in a sequence diagram, you can represent a situation where multiple components or instances are created one after another.

Destruction Occurrences

The occurrence of a destruction is an important event in a sequence diagram that marks the end of the life cycle of an instance. Destruction occurrences serve to clearly indicate in the sequence diagram the critical moments at which the life cycle of an instance ends. This accurately represents the creation and destruction of instances in system design and provides important information for understanding the flow of interactions and relationships between instances. The use of destruction occurrence and deletion messages helps document the dynamic behavior of the system more clearly and effectively communicates design intent.

Concept of Destruction Occurrence

Meaning : Destruction occurs refers to the moment when an instance within a system is destroyed. This may mean that the instance no longer participates in interactions and is removed from the system or physically destroyed.
Meaning of destruction : For software objects it can mean freeing memory, and for hardware objects it can mean actual removal or physical destruction.

Notation for occurrence of destruction

X-shaped cross : Destruction occurrences are indicated by an X-shaped cross located at the bottom of the lifeline. This cross indicates that the instance’s life cycle has ended.
Coupling with a delete message : The occurrence of destruction can be linked to the receipt of a delete message, which contains a command to terminate the instance. Deletion messages are a special type of message that ends with destruction occurring.

Key features of weak ordering

Order of occurrences of message transmission and reception : Within a particular lifeline, the reception occurrence of a message must be aligned after the transmission occurrence of that message. This reflects the intuitive understanding that a message can only be received after it has been sent.
Specify the order of occurrence within a lifeline : Events that occur in a specific lifeline follow the order defined for that lifeline. For example, in lifeline 3, it can be explicitly specified that A.receive occurs before B.send.
No ordering between different lifelines : The ordering may not be explicitly specified between occurrences of different lifelines. For example, the order in which B.send and D.send occur is unspecified, so the order between them can be freely determined during interaction execution.
Message overwhelm : Message overwhelm refers to a phenomenon in which the transmission of a specific message occurs before the transmission of another message, but reception may occur in the opposite order. This may be due to time delays or concurrency between sending and receiving messages, and is an important consideration when modeling asynchronous behavior within a system.