구조적 방법론: 소프트웨어 개발의 체계적 접근법

구조적 방법론: 소프트웨어 개발의 체계적 접근법

• 개요
• 구조적 방법론의 기본 원리
  • 1. 추상화(Abstraction)
  • 2. 정보 은닉(Information Hiding)
  • 3. 분할과 정복(Divide and Conquer)
  • 4. 단계적 상세화(Stepwise Refinement)
  • 5. 모듈화(Modularization)
• 구조적 방법론의 개발 단계
  • 1. 요구분석(Requirement Analysis)
  • 2. 구조적 분석(Structured Analysis)
    • 주요 도구:
  • 3. 구조적 설계(Structured Design)
    • 주요 평가 지표:
  • 4. 구조적 프로그래밍(Structured Programming)
    • 주요 원칙:
• 구조적 방법론의 실제 적용 사례
  • 은행 업무 시스템 개발
• 구조적 방법론의 장단점
  • 장점
  • 단점
• 현대 개발 방법론과의 비교
• 결론
• Keywords

개요

구조적 방법론은 1970년대 등장한 소프트웨어 개발 방법론으로, 복잡한 시스템을 체계적으로 분석하고 설계하기 위한 접근법. 복잡한 문제를 단순화하고 표준화된 방식으로 개발 프로세스를 관리하는데 중점. 하향식(Top-down) 접근 방식을 통해 문제를 분해하고 단계적으로 해결책을 구체화하는 특징이 있음.

구조적 방법론의 기본 원리

1. 추상화(Abstraction)

• 문제의 본질적인 특성만 추출하여 복잡성 감소
• 불필요한 세부사항은 제거하고 핵심 요소만 집중
• 예시: 은행 시스템에서 계좌 관리 시 계좌번호, 잔액 등 필수 정보만 모델링

2. 정보 은닉(Information Hiding)

• 모듈 내부 동작 방식과 데이터를 외부로부터 감춤
• 모듈 간 인터페이스를 통해서만 상호작용 허용
• 시스템 변경 시 영향 범위 최소화
• 예시: 인증 모듈의 암호화 알고리즘 변경 시 다른 모듈에 영향 없음

3. 분할과 정복(Divide and Conquer)

• 큰 문제를 작고 관리 가능한 하위 문제로 분할
• 각 하위 문제를 독립적으로 해결 후 통합
• 복잡성 관리와 팀 작업 분담에 효과적
• 예시: 급여 시스템을 직원정보관리, 급여계산, 세금처리 등 하위 모듈로 분할

4. 단계적 상세화(Stepwise Refinement)

• 상위 수준의 추상적 설계에서 점진적으로 상세화
• 각 단계마다 더 구체적인 세부사항 추가
• 예시: 주문처리 → 주문입력 → 주문검증 → 재고확인 → 결제처리 등으로 상세화

5. 모듈화(Modularization)

• 시스템을 기능적으로 독립된 모듈 단위로 분할
• 각 모듈은 단일 기능에 집중, 독립적 개발/테스트 가능
• 재사용성과 유지보수성 향상
• 예시: 회원관리, 상품관리, 결제처리, 배송관리 등 기능별 모듈 구성

구조적 방법론의 개발 단계

1. 요구분석(Requirement Analysis)

• 사용자 요구사항 수집, 분석, 문서화
• 시스템의 목표와 범위 정의
• 주요 산출물: 요구사항 명세서, 타당성 분석 보고서
• 기법: 인터뷰, 설문조사, 관찰, 문서 검토 등
• 예시: "시스템은 분당 최소 100건의 주문을 처리할 수 있어야 함"

2. 구조적 분석(Structured Analysis)

• 요구사항을 기능적 모델로 변환
• 시스템의 기능적 요소와 데이터 흐름 식별

주요 도구:

1. 데이터 흐름도(DFD, Data Flow Diagram)
   • 시스템 내 데이터의 이동, 처리, 저장을 그래픽으로 표현
   • 구성요소: 프로세스(원), 데이터 흐름(화살표), 데이터 저장소(평행선), 외부 개체(사각형)

graph TD
    A[고객] -->|주문정보| B((주문처리))
    B -->|주문데이터| C[주문DB]
    B -->|재고확인요청| D((재고관리))
    D -->|재고정보| B
    D -->|재고데이터| E[재고DB]
    B -->|주문확인| A
    B -->|출고요청| F((출고처리))

2. 데이터 사전(DD, Data Dictionary)

   • 시스템에서 사용되는 모든 데이터 요소의 정의와 특성 문서화
   • 데이터 항목, 구조, 흐름, 저장소에 대한 상세 정보 제공
   • 예시:

     주문정보 = 주문번호 + 고객ID + 주문일자 + {주문상품} + 결제정보
     주문상품 = 상품코드 + 수량 + 단가
     결제정보 = 결제방법 + 결제금액 + [카드정보]
     카드정보 = 카드사 + 카드번호 + 만료일

3. 미니명세서(Mini Specification)

   • DFD의 각 프로세스에 대한 상세 로직 기술
   • 구조적 영어, 의사코드, 결정 테이블 등 사용
   • 예시:

     프로세스: 주문유효성검증
     1. 고객ID 존재여부 확인
     2. 각 주문상품의 재고 확인
     3. IF (모든 재고 충분) THEN
          주문상태 = "승인"
        ELSE
          주문상태 = "재고부족"
          부족상품 목록 생성
        ENDIF
     4. 주문결과 반환

3. 구조적 설계(Structured Design)

