บทเรียนนี้อธิบาย UML: Unified Modeling Language ในฐานะภาษามาตรฐานสำหรับสร้างแบบจำลองระบบ ครอบคลุม Software Modeling, ประเภทของ Model, มุมมองของ UML และภาพรวมแผนภาพสำคัญ เช่น Class, Object, Use Case, Sequence, Collaboration, Component, Deployment, State และ Activity Diagram
บทเรียนนี้เป็นบทเริ่มต้นของการใช้ UML ในรายวิชาการวิเคราะห์และออกแบบระบบเชิงวัตถุ โดยเชื่อมโยงจากบทก่อนหน้าเรื่อง Object-Oriented, Abstraction และ Unified Process ให้เห็นว่า เมื่อทีมพัฒนาต้องสื่อสารระบบที่ซับซ้อนร่วมกัน จำเป็นต้องมี “ภาษากลาง” สำหรับอธิบายโครงสร้าง พฤติกรรม การติดตั้ง และการทำงานของระบบในรูปแบบที่ทุกฝ่ายเข้าใจตรงกัน
ในสไลด์บทที่ 4 เริ่มจากการทบทวนความรู้เดิม เช่น Abstraction ทั้ง 4 แบบ, SQL, SDLC และแนวคิด Divide & Conquer จากนั้นเข้าสู่ Software Modeling ซึ่งเป็นการสร้างแบบจำลองเพื่อช่วยวิเคราะห์ ออกแบบ และสื่อสารแนวคิดของระบบ แล้วจึงอธิบายว่า UML คืออะไร มีประวัติความเป็นมาอย่างไร มีมุมมองและแผนภาพประเภทใดบ้าง
บทนี้ไม่ใช่เพียงการจำชื่อแผนภาพ UML แต่ต้องเข้าใจว่าแผนภาพแต่ละชนิด “ตอบคำถามอะไร” เช่น Use Case ตอบว่าผู้ใช้ต้องการทำอะไร, Class Diagram ตอบว่าโครงสร้างระบบมีคลาสอะไร, Sequence Diagram ตอบว่าการโต้ตอบเกิดตามลำดับเวลาอย่างไร และ Deployment Diagram ตอบว่าระบบถูกติดตั้งบนโหนดใดบ้าง
Modeling คือการสร้างแบบจำลองเพื่อให้เข้าใจปัญหา สื่อสารแนวคิด และออกแบบระบบก่อนพัฒนาเป็นโปรแกรมจริง
Modeling คือวิธีการวิเคราะห์และออกแบบระบบโดยสร้างแบบจำลองขึ้นมาแทนระบบจริง จุดมุ่งหมายคือทำให้ผู้เกี่ยวข้องเข้าใจปัญหาและแนวทางแก้ปัญหาได้ง่ายขึ้น โดยเฉพาะระบบซอฟต์แวร์ที่มีข้อมูล กระบวนการ ผู้ใช้ ฟังก์ชัน และความสัมพันธ์จำนวนมาก
ในสไลด์อธิบาย Modeling หลายรูปแบบ ได้แก่ Textual Modeling เช่น รหัสเทียม, Mathematics Modeling เช่น สูตรหรือสมการ และ Visual Modeling คือการใช้สัญลักษณ์รูปภาพเพื่อสร้างแบบจำลอง ซึ่ง UML อยู่ในกลุ่ม Visual Modeling
ใช้ข้อความอธิบายตรรกะ เช่น รหัสเทียม Pseudocode, คำอธิบายขั้นตอน หรือ Use Case Description
ใช้สูตร สมการ หรือสัญลักษณ์ทางคณิตศาสตร์ เช่น ผลรวม ค่าเฉลี่ย หรือโมเดลการคำนวณ
ใช้ภาพและสัญลักษณ์ เช่น UML Diagram เพื่อช่วยให้ทีมเข้าใจระบบตรงกัน
UML (Unified Modeling Language) คือภาษาสำหรับสร้างแบบจำลองเชิงวัตถุที่ใช้สัญลักษณ์และแผนภาพมาตรฐาน เพื่อสื่อสารแนวคิดการวิเคราะห์และออกแบบระบบให้ทีมพัฒนา ผู้ใช้ และผู้เกี่ยวข้องเข้าใจตรงกัน UML สามารถใช้ประกอบเอกสารทางเทคนิค เช่น Programmer Manual, Technical Manual และเอกสารออกแบบระบบ
อย่างไรก็ตาม UML ไม่ใช่ภาษาโปรแกรม เช่น Java, C#, VB หรือ Python และ ไม่ใช่กระบวนการพัฒนาระบบ เพราะ UML ไม่บังคับว่าจะต้องใช้ขั้นตอนแบบใดหรือภาษาใดในการเขียนโปรแกรม โครงการหนึ่งอาจใช้ UML ร่วมกับ UP, Agile, Waterfall หรือกระบวนการอื่นได้ตามความเหมาะสม
UML ไม่ควรยึดชนิดข้อมูลของภาษาใดภาษาหนึ่ง เช่น real ของ Pascal หรือ float/double ของ Java/C เพราะ UML ควรเป็นกลางต่อภาษาโปรแกรม
| Textual | ข้อความหรือสายอักขระ เช่น ชื่อ ที่อยู่ รหัส |
|---|---|
| Character | ตัวอักษรเดี่ยว |
| Integral | จำนวนเต็ม เช่น อายุ จำนวนสินค้า |
| Floating-Point | จำนวนทศนิยม เช่น ราคา รายได้ ยอดเงิน |
| Boolean | ค่าจริง/เท็จ เช่น TaxPaid |
| Date | วันที่ เช่น วันเกิด วันที่สั่งซื้อ |
UML เกิดจากการรวมแนวคิดเชิงวัตถุหลายสายให้กลายเป็นมาตรฐานเดียว
ในช่วงทศวรรษ 1970-1990 แนวคิดเชิงวัตถุมีวิธีการและสัญลักษณ์หลายแบบ ทำให้เกิดปัญหาการสื่อสารระหว่างทีม เพราะแต่ละวิธีใช้สัญลักษณ์ไม่เหมือนกัน สไลด์เรียกช่วงนี้ว่า Method Wars
ต่อมา Grady Booch, Jim Rumbaugh และ Ivar Jacobson หรือที่เรียกว่า Three Amigos ได้รวมแนวคิดสำคัญ ได้แก่ Booch Method, OMT และ OOSE เข้าด้วยกันที่ Rational Software และเสนอ UML ไปยัง OMG เพื่อให้เป็นมาตรฐานสำหรับสร้างแบบจำลองเชิงวัตถุ
UML ใช้อธิบายระบบจากหลายมุมมอง เพื่อให้ผู้เกี่ยวข้องแต่ละกลุ่มมองเห็นสิ่งที่ตนสนใจ
ในบทเรียนนี้เน้นภาพรวม 9 แผนภาพหลัก โดยแบ่งเป็น Structural Diagrams และ Behavioral Diagrams
ใช้แสดงโครงสร้างแบบค่อนข้างคงที่ของระบบ เช่น คลาส อ็อบเจกต์ องค์ประกอบไฟล์ และโครงสร้างการติดตั้ง
โครงสร้างคลาสและความสัมพันธ์
ตัวอย่าง Object ณ ช่วงเวลาใดเวลาหนึ่ง
องค์ประกอบซอฟต์แวร์และ dependency
โหนด ฮาร์ดแวร์ และการติดตั้ง
ใช้แสดงพฤติกรรม การโต้ตอบ ลำดับเวลา สถานะ และกระแสกิจกรรมของระบบ
ฟังก์ชันที่ผู้ใช้ต้องการจากระบบ
ลำดับการส่ง Message ตามเวลา
การทำงานร่วมกันของ Object
สถานะและกระแสงานของระบบ
สองแผนภาพนี้เป็นพื้นฐานสำคัญของ UML เพราะใช้แสดงโครงสร้างของระบบเชิงวัตถุ
Class Diagram ใช้แสดงโครงสร้างของคลาส คุณลักษณะ เมธอด และความสัมพันธ์ระหว่างคลาส เช่น Association, Aggregation, Dependency และ Generalization เป็นแผนภาพที่อยู่ในมุมมอง Logical View และใช้มากทั้งในขั้นวิเคราะห์และออกแบบ
ส่วนประกอบหลักของ Class คือ Class Name, Attributes และ Operations
โดยสามารถระบุ Visibility เช่น + public, - private และ # protected
รูปแบบทั่วไปของ Attribute คือ visibility attribute_name : type
ส่วน Operation คือ visibility operationName(parameter:type) : result type
Object Diagram ใช้แสดงวัตถุจริงหรือ Instance ของคลาสในช่วงเวลาหนึ่ง เป็นเหมือนภาพ Snapshot ของระบบ โดยแสดงชื่อ Object, ชื่อ Class, ค่าของ Attribute และ Link ระหว่าง Object
ตัวอย่างเช่น Class Diagram อาจเขียนว่า “ลูกค้าเป็นลูกค้าของธนาคาร” ส่วน Object Diagram จะระบุสถานการณ์เฉพาะ เช่น “นัฐพงศ์:ลูกค้า เป็นลูกค้าของ ทหารไทย:ธนาคาร”
สองแผนภาพนี้ใช้มองระบบในเชิงกายภาพและการติดตั้งจริง
Component Diagram ใช้อธิบายซอฟต์แวร์หรือองค์ประกอบของระบบ เช่น Source Code, Executable, Database File, DLL, Library และ Report เพื่อให้ผู้พัฒนาต่อเข้าใจว่าโปรแกรมประกอบด้วยไฟล์หรือโมดูลใดบ้าง
สไลด์ยกตัวอย่าง Course.dll, People.dll, Register.exe, Billing.exe และ Billing System แสดงให้เห็นความสัมพันธ์ขององค์ประกอบซอฟต์แวร์ในระดับ Physical View
Deployment Diagram ใช้แสดงสถาปัตยกรรมของระบบในลักษณะ Physical Architecture เช่น เครื่อง Client, Application Server, Database Server, Network, Protocol และ Component ที่ติดตั้งในแต่ละ Node
แผนภาพนี้สำคัญตอนติดตั้งระบบและมักอยู่ใน Technical Manual หรือ Programmer Manual เพื่อให้ผู้ติดตั้งเข้าใจโครงสร้างเครื่องและการเชื่อมต่อ
แผนภาพกลุ่มนี้ช่วยอธิบายพฤติกรรมของระบบ การโต้ตอบ และลำดับการทำงาน
Use Case Model ใช้ในขั้นตอนเก็บ Requirement โดยแสดงฟังก์ชันหรือการกระทำที่ระบบต้องรองรับจากมุมมองผู้ใช้ ประกอบด้วย Actor, Use Case, Communicates-Association และ System Boundary
สไลด์ยกตัวอย่างระบบ ATM ที่มี Bank Customer, Cashier, Maintenance Crew และ use case เช่น Deposit Funds, Withdraw Cash, Transfer Funds และ Maintain ATM
Sequence Diagram เน้นลำดับเวลา เหมาะกับ Requirement ที่ต้องบอกว่าอะไรทำก่อน-หลัง เช่น ผู้ใช้เลือกสินค้า เว็บไซต์เรียกข้อมูลจาก Server, Server ดึงข้อมูลจาก Database แล้วส่งผลกลับมาแสดง
Collaboration Diagram หรือใน UML 2 เรียกว่า Communication Diagram เน้นความสัมพันธ์และการร่วมทำงานของ Object มากกว่าการเรียงเวลาแบบชัดเจน ใช้ดูว่า Object ตัวใดติดต่อกับ Object ตัวใด และมี Message อะไรเกิดขึ้นระหว่างกัน
| Sequence | Collaboration / Communication |
|---|---|
| เน้นลำดับเวลา | เน้นความสัมพันธ์และการสื่อสาร |
| เหมาะกับขั้นตอนที่ต้องทำก่อน-หลัง | เหมาะกับการมองภาพรวมการทำงานร่วมกัน |
| ใช้ Lifeline และ Message | ใช้ Object Link และ Message Number |
ใช้อธิบายสถานะของ Object หรือระบบ และเหตุการณ์ที่ทำให้เปลี่ยนสถานะ เช่น คำสั่งซื้ออาจมีสถานะ Draft → Confirmed → Paid → Shipped → Completed หรือ Cancelled
เหมาะกับระบบที่มีสถานะชัดเจน เช่น ระบบคำสั่งซื้อ ระบบจองคิว ระบบสมัครสมาชิก หรือระบบควบคุมอุปกรณ์
Activity Diagram ใช้แสดงลำดับกระแสกิจกรรมของการทำงาน เช่น ขั้นตอนการลงทะเบียน ขั้นตอนการสั่งพิมพ์เอกสาร หรือขั้นตอนการสั่งซื้อสินค้า ประกอบด้วย Initial State, Action State, Control Flow, Decision, Fork/Join, Swimlane และ Final State
สไลด์ยกตัวอย่าง Operation “print” ที่มีการตรวจสอบ disk full ถ้าพื้นที่เต็มจะแสดงข้อความแจ้งเตือน ถ้ามีพื้นที่ว่างจึงสร้าง postscript file และสั่งพิมพ์
แบ่งได้เป็น Textual, Mathematics และ Visual Modeling
ไม่ใช่ภาษาโปรแกรม และไม่ใช่กระบวนการพัฒนาระบบ
Booch, OMT และ OOSE ถูกพัฒนาเป็นมาตรฐาน UML
Use-case, Logical, Component, Concurrency และ Deployment View
Class ดูโครงสร้าง, Use Case ดูความต้องการ, Sequence ดูลำดับเวลา, Activity ดูกระแสงาน
บทถัดไปสามารถต่อยอดไปสู่การวิเคราะห์ Requirement และ Use Case หรือเจาะลึกแผนภาพ UML แต่ละชนิดเพื่อใช้ในโครงงานรายวิชา