UML 다이어그램 튜토리얼

백문이 불여일견입니다. 복잡한 소프트웨어 개발 세계에서 비즈니스 사용자와 시스템을 이해하고자 하는 모든 이가 공통으로 이해할 수 있는 시각적 언어를 제공하기 위해 통합 모델링 언어(UML)가 만들어진 이유가 바로 여기에 있습니다. 이 가이드에서는 UML에 대해 알아야 할 모든 내용을 다룹니다. 정규 교육 과정에서 UML을 처음 접한 후 자주 사용하지 않았더라도, 일회성 결과물이 아닌 최신 상태를 유지하는 문서로 활용한다면 복잡한 시스템을 쉽게 이해할 수 있는 실용적인 방법이 됩니다.

UML이란 무엇인가요?

통합 모델링 언어(UML)는 복잡한 소프트웨어 시스템의 아키텍처, 설계 및 구현을 구조적 및 행위적 측면 모두에서 명확하게 표현할 수 있도록, 의미론적 및 구문론적으로 풍부한 공통의 시각적 모델링 언어를 구축하기 위해 만들어졌습니다.

UML은 다른 분야에서 사용되는 청사진과 유사하며 다양한 유형의 다이어그램으로 구성됩니다. 종합적으로 UML 다이어그램은 시스템의 경계, 구조, 시스템과 그 내부 객체의 행위를 설명합니다. 코드를 작성할 때 애플리케이션의 수천 줄에 달하는 코드 속에서 소프트웨어 시스템 내부의 관계와 계층 구조를 추적하기는 어렵습니다. UML 다이어그램은 이러한 소프트웨어 시스템을 컴포넌트와 하위 컴포넌트로 세분화해 줍니다.

문제 해결 모델 범주에는 명령형, 함수형, 선언형, 객체 지향 언어의 네 가지가 있습니다. 객체 지향 언어에서는 '객체'를 정의하고 이러한 객체들이 서로 상호작용하도록 하여 알고리즘을 표현합니다. 이러한 객체는 조작의 대상이며 현실 세계에 존재합니다. 건물, 데스크톱의 위젯, 인간 등이 모두 객체가 될 수 있습니다.

객체 지향 언어는 현실 세계의 객체를 모델링하므로 프로그래밍 세계를 지배하고 있습니다. UML은 객체 지향 설계, 객체 모델링 기술, 객체 지향 소프트웨어 엔지니어링 등 여러 객체 지향 표기법의 결합체입니다.

UML은 이 세 가지 접근 방식의 장점을 활용하여 사용하기 더 쉽고 일관된 방법론을 제시합니다. UML은 소프트웨어 및 비즈니스 시스템 모델링의 다양한 측면을 구축하고 문서화하기 위한 모범 사례를 나타냅니다. UML은 표준화되어 있으므로 여러 프로그래밍 언어와 개발 프로세스에 적용할 수 있어 대부분의 소프트웨어 개발자가 광범위하게 읽을 수 있습니다.

실제 업무에서 UML은 시스템을 다시 설명하는 데 드는 시간을 줄여줄 수 있는 시각적 문서의 형태이기도 합니다. 이러한 문서는 신규 직원의 온보딩부터 이해관계자에게 시스템 개요를 신속하게 제공하는 것까지 다양한 방식으로 엔지니어를 지원하므로, 개발자가 회의로 시간을 낭비하지 않도록 도와줍니다.

UML의 역사와 기원

소프트웨어 엔지니어링 분야에서 '세 친구(The Three Amigos)'로도 잘 알려진 그래디 부치(Grady Booch), 제임스 럼보(James Rumbaugh), 이바 야콥슨(Ivar Jacobson)은 새로운 표준을 만들어 프로그래머들에게 명확한 지침을 제공하기 위해 힘을 합쳤습니다.

이들의 노력으로 1996년에 UML 0.9 및 0.91 문서가 출시되었습니다. 곧 Microsoft, Oracle, IBM을 비롯한 여러 기업이 UML을 자체 비즈니스 개발에 필수적인 요소로 인식하게 되었습니다. 이들은 다른 수많은 개인 및 기업과 함께 본격적인 모델링 언어를 개발할 수 있는 리소스를 구축했습니다. '세 친구'는 1999년에 'The Unified Modeling Language User Guide'를 출간했으며, 2005년에는 UML 2.0이 포함된 개정판을 발표했습니다.

