การวิเคราะห์และออกแบบระบบ

175 ภาพที่ 6.51 ขั้นตอนการประมวลผล แบบเรียงลำดับ แบบการตัดสินใจ และแบบทำซ้ำ และจากรูปที่ 6.52 เป็นตัวอย่างคำอธิบายการประมวลผลของ Process ที่เกี่ยวข้องกับ เงื่อนไขการอนุมัติเครดิตให้กับลูกค้า ซึ่งเขียนอยู่ในรูปแบบภาษาอังกฤษแบบโครงสร้าง If credit limit exceeded Then If customer has bad payment history Then refuse credit Else If purchase is above 3000 Baht Then refuse credit Else refer to manager Else allow credit ภาพที่ 6.52 คำอธิบายการประมวลผลในรูปแบบ Structured English ภาษาอังกฤษแบบโครงสร้างเป็นประโยคที่ใช้อธิบายกระบวนการอย่างย่อๆ ซึ่งคล้ายกับซูโด โค้ด โดยไม่ขึ้นกับภาษาคอมพิวเตอร์ซึ่งโปรแกรมเมอร์ได้อ่านก็จะเข้าใจ ทั้งยังช่วยอำนวยความ สะดวกกับการออกแบบและเขียนโปรแกรม นอกจากนี้ภาษาอังกฤษแบบโครงสร้างยังช่วยหลีกเลี่ยง คำกำกวมที่เกิดขึ้นจากถ้อยคำอธิบายที่เขียนด้วยภาษาธรรมชาติ ซึ่งอาจก่อให้เกิดข้อผิดพลาดจาก

176 การสื่อสารไม่ตรงกันได้ และจากรูปที่ 6.53 ต่อไปนี้ ได้มีการนำภาษาอังกฤษแบบโครงสร้างมาใช้ อธิบายกระบวนการทำงานของ Process 2.1 ซึ่งเกี่ยวข้องกับการตรวจสอบ/บันทึกประวัติลูกค้า Process 2.1 ตรวจสอบ/บันทึกประวัติลูกค้า Ask if customer has an account (or has made a previous contract) If customer has an account then Ask for identification information Query database with identifying information Copy query response data to Contract details Else Create an empty Customer record in the database Ask customer for Customer attributes Update empty Customer record with Customer attributes Endif Ask customer for contract information for first item While more car rent items Do Update car rent item file with car rent information Endwhile ภาพที่ 6.53 ตัวอย่างภาษาอังกฤษแบบโครงสร้าง 2) ผังการตัดสินใจแบบต้นไม้ ผังการตัดสินใจแบบต้นไม้ (Decision Tree) มีลักษณะเป็นโครงสร้างเงื่อนไขคล้าย กับต้นไม้ที่แผ่กิ่งก้านสาขา ด้วยการแบ่งแยกเงื่อนไขออกเป็นส่วนๆ ทำให้เห็นโครงสร้างเงื่อนไขได้ อย่างชัดเจน ดังนั้น กรณี Process ใดที่มีเงื่อนไขซับซ้อนหรือมีตรรกะเปรียบเทียบจำนวนมาก การ นำผังการตัดสินใจแบบต้นไม้มาใช้เพื่ออธิบายการประมวลผล ถือว่าเป็นแนวทางหนึ่งที่เหมาะสม จากเงื่อนไขการเพิกถอนวิชาดังรูปที่ 6.27 สามารถอธิบายรายละเอียดได้ดังนี้

177 กรณีอนุญาตให้เพิกถอน เนื่องจากอยู่ในช่วงระยะเวลาของการเพิกถอน (Valid) ▪ กรณีเพิกถอนวิชาตามช่วงระยะเวลาที่กำหนด - นักศึกษาจะได้รับเงินคืนค่าลงทะเบียนวิชาที่เพิกถอนเต็มจำนวน - รายการวิชาที่เพิกถอนจะถูกลบทิ้งไป - การเพิกถอนวิชาเสร็จสมบูรณ์ ▪ กรณีเพิกถอนวิชาพ้นระยะเวลาที่กำหนด - นักศึกษาจะได้รับเงินคืนค่าลงทะเบียนวิชาที่เพิกถอนเพียงครึ่งหนึ่ง - วิชาที่เพิกถอนจะถูกกำหนดเกรดเป็น “W” และจะแสดงผลลง ในทรานสคริปต์ - การเพิกถอนวิชาเสร็จสมบูรณ์ กรณีไม่อนุญาตให้เพิกถอน เนื่องจากเกินช่วงระยะเวลาของการเพิกถอน (Invalid) จะ ปฏิเสธการเพิกถอนวิชา ภาพที่ 6.54 ตัวอย่างผังการตัดสินใจแบบต้นไม้ 3) ตารางการตัดสินใจ ตารางการตัดสินใจ (Decision Table) มีลักษณะเป็นตารางที่แบ่งออกเป็นส่วนๆ ประกอบด้วยส่วนสำคัญคือ ▪ เงื่อนไข (Condition) ▪ การกระทำ (Action) คือผลลัพธ์หรือการกระทำที่เกิดขึ้นจากเงื่อนไขนั้นๆ รูปที่ 6.28 เป็นตัวอย่างตารางการตัดสินใจในเรื่องของการอนุมัติบัตรเครดิต ซึ่งสามารถ อธิบายได้ดังนี้

178 เงื่อนไข (Condition) ▪ ลูกค้าใช้เงินเกินวงเงินเครดิต → ใช่ ▪ ลูกค้ามีประวัติการชำระเงินที่ดี → ไม่ ▪ มียอดค่าใช้จ่ายเกิน 3000 บาท →ใช่ การกระทำ (Action) ▪ ปฏิเสธการให้เครดิต (Refuse Credit) 1 2 3 4 5 6 7 8 Condition Credit limit exceeded Y Y Y Y N N N N Customer with good payment history Y Y N N Y Y N N Purchase above 3000 Baht Y N Y N Y N Y N Action Allow credit X X X X Refuse credit X X X Refer to manager X Key: Y = Yes, condition true N = No, condition not true ภาพที่ 6.55 ตัวอย่างคำอธิบายการประมวลผลในรูปแบบตารางการตัดสินใจ

179 ใบงาน จากระบบงานห้องสมุดในบทเรียนก่อนหน้า ที่แต่ละกลุ่มได้ดำเนินการรวบรวมความ ต้องการมาแล้วนั้น ให้ทำสร้างแบบจำลองโดยใช้โปรแกรม Draw.io 1. เขียน Context Diagram 2. เขียน Data Flow Diagram ในระดับต่างๆ 3. เขียน Process Description เฉพาะโปรเซสที่มีความซับซ้อน 4. แต่ละกลุ่มส่งตัวแทนออกมานำเสนอแผนภาพทั้งหมด

180 แบบฝึกหัด 1. แผนภาพกระแสข้อมูล (Data Flow Diagram) คืออะไร และมีวัตถุประสงค์เพื่ออะไร 2. จงอธิบายสัญลักษณ์และการทำงานของ Process, Data Flow, External Entity และ Data Store ในแผนภาพกระแสข้อมูล 3. จงอธิบายกฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล 4. จงอธิบายวิธีการสร้างแผนภาพกระแสข้อมูล มาพอเข้าใจ 5. แนวคิดการแตกระดับ (Leveling) ของแผนภาพกระแสข้อมูล หมายความว่าอย่างไร ให้ ยกตัวอย่างประกอบ 6. การตรวจสอบความสมดุลของแผนภาพกระแสข้อมูล (Balancing DFD) หมายความว่าอย่างไร ให้ยกตัวอย่างประกอบ 7. การสร้างแผนภาพบริบท (Context Diagram) มีหลักในการสร้างอย่างไร 8. แผนภาพระดับ 0 หรือ ไดอะแกรม 0 (Diagram 0) เป็นแผนภาพที่แสดงถึงอะไร 9. ทุกๆ Process ในไดอะแกรม 0 จำเป็นต้องแตกเป็นไดอะแกรมระดับล่างหรือไม่ 10. คำอธิบายการประมวลผล มีความเกี่ยวข้องกับ Process บนแผนภาพกระแสข้อมูลอย่างไร

181 เฉลยแบบฝึกหัด 1. แผนภาพกระแสข้อมูล หมายถึง แผนภาพที่แสดงให้เห็นถึงทิศทางการไหลของข้อมูลที่มีอยู่ใน ระบบ และกระบวนการดำเนินงานที่เกิดขึ้นในระบบ มีวัตถุประสงค์เพื่อ ต้องการแสดงข้อเท็จจริงใน การทำงานและข้อมูลของระบบที่เก็บรวบรวมมาในรูปแบบของข้อความ ให้เป็นแผนภาพเพื่อความ สะดวกในการสื่อสารระหว่างนักวิเคราะห์ระบบและโปรแกรมเมอร์หรือผู้ที่เกี่ยวข้องคนอื่นๆ และ ง่ายต่อความเข้าใจของผู้ใช้และเจ้าของระบบ 2. Gane & Sarson Demarco & Yourdon ความหมาย กระบวนการทำงานของระบบ (Process) - ขั้นตอนการ ทำงานภายในระบบ แหล่งจัดเก็บข้อมูล (Data Store) – แหล่งข้อมูลสามารถ เป็นได้ทั้งไฟล์ข้อมูลและ ฐานข้อมูล (File or Database) ตัวแทนข้อมูล (External Entity) - ปัจจัยหรือ สภาพแวดล้อมที่มีผลกระทบ ต่อระบบ เส้นทางการไหลของข้อมูล (Data Flows) - เส้นทางการ ไหลของข้อมูล แสดงทิศทาง ของข้อมูลจากขั้นตอนการ ทำงานหนึ่งไปยังอีกขั้นตอน หนึ่ง 3. กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูลมีดังนี้ - เมื่อมีข้อมูลเข้าไปยัง Process ย่อมมีข้อมูลหรือผลลัพธ์ออกจาก Process เสมอ และชื่อ ของ Process จะใช้คำกริยา ที่หมายถึงการกระทำ

182 - ข้อมูลจะไหลจาก Data Store หนึ่งไปยังอีก Data Store หนึ่งโดยตรงไม่ได้ จะต้องไหล ผ่าน Process เท่านั้น - ข้อมูลที่ส่งผ่านจาก External Entity ไม่สามารถไหลผ่านเข้าไปยัง Data Store โดยตรง จะต้องใช้ Process เป็นตัวกลางในการเชื่อมโยง เพื่อจัดเก็บข้อมูลลงใน Data Store ต่อไป - ข้อมูลที่ไหลผ่านจาก Data Store ไม่สามารถเชื่อมโยงเข้ากับ External Entity ได้โดยตรง จะต้องเชื่อมโยงผ่าน Process เท่านั้น และชื่อของ Data Store จะใช้คำนาม - External Entity ไม่สามารถเชื่อมโยงข้อมูลด้วยกันเอง จะต้องใช้ Process เป็นตัวกลาง เพื่อการส่งผ่าน และชื่อของ External Entity จะใช้คำนาม - กระแสข้อมูลที่มีหัวลูกศรชี้ไปยัง Process หมายถึง Process มีการอ่านหรือดึงข้อมูลจาก Data Store มาใช้งาน - กระแสข้อมูลจาก Process ที่มีหัวลูกศรชี้ไปยัง Data Store หมายถึงการ update หรือ การเพิ่มข้อมูลลงใน Data Store - กระแสข้อมูลที่มีหัวลูกศรทั้งสองด้าน ที่เชื่อมโยงไปมาระหว่าง Process กับ Data Store หมายถึง มีการดึงข้อมูลจาก Data Store มาปรับปรุง แล้ว update ข้อมูลลงใน Data Store - กระแสข้อมูลไม่สามารถเชื่อมโยงย้อนกลับไปยัง Process เดิมได้ อย่างน้อยต้องเชื่อมโยง ผ่าน Process ใด Process หนึ่ง เพื่อส่งผ่านย้อนกลับมายัง Process เดิม - ชื่อที่ระบุในกระแสข้อมูลจะใช้คำนาม 4. วิธีการสร้างแผนภาพกระแสข้อมูล มีขั้นตอนดังนี้ 1) นำความต้องการที่รวบรวมมาทำการวิเคราะห์ และกำหนดขอบเขตของระบบ ด้วยการระบุ External Entity ที่เกี่ยวข้อง (ไม่ว่าจะเป็นบุคคล หน่วยงาน หรือระบบงาน) รวมถึงกระแสข้อมูลที่ เข้าออกภายในระบบ 2) สร้าง Context Diagram เพื่อแสดงภาพรวมและขอบเขตของระบบที่จะพัฒนา แผนภาพนี้ จะทำให้เรารู้ว่า มีกระแสข้อมูลอะไรจาก External Entity ที่ส่งเข้ามายังระบบ ในขณะเดียวกัน ตัว ระบบได้ส่งกระแสข้อมูลอะไรออกไปยัง External Entity 3) วิเคราะห์ว่า ควรมีข้อมูลอะไรบ้างที่ต้องจัดเก็บในระบบ (ได้มาจากแผนภาพ ER) 4) เขียนไดอะแกรม 0 เพื่อแสดงถึง Process หลักๆ ในระบบ 5) เขียนไดอะแกรมระดับต่ำลงมา โดยไดอะแกรมระดับล่างสุดจะเป็น Process ที่ไม่สามารถ แตกย่อยต่อไปได้อีกแล้ว 5. การแตกระดับของแผนภาพกระแสข้อมูล เป็นการขยายรายละเอียดของกระบวนการเพื่ออธิบาย ขั้นตอนการทำงานของระบบ ขั้นตอนแรก นักวิเคราะห์ระบบจะเริ่มต้นด้วยการสร้างแผนภาพบริบท (Context Diagram) ขึ้นมาก่อน เพื่อแสดงมุมมองหรือบริบทของระบบงานในภาพรวมก่อน ซึ่ง

