소프트웨어 설계 - 요구사항 확인

정보처리기사
공개

2026년 1월 10일

소프트웨어 생명(수명) 주기

  1. 요구사항 분석:
    • 기능 요구사항: 사용자가 시스템을 통해 제공받기 원하는 기능
    • 비기능 요구사항: 품질, 제약사항 등
    • 워크스루(비공식), 인스펙션(공식) 등을 통해 검토
  2. 설계
  3. 구현
  4. 테스트
  5. 유지보수

대표적 모형

  1. 폭포수 모형
  2. 프로토타입(원형) 모형
  3. 나선형(점진적) 모형
    • 위험 관리에 중점을 둔 모형
    • 각 단계마다 계획, 위험 분석, 개발, 고객 평가의 활동을 반복

개발 방법론

  1. 구조적 방법론: 하향식, 기능 중심, 나씨 - 슈나이더만 차트 사용

  2. 정보공학 방법론: 데이터 중심

  3. 객체지향 방법론: 객체 중심

    • 객체지향 분석 방법:
      • OOSE(Object Oriented Software Engineering): 야콥슨, 유스케이스 중심
      • OMT(Object Modeling Technology): 럼바우, 객체(객체 다이어그램), 동적(상태 다이어그램), 기능 모델링(자료 흐름도) 중심
      • OOD(Object Oriented Design): 부치, 설계 관점 강조
    • 설계 원칙(SOLID):
      • 단일 책임 원칙(SRP): 클래스는 하나의 책임만 가져야 한다.
      • 개방-폐쇄 원칙(OCP): 기존 코드를 변경하지 않고 기능을 확장할 수 있어야 한다.
      • 리스코프 치환 원칙(LSP): 자식 클래스는 부모 클래스로 치환될 수 있어야 한다.
      • 인터페이스 분리 원칙(ISP): 자신이 사용하지 않는 인터페이스를 구현해서 클라이언트가 영향을 받아서는 안된다.
      • 의존관계 역전 원칙(DIP): 하위 모듈이 상위 모듈에 의존하면 안된다.

  4. 컴포넌트 기반 방법론: 컴포넌트 중심

  5. 애자일 모형: 사람 중심

    • 스크럼
    • XP
      • 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중
      • 12가지 기본원리:
        1. pair programming
        2. 공동코드 소유
        3. 지속적인 통합(CI)
        4. 계획 세우기
        5. 작은 릴리즈
        6. 메타포어: 공통적인 이름 체계 사용해라
        7. 간단한 디자인
        8. 테스트 주도 개발(TDD)
        9. 리팩토링
        10. 주 40시간 이내 작업
        11. 고객 상주
        12. 코드 표준(convention)
    • 린: 칸반보드 사용

  6. 제품 계열 방법론: 임베디드 소프트웨어를 작성하는데 유용

프로젝트 관리

비용 산정

  1. LoC(Line of Code) 산정법: (낙관치 + 4 * 중간치 + 비관치) / 6
  2. Man Month 모형:
    • Man Month = LoC / (프로그래머 월간 생산성)
    • 프로젝트 기간 = Man Month / 프로젝트 인력
  3. COCOMO(COnstructive COst MOdel) 모형: 프로젝트 규모에 따라 비용 산정
    • 조직형: 소규모. 5만 라인 이하
    • 반 분리형: 트랜잭션 처리 시스템, 데이터베이스 관리 시스템, 컴파일러 등 30만 라인 이하 소프트웨어
    • 임베디드 형: 30만 라인 이상의 대규모 시스템
  4. Putnam 모형: 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정. Rayleigh Norden 곡선 사용
  5. Function Point(FP) 모형: 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 합산하여 비용 산정

소프트웨어 아키텍처

아키텍처 비용 평가 모델

  • SAAM(Software Architecture Analysis Method)
  • ATAM(Architecture Tradeoff Analysis Method): 아키텍처 품질 속성간 트레이드오프 분석
  • CBAM(Cost Benefit Analysis Method): ATAM을 기반으로 비용과 이익을 분석
  • ADR(Active Design Review)
  • ARID(Active Reviews for Intermediate Designs)

디자인 패턴

  1. 생성 패턴
    • builder: 생성 과정과 표현 방법을 분리
    # 생성 과정 (Director) - 순서만 담당, 재료는 모름

