> 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/use-case-diagram.md).

# Use case Diagram

## 😢 ปัญหา

เวลาที่เริ่มอธิบายตัวโปรเจคว่ามันทำอะไรได้บ้าง? แต่ละส่วนสัมพันธ์กันยังไง? ใครมีสิทธิ์ทำอะไรแค่ไหน? ให้กับเพื่อนๆในทีมฟัง บ่อยครั้งเราก็จะพบว่าคนในทีมเริ่มหาวนอน ฟังไม่รู้เรื่อง จำต้นชนปลายไม่ถูก หรือเล่าให้ฟังแล้วก็ลืมนั่นเอง แล้วเราจะแก้ปัญหาพวกนี้ได้ยังไงเพื่อไม่ให้คนในทีมลืม หรือเอาไว้อธิบายคนใหม่ที่เข้ามาในทีมเข้าใจเรื่องพวกนี้ได้เร็วๆได้อย่างไร ?

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

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

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

## 🤔 Use case Diagram ใช้ยังไง?

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

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

### 🔥 Use case

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

![](/files/-LnIPOAqg11YMSBb1Wgf)

### 🔥 Extend (ความสัมพันธ์)

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

![](/files/-LmyVUbNkFPFo-JkVWE-)

{% hint style="info" %}
**Extend**\
คือการอธิบายว่า ความสามารถนี้ถูกเพิ่มเติมจากความสามารอะไร ซึ่งหัวลูกศรจะชี้ไปยังความสามารถพื้นฐาน และส่วนหางคือความสามารถที่ต่อยอดขึ้นมา โดยปรกติความสามารถที่ extend ออกมาจะไม่ได้มีประโยชน์อะไรถ้าเอามาทำงานเดี่ยวๆ เช่น การยืนยัน PIN ถ้าเอามาทำงานเดี๋ยวๆก็ไม่รู้จะยืนยันมันไปทำไมนั่นเอง
{% endhint %}

### 🔥 Include (ความสัมพันธ์)

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

![](/files/-LtrqP5fas-2tWlinw2r)

{% hint style="info" %}
**Include**\
คือการบอกว่า ถ้าจะให้ความสามารถนั้นทำงานได้สมบูรณ์จะต้องใช้ความสามารถอื่นด้วย โดยเราจะใช้หัวลูกศรชี้ไปยังความสามารถที่เราต้องการเอาเข้าใช้ เช่น การตั้งโหวตจะต้องใช้การยืนยันตัวตนด้วยถึงจะตั้งโหวตได้
{% endhint %}

### 🔥 **Generalization** (ความสัมพันธ์)

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

![](/files/-LqvuEeBHFGY78RnHPPh)

{% hint style="info" %}
**Generalization**\
เป็นการต่อยอดความสามารถเดิมที่มีอยู่ให้ทำเรื่องใหม่ๆเข้าไปได้ ซึ่งจะต่างกับ extend เพราะมันแยกออกมาทำงานด้วยตัวมันเองแล้วเกิดประโยชน์ นั่นคือเราสามารถตั้งกลุ่มที่เป็นส่วนตัวได้นั่นเอง
{% endhint %}

### 🔥 Actor

🧔 ถัดมาเราก็จะเริ่มวาดของที่จะเข้ามาใช้งานระบบของเราละ ซึ่งเจ้าตัวแรกก็คือ **ผู้ใช้** นั่นเอง

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

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

![](/files/-LtpPWOv1NU48CcP7dNf)

{% hint style="info" %}
**Actor**\
คือสิ่งที่จะเข้ามากระทำกับระบบของเรา ซึ่งถ้าเป็นคนเราจะวาดเป็นรูปคน แต่ถ้าสิ่งที่เข้ามากระทำกับระบบไม่ใช่คนเราก็จะวาดเป็นวงรีเหมือน Use case ปรกติเลย เช่น API ภายนอกเรียกเข้ามา, ระบบตั้งเวลาอัตโนมัติ บลาๆ
{% endhint %}

### 🔥 Association

🧔 คราวนี้เราก็จะ**ลากเส้นเชื่อมโยง**เจ้า Actor ต่างๆว่ามันจะมาใช้งานความสามารถอะไรของระบบของเราบ้าง วาดๆๆ (ผมแอบเติม **การปิดโหวต** ลงไปนะเพราะระบบก็ควรจะต้องทำได้เช่นกัน)

![](/files/-LtpXRL7RHn3yRkxozot)

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

### 🔥 **Boundary of system**

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

![](/files/-LpD7i08PtSzBTa6UhTX)

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

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

## 🎯 บทสรุป

จากตัวอย่างทั้งหมดเราก็น่าจะพอเห็นภาพแล้วว่า อย่าเสียเวลาเขียนว่าระบบต้องทำอะไรได้บ้างเลย เขียนเป็นแผนภาพแบบนี้เข้าใจได้ง่ายกว่าเยอะเลย แถมมันแบ่งเป็นสัดเป็นส่วนให้คนทำงานเข้าใจได้ง่ายขึ้นจมเลยว่า อะไรบ้างที่เราต้องเขียน อะไรบ้างที่ไม่เกี่ยวกับระบบ เผลอๆเอาไปสร้างเป็น features แล้ว map เข้าทำงานในแต่ละ iteration ได้เลยนะเนี่ย

{% hint style="success" %}
**Iteration**\
เป็นวิธีการวางแผนการทำงานเป็นช่วงๆ ซึ่งเมื่อแต่ละช่วงจบลงเราจะมีงานออกมาส่งมอบให้ลูกค้า แล้วเราก็จะวางแผนกันต่อว่าช่วงถัดไปเราจะส่งมอบ features อะไรให้กับลูกค้าบ้าง โดยทั้งหมดนี่เป็นหนึ่งในการทำงานในรูปแบบของ **Agile** ซึ่งเดี๋ยวผมจะเขียนสรุปการทำงานแบบ agile ไว้ให้ ดังนั้นเพื่อนๆลองดูจาก side menu ได้เลย
{% endhint %}

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

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