โดย สรพงษ์ เรือนมณี เขียนเมื่อ 2543 เผยแพร่ 2566
เพื่อให้ซอฟแวร์ที่พัฒนาขึ้นมีลักษณะเป็นส่วนประกอบที่ชัดเจน และมีโครงสร้างที่ยืดหยุ่นเพียงพอสำหรับการเปลี่ยนแปลง แก้ไขที่จะเกิดขึ้นในอนาคต เราจำเป็นต้องใช้วิธีการเชิงวัตถุในการออกแบบ และพัฒนาซอฟแวร์ร่วมด้วย ลักษณะของวัตถุที่ประกอบอยู่ในระบบงานจะมีวัตถุหลายชนิดขึ้นอยู่กับการวิเคราะห์ระบบ ซึ่งอาจจะมีทั้งวัตถุที่เป็นตัวแทนของวัตถุจริงในโลกที่เราอาศัยอยู่ (Real-World Object) หรือวัตถุที่สมมุติขึ้นมาเพื่อให้ทำหน้าที่บางอย่างในระบบงาน (Imaginary Object) วัตถุจะมีองค์ประกอบสองอย่างคือ ส่วนข้อมูล เรียกว่าแอททริบิวท์ และส่วนการกระทำ เรียกว่าเมธอด ส่วนข้อมูลใช้สำหรับเก็บข้อมูลที่เป็นคุณสมบัติเฉพาะของวัตถุชนิดนั้น เช่น ถ้าเป็นวัตถุรถยนต์ส่วนข้อมูลจะได้แก่ สี ขนาด น้ำหนัก ราคา หรือ ยี่ห้อ เป็นต้น สำหรับส่วนการกระทำ ใช้สำหรับบอกให้รู้ว่าวัตถุสามารถทำอะไรหรือถูกกระทำอะไรได้บ้าง ตัวอย่างเช่น วัตถุรถยนต์ อาจจะมีส่วนการกระทำคือ รถยนต์วิ่ง รถยนต์กำลังเร่งเครื่อง รถยนต์กำลังหยุดเครื่อง รถยนต์ถูกซื้อมาและขายไป เป็นต้น
คลาส
ชนิดของวัตถุเราเรียกว่า คลาส คลาสเป็นเหมือนแม่พิมพ์ของวัตถุ ซึ่งภายในคลาสจะใช้กำหนดว่าวัตถุที่ถูกสร้างขึ้นจากคลาสนี้จะมีส่วนข้อมูลและส่วนการกระทำเป็นอย่างไร ดังนั้น วัตถุที่เกิดขึ้นมาจากคลาสเดียวกันจะมีส่วนข้อมูลและส่วนการกระทำเป็นรูปแบบเดียวกัน แต่หลังจากที่วัตถุทำงานไปได้ระยะเวลาหนึ่งแล้ว วัตถุชนิดเดียวกันอาจจะมีข้อมูลบางอย่างที่แตกต่างกันไปแล้วแต่สถานะที่กำลังเป็นอยู่ในขณะนั้นก็ได้
ถ้าจะเปรียบเทียบกับวัตถุในโลกความจริงเราอาจจะเปรียบเทียบคลาสได้เหมือนกับเป็นพิมพ์เขียวหรือแบบที่ใช้สำหรับก่อสร้างสิ่งต่าง ๆ เช่น แบบบ้าน แบบรถยนต์ และวัตถุที่สร้างขึ้นตามพิมพ์เขียวเดียวกันจะปรากฏออกมารูปร่างหน้าตาเหมือน ๆ กัน ตัวอย่างเช่น รถยนต์ที่ผลิตขึ้นมาในรุ่นเดียวกันจะมีคุณลักษณะเหมือนกันเนื่องจากใช้แม่แบบเดียวกันในการผลิต ในการใช้งานจริงเราไม่สามารถนำคลาสไปใช้งานได้โดยตรงแต่เราจะต้องนำคลาสมาสร้างเป็นวัตถุก่อน แล้วจึงสั่งให้วัตถุทำงานตามที่เราต้องการ เช่นเดียวกับที่เราไม่สามารถขับขี่แม่แบบของรถยนต์ (ซึ่งเป็นกระดาษพิมพ์เขียว เปรียบเหมือนกับคลาส) แต่เราจะต้องนำแม่แบบไปสร้างเป็นตัวรถยนต์ออกมาก่อนเราจึงจะสามารถขับขี่รถยนต์ (ซึ่งเป็นวัตถุ) ได้
รูปภาพ 1 ตัวอย่างคลาส Patient
จากภาพที่ 1 เราจะเห็นตัวอย่างการออกแบบคลาส Patient (ผู้ป่วย) ซึ่งประกอบด้วยแอททริบิวท์[1]คือ id หมายถึงรหัสของผู้ป่วย firstName คือชื่อผู้ป่วย dateOfBirth คือวันเดือนปีเกิดของผู้ป่วย สำหรับเมธอดที่ผู้ป่วยสามารถกระทำ (หรือถูกกระทำ) ได้แก่ register คือลงทะเบียนผู้ป่วย และ transferTo คือย้ายสถานพยาบาล ในตัวอย่างนี้เป็นเพียงตัวอย่างเล็ก ๆ เพื่อแสดงให้เห็นถึงการออกแบบคลาสที่แทนที่วัตถุที่อยู่ในระบบงานจริง
แม้ว่าเราจะมีคลาสแล้วก็ตาม แต่ในความเป็นจริงเราจะไม่ได้ใช้คลาส เนื่องจากเราจะต้องนำคลาสไปสร้างเป็นวัตถุก่อน แล้วจึงสามารถสั่งงานวัตถุให้ทำตามที่โปรแกรมต้องการ จากภาพที่ 1 นี้ แม้ว่าเราจะมีคลาส Patient ตามเรายังไม่มีวัตถุผู้ป่วย แม้แต่สักคนเดียว เราจะต้องนำคลาส Patient นี้ไปสร้างเป็นวัตถุ Patient โดยใช้กระบวนการที่เรียกว่า อินสแตนทิเอชัน (Instantiation)
[1] แอททริบิวท์ หมายถึงส่วนข้อมูล เนื่องจากหนังสือบางเล่มใช้คำศัพท์ต่างกัน คำว่าแอททริบิวท์ใช้ในเชิงของทฤษฏี Object-Oriented สำหรับคำว่า ส่วนข้อมูล (Member Data) หรือ ตัวแปรอินสแตนซ์ (Instance Variable) เป็นคำศัพท์ที่เกิดขึ้นเนื่องจากการนำทฤษฏีไปประยุกต์ใช้ในภาษา C++ และภาษา Java ตามลำดับ
วัตถุ (อินสแตนซ์)
เป็นสิ่งที่ถูกสร้างขึ้นจากคลาส โดยวัตถุที่สร้างขึ้นจะมีแอททริบิวท์และเมธอดเหมือนกับที่ได้บรรยายไว้ในคลาส ในทางโปรแกรมเรียกวัตถุว่าอินสแตนซ์เนื่องจากการเก็บวัตถุจะต้องใช้หน่วยความจำของเครื่องคอมพิวเตอร์และการสั่งงานให้วัตถุกระทำตามเมธอดจะต้องใช้หน่วยประมวลผล (CPU) รันตามคำสั่งที่อยู่ภายในเมธอดนั้น ๆ
รูปภาพ 2 วัตถุที่ถูกสร้างขึ้นจากคลาส Patient
จากภาพที่ 2 เราจะเห็นว่าเราสามารถนำคลาส Patient มาสร้างขึ้นเป็นวัตถุกี่ตัวก็ได้[1] วัตถุแต่ละตัวจะมีค่าแอททริบิวท์เป็นของตัวเองไม่ขึ้นต่อกัน เช่นในภาพจะเห็นว่าวัตถุ a มี id เป็น P123 ส่วนวัตถุ b จะมี id เป็น P201 ค่าของแอททริบิวท์อาจจะเปลี่ยนไปได้ตามการใช้งาน
จากภาพที่ 2 เราจะเห็นว่า a และ b เป็น Reference Variable ซึ่ง Reference Variable ก็คือตัวแปรอ้างอิงที่ใช้สำหรับอ้างอิงวัตถุ เราจำเป็นต้องมีตัวแปรอ้างอิงวัตถุถึงจะสามารถใช้งานวัตถุได้ เนื่องจากการเข้าถึงแอททริบิวท์หรือเมธอดของวัตถุใด ๆ ก็ตามจะต้องขึ้นต้นด้วยชื่อตัวแปรอ้างอิงแล้วตามด้วยชื่อแอททริบิวท์หรือเมธอดที่มีอยู่ในวัตถุตัวนั้นเสมอ ดังนั้นถ้าเราไม่มีตัวแปรอ้างอิงเราจะไม่สามารถเข้าถึงวัตถุได้เลย และวัตถุที่ปราศจากตัวแปรอ้างอิง เราจะถือว่าเป็นขยะ (Gabage) เนื่องจากเป็นวัตถุที่ไม่สามารถเข้าถึงเพื่อใช้งานใด ๆ ได้[2]
โปรแกรม OC-1 ตัวอย่างการนำคลาส Patient ไปโปรแกรมเพื่อสร้างวัตถุ a ตามภาพที่ 2 (ภาษา Java)
[1] จำนวนของวัตถุขึ้นอยู่กับความต้องการของระบบ และประสิทธิภาพของเครื่องเซิร์ฟเวอร์ที่สามารถรองรับได้
[2] ในภาษาโปรแกรมปัจจุบันอย่างเช่น ภาษา Java, JavaScript, C#, VB.NET จะมีคุณลักษณะที่เรียกว่า Gabage Collection ไว้สำหรับเก็บวัตถุที่เป็นขยะให้ออกไปจากหน่วยความจำ (Heap Memory) เพื่อให้มีพื้นที่หน่วยความจำใช้สอยมากขึ้น
ความสัมพันธ์กันระหว่างวัตถุ (Association)
วัตถุแต่ละตัวในระบบสามารถสร้างความสัมพันธ์กับวัตถุอีกตัวหนึ่งได้ (แม้ว่าจะเป็นความสัมพันธ์กับตัวมันเองก็ได้ด้วย[1]) ความสัมพันธ์ที่เกิดขึ้นจะเป็นมีคุณลักษณะที่เกี่ยวข้องดังต่อไปนี้
1. เหตุผลที่นำมาสัมพันธ์กันและบทบาทที่รับผิดชอบ
2. ทิศทางของความสัมพันธ์ (Navigability)
3. จำนวนนับของวัตถุที่มาสัมพันธ์กัน (Multiplicity)
[1] ความสัมพันธ์กับวัตถุตัวเองเราเรียกว่า Self Reference ใช้ในกรณีพิเศษบางอย่าง ตัวอย่างเช่น เป็นวัตถุรูทของโครงข่าย
1. เหตุผลที่นำมาสัมพันธ์กันและบทบาทที่รับผิดชอบ
เมื่อวัตถุสองตัวมาสัมพันธ์กัน เนื่องมาจากการวิเคราะห์ความต้องการของระบบแล้วพบว่าวัตถุสองตัวนี้จะต้องเกี่ยวข้องกัน เช่น วัตถุผู้ป่วย และวัตถุสถานพยาบาล มาเกี่ยวข้องกันเนื่องจากผู้ป่วยไปรักษาไข้อยู่ที่สถานพยาบาล หรือวัตถุผู้ป่วยกับวัตถุแพทย์ มาเกี่ยวข้องกันเนื่องจากผู้ป่วยมาให้แพทย์รักษา ดังนี้เราจะพบว่าในระบบงานหนึ่งจะเกิดขึ้นจากการทำงานร่วมกัน ระหว่างวัตถุหลาย ๆ ตัวและวัตถุแต่ละตัวก็จะมีหน้าที่ที่ต้องรับผิดชอบแตกต่างกันไป เมื่อเราสามารถจัดวางวัตถุและความสัมพันธ์ให้สอดคล้องกันได้อย่างลงตัวแล้วเราจะได้โครงสร้างของระบบงานที่ชัดเจนและพร้อมสำหรับการนำไปพัฒนาเป็นแอพพลิเคชันในขั้นต่อไป
รูปภาพ 3 ความสัมพันธ์ที่เกิดขึ้นระหว่างวัตถุ Patient และวัตถุ Hospital
จากภาพที่ 3 เราจะเห็นว่าวัตถุ a คือผู้ป่วยที่ชื่อสมชาย ไปรักษาที่โรงพยาบาลวิภาวดี 1 คือวัตถุ h เราสามารถเขียนเส้นลากเชื่อมโยงระหว่างวัตถุ a และวัตถุ h และเรียกเส้นนี้ว่า assication ที่เหนือเส้นหรือใต้เส้นจะมีข้อความกำกับไว้ (Association Verb) เพื่อบอกให้ทราบว่าเกี่ยวข้องกันอย่างไร ซึ่งบางครั้งอาจจะมีไม่จำเป็นต้องเขียนบอกไว้ก็ได้ถ้าความหมายของภาพชัดเจนและเป็นที่รู้กันอยู่แล้ว
เมื่อวัตถุมาเกี่ยวข้องสัมพันธ์กันเราจะสามารถเขียนบรรยายเป็นลักษณะของคลาสได้ ดังภาพที่ 4 ต่อไปนี้
รูปภาพ 4 แสดงบทบาทของวัตถุแต่ละด้านที่เกี่ยวข้องกัน
ในภาพที่ 4 เราจะเห็นว่าเมื่อวัตถุมาเกี่ยวข้องสัมพันธ์กัน เราจะเขียนเส้นเชื่อมโยงระหว่างคลาสของวัตถุทั้งสองชนิดที่เกี่ยวข้องกันไว้[1] เมื่อลากเส้นเชื่อมโยงแล้ว ทางปลายเส้นแต่ละด้านเราอาจจะใส่ข้อความกำกับบทบาท (Role Name) ไว้ด้วยก็ได้
[1] แม้ว่าเส้นจะเชื่อมโยงระหว่างคลาสแต่แท้ที่จริงคือความสัมพันธ์ระหว่างตัววัตถุแต่ละตัว ดังนั้นเมื่อผู้อ่านไดอะแกรมเห็นเส้นเชื่อมโยงความสัมพันธ์ขอให้ระลึกไว้เสมอว่าไม่ใช่ความสัมพันธ์ของคลาสกับคลาสแต่เป็นความสัมพันธ์ของวัตถุที่เกิดขึ้นจากคลาสนั้น
Role Name ใช้สำหรับบอกให้ผู้อ่านไดอะแกรมทราบว่าวัตถุที่เกี่ยวข้องกันนั้นทำหน้าที่อะไร เช่นในภาพที่ 4 เราจะเห็นว่าวัตถุ a ทำหน้าที่เป็น patient (ผู้ป่วย) และวัตถุ b ทำหน้าที่เป็น nursing home (สถานพยาบาล) การใส่ Role Name เข้าไปในไดอะแกรมจะช่วยให้เราเห็นบทบาทหน้าที่ของวัตถุได้ชัดเจนยิ่งขึ้น ซึ่งในภาพที่ 4 อาจจะไม่แสดงความสำคัญของ Role Name เท่าใดนักเนื่องจากชื่อคลาสเองก็สื่อความหมายที่ชัดเจนอยู่แล้วว่าเป็นผู้ป่วย และเป็นโรงพยาบาล แต่ในกรณีที่ชื่อคลาสไม่บ่งบอกหน้าที่ที่ชัดเจนลงไปเราอาจจะต้องใช้ Role Name กำกับไว้ด้วย
รูปภาพ 5 แสดงการใช้ Role Name เพื่อแสดงบทบาทที่ชัดเจนของวัตถุ
จากภาพที่ 5 เราจะเห็นว่าคลาส Person ไม่บ่งบอกความหมายที่ชัดเจนเพียงพอ ในกรณีที่เป็นโรงพยาบาลว่าจ้างพยาบาล เราจะเห็นว่าโรงพยาบาลมีบทบาทเป็นผู้ว่าจ้าง (employer) และบุคคลรับบทบาทเป็นพยาบาล (nurse) แต่ในขณะเดียวกันถ้าเป็นความสัมพันธ์ระหว่างบุคคลที่เป็นผู้ป่วยกับโรงพยาบาล โรงพยาบาลจะรับบทบาทเป็น สถานพยาบาล (nursing home) และบุคคลรับบทบาทเป็นผู้ป่วย (patient)
2. ทิศทางของความสัมพันธ์ (Navigatability)
ความสัมพันธ์ที่เกิดขึ้นระหว่างวัตถุสามารถเกิดได้สองแบบคือ ทิศทางเดียว (Uni-direction) หรือ สองทิศทาง (Bi-direction) ทั้งสองแบบนี้บ่งบอกให้เห็นว่าเราสามารถดึงค่าของวัตถุตัวหนึ่งออกมาจากวัตถุอีกตัวหนึ่งที่กำลังทำความสัมพันธ์กันอยู่ได้หรือไม่
ตัวอย่างของทิศทางเช่น ถ้าเรามีวัตถุผู้ป่วยอยู่หนึ่งคน หรือผู้ป่วย a เราต้องรู้ว่าปัจจุบันผู้ป่วย a เค้ารักษาตัวอยู่ที่สถานพยาบาลแห่งไหน เราสามารถสอบถามได้จากผู้ป่วย a โดยตรงเมื่อถามวัตถุผู้ป่วย a แล้วเค้าจะตอบกลับมาว่าเค้ารักษาตัวอยู่ที่สถานพยาบาล h ในกรณีอย่างนี้เราบอกได้ว่า วัตถุผู้ป่วยสามารถเชื่อมโยงไปที่วัตถุสถานพยาบาลที่เกี่ยวข้องกันอยู่ได้ และทิศทางของความสัมพันธ์จะชี้จากวัตถุผู้ป่วยไปที่วัตถุสถานพยาบาล ดังรูปภาพที่ 6
รูปภาพ 6 ทิศทางของความสัมพันธ์จากวัตถุผู้ป่วยมาที่วัตถุสถานพยาบาล
จากภาพที่ 6 แสดงให้เห็นในกรณีของวัตถุที่สัมพันธ์กันอยู่ แต่เมื่อเรานำมาเขียนเป็นคลาสไดอะแกรมแล้วเราจะสามารถเขียนได้ดังภาพที่ 7
รูปภาพ 7 แสดงทิศทางของความสัมพันธ์ในคลาสไดอะแกรม
การออกแบบโปรแกรมเพื่อให้เกิดความสัมพันธ์แบบทิศทางเดียวก็คือความสามารถในการดึงวัตถุอีกตัวหนึ่งออกมาจากวัตถุที่กำลังใช้งานอยู่ ดังนั้นวัตถุที่จะสัมพันธ์กับวัตถุอื่นและสามารถเชื่อมโยงไปถึงวัตถุนั้นได้จะต้องจัดให้มีแอททริบิวท์หรือเมธอดที่สามารถดึงวัตถุที่เชื่อมโยงกันอยู่ออกมาใช้งานได้
รูปภาพ 8 แสดง Detail Design ที่ทำให้ Patient เชื่อมโยงกับ Hospital
จากภาพที่ 8 เราให้วัตถุ Patient ทุกตัวมีตัวแปรอ้างอิงไปที่วัตถุ Hospital ชื่อตัวแปรว่า hospital เพื่อเก็บไว้ว่าสถานพยาบาลไหนที่เป็นสถานพยาบาลปัจจุบันที่ผู้ป่วยคนนี้กำลังใช้บริการอยู่ สำหรับเมธอด getCurrentHospital เราจัดเตรียมไว้ให้ Client Code[1] เรียกใช้ในกรณีที่ไม่ต้องการให้เข้าถึงแอททริบิวท์ได้โดยตรง[2]
การเชื่อมโยงแบบสองทิศทาง จะเกิดขึ้นเนื่องจากเราสามารถดึงวัตถุที่เชื่อมโยงกันอยู่ออกมาจากวัตถุใดวัตถุหนึ่งก็ได้ เช่นในกรณีของผู้ป่วยกับสถานพยาบาล ถ้าเรามีวัตถุสถานพยาบาล h อยู่เราต้องการรู้ว่าปัจจุบันสถานพยาบาล h มีผู้ป่วยมารักษาอยู่ทั้งหมดกี่คน แล้วเราสามารถเรียกใช้เมธอด getAllPatients เพื่อให้ได้วัตถุผู้ป่วยทั้งหมดที่กำลังรักษาตัวอยู่ที่สถานพยาบาล h ได้ เราสามารถบอกได้ว่า วัตถุสถานพยาบาลเชื่อมโยงอยู่กับวัตถุผู้ป่วย
รูปภาพ 9 แสดงการเชื่อมโยงทิศทางเดียวจากวัตถุ Hospital มาที่วัตถุ Patient
จากภาพที่ 9 แสดงให้เห็นว่าเราสามารถดึงวัตถุ Patient ทุกคนที่กำลังรักษาตัวอยู่ที่สถานพยาบาลออกมาได้โดยเรียกใช้เมธอด getAllPatients[1] จากภาพที่ 9 ถ้าเรานำไปรวมเข้าด้วยกันภาพที่ 8 ก็จะได้ความสัมพันธ์แบบสองทิศทางที่วัตถุ Patient สามารถเชื่อมโยงไปถึงวัตถุ Hospital และในขณะเดียวกันวัตถุ Hospital ก็สามารถเชื่อมโยงมาที่วัตถุ Patient ได้เช่นเดียวกัน
[1] เครื่องหมาย [*] ในไดอะแกรมหมายถึงการส่งคืนค่ากลับมาเป็นกลุ่มของวัตถุ ซึ่งอาจจะไม่ใช่วัตถุเพียงตัวเดียว
[1] โปรแกรมที่มาเรียกใช้วัตถุ โดยนำคลาสไปสร้างเป็นวัตถุแล้วสั่งงานตามเมธอดต่างๆที่วัตถุได้จัดเตรียมไว้ให้
[2] ตามแนวคิดแบบ Encapsulation เพื่อป้องกันสถานะของวัตถุให้อยู่ในสถานะที่ถูกต้องตามที่ระบบงานต้องการเสมอ
รูปภาพ 10 แสดงความสัมพันธ์แบบสองทิศทางระหว่าง Patient และ Hospital
จากภาพที่ 10 เราจะสังเกตเห็นว่าถ้าเป็นความสัมพันธ์แบบสองทิศทางเราไม่จำเป็นต้องใส่หัวลูกศรเข้าไปที่ปลายเส้นด้านใดด้านหนึ่ง
ในการออกแบบระบบจริง เราอาจจะยังไม่ระบุทิศทางของความสัมพันธ์ที่ชัดเจนในระดับของการออกแบบขั้นคอนเซ็ปต์ (Conceptual Design) เนื่องจากความต้องการของระบบยังไม่ชัดเจน เราอาจจะทิศไว้เป็นเส้นเชื่อมโยงธรรมดาที่ไม่แสดงหัวลูกศร แต่เมื่อผ่านการออกแบบมาถึงขั้นออกแบบรายละเอียด (Detailed Design) สถาปนิกซอฟแวร์อาจจะวิเคราะห์และออกแบบให้เหลือเป็นความสัมพันธ์แบบทิศทางเดียวก็ได้ เนื่องจากความสัมพันธ์แบบทิศทางเดียวจะง่ายสำหรับการนำไปสร้างเป็นโปรแกรมมากกว่าความสัมพันธ์แบบสองทิศทาง
3. จำนวนนับของวัตถุที่มาสัมพันธ์กัน (Multiplicity)
เมื่อวัตถุมาเกี่ยวข้องสัมพันธ์กัน เราจะวิเคราะห์ว่าวัตถุเหล่านั้นสามารถเกิดความสัมพันธ์กันได้ด้วยจำนวนเท่าใด ตัวอย่างเช่น รถยนต์นั่งธรรมดาจะสัมพันธ์กับล้อรถด้วยจำนวนเป็น 4 หรือ โรงพยาบาลแห่งหนึ่งสามารถรักษาผู้ป่วยได้หลายคน เป็นต้น
รูปภาพ 11 แสดงจำนวนนับระหว่างวัตถุ Patient และวัตถุ Hospital
จากภาพที่ 11 จำนวนนับระหว่างวัตถุ[1]สองชนิดคือ Patient และ Hospital เราสามารถแปลความหมายได้จากการอ่านทั้งสองทิศทางคือ อ่านจากทางซ้ายไปทางขวา หรืออ่านจากทางขวามาทางซ้าย
รูปภาพ 12 อ่าน Multiplicity จากทางซ้ายไปทางขวา
จากภาพที่ 12 ถ้าเราพิจารณาภาพที่ 11 จากซ้ายมาขวา จะได้ว่าวัตถุ Patient หนึ่งตัวจะเชื่อมโยงไปที่วัตถุ Hospital หนึ่งตัวที่ทำหน้าที่เป็นสถานพยาบาลปัจจุบันที่ผู้ป่วยคนนี้กำลังใช้รักษาตัวอยู่
รูปภาพ 13 อ่าน Multiplicity จากขวามาซ้าย
จากภาพที่ 13 เป็นการอ่านจากภาพที่ 11 แต่อ่านจากทางขวามาทางซ้ายเราจะได้ความหมายว่าวัตถุ Hospital หนึ่งตัวสามารถเชื่อมโยงกับวัตถุ Patient ได้หลายคน ซึ่งภาพที่ 12 และภาพที่ 13 เป็นเพียงแนวคิดในการอ่านคลาสไดอะแกรมที่มี Multiplicity อยู่ให้สามารถเข้าใจเรื่อง Multiplicity ได้ง่ายขึ้น แต่เวลาที่เขียนในคลาสไดอะแกรมจริง ๆ จะเขียนเหมือนกับที่แสดงในภาพที่ 11
[1] แม้ว่าในไดอะแกรมจะแสดงภาพของคลาส แต่แท้ที่จริงเป็นการนับจำนวนวัตถุที่สัมพันธ์กัน
จากภาพที่ 13 เป็นการอ่านจากภาพที่ 11 แต่อ่านจากทางขวามาทางซ้ายเราจะได้ความหมายว่าวัตถุ Hospital หนึ่งตัวสามารถเชื่อมโยงกับวัตถุ Patient ได้หลายคน ซึ่งภาพที่ 12 และภาพที่ 13 เป็นเพียงแนวคิดในการอ่านคลาสไดอะแกรมที่มี Multiplicity อยู่ให้สามารถเข้าใจเรื่อง Multiplicity ได้ง่ายขึ้น แต่เวลาที่เขียนในคลาสไดอะแกรมจริง ๆ จะเขียนเหมือนกับที่แสดงในภาพที่ 11
ตัวเลขที่บอกจำนวนนับของวัตถุที่ปลายเส้น Association อาจจะมีจำนวนตั้งแต่เท่าไรถึงเท่าไรก็ได้ เช่น 0..* หมายถึงมีจำนวนวัตถุตั้งแต่ 0 ถึงเท่าไรก็ได้ หรือถ้ามีเลขจำนวนเป็น 4..8 หมายถึงจะต้องสร้างความสัมพันธ์ที่จำนวนวัตถุตั้งแต่ 4 ถึง 8 ตัวเท่านั้น
จากเรื่องของวัตถุ คลาส และความสัมพันธ์ เราจะสามารถนำมาใช้ในการออกแบบออบเจกต์โมเดล (Object Model) ได้ ต่อไปนี้เป็นตัวอย่างของการวิเคราะห์ Problem Statement[1] บางส่วนของระบบงานที่ยกมาเป็นกรณีศึกษา เพื่อให้เข้าใจวิธีการของ Object-Oriented มากขึ้น
[1] เป็นคำบรรยายถึงคุณลักษณะบางอย่างของระบบงานที่เรากำลังวิเคราะห์และออกแบบโดยตัดเอามาเฉพาะบางส่วนของระบบทั้งหมด
ตัวอย่าง – 1 การวิเคราะห์ File และ Folder
Problem Statement ไฟล์จะเก็บอยู่ในโฟลเดอร์ โฟลเดอร์หนึ่งสามารถเก็บไฟล์ได้หลาย ๆ ไฟล์ ในโฟลเดอร์สามารถเก็บโฟลเดอร์ได้หลาย ๆ โฟลเดอร์ ไฟล์สามารถมีแอททริบิวส์ได้หลาย ๆ แอททริบิวส์ เช่น อ่านอย่างเดียว เขียนอย่างเดียว อ่านและเขียน และอื่น ๆ
ตัวอย่าง – 2 การวิเคราะห์ Song Album
Problem Statement อัลบัมหนึ่งสามารถมีเพลงได้มากกว่าหนึ่งเพลง เพลงหนึ่งสามารถไปอยู่ในอัลบัมไหนก็ได้ เพลงหนึ่งสามารถมีศิลปินผู้ร้องเพลงได้เพียงคนเดียว เพลงหนึ่งสามารถมีได้หลายเวอร์ชัน และแต่ละเวอร์ชันสามารถมีผู้ร้องเพลงได้ต่างจากเวอร์ชันที่แล้ว
ตัวอย่าง – 3 การวิเคราะห์ Task Assignment
Problem Statement พนักงานหนึ่งคนจะมีงานที่ต้องรับผิดชอบมากกว่าหนึ่งในเวลาเดียวกัน พนักงานสามารถอยู่ในทีมงานไหนก็ได้ ขึ้นอยู่กับงานที่รับผิดชอบ ทีมงานแต่ละทีมจะประกอบด้วยพนักงานหลาย ๆคน และมีคนหนึ่งคนที่เป็นหัวหน้าทีม
ตัวอย่าง – 4 การวิเคราะห์ Hotel Room Reservation
Problem Statement โรงแรมแห่งหนึ่งมีห้องพักแบ่งให้ลูกค้าสั่งจองเข้าพักได้ โดยห้องนึงสามารถพักได้มากกว่าหนึ่งคน และลูกค้าสามารถสั่งจองได้มากกว่าหนึ่งห้อง ห้องพักห้องนึงสามารถถูกสั่งจองโดยลูกค้ามากกว่าหนึ่งรายในช่วงเวลาที่ต่างกัน