class 건축감독:
    build(빌더):
        빌더.기초()
        빌더.벽()
        빌더.지붕()
        빌더.문()
        return 빌더.결과()
# 표현 (Builder) - 결과물의 실제 모습 담당

감독.build(나무빌더)   → 통나무집
감독.build(벽돌빌더)   → 벽돌집
    • prototype: 원본을 clone으로 깊은 복사하여 새로운 객체 생성
    • factory method: 인스턴스 생성을 서브 클래스에 위임하는 것
    • abstract factory: factory method와 달리 여러 관련된 객체들의 집합을 생성하는 것
    • singleton: 한 클래스에 대해 한 객체만 존재하도록 제한
  2. 구조 패턴: 클래스나 객체를 조합하여 더 큰 구조를 만드는 패턴
    • Bridge: 추상(기능)과 구현을 분리하여 독립적으로 확장 (no M x N, yes M + N)
    • Decorator: 기존에 구현된 클래스에 필요한 기능을 추가해 나가는 것.
    커피 = new 에스프레소()
커피 = new 우유데코(커피)      # 우유 추가
커피 = new 시럽데코(커피)      # 시럽 추가
커피.가격()   # 에스프레소 + 우유 + 시럽 (감싼 만큼 누적)
    • Facade: 복잡한 서브시스템 앞에 단순한 통합 창구(인터페이스)를 제공
    • Flyweight: 공통 부분을 공유하여 메모리 사용량을 줄이는 패턴
    • Proxy: 특정 객체에 접근하기 전에 대리 객체를 두어 접근을 제어하는 패턴
    • Composite: 단일 객체, 여러 객체를 담은 복합 객체를 동일하게 다루는 패턴
    • Adapter
  3. 행위 패턴
    • Mediator:
    • Interpreter:
    • Iterator: 내부 구조를 노출하지 않고(array인지 list인지 몰라도 된다) 컬렉션 요소를 순차 접근할 수 있도록 하는 패턴
    • Template Method: 알고리즘의 골격(뼈대)은 상위 클래스에 정의, 세부 단계는 하위 클래스가 override
    • Observer: 한 객체의 상태가 바뀌면, 의존하는 객체들에게 자동으로 통지
    • State: 상태를 객체로 표현
    • Visitor: 원 객체는 그대로. 방문자가 원 객체를 방문하여 특정 기능을 수행
    class 원 { accept(v): v.visit(this) }
class 사각형 { accept(v): v.visit(this) }
    • Command: 요청(명령)을 객체로 캡슐화
    • Strategy: 알고리즘을 캡슐화하여 자유롭게 교체할 수 있도록 하는 패턴
    • Memento: 객체의 상태를 저장하고 복원할 수 있도록 하는 패턴
    • Chain of Responsibility: 객체를 chain으로 연결하고, 요청을 처리할 수 있는 객체가 나타날 때까지 chain을 따라 요청을 전달하는 패턴

UML(Unified Modeling Language)

  • 모두를 위한 객체지향 모델링 언어

관계

┌────────────┬────────────────┬────────────────────────┬───────────────────────────┐ │ 관계 │ 영문 │ 표기(화살표) │ 핵심 의미 │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 연관 │ Association │ 실선 ───▶ │ 서로 사용하는 지속적 관계 │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 의존 │ Dependency │ 점선 화살표 ┈┈▶ │ 잠깐 사용하는 관계 │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 일반화 │ Generalization │ 실선 + 빈 삼각형 ──▷ │ 상속 (is-a) │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 실체화 │ Realization │ 점선 + 빈 삼각형 ┈┈▷ │ 인터페이스 구현 │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 집합(집약) │ Aggregation │ 실선 + 빈 마름모 ──◇ │ 약한 전체-부분 │ ├────────────┼────────────────┼────────────────────────┼───────────────────────────┤ │ 포함(합성) │ Composition │ 실선 + 채운 마름모 ──◆ │ 강한 전체-부분 │ └────────────┴────────────────┴────────────────────────┴───────────────────────────┘

  • 집합 관계 (Aggregation, 집약)

