# Sequence Diagram

## 😢 ปัญหา

เคยไหมเวลาอธิบายการทำงานให้กับเพื่อนๆในทีมว่า ของต่างๆมันทำงานร่วมกันยังไง ซึ่งตอนที่คุยกันก็อาจจะต้องทวนกันหลายทีบ้างเพื่อให้เข้าใจตรงกัน แต่แล้วตอนไปทำงานจริงๆก็ไม่ได้ทำตามที่คุย เพราะเข้าใจผิดหรือลืม เพราะมันมีขั้นตอนการทำงานที่ค่อนข้างเยอะและตัวแปรต่างๆที่รับส่งก็วุ่นวายเช่นกัน

> **ตัวอย่าง**\
> ฝั่ง front-end จะต้องส่งข้อมูลต่างๆไปให้กับฝั่ง back-end ผ่าน API ตัวนี้สำหรับเรื่องนี้นะ แล้วฝั่ง back-end จะไปเรียก module 1234 เพื่อทำงานต่อ แล้วจะได้ข้อมูลแบบนี้ส่งกลับมา บลาๆ

จากที่ร่ายยาวมาเราจะทำยังไงดีเพื่อให้คนในทีมเข้าใจและไม่ลืมขั้นตอนการทำงานของโค้ดเหล่านั้นได้กันนะ ?

## 😄 วิธีแก้ปัญหา

ผมเชื่อว่าคนเราเห็นภาพแล้วเข้าใจได้ง่ายกว่าเห็นตัวหนังสือ ดังนั้นเราจะใช้แผนภาพที่เรียกว่า **Sequence Diagram** มาช่วยแก้ปัญหาโลกแตกนี้กัน โดยเจ้า sequence diagram นั้นจะแปลงเรื่องราวทั้งหมดที่เกิดขึ้นให้กลายเป็นรูปที่เข้าใจง่ายๆนั่นเอง

