구조적 분석
1. 개요
구조적 분석은 1960년대에서 1980년대 사이 소프트웨어 개발의 복잡성 증가와 개발 프로세스의 비효율성에 대응하기 위해 개발된 일련의 기법이다. 구조적 프로그래밍, 구조적 설계, 구조적 시스템 분석 등을 포함하며, 다이어그램과 데이터 사전을 활용하여 시스템을 분석하고 설계하는 데 사용되었다. 데이터 흐름도, 구조 차트 등의 도구를 통해 시스템을 시각적으로 표현하고, 기능 분해 방식을 통해 시스템을 계층적으로 분해하여 이해를 돕는다. 하지만, 객체 지향 프로그래밍과 같은 새로운 개발 패러다임의 등장으로 활용도가 감소하였으며, 데이터 흐름도의 복잡성과 변경에 대한 취약성 등의 한계점을 가지고 있다.
| 명칭 | 구조적 분석 및 설계 |
|---|---|
| 영어 명칭 | structured analysis and design (SAD) |
| 정의 | 시스템을 분석하고 소프트웨어 및 하드웨어 구성 요소를 설계하기 위한 방법론 |
| 개발 시기 | 1970년대 |
|---|---|
| 개발자 | 래리 콘스탄틴 (Larry Constantine) 및 에드워드 요던 (Edward Yourdon) |
| 발전 | 톰 드마르코 (Tom DeMarco), 켄 오어 (Ken Orr), 스티븐 맥메나민 (Stephen McMenamin), 존 팔머 (John Palmer) |
| 방법론 | 자료 흐름도(DFD), 자료 사전(DD), 구조도, 의사 코드, 상태 전환 다이어그램 등의 도구 사용 |
| 목표 | 문제를 이해하고 해결책을 제시 요구 사항을 체계적으로 분석하고 명세화 |
|---|---|
| 특징 | 하향식 접근 방식 사용 모듈화 및 분할 통치 전략 적용 그래픽 모델링 도구 활용 |
| 장점 | 시스템의 복잡성을 줄임 이해하기 쉬운 시각적 표현 제공 유지 보수 용이 |
| 단점 | 변화하는 요구 사항에 대한 적응성 부족 객체 지향 프로그래밍에 대한 지원 미흡 |
| 자료 흐름도 (Data Flow Diagram, DFD) | 시스템 내 데이터 흐름을 그래픽으로 표현 |
|---|---|
| 자료 사전 (Data Dictionary, DD) | 데이터 요소의 정의, 속성, 관계 등을 기술 |
| 구조도 (Structure Chart) | 프로그램 모듈 간의 계층적 관계를 표현 |
| 의사 코드 (Pseudocode) | 프로그램 로직을 자연어와 유사하게 표현 |
| 상태 전환 다이어그램 (State Transition Diagram) | 객체의 상태 변화를 표현 |
| 소프트웨어 개발 | 시스템 분석 및 설계 단계에서 활용 |
|---|---|
| 정보 시스템 구축 | 업무 프로세스 모델링 및 시스템 요구 사항 정의 |
| 시스템 통합 (System Integration, SI) | 기존 시스템 분석 및 새로운 시스템 설계 |
| 구조적 프로그래밍 | 순차, 선택, 반복 구조를 사용하여 프로그램 작성 |
|---|---|
| 객체 지향 분석 및 설계 (Object-Oriented Analysis and Design, OOAD) | 객체, 클래스, 상속 등의 개념을 사용하여 시스템 모델링 |
| UML (Unified Modeling Language) | 객체 지향 시스템 모델링을 위한 표준 표기법 |
| 유연성 부족 | 변화하는 요구 사항에 대한 적응이 어려움 |
|---|---|
| 객체 지향 개념 미반영 | 현대적인 소프트웨어 개발 방법론과의 통합이 어려움 |
| 문서 중심 | 과도한 문서 작업으로 인해 개발 속도가 느려질 수 있음 |
-
소프트웨어 설계 -
지속적 배포
지속적 배포(CD)는 소프트웨어 릴리스 프로세스를 자동화하는 접근 방식이며, 배포 파이프라인을 통해 구현되고 시장 출시 시간 단축, 제품 품질 향상 등의 이점을 제공하지만 테스트 자동화 부족 등의 과제도 존재한다. -
소프트웨어 설계 -
도메인 주도 설계
도메인 주도 설계는 소프트웨어 개발에서 문제 해결 영역인 도메인의 중요성을 강조하며, 도메인 전문가와 개발자의 협력을 통해 도메인 모델을 구축하여 소프트웨어의 복잡성 관리와 일관성 유지를 목표로 하는 방법론이다. -
에츠허르 데이크스트라 -
교착 상태
교착 상태는 둘 이상의 프로세스가 자원을 점유하고 서로의 자원을 요청하여 더 이상 진행할 수 없는 상태를 의미하며, 상호 배제, 점유 대기, 비선점, 순환 대기 네 가지 조건이 모두 충족되어야 발생하고, 운영 체제는 이를 예방, 회피, 무시, 발견하는 방법으로 관리한다. -
에츠허르 데이크스트라 -
세마포어
세마포어는 데이크스트라가 고안한 정수 변수로, P/V 연산을 통해 자원 접근을 제어하고 동기화 문제를 해결하며, 계수 세마포어와 이진 세마포어로 나뉘어 멀티스레드 환경에서 자원 관리 및 스레드 동기화에 기여한다.
2. 역사
구조적 분석은 1960년대와 1980년대 사이에 소프트웨어 개발 분야에서 나타난 주요 문제점, 즉 대규모 시스템의 복잡성 증가와 비효율적인 개발 프로세스에 대한 해결책으로 개발되었다. 이 시기에는 코볼, 포트란, C, 베이직과 같은 프로그래밍 언어가 주로 사용되었으며, 체계적인 설계 및 프로그래밍 기법, 표준화된 문서화 방법이 부족하여 소프트웨어 개발이 더욱 어려웠다.
2.1. 구조적 분석의 등장 배경
1960년대 말부터 소프트웨어 개발의 복잡성을 관리하고 효율성을 높이기 위해 다양한 구조적 방법론들이 등장했다.
이 시기 대부분의 상용 프로그래밍은 코볼과 포트란, 이후 C, 베이직으로 완성되었다. 당시에는 "훌륭한" 설계 및 프로그래밍 기법에 대한 지침이 거의 없었고, 요구사항과 디자인을 문서화하기 위한 표준 기법들도 없었다. 시스템은 규모가 커지고 더 복잡해져갔으며 정보 시스템 개발은 더욱더 어려워져만 갔다.
1960년대 말부터 대규모의 복잡한 소프트웨어를 관리하는 데 도움이 되기 위해 다음과 같은 구조적 방법들이 등장했다.
| 연도 | 기법 | 개발자 |
|---|---|---|
| 1967년경 | 구조적 프로그래밍 | 에츠허르 데이크스트라 |
| 1971년 | 단계별 설계 | 니클라우스 비르트 |
| 1972년 | 나시-슈나이더만 다이어그램 | |
| 1974년 | 워니어/오어 다이어그램 | |
| 1974년 | HIPO | |
| 1975년경 | 구조적 설계 | 래리 콘스탄틴, 에드워드 유돈, 웨인 스티븐스 |
| 1975년경 | 잭슨 구조적 프로그래밍 | 마이클 A. 잭슨 |
| 1978년경 | 구조적 분석 | 톰 데마르코, 에드워드 유돈, Gane & Sarson, McMenamin & Palmer |
| 구조적 분석 및 설계 기법(SADT) | 더글러스 T. 로스 | |
| 유돈 구조적 방법 | 에드워드 유돈 | |
| 1978년 | 구조적 분석 및 시스템 명세 | 톰 데마르코 |
| 1983년 | 구조적 시스템 분석 및 설계 방법(SSADM) | 영국 정부 정부 상업 사무소 |
| 필수 시스템 분석 | 스티븐 M. 맥메너민과 존 F. 팔머 | |
| 1985년 | IDEF0 | 더글러스 T. 로스 |
| 1988년 | Hatley-Pirbhai 모델링 | 데릭 J. 해틀리와 임티아즈 A. 피르바이 |
| 1989년 | 현대적 구조 분석 | 에드워드 유돈 |
| 1990년경 | 정보 기술 엔지니어링 | 핀켈스타인, 제임스 마틴 |
정보 공학은 1970년대에 개발된 구조적 기법의 논리적 확장이다. 구조적 프로그래밍은 구조적 설계로 이어졌고, 이는 다시 구조적 시스템 분석으로 이어졌다. 이러한 기법은 다이어그램 사용이 특징이었다. 구조적 설계를 위한 구조 차트와 구조적 분석을 위한 데이터 흐름도가 사용자 및 개발자 간의 의사 소통을 돕고 분석가 및 설계자의 규율을 향상시키는 데 사용되었다. 1980년대에는 다이어그램 그리기를 자동화하고 그려진 항목을 데이터 사전에 추적하는 도구들이 나타나기 시작했다. 컴퓨터 지원 설계 및 컴퓨터 지원 제조(CAD/CAM)의 예를 따라, 이러한 도구 사용은 컴퓨터 지원 소프트웨어 공학(CASE)으로 명명되었다.
2.2. 구조적 분석의 발전과 영향
구조적 분석은 1960년대부터 1980년대까지 소프트웨어 개발의 어려움을 해결하기 위해 등장한 여러 구조적 방법 중 하나이다. 톰 데마르코, 에드워드 유돈 등이 1978년경 구조적 분석을 개발하였다. 구조적 분석은 다이어그램을 사용하여 시스템의 구조와 데이터 흐름을 시각적으로 표현함으로써, 사용자와 개발자 간의 의사소통을 원활하게 하고 분석 및 설계 과정의 효율성을 높였다.
1980년대에는 컴퓨터 지원 소프트웨어 공학(CASE) 도구들이 등장하여 다이어그램 작성을 자동화하고, 데이터 사전에 정보를 추적하는 기능을 제공했다. 이는 정보 공학 발전에 영향을 주었다.
3. 구조적 분석의 주요 개념 및 도구
구조적 분석은 시스템을 데이터와 프로세스 중심으로 파악하며, 복잡한 시스템을 계층적으로 분해하여 이해하기 쉬운 형태로 표현한다. 1980년대에 널리 사용되었으며, 자료 흐름도를 통해 시스템의 개념을 데이터 및 제어 용어로 해석한다.
구조적 분석은 시스템을 데이터 흐름의 관점에서 바라보며, 데이터 흐름을 변환하는 프로세스로 시스템의 기능을 설명한다. 연속적인 분해(또는 하향식) 분석을 통해 정보 은닉을 활용하여 관련 세부 사항에 집중하고 관련 없는 세부 사항은 보지 않음으로써 혼란을 피한다.
톰 드마코, 켄 오어, 래리 콘스탄틴, 본 프릭, 에드 요돈, 스티븐 워드, 피터 첸 등은 구조 차트, 자료 흐름도, 데이터 모델 다이어그램을 사용하여 구조적 분석 및 구조적 설계를 표현하는 다양한 방법을 개발했다.
--
3.1. 단일 추상화 메커니즘
구조적 분석은 단일 추상화 메커니즘을 사용하여 계층 구조를 만든다. 구조적 분석 방법은 IDEF를 사용할 수 있으며, 프로세스 중심적이며 목적과 관점을 가지고 시작한다. 이 방법은 전체 기능을 식별하고, 입출력, 제어, 프로세스 최적화에 필요한 메커니즘을 유지하면서 기능을 더 작은 기능으로 반복적으로 나눈다. 이는 기능 분해 접근 방식이라고도 하며, 구조화된 데이터를 생성하는 기능 내의 응집력과 기능 간의 결합에 중점을 둔다.
구조적 방법의 기능 분해는 시스템 동작을 상세히 설명하지 않고 프로세스를 설명하며, 필요한 기능 형태로 시스템 구조를 지시한다. 이 방법은 활동과 관련된 입출력을 식별한다.
3.2. 구조적 분석의 접근 방식
구조적 분석은 시스템을 데이터 흐름의 관점에서 바라보며, 시스템의 기능을 데이터를 변환하는 프로세스로 설명한다. 정보 은닉을 위해 하향식 분해 방식을 사용하며, 주요 도구는 다음과 같다.
--
* [[컨텍스트 다이어그램]]: 시스템과 외부 개체 간의 상호 작용을 나타내는 최상위 수준의 다이어그램이다.
* [[데이터 흐름도]] (DFD): 정보 시스템을 통한 데이터의 "흐름"을 그래픽으로 표현한 것이다. 시스템의 기능을 더 작은 부분으로 나누고 데이터 흐름을 강조한다.
* 프로세스 사양: 기능적 기본 요소를 설명하며, 의사 코드, 순서도 또는 구조적 영어로 구성될 수 있다.
* [[데이터 사전]]: 데이터베이스의 기본 구성을 정의하는 파일로, 데이터베이스 관리를 위한 정보를 담고 있다.
드 마르코(De Marco)의 접근 방식은 위의 객체들을 이용하여 시스템을 분석한다. 데이터 흐름도는 방향성 그래프로, 화살표는 데이터를, 노드(원 또는 버블)는 데이터를 변환하는 프로세스를 나타낸다. 프로세스는 하위 프로세스로 더 자세히 분해될 수 있으며, 기능적 기본 요소는 프로세스 사양으로 설명된다. 데이터 사전은 데이터 흐름, 데이터 요소, 파일 및 데이터베이스의 항목을 정의하며, 하향식으로 분할된다.
4. 구조적 분석의 활용 및 한계
구조적 분석은 시스템을 데이터 흐름의 관점에서 바라보며, 정보 은닉을 활용하여 시스템의 기능과 데이터를 명확하게 표현한다. 하지만 몇 가지 한계점도 존재한다.
한계:
* 데이터 흐름도 관련 문제점:
* 적절한 버블(프로세스)을 선택하고, 의미 있는 방식으로 분할하는 것이 어려울 수 있다.
* 데이터 흐름을 이해하기 위해 많은 양의 문서가 필요할 수 있다.
* 데이터 흐름도는 본질적으로 기능적인 관점에 치중하여, 잦은 변경에 취약하고 시스템의 데이터 모델링을 충분히 반영하지 못한다.
* 고객이 데이터 흐름과 버블의 개념을 이해하고 실제 시스템과 연결 짓는 데 어려움을 겪을 수 있다.
* 설계자는 데이터 흐름도 구성을 실제 구현 가능한 형태로 변환해야 하는 추가적인 작업이 필요하다.
* 구조 차트는 구성 시스템을 관리하기 쉬운 수준까지 세분화하여 보여주는 차트이다.
* 구조적 프로그래밍에서 프로그램 모듈을 트리 구조로 정렬하는 데 사용되며, 각 모듈은 상자로 표시된다. 트리 구조는 모듈 간 관계를 시각화한다.
* 컴퓨터 프로그램의 고수준 설계 또는 아키텍처를 지정하는 데 사용되며, 프로그래머가 큰 소프트웨어 문제를 작은 부분으로 분해하는 것을 돕는다. (하향식 설계 또는 기능 분해)
4.1. 구조적 분석의 활용
구조적 분석은 1980년대에 널리 사용되었으며 오늘날에도 여전히 사용되고 있다. 시스템 개념을 자료 흐름도로 표현하며, 데이터 및 제어 흐름을 추적한다. 복잡성을 줄이기 위해 버블을 그룹화하고, 자료 사전을 통해 데이터 및 명령 흐름을 설명한다.
구조 차트, 자료 흐름도, 데이터 모델 다이어그램 등이 구조적 분석 및 설계에 사용되며, 톰 드마코, 켄 오어, 래리 콘스탄틴 등 다양한 사람들이 개발했다. 이러한 기술은 구조적 시스템 분석 및 설계 방법 등 다양한 소프트웨어 개발 방법론에 결합되었다.
--
구조적 분석은 단일 추상화 메커니즘을 사용하여 계층 구조를 만든다. IDEF를 사용할 수 있으며, 기능 분해 접근 방식을 통해 기능을 더 작은 기능으로 나눈다. 이는 고수준 프로세스와 개념을 직관적으로 전달할 수 있다는 장점이 있지만, 객체 지향 개발에서는 객체가 기능을 어떻게 지원하는지 파악하기 어렵다. UML은 서비스 지향 아키텍처(SOA)를 설명하는 데 유용하다.
구조적 분석은 시스템을 데이터 흐름의 관점에서 바라보며, 정보 은닉을 활용한다. 그 결과 관련 그래픽 다이어그램, 프로세스 설명, 데이터 정의 집합이 생성된다.
thumb
드 마르코(De Marco)의 접근 방식은 컨텍스트 다이어그램, 데이터 흐름도, 프로세스 사양, 데이터 사전으로 구성된다. 데이터 흐름도(DFD)는 방향성 그래프이며, 프로세스는 더 자세한 DFD로 분해될 수 있다. 기능적 기본 요소는 프로세스 사양으로 설명되며, DFD는 기능적 기본 요소로 구성된 상호 연결된 프로세스 네트워크로 시스템 구조를 모델링한다. 데이터 사전은 데이터 흐름, 데이터 요소, 파일 및 데이터베이스의 항목 집합이다.
4.2. 구조적 분석의 한계
구조 차트는 구성 시스템을 가장 관리하기 쉬운 수준까지 세분화하여 보여주는 차트이다. 이 차트는 구조적 프로그래밍에서 프로그램 모듈을 트리 구조로 정렬하는 데 사용된다. 각 모듈은 모듈의 이름이 포함된 상자로 표시된다. 트리 구조는 모듈 간의 관계를 시각화한다.
구조 차트는 구조적 분석에서 컴퓨터 프로그램의 고수준 설계 또는 아키텍처를 지정하는 데 사용된다. 설계 도구로서, 프로그래머가 큰 소프트웨어 문제를 분할하고 정복하는 데 도움을 준다. 즉, 문제를 인간의 두뇌가 이해할 수 있을 정도로 작은 부분으로 재귀적으로 분해한다. 이 프로세스를 하향식 설계 또는 기능 분해라고 한다. 프로그래머는 건축가가 집을 짓기 위해 청사진을 사용하는 것과 유사한 방식으로 구조 차트를 사용하여 프로그램을 구축한다. 설계 단계에서 차트는 클라이언트와 다양한 소프트웨어 설계자가 소통하는 방식으로 그려지고 사용된다. 프로그램의 실제 구축(구현) 동안, 차트는 마스터 플랜으로 지속적으로 참조된다.
데이터 흐름도 관련 문제점은 다음과 같다.
* 적절한 버블 선택
* 의미 있고 상호 합의된 방식으로 버블 분할
* 데이터 흐름을 이해하는 데 필요한 문서의 크기
* 데이터 흐름도는 본질적으로 기능적이며, 빈번한 변경에 취약함
* "데이터" 흐름이 강조되지만, "데이터" 모델링은 그렇지 않으므로 시스템의 주제에 대한 이해가 부족함
* 고객은 개념이 데이터 흐름과 버블에 어떻게 매핑되는지 따라가는 데 어려움을 겪음
* 설계자는 DFD 구성을 구현 가능한 형식으로 전환해야 함
5. 현대적 관점에서의 구조적 분석
객체 지향 프로그래밍, 서비스 지향 아키텍처(SOA) 등 새로운 소프트웨어 개발 패러다임이 등장하면서 구조적 분석의 활용은 과거에 비해 감소하였다. 그러나 구조적 분석의 기본 원리와 개념은 여전히 유효하며, 특정 분야에서는 여전히 활용되고 있다. 대한민국에서는 1990년대 이후 정보화 사업이 본격화되면서 구조적 분석 방법론이 널리 도입되었으나, 2000년대 이후 객체 지향 기술의 확산과 함께 그 활용도가 점차 감소하였다.
Hay (1999)에 따르면 "정보 공학은 1970년대에 개발된 구조적 기법의 논리적 확장이다. 구조적 프로그래밍은 구조적 설계로 이어졌고, 이는 다시 구조적 시스템 분석으로 이어졌다. 이러한 기법은 다이어그램의 사용이 특징이었다. 즉, 구조적 설계를 위한 구조 차트와 구조적 분석을 위한 데이터 흐름도가 사용자 및 개발자 간의 의사 소통을 돕고 분석가 및 설계자의 규율을 향상시키는 데 사용되었다. 1980년대에는 다이어그램 그리기를 자동화하고 그려진 항목을 데이터 사전에 추적하는 도구들이 나타나기 시작했다." 컴퓨터 지원 설계 및 컴퓨터 지원 제조(CAD/CAM)의 예를 따라, 이러한 도구의 사용은 컴퓨터 지원 소프트웨어 공학(CASE)으로 명명되었다.
6. 결론
구조적 분석은 1960년대부터 1980년대까지 소프트웨어 업계의 문제에 대응하여 개발된 분석, 설계, 프로그래밍 기법이다. 이 시기에는 코볼(COBOL)과 포트란(FORTRAN)이 주로 사용되었고, 이후 C와 베이직(BASIC)이 사용되었다. 당시에는 설계 및 프로그래밍 기법에 대한 지침이나 표준 기술이 거의 없었기 때문에, 시스템이 복잡해짐에 따라 정보 시스템 개발이 점점 더 어려워졌다.
1960년대 말부터 대규모 소프트웨어를 관리하기 위해 다양한 구조적 방법들이 등장했다. 주요 방법들은 다음과 같다.
| 기법 | 개발 연도 | 주요 개발자 |
|---|---|---|
| 구조적 프로그래밍 | 1967년경 | 에츠허르 데이크스트라 |
| 단계별 설계 | 1971년 | 니클라우스 비르트 |
| 나시-슈나이더만 다이어그램 | 1972년 | |
| 워니어/오어 다이어그램 | 1974년 | |
| HIPO | 1974년 | IBM |
| 구조적 설계 | 1975년경 | 래리 콘스탄틴, 에드워드 유돈, 웨인 스티븐스 |
| 잭슨 구조적 프로그래밍 | 1975년경 | 마이클 A. 잭슨 |
| 구조적 분석 | 1978년경 | 톰 데마르코, 에드워드 유돈 등 |
| 구조적 분석 및 설계 기법(SADT) | 더글러스 T. 로스 | |
| 유돈 구조적 방법 | 에드워드 유돈 | |
| 구조적 분석 및 시스템 명세 | 1978년 | 톰 데마르코 |
| 구조적 시스템 분석 및 설계 방법(SSADM) | 1983년 | 영국 정부 상업 사무소 |
| 필수 시스템 분석 | 스티븐 M. 맥메너민과 존 F. 팔머 | |
| IDEF0 | 1985년 | 더글러스 T. 로스 |
| Hatley-Pirbhai 모델링 | 1988년 | 데릭 J. 해틀리와 임티아즈 A. 피르바이 |
| 현대적 구조 분석 | 1989년 | 에드워드 유돈 |
| 정보 기술 엔지니어링 | 1990년경 | 핀켈스타인, 제임스 마틴 |
1980년대에는 다이어그램 작성을 자동화하고 데이터 사전에 추적하는 컴퓨터 지원 소프트웨어 공학(CASE) 도구들이 등장했다. 구조적 분석은 자료 흐름도를 사용하여 시스템을 표현하며, 자료 사전은 데이터 및 명령 흐름을 설명하는 데 사용된다. 구조 차트, 자료 흐름도, 데이터 모델 다이어그램 등이 구조적 분석 및 설계에 사용되었다.