프로그램 정확성, 사양

위키피디아 (Wikipedia) : 이론적 인 컴퓨터 과학에서 알고리즘의 정확성은 알고리즘이 사양과 관련하여 정확하다고 언급 될 때 주장된다.

그러나 문제는 "적절한"사양을 얻는 것이 사소한 작업이 아니며 올바른 방법을 얻을 수있는 100 % 올바른 방법이 없다는 것입니다. "하나"와 같이 "보이기"때문에 술어를 스펙으로 사용하십시오. 왜 "보이기"때문에 프로그램을 올바른 것으로 간주하지 않습니까?

우선, 당신은 절대적으로 옳습니다 : 당신은 진짜 관심사에 있습니다. 공식 검증은 프로그램 정확성에 대한 신뢰 문제를 사양 정확성에 대한 신뢰 문제로 이전하므로 은색 총알이 아닙니다.

그래도이 프로세스가 여전히 유용한 이유는 여러 가지가 있습니다.

1. 사양은 종종 코드 자체보다 단순합니다. 예를 들어 정수 배열을 정렬하는 문제를 고려하십시오. 성능을 향상시키기 위해 영리한 작업을 수행하는 상당히 정교한 정렬 알고리즘이 있습니다. 그러나 사양은 설명하기가 매우 간단합니다. 출력은 순서가 커야하며 입력의 순열이어야합니다. 따라서 코드 자체의 정확성보다 사양의 정확성에 대한 신뢰를 얻는 것이 더 쉽다는 것이 틀림 없습니다.

2. 단일 실패 지점이 없습니다. 한 사람이 스펙을 작성하고 다른 사람이 소스 코드를 작성한 다음 코드가 스펙을 충족하는지 공식적으로 확인한다고 가정하십시오. 그러면 탐지되지 않은 결함이 사양 과 코드 모두에 존재 해야합니다. 어떤 경우에는 결함의 일부 유형, 덜이 Feel로 위해 : 그것은 덜 당신이 사양을 검사 할 때 결함을 간과 거라고입니다 및 소스 코드를 검사 할 때 결함을 감상 할 수 있습니다. 전부는 아니지만 일부.

3. 부분 사양은 코드보다 훨씬 간단 할 수 있습니다. 예를 들어, 프로그램에 버퍼 오버런 취약점이 없어야한다는 요구 사항을 고려하십시오. 또는 배열 인덱스 범위를 벗어난 오류가 없어야한다는 요구 사항이 있습니다. 이것은 증명할 수있는 아주 좋고 유용한 것입니다 간단한 사양입니다. 이제 공식적인 방법을 사용하여 전체 프로그램이이 사양을 충족하는지 확인할 수 있습니다. 이는 상당히 복잡한 일이지만 성공하면 프로그램에 대한 신뢰가 높아집니다.

4. 사양이 코드보다 덜 자주 변경 될 수 있습니다. 공식적인 방법이 없다면 소스 코드를 업데이트 할 때마다 업데이트에 버그 나 결함이 없는지 수동으로 확인해야합니다. 공식적인 방법은 이러한 부담을 잠재적으로 줄일 수 있습니다. 사양이 변경되지 않는다고 가정하면 소프트웨어 업데이트에는 사양 변경이 아닌 코드 변경 만 포함됩니다. 그런 다음 각 업데이트에 대해 사양이 여전히 올바른지 확인해야하는 부담 (변경되지 않았으므로 사양에 새로운 버그가 도입 될 위험이 없음)과 코드가 여전히 있는지 확인해야하는 부담이 줄어 듭니다. 맞습니다 (프로그램 검증 프로그램이이를 확인합니다). 원래 사양이 올바른지 확인해야하지만 개발자가 새로운 패치 / 업데이트 / 변경을 할 때마다 계속 확인하지 않아도됩니다.

마지막으로, 스펙은 일반적으로 선언적이며 코드로 직접 실행되거나 컴파일 될 필요는 없습니다. 예를 들어, 다시 정렬을 고려하십시오. 스펙은 출력이 증가하고 입력의 순열이라고 말하지만이 스펙을 직접 "실행"하는 명확한 방법은없고 컴파일러가 자동으로 코드를 컴파일하는 명확한 방법은 없습니다. 따라서 스펙을 올바른 것으로 간주하고 실행하는 것은 종종 옵션이 아닙니다.

