3강. UML과 분석 모델 — 다이어그램·모델링 기법·분석 자동화 도구 | 정보처리기사 필기 완전정복 50강 · 중급 — 누구나패스

🎯 이 강의 학습 목표

이 강을 마치면 UML의 구성 요소와 14종 다이어그램을 구조·행위로 나눌 수 있고, 클래스 다이어그램의 관계 표기(연관·집합·합성·일반화·실현·의존)를 보고 코드 구조를 읽을 수 있습니다. 또 유스케이스의 포함·확장 관계, 시퀀스·상태·활동 다이어그램의 기호를 구별하고, 구조적 분석과 객체지향 분석의 모델링 기법, 분석 자동화(CASE) 도구의 분류를 설명할 수 있습니다.

출제기준 위치: [소프트웨어 개발 › 1. 요구사항 확인 › 1. 요구사항 확인 › 2. UML], [같은 항목 › 2. 분석모델 확인 › 1. 모델링 기법 · 2. 분석자동화 도구]. 요구사항 관리 도구는 2강에서 다뤘습니다.

💡 UML의 구성 — 사물, 관계, 다이어그램

UML(Unified Modeling Language)은 소프트웨어를 시각적으로 명세·구성·문서화하는 표준 모델링 언어로, 표준 관리 단체 OMG가 발행합니다. 현재 공식판은 2017년 12월 발행된 UML 2.5.1입니다. 모두가 같은 그림을 같은 뜻으로 읽도록 기호의 의미가 엄격히 정해져 있습니다.

UML은 세 가지 요소로 설명합니다. 사물(Things)은 모델의 구성 단위로, 클래스·유스케이스·컴포넌트 같은 구조 사물, 상호작용·상태 머신 같은 행동 사물, 요소를 묶는 그룹 사물(패키지), 설명을 붙이는 주해 사물(노트)이 있습니다. 관계(Relationships)는 사물 사이의 연결이고, 다이어그램은 사물과 관계를 특정 관점에서 그린 그림입니다.

분류	다이어그램
구조(정적) 7종	클래스, 객체, 컴포넌트, 배치(Deployment), 복합 구조, 패키지, 프로파일
행위(동적) 3종	유스케이스, 활동, 상태 머신
행위 중 상호작용 4종	시퀀스, 커뮤니케이션, 상호작용 개요, 타이밍

구조 다이어그램은 「무엇으로 이루어져 있는가」를, 행위 다이어그램은 「시간에 따라 어떻게 움직이는가」를 보여 줍니다. 배치 다이어그램은 서버·장치 같은 물리 노드에 실행 산출물을 어떻게 올리는지 그리고, 컴포넌트 다이어그램은 교체 가능한 소프트웨어 부품과 인터페이스를 그립니다. 둘 다 구조 다이어그램입니다.

💡 관계 표기 — 선 모양과 끝 모양으로 구분

관계 문제는 「선이 실선인가 점선인가」와 「끝에 무엇이 달렸는가」 두 가지만 보면 풀립니다.

관계	표기	의미
연관(Association)	실선(방향이 있으면 열린 화살표)	두 클래스가 서로 참조하며 협력
집합(Aggregation)	실선 + 전체 쪽 빈 마름모	전체-부분이지만 부분이 독립적으로 존재 가능
합성(Composition)	실선 + 전체 쪽 채운 마름모	부분의 생명주기가 전체에 종속
일반화(Generalization)	실선 + 부모 쪽 빈 삼각형	is-a 관계, 상속
실현(Realization)	점선 + 인터페이스 쪽 빈 삼각형	인터페이스의 기능을 클래스가 구현
의존(Dependency)	점선 + 열린 화살표	매개변수·지역변수처럼 짧게 사용, 상대가 바뀌면 영향받음

