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


---

# 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/use-case-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.