학교 CS/소프트웨어공학 (3-1학기)

CH 9 소프트웨어 구조 설계

우중충 2025. 6. 17. 02:40
반응형

CH 9 소프트웨어 구조 설계

1 설계

2 프로세스 지향 설계

3 객체 지향 설계

4 아키텍쳐 유형

CH 9 소프트웨어 구조 설계

9.1 설계

▪ 개념 및 비유

  • 설계란 고객 요구를 만족시키기 위해 구조를 계획하고 설계 도면을 만드는 것
  • 소프트웨어 설계는 건축 설계와 유사
  • 건물 설계 예시: 1층은 안내데스크, 2층은 카페처럼 층별 용도 배치 → 소프트웨어 구조 설계와 동일

▪ 소프트웨어 설계란?

  • 요구사항 명세서를 기반으로 전체 소프트웨어 구조를 정의하고 구현의 기반을 마련하는 작업
  • '무엇을'에 집중하는 요구사항 분석(What)과 달리, '어떻게'를 설명하는 How 중심 활동

▪ 비기능적 요구사항 예시

  • 성능 목표: 반응 시간, 처리량, 메모리 요구량
  • 신용도 목표: 강인성, 신뢰성, 가용성, 보안성, 안전성

비기능적 요구

▪ 상위 설계 vs 하위 설계

  • 상위 설계(High-Level Design): 시스템 구성 모듈 간 관계 (시스템 구조도, ERD 등 포함)
  • 하위 설계(Low-Level Design): 모듈 내부의 구조와 알고리즘, 자료구조 등 구체화

▪ 좋은 설계의 조건

  • 요구사항 완전 반영
  • 구현/테스트로의 추적 가능
  • 유지보수 및 변경 용이성
  • 모듈 독립성 확보, 낮은 결합도

▪ 설계 원리

  1. 추상화 (Abstraction): 중요한 정보만 강조, 세부사항 생략
  2. 단계적 분해 (Stepwise Refinement): 문제를 상위 → 하위 단계로 점차 분할
  3. 모듈화 (Modularization): 독립 실행 가능한 단위로 분리
  4. 정보 은닉 (Information Hiding): 내부 로직 감추고 인터페이스만 공개

▪ 응집도(Cohesion)

  • 모듈 내부 구성요소 간의 관련성 정도
  • 종류 (강한 응집 → 약한 응집):
    • 기능적 > 순차적 > 교환적 > 절차적 > 시간적 > 논리적 > 우연적 응집

▪ 결합도(Coupling)

  • 모듈 간 상호 의존성 정도
  • 종류 (약한 결합 → 강한 결합):
    • 자료 > 구조 > 제어 > 공통 > 내용 결합

9.2 프로세스 지향 설계

▪ 개념

  • 프로세스(기능) 중심으로 설계
  • 데이터 흐름도(DFD)를 활용

▪ 표준 기호

  • 모듈 호출: 화살표
  • 데이터 흐름: 실선
  • 제어 흐름: 점선
  • 반복/선택 등 제어 구조: 도형 표현
  •  

▪ 변환 분석 (Transformation Analysis)

  • 입력 흐름, 변환 센터, 출력 흐름으로 나누어 시스템 구조 분석

▪ 예시: 단어 개수 세기

  1. 입력: 파일 이름 입력 및 검증
  2. 변환: 단어 개수 계산
  3. 출력: 개수 출력 및 저장

▪ 처리 분석 (Transaction Analysis)

  • 하나의 프로세스에서 여러 흐름으로 분기되는 경우 분석
  • 중심 처리 센터를 기준으로 구조도 설계 후 상세화

▪ 예시: 구독자 갱신 시스템

  1. 입력 흐름: 구독자 정보, 만료일 추출
  2. 변환 센터: 만료일 계산, 갱신 여부 판단
  3. 출력 흐름: 새로운 만료일 저장 및 출력

▪ 설계 문서 예시

  1. 시스템 개요 및 목표
  2. 시스템 구조도
  3. 모듈 상세 설명 (이름, 인터페이스, 기능 등)
  4. 데이터베이스 설계
  5. 제약사항 및 참고자료

9.3 객체 지향 설계

▪ 객체의 개념

  • 객체(Object): 속성과 행위를 가지며, 고유 식별성(Identity)을 지님
    • 예: 자동차 → 속성(차체, 엔진), 행위(출발, 정지), ID(차량번호)

▪ 클래스와 객체

  • 클래스: 객체 설계도 (속성 = 변수, 행위 = 메서드)
  • 객체: 클래스의 인스턴스 (메모리상 실체)

▪ 캡슐화 (Encapsulation)

  • 내부 데이터와 연산을 하나로 묶고, 외부 접근 제한 (private/public)
  • 변경에 대한 영향을 최소화

▪ 상속 (Inheritance)

  • 상위 클래스의 속성과 기능을 하위 클래스가 물려받아 재사용
  • 예: Car → Bus extends Car (좌석 수 추가)

▪ 다형성 (Polymorphism)

  • 동일한 인터페이스를 통해 다른 구현 제공 가능
  • 예: 무기 객체 → 칼, 총이 동일한 메서드를 다르게 구현

▪ UML 다이어그램

  • 구성요소: 클래스, 속성, 메서드
  • 관계표현:
    • 일반화(상속), 실체화(인터페이스), 연관, 집합, 포함 등

9.4 아키텍처 유형

▪ 아키텍처란?

  • 시스템 전체 구조를 정의하는 설계 스타일
  • 도메인/플랫폼/애플리케이션에 따라 적합한 유형 선택 필요
  • 개발 이후 구조 수정은 매우 어려움

▪ 아키텍처 유형 목록

  1. 계층형 (Layered)
    • UI → 비즈니스 로직 → 데이터 계층으로 분리
    • 계층 간 인터페이스 제공, 유지보수 용이
     
  2. 클라이언트-서버 (Client-Server)
    • 클라이언트: UI 및 요청 전송
    • 서버: 데이터베이스 및 로직 처리
  3. 마스터-슬레이브 (Master-Slave)
    • 마스터가 슬레이브를 제어하여 작업 분담
  4. 파이프-필터 (Pipe-Filter)
    • 데이터 흐름이 연속된 필터를 거침 (스트리밍 처리)
  5. 브로커 (Broker)
    • 중간자(브로커)가 분산 컴포넌트 간 통신 중재
  6. 피어 투 피어 (P2P)
    • 모든 노드가 동등한 관계로 직접 통신
  7. 이벤트 기반 (Event Driven)
    • 이벤트 발생 → 리스너가 처리, GUI 시스템에 적합
  8. 모델-뷰-컨트롤러 (MVC)
    • 모델: 도메인 데이터, 뷰: UI, 컨트롤러: 상호작용 제어
    • 뷰/컨트롤러 변경이 모델에 영향 안 줌
  9. 블랙보드 (Blackboard)
    • 중앙 저장소(블랙보드)에 모든 컴포넌트가 읽고 씀
  10. 인터프리터 (Interpreter)
    • 명령어를 해석하며 실행, 스크립트 기반 처리
  11. 모놀리식 (Monolithic)
    • 하나의 거대한 시스템으로 모든 기능 통합
  12. 마이크로서비스 (Microservice)
    • 각 기능을 독립적인 서비스로 분리, 통신은 API 기반

 

▪ 아키텍처 선택의 이점

  • 개발 생산성 향상
  • 검증된 구조 사용
  • 명확한 커뮤니케이션 구조 제공
  • 시뮬레이션 및 유지보수 용이