[SysML] #24. Seq Diag Constraints Fragment Decompose

쉬운 목차

Understanding Seq Diag Constraints Fragment Decompose

Execution Specifications

An execution specification is a mechanism for explicitly indicating the start and end of execution of specific actions in a sequence diagram. This allows you to more accurately understand and document the complex flow of system dynamic behavior and interactions. The use of execution specifications highlights the specifics of interaction and contributes to improving communication between system designers and developers.

Concept of Execution Specification

Meaning : An execution specification represents the period during which a particular instance within the system (represented by the lifeline) executes some action within the interaction. This is a visual representation that an action begins after receiving a specific message and ends when a specific condition is met or a response message is sent.
Purpose : By explicitly indicating the execution of an action, it removes ambiguity that can arise in the interpretation of a sequence diagram and allows a clearer understanding of the flow of interaction.

Notation in Execution Specification

Visual Representation : Execution specifications appear as thin vertical rectangles, either white or shaded, along a lifeline. The top of the rectangle explicitly indicates the start of action execution, and the bottom explicitly indicates the end of action execution.
Connection with a message : An execution specification is usually linked to the receipt of a message, with the start of action execution being related to the received message, and the end of action execution being related to the corresponding response message.

Constraints

Constraints are an important concept in system modeling that are used to define specific conditions or rules. Constraints within a sequence diagram allow you to clearly specify the flow of interactions or requirements for specific conditions. Here we describe the three main types of constraints commonly used in sequence diagrams.

Timing Constraints

Time constraints specify the time required for a particular event to occur or for a particular state to persist, or the maximum or minimum time interval between events. For example, if the system must respond to a user’s request within a certain amount of time, this time constraint can be explicitly shown in the sequence diagram.

Statement of performance requirements : Time constraints allow you to document the exact time a system or component must complete a specific task. This is especially important in real-time systems or applications where response time is critical.
Defining the conditions of a valid execution : An interaction is considered a valid execution only if it occurs within the time interval specified by the time constraint, which ensures that the system operates correctly according to its design intent.

Duration Constraints

Duration constraints specify the duration of execution of a specific interaction or action. For example, it can be used to define the time from when a process starts to completion. This can be useful for modeling the performance requirements of a system.

Definition of time interval : A duration constraint defines the acceptable time range between the start and completion of a specific task or message transmission within an interaction.
Statement of performance requirements : This helps document the performance goals of the system by specifying the minimum and maximum time required for the system or component to complete a given task.

State Invariants

State invariants represent conditions that must be satisfied by a system or object at a specific point in the sequence diagram. It is used to specify that the state of a system at a certain point in the interaction satisfies certain conditions. For example, you can specify that the system must be in a certain state before a certain message can be sent.

Validation of Conditions : State invariance guarantees that certain conditions must remain true continuously during the execution of an interaction. This maintains the logical consistency of the system and ensures that it operates as designed.
Conditions of Validity : The execution of the event is considered valid only when the state invariance conditions are satisfied. This helps you ensure that your system performs as expected in certain scenarios.
Connection with State Machine : State invariants can also be expressed in the state notation (a rectangle with rounded corners) that appears in a state machine diagram. In this case, it contains the name of the state the system or object should be in when a specific event occurs. This method only makes sense if that lifeline possesses a state machine operation with a defined set of states.

Constraint notation

Constraints typically appear in the form of boolean expressions between curly braces {}. These expressions are placed near relevant points or elements on the diagram to clearly communicate their conditions or requirements.

Combined Fragments

Combined Fragments provide a flexible way to add control structures such as conditional logic, iteration, and parallelism to the flow of interactions in a sequence diagram. These mechanisms allow modeling different execution paths and conditions within an interaction and provide a more detailed representation of the dynamic behavior of the system.

Basic structure of joined fragments

Rectangular Frame : Combined Fragments appear as a rectangular frame containing one or more lifelines. Control logic is applied within this frame, and specific messages are included depending on that logic.
Interaction Operator : A string displayed within the pentagon located in the upper left corner of the frame, indicating the control logic type of Combined Fragments. Common interactive operators include opt (selection), alt (alternative), loop (repetition), and par (parallel). there is.
Operand (region) : The interior of the combined fragment can be divided into one or more interaction operands, each of which is a region separated by a dotted line. Each area contains messages that can occur depending on specific conditions or situations.

