อะไรคืออุปสรรคที่ขัดขวางการยอมรับวิธีการอย่างเป็นทางการ? [ปิด]

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

ทำไมเราไม่ใช้มันบ่อยกว่าสำหรับการเขียนโปรแกรมทุกวันหรือในเว็บแอปพลิเคชัน ฯลฯ ...

การอ้างอิง:

• วิธีการอย่างเป็นทางการ
• วิธีการ B
• Hoare Logic

วิศวกรคือคนที่สามารถทำได้ด้วยเงินดอลล่าร์ที่คนงี่เง่าคนไหนสามารถทำได้ 10

ข้อ จำกัด ด้านทรัพยากรข้อ จำกัด ด้านงบประมาณข้อ จำกัด ด้านเวลาล้วนมีความสำคัญ

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

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

ในการเขียนโปรแกรมหรือไม่ที่จะเขียนโปรแกรม?

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

ทำสิ่งที่ถูกต้องหรือทำสิ่งที่ถูกต้อง?

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

ข้อกำหนดที่คุณใช้งานอยู่อาจไม่สมบูรณ์หรือคลุมเครือ พวกเขาอาจจะบั๊กกี้ ในกรณีที่เลวร้ายที่สุดความต้องการที่แท้จริงยังไม่ได้แสดงออก แต่ภาพมีค่าหนึ่งพันคำเพียงแค่ภาพ google สำหรับ "สิ่งที่ลูกค้าต้องการ" ตัวอย่างเช่นจากบทความนี้ :

ค่าใช้จ่ายของพิธีการ

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

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

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

ในทางปฏิบัติ

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

อัปเดต: ความพยายามที่วัดได้

ในฉบับเดือนตุลาคม 2018 Communications of the ACMมีบทความที่น่าสนใจเกี่ยวกับซอฟต์แวร์ที่ได้รับการยืนยันอย่างเป็นทางการในโลกแห่งความเป็นจริงโดยมีการประมาณความพยายามบางอย่าง

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

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

การออกแบบ seL4 และการพัฒนาโค้ดใช้เวลาสองคนต่อปี การเพิ่มหลักฐานเชิงประจักษ์ทั้งหมดในช่วงหลายปีที่ผ่านมามีทั้งหมด 18 คนต่อปีสำหรับรหัส C 8,700 บรรทัด ในการเปรียบเทียบ L4Ka :: Pistachio ซึ่งเป็น microkernel อีกตัวในตระกูล L4 ซึ่งมีขนาดใกล้เคียงกับ seL4 ใช้เวลาหกปีในการพัฒนาและไม่มีความมั่นใจในระดับนัยสำคัญ ซึ่งหมายความว่ามีเพียงปัจจัย3.3ระหว่างซอฟต์แวร์ที่ได้รับการตรวจสอบและซอฟต์แวร์ที่ออกแบบมาแบบดั้งเดิม ตามวิธีการประเมินโดย Colbert และ Boehm การรับรองมาตรฐานสามัญ EAL7 แบบดั้งเดิม 8 ข้อสำหรับรหัส C 8,700 บรรทัดจะใช้เวลามากกว่า 45.9 คนต่อปี นั่นหมายถึงการตรวจสอบการใช้งานในระดับไบนารีอย่างเป็นทางการนั้นมีมากกว่า2.3 ค่าใช้จ่ายน้อยกว่าระดับการรับรองสูงสุดของ Common Criteria แต่ให้ความเชื่อมั่นที่มากขึ้น

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

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

การแม็พความต้องการระดับสูงกับรายละเอียดระดับล่างนั้นเป็นส่วนสำคัญของการเขียนโปรแกรมจริง ไม่น่าแปลกใจที่งานแกนกลางที่ทำโดยการอ่านและการตีความข้อกำหนดของโปรแกรมเมอร์ไม่สามารถแทนที่ด้วยการโบกมือและพูดว่า 'ตอนนี้เพียงแค่ดูว่าสเปคอย่างเป็นทางการระดับสูงนี้เป็นไปตามโปรแกรมตัวอย่างนี้หรือไม่

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