เอกสารประกอบการเรียน การวิเคราะห์และออกแบบระบบเชิงวัตถุ

44 2. เครือ่ งมือออกแบบซอฟต์แวร์ (Software Design Tools)เป็นเคสทลู สท์ ีใ่ ช้สำหรบั การออกแบบ ซอฟต์แวร์ และตรวจสอบความตอ้ งการทางด้านซอฟต์แวรใ์ หม้ คี วามสมบูรณ์และสอดคล้องตามความต้องการของ ลกู คา้ ปัจจบุ นั มเี คสทลู ส์ประเภทนจ้ี ำ นวนมาก ไดแ้ ก่ Justinmind และ Drwa.io เปน็ ตน้ 3. เครื่องมือสรา้ งซอฟต์แวร์ (Software Construction Tools) เปน็ เคสทลู ส์ทีใ่ ชส้ ำหรบั สร้างหรือแก้ไข ซอฟต์แวรท์ นี่ ำมาพัฒนาโปรแกรมให้กบั ลูกค้า ได้แก่ โปรแกรมคอมไพเลอร์ (Compiler)โปรแกรมอนิ เตอร์พรีเตอร์ (Interpreter) โปรแกรมดีบักเกอร(์ Debugger) เชน่ Eclipse, Sublime Text Firebase และ Visual Studio ตา่ งๆ

45 4. เครือ่ งมือทดสอบซอฟต์แวร์ (Software Testing Tools)เป็นเคสทูลสท์ ่ีใชส้ ำหรบั การทดสอบ ซอฟตแ์ วร์ มีการกำหนดกรอบการปฏบิ ัตกิ ารทดสอบภายใต้สภาพแวดลอ้ มท่ีกำหนดไวล้ ่วงหนา้ ใชจ้ ดั ทำเคร่อื งมือ ประเมนิ ผลการทดสอบวา่ เป็นไปตามท่ีคาดหวังหรือไม่ ใชบ้ ริหารงานทดสอบและวเิ คราะห์ประสทิ ธิภาพการทำงาน ของซอฟต์แวร์โดยแบ่งรูปแบบการทดสอบออกเป็น 5 ชนิด คอื 1. Unit Test เป็นการทดสอบโดยโปรแกรมเมอร์หรือผทู้ เ่ี ขยี นโปรแกรมขึ้นมา การทดสอบในรปู แบบน้ีทำ ขึน้ เพ่ือยืนยนั การทำงานในระดับย่อยท่ีสุดว่า ทำงานได้ถกู ต้องทต่ี ามทต่ี ้องการหรอื ไม่ 2. Integration Test เปน็ การทดสอบการเชื่อมต่อส่วนต่าง ๆ ท่ีนำมาประกอบกันเป็นโปรแกรม เช่น โมดูล (Module) ย่อย ๆ ของโปรแกรมมคี วามสมบูรณแ์ ละสง่ ตอ่ ข้อมลู ได้ครบถว้ นตามที่ต้องการหรือไม่ 3. System Test เป็นการทดสอบการเชอื่ มต่อและการสอ่ื สารกนั ระหวา่ งซอฟต์แวร์หรอื ระบบอน่ื ๆ ท่ี นำมาเช่ือมโยงกนั วา่ มคี วามสมบรู ณแ์ ละเช่ือมต่อได้อย่างมีประสิทธภิ าพหรอื ไม่ 4. Acceptant Test เป็นการทดสอบโดยให้ผูใ้ ช้งาน (End User) หรือลกู คา้ ทดลองการทำงานของ โปรแกรมวา่ ถกู ต้องและสอดคลอ้ งกบั ความตอ้ งการหรือไม่ 5. Usability Test เป็นการทดสอบโดยผูเ้ ชีย่ วชาญวา่ โปรแกรมที่พฒั นาข้นึ มามีการใชง้ านทงี่ ่าย สะดวก และสอดคล้องกบั ความต้องการของผ้ใู ชห้ รือไม่

46 5. เครือ่ งมือบำรงุ รักษาซอฟต์แวร์ (Software Maintenance Tools) เปน็ เคสทูลส์ทใี่ ช้สำหรับ บำรุงรักษาซอฟตแ์ วร์ที่มีอยแู่ ล้วใหค้ งสภาพใช้งานได้ดีอยู่ตลอดเวลา เช่น โปรแกรม Synei SystemUtilities หรอื CCleaner เป็นตน้ สำหรบั เคสทลู สป์ ระเภทนีส้ ามารถแบง่ ออกเปน็ 2 กล่มุ คือ 1.เครอ่ื งมือสร้างความเขา้ ใจ (Comprehension Tools) เป็นเคสทูลส์ท่ีช่วยให้ทมี งานซ่อมบำรงุ รกั ษา ระบบ ทำความเข้าใจกบั โปรแกรมท่บี ำรุงรักษาไดง้ ่ายขนึ้ 2. เครอ่ื งมือร้อื ปรับระบบใหม่(Reengineering Tools)เปน็ เคสทูลส์ท่ีช่วยในกระบวนการปรบั ปรงุ โครงสร้างของโปรแกรมทีละส่วน เพ่อื ทำให้โปรแกรมอยใู่ นสภาพทส่ี มบรู ณเ์ หมือเดิม รปู แสดง ตัวอย่างหนา้ จอโปรแกรม CCLeaner

47 รปู แสดง ตวั อย่างหน้าจอโปรแกรม Synei System Utilities 6. เคร่อื งมือจดั การโครงแบบ (Software Configuration Management Tools) เปน็ เคสทลู ส์ทใ่ี ช้ สำหรบั ตดิ ตามการเปลยี่ นแปลงของทกุ องค์ประกอบของโปรแกรม มีการจัดการรนุ่ ของโปรแกรมและการวาง จำหน่ายโปรแกรม ตวั อยา่ งโปรแกรมท่ีนยิ มใชง้ าน ได้แก่ SVN : Subversion • Perforce • VCC: Visual Source Safe • CVS : Concurrent Version System • Rational Clear Case

48 รปู แสดง ตัวอย่างหน้าจอโปรแกรม Relationnal Clearcase รูปแสดง ตัวอยา่ งหนา้ จอโปรแกรม Perforce

49 7. เคร่ืองมือบริการงานวศิ วกรรมซอฟต์แวร์(Software Engineering Management Tools) เปน็ เคส ทลู สท์ ใ่ี ชส้ ำหรบั การวางแผนและการติดตามโครงการ และการจัดการความเสย่ี ง มีการ ประมาณการแรงงานและต้นทุน พรอ้ มท้งั จดั ตารางงาน มีการระบปุ ัจจัยเสย่ี ง ประมาณการผลกระทบและติดตาม ความเสีย่ ง ตวั อย่างโปรแกรมทเ่ี กี่ยวข้อง ได้แก่ Condendi Redmine Projectpire Trac และ Project HQ เปน็ ต้น รูปแสดง ตัวอยา่ งหนา้ จอโปรแกรม Condendi รูปแสดง ตวั อยา่ งหน้าจอโปรแกรม Project HQ

50 8. เครอื่ งมือคุณภาพซอฟต์แวร(์ Software Quality Tools) เปน็ เคสทลู ส์ทใี ช้ สำหรับตรวจสอบคณุ ภาพ (Inspection Tools) และวิเคราะหค์ ุณภาพ (Static Analysis Tools) ซ่งึ ใชส้ ำหรบั ทบทวนและตรวจสอบ คณุ ภาพของโปรแกรมมีการวิเคราะหล์ ักษณะด้านต่าง ๆ ของโปรแกรมตวั อย่างโปรแกรม ได้แก่Php Metrics เปน็ ต้น รูปแสดง ตัวอย่างหน้าจอโปรแกรม Pho Metrics สรุป เครอื่ งมือเคสทลู สท์ ใ่ี ช้ในการวิเคราะหแ์ ละออกแบบระบบดงั นี้ • เครอื่ งมือคณุ ภาพซอฟแวร์(Software Quality Tools) • เครื่องมือบริการงานวศิ วกรรมซอฟแวร์ (Software Engineering Management Tools) • เครือ่ งมือจดั การโครงแบบ (Software Configuration Management Tools) • เครือ่ งมอื บำรุงรักษาซอฟแวร์ (Software Maintenance Tools) • เคร่อื งมอื ทดสอบซอฟแวร์ (Software Testing Tools) • เครอ่ื งมือสร้างซอฟแวร์ (Software Construction Tools) • เครือ่ งมือออกแบบซอฟแวร์ (Software Design Tools) • เครือ่ งมือสำหรับการวเิ คราะห์(Software Requirement Tools)

