การตรวจสอบโปรแกรมอย่างเป็นทางการในทางปฏิบัติ

ในฐานะวิศวกรซอฟต์แวร์ฉันเขียนโค้ดจำนวนมากสำหรับผลิตภัณฑ์อุตสาหกรรม สิ่งที่ค่อนข้างซับซ้อนกับคลาส, เธรด, ความพยายามในการออกแบบบางอย่าง แต่ยังมีบางอย่างที่ทำให้ประสิทธิภาพลดลง ฉันทำการทดสอบจำนวนมากและฉันเหนื่อยกับการทดสอบดังนั้นฉันจึงสนใจในเครื่องมือพิสูจน์อย่างเป็นทางการเช่น Coq, Isabelle ... ฉันสามารถใช้สิ่งเหล่านี้เพื่อพิสูจน์อย่างเป็นทางการว่ารหัสของฉันปราศจากข้อบกพร่องและสามารถทำได้ ด้วยหรือ - แต่ทุกครั้งที่ฉันตรวจสอบหนึ่งในเครื่องมือเหล่านี้ฉันเดินออกไปโดยไม่มั่นใจว่าพวกเขาสามารถใช้งานได้สำหรับวิศวกรรมซอฟต์แวร์ทุกวัน ตอนนี้นั่นอาจเป็นฉันเท่านั้นและฉันกำลังมองหาตัวชี้ / ความคิดเห็น / ความคิดเกี่ยวกับที่ :-)

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

ใครบางคนที่มีประสบการณ์มากขึ้นเกี่ยวกับเครื่องมือพิสูจน์ความคิดเห็นอย่างเป็นทางการ? อีกครั้ง - ฉันจะรักในการใช้เครื่องมือสอบมาตรอย่างเป็นทางการผมคิดว่าพวกเขาจะดี แต่ผมมีความประทับใจที่พวกเขาอยู่ในหอคอยงาช้างที่ฉันไม่สามารถเข้าถึงได้จากคูต่ำต้อยของ Java / C ++ ... (PS: ผม ยังรัก Haskell, OCaml ... ไม่ได้รับความคิดที่ผิด: ฉันเป็นแฟนของภาษาที่เปิดเผยและหลักฐานอย่างเป็นทางการผมแค่พยายามที่จะดูว่าฉันจะทำให้แนบเนียนที่มีประโยชน์ในการวิศวกรรมซอฟต์แวร์)

อัปเดต: เนื่องจากนี่เป็นคำถามที่ค่อนข้างกว้างลองทำคำถามที่เฉพาะเจาะจงต่อไปนี้: 1) มีตัวอย่างของการใช้ตัวพิสูจน์เพื่อพิสูจน์ความถูกต้องของโปรแกรม Java / C ++ อุตสาหกรรมหรือไม่ 2) Coq เหมาะสำหรับงานนั้นหรือไม่? 3) ถ้า Coq เหมาะสมฉันควรเขียนโปรแกรมใน Coq ก่อนจากนั้นสร้าง C ++ / Java จาก Coq? 4) วิธีการนี้สามารถจัดการเธรดและการเพิ่มประสิทธิภาพได้หรือไม่?

ฉันจะพยายามให้คำตอบสั้น ๆ กับคำถามของคุณ โปรดทราบว่านี่ไม่ใช่งานวิจัยของฉันอย่างเคร่งครัดดังนั้นข้อมูลบางอย่างของฉันอาจล้าสมัย / ไม่ถูกต้อง

1. มีเครื่องมือมากมายที่ออกแบบมาเป็นพิเศษเพื่อพิสูจน์คุณสมบัติของ Java และ C ++ อย่างเป็นทางการ

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

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

2. เมื่อคุณมีข้อกำหนดของคุณคุณต้องพิสูจน์ว่าโปรแกรมนั้นสอดคล้องกับข้อกำหนดนั้น

   สำหรับสิ่งนี้คุณต้องมีเครื่องมือที่มีความเข้าใจอย่างเป็นทางการทั้งในสเปคของคุณและความหมายในการปฏิบัติงานของภาษาของคุณ (Java หรือ C ++) เพื่อแสดงทฤษฎีบทความเพียงพอนั่นคือการดำเนินการของโปรแกรม

   เครื่องมือนี้ควรอนุญาตให้คุณกำหนดหรือสร้างหลักฐานของทฤษฎีบทนั้น ตอนนี้งานทั้งสองอย่างนี้ (การระบุและการพิสูจน์) นั้นค่อนข้างยากดังนั้นจึงมักแยกออกเป็นสองส่วน:

   • เครื่องมือหนึ่งที่แยกวิเคราะห์รหัสข้อมูลจำเพาะและสร้างทฤษฎีบทความเพียงพอ ดังที่แฟรงค์กล่าวถึงKrakatoaเป็นตัวอย่างของเครื่องมือดังกล่าว

   • เครื่องมือหนึ่งที่พิสูจน์ทฤษฎีบทโดยอัตโนมัติหรือแบบโต้ตอบได้ Coq โต้ตอบกับ Krakatoa ในลักษณะนี้และมีเครื่องมืออัตโนมัติที่ทรงพลังเช่นZ3ซึ่งสามารถใช้งานได้

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

