> For the complete documentation index, see [llms.txt](https://www.saladpuk.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.saladpuk.com/basic/uml/sequence-diagram.md).

# 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 %}