51 การออกแบบระบบ(System Design) การออกแบบระบบ ถือเป็นส่วนที่เกิดขึ้นหลังจากการวิเคราะห์ระบบโดยจุดประสงค์สำคัญในการ วิเคราะห์ระบบ คือ การแสวงหาข้อเท็จจริงถงึ ความต้องการของผู้ใช้ (End User) หรือ ลูกค้า ว่าต้องการให้ระบบ ทำงานเพื่ออะไร แก้ไขปัญหาอะไร และขอบเขตการทำงานเป็นอย่างไร ดังนั้นเมื่อนักวิเคราะห์ระบบได้วิเคราะห์ และรวบรวมความต้องการของลูกค้าเหล่านั้นเป็นที่เรียบร้อยแล้ว ก็จำเป็นต้องประมวลความต้องการเหล่านั้น ออกมาอยู่ในรูปของแผนภาพ เพื่อขยายความเข้าใจและสื่อสารความต้องการเหล่านั้นให้เข้าใจกันทุกฝ่ายท่ี เกี่ยวข้องไม่ว่าจะเป็นผู้ใช้ โปรแกรมเมอร์ หรือนักวิเคราะห์ระบบ ซึ่งวิธีการสื่อสารเหล่านี้จะเรียกว่า กาออกแบบ ระบบ การออกแบบระบบ คือ การนำเอาความตอ้ งการของระบบหรอื ข้อมูลที่ได้จากขัน้ ตอนต่าง ๆ ที่ผ่านมา นำมาเปน็ แบบแผนในการสร้างระบบสารสนเทศใหใ้ ชง้ านได้จรงิ และเป็นรปู ธรรม โดยอาศัยเครือ่ งมือตา่ ง ๆ ในการ ออกแบบ เชน่ การออกแบบฐานข้อมลู การออกแบบสว่ นการแสดงผล การออกแบบสถาปัตยกรรมซอฟต์แวร์ การ ออกแบบสถาปัตยกรรมฮาร์ดแวร์ การออกแบบสว่ นประสานงานกบั ผู้ใช้ เปน็ ตน้ • การออกแบบระบบ แบ่งออกไดเ้ ป็น 2 ประเภท คือ • การออกแบบเชิงตรรกะ (Logical Design) • การออกแบบเชงิ กายภาพ (Physical Design) การออกแบบเชิงตรรกะ (Logical Design) คอื การวเิ คราะหใ์ รายละเอียดเพื่อกำหนดความสมั พันธข์ อง โครงสรา้ งตา่ ง ๆ ภายในระบบ โดยมีการออกแบบฟอรม์ (Form Design) ออกแบบรายงาน (Report Design) เพื่อให้เหน็ ความสัมพนั ธข์ องข้อมูลท่ีนำเขา้ และนำออกจากระบบ มีการออกแบบในสว่ นของฐานข้อมูล อปุ กรณ์ ชดุ คำส่งั และบคุ ลากรทเี่ ก่ยี วขอ้ ง รูปแสดง ตวั อยา่ งหนา้ Form Design

52 การออกแบบเชิงกายภาพ(Physical Design) การออกแบบเชิงกายภาพ คือ การนำผลจากการออกแบบเชิงตรรกะมาออกแบบให้ระบบสามารถทำ งานได้จริง เป็นรูปธรรม โดยผู้พัฒนาโปรแกรมจะต้องใช้ความระมัดระวังในการตัดสินใจเกี่ยวกับระบบด้วยความ รอบคอบ ต้องพิจารณาปัจจัยแวดล้อมที่เก่ียวข้องอย่างครบถ้วน เช่น จะนำ ระบบใหม่มาแทนที่ระบบเดิมอย่างไร จะดำเนินการแปลงข้อมูลจะระบบเดิมมาสู่ระบบใหม่ด้วยวิธีอะไร มีความเป็นไปได้มากน้อยเพียงใด และมีความ เสีย่ งใดที่เก่ยี วข้องบา้ ง ทำอย่างไรจึงจะลดผลกระทบที่เกิดข้นึ เหล่านนั้ ไปได้ แสดงกิจกรรม แบบจำลอง เทคนคิ และเคร่อื งมือในข้ันตอนการออกแบบระบบ รปู แสดงตัวอยา่ งการออกแบบหนา้ จอบนโทรศพั ท์มือถือ

53 การติดต้ังระบบ การติดตงั้ ระบบ คือ การนำระบบใหม่ทีผ่ า่ นกระบวนการวเิ คราะห์ และออกแบบระบบมาอยา่ งดีแล้ว เข้ามาตดิ ตั้งให้กับผใู้ ช้งานหรือในองคก์ ร โดยแบง่ วิธกี ารตดิ ตง้ั ออกเป็น 1.การตดิ ตงั้ แบบทันที เปน็ การตดิ ตัง้ ระบบทันทเี ม่ือครบกำหนดเวลา โดยระบบเดิมจะถูกยกเลิกไปท้งั หมดในวันท่ตี ิดต้งั เสรจ็ เรียบรอ้ ย 2. การติดตั้งแบบขนาน เปน็ การติดตั้งระบบใหมใ่ ห้ทำงานควบคู่ไปกบั ระบบเดมิ สักระยะหนง่ึ จนม่ันใจวา่ ระบบใหม่สามารถ ทำงานได้ตรงตามที่ตอ้ งการและทดแทนระบบเดิม ได้ จึงทำการยกเลกิ ระบบเดิมแล้วใชร้ ะบบใหมแ่ ทน 3. การตดิ ต้งั แบบเป็นระยะ เปน็ การตดิ ตงั้ ระบบทลี ะสว่ นเป็นระยะ ๆ เริ่มจากส่วนทมี่ ีความจำเป็นเร่งด่วนท่สี ดุ ก่อน และค่อย ๆ ดำเนนิ การติดตง้ั ไปจนครบทกุ สว่ นจนครบสมบูรณ์เป็นที่เรยี บร้อย

54 4. การตดิ ตั้งแบบนำรอ่ ง เป็นการติดตง้ั ระบบที่มลี ักษณะคล้ายกับแบบเปน็ ระยะ โดยจะเริม่ ทดลองตดิ ต้ังระบบกับบางหน่วยงาน หรือบางสาวน ถา้ ระบบงานท่ีตดิ ตงั้ สามารถทำงานไดต้ รงตามเปา้ หมายจึงขยายไปติดต้งั ให้กับหน่วยงานหรือสาขา อ่นื ๆ จนสำเร็จครบทั่งระบบ การติดตงั้ ระบบ จากข้อมูลข้างตน้ การพัฒนาและการติดตั้งระบบ จึงหมายถึง การพัฒนาโปรแกรม (Coding)การทดสอบ ระบบ (Testing)การติดตั้ง(Installation) การจัดทำเอกสาร (Documentation) และการอบรม(Training) ซึ่งเปน็ หน้าที่หลกั ของนักวิเคราะห์ระบบ และนักเขียนโปรแกรมที่ต้องดำเนนิ การ โดยมีวัตถุประสงค์เพื่อปรบั เปลี่ยนจาก ระบบงานเดิมเข้าสู่ระบบงานใหม่ที่ไดผ้ ่านการวิเคราะห์และออกแบบมาแล้ว โดยเริ่มจากการพัฒนาโปรแกรมของ ระบบงาน ทดสอบระบบที่พัฒนาขึ้นเพื่อให้ได้ระบบที่ถูกต้องสมบูรณ์และมีข้อผิดพลาดเกิดขึ้นน้อยที่สุดพร้อมทั้ง จดั ทำเอกสารคู่มือสำหรับระบบ และทำการจดั ฝกึ อบรมใหก้ ับผเู้ กี่ยวข้องกบั ระบบอนั จะทำใหร้ ะบบสามารถทำงาน ไดอ้ ยา่ งมปี ระสทิ ธภิ าพ รปู แสดงตวั อยา่ งแผนภาพการทดสอบระบบ

55 การบำรุงรักษาระบบ(System Implemetation) การบำรงุ รกั ษาระบบ คือ ขั้นตอนการเก็บรวบรวบข้อมูล หรือคำร้องขอในการปรับปรงุ ระบบ ภายหลงั จากท่ีผู้ใช้งานระบบได้ใช้มารุ่นหน่ึงแล้ว ซึง่ ปญั หาที่เกิดขึ้นอาจจะมีแนวทางแกไ้ ขปญั หาอย่แู ลว้ ดงั นน้ั นกั วเิ คราะห์ ระบบจึงต้องเกบ็ รวบรวมข้อมูลเหลา่ นมี้ าวิเคราะหค์ วามตอ้ งการของผูใ้ ช้งานและออกแบบการทำงานทีต่ ้องการ ปรับปรุง เพือ่ ตอบสนองความตอ้ งการของผูใ้ ช้ และเพ่มิ ประสิทธภิ าพให้กับการทำงานของระบบที่จำเป็นตอ้ งได้รับ การปรับปรุงอย่างต่อเน่อื งให้ตรงกับความต้องการของผ้ใู ชใ้ หไ้ ดม้ ากที่สุด ตารางแสดงกจิ กรรม แบบจำลอง เทคนิค และเครือ่ งมอื ในขัน้ ตอนการบำรุงรักษาระบบ

56 หนว่ ยที่ 5 โมเดลทีใ่ ชอ้ อกแบบเชงิ วตั ถุ “ UML ” สาระการเรียนรู้ 1. โมเดล (Model) 2. ความสำคญั ของแบบจำลองระบบงาน 3. ประเภทของโมเดล (Model Type) 4. โมเดลออกแบบเชงิ วตั ถุ (Object Model) จุดประสงค์การเรียนรู้ 1. เพือ่ ให้เขา้ ใจรปู แบบของโมเดลทีใ่ ชอ้ อกแบบเชิงวตั ถุ 2. เพ่อื ให้เข้าใจรูปแบบของโมเดลเชงิ วัตถุแตล่ ะประเภท 3. เพื่อให้ทักษะคติท่ีดีในการอยู่ร่วมกันแบบหมู่คณะคำนงึ ถึงความเปน็ ไทยและมจี รยิ ธรรมท่ดี งี าม สมรรถนะประจำ 1. แสดงความรูเ้ กีย่ วกบั โมเดลทใ่ี ชอ้ อกแบบบเชงิ วัตถุ 2. เลอื กโมเดลที่เหมาะสมในการออกแบบบเชงิ วัตถุ 3. เปรียบเทียบความแตกต่างระหว่าโมเดลเชิงโครงสร้างและโมเดลเชงิ พฤติกรรม