마름모는 항상 「전체」 쪽에 붙고, 삼각형은 항상 「부모·인터페이스」 쪽을 향합니다. 연관 양 끝에는 다중도(1, 0..1, *, 1..*)를 적습니다. 클래스 상자는 이름·속성·연산 세 칸으로 나누고, 접근 제어는 + public, - private, # protected, ~ package로 표시합니다. 추상 클래스와 추상 연산은 이름을 기울임꼴로 쓰거나 {abstract}를 붙입니다.

💡 자주 나오는 행위 다이어그램

유스케이스 다이어그램은 시스템 밖의 액터(사람 모양)와 시스템이 제공하는 기능(타원)을 시스템 경계(사각형) 안팎에 배치합니다. 유스케이스 사이 관계 중 포함(<<include>>)은 기본 유스케이스가 실행될 때 반드시 함께 실행되는 공통 기능입니다. 화살표는 기본 → 포함 쪽으로 향합니다(예: 「주문하기」 → 「로그인」). 확장(<<extend>>)은 특정 조건에서만 덧붙는 선택 기능으로, 화살표는 확장 → 기본 쪽입니다(예: 「쿠폰 적용」 → 「결제하기」). 방향이 반대라는 점이 단골 함정입니다.

시퀀스 다이어그램은 객체 사이에 주고받는 메시지를 시간 순서로 보여 줍니다. 위에서 아래로 내려오는 점선이 생명선, 그 위의 얇은 막대가 활성 구간(실행 중인 구간)입니다. 동기 메시지는 실선과 채운 화살촉, 비동기 메시지는 실선과 열린 화살촉, 응답은 점선 화살표로 그립니다. 조건 분기는 alt, 선택 실행은 opt, 반복은 loop, 병렬은 par 결합 프래그먼트로 묶습니다. 같은 상호작용을 객체 간 연결 구조 중심으로 그리고 메시지에 번호를 붙이면 커뮤니케이션 다이어그램이 됩니다.

상태 머신 다이어그램은 한 객체가 이벤트에 따라 상태를 바꾸는 과정을 그립니다. 상태는 모서리가 둥근 사각형, 시작은 채운 원, 종료는 테두리가 있는 채운 원(과녁 모양)입니다. 전이는 화살표에 이벤트[가드 조건]/동작 형식으로 적습니다. 활동 다이어그램은 처리 흐름을 순서도처럼 그리며, 마름모는 분기·병합, 굵은 막대는 병렬 흐름의 분기(fork)와 합류(join)입니다. 수영 레인처럼 칸을 나눠 담당 주체를 표시하는 것을 파티션(swimlane)이라고 합니다.

💡 분석 모델링 기법과 분석 자동화 도구

UML 이전부터 쓰인 구조적 분석은 데이터가 처리 과정을 따라 흐르는 모습에 초점을 둡니다. 핵심 도구는 다음 네 가지입니다.

자료 흐름도(DFD): 프로세스(원), 자료 흐름(화살표), 자료 저장소(평행선), 단말(사각형) 네 기호로 시스템을 그립니다. 상위 DFD를 하위로 쪼개 나가는 단계적 분할을 씁니다.
자료 사전(DD): DFD에 나오는 자료를 정의합니다. 기호는 = 정의, + 연결, [ | ] 택일, { } 반복, ( ) 생략 가능, * * 주석입니다.
소단위 명세서(Mini-Spec): 최하위 프로세스의 처리 논리를 구조적 언어·의사결정표 등으로 적습니다.
개체 관계도(ERD)와 상태 전이도(STD): 데이터 구조와 시간에 따른 제어 흐름을 보완합니다.

객체지향 분석은 데이터와 그 데이터를 다루는 연산을 객체로 묶어 모델링합니다. 대표 방법론으로 럼바우의 OMT가 있는데, 객체 모델링(객체 다이어그램으로 정적 구조) → 동적 모델링(상태 다이어그램으로 시간 흐름) → 기능 모델링(자료 흐름도로 값의 변환) 순서로 진행합니다. 부치(Booch) 방법은 설계 문서화를 강조하고, 야콥슨의 OOSE는 유스케이스를 중심으로 분석합니다. UML은 이 세 사람의 표기를 통합하면서 출발했습니다.

