คำถามติดแท็ก formal-methods

เมื่อเปรียบเทียบกับวิศวกรรมซอฟต์แวร์กับวิศวกรรมโยธาฉันรู้สึกประหลาดใจที่สังเกตวิธีการคิดที่แตกต่าง: วิศวกรโยธาคนใดรู้ว่าถ้าคุณต้องการสร้างกระท่อมเล็ก ๆ ในสวนคุณก็จะได้วัสดุและสร้างมันในขณะที่ถ้าคุณต้องการสร้าง บ้าน 10 ชั้น (หรือบางอย่างเช่นนี้ ) คุณต้องทำคณิตศาสตร์เพื่อให้แน่ใจว่ามันจะไม่พัง ในทางตรงกันข้ามการพูดกับการเขียนโปรแกรมบางส่วนหรืออ่านบล็อกหรือฟอรั่ฉันมักจะพบความเห็นในวงกว้างที่สามารถนำสูตรมากหรือน้อยดังต่อไปนี้: ทฤษฎีและวิธีการอย่างเป็นทางการสำหรับนักคณิตศาสตร์ / นักวิทยาศาสตร์ในขณะที่การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการทำสิ่งต่างๆ สิ่งที่บอกเป็นนัยก็คือการเขียนโปรแกรมเป็นสิ่งที่ใช้งานได้จริงและแม้ว่าวิธีการอย่างเป็นทางการคณิตศาสตร์ทฤษฎีอัลกอริทึมภาษาโปรแกรมสะอาด / เชื่อมโยงกัน ฯลฯ อาจเป็นหัวข้อที่น่าสนใจพวกเขามักไม่จำเป็นถ้าทุกคนต้องการได้สิ่ง เสร็จแล้ว จากประสบการณ์ของฉันฉันจะบอกว่าในขณะที่คุณไม่จำเป็นต้องใช้ทฤษฎีมากในการรวบรวมสคริปต์ 100 บรรทัด (กระท่อม) เพื่อพัฒนาแอปพลิเคชันที่ซับซ้อน (อาคาร 10 ชั้น) คุณต้องมีการออกแบบที่มีโครงสร้าง - วิธีการกำหนดภาษาการเขียนโปรแกรมที่ดีหนังสือข้อความที่ดีที่คุณสามารถค้นหาอัลกอริทึม ฯลฯ ดังนั้น IMO (ปริมาณที่เหมาะสมของ) ทฤษฎีเป็นหนึ่งในเครื่องมือสำหรับการทำสิ่งต่างๆ คำถามของฉันคือทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎี (วิธีการที่เป็นทางการ) และการฝึกฝน ซอฟต์แวร์วิศวกรรม (ซอฟท์แวร์อาคาร) ถูกมองว่าเป็นเรื่อง ง่ายเมื่อเทียบกับวิศวกรรมโยธา (บ้านอาคาร)? หรือทั้งสองสาขาแตกต่างกันจริงๆ (นอกเหนือจากซอฟต์แวร์ที่มีความสำคัญต่อภารกิจแล้วความล้มเหลวของซอฟต์แวร์นั้นเป็นที่ยอมรับได้มากกว่าการสร้างความล้มเหลว) ฉันพยายามสรุปสิ่งที่ฉันเข้าใจจากคำตอบแล้ว ตรงกันข้ามกับวิศวกรรมซอฟต์แวร์ในสาขาวิศวกรรมโยธามันมีความชัดเจนมากขึ้นว่าจำนวนของทฤษฎี (การสร้างแบบจำลองการออกแบบ) เป็นสิ่งจำเป็นสำหรับงานบางอย่าง …

63 programming-practices  theory  formal-methods 

หากคุณได้รับการฝึกอบรมการใช้วิธีการอย่างเป็นทางการ (FM) สำหรับการเขียนโปรแกรม: คุณพบว่ามีประโยชน์อย่างไร การฝึกอบรม FM ของคุณเกี่ยวข้องกับอะไร (เช่นหลักสูตรหนังสือ) คุณใช้เครื่องมือ FM ชนิดใด มีข้อได้เปรียบอะไรบ้างเกี่ยวกับความเร็ว / คุณภาพเมื่อเปรียบเทียบกับคุณที่ไม่ได้ใช้ FM คุณสร้างซอฟต์แวร์ประเภทใดด้วย FM และถ้าคุณไม่ใช้ FM โดยตรงในตอนนี้มันก็คุ้มค่าที่จะเรียนรู้หรือไม่? ฉันอยากรู้ว่าจะได้ยินประสบการณ์ / ความคิดเห็นเกี่ยวกับ FM มากเท่าที่จะพบได้ในชุมชนนี้ ฉันเริ่มอ่านมันและต้องการทราบข้อมูลเพิ่มเติม พื้นหลัง การเขียนโปรแกรมและการพัฒนาซอฟต์แวร์ / วิศวกรรมเป็นทักษะ / อาชีพใหม่ล่าสุดของมนุษย์บนโลกดังนั้นจึงไม่น่าแปลกใจที่สนามยังไม่สมบูรณ์ - ซึ่งแสดงให้เห็นในผลผลิตหลักของสาขาของเราเนื่องจากรหัสที่มักจะล่าช้าและผิดพลาด ยังไม่บรรลุนิติภาวะอุตสาหกรรมจะแสดงด้วยระยะขอบกว้าง (อย่างน้อย 10: 1) ในการผลิตระหว่างตัวแปลงสัญญาณเฉลี่ยและตัวเข้ารหัสสูงสุด ข้อเท็จจริงกลุ้มใจดังกล่าวจะครอบคลุมดีในวรรณคดีและแนะนำให้รู้จักกับหนังสือเช่นสตีฟ McConnell สมบูรณ์รหัส การใช้วิธีการอย่างเป็นทางการ (FM) ได้รับการเสนอโดยบุคคลสำคัญในซอฟต์แวร์ / CS (เช่นE Dijkstraตอนปลาย) ไปยังที่อยู่ …

