Object-Oriented Programs Design and Construction #1: Designing good Software ITEC0610 Object-Oriented Programs Design and Construction

#1: Designing Good Software Software quality : การวัดคุณภาพของระบบซอฟต์แวร์ที่ดี มีองค์ประกอบอย่างไรบ้าง Criteria of Object Orientation : การออกแบบซอฟต์แวร์ภายใต้แนวคิดเชิงวัตถุ ประกอบไปด้วยปัจจัยอะไรบ้าง ITEC0610 Object-Oriented Programs Design and Construction

Software Quality คุณภาพของซอฟต์แวร์ขึ้นอยู่กับปัจจัยหลายประการดังต่อไปนี้ Correctness Robustness Extendibility Reusability Compatibility Efficiency Portability Ease of use Functionality Timeliness Others ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Correctness ความถูกต้องในการทำงานของซอฟต์แวร์ คือการที่ซอฟต์แวร์นั้นๆ สามารถทำงานได้ตรงตามรายละเอียดที่ได้ออกแบบไว้ (software specification) ปัญหาในการออกแบบซอฟต์แวร์ภายใต้ปัจจัยนี้ก็คือ การที่เราไม่อาจจะสามารถกำหนดข้อจำกัดหรือรายละเอียดต่างๆ ได้ครบถ้วนเพียงพอเพื่อที่จะออกแบบซอฟต์แวร์ เมื่อเกิดความไม่ชัดเจนในการออกแบบ ผู้พัฒนาซอฟต์แวร์จึงต้องกำหนดขอบเขตเอง ซึ่งอาจทำให้ไม่ตรงกับที่ผู้ใช้ต้องการ บ่อยครั้งที่การออกแบบซอฟต์แวร์อาศัยไลบรารีหรือโมดูลที่พัฒนาไว้ก่อนหน้าโดยผู้อื่น ทำให้เกิดข้อจำกัดในพัฒนาที่อาจส่งผลต่อซอฟต์แวร์ที่พัฒนาไม่สามารถจะทำงานได้ตามขอบเขตที่ต้องการ ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Robustness ความทนทานต่อสภาวะที่ไม่อาจคาดคิดของซอฟต์แวร์ คือสภาพที่ซอฟต์แวร์หนึ่งๆ ยังคงสามารถทำงานได้ ภายใต้สภาวะการทำงานที่มิได้เป็นไปตามขอบเขตที่วางไว้แต่ต้น จากรูป สมมติว่าหากเรากำหนดขอบเขตการทำงานของซอฟต์แวร์เอาไว้ในระดับหนึ่ง Correctness หมายถึงความสามารถในการทำงานภายใต้ ขอบเขตที่กำหนด แต่ Robustness หมายถึงความสามารถในการ ทำงานของซอฟต์แวร์เหนือขอบเขตที่กำหนดไว้นั้น ซอฟต์แวร์ที่ดี จะต้องออกแบบเผื่อให้ ระบบยังคงทำงานได้ภายใต้สภาวะที่ไม่ ปกติ หรืออย่างน้อยต้องมีระบบป้องกัน ไม่ให้ซอฟต์แวร์ล่มเมื่อพบกับสภาพนี้ ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Extendibility ความทนทานต่อการเปลี่ยนแปลงรายละเอียดซอฟต์แวร์ คือ ความสามารถในการปรับเปลี่ยนซอฟต์แวร์ให้เป็นไปตามการเปลี่ยนแปลงของ รายละเอียดซอฟต์แวร์(specification) ที่จะเกิดขึ้นในภายหลัง ซอฟต์แวร์ มีจุดเด่นอยู่ที่ “ซอฟต์” หรืออ่อนต่อการเปลี่ยนแปลง ระบบคอมพิวเตอร์ใช้จุดเด่นของซอฟต์แวร์เพื่อศักยภาพในการเปลี่ยนแปลงระบบให้เป็นไปตามที่ผู้ใช้ต้องการได้ อุปสรรคต่อการพัฒนาซอฟต์แวร์ให้มีคุณสมบัตินี้ส่วนมากมาจากขนาดและความซับซ้อนของตัวซอฟต์แวร์เอง (ยิ่งขนาดใหญ่ มีความซับซ้อนมาก การเปลี่ยนสเป็คอาจจะส่งผลต่อการแก้ไขโค้ดและการออกแบบจำนวนมาก) ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Extendibility กระบวนการพัฒนาซอฟต์แวร์ที่เราเรียนกันมาเป็นมาตรฐาน จะมองการพัฒนาเป็น lifecycle นั่นคือมองการพัฒนาเป็นรอบวัฏจักร การเปลี่ยนแปลงซอฟต์แวร์แต่เดิมจะกระทำเฉพาะเมื่อขึ้นรอบวัฏจักรใหม่เท่านั้น แต่ทางปฏิบัติ ซอฟต์แวร์ยุคใหม่อาจจะต้องประสบกับปัญหาสำคัญที่ต้องทำให้เกิดการเปลี่ยนแปลงระหว่างช่วงวัฏจักร เช่นระหว่างการพัฒนา เป็นต้น ดังนั้นซอฟต์แวร์ที่ดี ควรสามารถเปลี่ยนแปลงได้ระหว่างรอบวัฏจักร (เช่นการออก patch ของวินโดวส์ การเพิ่มระบบรักษาความปลอดภัยใน SP2 เป็นต้น) การเพิ่มความยืดหยุ่นในการเปลี่ยนแปลงของซอฟต์แวร์ สามารถทำได้ในสองประเด็นคือ Design simplicity (ออกแบบให้ง่าย) และ Decentralization (กระจายการทำงานของซอฟต์แวร์ออกเป็นส่วนๆ) ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Reusability ความสามารถในการนำกลับมาใช้ใหม่ของซอฟต์แวร์ คือการที่เราสามารถที่จะนำเอาส่วนใดส่วนหนึ่งของซอฟต์แวร์ไปใช้เป็นองค์ประกอบของซอฟต์แวร์ตัวอื่นๆ ที่เราพัฒนาขึ้นได้อย่างหลากหลาย นักพัฒนาซอฟต์แวร์มักจะสังเกตเห็นว่า กระบวนการทำงานย่อยๆ หลายกระบวนการนั้นเป็นกระบวนการมาตรฐานที่มักจะเป็นองค์ประกอบในซอฟต์แวร์หลายๆ ตัว การนำกลับมาใช้ซ้ำได้ ช่วยทำให้ลดปริมาณเนื้องานลง ประหยัดเวลาและงบประมาณ และแน่นอนว่าลดความผิดพลาดลงหรือสามารถใส่ใจกับความผิดพลาดและสามารถแก้ไขได้อย่างมีระบบ ปัจจัยนี้ จำเป็นมากขึ้นเรื่อยๆ ต่อการพัฒนาซอฟต์แวร์ขนาดใหญ่ในปัจจุบันและอนาคต ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Compatibility ความเข้ากันได้ของซอฟต์แวร์ คือความสามารถที่ซอฟต์แวร์ที่พัฒนาขึ้นมา สามารถนำไปใช้ร่วมกันกับซอฟต์แวร์ตัวอื่นเพื่อทำงานในระบบที่ใหญ่ขึ้นไปได้ โลกของซอฟต์แวร์ในปัจจุบันและอนาคต หลีกหนีไม่พ้นที่ซอฟต์แวร์หลายตัวจะต้องมีการติดต่อสื่อสารและใช้งานซึ่งกันและกันมากขึ้นเรื่อยๆ ปัจจัยในการออกแบบซอฟต์แวร์ให้มีความเข้ากันได้ ขึ้นกับ การกำหนดมาตรฐานให้กับไฟล์ฟอร์แมต การกำหนดมาตรฐานให้กับโครงสร้างการจัดการข้อมูลที่ใช้ในซอฟต์แวร์ การกำหนดมาตรฐานให้กับการแสดงผล ส่วนที่ผู้ใช้ทำการติดต่อใช้งานกับโปรแกรม (เช่นเมนู ทูลบาร์ เป็นต้น) การกำหนดมาตรฐานให้กับการเชื่อมต่อการทำงานของโมดูลย่อยต่างๆ ของซอฟต์แวร์ เช่น ActiveX control เป็นต้น และรวมทั้งมาตรฐานการติดต่อของ middleware ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Efficiency การใช้ทรัพยากรระบบอย่างประหยัดของซอฟต์แวร์ คือการที่ซอฟต์แวร์ถูกออกแบบมาให้ใช้ทรัพยากรของระบบให้น้อยที่สุดเท่าที่จำเป็น ทรัพยากรระบบอันได้แก่เวลาของหน่วยประมวลผล พื้นที่หน่วยความจำหลัก และพื้นที่หน่วยความจำสำรอง แบนวิดธ์ของช่องสื่อสารของระบบ อีกคำหนึ่งที่อาจจะใช้แทน efficiency ก็คือ performance หรือประสิทธิภาพการใช้ทรัพยากรระบบอย่างคุ้มค่า ปัจจุบัน แนวคิดการออกแบบระบบถูกแบ่งแยกออกเป็นสองแนวคิด ออกแบบระบบให้ใช้ทรัพยากรให้คุ้มค่าที่สุด โดยการoptimize ระบบ ออกแบบระบบโดยยึดหลักพัฒนาออกสู่ตลาดให้เร็วที่สุด เพราะคอมพิวเตอร์จะเร็วขึ้นทุกปีอยู่แล้ว ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Efficiency นักพัฒนาซอฟต์แวร์บางคนอาจจะทุ่มกับการ optimization มากไป แต่สิ่งที่สำคัญกว่าก็คือ ซอฟต์แวร์ทำงานตรงตามที่ต้องการหรือเปล่า เมื่อสามารถพัฒนาระบบให้ทำงานได้ตามต้องการ จึงค่อยมาดูเรื่อง optimization อย่างน้อย ระบบที่ดีควรจะทำงานได้อย่างมีประสิทธิภาพบนฮาร์ดแวร์ที่กลุ่มผู้ใช้เป้าหมายใช้งานอยู่ ไม่ใช่ว่าต้องซื้อฮาร์ดแวร์เพิ่มมากมายเพียงเพื่อจะรัน ซอฟต์แวร์ที่พัฒนาขึ้นใหม่โดยไม่จำเป็น ซอฟต์แวร์บางสาขานั้น การ optimize เป็นเรื่องสำคัญ เช่นซอฟต์แวร์ทางคณิตศาสตร์ เป็นต้น ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Efficiency อย่างน้อยที่สุด efficiency/performance ของซอฟต์แวร์ยังคงจำเป็นด้วยสาเหตุดังต่อไปนี้ ผู้ใช้ที่ซื้อซอฟต์แวร์ที่กินทรัพยากรระบบมากๆ ย่อมคาดหวังคุณภาพที่ดีกว่าจากซอฟต์แวร์นั้นๆ ผู้ซื้อระบบที่เร็วขึ้น ย่อมคาดหวังว่าจะสามารถรันซอฟต์แวร์ที่ออกแบบมาอย่างดีได้เร็วขึ้น หากซอฟต์แวร์ออกแบบมาไม่ดี ระบบที่เร็วขึ้นอาจจะไม่ส่งผลในความเร็วที่เพิ่มขึ้นอย่างมีสัดส่วนที่สมเหตุสมผล ในบางกรณี (เช่นในระบบ real-time system) ระบบจะต้องตอบสนองภายในช่วงเวลาที่กำหนด หากพัฒนาซอฟต์แวร์โดยไม่สนใจ efficiency ระบบก็จะไม่สามารถทำงานในสภาวะเฉพาะนี้ได้ ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Portability ความสามารถในการโอนย้ายซอฟต์แวร์ไปยังระบบใหม่ คือการที่ผู้พัฒนาซอฟต์แวร์สามารถที่จะโอนซอฟต์แวร์ที่พัฒนาขึ้นเพื่อระบบฮาร์ดแวร์/ระบบปฏิบัติการ หรือสภาวะสถาปัตยกรรมทางฮาร์ดแวร์และซอฟต์แวร์หนึ่งๆ ไปยังสถาปัตยกรรมทางฮาร์ดแวร์/ซอฟต์แวร์ ที่แตกต่างไปจากเดิมได้โดยเปลี่ยนแปลงตัวซอฟต์แวร์น้อยที่สุด ระดับความซับซ้อนในการพอร์ตระบบ ต้องแก้ไขโค้ดใหม่จำนวนมาก (มี portability ที่ต่ำสุด) ไม่ต้องแก้ไขโค้ด แค่คอมไพล์ใหม่ รัน binary โค้ดบน virtual machine โดยมีการจำลองฮาร์ดแวร์ทั้งหมด รันbinaryโค้ดบนระบบ virtual machine โดย mapping hardware ในขณะที่binary ส่วนมากแทบไม่ต้องมีการถูก virtualized เสียประสิทธิภาพน้อยลง (อาจได้ราว 80-90 เปอร์เซนต์เมื่อเทียบกับการรันบนระบบแท้ๆ) รัน intermediate โค้ด บนระบบ virtual machine โดยเสียประสิทธิภาพน้อยที่สุด ไม่ต้องแก้ไขอะไรเลย โดยการรันโค้ดบนระบบใหม่โดยไม่เสียประสิทธิภาพเลย ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Ease of Use ความง่ายต่อการใช้งาน คือลักษณะของซอฟต์แวร์ที่ผู้ใช้ผู้ซึ่งมีพื้นฐานการใช้ซอฟต์แวร์ที่แตกต่างกันไป สามารถมาใช้ซอฟต์แวร์ที่พัฒนาขึ้นใหม่นี้ โดยมีช่วงเวลาการเรียนรู้ที่น้อยที่สุดเพื่อใช้งานซอฟต์แวร์ในการแก้ไขปัญหาที่ต้องการได้ พิจารณาในสามองค์ประกอบคือ การติดตั้ง (installation) การใช้งาน(operation) และการเฝ้าดูกระบวนการทำงานและผลการทำงานของซอฟต์แวร์(monitoring) พิจารณากลุ่มผู้ใช้ตั้งแต่ผู้ที่ควรจะมีหน้าที่ใช้งานซอฟต์แวร์ จนถึงผู้เชี่ยวชาญในสาขานั้นๆ (ไม่รวมคนที่ไม่เกี่ยวข้องกับหน้าที่ใช้งาน) ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Ease of Use ประเด็นต่างๆที่เกี่ยวข้องกับการออกแบบระบบให้ง่ายต่อการใช้งาน จะทำอย่างไรให้ซอฟต์แวร์ที่พัฒนาขึ้น มีการให้ข้อมูลสนับสนุนการใช้งานแก่ผู้ใช้มือใหม่ โดยไม่ไปรบกวนผู้ใช้ที่ใช้งานคล่องอยู่แล้ว (เช่นกรณีเปเปอร์คลิปของเวิร์ด) จะทำอย่างไรให้ซอฟต์แวร์ที่พัฒนาขึ้น มีการวางเมนูและออกแบบซอฟต์แวร์ให้มีโครงสร้างที่ง่ายที่สุด การออกแบบระบบให้มีการควบคุมที่น้อย จะทำให้ซอฟต์แวร์ใช้งานง่ายกว่าซอฟต์แวร์ที่ต้องมีการเซ็ตแก้ไขต่างๆ มากมาย จะทำอย่างไรให้ผู้พัฒนาระบบ สามารถเข้าใจถึงมุมมองของกลุ่มผู้ใช้เป้าหมาย เพื่อสามารถออกแบบซอฟต์แวร์ที่กลุ่มผู้ใช้เป้าหมายจะเรียนรู้การใช้งานน้อยที่สุด User Interface Design Principle (Wilfred J. Hansen) Do not pretend you know the user; you don’t ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Functionality ความหลากหลายในการใช้งานของซอฟต์แวร์ คือซอฟต์แวร์ที่ได้รับการพัฒนาให้สามารถทำงานได้อย่างหลากหลายหรือหลากหน้าที่ เท่าที่ระบบฮาร์ดแวร์/ซอฟต์แวร์ที่รองรับจะสามารถเอื้อให้ได้ (และภายใต้ขอบเขตที่ซอฟต์แวร์ได้รับการออกแบบ) บ่อยครั้งที่ซอฟต์แวร์ถูกตีค่าจากที่ซอฟต์แวร์สามารถทำอะไรได้บ้าง : Featurism และอาจก่อให้เกิดปัญหาตามมาได้อาทิ ส่งผลให้การใช้งานยากขึ้น เพราะการทำงานอย่างหนึ่ง อาจจะมีกรรมวิธีที่จะทำได้มากกว่าหนึ่งอย่าง (เช่นการกำหนดก็อปปี้ข้อความจากตำแหน่งหนึ่งไปวางอีกที่หนึ่งในเวิร์ด) ทำให้ผู้ใช้เกิดความสับสนว่าจะใช้วิธีใด หรือจะแนะผู้ใช้คนอื่นด้วยวิธีใด ผู้ใช้มักบ่นว่า ใช้งานซอฟต์แวร์ไม่คุ้มเพราะซอฟต์แวร์มีขีดความสามารถหลายส่วนที่ผู้ใช้จะไม่เคยได้ใช้เลย และทำให้ซอฟต์แวร์ดูซับซ้อน (ทั้งๆ ที่จริงๆ แล้วทั้งหมด ที่มีอยู่ในซอฟต์แวร์ก็มาจากความต้องการโดยรวมของผู้ใช้ทั้งนั้น) ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Functionality ผู้พัฒนาระบบจึงต้องแก้ปัญหาดังกล่าว โดยการออกแบบซอฟต์แวร์โดยระวังให้วิธีการใช้งานฟีเจอร์ต่างๆนั้น มีหนทางน้อยวิธีที่สุด (ดังที่ปรากฏใน Mac OS) นอกจากนี้ การแก้ไขปัญหาสามารถทำได้โดยในขั้นตอนการออกแบบและปรับแต่งเพื่อบรรจุหน้าที่การทำงานต่างๆ เข้าไปนั้น ซอฟต์แวร์ที่ดีจะต้องไม่ทำให้หน้าที่การทำงานเดิมนั้นใช้งานยากขึ้น Roger Osmond นำเสนอกราฟด้านล่าง ซึ่งบ่อยครั้งที่ซอฟต์แวร์ที่พัฒนาต่อเนื่องมาหลายเวอร์ชันที่มีการเพิ่มฟีเจอร์ใหม่เข้าไป กลับทำให้คุณภาพ ของซอฟต์แวร์โดยรวมในด้านอื่นนั้นตกต่ำลง ซึ่งการปรับแก้ไขให้ซอฟต์แวร์ทำงานให้ได้ตาม เป้าจะต้องเสียเวลาและแรงงานมาก เขาเสนอการ พัฒนาภายใต้แนวคิด OO จะช่วยได้ ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Timeliness การพัฒนาซอฟต์แวร์ให้เป็นไปจังหวะเวลาที่เหมาะสม การออกแบบพัฒนาซอฟต์แวร์ที่ดี จะต้องสามารถพัฒนาซอฟต์แวร์ให้เสร็จทันในช่วงเวลาที่ผู้ใช้ต้องการ หรือเสร็จก่อนหน้า ซอฟต์แวร์ที่ผลิตออกมาไม่ทันกับเวลา อาจทำให้บริษัทเสียความน่าเชื่อถือ และอาจเสียลูกค้า (เพราะอาจจะหันไปใช้ของคู่แข่ง) สำหรับซอฟต์แวร์ขนาดใหญ่ การที่สามารถส่งมอบซอฟต์แวร์ได้ก่อนกำหนด ยิ่งเป็นสิ่งที่แสดงถึงความเชื่อมั่นต่อบริษัทที่ผลิตซอฟต์แวร์นั้นๆ ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Others นอกจากประเด็นต่างๆที่ได้กล่าวมาแล้ว ยังมีประเด็นปลีกย่อยอื่นๆ อีกเช่น Verifiability ความสามารถในการตรวจสอบข้อมูลต่างๆได้ รวมทั้งหากเกิดความผิดพลาดขึ้นในระบบ จะสามารถสืบค้นหาต้นตอจุดผิดพลาดได้ Integrity ความสามารถในการป้องกันตัวซอฟต์แวร์และข้อมูลที่ใช้ จากการเข้าใช้หรือถูกแก้ไขจากผู้ที่ไม่มีสิทธิในการเข้าใช้ Repairability ความสามารถในการซ่อมแซมได้โดยง่าย หากพบความผิดพลาดในตัวซอฟต์แวร์ Economy การผลิตซอฟต์แวร์ภายใต้ต้นทุนที่กำหนดไว้ ในทางปฏิบัติ เราอาจจะต้องมีการ trade off ประเด็นต่างๆ ในกระบวนการพัฒนาซอฟต์แวร์ที่มีเวลาและงบจำกัด ITEC0610 Object-Oriented Programs Design and Construction

