Software Modeling & System Design (UML)

guidelines ระบุชัดว่าต้อง วาดด้วยมือให้สะอาด — รู้จัก lifeline, execution box, provided/required interface และ alt/opt frame

UML คืออะไร

Structural vs Behavioral

ประเภทบอกอะไรตัวอย่าง
Structuralโครงสร้างคงที่ของระบบClass Diagram, Object Diagram, Component Diagram
Behavioralพฤติกรรมเคลื่อนไหวของระบบUse Case, Sequence, Activity Diagram

Use Case Diagram

บอกว่าใครใช้ระบบทำอะไรได้บ้าง และขอบเขตของระบบอยู่ตรงไหน

System boundary — E-commerce Customer Admin Browse Products Checkout Login Manage «include»

Actor = คน/องค์กร/ระบบภายนอก · วงรี = use case · กล่องใหญ่ = ขอบเขตระบบ · เส้น = association

องค์ประกอบรูปร่างความหมาย
Actorรูปคนแท่งผู้ใช้ระบบ อาจเป็นคน องค์กร หรือระบบภายนอก — ต้องอยู่นอกระบบและผลิตหรือใช้ข้อมูล
Use caseวงรีแนวนอนสิ่งที่ผู้ใช้ทำกับระบบได้
System boundaryกล่องสี่เหลี่ยมขอบเขตระบบ ทุกอย่างนอกกล่องถือว่าอยู่นอกขอบเขต
Associationเส้นตรงเชื่อม actor กับ use case ที่เกี่ยวข้อง
Packageรูปโฟลเดอร์จัดกลุ่มองค์ประกอบเข้าด้วยกัน

«include» vs «extend» — ข้อสอบถามแน่

«include»«extend»
ความหมายuse case หลัก ต้องเรียกใช้เสมอทำงาน เฉพาะบางเงื่อนไข (ทางเลือก)
บังคับไหมบังคับ 100%ไม่บังคับ
ทิศลูกศรจาก use case หลัก → ไป use case ย่อยจาก use case เสริม → ไป use case หลัก
ตัวอย่างCheckout «include» Login (ไม่ล็อกอินก็ซื้อไม่ได้)Checkout «extend» Apply Discount Code (ใส่โค้ดส่วนลดหรือไม่ก็ได้)
จำทิศลูกศรให้แม่น: include ชี้ออกจากตัวหลักไปหาตัวที่ถูกรวม ส่วน extend ชี้กลับเข้าหาตัวหลัก เพราะตัวเสริมเป็นฝ่ายไปต่อยอดให้

Activity Diagram

แสดง flow ของการควบคุม การตัดสินใจ และงานที่ทำขนานกัน — ทีละขั้นตั้งแต่ต้นจนจบ

Initial node คลิก Add to Cart สินค้านี้อยู่ใน ตะกร้าแล้วหรือยัง [yes] quantity + 1 [no] push object ใหม่ (qty=1) saveToLocalStorage() Final node

วงกลมทึบ = จุดเริ่ม · สี่เหลี่ยมมุมมน = action · สี่เหลี่ยมข้าวหลามตัด = decision · วงกลมมีขอบ = จุดจบ

สัญลักษณ์ความหมาย
Initial Nodeวงกลมทึบ = จุดเริ่มต้น
Action / Activityสี่เหลี่ยมมุมมน = งานที่ต้องทำ
Control Flowลูกศรบอกลำดับการทำงาน
Decision Nodeสี่เหลี่ยมข้าวหลามตัด = แตกเงื่อนไข
Fork / Joinแท่งทึบหนา = แตก (fork) หรือรวม (join) งานที่ทำขนานกัน
Final Nodeวงกลมมีวงล้อม = จุดจบ
Swimlaneคอลัมน์แนวตั้ง/นอน แบ่งกิจกรรมตามผู้รับผิดชอบ
Activity diagram ต่างจาก flowchart: activity diagram แสดง parallel processing (fork/join) และการโต้ตอบที่ซับซ้อนได้ ขณะที่ flowchart มักเป็นเส้นตรง

Sequence Diagram

บอกว่า object คุยกันอย่างไร เรียงตามเวลาจากบนลงล่าง ใช้ map ลำดับการเรียก API

User Browser (UI) Server / API Database lifeline activation / execution box requestProducts() fetch('/api/products') SELECT * FROM products rows 200 OK + JSON renderProducts() alt [data ไม่พบ] → 404 + แสดง "No results"

เส้นทึบหัวลูกศรเต็ม = synchronous call · เส้นประ = return message · แท่งบน lifeline = activation

องค์ประกอบ Sequence Diagram