17 code-quality  formal-methods 

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

14 development-process  code-quality  formal-methods 

Googling "ทฤษฎีการทดสอบซอฟต์แวร์" ดูเหมือนว่าจะให้ทฤษฎีในความหมายที่นุ่มนวลของคำเท่านั้น ฉันไม่สามารถค้นหาสิ่งใดที่จะจัดเป็นทฤษฎีในเชิงคณิตศาสตร์ข้อมูลเชิงทฤษฎีหรือความรู้สึกทางวิทยาศาสตร์อื่น ๆ สิ่งที่ฉันกำลังมองหาคือสิ่งที่เป็นทางการว่าการทดสอบคืออะไรความคิดที่ใช้สิ่งที่กรณีทดสอบคือความเป็นไปได้ของการทดสอบบางสิ่งความเป็นประโยชน์ของการทดสอบบางอย่างขอบเขตของสิ่งที่ควรทดสอบ รหัสครอบคลุม ฯลฯ UPDATE: นอกจากนี้ฉันไม่แน่ใจอย่างสังหรณ์ใจเกี่ยวกับการเชื่อมต่อระหว่างการยืนยันอย่างเป็นทางการกับสิ่งที่ฉันถาม แต่มีการเชื่อมต่อบางอย่างชัดเจน

12 testing  math  theory  formal-methods  information-theory 

ขณะนี้ฉันกำลัง refactoring ส่วนหนึ่งของ codebase ขนาดใหญ่ที่ไม่มีหน่วยทดสอบใด ๆ ฉันพยายาม refactor code ในแบบที่โง่เง่านั่นคือการพยายามเดาว่าโค้ดกำลังทำอะไรและการเปลี่ยนแปลงใดที่จะไม่เปลี่ยนความหมาย แต่ไม่ประสบความสำเร็จ: มันสุ่มแยกคุณสมบัติรอบ ๆ codebase โปรดทราบว่าการเปลี่ยนโครงสร้างรวมถึงการย้ายรหัส C # ดั้งเดิมไปสู่รูปแบบการทำงานที่มากขึ้น (รหัสดั้งเดิมไม่ได้ใช้คุณสมบัติใด ๆ ของ. NET Framework 3 และใหม่กว่ารวมถึง LINQ) การเพิ่มข้อมูลทั่วไปที่รหัสอาจได้รับประโยชน์จากพวกเขาเป็นต้น ฉันไม่สามารถใช้วิธีการที่เป็นทางการได้เพราะจะมีค่าใช้จ่ายเท่าใด ในทางกลับกันฉันคิดว่าอย่างน้อย"กฎใด ๆ ที่ได้รับการปรับเปลี่ยนใหม่จะต้องมาพร้อมกับการทดสอบหน่วย"ควรปฏิบัติตามกฎอย่างเคร่งครัดไม่ว่าจะต้องเสียค่าใช้จ่ายเท่าใด ปัญหาคือเมื่อฉันสร้างส่วนเล็ก ๆ ของวิธีส่วนตัว 500 LOC การเพิ่มการทดสอบหน่วยดูเหมือนจะเป็นงานที่ยาก สิ่งใดที่สามารถช่วยฉันในการรู้ว่าการทดสอบหน่วยใดที่เกี่ยวข้องกับโค้ดบางส่วน ฉันเดาว่าการวิเคราะห์โค้ดแบบคงที่จะมีประโยชน์ แต่เครื่องมือและเทคนิคที่ฉันสามารถใช้เพื่อ: รู้ว่าฉันควรสร้างการทดสอบหน่วยใด และ / หรือทราบว่าการเปลี่ยนแปลงที่ฉันทำมีผลกับรหัสต้นฉบับในแบบที่มันทำงานแตกต่างจากนี้หรือไม่?

10 unit-testing  refactoring  legacy  formal-methods