Transcript การค้นหา Class - มหาวิทยาลัยบูรพา วิทยาเขตจันทบุรี

291474
Selected Topics in Information System I
บทที่ 5
การกาหนดพืน้ ฐานของระบบงาน
โดยใช้ Class Diagram
อ.ธารารัตน์ พวงสุ วรรณ
คณะวิทยาศาสตร์ และศิลปศาสตร์
มหาวิทยาลัยบูรพา วิทยาเขตสารสนเทศจันทบุรี
เนือ้ หา
การค้นหา Class
องค์ประกอบของ Class
ความสัมพันธ์ระหว่าง Class
หลักการสร้าง Class Diagram
การค้ นหา Class
มีหลายวิธีดว้ ยกัน เช่น
วิธีคน้ หาคานาม
วิธีคน้ หาคลาสโดยใช้กลุ่มลักษณะ
การใช้ CRC (Class, Responsibilities, and Collaborators)
Reuse
อื่น ๆ
การค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
เป็ นการค้นหาคานามจากคาอธิบายการทางานระบบที่รวมรวมได้
เป็ นวิธีที่หลายคนเสนอให้ใช้เป็ นวิธีคน้ หาคลาส
ผลที่ได้จะแตกต่างกันตามคาอธิบายการทางานของระบบที่รวบรวมได้
คาอธิบายระบบที่สามารถใช้ได้คือ คาอธิบาย Use case (Larman 2005)
เนื่องจาก คาอธิบาย Use case มีการอ้างอิงถึง Object ที่สาคัญที่ควรเป็ น
คลาสของระบบ
เริ่ มต้นจากส่ วนที่เป็ นการทางานหลักที่สาเร็ จ ( Main Success Scenario)
และส่ วนการทางานอื่นที่รองรับได้ (Extension)
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
 Use Case การขายสิ นค้า
 Main Success Scenario :
 ลูกค้านาสิ นค้ามาส่ งให้แคชเชียร์
แคชเชียร์เปิ ดรายการขายใหม่ในระบบ
แคชเชียร์ป้อนรหัสสิ นค้าทีละชิ้นในเครื่ องรับชาระเงิน
ระบบรับรหัสสิ นค้าและค้นหารายการสิ นค้านั้นเพื่อแสดงชื่อสิ นค้าและราคาและบันทึกเป็ น
รายการย่อย พร้อมกับแสดงยอดรวมค่าสิ นค้าที่รวมถึงรายการนี้ แคชเชียร์ทาซ้ าตามขั้นตอน 3-4
จนกว่าสิ นค้าที่ลูกค้านามาจะหมด
แคชเชียร์ปิดรายการขาย
ระบบแสดงยอดรวมค่าสิ นค้าทั้งหมดรวมทั้งภาษีขายที่คานวณได้
แคชเชียร์แจ้งยอดรวมค่าสิ นค้าต่อลูกค้าและรอรับชาระเงิน
ลูกค้าชาระเงินและระบบบันทึกการรับชาระเงินนั้น
ระบบบันทึกการปิ ดรายการขาย และส่ งข้อมูลไปยังระบบสิ นค้าคงคลังเพื่อลดสต็อกสิ นค้าและ
ระบบบัญชีเพื่อบันทึกบัญชี
ระบบพิมพ์ใบเสร็ จรับเงิน
ลูกค้ารับใบเสร็ จรับเงินพร้อมกับสิ นค้าที่ซ้ื อและเดินออกจากร้าน
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
 จากคานามทั้งหมดที่ได้ จะต้องนามาพิจารณาคัดว่าคานามใดเป็ นคลาสของระบบ
