Use case Diagram
🤔 จะอธิบายสิ่งที่อยู่ในระบบทั้งหมดให้คนอื่นเข้าใจง่ายๆได้ยังไงดีนะ ?
Last updated
Was this helpful?
🤔 จะอธิบายสิ่งที่อยู่ในระบบทั้งหมดให้คนอื่นเข้าใจง่ายๆได้ยังไงดีนะ ?
Last updated
Was this helpful?
เวลาที่เริ่มอธิบายตัวโปรเจคว่ามันทำอะไรได้บ้าง? แต่ละส่วนสัมพันธ์กันยังไง? ใครมีสิทธิ์ทำอะไรแค่ไหน? ให้กับเพื่อนๆในทีมฟัง บ่อยครั้งเราก็จะพบว่าคนในทีมเริ่มหาวนอน ฟังไม่รู้เรื่อง จำต้นชนปลายไม่ถูก หรือเล่าให้ฟังแล้วก็ลืมนั่นเอง แล้วเราจะแก้ปัญหาพวกนี้ได้ยังไงเพื่อไม่ให้คนในทีมลืม หรือเอาไว้อธิบายคนใหม่ที่เข้ามาในทีมเข้าใจเรื่องพวกนี้ได้เร็วๆได้อย่างไร ?
ปัญหามันเกิดขึ้นเพราะคนฟังจินตนาการตามสิ่งที่อธิบายได้ยาก ดังนั้นเราก็จะวาดรูปประกอบการอธิบายแทน เพราะคนเราเห็นภาพแล้วเข้าใจได้ง่ายกว่าเห็นตัวหนังสือ ดังนั้นเราจะใช้แผนภาพที่เรียกว่า Use case Diagram มาช่วยแก้ปัญหาโลกแตกนี้กัน โดยเจ้า use case diagram นั้นจะแปลงเรื่องราวทั้งหมดที่เกิดขึ้นให้กลายเป็นรูปที่เข้าใจง่ายๆนั่นเอง
โดยปรกติเวลาที่เราใช้ UML เราจะไม่เขียนโค้ดหรือเขียนเอกสารกัน แต่เราจะวาดรูปเล่นกันต่างหาก โดยในตัวอย่างรอบนี้เราจะใช้ตัวอย่างของ ระบบโหวต มาเขียนเป็น diagram แบบ step-by-step ดูละกัน ซึ่งผมจะให้ ดช.แมวน้ำ 🧔 เป็นคนไล่ลำดับการเขียน diagram ให้ดูละกันนะ
🧔 ในการเขียน use case diagram นั้นเราจะต้องเริ่มวาดจากของที่ระบบทำได้ก่อน ซึ่งในระบบโหวตนั้น สิ่งแรกที่มันต้องทำได้ก็คือ ยืนยันตัวตน นั่นเองดังนั้นเราก็จะวาดรูป วงรี แล้วเขียนลงไปว่ามันคือการยืนยันตัวตนไปครับ
🧔 ในการยืนยันตัวตนนั้นปรกติเราก็ให้ใส่แค่ชื่อผู้ใช้กับรหัสผ่านอย่างเดียวก็พอ แต่ก็มีบางกรณีเราจะต้องให้ทำการยืนยัน PIN ด้วย ซึ่งการยืนยัน PIN นี้เป็นการทำงานเสริมของการยืนยันตัวตนตามแบบเดิม เราก็จะสามารถเขียนการทำงานเสริมออกมาเป็นแบบนี้ได้
🧔 สิ่งถัดมาที่ระบบโหวตทำได้คือการตั้งหัวข้อในการโหวต ซึ่งคนที่จะตั้งหัวข้อในการโหวตได้จะต้องผ่านการยืนยันตัวตนเสียก่อน ดังนั้นผมก็จะวาดออกมาเป็นแบบนี้
🧔 ในการตั้งหัวข้อโหวตนั้นจริงๆเราก็มีการตั้งหัวข้อโหวตสำหรับกลุ่มลับ ซึ่งทำงานเหมือนกับการตั้งหัวข้อโหวตธรรมดาเลยเพียงแค่ให้เฉพาะคนที่ถูกเชิญเท่านั้นถึงจะโหวตได้
🧔 ถัดมาเราก็จะเริ่มวาดของที่จะเข้ามาใช้งานระบบของเราละ ซึ่งเจ้าตัวแรกก็คือ ผู้ใช้ นั่นเอง
🧔 และนอกจากผู้ใช้เองบางทีระบบก็จะทำการเรียกใช้งานกันเองอีกด้วย เช่น เมื่อถึงเวลาที่กำหนด ระบบก็จะทำการปิดโหวต ซึ่งเจ้าตัวปิดโหวตอัตโนมัตินี้เราก็ถือว่าเป็น Actor แบบนึงเหมือนกัน วาดๆๆ
🧔 คราวนี้เราก็จะลากเส้นเชื่อมโยงเจ้า Actor ต่างๆว่ามันจะมาใช้งานความสามารถอะไรของระบบของเราบ้าง วาดๆๆ (ผมแอบเติม การปิดโหวต ลงไปนะเพราะระบบก็ควรจะต้องทำได้เช่นกัน)
🧔 จากรูปด้านบนเราจะเห็นแล้วว่า ผู้ใช้ สามารถเรียกใช้ของในระบบได้ 4 เรื่อง ส่วนเจ้าระบบจับเวลาจะสามารถสั่งปิดการโหวตได้อย่างเดียวเท่านั้น
🧔 สุดท้ายเราก็จะทำการคลุมของที่อยู่ในระบบของเราทั้งหมดไว้ภายในกรอบสี่เหลี่ยม เพื่อเป็นการบอกว่าอะไรบ้างในระบบที่เราต้องดูแลนั่นเอง ตามรูปเบย
ของที่ยกตัวอย่างให้ดูด้านบนทั้งหมดจริงๆมันก็เพียงพอต่อการใช้งาน 80% แล้วล่ะ ส่วนที่เหลือมันเป็นตัวเสริมให้เราสามารถลงรายละเอียดของแผนภาพได้ชัดขึ้นกว่าเดิมเฉยๆ แต่ดูเหมือนว่าตอนเขียนบทความนี้ผมจะเริ่มไม่ค่อยสบายแล้ว เลยขอเขียนไว้เท่านี้ก่อนละกันนะ
จากตัวอย่างทั้งหมดเราก็น่าจะพอเห็นภาพแล้วว่า อย่าเสียเวลาเขียนว่าระบบต้องทำอะไรได้บ้างเลย เขียนเป็นแผนภาพแบบนี้เข้าใจได้ง่ายกว่าเยอะเลย แถมมันแบ่งเป็นสัดเป็นส่วนให้คนทำงานเข้าใจได้ง่ายขึ้นจมเลยว่า อะไรบ้างที่เราต้องเขียน อะไรบ้างที่ไม่เกี่ยวกับระบบ เผลอๆเอาไปสร้างเป็น features แล้ว map เข้าทำงานในแต่ละ iteration ได้เลยนะเนี่ย
Iteration เป็นวิธีการวางแผนการทำงานเป็นช่วงๆ ซึ่งเมื่อแต่ละช่วงจบลงเราจะมีงานออกมาส่งมอบให้ลูกค้า แล้วเราก็จะวางแผนกันต่อว่าช่วงถัดไปเราจะส่งมอบ features อะไรให้กับลูกค้าบ้าง โดยทั้งหมดนี่เป็นหนึ่งในการทำงานในรูปแบบของ Agile ซึ่งเดี๋ยวผมจะเขียนสรุปการทำงานแบบ agile ไว้ให้ ดังนั้นเพื่อนๆลองดูจาก side menu ได้เลย
คำเตือน เวลาที่เราเขียน Diagram ต่างๆ ห้ามเอาทุกกระบวนการทำงานมาเขียนยำกันไว้ในภายใน diagram เดียวกัน เพราะไม่อย่างนั้นมันจะกลายเป็นแผนภาพพาทัวร์นรกเลย เพราะเส้นมันจะยุ่งเหยิงไม่รู้จุดเริ่มต้นแต่ละเรื่องคืออะไร
สิ่งที่ควรทำคือ เขียน 1 กระบวนการทำงานต่อ 1 diagram เท่านั้น ดังนั้นถ้างานเราใหญ่เราก็จะมีหลาย diagram ก็จริงแต่มันจะช่วยทำให้เรา focus กับแต่ละกระบวนการทำงานได้ชัดเจนขึ้นนั่นเอง
