UML 다이어그램 상세 가이드
목차
- 클래스 다이어그램
- 시퀀스 다이어그램
- 유스케이스 다이어그램
- 액티비티 다이어그램
- 상태 다이어그램
- 컴포넌트 다이어그램
- 배치 다이어그램
- 객체 다이어그램
- 패키지 다이어그램
- 커뮤니케이션 다이어그램
- 타이밍 다이어그램
- 인터랙션 오버뷰 다이어그램
- 컴포지트 구조 다이어그램
- 프로파일 다이어그램
클래스 다이어그램
개념
클래스 다이어그램은 시스템의 정적 구조를 표현하는 UML 다이어그램입니다. 클래스, 인터페이스, 속성, 메서드, 그리고 클래스 간의 관계(상속, 구현, 연관, 의존 등)를 시각적으로 표현합니다.
주요 구성 요소
- 클래스: 이름, 속성(필드), 메서드(오퍼레이션)로 구성된 3구획 박스
- 인터페이스: 구현해야 할 계약을 정의
- 관계:
- 상속(Generalization): 실선 화살표
- 구현(Realization): 점선 화살표
- 연관(Association): 실선
- 의존(Dependency): 점선 화살표
- 집합(Aggregation): 빈 다이아몬드
- 합성(Composition): 채워진 다이아몬드
- 가시성: + (public), - (private), # (protected), ~ (package)
- 다중성: 1, , 0..1, 1.. 등
사용하는 곳
- 객체지향 소프트웨어 설계: 시스템의 클래스 구조 설계
- 데이터 모델링: 도메인 모델 설계
- API 설계: 인터페이스와 클래스 계층 구조 정의
- 리팩토링 계획: 코드 구조 개선 전 현재 구조 파악
- 시스템 문서화: 기존 시스템의 구조 이해
어디에 사용하면 유리한지
✅ 대규모 프로젝트: 여러 개발자가 협업할 때 공통 이해를 위한 설계 문서
✅ 복잡한 도메인: 비즈니스 로직이 복잡하고 클래스 간 관계가 많은 경우
✅ 상속 구조가 중요한 경우: 프레임워크나 라이브러리 설계
✅ 리팩토링이 필요한 레거시 코드: 기존 코드 구조 파악
✅ 교육 및 온보딩: 신규 개발자에게 시스템 구조 설명
✅ 설계 리뷰: 아키텍처 결정을 논의할 때
✅ 코드 생성: UML 모델에서 코드 자동 생성이 필요한 경우
어떤 경우에는 과한 경우인지
❌ 간단한 스크립트나 유틸리티: 클래스가 1~2개인 작은 프로그램
❌ 프로토타입 단계: 빠르게 변경되는 초기 개발 단계
❌ 단순한 CRUD 애플리케이션: 복잡한 관계가 없는 경우
❌ 함수형 프로그래밍 중심: 클래스보다 함수가 중심인 경우
❌ 마이크로서비스의 작은 서비스: 단일 책임만 가진 작은 서비스
❌ 임시 스크립트: 일회성 코드
개발 문서에 포함될 경우
- 시스템 설계서 (System Design Document): 전체 시스템 구조 설명
- 아키텍처 문서 (Architecture Document): 소프트웨어 아키텍처의 정적 구조
- API 설계서: 인터페이스와 클래스 계약 정의
- 도메인 모델 문서: 비즈니스 도메인 모델링
- 코드 리뷰 가이드: 코드 구조 이해를 위한 참고 자료
- 개발 가이드: 개발자가 참조할 설계 문서
- 온보딩 문서: 신규 개발자 교육 자료
시퀀스 다이어그램
개념
시퀀스 다이어그램은 객체 간의 상호작용을 시간 순서대로 표현하는 UML 다이어그램입니다. 메시지가 전송되는 순서와 객체의 생명주기를 시각화하여 시스템의 동적 동작을 표현합니다.
주요 구성 요소
- 액터/객체: 수직 라인(Lifeline)으로 표현
- 생명선: 객체가 존재하는 기간을 점선으로 표현
- 활성화 박스: 객체가 실행 중인 구간을 박스로 표현
- 메시지: 객체 간 전송되는 메시지를 화살표로 표현
- 동기 메시지: 실선 화살표
- 비동기 메시지: 점선 화살표
- 반환 메시지: 점선 화살표
- 조각(Fragment):
- alt: 조건부 분기
- loop: 반복
- opt: 선택적 실행
- par: 병렬 실행
사용하는 곳
- API 설계: REST API나 RPC 호출 흐름 설계
- 시스템 상호작용 분석: 마이크로서비스 간 통신 흐름
- 트랜잭션 처리: 데이터베이스 트랜잭션 흐름
- 인증/인가 프로세스: 사용자 인증 과정
- 에러 처리 시나리오: 예외 상황 처리 흐름
- 통합 테스트 설계: 시스템 간 상호작용 테스트 케이스 작성
어디에 사용하면 유리한지
✅ 복잡한 상호작용: 여러 객체가 순차적으로 상호작용하는 경우
✅ 비동기 처리: 비동기 메시지나 이벤트 기반 시스템
✅ 분산 시스템: 마이크로서비스나 분산 시스템의 통신 흐름
✅ 트랜잭션 관리: 복잡한 트랜잭션 흐름이 있는 경우
✅ API 문서화: API 사용 예제와 흐름 설명
✅ 디버깅: 복잡한 버그의 원인 파악
✅ 성능 분석: 병목 지점 식별
어떤 경우에는 과한 경우인지
❌ 단순한 함수 호출: 1:1 단순 호출만 있는 경우
❌ 동기적 단일 흐름: 순차적이고 단순한 처리
❌ 이벤트 기반 단순 시스템: 단순 이벤트 핸들러만 있는 경우
❌ 정적 페이지: 상호작용이 없는 정적 웹사이트
❌ 배치 작업: 단순한 순차 처리만 있는 경우
개발 문서에 포함될 경우
- API 문서: API 호출 흐름과 예제
- 시스템 통합 문서: 시스템 간 상호작용 설명
- 아키텍처 문서: 동적 동작 시나리오
- 테스트 계획서: 통합 테스트 시나리오
- 운영 가이드: 트러블슈팅을 위한 상호작용 흐름
- 개발 가이드: 개발자가 따라야 할 상호작용 패턴
유스케이스 다이어그램
개념
유스케이스 다이어그램은 시스템의 기능과 사용자(액터)의 상호작용을 표현하는 UML 다이어그램입니다. 시스템이 제공하는 기능을 사용자 관점에서 표현하여 요구사항을 명확히 합니다.
주요 구성 요소
- 액터: 시스템과 상호작용하는 사용자나 외부 시스템 (막대인형)
- 유스케이스: 시스템이 제공하는 기능 (타원형)
- 시스템 경계: 시스템의 범위를 나타내는 사각형
- 관계:
- 연관: 액터와 유스케이스 간의 상호작용
- 포함(Include): 필수적으로 포함되는 유스케이스
- 확장(Extend): 조건부로 확장되는 유스케이스
- 일반화: 액터나 유스케이스의 상속 관계
사용하는 곳
- 요구사항 분석: 시스템이 제공해야 할 기능 정의
- 프로젝트 기획: 초기 단계에서 기능 범위 정의
- 사용자 스토리 작성: 사용자 관점의 기능 정의
- 테스트 케이스 작성: 기능 테스트 범위 정의
- 시스템 범위 정의: 프로젝트 범위 명확화
- 이해관계자 소통: 비기술자와의 소통 도구
어디에 사용하면 유리한지
✅ 프로젝트 초기 단계: 요구사항 수집 및 분석
✅ 복잡한 비즈니스 로직: 다양한 사용자 역할과 기능이 있는 경우
✅ 이해관계자 소통: 비기술자와의 소통이 중요한 경우
✅ 대규모 시스템: 많은 기능과 사용자 유형이 있는 경우
✅ 제품 기획: 제품 기능 정의 및 우선순위 결정
✅ 문서화: 시스템 기능을 명확히 문서화해야 하는 경우
✅ 계약서 작성: 개발 범위를 명확히 해야 하는 경우
어떤 경우에는 과한 경우인지
❌ 기술적 프로토타입: 기능보다 기술 검증이 목적인 경우
❌ 내부 도구: 사용자가 개발팀뿐인 경우
❌ 단순한 유틸리티: 기능이 매우 단순한 경우
❌ 레거시 시스템 개선: 기존 시스템의 일부만 개선하는 경우
❌ 인프라 구성: 사용자 상호작용이 없는 인프라 작업
개발 문서에 포함될 경우
- 요구사항 명세서 (Requirements Specification): 기능 요구사항 정의
- 시스템 명세서: 시스템 기능 범위
- 프로젝트 계획서: 프로젝트 범위 정의
- 테스트 계획서: 테스트 범위 정의
- 사용자 매뉴얼: 시스템 기능 개요
- 제품 기획서: 제품 기능 정의
액티비티 다이어그램
개념
액티비티 다이어그램은 비즈니스 프로세스나 알고리즘의 활동 흐름을 표현하는 UML 다이어그램입니다. 워크플로우, 비즈니스 프로세스, 알고리즘의 단계와 분기를 표현합니다.
주요 구성 요소
- 액티비티: 수행되는 작업 (둥근 사각형)
- 시작 노드: 프로세스 시작 (검은 원)
- 종료 노드: 프로세스 종료 (이중 원)
- 결정점: 조건 분기 (다이아몬드)
- 포크/조인: 병렬 처리 (가로선)
- 병합: 여러 흐름을 하나로 합침
- 스윔레인: 역할이나 책임자 구분
- 객체 노드: 데이터나 객체
사용하는 곳
- 비즈니스 프로세스 모델링: 업무 프로세스 정의
- 알고리즘 설계: 복잡한 알고리즘의 흐름 표현
- 워크플로우 설계: 작업 흐름 정의
- 승인 프로세스: 다단계 승인 프로세스
- 데이터 처리 파이프라인: ETL 프로세스
- 상태 머신 설계: 복잡한 상태 전이
어디에 사용하면 유리한지
✅ 복잡한 비즈니스 로직: 여러 단계와 조건이 있는 프로세스
✅ 병렬 처리: 동시에 실행되는 작업이 있는 경우
✅ 다단계 프로세스: 여러 단계를 거치는 프로세스
✅ 승인 워크플로우: 여러 승인자가 있는 경우
✅ 데이터 파이프라인: 데이터 변환 단계가 많은 경우
✅ 상태 전이가 복잡한 경우: 여러 상태와 전이 조건
✅ 프로세스 개선: 기존 프로세스 분석 및 개선
어떤 경우에는 과한 경우인지
❌ 단순한 순차 처리: 단순히 순차적으로 실행되는 경우
❌ 간단한 조건문: if-else 정도의 단순 분기
❌ 단일 함수: 하나의 함수 내부 로직만 표현하는 경우
❌ 정적 페이지: 동적 프로세스가 없는 경우
개발 문서에 포함될 경우
- 비즈니스 프로세스 문서: 업무 프로세스 정의
- 시스템 설계서: 비즈니스 로직 흐름
- 알고리즘 문서: 알고리즘 설계 및 설명
- 워크플로우 문서: 작업 흐름 정의
- 운영 매뉴얼: 프로세스 실행 가이드
- 테스트 계획서: 프로세스 테스트 시나리오
상태 다이어그램
개념
상태 다이어그램(State Machine Diagram)은 객체의 상태 변화와 전이를 표현하는 UML 다이어그램입니다. 객체가 가질 수 있는 상태와 상태 간 전이 조건, 이벤트를 표현합니다.
주요 구성 요소
- 상태: 객체의 상태 (둥근 사각형)
- 초기 상태: 시작 상태 (검은 원)
- 최종 상태: 종료 상태 (이중 원)
- 전이: 상태 간 변화 (화살표)
- 이벤트: 전이를 유발하는 이벤트
- 가드 조건: 전이 조건
- 액션: 상태 진입/종료 시 실행되는 액션
- 하위 상태: 복합 상태 내부의 상태
사용하는 곳
- 상태 머신 설계: 복잡한 상태 관리가 필요한 시스템
- 워크플로우 엔진: 작업 상태 관리
- 주문 처리 시스템: 주문 상태 관리
- 인증 시스템: 사용자 인증 상태
- 장치 제어: 하드웨어 장치 상태 관리
- 게임 개발: 게임 오브젝트 상태
- 프로토콜 설계: 통신 프로토콜 상태
어디에 사용하면 유리한지
✅ 상태가 많은 경우: 여러 상태와 전이가 있는 경우
✅ 상태 전이 로직이 복잡한 경우: 조건부 전이가 많은 경우
✅ 상태 기반 시스템: 상태가 시스템 동작의 핵심인 경우
✅ 이벤트 기반 시스템: 이벤트에 따라 상태가 변경되는 경우
✅ 유한 상태 머신: FSM을 구현해야 하는 경우
✅ 상태 관리가 중요한 비즈니스: 주문, 승인 등 상태가 중요한 경우
어떤 경우에는 과한 경우인지
❌ 상태가 없는 객체: 상태가 없는 순수 함수형 객체
❌ 단순한 boolean 상태: on/off 정도의 단순 상태
❌ 상태가 명확하지 않은 경우: 상태 개념이 모호한 경우
❌ 일회성 처리: 상태 전이가 없는 일회성 작업
개발 문서에 포함될 경우
- 시스템 설계서: 상태 관리 로직
- 상태 머신 명세서: 상태 전이 규칙
- API 문서: 상태 기반 API의 상태 전이
- 프로토콜 문서: 통신 프로토콜의 상태 머신
- 비즈니스 로직 문서: 비즈니스 상태 관리
- 테스트 계획서: 상태 전이 테스트 케이스
컴포넌트 다이어그램
개념
컴포넌트 다이어그램은 시스템의 물리적 컴포넌트와 인터페이스를 표현하는 UML 다이어그램입니다. 재사용 가능한 컴포넌트와 그들 간의 의존성을 표현합니다.
주요 구성 요소
- 컴포넌트: 재사용 가능한 모듈 (직사각형, 컴포넌트 아이콘)
- 인터페이스:
- 제공 인터페이스: 원 (lollipop)
- 요구 인터페이스: 반원 (socket)
- 의존성: 점선 화살표
- 포트: 컴포넌트의 상호작용 지점
- 아티팩트: 구현 파일
사용하는 곳
- 모듈화 설계: 시스템을 모듈로 분해
- 컴포넌트 기반 개발: 재사용 가능한 컴포넌트 설계
- 마이크로서비스 아키텍처: 서비스 간 의존성
- 라이브러리 설계: 라이브러리 구조
- 플러그인 시스템: 플러그인 아키텍처
- 시스템 통합: 시스템 간 인터페이스 정의
어디에 사용하면 유리한지
✅ 대규모 시스템: 여러 모듈로 구성된 시스템
✅ 재사용이 중요한 경우: 컴포넌트 재사용이 핵심인 경우
✅ 마이크로서비스: 여러 서비스로 구성된 시스템
✅ 플러그인 아키텍처: 확장 가능한 시스템
✅ 라이브러리 개발: 재사용 가능한 라이브러리
✅ 시스템 통합: 여러 시스템을 통합하는 경우
✅ 모듈 간 의존성 관리: 의존성 구조가 복잡한 경우
어떤 경우에는 과한 경우인지
❌ 단일 모듈 애플리케이션: 하나의 모듈만 있는 경우
❌ 모놀리식 작은 애플리케이션: 단순한 구조의 경우
❌ 스크립트: 일회성 스크립트
❌ 프로토타입: 빠르게 변경되는 초기 단계
개발 문서에 포함될 경우
- 시스템 아키텍처 문서: 컴포넌트 구조
- 모듈 설계서: 모듈 구조 및 인터페이스
- API 문서: 컴포넌트 인터페이스
- 통합 문서: 시스템 통합 구조
- 라이브러리 문서: 라이브러리 구조 및 사용법
배치 다이어그램
개념
배치 다이어그램(Deployment Diagram)은 하드웨어 노드와 소프트웨어 아티팩트의 배치를 표현하는 UML 다이어그램입니다. 시스템이 물리적으로 어떻게 배치되는지 표현합니다.
주요 구성 요소
- 노드: 하드웨어 장치나 실행 환경 (입방체)
- 디바이스: 물리적 하드웨어
- 실행 환경: 소프트웨어 실행 환경 (JVM, 컨테이너 등)
- 아티팩트: 소프트웨어 파일 (문서 아이콘)
- 컴포넌트 인스턴스: 실행 중인 컴포넌트
- 연결: 노드 간 통신 경로
- 스테레오타입: <
>, < > 등
사용하는 곳
- 인프라 설계: 하드웨어 및 소프트웨어 배치 계획
- 배포 계획: 애플리케이션 배포 구조
- 클라우드 아키텍처: 클라우드 리소스 배치
- 분산 시스템: 분산 환경의 배치
- 컨테이너 오케스트레이션: Kubernetes 등 배치 구조
- 하드웨어 요구사항: 필요한 하드웨어 스펙 정의
어디에 사용하면 유리한지
✅ 분산 시스템: 여러 서버에 배치되는 시스템
✅ 클라우드 배포: 클라우드 인프라 설계
✅ 마이크로서비스: 여러 서비스의 배치 구조
✅ 하이브리드 클라우드: 온프레미스와 클라우드 혼합
✅ 고가용성 시스템: 장애 대비 배치 구조
✅ 보안 요구사항이 높은 경우: 네트워크 분리 등
✅ 용량 계획: 리소스 배치 계획
어떤 경우에는 과한 경우인지
❌ 단일 서버 배포: 하나의 서버에만 배치되는 경우
❌ 로컬 개발 환경: 개발자 로컬 환경
❌ 간단한 웹 애플리케이션: 단순한 배치 구조
❌ SaaS 서비스: 배치 구조가 명확하지 않은 경우
개발 문서에 포함될 경우
- 인프라 설계서: 인프라 구조 및 배치
- 배포 문서: 배포 구조 및 절차
- 운영 매뉴얼: 시스템 배치 구조
- 하드웨어 요구사항 문서: 필요한 하드웨어 스펙
- 보안 설계서: 네트워크 및 보안 구조
- 재해 복구 계획: 백업 및 복구 구조
객체 다이어그램
개념
객체 다이어그램은 특정 시점의 객체 인스턴스와 그들 간의 링크를 표현하는 UML 다이어그램입니다. 클래스 다이어그램의 인스턴스 뷰로, 런타임의 객체 상태를 표현합니다.
주요 구성 요소
- 객체: 박스 (이름:클래스 형식)
- 속성 값: 객체의 속성과 실제 값
- 링크: 객체 간의 연결 (연관의 인스턴스)
- 다중성: 객체의 개수
- 상태: 객체의 현재 상태
사용하는 곳
- 시나리오 분석: 특정 시나리오에서의 객체 상태
- 테스트 케이스 설계: 테스트 시나리오의 객체 상태
- 디버깅: 특정 시점의 객체 상태 확인
- 프로토타입 검증: 설계 검증
- 예제 설명: 클래스 다이어그램의 구체적 예제
어디에 사용하면 유리한지
✅ 복잡한 객체 관계: 여러 객체가 복잡하게 연결된 경우
✅ 시나리오 기반 설계: 특정 시나리오 검증
✅ 테스트 설계: 테스트 케이스의 객체 상태
✅ 설계 검증: 클래스 다이어그램의 검증
✅ 교육 자료: 구체적인 예제 설명
어떤 경우에는 과한 경우인지
❌ 단순한 객체: 객체가 적고 관계가 단순한 경우
❌ 일반적인 설계: 특정 시나리오가 아닌 일반 설계
❌ 프로토타입 단계: 빠르게 변경되는 초기 단계
개발 문서에 포함될 경우
- 시스템 설계서: 설계 예제 및 시나리오
- 테스트 계획서: 테스트 시나리오의 객체 상태
- 개발 가이드: 객체 사용 예제
- 교육 자료: 객체 관계 이해를 위한 예제
패키지 다이어그램
개념
패키지 다이어그램은 패키지와 그들 간의 의존성을 표현하는 UML 다이어그램입니다. 시스템의 모듈 구조와 네임스페이스를 표현합니다.
주요 구성 요소
- 패키지: 폴더 아이콘 또는 탭이 있는 폴더
- 의존성: 점선 화살표
- 네임스페이스: 계층적 구조
- 가시성: public, private, protected
- 패키지 병합: 패키지 통합
- 패키지 가져오기: 다른 패키지의 요소 사용
사용하는 곳
- 모듈 구조 설계: 시스템을 모듈로 분해
- 네임스페이스 설계: 코드 조직화
- 의존성 관리: 모듈 간 의존성 관리
- 리팩토링: 패키지 구조 개선
- 아키텍처 설계: 계층적 아키텍처
어디에 사용하면 유리한지
✅ 대규모 프로젝트: 많은 패키지로 구성된 프로젝트
✅ 계층적 아키텍처: 레이어드 아키텍처
✅ 의존성 관리가 중요한 경우: 순환 의존성 방지
✅ 리팩토링: 기존 구조 개선
✅ 코드 조직화: 코드 구조 설계
어떤 경우에는 과한 경우인지
❌ 작은 프로젝트: 패키지가 적은 경우
❌ 단순한 구조: 단순한 폴더 구조
❌ 스크립트: 일회성 스크립트
개발 문서에 포함될 경우
- 시스템 아키텍처 문서: 모듈 구조
- 코드 구조 문서: 패키지 구조
- 개발 가이드: 코드 조직화 가이드
- 리팩토링 계획: 구조 개선 계획
커뮤니케이션 다이어그램
개념
커뮤니케이션 다이어그램(Communication Diagram, 협업 다이어그램)은 객체 간의 관계와 메시지 교환을 표현하는 UML 다이어그램입니다. 시퀀스 다이어그램과 유사하지만 객체 관계를 더 강조합니다.
주요 구성 요소
- 객체: 박스
- 링크: 객체 간의 연결선
- 메시지: 번호가 매겨진 화살표
- 순서 번호: 메시지 순서
- 다중성: 객체 수
사용하는 곳
- 객체 협력 분석: 객체 간 협력 관계
- 설계 패턴 설명: 디자인 패턴의 객체 협력
- 시퀀스 다이어그램 대안: 관계 중심 표현이 필요한 경우
어디에 사용하면 유리한지
✅ 객체 관계가 중요한 경우: 관계 구조를 강조해야 하는 경우
✅ 설계 패턴 설명: 패턴의 객체 협력
✅ 복잡한 객체 네트워크: 객체 간 복잡한 관계
어떤 경우에는 과한 경우인지
❌ 시간 순서가 중요한 경우: 시퀀스 다이어그램이 더 적합
❌ 단순한 상호작용: 단순한 호출만 있는 경우
개발 문서에 포함될 경우
- 시스템 설계서: 객체 협력 구조
- 디자인 패턴 문서: 패턴 적용 예제
- 아키텍처 문서: 객체 관계 구조
타이밍 다이어그램
개념
타이밍 다이어그램은 시간 제약 조건이 중요한 상호작용을 표현하는 UML 다이어그램입니다. 시간축을 사용하여 상태 변화와 이벤트 타이밍을 표현합니다.
주요 구성 요소
- 생명선: 수평선 (시간축)
- 상태: 상태 구간
- 시간 제약: 시간 표시
- 메시지: 화살표
- 제약: 시간 제약 조건
사용하는 곳
- 실시간 시스템: 시간 제약이 중요한 시스템
- 하드웨어 인터페이스: 하드웨어 통신 프로토콜
- 성능 분석: 시간 제약 분석
- 프로토콜 설계: 통신 프로토콜의 타이밍
어디에 사용하면 유리한지
✅ 실시간 시스템: 시간 제약이 중요한 경우
✅ 하드웨어 통신: 타이밍이 중요한 통신
✅ 성능 요구사항: 시간 제약이 명확한 경우
✅ 프로토콜 설계: 통신 프로토콜 설계
어떤 경우에는 과한 경우인지
❌ 일반적인 소프트웨어: 시간 제약이 없는 경우
❌ 비즈니스 애플리케이션: 시간 제약이 중요하지 않은 경우
개발 문서에 포함될 경우
- 시스템 설계서: 실시간 요구사항
- 프로토콜 문서: 통신 프로토콜 타이밍
- 성능 요구사항 문서: 시간 제약 조건
- 하드웨어 인터페이스 문서: 하드웨어 통신 타이밍
인터랙션 오버뷰 다이어그램
개념
인터랙션 오버뷰 다이어그램은 여러 인터랙션 다이어그램을 조합하여 전체 흐름을 표현하는 UML 다이어그램입니다. 액티비티 다이어그램과 시퀀스 다이어그램의 조합 형태입니다.
주요 구성 요소
- 인터랙션 발생: 프레임
- 제어 흐름: 화살표
- 결정점: 다이아몬드
- 병렬 처리: 포크/조인
사용하는 곳
- 복잡한 상호작용: 여러 상호작용을 조합해야 하는 경우
- 전체 흐름 개요: 복잡한 프로세스의 개요
- 시나리오 조합: 여러 시나리오를 하나로 통합
어디에 사용하면 유리한지
✅ 복잡한 프로세스: 여러 상호작용이 조합된 경우
✅ 전체 흐름 이해: 복잡한 시스템의 전체 흐름
✅ 시나리오 통합: 여러 시나리오를 통합 표현
어떤 경우에는 과한 경우인지
❌ 단순한 상호작용: 단순한 흐름만 있는 경우
❌ 일반적인 설계: 복잡한 조합이 필요 없는 경우
개발 문서에 포함될 경우
- 시스템 설계서: 복잡한 프로세스 개요
- 아키텍처 문서: 전체 상호작용 흐름
- 시나리오 문서: 통합 시나리오
컴포지트 구조 다이어그램
개념
컴포지트 구조 다이어그램은 클래스의 내부 구조와 구성 요소를 표현하는 UML 다이어그램입니다. 복합 클래스의 내부 구조를 상세히 표현합니다.
주요 구성 요소
- 컴포지트: 외부 박스
- 파트: 내부 구성 요소
- 포트: 인터페이스 포인트
- 커넥터: 내부 연결
- 인터페이스: 제공/요구 인터페이스
사용하는 곳
- 복합 클래스 설계: 내부 구조가 복잡한 클래스
- 컴포넌트 설계: 컴포넌트의 내부 구조
- 인터페이스 설계: 포트 기반 인터페이스
어디에 사용하면 유리한지
✅ 복잡한 클래스: 내부 구조가 복잡한 경우
✅ 컴포넌트 기반 설계: 컴포넌트 내부 구조
✅ 포트 기반 인터페이스: 포트를 사용하는 설계
어떤 경우에는 과한 경우인지
❌ 단순한 클래스: 내부 구조가 단순한 경우
❌ 일반적인 설계: 복합 구조가 필요 없는 경우
개발 문서에 포함될 경우
- 시스템 설계서: 복합 클래스 구조
- 컴포넌트 설계서: 컴포넌트 내부 구조
- 인터페이스 문서: 포트 기반 인터페이스
프로파일 다이어그램
개념
프로파일 다이어그램은 UML 확장 메커니즘을 표현하는 UML 다이어그램입니다. 도메인 특화 모델링을 위해 UML을 확장합니다.
주요 구성 요소
- 프로파일: 패키지
- 스테레오타입: 확장 타입
- 태그 값: 추가 속성
- 제약 조건: 규칙
- 메타클래스: 확장 대상
사용하는 곳
- 도메인 특화 모델링: 특정 도메인을 위한 UML 확장
- DSL 정의: 도메인 특화 언어 정의
- 메타모델링: 메타모델 정의
어디에 사용하면 유리한지
✅ 도메인 특화 모델링: 특정 도메인을 위한 확장
✅ DSL 개발: 도메인 특화 언어 개발
✅ 표준 확장: UML을 특정 목적으로 확장
어떤 경우에는 과한 경우인지
❌ 일반적인 모델링: 표준 UML로 충분한 경우
❌ 소규모 프로젝트: 확장이 필요 없는 경우
개발 문서에 포함될 경우
- 메타모델 문서: 확장된 UML 메타모델
- DSL 문서: 도메인 특화 언어 정의
- 모델링 가이드: 확장된 UML 사용 가이드
UML 다이어그램 선택 가이드
프로젝트 단계별 추천
요구사항 분석 단계
- 유스케이스 다이어그램: 기능 정의
- 액티비티 다이어그램: 비즈니스 프로세스
설계 단계
- 클래스 다이어그램: 정적 구조
- 시퀀스 다이어그램: 동적 상호작용
- 상태 다이어그램: 상태 관리
- 컴포넌트 다이어그램: 모듈 구조
구현 단계
- 클래스 다이어그램: 코드 구조
- 시퀀스 다이어그램: API 설계
- 객체 다이어그램: 시나리오 검증
배포 단계
- 배치 다이어그램: 배치 구조
도구 추천
- PlantUML: 텍스트 기반 UML 생성
- Lucidchart: 웹 기반 다이어그램 도구
- Draw.io: 무료 다이어그램 도구
- Enterprise Architect: 전문 UML 도구
- Visual Paradigm: 통합 모델링 도구
참고 자료
- UML 2.5 Specification (OMG)
- “UML Distilled” by Martin Fowler
- PlantUML Documentation
- 각 다이어그램별 상세 명세서