레슨 05: 소프트웨어 모델링과 UML¶

이전: 04. 요구사항 공학 | 다음: 06. 추정과 계획

코드 한 줄이 작성되기 전에, 엔지니어들은 모델로 생각합니다. 모델은 일부 측면을 부각하고 나머지를 숨기는 시스템의 추상적이고 단순화된 표현입니다. 좋은 모델은 의사소통을 날카롭게 하고, 설계 문제를 조기에 드러내며, 기억이 희미해진 이후에도 오래도록 문서로 기능합니다. 통합 모델링 언어(UML, Unified Modeling Language)는 소프트웨어 모델을 위한 산업 표준 표기법입니다. 이 레슨은 가장 유용한 UML 다이어그램, 각각을 언제 적용해야 하는지, 그리고 올바르게 읽고 그리는 방법을 가르칩니다.

난이도: ⭐⭐⭐

선수 학습: - 레슨 01 — 소프트웨어 공학이란 무엇인가 - 레슨 04 — 요구사항 공학 (유스케이스는 여기서 다시 다룸) - 기본 객체지향 프로그래밍 개념 (클래스, 객체, 상속)

학습 목표: - 소프트웨어 모델이 왜 가치 있으며 어느 수준의 세부 사항으로 그려야 하는지 설명한다 - UML 2.x에서 구조 다이어그램과 행동 다이어그램을 구별한다 - 액터, 유스케이스, 관계를 포함한 유스케이스 다이어그램을 그리고 해석한다 - 클래스, 속성, 오퍼레이션, 다섯 가지 관계 유형을 보여주는 클래스 다이어그램을 그린다 - 생명선, 메시지, 활성화 박스, 복합 단편을 포함한 시퀀스 다이어그램을 그린다 - 결정 노드, 포크/조인, 수영 레인을 포함한 액티비티 다이어그램을 그린다 - 상태, 전이, 가드, 진입/진출 액션을 포함한 상태 머신 다이어그램을 그린다 - 컴포넌트 및 배포 다이어그램의 목적을 설명한다 - 모델링 모범 사례를 적용하고 일반적인 실수를 피한다

1. 소프트웨어를 모델링하는 이유¶

1.1 추상화의 역할¶

도시 지도는 도로의 모든 균열을 포함하지 않습니다 — 내비게이션에 중요한 도로와 랜드마크를 보여줍니다. 소프트웨어 모델도 같은 방식으로 작동합니다: 중요한 구조를 보이게 만들기 위해 관련 없는 세부 사항을 억제합니다.

모델링의 이점: - 의사소통: 다이어그램은 산문이나 코드보다 더 빠르게 이해관계자, 팀원, 미래의 유지보수자에게 구조를 전달합니다 - 초기 결함 감지: 모델에서 발견된 설계 결함은 코드나 프로덕션에서 발견된 결함보다 수정 비용이 훨씬 적게 듭니다 - 구축을 위한 청사진: 모델은 구현 선택을 안내합니다 - 문서화: 시스템과 동기화를 유지하는 살아있는 모델은 최신 아키텍처 문서로 기능합니다

1.2 적절한 추상화 수준¶

적절한 수준은 대상 독자와 목적에 따라 다릅니다:

대상 독자	적절한 모델	수준
비즈니스 이해관계자	유스케이스 다이어그램, 액티비티 다이어그램	비즈니스 프로세스
아키텍트	컴포넌트 / 배포 다이어그램	시스템 / 서브시스템
개발자	클래스 다이어그램, 시퀀스 다이어그램	모듈 / 클래스
테스터	상태 머신, 액티비티 다이어그램	행동 / 경계 사례

과도한 모델링은 시간을 낭비하고 아무도 읽지 않는 다이어그램을 생성합니다. 과소 모델링은 팀에 공유된 오해를 남깁니다. 경험 법칙: 새롭거나, 복잡하거나, 오해를 일으킬 가능성이 있는 부분을 모델링하세요.

1.3 실행 가능한 명세로서의 모델¶

일부 팀은 모델 주도 개발(MDD, Model-Driven Development) 도구 (예: Enterprise Architect, Modelio)를 사용하여 클래스 및 상태 머신 다이어그램에서 코드 스켈레톤을 생성합니다. 안전 필수 도메인 (자동차 AUTOSAR, 항공 전자 DO-178C)에서 모델은 권위 있는 산출물이 될 수 있습니다.

2. UML 개요¶

2.1 역사¶

UML은 1990년대 중반 Rational Software에서 Grady Booch, Ivar Jacobson, James Rumbaugh ("세 아미고")가 여러 경쟁하는 OO 표기법들을 통합하여 만들었습니다. 버전 1.0은 1997년 객체 관리 그룹(OMG, Object Management Group)에 제출되었습니다. UML 2.0 (2004)은 언어를 크게 재구성했습니다. 현재 표준은 UML 2.5.1 (2017)입니다.