Software Quality: Documentation การทำคู่มือ เป็นส่วนเสริมเพื่อให้แต่ละฝ่ายสามารถใช้หรือพัฒนาต่อยอดซอฟต์แวร์ได้อย่างมีประสิทธิภาพ External documentation (user documentation) Internal documentation (program documentation) Module interface documentation (ส่วนนี้เป็นคู่มืออธิบายองค์ประกอบโมดูลต่างๆ ซึ่งจะมีประโยชน์มากในกระบวนการนำเอาโมดูลไปใช้ใหม่ในการพัฒนาซอฟต์แวร์อื่นๆ) Online help เป็นส่วนเสริม External doc. ที่ดี การเขียน source code ที่เป็นระบบ จะช่วยเสริมหรือลด Int. doc ในทางปฏิบัติอาจใช้ทูลช่วยในการสร้าง documentation หรือแทรก รายละเอียดเสริมใน source code เพื่อความสะดวกในการพัฒนาต่อยอด ITEC0610 Object-Oriented Programs Design and Construction

Software Maintenance ITEC0610 Object-Oriented Programs Design and Construction

Criteria of Object Orientation การพัฒนาซอฟต์แวร์ สามารถยืนอยู่บนพื้นฐานการออกแบบได้หลายอย่าง และภาษาโปรแกรมมักจะรองรับการออกแบบอย่างน้อยหนึ่งรูปแบบ เช่น Sequential programming design: การโปรแกรมจากบนลงล่าง Structural programming design: การโปรแกรมแบบมีโครงสร้าง Modular programming design: การโปรแกรมแบบโครงสร้างโมดูล Top-down programming design: การโปรแกรมจากภาพรวม แตกแขนงสู่ภาพย่อย Bottom-up programming design: การโปรแกรมโดยมองภาพย่อยก่อน แล้วค่อยออกแบบไปยังภาพหลัก Event-driven programming: การโปรแกรมโดยมองภาพว่าจะต้องมีฟังก์ชันทำงานตอบสนองต่อเหตุการณ์ที่เกิดขึ้นต่างๆ State machine design: การมองการออกแบบในรูปแบบของระบบที่ทำงานโดยมีการเปลี่ยนแปลงจากสถานะหนึ่งไปยังอีกสถานะหนึ่ง เมื่อได้รับอินพุตหนึ่งๆ เข้ามา Objected-Oriented programming design: การมองระบบออกแบบในรูปของวัตถุที่ประกอบไปด้วยส่วนประกอบที่มีหน้าที่การทำงานเฉพาะอย่างและมีคุณสมบัติเฉพาะ ITEC0610 Object-Oriented Programs Design and Construction

