บทเรียนที่ 7 • Structural Modeling

แบบจำลองเชิงโครงสร้าง
Class & Object Diagram

เรียนรู้การออกแบบโครงสร้างของระบบเชิงวัตถุด้วย UML Class Diagram และ Object Diagram ตั้งแต่การค้นหา Class จาก Requirement/Use Case ไปจนถึง Association, Generalization, Aggregation และ Composition

Classแบบพิมพ์เขียวของวัตถุ
Objectตัวอย่างจริงจาก Class
Relationshipความสัมพันธ์ระหว่าง Class
Learning Path

จาก Requirement สู่ Class Diagram

1
Requirement Specification
ทำความเข้าใจระบบและขอบเขตปัญหา
2
Use Case Description
ดูว่าผู้ใช้ต้องการทำอะไรกับระบบ
3
Candidate Classes
ค้นหาคำนามสำคัญ ข้อมูล และบทบาท
4
Class/Object Diagram
กำหนด Attribute, Operation และ Relationship
ผู้สอน
ผู้ช่วยศาสตราจารย์ ดร. นัฐพงศ์ ส่งเนียม
Dr.nattapong_s@hotmail.com
7.1 Introduction

บทนำ Structural Modeling

แบบจำลองเชิงโครงสร้างใช้แสดงมุมมอง Static View ของระบบ โดยเน้นว่าระบบประกอบด้วยอะไรและแต่ละส่วนสัมพันธ์กันอย่างไร

Structural Model คืออะไร

Structural Model หรือแบบจำลองเชิงโครงสร้าง หมายถึงแบบจำลองที่ใช้แสดงองค์ประกอบคงที่ของระบบ เช่น Class, Attribute, Operation และ Relationship ระหว่าง Class จุดประสงค์สำคัญคือช่วยให้ทีมพัฒนาเข้าใจว่า ระบบมี “หน่วยข้อมูลหลัก” อะไรบ้าง แต่ละหน่วยมีข้อมูลและหน้าที่อะไร และเชื่อมโยงกับหน่วยอื่นอย่างไร

ในบทที่ 7 จะเน้น Static Structural Modeling สองประเภท คือ Class Diagram และ Object Diagram โดย Class Diagram เปรียบเหมือนแบบพิมพ์เขียวของระบบ ส่วน Object Diagram เป็นตัวอย่างข้อมูลจริงที่เกิดจากแบบพิมพ์เขียวนั้น ณ ช่วงเวลาหนึ่ง

หลักคิด: Structural Diagram ตอบคำถามว่า “ระบบประกอบด้วยอะไรบ้าง” ส่วน Behavioral Diagram ตอบคำถามว่า “ระบบทำงานอย่างไร”
วัตถุประสงค์การเรียนรู้
  • อธิบายความหมายของ Structural Modeling ได้
  • แยก Class Diagram กับ Object Diagram ได้
  • เขียน Class Name, Attribute, Operation และ Visibility ได้ถูกต้อง
  • อธิบาย Association, Role Name, Multiplicity และ Link ได้
  • เลือกใช้ Generalization, Aggregation และ Composition ได้เหมาะสม
  • สร้าง Class Diagram จาก Requirement และ Use Case ได้
ภาพประกอบ: จาก Requirement และ Use Case สู่ Class/Object Diagram
Analysis Process: Requirement → Use Case → Structural Model Requirementความต้องการของระบบ Use Caseผู้ใช้ทำอะไร Candidate Classคำนาม/ข้อมูลสำคัญ Class Diagramโครงสร้างระบบ Use Case เป็นแหล่งค้นหา Class, Attribute, Operation และ Relationship
แนวคิดจากสไลด์ที่อธิบายความเชื่อมโยง Requirement Specification → Use Case Diagram → Class Diagram
7.2 Class Diagram

Class Diagram: โครงสร้างของ Class

Class Diagram แสดง Class, Attribute, Operation และ Relationship เพื่อเป็นแบบพิมพ์เขียวสำหรับพัฒนาระบบ

ส่วนประกอบของ Class

สัญลักษณ์ Class ใน UML เป็นสี่เหลี่ยมแบ่ง 3 ส่วนหลัก ได้แก่