UML에서 객체 관리 그룹(OMG)의 역할

웹사이트에 따르면, 객체 관리 그룹®(OMG®)은 1989년에 설립된 국제적인 개방형 회원제 비영리 기술 표준 컨소시엄입니다. OMG 표준은 공급업체, 최종 사용자, 학술 기관 및 정부 기관이 주도합니다. OMG 태스크 포스는 다양한 기술과 더 광범위한 산업 분야를 위한 엔터프라이즈 통합 표준을 개발합니다. UML 및 모델 구동 아키텍처(Model Driven Architecture®, MDA®)를 포함한 OMG의 모델링 표준은 소프트웨어 및 기타 프로세스의 강력한 시각적 설계, 실행 및 유지 관리를 가능하게 합니다.

OMG는 UML 사양의 정의 및 유지 관리를 감독합니다. 이러한 감독을 통해 엔지니어와 프로그래머는 시스템 규모에 관계없이 소프트웨어 수명 주기의 모든 단계에서 다양한 목적으로 하나의 언어를 사용할 수 있는 능력을 갖추게 됩니다.

OMG는 UML의 목적을 다음과 같이 정의합니다.

• 시스템 아키텍트, 소프트웨어 엔지니어, 소프트웨어 개발자에게 소프트웨어 기반 시스템의 분석, 설계 및 구현을 위한 도구와 비즈니스 및 이와 유사한 프로세스를 모델링하기 위한 도구를 제공합니다.

• 객체 시각적 모델링 도구의 상호 운용성을 지원하여 업계 수준을 발전시킵니다. 그러나 도구 간에 의미 있는 모델 정보 교환을 가능하게 하려면 의미론과 표기법에 대한 합의가 필요합니다.

UML은 다음 요구 사항을 충족합니다.

• UML의 추상 구문을 지정하는 공통 MOF(Meta-Object Facility) 기반 메타 모델의 공식 정의를 설정합니다. 추상 구문은 UML 모델링 개념, 해당 속성 및 관계의 집합뿐만 아니라 부분적 또는 완전한 UML 모델을 구성하기 위해 이러한 개념을 결합하는 규칙을 정의합니다.

• 각 UML 모델링 개념의 의미론에 대한 자세한 설명을 제공합니다. 의미론은 기술 독립적인 방식으로 컴퓨터가 UML 개념을 어떻게 구현해야 하는지 정의합니다.

• 개별 UML 모델링 개념을 나타내기 위해 사람이 읽을 수 있는 표기법 요소와 모델링된 시스템의 다양한 측면에 해당하는 다양한 다이어그램 유형으로 이들을 결합하는 규칙을 지정합니다.

• UML 도구가 이 사양을 준수하도록 만드는 방법을 정의합니다. 이는 준수 도구에서 구현해야 하는 상응하는 XML 기반 모델 교환 형식(XMI) 사양(별도 사양)을 통해 지원됩니다.

UML 다이어그램 유형

UML은 요소를 사용하고 이를 다양한 방식으로 연관시켜 정적 다이어그램(시스템의 구조적 측면을 나타냄)과 행위 다이어그램(시스템의 동적 측면을 나타냄)을 형성합니다. 처음 접하는 사람에게는 UML 다이어그램의 종류가 무한해 보일 수 있지만, 실제 UML 표준에서는 다이어그램을 아래에 정의된 두 그룹의 14가지 유형으로 분류합니다.

구조 UML 다이어그램

• 클래스 다이어그램: 이것은 가장 일반적으로 사용되는 UML 다이어그램이자 모든 객체 지향 솔루션의 주요 토대입니다. 시스템 내부의 클래스, 속성 및 작업, 그리고 각 클래스 간의 관계를 보여줍니다. 대규모 시스템을 다이어그램으로 표현할 때 클래스들을 함께 그룹화하여 클래스 다이어그램을 생성합니다. 클래스는 수직으로 쌓인 세 개의 구획이 있는 직사각형으로 표시됩니다. 맨 위 구획에는 클래스 이름이 포함되며 필수 항목입니다. 아래쪽 두 구획은 클래스 속성과 클래스 작업 또는 행위에 대한 세부 정보를 제공합니다.

