Làm thế nào chúng ta có thể biết rằng các phương pháp chính thức hoạt động?

Một mục tiêu quan trọng của các phương pháp chính thức là chứng minh tính đúng đắn của các hệ thống, bằng phương tiện tự động hoặc hướng đến con người. Tuy nhiên, dường như ngay cả khi bạn có thể đưa ra bằng chứng chính xác, bạn vẫn KHÔNG thể đảm bảo rằng hệ thống sẽ không bị lỗi. Ví dụ:

• Thông số kỹ thuật có thể không mô hình hệ thống chính xác hoặc hệ thống sản xuất có thể quá phức tạp để mô hình hóa hoặc hệ thống có thể bị thiếu sót do các yêu cầu mâu thuẫn. Những kỹ thuật nào được biết để kiểm tra xem một đặc điểm kỹ thuật có ý nghĩa gì không?
• Quá trình chứng minh có thể là thiếu sót quá! Ai biết rằng những quy tắc suy luận là chính xác và hợp pháp? Hơn nữa, bằng chứng có thể rất lớn, và làm thế nào để chúng ta biết rằng chúng không chứa lỗi? Đây là trung tâm của bài phê bình trong "Các quy trình xã hội và bằng chứng về các định lý và chương trình" của de Millo, Lipton và Perlis. Làm thế nào để các nhà nghiên cứu phương pháp chính thức hiện đại phản ứng với phê bình này?
• Trong thời gian chạy, có nhiều sự kiện và yếu tố không xác định có thể ảnh hưởng nghiêm trọng đến hệ thống. Ví dụ, các tia vũ trụ có thể thay đổi RAM theo những cách không thể đoán trước và nói chung, chúng tôi không đảm bảo rằng phần cứng sẽ không bị lỗi Byzantine, điều Lamport đã chứng minh là rất khó để chống lại. Vì vậy, tính chính xác của hệ thống tĩnh không đảm bảo hệ thống sẽ không bị lỗi! Có bất kỳ kỹ thuật nào được biết đến cho tính khả thi của phần cứng thực sự?
• Hiện tại, kiểm thử là công cụ quan trọng nhất mà chúng tôi có để thiết lập phần mềm đó hoạt động. Có vẻ như nó phải là một công cụ bổ sung với các phương thức chính thức. Tuy nhiên, tôi chủ yếu thấy nghiên cứu tập trung vào các phương pháp chính thức hoặc thử nghiệm. Kết hợp cả hai là gì?

Về 4: Có rất nhiều công việc kết hợp các phương pháp và thử nghiệm chính thức. Googling "thử nghiệm phương pháp chính thức" cho thấy khối lượng công việc khá lớn. Mặc dù có nhiều mục tiêu khác nhau của công việc như vậy, một trong những mục tiêu chính là tạo ra các bộ thử nghiệm hiệu quả hơn. Bài nói chuyện này đưa ra một giới thiệu tốt đẹp, dựa trên kiểm tra mô hình.

Cũng liên quan đến vấn đề bảo mật phần mềm , đã được chỉnh sửa ra khỏi câu hỏi: các phương pháp chính thức cần phải làm việc chăm chỉ hơn để cung cấp trong lĩnh vực đó. Thông thường, người ta viết một đặc tả cho một phần mềm và xác minh rằng đặc tả đó được thỏa mãn, cụ thể là khi đầu vào thỏa mãn điều kiện tiên quyết là đầu ra thỏa mãn điều kiện hậu. Để đảm bảo phần mềm bảo mật, người ta cũng cần kiểm tra xem phần mềm có hoạt động hợp lý cho đầu vào không thỏa mãn điều kiện tiên quyết hay không. . vi phạm các giả định của nó.

Về điểm 3: Một số công việc đã được thực hiện để xác minh các hệ thống trong các cài đặt trong đó các lỗi được mô hình hóa rõ ràng, bao gồm Logic Lỗi: Lý do về các Chương trình chịu lỗi. Matthew Meola và David Walker. Hội nghị chuyên đề châu Âu về lập trình, 2010. Làm việc về kiểm tra mô hình xác suất và xác minh xác suất chắc chắn cả hai cũng giải quyết vấn đề lỗi ở một mức độ nào đó.

Điểm của bạn theo thứ tự:

