) [UNK] 프로그래밍 v. d. e. h 구조적 프로그래밍 ( structured programming ) 은 구조화 프로그래밍으로도 불리며 프로그래밍 패러다임의 일종인 절차적 프로그래밍의 하위 개념으로 볼 수 있다. GOTO문을 없애거나 GOTO문에 대한 의존성을 줄여주는 것으로 가장 유명하다. 역사적으로 구조적 프로그램을 작성하기 위하여 몇가지 다른 구조화 기법과 방법론이 개발되어왔다. 가장 일반적인 3가지는 다음과 같다. 잭슨의 구조적 프로그래밍 : 자료구조를 프로그램 구조에 맞추는 것에 중점을 두었다. 데이크스트라의 구조적 프로그래밍 : 프로그램의 논리 구조는 제한된 몇 가지 방법만을 이용하여 비슷한 서브 프로그램들로 구성된다. 프로그램에 있는 각각의 구조와 그 사이의 관계를 이해하면 프로그램 전체를 이해해야 하는 수고를 덜 수 있어, SoC에 유리하다. 데이크스트라의 관점에서 파생된 관점 : 하위 프로그램의 시작점은 한 군데이지만 끝점은 여러 개일 수 있다. 대부분의 사람들이 구조적 프로그래밍이라고 할 때 첫 번째 것을 제외한 둘 중에 하나를 말하는 것이며, 이것이 여기서 말하고자 하는 것이다. 목차 1 요약 1. 1 저수준 구조 1. 2 고수준 구조 1. 3 설계 2 구조적 프로그래밍 언어 3 역사 3.
구조적 프로그래밍 - 위키백과, 우리 모두의 백과사전 구조적 프로그래밍 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 프로그래밍 패러다임 행위 에이전트 지향 배열 지향 오토마타 기반 병행 컴퓨팅 상대주의적 프로그래밍 데이터 기반 선언형 ( 반의어 : 명령형 ) 함수형 함수 논리형 순수 함수형 논리형 가추법 Answer set 병행 논리 함수 논리 귀납적 논리 제약 제약 논리 병행 제약 논리 데이터플로 플로 기반 반응형 동적 / 스크립트 사건 기반 함수 레벨 ( 반의어 : 값 레벨 ) 포인트 프리 스타일 연결식 제네릭 명령형 ( 반의어 : 선언형 ) 절차적 객체 지향 문학적 언어 지향 자연어 프로그래밍 규율 지향 도메인 특화 문법 지향 의도적 메타프로그래밍 자동 귀납적 프로그래밍 반영 속성 지향 매크로 템플릿 비구조적 ( 반의어 : 구조적 ) 배열 비결정 병렬 컴퓨팅 프로세스 지향 확률론적 스택 지향 구조적 ( 반의어 : 비구조적 ) 블록 구조 객체 지향 행위자 기반 클래스 기반 병행 프로토타입 기반 관심사의 분리에 따라 : 관점 지향 역할 지향 주체 지향 재귀 심볼릭 값 레벨 ( 반의어 : 함수 레벨 ) [UNK] 프로그래밍 v. d. e. h 구조적 프로그래밍 ( structured programming ) 은 구조화 프로그래밍으로도 불리며 프로그래밍 패러다임의 일종인 절차적 프로그래밍의 하위 개념으로 볼 수 있다. GOTO문
프로그램의 정확성을 증명하는 문제를 떠나서 데이크스트라가 그의 논문에서 말한 대로 시간에 따라 변하는 동적인 과정을 시각화하는 것은 인간에게 매우 어려운 일이다. 꼭 GOTO문만의 문제가 아니라 구조화된 흐름 제어문을 사용한다고 할지라도 너무 복잡하게 중첩되어 있거나 스코프의 길이가 너무 긴 코드를 작성한다거나 너무 긴 길이의 하위프로그램을 작성하는 일을 가급적 피하게 경향이 생겼다. 그리고 이런 습관은 다른 사람이 작성한 프로그래밍 코드를 쉽게 이해하는 데 도움을 준다. 데이크스트라가 쓴 " GOTO문의 해로움 " 이라는 논문은 이후 "... 의 해로움 " 이라는 유행을 낳기도 하였다. 이는 컴퓨터 과학에서 과도하게 사용되는 어떤 것에 대한 것을 비판하는 데 많이 사용되었다. 읽을거리 [ 편집 ] 비구조적 프로그래밍 ( 대조되는 개념 ) 프로그래밍 패러다임 순서도 ( 고급 순서 구조에 대한 더 자세한 내용이 있음 ) 구조적 예외 처리 최소 평가 참고문헌 [ 편집 ] ( 영어 ) 에츠허르 데이크스트라, Notes on Structured Programming, pg. 6 ( 영어 ) [UNK], C. 와 야코피니, G. : Flow diagrams, Turing machines and la
대 초반에 개발되었는데 주로 데이크스트라, 플로이드, 호, 그리즈가 많은 공헌을 했다. 논쟁 [ 편집 ] 구조적 프로그래밍의 선구적 실천가 ( 얼리어답터 ) 인 플로저는 구조적 프로그램 정리에 대한 그의 반응을 이렇게 설명했다. : 우리는 이 흥미로운 소식을 어셈블리 프로그래머들에게 알려주면서 마음을 돌려보려 하였지만, 이 덜된 어셈블리 프로그래머들은 비비꼬인 로직의 비트들을 만들어내면서 계속해서'이런건 구조화가 안될껄'이라고 말하고 있다. [UNK] 야코피니의 증명을 보여주어도, 우리가 구조적 코드를 성공적으로 계속해서 만들어서 보여주어도, 그들은 구조화된 프로그래밍 적응 준비를 하루도 앞당기지 않았다. 1967년, CACM에 데이크스트라의 " GOTO문의 해로움 " ( Go to statement considered harmful ) 라는 서한이 실렸다. 이 글에서 그는 [UNK] 야코피니의 증명을 인용하면서, 고급언어에서 GOTO 명령을 제거하는 것이 코드의 질을 높일 수 있다고 했다. 이 글은 주로 구조적 프로그래밍 논쟁의 시작점으로 인용된다. 비록 플로저가 언급했듯이 다수의 프로그래머들이 이 정리에 익숙하지 않다고 해도, 이런 프로그래머들을
크스트라, Notes on Structured Programming, pg. 6 ( 영어 ) [UNK], C. 와 야코피니, G. : Flow diagrams, Turing machines and languages with only two formation rules, CACM 9 ( 5 ), 1966. 외부 링크 [ 편집 ] ( 영어 ) Notes on Structured Programming and Variation Analysis ( Programming Wisdom Center ) vdeh컴퓨터 과학의 주요 분야수학적 기초 수리논리학 집합론 정수론 그래프 이론 형 이론 범주론 수치해석학 이산수학 계산 이론 오토마타 이론 계산 가능성 이론 계산 복잡도 이론 양자 계산 이론 알고리즘 & 자료 구조 알고리즘 알고리즘 설계 알고리즘 해석 자료 구조 계산기하학 프로그래밍 언어 & 컴파일러 구문 분석 컴파일러 인터프리터 프로그래밍 언어 구조적 프로그래밍 객체 지향 프로그래밍 병렬 & 분산 시스템 병렬 컴퓨팅 컴퓨터 클러스터 분산 컴퓨팅 그리드 컴퓨팅 클라우드 컴퓨팅 IaaS PaaS SaaS 소프트웨어 공학 요구 분석 소프트웨어 설계 컴퓨터 프로그래밍 정형 기법 소프트웨어 테스트 소프트웨어 개발 시스템 아키텍처 컴퓨터 아키텍처 마이크로아키텍처 운영 체제 통신 & 네트워크 컴퓨터 오디오 라우팅 네트워크 토폴로지 암호학 차세대 통신망 데이터베이스 데이터 마이닝 RDBMS SQL NoSQL 오라클 데이터베이스 인공 지능 자동추론 전산언어
의 코드를 이해하기 쉬운 크기의 작은 하부 프로그램 ( 함수, 프로시저, 메서드, 블록, 등 ) 으로 나누어야 한다. 일반적으로 프로그램은 전역 변수는 거의 사용하지 않아야 하고 대신에 하부 프로그램은 지역 변수를 사용하거나, 값이나 참조에 의한 인자를 받아야 한다. 이런 기법은 전체 프로그램을 한번에 이해하지 않고, 분리된 작은 코드 조각을 쉽게 이해하는 데 도움을 준다. 설계 [ 편집 ] 구조적 프로그래밍은 항상 그런 것은 아니지만 하향식 설계와 관련이 있다. 하향식 설계를 할 때, 설계자는 큰 규모의 프로그램을 더 작은 공정으로 나누어 구현하고, 각각 검사한 다음에 전체 프로그램으로 합친다. 구조적 프로그래밍 언어 [ 편집 ] 모든 절차적 프로그래밍 언어에서 구조적 프로그래밍을 할 수 있다. 1970년쯤부터 구조적 프로그래밍이 인기있는 기법이 되었기 때문에, 대부분의 새로 나온 절차적 프로그래밍 언어들이 구조적 프로그래밍을 고취시키기 위한 특징을 추가하였고 구조화되지 않은 프로그래밍을 쉽게 하기 위한 특징들은 남겨둔 것들도 있었다. 잘 알려진 구조적 프로그래밍 언어에는 파스칼 ( Pascal ) 과 에이다 ( Ada ) 가 있다. 역사 [ 편집 ] 이론적 기반 [ 편집 ] 구조적 프로그램 정리는 구조적 프로그래밍의 이론적 기반이 되었
게 할 것이다. 대부분의 언어는 구조적 프로그래밍에서의 여러 종료점을 지원한다. C는 continue, break, return과 같이 여러가지 경로로 구조에서 빠져나가는 것을 허용하고, 더 새로운 언어들은 레이블한 루프 ( 전자와 비슷하지만 제일 안쪽 루프 뿐만 아니라 그 이상도 빠져나갈 수 있게 해 준다 ) 와 예외처리를 지원한다. 상태 기계 [ 편집 ] 특히 구문분석기와 통신 규약 같은 프로그램들은 상태들이 있어서 기본 구조들로 줄이기가 쉽지 않다. 각각의 상태 변화를 분리하여 하위프로그램을 만들고 변수를 이용하여 활동중인 상태를 나타내면 가능하긴 하다. 하지만, 카누스를 포함한 일부 프로그래머들은 상태의 변화를 새로운 상태로 직접 분기하는 것을 더 좋아한다. 현대적 가치 [ 편집 ] 구조적 프로그래밍에 대한 논의는 많은 새로운 언어를 낳았으며, 기존의 언어에 구조적인 면이 추가되는 등 언어의 발전에 도움이 되었다. 그리고 이후에 나온 프로그래밍 패러다임들에도 영향을 끼쳤다. 구조적 프로그래밍은 프로그래머의 습관을 바꾸었다. 프로그램의 정확성을 증명하는 문제를 떠나서 데이크스트라가 그의 논문에서 말한 대로 시간에 따라 변하는 동적인 과정을 시각화하는 것은 인간에게 매우 어려운 일이다. 꼭 GOTO문만
의 질을 높일 수 있다고 했다. 이 글은 주로 구조적 프로그래밍 논쟁의 시작점으로 인용된다. 비록 플로저가 언급했듯이 다수의 프로그래머들이 이 정리에 익숙하지 않다고 해도, 이런 프로그래머들을 양성할 가치가 충분히 있을 정도로 몇 년간 소프트웨어 개발은 간결성, 품질, 개발 시간의 측면에서 향상되었다. 데이크스트라는 구조의 종류를 제한하는 것이 프로그래머가 생각하는 데 집중하는 것을 돕고, 관리 가능한 절차로 분석하여 프로그램의 유효성을 더 간단히 보장할 수 있다고 했다. 그는 1969년구조적 프로그래밍에 대한 글에서 이렇게 썼다. : 우리는 정확한 프로그램을 작성하는 프로그래머의 직분을 수행해야 할 뿐만 아니라, 그것의 정확성을 납득가능한 방법으로 증명하는 역할도 수행해야 한다. 위에서 한 언급은 프로그래머가 작성하는 모든 것은 유효하게 구조화되어야 한다는 것에 뜻 깊은 영향을 끼친다. ( 중략 ) 프로그램의 정확성뿐만 아니라 프로그램의 적응성과 관리성까지 내가 신경 쓰고 있다는 것이 더욱 명백해진다. 1 도널드 커누스 ( Donald Knuth ) 는 프로그램이 입증가능성을 염두에 두고 작성되어야 한다는 원리는 받아들였으나 GOTO문을 없애는 것은 받아들이지 않았고 지금도 받아들이지
명백해진다. 1 도널드 커누스 ( Donald Knuth ) 는 프로그램이 입증가능성을 염두에 두고 작성되어야 한다는 원리는 받아들였으나 GOTO문을 없애는 것은 받아들이지 않았고 지금도 받아들이지 않는다. 1974년, 그의 논문, " GOTO문이 포함된 구조적 프로그래밍 " 에서 직접적인 분기를 하여 입증가능성을 희생시키지 않으면서도 더 간결하고 효율적인 코드를 작성할 수 있는 몇 가지 예제를 보였다. 카누스는 좀 더 완화된 구조 제한을 제안했다. 그것은 프로그램의 순서도를 그린다면 왼쪽에는 아래쪽으로 가는 가지 ( branches ) 만, 오른쪽에는 위쪽으로 가는 가지만 그려야하며 그 가지들이 서로 교차하지 않아야 한다는 것이다. 컴파일러와 그래프 이론에 정통해 있는 많은 사람들이 축소 가능한 흐름도 ( reducible flow graphs ) 만을 허용해야한다고 이 생각을 옹호했다. 구조적 프로그램 이론가들은 1970년대 IBM의 연구원 밀즈가 구조적 프로그래밍 이론에 대한 그의 해석을 즈의 인덱싱 시스템 개발자들에게 적용한 일이 있은 후에 대부분이 합의를 봤다. 이 계획은 공학적으로 크게 성공하였다. 데이크스트라가 밀즈의 해석이 출판된 것들과 다르다며
아키텍처 마이크로아키텍처 운영 체제 통신 & 네트워크 컴퓨터 오디오 라우팅 네트워크 토폴로지 암호학 차세대 통신망 데이터베이스 데이터 마이닝 RDBMS SQL NoSQL 오라클 데이터베이스 인공 지능 자동추론 전산언어학 컴퓨터 비전 진화 연산 기계 학습 자연 언어 처리 로봇학 컴퓨터 그래픽 시각화 영상 처리 인간과 컴퓨터 상호 작용 컴퓨터 접근성 사용자 인터페이스 착용 컴퓨터 유비쿼터스 컴퓨팅 가상현실 계산과학 인공생명 생물정보학 인지과학 계산화학 계산론적 신경과학 계산물리학 수치해석학 기호계산 정보보호 암호학 물리 보안 애플리케이션 보안 인터넷 보안 네트워크 보안 해킹 크래킹 전거 통제 LCCN : sh85129214 GND : 4058133 - 0 BNF : cb11966709k ( 데이터 ) BNE : XX531013 원본 주소 " " 분류 : 전체론프로그래밍 패러다임에츠허르 데이크스트라숨은 분류 : 영어 표기를 포함한 문서LCCN 식별자를 포함한 위키백과 문서GND 식별자를 포함한 위키백과 문서BNF 식별자를 포함한 위키백과 문서 둘러보기 메뉴 개인 도구 로그인하지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더 보기 검색 둘러보기 대문사용자 모임요즘 화제최근 [UNK] 문서 보기임의 문서로도움말기부 도구 여기를 가리키는
구조적 프로그래밍(structured programming)은 구조화 프로그래밍으로도 불리며 프로그래밍 패러다임의 일종인 절차적 프로그래밍의 하위 개념으로 볼 수 있다. GOTO문을 없애거나 GOTO문에 대한 의존성을 줄여주는 것으로 가장 유명하다. 역사적으로 구조적 프로그램을 작성하기 위하여 몇가지 다른 구조화 기법과 방법론이 개발되어왔다. 가장 일반적인 3가지는 다음과 같다. 잭슨의 구조적 프로그래밍 : 자료구조를 프로그램 구조에 맞추는 것에 중점을 두었다. 데이크스트라의 구조적 프로그래밍 : 프로그램의 논리 구조는 제한된 몇 가지 방법만을 이용하여 비슷한 서브 프로그램들로 구성된다. 프로그램에 있는 각각의 구조와 그 사이의 관계를 이해하면 프로그램 전체를 이해해야 하는 수고를 덜 수 있어, SoC에 유리하다. 데이크스트라의 관점에서 파생된 관점 : 하위 프로그램의 시작점은 한 군데이지만 끝점은 여러 개일 수 있다.대부분의 사람들이 구조적 프로그래밍이라고 할 때 첫 번째 것을 제외한 둘 중에 하나를 말하는 것이며, 이것이 여기서 말하고자 하는 것이다.