องค์ประกอบรูปร่างความหมาย
Participant (Actor/Object)สี่เหลี่ยมด้านบนสุดใครหรืออะไรที่กำลังโต้ตอบ เช่น User, System, Database
Lifelineเส้นประแนวตั้งการมีอยู่ของ object ตลอดช่วงเวลา
Messageลูกศรแนวนอนการสื่อสาร — synchronous, asynchronous หรือ return
Activation Boxสี่เหลี่ยมผอมบน lifelineช่วงที่ object นั้นกำลังทำงานอยู่จริง
Fragmentกรอบสี่เหลี่ยมมีป้ายมุมบนซ้ายlogic ซับซ้อน เช่น alt, opt, loop

alt / opt / loop

Fragmentเทียบกับโค้ดใช้เมื่อไร
altif / elseมีทางเลือกตั้งแต่ 2 ทางขึ้นไป เช่น login สำเร็จ / ล้มเหลว
optif เดี่ยว ๆทำหรือไม่ทำก็ได้ เช่น ใส่โค้ดส่วนลด
loopfor / whileทำซ้ำ เช่น วนแสดงสินค้าทีละชิ้น
Best practice จากสไลด์: อย่าใส่รายละเอียดจนรก และลำดับบนลงล่างต้องสะท้อนเวลาจริง

Component Diagram

เป็น structural diagram แสดงว่าระบบประกอบด้วยส่วนอะไร แต่ละส่วนให้บริการหรือต้องการบริการอะไร

Frontend SPA «component» required provided IProductAPI Product Service «component» วงกลมทึบ = provided interface (ให้บริการ) · ครึ่งวงกลม = required interface (ต้องการบริการ) "ซ็อกเก็ตเสียบเข้ากับลูกบอล" — ฝั่งที่ต้องการเสียบเข้ากับฝั่งที่ให้บริการ System boundary cut = เส้นแบ่งว่าอะไรอยู่ในระบบเรา อะไรเป็นระบบภายนอก

ถ้าถูกถามให้ระบุ interface: ลูกบอล = provided (ผู้ให้) · ซ็อกเก็ต = required (ผู้ขอ)

ตัวอย่างที่ต้องวาดได้ (จากสไลด์)

สถานการณ์ไดอะแกรมที่เหมาะเหตุผล
ผู้ใช้ทั่วไปกับสมาชิกทำอะไรได้บ้างUse Caseบอกขอบเขตและสิทธิ์ของแต่ละ actor
ขั้นตอนการสมัครสมาชิกActivityมีเงื่อนไขและทางแยกหลายทาง
ขั้นตอนการ loginSequenceเน้นลำดับการคุยกันระหว่าง client, server, DB
โหลดสินค้ามาแสดงบนหน้าเว็บSequenceป้ายลูกศร: requestProducts(), fetch(), return JSON, renderProducts()
ค้นหา/กรองสินค้าActivityUser Action → Capture Input → Filter Array → Update DOM
ตรรกะ checkoutLogic Map / Decision Treeตรวจหลายเงื่อนไขต่อกันเป็นชั้น
คำถามชวนคิดที่สไลด์ย้ำ: ไดอะแกรมของคุณมี loading state ไหม ถ้าโหลดข้อมูลไม่ได้จะเกิดอะไร และระหว่างข้อมูลกำลังเดินทางผู้ใช้เห็นอะไร — ข้อสอบอัตนัยชอบถามเคสเหล่านี้

แนวข้อสอบอัตนัย

โจทย์: จงวาด/อธิบาย sequence diagram ของการ login พร้อมระบุ lifeline, activation box และ alt fragment และอธิบายว่าเกิดอะไรขึ้นเมื่อรหัสผ่านไม่ถูกต้อง

โครงคำตอบ

  1. Participants — Client (Browser), API Gateway / Server, Database
  2. ลำดับข้อความ — POST /login {credentials} (ระบุว่าเข้ารหัสด้วย HTTPS) → findUser(email) → DB คืน hash → bcrypt.compare() ภายใน server → jwt.sign(payload, secret) → ตอบกลับ {token} → client เก็บ token
  3. alt fragment — สาขาแรก [รหัสถูก] ตอบ 200 พร้อม token · สาขาที่สอง [รหัสผิดหรือไม่พบผู้ใช้] ตอบ 401 พร้อมข้อความกลาง ๆ ว่า "Invalid email or password"
  4. เหตุผลเชิงความปลอดภัย — ใช้ข้อความเดียวกันทั้งสองกรณีเพื่อกัน user enumeration ไม่ให้ผู้โจมตีรู้ว่าอีเมลนี้มีอยู่จริงในระบบ
← หัวข้อก่อน: Architecture หัวข้อถัดไป: Client-Side →