Class Nameชื่อคลาส เช่น Student, Customer, Product, Order
Attributeข้อมูลหรือคุณลักษณะ เช่น studentId, name, gpa, price
Operationพฤติกรรมหรือ Method เช่น registerCourse(), calculateGPA()
ข้อควรจำ: Attribute ควรเป็นข้อมูลที่เรียบง่าย ถ้าค่าที่เก็บเป็นวัตถุอีกประเภทหนึ่ง ควรสร้างเป็น Class แล้วเชื่อมด้วย Association แทนการยัดไว้เป็น Attribute
ภาพประกอบ: โครงสร้าง Class ใน UML
Student - studentId : String - name : String - gpa : Real + getName() : String + setName(name : String) : void + calculateGPA() : Real Class Name Attribute Operation Visibility + public - private # protected
Class แบ่งเป็น Class Name, Attribute และ Operation พร้อม Visibility +, -, #

Attribute Syntax

รูปแบบการเขียน Attribute คือ

visibility attributeName : Type

- studentId : String
- name : String
- age : Integer
- gpa : Real
- birthDate : Date

ในการออกแบบ UML ควรใช้ชนิดข้อมูลเชิงแนวคิด เช่น Textual, Integer, Floating-Point, Boolean, Date มากกว่าชนิดข้อมูลเฉพาะภาษา เช่น int16, double หรือ float ที่ผูกกับภาษาโปรแกรมบางภาษา

Operation Syntax

รูปแบบการเขียน Operation คือ

visibility operationName(parameterName : Type) : ReturnType

+ getName() : String
+ setName(name : String) : void
+ calculateGPA() : Real
+ registerCourse(courseId : String) : Boolean

Operation ควรเป็นคำกริยาที่บอกพฤติกรรม เช่น add, calculate, verify, register, approve และควรสอดคล้องกับ Message ใน Sequence Diagram

Analysis Class vs Design Class

ประเด็นAnalysis ClassDesign Class
จุดประสงค์เข้าใจปัญหาและขอบเขตเตรียมออกแบบเพื่อเขียนโปรแกรม
Attributeระบุข้อมูลสำคัญระบุ visibility และ data type
Operationอาจยังไม่ละเอียดมี method, parameter, return type
ตัวอย่างCustomer, Order, ProductCustomer, OrderController, OrderRepository

UML Primitive Types ที่ควรใช้

Textual / String Integer / Integral Floating-Point / Real Boolean Date Character
ข้อควรระวังจากสไลด์: UML ไม่ควรผูกติดกับภาษาโปรแกรมใดภาษาหนึ่ง ดังนั้นในขั้นวิเคราะห์และออกแบบควรหลีกเลี่ยง keyword หรือ type ที่เฉพาะเจาะจงของภาษา เช่น int16 ของ VB หรือ double ของ Java/C++ ถ้าระดับแบบจำลองยังไม่ถึงขั้น Implementation
7.3 Object Diagram

Object Diagram: ตัวอย่างวัตถุจริงจาก Class

Object Diagram แสดง instance ที่ถูกสร้างจาก Class ณ ช่วงเวลาหนึ่ง พร้อมค่าของ Attribute

Class vs Object

Class คือแบบพิมพ์เขียวหรือแม่แบบของวัตถุ เช่น Student, City, Person

Object คือสิ่งที่ถูกสร้างจาก Class เป็นตัวอย่างจริง เช่น somchai : Student หรือ Bangkok : City

ClassStudent
รูปแบบของนักศึกษาโดยทั่วไป
Objectsomchai : Student
นักศึกษาคนหนึ่งที่ชื่อสมชาย
Object nameobjectName : ClassName
SlotattributeName = value
ทำไม Object Diagram ไม่ต้องแสดง Operation? เพราะ Object ทุกตัวที่สร้างจาก Class เดียวกันมี Operation เหมือนกันอยู่แล้ว จึงแสดงเฉพาะชื่อวัตถุและค่าของ Attribute เพื่อให้ภาพอ่านง่าย
ภาพประกอบ: Class Diagram → Object Diagram
Class เป็นแบบ ส่วน Object เป็นตัวอย่างจริง City - name : String - country : String - population : Integer + setName(s : String) + getPopulation() Bangkok : City name = "Bangkok" country = "Thailand" population = 7534013 London : City name = "London" country = "UK" population = 2324320 Sydney : City name = "Sydney" country = "Australia" population = 3536000 «instanceOf» / is member of
ดัดแปลงจากตัวอย่าง City, London, Sydney, New York และ Bangkok ในสไลด์บทที่ 7
7.4 Association Relationship

