บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)

บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)

บทที่ 9 วิศวกรรมการออกแบบ
9.1 การออกแบบภายใต้บริบทของวิศวกรรมซอฟต์แวร์ (Design within the context of Software Engineering) 9.2 กระบวนการออกแบบและคุณภาพ (Design Process and Design Quality) 9.3 แนวคิดด้านการออกแบบ (Design Concepts) 9.4 แบบจำลองการออกแบบ (The Design Model) 9.5 สรุปท้ายบท

แนวคิดที่สำคัญ (Key Concepts)
การกำหนดสาระสำคัญ Abstraction สถาปัตยกรรม Architecture คลาสออกแบบ Design Classes ส่วนประกอบของแบบจำลอง Model Elements คุณภาพ Quality เชิงหน้าที่ Functional ความเป็นอิสระ ความไม่ขึ้นแก่กัน Independence การปกปิดข่าวสาร Information Hiding ความเป็นโมดูล Modularity แบบรูป Patterns การแยกส่วนประกอบใหม่ Refactoring การลงรายละเอียดเพิ่มเติม Refinement

วิศวกรรมการออกแบบรวบรวมหลักการ แนวความคิด และวิธีปฏิบัติที่นำไปสู่การพัฒนาระบบคอมพิวเตอร์ที่มีคุณภาพสูง การออกแบบเป็นกิจกรรมหลักอย่างหนึ่งของวิศวกรรมคอมพิวเตอร์

ซอฟต์แวร์ที่ดีต้องมี
ความคงทน (Firmness) ไม่มีบั๊ก (Bugs) หรือความผิดพลาดของการทำงานในโปรแกรม ความเป็นโภคภัณฑ์ (Commodity) คือ โปรแกรมจะต้องเหมาะสมและตรงกับวัตถุประสงค์ในการใช้งาน ความเพลิดเพลิน (Delight) หมายถึง ผู้ใช้งานควรจะรู้สึกพึงพอใจต่อการใช้งานโปรแกรม

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

วิศวกรซอฟต์แวร์จะเป็นผู้ทำหน้าที่ในการออกแบบซอฟต์แวร์ ซึ่งในการออกแบบนั้นจะทำให้เกิดรูปแบบของระบบหรือผลิตภัณฑ์ก่อนที่จะทำการสร้างจริง เราจะสามารถตรวจสอบคุณภาพและทำการปรับปรุงให้ดีขึ้นก่อนที่จะมีการลงมือเขียนโปรแกรมจริงได้

ขั้นตอนในการออกแบบซึ่งมีอยู่หลายแนวทางด้วยกัน ในอันดับแรกจะต้องแสดงให้เห็นถึงสถาปัตยกรรมของระบบ จากนั้นเป็นเรื่องของการสร้างแบบจำลองของการต่อประสานซอฟต์แวร์นั้นกับผู้ใช้งาน หรือกับระบบและอุปกรณ์ต่อพ่วงอื่นๆ ท้ายที่สุด จึงจะทำการออกแบบองค์ประกอบย่อยต่างๆ ที่จะต้องใช้ในการสร้างระบบ

วิศวกรรมการออกแบบซอฟต์แวร์มีการเปลี่ยนแปลงอยู่ตลอดเวลา เนื่องจากมีวิธีใหม่ๆ การวิเคราะห์ที่ดีกว่า ความเข้าใจที่กว้างกว่าเข้ามาอยู่เรื่อยๆ แม้กระทั่งทุกวันนี้ ระเบียบวิธีการออกแบบซอฟต์แวร์ยังขาดความลึก ความยืดหยุ่นและลักษณะเชิงปริมาณ ซึ่งอาจพบได้ในแนวทางการออกแบบเชิงวิศวกรรมทั่วไป

9.1 การออกแบบภายใต้บริบท ของวิศวกรรมซอฟต์แวร์ (DESIGN WITHIN THE CONTEXT OF SOFTWARE ENGINEERING)

9.1 การออกแบบภายใต้บริบทของวิศวกรรมซอฟต์แวร์ (Design within the context of software engineering)
โดยปกติแล้วการออกแบบซอฟต์แวร์ จะเริ่มภายหลังจากการวิเคราะห์ความต้องการและสร้างแบบจำลองการวิเคราห์ (Analysis Model) นอกจากนี้ ขั้นตอนการออกแบบยังเป็นเสมือนการจัดเตรียมเวทีให้พร้อมกับการสร้างระบบต่อไป ซึ่งได้แก่การเขียนและการทดสอบโปรแกรม

การแปลงแบบจำลองการวิเคราะห์ไปเป็นแบบจำลองการออกแบบ

จากรูปแสดงถึงกระแสการไหลของข้อมูลในช่วงการออกแบบซอฟต์แวร์ โดยจากขั้นตอนการวิเคราะห์จะนำข้อมูลด้านองค์ประกอบเชิงบรรยาย (Scenario-based Elements) องค์ประกอบเชิงคลาส (Class-based Elements) องค์ประกอบเชิงกระแส (Flow-oriented Elements) และองค์ประกอบเชิงพฤติกรรม (Behavioral Elements) ไปใช้ต่อในขั้นตอนของการออกแบบ ซึ่งจะทำให้ได้แบบข้อมูล/คลาส (Data/Class Design) แบบสถาปัตยกรรม (Architectural Design) แบบส่วนต่อประสาน (Interface Design) และแบบระดับองค์ประกอบย่อย (Component-level Design)