전체-부분 관계이지만 “약한 결합” — 부분이 독립적으로 존재 가능

  • 전체가 사라져도 부분은 살아남음 동아리 ◇────── 학생

  • 예: 동아리 ◇── 학생 → 동아리가 없어져도 학생은 존재. 학생은 다른 동아리에도 소속 가능

  • 부분이 공유될 수 있음

  • 포함 관계 (Composition, 합성)

전체-부분 관계이면서 “강한 결합” — 부분이 전체에 종속 (생명주기 함께)

  • 전체가 사라지면 부분도 함께 소멸 집 ◆────── 방
  • 예: 집 ◆── 방 → 집이 철거되면 방도 사라짐. 방은 그 집에만 속함 (공유 X)

다이어그램

  • 구조적 다이어 그램: 정적 모델링
    • 클래스 다이어그램
      • class: 일반적으로 3개의 획으로 나눠 클래스 이름, 속성, 오퍼레이션을 표기함
      • 제약 조건: 입력될 값에 대한 조건, 오퍼레이션(함수) 전후에 지정해야 할 조건
      • 관계: 연관, 포함, 집합, 일반화, 의존
    • 객체 다이어그램: 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
    • 컴포넌트 다이어그램: 구현 단계에서 실제 컴포넌트 간의 관계나 인터페이스 표현
    • 배치(deployment) 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
    • 패키지 다이어그램: 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현
  • 행동 다이어그램: 동적 모델링
    • 유스케이스 다이어그램: 사용자, 사용 사례로 구성. 사용 사례 간 여러 관계 표현
      • 시스템: 시스템 내부에서 수행되는 기능들을 사각형으로 묶어 표현
      • 액터: 시스템과 상호작용 하는 모든 외부 요소
        • 주액터: 시스템을 사용함으로써 이득을 얻는 대상
        • 부액터: 주액터의 목적 달성을 위해 서비스를 제공하는 외부 시스템
      • 유스케이스: 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스
      • 관계: 연관, 포함, 확장, 일반화
    • 순차 다이어그램: 객체 간 메세지 표현
      • 액터: 외부 시스템
      • 객체: 메시지를 주고받는 주체
      • 생명선: 객체가 메모리에 존재하는 기간
      • 실행 상자: 객체가 메시지를 주고받고 있음을 표현
      • 메시지
      • 회귀 메시지(reply message)
      • 제어 블록(loop)
    • 상태 다이어그램: 이벤트에 의한 객체들의 변화 표현
    • 활동 다이어그램: 객체의 처리 흐름 표현

모듈

결합도

  • 아래로 갈 수록 결합도 강함(안 좋음)
  1. 자료 결합도(data): 매개변수로만 데이터 전달
  2. 스탬프 결합도(stamp): 배열이나 레코드 등의 자료 구조가 전달됨
  3. 제어 결합도(control): flag 변수를 전달함
  4. 외부 결합도(external): 모듈에서 선언한 변수를 다른 모듈에서 참조
  5. 공통 결합도(common): 공통의 영역을 여러 모듈이 참조
  6. 내용 결합도(content): 한 모듈의 내부 기능이나 자료를 직접 참조

응집도

  • 아래로 갈 수록 응집도 강함(좋음)
  1. 우연적 응집도(coincidental): 모듈의 구성 요소들이 관련 없음
  2. 논리적 응집도(logical): 유사한 기능들을 묶음
  3. 시간적 응집도(temporal): 특정 시간에 실행되는 기능들을 묶음(ex 프로그램 초기화)
  4. 절차적 응집도(procedual): 모듈 안의 구성 요소들이 순차적으로 수행됨. 데이터를 주고받지는 않음
  5. 교환적 응집도(communication): 동일한 입력 데이터 혹은 출력 데이터를 사용하여 서로 다른 기능을 수행함
  6. 순차적 응집도(sequential): 하나의 기능에서 나온 출력 데이터를 다음 기능의 입력 데이터로 사용
  7. 기능적 응집도(functional): 모듈 내 모든 기능들이 단일 문제와 연관됨
  • 팬인: 모듈이 다른 모듈로부터 호출되는 횟수
  • 팬아웃: 모듈이 다른 모듈을 호출하는 횟수
  • 팬인이 높고 팬아웃이 낮은 모듈이 이상적
맨 위로