183 แผนภาพบริบทจะแสดงภาพรวมและขอบเขตการทำงานของระบบ หลังจากแผนภาพบริบทถูกสร้าง ขึ้น ลำดับถัดมานักวิเคราะห์ระบบก็จะสร้างแผนภาพลำดับถัดไปที่เรียกว่าไดอะแกรม 0 เพื่อแสดง Process หลักๆ ของระบบ และหาก Process ใดๆ ในไดอะแกรม 0 จำเป็นต้องแตกรายละเอียดลง ไปอีก (Lower-Level) ก็จะแตก Process เหล่านั้นจนกระทั่งไม่สามารถแตกย่อยได้อีก (Functional Primitives) 6. การตรวจสอบความสมดุลของแผนภาพกระแสข้อมูล (Balancing DFD) หมายถึง ความสมดุล ของแผนภาพกระแสข้อมูลที่จะต้องมี ข้อมูลนำเข้า (Input Data Flow) ที่เข้าสู่ระบบและ ข้อมูลที่ ต้องการแสดงผล (Output Data Flow) ที่ออกจากระบบในแผนภาพกระแสข้อมูลระดับล่างครบทุก ข้อมูลที่เข้าและออก (Input/Output Data Flow) ที่ปรากฏอยู่ในแผนภาพกระแสข้อมูลระดับบน แต่ในระดับล่างอาจมีมากกว่าได้ โดยมีเงื่อนไขว่า ข้อมูลนำเข้า (Input Data Flow) และ ข้อมูลที่ ต้องการแสดงผล (Output Data Flow) นั้นจะต้องเกิดจาก Process ภายในระดับล่างเท่านั้น และ จะนำไปใช้ตรวจสอบความสมดุลของแผนภาพอีกระดับ หากมีการแบ่งย่อยแผนภาพในระดับล่างลง ไปอีก 7. - วางสัญลักษณ์Process 1 Process ไว้ตรงกลางหน้ากระดาษ ซึ่งจะแทนระบบงาน ภายใน Process ให้ใส่ชื่อระบบงาน - วาง External Entity ภายนอกที่เกี่ยวข้องไว้รอบๆ Process - ลากเส้น Data Flow เพื่อนำข้อมูลเข้าสู่ Process และนำข้อมูลที่ประมวลผลในระบบแล้วออก จาก Process 8. แผนภาพกระแสข้อมูลในระดับที่แสดงขั้นตอนการทำงานหลักทั้งหมด (Process หลัก) ของระบบ ว่ามีกระบวนการหรือขั้นตอนอะไรบ้าง แสดงทิศทางการไหลของกระแสข้อมูล (Data Flow) และ แสดงรายละเอียดของแหล่งจัดเก็บข้อมูล (Data Store) ในแต่ละ Process จะมีหมายเลขกำกับอยู่ ด้านบนของสัญลักษณ์ตั้งแต่ 1 เป็นต้นไป 9. ไม่จำเป็น บาง Process ที่ไม่มีความซับซ้อนก็ไม่จำเป็นต้องแตกย่อยอีกต่อไป 10. คำอธิบายการประมวลผล ทำให้รู้ว่าแต่ละ Process ในแผนภาพกระแสข้อมูลมีรายละเอียด การอย่างไร

184 3.3 แบบจำลองข้อมูล นอกจากการออกแบบจำลองกระบวนการเพื่อแสดงถึงขั้นตอนการดำเนินงานทางธุรกิจแล้ว ใน การการออกแบบจำลองกระบวนการนั้นจะต้องแสดงถึงข้อมูลที่นำมาใช้ร่วมกับแต่ละกระบวนการ ด้วย ตัวอย่างเช่น กระบวนการสั่งซื้อสินค้า จะต้องมีข้อมูลลูกค้า ข้อมูลสินค้า และข้อมูลการสั่งซื้อ เข้ามามีส่วนเกี่ยวข้องกับกระบวนการดังกล่าว ในบทนี้เราจะมากล่าวถึงข้อมูลที่ไหลผ่าน กระบวนการ รวมถึงการจัดระเบียบกับข้อมูลเหล่านั้น แบบจำลองข้อมูลเป็นเทคนิคหนึ่ง ที่นำมาใช้อธิบายโครงสร้างและความสัมพันธ์ระหว่าง ข้อมูลในระบบธุรกิจ ว่าข้อมูลเหล่านั้นมีความสัมพันธ์กันอย่างไร โดยในระยะการวิเคราะห์ นักวิเคราะห์ระบบจะสร้าง แบบจำลองข้อมูลเชิงแนวคิด (Conceptual Data Model) ขึ้นมาก่อน ซึ่งก็คือแผนภาพอีอาร์ เพื่อแสดงภาพรวมของระบบธุรกิจอย่างคร่าวๆ ว่าต้องมีข้อมูลหลักๆ สำคัญๆ อะไรบ้าง ลำดับต่อมาจึงพัฒนา แบบจำลองข้อมูลเชิงตรรกะ (Logical Data Model) ด้วยการนำ แผนภาพอีอาร์มาแปลงให้อยู่ในรูปของรีเลชันสคีมา เมื่อเข้าสู่ระยะการออกแบบ แบบจำลองข้อมูล เชิงตรรกะก็จะได้รับการเปลี่ยนแปลงจนกลายเป็น แบบจำลองข้อมูลเชิงกายภาพ (Physical Data Models) ที่แสดงให้เห็นถึงวิธีการจัดเก็บข้อมูลเหล่านั้นลงในแฟ้มข้อมูลและฐานข้อมูลจริงๆ ได้ อย่างไร มีขนาดความจุเท่าไร ซึ่งนักวิเคราะห์ระบบจะสำรวจแนวทางในการจัดเก็บข้อมูลเหล่านั้น เพื่อให้เกิดประสิทธิภาพสูงสุด และง่ายต่อการดึงข้อมูลออกมาใช้งาน 3.3.1 แนะนำแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram) หมายถึง แผนภาพที่ใช้เป็นเครื่องมือสำหรับจำลองข้อมูลซึ่งจะประกอบด้วย เอ็นทิตี้ (Entity) ซึ่งแทนกลุ่มของ ข้อมูลที่เป็นเรื่องเดียวกันหรือเกี่ยวข้องกัน คุณสมบัติ (Attribute) ซึ่งหมายถึงคุณสมบัติของเอ็นทิตี้ และความสัมพันธ์ระหว่างข้อมูล (Relationship) ที่เกิดขึ้นทั้งหมดในระบบ แผนภาพแสดง ความสัมพันธ์ระหว่างข้อมูลถูกสร้างขึ้นมาเพื่อใช้เป็นแบบจำลองข้อมูลในการออกแบบฐานข้อมูล และใช้อธิบายความสัมพันธ์ระหว่างข้อมูล ซึ่งจะถูกสร้างขึ้นมาพร้อมๆ กับขั้นตอนการวิเคราะห์ ความต้องการ ที่ได้มาจากการเข้าไปสืบเสาะ ค้นหาข้อเท็จจริง เพื่อให้ได้ความต้องการของผู้ใช้ จากนั้นก็จะนำมาวิเคราะห์เพื่อสร้างเป็นข้อกำหนดความต้องการของระบบใหม่ ด้วยการสร้าง แบบจำลองกระบวนการขึ้นมา ซึ่งก็คือ แผนภาพกระแสข้อมูล ที่แสดงถึงความสัมพันธ์ระหว่าง Process กับข้อมูลที่ไหลไปยังกระบวนการต่างๆ โดยข้อมูลที่ถูกจัดเก็บลงในดาต้าสโตร์เหล่านั้น จะ ถูกบันทึกลงในฐานข้อมูลอย่างมีระบบ และนำดาต้าสโตร์เหล่านั้นมาออกแบบเป็นแบบจำลองข้อมูล ซึ่งแสดงด้วยแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram) ซึ่งการ สร้างแผนภาพจำลองข้อมูลและกระบวนการดำเนินงานของระบบนั้นมีบทบาทสำคัญในการพัฒนา

185 ระบบ เนื่องจากสามารถแสดงโครงสร้างของข้อมูลและการทำงานภายในระบบได้ชัดเจน ซึ่งจะช่วย ให้ทั้งนักวิเคราะห์ระบบและผู้ใช้งานเกิดความเข้าใจในการทำงานของระบบอย่างถูกต้อง 3.3.2 สัญลักษณ์ที่ใช้ในแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล สัญลักษณ์ที่ใช้ในแผนภาพประกอบด้วย เอ็นทิตี้ (Entity) คุณสมบัติ (Attribute) และ ความสัมพันธ์ (Relationship) ดังรายละเอียดต่อไปนี้ เอ็นทิตี้ เอ็นทิตี้ (Entity) หมายถึง สิ่งของหรือวัตถุที่เกี่ยวข้องกับความต้องการทางธุรกิจที่นำมาใช้ จัดเก็บข้อมูล เช่น เอ็นทิตี้ชื่อ CUSTOMER ที่ใช้แทนลูกค้า เอ็นทิตี้ STUDENT ที่ใช้แทนนักเรียน เป็นต้น เอ็นทิตี้อาจหมายถึงสิ่งต่าง ๆ ต่อไปนี้ - บุคคล (Persons) เช่น ลูกค้า พนักงาน นักศึกษา ผู้ป่วย เป็นต้น นอกจากนี้ เอ็นทิตี้ยัง สามารถแทนกลุ่มคนหรือองค์กร เช่น ทีมงาน แผนก ฝ่าย และร้านค้า เป็นต้น - สถานที่ (Place) เช่น อาคาร ห้อง สาขา วิทยาเขต แคมปัส เป็นต้น - วัตถุ (Objects) เช่น หนังสือ เครื่องจักร อะไหล่ชิ้นส่วน สินค้า เครื่องยนต์ เป็นต้น - เหตุการณ์ (Events) เช่น การลงทะเบียน การจอง การสั่งซื้อ - แนวความคิด (Concepts) เช่น บัญชี พันธบัตร หลักสูตร กองทุน เป็นต้น สัญลักษณ์ที่ใช้แสดงแทนเอ็นทิตี้ จะเป็นรูปสี่เหลี่ยมผืนผ้าที่มีชื่อเอ็นทิตี้กำกับอยู่ภายใน ดัง แสดงในภาพที่ 7.1 ภาพที่ 7.1 สัญลักษณ์ Entity CUSTOMER และ STUDENT คุณลักษณะ คุณลักษณะ (Attributes) หมายถึงคุณลักษณะเฉพาะของแต่ละเอ็นทิตี้ เช่น เอ็นทิตี้ลูกค้า (CUSTOMER) ประกอบด้วยคุณลักษณะ ดังนี้ รหัสลูกค้า (custID) ชื่อลูกค้า (custName) นามสกุล ลูกค้า (custSurname) วันเกิดลูกค้า (birthDate) เพศลูกค้า (custGender) ที่อยู่ลูกค้า (custAddress) โทรศัพท์ลูกค้า (custTel) สัญลักษณ์คุณลักษณะของแต่ละเอ็นทิตี้ในแผนภาพอีอาร์ สามารถเลือกเขียนตามมาตรฐานของ Peter Chen (ภาพที่ 7.2) หรือมาตรฐานของ Crow’s Foot Model (ภาพที่ 7.3) ก็ได้ จากรูปจะเห็นมีบางคุณลักษณะถูกขีดเส้นใต้ไว้ ซึ่งหมายความว่า คุณลักษณะนั้นถูกกำหนดให้เป็นคีย์หลัก (Primary Key : PK) CUSTOMER STUDENT

186 ภาพที่ 7.2 ตัวอย่าง Attribute แบบ Peter Chen ของ Entity ลูกค้า ภาพที่ 7.3 ตัวอย่าง Attribute แบบ Crow’s Foot Model ของ Entity ลูกค้า ความสัมพันธ์ ความสัมพันธ์ (Relationships) หมายถึง ความสัมพันธ์ระหว่าเอ็นทิตี้ ซึ่งแต่ละเอ็นทิตี้ จะต้องมีความสัมพันธ์ระหว่างกันเสมอ ความสัมพันธ์แต่ละความสัมพันธ์จะถูกระบุด้วยชื่อที่ใช้ อธิบายความสัมพันธ์นั้นๆ การตั้งชื่อความสัมพันธ์โดยทั่วไปจะใช้คำกริยาที่แสดงการกระทำ เช่น สอน สั่งซื้อ ว่าจ้าง เป็นต้น ตัวอย่างของความสัมพันธ์ระหว่างเอ็นทิตี้ เช่น อาจารย์ สอน วิชา ลูกค้า สั่งซื้อ สินค้า เป็นต้น ความสัมพันธ์มี 3 ชนิด คือ ความสัมพันธ์แบบหนึ่งต่อหนึ่ง (1:1) ความสัมพันธ์ แบบหนึ่งต่อกลุ่ม (1:M) และความสัมพันธ์แบบกลุ่มต่อกลุ่ม (M:N) - ความสัมพันธ์แบบหนึ่งต่อหนึ่ง (1:1) เป็นความสัมพันธ์ที่เอ็นทิตี้สองเอ็นทิตี้ที่มีส่วนร่วมใน ความสัมพันธ์ต่างมีความสัมพันธ์กับอีกเอ็นทิตี้หนึ่งอย่างมากหนึ่งเอ็นทิตี้ เช่น พนักงานเป็นคณบดีได้ อย่างมากหนึ่งคณะ และคณะหนึ่งคณะสามารถมีคณบดีได้อย่างมากหนึ่งคน ดังภาพที่ 7.3