2.2 다이어그램 분류¶

UML 2.x는 두 계열에 걸쳐 14가지 다이어그램 유형을 정의합니다:

구조 다이어그램(Structural Diagrams) — 정적 구조(무엇이 존재하는지)를 기술합니다:

다이어그램	기술 내용
클래스(Class)	클래스, 속성, 오퍼레이션, 관계
객체(Object)	클래스 다이어그램의 인스턴스 수준 스냅샷
컴포넌트(Component)	소프트웨어 컴포넌트와 인터페이스
복합 구조(Composite Structure)	클래스 또는 컴포넌트의 내부 구조
패키지(Package)	패키지와 의존성
배포(Deployment)	하드웨어 노드와 산출물 배포
프로파일(Profile)	UML 확장 메커니즘

행동 다이어그램(Behavioral Diagrams) — 동적 행동(무슨 일이 일어나는지)을 기술합니다:

다이어그램	기술 내용
유스케이스(Use Case)	사용자 관점에서의 시스템 기능
액티비티(Activity)	워크플로; 병렬 및 순차 액션
상태 머신(State Machine)	객체의 상태와 상태 간 전이
시퀀스(Sequence)	시간 순서로 정렬된 객체 상호작용
커뮤니케이션(Communication)	링크를 강조하는 객체 상호작용
타이밍(Timing)	시간 축에 대한 상태 변화
상호작용 개요(Interaction Overview)	상호작용 단편의 고수준 흐름

실무에서 가장 일반적으로 사용되는 다섯 가지 다이어그램은: 유스케이스, 클래스, 시퀀스, 액티비티, 상태 머신입니다. 이 레슨은 이 다섯 가지를 심층적으로 다룹니다.

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

유스케이스 다이어그램은 시스템과 상호작용하는 사람(액터)과 그들이 할 수 있는 것(유스케이스)을 보여줍니다. 기능 요구사항을 높은 추상화 수준에서 포착합니다.

3.1 요소¶

요소	표기법	설명
액터(Actor)	막대 인형	시스템과 상호작용하는 외부 엔터티 (사람, 시스템, 장치)
유스케이스(Use Case)	타원	액터에게 보이는 시스템 행동의 단위
시스템 경계(System Boundary)	사각형	내부 유스케이스와 외부 액터를 분리
연관(Association)	실선	액터가 유스케이스에 참여함
포함(Include)	점선 화살표 + `<<include>>`	유스케이스가 항상 다른 유스케이스를 포함함 (공유된 하위 행동)
확장(Extend)	점선 화살표 + `<<extend>>`	유스케이스가 선택적으로 다른 유스케이스를 확장함 (조건부 행동)
일반화(Generalization)	실선 화살표 (속이 빈 머리)	하나의 액터/유스케이스가 다른 것을 특수화함

3.2 포함(Include) vs. 확장(Extend)¶

<<include>>: 기본 유스케이스가 포함된 유스케이스를 항상 호출합니다. 재사용 가능한 행동을 추출하는 데 사용합니다. 화살표는 기본에서 포함으로 향합니다.
<<extend>>: 확장 유스케이스가 특정 조건 하에 기본 케이스에 선택적으로 행동을 추가합니다. 화살표는 확장에서 기본으로 향합니다.

기억 보조: <<include>>는 함수 호출과 같습니다 (항상 발생); <<extend>>는 플러그인과 같습니다 (때때로 발생).

3.3 ASCII 아트 예시: 온라인 도서관 시스템¶

            ┌─────────────────────────────────────────┐
            │           Online Library System          │
            │                                          │
  Member ───┼──── Search Catalog                       │
    │        │         │ <<include>>                    │
    │        │    View Book Details ◄── Extend ── Reserve Book
    │        │                                   (if logged in)
    │        │                                          │
    ├────────┼──── Borrow Book ─────<<include>>──────► Authenticate
    │        │                                          │
    │        │                                          │
  Librarian ─┼──── Manage Catalog                       │
    │        │                                          │
    │        │                                          │
   Admin ────┼──── Manage Users                         │
            │                                          │
            └─────────────────────────────────────────┘

(공식 도구에서는 화살표 방향이 올바르게 표시됩니다. ASCII 아트는 구조를 근사적으로 표현합니다.)

3.4 유스케이스 설명¶

유스케이스 다이어그램만으로는 충분하지 않습니다. 각 유스케이스는 다음을 포함하는 산문 설명이 있어야 합니다:

Use Case: Borrow Book
Actor: Member (primary), Librarian (secondary)
Preconditions: Member is authenticated. Book is available.
Main Success Scenario:
  1. Member scans book barcode.
  2. System verifies the book is available for loan.
  3. System records loan: member ID, book ID, due date (today + 14 days).
  4. System decrements available copy count.
  5. System prints/displays a loan receipt.