분석 자동화 도구는 요구사항 분석과 명세 작업을 소프트웨어로 지원하는 도구로, 흔히 CASE(Computer-Aided Software Engineering) 도구라 부릅니다. 지원하는 생명주기 범위에 따라 계획·요구 분석·설계 단계를 돕는 상위 CASE, 코드 생성·테스트·문서화 같은 구현 단계를 돕는 하위 CASE, 전 과정을 연결하는 통합 CASE로 나눕니다. 다이어그램을 그리면 일관성 검사를 하고 문서를 자동으로 만들어 주므로 명세의 표준화와 유지보수가 쉬워집니다. 역사적으로 유명한 요구 분석 도구로 SADT(Douglas Ross와 SofTech가 개발한 구조적 분석·설계 기법, 미 공군 IDEF0의 바탕), PSL/PSA(미시간대학교 ISDOS 프로젝트에서 요구사항을 PSL로 기술하고 PSA로 분석), SREM(TRW가 대형 실시간 시스템용으로 개발, RSL 언어와 REVS 도구 사용)이 있습니다.

💻 예제로 확인하기 — 관계 표기를 코드로 읽기

클래스 다이어그램을 코드로 옮기면 관계의 차이가 분명해집니다. 아래 Java 코드는 주석에 표시한 대로 여섯 관계를 모두 담고 있습니다.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        Order o = new Order(new VipMember("kim"));
        o.add("book", 20000);
        o.add("pen", 3000);
        System.out.println("결제 금액: " + o.checkout(new CardPayment()));

        List<String> wish = new ArrayList<>(List.of("book", "pen"));
        Cart c = new Cart(wish);
        c = null;                       // 장바구니가 사라져도
        System.out.println("목록 유지: " + wish.size());
    }
}


interface Payable {                       // 인터페이스
    int pay(int amount);
}

class CardPayment implements Payable {    // 실현(realization)
    public int pay(int amount) { return amount; }
}

abstract class Member {                   // 일반화의 부모
    protected String name;
    Member(String name) { this.name = name; }
    abstract int discount(int price);
}

class VipMember extends Member {          // 일반화(generalization)
    VipMember(String name) { super(name); }
    int discount(int price) { return price * 90 / 100; }
}

class OrderLine {                         // 주문에 종속된 부분
    final String item; final int price;
    OrderLine(String item, int price) { this.item = item; this.price = price; }
}

class Order {
    private final Member buyer;                           // 연관(association)
    private final List<OrderLine> lines = new ArrayList<>(); // 합성(composition)

    Order(Member buyer) { this.buyer = buyer; }
    void add(String item, int price) { lines.add(new OrderLine(item, price)); }

    int checkout(Payable method) {                        // 의존(dependency)
        int sum = 0;
        for (OrderLine l : lines) sum += l.price;
        return method.pay(buyer.discount(sum));
    }
}

class Cart {
    private final List<String> picked;                    // 집합(aggregation)
    Cart(List<String> shared) { this.picked = shared; }
    int size() { return picked.size(); }
}

$ java Main.java
결제 금액: 20700
목록 유지: 2

읽는 순서는 이렇습니다. CardPayment implements Payable은 점선+빈 삼각형의 실현, VipMember extends Member는 실선+빈 삼각형의 일반화입니다. Order는 생성자에서 받은 Member를 필드로 계속 들고 있으므로 연관이고, OrderLine은 Order 안에서만 만들어져 주문과 운명을 같이하므로 합성(채운 마름모)입니다. checkout의 매개변수로 잠깐 쓰는 Payable은 필드로 저장하지 않으므로 의존입니다. 마지막으로 Cart는 밖에서 만든 목록을 넘겨받아 참조할 뿐이라 Cart가 사라져도 목록은 그대로 2개가 남습니다. 이것이 빈 마름모의 집합 관계입니다. 결제 금액은 23,000원에 VIP 10% 할인이 적용된 20,700원입니다.