ตัวแบบคลาสหรือข้อมูล (Data/Class Design) แปลงแบบจำลองคลาสวิเคราะห์ไปเป็นคลาสออกแบบกับโครงสร้างข้อมูลที่จำเป็นต่อการอิมพลีเมนต์ซอฟต์แวร์ คลาสและความสัมพันธ์ที่กำหนดโดยบัตรดัชนีซีอาร์ซี (CRC Index Cards) เนื้อหารายละเอียดข้อมูลจากแอตทริบิวส์ของคลาสและแบบวิเคราะห์อื่นๆ เป็นพื้นฐานที่ใช้ในกิจกรรมออกแบบข้อมูล ส่วนหนึ่งของคลาสออกแบบอาจเกิดไปพร้อมกับการออกแบบสถาปัตยกรรมซอฟต์แวร์

ตัวแบบสถาปัตยกรรม (Architecture Design) นิยามความสัมพันธ์ระหว่างส่วนประกอบเชิงโครงสร้างหลักๆ ของซอฟต์แวร์ สไตล์ และแบบรูปสถาปัตยกรรม เพื่อให้ประสบผลตามความต้องการของระบบ โดยคำนึงถึงข้อจำกัดต่างๆ ในการอิมพลีเมนต์ตามสถาปัตยกรรมนี้ ตัวแบบสถาปัตยกรรม หรือโครงแบบของระบบคอมพิวเตอร์อาจะสร้างมาจากข้อกำหนดระบบ แบบจำลองการวิเคราะห์ และปฏิสัมพันธ์ของระบบย่อยที่ได้จากแบบจำลองการวิเคราะห์

ตัวแบบส่วนต่อประสาน (Interface Design) เป็นสิ่งที่อธิบายว่า ซอฟต์แวร์สื่อสารกับระบบอื่นๆ และมนุษย์ที่ทำงานร่วมกันอย่างไร ตัวต่อประสานมีนัยรวมถึงกระแสข่าวสาร เช่น ข้อมูล หรือตัวควบคุม และชนิดของพฤติกรรมที่เกิดขึ้น ดังนั้น ฉากบรรยายการใช้งาน และแบบจำลองเชิงพฤติกรรม สามารถให้ข้อมูลที่จำเป็นต่อการออกแบบส่วนต่อประสานได้ดี

ตัวแบบระดับคอมโพเน้นท์ (Component-level Design) จะแปลงองค์ประกอบเชิงโครงสร้างของสถาปัตยกรรมซอฟต์แวร์ไปเป็นคำบรรยายกระบวนการทำงานของคอมโพเน้นท์ซอฟต์แวร์ ข่าวสารที่ได้จากแบบจำลองเชิงคลาส เชิงกระแส และเชิงพฤติกรรม สามารถใช้ในการออกแบบคอมโพเน้นท์ได้

ความสำคัญของงานออกแบบซอฟต์แวร์ อาจมองรวมอยู่ในคำๆ เดียวได้คือคำว่า “คุณภาพ” การออกแบบเป็นที่กำเนิดของคุณภาพของงานวิศวกรรมซอฟต์แวร์ เนื่องจากตัวแบบเป็นตัวแทนของซอฟต์แวร์ที่อ้าจใช้ประเมินคุณภาพได้ ตัวแบบเป็นการแปลงความต้องการของลูกค้าไปเป็นซอฟต์แวร์หรือตัวระบบที่ทำงานได้ และตัวแบบเป็นรากฐานสำหรับกิจกรรมด้านวิศวกรรมซอฟต์แวร์อื่นๆ ที่ตามมา

9.2 กระบวนการออกแบบและคุณภาพ (DESIGN PROCESS AND DESIGN QUALITY)

9.2 กระบวนการออกแบบและคุณภาพ (Design Process and Design Quality)
งานออกแบบเป็นกระบวนการทำวนซ้ำเพื่อแปลงความต้องการไปเป็นพิมพ์เขียว เพื่อใช้ในการสร้างซอฟต์แวร์ในระยะเริ่มต้น พิมพ์เขียวแสดงภาพโดยรวมของซอฟต์แวร์ นั่นคือ เป็นการแสดงในระดับบน ซึ่งเป็นระดับที่ติดตามกลับไปยังวัตถุประสงค์ ข้อมูล หน้าที่การทำงาน และพฤติกรรมของระบบได้โดยตรง เมื่อมีการออกแบบวนซ้ำ การลงรายละเอียดเพิ่มเติมที่ตามมา จะนำไปสู่การแสดงแทน ณ ระดับล่าง ที่อาจยังติดตามกลับไปยังความต้องการเริ่มต้นได้ แต่อาจลำบากขึ้น