187 ภาพที่ 7.4 ความสัมพันธ์แบบ 1:1 - ความสัมพันธ์แบบหนึ่งต่อกลุ่ม (1:M) คือ การที่เอ็นทิตี้หนึ่งมีส่วนร่วมในความสัมพันธ์กับ อีกเอ็นทิตี้หนึ่งอย่างมากหนึ่งเอ็นทิตี้ แต่อีกเอ็นทิตี้หนึ่งในทางกลับกันมีความสัมพันธ์กับเอ็นทิตี้นั้น อย่างมากหลาย (M) เอ็นทิตี้ เช่น พนักงานหนึ่งคนทำงานให้กับหนึ่งคณะแต่คณะหนึ่งสามารถมี พนักงานทำงานได้หลายคน ดังแสดงในภาพที่ 7.4 ภาพที่ 7.5 ความสัมพันธ์แบบ 1:M - ความสัมพันธ์แบบกลุ่มต่อกลุ่ม (M:N) คือการที่เอ็นทิตี้สองเอ็นทิตี้ที่มีส่วนร่วมใน ความสัมพันธ์ ต่างมีความสัมพันธ์กับอีกเอ็นทิตี้หนึ่งอย่างมากหลาย (M) เอ็นทิตี้ เช่น นักศึกษาหนึ่ง คนสามารถลงทะเบียนเรียนได้หลายวิชา และแต่ละวิชาสามารถมีนักศึกษาลงทะเบียนเรียนได้หลาย คน ดังรูปที่ 7.5

188 ภาพที่ 7.6 ความสัมพันธ์แบบ M:N ความสัมพันธ์จะเกิดขึ้นตามธรรมชาติในกระบวนการทางธุรกิจ โดยนำเสนอผ่านเหตุการณ์ เชื่อมโยงระหว่างเอ็นทิตี้ เช่น ลูกค้ามีความสัมพันธ์กับสัญญาเช่ารถ หรือพนักงานมีความสัมพันธ์กับ แผนกที่ตนสังกัดอยู่ ภาพที่ 7.7 ความสัมพันธ์ระหว่างเอ็นทิตี้ในรูปแบบต่างๆ การกำหนดความสัมพันธ์ระหว่างเอ็นทิตี้ สามารถกำหนดในรูปแบบอย่างง่ายดังรูปที่ 7.6 หรือจะกำหนดความสัมพันธ์ให้ละเอียดยิ่งขึ้นในรูปแบบ Mandatory ภาพรูปที่ 7.7 ก็ได้

189 ภาพที่ 7.8 ความสัมพันธ์ระหว่างเอ็นทิตี้ในรูปแบบ Mandatory ต่อไปนี้เป็นตัวอย่างการกำหนดความสัมพันธ์ระหว่างเอ็นทิตี้ในระบบการเช่ารถ - ลูกค้าหนึ่งคน ทำสัญญาเช่าได้มากกว่าหนึ่งฉบับ (1:M) - สัญญาเช่าหลายๆ ฉบับ สามารถเช่ารถได้หลายคัน (M:N) จากความสัมพันธ์ M:N ต้องแปลงเป็นความสัมพันธ์แบบหนึ่งต่อกลุ่ม ด้วยการเพิ่มเอ็นทิตี้ รายการเช่ารถแทรกระหว่างกลาง ดังนี้ สัญญาเช่าหนึ่งฉบับ สามารถทำรายการเช่ารถได้หลายคัน (1:M) และรถหนึ่งคัน สามารถถูก เช่าได้หลายครั้ง (1:M) - ลูกค้าหนึ่งคน จองรถได้หลายคัน (1:M)

190 - รถหนึ่งคัน เข้ารับบริการอู่ซ่อมได้หลายครั้ง จึงมีใบส่งซ่อมได้หลายใบ (1:M) - ใบส่งซ่อมหนึ่งฉบับ มีรายการซ่อมได้มากกว่าหนึ่งรายการ (1:M) เมื่อนำแผนภาพแต่ละภาพจากข้างต้นมารวมอยู่ในแผนภาพเดียวกัน จะได้แผนภาพอีอาร์ทั้ง ระบบดังนี้ ภาพที่ 7.9 แผนภาพอีอาร์ของระบบการเช่ารถ 3.3.3 ความสมดุลระหว่างแผนภาพอีอาร์กับแผนภาพกระแสข้อมูล ความสมดุลระหว่างแผนภาพอีอาร์กับแผนภาพกระแสข้อมูล หมายถึง ส่วนประกอบของ ข้อมูลในแผนภาพกระแสข้อมูล จะต้องสอดคล้องกับข้อมูลในแผนภาพอีอาร์ คือ ดาต้าสโตว์ที่ ปรากฏอยู่ในแผนภาพกระแสข้อมูล จะต้องปรากฏอยู่ในแผนภาพอีอาร์เสมอ วิธีการตรวจสอบความ สมดุลระหว่างแผนภาพอีอาร์กับแผนภาพกระแสข้อมูลให้พิจารณาจากจำนวนดาต้าสโตว์ที่ปรากฎ อยู่ในไดอะแกรม 0 จะต้องมีจำนวนเท่ากับเอ็นทิตี้ในแผนภาพอีอาร์ ตัวอย่างเช่นในไดอะแกรม 0 ของระบบประเมินการสอนออนไลน์ในภาพที่ 7.10 ประกอบไปด้วยดาต้าสโตว์จำนวน 8 ดาต้าสโตว์ คือตั้งแต่ D1 จนถึง D8 ดังนั้นเมื่อสร้างแผนภาพอีอาร์ที่มีความสมดุลกับไดอะแกรม 0 จะต้อง ประกอบไปด้วยเอ็นทิตี้เท่ากับจำนวนดาต้าสโตว์ที่ปรากฎในไดอะแกรม 0 ภาพที่ 7.10

191 1.0 2.0 3.0 4.0 D1 D2 D3 D4 D5 D6 D7 D8 D4 D1 D2 D3 D5 D6 D7 D 8 ภาพที่ 7.10 ไดอะแกรม 0 : ระบบประเมินการสอนออนไลน์

192 ภาพที่ 7.11 แผนภาพอีอาร์ระบบประเมินการสอนออนไลน์ 3.3.4 พจนานุกรมข้อมูล วัตถุประสงค์หลักของการจัดทำพจนานุกรมข้อมูลคือ การรวบรวมรายละเอียดข้อมูลอย่าง เป็นหมวดหมู่เพื่อให้ผู้ที่เกี่ยวข้อง เช่น ผู้บริหารข้อมูล โปรแกรมเมอร์ หรือผู้ที่ต้องการสื่อสารการ ทำงานของระบบเกิดความเข้าใจความหมายของข้อมูลได้อย่างถูกต้องตรงกัน ลักษณะของระบบงาน และวัตถุประสงค์การใช้งานพจนานุกรมมีความแตกต่างกันไป เช่น พจนานุกรมสำหรับระบบ ฐานข้อมูลจะมีรายละเอียดเกี่ยวกับกฎการรักษาความปลอดภัยของข้อมูล ขนาดของข้อมูล การ กำหนดโครงสร้างดัชนีหรือกำหนดคีย์หลัก เป็นต้น พจนานุกรมข้อมูล (Data dictionary) จะ ประกอบด้วยหน่วยข้อมูลหรือข้อมูลย่อย (Data Element) ในระบบ ซึ่งข้อมูลย่อยเหล่านี้คือข้อมูลที่ ไม่สามารถแตกย่อยออกไปได้อีกแล้ว เช่น ข้อมูลลูกค้า ประกอบด้วย รหัสลูกค้า ชื่อลูกค้า ที่อยู่ ลูกค้า เป็นต้น และเมื่อนำข้อมูลย่อยต่างๆ รวมเข้าด้วยกันก็จะเป็นเรคอร์ด จนในที่สุดก็กลายเป็น โครงสร้างแฟ้มข้อมูลขึ้นมา พจนานุกรมข้อมูล เป็นเอกสารใช้อธิบายรายละเอียดโครงสร้างแฟ้มข้อมูล รายการข้อมูล ซึ่ง ประกอบด้วย ชื่อของรีเลชัน (Relation), แอตทริบิวต์ (Attribute), ชื่อแทน (Aliase), รายละเอียด

193 ข้อมูล (Data Description), แอตทริบิวต์โดเมน (Attribute Domain), ลำดับดัชนี (Index), คีย์หลัก (Primary Key), คีย์นอก (Foreign Key) และชนิดข้อมูล (Data Type) นอกจากนี้ พจนานุกรม ข้อมูลยังอาจรวมรายละเอียดที่เกี่ยวข้องกับแหล่งกำเนิดข้อมูล วันที่สร้างแฟ้มข้อมูล ผู้ใช้ระบบ สิทธิ การใช้งานแฟ้มข้อมูล ความถี่ในการใช้งาน และอื่นๆ ต่อไปนี้เป็นตัวอย่างการนำเสนอพจนานุกรมข้อมูลในรูปแบบของโครงสร้างแฟ้มข้อมูล ซึ่ง เป็นเอกสารที่ทำให้เราเห็นถึงโครงสร้างภายในแฟ้มข้อมูลว่า ประกอบด้วยรายละเอียดอะไรบ้าง ซึ่ง สามารถนำไปอ้างอิงหรือใช้ประโยชน์เพื่องานออกแบบฐานข้อมูลต่อไป Relation Attribute Description Attribute Domain Type PK FK Reference CUSTOMER cus_no รหัสลูกค้า Text(6) Yes name ชื่อ Text(40) surname นามสกุล Text(40) gender เพศ F=Female Text(1) address1 ที่อยู่ 1 M=Male Text(50) address2 ที่อยู่ 2 Text(50) per_id เลขที่บัตร ประชาชน Text(13) psp_id เลขที่พาสปอร์ต Text(20) driver_lic_no เลขที่ใบขับขี่ Text(10) nationality สัญชาติ Text(15) origin เชื้อชาติ Text(15) date_contact วันที่ติดต่อครั้ง แรก Date cus_status สถานะของ ลูกค้า - ลูกค้าชั้นดี - ลูกค้าปกติ - Blacklist Text(15) CAR car_no รหัสรถ Text(4) Yes car_type ประเภทรถ - 4WD - Utility Pickup - Sedan - Luxury Sedan Text(20) brand ยี่ห้อ Text(18) model รุ่น/รายละเอียด Text(50)

194 Relation Attribute Description Attribute Domain Type PK FK Reference year ปีที่ซื้อ Text(4) reg_id เลขทะเบียนรถ Text(6) date_reg วันที่จดทะเบียน Date date_ins วันที่ต่อ ประกันภัย Date mile_no_before หมายเลขไมล์ ก่อน Text(6) mile_no_after หมายเลขไมล์ หลัง Text(6) rate ค่าเช่าต่อวัน Number charge ค่าปรับต่อวัน Number car_status สถานะรถ - พร้อม ปล่อยเช่า - ถูกเช่า - ถูกจอง - รออนุมัติ การซ่อม - กำลังซ่อม บำรุง - สงวนไว้ Text(20) CONTRACT contract_no เลขที่สัญญา Text(8) Yes contract_date วันที่ทำสัญญา Date cus_no รหัสลูกค้า Text(6) description รายละเอียดการ เช่า Text(80) payment_date วันที่รับชำระ Date net_deposit ค่ามัดจำสุทธิ Number net_discount ยอดส่วนลดสุทธิ Number net_charge ยอดค่าปรับสุทธิ Number vat ภาษีมูลค่าเพิ่ม Number net ยอดรวมสุทธิ Number cash_payment ยอดเงินสุทธิที่ ชำระด้วยเงินสด Number

195 Relation Attribute Description Attribute Domain Type PK FK Reference credit_payment ยอดเงินสุทธิที่ ชำระด้วยบัตร เครดิต Number bank_name ชื่อธนาคาร Text(30) card_no เลขที่บัตรเครดิต Text(16) CARRENT_ITEM contract_no เลขที่สัญญา Text(8) Yes Yes CONTRACT car_no รหัสรถ Text(4) Yes Yes CAR rate ค่าเช่าต่อวัน Number rental_date วันที่เช่า Date days จำนวนวัน Number expire_date วันครบกำหนด Date return_date วันที่ส่งคืน Date day_of_late ส่งคืนล่าช้ากี่วัน Number amount จำนวนเงิน Number discount ส่วนลด Number charge ค่าปรับ Number RESERVE_ITEM cus_no รหัสลูกค้า Text(6) Yes Yes CUSTOMER car_no รหัสรถที่จอง Text(4) Yes Yes CAR description รายละเอียด Text(50) use_date วันที่ใช้งาน Date days จำนวนวัน Number deposit ค่ามัดจำ Number card_no เลขที่บัตรเครดิต Text(16) bank ชื่อธนาคาร Text(20) JOB_NOTICE job_no เลขที่ใบส่งซ่อม Text(6) Yes Yes car_no รหัสรถ Text(4) Yes CAR cheq_no เลขที่เช็คสั่งจ่าย Text(15) delivery_date วันที่ส่งซ่อม Date finish_date วันที่ซ่อมเสร็จ Date details รายละเอียดการ ซ่อม Memo part_amount ยอดค่าอะไหล่ สุทธิ Number effort_amount ยอดค่าแรงสุทธิ Number disc_amount ยอดส่วนลดสุทธิ Number