57 โมเดล (Model) โมเดล หรือเรียกว่า “แบบจำลองระบบ” คือ แผนภาพที่ใช้ สัญลักษณ์ในการจำลองข้อเท็จจริงต่างๆ ท่ี เกดิ ขึน้ ในระบบ ทำใหผ้ ้ใู ช้ ระบบมีความเขา้ ใจขั้นตอนการทำงานในมมุ มองตา่ ง ๆ เชน่ หนา้ ที่ของระบบ โครงสร้าง ของระบบ และส่วนประกอบต่าง ๆ ของระบบได้อย่างง่าย ๆ เพราะการใช้สัญลักษณ์ที่เป็นรูปภาพแทนการใช้ ภาษาพูด จะทำให้การสื่อสารระหว่างบุคคลต่าง ๆ มีความเข้าใจตรงกันและนำไปสู่ขั้นตอนการวิเคราะห์และ ออกแบบระบบในลำดบั ต่อไปโดยท่ีผู้เก่ียวข้องไม่จำเป็นตอ้ งมีความรดู้ ้านคอมพวิ เตอร์กส็ ามารถเข้าใจกระบวนการ ทำงานตามแบบจำลองดังกล่าวได้ ความสำคัญของแบบจำลองระบบงาน แบบจำลองระบบงานมีความสำคัญกบั การวเิ คราะห์และออกแบบระบบ สามารถสรุปได้ ดังนี้ 1. แบบจำลองเป็นเคร่อื งมือสำคัญทช่ี ่วยให้การสือ่ สารระหวา่ งบคุ คลทกุ ฝา่ ยมีความถูกต้องตรงกันมากขึน้ 2. แบบจำลองประกอบดว้ ยรูปภาพสัญลักษณ์แสดงใหเ้ หน็ การทำงานของระบบ หรือแสดงใหเ้ ห็นหนา้ ท่ขี อง ระบบ โครงสร้าง และส่วนประกอบต่าง ๆ 3. แบบจำลองเป็นสิง่ ที่ไดจ้ ากการวิเคราะหค์ วามต้องการของผู้ใชท้ งั้ ในด้านระบบและซอฟต์แวร์ 4. แบบจำลองสะทอ้ นให้เห็นหน้าทก่ี ารทำงานของระบบในดา้ นตา่ ง ๆได้อย่างชดั เจน 5. ระบบทำหนา้ ทอ่ี ะไร (What) และอย่างไร (How) 6. มกี ารสรา้ งแบบจำลองในระยะการวเิ คราะห์ความต้องการและเปน็ จุดเร่ิมต้นของการสร้างแบบจำลอง ระยะอืน่ ๆ

58 ประเภทของโมเดล (Model Type) การวิเคราะห์และออกแบบระบบสารสนเทศ จำแนกเป็นโมเดลได้ 3 แบบ คือ 1. โมเดลจำลองกระบวนการ คือ แบบจำลองแสดงขน้ั ตอนการทำงานของระบบในเชิงโครงสรา้ ง มลี ำดบั ขั้นตอนการดำเนนิ งานทแ่ี น่นอนและมีความสมั พันธ์กัน ให้ความสำคัญกับหลกั การ Input-Process-Output ไดแ้ ก่ • แผนภาพกระแสการไหลขอ้ มูล • ผังงาน • พจนานุกรมข้อมูล • ผงั โครงสรา้ งระบบงาน • ตารางการตัดสินใจและผงั ตน้ ไม้ ประเภทของโมเดล(Model Type) การวเิ คราะห์และออกแบบระบบสารสนเทศ จำแนกเป็นโมเดลได้ 3 แบบ คือ 1. โมเดลจำลองกระบวนการ รปู ภาพแสดง โมเดล ประเภท DFDs

59 รูปภาพแสดง โมเดล ประเภทพจนานกุ รมข้อมูล รปู ภาพแสดง โมเดล ตารางแสดงการตัดสนิ ใจ

60 รปู ภาพแสดง โมเดลผงั ต้นไม้ 2. โมเดลจำลองฐานข้อมูล คือ แบบจำลองแสดงความสมั พนั ธ์ของฐานข้อมลู ในระบบ โดยจะแสดงชดุ ข้อมลู ท่เี กี่ยวข้อง และรปู แบบความสัมพนั ธท์ ีเ่ กดิ ขึ้น ได้แก่ • แผนภาพแสดงความสัมพันธข์ องข้อมลู (ERDM) รูปภาพแสดง โมเดลจำลองฐานขอ้ มลู ประเภท ERDM

61 3. โมเดลออกแบบเชิงวตั ถุ คือ แบบจำลองท่ีใช้สญั ลกั ษณ์มาแสดงเป็นแผนภาพจำลองขัน้ ตอนการทำงาน ของระบบ ได้แก่ภาษา UML (Unified Modeling Language) เปน็ ภาษาโมเดลในรปู แบบแผนภาพ (Graphical Model) เช่น • ผงั ภาพยูสเคส (Use Case Diagram) • ผงั ภาพคลาส (Class Diagram) รูปภาพแสดงโมเดลออกแบบเชงิ วัตถุใน ภาษา UML โมเดลออกแบบเชิงวัตถุ (Object Model) โมเดลออกแบบเชิงวัตถุ เป็นเครอื่ งมอื ท่นี ำสญั ลักษณม์ าใชใ้ นการสอ่ื สาร สร้างข้อตกลงและความเขา้ ใจ รว่ มกันของทมี พฒั นาระบบ รวมถึงเจ้าของระบบดว้ ย ลกั ษณะสำคัญของโมเดลรปู แบบนี้คือจะมงุ่ สรา้ งคลาสและ กำหนดลักษณะของคลาสที่ทำงานรว่ มกันโดยจะเนน้ แกป้ ัญหาโครงสร้างข้อมูลตามลำดับและให้ความสำคัญท่ี ออบเจ็กต์ ของหน่วยโครงสร้างพืน้ ฐานโปรแกรม ปัจจบุ นั จะใช้ภาษายเู อ็มแอล (UML)ในการสร้างโมเดลออกแบบเชิงวตั ถุ โดยโมเดลที่เปน็ ศนู ยก์ ลางของ ระบบคือ“ผังภาพคลาส” (Class Diagram) ซ่งึ จะเกดิ ข้นึ ในระยะแรกของ การวเิ คราะหร์ ะบบ และใช้เป็นกลไก พนื้ ฐานในการพัฒนาโมเดลพฤติกรรมของระบบต่อไป ซ่ึงโมเดลทใี่ ช้ออกแบบเชิงวตั ถุแบ่ง ออกไดเ้ ป็น 2 กลมุ่ ได้แก่ 1. แผนภาพอธิบายโครงสรา้ งระบบ (Structural Model) เป็นโมเดลท่จี ำลองโครงสร้างของระบบเชงิ สถิต (Static)ของระบบ คือ โครงสรา้ งในสว่ นทไี่ ม่มกี ารเปลย่ี นแปลงหรอื เคล่ือนไหว ถึงแมจ้ ะมเี หตุการณใ์ ด ๆ เกิดขึน้ ได้แก่

62 1.1Class Diagram เป็นแผนภาพท่ีแสดงความสัมพนั ธ์ของออบเจ็กตท์ ่ีเชื่อมโยงกนั ตามความ ตอ้ งการของระบบ ลกั ษณะเป็นโครงสรา้ ง ซง่ึ ประกอบดว้ ย คลาส ประเภทคลาส เนอื้ หา และ ความสัมพนั ธ์ระหวา่ งกนั 1.2 Object Diagram เป็นแผนภาพแสดงความสัมพนั ธร์ ะหวา่ งออบเจก็ ต์ในขณะหนึ่ง โดยเปน็ การแสดงสถานการณห์ นงึ่ ตามแผนภาพคลาส มีลักษณะคล้ายกับ Class Diagram แต่จะมองสง่ิ ตา่ ง ๆ เป็นวัตถุแทนหรอื อาจกลา่ วได้ว่า Class Diagram มลี กั ษณะเปน็ นามธรรมประกอบด้วย คลาสและ ความสมั พันธ์เท่านั้น ในขณะที่ Object Diagram จะแสดงมมุ มองด้านพฤติกรรมท่เี กดิ ขึ้นจรงิ ของระบบ โดยมจี ุดประสงค์เพอื่ จบั คา่ คงทข่ี องระบบในขณะเวลาหนึ่ง สว่ นใหญ่ใช่ในการสรา้ งตน้ แบบของระบบ วศิ วกรรมยอ้ นกลบั การสร้างแบบจำลองโครงสร้างข้อมูลที่ซับซอ้ น ทำความเขา้ ใจกบั ระบบจากมมุ มองการ ปฏบิ ตั ิ ซึง่ มีองค์ประกอบ 2 สว่ น คือ • คุณสมบตั ิ (Properties) • พฤติกรรม (Behavior)

63 1.3 Package Diagram เป็นแผนภาพแสดงการจับกลุ่มองคป์ ระกอบต่าง ๆ ของระบบ ให้อยู่ รว่ มกนั ทำให้การจัดการมีความสะดวกและง่ายยง่ิ ข้ึน แผนภาพลกั ษณะนจ้ี ะแสดงใหเ้ ห็นมุมมองความ ตอ้ งการของระบบในดา้ นบนสุด ความสัมพนั ธท์ เ่ี ปน็ อิสระต่อกนั แลกระบวนการทำงานทีซ่ ับซอ้ น ซ่ึงจะ ทำให้การจดั การกับการเปล่ียนแปลงในระดับโครงสร้างสามารถทำได้งา่ ย มีความยืดหยุ่น จึงเหมาะกับ ระบบท่ีมีขนาดใหญ่ เพราะการปรบั เปลย่ี นหรอื การพฒั นาระบบไม่จำเปน็ ต้องลงไปแก้ไขในระดับ รายละเอยี ด ทำใหก้ ารพฒั นาระบบมีความรวดเรว็ มากยิง่ ข้ึน 1.4 Composite Structure Diagram เป็นแผนภาพแสดงใหเ้ ห็นรายละเอียดและ ความสมั พนั ธท์ ี่เกดิ ขน้ึ ในคลาสและจุดท่มี สี ่วนโต้ตอบระหว่างองค์ประกอบเหล่านี้กบั สว่ นอ่นื ๆ ของระบบ รูปภาพแสดง “Composite Structure Diagram”