Mc Glaughlin แนะนำลักษณะของงานออกแบบที่ดีไว้ดังนี้ ตัวแบบต้องใช้ในการอิมพลีเมนต์ความต้องการทั้งหมดได้ ซึ่งได้ระบุไว้แล้วอย่างชัดเจนในแบบจำลองการวิเคราะห์ และต้องรองรับความต้องการที่ไม่ได้ระบุไว้อย่างชัดเจนของลูกค้าได้ด้วยเช่นกัน ตัวแบบต้องอ่านง่าย เข้าใจง่ายสำหรับผู้เขียนโค้ด ผู้ทดสอบและผู้สนับสนุนงานที่ตามมาอื่นๆ ตัวแบบควรให้แบบที่สมบูรณ์ของซอฟต์แวร์ โดยกล่าวถึงข้อมูล หน้าที่การทำงาน และพฤตกรรมของระบบจากมุมมองของการอิมพลีเมนต์

แนวทางคุณภาพ การออกแบบควรเสนอสถาปัตยกรรมที่ใช้สไตล์หรือรูปแบบสถาปัตยกรรมที่รู้จักกันดี (Recognizable) และประกอบด้วยองค์ประกอบย่อยที่มีลักษณะการออกแบบที่ดี และสามารถอิมพลีเมนต์แบบค่อยเป็นค่อยไป ซึ่งช่วยทำให้การอิมพลีเมนต์และการทดสอบทำได้ง่าย การออกแบบควรมีลักษณะเป็นส่วนโมดูล นั่นคือ เราควรจะสามารถแบ่งซอฟต์แวร์ออกเป็นส่วนประกอบย่อยๆ หรือระบบย่อยๆ ในเชิงตรรกะได้ การออกแบบควรประกอบด้วยตัวแสดงแทนแยกกัน สำหรับข้อมูล สถาปัตยกรรม ส่วนต่อประสาน และองค์ประกอบย่อย การออกแบบควรนำมาซึ่งโครงสร้างข้อมูลที่เหมาะกับคลาสที่จะสร้างขึ้น โดยโครงสร้างข้อมูลนั้นอาจได้มาจากแบบรูปข้อมูลที่รู้จักกันดี

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

คุณลักษณะด้านคุณภาพ (Quality Attributes) Hewlett-Packard ได้กำหนดลักษณะเชิงคุณภาพของซอฟต์แวร์โดยเรียกว่า FURPS ไว้ดังนี้ F Functionality หมายถึง ความสามารถในการทำงาน ซึ่งจะประเมินจากหน้าที่และความสามารถของโปรแกรม U Usability หมายถึง ความสามารถในการใช้งาน ซึ่งอาจประเมินได้จากปัจจัยด้านบุคลากร ความสม่ำเสมอ และการจัดทำเอกสารประกอบ R Reliability หมายถึง ความน่าเชื่อถือได้ โดยอาจประเมินได้จากระดับความถี่และความรุนแรงของการทำงานผิดพลาด ความถูกต้องของผลลัพธ์ เวลาเฉลี่ยที่โปรแกรมจะเริ่มทำงานผิดพลาด ความสามารถในการกู้คืน P Performance ประสิทธิภาพของการทำงาน วัดได้จากความเร็วในการประมวลผล เวลาในกาตอบสนอง การใช้ทรัพยากร ผลลัพธ์ที่ได้ และประสิทธิผล S Supportability หมายถึง ความสามารถในการสนับสนุน เป็นสิ่งที่รวมความสามารถในการขยายโปรแกรม (Extensibility) ปรับเปลียนโปรแกรม (Adaptability) และความสามารถในการบริการ (Serviceability) เข้าไว้ด้วยกัน รวมเรียกว่า (Maintainability)

คุณลักษณะด้านคุณภาพซอฟต์แวร์ อาจมีค่าน้ำหนักแตกต่างกันในระหว่างการออกแบบ บางแอพพลิเคชั่นอาจเน้นความสามารถในการทำงาน โดยเฉพาะความปลอดภัยของระบบ บางแอพพลิเคชั่นอาจต้องการประสิทธิภาพของการทำงาน โดยเน้นความเร็วในการประมวลผล ส่วนอีกแอพพลิเคชั่นหนึ่งอาจมุ่งไปที่ความน่าเชื่อถือได้ แม้ว่าค่าน้ำหนักจะต่างกัน แต่คุณลักษณะด้านคุณภาพทุกตัวต้องได้รับการพิจารณาระหว่างการออกแบบไม่ใช่ภายหลังการออกแบบ

9.3 แนวคิดด้านการออกแบบ (DESIGN CONCEPTS)

9.3 แนวคิดด้านการออกแบบ (Design Concepts)
จุดเริ่มต้นของภูมิปัญญาด้านวิศวกรรมซอฟต์แวร์ เริ่มขึ้นเมื่อรับรู้ความแตกต่างระหว่างการเขียนโปรแกรมให้ทำงานได้ กับการทำให้ทำงานได้ถูกต้อง M.A. Jackson

