실제 공식 프로그램 검증

소프트웨어 엔지니어로서 저는 산업용 제품에 대한 많은 코드를 작성합니다. 클래스, 스레드, 일부 디자인 노력, 성능 저하와 함께 비교적 복잡한 작업. 나는 많은 테스트를 수행하고 테스트에 지쳤으므로 Coq, Isabelle과 같은 공식적인 증거 도구에 관심이있었습니다 ...이 중 하나를 사용하여 내 코드에 버그가 없으며 완료되었음을 증명할 수 있습니까 그것으로? -그러나 이러한 도구 중 하나를 확인할 때마다 일상적인 소프트웨어 엔지니어링에 사용할 수 있는지 확신 할 수 없습니다. 이제, 그것은 나만이 될 수 있으며, 나는 그것에 대해 포인터 / 의견 / 아이디어를 찾고 있습니다 :-)

특히,이 도구 중 하나를 작동하게하려면 고려중인 프로그램의 객체, 방법 ...을 입증하기 위해 막대한 투자가 필요하다는 인상을 얻었습니다. 그런 다음 프로 버가 처리해야 할 모든 것의 크기를 감안할 때 스팀이 부족하지 않은지 궁금합니다. 또는 부작용을 제거해야 할 수도 있습니다 (이 입증 된 도구는 선언적 언어와 실제로 잘 작동하는 것처럼 보입니다). 그렇지 않으면 "입증 된 코드"가 빠르지 않아 사용할 수 없는지 궁금합니다. 충분히 작습니다. 또한, 내가 사용하는 언어를 바꿀 수있는 사치를 가지고 있지 않으며 Java 또는 C ++이어야합니다. 오래 전부터 보스에게 OXXXml로 코딩 할 것이라고 말할 수는 없습니다. 코드의 정확성을 증명할 수 있습니다 ...

공식적인 교정 도구에 대한 경험이 많은 사람이 의견을 제시 할 수 있습니까? 다시 - 나는 것 사랑 나는 그들이 좋은 생각, 공식적인 증명 도구를 사용하지만, 나는 그들이 내가 자바 / C ++ (PS의 낮은 도랑에서 도달 할 수 상아탑에있는 인상을 : 나는 또한 LOVE Haskell, OCaml ... 오해하지 마십시오. 나는 선언적 언어와 공식적인 증거를 좋아합니다. 소프트웨어 엔지니어링에 실제로 유용하게 사용할 수있는 방법을 찾으려고 노력하고 있습니다)

업데이트 : 이것은 상당히 광범위하므로 다음과 같은 더 구체적인 질문을 시도해 보겠습니다. 1) 산업 Java / C ++ 프로그램의 정확성을 입증하기 위해 프로 버를 사용하는 예가 있습니까? 2) Coq가 해당 작업에 적합합니까? 3) Coq가 적합한 경우 먼저 Coq로 프로그램을 작성하고 Coq에서 C ++ / Java를 생성해야합니까? 4)이 접근 방식이 스레딩 및 성능 최적화를 처리 할 수 ​​있습니까?

몇 가지 질문에 간결한 답변을 드리겠습니다. 이것은 엄격히 제 연구 분야가 아니므로 일부 정보가 오래되었거나 잘못되었을 수 있습니다.

1. Java 및 C ++의 특성을 공식적으로 증명하도록 특별히 설계된 많은 도구가 있습니다.

   그러나 나는 여기서 작은 왜곡을해야합니다 : 프로그램의 정확성을 증명한다는 것은 무엇을 의미합니까? Java 유형 검사기는 Java 프로그램의 공식 속성, 즉 a float및 a 추가 와 같은 특정 오류가 int발생할 수 없음을 증명 합니다! 훨씬 강력한 속성, 즉 프로그램이 원치 않는 상태로 들어갈 수 없거나 특정 함수의 출력이 특정 수학 사양을 준수한다는 훨씬 강력한 속성에 관심이 있다고 생각합니다. 요컨대, 간단한 보안 속성에서 프로그램이 세부 사양을 충족한다는 완전한 증거에 이르기까지 "프로그램의 정확성을 입증하는"의 의미에 대한 다양한 기울기가 있습니다.

   이제 나는 당신이 당신의 프로그램에 대한 강력한 속성을 증명하는데 관심이 있다고 가정합니다. 보안 속성에 관심이있는 경우 (프로그램 이 특정 상태에 도달 할 수 없음 ) 일반적으로 가장 좋은 방법은 모델 확인 입니다. 그러나 Java 프로그램의 동작을 완전히 지정하려면 JML 과 같은 해당 언어의 사양 언어를 사용하는 것이 가장 좋습니다 . C 프로그램의 동작 (예 : ACSL) 을 지정하기위한 이러한 언어가 있지만 C ++에 대해서는 모르겠습니다.