64 สำหรบั Composite Structure Diagram มีองค์ประกอบ ท้งั หมด 5 สว่ น ➢ สว่ นท่ี 1 Part/Property คือ องค์ประกอบทอ่ี ยู่ใน Class โดยแตล่ ะคลาสสามารถมไี ด้มากกวา่ 1 Part ตวั อย่างเช่น จากรูป จะเห็นว่า Class FibonacciSystem มี Part ท้งั หมด 5 Part คอื FibonacciSystem, Nminus 2, Nminus , N, Viewer ➢ สว่ นท่ี 2 Part คือ จดุ เช่อื มต่อระหวา่ ง Port กบั Port หรอื Port กบั Environment สญั ลักษณ์กจ็ ะเป็น รูปส่เี หลีย่ มจัตรุ ัส วางไว้บนกรอบของ Class ➢ สว่ นที่ 3 Connector คือ เส้นตรงท่ีทำหน้าทเี่ ช่อื มต่อระหวา่ ง Port กบั Port หรือ Part กับ Environment ➢ สว่ นที่ 4 Collaboraration คอื ส่วนท่ที ำหนา้ ทร่ี วบรวม Operation/Function ท่อี ยูใ่ น Class อื่นๆ มา ไวใ้ นตวั ของมัน ➢ ส่วนท่ี 5 Structure Classifier ก็คือ Class ท่ียอมให้ส่สี ่วนแรกดังข้างต้น สามารถมาอยู่รวมกันใน Class ได้ ตัวอย่างเชน่ จากรปู Class Fibonacci System กค็ ือ Structure Classifierน่ันเอง ➢ ส่วนที่ 6 Encapsulated Classifier ก็คือ Structure classifier ชนิดหน่ึงทตี่ ้องมี Ports อยู่ภายใน Class จากตัวอย่างกจ็ ะเห็นว่า ท้งั Class Variable และ Fibonacci System ตา่ งก็เป็น Encapsulated classifier เพราะว่าท้งั 2 class มี Port อยู่ภายในน้ันเอง 1.5 Component Diagram เปน็ แผนภาพทีจ่ ำลองลักษณะทางกายภาพของระบบเชงิ วัตถุ โดยจะ แสดงใหเ้ ห็นส่วนประกบของซอฟต์แวร์ ซง่ึ เรียกสนั้ ๆ ว่า“Component” ตา่ ง ๆ ของระบบ มีประโยชนส์ ำคัญ คอื การแบ่งระบบงานให้เปน็ ระบบย่อยต่าง ๆ ทำให้การทำงานของระบบมีประสิทธิภาพและสนบั สนุนหลกั การ พฒั นาระบบงานแบบเปน็ ทีมงานทแ่ี ตล่ ะสว่ นสามารถรับผิดชอบงานของตนเองได้

65 1.6 Deploy Diagram เปน็ แผนภาพ แสดงสถาปตั ยกรรมของระบบ ทั้งฮารด์ แวรแ์ ละซอฟต์แวร์ และการเชื่อมต่อระหว่างระบบย่อยอ่ืน ๆ โดยแบง่ องค์ประกอบหลักเปน็ 2 ส่วน คือ • Software • Hardware รูปภาพแสดง “Deploy Diagram”

66 2. แผนภาพอธิบายพฤติกรรมของระบบ (Behavior Model) เป็นโมเดลที่แสดงใหเ้ ห็นถึงพฤตกิ รรม ของระบบท่ีมกี ารเปลีย่ นแปลงเมอ่ื เกดิ เหตุการณ์ใด ๆ ขึ้น และแสดงให้เห็นถึงความสามารถของระบบทดี่ ำเนินใน หนา้ ที่บางอย่างได้ ได้แก่ 2.1 Use Case Diagram เปน็ แผนภาพแสดงฟงั กช์ ันการทำงานหรือบริการของระบบ และ แสดงปฏสิ มั พันธ์ระหว่างระบบกับสง่ิ แวดล้อม รปู ภาพแสดง Use Case Diagram ระบบห้องสมดุ 2.2 Activity Diagram เป็นแผนภาพแสดงกระบวนการทางธุรกิจท่อี ยู่ในขอบเขตของระบบ รวมทั้งการไหลของข้อมูลและตรรกะในระบบ ลักษณะของแผนภาพจะคล้ายกบั ผงั งาน(Flowchart) รูปภาพ แสดง Activity Diagram

67 2.3 State Diagram เปน็ แผนภาพแสดงสถานะตา่ ง ๆของออบเจ็กต์ และการเปลีย่ นสถานะ ของออบเจก็ ต์ เมื่อมเี หตุการณ์มากระทบ หรือเมื่อออบเจ็กตน์ ้นั ถูกส่ังให้ทำงานอยา่ งใดอยา่ งหนึ่ง รปู ภาพ แสดง State Diagram 2.4 Sequence Diagram เปน็ แผนภาพแสดงลำดบั การโต้ตอบกันระหวา่ งออบเจ็กต์ เพื่อ ตอบสนองการส่งั งานของผใู้ ชร้ ะบบตามลำดบั ของเวลาทเ่ี กิดเหตุการณ์ โดยจะมีสัญลักษณ์แสดงให้เห็น ลำดับการสง่ Message ตามเวลาส่งอยา่ งชดั เจน รูปภาพ แสดง Sequence Diagram

68 2.5 Interaction Diagram เป็นแผนภาพแสดงภาพรวมของกระบวนการธรุ กจิ เหมือนกบั Activity Diagram ซ่ึงจะอธบิ ายการโต้ตอบระหว่างองคป์ ระกอบตา่ ง ๆ ในแบบจำลอง รปู ภาพ แสดง Interaction Diagram

69 หนว่ ยท่ี 6 หลกั การของ UML สาระการเรียนรู้ 1. หลักการของ UML Modeling 2. ประโยชน์ของ UML Modeling 3. องคป์ ระกอบของ UML 4. องคป์ ระกอบของ UML แบบ Class Diagram 5. องคป์ ระกอบของ UML แบบ Use Case Diagram จุดประสงค์การเรียนรู้ 1. เพ่ือใหเ้ ขา้ ใจหลกั การของ UML Modeling และองค์ประกอบของ UML 2. เพอื่ ให้เขา้ ใจแนวคิดเชงิ วตั ถุโดยการใช้ภาษา UML 3. เพือ่ ให้เขา้ ใจแนวการออกแบบแผนภาพแบบ Class Diagram 4. เพอ่ื ให้เข้าใจแนวการออกแบบแผนภาพแบบ Use Case Diagram 5. เพื่อให้ทกั ษะคตทิ ี่ดีในการปฏิบตั ิงานด้วยความรบั ผิดชอบ ซอ้ื สัตย์ ละเอยี ด รอบคอบ สมรรถนะประจำหน่วย 1. แสดงความรูเ้ ก่ยี วกบั หลกั การของ UML Modeling 2. แสดงความรู้เกยี่ วกับแผนภาพ Class Diagram 3. แสดงความรู้เกย่ี วกบั แผนภาพ Use Cass Diagram 4. ปฏิบัตอิ อกแบบโมเดลมาตรฐานด้วยภาษา UML

70 หลักการของ UML Modeling ภาษายูเอ็มแอล (Unified Modeling Language: UML) คือ ภาษาโมเดลในรูปแบบแผนภาพ (Graphic Model) ใช้สำหรับสร้างตัวแบบเชิงวัตถุ ซึ่งเกิดขึ้นจากการนำแนววิธีปฏิบัติในการพัฒนาระบบเชิงวัตถุของ ศาสตราจารย์ทัง้ 3 ท่าน ประกอบด้วย James Rumbaugh, Grady Booch และ Ivar Jacobson ที่มีข้อดีข้อเสีย และข้อแตกต่างมา ประยุกต์รวมกัน โดยมีวัตถุประสงค์ภาษายูเอ็มแอลเพื่อให้เป็นระเบียบวิธีปฏิบัติในการพัฒนา ระบบเชิงวัตถุที่เป็นมาตรฐานเดียวกันในระดับสากล เรียกว่า “Unified Method” มีการพัฒนามา อย่างต่อเนื่อง จนกระทง่ั กลายมาเปน็ “UML” และได้รบั การรับรองจากหน่วยงานท่ที ำหน้าท่ีดูแลและควบคุมเทคโนโลยีเชิงวัตถุ (Object Management Group : OMG) ให้เป็น มาตรฐานในการสร้างแบบจำลองเชิงวัตถุ ซึ่งภาษา UML มี จุดประสงคห์ ลัก 4 ขอ้ คอื 1. จำลองด้วยภาพ (Visualizing) 2. แสดงการกำหนด (Specifying) 3. ชว่ ยสร้างระบบ (Constructing) 4. ชว่ ยบันทึก (Documenting) โมเดลมาตรฐานของ MLU 1. Class Diagram แสดงถงึ Class และความสมั พันธ์ของข้อมูลและกจิ กรรมทมี่ ีผลกับข้อมูลในแตล่ ะ Class 2. Use case Diagram แสดงการใช้งานระบบจากมมุ มอง ของผู้ใช้ 3. Sequence Diagram แสดงลำดบั ข้ันตอนการทำงานภายในของ Use case Diagram 4. Activity Diagram แสดงถึง กระแสการไหลของ การทำงานในระบบ ( Work Flow ) 5. Collaboration Diagram แสดงถงึ การติดต่อส่ือสาร และความสมั พันธ์ระหวา่ ง Object 6. Component Diagram แสดงถงึ โครงสรา้ งทาง กายภาพของ Component ต่างๆ ในระบบ 7. Deployment Diagram แสดงถึง สถาปตั ยกรรม ของระบบ Hardware/Software 8. Object Diagram แสดงถึงความสมั พันธ์ และ Instance ของ Class และ Object 9. State Diagram แสดงถงึ สถานภาพ และ พฤตกิ รรม ของ Object

71 รปู ภาพ แสดงโมเดลมาตรฐานของ UML ประโยชนข์ อง UML Advantage 1. วงจรการพฒั นาที่สนั้ ทีส่ ดุ (Shortest Development life cycle) 2. เพม่ิ ผลผลิต (Increase productivity) 3. ปรบั ปรงุ คุณภาพซอฟต์แวร์ (Improve software quality) 4. สนับสนนุ ระบบสบื ทอดมรดก (Support legacy system) 5. ปรบั ปรงุ การเชอ่ื มตอ่ ทมี งาน (Improve team connectivity)