196 Relation Attribute Description Attribute Domain Type PK FK Reference car_status สถานะ - ไม่อนุมัติ การซ่อม - อยู่ระหว่าง การซ่อม - กำลัง ทดสอบ - พร้อมส่ง มอบ - Job Closed Text(20) REPAIR_ITEM job_no เลขที่ใบส่งซ่อม Text(6) Yes Yes JOB_NOTICE seq ลำดับที่ Text(2) Yes part_details รายการอะไหล่ Text(40) quantity จำนวน Number unit_price ราคาต่อหน่วย Number discount ส่วนลด Number ภาพที่ 7.12 โครงสร้างแฟ้มข้อมูลของระบบการเช่ารถ 3.3.5 วิธีการสร้างแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล ในหัวข้อนี้จะนำเสนอวิธีการสร้างแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram) ตามลำดับดังนี้ กำหนดเอ็นทิตี้ (Entity) ทั้งหมดของระบบ สร้าง ความสัมพันธ์ (Relationship) ระหว่างเอ็นทิตี้ กำหนดเงื่อนไข (Constraints) ของความสัมพันธ์ ระหว่างเอ็นทิตี้ต่างๆ และกำหนดคุณสมบัติ (Attribute) ให้กับแต่ละเอ็นทีตี้ พร้อมทั้งกำหนดคีย์ หลัก (Primary Key) ตัวอย่าง การเก็บรวบรวมข้อมูลสมมติของมหาวิทยาลัยแห่งหนึ่ง เปิดสอนหลักสูตรปริญญา ตรีหลายคณะแต่ละคณะเปิดสอนหลายวิชา ซึ่งทำการสอนโดยอาจารย์ที่มีคุณภาพ แต่ละรายวิชาจะ สามารถเปิดสอนได้ก็ต่อเมื่อมีนักศึกษามาลงทะเบียนในรายวิชานั้นอย่างน้อย 20 คน อาจารย์ 1 ท่านสามารถสอนได้หลายวิชา และห้องเรียนแต่ละห้องสามารถใช้สอนวิชาต่างๆ ได้หลายวิชา จาก ข้อมูลดังกล่าวนำมาสร้างเป็นแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูลหรือแผนภาพอีอาร์ (Entity Relationship Diagram) ตามขั้นตอนต่อไปนี้ กำหนดเอ็นทิตี้ (Entity) ทั้งหมดของระบบ จากข้อมูลสมมติของมหาวิทยาลัยแห่งหนึ่ง สามารถกำหนด Entity ได้ดังนี้

197 - คณะ (Faculty) - รายวิชา (Course) - อาจารย์ (Teacher) - นักเรียน (Student) - ห้องเรียน (Room) ภาพที่ 7.13 Entity ที่กำหนดได้จากโจทย์ตัวอย่าง สร้างความสัมพันธ์(Relationship) ระหว่างเอ็นทิตี้ จาก Entity และข้อมูลข้างต้น นำมาเขียนเป็นความสัมพันธ์ (Relationship) ระหว่าง Entity ดังรายละเอียดต่อไปนี้ - ทางคณะ (Faculty) จะต้องเสนอเรื่อง (Offer) เพื่อขอเปิดวิชาเรียน (Course) - แต่ละรายวิชา (Course) จะต้องมีอาจารย์ (Teacher) เป็นผู้ทำการสอน (Teach) - ห้องเรียน (Room) เปิด (Open) ทำการเรียนการสอนทุกรายวิชา (Course) - รายวิชาใดๆ (Course) จะสามารถเปิดสอนได้ต้องมี (Have) นักเรียน (Student) ลงทะเบียน เรียนอย่างน้อย 20 คน Faculty Course Teacher Student Room Faculty Offer Course Course Teacher Teach Room Open Course

198 เมื่อนำทุกความสัมพันธ์ (Relationship) มาเชื่อมต่อกันทั้งหมดจะได้ดังภาพต่อไปนี้ ภาพที่ 7.14 ความสัมพันธ์ระหว่าง Entity กำหนดเงื่อนไข (Constraints) ของความสัมพันธ์ระหว่างเอ็นทิตี้ จากข้อมูลดังกล่าวและการสอบถามข้อมูลเพิ่มเติม สามารถกำหนดเงื่อนไขและนำมา กำหนดประเภทของความสัมพันธ์ (Relationship) ได้ดังนี้ 1) แต่ละคณะสามารถเสนอหัวหน้าหลักสูตรเพื่อขอเปิดสอนได้หลายวิชา แต่วิชา 1 วิชา จะต้องอยู่ในคณะเดียวเท่านั้น คือ ชื่อวิชาจะซ้ำกับคณะอื่นไม่ได้ 2) อาจารย์ 1 ท่าน สามารถสอนได้หลายวิชา และ 1 วิชาสามารถมีอาจารย์สอนได้หลาย ท่าน 3) ห้องเรียน 1 ห้องเรียนสามารถเปิดทำการเรียนการสอนได้หลายวิชา และ 1 วิชาก็ สามารถใช้ห้องเรียนหลายห้องเพื่อทำการเรียนการสอน 4) วิชา 1 วิชาสามารถเปิดได้จะต้องมีนักศึกษาลงทะเบียนอย่างน้อย 20 คนและนักศึกษา 1 คนสามารถมีวิชาเรียนได้หลายวิชา Course Student Have Faculty Offer Room Course Open Teacher Have Student Teach

199 จากเงื่อนไขข้างต้นสามารถแสดงความสัมพันธ์ได้ดังภาพต่อไปนี้ ภาพที่ 7.15 ประเภทของความสัมพันธ์ (Relationship) ที่กำหนดได้จากเงื่อนไขที่รวบรวมได้ กำหนดคุณสมบัติ (Attribute) ให้กับแต่ละเอ็นทีตี้ พร้อมทั้งกำหนดคีย์หลัก (Primary Key) หลังจากกำหนดความสัมพันธ์ให้กับ Entity ต่างๆ แล้ว ลำดับต่อไปคือกำหนด Attribute และ Primary Key ให้กับแต่ละ Entity ดังนี้ Faculty (FacId, FacName) โดยที่ FacId เป็น Primary Key Course (CourseId, CourseName) โดยที่ CourseId เป็น Primary Key Teacher (TeacherId, TeacherName) โดยที่ TeacherId เป็น Primary Key Student (StdId, StdSex, StdName) โดยที่ StdId เป็น Primary Key Room (RoomNo) โดยที่ Room_No เป็น Primary Key Faculty Offer Room Course Open Teacher Have Student Teach 1 M M N M N M N

200 ภาพที่ 7.16 E-R Diagram ที่ได้กำหนด Attribute และ Primary Key จากภาพที่ 7.15 E-R Diagram ที่กำหนด Relationship และประเภทของ Relationship แล้วนำมากำหนด Attribute ให้กับ Entity ต่างๆ ในระบบ พร้อมทั้งกำหนด Attribute ที่เป็น Primary Key เพื่อให้สามารถระบุค่าของ Attribute อื่นได้ ทำให้สามารถค้นหาข้อมูลได้ง่ายขึ้นดัง ภาพที่ 7.16 Faculty Offer Room Course Open Teacher Have Student Teach 1 M M N M N M N FacId FacName CourseId CourseName TeacherId TeacherName RoomNo StdId StdSex StdName

201 ใบงาน ให้นักศึกษาวิเคราะห์ระบบประเมินการสอนออนไลน์ต่อไปนี้ และเขียน ER Diagram และ Data Dictionary Standard Form : System Requirements Specification Brief Description: เมื่อนักศึกษาได้ล็อกอินเข้าสู่ระบบเครือข่าย LAN ภายในมหาวิทยาลัย โดยใส่ชื่อผุ้ใช้ รหัสผ่าน และระบุวิชาที่ต้องการประเมินเป็นที่เรียบร้อย ระบบจะแสดงแบบฟอร์ม ประเมินบนหน้าจอ เพื่อให้นักศึกษาประเมินการสอนของอาจารย์ที่สอนวิชานั้นๆ เมื่อ นักศึกษากรอกแบบประเมินเสร็จและยืนยันการส่งแบบประเมินแล้ว ระบบก็จะบันทึก ข้อมูลการประเมินลงในฐานข้อมูล ซึ่งสามารถนำข้อมูลดังกล่าวมาประมวลผลเพื่อแสดง รายงานผลการประเมินอาจารย์ให้กับทางคณะและให้กับอาจารย์ นอกจากนี้อาจารย์ยัง สามารถดูรายชื่อนักศึกษาที่เข้าร่วมประเมินจำแนกตามรายวิชาได้อีกด้วย Input: ข้อมูลนักศึกษา รหัสวิชา ข้อมูลการตอบแบบประเมิน Source: แบบฟอร์มการประเมินการสอนแบบออนไลน์ Output: วิชาที่ได้รับการประเมิน รายชื่อนักศึกษาที่ประเมิน คำตอบรับการประเมินเสร็จสมบูรณ์ รายงานผลการประเมิน Requires: วิชาที่นักศึกษาประเมินคือวิชาที่นักศึกษาได้ลงทะเบียนเรียนในภาคการศึกษานั้น Stakeholders: นักศึกษา อาจารย์ คณะ Precondition: นักศึกษาต้องมีการลงทะเบียนในภาคการศึกษานั้นๆ ให้เสร็จสมบูรณ์ก่อนและระบบถูก เปิดใช้บริการ Postcondition: รายวิชาที่ลงทะเบียนเรียนกับอาจารย์ประจำวิชาผู้นั้น ได้รับการประเมินแล้ว Main Flow: 1. นักศึกษาล็อกอินเข้าสู่ระบบ 2. ระบบร้องขอรหัสผ่าน 3. นักศึกษากรอกรหัสผ่าน 4. ระบบตรวจสอบรหัสผ่าน 5. นักศึกษาเลือกรหัสวิชาที่ต้องการประเมินและยืนยัน 6. ระบบจัดเตรียมแบบฟอร์มประเมิน 7. นักศึกษากรอกแบบประเมิน

202 Standard Form : System Requirements Specification 8. นักศึกษาส่งแบบประเมิน 9. ระบบบันทึกข้อมูล 10. นักศึกษาออกจากระบบ Exception Condition: 4.1 กรณีรหัสผ่านได้รับการตรวจสอบแล้วไม่ถูกต้อง นักศึกษาจะไม่สามารถเข้าสู่ระบบได้ 5.1 กรณีรหัสวิชาที่นักศึกษาเลือก ถูกตรวจสอบพบว่าเป็นรายวิชาที่ได้รับการประเมินแล้ว ระบบจะไม่อนุญาตให้ประเมินซ้ำ

203 แบบฝึกหัด 1. แบบจำลองข้อมูลสามารถนำมาใช้อธิบายอะไร 2. จงอธิบายวัตถุประสงค์ของแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity Relationship Diagram: E-R Diagram) 3. แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล ประกอบด้วยองค์ประกอบใดบ้าง 4. ความสัมพันธ์ระหว่าง Entity บนแผนภาพ E-R Diagram มีรูปแบบใดบ้าง 5. พนักงานเป็นคณบดีได้อย่างมากหนึ่งคณะ และคณะหนึ่งคณะสามารถมีคณบดีได้อย่างมาก หนึ่งคน เป็นความสัมพันธ์ในรูปแบบใด 6. นักศึกษาแต่ละคนสามารถลงทะเบียนเรียนได้หลายวิชา และวิชาแต่ละวิชามีนักศึกษา ลงทะเบียนได้หลายคน เป็นความสัมพันธ์ในรูปแบบใด 7. ในการตรวจสอบความสมดุลระหว่างแผนภาพอีอาร์กับแผนภาพกระแสข้อมูล มีวิธีการ ตรวจสอบอย่างไร 8. พจนานุกรมคืออะไร นำมาใช้ประโยชน์อย่างไร 9. คีย์หลัก (Primary Key: PK) และคีย์นอก (Foreign Key: FK) ที่ระบุไว้ในพจนานุกรมข้อมูล มีไว้เพื่ออะไร 10. จงอธิบายวิธีการสร้างแผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล

204 เฉลยแบบฝึกหัด 1. แบบจำลองข้อมูลเป็นเทคนิคหนึ่ง ที่นำมาใช้อธิบายโครงสร้างและความสัมพันธ์ระหว่าง ข้อมูลในระบบธุรกิจ ว่าข้อมูลเหล่านั้นมีความสัมพันธ์กันอย่างไร 2. แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูลถูกสร้างขึ้นมาเพื่อใช้เป็นแบบจำลองข้อมูลใน การออกแบบฐานข้อมูล และใช้อธิบายความสัมพันธ์ระหว่างข้อมูล ซึ่งจะถูกสร้างขึ้นมาพร้อมๆ กับ ขั้นตอนการวิเคราะห์ความต้องการ ที่ได้มาจากการเข้าไปสืบเสาะ ค้นหาข้อเท็จจริง เพื่อให้ได้ความ ต้องการของผู้ใช้ 3. แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล ประกอบด้วยองค์ประกอบดังนี้ - เอ็นทิตี้ (Entity) หมายถึง สิ่งของหรือวัตถุที่เกี่ยวข้องกับความต้องการทางธุรกิจที่ นำมาใช้จัดเก็บข้อมูล เช่น เอ็นทิตี้ชื่อ CUSTOMER ที่ใช้แทนลูกค้า เอ็นทิตี้ STUDENT ที่ใช้แทน นักเรียน เป็นต้น - คุณลักษณะ (Attributes) หมายถึงคุณลักษณะเฉพาะของแต่ละเอ็นทิตี้ เช่น เอ็นทิตี้ ลูกค้า (CUSTOMER) ประกอบด้วยคุณลักษณะ ดังนี้ รหัสลูกค้า (custID) ชื่อลูกค้า (custName) นามสกุลลูกค้า (custSurname) วันเกิดลูกค้า (birthDate) เพศลูกค้า (custGender) ที่อยู่ลูกค้า (custAddress) โทรศัพท์ลูกค้า (custTel) เป็นต้น - ความสัมพันธ์ (Relationships) หมายถึง ความสัมพันธ์ระหว่าเอ็นทิตี้ ซึ่งแต่ละเอ็นทิตี้ จะต้องมีความสัมพันธ์ระหว่างกันเสมอ ความสัมพันธ์แต่ละความสัมพันธ์จะถูกระบุด้วยชื่อที่ใช้ อธิบายความสัมพันธ์นั้นๆ การตั้งชื่อความสัมพันธ์โดยทั่วไปจะใช้คำกริยาที่แสดงการกระทำ เช่น สอน สั่งซื้อ ว่าจ้าง เป็นต้น 4. ความสัมพันธ์ระหว่าง Entity บนแผนภาพ E-R Diagram มี3 แบบ คือ ความสัมพันธ์แบบ หนึ่งต่อหนึ่ง (1:1) ความสัมพันธ์แบบหนึ่งต่อกลุ่ม (1:M) และความสัมพันธ์แบบกลุ่มต่อกลุ่ม (M:N) 5. ความสัมพันธ์แบบหนึ่งต่อหนึ่ง (1:1) 6. ความสัมพันธ์แบบกลุ่มต่อกลุ่ม (M:N) 7. วิธีการตรวจสอบความสมดุลระหว่างแผนภาพอีอาร์กับแผนภาพกระแสข้อมูลให้พิจารณา จากจำนวนดาต้าสโตว์ที่ปรากฎอยู่ในไดอะแกรม 0 จะต้องมีจำนวนเท่ากับเอ็นทิตี้ในแผนภาพอีอาร์ ตัวอย่างเช่นในไดอะแกรม 0 ประกอบไปด้วยดาต้าสโตว์จำนวน 8 ดาต้าสโตว์ คือตั้งแต่ D1 จนถึง D8 ดังนั้นเมื่อสร้างแผนภาพอีอาร์ที่มีความสมดุลกับไดอะแกรม 0 จะต้องประกอบไปด้วยเอ็นทิตี้ เท่ากับจำนวนดาต้าสโตว์ที่ปรากฎในไดอะแกรม 0 คือเท่ากับ 8 เอ็นทิตี้