Criteria of Object-Orientation ถ้าจะออกแบบซอฟต์แวร์(และระบบ)โดยยึดหลัก OO เราจะมีกฏเกณฑ์อย่างไร??? ต้องคิดถึงอะไรบ้าง??? เราคงมากะเกณฑ์ไม่ได้ว่าจะต้องออกแบบระบบโดยยึดหลัก OO ร้อยเปอร์เซนต์ แต่อย่างน้อย เราสามารถเลือกออกแบบโดยยึดหลัก OO ตามความเหมาะสม ไม่มีใครต้องการใช้งานซอฟต์แวร์ทุกฟังก์ชันที่มีตลอดเวลา ไม่จำเป็นที่เราจะต้องยึดหลักว่า ระบบต้องออกแบบโดยอาศัย OO แต่เราอาจจะอาศัยการออกแบบโดยอาศัย OO เป็นเพียงปัจจัยหนึ่งในการออกแบบผสมผสานกับการออกแบบวิธีอื่นๆ หรือใช้ชุดพัฒนาที่รองรับ OO มาช่วยในการพัฒนา ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation?? จะเอาอะไรมาบ่งบอกถึงความเป็น OO องค์ประกอบของ OO คืออะไร?? Seamlessness: ความเป็นองค์รวมของระบบการพัฒนาซอฟต์แวร์ ตั้งตัวภาษาโปรแกรม ทูลและโปรแกรมช่วยพัฒนา กรรมวิธีการออกแบบพัฒนาระบบ การใช้งานและการดูแลรักษาซอฟต์แวร์ การพัฒนาซอฟต์แวร์อาจจะใช้หลักการของ OO ผู้พัฒนาระบบบางคน อาจจะใช้กระบวนการออกแบบพัฒนาเบื้องต้นด้วย OO แต่เขียนโค้ดด้วยภาษาเดิมๆ หรือบางคนอาจจะใช้ภาษาที่รองรับ OO แต่ไม่เกี่ยวเนื่องใดๆ กับการออกแบบและพัฒนาระบบ (ใช้การออกแบบวิธีเดิมๆ) การมองระบบอย่าง OO แบบร้อยเปอร์เซนต์ จึงควรมองทั้งองค์รวมทั้ง software lifecycle ตั้งแต่การออกแบบไปจนถึงกระบวนการออก document และการดูแลรักษาซอฟต์แวร์ (ถ้าทำได้!!!) ITEC0610 Object-Oriented Programs Design and Construction