Postconditions: Loan record exists. Book copy count decreased by 1.
Alternative Flows:
  2a. Book is on hold for another member.
     System notifies librarian; loan is refused.
  2b. Member has exceeded the loan limit (5 books).
     System displays error; loan is refused.

3.5 일반적인 실수¶

너무 많은 유스케이스: 개별 시스템 단계가 아닌 완전한 사용자 목표 수준으로 유지
액터가 역할이 아닌 직책: "영업 관리자"는 관련 역할이 "승인자" 또는 "보고자"라면 그렇게 모델링해야 함
<<extend>>의 과용: 대부분의 선택적 행동은 흐름 내러티브에서 더 잘 포착됨
유스케이스 이름 안에 비즈니스 로직 포함: "프리미엄 회원이면 월별 할인 계산"은 단계이지 유스케이스가 아님

4. 클래스 다이어그램¶

클래스 다이어그램은 객체지향 설계를 위한 가장 기본적인 UML 다이어그램입니다. 시스템의 정적 구조를 보여줍니다: 클래스(또는 타입), 속성, 오퍼레이션, 그리고 클래스 간의 관계입니다.

4.1 클래스 표기법¶

┌──────────────────────────────┐
│        BankAccount           │  ← 클래스 이름 (중앙, 굵게)
├──────────────────────────────┤
│ - accountNumber: String      │  ← 속성(Attributes)
│ - balance: Decimal           │    가시성: - private, + public,
│ # owner: Customer            │    # protected, ~ package
│ + interestRate: float        │
├──────────────────────────────┤
│ + deposit(amount: Decimal)   │  ← 오퍼레이션(Operations, 메서드)
│ + withdraw(amount: Decimal)  │    반환 타입은 콜론 뒤에 표시
│ - calculateInterest(): float │
│ + getBalance(): Decimal      │
└──────────────────────────────┘

4.2 관계 유형¶

관계	표기법	의미	강도
의존(Dependency)	점선 화살표	A가 B를 사용함 (일시적)	가장 약함
연관(Association)	실선	A가 B에 대한 참조를 가짐	—
집합(Aggregation)	실선 + A쪽 속이 빈 다이아몬드	A가 B를 소유하지만 B는 A 없이 존재 가능	—
합성(Composition)	실선 + A쪽 채워진 다이아몬드	A가 B를 소유; B는 A 없이 존재 불가	더 강함
상속(Inheritance)	실선 + 부모쪽 속이 빈 삼각형	A는 B이다 (일반화)	—
실현(Realization)	점선 + 속이 빈 삼각형	A가 인터페이스 B를 구현함	—

4.3 다중성(Multiplicity)¶

다중성은 연관 선의 양쪽 끝에 나타납니다:

표기법	의미
`1`	정확히 하나
`0..1`	0 또는 하나 (선택적)
`` 또는 `0..`	0 이상
`1..*`	하나 이상
`2..5`	2에서 5 사이

4.4 ASCII 아트 예시: 전자상거래 주문 시스템¶

Customer                 Order                    Product
┌──────────────┐  1    *┌──────────────┐  *    *┌──────────────┐
│- customerId  ├────────┤- orderId     ├─────────┤- productId   │
│- name        │        │- orderDate   │         │- name        │
│- email       │        │- status      │         │- price       │
├──────────────┤        ├──────────────┤         │- stockQty    │
│+ register()  │        │+ addItem()   │         ├──────────────┤
│+ login()     │        │+ cancel()    │         │+ checkStock()│
│+ getOrders() │        │+ getTotal()  │         │+ reserve()   │
└──────────────┘        └──────┬───────┘         └──────────────┘
                               │ 1
                               │  (합성: 주문 항목은
                               │   주문 없이 존재 불가)
                              ◆│
                            * │
                    ┌──────────▼──────┐
                    │   OrderItem     │
                    │- quantity: int  │
                    │- unitPrice      │
                    ├─────────────────┤
                    │+ getSubtotal()  │
                    └─────────────────┘

PaymentMethod (추상)
┌──────────────────┐
│ <<abstract>>     │
│+ authorize()     │
│+ capture()       │
└────────┬─────────┘
         │ (상속)
    ┌────┴──────────────┐
    │                   │
CreditCard           BankTransfer
┌──────────┐       ┌──────────────┐
│- cardNum │       │- accountNum  │
│- expiry  │       │- routingNum  │
└──────────┘       └──────────────┘

4.5 인터페이스와 추상 클래스¶

