แบบทดสอบ Use Case Diagram

ในระบบจัดการห้องสมุด Actor "นักเรียน" สามารถ "ค้นหาหนังสือ" และ "ยืมหนังสือ" ได้ หาก Use Case "ยืมหนังสือ" จำเป็นต้องทำ "ตรวจสอบสิทธิ์" ก่อนเสมอ ควรใช้ความสัมพันธ์แบบใด?

• <<extend>>

• <<include>>

• Association

• Generalization

• Dependency

ในระบบธนาคารออนไลน์ Actor "ลูกค้า" มี Use Case "โอนเงิน" และในบางกรณีอาจมี "พิมพ์ใบเสร็จ" ถ้าลูกค้าต้องการ ความสัมพันธ์ระหว่าง Use Case ทั้งสองควรเป็นแบบใด?

• "โอนเงิน" <<include>> "พิมพ์ใบเสร็จ"

• "โอนเงิน" <<extend>> "พิมพ์ใบเสร็จ"

• "พิมพ์ใบเสร็จ" <<extend>> "โอนเงิน"

• "พิมพ์ใบเสร็จ" <<include>> "โอนเงิน"

• ไม่มีความสัมพันธ์

ในระบบขายสินค้าออนไลน์ Actor "ลูกค้า" และ "พนักงาน" ต่างก็สามารถ "ดูข้อมูลสินค้า" ได้ แต่เฉพาะ "พนักงาน" เท่านั้นที่สามารถ "แก้ไขข้อมูลสินค้า" ได้ ควรจัดการความสัมพันธ์อย่างไร?

• สร้าง Actor "ผู้ใช้" เป็น parent ของ "ลูกค้า" และ "พนักงาน"

• ให้ทั้งสอง Actor เชื่อมต่อกับ Use Case "ดูข้อมูลสินค้า" โดยตรง

• ใช้ <<include>> ระหว่าง Use Case ทั้งสอง

• ให้ "พนักงาน" เป็น child ของ "ลูกค้า"

• สร้าง Use Case แยกกันสำหรับแต่ละ Actor

ในระบบจองตั๋วเครื่องบิน Use Case "จองตั๋ว" มีขั้นตอน "เลือกที่นั่ง", "ชำระเงิน", และ "ยืนยันการจอง" ที่ต้องทำทุกครั้ง ควรแสดงความสัมพันธ์อย่างไร?

• ใช้ <<include>> จาก "จองตั๋ว" ไปยังทั้งสาม Use Case

• ใช้ <<extend>> จาก "จองตั๋ว" ไปยังทั้งสาม Use Case

• แสดงเป็น Use Case เดียวคือ "จองตั๋ว" เท่านั้น

• ใช้ <<include>> จากทั้งสาม Use Case ไปยัง "จองตั๋ว"

• ใช้ Association ปกติ

ในระบบการจอง Actor "แพทย์" และ "พยาบาล" สามารถ "ช่วย" ได้เฉพาะ "แพทย์" และสามารถ "รักษาโรค" ได้ในการออกแบบระบบ?

• สร้าง Actor "บุคลากรทางการแพทย์" เป็น parent

• เชื่อมสอง Actor เข้าด้วยกัน

• แยก Use Case กับ Actor

• ใส่ <> เข้ากับ Use Case

• ไม่ต้องแสดง Actor "พยาบาล"

ในระบบ ATM Use Case "ถอนเงิน" จะต้องมี "ตรวจสอบ PIN" และ "ตรวจสอบยอดเงิน" เสมอ และอาจจะ "มีใบเสร็จ" ตามความต้องการ การออกแบบระบบ?

• "ถอนเงิน" <> "ตรวจสอบ PIN", "ตรวจสอบยอดเงิน" และ <> "มีใบเสร็จ"

• "ถอนเงิน" <> ทั้งหมด

• "ถอนเงิน" <> ทั้งหมด

• "มีใบเสร็จ" <> "ถอนเงิน" และ "ถอนเงิน" <> กับสอง Use Case

• ไม่ต้องมีความสัมพันธ์ใดๆ

ในระบบลงทะเบียน Actor "นักเรียน" สามารถ "ลงทะเบียน" ได้ และอาจจะ "ถอนชั้น" ได้ในช่วงเวลาที่กำหนด การแสดงความสัมพันธ์ในการออกแบบระบบ?

• "ลงทะเบียน" <> "ถอนชั้น"

• "ถอนชั้น" <> "ลงทะเบียน"

• "ลงทะเบียน" <> "ถอนชั้น"

• ไม่ต้องมีความสัมพันธ์

• ใส่ Generalization

ในระบบอาหาร Actor "การ" สามารถ "สั่งอาหาร" ได้ และหาก Use Case "สั่งอาหาร" ต้องมี "เอกสาร" และ "นอนออเดอร์" เป็นองค์ประกอบที่เสมอ ควรใช้ความสัมพันธ์แบบใด?

• "สั่งอาหาร" <> "เอกสาร", "นอนออเดอร์"

• "สั่งอาหาร" <> "เอกสาร", "นอนออเดอร์"

• "เอกสาร" <> "สั่งอาหาร"

• แสดงความสัมพันธ์

• Association

ในระบบการคง Actor "พนักงานคง" และ "วหาคง" สามารถ "ตรวจสอบ" ได้ เฉพาะ "วหาคง" เท่านั้นสามารถ "ออกรายการเก็บ" ได้ ควรออกแบบอย่างไร?

• "วหาคง" สืบทอดจาก "พนักงานคง"

• "พนักงานคง" สืบทอดจาก "วหาคง"

• แยก Actor แสดงความสัมพันธ์

• รวม Actor แนวเดียว

• สร้าง Actor "พนักงาน" เป็น parent

ในระบบโรงเรียน Use Case "ลงทะเบียนเรียน" อาจจะ "ระบุเทอม" ในกรณีใดความสัมพันธ์เหมาะสม?

• "ลงทะเบียนเรียน" <> "ระบุเทอม"

• "ระบุเทอม" <> "ลงทะเบียนเรียน"

• "ลงทะเบียนเรียน" <> "ระบุเทอม"

• แสดงความสัมพันธ์

• Association