Use Case Model เบื้องต้น

Use Case Model คืออะไร?

Use Case ไดอะแกรม เป็นรายการหรือขั้นตอนที่อธิบายการโต้ตอบระหว่างผู้ใช้งานและระบบเพื่อบรรลุเป้าหมายใดเป้าหมายหนึ่ง

ประโยชน์ของการใช้ Use Case

มีประโยชน์ในการกำหนด ชี้แจง และจัดระเบียบของข้อกำหนดในระบบ ทำให้เราสามารถสร้างคุณลักษณะที่เป็นประโยชน์ในการใช้งาน และวิธีแก้ปัญหาหากมีข้อผิดพลาด

นอกจากนี้ยังมีประโยชน์ในการใช้สื่อสารกับผู้พัฒนาคนอื่นๆที่ทำงานร่วมกันหรือแม้แต่ลูกค้าที่เราเสนอโปรเจ็ค Use Case Model ทำให้ผู้พัฒนาหรือลูกค้าเห็นแผนภาพการทำงานที่เรียบง่าย และเข้าใจการทำงานของระบบมากขึ้น

คุณสมบัติของ Use Case Model

• จัดระเบียบข้อกำหนดการทำงานของระบบ
• จำลองเป้าหมายของการโต้ตอบระหว่างผู้ใช้กับระบบ
• อธิบายการไหลของเหตุการณ์ (เหตุการณ์ฉากหลักๆ)

Use Case Model Notations

Use Case Model จะกำหนดการโต้ตอบระหว่างผู้ใช้ภายนอกและระบบเพื่อบรรลุเป้าหมายใดเป้าหมายหนึ่งโดยเฉพาะ ในแผนภาพของ Use Case จะประกอบไปด้วยองค์ประกอบสำคัญ 4 ส่วน ดังนี้

Actor

Actor คือ ผู้ใช้งาน หรือบุคคลที่เกี่ยวข้องกับระบบ โดย actor จะเป็นบุคคลหรือระบบภายนอกอื่นๆก็ได้

สัญลักษณ์คือรูปคน (stick man icon) จริงๆแล้วจะใช้เป็นรูปคนที่วาดแบบง่ายๆ คือ หัวกลมๆ แขนขาขีดเป็นเส้นตรง หรือจะเป็นรูปคนแบบที่แสดงนี้ก็ได้ ระบุบทบาทของ actor ด้านล่างสัญลักษณ์

Use Case

คือ งานหรือเป้าหมายเฉพาะที่ระบบต้องบรรลุ โดยผู้ที่กำหนดหรือต้องการบรรลุเป้าหมายนั้นคือผู้ใช้งานหรือ Actor

สัญลักษณ์เป็นรูปวงรี มีชื่อฟังก์ชั่น โมดูล คลาส ที่โต้ตอบกับผู้ใช้อยู่ด้านใน

Relationship

ความสัมพันธ์ระหว่างผู้ใช้ (actor) และระบบ (Use Case) แสดงด้วยเส้นตรง เรียกว่า association line

System Boundary

เป็นขอบเขตของระบบ แบ่งขอบเขตระหว่างระบบและผู้ใช้

สัญลักษณ์เป็นรูปสี่เหลี่ยมโดยมีขื่อระบบระบุไว้ด้านใน

ความสัมพันธ์ระหว่าง Use Case ด้วยกันเอง

เมื่อ Use Case โต้ตอบหรือมีความสัมพันธ์ระหว่างกันเอง จะใช้สัญลักษณ์เป็นเส้นประแบบมีหัวลูกศร พร้อมทั้งเขียนชื่อรูปแบบความสัมพันธ์ไว้กลางเส้นประนั้น คลุมด้วยเครื่องหมาย <<  >> (นอกจากนั้นจะเห็นว่ามีการเขียนชื่อความสัมพันธ์บนเส้นด้วยบ่อยครั้ง)

ความสัมพันธ์ระหว่าง Use Case มีสองแบบ ดังนี้

<<include>>

ความสัมพันธ์แบบ <<include>> คือ ความสัมพันธ์ที่ Use Case หนึ่งต้องพึ่งพาความสามารถหรือฟังก์ชั่นอื่นๆของ Use Case อื่น กล่าวได้ว่าการทำงานของ Use Case หนึ่งเป็นส่วนหนึ่งของการทำงานของอีก Use Case หนึ่ง โดยเรียก Use Case ที่เป็นส่วนหนึ่งของ Use Case อื่นว่า Base Use Case และ Use Case ที่ถูกดึงมาใช้ว่า Include Use Case การวาดความสัมพันธ์ คือ ลากเส้นประจาก Base Use Case หันลูกศรชี้ไปที่ Include Use Case และเขียนชื่อความสัมพันธ์ไว้ตรงกลาง

<<extend>>

