공식적인 방법이 작동한다는 것을 어떻게 알 수 있습니까?

공식적인 방법의 중요한 목표는 자동화 된 또는 사람이 지시하는 방법으로 시스템의 정확성을 입증하는 것입니다. 그러나 올바른 증거를 제공 할 수 있어도 시스템이 실패하지 않을 것이라고 보장하지 못할 수 있습니다. 예를 들면 다음과 같습니다.

• 사양이 시스템을 올바르게 모델링하지 않거나 생산 시스템이 모델링하기에 너무 복잡하거나 모순 된 요구 사항으로 인해 시스템에 결함이있을 수 있습니다. 사양이 의미가 있는지 테스트하는 기술은 무엇입니까?
• 증명 과정에도 결함이있을 수 있습니다! 이러한 추론 규칙이 정확하고 합법적이라는 것을 누가 알 수 있습니까? 또한 증명은 매우 클 수 있으며 오류가 없다는 것을 어떻게 알 수 있습니까? 이것은 De Millo, Lipton 및 Perlis의 "사회적 과정과 정리의 정리와 프로그램"에서 비판의 핵심입니다. 현대의 공식적인 방법론 연구자들은이 비평에 어떻게 대응 하는가?
• 런타임에는 시스템에 심각한 영향을 줄 수있는 많은 비 결정적 이벤트 및 요소가 있습니다. 예를 들어, 우주 광선은 예측할 수없는 방식으로 RAM을 변경할 수 있으며,보다 일반적으로 Lamport가 견고하게하기 어려운 비잔틴 결함을 하드웨어가받지 않을 것이라는 보장은 없습니다. 따라서 정적 시스템의 정확성으로 인해 시스템이 실패하지는 않습니다. 실제 하드웨어의 오류를 설명하는 기술이 있습니까?
• 현재 테스트는 소프트웨어 작동을 위해 가장 중요한 도구입니다. 공식적인 방법으로 보완 도구가되어야합니다. 그러나 나는 공식적인 방법이나 테스트에 중점을 둔 연구를 주로 본다. 두 가지를 결합하는 것에 대해 알려진 것은 무엇입니까?

4 관련 : 공식적인 방법과 테스트를 결합한 많은 작업이 있습니다. 인터넷 검색 "공식 분석법 테스트"는 상당히 많은 작업을 보여줍니다. 이러한 작업에는 여러 가지 목표가 있지만 핵심 목표 중 하나는보다 효과적인 테스트 스위트를 생성하는 것입니다. 이 대화 는 모델 검사를 기반으로 멋진 소개를 제공합니다.

또한 문제 로부터 편집 된 소프트웨어 보안 문제와 관련하여 공식적인 방법은 그 영역에서 제공하기 위해 더 열심히 노력해야합니다. 일반적으로 소프트웨어에 대한 사양을 작성하고 사양이 충족되는지, 즉 입력이 사전 조건을 만족할 때 출력이 사후 조건을 만족하는지 확인합니다. 안전한 소프트웨어를 보장하기 위해서는 소프트웨어가 전제 조건을 만족하지 않는 입력에 대해 적절하게 동작하는지 확인해야합니다. (이것은 물론 모든 입력에 대해 전제 조건을 true로 설정하는 것과 같습니다.) 모든 입력의 공간은 일반적으로 올바르게 구성된 입력보다 훨씬 큽니다. 그러나 일반적으로 이것은 기능적으로 올바른 소프트웨어조차도 위반할 수있는 한 곳입니다. 그 가정을 위반하는 것.

포인트 3 관련 : 결함 논리 : 결함 허용 프로그램에 대한 추론을 포함하여 결함 이 명시 적으로 모델링 된 설정에서 시스템을 확인하기위한 일부 작업이 수행되었습니다 . Matthew Meola와 David Walker. 프로그래밍에 관한 유럽 심포지엄, 2010. 확률 적 모델 점검과 확률 적 검증에 관한 연구는 어느 정도 결함 문제를 어느 정도 해결한다.

순서대로 포인트 :

• 모든 사양의 정확성은 궁극적으로 주관적입니다. 사용자에 따라 문제를 올바르게 해결하거나 그렇지 않은 것으로 인식됩니다. 이것은 소프트웨어 개발에서 벗어나지 않으며,이 방법에 대한 총알은 없습니다.
• 프로세스가 가정과 관련하여 올바른지 증명하기 위해 많은 노력이 필요합니다. 일반적으로 전문가가 이러한 규칙을 검증 할 수있는 정보가 있습니다. 모든 인간 활동에는 오류가 있지만 잘 연구 된 접근 방식을 사용하는 매우 공식화 된 시스템 은 거의 모든 다른 인간 프로세스보다 오류에 덜 영향을받습니다.
• 어느 시점에서 모든 시스템은 해당 시스템의 범위를 벗어난 장애 모드를 갖습니다. 예측할 수없는 오류를 고려하지 않은 경우에도 예측 가능한 모든 오류 원인을 제거하는 것이 좋습니다 .
• 테스트와 증명은 쉽게 공존 할 수 있습니다. 테스트는 덜 구체적이고 임시적인 프로세스이므로 공식적인 작업이 줄어 듭니다. 그러나 Haskell 유형 시스템에서 제공하는 증명을 테스트로 보완하는 QuickCheck 와 같은 도구에 관심이있을 수 있습니다 .

공식적인 방법은 이미 크게 작동하는 것으로 나타났습니다. 그것들이 없다면 우리는 현대 디지털 시스템 (마이크로 프로세서) 설계의 복잡성에 대처할 수 없었을 것입니다.

