กระทรวงศึกษาธิการและวิทยาศาสตร์
สาธารณรัฐประชาชนโดเนตสค์
รัฐมืออาชีพ
สถาบันการศึกษา
"วิทยาลัยอุตสาหกรรมและเศรษฐกิจโดเนตสค์"
โปรแกรมการทำงาน
แนวปฏิบัติทางการศึกษา UP.01
โมดูลมืออาชีพ PM.01 การพัฒนาโมดูลซอฟต์แวร์ ซอฟต์แวร์สำหรับ ระบบคอมพิวเตอร์
พิเศษ 09.02.03 "การเขียนโปรแกรมในระบบคอมพิวเตอร์"
รวบรวมโดย:
Volkov Vladimir Aleksandrovich ครูสอนวิชาคอมพิวเตอร์ในหมวดคุณสมบัติ "ผู้เชี่ยวชาญประเภทสูงสุด" สถาบันการศึกษาของรัฐ "วิทยาลัยอุตสาหกรรมและเศรษฐกิจโดเนตสค์"
โปรแกรมได้รับการอนุมัติโดย: Vovk Pavel Andreevich ผู้อำนวยการฝ่าย "Smart IT Service"
| 1. หนังสือเดินทางของโปรแกรมการปฏิบัติ | |
| 2. ผลการปฏิบัติ | |
| 3. โครงสร้างและเนื้อหาของการปฏิบัติ | |
| 4. เงื่อนไขในการจัดและการปฏิบัติ | |
| 5. การติดตามและประเมินผลการปฏิบัติ |
1 หนังสือเดินทางของโครงการฝึกปฏิบัติทางการศึกษา 01
1.1 สถานที่ฝึก UP.01
โปรแกรมการฝึกปฏิบัติทางการศึกษา UP.01 ของโมดูลมืออาชีพ PM.01 "การพัฒนาโมดูลซอฟต์แวร์ซอฟต์แวร์สำหรับระบบคอมพิวเตอร์" พิเศษ 09.02.03 "การเขียนโปรแกรมในระบบคอมพิวเตอร์ » กลุ่มขยาย 09.00.00 "วิทยาการคอมพิวเตอร์และเทคโนโลยีคอมพิวเตอร์" ในแง่ของการเรียนรู้ประเภทหลักของกิจกรรมวิชาชีพ (VPD):
การพัฒนาโมดูลซอฟต์แวร์ซอฟต์แวร์สำหรับระบบคอมพิวเตอร์และความสามารถทางวิชาชีพที่เกี่ยวข้อง (PC):
| ดำเนินการพัฒนาข้อกำหนดสำหรับแต่ละส่วนประกอบ |
|
| ดำเนินการพัฒนาโค้ด ผลิตภัณฑ์ซอฟต์แวร์ตามข้อกำหนดสำเร็จรูปในระดับโมดูล |
|
| ทำการดีบักโมดูลโปรแกรมโดยใช้เครื่องมือซอฟต์แวร์พิเศษ |
|
| ทำการทดสอบโมดูลซอฟต์แวร์ |
|
| ดำเนินการเพิ่มประสิทธิภาพ รหัสโปรแกรมโมดูล. |
|
| พัฒนาองค์ประกอบการออกแบบและเอกสารทางเทคนิคโดยใช้ภาษาข้อกำหนดกราฟิก |
โปรแกรมการฝึกปฏิบัติด้านการศึกษา UP.01 ของโมดูลมืออาชีพ PM.01 "การพัฒนาโมดูลซอฟต์แวร์ซอฟต์แวร์สำหรับระบบคอมพิวเตอร์" สามารถใช้ในการศึกษาวิชาชีพเพิ่มเติมและการฝึกอบรมวิชาชีพของพนักงานสำหรับความเชี่ยวชาญพิเศษ 09.02.03 การเขียนโปรแกรมในระบบคอมพิวเตอร์ด้วยรอง ( สมบูรณ์) หมวดวิชาศึกษาทั่วไป. ไม่จำเป็นต้องมีประสบการณ์การทำงาน
1.2 เป้าหมายและวัตถุประสงค์แนวปฏิบัติทางการศึกษา UP.01
เพื่อให้เชี่ยวชาญในประเภทของกิจกรรมทางวิชาชีพที่ระบุและความสามารถทางวิชาชีพที่เกี่ยวข้อง นักเรียนในหลักสูตรการฝึกปฏิบัติด้านการศึกษา UP.01 จะต้อง:
มีประสบการณ์จริง:
การพัฒนาอัลกอริทึมของงานและการนำไปใช้งานโดยการออกแบบโดยใช้คอมพิวเตอร์ช่วย
การพัฒนารหัสผลิตภัณฑ์ซอฟต์แวร์ตามข้อกำหนดสำเร็จรูปในระดับโมดูล
การใช้เครื่องมือในขั้นตอนการดีบักผลิตภัณฑ์ซอฟต์แวร์
การทดสอบโมดูลซอฟต์แวร์ตามสถานการณ์เฉพาะ
สามารถ:
ดำเนินการพัฒนาโค้ดโมดูลโปรแกรมในภาษาโปรแกรมสมัยใหม่
สร้างโปรแกรมตามอัลกอริทึมที่พัฒนาขึ้นเป็นโมดูลแยกต่างหาก
ดีบักและทดสอบโปรแกรมในระดับโมดูล
จัดทำเอกสารประกอบซอฟต์แวร์
ใช้เครื่องมือเพื่อเตรียมเอกสารโดยอัตโนมัติ
ทราบ:
ขั้นตอนหลักของการพัฒนาซอฟต์แวร์
หลักการพื้นฐานของเทคโนโลยีการเขียนโปรแกรมเชิงโครงสร้างและเชิงวัตถุ
หลักการพื้นฐานของการดีบักและการทดสอบผลิตภัณฑ์ซอฟต์แวร์
วิธีการและวิธีการพัฒนาเอกสารทางเทคนิค
1.3 จำนวนสัปดาห์(ชั่วโมง) เพื่อการพัฒนาโปรแกรมแนวปฏิบัติทางการศึกษา UP.01
แค่ 1.5 สัปดาห์ 54 ชม.
2 ผลลัพธ์ของการปฏิบัติ
ผลการปฏิบัติการศึกษา UP.01 ของโมดูลมืออาชีพ PM.01 "การพัฒนาโมดูลซอฟต์แวร์ซอฟต์แวร์สำหรับระบบคอมพิวเตอร์" เป็นการพัฒนาความสามารถทั่วไป (OK):
| ชื่อผลงานการปฏิบัติ |
|
| - |
|
| ตกลง 2. จัดกิจกรรมของตนเอง เลือกวิธีมาตรฐานและวิธีการปฏิบัติงานระดับมืออาชีพ ประเมินประสิทธิภาพและคุณภาพ | |
| ตกลง 3. ตัดสินใจในสถานการณ์ที่เป็นมาตรฐานและไม่เป็นมาตรฐานและรับผิดชอบต่อสถานการณ์เหล่านั้น | |
| ตกลง 4. ค้นหาและใช้ข้อมูลที่จำเป็นสำหรับการใช้งานอย่างมีประสิทธิภาพ การพัฒนาวิชาชีพและส่วนบุคคล | |
| ตกลง 5. ใช้เทคโนโลยีสารสนเทศและการสื่อสารในกิจกรรมระดับมืออาชีพ | |
| ตกลง 6. ทำงานเป็นทีมและในทีม, สื่อสารกับเพื่อนร่วมงาน, ผู้บริหาร, ผู้บริโภคอย่างมีประสิทธิภาพ | |
| ตกลง 7. รับผิดชอบงานของสมาชิกในทีม (ผู้ใต้บังคับบัญชา) เพื่อผลสำเร็จของงาน | - |
| คุณสมบัติ |
|
| ตกลง 9. นำทางในเงื่อนไขของการเปลี่ยนแปลงบ่อยครั้งของเทคโนโลยีในกิจกรรมระดับมืออาชีพ |
ความสามารถทางวิชาชีพ (PC):
| ประเภทของกิจกรรมระดับมืออาชีพ | ชื่อผลงานการปฏิบัติ |
|
| การเรียนรู้ประเภทหลักของกิจกรรมระดับมืออาชีพ | การใช้ทรัพยากรของเครือข่ายคอมพิวเตอร์ในพื้นที่และทั่วโลก การจัดการไฟล์ข้อมูลบนอุปกรณ์เก็บข้อมูลแบบถอดได้ภายในเครื่องรวมถึงบนดิสก์ของเครือข่ายคอมพิวเตอร์ในพื้นที่และบนอินเทอร์เน็ต การพิมพ์ การจำลองแบบ และการถ่ายสำเนาเอกสารบนเครื่องพิมพ์และอุปกรณ์สำนักงานอื่นๆ การควบคุมปัจจุบันในรูปแบบของรายงานการปฏิบัติงานแต่ละงาน การสอบคัดเลือกโมดูล |
|
| การรู้หนังสือและความถูกต้องของงานในโปรแกรมประยุกต์: โปรแกรมแก้ไขข้อความและกราฟิก ฐานข้อมูล โปรแกรมแก้ไขงานนำเสนอ ความเร็วในการค้นหาข้อมูลในเนื้อหาของฐานข้อมูล |
||
| การตั้งค่าความแม่นยำและการรู้หนังสือ อีเมลซอฟต์แวร์เซิร์ฟเวอร์และไคลเอ็นต์: ความเร็วในการค้นหาข้อมูลด้วยเทคโนโลยีและบริการของอินเทอร์เน็ต ความถูกต้องและความรู้ในการป้อนและส่งข้อมูลโดยใช้เทคโนโลยีและบริการอินเทอร์เน็ต |
||
| ความรู้ในการใช้วิธีการและวิธีการปกป้องข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาต ความถูกต้องและแม่นยำ สำเนาสำรองและการกู้คืนข้อมูล |
||
| ความรู้และความแม่นยำในการทำงานกับระบบไฟล์ รูปแบบไฟล์ต่างๆ โปรแกรมจัดการไฟล์ |
||
| การบำรุงรักษารายงานและเอกสารทางเทคนิค |
3 โครงสร้างและเนื้อหาของโปรแกรมการฝึกปฏิบัติ UP.01
3.1 แผนเฉพาะเรื่อง
| รหัสของความสามารถที่สร้างขึ้น | ชื่อของโมดูลมืออาชีพ | ขอบเขตของเวลา, ได้รับมอบหมายให้ปฏิบัติ (ในสัปดาห์, ชั่วโมง) | วันที่ |
| พีซี 1.1 - พีซี 1.6 | น.01 "การพัฒนาโมดูลซอฟต์แวร์สำหรับระบบคอมพิวเตอร์" | 1.5 สัปดาห์ 54 ชม |
3.2 เนื้อหาการปฏิบัติ
| กิจกรรม | ประเภทของงาน | ชื่อสาขาวิชา, หลักสูตรสหวิทยาการระบุหัวข้อ, มั่นใจในประสิทธิภาพของงานประเภทต่างๆ | จำนวนชั่วโมง (สัปดาห์) |
|
| “ การเรียนรู้ประเภทหลักของกิจกรรมระดับมืออาชีพ » | หัวข้อ 1.การแนะนำ. อัลกอริทึมสำหรับการแก้ปัญหา โครงสร้างของอัลกอริทึมเชิงเส้น โครงสร้างของอัลกอริทึมแบบวนรอบ อัลกอริทึมของรูทีนย่อย (ฟังก์ชัน) | ความรู้พื้นฐานเกี่ยวกับการสร้างวัตถุพิเศษ | ||
| เรื่อง2 . สิ่งแวดล้อม สแครช (Scratch) | สร้างความรู้พื้นฐานเกี่ยวกับเครื่องมือกระบวนการอัตโนมัติ สร้างความรู้พื้นฐานเกี่ยวกับเอฟเฟ็กต์แอนิเมชันต่อวัตถุ การใช้ไฮเปอร์ลิงก์และปุ่มต่างๆ การตั้งค่าการสาธิต; บันทึกงานนำเสนอในรูปแบบต่างๆ | MDK.01.01 "การเขียนโปรแกรมระบบ" | ||
| เรื่อง 3 . การสร้างโปรแกรมการฝึกอบรม (บทเรียนจากเรื่อง) | สร้างความรู้พื้นฐานการวิเคราะห์ข้อมูลโดยใช้ฟังก์ชันตัวประมวลผล | MDK.01.02 "การเขียนโปรแกรมประยุกต์" | ||
| หัวข้อที่ 4การพัฒนาโปรแกรมเกม. | สร้างความรู้พื้นฐานการคำนวณลักษณะสุดท้าย | MDK.01.01 "การเขียนโปรแกรมระบบ" | ||
| หัวข้อ 5.ภาษา การเขียนโปรแกรมกราฟิก LabVIEW. | ความรู้พื้นฐานเกี่ยวกับการสร้างการทดสอบโปรเซสเซอร์ | MDK.01.02 "การเขียนโปรแกรมประยุกต์" | ||
| เรื่อง 6. การสร้างแอปพลิเคชันโดยใช้ LabVIEW | สร้างความรู้พื้นฐานของบทสนทนาของผู้ใช้กับระบบ | MDK.01.02 "การเขียนโปรแกรมประยุกต์" | ||
| เรื่อง 7 การใช้ส่วนของโปรแกรมซ้ำ | สร้างความรู้ของผู้ดำเนินการและฟังก์ชั่นของระบบ | MDK.01.02 "การเขียนโปรแกรมประยุกต์" | ||
| เรื่อง 8 เวิร์กชอปเกี่ยวกับ LabVIEW การคุ้มครองแรงงานเมื่อทำงานกับคอมพิวเตอร์ในที่ทำงานของผู้ใช้ | มีความรู้ด้านคอมพิวเตอร์เกิดขึ้น ฟังก์ชันพื้นฐาน. สร้างความรู้ด้านการคุ้มครองแรงงาน | MDK.01.02 "การเขียนโปรแกรมประยุกต์". OP.18 "การคุ้มครองแรงงาน" | ||
| เรื่อง 9 ข้อสรุป การรวบรวมรายงานการปฏิบัติ | มีทักษะในการวิเคราะห์เทคโนโลยีคอมพิวเตอร์การแก้ปัญหา ทักษะเกิดขึ้น | MDK.01.01 "การเขียนโปรแกรมระบบ" MDK.01.02 "การเขียนโปรแกรมประยุกต์" MDK.04.01 "ซอฟต์แวร์สำนักงาน" |
4 เงื่อนไขขององค์กรและการดำเนินการ
การปฏิบัติทางการศึกษาขึ้น 01
4.1 ข้อกำหนดด้านเอกสาร, ที่จำเป็นสำหรับการปฏิบัติ:
โปรแกรมการทำงานการปฏิบัติทางการศึกษา UP.01 ของโมดูลมืออาชีพ PM.01 "การพัฒนาโมดูลซอฟต์แวร์สำหรับระบบคอมพิวเตอร์" เป็นส่วนหนึ่งของโปรแกรมการฝึกอบรมสำหรับผู้เชี่ยวชาญระดับกลางโดยสถาบันการศึกษาอาชีวศึกษาของรัฐ "วิทยาลัยอุตสาหกรรมและเศรษฐกิจโดเนตสค์" ตามมาตรฐานการศึกษาของรัฐของอาชีวศึกษาระดับมัธยมศึกษาในสาขาพิเศษ 09.02.03 “การเขียนโปรแกรมในระบบคอมพิวเตอร์” ก่อตั้งเมื่อ หลักสูตรในโปรแกรมพิเศษโปรแกรมการทำงานในสาขาวิชา MDK.01.01 "การเขียนโปรแกรมระบบ", MDK01.02 "การเขียนโปรแกรมประยุกต์" คำแนะนำวิธีการสำหรับการสนับสนุนด้านการศึกษาและระเบียบวิธีสำหรับการฝึกปฏิบัติของนักเรียนที่เชี่ยวชาญโปรแกรมการศึกษาของอาชีวศึกษาระดับมัธยมศึกษา
4.2 ข้อกำหนดสำหรับการสนับสนุนด้านการศึกษาและระเบียบวิธีปฏิบัติ:
รายการงานที่ได้รับการอนุมัติแยกตามประเภทงาน แนวปฏิบัติ สำหรับนักศึกษาในการปฏิบัติงาน ข้อเสนอแนะ การจัดทำรายงานการปฏิบัติ
4.3 ข้อกำหนดด้านโลจิสติกส์:
องค์กรของการปฏิบัติทางอุตสาหกรรมจำเป็นต้องมีห้องเรียนและห้องปฏิบัติการ
อุปกรณ์สำนักงานและสถานที่ทำงาน:
ที่นั่งตามจำนวนนักเรียน (โต๊ะ คอมพิวเตอร์ เก้าอี้)
สถานที่ทำงานของครู (โต๊ะ คอมพิวเตอร์ เก้าอี้)
ตู้เก็บอุปกรณ์ช่วยสอนและที่ใส่ข้อมูล
งานสำหรับวิธีการเรียนรู้แบบรายบุคคล, การจัดระเบียบงานและแบบฝึกหัดอิสระ, นักเรียนบนคอมพิวเตอร์;
เอกสารอ้างอิงและระเบียบวิธี;
ชุดระบบ แอปพลิเคชัน และโปรแกรมการฝึกอบรมสำหรับพีซีบนสื่อแสงและสื่ออิเล็กทรอนิกส์
วารสารแนะนำนักศึกษาเกี่ยวกับการคุ้มครองแรงงาน
ชุดอุปกรณ์ช่วยสอน
ความช่วยเหลือในการฝึกอบรมด้านเทคนิค:
พีซีเพื่อการศึกษา
ชุดอุปกรณ์โต้ตอบ (โปรเจ็กเตอร์, จอภาพ, ลำโพง);
หมายถึงการดับเพลิง (เครื่องดับเพลิง).
คณะกรรมการห้องเรียน
คอมพิวเตอร์ส่วนบุคคลพร้อมซอฟต์แวร์ลิขสิทธิ์
เลเซอร์ปริ้นเตอร์;
อุปกรณ์ของตู้และเวิร์กสเตชันของเครื่องมือในการพัฒนา: คอมพิวเตอร์ส่วนบุคคล (จอภาพ, หน่วยระบบ, แป้นพิมพ์, เมาส์), ชุดเอกสารการศึกษาและระเบียบวิธี, ซอฟต์แวร์ตามเนื้อหาของระเบียบวินัย (เปลือก ภาษาโปรแกรม).
คอมพิวเตอร์ทุกเครื่องในห้องเรียนเชื่อมต่อกับ เครือข่ายท้องถิ่นสามารถเข้าถึงเครือข่ายจัดเก็บข้อมูลและเข้าถึงอินเทอร์เน็ตได้
อุปกรณ์สื่อสาร:
อะแดปเตอร์เครือข่าย
สายเคเบิลเครือข่าย
อุปกรณ์ไร้สาย WiFi
ส่วนประกอบสำหรับการติดตั้งเครือข่าย อุปกรณ์สำหรับการติดตั้ง
4.4 รายชื่อสิ่งพิมพ์เพื่อการศึกษา, แหล่งข้อมูลทางอินเทอร์เน็ต, วรรณกรรมเพิ่มเติม
แหล่งที่มาหลัก:
โอลิเฟอร์ วี.จี. ระบบปฏิบัติการเครือข่าย: หนังสือเรียนสำหรับมหาวิทยาลัย / V.G. Olifer, N.A. Olifer - แก้ไขครั้งที่ 2 - เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2552,2551 - 668 น.:
อี. ทาเนนบอม. ระบบปฏิบัติการ การพัฒนาและการนำไปใช้ เซนต์ปีเตอร์สเบิร์ก: Piter, 2549. - 568 น.
Pupkov K.A. การเรียนรู้ระบบปฏิบัติการ Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva - มอสโก: วิทยุและการสื่อสาร 2537 - 112 น.
L. Beck ความรู้เบื้องต้นเกี่ยวกับการเขียนโปรแกรมระบบ - M.: Mir, 1988
Grekul V.I. , Denishchenko G.N. , Korovkina N.L. การออกแบบระบบข้อมูล / มอสโก: Binom, 2008. - 304 p.
Lipaev, V.V. วิศวกรรมซอฟต์แวร์ รากฐานของระเบียบวิธี [ข้อความ]: Proc. / V. V. Lipaev; สถานะ. un-t - โรงเรียนเศรษฐศาสตร์ชั้นสูง - ม.: TEIS, 2549. - 608 น.
Lavrishcheva E. M. , Petrukhin V. A. วิธีการและวิธีการของวิศวกรรมซอฟต์แวร์ - หนังสือเรียน
เอียน ซอมเมอร์วิลล์. วิศวกรรมซอฟต์แวร์ พิมพ์ครั้งที่ 6.: ต่อ. จากอังกฤษ. ―เอ็ม : สำนักพิมพ์วิลเลียมส์, 2545.―624 น.
Excel 2010: การเขียนโปรแกรมระดับมืออาชีพใน VBA.: ต่อ. จากอังกฤษ. - M.: LLC “ไอดี. วิลเลียมส์”, 2555. - 944 น. : ป่วย. - พารา หัวนม. ภาษาอังกฤษ
Fowler M. Refactoring: การปรับปรุงรหัสที่มีอยู่ จากภาษาอังกฤษ—St. Petersburg: Symbol Plus, 2003.—432 p.
แหล่งข้อมูลเพิ่มเติม:
วอลคอฟ วี.เอ. คำแนะนำเชิงระเบียบวิธีสำหรับการนำไปใช้งาน งานจริงในระเบียบวินัย "การเขียนโปรแกรมระบบ", โดเนตสค์: DONPEK, 2015
วอลคอฟ วี.เอ. หลักเกณฑ์เพื่อดำเนินการตามโครงการหลักสูตร โดเนตสค์: DONPEC, 2015
อินเทอร์เน็ต- ทรัพยากร:
การเขียนโปรแกรมระบบ [ ทรัพยากรอิเล็กทรอนิกส์] / โหมดการเข้าถึง: http://www.umk3.utmn.ru
ทรัพยากรซอฟต์แวร์และอินเทอร์เน็ต: http://www.intuit.ru
วรรณกรรมตามระเบียบวินัย - http://www.internet-technologies.ru/books/
ตำราอิเล็กทรอนิกส์ "ความรู้เบื้องต้นเกี่ยวกับวิศวกรรมซอฟต์แวร์" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info
ตำราอิเล็กทรอนิกส์ "เทคโนโลยีการเขียนโปรแกรม" - http://bourabai.kz/alg/pro.htm
4.5 ข้อกำหนดสำหรับผู้นำการปฏิบัติจากสถาบันการศึกษาและองค์กร
ข้อกำหนดสำหรับผู้นำการปฏิบัติจากสถาบันการศึกษา:
บุคลากรด้านวิศวกรรมและการสอน : บัณฑิต-อาจารย์หลักสูตรสหวิทยาการและสาขาวิชาวิชาชีพทั่วไป จำเป็นต้องมีประสบการณ์ในองค์กรของสาขาวิชาชีพที่เกี่ยวข้อง
การฝึกอบรมอุตสาหกรรมมหาบัณฑิต: มีประเภทคุณสมบัติ 5-6 ประเภทพร้อมการฝึกงานภาคบังคับในองค์กรเฉพาะทางอย่างน้อยทุก ๆ 3 ปี จำเป็นต้องมีประสบการณ์ในองค์กรของสาขาวิชาชีพที่เกี่ยวข้อง
5 การติดตามและประเมินผล
การปฏิบัติทางการศึกษาขึ้น 01
แบบฟอร์มการรายงานเกี่ยวกับการปฏิบัติด้านการศึกษา UP.01 - รายงานเกี่ยวกับการปฏิบัติซึ่งจัดทำขึ้นตามข้อกำหนดของคำแนะนำเกี่ยวกับระเบียบวิธี
| ผลลัพธ์ (เชี่ยวชาญสมรรถนะวิชาชีพ) | ตัวบ่งชี้พื้นฐาน ผลการเตรียมการ | รูปแบบและวิธีการ ควบคุม |
| พีซี 1.1 ดำเนินการพัฒนาข้อกำหนดสำหรับแต่ละส่วนประกอบ | การพัฒนาอัลกอริทึมสำหรับงานและการนำไปใช้งานโดยใช้คอมพิวเตอร์ช่วยในการออกแบบ | การสังเกตโดยผู้เชี่ยวชาญและการประเมินกิจกรรมของนักเรียนในกระบวนการควบคุมโปรแกรมการศึกษาในชั้นเรียนภาคปฏิบัติเมื่อปฏิบัติงานด้านการศึกษาและภาคปฏิบัติ |
| พีซี 1.2 ดำเนินการพัฒนารหัสผลิตภัณฑ์ซอฟต์แวร์ตามข้อกำหนดสำเร็จรูปในระดับโมดูล | รู้หลักการพื้นฐานของเทคโนโลยีการเขียนโปรแกรมเชิงโครงสร้างและเชิงวัตถุ เพื่อดำเนินการพัฒนาโค้ดโมดูลโปรแกรมในภาษาโปรแกรมสมัยใหม่ |
|
| พีซี 1.3 ทำการดีบักโมดูลโปรแกรมโดยใช้เครื่องมือซอฟต์แวร์พิเศษ | ทำการดีบั๊กและทดสอบโปรแกรมในระดับโมดูล |
|
| พีซี 1.4 ทำการทดสอบโมดูลซอฟต์แวร์ | สร้างโปรแกรมตามอัลกอริทึมที่พัฒนาขึ้นเป็นโมดูลแยกต่างหาก |
|
| พีซี 1.5 ทำการเพิ่มประสิทธิภาพรหัสโมดูล | การพัฒนารหัสผลิตภัณฑ์ซอฟต์แวร์ตามข้อกำหนดสำเร็จรูปที่ระดับโมดูล |
|
| พีซี 1.6 พัฒนาองค์ประกอบการออกแบบและเอกสารทางเทคนิคโดยใช้ภาษาข้อกำหนดกราฟิก | รู้วิธีการและวิธีการในการพัฒนาเอกสารทางเทคนิค เตรียมเอกสารซอฟต์แวร์ ใช้เครื่องมือเพื่อทำเอกสารอัตโนมัติ |
รูปแบบและวิธีการติดตามและประเมินผลการเรียนรู้ควรให้นักเรียนตรวจสอบไม่เพียง แต่การก่อตัวของความสามารถทางวิชาชีพเท่านั้น แต่ยังรวมถึงการพัฒนาความสามารถทั่วไปและทักษะที่ให้พวกเขาด้วย
| ผลลัพธ์ (รอบรู้ความสามารถทั่วไป) | ตัวบ่งชี้หลักสำหรับการประเมินผล | รูปแบบและวิธีการควบคุมและประเมินผล |
| ตกลง 1. เข้าใจสาระสำคัญและความสำคัญทางสังคมของอาชีพในอนาคตของคุณ แสดงความสนใจอย่างต่อเนื่อง | แสดงให้เห็นถึงความสนใจอย่างต่อเนื่องในอาชีพในอนาคต - ความถูกต้องของการประยุกต์ใช้ความสามารถทางวิชาชีพที่เชี่ยวชาญ | การสังเกตและการประเมินโดยผู้เชี่ยวชาญในชั้นเรียนภาคปฏิบัติเมื่อปฏิบัติงานในภาคปฏิบัติทางอุตสาหกรรม |
| ตกลง 2. จัดกิจกรรมของตนเอง กำหนดวิธีการและวิธีการปฏิบัติงานอย่างมืออาชีพ ประเมินประสิทธิภาพและคุณภาพ | เหตุผลของการกำหนดเป้าหมายการเลือกและการประยุกต์ใช้วิธีการและวิธีการในการแก้ปัญหาทางวิชาชีพ ดำเนินการวิเคราะห์ตนเองและแก้ไขผลงานของตนเอง | การประเมินผลในชั้นเรียนภาคปฏิบัติในการปฏิบัติงาน การสังเกตระหว่างการปฏิบัติ วิปัสสนา |
| ตกลง 3. แก้ปัญหา ประเมินความเสี่ยง และตัดสินใจในสถานการณ์ที่ไม่ได้มาตรฐาน | ประสิทธิผลของการตัดสินใจของงานมืออาชีพมาตรฐานและไม่ได้มาตรฐานสำหรับ เวลาที่แน่นอน; ประสิทธิผลของแผนเพื่อเพิ่มประสิทธิภาพคุณภาพของงานที่ทำ | การตีความผลการติดตามกิจกรรมของนักเรียนในกระบวนการทำงานให้เสร็จ |
| ตกลง 4. ค้นหา วิเคราะห์ และประเมินข้อมูลที่จำเป็นสำหรับการตั้งค่าและแก้ปัญหาทางวิชาชีพ การพัฒนาทางวิชาชีพและส่วนบุคคล | การเลือกและวิเคราะห์ข้อมูลที่จำเป็นสำหรับการดำเนินงานด้านวิชาชีพที่ชัดเจนและรวดเร็ว การพัฒนาวิชาชีพและส่วนบุคคล | การประเมินผู้เชี่ยวชาญในระหว่างการทำงาน การควบคุมตนเองในการวางตัวและการแก้ปัญหา |
| ตกลง 5. ใช้เทคโนโลยีสารสนเทศและการสื่อสารเพื่อปรับปรุงกิจกรรมทางวิชาชีพ | ความสามารถในการใช้เทคโนโลยีสารสนเทศและการสื่อสารเพื่อแก้ปัญหาทางวิชาชีพ | การประเมินการมอบหมายงาน |
| ตกลง 6. ทำงานเป็นทีมและทีม, มั่นใจในความสามัคคี, สื่อสารอย่างมีประสิทธิภาพกับเพื่อนร่วมงาน, ผู้บริหาร, ผู้บริโภค | ความสามารถในการโต้ตอบกับกลุ่ม, ครู, ต้นแบบของการฝึกอบรมอุตสาหกรรม | |
| ตกลง 7. กำหนดเป้าหมายกระตุ้นกิจกรรมของผู้ใต้บังคับบัญชาจัดระเบียบและควบคุมงานของพวกเขาด้วยความรับผิดชอบต่อผลลัพธ์ของงาน | - วิเคราะห์ตนเองและแก้ไขผลงานของตนเองและผลงานของทีมงาน | การสังเกตความก้าวหน้าของงานในกลุ่มในกระบวนการผลิต |
| ตกลง 8. กำหนดงานของการพัฒนาวิชาชีพและส่วนบุคคลอย่างอิสระ มีส่วนร่วมในการศึกษาด้วยตนเอง วางแผนการฝึกอบรมขั้นสูงอย่างมีสติ | องค์กรของงานอิสระในการสร้างภาพลักษณ์ที่สร้างสรรค์และเป็นมืออาชีพ จัดระเบียบงานด้านการศึกษาและปรับปรุงตนเอง คุณสมบัติ | การสังเกตและประเมินผลในกระบวนการอุตสาหกรรม การวิเคราะห์เชิงไตร่ตรอง (อัลกอริทึมของการกระทำของนักเรียน); ไดอารี่ปฏิบัติ; การวิเคราะห์แฟ้มสะสมผลงานของนักศึกษา |
| ตกลง 9. เตรียมพร้อมที่จะเปลี่ยนเทคโนโลยีในกิจกรรมระดับมืออาชีพ | การวิเคราะห์นวัตกรรมในด้านกระบวนการทางเทคโนโลยีสำหรับการพัฒนาและการผลิตเสื้อผ้า | การประเมินแนวทางแก้ไขปัญหาตามสถานการณ์ เกมธุรกิจและองค์กรเพื่อการศึกษา การสังเกตและประเมินผลในชั้นเรียนภาคปฏิบัติในกระบวนการผลิต |
ขั้นตอนการพัฒนาโมดูลซอฟต์แวร์
- 1. ศึกษาและตรวจสอบคุณสมบัติของโมดูล ทางเลือกของภาษาโปรแกรม (นั่นคือผู้พัฒนาศึกษาข้อมูลจำเพาะค้นหาว่าชัดเจนสำหรับเขาหรือไม่ไม่ว่าจะอธิบายโมดูลเพียงพอหรือไม่ จากนั้นเขาก็เลือกภาษาโปรแกรมที่จะเขียนโมดูลแม้ว่าภาษาโปรแกรมจะเป็น เหมือนกันทั้ง PS)
- 2. ทางเลือกของอัลกอริทึมและโครงสร้างข้อมูล (ที่นี่ปรากฎว่ามีอัลกอริทึมใดบ้างที่รู้จักในการแก้ปัญหาและถ้าเป็นเช่นนั้นให้ใช้)
- 3. การเขียนโปรแกรมโมดูล (เขียนโค้ดโปรแกรม)
- 4. ขัดเกลาข้อความของโมดูล (แก้ไขความคิดเห็นที่มีอยู่ เพิ่มความคิดเห็นเพิ่มเติมเพื่อให้แน่ใจว่ามีคุณภาพตามที่ต้องการ)
- 5. การตรวจสอบโมดูล (ตรวจสอบตรรกะของโมดูลแล้ว การทำงานของโมดูลถูกดีบั๊ก)
มีการใช้วิธีการควบคุมโมดูลโปรแกรมต่อไปนี้:
- - การตรวจสอบข้อความของโมดูลแบบคงที่ (ข้อความถูกอ่านตั้งแต่ต้นจนจบเพื่อค้นหาข้อผิดพลาดในโมดูล โดยปกติแล้ว นอกเหนือจากผู้พัฒนาโมดูลแล้ว โปรแกรมเมอร์หนึ่งหรือหลาย ๆ คนมีส่วนเกี่ยวข้องกับการตรวจสอบดังกล่าว ขอแนะนำว่า ตรวจพบข้อผิดพลาดระหว่างการตรวจสอบดังกล่าว ไม่ได้รับการแก้ไขทันที แต่เมื่ออ่านข้อความโมดูลเสร็จสิ้น)
- - การติดตามแบบ end-to-end (การเลื่อนการดำเนินการของโมดูลด้วยตนเอง (ตัวดำเนินการโดยตัวดำเนินการในลำดับที่ต่อจากตรรกะของโมดูล) ในชุดการทดสอบบางชุด)
- 6. การรวบรวมโมดูล
การเขียนโปรแกรมโครงสร้าง.
เทคนิคการเขียนโปรแกรมที่ได้รับความนิยมมากที่สุดในปัจจุบันคือการเขียนโปรแกรมแบบมีโครงสร้างจากบนลงล่าง
การเขียนโปรแกรมเชิงโครงสร้างเป็นกระบวนการในการแบ่งอัลกอริทึมทีละขั้นตอนออกเป็นส่วนย่อยๆ เพื่อให้ได้องค์ประกอบที่สามารถเขียนใบสั่งยาเฉพาะได้ง่าย
หลักการของการเขียนโปรแกรมเชิงโครงสร้างสองประการ:
- 1. ลำดับรายละเอียด "จากบนลงล่าง"
- 2. ชุดโครงสร้างพื้นฐานที่จำกัดสำหรับการสร้างอัลกอริทึมในระดับความซับซ้อนใดๆ
ข้อกำหนดการเขียนโปรแกรมเชิงโครงสร้าง:
- 1. ควรร่างโปรแกรมเป็นขั้นตอนเล็ก ๆ ดังนั้นงานที่ซับซ้อนจึงแบ่งออกเป็นส่วนที่ค่อนข้างง่ายและเข้าใจได้ง่าย
- 2. ตรรกะของโปรแกรมควรขึ้นอยู่กับจำนวนขั้นต่ำของโครงสร้างการควบคุมพื้นฐานที่เพียงพอ (โครงสร้างเชิงเส้น กิ่งก้าน และวงจร)
คุณสมบัติหลักและข้อดีของการเขียนโปรแกรมเชิงโครงสร้าง:
- 1. ลดความซับซ้อนของโปรแกรม
- 2. ความเป็นไปได้ในการแสดงความถูกต้องของโปรแกรมในขั้นตอนต่าง ๆ ของการแก้ปัญหา
- 3. การมองเห็นของโปรแกรม
- 4. ความสะดวกในการแก้ไข (เปลี่ยนแปลง) ของโปรแกรม
เครื่องมือการเขียนโปรแกรมสมัยใหม่ควรให้การป้องกันสูงสุด ข้อผิดพลาดที่เป็นไปได้นักพัฒนา
ที่นี่เราสามารถเปรียบเทียบกับการพัฒนาวิธีการขับขี่ยานพาหนะ ในตอนแรก ความปลอดภัยได้รับการสนับสนุนโดยการพัฒนากฎจราจร จากนั้นก็มีระบบตีเส้นจราจรและควบคุมทางแยก และในที่สุดทางแยกต่างระดับจราจรก็เริ่มสร้างขึ้นซึ่งโดยหลักการแล้วจะป้องกันการตัดกันของกระแสจราจรของรถยนต์และคนเดินถนน อย่างไรก็ตามวิธีการที่ใช้ควรพิจารณาจากลักษณะของปัญหาที่กำลังแก้ไข: สำหรับถนนในชนบทให้ปฏิบัติตาม กฎง่ายๆ- "ดูใต้เท้าของคุณและรอบ ๆ "
แนวคิดพื้นฐานของการเขียนโปรแกรมแบบมีโครงสร้าง: โปรแกรมควรเป็นชุดของบล็อกที่รวมกันเป็นโครงสร้างแบบลำดับชั้น ซึ่งแต่ละชุดมีอินพุตและเอาต์พุตเดียว
โปรแกรมใด ๆ สามารถสร้างได้โดยใช้บล็อกพื้นฐานสามประเภทเท่านั้น:
- 1. บล็อกการทำงาน - แยก ตัวดำเนินการเชิงเส้นหรือลำดับ;
- บล็อกการแตกแขนงที่ 2 - ถ้า
- 3. ลูปทั่วไป - การสร้างประเภทในขณะที่
จำเป็นอย่างยิ่งที่แต่ละโครงสร้างเหล่านี้จะมีอินพุตเดียวและเอาต์พุตเดียวในแง่ของการควบคุม ดังนั้นตัวดำเนินการทั่วไปจึงมีอินพุตเดียวและเอาต์พุตเดียว
การเขียนโปรแกรมแบบมีโครงสร้าง บางครั้งเรียกว่า "การเขียนโปรแกรมโดยไม่มี GO TO" อย่างไรก็ตาม ประเด็นที่นี่ไม่ใช่คำสั่ง GO TO แต่เป็นการใช้อย่างไม่เลือกปฏิบัติ บ่อยครั้งมาก เมื่อนำโปรแกรมโครงสร้างไปใช้ในภาษาโปรแกรมบางภาษา ตัวดำเนินการเปลี่ยนผ่าน (GO TO) จะถูกใช้เพื่อใช้งานโครงสร้างโครงสร้างโดยไม่ลดข้อได้เปรียบหลักของโปรแกรมโครงสร้าง เป็นคำสั่งข้าม "ที่ไม่ใช่โครงสร้าง" ที่สร้างความสับสนให้กับโปรแกรม โดยเฉพาะอย่างยิ่งการข้ามไปยังคำสั่งที่อยู่ในข้อความโมดูลด้านบน (ก่อนหน้า) คำสั่งข้ามที่กำลังดำเนินการ อย่างไรก็ตาม ความพยายามที่จะหลีกเลี่ยงคำสั่งข้ามในบางกรณีอาจนำไปสู่โปรแกรมที่มีโครงสร้างยุ่งยากเกินไป ซึ่งไม่ได้ปรับปรุงความชัดเจนและมีความเสี่ยงที่จะเกิดข้อผิดพลาดเพิ่มเติมในข้อความของโมดูล ดังนั้น ขอแนะนำให้หลีกเลี่ยงการใช้คำสั่ง Jump หากทำได้ แต่ไม่ควรทำให้โปรแกรมมีความชัดเจน
กรณีที่เป็นประโยชน์ของการใช้ตัวดำเนินการการเปลี่ยนแปลง ได้แก่ การออกจากลูปหรือขั้นตอนในเงื่อนไขพิเศษที่ยุติการทำงาน "ก่อนกำหนด" รอบนี้หรือขั้นตอนที่กำหนดเช่น ยุติการทำงานของหน่วยโครงสร้างบางส่วน (ตัวดำเนินการทั่วไป) และ ด้วยประการฉะนี้เฉพาะที่ละเมิดโครงสร้างของโปรแกรม ความยากลำบากอย่างมาก (และความซับซ้อนของโครงสร้าง) เกิดจากการใช้โครงสร้างของการตอบสนองต่อสถานการณ์พิเศษ (มักผิดพลาด) เนื่องจากสิ่งนี้ไม่เพียงต้องการการออกจากหน่วยโครงสร้างก่อนเวลาเท่านั้น แต่ยังต้องดำเนินการที่จำเป็นสำหรับสถานการณ์นี้ด้วย (ตัวอย่างเช่น การออกข้อมูลการวินิจฉัยที่เหมาะสม) ตัวจัดการข้อยกเว้นสามารถอยู่ที่ระดับใดก็ได้ของโครงสร้างโปรแกรม และสามารถเข้าถึงได้จากระดับที่ต่ำกว่า ที่ยอมรับได้ค่อนข้างมากจากมุมมองทางเทคโนโลยีคือการดำเนินการ "ที่ไม่ใช่โครงสร้าง" ต่อไปนี้ของการตอบสนองต่อสถานการณ์พิเศษ ตัวจัดการข้อยกเว้นถูกวางไว้ที่ส่วนท้ายของหน่วยโครงสร้างหนึ่งหรืออีกหน่วยหนึ่ง และตัวจัดการดังกล่าวแต่ละตัวจะถูกตั้งโปรแกรมในลักษณะที่หลังจากเสร็จสิ้นการทำงาน มันจะออกจากหน่วยโครงสร้างที่ส่วนท้ายของหน่วยโครงสร้างที่วางอยู่ ตัวจัดการดังกล่าวถูกเรียกโดยตัวดำเนินการกระโดดจากหน่วยโครงสร้างที่กำหนด (รวมถึงหน่วยโครงสร้างที่ซ้อนกัน)
โดยทั่วไปแล้วสิ่งสำคัญในการเขียนโปรแกรมเชิงโครงสร้างคือการรวบรวมที่ถูกต้อง แผนภาพลอจิกโปรแกรมการใช้งานซึ่งหมายถึงภาษาเป็นเรื่องรอง
การเปลี่ยนจากแบบไม่เป็นทางการเป็นแบบไม่เป็นทางการเป็นหลัก
การบรรยายครั้งที่ 8
การพัฒนาโมดูลซอฟต์แวร์
ขั้นตอนการพัฒนาโมดูลซอฟต์แวร์ การเขียนโปรแกรมโครงสร้างและรายละเอียดทีละขั้นตอน แนวคิดของรหัสเทียม การควบคุมโมดูลซอฟต์แวร์
8.1. ขั้นตอนการพัฒนาโมดูลซอฟต์แวร์
เมื่อพัฒนาโมดูลซอฟต์แวร์ ขอแนะนำให้ปฏิบัติตามคำสั่งต่อไปนี้:
การศึกษาและตรวจสอบข้อกำหนดของโมดูล การเลือกภาษาโปรแกรม
ทางเลือกของอัลกอริทึมและโครงสร้างข้อมูล
การเขียนโปรแกรม (การเข้ารหัส) ของโมดูล
ขัดข้อความของโมดูล
กำลังตรวจสอบโมดูล
การรวบรวมโมดูล
ขั้นตอนแรกในการพัฒนาโมดูลซอฟต์แวร์คือการควบคุมโครงสร้างของโปรแกรมที่ต่อเนื่องกันในระดับมากจากด้านล่าง: โดยการศึกษาข้อกำหนดของโมดูลผู้พัฒนาจะต้องตรวจสอบให้แน่ใจว่าเข้าใจได้และเพียงพอสำหรับการพัฒนา โมดูลนี้ ในตอนท้ายของขั้นตอนนี้ ภาษาโปรแกรมจะถูกเลือก: แม้ว่าภาษาโปรแกรมอาจถูกกำหนดไว้ล่วงหน้าสำหรับ PS ทั้งหมดแล้ว ในบางกรณี (หากระบบโปรแกรมอนุญาต) อาจเลือกภาษาอื่นที่เหมาะกับการใช้งานมากกว่า ของโมดูลนี้ (เช่น ภาษาแอสเซมบลี)
ในขั้นตอนที่สองในการพัฒนาโมดูลซอฟต์แวร์ จำเป็นต้องค้นหาว่าอัลกอริทึมใดเป็นที่รู้จักสำหรับการแก้ปัญหาที่เกิดขึ้นหรือใกล้เคียงอยู่แล้วหรือไม่ และถ้ามีอัลกอริทึมที่เหมาะสมก็แนะนำให้ใช้ ทางเลือกของโครงสร้างข้อมูลที่เหมาะสมที่จะใช้เมื่อโมดูลทำหน้าที่ของมันส่วนใหญ่จะกำหนดตรรกะและตัวบ่งชี้คุณภาพของโมดูลที่กำลังพัฒนา ดังนั้นจึงควรได้รับการพิจารณาว่าเป็นการตัดสินใจที่สำคัญมาก
ในขั้นตอนที่สาม ข้อความของโมดูลถูกสร้างขึ้นในภาษาโปรแกรมที่เลือก รายละเอียดต่างๆ มากมายที่ต้องนำมาพิจารณาเมื่อใช้งานฟังก์ชันที่ระบุในข้อมูลจำเพาะของโมดูลสามารถนำไปสู่การสร้างข้อความที่สับสนซึ่งมีข้อผิดพลาดและความไม่ถูกต้องจำนวนมากได้อย่างง่ายดาย การค้นหาข้อผิดพลาดในโมดูลดังกล่าวและทำการเปลี่ยนแปลงที่จำเป็นอาจเป็นงานที่ใช้เวลานานมาก ดังนั้นจึงเป็นเรื่องสำคัญมากที่จะต้องใช้ระเบียบวินัยในการเขียนโปรแกรมที่ได้รับการพิสูจน์แล้วและสมเหตุสมผลทางเทคโนโลยีเพื่อสร้างข้อความของโมดูล เป็นครั้งแรกที่ Dijkstra ดึงความสนใจไปที่สิ่งนี้ โดยกำหนดและยืนยันหลักการพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้าง สาขาวิชาการเขียนโปรแกรมจำนวนมากที่ใช้กันอย่างแพร่หลายในทางปฏิบัตินั้นขึ้นอยู่กับหลักการเหล่านี้ ที่พบมากที่สุดคือระเบียบวินัยแบบเจาะลึก ซึ่งจะกล่าวถึงในรายละเอียดในหัวข้อ 8.2 และ 8.3
ขั้นตอนต่อไปในการพัฒนาโมดูลนั้นเกี่ยวข้องกับการนำข้อความของโมดูลไปสู่รูปแบบสุดท้ายตามข้อกำหนดคุณภาพ PS เมื่อตั้งโปรแกรมโมดูล นักพัฒนาจะมุ่งเน้นไปที่การใช้งานฟังก์ชันของโมดูลอย่างถูกต้อง โดยปล่อยให้ความคิดเห็นยังไม่เสร็จสิ้นและปล่อยให้มีการละเมิดข้อกำหนดสำหรับรูปแบบของโปรแกรม เมื่อขัดเกลาข้อความของโมดูล เขาควรแก้ไขความคิดเห็นในข้อความและอาจรวมความคิดเห็นเพิ่มเติมเพื่อจัดเตรียมคุณภาพเบื้องต้นที่จำเป็น เพื่อจุดประสงค์เดียวกัน ข้อความของโปรแกรมจะถูกแก้ไขเพื่อให้เป็นไปตามข้อกำหนดด้านโวหาร
ขั้นตอนการตรวจสอบโมดูลคือการตรวจสอบตรรกะภายในของโมดูลด้วยตนเองก่อนที่จะทำการดีบัก (โดยใช้การดำเนินการบนคอมพิวเตอร์) ใช้หลักการทั่วไปที่กำหนดขึ้นสำหรับสิ่งที่กล่าวถึง เทคโนโลยีการเขียนโปรแกรมเกี่ยวกับความจำเป็นในการควบคุมการตัดสินใจในแต่ละขั้นตอนของการพัฒนา PS (ดูการบรรยาย 3) วิธีการตรวจสอบความถูกต้องของโมดูลได้กล่าวถึงในหัวข้อ 8.4
สุดท้าย ขั้นตอนสุดท้ายของการพัฒนาโมดูลหมายถึงการตรวจสอบความถูกต้องของโมดูล (โดยใช้คอมไพเลอร์) และดำเนินการต่อไปยังกระบวนการดีบักโมดูล
8.2. การเขียนโปรแกรมโครงสร้าง.
เมื่อตั้งโปรแกรมโมดูล ควรระลึกไว้เสมอว่าโปรแกรมต้องเข้าใจได้ไม่เฉพาะกับคอมพิวเตอร์เท่านั้น แต่ยังรวมถึงบุคคลด้วย: ทั้งผู้พัฒนาโมดูลและผู้ตรวจสอบโมดูลและผู้ทดสอบที่เตรียมการทดสอบสำหรับการดีบักโมดูล และผู้ดูแล PS ที่ทำการเปลี่ยนแปลงที่จำเป็นกับโมดูลจะถูกบังคับจะแยกวิเคราะห์ตรรกะของโมดูลซ้ำๆ ในภาษาการเขียนโปรแกรมสมัยใหม่ มีเครื่องมือเพียงพอที่จะสร้างความสับสนให้กับตรรกะนี้ได้มากเท่าที่คุณต้องการ จึงทำให้โมดูลเข้าใจยากสำหรับบุคคลหนึ่งๆ และทำให้ไม่น่าเชื่อถือหรือยากต่อการบำรุงรักษา ดังนั้นจึงต้องระมัดระวังในการเลือกเครื่องมือภาษาที่เหมาะสมและปฏิบัติตามระเบียบวินัยในการเขียนโปรแกรม ในเรื่องนี้ Dijkstra เสนอให้สร้างโปรแกรมโดยประกอบด้วยโครงสร้างการควบคุมหลายประเภท (โครงสร้าง) ซึ่งสามารถเพิ่มความเข้าใจในตรรกะของโปรแกรมได้อย่างมาก การเขียนโปรแกรมโดยใช้โครงสร้างดังกล่าวเท่านั้นที่เรียกว่า โครงสร้าง.
ข้าว. 8.1. โครงสร้างการควบคุมเบื้องต้นของการเขียนโปรแกรมเชิงโครงสร้าง
โครงสร้างหลักของการเขียนโปรแกรมเชิงโครงสร้างคือ: ตาม แยก และทำซ้ำ (ดูรูปที่ 8.1) ส่วนประกอบของโครงสร้างเหล่านี้คือตัวดำเนินการทั่วไป (โหนดการประมวลผล) S, S1, S2 และเงื่อนไข (เพรดิเคต) P ในฐานะตัวดำเนินการทั่วไป อาจมีตัวดำเนินการอย่างง่ายของภาษาโปรแกรมที่ใช้ (การกำหนด อินพุต เอาต์พุต ขั้นตอน โทร) หรือ ส่วนย่อยของโปรแกรม ซึ่งเป็นองค์ประกอบของโครงสร้างการควบคุมหลักของการเขียนโปรแกรมเชิงโครงสร้าง จำเป็นอย่างยิ่งที่แต่ละโครงสร้างเหล่านี้จะมีอินพุตเดียวและเอาต์พุตเดียวในแง่ของการควบคุม ดังนั้นตัวดำเนินการทั่วไปจึงมีอินพุตเดียวและเอาต์พุตเดียว
นอกจากนี้ยังเป็นสิ่งสำคัญมากที่สิ่งก่อสร้างเหล่านี้เป็นวัตถุทางคณิตศาสตร์อยู่แล้ว (ซึ่งโดยพื้นฐานแล้ว จะอธิบายถึงสาเหตุของความสำเร็จของการเขียนโปรแกรมเชิงโครงสร้าง) มันพิสูจน์ได้ว่าสำหรับแต่ละโปรแกรมที่ไม่มีโครงสร้าง มันเป็นไปได้ที่จะสร้างโปรแกรมที่มีโครงสร้างเทียบเท่ากัน (กล่าวคือ แก้ปัญหาเดียวกัน) สำหรับโปรแกรมที่มีโครงสร้าง คุณสมบัติบางอย่างสามารถพิสูจน์ได้ทางคณิตศาสตร์ ซึ่งทำให้สามารถตรวจพบข้อผิดพลาดบางอย่างในโปรแกรมได้ การบรรยายแยกต่างหากจะอุทิศให้กับปัญหานี้
การเขียนโปรแกรมแบบมีโครงสร้าง บางครั้งเรียกว่า "การเขียนโปรแกรมโดยไม่มี GO TO" อย่างไรก็ตาม ประเด็นที่นี่ไม่ใช่คำสั่ง GO TO แต่เป็นการใช้อย่างไม่เลือกปฏิบัติ บ่อยครั้งเมื่อใช้งานการเขียนโปรแกรมโครงสร้างในภาษาการเขียนโปรแกรมบางภาษา (เช่นใน FORTRAN) ตัวดำเนินการการเปลี่ยนแปลง (GO TO) จะใช้ในการสร้างโครงสร้างซึ่งไม่ละเมิดหลักการของการเขียนโปรแกรมโครงสร้าง เป็นคำสั่งข้าม "ที่ไม่ใช่โครงสร้าง" ที่สร้างความสับสนให้กับโปรแกรม โดยเฉพาะอย่างยิ่งการข้ามไปยังคำสั่งที่อยู่ในข้อความโมดูลด้านบน (ก่อน) คำสั่งข้ามที่กำลังดำเนินการ อย่างไรก็ตาม ความพยายามที่จะหลีกเลี่ยงคำสั่งข้ามในบางกรณีอาจนำไปสู่โปรแกรมที่มีโครงสร้างยุ่งยากเกินไป ซึ่งไม่ได้ปรับปรุงความชัดเจนและมีความเสี่ยงที่จะเกิดข้อผิดพลาดเพิ่มเติมในข้อความของโมดูล ดังนั้นจึงอาจแนะนำให้หลีกเลี่ยงการใช้คำสั่ง Jump หากทำได้ แต่ไม่ควรทำให้โปรแกรมมีความชัดเจน
กรณีที่เป็นประโยชน์ของการใช้ทรานซิชันโอเปอเรเตอร์ ได้แก่ การออกจากลูปหรือโพรซีเดอร์ด้วยเงื่อนไขพิเศษที่ "ก่อนกำหนด" จะยุติการทำงานของลูปนี้หรือโพรซีเดอร์นี้ เช่น ยุติการทำงานของหน่วยโครงสร้างบางส่วน โครงสร้างของโปรแกรม ความยากลำบากอย่างมาก (และความซับซ้อนของโครงสร้าง) เกิดจากการใช้โครงสร้างของการตอบสนองต่อสถานการณ์พิเศษ (มักผิดพลาด) เนื่องจากสิ่งนี้ไม่เพียงต้องการการออกจากหน่วยโครงสร้างก่อนกำหนดเท่านั้น แต่ยังต้องมีการประมวลผลที่จำเป็น (การยกเว้น) ของสถานการณ์นี้ (เช่น การออกข้อมูลการวินิจฉัยที่เหมาะสม) ตัวจัดการข้อยกเว้นสามารถอยู่ที่ระดับใดก็ได้ของโครงสร้างโปรแกรม และสามารถเข้าถึงได้จากระดับที่ต่ำกว่า ที่ยอมรับได้ค่อนข้างมากจากมุมมองทางเทคโนโลยีคือการดำเนินการ "ที่ไม่ใช่โครงสร้าง" ต่อไปนี้ของการตอบสนองต่อสถานการณ์พิเศษ ตัวจัดการข้อยกเว้นถูกวางไว้ที่ส่วนท้ายของหน่วยโครงสร้างหนึ่งหรืออีกหน่วยหนึ่ง และตัวจัดการดังกล่าวแต่ละตัวจะถูกตั้งโปรแกรมในลักษณะที่หลังจากเสร็จสิ้นการทำงาน มันจะออกจากหน่วยโครงสร้างที่ส่วนท้ายของหน่วยโครงสร้างที่วางอยู่ ตัวจัดการดังกล่าวถูกเรียกโดยตัวดำเนินการกระโดดจากหน่วยโครงสร้างที่กำหนด (รวมถึงหน่วยโครงสร้างที่ซ้อนกัน)
8.3. รายละเอียดทีละขั้นตอนและแนวคิดของรหัสเทียม
การเขียนโปรแกรมเชิงโครงสร้างให้คำแนะนำเกี่ยวกับข้อความของโมดูลที่ควรจะเป็น คำถามเกิดขึ้นว่าโปรแกรมเมอร์ควรทำตัวอย่างไรเพื่อสร้างข้อความดังกล่าว บ่อยครั้งที่การเขียนโปรแกรมของโมดูลเริ่มต้นด้วยการสร้างบล็อกไดอะแกรมซึ่งอธิบายถึงตรรกะของการดำเนินการโดยทั่วไป อย่างไรก็ตาม เทคโนโลยีที่ทันสมัยโปรแกรมเมอร์ไม่แนะนำให้ทำเช่นนี้หากไม่ได้รับการสนับสนุนจากคอมพิวเตอร์ที่เหมาะสม แม้ว่าผังงานจะให้การแสดงตรรกะของโมดูลที่มองเห็นได้ชัดเจน แต่เมื่อเขียนโค้ดด้วยตนเองในภาษาโปรแกรม แหล่งที่มาของข้อผิดพลาดที่เจาะจงมากก็เกิดขึ้น: การแมปโครงสร้างสองมิติเป็นหลัก เช่น ผังงาน บนข้อความเชิงเส้นที่แสดงโมดูล มีอันตรายจากการบิดเบือนตรรกะของโมดูล โดยเฉพาะอย่างยิ่งเนื่องจากมันเป็นเรื่องค่อนข้างยากทางจิตใจที่จะรักษาระดับความสนใจให้สูงเมื่อทบทวนอีกครั้ง อาจมีข้อยกเว้นในกรณีที่ใช้สร้างบล็อกไดอะแกรม โปรแกรมแก้ไขกราฟิกและมีรูปแบบเป็นทางการมากจนสร้างข้อความโดยอัตโนมัติในภาษาการเขียนโปรแกรม (เช่น ดำเนินการในเทคโนโลยี R)
ในฐานะที่เป็นวิธีการหลักในการสร้างข้อความโมดูล เทคโนโลยีการเขียนโปรแกรมสมัยใหม่แนะนำ รายละเอียดทีละขั้นตอน. สาระสำคัญของวิธีนี้คือการแบ่งขั้นตอนการพัฒนาข้อความของโมดูลออกเป็นหลายขั้นตอน ในครั้งแรก
ขั้นตอนนี้อธิบายโครงร่างทั่วไปของการทำงานของโมดูลในรูปแบบข้อความเชิงเส้นที่มองเห็นได้ (นั่นคือ การใช้แนวคิดขนาดใหญ่มาก) และคำอธิบายนี้ไม่ได้ทำให้เป็นรูปเป็นร่างอย่างสมบูรณ์และเน้นที่การรับรู้ของมนุษย์ ในแต่ละขั้นตอนถัดไป หนึ่งในแนวคิดจะได้รับการปรับปรุงและลงรายละเอียด (เราจะเรียกว่า ระบุไว้) ในคำอธิบายใดๆ ที่พัฒนาขึ้นในขั้นตอนใดขั้นตอนหนึ่งก่อนหน้านี้ ผลลัพธ์ของขั้นตอนนี้ คำอธิบายของแนวคิดที่เลือกซึ่งได้รับการขัดเกลาจะถูกสร้างขึ้นทั้งในแง่ของ ภาษาพื้นฐานการเขียนโปรแกรม (เช่น โมดูลที่เลือกสำหรับการนำเสนอ) หรือในรูปแบบเดียวกับในขั้นตอนแรกโดยใช้แนวคิดที่ได้รับการปรับปรุงใหม่ กระบวนการนี้จะสิ้นสุดลงเมื่อมีแนวคิดทั้งหมดที่ระบุ คำชี้แจง(กล่าวคือจะแสดงเป็นภาษาโปรแกรมพื้นฐานในที่สุด) ขั้นตอนสุดท้ายคือการรับข้อความของโมดูลในภาษาโปรแกรมพื้นฐานโดยการแทนที่แนวคิดที่ปรับปรุงแล้วทั้งหมดด้วยคำอธิบายที่ระบุ และแสดงการเกิดขึ้นทั้งหมดของโครงสร้างโปรแกรมที่มีโครงสร้างโดยใช้ภาษาโปรแกรมนี้
การปรับแต่งทีละขั้นตอนเกี่ยวข้องกับการใช้ภาษาที่เป็นทางการบางส่วนเพื่อแสดงคำอธิบายที่ระบุซึ่งเรียกว่า รหัสเทียม. ภาษานี้อนุญาตให้ใช้โครงสร้างการเขียนโปรแกรมที่มีโครงสร้างทั้งหมดที่ได้รับการทำให้เป็นทางการ พร้อมด้วยส่วนย่อยของภาษาธรรมชาติที่ไม่เป็นทางการเพื่อแสดงข้อความและเงื่อนไขทั่วไป แฟรกเมนต์ที่สอดคล้องกันในภาษาโปรแกรมพื้นฐานยังสามารถระบุเป็นตัวดำเนินการและเงื่อนไขทั่วไปได้อีกด้วย
· จุดเริ่มต้นของโมดูลในภาษาพื้นฐาน เช่น ประโยคแรกหรือหัวเรื่อง (ข้อมูลจำเพาะ) ของโมดูลนี้
ส่วน (ชุด) ของคำอธิบายในภาษาพื้นฐาน และแทนที่จะเป็นคำอธิบายของขั้นตอนและฟังก์ชัน - เฉพาะการออกแบบภายนอกเท่านั้น
· การกำหนดอย่างไม่เป็นทางการของลำดับของตัวดำเนินการโมดูลเป็นตัวดำเนินการทั่วไปหนึ่งตัว (ดูด้านล่าง) เช่นเดียวกับการกำหนดอย่างไม่เป็นทางการของตัวดำเนินการแต่ละขั้นตอนหรือคำอธิบายฟังก์ชันเป็นหนึ่งตัวดำเนินการทั่วไป
· ประโยคสุดท้าย (สิ้นสุด) ของโมดูลในภาษาพื้นฐาน
การออกแบบภายนอกของคำอธิบายของขั้นตอนหรือฟังก์ชันถูกนำเสนอในลักษณะเดียวกัน อย่างไรก็ตาม ต่อไปนี้เป็น Dijkstra จะเป็นการดีกว่าหากนำเสนอส่วนของคำอธิบายที่นี่ด้วยเครื่องหมายที่ไม่เป็นทางการ โดยให้รายละเอียดเป็นคำอธิบายแยกต่างหาก
การกำหนดอย่างไม่เป็นทางการของตัวดำเนินการทั่วไปใน pseudocode นั้นทำขึ้นในภาษาธรรมชาติโดยใช้ประโยคตามอำเภอใจที่เปิดเผยเนื้อหาของมันในเงื่อนไขทั่วไป ข้อกำหนดอย่างเป็นทางการเพียงอย่างเดียวสำหรับการออกแบบการกำหนดดังกล่าวมีดังต่อไปนี้: ประโยคนี้ต้องมีบรรทัดกราฟิก (พิมพ์) หนึ่งบรรทัดขึ้นไปและลงท้ายด้วยจุด (หรืออักขระอื่น ๆ ที่จัดสรรไว้เป็นพิเศษสำหรับสิ่งนี้)
ข้าว. 8.2. การสร้างพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้างในรหัสเทียม
สำหรับตัวดำเนินการทั่วไปที่ไม่เป็นทางการแต่ละตัว จะต้องสร้างคำอธิบายแยกต่างหากซึ่งแสดงตรรกะของงาน (รายละเอียดเนื้อหา) โดยใช้ส่วนประกอบของโครงสร้างหลักของโปรแกรมที่มีโครงสร้างและตัวดำเนินการทั่วไปอื่นๆ ส่วนหัวของคำอธิบายดังกล่าวควรเป็นการกำหนดอย่างไม่เป็นทางการของตัวดำเนินการทั่วไปที่ได้รับการปรับปรุง โครงสร้างพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้างสามารถแสดงได้ดังต่อไปนี้ (ดูรูปที่ 8.2) ในที่นี้ เงื่อนไขสามารถระบุได้อย่างชัดเจนในภาษาการเขียนโปรแกรมพื้นฐานเป็นนิพจน์บูลีน หรือแสดงอย่างไม่เป็นทางการในภาษาธรรมชาติโดยส่วนย่อยบางส่วนที่แสดงความหมายของเงื่อนไขนี้ ในกรณีหลังนี้ ควรสร้างคำอธิบายแยกต่างหากซึ่งมีรายละเอียดเกี่ยวกับเงื่อนไขนี้ โดยระบุการกำหนดเงื่อนไขนี้ (ส่วนย่อยในภาษาธรรมชาติ) เป็นชื่อเรื่อง
ออกจากการทำซ้ำ (วนซ้ำ): ขั้นตอนการออก (ฟังก์ชัน): |
การบรรยาย 8. การพัฒนาโมดูลซอฟต์แวร์
ขั้นตอนการพัฒนาโมดูลซอฟต์แวร์ การเขียนโปรแกรมโครงสร้างและรายละเอียดทีละขั้นตอน แนวคิดของรหัสเทียม การควบคุมโมดูลซอฟต์แวร์
8.1. ขั้นตอนการพัฒนาโมดูลซอฟต์แวร์
เมื่อพัฒนาโมดูลซอฟต์แวร์ ขอแนะนำให้ปฏิบัติตามคำสั่งต่อไปนี้:
ศึกษาและตรวจสอบคุณสมบัติโมดูล การเลือกภาษา
การเขียนโปรแกรม;
ทางเลือกของอัลกอริทึมและโครงสร้างข้อมูล
การเขียนโปรแกรมโมดูล
ขัดข้อความของโมดูล
การตรวจสอบโมดูล
การรวบรวมโมดูล
ขั้นตอนแรกในการพัฒนาโมดูลซอฟต์แวร์คือการควบคุมโครงสร้างของโปรแกรมที่ต่อเนื่องกันในระดับมากจากด้านล่าง: โดยการศึกษาข้อกำหนดของโมดูลผู้พัฒนาจะต้องตรวจสอบให้แน่ใจว่าเข้าใจได้และเพียงพอสำหรับการพัฒนา โมดูลนี้ ในตอนท้ายของขั้นตอนนี้ ภาษาโปรแกรมจะถูกเลือก: แม้ว่าภาษาโปรแกรมอาจถูกกำหนดไว้ล่วงหน้าสำหรับ PS ทั้งหมดแล้ว ในบางกรณี (หากระบบโปรแกรมอนุญาต) อาจเลือกภาษาอื่นที่เหมาะกับการใช้งานมากกว่า ของโมดูลนี้ (เช่น ภาษาแอสเซมบลี)
ในขั้นตอนที่สองในการพัฒนาโมดูลซอฟต์แวร์ จำเป็นต้องค้นหาว่าอัลกอริทึมใดเป็นที่รู้จักสำหรับการแก้ปัญหาที่เกิดขึ้นหรือใกล้เคียงอยู่แล้วหรือไม่ และถ้ามีอัลกอริทึมที่เหมาะสมก็แนะนำให้ใช้ ทางเลือกของโครงสร้างข้อมูลที่เหมาะสมที่จะใช้เมื่อโมดูลทำหน้าที่ของมันส่วนใหญ่จะกำหนดตรรกะและตัวบ่งชี้คุณภาพของโมดูลที่กำลังพัฒนา ดังนั้นจึงควรได้รับการพิจารณาว่าเป็นการตัดสินใจที่สำคัญมาก
ในขั้นตอนที่สาม ข้อความของโมดูลถูกสร้างขึ้นในภาษาโปรแกรมที่เลือก รายละเอียดต่างๆ มากมายที่ต้องนำมาพิจารณาเมื่อใช้งานฟังก์ชันที่ระบุในข้อมูลจำเพาะของโมดูลสามารถนำไปสู่การสร้างข้อความที่สับสนซึ่งมีข้อผิดพลาดและความไม่ถูกต้องจำนวนมากได้อย่างง่ายดาย การค้นหาข้อผิดพลาดในโมดูลดังกล่าวและทำการเปลี่ยนแปลงที่จำเป็นอาจเป็นงานที่ใช้เวลานานมาก ดังนั้นจึงเป็นเรื่องสำคัญมากที่จะต้องใช้ระเบียบวินัยในการเขียนโปรแกรมที่ได้รับการพิสูจน์แล้วและสมเหตุสมผลทางเทคโนโลยีเพื่อสร้างข้อความของโมดูล เป็นครั้งแรกที่ Dijkstra ดึงความสนใจไปที่สิ่งนี้ โดยกำหนดและยืนยันหลักการพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้าง สาขาวิชาการเขียนโปรแกรมจำนวนมากที่ใช้กันอย่างแพร่หลายในทางปฏิบัตินั้นขึ้นอยู่กับหลักการเหล่านี้ ที่พบมากที่สุดคือระเบียบวินัยแบบเจาะลึก ซึ่งจะกล่าวถึงในรายละเอียดในหัวข้อ 8.2 และ 8.3
ขั้นตอนต่อไปในการพัฒนาโมดูลนั้นเกี่ยวข้องกับการนำข้อความของโมดูลไปสู่รูปแบบสุดท้ายตามข้อกำหนดคุณภาพ PS เมื่อตั้งโปรแกรมโมดูล นักพัฒนาจะมุ่งเน้นไปที่การใช้งานฟังก์ชันของโมดูลอย่างถูกต้อง โดยปล่อยให้ความคิดเห็นยังไม่เสร็จสิ้นและปล่อยให้มีการละเมิดข้อกำหนดสำหรับรูปแบบของโปรแกรม เมื่อขัดเกลาข้อความของโมดูล เขาควรแก้ไขความคิดเห็นในข้อความและอาจรวมความคิดเห็นเพิ่มเติมเพื่อจัดเตรียมคุณภาพเบื้องต้นที่จำเป็น เพื่อจุดประสงค์เดียวกัน ข้อความของโปรแกรมจะถูกแก้ไขเพื่อให้เป็นไปตามข้อกำหนดด้านโวหาร
ขั้นตอนการตรวจสอบโมดูลคือการตรวจสอบลอจิกภายในของโมดูลด้วยตนเองก่อนที่จะทำการดีบัก (โดยใช้การดำเนินการบนคอมพิวเตอร์) ใช้หลักการทั่วไปที่กำหนดขึ้นสำหรับเทคโนโลยีการเขียนโปรแกรมที่กล่าวถึง เกี่ยวกับความจำเป็นในการควบคุมการตัดสินใจในแต่ละขั้นตอนของ การพัฒนา PS (ดูการบรรยาย 3) วิธีการตรวจสอบความถูกต้องของโมดูลได้กล่าวถึงในหัวข้อ 8.4
สุดท้าย ขั้นตอนสุดท้ายของการพัฒนาโมดูลหมายถึงการตรวจสอบความถูกต้องของโมดูล (โดยใช้คอมไพเลอร์) และดำเนินการต่อไปยังกระบวนการดีบักโมดูล
8.2. การเขียนโปรแกรมโครงสร้าง.
เมื่อตั้งโปรแกรมโมดูล ควรระลึกไว้เสมอว่าโปรแกรมต้องเข้าใจได้ไม่เฉพาะกับคอมพิวเตอร์เท่านั้น แต่ยังรวมถึงบุคคลด้วย: ทั้งผู้พัฒนาโมดูลและบุคคลที่ตรวจสอบโมดูล และผู้เขียนข้อความที่กำลังเตรียมการทดสอบสำหรับการดีบัก โมดูล และผู้ดูแล PS ที่ทำการเปลี่ยนแปลงที่จำเป็นกับโมดูลจะต้องแยกวิเคราะห์ตรรกะของโมดูลซ้ำๆ ในภาษาการเขียนโปรแกรมสมัยใหม่ มีเครื่องมือเพียงพอที่จะสร้างความสับสนให้กับตรรกะนี้ได้มากเท่าที่คุณต้องการ จึงทำให้โมดูลเข้าใจยากสำหรับบุคคลหนึ่งๆ และทำให้ไม่น่าเชื่อถือหรือยากต่อการบำรุงรักษา ดังนั้นจึงต้องระมัดระวังในการเลือกเครื่องมือภาษาที่เหมาะสมและปฏิบัติตามระเบียบวินัยในการเขียนโปรแกรม เป็นครั้งแรกที่ Dijkstra ให้ความสนใจกับสิ่งนี้และเสนอให้สร้างโปรแกรมเป็นองค์ประกอบของโครงสร้างควบคุมหลายประเภท (โครงสร้าง) ซึ่งสามารถเพิ่มความเข้าใจในตรรกะของโปรแกรมได้อย่างมาก การเขียนโปรแกรมโดยใช้โครงสร้างดังกล่าวเท่านั้นเรียกว่าการเขียนโปรแกรมเชิงโครงสร้าง
โครงสร้างหลักของการเขียนโปรแกรมเชิงโครงสร้างคือ: ตาม แยก และทำซ้ำ (ดูรูปที่ 8.1) ส่วนประกอบของโครงสร้างเหล่านี้คือตัวดำเนินการทั่วไป (โหนดการประมวลผล) S, S1, S2 และเงื่อนไข (เพรดิเคต) P ในฐานะตัวดำเนินการทั่วไป อาจมีตัวดำเนินการอย่างง่ายของภาษาการเขียนโปรแกรมที่ใช้ (การกำหนด อินพุต เอาต์พุต ขั้นตอน โทร) หรือ ส่วนย่อยของโปรแกรม ซึ่งเป็นองค์ประกอบของโครงสร้างการควบคุมหลักของการเขียนโปรแกรมเชิงโครงสร้าง จำเป็นอย่างยิ่งที่แต่ละโครงสร้างเหล่านี้จะมีอินพุตเดียวและเอาต์พุตเดียวในแง่ของการควบคุม ดังนั้นตัวดำเนินการทั่วไปจึงมีอินพุตเดียวและเอาต์พุตเดียว
นอกจากนี้ยังเป็นสิ่งสำคัญมากที่สิ่งก่อสร้างเหล่านี้เป็นวัตถุทางคณิตศาสตร์อยู่แล้ว (ซึ่งโดยพื้นฐานแล้ว จะอธิบายถึงสาเหตุของความสำเร็จของการเขียนโปรแกรมเชิงโครงสร้าง) ได้รับการพิสูจน์แล้วว่าสำหรับโปรแกรมที่ไม่มีโครงสร้างแต่ละโปรแกรม สามารถสร้างโปรแกรมโครงสร้างที่ใช้งานได้เทียบเท่ากัน (นั่นคือ การแก้ปัญหาเดียวกัน) สำหรับโปรแกรมที่มีโครงสร้าง คุณสมบัติบางอย่างสามารถพิสูจน์ได้ทางคณิตศาสตร์ ซึ่งทำให้สามารถตรวจพบข้อผิดพลาดบางอย่างในโปรแกรมได้ การบรรยายแยกต่างหากจะอุทิศให้กับปัญหานี้
การเขียนโปรแกรมแบบมีโครงสร้าง บางครั้งเรียกว่า "การเขียนโปรแกรมโดยไม่มี GO TO" อย่างไรก็ตาม ประเด็นที่นี่ไม่ใช่คำสั่ง GO TO แต่เป็นการใช้อย่างไม่เลือกปฏิบัติ บ่อยครั้งเมื่อใช้งานการเขียนโปรแกรมเชิงโครงสร้างในภาษาการเขียนโปรแกรมบางภาษา (เช่นใน FORTRAN) ตัวดำเนินการเปลี่ยนผ่าน (GO TO) จะถูกใช้เพื่อใช้งานโครงสร้างโครงสร้างโดยไม่ลดข้อได้เปรียบหลักของการเขียนโปรแกรมเชิงโครงสร้าง เป็นคำสั่งข้าม "ที่ไม่ใช่โครงสร้าง" ที่สร้างความสับสนให้กับโปรแกรม โดยเฉพาะอย่างยิ่งการข้ามไปยังคำสั่งที่อยู่ในข้อความโมดูลด้านบน (ก่อนหน้า) คำสั่งข้ามที่กำลังดำเนินการ อย่างไรก็ตาม ความพยายามที่จะหลีกเลี่ยงคำสั่งข้ามในบางกรณีอาจนำไปสู่โปรแกรมที่มีโครงสร้างยุ่งยากเกินไป ซึ่งไม่ได้ปรับปรุงความชัดเจนและมีความเสี่ยงที่จะเกิดข้อผิดพลาดเพิ่มเติมในข้อความของโมดูล ดังนั้นจึงอาจแนะนำให้หลีกเลี่ยงการใช้คำสั่ง Jump หากทำได้ แต่ไม่ควรทำให้โปรแกรมมีความชัดเจน
กรณีที่เป็นประโยชน์ของการใช้ทรานสิชันโอเปอเรเตอร์ ได้แก่ การออกจากลูปหรือโพรซีเดอร์ด้วยเงื่อนไขพิเศษที่ "ก่อนกำหนด" จะยุติการทำงานของลูปนี้หรือโพรซีเดอร์นี้ เช่น ยุติการทำงานของหน่วยโครงสร้างบางส่วน (ตัวดำเนินการทั่วไป) และด้วยเหตุนี้จึงเป็นการละเมิดโครงสร้างของโปรแกรมในท้องถิ่นเท่านั้น ความยากลำบากอย่างมาก (และความซับซ้อนของโครงสร้าง) เกิดจากการใช้โครงสร้างของการตอบสนองต่อสถานการณ์พิเศษ (มักผิดพลาด) เนื่องจากสิ่งนี้ไม่เพียงต้องการการออกจากหน่วยโครงสร้างก่อนกำหนดเท่านั้น แต่ยังต้องมีการประมวลผลที่จำเป็น (การยกเว้น) ของสถานการณ์นี้ (เช่น การออกข้อมูลการวินิจฉัยที่เหมาะสม) ตัวจัดการข้อยกเว้นสามารถอยู่ที่ระดับใดก็ได้ของโครงสร้างโปรแกรม และสามารถเข้าถึงได้จากระดับที่ต่ำกว่า ที่ยอมรับได้ค่อนข้างมากจากมุมมองทางเทคโนโลยีคือการดำเนินการ "ที่ไม่ใช่โครงสร้าง" ต่อไปนี้ของการตอบสนองต่อสถานการณ์พิเศษ ตัวจัดการข้อยกเว้นถูกวางไว้ที่ส่วนท้ายของหน่วยโครงสร้างหนึ่งหรืออีกหน่วยหนึ่ง และตัวจัดการดังกล่าวแต่ละตัวจะถูกตั้งโปรแกรมในลักษณะที่หลังจากเสร็จสิ้นการทำงาน มันจะออกจากหน่วยโครงสร้างที่ส่วนท้ายของหน่วยโครงสร้างที่วางอยู่ ตัวจัดการดังกล่าวถูกเรียกโดยตัวดำเนินการกระโดดจากหน่วยโครงสร้างที่กำหนด (รวมถึงหน่วยโครงสร้างที่ซ้อนกัน)
8.3. รายละเอียดทีละขั้นตอนและแนวคิดของรหัสเทียม
การเขียนโปรแกรมเชิงโครงสร้างให้คำแนะนำเกี่ยวกับข้อความของโมดูลที่ควรจะเป็น คำถามเกิดขึ้นว่าโปรแกรมเมอร์ควรทำตัวอย่างไรเพื่อสร้างข้อความดังกล่าว บางครั้งการเขียนโปรแกรมของโมดูลเริ่มต้นด้วยการสร้างบล็อกไดอะแกรมซึ่งอธิบายถึงตรรกะของการดำเนินการโดยทั่วไป อย่างไรก็ตาม เทคโนโลยีการเขียนโปรแกรมสมัยใหม่ไม่แนะนำให้ทำเช่นนี้ แม้ว่าผังงานจะให้การแสดงตรรกะของโมดูลที่มองเห็นได้ชัดเจน แต่เมื่อมีการเขียนโค้ดในภาษาโปรแกรม แหล่งที่มาของข้อผิดพลาดที่เจาะจงมากก็เกิดขึ้น: การแมปโครงสร้างสองมิติเป็นหลัก เช่น ผังงาน บนข้อความเชิงเส้นที่เป็นตัวแทนของโมดูล ประกอบด้วย อันตรายจากการบิดเบือนตรรกะของโมดูล ยิ่งกว่านั้น ในทางจิตวิทยาค่อนข้างยากที่จะรักษาระดับความสนใจให้สูงเมื่อทบทวนอีกครั้ง อาจมีข้อยกเว้นในกรณีที่ใช้โปรแกรมแก้ไขกราฟิกเพื่อสร้างผังงานและได้รับการทำให้เป็นทางการเพื่อให้ข้อความในภาษาการเขียนโปรแกรมถูกสร้างขึ้นโดยอัตโนมัติจากโปรแกรมเหล่านี้ (เช่น สามารถทำได้ในเทคโนโลยี R)
ในฐานะที่เป็นวิธีหลักในการสร้างข้อความโมดูล เทคโนโลยีการเขียนโปรแกรมสมัยใหม่จึงแนะนำรายละเอียดทีละขั้นตอน สาระสำคัญของวิธีนี้คือการแบ่งขั้นตอนการพัฒนาข้อความของโมดูลออกเป็นหลายขั้นตอน ในขั้นตอนแรก โครงร่างทั่วไปของการทำงานของโมดูลจะอธิบายในรูปแบบข้อความเชิงเส้นที่มองเห็นได้ (นั่นคือ ใช้แนวคิดขนาดใหญ่มาก) และคำอธิบายนี้ไม่ได้ทำให้เป็นทางการอย่างสมบูรณ์และมุ่งเน้นไปที่การรับรู้ของมนุษย์ ในแต่ละขั้นตอนถัดไป แนวคิดหนึ่ง (เราจะเรียกว่าการขัดเกลา) ได้รับการปรับปรุงและลงรายละเอียด ซึ่งใช้ (ตามกฎแล้ว ไม่เป็นทางการ) ในคำอธิบายใด ๆ ที่พัฒนาขึ้นในขั้นตอนใดขั้นตอนหนึ่งก่อนหน้านี้ ผลจากขั้นตอนนี้ คำอธิบายของแนวคิดที่เลือกซึ่งได้รับการขัดเกลาจะถูกสร้างขึ้นทั้งในแง่ของภาษาโปรแกรมพื้นฐาน (เช่น โมดูลที่เลือกสำหรับการนำเสนอ) หรือในรูปแบบเดียวกับในขั้นตอนแรกโดยใช้แนวคิดใหม่ที่กำลังปรับปรุง . กระบวนการนี้จะสิ้นสุดลงเมื่อแนวคิดทั้งหมดที่ได้รับการปรับปรุงจะแสดงในภาษาโปรแกรมพื้นฐานในที่สุด ขั้นตอนสุดท้ายคือการรับข้อความของโมดูลในภาษาโปรแกรมพื้นฐานโดยการแทนที่แนวคิดที่ปรับปรุงแล้วทั้งหมดด้วยคำอธิบายที่ระบุ และแสดงการเกิดขึ้นทั้งหมดของโครงสร้างโปรแกรมที่มีโครงสร้างโดยใช้ภาษาโปรแกรมนี้
การเจาะลึกทีละขั้นตอนเกี่ยวข้องกับการใช้ภาษาที่เป็นทางการบางส่วนเพื่อแสดงคำอธิบายดังกล่าว ซึ่งเรียกว่า pseudocode ภาษานี้อนุญาตให้ใช้โครงสร้างการเขียนโปรแกรมที่มีโครงสร้างทั้งหมดที่ได้รับการทำให้เป็นทางการ พร้อมด้วยส่วนย่อยของภาษาธรรมชาติที่ไม่เป็นทางการเพื่อแสดงข้อความและเงื่อนไขทั่วไป แฟรกเมนต์ที่สอดคล้องกันในภาษาโปรแกรมพื้นฐานยังสามารถระบุเป็นตัวดำเนินการและเงื่อนไขทั่วไปได้อีกด้วย
คำอธิบายส่วนหัวใน pseudocode ถือได้ว่าเป็นการออกแบบภายนอกของโมดูลในภาษาโปรแกรมพื้นฐานซึ่ง
จุดเริ่มต้นของโมดูลในภาษาพื้นฐาน เช่น ประโยคหรือหัวเรื่องแรก (ข้อมูลจำเพาะ) ของโมดูลนี้
ส่วน (ชุด) ของคำอธิบายในภาษาพื้นฐาน และแทนที่จะเป็นคำอธิบายของขั้นตอนและฟังก์ชัน - เฉพาะการออกแบบภายนอกเท่านั้น
การกำหนดลำดับอย่างไม่เป็นทางการของคำสั่งเนื้อหาของโมดูลเป็นคำสั่งทั่วไปหนึ่งคำสั่ง (ดูด้านล่าง) เช่นเดียวกับการกำหนดลำดับของคำสั่งเนื้อหาของแต่ละขั้นตอนหรือคำอธิบายฟังก์ชันอย่างไม่เป็นทางการเป็นคำสั่งทั่วไปหนึ่งคำสั่ง
ประโยคสุดท้าย (สิ้นสุด) ของโมดูลในภาษาพื้นฐาน
การออกแบบภายนอกของคำอธิบายของขั้นตอนหรือฟังก์ชันถูกนำเสนอในลักษณะเดียวกัน อย่างไรก็ตาม ต่อไปนี้เป็น Dijkstra จะเป็นการดีกว่าหากนำเสนอส่วนของคำอธิบายที่นี่ด้วยเครื่องหมายที่ไม่เป็นทางการ โดยให้รายละเอียดเป็นคำอธิบายแยกต่างหาก
การกำหนดอย่างไม่เป็นทางการของตัวดำเนินการทั่วไปใน pseudocode นั้นทำขึ้นในภาษาธรรมชาติโดยใช้ประโยคตามอำเภอใจที่เปิดเผยเนื้อหาของมันในเงื่อนไขทั่วไป ข้อกำหนดอย่างเป็นทางการเพียงอย่างเดียวสำหรับการออกแบบการกำหนดดังกล่าวมีดังต่อไปนี้: ประโยคนี้ต้องมีบรรทัดกราฟิก (พิมพ์) หนึ่งบรรทัดขึ้นไปและลงท้ายด้วยจุด
สำหรับตัวดำเนินการทั่วไปที่ไม่เป็นทางการแต่ละตัว จะต้องสร้างคำอธิบายแยกต่างหากซึ่งแสดงตรรกะของงาน (รายละเอียดเนื้อหา) โดยใช้ส่วนประกอบของโครงสร้างหลักของโปรแกรมที่มีโครงสร้างและตัวดำเนินการทั่วไปอื่นๆ ส่วนหัวของคำอธิบายดังกล่าวควรเป็นการกำหนดอย่างไม่เป็นทางการของตัวดำเนินการทั่วไปที่ได้รับการปรับปรุง โครงสร้างพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้างสามารถแสดงได้ดังต่อไปนี้ (ดูรูปที่ 8.2) ในที่นี้ เงื่อนไขสามารถระบุได้อย่างชัดเจนในภาษาการเขียนโปรแกรมพื้นฐานเป็นนิพจน์บูลีน หรือแสดงอย่างไม่เป็นทางการในภาษาธรรมชาติโดยส่วนย่อยบางส่วนที่แสดงความหมายของเงื่อนไขนี้ ในกรณีหลังนี้ ควรสร้างคำอธิบายแยกต่างหากซึ่งมีรายละเอียดเกี่ยวกับเงื่อนไขนี้ โดยระบุการกำหนดเงื่อนไขนี้ (ส่วนย่อยในภาษาธรรมชาติ) เป็นชื่อเรื่อง
ข้าว. 8.2. การสร้างพื้นฐานของการเขียนโปรแกรมเชิงโครงสร้างในรหัสเทียม
ข้าว. 8.3. กรณีเฉพาะของตัวดำเนินการการเปลี่ยนแปลงเป็นตัวดำเนินการทั่วไป
ในฐานะที่เป็นตัวดำเนินการทั่วไปใน pseudocode คุณสามารถใช้กรณีพิเศษข้างต้นของตัวดำเนินการการเปลี่ยนแปลง (ดูรูปที่ 8.3) ลำดับของตัวจัดการข้อยกเว้น (ข้อยกเว้น) ระบุไว้ที่ส่วนท้ายของคำอธิบายโมดูลหรือขั้นตอน (ฟังก์ชัน) ตัวจัดการแต่ละตัวมีลักษณะดังนี้:
ข้อยกเว้นexception_name
generic_operator
ข้อยกเว้นทั้งหมด
ข้อแตกต่างระหว่างตัวจัดการข้อยกเว้นและโพรซีเดอร์ที่ไม่มีพารามิเตอร์มีดังนี้: หลังจากโพรซีเดอร์ถูกเรียกใช้งาน ตัวควบคุมจะกลับไปที่คำสั่งตามการเรียกใช้ และหลังจากดำเนินการข้อยกเว้น ตัวควบคุมจะกลับไปที่คำสั่งตามการเรียกไปยังโมดูล หรือขั้นตอน (ฟังก์ชัน) ต่อท้ายซึ่ง ( ซึ่ง) ข้อยกเว้นนี้ถูกวางไว้
ในแต่ละขั้นตอนของรายละเอียด ขอแนะนำให้สร้างคำอธิบายที่มีความหมายเพียงพอ แต่มองเห็นได้ง่าย (ภาพ) เพื่อให้อยู่ในหน้าเดียวของข้อความ ตามกฎแล้ว หมายความว่าคำอธิบายดังกล่าวควรเป็นส่วนประกอบของโครงสร้างการเขียนโปรแกรมเชิงโครงสร้างห้าหรือหกรายการ ขอแนะนำให้วางโครงสร้างที่ซ้อนกันโดยเลื่อนไปทางขวาหลายตำแหน่ง (ดูรูปที่ 8.4) เป็นผลให้คุณสามารถรับคำอธิบายตรรกะของงานในแง่ของการมองเห็นซึ่งค่อนข้างแข่งขันกับผังงาน แต่มีข้อได้เปรียบที่สำคัญ - คำอธิบายเชิงเส้นจะถูกรักษาไว้
ลบในบันทึกไฟล์ก่อนครั้งแรก
เหมาะสำหรับชุดกรอง:
ตั้งค่าเริ่มต้นของไฟล์
หากบันทึกอื่นตอบสนอง
กรองไปยัง
ลบบันทึกอื่นจากไฟล์
ถ้าทั้งหมด
ลาก่อน
หากรายการไม่ถูกลบ
พิมพ์ "บันทึกไม่ถูกลบ"
พิมพ์ "ลบ n บันทึก"
ถ้าทั้งหมด
แนวคิดของรายละเอียดทีละขั้นตอนบางครั้งมาจาก Dijkstra อย่างไรก็ตาม Dijkstra ได้เสนอวิธีการที่แตกต่างกันโดยพื้นฐานสำหรับการสร้างข้อความของโมดูล ซึ่งดูเหมือนว่าเราจะมีความลึกซึ้งและมีแนวโน้มมากกว่า ประการแรก พร้อมกับการปรับแต่งตัวดำเนินการ เขาเสนอให้ค่อย ๆ (ทีละขั้นตอน) ปรับแต่ง (รายละเอียด) โครงสร้างข้อมูลที่ใช้ ประการที่สอง ในแต่ละขั้นตอน เขาแนะนำให้สร้างเครื่องเสมือนขึ้นมาเพื่อลงรายละเอียด และในแง่นั้น ให้รายละเอียดเกี่ยวกับแนวคิดที่ได้รับการขัดเกลาซึ่งเครื่องนี้อนุญาตให้ทำสิ่งนี้ได้ โดยพื้นฐานแล้ว Dijkstra จึงเสนอรายละเอียดโดยเลเยอร์แนวนอนซึ่งเป็นการถ่ายโอนแนวคิดของเขาเกี่ยวกับระบบเลเยอร์ (ดูบทที่ 6) ไปสู่ระดับของการพัฒนาโมดูล ปัจจุบันวิธีการพัฒนาโมดูลนี้ได้รับการสนับสนุนโดยแพ็คเกจภาษา ADA และเครื่องมือการเขียนโปรแกรมเชิงวัตถุ
8.4. การควบคุมโมดูลซอฟต์แวร์
มีการใช้วิธีการควบคุมโมดูลโปรแกรมต่อไปนี้:
การตรวจสอบข้อความโมดูลแบบคงที่
การติดตามแบบ end-to-end;
การพิสูจน์คุณสมบัติของโมดูลซอฟต์แวร์
ในระหว่างการตรวจสอบข้อความของโมดูลแบบคงที่ ข้อความนี้จะถูกอ่านตั้งแต่ต้นจนจบเพื่อค้นหาข้อผิดพลาดในโมดูล โดยปกติแล้ว นอกเหนือจากผู้พัฒนาโมดูลแล้ว ยังมีโปรแกรมเมอร์อีกหนึ่งคนหรือหลาย ๆ คนที่เกี่ยวข้องกับการตรวจสอบดังกล่าว ขอแนะนำให้แก้ไขข้อผิดพลาดที่ตรวจพบระหว่างการตรวจสอบดังกล่าวทันที แต่หลังจากอ่านข้อความของโมดูลเสร็จแล้ว
การติดตามแบบ end-to-end เป็นหนึ่งในประเภทของการควบคุมแบบไดนามิกของโมดูล นอกจากนี้ยังเกี่ยวข้องกับโปรแกรมเมอร์หลายคนที่วนซ้ำการดำเนินการของโมดูลด้วยตนเอง (คำสั่งโดยคำสั่งในลำดับที่ต่อจากตรรกะของโมดูล) ในการทดสอบชุดหนึ่ง
การบรรยายครั้งต่อไปอุทิศให้กับการพิสูจน์คุณสมบัติของโปรแกรม ควรสังเกตที่นี่ว่าวิธีนี้ยังใช้น้อยมาก
วรรณกรรมประกอบการบรรยาย8.
8.2. อี. ไดค์สตรา. หมายเหตุเกี่ยวกับการเขียนโปรแกรมเชิงโครงสร้าง// W. Dahl, E. Dijkstra, K. Hoor การเขียนโปรแกรมโครงสร้าง. - M.: Mir, 1975. - S. 24-97.
8.3. เอ็น. เวิร์ธ. การเขียนโปรแกรมอย่างเป็นระบบ - ม.: มีร์, 2520. - ส. 94-164.
การบรรยายครั้งที่ 9
แนวคิดของเหตุผลของโปรแกรม การทำให้เป็นทางการของคุณสมบัติของโปรแกรม Hoor's triad กฎสำหรับการตั้งค่าคุณสมบัติของตัวดำเนินการกำหนด ตัวดำเนินการเงื่อนไข และตัวดำเนินการผสม กฎสำหรับการสร้างคุณสมบัติของตัวดำเนินการลูป แนวคิดของค่าคงที่ของลูป การยุติการทำงานของโปรแกรม
9.1. เหตุผลของโปรแกรม การทำให้คุณสมบัติของโปรแกรมเป็นทางการ
เพื่อปรับปรุงความน่าเชื่อถือของเครื่องมือซอฟต์แวร์ การจัดหาโปรแกรมจะมีประโยชน์มาก ข้อมูลเพิ่มเติมด้วยการใช้มันเป็นไปได้ที่จะเพิ่มระดับการควบคุมของ PS ได้อย่างมาก ข้อมูลดังกล่าวสามารถให้ในรูปแบบของแถลงการณ์ที่ไม่เป็นทางการหรือเป็นทางการซึ่งเชื่อมโยงกับส่วนย่อยของโปรแกรมต่างๆ เราจะเรียกการอ้างเหตุผลของโปรแกรมการยืนยันดังกล่าวว่า ตัวอย่างเช่น การให้เหตุผลแบบไม่เป็นทางการของโปรแกรมสามารถอธิบายแรงจูงใจในการตัดสินใจบางอย่าง ซึ่งสามารถอำนวยความสะดวกอย่างมากในการค้นหาและแก้ไขข้อผิดพลาด เช่นเดียวกับการศึกษาโปรแกรมระหว่างการบำรุงรักษา เหตุผลอย่างเป็นทางการทำให้สามารถพิสูจน์คุณสมบัติบางอย่างของโปรแกรมได้ทั้งด้วยตนเองและควบคุม (ตั้งค่า) โดยอัตโนมัติ
หนึ่งในแนวคิดที่ใช้ในปัจจุบันของเหตุผลอย่างเป็นทางการสำหรับโปรแกรมคือการใช้สิ่งที่เรียกว่า Hoor's triads ให้ S เป็นตัวดำเนินการทั่วไปในสภาพแวดล้อมข้อมูล IS, P และ Q - ภาคแสดง (คำสั่ง) บางอย่างในสภาพแวดล้อมนี้ จากนั้นสัญกรณ์ (P)S(Q) จะเรียกว่า Hoor triad ซึ่งเพรดิเคต P เรียกว่า precondition และเพรดิเคต Q เรียกว่า postcondition สำหรับตัวดำเนินการ S ตัวดำเนินการ (โดยเฉพาะอย่างยิ่ง โปรแกรม) กล่าวกันว่า S มีคุณสมบัติ (P)S(Q) ถ้าเมื่อใดก็ตามที่เพรดิเคต P เป็นจริงก่อนที่ S จะถูกดำเนินการ เพรดิเคต Q จะเป็นจริงหลังจาก S จะถูกดำเนินการ
ตัวอย่างคุณสมบัติของโปรแกรมอย่างง่าย:
(9.1) (n=0) n:=n+1 (n=1),
(9.2) (น
(9.3) (น
(9.4) (n>0) p:=1; ม:=1;
ในขณะที่ m /= n DO
ลาก่อน
ในการพิสูจน์คุณสมบัติของโปรแกรม S เราใช้คุณสมบัติของตัวดำเนินการอย่างง่ายของภาษาการเขียนโปรแกรม (ที่นี่เราจำกัดตัวเองไว้ที่ตัวดำเนินการว่างและตัวดำเนินการกำหนด) และคุณสมบัติของโครงสร้างควบคุม (องค์ประกอบ) ที่โปรแกรมสร้างขึ้นจาก ตัวดำเนินการอย่างง่าย (เราจำกัดตัวเองไว้ที่องค์ประกอบหลักสามประการของการเขียนโปรแกรมเชิงโครงสร้าง ดูการบรรยายที่ 8) คุณสมบัติเหล่านี้มักจะเรียกว่ากฎการตรวจสอบโปรแกรม
9.2. คุณสมบัติของตัวดำเนินการอย่างง่าย
สำหรับตัวดำเนินการว่าง
ทฤษฎีบท 9.1 ให้ P เป็นเพรดิเคตเหนือสภาพแวดล้อมของข้อมูล จากนั้นคุณสมบัติ (P)(P) ถือ
ข้อพิสูจน์ของทฤษฎีบทนี้ชัดเจน: ตัวดำเนินการว่างไม่ได้เปลี่ยนสถานะของสภาพแวดล้อมข้อมูล (ตามความหมายของมัน) ดังนั้นเงื่อนไขเบื้องต้นยังคงเป็นจริงหลังจากการดำเนินการ
สำหรับผู้ดำเนินการมอบหมาย
ทฤษฎีบท 9.2 ให้สภาพแวดล้อมข้อมูล IS ประกอบด้วยตัวแปร X และส่วนที่เหลือของสภาพแวดล้อมข้อมูล RIS:
แล้วคุณสมบัติ
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,
โดยที่ F(X, RIS) เป็นฟังก์ชันค่าเดียว Q คือภาคแสดง
การพิสูจน์. ให้เพรดิเคต Q(F(X0, RIS0), RIS0) เป็นจริงก่อนการดำเนินการของโอเปอเรเตอร์การกำหนด โดยที่ (X0, RIS0) เป็นสถานะตามอำเภอใจของสภาพแวดล้อมข้อมูล IS จากนั้นหลังจากดำเนินการโอเปอเรเตอร์การกำหนดแล้ว เพรดิเคต Q(X, RIS) จะเป็นจริง ดังนั้น X จะได้รับค่า F(X0, RIS0) ได้อย่างไร และสถานะของ RIS จะไม่เปลี่ยนแปลงโดยคำสั่งมอบหมายที่กำหนด และด้วยเหตุนี้หลังจากดำเนินการคำสั่งมอบหมายในกรณีนี้
Q(X, RIS)=Q(F(X0, RIS0), RIS0)
โดยอาศัยอำนาจตามอำเภอใจของการเลือกสถานะของสภาพแวดล้อมข้อมูล ทฤษฎีบทได้รับการพิสูจน์
ตัวอย่างของคุณสมบัติของตัวดำเนินการกำหนดคือตัวอย่าง 9.1
9.3. คุณสมบัติของโครงสร้างพื้นฐานของการโปรแกรมโครงสร้าง
พิจารณาคุณสมบัติของโครงสร้างหลักของการเขียนโปรแกรมเชิงโครงสร้าง: ต่อไปนี้ การแยกสาขา และการทำซ้ำ
คุณสมบัติของการสืบสันตติวงศ์มีดังต่อไปนี้
ทฤษฎีบท 9.3 ให้ P, Q และ R เป็นเพรดิเคตเหนือสภาพแวดล้อมข้อมูล และ S1 และ S2 เป็นโอเปอเรเตอร์ทั่วไปที่มีคุณสมบัติตามลำดับ
(P)S(Q) และ (Q)S2(R)
จากนั้นสำหรับตัวดำเนินการผสม
S1; S2<.blockquote>
มีสถานที่ให้บริการ
(ป) ส1; เอสทู(ร) .
การพิสูจน์. ให้เพรดิเคต P เป็นจริงสำหรับบางสถานะของสภาพแวดล้อมข้อมูลก่อนการดำเนินการของโอเปอเรเตอร์ S1 จากนั้น โดยอาศัยคุณสมบัติของโอเปอเรเตอร์ S1 หลังจากดำเนินการ เพรดิเคต Q จะเป็นจริง โดยดำเนินการโอเปอเรเตอร์ S2 ดังนั้น หลังจากการดำเนินการของโอเปอเรเตอร์ S2 โดยอาศัยคุณสมบัติของมัน เพรดิเคต R จะเป็นจริง และเนื่องจากโอเปอเรเตอร์ S2 เสร็จสิ้นการดำเนินการของคำสั่งผสม (ตามความหมายของมัน) เพรดิเคต R จะเป็นจริงหลังจาก การดำเนินการตามคำสั่งผสมนี้ซึ่งจำเป็นต้องได้รับการพิสูจน์
ตัวอย่างเช่น ถ้าคุณสมบัติ (9.2) และ (9.3) ค้าง ดังนั้น
สถานที่และทรัพย์สิน
(น
คุณสมบัติการแตกแขนงแสดงดังต่อไปนี้
ทฤษฎีบท 9.4 ให้ P, Q และ R เป็นเพรดิเคตเหนือสภาพแวดล้อมข้อมูล และ S1 และ S2 เป็นโอเปอเรเตอร์ทั่วไปที่มีคุณสมบัติตามลำดับ
(P,Q)S1(R) และ (`P,Q)S2(R)
จากนั้นสำหรับตัวดำเนินการตามเงื่อนไข
ถ้า P แล้ว S1 อื่น S2 ทั้งหมด ถ้า
มีสถานที่ให้บริการ
(Q) IF P แล้ว S1 อื่น S2 ทั้งหมด IF (R)
การพิสูจน์. ให้เพรดิเคต Q เป็นจริงสำหรับบางสถานะของสภาพแวดล้อมข้อมูลก่อนการดำเนินการของตัวดำเนินการเงื่อนไข หากภาคแสดง P เป็นจริงด้วย การดำเนินการของตัวดำเนินการเงื่อนไขตามความหมายของมันจะลดลงเป็นการดำเนินการของตัวดำเนินการ S1 . โดยอาศัยคุณสมบัติของตัวดำเนินการ S1 หลังจากการดำเนินการ (และในกรณีนี้ หลังจากการดำเนินการของตัวดำเนินการเงื่อนไข) เพรดิเคต R จะเป็นจริง อย่างไรก็ตาม หากก่อนการดำเนินการของตัวดำเนินการเงื่อนไข เพรดิเคต P เป็นเท็จ (และ Q ยังคงเป็นจริง) จากนั้นการดำเนินการของตัวดำเนินการตามเงื่อนไขตามความหมายของมันจะลดลงเป็นการดำเนินการของตัวดำเนินการ S2 โดยอาศัยคุณสมบัติของตัวดำเนินการ S2 หลังจากการดำเนินการ (และในกรณีนี้ หลังจากการดำเนินการของตัวดำเนินการเงื่อนไข) เพรดิเคต R จะเป็นจริง ดังนั้น ทฤษฎีบทจึงได้รับการพิสูจน์อย่างสมบูรณ์
ก่อนที่จะดำเนินการต่อไปยังคุณสมบัติของการสร้างซ้ำควรสังเกตว่ามีประโยชน์สำหรับต่อไป
ทฤษฎีบท 9.5 ให้ P, Q, P1 และ Q1 เป็นเพรดิเคตเหนือสภาพแวดล้อมของข้อมูลที่มีความหมาย
P1=>P และ Q=>Q1,
และปล่อยให้คุณสมบัติ (P)S(Q) ถือสำหรับผู้ประกอบการ S จากนั้นคุณสมบัติ (P1)S(Q1) ถือ
ทฤษฎีบทนี้เรียกอีกอย่างว่าทฤษฎีบทคุณสมบัติการอ่อนตัว
การพิสูจน์. ให้เพรดิเคต P1 เป็นจริงสำหรับบางสถานะของสภาพแวดล้อมข้อมูลก่อนการดำเนินการของโอเปอเรเตอร์ S จากนั้นเพรดิเคต P จะเป็นจริงด้วย (เนื่องจากนัย P1=>P) ดังนั้น โดยอาศัยคุณสมบัติของโอเปอเรเตอร์ S หลังจากดำเนินการแล้ว เพรดิเคต Q จะเป็นจริง และด้วยเหตุนี้เพรดิเคต Q1 (โดยอาศัยความหมายโดยนัย Q=>Q1) ดังนั้นทฤษฎีบทจึงได้รับการพิสูจน์
คุณสมบัติการทำซ้ำแสดงดังต่อไปนี้
ทฤษฎีบท 9.6 ให้ I, P, Q และ R เป็นเพรดิเคตเหนือสภาพแวดล้อมของข้อมูลที่มีความหมาย
P=>I และ (I,`Q)=>R ,
และให้ S เป็นตัวดำเนินการทั่วไปด้วยคุณสมบัติ (I)S(I)
จากนั้นสำหรับตัวดำเนินการลูป
ลาก่อน Q DO S ALL BYE
มีสถานที่ให้บริการ
(P) BYE Q DO S ALL BYE (R) .
เพรดิเคต I เรียกว่าค่าคงที่ของตัวดำเนินการลูป
การพิสูจน์. ในการพิสูจน์ทฤษฎีบทนี้ การพิสูจน์คุณสมบัติก็เพียงพอแล้ว
(I) ลาก่อน Q ลาก่อน (I,'Q)
(โดยทฤษฎีบทที่ 9.5 บนพื้นฐานของนัยในเงื่อนไขของทฤษฎีบทนี้) ให้เพรดิเคต I เป็นจริงสำหรับบางสถานะของสภาพแวดล้อมข้อมูลก่อนที่จะดำเนินการกับตัวดำเนินการวัฏจักร หากในกรณีนี้ เพรดิเคต Q เป็นเท็จ ตัวดำเนินการวัฏจักรจะเทียบเท่ากับโอเปอเรเตอร์ว่าง (ตามความหมาย) และโดยอาศัยทฤษฎีบท 9.1 หลังจากการดำเนินการของตัวดำเนินการวัฏจักร ข้อความ (I ,`Q) ถ้าเพรดิเคต Q เป็นจริงก่อนการดำเนินการของโอเปอเรเตอร์ลูป ดังนั้นโอเปอเรเตอร์ลูปตามความหมายสามารถแสดงเป็นตัวดำเนินการผสม S; ลาก่อน Q DO S ALL BYE
โดยอาศัยคุณสมบัติของตัวดำเนินการ S หลังจากดำเนินการแล้ว เพรดิเคต I จะเป็นจริง และสถานการณ์เริ่มต้นเกิดขึ้นเพื่อพิสูจน์คุณสมบัติของตัวดำเนินการวัฏจักร: เพรดิเคต I เป็นจริงก่อนการดำเนินการของโอเปอเรเตอร์วัฏจักร แต่สำหรับ สถานะที่แตกต่างกัน (เปลี่ยนแปลง) ของสภาพแวดล้อมข้อมูล (ซึ่งเพรดิเคต Q สามารถเป็นจริงหรือเท็จก็ได้) หากการดำเนินการของคำสั่งวนซ้ำสิ้นสุดลง โดยการใช้วิธีการเหนี่ยวนำทางคณิตศาสตร์ในจำนวนขั้นตอนที่จำกัด เราจะมาถึงสถานการณ์ที่คำสั่ง (I,`Q) จะเป็นจริงก่อนที่จะดำเนินการ และในกรณีนี้ ตามที่ได้พิสูจน์ไว้ข้างต้น ข้อความนี้จะเป็นจริงแม้หลังจากการดำเนินการของคำสั่งวัฏจักร ทฤษฎีบทได้รับการพิสูจน์แล้ว
ตัวอย่างเช่น สำหรับตัวดำเนินการลูปจากตัวอย่าง (9.4) คุณสมบัติจะเกิดขึ้น
ม.:= ม.+1; พี:= พี*ม
ทั้งหมดเลย (p=n.!}
สิ่งนี้ตามมาจากทฤษฎีบท 9.6 เนื่องจากค่าคงที่ของตัวดำเนินการลูปนี้คือภาคแสดง p=m! และความหมาย (n>0, p=1, m=1) => p=m! และ (p=m!, m=n) => p=n!
9.4. การยุติการทำงานของโปรแกรม
หนึ่งในคุณสมบัติของโปรแกรมที่เราอาจสนใจเพื่อหลีกเลี่ยงข้อผิดพลาดที่อาจเกิดขึ้นใน PS คือการสิ้นสุดของมัน เช่น ไม่มีการปั่นจักรยานสำหรับข้อมูลเริ่มต้นบางอย่าง ในโปรแกรมโครงสร้างที่เราได้พิจารณา เฉพาะโครงสร้างการทำซ้ำเท่านั้นที่สามารถเป็นแหล่งของการวนซ้ำได้ ดังนั้น เพื่อพิสูจน์การสิ้นสุดของโปรแกรม ก็เพียงพอแล้วที่จะสามารถพิสูจน์การสิ้นสุดของโอเปอเรเตอร์ลูปได้ ข้อมูลต่อไปนี้มีประโยชน์สำหรับสิ่งนี้
ทฤษฎีบท 9.7 ให้ F เป็นฟังก์ชันจำนวนเต็มที่ขึ้นอยู่กับสถานะของสภาพแวดล้อมข้อมูลและเป็นไปตามเงื่อนไขต่อไปนี้:
(1) ถ้าสำหรับ สถานะที่กำหนดสภาพแวดล้อมของข้อมูล เพรดิเคต Q เป็นจริง จากนั้นค่าจะเป็นบวก
(2) จะลดลงเมื่อสถานะของสภาพแวดล้อมข้อมูลเปลี่ยนไปอันเป็นผลมาจากการดำเนินการของโอเปอเรเตอร์ S.
จากนั้นดำเนินการคำสั่งวนซ้ำ
ในขณะที่ Q ทำทุกอย่างในขณะที่เสร็จสิ้น
การพิสูจน์. อนุญาต เป็นสถานะของสภาพแวดล้อมข้อมูลก่อนการดำเนินการของคำสั่งรอบ และให้ F(is)=k ถ้าภาคแสดง Q(is) เป็นเท็จ การดำเนินการคำสั่งวนซ้ำจะสิ้นสุดลง ถ้า Q(is) เป็นจริง ให้สันนิษฐานตามทฤษฎีบท k>0 ในกรณีนี้ คำสั่ง S จะถูกดำเนินการอย่างน้อยหนึ่งครั้ง หลังจากการดำเนินการของตัวดำเนินการ S แต่ละครั้งตามเงื่อนไขของทฤษฎีบท ค่าของฟังก์ชัน F จะลดลง และตั้งแต่ก่อนการดำเนินการของตัวดำเนินการ S ภาคแสดง Q จะต้องเป็นจริง (ตามความหมายของตัวดำเนินการวงจร) ค่าของฟังก์ชัน F ในขณะนี้ต้องเป็นบวก (ตามเงื่อนไขของทฤษฎีบท) ดังนั้น เนื่องจากความสมบูรณ์ของฟังก์ชัน F ตัวดำเนินการ S ในวงจรนี้สามารถดำเนินการได้มากกว่า k ครั้ง ทฤษฎีบทได้รับการพิสูจน์แล้ว
ตัวอย่างเช่น สำหรับตัวอย่างตัวดำเนินการวัฏจักรที่พิจารณาข้างต้น เงื่อนไขของทฤษฎีบท 9.7 เป็นไปตามฟังก์ชัน f(n, m)= n-m ตั้งแต่ก่อนดำเนินการคำสั่งลูป m=1 เนื้อหาของลูปนี้จะถูกดำเนินการ (n-1) ครั้ง เช่น คำสั่งลูปนี้สิ้นสุดลง
9.5. ตัวอย่างการพิสูจน์คุณสมบัติของโปรแกรม
ตามกฎที่พิสูจน์แล้วสำหรับการตรวจสอบโปรแกรม เป็นไปได้ที่จะพิสูจน์คุณสมบัติของโปรแกรมที่ประกอบด้วยคำสั่งการมอบหมายและคำสั่งว่าง และใช้องค์ประกอบพื้นฐานสามประการของการเขียนโปรแกรมเชิงโครงสร้าง ในการทำเช่นนี้ การวิเคราะห์โครงสร้างของโปรแกรมและการใช้เงื่อนไขก่อนและหลังของโปรแกรม จำเป็นต้องใช้กฎการตรวจสอบที่เหมาะสมในแต่ละขั้นตอนของการวิเคราะห์ ในกรณีของการจัดองค์ประกอบซ้ำ จำเป็นต้องเลือกค่าคงที่ของวัฏจักรที่เหมาะสม
ตัวอย่างเช่น ให้เราพิสูจน์คุณสมบัติ (9.4) การพิสูจน์นี้จะประกอบด้วยขั้นตอนดังต่อไปนี้
(ขั้นตอนที่ 1). n>0 => (n>0, p - ใดๆ, m - ใดๆ)
(ขั้นตอนที่ 2). เกิดขึ้น
(n>0, p - ใดๆ, m - ใดๆ) p:=1 (n>0, p=1, m - ใดๆ)
โดยทฤษฎีบท 9.2
(ขั้นตอนที่ 3). เกิดขึ้น
(n>0, p=1, ม. - ใดๆ) ม.:=1 (n>0, p=1, ม.=1)
โดยทฤษฎีบท 9.2
(ขั้นตอนที่ 4). เกิดขึ้น
(n>0, p - ใดๆ, m - ใดๆ) p:=1; ม.:=1 (n>0, p=1, ม=1)
ตามทฤษฎีบทที่ 9.3 เนื่องจากผลลัพธ์ของขั้นตอนที่ 2 และ 3
ให้เราพิสูจน์ว่าเพรดิเคต p=m! เป็นวัฏจักรไม่แปรเปลี่ยน นั่นคือ (พี=ม m:=m+1; p:=p*m {p=m!}.!}
(ขั้นตอนที่ 5). เกิดขึ้น (p=m m:=m+1 {p=(m-1)!}.!}
ตามทฤษฎีบท 9.2 ถ้าเราแสดงเงื่อนไขเบื้องต้นในรูปแบบ (p=((m+1)-1).!}
(ขั้นตอนที่ 6). เกิดขึ้น (p=(m-1) p:=p*m {p=m!}.!}
ตามทฤษฎีบท 9.2 ถ้าเราแสดงเงื่อนไขเบื้องต้นในรูปแบบ (p*m=m.!}
(ขั้นตอนที่ 7). มีวัฏจักรที่ไม่แปรผัน
(พี=ม m:=m+1; p:=p*m {p=m!}.!}
ตามทฤษฎีบทที่ 9.3 เนื่องจากผลลัพธ์ของขั้นตอนที่ 5 และ 6
(ขั้นตอนที่ 8). เกิดขึ้น
(n>0, p=1, m=1) ในขณะที่ m /= n DO
ม.:= ม.+1; พี:= พี*ม
ทั้งหมดเลย (p=n.!}
ตามทฤษฎีบท 9.6 โดยอาศัยผลของขั้นตอนที่ 7 และจำไว้ว่า (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(ขั้นตอนที่ 9). เกิดขึ้น
(n>0, p - ใดๆ, m - ใดๆ) p:=1; ม:=1;
ในขณะที่ m /= n DO
ม.:= ม.+1; พี:= พี*ม
ทั้งหมดเลย (p=n.!}
ตามทฤษฎีบทที่ 9.3 เนื่องจากผลลัพธ์ของขั้นตอนที่ 3 และ 8
(ขั้นตอนที่ 10). คุณสมบัติ (9.4) ถือโดยทฤษฎีบท 9.5 เนื่องจากผลลัพธ์ของขั้นตอนที่ 1 และ 9
วรรณกรรมประกอบการบรรยาย9.
9.1. ส. อับรามอฟ องค์ประกอบของการเขียนโปรแกรม - ม.: Nauka, 1982. S. 85-94.
9.2. เอ็ม. เซลโคเวตส์, เอ. ชอว์, เจ. แกนนอน หลักการพัฒนาซอฟต์แวร์ - ม.: มีร์ 2525 ส. 98-105
การบรรยายครั้งที่ 10
แนวคิดพื้นฐาน. ทดสอบกลยุทธ์การออกแบบ คำสั่งดีบัก การดีบักแบบออฟไลน์และการทดสอบโมดูลซอฟต์แวร์ การดีบักและการทดสอบซอฟต์แวร์ที่ครอบคลุม
10.1. แนวคิดพื้นฐาน.
การดีบัก PS เป็นกิจกรรมที่มุ่งตรวจจับและแก้ไขข้อผิดพลาดใน PS โดยใช้กระบวนการรันโปรแกรม การทดสอบ PS เป็นกระบวนการของการดำเนินการโปรแกรมบนชุดข้อมูลบางอย่าง ซึ่งทราบผลลัพธ์ของแอปพลิเคชันล่วงหน้าหรือทราบกฎสำหรับการทำงานของโปรแกรมเหล่านี้ ชุดข้อมูลที่ระบุเรียกว่าการทดสอบหรือเพียงแค่การทดสอบ ดังนั้นการดีบักสามารถแสดงเป็นกระบวนการสามขั้นตอนซ้ำ ๆ กัน: การทดสอบซึ่งเป็นผลมาจากการมีอยู่ของข้อผิดพลาดใน PS สามารถตรวจสอบได้การค้นหาตำแหน่งของข้อผิดพลาดในโปรแกรมและเอกสารประกอบของ PS และ แก้ไขโปรแกรมและเอกสารประกอบเพื่อกำจัดข้อผิดพลาดที่ตรวจพบ กล่าวอีกนัยหนึ่ง:
การดีบัก = การทดสอบ + การค้นหาข้อผิดพลาด + การแก้ไข
ในวรรณคดีต่างประเทศ การดีบักมักเข้าใจว่าเป็นกระบวนการค้นหาและแก้ไขข้อผิดพลาดเท่านั้น (โดยไม่ต้องทดสอบ) ซึ่งจะมีขึ้นในระหว่างการทดสอบ บางครั้งการทดสอบและการดีบักถือเป็นความหมายเดียวกัน ในประเทศของเรา แนวคิดของการดีบั๊กมักจะรวมถึงการทดสอบด้วย ดังนั้นเราจะปฏิบัติตามประเพณีที่กำหนดไว้ อย่างไรก็ตาม การพิจารณาร่วมกันของกระบวนการเหล่านี้ในการบรรยายนี้ทำให้ความคลาดเคลื่อนที่ระบุนั้นไม่มีนัยสำคัญมากนัก อย่างไรก็ตาม ควรสังเกตว่าการทดสอบนั้นใช้เป็นส่วนหนึ่งของกระบวนการรับรอง PS ด้วย (ดูการบรรยาย 14)
10.2. หลักการและประเภทของการดีบัก
ความสำเร็จของการดีบักนั้นขึ้นอยู่กับองค์กรของการทดสอบที่มีเหตุผลเป็นส่วนใหญ่ ในระหว่างการดีบัก ส่วนใหญ่จะพบและกำจัดข้อผิดพลาดเหล่านั้น ซึ่งมีอยู่ใน PS ในระหว่างการทดสอบ ตามที่ระบุไว้แล้ว การทดสอบไม่สามารถพิสูจน์ความถูกต้องของ PS ได้ แต่อย่างดีที่สุดก็สามารถแสดงให้เห็นว่ามีข้อผิดพลาดอยู่ในนั้น กล่าวอีกนัยหนึ่ง ไม่สามารถรับประกันได้ว่าการทดสอบซอฟต์แวร์ด้วยชุดการทดสอบที่เป็นไปได้จริง เป็นไปได้ที่จะระบุการมีอยู่ของข้อผิดพลาดทั้งหมดที่มีอยู่ในซอฟต์แวร์ ดังนั้นจึงเกิดปัญหาสองประการ ก่อนอื่นให้เตรียมชุดการทดสอบดังกล่าวและใช้ PS กับชุดทดสอบเพื่อตรวจจับข้อผิดพลาดให้ได้มากที่สุด อย่างไรก็ตาม ยิ่งกระบวนการทดสอบ (และการดีบักโดยทั่วไป) ดำเนินต่อไปนานเท่าใด ต้นทุนของซอฟต์แวร์ก็จะยิ่งสูงขึ้นเท่านั้น ดังนั้นงานที่สอง: เพื่อกำหนดช่วงเวลาที่การดีบัก PS (หรือส่วนประกอบแต่ละส่วน) เสร็จสมบูรณ์ สัญญาณของความเป็นไปได้ของการสิ้นสุดการดีบักคือความสมบูรณ์ของการครอบคลุมโดยการทดสอบที่ผ่าน PS (เช่น การทดสอบที่ใช้ PS) ของสถานการณ์ต่างๆ มากมายที่เกิดขึ้นระหว่างการดำเนินการของโปรแกรม PS และ การแสดงข้อผิดพลาดที่ค่อนข้างหายากใน PS ในส่วนสุดท้ายของกระบวนการทดสอบ หลังถูกกำหนดตามระดับความน่าเชื่อถือที่ต้องการของ PS ซึ่งระบุไว้ในข้อกำหนดคุณภาพ
เพื่อเพิ่มประสิทธิภาพชุดทดสอบ เช่น เพื่อเตรียมชุดการทดสอบที่จะอนุญาตให้ตรวจจับตามจำนวนที่กำหนด (หรือตามช่วงเวลาที่กำหนดสำหรับการทดสอบ) มากกว่าข้อผิดพลาด อันดับแรก จำเป็นต้องวางแผนชุดนี้ล่วงหน้า และ ประการที่สอง ต้องใช้กลยุทธ์ที่มีเหตุผลสำหรับการวางแผน (การออกแบบ) การทดสอบ การออกแบบการทดสอบสามารถเริ่มได้ทันทีหลังจากเสร็จสิ้นขั้นตอนของคำอธิบายภายนอกของ PS มีแนวทางต่างๆ ในการพัฒนากลยุทธ์การออกแบบการทดสอบ ซึ่งสามารถวางเงื่อนไขแบบกราฟิกได้ (ดูรูปที่ 9.1) ระหว่างแนวทางสุดโต่งสองแนวทางต่อไปนี้ แนวทางซ้ายสุดขั้วคือการทดสอบได้รับการออกแบบบนพื้นฐานของการศึกษาข้อกำหนดเฉพาะของ PS เท่านั้น (คำอธิบายภายนอก คำอธิบายสถาปัตยกรรม และข้อมูลจำเพาะของโมดูล) โครงสร้างของโมดูลไม่ได้คำนึงถึง แต่อย่างใดเช่น พวกเขาจะถือว่าเป็นกล่องดำ อันที่จริง วิธีการนี้ต้องการการแจงนับชุดข้อมูลอินพุตทั้งหมดอย่างสมบูรณ์ เนื่องจากเมื่อใช้เพียงบางส่วนของชุดเหล่านี้เป็นการทดสอบ บางส่วนของโปรแกรม PS อาจใช้ไม่ได้กับการทดสอบใดๆ ดังนั้น ข้อผิดพลาดที่อยู่ในชุดเหล่านั้นจะไม่ ปรากฏ. อย่างไรก็ตาม การทดสอบ PS ด้วยชุดข้อมูลอินพุตแบบเต็มนั้นแทบจะเป็นไปไม่ได้เลย วิธีการสุดโต่งที่เหมาะสมคือการทดสอบได้รับการออกแบบตามการศึกษาข้อความโปรแกรมเพื่อทดสอบทุกวิธีที่โปรแกรม PS แต่ละโปรแกรมถูกดำเนินการ หากเราคำนึงถึงการมีอยู่ของรอบที่มีจำนวนการทำซ้ำหลายตัวแปรในโปรแกรม อาจมีวิธีการดำเนินการโปรแกรม PS ที่แตกต่างกันจำนวนมาก ดังนั้นการทดสอบจึงเป็นไปไม่ได้ในทางปฏิบัติ
กลยุทธ์การออกแบบการทดสอบที่เหมาะสมที่สุดจะอยู่ภายในช่วงเวลาระหว่างแนวทางที่รุนแรงเหล่านี้ แต่ใกล้กับด้านซ้ายมากกว่า มันเกี่ยวข้องกับการออกแบบส่วนสำคัญของการทดสอบตามข้อกำหนด โดยยึดตามหลักการ: สำหรับแต่ละฟังก์ชันหรือคุณลักษณะที่ใช้ - การทดสอบอย่างน้อยหนึ่งรายการ สำหรับแต่ละพื้นที่ และสำหรับแต่ละขอบเขตของการเปลี่ยนแปลงในตัวแปรอินพุตใดๆ - การทดสอบอย่างน้อยหนึ่งรายการ สำหรับแต่ละรายการ กรณีพิเศษหรือสำหรับแต่ละข้อยกเว้นที่ระบุในข้อกำหนด - การทดสอบอย่างน้อยหนึ่งครั้ง แต่ก็ต้องมีการออกแบบการทดสอบบางอย่างและข้อความของโปรแกรมตามหลักการ (อย่างน้อย): แต่ละคำสั่งของโปรแกรม PS แต่ละโปรแกรมต้องทำงานในการทดสอบอย่างน้อยหนึ่งรายการ
สามารถระบุกลยุทธ์การออกแบบการทดสอบที่เหมาะสมที่สุดตามหลักการต่อไปนี้: สำหรับแต่ละเอกสารโปรแกรม (รวมถึง ข้อความโปรแกรม) ซึ่งเป็นส่วนหนึ่งของ PS ควรออกแบบการทดสอบของตนเองเพื่อระบุข้อผิดพลาดในนั้น ไม่ว่าในกรณีใด จะต้องปฏิบัติตามหลักการนี้ตามคำจำกัดความของซอฟต์แวร์และเนื้อหาของแนวคิดของเทคโนโลยีการเขียนโปรแกรมในฐานะเทคโนโลยีสำหรับการพัฒนาซอฟต์แวร์ที่เชื่อถือได้ (ดูการบรรยาย 1) ในเรื่องนี้ Myers ถึงกับให้คำจำกัดความ ประเภทต่างๆการทดสอบขึ้นอยู่กับประเภทของเอกสารโปรแกรมตามการทดสอบที่สร้างขึ้น ในประเทศของเรา การดีบักมีสองประเภทหลัก (รวมถึงการทดสอบ): การดีบักแบบสแตนด์อโลนและการดีบักแบบซับซ้อน การดีบักแบบออฟไลน์หมายถึงการทดสอบเฉพาะบางส่วนของโปรแกรมที่รวมอยู่ใน PS โดยมีการค้นหาและแก้ไขข้อผิดพลาดที่บันทึกไว้ในระหว่างการทดสอบ ซึ่งรวมถึงการดีบักแต่ละโมดูลและการจับคู่โมดูลเพื่อดีบัก การดีบักแบบครอบคลุมหมายถึงการทดสอบ PS โดยรวมด้วยการค้นหาและแก้ไขข้อผิดพลาดที่บันทึกไว้ระหว่างการทดสอบในเอกสารทั้งหมด (รวมถึงข้อความของโปรแกรม PS) ที่เกี่ยวข้องกับ PS โดยรวม เอกสารดังกล่าวรวมถึงคำจำกัดความของข้อกำหนดสำหรับ PS, ข้อกำหนดด้านคุณภาพของ PS, ข้อกำหนดด้านฟังก์ชันของ PS, คำอธิบายของสถาปัตยกรรม PS และข้อความของโปรแกรม PS
10.3. คำสั่งดีบัก
ส่วนนี้ให้แนวทางทั่วไปสำหรับการจัดระเบียบการดีบัก แต่ก่อนอื่น ควรสังเกตปรากฏการณ์ที่ยืนยันความสำคัญของการป้องกันข้อผิดพลาดในขั้นตอนก่อนหน้าของการพัฒนา: เมื่อจำนวนข้อผิดพลาดที่ตรวจพบและแก้ไขในซอฟต์แวร์เพิ่มขึ้น ความน่าจะเป็นสัมพัทธ์ของการมีอยู่ของข้อผิดพลาดที่ตรวจไม่พบในซอฟต์แวร์ก็เพิ่มขึ้นเช่นกัน สิ่งนี้อธิบายได้จากข้อเท็จจริงที่ว่าด้วยจำนวนข้อผิดพลาดที่ตรวจพบใน PS เพิ่มขึ้น ความเข้าใจของเราเกี่ยวกับจำนวนข้อผิดพลาดทั้งหมดที่เกิดขึ้นในนั้น และด้วยเหตุนี้ จำนวนข้อผิดพลาดที่ยังไม่ตรวจพบก็ได้รับการขัดเกลาด้วยเช่นกัน ปรากฏการณ์นี้เป็นการยืนยันถึงความสำคัญของการตรวจหาข้อผิดพลาดตั้งแต่เนิ่นๆ และความจำเป็นในการควบคุมการตัดสินใจอย่างรอบคอบในแต่ละขั้นตอนของการพัฒนาซอฟต์แวร์
บัญญัติ 1. ให้ถือว่าการทดสอบเป็นงานหลักของการพัฒนาซอฟต์แวร์ มอบความไว้วางใจให้กับโปรแกรมเมอร์ที่มีคุณสมบัติเหมาะสมและมีพรสวรรค์มากที่สุด ไม่พึงปรารถนาที่จะทดสอบโปรแกรมของคุณเอง
บัญญัติ 2 การทดสอบที่ดีคือการทดสอบที่มีโอกาสสูงที่จะพบข้อผิดพลาด ไม่ใช่การทดสอบที่แสดงให้เห็นถึงการทำงานที่ถูกต้องของโปรแกรม
บัญญัติ 3. เตรียมการทดสอบทั้งข้อมูลที่ถูกต้องและไม่ถูกต้อง
บัญญัติ 4. หลีกเลี่ยงการทดสอบที่ไม่สามารถทำซ้ำได้ บันทึกข้อความผ่านคอมพิวเตอร์ ศึกษาผลการทดสอบในแต่ละข้ออย่างละเอียด
บัญญัติ 5. เชื่อมต่อแต่ละโมดูลกับโปรแกรมเพียงครั้งเดียว ไม่เคยแก้ไขโปรแกรมเพื่อให้ง่ายต่อการทดสอบ
บัญญัติ 6. ข้ามการทดสอบทั้งหมดที่เกี่ยวข้องกับการตรวจสอบการทำงานของโปรแกรม PS ใดๆ หรือการโต้ตอบกับโปรแกรมอื่น หากมีการเปลี่ยนแปลง (ตัวอย่างเช่น จากการแก้ไขจุดบกพร่อง)
10.4. การดีบักโมดูลออฟไลน์
ในการดีบักแบบออฟไลน์ แต่ละโมดูลจะได้รับการทดสอบจริงในสภาพแวดล้อมการเขียนโปรแกรมบางอย่าง เว้นแต่ว่าโปรแกรมที่ถูกดีบักประกอบด้วยโมดูลเดียวเท่านั้น สภาพแวดล้อมนี้ประกอบด้วยโมดูลอื่นๆ ซึ่งบางโมดูลเป็นโมดูลของโปรแกรมที่ถูกดีบั๊กซึ่งถูกดีบั๊กแล้ว และบางส่วนเป็นโมดูลที่ควบคุมการดีบั๊ก (โมดูลดีบั๊ก โปรดดูด้านล่าง) ดังนั้น ในระหว่างการดีบักแบบออฟไลน์ บางโปรแกรมจะถูกทดสอบอยู่เสมอ ซึ่งสร้างขึ้นโดยเฉพาะสำหรับการทดสอบโมดูลที่ถูกดีบัก โปรแกรมนี้จะจับคู่กับโปรแกรมที่กำลังดีบั๊กเพียงบางส่วนเท่านั้น ยกเว้นเมื่อโมดูลสุดท้ายของโปรแกรมที่กำลังดีบั๊กกำลังถูกดีบั๊ก ขณะที่การดีบักโปรแกรมดำเนินไป สภาพแวดล้อมของโมดูลถัดไปที่ถูกดีบั๊กเพิ่มขึ้นส่วนหนึ่งจะถูกดีบั๊กโมดูลของโปรแกรมนี้อยู่แล้ว และเมื่อดีบั๊กโมดูลสุดท้ายของโปรแกรมนี้ สภาพแวดล้อมของโมดูลที่ถูกดีบั๊กจะประกอบด้วยทั้งหมด โมดูลอื่น ๆ (ดีบั๊กแล้ว) ทั้งหมดของโปรแกรมที่ถูกดีบั๊ก (ไม่มีเลย) โมดูลดีบั๊ก โมดูล เช่น ในกรณีนี้โปรแกรมดีบั๊กจะถูกทดสอบ กระบวนการสร้างโปรแกรมดีบั๊กที่มีโมดูลดีบั๊กและดีบั๊กนี้เรียกว่าการรวมโปรแกรม
โมดูลดีบั๊กที่รวมอยู่ในสภาพแวดล้อมของโมดูลที่ถูกดีบั๊กขึ้นอยู่กับลำดับที่โมดูลของโปรแกรมนั้นถูกดีบั๊ก โมดูลใดที่ถูกดีบั๊ก และเป็นไปได้ว่าการทดสอบใดจะถูกข้ามไป
ในการทดสอบจากล่างขึ้นบน (ดูบทที่ 7) สภาพแวดล้อมนี้จะมีโมดูลดีบั๊กเพียงโมดูลเดียวเสมอ (ยกเว้นเมื่อโมดูลสุดท้ายของโปรแกรมที่ถูกดีบั๊กกำลังถูกดีบั๊ก) ซึ่งจะเป็นหัวหน้าของโปรแกรมภายใต้การทดสอบซึ่งเรียกว่า นาย (หรือคนขับ) โมดูลดีบั๊กชั้นนำเตรียมสภาพแวดล้อมข้อมูลสำหรับการทดสอบโมดูลที่กำลังดีบั๊ก (กล่าวคือ สร้างสถานะที่จำเป็นสำหรับการทดสอบโมดูลนี้ โดยเฉพาะอย่างยิ่ง สามารถป้อนข้อมูลทดสอบบางส่วนได้) เรียกโมดูลที่กำลังดีบั๊ก และหลังจากทำงานเสร็จ เสร็จแล้วออกข้อความที่จำเป็น เมื่อดีบักโมดูลเดียว สามารถคอมไพล์โมดูลดีบักหลักที่แตกต่างกันสำหรับการทดสอบที่แตกต่างกัน
ในการทดสอบด้านล่าง (ดูบทที่ 7) สภาพแวดล้อมของโมดูลที่ถูกดีบั๊กประกอบด้วย เช่น โมดูลดีบั๊ก เครื่องจำลองของโมดูลทั้งหมดที่สามารถเข้าถึงได้โดยโมดูลที่กำลังดีบั๊ก ตลอดจนเครื่องจำลองของโมดูลที่สามารถเข้าถึงได้โดยดีบั๊ก โมดูลของโปรแกรมที่กำลังดีบั๊ก (รวมอยู่ในสภาพแวดล้อมนี้) แต่ยังไม่ได้ดีบั๊ก เครื่องจำลองเหล่านี้บางตัวอาจเปลี่ยนแปลงสำหรับการทดสอบต่างๆ เมื่อแก้จุดบกพร่องโมดูลหนึ่ง
ในความเป็นจริง สภาพแวดล้อมของโมดูลที่ถูกดีบั๊กอาจมีโมดูลดีบั๊กทั้งสองประเภทด้วยเหตุผลดังต่อไปนี้ การทดสอบทั้งขึ้นและลงมีข้อดีและข้อเสีย
ประโยชน์ของการทดสอบจากล่างขึ้นบนรวมถึง
ความสะดวกในการเตรียมการทดสอบและ
ความสามารถในการดำเนินการตามแผนการทดสอบโมดูลอย่างเต็มที่
นี่เป็นเพราะความจริงที่ว่าสถานะการทดสอบของสภาพแวดล้อมข้อมูลนั้นถูกเตรียมไว้ทันทีก่อนที่จะมีการเรียกไปยังโมดูลที่ถูกดีบั๊ก (โมดูลการดีบั๊กชั้นนำ) ข้อเสียของการทดสอบจากล่างขึ้นบนคือคุณลักษณะต่อไปนี้:
ตามกฎแล้วข้อมูลการทดสอบไม่ได้อยู่ในรูปแบบที่ออกแบบมาสำหรับผู้ใช้ (ยกเว้นเมื่อมีการดีบั๊กสุดท้าย, หัว, โมดูลของโปรแกรมที่ถูกดีบั๊ก);
การเขียนโปรแกรมดีบั๊กจำนวนมาก (เมื่อดีบั๊กโมดูลหนึ่ง คุณมักจะต้องสร้างโมดูลดีบั๊กชั้นนำจำนวนมากสำหรับการทดสอบที่แตกต่างกัน)
ความจำเป็นในการทดสอบโมดูลอินเทอร์เฟซเป็นพิเศษ
ข้อดีของการทดสอบจากบนลงล่างรวมถึงคุณสมบัติต่อไปนี้:
การทดสอบส่วนใหญ่จัดทำขึ้นในรูปแบบที่ออกแบบมาสำหรับผู้ใช้
ในหลายกรณี การเขียนโปรแกรมดีบักจำนวนค่อนข้างน้อย (ตามกฎแล้วตัวจำลองโมดูลนั้นง่ายมาก และแต่ละอันเหมาะสำหรับการทดสอบจำนวนมาก บ่อยครั้งสำหรับการทดสอบทั้งหมด)
ไม่จำเป็นต้องทดสอบการจับคู่โมดูล
ข้อเสียของการทดสอบจากบนลงล่างคือสถานะการทดสอบของสภาพแวดล้อมข้อมูลก่อนเข้าถึงโมดูลที่ถูกดีบั๊กนั้นถูกเตรียมโดยอ้อม - เป็นผลจากการใช้โมดูลที่ดีบั๊กแล้วเพื่อทดสอบข้อมูลหรือข้อมูลที่ออกโดยเครื่องจำลอง ประการแรก ทำให้ยากต่อการเตรียมการทดสอบ ต้องใช้ผู้ดำเนินการทดสอบที่มีคุณสมบัติสูง และประการที่สอง ทำให้ยากหรือแม้แต่เป็นไปไม่ได้ที่จะใช้แผนการทดสอบที่สมบูรณ์สำหรับโมดูลที่ถูกดีบั๊ก ข้อบกพร่องนี้บางครั้งทำให้นักพัฒนาต้องใช้การทดสอบจากล่างขึ้นบน แม้ในกรณีของการพัฒนาจากบนลงล่าง อย่างไรก็ตาม บ่อยครั้งที่มีการใช้การปรับเปลี่ยนการทดสอบจากบนลงล่าง หรือการทดสอบจากบนลงล่างและจากล่างขึ้นบนรวมกัน
จากข้อเท็จจริงที่ว่าโดยหลักการแล้วการทดสอบจากบนลงล่างนั้นดีกว่า ให้เราอาศัยเทคนิคที่ช่วยให้เราสามารถเอาชนะความยากลำบากเหล่านี้ได้ในระดับหนึ่ง ก่อนอื่นจำเป็นต้องจัดระเบียบการดีบักของโปรแกรมในลักษณะที่โมดูลที่ทำการป้อนข้อมูลถูกดีบั๊กโดยเร็วที่สุด - จากนั้นสามารถเตรียมข้อมูลทดสอบในรูปแบบที่ออกแบบมาสำหรับผู้ใช้ซึ่งจะช่วยได้มาก ทำให้การเตรียมการทดสอบครั้งต่อไปง่ายขึ้น อินพุตนี้ไม่ได้ดำเนินการในโมดูลหลักเสมอไป ดังนั้นก่อนอื่นคุณต้องดีบักสายโซ่ของโมดูลที่นำไปสู่โมดูลที่ดำเนินการอินพุตที่ระบุ (เปรียบเทียบด้วยวิธีการดำเนินการเชิงสร้างสรรค์ที่มีจุดประสงค์ในการบรรยายที่ 7) จนกว่าโมดูลอินพุตจะถูกดีบั๊ก ข้อมูลการทดสอบจะถูกจัดเตรียมโดยเครื่องจำลองบางอย่าง: โมดูลเหล่านี้รวมอยู่ในเครื่องจำลองโดยเป็นส่วนหนึ่งของเครื่องจำลอง หรือป้อนโดยเครื่องจำลองนี้
ในการทดสอบจากบนลงล่าง สภาวะแวดล้อมของข้อมูลบางอย่างซึ่งจำเป็นสำหรับการทดสอบโมดูลที่ถูกดีบั๊กอาจไม่เกิดขึ้นระหว่างการดำเนินการของโปรแกรมที่ถูกดีบั๊กสำหรับอินพุตใดๆ ในกรณีเหล่านี้ เป็นไปไม่ได้ที่จะไม่ทดสอบโมดูลที่กำลังดีบั๊กเลย เนื่องจากข้อผิดพลาดที่พบในกรณีนี้จะไม่ปรากฏขึ้นเมื่อโปรแกรมที่ถูกดีบั๊กทำงานภายใต้ข้อมูลอินพุตใดๆ อย่างไรก็ตาม ไม่แนะนำให้ทำเช่นนี้ เนื่องจากเมื่อโปรแกรมที่ถูกดีบั๊กเปลี่ยนแปลง (เช่น เมื่อบำรุงรักษา PS) สถานะของสภาพแวดล้อมข้อมูลที่ไม่ได้ใช้สำหรับการทดสอบโมดูลที่ถูกดีบั๊กอาจเกิดขึ้นแล้ว ซึ่งต้องการเพิ่มเติม การทดสอบโมดูลนี้ (และด้วยองค์กรที่มีเหตุผลของการดีบักไม่สามารถทำได้หากตัวโมดูลไม่ได้เปลี่ยนแปลง) เพื่อทดสอบโมดูลที่ถูกดีบั๊กในสถานการณ์เหล่านี้ บางครั้งมีการใช้ตัวจำลองที่เหมาะสมเพื่อสร้างสถานะที่ต้องการของสภาพแวดล้อมข้อมูล บ่อยครั้งที่มีการใช้การทดสอบจากบนลงล่างในเวอร์ชันที่แก้ไข ซึ่งโมดูลที่ถูกดีบั๊กจะได้รับการทดสอบล่วงหน้าแยกต่างหากก่อนที่จะรวมเข้าด้วยกัน (ในกรณีนี้ โมดูลดีบั๊กชั้นนำจะปรากฏในสภาพแวดล้อมของโมดูลที่ถูกดีบั๊กพร้อมกับโมดูล ตัวจำลองที่สามารถเข้าถึงได้โดยโมดูลที่ถูกดีบั๊ก) อย่างไรก็ตาม การปรับเปลี่ยนอื่นของการทดสอบจากบนลงล่างดูเหมือนจะเหมาะสมกว่า: หลังจากการทดสอบจากบนลงล่างของโมดูลที่ถูกดีบั๊กสำหรับสถานะการทดสอบที่เข้าถึงได้ของสภาพแวดล้อมข้อมูลเสร็จสิ้น ควรทำการทดสอบแยกต่างหากสำหรับสถานะที่จำเป็นที่เหลือของข้อมูล สิ่งแวดล้อม.
บ่อยครั้งที่ใช้การทดสอบจากล่างขึ้นบนและล่างขึ้นบนร่วมกัน ซึ่งเรียกว่าวิธีแซนวิช สาระสำคัญของวิธีการนี้อยู่ที่การดำเนินการพร้อมกันของการทดสอบทั้งขึ้นและลง จนกว่ากระบวนการทดสอบทั้งสองนี้จะพบในโมดูลบางโมดูลที่อยู่ตรงกลางของโครงสร้างของโปรแกรมที่ถูกดีบั๊ก วิธีนี้ช่วยให้สามารถใช้ประโยชน์จากข้อได้เปรียบของการทดสอบจากล่างขึ้นบนและบนลงล่างด้วยวิธีการที่สมเหตุสมผล และทำให้ข้อบกพร่องของพวกเขาเป็นกลางในระดับมาก ผลกระทบนี้เป็นการแสดงออกของ หลักการทั่วไป: ผลกระทบทางเทคโนโลยีที่ยิ่งใหญ่ที่สุดสามารถทำได้โดยการรวมวิธีการจากบนลงล่างและจากล่างขึ้นบนในการพัฒนาโปรแกรมระบบปฏิบัติการ เพื่อสนับสนุนวิธีการนี้ว่าแนวทางสถาปัตยกรรมในการพัฒนาซอฟต์แวร์มีจุดมุ่งหมาย (ดูบทที่ 7): ชั้นของโมดูลที่ออกแบบอย่างดีและผ่านการทดสอบอย่างรอบคอบช่วยอำนวยความสะดวกอย่างมากในการดำเนินการของตระกูลโปรแกรมในสาขาวิชาที่เกี่ยวข้องและการปรับปรุงให้ทันสมัยในภายหลัง
สิ่งที่สำคัญมากในการดีบักแบบออฟไลน์คือการทดสอบการจับคู่โมดูล ความจริงก็คือข้อกำหนดของแต่ละโมดูลโปรแกรมยกเว้นส่วนหัวหนึ่งใช้ในโปรแกรมนี้ในสองสถานการณ์: ประการแรกเมื่อพัฒนาข้อความ (บางครั้งพวกเขาพูดว่า: เนื้อหา) ของโมดูลนี้และประการที่สองเมื่อเขียน ยื่นอุทธรณ์ต่อโมดูลนี้ในโมดูลโปรแกรมอื่นๆ ในทั้งสองกรณี อันเป็นผลมาจากข้อผิดพลาด การปฏิบัติตามข้อกำหนดของโมดูลที่กำหนดอาจถูกละเมิดได้ ข้อผิดพลาดดังกล่าวจำเป็นต้องตรวจพบและแก้ไข นี่คือจุดประสงค์ของการทดสอบการจับคู่โมดูล ในการทดสอบจากบนลงล่าง การทดสอบการจับคู่จะดำเนินการไปพร้อมกับการทดสอบที่ข้ามไปแต่ละครั้ง ซึ่งถือเป็นข้อได้เปรียบที่แข็งแกร่งที่สุดของการทดสอบจากบนลงล่าง ระหว่างการทดสอบจากล่างขึ้นบน โมดูลดีบั๊กจะไม่สามารถเข้าถึงได้จากโมดูลของโปรแกรมที่กำลังดีบั๊ก แต่จากโมดูลดีบั๊กชั้นนำ ในเรื่องนี้ มีอันตรายที่โมดูลสุดท้ายสามารถปรับให้เข้ากับ "ความเข้าใจผิด" บางประการของโมดูลที่ถูกดีบั๊กได้ ดังนั้น เมื่อเริ่มต้น (ในกระบวนการรวมโปรแกรม) ทำการดีบักโมดูลใหม่ จึงจำเป็นต้องทดสอบการเรียกแต่ละครั้งไปยังโมดูลที่แก้ไขข้อบกพร่องก่อนหน้านี้ เพื่อตรวจหาความไม่สอดคล้องกันระหว่างการเรียกนี้กับเนื้อหาของโมดูลที่เกี่ยวข้อง (และเป็นไปได้ว่า โมดูลที่แก้ไขข้อบกพร่องก่อนหน้านี้จะต้องตำหนิในเรื่องนี้) ดังนั้นจึงจำเป็นต้องทำการทดสอบซ้ำบางส่วนของโมดูลที่แก้ไขข้อบกพร่องก่อนหน้านี้ภายใต้เงื่อนไขใหม่ และปัญหาเดียวกันก็เกิดขึ้นในกรณีของการทดสอบจากบนลงล่าง
การทดสอบโมดูลแบบอัตโนมัติควรดำเนินการในสี่ขั้นตอนต่อเนื่องกัน
ขั้นตอนที่ 1: ตามข้อมูลจำเพาะของโมดูลที่คุณกำลังแก้ไขข้อบกพร่อง เตรียมการทดสอบสำหรับแต่ละความเป็นไปได้และสถานการณ์ สำหรับแต่ละขอบเขตของช่วงของอินพุตทั้งหมด สำหรับแต่ละช่วงของการเปลี่ยนแปลงข้อมูล สำหรับแต่ละช่วงที่ไม่ถูกต้องของอินพุตทั้งหมด และแต่ละช่วง สภาพไม่ถูกต้อง
ขั้นตอนที่ 2 ตรวจสอบข้อความของโมดูลเพื่อให้แน่ใจว่าแต่ละทิศทางของสาขาใด ๆ จะผ่านการทดสอบอย่างน้อยหนึ่งครั้ง เพิ่มการทดสอบที่ขาดหายไป
ขั้นตอนที่ 3 ตรวจสอบจากข้อความโมดูลว่าสำหรับแต่ละลูปมีการทดสอบที่ไม่ได้ดำเนินการกับเนื้อหาของลูป การทดสอบซึ่งดำเนินการกับเนื้อหาของลูปหนึ่งครั้ง และการทดสอบซึ่งดำเนินการกับเนื้อหาของลูปเป็นจำนวนสูงสุด ครั้ง. เพิ่มการทดสอบที่ขาดหายไป
ขั้นตอนที่ 4 ตรวจสอบข้อความของโมดูลสำหรับความไวต่อค่าข้อมูลอินพุตพิเศษแต่ละค่า - ควรรวมค่าดังกล่าวทั้งหมดไว้ในการทดสอบ เพิ่มการทดสอบที่ขาดหายไป
10.5 การดีบักที่ซับซ้อนของซอฟต์แวร์
ตามที่กล่าวไว้ข้างต้น ด้วยการดีบักที่ซับซ้อน PS โดยรวมจะได้รับการทดสอบ และการทดสอบจะถูกจัดเตรียมไว้สำหรับเอกสาร PS แต่ละรายการ การทดสอบเอกสารเหล่านี้มักจะดำเนินการในลำดับย้อนกลับของการพัฒนา (ข้อยกเว้นเพียงอย่างเดียวคือการทดสอบเอกสารแอปพลิเคชันซึ่งได้รับการพัฒนาตามคำอธิบายภายนอกควบคู่ไปกับการพัฒนาข้อความโปรแกรม การทดสอบนี้ทำได้ดีที่สุดหลังจากการทดสอบ คำอธิบายภายนอกเรียบร้อยแล้ว) การทดสอบในการดีบั๊กที่ซับซ้อนคือการประยุกต์ใช้ PS กับข้อมูลเฉพาะที่โดยหลักการแล้ว อาจเกิดจากผู้ใช้ (โดยเฉพาะอย่างยิ่ง การทดสอบทั้งหมดจัดทำขึ้นในรูปแบบที่ออกแบบมาสำหรับผู้ใช้) แต่อาจอยู่ในแบบจำลอง (แทนที่จะเป็นของจริง) สิ่งแวดล้อม. ตัวอย่างเช่น อุปกรณ์อินพุตและเอาต์พุตบางตัวที่ไม่สามารถเข้าถึงได้ระหว่างการดีบักที่ซับซ้อนสามารถถูกแทนที่ด้วยซอฟต์แวร์จำลอง
การทดสอบสถาปัตยกรรม PS จุดประสงค์ของการทดสอบคือเพื่อค้นหาความแตกต่างระหว่างคำอธิบายของสถาปัตยกรรมและชุดโปรแกรมของ PS เมื่อเริ่มการทดสอบสถาปัตยกรรม PS การดีบักแบบอัตโนมัติของแต่ละระบบย่อยควรเสร็จสิ้นแล้ว ข้อผิดพลาดในการใช้งานสถาปัตยกรรมสามารถเชื่อมโยงกับการโต้ตอบของระบบย่อยเหล่านี้เป็นหลัก โดยเฉพาะอย่างยิ่งกับการใช้งานฟังก์ชันสถาปัตยกรรม (ถ้ามี) ดังนั้นฉันต้องการตรวจสอบวิธีการโต้ตอบทั้งหมดระหว่างระบบย่อย PS แต่เนื่องจากอาจมีจำนวนมากเกินไป จึงควรทดสอบอย่างน้อยห่วงโซ่การดำเนินการทั้งหมดของระบบย่อยโดยไม่ต้องกลับเข้ามาใหม่ หากสถาปัตยกรรมที่กำหนดแสดงถึง PS เป็นระบบย่อยที่เลือกไว้จำนวนของห่วงโซ่ดังกล่าวจะมองเห็นได้ค่อนข้างชัดเจน
การทดสอบ ฟังก์ชั่นภายนอก. จุดประสงค์ของการทดสอบคือเพื่อค้นหาความแตกต่างระหว่างข้อกำหนดการทำงานและชุดโปรแกรมซอฟต์แวร์ของ PS แม้จะมีข้อเท็จจริงที่ว่าโปรแกรมเหล่านี้ทั้งหมดได้รับการดีบั๊กอย่างอิสระแล้ว ความคลาดเคลื่อนเหล่านี้อาจเกิดจากความไม่ตรงกันระหว่างข้อกำหนดภายในของโปรแกรมและโมดูลของโปรแกรม (ขึ้นอยู่กับการทดสอบอัตโนมัติที่ทำขึ้น) และข้อกำหนดการทำงานภายนอก ของ มสธ. ตามกฎแล้ว การทดสอบฟังก์ชันภายนอกจะทำในลักษณะเดียวกับการทดสอบโมดูลในขั้นตอนแรก นั่นคือ เหมือนกล่องดำ
PS การทดสอบคุณภาพ จุดประสงค์ของการทดสอบคือเพื่อค้นหาการละเมิดข้อกำหนดด้านคุณภาพที่กำหนดไว้ในข้อกำหนดคุณภาพ PS นี่เป็นประเภทการทดสอบที่ยากที่สุดและมีการศึกษาน้อยที่สุด เป็นที่ชัดเจนว่าไม่ใช่ทุกคุณภาพดั้งเดิมของ PS ที่สามารถทดสอบได้โดยการทดสอบ (ดูการบรรยายถัดไปเกี่ยวกับการประเมินคุณภาพของ PS) มีการตรวจสอบความสมบูรณ์ของ PS แล้วเมื่อทดสอบฟังก์ชั่นภายนอก ในขั้นตอนนี้ การทดสอบคุณภาพดั้งเดิมนี้สามารถดำเนินต่อไปได้หากจำเป็นต้องได้รับค่าประมาณความน่าจะเป็นของระดับความน่าเชื่อถือของ PS อย่างไรก็ตาม วิธีการทดสอบดังกล่าวยังคงต้องได้รับการพัฒนาต่อไป ความแม่นยำ ความทนทาน ความปลอดภัย ประสิทธิภาพชั่วคราว ประสิทธิภาพของหน่วยความจำในระดับหนึ่ง ประสิทธิภาพของอุปกรณ์ ความสามารถในการขยาย และบางส่วน ความเป็นอิสระของอุปกรณ์สามารถทดสอบได้ การทดสอบแต่ละประเภทมีลักษณะเฉพาะของตนเองและสมควรได้รับการพิจารณาแยกจากกัน เราจะจำกัดตัวเองไว้ที่นี่เพื่อแสดงรายการเหล่านั้น ความง่ายในการใช้งานของ PS (เกณฑ์คุณภาพที่รวมคุณสมบัติพื้นฐานด้านคุณภาพหลายประการ ดูบทบรรยายที่ 4) ได้รับการประเมินเมื่อทำการทดสอบเอกสารเกี่ยวกับการใช้ PS
เอกสารประกอบการทดสอบการสมัคร PS จุดประสงค์ของการทดสอบคือเพื่อค้นหาความไม่สอดคล้องกันระหว่างเอกสารประกอบในแอปพลิเคชันและชุดของโปรแกรมซอฟต์แวร์ รวมถึงความไม่สะดวกในการใช้งานซอฟต์แวร์ ขั้นตอนนี้นำหน้าการเชื่อมต่อของผู้ใช้ทันทีจนเสร็จสิ้นการพัฒนา PS (การทดสอบข้อกำหนดสำหรับ PS และการรับรอง PS) ดังนั้นจึงเป็นเรื่องสำคัญมากที่นักพัฒนาจะต้องใช้ PS ด้วยตนเองในวิธีที่ผู้ใช้จะทำก่อน มัน. การทดสอบทั้งหมดในขั้นตอนนี้จัดทำขึ้นตามเอกสารประกอบการสมัคร PS เท่านั้น ประการแรก ควรทดสอบความสามารถของซอฟต์แวร์เหมือนที่ทำเมื่อทดสอบฟังก์ชันภายนอก แต่ควรทดสอบตามเอกสารประกอบแอปพลิเคชันเท่านั้น ควรทดสอบตำแหน่งที่ไม่ชัดเจนทั้งหมดในเอกสารประกอบ รวมถึงตัวอย่างทั้งหมดที่ใช้ในเอกสารประกอบ ต่อไป กรณีที่ยากที่สุดของการประยุกต์ใช้ PS ได้รับการทดสอบเพื่อตรวจหาการละเมิดข้อกำหนดสำหรับสัมพัทธภาพของการใช้งานง่ายของ PS
การทดสอบคำจำกัดความของข้อกำหนดสำหรับ PS จุดประสงค์ของการทดสอบคือเพื่อค้นหาว่าซอฟต์แวร์ไม่สอดคล้องกับข้อกำหนดที่นำเสนอสำหรับซอฟต์แวร์ในระดับใด ความไม่ชอบมาพากลของการทดสอบประเภทนี้คือดำเนินการโดยองค์กรจัดซื้อหรือองค์กรผู้ใช้ PS ซึ่งเป็นวิธีหนึ่งในการเอาชนะอุปสรรคระหว่างผู้พัฒนาและผู้ใช้ (ดูการบรรยาย 3) โดยปกติแล้วการทดสอบนี้ดำเนินการโดยใช้งานควบคุม - งานทั่วไปที่ทราบผลลัพธ์ของการแก้ปัญหา ในกรณีที่ PS ที่พัฒนาแล้วควรแทนที่ PS รุ่นอื่นที่แก้ปัญหาอย่างน้อยส่วนหนึ่งของ PS ที่พัฒนาแล้ว การทดสอบจะดำเนินการโดยการแก้ปัญหาทั่วไปโดยใช้ทั้ง PS เก่าและใหม่ ตามด้วยการเปรียบเทียบผลลัพธ์ ได้รับ บางครั้งในรูปแบบของการทดสอบดังกล่าวจะใช้การดำเนินการทดลองของ PS - แอปพลิเคชัน PS ใหม่ที่ จำกัด พร้อมการวิเคราะห์การใช้ผลลัพธ์ในทางปฏิบัติ โดยพื้นฐานแล้ว การทดสอบประเภทนี้มีความเหมือนกันอย่างมากกับการทดสอบ PS ระหว่างการรับรอง (ดูบทบรรยายที่ 14) แต่จะดำเนินการก่อนการรับรอง และบางครั้งก็ทำแทนการรับรอง
วรรณกรรมประกอบการบรรยาย10.
10.1. จี. ไมเออร์. ความน่าเชื่อถือของซอฟต์แวร์ - M.: Mir, 1980. - S. 171-262.
10.2. ง. ฟาน พู่. รูปแบบ การพัฒนา ประสิทธิภาพ การดีบัก และการทดสอบโปรแกรม - M.: Mir, 1985. - S. 179-295.
10.3. เจ. ฮิวจ์ส, เจ. มิชทอม. แนวทางโครงสร้างไปจนถึงการเขียนโปรแกรม - M.: Mir, 1980. - S. 254-268.
10.4. เจ. ฟอกซ์. ซอฟต์แวร์และการพัฒนา - M.: Mir, 1985. - S. 227-241.
10.5 เอ็ม. เซลโควิทซ์, เอ. ชอว์, เจ. แกนนอน หลักการพัฒนาซอฟต์แวร์ - M.: Mir, 1982. - S. 105-116.
10.6. ยูเอ็ม เบซโบโรดอฟ. การดีบักแต่ละโปรแกรม - ม.: Nauka, 1982. - S. 9-79.
10.7. วี.วี. ลิปาเยฟ การทดสอบโปรแกรม - ม.: วิทยุและการสื่อสาร 2529. - ส. 15-47.
10.8. อีเอ โซโกเลฟ ความรู้เบื้องต้นเกี่ยวกับเทคโนโลยีการเขียนโปรแกรม (เอกสารประกอบการบรรยาย) - ม.: "DIALOGUE-MGU", 1994.
10.9 อี. ไดค์สตรา. หมายเหตุเกี่ยวกับการเขียนโปรแกรมเชิงโครงสร้าง //ยู. Dahl, E. Dijkstra, K. Hoor การเขียนโปรแกรมโครงสร้าง. - ม.: มีร์ 2518. - ส. 7-13.
การบรรยายครั้งที่ 11
11.1. ฟังก์ชันการทำงานและความเชื่อถือได้เป็นเกณฑ์บังคับสำหรับคุณภาพของซอฟต์แวร์
ในการบรรยายครั้งก่อน เราได้พิจารณาทุกขั้นตอนของการพัฒนา PS ยกเว้นการรับรอง ในขณะเดียวกัน เราไม่ได้กล่าวถึงประเด็นการรับประกันคุณภาพของ PS ตามข้อกำหนดคุณภาพ (ดูการบรรยาย 4) จริงอยู่ ในขณะที่ใช้ข้อกำหนดการทำงานของ PS เราจึงได้หารือเกี่ยวกับประเด็นหลักในการรับรองเกณฑ์การทำงาน หลังจากประกาศความน่าเชื่อถือของซอฟต์แวร์เป็นคุณสมบัติหลัก (ดูการบรรยาย 1) เราได้เลือกการป้องกันข้อผิดพลาดเป็นแนวทางหลักเพื่อให้มั่นใจถึงความน่าเชื่อถือของซอฟต์แวร์ (ดูการบรรยาย 3) และหารือเกี่ยวกับการใช้งานในขั้นตอนต่างๆ ของการพัฒนาซอฟต์แวร์ ดังนั้นวิทยานิพนธ์เกี่ยวกับการทำงานที่จำเป็นและความน่าเชื่อถือของ PS เป็นเกณฑ์สำหรับคุณภาพของมันจึงเป็นที่ประจักษ์
อย่างไรก็ตาม ข้อกำหนดด้านคุณภาพซอฟต์แวร์อาจมีคุณสมบัติเพิ่มเติมของเกณฑ์เหล่านี้ ซึ่งข้อกำหนดดังกล่าวต้องมีการหารือเป็นพิเศษ คำถามเหล่านี้คือประเด็นสำคัญของการบรรยายนี้ การรับรองเกณฑ์คุณภาพอื่น ๆ จะกล่าวถึงในการบรรยายครั้งต่อไป
บทบัญญัติของ MS Quality Primitives ที่แสดงเกณฑ์สำหรับฟังก์ชันการทำงานและความน่าเชื่อถือของ MS ได้อธิบายไว้ด้านล่าง
11.2. รับรองความสมบูรณ์ของซอฟต์แวร์
ความสมบูรณ์ของ PS เป็นคุณภาพดั้งเดิมของ PS ทั่วไปสำหรับการแสดงทั้งฟังก์ชันการทำงานและความน่าเชื่อถือของ PS และสำหรับฟังก์ชันการทำงาน มันเป็นสิ่งดั้งเดิมเพียงอย่างเดียว (ดูบทบรรยายที่ 4)
ฟังก์ชันการทำงานของ PS ถูกกำหนดโดยข้อกำหนดการทำงาน ความสมบูรณ์ของ PS ในระดับดั้งเดิมของคุณภาพเป็นการวัดว่าข้อกำหนดนี้ถูกนำมาใช้ใน PS ที่กำหนดอย่างไร การให้แบบดั้งเดิมนี้อย่างเต็มรูปแบบหมายถึงการใช้แต่ละฟังก์ชันที่กำหนดไว้ในข้อกำหนดการทำงาน โดยมีรายละเอียดและคุณสมบัติทั้งหมดระบุไว้ที่นั่น กระบวนการทางเทคโนโลยีที่กล่าวถึงก่อนหน้านี้ทั้งหมดแสดงให้เห็นว่าสามารถทำได้อย่างไร
อย่างไรก็ตาม สามารถกำหนดการใช้งานฟังก์ชันการทำงานของ PS ได้หลายระดับในข้อกำหนดคุณภาพ PS: สามารถกำหนดบางเวอร์ชันที่เรียบง่าย (เริ่มต้นหรือเริ่มต้น) ซึ่งต้องใช้งานก่อน และยังสามารถกำหนดเวอร์ชันกลางได้หลายเวอร์ชัน ในกรณีนี้ปัญหาทางเทคโนโลยีเพิ่มเติมเกิดขึ้น: องค์กรของการเพิ่มฟังก์ชันการทำงานของ PS โปรดทราบว่าการพัฒนา PS เวอร์ชันที่เรียบง่ายไม่ใช่การพัฒนาต้นแบบ กำลังพัฒนาต้นแบบเพื่อให้เข้าใจเงื่อนไขการใช้งาน PS ในอนาคตได้ดีขึ้นเพื่ออธิบายคำอธิบายภายนอก ได้รับการออกแบบมาสำหรับผู้ใช้ที่เลือก ดังนั้นอาจแตกต่างอย่างมากจาก PS ที่จำเป็น ไม่เพียงแต่ในฟังก์ชันที่ทำเท่านั้น แต่ยังรวมถึงคุณลักษณะของอินเทอร์เฟซผู้ใช้ด้วย เวอร์ชันที่เรียบง่ายของ PS ที่จำเป็นควรได้รับการออกแบบสำหรับการใช้งานจริงโดยผู้ใช้ที่ต้องการ ดังนั้น หลักการสำคัญสำหรับการรับรองการทำงานของ OS ดังกล่าวคือการพัฒนา OS ตั้งแต่เริ่มต้นในลักษณะที่เหมือนกับว่าจำเป็นต้องใช้ทั้ง OS จนกว่าผู้พัฒนาจะจัดการกับส่วนหรือรายละเอียดของ OS เหล่านั้น การติดตั้งใช้งาน ซึ่งสามารถเลื่อนออกไปได้ตามข้อกำหนดคุณภาพ ดังนั้นทั้งคำอธิบายภายนอกและคำอธิบายของสถาปัตยกรรม PS จะต้องได้รับการพัฒนาอย่างครบถ้วน เป็นไปได้ที่จะเลื่อนเฉพาะการใช้งานระบบย่อยของซอฟต์แวร์ที่กำหนดไว้ในสถาปัตยกรรมของ PS ที่พัฒนาแล้ว ซึ่งการทำงานดังกล่าวไม่จำเป็นในเวอร์ชันเริ่มต้นของ PS นี้ การนำระบบย่อยของซอฟต์แวร์ไปใช้เองนั้นทำได้ดีที่สุดโดยวิธีการนำไปใช้อย่างสร้างสรรค์โดยมีจุดประสงค์ โดยปล่อยไว้ในเวอร์ชันเริ่มต้นของ PS จำลองที่เหมาะสมของโมดูลซอฟต์แวร์เหล่านั้นซึ่งไม่จำเป็นในเวอร์ชันนี้ การใช้งานแบบง่ายของโมดูลซอฟต์แวร์บางตัวก็เป็นที่ยอมรับเช่นกัน ละเว้นการใช้งานรายละเอียดบางอย่างของฟังก์ชันที่เกี่ยวข้อง อย่างไรก็ตาม จากมุมมองทางเทคโนโลยี เป็นการดีกว่าที่จะพิจารณาโมดูลดังกล่าวว่าเป็นตัวลอกเลียนแบบดั้งเดิม (แม้ว่าจะเป็นโมดูลขั้นสูงก็ตาม)
เนื่องจากข้อผิดพลาดใน PS ที่พัฒนาขึ้น ความสมบูรณ์ที่ได้รับในการรับรองฟังก์ชันการทำงาน (ตามข้อกำหนดคุณภาพ) อาจไม่เป็นไปตามที่คาดไว้ เราสามารถพูดได้เพียงว่าความสมบูรณ์นี้เกิดขึ้นได้ด้วยความน่าจะเป็นที่กำหนดโดยปริมาณและคุณภาพของการทดสอบ เพื่อเพิ่มความน่าจะเป็นนี้ จำเป็นต้องดำเนินการทดสอบและดีบัก PS ต่อไป อย่างไรก็ตาม การประมาณค่าความน่าจะเป็นดังกล่าวเป็นงานที่เฉพาะเจาะจงมาก (โดยคำนึงถึงข้อเท็จจริงที่ว่าการสำแดงข้อผิดพลาดใน PS เป็นหน้าที่ของข้อมูลเริ่มต้น) ซึ่งยังรอการศึกษาทางทฤษฎีที่เหมาะสมอยู่
11.3. รับรองความถูกต้องของเครื่องมือซอฟต์แวร์
การให้แบบดั้งเดิมนี้เชื่อมโยงกับการดำเนินการกับค่าของประเภทจริง (แม่นยำยิ่งขึ้นโดยมีค่าที่แสดงด้วยข้อผิดพลาด) เพื่อให้มั่นใจถึงความถูกต้องที่จำเป็นเมื่อคำนวณค่าของฟังก์ชันเฉพาะ เพื่อให้ได้ค่านี้โดยมีข้อผิดพลาดไม่เกินขีดจำกัดที่ระบุ ประเภทของข้อผิดพลาด วิธีการประมาณค่า และวิธีการเพื่อให้ได้ความแม่นยำที่ต้องการ (ที่เรียกว่าการคำนวณโดยประมาณ) จะจัดการโดยการคำนวณทางคณิตศาสตร์ ที่นี่เราให้ความสนใจเฉพาะโครงสร้างข้อผิดพลาดบางอย่าง: ข้อผิดพลาดของค่าที่คำนวณได้ (ข้อผิดพลาดทั้งหมด) ขึ้นอยู่กับ
เกี่ยวกับข้อผิดพลาดของวิธีการคำนวณที่ใช้ (ซึ่งเราได้รวมความไม่ถูกต้องของแบบจำลองที่ใช้ไว้ด้วย)
จากความผิดพลาดในการนำเสนอข้อมูลที่ใช้ (จากที่เรียกว่า fatal error)
จากข้อผิดพลาดในการปัดเศษ (ความไม่ถูกต้องในการดำเนินการของการดำเนินการที่ใช้ในวิธีการ)
11.4. รับประกันความเป็นอิสระของซอฟต์แวร์
คุณภาพดั้งเดิมนี้มีให้ในขั้นตอนของข้อกำหนดคุณภาพโดยการตัดสินใจว่าจะใช้ซอฟต์แวร์พื้นฐานที่เหมาะสมใน PS ที่พัฒนาหรือไม่ใช้ซอฟต์แวร์พื้นฐานใดๆ ในนั้น ในขณะเดียวกันก็จำเป็นต้องคำนึงถึงทั้งความน่าเชื่อถือและทรัพยากรที่จำเป็นสำหรับการใช้งาน ด้วยข้อกำหนดที่เพิ่มขึ้นสำหรับความน่าเชื่อถือของ PS ที่พัฒนาแล้ว ความน่าเชื่อถือของซอฟต์แวร์พื้นฐานที่มีให้สำหรับนักพัฒนาอาจกลายเป็นสิ่งที่ไม่น่าพอใจ ดังนั้น การใช้งานจะต้องถูกยกเลิก และการใช้งานฟังก์ชั่นของมันในปริมาณที่กำหนดจะต้องรวมอยู่ใน ปล. การตัดสินใจในลักษณะเดียวกันนี้ต้องทำภายใต้ข้อจำกัดที่รุนแรงเกี่ยวกับทรัพยากรที่ใช้ (ตามเกณฑ์ประสิทธิภาพ PS)
11.5. รับประกันความยั่งยืนของซอฟต์แวร์
แบบดั้งเดิมที่มีคุณภาพนี้มีให้ด้วยความช่วยเหลือของโปรแกรมป้องกันที่เรียกว่า โดยทั่วไปแล้ว การตั้งโปรแกรมป้องกันจะใช้เพื่อปรับปรุงความน่าเชื่อถือของ MS เมื่อตั้งโปรแกรมโมดูลในความหมายที่กว้างขึ้น ดังที่ไมเยอร์สกล่าวไว้ว่า "การตั้งโปรแกรมป้องกันขึ้นอยู่กับหลักฐานที่สำคัญ: สิ่งที่แย่ที่สุดที่โมดูลสามารถทำได้คือยอมรับอินพุตที่ไม่ถูกต้อง แล้วส่งคืนผลลัพธ์ที่ไม่ถูกต้องแต่เป็นไปได้" เพื่อหลีกเลี่ยงปัญหานี้ ข้อความของโมดูลรวมถึงการตรวจสอบข้อมูลอินพุตและเอาต์พุตเพื่อความถูกต้องตามข้อกำหนดของโมดูลนี้ โดยเฉพาะอย่างยิ่ง การปฏิบัติตามข้อจำกัดของข้อมูลอินพุตและเอาต์พุตและความสัมพันธ์ระหว่างกัน ระบุในข้อมูลจำเพาะของโมดูลควรตรวจสอบ ในกรณีที่ผลการตรวจสอบเป็นลบ ข้อยกเว้นที่เกี่ยวข้องจะถูกยกขึ้น ในเรื่องนี้ ชิ้นส่วนของประเภทที่สองจะรวมอยู่ในส่วนท้ายของโมดูลนี้ - ตัวจัดการของสถานการณ์พิเศษที่สอดคล้องกัน ซึ่งนอกเหนือจากการออกข้อมูลการวินิจฉัยที่จำเป็นแล้ว ยังสามารถใช้มาตรการเพื่อกำจัดข้อผิดพลาดในข้อมูล (ตัวอย่างเช่น จำเป็นต้องป้อนใหม่อีกครั้ง) หรือเพื่อลดผลกระทบของข้อผิดพลาด (เช่น ซอฟต์สต็อปของอุปกรณ์ที่ควบคุมโดย PS เพื่อหลีกเลี่ยงการพังทลายในกรณีที่การดำเนินการโปรแกรมยุติลงอย่างฉุกเฉิน)
การใช้การเขียนโปรแกรมป้องกันของโมดูลทำให้ประสิทธิภาพของ PS ลดลงทั้งในด้านเวลาและในหน่วยความจำ ดังนั้นจึงจำเป็นต้องควบคุมระดับของการใช้โปรแกรมป้องกันอย่างสมเหตุสมผล ทั้งนี้ขึ้นอยู่กับข้อกำหนดสำหรับความน่าเชื่อถือและประสิทธิภาพของ PS ซึ่งกำหนดไว้ในข้อกำหนดคุณภาพของ PS ที่พัฒนาแล้ว ข้อมูลอินพุตของโมดูลที่พัฒนาขึ้นอาจมาจากผู้ใช้โดยตรงหรือจากโมดูลอื่น กรณีที่พบบ่อยที่สุดของการใช้โปรแกรมป้องกันคือการใช้งานสำหรับข้อมูลกลุ่มแรก ซึ่งหมายถึงการตระหนักถึงความเสถียรของ PS ควรทำเมื่อใดก็ตามที่ข้อกำหนดด้านคุณภาพของ PS มีข้อกำหนดเพื่อให้มั่นใจถึงเสถียรภาพของ PS การใช้การเขียนโปรแกรมเชิงป้องกันสำหรับข้อมูลอินพุตกลุ่มที่สองหมายถึงความพยายามในการตรวจหาข้อผิดพลาดในโมดูลอื่นระหว่างการดำเนินการของโมดูลที่พัฒนาแล้ว และสำหรับข้อมูลเอาต์พุตของโมดูลที่พัฒนาแล้ว ความพยายามในการตรวจหาข้อผิดพลาดในตัวโมดูลเอง ในระหว่างการดำเนินการ โดยพื้นฐานแล้ว นี่หมายถึงการนำวิธีการตรวจจับข้อผิดพลาดด้วยตนเองไปใช้บางส่วนเพื่อให้มั่นใจในความน่าเชื่อถือของซอฟต์แวร์ ซึ่งได้กล่าวถึงในการบรรยายครั้งที่ 3 กรณีของการตั้งโปรแกรมเชิงป้องกันนี้จะใช้น้อยมาก - เฉพาะเมื่อข้อกำหนดสำหรับความน่าเชื่อถือของซอฟต์แวร์ สูงมาก
11.6. มั่นใจในความปลอดภัยของซอฟต์แวร์
ประเภทของการป้องกัน PS จากการบิดเบือนข้อมูลมีดังต่อไปนี้:
การป้องกันความล้มเหลวของฮาร์ดแวร์
การป้องกันจากอิทธิพลของโปรแกรม "ต่างประเทศ"
การป้องกันความล้มเหลวของโปรแกรม "ของตัวเอง"
การป้องกันข้อผิดพลาดของผู้ปฏิบัติงาน (ผู้ใช้);
การป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
การป้องกันการป้องกัน
การป้องกันความล้มเหลวของฮาร์ดแวร์ไม่ใช่งานเร่งด่วนในขณะนี้ (โดยคำนึงถึงระดับความน่าเชื่อถือของคอมพิวเตอร์ที่ได้รับ) แต่ก็ยังมีประโยชน์ที่จะรู้วิธีแก้ปัญหาของเธอ สิ่งนี้รับรองโดยองค์กรของสิ่งที่เรียกว่า "การคำนวณผิดสองครั้งสามครั้ง" ในการทำเช่นนี้ กระบวนการประมวลผลข้อมูลทั้งหมดที่กำหนดโดย PS จะถูกแบ่งเวลาออกเป็นช่วงๆ โดยเรียกว่า "จุดอ้างอิง" ความยาวของช่วงเวลานี้ไม่ควรเกินครึ่งหนึ่งของเวลาทำงานเฉลี่ยของคอมพิวเตอร์ สำเนาของสถานะของหน่วยความจำที่เปลี่ยนแปลงในกระบวนการนี้สำหรับแต่ละจุดอ้างอิงจะถูกเขียนไปยังหน่วยความจำรองด้วยการตรวจสอบบางอย่าง (ตัวเลขที่คำนวณเป็นฟังก์ชันของสถานะนี้) ในกรณีที่จะพิจารณาว่าการประมวลผลข้อมูลจาก จุดอ้างอิงก่อนหน้าของจุดอ้างอิงนี้ (เช่น . "การคำนวณผิด") หนึ่งรายการทำอย่างถูกต้อง (โดยคอมพิวเตอร์ไม่ขัดข้อง) เพื่อค้นหาว่ามีการทำ "การคำนวณผิด" สองครั้ง หลังจาก "การคำนวณ" ครั้งแรก เช็คซัมที่ระบุจะถูกคำนวณและจัดเก็บ จากนั้นสถานะหน่วยความจำสำหรับจุดอ้างอิงก่อนหน้าจะถูกกู้คืนและ "การคำนวณ" ครั้งที่สองจะถูกสร้างขึ้น หลังจาก "คำนวณผิด" ครั้งที่สอง จะมีการคำนวณผลรวมตรวจสอบที่ระบุอีกครั้ง ซึ่งจะเปรียบเทียบกับผลรวมตรวจสอบของ "การคำนวณผิด" ครั้งแรก หากผลรวมการตรวจสอบทั้งสองนี้ตรงกัน การคำนวณครั้งที่สองจะถือว่าถูกต้อง มิฉะนั้น ผลรวมการตรวจสอบของ "การคำนวณ" ที่สองจะถูกเก็บไว้ด้วย และดำเนินการ "การคำนวณ" ครั้งที่สาม (โดยมีการกู้คืนสถานะหน่วยความจำเบื้องต้นสำหรับจุดอ้างอิงก่อนหน้า) หากผลรวมการตรวจสอบของ "การคำนวณผิดพลาด" ครั้งที่สามตรงกับผลรวมการตรวจสอบของ "การคำนวณผิดพลาด" หนึ่งในสองรายการแรก ดังนั้นการคำนวณผิดพลาดครั้งที่สามจะถือว่าถูกต้อง มิฉะนั้น จำเป็นต้องมีการตรวจสอบทางวิศวกรรมของคอมพิวเตอร์
การป้องกันจากอิทธิพลของโปรแกรม "ต่างประเทศ" หมายถึงระบบปฏิบัติการหรือโปรแกรมที่ทำหน้าที่บางส่วนเป็นหลัก การป้องกันนี้มีสองประเภท:
การป้องกันความล้มเหลว,
การป้องกันอิทธิพลที่เป็นอันตรายของโปรแกรม "ต่างประเทศ"
เมื่อโหมดการทำงานหลายโปรแกรมของคอมพิวเตอร์ปรากฏขึ้น โปรแกรมหลายโปรแกรมสามารถทำงานพร้อมกันในหน่วยความจำ โดยสลับกันรับการควบคุมอันเป็นผลมาจากการขัดจังหวะ (ที่เรียกว่าการดำเนินการโปรแกรมกึ่งคู่ขนาน) หนึ่งในโปรแกรมเหล่านี้ (โดยปกติ: ระบบปฏิบัติการ) จัดการการขัดจังหวะและจัดการการเขียนโปรแกรมหลายโปรแกรม ในแต่ละโปรแกรมเหล่านี้ ความล้มเหลวอาจเกิดขึ้น (ข้อผิดพลาดปรากฏขึ้น) ซึ่งอาจส่งผลต่อประสิทธิภาพการทำงานของฟังก์ชันโดยโปรแกรมอื่น ดังนั้นโปรแกรมควบคุม (ระบบปฏิบัติการ) จะต้องป้องกันตัวเองและโปรแกรมอื่น ๆ จากอิทธิพลดังกล่าว ในการทำเช่นนี้ ฮาร์ดแวร์คอมพิวเตอร์จะต้องใช้คุณลักษณะต่อไปนี้:
การป้องกันหน่วยความจำ,
การทำงานของคอมพิวเตอร์สองโหมด: สิทธิพิเศษและการทำงาน (ผู้ใช้)
การทำธุรกรรมสองประเภท: สิทธิพิเศษและธรรมดา
การใช้งานอินเทอร์รัปต์ที่ถูกต้องและการเริ่มต้นคอมพิวเตอร์เบื้องต้น
การหยุดชะงักชั่วคราว
การป้องกันหน่วยความจำหมายถึงความสามารถในการตั้งค่าทางโปรแกรมสำหรับแต่ละพื้นที่โปรแกรมของหน่วยความจำที่ไม่สามารถเข้าถึงได้ ในโหมดสิทธิพิเศษ การดำเนินการใด ๆ (ทั้งแบบธรรมดาและแบบมีสิทธิพิเศษ) สามารถดำเนินการได้ และในโหมดรัน จะดำเนินการได้เฉพาะแบบธรรมดาเท่านั้น ความพยายามที่จะดำเนินการพิเศษ เช่นเดียวกับการเข้าถึงหน่วยความจำที่ได้รับการป้องกันในโหมดการทำงาน ทำให้เกิดการขัดจังหวะที่เกี่ยวข้อง ยิ่งไปกว่านั้น การดำเนินการที่ได้รับสิทธิพิเศษยังรวมถึงการดำเนินการเพื่อเปลี่ยนการป้องกันหน่วยความจำและโหมดการทำงาน ตลอดจนการเข้าถึงสภาพแวดล้อมข้อมูลภายนอก การเปิดเครื่องครั้งแรกของคอมพิวเตอร์และการขัดจังหวะใด ๆ ควรเปิดใช้งานโหมดสิทธิพิเศษโดยอัตโนมัติและแทนที่การป้องกันหน่วยความจำ ในกรณีนี้ โปรแกรมควบคุม (ระบบปฏิบัติการ) สามารถป้องกันตัวเองจากอิทธิพลของโปรแกรมอื่นได้อย่างสมบูรณ์ หากจุดถ่ายโอนการควบคุมทั้งหมดที่เปิดเครื่องครั้งแรกและการขัดจังหวะเป็นของโปรแกรมนี้ หากไม่อนุญาตให้โปรแกรมอื่นทำงาน โหมดสิทธิพิเศษ (เมื่อการควบคุมถูกถ่ายโอนไปยังโปรแกรมอื่น ๆ โปรแกรมจะเปิดเฉพาะโหมดการทำงานเท่านั้น) และหากโปรแกรมดังกล่าวปกป้องหน่วยความจำอย่างสมบูรณ์ (โดยเฉพาะอย่างยิ่ง ข้อมูลการควบคุมทั้งหมด รวมทั้งสิ่งที่เรียกว่าอินเทอร์รัปต์เวคเตอร์) จากโปรแกรมอื่น ๆ จากนั้นจะไม่มีใครป้องกันไม่ให้ทำหน้าที่ป้องกันใด ๆ ที่ใช้ในโปรแกรมอื่น (รวมถึงการเข้าถึงสภาพแวดล้อมข้อมูลภายนอก) เพื่ออำนวยความสะดวกในการแก้ปัญหานี้ ส่วนหนึ่งของโปรแกรมดังกล่าวจะอยู่ในหน่วยความจำถาวร เช่น แยกออกจากตัวคอมพิวเตอร์ไม่ได้ การมีอยู่ของอินเตอร์รัปต์ชั่วคราวทำให้โปรแกรมควบคุมสามารถป้องกันตัวเองจากการวนลูปในโปรแกรมอื่น (หากปราศจากการขัดจังหวะ ก็อาจสูญเสียความสามารถในการควบคุมได้)
การป้องกันความล้มเหลวของโปรแกรม "ของตัวเอง" นั้นรับประกันได้จากความน่าเชื่อถือของโปรแกรมนี้ ซึ่งเป็นจุดเน้นของเทคโนโลยีการเขียนโปรแกรมทั้งหมดที่กล่าวถึงในหลักสูตรการบรรยายนี้
การป้องกันข้อผิดพลาดของผู้ใช้ (นอกเหนือจากข้อผิดพลาดในการป้อนข้อมูล โปรดดูที่การรับประกันความเสถียรของ PS) โดยการออกข้อความเตือนเกี่ยวกับความพยายามที่จะเปลี่ยนสถานะของสภาพแวดล้อมข้อมูลภายนอกพร้อมข้อกำหนดเพื่อยืนยันการดำเนินการเหล่านี้ ตลอดจนความสามารถในการกู้คืน สถานะของแต่ละส่วนประกอบของสภาพแวดล้อมข้อมูลภายนอก หลังขึ้นอยู่กับการใช้งานการเปลี่ยนแปลงการเก็บถาวรในสถานะของสภาพแวดล้อมข้อมูลภายนอก
การป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตมีให้โดยการใช้คำลับ (รหัสผ่าน) ในกรณีนี้ ผู้ใช้แต่ละรายจะได้รับข้อมูลบางอย่างและทรัพยากรขั้นตอน (บริการ) ซึ่งผู้ใช้รายนี้จำเป็นต้องแสดงรหัสผ่านให้กับ PS ซึ่งผู้ใช้รายนี้ได้ลงทะเบียนไว้ก่อนหน้านี้ใน PS กล่าวอีกนัยหนึ่งคือผู้ใช้ "แฮงก์ล็อค" บนทรัพยากรที่จัดสรรให้กับเขาซึ่งเป็น "คีย์" ที่ผู้ใช้รายนี้มีเท่านั้น อย่างไรก็ตาม อาจมีความพยายามอย่างต่อเนื่องที่จะทำลายการป้องกันดังกล่าวในแต่ละกรณี หากทรัพยากรที่ได้รับการปกป้องนั้นมีค่ามากสำหรับใครบางคน ในกรณีเช่นนี้ ต้องใช้มาตรการเพิ่มเติมเพื่อป้องกันการละเมิดความปลอดภัย
การป้องกันการละเมิดความปลอดภัยเกี่ยวข้องกับการใช้เทคนิคการเขียนโปรแกรมพิเศษใน PS ซึ่งทำให้ยากต่อการเอาชนะการป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต การใช้รหัสผ่านธรรมดานั้นไม่เพียงพอสำหรับความปรารถนาที่คงอยู่อย่างถาวร (เช่น ในลักษณะที่เป็นอาชญากร) เพื่อเข้าถึงข้อมูลที่มีค่า ประการแรก เนื่องจากข้อมูลเกี่ยวกับรหัสผ่านที่ PS ใช้เพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตสามารถรับได้ค่อนข้างง่ายโดย "แคร็กเกอร์" ของการป้องกันนี้ หากเขาสามารถเข้าถึง PS นี้ได้ ประการที่สองการใช้คอมพิวเตอร์เป็นไปได้ที่จะทำการแจกแจงรหัสผ่านที่เป็นไปได้จำนวนมากพอสมควรเพื่อค้นหารหัสผ่านที่เหมาะสมสำหรับการเข้าถึงข้อมูลที่น่าสนใจ คุณสามารถป้องกันตัวเองจากการถูกแฮ็กด้วยวิธีต่อไปนี้ คำลับ (รหัสผ่าน) หรือเลขจำนวนเต็มลับ X เท่านั้นที่ทราบโดยเจ้าของข้อมูลที่ได้รับการป้องกันเท่านั้น และเพื่อตรวจสอบสิทธิ์ในการเข้าถึง หมายเลขอื่น Y=F(X) จะถูกเก็บไว้ในคอมพิวเตอร์ ซึ่งคำนวณโดยไม่ซ้ำกันโดย ป.ล. ทุกครั้งที่มีการพยายามเข้าถึงข้อมูลนี้เมื่อมีการนำเสนอคำลับ ในเวลาเดียวกัน ฟังก์ชัน F สามารถเป็นที่รู้จักกันดีสำหรับผู้ใช้ PS ทุกคน แต่มีคุณสมบัติดังกล่าวซึ่งเป็นไปไม่ได้ที่จะกู้คืนคำว่า X จาก Y ด้วยความยาวที่เพียงพอของคำว่า X (ตัวอย่างเช่น หลายร้อยตัวอักษร ) ซึ่งต้องใช้เวลาทางดาราศาสตร์ หมายเลข Y ดังกล่าวจะเรียกว่าลายเซ็นอิเล็กทรอนิกส์ (คอมพิวเตอร์) ของเจ้าของคำลับ X (และด้วยเหตุนี้ข้อมูลที่ได้รับการคุ้มครอง)
การป้องกันประเภทอื่นเกี่ยวข้องกับการป้องกันข้อความที่ส่งผ่านเครือข่ายคอมพิวเตอร์ การบิดเบือนโดยเจตนา (หรือประสงค์ร้าย) ข้อความดังกล่าวสามารถดักจับได้ที่จุด "ถ่ายโอน" ของเครือข่ายคอมพิวเตอร์ และแทนที่ด้วยข้อความอื่นจากผู้เขียนข้อความที่ถูกสกัดกั้น สถานการณ์นี้เกิดขึ้นเป็นหลักในการดำเนินงานธนาคารโดยใช้เครือข่ายคอมพิวเตอร์ โดยการแทนที่ข้อความดังกล่าวซึ่งเป็นคำสั่งจากเจ้าของบัญชีธนาคารเพื่อดำเนินการด้านการธนาคาร เงินจากบัญชีของเขาสามารถโอนไปยังบัญชีของการป้องกัน "แฮ็กเกอร์" (การโจรกรรมธนาคารทางคอมพิวเตอร์ชนิดหนึ่ง) การป้องกันการละเมิดความปลอดภัยสามารถทำได้ดังนี้ พร้อมกับฟังก์ชัน F ซึ่งกำหนดลายเซ็นคอมพิวเตอร์ของเจ้าของคำลับ X ซึ่งผู้รับข้อความที่มีการป้องกันรู้จัก (หากเจ้าของเท่านั้นที่เป็นไคลเอนต์ของผู้รับนี้) ฟังก์ชัน Stamp อื่นถูกกำหนดไว้ใน ป.ล. ซึ่งผู้ส่งข้อความต้องคำนวณตัวเลข S=Stamp(X,R ) โดยใช้คำลับ X และข้อความของข้อความที่ส่ง R ฟังก์ชัน Stamp ถือว่าเป็นที่รู้จักกันดีสำหรับผู้ใช้ MS ทุกคนและมีคุณสมบัติดังกล่าว คุณสมบัติที่ไม่สามารถกู้คืนหมายเลข X จาก S หรือเลือกข้อความอื่น R ด้วยลายเซ็นคอมพิวเตอร์ที่เกี่ยวข้อง ข้อความที่ส่งเอง (พร้อมกับการป้องกัน) ควรมีลักษณะดังนี้:
ยิ่งกว่านั้น Y (ลายเซ็นคอมพิวเตอร์) อนุญาตให้ผู้รับสร้างความจริงของลูกค้าและ S เหมือนเดิม ยึดข้อความป้องกัน R ด้วยลายเซ็นคอมพิวเตอร์ Y ในเรื่องนี้เราจะเรียกหมายเลข S ว่าอิเล็กทรอนิกส์ (คอมพิวเตอร์ ) ผนึก. PS กำหนดหน้าที่รับรองเอกสารอีกหนึ่งหน้าที่ ซึ่งผู้รับข้อความที่ได้รับความคุ้มครองจะตรวจสอบความจริงของข้อความที่ส่ง:
สิ่งนี้ช่วยให้คุณระบุได้อย่างชัดเจนว่าข้อความ R เป็นของเจ้าของคำลับ X
การป้องกันจากการป้องกันเป็นสิ่งจำเป็นในกรณีที่ผู้ใช้ลืมรหัสผ่าน (หรือทำหาย) ในกรณีเช่นนี้ ผู้ใช้พิเศษ (ผู้ดูแลระบบ PS) ที่รับผิดชอบการทำงานของระบบป้องกันควรสามารถถอดการป้องกันชั่วคราวจากการเข้าถึงโดยไม่ได้รับอนุญาตสำหรับเจ้าของได้ ลืมรหัสผ่านเพื่อให้เขามีโอกาสแก้ไขรหัสผ่านใหม่
วรรณกรรมประกอบการบรรยาย11.
11.1. เป็น. เบเรซิน, N.P. Zhidkov วิธีการคำนวณฉบับ 1 และ 2 - ม.: Fizmatgiz, 1959
11.2. น.ส. Bakhvalov, N.P. Zhidkov, G.M. โคเบลคอฟ วิธีการเชิงตัวเลข - ม.: Nauka, 1987.
11.3. จี. ไมเออร์. ความน่าเชื่อถือของซอฟต์แวร์ - ม.: มีร์ 2523 ส. 127-154
11.4. หนึ่ง. เลเบเดฟ การปกป้องข้อมูลธนาคารและการเข้ารหัสสมัยใหม่//ปัญหาความปลอดภัยของข้อมูล 2(29), 1995
การบรรยาย 12. การประกันคุณภาพซอฟต์แวร์
12.1. ลักษณะทั่วไปของกระบวนการประกันคุณภาพซอฟต์แวร์
ตามที่ระบุไว้แล้วในบทที่ 4 ข้อกำหนดด้านคุณภาพกำหนดแนวทางหลัก (เป้าหมาย) ซึ่งในทุกขั้นตอนของการพัฒนา PS ไม่ทางใดก็ทางหนึ่งจะมีอิทธิพลต่อการเลือกตัวเลือกที่เหมาะสมเมื่อทำการตัดสินใจต่างๆ อย่างไรก็ตาม คุณภาพดั้งเดิมแต่ละชนิดมีลักษณะเฉพาะของอิทธิพลดังกล่าว ดังนั้น การรับประกันว่ามีอยู่ใน PS อาจต้องใช้แนวทางและวิธีการของตนเองในการพัฒนา PS หรือแต่ละส่วน นอกจากนี้ยังสังเกตเห็นความไม่สอดคล้องกันของเกณฑ์คุณภาพ PS และคุณภาพดั้งเดิมที่แสดงออกมา: การจัดหาหนึ่งในคุณภาพดั้งเดิมของ PS ที่ดีอาจทำให้ซับซ้อนหรือทำให้ไม่สามารถจัดหาสิ่งดั้งเดิมอื่นๆ บางอย่างได้ ดังนั้น ส่วนสำคัญของกระบวนการรับประกันคุณภาพของ PS จึงประกอบด้วยการหาจุดแลกเปลี่ยนที่ยอมรับได้ การแลกเปลี่ยนเหล่านี้ควรได้รับการกำหนดไว้บางส่วนแล้วในข้อกำหนดคุณภาพ PS: แบบจำลองคุณภาพ PS ควรระบุระดับการมีอยู่ที่จำเป็นใน PS ของคุณสมบัติพื้นฐานคุณภาพแต่ละรายการ และกำหนดลำดับความสำคัญเพื่อให้บรรลุระดับเหล่านี้
การประกันคุณภาพจะดำเนินการในแต่ละกระบวนการทางเทคโนโลยี: การตัดสินใจที่เกิดขึ้นในระดับใดระดับหนึ่งจะส่งผลต่อคุณภาพของซอฟต์แวร์โดยรวม โดยเฉพาะอย่างยิ่งเนื่องจากส่วนสำคัญของคุณภาพดั้งเดิมนั้นไม่เกี่ยวข้องกับคุณสมบัติของโปรแกรมที่รวมอยู่ใน PS มากนัก แต่เกี่ยวข้องกับคุณสมบัติของเอกสารประกอบ เนื่องจากความไม่สอดคล้องกันของคุณภาพดั้งเดิม จึงเป็นสิ่งสำคัญอย่างยิ่งที่จะต้องปฏิบัติตามลำดับความสำคัญที่เลือกไว้ในข้อกำหนด แต่ไม่ว่าในกรณีใด การปฏิบัติตามหลักการทั่วไปสองประการจะเป็นประโยชน์:
ประการแรก จำเป็นต้องตรวจสอบการทำงานที่จำเป็นและความน่าเชื่อถือของ PS จากนั้นนำเกณฑ์คุณภาพที่เหลือไปสู่ระดับที่ยอมรับได้ใน PS
ไม่มีความจำเป็นและอาจเป็นอันตรายด้วยซ้ำที่จะแสวงหาการแสดงตนในระดับที่สูงขึ้นใน PS ของคุณภาพดั้งเดิมใดๆ ที่มากกว่าที่กำหนดไว้ในข้อกำหนดคุณภาพ PS
การตรวจสอบการทำงานและความน่าเชื่อถือของ PS ได้รับการพิจารณาในการบรรยายครั้งก่อน ข้อกำหนดของเกณฑ์คุณภาพ OS อื่นๆ จะกล่าวถึงด้านล่าง
12.2. สร้างความมั่นใจในความสะดวกในการใช้เครื่องมือซอฟต์แวร์
เอกสาร P ของ PS กำหนดองค์ประกอบของเอกสารผู้ใช้
ในการบรรยายครั้งก่อน ได้มีการพิจารณาคุณสมบัติเบื้องต้นด้านคุณภาพสองในห้าประการ (ความเสถียรและความปลอดภัย) ที่กำหนดความสะดวกในการใช้งาน PS
เอกสาร P และข้อมูลจะเป็นตัวกำหนดองค์ประกอบและคุณภาพของเอกสารผู้ใช้ (ดูการบรรยายถัดไป)
การสื่อสารจะมั่นใจได้โดยการสร้างที่เหมาะสม หน้าจอผู้ใช้และการจัดการข้อยกเว้นที่เกี่ยวข้อง มีปัญหาอะไรที่นี่?
12.3. มั่นใจในประสิทธิภาพของซอฟต์แวร์
ประสิทธิภาพของ PS นั้นรับประกันได้จากการตัดสินใจที่เหมาะสมในขั้นตอนต่างๆ ของการพัฒนา โดยเริ่มจากการพัฒนาสถาปัตยกรรม การเลือกโครงสร้างข้อมูลและการนำเสนอส่งผลต่อประสิทธิภาพของ PS โดยเฉพาะอย่างยิ่ง (โดยเฉพาะในแง่ของหน่วยความจำ) แต่การเลือกอัลกอริธึมที่ใช้ในโมดูลซอฟต์แวร์บางโมดูล ตลอดจนคุณลักษณะของการใช้งาน (รวมถึงการเลือกภาษาโปรแกรม) อาจส่งผลต่อประสิทธิภาพของ PS ได้อย่างมีนัยสำคัญ ในเวลาเดียวกัน เราต้องแก้ไขความขัดแย้งระหว่างประสิทธิภาพชั่วคราวและประสิทธิภาพจากหน่วยความจำอย่างต่อเนื่อง ดังนั้น จึงเป็นสิ่งสำคัญอย่างยิ่งที่ข้อกำหนดด้านคุณภาพจะต้องระบุความสัมพันธ์เชิงปริมาณอย่างชัดเจนระหว่างตัวบ่งชี้ของคุณภาพดั้งเดิมเหล่านี้ หรืออย่างน้อยก็กำหนดขอบเขตเชิงปริมาณสำหรับหนึ่งในตัวบ่งชี้เหล่านี้ และถึงกระนั้น โมดูลซอฟต์แวร์ที่แตกต่างกันก็มีผลแตกต่างกันต่อประสิทธิภาพของ PS โดยรวม ทั้งในแง่ของการมีส่วนร่วมกับต้นทุนรวมของ PS ในแง่ของเวลาและหน่วยความจำ และในแง่ของผลกระทบต่อคุณภาพดั้งเดิมที่แตกต่างกัน (บางโมดูลสามารถส่งผลกระทบอย่างมากต่อความสำเร็จของเวลาอย่างมีประสิทธิภาพ และในทางปฏิบัติจะไม่ส่งผลต่อประสิทธิภาพของหน่วยความจำ ในขณะที่โมดูลอื่น ๆ สามารถส่งผลกระทบต่อการใช้หน่วยความจำโดยรวมได้อย่างมาก โดยไม่ส่งผลกระทบต่อเวลาการทำงานของ PS อย่างมีนัยสำคัญ) ยิ่งไปกว่านั้น ผลกระทบนี้ (โดยหลักในแง่ของประสิทธิภาพเวลา) ล่วงหน้า (ก่อนที่จะเสร็จสิ้นการดำเนินการของ PS) ไม่สามารถประเมินได้อย่างถูกต้องเสมอไป
ก่อนอื่นคุณต้องพัฒนา PS ที่เชื่อถือได้ จากนั้นจึงบรรลุประสิทธิภาพที่ต้องการตามข้อกำหนดคุณภาพของ PS นี้
เพื่อปรับปรุงประสิทธิภาพของ PS ก่อนอื่นให้ใช้คอมไพเลอร์ที่ปรับให้เหมาะสม - สิ่งนี้สามารถให้ประสิทธิภาพที่ต้องการ
หากประสิทธิภาพของ PS ที่ได้รับไม่เป็นไปตามข้อกำหนดด้านคุณภาพ ให้ค้นหาโมดูลที่สำคัญที่สุดในแง่ของประสิทธิภาพที่ต้องการของ PS (ในกรณีของประสิทธิภาพชั่วคราว จะต้องได้รับการแจกจ่ายตามโมดูลของ PS เวลาดำเนินการโดยการวัดที่เหมาะสมระหว่างการดำเนินการของ PS) โมดูลเหล่านี้และพยายามปรับให้เหมาะสมก่อนโดยการแก้ไขด้วยตนเอง
อย่าปรับโมดูลให้เหมาะสมหากไม่จำเป็นเพื่อให้ได้ประสิทธิภาพตามที่ต้องการของ PS
12.4. มั่นใจในการบำรุงรักษา
เอกสาร C เนื้อหาข้อมูลและความสามารถในการเข้าใจกำหนดองค์ประกอบและคุณภาพของเอกสารการบำรุงรักษา (ดูการบรรยายถัดไป) นอกจากนี้ยังสามารถให้คำแนะนำต่อไปนี้เกี่ยวกับข้อความของโปรแกรม (โมดูล)
ใช้ความคิดเห็นในข้อความของโมดูลที่ชี้แจงและอธิบายคุณลักษณะของการตัดสินใจที่กำลังทำอยู่ ถ้าเป็นไปได้ ให้ใส่ความคิดเห็น (อย่างน้อยในรูปแบบสั้นๆ) ในช่วงแรกสุดของการพัฒนาเนื้อหาของโมดูล
ใช้ชื่อที่มีความหมาย (ช่วยจำ) และแยกแยะได้อย่างต่อเนื่อง (ความยาวที่เหมาะสมของชื่อคือ 4-12 ตัวอักษร ตัวเลขอยู่ท้ายสุด) อย่าใช้ชื่อและคำหลักที่คล้ายกัน
ระมัดระวังเมื่อใช้ค่าคงที่ (ค่าคงที่เฉพาะจะต้องมีค่าเดียวในข้อความของโมดูล: เมื่อมีการประกาศหรือในกรณีร้ายแรง เมื่อตัวแปรถูกเตรียมใช้งานเป็นค่าคงที่)
อย่ากลัวที่จะใช้วงเล็บเผื่อเลือก (วงเล็บถูกกว่าจุดบกพร่อง ;
วางไม่เกินหนึ่งคำสั่งต่อบรรทัด; เพื่อชี้แจงโครงสร้างของโมดูลให้ใช้ช่องว่างพิเศษ (เยื้อง) ที่จุดเริ่มต้นของแต่ละบรรทัด ;
หลีกเลี่ยงกลอุบายเช่น เช่น เทคนิคการเขียนโปรแกรมเมื่อมีการสร้างแฟรกเมนต์ของโมดูลซึ่งเอฟเฟกต์หลักไม่ชัดเจนหรือซ่อนเร้น (ปกปิด) เช่น เอฟเฟกต์ข้างเคียงของ
มั่นใจได้ถึงความสามารถในการขยายโดยการสร้างตัวติดตั้งที่เหมาะสม
โครงสร้างและโมดูลาร์ทำให้ทั้งความเข้าใจในข้อความโปรแกรมและการปรับเปลี่ยนง่ายขึ้น
12.5 มั่นใจในความคล่องตัว
วรรณกรรมประกอบการบรรยาย12.
12.1. เอียน ซอมเมอร์วิลล์. วิศวกรรมซอฟต์แวร์. - Addison-Wesley Publishing Company, 1992. หน้า
12.3. ง. ฟาน พู่. รูปแบบ การพัฒนา ประสิทธิภาพ การดีบัก และการทดสอบโปรแกรม - ม.: มีร์ 2528 ส. 8-44, 117-178
12.4. เอกสารคู่มือผู้ใช้ซอฟต์แวร์/มาตรฐาน ANSI/IEEE 1063-1987
การบรรยายครั้งที่ 13
13.1. เอกสารที่สร้างขึ้นระหว่างกระบวนการพัฒนาซอฟต์แวร์
เมื่อพัฒนา PS จะมีการสร้างเอกสารต่างๆ จำนวนมาก มันเป็นสิ่งจำเป็นในการถ่ายโอนข้อมูลระหว่างผู้พัฒนา PS เป็นวิธีการจัดการการพัฒนา PS และเป็นวิธีการส่งข้อมูลที่จำเป็นสำหรับแอปพลิเคชันและการบำรุงรักษา PS ให้กับผู้ใช้ การสร้างเอกสารประกอบนี้คิดเป็นต้นทุนส่วนใหญ่ของ PS
เอกสารนี้สามารถแบ่งออกเป็นสองกลุ่ม:
เอกสารการจัดการการพัฒนา PS.
เอกสารประกอบปล.
เอกสารการจัดการการพัฒนา PS (เอกสารกระบวนการ) บันทึกกระบวนการพัฒนาและบำรุงรักษา PS ให้การสื่อสารภายในทีมพัฒนาและระหว่างทีมพัฒนากับผู้จัดการ (ผู้จัดการ) - บุคคลที่จัดการการพัฒนา เอกสารเหล่านี้สามารถเป็นประเภทต่อไปนี้:
แผน ประมาณการ กำหนดการ. เอกสารเหล่านี้สร้างขึ้นโดยผู้จัดการเพื่อคาดการณ์และจัดการกระบวนการพัฒนาและบำรุงรักษา
รายงานการใช้ทรัพยากรระหว่างการพัฒนา สร้างโดยผู้จัดการ
มาตรฐาน เอกสารเหล่านี้กำหนดไว้สำหรับนักพัฒนาว่าจะต้องปฏิบัติตามหลักการ กฎ และข้อตกลงใดในกระบวนการพัฒนา PS มาตรฐานเหล่านี้สามารถเป็นได้ทั้งในระดับนานาชาติหรือระดับประเทศ หรือสร้างขึ้นเป็นพิเศษสำหรับองค์กรที่กำลังพัฒนา PS นี้
เอกสารการทำงาน. นี่คือเอกสารทางเทคนิคหลักที่ให้การสื่อสารระหว่างนักพัฒนา ประกอบด้วยการแก้ไขความคิดและปัญหาที่เกิดขึ้นระหว่างกระบวนการพัฒนา คำอธิบายของกลยุทธ์และแนวทางที่ใช้ ตลอดจนเอกสารเวอร์ชันการทำงาน (ชั่วคราว) ที่ควรรวมไว้ใน PS
บันทึกและจดหมายโต้ตอบ เอกสารเหล่านี้รวบรวมรายละเอียดต่างๆ ของการโต้ตอบระหว่างผู้จัดการและนักพัฒนา
เอกสารที่รวมอยู่ใน PS (เอกสารประกอบผลิตภัณฑ์) อธิบายถึงโปรแกรม PS ทั้งจากมุมมองของการใช้งานโดยผู้ใช้ และจากมุมมองของนักพัฒนาและผู้ดูแล (ตามวัตถุประสงค์ของ PS) ควรสังเกตว่าเอกสารเหล่านี้จะถูกนำมาใช้ไม่เพียง แต่ในขั้นตอนการทำงานของ PS (ในขั้นตอนการสมัครและการบำรุงรักษา) แต่ยังรวมถึงในขั้นตอนการพัฒนาเพื่อจัดการกระบวนการพัฒนา (พร้อมกับเอกสารการทำงาน) - ในรูปแบบใด ๆ กรณีนี้ควรตรวจสอบ (ทดสอบ) ว่าสอดคล้องกับโปรแกรม PS เอกสารเหล่านี้ประกอบขึ้นเป็นสองชุดโดยมีจุดประสงค์ต่างกัน:
เอกสารผู้ใช้ PS (เอกสาร P)
เอกสารสำหรับการสนับสนุนของ PS (เอกสาร C)
13.2. เอกสารผู้ใช้ซอฟต์แวร์
เอกสารคู่มือผู้ใช้ของ PS (เอกสารคู่มือผู้ใช้) อธิบายให้ผู้ใช้ทราบว่าพวกเขาต้องดำเนินการอย่างไรเพื่อใช้ PS นี้ จำเป็นหาก PS เกี่ยวข้องกับการโต้ตอบกับผู้ใช้ เอกสารดังกล่าวรวมถึงเอกสารที่แนะนำผู้ใช้เมื่อติดตั้ง PS (เมื่อติดตั้ง PS ด้วยการตั้งค่าที่เหมาะสมสำหรับสภาพแวดล้อมสำหรับการใช้ PS) เมื่อใช้ PS เพื่อแก้ปัญหาและเมื่อจัดการ PS (เช่น เมื่อ PS นี้ โต้ตอบกับระบบอื่น) เอกสารเหล่านี้ครอบคลุมประเด็นการสนับสนุนซอฟต์แวร์บางส่วน แต่ไม่เกี่ยวข้องกับปัญหาที่เกี่ยวข้องกับการปรับเปลี่ยนโปรแกรม
ในเรื่องนี้ ควรแยกแยะผู้ใช้ PS สองประเภท: ผู้ใช้ PS ทั่วไปและผู้ดูแลระบบ PS ผู้ใช้ทั่วไปของ PS (ผู้ใช้ปลายทาง) ใช้ PS เพื่อแก้ปัญหาของเขา (ในสาขาวิชาของเขา) ซึ่งอาจเป็นวิศวกรออกแบบอุปกรณ์ทางเทคนิค หรือแคชเชียร์ขายตั๋วรถไฟโดยใช้ PS เขาอาจไม่รู้รายละเอียดเกี่ยวกับการทำงานของคอมพิวเตอร์หรือหลักการเขียนโปรแกรมมากนัก ผู้ดูแลระบบ PS (ผู้ดูแลระบบ) จัดการการใช้งาน PS โดยผู้ใช้ทั่วไปและให้การสนับสนุน PS ที่ไม่เกี่ยวข้องกับการดัดแปลงโปรแกรม ตัวอย่างเช่น อาจควบคุมสิทธิ์การเข้าถึง OS ระหว่างผู้ใช้ทั่วไป สื่อสารกับผู้ให้บริการ OS หรือดำเนินการบางอย่างเพื่อให้ OS ทำงานได้ตามปกติหากมีการรวมเป็นส่วนหนึ่งของระบบอื่น
องค์ประกอบของเอกสารผู้ใช้ขึ้นอยู่กับผู้ชมของผู้ใช้ที่ PS นี้มุ่งเป้าไปที่ และรูปแบบการใช้เอกสาร ผู้ชมที่นี่เป็นที่เข้าใจกันว่าเป็นผู้ใช้ PS ซึ่งมีความต้องการเอกสารผู้ใช้ PS บางอย่าง เอกสารผู้ใช้ที่ประสบความสำเร็จนั้นขึ้นอยู่กับคำจำกัดความที่ชัดเจนของผู้ชมที่ต้องการ เอกสารสำหรับผู้ใช้ควรมีข้อมูลที่จำเป็นสำหรับผู้ชมแต่ละราย รูปแบบการใช้เอกสารหมายถึงลักษณะการใช้งานเอกสาร โดยปกติแล้ว ผู้ใช้ระบบซอฟต์แวร์ที่มีขนาดใหญ่เพียงพอต้องการเอกสารอย่างใดอย่างหนึ่งเพื่อศึกษา PS (ใช้ใน คำแนะนำ) หรือเพื่อชี้แจงข้อมูลบางอย่าง (ใช้เป็นข้อมูลอ้างอิง)
ตามผลงานองค์ประกอบของเอกสารผู้ใช้ต่อไปนี้สำหรับ PS ที่มีขนาดใหญ่เพียงพอถือเป็นเรื่องปกติ:
คำอธิบายการทำงานทั่วไปของ PS ให้คำอธิบายสั้น ๆ เกี่ยวกับการทำงานของ PS มีไว้สำหรับผู้ใช้ที่ต้องตัดสินใจว่าต้องการ PS นี้มากน้อยเพียงใด
ป.ล. คู่มือการติดตั้ง. ออกแบบมาสำหรับผู้ดูแลระบบ ควรกำหนดรายละเอียดวิธีการติดตั้งระบบในสภาพแวดล้อมเฉพาะ จะต้องมีรายละเอียดของสื่อที่เครื่องอ่านได้ซึ่งมี MS มาให้ ไฟล์ที่เป็นตัวแทนของ MS และข้อกำหนดสำหรับการกำหนดค่าฮาร์ดแวร์ขั้นต่ำ
คำแนะนำสำหรับการใช้งาน PS ออกแบบมาสำหรับผู้ใช้ทั่วไป มีข้อมูลที่จำเป็นเกี่ยวกับการสมัคร PS ซึ่งจัดในรูปแบบที่สะดวกสำหรับการศึกษา
หนังสืออ้างอิงการสมัคร PS. ออกแบบมาสำหรับผู้ใช้ทั่วไป มีข้อมูลที่จำเป็นเกี่ยวกับแอปพลิเคชันของ PS ซึ่งจัดในรูปแบบที่สะดวกสำหรับการค้นหารายละเอียดส่วนบุคคลแบบเลือกได้
ป.ล. คู่มือการจัดการ. ออกแบบมาสำหรับผู้ดูแลระบบ ควรอธิบายข้อความที่สร้างขึ้นเมื่อ MS โต้ตอบกับระบบอื่นและวิธีตอบกลับข้อความเหล่านี้ นอกจากนี้ หาก MS ใช้ฮาร์ดแวร์ระบบ เอกสารนี้อาจอธิบายวิธีการบำรุงรักษาฮาร์ดแวร์นั้น
ดังที่ได้กล่าวไว้ก่อนหน้านี้ (ดูบทที่ 4) การพัฒนาเอกสารผู้ใช้เริ่มต้นทันทีหลังจากสร้างคำอธิบายภายนอก คุณภาพของเอกสารนี้สามารถกำหนดความสำเร็จของ PS ได้อย่างมีนัยสำคัญ ควรค่อนข้างเรียบง่ายและเป็นมิตรกับผู้ใช้ (ไม่เช่นนั้น PS นี้โดยทั่วไปก็ไม่คุ้มที่จะสร้าง) ดังนั้น แม้ว่าเวอร์ชันร่าง (แบบร่าง) ของเอกสารผู้ใช้จะถูกสร้างขึ้นโดยผู้พัฒนาหลักของ PS แต่นักเขียนทางเทคนิคมืออาชีพมักมีส่วนร่วมในการสร้างเวอร์ชันสุดท้าย นอกจากนี้ เพื่อให้มั่นใจในคุณภาพของเอกสารสำหรับผู้ใช้ จึงมีการพัฒนามาตรฐานจำนวนหนึ่ง (ดูตัวอย่าง) ซึ่งกำหนดขั้นตอนในการพัฒนาเอกสารนี้ กำหนดข้อกำหนดสำหรับเอกสารผู้ใช้แต่ละประเภท และกำหนดโครงสร้างและเนื้อหา .
13.3. เอกสารสนับสนุนซอฟต์แวร์
เอกสารสำหรับการบำรุงรักษา PS (เอกสารระบบ) อธิบาย PS จากมุมมองของการพัฒนา เอกสารนี้จำเป็นหาก PS เกี่ยวข้องกับการศึกษาวิธีการจัดเรียง (ออกแบบ) และความทันสมัยของโปรแกรม ตามที่ระบุไว้ การบำรุงรักษาเป็นการพัฒนาอย่างต่อเนื่อง ดังนั้นหากจำเป็นต้องอัปเกรด PS ทีมพิเศษของนักพัฒนาที่มาพร้อมกันจะมีส่วนร่วมในงานนี้ ทีมนี้จะต้องจัดการกับเอกสารเดียวกันกับที่กำหนดกิจกรรมของทีมผู้พัฒนาเริ่มต้น (หลัก) ของ PS โดยมีข้อแตกต่างเพียงอย่างเดียวคือตามกฎแล้วเอกสารนี้จะเป็นของคนอื่นสำหรับทีมพัฒนาผู้ดูแล ( มันถูกสร้างโดยทีมอื่น) ทีมบำรุงรักษาจะต้องศึกษาเอกสารนี้เพื่อทำความเข้าใจโครงสร้างและขั้นตอนการพัฒนาของ PS ที่อัปเกรด และทำการเปลี่ยนแปลงที่จำเป็นในเอกสารนี้ โดยทำซ้ำกระบวนการทางเทคโนโลยีที่สร้าง PS ดั้งเดิมในระดับมาก
เอกสารเกี่ยวกับการสนับสนุน PS สามารถแบ่งออกเป็นสองกลุ่ม:
(1) เอกสารที่กำหนดโครงสร้างของโปรแกรมและโครงสร้างข้อมูลของ PS และเทคโนโลยีสำหรับการพัฒนา
(2) เอกสารเพื่อช่วยในการเปลี่ยนแปลง PS
เอกสารของกลุ่มแรกประกอบด้วยเอกสารขั้นสุดท้ายของแต่ละขั้นตอนทางเทคโนโลยีของการพัฒนา PS ประกอบด้วยเอกสารดังต่อไปนี้:
คำอธิบายภายนอกของ PS (เอกสารข้อกำหนด)
คำอธิบายสถาปัตยกรรมระบบของ PS รวมถึงข้อกำหนดภายนอกของแต่ละโปรแกรม
สำหรับแต่ละโปรแกรม PS คำอธิบายของโครงสร้างแบบแยกส่วน รวมถึงข้อมูลจำเพาะภายนอกสำหรับแต่ละโมดูลที่รวมอยู่ในนั้น
สำหรับแต่ละโมดูล - ข้อกำหนดและคำอธิบายของโครงสร้าง (คำอธิบายการออกแบบ)
ข้อความโมดูลในภาษาการเขียนโปรแกรมที่เลือก (รายการซอร์สโค้ดของโปรแกรม)
เอกสารการตรวจสอบความถูกต้องของระบบปฏิบัติการที่อธิบายถึงวิธีการกำหนดความถูกต้องของโปรแกรมระบบปฏิบัติการแต่ละโปรแกรมและข้อมูลการตรวจสอบนั้นเชื่อมโยงกับข้อกำหนดสำหรับระบบปฏิบัติการอย่างไร
เอกสารการตรวจสอบความถูกต้องของซอฟต์แวร์ส่วนใหญ่ประกอบด้วยเอกสารการทดสอบ (การออกแบบการทดสอบและคำอธิบายชุดการทดสอบ) แต่อาจรวมถึงผลลัพธ์ของการตรวจสอบความถูกต้องของซอฟต์แวร์ประเภทอื่นๆ เช่น การพิสูจน์คุณสมบัติของโปรแกรม
เอกสารของกลุ่มที่สองประกอบด้วย
คู่มือการบำรุงรักษาระบบ ซึ่งอธิบายปัญหาที่ทราบพร้อมกับซอฟต์แวร์ อธิบายว่าส่วนใดของระบบขึ้นอยู่กับฮาร์ดแวร์และซอฟต์แวร์ และวิธีพิจารณาการพัฒนาซอฟต์แวร์ในโครงสร้าง (การออกแบบ)
ปัญหาการบำรุงรักษาทั่วไปสำหรับ PS คือการทำให้แน่ใจว่าการแสดงทั้งหมดนั้นทัน (คงเส้นคงวา) เมื่อ PS เปลี่ยนแปลง เพื่อช่วยในเรื่องนี้ ความสัมพันธ์และการขึ้นต่อกันระหว่างเอกสารและส่วนต่างๆ จะต้องถูกจับในฐานข้อมูลการจัดการการกำหนดค่า
วรรณกรรมประกอบการบรรยาย13.
13.1. เอียน ซอมเมอร์วิลล์. วิศวกรรมซอฟต์แวร์. - Addison-Wesley Publishing Company, 1992. หน้า
13.2. ANSI/IEEE Std 1063-1988 มาตรฐาน IEEE สำหรับเอกสารผู้ใช้ซอฟต์แวร์
13.3. ANSI/IEEE Std 830-1984 คู่มือ IEEE สำหรับข้อกำหนดซอฟต์แวร์
13.4. ANSI/IEEE Std 1016-1987, IEEE แนะนำแนวทางปฏิบัติสำหรับคำอธิบายการออกแบบซอฟต์แวร์
13.5 ANSI/IEEE Std 1008-1987, มาตรฐาน IEEE สำหรับการทดสอบหน่วยซอฟต์แวร์
13.6. ANSI/IEEE Std 1012-1986 มาตรฐาน IEEE สำหรับแผนการตรวจสอบและการตรวจสอบความถูกต้องของซอฟต์แวร์
13.7. ANSI/IEEE Std 983-1986 คู่มือ IEEE สำหรับการวางแผนประกันคุณภาพซอฟต์แวร์
13.8. ANSI/IEEE Std 829-1983 มาตรฐาน IEEE สำหรับเอกสารการทดสอบซอฟต์แวร์
การบรรยายครั้งที่ 14
การแต่งตั้งใบรับรองซอฟต์แวร์ การทดสอบและประเมินคุณภาพของซอฟต์แวร์ ประเภทของการทดสอบและวิธีการประเมินคุณภาพของซอฟต์แวร์
14.1. การแต่งตั้งใบรับรองซอฟต์แวร์
การรับรอง PS เป็นการยืนยันอย่างเป็นทางการเกี่ยวกับคุณภาพของ PS โดยปกติแล้ว จะมีการสร้างคณะกรรมการตัวแทน (การรับรอง) สำหรับการรับรองระบบซอฟต์แวร์ ซึ่งประกอบด้วยผู้เชี่ยวชาญ ตัวแทนของลูกค้า และตัวแทนของผู้พัฒนา คณะกรรมาธิการนี้ดำเนินการทดสอบ PS เพื่อให้ได้ข้อมูลที่จำเป็นในการประเมินคุณภาพ ภายใต้การทดสอบของ PS เราหมายถึงกระบวนการดำเนินการชุดมาตรการที่ตรวจสอบความเหมาะสมของ PS สำหรับการดำเนินงานที่ประสบความสำเร็จ (การใช้งานและการบำรุงรักษา) ตามความต้องการของลูกค้า คอมเพล็กซ์นี้รวมถึงการตรวจสอบความสมบูรณ์และความถูกต้องของเอกสารประกอบซอฟต์แวร์ ศึกษาและหารือเกี่ยวกับคุณสมบัติอื่นๆ ตลอดจนการทดสอบที่จำเป็นของโปรแกรมที่รวมอยู่ในชุดซอฟต์แวร์ และโดยเฉพาะอย่างยิ่ง การปฏิบัติตามข้อกำหนดของโปรแกรมเหล่านี้กับเอกสารที่มีอยู่
จากข้อมูลที่ได้รับระหว่างการทดสอบ PS ก่อนอื่นต้องระบุว่า PS ทำหน้าที่ตามที่ประกาศไว้และต้องกำหนดว่า PS มีเกณฑ์พื้นฐานและคุณภาพที่ประกาศไว้ในระดับใด ดังนั้นการประเมินคุณภาพของ PS จึงเป็นเนื้อหาหลักของกระบวนการรับรอง การประเมินคุณภาพของ PS จะถูกบันทึกไว้ในการตัดสินใจที่เกี่ยวข้องของคณะกรรมการรับรอง
14.2. ประเภทของการทดสอบซอฟต์แวร์
การทดสอบ PS ประเภทต่อไปนี้เป็นที่รู้จัก ซึ่งดำเนินการเพื่อวัตถุประสงค์ในการรับรอง PS:
การทดสอบส่วนประกอบ PS;
การทดสอบระบบ
การทดสอบการยอมรับ
การทดลองภาคสนาม
การทดสอบทางอุตสาหกรรม
การทดสอบส่วนประกอบ PS เป็นการตรวจสอบ (ทดสอบ) ความสามารถในการทำงานของระบบย่อยแต่ละระบบของ PS พวกเขาจะจัดขึ้นในกรณีพิเศษเท่านั้นโดยการตัดสินใจพิเศษของคณะกรรมการรับรอง
การทดสอบระบบของ PS เป็นการตรวจสอบ (ทดสอบ) ความสามารถในการทำงานของ PS โดยรวม อาจรวมถึงการทดสอบประเภทเดียวกับการดีบักที่ซับซ้อนของ PS (ดูการบรรยาย 10) ดำเนินการโดยการตัดสินใจของคณะกรรมการรับรอง หากมีข้อสงสัยเกี่ยวกับคุณภาพของการดีบักโดยผู้พัฒนา PS
การทดสอบการยอมรับเป็นประเภทการทดสอบหลักสำหรับการรับรอง PS ด้วยการทดสอบเหล่านี้คณะกรรมการรับรองจึงเริ่มทำงาน การทดสอบเหล่านี้เริ่มต้นด้วยการศึกษาเอกสารที่ส่งมา รวมถึงเอกสารเกี่ยวกับการทดสอบและการดีบัก PS หากเอกสารประกอบไม่มีผลการทดสอบซอฟต์แวร์ที่สมบูรณ์เพียงพอ คณะกรรมการรับรองอาจตัดสินใจดำเนินการทดสอบระบบของซอฟต์แวร์หรือยุติกระบวนการรับรองโดยให้คำแนะนำแก่นักพัฒนาให้ทำการทดสอบซอฟต์แวร์เพิ่มเติม (สมบูรณ์ยิ่งขึ้น) นอกจากนี้ ในระหว่างการทดสอบเหล่านี้ การทดสอบของนักพัฒนาสามารถเลือกข้ามได้ เช่นเดียวกับงานควบคุมผู้ใช้ (ดูการบรรยาย 10) และการทดสอบเพิ่มเติมที่จัดทำโดยคณะกรรมการเพื่อประเมินคุณภาพของ PS ที่ได้รับการรับรอง
การทดสอบภาคสนามของ PS เป็นการสาธิต PS ร่วมกับระบบทางเทคนิคที่ควบคุมโดย PS นี้ให้กับลูกค้าวงแคบในสภาพจริง และพฤติกรรมของ PS จะได้รับการตรวจสอบอย่างรอบคอบ ลูกค้าควรได้รับโอกาสในการตั้งค่ากรณีทดสอบของตนเอง โดยเฉพาะอย่างยิ่ง ตั้งแต่การออกจากระบบจนถึงโหมดการทำงานที่สำคัญของระบบทางเทคนิค รวมถึงการเรียกสถานการณ์ฉุกเฉินในนั้น การทดสอบเหล่านี้เป็นการทดสอบเพิ่มเติมที่ดำเนินการโดยการตัดสินใจของคณะกรรมการรับรองสำหรับ PS บางตัวที่ควบคุมระบบทางเทคนิคบางอย่างเท่านั้น
การทดสอบทางอุตสาหกรรมของ PS เป็นกระบวนการถ่ายโอน PS เข้าสู่การทำงานถาวรแก่ผู้ใช้ เป็นช่วงของการทดลองใช้งาน PS (ดูบทที่ 10) โดยผู้ใช้ โดยมีการรวบรวมข้อมูลเกี่ยวกับพฤติกรรมของ PS และลักษณะการทำงาน นี่คือการทดสอบขั้นสุดท้ายของ PS ซึ่งดำเนินการโดยการตัดสินใจของคณะกรรมการรับรอง หากได้รับข้อมูลที่ไม่สมบูรณ์หรือเชื่อถือได้เพียงพอในระหว่างการทดสอบครั้งก่อนเพื่อประเมินคุณภาพของ PS ที่ได้รับการรับรอง
14.3. วิธีการประเมินคุณภาพของซอฟต์แวร์
การประเมินคุณภาพของ PS สำหรับแต่ละเกณฑ์จะลดลงเป็นการประเมินของเกณฑ์พื้นฐานแต่ละข้อที่เกี่ยวข้องกับเกณฑ์คุณภาพของ PS ตามข้อกำหนดที่กำหนดในข้อกำหนดคุณภาพของ PS นี้ วิธีการประเมินคุณภาพดั้งเดิมของ PS สามารถแบ่งออกเป็นสี่กลุ่ม:
การวัดโดยตรงของตัวบ่งชี้คุณภาพดั้งเดิม
โปรแกรมประมวลผลและเอกสารประกอบของ PS พร้อมเครื่องมือซอฟต์แวร์พิเศษ (โปรเซสเซอร์)
การทดสอบโปรแกรม PS;
การประเมินโดยผู้เชี่ยวชาญจากการศึกษาโปรแกรมและเอกสารของ PS
การวัดโดยตรงของตัวบ่งชี้คุณภาพดั้งเดิมนั้นดำเนินการโดยการนับจำนวนครั้งที่เกิดขึ้นในเอกสารโปรแกรมเฉพาะของหน่วยคุณลักษณะ วัตถุ โครงสร้าง ฯลฯ เช่นเดียวกับการวัดเวลาในการทำงาน อุปกรณ์ต่างๆและจำนวนหน่วยความจำของคอมพิวเตอร์ที่ถูกครอบครองในระหว่างการดำเนินการกรณีทดสอบ ตัวอย่างเช่น การวัดประสิทธิภาพหน่วยความจำบางอย่างอาจเป็นจำนวนบรรทัดของโปรแกรมในภาษาการเขียนโปรแกรม และการวัดประสิทธิภาพด้านเวลาบางอย่างอาจเป็นเวลาตอบสนองต่อคิวรี การใช้ตัวบ่งชี้ใด ๆ สำหรับคุณภาพดั้งเดิมอาจกำหนดไว้ในข้อกำหนดคุณภาพของ MS วิธีการวัดโดยตรงของตัวบ่งชี้คุณภาพดั้งเดิมสามารถใช้ร่วมกับการทดสอบโปรแกรมได้
เครื่องมือซอฟต์แวร์บางอย่างสามารถใช้เพื่อพิจารณาว่า MS มีพื้นฐานคุณภาพบางอย่างหรือไม่ เครื่องมือซอฟต์แวร์ดังกล่าวจะประมวลผลข้อความโปรแกรมหรือเอกสารประกอบซอฟต์แวร์เพื่อควบคุมคุณภาพดั้งเดิมใดๆ หรือรับตัวบ่งชี้บางอย่างของคุณภาพดั้งเดิมเหล่านี้ ในการประเมินโครงสร้างของโปรแกรม PS หากโปรแกรมเหล่านี้ถูกตั้งโปรแกรมในภาษาถิ่นที่มีโครงสร้างเหมาะสมของภาษาโปรแกรมพื้นฐาน ก็เพียงพอแล้วที่จะส่งผ่านโปรแกรมเหล่านั้นผ่านตัวแปลงโปรแกรมที่มีโครงสร้างซึ่งทำหน้าที่ควบคุมวากยสัมพันธ์และความหมายของภาษาถิ่นนี้ และแปลข้อความของ โปรแกรมเหล่านี้เป็นภาษาอินพุตของตัวแปลหลัก อย่างไรก็ตาม ในปัจจุบันมีเพียงวัตถุดั้งเดิมที่มีคุณภาพจำนวนเล็กน้อยเท่านั้นที่สามารถควบคุมได้ด้วยวิธีนี้ และแม้แต่ในกรณีที่หายาก ในบางกรณี แทนที่จะใช้เครื่องมือซอฟต์แวร์ที่ควบคุมคุณภาพของซอฟต์แวร์ การใช้เครื่องมือที่แปลงการนำเสนอโปรแกรมหรือเอกสารประกอบโปรแกรมจะมีประโยชน์มากกว่า ตัวอย่างเช่น เป็นตัวจัดรูปแบบโปรแกรมที่นำข้อความของโปรแกรมมาสู่รูปแบบที่อ่านได้ - การประมวลผลข้อความของโปรแกรม PS ด้วยเครื่องมือดังกล่าวสามารถรับประกันได้โดยอัตโนมัติว่า PS มีคุณภาพดั้งเดิมที่เหมาะสม
การทดสอบใช้เพื่อประเมินคุณภาพดั้งเดิมของ PS พื้นฐานดังกล่าวรวมถึงความสมบูรณ์ของ PS เป็นหลัก เช่นเดียวกับความแม่นยำ ความเสถียร ความปลอดภัย และคุณสมบัติดั้งเดิมด้านคุณภาพอื่นๆ ในบางกรณี การทดสอบจะใช้ร่วมกับวิธีอื่นๆ เพื่อประเมินคุณภาพดั้งเดิมของ PS แต่ละรายการ ดังนั้น เพื่อประเมินคุณภาพของเอกสารเกี่ยวกับการใช้ PS (เอกสาร P) การทดสอบจึงใช้ร่วมกับการประเมินโดยผู้เชี่ยวชาญของเอกสารนี้ หากมีการทดสอบที่สมบูรณ์เพียงพอระหว่างการดีบักที่ซับซ้อนของ PS การทดสอบเดียวกันนี้สามารถใช้ได้ระหว่างการรับรอง PS ในกรณีนี้ คณะกรรมการรับรองสามารถใช้โปรโตคอลการทดสอบที่ดำเนินการระหว่างการแก้ไขจุดบกพร่องที่ซับซ้อนได้ อย่างไรก็ตาม แม้ในกรณีนี้ ก็จำเป็นต้องทำการทดสอบใหม่หรืออย่างน้อยก็ทำการทดสอบเก่าบางรายการใหม่อีกครั้ง หากพบว่าการทดสอบระหว่างการดีบักแบบซับซ้อนยังไม่สมบูรณ์เพียงพอ ก็จำเป็นต้องดำเนินการทดสอบที่สมบูรณ์ยิ่งขึ้น ในกรณีนี้ อาจมีการตัดสินใจที่จะดำเนินการทดสอบส่วนประกอบหรือการทดสอบระบบของ PS รวมถึงการส่งคืน PS ให้กับนักพัฒนาเพื่อทำการแก้ไข มันสำคัญมากที่จะต้องประเมิน PS ตามเกณฑ์ของการใช้งานง่าย (ระหว่างการดีบั๊กและการรับรอง PS) การทดสอบเต็มรูปแบบจะดำเนินการในการทดสอบที่จัดทำขึ้นตามเอกสารประกอบสำหรับแอปพลิเคชันและตาม ตามเกณฑ์การบำรุงรักษา - ในการทดสอบที่จัดทำขึ้นสำหรับเอกสารแต่ละฉบับที่เสนอสำหรับการบำรุงรักษา
ในการประเมินคุณภาพดั้งเดิมของ PS ส่วนใหญ่ ในปัจจุบันสามารถใช้วิธีการประเมินโดยผู้เชี่ยวชาญเท่านั้น วิธีนี้ประกอบด้วยสิ่งต่อไปนี้: มีการแต่งตั้งกลุ่มผู้เชี่ยวชาญ ผู้เชี่ยวชาญแต่ละคนเหล่านี้จากการศึกษาเอกสารที่ส่งมาได้ให้ความเห็นเกี่ยวกับการครอบครอง PS โดยคุณภาพดั้งเดิมที่จำเป็น จากนั้นจึงประเมินสิ่งที่จำเป็น คุณภาพดั้งเดิมของ PS นั้นเกิดจากการลงคะแนนเสียงของสมาชิกในกลุ่มนี้ การประเมินนี้สามารถทำได้ทั้งในระบบสองจุด ("มี" - "ไม่มี") และคำนึงถึงระดับความครอบครองของ PS ด้วยคุณภาพดั้งเดิมนี้ (ตัวอย่างเช่น สามารถทำได้ในห้า ระบบจุด) ในเวลาเดียวกัน กลุ่มผู้เชี่ยวชาญควรได้รับคำแนะนำจากข้อมูลจำเพาะของสิ่งดั้งเดิมนี้และข้อบ่งชี้ของวิธีการประเมิน ซึ่งกำหนดไว้ในข้อกำหนดคุณภาพของ PS ที่ผ่านการรับรอง
วรรณกรรมประกอบการบรรยาย14.
14.2. V.V. Lipaev การทดสอบโปรแกรม - ม.: วิทยุและการสื่อสาร 2529. - ส. 231-245.
14.3. ง. ฟาน พู่. รูปแบบ การพัฒนา ประสิทธิภาพ การดีบัก และการทดสอบโปรแกรม - ม.: มีร์ 2528. - ส. 281-283.
14.4. บี. ชไนเดอร์แมน. จิตวิทยาการเขียนโปรแกรม - ม.: วิทยุและการสื่อสาร 2527. - ส. 99-127.
การบรรยาย 15. วัตถุประสงค์ในการพัฒนาซอฟต์แวร์
15.1. วัตถุและความสัมพันธ์ในการเขียนโปรแกรม สาระสำคัญของแนวทางวัตถุในการพัฒนาซอฟต์แวร์
โลกรอบตัวเราประกอบด้วยวัตถุและความสัมพันธ์ระหว่างกัน อ็อบเจกต์ประกอบเอนทิตีบางอย่างและมีสถานะบางอย่างที่สามารถเปลี่ยนแปลงได้เมื่อเวลาผ่านไปอันเป็นผลมาจากอิทธิพลของอ็อบเจกต์อื่นๆ ที่มีผลในทางใดทางหนึ่งกับข้อมูล มันสามารถมีโครงสร้างภายใน: มันสามารถประกอบด้วยวัตถุอื่น ๆ ที่มีความสัมพันธ์ซึ่งกันและกัน จากนี้จึงเป็นไปได้ที่จะสร้างโครงสร้างลำดับชั้นของโลกจากวัตถุ อย่างไรก็ตาม สำหรับการพิจารณาเฉพาะเจาะจงของโลกรอบตัวเรา วัตถุบางอย่างถูกพิจารณาว่าแบ่งแยกไม่ได้ ("จุด") และขึ้นอยู่กับเป้าหมายของการพิจารณา วัตถุ (ที่แบ่งแยกไม่ได้) ดังกล่าวที่มีลำดับชั้นต่างกันสามารถเป็นที่ยอมรับได้ ความสัมพันธ์เชื่อมโยงวัตถุบางอย่าง: เราสามารถพิจารณาได้ว่าการรวมกันของวัตถุเหล่านี้มีคุณสมบัติบางอย่าง หากความสัมพันธ์เชื่อมโยงวัตถุ n ชิ้น ความสัมพันธ์ดังกล่าวจะเรียกว่า n-place (n-ary) ในแต่ละตำแหน่งของการเชื่อมโยงของวัตถุที่สามารถเชื่อมต่อกันด้วยความสัมพันธ์เฉพาะใด ๆ อาจมีวัตถุที่แตกต่างกัน แต่วัตถุที่แน่นอนค่อนข้างแน่นอน (ในกรณีนี้พวกเขากล่าวว่า: วัตถุของคลาสที่แน่นอน) ความสัมพันธ์แบบตำแหน่งเดียวเรียกว่าคุณสมบัติของวัตถุ (คลาสที่เกี่ยวข้อง) สถานะของวัตถุสามารถศึกษาได้จากค่าของคุณสมบัติของวัตถุนี้หรือโดยปริยายโดยค่าของคุณสมบัติของสหภาพของวัตถุที่เชื่อมโยงกันด้วยความสัมพันธ์ที่กำหนดหรือความสัมพันธ์อื่น
ในกระบวนการรับรู้หรือเปลี่ยนแปลงโลกรอบตัวเรา เรามักคำนึงถึงแบบจำลองที่เรียบง่ายของโลก (แบบจำลองโลก) ซึ่งรวมถึงวัตถุบางอย่างและความสัมพันธ์บางอย่างของโลกรอบตัวเรา และ ตามกฎแล้วลำดับชั้นหนึ่งระดับ แต่ละออบเจกต์ที่มีโครงสร้างภายในสามารถแสดงถึงโลกจำลองของมันเอง รวมถึงอ็อบเจกต์ของโครงสร้างนี้และความสัมพันธ์ที่ผูกมัดพวกมัน ดังนั้น โลกรอบตัวเราจึงถือได้ว่าเป็นโครงสร้างแบบลำดับขั้นของโลกจำลอง
ปัจจุบัน ในกระบวนการเรียนรู้หรือเปลี่ยนแปลงโลกรอบตัวเรา เทคโนโลยีคอมพิวเตอร์ถูกนำมาใช้อย่างแพร่หลายในการประมวลผลข้อมูลประเภทต่างๆ ในเรื่องนี้จะใช้คอมพิวเตอร์ (ข้อมูล) แทนวัตถุและความสัมพันธ์ แต่ละวัตถุสามารถแสดงข้อมูลโดยโครงสร้างข้อมูลบางส่วนที่แสดงสถานะของมัน คุณสมบัติของวัตถุนี้สามารถตั้งค่าโดยตรงเป็นส่วนประกอบแยกต่างหากของโครงสร้างนี้ หรือโดยฟังก์ชันพิเศษในโครงสร้างข้อมูลนี้ ความสัมพันธ์ N-ary สำหรับ N>1 สามารถแสดงได้ทั้งในรูปแบบแอ็คทีฟหรือแบบพาสซีฟ ในรูปแบบที่แอ็คทีฟ ความสัมพันธ์ N-place จะแสดงโดยแฟรกเมนต์ของโปรแกรมบางส่วนที่ใช้ทั้งฟังก์ชัน N-place (การกำหนดค่าของคุณสมบัติของยูเนียนของออบเจกต์ที่สอดคล้องกัน) หรือขั้นตอนที่เปลี่ยนสถานะของบางรายการตาม ในสถานะของการเป็นตัวแทนของวัตถุที่เชื่อมต่อโดยความสัมพันธ์ที่เป็นตัวแทน ในรูปแบบพาสซีฟ ความสัมพันธ์ดังกล่าวสามารถแสดงโดยโครงสร้างข้อมูลบางอย่าง (ซึ่งอาจรวมถึงการแสดงวัตถุที่เชื่อมต่อด้วยความสัมพันธ์นี้) ตีความบนพื้นฐานของข้อตกลงที่ยอมรับเกี่ยวกับขั้นตอนทั่วไปที่ไม่ขึ้นกับความสัมพันธ์เฉพาะ (ตัวอย่างเช่น ฐานข้อมูลเชิงสัมพันธ์) ในทั้งสองกรณี การแสดงความสัมพันธ์จะกำหนดกิจกรรมการประมวลผลข้อมูลบางอย่าง
เมื่อสำรวจโลกจำลอง ผู้ใช้สามารถรับ (หรือต้องการรับ) ข้อมูลจากคอมพิวเตอร์ด้วยวิธีต่างๆ ในแนวทางหนึ่ง เขาอาจสนใจที่จะรับข้อมูลเกี่ยวกับคุณสมบัติแต่ละอย่างของวัตถุที่เขาสนใจหรือผลลัพธ์ของปฏิสัมพันธ์ใดๆ ระหว่างวัตถุบางอย่าง ในการทำเช่นนี้เขาสั่งให้พัฒนา PS อย่างน้อยหนึ่งตัวที่ทำหน้าที่ที่เขาสนใจหรือระบบข้อมูลบางอย่างที่สามารถออกข้อมูลเกี่ยวกับความสัมพันธ์ที่เขาสนใจโดยใช้ฐานข้อมูลที่เหมาะสม ในช่วงเริ่มต้นของการพัฒนาเทคโนโลยีคอมพิวเตอร์ (โดยคอมพิวเตอร์มีกำลังสูงไม่เพียงพอ) วิธีการใช้คอมพิวเตอร์ดังกล่าวค่อนข้างเป็นธรรมชาติ เขาเป็นคนที่กระตุ้นแนวทางการทำงาน (เชิงสัมพันธ์) ในการพัฒนา PS ซึ่งได้กล่าวถึงในรายละเอียดในการบรรยายครั้งก่อน สาระสำคัญของแนวทางนี้คือการใช้การสลายตัวของฟังก์ชัน (ความสัมพันธ์) อย่างเป็นระบบเพื่อสร้างโครงสร้างของ PS และข้อความโปรแกรมที่รวมอยู่ในนั้น ในเวลาเดียวกัน อ็อบเจ็กต์เองซึ่งใช้ฟังก์ชันที่สั่งและนำไปใช้นั้นถูกนำเสนอเป็นส่วนๆ (ในขอบเขตที่จำเป็นในการทำหน้าที่เหล่านี้) และในรูปแบบที่สะดวกสำหรับการนำฟังก์ชันเหล่านี้ไปใช้ ดังนั้นจึงไม่มีการแสดงคอมพิวเตอร์ที่สมบูรณ์และเพียงพอของโลกแห่งแบบจำลองที่ผู้ใช้สนใจ: การแสดงบน PS ที่ใช้แล้วอาจกลายเป็นงานที่ค่อนข้างลำบากสำหรับผู้ใช้ความพยายามที่จะขยายระดับเสียงและธรรมชาติเล็กน้อย ข้อมูลเกี่ยวกับโลกแห่งแบบจำลองที่ผู้ใช้สนใจ ที่ได้รับจากสถานีย่อยดังกล่าวอาจนำไปสู่การปรับปรุงให้ทันสมัยอย่างจริงจัง แนวทางการพัฒนา PS นี้ได้รับการสนับสนุนโดยภาษาโปรแกรมส่วนใหญ่ที่ใช้ตั้งแต่ภาษาแอสเซมบลีและ ภาษาขั้นตอน(Fortran, Pascal) เป็นภาษาใช้งาน (LISP) และภาษาโปรแกรมลอจิก (PROLOGUE)
ด้วยวิธีการอื่นในการศึกษาโลกของแบบจำลองโดยใช้คอมพิวเตอร์ ผู้ใช้อาจสนใจที่จะสังเกตการเปลี่ยนแปลงสถานะของวัตถุอันเป็นผลมาจากการโต้ตอบ สิ่งนี้ต้องการการแสดงที่ค่อนข้างมั่นคงในคอมพิวเตอร์ของวัตถุที่ผู้ใช้สนใจ และส่วนประกอบของซอฟต์แวร์ที่ใช้ความสัมพันธ์ที่วัตถุนี้เข้าร่วมนั้นมีความเกี่ยวข้องอย่างชัดเจน ในการดำเนินการตามแนวทางนี้ จำเป็นต้องสร้างเครื่องมือซอฟต์แวร์ที่จำลองกระบวนการโต้ตอบระหว่างวัตถุ (แบบจำลองโลก) ด้วยความช่วยเหลือของเครื่องมือการพัฒนาแบบดั้งเดิม สิ่งนี้กลายเป็นงานที่ลำบากพอสมควร จริงอยู่ที่ภาษาการเขียนโปรแกรมที่เน้นไปที่การสร้างแบบจำลองดังกล่าวโดยเฉพาะ แต่สิ่งนี้ทำให้งานพัฒนา PS ที่ต้องการง่ายขึ้นเพียงบางส่วนเท่านั้น ทางออกที่สมบูรณ์ที่สุดของปัญหานี้คือแนวทางการพัฒนา PS สาระสำคัญอยู่ที่การใช้การสลายตัวของวัตถุอย่างเป็นระบบในการสร้างโครงสร้างของ PS และข้อความของโปรแกรมที่รวมอยู่ในนั้น ในเวลาเดียวกัน ฟังก์ชัน (ความสัมพันธ์) ที่ดำเนินการโดย PS ดังกล่าวถูกแสดงผ่านความสัมพันธ์ของวัตถุในระดับต่างๆ เช่น การสลายตัวขึ้นอยู่กับการสลายตัวของวัตถุอย่างมีนัยสำคัญ
เมื่อพูดถึงแนวทางของวัตถุ เราควรเข้าใจอย่างชัดเจนว่าวัตถุประเภทใดที่เกี่ยวข้อง: วัตถุในโลกจำลองของผู้ใช้ การแสดงข้อมูล วัตถุโปรแกรมที่สร้าง PS นอกจากนี้ เราควรแยกความแตกต่างระหว่างวัตถุจริง (วัตถุ "เฉยๆ") และวัตถุ (วัตถุ "ที่ใช้งานอยู่")
15.2. วัตถุและวิชาในการเขียนโปรแกรม
15.3. แนวทางวัตถุประสงค์และอัตนัยในการพัฒนาซอฟต์แวร์
Descartes ตั้งข้อสังเกตว่าผู้คนมักจะมีมุมมองเชิงวัตถุของโลก (c)
พวกเขาเชื่อว่าการออกแบบเชิงวัตถุขึ้นอยู่กับหลักการของ:
เน้นสิ่งที่เป็นนามธรรม
ข้อ จำกัด การเข้าถึง
โมดูลาร์,
ลำดับชั้น
พิมพ์
ความเท่าเทียม,
ความยั่งยืน
แต่ทั้งหมดนี้สามารถนำไปใช้ในแนวทางการทำงาน
จำเป็นต้องแยกความแตกต่างระหว่างข้อดีและข้อเสียของแนวทางวัตถุทั่วไปกับกรณีพิเศษ - วิธีการเชิงวัตถุ
ข้อดีของแนวทางวัตถุประสงค์ทั่วไป:
การทำแผนที่ตามธรรมชาติของโลกแห่งความจริงบนโครงสร้าง PS (การรับรู้โดยธรรมชาติของมนุษย์เกี่ยวกับความสามารถของ PS ไม่จำเป็นต้อง "ประดิษฐ์" โครงสร้าง PS แต่ใช้การเปรียบเทียบที่เป็นธรรมชาติ)
การใช้หน่วยโครงสร้างที่มีความหมายเพียงพอของ PS (วัตถุที่เป็นความสมบูรณ์ของการเชื่อมโยงที่ไม่ซ้ำซ้อน โมดูลข้อมูลที่แข็งแกร่ง)
การลดความซับซ้อนของการพัฒนาซอฟต์แวร์โดยใช้นามธรรมระดับใหม่ (โดยใช้ลำดับชั้นของนามธรรม "ไม่ใช่โปรแกรม" ในการพัฒนาซอฟต์แวร์: การจำแนกประเภทของวัตถุในโลกแห่งความเป็นจริง วิธีการเปรียบเทียบในธรรมชาติ) เป็นระดับใหม่ของ มรดก
15.4. แนวทางวัตถุในการพัฒนาคำอธิบายภายนอกและสถาปัตยกรรมซอฟต์แวร์
การออกแบบเชิงวัตถุเป็นวิธีการที่ใช้การแยกส่วนของวัตถุ วิธีการเชิงวัตถุมีระบบของตัวเอง สัญลักษณ์และเสนอชุดแบบจำลองเชิงตรรกะและเชิงกายภาพที่หลากหลายสำหรับการออกแบบระบบ ระดับสูงความยากลำบาก .
การวิเคราะห์เชิงวัตถุ (OOA) แสดงวิธีการของวัตถุ OOA มีเป้าหมายที่จะสร้างแบบจำลองที่ใกล้เคียงกับความเป็นจริงมากขึ้นโดยใช้วิธีการเชิงวัตถุ เป็นวิธีการที่ความต้องการถูกสร้างขึ้นบนพื้นฐานของแนวคิดของชั้นเรียนและวัตถุที่ประกอบกันเป็นคำศัพท์ของสาขาวิชา .
คุณสมบัติของการเขียนโปรแกรมเชิงวัตถุ
วัตถุ คลาส พฤติกรรมของวัตถุ คุณสมบัติ เหตุการณ์
วรรณกรรมประกอบการบรรยาย15.
15.1. K. Futi, N. Suzuki ภาษาโปรแกรมและวงจร VLSI - ม.: มีร์ 2531 ส. 85-98
15.2. เอียน ซอมเมอร์วิลล์. วิศวกรรมซอฟต์แวร์. - Addison-Wesley Publishing Company, 1992. P. ?-?
15.3. จี บุทช์ การออกแบบเชิงวัตถุพร้อมตัวอย่างการใช้งาน: ต่อ. จากอังกฤษ. - ม.: คองคอร์ด, 2535.
15.4. วี.ช.คอฟแมน ภาษาโปรแกรม. แนวคิดและหลักการ. มอสโก: วิทยุและการสื่อสาร 2536
เจ. ฮิวจ์ส, เจ. มิชทอม. แนวทางโครงสร้างในการเขียนโปรแกรม - ม.: มีร์, 2523. - น. 29-71.
วี. เตอร์สกี้. วิธีการเขียนโปรแกรม - ม.: มีร์, 2524. - หน้า 90-164.
อีเอ โซโกเลฟ รากฐานทางเทคโนโลยีของการเขียนโปรแกรมแบบแยกส่วน // การเขียนโปรแกรม 1980 หมายเลข 2 - หน้า 44-49.
อาร์. ซี. โฮลท์ โครงสร้างโปรแกรมคอมพิวเตอร์: การสำรวจ // การดำเนินการของ IEEE, 1975, 63(6) - หน้า 879-893.
จี. ไมเออร์. ความน่าเชื่อถือของซอฟต์แวร์ - ม.: มีร์, 2523. - น. 92-113.
ไอ.ไพล. ADA เป็นภาษาของระบบฝังตัว ม.: การเงินและสถิติ 2527. - น. 67-75.
เอ็ม. เซลโคเวตส์, เอ. ชอว์, เจ. แกนนอน หลักการพัฒนาซอฟต์แวร์ - ม.: มีร์, 2525, น. 65-71.
A.L. Fuksman. ด้านเทคโนโลยีของการสร้าง ระบบซอฟต์แวร์. ม.: สถิติ 2522 - น. 79-94.
ข้าว. 8.4. ตัวอย่างรายละเอียดขั้นตอนหนึ่งในรหัสเทียม
กำลังโหลด...