การส่งเสริมการเรียนรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุ

บทที่ 1 บทนำ 1.1 ความเป็นมาและความสำคัญของปัญหา แนวความคิดในการเขียนโปรแกรมชิงวัตถุ (Object-Oriented Programming) เป็นการ เขียนโปรแกรมเป็นส่วนๆ และนำส่วนต่างๆ มาเชื่อมต่อกันแต่ละส่วนอธิบายได้ในเชิงวัตถุ ซึ่ง ประกอบไปด้วยกลุ่มข้อมูล (Attribute) และ พฤติกรรม (Behavior) และจากการพิจารณาทุกสิ่ง ทุกอย่างเป็นวัตถุ ซึ่งเป็นหลักการที่จะใกล้เคียงกับธรรมชาติของมนุษย์มาก จากแนวคิดดังกล่าวมี ผลให้เกิดการทำงานที่รวดเร็ว สามารถนำซอฟต์แวร์กลับมาใช้ใหม่ได้ หรือที่เรียกว่า ซอฟต์แวร์ รียูส (Software Reuse) การเปลี่ยนแปลงแก้ไขทำได้ง่าย มีผลิตผลและความน่าเชื่อถือ สูง และสามารถจะป้องกันการเกิดปัญหาวิกฤตซอฟต์แวร์ที่ประกอบไปด้วยปัญหาความซับซ้อน ของซอฟต์แวร์ ปัญหาการควบคุมเวลาและค่าใช้จ่ายในการพัฒนาซอฟต์แวร์ ปัญหาคุณภาพของ ซอฟต์แวร์ไม่ได้ตามที่ต้องการ จากแนวความคิดในการแก้ปัญหาของการเขียนโปรแกรมเชิงวัตถุที่พิจารณาถึงองค์ประกอบ ปัญหาและองค์ประกอบของปัญหา (Problem Space) ซึ่งแตกต่างจากแนวคิดในการแก้ปัญหาของ การเขียนโปรแกรมแบบเก่าที่ค้นหาวิธีการแก้ปัญหา (Solution Space) ผู้พัฒนาซอฟต์แวร์ที่ขาด ความรู้ความเข้าใจในแนวคิดการแก้ปัญหาแบบใหม่ และขาดทักษะ ความชำนาญในการพัฒนา ซอฟต์แวร์เชิงวัตถุ จะทำให้การพัฒนาซอฟต์แวร์มีผลิตผลและความน่าเชื่อถือต่ำ ผู้พัฒนาซอฟต์แวร์และผู้ที่สนใจเรียนรู้ ควรศึกษาทำความเข้าใจในแนวคิดการแก้ปัญหาของ การเขียนโปรแกรมเชิงวัตถุ และฝึกฝน พัฒนาทักษะและความชำนาญในการเขียนโปรแกรมเชิง วัตถุเพื่อสามารถพัฒนาซอฟต์แวร์ที่มีผลิตผลและความน่าเชื่อถือต่อไปได้ โดยควรมีสื่อที่น่าสนใจ นำเสนอข้อมูลและให้ผู้ใช้ได้ฝึกฝน สร้างทักษะและความชำนาญในการเขียนโปรแกรมเชิงวัตถุ เกมนักรบจะมีส่วนที่ให้ผู้ใช้ได้เล่นเกมซึ่งเป็นส่วนที่ดึงดูดความสนใจจากผู้ใช้ และมีส่วนที่ ให้ผู้ใช้ได้มีโอกาสฝึกเขียนโปรแกรมเพื่อสร้างหรือปรับปรุงโรบ็อทซึ่งเป็นส่วนที่ช่วยสร้างทักษะ และความชำนาญในการเขียนโปรแกรมเชิงวัตถุ และยังมีส่วนนำเสนอข้อมูลที่เป็นแนวคิดในการ เขียนโปรแกรมเชิงวัตถุซึ่งจะช่วยให้ผู้ใช้เข้าใจแนวคิดในการแก้ปัญหาของการเขียนโปรแกรมเชิง วัตถุด้วย 2 1.2 วัตถุประสงค์ 1.2.1 เพื่อพัฒนาเกมนักรบ ที่ให้ผู้เล่นได้ควบคุมโรบ็อทโดยการเขียนโปรแกรมเชิงวัตถุด้วย ภาษาจาวา และให้มีส่วนของการนำเสนอความรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุ ที่มีประสิทธิ ภาพในการทำงานดี 1.2.2 เพื่อหาประสิทธิภาพของเกมนักรบที่ได้พัฒนาขึ้น 1.3 สมมติฐานการวิจัย 1.3.1 เกมที่พัฒนาขึ้นได้รับการประเมินประสิทธิภาพในระดับดีขึ้นไป 1.4 ขอบเขตการวิจัย ระบบที่พัฒนาในสารนิพนธ์นี้มีขอบเขตดังนี้ 1.4.1 เป็นการพัฒนาด้วยภาษาจาวา รุ่นมาตรฐานที่ทำงานบนเครื่องคอมพิวเตอร์ทั่วไป 1.4.2 เป็นการพัฒนาภายใต้แนวคิดการเขียนโปรแกรมเชิงวัตถุ 1.4.3 เกมแบ่งเป็น 2 ส่วนหลัก ๆ ดังนี้ 1.4.2.1 ให้ผู้เล่นเลือกโรบ็อทมาจัดสร้างเป็นทีมและเลือกทีมที่จัดไว้แล้วมาเล่น 1.4.2.2 ให้ผู้เล่นสามารถสร้างหรือปรับปรุงโรบ็อท ด้วยการเขียนโปรแกรมโดย ใช้แนวคิดการเขียนโปรแกรมเชิงวัตถุด้วยภาษาจาวา เพื่อควบคุมโรบ็อท 1.4.4 ในส่วนของการสร้างหรือปรับปรุงโรบ็อทนี้จะมีส่วนนำเสนอความรู้แนวคิดการเขียน โปรแกรมเชิงวัตถุ ที่สอดคล้องกับคำที่เขียนโปรแกรมลงไป โดยข้อมูลที่นำเสนอประกอบไปด้วย 1.4.3.1 ข้อความอธิบายความหมายของคำที่สอดคล้องกับคำเฉพาะของแนวคิดการเขียน โปรแกรมเชิงวัตถุ 1.4.3.2 ตัวอย่างโปรแกรมที่เกี่ยวข้องกับคำที่สอดคล้องกับคำเฉพาะของแนวคิดการเขียน โปรแกรมเชิงวัตถุ 1.4.3.3 ภาพสัญลักษณ์ยูเอ็มแอลที่เกี่ยวข้องกับคำที่สอดคล้องกับคำเฉพาะของแนวคิดการ เขียนโปรแกรมเชิงวัตถุ 1.5 ข้อตกลงเบื้องต้น 1.5.1 พัฒนาเกมโดยใช้ภาษาจาวา และแนวคิดการเขียนโปรแกรมเชิงวัตถุ 1.5.2 พัฒนาเกมโดยใช้ระบบปฏิบัติการ Microsoft Windows 3 1.6 นิยามศัพท์ 1.6.1 โรบ็อท (Robot) หมายถึง วัตถุหรือ สิ่งต่าง ๆ ที่ถูกกำหนดให้อยู่ในทีมใดๆ และอยู่ใน ชนิดใดชนิดหนึ่ง ซึ่งสามารถนำไปใช้ร่วมกันในการต่อสู้ โดยโรบ็อท จะมีข้อมูลและพฤติกรรม เฉพาะตัว 1.6.2 ทีม หมายถึง กลุ่มของโรบ็อท ที่มีสถานะความเป็นกลุ่มเดียวกันจะไม่ทำลายกันเอง 1.6.3 ประสิทธิภาพ หมายถึง ผลจากการประเมินโดยกลุ่มผู้เล่นเกม ด้วยแบบประเมินที่ผู้วิจัย สร้างขึ้น 1.7 ประโยชน์ที่คาดว่าจะได้รับ 1.7.1 ผู้เล่นมีความรู้ ทักษะความชำนาญ และความเข้าใจที่ถูกต้องในแนวคิดการเขียน โปรแกรมเชิงวัตถุ ด้วยภาษาจาวา เพิ่มขึ้น 1.7.2 สร้างแรงจูงใจ และลดระยะเวลาในการเรียนรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุ 1.7.3 เป็นการสนับสนุน เผยแพร่การศึกษาและการนำไปใช้ของแนวคิดการเขียนโปรแกรม เชิงวัตถุ บทที่ 2 ทฤษฎีและเทคโนโลยีที่เกี่ยวข้อง การพัฒนาเกมนักรบเพื่อส่งเสริมการเรียนรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุ ผู้พัฒนาได้ทำการศึกษา ทฤษฎีและเทคโนโลยีต่าง ๆ ที่เกี่ยวข้องกับการพัฒนา ที่สามารถนำมาประยุกต์ใช้กับงาน ได้ โดยแบ่งออกเป็นหัวข้อต่าง ๆ ดังต่อไปนี้ คือ 2.1 ภาษาจาวา 2.2 แนวคิดการเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming หรือ OOP) 2.3 ยูเอ็มแอล (Unified Modeling Language หรือ UML ) 2.4 วิศวกรรมซอฟต์แวร์เชิงวัตถุ (Object Oriented Software Engineering) 2.1 ภาษาจาวา (Java) 2.1.1 พื้นฐานภาษาจาวา ภาษา จาวา ถูกพัฒนาขึ้นโดยบริษัท ซันไมโครซิสเต็ม (Sun Microsystems) โดยมี ประกาศให้เป็นภาษาสำหรับสร้างโปรแกรมเพื่อใช้งานบนอินเทอร์เน็ตมีจุดเด่นที่เมื่อสร้างขึ้นบน เครื่องคอมพิวเตอร์เครื่องหนึ่งแล้ว สามารถ นำไปทำงานบนเครื่องคอมพิวเตอร์ต่างระบบได้ โดย ไม่ต้องคอมไพล์โปรแกรมใหม่ ภาษาจาวาถูกออกแบบให้มีลักษณะดังต่อไปนี้ (วีระศักดิ์, 2543: 1) 2.1.1.1 เป็นภาษาที่ง่าย ในการเรียนรู้และใช้งานในแง่ต่าง ๆ ดังนี้ ก) ภาษา จาวา นำไวยากรณ์ภาษาส่วนใหญ่มาจากภาษา C และ C++ ฉะนั้นผู้ที่คุ้นเคยกับภาษา C หรือ C++ อยู่ก่อนแล้ว จะเข้าใจภาษาจาวา ได้ง่ายใช้เวลาศึกษาไม่นาน ข) ภาษา จาวา มีกลไกของภาษาจำนวนไม่มากและไม่ซับซ้อน โดยตัดกล ไกของภาษา C และ C++ ที่ยุ่งยากออกไป อีกทั้ง ภาษา จาวา ถูกออกแบบให้เป็นภาษาเชิงวัตถุอย่าง รอบคอบกว่าภาษา C และ C++ ซึ่งกลไกที่ซับซ้อนและไม่ชัดเจน ง่ายต่อการเกิดความผิดพลาด จะ ถูกตัดออกไป เช่น มัลติเพิลอินเฮอร์ริแทนซ์ (Multiple Inheritance) 5 ค. ภาษาจาวา จะทำการตรวจสอบเกี่ยวกับ ชนิดข้อมูล เพื่อช่วยให้โปรแกรม ทำงานโดยไม่มีความผิดพลาดเกี่ยวกับชนิดข้อมูล ซึ่งภาษาจาวา ได้สร้างกฎเกณฑ์เกี่ยวกับการ เปลี่ยนแปลงชนิดข้อมูลโดยอัตโนมัติซึ่งช่วยเปลี่ยนแปลงชนิดข้อมูลที่แตกต่างกัน ช่วยให้การเขียน โปรแกรมทำได้ง่ายขึ้น 2.1.1.2 โปรแกรมที่สร้างด้วยภาษาจาวา จะไม่มีความผิดพลาดจากข้อบกพร่องของ ภาษา หมายถึง โปรแกรมจะต้องไม่ล้มเหลวลง ด้วยความผิดปกติเล็กน้อยที่ไม่เกี่ยวกับตรรกะของ โปรแกรมซึ่งทำให้ภาษาจาวา มีความแข็งแกร่งคงทน (Robust) ด้วยวิธีการดังนี้ ก) ภาษาจาวาเน้นการใช้กลไกการดักจับข้อผิดพลาด (Exception Handling) เพื่อให้โปรแกรมสามารถจัดการกับความผิดปกติบางอย่างที่เกิดขึ้นในขณะที่โปรแกรม ทำงาน ช่วยให้โปรแกรมสามารถทำงานต่อไปได้โดยไม่ต้องหยุดการทำงานลง ข) ภาษาจาวา ตัดกลไกบางอย่างของ ภาษา C และ C++ ที่อาจก่อให้เกิดข้อ ผิดพลาดโดยไม่ระวังได้เช่นการตัดการอ้างถึงที่อยู่ (Address) ของ ตัวแปร และการใช้ ตัวชี้ (Pointer) สำหรับอ่านหรือเขียนข้อมูลลงหน่วยความจำโดยตรง ค) ภาษาจาวาไม่มีกลไกสำหรับคืนหน่วยความจำที่ขอมาขณะโปรแกรม ทำงานแต่ ภาษาจาวา อาศัยการทำงานของตัวกำจัดขยะ (Automatic Garbage Collector) ทำหน้าที่เก็บหน่วยความจำที่ไม่สามารถอ้างถึงได้แล้ว กลับมาใช้งานใหม่ ง) ภาษาจาวา เป็นภาษาที่เน้นความถูกต้องของชนิดข้อมูลที่ใช้ในโปรแกรม คอมไพเลอร์ของภาษาจาวา จะทำการตรวจสอบว่าโปรแกรมจัดการกับชนิดข้อมูลถูกต้องหรือไม่ซึ่ง ความผิดพลาดที่เกี่ยวกับชนิดข้อมูลจะ ถูกปฏิเสธตั่งแต่การคอมไพล์ ฉะนั้นความผิดพลาดชนิดนี้ จะไม่ข้ามไปเกิดขึ้นขณะที่โปรแกรมทำงาน 2.1.1.3 ภาษาจาวา มักจะถูกส่งผ่านระบบเครือข่ายไปทำงานบนเครื่องคอมพิวเตอร์ ของผู้อื่นซึ่งผู้รับจะต้องมั่นใจได้ว่าสิ่งที่รับมาจะไม่ก่อให้เกิดความเสียหายใด ๆ ต่อระบบนั้น ๆ โดย ภาษาจาวา ถือว่าเป็นภาษาที่มีความปลอดภัยสูง ซึ่งถูกออกแบบมาเพื่อความปลอดภัยมากกว่าภาษา อื่นโดยแบ่งการป้องกันออกเป็นหลายระดับดังนี้ ก) จาการที่ภาษาจาวา ไม่ยอมให้อ้างถึงค่าในหน่วยความจำผ่านทาง ตัวชี้ตำแหน่งที่อยู่ และจะทำการตรวจสอบว่าการอ้างถึงสมาชิกใน อะเรย์ (Array) อยู่ในขอบเขต หรือไม่ โปรแกรมจึงไม่สามารถเขียนหรืออ่านค่าในหน่วยความจำที่ไม่มีสิทธิ์จะอ้างถึง การเปลี่ยน แปลงโปรแกรม หรือค่าในหน่วยความจำ เพื่อสร้างโปรแกรมที่ไม่ปลอดภัยด้วยวิธีนี้จะไม่เกิดขึ้น ข) ตัวแปลภาษาจาวา มี การตรวจสอบไบต์โค้ด (Byte Code) ทำหน้าที่ ตรวจสอบโปรแกรมที่จะถูกทำงานว่ามีคำสั่งผิดปกติหรือมีการทำงานที่ไม่สมควรหรือไม่ 6 ค) ภาษาจาวา มีระบบรักษาความปลอดภัยที่เรียกว่า แซ็นด์บอกซ์โมเดล (Sandbox Model) คือโปรแกรมที่ถูกนำมาจากเครื่องอื่นผ่านเครือข่ายจะถือว่าเป็นโปรแกรมที่ไม่ น่าไว้ใจจะถูกเก็บอยู่ในภาวะที่เรียกว่า แซ็นด์บอกซ์ (Sandbox) ซึ่งมีข้อจำกัดหลาอย่างเช่น ไม่สามารถอ่าน หรือเขียนไฟล์ได้ 2.1.1.4 จุดมุ่งหมายสำคัญของการออกแบบภาษาจาวาคือโปรแกรมต้องสามารถ ทำงานบนเครื่องต่างระบบกันได้เป็นคุณสมบัติของการไม่ขึ้นกับระบบ (Platform Independent) ซึ่งภาษาจาวา ใช้วิธีการแปลภาษาทั้งแบบคอมไพล์ และแบบ อินเตอร์พรีท (Interpret) (วีระศักดิ์, 2543: 6) ภาษาจาวา นำแนวความคิดการสร้างเครื่องจักรสมมติ (Java Virtual Machine) มาใช้ เพื่อ ให้โปรแกรมไม่ขึ้นกับระบบโดยคอมไพเลอร์ (Compiler) ทำการแปลภาษาให้เป็นโปรแกรมของ เครื่องจักรสมมติ แล้วนำโปรแกรมนั้นมาทำงานด้วยเครื่องจักรสมมติที่จำลองขึ้นด้วย จาวา อิน เตอร์พรีทเตอร์ (Java Interpreter) ภาพที่ 2-1 แสดงการทำงานของเครื่องจักรสมมติ ซึ่งวิธีนี้โปรแกรมภาษาจาวาจะถูกคอมไพล์ โดยจาวาคอมไพล์เลอร์ (Java Compiler) ได้ เป็นโปรแกรมของ เครื่องจักรสมมติ สามารถนำไปทำงานบนเครื่องใด ๆ ที่มีจาวา อิน เตอร์พรีทเตอร์ (Java Interpreter) ได้จึงมีคุณสมบัติไม่ขึ้นกับระบบ โปรแกรมของ เครื่องจักร สมมติ จะทำงานได้เร็วกว่าการใช้ จาวา อินเตอร์พรีทเตอร์ เพียงอย่างเดียว โดยการคอมไพล์ ถูก แยกออกไปจากการเอ็กซีคิว (Execute) และด้วยการออกแบบคำสั่งของ เครื่องจักรสมมติ ให้ใกล้ เคียงกับคำสั่งของหน่วยประมวลผลทั่วไป จาวา อินเตอร์พรีทเตอร์ จึงเปลี่ยนคำสั่งของเครื่องจักร สมมติ ไปสู่คำสั่งของหน่วยประมลผลที่ใช้งานได้ง่าย การทำการแปลภาษาด้วย อินเตอร์พรีทเตอร์ ของภาษาจาวาจึงทำงานได้เร็วกว่าอินเตอร์พรีทเตอร์ ของภาษาอื่น ๆ ชุดคำสั่งของ เครื่องจักรสมมติ ถูกออกแบบมาเพื่อสนับสนุนการทำงานของการเขียน โปรแกรมเชิงวัตถุจึงมีคำสั่งเกี่ยวกับการสร้างวัตถุ (Object) และการอ้างถึงสมาชิกในวัตถุ ซึ่งไม่มี ในหน่วยประมวลผลทั่วไปภาษาจาวาเป็นภาษาที่เน้นความถูกต้องเกี่ยวกับชนิดข้อมูล (Type) จึงมี คำสั่งสำหรับคำนวณชนิดข้อมูลพื้นฐานแต่ละชนิด Java Program Java Compiler JVM Java Interpreter 7 เครื่องจักรสมมติ ถูกออกแบบให้สามารถจำลองได้บนตัวประมวลผลทั่วไป ซึ่งมีปัญหาเรื่อง ขนาดของหน่วยความจำรีจีสเตอร์ (Register) ที่ไม่เท่ากัน ฉะนั้น เครื่องจักรสมมติ จะทำการ คำนวณทั้งหมดบนหน่วยความจำแบบสเตค (Stacks) 2.1.2 การสร้างโปรแกรมภาษาจาวา จาวา แอปพลิเคชั่น (Java Application) คือ โปรแกรม ที่สร้างขึ้นด้วยภาษาจาวาเพื่อถูกทำงานโดยจาวา อินเตอร์พรีทเตอร์ ต้องเป็นโปรแกรมที่ สมบูรณ์ มี main() เป็นจุดเริ่มต้น และ สามารถควบคุมการดำเนินไปของตัวเองได้ การทำงาน ของภาษาจาวาภายใต้ จาวา อินเตอร์พรีทเตอร์ ทำได้โดยไม่ต้องมีโปรแกรมอื่นช่วย โดยที่ส่วน หัวของโปรแกรม main() ต้องประกอบด้วย ประโยคดังนี้ (วีระศักดิ์, 2543: 17) public static void mani(String args[ ]) ดังตัวอย่างต่อไปนี้ //Hello.java class Hello { public static void main(String args[]) { System.out.println("Hello") ; } } ขั้นตอนการสร้างและทำงาน จาวา แอปพลิเคชั่น จะเริ่มจากใช้ เอดดิเตอร์ เขียนโปรแกรม สำหรับ จาวา แอปพลิเคชั่น และบันทักไฟล์ไว้ มีนามสกุล .java จากนั้นใช้คำสั่ง javac.exe ทำการ คอมไพล์ จะได้ผลลัพธ์เป็นไฟล์นามสกุล .class ซึ่งเมื่อต้องการให้ทำงานก็ส่ง ไฟล์นามสกุล .class ให้กับ java.exe 2.1.3 ภาษาจาวากับการเขียนโปรแกรมเชิงวัตถุ การเขียนโปรแกรมโดยให้มีรูปแบบเป็น ลักษณะเชิงวัตถุ ต้องอาศัยภาษา คอมพิวเตอร์ที่ถูกออกแบบมาให้มีลักษณะพิเศษและเอื้อประโยชน์ สำหรับการเขียนโปรแกรมแบบเชิงวัตถุโดยเฉพาะ ภาษาเชิงวัตถุมีคลาส (Class) เป็นโครงสร้าง หลักของโปรแกรม แต่ละคลาสอาจมีสมาชิกเป็นข้อมูลหรือฟังก์ชัน (Function) โดยที่ฟังก์ชันใน ภาษาเชิงวัตถุ เราจะเรียกว่า เมธทอด (Method) หรือ โอเปอเรชั่น (Operation) คลาสจะถูก กำหนดขึ้นโปรแกรม โดยใช้คำว่า “class” ตามด้วยชื่อคลาส และส่วนของโปรแกรมที่กำหนด สมาชิกของคลาสซึ่งอยู่ระหว่างเครื่องหมาย “{“ กับ “}” ในไฟล์ของภาษาจาวาหนึ่งอาจมีคลาส มากกว่าหนึ่งคลาสได้ แต่เมื่อถูกคอมไพล์แล้วจะได้ ไฟล์นามสกุล .class สำหรับแต่ละคลาสโดยมี ชื่อเหมือนกับคลาสนั้น ๆ ด้วยเหตุว่าเพื่อให้โปรแกรมมีขนาดเล็ก และใช้วิธี ไดนามิค ลิงค์ 8 (Dynamic Linked) คือ คลาสที่ถูกอ้างอิงถึงจะถูกโหลดเข้าสู่ จาวา อินเตอร์พรีทเตอร์ ขณะที่ โปรแกรมทำงาน แม้โปรแกรมจะทำงานช้ากว่าเพราะเสียเวลาโหลดคลาส แต่จะมีเฉพาะคลาสที่ถูก ใช้จริง ๆ เท่านั้นที่ถูกโหลด แต่มีข้อดีที่บางคลาสอาจถูกใช้ร่วมมันโดยโปรแกรมหลาย ๆ โปรแกรม ได้ (วีระศักดิ์, 2543: 22) 2.1.3.1 ไฟล์ และคลาส ก) โครงสร้างของคลาส ทุกโปรแกรมที่สร้างจากภาษาจาวาต้องสามารถ สร้างคลาสให้ได้อย่างน้อยหนึ่งคลาส จึงจะถือว่าเป็นภาษาจาวา และเนื่องจากโปรแกรมตามแนว ความคิดเชิงวัตถุต้องทำงานด้วยวัตถุ และคลาสก็เป็นส่วนเริ่มต้นจองวัตถุโดยมีรูปแบบโครงสร้าง ดังนี้ ข) ข้อมูลในคลาสหรือตัวแปร (Data Member) การเก็บข้อมูลภายในคลา สมีรูปแบบการกำหนดดังนี้ Access_Level final static Data_Type Data_Name 1. Acces_Level คือระดับการเข้าถึงตัวแปรที่กำหนด มีการเข้าถึง 4 รูปแบบ คือ public เป็นระดับการเข้าถึงข้อมูลที่ไม่มีข้อจำกัด private เป็นระดับการเข้าถึงข้อมูลภายในคลาสเท่านั้น protected เป็นระดับการเข้าถึงข้อมูลภายในคลาสหรือวัตถุ และคลาสที่สืบทอดมา แต่ต้องอยู่ใน เพกเกจ(Package)เดียวกัน ถ้าไม่กำหนดเป็นระดับการเข้าถึงข้อมูลภายในคลาสหรือวัตถุใน เพกเกจเดียวกัน 2. final ใช้บอกว่าตัวแปรตัวนั้นเราไม่สามารถเข้าไปทำการเปลี่ยนแปลงค่าด้วยวิธีใดๆ ได้ เป็นการประกาศค่าสุดท้ายของตัวแปรนั้น ๆ และใช้งานตลอดทั้งโปรแกรม 3. static ถ้า กำหนดไว้หน้าตัวแปรใด ตัวแปรนั้นจะถูกโหลดเข้าไปอยู่ในหน่วยความจำพร้อมที่จะใช้งานได้ทันที 2.1.3.2 วัตถุ และการสร้างวัตถุ วัตถุสร้างขึ้นจากขั้นตอนสองขั้นตอน คือขั้นตอนแรก ทำการประกาศชื่อตัวแปรอ้างถึง (Reference Variable) คือขั้นตอนที่ใช้กำหนดชื่อตัวแปรเพื่อใช้ class Class_Name { Data_member Method_member } 9 ในการอ้างถึงไปยังพื้นที่ในหน่วยความจำ โดยพื้นที่ส่วนนี้เป็นส่วนที่จัดเก็บวัตถุที่สร้างขึ้นมาใน ภายหลัง โดยมีรูปแบบการกำหนดดังนี้ Class Name Reference Name ขั้นตอนที่สองการสร้างวัตถุ (Instance of Class) วัตถุจะเป็นพื้นที่ในหน่วยความจำซึ่งสร้าง ตามแบบโครงร่างของคลาสใดๆ ดังนั้นวัตถุจะอ้างถึงพื้นที่ที่สามารถเก็บข้อมูล และประมวลผลซึ่ง มีรูปแบบดังนี้ new Class_Constructor( Parameter_List ) ในภาษาจาวาตัวแปรอ้างถึงและวัตถุมีความสัมพันธ์ซึ่งกันและกัน โดยตัวแปรอ้างถึง ถูกกำหนดขึ้น เพื่อประโยชน์ในการอ้างไปยังตำแหน่งของวัตถุที่อยู่ในหน่วยความจำ โดย ในหน่วยความจำบนเครื่องคอมพิวเตอร์ บางครั้งสามารถสร้างวัตถุได้หลายๆวัตถุของการทำงานแต่ ละครั้ง จึงจำเป็นต้องใช้ชื่อตัวแปรอ้างถึงเพื่อให้สามารถเข้าใช้งานข้อมูลและเมธทอด ในวัตถุได้ 2.2 แนวคิดการเขียนโปรแกรมเชิงวัตถุ (Object-Oriented Programming หรือ OOP) โดยทั่วไปแล้วในระบบที่ซับซ้อนจะประกอบด้วยวัตถุจำนวนมากที่ทำงานร่วมกัน และการ สร้างโปรแกรมที่คำนวณผลลัพธ์การทำงานของวัตถุทั้งหมดออกมาโดยตรงจะยากกว่าการสร้าง โปรแกรมที่จำลองการทำงานของแต่ละวัตถุไปที่ละขั้นจนกว่าจะได้คำตอบ แนวคิดในการสร้าง โปรแกรมที่ประกอบขึ้นจากวัตถุเป็นหลักนี้เรียกว่า การเขียนโปรแกรมเชิงวัตถุ ซึ่งโดยแท้จริงแล้ว การเขียนโปรแกรมเชิงวัตถุ ก็คือเทคนิควิธีการเขียนโปรแกรมแบบหนึ่ง(ธวัชชัย, 2545) แนวความคิดแบบใหม่ที่ใช้ในการเขียนโปรแกรมเป็น การเน้นถึงปัญหาและองค์ประกอบ ของปัญหา การเน้นที่ปัญหาและองค์ประกอบการการแก้ปัญหา (Problem Space) จะคล้ายกับการ แก้ไขปัญหาในการดำรงชีวิตประจำวันของมนุษย์ มากกว่าที่จะมองหาวิธีการแก้ปัญหานั้น ๆ หรือ ขั้นตอนในการแก้ปัญหา (Solution Space) ซึ่งเป็นการเขียนโปรแกรมแบบเก่า 2.2.1 การเขียนโปรแกรมเชิงวัตถุหลักการสำคัญสำหรับการออกแบบงานเชิงวัตถุคือ การค้นหาวัตถุ และจำแนกวัตถุนั้น ๆ ออกเป็นส่วนที่มีการเปลี่ยนแปลงและส่วนที่อยู่คงที่ ซึ่งวัตถุที่ ไม่มีการเปลี่ยนแปลงอยู่คงที่ สามารถนำมาใช้ได้เมื่อมีการปรับปรุงระบบงานใหม่ ซึ่งเป็นความจำเป็นที่ต้องมีการออกแบบระบบงานเพื่อให้ทราบถึงส่วนที่มีการเปลี่ยนแปลง และส่วนที่ไม่มีการ เปลี่ยนแปลง แนวคิดการเขียนโปรแกรมเชิงวัตถุ อาลัน เคร์ ซึ่งเป็นผู้บุกเบิกแนวความคิดการเขียน 10 โปรแกรมเชิงวัตถุคนหนึ่ง ได้เสนอกฎ 5 ข้อที่เป็นแนวทางของภาษาคอมพิวเตอร์เชิงวัตถุ ดังนี้ (ธวัชชัย, 2545: 10) 2.2.1.1 ทุก ๆ สิ่งเป็นวัตถุ คือ องค์ประกอบของโปรแกรมคอมพิวเตอร์ทุก ๆ ส่วนจะ ต้องเป็นวัตถุ 2.2.1.2 โปรแกรม คือ กลุ่มของวัตถุที่ส่งข่าวสารบอกซึ่งกันและกันให้ทำงาน โปรแกรม ในความหมายของการเขียนโปรแกรมเชิงวัตถุ ก็คือ กลุ่มของวัตถุที่ส่งข้อความข่าวสาร หรือ เมสเสจ (Message) ถึงกันและกันเพื่อบอกให้วัตถุทำงาน ดั้งนั้นวัตถุจะไม่ทำงานถ้าไม่มีข่าว สาร 2.2.1.3 วัตถุแต่ละวัตถุ จะต้องมีหน่วยความจำและประกอบไปด้วยวัตถุอื่น ๆ วัตถุจะ ต้องมีหน่วยความจำของมันเองซึ่งอาจประกอบขึ้นจากวัตถุอื่นๆ ได้ ซึ่งหมายถึง วัตถุสามารถ ประกอบจากวัตถุอื่น ๆ ได้ ซึ่งเป็น คุณ สมบัติการถ่ายทอดห รือที่เรียกว่า อิน เฮอร์ริ แทนซ์(Inheritance) และคุณสมบัติขององค์ประกอบหรือที่เรียกว่า คอมโพสิชั่น (Composition) 2.2.1.4 วัตถุทุกชนิดจะต้องจัดอยู่ในประเภทใดประเภทหนึ่งวัตถุ ที่สร้างขึ้นจะต้องมี ชนิดหรือประเภท ซึ่งหมายถึง วัตถุทุกชนิดจะต้องสามารถจัดเป็นกลุ่มได้กลุ่มของวัตถุ ก็คือ คลาส นั่นเอง ในการเขียนโปรแกรมเชิงวัตถุจะต้องเขียนคลาสขึ้นมาก่อนแล้วจังสร้างวัตถุภายหลัง ซึ่ง วัตถุจะอยู่ในคลาสใด ๆ โดยที่วัตถุที่เกิดจากคลาสเดียวกันจะมีคุณสมบัติพื้นฐานเหมือนกัน 2.2.1.5 วัตถุที่จัดอยู่ในประเภทเดียวกันย่อมได้รับข่าวสารเหมือนกันการเขียน โปรแกรมเชิงวัตถุมีประสิทธิภาพที่ดีเพราะชนิดของวัตถุมิได้กำหนดอยู่อย่างโดด ๆ แต่สามารถจัด เป็นกลุ่มได้ซึ่งวัตถุในกลุ่มเดียวกันจะได้รับข่าวสารเหมือนกันซึ่งเป็นพื้นฐานของการพ้องรูปหรือ โพลีมอร์ฟิซึม (Polymorphism) 2.2.2 ก ารเก็ บ ข้ อ มู ล ใน โม ดู ล แ ล ะก ารซ่ อ น ข่ าวส าร(Data Encapsulation and Information Hiding) ปัญหาหนึ่งในระบบงานคอมพิวเตอร์คือการแก้ไขข้อมูลในระบบใหญ่ ๆ ที่ มีการใช้ข้อมูลร่วมกัน การแก้ไขปรับปรุงข้อมูลจะไม่ทราบได้ว่าโมดูลใดแก้ไขส่วนข้อมูลใดอย่าง ไร ดังนั้นจึงเกิดแนวคิดที่จะนำข้อมูลให้อยู่ในโมดูลนั่น ๆ ซึ่งก็เป็นการเก็บข้อมูลไว้ภายใน (Data Encapsulation) เพื่อป้องกันการแก้ไขโดยส่วนของโปรแกรมที่ไม่ได้รับอนุญาต ซึ่งจะมีการ กำหนดหน้าที่ส่วนที่ทำหน้าที่แก้ไขข้อมูลโดยเฉพาะให้โมดูลที่ต้องการแก้ไขข้อมูลเรียกใช้ นอก จากข้อมูลแล้วส่วนของโมดูลเองก็อาจถูกเรียกใช้โดยไม่เหมาะสมได้ฉะนั้นการซ่อนส่วนของโมดูล ที่สมควรซ่อนและเปิดเผยส่วนที่ควรเปิดเผย เพื่อป้องกันจึงต้องมีการป้องกันส่วนของโมดูลที่ไม่สม ควรให้ผู้อื่นมาใช้ กลไกนี้เรียกว่าการซ่อนข่าวสาร (Information Hiding) 11 2.2.3 การเชื่อมต่อ (Interface) ในการเขียนโปรแกรมเชิงวัตถุ ในวัตถุจะต้องมีการเชื่อมต่อ เป็นส่วนที่วัตถุนั้น ๆ จะให้บริการหรือเป็นส่วนที่บอกว่าวัตถุนั้น ๆ สามารถทำอะไรได้บ้าง ซึ่งเรียก ว่าเมธทอดซึ่งมีข้อดีคือการเปลี่ยนแปลงที่เกิดขึ้นภายในวัตถุจะไม่กระทบต่ออินเตอร์เฟส (Interface) ดังนั้นภายในวัตถุผู้เขียนคำสั่งสามารถดัดแปลงแก้ไข หรือเพิ่มเติมได้ตลอดเวลา และ ภายในวัตถุสามารถเก็บค่าต่าง ๆ ได้ด้วย ซึ่งถือเป็นจุดเด่นของการเขียนโปรแกรมเชิงวัตถุ เพราะผู้ ใช้สามารถเรียกใช้วัตถุต่าง ๆ โดยไม่จำเป็นต้องทราบกลไกการทำงานภายใน ผู้ใช้สามารถเรียกใช้ วัตถุได้ด้วยการส่งข่าวสาร ไปยังวัตถุที่ต้องการ 2.2.4 วงจรชีวิตของวัตถุ จุดเด่นของการเขียนโปรแกรมเชิงวัตถุที่สำคัญก็คือการทำข้อมูลให้ อยู่ในรูปของ เอ็บสแตค(Abstract) เพื่อนำกลับมาใช้ใหม่ การถ่ายทอดคุณสมบัติ และการ พ้องรูป และการเขียนโปรแกรมเชิงวัตถุจะจัดเก็บข้อมูลไว้ในวัตถุ ดังนั้นวงจรชีวิตของวัตถุจึงเป็น สิ่งสำคัญเพราะหมายถึงข้อมูลด้วย (ธวัชชัย, 2545: 20) ในภาษาจาวา วัตถุจะถูกสร้างในส่วนของหน่วยความจำที่เรียกว่า ฮีป (Heap) เมื่อใช้คำสั่ง นิว (new) เพื่อสร้างวัตถุขึ้นในฮีป และอ้างถึงโดยตำแหน่ง เมื่อต้องการใช้ก็จะอ้างถึงตำแหน่งของ วัตถุ และภาษาจาวายังมีกาเบจคอเล็กเตอร์ (Garbage Collector) เมื่อส่วนของหน่วยความจำเต็ม การเบจคอเล็กเตอร์ จะถูกเรียกใช้งานโดยอัตโนมัติ ซึ่งจะคืนหน่วยความจำที่ไม่ได้ใช้ให้กับ คอมพิวเตอร์โดยการพิจารณาจากการอ้างอิงถึงวัตถุ (Reference) ถ้าวัตถุใดไม่มีการอ้างอิงถึงแสดง ว่าวัตถุนั้นไม่ได้ใช้งานแล้ว ก็จะถูกกาเบจคอเล็กเตอร์ ยกเลิกการใช้งานไปด้วย 2.2.5 การฝังตัวของวัตถุ (Persistence) การฝังตัวของวัตถุ (Persistence) ก่อนที่จะออกจาก โปรแกรมจะมีวิธีการที่จะทำให้คอมพิวเตอร์จัดเก็บข้อมูลล่าสุด เมื่อเข้ามาใช้งานคราวหน้า คอมพิวเตอร์ก็จะสามารถจำข้อมูลครั้งสุดท้ายได้อย่างถูกต้องซึ่ง ในภาษาจาวามีคำสั่ง ซีรีไลเซชั่น (Serialization) ที่จะทำการแปลงวัตถุให้อยู่ในรูปของบิตและไบต์ 2.2.6 คลาสและวัตถุ (Class and Object) คลาสเป็นตัวกำหนดรายละเอียดที่จะสร้างวัตถุ ออกมาใช้แต่โปรแกรมเมอร์ไม่สามารถใช้ประโยชน์จากคลาสได้โดยตรง ในการเขียนโปรแกรม เชิงวัตถุ คลาสจะถูกนิยามโดยข้อมูล และ พฤติกรรม ที่คลาสจะกระทำกับข้อมูลเมื่อคลาสหนึ่ง ๆ ถูกเรียกใช้ คลาสจะสร้างวัตถุขึ้นมาทำงานแทนคลาสที่ถูกเรียกใช้ (ธวัชชัย, 2545: 25) วัตถุคือสิ่งใดๆ ก็ตามซึ่งมีคุณลักษณะ (State) บ่งบอกถึงความเป็นตัวของมันเองในขณะนั้น และสามารถแสดงพฤติกรรม (Behavior) ของตัวเองออกมาได้ไม่ว่าจะเป็นคำว่าวัตถุหรือคำว่า อ็อบเจ็กต์ถือว่าเป็นสิ่งเดียวกันในแนวคิดของภาษาคอมพิวเตอร์เชิงวัตถุ (วีระศักดิ์, 2543: 143) โดยทั่วไปวัตถุใดๆมักจะมีส่วนประกอบที่สำคัญอยู่สองประการ ประการแรกคือคุณ ลักษณะ (State) คือสิ่งที่สามารถบ่งบอกถึงความเป็นวัตถุ และอยู่ภายในตัววัตถุซึ่งสามารถ เปลี่ยน 12 แปลง ได้ เช่น วัตถุรถจักรยานมีคุณลักษณะหลายประการด้วยกัน เช่น สี ความสูง น้ำหนัก เป็นต้น ประการที่สองคือ พฤติกรรม (Behavior) คืออาการที่วัตถุใดๆ แสดงออกมาหรือถูกให้แสดงออก มา เช่น การเคลื่อนที่ของรถจักรยาน โดยพฤติกรรมใดๆ ของวัตถุนั้นจะมีผลเชื่อมโยงไปถึงข้อมูล คุณลักษณะภายในตัววัตถุเองด้วย ในภาษาจาวานั้นคลาสประกอบไปด้วย ชนิดของคลาส, ชื่อของคลาส, ตัวแปรของคลาส และ พฤติกรรม ชนิดของคลาสนั้นอาจจะเป็นพับลิค (Public) หรือ ไพรเวท (Private) ถ้าเป็น พับลิค หมายถึงคลาสที่มองเห็นได้โดยคลาสที่อยู่ภายนอกหรือภายในเพกเกจ แต่ถ้าเป็น ไพรเวท คลาสที่อยู่นอกเพกเกจจะไม่สามารถเรียกใช้คลาสนี้ การอ้างถึงตัวแปรแบบ พับลิค ของอีกวัตถุ หนึ่งสามารถทำได้โดยใช้ชื่อ วัตถุ นั้นแล้วตามด้วยจุดและชื่อตัวแปร แต่ถ้าเป็นการอ้างถึงตัวแปรที่ ถูกประกาศ ไว้ในคลาสก็สามารถอ้างถึงชื่อตัวแปรได้โดยตรง 2.2.6.1 การสร้างคลาส การสร้างคลาสให้ขึ้นต้นด้วยคำว่าคลาส (class) แล้วตามด้วย ชื่อคลาส และตามด้วยข้อความระหว่าง { } ซึ่งเป็นคำสั่งที่บอกว่าคลาสนี้มีลักษณะ ข้อมูลอย่างไร การสร้างวัตถุ การสร้างวัตถุขึ้นมาใหม่นั่นเองโดยมีคำสั่งนิว (New Operator) ก็คือ คำสั่ง ที่ช่วยในการ สร้างวัตถุ ใหม่ขึ้นมานั่นเอง ชื่อคลาสที่ตามหลัง คำสั่งนิว (New Operator) นี้จะเป็น ตัวบ่งชี้ว่าเรากำลัง สร้างวัตถุของคลาสอะไรขึ้นมาและคอนสตัคตอร์ (Constructor) ที่มีเครื่อง หมายกำหนด (Signature) เดียวกับ ตัวแปร ที่อยู่ในวงเล็บหลังชื่อคลาสจะถูกเรียกโดยอัตโนมัติ หลังจากที่วัตถุ ถูกสร้างขึ้น โดย คำสั่งนิว จะคืน ค่า อ้างอิงของวัตถุ ที่เพิ่งถูกสร้างออกมา และถ้า เราไม่เก็บค่านั้นไว้ในตัวแปร เราก็จะไม่มีโอกาสเรียกใช้ วัตถุ ตัวนั้นอีก 2.2.6.3 พฤติกรรม (Method) พฤติกรรม ในภาษาจาวานั้นก็เปรียบได้กับฟังก์ชั่น ในภาษาC นั่นเอง โดยทั่วไปแล้วควรจะ กำหนด ให้ พฤติกรรม ทำอะไรอย่างหนึ่งเท่าที่เราต้องการ การสร้างพฤติกรรม ให้ใหญ่และซับซ้อนมาก ๆ จะทำให้วัตถุประสงค์ของแนวคิดการเขียน โปรแกรมเชิงวัตถุ นั้นถูกบดบังลงได้ องค์ประกอบสำคัญของ พฤติกรรม นั้นมีดังนี้ ก) ชื่อของพฤติกรรม ชื่อของ พฤติกรรม นั้นมีกฎเกณฑ์ในการตั้งเหมือนกับ ชื่อของตัวแปรนั่นเอง หลักการตั้งชื่อ พฤติกรรม นี้มิใช่กฎบังคับ แต่ผู้เขียนโปรแกรมจาวาโดยส่วน มากใช้กันเพื่อทำให้โปรแกรมอ่านง่าย ซึ่งจะตั้งให้เป็นคำกิริยาหลาย ๆ คำซึ่งแสดงถึงหน้าที่ของ พฤติกรรม นั้น ๆ คำแรกจะถูกเขียนด้วยตัว ตัวอักษรตัวเล็ก ทั้งหมดและตัวอักษรตัวแรกของคำถัด ไปแต่ละคำจะเป็นตัว ตัวใหญ่ และที่เหลือจะเป็นตัว ตัวเล็ก เช่น พฤติกรรม getClassSched() ข) อาร์กิวเมนต์ (Argument) อาจจะเป็นตัวแปรพื้นฐานของจาวา หรืออาจ จะเป็นวัตถุ ก็ได้ เราสามารถกำหนดพฤติกรรม ให้รับ อาร์กิวเมนต์ (Argument) ได้ 13 ค) พฤติกรรม (Method) ตัวขอบเขต เป็นตัวกำหนดอย่างแท้จริงว่า พฤติ กรรม นี้ทำหน้าที่อะไร ภายใน ขอบเขตของพฤติกรรม เราสามารถ จะประกาศ ตัวแปรขึ้นมาเพื่อใช้ งานชั่วคราวซึ่ง ช่วงชีวิต ของตัวแปรเหล่านี้จะอยู่ภายใน พฤติกรรม นี้เท่านั้น ภายในขอบเขตของ พฤติกรรม เราสามารถเรียกใช้ พฤติกรรม อื่นของ วัตถุนั้นหรือของวัตถุอื่นที่อยู่ภายใน ขอบเขต ของพฤติกรรม นั้นได้ด้วย ขอบเขตของขอบเขตของพฤติกรรม นั้นจะถูกกำหนดด้วยเครื่องหมาย ปีกกาเปิดและปิดหนึ่งคู่ “{“ “}” ง) การคืนค่า (Return) หลังจาก พฤติกรรม ทำงานจนถึงบรรทัดสุดท้าย แล้วก็จะคืนค่า กลับไปหาส่วนของโปรแกรมที่เรียก หากต้องการให้ พฤติกรรม ส่งค่าคืนไปยังผู้ เรียก ก็สามารถใส่ ประโยคการคืนค่า เข้าไปได้ หลังจากที่ ประโยคการคืนค่า ได้ถูก ทำงาน แล้ว ก็ จะหลุดออกจาก ขอบเขตของพฤติกรรม นั้นทันที โปรแกรมส่วนที่กระทำการเรียก ก็สามารถรับค่า คืนค่า นั้นได้โดยการใส่ ตัวแปรตามด้วยเครื่องหมายเท่ากับไว้ด้านซ้ายของ พฤติกรรมที่เรียก ถ้าไม่ มีค่าที่จะคืนค่าก็ต้องใส่ คำว่า void ไว้ตรงตำแหน่งของชนิด 2.2.7 คอนสทรัคเตอร์ (Constructor) ทุกๆ ครั้งที่วัตถุ ถูกเริ่มทำงาน จะมี พฤติกรรมหนึ่งที่ ถูกเรียกเสมอซึ่ง พฤติกรรม นั้นก็คือ คอนสทรัคเตอร์ เมธทอด (Constructor Method) นั่นเอง โดย คอนสทรัคเตอร์ นั้นจะไม่สามารถถูกเรียกโดยตรงโดยโปรแกรมเมอร์ได้ แต่จะถูกเรียกโดย อัตโนมัติหลังจากที่ วัตถุ ถูกเริ่มทำงาน ขึ้นมา วัตถุประสงค์ที่มี คอนสทรัคเตอร์ ขึ้นมานี้ก็เพื่อให้ผู้ เขียนโปรแกรมเขียนสิ่งที่ต้องทำหลังจากที่ วัตถุถูกสร้างในทันทีโดยที่ไม่ต้องเขียน พฤติกรรม เพื่อ ที่เริ่มทำงาน ต่างหาก และถ้าทำแบบนั้นผู้เขียนโปรแกรมจะต้องเสียเวลาเพิ่มขึ้นในการเรียก พฤติ กรรม ที่ต้องการให้เริ่มทำงาน (วีระศักดิ์, 2543: 147) 2.2.8 ชนิดของตัวแปร ตัวแปร หมายถึง ตัวที่เก็บค่า ๆ หนึ่งซึ่งค่านั้นอาจจะเปลี่ยนแปลงไป ตามสถานการณ์ ในภาษาจาวาตัวแปรอาจจำแนกได้ 2 ประเภท (ธวัชชัย, 2545: 29) 2.2.8.1 ตัวแปรพื้นฐาน (Primitive Data Type) ตัวแปรพื้นฐานมีอยู่ 8 ชนิดคือ Boolean, char, byte, int, short, long, float และ double ตัวแปรประเภทนี้จะถูกออกแบบให้ เก็บข้อมูลไว้ในสแตค ซึ่งทำงานได้รวดเร็วกว่าข้อมูลที่เก็บในฮีป ซึ่งต้องใช้ตัวแปรอ้างอิงถึงวัตถุ แทนการเรียกใช้โดยตรง 2.2.8.2 ตัวแปรแอบสแตค เดต้า ไทป์ (Abstract Data Type) แอบสแตค เดต้า ไทป์ เป็นกรอบของวัตถุ ที่ผู้เขียนโปรแกรม สามารถกำหนดชนิดของข้อมูลขึ้นมาใหม่ได้ตามต้องการ เมื่อต้องการเรียกใช้วัตถุชนิดนี้จะใช้ผ่านตัวแปรที่เรียกว่าตัวแปรอ้างอิง เช่น String f; ซึ่งอธิบายได้ ดังภาพ 14 ภาพที่ 2-2 แสดงการอ้างอิงถึงวัตถุ 2.2.9 การนำคลาสกลับมาใช้งานอีก การนำคลาสกลับมาใช้งานอีกหรือที่เรียกว่าซอฟต์แวร์ รียูส นับเป็นจุดเด่นของการเขียนโปรแกรมเชิงวัตถุซึ่งทำได้ หลายวิธีแต่วิธีที่มีประสิทธิภาพดีคือ การทำ คอมโพสิตชั่น(Composition) และ การสืบทอดคุณสมบัติ (Inheritance) (ธวัชชัย, 2545: 138) 2.2.9.1 คอมโพสิตชั่น (Composition) เป็นการพัฒนาโปรแกรมที่อาศัยองค์ ประกอบเล็ก ๆ ซึ่งอาจถือเป็นหน่วยพื้นฐานนำมาประกอบกันลักษณะเช่นนี้เรียกว่า คอมโพ สิตชั่น ภาพที่ 2-3 แสดงความสัมพันธ์ระหว่างคลาสแบบคอมโพสิต f reference String 15 2.2.9.2 การสืบทอดคุณสมบัติ (Inheritance) การสืบทอดคุณสมบัติจะใช้กับคลาสที่ อยู่ในกลุ่มเดียวกัน มีความสัมพันธ์ ในลักษณะของคลาสแม่ (Super Class) และคลาสลูก (Sub Class) โดย คลาสผู้กำหนดคุณสมบัติเรียกว่า คลาสแม่ และ คลาสที่รับคุณสมบัติเรียกว่า คลาสลูก ภาพที่ 2-4 แสดงการสืบทอดคุณสมบัติ คลาสลูก จะได้รับการถ่ายทอดคุณสมบัติซึ่งก็คือตัวแปรและเมธทอด จากคลาส แม่ทุก ๆ ตัวแปรและเมธทอด และ คลาสลูก อาจเพิ่มเติมตัวแปรและเมธทอด ได้ตามต้องการ ซึ่งมีแนวทาง ในการใช้คุณสมบัติการถ่ายทอดได้ดังนี้ ก) คลาสลูก จะไม่ได้รับการสืบทอดคอนคอนสทรัคเตอร์ ของคลาสแม่ ดั้งนั้นจะต้องเขียน คอนสทรัคเตอร์ หรือใช้ ดีฟอลต์คอนสตรัคเตอร์ (Default Constructor) ข) ตัวแปรหรือเมธทอดที่เป็นไพรเวท จะไม่ได้รับการสืบทอดคุณสมบัติ โดยทั่วไปแล้ว คลาสลูก จะได้รับการสืบทอดคุณสมบัติทุกอย่างซึ่งสามารถเรียกใช้งานได้ทันทีโดย ไม่ต้องมีการเขียนซ้ำ แต่ถ้าเมธทอดใดมีการเขียนซ้ำใน คลาสลูก อีกแสดงว่ามีการปรับปรุงเปลี่ยน แปลงเมธทอดดังกล่าวเรียกว่าการ โอเวอร์ไรดิง (Overriding) นอกจากนี้ยังมีเมธทอด โอเวอร์ โหลดดิ้ง (Overloading) ซึ่งเป็นเมธทอดที่มีชื่อเหมือน แต่สามารถทำงานได้แตกต่างกันโดยอาศัย พารามิเตอร์ (Parameter) ที่ส่งค่าและชนิดของการ คืนค่า เป็นตัวกำหนด 2.2.9.3 คอมโพสิตชัน(Composition) และอากิเกชั่น (Aggregation) ความแตกต่าง จะพิจารณาจากส่วนประกอบต่าง ๆ หากสามารถแยกส่วนประกอบออกโดยไม่มีผลกระทบการ ทำงานของคลาสถ้าแยกส่วนประกอบออกบางส่วนแล้วยังคงทำงานได้ส่วนประกอบนั้นจะกำหนด ให้มีความสัมพันธ์แบบ อากิเกชั่น แต่ถ้าแยกส่วนประกอบออกบางส่วนแล้วไม่สามารถทำงานได้ ก็จะมีความสัมพันธ์แบบ คอมโพสิตชัน 16 2.2.10 การพ้องรูป (Polymorphism) การพ้องรูป (Polymorphism) เป็นคุณสมบัติประการ หนึ่งที่สนับสนุนการนำคลาสกลับมาใช้งานอีก ซึ่งเป็นผลจากการสืบทอดคุณสมบัติ การพ้องรูปมี วัตถุประสงค์คือการแยกส่วนของ อินเตอร์เฟส และอิมพลีเม็นเทชั่น (Implementation) ออกจาก กัน การพ้องรูป ในการเขียนโปรแกรมเชิงวัตถุในปัจจุบันที่เด่นชัดมีอยู่ 2 แบบ (ธวัชชัย, 2545: 173) 2.2.10.1 โอเวอร์โหลดดิ้ง เป็นการพ้องรูปที่มีลักษณะชื่อเมธทอดเดียวกันอาศัยพารา มิเตอร์ เป็นตัวจำแนกความแตกต่าง ซึ่งภายในแต่ละเมธทอดอาจทำงานต่างกัน 2.2.10.2 โอเวอร์ไรดิง เป็นการพ้องรูปที่มีลักษณะของ คลาสแม่ และ คลาสลูก ที่มี เมธทอด ที่มีชื่อและ เหมือนกัน 2.2.11 เอ็บสแตค (Abstract) ส่วนขยาย เอ็บสแตค ที่ไว้หน้าคลาสและเมธทอด เพื่อกำหนด คลาสและเมธทอดนั้น ๆ ให้เป็นเอ็บสแตค เพื่อแยก อินเตอร์เฟส และคำขยายเมธทอด (static, void) ในคลาสแม่ออกจากวิธีการทำงานโดยนำวิธีการทำงานมาไว้ในคลาสลูก ซึ่งการเขียนเอ็บส แตค ที่คลาสจะบังคับให้ผู้ใช้ต้องแยกอินเตอร์เฟส (Interface) และการทำงานออกจากกันอย่างเต็ม รูปแบบ โดยสรุปแล้ว เอ็บสแตคคลาส (Abstract Class) คือคลาสที่มีเมธทอดใดเมธทอดหนึ่งเป็น เอ็บสแตค และ เอ็บสแตคเมธทอด (Abstract Method) คือเมธทอดที่ไม่ระบุการทำงานใด ๆ รอ ให้คลาสลูกทำการ โอเวอร์ไรดิง เมธทอดนั้นและ วัตถุประสงค์ของ เอ็บสแตค เพื่อให้คลาสแม่ เป็นผู้กำหนดอินเตอร์เฟส และให้คลาสลูกกำหนดวิธีการทำงาน 2.3 ยูเอ็มแอล (Unified Modeling Language หรือ UML) ยูเอ็มแอล (UML) เป็นภาพสัญลักษณ์ สำหรับการวาดแผนผังของการพัฒนาซอฟต์แวร์ สามารถใช้วาดแผนผังเพื่ออธิบายขอบเขตของปัญหา หรือเพื่อช่วยออกแบบซอฟต์แวร์ เป็นมาตร ฐานสากลที่ใช้ในการอธิบายซอฟท์แวร์ในรูปของไดอะแกรม (Diagram) ตัวมาตรฐาน ยูเอ็มแอล กำหนดโดยโอเอ็มจี (OMG หรือ Object Management Group) ซึ่งภาพสัญลักษณ์ ยูเอ็มแอล มีพื้นฐานพัฒนามาจาก ภาพสัญลักษณ์ของโอเอ็มที (OMT), บูช (Boosh) และ จาค๊อบสัน (Jacobson) การวิเคราะห์และออกแบบระบบเชิงวัตถุนั้นเป็นวิธีที่นิยมกันมาในปัจจุบันและมีแนวโน้มที่ จะแทนที่การออกแบบระบบแบบเดิม กระบวนการพัฒนาระบบตามแบบวิธี เรชั่นแน็ล ยูนิไฟ โพรเซส (Rational Unified Process) เป็นกระบวนที่ครอบคลุมกระบวนการพัฒนาระบบ ทั้งหมด โดยมองเป็นกระบวนการในภาพรวมโดยการพิจารณาทั้งงานด้านการบริหารและงานด้าน เทคนิค กระบวนการพัฒนาจะมีลักษณะการทำซ้ำ (Iterative) และการเพิ่มขึ้น (Incremental) ดัง นั้นงานที่ทำจะไม่มีมากในคราวเดียวในตอนสุดท้ายของโพรเจ็กต์ (Project) แต่จะมีการแบ่งงาน 17 ออกเป็นช่วง ๆ (Phase) ในช่วงของการสร้างระบบ (Construction Phase) การทดสอบและการ รวบรวมส่วนย่อยเข้ากับระบบรวม จะมีการทำซ้ำหลาย ๆ ครั้ง เพื่อจะให้ได้โปรแกรมที่มีคุณภาพ และตรงตามความต้องการ ในการทำซ้ำแต่ละรอบ จะประกอบด้วย การวิเคราะห์ (Analysis) การออกแบบ (Design) การอิมพลีเมนต์ (Implement) และการทดสอบ (Testing) ช่วงของการ พัฒนาระบบ จะช่วยให้เห็นภาพรวมของระบบ และสนับสนุนการทำงานแบบคอมโพเน็นต์ เบส (Component Based) 2.3.1 ส่วนประกอบของ ยูเอ็มแอล (UML) ประกอบด้วยส่วนต่าง ๆ ดังนี้ ระบบงานทั้งหมด อาจมีหลายส่วนที่ต้องพิจารณา เพราะอาจมีขอบข่ายงานที่กว้างและซับซ้อนการอธิบายกระบวน การทำงานต่าง ๆ ของระบบไม่สามารถอธิบายได้เพียงแค่มุมมองเดียว (View) ดังนั้น การมอง ระบบควรจะต้องมีมุมมองต่าง ๆ กัน เช่น มุมมองด้าน ฟังก์ชันแน็ล (Functional), น็อน ฟังก์ชันแน็ล (Non Functional), มุมมองขององค์กร เป็นต้น ซึ่งแต่ละ ไดอะแกรม (Diagram) สามารถที่จะมีมุมมองได้มากกว่าหนึ่งมุมมองก็เพื่อมาอธิบายภาพรวมของระบบ โดยอาจเป็นมุม มองของผู้ใช้ระบบ ผู้เขียนโปรแกรมพัฒนาระบบ ซึ่งแต่ละมุมมองทำให้ผู้ทำเข้าใจระบบในแง่มุมที่ ต่าง ๆ กัน มุมมอง (View) ต่าง ๆ ของ ยูเอ็มแอล มีดังนี้ 2.3.1.1 ยูสเคสวิว(Use Case View) เป็นการมองระบบจากผู้ใช้ภายนอก หรือผู้ใช้ ระบบ ซึ่งไดอะแกรมที่ใช้อธิบาย คือ ยูสเคสไดอะแกรม (Use-Case Diagram) ตัวอย่างผู้ใช้ระบบ ภายนอก เช่น ลูกค้า, ผู้ออกแบบ, ผู้ทดสอบระบบ, นักเรียน, อาจารย์ เป็นต้นยูสเคส (Use Case) ใน ยูสเคสไดอะแกรม เป็นการทำงานของระบบที่ผู้ใช้ต้องการ ซึ่งได้มาจากการสำรวจความ ต้องการของผู้ใช้ ยูสเคสไดอะแกรม เป็นตัวกำหนดเป้าหมายของระบบ จึงเป็นส่วนกลางของ มุม มอง อื่น ๆ ที่จะต้องมีการทำงานต่าง ๆ ครบตามที่กำหนดไว้ใน ยูสเคสไดอะแกรม 2.3.1.2 ลอจิคัลวิว (Logical View) ใช้อธิบายว่าสามารถที่จะจัดการทำงานของ ระบบให้เป็นไปตามที่ต้องการได้อย่างไรและมีบริการอะไรให้กับผู้ใช้บ้าง ลอจิคัลวิว ต่างจาก ยูสเคส วิว เนื่องจากเป็นมุมมองของผู้ออกแบบและพัฒนาระบบ โดยจะแสดงในรูปแบบของโครง สร้างแบบสแตติก (Static) เช่น คลาส, อ็อบเจ็กต์, ความสัมพันธ์ระหว่างการทำงานร่วมกันแบบได นามิก คอลาโบเรชัน (Dynamic Collaboration) ซึ่งเกิดเมื่ออ็อบเจ็กต์ ส่งแมสเสจ ระหว่างการ ทำงาน โครงสร้างแบบสแตติก (Static) จะอธิบายโดยใช้ คลาสไดอะแกรม (Class Diagram) และ อ็อบเจ็กต์ไดอะแกรม (Object Diagram) ส่วนการทำงานร่วมกันแบบไดนามิกจะอธิบายโดยใช้ สเตทไดอะแกรม (State Diagram) ซีเควนซ์ไดอะแกรม (Sequence Diagram) คอลาโบเรชันได อะแกรม (Collaboration Diagram) และแอคติวิตี้ไดอะแกรม (Activity Diagram) 18 2.3.1.3 คอมโพเนนต์วิว (Component View) บอกถึงการสร้างและความขึ้นต่อกัน ของโมดูลซึ่งเป็นส่วนที่ผู้พัฒนาระบบต้องคำนึงถึง ว่าในแต่ละคอมโพเนนต์ประกอบด้วยโครง สร้างและความขึ้นต่อกันตลอดจนข้อมูลต่าง ๆ เช่นความต้องการทรัพยากรของคอมโพเนนต์นั้น มี อะไรบ้าง โดยใช้คอมโพเนนต์ไดอะแกรม (Component Diagram) ในการอธิบาย 2.3.1.4 ดีพลอยเมนต์วิว (Deployment View) เป็นการแสดงการจัดระบบในระดับ กายภาพ (Physical) ให้เหมาะสม เช่นการเชื่อมต่อระหว่างคอมพิวเตอร์และโหนดต่าง ๆ และรวม ถึงการแมป (Map) คอมโพเนนต์ (Component) ต่าง ๆ ในระดับโครงสร้างทางกายภาพ เช่น ลำดับการของหรือโปรแกรมในแต่ละเครื่องคอมพิวเตอร์ ใช้สำหรับผู้พัฒนาระบบ ผู้ร่วมพัฒนา ระบบ ผู้ทดสอบระบบอธิบายโดยดีพลอยเมนต์ ไดอะแกรม (Deployment Diagram) 2.3.1.5 โปรเซสวิว(Process View) ไดอะแกรม (Diagram) เป็นกราฟซึ่งแสดงโดย สัญลักษณ์ที่จัดเรียงขึ้นเพื่อใช้อธิบายระบบในมุมมองต่าง ๆ ในระบบหนึ่ง ๆ จะประกอบไปด้วย หลาย ๆ ไดอะแกรม แต่ละไดอะแกรม ยังสามารถมองในหลาย ๆ มุมมองด้วย 2.3.2 ใน ยูเอ็มแอล จะมีไดอะแกรม ต่าง ๆ ดังนี้ 2.3.2.1 ยูสเคสไดอะแกรม (Use Case Diagram) ส่วนประกอบสำคัญในยูสเคสได อะแกรม คือ ยูสเคส (Use Case) แอ๊กเตอร์ (Actor) และเส้นแสดงความสัมพันธ์ (Relationship) ในการสร้าง ยูสเคสไดอะแกรม สิ่งที่สำคัญ คือ การค้นหาว่าระบบทำอะไรได้บ้าง โดยไม่สนว่าข้าง ในสิ่งที่ระบบต้องทำได้เหล่านั้นมีกลไกการทำงานอย่างไรหรือใช้เทคนิคการสร้างอย่างไรเปรียบ เสมือนเป็น “กล่องดำ” (Black Box) โดยยูสเคสไดอะแกรม จะแสดงความสัมพันธ์ระหว่างผู้ใช้ งาน กับระบบ ซึ่งจะมีผู้กระทำจากภายนอกระบบ เรียกว่า แอ๊กเตอร์ กระทำกับระบบ โดยติดต่อ ผ่าน ยูสเคส ต่าง ๆ ที่เกี่ยวข้อง และจะใช้ในการสื่อสารกับผู้ใช้ เพื่ออธิบายถึงฟังก์ชันการทำงาน หลักของระบบ ใน ยูสเคสไดอะแกรม ก็คือการทำงานต่างๆ ที่ผู้ใช้ต้องการ ซึ่งจะได้มาจากการสอบ ถามจากผู้ใช้ ยูสเคส (Use Case) เป็น ความสามารถหรือฟังก์ชัน (Function) ที่ระบบซอฟต์แวร์จะต้อง ทำได้ เช่น ค้นหาข้อมูลของนักศึกษา สรุปคุณสมบัติของยูสเคสคือ ยูสเคส จะต้องถูกกระทำโดย แอ็กเตอร์ และเป็นผู้ติดต่อกับระบบตามยูสเคส ที่กำหนดไว้ และยูสเคส รับข้อมูลจากแอ็กเตอร์ และส่งข้อมูลให้แอ็กเตอร์ นั่นคือแอ็กเตอร์ กระทำกับยูสเคส โดยการส่งข้อมูลเข้าสู่ระบบตาม ยูสเคส หรือรอรับค่าที่ระบบจะส่งกลับให้ ยูสเคส ถือว่าเป็นการรวบรวมคุณลักษณะความต้องการในระบบอย่างสมบูรณ์ เปรียบเสมือน เป็นการสรุปความต้องการของผู้ใช้ ออกเป็นข้อ ๆ อย่างครบถ้วน 19 แอ็กเตอร์ (Actor) คือ ผู้ที่กระทำกับยูสเคส หรือใช้งานยูสเคส นั้น ๆ เช่น นักศึกษา อาจารย์ เจ้าหน้าที่ไม่ใช่ส่วนประกอบของระบบ แต่เป็นส่วนที่ใช้ติดต่อกับระบบ ซึ่งอาจเป็นเพียงการป้อน ข้อมูลเข้าสู่ระบบ หรือการส่งข้อมูลออกจากระบบ หรืออาจเป็นทั้งสองอย่าง แอ็กเตอร์ ในระบบแบ่งได้เป็น 2 ประเภทโดยประเภทแรกคือ แอ๊กเตอร์หลัก หมายถึง แอ็กเตอร์ ที่มีความสำคัญโดยตรงต่อความสามารถหลักของระบบซึ่งถูกแสดงด้วยยูสเคส ผู้ใช้งาน ระบบจะให้ความสำคัญกับงานที่แอ๊กเตอร์หลักจะต้องกระทำมากที่สุด ส่วนประเภทที่สองคือ แอ๊กเตอร์รอง หมายถึงแอ็กเตอร์ ที่มีหน้าที่ความสำคัญรองลงไปจากแอ็กเตอร์หลัก ความสัมพันธ์ระหว่างยูสเคส มีอยู่ 2 ชนิดแตกต่างกันออกไปได้แก่ ความสัมพันธ์แบบขยาย (Extend Relationship) ยูสเคส หนึ่งอาจถูกช่วยเหลือโดยการทำงานยูสเคสอื่น สัญลักษณ์ในยูเอ็ม แอล คือลูกศรเส้นประที่ชี้จากยูสเคสแรกไปยังยูสเคส ที่ถูกช่วยเหลือหรือถูกขยาย โดยมีคำว่า “extend” อยู่ในเครื่องหมายสเตริโอไทป์ (Stereotype) <> อยู่กึ่งกลางลูกศร และความ สัมพันธ์แบบรวม (Include Relationship) ยูสเคส หนึ่ง ๆ อาจจำเป็นต้องอาศัยการทำงานของยูส เคส อื่น ๆ สำหรับยูสเคส ที่ถูกเรียกใช้โดยยูสเคส อื่น สัญลักษณ์ในยูเอ็มแอล ของความสัมพันธ์ดัง กล่าวคือลูกศรเส้นประชี้ไปยังยูสเคส ที่ถูกเรียกใช้หรือถูกรวมไว้ด้วยกัน กล่าวอีกนัยหนึ่งคือยูสเคส ที่ถูกยูสเคส อื่น ๆ เรียกใช้งานมากกว่าหนึ่งยูสเคส ขึ้นไป โดยมีคำว่า “include” อยู่ในเครื่องหมาย เตอริไทป์ <> อยู่ที่กึ่งกลางลูกศร ภาพที่ 2-5 ภาพตัวอย่างยูเคสไดอะแกรม 2.3.2.2 คลาสไดอะแกรม (Class Diagram) แสดงโครงสร้างของส่วนที่ไม่เปลี่ยน แปลงของระบบ ในมุมมองของผู้พัฒนาระบบ ซึ่งสามารถแสดงความสัมพันธ์ได้หลายวิธี ได้แก่ 20 แอซโซซิเอชัน (Association) หรือ เชื่อมต่อระหว่างกัน ดีเพนเดนต์ (Dependent) หรือ การพึ่งพา เรียกใช้คลาสอื่น ๆ สเปเชียลไลซ์ (Specialized) หรือ ความเป็นลักษณะเฉพาะของคลาสอื่น ๆ เพกเกจหรือ ร่วมเป็นหน่วย ความสัมพันธ์ระหว่างคลาสต่าง ๆ เหล่านี้ จะถูกแสดงโดยคลาสไดอะ แกรม โดยรวมเข้าเป็นโครงสร้างภายในของคลาสเป็นกลุ่มแอททริบิวต์และ กลุ่มของ โอเปอเรชัน ในระบบหนึ่งสามารถประกอบด้วยหลายคลาสไดอะแกรมโดยที่ คลาสคือ กลุ่มของ อ็อบเจ็กต์ที่มี คุณสมบัติ และพฤติกรรม ร่วมกัน โดยที่รายละเอียดของคลาสเป็นดังนี้ ก) ชื่อคลาส จะขึ้นต้นด้วยตัวใหญ่แบบหนาและเอียงถ้าเป็นเอ็บสแตค คลาส ข) แอตทริบิวต์ ประกอบด้วย 1. ชนิดของการเข้าถึง (Visibility) ของแอตทริบิวต์ ได้แก่ พับลิคซึ่งถูกแสดงด้วยเครื่อง หมายบวก (+), ไพรเวทซึ่งถูกแสดงด้วยเครื่องหมายลบ (-) และโพรเท็กแสดงด้วยเครื่องหมาย (#) 2. ชื่อของแอตทริบิวต์ 3. ประเภทของแอตทริบิวต์ ซึ่งจะอยู่ต่อจากเครื่องหมายโคล่อน(:) โดยอาจเป็นตัวแปร ชนิดพรีมิทีฟ (Primitive Data Type) ของแต่ละภาษาซึ่งมักคล้ายคลึงกัน เช่น Integer, Boolean, Real เป็นต้น 4. ค่าเริ่มต้นของแอตทริบิวต์ ซึ่งอาจไม่มีก็ได้ แต่ถ้ามีจะอยู่ต่อจาเครื่องหมายเท่ากับ ค) โอเปอเรชั่น (Operation) ประกอบด้วย 1. ชนิดของการเข้าถึงโอเปอเรชั่น เช่นเดียวกับแอตทริบิวต์ คือ พับลิคจะถูกแสดงด้วย เครื่องหมายบวก (+) ไพรเวทซึ่งถูกแสดงด้วยเครื่องหมายลบ (-) และโพรเท็กแสดงด้วยเครื่อง หมายชาร์ป (#) 2. ชื่อโอเปอเรชั่น 3. พารามิเตอร์ 4. ประเภทของค่าที่ส่งคืน (Return Type) ง) ความสัมพันธ์ระหว่างคลาส (Relationships) สามารถเป็นได้ 3 แบบคือ 1. ดีเพนเดนซี่ (Dependency) หรือความสัมพันธ์แบบพึ่งพิง การเปลี่ยนแปลงที่เกิดขึ้นกับ คลาดที่ถูกพึ่งพิง (Independent Class) จะส่งผลต่อคลาสที่พึ่งพิง (Dependent Class) การสร้าง ความสัมพันธ์แบบนี้สามารถทำได้โดยวาดเส้นตรงแบบประที่มีหัวลูกศรเป็นเส้นโปร่งชี้จาก คลาสลูกที่พึ่งพิงไปยังคลาสที่ถูกพึ่งพิง 2. เจอเนอรัลไลซ์เซชัน (Generalization) คือความสัมพันธ์ระหว่างคลาสแม่และคลาสลูก การให้ความสัมพันธ์แบบนี้วาดเส้นตรงทึบที่มีหัวลูกศรเป็นรูปสามเหลี่ยมโปร่งชี้จากคลาสไปยัง คลาสแม่ 21 3. แอ็ซโซซิเอชัน (Association) แบ่งได้ดังนี้คือ 3.1 ความสัมพันธ์ปกติ (Normal Association) มักใช้ในการออกแบบระบบที่ซับ ซ้อนโดยเฉพาะระบบสารสนเทศ ปกติจะเป็นความสัมพันธ์แบบสองทิศทาง จะวาดด้วยเส้นตรงทึบ เชื่อมระหว่างสองคลาสและมีชื่อความสัมพันธ์กำกับอยู่โดยชื่อนี้มักเป็นคำกิริยาเป็นส่วนใหญ่ นอก จากนี้ยังมีการกำหนดปริมาณของคลาสหรือ อ็อบเจ็กต์ที่สัมพันธ์กันอยู่ โดยที่สัญลักษณ์ 1 หมายถึง จะมีอ็อบเจ็กต์ในคลาสไดอะแกรมได้หนึ่ง อ็อบเจ็กต์เท่านั้น และสัญลักษณ์ 0…1 หมายถึงจะมีอ็ อบเจ็กต์ในคลาสไดอะแกรมได้แค่หนึ่งหรืออาจจะไม่มี และสัญลักษณ์ M...N หมายถึงจะมี อ็อบ เจ็กต์ในคลาสไดอะแกรมได้ตั้งแต่ M ถึง N เมื่อ M, N เป็นจำนวนเต็มบวกและสัญลักษณ์ *หมาย ถึงจะมีอ็อบเจ็กต์ในคลาสไดอะแกรมได้ตั้งแต่ศูนย์ขึ้นไปและสัญลักษณ์ 0…* หมายถึงจะมี อ็อบ เจ็กต์ในคลาสไดอะแกรมได้ตั้งแต่ศูนย์ขึ้นไปและสัญลักษณ์ 1…* หมายถึงจะมีอ็อบเจ็กต์ในคลาส ไดอะแกรมได้ตั้งแต่หนึ่งขึ้นไป 3.2 อากิเกชัน (Aggregation) เป็นความสัมพันธ์ระหว่างคลาสหรืออ็อบเจ็กต์ในแง่ ของการรวมกัน แบ่งเป็น 2 แบบคือ แบบอากิเกชัน แบบปกติ (Normal Aggregation) ถูกแสดง ด้วยเส้นตรงทึบโยงระหว่างคลาสโดยมีสัญลักษณ์ข้าวหลามตัดติดอยู่ระหว่างปลายเส้นความ สัมพันธ์กับคลาสที่หมายถึงสิ่งที่ใหญ่กว่า และแบบ คอมโพสิตชัน ซึ่งคล้ายคลึงกับความสัมพันธ์ แบบ อากิเกชัน แบบปกติ หากแต่คลาสที่เป็นองค์ประกอบจะเป็นส่วนหนึ่งของคลาสที่ใหญ่กว่า และเมื่อคลาสที่ใหญ่กว่าถูกทำลาย คลาสที่เป็นองค์ประกอบก็จะถูกทำลายไปด้วย ภาพที่ 2-6 ภาพตัวอย่างคลาสไดอะแกรม 22 2.3.2.3 ซีเควนซ์ไดอะแกรม (Sequence Diagram) ซีเควนซ์ไดอะแกรม จะบอกว่า ใน ยูสเคส นั้น วัตถุแต่ละตัวจะติดต่อสื่อสารกันอย่างไร มีขั้นตอนการทำงานอย่างไร โดยจะเน้นไป ที่แกนเวลาเป็นสำคัญ ถ้าเวลาเปลี่ยน ขั้นตอนการทำงานจะเปลี่ยน โดยมีแอ็กเตอร์ เป็นผู้กระทำเริ่ม ต้น สัญลักษณ์ ซีเควนซ์ไดอะแกรม ในยูเอ็มแอล มีแกนสมมติ 2 แกนคือแกนนอน และแกนตั้ง แกนนอนจะแสดงขั้นตอนการทำงานหรือการส่งเมสเสจ ระหว่างวัตถุ โดยแต่ละวัตถุจะส่งข้อมูลถึง กันว่าต้องทำอะไร เมื่อใด ส่วนแกนตั้งเป็นแกนเวลา แกนนอนและแกนตั้งต้องสัมพันธ์กัน ส่วน วัตถุหรือคลาสแทนด้วยรูปสี่เหลี่ยมเรียงกันตามแนวนอน ภายในบรรจุชื่ออ็อบเจ็กต์ตามด้วยเครื่อง หมายโคล่อน ( : ) และชื่อคลาส เส้นประที่อยู่ในแนวแกนเวลาซึ่งแสดงถึงชีวิตของวัตถุ สี่เหลี่ยม แนวตั้งที่อยู่ตำแหน่งเดียวกับวัตถุหรือคลาสเรียกว่า แอ๊กทิเวชัน (Activation) ซึ่งใช้แสดงช่วงเวลา ที่วัตถุกำลังปฏิบัติงาน และส่งข้อมูลระหว่างวัตถุ และแสดงการสิ้นสุดลงของอ็อบเจ็กต์หรือการถูก ทำลายด้วยเครื่องหมายกากบาทไว้ที่ปลายเส้นชีวิตของอ็อบเจ็กต์ ภาพที่ 2-7 ภาพตัวอย่างซีแควนไดอะแกรม 23 2.3.2.4 คอลาบอเรชันไดอะแกรม (Collaboration Diagram) ทำหน้าที่เดียวกับ ซีเควนซ์ไดอะแกรม แต่จะไม่แสดงถึงแกนเวลาอย่างชัดเจน ยกเว้นการโต้ตอบกันระหว่างอ็อบเจ็กต์ สัญลักษณ์ที่ใช้แทนวัตถุหรือคลาสด้วยรูปสี่เหลี่ยม ข้างในสี่เหลี่ยมเป็น ชื่ออ็อบเจ็กต์ ตามด้วยเครื่อง หมาย สแลช ( / ) บทบาท ตามด้วยเครื่องหมายโคล่อน ( : ) ชื่อคลาสและขีดเส้นใต้เพื่อแสดงว่า เป็นวัตถุ แต่ไม่จำเป็นต้องเรียงตามแนวนอน มีเส้นเชื่อมกันระหว่างวัตถุเรียกว่า ลิงก์ (Link) ซึ่งแต่ ละลิงก์ (Link) จะมีคำอธิบายแสดงขั้นตอนการทำงานตามทิศทางลูกศร โดยมีตัวเลขลำดับกำกับไว้ เพื่อบอกว่าขั้นตอนใดทำก่อนทำหลังซึ่งแทนแกนเวลาตามด้วยเครื่องหมายโคล่อน ( : )และ เมสเสจ การทำงานย่อยจะใช้ตัวเลขและเติมจุดย่อยแล้วใส่ตัวเลขต่อท้ายเหมือนทศนิยมเพื่อให้รู้ว่าเป็นการ ทำงานย่อยของเลขลำดับใด ภาพที่ 2-8 ภาพตัวอย่างคอลาบอเรชันไดอะแกรม 2.3.2.5 สเตทชาร์ตไดอะแกรม (State Chart Diagram) อธิบายประกอบคลาสไดอะ แกรม โดยจะแสดงทุก ๆ สถานะที่เป็นไปได้และเหตุการณ์ที่ทำให้อ็อบเจ็กต์ต่าง ๆ เกิดการเปลี่ยน แปลง โดยเหตุการณ์ที่ทำให้อ็อบเจ็กต์เกิดความเปลี่ยนแปลงอาจมาจากอ็อบเจ็กต์อื่นส่งแมสเสจมา การเปลี่ยนสถานะเรียกว่าทรานซิซัน (Transition) โดยมีแอ็กชัน (Action) ทำให้เกิดการเปลี่ยน สถานะ สเตทชาร์ตไดอะแกรม ไม่จำเป็นต้องวาดทุกคลาสแต่จะใช้สำหรับคลาสที่มีการกำหนด สถานะไว้ชัดเจนและเมื่อมีการเปลี่ยนแปลงเท่านั้น 24 สัญลักษณ์ สเตทชาร์ตไดอะแกรมในยูเอ็มแอลจะมีจุดเริ่มต้นสถานะและจุดสิ้นสุดสถานะ จุดเริ่มต้นสถานะจะมีสัญลักษณ์เป็นรูปวงกลมทึบและจุดสิ้นสุดสถานะจะเป็นรูปวงกลมโปร่งล้อม รอบวงกลมทึบข้างใน ส่วนแต่ละสถานะในไดอะแกรมจะแสดงเป็นรูปสี่เหลี่ยมหัวมน และจะเชื่อม กันด้วยเส้นลูกศรชี้จากสถานะหนึ่งไปยังอีกสถานะหนึ่ง บางสเตทชาร์ตไดอะแกรมจะมีสถานะวน เวียน (Loop) ภาพที่ 2-9 ภาพตัวอย่างสเตตไดอะแกรม 2.3.2.6 แอ๊กทิวิตี้ไดอะแกรม (Activity Diagram) แสดงลำดับการไหลของกิจกรรม ต่าง ๆ โดยจะอธิบายกิจกรรมต่าง ๆ ในลักษณะของการกระทำจะมีเงื่อนไขและการตัดสินใจ กำหนดไว้เพื่อควบคุมการไหลของกิจกรรมรวมถึงแมสเสจที่รับส่งระหว่างแต่ละกิจกรรม สัญลักษณ์ แสดงด้วยสี่เหลี่ยมมนเหมือนแคปซูลเชื่อมโยงกันด้วยลูกศรเพื่อแสดงลำดับการ ทำแอ๊กทิวิตี้ถัดไปได้ โดยจะมีเส้นลูกศรชี้เข้ามารวมกันที่จุดเดียว (ตรงเส้นแนวนอน) นั่นคือ แอ๊ก ทิวิตี้ที่ชี้เข้ามาที่เส้นทึบดังกล่าวเสร็จหมดก่อนจึงทำแอ็กทิวิตี้ที่ชี้เข้ามาที่เส้นทึบดังกล่าวเสร็จหมด ก่อนจึงทำแอ็กทิวิตี้ถัดไปได้ การแบ่งเป็น สวิมเลนส์ (Swim Lanes) เหมือนสระว่ายน้ำโดยแบ่ง เป็นช่องในแนวดิ่งและกำหนดแต่ละช่องด้วยชื่อของอ็อบเจ็กต์ไว้แถวบนสุด 25 ภาพที่ 2-10 ภาพตัวอย่างแอ๊กทิวิตี้ไดอะแกรม 2.3.2.7 คอมโพเนนต์ไดอะแกรม (Component Diagram) แสดงโครงสร้างทางกาย ภาพของโค้ด อาจเป็นส่วนประกอบซอสโค้ด คอมโพเนนต์ประกอบด้วยข้อมูลเกี่ยวกับลอจิคัล คลาส (Logical Class) ของ คอมโพเนนต์ นั้น ในไดอะแกรมแสดงความสัมพันธ์หรือความพึ่งพา กันของคอมโพเนนต์ จะช่วยในการวิเคราะห์ว่าเมื่อเกิดการเปลี่ยนแปลงของคอมโพเนนต์หนึ่งจะมี ผลต่ออีกคอมโพเนนต์อื่น ๆ อย่างไรในโปรแกรม สัญลักษณ์ เป็นการเชื่อมกันระหว่างโหนด (Node) ซึ่งโหนดหรือฮาร์ดแวร์ ก็จะบรรจุ อินสแตนซ์ของซอฟต์แวร์คอมโพแนนต์ที่ถูกแสดงด้วยสัญลักษณ์ของคอมโพเนนต์ไว้ข้างใน แต่ละ คอมโพเนนต์เชื่อต่อกันโดยใช้ความสัมพันธ์แบบพึ่งพิงโดยชี้จากคอมโพเนนต์ที่ขอใช้บริการไปยัง คอมโพเนนต์อื่น ๆ เหมือนกับคอมโพแนนต์ไดอะแกรม ภาพที่ 2-11 ภาพตัวอย่างคอมโพแนนต์ไดอะแกรม 26 2.3.2.8 ดีพลอยเมนต์ไดอะแกรม (Deployment Diagram) แสดงสถาปัตยกรรมทาง กายภาพของฮาร์ดแวร์และซอฟต์แวร์ที่ใช้ในระบบ ซึ่งสามารถแสดงเป็นคอมพิวเตอร์และโหนดที่ เชื่อมต่อถึงกัน ภายในโหนดยังสามารถมีคอมโพเนนต์หรืออ็อบเจ็กต์ที่สามารถปฏิบัติกับโหนดเพื่อ แสดงว่าโปรแกรมส่วนใดปฏิบัติบนโหนดใด และความสัมพันธ์ระหว่างคอมโพเนนต์ที่อยู่บน โหนด สัญลักษณ์ แสดงเป็นสี่เหลี่ยมที่ประกอบไปด้วยสี่เหลี่ยมเล็กอีก 2 รูปติดอยู่ที่ขอบด้านซ้าย และอาจเชื่อมต่อกันด้วยเส้นแสดงความสัมพันธ์แบบที่พึ่งพิงระหว่างกัน ภาพที่ 2-12 ภาพตัวอย่างดีพลอยเมนต์ไดอะแกรม 2.4 วิศวกรรมซอฟต์แวร์เชิงวัตถุ (Object-Oriented Software Engineering หรือ OOSE) 2.4.1 วิศวกรรมซอฟต์แวร์ (Software Engineering) ซอฟต์แวร์เอ็นจิเนียริ่งเป็นกระบวน ที่ทำให้ ซอฟต์แวร์มีประสิทธิภาพดีขึ้น ซึ่งเกิดจากความซับซ้อนของซอฟต์แวร์และปัญหาในการ พัฒนาซอฟต์แวร์ในอดีต ที่เรียกว่า ซอฟต์แวร์ ไครซิส ซึ่งประกอบด้วย ปัญหา ด้านควอลิทิ (Quality) คือซอฟต์แวร์ที่พัฒนาได้มีคุณภาพต่ำ ไม่สามารถแก้ปัญหาที่ต้องการได้ ปัญหาด้านไทม์ 27 (Time) หรือ (Dead Line) คือไม่สามารถพัฒนาให้เสร็จในระยะเวลาที่กำหนดได้และปัญหาด้าน ค็อสท์ (Cost) คือไม่สามารถพัฒนาให้อยู่ภายใต้งบประมาณที่กำหนดได้ ซอฟต์แวร์ เอ็นจิเนียริ่ง จะเกี่ยวข้องกับสิ่งต่าง ๆ ดังนี้ 2.4.1.1 เป็นการใช้วิธีการทางวิศวกรรม เพื่อสร้างซอฟต์แวร์ที่ ก) เอ็คโคโนมิค (Economic) ประหยัดควบคุมค่าใช้จ่ายและระยะเวลาได้ ข) เรียลบิลิทิ ควอลิทิ (Reliability and Quality) คุณภาพและเชื่อถือได้ ค) แอ็ฟฟิเชี่ยนลี่ (Efficiently) มีประสิทธิภาพทำงานได้ตามต้องการ 2.4.1.2 เป็นการสร้างซอฟต์แวร์ที่ มีวิธีการพัฒนา นำไปใช้ บำรุงรักษา และ นำออก 2.4.1.3 เป็นศาสตร์ที่ว่าด้วยการสร้างผลิตภัณฑ์ ในระยะเวลาและค่าใช้จ่ายที่กำหนด 2.4.1.4 มีเพอฟอร์มานซ์ (Performance) ที่มีคุณภาพและมีมาตรฐาน 2.4.1.5 มีการใช้ทรัพยากรอย่างมีประสิทธิภาพทั้ง บุคลากร, เงินทุน และ เครื่องมือ 2.4.1.6 มีหลักการในการดำเนินการ ทดสอบ และการประเมินผลที่ชัดเจน 2.4.2 การนำซอฟต์แวร์กลับมาใช้งานใหม่ (Software Reuse) การทำ ซอฟต์แวร์ รียูส เป็น ผลจากแนวคิดการเขียนโปรแกรมเชิงวัตถุและเป็นไปเพื่อวัตถุประสงค์ในการแก้ไขปัญหา ซอฟต์แวร์ ไครซิส โดยทั่วไปทำได้ 2 แนวทางคือ อินเฮอร์ริแทนซ์และ คอมโพสิชั่น 2.4.2.1 ข้อดี ก) รียูส (Reuses) คือข้อมูลและพฤติกรรม ในคลาสแม่ นำไปใช้ในคลาส ลูกได้โดยไม่ต้องเขียนซ้ำ ข) โค้ด แชร์ริ่ง (Code Sharing) คือสามารถนำบางส่วนของของโปรแกรม ไปใช้ในโครงการต่อไปหรือโปรแกรมอื่นได้ โดยการทำซอฟต์แวร์เพกเกจ (Software Package) ค) อิมพรูฟ เรียลบิลิทิ (Improving Reliability) คือเมื่อทำรียูส หรือ โค้ดแชร์ริ่ง จากโปรแกรมที่ถูกต้องสมบูรณ์ เมื่อนำไปใช้ก็จะมีความถูกต้องสมบูรณ์ด้วยในระดับ หนึ่ง ง) คอนสแท็นซี (Constancy of Interface) คือการทำงานระหว่าง คลาสแม่ และ คลาสลูก จะมีความถูกต้องตรงกันและเข้ากันได้ จ) เรปิด โปรโตไทป์(Rapid Prototype) คือสามารถสร้าง โปรโตไทป์ ได้ เร็วช่วยให้ค้นหาความต้องการ ได้อย่างรวดเร็วและถูกต้องตรงตามความต้องการของผู้ใช้มากที่สุด ฉ) โพลีมอร์ฟิซึม (Polymorphism) คือเมธทอดมีชื่อซ้ำกันได้โดยมี พารา มิเตอร์ที่ต่างกันโดยจะตอบสนอง เมสเสจ เดียวกันแต่ให้ผลแตกต่างกัน 28 ช) อินฟอร์เมชั่น ไฮดิ้ง (Information Hiding) คือมีการซ่อนข้อมูลและขึ้น ตอนการทำงาน ลดความเสียหายต่อข้อมูล 2.4.2.2 ข้อเสีย ก) ความเร็วในการทำงาน คือการทำ การส่งผ่านเมสเสจ และการผูก เมธทอด จะต้องมีการค้นหา ข) ขนาดของโปรแกรม คือการอินเฮอร์ริแทนซ์ จะได้บางส่วนที่ไม่ต้องการ หรือไม่ต้องใช้งานมาด้วย ค) การส่งผ่านเมสเสจ คือการทำ การส่งผ่านเมสเสจ หลาย ๆ ครั้งจะมีค่าใช้ จ่ายสูง (ระยะเวลาและทรัพยากรระบบ) ง) ความซับซ้อนของโปรแกรม คือความซับซ้อนของโปรแกรมซึ่งยากต่อ การทำความเข้าใจแต่ง่ายต่อการเขียนโปรแกรม (ปัญหานี้แก้ได้โดยการมีเอกสารประกอบที่ สมบูรณ์ ซึ่งจะช่วยให้ผู้ที่ศึกษาระบบทำความเข้าใจได้โดยง่าย) 2.4.3 วงจรการพัฒนาระบบ (Object-Oriented Paradigm) 2.4.3.1 ค้นหาความต้องการ (Requirement Phase) ก) ลูกค้าจะกำหนดความต้องการซึ่งได้มาจากผู้ใช้ จะเป็นภาพรวมของ ซอฟต์แวร์ ซึ่งจะต้องเข้าใจตรงกัน พิจารณา เงื่อนไข, ข้อจำกัด, งบประมาณ, ระยะเวลา อย่างสำคัญ ข) ลูกค้าอาจมีการเปลี่ยนแปลง ความต้องการในภายหลัง เพราะฉะนั้นจะ ต้องหา ความต้องการที่ถูกต้อง แท้จริง และเข้าใจตรงกันให้ได้ ค) เน้นการค้นหา ฟังก์ชั่น รีไควเมนต์ (Function Requirement) และ น็อน ฟังก์ชั่น รีไควเมนต์ (Non-Function Requirement) ง) อาจนำโปรโตไทป์ มาช่วยในการค้นหาความต้องการที่แท้จริง จ) การทดสอบความต้องการที่แท้จริง (Requirement Phase Testing) ตรวจสอบความถูกต้องตรงกันของความต้องการ ที่ลูกค้าและผู้ใช้ต้องการจริงๆ 2.4.3.2 วิเคราะห์ (OO Analysis Phase) หรือ (Specification Phase) ก) อธิบาย ฟังก์ชั่น ต่าง ๆ ของระบบอย่างครบถ้วนจัดทำเป็นเอกสารอธิบาย ฟังก์ชั่น (Specification Document) จัดทำรายการข้อจำกัด ข้อมูลเข้า ข้อมูลออก จัดทำประมาณ การงบประมาณ และ ระยะเวลา ข) สิ่งที่ได้จาก ขั้นตอนการวิเคราะห์ได้แก่ รายการ ฟังก์ชั่นรีไควเมนต์ น็อน ฟังก์ชั่นรีไควเมนต์ ข้อจำกัด ยูสเคสไดอะแกรม อ็อบเจ็กต์ไดอะแกรม คลาสไดอะแกรม คอลาโบเรชันไดอะแกรม ซีเควนซ์ไดอะแกรม รายงานประมาณการ ระยะเวลา และค่าใช้จ่าย 29 ค) การทดสอบขั้นตอนการวิเคราะห์ (OO Analysis Phase Testing) จะมี การตรวจสอบเงื่อนไขข้อจำกัด และความสมบูรณ์ของระบบ ตรวจสอบ Diagram ต่าง ๆ จะต้อง เข้ากันได้ ไม่ขัดแย้งกัน ตรวจสอบย้อนกลับจาก เอกสารอธิบายฟังก์ชั่น ไปยัง เอกสารอธิบายความ ต้องการได้ 2.4.3.3 ออกแบบ (OO Design Phase) ก) การออกแบบจะบอกว่าจะจัดทำซอฟต์แวร์โดยมีการกำหนดโครงสร้าง และการทำงาน ประกอบด้วยโครงสร้างภายในของซอฟต์แวร์ อัลกอริทึม (Algorithm) และ โครง สร้างข้อมูล (Data Structure) ที่ใช้ และทำการออกแบบข้อมูลเข้า (Input) และข้อมูลออก (Output) ทำการออกแบบการไหลของข้อมูลและการเข้าถึงข้อมูล (Control Flow and Access Control) จากนั้นจัดแบ่งระบบออกเป็นโมดูล(Module) ย่อย ๆ โดยทำการแบ่งระบบออกเป็น ระบบย่อย หรือโมดูล ออกแบบโมดูลให้เข้ากับอุปกรณ์ ออกแบบจุดเชื่อมต่อแต่ละโมดูล จัดทำบันทึกการจัดแบ่งโมดูลไว้เป็นเอกสาร ค้นหาสิ่งที่ขาดหายไปเช่นเมธทอด หรือตัวแปรต่าง ๆ ข) สิ่งที่ได้จากการขั้นตอนการออกแบบ จะได้Architectural Design ที่จะ อธิบายซอฟต์แวร์โดยใช้ โมดูล และ Detail Design ที่จะอธิบายรายละเอียดในแต่ละโมดูล เพื่อให้ ผู้เขียนโปรแกรมนำไปใช้งานเช่น คลาส ไดอะแกรม จะถูกระบุความสัมพันธ์ แอททริบิวต์เมธทอด ไว้ครบ พร้อมที่จะนำไปเขียนโปรแกรมในขั้นตอนถัดไปได้ ค) การทดสอบขั้นตอนการออกแบบ ทำการตรวจสอบการจัดแบ่ง โมดูล ให้ เป็นไปตาม เอกสารอธิบายฟังก์ชั่น ตรวจสอบจุดเชื่อมต่อจะต้องถูกต้องไม่ขัดแย้งกัน มีความเข้า กันได้ของพารามิเตอร์ที่มีการส่งผ่านกัน 2.4.3.4 การพัฒนา (OO Programming Phase) ก) ทำการพัฒนาโดยนำเอา โมดูล ต่าง ๆ มาเขียนเป็นโปรแกรมด้วยแนวคิด การเขียนโปรแกรมเชิงวัตถุ ซึ่งจะได้ ซอร์สโค้ด ซึ่งจัดเก็บเป็นเอกสารที่นำไปใช้ในการทดสอบ โดยเปรียบเทียบผลที่คาดว่าจะได้รับกับ ผลที่ได้จากการทำงานจริงของซอฟต์แวร์ ข) สิ่งที่ได้จากขั้นตอนพัฒนาจะได้ซอร์สโค้ด ที่ถูกเขียนขึ้นตามแนวคิดการ เขียนโปรแกรมเชิงวัตถุ ค) การทดสอบขั้นตอนการพัฒนาโดยทำการตรวจสอบโปรแกรมเป็นไป ตามที่ได้ออกแบบไว้และตรวจดูด้วยสายตา (Desk Checking) ดูการคอมไพล์โปรแกรมและทำการทดสอบโปรแกรมโดยใช้ เทสเคส (Test Case) ต่าง ๆ พิจารณา ผลที่คาดว่าจะได้รับ กับ ผลที่ ได้รับจริง อาจมีการตรวจดู ซอร์สโค้ด ด้วยสายตา (Code Review) 2.4.3.5 เชื่อมต่อโมดูล (Integration Phase) 30 ก) ทำการรวมโมดูล ต่าง ๆ เข้าด้วยกันให้ทำงานตามฟังก์ชั่นได้ถูกต้อง ข) สิ่งที่ได้จากขั้นตอนการเชื่อมต่อโมดูลจะได้ระบบทั้งหมดจากทุกโมดูล ค) การทดสอบขั้นตอนการเชื่อมต่อโมดูล โดยทำการตรวจสอบการเชื่อมต่อ โมดูลเข้าด้วยกันให้เป็นไปตามที่ได้ระบุไว้ ทดสอบการเชื่อมต่อด้วยจำนวนรายการและชนิดข้อมูล ปกติ ทดสอบการทำงานของระบบโดยรวมทั้งระบบเพื่อดูการทำงานตามหน้าที่จะถูกตรวจสอบทั้ง หมดทุกฟังก์ชั่นทดสอบในด้านความถูกต้อง(Correct) และ ความแข็งแกร่ง (Robust) และให้ลูก ค้าได้ทดสอบกับสภาพแวดล้อมจริง ๆ ข้อมูลจริงและ อุปกรณ์จริง 2.4.3.6 การบำรุงรักษา (Maintenance Phase) ก) การบำรุงรักษาต้องถูกออกแบบไว้ตั้งแต่เริ่มต้น และบำรุงรักษาด้วยการ แก้ไขข้อผิดพลาดให้ถูกต้อง หรือ ปรับปรุงให้เป็นไปตามความต้องการของผู้ใช้หรือระบบอื่น ๆ ข) สิ่งที่ได้จากขั้นตอนการบำรุงรักษาจะมีการปรับปรุงเอกสารให้ทันสมัย และสมบูรณ์ ค) การทดสอบขึ้นตอนการบำรุงรักษาจะทำการทดสอบเมื่อมีการเปลี่ยน แปลงแล้วยังคงทำงานถูกต้อง และเมื่อมีการเปลี่ยนแปลงแล้วส่วนอื่น ๆ ที่ทำงานร่วมด้วยจะไม่มีข้อ ผิดพลาดเกิดขึ้นตามมา 2.4.3.6 การนำออก (Retirement Phase) ให้พิจารณาความคุ้มค่าในการบำรุงรักษา ถ้าไม่คุ้มค่าก็นำออกจากการใช้งานได้ จะไม่มีการแบ่งขั้นตอนการทดสอบ(Testing) และการจัดทำเอกสาร (Documentation) เพราะ การทดสอบจะถูกทำในทุก ๆ ขั้นตอนเพื่อให้แน่ใจได้ว่าสิ่งที่ทำในขั้นตอนนั้น ๆ ถูกต้อง ก่อนที่จะผ่านไปทำยังขั้นตอนถัดไป และการจัดทำเอกสารจะถูกจัดทำในทุก ๆ ขั้นตอนเช่นเดียวกัน จะมีเอกสารเกิดขึ้นในแต่ละขั้นตอนจะมีการบันทึกและปรับปรุงก่อนที่จะผ่านไปยังขั้นตอนถัดไป 2.4.4 กระบวนการทดสอบระบบ ปกติองค์ประกอบของระบบขนาดใหญ่ประกอบด้วย ระบบ ย่อยต่างๆ รวมกันระบบย่อยเหล่านี้เกิดจากการนำหน่วยย่อย ๆ ในระบบหรือโมดูล มาประกอบ รวมกันเช่นกัน และหน่วยย่อยที่เกิดจากการนำวิธีการงานต่าง ๆ ได้แก่ โพรซีเยอร์ (Procedure) และ ฟังก์ชั่น ประกอบรวมกัน นอกจากนี้แล้วในการทดสอบระบบเชิงวัตถุนั้นจะไม่สามารถแยก โอเปอเรชั่น ออกมาทดสอบได้เพราะ โอเปอเรชั่น จะเป็นส่วนหนึ่งของ คลาส ฉะนั้นการทดสอบ จะต้องทำในเทอมของ คลาส โดยทั่วไป การทดสอบระบบต้องดำเนินกับทุกหน่วย ๆ ที่นำมา ประกอบรวมกันเป็นระบบ ในการทดสอบระบบโดยรวมทำได้โดยใช้เทคนิคของ แบล็คบ็อกซ์ 31 เทสติ้ง (Black box Testing) ซึ่งใช้รายละเอียดในข้อกำหนดซอฟต์แวร์เพียงอย่างเดียว สำหรับ กำหนดกรณีทดสอบ บางครั้งเรียกว่าฟังก์ชันเทสติ้ง (Function Testing) 2.5 งานวิจัยที่เกี่ยวข้อง จากขั้นตอนการศึกษาและรวบรวมข้อมูล ผู้ทำได้ค้นคว้างานวิจัยที่เกี่ยวข้อง ซึ่งมีรายละเอียด ของงานวิจัยเกี่ยวกับการพัฒนาซอฟต์แวร์ด้วยแนวคิดเชิงวัตถุ และ ยูเอ็มแอล ซึ่งมีความคล้ายคลึง กับโครงงานที่ผู้ทำการวิจัยทำขึ้น ได้แก่ 2.5.1 การประเมินประสิทธิภาพของแผนภาพ ยูเอ็มแอล เพื่อการทำความเข้าใจโปรแกรม (Assessing the Efficacy of UML Diagrams for Program Understanding) โ ด ย Mr. Shihong Huang จาก University of California at Riverside และMr. Scott Tilley จาก Florida Institute of Technology งานวิจัยนี้ทำการประเมินประสิทธิภาพของแผนภาพ ยูเอ็มแอล โดยเน้นในการช่วยให้นัก เขียนโปรแกรมทำความเข้าใจโปรแกรมได้ง่ายขึ้น นักเขียนโปรแกรมมักจะใช้รูปภาพกราฟฟิคมา ใช้ในเอกสารเพื่ออธิบายซอฟต์แวร์ เป็นเทคนิคที่ช่วยให้เข้าใจสิ่งที่ซับซ้อนได้ง่ายขึ้น แต่มีปัญหา เรื่องรูปภาพกราฟฟิคที่เหมาะสมมาอธิบายโปรแกรมที่มีความเฉพาะเจาะจง ยูเอ็มแอล เป็นตัวแบบ รูปภาพกราฟฟิคมาตรฐานสำหรับซอฟต์แวร์ งานวิจัยชิ้นนี้มุ่งเน้นไปที่ประสิทธิภาพการใช้งานของ ยูเอ็มแอล เพื่อช่วยให้นักเขียนโปรแกรมเข้าใจ และจะเกี่ยวข้องกับการวิเคราะห์อนุกรมของแผน ภาพ ยูเอ็มแอล และการให้รายละเอียดที่เกี่ยวข้องกับซอฟต์แวร์ 2.5.2 การริเริ่มแนวคิดเชิงวัตถุกับระบบที่ซับซ้อนและมีขนาดใหญ่ (Introducing Object Orientation into Large and Complex Systems) โดย Mr. Deubler และ Mr. M. Koestler งานวิจัยชิ้นนี้อธิบายการใช้แนวคิดเชิงวัตถุกับระบบที่มีความซับซ้อนสูง ซึ่งระบบจะต้องมี ความเข้ากันได้อย่างราบรื่นเมื่อมีการนำส่วนของซอฟต์แวร์ใหม่มาเพิ่มเติมเพื่อรองรับการเปลี่ยน แปลงที่เกิดขึ้นจริงในอนาคต ส่วนของซอฟต์แวร์ใหม่จะต้องทำงานร่วมกับตัวซอฟต์แวร์เดิมได้โดย ไม่ติดขัด แนวคิดเชิงวัตถุช่วยให้การออกแบบซอฟต์แวร์ได้มีการคำนึงถึงการเปลี่ยนแปลงใน อนาคตด้วย และแนวคิดเชิงวัตถุจะสามารถประยุกต์ใช้ในระบบที่มีโครงสร้างต่างกันได้ด้วย บทที่ 3 วิธีการดำเนินงาน วิธีการดำเนินงานของการส่งเสริมการเรียนรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุด้วยเกมนัก รบ ผู้พัฒนาได้แบ่งวิธีการดำเนินงานดังนี้ 3.1 การวิเคราะห์ระบบ 3.2 การออกแบบระบบ 3.3 การพัฒนาระบบ 3.4 การทดสอบระบบ 3.1 การวิเคราะห์ระบบ เกมนักรบ (Warrior Code) เป็นเกมที่ให้ผู้เล่นได้เล่นเกม โดยผู้เล่นสามารถจะเลือกทีมจาก รายการทีมที่มีมาให้และกำหนดรอบที่ต้องการจะเล่น เมื่อเริ่มเล่น เกมจะเล่นอัตโนมัติ แต่ละทีมจะสู้ รบกันตามพฤติกรรมของโรบ็อทแต่ละตัวที่ได้กำหนดไว้ เมื่อเกมจบลงจะมีการสรุปผลการเล่น ซึ่งผู้ เล่นสามารถเรียกดูได้ในภายหลังเพื่อเปรียบเทียบกับทีมอื่น ๆ หรือผู้เล่นคนอื่น ๆ ผู้เล่นสามารถเลือกที่จะกำหนดรูปแบบการทำงานของโรบ็อทได้เองโดยใช้ส่วนของปรับ ปรุงโรบ็อท ( EditRobot) ซึ่งให้ผู้เล่นเลือกชนิดของโรบ็อทที่ต้องการ และตั้งชื่อให้ จากนั้นก็ กำหนดพฤติกรรมของโรบ็อท ซึ่งผู้เล่นต้องเขียนโปรแกรมภาษาจาวา ด้วยแนวความคิดการเขียน โปรแกรมเชิงวัตถุ และจะมีส่วนที่จะอธิบายหลักวิชาของการเขียนโปรแกรมเชิงวัตถุที่สอดคล้องกับ เกม เพื่อช่วยให้ผู้ใช้มีความรู้ความเข้าใจและความชำนาญในแนวคิดเชิงวัตถุมากยิ่งขึ้น เกมนักรบถูกพัฒนาและนำไปเล่นโดยใช้ภาษาจาวา ซึ่งในการพัฒนาซอฟต์แวร์มีภาษา คอมพิวเตอร์มากมายเช่น ภาษา BASIC, Cobol, Pascal, C, C++, Java และอื่น ๆซึ่งแต่ละภาษา ก็มีลักษณะจุดเด่นจุดด้อยแตกต่างกันไป ขึ้นอยู่กับวัตถุประสงค์ของการออกแบบภาษานั้น ๆ ผู้ พัฒนาเกมนักรบได้เลือกใช้ภาษาจาวาด้วยเหตุผลเพราะว่า ภาษาจาวาเป็นภาษาที่สามารถอธิบาย ความเป็นภาษาเชิงวัตถุได้ดีที่สุดเมื่อเทียบกับนิยามความเป็นภาษาเชิงวัตถุของ อลัน เคร์ ดังที่ได้ กล่าวมาแล้วในบทที่ 2 33 3.1.1 คำนิยาม (Term) ผู้เล่น (Player) หมายถึง คนที่เล่นเกม การเล่นเกม (PlayGame) หมายถึง ส่วนของการเริ่มเล่นเกม การสร้างทีม (CreateNewTeam) หมายถึง ส่วนของการสร้างทีมรบเพื่อนำไปเล่น การปรับปรุงโรบ็อท (EditRobot) หมายถึง ส่วนของการสร้างหรือปรับปรุงโรบ็อท การเสนอแนวคิดเชิงวัตถุ (OOConcept) หมายถึง ส่วนนำเสนอแนวคิดเชิงวัตถุ การเสนอประวัติการเล่น (History) หมายถึง ส่วนนำเสนอประวัติการเล่น 3.1.2 ฟังก์ชั่นนัล รีไควเมนต์ (Functional Requirement) 3.1.2.1 ผู้เล่น เล่นเกม (PlayGame) ก) ผู้เล่นเลือกทีมที่ต้องการจากที่มีมาให้ในรายการของทีมที่ถูกสร้างไว้แล้ว ข) ผู้เล่นสามารถกำหนดรอบของการเล่นได้ตามต้องการ ค) ผู้เล่นสามารถเลือกทีมที่สร้างขึ้นเองจากส่วนของ CreateNewTeam ง) เมื่อการรบสิ้นสุดลงจะมีผลการเล่นให้ดูและจัดกับไว้ใน History 3.2.2.1 ผู้เล่น สร้างทีมใหม่ (CreateNewTeam) ก) ผู้เล่นสามารถเลือกสร้างทีมซึ่งประกอบด้วยโรบ็อทชนิดต่าง ๆ ได้ มา เป็นทีมที่ผู้เล่นต้องการได้ซึ่งต้องเลือกโรบ็อทอย่างน้อย 1 ตัวขึ้นไป ข) ผู้เล่นสามารถตั้งชื่อทีมและคำอธิบายทีมที่สร้างขึ้นและใส่ชื่อผู้สร้างได้ ค) ผู้เล่นสามารถบันทึกทีมที่สร้างขึ้นใหม่เพื่อนำไปใช้เลือกในการเล่นได้ 3.2.2.3 ผู้เล่น เลือกปรับปรุงหรือสร้างโรบ็อทได้ (EditRobot) ก) ผู้เล่นสามารถเลือกที่จะสร้างโรบ็อทใหม่จากชนิดต่าง ๆ ของโรบ็อทที่ กำหนดไว้ได้ ข) ผู้เล่นเลือกว่าจะปรับปรุงโรบ็อทเดิมที่มีอยู่แล้วก่อนหน้าได้ ค) ผู้เล่นสามารถบันทึกโรบ็อทที่ปรับปรุงหรือสร้างใหม่ เพื่อนำไปใช้เลือก ใน การเล่นได้ หรือแก้ไขภายหลังได้ ซึ่งการบันทึกจะถูกกำหนดไปยังไดเร็กทอรี่ปลายทางปกติ ของโรบ็อทแต่ละชนิดที่แตกต่างกัน ง) ผู้เล่นสามารถศึกษาและทำความเข้าใจกับแนวคิดการเขียนโปรแกรมเชิง วัตถุได้ โดยจะมีการนำเสนอหลักการของแนวคิดเชิงวัตถุให้ผู้เล่นอ่านขณะที่กำลังเขียนโปรแกรม เพื่อปรับปรุงโรบ็อทเดิมหรือสร้างโรบ็อทใหม่ จ) ผู้เล่นเลือกจะคอมไพล์โปรแกรมของโรบ็อทที่ปรับปรุงหรือสร้างใหม่ได้ 34 3.2.2.4 ผู้เล่น ดูประวัติการเล่น (History) ก) เลือกที่จะดูประวัติการเล่นเพื่อเปรียบเทียบศักยภาพของแต่ละทีมโดย เรียงลำดับจากใหม่ไปเก่า โดยจะแสดงผล 4 ลำดับแรกจากทีมที่มีคะแนนสูงสุดของการเล่นในแต่ ละครั้งเท่านั้น 3.1.3 น็อนฟังก์ชั่นนัลรีไควเมนต์ (Non-Functional Requirement) 3.1.3.1 ติดต่อกับผู้ใช้ด้วยภาพกราฟฟิคและมีการพัฒนาซอฟต์แวร์ที่แบ่งเป็นส่วน ๆ 3.1.3.2 ทำงานได้รวดเร็ว ไม่เกิดการกระตุกของภาพ 3.1.4 กฎกติกาของเกม 3.1.4.1 โรบ็อทชนิด Camp มีคุณสมบัติคือ ไม่สามารถเคลื่อนที่ได้ ไม่มีอาวุธ มีค่า พลังสูงกว่า 120 แต้ม ภาพที่ 3-1 แสดง โรบ็อทชนิด Camp 3.1.4.2 โรบ็อทชนิด Cannon มีคุณสมบัติคือ ไม่สามารถเคลื่อนที่ได้ มีอาวุธยิงโร บ็อทอื่นได้ มีค่าพลัง 100 แต้ม ภาพที่ 3-2 แสดง โรบ็อทชนิด Cannon 3.1.4.3 โรบ็อทชนิด Missile มีคุณสมบัติคือ สามารถเคลื่อนที่ได้ มีอาวุธยิงโรบ็อท อื่นได้มีค่าพลังสูงกว่า 100 แต้ม ภาพที่ 3-3 แสดง โรบ็อทชนิด Missile 3.1.4.4 โรบ็อทชนิด Tank มีคุณสมบัติคือ สามารถเคลื่อนที่ได้ มีอาวุธยิงโรบ็อทอื่น ได้ มีค่าพลัง 100 แต้ม 35 ภาพที่ 3-4 แสดง โรบ็อทชนิด Tank 3.1.4.5 โรบ็อทชนิด Tractor มีคุณสมบัติคือ สามารถเคลื่อนที่ได้ ไม่มีอาวุธ มีค่าพลัง สูงกว่า 120 แต้ม ภาพที่ 3-5 แสดง โรบ็อทชนิด Tractor 3.1.4.6 โรบ็อทจะแสดงชื่อด้านล่างและค่าพลังด้านบนของโรบ็อท ภาพที่ 3-6 แสดง โรบ็อทพร้อมชื่อโรบ็อทด้านล่างและค่าพลังด้านบน 3.1.4.7 การคำนวณค่าพลัง ก) โรบ็อทใดที่ยิงโรบ็อทอื่น จะเสียค่าพลัง 1 ถึง 3 แต้มขึ้นอยู่กับการแบ่ง พลังจากโรบ็อทไปยังกระสุน ข) กระสุนที่ยิงออกไปมีค่าพลังในการทำลาย 1 ถึง 3 แต้มขึ้นอยู่กับการแบ่ง พลังมาจากโรบ็อท ค) ถ้ากระสุนมีค่าพลังในการทำลาย 1 แต้มโรบ็อทใดที่ถูกยิงจะเสียค่าพลัง 4 แต้ม แต่ถ้ากระสุนมีค่าพลังในการทำลายมากกว่า 1 แต้มโรบ็อทใดที่ถูกยิงจะเสียค่าพลังไป (2 * (ค่าพลังในการทำลายของกระสุน -1)) แต้ม ง) โรบ็อทใดยิงโดนโรบ็อทอื่นจะได้ค่าพลังเพิ่มเท่ากับ (3 * พลังในการ ทำลายที่ยิงออกไป) จ) โรบ็อทใดค่าพลังน้อยกว่าหรือเท่ากับ 0 จะถูกทำลาย 36 3.2 การออกแบบระบบ 3.2.1 ยูสเคส ไดอะแกรม ในการออกแบบระบบได้ใช้หลักการของ ยูเอ็มแอล ซึ่งมีไดอะแกรม ต่าง ๆ ที่ได้จากการวิเคราะห์โดยมียูสเคสไดอะแกรมที่อธิบายภาพรวมของเกมนักรบ ซึ่งประกอบ ไปด้วยยูสเคสต่าง ๆ ที่ทำหน้าที่หลักในการให้บริการผู้เล่น ซึ่งประกอบได้ด้วย ยูสเคสต่างๆ ดังภาพ ที่ 3-7 ภาพที่ 3-7 แสดง ยูสเคส ไดอะแกรม (Use Case Diagram) ตารางที่ 3-1 แสดง Class Responsibility Collaborations (CRC) robots Responsibility Collaborators จัดเก็บและรักษาข้อมูลของโรบ็อททุกชนิด บริการข้อมูลของโรบ็อททุกชนิด Team Camp : extends Cannon : extends Missile : extends Tank : extends Tractor : extends 37 ตารางที่ 3-1 แสดง Class Responsibility Collaborations (ต่อ) Team Responsibility Collaborators จัดเก็บและรักษาข้อมูลทีมทุก ทีม และ เป็นที่เก็บ Robots ด้วย Robots templates Responsibility Collaborators จัดเก็บและให้บริการข้อมูลที่เป็นแบบฟอร์มพื้นฐานของโรบ็อท แต่ละชนิด None historydb Responsibility Collaborators จัดเก็บและให้บริการข้อมูลประวัติการเล่นครั้งก่อนหน้า None ooconcpetdb Responsibility Collaborators จัดเก็บและให้บริการข้อมูลในรูปแบบของภาพและข้อความที่มี เกี่ยวข้องกับแนวคิดการเขียนโปรแกรมเชิงวัตถุ None 3.2.2 Use Case Specification Play Game 3.2.2.1 Brief Description ยูสเคสนี้ใช้เป็นตัวอธิบายส่วนของโปรแกรมที่ให้ผู้เล่น เลือกเพื่อเล่นเกม 3.2.2.2 Flow of Events ยูสเคสนี้เริ่มต้นทำงานเมื่อผู้เล่นเลือก Play Game จาก เมนู (Menu) ของเกม ก) Main Flow 1. ผู้เล่นเข้ามาที่ เมนู ของเกม 2. ผู้เล่นเลือก Play Game เพื่อเข้าสู่ส่วนของการเล่นเกม 3. ผู้เล่นจะเจอกับหน้าต่าง Play Game เพื่อเลือกทีมที่ต้องการนำไปต่อสู้จากรายการชื่อทีม ที่มีให้เลือก 4. การเลือกสามารถเลือกได้ครั้งละ 1 ทีมหรือเลือกทั้งหมดโดยต้องเลือกอย่างน้อย 1 ทีม 5. ผู้เล่นสามารถยกเลิกการเลือกทีมได้ โดยสามารถนำออกครั้งละ 1 ทีม หรือทั้งหมดได้ 6. ผู้เล่นสามารถกำหนดจำนวนรอบของการต่อสู้ได้ตามต้องการ 7. ผู้เล่นเลือก เริ่มเกม เพื่อให้เกมเริ่มเล่น เกมเริ่มเล่นอัตโนมัติ 8. ผู้เล่นสามารถเลือกที่จะหยุด หรือหยุดชั่วคราวระหว่างที่การต่อสู้กำลังดำเนินการอยู่ได้ 38 9. เมื่อเกมสิ้นสุด ไม่ว่าผลจะเป็นเช่นไร ผู้เล่นจะพบกับหน้าต่าง ผลการเล่น ซึ่งจะแสดงผล การรบของทุกทีมเรียงลำดับจากมากไปน้อย และจะถูกบันทึกไว้ในประวัติการเล่น เพื่อใช้ดูได้ใน ภายหลังโดยจะจัดเก็บเฉพาะ 4 อันดับแรกเท่านั้น 10. กลับสู่ เมนู ข) Alternate Flow 1. None 3.2.2.3 Associations ก) Actor 1. The actor starting this use case is 1.1 Player 2. Actors also involved this use case 1.1 None ข) Association to Other Use Case 1. None ค) Association from Other Use Case 1. None 3.2.2.4 Pre-Condition ก) None 3.2.2.5 Special Requirements ก) None ภาพที่ 3-8 แสดง Analysis Classes ของยูสเคส Play Game ภาพที่ 3-9 แสดง Analysis Model ของยูสเคส Play Game 39 ภาพที่ 3-10 แสดง Collaboration Diagram ของยูสเคส Play Game ภาพที่ 3-11 แสดง Sequence Diagram ของยูสเคส Play Game 40 3.1.4 Use Case Specification CreateNewTeam 3.2.3.1 Brief Description ยูสเคสนี้ใช้อธิบายส่วนของโปรแกรมที่ให้ผู้เล่นได้มี โอกาสสร้างทีมโดยการเลือกโรบ็อทชนิดต่าง ๆ มาประกอบกันเป็นทีมเพื่อใช้ในการต่อสู้ 3.2.3.2 Flow of Events ยูสเคสนี้เริ่มต้นทำงานเมื่อผู้เล่นเลือก CreateNewTeam จาก เมนู ก) Main Flow 1. ผู้เล่นเข้ามาที่ เมนู ของเกม 2. ผู้เล่นเลือก Create Team เพื่อสร้างกำลังรบใหม่ของแต่ละทีม 3. จากนั้นผู้เล่นจะเจอกับหน้าต่างที่ใช้ในการสร้างทีม 4. ผู้เล่นเลือกโรบ็อทโดยเลือกทีละชนิดหรือเลือกจากทุกชนิดก็ได้ สามารถเลือกไปสร้าง ทีมโดยเลือกได้ที่ละ 1 ตัวหรือทุกตัวก็ได้ 5. สามารถนำโรบ็อทที่ถูกเลือกออกจากรายการได้โดยนำออกที่ละตัวหรือทั้งหมดก็ได้ 6. ผู้เล่นจะต้องตั้งชื่อทีม คำอธิบายของทีม และอาจใส่ชื่อผู้สร้างด้วยหรือไม่ก็ได้ 7. ผู้เล่นเลือกให้สร้างทีมที่ระบุไว้ซึ่งจะสามารถนำไปใช้เล่นต่อสู้ได้ทันที ข) Alternate Flow 1. None 3.2.3.3 Associations ก) Actor 1. The actor starting this use case is 1.1 Player 2. Actors also involved this use case 1.2 None ข) Association to Other Use Case 1. None ค) Association from Other Use Case 1. None 3.2.3.4 Pre-Condition ก) None 3.2.3.5 Special Requirements ก) None 41 ภาพที่ 3-12 แสดง Analysis Classes ของยูสเคส Create New Team ภาพที่ 3-13 แสดง Analysis Model ของยูสเคส Create New Team ภาพที่ 3-14 แสดง Collaboration Diagram ของยูสเคส Create New Team 42 ภาพที่ 3-15 แสดง Sequence Diagram ของยูสเคส Create New Team 3.2.4 Use Case Specification EditRobot 3.2.4.1 Brief Description ยูสเคสนี้ใช้อธิบายส่วนของโปรแกรมที่ให้ผู้เล่นได้มี โอกาสปรับปรุงโรบ็อทเดิมหรือสร้างโรบ็อทใหม่จากชนิดที่กำหนดให้เพื่อนำไปใช้ในแต่ละทีมซึ่ง ทำให้ทีมมีศักยภาพสูงขึ้นตามต้องการ โดยให้ผู้เล่นสามารถเขียนโปรแกรมเพิ่มเติมได้ตามต้อง 3.2.4.2 Flow of Events ยูสเคส นี้เริ่มต้นทำงานเมื่อ ผู้เล่นเลือก EditRobot จากเมนู ก) Main Flow 1. ผู้เล่นเข้ามาที่ เมนู ของเกม 2. ผู้เล่นเลือก EditRobot เพื่อเข้าสู่การแก้ไขปรับปรุงกำลังรบของแต่ละทีม 3. ผู้เล่นจะเจอกับหน้าต่างการแก้ไขซึ่งมี เมนูให้เลือกที่จะสร้างโรบ็อทใหม่ตามชนิดที่ กำหนดไว้ หรือนำโรบ็อทเดิมที่มีอยู่แล้วมาปรับปรุง แก้ไข 4. ผู้เล่นเลือกสร้างโรบ็อทใหม่ โดยผู้เล่นจะตั้งชื่อโรบ็อทซึ่งเริ่มต้นด้วยอักษรตัวใหญ่ จาก นั้นมีชนิดของโรบ็อทให้เลือกซึ่งผู้เล่นจะต้องเลือกตามที่กำหนดไว้เท่านั้น หากเลือกนอกเหนือจาก นั้นจะไม่สนับสนุนในการนำไปใช้งาน โดยที่ชนิดของโรบ็อทจะเริ่มต้นด้วยอักษรตัวเล็ก 5. ผู้เล่นจะได้แบบฟอร์มของโปรแกรมพื้นฐานที่กำหนดให้ซึ่งจะแตกต่างกันตามแต่ชนิด ของโรบ็อทที่เลือก และให้ผู้เล่นสร้างเพิ่มเติมตามต้องการได้ 43 6. ในการเปิดโรบ็อทมาแก้ไขปรับปรุงจะมีให้ผู้เล่นเลือกจากไดเร็กทอรี่ที่เป็นชนิดของโร บ็อทนั้น ๆ 7. ผู้เล่นเลือกที่จะบันทึก หรือบันทึกเป็นได้ โดยมีไดเร็กทอรี่ปลายทางที่ตรงกับชนิดของโร บ็อทนั้น ๆ ข) Alternate Flow 1. ถ้าโปรแกรมที่แก้ไขปรับปรุงคอมไพล์ ไม่ผ่านจะสามารถบันทึกไฟล์เก็บไว้เพื่อจะนำมา ใช้ในอนาคตได้ แต่ไม่สามารถเรียกใช้จากส่วนของ PlayGame ได้ 2. การเลือกชนิดของโรบ็อทจะต้องเลือกจากชนิดที่ระบุเท่านั้น 3.2.4.3 Associations ก) Actor 1. The actor starting this use case is 1.1 Player 2. Actors also involved this use case 2.1 None ข) Association to Other Use Case 1. None ค) Association from Other Use Case 1. OOConcept 3.2.4.4 Pre-Condition ก) None 3.2.4.5 Special Requirements ก) None ภาพที่ 3-16 แสดง Analysis Classes ของยูสเคส Edit Robot 44 ภาพที่ 3-17 แสดง Analysis Model ของยูสเคส Edit Robot ภาพที่ 3-18 แสดง Collaboration Diagram ของยูสเคส Edit Robot 45 ภาพที่ 3-19 แสดง Sequence Diagram ของยูสเคส Edit Robot 3.2.5 Use Case Specification History 3.2.5.1 Brief Description ยูสเคส นี้ใช้อธิบายส่วนของโปรแกรมที่ให้ผู้เล่นดู ประวัติการเล่นครั้งก่อนหน้านี้ได้ โดยนำเสนอเรียงลำดับจากการเล่นครั้งล่าสุดไปยังการเล่น ครั้งแรก ข้อมูลในการเล่นแต่ละครั้งจะนำเสนอชื่อทีม คะแนน โดยเรียงลำดับจากทีมที่ได้คะแนน มากที่สุด ไปจนถึงอันดับที่ 4 เท่านั้น 3.2.5.2 Flow of Events ยูสเคส นี้เริ่มต้นทำงานเมื่อผู้เล่นเลือก History จาก เมนู ก) Main Flow 1. ผู้เล่นเข้ามาที่ เมนู ของเกม 2. ผู้เล่นเลือก History เพื่อดูประวัติการรบ ที่ผ่านมา 3. เกมจะแสดงประวัติการรบที่ผ่านมาโดยมีข้อมูลคือ วันเวลาที่เล่น ชื่อทีม และคะแนน ข) Alternate Flow 1. None 3.2.5.3 Associations ก) Actor 1. The actor starting this use case is 1.1 Player 2. Actors also involved this use case 2.1 None 46 ข) Association to Other Use Case 1. None ค) Association from Other Use Case 1. None 3.2.5.4 Pre-Condition ก) จะใช้งานได้เมื่อมีการเล่นมาแล้วอย่างน้อย 1 ครั้ง 3.2.5.5 Special Requirements ก) None ภาพที่ 3-20 แสดง Analysis Classes ของยูสเคส History ภาพที่ 3-21 แสดง Analysis Model ของยูสเคส History ภาพที่ 3-22 แสดง Collaboration Diagram ของยูสเคส History 47 ภาพที่ 3-23 แสดง Sequence Diagram ของยูสเคส History 3.2.6 Use Case Specification OOConcept 3.2.6.1 Brief Description ยูสเคส นี้อธิบายถึงส่วนของโปรแกรมซึ่งจะถูกส่วนของ EditRobot เรียกใช้เพื่อแสดงข้อมูลอธิบายของแนวคิดการเขียนโปรแกรมเชิงวัตถุ 3.2.6.2 Flow of Events ยูสเคส นี้เริ่มต้นทำงานโดยจะถูกเรียกใช้ในขั้นตอนของ ส่วนอื่นๆ คือ EditRobot ก) Main Flow 1. ผู้เล่นเลือก EditRobot จากเมนูเพื่อเข้าสู่ปรับปรุง หรือ การสร้างโรบ็อทใหม่ 2. ผู้เล่นจะเจอกับหน้าต่าง Editor ในส่วนนี้ผู้เล่นจะสามารถเลือกสร้างโรบ็อทใหม่หรือ เปิดโรบ็อทเก่าขึ้นมาแก้ไขปรับปรุงซึ่งมีหน้าต่าง Editor มาให้ผู้เล่นใช้ในการสร้างหรือปรับปรุง โรบ็อทเก่าเมื่อผู้เล่นทำการแก้ไขหรือสร้างโรบ็อทโดยการเขียนโปรแกรมลงในหน้าต่าง รับการแก้ไขระบบจะนำคำที่ผู้เล่นพิมพ์เข้าไป ไปเปรียบเทียบกับ คีย์เวิร์ด (Key Word) ของข้อ มูลการเขียนโปรแกรมเชิงวัตถุ ก็จะมีหน้าต่าง OOConcept ขึ้นมานำเสนอข้อมูลที่เกี่ยวข้อง 48 3. ในส่วนของหน้าต่าง OOConcept มีช่องให้ผู้เล่นป้อนคำที่ต้องการทราบข้อมูลเพิ่มเติม ที่เกี่ยวข้องกับการเขียนโปรแกรมเชิงวัตถุ ข) Alternate Flow 1. None 3.2.6.3 Associations ก) Actor 1. The actor starting this use case is 1.1 Player 2. Actors also involved this use case 2.1 None ข) Association to Other Use Case 1. None ค) Association from Other Use Case 1. Edit Team 3.2.6.4 Pre-Condition ก) จะเริ่มทำงานมาจากส่วนของ Edit Robot เมื่อเจอ คีย์เวิร์ด แรก 3.2.6.5 Special Requirements ก) None ภาพที่ 3-24 แสดง Analysis Classes ของยูสเคส OOConcept ภาพที่ 3-25 แสดง Analysis Model ของยูสเคส OOConcept 49 ภาพที่ 3-26 แสดง Collaboration Diagram ของยูสเคส OOConcept ภาพที่ 3-27 แสดง Sequence Diagram ของยูสเคส OOConcept 3.2.7 คลาสไดอะแกรม (Class Diagram) 50 Class diagram ภาพที่ 3-28 แสดง Class Diagram 51 ภาพที่ 3-29 แสดง Class Diagram ของ Play Game ภาพที่ 3-30 แสดง Class Diagram ของ Create New Team 52 ภาพที่ 3-31 แสดง Class Diagram ของ Edit Robot ภาพที่ 3-32 แสดง Class Diagram ของ History 53 ภาพที่ 3-33 แสดง Class Diagram ของ OOConcept ภาพที่ 3-34 แสดง StateChart Diagram ของวัตถุ Battle 54 3.3 การพัฒนาระบบ การพัฒนาเกมนักรบ เริ่มจากการศึกษาแนวคิดการเขียนโปรแกรมเชิงวัตถุและศึกษาการ ทำงานพื้นฐานของเกมและโรบ็อท แล้วจึงเริ่มวิเคราะห์และออกแบบโปรแกรมให้สามารถทำงาน ได้ตามวัตถุประสงค์ที่ได้ออกแบบไว้ และดำเนินการพัฒนาโปรแกรมด้วยภาษาจาวา และใช้ โปรแกรม Sun One Studio เป็นเครื่องมือหลักในการพัฒนาโปรแกรม ในการพัฒนาเกมนักรบ จะประกอบด้วย แพคเกจต่าง ๆ คือ การเล่นเกมใช้ชื่อแพคเกจคือ playgame การสร้างทีมใหม่ใช้ชื่อแพคเกจคือ createnewteam การสร้างและปรับปรุงแก้ไขโร บ็อทใช้ชื่อแพคเกจคือ editrobot การดูประวัติการเล่นใช้ชื่อแพคเกจคือ history การนำเสนอแนว คิดการเขียนโปรแกรมเชิงวัตถุ ใช้ชื่อแพคเกจคือ ooconcept เมื่อเขียนโปรแกรมในแพคเกจต่างๆ เสร็จเรียบร้อยแล้ว จะนำแพคเกจทั้งหมดมารวมกันและ สร้างไดเรกทอรี่จัดเก็บไฟล์ภาพชื่อ resource จากนั้นนำทั้งหมดสร้างไฟล์นามสกุล *.jar ขึ้นด้วย คำสั่ง jar cf wc.jar META-INF playgame createnewteam editrobot history ooconcept resource robocode เมื่อได้ไฟล์ wc.jar แล้วให้ทำการปรับปรุงไฟล์ที่ชื่อ Manifest.mf ซึ่งอยู่ภายในwc.jar ด้วย ไฟล์ที่สร้างขึ้นใหม่เพื่อกำหนดการเริ่มต้นการทำงาน (Main class) โดยผู้พัฒนาได้สร้างไฟล์ชื่อ mf1.mf จากนั้นปรับปรุงไฟล์ Mainfest.mf ด้วยคำสั่ง jar umf mf1.mf wc.jar เมื่อได้ไฟล์ wc.jar ที่ปรับปรุงไฟล์ Mainfest.mf แล้วจะนำไฟล์มารวมกับไดเร็กทอรี่ที่ใช้ จัดเก็บข้อมูลต่าง ๆ ซึ่งประกอบด้วย ไดเร็กทอรี่ battle จัดเก็บคุณสมบัติเริ่มต้นของสนามรบ ไดเร็กทอรี่ compilers ใช้ในการคอมไพล์โปรแกรมที่ผู้เล่นสร้างหรือปรับปรุงโรบ็อท ไดเร็กทอรี่ historydb จัดเก็บข้อมูลประวัติการเล่น ไดเร็กทอรี่ ooconceptdb จัดเก็บข้อมูลแนวคิดการเขียน โปรแกรมเชิงวัตถุ ไดเร็กทอรี่ robots จัดเก็บโรบ็อทชนิดต่าง ๆ ไดเร็กทอรี่ templates จัดเก็บ แบบฟอร์มเริ่มต้นของโรบ็อทชนิดต่าง ๆ เมื่อรวมไดเร็กทอรี่ต่าง ๆ เข้ากับไฟล์ wc.jar แล้ว หากเครื่องคอมพิวเตอร์ที่ใช้ได้มีการติดตั้ง Java Web Start ไว้แล้ว จะสามารถเริ่มเล่นเกมได้โดยการคลิ๊กเลือกบนไฟล์ wc.jar หากไม่ได้ติด ตั้ง Java Web Start จะต้องติดตั้งเกมนักรบจากไฟล์ที่ชื่อ wc_windows_1_0 ซึ่งได้จากการสร้าง ไฟล์ติดตั้งด้วยโปรแกรมชื่อ install4j ซึ่งสามารถนำไปติดตั้งบนเครื่องคอมพิวเตอร์ที่ใช้ระบบ ปฏิบัติการวินโดว์(Windows) ได้ 3.4 การทดสอบระบบ ในส่วนของการทดสอบระบบจะใช้กระบวนการทดสอบแบบแบล็กบอกซ์ (Black Box Testing) ซึ่งเป็นการทดสอบการทำงานของระบบโดยรวมทั้งหมดว่ามีกระบวนการทำงานถูกต้อง 55 ตามวัตถุประสงค์ที่ต้องการหรือไม่ โดยการทดสอบจะเป็นการป้อนข้อมูลที่ถูกต้อง (Valid) และ การป้อนข้อมูลที่ไม่ถูกต้อง (Invalid) เข้าสู่ระบบ (Null) เพื่อให้ระบบทำการประมวลผลข้อมูล พร้อมทั้งแสดงผลลัพธ์ที่ได้จากการทำงาน ดังต่อไปนี้ 3.4.1 การเลือกทีมเพื่อนำไปเล่นควรเลือกอย่างน้อย 2 ทีมขึ้นไปซึ่งมีข้อความแนะนำไว้ หาก เลือกเพียง 1 ทีมจะมีข้อความเตือนให้ผู้เล่นทราบ ภาพที่ 3-35 แสดงเตือนให้ทราบว่าควรเลือกอย่างน้อย 2 ทีม 3.4.2 ทีมจะต้องประกอบด้วยโรบ็อทอย่างน้อย 2 ตัวขึ้นไป หาผู้เล่นเลือกเพียง 1 ตัว ปุ่ม Next จะไม่ทำงาน จนกว่าผู้เล่นจะเลือกโรบ็อทเท่ากับหรือมากกว่า 2 ตัว ภาพที่ 3-36 ให้ผู้เล่นเลือกโรบ็อทครบ 2 ตัวเป็นอย่างน้อย 56 3.4.3 การกรองข้อมูลเพื่อสร้างทีมใหม่จะต้องกรองให้ครบตามที่กำหนด หากไม่ครบปุ่มกด จะไม่ทำงาน ภาพที่ 3-37 ให้ผู้เล่นกรองข้อมูลจนครบตามกำหนดจึงทำงานต่อได้ 3.4.4 การสร้างโรบ็อทใหม่ชื่อโรบ็อทจะใช้อักษรตัวแรกจะต้องเป็นตัวใหญ่เท่านั้น หากผู้เล่น ใช้อักษรตัวเล็กเริ่มต้นชื่อโรบ็อทจะถูกเปลี่ยนเป็นอักษรตัวใหญ่ทันที ภาพที่ 3-38 ชื่อโรบ็อทจะต้องเริ่มต้นด้วยอักษรตัวใหญ่ 57 3.4.5 การเลือกชนิดของโรบ็อท อักษรตัวแรกจะต้องเป็นตัวใหญ่เท่านั้น หากผู้เล่นใช้อักษร ตัวเล็กจะถูกเปลี่ยนเป็นอักษรตัวใหญ่ทันที ภาพที่ 3-39 ชื่อชนิดของโรบ็อทจะต้องเป็นตัวใหญ่ นอกจากการทดสอบแบบแบล็กบอกซ์แล้วจะมีการนำเอาโปรแกรมดังกล่าวให้ผู้ที่มีส่วน เกี่ยวข้องกับระบบทำการทดสอบเพื่อหาประสิทธิภาพและประเมินผล ด้วยเครื่องมือทดสอบระบบ ซึ่งเป็นแบบสอบถาม โดยมีผู้ร่วมทดสอบจำนวน 18 คนซึ่งเป็น นักศึกษา หรือคนที่ทำงานด้านการ เขียนโปรแกรมที่เคยผ่านการเรียนรู้การเขียนโปรแกรมด้วยแนวคิดเชิงวัตถุและการเขียนโปรแกรม ด้วยภาษาจาวามาก่อน โดยจะใช้แบบสอบถามโดยมีวัตถุประสงค์เพื่อประเมินประสิทธิภาพ โดย แบ่งแบบการประเมินประสิทธิภาพเป็น 2 ตอน คือ ตอนที่ 1 ข้อมูลทั่วไปของผู้ตอบแบบสอบถาม ตอนที่ 2 ความคิดเห็นของผู้ประเมินเกี่ยวกับประสิทธิภาพของระบบ ในแบบสอบถามตอนที่ 2 ซึ่งวัดค่าออกเป็น 5 ระดับ ซึ่งกำหนดให้ค่าคะแนนดังนี้ ตารางที่ 3-2 เกณฑ์การให้คะแนนในแบบสอบถาม ลักษณะคำตอบ การให้คะแนน ระดับดีมาก 5 ระดับดี 4 ระดับปานกลาง 3 ระดับน้อย 2 ระดับน้อยมาก 1 58 ค่าสถิติที่ใช้วิเคราะห์ข้อมูลคือ ค่ามัชฌิมเลขคณิต (Mean) เป็นค่าที่นิยมใช้มากที่สุด ในการ หาแนวโน้มเข้าสู่ส่วนกลาง (Measures of Central Tendency) โดยใช้สูตร (3-1) เมื่อ x แทน หน่วยน้ำหนัก N แทน จำนวนข้อมูล f แทน ความถี่ของแต่ละช่วง .fx แทน ผลรวมของค่าความถี่ของคะแนนทั้งหมด การทดสอบสมมติฐานเชิงสถิติ (Statistical testing) คือ กฎเกณฑ์อย่างหนึ่งในการตัดสินว่า จะยอมรับหรือปฏิเสธสมมติฐานทางสถิติที่ตั้งขึ้น โดยใช้การทดสอบสมมติฐานเกี่ยวกับค่าเฉลี่ย ของประชากร ที่ไม่ทราบความแปรปรวน และมีขนาดของกลุ่มตัวอย่างน้อยกว่า 30 จะมีขั้นตอนดัง นี้ ขั้นที่ 1 ตั้งสมมติฐาน Ho : . = .o และ H1 : . < .o ขั้นที่ 2 กำหนดระดับนัยสำคัญ . = .05 โดยกำหนดให้ . = 4 เป็นเกณฑ์ ขั้นที่ 3 กรณีนี้ใช้ตัวสถิติ t เป็นตัวสถิติทดสอบ จากกลุ่มผู้เล่นจำนวน 18 คนซึ่ง t มีองศา อิสระเป็น n-1 โดยถ้า t < x =" X" t =" บทที่" ho =" ระบบมีประสิทธิภาพในการทำงานจากการทดสอบอยู่ในระดับดี" h1 =" ระบบมีประสิทธิภาพในการทำงานจากการทดสอบต่ำกว่าระดับดี" df ="17" ta =" 1.740" test =" 2.04"> 1.740 ค่า t ของ Function Test = 1.50 < test =" 0.99"> 1.740 ผลที่ได้คือค่า t ของ Functional Requirement Test เท่ากับ 2.04 ซึ่งมากกว่า1.740 หมาย ถึงแตกต่างจากเกณฑ์ คืออยู่ในระดับดีขึ้นไป ค่า t ของ Function Test เท่ากับ 1.50 ซึ่ง น้อยกว่า 1.740 หมายถึง ไม่แตกต่างจากเกณฑ์ คือ อยู่ในระดับดี ค่าt ของ Usability Test เท่ากับ 0.99 ซึ่ง น้อยกว่า1.740 หมายถึงไม่แตกต่างจากเกณฑ์ คือ อยู่ในระดับดี และค่า t ของระบบโดยรวม เท่า กับ 2.71 ซึ่งมากกว่า 1.740 หมายถึงแตกต่างจากเกณฑ์ คืออยู่ในระดับดีขึ้นไป ผลการประเมินโดยผู้ใช้สูงกว่าเกณฑ์ที่กำหนดไว้คือ 4 หรือระดับดี อย่างมีนัยสำคัญที่ .05 หมายถึงประสิทธิภาพของเกมที่พัฒนาขึ้นมีประสิทธิภาพอยู่ในระดับดีขึ้นไป ซึ่งเป็นไปตามสมมติ ฐานการวิจัย X - .o s/.n t = บทที่ 5 สรุปผล อภิปรายผลและข้อเสนอแนะ 5.1 สรุปผลการจัดทำสารนิพนธ์ การส่งเสริมการเรียนรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุด้วยเกมนักรบ มีวัตถุประสงค์เพื่อ พัฒนาเกมนักรับ ที่ให้ผู้เล่นได้ควบคุมโรบ็อทโดยการเขียนโปรแกรมเชิงวัตถุด้วยภาษาจาวา และ ให้มีส่วนของการนำเสนอความรู้แนวคิดการเขียนโปรแกรมเชิงวัตถุ ให้เป็นเกมที่มีประสิทธิภาพใน การทำงานดี ซึ่งการพัฒนาเกมได้เริ่มจากการศึกษาข้อมูล วิเคราะห์และออกแบบระบบเชิงวัตถุ (OOAD) และทำการพัฒนาระบบโดยใช้การเขียนโปรแกรมเชิงวัตถุ (OOP) ด้วยภาษาจาวา และ ใช้ระบบปฏิบัติการ Windows เป็นเครื่องมือในการพัฒนาเกม ซึ่งสามารถสรุปความสามารถใน การทำงานได้ดังนี้ 1. ผู้เล่นสามารถเลือกที่จะเล่นเกมจากทีมที่มีอยู่ 2. ผู้เล่นสามารถเลือกสร้างทีมรบตามที่ต้องการจากโรบ็อทที่มีอยู่ 3. ผู้เล่นสามารถเลือกสร้างโรบ็อทใหม่หรือปรับปรุงโรบ็อทเก่าด้วยการเขียนโปรแกรม เชิงวัตถุด้วยภาษาจาวาได้ 4. ผู้เล่นสามารถศึกษาข้อมูลพื้นฐานของแนวคิดการเขียนโปรแกรมเชิงวัตถุได้ 5. ผู้เล่นสามารถเลือกดูประวัติการเล่นเกมครั้งก่อนหน้าได้ การทดสอบเกม ได้ทำการทดสอบเพื่อหาประสิทธิภาพของเกมโดยใช้แบบสอบถามซึ่งมี ผู้ร่วมทดสอบ คือผู้ที่เคยผ่านการเรียนรู้การเขียนโปรแกรมด้วยแนวคิดเชิงวัตถุมาก่อน หรือคนที่ ทำงานด้านการเขียนโปรแกรม โดยค่าสถิติที่ใช้วิเคราะห์คือ ค่ามัชฌิมเลขคณิต และ การทดสอบ สมมติฐานเชิงสถิติโดยใช้การทดสอบสมมติฐานเกี่ยวกับค่าเฉลี่ยของประชากร จากการทดสอบค่ามัชฌิมเลขคณิตสามารถสรุปผลการประเมินหาประสิทธิภาพของระบบ โดยรวม พบว่าได้ค่าเฉลี่ยเท่ากับ 4.15 แสดงให้เห็นว่าระบบที่ได้พัฒนาขึ้นนี้มีประสิทธิภาพใน ระดับดี จากการทดสอบสมมติฐานเพื่อสรุปผลการยอมรับหรือปฏิเสธสมมติฐานทางสถิติที่ตั้งขึ้น โดยใช้การทดสอบสมมติฐานเกี่ยวกับค่าเฉลี่ยของประชากร ที่ไม่ทราบความแปรปรวน และมี ขนาดของกลุ่มตัวอย่างน้อยกว่า 30 ที่ระดับนัยสำคัญทางสถิติ (.) เท่ากับ.05 และค่า df = 17 โดย กำหนดเกณฑ์ไว้ที่ 4 คือระดับดี ได้ผลการทดสอบสมมติฐานคือ ระบบมีมีประสิทธิภาพในการ ทำงานอยู่ในระดับดี ขึ้นไป ซึ่งเป็นไปตามสมมติฐานการวิจัย 70 บรรณานุกรม ธวัชชัย งามสันติวงศ์. การเขียนโปรแกรมเชิงวัตถุ. กรุงเทพฯ : โรงพิมพ์21 เซ็นจูรี จำกัด, 2545. วีระศักดิ์ ซึงถาวร. Java Programming Volume I. กรุงเทพฯ : บริษัท ซีเอ็ดยูเคชั่น จำกัด, 2543. วีระศักดิ์ ซึงถาวร. Java Programming Volume II. กรุงเทพฯ : บริษัท ซีเอ็ดยูเคชั่น จำกัด, 2545. กิตติ ภักดีวัฒนะกุล. Java โปรแกรมเมอร์. กรุงเทพฯ : บริษัท เคทีพี คอมพ์ แอนด์ คอนซัลท์ จำกัด, 2543. Allen H Dutoit, Brend Bruegge. Object-Oriented Software Engineering. New Jersey : Prentice Hall International, 2000 Robert C. Martin. UML for Java Programers. New Jersey : Prentice Hall International, 2003. Ralph Morelli. Object-Oriented Problem Solving. New Jersey : Prentice Hall International, 2003. Stephen R. Schach. Object-Oriented Analysis and Design with UML and the Unified Process. New York : McGraw-Hill, 2004.