인터페이스 (또는 <<interface>>)는 구현 없이 오퍼레이션을 선언합니다. 클래스는 인터페이스를 실현합니다.
추상 클래스 (공식 UML에서 이름이 기울임체, 또는 {abstract} 태그)는 인스턴스화될 수 없습니다; 서브클래스가 추상 오퍼레이션을 구현해야 합니다.

4.6 일반적인 실수¶

신 클래스(God class): 20개 이상의 속성과 30개 이상의 오퍼레이션을 가진 하나의 클래스. 단일 책임(single responsibility)에 따라 분리하세요.
다중성 누락: 1 또는 *를 생략하면 카디널리티에 모호성이 생깁니다.
집합과 합성 혼동: 자식의 생명주기가 부모에 엄격하게 의존할 때만 합성을 사용하세요.
관계 남용: 모든 연관에 명명된 역할이 필요한 것은 아닙니다. 명확성을 위해 역할 이름을 예약하세요.
다이어그램에 코드 넣기: 클래스 다이어그램의 오퍼레이션은 구현이 아닌 시그니처를 보여줍니다.

5. 시퀀스 다이어그램¶

시퀀스 다이어그램은 객체들이 시간에 걸쳐 시나리오를 수행하기 위해 어떻게 상호작용하는지를 보여줍니다 — 일반적으로 유스케이스의 하나의 주요 흐름입니다. 시간은 위에서 아래로 흐르며; x축은 객체 식별을 나타냅니다.

5.1 요소¶

요소	표기법	설명
생명선(Lifeline)	수직 점선	하나의 참여자 (객체, 컴포넌트, 액터)를 표현
활성화 박스(Activation box)	생명선 위의 얇은 사각형	객체가 실행 중인 기간
동기 메시지(Synchronous message)	실선 화살촉 `→`	호출자가 반환을 기다림
반환 메시지(Return message)	점선 화살표 `-->`	호출된 객체의 반환 값
비동기 메시지(Asynchronous message)	열린 화살촉 `->`	호출자가 기다리지 않음
자기 메시지(Self-message)	같은 생명선으로 돌아오는 화살표	객체가 자기 자신을 호출함 (재귀)
생성 메시지(Create message)	박스 헤드로 향하는 점선 화살표	새 객체를 인스턴스화
소멸(Destroy)	생명선 아래의 X	객체가 삭제됨

5.2 복합 단편(Combined Fragments)¶

복합 단편은 제어 흐름 표기법을 추가합니다:

연산자	의미
`alt`	대안 (if/else); 각 분기는 점선으로 구분
`opt`	선택적; 가드가 참일 때만 실행
`loop`	반복; `loop(min, max)` 또는 `loop(condition)`
`par`	하위 단편의 병렬 실행
`break`	둘러싸는 단편 중단
`ref`	다른 상호작용 다이어그램 참조
`critical`	원자적 영역; 인터리브되지 않음

5.3 ASCII 아트 예시: 사용자 로그인 시퀀스¶

  :User       :Browser      :AuthController  :UserRepository  :SessionStore
    |              |                |                 |               |
    |--submit()-->  |                |                 |               |
    |              |--POST /login-->|                 |               |
    |              |                |--findByEmail()-->|               |
    |              |                |<--User or null--|               |
    |              |  ┌─alt──────────────────────────────────────────┐|
    |              |  │ [user found AND password matches]             ||
    |              |  │              |--createSession(userId)-------->||
    |              |  │              |<----sessionToken---------------|
    |              |  │              |                                ||
    |              |<-│-200 OK + token                               ||
    |<--redirect-->|  │                                              ||
    |              |  ├──────────────────────────────────────────────┤|
    |              |  │ [user not found OR password wrong]            ||
    |              |<-│-401 Unauthorized                             ||
    |<--show error-|  └──────────────────────────────────────────────┘|
    |              |                |                 |               |

5.4 시퀀스 vs. 커뮤니케이션 다이어그램¶

둘 다 객체 상호작용을 보여줍니다. 시퀀스 다이어그램은 시간 순서 (왼쪽에서 오른쪽 또는 위에서 아래)를 강조합니다; 커뮤니케이션(협업) 다이어그램은 객체 간 링크 구조를 강조합니다. 시퀀스 다이어그램은 유스케이스 시나리오를 문서화하는 데 더 널리 사용됩니다.

5.5 일반적인 실수¶

너무 많은 생명선: 다이어그램당 4~7명의 참여자로 유지; 긴 시나리오를 분리하는 데 ref 단편 사용
반환 화살표 누락: 반환을 생략하면 호출이 동기적인지 모호해짐
모든 시스템 내부 포함: 시나리오와 관련된 객체와 메시지를 보여주고 모든 내부 호출은 제외
복합 단편 없는 평평한 다이어그램: 비자명한 제어 흐름을 보여주기 위해 alt, loop, opt 추가

