소프트웨어의 공식적인 방법을 배웠다면 얼마나 유용 했습니까?

프로그래밍을 위해 공식적인 방법 (FM)을 사용하도록 훈련을받은 경우 :

• 얼마나 유용 했습니까?
• FM 교육에는 무엇이 포함 되었습니까 (예 : 강좌, 책)?
• 어떤 FM 도구를 사용하십니까?
• FM을 사용하지 않는 것과 비교하여 속도 / 품질에서 어떤 이점이 있습니까?
• FM으로 어떤 종류의 소프트웨어를 작성합니까?
• 그리고 지금 FM을 직접 사용하지 않는다면 최소한 배울 가치가 있습니까?

이 커뮤니티에서 찾을 수있는만큼 FM에 대한 많은 경험 / 의견을 듣고 싶습니다. 나는 그것을 읽고 시작하고 더 알고 싶어요.

배경

프로그래밍 및 소프트웨어 개발 / 엔지니어링은 지구상에서 가장 최신의 인간 기술 / 직업 중 일부이므로 놀랍지 않게이 필드는 미숙합니다. 이는 필드의 주요 출력에 일반적으로 늦고 오류가 발생하기 쉬운 코드로 표시됩니다. 업계 미성숙도는 평균 코더와 최고 코더 사이의 생산성이 큰 차이 (최소 10 : 1)로 표시됩니다. 이러한 엉뚱한 사실은 문헌에서 잘 다루고 있으며 Steve McConnell의 Code Complete 와 같은 책에서 소개합니다 .

공식적인 방법 (FM) 의 사용은 소프트웨어 / CS (예 : E. Dijkstra 후기 )의 주요 인물들에 의해 오류의 근본 원인 중 하나 인 프로그래밍의 수학적 엄격함의 부족을 해결하기 위해 제안되었습니다 . 예를 들어 Dijkstra 는 프로그램과 그 증거를 함께 개발하는 학생들을 옹호했습니다 .

FM은 미국에 비해 유럽의 CS 커리큘럼에서 훨씬 더 널리 퍼져있는 것 같습니다. 그러나 지난 몇 년 동안 새로운 "경량"FM 접근 방식과 Alloy 와 같은 도구 가 주목을 받았습니다. 그럼에도 불구하고 FM은 업계에서 일반적으로 사용되는 것과는 거리가 멀고, 나는 왜 여기에 대한 피드백을 기대하고 있습니다.

최신 정보

현재 (2010 년 10 월 14 일) 현재, 아래 6 가지 답변 중 "현실"작업에서 FM 사용에 대해 분명히 주장한 사람은 없습니다. 누군가가 할 수 있고 의지 할 수 있다면 정말 궁금합니다. 또는 FM은 실제로 학계 (FM은 미래입니다!)와 산업 (FM은 대부분 쓸모가 없음)의 차이를 보여줍니다.

사소한 일에는 절대 쓸모가 없습니다.

나는 합금에 중점을 둔 "공식 방법 (Formal Methods)"이라고 불리는 과정을 가졌다. LTSA와 마찬가지로 쓸모없는 동시성 모델링에 중점을 둔 다른 클래스가 있습니다.

문제는 소프트웨어의 버그와 문제 (적어도 내 경험으로는 대부분)가 해당 도구의 추상화 수준 아래에서 발생하는 복잡성으로 인해 발생한다는 것입니다.

CSP (Communicating Sequential Processes)에 대한 배경 지식이 있습니다. 내 자신의 경적을 표명하지는 않지만 Timed CSP에 대한 석사 논문, 특히 공식적인 메소드로 작성된 "컴파일"사양을 실행 가능한 C ++로 작성했습니다. 공식적인 방법에 대한 경험이 있다고 말할 수 있습니다. 학위를 마치고 업계에 취업 한 후에는 공식적인 방법을 전혀 사용하지 않았습니다. 공식적인 방법은 여전히 ​​업계에 적용하기에는 너무 이론적입니다. 공식적인 방법은 임베디드 시스템 분야에서 일부 실제 적용을 발견했습니다. 예를 들어 NASA는 프로젝트에서 공식적인 방법을 사용합니다. 공식적인 방법이 업계에서 널리 채택되는 것과는 거리가 멀다고 생각합니다. 공식적인 방법으로 소프트웨어 사양을 작성하고 선택한 프레임 워크에 "인간 해석"하는 것은 의미가 없습니다. 일반 영어와 다이어그램이 더 잘 작동하는 반면, 단위 및 통합 테스트는 코드의 정확성을 "확인"하는 작업을 잘 수행해 왔습니다. 나는 생각한다공식적인 방법은 학계에서 한동안 남아있을 것이다 .

