SW 전공

SW 전공 이론 학습

이론 목록으로 돌아가기

UML과 시스템 분석·설계

UML 구조·행위 다이어그램과 업무·데이터·인터페이스 분석에서 논리·물리 설계까지의 흐름을 학습한다.

예상 읽기 9분

1. UML의 역할

UML(Unified Modeling Language)은 시스템을 분석·설계·의사소통하기 위한 표준화된 모델링 언어이다. UML은 개발 방법론 자체가 아니라 여러 방법론에서 사용할 수 있는 표현 언어이다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
요구사항
   ↓
분석 모델: 무엇이 필요한가
   ↓
설계 모델: 어떻게 구성할 것인가
   ↓
구현·테스트·배포

UML 모델은 모든 코드를 완벽히 대체하는 문서가 아니라, 핵심 구조·행위·책임·관계를 이해관계자 사이에 공유하는 수단이다.

2. UML 다이어그램 분류

분류대표 다이어그램주요 질문
구조클래스, 객체, 컴포넌트, 배치, 패키지무엇으로 구성되는가?
행위유스케이스, 활동, 상태어떤 행동과 상태 변화가 있는가?
상호작용시퀀스, 커뮤니케이션객체들이 어떤 순서로 메시지를 교환하는가?

3. 유스케이스 다이어그램

유스케이스 다이어그램은 시스템 외부 액터와 시스템이 제공하는 목표 중심 기능을 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
   [회원]
      │
      ├──────── (로그인)
      ├──────── (비밀번호 재설정)
      └──────── (주문 조회)

[관리자] ────── (상품 관리)
  • 액터: 시스템 외부에서 상호작용하는 역할
  • 유스케이스: 액터가 달성하려는 시스템 기능
  • 시스템 경계: 대상 시스템의 범위
  • include: 공통 기능을 반드시 포함
  • extend: 특정 조건에서 선택적으로 확장
  • 일반화: 액터 또는 유스케이스의 상위·하위 관계

include와 extend는 단순 실행 순서 표시가 아니다.

4. 클래스 다이어그램

클래스 다이어그램은 클래스의 속성·연산과 클래스 사이 관계를 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
┌────────────────────────┐
│ Order                  │
├────────────────────────┤
│ - id: Long             │
│ - status: OrderStatus  │
├────────────────────────┤
│ + cancel(): void       │
│ + total(): Money       │
└────────────────────────┘
           ◆ 1
           │
           │ 1..*
┌────────────────────────┐
│ OrderItem              │
└────────────────────────┘

가시성 표기는 + public, - private, # protected, ~ package를 주로 사용한다. 다중도 예시는 1, 0..1, *, 1..*이다.

관계 판독:

  • 실선: 연관
  • 빈 마름모: 집합
  • 채운 마름모: 합성
  • 빈 삼각형 실선: 일반화
  • 빈 삼각형 점선: 실체화
  • 점선 화살표: 의존

5. 시퀀스 다이어그램

시퀀스 다이어그램은 시간 순서에 따른 객체 사이 메시지를 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
User        UI        AuthService        UserRepo
 │          │              │                 │
 │ login()  │              │                 │
 ├─────────►│ authenticate │                 │
 │          ├─────────────►│ findById()      │
 │          │              ├────────────────►│
 │          │              │◄────────────────┤
 │          │              │ verifyPassword  │
 │          │◄─────────────┤                 │
 │◄─────────┤ result       │                 │

세로선은 생명선, 가로 화살표는 메시지이며 위에서 아래로 시간이 흐른다. alt, opt, loop 같은 결합 단편으로 조건·선택·반복을 표현할 수 있다.

6. 활동 다이어그램

활동 다이어그램은 업무나 알고리즘의 제어 흐름을 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
● 시작
  ↓
주문 검증
  ↓
<재고 있음?> ─아니오─► 품절 안내 ─► ◎ 종료
  │예
  ▼
결제 ──┬──► 영수증 발행
       └──► 재고 차감
  ↓
배송 요청
  ↓
◎ 종료

분기·병합, 병렬 분기·합류, 객체 흐름을 표현할 수 있다.

7. 상태 다이어그램

상태 다이어그램은 한 객체가 이벤트에 따라 상태를 바꾸는 과정을 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
[생성] → 결제대기
           │ 결제완료
           ▼
         결제완료
           │ 발송
           ▼
          배송중
           │ 배송완료
           ▼
          완료

결제대기 ─ 취소 ─► 취소됨
결제완료 ─ 환불승인 ─► 환불됨

상태는 객체의 행동과 허용 이벤트가 달라지는 의미 있는 조건이다.