205 8. พจนานุกรมข้อมูล เป็น การรวบรวมรายละเอียดข้อมูลอย่างเป็นหมวดหมู่เพื่อให้ผู้ที่ เกี่ยวข้อง เช่น ผู้บริหารข้อมูล โปรแกรมเมอร์ หรือผู้ที่ต้องการสื่อสารการทำงานของระบบเกิดความ เข้าใจความหมายของข้อมูลได้อย่างถูกต้องตรงกัน 9. คีย์หลัก มีไว้เพื่อแสดงถึงความไม่ซ้ำกันของข้อมูลที่อยู่ในเอ็นทิตี้ คีย์นอก มีเพื่อใช้ในการ อ้างอิงถึงคีย์หลักของอีกเอ็นทิตี้หนึ่ง เพื่อเป็นการสร้างความสัมพันธ์ 10. 1) กำหนดเอ็นทิตี้ทั้งหมดของระบบ 3) สร้างความสัมพันธ์ระหว่างเอ็นทิตี้ 4) กำหนดเงื่อนไขของความสัมพันธ์ระหว่างเอ็นทิตี้ 5) กำหนดคุณสมบัติให้กับแต่ละเอ็นทีตี้ พร้อมทั้งกำหนดคีย์หลัก

หน่วยที่ 4 การออกแบบและพัฒนาระบบ 4.1 การออกแบบระบบสารสนเทศตามแนวทางเชิงวัตถุ การออกแบบระบบสารสนเทศตามแนวทางเชิงวัตถุ จะพิจารณาสิ่งต่างๆ ภายในระบบเป็นวัตถุ (Object) ด้วยการมองวัตถุ (Object) เป็นแหล่งรวมของกระบวนการและข้อมูล ซึ่งแตกต่างจาก วิธีการวิเคราะห์และออกแบบระบบเชิงโครงสร้าง (Structural) ที่เน้นที่กระบวนการเป็นหลัก เนื่องจากกระบวนการจะนำไปสู่การเปลี่ยนแปลงข้อมูลให้กลายเป็นสารสนเทศ ประกอบกับ กระบวนการกับข้อมูลจะแยกออกจากกัน ปัญหาที่พบบ่อยในการพัฒนาระบบด้วยวิธีเชิงโครงสร้างก็ คือ แบบจำลองต่างๆ ที่สร้างขึ้น ไม่ว่าจะเป็นแผนภาพกระแสข้อมูล หรือแผนภาพอีอาร์ ต่างก็ไม่ได้ เชื่อมต่อไปถึงรายละเอียดการพัฒนาระบบ หรือวิธีการเขียนโปรแกรมแต่อย่างใด เพียงแต่นำเสนอ ให้เห็นว่าระบบมีลักษณะการทำงานอย่างไรเท่านั้น การออกแบบระบบเชิงวัตถุเป็นการอธิบายถึงระบบสารสนเทศ โดยการกำหนดสิ่งต่างๆ ภายในระบบให้เป็นวัตถุ (object) ซึ่งวัตถุอาจเป็นสิ่งที่มองเห็นและจับต้องได้ หรืออาจเป็นสิ่งที่มีอยู่ จริงแต่ไม่สามารถจับต้องได้ โดยมีคลาส (class) เป็นตัวกำหนดคุณสมบัติของวัตถุ วัตถุประกอบด้วย คุณลักษณะหรือแอตทริบิวต์ (attribute) ของวัตถุ และเมธอด (method) หรือโอเปอเรชั่น (operation) ซึ่งเป็นกิจกรรมหรืองานที่วัตถุสามารถกระทำหรือถูกกระทำได้ กล่าวคือ วัตถุนั้นจะ สามารถทำอะไรหรือทำอย่างไรได้บ้าง และวัตถุจะแสดงกิจกรรมอย่างใดอย่างหนึ่งได้ต้องมีการ ติดต่อสื่อสารหรือส่งข่าวสาร (message) ซึ่งเป็นคำสั่งที่บอกให้วัตถุแสดงกิจกรรมนั้นๆ ได้ การวิเคราะห์และออกแบบระบบเชิงโครงสร้างใช้แผนภาพกระแสข้อมูล (Data Flow Diagram: DFD) สำหรับการแสดงแบบจำลองกระบวนการ ส่วนการวิเคราะห์และออกแบบระบบ เชิงวัตถุเป็นการสร้างแบบจำลองของวัตถุและคลาส และองค์ประกอบอื่นๆ ของระบบสารสนเทศ โดยใช้แผนภาพภาษายูเอ็มแอล (Unified Modeling Language: UML) ชนิดต่างๆ อธิบาย ระบบงาน และต่อไปนี้เป็นรายละเอียดพื้นฐานที่เราต้องเรียนรู้เกี่ยวกับเทคโนโลยีเชิงวัตถุ อัน ประกอบด้วย วัตถุ คลาส การสืบทอดคุณสมบัติโพลิมอร์ฟิซึม เอนแคปซูเลชัน และความสัมพันธ์ ของวัตถุและการมีส่วนร่วม และแผนภาพในภาษา UML 4.1.1 วัตถุและคลาส (Object and Class) ในโลกความจริง และในชีวิตประจำวันเมื่อมองดูรอบตัว มักจะพบกับวัตถุ (Objects) ต่างๆ มากมาย ไม่ว่าจะเป็นวัตถุที่สามารถมองเห็นได้และจับต้องได้ เช่น คน โต๊ะ รถยนต์ คอมพิวเตอร์ เป็นต้น และวัตถุที่มีอยู่จริงแต่ไม่สามารถจับต้องได้ เช่น กฎหมาย เวลา หรือความรู้ต่างๆ เป็นต้น โดย Objects จะมีข้อมูลที่ใช้บ่งบอกถึงความเป็นตัวตน และยังสามารถแสดงพฤติกรรมของตัวเอง ออกมาให้เห็นได้ในขณะเดียวกัน ตัวอย่างเช่น รถยนต์ซึ่งจัดเป็น Object หนึ่ง โดยรถยนต์แต่ละคัน

207 ก็จะมีข้อมูลหรือคุณลักษณะของตัวเองที่แตกต่างกันได้ เช่น รถยนต์คันนั้นเป็นสีขาว เปิดประทุน หรือรถยนต์คันนั้นเป็นสีแดง มีหลังคา ส่วนพฤติกรรมของรถยนต์ก็คือ การวิ่งเคลื่นที่ การเลี้ยว และ การหยุด เป็นต้น สำหรับวัตถุ (Objects) ในโลกของเทคโนโลยีเชิงวัตถุ จะเน้นที่ “ตัวปฏิบัติการ” มากกว่า “การปฏิบัติ” ตัวอย่าง เช่น สมยศต้องการส่งพัสดุให้ถึงมือเพื่อนชื่อสมควร สมยศก็ต้องเดินทางไปยัง ที่ทำการไปรษณีย์ จากนั้นก็จะสื่อสาร (Message) กับเจ้าหน้าที่ว่า ต้องการส่งพัสดุชิ้นนี้ไปยัง ปลายทางคือประเทศจีน และได้จ่าหน้าซอง ชำระค่าธรรมเนียม ซึ่งถือว่าเสร็จสิ้นกระบวนการ โดย สมยศไม่ต้องไปกังวลเลยว่ากรรมวิธีในการจัดส่งพัสดุจะต้องดำเนินการอย่างไร สมยศสนใจเพียงแต่ ต้องการให้พัสดุชิ้นนั้นส่งถึงมือเพื่อนเท่านั้น โดยที่ทำการไปรษณีย์ซึ่งถือเป็น Object ได้จัดตัว ปฏิบัติการต่างๆ เอาไว้ เพื่อรับผิดชอบ (Responsibility) ต่อหน้าที่ ด้วยการจัดส่งพัสดุให้ถึงผู้รับ ตามสถานที่ที่ได้จ่าหน้าซองไว้อย่างเรียบร้อย ดังนั้นจึงสรุปได้ว่า วัตถุ (Objects) จะมีคุณสมบัติ (Attributes) ที่ใช้อธิบายถึงลักษณะของ Objects นั้นๆ รวมถึง วิธีการ (Method) ซึ่งจะปฏิบัติตามหรือตอบสนองต่อ ข้อความ (Message) ที่ร้องขอเข้ามา เช่น รถยนต์ได้เตรียมวิธีการ “ขับ (Drive)” เอาไว้ เพื่อส่ง Message ไปยังระบบ ขับเคลื่อน เพื่อขับเคลื่อนรถยนต์ให้เคลื่อนที่ไปข้างหน้า หรือที่ทำการไปรษณีย์ ได้เตรียมวิธีการส่ง สินค้า เพื่อส่ง Message ไปยังระบบการขนส่ง เพื่อจัดส่งพัสดุไปยังปลายทาง เป็นต้น คลาสกับวัตถุมีความหมายคล้ายกันมาก แต่คลาส (Class) เป็นนามธรรม (Abstract) ในขณะ ที่ วัตถุ (Objects) เป็นสิ่งที่มีตัวตน (Concrete) กล่าวคือ คลาสก็คือตัวแบบ (Template) ของวัตถุ โดยที่คลาสไม่สามารถทำงานได้ ในขณะที่วัตถุสามารถทำงานได้ การทำงานของวัตถุจะเป็นไปตาม คุณสมบัติที่กำหนดไว้ในคลาส และวัตถุทุกตัวก็จะต้องอยู่ในคลาสซึ่งคลาสกับวัตถุจะเป็นสิ่งที่คู่กัน เสมอ โดยเราสามารถดูคุณสมบัติของวัตถุได้ด้วยการดูที่คลาส นอกจากนี้คลาสยังสามารถนำมาใช้ จัดกลุ่มวัตถุต่างๆ ที่มีโครงสร้างพื้นฐานพฤติกรรมเดียวกัน มาอยู่รวมกลุ่มภายใต้คลาสเดียวกันได้ ดังนั้นวัตถุใดๆ ก็ตามที่มีคุณสมบัติเป็นไปในลักษณะเดียวกัน ก็จะถูกรวมกลุ่มเข้าด้วยกันภายใน คลาสนั้นๆ ในขณะเดียวกันวัตถุทุกตัวที่อยู่ภายใต้คลาสดังกล่าว ก็จะได้รับคุณสมบัติต่างๆ ตาม คลาสเหล่านั้น จึงสรุปได้ว่าคลาสก็คือตัวแบบข้อมูลที่มีไว้เพื่อสร้างวัตถุนั่นเอง ยกตัวอย่างเช่น มี คลาสชื่อ “Student” และมี Object สุดาและสมชาย อยู่ภายใต้คลาส Student นั่นหมายความว่า ทั้งสุดา และสมชายต่างก็เป็นนักศึกษาที่มีคุณสมบัติตามที่ระบุไว้ในคลาส Student องค์ประกอบในคลาสจะประกอบด้วย ชื่อคลาส คุณลักษณะของคลาส (Attribute) และ วิธีการ (Method/Operation) ที่ใช้อธิบายพฤติกรรมของคลาสว่ามีตัวปฏิบัติการอะไรบ้าง โดยตัว แบบของคลาส คุณลักษณะ และวิธีการ แสดงดังภาพต่อไปนี้