Association, Role, Link และ Multiplicity

Association คือความสัมพันธ์ระหว่าง Class ส่วน Link คือความสัมพันธ์ระหว่าง Object จริง

Association คืออะไร

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

Multiplicity ที่ใช้บ่อย

สัญลักษณ์ความหมายตัวอย่าง
1มีได้ 1 เท่านั้นOrder เป็นของ Customer หนึ่งคน
0..1มีได้ 0 หรือ 1Employee อาจมีหัวหน้า 0 หรือ 1 คน
* / 0..*มีได้ 0 ตัวขึ้นไปCustomer มี Order ได้หลายรายการ
1..*มีอย่างน้อย 1 ตัวขึ้นไปOrder ต้องมี OrderLine อย่างน้อย 1 รายการ
2..5มีตั้งแต่ 2 ถึง 5 ตัวทีมหนึ่งมีสมาชิก 2–5 คน
ภาพประกอบ: Association, Role Name และ Multiplicity
Customer places Order Customer - customerId : String- name : String + getCreditRating() Order - orderNo : String- orderDate : Date + calculateTotal() places 1 0..* customer orders somchai : Customername = "สมชาย" order001 : OrderorderNo = "O001" Link
Association อยู่ระดับ Class ส่วน Link อยู่ระดับ Object Diagram
Reflexive Association

Class มีความสัมพันธ์กับ Class เดียวกันเอง เช่น Employee มี manager และ subordinate

Employee
manager 0..1 ── 0..* subordinate
Association Class

ใช้เมื่อความสัมพันธ์มีข้อมูลของตัวเอง เช่น Student ลงทะเบียน Course และต้องเก็บ grade/status

Student * ── * Course
Enrollment
- enrollDate : Date
- grade : String
Qualified Association

ใช้ qualifier หรือ key เพื่อระบุ Object ปลายทาง เช่น Bank ใช้ accountNo เพื่อค้นหา Account

Bank [accountNo] ── Account
Library [bookId] ── Book
7.5 Generalization & Specialization

ความสัมพันธ์แบบ IS-A

Generalization ใช้แสดงความสัมพันธ์ระหว่าง Superclass และ Subclass โดย Subclass เป็นชนิดหนึ่งของ Superclass

แนวคิดสำคัญ

  • Generalization คือการสรุปคลาสย่อยหลายคลาสขึ้นเป็นคลาสทั่วไป เช่น Dog, Cat → Animal
  • Specialization คือการแยกคลาสทั่วไปให้เป็นคลาสย่อยเฉพาะ เช่น Payment → CashPayment, CreditCardPayment
  • Inheritance คือ Subclass รับ Attribute และ Operation จาก Superclass
  • Polymorphism คือ Operation ชื่อเดียวกัน แต่ Subclass ทำงานแตกต่างกันได้
  • ใช้เมื่ออ่านได้ว่า “Subclass เป็น Superclass ประเภทหนึ่ง”
ไม่ควรใช้ Generalization: Car is an Engine ไม่ถูกต้อง เพราะรถยนต์ “มี” เครื่องยนต์ ควรใช้ Aggregation/Composition ไม่ใช่ IS-A
ภาพประกอบ: Generalization และ Polymorphism ของ Payment
Payment Generalization Payment - paymentId : String - amount : Real + pay(amount : Real) : Boolean CashPayment - cashReceived : Real + calculateChange() CreditCardPayment - cardNo : String + verifyCard() BankTransferPayment - transferRef : String + verifyTransfer() ทุก Subclass เป็น Payment ประเภทหนึ่ง และ override pay() ได้
ตัวอย่าง Payment–Cash/Credit และแนวคิด Polymorphism จากสไลด์ 7.5
ตัวอย่างที่ถูกต้อง
  • Manager is an Employee
  • Dog is an Animal
  • CashPayment is a Payment
ตัวอย่างที่ไม่ควรใช้ IS-A
  • Car is an Engine ❌
  • Student is a Course ❌
  • Order is a Product ❌