แนวคิดด้านการออกแบบได้มีวิวัฒนาการมาตลอดประวัติศาสตร์ของวิศวกรรมซอฟต์แวร์ ระดับความสนใจในแต่ละแนวคิดมีการเปลี่ยนแปลงมาตลอด แต่ละแนวคิดต้องผ่านการพิสูจน์มายาวนาน จนกลายมาเป็นรากฐานของวิธีการออกแบบขั้นสูงที่สามารถใช้งานได้

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

9.3.1 การกำหนดสาระสำคัญ (Abstraction) เราอาจกำหนดสาระสำคัญเชิงกระบวนการทำงานและเชิงข้อมูล สาระสำคัญเชิงกระบวนการทำงาน หมายถึง ลำดับของคำสั่งที่ทำหน้าที่เฉพาะเจาะจงอย่างหนึ่ง ชื่อของสาระสำคัญเชิงกระบวนการจะบ่งบอกถึงหน้าที่การทำงานั้นๆ แต่ไม่มีรายละเอียด ตัวอย่างของสาระสำคัญเชิงกระบวนการ เช่น open สำหรับประตู หมายถึง ชุดลำดับขั้นตอนการทำงาน เช่น เดินไปที่ประตู เอื้อมมือไปจับลูกบิด หมุนลูกบิด และดึงออก เป็นต้น

9.3.1 การกำหนดสาระสำคัญ (Abstraction) สาระสำคัญเชิงข้อมูล เป็นชื่อของข้อมูลที่อธิบายวัตถุข้อมูลในบริบทของการเปิดประตู เราอาจกำหนดสาระสำคัญเชิงข้อมูลชื่อ door ที่ประกอบด้วยแอตทริบิวส์ต่างๆ เช่น doortype, swing direction, opening mechanism, weight, dimensions เป็นต้น ดังนั้น สาระสำคัญเชิงกระบวนการ open จะทำงานกับแอตทริบิวส์ต่างๆ ที่บรรจุในสาระสำคัญเชิงข้อมูล door ได้

9.3.2 การกำหนดสถาปัตยกรรม (Architecture) สถาปัตยกรรมซอฟต์แวร์ในรูปที่ง่ายที่สุด เป็นโครงสร้างหรือการจัดระเบียบโปรแกรม องค์ประกอบย่อยหรือโมดูล ในลักษณะที่องค์ประกอบเหล่านั้นมีปฏิสัมพันธ์กันเอง และกับโครงสร้างข้อมูลที่จำเป็น ในความหมายกว้างๆ อาจมีการจัดกลุ่มองค์ประกอบย่อยเป็นระบบหลักและระบบย่อยที่มีปฏิสัมพันธ์ต่อกัน

9.3.2 การกำหนดสถาปัตยกรรม (Architecture) การออกแบบสถาปัตยกรรม สามารถทำได้ด้วยแบบจำลองหลายๆ แบบ แบบจำลองโครงสร้าง (Structural Models) แสดงการจัดระเบียบของคอมโพเน้นท์โปรแกรม แบบจำลองโครงแบบ (Framework Models) เพิ่มระดับของการกำหนดสาระสำคัญ โดยพยายามหาส่วนที่คล้ายๆ กันของหลายๆ แอพลิเคชั่นมาสร้างเป็นโครงแบบสถาปัตยกรรม

9.3.2 การกำหนดสถาปัตยกรรม (Architecture) การออกแบบสถาปัตยกรรม สามารถทำได้ด้วยแบบจำลองหลายๆ แบบ แบบจำลองเชิงพลวัต (Dynamic Models) กล่าวถึงพฤติกรรมของสถาปัตยกรรมโปรแกรมว่า เปลี่ยนแปลงไปตามหน้าที่หรือเหตุการณ์ภายนอกอย่างไร แบบจำลองเชิงกระบวนการ (Process Models) เน้นการออกแบบกระบวนการทางเทคนิคหรือทางธุรกิจที่ระบบต้องรองรับ แบบจำลองเชิงหน้าที่ (Functional Models) จะใช้แทนลำดับขั้นเชิงหน้าที่ของระบบ

9.3.3 การเลือกแบบรูป (Patterns) แบบรูปการออกแบบ (Design Patterns) อธิบายโครงสร้างตัวแบบที่ช่วยแก้ปัญหาการออกแบบเฉพาะเจาะจงหนึ่งๆ ภายในบริบทหนึ่งๆ ท่ามกลางแรงผลักดันที่อาจมีผลกระทบต่อการใช้งานรูปแบบนั้นๆ

9.3.3 การเลือกแบบรูป (Patterns) แบบรูปการออกแบบให้คำอธิบายที่จะช่วยนักออกแบบตัดสินใจว่า แบบรูปนี้จะประยุกต์กับงานปัจจุบันได้หรือไม่ แบบรูปนี้สามารถนำกลับมาใช้งานใหม่เพื่อช่วยประหยัดเวลาในการออกแบบได้หรือไม่ แบบรูปนี้จะใช้เป็นข้อแนะนำในการพัฒนาแบบรูปเชิงโครงสร้างหรือเชิงหน้าที่อื่นๆ ที่มีส่วนคล้ายกันได้หรือไม่

