영어와 같은 자연어로 모호하지 않은 사양을 작성할 수 있습니까?

자연어의 비공식적 성격으로 인해 모호성이 전혀없는 소프트웨어 사양을 영어로 작성할 수는 없으며, 따라서 진정한 모호하지 않은 사양에는 공식적으로 지정된 언어로 작성된 코드가 포함되어야합니다.

이것은 알려진 결과입니까, 아니면 뭔가 빠졌습니까?

이것이 변호사가 항상 모호성을 피하기 위해 한 일이 아닙니까?

그 결과 가장 부 자연스러운 방식으로 글을 쓰고 논문을 읽는 것이 그 어느 때보 다 어려워지며, 그럼에도 불구하고 항상 불일치와 모호성이 있습니다.

귀하는 그렇습니다. 모호성이 완전히없는 소프트웨어 사양을 작성할 수는 없지만 공식적으로 지정된 언어를 구현하는 것은 관리 할 수 ​​없습니다.

그렇기 때문에 우리가 코드를 문서화하는 이유도 있습니다.

다른 코드로 코드를 문서화 할 필요가 없습니다.

불가능한? 그것이 바람직한 지 물어 보자. 불가능하다는 데 동의하고 유용한 소프트웨어가 여전히 많다면 분명한 사양의 목표는 학문적 인 것 같습니다.

스펙과 소프트웨어 모두 완벽하고 모호하지 않다는 것을 증명하는 것은 불가능하다고 말하고 싶습니다.

문제의 크기에 달려 있다고 생각합니다. 문제가 충분히 작고 본질적으로 수학적이며 아마도 누락 된 다른 기준이 있다면 실행 가능한 사양을 작성할 수 있다고 말하고 싶습니다.

문제가 클수록 청중이 넓어 질수록 더 어려워집니다.

그러나 항공 전자 공학 및 기타 복잡한 문제는 큰 문제를 해결하기 위해 영어로 "충분히 좋은"사양을 작성할 수 있음을 시사합니다.

글쎄 .. 문제의 완전히 명백한 사양은 실제 코드 자체입니다 :)

이것은 알려진 문제이며 특별한 미션 크리티컬 시스템의 경우, 공식적인 (프로그래밍) 언어로 모호하지 않은 사양을 작성하고 사양에 명시된 기능을 수행 하는 코드로 변환해야합니다 . 이것은 매우 좁은 분야이며, 개발자의 99.999 %는 이와 같은 작업을 수행 할 필요가 없지만 교통 통제 / 철도 시스템을 위해 이것을 한 사람과 이야기를 나 once습니다.

저는 W3C 추종자이며 사양에 따라 기사를 작성하는 경향이 있습니다. 내 경험에 따르면 예제 코드를 작성하지 않고 사양 을 읽는 것은 두통 일뿐입니다.

나는 완전히 동의하고 주된 이유는 개발자가 코드를 더 잘 읽고 이해하는 경향이 있다고 생각합니다. 공식없이 수학 종이를 얻는다고 상상해보십시오.

To calculate the result, simply add variable x to variable y, 
and then divide that by the b factor.

또는:

result = (x + y) / b

어느 것이 더 짧은가요? 어느 것이 더 읽기 쉬운가? 어느 쪽이 더 이해가 되나요?

사양에 대해서도 마찬가지입니다. 여러 번 기술 부분에 도달하면 한 줄의 코드를 작성하면 긴 설명 단락이 명확 해질 수 있습니다.

명확한 사양을 작성할 수있는 공식 언어가 있다고 가정하십시오. 그런 다음 영어 하위 집합에 대한 형용사 매핑이 있어야한다고 제안합니다. 따라서이 하위 집합을 고수하면 명확한 사양을 작성할 수 있어야합니다.

그러나 흥미로운 일을 할 정도로 표현력이있는 공식 언어에는 불일치가 없습니다 (Gödel 불완전 성).

사람들이 모호하고 부정확하기 때문에 사양이 모호하고 부정확합니다. 완벽한 사람을 찾으면 완벽한 사양을 얻을 수 있습니다.

영어, 스와힐리어, 산스크리트어 또는 바빌론은 아무런 차이가 없습니다.

모호성은 실제로이 맥락에서 강점입니다.

이유를 설명하기 위해, 그것을하는 순간 가정하자 입니다 프로그래밍 방식으로 해결 될 수있는 문제가 완벽하고 명확하게 표현 될 수 있도록하는, 완전히 명확한 방법으로 영어를 사용할 수있다. 우리가이 영어 변형을 사용하고 우리의 설명이 실제로 프로그램이 완전하고 명확하게 작성되도록 설명한다면, 논리적으로 다음과 같이 목표 프로그래밍 언어로의 자동 번역을 수행 할 수 있어야합니다. 우리가 잉태 한 영어는 실제로 프로그래밍 언어 그 자체입니다.