ความสัมพันธ์แบบ <<extend>> คือ ความสัมพันธ์ที่ Use Case หนึ่งถูกกระตุ้นหรือรบกวนด้วยบางเหตุการณ์ จนอาจทำให้การทำงานของ Use Case นั้นเปลี่ยนไป หรือกรณีที่ Use Case หนึ่งต้องพึ่งพาคุณสมบัติหรือความสามารถของ Use Case ในการบรรลุการทำงานของตัวเอง เราสามารถเขียนสิ่งที่กระตุ้นหรือสิ่งที่ต้องพึ่งพาคุณสมบัติของ Use Case อื่นได้ในรูปแบบของ Use Case อีกหนึ่งอัน เรียกว่า Extending Use Case ส่วน Use Case ที่ถูกกระตุ้นหรือถูกรบกวนเรียกว่า Base Use Case

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

การวาดความสัมพันธ์ คือ ลากเส้นประจาก Base Use Case หันลูกศรชี้ไปที่ Extending Use Case และเขียนชื่อความสัมพันธ์ไว้ตรงกลาง

Use Case ที่เป็นนามธรรม (Abstract) หรือความสัมพันธ์แบบทั่วไป (Generalised)

Use Case ชนิดนี้ไม่สามาถสร้าง instance ได้ เนื่องจากมีข้อมูลที่ไม่สมบูรณ์ ชื่อของ Use Case จะเขียนด้วยตัวเอียง

ตัวอย่างการเขียน Use Case Model

คำอธิบายระบบร้านอาหาร

waiter หรือ พนักงานเสริฟสามารถ “Order Food”, “Serve Food” และ “Pay for Food” ได้
Customer หรือ ลูกค้าสามารถ “Order Food”, “Eat Food” และ “Pay for Food” ได้
Cashier หรือพนักงานคิดเงินสามารถ “Pay for Food” อย่างเดียวเท่านั้น
Chef หรือ คนทำอาหารสามารถ “Order Food” และ “Cook Food”

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

หากการสั่งอาหารถูกรบกวนด้วยการสั่งไวน์ เมื่อต้องเสริฟอาหาร ก็เสริฟไวน์แทน การเสริฟไวน์จึงเป็นตัวรบกวนการเสริฟอาหาร ส่งผลไปถึงกิจกรรมการทานอาหาร ก็กลายเป็นการดื่มไวน์ และชำระเงินค่าอาหารกลายเป็นชำระเงินค่าไวน์

ความสัมพันธ์ที่เป็นตัวเลือกเหล่านี้ คือความสัมพันธ์แบบ Extend

Business Use Case

คือ ลำดับเหตุการณ์ที่ให้ผลลัพธ์แก่ actor นั้นๆเป็นการส่วนตัว โดยจากมุมมองของ actor แล้ว Business Use Case จะแสดงการทำงานที่สมบูรณ์ที่ให้ผลลัพธ์ที่ต้องการแก่ผู้ใช้งาน

ปกติแล้ว Business Use Case จะเขียนด้วยคำที่ actor ใช้เรียก ไม่ได้ใช้คำศัพท์อย่างเป็นทางการของระบบ ในขณะที่ Use Case ทั่วไปจะเป็นการอธิบายระดับการทำงานทำงานของระบบ และถูกเขียนด้วยชื่อฟังก์ชั่นหรือชื่อการทำงานของระบบนั้น

กล่าวได้ว่า Business Use Case แสดงการทำงานที่ถูกทำให้สำเร็จได้ด้วยตนเองในสถานการณ์นั้น และไม่จำเป็นต้องถูกทำให้สำเร็จโดยระบบ แต่ถูกทำให้สำเร็จโดยอัตโนมัติด้วยระบบอัตโนมัติที่อยู่ในขอบเขตของ System Boundary

คำอธิบายระบบ

ผู้โดยสารต้องทำการ security Screening ซึ่งสามารถผ่านการ screening ได้ทันที อาจเป็นการ screen ผ่านเครื่อง screening อัตโนมัติ และให้ผลลัพธ์ทันทีเป็นผ่านหรือไม่ผ่าน Security Screening เป็น Business Use Case และ ผู้โดยสารเป็น Business actor

ผู้โดยสารสามารถเลือกว่าจะ check-in luggage และ/หรือ check-in ตัวเองได้ โดยการ check-in เป็น main function ส่วน check-in luggage ต้องพึ่งพาการ individual check-in 

Group check-in เป็นส่วนหนึ่งของ individual check-in ไม่สามารถทำ Group check-in ได้ หากไม่ individual check-in

ความสัมพันธ์ระหว่างทัวร์ไกด์และผู้โดยสารเป็นความสัมพันธ์แบบทั่วไป (Generalisation) ไม่มีข้อมูลที่สมบูรณ์ว่าทัวร์ไกด์มีความสัมพันธ์กับผู้โดยสารอย่างไรกันแน่