상태 다이어그램 및 페트리 넷은 프로토콜 및 실시간 시스템을 모델링하고 분석하는 데 유용합니다. 먼저 솔루션 설계를 돕습니다. 둘째, 매우 특정한 상황에서 흥미로운 소프트웨어에 대한 테스트 사례를 찾는 데 도움이됩니다.

공식적인 방법에 대한 몇 권의 책을 읽었으며 일부를 적용했습니다. 저의 즉각적인 반응은 "이 책은 내가 완벽한 수학자 인 한 좋은 프로그래머가되는 방법을 말해줍니다." 또 다른 약점은 다른 공식적인 설명과의 동등성을 증명할 수 있다는 것입니다. 프로그램에 대한 공식 사양을 작성하는 것은 고급 언어로 프로그램을 작성하는 데있어 가장 중요하며, 상당히 큰 사양으로 버그를 도입하는 것을 피할 수있는 방법은 없습니다.

공식적인 방법으로 대규모 작업을 한 적이 없습니다. 그것들은 작고 까다로운 올바른 것을 얻는데 유용하며 그들이 옳다는 것을 확신시켜줍니다. 그런 식으로, 나는 약간 더 큰 빌딩 블록으로 작업하고 때로는 조금 더 할 수 있습니다.

내가 좀 더 일반적으로 유용했던 것은 불변의 개념, 프로그램에 대한 진술, 그리고 항상 사실 인 상태입니다. 당신이 추론 할 수있는 모든 것이 좋습니다.

위에서 언급했듯이, 나는 완벽한 수학자가 아니므로 내 증거에는 때때로 오류가 있습니다. 그러나 내 경험에 따르면 이들은 포착하기 쉽고 수정하기 쉬운 큰 바보 같은 경향이 있습니다.

나는 공식적인 프로그램 분석에서 대학원 과정을 밟았으며 여기서 우리는 운영 의미론에 중점을 두었습니다. 나는 seL4 노력에 대한 최종 논문을 작성하여 그들이 사용한 공식적인 방법을 검토했다. 실용성 측면에서 나의 주요 테이크 아웃은 한계가 있다는 것이었다. 프로그램을 작성해야 할뿐만 아니라 증명도 작성해야합니다. 와. 두 가지 버그 소스. 하나만이 아닙니다. 또한 실제 코드에는 많은 양의 제한이있었습니다. I / O를 포함한 물리적 컴퓨터를 공식적으로 설명하기는 매우 어렵습니다 .

작년에 TLA +를 스스로 가르쳤다. 프로젝트를 시작할 때마다 도달하는 첫 번째 도구 중 하나입니다. 대부분의 사람들이 저지르는 실수는 공식적인 방법이 전부 또는 전혀 없다고 가정하는 것입니다. 공식적인 방법을 사용하지 않거나 완전한 검증을받은 것입니다. 그러나 프로젝트 사이에 추상적 인 사양이 불변성을 깨뜨리지 않는지 확인하는 형식적인 사양 (formal specification) 사이에는 무언가가 있습니다 . 검증과 달리, 사양은 산업에서 사용하기에 충분히 실용적입니다.

사양 언어는 프로그래밍 언어보다 표현력이 좋습니다. 예를 들어, 분산 데이터 저장소에 대한 (매우) 간단한 PlusCal 사양은 다음과 같습니다.

process node \in 1..5 \* Nodes
variables online = TRUE,
          stored \in SUBSET data; \* Some set
begin 
  Transfer:
    either
      with node \in Nodes, datum \in stored do
        node.stored := node.stored \union {datum};
      end
    or \* crash
      online := FALSE;
    end either;
end process;