Single vs Multiple Inheritance

Single Inheritance คือ Subclass มี Superclass เดียว เช่น Dog → Animal ส่วน Multiple Inheritance คือ Subclass มี Superclass มากกว่าหนึ่ง เช่น TeachingAssistant อาจเป็นทั้ง Student และ Employee แต่ควรใช้อย่างระมัดระวัง

7.6 Aggregation & Composition

ความสัมพันธ์แบบ HAS-A / PART-OF

Aggregation และ Composition ใช้แสดง Whole–Part Relationship หรือความสัมพันธ์ระหว่างส่วนรวมกับส่วนประกอบ

Aggregation: เพชรโปร่ง

Aggregation เป็นความสัมพันธ์แบบ “มีส่วนประกอบ” ที่ค่อนข้างหลวม ส่วนประกอบอาจอยู่ได้แม้ Whole ไม่มีอยู่ หรืออาจถูกแบ่งใช้กับสิ่งอื่นได้

ตัวอย่าง: Company มี Department, Team มี Member, Smartphone มี Case หรือ Film ที่ถอดเปลี่ยนได้

Company ◇── Department
Smartphone ◇── Case

Composition: เพชรทึบ

Composition เป็นความสัมพันธ์แบบแน่น ส่วนประกอบมีวงจรชีวิตขึ้นกับ Whole ถ้า Whole ถูกทำลาย ส่วนประกอบมักถูกทำลายไปด้วย

ตัวอย่าง: Order ประกอบด้วย OrderLine, House ประกอบด้วย Room, Polygon ประกอบด้วย Point

Order ◆── OrderLine
House ◆── Room
ภาพประกอบ: Aggregation vs Composition
Whole–Part Relationship Aggregation: เพชรโปร่ง Composition: เพชรทึบ Smartphone Case ถอดเปลี่ยนได้ Order OrderLine ขึ้นกับใบสั่งซื้อ วิธีตัดสินใจเลือก Relationship 1) ถ้าอ่านว่า “เป็นชนิดหนึ่งของ” → Generalization (IS-A) 2) ถ้าอ่านว่า “เกี่ยวข้องกับ” ทั่วไป → Association 3) ถ้าอ่านว่า “มี/เป็นส่วนหนึ่งของ” และหลวม → Aggregation 4) ถ้า Part อยู่ไม่ได้ถ้า Whole ถูกทำลาย → Composition
สรุปจากสไลด์ 7.6 และหัวข้อ Association vs Aggregation / Generalization vs Aggregation
Car–Wheel

รถยนต์มีล้อ ความสัมพันธ์เป็น HAS-A / PART-OF ถ้าพิจารณาว่าล้อเป็นส่วนสำคัญของรถ อาจใช้ Composition หรือ Aggregation ตามขอบเขตระบบ

Order–OrderLine

ใบสั่งซื้อประกอบด้วยรายการสั่งซื้อ รายการมักไม่มีความหมายเมื่อไม่มีใบสั่งซื้อ จึงเหมาะกับ Composition

Smartphone–Battery

ถ้าแบตเตอรี่เป็นชิ้นส่วนภายในที่ผูกกับเครื่องมาก อาจใช้ Composition แต่ถ้าเป็นแบตเตอรี่ถอดเปลี่ยนได้อาจใช้ Aggregation

7.7 Building Class Diagram

แนวทางการสร้าง Class Diagram จาก Use Case

ไม่ควรคิด Class ขึ้นเองโดยไม่มีที่มา แต่ควรย้อนกลับไปที่ Requirement, Use Case และ Problem Domain

ขั้นตอนวิเคราะห์หา Class

1. ศึกษา Problem Domain

เข้าใจระบบจริง คำศัพท์ในงาน และขอบเขต

2. อ่าน Requirement Specification

แยก functional และ non-functional requirement

3. อ่าน Use Case Description

ดู Main Flow, Alternative Flow และข้อมูลที่ระบบต้องจัดเก็บ

4. ค้นหา Candidate Classes

คัดคำนามสำคัญ เช่น Customer, Product, Order, Payment

5. กำหนด Attribute และ Operation

