เรียนรู้การออกแบบโครงสร้างของระบบเชิงวัตถุด้วย UML Class Diagram และ Object Diagram ตั้งแต่การค้นหา Class จาก Requirement/Use Case ไปจนถึง Association, Generalization, Aggregation และ Composition
แบบจำลองเชิงโครงสร้างใช้แสดงมุมมอง Static View ของระบบ โดยเน้นว่าระบบประกอบด้วยอะไรและแต่ละส่วนสัมพันธ์กันอย่างไร
Structural Model หรือแบบจำลองเชิงโครงสร้าง หมายถึงแบบจำลองที่ใช้แสดงองค์ประกอบคงที่ของระบบ เช่น Class, Attribute, Operation และ Relationship ระหว่าง Class จุดประสงค์สำคัญคือช่วยให้ทีมพัฒนาเข้าใจว่า ระบบมี “หน่วยข้อมูลหลัก” อะไรบ้าง แต่ละหน่วยมีข้อมูลและหน้าที่อะไร และเชื่อมโยงกับหน่วยอื่นอย่างไร
ในบทที่ 7 จะเน้น Static Structural Modeling สองประเภท คือ Class Diagram และ Object Diagram โดย Class Diagram เปรียบเหมือนแบบพิมพ์เขียวของระบบ ส่วน Object Diagram เป็นตัวอย่างข้อมูลจริงที่เกิดจากแบบพิมพ์เขียวนั้น ณ ช่วงเวลาหนึ่ง
Class Diagram แสดง Class, Attribute, Operation และ Relationship เพื่อเป็นแบบพิมพ์เขียวสำหรับพัฒนาระบบ
สัญลักษณ์ Class ใน UML เป็นสี่เหลี่ยมแบ่ง 3 ส่วนหลัก ได้แก่
| Class Name | ชื่อคลาส เช่น Student, Customer, Product, Order |
|---|---|
| Attribute | ข้อมูลหรือคุณลักษณะ เช่น studentId, name, gpa, price |
| Operation | พฤติกรรมหรือ Method เช่น registerCourse(), calculateGPA() |
รูปแบบการเขียน Attribute คือ
ในการออกแบบ UML ควรใช้ชนิดข้อมูลเชิงแนวคิด เช่น Textual, Integer, Floating-Point, Boolean, Date มากกว่าชนิดข้อมูลเฉพาะภาษา เช่น int16, double หรือ float ที่ผูกกับภาษาโปรแกรมบางภาษา
รูปแบบการเขียน Operation คือ
Operation ควรเป็นคำกริยาที่บอกพฤติกรรม เช่น add, calculate, verify, register, approve และควรสอดคล้องกับ Message ใน Sequence Diagram
| ประเด็น | Analysis Class | Design Class |
|---|---|---|
| จุดประสงค์ | เข้าใจปัญหาและขอบเขต | เตรียมออกแบบเพื่อเขียนโปรแกรม |
| Attribute | ระบุข้อมูลสำคัญ | ระบุ visibility และ data type |
| Operation | อาจยังไม่ละเอียด | มี method, parameter, return type |
| ตัวอย่าง | Customer, Order, Product | Customer, OrderController, OrderRepository |
Object Diagram แสดง instance ที่ถูกสร้างจาก Class ณ ช่วงเวลาหนึ่ง พร้อมค่าของ Attribute
Class คือแบบพิมพ์เขียวหรือแม่แบบของวัตถุ เช่น Student, City, Person
Object คือสิ่งที่ถูกสร้างจาก Class เป็นตัวอย่างจริง เช่น somchai : Student หรือ Bangkok : City
| Class | Student รูปแบบของนักศึกษาโดยทั่วไป |
|---|---|
| Object | somchai : Student นักศึกษาคนหนึ่งที่ชื่อสมชาย |
| Object name | objectName : ClassName |
| Slot | attributeName = value |
Association คือความสัมพันธ์ระหว่าง Class ส่วน Link คือความสัมพันธ์ระหว่าง Object จริง
Association คือเส้นความสัมพันธ์ที่เชื่อมระหว่าง Class ตั้งแต่ 2 Class ขึ้นไป เพื่อแสดงว่าวัตถุของ Class เหล่านั้นเกี่ยวข้องกันได้ เช่น Customer places Order, Student enrolls Course หรือ Employee works for Department
| Association Name | ชื่อความสัมพันธ์ เช่น places, enrolls, teaches, works for |
|---|---|
| Role Name | ชื่อบทบาทที่ปลาย Association เช่น owner/ownedCar, advisor/advisee |
| Link | ความสัมพันธ์ระดับ Object เช่น somchai : Customer เชื่อมกับ order001 : Order |
| Multiplicity | จำนวน Object ที่เชื่อมโยงกันได้ เช่น 1, 0..1, *, 1..*, 2..5 |
| สัญลักษณ์ | ความหมาย | ตัวอย่าง |
|---|---|---|
| 1 | มีได้ 1 เท่านั้น | Order เป็นของ Customer หนึ่งคน |
| 0..1 | มีได้ 0 หรือ 1 | Employee อาจมีหัวหน้า 0 หรือ 1 คน |
| * / 0..* | มีได้ 0 ตัวขึ้นไป | Customer มี Order ได้หลายรายการ |
| 1..* | มีอย่างน้อย 1 ตัวขึ้นไป | Order ต้องมี OrderLine อย่างน้อย 1 รายการ |
| 2..5 | มีตั้งแต่ 2 ถึง 5 ตัว | ทีมหนึ่งมีสมาชิก 2–5 คน |
Class มีความสัมพันธ์กับ Class เดียวกันเอง เช่น Employee มี manager และ subordinate
ใช้เมื่อความสัมพันธ์มีข้อมูลของตัวเอง เช่น Student ลงทะเบียน Course และต้องเก็บ grade/status
ใช้ qualifier หรือ key เพื่อระบุ Object ปลายทาง เช่น Bank ใช้ accountNo เพื่อค้นหา Account
Generalization ใช้แสดงความสัมพันธ์ระหว่าง Superclass และ Subclass โดย Subclass เป็นชนิดหนึ่งของ Superclass
Single Inheritance คือ Subclass มี Superclass เดียว เช่น Dog → Animal ส่วน Multiple Inheritance คือ Subclass มี Superclass มากกว่าหนึ่ง เช่น TeachingAssistant อาจเป็นทั้ง Student และ Employee แต่ควรใช้อย่างระมัดระวัง
Aggregation และ Composition ใช้แสดง Whole–Part Relationship หรือความสัมพันธ์ระหว่างส่วนรวมกับส่วนประกอบ
Aggregation เป็นความสัมพันธ์แบบ “มีส่วนประกอบ” ที่ค่อนข้างหลวม ส่วนประกอบอาจอยู่ได้แม้ Whole ไม่มีอยู่ หรืออาจถูกแบ่งใช้กับสิ่งอื่นได้
ตัวอย่าง: Company มี Department, Team มี Member, Smartphone มี Case หรือ Film ที่ถอดเปลี่ยนได้
Composition เป็นความสัมพันธ์แบบแน่น ส่วนประกอบมีวงจรชีวิตขึ้นกับ Whole ถ้า Whole ถูกทำลาย ส่วนประกอบมักถูกทำลายไปด้วย
ตัวอย่าง: Order ประกอบด้วย OrderLine, House ประกอบด้วย Room, Polygon ประกอบด้วย Point
รถยนต์มีล้อ ความสัมพันธ์เป็น HAS-A / PART-OF ถ้าพิจารณาว่าล้อเป็นส่วนสำคัญของรถ อาจใช้ Composition หรือ Aggregation ตามขอบเขตระบบ
ใบสั่งซื้อประกอบด้วยรายการสั่งซื้อ รายการมักไม่มีความหมายเมื่อไม่มีใบสั่งซื้อ จึงเหมาะกับ Composition
ถ้าแบตเตอรี่เป็นชิ้นส่วนภายในที่ผูกกับเครื่องมาก อาจใช้ Composition แต่ถ้าเป็นแบตเตอรี่ถอดเปลี่ยนได้อาจใช้ Aggregation
ไม่ควรคิด Class ขึ้นเองโดยไม่มีที่มา แต่ควรย้อนกลับไปที่ Requirement, Use Case และ Problem Domain
เข้าใจระบบจริง คำศัพท์ในงาน และขอบเขต
แยก functional และ non-functional requirement
ดู Main Flow, Alternative Flow และข้อมูลที่ระบบต้องจัดเก็บ
คัดคำนามสำคัญ เช่น Customer, Product, Order, Payment
Attribute จากข้อมูลที่ต้องเก็บ Operation จากพฤติกรรมของ Class
Association, Multiplicity, Generalization, Aggregation, Composition
Message ที่ส่งหากันควรมี Operation รองรับใน Class ที่ถูกเรียก
ใช้แสดงโครงสร้างคงที่ของระบบ เช่น Class, Attribute, Operation และ Relationship
เป็นแบบพิมพ์เขียวของระบบเชิงวัตถุ ใช้ออกแบบ Class และความสัมพันธ์
เป็นตัวอย่างวัตถุจริงที่สร้างจาก Class ณ ช่วงเวลาหนึ่ง
ใช้แสดงความสัมพันธ์ทั่วไป พร้อม Role Name, Link และ Multiplicity
ใช้ตัดสินความสัมพันธ์แบบ IS-A, HAS-A และ PART-OF ให้เหมาะสม
เมื่อเข้าใจ Class/Object Diagram แล้ว นักศึกษาจะสามารถออกแบบโครงสร้างระบบให้เชื่อมโยงกับ Use Case, Sequence Diagram และการพัฒนาโปรแกรมจริงได้อย่างเป็นระบบ