208 ภาพที่ 8.1 ตัวแบบของคลาส (Class Template) ภาพที่ 8.2 ตัวอย่างคลาส Student พร้อมรายละเอียด จากภาพที่ 8.2 เป็นคลาส Student ซึ่งประกอบด้วยคุณลักษณะ (Attribute) ต่างๆ เช่น เลข ประจำตัว ชื่อ ที่อยู่ หมายเลขโทรศัพท์ สาขาวิชา วันที่เกิด เกรดเฉลี่ยสะสม โดยที่คลาส Student จะมีOperation ต่างๆ ได้แก่ การลงทะเบียนเรียน การหยุดการเรียน (Drop) การเปลี่ยนแปลงที่อยู่ และเบอร์โทรศัพท์ และการร้องขอทรานสคริปต์ เป็นต้น 4.1.2 การสืบทอดคุณสมบัติ (Inheritance) การกำหนดคุณสมบัติให้กับวัตถุแต่ละตัวในระบบ จะใช้วิธีการสืบทอด (Inheritance) โดย อาศัยคุณสมบัติของวัตถุที่มีอยู่แล้วใส่ลงในวัตถุตัวใหม่ ยกตัวอย่างเช่น “สัตว์” เป็นวัตถุหนึ่งที่มี คุณสมบัติเฉพาะตัว เมื่อต้องการกำหนดคุณสมบัติของ “แมว” ซึ่ง “แมว” จัดเป็นสัตว์ชนิดหนึ่ง ดังนั้น “แมว” จึงถูกถ่ายทอดคุณสมบัติมาจาก “สัตว์” จึงไม่จำเป็นต้องกำหนดคุณสมบัติพื้นฐาน ของ “แมว” อีกต่อไปเพราะได้ถูกถ่ายทอดคุณสมบัติมาจาก “สัตว์” เป็นที่เรียบร้อยแล้ว แต่ “แมว” ก็อาจมีคุณสมบัติเฉพาะตัวได้ เช่น เสียงร้อง หรือคุณสมบัติที่อ้อนเก่ง เป็นต้น ส่วน “สุนัข” ก็คือ สัตว์ชนิดหนึ่งที่ถูกถ่ายทอดคุณสมบัติมาจาก “สัตว์” เช่นกันซึ่งคุณสมบัติเฉพาะตัวของ “สุนัข” ก็

209 แตกต่างจาก “แมว” หลักการนี้ถือว่าเป็นหลักแห่งความเป็นจริงบนโลก ดังนั้นแนวความคิดเชิงวัตถุ จะถือว่าการสืบทอดเป็นสิ่งสำคัญ เพราะว่าไม่มีสิ่งใดในโลกที่เกิดขึ้นเอง ต้องมีการสืบทอด ภาพที่ 8. 3 การสืบทอดคุณสมบัติ (Inheritance) การสืบทอดคุณสมบัติ (Inheritance) เป็นการสืบทอดคุณสมบัติ(Attributes) ที่ Classๆ หนึ่ง ที่เรียกว่าคลาสลูก (Subclass) สามารถสืบทอดคุณสมบัติ(Attributes) และวิธีการ (Method/Operation) ของอีก Class หนึ่ง ที่เรียกว่าคลาสแม่ (Superclass) ได้ และ Class ใหม่ นั้นสามารถเพิ่มคุณสมบัติ(Attributes) และวิธีการ (Method/Operation) ใหม่ได้ ภาพที่ 8.4 ตัวอย่างการสืบทอดคุณสมบัติ (Inheritance) ของ Car จากภาพที่ 8.4 ได้มีการเพิ่มคุณสมบัติ (Attributes) และวิธีการ (Method) ของ Superclass “รถยนต์ (Car)” โดยกำหนดให้มีคุณสมบัติ (Attribute) “model (รุ่นของรถยนต์)” และ “engineSize (ขนาดของเครื่องยนต์)” และกำหนดให้มีวิธีการ (Method) “run (วิ่ง)” และมีการ

210 เพิ่มคุณสมบัติ (Attribute) “ขนาดของอุปกรณ์ Turbo (turboSize)” ให้กับ Superclass “Car” เพื่อให้เกิดเป็น Subclass “SportCar” ขึ้น ภาพที่ 8.5 ตัวอย่างการสืบทอดคุณสมบัติ (Inheritance) ของ Animal จากภาพที่ 8.5 ได้มีการเพิ่มคุณสมบัติ (Attributes) และวิธีการ (Method) ของ Superclass “สัตว์(Animal)” โดยกำหนดให้มีคุณสมบัติ (Attribute) “animalType (ประเภทของสัตว์)” และ วิธีการ (Method) “eat (กินอาหาร)” และมีการเพิ่มวิธีการ (Method) “วิ่ง (run)” ให้กับ Superclass “Animal” เพื่อก่อให้เกิด Subclass ใหม่คือ “สัตว์บก (LandAnimal)” และเพิ่ม Method “ดำน้ำ (dive)” ให้กับ Superclass “Animal” เพื่อก่อให้เกิด Subclass ใหม่คือ “สัตว์ น้ำ (SeaAnimal)” ขึ้น หลักการสืบทอดคุณสมบัติจะทำให้ความสัมพันธ์ระหว่างวัตถุ (Objects) มีความชัดเจนยิ่งขึ้น และถ้ามีความสัมพันธ์ที่ชัดเจนมากขึ้นเท่าใด ก็ส่งผลต่อนักพัฒนาสามารถออกแบบระบบงานง่ายขึ้น รวมถึงการรองรับระบบงานขนาดใหญ่ได้ ด้วยการอาศัยวัตถุที่มีการนิยามไว้ก่อน ซึ่งอาจเป็นวัตถุที่มี ผู้อื่นทำการออกแบบมาก่อนแล้ว ซึ่งเราเรียกว่า การนำกลับมาใช้ใหม่ (Reusable) 4.1.3 โพลิมอร์ฟิซึม (Polymorphism) โพลิมอร์ฟิซึม (Polymorphism) คือ การที่เราสามารถเขียนเมธอด (Method) ชื่อเดียวกัน ให้สามารถรับพารามิเตอร์ (Parameter) ได้หลายชนิด และการเขียนเมธอดชื่อเดียวกับคลาสที่สืบ ทอดมา แต่ทำงานคนละอย่างกัน โดยความหมายแล้ว poly แปลว่าหลายหรือมาก ส่วนคำว่า morphism นั้นมาจากคำว่า morph ซึ่งแปลว่ารูปร่าง เมื่อนำสองคำมารวมกันจะมีความหมายคือ การที่วัตถุสามารถมีรูปร่างได้หลากหลาย รากฐานของการพ้องรูป (Polymorphism) ก็คือ การ ถ่ายทอดคุณสมบัติ เพราะถ้าไม่มีการถ่ายทอดคุณสมบัติก็จะไม่เกิดสภาวะการพ้องรูป การถ่ายทอด

211 คุณสมบัติเป็นเครื่องมือยืนยันได้ว่าคลาสลูก (Subclass) ที่เกิดจากคลาสแม่ (Superclass) เดียวกัน ย่อมมีคุณสมบัติเหมือนกัน หลักการของโพลิมอร์ฟิซึมก็คือ การออกแบบครั้งเดียว แต่ได้รับการตอบสนองหลายรูปแบบ คือเมธอด (Method) เดียวกัน แต่สามารถตอบสนองวิธีการที่ไม่เหมือนกันได้ ตัวอย่างเช่น ฟังก์ชัน draw() เป็นฟังก์ชันเกี่ยวกับการวาดรูป และโดยปกติ การวาดนั้น ผู้วาดสามารถวาดได้หลายรูปแบบ เช่น วาดวงกลม สี่เหลี่ยม วงรี เป็นต้น และด้วยคุณสมบัติของโพลิมอร์ฟิซึมนี้เอง ทำให้ผู้ใช้สามารถ ใช้งานฟังก์ชัน draw() เพียงฟังก์ชันเดียวในการวาดรูปต่างๆ เหล่านั้นได้ โดยการตอบสนองว่าจะ วาดเป็นรูปใดนั้นเป็นเรื่องของรายละเอียด ดังนั้นผู้ใช้ไม่จำเป็นต้องจดจำฟังก์ชันการวาดรูปต่างๆ มากมาย ซึ่งแตกต่างจากการเขียนโปรแกรมแบบเดิมที่จำเป็นต้องสร้างฟังก์ชันการวาดหลายๆ รูปแบบมาให้เลือกใช้งาน เช่น ฟังก์ชันวาดรูปวงกลม ฟังก์ชันวาดรูปสี่เหลี่ยม ฟังก์ชันวาดรูปวงรี เป็นต้น และด้วยหลักการของโพลิมอร์ฟิซึมนี้เอง จึงช่วยลดความยุ่งยากในการจดจำคำสั่ง และลด คำสั่งลงได้มาก อีกทั้งยังช่วยให้เกิดการนำชุดคำสั่งกลับมาใช้ใหม่ (Reuse) โดยสามารถกำหนด ชุดคำสั่งแบบทั่วไป และมอบหมายหน้าที่ด้านรายละเอียดของการนำไปใช้ให้กับวัตถุ (Object) ที่ เกี่ยวข้องนำไปจัดการเอง โพลิมอร์ฟิซึม มีความเกี่ยวข้องกับกลไกของการสืบทอด (Inheritance) คือ Subclass ที่ ได้รับการสืบทอดมาจาก Superclass นอกจากจะได้รับการถ่ายทอดคุณสมบัติและพฤติกรรมมา จาก Superclass แล้วก็ตาม แต่ Subclass แต่ละตัวก็สามารถมีคุณสมบัติเฉพาะของตนได้ ใน ขณะเดียวกันก็มีความเป็นอิสระต่อการตอบสนองที่แตกต่างกันได้เช่นกัน เมื่อมีเมสเสจ (Message) ที่เหมือนๆ กันได้ร้องขอเข้ามายังวัตถุ (Object) ในแต่ละ Subclass พิจารณาจากตัวอย่างต่อไปนี้ เช่น หากต้องการอธิบายความสัมพันธ์ระหว่างยานพาหนะ (Vehicle) กับรถเกรดตีนตะขาบ (Bulldozer) จะอธิบายได้ว่า BullDozer เป็นประเภทหนึ่งของ Vehicle (Vehicle ถ่ายทอดคุณสมบัติต่างๆ ให้กับ BullDozer) ซึ่งถ้า Vehicle มี Method สำหรับ การเดินหน้า (goForward) ถอยหลัง (goBackward) เลี้ยวซ้าย (turnLeft) และเลี้ยวขวา (turnRight) แล้ว BullDozer ก็จะมี Method เหล่านี้ด้วย ดังรูปต่อไปนี้

212 ภาพที่ 8.6 โพลิมอร์ฟิซึม (Polymorphism) ของ Vehicle อย่างไรก็ตาม สำหรับการเลี้ยวซ้าย เลี้ยวขวาของ Vehicle ทั่วไป จะใช้พวงมาลัยเป็นตัว บังคับ แตกต่างจากรถเกรดตีนตะขาบ (Bulldozer) ซึ่งใช้วิธีการหยุดล้อข้างที่จะเลี้ยว เพื่อให้ล้อนั้น ทำหน้าที่เป็นจุดสำหรับการหมุนเลี้ยว (แบบวงเวียน) ซึ่งนั่นหมายความว่า Method “turnLeft” และ “turnRight” ของ Bulldozer จะต้องมีกลไกการทำงานที่แตกต่างจาก Method “turnLeft” และ “turnRight” ของ Vehicle ถึงแม้จะเป็น Method ที่ถูกถ่ายทอดมาจาก Vehicle ก็ตาม ซึ่ง การที่ Superclass ยินยอมให้ Subclass ดำเนินการแก้ไขดัดแปลง Method ที่ได้รับถ่ายทอดไป จากตนเองนี้ เรียกว่า โพลิมอร์ฟิซึม โดยในรูปที่ 8.7 จะแสดงถึง Method การเลี้ยวซ้ายและเลี้ยว ขวาของ Vehicle จะเลี้ยวโดยการใช้พวงมาลัย แต่ Method การเลี้ยวซ้ายและเลี้ยวขวาของ Bulldozer จะเลี้ยวโดยการหยุดล้อ ภาพที่ 8.7 แสดง Internal View ของ Vehicle และ Bulldozer อีกตัวอย่างของโพลิมอร์ฟิซึม คือ รีโมทคอนโทรลที่ทำงานกับเครื่องรับโทรทัศน์ (TVRemoteControl) และเครื่องเล่นวิทยุ (RadioRemoteControl) ในส่วนของปุ่มลดหรือเพิ่ม

213 ระดับเสียง ซึ่งมีในรีโมทคอนโทรลของเครื่องเล่นทั้งสองประเภทนั้น แม้จะทำหน้าที่เหมือนกันคือ ปรับระดับเสียง แต่กลไกการทำงานภายในเพื่อควบคุมระดับเสียงของเครื่องเล่นต่างประเภทกันย่อม แตกต่างกัน ภาพที่ 8.8 โพลิมอร์ฟิซึม (Polymorphism) ของ RemoteControl 4.1.4 เอนแคปซูเลชัน เอนแคปซูเลชัน (Encapsulation and Information Hiding) เป็นหนึ่งในคุณสมบัติของ วัตถุ (Object) โดย Object ใดๆ ก็ตามสามารถที่จะปกปิด ซ่อนรายละเอียดภายในของตนได้ไม่ว่า จะเป็น Attribute และ Method เพื่อป้องกันการเข้าถึง นั่นหมายความว่า การที่ Object ใดๆ ต้องการเข้าถึงเพื่อสื่อสารกับ Object อื่นๆ จะต้องมีการตอบรับจาก Method ของ Object ปลายทางก่อนว่าจะอนุญาตให้ Object ที่ส่ง Message ร้องขอเข้ามานั้น เข้าถึงข้อมูลตนได้หรือไม่ ตัวอย่างเช่นในภาษา C++ ที่มีคุณสมบัติ Encapsulation ด้วยการเตรียมกลไกป้องกันข้อมูลและ ฟังก์ชันที่ประกอบด้วย Public, Private และ Protected โดยข้อมูลหรือฟังก์ชันที่ถูกกำหนดเป็น Public จะเป็นการเปิดแบบสาธารณะเพื่อให้ Object ใดๆ สามารถเข้าถึงได้โดยตรงจากภายนอก ส่วนข้อมูลหรือฟังก์ชันที่เป็น Private จะถูกสงวนไว้ใช้งานภายในคลาสเท่านั้น ส่วน Protected จะ ไม่สามารถเห็นได้จากภายนอกและจะมองเห็นหรือเข้าถึงได้เฉพาะภายใน Subclass เท่านั้น ใน UML การกำหนดให้การมองเห็น (Visibility) ของ Attribute หรือ Method ว่าเป็น Public, Protected หรือ Private จะใช้สัญลักษณ์ดังนี้ + คือสัญลักษณ์ Public Visibility # คือสัญลักษณ์ Protected Visibility - คือสัญลักษณ์ Private Visibility