Interaction Operator Type

opt (Optional) : Indicates an optional interaction in which a message occurs only when certain conditions are true.
alt (Alternative) : Models a situation where one of two or more alternative execution paths is selected for execution.
loop (Loop) : Indicates a situation in which a message is repeated while a specific condition is met.
par (Parallel) : Models a situation where multiple messages or actions occur in parallel.

Applications of Combined Fragments

Combined Fragments allow you to effectively model complex interactions and dynamic behavior of systems. For example, you can use the alt operator when your user interface should react differently to different user inputs, and the opt operator when logging should only occur under certain conditions. can. Repetitive data processing can be modeled with the loop operator, and situations where multiple tasks must be processed simultaneously can be modeled with the par operator.

Nested Combined Fragments

Combined Fragments can be nested, allowing for more detailed expressions of interactions, including complex control logic. This allows developers to effectively document the various dynamic situations and possible execution paths of the system and accurately model the system’s behavior.

Combined Fragments greatly increase the flexibility and expressiveness of sequence diagrams and help communicate the complex dynamic behavior of a system in a clear and easy-to-understand manner.

Opt (Optional)

opt Coupling fragments are used to represent optional interactions in sequence diagrams. It represents a set of events that can occur only under certain conditions, i.e. when the guard evaluates to true (true). In this way, opt enables the modeling of conditional execution, allowing various scenarios to be efficiently represented within a single diagram.

Features of the `opt` interaction operator

Conditional Execution : opt Combined Fragment causes a specific event to occur only when a given condition is met. This means that logic similar to if statements in programming can be applied to sequence diagrams.
Single operand : opt Combined Fragment has exactly one operand, which represents an optional set of events. Events that occur within this operand may or may not be executed depending on the result of the guard’s evaluation.
Guard expression : A guard is expressed as a boolean expression placed within square brackets ([]), and when this expression is true, the events in the operand are executed. Guards can be based on properties of a specific lifeline or properties of the block that owns the interaction as a whole.

Alt (Alternative)

alt Combined Fragment is used in sequence diagrams to represent alternative execution paths based on various conditions. This means that logic similar to if-else or switch constructs in programming can be applied to sequence diagrams, allowing multiple possible scenarios to be expressed efficiently within a single diagram. do.

Features of the `alt` interaction operator

Alternative execution paths : alt Combined Fragment contains two or more alternative sets of event occurrences, of which only one path is selected and executed at execution time. .
Guard condition : Each alternative path (operand) has its own guard condition, and only one of these conditions can evaluate to true. If all guard conditions evaluate to false, the path will be selected if the else guard is present.
Mutually Exclusive Guard : The guard conditions of alt Combined Fragment must be mutually exclusive. That is, multiple guards should not evaluate to true at the same time. If this rule is not followed, the model is considered formally invalid.
Use of the else guard : The else guard is optional and evaluates to true only when all other guards evaluate to false. else The guard is considered the last of the alternative paths.

Loop

Loop Combined Fragment is used in sequence diagrams to model the occurrence of repetitive events. This is useful when one or more messages are sent multiple times under certain conditions or when a specific action must be performed repeatedly, and allows the dynamic behavior of the system to be expressed in more detail.

Features of Loop Combined Fragment

Repeated Execution : A loop Combined Fragment represents a set of events that can occur multiple times during the execution of an interaction, making it suitable for modeling situations where the system must perform the same task repeatedly.
Specify number of repetitions : The number of repetitions is specified in parentheses (<minimum>, <maximum>), which represents constraints on the minimum and maximum number of times a repetition can occur. . If the minimum and maximum values are the same, they can be expressed as a single number.
Guard Condition : Operands within a loop Combined Fragment may have a guard condition, and the loop continues until this condition evaluates to false or the maximum number of iterations is reached.
Infinite loop support : You can use the range (0, *) to indicate when there is no upper bound on the number of iterations, which means “no upper bound”. If nothing is specified within the parentheses, the range (0, *) is applied by default.