6. 액티비티 다이어그램¶

액티비티 다이어그램은 워크플로 또는 알고리즘 — 일련의 액션을 통한 제어 및 데이터의 흐름 — 을 모델링합니다. UML의 순서도 등가물이지만 동시 실행을 위한 추가 기능이 있습니다.

6.1 요소¶

요소	표기법	설명
초기 노드(Initial node)	채워진 원	시작 지점
액티비티 최종 노드(Activity final node)	원 안의 채워진 원	전체 액티비티의 끝
흐름 최종 노드(Flow final node)	원 안의 X	하나의 분기를 끝냄, 전체 액티비티는 아님
액션(Action)	둥근 사각형	단일 단계 또는 작업
결정/병합 노드(Decision/Merge node)	다이아몬드	분기 (결정) 또는 분기 합류 (병합)
포크(Fork)	두꺼운 수평 바	흐름을 병렬 분기로 분할
조인(Join)	두꺼운 수평 바	병렬 분기를 동기화
수영 레인/파티션(Swimlane/partition)	수직/수평 레인	역할 또는 컴포넌트에 책임 할당
객체 노드(Object node)	사각형	생성되거나 소비되는 데이터
제어 흐름(Control flow)	화살표	액션 간의 순서

6.2 ASCII 아트 예시: 주문 처리 (수영 레인 포함)¶

  Customer              Website               Warehouse            Finance
     │                     │                      │                   │
  ●  │                     │                      │                   │
     │──Place Order──────►  │                      │                   │
     │                     │──Validate Payment──────────────────────► │
     │                     │◄───────────────────────────────OK────── │
     │                     │                      │                   │
     │                     │──Send Order────────► │                   │
     │                     │                     ═══ (Fork)           │
     │                     │              Pick Items│   │Update Stock  │
     │                     │                      │   │               │
     │                     │                     ═══ (Join)           │
     │                     │◄──Shipment Confirmed─ │                   │
     │◄──Confirmation Email─ │                      │                   │
  ⊙  │                     │                      │                   │

6.3 액티비티 다이어그램을 사용해야 할 때¶

비즈니스 프로세스 문서화 (주문에서 현금까지, 직원 온보딩)
분기와 반복이 있는 알고리즘 워크플로 모델링
동시 프로세스 표시 (포크/조인)
교차 기능 책임 포착 (수영 레인을 통해)

액티비티 다이어그램은 초점이 객체 상호작용보다 제어 흐름에 있을 때 시퀀스 다이어그램보다 선호됩니다.

6.4 일반적인 실수¶

결정 전 병합 누락: 두 개의 들어오는 흐름 (양쪽 분기 모두에서)이 있는 결정 노드에는 그 앞에 명시적인 병합 노드가 있어야 함
지나치게 복잡한 다이어그램: 액티비티 다이어그램이 한 페이지를 초과하면 서브 액티비티(호출 행동 액션)를 사용하여 분해
포크와 결정 혼동: 포크는 병렬 흐름을 생성; 결정은 배타적 대안 흐름을 생성

7. 상태 머신 다이어그램¶

상태 머신 다이어그램은 객체의 이산 상태와 이벤트에 반응하여 그 상태들 간의 전이를 모델링합니다. 상태 머신은 행동이 그 이력에 크게 의존하는 객체에 특히 유용합니다.

7.1 요소¶

요소	표기법	설명
상태(State)	둥근 사각형	객체가 있을 수 있는 조건
초기 의사상태(Initial pseudostate)	채워진 원	진입 지점
최종 상태(Final state)	원 안의 채워진 원	종료 상태
전이(Transition)	상태 간 화살표	트리거된 변경
가드(Guard)	전이에 `[조건]`	전이를 활성화하는 불리언 조건
트리거(Trigger)	`/` 앞의 이벤트 이름	전이를 발화시키는 이벤트
액션(Action)	`/` 뒤	전이 시 실행되는 행동
진입 액션(Entry action)	상태의 `entry / 액션`	상태 진입 시 실행
진출 액션(Exit action)	상태의 `exit / 액션`	상태 이탈 시 실행
도 액티비티(Do activity)	상태의 `do / 액티비티`	상태에 있는 동안 진행 중인 액티비티

7.2 전이 구문¶

trigger [guard] / action

예시: paymentReceived [amount >= total] / confirmOrder()

7.3 ASCII 아트 예시: 주문 생명주기¶

     ●
     │
     ▼
