Chương trình chính xác, đặc điểm kỹ thuật

Từ Wikipedia: Trong khoa học máy tính lý thuyết, tính chính xác của thuật toán được khẳng định khi người ta nói rằng thuật toán này đúng với một đặc điểm kỹ thuật.

Nhưng vấn đề là để có được đặc tả "phù hợp" không phải là một nhiệm vụ tầm thường và không có phương pháp đúng 100% (theo như tôi biết) để có được một phương pháp đúng, nó chỉ là một ước tính, vì vậy nếu chúng ta sẽ lấy một vị ngữ làm đặc tả chỉ vì nó "trông" giống như "một", tại sao không xem chương trình là chính xác chỉ vì nó "có vẻ" đúng?

Trước hết, bạn hoàn toàn đúng: bạn đang quan tâm thực sự. Xác minh chính thức chuyển vấn đề về độ tin cậy của tính chính xác của chương trình sang vấn đề về độ tin cậy về tính chính xác của thông số kỹ thuật, vì vậy đây không phải là viên đạn bạc.

Có một số lý do tại sao quá trình này vẫn có thể hữu ích, mặc dù.

1. Thông số kỹ thuật thường đơn giản hơn mã. Ví dụ, hãy xem xét vấn đề sắp xếp một mảng các số nguyên. Có các thuật toán sắp xếp khá tinh vi làm những điều thông minh để cải thiện hiệu suất. Nhưng đặc điểm kỹ thuật khá đơn giản để nêu: đầu ra phải theo thứ tự tăng dần và phải là một hoán vị của đầu vào. Do đó, có thể dễ dàng đạt được sự tin tưởng về tính chính xác của đặc tả hơn là tính chính xác của mã.

2. Không có điểm thất bại duy nhất. Giả sử bạn có một người viết ra một đặc tả và một người khác viết mã nguồn, sau đó chính thức xác minh rằng mã đáp ứng thông số kỹ thuật. Sau đó, bất kỳ lỗ hổng nào không bị phát hiện sẽ phải có mặt trong cả thông số kỹ thuật và mã. Trong một số trường hợp, đối với một số loại lỗ hổng, điều này cảm thấy ít khả năng hơn: ít có khả năng bạn bỏ qua lỗ hổng khi kiểm tra thông số kỹ thuật và bỏ qua lỗ hổng khi kiểm tra mã nguồn. Không phải tất cả, nhưng một số.

3. Thông số kỹ thuật một phần có thể đơn giản hơn nhiều so với mã. Ví dụ, hãy xem xét yêu cầu rằng chương trình không có lỗ hổng bộ đệm. Hoặc, yêu cầu không có lỗi ngoài chỉ mục mảng. Đây là một thông số đơn giản rõ ràng là một điều tốt và hữu ích để có thể chứng minh. Bây giờ bạn có thể thử sử dụng các phương thức chính thức để chứng minh rằng toàn bộ chương trình đáp ứng thông số này. Đó có thể là một nhiệm vụ khá liên quan, nhưng nếu bạn thành công, bạn sẽ tăng sự tự tin trong chương trình.

4. Thông số kỹ thuật có thể thay đổi ít thường xuyên hơn mã. Nếu không có các phương thức chính thức, mỗi lần chúng tôi cập nhật mã nguồn, chúng tôi phải kiểm tra thủ công rằng bản cập nhật sẽ không giới thiệu bất kỳ lỗi hay sai sót nào. Các phương thức chính thức có khả năng giảm gánh nặng này: giả sử thông số kỹ thuật không thay đổi, do đó các cập nhật phần mềm chỉ liên quan đến các thay đổi đối với mã và không thay đổi đối với thông số kỹ thuật. Sau đó, với mỗi bản cập nhật, bạn sẽ giảm bớt gánh nặng để kiểm tra xem thông số kỹ thuật có còn đúng không (nó đã thay đổi, do đó, không có lỗi mới nào được đưa ra trong thông số kỹ thuật) và về gánh nặng để kiểm tra xem mã có còn không đúng (trình xác minh chương trình kiểm tra điều đó cho bạn). Bạn vẫn cần kiểm tra xem thông số ban đầu có đúng không, nhưng sau đó bạn không cần phải kiểm tra nó mỗi khi nhà phát triển thực hiện một bản vá / cập nhật / thay đổi mới.

Cuối cùng, hãy nhớ rằng thông số kỹ thuật thường là khai báo và không nhất thiết phải được thực thi hoặc biên dịch trực tiếp thành mã. Ví dụ, hãy xem xét sắp xếp lại: thông số kỹ thuật nói rằng đầu ra đang tăng và là hoán vị của đầu vào, nhưng không có cách rõ ràng nào để "thực thi" thông số này trực tiếp và không có cách rõ ràng nào để trình biên dịch tự động biên dịch nó thành mã. Vì vậy, chỉ lấy thông số là chính xác và thực thi nó thường không phải là một lựa chọn.