기능적 동등성 검증을 받아야하는 로직이없는 마이크로 선박은 없습니다. FPU가 FV의 영향을받지 않은 경우; 캐시 일관성 프로토콜이 FV에 종속되지 않은 경우 (1995 년 이후).

소프트웨어와 엔지니어링 된 물리적 시스템 (예 : 안전 요소를 추가 할 수있는 브리지) 간의 명백한 차이점을 제외하고 CS에서 엔지니어링 수학의 역할을합니다. 그러나 FM의 사용은 항상 이익 / 비용에 달려 있습니다. 퍼즈 테스트는 Microsoft와 같은 회사 (한 번에 Google SAGE)에서 큰 성과를 거두고 있습니다.

마이크로 내부에서도 FV가 다른 곳과 동일한 영향을 미치지 않는 서브 시스템 (예 : 마이크로 프로세서 파이프 라인)이 있습니다 (예 : FPU, 공식적인 상징적 궤적 평가에서 버그가 없음을 입증 한 경우에 기존 테스트가 전혀 수행되지 않은 경우) : Kaivola et al. CAV'09).

공식적인 방법은 인공물 (코드, 고품질 테스트, 배터리 뱅크를 최적으로 방전시키는 일정 등)의 합성에도 사용됩니다. 물론,이 문제에서 제기 된 모든 문제는 매우 유효하며 다른 기술 사용과 마찬가지로 허위 광고를 인식하고 피해야합니다.

2 : 시스템이 교정 조교 (예 : Twelf 또는 Agda 또는 Coq)로 공식화되고 건전성과 완전성의 특성이 검증되고 교정이이 인코딩으로 수행되면 이는 문제가되지 않습니다. 의도 한 바를 설명하지 않는 시스템을 공식화했을 수도 있지만 적어도 잘못된 증거 나 추론중인 시스템이 손상되지는 않습니다.

그러나 정확한 증거를 제공 할 수 있어도 시스템이 실패하지 않을 것이라고 보장하지 못할 수 있습니다.

예, 아마도 보장이 없습니다 . 공식적인 방법은 오류를 찾아서 제거하고 사람을 설득하기위한 것입니다.

사양이 의미가 있는지 테스트하는 기술은 무엇입니까?

공식적인 시스템 사양을위한 모델 확인 도구에 관심이있을 수 있습니다 .

증명 과정에도 결함이있을 수 있습니다! 이러한 추론 규칙이 정확하고 합법적이라는 것을 누가 알 수 있습니까?

추론 규칙 시스템을 보여주는 것은 (Goedel의 불완전 성 정리로 인해) 일관성이 필연적으로 훨씬 더 강력한 추론 규칙에 호소한다고 생각합니다.

또한 증명은 매우 클 수 있으며 오류가 없다는 것을 어떻게 알 수 있습니까?

바라건대, 사람이 합리적인 시간 안에 읽고 이해할 수있는 작은 증명 검사기가 거대한 증명을 검사하기를 바랍니다. 이것을 "de Bruijn 기준"이라고도합니다. 증명 검사기가 잘못된 증명을 인증하지 않는다고 생각되면 검사기 만 확인하면됩니다.

실제 하드웨어의 오류를 설명하는 기술이 있습니까?

방법에 대한 오류 허용 언어 조립 입력 ?

그러나 나는 공식적인 방법이나 테스트에 중점을 둔 연구를 주로 본다. 두 가지를 결합하는 것에 대해 알려진 것은 무엇입니까?

"TAP 회의는 증명 및 테스트의 수렴에 전념하고 있습니다. "

"증거 및 테스트"에 대한 인터넷 검색만으로도 몇 가지 좋은 결과를 얻을 수 있습니다.

사양이 의미가 있는지 테스트하는 기술은 무엇입니까?

확실히 판결 요청입니다. 소프트웨어 엔지니어링에서 사람들은 사양을 찾고 / 작성 / 확인하기 위해 매우 엄격한 방법론을 설계했습니다. 이것은 실제 인간에 의해 수행되고 비정규적인 (수학적 과정이 아닌 의미에서) 비정형 화를 사용하므로 여전히 불일치의 대상이되지만 하루가 끝날 무렵에는 사람들이 확인하고자하는 것에 해당합니다.

실제 하드웨어의 오류를 설명하는 기술이 있습니까?

물론, 런타임 검증으로 알려진 검증 분야가 있으며 특정 시나리오에 따라 완전히 가상 환경에서 실행되는 실제 시스템에서 실행 기반 모델 검사를 사용할 수도 있습니다 ( V-DS + APMC로 나에게 기여 했습니다 ). 그러나 이는 시스템과 환경 간의 상호 작용을 확인 프로세스에 추가하는 데있어 중대한 문제입니다.

그러나 나는 공식적인 방법이나 테스트에 중점을 둔 연구를 주로 본다. 두 가지를 결합하는 것에 대해 알려진 것은 무엇입니까?

와, 오늘 나는 완전히 부끄러워하지 않고 다시 인용 할 것이다. 공동 저자와 함께 모델 검사와 테스트를 함께 수행하면 그룹의 전 박사 학위 학생의 출판 목록을 보거나 좋은 검색 엔진에서 "대략 확률 모델 검사"또는 "통계 모델 검사"를 검색 할 수 있습니다 (작업 수행) Younes 등, Sen 등 또는 내 자신 및 기타 다수).

PVS 정리 증명 자 중 한 사람인 John Rushby 의 작품에 관심이있을 것 입니다. 이 고전 읽기 즐길 수있는 정형 기법의 사용 및 중요 시스템의 인증 (1993)에 대해 연방 항공청 (FAA)에 보고서를 , 그의 새로운 작품 , 다양한 제공된 증거의 수단 (테스트, 교정에서 확률, 형식적인 안전 케이스 조립에 대한 분석 등).