• 컴포넌트 다이어그램: 컴포넌트 다이어그램은 본질적으로 클래스 다이어그램의 더 전문화된 버전이며 두 다이어그램 모두 동일한 표기법 규칙이 적용됩니다. 컴포넌트 다이어그램은 복잡한 시스템을 더 작은 컴포넌트로 세분화하고 이러한 컴포넌트 간의 관계를 시각화합니다.

• 복합 구조 다이어그램: 이러한 유형의 다이어그램은 본질적으로 분류자(classifier)의 내부 구조를 위한 청사진입니다. 협업의 행위나 포트를 통한 분류자와 환경 간의 상호작용을 보여주는 데 사용할 수도 있습니다. 하드웨어의 내부 컴포넌트를 쉽게 묘사하여 내부 작동 방식을 더 철저하게 이해할 수 있습니다.

• 배포 다이어그램: 이러한 다이어그램은 시스템 엔지니어에게 가장 유용하며 일반적으로 성능, 확장성, 유지 관리성 및 이식성을 보여줍니다. 하드웨어 컴포넌트가 서로 연관되어 표시되면 전체 하드웨어 메쉬를 쉽게 추적하고 배포 시 모든 요소가 고려되었는지 확인할 수 있습니다.

• 객체 다이어그램: 객체 다이어그램은 특정 시점의 데이터 구조 예시를 보여줍니다. 클래스 다이어그램을 사용하여 구조를 보여준 다음 객체 다이어그램을 테스트 케이스로 사용하여 클래스 다이어그램의 완전성을 검증할 수 있습니다. 또는 객체 다이어그램을 생성하여 모델 요소 및 해당 링크에 대한 정보를 찾을 수도 있습니다.

• 패키지 다이어그램: 패키지 다이어그램은 시스템 내 서로 다른 패키지 간의 의존성을 보여주는 데 사용됩니다. 서류 폴더 모양으로 표시되는 패키지는 유스케이스나 클래스와 같은 모델 요소를 그룹으로 구성합니다. 패키지 간에 정의된 두 가지 특별한 의존성 유형에는 패키지 가져오기(package import)와 패키지 병합(package merge)이 있습니다.

• 프로파일 다이어그램: 프로파일 다이어그램도 UML 표준의 일부이며 주로 특정 도메인에 맞게 UML을 조정해야 할 때 사용됩니다. 최근 UML 2.0에 추가된 프로파일 다이어그램은 독특하며 사양에서 거의 사용되지 않습니다. 프로파일 다이어그램은 특정 도메인 및 플랫폼에 맞게 UML 모델을 맞춤 설정하기 위한 확장 메커니즘으로 이해하는 것이 가장 좋습니다.

행위 UML 다이어그램

• 활동 다이어그램: 활동 다이어그램은 상태 머신 다이어그램의 대안으로 사용됩니다. 활동 다이어그램은 유스케이스에서 수행되는 단계를 시각화하며, 활동은 순차적이거나 분기되거나 동시적일 수 있습니다. 이 유형의 UML 다이어그램은 시스템의 동적 행위를 보여주는 데 사용되지만 비즈니스 프로세스 모델링에도 유용할 수 있습니다.

• 커뮤니케이션 다이어그램: 이전에 협업 다이어그램(collaboration diagram)으로 불렸던 커뮤니케이션 다이어그램은 객체들이 서로 어떻게 연관되어 있는지 보여줍니다. 시스템의 아키텍처 설계 내에서 메시지를 통해 객체가 연결되고 연관되는 방식을 모델링합니다. 또한 유스케이스 내의 대안 시나리오나 다양한 객체의 협업 및 상호작용이 필요한 작업을 보여줄 수도 있습니다.

• 상호작용 개요 다이어그램: 이 다이어그램은 상호작용하는 노드 간의 제어 흐름을 개괄적으로 보여줍니다. 여기에는 시작 노드, 흐름 종료 노드, 활동 종료 노드, 결정 노드, 병합 노드, 포크 노드 및 조인 노드가 포함됩니다.

• 시퀀스 다이어그램: 시퀀스 다이어그램은 이벤트 다이어그램 또는 이벤트 시나리오라고도 하며, 객체가 상호작용하는 순서를 보여줍니다. 이를 통해 간단한 런타임 시나리오를 시각적으로 표현할 수 있습니다.