What is Object Orientation??? Classes: การออกแบบซอฟต์แวร์แบบ OO ยืนอยู่บนหลักการของการใช้คลาสเป็นฐานการออกแบบ คลาส คือภาพเชิงรูปธรรมของ Abstract Data Type ซึ่งเป็นภาพเชิงนามธรรม ขององค์ประกอบย่อยของฟังก์ชันการทำงานและข้อมูลที่เกี่ยวเนื่อง (เราจะได้ดูในรายละเอียดของ ADTต่อไปภายหลัง) Assertions: คือขีดความสามารถในการแทรกองค์ประกอบอย่างใดอย่างหนึ่งลงในโค้ด เพื่อให้เราสามารถตรวจทราบสภาพของระบบ ณ ก่อนการทำงาน ณ ขณะการทำงาน และ ณ ขณะจบการทำงาน ขององค์ประกอบส่วนใดส่วนหนึ่งของโปรแกรม (preconditions, postconditions, invariants) ภาษาโปรแกรม OO ที่ดี และ/หรือ ระบบพัฒนาที่วางอยู่บนพื้นฐานของ OO ที่ดี จะมีขีดความสามารถที่จะแทรกโค้ดเพื่อให้ทราบคุณสมบัติทั้งสามดังกล่าวนี้ได้ เพื่อผลประโยชน์ในการตรวจสอบการทำงานและการทำ document ที่เกี่ยวเนื่องกับโค้ดส่วนนั้นๆ ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Class as modules: การพัฒนา OO ที่ดี องค์ประกอบของซอฟต์แวร์ทั้งหมดจะเขียนโดยอาศัยการนิยามด้วยคลาส นั่นคือ องค์ประกอบต่างๆ ของโปรแกรม ต่างถูกนิยามเป็นกลุ่มเป็นโครงสร้าง โดยอาศัยคลาส Class as types: การพัฒนา OO ที่ดี การนิยามโครงสร้างการจัดเก็บข้อมูล ที่จะนำไปใช้ภายในการทำงานของโปรแกรม ควรจะได้มาจากการนิยามด้วยคลาสเท่านั้น Feature-based computation: ในรากฐานของ OO ซึ่งประกอบไปด้วย attribute และ feature(ในรูปของ method) กระบวนการทำงานใดๆ ของโปรแกรม ควรจะเป็นการทำงานโดยอาศัย Feature เท่านั้น ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Information hiding: การพัฒนาซอฟต์แวร์ด้วยแนวคิด OO ที่ดี องค์ประกอบย่อยในคลาส ควรจะถูกเปิดเผยหรือเข้าถึงได้ เท่าที่จำเป็นเท่านั้น โดยเฉพาะอย่างยิ่ง attribute และ method ที่มีจุดประสงค์เพื่อการ ใช้งานเป็นการภายในของคลาส ควรเข้าถึงโดยอาศัย method เท่าทีเตรียมไว้ จุดประสงค์ของ Information hiding เพื่อกำหนดความแน่ชัดว่าองค์ประกอบใดของคลาสเข้าถึงได้หรือไม่ได้ เพื่อไม่ให้การนำเอาโค้ดไปใช้ซ้ำกระทำผิดจากที่ได้เคยออกแบบไว้ก่อนหน้า เพื่อกำหนดไม่ให้เกิดความผิดพลาดจากการทำงานที่ไม่ได้วางแผนไว้ล่วงหน้า เช่นการเปลี่ยนแปลงข้อมูลใน attribute มากกว่าหนึ่งทาง หากเกิดความผิดพลาดในซอฟต์แวร์ จะทำให้หาจุดผิดได้ลำบาก เพื่อความสะดวกในการ port ซอฟต์แวรไปยังระบบใหม่ การอาศัยเมธอดกลางเพื่อเข้าถึง attribute จะได้สามารถแก้ไขโครงสร้าง attribute และแก้ไขเมธอดที่เกี่ยวข้อง โดยไม่จำเป็นต้องแก้ไขซอฟต์แวร์ในองค์รวม เพื่อลดโอการการใช้ชื่อซ้ำกัน โดยให้ชื่อผูกกับคลาสดังกล่าวจะมีความหมายเฉพาะกับคลาสนั้นสๆ ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Exception handling: การพัฒนาซอฟต์แวร์บนพื้นฐานของ OO ที่ดี องค์ประกอบต่างๆของซอฟต์แวร์ควรจะสามารถรองรับสภาพหากส่วนประกอบย่อยถูกสั่งให้ทำงานนอกเหนือจากที่ได้ออกแบบไว้ หรือต้องรองรับในสภาพที่เกิดบักในซอฟต์แวร์ Static typing: การพัฒนาซอฟต์แวร์บนพื้นฐาน OO ที่ดี องค์ประกอบของข้อมูล การรับส่งข้อมูล การทำงานต่างๆ ควรมีการกำหนดชนิดของข้อมูลอย่างเด่นชัด รวมทั้งต้องมีความแน่ใจว่า เมื่อมีการจะเรียกใช้ การทำงานอย่างใดอย่างหนึ่ง จะต้องมีกระบวนการรองรับการทำงานเหล่านั้นไว้เสมอ ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation เราพิจารณาคุณสมบัติของความเด่นชัดแน่นอนของตัวข้อมูลและการทำงานจาก ในทุกๆ องค์ประกอบย่อยของซอฟต์แวร์ที่กำลังทำงานอยู่(run-time object) จะต้องถูกนิยามอย่างเด่นชัดโดยอาศัยคลาส องค์ประกอบย่อยของซอฟต์แวร์ที่จะมีการเรียกใช้สิ่งต่างๆ ที่นิยามจากคลาสใดๆ ควรจะต้องอาศัยฟังก์ชันการทำงาน (feature or method) ที่สร้างขึ้นจากการนิยามคลาสนั้นๆเอง (ตามหลัก information hiding เราจะไม่เปิดให้เมธอดจากคลาสอื่น เข้าล่วงเกินข้อมูลที่เก็บในคลาสใดๆ โดยตรง) การถ่ายค่าจากobject หนึ่งไปยังตัวอื่นใด จะต้องถ่ายค่าในลักษณะที่มั่นใจได้ว่า โครงสร้างการจัดเก็บข้อมูลต้องสอดคล้องกันระหว่างผู้ให้และผู้รับ ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Genericity: การนิยามคลาสภายใต้ OO ที่ดี หากมีกระบวนการทำงานที่มีหลักการมาตรฐานอันหนึ่ง(ในแง่มุมของมนุษย์) ที่สามารถกระทำกับวัตถุที่แตกต่างชนิดกันไป ควรจะนิยามในรูปที่ใช้ชื่อ(เมธอด)ร่วมกัน เช่น อาจนิยาม list (G) โดยที่ G อาจจะเป็น integer หรือ double หรืออื่นใด ก็ได้ ทั้งนี้ด้วยการสื่อความหมายของ list ที่เป็นกลางในเชิงของ OO ว่ามีหน้าที่การทำงานอย่างหนึ่งอย่างใด การนิยามดังกล่าวเรียกว่า unconstrained genericity ITEC0610 Object-Oriented Programs Design and Construction

