บทเรียนนี้อธิบายมุมมองเชิงพฤติกรรมของ UML โดยเน้น Sequence Diagram และ Communication Diagram เพื่อแสดงว่า Actor และ Object ส่ง Message ติดต่อกันอย่างไรในแต่ละ Use Case
บทที่ 6 อยู่ในกลุ่ม Behavioral Diagram โดยเจาะลึก Interaction Diagram
UML หรือ Unified Modeling Language เป็นภาษามาตรฐานในการสร้างแบบจำลองระบบเชิงวัตถุ ในการเรียน OOAD เราไม่ได้ใช้ UML เพียงเพื่อวาดรูป แต่ใช้เพื่อสื่อสารความเข้าใจระหว่างผู้ใช้ นักวิเคราะห์ระบบ นักออกแบบ และนักพัฒนา
ในสไลด์บทที่ 6 มีการอธิบายว่า UML 1.x มี 9 diagrams และ UML 2.x ขยายเป็น 14 diagrams โดยในรายวิชาจะเน้นแผนภาพที่ใช้บ่อย เช่น Use Case, Activity, Sequence, Communication, Class, State Machine, Component และ Deployment
สองมุมมองนี้ช่วยให้นักศึกษาแยกได้ว่าแผนภาพใดใช้ตอบคำถาม “ระบบมีอะไร” และแผนภาพใดใช้ตอบ “ระบบทำงานอย่างไร”
Static View คือมุมมองที่แสดงองค์ประกอบของระบบ เช่น Class, Object, Module, Database, Server และความสัมพันธ์ระหว่างองค์ประกอบเหล่านั้น
มุมมองนี้ตอบคำถามว่า “ระบบมีอะไร และแต่ละส่วนสัมพันธ์กันอย่างไร”
| แผนภาพ | ใช้แสดง |
|---|---|
| Class Diagram | Class, Attribute, Method, Relationship |
| Object Diagram | ตัวอย่างวัตถุที่เกิดจาก Class |
| Component Diagram | ส่วนประกอบหรือโมดูลของโปรแกรม |
| Deployment Diagram | การติดตั้งบน Server, Client, Network |
Dynamic View คือมุมมองที่แสดงการทำงาน ขั้นตอน การโต้ตอบ การส่ง Message หรือการเปลี่ยนสถานะของระบบ
มุมมองนี้ตอบคำถามว่า “ระบบทำงานตามลำดับอย่างไร และวัตถุติดต่อกันอย่างไร”
| แผนภาพ | ใช้แสดง |
|---|---|
| Use Case Diagram | ผู้ใช้ทำอะไรกับระบบ |
| Activity Diagram | Workflow หรือขั้นตอนการทำงาน |
| Sequence Diagram | ลำดับ Message ระหว่าง Actor/Object |
| Communication Diagram | โครงสร้างการสื่อสารระหว่าง Object |
แผนภาพเชิงพฤติกรรมใช้แสดงพฤติกรรม ขั้นตอน เหตุการณ์ การเปลี่ยนสถานะ และการโต้ตอบภายในระบบ
แสดงว่า Actor ต้องการทำอะไรกับระบบ ใช้ในช่วงวิเคราะห์ความต้องการ
แสดงขั้นตอนหรือ Workflow ของ Use Case เช่น เลือกสินค้า → ชำระเงิน → ยืนยันคำสั่งซื้อ
แสดงการโต้ตอบและการส่ง Message ระหว่าง Actor/Object เช่น Sequence และ Communication
แสดงสถานะของ Object และการเปลี่ยนสถานะ เช่น Order: รอชำระเงิน → ชำระแล้ว → จัดส่งแล้ว
แผนภาพปฏิสัมพันธ์ใช้แสดงว่า Actor และ Object ติดต่อสื่อสารกันอย่างไรผ่าน Message
ผู้ใช้หรือสิ่งภายนอกที่เข้ามาโต้ตอบกับระบบ เช่น ลูกค้า นักศึกษา ผู้ดูแลระบบ Payment Gateway, Email Server หรือ Barcode Scanner
วัตถุหรือส่วนประกอบภายในระบบที่รับ ส่ง หรือประมวลผลข้อมูล เช่น LoginForm, AuthController, UserDatabase, Session
ข้อความ คำสั่ง หรือการเรียกใช้ Method ที่ส่งจาก Actor/Object หนึ่งไปยังอีก Object หนึ่ง เช่น submitLogin(), validateUser(), checkPassword()
Sequence Diagram เน้นลำดับเวลาก่อน-หลังของ Message โดยอ่านจากบนลงล่าง
Sequence Diagram หรือแผนภาพลำดับ คือแผนภาพ UML ที่แสดงลำดับการโต้ตอบระหว่าง Actor และ Object ภายในระบบ โดยแสดงการส่ง Message จากวัตถุหนึ่งไปยังอีกวัตถุหนึ่งตามลำดับเวลา
จุดเด่นคือการอธิบายว่า ใครติดต่อกับใคร ส่ง Message อะไร และเกิดขึ้นก่อน-หลังอย่างไร ใช้ได้ดีเมื่ออธิบาย Use Case เช่น เข้าสู่ระบบ สมัครสมาชิก สั่งซื้อสินค้า ชำระเงิน หรือจองตั๋วหนัง
| Actor | ผู้ใช้หรือระบบภายนอกที่เริ่มต้นหรือร่วมในการทำงาน |
|---|---|
| Object / Participant | วัตถุหรือส่วนประกอบของระบบ เช่น Form, Controller, Service, Database |
| Lifeline | เส้นประแนวตั้ง แสดงช่วงเวลาการมีอยู่ของ Participant |
| Message | คำสั่งหรือ Method ที่ส่งระหว่าง Participant |
| Activation Bar | ช่วงเวลาที่ Object กำลังทำงานหรือประมวลผล |
| Return Message | เส้นประแสดงการส่งผลลัพธ์กลับ |
| Create / Destroy | Message ที่สร้างหรือทำลาย Object |
Message คือข่าวสาร คำสั่ง หรือการเรียกใช้ Method ที่ส่งระหว่าง Participant เพื่อให้ระบบทำงาน
เรียกใช้ Method หรือ Function เช่น User → TicketSystem: bookTicket()
ส่งผลลัพธ์กลับไปยังผู้เรียก มักแสดงด้วยเส้นประ เช่น returnConfirmation()
ส่งสัญญาณหรือแจ้งเหตุการณ์โดยไม่จำเป็นต้องรอผลลัพธ์ทันที เช่น alertUser()
สร้าง Object ใหม่ เช่น new Session(), createReportCard()
ทำลายหรือสิ้นสุด Object เช่น destroySession() เมื่อผู้ใช้ Logout
Object ส่ง Message กลับหาตัวเอง เช่น Interface แสดงรายการสินค้าหลังได้รับข้อมูล
| ประเภท | ความหมาย | ตัวอย่าง |
|---|---|---|
| Synchronous | ผู้ส่งรอจนผู้รับทำงานเสร็จแล้วตอบกลับ | AuthController → Database: checkPassword() |
| Asynchronous | ผู้ส่งไม่ต้องรอ ผู้รับอาจทำงานภายหลัง | OrderService → EmailService: sendEmail() |
| Return | ผลลัพธ์ที่ส่งกลับจากผู้รับไปยังผู้เรียก | Database -->> AuthController: userFound |
ใช้กรอบใน Sequence Diagram เพื่อแสดงเงื่อนไขพิเศษ เช่น ทางเลือก กรณีเสริม การทำซ้ำ และการทำงานพร้อมกัน
Alternative ใช้เมื่อมีหลายทางเลือก คล้าย if...else เช่น Login สำเร็จ / Login ไม่สำเร็จ
Optional ใช้เมื่อขั้นตอนอาจเกิดหรือไม่เกิดก็ได้ คล้าย if ที่ไม่มี else เช่น มีคูปองส่วนลด
Loop ใช้เมื่อทำซ้ำหลายครั้ง เช่น ตรวจสอบสินค้าแต่ละรายการในตะกร้า
Parallel ใช้เมื่อหลายงานเกิดพร้อมกัน เช่น ส่งอีเมล แจ้งเตือน และบันทึก Log
เลือก Use Case → อ่าน Main Flow → ระบุ Actor/Object → จัดลำดับ Message → เพิ่มเงื่อนไข → ตรวจสอบกับ Class Diagram
ไม่จำเป็นต้องเขียนทั้งระบบ เลือก Use Case ที่สำคัญก่อน
ดึงลำดับเหตุการณ์จาก Use Case Description
หา External Entity, Boundary, Control, Entity และ External System
Actor มักวางซ้ายสุด จากนั้นวาง Object ที่เกี่ยวข้อง
Message ด้านบนเกิดก่อน ด้านล่างเกิดทีหลัง
ใช้ Activation Bar, Return Message, alt, opt, loop, par ตามความจำเป็น
ถ้ามี Method หรือ Class ใหม่ ต้องปรับ Class Diagram ให้สอดคล้อง
ในการเลือกเขียน Interaction Diagram ไม่มีหลักตายตัว ควรเลือก Use Case หรือ Scenario ที่สำคัญและมีการโต้ตอบระหว่าง Object ชัดเจน
| 1 | User → LoginForm: กรอก Username/Password |
|---|---|
| 2 | LoginForm → AuthController: validateUser() |
| 3 | AuthController → UserDatabase: checkUser() |
| 4 | UserDatabase → AuthController: ส่งผลการตรวจสอบ |
| 5 | AuthController → LoginForm: ส่งผลลัพธ์ |
| 6 | LoginForm → User: แสดงผล Login สำเร็จ/ไม่สำเร็จ |
Communication Diagram หรือชื่อเดิม Collaboration Diagram เน้นความสัมพันธ์และการสื่อสารระหว่าง Object พร้อมหมายเลข Message
| ประเด็น | Sequence Diagram | Communication Diagram |
|---|---|---|
| จุดเน้น | ลำดับเวลาของ Message | ความสัมพันธ์ระหว่าง Object |
| การอ่านลำดับ | อ่านจากบนลงล่าง | อ่านจากหมายเลข Message |
| เหมาะกับ | Flow ที่ต้องเห็นก่อน-หลังชัดเจน | ระบบที่ต้องเห็นโครงสร้างการสื่อสาร |
| ข้อควรระวัง | ถ้า Message มากจะยาว | ถ้า Object มากและเส้นเยอะจะอ่านยาก |
Static ใช้อธิบายโครงสร้าง Dynamic ใช้อธิบายพฤติกรรมและการทำงาน
เช่น Use Case, Activity, State Machine และ Interaction Diagram
ประกอบด้วย Actor, Object, Message, Lifeline และ Activation
อ่านจากบนลงล่าง เหมาะกับการอธิบาย Flow ของ Use Case
อ่านลำดับจากหมายเลข Message เหมาะกับการมองความสัมพันธ์ของ Object
เมื่อเข้าใจ Interaction Diagram แล้ว จะสามารถตรวจสอบได้ว่า Class/Object ที่ออกแบบไว้มีการสื่อสารกันครบตาม Requirement และ Use Case หรือไม่