Par(Paralell)

par Combined Fragment is used to represent parallel interactions in sequence diagrams. This is especially useful when expressing that multiple events can occur simultaneously or in any order during the execution of an interaction. These properties are suitable for modeling scenarios where the system must process multiple tasks in parallel, for example, calling multiple services or processing data at the same time.

Features of the `par` interaction operator

Parallel execution : par Combined Fragment represents a set of events that occur in parallel during the execution of an interaction. This indicates that the system can perform multiple tasks simultaneously.
Mutually independent events : The occurrence of events appearing in different operands can occur in any order during interaction execution, and the relative order between them is not predetermined.
Guard Condition : Each operand of par Combined Fragment can optionally have a guard condition, and only if the guard evaluates to true will the event for that operand be fired.
Order of event firing : Event firings that appear on the same operand within par Combined Fragment must occur in the order shown in their lifeline. However, there is no set order between the different operands.

Constructing complex Interactions using Interaction references

Using Interaction provides a way to reuse specific Interaction patterns that are repeated within a system, or to decompose complex Interactions into more manageable subunits. This approach is similar to reusing functions or methods in software development and can improve model readability, reduce duplication, and clarify the structure of interactions.

Interaction Features of use

Reusability : Interaction usage allows you to reuse a subset of common event occurrences across multiple higher-level Interactions.
Decomposition : Helps understand the model by breaking down a complex set of event occurrences into more readable, low-level interaction sequences.
Modularization : Using Interaction modularizes the behavior of the system, defines each module independently, and allows it to be called between Interactions as needed.

Interaction Usage Conventions

Rectangular frame and ref string : Interaction usage is represented by a rectangle located within a frame and includes the name of the referenced Interaction along with the ref string.
Participating Lifelines : Lifelines participating in the referenced Interaction disappear behind the rectangle, indicating that the Interaction occurs between those lifelines.

Decomposing the lifeline to express its internal behavior

Lifeline decomposition is used to express the inner workings of complex systems in detail. Through this method, the black box interaction of the system can be converted into a white box interaction, allowing the interaction between internal components to be clearly revealed. Interaction decomposition plays an important role in understanding and documenting the detailed operation of a system.

Key concepts of lifeline decomposition

Interaction Use(ref) : Lifeline decomposition is done through referenced Interaction(ref). This shows the internal structure of a specific lifeline by referring to other interactions.
Formal Gate : The referenced interaction must contain a formal gate corresponding to the message starting or ending on the parent lifeline. These gates must be compatible with messages from the parent lifeline, and the transmission and reception of messages must occur in the same order as the parent lifeline.
Nested Interaction : Lifeline decomposition allows you to express nested interactions between internal components of the system. This helps you manage the complexity of your system and analyze its internal workings in detail.

Application example of lifeline decomposition

Conversion from black box to white box : By starting from black box interaction and converting the internal operation of the system to white box interaction, the internal structure of the system can be revealed in detail.
Reuse of Interaction : By defining commonly occurring interaction patterns as reference interactions and reusing them in various upper lifelines, you can reduce model duplication and increase reusability.
Subdivision of Interaction : By subdividing interactions that occur within a complex system into smaller units, you can clearly understand how each part of the system interacts.

Lifeline decomposition is an important tool in systems engineering and software design to clearly express and understand the internal structure and behavior of complex systems. This allows developers and designers to effectively document the detailed operation of a system and accurately design the interactions between the system’s various components.

If you are interested in other articles about the basic Knowledge of SysML with EA, please refer to the links below!

[SysML] #1. Understanding SysML Diagrams

[SysML] #2. Understanding SysML Package Diagram

[SysML] #3. Understanding Dependencies of Pkg Diagram

[SysML] #5. Understanding SysML Requirement Diagram

[SysML] #6. Understanding Relations In Req Diagram

[SysML] #7. How to draw a Req Diagram with EA

[SysML] #8. Understanding SysML UseCase Diagram

[SysML] #9. How to draw a UseCase Diagram with EA

[SysML] #10. Understanding SysML bdd Diagram

[SysML] #11. Understanding SysML ibd Diagram

[SysML] #12. Understanding Part Property of Block