• 상태 다이어그램: 상태 다이어그램은 간단히 말해 상태와 전이를 묘사합니다. 상태는 객체가 가질 수 있는 다양한 정보의 조합을 말하며, 이 UML 다이어그램은 가능한 모든 상태와 객체가 한 상태에서 다음 상태로 전이하는 방식을 시각화할 수 있습니다.

• 타이밍 다이어그램: 종종 역방향 시퀀스 다이어그램으로 설명되는 타이밍 다이어그램은 주어진 시간 프레임 내에서 객체들이 서로 어떻게 상호작용하는지 보여줍니다. 이 다이어그램을 사용하여 프로세스의 각 단계가 얼마나 걸리는지 확인하고 개선할 부분을 찾을 수 있습니다.

• 유스케이스 다이어그램: 유스케이스 다이어그램은 "액터(actor)"라고 불리는 졸라맨 모양으로 표시되는 사용자가 시스템과 상호작용하는 방식을 모델링합니다. 이 유형의 UML 다이어그램은 액터와 시스템 간의 관계를 고수준에서 개괄적으로 보여주어야 하므로, 비기술 잠재 고객에게 시스템을 설명할 수 있는 훌륭한 도구가 될 수 있습니다.

UML 용어 사전

OMG 비회원이 자주 사용되는 용어를 이해하는 데 도움이 되도록 UML 2.4.1 문서에서 발췌한 아래 목록을 통해 UML 어휘를 익혀보세요.

• 추상 구문 준수: 사용자가 서로 다른 표기법을 사용하더라도 여러 도구 간에 모델을 이동할 수 있습니다.

• 공통 웨어하우스 메타모델(CWM): 분산된 이기종 환경에서 웨어하우스 도구, 웨어하우스 플랫폼 및 웨어하우스 메타데이터 저장소 간에 웨어하우스 및 비즈니스 인텔리전스 메타데이터의 교환을 가능하게 하는 데 사용되는 표준 인터페이스입니다.

• 구체 구문 준수: 사용자가 서로 다른 도구 간에 익숙한 표기법을 계속해서 사용할 수 있습니다.

• 핵심(Core): UML의 컨텍스트에서 핵심은 일반적으로 높은 재사용성을 위해 특별히 설계된 완전한 메타모델인 '핵심 패키지(core package)'를 의미합니다.

• 언어 단위: 사용자가 특정 패러다임이나 형식주의에 따라 연구 중인 시스템의 측면을 표현할 수 있는 기능을 제공하는 밀접하게 결합된 모델링 개념의 집합으로 구성됩니다.

• 레벨 0(L0): 대부분의 대중적인 객체 지향 프로그래밍 언어에서 접하는 일종의 클래스 기반 구조를 모델링할 수 있도록 제공하는 단일 언어 단위로, UML 인프라의 가장 낮은 준수 레벨입니다.

• 메타 객체 시설(MOF): OMG의 MDA 언어 제품군에서 메타모델 정의의 기반을 제공하는 OMG 모델링 사양입니다.

• 메타모델: 모델을 형성하기 위한 언어와 프로세스를 정의합니다.

• 메타모델 구조(LM): UML 자체와 같은 메타모델을 빌드(CMOF 사용)하는 데 사용되는 더 고급 클래스 기반 구조를 위한 추가 언어 단위로, UML 인프라의 두 번째 준수 레벨입니다. UML에는 두 가지 준수 레벨만 있습니다.

• 모델 구동 아키텍처(MDA): 일련의 응집력 있는 모델 구동 기술 사양을 달성하기 위한 접근 방식 및 계획입니다.

• 객체 제약 언어(OCL): 통합 모델링 언어에 적용되는 규칙을 설명하기 위한 선언적 언어입니다. OCL은 자연어보다 정밀하지만 수학보다 마스터하기 덜 어려운 용어와 순서도 기호를 제공하여 UML을 보완합니다.

• 객체 관리 그룹(OMG): 회원들이 UML 사양을 정의하고 유지 관리하는 비영리 컴퓨터 산업 사양 컨소시엄입니다.

• UML 1: 통합 모델링 언어의 첫 번째 버전입니다.