이 스 니펫은 5 개의 노드가 동시에 실행되고 임의의 순서로 전송되며, 모든 전송은 임의의 노드에 대한 임의의 데이터 조각입니다. 또한 지정된 전송이 실패하고 노드가 충돌 할 수 있도록 지정했습니다. 또한 TLA + 모델 검사기에서 이러한 모든 동작을 시뮬레이션 할 수 있습니다! 그렇게하면 주문, 고장률 등에 관계없이 요구 사항이 여전히 충족되는지 테스트 할 수 있습니다. 이것에 대해 몇 가지 요구 사항을 추가해 봅시다. 먼저 데이터를 오프라인 노드로 전송하지 않습니다.

[][\A node \in Nodes: ~online => UNCHANGED node.stored]_vars

단순화 된 버전에서 모델 검사기는 실패 상태를 찾습니다. "어떤 주어진 데이터가 하나 이상의 온라인 노드에 있습니다"를 지정할 수도 있습니다.

\A d \in data: \E n \in Nodes: n.online /\ d \in n.stored

어느 쪽도 실패 할 것입니다. 단위 테스트로 확인하십시오.

사양의 주요 제한 사항은 실제 코드와 독립적으로 존재한다는 것입니다. 디자인이 올바르게 구현되었다는 것이 아니라 디자인이 정확하다고 말할 수 있습니다. 그러나 검증하는 것보다 지정하는 것이 빠르며 테스트하기에 너무 미묘한 버그를 포착하므로 노력할 가치가 있습니다. 동시성 또는 여러 시스템과 관련된 거의 모든 코드는 공식 사양에 적합합니다.

저는 Fujitsu가 인수하기 전에 ICL 부서에서 일했습니다. 그들은 소프트웨어가 광고 된대로 작동했다는 증거 를 요구하는 일부 정부 유형의 계약을 맺었 으므로 Z로 작성된 공식 사양을 채택 하고 코드가 실행되는 동안 통과 할 수있는 큰 녹색 또는 적색 표시등으로 코드를 검증 하는 기계를 만들었 습니다. 불합격.

그것은 놀라운 일이지만, 존경받는 @FishToaster가 지적했듯이 사소한 것은 쓸모가 없었습니다.

1. " 얼마나 유용 했습니까? "

Petri Nets를 컴퓨터 프로그래밍에 적용하는 것은 매우 유용합니다. Petri Nets (Chionglo, 2014)를 기반으로 한 방법 인“Net Elements and Annotations”를 만들었습니다. 2014 년 이후이 방법을 적용하여 PDF 양식 응용 프로그램에 Acrobat / JavaScript API를 사용하는 JavaScript 프로그램을 작성했습니다.

2. “ FM 교육에는 무엇이 포함 되었습니까 (예 : 강좌, 책)? "

나는 자율 학습을 통해 Petri Nets에 대해“훈련”했습니다. 나는“Petri Nets and Grafcet : Discrete Event Systems 모델링 도구”(David and Alla, 1992) 교과서에서 Petri Nets에 관한 장을 읽었습니다. 또한 Petri Nets에 관한 연구 논문을 읽고 있습니다. “순 요소 및 주석”을 작성하고 문서화 한 후 몇 주 동안이 방법을 적용하는 방법을 연습했습니다.

3. “ 어떤 FM 도구를 사용하십니까? "

PowerPoint를 사용하여 Petri Net 다이어그램을 그립니다. Word를 사용하여 주석의 양식보기를 만듭니다. Acrobat과 Notepad를 사용하여 토큰 게임을 PDF 양식 응용 프로그램으로 만듭니다. 항목을 양식에 추가 한 후 이러한 항목을 JavaScript 코드로 변환하는 것은 체계적입니다. 따라서 번역을 자동화 할 수 있어야합니다. "항목"이 PowerPoint의 그래픽스 개체에 추가 된 경우, 체계적으로 JavaScript 코드로 변환하고이 번역을 자동화 할 수도 있습니다. 또한 이러한 변환을 수행하고 PDF 양식 응용 프로그램을 만들기위한 추가 리소스를 만드는 진행중인 작업 도구 세트도 사용합니다 (Chionglo, 2018; 2017).

4. “ FM을 사용하지 않는 것과 비교했을 때 속도 / 품질면에서 어떤 이점이 있습니까? "