214 4.1.5 ความสัมพันธ์ของวัตถุและการมีส่วนร่วม ความสัมพันธ์ของวัตถุและการมีส่วนร่วม (Object Relationship and Associations) ประกอบด้วยความสัมพันธ์ดังนี้ 1) Association จะแสดงความสัมพันธ์ระหว่าง Objects และ Classes ในลักษณะที่เป็น ความสัมพันธ์ที่อยู่บนระนาบเดียวกัน ซึ่งหมายความว่าสิ่งของทั้งสองสิ่งที่มีความสัมพันธ์กันเป็นสิ่งที่ มีความสำคัญเท่าเทียมกัน ไม่ใช่องค์ประกอบกัน ยกตัวอย่าง เช่น “คนเป็นเจ้าของรถยนต์”, “สมาชิกยืมหนังสือ” หรือ “พนักงานทำงานในบริษัท” เป็นต้น เมื่อ Class สอง Class มีความสัมพันธ์แบบ Association ต่อกันแล้ว Association นั้นต้อง เป็น Association ที่สามารถอธิบายได้ โดยสามารถอธิบาย Association แต่ละตัวได้ด้วยชื่อของ Association (Association Name) เช่น ในความสัมพันธ์พนักงานทำงานในบริษัท พนักงานและ บริษัท ถูกเชื่อมความสัมพันธ์ด้วย Association ที่ชื่อว่า “ทำงานใน (works in)” เป็นต้น แต่การ อาศัย Association Name เพียงอย่างเดียวในการอธิบายความสัมพันธ์ อาจทำให้เข้าใจผิดเนื่องจาก อ่านผิดด้าน เช่น อ่านว่า “บริษัท ทำงานใน พนักงาน” ซึ่งไม่ถูกต้อง ดังนั้น ในการอธิบาย Association ควรกำหนดทิศทางของ Association (Association Direction) ด้วยเสมอ นั่นคือ ต้องระบุว่า พนักงานและบริษัท ถูกเชื่อมความสัมพันธ์ด้วย Association ที่ชื่อว่า “ทำงานใน (work in)” โดยมีทิศทางของความสัมพันธ์จาก “พนักงาน” ไปยัง “บริษัท” ในการพิจารณา Association ระหว่าง Class สิ่งที่ต้องคำนึงถึง คือ ค่าที่เป็นไปได้ของจำนวน สมาชิกใน Class หนึ่งๆ ที่มีส่วนร่วมใน Association นั้น ซึ่งจะเรียกค่าของจำนวนสมาชิกของ Class ที่เป็นไปได้ใน Association นั้นว่า “Multiplicity” โดยจะเรียกจำนวนที่น้อยที่สุดของสมาชิก ของ Class ที่มีส่วนร่วมใน Association ว่า “Minimum Multiplicity (Min-card)” และเรียก จำนวนที่มากที่สุดของสมาชิกของ Class ที่มีส่วนร่วมใน Association ว่า “Maximum Multiplicity (Max-card)” ตัวอย่างที่ สมมติว่าจากการสอบถามเพื่อหาความสัมพันธ์ของ Class ในระบบห้องสมุด ประชาชน พบว่า 1. สมาชิกของห้องสมุดประชาชน (Member) มีบัตรสมาชิก (Member Card) ได้หนึ่งใบ 2. การยืมหนังสือ (Book) แต่ละครั้งสมาชิกสามารถยืมได้อย่างน้อย 1 เล่มอย่างมาก 5 เล่ม 3. หนังสือบางเล่ม (โดยเฉพาะหนังสือเกี่ยวกับคอมพิวเตอร์) จะมีแผ่น CD (Compact Disk) เพื่อศึกษาคู่กับหนังสือเล่มนั้นๆ โดยแผ่น CD จะถูกแยกเก็บไว้ที่บรรณารักษ์ ซึ่งสมาชิก สามารถขอยืมเพื่อนำไปประกอบการค้นคว้าได้โดยแผ่น CD ที่มากับหนังสือจะมีจำนวนเท่าใดก็ได้ ขึ้นอยู่กับความจำเป็น

215 4. สมาชิกของห้องสมุด สามารถแจ้งความจำนงขอให้ห้องสมุดจัดหาสื่อวิชาการต่างๆ (Media) ที่ต้องการได้ เช่น คลิปวิดีโอ สไลด์ เป็นต้น โดยสมาชิกหนึ่งคนสามารถแจ้งความจำนงได้ มากกว่าหนึ่งรายการ และเป็นไปได้ว่าสื่อหนึ่งรายการอาจถูกแจ้งความจำนงโดยสมาชิกมากกว่าหนึ่ง คน จากความต้องการ (Requirements) ทั้ง 4 ข้อ สามารถสรุป Association และ Multiplicity ได้ดังนี้ 1. Association ระหว่าง Member และ MemberCard Association Name Association Direction Member MemberCard Multiplicity Multiplicity Min Max Min Max มี (has) Member→MemberCard 1 1 1 1 2. Association ระหว่าง Member และ Book Association Name Association Direction Member Book Multiplicity Multiplicity Min Max Min Max ยืม (borrows) Member→Book 1 1 1 5 3. Association ระหว่าง Book และ CompactDisk Association Name Association Direction Book CompactDisk Multiplicity Multiplicity Min Max Min Max ใช้ร่วมกับ (used with) CompactDisk → Book 1 1 0 n 4. Association ระหว่าง Media และ Member Association Name Association Direction Member Media Multiplicity Multiplicity Min Max Min Max ลงทะเบียน (Register) Member→Media 1 1 0 n หากพิจารณาจาก Max-card ของ Class ที่มีส่วนร่วมใน Association จะสามารถแบ่ง

216 ประเภทของความสัมพันธ์ใน Association ได้เป็น 3 ประเภท ดังนี้ 1. One-to-one Association (1:1) ค ื อ Association ท ี ่ Class ท ั ้ ง ส อ ง ข ้ า ง ข อ ง Association มี Max-card เป็น 1 ทั้งคู่ 2. One-to-many Association (1:M) ค ื อ Association ที่ Class ข ้ า ง ห น ึ ่ ง ข อ ง Association มี Max-card เป็น 1 ส่วน Class อีกข้างหนึ่ง มี Max-card ที่มีค่ามากกว่า 1 3. Many-to-many Association (M:N) คือ Association ที่ Class ทั้งสองข้างของ Association มี Max-card มากกว่า 1 ทั้งคู่ ใน UML นั้น Association ระหว่าง Class แสดงด้วยเส้นตรง ลากเชื่อมระหว่าง Class ทั้ง สอง โดยเส้นที่ลากเชื่อมนั้นต้องมี Association Name กำกับด้วยเสมอ และบนเส้นตรงนั้นต้องมี ลูกศรก้างปลาเพื่อแสดง Association Direction ซึ่งเป็นทิศทางในการอ่านความสัมพันธ์ และแต่ละ ด้านของเส้นตรง ซึ่งอยู่ติดกับ Class ทั้งสอง ต้องถูกกำกับไว้ด้วย Min-card และ Max-card โดย เขียนในรูปแบบ (min..max) หรือ (m) แสดงตัวอย่างของการเขียนจำลองภาพของ Association ใน ภาพที่ 8.9 Association ระหว่าง Member และ MemberCard Association ระหว่าง Member และ Book Association ระหว่าง CompactDisk และ Book

217 Association ระหว่าง Member และ Media ภาพที่ 8.9 การจำลอง Association ด้วย UML เมื่อนำ Association ทั้งหมดมาแสดงรวมกันเป็นภาพเดียว เพื่อให้เห็นเป็นภาพรวมทั้งหมด จะได้ดังภาพต่อไปนี้ ภาพที่ 8.10 การจำลอง Association ในภาพรวมจากตัวอย่างที่ 8.1 ด้วย UML 2) Aggregation คือความสัมพันธ์ระหว่าง Class ที่เป็นลักษณะที่ Class หนึ่งเป็น องค์ประกอบของ Class หนึ่ง ในโลกความเป็นจริง จะพบว่าวัตถุหลายชนิดเกิดจากการรวมตัวของ วัตถุอื่นๆ เช่น คนเกิดจากการรวมกันของ ลำตัว แขน ขา หัว หรือคอมพิวเตอร์เกิดจากการรวมตัว กันของ Main Board, Rom, Disk Drive, Case หรือแม้แต่โลกของเราก็เกิดจากการรวมตัวกันของ ดิน น้ำ อากาศ และแร่ธาตุต่าง เป็นต้น หรือในทางกลับกัน วัตถุชิ้นหนึ่งสามารถแยกออกเป็นวัตถุ ชิ้นย่อยๆ ได้ ซึ่งวัตถุที่ถูกแยกย่อยนั้น มีแนวคิด (Concept) ที่แตกต่างจากเดิม เช่น หนังสือสามารถ แบ่งออกเป็น หน้าปกและหน้าหนังสือ หรือคณะรัฐมนตรี แบ่งออกเป็นฝ่ายค้านและฝ่ายรัฐบาล หรือบทเพลงสามารถแบ่งออกเป็นเนื้อร้องและทำนอง เป็นต้น ความสัมพันธ์แบบ Aggregation มีความคล้ายคลึงกับ Association อยู่มาก (UML ถือว่า Aggregation เป็น Association ประเภทหนึ่ง) ดังนั้น ในการอธิบาย Aggregation จึงจำเป็นต้อง อธิบาย Multiplicity ของ Class ที่มีส่วนร่วมใน Aggregation ด้วยเหมือนกับที่ทำใน Association

218 ใน Association ได้จำแนกความสัมพันธ์ออกเป็น 3 ประเภทตาม Max-card ของ Class ได้แก่ 1:1, 1:M, M:N แต่สำหรับ Aggregation แล้ว จะจำแนกได้เป็น 1:1 และ 1:M เท่านั้น เนื่องจากในการ อธิบาย Class ที่เกิดจากการรวม (Whole Class) กับ Class ที่เป็นองค์ประกอบ (Part Class) นั้น ส่วนของ Part Class จะมีจำนวนเท่าใดก็ขึ้นอยู่กับข้อเท็จจริงของ Class นั้นๆ เอง แต่ตัว Whole Class จะมีเพียงหนึ่งตัวเท่านั้น หรือมี Max-card เป็น 1 เสมอ ดังนั้น ในการเขียนอธิบาย Aggregation ด้วย UML จึงไม่จำเป็นต้องเขียนอธิบายหรือกำกับ Multiplicity ของ Whole Class ใน UML นั้นการจำลอง Aggregation จะใช้เส้นตรงที่มีหัวลูกศรเป็นสี่เหลี่ยมข้ามหลามตัด ลากเชื่อมจาก Part Class ไปยัง Whole Class และกำกับ Minimum และ Maximum Multiplicity ไว้ที่ Part Class ตัวอย่าง การอธิบาย Aggregation ด้วย UML จากข้อความต่อไปนี้ รถยนต์ (Car) ประกอบด้วยเครื่องยนต์ (Engine) หนึ่งเครื่องยนต์ ตัวถัง (Body) หนึ่งตัวถัง และล้อ (Wheel) จำนวน 4 ล้อ ในขณะที่เรือยนต์ (Boat) ประกอบด้วยเครื่องยนต์ 1 เครื่องยนต์ ใบพัด (Propeller) 1 ใบพัด และหางเสือ (Rudder) 1 หางเสือ แสดงเป็นแผนภาพ UML ได้ดังรูป ต่อไปนี้ ภาพที่ 8.11 แสดง Aggregation ของรถยนต์และเรือยนต์ ในภาพที่ 8.11 เป็นตัวอย่างของ Aggregation ที่ Class หนึ่ง สามารถเป็นองค์ประกอบ ของ Class หลักได้มากกว่าหนึ่ง Class กล่าวคือ เครื่องยนต์ (Engine) สามารถเป็นได้ทั้ง องค์ประกอบของรถยนต์ (Car) และของเรือยนต์ (Boat) 3) Composition เป็นความสัมพันธ์แบบขึ้นต่อกัน และมีความข้องเกี่ยวกันเสมอ เช่น ห้องเรียน (Classroom) จะมีอยู่ได้ต้องอาศัยการมีอยู่ของอาคาร (Building) เสมอ ถ้า Building ไม่ได้มีอยู่ Classroom ก็จะไม่สามารถเกิดขึ้นได้เช่นเดียวกัน

219 ตัวอย่างการอธิบาย Composition ด้วย UML จากข้อความต่อไปนี้ หนังสือ (Book) ประกอบด้วย ปก (Cover) 2 ปกคือ ปกหน้าและปกหลัง คำนำ (Preface) 1 คำนำ สารบัญ (TableOfContent) และเนื้อหาบทต่างๆ (Chapter) ความสัมพันธ์ลักษณะนี้ถือว่า เป็น Composition เนื่องจากหากไม่มีหนังสือ ปก คำนำ สารบัญ และเนื้อหาจะไม่มีอยู่ด้วย เช่นเดียวกัน สามารถอธิบายด้วย UML ดังภาพต่อไปนี้ ภาพที่ 8.12 Composition ของ Class Book 4) Generalization เป็นความสัมพันธ์ระหว่างคลาสในลักษณะของการสืบทอดคุณสมบัติ จากโครงสร้างคลาสหนึ่งไปยังโครงสร้างอีกคลาสหนึ่ง โดยที่ Generalization/Specialization ก็คือ เทคนิคการนำคุณสมบัติและพฤติกรรมของ Superclass ถ่ายทอดคุณสมบัติไปยัง Subclass นั่นเอง เมื่อพิจารณาความจริงในโลกนี้ จะพบว่าสิ่งของหรือสิ่งมีชีวิตหลายชนิดเกิดจากการเพิ่มเติม คุณสมบัติพิเศษเข้าไปในสิ่งของหรือสิ่งมีชีวิตอีกสิ่งหนึ่ง เช่น รถสปอร์ต (Sport Car) เกิดจากการ เพิ่มระบบ Turbo และตัวถังแบบพิเศษเข้าไปสู่รถปกติ (General Car) ทำให้วิ่งได้เร็วขึ้น เป็นต้น