9.3.4 ความเป็นโมดูล (Modularity) ทั้งสถาปัตยกรรมซอฟต์แวร์ และแบบรูปการออกแบบ ต่างมีความเป็นโมดูลอยู่ นั่นคือ จะแบ่งซอฟต์แวร์ออกเป็นองค์ประกอบย่อยที่มีชื่อเรียกต่างๆ กัน เรียกว่าโมดูล ซึ่งจะประกอบกันได้เพื่อทำงานตามความต้องการ

9.3.4 ความเป็นโมดูล (Modularity) ความเป็นโมดูลเป็นคุณลักษณะของซอฟต์แวร์ที่ช่วยให้สามารถจัดการโปรแกรมได้ ซอฟต์แวร์ขนาดใหญ่ซอฟต์แวร์เดียวที่ประกอบด้วยโมดูลเดียวไม่อาจจัดการได้ เพื่อให้เข้าใจความคิดนี้ ลองพิจารณาปัญหา 2 ปัญหา คือ P1 และ P2 ถ้าความซับซ้อนรับรู้ของ P1 มากกว่า ความซับร้อนรับรู้ของ P2 สิ่งที่ตามมาคือแรงงานในการแก้ปัญหา P1 จะมากกว่าแรงงานในการแก้ปัญหา P2 สิ่งที่ตามต่อมาก็คือ ความซับซ้อนรับรู้ของทั้งสองปัญหา เมื่อนำมารวมกันมักจะมากกว่าผลบวกเมื่อแยกกัน ดังนั้น จึงเป็นที่มาของกลยุทธ์ “แบ่งแยกแล้วปกครอง (Divide and Conquer)” เนื่องจากเป็นการง่ายกว่าที่จะแตกปัญหาที่ซับซ้อนออกเป็นชิ้นเล็กๆ ที่พอจัดการได้ ดังนั้นโมดูลของซอฟต์แวร์จึงเป็นเรื่องที่สำคัญ

9.3.4 ความเป็นโมดูล (Modularity) จากรูปแสดงค่าใช้จ่ายในการพัฒนาโมดูลหนึ่งๆ ว่ามีค่าใช้จ่ายลดลงเมื่อโมดูลเพิ่มขึ้นตามขนาดของโมดูลที่เล็กลง แต่เมื่อจำนวนของโมดูลเพิ่มขึ้น ค่าใช้จ่ายในการประกอบโมดูลเข้าด้วยกันก็เพิ่มขึ้นไปด้วย

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

9.3.6 ความเป็นอิสระเชิงหน้าที่ (Functional Independence) แนวคิดความเป็นอิสระเชิงหน้าที่ มีความสัมพันธ์โดยตรงกับความเป็นโมดูลและการซ่อนข่าวสาร โมดูลควรได้รับการออกแบให้มีหน้าที่เดียว และหลีกเลี่ยงจากการปฏิสัมพันธ์กับโมดูลอื่นๆ นั่นคือเราต้องการตัวแบบซอฟต์แวร์ที่แต่ละโมดูลทำหน้าที่ย่อยเฉพาะอย่างและมีส่วนต่อประสานที่ง่ายๆ เมื่อมองจากส่วนของโครงสร้างโปรแกรมอื่นๆ

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

9.3.6 ความเป็นอิสระเชิงหน้าที่ (Functional Independence) เราอาจประเมินความเป็นอิสระจากกฎเกณฑ์เชิงคุณภาพสองตัว คือ ความเชื่อมแน่น (Cohesion) และ ความเชื่อมโยง (Coupling) ความเชื่อมแน่นเป็นตัวบ่งชี้ความแข็งแกร่งเชิงหน้าที่ของโมดูล ขณะที่ความเชื่อมโยงเป็นตัวบ่งชี้ความขึ้นต่อกันระหว่างโมดูล

9.3.7 การลงรายละเอียดเพิ่มเติม (Refinement) การลงรายละเอียดเพิ่มเติมไปตามลำดับเป็นกลยุทธ์การออกแบบจากบนลงล่าง เป็นการพัฒนาโปรแกรมด้วยการเพิ่มเติมรายละเอียดกระบวนการทำงาน จากประโยคที่ระบุหน้าที่ไปทีละขั้นตอน จนกว่าจะได้ประโยคภาษาโปรแกรม

9.3.7 การลงรายละเอียดเพิ่มเติม (Refinement) การลงรายละเอียดเพิ่มเติมเป็นกระบวนการขยายความ เราเริ่มต้นด้วยประโยคที่กล่าวถึงหน้าที่ ณ ระดับของการกำหนดสาระสำคัญระดับบน คือ ประโยคที่อธิบายหน้าที่และข่าวสาร โดยไม่ระบุการทำงานภายในหรือโครงสร้างข้อมูลภายใน การลงรายละเอียดก่อให้เกิดการขยายความประโยคตั้งต้น ให้มีรายละเอียดมากขึ้นเรื่อยๆ การกำหนดสาระสำคัญ (Abstraction) และการลงรายละเอียด (Refinement) เป็นแนวคิดสองอย่างที่ตรงข้ามกันแต่เสริมซึ่งกันและกัน การกำหนดสาระสำคัญช่วยให้นักออกแบบกำหนดกระบวนการและข้อมูล โดยไม่ต้องลงรายละเอียดระดับล่าง ส่วนการลงรายละเอียดเพิ่มเติม ช่วยให้นักออกแบบเปิดเผยรายละเอียดระดับล่าง เมื่อออกแบบก้าวหน้าไป

