구조적 프로그래밍
: 제어흐름의 직접적인 전환을 불가능하게 하거나 제한하는 것
: 데이크스트라에 의해 제기되었으며 프로그래머가 제어흐름을 제약 없이 직접 전환할 수 있었던 goto문을 지적하여 생긴 패러다임
⇒ 무분별한 goto 문장의 사용은 프로그램의 흐름을 해치고 오류를 발생시킬 수 있어서?
: goto 문장은 점차 보이지 않게 되었고 제공 되더라도 goto문의 목적지를 현재 함수 내로 한정
기능적 분해
: 구조적 프로그래밍을 통해 모듈을 증명이 가능한 더 작은 단위로 분해할 수 있게 되었고, 이는 곧 기능 단위로 분해할 수 있음을 뜻했다.
: 문제를 고수준의 기능들로 분해할 수 있었고 이들 각 기능들은 저수준의 함수로 분해되었다.
: 이러한 분해 과정을 끝없이 반복할 수 있음.
: 구조적 분석이나 구조적 설계 기법을 사용하면 프로그래머는 대규모 시스템을 모듈과 컴포넌트로 분리할 수 있다.
: 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화할 수 있다.
테스트
: 테스트를 통해 프로그램이 잘못되었음을 증명할 수 는 있지만 프로그램이 100% 기능을 수행한다고 증명할 수는 없다.
: 이는 상당히 충격적인 것이, 프로그램이 수학적인 구조를 다루는 듯이 보여도 소프트웨어 개발은 수학적인 시도가 아니라는 사실이다.
: 이러한 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용할 수 있다. 즉 goto문과 같은 제어흐름을 직접 제어하는 프로그램은 테스트를 아무리 많이 수행해도 증명이 불가능
: 거짓임을 증명하려는 테스트들이 실패한다면 이 기능들은 목표에 부합할만큼 완성되었다고 할 수 있다.
결론
: 구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 바로 이 능력 때문
: 가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고 따라서 반증 가능성에 의해 주도된다.
: 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 테스트하기 쉽도록 만들기 위해 노력해야 한다.
