Please enable JavaScript.
Coggle requires JavaScript to display documents.
Software Engineering Concept Final - Coggle Diagram
Software Engineering Concept Final
System Modeling
โมเดลบริบท (Context models)
โมเดลบริบท อธิบายขอบเขตของระบบและความสัมพันธ์กับสภาพแวดล้อม
ขั้นตอน
กำหนดขอบเขตของระบบ
ระบุระบบอื่นๆ ในสภาพแวดล้อม
กำหนดความสัมพันธ์ระหว่างระบบ
ประโยชน์
เข้าใจบริบทของระบบ
ระบุความต้องการของระบบ
ออกแบบระบบให้ทำงานร่วมกับระบบอื่นๆ ได้
ประเด็นสำคัญ
ขอบเขตของระบบควรพิจารณาความต้องการของผู้ใช้ ต้นทุน และข้อจำกัดทางเทคนิค
โมเดลบริบทช่วยให้เข้าใจความสัมพันธ์ระหว่างระบบและสภาพแวดล้อม
โมเดลกิจกรรม UML แสดงกระบวนการทางธุรกิจที่ใช้ระบบ
คำถาม
อะไรคือปัจจัยที่ส่งผลต่อขอบเขตของระบบ?
ความต้องการของผู้ใช้
ต้นทุน
ข้อจำกัดทางเทคนิค
กฎหมายและข้อบังคับ
โครงสร้างองค์กร
ความเสี่ยง
กลยุทธ์ทางธุรกิจ
โมเดลบริบทมีประโยชน์อย่างไร?
ช่วยให้เข้าใจบริบทของระบบ
ระบุความต้องการของระบบ
ออกแบบระบบให้ทำงานร่วมกับระบบอื่นๆ ได้
กำหนดขอบเขตของระบบ
ระบุผู้มีส่วนได้เสีย
วางแผนการพัฒนาระบบ
โมเดลกิจกรรม UML แสดงอะไร?
กระบวนการทางธุรกิจที่ใช้ระบบ
กิจกรรมต่างๆ ในกระบวนการ
ลำดับการไหลของงาน
เงื่อนไขการไหลของงาน
ระบบที่ใช้สนับสนุนกิจกรรม
โมเดลระบบ คือ การแสดงระบบแบบนามธรรม โดยใช้สัญลักษณ์กราฟิก มักใช้ UML
วัตถุประสงค์
ช่วยกำหนดความต้องการระบบ
อธิบายระบบให้วิศวกร
บันทึกโครงสร้างและการทำงานของระบบ
โมเดลระบบ
ระบบที่มีอยู่: ช่วยชี้แจงว่าระบบทำงานอย่างไร และใช้เพื่อเน้นการอภิปรายเกี่ยวกับจุดแข็งและจุดอ่อนของระบบ
ระบบใหม่: ช่วยอธิบายข้อกำหนดที่เสนอให้กับผู้มีส่วนได้ส่วนเสีย และใช้เพื่อบันทึกระบบ
มุมมอง
ภายนอก: โมเดลบริบท
ปฏิสัมพันธ์: โมเดลการโต้ตอบ
โครงสร้าง: โมเดลองค์กร
พฤติกรรม: โมเดลพฤติกรรม
ไดอะแกรม UML
ไดอะแกรมกิจกรรม Activity diagrams: แสดงกิจกรรมในกระบวนการ
ไดอะแกรมกรณีใช้งาน Use case diagrams : แสดงการโต้ตอบระหว่างระบบกับสภาพแวดล้อม
ไดอะแกรมลำดับ Sequence diagrams : แสดงการโต้ตอบระหว่างตัวแสดงกับระบบ
ไดอะแกรมคลาส Class Diagram: แสดงคลาสอ็อบเจ็กต์และความสัมพันธ์
ไดอะแกรมสถานะ State diagrams : แสดงวิธีการที่ระบบตอบสนองต่อเหตุการณ์
โมเดลปฏิสัมพันธ์ (Interaction models)
โมเดลปฏิสัมพันธ์ อธิบายการโต้ตอบระหว่างระบบกับ:
ผู้ใช้
ระบบอื่นๆ
ส่วนประกอบของระบบ
ประโยชน์
ระบุความต้องการของผู้ใช้
เน้นปัญหาการสื่อสาร
เข้าใจประสิทธิภาพและความน่าเชื่อถือของระบบ
แนวทางสองแนวทางที่เกี่ยวข้องกับการสร้างโมเดลปฏิสัมพันธ์
การสร้างโมเดลกรณีการใช้งาน (use case modeling) ส่วนใหญ่ใช้เพื่อสร้างแบบจำลองการโต้ตอบระหว่างระบบกับตัวแทนภายนอก (ผู้ใช้มนุษย์หรือระบบอื่น)
ไดอะแกรมลำดับ (sequence diagrams) ใช้เพื่อสร้างแบบจำลองการโต้ตอบระหว่างส่วนประกอบของระบบ แม้ว่าตัวแทนภายนอกอาจรวมอยู่ด้วยก็ได้
โมเดลกรณีการใช้งาน (use case modeling)
องค์ประกอบ
กรณีการใช้งาน (use case) : งานแยกส่วนที่เกี่ยวข้องกับการโต้ตอบภายนอก
ตัวละคร (actor) : ผู้ใช้ ระบบภายนอก หรือฮาร์ดแวร์
ประโยชน์
เข้าใจภาพรวมการโต้ตอบ
ระบุความต้องการของผู้ใช้
ไดอะแกรมกรณีการใช้งาน (Use case diagram)
แสดงกรณีการใช้งานและตัวละคร
เส้นแสดงการเชื่อมโยงระหว่างกรณีการใช้งานและตัวละคร
ลูกศร (ไม่จำเป็น) แสดงทิศทางของการเริ่มต้นธุรกรรม
ไดอะแกรมลำดับ (Sequence diagrams) แสดงลำดับของการโต้ตอบระหว่าง:
ตัวละคร (actor)
วัตถุ
วัตถุกับวัตถุ
องค์ประกอบ
วัตถุ (object) : สิ่งที่มีสถานะและพฤติกรรม
ตัวละคร (actor) : ผู้ใช้ ระบบภายนอก หรือฮาร์ดแวร์
เส้นชีวิต (lifeline) : แสดงช่วงเวลาที่วัตถุมีส่วนร่วม
ลูกศร : แสดงการโต้ตอบ
กรอบ alt : แสดงตัวเลือก
โมเดลเชิงโครงสร้าง (Structural models)
โมเดลเชิงโครงสร้าง แสดงการจัดระเบียบของระบบซอฟต์แวร์
ประเภท
โมเดลแบบคงที่: แสดงการออกแบบระบบ
โมเดลแบบไดนามิก: แสดงการทำงานของระบบ
การใช้งาน
ออกแบบสถาปัตยกรรมระบบ
โมเดลวัตถุและความสัมพันธ์
เครื่องมือ
ไดอะแกรมคลาส
ไดอะแกรมคอมโพเนนต์
ไดอะแกรมแพ็กเกจ
ไดอะแกรมการปรับใช้
โมเดลแบบคงที่ vs โมเดลแบบไดนามิก
โมเดลแบบคงที่แสดงโครงสร้างระบบในขณะที่ออกแบบ
โมเดลแบบไดนามิกแสดงโครงสร้างระบบเมื่อระบบกำลังทำงาน
โครงสร้างทั้งสองแบบนี้อาจแตกต่างกันมาก
การใช้งานโมเดลเชิงโครงสร้าง
โมเดลเหล่านี้ใช้เพื่อหารือและออกแบบสถาปัตยกรรมระบบ
โมเดลเหล่านี้อาจเป็นโมเดลของระบบโดยรวม หรือโมเดลที่ละเอียดของวัตถุในระบบ
ไดอะแกรมคลาส Class Diagram
องค์ประกอบ
คลาส: วัตถุระบบประเภทหนึ่ง
ความสัมพันธ์: ลิงก์ระหว่างคลาส
ความหลากหลาย: จำนวนวัตถุที่เกี่ยวข้องกับความสัมพันธ์
แอตทริบิวต์: ลักษณะของวัตถุ
การดำเนินการ: ฟังก์ชันของวัตถุ
ไดอะแกรมคลาสเป็นเครื่องมือสำคัญในการออกแบบระบบ UML ช่วยให้คุณสามารถแสดงคลาส ความสัมพันธ์ แอตทริบิวต์ และการดำเนินการ
Generalization
Generalization เป็นเทคนิคในการจัดการความซับซ้อนโดยการ:
เรียนรู้ลักษณะทั่วไปของประเภท (สัตว์, รถยนต์, บ้าน, ฯลฯ)
นำความรู้กลับมาใช้ใหม่โดยจัดประเภทสิ่งต่างๆ
มุ่งเน้นไปที่ความแตกต่างระหว่างสิ่งต่างๆ กับประเภท
ประโยชน์
เก็บข้อมูลทั่วไปในที่เดียว
ง่ายต่อการจัดการการเปลี่ยนแปลง
นำไปใช้โดยใช้กลไกการสืบทอดคลาส
Generalization เป็นเทคนิคที่มีประโยชน์ในการจัดการความซับซ้อน UML มีเครื่องมือสำหรับแสดง Generalization และ Inheritance
Aggregation
Aggregation แสดงความสัมพันธ์แบบ "ทั้งหมด-ส่วน" ระหว่างคลาส
รายละเอียดเพิ่มเติม
Aggregation เป็นประเภทพิเศษของ Association
Aggregation แสดงความสัมพันธ์แบบ "มี"
วัตถุ "ส่วน" สามารถดำรงอยู่ได้โดยไม่ต้องมีวัตถุ "ทั้งหมด"
วัตถุ "ทั้งหมด" มีความรับผิดชอบในการจัดการวัตถุ "ส่วน"
ข้อควรระวัง
Aggregation ไม่ได้แสดงลำดับชั้น
Aggregation ไม่ได้แสดงความสัมพันธ์แบบพึ่งพา
โมเดลพฤติกรรม (Behavioral models)
โมเดลพฤติกรรม อธิบายพฤติกรรมแบบไดนามิกของระบบขณะทำงาน แสดงสิ่งที่เกิดขึ้นเมื่อระบบตอบสนองต่อสิ่งกระตุ้น
ประเภท
โมเดลพฤติกรรมที่ขับเคลื่อนด้วยข้อมูล: กระตุ้นโดยข้อมูล ป้อนข้อมูล -> ประมวลผล -> ผลลัพธ์
ตัวอย่าง: ระบบเรียกเก็บเงินค่าโทรศัพท์
โมเดลพฤติกรรมที่ขับเคลื่อนด้วยเหตุการณ์: กระตุ้นโดยเหตุการณ์ เกิดเหตุการณ์ -> ประมวลผล -> ตอบสนอง
ตัวอย่าง: ระบบสลับโทรศัพท์บ้าน
โมเดลพฤติกรรมเป็นเครื่องมือที่มีประโยชน์ในการอธิบายพฤติกรรมของระบบ UML มีเครื่องมือสำหรับสร้างโมเดลพฤติกรรมประเภทต่างๆ
โมเดลที่ขับเคลื่อนด้วยข้อมูล (Data-driven models)
ประเภท
ไดอะแกรมการไหลของข้อมูล (DFDs): เน้นที่การดำเนินการ
ไดอะแกรมกระบวนการ (Activity diagrams): เน้นที่กิจกรรม
ไดอะแกรมลำดับ (Sequence diagrams): เน้นที่อ็อบเจ็กต์
ประโยชน์
แสดงการประมวลผลแบบครบวงจร
เข้าใจง่าย
มีส่วนร่วมกับผู้มีส่วนได้ส่วนเสีย
โมเดลที่ขับเคลื่อนด้วยข้อมูลเป็นเครื่องมือที่มีประโยชน์ในการแสดงลำดับการดำเนินการในการประมวลผลข้อมูล UML มีเครื่องมือสำหรับสร้างโมเดลที่ขับเคลื่อนด้วยข้อมูลประเภทต่างๆ
โมเดลที่ขับเคลื่อนด้วยเหตุการณ์ (Event-driven modeling)
โมเดลที่ขับเคลื่อนด้วยเหตุการณ์ แสดงการตอบสนองของระบบต่อเหตุการณ์
องค์ประกอบ
สถานะ: สถานะการทำงานของระบบ
เหตุการณ์: สิ่งเร้าที่ทำให้ระบบเปลี่ยนสถานะ
ข้อดี
เข้าใจง่าย
เหมาะสำหรับระบบเรียลไทม์
โมเดลที่ขับเคลื่อนด้วยเหตุการณ์เป็นเครื่องมือที่มีประโยชน์ในการแสดงการตอบสนองของระบบต่อเหตุการณ์ UML มีเครื่องมือสำหรับสร้างโมเดลที่ขับเคลื่อนด้วยเหตุการณ์
Model-driven engineering (MDE)
Model-driven engineering (MDE) หรือ วิศวกรรมซอฟต์แวร์เชิงโมเดล เป็นแนวทางการพัฒนาซอฟต์แวร์ที่ใช้โมเดลเป็นศูนย์กลาง แทนที่จะเขียนโปรแกรมโดยตรง โมเดลเหล่านี้จะถูกใช้เพื่อสร้างโปรแกรมสำหรับแพลตฟอร์มต่างๆ โดยอัตโนมัติ
ข้อดี
เพิ่มระดับนามธรรม
นักพัฒนาไม่ต้องกังวลกับรายละเอียดของภาษาโปรแกรมหรือแพลตฟอร์ม
ช่วยให้การพัฒนาซอฟต์แวร์มีประสิทธิภาพมากขึ้น
ความสัมพันธ์กับ MDA
MDE พัฒนาต่อยอดมาจาก MDA (Model-Driven Architecture)
MDA เน้นที่ขั้นตอนการออกแบบและการนำไปใช้งาน
MDE ครอบคลุมทุกแง่มุมของการพัฒนาซอฟต์แวร์
รายละเอียดเพิ่มเติม
MDE เป็นวิธีการพัฒนาซอฟต์แวร์ที่เน้นโมเดล
โมเดลถูกสร้างขึ้นเพื่ออธิบายระบบ
โมเดลเหล่านี้ถูกใช้เพื่อสร้างโปรแกรมโดยอัตโนมัติ
MDE มีศักยภาพที่จะเพิ่มประสิทธิภาพของการพัฒนาซอฟต์แวร์
ยังมีอุปสรรคบางประการที่ขัดขวางการนำ MDE ไปใช้
Model-driven architecture
MDA เป็นแนวทางการออกแบบและนำซอฟต์แวร์ไปใช้งานที่เน้นการใช้โมเดล แทนที่จะเขียนโปรแกรมโดยตรง
ประเภทของโมเดล
โมเดลที่ไม่ขึ้นกับการคำนวณ (CIM)
โมเดลที่ไม่ขึ้นกับแพลตฟอร์ม (PIM)
โมเดลเฉพาะแพลตฟอร์ม (PSM)
ข้อดี
ช่วยให้นักพัฒนาคิดในระดับนามธรรม
ลดโอกาสเกิดข้อผิดพลาด
เร่งความเร็วในกระบวนการพัฒนา
ช่วยให้สร้างโมเดลที่นำกลับมาใช้ใหม่ได้
ข้อจำกัด
การแปลงโมเดลเป็นรหัสโดยอัตโนมัติทั้งหมดนั้นเป็นไปได้ยาก
เครื่องมือสนับสนุน MDA มักมีตัวแปลเฉพาะแพลตฟอร์ม
ไม่เหมาะสำหรับระบบขนาดเล็ก
ขัดแย้งกับแนวคิด agile
การใช้งาน
เหมาะสำหรับผลิตภัณฑ์ระบบที่มีอายุการใช้งานยาวนาน
ใช้กันอย่างแพร่หลายในบริษัทที่พัฒนาผลิตภัณฑ์ฮาร์ดแวร์และซอฟต์แวร์
ความสัมพันธ์กับวิธี agile
ไม่แน่นอน
แนวคิดของ MDA ขัดแย้งกับแนวคิดพื้นฐานของ agile
มีบางส่วนของ MDA ที่สามารถนำไปใช้กับ agile ได้
รายละเอียดเพิ่มเติม
MDA เน้นการสร้างโมเดล UML ย่อยชุดหนึ่งเพื่ออธิบายระบบ
โมเดลเหล่านี้ถูกสร้างขึ้นในระดับนามธรรมที่แตกต่างกัน
มีเครื่องมือเชิงพาณิชย์และเครื่องมือโอเพ่นซอร์สสำหรับการแปลงโมเดล
MDA ไม่ได้กลายเป็นแนวทางหลักในการพัฒนาซอฟต์แวร์
เหมาะสำหรับระบบเฉพาะบางประเภท
Architectural design
บทนำ
บทบาท
เชื่อมโยงความต้องการของระบบกับการออกแบบ
กำหนดส่วนประกอบหลักของระบบและความสัมพันธ์
อธิบายวิธีจัดระเบียบระบบซอฟต์แวร์
สถาปัตยกรรมขนาดเล็ก: การออกแบบโปรแกรมแต่ละโปรแกรม
สถาปัตยกรรมขนาดใหญ่: โครงสร้างของระบบองค์กร
ความสำคัญ
ส่งผลต่อประสิทธิภาพ ความเสถียร การกระจาย และความสามารถในการบำรุงรักษา
มีอิทธิพลต่อคุณสมบัติที่ไม่ใช่ฟังก์ชันการทำงานของระบบ
ข้อดี
สื่อสารกับผู้มีส่วนได้ส่วนเสีย
วิเคราะห์ระบบ
นำกลับมาใช้ใหม่
รูปแบบ
แผนภาพบล็อก: แสดงภาพโครงสร้างระบบ
ภาษาอธิบายสถาปัตยกรรม: อธิบายสถาปัตยกรรมอย่างละเอียด
การใช้งาน
อภิปรายการออกแบบระบบ
วางแผนโครงการ
บันทึกสถาปัตยกรรมที่ออกแบบแล้ว
ประเด็นสำคัญ
การออกแบบโครงสร้างซอฟต์แวร์เป็นขั้นตอนแรกในการออกแบบซอฟต์แวร์
สถาปัตยกรรมซอฟต์แวร์มีบทบาทสำคัญต่อคุณสมบัติของระบบ
มีหลายวิธีในการออกแบบและบันทึกสถาปัตยกรรมซอฟต์แวร์
ทางเลือกที่ดีที่สุดขึ้นอยู่กับขนาดและความซับซ้อนของระบบ
Architectural design decisions
การออกแบบสถาปัตยกรรมระบบ
กระบวนการสร้างสรรค์โครงสร้างของระบบ
ตอบสนองความต้องการทั้งด้านการทำงานและด้านอื่นๆ
ขึ้นอยู่กับประเภทของระบบ ประสบการณ์ และความต้องการของระบบ
ไม่มีสูตรตายตัว
คำถามพื้นฐาน
ระบบของคุณเป็นประเภทไหน?
ระบบของคุณจะกระจายหรือไม่?
รูปแบบสถาปัตยกรรมแบบไหน?
กลยุทธ์การแบ่งย่อยชิ้นส่วน?
รูปแบบการควบคุม?
ความสัมพันธ์กับความต้องการที่ไม่ใช่การทำงาน
ประสิทธิภาพ
ความปลอดภัย
ความปลอดภัย
ความพร้อมใช้งาน
การบำรุงรักษา
การประเมินการออกแบบ
เปรียบเทียบกับสถาปัตยกรรมอ้างอิง
เปรียบเทียบกับรูปแบบสถาปัตยกรรมทั่วไป
คำอธิบายของ Bosch เกี่ยวกับลักษณะเฉพาะที่ไม่ใช่การทำงาน
ประเด็นสำคัญ
การตัดสินใจออกแบบสถาปัตยกรรมส่งผลต่อระบบและกระบวนการพัฒนา
รูปแบบสถาปัตยกรรมคือคำอธิบายโครงสร้างของระบบ
เลือกโครงสร้างที่เหมาะสมเพื่อตอบสนองความต้องการของระบบ
สถาปัตยกรรมควรออกแบบให้รองรับความต้องการที่ไม่ใช่การทำงาน
การประเมินการออกแบบสถาปัตยกรรมเป็นเรื่องยาก
Architectural views
โมเดลสถาปัตยกรรม
ใช้เพื่อเน้นการพูดคุยเกี่ยวกับความต้องการ หรือการออกแบบซอฟต์แวร์
บันทึกการออกแบบ เพื่อใช้เป็นพื้นฐานสำหรับการออกแบบและการใช้งานระบบ
มุมมอง
แสดงข้อมูลด้านใดด้านหนึ่งหรือมุมมองหนึ่งของระบบ
มุมมองพื้นฐาน 4 แบบ:
เชิงตรรกะ: แสดงแนวคิดสำคัญในระบบเป็นอ็อบเจกต์หรือคลาส
เชิงกระบวนการ: แสดงการโต้ตอบกันของกระบวนการรันไทม์
เชิงพัฒนาการ: แสดงการแบ่งส่วนซอฟต์แวร์เพื่อการพัฒนา
เชิงกายภาพ: แสดงฮาร์ดแวร์ของระบบและวิธีการกระจายส่วนประกอบซอฟต์แวร์
มุมมองเพิ่มเติม
เชิงแนวคิด: มุมมองนามธรรมของระบบ
ใช้สำหรับอธิบายสถาปัตยกรรมระบบให้ผู้มีส่วนได้ส่วนเสียเข้าใจ
ใช้เป็นข้อมูลประกอบการตัดสินใจด้านสถาปัตยกรรม
เอกสารการออกแบบ
ผู้ใช้แนวทาง Agile มักอ้างว่าเอกสารการออกแบบรายละเอียดส่วนใหญ่ไม่ได้ถูกนำไปใช้
ไม่จำเป็นต้องพัฒนาคำอธิบายสถาปัตยกรรมอย่างละเอียด
พัฒนามุมมองที่เป็นประโยชน์สำหรับการสื่อสาร
ประเด็นสำคัญ
ไม่สามารถแสดงข้อมูลทั้งหมดเกี่ยวกับสถาปัตยกรรมของระบบในแผนภาพเดียวได้
มีมุมมองสถาปัตยกรรมหลายแบบ
มุมมองเชิงแนวคิดมักจะพัฒนาขึ้นในระหว่างกระบวนการออกแบบ
UML มีประโยชน์ในการบันทึกสถาปัตยกรรมอย่างละเอียด
ADLs ยากต่อผู้เชี่ยวชาญด้านโดเมนและแอปพลิเคชัน
โมเดลและสัญกรณ์ที่ไม่เป็นทางการนิยมใช้กันมากที่สุด
เอกสารการออกแบบรายละเอียดส่วนใหญ่ไม่ได้ถูกนำไปใช้
Architectural patterns
รายละเอียด
รูปแบบ (Patterns)
มีการประยุกต์ใช้ในหลายๆ ด้านของวิศวกรรมซอฟต์แวร์
แนวทางในการนำเสนอ แบ่งปัน และนำความรู้เกี่ยวกับระบบซอฟต์แวร์กลับมาใช้ใหม่
รูปแบบสถาปัตยกรรม (Architectural Patterns)
เสนอในช่วงทศวรรษที่ 1990
อธิบายโครงสร้างระบบที่ประสบความสำเร็จ
แนะนำแนวทางที่ดีผ่านการทดลองและใช้ในระบบต่างๆ
องค์ประกอบของรูปแบบ
ชื่อรูปแบบ
คำอธิบายสั้นๆ
แบบจำลองกราฟิก
ตัวอย่างของประเภทระบบที่ใช้รูปแบบ
ข้อมูลเกี่ยวกับเวลาที่ควรใช้รูปแบบ
ข้อดีและข้อเสียของรูปแบบ
ตัวอย่างรูปแบบ
Model-View-Controller (MVC): รูปแบบพื้นฐานของการจัดการการโต้ตอบในระบบเว็บ
ประเด็นสำคัญ
รูปแบบสถาปัตยกรรมเป็นคำอธิบายเชิงนามธรรมของแนวทางที่ดี
รูปแบบควรมีข้อมูลเกี่ยวกับเวลาที่เหมาะสมและไม่เหมาะสมที่จะใช้
รูปแบบควรมีรายละเอียดเกี่ยวกับจุดแข็งและจุดอ่อน
Layered Architecture
แนวคิดหลัก
แยกส่วนและความเป็นอิสระ
การพัฒนาเชิงเพิ่ม
ความสามารถในการเปลี่ยนแปลงและพกพา
การลดการขึ้นอยู่กับเครื่องเฉพาะ
องค์ประกอบ
เลเยอร์แยกต่างหาก
แต่ละเลเยอร์อาศัยเลเยอร์ด้านล่าง
อินเทอร์เฟซระหว่างเลเยอร์
ข้อดี
รองรับการพัฒนาเชิงเพิ่ม
เปลี่ยนแปลงและพกพาง่าย
ลดการขึ้นอยู่กับเครื่องเฉพาะ
สนับสนุนการใช้งานแอปพลิเคชันระบบแบบมัลติแพลตฟอร์ม
ประเด็นสำคัญ
รูปแบบสถาปัตยกรรมแบบเลเยอร์เป็นวิธีหนึ่งในการสร้างการแยกส่วนและความเป็นอิสระ
รูปแบบนี้รองรับการพัฒนาเชิงเพิ่มและช่วยให้สามารถเปลี่ยนแปลงและพกพาระบบได้ง่าย
รูปแบบนี้ช่วยลดการขึ้นอยู่กับเครื่องเฉพาะ
Repository Architecture
สถาปัตยกรรมแบบเลเยอร์และแพทเทิร์น MVC เป็นตัวอย่างของแพทเทิร์นที่มุมมองที่นำเสนอคือการจัดระเบียบระบบเชิงแนวคิด
ระบบจัดการข้อมูลแบบรวมศูนย์ (Centralized Repository)
ระบบส่วนใหญ่ที่ใช้ข้อมูลจำนวนมากมักจะจัดระเบียบโดยใช้ฐานข้อมูลหรือที่เก็บข้อมูล (repository) ร่วมกัน รูปแบบนี้จึงเหมาะกับแอปพลิเคชันที่ข้อมูลถูกสร้างโดยส่วนประกอบหนึ่งและใช้งานโดยอีกส่วนประกอบ
องค์ประกอบหลักของ Repository Architecture:
Repository: เป็นชั้นที่ทำหน้าที่จัดการการเข้าถึงข้อมูลโดยตรง รับผิดชอบการดึงข้อมูล บันทึกข้อมูล และลบข้อมูล
Data Access Layer (DAL): เป็นชั้นกลางที่ทำหน้าที่เชื่อมต่อระหว่าง Repository กับ Business Logic Layer ทำหน้าที่แปลงคำขอจาก Business Logic Layer เป็นคำสั่ง SQL ที่ Repository เข้าใจ
Business Logic Layer (BLL): เป็นชั้นที่ควบคุมการทำงานหลักของโปรแกรม ทำหน้าที่ประมวลผลข้อมูล ตัดสินใจ และส่งคำขอไปยัง DAL
Presentation Layer: เป็นชั้นที่แสดงผลลัพธ์ให้กับผู้ใช้ ทำหน้าที่รับข้อมูลจาก BLL แสดงผลบนหน้าจอ
ข้อดีของ Repository Architecture:
ความยืดหยุ่น: สามารถเปลี่ยนแปลงวิธีการจัดเก็บข้อมูลได้โดยไม่ต้องแก้ไขโปรแกรมส่วนอื่น
การทดสอบ: ง่ายต่อการทดสอบ Repository แยกต่างหากจากส่วนอื่นๆ ของโปรแกรม
การบำรุงรักษา: ง่ายต่อการบำรุงรักษาและแก้ไขโปรแกรม
การแยกส่วน: แยกส่วนการเข้าถึงข้อมูลออกจาก Business Logic
Client–server architecture
แยกส่วนประกอบเป็น:
เซิร์ฟเวอร์: นำเสนอบริการ เช่น การพิมพ์ ไฟล์ การคอมไพล์
ไคลเอนต์: เรียกใช้บริการจากเซิร์ฟเวอร์
เครือข่าย: เชื่อมต่อไคลเอนต์กับเซิร์ฟเวอร์
ข้อดี:
ความเป็นอิสระ: เปลี่ยนแปลงบริการและเซิร์ฟเวอร์ได้โดยไม่ส่งผลต่อส่วนอื่น
การขยาย: เพิ่มเซิร์ฟเวอร์ใหม่ได้ง่าย
ประสิทธิภาพ: กระจายการประมวลผลบนหลายคอมพิวเตอร์
ข้อดีของสถาปัตยกรรมแบบ Client-Server:
กระจายศูนย์: ใช้ระบบเครือข่ายที่มีตัวประมวลผลแบบกระจาย
การขยาย: เพิ่มเซิร์ฟเวอร์ใหม่ได้ง่าย
การอัปเกรด: อัปเกรดเซิร์ฟเวอร์ได้โปร่งใส
แพทเทิร์น Client-Server เหมาะสำหรับระบบกระจายที่ต้องการความเป็นอิสระ การขยาย และประสิทธิภาพ
Pipe and filter architecture
รูปแบบ Pipe and Filter:
โมเดลการจัดระเบียบการทำงานของระบบ
แปลงข้อมูลนำเข้าเป็นข้อมูลผลลัพธ์
ข้อมูลไหลผ่านลำดับการแปลง
แต่ละขั้นตอนเป็นการแปลงฟังก์ชัน
ข้อมูลสามารถประมวลผลแบบเรียงลำดับหรือแบบขนาน
ที่มาของชื่อ:
มาจากระบบ Unix ดั้งเดิม
ท่อ (pipe) ส่งผ่านสตรีมข้อความ
ฟิลเตอร์ (filter) ประมวลผลข้อมูล
การใช้งาน:
ประมวลผลข้อมูลอัตโนมัติ
ระบบประมวลผลแบบชุด (batch processing)
ระบบฝังตัว
ข้อดี:
เหมาะสำหรับระบบประมวลผลแบบชุด
เหมาะสำหรับระบบฝังตัว
ข้อเสีย:
เขียนยากสำหรับระบบแบบโต้ตอบ
ยากต่อการจัดการส่วนติดต่อผู้ใช้แบบกราฟิก (GUI)
รูปแบบ Pipe and Filter:
เหมาะสำหรับการประมวลผลข้อมูลแบบต่อเนื่อง
ไม่เหมาะสำหรับระบบแบบโต้ตอบ
Application architectures
รายละเอียด
สถาปัตยกรรมของแอปพลิเคชัน:
รวบรวมลักษณะสำคัญของระบบประเภทต่างๆ
นำกลับมาใช้ใหม่เมื่อพัฒนาระบบใหม่
ตัวอย่าง: ระบบเรียลไทม์ ระบบ ERP
อธิบายโครงสร้างและองค์ประกอบของระบบซอฟต์แวร์
การใช้งาน:
จุดเริ่มต้นกระบวนการออกแบบสถาปัตยกรรม
รายการตรวจสอบการออกแบบ
วิธีจัดระเบียบงานของทีมพัฒนา
วิธีประเมินคอมโพเนนต์สำหรับการนำกลับมาใช้ใหม่
คำศัพท์สำหรับพูดคุยเกี่ยวกับแอปพลิเคชัน
ประเด็นสำคัญ:
สถาปัตยกรรมของแอปพลิเคชันช่วยให้พัฒนาระบบใหม่ได้รวดเร็ว
ระบบธุรกิจบนเว็บส่วนใหญ่เป็นระบบประมวลผลธุรกรรม
การพัฒนาซอฟต์แวร์ทั้งหมดขึ้นอยู่กับระบบประมวลผลภาษา
Transaction processing systems
ระบบประมวลผลธุรกรรม:
ออกแบบมาเพื่อประมวลผลคำขอข้อมูล/อัปเดตฐานข้อมูล
ธุรกรรม: ลำดับการดำเนินการที่เป็นหน่วยอะตอม
ตัวอย่าง: การถอนเงินจากบัญชีธนาคาร
โครงสร้างสถาปัตยกรรม:
ส่วนประกอบ I/O: ประมวลผลคำขอ
ตรรกะแอปพลิเคชัน: ประมวลผลธุรกรรม
ตัวจัดการธุรกรรม: ควบคุมธุรกรรม
ฐานข้อมูล: เก็บข้อมูล
การจัดระเบียบ:
สถาปัตยกรรมแบบ "ไปป์และฟิลเตอร์"
ส่วนประกอบ: อินพุต, ประมวลผล, ผลลัพธ์
ตัวอย่าง:
ระบบ ATM
ซอฟต์แวร์ ATM: อินพุต/เอาต์พุต
ซอฟต์แวร์เซิร์ฟเวอร์: ประมวลผล
ประเด็นสำคัญ:
ธุรกรรมฐานข้อมูล: รักษาความสมบูรณ์ของข้อมูล
ระบบประมวลผลธุรกรรม: ตอบสนองเป้าหมายของผู้ใช้
Information systems
ระบบสารสนเทศ:
เกี่ยวข้องกับการโต้ตอบกับฐานข้อมูลขนาดใหญ่
ตัวอย่าง: แคตตาล็อกห้องสมุด ตารางเที่ยวบิน ประวัติผู้ป่วย
ส่วนใหญ่เป็นระบบบนเว็บ
โมเดลทั่วไป:
แบ่งเป็นเลเยอร์
เลเยอร์บนสุด: ส่วนติดต่อผู้ใช้
เลเยอร์ล่างสุด: ฐานข้อมูล
เลเยอร์กลาง: ตรรกะแอปพลิเคชัน
ระบบ Mentcare
เลเยอร์บนสุด: ส่วนติดต่อผู้ใช้บนเบราว์เซอร์
เลเยอร์ที่สอง: ฟังก์ชันการทำงานของส่วนติดต่อผู้ใช้
เลเยอร์ที่สาม: ฟังก์ชันการทำงานของระบบ
เลเยอร์ล่างสุด: ฐานข้อมูล
ข้อดี:
เพิ่มประสิทธิภาพการทำงาน
รองรับธุรกรรมจำนวนมาก
Language processing systems
ระบบประมวลภาษา:
แปลงภาษาหนึ่งเป็นรูปแบบอื่น
ตัวอย่าง: คอมไพเลอร์ ระบบแปลภาษาธรรมชาติ
สถาปัตยกรรม:
คำสั่งภาษาต้นฉบับ -> คำสั่งสำหรับเครื่องมือทางนามธรรม -> interpreted -> ผลลัพธ์
ตัวแปล: ฮาร์ดแวร์ หรือ ซอฟต์แวร์
ส่วนประกอบคอมไพเลอร์:
ตัววิเคราะห์คำศัพท์
ตารางสัญลักษณ์
ตัววิเคราะห์ไวยากรณ์
แผนผังไวยากรณ์
ตัววิเคราะห์ความหมาย
ตัวสร้างโค้ด
สถาปัตยกรรมทางเลือก:
โมเดลท่อและกรอง
ตารางสัญลักษณ์: ฐานข้อมูล
ขั้นตอน: เรียงลำดับ
สื่อสาร: ผ่านตารางสัญลักษณ์
Design and implementation
บทนำ
ประเด็นสำคัญ:
การออกแบบและพัฒนาซอฟต์แวร์เป็นขั้นตอนสำคัญของกระบวนการวิศวกรรมซอฟต์แวร์
การออกแบบซอฟต์แวร์เป็นกิจกรรมที่สร้างสรรค์
มีทั้งการออกแบบแบบแยกขั้นตอนและแบบรวมกับการพัฒนา
การใช้ UML ไม่จำเป็นเสมอไป
การตัดสินใจว่า "สร้างเอง" หรือ "ซื้อสำเร็จรูป" เป็นสิ่งสำคัญ
เป้าหมายของบทนี้:
แสดงให้เห็นว่าการสร้างโมเดลและสถาปัตยกรรมถูกนำไปใช้ในการออกแบบเชิงวัตถุอย่างไร
แนะนำประเด็นการพัฒนาสำคัญที่มักไม่ค่อยพบในหนังสือสอนเขียนโปรแกรม
ตัวอย่างทั้งหมดจะใช้ UML แทนภาษาโปรแกรม
Object-oriented design using the UML
บทนำ
ระบบเชิงวัตถุ:
ออบเจ็กต์: เก็บรักษาสถานะและดำเนินการ
การออกแบบเชิงวัตถุ: ออกแบบคลาสออบเจ็กต์และความสัมพันธ์
ประกอบด้วยออบเจ็กต์ที่มีการโต้ตอบกัน
ออบเจ็กต์:
เก็บข้อมูลและการดำเนินการ
เข้าใจและแก้ไขได้โดยอิสระ
เปลี่ยนแปลงการใช้งานโดยไม่ส่งผลต่อออบเจ็กต์อื่น
การออกแบบระบบ:
เข้าใจบริบทและการทำงานร่วมกัน
ออกแบบสถาปัตยกรรม
ระบุออบเจ็กต์หลัก
พัฒนาโมเดลการออกแบบ
กำหนดรายละเอียดอินเทอร์เฟซ
กระบวนการออกแบบ:
ไม่ใช่กระบวนการที่ตายตัว
หาไอเดีย เสนอโซลูชัน ปรับปรุง
ย้อนกลับไปแก้ไข
เจาะลึกรายละเอียด หรือปล่อยไว้
System context and interactions
วัตถุประสงค์:
ตัดสินใจเกี่ยวกับ ฟังก์ชันการทำงาน
จัดโครงสร้างระบบเพื่อ สื่อสาร กับสภาพแวดล้อม
กำหนด ขอบเขต ของระบบ
ตัดสินใจว่า คุณลักษณะ ใดจะรวมอยู่ในระบบ
โมเดล:
โมเดลบริบทของระบบ:
แสดง ระบบอื่นๆ ในสภาพแวดล้อม
ใช้ ความสัมพันธ์
โมเดลปฏิสัมพันธ์:
แสดง วิธีการ ที่ระบบโต้ตอบกับสภาพแวดล้อม
ใช้ โมเดลกรณีการใช้งาน
โมเดลกรณีการใช้งาน:
แต่ละกรณีแสดงถึง การโต้ตอบ กับระบบ
วงรี: ชื่อการโต้ตอบ
รูปแท่ง: เอนทิตีภายนอก
คำอธิบาย: ภาษาธรรมชาติที่มีโครงสร้าง
Architectural design
วัตถุประสงค์:
ระบุ ส่วนประกอบหลัก ของระบบ
กำหนด การโต้ตอบ ของส่วนประกอบ
ออกแบบ องค์กร ของระบบ
ใช้ รูปแบบโครงสร้าง
Object class identification
วัตถุประสงค์:
ระบุ คลาสออบเจ็กต์ ทั่วไปในระบบ
ใช้ แหล่งความรู้หลายแหล่ง
ปรับแต่ง การออกแบบออบเจ็กต์ ให้ละเอียดยิ่งขึ้น
วิธีการ:
วิเคราะห์ คำอธิบายภาษาธรรมชาติ
ระบุ เอนทิตีที่จับต้องได้
วิเคราะห์ สถานการณ์
Design models
โมเดลการออกแบบ หรือ โมเดลระบบ แสดงถึง ออบเจ็กต์ หรือ คลาสออบเจ็กต์ ในระบบ ความสัมพันธ์ และความเชื่อมโยงระหว่างเอนทิตีเหล่านี้
วัตถุประสงค์:
เป็นสะพานเชื่อมระหว่าง ความต้องการของระบบ กับ การใช้งานของระบบ
สื่อสาร การออกแบบ กับสมาชิกทีม
ระดับความละเอียด:
ขึ้นอยู่กับ กระบวนการออกแบบ
โมเดลนามธรรม
โมเดลแบบละเอียด
ประเภทของโมเดล:
โมเดลไดนามิก
แสดงโครงสร้างไดนามิกของระบบ
โต้ตอบรันไทม์
ลำดับของคำขอบริการ
การเปลี่ยนแปลงสถานะ
โมเดลโครงสร้าง
ความสัมพันธ์: การสืบทอด, การใช้/ถูกใช้โดย, องค์ประกอบ
แสดงโครงสร้างคงที่ของระบบ
Interface specification
วัตถุประสงค์:
ระบุ ส่วนต่อประสาน ระหว่างส่วนประกอบต่างๆ ในการออกแบบ
อนุญาตให้ ออกแบบวัตถุแบบขนานกัน
กำหนด ลายเซ็น และ ความหมาย ของบริการ
เนื้อหา:
รายละเอียดของ ส่วนต่อประสาน กับวัตถุหรือกลุ่มของวัตถุ
สเตอริโอไทป์ UML «interface»
ภาษาข้อจำกัดอ็อบเจ็กต์ (OCL)
การดำเนินการ เพื่อเข้าถึงและอัปเดตข้อมูล
การออกแบบ:
ไม่รวม รายละเอียดของการแทนข้อมูล
เปิดเผย แอตทริบิวต์ในโมเดลอ็อบเจ็กต์
อ็อบเจ็กต์เดียวกันอาจมี หลายอินเทอร์เฟซ
ข้อดี:
การออกแบบที่ ดูแลรักษาได้ง่ายขึ้น
รองรับ มุมมอง ต่างๆ เกี่ยวกับเมธอด
Design patterns
Design patterns เป็นแนวคิดที่นำเสนอโดย Christopher Alexander เป็นการอธิบายวิธีการแก้ปัญหาการออกแบบที่พบบ่อย โดยสามารถนำไปใช้ในสถานการณ์ที่แตกต่างกันได้
รูปแบบ
ชื่อ: สื่อถึงรูปแบบนั้น ๆ อย่างชัดเจน
คำอธิบายปัญหา: บอกสถานการณ์ที่ควรใช้รูปแบบนี้
คำอธิบายแนวทางแก้ไข: อธิบายองค์ประกอบต่าง ๆ ในแนวทางแก้ไข การเชื่อมโยงกัน และหน้าที่ความรับผิดชอบ
ผลลัพธ์และทางเลือก: อธิบายผลลัพธ์และทางเลือกจากการใช้รูปแบบนี้
ประโยชน์:
นำความรู้และประสบการณ์ของนักออกแบบคนอื่นมาใช้ใหม่
ช่วยให้นักออกแบบพูดคุยเกี่ยวกับการออกแบบได้อย่างมีประสิทธิภาพ
นำแนวคิดกลับมาใช้ใหม่ได้ โดยปรับแต่งให้เหมาะสมกับระบบ
ข้อจำกัด:
โปรแกรมเมอร์ที่ไม่มีประสบการณ์อาจใช้รูปแบบได้ไม่เต็มประสิทธิภาพ
หายากที่จะค้นหารูปแบบที่เหมาะสมสำหรับปัญหาเฉพาะ
Implementation issues
บทนำ
วิศวกรรมซอฟต์แวร์ ครอบคลุมกิจกรรมทั้งหมดที่เกี่ยวข้องกับการพัฒนาซอฟต์แวร์ ตั้งแต่การกำหนดข้อกำหนด ไปจนถึงการบำรุงรักษา และการจัดการระบบ
การนำไปใช้ เป็นขั้นตอนสำคัญที่สร้างซอฟต์แวร์เวอร์ชันที่ใช้งานได้ ซอฟต์แวร์อาจถูกเขียนในภาษาโปรแกรม หรือปรับแต่งจากระบบสำเร็จรูป
บทนี้มุ่งเน้นไปที่:
การนำกลับมาใช้: การใช้ส่วนประกอบหรือระบบที่มีอยู่
การจัดการการกำหนดค่า: การติดตามเวอร์ชันของซอฟต์แวร์
การพัฒนาโฮสต์-เป้าหมาย: การพัฒนาบนเครื่องหนึ่ง (โฮสต์) และใช้งานบนอีกเครื่องหนึ่ง (เป้าหมาย)
ประเด็นสำคัญ:
ซอฟต์แวร์สมัยใหม่มักสร้างจากการนำส่วนประกอบที่มีอยู่กลับมาใช้
การจัดการการกำหนดค่าเป็นสิ่งสำคัญเพื่อติดตามเวอร์ชันของซอฟต์แวร์
การพัฒนาโฮสต์-เป้าหมายต้องพิจารณาความแตกต่างระหว่างระบบโฮสต์และเป้าหมาย
Reuse
ระดับของการนำกลับมาใช้:
ระดับนามธรรม: นำความรู้เกี่ยวกับนามธรรมที่ประสบความสำเร็จมาใช้ เช่น รูปแบบการออกแบบ
ระดับออบเจ็กต์: นำออบเจ็กต์จากไลบรารีมาใช้ซ้ำ เช่น ไลบรารี JavaMail
ระดับคอมโพเนนต์: นำคอมโพเนนต์มาใช้ซ้ำ เช่น เฟรมเวิร์กสำหรับสร้างส่วนต่อประสานผู้ใช้
ระดับระบบ:
ข้อดีของการนำกลับมาใช้:
พัฒนาระบบใหม่ได้เร็วขึ้น
มีความเสี่ยงในการพัฒนาน้อยลง
ต้นทุนต่ำกว่า
ค่าใช้จ่ายของการนำกลับมาใช้:
ค่าใช้จ่ายของเวลา
ค่าใช้จ่ายในการซื้อซอฟต์แวร์
ค่าใช้จ่ายในการปรับแต่งและกำหนดค่า
ค่าใช้จ่ายในการบูรณาการ
Configuration management
การจัดการคอนฟิก เป็นกระบวนการจัดการระบบซอฟต์แวร์ที่มีการเปลี่ยนแปลง จุดมุ่งหมายคือเพื่อ:
สนับสนุนการบูรณาการระบบ
ให้การเข้าถึงโค้ดและเอกสารเวอร์ชันล่าสุด
ติดตามการเปลี่ยนแปลง
ค้นหาสาเหตุของปัญหา
ย้อนกลับไปยังเวอร์ชันที่ทำงานได้
กิจกรรมการจัดการคอนฟิกหลัก:
การจัดการเวอร์ชัน: ติดตามเวอร์ชันของคอมโพเนนต์ซอฟต์แวร์
การบูรณาการระบบ: กำหนดเวอร์ชันของคอมโพเนนต์สำหรับการสร้างระบบ
การติดตามปัญหา: รายงานและติดตามจุดบกพร่อง
การจัดการรีลีส: เผยแพร่ซอฟต์แวร์เวอร์ชันใหม่
สรุป
การจัดการคอนฟิกช่วยให้มั่นใจว่าการพัฒนาซอฟต์แวร์มีประสิทธิภาพและราบรื่น
เครื่องมือจัดการคอนฟิกช่วยให้ติดตามการเปลี่ยนแปลง ค้นหาสาเหตุของปัญหา และย้อนกลับไปยังเวอร์ชันที่ทำงานได้
ประเด็นสำคัญ:
การจัดการคอนฟิกมีความสำคัญสำหรับการพัฒนาซอฟต์แวร์ที่มีหลายคน
เครื่องมือจัดการคอนฟิกช่วยให้การพัฒนาซอฟต์แวร์มีประสิทธิภาพ
Host-target development
รูปแบบการพัฒนา:
ซอฟต์แวร์ถูกพัฒนาบนเครื่องหนึ่ง (โฮสต์)
ทำงานบนอีกเครื่องหนึ่ง (ทาร์เก็ต)
แพลตฟอร์ม:
รวมถึงระบบปฏิบัติการและซอฟต์แวร์สนับสนุน
ไม่ได้หมายถึงแค่ฮาร์ดแวร์
ตัวอย่าง:
ระบบฝังตัว
ระบบมือถือ
เครื่องมือ
คอมไพเลอร์แบบบูรณาการ
ระบบแก้ไขโค้ด
เครื่องมือดีบักภาษา
เครื่องมือทดสอบ
เครื่องมือจัดการการกำหนดค่า
สภาพแวดล้อมการพัฒนาแบบบูรณาการ (IDE):
ชุดเครื่องมือซอฟต์แวร์
สนับสนุนด้านต่างๆ ของการพัฒนาซอฟต์แวร์
ตัวอย่าง: Eclipse
ระบบฝังตัว:
พิจารณาคุณสมบัติของเป้าหมาย
ขนาดทางกายภาพ
ความสามารถในการจ่ายไฟ
ความต้องการแบบเรียลไทม์
ประเด็นสำคัญ:
การพัฒนาแบบโฮสต์-ทาร์เก็ตเป็นรูปแบบทั่วไป
เครื่องมือและ IDE ช่วยให้พัฒนาซอฟต์แวร์มีประสิทธิภาพ
การเลือกแพลตฟอร์มทาร์เก็ตเป็นสิ่งสำคัญ
สรุป:
รูปแบบการพัฒนาแบบโฮสต์-ทาร์เก็ตช่วยให้พัฒนาซอฟต์แวร์บนแพลตฟอร์มหนึ่งและใช้งานบนอีกแพลตฟอร์มหนึ่ง
เครื่องมือและ IDE ต่างๆ ช่วยให้การพัฒนาซอฟต์แวร์มีประสิทธิภาพ
การเลือกแพลตฟอร์มทาร์เก็ตต้องพิจารณาจากข้อกำหนดด้านฮาร์ดแวร์ ซอฟต์แวร์ ความพร้อมใช้งาน และการสื่อสาร
Open-source development
แนวทาง:
เผยแพร่โค้ดต้นฉบับ
เชิญชวนอาสาสมัครมาร่วมพัฒนา
หลักการ:
โค้ดต้นฉบับไม่ควรเป็นกรรมสิทธิ์
ผู้ใช้สามารถตรวจสอบและปรับเปลี่ยนได้
ผู้ร่วมพัฒนา:
รายงานและแก้ไขข้อบกพร่อง
เสนอคุณสมบัติใหม่
ข้อดี:
ราคาถูกหรือฟรี
น่าเชื่อถือสูง
แก้ไขข้อผิดพลาดได้เร็ว
ข้อดีของการใช้คอมโพเนนต์โอเพ่นซอร์ส:
ประหยัดเวลา
ลดต้นทุน
ข้อเสีย:
อาจไม่ตรงกับชุดข้อกำหนดเฉพาะ
ผสานรวมกับระบบอื่นยาก
สรุป:
การพัฒนาแบบโอเพ่นซอร์สเป็นแนวทางที่ได้รับความนิยม
มีข้อดีและข้อเสียที่ต้องพิจารณา
เหมาะสำหรับการพัฒนาซอฟต์แวร์บางประเภท
ประเด็นสำคัญ:
โมเดลการพัฒนาแบบโอเพ่นซอร์สช่วยให้ผู้ใช้สามารถเข้าถึงโค้ดต้นฉบับและมีส่วนร่วมในการพัฒนา
ซอฟต์แวร์โอเพ่นซอร์สมีราคาถูกหรือฟรี และมักจะน่าเชื่อถือสูง
การตัดสินใจว่าจะใช้คอมโพเนนต์โอเพ่นซอร์สหรือไม่นั้นขึ้นอยู่กับประเภทของซอฟต์แวร์และประสบการณ์ของทีมพัฒนา
Open-source licensing
ใบอนุญาตโอเพนซอร์สส่วนใหญ่ (Chapman 2010) เป็นรูปแบบหนึ่งของสามโมเดลทั่วไป:
GNU General Public License (GPL): ใบอนุญาตแบบต่างตอบแทน ซึ่งหมายความว่าหากคุณใช้ซอฟต์แวร์โอเพนซอร์สที่ออกภายใต้ใบอนุญาต GPL คุณต้องทำให้ซอฟต์แวร์นั้นเป็นโอเพนซอร์สด้วย
GNU Lesser General Public License (LGPL): รูปแบบหนึ่งของใบอนุญาต GPL ซึ่งคุณสามารถเขียนส่วนประกอบที่เชื่อมโยงกับโค้ดโอเพนซอร์สได้โดยไม่ต้องเผยแพร่ซอร์สโค้ดของส่วนประกอบเหล่านี้ อย่างไรก็ตาม หากคุณเปลี่ยนแปลงส่วนประกอบที่มีลิขสิทธิ์ คุณต้องเผยแพร่สิ่งนี้เป็นโอเพนซอร์ส
Berkley Standard Distribution (BSD) License: ใบอนุญาตที่ไม่ต่างตอบแทน ซึ่งหมายความว่าคุณไม่จำเป็นต้องเผยแพร่การเปลี่ยนแปลงหรือการแก้ไขใด ๆ ที่ทำกับโค้ดโอเพนซอร์สซ้ำ คุณสามารถรวมโค้ดไว้ในระบบที่เป็นกรรมสิทธิ์ซึ่งขายได้ หากคุณใช้ส่วนประกอบโอเพนซอร์ส คุณต้องรับทราบผู้สร้างโค้ดดั้งเดิม ใบอนุญาต MIT เป็นรูปแบบหนึ่งของใบอนุญาต BSD ที่มีเงื่อนไขคล้ายคลึงกัน
Bayersdorfer (Bayersdorfer 2007) เสนอแนะว่า บริษัทที่จัดการโครงการที่ใช้โอเพ่นซอร์สควร:
สร้างระบบ สำหรับเก็บรักษาข้อมูลเกี่ยวกับส่วนประกอบโอเพ่นซอร์สที่ดาวน์โหลดและนำมาใช้ โดยต้องเก็บสำเนาของสิทธิการใช้งานสำหรับแต่ละส่วนประกอบ ณ เวลาที่นำมาใช้ เพราะสิทธิการใช้งานอาจเปลี่ยนแปลงได้
ทราบถึงประเภทของสิทธิการใช้งานที่แตกต่างกัน และทำความเข้าใจเกี่ยวกับสิทธิการใช้งานของส่วนประกอบก่อนนำมาใช้ คุณอาจตัดสินใจใช้ส่วนประกอบในระบบหนึ่ง แต่ไม่ใช้ในระบบอื่น เนื่องจากวางแผนใช้งานระบบเหล่านั้นในรูปแบบที่แตกต่างกัน
ตระหนักถึงแนวทางการพัฒนา ของส่วนประกอบ คุณจำเป็นต้องรู้คร่าวๆ เกี่ยวกับโครงการโอเพ่นซอร์สที่พัฒนาส่วนประกอบเหล่านั้น เพื่อประเมินแนวโน้มการเปลี่ยนแปลงในอนาคต
ให้ความรู้เกี่ยวกับโอเพ่นซอร์ส แก่บุคลากร การมีขั้นตอนปฏิบัติเพื่อให้แน่ใจว่าปฏิบัติตามเงื่อนไขสิทธิการใช้งานนั้นไม่เพียงพอ คุณยังต้องให้ความรู้แก่โปรแกรมเมอร์เกี่ยวกับโอเพ่นซอร์สและสิทธิการใช้งานโอเพ่นซอร์สด้วย
มีระบบการตรวจสอบ โปรแกรมเมอร์ที่ทำงานภายใต้ระยะเวลาที่จำกัดอาจเผลอละเมิดเงื่อนไขสิทธิการใช้งาน หากเป็นไปได้ คุณควรมีซอฟต์แวร์เพื่อตรวจจับและป้องกันปัญหานี้
มีส่วนร่วมในชุมชนโอเพ่นซอร์ส หากคุณพึ่งพาผลิตภัณฑ์โอเพ่นซอร์ส คุณควรมีส่วนร่วมในชุมชนและช่วยสนับสนุนการพัฒนา
Software Testing
บทนำ
การทดสอบซอฟต์แวร์ มีจุดประสงค์เพื่อ:
แสดงให้ผู้พัฒนาและลูกค้าเห็นว่าซอฟต์แวร์ทำงานตรงตามความต้องการ
ค้นหาอินพุตหรือลำดับอินพุตที่พฤติกรรมของซอฟต์แวร์ไม่ถูกต้อง ไม่พึงประสงค์ หรือไม่ตรงตามข้อกำหนด
ประเภทของการทดสอบซอฟต์แวร์:
การทดสอบการตรวจสอบ (Validation Testing): ทดสอบเพื่อให้แน่ใจว่าระบบทำงานถูกต้องตามที่คาดหวัง
การทดสอบข้อบกพร่อง (Defect Testing): ทดสอบเพื่อค้นหาข้อบกพร่องในระบบ
กระบวนการตรวจสอบและยืนยัน (Verification & Validation - V & V):
Verification: ตรวจสอบว่าซอฟต์แวร์ตอบสนองต่อความต้องการด้านฟังก์ชันและไม่ใช่ฟังก์ชันที่ระบุไว้
Validation: ตรวจสอบว่าซอฟต์แวร์ตอบสนองความคาดหวังของลูกค้า
เทคนิค V&V:
การทดสอบซอฟต์แวร์
การตรวจตราอย่างละเอียด (Inspections)
ทบทวนซอฟต์แวร์ (Reviews)
ข้อดีของการตรวจตราอย่างละเอียด (Inspections) เหนือการทดสอบ (Testing):
ค้นหาข้อผิดพลาดได้มากกว่า
ตรวจสอบเวอร์ชันที่ไม่สมบูรณ์ของระบบได้
พิจารณาคุณลักษณะด้านคุณภาพที่กว้างขึ้น
Development testing
บทนำ
ผู้ทดสอบ :
โปรแกรมเมอร์
คู่โปรแกรมเมอร์/ผู้ทดสอบ
กลุ่มการทดสอบแยกต่างหาก
ขั้นตอนหลัก:
การทดสอบยูนิต (Unit testing): ทดสอบหน่วยโปรแกรมหรือคลาสวัตถุทีละส่วน เน้นประสิทธิภาพการทำงาน
การทดสอบส่วนประกอบ (Component testing): ทดสอบการทำงานของส่วนต่อประสานระหว่างส่วนประกอบ
การทดสอบระบบ (System testing): ทดสอบการโต้ตอบระหว่างส่วนประกอบต่างๆ รวมถึงการทำงานของระบบโดยรวม
หัวใจสำคัญ:
ค้นหาข้อบกพร่อง (defect) ในซอฟต์แวร์
ทำงานควบคู่ไปกับการดีบัก (debugging) : ระบุปัญหาในโค้ดและแก้ไขโปรแกรม
การทดสอบระหว่างพัฒนา หมายถึง กิจกรรมการทดสอบทั้งหมดที่ดำเนินการโดยทีมพัฒนาระหว่างการพัฒนาซอฟต์แวร์
Unit testing
ความหมาย:
กระบวนการทดสอบส่วนประกอบของโปรแกรม เช่น เมธอดหรือคลาสวัตถุ
ทดสอบการทำงานของส่วนประกอบเหล่านี้โดยแยกออกจากส่วนอื่น ๆ ของโปรแกรม
เป้าหมาย:
ค้นหาข้อบกพร่องในหน่วยย่อยของโปรแกรม
ตรวจสอบว่าหน่วยย่อยทำงานตามที่คาดหวัง
ขั้นตอน:
ออกแบบกรณีทดสอบ:
กำหนดกรณีทดสอบสำหรับแต่ละเมธอดหรือฟังก์ชัน
พิจารณากรณีทดสอบสำหรับค่าอินพุตที่หลากหลาย
ทดสอบการทำงานของส่วนต่อประสานระหว่างหน่วยย่อย
ทดสอบ:
ทดสอบเมธอดแยกจากกัน
ทดสอบลำดับการทำงานที่จำเป็น
ทดสอบสถานะต่างๆ ของวัตถุ
ตรวจสอบผลลัพธ์:
เปรียบเทียบผลลัพธ์กับผลลัพธ์ที่คาดหวัง
วิเคราะห์สาเหตุของความผิดพลาด
ข้อดีของการทดสอบหน่วยย่อยแบบอัตโนมัติ:
รันการทดสอบได้รวดเร็ว
ตรวจสอบการเปลี่ยนแปลงของโปรแกรมได้ง่าย
ค้นหาข้อบกพร่องได้เร็วขึ้น
ข้อจำกัด:
ไม่สามารถทดสอบการทำงานกับระบบภายนอกได้
ไม่สามารถทดสอบการทำงานร่วมกันของหน่วยย่อยต่างๆ ได้
การทดสอบหน่วยย่อยเป็นวิธีที่มีประสิทธิภาพในการค้นหาข้อบกพร่องในโปรแกรม ช่วยให้มั่นใจว่าหน่วยย่อยทำงานตามที่คาดหวัง การทดสอบหน่วยย่อยแบบอัตโนมัติช่วยเพิ่มประสิทธิภาพและความแม่นยำของการทดสอบ
Choosing unit test cases
สองกลยุทธ์ที่มีประสิทธิภาพในการช่วยคุณเลือกกรณีทดสอบคือ:
การทดสอบตามแนวทาง (Guideline-based testing) โดยคุณใช้แนวทางการทดสอบเพื่อเลือกกรณีทดสอบ แนวทางเหล่านี้สะท้อนประสบการณ์ก่อนหน้านี้เกี่ยวกับข้อผิดพลาดประเภทที่ผู้พัฒนาโปรแกรมมักทำเมื่อพัฒนาส่วนประกอบ
การแบ่งพาร์ติชัน (Partition testing) โดยคุณระบุกลุ่มอินพุตที่มีลักษณะร่วมกันและควรได้รับการประมวลผลในลักษณะเดียวกัน คุณควรเลือกการทดสอบจากภายในกลุ่มเหล่านี้แต่ละกลุ่ม
ต้องเลือกกรณีทดสอบหน่วยย่อยที่มีประสิทธิภาพ
หากมีข้อบกพร่องในส่วนประกอบ กรณีทดสอบควรเปิดเผยข้อบกพร่องเหล่านั้น
กรณีทดสอบควรแสดงว่า เมื่อใช้ตามที่คาดหวัง ส่วนประกอบที่คุณกำลังทดสอบจะทำงานตามที่ควรจะเป็น
ควรออกแบบกรณีทดสอบสองประเภท
ส่วนกรณีทดสอบประเภทที่สองควรขึ้นอยู่กับประสบการณ์การทดสอบที่พบปัญหาทั่วไป ควรใช้ข้อมูลอินพุตที่ผิดปกติเพื่อตรวจสอบว่าข้อมูลเหล่านั้นได้รับการประมวลผลอย่างถูกต้องและไม่ทำให้ส่วนประกอบล่ม
ประเภทแรกควรสะท้อนการทำงานปกติของโปรแกรมและควรแสดงว่าส่วนประกอบทำงานได้ ตัวอย่างเช่น หากคุณกำลังทดสอบส่วนประกอบที่สร้างและเตรียมการบันทึกข้อมูลผู้ป่วยใหม่ กรณีทดสอบของคุณควรแสดงว่าบันทึกข้อมูลนั้นมีอยู่จริงในฐานข้อมูลและฟิลด์ต่าง ๆ ได้รับการตั้งค่าตามที่กำหนด
แนวทางที่จะช่วยเผยข้อบกพร่องได้แก่
ทดสอบซอฟต์แวร์ด้วยลำดับที่มีเพียงค่าเดียว โดยธรรมชาติแล้ว โปรแกรมเมอร์คิดว่าลำดับประกอบด้วยค่าหลายค่า และบางครั้งพวกเขาฝังสมมติฐานนี้ไว้ในโปรแกรม ดังนั้น หากพบกับลำดับที่มีค่าเดียว โปรแกรมอาจทำงานไม่ถูกต้อง
ใช้ลำดับที่แตกต่างกันหลายขนาดในการทดสอบที่แตกต่างกัน วิธีนี้จะลดโอกาสที่โปรแกรมที่มีข้อบกพร่องจะสร้างผลลัพธ์ที่ถูกต้องโดยบังเอิญเนื่องจากลักษณะบางอย่างของอินพุตโดยบังเอิญ
ออกแบบการทดสอบเพื่อให้เข้าถึงองค์ประกอบแรก กลาง และสุดท้ายของลำดับ วิธีการนี้อธิบายปัญหาที่ขอบเขตของพาร์ติชัน
ตัวอย่างเพิ่มเติมของแนวทางการทดสอบสำหรับลำดับ:
ทดสอบลำดับที่มีค่าซ้ำกัน
ทดสอบลำดับที่ประกอบด้วยค่าที่เป็นศูนย์หรือค่าพิเศษอื่นๆ
ทดสอบลำดับที่ยาวเกินความยาวที่กำหนด
ทดสอบลำดับที่มีค่าที่เป็นลบ (สำหรับลำดับที่ควรประกอบด้วยค่าไม่ติดลบ)
ทดสอบลำดับที่มีค่าที่ไม่ใช่ตัวเลข (สำหรับลำดับที่ควรประกอบด้วยตัวเลข)
ทดสอบลำดับว่าง
Component testing
ประเด็นสำคัญ:
การทดสอบส่วนประกอบเน้นไปที่การทดสอบอินเทอร์เฟซของส่วนประกอบ
อินเทอร์เฟซของส่วนประกอบมีหลายประเภท:
อินเทอร์เฟซพารามิเตอร์
อินเทอร์เฟซหน่วยความจำที่ใช้ร่วมกัน
อินเทอร์เฟซแบบโพรซีเดอร์
อินเทอร์เฟซการส่งผ่านข้อความ
ข้อผิดพลาดของอินเทอร์เฟซมี 3 ประเภท:
การใช้ผิดพลาด
เข้าใจผิดพลาด
ไทม์มิ่งผิดพลาด
การทดสอบหาข้อบกพร่องของอินเทอร์เฟซมีความยากลำบาก:
ปัญหาอาจปรากฏให้เห็นเฉพาะภายใต้เงื่อนไขที่ไม่ปกติ
ปัญหาอาจเกิดจากปฏิกิริยาระหว่างข้อบกพร่องในโมดูลต่างๆ
แนวทางสำคัญในการทดสอบหาข้อบกพร่องของอินเทอร์เฟซ:
ออกแบบชุดการทดสอบที่ครอบคลุมสถานการณ์ต่างๆ
ตรวจสอบการโต้ตอบระหว่างวัตถุหรือโมดูลต่างๆ
ให้ความสำคัญกับขอบเขตของอินเทอร์เฟซ
ใช้เทคนิคการทดสอบที่เหมาะสม
ออกแบบอินเทอร์เฟซที่ชัดเจนและรัดกุม
แนวทางทั่วไปสำหรับการทดสอบอินเทอร์เฟซ:
ตรวจสอบโค้ดอย่างละเอียด
ทดสอบด้วย null pointer
จงใจทำให้ส่วนประกอบล้มเหลว
ใช้ stress testing ในระบบส่งข้อความ
สลับลำดับการเรียกใช้งาน
ใช้การตรวจสอบและทบทวน
สรุป:
การทดสอบอินเทอร์เฟซเป็นกระบวนการสำคัญที่ต้องอาศัยการวางแผนอย่างรอบคอบ
การใช้เทคนิคการทดสอบที่เหมาะสมจะช่วยเพิ่มโอกาสในการค้นหาข้อบกพร่องของอินเทอร์เฟซ
การแก้ไขข้อบกพร่องของอินเทอร์เฟซตั้งแต่เนิ่นๆ จะช่วยป้องกันปัญหาร้ายแรงที่อาจเกิดขึ้นในระบบที่ซับซ้อน
System testing
ประเด็นสำคัญ:
การทดสอบระบบมุ่งเน้นไปที่การทดสอบการโต้ตอบระหว่างส่วนประกอบและอ็อบเจ็กต์
ระบบทั้งหมดมีพฤติกรรมที่เกิดขึ้นใหม่ ซึ่งอาจเป็นไปตามแผนหรือไม่ได้วางแผน
การทดสอบตามกรณีการใช้งานเป็นวิธีที่มีประสิทธิภาพในการทดสอบระบบ
ไดอะแกรมลำดับช่วยในการออกแบบชุดทดสอบ
การทดสอบระบบแบบละเอียดนั้นทำไม่ได้จริง จำเป็นต้องมีนโยบายสำหรับการเลือกชุดย่อยของกรณีทดสอบ
การทดสอบระบบอัตโนมัติยากกว่าการทดสอบยูนิตหรือส่วนประกอบอัตโนมัติ
รายละเอียดเพิ่มเติม:
การทดสอบระบบช่วยให้มั่นใจว่าส่วนประกอบเข้ากันได้ ทำงานร่วมกันอย่างถูกต้อง และถ่ายโอนข้อมูลที่ถูกต้อง
การทดสอบระบบจะรวมส่วนประกอบที่นำกลับมาใช้ใหม่ ระบบสำเร็จรูป และส่วนประกอบที่พัฒนาใหม่
การทดสอบระบบเป็นกระบวนการร่วมกันมากกว่าเป็นกระบวนการเฉพาะบุคคล
พฤติกรรมที่เกิดขึ้นใหม่ของระบบอาจเป็นไปตามแผนหรือไม่ได้วางแผน
การทดสอบระบบ ควรเน้นไปที่การทดสอบการโต้ตอบระหว่างส่วนประกอบ
การทดสอบตามกรณีการใช้งานเป็นวิธีที่มีประสิทธิภาพในการทดสอบระบบ
ไดอะแกรมลำดับช่วยในการระบุการดำเนินการที่จะได้รับการทดสอบและออกแบบชุดทดสอบ
นโยบายการทดสอบควรระบุชุดย่อยของกรณีทดสอบที่จะใช้
การทดสอบระบบอัตโนมัติยากกว่าการทดสอบยูนิตหรือส่วนประกอบอัตโนมัติ
การทดสอบระบบเป็นขั้นตอนสำคัญในการพัฒนาซอฟต์แวร์ การทดสอบระบบช่วยให้มั่นใจว่าซอฟต์แวร์ทำงานตามที่คาดหวังและตอบสนองความต้องการของผู้ใช้ การทดสอบระบบควรเน้นไปที่การทดสอบการโต้ตอบระหว่างส่วนประกอบและใช้กรณีการใช้งานและไดอะแกรมลำดับเพื่อช่วยในการออกแบบชุดทดสอบ นโยบายการทดสอบควรระบุชุดย่อยของกรณีทดสอบที่จะใช้
Test-driven development
ประเด็นสำคัญ:
TDD เป็นแนวทางการพัฒนาโปรแกรมที่แทรกการทดสอบและการพัฒนาโค้ดเข้าด้วยกัน
กระบวนการ TDD พื้นฐาน:
ระบุส่วนเพิ่มของฟังก์ชัน
เขียนการทดสอบสำหรับฟังก์ชัน
รันการทดสอบ
ใช้งานฟังก์ชัน
รันการทดสอบอีกครั้ง
ไปต่อกับฟังก์ชันอื่นๆ
ประโยชน์ของ TDD:
ทำความเข้าใจปัญหาได้ดีขึ้น
ครอบคลุมโค้ด
การทดสอบย้อนกลับ
การดีบักที่ง่ายขึ้น
เอกสารระบบ
TDD ลดต้นทุนของการทดสอบย้อนกลับ
ข้อจำกัดของ TDD:
ไม่เหมาะกับการประยุกต์ใช้ซ้ำส่วนประกอบโค้ดขนาดใหญ่หรือระบบเก่า
ไม่เหมาะกับระบบมัลติเธรด
ยังคงต้องมีการทดสอบระบบ
ผลการวิจัยยังไม่ชัดเจน
รายละเอียดเพิ่มเติม:
TDD มักใช้ในกระบวนการแบบ Agile อย่าง XP
สภาพแวดล้อมการทดสอบอัตโนมัติ เช่น JUnit จำเป็นสำหรับ TDD
การทดสอบ TDD ควรมีขนาดเล็กและสามารถใช้งานได้
TDD ช่วยให้มั่นใจได้ว่าโค้ดทั้งหมดในระบบได้รับการเรียกใช้จริง
TDD ทำให้การค้นพบข้อบกพร่องเร็วขึ้น
การทดสอบ TDD เองทำหน้าที่เป็นเอกสาร
Release testing
บทนำ
ประเด็นสำคัญ:
การทดสอบการเผยแพร่คือการทดสอบระบบรุ่นใดรุ่นหนึ่งเพื่อใช้งานนอกเหนือจากทีมพัฒนา
มีสองข้อแตกต่างที่สำคัญระหว่างการทดสอบการเผยแพร่และการทดสอบระบบระหว่างกระบวนการพัฒนา:
ทีมพัฒนาไม่ควรรับผิดชอบการทดสอบการเผยแพร่
การทดสอบการเผยแพร่เน้นไปที่การตรวจสอบว่าระบบตรงตามข้อกำหนดและเหมาะสมกับการใช้งานของลูกค้า
เป้าหมายหลักของการทดสอบการเผยแพร่:
ให้ผู้จัดหาเชื่อมั่นว่าระบบนั้นเหมาะสมกับการใช้งาน
แสดงให้เห็นว่าระบบส่งมอบฟังก์ชันการทำงาน ประสิทธิภาพ และความน่าเชื่อถือตามที่กำหนด
การทดสอบการเผยแพร่เป็นการทดสอบแบบ "black-box" เน้นไปที่ฟังก์ชันการทำงาน
รายละเอียดเพิ่มเติม:
การทดสอบการเผยแพร่มักเกี่ยวข้องกับลูกค้า ผู้ใช้ หรือทีมพัฒนาอื่นๆ
การทดสอบการเผยแพร่ควรตรวจสอบว่าระบบ:
ตรงตามข้อกำหนด
ทำงานได้ตามที่คาดหวัง
มีประสิทธิภาพและความน่าเชื่อถือ
ไม่ล้มเหลวระหว่างการใช้งานตามปกติ
การทดสอบการเผยแพร่มักใช้การทดสอบแบบ "black-box"
ชื่ออื่นสำหรับการทดสอบการเผยแพร่คือการทดสอบฟังก์ชันการทำงาน
Requirements-based testing
ประเด็นสำคัญ:
การทดสอบตามความต้องการเป็นวิธีการทดสอบระบบโดยพิจารณาจากความต้องการของระบบ
เป้าหมายหลักของการทดสอบตามความต้องการคือเพื่อตรวจสอบว่าระบบได้นำความต้องการไปใช้จริงอย่างถูกต้อง
การทดสอบตามความต้องการ เป็นการตรวจสอบคุณภาพมากกว่าการทดสอบหาข้อบกพร่อง
คุณต้องเขียนการทดสอบหลายชุดเพื่อให้แน่ใจว่าคุณครอบคลุมความต้องการ
รายละเอียดเพิ่มเติม:
หลักการสำคัญของการเขียนความต้องการที่ดีคือ ความต้องการควรทดสอบได้
การทดสอบตามความต้องการช่วยให้มั่นใจได้ว่าระบบ:
ตรงตามความต้องการของผู้ใช้
ทำงานได้ตามที่คาดหวัง
มีความปลอดภัยและเชื่อถือได้
Scenario testing
ประเด็นสำคัญ:
การทดสอบแบบสถานการณ์เป็นวิธีการทดสอบระบบโดยใช้สถานการณ์จำลองการใช้งาน
สถานการณ์ควรมีความสมจริงและผู้ใช้ระบบจริงสามารถเชื่อมโยงกับสถานการณ์เหล่านั้นได้
การทดสอบแบบสถานการณ์ควรทดสอบข้อกำหนดหลายข้อภายในสถานการณ์เดียวกัน
ประโยชน์ของการทดสอบแบบสถานการณ์:
ค้นพบปัญหาที่อาจเกิดขึ้นซึ่งอาจ overlooked ในการทดสอบแบบอื่น
ตรวจสอบว่าระบบทำงานได้อย่างถูกต้องในสถานการณ์การใช้งานจริง
ช่วยให้ผู้มีส่วนได้ส่วนเสียเข้าใจระบบและข้อกำหนด
Performance testing
รายละเอียดเพิ่มเติม:
การทดสอบประสิทธิภาพมักทำหลังจากรวมระบบ
การทดสอบประสิทธิภาพวัด:
เวลาตอบสนอง
อัตราการส่งออก
การใช้ทรัพยากร
การทดสอบประสิทธิภาพใช้วิธีการต่างๆ เช่น:
การทดสอบโหลด
การทดสอบความเครียด
การทดสอบการแย่งชิง
การทดสอบความเครียดเน้นระบบด้วย:
โหลดสูง
ข้อมูลอินพุตที่ไม่ถูกต้อง
สถานการณ์ที่ไม่คาดคิด
การทดสอบความเครียดช่วยให้ค้นพบ:
ขีดจำกัดของระบบ
พฤติกรรมความล้มเหลว
ข้อบกพร่องที่ปรากฏขึ้นเฉพาะเมื่อระบบเต็มโหลด
ประเด็นสำคัญ:
ทดสอบพฤติกรรมความล้มเหลวของระบบ
เปิดเผยข้อบกพร่องที่ปรากฏขึ้นเฉพาะเมื่อระบบเต็มโหลด
การทดสอบความเครียดคือการเน้นระบบโดยการเรียกร้องที่อยู่นอกเหนือขีดจำกัดการออกแบบ
โปรไฟล์การทำงานคือชุดการทดสอบที่สะท้อนถึงการผสมผสานงานจริง
การทดสอบประสิทธิภาพเกี่ยวข้องกับ:
ค้นหาปัญหาและข้อบกพร่อง
แสดงให้เห็นว่าระบบตรงตามความต้องการ
การทดสอบประสิทธิภาพคือการตรวจสอบว่าระบบสามารถประมวลผลโหลดที่ต้องการได้
User testing
ประเด็นสำคัญ:
การทดสอบโดยผู้ใช้เป็นขั้นตอนสำคัญในการพัฒนาซอฟต์แวร์
มีการทดสอบโดยผู้ใช้สามประเภท:
การทดสอบ Alpha
การทดสอบ Beta
การทดสอบการยอมรับ
การทดสอบ Alpha:
ผู้ใช้และผู้พัฒนาร่วมมือกันทดสอบระบบ
ผู้ใช้สามารถระบุปัญหาที่ทีมทดสอบของผู้พัฒนาอาจมองไม่เห็น
เหมาะสำหรับการพัฒนาผลิตภัณฑ์ซอฟต์แวร์หรือแอป
การทดสอบ Beta:
ซอฟต์แวร์รุ่นเบื้องต้นเผยแพร่ให้กับลูกค้าและผู้ใช้กลุ่มใหญ่
ค้นหาปัญหาการโต้ตอบระหว่างซอฟต์แวร์กับสภาพแวดล้อมการใช้งาน
เป็นรูปแบบหนึ่งของการตลาด
การทดสอบการยอมรับ:
ลูกค้าทดสอบระบบโดยใช้ข้อมูลของตนเอง
ตัดสินใจว่าจะยอมรับระบบจากผู้พัฒนาหรือไม่
มีหกขั้นตอน:
กำหนดเกณฑ์การยอมรับ
วางแผนการทดสอบการยอมรับ
ออกแบบเคสทดสอบการยอมรับ
ดำเนินการทดสอบการยอมรับ
เจรจาผลการทดสอบ
ยอมรับ/ปฏิเสธระบบ
ปัญหา:
ยากที่จะสร้างเกณฑ์การยอมรับที่เป็นกลาง
กระบวนการทดสอบอาจไม่สะท้อนถึงวิธีการใช้งานระบบจริง
การทดสอบแบบอัตโนมัติจำกัดความยืดหยุ่น
รายละเอียดเพิ่มเติม:
การทดสอบโดยผู้ใช้ช่วยให้มั่นใจว่า:
ระบบใช้งานง่าย
ตรงตามความต้องการของผู้ใช้
ทำงานได้อย่างถูกต้องในสภาพแวดล้อมการทำงานจริง
การทดสอบโดยผู้ใช้มีรูปแบบต่างๆ:
การทดสอบแบบใช้ผู้ใช้จริง
การทดสอบการใช้งาน
การทดสอบ A/B
การทดสอบ Alpha มักใช้กับ:
ซอฟต์แวร์ที่มีความซับซ้อนสูง
ซอฟต์แวร์ที่มีความเสี่ยงสูง
ซอฟต์แวร์ที่ต้องใช้งานกับฮาร์ดแวร์พิเศษ
การทดสอบ Beta มักใช้กับ:
ซอฟต์แวร์ที่มีผู้ใช้จำนวนมาก
ซอฟต์แวร์ที่ต้องใช้งานกับระบบอื่น
ซอฟต์แวร์ที่ต้องใช้งานกับข้อมูลที่ละเอียดอ่อน
การทดสอบการยอมรับเป็นขั้นตอนสำคัญใน:
การพัฒนาซอฟต์แวร์แบบคัสตอม
การพัฒนาซอฟต์แวร์ที่มีภาระผูกพันทางสัญญา
การพัฒนาซอฟต์แวร์ที่มีความเสี่ยงสูง
ปัญหาการทดสอบโดยผู้ใช้:
หาผู้ใช้ที่เหมาะสม
จัดการความคาดหวังของผู้ใช้
เก็บรวบรวมข้อมูลอย่างมีประสิทธิภาพ
Software evolution
บทนำ
ซอฟต์แวร์ระบบใหญ่มีอายุการใช้งานยาวนาน: ระบบเหล่านี้มักมีการใช้งาน 10 ปีขึ้นไปสำหรับระบบธุรกิจ และ 30 ปีขึ้นไปสำหรับระบบทางทหารหรือโครงสร้างพื้นฐาน
ซอฟต์แวร์ต้องมีการเปลี่ยนแปลง: การเปลี่ยนแปลงทางธุรกิจ ความคาดหวังของผู้ใช้ ฮาร์ดแวร์ และแพลตฟอร์มซอฟต์แวร์ ล้วนเป็นปัจจัยที่ทำให้ต้องปรับเปลี่ยนซอฟต์แวร์
วิวัฒนาการของซอฟต์แวร์มีค่าใช้จ่าย: โดยเฉพาะในระบบองค์กร การเปลี่ยนแปลงระบบหนึ่งอาจส่งผลต่อระบบอื่นๆ ในสภาพแวดล้อมนั้น
การพัฒนาซอฟต์แวร์เป็นกระบวนการแบบเกลียว: มีการทำความต้องการ ออกแบบ พัฒนา และทดสอบ ตลอดอายุการใช้งานของระบบ
การเปลี่ยนผ่านจากการพัฒนาไปสู่การปรับเปลี่ยน:
กรณีบริษัทเดียวกันรับผิดชอบซอฟต์แวร์: กระบวนการพัฒนาต่อเนื่อง
กรณีใช้ซอฟต์แวร์แบบกำหนดเอง:
ลูกค้ารับผิดชอบเอง
ลูกค้าจ้างบริษัทอื่น
กระบวนการอาจไม่ต่อเนื่อง
วัฏจักรชีวิตของการวิวัฒนาการซอฟต์แวร์:
การพัฒนาต่อเนื่อง: มีการเปลี่ยนแปลงโครงสร้างและฟังก์ชันการทำงาน
การบริการบำรุงรักษา: มีการเปลี่ยนแปลงเพียงเล็กน้อย
จุดเปลี่ยนผ่าน:
ซอฟต์แวร์มีการใช้งานสำเร็จ
โครงสร้างซอฟต์แวร์เสื่อมโทรม
การเปลี่ยนแปลงสำคัญมีค่าใช้จ่ายสูง
การบริการบำรุงรักษา:
ปรับเปลี่ยนเล็กน้อย
พิจารณาแทนที่ซอฟต์แวร์
ปลดระวางซอฟต์แวร์:
เปลี่ยนแปลงที่จำเป็นเท่านั้น
โอนย้ายข้อมูลไปยังระบบใหม่
ค่าใช้จ่าย:
การพัฒนาซอฟต์แวร์ใหม่
การโอนย้ายข้อมูล
Evolution processes
การเปลี่ยนแปลงระบบ
ข้อเสนอแนะการเปลี่ยนแปลงระบบเป็นตัวขับเคลื่อนการวิวัฒนาการของระบบ
ข้อเสนอแนะอาจมาจาก:
ความต้องการที่มีอยู่
คำขอสำหรับความต้องการใหม่
รายงานข้อบกพร่อง
แนวคิดใหม่
กระบวนการวิวัฒนาการ
ประกอบด้วยกิจกรรมพื้นฐาน:
การวิเคราะห์การเปลี่ยนแปลง
การวางแผนการเผยแพร่
การใช้งานระบบ
การเผยแพร่ระบบ
วนซ้ำไปเรื่อย ๆ
การพัฒนาและการวิวัฒนาการผสมผสานกัน
นำการเปลี่ยนแปลงไปใช้เป็นเพียงการวนซ้ำของกระบวนการพัฒนา
ความแตกต่าง:
ต้องคำนึงถึงข้อเสนอแนะจากลูกค้าหลังการจัดส่ง
ขั้นตอนแรกคือการทำความเข้าใจโปรแกรม
การเปลี่ยนแปลงเร่งด่วน
เกิดขึ้นจาก:
ข้อบกพร่องร้ายแรง
การเปลี่ยนแปลงสภาพแวดล้อม
การเปลี่ยนแปลงธุรกิจ
อาจทำให้เอกสารประกอบซอฟต์แวร์ไม่ตรงกัน
แนวคิดเอกสารประกอบน้อยที่สุด
ควรปรับปรุงโค้ดใหม่ให้ดีขึ้น
วิธีการแบบ Agile
สามารถใช้สำหรับการวิวัฒนาการของโปรแกรม
ปัญหา:
ทีมพัฒนาและทีมวิวัฒนาการใช้วิธีการต่างกัน
ทีมพัฒนาใช้ Agile แต่ทีมวิวัฒนาการต้องการใช้แผน
ทีมพัฒนาใช้แผน แต่ทีมวิวัฒนาการต้องการใช้ Agile
เทคนิค Agile:
การพัฒนาที่เน้นการทดสอบ
การทดสอบย้อนกลับอัตโนมัติ
user stories
รายการงานค้างที่ต้องทำ (backlog)
การปรับเปลี่ยนวิธีการแบบ Agile
อาจต้องมีการปรับเปลี่ยนเมื่อนำไปใช้กับการบำรุงรักษาและวิวัฒนาการโปรแกรม
สาเหตุ:
การมีส่วนร่วมของผู้ใช้ในทีมพัฒนาอาจเป็นไปไม่ได้
รอบการพัฒนาที่สั้นอาจต้องหยุดชะงัก
ระยะเวลาว่างระหว่างรุ่นอาจต้องขยายออก
Legacy systems
ระบบล้าสมัย
ระบบเก่าที่ใช้ภาษาและเทคโนโลยีล้าสมัย
มักมีค่าใช้จ่ายในการบำรุงรักษาสูง
ยากที่จะเปลี่ยนแปลง
อาจขึ้นอยู่กับฮาร์ดแวร์รุ่นเก่า
กระบวนการทางธุรกิจอาจถูกจำกัดโดยระบบล้าสมัย
องค์ประกอบของระบบล้าสมัย
ฮาร์ดแวร์
ซอฟต์แวร์สนับสนุน
ซอฟต์แวร์แอปพลิเคชัน
ข้อมูลแอปพลิเคชัน
กระบวนการทางธุรกิจ
นโยบายและกฎระเบียบทางธุรกิจ
ลำดับชั้นของระบบล้าสมัย
ฮาร์ดแวร์
ซอฟต์แวร์ระบบ
ซอฟต์แวร์แอปพลิเคชัน
ข้อมูล
ปัญหาของระบบล้าสมัย
ขาดแคลนทักษะ
ช่องโหว่ด้านความปลอดภัย
ยากที่จะเชื่อมต่อกับระบบใหม่
ฮาร์ดแวร์ล้าสมัย
เหตุผลที่ไม่แทนที่ระบบล้าสมัย
มีค่าใช้จ่ายสูง
มีความเสี่ยง
ระบบทำงานได้ดี
กลัวความเสี่ยงของระบบใหม่
เหตุผลที่ค่าใช้จ่ายในการเปลี่ยนระบบล้าสมัยสูง
ไม่มีสเปคที่สมบูรณ์
กระบวนการทางธุรกิจผสานรวมกับระบบ
กฎธุรกิจฝังอยู่ในซอฟต์แวร์
การพัฒนาซอฟต์แวร์ใหม่มีความเสี่ยง
ปัญหาของระบบล้าสมัยที่มีอายุมากกว่าสองสามปี
รูปแบบโปรแกรมและขนบธรรมเนียมการใช้งานไม่สอดคล้องกัน
ภาษาโปรแกรมล้าสมัย
เอกสารประกอบไม่เพียงพอ
โครงสร้างระบบเสื่อมโทรม
ข้อมูลมีโครงสร้างไม่ดี
จุดเปลี่ยน
ค่าใช้จ่ายในการจัดการระบบล้าสมัยสูงเกินไป
จำเป็นต้องแทนที่ด้วยระบบใหม่
แนวทางการตัดสินใจ
วิเคราะห์ระบบล้าสมัย
ประเมินตัวเลือก
เลือกตัวเลือกที่ดีที่สุด
ระบบล้าสมัยเป็นปัญหาสำคัญสำหรับองค์กรต่างๆ ระบบเหล่านี้มีค่าใช้จ่ายในการบำรุงรักษาสูง ยากที่จะเปลี่ยนแปลง และอาจเป็นช่องโหว่ด้านความปลอดภัยได้ มีหลายเหตุผลที่องค์กรไม่แทนที่ระบบล้าสมัย แต่ถึงจุดหนึ่ง ค่าใช้จ่ายในการจัดการระบบล้าสมัยสูงเกินไป และจำเป็นต้องแทนที่ด้วยระบบใหม่ มีแนวทางการตัดสินใจที่มีระบบเพื่อช่วยองค์กรในการตัดสินใจว่าจะแทนที่ระบบล้าสมัยหรือไม่
Legacy system management
ระบบเลกาซี หมายถึง ระบบซอฟต์แวร์เก่าที่พัฒนาโดยใช้เทคโนโลยีแบบเก่า ซึ่งอาจไม่รองรับความต้องการทางธุรกิจปัจจุบันหรือใช้งานได้ยาก
ปัญหา:
ระบบเลกาซีอาจมีประสิทธิภาพต่ำ
ยากต่อการบำรุงรักษา
ไม่รองรับเทคโนโลยีใหม่
เสี่ยงต่อความปลอดภัย
กลยุทธ์:
ยกเลิกระบบ: เหมาะกับระบบที่ไม่มีประโยชน์ต่อธุรกิจ
คงสภาพเดิม: เหมาะกับระบบที่มีเสถียรภาพและใช้งานน้อย
ปรับปรุงระบบ: เหมาะกับระบบที่ต้องการปรับให้เข้ากับเทคโนโลยีใหม่
แทนที่ระบบ: เหมาะกับระบบที่ล้าสมัยหรือมีฮาร์ดแวร์เก่า
วิธีประเมินระบบเลกาซี:
มูลค่าทางธุรกิจ: ระบบช่วยประหยัดเวลาและความพยายามหรือไม่?
คุณภาพทางเทคนิค: ระบบมีความน่าเชื่อถือ ยืดหยุ่น ใช้งานง่าย หรือไม่?
ปัจจัยที่ใช้ในการประเมินสภาพแวดล้อม:
ความมั่นคงของซัพพลายเออร์: ผู้จัดจำหน่ายยังคงดำเนินกิจการอยู่หรือไม่?
อายุฮาร์ดแวร์และซอฟต์แวร์: ฮาร์ดแวร์และซอฟต์แวร์เก่าหรือไม่?
ประสิทธิภาพ: ประสิทธิภาพของระบบเพียงพอหรือไม่?
ค่าใช้จ่ายในการบำรุงรักษา: ค่าใช้จ่ายในการบำรุงรักษาสูงหรือไม่?
ความสามารถในการทำงานร่วมกัน: ระบบสามารถเชื่อมต่อกับระบบอื่นได้หรือไม่?
ปัจจัยที่ใช้ในการประเมินคุณภาพทางเทคนิคของระบบแอปพลิเคชัน:
จำนวนคำขอเปลี่ยนแปลงระบบ: ระบบมีการเปลี่ยนแปลงบ่อยหรือไม่?
จำนวนส่วนติดต่อผู้ใช้: ระบบมีส่วนติดต่อผู้ใช้มากหรือไม่?
ปริมาณข้อมูลที่ระบบใช้: ระบบใช้ข้อมูลมากหรือไม่?
การตัดสินใจ:
ควรใช้การประเมินอย่างมีวัตถุประสงค์
ในบางกรณี การตัดสินใจอาจขึ้นอยู่กับองค์กรหรือข้อพิจารณาทางการเมือง
ข้อควรพิจารณา:
งบประมาณ
ระยะเวลา
ทรัพยากร
Software maintenance
บทนำ
การบำรุงรักษาซอฟต์แวร์ คือ กระบวนการเปลี่ยนแปลงซอฟต์แวร์หลังจากส่งมอบ มี 3 ประเภทหลัก:
การแก้ไขข้อบกพร่อง: แก้ไขจุดบกพร่องและช่องโหว่
การปรับตัวเข้ากับสภาพแวดล้อม: ปรับซอฟต์แวร์ให้เข้ากับแพลตฟอร์มและสภาพแวดล้อมใหม่
การเพิ่มฟังก์ชันการทำงาน: เพิ่มคุณสมบัติใหม่และรองรับความต้องการใหม่
การกระจายตัวของค่าใช้จ่ายในการบำรุงรักษา:
การแก้ไขข้อบกพร่อง: 20%
การปรับตัวเข้ากับสภาพแวดล้อม: 25%
การเพิ่มฟังก์ชันการทำงาน: 55%
ทำไมการเพิ่มฟีเจอร์ใหม่ระหว่างการบำรุงรักษาจึงแพงกว่าช่วงพัฒนา:
ทีมใหม่ต้องทำความเข้าใจโปรแกรม
การแยกการบำรุงรักษาและการพัฒนาไม่มีแรงจูงใจให้เขียนซอฟต์แวร์ที่ดูแลรักษาง่าย
งานบำรุงรักษาโปรแกรมไม่ค่อยน่าดึงดูด
โครงสร้างของโปรแกรมเสื่อมสภาพตามอายุ ทำให้เปลี่ยนแปลงยากขึ้น
ปัญหาของการมองว่าการพัฒนาซอฟต์แวร์และการบำรุงรักษาเป็นคนละเรื่อง:
ไม่มีแรงจูงใจในการลงทุนเงินระหว่างการพัฒนาเพื่อลดต้นทุนการเปลี่ยนแปลงระบบ
การบำรุงรักษามักถูกมองว่าเป็นกิจกรรมรอง
วิธีแก้ปัญหา:
คิดว่าระบบมีการพัฒนาตลอดอายุการใช้งาน ผ่านกระบวนการพัฒนาอย่างต่อเนื่อง
ลงทุนในการออกแบบและใช้งานระบบเพื่อลดต้นทุนการเปลี่ยนแปลงในอนาคต
บูรณาการการพัฒนาและการบำรุงรักษาเข้าด้วยกัน
ข้อควรพิจารณา:
การบำรุงรักษาซอฟต์แวร์เป็นกิจกรรมที่สำคัญและมีค่าใช้จ่ายสูง
การลงทุนในการบำรุงรักษาที่ดีสามารถลดต้นทุนโดยรวมของระบบได้
การบูรณาการการพัฒนาและการบำรุงรักษาสามารถช่วยปรับปรุงคุณภาพของซอฟต์แวร์และลดต้นทุนการบำรุงรักษา
Maintenance prediction
การคาดการณ์การบำรุงรักษา คือ การประเมินการเปลี่ยนแปลงที่อาจเกิดขึ้นในระบบซอฟต์แวร์และระบุส่วนที่มีแนวโน้มว่าจะมีค่าใช้จ่ายในการเปลี่ยนแปลงสูง
ประโยชน์:
ออกแบบคอมโพเนนต์ให้ปรับตัวได้มากขึ้น
ลงทุนในการปรับปรุงคอมโพเนนต์เพื่อลดต้นทุน
ประเมินต้นทุนการบำรุงรักษาทั้งหมด
กำหนดงบประมาณ
ปัจจัยที่มีผลต่อจำนวนคำขอเปลี่ยนแปลง:
จำนวนและความซับซ้อนของอินเตอร์เฟส
ความไม่แน่นอนของข้อกำหนด
กระบวนการทางธุรกิจ
ตัววัดความซับซ้อน:
ขนาดของโปรแกรม
จำนวนฟังก์ชัน
โครงสร้างการควบคุม
ข้อมูลที่ใช้
เมตริกกระบวนการ:
จำนวนคำขอการบำรุงรักษาแบบแก้ไข
เวลาเฉลี่ยที่ใช้สำหรับการวิเคราะห์ผลกระทบ
เวลาเฉลี่ยที่ใช้ในการดำเนินการเปลี่ยนแปลง
จำนวนคำขอเปลี่ยนแปลงที่ยังคงอยู่
การคาดการณ์ต้นทุน:
ผสมผสานข้อมูลการคาดการณ์กับสัญชาตญาณและประสบการณ์
โมเดล COCOMO 2: ประมาณความพยายามในการบำรุงรักษาจากความพยายามในการเข้าใจโค้ดที่มีอยู่และพัฒนาโค้ดใหม่
ข้อควรพิจารณา:
การคาดการณ์การบำรุงรักษาเป็นกระบวนการที่ซับซ้อน
ไม่มีวิธีการที่สมบูรณ์แบบ
ข้อมูลที่มีคุณภาพเป็นกุญแจสำคัญ
การคาดการณ์ช่วยให้ตัดสินใจได้ดีขึ้น
คำถามที่การคาดการณ์สามารถตอบได้:
ส่วนใดของระบบที่มีแนวโน้มว่าจะมีการเปลี่ยนแปลงมากที่สุด
การเปลี่ยนแปลงประเภทใดมีแนวโน้มที่จะเกิดขึ้น
อะไรคือต้นทุนที่คาดว่าจะเกิดขึ้นในการบำรุงรักษา
ทรัพยากรประเภทใดที่จำเป็นสำหรับการบำรุงรักษา
Software reengineering
การรื้อปรับระบบซอฟต์แวร์ คือ การปรับโครงสร้างและทำความเข้าใจระบบเก่าให้เข้าใจและเปลี่ยนแปลงได้ง่ายขึ้น
ข้อดี:
ลดความเสี่ยง: หลีกเลี่ยงความเสี่ยงของการพัฒนาซอฟต์แวร์ใหม่
ลดต้นทุน: ประหยัดกว่าการพัฒนาซอฟต์แวร์ใหม่
กระบวนการ:
แปลรหัสต้นฉบับ
วิศวกรรมย้อนกลับ
ปรับปรุงโครงสร้างโปรแกรม
สร้างโมดูลโปรแกรม
การรื้อปรับข้อมูล
แนวทาง:
แปลรหัสต้นฉบับ
การวิศวกรรมย้อนกลับ
การปรับโครงสร้างโปรแกรม
การรื้อปรับข้อมูล
การย้ายสถาปัตยกรรม
ข้อจำกัด:
ไม่สามารถเปลี่ยนแปลงพื้นฐานได้
ความสามารถในการบำรุงรักษาอาจไม่ดีเท่าระบบใหม่
ข้อควรพิจารณา:
การรื้อปรับระบบซอฟต์แวร์เป็นทางเลือกที่คุ้มค่าสำหรับการแทนที่ระบบเก่า
ตัดสินใจเลือกแนวทางการปรับรื้อระบบที่เหมาะสมกับความต้องการ
พิจารณาข้อจำกัดของการรื้อปรับระบบซอฟต์แวร์
Refactoring
การปรับปรุงรหัส คือ การปรับโครงสร้าง ลดความซับซ้อน หรือทำโปรแกรมให้เข้าใจง่ายขึ้น เพื่อชะลอการเสื่อมสภาพลงเมื่อมีการเปลี่ยนแปลง
จุดประสงค์:
ป้องกันปัญหาระยะยาว
รักษาคุณภาพของโปรแกรม
ลดต้นทุนการบำรุงรักษา
ความแตกต่างระหว่างการปรับปรุงรหัสและการรื้อปรับระบบ:
การปรับปรุงรหัส: ดำเนินการอย่างต่อเนื่องระหว่างการพัฒนา
การรื้อปรับระบบ: ดำเนินการหลังจากระบบใช้งานไประยะหนึ่ง
การปรับปรุงรหัส: เน้นการปรับโครงสร้าง
การรื้อปรับระบบ: เน้นการสร้างระบบใหม่
สถานการณ์ที่เหมาะกับการปรับปรุงรหัส:
รหัสที่ซ้ำกัน
เมธอดที่ยาว
คำสั่ง Switch (case)
การจับกลุ่มข้อมูล
การคาดการณ์ความทั่วไป
การเปลี่ยนแปลงพื้นฐานในการปรับปรุงรหัส:
Extract method
Consolidate conditional expression
Pull up method
ข้อดี:
ลดต้นทุนการบำรุงรักษา
เพิ่มคุณภาพของโปรแกรม
ข้อจำกัด:
ไม่สามารถแก้ไขโครงสร้างที่เสื่อมโทรมอย่างมากได้
อาจต้องพิจารณาการปรับปรุงการออกแบบ
ข้อควรพิจารณา:
การปรับปรุงรหัสเป็นวิธีที่มีประสิทธิภาพในการลดต้นทุนการบำรุงรักษา
ควรดำเนินการปรับปรุงรหัสอย่างต่อเนื่องระหว่างการพัฒนา
การปรับปรุงรหัสอาจไม่เพียงพอสำหรับโปรแกรมที่มีโครงสร้างเสื่อมโทรมอย่างมาก