• 분석 모델을 소프트웨어 아키텍처로 변환
• 시스템 구성 요소와 상호작용 정의
• 모듈 설계 및 인터페이스 명세

주요 평가 지표:

1. 모듈 응집도(Cohesion)

   • 모듈 내부 요소들의 관련성 정도
   • 높은 응집도가 바람직(기능적 응집도가 최상)
   • 응집도 유형(낮음→높음):
     • 우연적 응집도: 서로 관련 없는 기능들이 한 모듈에 존재
     • 논리적 응집도: 논리적으로 유사한 기능들을 그룹화
     • 시간적 응집도: 동시에 실행되는 기능들의 그룹화
     • 절차적 응집도: 순차적으로 실행되는 기능들의 그룹화
     • 통신적 응집도: 동일한 데이터를 사용하는 기능들의 그룹화
     • 순차적 응집도: 한 기능의 출력이 다른 기능의 입력이 되는 경우
     • 기능적 응집도: 단일 목적을 위한 모든 요소가 결합된 경우

2. 모듈 결합도(Coupling)

   • 모듈 간 상호의존성 정도
   • 낮은 결합도가 바람직(데이터 결합도가 최상)
   • 결합도 유형(높음→낮음):
     • 내용 결합도: 한 모듈이 다른 모듈의 내부 동작에 직접 의존
     • 공통 결합도: 전역 데이터를 공유하는 모듈 간 결합
     • 제어 결합도: 한 모듈이 다른 모듈의 내부 논리를 제어
     • 스탬프 결합도: 모듈 간에 데이터 구조를 전달
     • 데이터 결합도: 모듈 간에 필요한 데이터만 매개변수로 전달

graph TD
    subgraph "고결합 예시"
        A1[모듈A] -->|내부변수 직접접근| B1[모듈B]
    end

    subgraph "저결합 예시"
        A2[모듈A] -->|인터페이스 통한 데이터 전달| B2[모듈B]
    end

4. 구조적 프로그래밍(Structured Programming)

• 구조화된 코드 작성을 위한 프로그래밍 패러다임
• 순차, 선택, 반복 구조만을 사용
• goto 문장 사용 지양

주요 원칙:

1. 단일 입출구 원칙

   • 모든 함수와 루틴은 하나의 진입점과 하나의 종료점만 가짐
   • 가독성과 디버깅 용이성 증가

2. 세 가지 제어 구조만 사용

   • 순차(Sequence): 명령어를 순차적으로 실행
   • 선택(Selection): if-then-else, switch-case 구문
   • 반복(Iteration): for, while, do-while 루프

3. 모듈 크기 제한

   • 한 화면(약 50줄)에 표시 가능한 크기로 모듈 제한
   • 가독성과 이해도 향상

graph TD
    A[시작] --> B{조건 검사}
    B -->|참| C[작업 A 수행]
    B -->|거짓| D[작업 B 수행]
    C --> E[종료]
    D --> E

구조적 방법론의 실제 적용 사례

은행 업무 시스템 개발

• 요구분석: 계좌관리, 입출금 처리, 대출관리 등 기능 정의
• 구조적 분석:
  • DFD로 고객-창구직원-시스템 간 데이터 흐름 모델링
  • 데이터 사전에서 계좌정보, 거래내역 등 데이터 구조 정의
• 구조적 설계:
  • 계좌관리, 거래처리, 보고서생성 등 모듈 구성
  • 높은 응집도(각 모듈은 단일 기능에 집중)와 낮은 결합도(표준화된 인터페이스로 통신) 설계
• 구조적 프로그래밍:
  • 입출금 처리 시 거래 유효성 검증→잔액 확인→트랜잭션 처리→결과 반환 등 순차적 흐름 구현

구조적 방법론의 장단점

장점

• 복잡한 문제를 체계적으로 분해하여 관리 가능
• 표준화된 문서와 도구로 의사소통 용이
• 유지보수성과 재사용성 향상
• 하향식 접근법으로 초기 시스템 구조 명확화
• 팀 작업 분담과 협업 지원

단점

• 변화에 대한 유연성 부족
• 사용자 참여가 초기에만 집중됨
• 객체지향 개념 미반영
• 대규모 시스템에서 문서 작업 과다
• 반복적인 개발과 프로토타이핑 지원 미흡

현대 개발 방법론과의 비교

구조적 방법론은 객체지향 방법론, 애자일 방법론 등 현대적 방법론의 기초가 됨:

timeline
    title 소프트웨어 개발 방법론의 진화
    1970s : 구조적 방법론
          : 하향식 접근법
          : 기능 중심 분해
    1980-90s : 객체지향 방법론
              : 데이터와 기능 캡슐화
              : UML 등장
    2000s : 애자일 방법론
           : 반복적, 점진적 개발
           : 고객 참여 강화
    2010s+ : DevOps
            : 지속적 통합/배포
            : 마이크로서비스 아키텍처

결론

구조적 방법론은 소프트웨어 개발을 체계화하고 표준화하는데 크게 기여한 방법론. 추상화, 정보은닉, 분할정복 등의 기본 원칙은 현대 소프트웨어 공학에서도 여전히 중요한 개념으로 활용됨. 비록 객체지향이나 애자일 등 새로운 방법론이 등장했지만, 구조적 방법론의 핵심 원리는 이들의 기초가 되었으며, 특히 명확한 요구사항과 체계적인 접근이 필요한 분야에서는 여전히 유용한 방법론으로 자리잡고 있음.

Keywords

소프트웨어 공학, 구조적 방법론, DFD, 응집도, 결합도, 모듈화, 추상화, 하향식 설계, 정보은닉, 분할정복