이 문서의 과거 버전 (r1)을 보고 있습니다. 수정일: 2026.02.14 23:09
UML(Unified Modeling Language)은 소프트웨어 공학에서 시스템의 구조, 설계, 행위를 시각적으로 표현하기 위해 사용되는 표준화된 모델링 언어이다. 주로 객체 지향 프로그래밍과 소프트웨어 개발 과정에서 시스템의 청사진을 만들고 의사소통을 돕는 도구로 활용된다. UML은 특정 프로그래밍 언어나 개발 방법론에 종속되지 않는 일반적인 언어로서, 복잡한 시스템을 추상화하여 다이어그램으로 표현하는 데 중점을 둔다.
UML의 주요 목적은 시스템에 대한 이해를 공유하는 것이다. 개발자, 분석가, 이해관계자 등 다양한 역할 간에 시스템의 요구사항, 설계, 아키텍처를 명확하고 모호함 없이 전달할 수 있게 해준다. 이를 통해 개발 초기 단계에서의 오류를 줄이고, 유지보수를 용이하게 하며, 문서화의 표준을 제공한다.
UML은 크게 시스템의 정적인 구조를 보여주는 구조 다이어그램과 동적인 행위를 보여주는 행위 다이어그램으로 분류되는 여러 다이어그램을 포함한다. 대표적인 다이어그램으로는 클래스 다이어그램, 시퀀스 다이어그램, 유스케이스 다이어그램, 활동 다이어그램 등이 있다. 이러한 다이어그램들은 각기 다른 관점에서 시스템을 묘사하여 전체적인 이해를 돕는다.
UML은 OMG(Object Management Group)에 의해 표준으로 관리되며, 지속적으로 개정되고 확장되고 있다. 현재는 소프트웨어 시스템뿐만 아니라 비즈니스 프로세스 모델링, 시스템 엔지니어링 등 더 넓은 범위의 모델링에도 적용되고 있다.
UML의 역사는 1990년대 중반으로 거슬러 올라간다. 당시 객체 지향 분석 및 설계 방법론 분야는 그래디 부치, 제임스 럼바우, 아이바 야콥슨 등 여러 유력한 방법론 학자들이 각기 다른 표기법과 방법론을 제시하며 분열된 상태였다. 이로 인해 소프트웨어 개발자들 사이에는 방법론 전쟁이 벌어지기도 했다. 이러한 혼란을 해결하고 표준화된 모델링 언어의 필요성이 대두되면서, 세 방법론 학자는 협력하여 통합 방법론을 만들기로 합의했다.
1994년부터 1996년까지 이들은 각자의 방법론(부치 방법, OMT, OOSE)의 장점을 통합한 초안을 만들어냈고, 이를 Rational Software 회사에 제안했다. 이 통합 작업의 결과물이 바로 1996년에 발표된 UML 0.9와 0.91이다. 이후 이 표준화 작업은 객체 관리 그룹(OMG)에 이관되어 공식적인 표준화 절차를 밟게 되었다.
1997년, OMG는 UML 1.1을 공식 표준으로 채택하여 발표했다. 이는 UML 역사상 첫 번째 주요 공식 버전이었다. 이후 지속적인 개선을 통해 UML 1.x 시리즈(1.2, 1.3, 1.4, 1.5)가 이어졌다. 2005년에는 큰 변화를 수반한 UML 2.0이 발표되었는데, 이 버전에서는 시퀀스 다이어그램과 활동 다이어그램 등 여러 다이어그램의 표현력이 크게 향상되고 정형화되었다. UML 2.x 시리즈는 현재까지도 유효한 최신 표준으로, 2.4.1, 2.5, 2.5.1 등의 부 버전으로 발전을 거듭하고 있다.
UML의 발전 과정은 표준화 기구인 OMG의 관리 하에 공개 리뷰와 합의를 거치는 개방적인 과정을 통해 이루어졌다. 이는 UML이 특정 벤더나 방법론에 종속되지 않고, 산업계와 학계의 광범위한 요구를 반영하는 진정한 공개 표준으로 자리 잡는 데 기여했다.
UML은 시스템을 시각적으로 표현하기 위해 여러 종류의 다이어그램을 정의한다. 이 다이어그램들은 크게 시스템의 정적인 구조를 보여주는 구조 다이어그램과, 시간의 흐름에 따른 동적인 행위를 보여주는 행위 다이어그램으로 분류된다.
구조 다이어그램은 시스템을 구성하는 요소들 사이의 관계를 정적으로 묘사한다. 주요 다이어그램으로는 시스템의 논리적 구조를 보여주는 클래스 다이어그램, 물리적 구성 요소와 의존성을 보여주는 컴포넌트 다이어그램, 실행 시점의 객체 배치를 보여주는 배치 다이어그램, 시스템의 내부 구조와 연결을 보여주는 복합체 구조 다이어그램, 개념 영역의 요소들을 분류하는 객체 다이어그램과 패키지 다이어그램 등이 포함된다.
행위 다이어그램은 시스템 구성 요소들이 상호작용하며 변화하는 동적인 측면을 모델링한다. 여기에는 사용자의 관점에서 시스템 기능을 정의하는 유스케이스 다이어그램, 객체 간 메시지 교환 순서를 강조하는 시퀀스 다이어그램, 작업 흐름이나 알고리즘을 모델링하는 활동 다이어그램, 객체의 생명주기와 상태 변화를 보여주는 상태 머신 다이어그램, 상호작용의 전체적인 흐름을 보여주는 통신 다이어그램과 상호작용 개요 다이어그램, 그리고 타이밍 제약을 명시적으로 표현하는 타이밍 다이어그램 등이 있다.
다이어그램 유형 | 주요 다이어그램 | 초점 |
|---|---|---|
구조 다이어그램 | 클래스, 컴포넌트, 배치, 객체, 복합체 구조, 패키지 | 시스템의 정적 구조 |
행위 다이어그램 | 유스케이스, 시퀀스, 활동, 상태 머신, 통신, 타이밍 | 시스템의 동적 행위 |
이러한 다이어그램들은 각각 다른 관점과 추상화 수준에서 시스템을 표현하며, 모델러는 개발 단계와 목적에 따라 적절한 다이어그램을 선택하여 사용한다.
구조 다이어그램은 시스템의 정적인 구조를 표현하는 UML 다이어그램이다. 이 다이어그램들은 시스템을 구성하는 요소들, 그 요소들의 속성, 그리고 요소들 간의 관계가 시간에 따라 변하지 않는 측면을 보여준다. 시스템의 청사진이나 설계도와 같은 역할을 하며, 주로 시스템의 논리적 또는 물리적 구성 요소를 모델링하는 데 사용된다.
주요 구조 다이어그램으로는 클래스 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램, 객체 다이어그램, 복합체 구조 다이어그램, 패키지 다이어그램, 프로필 다이어그램이 있다. 각 다이어그램은 서로 다른 관점에서 구조를 묘사한다. 예를 들어, 클래스 다이어그램은 시스템의 논리적 구조를 클래스와 그 관계로 나타내고, 컴포넌트 다이어그램은 구현 단계의 물리적 모듈 구성, 배치 다이어그램은 하드웨어 노드와 소프트웨어 아티팩트의 배치 관계를 보여준다.
이들 다이어그램은 다음과 같은 특징을 공유한다.
다이어그램 명 | 주요 목적 |
|---|---|
시스템의 클래스, 속성, 연산 및 클래스 간 관계(연관, 일반화 등)를 표시한다. | |
소프트웨어 컴포넌트(라이브러리, 실행 파일 등)와 그 의존 관계를 모델링한다. | |
시스템의 물리적 아키텍처와 하드웨어 노드 상에 배치된 소프트웨어 아티팩트를 보여준다. | |
특정 시점에 시스템에 존재하는 객체 인스턴스와 그 링크를 보여주는 클래스 다이어그램의 인스턴스이다. |
구조 다이어그램은 개발 초기 단계에서 요구사항을 분석하고 도메인 모델을 구성하는 데 필수적이며, 구현 단계에서도 코드의 정적 구조를 이해하고 문서화하는 데 널리 활용된다. 이들은 시스템의 골격을 정의함으로써 개발자 간의 명확한 의사소통과 설계의 일관성을 유지하는 데 기여한다.
행위 다이어그램은 시스템의 동적인 측면, 즉 시간의 흐름에 따라 변화하는 객체들의 행위와 상호작용을 모델링하는 데 사용된다. 구조 다이어그램이 시스템의 정적인 '구조'를 보여준다면, 행위 다이어그램은 시스템이 '어떻게' 작동하는지를 묘사한다. 이들은 주로 시스템의 기능적 요구사항을 분석하고 설계하는 과정에서 활용된다.
행위 다이어그램의 주요 종류는 다음과 같다.
다이어그램 | 주요 목적 |
|---|---|
시스템이 사용자에게 제공해야 하는 기능적 요구사항을 액터와 유스케이스의 관계로 표현한다. | |
객체 간의 상호작용을 시간의 순서에 따라 메시지 교환 형태로 중점적으로 보여준다. | |
통신 다이어그램 (협업 다이어그램) | 객체 간의 관계와 그들 사이에 주고받는 메시지를 강조하며, 시퀀스 다이어그램과 정보는 동일하지만 표현 방식이 다르다. |
상태 머신 다이어그램 (상태 다이어그램) | 하나의 객체가 가질 수 있는 다양한 상태와, 사건에 의해 상태가 전이되는 조건 및 과정을 표현한다. |
비즈니스 프로세스나 알고리즘의 흐름을 작업의 순서와 제어 흐름, 병행 처리를 중심으로 보여준다. | |
상호작용 개요 다이어그램 | 활동 다이어그램의 요소를 사용하여 여러 상호작용 다이어그램(시퀀스, 통신 등)의 흐름을 제어한다. |
타이밍 다이어그램 | 객체의 상태 변화나 조건 변경을 시간 제약과 함께 상세하게 표현하는 데 특화되어 있다. |
이들 다이어그램은 각기 다른 관점에서 시스템의 동작을 포착한다. 예를 들어, 시퀀스 다이어그램과 통신 다이어그램은 모두 객체 간의 상호작용을 다루지만, 전자는 시간 순서를, 후자는 객체 간의 구조적 연결 관계를 더 명확히 보여준다. 활동 다이어그램은 업무 흐름을, 상태 머신 다이어그램은 단일 객체의 생명주기 내부 상태를 모델링한다. 이러한 다이어그램들을 상황에 맞게 조합하여 사용함으로써, 개발팀은 복잡한 시스템의 동적 행위를 효과적으로 이해, 설계, 의사소통할 수 있다.
UML의 핵심 다이어그램은 시스템의 정적 구조와 동적 행위를 모델링하는 데 가장 널리 사용되는 네 가지를 꼽을 수 있다. 이들은 각각 다른 관점과 목적을 가지며, 함께 사용될 때 시스템에 대한 포괄적인 이해를 제공한다.
클래스 다이어그램은 시스템의 정적 구조를 보여주는 가장 기본적이고 중요한 다이어그램이다. 클래스, 그 속성, 메서드, 그리고 클래스들 간의 관계(연관 관계, 상속, 집합 관계 등)를 표현한다. 이 다이어그램은 시스템을 구성하는 객체의 유형과 그들 사이의 정적인 관계를 설계 단계에서 정의하는 데 사용된다. 코드의 골격을 직접적으로 반영하는 경우가 많아 개발자들에게 매우 친숙하다.
시퀀스 다이어그램은 시간의 흐름에 따른 객체 간의 상호작용을 중점적으로 보여준다. 다이어그램 상단의 객체 생명선에서 아래로 향하는 수직 점선과 그 사이를 오가는 가로 화살표(메시지)를 통해 특정 시나리오나 작업이 수행되는 과정에서 객체들이 어떤 순서로 메시지를 주고받는지를 명확히 한다. 특정 유스케이스의 실행 흐름을 분석하거나 복잡한 프로세스의 로직을 설계할 때 유용하다.
유스케이스 다이어그램은 시스템의 기능적 요구사항을 사용자 관점에서 묘사한다. 시스템 외부에 있는 액터와 시스템이 제공하는 유스케이스(기능 단위) 간의 상호작용을 개괄적으로 보여준다. 이 다이어그램은 시스템의 범위를 정의하고, 이해관계자들과 요구사항을 논의하는 초기 단계에서 주로 활용된다. '무엇을' 제공하는지에 초점을 맞추며, '어떻게' 구현하는지는 다루지 않는다.
활동 다이어그램은 비즈니스 프로세스나 알고리즘의 작업 흐름을 모델링한다. 플로우차트와 유사하게, 시작점, 종료점, 액션, 판단(결정) 노드, 그리고 제어 흐름을 나타내는 화살표로 구성된다. 동시에 수행되는 병렬 활동을 포크와 조인 노드로 표현할 수 있어, 복잡한 작업의 순차적 및 병렬적 흐름을 시각화하는 데 강점을 가진다.
다이어그램 | 주요 초점 | 주요 사용 시기 | 주요 구성 요소 예시 |
|---|---|---|---|
클래스 다이어그램 | 정적 구조 | 설계 | 클래스, 속성, 연관 관계 |
시퀀스 다이어그램 | 시간 순서 상호작용 | 설계, 상세 분석 | 객체, 생명선, 메시지 |
유스케이스 다이어그램 | 기능적 요구사항 | 요구사항 분석 | 액터, 유스케이스, 관계 |
활동 다이어그램 | 작업 흐름/프로세스 | 비즈니스 분석, 알고리즘 설계 | 액션, 제어 흐름, 병렬 포크 |
클래스 다이어그램은 UML의 구조 다이어그램 중 하나로, 시스템의 정적인 구조를 모델링하는 데 사용된다. 이 다이어그램은 시스템을 구성하는 클래스, 그들의 속성(어트리뷰트), 메서드(오퍼레이션), 그리고 클래스들 간의 다양한 관계를 시각적으로 표현한다. 클래스 다이어그램은 주로 객체 지향 프로그래밍의 설계 단계에서 시스템의 기본적인 청사진을 제공하며, 코드 생성의 기초가 되기도 한다.
클래스는 일반적으로 세 개의 구획으로 나뉜 직사각형으로 표현된다. 최상단 구획에는 클래스 이름, 중간 구획에는 속성(예: -name: String), 하단 구획에는 메서드(예: +getName(): String)가 표기된다. 접근 제어자(가시성)는 +(public), -(private), #(protected), ~(package) 등의 기호로 나타낸다. 클래스 간의 주요 관계에는 다음과 같은 것들이 있다.
관계 | 표기법 | 설명 |
|---|---|---|
연관 | 실선 | 클래스들이 서로 알고 있거나 연결되어 있음을 나타낸다. |
일반화 | 실선과 빈 삼각형 화살표 | 상속 관계를 나타낸다(예: |
집합 | 실선과 빈 마름모 | 전체와 부분의 관계이며, 부분이 전체에 독립적으로 존재할 수 있다. |
합성 | 실선과 채워진 마름모 | 전체와 부분의 강한 관계이며, 전체가 소멸되면 부분도 함께 소멸된다. |
의존 | 점선과 열린 화살표 | 한 클래스가 다른 클래스를 매개변수나 지역 변수 등으로 일시적으로 사용함을 나타낸다. |
클래스 다이어그램은 시스템의 복잡한 구조를 단순화하여 이해하기 쉽게 만들어 준다. 이를 통해 개발자들은 설계를 논의하고 검증하며, 구현 전에 잠재적인 문제점을 발견할 수 있다. 또한, 이 다이어그램은 시간이 지남에 따라 시스템이 어떻게 변화했는지를 문서화하는 데에도 유용하게 활용된다.
시퀀스 다이어그램은 UML의 행위 다이어그램 중 하나로, 시스템 내 객체들 간의 상호작용을 시간의 흐름에 따라 순차적으로 표현한다. 주로 특정 유스케이스나 시나리오를 실행할 때 객체들이 주고받는 메시지의 순서와 흐름을 시각화하는 데 사용된다. 이 다이어그램은 시스템의 동적 행위를 이해하고, 설계의 정확성을 검증하며, 개발자 간의 의사소통을 원활하게 하는 데 중요한 역할을 한다.
다이어그램의 기본 구성 요소는 생명선과 메시지이다. 생명선은 상호작용에 참여하는 객체나 인스턴스를 수직선으로 나타내며, 상단에는 객체 이름이 표시된다. 메시지는 생명선 사이를 가로지르는 화살표로 표현되며, 메서드 호출, 신호 전송 등의 상호작용을 의미한다. 메시지에는 동기 메시지(실선 화살표), 비동기 메시지(실선 화살표, 반대쪽 끝이 열려 있음), 회신 메시지(점선 화살표) 등이 있다. 또한, 생명선 위에 표시되는 얇은 직사각형은 객체가 활동 중인 기간을 나타내는 활성화 상자이다.
시퀀스 다이어그램은 주로 시스템의 실행 로직이나 프로세스를 설명할 때 작성된다. 예를 들어, '로그인'이라는 유스케이스를 구현할 때, 사용자 인터페이스 객체, 컨트롤러 객체, 데이터베이스 객체 간에 발생하는 메시지 교환을 시간 순으로 명확하게 보여줄 수 있다. 이를 통해 설계상의 결함(예: 누락된 메시지, 잘못된 순서)을 조기에 발견할 수 있다. 다이어그램은 루프나 조건문과 같은 제어 흐름을 표현하기 위해 조각(Combined Fragment) 요소를 사용할 수도 있다[1].
구성 요소 | 설명 |
|---|---|
생명선(Lifeline) | 상호작용에 참여하는 객체를 나타내는 수직선. |
메시지(Message) | 객체 간에 주고받는 통신을 나타내는 화살표. |
활성화 상자(Activation Box) | 객체가 메시지를 처리하는 기간을 나타내는 생명선 위의 얇은 직사각형. |
조각(Combined Fragment) | 루프, 조건문, 병행 처리 등의 제어 흐름을 표현하는 영역. |
유스케이스 다이어그램은 시스템의 기능적 요구사항을 사용자 관점에서 표현하는 행위 다이어그램이다. 시스템이 사용자에게 제공해야 하는 기능을 액터와 유스케이스 간의 상호작용으로 모델링하며, 시스템의 범위를 정의하는 데 주로 사용된다. 이 다이어그램은 시스템의 '무엇을'에 초점을 맞추어, 기술적인 세부 사항보다는 사용자 요구사항과 시스템의 목표를 이해 관계자들 사이에 명확히 공유하는 데 목적이 있다.
주요 구성 요소는 액터, 유스케이스, 시스템 경계, 그리고 이들 사이의 관계이다. 액터는 시스템과 상호작용하는 외부의 사용자, 조직, 또는 다른 시스템을 나타낸다. 유스케이스는 시스템이 액터에게 제공하는 하나의 명확한 기능 단위를 타원형으로 표현한다. 시스템 경계는 사각형으로 표시되며, 내부에 유스케이스를, 외부에 액터를 배치하여 시스템의 범위를 가시적으로 정의한다.
액터와 유스케이스 간의 관계는 주로 연관(실선), 포함(<<include>>), 확장(<<extend>>), 일반화로 표현된다. 포함 관계는 한 유스케이스가 반드시 다른 유스케이스의 행동을 실행함을 의미한다. 확장 관계는 특정 조건에서만 다른 유스케이스의 행동이 확장되어 실행됨을 나타낸다. 일반화 관계는 액터나 유스케이스 간의 상속 관계를 모델링한다.
관계 유형 | 표기법 | 설명 |
|---|---|---|
연관 | 실선 | 액터와 유스케이스 간의 기본적인 상호작용을 나타낸다. |
포함 | 점선 + | 기본 유스케이스가 반드시 포함 유스케이스의 행동을 실행한다. |
확장 | 점선 + | 특정 조건에서 확장 유스케이스의 행동이 기본 유스케이스를 확장한다. |
일반화 | 실선 + 빈 삼각형 화살표 | 자식 요소가 부모 요소의 특성을 상속받는다. |
유스케이스 다이어그램은 프로젝트 초기 단계에서 요구사항을 수집하고 분석하는 데 필수적이다. 이를 통해 개발팀과 비기술적 이해 관계자 모두가 시스템의 기능적 범위와 사용자 상호작용을 직관적으로 이해할 수 있다. 또한, 이후에 작성될 시퀀스 다이어그램이나 클래스 다이어그램과 같은 보다 상세한 설계 다이어그램의 기초를 제공한다.
활동 다이어그램은 프로세스나 알고리즘의 순차적 흐름과 병행 처리를 시각적으로 모델링하는 행위 다이어그램이다. 주로 비즈니스 프로세스의 워크플로우, 시스템 내의 연산 절차, 또는 객체 간의 상호작용 과정을 표현하는 데 사용된다. 기본적으로 플로우차트와 유사한 형태를 가지지만, 포크와 조인 노드를 통해 병렬 활동을 표현할 수 있는 것이 특징이다.
활동 다이어그램의 주요 구성 요소는 다음과 같다.
구성 요소 | 설명 |
|---|---|
활동 흐름의 시작점을 나타낸다. | |
수행되는 작업이나 태스크를 나타낸다. | |
조건 분기를 나타내며, 보통 다이아몬드 기호로 표시된다. | |
활동 흐름을 병렬로 분기하거나 병렬 흐름을 다시 합치는 데 사용된다. | |
활동 간에 흐르는 데이터나 객체를 나타낸다. | |
활동 흐름의 종료점을 나타낸다. |
이 다이어그램은 복잡한 제어 흐름을 명확하게 보여주기 때문에, 시스템 분석 단계에서 업무 절차를 이해하거나 소프트웨어 설계 단계에서 메서드의 내부 로직을 정의하는 데 유용하다. 특히 여러 담당자나 시스템 구성 요소 간의 협업 과정을 모델링할 때 스윔레인을 활용해 역할별로 영역을 구분하여 그릴 수 있다.
UML 모델은 기본 구성 요소와 그들 사이의 관계를 통해 시스템의 구조와 행동을 표현한다. 이러한 요소들은 크게 구조적 요소와 행위적 요소로 나뉘지만, 본 섹션에서는 구조적 요소와 관계에 초점을 맞춘다.
구조적 요소는 시스템의 정적인 부분을 나타내는 개념적 또는 물리적 요소이다. 주요 구조적 요소로는 클래스, 인터페이스, 협력, 유스케이스, 액터, 컴포넌트, 노드 등이 있다. 예를 들어, 클래스는 공통된 속성, 연산, 관계, 의미를 공유하는 객체들의 집합을 정의한다. 컴포넌트는 시스템의 물리적이고 교체 가능한 부분을, 노드는 실행 시간에 존재하는 물리적 요소를 모델링한다. 이러한 요소들은 다양한 다이어그램에서 시각적 아이콘으로 표현된다.
요소들 사이의 논리적 또는 물리적 연결은 관계를 통해 명시된다. UML에서 정의하는 주요 관계의 종류는 다음과 같다.
관계 | 설명 | 표기법 |
|---|---|---|
연관 | 두 클래스 사이의 구조적 연결. 인스턴스들이 서로를 알고 있음을 의미한다. | 실선 |
집합 | 전체와 부분의 관계이며, 부분이 전체에 독립적으로 존재할 수 있다. | 실선과 빈 마름모 |
합성 | 전체와 부분의 강한 소유 관계. 부분은 전체와 생명주기를 함께한다. | 실선과 채워진 마름모 |
일반화 | 객체지향의 상속 관계. 특수한 요소가 일반적인 요소의 구조와 행동을 물려받는다. | 실선과 빈 화살촉 |
실현 | 명세(예: 인터페이스)와 그 명세를 구현하는 요소 사이의 관계. | 점선과 빈 화살촉 |
의존 | 한 요소의 변경이 다른 요소에 영향을 미칠 수 있는 약하고 일시적인 사용 관계. | 점선과 열린 화살촉 |
이러한 관계들은 모델의 정확성과 명확성을 높이는 데 필수적이다. 예를 들어, 클래스 다이어그램에서는 연관, 집합, 일반화 관계가 빈번히 사용되어 시스템의 정적 구조를 보여준다. 관계의 다중성(예: 1, 0..*, 1..5)을 표시하여 객체들 사이의 수적 연결 제약을 정의할 수도 있다.
UML의 구조적 요소는 시스템의 정적인 측면을 모델링하는 데 사용되는 구성 요소를 가리킨다. 이 요소들은 시스템을 구성하는 개념적인 또는 물리적인 객체, 그리고 그 객체들 사이의 관계를 표현하는 기본 블록 역할을 한다. 가장 기본적이고 중요한 구조적 요소는 클래스, 인터페이스, 컴포넌트, 노드 등이다.
클래스는 공통된 속성, 연산(메서드), 관계, 의미를 공유하는 객체들의 집합을 정의한다. 클래스는 이름, 속성, 연산이 구분된 구획으로 표시되는 사각형으로 표현된다. 인터페이스는 클래스나 컴포넌트가 제공해야 하는 연산의 집합을 명시하는 계약을 나타낸다. 인터페이스는 구현 세부 사항 없이 '무엇을' 할 수 있는지에 초점을 맞춘다.
물리적인 측면의 구조적 요소로는 컴포넌트와 노드가 있다. 컴포넌트는 시스템의 물리적이고 교체 가능한 부분으로, 인터페이스를 통해 기능을 제공하고 요구하는 소프트웨어 모듈을 모델링한다. 노드는 처리 능력을 가진 물리적인 하드웨어 장치(서버, 워크스테이션 등)를 나타내며, 실행 중인 아티팩트나 다른 실행 가능한 요소들을 배치할 수 있다.
UML에서 관계는 모델 요소 간의 의미 있는 연결을 정의한다. 관계는 시스템의 정적 구조를 표현하는 데 필수적이며, 주로 클래스 다이어그램에서 사용되지만 다른 다이어그램에서도 나타난다. 주요 관계 유형은 연관, 일반화, 실체화, 의존, 집합, 합성으로 구분된다.
관계 유형 | 표기법 (기본) | 설명 |
|---|---|---|
실선 | 두 클래스 사이의 구조적 연결을 나타낸다. 방향성과 다중성을 가질 수 있다. | |
실선 + 속이 빈 화살촉 | 한 클래스(자식)가 다른 클래스(부모)의 특성을 상속받는 관계이다. | |
점선 + 속이 빈 화살촉 | 한 클래스가 다른 클래스나 인터페이스가 정의한 계약을 구현하는 관계이다. | |
점선 + 열린 화살촉 | 한 요소의 변경이 다른 요소에 영향을 미칠 수 있는 일시적인 사용 관계를 나타낸다. | |
실선 + 속이 빈 마름모 | 전체와 부분의 관계이며, 부분이 전체와 독립적으로 존재할 수 있다. | |
실선 + 속이 찬 마름모 | 전체와 부분의 강한 소유 관계이며, 전체가 소멸되면 부분도 함께 소멸된다. |
연관 관계는 더 세분화될 수 있다. 양방향 연관은 기본 실선으로, 단방향 연관은 화살표가 달린 실선으로 표현한다. 연관선 끝에 표시되는 다중성(예: 1, 0..1, *, 1..*)은 객체들 사이의 수적 관계를 정의한다. 자기 연관은 동일한 클래스의 인스턴스끼리 연결될 수 있음을 보여준다. 집합과 합성은 모두 연관 관계의 특수한 형태로, 객체들의 수명 주기와 소유권을 명시적으로 모델링하는 데 사용된다.
UML은 소프트웨어 시스템의 설계, 시각화, 구축 및 문서화를 위한 표준화된 모델링 언어로서, 다양한 분야에서 폭넓게 활용된다. 주로 소프트웨어 공학 분야에서 요구사항 분석, 시스템 설계, 구현, 테스트, 유지보수 등 소프트웨어 개발 전 생명주기 전반에 걸쳐 사용된다. 특히 객체지향 프로그래밍 방식의 시스템 설계와 의사소통에 핵심적인 역할을 한다. 또한 비즈니스 프로세스 모델링, 시스템 아키텍처 설계, 데이터 모델링 등 소프트웨어 개발 외에도 조직의 업무 흐름을 분석하고 표준화하는 데에도 적용된다.
UML을 사용함으로써 얻는 주요 이점은 명확한 의사소통과 공유된 이해의 창출이다. 복잡한 시스템을 추상화된 다이어그램으로 표현함으로써 개발자, 분석가, 관리자, 고객 등 다양한 이해관계자 간에 효과적인 의사소통이 가능해진다. 이는 요구사항의 오해를 줄이고, 설계의 일관성을 유지하며, 시스템의 구조와 동작을 명확하게 문서화하는 데 기여한다. 또한 설계 단계에서 잠재적인 문제나 모순을 시각적으로 발견하고 조기에 해결할 수 있어 개발 비용과 시간을 절감하는 효과가 있다.
UML의 활용은 프로젝트의 규모와 방법론에 따라 유연하게 조정된다. 대규모 엔터프라이즈 시스템에서는 클래스 다이어그램과 컴포넌트 다이어그램을 이용한 정교한 구조 설계가, 복잡한 비즈니스 로직을 가진 시스템에서는 활동 다이어그램과 상태 머신 다이어그램을 통한 동작 모델링이 강조된다. 반면, 애자일이나 스크럼 같은 경량 개발 방법론에서는 빠른 프로토타이핑과 팀 내 소통을 위해 유스케이스 다이어그램과 간소화된 시퀀스 다이어그램을 적극적으로 활용하기도 한다.
UML 모델링을 지원하는 도구는 상용, 오픈 소스, 클라우드 기반 등 다양하게 존재한다. 이러한 도구들은 다이어그램 작성을 자동화하고, 코드 생성 및 역공학[2], 모델 검증, 팀 협업 등의 기능을 제공하여 소프트웨어 개발 과정의 효율성을 높인다.
대표적인 상용 도구로는 IBM Rational Rose의 후속 제품군, Sparx Systems의 Enterprise Architect, 그리고 Visual Paradigm 등이 있다. 이들 도구는 종합적인 모델링 환경, 다양한 프로그래밍 언어에 대한 코드 변환 지원, 보고서 생성 등 고급 기능을 갖추고 있다. 한편, StarUML, ArgoUML, PlantUML 등은 널리 사용되는 오픈 소스 도구이다. 특히 PlantUML은 텍스트 기반의 스크립트로 다이어그램을 생성하는 독특한 방식을 채택하여 버전 관리 시스템과의 호환성이 뛰어나다는 장점이 있다.
최근에는 웹 브라우저에서 동작하는 클라우드 기반 협업 도구의 인기가 증가하고 있다. Lucidchart, draw.io(diagrams.net), Miro 등의 플랫폼은 실시간 공동 편집, 쉬운 공유 기능을 강점으로 하여 분산된 팀의 소프트웨어 설계 협업에 적합하다. 도구 선택은 프로젝트의 규모, 예산, 필요한 기능, 팀의 작업 방식 등을 고려하여 결정한다.
도구 유형 | 대표 예시 | 주요 특징 |
|---|---|---|
상용 도구 | Enterprise Architect, Visual Paradigm | 종합적 기능, 코드 생성/역공학, 강력한 보고 |
오픈 소스 도구 | StarUML, PlantUML | 무료 사용, 커뮤니티 기반 발전, 특정 방식(예: 텍스트 기반) 지원 |
클라우드/협업 도구 | Lucidchart, draw.io | 웹 기반 실시간 협업, 쉬운 공유 및 통합 |