ตามลักษณะต่อไปนี้ (Rumbaugh,et.al.,1991; Bahrami, 1999; Quatrani และ
Palistrant, 2006)
Redundant Class พิจารณาคาที่มีความหมายซ้ าซ้อนกับคาอื่น ให้เลือกเพียงคา
เดียว เช่น รายการขาย กับรายการขายใหม่ (ต่างกันที่สถานะ)
Irrelevant Class พิจารณาคัดเลือกคาที่ไม่เกี่ยวข้องกับระบบที่กาลังวิเคราะห์
หรื ออยูน่ อกขอบเขต เช่น ระบบสิ นค้าคงคลัง
Vague Class พิจารณาคัดเลือกคาที่มีความหมายไม่ชดั เจน ไม่สื่อความหมาย
เช่น ระบบ
Attribute พิจารณาคาที่เป็ นข้อมูลจาเพาะของคลาสอื่น เช่น รหัสสิ นค้า ชื่อ
สิ นค้า ราคา
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
Opereation พิจารณาคาที่แสดงถึงกิจกรรมของระบบ ซึ่งเป็ นการ
ระบุกิจกรรมไม่สมควรเป็ นคลาส เช่น การปิ ดรายการขาย
Role คลาสควรสื่ อความหมายถึงลักษณะโดยทัว่ ไปของสิ่ งนั้น ไม่ใช่
เพียงบทบาทของความสัมพันธ์ของคลาสอื่น ดังนั้น คาที่มีลกั ษณะ
เป็ นบทบาท ควรถูกเปลี่ยนเพื่อให้สื่อความหมายถึงลักษณะทัว่ ไป
แทน เช่น แคชเชียร์ เป็ นเพียงบทบาทพนักงานในร้าน ควรใช้
พนักงานแทนแคชเชียร์ ยกเว้นว่า แคชเชียร์มีพฤติกรรมที่แตกต่างจาก
พนักงานอื่นในระบบ
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
 ผลการพิจารณาคานามทั้งหมดตามเกณฑ์ขา้ งต้น จะได้ดงั นี้
