2. Usecase Diagram
ในการออกแบบระบบงาน เราจะเริ่มต้นด้วยการวิเคราะห์ว่าระบบงานจะต้องสามารถทำอะไรให้กับผู้ใช้ได้บ้าง แล้วเขียนบรรยายกรณีต่าง ๆ ที่จะเกิดขึ้นกับการใช้ระบบงาน โดยเขียนบรรยายออกมาเป็น Usecase Diagram Usecase Diagram จะไม่ได้จับคู่โดยตรงกับความต้องการของระบบ แต่ Usecase Diagram แสดงให้เห็นว่ามีกรณีใดบ้างที่ผู้ใช้จะมาใช้งานระบบ ซึ่งบางกรณีอาจจะไม่ใช้ความต้องการของผู้ใช้โดยตรงก็ได้
รูปภาพ 14 Usecase Diagram ของระบบส่งต่อผู้ป่วย
ในภาพที่ 14 เป็นตัวอย่างการใช้งาน Usecase Diagram เพื่อแสดงให้เห็นกรณีต่าง ๆ ที่ผู้ใช้เข้ามาใช้งานระบบ สัญลักษณ์รูปคนก้าง (Stickman) เราเรียกว่าแอคเทอร์ (Actor) แอคเทอร์จะใช้แทนผู้ใช้ที่เป็นคนจริง หรือระบบอีกระบบหนึ่งที่ต้องการใช้งานระบบนี้ก็ได้
สำหรับรูปวงรี เราเรียกว่า Usecase ซึ่งหมายถึงกรณีที่ระบบสามารถทำงานให้กับแอคเทอร์ โดยเส้นแต่ละเส้นที่เชื่อมจากแอคเทอร์ไปที่ Usecase แสดงให้เห็นว่าแอคเทอร์ต้องการสั่งให้ระบบทำงานอะไรให้สักอย่างหนึ่ง และ Usecase แต่ละก้อนจะต้องสร้างผลลัพธ์บางอย่างให้กับแอคเทอร์ ตามที่แอคเทอร์ต้องการ
รูปสี่เหลี่ยมที่ล้อมรอบ Usecase ไว้ก็คือ System Boundary ที่แสดงขอบเขตของระบบงาน ว่าต้องประกอบด้วย Usecase อะไรบ้าง สำหรับการพิจารณาแอคเทอร์ที่จะโต้ตอบกับระบบ เราจะพิจารณาจากบทบาทมากกว่าพิจารณาตามตำแหน่งงานที่เป็นอยู่จริงในองค์กร ซึ่งจากภาพที่ 14 เราจะสังเกตเห็นว่า เราสามารถแยกผู้ใช้ออกเป็น ผู้ใช้ที่เป็นเจ้าหน้าที่ของสถานบริการฝ่ายส่ง และผู้ใช้ที่เจ้าหน้าที่ของสถานบริการฝ่ายรับ ก็เนื่องจากทั้งสองแอคเทอร์นี้มีบทบาทหน้าที่ต่างกัน
ความสัมพันธ์ระหว่าง Usecase กับ Usecase สามารถเกิดขึ้นได้ 2 แบบคือ
1. includes ถ้า Usecase หนึ่ง includes ไปที่ Usecase อีกก้อนหนึ่ง หมายถึง การทำงานภายใน Usecase นั้นจะต้องไปสั่งให้อีก Usecase ที่ถูก includes เข้ามาไว้ ทำงานร่วมกันด้วย ถ้าคิดในแบบง่าย ๆ ก็คือ Usecase ที่ถูก includes จะถูกรวมการทำงานเข้าไว้กับ Usecase ที่เป็นตัวหลักด้วยเสมอ จากตัวอย่างในภาพที่ 14 จะพบว่า การตรวจสอบสถานภาพของผู้ป่วย การตรวจสอบค่าใช้จ่ายที่ใช้รักษา และการบันทึกข้อมูลผู้ป่วยส่งต่อจะต้องผ่าน Usecase เพื่อเลือกผู้ป่วยก่อนเสมอ
ความสัมพันธ์แบบ includes มักจะเกิดขึ้นเสมอกับ Usecase ที่มีลักษณะการทำงานเป็นทั่วๆ ไป เช่น การเพิ่มข้อมูล การลบข้อมูล การบันทึกข้อมูล การค้นหาข้อมูล ซึ่งมักจะถูกรวมเข้าไปไว้ใน Usecase ที่เป็นกิจกรรมเฉพาะของระบบงานนั้น ๆ
2. extends Usecase ที่ extends จากอีก Usecase หนึ่งจะเป็น Usecase ที่เกิดขึ้นในกรณีเดียวกันแต่เป็นกรณีที่พิเศษมากกว่า เช่น ในภาพที่ 14 จะพบว่า การตรวจสอบสิทธิผู้ป่วยในกรณีปกติจะตรวจสอบจากหมายเลขบัตรประชาชน แต่ถ้าผู้ป่วยลืมรหัสบัตรประชาชนหรือไม่ได้ติดบัตรประชาชนมาด้วย ระบบจะตรวจสอบสิทธิโดยใช้ ชื่อ นามสกุล และวันเดือนปี เกิดของผู้ป่วย ซึ่งเป็นกรณีพิเศษของการตรวจสอบสิทธิผู้ป่วย เช่นนี้ จะเห็นว่าเราจะให้ Usecase การตรวจสอบด้วย ชื่อ นามสกุลและวันเดือนปีเกิด เป็น Usecase ที่ extends มาจาก Usecase การตรวจสอบสิทธิปกติ
เราสามารถออกแบบให้แอคเทอร์สืบทอดต่อจากแอคเทอร์อีกชนิดหนึ่งได้ เช่นในกรณีของระบบส่งต่อผู้ป่วย ผู้ใช้ระบบทุกคนจะต้องผ่านการตรวจสอบว่าเป็นผู้ใช้ของระบบอย่างถูกต้อง โดยใส่ชื่อผู้ใช้และรหัสผ่าน เพื่อให้ระบบตรวจสอบตอนเข้าสู่ระบบ ดังนั้น เราจะเขียนให้เห็นว่าแอคเทอร์ผู้ใช้ประเภทอื่น ๆ สืบทอดต่อจาก แอคเทอร์ผู้ใช้ระบบทุกคน
รูปภาพ 15 การออกแบบให้แอคเทอร์สืบทอดต่อจากแอคเทอร์ที่มีลักษณะทั่วไป
2.1 Usecase Description
เนื่องจากรายละเอียดที่ปรากฏใน Usecase Diagram เป็นเพียงภาพรวมของระบบ และไม่ได้มีคำอธิบายว่า Usecase แต่ละตัวมีการทำงานภายในเป็นอย่างไรบ้าง ดังนั้นในการเขียนเอกสาร Requirement Specification ให้สมบูรณ์จะเพิ่มเติมส่วนที่เป็น Usecase Description เข้าไปด้วยเพื่อให้ผู้ร่วมทีมพัฒนาระบบเข้าใจรายละเอียดของ Usecase ได้ดียิ่งขึ้น
ตารางที่ 1 ตัวอย่างข้อมูลที่ควรใส่เข้าไปใน Usecase Description
| Usecase No. | หมายเลข Usecase เพื่อใช้สำหรับอ้างอิงกับ Usecase อื่น |
| Usecase name | ชื่อของ Usecase |
| Last update on | วันที่แก้ไขครั้งสุดท้าย |
| Last update by | ชื่อของผู้ที่แก้ไขเอกสารนี้ครั้งสุดท้าย |
| Primary Actor | แอคเทอร์ที่เป็นผู้กระทำหลัก |
| Secondary Actor | แอคเทอร์ที่เป็นผู้กระทำรอง |
| Objective | วัตถุประสงค์ |
| Usecase type | ประเภทของ Usecase เช่น Basic, Alternative, Abstract หรือ Extension |
| Precondition | เงื่อนไขที่ต้องเกิดมาก่อนที่จะมาทำงานที่ Usecase นี้ |
| Success End Condition | เงื่อนไขที่บ่งชี้ให้เห็นว่า Usecase เสร็จอย่างสมบูรณ์ |
| Failed End Condition | เงื่อนไขที่บ่งชี้ให้เห็นว่า Usecase ล้มเหลว |
| Trigger | เมื่อเข้ามาทำที่ Usecase นี้แล้วจะทำให้เกิดเหตุการณ์ต่อเนื่องอะไรขึ้น |
| Basic Flow of Events | ลำดับเหตุการณ์ตามปกติ |
| Exception Flow of Events | ลำดับเหตุการณ์พิเศษที่ไม่ค่อยพบบ่อยในกรณีปกติ |
| Alternative Flow of Events | ลำดับเหตุการณ์อื่น ๆ ที่เป็นทางเลือกเมื่อไม่สามารถทำตามลำดับเหตุการณ์ปกติได้ |
| Current Open Issue | ประเด็นที่ยังเป็นที่น่าสงสัยอยู่ในปัจจุบัน |
| Future Open Issue | ประเด็นที่อาจจะเกิดขึ้นในอนาคต |
| Superordinates | Usecase ที่ต้องเกิดขึ้นก่อนที่จะเข้ามาทำงานใน Usecase นี้ |
| Subordinates | Usecase ที่จะเกิดตามมาหลังจากที่ Usecase นี้เสร็จสิ้น |
| General Description | รายละเอียดอื่น ๆ ทั่วไปที่เพิ่มเติมให้กับผู้อ่าน |
ในตารางที่ 1 จะเป็นรายละเอียดทั่ว ๆ ไปที่ควรจะใส่ให้กับ Usecase หนึ่งก้อน ซึ่งอาจจะมีรูปแบบต่างกันไป แล้วแต่กฏระเบียบของทีมพัฒนา อย่างไรก็ตามข้อมูลที่สำคัญที่ควรจะปรากฏใน Usecase Description เสมอก็คือลำดับเหตุการณ์[3]ที่เกิดขึ้น ซึ่งอย่างน้อยจะต้องมีอยู่หนึ่งลำดับเหตุการณ์ที่เป็นเหตุการณ์หลักที่แอคเทอร์จะกระทำกับระบบงานใน Usecase นี้ นอกจากนั้นถือว่าเป็นข้อมูลเพิ่มเติมที่อาจจะมีหรือไม่มีก็ได้
ตารางที่ 2 ตัวอย่างของการเขียน Usecase Description ให้กับ Usecase บันทึกข้อมูลผู้ป่วยส่งต่อ
| Usecase No. | 3.1 |
| Usecase name | บันทึกข้อมูลผู้ป่วยส่งต่อ |
| Last update on | 10 กันยายน พ.ศ. 2546 |
| Last update by | นาย สรพงษ์ เรือนมณี |
| Primary Actor | ผู้ใช้ระบบของสถานบริการฝ่ายส่ง |
| Secondary Actor | |
| Objective | เพื่อบันทึกข้อมูลผู้ป่วย แล้วส่งต่อไปให้สถานบริการที่จะรับผู้ป่วยไปรักษาต่อ |
| Usecase type | þBasic ¨Alternative ¨Abstract ¨Extension |
| Precondition | 1. ผู้ใช้ต้องป้อนชื่อผู้ใช้และรหัสผ่านเพื่อขอเข้าสู่ระบบก่อน 2. ผู้ใช้ต้องมีระดับสิทธิพอเพียงที่จะดำเนินการบันทึกข้อมูลผู้ป่วยส่งต่อ 3. ผู้ป่วยที่จะถูกส่งต่อไปที่สถานบริการฝ่ายรับ จะต้องเป็นผู้ป่วยที่มีสิทธิประกันสุขภาพ โดยผ่านการตรวจสอบสิทธิมาแล้ว |
| Success End Condition | 1. มีข้อมูลครบถ้วนถูกบันทึกไว้ในแฟ้มผู้ป่วยส่งต่อ 2. มีข้อความแจ้งเตือนไปปรากฏที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ ว่าผู้ป่วยที่ถูกเลือก ได้ส่งต่อไปที่สถานบริการแห่งนั้นแล้ว 3. มีข้อความปรากฏให้ผู้ใช้ทราบว่าได้บันทึกข้อมูลเสร็จเรียบร้อยแล้ว |
| Failed End Condition | 1. มีข้อความปรากฏให้ผู้ใช้ทราบว่าการบันทึกข้อมูลไม่สำเร็จ 2. ไม่มีข้อมูลใด ๆ ทั้งสิ้นบันทึกไว้ในแฟ้มผู้ป่วยส่งต่อ 3. ไม่มีข้อความแจ้งเตือนใด ๆ ไปปรากฏที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ |
| Trigger | ส่งเหตุการณ์แจ้งเตือนไปที่เครื่องเทอร์มินอลของสถานบริการฝ่ายรับ |
| Basic Flow of Events | 1. หลังจากผู้ใช้เข้าสู่ระบบงาน และผู้ใช้มีสิทธิที่จะส่งต่อผู้ป่วยได้ จะปรากฏคำสั่งให้ผู้ใช้เลือกว่าจะส่งต่อผู้ป่วย 2. ผู้ใช้เลือกคำสั่งเพื่อส่งต่อผู้ป่วย จะปรากฏแบบฟอร์มให้ผู้ใช้กรอกข้อมูลที่จำเป็นสำหรับการส่งต่อผู้ป่วย 3. ผู้ใช้เลือกผู้ป่วยที่ต้องการส่งต่อไปที่สถานบริการอื่น (ดูที่ Usecase 3.2 เลือกผู้ป่วย) 4. ผู้ใช้เลือกสถานบริการที่ต้องการส่งผู้ป่วยไปให้ (ดูที่ Usecase 3.3 เลือกสถานบริการ) 5. ผู้ใช้กรอกรายละเอียดที่เหลือในแบบฟอร์มให้ครบถ้วน 6. ผู้ใช้เลือกคำสั่งบันทึกข้อมูลผู้ป่วยส่งต่อ 7. ระบบตรวจสอบความถูกต้องของข้อมูลในแบบฟอร์มผู้ป่วยส่งต่อ ก่อนที่จะเริ่มดำเนินการบันทึกเข้าสู่ระบบ 8. ถ้าข้อมูลที่ผู้ใช้กรอกเข้ามาทุกอย่างถูกต้อง และครบถ้วนสมบูรณ์ ระบบจะบันทึกข้อมูลผู้ป่วยส่งต่อ เข้าสู่แฟ้มข้อมูลผู้ป่วยส่งต่อ 9. ระบบส่งสัญญาณแจ้งเตือนไปที่เครื่องเทอร์มินอลที่เปิดไว้ที่สถานบริการที่รับต่อผู้ป่วย 10. ระบบแจ้งข้อความให้ผู้ใช้ทราบว่าการบันทึกเสร็จสมบูรณ์ 11. ผู้ใช้ตอบ ตกลง แล้วกลับเข้าสู่การทำงานในหน้าเมนูหลัก |
| Exception Flow of Events | 8.1 ถ้าข้อมูลที่ผู้ใช้กรอกเข้ามาไม่ครบถ้วนสมบูรณ์ 8.2 แสดงข้อความแจ้งเตือนปรากฏขึ้นบนหน้าจอ พร้อมกับแนะนำผู้ใช้ว่าสมควรแก้ไขที่ตรงจุดไหน 8.3 ผู้ใช้แก้ไขข้อมูลในแบบฟอร์มแล้วทดลองสั่งบันทึกข้อมูลใหม่อีกครั้ง |
| Alternative Flow of Events | 1. ลักษณะการทำงานแบบ Batch Operation โดยการเก็บข้อมูลผู้ป่วยส่งต่อไว้ก่อน แล้วจึงสั่งให้บันทึกข้อมูลทั้งหมดในเวลาเดียวกัน |
| Current Open Issue | 1. มีการทำงานแบบ Offline หรือไม่ เช่นในกรณีที่เครื่องเซิร์ฟเวอร์ที่ส่วนกลางไม่พร้อมดำเนินการให้ จะสามารถเก็บข้อมูลการส่งต่อผู้ป่วยไว้ที่เครื่องเทอร์มินอลก่อนหรือไม่ 2. การแจ้งไปที่เครื่องเทอร์มินอลของสถานบริการรับผู้ป่วย จะให้แจ้งแบบ Synchronous หรือแจ้งแบบ Asynchronous 3. ต้องการให้เก็บบันทึกเหตุการณ์ ที่ผู้ใช้เข้าใช้งานระบบไว้ในไฟล์บันทึกเหตุการณ์เปลี่ยนแปลง (Event Log) ด้วยหรือไม่ |
| Future Open Issue | 1. ในกรณีที่มีผู้ใช้สองคนพยายามจะส่งผู้ป่วยคนเดียวกัน กรณีแบบนี้สามารถเกิดขึ้นได้หรือไม่ และถ้าเกิดขึ้นจะให้แก้ปัญหานี้อย่างไร |
| Superordinates | 1. ตรวจสอบความเป็นผู้ใช้ของระบบ 2. ตรวจสอบสิทธิการเข้าใช้งาน 3. เลือกผู้ป่วย 4. ตรวจสอบสิทธิประกันสุขภาพของผู้ป่วย 5. เลือกสถานบริการที่รับผู้ป่วย |
| Subordinates | 1. ส่งสัญญาณเตือนสถานบริการฝ่ายรับ |
| General Description |
2.2 สรุปการใช้งาน Usecase Diagram
ใน Usecase Diagram ประกอบด้วยสัญลักษณ์ 3 อย่างคือ
| ชื่อสัญลักษณ์ | รูปสัญลักษณ์ | คำอธิบายอย่างย่อ |
| Usecase |  | แสดงกรณีที่แอคเทอร์จะทำงานโต้ตอบกับระบบ และจะต้องมีผลลัพธ์บางอย่างเกิดขึ้นถ้าทำสำเร็จ |
| Actor |  | เป็นผู้กระทำกับระบบงาน โดยสั่งให้ระบบทำงานบางอย่างให้ อาจจะเป็นผู้ป้อนข้อมูลให้กับระบบ หรือเป็นผู้ที่ต้องการข้อมูลจากระบบก็ได้ |
| includes stereotype |  | รวมเอาอีก usecase หนึ่งที่ปลายลูกศรชี้ไปไว้ด้วยกัน แสดงให้เห็นว่าไปเรียกใช้งาน usecase อีกตัวหนึ่ง |
| extends stereotype |  | มี usecase ที่เกิดขึ้นเป็นกรณีพิเศษ ต่อไปจาก usecase ตัวนี้ ซึ่งทางปลายลูกศรจะชี้ไปที่อีก usecase หนึ่งที่เป็นกรณีพิเศษที่ไม่ค่อยจะพบบ่อยในการทำงานตามปกติ |