⚠️ 시험에 나오는 함정

집합 vs 합성: 빈 마름모는 부분이 독립 생존(집합), 채운 마름모는 함께 소멸(합성). 마름모는 전체 쪽에 붙습니다.
일반화 vs 실현: 둘 다 빈 삼각형이지만 일반화는 실선, 실현은 점선입니다.
연관 vs 의존: 필드로 계속 참조하면 연관(실선), 매개변수·지역변수로 잠깐 쓰면 의존(점선).
include vs extend: 포함은 필수·기본→포함 방향, 확장은 선택·확장→기본 방향입니다.
상태 기호: 상태는 둥근 사각형이고 원이 아닙니다. 원 기호는 DFD의 프로세스입니다.
구조 vs 행위: 배치·컴포넌트·패키지는 구조, 활동·상태 머신·타이밍은 행위입니다.
OMT 순서: 객체 → 동적 → 기능. 기능 모델링에 DFD를 씁니다.

📝 핵심 요약 — 암기표

항목	암기 포인트
UML 구성	사물·관계·다이어그램, 현행판 2.5.1(OMG)
다이어그램	구조 7 + 행위 7(그중 상호작용 4) = 14종
관계 기호	연관 실선 / 집합 빈◇ / 합성 채운◆ / 일반화 실선△ / 실현 점선△ / 의존 점선→
유스케이스	include 필수(기본→포함), extend 선택(확장→기본)
구조적 분석	DFD·DD·Mini-Spec·ERD·STD
OMT	객체 → 동적 → 기능 모델링
CASE	상위(분석·설계), 하위(구현·테스트), 통합 / SADT·PSL/PSA·SREM

다음 강 「화면 설계 — UI 표준·지침·스토리보드·감성공학」에서는 분석한 요구를 사용자가 만나는 화면으로 옮기는 UI 원칙과 설계 도구를 다룹니다.

📋 실전 문제

UML 다이어그램 중 구조 다이어그램에 해당하는 것은?

① 시퀀스 다이어그램
② 배치 다이어그램
③ 상태 머신 다이어그램
④ 활동 다이어그램
「주문」이 삭제되면 그 주문의 「주문 항목」도 함께 사라질 때, 두 클래스 사이에 쓰는 관계 표기는?

① 실선 + 주문 항목 쪽 빈 마름모
② 점선 + 열린 화살표
③ 실선 + 주문 쪽 채운 마름모
④ 점선 + 빈 삼각형
클래스가 인터페이스를 구현하는 관계의 표기로 옳은 것은?

① 실선 + 빈 삼각형
② 실선 + 채운 마름모
③ 점선 + 열린 화살표
④ 점선 + 빈 삼각형
유스케이스 「결제하기」를 수행할 때 회원이 원하면 「포인트 사용」을 덧붙일 수 있다. 두 유스케이스의 관계로 옳은 것은?

① 「포인트 사용」이 「결제하기」를 확장(extend)한다.
② 「결제하기」가 「포인트 사용」을 포함(include)한다.
③ 「포인트 사용」이 「결제하기」를 일반화한다.
④ 두 유스케이스는 연관 관계로만 표현한다.
럼바우(Rumbaugh)의 OMT 분석 순서로 옳은 것은?

① 기능 모델링 → 동적 모델링 → 객체 모델링
② 동적 모델링 → 객체 모델링 → 기능 모델링
③ 객체 모델링 → 동적 모델링 → 기능 모델링
④ 객체 모델링 → 기능 모델링 → 동적 모델링
자료 사전(DD) 기호와 의미의 연결이 옳지 않은 것은?

① + : 자료의 연결
② { } : 자료의 반복
③ ( ) : 생략 가능한 자료
④ [ | ] : 주석
상태 머신 다이어그램의 표기로 옳지 않은 것은?