2. 사양이 지정되면 프로그램이 해당 사양을 준수 함을 증명해야합니다.

   이를 위해서는 적합성 이론 을 표현하기 위해 , 즉 프로그램 실행이 사양을 존중한다는 점에서 사양과 언어의 운영 의미론 (Java 또는 C ++)을 모두 공식적으로 이해하는 도구가 필요합니다 .

   이 도구를 사용하면 해당 정리의 증거를 공식화하거나 생성 할 수 있습니다. 이제이 두 가지 작업 (지정 및 증명)은 매우 어렵 기 때문에 종종 두 가지로 분리됩니다.

   • 코드, 사양을 구문 분석하고 적절성 정리를 생성하는 하나의 도구입니다. Frank가 언급했듯이 Krakatoa 는 그러한 도구의 예입니다.

   • 자동 또는 대화식으로 정리를 증명하는 도구입니다. Coq는 이러한 방식으로 Krakatoa와 상호 작용하며 Z3 과 같은 강력한 자동화 도구 도 사용할 수 있습니다.

   하나의 (사소한) 요점 : 자동화 된 방법으로는 입증하기가 너무 어려운 일부 이론이 있으며, 자동 정리 프로 버는 때때로 신뢰도를 떨어 뜨리는 건전성 버그가있는 것으로 알려져 있습니다. 이것은 Coq가 비교되는 영역입니다 (그러나 자동은 아닙니다).

3. Ocaml 코드를 생성하려면 먼저 Coq (Gallina)로 작성한 다음 코드를 추출하십시오. 그러나 Coq는 가능하다면 C ++ 또는 Java를 생성하는 데 끔찍합니다.

4. 위의 도구가 스레딩 및 성능 문제를 처리 할 수 ​​있습니까? 아마 그렇지는 않지만, 성능 및 스레딩 문제는 특히 어려운 문제이므로 특별히 설계된 도구로 처리하는 것이 가장 좋습니다. Martin Hofmann의 PolyNI 프로젝트 가 흥미로워 보이지만 여기에 권장 할 도구가 있는지 확실하지 않습니다 .

결론 : "실제"Java 및 C ++ 프로그램의 공식 검증은 대규모로 잘 개발 된 분야이며 Coq는 해당 작업의 일부에 적합합니다. 예를 들어 여기 에서 높은 수준의 개요를 찾을 수 있습니다 .

산업계 또는 사소한 실제 시스템에서 공식적인 방법 / 공식 검증 도구를 사용하는 세 가지 놀라운 응용 사례를 언급하고자합니다. 이 주제에 대한 경험이 거의 없으며 논문을 읽는 것만으로 배울 수 있습니다.

1. 2005 년 NASA가 발표 한 오픈 소스 도구 인 Java Pathfinder (JPF) 는 실행 가능한 Java 바이트 코드 프로그램을 확인하는 시스템입니다 ( Java Pathfinder @ wiki 참조 ). NASA Ames의 K9 Rover 경영 소프트웨어에서 불일치를 감지하는 데 사용되었습니다.

2. 이 백서 : 모델 검사를 사용하여 심각한 파일 시스템 오류 찾기 @ OSDI'04 는 모델 검사를 사용하여 파일 시스템에서 심각한 오류를 찾는 방법을 보여줍니다. FiSC라는 시스템은 널리 사용되는 세 가지 널리 테스트 된 파일 시스템 인 ext3, JFS 및 ReiserFS에 적용되며 32 개의 심각한 버그가 발견되었습니다. 최우수 논문상을 수상했습니다.