ลูกค้า
สิ นค้า (ซ้ าซ้อนกับ รายการสิ นค้า)
แคชเชียร์
รายการขายใหม่ (ซ้ าซ้อนกับรายการขาย)
รหัสสิ นค้า ( เป็ น Attribute ของรายการสิ นค้า)
เครื่ องรับชาระเงิน
ระบบ (Vague Class)
รายการสิ นค้า
ชื่อสิ นค้า (เป็ น Attribute ของรายการสิ นค้า)
ราคา (เป็ น Attribute ของรายการสิ นค้า)
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
รายการย่อย
ยอดรวมค่าสิ นค้าที่รวมถึงรายการนี้ (เป็ น Attribute ของรายการขาย อาจตัด
ออกได้เนื่องจากรายการขายยังไม่สิ้นสุ ด)
สิ นค้าที่ลกู ค้านามา (ซ้ าซ้อนกับสิ นค้า)
รายการขาย
ยอดรวมค่าสิ นค้าทั้งหมด (เป็ น Attribute ของรายการขาย)
ภาษีขาย (เป็ น Attribute ของรายการขาย)
การรับชาระเงิน
การปิ ดรายการขาย (เป็ น Operation)
ข้อมูล (Vague Class)
ตัวอย่ างการค้ นหา Class ด้ วยวิธีการค้ นหาคานาม
ระบบสิ นค้าคงคลัง (Irrelevant Class)
ระบบบัญชี (Irrelevant Class)
ใบเสร็ จรับเงิน (เป็ นเอกสารที่มีขอ้ มูลของการรับชาระเงิน จึงซ้ าซ้อนกัน)
สิ นค้าที่ซ้ื อ (ซ้ าซ้อนกับสิ นค้า)
ร้าน
การค้ นหาคลาสตามกลุ่มลักษณะ (Common Class Pattern)
เป็ นวิธีคน้ หาคลาสสาคัญของระบบที่กาลังวิเคราะห์ โดยจะตั้งเกณฑ์ที่
เป็ นกลุ่มลักษณะของคลาสและวิเคราะห์วา่ มีคลาสในลักษณะดังกล่าว
หรื อไม่
Bahrami (1999) และ Larman (2005) ได้เสนอกลุ่มลักษณะของคลาสไว้
ตัวอย่างกลุ่มลักษณะของคลาสที่เสนอไว้ แสดงได้ดงั นี้
การค้ นหาคลาสตามกลุ่มลักษณะ (Common Class Pattern)
กลุ่มลักษณะคลาส
คาอธิบายเพิม่ เติม
รายการทางธุรกิจ
ตัวอย่ าง
ในธุรกิจที่มีการทาธุรกรรมต่างๆ จะต้องมี
รายการทางธุรกิจเสนอ
รายกายย่อยทางธุรกิจ
รายการย่อยทางธุรกิจมักจะมีรายการย่อยที่
รวมกลุ่มอยูด่ ว้ ยกัน
สิ นค้าหรื อบริ การที่เกี่ยวข้องกับ รายการธุรกิจหนึ่งมักจะเป็ นของสิ นค้า
รายการทางธุรกิจ
หรื อบริ การที่ธุรกิจมี
รายการขาย รายการ
ชาระเงิน
รายการขายย่อย
ตาแหน่งหรื อหน้าที่ของบุคลากร ใครเป็ นผูเ้ กี่ยวข้องในการเกิดรายการทาง
ที่เกี่ยวข้องกับรายการทางธุรกิจ ธุรกิจ
หรื อ Actor ของ Use Case
แคชเชียร์ ลูกค้า
ผูจ้ ดั การ
เครื่ องมือทางการเงิน
เงินสด เช็ค
ตัวสิ นค้า
การค้ นหาคลาสตามกลุ่มลักษณะ (Common Class Pattern)
ผลการค้นหาคลาสตามกลุ่มลักษณะของคลาสนี้ อาจทาให้เกิดคลาส
จานวนมาก ซึ่งบางคลาสอาจยังไม่เกี่ยวข้องโดยตรงกับระบบที่สนใจ
ดังนั้น จึงจาเป็ นต้องมีการพิจารณาเพื่อตัดคลาสที่ไม่เกี่ยวข้องออกไป
การค้ นหาคลาสโดยใช้ CRC
CRC ถูกพัฒนาในปี ค.ศ. 1989 (Beck and Cunningham) เพื่อใช้ในการ
สอนหลักการของการพัฒนาระบบเชิงวัตถุ
ใช้การระดมความคิดเพื่อกาหนดความรับผิดชอบของคลาส
(Responsibility) และการทางานร่ วมกับคลาสอื่น (Collaborator)
นิยมใช้การสร้าง CRC Card
การค้ นหาคลาสโดยใช้ CRC
การค้ นหาคลาสโดยใช้ CRC
กาหนด Class เพื่อเอามาใส่ CRC Card โดยหนึ่ง CRC card ต่อหนึ่ง Class
ชื่อ class ให้พิจารณาจาก User Story หรื อเอกสารประกอบ มองหาคานาม
ที่อยูใ่ นเอกสารเหล่านั้น ดูวา่ มีอะไรบ้าง เอาคานามแปลงมาเป็ นชื่อ class
จากนั้นให้มองหาคากริ ยาที่อยูใ่ นเอกสารชุดเดิม ดูวา่ กริ ยาดังกล่าวนั้น
class ไหนควรจะรับผิดชอบ ก็ใส่ ลงในช่อง Responsibilities ของ class
นั้น
กาหนด Super Class และSubclass ถ้ามี ทาให้จะได้คลาสเพิม่ ขึ้นมาเพื่อใช้
ในการ Inherit
การค้ นหาคลาสโดยใช้ CRC
พิจารณา Scenario ก็จะเห็นพฤติกรรมที่ class ต่างๆ จะกระทาซึ่งกันและ
กัน ไปกรอกลงช่อง Responsibilities ถ้า class หนึ่ง class ใดมีปฏิสัมพันธ์
กับ class อื่น ก็ให้ระบุ class ที่มนั เกี่ยวข้อง ลงในช่อง collaborators
เอา CRC card มาสร้างเป็ น Class Diagram โดย ในส่ วนของ
Responsibilities จะถูกแปลงเป็ น Attributes และ Operations
Collaborators จะถูกแปลงให้เป็ นเส้นความสัมพันธ์ต่างๆ
Subclasses/superclasses ก็จะแปลงเป็ น Inheritance
การค้ นหาคลาสโดยใช้ Reuse
Reuse หมายถึง การปรับปรุ งจากตัวแบบที่มีอยูแ่ ล้ว
วิธีการนี้เป็ นอีกทางเลือกหนึ่งในการพัฒนาระบบ (Larman,2005)
เนื่องจากต้นแบบที่มีอยูแ่ ล้วได้ถูกพิสูจน์วา่ เป็ นตัวแบบที่ใช้งานได้
ปัจจุบนั มีตวั แบบที่ถูกสร้างขึ้นเป็ นมาตรฐานอยู่ เช่น ทางด้านสิ นค้าคง
คลัง การเงิน เป็ นต้น
Reuse ไม่สามารถเกิดขึ้นได้ หากยังไม่มีตวั แบบที่เป็ นต้นแบบ เพื่อนาไป
ปรับปรุ งให้เหมาะสมกับความต้องการของระบบได้
Class Diagram
เป็ นแผนภาพที่ใช้แสดง Class และความสัมพันธ์ระหว่าง Class
ความสัมพันธ์ระหว่าง Class ถือเป็ นความสัมพันธ์เชิงสถิต (Static Relationship)
เป็ นความสัมพันธ์ที่มีอยูแ่ ล้วเป็ นปกติในระหว่าง Class ต่างๆ
ไม่ใช่ความสัมพันธ์ที่เกิดขึ้นเนื่องจากกิจกรรมต่างๆ (Dynamic Relationship)
Static Relationship
Dynamic Relationship
เจ้าของบัญชีเป็ นเจ้าของบัญชีเงินฝาก
เจ้าของบัญชีฝากเงินเข้าบัญชีเงินฝาก
เจ้าของบัญชีถอนเงินจากบัญชีเงินฝาก
เจ้าของบัญชีปรับปรุ งยอดบัญชีเงินฝาก
Class Diagram (ต่ อ)
Class Diagram ประกอบด้วย
กลุ่ม Class
แต่ละ Class จะแทนด้วยสี่ เหลี่ยมซึ่ งแบ่งออกเป็ น 3 ส่ วน คือ ชื่อของ Class ,
Attribute และ Operation
กลุ่มของความสัมพันธ์ (Relationship)
สัญลักษณ์ที่ใช้ในการแสดง Relationship แตกต่างกันไปตามประเภท
Abstraction
• Classification Abstraction
• Aggregation Abstraction
• Generalization Abstraction
• Association Abstraction
องค์ ประกอบของ Class
ชื่อของคลาส (Name)
ควรเป็ นคานามภาษาอังกฤษที่สื่อความหมาย
ไม่ควรยาวเกิน 15 ตัวอักษร (a-z, A-Z, 0-9)
แอตทริ บิวต์ (Attributes)
เป็ นการบอกคุณสมบัติของ Class
แต่ละ Class สามารถมีได้หลาย Attributes
หรื อไม่มีเลยก็ได้
โอเปอร์เรชัน (Operations)
คือ พฤติกรรมที่เราสามารถกระทากับ Object
แต่ละ Class มีได้หลาย Operations หรื อไม่มี
เลยก็ได้
ในทางปฏิบตั ินิยมตั้งชื่อโดยใช้คากริ ยา
Class1
Name
-Attribute1
-Attribute2
#Attribute3
Attributes
+Operation1
+Operation2
+Operation3
Operations
หลักการตั้งชื่อ Class, Attributes และ Method
1.ชื่อของ Class, Attribute และ Methods ต้องเป็ นชื่อที่สื่อความได้ และตรงกับ
ความหมายของ Class, Attribute และ Methods นั้นๆ ในกรณี ที่ชื่อเป็ นคา
ผสมให้นาคาเหล่านั้นมาเรี ยงต่อกันโดยไม่มีเครื่ องหมายใดๆ คัน่ โดยอักษร
ตัวแรกของแต่ละคา ต้องเป็ นตัวพิมพ์ใหญ่
 เช่น ตั้งชื่อ Class ที่ใช้เพื่อจาลองบัตรสมาชิก (Member Card) ว่า
