Use case Diagram

🤔 จะอธิบายสิ่งที่อยู่ในระบบทั้งหมดให้คนอื่นเข้าใจง่ายๆได้ยังไงดีนะ ?

😢 ปัญหา

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

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

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

แนะนำให้อ่าน บทความนี้เป็นส่วนหนึ่งของคอร์ส 👶 UML พื้นฐาน หากเพื่อนๆสนใจอยากดูรายละเอียดของ UML แต่ละตัวว่ามันมีอะไรบ้างก็สามารถกดลิงค์ที่ชื่อคอร์สเข้าไปดูได้เลยนะ หรือจะดูหมวดอื่นๆจาก side menu ก็ได้เน่อ

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

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

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

🔥 Use case

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

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

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

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

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

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

Include คือการบอกว่า ถ้าจะให้ความสามารถนั้นทำงานได้สมบูรณ์จะต้องใช้ความสามารถอื่นด้วย โดยเราจะใช้หัวลูกศรชี้ไปยังความสามารถที่เราต้องการเอาเข้าใช้ เช่น การตั้งโหวตจะต้องใช้การยืนยันตัวตนด้วยถึงจะตั้งโหวตได้

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

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

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

🔥 Actor

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

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

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

🔥 Association

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

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

🔥 Boundary of system

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

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

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

🎯 บทสรุป

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

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

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

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