디자인 문서 (특히 기능적 디자인)를 읽는 사람들은 실제로 이러한 수준의 세부 정보를 원하지 않습니다. C ++, Java 또는 명확한 영어로 프로그램 소스를 읽는 것은 프로그래머가 아닌 일반 사용자보다 훨씬 낫습니다. 여기에서 자연어가 등장합니다. 스펙 작성자가 세부 스케일로 이동하거나 관련없는 구현 세부 사항을 서브 텍스트로 이동 시키거나 완전히 지정하지 않은 채로 둘 수 있습니다. 자연어는 정확한 정의를 제공하지 않아도 (자동 번역을 어렵게 만드는 요소 중 하나) 의미를 비교적 명확하게 전달하는 장치로 가득합니다.

따라서 목표는 일반적으로 완전하고 정확하며 모호하지 않은 사양이 아닙니다. 목표는 당신이 만들려고하는 것을 사람에게 명확하게 보여주는 사양을 작성하는 것입니다.

정확하고 모호하지 않고 어쨌든 기술이 필요한 경우, 의사 코드는 종종 자연 언어 또는 엄격한 공식 언어보다 가치가 있습니다.하지만 지정되지 않은 함수 / 프로세스를 호출하여 관련이없는 세부 사항은 여전히 ​​생략 할 수 있지만 구조는 모호하지 않습니다. .

인간이 읽을 수 있도록 문서가 작성되었다는 점을 제외하고는 아무것도 빠졌습니다. 간결한 텍스트를 읽기가 어렵 기 때문에 어떤 모호함이 예상되고 심지어 환영받을 수도 있습니다 (= 인간이 아님).

다른 공식 언어로 공식 언어 문서를 지정하는 것은 일종의 닭과 계란 문제 일 것입니다.

공식적인 사양이 필요한 경우 모델 을 확인 하는 공식적인 방법이 있습니다. 활발하고 흥미로운 연구 분야이지만, 여기서 "사용자"는 인간이 아닌 기계입니다.

(내 의견 중 일부는 이미 다른 답변으로 언급되었지만, 의견이 아닌 답변의 가치를 높이기 위해 다른 관점을 제공하고 있다고 생각합니다.)

사양이 진정으로 완벽하게 모호 할 수 있는지 여부에 대한 문제를 해결하기 전에 , 적어도 요구하는 수준에서 사양이 모호하지 않아야 하는지에 대한 문제를 해결해야합니다 .

중소 규모의 프로젝트에서 작업하는 프로그램 관리자 또는 더 큰 프로젝트의 일부인 기능의 관점에서 이에 접근하겠습니다. 일반적으로 이러한 프로젝트를 위해 작성 될 두 가지 유형의 사양이 있습니다 : 기능 (또는 PM) 사양과 디자인 (또는 개발) 사양 :

• 기능 명세는 기술의 직업이 무엇 projecty 또는 기능은 종종 고객의 관점에서 수행해야합니다. 일반적 으로이 작업을 수행 하는 방법을 설명 해서는 안됩니다. 프로젝트 유형에 따라 고객은 외부 API의 모양을 관리 할 수 ​​있지만 클래스 A가 클래스 B를 상속하는지 아니면 인터페이스 C를 구현하는지 여부를 관리합니까? 그는해서는 안됩니다. 그리고 기능 사양도 마찬가지입니다. 이것은 이미 기술 설계의 한 수준의 모호성을 소개합니다.
• 설계 사양에는 기능 또는 프로젝트의 설계자 또는 기술 설계자의 관점에서 기능 요구 사항을 충족시키는 방법 이 설명되어 있습니다. 기술 설계의 고급 모호성을 해결하기위한 것입니다. 여기에는 프로젝트의 범위와 규모에 따라 클래스 구조, 상속, 개별 함수 및 방법 등 솔루션 아키텍처와 같이 기능 사양에서 원하지 않는 세부 사항이 포함됩니다. 아키텍트는 임시 변수라고 부르거나 내부 데이터 유형에 목록 또는 배열을 사용하는지 여부를 관리합니까? 그녀가 개발자를 신뢰한다고 가정하면 디자인 사양을해서는 안됩니다. 이는 구현의 두 번째 수준의 모호성을 소개합니다.

일반적으로 이러한 구현 수준의 세부 사항은 공식 문서에서 캡처되지 않습니다 아니라, 문서화 자체 코멘트를 포함한 코드에서 자체. 이러한 모호함은 훌륭한 개발자가 자신의 기술을 사용하고 훌륭한 개별 개발자의 특징 인 세부적인 기술 결정을 내릴 수 있도록합니다. 이 때문에 스펙의 모호함이 실제로 좋은 것이라고 말하고 주저하지 않을 것입니다. 개발자가 자신의 작업을 수행하고 단순한 "코드 원숭이"이상으로 향상시킬 수 있습니다.

그러나 이것은 전체 문서에 모호성이 있어야한다는 것은 아닙니다. 높은 수준에서는 고객과의 인터페이스에 대한 모호성이 없어야합니다. 기능에 공개 API가있는 경우 엄격하게 정의해야합니다. 시스템이 작업을 수행하기 위해 날짜를 전달해야하는 경우이 날짜가 현지 시간대 또는 UTC 여야합니까? 어떤 형식이 필요합니까? 밀리 초까지 정확해야합니까, 아니면 분은 괜찮습니까?