① 상태는 원으로 그린다.
② 시작 상태는 채운 원으로 그린다.
③ 전이에는 이벤트[가드]/동작 형식으로 적을 수 있다.
④ 종료 상태는 테두리를 두른 채운 원으로 그린다.
CASE 도구에 대한 설명으로 옳은 것은?

① 하위 CASE는 요구 분석과 설계 단계를 주로 지원한다.
② 상위 CASE는 요구 분석·설계 단계를, 하위 CASE는 코드 생성·테스트 단계를 주로 지원한다.
③ CASE 도구를 쓰면 다이어그램 간 일관성 검사가 불가능해진다.
④ PSL/PSA는 코드 자동 생성을 위한 하위 CASE 도구이다.

✅ 정답과 해설

정답 ② — 배치 다이어그램은 노드와 산출물의 물리적 배치를 그리는 구조 다이어그램입니다. ① 시퀀스는 상호작용(행위), ③ 상태 머신과 ④ 활동은 행위 다이어그램입니다.
정답 ③ — 부분의 생명주기가 전체에 종속되면 합성이고, 채운 마름모를 전체(주문) 쪽에 붙입니다. ①은 마름모 모양(빈 = 집합)과 위치(부분 쪽)가 모두 틀렸고, ②는 의존, ④는 실현입니다.
정답 ④ — 실현은 점선에 빈 삼각형을 인터페이스 쪽으로 그립니다. ①은 실선이므로 일반화(상속), ②는 합성, ③은 의존입니다.
정답 ① — 포인트 사용은 조건에 따라 덧붙는 선택 기능이므로 확장이고, 화살표는 확장 유스케이스(포인트 사용)에서 기본 유스케이스(결제하기)로 향합니다. ②의 포함은 매번 반드시 실행되는 경우에 쓰고, ③의 일반화는 「카드 결제」가 「결제하기」의 한 종류일 때처럼 is-a 관계에 씁니다. ④는 액터와 유스케이스를 잇는 방식입니다.
정답 ③ — OMT는 객체 다이어그램으로 정적 구조를 먼저 잡고, 상태 다이어그램으로 동적 측면을, 자료 흐름도로 기능을 모델링합니다. 나머지는 순서가 뒤바뀌었습니다.
정답 ④ — [ | ]는 여러 자료 중 하나를 고르는 택일입니다. 주석은 * *입니다. ①·②·③은 올바른 연결입니다.
정답 ① — UML에서 상태는 모서리가 둥근 사각형입니다. 원은 시작 상태(채운 원)나 DFD의 프로세스 기호와 혼동한 것입니다. ②·③·④는 맞는 표기입니다.
정답 ② — 상위 CASE는 생명주기 앞부분(계획·분석·설계), 하위 CASE는 뒷부분(코드 생성·테스트·문서화)을 지원합니다. ①은 상위와 하위를 바꿔 썼고, ③은 반대로 CASE의 대표 장점이 일관성 검사입니다. ④의 PSL/PSA는 요구사항을 기술·분석하는 도구라 하위 CASE가 아닙니다.

📚 참고 자료

OMG, Unified Modeling Language 2.5.1 (formal/17-12-05): https://www.omg.org/spec/UML/2.5.1/About-UML
D. Teichroew, E. A. Hershey, "PSL/PSA: A Computer-Aided Technique for Structured Documentation and Analysis of Information Processing Systems", IEEE Transactions on Software Engineering, 1977 — 서지: https://foldoc.org/PSL/PSA
TRW, Software Requirements Engineering Methodology 보고서(DTIC): https://apps.dtic.mil/sti/pdfs/ADA073132.pdf
IEEE Computer Society, Douglas T. Ross(SADT): https://history.computer.org/pioneers/ross.html
큐넷 정보처리기사 출제기준(2027.1.1~2029.12.31): https://www.q-net.or.kr/cst006.do?id=cst00601&code=1202

UML과 분석 모델 — 다이어그램·모델링 기법·분석 자동화 도구