┌──────────┐   itemsAdded       ┌──────────────┐
│  DRAFT   │──────────────────► │  PENDING     │
│          │                    │  PAYMENT     │
└──────────┘                    └──────┬───────┘
                                       │
              paymentReceived [valid]  │    paymentFailed
              ◄─────────────────────── ┤ ──────────────────────►
              │                        │                       ┌──────────┐
              ▼                        │                       │ PAYMENT  │
      ┌───────────────┐                │                       │ FAILED   │
      │   CONFIRMED   │                │                       └──────────┘
      │ entry/notifyWH│                │
      │ do/reserveItems│               │
      └───────┬───────┘               │
              │ shipped               │
              ▼                       │
      ┌───────────────┐               │
      │   SHIPPED     │               │
      │ entry/sendEmail│              │
      └───────┬───────┘               │
              │ delivered             │
              ▼                       │
      ┌───────────────┐               │
      │   DELIVERED   │               │
      └───────┬───────┘               │
              │                       │
        ┌─────┴─────┐  customerReturn │
        │           │────────────────►┌──────────┐
        │           │                 │ RETURNED │
        │           │                 └──────────┘
        ▼           │
       ⊙            │

7.4 복합 상태와 이력¶

복합 상태(composite state) (내부 상태가 있는 상태)는 계층적 상태 머신을 허용합니다. 이력 의사상태(history pseudostate) (H)는 복합 상태가 종료될 때 어떤 하위 상태가 활성 상태였는지 기억하여 재진입 시 그곳에서 재개합니다.

7.5 일반적인 실수¶

초기 전이 누락: 모든 상태 머신에는 초기 의사상태가 있어야 함
가드 없는 경쟁 전이: 같은 상태에서 같은 트리거를 가지고 가드가 없는 두 전이가 있으면 동작이 비결정적임
너무 많은 객체 모델링: 상태 머신은 전체 시스템이 아닌 개별 객체를 위한 것
상태를 값으로 혼동: 상태는 (객체가 어떻게 반응하는지에 대한) 행동 모드를 포착해야 하지 단순히 데이터 값이 아님

8. 컴포넌트 및 배포 다이어그램¶

8.1 컴포넌트 다이어그램¶

컴포넌트 다이어그램은 시스템을 구성하는 소프트웨어 컴포넌트 (모듈, 서비스, 실행 파일, 라이브러리)와 그것들의 인터페이스 및 의존성을 보여줍니다.

주요 표기법: - 컴포넌트: <<component>> 스테레오타입 또는 컴포넌트 아이콘 (왼쪽 가장자리에 두 개의 작은 박스가 있는 박스)이 있는 박스 - 제공 인터페이스: "막대사탕" (선 위의 원) - 요구 인터페이스: "소켓" (선 위의 반원) - 의존성: 점선 화살표

                   ┌──────────────────┐
                   │  <<component>>   │
                   │   OrderService   ○── IOrderPort
                   │                  │
                   └────────┬─────────┘
                            │ uses
                     ┌──────┴────────────────┐
             ┌───────▼──────┐  ┌─────────────▼─────┐
             │ <<component>>│  │  <<component>>     │
             │ PaymentGW    │  │  InventoryService  │
             └──────────────┘  └────────────────────┘

8.2 배포 다이어그램¶

배포 다이어그램은 소프트웨어 컴포넌트가 물리적 또는 가상 노드 (하드웨어, VM, 컨테이너, 클라우드 서비스)에 어떻게 매핑되는지를 보여줍니다.

주요 표기법: - 노드: 3D 박스 (하드웨어) 또는 <<device>>, <<executionEnvironment>> - 산출물: 배포된 실행 파일 또는 파일 (<<artifact>>) - 통신 경로: 노드 간 실선

┌────────────────────────┐       ┌────────────────────────┐
│ <<device>>             │       │ <<device>>             │
│  Web Server (AWS EC2)  │───────│  DB Server (RDS)       │
│  ┌──────────────────┐  │  TCP  │  ┌──────────────────┐  │
│  │ <<artifact>>     │  │ 5432  │  │ <<artifact>>     │  │
│  │  app.war         │  │       │  │  postgres DB     │  │
│  └──────────────────┘  │       │  └──────────────────┘  │
└────────────────────────┘       └────────────────────────┘
            │
         HTTPS
            │
┌───────────▼────────────┐
│ <<device>>             │
│  Client Browser        │
└────────────────────────┘

배포 다이어그램은 다음에 필수적입니다: - DevOps 및 운영 팀에 인프라 아키텍처 전달 - 네트워크 보안 영역 계획 - 컨테이너 및 마이크로서비스 아키텍처 문서화

9. 어떤 다이어그램을 사용해야 하는가¶

목표	최적 다이어그램
이해관계자에게 시스템 범위 전달	유스케이스
상세한 유스케이스 흐름 문서화	시퀀스
객체 구조와 관계 설계	클래스
워크플로 또는 비즈니스 프로세스 표시	액티비티
객체 생명주기 모델링 (예: 주문 상태)	상태 머신
시스템 컴포넌트와 API 문서화	컴포넌트
인프라 및 배포 표시	배포
병렬 및 동시 흐름 탐색	액티비티 (포크/조인)
파이프라인을 통한 데이터 변환 표시	액티비티 (객체 노드)
알고리즘 분기 문서화	액티비티 또는 시퀀스 (alt/opt 포함)