• Tính chính xác của tất cả các thông số kỹ thuật cuối cùng là chủ quan: chúng được nhận thức để giải quyết vấn đề một cách chính xác theo người dùng của họ hoặc họ không. Không thể tránh khỏi điều này là phát triển phần mềm và không có phương pháp nào có viên đạn bạc cho cái này.
• Rất nhiều công việc đi vào chứng minh rằng quy trình này là chính xác đối với các giả định của nó. Thông thường có thông tin có sẵn cho các chuyên gia để xác nhận các quy tắc này. Bất kỳ hoạt động nào của con người đều có lỗi nhưng các hệ thống rất chính thức sử dụng các phương pháp được nghiên cứu kỹ sẽ ít bị lỗi hơn hầu hết các quy trình khác của con người.
• Tại một số điểm, bất kỳ hệ thống nào cũng có chế độ thất bại ngoài phạm vi của hệ thống đó. Bạn vẫn nên loại bỏ tất cả các nguồn lỗi có thể dự đoán được , ngay cả khi bạn để lại một số lỗi không dự đoán được.
• Kiểm tra và chứng minh có thể dễ dàng cùng tồn tại. Thử nghiệm là một cụ thể ít hơn, nhiều quảng cáo hoc quá trình, vì vậy bạn có thể tìm được việc làm không chính thức thực hiện trên nó. Nhưng bạn có thể quan tâm đến một công cụ như QuickCheck bổ sung bằng các bài kiểm tra bằng chứng được cung cấp bởi hệ thống loại Haskell.

Các phương pháp chính thức đã được chứng minh là có tác dụng lớn. Không có chúng, chúng tôi sẽ không thể đối phó với sự phức tạp của việc thiết kế các hệ thống kỹ thuật số hiện đại (bộ vi xử lý).

Không có tàu vi mô mà không có logic của nó để xác minh tương đương chức năng; không có FPU của nó đã chịu FV; không có giao thức kết hợp bộ đệm của nó đã chịu sự điều chỉnh của FV (điều này đã xảy ra từ năm 1995).

Không có sự khác biệt rõ ràng giữa phần mềm và các hệ thống vật lý được thiết kế (ví dụ như cầu nối, nơi người ta có thể thêm các yếu tố an toàn), chúng đóng vai trò của toán kỹ thuật trong CS. Tuy nhiên, việc sử dụng FM luôn phụ thuộc vào lợi ích / chi phí. Thử nghiệm Fuzz trả hết thời gian lớn tại các công ty như Microsoft (Google SAGE trong một slide).