3. หากคุณต้องการสร้างรหัส Ocaml ให้เขียนเป็น Coq (Gallina) ก่อนจากนั้นจึงคลายรหัส อย่างไรก็ตาม Coq แย่มากในการสร้าง C ++ หรือ Java ถ้าเป็นไปได้

4. เครื่องมือด้านบนสามารถจัดการกับเธรดและปัญหาด้านประสิทธิภาพได้หรือไม่? อาจไม่มีประสิทธิภาพและความกังวลเกี่ยวกับเกลียวได้รับการจัดการที่ดีที่สุดโดยเครื่องมือที่ออกแบบมาโดยเฉพาะเนื่องจากเป็นปัญหาที่ยากโดยเฉพาะ ฉันไม่แน่ใจว่าฉันมีเครื่องมือที่จะแนะนำที่นี่ แต่โครงการPolyNIของ Martin Hofmann น่าสนใจ

โดยสรุป: การตรวจสอบอย่างเป็นทางการของโปรแกรม Java และ C ++ เป็นฟิลด์ที่มีขนาดใหญ่และได้รับการพัฒนาอย่างดีและ Coq เหมาะสำหรับส่วนของงานนั้น คุณสามารถค้นหาภาพรวมระดับสูงได้ที่นี่เช่น

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

1. เครื่องมือJava Pathfinderโอเพนซอร์ส(JPF สำหรับย่อ) ที่เผยแพร่โดย NASA ในปี 2005เป็นระบบเพื่อตรวจสอบโปรแกรม Java bytecode ที่ปฏิบัติการได้ (ดูJava Pathfinder @ wiki ) มันถูกใช้เพื่อตรวจสอบความไม่สอดคล้องกันในซอฟต์แวร์สำหรับผู้บริหารของ K9 Rover ที่ NASA Ames

2. เอกสารนี้: การใช้การตรวจสอบรุ่นเพื่อค้นหาข้อผิดพลาดร้ายแรงของระบบไฟล์ @ OSDI'04แสดงวิธีใช้การตรวจสอบรุ่นเพื่อค้นหาข้อผิดพลาดร้ายแรงในระบบไฟล์ ระบบที่เรียกว่า FiSC ถูกนำไปใช้กับระบบไฟล์ที่ใช้กันอย่างแพร่หลายสามระบบที่ผ่านการทดสอบอย่างหนัก: ext3, JFS และ ReiserFS และพบข้อบกพร่องร้ายแรง 32 ข้อ ได้รับรางวัล Best Paper Award

3. บทความนี้: วิธีที่ Amazon Web Services ใช้วิธีการที่เป็นทางการ @ CACM'15อธิบายถึงวิธีการที่ AWS ใช้วิธีการที่เป็นทางการกับผลิตภัณฑ์เช่น S3, DynamoDB, EBS และตัวจัดการการล็อคแบบกระจายภายใน มันมุ่งเน้นไปที่เครื่องมือTLA + ของ Lamport โดยวิธีการ Lamport ได้ใช้กล่องเครื่องมือ TLA ของตัวเองอย่างเข้มข้น เขามักจะให้การตรวจสอบอย่างเป็นทางการ (ค่อนข้างสมบูรณ์) ใน TLA ของอัลกอริทึม / ทฤษฎีบทที่เสนอโดยตัวเอง (เช่นเดียวกับผู้เขียนร่วม) ในภาคผนวกกับเอกสาร

ข้อกำหนดอย่างเป็นทางการของโปรแกรมคือ (มากหรือน้อย) โปรแกรมที่เขียนด้วยภาษาโปรแกรมอื่น ดังนั้นข้อกำหนดจะรวมข้อบกพร่องของตัวเองอย่างแน่นอน

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

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

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

การตรวจสอบอย่างเป็นทางการตอนนี้เป็นไปได้สำหรับโปรแกรมที่เขียนชุดย่อย C ++ ที่ออกแบบมาสำหรับระบบฝังตัวที่ปลอดภัย ดูhttp://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pptสำหรับการนำเสนอสั้น ๆ และhttp://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdfสำหรับบทความฉบับเต็ม

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

คุณพูดว่า "ฉันเบื่อการทดสอบ" แต่การตรวจสอบอย่างเป็นทางการไม่ใช่การทดสอบแทนจริงๆ ในรูปแบบของการทดสอบ

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

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

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

นี่คือตัวอย่างของการสำรวจของเครื่องมือการตรวจสอบอย่างเป็นทางการในด้าน EE โดยหนึ่งLars Philipson

บางทีตัวตรวจสอบรุ่นอาจมีประโยชน์

http://alloytools.org/documentation.html Alloy เป็นตัวตรวจสอบรุ่น

การนำเสนอที่ดีอธิบายแนวคิดของการตรวจสอบแบบจำลองโดยใช้ Alloy: https://www.youtube.com/watch?v=FvNRlE4E9QQ

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