72 องคป์ ระกอบ UML ภาษายูเอ็มแอล แบ่งองค์ประกอบออกเป็น 3 สว่ น คือ 1. สญั ลกั ษณ์ทั่วไป (Things) คือ สัญลักษณ์พื้นฐานท่ใี ชใ้ นการออกแบบไดอะแกรมต่าง ๆ แบง่ ออกเป็น หมวดหม่ยู ่อย ๆ ประกอบด้วย - หมวดโครงสร้าง (Structure) - หมวดพฤตกิ รรม (Behavior) - หมวดจัดกลุม่ (Grouping) - หมวดคำอธบิ ายประกอบ (Annotational) 2.ความสมั พันธ์ (Relationships) แบ่งออกเปน็ - ความสัมพันธแ์ บบพง่ึ พา (Dependency Relationship) - ความสัมพันธแ์ บบเกี่ยวพันธ์ (Association Relationship - ความสมั พนั ธไ์ ม่เจาะจง หรือความสัมพันธแ์ บบสบื ทอดคุณสมบัติ (Generalization Relationship) 3. แผนภาพหรือไดอะแกรม (Diagram) ได้แก่ โมเดลมาตรฐานต่างๆ ได้แก่ Class Diagram, Use Case Diagram, Activity Diagram ฯลฯ สำหรับหนว่ ยการเรียนรูน้ ี้ จะขอกล่าวถึงองคป์ ระกอบของ UML ที่เป็นแบบมาตรฐาน 2 โมเดลคือ Class Diagram และ Use Case Diagram องคป์ ระกอบ UML แบบ Class Diagram แผนภาพภาพคลาส คือ โมเดลท่แี สดงความสัมพนั ธ์ของกล่มุ ออบเจ็กต์ท่ีอย่รู วมกนั มลี ักษณะมุมมอง เน้นโครงสร้างเชิงวัตถุ ซ่งึ เรยี กวา่ “Logical View” โดยจะอธิบายความสมั พันธร์ ะหวา่ ง คลาส คุณลกั ษณะ (Attribute) และวิธีการประมวลผล (Operation) ของคลาสน้ัน ๆ แบง่ อง๕ประกอบออกเป็น 3 สว่ น

73 - ClassName - Attribute - Operation/Method Class Name (คลาส) เปน็ คํานาม พยญั ชนะตัวแรกเป็นตัวใหญ่หาก มี 2 คาํ ต้องขึน้ ตน้ ดว้ ยพยญั ชนะ ตวั พมิ พ์ใหญ่ ไม่เวน้ ชอ่ งว่าง ชอ่ื คลาสจะเปน็ ตัวหนา ส่วนชอ่ื ออบเจก็ ตจ์ ะข้นึ ตน้ ดว้ ยพยัญชนะ ตัวพิมพ์เลก็ Attibute(แอตทริบิวต์) เปน็ คุณลักษณะทต่ี ้องการในคลาสนั้นๆ ใชเ้ ปน็ ตัวพิมพเ์ ลก็ ถ้ามี 2 คาํ พยัญชนะ ตวั แรกของคําท่สี องต้องเป็น พยญั ชนะตัวพิมพ์ใหญ่ โดยมีส่วนประกอบ 3 สว่ นคือ Visibility Name : Type

74 สว่ นประกอบของแอตทริบิวต์ Visibility : ระดบั ในการมองเห็นรายละเอียดต่างๆ ของ Class จากภายนอก Name : นอกช่ือแอตทรบิ วิ ต์ ตามด้วยเครอ่ื งหมายโคลอน(:) Type : ชนดิ ของแอตทริบวิ ต์ จะอยตู่ ่อจากเครื่องหมายโคลอน (:) ขน้ึ ตน้ ด้วยตัวพิมพใ์ หญ่ แบง่ ออกเป็น 2 ชนิด คือ Primittive Type และ Class Type Operation/Method (โอเปอร์เรชนั /เมธทอด) คือ กจิ กรรมที่สามารถดำเนินการกบั ออบเจ็กต์นัน้ ๆ ได้ โดย ตอ้ งขนึ้ ตน้ ด้วยคาํ ว่า Visibility และตามดว้ ยสว่ นประกอบอนื่ ๆ ดังน้ี Visibility Method-name (parameter :Type) : return-type-expression แผนภาพยสู เคส คือ เปน็ แผนภาพทีแ่ สดงให้ทราบว่า ระบบมีการทำงานหรอื มีหน้าที่ใดบ้าง ซึ่งจะเกิดขึ้น หลงั จากท่ี วิเคราะห์ท่ปี ระกอบเจ็กตท์ ีป่ ระกอบกนั เปน็ ระบบแลว้ นั่นก็คอื ได้ Class Diagram มาเรียบรอ้ ยแล้ว นั้นเอง สำหรบั วัตถปุ ระสงค์ สำคัญของแผนภาพยูสเคส คือ 1. อธิบายขอบเขตของส่ิงท่ีระบบตอ้ งการ หรอื เรียกว่า Problem Domain ซึ่งจะได้มาจากการ สํารวจความต้องการของผใู้ ชง้ านระบบ (Requirement) 2. บอกสว่ นประกอบตา่ ง ๆ ของระบบท่ีกําลงั ศกึ ษา 3. บอกความสัมพนั ธ์ของส่วนประกอบตา่ ง ๆ ในระบบท่ี กําลังศึกษา

75 ประโยชนข์ อง Use Case Diagram 1. เป็นแผนภาพพนื้ ฐานทส่ี ามารถอธบิ ายสงิ่ ต่างๆ ไดโ้ ดยใช้รูปภาพที่ ไม่ซบั ซอ้ น 2. ช่วยให้ผ้พู ัฒนาระบบสามารถแยกแยะกิจกรรมท่ีอาจเกดิ ขึ้นในระบบ 3. ทราบความสามารถของระบบ 4. ทราบผใู้ ชง้ านในแตล่ ะส่วนของระบบ 5. งา่ ยต่อการส่ือสารระหวา่ งลูกคา้ และผู้พฒั นาระบบ 6. ใช้ทดสอบระบบว่าตรงตามความตอ้ งการของระบบหรอื ไม่ รปู ภาพ แสดงตัวอยา่ งแผนภาพ Use Case Diagram

76 องค์ประกอบของ Use Case Diagram แบง่ ออกเป็น 3 ส่วน คอื Actor , Use Case, Relation - Actor คือ ผูท้ กี่ ระทำกับระบบ อาจเป็นผสู้ ่งข้อมลู ผู้รบั ข้อมูล หรือแลกเปลี่ยนข้อมลู กับระบบ น้ัน ๆ ซ่งึ อาจจะเป็นมนษุ ย์ หนว่ ยงาน หรอื ระบบท่ีเก่ียวข้องกไ็ ด้ แบ่งออกเป็น 2 ประเภท คือ 1. Primary Action 2. Stakeholder Action -Use Case คือหนา้ ท่ีหรอื งานต่างๆ ในระบบ ใชส้ ัญลกั ษณ์ เปน็ รปู วงรี ภายในเขยี นช่ือของ Use Case โดยใช้เป็น คำกริยา หรอื กริยาวลีทีต่ ้องมีกรรมมารองรับ เช่นการเช็คยอดสนิ ค้า การตรวจสอบ สถานะห้องพัก การลงทะเบียนเรยี น เป็นตน้ -Relation คือความสมั พนั ธ์ท่เี กดิ ขนึ้ ระหว่าง Use Case กบั Actor ซ่ึงใชเ้ ส้นตรง (Connection) เชอื่ มโยงระหวา่ งกนั แสดงใหเ้ ห็นความสัมพนั ธท์ ีเ่ กิดขน้ึ ทงั้ การรบั และส่ง Message ระหวา่ งกนั

77 ความสัมพันธ์ (Relation) แบ่งออกได้ 3 ประเภท คือ 1. ความสัมพนั ธ์ระหวา่ ง Use Case กับ Actor เป็น ความสัมพันธแ์ บบทิศทางเดยี ว 2. ความสัมพันธ์ระหวา่ ง Actor กับ Actor เปน็ ความสมั พนั ธ์แบบทิศทางเดยี ว 3. ความสัมพนั ธ์ระหวา่ ง Use Case กบั Use Caseเปน็ ความสัมพันธ์แบบทิศทางเดียว ขอ้ แนะนำในการสรา้ ง Use Case Diagram 1. แผนภาพ Use Case Diagram เป็นเครอื่ งมือใช้อธิบายให้ เหน็ ถึงความต้องการของระบบเทา่ น้นั 2. แผนภาพ Use Case Diagram อาจจะมีความละเอยี ดในเชิงลกึ ทแ่ี ตกต่างกันอกไป ขึ้นอยูก่ บั มมุ มอง ประสบการณ์ เทคนคิ และ ความเช่ยี วชาญในการวิเคราะห์ความตอ้ งการของระบบ ดงั นน้ั จึงไม่มขี ้อสรุปทแี่ นน่ อนวา่ Use Case Diagram ควรมคี วามละเอียดมากน้อยเพยี งใด 3. แผนภาพ Use Case Diagram มวี ัตถุประสงค์หลกั เพื่อการสอ่ื สารระหวา่ ง ทมี งานกับผใู้ ชใ้ หม้ ี ความเข้าใจท่ตี รงกนั ในมมุ กว้าง ไม่ไชแ่ ผนภาพทใ่ี ช้สอ่ื สารกบั โปรแกรมเมอร์ (Programmer) ดังนน้ั Use Case Diagramจึงควรทำให้ผใู้ ช้และทมี งานเห็นภาพรวมในการทำงานของระบบให้ มากท่สี ดุ และตอบสนองความต้องการของผู้ใช้ได้อยา่ ครบถ้วนตามขอบเขตของงาน 4. แผนภาพ Use Case Diagram ไม่มีหน้าทใ่ี ห้เหน็ ระดับการ ทำงานในระบบการจัดการฐานข้อมูล เชน่ การเพ่ิม การลบ หรือการปรับปรุงข้อมูล เป็นต้น เพราะหน้าทเ่ี หลา่ นีเ้ ป็นบทบาทพน้ื ฐานใน การจัดการขอ้ มูลอยแู่ ลว้ จงึ ไมต่ อ้ งนำมาแสดงใหเ้ หน็ ใน Use Case Diagram 5. แผนภาพ Use Case Diagram ควรนําเสนอหน้าทหี่ รือ บทบาทหลกั ทีเ่ ป็นจดุ เด่นของระบบ ท่ี ผใู้ ช้ต้องการให้ระบบ ทำงานไดอ้ ยา่ งแท้จริงเท่านัน้

78 หน่วยที่ 7 การวเิ คราะหแ์ ละการออกแบบโปรแกรมทางธรุ กิจ สาระการเรียนรู้ 1. การวเิ คราะห์และออกแบบโปรแกรมทางธุรกจิ 2. การวิเคราะห์และออกแบบโปรแกรมด้วยClass Diagram 3. การวเิ คราะห์และออกแบบโปรแกรมด้วย Use Case Diagram 4. การเขียนคำอธิบาย Use Case 5.การบรหิ ารโครงการ 5. เทคนิคการบริหารโครงการ 6. เทคนคิ การบริหารงบประมาณของโครงการ 8.การวิเคราะห์ผลตอบแทนในการลงทนุ 7. การวเิ คราะห์กระแสเงินสด จดุ ประสงค์เรียนรู้ 1. เพ่ือมที กั ษะในการวเิ คราะหแ์ ละออกแบบเชิงวัตถุ 2. เพอื่ มีทกั ษะในการออกแบบโปรแกรมทางธรุ กจิ 3. เพื่อใหม้ ีเจตคติ และกิจนิสัยท่ีดีในการปฏบิ ัติงานด้วยความรับผดิ ชอบ ซอ่ื สตั ย์ ละเอียด รอบคอบ สมรรถนะประจำหน่วย 1. แสดงความร้เู ก่ียวกบั เทคนิคการบรหิ ารโครงการ 2. ปฏบิ ตั กิ ารออกแบบโปรแกรมทางธุรกิจโดยใช้หลกั การของ UML 3. ปฏบิ ตั ิงานดว้ ยความรอบคอบ มเี จตคตทิ ่ีดีในการทำงานดว้ ยความรับผดิ ชอบ ซือ่ สัตย์

79 การวเิ คราะหแ์ ละออกแบบโปรแกรมทางธรุ กจิ การวเิ คราะหแ์ ละออกแบบโปรแกรมทางธรุ กจิ หมายถงึ กระบวนการพัฒนาระบบเทคโนโลยีสารสนเทศใน หน่วยงานของภาคธุรกิจโดยมุ่งแสวงหาผลประโยชน์ จากการลงทุนในการพัฒนาระบบทั้งทางตรง ( Tangible) และทางอ้อม (Intangible) ซึ่งนักวิเคราะห์ระบบจะต้องเข้าใจบริบทและวัตถุประสงค์ในการวิเคราะห์และ ออกแบบระบบอย่างชัดเจนจากการสืบค้นความต้องการของผู้ใช้ผ่านเครื่องมือต่าง ๆ เช่น การสัมภาษณ์ (Interview) การสังเกตุ (Observation) การแจกแบบสอบถาม (Questionnaire) เปน็ ตน้ การวเิ คราะหแ์ ละออกแบบโปรแกรมทางธุรกจิ การวิเคราะห์และออกแบบโปรแกรมทางธรุ กจิ • ผลตอบแทนทางตรง (Tangible) คือ ผลตอบแทนที่สามารถวัดผลในเชิงสถิติ หรือตัวเลขได้ เช่น ผลตอบแทนจากการลงทุน กำไรที่ได้รับ จำนวนสินค้าที่ผลิตได้ ยอดขายสินค้า ระยะเวลาในการผลิต ต้นทนุ ท่ลี ดหรือเพม่ิ ข้นึ ความรวดเรว็ และความถูกตอ้ งแมน่ ยำของระบบ เปน็ ตน้ • ผลตอบแทนทางอ้อม (Intangible) คือ ผลตอบแทนที่ไม่สามารถวัดผลเชิงสถิติ หรือตัวเลขได้ เช่น ความ พงึ พอใจของผใู้ ช้บรกิ ารหรอื ลกู ค้า ความพึงพอใจของ ผใู้ ช้ระบบ ภาพลกั ษณ์ขององคก์ รภาคธรุ กิจ เปน็ ต้น

80 การวิเคราะห์และออกแบบโปรแกรมด้วย Class Diagram ขน้ั ตอนท่ี 1 กำหนดออบเจก็ ตแ์ ละสร้างคลาสของออบเจ็กต์เหลา่ นน้ั การกำหนดออปเจ็กตจ์ ะสร้างขอบเขตของระบบซง่ึ เกดิ จากปัญหาและความต้องการของระบบเป็นคำนาม ไม่ซำ้ ซ้อน และต้องสามารถกำหนดแอตทรบิ ิวตไ์ ด้ ขัน้ ตอนที่ 2 กำหนดแอทริบิวต์ (Attribute) ให้กบั คลาสเปน็ การกำหนดคุณลกั ษณะเฉพาะให้กับออบเจ็กตต์ า่ ง ๆ ท่ีอยู่ในคลาส โดยคณุ ลกั ษณะหรือ แอตทิบวิ ต์ท่ีจะกำหนดต้องตรงกบั ความต้องการของระบบเทา่ นั้น 1. Primary Key: มคี ่าไมซ่ ำ้ กัน 2. Multi-Value Attribute: มีคา่ ข้อมลู มากกว่า 1 3. Derived Attribute: มีคา่ การคํานวณ 4. Composite Attribute: แตกย่อยได้ อาจแยก ออกเปน็ อกี 1 คลาสได้

81 ขัน้ ตอนที่ 3 พัฒนาดิกชนั นารีข้อมูล ขนั้ ตอนนเี้ ปน็ การเขยี นอธิบายข้อมลู ของคลาสโดยอาจเขยี นเปน็ รปู แบบย่อ ๆ ไม่เป็นทางการเป็นการ อธิบาย ช่อื ขอบเขต บทบาท และแอตทริบวิ ตข์ องคลาส Customer: ลกู ค้าทีเ่ ขา้ มาเช่าพื้นทขี่ ายสนิ คา้ ซ่งึ จะมกี ารบนั ทกึ รหสั ลูกค้า ชื่อลูกคา้ ท่ีอยู่ และ เบอร์ Area: โทรศพั ท์ Leasing: เป็นพื้นทที่ ี่ใหบ้ ริการเชา่ กับลกู คา้ จะบนั ทึกขอ้ มลู หมายเลขพืน้ ที่ ขนาดพ้นื ที่ ประเภท Payment: การเชา่ แบบรายวนั รายเดือน หรอื รายปี และอัตราคา่ เช่าในแตล่ ะประเภท Income: สัญญาเช่าพน้ื ท่ีท่ีกาํ กับลูกค้า เกบ็ ข้อมูล เลขทีเ่ ช่าสญั ญาเช่า วนั ที่ทําสัญญา รหสั ลกู ค้า ทที่ าํ สญั ญา และประเภทของสัญญาเป็นแบบรายวัน รายเดือน หรอื รายปี การชําระเงิน เก็บข้อมลู การชําระเงินคา่ เช่าพ้นื ท่ีของลูกคา้ ได้แก่ เลขท่กี ารชําระเงิน วันที่ชําระเงนิ รหัสลกู ค้าท่ชี าํ ระเงิน ยอดชําระเงนิ รายได้เปน็ การสรปุ ขอ้ มูลจากการขาํ ระเงิน ซึง่ จะเกบ็ ข้อมูลเลขท่ีใบสรปุ รายได้ วันท่ี สรปุ รายได้ ยอดรายได้รวมซ่งึ ไดม้ าจากข้อมูลการชาํ ระเงนิ ขั้นตอนที่ 4 กาํ หนดโอเปอเรชนั ให้กบั คลาส ขัน้ ตอน 1-3 เปน็ การกาํ หนดแอตทริบิวต์ที่เก่ียวข้องกบั ความตอ้ งการของระบบซึง่ จะเน้นไปทข่ี ้อมลู ตาม ขอบเขตของปัญหาทกี่ ําหนดไว้ ซ่งึ เปน็ สว่ นหน่งึ เท่าน้ัน ในความเปน็ จรงิ ยงั ต้องพจิ ารณาโอเปอร์เรชันท่เี ก่ียวข้องกับ คลาสน้นั ๆ ด้วย ขน้ั ตอนที่ 5 กําหนดความสัมพันธร์ ะหวา่ งคลาส ระบบสารสนเทศประกอบด้วยคลาสต่าง ๆ เปน็ จํานวนมากซึง่ มีหนา้ ท่ีต่างกันไปการประสานงานจะต้อง กําหนดรูปแบบท่ีชัดเจนและใชเ้ ส้นตรงลากเชอื่ มระหว่างคลาสบนเส้นอาจระบุ การวเิ คราะห์และออกแบบโปรแกรมทางธรุ กจิ 1. Associations Name เป็นความสัมพันธแ์ บบทวั่ ไปท่ีไม่กําหนดผลของการการสืบทอด 2. Navigation ทิศทางความสัมพันธโ์ ดยหวั ลูกศรแสดงให้เหน็ ความสามารถของออบเจก็ ตข์ องคลาสหนงึ่ สามารถเขา้ ถึงออบเจ็กตข์ องอกี คลาสหนึง่ ได้อยา่ งไรกรณีมีหวั ลูกศรทศิ ทางเดยี วจะ เรยี กว่า “UnidirectionAssociation” แต่ถ้ามีหวั ลกู ศร 2 ดา้ นหรือไม่มีเลยจะเรียกว่า “Bidirection Association”

82 การวเิ คราะห์และออกแบบโปรแกรมทางธุรกจิ จาํ นวนสมาชกิ ทมี่ ีอยู่ในความสัมพันธ์(Multiplicity) ความสมั พันธ์ทเี กดิ ข้ึนระหว่างคลาสจําเป็นต้องกําหนดจาํ นวนสมาชกิ ทม่ี อี ยู่ในความสัมพันธ์ นัน่ ๆ โดย ตัวเลขทีปลายสดุ ของคลาสฝ่ังตรงกนั ขา้ มจะใช้บอกจาํ นวนของความสมั พันธ์ของคลาสท่ี อยู่อีกฝงั่ หนง่ึ

83 ความสมั พันธ์ระหวา่ งคลาสแบง่ ออกได้หลายรูปแบบดงั นี้ 1. Associations เป็นความสัมพนั ธแ์ บบท่ัวไปทีได้กําหนดผลของการสืบทอดและการเป็นส่วนหนึง่ ของ คลาสที่สมั พันธก์ นั เป็นความสัมพนั ธใ์ นระดับชนั เดียวกนั 2. Generalizations เปน็ ความสมั พนั ธเ์ ชงิ โครงสรา้ ง แสดงใหเ้ ห็นความสัมพนั ธร์ ะหวา่ งออบเจ็กต์หรือ คลาส ในลกั ษณะของการสบื ทอดคุณสมบตั จิ ากคลาสหนึ่ง(Superclass) ไปยงั อีกคลาสหน่งึ (Subclass) ซงึ เป็น แนวคิดเชิงวัตถุ อาจใช้กําหนดความสัมพันธแ์ บบหนงึ่ ตอ่ กลมุ่ (One to Money) หรอื หน่งึ ต่อหน่ึง (One to One) หรอื อาจใช้เพ่ือแสดงความสมั พนั ธร์ ะหว่างออกเจก็ ต์ได้

84 การสบื ทอดคณุ สมบัติ แบง่ ไดอ้ อกเป็น 2 ประเภท คือ 1. Single Inheritance สบื ทอดคณุ สมบตั ิจาก Superclass 1 คลาส 2. Multiple Inheritance สบื ทอดคุณสมบัตจิ าก Superclass มากกวา่ 1 คลาส 3. Aggregation เป็นแผนภาพแสดงความสัมพนั ธ์ของวัตถุท้ังหมดกบั วัตถุบางส่วน ซงึ แตกตา่ งจากแนวคดิ การสบื ทอดคุณสมบตั ิโดยจะพจิ ารณาว่าคลาสหนงึ่ ๆ สามารถแยกออกเปน็ คลาสย่อย ๆ ไดก้ ่ีคลาสซึ่ง เรียกวิธกี ารแบ่งคลาสแบบน้ีว่า “Whole-Part Relationship”หรือ “Is Part Of” โดยจะมคี ลาสทีใหญท่ ี สดุ ทเี ปน็ ออบเจก็ ตห์ ลักและมีคลาสอน่ื เปน็ ส่วนประกอบ

85 การวเิ คราะห์และออกแบบโปรแกรมดว้ ย Use Case Diagram ข้ันตอนท่ี 1 ขัน้ สร้าง Use Case Diagram ข้ันนีจ้ ะวิเคราะห์หาขอบเขตของระบบ (Problem Domain) ซงึ่ ประกอบดว้ ย 1. ค้นหา Actor 2. ค้นหา Use Case ที่มปี ฏสิ มั พนั ธก์ บั Actor นั้นโดยตรง 3. ตอ้ งไม่มี Actor ใดเลยที่ไม่มีปฏสิ มั พันธ์กับ Use Case 4. ต้องไม่มี Use Case ใดเลยที่ไม่มปี ฏสิ มั พนั ธ์กับActor ➢ การค้นหาActor สามารถคน้ หาจากผใู้ ชร้ ะบบท้ังหมด(User) โดยพิจารณาบทบาทของผู้ใช้แตล่ ะกล่มุ ซง่ึ ตวั อยา่ งคําถาม ดงั กล่าวมีดงั น้ี ? ใครเปน็ ผูใ้ ชห้ ลกั ของระบบ ? ใครเป็นผู้ดแู ลระบบ ? ใครหรอื หนว่ ยงานไหนท่ตี ้องแลกเปลีย่ นขอ้ มูล หรอื รับข่าวสารจากระบบ ? ใครที่ต้องการผลลพั ธจ์ ากระบบ ? อุปกรณ์ใดบ้างท่ีเกย่ี วขอ้ งกับระบบ ? ระบบใดบ้างท่ีปฏิสมั พันธ์หรือเก่ยี วข้องกบั ระบบ ➢ การคน้ หา Use Case เป็นการพจิ ารณาหนา้ ที่ของ Actor โดยหนงึ่ หนา้ ท่ีจะถือเป็นหน่งึ Use Case ถา้ Actor นนั้ มีหลายหนา้ ท่ี กย็ ่อมจะมี Use Case เพิม่ ข้ึนตามไปด้วยในกรณีท่ีทราบบทบาทและหน้าท่หี ลักของระบบอยแู่ ลว้ ซงึ่ สว่ นใหญจ่ ะ กําหนดไวเ้ ปน็ ขอบเขตของระบบกไ็ มจ่ ําเป็นตอ้ งคน้ หา Use Case จาก Actor ก็ได้ ใหน้ าํ หน้าทหี่ ลักของระบบมา ใชเ้ ป็น Use Case ได้เลยแล้วจงึ คน้ หาตอ่ วา่ Actor ใดที่ปฏสิ มั พนั ธก์ บั Use Case นั้นท้งั น้เี พอ่ื เปน็ การช่วยค้นหา Use Case ใหง้ า่ ยขึน้ อาจจะใชค้ าํ ถามเหล่าน้กี ็ได้ ? Actor ต้องการใหร้ ะบบทําหน้าที่อะไร ? Actor ตอ้ งการเพ่มิ ลบแก้ไขหรอื ปรบั ปรุงข้อมูลใด ๆ หรือไมอ่ ย่างไร ? หลงั จากระบบรับข้อมลู หรือเอกสารจาก Actor แลว้ ต้องการนาํ ไปใช้ทาํ อะไรต่อ ? สง่ิ ท่ี Actor ตอ้ งการจากระบบนัน้ คืออะไรและสงิ่ นนั้ เกิดจากหน้าทใ่ี ดของระบบ

86 ขนั้ ตอนท่ี 2 สรา้ ง Use Case Diagram ในระดบั System Requirement Model ขั้นตอนนจี้ ะ วิเคราะห์ถึงงานและหนา้ ทีข่ องระบบซ่งึ กค็ ือการพจิ ารณาหา Use Case และความสมั พันธ์ระหว่าง Use Case 1. คน้ หาและสรา้ งความสัมพันธ์ระหวา่ ง Use Case หรอื Actor(ถ้ามี) แลว้ เพิ่มเตมิ Use Caseใหมซ่ งึ่ อาจจะเป็นแบบ Include หรอื Extends 2. ตอ้ งไม่มี Actor ใดเลยท่ีไม่ปฏสิ มั พันธก์ ับ Use Case 3. ตอ้ งไม่มี Use Case ใดเลยทไี่ มป่ ฏิสมั พันธก์ บั Actor 4. Use Case ทกุ ตัวต้องมีปฏิสัมพันธอ์ ยา่ งใดอย่างหน่ึงกับ Actor หรือ Use Case ตวั อื่น ๆ 5. เขียนคําอธิบาย Use Case ทุกตัวจนครบถ้วน การเขียนคําอธบิ าย Use Case การไหลของเหตุการณ(์ Flow of Event) หรอื การสร้าง Use Case Description โดยมีสว่ นประกอบดงั น้ี การบริหารโครงการ การบริหารโครงการ หมายถึง กระบวนการวางแผนและควบคุมโครงการให้สําเร็จและบรรลุตาม วัตถปุ ระสงค์ของโครงการทีกาํ หนดไวอ้ ย่างมปี ระสิทธภิ าพและประสิทธิผลโดยอาศัยเครืองมือต่าง ๆ มาช่วยบรหิ าร จัดการ ซึงเครืองมือแต่ละชนิดมีข้อดีข้อเสียทีแตกต่างกันการเลือกเครื่องมือมาใช้ขึ้นอยู่กับลักษณะความซับซ้อ น ของโครงการซึ่งนักวเิ คราะหร์ ะบบจาํ เปน็ ต้องศึกษาเคร่ืองมือแต่ละชนิดให้ดีและเหมาะสมกับโครงการ และเหตุผล ทีก่ ารบริหารโครงการจะลม้ เหลวหรือประสบความสาํ เรจ็ ขน้ึ อย่กู ับสาเหตดุ ังนี้

87 สาเหตกุ ารบริหารโครงการล้มเหลว เทคนิคการบรหิ ารโครงการ เริม่ จากการพิจารณางบประมาณในแตล่ ะกจิ กรรมตรงตามวัตถปุ ระสงค์เพื่อบรรลเุ ปา้ หมายการจกั สรร ทรัพยากรและตารางการปฏบิ ัติงานต้องอาศยั เทคนิคการบริหารโครงการฯ • เทคนคิ การบริหารงบประมาณในโครงการ • เทคนิคการบริหารระยะเวลาในโครงการ • เทคนคิ การเร่งระยะเวลาของโครงการ

88 เทคนิคการบรหิ ารงบประมาณของโครงการ งบประมาณเป็นปัจจัยสําคัญในการพิจารณาว่าจะดําเนินโครงการนันต่อไปหรือไม่ มีผลกับการตัดสินใจ ของผู้อนุมัติโครงการทีจะพิจารณาถึงความคุ้มค่าในการลงทุนผลตอบแทนทีจะได้รับจากการลงทุนรวมถึงการ วิเคราะห์จุดคุ้มทุน (Break Event Point) ว่าเหมาะสมกับโครงการนั้น ๆ หรือไม่ หากประเมินงบประมาณ ผิดพลาดอาจส่งผลต่อการอนุมัติโครงการนั้น ๆ ไปโดยทันที่ซึ่งการ พิจารณาในขันตอนนี้ก็คือการศึกษาความ เปน็ ไปไดท้ างดา้ นเศรษฐศาสตร์ (Economical Feasibility) ดงั น้นั นกั วิเคราะหร์ ะบบจงึ ต้องมีการกําหนดแผนการ บริหารโครงการหรือการประมาณการงบประมาณทีสอดคล้องกับสภาพจริงมีการวิเคราะห์งบประมาณให้เห็นถึง ผลตอบแทนทีจะเกดิ ขึ้น การวิเคราะห์ผลตอบแทนในการลงทนุ ภายหลังจากวิเคราะห์ค่าใช้จ่ายหรือต้นทุนที่เกิดขึ้นจากการนําระบบใหม่เข้ามาใช้งานได้แล้วนั้นหากจะ วิเคราะห์ผลตอบแทนจากการลงทุนก็ต้องทําการเปรียบเทียบให้เห็นความแตกต่างระหว่างต้นทุนที่เกิดขึ้นของ ระบบปัจจบุ ันกบั ต้นทุนท่ีเกิดขึน้ ของระบบใหม่ว่ามีความแตกต่างกันมากน้อยเพียงใดซึง่ การเปรียบเทียบแบบน้จี ะ ทาํ ใหเ้ หน็ ถึงผลตอบแทนทเ่ี กดิ ขน้ึ จากการลงทุนว่าคุ้มคา่ กบั การลงทนุ หรือไม่

89 การวิเคราะหก์ ระแสเงนิ สด การวิเคราะหเ์ งินสด (Case Flow Analysis) คือ การเปรยี บเทยี บผลตอบแทนจากการลงทุน (Investment) กับต้นทุนทั้งหมด (Cost) เพ่ือหากระแสเงนิ สดและกระแสเงินสดในชว่ งระยะเวลานัน้ ๆ

90 หน่วยที่ 8 แผนภาพกระแสข้อมลู (DFD) สาระการเรียนรู้ 1. แผนภาพกระแสข้อมูล 2. ประโยชนข์ องแผนภาพกระแสข้อมลู 1. สญั ลกั ษณ์ที่ใชอ้ อกแบบแผนภาพกระแสขอ้ มูล 3. การเขยี นแผนภาพกระแสข้อมลู ทไี่ ม่ถกู ต้อง 4. ระดบั ชน้ั ของแผนภาพกระแสข้อมลู 5. แผนภาพบรบิ ท 6. แผนภาพกระแสข้อมลู ระดบั 0 7. แผนภาพกระแสข้อมลู ระดับล่าง 8. กรณีศึกษา จุดประสงค์การเรียนรู้ 1. เข้าใจหลกั การวเิ คราะห์ธรุ กิจด้วยแผนภาพกระแสขอ้ มูล 2. อธิบายขั้นตอนการวิเคราะห์ระบบด้วยแผนภาพกระแสขอ้ มูล 3. อธบิ ายขนั้ ตอนการทำงานของระบบด้วยแผนภาพกระแสข้อมลู 4. บอกหนา้ ทแ่ี ละความหมายของสัญลักษณ์ท่ีใชอ้ อกแบบแผนภาพกระแสขอ้ มูล สมรรถนะประจำหนว่ ย 1. แสดงความรูเ้ กี่ยวกบั หลักการออกแบบแผนภาพกระแสข้อมลู 2. วเิ คราะห์และออกแบบระบบงานธรุ กจิ ดว้ ยแผนภาพกระแสข้อมูล 3. มีกิจนสิ ัยในการทำงานดว้ ยความรอบคอบ และประณตี

91 แผนภาพกระแสข้อมลู แผนภาพกระแสข้อมูล (Data Flow Diagram : DFDs) หมายถึง แผนภาพทีอ่ ธบิ ายการโหลของข้อมลู ภายในระบบ เพื่อให้ทราบว่าข้อมูลนั้นมาจากไหน นำเข้ามาเพื่อทำอะไร มีใครที่เกี่ยวข้องบ้าง และจะนำข้อมูล เหล่านั้นไปจัดเก็บที่ไหน อย่างไร ซึ่งวิธีการเขียนแผนภาพกระแสข้อมูลก็เปรียบเสมือนแบบจำลองกระบวนการ (Process Model) ชนิดหนึ่งน่นั เอง ประโยชน์ของแผนภาพกระแสขอ้ มลู แผนภาพกระแสข้อมูลเปน็ เคร่ืองมือท่ใี ชจ้ ำลองกระบวนการของขอ้ มูลทเี่ กยี่ วข้องในระบบซงึ่ อธบิ ายการ ทำงานด้วยสญั ลกั ษณห์ รอื รูปภาพ มปี ระโยชนต์ อ่ การวเิ คราะหแ์ ละออกแบบระบบได้ ดังนี้ 1. เพอ่ื อธิบายใหผ้ ู้ที่ไม่มีความรทู้ างด้านคอมพิวเตอรเ์ ข้าใจขน้ั ตอนการทำงานไดอ้ ย่างง่าย 2. เพอ่ื ใชแ้ สดงทศิ ทางของข้อมูลและระบบย่อยตา่ ง ๆ 3. เพอ่ื ใชเ้ ป็นเครอ่ื งมือในการวเิ คราะหแ์ ละออกแบบระบบในอนาคตไดต้ ่อไป นอกจากนี้ประโยชนท์ เ่ี กิดข้นึ จากมุมมองของผู้ทเี่ กยี่ วข้อง อาจจะกำหนดได้ดังนี้ 1. มุมมองของลกู ค้า หรอื ผู้ใช้งาน จะใช้ DFD เพ่ือให้เหน็ ภาพรวมของระบบ 2. มุมมองของโปรแกรมเมอร์ จะใช้ DFD ในด้านการพัฒนาโปรแกรม และการกำหนดรายละเอยี ด ทเ่ี ก่ยี วข้อง 3. มมุ มองของนกั วิเคราะห์ จะใช้ DFD เพ่ือแสดงภาพรวมของระบบ และรายละเอยี ดท่เี กีย่ วข้อง ของระบบ รปู ตัวอยา่ งการใชแ้ ผนภาพกระแสข้อมูล

92 สญั ลักษณ์ทีใ่ ช้ออกแบบแพนภาพกระแสข้อมูล การออกแบบ DFD จะมีสัญลักษณ์ที่ใช้แบ่งออกเป็น 2 รูปแบบ คือ รูปแบบทฤษฎีของ Demarco & Yourdon และรูปแบบทฤษฎีของ Gane & Sarson ซึ่งบางสญั ลักษณเ์ หมือนกนั และบางสัญลักษณ์ไมเ่ หมือนกันแต่ ให้ความหมายหรือหน้าทข่ี องสัญลกั ษณน์ ัน้ 1 เหมอื นกัน ดังตาราง ตอ่ ไปน้ี Demarco & Gane & ช่อื สญั ลักษณ์ : ตัวอยา่ ง Yourdon Sarson ความหมาย (Yourdon) Process : การประมวลผล คอื ข้ันตอนการทำงาน การขาย ภายในระบบสารสนเทศ สินคา้ Data Store : แหลง่ จดั เก็บ สนิ ค้า ขอ้ มลู สามารถเปน็ ไดท้ ัง้ ไฟล์และฐานขอ้ มูล สนิ ค้า External Entity : แหล่งกำเนิดขอ้ มลู คอื ปัจจยั หรอื สภาพแวดลอ้ มที่ ใบเสร็จ เก่ยี วขอ้ งกบั ระบบ Data Flow: กระแสขอ้ มลู คือเสน้ ทาง การไหลของข้อมูลจากขั้นตอนหนง่ึ ไป ยังอกี ตอนหน่งึ เนอื่ งจากสญั ลักษณใ์ นการออกแบบ DFD มดี ้วยกนั 2 รูปแบบ ดังนนั้ เพื่อใหง้ ่ายต่อการทำใจ หนังสอื เล่มนี้ จงึ ขอใช้สัญลกั ษณ์การออกแบบ DFD ของ Gane & Sarson มาเปน็ แนวทางในการยกตัวอย่างแต่ละกรณี

93 1. Process : สัญลักษณ์ท่ีใช้แทนการประมวลผล หรืองานทท่ี ำโดยระบบคอมพวิ เตอร์การกำหนดช่ือของ Process ควรสื่อให้เห็นว่าขั้นตอนนี้ระบบต้องการทำงานเกี่ยวกับเรื่องอะไรโดยใช้ข้อความที่สั้นและกระฉับ อ่าน แล้วเข้าใจง่ายว่าขั้นตอนนี้ทำเกี่ยวกับเรื่องอะไรหรือเขียนให้อยู่ในรูปกิริยา เช่น การสมัครสมาชิก การชำระค่า สนิ ค้า การขายสินคา้ การทำบญั ชเี งินเดือน การสรุปผลรายงาน เป็นตน้ 2 .Data Store : สัญลักษณ์ที่ใช้แทนแหล่งเก็บข้อมูล ซึ่งต่อไปจะถูกนำไปพัฒนาขึ้นเป็นตาราง (Table) ในฐานข้อมูล การกำหนดชื่อจึงควรเป็นคำนามและสื่อให้รู้ว่าสัญลักษณ์นี้ใช้เก็บข้อมูลเกี่ยวกับเรื่องอะไร เช่น นกั ศกึ ษา อาจารย์ พนักงาน สมาชกิ ลกู ค้า รายการขายสนิ ค้า ตารางเวลาทำงาน บญั ชเี งินเดอื น เปน็ ตน้ 3. External Entity : สัญลักษณ์ที่ใช้แทนแหล่งกำเนิดหรือต้นทางของข้อมูล ซึ่งเป็นปัจจัยหรือ สภาพแวดล้อมท่ีเกี่ยวข้องกบั ระบบ ส่วนใหญ่จะกำหนดเปน็ ช่ือตวั บุคคล ชอื่ แผนก ช่อื หนว่ ยงานหรือชื่อระบบที่มา เชื่อมโยงก็ได้ เช่น ลูกค้า พนักงาน สมาชิก นักศึกษา ผู้ใช้งาน ผู้ดูแลระบบ ฝ่ายจัดซื้อ ฝ่ายบุคคล แผนกการคลัง ระบบธนาคาร เป็นตน้