{% hint style="info" %}
**แนะนำให้อ่าน**\
บทความนี้เป็นส่วนหนึ่งของคอร์ส [👶 UML พื้นฐาน](https://saladpuk.gitbook.io/learn/basic/uml) หากเพื่อนๆสนใจอยากดูรายละเอียดของ UML แต่ละตัวว่ามันมีอะไรบ้างก็สามารถกดลิงค์ที่ชื่อคอร์สเข้าไปดูได้เลยนะ หรือจะดูหมวดอื่นๆจาก side menu ก็ได้เน่อ
{% endhint %}

## 🤔 Sequence Diagram ใช้ยังไง?

โดยปรกติเวลาที่เราใช้ UML เราจะไม่เขียนโค้ดหรือเขียนเอกสารกัน แต่เราจะวาดรูปเล่นกันต่างหาก โดยในตัวอย่างรอบนี้เราจะใช้ตัวอย่างของการ **Login** มาเขียนเป็น diagram แบบ step-by-step ดูละกัน ซึ่งผมจะให้ **ดช.แมวน้ำ** 🧔 เป็นคนไล่ลำดับการเขียน diagram ให้ดูละกันนะ

## 😄 ลองเขียน Sequence Diagram กัน

### 🔥 Actor

🧔 ในการเขียน sequence diagram นั้นเราจะต้อง**เริ่มวาดจากสิ่งที่เริ่มต้นกระบวนการ**ก่อน ซึ่งในการ login นั้นจุดเริ่มต้นของมันคือมีผู้ใช้เข้ามานั่นเอง ดังนั้นเราก็จะวาดรูป **ผู้ใช้** เป็นสิ่งแรกลงไป

![](/files/-LnSFu3kbeI9K5_QswaE)

### 🔥 Lifeline

🧔 หลังจากที่มีผู้ใช้เข้ามาในระบบแล้ว ระบบก็จะเปิดหน้า Login มาให้ผู้ใช้เห็น ดังนั้นเราก็จะวาดกล่องของหน้า Login เข้าไปตามรูปด้านล่าง

![](/files/-LrncjXNKK1j6WvFihbd)

{% hint style="info" %}
**เส้นประ**\
คือตัวที่เอาไว้บอกว่าของต่างๆนั้นเริ่มต้นทำงานที่จุดไหน และ สิ้นสุดที่ตรงไหน
{% endhint %}

### 🔥 Message

🧔 หลังจากที่ระบบแสดงหน้า login ขึ้นมาแล้ว ถัดไปผู้ใช้ก็จะทำการกรอกข้อมูลและกดปุ่มเข้าสู่ระบบซึ่งเป็นการทำงานระหว่าง **User** กับ **Login page** นั่นเอง ดังนั้นเราก็จะวาดรูปออกมาเป็นแบบนี้

![](/files/-Lsb5cH3a0bO02fbw6Sd)

### 🔥 **Activations**

🧔 หลังจากที่ Login page ถูก User เรียกมาแล้ว มันก็จะเริ่มต้นทำงานต่อ โดยเราจะวาดกล่องครอบจุดเริ่มต้นของสิ่งที่มันจะทำไปจนถึงขั้นตอนการทำงานสุดท้ายของมันลงไปภายในเส้นประตามรูปเลย

![](/files/-LnhFwX6_TcvDO5G1f2y)

### 🔥 **Self Message**

🧔 สิ่งแรกที่หน้า Login จะทำก็คือตรวจสอบว่าข้อมูลที่ผู้ใช้กรอกมานั้นครบหรือยัง เช่น ชื่อผู้ใช้ และ รหัสผ่าน ต้องไม่เป็นค่าว่างไรงี้ ซึ่งการทำงานนี้มันจะทำงานภายในหน้า Login เองไม่ได้ให้ใครช่วยทำ เราก็จะวาดรูปออกมาราวๆนี้

![](/files/-LqpkPQlGZQYrWzwA1Tf)

### 🔥 Fragments

🧔 ถัดมาถ้าผู้ใช้ยังกรอกข้อมูลไม่ครบ ระบบก็จะแจ้งเตือนออกมา ซึ่งมันจะแจ้งเตือนเฉพาะกรณีที่ใส่ข้อมูลไม่ครบเท่านั้น ดังนั้นเราก็จะใส่กล่องเงื่อนไขครอบลงไปตามนี้

![](/files/-Lv0LVdlYjLgL8eJmC5P)

{% hint style="success" %}
**Fragments**\
ในกล่อง fragment จะเห็นว่ามันเขียนไว้ว่าเป็น **alt** ซึ่งย่อมาจาก **Alternative** ที่แปล**ว่าทางเลือก** ซึ่งมันจะทำก็ต่อเมื่อเงื่อนไขที่เขียนกำกับไว้เป็นจริง ส่วน fragments นั้นจริงๆมีให้เลือกใช้เยอะเต็มไปหมดเลย เช่น **loop**, **ref** ที่ได้ใช้บ่อยๆนะ ส่วนอันอื่นๆลองไปศึกษาเพิ่มเติมดูละกันนะ
{% endhint %}

### 🔥 Guard condition

🧔 ถัดมาถ้าผู้ใช้กรอกข้อมูลครบ มันก็จะส่งข้อมูลชื่อผู้ใช้และรหัสผ่านไปตรวจสอบกับเซิฟเวอร์โดยส่งผ่าน API ไป ซึ่งมันจะส่งไปก็ต่อเมื่อ **ข้อมูลถูกกรอกครบหมดแล้วเท่านั้น** เราก็จะวาดรูปออกมาราวๆนี้

![](/files/-LngWLw6wrdxayhwbZr0)

{% hint style="danger" %}
สังเกตุนะว่าถ้าเราไม่ใส่ **Guard condition** ไว้ ตอนที่มันทำข้อ 3 เสร็จ คนที่ไม่รู้เรื่องก็จะเข้าใจว่ามันจะทำข้อ 4 ต่อเลยนั่นเอง แต่ถ้าเราใส่ Guard condition ไว้ในข้อ 4 มันจะเป็นการบังคับว่าต้องผ่านเงื่อนไขนี้ก่อนเท่านั้นนะถึงจะทำข้อนี้ได้นั่นเอง
{% endhint %}

🧔 ในการส่ง Message ของข้อ 4 เราอาจจะเขียนไว้เลยก็ได้ว่ามันส่งอะไรไปบ้างก็ได้ ตามรูปด้านล่าง

![](/files/-Lw9OzZF-9yXgJlfUpUJ)

### 🔥 Return Message

🧔 หลังจากที่ตัว API ตรวจสอบผลลัพท์ต่างๆแล้ว มันก็จะส่งผลลัพท์กลับมาให้กับหน้า Login นั่นเอง ซึ่งเราก็จะวาดรูปออกมาเป็น **เส้นประ** ครับ

![](/files/-M-w9fLTQQHf348jlLW3)

### 🔥 Note

🧔 ผลลัพท์ที่มันส่งกลับมา ในบางครั้งเราก็อยากจะเขียนรายละเอียดไว้กันลืมว่ามันส่งอะไรกลับมาบ้าง เราก็สามารถใส่ note ไว้ก็ได้ ซึ่งของที่เขียนไว้ใน note ไม่มีรูปแบบกำหนดไว้ ดังนั้นในตัวอย่างผมจะเขียน Json ที่มันส่งกลับมาละกัน ตามรูปเลย

![](/files/-LrKRFGR9bkEg-Jr5C9J)

### 🔥 Fragments (ต่อ)

🧔 ตัวผลลัพท์ที่ได้กลับมานั้น หน้า Login ก็จะทำการตัดสินใจต่อว่ามันจะต้องแสดงผลยังไงต่อดี ซึ่งเราจะเขียนแยกเงื่อนไขออกเป็น 2 เรื่องตามนี้

1. **เข้าใช้งานไม่ได้** - ระบบก็ควรจะแจ้งข้อผิดพลาดที่ได้มาจากเซิฟเวอร์ 
2. **เข้าใช้งานได้** - ระบบก็จะแจ้งเตือนว่ากำลังเปลี่ยนหน้านะ 

![](/files/-LpqDUw-xwi3t6fFZN23)

🧔 เสร็จแล้ว จากที่ร่ายยาวมาเราก็จะได้ลำดับการทำงานของระบบ Login ทั้งหมด 7 ขั้นตอนที่ไม่ต้องนั่งไล่จำอะไร เพราะทุกคนในทีมสามารถกลับมาดูรูปก็สามารถพูดคุยกันต่อได้เลยนั่นเอง

![ถ้าไม่ชัดให้กดที่รูปเพื่อดูแบบเต็มจอได้นะ](/files/-LvAEGzvMtJTs6P1pzWw)

## 🤔 Sequence Diagram มีแค่นี้เหรอ ?

ของที่ยกตัวอย่างให้ดูด้านบนทั้งหมดจริงๆมันก็เพียงพอต่อการใช้งาน 80% แล้วล่ะ ส่วนที่เหลือมันเป็นตัวเสริมให้เราสามารถลงรายละเอียดของแผนภาพได้ชัดขึ้นกว่าเดิมเฉยๆ ดังนั้นผมจะยกตัวอย่างการใช้งานตัวอื่นๆไว้ในนี้ต่อละกันไม่งั้นเดี๋ยวคนที่พึ่งเคยใช้จะตกใจว่าทำไมมันวุ่นวายจุงเบย

### 🔥 **Create Message**

🧔 ถ้าการทำงานของเราจะต้องไปสร้าง Lifeline อื่นขึ้นมาเพื่อทำงานกับตัวนั้นโดยเฉพาะเราก็สามารถเขียนเป็นแบบนี้ได้

![](/files/-M1VRbOBlyQn3iAa0eEw)

### 🔥 Destroy **Message**

🧔 ในการส่ง message บางทีก็เป็นการสั่งให้อีก Lifeline นึงจบการทำงานเลยก็ได้เหมือนกัน เช่นพวกคำสั่ง **Dispose** ยังไงล่ะ ซึ่งเราก็จะวาดรูปเป็นแบบนี้

![](/files/-LntqUTIyVeHiMOPH-S7)

ขอแนะนำแบบเบื้องต้นไว้เท่านี้ก่อนละกัน เพราะที่เหลือมันเป็นของที่นานๆครั้งเราจะได้ใช้ เพราะการคุยกัน 80% ในการทำงานนั้นใช้แค่นี้ก็เหลือเฟือแล้วครับ ส่วนกรณีที่ต้องใช้ของที่เหลือก็คือ งานในจุดนั้นๆมันต้องมีการลงรายละเอียดที่ชัดเจนเพื่อไม่ให้เข้าใจผิดเพราะงานจุดนั้นมันละเอียดอ่อนจริงๆยังไงล่ะ

## 🎯 บทสรุป

จากทั้งหมดเราก็จะเห็นแล้วว่า เราสามารถแปลงขั้นตอนการทำงานร่วมกันของคลาสต่างๆหรือ module ต่างๆให้กลายมาเป็นรูปภาพที่เข้าใจง่ายๆได้ยังไง ดังนั้นเราลองไปหัดวาดรูปเล่นเพื่อทำให้คนในทีมเข้าใจการทำงานได้ง่ายๆกันเถอะ

{% hint style="danger" %}
**คำเตือน**\
เวลาที่เราเขียน Diagram ต่างๆ ห้ามเอาทุกกระบวนการทำงานมาเขียนยำกันไว้ในภายใน diagram เดียวกัน เพราะไม่อย่างนั้นมันจะกลายเป็นแผนภาพพาทัวร์นรกเลย เพราะเส้นมันจะยุ่งเหยิงไม่รู้จุดเริ่มต้นแต่ละเรื่องคืออะไร

**สิ่งที่ควรทำคือ** เขียน 1 กระบวนการทำงานต่อ 1 diagram เท่านั้น ดังนั้นถ้างานเราใหญ่เราก็จะมีหลาย diagram ก็จริงแต่มันจะช่วยทำให้เรา focus กับแต่ละกระบวนการทำงานได้ชัดเจนขึ้นนั่นเอง
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/uml/sequence-diagram.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.