실용적인 경험 법칙: - 범위를 정의하기 위해 유스케이스 다이어그램으로 시작하세요 - 시퀀스 다이어그램으로 핵심 시나리오를 상세화하세요 - 클래스 다이어그램으로 도메인 모델을 설계하세요 - 생명주기가 중요한 객체를 위해 상태 머신을 추가하세요 - 컴포넌트 및 배포 다이어그램으로 아키텍처를 문서화하세요

10. 모델링 모범 사례와 일반적인 실수¶

10.1 모범 사례¶

목적을 가지고 모델링하세요: 모든 다이어그램에는 명시된 대상 독자와 답해야 할 질문이 있어야 합니다. 다이어그램이 왜 존재하는지 명시할 수 없다면 그리지 마세요.
완벽함보다 스케치를 선호하세요: 아이디어를 전달하는 거친 다이어그램의 화이트보드 사진은 3일이 걸렸지만 이미 구식이 된 픽셀 완벽한 다이어그램보다 더 가치 있습니다.
다이어그램을 작게 유지하세요: 스크롤이나 줌이 필요한 다이어그램은 아무도 읽지 않습니다. 패키지, 서브 액티비티, 또는 ref 프레임을 사용하여 큰 다이어그램을 분할하세요.
일관성을 유지하세요: 클래스 다이어그램에서 OrderItem이라고 불리는 클래스는 어디서나 OrderItem이어야 합니다 — 시퀀스 다이어그램에서 LineItem이고 데이터베이스 스키마에서 Item이어선 안 됩니다.
모델을 버전 관리하세요: 모델 소스 파일 (.xmi, .puml, .drawio)을 코드와 함께 저장소에 저장하세요. CI에서 다이어그램 이미지를 생성하세요.
텍스트 기반 모델을 위해 PlantUML 또는 Mermaid를 사용하세요: 코드 리뷰 도구와 통합되고 다이어그램이 코드와 동기화에서 벗어나는 것을 방지합니다.
이해관계자와 검증하세요: 모든 다이어그램은 권위 있는 것으로 취급되기 전에 적어도 한 명의 비작성자와 함께 검토되어야 합니다.

10.2 일반적인 실수 요약¶

실수	영향	수정
모든 것을 모델링	시간 낭비; 아무도 읽지 않는 다이어그램	새롭거나 논쟁적인 것만 모델링
잘못된 다이어그램 유형	오해	질문에 다이어그램 맞추기 (§9 참조)
일관되지 않은 이름	혼란, 구현 오류	용어집에 동의; 모든 곳에 적용
구식 다이어그램	문서에 대한 거짓된 확신	코드와 같은 PR에서 다이어그램 업데이트
다중성 누락	모호한 카디널리티가 잘못된 스키마로 이어짐	항상 연관의 양쪽 끝에 주석 추가
`<<extend>>` 과용	복잡하고 읽기 어려운 유스케이스 다이어그램	선택적 흐름에는 내러티브 설명 선호
NFR 무시	다이어그램이 구조를 포착하지만 성능, 보안 놓침	컴포넌트/배포 다이어그램에 제약 주석 추가

10.3 도구¶

도구	유형	참고
PlantUML	텍스트 기반, 오픈소스	IDE, CI와 통합; 버전 관리에 적합
Mermaid	텍스트 기반, JS 렌더링	GitHub/GitLab 네이티브; 시퀀스와 클래스에 탁월
draw.io / diagrams.net	GUI, 무료	임시 다이어그램에 적합; XML 형식은 버전 관리 가능
Lucidchart	GUI, 클라우드	협업 친화적; Jira/Confluence 통합
Enterprise Architect	완전한 CASE 도구	MDD와 코드 생성이 필요한 대형 팀에 적합
Visual Paradigm	완전한 CASE 도구	UML + BPMN + ArchiMate 지원

11. 요약¶

UML은 여러 추상화 수준에서 소프트웨어를 모델링하기 위한 표준화된 어휘를 제공합니다. 가장 중요한 다섯 가지 다이어그램은:

다이어그램	계열	핵심 답변 질문
유스케이스(Use Case)	행동	사용자가 시스템으로 무엇을 할 수 있는가?
클래스(Class)	구조	어떤 유형이 존재하며 어떻게 관련되어 있는가?
시퀀스(Sequence)	행동	어떤 객체들이 어떤 순서로 협력하는가?
액티비티(Activity)	행동	이 프로세스 또는 알고리즘의 흐름은 무엇인가?
상태 머신(State Machine)	행동	이 객체의 행동이 상태에 어떻게 의존하는가?