“Net Elements and Annotations”를 사용하지 않고 JavaScript 프로그램을 작성할 수있는 것보다“Net Elements and Annotations”를 사용하여 JavaScript 프로그램을 더 빨리 작성할 수 있습니다. 그리고 큰 프로그램의 경우 어디에서 계속할 것인지 궁금하지 않고 코딩을 중단하고 나중에 (또는 그 이후에) 코딩으로 돌아갈 수 있습니다 (Chionglo, 2019). 경우에 따라“Net Elements and Annotations”를 사용하여 JavaScript 프로그램을 작성할 수 있지만“Net Elements and Annotations”를 사용하지 않으면 JavaScript 프로그램을 작성할 수 없습니다. 예를 들어“Net Elements and Annotations”(Chionglo, 2019b; 2018b; 2016)를 사용하지 않고 재귀 함수의 비 재귀 구현을 만들 수 없었습니다. 이는 진행중인 작업 도구의 유무에 관계없이 적용됩니다.

5. " FM으로 어떤 종류의 소프트웨어를 만드십니까? "

“Net Elements and Annotations”를 사용하여 PDF 양식 응용 프로그램에 Acrobat / JavaScript API를 사용하는 JavaScript 프로그램을 만듭니다. HTML 문서 용 JavaScript 프로그램을 작성하고 Arduino Sketches (Chionglo, 2019c; 2019d)를 작성하는 방법을 적용 할 수도 있습니다.

6. " 지금 FM을 직접 사용하지 않는다면 최소한 배울 가치가 있었습니까? "해당 사항이 없습니다.

참고 문헌

JF Chionglo (2019b). 재귀 관계의 N 번째 용어 계산 : 비 재귀 함수 사용 – 수학 스택 교환에서 질문에 대한 답변. < https://www.academia.edu/38496025/Computing_the_N-th_Term_of_a_Recursive_Relation_Using_a_Non-Recursive_Function_A_Reply_to_a_Question_at_Mathematics_Stack_Exchange >.

JF Chionglo (2019c). 화염 효과 제어 논리, 시뮬레이션 및 스케치 : Arduino 커뮤니티 포럼의 요청에 대한 답변. https://www.academia.edu/40342956/Flame_Effect_Control_Logic_Simulation_and_Sketch_A_Reply_to_a_Request_at_the_Arduino_Community_Forum .

JF 치옹로 (2019). 오랜 휴식 후 응용 프로그램을 계속 코딩하려면 어떻게합니까? "2 주 휴식 후 코드에서 어디에서 멈췄는지 어떻게 알 수 있습니까?"– Software Engineering Stack Exchange. https://www.academia.edu/39705042/How_I_Continue_Coding_an_Application_after_a_Long_Break_Reply_to_How_do_you_know_where_you_stopped_in_your_codes_after_a_2-week_break_Software_Engineering_Stack_Exchange .

JF Chionglo (2019d). 표시 및 숨기기 제어 논리 : 스택 오버플로의 질문에서 영감을 얻었습니다. < https://www.academia.edu/40283015/Show-and-Hide_Control_Logic_Inspired_by_a_Question_at_Stack_Overflow >.

JF Chionglo (2018b). 숫자의 계승에 대한 페트리 넷 모델 : 그리고 비 재귀 JavaScript 함수로 계산 <>.

JF Chionglo (2018). Hyper Form ™-진행중인 워크 플로 만들기 : Net Programming Research의 업데이트. https://www.academia.edu/37697498/Create_Hyper_Form_-A_Workflow_in_Progress_Update_on_the_Net_Programming_Research .

JF Chionglo (2017). 넷 프로그래밍 : 연구 제안 : PowerPoint 및 Acrobat을 사용하여 PDF 양식 응용 프로그램 개발 용. https://www.academia.edu/33374809/Net_Programming_A_Research_Proposal_For_Developing_PDF_Form_Applications_with_PowerPoint_and_Acrobat. .

JF Chionglo (2016). 피보나치 수를 계산하기위한 페트리 넷 모델. https://www.academia.edu/31748108/A_Petri_Net_Model_for_Computing_the_Fibonacci_Number.

JF Chionglo (2014). 컴퓨터 프로그래밍을위한 순 요소 및 주석 : PDF의 계산 및 상호 작용. https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .

David, R. 및 H. Alla. (1992). Petri Nets 및 Grafcet : 개별 이벤트 시스템 모델링 도구. 뉴저지 어퍼 새들 : 프렌 티스 홀.