วันพุธที่ ๒๑ พฤศจิกายน พ.ศ. ๒๕๕๐

No.2-1 Key Assignment: Use Case ร้านอร่อยจัง

Date: 20 พ.ย. 50

ทำอึ้งกิมกี่กันไปเล็กน้อย ว่าทำไมมันง่ายกว่าที่คิด เพราะที่ไปคิดมามันยากกว่าที่เฉลย ชักงง เพราะว่า Use Case ที่อ.อัษ เฉลยให้ ไม่มีทั้ง include และ extend มี actor แค่ 2 ตัว คือ บริกร และ ผู้จัดการร้าน ไม่รวมพ่อครัว สรุปว่า





Scope: ระบบบริการลูกค้า

Level: User Goal

Actor: บริกร มี use case คือ
1. พาลูกค้าไปที่โต๊ะ 2. รับคำสั่งอาหาร 3.เสริฟอาหาร 4.ยกเลิกอาหาร

Actor: ผู้จัดการ มี 2 use case คือ
1. ออกใบเก็บเงิน 2. รับชำระค่าอาหาร

Actor: พ่อครัว ไปไหนไม่รู้ (ไม่มีนะครับ)

การบรรยาย Main Success
สำหรับ Main Success Scenario แต่ละเคส ก็เป็นการบรรยายในลักษณะที่ ยูสเซ้อออ...ยูสเซ่อร์ (ทำเสียงสูง ๆ นะครับ) มันเหมือนบทละคร (Script) ในแต่ละตอน (Boundary) ว่าใคร (Actor อาจจะคน หรือ ระบบ ที่มันแสดงพฤติกรรมหรือตอบสนองได้) ทำอะไรบ้าง (Use Case) และ มีขั้นตอนทำอย่างไรบ้าง(Main Success Scenario / Alternative Success)...ถึงบางอ้อ.....มิน่าถึงไม่เรียกว่า user เรียกเป็น actor แทน

อ่อรู้จัก use case จริง ๆ ซะที
ก็เลยถึงบางอ้อที่ว่า "ตกลง use case มันก็คือ การสรุป Requirement ที่อยู่ใน Boundary และบอกได้ว่า Actor ทำอะไรได้บ้าง มาในรูปแบบของภาษาภาพ (Diagram) ซึ่ง ในขั้นการทำ use case ยังไม่ต้องไปคิดอะไรมาก คือ ถ้าโยน use case ที่เราเขียนไปให้ ยูสเซ่อร์อ่านแล้วไม่ต้องไปบอกอะไรมาก คือ ยูสเซ่อร์เข้าใจ ใช่เลย

เขียน use case ได้แบบมึน ๆ
โดยส่วนใหญ่พวกเราไอที้ ไอที ก็จะมองอะไรก็เกาะ Database เป็นผังข้อมูลวิ่งอยู่ในหัว มองอะไรก็เป็น Entity เป็น Key เป็น Field เป็น Module เป็น Program ส่ง parameter ชิ่งกันไปชิ่งกันมาอยู่ในหัว เวลาเขียนก็เลยมึน ๆ เพราะคาบเส้นระหว่างการพัฒนาระบบ กับการทำตัวเป็นยูสเซ่อร์ปกติ (ซึ่งทำได้ยากเพราะฝืนธรรมชาติ)

คอนเซ็ปต์ Simple but Work ยังใช้ได้ดีกับ use case
ดังนั้นการเขียน use case ง่ายกว่าที่คิด เพราะคิดมากเลยยากกว่าที่คิด ยูสเซอร์บรรยายอะไรมาจับมาเขียนในรูปแบบ Actor ทำอะไรได้บ้าง ไม่มีผิดไม่มีถูก แต่มีหลักว่า ยูสเคสที่กำหนด ต้อง Test Size ด้วยว่าไม่เล็กเกินไป เช่น Actor ---->(กดปุ่ม Enter) อันนี้หน่อมแน้มมาก ... ไม่ Return Value / Information อะไรก็ไม่ต้องไปแตกมาเป็น use case ตามคำแนะนำในตำราหรือเว็บไซต์ทั่วไป แล้วที่สำคัญอย่ายัดเยียด Programming หรือ Technical ลงไปใน use case ที่นอกเหนือจาก Requirement

๒ ความคิดเห็น:

ไม่ระบุชื่อ กล่าวว่า...

เยี่ยมจริงๆๆ เลยเฮีย
ขอติวอย่างนี้บ่อยๆนะ
ทำให้เข้าใจง่ายดี
ขอบคุงมั๊กๆๆ ที่สรุปให้อ่านนจ้า

ไม่ระบุชื่อ กล่าวว่า...

สรุปได้ดีค่ะ แต่อย่างว่าแหละ อ่านแค่นี้คงไม่ทำเป็น ฝึกทำกันเยอะๆ นะคะ