자연어를 사용하여 명확한 사양을 만들 수 있는지 에 대한 질문으로 되돌아 가면 ,이 수준의 선명도를 잘 포착하지 못하는 것이 사실입니다. 나는 그것이 제한된 특정 상황에서 이루어진 것을 보았지만, 우리가 보편적으로 적용 할 수없는 독특한 예외 일 것입니다. 대부분의 경우 모호성은 기술 전문 용어, 다이어그램 또는 의사 코드를 사용하여 해결됩니다. 그러한 도구의 도움을 받기 시작하면 자연어는 유일한 설명자가 아닙니다. 이러한 툴은 기능적으로 명백한 사양을 훨씬 더 명확하게 만들 수 있기 때문에 그러한 사업을 시도해서는 안된다고 말하고 싶습니다.

자연 언어는 일반적으로 이러한 도구를 통해 기능적으로 모호하지 않게하기 때문에 자연 언어만으로는 모든 경우에 모호하지 않은 사양을 작성하기에 충분하지 않다는 전문가의 의견 입니다.

자연어를 비교적 명확하게 만들 수 있지만 큰 어려움이 있습니다.

법률 직업은 언어가 가능한 한 분명해야합니다. 법이 어떻게 적용되는지에 대해 많은 것이 해석에 개방적 일 수 있지만, 그 단어의 의미는 해석해서는 안됩니다.

이것은 법률의 발명으로 이어진다. 당신은 얼마나 멀리 갈 의향이 있습니까?

개방형 그룹, ISO, IETF 및 ITU에는 경쟁이 치열한 회사가 상당히 성공적으로 상호 운영 할 수있는 많은 사양이 있습니다. 수백만 달러가 사용되는 계약 또는 법률의 기초가되는 많은 사양이 있습니다.

따라서 사양이 "완벽하지"않을 수 있습니다. 그러나 그것은 인간이 완벽하지 않기 때문입니다. 예를 들어 HTTP가 "Referer"헤더를 사용해야한다는 것은 분명합니다. 올바른 철자는 실제로 "Referrer"입니다.

영어는 모호하지 않지만 인간은 모호성을 포함하여 실수를 할 수 있습니다.

또한 아직 확정되지 않았거나 향후 업데이트가 필요한 세부 사항에 대해서는 의도적으로 모호한 것이 도움이 될 수 있습니다. 예를 들어, 사양은 md5, sha1, crc32 등을 구체적으로 지정하지 않고 "해시"를 지정할 수 있습니다.

정답이 부정적이라고 생각합니다. 다음 질문을 구별해야합니다.

1. 모호성이없는 자연 언어로 소프트웨어 사양을 작성할 수 있습니까?
2. 모호성이없는 자연 언어로 소프트웨어를 작성할 수 있습니까?

첫 번째 질문과 두 번째 질문의 차이점은 소프트웨어 또는 소프트웨어 사양을 작성하기위한 목적으로 필요한 세부 수준, 필요한 해석의 양 및 자연 언어로 문장을 구성하는 규칙에 관한 것입니다.

두 번째 질문에 대한 답은 긍정적입니다. 문장 구성과 의미에 대해 합의 된 규칙을 가진 자연어의 적절하게 제한된 하위 집합이 주어지면 코드는 문법 영어 문장으로 작성 될 수 있습니다. 예를 들어, 다음 언어는 할당 문 작성을 명백하게 허용합니다.

Variables: x,y,z,...
Constants: 1,2,3,...
Rules: (1) if x is a variable and n a constant, then
           "The variable x contains the number n" is a sentence.
       (2) if x is a variable and n a constant, then
           "Assign the number n to the variable x" is a sentence.

즉, 각 절차 를 설명 함으로써 공식 프로그래밍 언어로 작성된 코드를 자연 언어로 체계적으로 변환 할 수 있습니다 . 반면에 소프트웨어 사양 에는 종종 해석이 필요합니다. 따라서, 소프트웨어 사양이 명확하게 제공 될 수 있는지의 여부는 사양과 관련된 상세 수준에 달려있다. 그러나, 사양이 범위에 걸쳐 선택된 도메인,이 도메인에 대한 특정 동작이 선택된 상태에서 유사한 번역 프로세스가 수행 될 수있다. 예를 들어 :

Over the domain D supporting operations f,g,h over elements a,b,c in relations
P,R,Q with properties φ,ψ,θ, design a program that does X,Y,Z.

문 어디에 X, Y, Z사양의 서문에 언급 된 항목 만 포함하고 적절한 형식으로 작성하고 합의 된 자연 언어의 하위 집합입니다. 모호성은 사양을 구현하는 방법 과 관련이 있지만 이는 예상됩니다.

아니

명백한 계산 사양은 컴퓨터 프로그램입니다.