8. 컴포넌트와 배치 다이어그램

  • 컴포넌트 다이어그램: 소프트웨어 모듈·서비스·라이브러리와 제공·필요 인터페이스를 표현
  • 배치 다이어그램: 서버·단말·네트워크 노드와 실행 아티팩트의 배치를 표현
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
[Web Browser]
      │ HTTPS
      ▼
[Web/API Server] ──► [Database]
      │
      └────────────► [Message Broker]
                          │
                          ▼
                     [Worker Service]

컴포넌트는 논리적 소프트웨어 구성, 배치는 물리·실행 환경을 중심으로 본다.

9. UML 이외의 분석 모델

DFD

데이터 흐름도는 프로세스, 데이터 흐름, 데이터 저장소, 외부 엔터티를 나타낸다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
[고객] ─ 주문정보 ─► (주문 접수) ─► ||주문 DB||
  ▲                         │
  └──── 주문결과 ◄──────────┘

CRUD 매트릭스

프로세스\엔터티고객주문상품
회원가입C
주문등록RCR
주문취소RUR

누락된 데이터 책임이나 지나치게 많은 의존을 발견하는 데 도움이 된다.

10. 논리 설계와 물리 설계

단계핵심 질문대표 산출물
분석무엇이 필요한가?요구 모델, 업무·데이터 모델
논리 설계기술과 무관한 구조는?논리 컴포넌트, 인터페이스, 논리 DB
물리 설계실제 기술로 어떻게 배치할까?서버·네트워크·DBMS·배포 구조
CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
요구·업무 모델
    ↓
논리 구조: 서비스·데이터·인터페이스 분할
    ↓
물리 구조: 제품·서버·네트워크·저장 방식 선택
    ↓
구현·이행 계획

11. include와 extend의 방향

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
(주문 처리) --<<include>>--> (인증 확인)
(쿠폰 적용) --<<extend>>-->  (주문 처리)
  • include 화살표는 포함하는 기본 유스케이스에서 재사용되는 포함 유스케이스를 향한다.
  • extend 화살표는 조건부 확장 유스케이스에서 확장 대상 기본 유스케이스를 향한다.

include는 공통 필수 행동 분리, extend는 기본 흐름을 독립적으로 완성한 뒤 선택적 행동을 붙이는 데 적합하다.

12. 시퀀스 결합 단편과 메시지

단편의미
alt조건에 따른 여러 대안 중 하나
opt조건이 참일 때만 수행
loop조건·횟수만큼 반복
par병렬로 수행 가능한 상호작용

동기 메시지는 호출자가 응답을 기다리는 호출, 비동기 메시지는 호출 후 다른 작업을 계속할 수 있는 메시지에 가깝다. 반환 메시지는 필요할 때 점선으로 나타낼 수 있다. 생성·소멸 메시지는 생명선의 시작과 끝을 바꾼다.

13. 활동 다이어그램의 분기와 병렬

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
결정(decision) : 하나의 흐름이 guard에 따라 하나로 분기
병합(merge)    : 대안 흐름 중 하나를 다시 합침
fork           : 하나의 흐름을 여러 병렬 흐름으로 분리
join           : 필요한 병렬 흐름이 끝날 때까지 동기화

결정 노드와 fork를 혼동하면 “하나만 수행”과 “모두 병렬 수행”을 반대로 해석하게 된다.

14. 상태 전이 표기

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.
event [guard] / action
결제요청 [잔액충분] / 승인처리
  • event: 전이를 일으키는 사건
  • guard: 전이가 허용되는 조건
  • action: 전이 순간 수행하는 동작
  • entry, do, exit: 상태 진입·머무는 동안·이탈 시 행동

이벤트가 와도 guard가 거짓이면 해당 전이는 수행되지 않는다.

15. DFD 균형과 CRUD 누락

상위 DFD의 프로세스를 하위 DFD로 분해할 때 외부로 들어오고 나가는 데이터 흐름은 논리적으로 균형을 이뤄야 한다. 외부 엔터티가 데이터 저장소를 직접 읽거나 저장소끼리 직접 데이터를 이동하는 표기는 중간 프로세스 없이 업무 처리가 일어난 것처럼 보여 부적절하다.

CRUD 매트릭스에서 어떤 엔터티에도 C가 없으면 생성 책임이 누락됐을 수 있고, R만 지나치게 많으면 공유 의존과 조회 권한을 검토해야 한다.

확인 문제

  1. include 관계의 화살표는 기본 유스케이스와 포함 유스케이스 중 어느 쪽을 향하는가?
  2. 시퀀스 다이어그램의 par 단편은 무엇을 표현하는가?
  3. 활동 다이어그램에서 여러 병렬 흐름의 완료를 기다리는 노드는 무엇인가?
  4. event[guard]/action에서 guard가 거짓이면 전이는 어떻게 되는가?
  5. 상위 DFD를 하위 DFD로 분해할 때 유지해야 하는 핵심 원칙은 무엇인가?