220 ภาพที่ 8.13 Generalization ของ Car ภาพที่ 8.13 ได้เพิ่มรายละเอียดของ Attributes ของ Superclass “รถยนต์ (Car)” โดย กำหนดให้มี Attribute “model” (รุ่นของรถยนต์)” และ “engineSize (ขนาดของเครื่องยนต์)” กำหนดให้มีMethod “run (วิ่ง)” และเพิ่ม Attribute “ขนาดของอุปกรณ์ Turbo (turboSize)” ให้กับ Superclass “Car” เพื่อให้เกิดเป็น Subclass “SportCar” ขึ้น ภาพที่ 8.14 Generalization ของ Animal ในภาพที่ 8.14 ได้มีการเพิ่มรายละเอียดของ Attributes และ Methods ของ Superclass “สัตว์ (Animal)” โดยกำหนดให้ Animal มี Attributes “animalType (ประเภทของสัตว์)” มี Method “eat (กินอาหาร)” และเพิ่ม Method “วิ่ง (run)” ให้กับ Superclass “สัตว์ (Animal)”

221 เพื่อก่อให้เกิด Subclass ใหม่คือ “สัตว์บก (LandAnimal)” และ เพิ่ม Method “ดำน้ำ (dive)” ให้กับ Superclass “Animal” เพื่อก่อให้เกิด Subclass ใหม่คือ “สัตว์น้ำ (SeaAnimal)” ขึ้น 4.1.6 หลักการพัฒนาระบบเชิงวัตถุ หลักการพัฒนาระบบเชิงวัตถุ ประกอบด้วยกลุ่มของวัตถุ (Object) ต่างๆ ที่ทำงานร่วมกัน โดยแบ่งบทบาทหน้าที่ความรับผิดชอบ ซึ่งใช้หลักการจัดแบ่งประเภทของ Object ในลักษณะทาง นามธรรมออกเป็นกลุ่มๆ ที่เรียกว่าคลาส (Class) แต่ละ Class ก็จะมีสถานะ (States) รวมทั้ง พฤติกรรม (Behavior) ตามบทบาทของตน โดยมีคุณสมบัติ (Characteristic) ที่เก็บซ่อน (Encapsulate) ใน Class ของตน และไม่มีการปะปนกับ Class อื่นๆ แต่ในด้านการติดต่อสื่อสาร หรือการร้องขอใช้บริการ จะสามารถติดต่อสื่อสารกันได้ด้วยข่าวสารหรือ Message และต่อไปนี้ คือ นิยามความหมายของหลักการพัฒนาระบบเชิงวัตถุ - OOA (Object-Oriented Analysis) เป็นขั้นตอนการวิเคราะห์เพื่อรับรู้และทำความเข้าใจ เกี่ยวกับรายละเอียดของปัญหา ว่ามีปัญหาอะไรบ้างที่ต้องได้รับการแก้ไข โดยในขั้นตอนนี้จะมีการ สร้างแผนภาพขึ้นมาที่เรียกว่า Use Case Diagram - OOD (Object-Oriented Design) เป็นขั้นตอนการออกแบบกระบวนการ ด้วยการสร้าง แบบจำลองเชิงวัตถุ ที่สามารถแสดงความหมายออกมาทั้งในเชิงตรรกะและเชิงกายภาพ ว่าจะแก้ไข ปัญหาเหล่านั้นได้อย่างไร โดยจะมีการกำหนดชนิดของวัตถุเพิ่มเติม ให้มีส่วนสำคัญต่อการสื่อสาร กับมนุษย์และอุปกรณ์ในระบบ วัตถุมีการโต้ตอบกันอ่างไรจนกระทั่งงานนั้นเสร็จสมบูรณ์ ต่อมาก็จะ ปรับวัตถุ (Object) แต่ละตัวให้มีความชัดเจนมากยิ่งขึ้น เพื่อนำไปเป็นแบบสำหรับการเขียน โปรแกรมต่อไป - OOP (Object-Oriented Programming) เป็นขั้นตอนการนำสิ่งที่ได้วิเคราะห์และ ออกแบบมาทั้งหมด มาแปลงเป็นระบบจริงขึ้นมา ด้วยการเขียนโปรแกรมภาษาคอมพิวเตอร์ เพื่อ กำหนดหรือสั่งให้วัตถุแต่ละตัวมีหน้าที่อะไร รวมถึงเมสเสจ (Message) ที่มีการสื่อสารโต้ตอบ ระหว่างกัน Unified Modeling Language (UML) ในการพัฒนาระบบเชิงวัตถุนั้น สิ่งที่จำเป็นอย่างหนึ่งในกระบวนการวิเคราะห์และออกแบบ คือ การสร้างแบบจำลองของ Object และ Class และองค์ประกอบอื่นๆ ของระบบ ซึ่งวิธีการ ถ่ายทอดแบบจำลองที่ชัดเจนที่สุด คือ การแสดงในรูปของสัญลักษณ์ที่มองเห็นได้ (Visualization) เช่น รูปภาพ แผนภาพ เป็นต้น ทำให้มีการคิดค้นรูปภาพ แผนภาพ และมาตรฐานต่างๆ ซึ่งเป็น เครื่องมือที่ทำให้นักวิเคราะห์ระบบสามารถสร้างแบบจำลองขององค์ประกอบต่างๆ ขึ้น หนึ่งใน เครื่องมือที่ได้รับการยอมรับและนิยมใช้มากที่สุดคือ “Unified Modeling Language (UML)” ซึ่ง UML จัดว่าเป็นภาษา เนื่องจาก UML มีหน่วยของภาษา (Language Units) ที่ชัดเจน คือ มีทั้ง

222 คำศัพท์ (Vocabulary) และไวยากรณ์ (Syntax: กฎกติกาในการนำคำศัพท์มาเรียงต่อกัน ) ที่ชัดเจน แต่ UML แตกต่างจากภาษาทั่วไป คือ หน่วยของภาษานั้น ประกอบขึ้นจากรูปภาพและแผนภาพ ไม่ใช่อักขระ จึงได้มีการจัดให้ UML เป็นประเภทหนึ่งของภาษารูปภาพ (Graphical Language) UML ช่วยให้นักวิเคราะห์และออกแบบระบบสามารถถ่ายทอดความคิดที่มีต่อระบบ ให้อยู่ในรูปของ แผนภาพซึ่งสามารถมองเห็นและตีความได้ ดังนั้น UML จึงจัดเป็น Methodology หนึ่งเช่นเดียวกับการวิเคราะห์ระบบเชิงโครงสร้างที่ ใช้ Data Flow Diagram (DFD) และ Entity Relationship Diagram (ERD) ส่วนระเบียบวิธีการ พัฒนาซอฟต์แวร์เชิงวัตถุด้วย UML อาจนำเทคนิคของ Unified Process มาใช้ ซึ่งประกอบด้วย 4 ระยะด้วยกันคือ Inception, Elaboration, Construction และ Transition แผนภาพในภาษา UML ภาษา UML ประกอบด้วยแผนภาพ (Diagram) ต่างๆ แต่ละแผนภาพต่างก็ให้มุมมองที่ แตกต่างกัน เพื่อให้เกิดความเข้าใจในระบบงานมากขึ้น แต่ในการพัฒนาระบบงานอาจไม่จำเป็นต้อง ใช้ทุก Diagram ก็ได้ ซึ่งอาจพิจารณาเพียง Diagram ที่เหมาะสมและเพียงพอต่อความต้องการ 1) Use Case Diagram Use Case Diagram เป็นแผนภาพที่ถูกนำมาใช้เพื่อแสดงภาพรวมของระบบด้วยการ อธิบายถึงพฤติกรรมหรือฟังก์ชันการทำงานของระบบว่ามีอะไรบ้าง เกี่ยวข้องกับใคร ซึ่งช่วยให้ นักพัฒนาสามารถแยกแยะกิจกรรมที่เกิดขึ้นในระบบ ว่ามีฟังก์ชันการทำงานอะไรโดยฟังก์ชันการ ทำงานเหล่านี้ จะต้องได้รับการดำเนินงานโดยระบบ Use Case Diagram ประกอบด้วย Actor, Use Case และ Relationship โดยที่ - Actor หมายถึงผู้เกี่ยวข้องกับระบบ เป็นองค์ประกอบที่แสดงถึง Entity ที่อยู่ภายนอก ระบบและมีการปฏิสัมพันธ์กับระบบ รวมถึงแสดงความสัมพันธ์กับ Use Case ใช้สัญลักษณ์เป็นรูป คน - Use Case ใช้แสดงถึงฟังก์ชันการทำงานของระบบ หรือสิ่งที่ระบบต้องทำในมุมมองของ ผู้ใช้งาน ใช้สัญลักษณ์เป็นรูปวงรี - Relationships คือความสัมพันธ์ ซึ่งสามารถเป็นความสัมพันธ์ที่เกิดขึ้นระหว่าง Use Case กับ Use Case, Actor กับ Use Case หรือ Actor กับ Actor โดยมีรูปแบบความสัมพันธ์ ต่างๆ เช่น Association, Aggregation, Composition และ Generalization

223 สัญลักษณ์ ความหมาย Actor คือบุคคล หน่วยงาน หรือระบบงานที่ อยู่ภายนอก Use Case คือฟังก์ชันการทำงานต่างๆ Relationships คือความสัมพันธ์ระหว่าง Actor กับ Use Case Relationships คือความสัมพันธ์ระหว่าง Use Case กับ Use Case ภาพที่ 8.15 สัญลักษณ์และความหมายใน Use Case Diagram ตามปกติแล้ว แบบจำลองของระบบใดระบบหนึ่ง มักจะมี Use Case มากกว่า 1 Use Case และแต่ละ Use Case ก็ยังมีความสัมพันธ์ระหว่างกันได้ โดยความสัมพันธ์ระหว่าง Use Case มี 2 ชนิดคือ ความสัมพันธ์แบบ <<include>> และ ความสัมพันธ์แบบ <<extends>> - ความสัมพันธ์แบบ <<include>> เป็นความสัมพันธ์แบบเรียกใช้งาน Use Case อื่นๆ ตามที่ต้องการ เพื่อทำงานร่วมกัน - ความสัมพันธ์แบบ <<extends>> เป็นความสัมพันธ์แบบทางเลือก โดย Use Case ที่ เป็นส่วนขยายนั้น จะมีกระบวนการทำงานเพิ่มเติมจาก Use Case หลัก ดังนั้น กรณีต้องการใช้ส่วน ขยายเพิ่มเติม ก็ต้องเชื่อมความสัมพันธ์ของส่วนขยายเหล่านั้น ไปยัง Use Case หลักเพื่อให้สามารถ รองรับการทำงานตามเงื่อนไขดังกล่าว โดยทั้ง Include และ Extend จะต้องเขียนอยู่ภายใต้ สัญลักษณ์ <<…>> ที่เรียกว่า Stereotype

224 ภาพที่ 8.16 ตัวอย่างการใช้ <<include>> และ <<extend>> พิจารณาจากภาพที่ 8.16 ซึ่งเป็นตัวอย่างระบบลงทะเบียน ในกรณีที่เป็นนักศึกษารายใหม่ จะต้องได้รับการบันทึกประวัตินักศึกษาก่อน (Create student) จึงสามารถลงทะเบียนได้ ดังนั้น เมื่อมีการ Create student เสร็จแล้ว จะพบว่า Use Case Create student ได้ <<include>> Use Case Enroll เพื่อทำการลงทะเบียนเรียน ในทำนองเดียวกัน กรณีนักศึกษาเก่าที่มีประวัติอยู่ แล้ว ก็ไม่จำเป็นต้องบันทึกประวัติใหม่แต่อย่างใด สามารถลงทะเบียนได้ทันทีโดยเรียกใช้ Use Case Enroll แต่ถ้านักศึกษาผู้นั้นมีการเปลี่ยนแปลงชื่อ ที่อยู่ ย้ายคณะ หรือสาขาวิชา ก็จะต้องเรียกใช้ Use Case Modify student เมื่อเปลี่ยนแปลงข้อมูลเสร็จ ก็เรียกใช้ Use Case Enroll เพื่อ ลงทะเบียนเรียนต่อไป และเมื่อต้องการเพิ่มวิชาหรือถอนรายวิชา จะทำการสร้าง Use Case ใหม่ ขึ้นมาคือ Use Case Add/Withdrawal โดยกระบวนการทำงานจะเริ่มต้นที่ Use Case หลักนั่นก็ คือ Enroll จากนั้นหากเป็นการลงทะเบียนเพิ่มหรือถอนรายวิชาเรียน ก็จะ <<extend>> Use Case Add/Withdrawal เข้ามา โดยภายหลังเสร็จสิ้นการทำงานที่ Use Case Add/Withdrawal แล้ว ก็จะกลับมาทำงานต่อไปในส่วนที่เหลือของ Use Case Enroll ต่อไป 2) Class Diagram Class Diagram เป็นแผนภาพที่ใช้แสดงโครงสร้างของระบบ ซึ่งประกอบไปด้วย Class ต่างๆ และความสัมพันธ์ระหว่าง Class โดยอาจเป็นได้ทั้งความสัมพันธ์แบบ Association, Aggregation, Composition หรือ Generalization ใน Class Diagram จะบอกถึง Class ทั้งหมด ที่ต้องมีภายในระบบ สิ่งที่ Class นั้นทำได้คือ คุณสมบัติและขั้นตอนการทำงาน (attribute and