• 통합 모델링 언어(UML): 시스템의 결과물을 지정, 구축 및 문서화하기 위한 시각적 언어입니다.

• XMI: 상응하는 모델 교환 형식의 XML 기반 사양입니다.

UML에 지정된 모델링 개념

시스템 개발은 전반적으로 세 가지 시스템 모델에 중점을 둡니다.

• 기능적 모델: 사용자의 관점에서 시스템 기능을 설명하는 유스케이스 다이어그램입니다.
• 객체 모델: 객체, 속성, 연관성 및 작업 측면에서 시스템의 구조를 설명하는 클래스 다이어그램입니다.
• 동적 모델: 시스템의 내부 행위를 설명하는 데 사용되는 상호작용 다이어그램, 상태 머신 다이어그램 및 활동 다이어그램입니다.

이러한 시스템 모델은 구조 다이어그램과 행위 다이어그램이라는 두 가지 유형의 다이어그램을 통해 시각화됩니다.

UML의 객체 지향 개념

UML의 객체는 우리 주변에 존재하는 현실 세계의 엔티티입니다. 소프트웨어 개발에서 객체는 관련 도메인 측면에서 생성 중인 시스템을 설명하거나 모델링하는 데 사용할 수 있습니다. 또한 객체를 사용하면 복잡한 시스템을 이해하기 쉬운 컴포넌트로 세분화하여 한 번에 하나의 부분을 빌드할 수 있습니다.

다음은 객체 지향 세계의 몇 가지 기본적인 개념입니다.

• 객체: 엔티티이자 기본 빌딩 블록을 나타냅니다.
• 클래스: 객체의 청사진입니다.
• 추상화: 현실 세계 엔티티의 행위입니다.
• 캡슐화: 데이터를 함께 묶고 외부 세계로부터 숨기는 메커니즘입니다.
• 상속: 기존 클래스에서 새로운 클래스를 만드는 메커니즘입니다.
• 다형성: 다양한 형태로 존재할 수 있는 메커니즘을 정의합니다.

현대적인 팀, 특히 애자일을 실천하는 팀에서는 다이어그램을 한 번 만들고 그대로 방치하는 것이 아니라, 코드가 변경될 때마다 함께 업데이트하며 '핵심 문서'로 취급할 때 이러한 객체 지향 개념을 가장 쉽게 전달할 수 있습니다.

팀이 여전히 UML 다이어그램을 사용하는 이유(특히 애자일에서)

정식 코드 교육을 받은 적이 있다면 학교에서 UML 다이어그램을 접했을 것입니다. 하지만 그 이후로 얼마나 많이 사용하셨나요? UML 다이어그램은 빌드하는 데 시간이 좀 걸리고 애자일 환경에서는 상당히 빨리 최신 상태에서 벗어나기 때문에 많은 소프트웨어 개발자가 이를 잊고 지내왔습니다.

그러한 우려는 타당합니다. 프로젝트와 함께 발전하지 않는 다이어그램은 가치를 빠르게 잃게 됩니다. 하지만 최신 상태를 유지한다면 UML은 개발 속도를 높이고 소통을 더 명확하게 만들 수 있습니다. 많은 엔지니어가 다이어그램 작성을 번거롭게 여기지만, 애자일 개발 환경에서는 매우 유용합니다. 개발을 생산적이고 집중력 있게 유지해 주기 때문입니다. 다이어그램을 단순히 '있으면 좋은 것'으로 생각하지 말고 UML 다이어그램을 문서화의 핵심 요소로 취급해 보세요.

UML 다이어그램은 엔지니어링 팀이 다음과 같은 작업을 수행하도록 도울 수 있습니다.

• 신규 팀원이나 팀을 이동하는 개발자가 빠르게 적응할 수 있도록 지원합니다.

• 소스 코드를 탐색합니다.

• 프로그래밍이 시작되기 전에 새로운 기능을 계획합니다.

• 기술 및 비기술 잠재 고객 모두와 더 쉽게 소통합니다.

그러나 프로젝트와 함께 진화하지 않는 다이어그램은 무용지물하므로 끊임없이 발전하는 다이어그램이 필수적입니다. 팀이 유지 관리 부담을 줄이는 한 가지 방법은 시스템이 변경될 때 문서의 탄력성을 유지할 수 있도록 더 가벼운 입력 방식(예: 텍스트 기반 정의)으로 다이어그램을 생성하는 것입니다. Lucidchart는 텍스트 마크업을 통해 UML 시퀀스 다이어그램을 생성할 수 있어 다이어그램 작성을 자동화하고 유연하게 만들어 줍니다.