3. 이 백서 : Amazon Web Services가 공식적인 방법을 사용하는 방법 @ CACM'15 는 AWS가 S3, DynamoDB, EBS 및 Internal Distributed Lock Manager와 같은 제품에 공식적인 방법을 적용하는 방법을 설명합니다. Lamport의 TLA + 도구 에 중점을 둡니다 . 그런데 Lamport는 자신의 TLA 도구 상자를 집중적으로 사용했습니다. 그는 종종 논문의 부록에서 (저자 및 공동 저자)가 제안한 알고리즘 / 정리에 대해 TLA에서 (완전히 완전한) 공식 검증을 제공합니다.

프로그램의 공식 사양은 다른 프로그래밍 언어로 작성된 프로그램입니다. 결과적으로 사양에는 분명히 자체 버그가 포함됩니다.

공식 검증의 장점은 프로그램과 사양이 두 개의 개별 구현이므로 버그가 다를 수 있다는 것입니다. 그러나 항상 그런 것은 아닙니다. 간과 된 사례 중 하나 인 일반적인 버그 원인이 종종 일치합니다. 따라서 공식 검증은 만병 통치약이 아닙니다. 여전히 사소한 수의 버그를 놓칠 수 있습니다.

공식 검증의 단점은 구현 비용의 두 배와 같은 것을 부과 할 수 있다는 것입니다. 공식 사양의 전문가가 필요하며 함께 제공되는 실험 도구를 더 많이 또는 적게 사용해야합니다. ).

테스트 케이스를 설정하고 비계를 자동으로 실행하는 것이 시간을 더 잘 사용하는 것으로 생각합니다.

안전에 중요한 임베디드 시스템을 위해 설계된 C ++의 서브 세트로 작성된 프로그램에 대해 공식 검증이 가능해졌습니다. 간단한 프리젠 테이션은 http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.ppt 를, 전체 논문 은 http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf 를 참조하십시오 .

몇 가지 다른 질문을합니다. 산업 / 상업용 응용 프로그램에 대한 공식 검증 방법이 그리 일반적이지 않은 것으로 보입니다. 그러나 프로그램의 정확성을 결정하기 위해 많은 "공식 검증"원칙이 컴파일러에 내장되어 있습니다! 어떤 식 으로든 최신 컴파일러를 사용하는 경우 공식 검증에 최신 기술을 많이 사용하고 있습니다.

"테스트에 지쳤다"고 말하지만 공식적인 검증은 실제로 테스트를 대신 할 수는 없습니다. 테스트 에서 변형 된 방식으로

당신은 자바를 언급합니다. FindBugs 라는 Java 검증 프로그램에 내장 된 많은 고급 공식 검증 방법이 있으며 실제로는 큰 코드베이스에서 실행될 수 있습니다. "false positives and false negatives"가 모두 나타나고 결과는 인간 개발자가 검토 / 분석해야합니다. 그러나 실제 기능적 결함을 일으키지 않더라도 일반적으로 코드에서 피해야하는 "반 패턴"을 나타냅니다.

"산업"이외의 특정 응용 프로그램에 대해서는 더 이상 언급하지 않습니다. 실제로 공식 검증은 특정 응용 프로그램에 의존하는 경향이 있습니다.

예를 들어 마이크로 프로세서 설계에서 회로 정확성을 입증하기 위해 공식 검증 기술이 EE에서 널리 사용되는 것 같습니다.

다음은 Lars Philipson 의 EE 분야의 공식 검증 도구에 대한 설문 조사의 예입니다 .

아마도 모델 체커가 도움이 될 것입니다.

http://alloytools.org/documentation.html Alloy는 모델 검사기입니다.

Alloy를 사용한 모델 확인 개념을 설명하는 멋진 프레젠테이션 : https://www.youtube.com/watch?v=FvNRlE4E9QQ

동일한 도구 제품군에 '속성 기반 테스트'가 제공되며, 소프트웨어의 특정 사양 모델에 대한 반례를 찾으려고 노력합니다.