<div id="readability-page-1" class="page"><div>
        
      
      <blockquote>
  <p>Sequence Diagram</p>
</blockquote>



<h2 id="environment-and-prerequisite">Environment and Prerequisite</h2>

<ul>
  <li>UML</li>
</ul>



<h2 id="sequence-diagram">Sequence Diagram</h2>

<h3 id="sequence-diagram-1">Sequence Diagram</h3>

<ul>
  <li><strong>Sequence Diagram</strong>: UML diagram which shows interactions between objects based on time sequence</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/sequence-diagram.jpg">
</p>

<h3 id="sequence-diagram-basic-notation">Sequence Diagram Basic Notation</h3>

<ul>
  <li><strong>Object</strong>: Interacting entities(objects or classes) in a sequence diagram which are placed at the top of the diagram, each having a lifeline represented by a vertical dashed line.</li>
  <li><strong>Lifeline</strong>: A line shows object’s existence and interactions between objects through time. Time goes up to down. It is depicted as a rectangle when state is active.</li>
  <li><strong>Message</strong>: It is an request and response in objects interactions which depicted as directed line.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/sequence-diagram-basic-notation.jpg">
</p>

<h3 id="message-type">Message Type</h3>

<ul>
  <li><strong>Synchronous Message</strong>: Sender waits until receive response message. It is depicted as an arrow as shown in the diagram below.</li>
  <li><strong>Asynchronous Message</strong>: Sender continues execution without waiting for a response message. It is depicted as an arrow as shown in the diagram below.</li>
  <li><strong>Response Message</strong>: It is depicted as shown below and can be omitted when unclear.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/sync-async-response-notation.jpg">
</p>



<h2 id="combined-fragments">Combined Fragments</h2>

<h3 id="guards">Guards</h3>

<p>When indicating the flow of communication between objects, the part that controls the flow using conditions is called <strong>Guards</strong>. In the IBM document below, it is shown as “[pastDueBalance = 0].”</p>

<p><img src="https://developer.ibm.com/developer/default/articles/the-sequence-diagram/images/3101_figure7.jpg">
</p>

<h3 id="combined-fragments-1">Combined Fragments</h3>

<p>There are many conditions using in sequence diagram like below.</p>

<ul>
  <li>Branches and Loops
    <ul>
      <li>alt</li>
      <li>opt</li>
      <li>loop</li>
      <li>break</li>
    </ul>
  </li>
  <li>Concurrency and Order
    <ul>
      <li>seq</li>
      <li>strict</li>
      <li>par</li>
      <li>critical</li>
    </ul>
  </li>
  <li>Filters and Assertions
    <ul>
      <li>ignore</li>
      <li>consider</li>
      <li>assert</li>
      <li>neg</li>
    </ul>
  </li>
</ul>

<h3 id="alt-opt">alt, opt</h3>

<ul>
  <li><strong>alt</strong>: It can be thought of as a switch statement, allowing multiple conditions to control the flow.</li>
  <li><strong>opt</strong>: It can be thought of as an if statement, where a specific condition controls the flow.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/alt.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/opt.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/ibm-alt.jpg">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/ibm-opt.jpg">
</p>

<h3 id="loop">loop</h3>

<ul>
  <li><strong>loop</strong>: It can control flow using loops based on conditions.</li>
  <li>Below shows iterate from 5 to 10 if  “[size&lt;0]” is true.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/loop.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/ibm-loop.png">
</p>

<h3 id="break">break</h3>

<ul>
  <li><strong>break</strong>: It is like an exception in code. If condition met, it exits fragment even though there are rest things to do.</li>
  <li>If there were any additional contents below break fragment such as case below, they would not be executed and the loop would be exited.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/break.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/ibm-break.jpg">
</p>

<h3 id="seq-strict">seq, strict</h3>

<ul>
  <li><strong>seq</strong>: This is the default fragment, which can be considered as the basic sequence.</li>
  <li><strong>strict</strong>: This fragment has a clear order where the parts divided by dotted lines must be executed sequentially.</li>
</ul>

<p>I found a good illustration on another blog that shows the difference between seq and strict. In the last diagram, the order is search_google() → search_bing() → search_yahoo().</p>

<p><img src="https://twpower.github.io/images/20250101_366/blog-seq.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/blog-strict.png">
</p>

<p><img src="https://twpower.github.io/images/20250101_366/strict.png">
</p>

<h3 id="par">par</h3>

<ul>
  <li><strong>par</strong>: To represent something that can be performed in parallel as the term suggests.</li>
  <li>Each fragment divided by dotted lines can be executed independently without interference.</li>
  <li>In some documents, I’ve seen this referred to as concurrency rather than actual parallelism.</li>
  <li>In the diagram below, you can see that add() and remove() are requested in parallel.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/critical-par.png">
</p>

<h3 id="critical">critical</h3>

<ul>
  <li><strong>critical</strong>: It is an atomic area which interacts independently with prevent from interfering from others.</li>
  <li>The order within the critical fragment follows the default sequence.</li>
  <li>When entering the critical fragment, that flow runs firstly without other interrupt or other interactions.</li>
  <li>In the diagram below, add() and remove() can proceed in either order add()→remove() or remove()→add() but within the critical fragment, only one of them is executed before handling the next request.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/critical-par.png">
</p>

<h3 id="ignore">ignore</h3>

<ul>
  <li><strong>ignore</strong>: It is used to ignore specific types of messages.</li>
  <li>The messages to be ignored are specified within the {} brackets.</li>
  <li>In the example below, the specified get and set messages are ignored.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/ignore.png">
</p>

<h3 id="consider">consider</h3>

