Use Case Diagram ไม่ใช่ Flowchart นะจะบอกให้

หลังจากไม่ได้เขียนบล็อกเสียนาน และหลัง ๆ นี้แทบไม่ได้เขียนเกี่ยวกับการพัฒนาโปรแกรมเลย วันนี้ก็ขอเขียนเสียหน่อยแล้วกัน แต่ก่อนอื่นขอเป็นกำลังใจให้กับชาวไทยทุกคนที่กำลังเผชิญกับปัญหาน้ำท่วมอยู่ตอนนี้นะครับ

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

ก่อนอื่นเรามาทบทวนกันก่อนว่า Use Case Diagram มีจุดประสงค์อะไร ซึ่งคิดว่าพวกเราคงตอบกันได้ว่ามันมีหน้าที่หลักในการแสดง Functional Requirement ของระบบ ตัว Use Case หนึ่ง Use Case เป็นตัวแทนของฟังก์ชันหลักฟังก์ชันหนึ่งของระบบ ดูก็ง่ายดีใช่ไหมครับ แล้วปัญหาใีนอยู่ตรงไหน ลองมาดูโจทย์ที่ผมได้ใช้ทดสอบผู้เข้ารับการอบรมกับผมกันก่อนครับ

  จงเขียน UML Diagram สำหรับระบบ ATM ที่่มีการทำงานคือฝากเงิน (Deposit) โอนเงิน (Transfer) และถอนเงิน (Withdraw) โดยจะต้องมีการตรวจสอบตัวตนของลูกค้าด้วย 

จากโจทย์ก็เป็นตัวอย่างพื้นฐานทั่วไป แต่มีผู้เข้ารับการอบรมหลายคนเขียน Use Case Diagram ในลักษณะนี้ครับ

Use Case Diagram แบบ Flowchart

ซึ่งผมก็ได้สอบถามว่าทำไมเขาถึงเขียนไดอะแกรม ในลักษณะนี้ คำตอบของเขาก็คือ ก็ทำตามโจทย์อาจารย์ ตรวจสอบสิทธิก่อนที่จะอนุญาตให้ทำธุรกรรมอย่างอื่น จะเห็นได้ชัดนะครับว่านี่คือความเข้าใจผิด ตัว Use Case Diagram ไม่ได้แสดงโฟลว์การทำงานว่าอะไรต้องทำก่อนอะไร อีกจุดหนึ่งที่ผมคิดว่าเป็นปัญหาของไดอะแกรมนี้ก็คือตัว Use Case ของเขาสองตัวคือ Enter Password และ Validate Password นั้นอยู่ในระดับที่ย่อยมากเกินไป

ถึงตรงนี้หลายคนก็อาจตั้งคำถามว่าแล้วเราควรจะเขียนอย่างไรดี ผมไม่ตอบดีไหมนี่ ทิ้งให้คิดเป็นการบ้าน มาเฉลยพรุ่งนี้ สวัสดีครับ ...... :)


ล้อเล่นน่ะครับ เฉลยเลยแล้วกันเดี๋ยวอึดอัดกันแย่ แนวทางหนึ่งที่จะเขียน Use Case Diagram สำหรับปัญหานี้ก็ตามนี้ครับ

Use Case Diagram สำหรับระบบ ATM อย่างง่าย 

จากไดอะแกรมนี้ผมได้รวมเอา Validate Password และ Enter Password เข้าด้วยกันเป็น Use Case ที่ชื่อว่า Authenticate และใช้ความสัมพันธ์  include เพื่อแสดงให้เห็นว่า Use Case ที่เหลือทั้งสามนั้นจะต้องมีการตรวจสอบตัวตนของผู้ถือบัตร ไดอะแกรมนี้แสดงความต้องการของระบบตรงตามที่โจทย์กำหนดได้อย่างชัดเจน และ Use Case Diagram ได้ทำหน้าที่หลักที่มันควรจะทำนั่นคือการแสดง Functional Requirement ของระบบ ไม่ได้แสดงโฟลว์การทำงาน อย่าลืมนะครับว่า Use Case Diagram เรามักจะสร้างขึ้นในช่วงวิเคราะห์ระบบ ซึ่งการวิเคราะห์ระบบควรจะตอบคำถามว่า "what" ซึ่งหมายความว่าระบบนี้ทำอะไรให้ได้เสียก่อน ไม่ใช่ไปตอบคำถามของคำว่า "how" ซึ่งหมายถึงว่ามันทำงานอย่างไร ถ้ามีแนวคิดนี้อยู่ในใจตลอดก็น่าจะหลีกเลี่ยงการเขียน Use Case Diagram ในลักษณะที่เป็น Flowchart ได้

หวังว่าบล็อกนี้จะทำให้มีความชัดเจนเกี่ยวกับ Use Case Diagram มากขึ้นไม่มากก็น้อยนะครับ ...