UML 2.0으로 설계 의도를 공유하는 방법

설계 산출물을 공통 언어로 만드는 UML 2.0

UML 2.0은 소프트웨어 시스템을 시각적으로 설계하고 문서화하는 표준 모델링 언어다. 이전 버전보다 표현 범위가 확장됐으며, 복잡한 시스템을 여러 관점에서 기술할 수 있도록 구성돼 있다.

이 표기법은 다양한 도메인에서 활용할 수 있고, SDL과 MSC의 장점을 통합한다. MDA(Model Driven Architecture)를 지원해 플랫폼 독립적인 모델링에도 쓰이며, 타이밍 다이어그램을 통해 실시간 시스템을 표현하는 기능도 강화했다. 비즈니스 프로세스와 워크플로우 모델링 범위가 넓어졌고, 재사용 가능한 컴포넌트를 중심으로 한 설계도 지원한다.

호환성부터 표기법까지 이어지는 구성

UML 2.0은 다음 4가지 영역으로 나뉜다.

Data Interchange는 UML 도구 사이에서 모델을 교환하기 위한 호환성 표준을 제공한다.
**OCL(Object Constraint Language)**은 객체 제약조건을 형식적으로 표현하는 언어다.
Infrastructure는 UML의 기본 구조와 메타모델을 정의한다.
Superstructure는 사용자가 직접 다루는 다이어그램과 표기법을 정의한다.

이 구분은 모델 자체의 기반과 실제 모델링에 쓰이는 표현 방식을 분리해 이해하게 해준다.

모델을 정의하는 계층

UML 2.0은 모델링 개념을 4계층 메타모델 아키텍처로 정리한다.

⤢✕

M0은 실행 중인 객체와 데이터가 존재하는 수준이며, 코드 생성과 시스템 실행 단계에 해당한다. M1에는 개발자가 작성한 UML 다이어그램과 사용자 모델이 놓인다. M2는 클래스, 관계, 속성 같은 UML 요소의 정의를 담는 메타모델이고, M3는 M2 수준의 메타모델을 정의하는 MOF(Meta Object Facility)다.

시스템의 정적 모습을 표현하는 다이어그램

UML 2.0은 시스템을 여러 관점에서 모델링하기 위해 13가지 다이어그램을 제공한다. 그중 구조 다이어그램은 시스템의 정적 구성과 배치, 논리적 묶음을 다룬다.

⤢✕

클래스 다이어그램은 클래스와 관계를 통해 시스템의 정적 구조를 나타낸다. 객체 다이어그램은 특정 시점의 객체 인스턴스와 관계를 표현한다. 컴포넌트 다이어그램은 구성요소와 의존관계에 집중하고, 복합체 구조 다이어그램은 클래스 내부 구조와 상호작용을 보여준다.

패키지 다이어그램은 클래스와 요소를 논리적으로 그룹화한다. 배포 다이어그램은 실행 환경의 물리적 아키텍처를 표현하며, 프로파일 다이어그램은 UML 확장 메커니즘을 정의한다.

흐름과 상태를 추적하는 다이어그램

행위 다이어그램은 사용자와 시스템의 상호작용, 업무 흐름, 객체 상태 변화처럼 시스템이 동작하는 방식을 표현한다.

⤢✕

유스케이스 다이어그램은 시스템과 사용자 사이의 상호작용을, 액티비티 다이어그램은 워크플로우와 비즈니스 프로세스를 표현한다. 상태 머신 다이어그램은 객체의 상태 변화와 전이를 다룬다.

상호작용 다이어그램에는 시퀀스, 커뮤니케이션, 타이밍, 상호작용 개요 다이어그램이 포함된다. 시퀀스 다이어그램은 메시지 교환의 시간적 순서를, 커뮤니케이션 다이어그램은 객체 간 메시지 교환 관계를 나타낸다. 타이밍 다이어그램은 상태 변화의 시간적 제약을 표현하고, 상호작용 개요 다이어그램은 복잡한 상호작용의 전체 윤곽을 보여준다.

금융과 임베디드 시스템에서의 모델링 관점

대형 은행의 온라인 뱅킹 시스템을 설계할 때는 계좌, 거래, 고객의 데이터 모델을 클래스 다이어그램으로 표현할 수 있다. 송금과 결제 트랜잭션 흐름에는 시퀀스 다이어그램이 맞고, 계좌의 개설·활성·휴면·폐쇄 상태 변화는 상태 다이어그램으로 모델링할 수 있다. 서버, 데이터베이스, 클라이언트의 물리적 아키텍처는 배포 다이어그램으로 설계한다.

자동차 제어 시스템 같은 실시간 임베디드 환경에서는 센서 데이터 처리의 타이밍 제약을 타이밍 다이어그램으로 다룬다. 엔진 제어 상태 전이는 상태 머신 다이어그램으로, 모듈화된 제어 시스템의 구성은 컴포넌트 다이어그램으로 표현할 수 있다. 제어 알고리즘의 흐름에는 액티비티 다이어그램을 적용한다.

모델링 품질을 지키는 원칙

UML을 협업의 도구로 쓰려면 표준 준수와 모델의 일관성을 확보해야 한다. 설계 패턴과 아키텍처 패턴을 적용하되, 목적을 넘는 상세화는 피하고 필요한 수준의 단순성을 유지한다.

요구사항부터 구현까지 추적성을 확보하고, 도메인 특화가 필요하면 프로파일을 활용한다. 모델은 이해관계자 사이의 의사소통 수단이므로 의미가 명확해야 하며, 팀 안에서는 표준화된 모델링 관행을 함께 정할 필요가 있다.

코드와 함께 유지하는 UML

프로젝트의 모든 다이어그램을 작성할 필요는 없다. 설계 검토, 구현 협업, 운영 인수처럼 현재 목적에 필요한 다이어그램을 선택하는 편이 낫다. 다이어그램 사이의 추상화 수준도 맞춰야 서로 다른 모델이 충돌하지 않는다.

처음부터 완성된 모델을 만들기보다 반복적으로 개선하는 방식이 적합하다. Enterprise Architect, Visual Paradigm, IBM Rational Rose 같은 UML 도구를 사용할 수 있으며, 모델 변경 이력을 관리하면 팀 협업에 도움이 된다. 다이어그램만으로 설명이 충분하지 않은 부분은 문서화도 병행해야 한다.

UML은 코드 변경 뒤 모델이 갱신되지 않으면 빠르게 신뢰를 잃는다. 모델과 코드의 불일치를 관리하고, 빠른 개발 주기와 상세 모델링 사이에서 균형을 잡는 일이 필요하다. 13개 다이어그램과 복잡한 표기법에는 학습 시간이 들며, 도구별 지원 기능과 UI 차이도 운영상의 부담이 될 수 있다.