9.3.8 การแยกส่วนประกอบใหม่ (Refactoring) กิจกรรมหนึ่งที่วิธีการอาไจลแนะนำให้ทำ คือ การแยกส่วนประกอบใหม่ เป็นการจัดระเบียบใหม่เพื่อให้งานออกแบบองค์ประกอบย่อยหรือตัวโค้ดมีลักษณะที่ง่ายขึ้น โดยไม่ไปเปลี่ยนแปลงพฤติกรรมการทำงาน

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

9.3.9 คลาสแบบต่างๆ (Design Classes) แบบจำลองการวิเคราะห์กำหนดชุดของคลาสวิเคราะห์ที่สมบูรณ์โดยคลาสเหล่านี้อธิบายส่วนประกอบของโดเมนปัญหาที่มองเห็นได้จากมุมมองของผู้ใช้งานหรือลูกค้า

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ ลงรายละเอียดของคลาสวิเคราะห์ โดยออกแบบรายละเอียดต่างๆ ที่เพียงพอแก่การนำไปอิมพลีเมนต์ได้

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ สร้างชุดของคลาสออกแบบที่สนับสนุนการทำงานของคลาสโดเมนที่ปัญหา คลาสออกแบบมี 5 ประเภทดังนี้ คลาสต่อประสานผู้ใช้งาน (User Interface Classes) จำเป็นสำหรับการต่อประสานคอมพิวเตอร์กับมนุษย์ ควรออกแบบให้อยู่ภายใต้บริบทของการทำงานจริง เช่น สมุดเช็คใบสั่งซื้อ เครื่องส่งแฟ็กซ์ เป็นต้น และคลาสการออกแบบสำหรับส่วนต่อประสาน ควรจะเป็นส่วนที่มองเห็นได้จากบริบทการทำงานเหล่านี้

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ สร้างชุดของคลาสออกแบบที่สนับสนุนการทำงานของคลาสโดเมนที่ปัญหา คลาสออกแบบมี 5 ประเภทดังนี้ คลาสโดเมนธุรกิจ (Business Domain Classes) มักจะเป็นการลงรายละเอียดเพิ่มเติม ของคลาสวิเคราะห์ที่ได้กำหนดมาก่อนหน้านี้ ได้แก่ การระบุรายละเอียดของแอตทริบิวส์ และรายละเอียดของการบริการที่จำเป็นในการอิมพลีเมนต์ส่วนประกอบของโดเมนธุรกิจ

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ สร้างชุดของคลาสออกแบบที่สนับสนุนการทำงานของคลาสโดเมนที่ปัญหา คลาสออกแบบมี 5 ประเภทดังนี้ คลาสกระบวนการ (Process Classes) อิมพลีเมนต์สาระสำคัญทางธุรกิจระดับล่างที่จำเป็นในการจัดคลาสโดเมนธุรกิจ

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ สร้างชุดของคลาสออกแบบที่สนับสนุนการทำงานของคลาสโดเมนที่ปัญหา คลาสออกแบบมี 5 ประเภทดังนี้ คลาสคงทนถาวร (Persistent Classes) เป็นตัวแทนของแหล่งเก็บข้อมูล เช่น ฐานข้อมูลที่จะอยู่อย่างถาวรหลังการทำงานของซอฟต์แวร์

9.3.9 คลาสแบบต่างๆ (Design Classes) เมื่อแบบจำลองการออกแบบเกิดขึ้น ทีมงานจะต้องนิยามชุดของคลาสออกแบบที่ สร้างชุดของคลาสออกแบบที่สนับสนุนการทำงานของคลาสโดเมนที่ปัญหา คลาสออกแบบมี 5 ประเภทดังนี้ คลาสระบบ (System Classes) อิมพลีเมนต์การจัดการซอฟต์แวร์ และหน้าที่ควบคุมที่ทำให้ระบบการทำงานสื่อสารกับสิ่งแวดล้อมภายนอกได้

Arlow และ Neustadt แนะนำให้ทบทวนคลาสออกแบบว่ามีลักษณะที่ดีดังต่อไปนี้ มีความสมบูรณ์และพอเพียงในตัว (Complete and Sufficient) คลาสออกแบบควรจะห่อหุ้มแอตทริบิวส์และตัวทำงานที่สมบูรณ์ ตัวอย่างเช่น คลาส Scene ที่นิยามไว้ให้ซอฟต์แวร์ตัดต่อวิดีโอ จะสมบูรณ์ก็ต่อเมื่อบรรลุแอตทริบิวส์และตัวทำงานทั้งหมดที่เกี่ยวข้องกับการสร้างฉากวิดีโอ ในขณะที่ความพอเพียงทำให้คลาสออกแบบบรรจุเพียงตัวทำงานที่เพียงพอต่อการทำงานให้สำเร็จ แต่ไม่มากกว่านั้น