UML 다이어그램 만드는 방법

UML 다이어그램은 특정 규칙과 모양 모음을 따르므로 각 유형을 올바르게 빌드하는 방법을 배우는 데 상당한 시간이 걸릴 수 있습니다. 다행히도 클래스 다이어그램부터 시작하여 프로세스를 단계별로 안내하는 쉬운 튜토리얼을 통해 쉽게 만들 수 있도록 준비했습니다.

도구에 관계없이 실제 워크플로는 일관됩니다. 질문에 맞는 다이어그램 유형(구조 vs. 행위)을 선택하고, 현재 대상에게 필요한 것만 모델링하며, 코드와 요구 사항이 변경될 때마다 다이어그램을 다시 검토하세요. 새로운 소프트웨어 시스템의 정적 아키텍처를 매핑하든 동적 사용자 상호작용을 시각화하든, 다음 단계에 따라 효과적인 모델을 빌드해 보세요.

1. 목표 정의하기

시각화해야 할 내용을 정확히 결정하세요. 시스템의 정적 구조를 매핑해야 하는지(구조적), 아니면 컴포넌트가 시간이 지남에 따라 어떻게 상호작용하고 변화하는지 보여주어야 하는지(행위적) 스스로에게 질문해 보세요.

2. 올바른 다이어그램 유형 선택하기

시스템 요구 사항을 바탕으로 적절한 UML 다이어그램을 선택하세요. 예를 들어, 객체 지향 시스템 구조에는 클래스 다이어그램을, 시간 순서에 따른 상호작용에는 시퀀스 다이어그램을, 사용자 기능을 설명할 때는 유스케이스 다이어그램을 사용하세요. (팁: Lucidchart의 미리 제작된 UML 템플릿으로 시작하는 것이 가장 빠른 방법입니다.)

3. UML 모양 라이브러리 활성화하기

UML은 엄격한 시각적 어휘를 사용하므로 올바른 기호가 필요합니다. Lucidchart의 왼쪽 메뉴 하단에서 '모양 더 보기'를 클릭하고 'UML'을 검색한 후 필요한 특정 모양 라이브러리(예: UML 클래스, UML 상태, UML 시퀀스)의 확인란을 선택하세요.

4. 모양 추가 및 정의하기

엔티티, 객체, 노드 또는 액터를 캔버스로 드래그 앤 드롭하세요. 이를 논리적으로 배치하고 모양 내부를 더블 클릭하여 사용자 지정 텍스트, 특정 속성 및 작업을 객체에 추가하세요.

5. 컴포넌트 연결하기

선들을 그려 엔티티 간의 관계를 설정하세요. 선의 끝점(화살표, 다이아몬드 등)을 맞춤 설정하여 상속, 컴포지션(합성), 의존성 또는 기본 연관성과 같은 특정 UML 관계를 정확하게 반영하세요.

6. 검토 및 협업하기

UML은 개발자, 엔지니어, 비즈니스 이해관계자 간의 공유 언어 역할을 하도록 설계되었습니다. 다이어그램의 초안이 작성되면 Lucidchart의 실시간 협업 기능을 사용하여 팀을 초대해 아키텍처를 검토하고 댓글을 남기며 청사진을 완성해 보세요.

UML 전도사 되기

때로는 나 혼자만 UML 다이어그램을 도입하는 것으로는 충분하지 않습니다. 결국 소프트웨어 개발자로서 대개 팀과 함께 작업하므로 다른 모든 사람도 동참하도록 이끄는 것이 중요합니다.

팀이 개발 프로세스에 UML 다이어그램을 통합하는 것을 주저한다면 우선 한 가지 프로젝트에만 사용해 볼 것을 제안해 보세요. 팀원들이 UML 다이어그램이 문서화에 얼마나 큰 도움이 되는지 확인하고 나면 이를 필수 단계로 기꺼이 받아들이기 시작할 것입니다.

게다가 Lucidchart와 함께라면 UML 다이어그램은 번거로운 일이 아니라 소중한 자산이 됩니다.