핵심 원칙: - 목적을 가지고 모델링하세요: 당면한 질문에 답하는 다이어그램을 선택하세요 - 다이어그램을 작고 집중적으로 유지하세요; 대형 시스템에는 참조를 사용하세요 - 코드와 다른 산출물과 일관성을 유지하세요 - 코드와 함께 살아가는 다이어그램을 위해 텍스트 기반 도구 (PlantUML, Mermaid)를 사용하세요 - 항상 의도된 대상 독자와 모델을 검증하세요

UML은 목적을 위한 수단입니다 — 더 나은 소프트웨어. 공유된 이해를 개선하거나 설계 결함을 잡지 못하는 완벽한 다이어그램은 그 목적을 달성하지 못한 것입니다.

12. 연습 문제¶

연습 1: 유스케이스 다이어그램

호텔 예약 시스템을 위한 유스케이스 다이어그램을 그리세요. 시스템은 세 명의 액터를 지원합니다: Guest(투숙객), Receptionist(접수원), System Administrator(시스템 관리자). 최소 여섯 개의 유스케이스와 최소 하나의 <<include>>와 하나의 <<extend>> 관계를 포함하세요. "Book Room(객실 예약)" 유스케이스에 대한 간략한 유스케이스 설명 (사전 조건, 주요 흐름, 대안 흐름)을 작성하세요.

연습 2: 클래스 다이어그램

다음 클래스들로 대학 강좌 등록 시스템을 모델링하세요: Student(학생), Course(강좌), Enrollment(등록), Instructor(강사), Department(학과). 다음을 포함하세요: - 최소 하나의 상속 계층 (예: 다양한 학생 유형) - 모든 연관에 올바른 다중성 - 최소 하나의 합성과 하나의 집합 - 클래스당 최소 다섯 개의 속성과 세 개의 오퍼레이션

연습 3: 시퀀스 다이어그램

연습 2 시스템에서 "학생이 강좌에 등록" 시나리오를 위한 시퀀스 다이어그램을 그리세요. 시나리오는 최소 네 개의 객체를 포함하고 최소 하나의 alt 단편 (예: 강좌가 꽉 찬 경우 vs. 그렇지 않은 경우)과 하나의 loop 또는 opt 단편을 포함해야 합니다.

연습 4: 액티비티 및 상태 머신

ATM 시스템에 대해:

a. "현금 출금" 유스케이스를 위한 액티비티 다이어그램을 그리세요. 다음 단계들을 포함하세요: 카드 삽입, PIN 검증 (재시도 로직, 최대 3회), 금액 선택, 잔액 확인, 현금 지급, 영수증 출력, 카드 반환.

b. ATM 자체에 대한 상태 머신 다이어그램을 그리세요. 상태: 유휴(Idle), 카드삽입됨(CardInserted), PIN입력(PINEntry), 인증됨(Authenticated), 거래진행중(TransactionInProgress), 지급중(Dispensing), 서비스불가(OutOfService).

연습 5: 아키텍처 다이어그램

마이크로서비스 전자상거래 백엔드를 설계하고 있습니다. 다음을 그리세요:

a. 최소 다섯 개의 서비스 (예: API Gateway, Order Service, Inventory Service, Payment Service, Notification Service)를 필요 인터페이스와 제공 인터페이스와 함께 보여주는 컴포넌트 다이어그램.

b. 이러한 서비스들이 로드 밸런서, PostgreSQL 데이터베이스 클러스터 (기본 + 복제본), Redis 캐시와 함께 Kubernetes 파드에 배포된 것을 보여주는 배포 다이어그램.

13. 더 읽을거리¶

Rumbaugh, J., Jacobson, I., Booch, G. — The Unified Modeling Language Reference Manual (2nd ed., Addison-Wesley, 2004) — UML 창시자들의 권위 있는 참고서
Fowler, M. — UML Distilled (3rd ed., Addison-Wesley, 2003) — 짧고 실용적인 가이드; UML에 관한 최고의 첫 번째 책
OMG UML Specification 2.5.1 — https://www.omg.org/spec/UML/ — 규범적 명세서
PlantUML documentation — https://plantuml.com/ — IDE 통합을 포함한 텍스트 기반 UML
Mermaid documentation — https://mermaid.js.org/ — GitHub/GitLab용 브라우저 네이티브 다이어그래밍
Scott, K. — Fast Track UML 2.0 (Apress, 2004) — 작업 예제를 포함한 간결한 참고서
Evans, E. — Domain-Driven Design (Addison-Wesley, 2003) — 클래스 모델이 도메인 개념을 어떻게 반영하는가

이전: 04. 요구사항 공학 | 다음: 06. 추정과 계획