Arlow และ Neustadt แนะนำให้ทบทวนคลาสออกแบบว่ามีลักษณะที่ดีดังต่อไปนี้ มีความเป็นปฐม (Primitiveness) ตัวทำงานภายในคลาสออกแบบควรให้บริการเพียงพออย่างเดียวแก่คลาส และคลาสไม่ควรมีวิธีการบริการแบบอื่นสำหรับงานเดียวกัน

Arlow และ Neustadt แนะนำให้ทบทวนคลาสออกแบบว่ามีลักษณะที่ดีดังต่อไปนี้ มีความเชื่อมแน่นสูง (High Cohesion) คลาสออกแบบที่มีความเชื่อมแน่นต้องมีขนาดเล็ก มีหน้าที่เดียวและเรียกใช้งานเพียงแอตทริบิวส์ภายใน

Arlow และ Neustadt แนะนำให้ทบทวนคลาสออกแบบว่ามีลักษณะที่ดีดังต่อไปนี้ มีความเชื่อมโยงต่ำ (Low Coupling) คลาสออกแบบต้องร่วมมือกันทำงานให้สำเร็จ อย่างไรก็ตาม ความร่วมมือควรอยู่ในระดับที่น้อยที่สุดที่ยอมรับได้

คลาสออกแบบสำหรับ FloorPlan และคลานประกอบอื่นๆ

9.4 แบบจำลองเชิงการออกแบบ (THE DESIGN MODEL)

9.4 แบบจำลองการออกแบบ (Object Oriented Analysis)
มิติของแบบจำลองการออกแบบ

จากรูปข้างต้น เราอาจมองแบบจำลองการออกแบบเป็นสองมิติ มิติของกระบวนการระบุวิวัฒนาการของแบบจำลอง ขณะที่มิติระดับความเป็นนามธรรม แทนระดับของรายละเอียด จากแบบจำลองการวิเคราะห์ไปสู่แบบจำลองการออกแบบ เราสามารถแยกความแตกต่างระหว่างแบบจำลองทั้งสองอย่างชัดเจน แต่ในบางกรณี แบบจำลองการวิเคราะห์มักจะหลอมเข้าหาการออกแบบทำให้ไม่เห็นความแตกต่างอย่างชัดเจน

9.4.1 ส่วนประกอบตัวแบบข้อมูล (Data Design Elements) การออกแบบข้อมูลสร้างแบบจำลองข้อมูลจากมุมมองผู้ใช้งาน จากนั้นจึงลงรายละเอียดให้แทนการอิมพลีเมนต์เฉพาะที่ประมวลผลด้วยคอมพิวเตอร์ได้ในหลายๆ แอพพลิเคชั่น สถาปัตยกรรมข้อมูลมีอิทธิพลอย่างมากกับสถาปัตยกรรมซอฟต์แวร์เอง

9.4.1 ส่วนประกอบตัวแบบข้อมูล (Data Design Elements) โครงสร้างข้อมูลต้องเป็นส่วนสำคัญของการออกแบบซอฟต์แวร์เสมอ ณ ระดับ คอมโพเน้นท์โปรแกรม การออกแบบโครงสร้างข้อมูลและอัลกอริทึมในการจัดการข้อมูลเป็นหัวใจของแอพพลิเคชั่นคุณภาพสูง ณ ระดับแอพพลิเคชั่น การแปลงแบบจำลองข้อมูล ซึ่งเป็นส่วนหนึ่งของงานวิศวกรรมความต้องการไปเป็นฐานข้อมูล เป็นส่วนสำคัญในการบรรลุเป้าหมายทางธุรกิจของระบบ ณ ระดับธุรกิจ ข้อมูลที่รวบรวมจากฐานข้อมูลต่างๆ และจัดระเบียบเป็นคลังข้อมูล ก่อให้เกิดการทำเหมืองข้อมูล หรือค้นหาความรู้ที่อาจมีผลกระทบต่อความสำเร็จของธุรกิจเอง การออกแบบข้อมูลเป็นเรื่องสำคัญมาก

9.4.2 ส่วนประกอบตัวแบบสถาปัตยกรรม (Architectural Design Elements) ตัวแบบสถาปัตยกรรมสำหรับซอฟต์แวร์ เปรียบเหมือนกับแปลนบ้านสำหรับบ้านอยู่อาศัย แปลนบ้านแสดงตำแหน่งของห้อง ขนาด รูปร่าง และความสัมพันธ์ระหว่างห้อง และประตู หน้าต่าง เข้าและออกจากห้องต่างๆ แปลนบ้านให้ภาพรวมของบ้าน ส่วนประกอบตัวแบบสถาปัตยกรรมก็ให้ภาพรวมของซอฟต์แวร์

