Những rào cản ngăn cản việc áp dụng rộng rãi các phương pháp chính thức là gì? [đóng cửa]

Các phương thức chính thức có thể được sử dụng để chỉ định, chứng minh và tạo mã cho một ứng dụng. Điều này ít xảy ra lỗi - do đó chủ yếu được sử dụng trong các chương trình an toàn / quan trọng.

Tại sao chúng ta không sử dụng nó thường xuyên hơn cho lập trình hàng ngày hoặc trong các ứng dụng web, v.v ...?

Người giới thiệu :

• Phương pháp chính thức
• Phương pháp B
• Logic Hoare

Một kỹ sư là một người có thể làm với một đô la, điều mà bất kỳ kẻ ngốc nào cũng có thể làm với 10.

Hạn chế về nguồn lực, hạn chế về ngân sách, hạn chế về thời gian, chúng đều quan trọng.

Phát triển phần mềm bằng các phương pháp chính thức thường tốn kém hơn đáng kể và mất nhiều thời gian hơn không có. Ngoài ra, đối với nhiều dự án, phần khó nhất là hiểu được các yêu cầu kinh doanh. Tất cả những gì sử dụng các phương thức chính thức mua cho bạn trong trường hợp đó là bằng chứng cho thấy mã của bạn tương ứng 100% với sự hiểu biết không đầy đủ và không chính xác của bạn về các yêu cầu kinh doanh.

Vì lý do đó, việc sử dụng các phương pháp chính thức, bằng chứng, xác minh chương trình và các kỹ thuật tương tự thường bị giới hạn ở "những thứ quan trọng", tức là phần mềm điện tử hàng không, hệ thống điều khiển cho thiết bị y tế, nhà máy điện, v.v.

Lập trình hay không lập trình?

Để giải quyết vấn đề với sản phẩm phần mềm, sau khi hiểu rõ các yêu cầu, bạn có thể EITHER viết chương trình bằng ngôn ngữ lập trình HOẶC chỉ định chương trình bằng ngôn ngữ chính thức và sử dụng các công cụ tạo mã. Cái sau chỉ thêm một mức độ trừu tượng.

Làm những điều đúng hay làm những điều đúng?

Cách tiếp cận chính thức cung cấp cho bạn một bằng chứng rằng phần mềm của bạn hoạt động theo các thông số kỹ thuật. Vì vậy, sản phẩm của bạn làm những điều đúng. Nhưng nó có làm đúng không?

Các yêu cầu mà bạn đang làm việc có thể không đầy đủ hoặc mơ hồ. Họ thậm chí có thể có lỗi. Trong trường hợp xấu nhất, nhu cầu thực sự thậm chí không được thể hiện. Nhưng một bức tranh đáng giá cả ngàn từ, chỉ cần google hình ảnh cho "Những gì khách hàng muốn", ví dụ từ bài viết này :

Chi phí chính thức

Trong một thế giới hoàn hảo, bạn sẽ có những yêu cầu đầy đủ chi tiết và hoàn hảo ngay từ đầu. Sau đó bạn có thể chỉ định đầy đủ phần mềm của bạn. Nếu bạn đi chính thức, mã của bạn sẽ được tạo tự động để bạn có năng suất cao hơn. Tăng năng suất sẽ bù đắp chi phí của các công cụ chính thức. Và mọi người bây giờ sẽ sử dụng các phương pháp chính thức. Vậy tại sao không?

Trong thực tế, điều này hiếm khi là thực tế! Đây là lý do tại sao rất nhiều dự án thác nước thất bại, và tại sao các phương pháp phát triển lặp lại (nhanh nhẹn, RAD, v.v.) dẫn đầu: chúng có thể xử lý các yêu cầu không hoàn chỉnh và không hoàn hảo, thiết kế và triển khai và tinh chỉnh chúng cho đến khi chúng ổn.

Và đây là điểm. Với các phương thức chính thức, mỗi lần lặp lại đòi hỏi phải có một thông số chính thức hoàn toàn phù hợp. Điều này đòi hỏi suy nghĩ cẩn thận và công việc bổ sung, bởi vì logic chính thức không tha thứ và không giống như những suy nghĩ không hoàn chỉnh. Các thí nghiệm vứt bỏ đơn giản trở nên đắt đỏ dưới sự ràng buộc này. Và mỗi lần lặp lại sẽ dẫn đến quay lui (ví dụ: một ý tưởng không hoạt động hoặc yêu cầu bị hiểu sai).