What is Objected-Orientation??? Inheritance: การออกแบบซอฟต์แวร์ภายใต้แนวคิด OO ที่ดี หากจะมีการนิยามคุณลักษณะของคลาสที่มีลักษณะคล้ายคลึงกันโดยอีกคลาสหนึ่งมีรายละเอียดเพิ่มเติมมากกว่าอีกคลาสหนึ่ง (ในขณะที่ส่วนที่เหลือมีโครงสร้างเหมือนกัน มีจุดประสงค์ต่างๆ เหมือนกัน) ก็ควรจะออกแบบคลาสทั้งสองในลักษณะที่คลาสหนึ่ง สืบทอดมาจากอีกคลาสหนึ่ง การ inheritance (การสืบทอด) มีหลายประเภทได้แก่ Single inheritance Multiple inheritance Repeat inheritance (สืบทอดผ่านมาจากมากกว่าหนึ่งฝั่ง เช่นคนคนหนึ่งอาจจะเป็นทั้งอาหรือทวดของอีกคนหนึ่ง) (ในทางปฏิบัติภาษาแบบ OO จะไม่ใช้ทุกแบบ โดยเราจะเรียนเรื่องนี้ในภายหลัง) ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Constrained genericity: จาก unconstrained genericity ที่เปิดโอกาสให้คลาสหนึ่งๆ สามารถมีเมธอดที่มีพารามิเตอร์ที่หลากชนิดได้ ในความเป็นจริง การจะนิยามคลาสคลาสหนึ่ง เราคงไม่สามารถที่จะนิยามชนิดพารามิเตอร์ที่รองรับได้อย่างไม่จำกัด ดังนั้นแนวคิด OO จึงเปิดโอกาสให้เราสามารถนิยามคลาสที่บรรจุชนิดของพารามิเตอร์ที่เป็นไปได้ และจากนั้น นิยามคลาสที่สืบทอดมาจากคลาสที่บรรจุพารามิเตอร์นี้ โดยกำหนดให้ชนิดพารามิเตอร์ที่จะรองรับได้ เป็นไปตามที่นิยามไว้ในคลาสแม่ ตัวอย่างเช่น สมมติว่ามีคลาสที่นิยามว่าจะมีชนิดข้อมูลใดบ้างที่ซอฟต์แวร์เราจะรองรับการเรียงข้อมูล(เช่นจากน้อยไปมาก) แล้วเรานิยามอีกคลาสหนึ่ง ใช้สำหรับเรียงข้อมูลโดยสืบทอดมาจากคลาสแรกนั้น เพื่อให้การเรียงข้อมูลกระทำได้กับชนิดข้อมูลที่รองรับเท่านั้น เป็นต้น ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Redefinition: เมื่อนิยามสมาชิกของคลาสหนึ่งๆ ไว้เป็นอย่างหนึ่งอย่างใดแล้ว แนวคิด OO ยังยอมรับการนิยามคลาสสืบทอดที่สืบทอดมาจากคลาสฐานนั้น มีการนิยามสมาชิกบางตัวที่ถูกสืบทอดมา ในรูปแบบที่เปลี่ยนไปจากเดิมได้ (เช่น คลาสวิทยุ มีสมาชิก switch_off เป็นการปิดวิทยุ แล้วมีการนิยามคลาสรถยนต์ที่มีการสืบทอดมาจากคลาสวิทยุ มีสมาชิก switch_off ที่ใช้บิดกุญแจเพื่อปิดระบบไฟของรถทั้งหมดเป็นต้น) Polymorphism: เมื่อนิยามสมาชิก(เมธอด)ของคลาสหนึ่งๆ ไว้ว่ามีความหมายหนึ่งใดแล้ว การสืบทอดที่แตกต่างกันออกไป ยังยินยอมให้มีการแปรเปลี่ยนความหมายหรือการทำงานไปได้ตามคลาสที่สืบทอด เช่น กำหนดเมธอด”เลี้ยวซ้าย” ในคลาสเรือ จากนั้นนิยามคลาส “เรือใบ” จากคลาสเรือ และคลาส “เรือหางยาว” จากคลาสเรือ เมื่อเราใช้งาน อาจจะมีการนิยามสมุดเล่มหนึ่ง ใช้บันทึกเรื่อที่ต้องการขับ เมื่อคนขับเรืออ่านสมุด แล้วไปบังคับเรื่อ เขาจะสามารถบังคับเรือให้ "เลี้ยวซ้าย" ได้อย่างถูกต้อง ไม่ว่าสมุดเล่มนั้นจะเขียนว่าจะหมายถึงเรือประเภทใด ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Dynamic binding: นี่คือคุณสมบัติพื้นฐานที่ทำให้เกิด redefinition และ polymorphism คุณสมบัตินี้หมายถึงการที่เมื่อมีการนิยามวัตถุ(object) แต่ละตัวจากคลาสแตกต่างกันที่มีการสืบทอดจากคลาสฐานเดียวกันโดยอาศัยคุณสมบัติ polymorphism (เช่นเรื่องการเลี้ยวของเรือแต่ละประเภทที่สืบทอดมาจากคลาสเรือ) เมื่อโปรแกรม เรียกใช้เมธอดที่มีคุณสมบัติ polymorphism กลไกทางภาษาจะต้องสามารถจัดส่งการเรียกเมธอดไปยังตัวเมธอดที่เหมาะสมโดยอัตโนมัติ (อาทิเช่น จากตัวอย่างเรื่องเรือ ทั้งนี้เพราะขั้นตอนการบังคับเรือแต่ประเภทนั้นไม่เหมือนกัน และถูกเขียนไว้คนละเมธอด) คุณสมบัตินี้อาศัยพื้นฐานของการทำ dynamic call (ของฟังก์ชัน) โดยการตัดสินใจว่าจะให้โปรแกรมกระโดดไปทำในเมธอดใด จะเกิดขึ้น ณ ขณะที่ก่อนจะมีการเรียกใช้เมธอด ไม่ใช่กำหนดไว้ตายตัวไว้ในโค้ด) ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientaion??? Run-time type interrogation: คุณสมบัติของระบบ OO จะรองรับขีดความสามารถที่จะมีการตรวจสอบชนิดของข้อมูลและตัวแปร และจัดการกับข้อมูลหรือตัวแปรอย่างเหมาะสมในขณะที่ซอฟต์แวร์กำลังรัน Deferred features and classes: การออกแบบภายใต้ OO รองรับการออกแบบคลาสที่ยังมีสมาชิกบางตัวที่ยังมิได้กำหนด feature ที่ยังไม่ชัดเจน โดยเมื่อนำคลาสนี้ไปสืบทอดเป็นคลาสอื่นๆ จึงจะค่อยนิยาม feature เหล่านั้น เช่น “เรือ” ที่กำหนด feature “หมุนซ้าย” แต่ยังไม่มีรายละเอียดของ feature นี้ (รู้ว่าเรือต้องหมุนซ้ายได้ แต่ในขณะที่กำหนดเรือ ยังไม่จำเป็นต้องรู้ว่าจะหมุนซ้ายอย่างไร) เมื่อนำเอาเรือไปสร้าง “เรือใบ” จึงค่อยนิยาม feature “หมุนซ้าย” ว่าจะต้องทำอย่างไรกับเรือใบ เราเรียกคลาสนี้ว่า deferred class หรือ abstract class ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? Memory management and garbage collection: ระบบที่ออกแบบภายใต้ OO นั้นจะรับภาระของการจัดการหน่วยความจำ (โดยเฉพาะกับการจัดการกับวัตถุแบบไดนามิก) และการกวาดเก็บพื้นที่หน่วยความจำที่ไม่ใช้(จากวัตถุที่มิได้ใช้แล้ว) คืนให้กับระบบเพื่อสามารถนำกลับมาใช้ได้อีก ระบบที่ออกแบบภายใต้แนวคิดเดิมที่ไม่ใช่ OO จะต้องมีกระบวนการหรือฟังก์ชันในการคืนพื้นที่ที่ไม่ใช้ ไม่เช่นนั้นพื้นที่เหล่านั้นจะนำกลับมาใช้ไม่ได้อีก (กรณีระบบปฏิบัติการที่ขาดคุณสมบัตินี้ เราจะพบว่าระบบจะต้องบูตใหม่เป็นระยะเพื่อดึงเอาพื้นที่ที่เสียไปเพราะระบบจัดการไม่ได้ กลับคืนมา) ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orieatation?? ส่วนต่อไปนี้เป็นส่วนเกี่ยวกับระบบเสริมการทำงานของซอฟต์แวร์ ที่ระบบที่ออกแบบภายใต้ OO จะต้องพึงพิจารณาออกแบบไว้ด้วย Automatic update Fast update Persistence: ขีดความสามารถที่สนับสนุนการจัดเก็บออปเจ็คต์ไว้ที่อื่นที่สามารถดึงข้อมูลกลับมาได้โดยโครงสร้างไม่เปลี่ยนแปลง (เช่นกระบวนการ serialization-unserialization ในหลายๆ ภาษาปัจจุบัน) รวมทั้งการจัดการฐานข้อมูล ที่จัดเก็บข้อมูลแม้ในขณะที่โปรแกรมไม่ได้รัน เป็นต้น Documentation Browsing โครงสร้างคลาส(โดยเฉพาะในชุดพัฒนาซอฟต์แวร์) ITEC0610 Object-Oriented Programs Design and Construction

