미션 크리티컬 소프트웨어를 만드는 방법?

나는 자율 학습 공식적인 방법입니다. 공식적인 방법을 사용하여 미션 크리티컬 소프트웨어 (예 : 원자로 컨트롤러, 항공기 비행 컨트롤러, 우주 탐침 컨트롤러)를 만드는 데 사용됩니다. 그래서 나는 그것을 배우고 싶습니다 : p

그러나 공식적인 방법 (특히 LTL, CTL 및 형제)을 배우면 사양의 정확성 (안전성, 활력, 공정성 등)을 확인하는 데만 사용할 수 있다고 생각합니다.

그렇다면 소프트웨어 (사양뿐만 아니라)가 실제로 올바른지 확인하는 방법은 무엇입니까?

면책 조항 : 나는 이론적 인 컴퓨터 과학에 관해서는 90 % 바보입니다. 따라서 대답하는 동안 자비 롭게 행동하십시오.

질문은 다소 광범위합니다. 합리적인 공간에서 대답하기 위해 많은 단순화를하겠습니다.

용어에 동의합시다. 프로그램이 사양을 암시 할 때 올바른 프로그램입니다 . 이 모호한 진술은 프로그램이 무엇인지, 스펙이 정확히 무엇인지를 찾아 여러 가지 방법으로 정확하게 만들어집니다. 예를 들어, 모델 검사에서 프로그램은 Kripke 구조 이고 사양은 종종 LTL 공식입니다. 또는 프로그램은 PowerPC 명령어 목록 일 수 있으며 사양은 1 차 논리로 작성된 Hoare-Floyd 어설 션 세트 일 수 있습니다.. 가능한 많은 변형이 있습니다. 어떤 경우에는 (Kripke 구조) 실제 프로그램을 검증하지 않지만 두 번째 경우 (PowerPC 명령어 목록)는 결론을 내립니다. 그러나 두 경우 모두 수학적 모델을 실제로보고 있다는 것을 인식하는 것이 중요합니다. (예를 들어, 고전 역학이 현실의 수학적 모델 인 물리와 매우 유사합니다.)

대부분의 형식화는 프로그램의 구문과 의미를 구별합니다. 즉, 그것이 어떻게 표현되고 무엇을 의미합니까? 프로그램의 의미는 프로그램 검증의 관점에서 계산됩니다. 그러나 프로그램에 (구문 표현 적) 의미를 부여하는 명확한 방법을 갖는 것이 중요합니다. 널리 사용되는 두 가지 방법은 다음과 같습니다.