“MemberCard”
2.ชื่อ Class ควรขึ้นต้นด้วยตัวอักษรภาษาอังกฤษตัวพิมพ์ใหญ่
 เช่น ReaderCounter
หลักการตั้งชื่อ Class, Attributes และ Method
3. ชื่อ Methods หรื อ Attributes ควรขึ้นต้นด้วยอักษรภาษาอังกฤษตัวพิมพ์เล็ก
 เช่น memberCardId, enterCount()
4.ชื่อ Methods ที่ใช้กาหนดค่าของ Attributes ควรขึ้นต้นด้วยคาว่า “set” แล้วตาม
ด้วยชื่อ Attribute นั้นซึ่งขึ้นต้นด้วยอักษรตัวพิมพ์ใหญ่
 เช่น Methods ที่ใช้กาหนดค่าของ Attribute “memberCardId” ควรมีชื่อ
ว่า “setMemberCardId”
5.ชื่อ Methods ที่ใช้อ่านค่าของ Attributes ควรขึ้นต้นด้วยคาว่า “get” แล้วตาม
ด้วยชื่อ Attribute นั้น ซึ่งขึ้นต้นด้วยอักษรตัวพิมพ์ใหญ่
Visibility ของ Attributes และ Operations
เป็ นการจาแนกประเภทของ Attributes และ Operation ตามความสามารถในการ
เห็นและการเข้าถึง
Public (+)
สามารถมองเห็นได้จากภายนอก เข้าไปเปลี่ยนค่า อ่านค่า หรื อเรี ยกใช้งาน
Attributes/Operations ได้
โดยทัว่ ไปจะใช้กบั Operations มากกว่า Attributes
Private (-)
ไม่สามารถมองเห็นได้จากภายนอกคลาส แต่สามารถมองเห็นได้จากภายใน
Class เองเท่านั้น
โดยทัว่ ไปจะใช้กบั Attributes มากกว่า Operations
Protected (#)
สงวนไว้สาหรับการทางาน Inheritance (Specialization) โดยเฉพาะ
Attributes/Operations ของ Superclass เมื่อ Inheritance แล้ว จะกลายไปเป็ น
Private หรื อ Protected Attributes/Operations ของ Subclass
Classes in UML
Class name
Attributes
attribute name : type
Operations
operation name(parameter : type)
: result type
Person
- taxIdNo : String
- name : String
+ income : double
+ taxPaid : Boolean
+ calcTax()
+ calcTaxBal()
UML Syntax for Attributes
visibility name : type
+ id : String
visibility: public (+), protected (#), private (-)
การตีความไม่ ขนึ้ กับ programming language
name : ชื่อของ attribute
type : ประเภทของข้ อมูล
UML syntax for operations
visibility name (parameter list) : return-type-expression
+ assignAgent (a : Agent) : Boolean
visibility: public (+), protected (#), private (-)
การตีความไม่ ขนึ้ กับ programming language
name : ชื่อ method
parameter list : arguments
return-type-expression : ประเภทของค่ าที่ return
Class Relationship
Class1
- Attribute1
- Attribute2
# Attribute3
Class1
+ Operation1
+ Operation2
+ Operation3
- Attribute1
- Attribute2
# Attribute3
0..n
+ Operation1
+ Operation2
+ Operation3
Object1
Object2
Class2
- Attribute4
+ Attribute5
- Attribute6
Object3
สัญลักษณ์แทน Classification Abstraction
+ Operation4
+ Operation5
+ Operation6
สัญลักษณ์แทน Aggregation Abstraction
Aggregation
มีได้ 2 รู ปแบบ Aggregation และ Composition
Aggregation
วัตถุมี วัตถุอนื่ ๆ เป็ นองค์ ประกอบย่ อย
เช่ น Car มี engine และwheels เป็ นองค์ ประกอบ
Composition
วัตถุมีวตั ถุอนื่ ๆ เป็ นองค์ ประกอบย่ อยทั้งหมด
การส่ ง message ติดต่ อกับวัตถุทเี่ ป็ นองค์ ประกอบรวม อาจมีผล
กับองค์ ประกอบทั้งหมด
ถ้ า delete วัตถุทเี่ ป็ นองค์ ประกอบรวม ส่ วนย่ อยจะต้ องถูก
delete ทิง้ ไปด้ วย
Class Relationship
Class1
- Attribute1
- Attribute2
# Attribute3
Class1
- Attribute1
- Attribute2
# Attribute3
+ Operation1
+ Operation2
+ Operation3
0..1
+ Operation1
+ Operation2
+ Operation3
Association Name
1..n
Class2
- Attribute4
+ Attribute5
- Attribute6
+ Operation4
+ Operation5
+ Operation6
สัญลักษณ์แทน Generalization Abstraction
Class2
- Attribute4
+ Attribute5
- Attribute6
+ Operation4
+ Operation5
+ Operation6
สัญลักษณ์แทน Association Abstraction
หลักการสร้ าง Class Diagram
(กิตติ ภักดีวฒั นะกุล, กิตติพงษ์ กลมกล่อม. UML วิเคราะห์ และออกแบบระบบเชิงวัตถุ)
1. กาหนดกรอบของ Problem Domain ให้ชดั เจน
และยึดถือ Problem Domain นี้เป็ นมาตรฐานและบรรทัดฐานในการ
วิเคราะห์ระบบ (ขอบเขตของ Problem Domain นี้ สามารถเปลี่ยนแปลง
ได้ตามช่วงเวลาแต่ไม่ควรเปลี่ยนแปลงบ่อยจนเกินความจาเป็ น)
เขียน Use Case Diagram ของ Problem Domain ที่กาหนดไว้แล้ว
พิจารณาว่า ในแต่ละ Use Case จะมี Objects อะไรอยูบ่ า้ ง เมื่อทาเช่นนี้
จนครบทุก Use Case แล้วจะได้ Object ที่มีอยูใ่ น Problem Domain
ทั้งหมด
หลักการสร้ าง Class Diagram
2. พิจารณาหา Objects ที่สามารถจับต้องได้ เห็นได้ สัมผัสได้
ซึ่งเรี ยกว่า Tangible Objects หรื อหาตัวแทนของ Tangible Objects
ในกรณี ที่มี Tangible Objects หลาย ๆ ตัวใน Problem Domain เดียวกัน
ให้ครบทุกตัว
3. พิจารณา Objects ที่ไม่สามารถจับต้องได้
ซึ่ งเรี ยกว่า Intangible Objects หรื อหาตัวแทนของ Intangible
Objects ในกรณี ที่มี Intangible Objects หลาย ๆ ตัวใน Problem Domain
เดียวกัน ที่มีอยูห่ รื อที่น่าจะมีอยูใ่ น Problem Domain ให้ครบทุกตัว
หลักการสร้ าง Class Diagram
4. ใช้ Classification Abstraction เพื่อแยกแยะและสร้าง Class
และพยายามหา Attributes และ Functions ที่มีอยูใ่ น Class นั้น ๆ
เท่าที่จะหามาได้ วาด Class ที่ได้ท้ งั หมดลงใน Class Diagram
5. หา Aggregation Abstraction
โดยพิจารณา Class ที่ได้จาก Classification Abstraction ว่ามี Class
ใดหรื อไม่ที่มีความสัมพันธ์แบบเป็ นส่ วนหนึ่ งหรื อประกอบด้วย (wholepart) กับ Class อื่น ๆ
ถ้ามีพยายามหาว่า Aggregation ที่เกิดขึ้นนั้นเป็ นแบบ One to One
หรื อ Many to One และใส่ Cardinality ให้ถูกต้อง
หลักการสร้ าง Class Diagram
6. ใช้ Generalization มาพิจารณา Class ต่างๆ ใน Class Diagram
หากเกิดมีความสัมพันธ์แบบ Generalization หรื อ Specialization
เกิดขึ้น ให้เพิ่มเติมลงใน Class Diagram ซึ่ งในขั้นตอนนี้ อาจมีการสร้าง
Class ใหม่ได้
7. ใช้ Association มาพิจารณา Class ต่าง ๆ ใน Class Diagram
เพิ่มเติมสัญลักษณ์ของ Association ลงใน Class Diagram และ
พิจารณาประเภทของความสัมพันธ์และ Cardinality (Multiplicity) ให้
ถูกต้อง
หลักการสร้ าง Class Diagram
8. พิจารณา Class Diagram ที่สร้างมาทั้งหมด ดังนี้
• ทุก Class และทุกกลุ่มของ Class มีความสัมพันธ์ (Relationship) แบบ
ใดแบบหนึ่งกับ Class หรื อกลุ่มของ Class อื่นหรื อไม่
• หากว่ามี Class ใด Class หนึ่งหรื อกลุ่มหนึ่ง ยังไม่มี Relationship ใด
กับ Class อื่นเลย อาจเกิดเนื่องจาก Class นั้นเป็ น Class ที่เกินความ
จาเป็ นจริ ง ๆ ไม่ตอ้ งมีในระบบก็ได้
• หรื ออาจเกิ ด จาก ยังขาด Class อื่ นๆ ที่ จาเป็ นต้องมี และต้อ งมี
Relationship กับ Class ดังกล่าว สิ่ งที่ตอ้ งทาหากเกิดกรณี น้ ี ข้ ึน คือ
เริ่ มต้นใหม่ต้ งั แต่ข้ นั ตอนที่ 1 โดยพิจารณาหา Objects ที่น่าจะขาด
หายหรื อ เกิ น ขึ้ น มา แล้ว ท าต่ อ มาจนจบหรื อจนกว่ า จะได้ Class
Diagram ที่สมบูรณ์
หมายเหตุ ข้อ 4 ถึง 7 สามารถทาสลับขั้นตอนกันได้
การสร้ าง Class Diagram
อย่างไรก็ตาม Class Diagram ที่ได้จะถูกนามาปรับปรุ งใหม่ในขั้นตอน
ของ Object Oriented Design (OOD) เพื่อเพิ่มความสมบูรณ์ จนกระทัง่
สามารถนามาใช้เป็ นต้นแบบในการพัฒนาระบบงานในคอมพิวเตอร์ได้
ในที่สุด
คาถามท้ ายบท
กาหนด Problem Domain ดังต่อไปนี้
ร้านเช่าซีดีแห่งหนึ่ง มีบริ การยืม CD VCD และDVD โดยลูกค้าที่จะ
เช่าต้องเป็ นสมาชิก ซึ่งมี 2 แบบคือ ลูกค้ารายเดือน กับรายปี รายเดือน
จะยืมได้ครั้งละ 2 เรื่ อง ส่ วนรายปี ยืมได้ครั้งละ 5 เรื่ อง และกาหนดให้
การยืมมีระยะเวลา 5 วัน ส่ วนอัตราค่าเช่าจะต่างกันไปตามประเภทของ
สื่ อแต่ละแบบ
จาก Problem Domain ดังกล่าว จงเขียน Class Diagram