Trong thực tế

Khi không bắt buộc phải sử dụng các phương pháp chính thức vì lý do hợp pháp hoặc hợp đồng, bạn cũng có thể đạt được chất lượng rất cao mà không cần hệ thống chính thức, ví dụ như bằng cách sử dụng lập trình dựa trên hợp đồng và các thực tiễn tốt khác (ví dụ: xem lại mã, TDD , v.v.). Bạn sẽ không thể chứng minh rằng phần mềm của bạn hoạt động, nhưng người dùng của bạn sẽ thích phần mềm hoạt động sớm hơn.

Cập nhật: nỗ lực đo lường

Trong số tháng 10 năm 2018 về Truyền thông của ACM có một bài viết thú vị về phần mềm được xác minh chính thức trong thế giới thực với một số ước tính về nỗ lực này.

Điều thú vị (dựa trên sự phát triển hệ điều hành cho thiết bị quân sự), dường như việc sản xuất phần mềm chính thức được chứng minh đòi hỏi nỗ lực gấp 3,3 lần so với các kỹ thuật kỹ thuật truyền thống. Vì vậy, nó thực sự tốn kém.

Mặt khác, đòi hỏi nỗ lực ít hơn 2,3 lần để có được phần mềm bảo mật cao theo cách này so với phần mềm được thiết kế theo truyền thống nếu bạn thêm nỗ lực để làm cho phần mềm đó được chứng nhận ở mức bảo mật cao (EAL 7). Vì vậy, nếu bạn có độ tin cậy cao hoặc yêu cầu bảo mật, chắc chắn có một trường hợp kinh doanh để đi chính thức.

Thiết kế seL4 và phát triển mã mất hai năm. Thêm tất cả các bằng chứng về ngôn ngữ học trong những năm qua có tổng cộng 18 năm người cho 8.700 dòng mã C. Để so sánh, L4Ka :: Pistachio, một hạt nhân khác trong họ L4, có kích thước tương đương seL4, mất sáu năm để phát triển và không cung cấp mức độ đảm bảo đáng kể. Điều này có nghĩa là chỉ có một yếu tố 3,3 giữa phần mềm được xác minh và phần mềm được thiết kế theo truyền thống. Theo phương pháp ước tính của Colbert và Boehm, 8 chứng nhận EAL7 tiêu chí chung truyền thống cho 8.700 dòng mã C sẽ mất hơn 45,9 năm người. Điều đó có nghĩa là xác minh thực hiện cấp nhị phân chính thức đã nhiều hơn hệ số 2,3 ít tốn kém hơn mức chứng nhận cao nhất của Tiêu chí chung nhưng vẫn đảm bảo chắc chắn hơn.

Mỗi chương trình trong bất kỳ ngôn ngữ nào cũng có thể được coi là một đặc điểm kỹ thuật chính thức (tương đương với một số máy tiện). Bất kỳ mức độ cao hơn, "đặc tả chính thức" sẽ được sử dụng để chứng minh tính chính xác cũng là - chỉ là một chương trình khác. Nhưng nó (thường) là một suy nghĩ tồi tệ, không đầy đủ, mơ hồ, không đủ thông qua chương trình. Và không phải ngẫu nhiên, thường được viết bởi những người không biết cách lập trình (họ thường là chuyên gia về miền).

Và do đó, việc chứng minh rằng một chương trình tương thích (tạo ra cùng một câu trả lời hoặc theo cách bạn mô tả nó) với các yêu cầu chính thức ở cấp độ cao hơn, bất biến là cách bạn giải quyết sự mơ hồ trong đặc tả chính thức cấp cao hơn. Không có cách mục đích chung tốt để làm điều đó.

Việc ánh xạ các yêu cầu cấp cao đến các chi tiết cấp thấp hơn là ý chính của lập trình thực sự. Không có gì đáng ngạc nhiên khi công việc cốt lõi được thực hiện bởi các lập trình viên đọc và thông số kỹ thuật có thể được thay thế bằng cách vẫy tay và nói 'bây giờ hãy xem liệu đặc tả chính thức cấp cao này có tuân thủ theo chương trình mẫu này không'.

Ngay cả trong những ngày đầu lập trình logic, nơi khái niệm này lần đầu tiên có vẻ rất hứa hẹn (bởi vì cả đặc tả kỹ thuật cấp cao và các chương trình cơ bản thực tế có thể được viết bằng cùng một ngôn ngữ), vấn đề cốt lõi này đã tỏ ra khó hiểu.