Làm thế nào để tạo phần mềm quan trọng sứ mệnh?

Tôi đang tự học phương pháp chính thức. Tôi nghe nói rằng các phương pháp chính thức được sử dụng (và thường chỉ được sử dụng) để tạo ra phần mềm quan trọng (như bộ điều khiển lò phản ứng hạt nhân, bộ điều khiển bay máy bay, bộ điều khiển thăm dò không gian). Đó là lý do tại sao tôi thích tìm hiểu nó: p

Tuy nhiên, sau khi học các phương pháp chính thức (đặc biệt là LTL, CTL và anh chị em của họ), tôi cảm thấy rằng chúng chỉ có thể được sử dụng để xác minh tính chính xác của thông số kỹ thuật (an toàn, sinh động, công bằng, v.v.).

Nhưng sau đó, làm thế nào để xác minh rằng phần mềm (không chỉ đặc điểm kỹ thuật) thực sự chính xác?

Disclaimer: Tôi là một thằng ngốc 90% khi nói đến khoa học máy tính lý thuyết. Vì vậy, xin hãy thương xót trong khi trả lời.

Câu hỏi khá rộng. Để trả lời nó trong một không gian hợp lý tôi sẽ thực hiện nhiều đơn giản hóa.

Hãy để chúng tôi đồng ý về thuật ngữ. Một chương trình là chính xác khi nó ngụ ý đặc điểm kỹ thuật của nó. Tuyên bố mơ hồ này được thực hiện chính xác theo nhiều cách, bằng cách xác định chính xác chương trình là gì và chính xác là gì. Ví dụ, trong mô hình kiểm tra chương trình là cấu trúc Kripke và đặc tả thường là công thức LTL . Hoặc, chương trình có thể là một danh sách các hướng dẫn PowerPC và thông số kỹ thuật có thể là một tập hợp các xác nhận Hoare-Floyd được viết bằng, giả sử, logic thứ nhất. Có rất nhiều biến thể có thể. Thật hấp dẫn khi kết luận rằng trong một trường hợp (cấu trúc Kripke), chúng tôi không xác minh một chương trình thực tế, trong trường hợp thứ hai (danh sách các hướng dẫn PowerPC) chúng tôi làm. Tuy nhiên, điều quan trọng là nhận ra chúng ta thực sự đang xem xét các mô hình toán học trong cả hai trường hợp, và điều này là hoàn toàn tốt. (Tình huống khá giống với vật lý, ví dụ, cơ học cổ điển là một mô hình toán học của thực tế.)

Hầu hết các chính thức phân biệt giữa cú pháp và ngữ nghĩa của một chương trình; đó là, nó được thể hiện như thế nào và nó có nghĩa gì. Các ngữ nghĩa của một chương trình là những gì được tính từ quan điểm xác minh chương trình. Nhưng, tất nhiên điều quan trọng là phải có một cách rõ ràng để gán ý nghĩa cho (các biểu diễn cú pháp của) các chương trình. Hai cách phổ biến như sau:

• (bước nhỏ) ngữ nghĩa hoạt động : Điều này rất giống với việc xác định ngôn ngữ lập trình bằng cách viết một trình thông dịch cho nó. Đối với điều này, bạn cần nói trạng thái là gì và nó bị ảnh hưởng bởi mỗi câu trong ngôn ngữ. (Bạn có thể tự hỏi ngôn ngữ nào bạn viết trình thông dịch, nhưng tôi sẽ giả vờ như bạn không biết.)
• ngữ nghĩa tiên đề : Ở đây mỗi loại câu lệnh đi kèm với một lược đồ tiên đề. Vì vậy, đại khái, bất cứ khi nào một tuyên bố cụ thể của loại đó được sử dụng, nó có nghĩa là có thể sử dụng các tiên đề nhất định. Ví dụ: phép gán đi kèm với lược đồ { P [ x / e ] ${\bf x}:={\bf e}$ ; phép gán cụ thể x : = x + 1 đi kèm với tiên đề { x + 1 = 1 $\{P[{\bf x}/{\bf e}]\}\,{\bf x}:={\bf e}\,\{P\}$$x:=x+1$ nếu chúng ta khởi tạo lược đồ với P = ( x = 1 ) .$\{x+1=1\}\,x:=x+1\,\{x=1\}$$P=(x=1)$

(Có những thứ khác. Tôi cảm thấy đặc biệt tệ khi bỏ qua ngữ nghĩa học biểu thị, nhưng câu trả lời này đã dài.) Mã máy cộng với ngữ nghĩa hoạt động khá gần với cái mà hầu hết mọi người gọi là 'chương trình thực'. Dưới đây là một bài báo chuyên đề, sử dụng ngữ nghĩa hoạt động cho một tập hợp con của mã máy DEC Alpha:

• Necula, Lee, Mã mang bằng chứng , 1996

Tại sao bạn sẽ sử dụng một số ngữ nghĩa cấp cao hơn, như các tiên đề? Khi bạn không muốn bằng chứng chính xác của mình phụ thuộc vào phần cứng mà bạn chạy. Cách tiếp cận sau đó là chứng minh tính đúng đắn của thuật toán đối với một số ngữ nghĩa cấp cao thuận tiện, và sau đó chứng minh rằng ngữ nghĩa đối với ngữ nghĩa cấp thấp gần với máy móc thực tế hơn.

Tóm lại, tôi có thể nghĩ ra ba lý do dẫn đến câu hỏi của bạn:

1. Bạn chỉ thấy các ngữ nghĩa cấp cao trông không giống với những gì bạn được sử dụng để gọi một chương trình, và bạn tự hỏi liệu có những ngữ nghĩa cấp thấp không. Câu trả lời là có.
2. Bạn tự hỏi làm thế nào bạn chứng minh rằng một mô hình tương ứng với thực tế. Giống như trong vật lý, bạn không. Bạn chỉ cần đưa ra các mô hình tốt hơn và kiểm tra chúng chống lại thực tế.
3. Bạn chưa thấy sự khác biệt giữa cú pháp và ngữ nghĩa và nhiều cách khác nhau để gán nghĩa cho các chương trình. Hai câu hỏi trước liệt kê một số cuốn sách.

Câu trả lời này chỉ đơn thuần là cố gắng xác định ba cách khác nhau để tôi hiểu câu hỏi. Đi sâu vào bất kỳ điểm nào trong số này sẽ cần rất nhiều không gian.

Một cách tiếp cận để giảm khoảng cách giữa một chương trình và đặc điểm kỹ thuật của nó là sử dụng một ngôn ngữ với ngữ nghĩa chính thức. Một ví dụ thú vị ở đây sẽ là Esterel . Hãy xem trang web của Gérard Berry để biết một số cuộc nói chuyện thú vị về công việc của anh ấy mang phương pháp chính thức vào thế giới thực. http://www-sop.inria.fr/members/Gerard.Berry/

ps Bạn đã ở trên một chiếc Airbus? Bạn đã bay với các phương pháp chính thức!

Khoa học xây dựng phần mềm đáng tin cậy trong "thế giới thực" vẫn đang được phát triển và ở một mức độ nào đó được nghiên cứu về văn hóa hoặc nhân học, bởi vì máy tính và phần mềm không "gây ra" lỗi cho con người! câu trả lời này sẽ tập trung vào các cách tiếp cận Q / A chung trong đó xác minh phần mềm chính thức có thể được xem là một yếu tố.

một quan sát đáng chú ý là thường phần mềm "đủ tốt" nhưng "lỗi" thường có thể bán chạy hơn phần mềm được kiểm tra tốt hơn nhưng chức năng thấp hơn trên thị trường. nói cách khác, thị trường không phải lúc nào cũng đặt ưu tiên cho chất lượng phần mềm và các kỹ thuật hiện đại của công nghệ phần mềm, không phải lúc nào cũng nhấn mạnh chất lượng, phần nào phản ánh điều đó. hơn nữa chất lượng thường có thể thêm một chi phí đáng kể cho sản phẩm cuối cùng. với những cảnh báo này, đây là một số điều cơ bản:

• hệ thống dự phòng / lỗi. đây là một lĩnh vực nghiên cứu rộng. khả năng chịu lỗi & dự phòng có thể được thiết kế thành nhiều lớp trong hệ thống. ví dụ: bộ định tuyến, máy chủ, ổ đĩa, vân vân.

• thử nghiệm . tất cả các loại thử nghiệm đơn vị, thử nghiệm tích hợp, thử nghiệm chấp nhận người dùng, thử nghiệm hồi quy, v.v.

• ngày nay, kiểm tra tự động thông qua các bộ kiểm tra có thể chạy mà không cần giám sát là phát triển / quan trọng hơn. bộ kiểm tra đang chạy thường được kết hợp với công cụ xây dựng.

• một khái niệm quan trọng trong thử nghiệm là bảo hiểm mã . tức là những gì mã được thực hiện bởi các bài kiểm tra. một bài kiểm tra không thể tìm thấy một lỗi trong mã không bị "chạm" bởi bài kiểm tra.

• một khái niệm quan trọng khác trong thử nghiệm là kiểm tra khai thác rằng mã bài tập không dễ dàng truy cập trực tiếp.

• kiểm tra nên thực hiện tất cả các cấp của phần mềm. Nếu phần mềm được mô đun hóa tốt, điều này không khó. kiểm tra mức cao hơn nên thâm nhập sâu vào mã. các thử nghiệm thực hiện số lượng lớn mã với thiết lập thử nghiệm nhỏ làm tăng "đòn bẩy thử nghiệm" .

• làm cho mã ít phức tạp nhất có thể là điều quan trọng để thử nghiệm. thử nghiệm nên được xem xét trong thiết kế kiến ​​trúc. thường có nhiều cách để thực hiện cùng một tính năng nhưng một số có ý nghĩa khác nhau đối với phạm vi kiểm tra / đòn bẩy. Đối với mỗi nhánh trong mã, nó thường là một trường hợp thử nghiệm khác. các nhánh trong các nhánh leo thang để tăng theo cấp số nhân trong các đường dẫn mã. do đó tránh logic lồng nhau / có điều kiện cải thiện khả năng kiểm tra.

• nghiên cứu các lỗi phần mềm nổi tiếng (lớn) trong đó có nhiều ví dụ & nghiên cứu trường hợp rất hữu ích để hiểu lịch sử và phát triển một tư duy hướng tới các cân nhắc về chất lượng.

• người ta có thể được mang đi với thử nghiệm! có cả một vấn đề với quá ít hoặc quá nhiều thử nghiệm. có một "điểm ngọt". phần mềm không thể được xây dựng thành công ở một trong hai thái cực.

• sử dụng tất cả các công cụ cơ bản một cách hiệu quả nhất. trình gỡ lỗi, trình biên dịch mã, công cụ bao phủ mã kiểm tra, hệ thống theo dõi lỗi, v.v! không nhất thiết phải cam kết sửa chữa, nhưng theo dõi ngay cả những lỗi nhỏ nhất trong phần mềm theo dõi.

• sử dụng cẩn thận SCM, quản lý mã nguồn và kỹ thuật phân nhánh là rất quan trọng trong việc tránh hồi quy, cách ly và tiến hành sửa lỗi, v.v.

• Lập trình phiên bản N : một cách thực hành thường được sử dụng để phát triển Phần mềm quan trọng của Mission. Tiền đề của thực tiễn này là N chương trình được phát triển độc lập dường như không có cùng lỗi / lỗi chung. Điều này đã bị chỉ trích trong một vài bài báo . NVP , tuy nhiên, một thực tế không phải là một khái niệm lý thuyết.

Tôi tin rằng nhà vật lý Feynman có một số tài khoản về phương pháp mà NASA đã sử dụng để đảm bảo độ tin cậy của các hệ thống tàu con thoi trong cuốn sách "Bạn quan tâm người khác nghĩ gì?" - anh ấy nói họ có hai đội, nói đội A và đội B. đội A đã xây dựng phần mềm. đội B đã thực hiện một cách tiếp cận đối nghịch với đội A và cố gắng phá vỡ phần mềm.

nó giúp nếu Đội B có nền tảng kỹ thuật phần mềm tốt, tức là bản thân họ có thể viết mã khai thác / kiểm tra chương trình, v.v. trong trường hợp đó, Đội B có mức tài nguyên gần như ngang bằng với Đội A. mặt khác, cách tiếp cận này rất tốn kém vì nó có thể tăng gần gấp đôi chi phí xây dựng phần mềm. thông thường hơn, có một nhóm QA nhỏ hơn so với nhóm phát triển.

Một cách tiếp cận cũ (nhưng nó vẫn được sử dụng trong một số ứng dụng) là lập trình phiên bản N

Từ Wikipedia:

Lập trình phiên bản N ( NVP ), còn được gọi là lập trình đa biến , là một phương pháp hoặc quy trình trong công nghệ phần mềm trong đó nhiều chương trình tương đương về chức năng được tạo độc lập từ cùng một thông số kỹ thuật ban đầu. Khái niệm lập trình phiên bản N được Liming Chen và Algirdas Avizienis giới thiệu vào năm 1977 với phỏng đoán trung tâm rằng "tính độc lập của các nỗ lực lập trình sẽ giảm đáng kể xác suất xảy ra lỗi phần mềm giống hệt nhau trong hai hoặc nhiều phiên bản của chương trình". của NVP là cải thiện độ tin cậy của hoạt động phần mềm bằng cách xây dựng khả năng chịu lỗi hoặc dự phòng.
....

Xem ví dụ: " Những thách thức trong việc xây dựng lỗi - Hệ thống điều khiển bay cho máy bay dân dụng "

fajrian, câu hỏi này bạn đã thực hiện bao gồm hai vấn đề lớn nhất trong nghiên cứu của kỹ sư phần mềm: sự phù hợp giữa đặc tả và mô hình và giữa mô hình và mã. Mô hình ở đây một đại diện cho những gì hệ thống sẽ làm, hoặc nó sẽ được thực hiện như thế nào, có rất nhiều cấp độ để mô hình hóa một hệ thống.

Vì vậy, có một số người đang cố gắng tìm câu trả lời tốt nhất cho câu hỏi của bạn. Bởi vì rất khó kiểm tra tính chính xác của một phần mềm dựa trên một mô hình, ví dụ, bằng các phương pháp chính thức. Tôi biết JML là một cách để làm điều đó, nhưng tôi không biết giới hạn sử dụng của nó.

Để kết thúc, việc kiểm tra tính chính xác của mã khó thực hiện như thế nào, mọi người cố gắng trộn các phương thức chính thức và kiểm tra, tạo thử nghiệm tự động từ các thông số kỹ thuật chẳng hạn. Một ví dụ cho các hệ thống thời gian thực là TIOSTS dựa trên các sự kiện hẹn giờ đầu vào / đầu ra.

Chỉ kiểm tra không phải là một phương pháp chính thức, làm nó cải thiện độ tin cậy nhưng không kiểm tra tính chính xác.

Hai hoặc ba năm trước tôi đã bắt đầu xem xét các phương pháp chính thức được áp dụng cho phần mềm. Đây là một nhiệm vụ được thúc đẩy bởi sự tò mò và bởi cảm giác rằng tôi phải học các công cụ và phương pháp lập trình với thời gian dài hơn. Mặc dù tôi mơ ước một viên đạn bạc , tôi thực sự nghĩ rằng không có câu trả lời cho câu hỏi: "Làm thế nào tôi có thể viết một chương trình chính xác?".

Tại thời điểm này của nhiệm vụ sau khi thử một số công cụ (Z, B, VHDL và Estelle), tôi đang sử dụng TLA + . Đây là một biến thể của logic thời gian với các công cụ phần mềm để kiểm tra mô hình và bằng chứng cơ học. Tôi nghĩ rằng tôi chọn cách tiếp cận này bởi vì L. Lamport đứng đằng sau nó, cú pháp đơn giản, có rất nhiều ví dụ, có một cộng đồng quan tâm đến nó, và ngôn ngữ và công cụ được ghi chép khá tốt.

Về câu hỏi ban đầu của tôi, tôi nghĩ rằng không có câu trả lời hoàn chỉnh. Tuy nhiên, điều đáng học là nó được đền đáp để chỉ định chính thức một số phần của hệ thống. Nó cũng khá hữu ích để đảo ngược một số kỹ thuật phức tạp. Đó là, nó có hiệu quả để tạo ra một kế hoạch chi tiết cho các phần khó khăn và quan trọng. Tuy nhiên, tôi không nghĩ có một phương pháp hiệu quả để tự động dịch đặc tả sang ngôn ngữ lập trình hoặc khung (trừ khi bạn giới hạn dự án trong một môi trường rất cụ thể). Tôi cũng không nghĩ rằng việc có một đặc tả chính thức sẽ ngăn bạn kiểm tra phần mềm.

Tóm lại, tôi nghĩ rằng phép ẩn dụ sau (từ Lamport) thực sự mạnh mẽ: "Bạn có mong đợi một ngôi nhà sẽ được tự động xây dựng từ một bản thiết kế không? Bạn sẽ mua một ngôi nhà chưa được xây dựng và nó không có bản thiết kế?" .

Trong nhiệm vụ này, tôi đã tìm thấy các tài nguyên sau hữu ích:

• Phương pháp đặc tả phần mềm . Cuốn sách này cung cấp một cái nhìn bao quát về các phương pháp và công cụ hiện có. Ở đó bạn có thể tìm thấy các giải thích và ví dụ cơ bản về Z, SDL, TLA +, Petri Nets, Coq, v.v.
• Nếu bạn nghĩ rằng TLA + phù hợp với nhu cầu của bạn, tôi thực sự khuyên bạn nên sử dụng cuốn sách Chỉ định hệ thống . Bạn có thể nhận được cuốn sách miễn phí, và nó đi kèm với các ví dụ để chơi với :).
• Gần đây, tôi đọc một vài bài viết liên quan đưa ra hai quan điểm khác nhau về tình trạng của nghệ thuật của các phương pháp chính thức: Trường hợp cho các phương pháp chính thức và Toán học được xác minh chính thức .

Chúc may mắn!

Các câu trả lời cho đến nay đã bao gồm hầu hết những gì cần nói về nền tảng của việc liên quan đến đặc tả và mã với nhau như thế nào. Tôi chỉ muốn thêm một điểm thực tế hơn tiếp cận câu hỏi trong tiêu đề của chủ đề này:

Làm thế nào để tạo ra phần mềm quan trọng nhiệm vụ?

Có các công cụ tự động phân tích mã của bạn để tìm lỗi (vi phạm đặc tả hoặc "lỗi điển hình"). Theo hiểu biết của tôi, các phương pháp này chủ yếu dựa trên phân tích tĩnh và không liên quan ngay đến các lý thuyết bạn đã đề cập (LTL / CTL / ...), nhưng chúng tìm thấy lỗi trong mã thực và nó đã khả thi, từ quan điểm thực tế của xem, để sử dụng các công cụ như vậy trong các dự án công nghiệp. Cá nhân tôi đã không sử dụng nhiều trong số họ, nhưng dường như những công cụ này bắt đầu được các học viên chấp nhận. Để đọc thêm, tôi có thể giới thiệu bài viết blog sau:

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

Các thuật toán xác nhận có thể hữu ích khi xây dựng phần mềm quan trọng.

Thuật toán chứng nhận là một thuật toán tạo ra, với mỗi đầu ra, một chứng chỉ hoặc nhân chứng (bằng chứng dễ xác minh) rằng đầu ra cụ thể không bị xâm phạm bởi một lỗi.

Đọc thêm trong bài khảo sát này Xác nhận các thuật toán của McConnell, RM và Mehlhorn, K. và Naher, S. và Schweitzer, P.

Nhưng sau đó, làm thế nào để xác minh rằng phần mềm (không chỉ đặc điểm kỹ thuật) thực sự chính xác?

Kiểm tra đơn vị? Viết một bài kiểm tra cho mọi yêu cầu duy nhất trong thông số kỹ thuật, và sau đó kiểm tra mọi phương thức đơn lẻ trong triển khai của bạn để thấy rằng đầu ra / đầu vào của nó phù hợp với thông số kỹ thuật đã nói. Điều này có thể được tự động để các thử nghiệm này được chạy liên tục để đảm bảo không có thay đổi nào phá vỡ các tính năng hoạt động trước đó.

Về mặt lý thuyết, nếu các bài kiểm tra đơn vị của bạn có độ bao phủ 100% mã (tức là mọi phương pháp duy nhất trong mã của bạn được kiểm tra) thì phần mềm của bạn phải chính xác, miễn là bản thân các bài kiểm tra là chính xác và thực tế.