<ul>
  <li><strong>consider</strong>: It is used to highlight and emphasize specific types of messages while ignoring others.</li>
  <li>The messages to be highlighted or emphasized are specified within the {} brackets.</li>
  <li>In the example below, only add and remove are considered and the other messages are ignored.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/consider.png">
</p>

<h3 id="assert">assert</h3>

<ul>
  <li><strong>assert</strong>: It is used to define parts of interactions that must always be true.</li>
  <li>Conditions are sometimes specified within {} brackets and these conditions must be satisfied.</li>
</ul>

<h3 id="neg">neg</h3>

<ul>
  <li><strong>neg</strong>: It is used to represent cases that are invalid or have encountered an error.</li>
  <li>All parts that are not neg are assumed to be working normally.</li>
  <li>In the example below, a timeout indicates a case of failure.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/neg.png">
</p>



<h2 id="others">Others</h2>

<h3 id="reference">Reference</h3>

<ul>
  <li>It is an method which connects sequence diagrams. There is another sequence diagram exists in ref.</li>
</ul>

<p><img src="https://twpower.github.io/images/20250101_366/ref.png">
</p>

<h2 id="reference-1">Reference</h2>

<ul>
  <li><a href="https://en.wikipedia.org/wiki/Sequence_diagram">https://en.wikipedia.org/wiki/Sequence_diagram</a></li>
  <li><a href="https://developer.ibm.com/articles/the-sequence-diagram/">https://developer.ibm.com/articles/the-sequence-diagram/</a></li>
  <li><a href="https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html">https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html</a></li>
  <li><a href="https://jsdysw.tistory.com/334">https://jsdysw.tistory.com/334</a></li>
  <li><a href="https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/">https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/</a></li>
  <li><a href="https://www.omg.org/spec/UML/2.5.1">https://www.omg.org/spec/UML/2.5.1</a></li>
</ul>

      
        
        
        </div></div>

TWpower’s Tech Blog

Sequence Diagram
Environment and Prerequisite
UML
Sequence Diagram
Sequence Diagram
Sequence Diagram: UML diagram which shows interactions between objects based on time sequence
Sequence Diagram Basic Notation
Object: Interacting entities(objects or classes) in a sequence diagram which are placed at the top of the diagram, each having a lifeline represented by a vertical dashed line.
Lifeline: A line shows object’s existence and interactions between objects through time. Time goes up to down. It is depicted as a rectangle when state is active.
Message: It is an request and response in objects interactions which depicted as directed line.
Message Type
Synchronous Message: Sender waits until receive response message. It is depicted as an arrow as shown in the diagram below.
Asynchronous Message: Sender continues execution without waiting for a response message. It is depicted as an arrow as shown in the diagram below.
Response Message: It is depicted as shown below and can be omitted when unclear.
Combined Fragments
Guards
When indicating the flow of communication between objects, the part that controls the flow using conditions is called Guards. In the IBM document below, it is shown as “[pastDueBalance = 0].”
Combined Fragments
There are many conditions using in sequence diagram like below.
Branches and Loops
    
alt
opt
loop
break
Concurrency and Order
    
seq
strict
par
critical
Filters and Assertions
    
ignore
consider
assert
neg
alt, opt
alt: It can be thought of as a switch statement, allowing multiple conditions to control the flow.
opt: It can be thought of as an if statement, where a specific condition controls the flow.

loop
loop: It can control flow using loops based on conditions.
Below shows iterate from 5 to 10 if  “[size<0]” is true.
break
break: It is like an exception in code. If condition met, it exits fragment even though there are rest things to do.
If there were any additional contents below break fragment such as case below, they would not be executed and the loop would be exited.
seq, strict
seq: This is the default fragment, which can be considered as the basic sequence.
strict: This fragment has a clear order where the parts divided by dotted lines must be executed sequentially.
I found a good illustration on another blog that shows the difference between seq and strict. In the last diagram, the order is search_google() → search_bing() → search_yahoo().

par
par: To represent something that can be performed in parallel as the term suggests.
Each fragment divided by dotted lines can be executed independently without interference.
In some documents, I’ve seen this referred to as concurrency rather than actual parallelism.
In the diagram below, you can see that add() and remove() are requested in parallel.
critical
critical: It is an atomic area which interacts independently with prevent from interfering from others.
The order within the critical fragment follows the default sequence.
When entering the critical fragment, that flow runs firstly without other interrupt or other interactions.
In the diagram below, add() and remove() can proceed in either order add()→remove() or remove()→add() but within the critical fragment, only one of them is executed before handling the next request.
ignore
ignore: It is used to ignore specific types of messages.
The messages to be ignored are specified within the {} brackets.
In the example below, the specified get and set messages are ignored.
consider
consider: It is used to highlight and emphasize specific types of messages while ignoring others.
The messages to be highlighted or emphasized are specified within the {} brackets.
In the example below, only add and remove are considered and the other messages are ignored.
assert
assert: It is used to define parts of interactions that must always be true.
Conditions are sometimes specified within {} brackets and these conditions must be satisfied.
neg
neg: It is used to represent cases that are invalid or have encountered an error.
All parts that are not neg are assumed to be working normally.
In the example below, a timeout indicates a case of failure.
Others
Reference
It is an method which connects sequence diagrams. There is another sequence diagram exists in ref.
Reference
https://en.wikipedia.org/wiki/Sequence_diagram
https://developer.ibm.com/articles/the-sequence-diagram/
https://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
https://jsdysw.tistory.com/334
https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/
https://www.omg.org/spec/UML/2.5.1

[UML](EN) Sequence Diagram

댓글