3. Static Diagram
จากภาพที่ 1 เราจะเห็นว่า UML แบ่งไดอะแกรมออกเป็น 2 ส่วนคือส่วนที่เป็น Static Diagram และ Dynamic Diagram ในหัวข้อนี้จะกล่าวถึงเฉพาะแต่ส่วนที่เป็น Static Diagram เท่านั้น ซึ่งสถาปนิกซอฟแวร์จะใช้ Static Diagram เพื่อออกแบบโครงสร้างของระบบงาน ใน Static Diagram จะมีไดอะแกรมอยู่ 4 ตัวคือ Class Diagram, Object Diagram, Component Diagram และ Deployment Diagram ที่ได้กล่าวถึงวัตถุประสงค์การใช้งานไว้แล้วในหัวข้อที่ 1.
สัญลักษณ์ส่วนใหญ่ที่ปรากฏอยู่ใน Class Diagram ซึ่งถือว่าเป็นหัวใจสำคัญสำหรับการออกแบบระบบที่เป็น Object-Oriented เนื่องจากระบบที่เป็น Object-Oriented จะประกอบด้วยวัตถุหลาย ๆ ชนิดทำงานร่วมกัน เพื่อให้ได้ผลลัพธ์ตามเป้าหมายที่ Usecase ได้กำหนดไว้ ในเอกสารฉบับนี้จะไม่ได้เน้นแนวคิดของการออกแบบซอฟแวร์เชิงวัตถุ (ซึ่งได้กล่าวถึงไว้ในเอกสาร แนวคิดการออกแบบซอฟแวร์เชิงวัตถุ แล้ว) แต่จะเน้นไปที่ความหมายของสัญลักษณ์แต่ละตัวที่ใช้ใน Static Diagram เช่น สัญลักษณ์ของ Class สัญลักษณ์ของ Object และสัญลักษณ์อื่น ๆ ที่จะกล่าวถึงอีกต่อไป
3.1 Class
การออกแบบเชิงวัตถุจะกำหนดให้คลาสเป็นแม่แบบของวัตถุ และวัตถุที่สร้างขึ้นจากคลาสจะมีแอททริบิวท์และเมธอดเหมือนกับที่ออกแบบไว้ในคลาส ดังนั้นคลาสจึงเป็นส่วนประกอบหลักของการออกแบบโครงสร้างซอฟแวร์เชิงวัตถุ
รูปภาพ 16 สัญลักษณ์ของคลาส
ในภาพที่ 16 จะเห็นว่าเวลาที่วาดรูปคลาสใน UML จะใช้สี่เหลี่ยมและแบ่งคลาสออกเป็น 3 ส่วนคือ ส่วนบนสุดคือชื่อคลาส ส่วนตรงกลางเป็นที่วางของรายการแอททริบิวท์ และส่วนด้านล่างสุดเป็นที่วางของรายการเมธอด แม้ว่าเราจะเขียนคลาสให้ประกอบด้วยแอททริบิวท์และเมธอด แต่แท้ที่จริงแล้วแอททริบิวท์และเมธอดที่ปรากฏให้เห็นในคลาสจะเกิดขึ้นจริงก็ต่อเมื่อเรานำคลาสนี้ไปสร้างเป็นวัตถุ แล้วใช้งานวัตถุเท่านั้น ดังนั้นในภาษาโปรแกรมอย่างเช่น Java จึงเรียกแอททริบิวท์ว่า instance variable (ตัวแปรอินสแตนซ์) และเรียกส่วนที่เป็นเมธอดว่า instance method (อินสแตนซ์เมธอด)
รูปภาพ 17 ตัวอย่างการแสดงผลรายละเอียดของคลาสในแบบต่าง ๆ
จากภาพที่ 17 จะเห็นว่าในการวาดสัญลักษณ์คลาสใน UML อาจจะให้ปรากฏเฉพาะแค่เพียงบางส่วนก็ได้ เช่นในรูป d. จะซ่อน (Suppress) ส่วนที่เป็นแอททริบิวท์และเมธอดไว้เพื่อให้เห็นเฉพาะชื่อคลาส มักจะใช้แสดงผลในไดอะแกรมที่นำเสนอแต่ภาพรวม ในรูป c. จะแสดงผลเฉพาะรายการเมธอดและซ่อนส่วนที่เป็นแอททริบิวท์ไว้ ซึ่งมักจะแสดงผลในไดอะแกรมที่ต้องการให้ไคลเอ็นต์โค้ดเห็นเฉพาะ public interface ที่สามารถเรียกใช้งานได้ ในรูป b. จะแสดงผลเฉพาะรายการแอททริบิวท์ และซ่อนส่วนที่เป็นเมธอดไว้มักจะปรากฏในไดอะแกรมที่เตรียมไว้เพื่อแมปข้อมูลไปเก็บในฐานข้อมูล และในรูป a. เป็นการแสดงรายละเอียดทั้งหมดของคลาส ซึ่งมักจะแสดงไว้ใน Detailed Design Specification ที่พร้อมสำหรับให้โปรแกรมเมอร์นำไปเข้ารหัสโปรแกรม
จากประสบการณ์ในการออกแบบซอฟแวร์ เราอาจจะแบ่งคลาสออกได้ตามวัตถุประสงค์การใช้งาน หลายประเภท เช่น
1. Domain Classs[4] เป็นคลาสที่ใช้สำหรับสร้าง Domain Object ที่จะใช้แทนวัตถุที่มีอยู่จริงในระบบ และเป็นของระบบงานนั้นเอง คลาสเหล่านี้มักจะมีหน้าที่เป็นตัวแทน (Representative) ให้กับคน วัตถุ สิ่งของ ที่มีอยู่ในโลกความจริง (Real-world) และมีอยู่ในระบบงานที่เรากำลังวิเคราะห์และออกแบบ คลาสเหล่านี้มักจะพบได้จากการวิเคราะห์ระบบ หรือวิเคราะห์ Problem Statement ที่ย่อยมาจากความต้องการของระบบอีกที ตัวอย่างของโดเมนคลาสในระบบส่งต่อผู้ป่วยเช่น คลาส Patient, Hospital, Card และ User
2. Business Logic Class[5] เป็นคลาสที่ใช้สำหรับสร้างวัตถุที่เป็น Business Object เพื่อให้รับผิดชอบดำเนินการตามขั้นตอนที่ระบบงานนั้น ๆ ได้กำหนดเอาไว้ เช่นในระบบส่งต่อผู้ป่วย ขั้นตอนการบันทึกการส่งต่อผู้ป่วย อาจจะรับผิดชอบโดยวัตถุที่สร้างมาจากคลาสชื่อว่า PatientTransferManager ซึ่งจะทำหน้าที่ควบคุมการส่งต่อผู้ป่วยตั้งแต่ตอนเริ่มต้นจนกระทั่งเสร็จกระบวนการเลยก็ได้
3. Presentation Class[6] เป็นคลาสที่อยู่ที่ส่วนแสดงผล และส่วนที่ติดต่อกับผู้ใช้ (User Interface) คลาสเหล่านี้จะนำไปสร้างวัตถุที่ใช้สำหรับรับข้อมูลเข้า และใช้สำหรับแสดงผล ตัวอย่างของ Presentation Class ในระบบส่งต่อผู้ป่วยเช่นคลาสชื่อ PatientTransferForm ที่ใช้สำหรับเป็นแบบฟอร์มบันทึกข้อมูลผู้ป่วยส่งต่อ
รูปภาพ 18 ตัวอย่างการแยกประเภทคลาสเพื่อรับผิดชอบในกระบวนการส่งต่อผู้ป่วย
นอกจากประเภทคลาส 3 ประเภทดังที่กล่าวมาแล้วนี้ ยังมีวิธีการแบ่งประเภทคลาสที่หนังสืออีกหลายเล่มเกี่ยวกับการออกแบบเชิงวัตถุได้แบ่งประเภทเอาไว้
ตารางที่ 3 ตัวอย่างการแบ่งประเภทคลาสที่สถาปนิกซอฟแวร์ผู้มีประสบการณ์ได้เคยแนะนำไว้
| วิธีการคิดแบบ | ประเภทคลาสที่เกิดขึ้น |
| MVC | Model, View, Controller |
| Peter Coad [UML In Color 2000] | Party or thing, Role, Moment-Interval, Catalog likes description |
| Enterprise JavaBeans | Entity Bean, Session Bean |
| Rumbaugh | Boundary, Controller, Entity |
3.1.1 Attribute
เป็นส่วนข้อมูลของวัตถุ ซึ่งจะเกิดขึ้นเมื่อเรานำคลาสไปสร้างเป็นวัตถุ วัตถุจะมีพื้นที่สำหรับเก็บข้อมูลแอททริบิวท์แต่ละตัวเป็นของตัวเอง แอททริบิวท์ที่เป็นของวัตถุชิ้นหนึ่งจะเป็นของวัตถุชิ้นนั้นไม่ได้แบ่งกันใช้กับวัตถุตัวอื่นในระบบ[7] บางครั้งเราเรียกส่วนแอททริบิวท์นี้ว่า State เนื่องจากแอททริบิวท์จะเก็บข้อมูลของวัตถุ และอาจจะมีค่าเปลี่ยนไปตามการใช้งานของวัตถุ ในขณะที่วัตถุมีสถานะหนึ่งก็จะมีค่าของแอททริบิวท์อยู่แบบหนึ่งและเมื่อวัตถุเปลี่ยนสถานะไปก็จะมีค่าของแอททริบิวท์เปลี่ยนไปเป็นอีกแบบหนึ่ง
ตัวอย่างของการออกแบบแอททริบิวท์ให้กับวัตถุ เช่น วัตถุผู้ป่วยในภาพที่ 17 จะประกอบด้วยแอททริบิวท์ id ที่ใช้สำหรับเก็บรหัสผู้ป่วย แอททริบิวท์ name ที่ใช้สำหรับเก็บชื่อ-นามสกุลผู้ป่วย แอททริบิวท์ personId ใช้สำหรับเก็บรหัสบัตรประจำตัวประชาชน แอททริบิวท์ age ใช้สำหรับเก็บอายุของผู้ป่วย แอททริบิวท์ sex ใช้สำหรับเก็บเพศของผู้ป่วย และแอททริบิวท์ occupation ใช้สำหรับเก็บอาชีพของผู้ป่วย
ใน UML จะมีรูปแบบในการเขียนแอททริบิวท์ ดังต่อไปนี้
[visibility] attribute-name [: type [ = default-value] ]
ความหมายของส่วนประกอบแต่ละส่วนในการเขียนแอททริบิวท์มีดังนี้
1. visibility หมายถึงความสามารถในการมองเห็นตัวแอททริบิวท์นี้ว่าจะยอมให้มองเห็นและเรียกใช้งานได้จากตำแหน่งใดบ้าง ซึ่งจะมีสัญลักษณ์ได้ 3 อย่างดังนี้
เครื่องหมาย – หมายถึง private เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้เท่านั้น
เครื่องหมาย + หมายถึง public เป็นการกำหนดให้มองเห็นได้จากทุกตำแหน่งในโปรแกรมซึ่งก็คือคลาสอื่นจะสามารถมองเห็นพวกที่เป็น public และสามารถเรียกใช้งานได้ด้วย
เครื่องหมาย # หมายถึง protected เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้ และเฉพาะคลาสลูกที่สืบทอดต่อไปจากคลาสนี้เท่านั้น (ดูรายละเอียดในเรื่อง Inhertiance)
2. attribute-name คือชื่อของแอททริบิวท์ซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้
3. type คือชนิดของแอททริบิว์ซึ่งอาจจะมีชนิดเป็น String (ตัวอักษร) หรือ integer (จำนวนเต็ม) หรือ double (เลขทศนิยมแบบความแม่นยำสองเท่า) หรือ float (เลขทศนิยมแบบความแม่นยำต่ำ) หรือ boolean (ค่าตรรก เป็นได้สองค่าจริงกับเท็จเท่านั้น) รวมทั้งสามารถเป็นชื่อคลาสหรือชื่ออินเตอร์เฟสที่เราได้ออกแบบไว้แล้วก็ได้ ในการกำหนดชนิดของแอททริบิวท์นี้มักจะไปลงรายละเอียดกันในระดับของ Detailed Design เมื่อได้ตกลงใจแล้วว่าจะใช้แพลตฟอร์มใดสำหรับพัฒนาระบบ
4. default-value คือค่าดีฟอลต์ที่จะกำหนดให้กับแอททริบิวท์ตั้งแต่ตอนที่วัตถุถูกสร้างขึ้นครั้งแรกซึ่งอาจจะเป็นค่าอะไรก็ได้แล้วแต่ข้อกำหนดของระบบงาน ปกติแล้วมักจะไปใส่ในขั้น Detailed Design
ตัวอย่างของการเขียนแอททริบิวท์เช่น
รูปภาพ 19 ตัวอย่างการเขียนแอททริบิวท์ในรูปแบบต่าง ๆ
ในภาพที่ 19 เป็นตัวอย่างของการเขียนแอททริบิวท์ ให้กับคลาส Hospital ซึ่งสามารถอธิบายได้ดังนี้
1. แอททริบิวท์ชื่อ id มี visibility เป็น private และมีชนิดข้อมูลเป็นตัวอักษร
2. แอททริบิวท์ชื่อ name มี visibility เป็น protected และมีชนิดข้อมูลเป็นตัวอักษร
3. แอททริบิวท์ชื่อ type มี visibility เป็น public และมีชนิดข้อมูลเป็นตัวอักษร และมีค่าดีฟอลต์เริ่มต้นเป็นคำว่า PROVINCE
4. แอททริบิวท์ชื่อ provinceId มี visibility เป็น protected และมีชนิดข้อมูลเป็นตัวอักษร
5. แอททริบิวท์ชื่อ province มี visibility เป็น private และมีชนิดข้อมูลเป็นคลาสชื่อ Province ซึ่งแสดงให้เห็นว่าตัวแปร province นี้ใช้สำหรับเป็นตัวแปรอ้างอิงเพื่อใช้อ้างอิงวัตถุ Province ได้
3.1.2 Method
เป็นส่วนพฤติกรรมของวัตถุ ในส่วนนี้จะบอกให้เรารู้ว่าวัตถุสามารถทำอะไรได้บ้าง ซึ่งการกระทำของวัตถุส่วนใหญ่จะถูกออกแบบให้กระทำกับข้อมูลที่เก็บอยู่ในตัววัตถุนั้นเอง ในขณะที่ไคลเอ็นต์โค้ดเรียกใช้ให้วัตถุทำงาน ไคลเอ็นต์จะต้องเรียกใช้เมธอด (Method Call) และผ่านค่าอาร์กิวเมนต์ใปให้ตามรายการพารามิเตอร์ที่เมธอดต้องการ เมื่อทำงานจนกระทั่งจบเมธอดแล้วเมธอดบางตัวอาจจะมีค่าที่ส่งคืนกลับมา (Return Value) เพื่อให้ไคลเอ็นต์โค้ดนำค่านั้นกลับไปใช้งานต่อก็ได้
ใน UML เราจะมีรูปแบบในการเขียนเมธอด ดังต่อไปนี้
[visibility] method-name([param-name : type, param-name : type, … ]) [ : return-type ]
ความหมายของส่วนประกอบแต่ละส่วนในการเขียนเมธอดมีดังนี้
1. visibility หมายถึงความสามารถในการมองเห็นตัวเมธอดนี้ว่าจะยอมให้มองเห็นและเรียกใช้งานได้จากตำแหน่งใดบ้าง ซึ่งจะมีสัญลักษณ์ได้ 3 อย่างดังนี้
เครื่องหมาย – หมายถึง private เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้เท่านั้น
เครื่องหมาย + หมายถึง public เป็นการกำหนดให้มองเห็นได้จากทุกตำแหน่งในโปรแกรมซึ่งก็คือคลาสอื่นจะสามารถมองเห็นพวกที่เป็น public และสามารถเรียกใช้งานได้ด้วย
เครื่องหมาย # หมายถึง protected เป็นการกำหนดให้มองเห็นได้เฉพาะในคลาสเดียวกันนี้ และเฉพาะคลาสลูกที่สืบทอดต่อไปจากคลาสนี้เท่านั้น (ดูรายละเอียดในเรื่อง Inhertiance)
2. method-name คือชื่อของเมธอดซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้
3. param-name คือชื่อของพารามิเตอร์ซึ่งเราอาจจะกำหนดให้มีชื่ออะไรก็ได้แต่จะต้องไม่ไปซ้ำกับชื่อพารามิเตอร์ตัวอื่นที่อยู่ในวงเล็บเดียวกันนี้
4. param-type คือชนิดข้อมูลของพารามิเตอร์
5. return-type คือชนิดของค่าส่งคืน ว่าค่าที่ได้กลับมาเมื่อทำงานจนจบเมธอดแล้วจะมีชนิดข้อมูลเป็นชนิดอะไร ซึ่งอาจจะเป็น String, integer, double หรือ อื่น ๆ ดังที่ได้กล่าวมาแล้ว
เราจะสังเกตเห็นว่ารูปแบบการเขียนเมธอดจะคล้ายกับเขียนแอททริบิวท์ แต่จะแตกต่างกันตรงที่เมธอดจะต้องมีวงเล็บตามหลังชื่อเมธอด และภายในวงเล็บจะเป็นรายการพารามิเตอร์ ในกรณีที่เมธอดนั้นไม่มีรายการพารามิเตอร์เรายังคงจำเป็นต้องใส่วงเล็บไว้เพื่อบอกให้ทราบว่าเป็นเมธอดด้วย ตัวอย่างเช่น ถ้าเรามีเมธอดชื่อ print() เรายังคงเขียนให้มีวงเล็บเปิดปิดต่อท้ายชื่อเมธอดไว้ แม้ว่าจะไม่มีพารามิเตอร์แม้แต่ตัวเดียวก็ตาม พารามิเตอร์แต่ละตัวที่กำหนดให้ไว้เป็นในวงเล็บจะคั่นกันด้วยเครื่องหมายคอมมา (,) และท้ายเมธอดจะมีชนิดของค่าส่งคืนเพื่อบอกให้ผู้ที่จะนำเมธอดนี้ไปใช้งานเตรียมตัวแปรที่มีชนิดเดียวกันไว้สำหรับรับค่าที่จะส่งกลับมาเมื่อทำงานจนจบเมธอด
รูปภาพ 20 ตัวอย่างการเขียนเมธอดแบบต่าง ๆ
จากภาพที่ 20 แสดงให้เห็นวิธีการเขียนเมธอดแบบต่าง ๆ ซึ่งสามารถอธิบายได้ดังนี้
1. เมธอดชื่อ transferPatient มี visibility เป็น public และรับพารามิเตอร์ 2 ตัวคือ user มีชนิดข้อมูลเป็น User และ form มีชนิดข้อมูลเป็น PatientTransferForm เมื่อทำงานจนจบเมธอดแล้วจะส่งคืนค่ากลับมาเป็น boolean ซึ่งจะมีค่าเป็น true หรือ false
2. เมธอดชื่อ transferPatient มี visibility เป็น private และรับพารามิเตอร์ 1 ตัวคือ form มีชนิดข้อมูลเป็น PatientTransferForm เมธอดนี้ไม่มีค่าส่งคืน
3. เมธอดชื่อ isValidUser มี visibility เป็น public และรับพารามิเตอร์ 2 ตัวคือ username มีชนิดข้อมูลเป็นตัวอักษร และพารามิเตอร์ชื่อ password มีชนิดข้อมูลเป็นตัวอักษรเช่นเดียวกัน เมื่อเมธอดนี้ทำงานจนจบจะได้ค่าส่งคืนกลับมามีชนิดข้อมูลเป็นวัตถุ User
4. เมธอดชื่อ getUser มี visibility เป็น protected และรับพารามิเตอร์ตัวเดียวคือ username มีชนิดข้อมูลเป็นตัวอักษร และเมื่อทำงานจนจบเมธอดจะได้ค่าส่งคืนกลับมามีชนิดข้อมูลเป็นวัตถุ User
3.2 Object
ปกติแล้วเราจะวาดสัญลักษณ์ของวัตถุไว้ใน Object Diagram ซึ่งหน้าที่ของสัญลักษณ์ Object จะใช้เพื่อจำลองแบบวัตถุที่จะถูกสร้างขึ้นจากคลาส โดยวัตถุที่ถูกสร้างขึ้นจะต้องมีแอททริบิวท์ตามที่คลาสกำหนดไว้ เมื่อวัตถุถูกสร้างขึ้นเราจะต้องกำหนดให้มีตัวแปรอ้างอิง (Reference Variable) อ้างอิงไว้ที่วัตถุตัวนั้นเพื่อใช้สำหรับเข้าถึงแอททริบิวท์และเมธอดที่อยู่ภายในตัววัตถุ
รูปภาพ 21 ตัวอย่างของวัตถุที่ถูกสร้างขึ้นจากคลาส Patient
จากภาพที่ 21 จะสังเกตได้ว่าเวลาที่เราเขียนวัตถุจะใช้สัญลักษณ์สี่เหลี่ยมเช่นเดียวกับการเขียนคลาส แต่บริเวณด้านบนสุดจะต้องเขียนชื่อของตัวแปรอ้างอิงและคลาสของวัตถุนั้นกำกับไว้ด้วย พร้อมกับขีดเส้นใต้เพื่อแสดงว่าเป็นวัตถุ บริเวณด้านล่างจะเขียนรายการค่าของแอททริบิวท์แต่ละตัว ซึ่งส่วนใหญ่เราจะสมมุติขึ้นเพื่อให้คล้ายกับเวลาที่ใช้งานระบบจริง ตามตัวอย่างในภาพที่ 21 เราจะเห็นว่าวัตถุตัวหนึ่งจะมีตัวแปรอ้างอิงกี่ตัวก็ได้ที่อ้างอิงอยู่ที่วัตถุตัวนั้นเช่นวัตถุ Patient ในภาพทางขวามือมีตัวแปรอ้างอิงอยู่ 2 ตัวคือ b และ c
นอกจากนี้เราจะสังเกตเห็นว่าเวลาที่เขียนภาพของวัตถุเราจะไม่แสดงส่วนที่เป็นเมธอด เนื่องจากเมธอดเป็นส่วนที่จะมีรูปแบบเหมือนกันในวัตถุทุกตัวที่เกิดจากคลาสเดียวกัน ซึ่งถ้าผู้อ่านไดอะแกรมอยากจะรู้ว่าวัตถุมีเมธอดอะไรให้เรียกใช้งานได้บ้าง เค้าจะต้องไปอ่านจากใน Class Diagram สำหรับส่วนแอททริบิวท์จะต้องเขียนให้กับวัตถุด้วย เนื่องจากวัตถุแต่ละตัวจะมีค่าของแอททริบิวท์ไม่เหมือนกันแม่ว่าจะถูกสร้างมาจากคลาสเดียวกันก็ตาม
รูปภาพ 22 ตัวอย่างการเขียนวัตถุแบบย่อ
ภาพที่ 22 แสดงให้เห็นว่าเราสามารถเขียนภาพวัตถุได้หลายแบบ แบบ Full details เป็นแบบที่เราแสดงรายละเอียดของวัตถุครบทั้งหมด คือมีรายการแอททริบิวท์และค่าของแอททริบิวท์แต่ละตัวด้วย สำหรับแบบ Short-form เราจะแสดงเฉพาะชื่อตัวแปรอ้างอิงและชนิดของวัตถุ และแบบที่เราไม่แสดงชื่อตัวแปรอ้างอิงแต่จะต้องแสดงชนิดของวัตถุไว้ด้วยเสมอ แบบนี้เราเรียกว่า Anonymous Object ทั้งสองแบบหลังเป็นการเขียนวัตถุแบบย่อ ซึ่งมักจะปรากฏให้เห็นใน Sequence Diagram และ Collaboration Diagram
3.3 Association
เป็นความสัมพันธ์ระหว่างวัตถุ คือวัตถุตั้งแต่ชิ้นเดียวหรือหลาย ๆ ชิ้นมาเกี่ยวข้องสัมพันธ์กันด้วยเหตุผลบางอย่าง เวลาที่วัตถุมาเกี่ยวข้องกันเราจะเขียนเส้นเชื่อมโยงระหว่างคลาสของวัตถุทั้งสองชนิดนี้ ซึ่งเราเรียกเส้นเชื่อมโยงนี้ว่า Association
ตัวอย่างของความสัมพันธ์ระหว่างวัตถุ เช่นความสัมพันธ์ระหว่างวัตถุผู้ใช้กับวัตถุระบบ ความสัมพันธ์ระหว่างวัตถุผู้ป่วยกับวัตถุสถานบริการ ความสัมพันธ์ระหว่างวัตถุผู้ป่วยกับวัตถุบันทึกการรักษา และอื่น ๆ อีกมากมายที่จะพบได้จากการวิเคราะห์ระบบ
รูปภาพ 23 ตัวอย่าง Association ที่เกิดขึ้นกับวัตถุ Hospital และ Patient
ในภาพที่ 23 เราจะเห็นว่าความสัมพันธ์ที่เกิดกับวัตถุ h1 และ a คือ h1 เป็นวัตถุ Hospital และ a เป็นวัตถุ Patient โดยวัตถุ h1 ส่งวัตถุ a ไปให้วัตถุ h2 รับไปรักษาต่อ
รูปภาพ 24 ตัวอย่างความสัมพันธ์ระหว่างวัตถุ Hospital และวัตถุ Patient แต่เขียนในรูปคลาส
ในภาพที่ 24 เป็นภาพใน Class Diagram ที่ลากเส้นเชื่อมโยงระหว่างคลาส Hospital และคลาส Patient
เนื่องจากวัตถุ Hospital และวัตถุ Patient มีความสัมพันธ์กันดังที่ปรากฏในภาพที่ 23
เรื่องของความสัมพันธ์ระหว่างวัตถุมีรายละเอียดปลีกย่อยอีกมากมาย ซึ่งจะขอกล่าวถึงในหัวข้อต่อไปนี้
3.3.1 Association Name
Associtation Name คือชื่อที่เรากำกับไว้บนเส้น Assocation เพื่อแสดงให้เห็นว่าวัตถุทั้งสองตัวนี้สัมพันธ์กันด้วยการกระทำอะไร ดังนั้น ส่วนใหญ่แล้วเราจึงตั้งชื่อ Association Name ให้ขึ้นต้นด้วยคำกริยา (Verb) และเวลาที่อ่านจะมีหัวลูกศรกำกับไว้ว่าให้อ่านจากวัตถุฝั่งไหนไปที่ฝั่งไหน ตัวอย่างของ Association Name เช่นในภาพที่ 24 เราจะเห็นว่าวัตถุ Patient ทำความสัมพันธ์กับวัตถุ Hospital โดยเหตุผลที่มากระทำกันก็คือ วัตถุ Hospital ส่ง (Send) วัตถุ Patient ต่อไปให้อีกที่หนึ่ง และวัตถุ Hospital อีกตัวหนึ่งรับ (Receive) วัตถุ Patient ไว้รักษาพยาบาลต่อไป ถ้าไม่มีหัวลูกศรกำกับทิศทางการอ่าน ปกติแล้วเราจะอ่านจากซ้ายไปขวาและบนลงล่าง
บางครั้งการใส่ไว้แค่ Association Name อาจจะไม่ทำให้ความสัมพันธ์ชัดเจนหรือเข้าใจง่ายเพียงพอ
รูปภาพ 25 แม้ว่าจะใส่ Association Name ให้แล้วแต่ความหมายยังไม่ชัดเจน
ตัวอย่างในภาพที่ 25 จะเห็นความสัมพันธ์ที่เกิดจากวัตถุ Person มาสัมพันธ์กันโดยวัตถุ Person มาแต่งงาน (marries) กับวัตถุ Person อีกคนหนึ่ง จากภาพแม่ว่าเราจะใส่ Association Name ให้แล้วก็ตามแต่รายละเอียดอื่น ๆ ก็ยังคงเป็นข้อสงสัย เช่น เราไม่รู้ว่า Person คนไหนที่เป็น สามี (Husband) และ Person คนไหนที่เป็น ภรรยา (Wife) เป็นต้น ซึ่งปัญหาดังกล่าวนี้เราจะกล่าวถึงในเรื่อง Role Name ต่อไป
3.3.2 Role Name
เมื่อวัตถุมาทำความสัมพันธ์กันด้วยกริยาบางอย่าง จะทำให้เกิดบทบาทขึ้นกับวัตถุทั้งสองตัวที่มาทำความสัมพันธ์ กันตัวอย่างเช่น ถ้าวัตถุ Person มาทำกริยา สอน วัตถุ Person อีกคนหนึ่ง วัตถุคนแรกจะรับบทบาทเป็นครู (Teacher) และวัตถุคนที่สองจะรับบทบาทเป็นนักเรียน (Student) เป็นต้น
รูปภาพ 26 ตัวอย่างการใส่ Role Name เพื่อให้ความสัมพันธ์ชัดเจนขึ้น
ในภาพที่ 26a เป็นตัวอย่างการใส่ Role Name ให้กับความสัมพันธ์ระหว่างวัตถุ Hospital และวัตถุ Patient เมื่อวัตถุ Hospital ส่งวัตถุ Patient ออกไปจะรับบทบาทเป็น sender และตัว Patient จะรับบทบาทเป็น sent patient (ผู้ป่วยที่ถูกส่งต่อ) สำหรับเส้นล่างเมื่อวัตถุ Hospital รับวัตถุ Patient เข้ามารักษาพยาบาลต่อ วัตถุ Hospital จะรับบทบาทเป็น receiver (ผู้รับ) และวัตถุ Patient จะรับบทบาทเป็น received patient (ผู้ป่วยที่ถูกรับเข้า) ในภาพ 26a นี้จะเห็นว่าเป็นการใช้ Role Name ที่ฟุ่มเฟือยและไม่จำเป็นต้องใส่เนื่องจาก แม้ว่าจะไม่ใส่ Role Name ลำพังแค่ Association Name ก็ทำให้ผู้อ่านไดอะแกรมเข้าใจได้อยู่แล้ว แต่อย่างไรก็ตาม จะมีบางครั้งที่เราจะต้องใส่ Role Name ด้วยจึงจะทำให้ผู้อ่านไดอะแกรมเข้าใจได้ดียิ่งขึ้น เช่น ในภาพ 26b ถ้าเราใส่ Role Name เข้าไป เราจะสามารถอ่านได้ว่าวัตถุ Person หนึ่งคนรับบทบาทเป็น สามี (husband) แต่งงานกับวัตถุ Person อีกหนึ่งคนที่รับบทบาทเป็นภรรยา (Wife)
ในการออกแบบคลาสที่ระดับ Detailed Design เราจะนำ Role Name มาใช้เป็นชื่อแอททริบิวท์ และชื่อเมธอดที่สื่อให้เห็นว่าเราสามารถเชื่อมต่อไปที่วัตถุอีกตัวหนึ่งที่สัมพันธ์กันอยู่ได้
รูปภาพ 27 ตัวอย่างการนำ Role Name ไปตั้งเป็นชื่อแอททริบิวท์และเมธอด
3.3.3 Multiplicity
เมื่อวัตถุมาทำความสัมพันธ์ เราสามารถนับจำนวนได้ว่าวัตถุทำความสัมพันธ์กันอยู่ด้วยจำนวนเท่าไรต่อเท่าไร เราเรียกจำนวนของวัตถุที่เกิดความสัมพันธ์กันขึ้นนี้ว่า Multiplicity
รูปภาพ 28 ความสัมพันธ์ระหว่างวัตถุในระบบสั่งจองตั๋วเครื่องบิน
ในภาพที่ 28 แสดงให้เห็นความสัมพันธ์ระหว่างวัตถุที่อยู่ในระบบสั่งจองตั๋วเครื่องบิน เราจะเห็นว่าวัตถุ Flight 1 ตัวสามารถเกี่ยวข้องกับวัตถุ Seat อีก 3 ตัว แต่เมื่อวิเคราะห์ให้ดีแล้วเราอาจจะได้ว่า วัตถุ Flight 1 ตัวสามารถเกี่ยวข้องวัตถุ Seat ได้หลายตัว
รูปภาพ 29 ตัวอย่างของ Multiplicity ที่เกิดจากการวิเคราะห์ภาพที่ 28
เวลาที่เราอ่าน Multiplicity เราสามารถอ่านได้ 2 ทิศทางคืออ่านจากซ้ายไปขวาหรืออ่านจากขวาไปซ้าย เช่นในภาพที่ 29 เราอ่านจากซ้ายไปขวาได้ว่า วัตถุ Flight หนึ่งตัวสัมพันธ์กับวัตถุ Seat อีกหลาย ๆ ตัว และเมื่ออ่านจากขวามาซ้ายจะได้ความหมายว่า วัตถุ Seat หนึ่งตัวสัมพันธ์กับวัตถุ Flight เพียงตัวเดียว ซึ่งเราจะได้หลักการอ่าน Multiplicity ก็คือถ้าเริ่มอ่านจากด้านไหนให้นับด้านนั้นเป็น 1 เสมอ (เพราะในความเป็นจริง เป็นความสัมพันธ์ระหว่างวัตถุ ไม่ใช้ความสัมพันธ์ระหว่างคลาส แต่นำมาเขียนอยู่ใน Class Diagram เท่านั้น)
จำนวนนับสามารถเขียนได้หลายแบบ เช่น
| 0..1 | เกิดความสัมพันธ์หรือไม่เกิดก็ได้ |
| 1 | ต้องเกิดความสัมพันธ์กับวัตถุหนึ่งตัวเท่านั้น |
| 0..* | เกิดความสัมพันธ์กับวัตถุหรือไม่เกิดก็ได้ และสามารถเกิดความสัมพันธ์กับวัตถุกี่ตัวก็ได้ |
| 1..* | เกิดความสัมพันธ์กับวัตถุตั้งแต่หนึ่งตัวขึ้นไป ถึงกี่ตัวก็ได้ |
| * | เหมือนกับ 0..* |
| 1, 2, 4 | ถ้าเกิดความสัมพันธ์ต้องเกิดกับวัตถุ 1 ตัว 2 ตัวหรือกับ 4 ตัวเท่านั้น |
3.3.4 Navigatability
ทิศทางของความสัมพันธ์มีอยู่ 2 แบบคือ แบบทิศทางเดียว (Uni-Direction) หรือแบบสองทิศทาง (Bi-Direction)
รูปภาพ 30 ตัวอย่างการใช้ Navigatability จาก Patient มาที่ Hospital
จากภาพที่ 30 เราจะเขียนเส้น Association ที่มีทิศทาง ให้มีหัวลูกศรชี้ไปทางใดสักทางหนึ่ง จากภาพหมายความว่าวัตถุ Patient สามารถเชื่อมโยงมาที่วัตถุ Hospital ได้ (สังเกตแอททริบิวท์ sender, receiver และเมธอด getSenderHospital, getReceiverHospital ที่เก็บอยู่ในวัตถุ Patient) แต่ในทางกลับกัน วัตถุ Hospital ไม่สามารถเชื่อมโยงไปที่วัตถุ Patient ได้
3.3.5 Aggregation
เป็นความสัมพันธ์แบบพิเศษ ใช้แทนความหมายว่า “ประกอบด้วย” หรือใช้แทนคำว่า “มี” เนื่องจากความสัมพันธ์แบบประกอบส่วนมักจะเกิดขึ้นอยู่เสมอ โดยวัตถุชิ้นหนึ่งประกอบด้วยวัตถุอีกชนิดหนึ่ง ตัวอย่างเช่นวัตถุ รถยนต์และล้อรถยนต์ วัตถุห้องเรียนและวัตถุนักเรียนที่อยู่ในห้อง วัตถุโรงพยาบาลและวัตถุผู้ป่วยที่อยู่ในโรงพยาบาล Aggregation จะแตกต่างจาก Association ธรรมดาก็คือ ในขณะที่ใช้งานวัตถุจะต้องมีการทำงานร่วมกันระหว่างวัตถุที่ประกอบกันอยู่
รูปภาพ 31 ตัวอย่างการใช้ Aggregation
เส้น Aggregation จะแสดงให้เห็นเป็นรูปสี่เหลี่ยมข้าวหลามตัด (Diamond) โดยชี้จากด้าน Diamond ไปที่อีกด้านหนึ่ง ด้านที่หัว Diamond ติดอยู่ก็คือด้านที่เป็นวัตถุรวม (Whole) ที่ประกอบด้วยวัตถุที่ด้าน Part of ที่เป็นวัตถุชิ้นส่วนย่อยที่ประกอบอยู่ในวัตถุรวม
เมื่อเราเขียนความสัมพันธ์แบบ Aggregation แล้วมักจะไม่จำเป็นต้องเขียน Association Name บอกไว้อีกแล้วเนื่องจากถือว่าผู้อ่านจะต้องแปลความหมายได้ทันทีว่าหมายถึงการ “ประกอบด้วย”
3.3.6 Composition
เป็นความสัมพันธ์แบบพิเศษที่มีลักษณะผูกติดกันมากกว่า Aggregation เนื่องจากวัตถุที่นำมาสัมพันธ์กันด้วย Aggregation เป็นวัตถุที่เกิดขึ้นคนละเวลาและถูกนำมาประกอบเข้าด้วยกันเวลาที่ต้องการใช้งานวัตถุรวม แต่สำหรับความสัมพันธ์แบบ Composition จะหมายถึงวัตถุที่ประกอบกันอยู่แล้วตั้งแต่ตอนสร้างวัตถุรวมขึ้นมาครั้งแรกเลย เช่น วัตถุรถยนต์และล้อรถ เป็นลักษณะ Composition ในมุมมองของผู้ใช้รถ เนื่องจากมีล้อรถประกอบมาให้ตั้งแต่ตอนที่ซื้อรถมาอยู่แล้ว วัตถุผู้ป่วยและการ์ดประจำตัวผู้ป่วย มีลักษณะ Composition เนื่องจากกำหนดไว้ว่าผู้ป่วยทุกคนจะต้องมีการ์ดประจำตัวด้วยเสมอ เป็นต้น
รูปภาพ 32 ตัวอย่างการใช้งาน Composition
วิธีการเขียน Composition จะแสดงเป็นรูป Diamond เหมือนกับใน Aggregation แต่จะใช้เป็นสีดำทึบ
3.3.7 Association Class
เป็นการแสดงให้เห็นว่ามีวัตถุเกิดขึ้น เมื่อวัตถุอีกสองตัวมาทำความสัมพันธ์กัน เราจะเขียนให้เห็น Association Class เชื่อมอยู่กับเส้น Assocation ด้วยเส้นประอย่างตัวอย่างในภาพที่ 33
รูปภาพ 33 แสดงการใช้ Association Class และ Association Object
จากภาพที่ 33 จะเห็นว่าทุกครั้งที่วัตถุ Student มาสัมพันธ์กับวัตถุ Course จะทำให้เกิดเป็นวัตถุ Transcript เช่นวัตถุ a เป็นนักเรียนชื่อสมชายขณะที่ ยังไม่ได้ไปสัมพันธ์กับวัตถุ Course ก็จะไม่มีวัตถุ Transcript เกิดขึ้น แต่เมื่อไปทำความสัมพันธ์กับวัตถุ Course ชื่อ Object-Oriented จะทำให้เกิดเป็นวัตถุ Transcript ซึ่งใช้สำหรับเก็บผลการสอบ
3.4 Inheritance
เราสามารถออกแบบให้คลาสหนึ่งสามารถสืบทอดต่อจากอีกคลาสหนึ่งได้ คลาสที่ใช้เป็นหลักให้อีกคลาสมาสืบทอดต่อไปเราเรียกว่าคลาสแม่ (Superclass) และคลาสที่มาสืบทอดต่อไปเราเรียกว่า คลาสลูก (Subclass) เมื่อเรานำคลาสลูกมาสืบทอดต่อจากคลาสแม่ คลาสลูกจะได้คุณสมบัติทุกอย่างที่กำหนดไว้ในคลาสแม่ คือได้ทั้งแอททริบิวท์และเมธอดที่คลาสแม่ออกแบบเอาไว้แล้ว
เหตุผลที่เรากำหนดให้คลาสลูกไปสืบทอดต่อจากคลาสแม่ มีทั้ง 2 มุมมองคือ
1. มุมมองโปรแกรมเมอร์ คลาสลูกจะได้ความสามารถของคลาสแม่ติดมาด้วยทำให้ไม่ต้องเขียนโปรแกรมซ้ำกับที่เคยเขียนไว้แล้วในคลาสแม่
2. มุมมองสถาปนิก คลาสลูกสมควรสืบทอดจากคลาสแม่เนื่องจากเป็นคลาสชนิดเดียวกัน (อยู่ในตระกูลเดียวกัน) วิธีการมองแบบนี้ เราสามารถอ่านได้คำว่า “is a” หรือภาษาไทยก็คือ “เป็น” เช่นถ้าบอกว่าคลาส Car สืบทอดต่อจาก Vehicle (ยานพาหนะ) เรากล่าวได้ว่า “Car is a Vehicle” (รถยนต์เป็นยานพาหนะ)
รูปภาพ 34 การใช้เส้น Generalization เพื่อแสดง Inheritance ระหว่างคลาสลูกและคลาสแม่
จากภาพที่ 24 จะเห็นว่าใน UML จะใช้เส้น Generalization ที่มีลักษณะหัวลูกศรสามเหลี่ยนโปร่งใส โดยใช้ลูกศรนี้ชี้ไปที่คลาสที่เป็นคลาสแม่ ซึ่งมีความเป็นลักษณะทั่วไปมากกว่าคลาสลูกที่พิเศษกว่า ตัวอย่างในภาพที่ 34 คลาสแม่คือยานพาหนะและคลาสลูกที่เป็นรถยนต์จะมีแอททริบิวท์ color และ weight และเมธอด move ที่ได้มาจากคลาสแม่ รวมกับแอททริบิวท์ wheels (ล้อรถ) และเมธอด fillFuel (เติมน้ำมัน) ที่เป็นของคลาส Car เอง สำหรับคลาสลูก Boat ก็จะสืบทอดจากคลาส Vehicle ดังนั้นจะมีคุณสมบัติของคลาส Vehicle รวมกับแอททริบิวท์ tail ที่เป็นของตัวเองด้วย
3.5 Abstract Class
เป็นคลาสที่ยังไม่สมบูรณ์และยังไม่ต้องการให้ไคลเอ็นต์นำคลาสนี้ไปสร้างเป็นวัตถุ แต่มีวัตถุประสงค์เพื่อให้โปรแกรมเมอร์นำคลาสนี้ไปสืบทอดต่อเป็นคลาสลูกแล้วเติมรายละเอียดในส่วนของ Abstract Method ให้สมบูรณ์ คลาสที่สมบูรณ์แล้วเราเรียกว่า Concrete Class ซึ่งก็คือคลาสที่เคยกล่าวมาแล้วในตัวอย่างที่ผ่านมา สถาปนิกซอฟแวร์จะใช้ Abstract Class ออกแบบในระดับที่เป็นการทำงานขั้นพื้นฐานและปล่อยการทำงานที่จำเพาะเจาะจงทิ้งไว้ให้กับโปรแกรมเมอร์ที่ต้องเป็นผู้เติมรายละเอียดใส่เข้าไปเอง
รูปภาพ 35 ตัวอย่างของ Abstract Class และ Abstract Method
จากภาพที่ 35 จะเห็นว่าเราออกแบบให้คลาส Vehicle เป็น Abstract Class เนื่องจากเราไม่ต้องการให้ไคลเอ็นโค้ดนำคลาส Vehicle ไปสร้างเป็นวัตถุ ถ้าไคลเอ็นต์โค้ดต้องการคลาสวัตถุจะต้องสร้างจากคลาส Car หรือคลาส Boat ที่เป็นคลาสลูก ให้สังเกตเมธอด move ที่อยู่ในคลาส Vehicle จะเขียนเป็นตัวเอน แสดงให้เห็นว่าเป็น Abstract Method พวกที่เป็น Abstract Method นี้จะเป็นเมธอดที่ไม่มีการทำงานอยู่ข้างใน แต่เป็นเมธอดเปล่า ๆ ที่มีเฉพาะโครงสร้างการประกาศเมธอดเท่านั้น คลาสลูกที่สืบทอดต่อไปจาก Abstract Class จะต้องเขียนการทำงานให้กับ Abstract Method ให้สมบูรณ์ ที่เมธอด move ในคลาส Vehicle เป็น Abstract Method ก็เนื่องจากเราไม่สามารถตัดสินใจได้ว่ากระบวนการเคลื่อนที่ในคลาส Vehicle จะเป็นอย่างไรเนื่องจากเราไม่รู้ว่าเป็นการเคลื่อนแบบรถหรือการเคลื่อนที่แบบเรือ จึงต้องทิ้งไว้เมธอด move นี้ไว้เป็น Abstract Method ก่อน
3.6 Interface
ใช้สำหรับเชื่อมต่อระหว่างคลาสที่เป็นผู้เรียกใช้ (Client Code) กับคลาสที่เป็นผู้ทำงานให้ (Implementation Code) ภายในอินเตอร์เฟสจะมีแต่โครงสร้างเมธอด โดยไม่มีการทำงานภายในเมธอด ดังนั้นเราจะคิดว่าอินเตอร์เฟสเป็น Abstract Class ที่ภายในมีแต่ Abstract Method ก็ได้
รูปภาพ 36 ตัวอย่างการใช้ interface
จากภาพที่ 36 เรากำหนดให้มีอินเตอร์เฟสชื่อว่า Service ซึ่งใช้ในความหมายว่าอะไรก็ตามที่เป็น Service แล้วจะต้องมีความสามารถ 3 อย่างคือ start (สามารถสั่งให้เริ่มทำงานได้) stop (สามารถสั่งให้หยุดทำงานได้) และ getStatus (สามารถสอบถามสถานะของงานที่กำลังทำอยู่ในปัจจุบันได้) ที่วัตถุ ServiceManager จะเป็นผู้ที่ควบคุมวัตถุ Service ทั้งหมดที่อยู่ในระบบ โดยเก็บรายการว่าในระบบมี Service อะไรอยู่บ้าง ดังนั้นใน ServiceManager จะสามารถรับ Service ไปเก็บไว้ในรายการได้โดยเรียกใช้เมธอด addService (ให้สังเกตว่าเมธอด addService รับอาร์กิวเมนต์มีชนิดข้อมูลเป็น Service) สมมุติว่าในระบบของเรามีบริการ 4 อย่างคือ Database, FileSystem, Telnet และ Web โดยทั้ง 4 คลาสนี้อิมพลีเมนต์มาจากอินเตอร์เฟส Service ทั้งสี่คลาสนี้จะต้องมีเมธอด start, stop และ getStatus พร้อมกับมีการทำงานอยู่ภายในเมธอดเหล่านี้ด้วย เมื่อทั้ง 4 คลาสนี้อิมพลีเมนต์มาจากอินเตอร์เฟส Service เราจะถือว่ามันเป็น Service ด้วยและวัตถุที่เกิดจากคลาสทั้ง 4 นี้จะสามารถใส่ให้กับเมธอด addService ในวัตถุ ServiceManager ได้ด้วย
3.7 Implementation
จากในภาพที่ 36 เราจะเห็นเส้น Implementation (ซึ่งบางครั้งเรียกว่า Realization หรือ Refinement) ชี้จากคลาสที่รับงานมาทำไปที่อินเตอร์เฟสที่เป็นผู้กำหนดงาน เส้น Implementation นี้จะชี้จากคลาสไปที่อินเตอร์เฟสเสมอ
รูปภาพ 37 ตัวอย่างการวาด Interface แบบย่อ
เราสามารถวาดอินเตอร์เฟสเป็นรูปวงกลมก็ได้ ซึ่งเป็นสัญลักษณ์ย่อของอินเตอร์เฟส เช่นปรากฏในภาพ 37
รูปภาพ 38 ตัวอย่างการสร้างคลาสอิมพลีเมนต์จากอินเตอร์เฟสมากกว่า 1 ตัว
ในภาพที่ 38 แสดงให้เห็นว่าคลาส Superman อิมพลีเมนต์จากอินเตอร์เฟส Runnable และ Flyable ดังนั้นคลาส Superman จะต้องมีการทำงานให้กับเมธอด run และ fly ครบทั้งคู่
3.8 Dependency
เป็นเส้นที่แสดงให้เห็นว่าวัตถุจำเป็นต้องอาศัยวัตถุอีกชิ้นหนึ่งในการทำงานร่วมด้วย
รูปภาพ 39 แสดงการใช้งาน Dependency
จากภาพที่ 39 จะเห็นเส้นประลากจาก PatientTransferManager ไปที่คลาส Patient ซึ่งบอกให้ทราบว่าคลาส PatientTransferManager มีการทำงานบางอย่างที่ต้องอาศัยคลาส Patient ร่วมด้วย ทำให้เวลาที่จะสร้างคลาส PatientTransferManager ให้เส็จสมบูรณ์จำเป็นต้องสร้างคลาส Patient มาก่อน
3.9 Package
เป็นการจัดกลุ่มคลาส ให้คลาสที่ทำงานในเรื่องเดียวกันอยู่ในแพคเกจเดียวกัน เนื่องจากในการพัฒนาระบบจะมีคลาสเกิดขึ้นเป็นจำนวนมาก และแบ่งคลาสออกเป็นกลุ่ม ๆ เป็นแนวคิดเดียวกันกับระบบไฟล์และไดเร็คทอรี เพื่อให้การค้นหาและแก้ไขคลาสทำได้ง่าย
รูปภาพ 40 ตัวอย่างการใช้งานแพคเกจ
ในภาพที่ 40 จะเห็นว่าเราแยกคลาสออกเป็น 3 แพคเกจคือ Domain, Presentation และ System และในแต่ละแพคเกจก็จะมีคลาสที่ทำงานในเรื่องนั้น ใน UML จะใช้สัญลักษณ์โฟลเดอร์ (Folder) แทนตัวแพคเกจ และแพคเกจสามารถมีแพคเกจซ้อนอยู่ข้างในลึกไปเรื่อย ๆ กี่ชั้นก็ได้
3.10 Component
เป็นชิ้นส่วนซอฟแวร์ที่พัฒนามาดีแล้ว และมีหน้าที่ชัดเจนให้ทำงานอย่างใดอย่างหนึ่ง ลักษณะเฉพาะที่ทำให้คอมโพเนนท์แตกต่างจากวัตถุธรรมดาก็คือจุดเชื่อมต่อ (Plug-in Point) ซึ่งคอมโพเนนท์จะต้องจัดเตรียมให้สามารถประกอบส่วนเข้ากับระบบงาน แล้วสามารถทำงานได้ทันที รวมทั้งสามารถถอดออกมาจากตัวระบบได้ด้วย นอกจากนี้คอมโพเนนท์จะต้องสามารถนำไปใช้งานกับแอพพลิเคชันอื่น ๆ ที่ทำงานในเรื่องเดียวกัน (อยู่ใน Business Domain เดียวกัน) ได้โดยอาจจะแก้ไขปรับเปลี่ยนเพียงเล็กน้อยเท่านั้น
ในคอมโพเนนท์หนึ่งชิ้นอาจจะประกอบด้วยวัตถุเพียงตัวเดียว หรือวัตถุหลาย ๆ ตัวมาทำงานร่วมกันก็ได้
รูปภาพ 41 ตัวอย่างการใช้สัญลักษณ์ Component และ Dependency
จากภาพที่ 41 เราจะเห็นว่ามีคอมโพเนนท์อยู่ 3 ตัวคือ Patient, Hospital และ TransferManager โดยคอมโพเนนท์ TransferManager จะต้องใช้คอมโพเนนท์ Patient และ Hospital ทำงานร่วมกันด้วย
3.11 Node
โหนดหมายถึงหน่วยประมวลผลที่สามารถใช้สำหรับรันคอมโพเนนท์ ซึ่งอาจจะหมายถึงเครื่องคอมพิวเตอร์ที่ใช้เป็นเครื่องเซิร์ฟเวอร์ หรือ เครื่องเทอร์มินอลต์อย่างเช่นเครื่องคอมพิวเตอร์ PC หรือโทรศัพท์มือถือในยุค 3G อย่างปัจจุบันก็ได้ เมื่อเราสร้างคอมโพเนนท์แล้วเราจะต้องนำคอมโพเนนท์ไปวางให้รันอยู่บนโหนดเราเรียกกระบวนการนำคอมโพเนนท์ไปใส่ไว้ในโหนดว่า Deployment
รูปภาพ 42 ตัวอย่างการใช้สัญลักษณ์ Node ใน Deployment Diagram
จากภาพที่ 42 จะเห็นว่าเราแบ่งเครื่องเซิร์ฟเวอร์ออกเป็นสองตัวคือเครื่อง Application Server ที่ใช้สำหรับรันคอมโพเนนท์ Patient, Hospital และ TransferManager แล้วจะมีเครื่องเซิร์ฟเวอร์อีกเครื่องทำหน้าที่เป็น Web Server สำหรับรันคอมโพเนนท์ PatientTransferForm
3.12 สรุปสัญลักษณ์ที่ใช้ใน Static Diagram
| ชื่อสัญลักษณ์ | รูปสัญลักษณ์ | ความหมายอย่างย่อ |
| Class |  | คลาสใช้สำหรับเป็นแม่แบบให้กับวัตถุ |
| Object |  | เป็นหน่วยรวมของข้อมูลและพฤติกรรม อาจจะหมายถึงวัตถุในโลกความจริง (Real-world) เช่น คน สิ่งของ หรือหมายถึงวัตถุในจินตนาการที่สมมุติให้ทำงานบางอย่างให้กับระบบ |
| Association |  | ความสัมพันธ์ระหว่างวัตถุ |
| Aggregation |  | ความสัมพันธ์แบบประกอบส่วน |
| Composition |  | ความสัมพันธ์แบบประกอบติด |
| Association with Navigatability |  | ความสัมพันธ์แบบทิศทางเดียว |
| Attribute | visibility name:type=default_value | รูปแบบของการเขียนแอททริบิวท์ |
| Method | visibility name(parameter:type, parameter:type, ….):return_type | รูปแบบของการเขียนเมธอด |
| Generalization |  | สร้างคลาสลูกสืบทอดจากคลาสแม่ |
| Implementation |  | สร้างคลาสอิมพลีเมนต์จากอินเตอร์เฟส |
| Interface |  | ข้อกำหนดระหว่างไคลเอ็นต์โค้ดและอิมพลีเมนต์โค้ด |
| Dependency |  | คลาสที่ขึ้นอยู่คลาสอีกคลาสหนึ่ง |
| Component |  | ชิ้นส่วนของซอฟแวร์ที่ออกแบบมาให้ทำหน้าที่อย่างใดอย่างหนึ่งและสามารถเชื่อมต่อเข้ากับระบบงานได้โดยใช้ข้อกำหนดที่ชัดเจน |
| Node |  | หน่วยประมวลผลที่ใช้สำหรับรันคอมโพเนนท์ |
สัญลักษณ์ที่สรุปรวมในตารางข้างบนนี้อาจจะยังไม่ครบถ้วน เนื่องจากใน UML จะมีสัญลักษณ์เพิ่มเติมอื่นอีก เช่น Parameterized Class, Pattern, Constraint, Qualifier และอื่น ๆ เนื่องจากสัญลักษณ์เหล่านี้มีการใช้งานเพียงเล็กน้อยและบางอย่างเป็นคุณลักษณะเฉพาะที่ภาษาโปรแกรมบางภาษาเท่านั้นสามารถทำได้ ในเอกสารฉบับนี้จึงไม่ได้กล่าวถึง อย่างไรก็ตามถ้าผู้อ่านสนใจในสัญลักษณ์ที่เหลือ ผู้อ่านสามารถค้นคว้าเพิ่มเติมได้จากรายการหนังสืออ้างอิงที่ปรากฏอยู่ท้ายเอกสารฉบับนี้