[S/W] Structured Programming(구조화 프로그래밍) & H/W의 발달

H/W의 발전

1960년대 후반에 IC의 개발로 인한 H/W의 급진적 발전과 이를 만족 시켜줄 새로운 S/W 개발의 필요성이 대두됨

(S/W 공학의 태동)

 

1. CPU의 발전 추세

- CPU 집적도의 한계 때문에 Multi-core 기술이 적용 > 저전력 사용 및 고성능화를 달성 - Daul-Core CPU, Quad-Core CPU 등과 같이 한 개의 CPU 내에 복수개의 Core들이 장착 됨 - Cache는 L1, L2, L3 Cache Memory 순으로 발전하며 CPU Core들 옆에 모두 장착됨 - Mobile용 AP는 절전이 중요하며, Computer CPU는 기능이 중요 ※Multi-Core 기술의 애로사항 1. 복수개의 Core들의 Memory 동시접근 가능성으로 인해 Bottle Neck 현상 발생 > 대기시간이 길어짐 2. 효율적인 Multi-Threading 프로그래밍 기법이 요구됨 3. System Programmer가 CPU 내부사항을 이해해야 됨

멀티코어와 캐시메모리

2. Memory의 발전 추세

- 기존의 SRAM과 DRAM은 휘발성 Memory라는 특성으로 인해 작업 중 Data 소실의 위험이 있음 - SRAM은 Cache Memory 구성에 DRAM은 Main Memory 구성에 사용됨 - 현재 일부 사용되고 있는 차세대 Memory에는 PRAM, RRAM, MRAM, FRAM 등이 있음 - 이들 차세대 Memory는 비휘발성과 빠른 동작속도 등으로 인해 기존 Memory 대체가 가능 - 차세대 Memory는 아직 고가이고 용량이 크지 않으며, 전력 소비나 쓰기 횟수 등에 개선점이 필요

---

Structured Programming

 

H/W는 가장 최신이고 S/W 개발 기법은 10~20년 이전의 방식을 그대로 적용하다 보니 S/W의 품질에 문제가 발생

따라서, Wirth에 의해 S/W의 설계 및 Testing 그리고 Reliability(신뢰성) 확보가 주요 이슈화 됨

무작정 S/W 개발 > Test 결과 실패율 증가 > 구조적인 접근책 요구

 

1969년 경에 NATO S/W 공학 협의회에서 S/W의 문제점이 제기되어 Dijkstra(다익스트라)가 "Structured Programming"이란 표현을 최초로 사용

 

1968년 쯤에 Dijkstra가 "Go To"문에 대한 반대 의견을 주장함

"Go To statement considered harmful" (GOTOLESS)

(* Wirth, Hoare, Bohm, Jacopini 등의 학자 역시 동의)

https://www.fntoday.co.kr/news/articleView.html?idxno=196995

GoTo문의 문제점 1. Program의 구조를 어지럽힘 2. Program의 이해 곤란 3. Program의 수정 곤란 4. Program의 길이가 길어짐 5. Maintenance 비용 상승

 

Structured Programming의 목적 1. Program Readability 향상 - 복잡도, Branch 등 감소로 이해 및 수정 등 용이 2. Program Efficiency 증진 - Memory 등 자원 이용 최소화와 Run-Time 효율성 증진 3. Program Reliability 증진 - Module / System 별로 철저한 Testing을 가능하게 함 4. Program 방법론 제공 - 프로그래머가 구조화를 위해 사고하고, CAD Tool을 사용하도록 함  5. Programming Cost 절약 - Module 단위의 프로그램 방식에서 COCOMO 기법 등을 이용해 프로그래머의 수와 생산성을 최적화 함

 

Structured Programming의 정의

표준화 형태의 제어 / 논리 구조를 사용하고, Modular 구조 하에서 GoToless 기법과 문서화를 도입하여,

Module 별/ 단계 별 Testing을 적용하는 방식