ทั้งหมดยกเว้นโปรแกรมที่น่ารำคาญที่สุดเต็มไปด้วยข้อบกพร่องและดังนั้นสิ่งที่สัญญาว่าจะลบออกนั้นมีเสน่ห์อย่างมาก ในขณะนี้การพิสูจน์ความถูกต้องเป็นรหัสมีความลับอย่างมากส่วนใหญ่เป็นเพราะการเรียนรู้อย่างยากลำบากและความพยายามพิเศษที่ใช้ในการพิสูจน์โปรแกรมที่ถูกต้อง คุณคิดว่าการพิสูจน์โค้ดนั้นจะเกิดขึ้นไหม?
คำตอบ:
ไม่ใช่ในแง่นั้นจริงๆ แต่การเขียนโปรแกรมฟังก์ชั่นที่บริสุทธิ์นั้นดีในโดเมนนี้ หากคุณใช้ Haskell อาจเป็นไปได้ว่าโปรแกรมของคุณถูกต้องหากรหัสรวบรวม ยกเว้นจาก IO ระบบชนิดที่ดีคือความช่วยเหลือที่ดี
นอกจากนี้การเขียนโปรแกรมไปยังสัญญาจะเป็นประโยชน์ ดูสัญญารหัสของ Microsoft
ทั้งหมดยกเว้นรายการเล็กน้อยที่สุด
ไม่สามารถพิสูจน์ได้อย่างสมบูรณ์ว่าถูกต้องด้วยความพยายามตามสมควร สำหรับการพิสูจน์ความถูกต้องอย่างเป็นทางการคุณต้องมีสเป็คอย่างเป็นทางการอย่างน้อยและสเป็คนั้นต้องสมบูรณ์และถูกต้อง นี่คือสิ่งที่คุณไม่สามารถสร้างได้ง่ายสำหรับโปรแกรมที่ใช้งานจริงส่วนใหญ่ ตัวอย่างเช่นลองเขียนข้อมูลจำเพาะสำหรับสิ่งที่ต้องการอินเทอร์เฟซผู้ใช้ของไซต์การสนทนานี้และคุณรู้ว่าฉันหมายถึงอะไร
ที่นี่ฉันพบบทความที่ดีในหัวข้อ:
http://www.encyclopedia.com/doc/1O11-programcorrectnessproof.html
printf("1")ถูกต้องหรือไม่ (ตัวอย่างเช่นเนื่องจากข้อกำหนดคือ "พิมพ์ตัวเลขสุ่มที่กระจายแบบเท่า ๆ กันจาก 1 ถึง 6") ไม่สามารถตัดสินใจได้โดยตัววิเคราะห์แบบคงที่
ปัญหาเกี่ยวกับการพิสูจน์อย่างเป็นทางการก็คือมันจะย้ายปัญหากลับขั้นตอน
การบอกว่าโปรแกรมนั้นถูกต้องเทียบเท่ากับการบอกว่าโปรแกรมทำในสิ่งที่ควรทำ คุณจะกำหนดสิ่งที่โปรแกรมควรทำอย่างไร คุณระบุมัน และคุณจะกำหนดว่าโปรแกรมควรทำอย่างไรในกรณีขอบที่สเป็คไม่ครอบคลุม? งั้นคุณต้องทำให้สเป็คมีรายละเอียดมากขึ้น
สมมุติว่าสเป็คของคุณมีรายละเอียดเพียงพอที่จะอธิบายพฤติกรรมที่ถูกต้องของทุกแง่มุมของโปรแกรมทั้งหมด ตอนนี้คุณต้องการวิธีที่จะทำให้เครื่องมือพิสูจน์ของคุณเข้าใจ ดังนั้นคุณต้องแปลสเป็คเป็นภาษาทางการบางอย่างที่เครื่องมือพิสูจน์เข้าใจได้ ... เฮ้รอสักครู่!
การตรวจสอบอย่างเป็นทางการมาไกล แต่โดยปกติแล้วเครื่องมือในอุตสาหกรรม / ที่ใช้กันอย่างแพร่หลายจะล้าหลังการวิจัยล่าสุด นี่คือความพยายามล่าสุดในทิศทางนี้:
Spec # http://research.microsoft.com/en-us/projects/specsharp/ นี่คือส่วนขยายของ C # ที่รองรับสัญญาโค้ด (เงื่อนไขก่อน / หลังและผู้แปรปรวน) และสามารถใช้สัญญาเหล่านี้เพื่อทำการวิเคราะห์แบบคงที่ประเภทต่างๆ .
โครงการที่คล้ายกันนี้มีอยู่สำหรับภาษาอื่นเช่น JML สำหรับ java และ Eiffel มีสิ่งนี้ในตัว
จะยิ่งโครงการเช่นสแลมและระเบิดสามารถนำมาใช้ในการตรวจสอบคุณสมบัติพฤติกรรมบางอย่างกับโปรแกรมเมอร์น้อยที่สุดคำอธิบายประกอบ / แทรกแซง แต่ก็ยังไม่สามารถจัดการกับทั่วไปเต็มรูปแบบของภาษาสมัยใหม่ (สิ่งที่ต้องการจำนวนเต็มล้น / คำนวณตัวชี้ยังไม่ได้สร้างแบบจำลอง)
ฉันเชื่อว่าเราจะเห็นเทคนิคเหล่านี้มากขึ้นที่ใช้ในการฝึกฝนในอนาคต อุปสรรคหลักคือค่าคงที่ของโปรแกรมนั้นยากที่จะอนุมานโดยไม่มีการเพิ่มความคิดเห็นด้วยตนเองและโปรแกรมเมอร์มักไม่เต็มใจที่จะให้คำอธิบายประกอบเหล่านี้เพราะการทำเช่นนั้นน่าเบื่อ / ใช้เวลานานเกินไป
ไม่เว้นแต่จะมีวิธีการพิสูจน์โค้ดโดยอัตโนมัติโดยไม่มีงานของนักพัฒนาซอฟต์แวร์เกิดขึ้น
เครื่องมือวิธีที่เป็นทางการบางอย่าง (เช่นFrama-Cสำหรับซอฟต์แวร์ฝังตัว C ที่สำคัญ) สามารถดูได้ว่าเป็น (การเรียงลำดับ) การจัดเตรียมหรืออย่างน้อยการตรวจสอบการพิสูจน์ความถูกต้องของซอฟต์แวร์ที่กำหนด (Frama-C ตรวจสอบว่าโปรแกรมปฏิบัติตามข้อกำหนดอย่างเป็นทางการในบางแง่และเคารพค่าคงที่ที่มีคำอธิบายประกอบอย่างชัดเจนในโปรแกรม)
ในบางส่วนอาจใช้วิธีการอย่างเป็นทางการเช่นDO-178Cสำหรับซอฟต์แวร์สำคัญในเครื่องบินพลเรือน ดังนั้นในบางกรณีแนวทางดังกล่าวเป็นไปได้และเป็นประโยชน์
แน่นอนว่าการพัฒนาซอฟต์แวร์รถบั๊กน้อยนั้นมีค่าใช้จ่ายสูงมาก แต่วิธีการแบบเป็นทางการเหมาะสมสำหรับซอฟต์แวร์บางประเภท หากคุณพูดในแง่ร้ายคุณอาจคิดว่าข้อผิดพลาดจะถูกย้ายจากโค้ดไปเป็นสเปคอย่างเป็นทางการ (ซึ่งอาจมี "บั๊ก" บางส่วนเนื่องจากการทำให้พฤติกรรมที่เป็นทางการของซอฟต์แวร์เป็นเรื่องยากและมีแนวโน้มผิดพลาด)
ฉันสะดุดกับคำถามนี้และฉันคิดว่าลิงก์นี้อาจน่าสนใจ:
การใช้งานในอุตสาหกรรมของAstrée
การพิสูจน์ว่าไม่มี RTE ในระบบที่ใช้โดยแอร์บัสที่มีโค้ดมากกว่า 130K ในปี 2003 ดูเหมือนจะไม่เลวและฉันสงสัยว่าจะมีใครบอกว่านี่ไม่ใช่โลกแห่งความเป็นจริง
ไม่สุภาษิตทั่วไปสำหรับเรื่องนี้คือ "ในทางทฤษฎีทฤษฎีและการปฏิบัติเหมือนกันในทางปฏิบัติไม่ใช่"
ตัวอย่างง่ายๆหนึ่งอย่าง: Typos
การใช้งานรหัสจริงผ่านการทดสอบหน่วยค้นหาสิ่งต่าง ๆ เกือบจะในทันทีและชุดการทดสอบที่เหนียวแน่นจะลบล้างความจำเป็นในการพิสูจน์อย่างเป็นทางการ กรณีการใช้งานทั้งหมด - ดี, ไม่ดี, ข้อผิดพลาดและกรณีขอบ - ควรระบุในการทดสอบหน่วยซึ่งท้ายสุดเป็นข้อพิสูจน์ที่ดีกว่ารหัสนั้นถูกต้องกว่าการพิสูจน์ใด ๆ ที่แยกจากรหัส
โดยเฉพาะอย่างยิ่งหากความต้องการเปลี่ยนแปลงหรืออัลกอริทึมได้รับการปรับปรุงเพื่อแก้ไขข้อบกพร่อง - การพิสูจน์อย่างเป็นทางการมีแนวโน้มที่จะล้าสมัยเช่นเดียวกับความคิดเห็นของรหัสมักจะได้รับ
ฉันคิดว่าข้อ จำกัด ที่กำหนดไว้ในการพิสูจน์ความถูกต้องเนื่องจากปัญหาการหยุดชะงักอาจเป็นอุปสรรคที่ใหญ่ที่สุดในการพิสูจน์ความถูกต้องกลายเป็นกระแสหลัก
มันถูกใช้โดยทุกคนแล้ว ทุกครั้งที่คุณใช้การตรวจสอบประเภทภาษาการเขียนโปรแกรมของคุณคุณจะต้องทำการพิสูจน์ทางคณิตศาสตร์ของความถูกต้องของโปรแกรมของคุณ วิธีนี้ใช้ได้ผลดีมาก - คุณเพียงแค่ต้องเลือกประเภทที่ถูกต้องสำหรับทุกฟังก์ชั่นและโครงสร้างข้อมูลที่คุณใช้ ยิ่งมีความแม่นยำมากเท่าไหร่การตรวจสอบของคุณก็จะยิ่งดีขึ้นเท่านั้น ประเภทที่มีอยู่ในภาษาการเขียนโปรแกรมมีเครื่องมือที่ทรงพลังพอที่จะอธิบายพฤติกรรมที่เป็นไปได้เกือบทั้งหมด ใช้ได้กับทุกภาษา C ++ และภาษาสแตติกกำลังทำการตรวจสอบในเวลาคอมไพล์ขณะที่ภาษาไดนามิกมากขึ้นเช่นไพ ธ อนกำลังทำเมื่อโปรแกรมรัน การตรวจสอบยังคงมีอยู่ในทุกภาษาเหล่านี้ (ตัวอย่างเช่น c ++ รองรับการตรวจสอบผลข้างเคียงเช่นเดียวกับที่ haskell ทำ
mutable const_castแน่นอนฉันเห็นการเชื่อมต่อที่คุณวาดที่นั่น แต่รสชาติของสองวิธีดูเหมือนจะค่อนข้างแตกต่างจากฉัน