Ngay cả trong một vi mô, vẫn có các hệ thống con (ví dụ: đường ống vi xử lý), trong đó FV không có tác động tương tự như ở nơi khác (ví dụ: FPU, trong đó nhiều thử nghiệm thông thường không được thực hiện trong nhiều trường hợp khi đánh giá quỹ đạo biểu tượng chính thức đã chứng minh sự vắng mặt của lỗi : Kaivola et al CAV'09).

Các phương pháp chính thức cũng đang được sử dụng trong việc tổng hợp các vật phẩm (mã, kiểm tra chất lượng cao, lịch trình để tiêu hao tối ưu các ngân hàng pin, ...). Tất nhiên, tất cả các vấn đề được nêu trong câu hỏi đều khá hợp lệ và giống như trong bất kỳ việc sử dụng công nghệ nào khác, quảng cáo sai phải được nhận ra và tránh.

Về 2: nếu hệ thống được chính thức hóa trong một trợ lý chứng minh (ví dụ Twelf hoặc Agda hoặc Coq) và các thuộc tính của âm thanh và tính đầy đủ được xác minh và bằng chứng được thực hiện trong mã hóa này, đây không phải là vấn đề. Bạn có thể đã chính thức hóa một hệ thống không mô tả những gì bạn dự định, nhưng ít nhất bạn sẽ không có bằng chứng không chính xác hoặc một hệ thống bị hỏng mà bạn đang suy luận.

Tuy nhiên, dường như ngay cả khi bạn có thể đưa ra bằng chứng chính xác, bạn vẫn KHÔNG thể đảm bảo rằng hệ thống sẽ không bị lỗi.

Vâng, có lẽ không có gì đảm bảo . Các phương pháp chính thức có nghĩa là tìm và loại bỏ lỗi và thuyết phục con người.

Những kỹ thuật nào được biết để kiểm tra xem một đặc điểm kỹ thuật có ý nghĩa gì không?

Bạn có thể quan tâm đến các công cụ kiểm tra mô hình cho các thông số kỹ thuật của các hệ thống chính thức .

Quá trình chứng minh có thể là thiếu sót quá! Ai biết rằng những quy tắc suy luận là chính xác và hợp pháp?

Tôi nghĩ (vì định lý không hoàn chỉnh của Goedel) cho thấy một hệ thống các quy tắc suy luận là nhất quán sẽ hấp dẫn một tập hợp các quy tắc suy luận thậm chí còn mạnh mẽ hơn.

Hơn nữa, bằng chứng có thể rất lớn, và làm thế nào để chúng ta biết rằng chúng không chứa lỗi?

Hy vọng, bằng chứng khổng lồ được kiểm tra bởi một người kiểm tra bằng chứng nhỏ có thể được đọc và hiểu bởi con người trong một khoảng thời gian hợp lý. Điều này đôi khi được gọi là "tiêu chí de Bruijn". Nếu bạn tin rằng người kiểm tra bằng chứng sẽ không chứng nhận bằng chứng không chính xác, bạn chỉ cần kiểm tra người kiểm tra.

Có bất kỳ kỹ thuật nào được biết đến cho tính khả thi của phần cứng thực sự?

Làm thế nào về Fault khoan dung gõ ngôn ngữ lắp ráp ?

Tuy nhiên, tôi chủ yếu thấy nghiên cứu tập trung vào các phương pháp chính thức hoặc thử nghiệm. Kết hợp cả hai là gì?

"Hội nghị TAP dành cho việc hội tụ các bằng chứng và bài kiểm tra" .

Chỉ cần googling cho "bằng chứng và bài kiểm tra" có một số lượt truy cập tốt trên màn hình đầu tiên.

Những kỹ thuật nào được biết để kiểm tra xem một đặc điểm kỹ thuật có ý nghĩa gì không?

Nó chắc chắn là một cuộc gọi phán xét. Trong công nghệ phần mềm, mọi người đã thiết kế phương pháp rất nghiêm ngặt để tìm / ghi / xác nhận các thông số kỹ thuật. Điều này được thực hiện bởi con người thực và sử dụng một quy trình không chính thức (theo nghĩa không phải là toán học), do đó, nó vẫn phải chịu sự không nhất quán, nhưng vào cuối ngày, nó tương ứng với những gì mọi người muốn xác minh, không hơn không kém.

Có bất kỳ kỹ thuật nào được biết đến cho tính khả thi của phần cứng thực sự?

Chắc chắn, có một lĩnh vực xác minh được gọi là xác minh thời gian chạy , bạn cũng có thể sử dụng kiểm tra mô hình dựa trên thực thi trên hệ thống thực chạy trên môi trường hoàn toàn ảo theo kịch bản cụ thể (tôi đã đóng góp cho điều này với V-DS + APMC ). Tuy nhiên, đây rõ ràng là một vấn đề lớn để thêm sự tương tác giữa hệ thống và môi trường vào quá trình xác minh.

Tuy nhiên, tôi chủ yếu thấy nghiên cứu tập trung vào các phương pháp chính thức hoặc thử nghiệm. Kết hợp cả hai là gì?

Wow, hôm nay tôi sẽ hoàn toàn không biết xấu hổ và tự trích dẫn lại. Với các đồng tác giả, chúng tôi làm việc kết hợp kiểm tra và kiểm tra mô hình, bạn có thể xem danh sách xuất bản của một cựu nghiên cứu sinh của nhóm chúng tôi hoặc tìm kiếm "kiểm tra mô hình xác suất gần đúng" hoặc "kiểm tra mô hình thống kê" trong bất kỳ công cụ tìm kiếm tốt nào (công việc được thực hiện bởi Younes và cộng sự, Sen và cộng sự hoặc bản thân tôi và nhiều người khác).

Bạn có thể rất hứng thú với các tác phẩm của John Rushby , một trong những nhà thiết kế của người ủng hộ định lý PVS, người thường quan tâm đến chính xác những điểm bạn đề cập. Bạn có thể thích đọc báo cáo kinh điển này với FAA về việc sử dụng Phương pháp chính thức và Chứng nhận hệ thống quan trọng (1993) , và các bài viết mới hơn của anh ấy về việc lắp ráp một trường hợp an toàn chính thức, xác suất từ ​​nhiều phương tiện chứng cứ được cung cấp (thử nghiệm, bằng chứng, phân tích, vv).