그럼에도 불구하고 결론은 동일하게 유지됩니다. 공식적인 방법은 만병 통치약이 아닙니다. 코드 정확성에 대한 (매우 어려운) 신뢰 문제를 스펙 정확성에 대한 (어려운) 신뢰 문제로 이전합니다. 사양의 버그는 실제 위험이며, 일반적이며 간과 할 수 없습니다. 실제로 공식적인 방법 커뮤니티는 때때로 문제를 두 부분으로 분리합니다. 검증 은 코드가 사양을 충족하는지 확인하는 것입니다. 검증 은 사양이 올바른지 확인하는 것입니다 (필요에 부합 함).

당신은 또한 즐길 수 실제로 공식 프로그램 검증을 하고 왜 우리는 컴파일 시간 보장으로 더 연구되지 않습니까? 이것에 대한 더 많은 관점을 위해.

DW의 대답은 훌륭 하지만 한 지점에서 확장하고 싶습니다. 사양은 코드를 확인하는 기준이 아닙니다. 공식적인 사양을 갖추어야하는 이유 중 하나는 몇 가지 기본 속성을 증명하여 사양을 확인하는 것입니다. 물론 사양을 완전히 검증 할 수는 없습니다. 검증은 사양 자체만큼 복잡하므로 끝이없는 프로세스가됩니다. 그러나 유효성 검사를 통해 일부 중요한 속성을 더욱 강력하게 보장 할 수 있습니다.

예를 들어 자동차 자동 조종 장치를 설계한다고 가정합니다. 이것은 많은 매개 변수를 포함하는 매우 복잡한 것입니다. 자동 조종 장치의 정확성 속성에는“차가 벽에 부딪치지 않을 것”및“차가 이동하라는 지시에 따라 운전할 것”과 같은 것들이 포함됩니다. "자동차가 벽에 부딪치지 않을 것"과 같은 속성이 정말 중요하므로이를 증명하고 싶습니다. 시스템은 물리적 환경에서 작동하므로 물리적 제약을 추가해야합니다. 계산 시스템의 실제 속성은 "재료 과학에 관한 이러한 가정과 자동차 센서의 장애물 인식에 관한 가정에서 자동차는 벽에 충돌하지 않습니다"와 같은 것입니다. 그러나 그럼에도 불구하고 결과는 분명히 바람직한 비교적 간단한 속성입니다.

코드에서이 속성을 증명할 수 있습니까? 완전히 공식적인 접근 방식을 따르는 경우 궁극적으로 이것이 진행되고 있습니다 ¹. 그러나 코드에는 많은 부분이 있습니다. 브레이크, 카메라, 엔진 등은 모두 자율적으로 제어됩니다. 브레이크의 정확성 속성은 " '브레이크 적용'신호가 켜져 있으면 브레이크가 적용되는"과 같습니다. 엔진의 정확성은“클러치 신호가 꺼져 있으면 엔진이 바퀴를 구동하지 않습니다”입니다. 그것들을 모두 모으려면 매우 높은 수준의 시각이 필요합니다. 사양은 시스템의 다른 구성 요소를 함께 연결할 수있는 중간 레이어를 만듭니다.

실제로, 자동차 자동 조종 장치와 같은 복잡한 시스템은 다양한 양의 미세 조정을 통해 여러 수준의 사양을 갖습니다. 세련미 접근 방식은 종종 디자인에 사용됩니다. "차가 벽에 부딪치지 않을 것"과 같은 높은 수준의 속성으로 시작한 다음 센서와 브레이크가 필요하고 센서, 브레이크에 대한 기본 요구 사항을 해결해야합니다. 그리고 파일럿 소프트웨어를 구성한 다음, 이러한 기본 요구 사항을 구성 요소 디자인 (센서의 경우 레이더, DSP, 이미지 처리 라이브러리 등)으로 다시 세분화합니다. 공식 개발 프로세스에서는 각 레벨의 스펙은 최상위 레벨 특성에서 코드까지 모든 레벨에서 설정 한 요구 사항을 충족시키는 것으로 입증되었습니다.

사양이 올바른지 확인하는 것은 불가능합니다. 예를 들어, 물리학에 문제가있는 경우, 브레이크 코드와 공식적인 요구 사항을 비교 한 계산이 정확하더라도 브레이크가 효과적이지 않을 수 있습니다. 실제로 5000kg 인 경우 500kg의 하중으로 파단이 효과적이라는 것을 증명하는 것은 좋지 않습니다. 그러나 500kg이 브레이크 코드 내부에서 자동차의 물리적 매개 변수에 충분하지 않다는 것을 보는 것보다 잘못되었음을 쉽게 알 수 있습니다.

¹ _{완전히 공식적인 접근 방식의 반대는“이것이 효과가있는 것 같지만 확실하지 않습니다”입니다. 당신이 인생에 베팅 할 때 그렇게 좋아 보이지 않습니다.}