Tuy nhiên, điểm mấu chốt vẫn như cũ: các phương pháp chính thức không phải là thuốc chữa bách bệnh. Họ chỉ đơn giản chuyển vấn đề (rất khó) về độ tin cậy về tính chính xác của mã sang vấn đề (chỉ đơn thuần là khó) về độ tin cậy của tính chính xác. Lỗi trong thông số kỹ thuật là một rủi ro thực sự, chúng là phổ biến và chúng không thể bị bỏ qua. Thật vậy, cộng đồng phương thức chính thức đôi khi tách vấn đề thành hai phần: xác minh là về việc đảm bảo mã đáp ứng thông số kỹ thuật; xác nhận là về việc đảm bảo thông số kỹ thuật là chính xác (đáp ứng nhu cầu của chúng tôi).

Bạn cũng có thể thích xác minh chương trình chính thức trong thực tế và Tại sao chúng ta không nghiên cứu nhiều hơn về việc đảm bảo thời gian biên dịch? cho nhiều quan điểm hơn với một số mang về điều này.

Câu trả lời của DW rất hay , nhưng tôi muốn mở rộng ở một điểm. Một đặc tả không chỉ là một tham chiếu mà mã được xác minh. Một trong những lý do để có một đặc điểm kỹ thuật chính thức là xác nhận nó bằng cách chứng minh một số thuộc tính cơ bản. Tất nhiên, đặc tả kỹ thuật không thể được xác nhận hoàn toàn - việc xác thực sẽ phức tạp như chính đặc điểm kỹ thuật, vì vậy nó sẽ là một quá trình vô tận. Nhưng xác nhận cho phép chúng tôi có được một bảo đảm mạnh mẽ hơn trên một số thuộc tính quan trọng.

Ví dụ: giả sử bạn đang thiết kế xe tự lái. Đây là một điều khá phức tạp liên quan đến rất nhiều thông số. Các đặc tính chính xác của hệ thống lái tự động bao gồm những thứ như Xe hơi sẽ không đâm vào tường và Xe sẽ lái ở nơi mà nó được yêu cầu đi tới. Một tài sản như thế thì chiếc xe sẽ không đâm vào tường mà thực sự rất quan trọng, vì vậy chúng tôi muốn chứng minh điều đó. Vì hệ thống hoạt động trong thế giới vật lý, bạn sẽ cần thêm một số ràng buộc vật lý; tài sản thực tế của hệ thống tính toán sẽ giống như những điều giả định về khoa học vật liệu và những giả định này liên quan đến nhận thức về chướng ngại vật của cảm biến ô tô, chiếc xe sẽ không đâm vào tường. Nhưng ngay cả như vậy, kết quả là một tài sản tương đối đơn giản rõ ràng là mong muốn.

Bạn có thể chứng minh tài sản này từ mã? Cuối cùng, đó là những gì đang diễn ra, nếu bạn đang theo một cách tiếp cận hoàn toàn chính thức¹. Nhưng mã có rất nhiều phần khác nhau; hệ thống phanh, máy ảnh, động cơ, v.v ... đều được điều khiển tự động. Một đặc tính chính xác của hệ thống phanh sẽ là một cái gì đó giống như nếu có tín hiệu 'áp dụng phanh' thì hệ thống phanh được áp dụng. Một đặc tính chính xác của động cơ sẽ là thành công nếu tín hiệu ly hợp tắt thì động cơ không truyền động cho các bánh xe. Phải có một cái nhìn rất cao cấp để đặt tất cả chúng lại với nhau. Một đặc tả tạo ra một lớp trung gian trong đó các thành phần khác nhau của hệ thống có thể được khớp nối với nhau.

Trên thực tế, một hệ thống phức tạp như xe tự lái sẽ có một số cấp độ thông số kỹ thuật với số lượng tinh chỉnh khác nhau. Một cách tiếp cận tinh tế thường được sử dụng trong thiết kế: bắt đầu với một số thuộc tính cao cấp như chiếc xe sẽ không đâm vào tường, sau đó tìm ra rằng điều này đòi hỏi phải có cảm biến và phanh và đưa ra một số yêu cầu cơ bản cho cảm biến, phanh và phần mềm thử nghiệm, sau đó tinh chỉnh lại các yêu cầu cơ bản đó thành thiết kế thành phần (đối với cảm biến, tôi sẽ cần một radar, DSP, thư viện xử lý hình ảnh, trộm), v.v. Trong quy trình phát triển chính thức, mỗi cấp độ đặc tả được chứng minh là đáp ứng các yêu cầu được đặt ra bởi cấp độ trên nó, tất cả các cách từ các thuộc tính cấp cao nhất cho đến mã.

Không thể chắc chắn rằng đặc điểm kỹ thuật là chính xác. Ví dụ, nếu bạn sai vật lý, hệ thống phanh có thể không hiệu quả mặc dù toán học liên quan đến mã phanh với các yêu cầu chính thức là chính xác. Thật không tốt khi chứng minh rằng việc nghỉ có hiệu quả với 500kg tải nếu bạn thực sự có 5000kg. Nhưng thật dễ dàng để thấy rằng 500kg là sai so với việc nhìn vào bên trong mã phanh rằng chúng sẽ không đủ tốt cho các thông số vật lý của xe.

¹ _{Điều ngược lại một cách tiếp cận hoàn toàn chính thức là “Tôi đoán công trình này, nhưng tôi không thể chắc chắn”. Khi bạn đặt cược cuộc sống của mình vào nó, điều đó dường như không tuyệt vời lắm.}