9.4.2 ส่วนประกอบตัวแบบสถาปัตยกรรม (Architectural Design Elements) เราสร้างแบบจำลองสถาปัตยกรรมจากข้อมูลสามแหล่ง คือ ข้อมูลเกี่ยวกับโดเมนแอพพลิเคชั่นของซอฟต์แวร์ที่จะสร้าง แบบจำลองการวิเคราะห์ เช่น แผนภาพกระแสข้อมูล หรือคลาสวิเคราะห์ และความสัมพันธ์ระหว่างกัน แบบรูปสถาปัตยกรรมที่มีอยู่และสไตล์

9.4.3 ส่วนประกอบตัวแบบต่อประสาน (Interface Design Elements) ส่วนประกอบของตัวต่อประสาน คือ ตัวต่อประสานผู้ใช้งาน (User Interface) ตัวต่อประสานภายนอกกับระบบอื่นๆ หรือเครือข่าย ตัวต่อประสานภายในระหว่างคอมโพเน้นท์

9.4.3 ส่วนประกอบตัวแบบต่อประสาน (Interface Design Elements) การออกแบบตัวต่อประสานผู้ใช้งาน (User Interface) เป็นกิจกรรมหลักของวิศวกรรมซอฟต์แวร์ที่ต้องคำนึงถึงความสวยงาน การใช้งานได้โดยสะดวก และส่วนประกอบด้านเทคนิค เช่น การนำคอมโพเน้นท์กลับมาใช้งานใหม่

9.4.3 ส่วนประกอบตัวแบบต่อประสาน (Interface Design Elements) การออกแบบตัวต่อประสานภายนอก ต้องมีข้อมูลที่ชัดเจนเกี่ยวกับเอนทิตี้ที่ส่งและรับข้อมูล วิศวกรรมความต้องการรวบรวมข้อมูลเหล่านี้ และตรวจทานเพื่อใช้ในการออกแบบตัวต่อประสานงาน การออกแบบควรคำนึงถึงข้อผิดพลาดที่ต้องตรวจสอบและการรักษาความปลอดภัยที่เหมาะสม

9.4.3 ส่วนประกอบตัวแบบต่อประสาน (Interface Design Elements) การออกแบบตัวต่อประสานภายใน จะเชื่อมกับการออกแบบระดับคอมโพเน้นท์ ตัวแบบเป็นการแทนตัวปฏิบัติการและข่าวสาร (Message) ที่ส่งระหว่างคลาสข่าวสารแต่ละตัว รองรับการส่งผ่านข้อมูล และเรียกใช้หน้าที่การทำงานเฉพาะเจาะจงที่ต้องการ

WirelessPDA MobilePhone ControlPanel LCDdisplay LEDindicators keyPadCharacteristics Speaker wirelessInterface readKeyStroke( ) decodeKey( ) displayStatus( ) lightLEDs( ) sendControlMsg( ) KeyPad <<Interface>> KeyPad readKeystroke( ) decodeKey( ) แผนภาพยูเอ็มแอลสำหรับตัวต่อประสานของคลาส Control Panel

9.5 สรุปท้ายบท

9.5 สรุปท้ายบท การออกแบบซอฟต์แวร์เป็นการประยุกต์ชุดหลักการ แนวคิด และการปฏิบัติที่นำไปสู่การพัฒนาระบบคุณภาพสูง เป้าหมายของการออกแบบคือ เพื่อสร้างแบบจำลองซอฟต์แวร์ที่จะมีอิมพลีเมนต์ทุกๆ ความต้องการของลูกค้าอย่างถูกต้องและง่ายแก่การใช้งาน กระบวนการออกแบบเริ่มจาก “ภาพใหญ่” โดยรวมของซอฟต์แวร์ และค่อยๆ เคลื่อนไปสู่ภาพที่แคบลงที่กำหนดรายละเอียดที่จำเป็นในการอิมพลีเมนต์ระบบ กระบวนการเริ่มจากสถาปัตยกรรม ระบบย่อย กลไลการสื่อสารระหว่างระบบย่อย คอมโพเน้นท์และรายละเอียดของแต่ละคอมโพเน้นท์ นอกจากนี้ยังมีการออกแบบตัวต่อประสานภายใน ภายนอก และตัวต่อประสานผู้ใช้งาน

คำถามท้ายบท จงอธิบายความแตกต่างระหว่างการออกแบบซอฟต์แวร์กับการเขียนโน้ต จงอธิบายความหมายของสถาปัตยกรรมซอฟต์แวร์ ตามความเข้าใจของตนเอง จงอธิบายความสัมพันธ์ระหว่างแนวคิดการปกปิดข่าวสาร กับคุณลักษณะของความเป็นโมดูล และความเป็นอิสระของโมดูล เราจะประเมินคุณภาพของงานออกแบบซอฟต์แวร์ได้อย่างไร

บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)

งานนำเสนอที่คล้ายกัน

งานนำเสนอเรื่อง: "บทที่ 9 วิศวกรรมการออกแบบ (Design Engineering)"— ใบสำเนางานนำเสนอ:

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