• (작은 단계) 연산 의미론 : 이것은 해석기를 작성하여 프로그래밍 언어를 정의하는 것과 매우 유사합니다. 이를 위해 당신은 상태 가 무엇인지 말해야 하며 언어의 각 진술에 의해 영향을받습니다. (당신은 어떤 언어로 통역사를 쓸지 궁금해 할 수 있지만, 그렇지 않은 척합니다.)
• axiomatic semantics : 여기에서 각 문장 유형은 공리 스키마와 함께 제공됩니다. 따라서 대략 해당 유형의 특정 문장이 사용될 때마다 특정 공리를 사용할 수있게됩니다. 예를 들어, 할당 는 스키마 { P [ x / e ] } 와 함께 제공됩니다.${\bf x}:={\bf e}$ ; 특정 할당 x : = x + 1 은 공리와 함께 제공됩니다.$\{P[{\bf x}/{\bf e}]\}\,{\bf x}:={\bf e}\,\{P\}$$x:=x+1$P = ( x로 스키마를 인스턴스화하면 { x = 1 $\{x+1=1\}\,x:=x+1\,\{x=1\}$입니다.$P=(x=1)$

(다른 것들도있다. 특히 의미 적 의미론을 생략하는 것이 좋지 않다고 생각하지만,이 답변은 이미 길다.) 기계어 코드와 운영 의미론은 대부분의 사람들이 '실제 프로그램'이라고 부르는 것과 매우 가깝다. 다음은 DEC Alpha 기계 코드의 서브 세트에 작동 시맨틱을 사용하는 중요한 논문입니다.

• 네 큘라,이, 증명 운반 코드 , 1996

왜 당신은 공리 학적 인 것들과 같은 더 높은 수준의 의미론을 사용하겠습니까? 정확성 증명이 실행되는 하드웨어에 의존하지 않게하려는 경우. 그런 다음 접근 방식은 편리한 고급 의미 체계에 대한 알고리즘의 정확성을 입증 한 다음 실제 기계에 더 가까운 하위 수준 의미 체계에 대한 의미 체계가 의미가 있음을 증명합니다.

요약하면, 나는 당신의 질문으로 이어진 세 가지 이유에 대해 생각할 수 있습니다.

1. 프로그램을 호출하는 데 사용되지 않는 상위 수준 의미 만 보았으며 하위 수준이 있는지 궁금합니다. 대답은 '예'입니다.
2. 모델이 현실과 일치한다는 것을 어떻게 증명하는지 궁금합니다. 물리학 에서처럼 그렇지 않습니다. 당신은 단순히 더 나은 모델을 생각해 내고 현실과 대조합니다.
3. 구문과 시맨틱의 차이점과 프로그램에 의미를 할당하는 다양한 방법을 보지 못했습니다. 두 가지 이전 질문 일부 책이 나와 있습니다.

이 답변은 내가 질문을 이해하는 세 가지 다른 방법을 식별하려고합니다. 이러한 점 중 하나에 깊이 들어가 려면 많은 공간이 필요합니다.

프로그램과 그 사양 사이의 격차를 줄이는 한 가지 방법은 공식적인 의미를 가진 언어를 사용하는 것입니다. 여기서 흥미로운 예는 Esterel 입니다. 공식적인 방법을 현실로 가져 오는 그의 작품에 대한 흥미로운 이야기는 Gérard Berry의 웹 페이지를 살펴보십시오. http://www-sop.inria.fr/members/Gerard.Berry/

ps 에어 버스에 있었습니까? 공식적인 방법으로 비행했습니다!

"실제 세계"에서 신뢰할 수있는 소프트웨어를 구축하는 과학은 여전히 ​​개발되고 있으며, 컴퓨터와 소프트웨어는 버그를 "원인"으로 만들지 않기 때문에 본질적으로 문화적 또는 인류 학적 연구에 어느 정도까지 영향을 미치고 있습니다. 이 답변은 공식적인 소프트웨어 검증을 하나의 요소로 볼 수있는 일반적인 Q / A 접근 방식에 중점을 둘 것입니다.

주목할만한 사실은 "충분히 좋은"소프트웨어이지만 "버기"인 소프트웨어는 종종 시장에서 테스트되었지만 기능이 낮은 소프트웨어보다 더 많이 팔릴 수 있다는 것입니다. 다시 말해서, 시장은 소프트웨어 품질과 소프트웨어 엔지니어링의 현대 기술에 항상 프리미엄을 부여하는 것은 아니며, 품질을 항상 강조하지는 않지만 다소 반영합니다. 또한 품질은 종종 최종 제품에 상당한 비용을 추가 할 수 있습니다. 이러한 경고와 함께 몇 가지 기본 사항이 있습니다.

• 중복 / 내결함성 시스템. 이것은 광범위한 연구 영역입니다. 내결함성 및 중복성은 시스템의 여러 계층에 설계 될 수 있습니다. 예를 들어 라우터, 서버, 디스크 드라이브 등.

• 테스트 . 단위 테스트, 통합 테스트, 사용자 승인 테스트, 회귀 테스트 등 모든 유형

• 요즘 무인으로 실행할 수있는 테스트 스위트를 통한 자동화 된 테스트 가보다 개발 / 중요합니다. 실행중인 테스트 스위트는 종종 빌드 도구와 결합됩니다.

• 테스트에서 중요한 개념은 코드 커버리지 입니다. 즉, 어떤 코드가 테스트에 의해 실행 되는지 입니다. 테스트는 테스트에서 "만지지"않은 코드에서 버그를 찾을 수 없습니다.

• 테스트의 또 다른 주요 개념은 쉽게 액세스 할 수없는 코드를 시험하는 테스트 하네스 입니다.

• 테스트는 모든 레벨의 소프트웨어를 실행해야합니다. 소프트웨어가 잘 모듈화되어 있으면 어렵지 않습니다. 높은 수준의 테스트는 코드에 깊이 침투해야합니다. 작은 테스트 설정 증가로 많은 양의 코드를 실행하는 테스트 "테스트 레버리지"를 .

• 코드 만들기 를 가능한 한 최소한으로 복잡하게 것이 테스트에 중요합니다. 아키텍처 디자인에서는 테스트를 고려해야합니다. 동일한 기능을 구현하는 방법은 여러 가지가 있지만 테스트 적용 범위 / 레버리지와는 다른 의미가 있습니다. 코드의 모든 브랜치마다 종종 다른 테스트 사례가 있습니다. 분기 내의 분기는 코드 경로의 기하 급수적으로 증가합니다. 따라서 고도로 중첩 된 / 조건부 논리를 피하면 테스트 기능이 향상됩니다.

• 공부 유명한 (대규모) 소프트웨어 오류 많은 예 및 사례 연구가있는 것은 품질의 고려 사항을 지향 사고 방식을 역사를 이해하고 개발에 도움이됩니다.

• 하나는 테스트로 날아갈 수 있습니다! 둘 다 문제가있다테스트 너무 적거나 너무 많은 있습니다 . "달콤한 장소"가 있습니다. 소프트웨어는 극단적으로 구축 할 수 없습니다.

• 가장 효과적인 방법으로 모든 기본 도구를 사용하십시오. 디버거, 코드 프로파일 러, 테스트 코드 범위 도구, 결함 추적 시스템 등! 반드시 고정 저지하지 않지만 추적 추적 소프트웨어의 아주 작은 결함.

• SCM, 소스 코드 관리 및 분기 기술 의 신중한 사용은 회귀 방지, 수정 격리 및 진행 등에서 중요합니다.

• N- 버전 프로그래밍 : 미션 크리티컬 소프트웨어 개발에 자주 사용되는 실습입니다. 이 관행의 전제는 N 독립적으로 개발 된 프로그램이 동일한 공통 버그 / 오류를 가질 가능성이 없다는 것입니다. 이것은 몇 가지 논문 에서 비판되었습니다. 그러나 NVP 는 이론적 인 개념이 아닙니다.

물리학 자 Feynman은 NASA가 자신의 저서 "다른 사람들의 생각에 신경 쓰는가? — 팀 A와 팀 B. 팀 A가 소프트웨어를 구축했다고 말합니다. 팀 B는 팀 A에 대한 대적 접근 방식을 취하여 소프트웨어를 파괴하려고 시도했습니다.

팀 B가 좋은 소프트웨어 엔지니어링 배경을 가지고 있다면, 즉 코드 하네스 / 프로그램 테스트 등을 작성할 수 있습니다. 반면에 팀 B는 팀 A와 거의 동일한 수준의 리소스를 가지고 있었지만이 방법은 소프트웨어 제작 비용의 거의 두 배가 될 수 있기 때문에 비용이 많이 듭니다. 더 일반적으로, 개발 팀에 비해 더 작은 QA 팀이 있습니다.

오래된 접근법 (그러나 여전히 일부 응용 프로그램에서 사용됨)은 N 버전 프로그래밍입니다

Wikipedia에서 :

멀티 버전 프로그래밍 이라고도하는 N- 버전 프로그래밍 ( NV- 버전 프로그래밍 ) 은 동일한 초기 사양에서 기능적으로 동등한 여러 프로그램이 독립적으로 생성되는 소프트웨어 엔지니어링의 방법 또는 프로세스입니다. N- 버전 프로그래밍의 개념은 1977 년 Liming Chen과 Algirdas Avizienis에 의해 "프로그래밍 노력의 독립성이 두 개 이상의 버전의 프로그램에서 발생하는 동일한 소프트웨어 결함의 가능성을 크게 줄일 것"이라는 중심 추측과 함께 도입되었습니다. NVP는 내결함성 또는 중복성을 구축하여 소프트웨어 작동의 안정성을 향상시키는 것입니다. ....

예를 들어 " 고장 비행을위한 내결함성 비행 제어 시스템 구축 과제 "

fajrian,이 질문은 소프트웨어 엔지니어의 연구에서 가장 큰 두 가지 문제, 즉 사양과 모델 사이, 모델과 코드 사이의 적합성을 다룹니다. 여기에서 시스템이 수행 할 작업 또는 수행 방식을 나타내는 모델을 모델링하십시오. 시스템을 모델링하기위한 많은 레벨이 있습니다.

따라서 귀하의 질문에 가장 적합한 답변을 찾으려고 노력하는 사람들이 있습니다. 예를 들어 공식적인 방법을 사용하여 모델을 기반으로 소프트웨어의 정확성을 확인하는 것은 매우 어렵 기 때문입니다. 나는 JML을 알고있다 이 그것을 수행하는 방법이라는 있지만 사용법의 한계를 모릅니다.

결론적으로, 코드의 정확성을 확인하는 것이 어려워지는 방식으로 사람들은 공식적인 방법과 테스트를 혼합하여 사양에서 자동으로 테스트를 만듭니다. 실시간 시스템의 한 예는 입 / 출력 시간 이벤트를 기반으로 하는 TIOSTS 입니다.

테스트는 공식적인 방법이 아니며 신뢰성을 향상 시키지만 정확성을 검사하지는 않습니다.

2-3 년 전에 저는 소프트웨어에 적용되는 공식적인 방법을 살펴보기 시작했습니다. 이것은 호기심과 더 긴 시간에 걸쳐 프로그래밍 도구와 방법을 배워야한다는 느낌으로 인해 퀘스트가되었습니다. 나는에 대해 wishfully 꿈이지만 실버 총알 "올바른 프로그램을 작성하려면 어떻게해야합니까?"라는 질문에 대한 답이 없다고 생각했습니다.

일부 도구 (Z, B, VHDL 및 Estelle)를 사용한 후이 퀘스트에서 TLA +를 사용하고 있습니다. 있습니다. 이것은 모델 확인 및 기계 교정을위한 소프트웨어 도구를 갖춘 시간 논리의 변형입니다. L. Lamport가 그 뒤에 있었고, 구문이 단순했고, 많은 예제가 있었고, 그것을 돌보는 커뮤니티가 있었고, 언어와 도구가 상당히 잘 문서화되어 있기 때문에이 접근법을 선택했다고 생각합니다.

내 첫 질문에 대해서는 완전한 답이 없다고 생각합니다. 그러나 공식적으로 시스템의 일부를 지정하는 것은 비용을 지불한다는 사실을 배우는 것이 좋습니다. 복잡한 것을 리버스 엔지니어링하는 것도 매우 유용합니다. 즉, 어렵고 중요한 부분에 대한 청사진을 작성하는 것이 효과적입니다. 그러나 프로젝트를 매우 구체적인 환경으로 제한하지 않는 한 사양을 프로그래밍 언어 또는 프레임 워크로 자동 변환하는 효과적인 방법은 없다고 생각합니다. 또한 공식 사양을 사용하면 소프트웨어를 테스트하지 못할 것이라고 생각하지 않습니다.

간단히 말해서, 나는 다음과 같은 은유 (램 포르 트)가 정말로 강력하다고 생각합니다. .

이 퀘스트에서 다음 리소스가 유용하다는 것을 알았습니다.

• 소프트웨어 사양 방법 . 이 책은 기존 방법과 도구에 대한 광범위한 개요를 제공합니다. 여기에서 Z, SDL, TLA +, Petri Nets, Coq 등의 기본 설명 및 예를 찾을 수 있습니다.
• TLA +가 귀하의 요구에 적합하다고 생각되면 시스템 지정 책을 추천합니다 . 이 책은 무료로 구할 수 있으며 다음과 같이 연주하는 예제가 제공됩니다. :).
• 최근에는 공식적인 방법에 대한 두 가지 다른 관점, 공식적인 방법에 대한 사례 및 공식적으로 검증 된 수학 이라는 두 가지 관련 기사를 읽었습니다 .

행운을 빕니다!

지금까지 답변은 사양과 코드를 서로 관련시키는 방법의 기초에 대해 말해야 할 대부분의 내용을 이미 다루었습니다. 이 스레드의 헤더에있는 질문에 접근하는보다 실용적인 점을 추가하고 싶습니다.

미션 크리티컬 소프트웨어는 어떻게 만드나요?

오류 (사양 위반 또는 "일반적인 버그")에 대해 코드를 자동으로 분석하는 도구가 있습니다. 내 지식으로,이 방법은 주로 정적 분석을 기반으로하며 언급 한 이론 (LTL / CTL / ...)과 즉시 관련이 없지만 실제 코드에서 오류를 발견하고 실제 지점에서 이미 실현 가능합니다. 산업 프로젝트에서 이러한 도구를 사용하십시오. 나는 개인적으로 그중 많은 것을 사용하지는 않았지만, 이러한 도구는 실무자가 받아들이 기 시작합니다. 자세한 내용은 다음 블로그 기사를 참조하십시오.

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

인증 알고리즘 은 미션 크리티컬 소프트웨어를 구축 할 때 유용 할 수 있습니다.

인증 알고리즘은 각 출력에서 ​​특정 출력이 버그에 의해 손상되지 않았 음을 증명하거나 증명하기 쉬운 증거를 생성하는 알고리즘입니다.

이 설문지에서 더 많은 정보를 확인하십시오 : McConnell, RM 및 Mehlhorn, K. 및 Naher, S. 및 Schweitzer, P.

그렇다면 소프트웨어 (사양뿐만 아니라)가 실제로 올바른지 확인하는 방법은 무엇입니까?

단위 테스트? 스펙의 모든 단일 요구 사항에 대한 테스트를 작성한 다음 구현의 모든 단일 메소드를 테스트하여 해당 출력 / 입력이 해당 스펙을 준수하는지 확인하십시오. 변경 사항이 이전 작동 기능을 중단하지 않도록 이러한 테스트를 지속적으로 실행하도록 자동화 할 수 있습니다.

이론적으로 말하면, 단위 테스트의 코드 적용 범위가 100 % 인 경우 (즉, 코드의 모든 단일 방법이 테스트되는 경우) 테스트 자체가 정확하고 현실적이라면 소프트웨어가 정확해야합니다.