Attribute จากข้อมูลที่ต้องเก็บ Operation จากพฤติกรรมของ Class

6. กำหนด Relationship

Association, Multiplicity, Generalization, Aggregation, Composition

7. ตรวจสอบกับ Sequence Diagram

Message ที่ส่งหากันควรมี Operation รองรับใน Class ที่ถูกเรียก

ภาพประกอบ: Class Diagram ระบบสั่งซื้อสินค้าออนไลน์
Example: Online Ordering Class Diagram Customer - customerId : String- name : String + placeOrder() Order - orderNo : String- orderDate : Date- status : String + calculateTotal() Product - productId : String- name : String- price : Real OrderLine - quantity : Integer- unitPrice : Real + subTotal() : Real Payment - amount : Real+ pay() : Boolean places10..* 11..*contains refers to0..*1 paid by0..11
ตัวอย่างนี้รวม Association, Multiplicity และ Composition ในระบบสั่งซื้อสินค้า

Checklist ตรวจงาน Class Diagram ของนักศึกษา

  • ชื่อ Class เป็นคำนามและสื่อความหมาย
  • ไม่ใส่ Class ที่ซ้ำหรือไม่เกี่ยวข้อง
  • Attribute มีชนิดข้อมูลเหมาะสม
  • Attribute ไม่ควรเป็น foreign key แบบฐานข้อมูล
  • Operation เป็นคำกริยาและสอดคล้อง Use Case
  • Visibility ใช้ +, -, # ถูกต้อง
  • Relationship มี Multiplicity ครบ
  • เลือก Association / Generalization / Aggregation / Composition ถูกความหมาย
7.8 Summary

สรุปบทเรียนที่ 7

Structural Modeling

ใช้แสดงโครงสร้างคงที่ของระบบ เช่น Class, Attribute, Operation และ Relationship

Class Diagram

เป็นแบบพิมพ์เขียวของระบบเชิงวัตถุ ใช้ออกแบบ Class และความสัมพันธ์

Object Diagram

เป็นตัวอย่างวัตถุจริงที่สร้างจาก Class ณ ช่วงเวลาหนึ่ง

Association

ใช้แสดงความสัมพันธ์ทั่วไป พร้อม Role Name, Link และ Multiplicity

Generalization / Aggregation / Composition

ใช้ตัดสินความสัมพันธ์แบบ IS-A, HAS-A และ PART-OF ให้เหมาะสม

แบบฝึกหัดท้ายบทที่ 7

  1. อธิบายความแตกต่างระหว่าง Structural Diagram และ Behavioral Diagram พร้อมยกตัวอย่าง
  2. เขียน Class Diagram ของ Student โดยมี studentId, name, gpa และ operation calculateGPA()
  3. สร้าง Object Diagram จาก Class Student อย่างน้อย 3 Object พร้อมค่าของ Attribute
  4. อธิบายความแตกต่างระหว่าง Association และ Link พร้อมตัวอย่าง
  5. ให้เขียน Association ระหว่าง Customer กับ Order พร้อม Multiplicity ที่เหมาะสม
  6. ออกแบบ Association Class สำหรับ Student ลงทะเบียน Course โดยเก็บ enrollDate, grade และ status
  7. เขียน Generalization ของ Payment โดยมี CashPayment และ CreditCardPayment เป็น Subclass
  8. เปรียบเทียบ Aggregation กับ Composition พร้อมตัวอย่าง Car–Wheel และ Order–OrderLine
  9. จากระบบโรงแรม ให้ค้นหา Candidate Class อย่างน้อย 8 Class และระบุ Relationship ที่สำคัญ
แนวทางทำงาน: เริ่มจาก Use Case Description แล้วคัดคำนามสำคัญเป็น Candidate Class จากนั้นกำหนด Attribute, Operation และ Relationship ก่อนตรวจสอบกับ Sequence Diagram ว่า Message ต่าง ๆ มี Method รองรับครบหรือไม่

ต่อยอดสู่การออกแบบระบบจริง

เมื่อเข้าใจ Class/Object Diagram แล้ว นักศึกษาจะสามารถออกแบบโครงสร้างระบบให้เชื่อมโยงกับ Use Case, Sequence Diagram และการพัฒนาโปรแกรมจริงได้อย่างเป็นระบบ