What is Object-Orientation??? การจัดเก็บและเรียกใช้ไลบรารี: การพัฒนาซอฟต์แวร์ภายใต้ OO นิยมพัฒนาไลบรารีพื้นฐานไว้ และนำมาใช้ ระบบพัฒนาซอฟต์แวร์มักจะมีไลบรารีมาตรฐานเตรียมไว้ให้เรียกใช้ได้โดยสะดวก ระบบพัฒนาซอฟต์แวร์ ที่ดีจะมีไลบรารีให้เรียกใช้และมีข้อสังเกตดังนี้ ไลบรารีพื้นฐาน ไลบรารีเกี่ยวกับการแสดงผลด้านกราฟิก และส่วนติดต่อกับผู้ใช้ ไลบรารีที่ดี จะรองรับการปรับปรุงพัฒนาไลบรารีเวอร์ชันใหม่ๆ ที่จะไม่ทำให้เกิดความเสียหายต่อซอฟต์แวร์ที่เคยเรียกใช้ไลบรารีเวอร์ชันเก่า และหันมาใช้เวอร์ชันใหม่โดยไม่ได้ตั้งใจ ไลบรารีที่ดี สนับสนุนการจัดทำ index เพื่อการค้นหาและใช้ได้โดยสะดวก ITEC0610 Object-Oriented Programs Design and Construction

Conclusion เนื้อหาที่ได้เรียนรู้ไปแล้วในครั้งนี้ เราได้ศึกษาถึงแนวทางการออกแบบและพัฒนาซอฟต์แวร์อย่างมีระบบ แนวทางดังกล่าวประกอบไปด้วยสองส่วนด้วยกัน ส่วนแรกคือการพิจารณาการออกแบบและพัฒนาซอฟต์แวร์ในภาพรวม การออกแบบซอฟต์แวร์ให้มีคุณภาพนั้น ควรจะต้องคำนึงถึงปัจจัยอะไรบ้าง ในส่วนที่สอง ได้เจาะจงลงไปที่แนวคิดการออกแบบเชิงวัตถุ ในแนวคิดนี้ เราต้องคำนึงถึงปัจจัยใดบ้างในการออกแบบซอฟต์แวร์ ITEC0610 Object-Oriented Programs Design and Construction