UML(Unified Modeling Language)은 소프트웨어 개발 과정에서 시스템의 구조와 행동을 시각적으로 표현하기 위한 표준 모델링 언어입니다.
다양한 UML 다이어그램이 있으며, 각각은 시스템의 특정 측면을 나타내는 데 사용됩니다.
업무를 진행하면서 기본적으로 아는 기준에서 소통하기 위해선 알아 두는게 좋다고 생각되어 이렇게 정리 해보려 합니다.
주요 UML 다이어그램의 종류는 다음과 같습니다:
- 클래스 다이어그램 (Class Diagram)
- 유스케이스 다이어그램(Use Case Diagram)
- 시퀀스 다이어그램 (Sequence Diagram)
- 상태 다이어그램(State Diagram)
- 활동 다이어그램(Activity Diagram)
- 컴포넌트 다이어그램(Component Diagram)
- 배치 다이어그램(Deployment Diagram) ※ 여기서 말하는 배치는 Batch가 아닌 Deployment 입니다.
1. 클래스 다이어그램(Class Diagram)
시스템의 클래스들과 그들 간의 관계를 표현합니다.
클래스, 속성, 메서드, 관계 등을 나타내며, 객체 지향 설계에서 가장 기본적으로 사용됩니다.
설계를 진행하며 클래스 다이어그램 이라는 단어를 들어본 적이 없었는데... 제가 있던 환경에서는 쓰지 않았다보니 생소했습니다.
프로젝트를 설계하면서 클래스간의 관계를 정의하고 중복되는 부분을 제거하는데 사용하기 위해 그림을 그린 적이 있는데, 그게 클래스 다이어그램 이었습니다...
이런 방법이 고유명사로 있었다는걸 몰랐네요.
클래스, 인터페이스 들을 표현할 수 있습니다.
1-1 클래스 타입
앞에 +, -, #이 붙는데 +는 public, -는 private, #은 protected, ~는 default를 의미합니다.
{readonly}가 붙으면 final을 의미합니다.
밑줄은 static을 의미합니다.
[*] 나 [0...1]은 리스트와 같은 변수에 지정된 사이즈를 뜻합니다.
List의 경우는 사이즈가 정해지지 않아서 *로 표기하고 Optional의 경우, 0개거나 1이여서 0..1로 표기합니다.
Array와 같이 미리 사이즈를 지정한다면 [5] 와 같은 형태로도 표현할 수 있습니다.
의미는 속성과 메소드 둘 다 사용하여 표기가 가능합니다.
속성(변수)를 보면 접근 제어자, 필드명, 타입 순으로 작성합니다.
{접근제어자} {필드명}: {타입}
메소드는 접근제어자, 메소드명(파라미터 타입), 반환 타입 순으로 작성합니다.
{접근제어자} {메소드명}({파라미터타입}): {반환타입}
1-2 스트레오 타입(인터페이스, enum, 추상클래스)
인터페이스나 추상 클래스와 같은 요소를 표기하기 위해 << >> 와 같은 문법을 사용하는데 이를 길러멧(guillemet)이라 부릅니다.
길러멧은 클래스명 위에 작은 글씨로 작성합니다.
길러멧은 보통 인터페이스, enum, 추상 클래스 등에서 사용되지만 사용자의 확장 클래스를 의미하는데에도 사용할 수 있습니다.
추상 클래스를 나타내는 방법은 총 3가지로 이탤릭체(기울어진 글씨)로 표시하거나 클래스 명에 {abstract}을 붙이거나 길러멧으로 표시합니다.
1-3 클래스 다이어그램 관계 표시 규칙
다이어그램을 그림으로 그려야 하는데, 선을 어떻게 표시하는지 정리해 봤습니다.
이런 규칙을 적용하여 최종적으로 아래처럼 클래스 다이어그램을 그리고, 해석할 수 있겠습니다.
2. 유스케이스 다이어그램 (Use Case Diagram)
사용자(Actor)의 관점에서 시스템의 기능, 상호작용과 그들 간의 관계를 표현합니다.
클래스 다이어그램을 만들기 전에 사용자 친화적으로 만들 수 있는 다이어그램 입니다.
유스케이스 다이어그램을 사용하는 이유는 다음과 같습니다.
- 제품과 상호작용하여 얻을 수 있는 목표를 자세히 설명할 수 있습니다.
- 시스템의 요구사항을 요약하고 정의할 수 있습니다.
- 시스템 이벤트의 기본적인 흐름을 모델링할 수 있습니다.
- 요소마다 화살표를 넣어도 되고 안넣어도 됩니다.
유스케이스 다이어그램 구성요소
- 시스템 (Systems) : 어플리케이션 단위, 큰 흐름, 소프트웨어 컴포넌트 단위로 구현할 기능에 대한 모든 범위라고 보면 됩니다.
사각형의 형태로 표시, 상단에 시스템 이름을 정의하며, 내부에 타원형의 구성요소가 들어갑니다.
- 액터 (Actors) : 시스템 외부에 존재하는 수행 개체, 클라이언트, 유저 로 봐도 됩니다.
보통 사람 모형으로 표시하며, 하나 이상의 유스케이스와 상호작용 해야 합니다.
- 유스케이스 (Use Cases) : 시스템 내에서 수행되는 기능, 행위로 단순히 동작으로 생각해도 됩니다.
타원형으로 표시되며, 유스케이스 들 간에 상호작용 하며, 액터와 연결되기도 합니다.
- 관계 (Relationship) : 유스케이스 들 간에 상호작용을 표현하는 방법입니다.
-- 실선 으로 표시하며, 서로 상호작용 한다는 뜻이 됩니다.
-- 점선 으로 표시하며, 포함<<include>> 과 확장<< extend>>가 있습니다.
---- 포함 <<include>> : 하나의 유스케이스가 실행될 때 포함 관계에 있는 유스케이스가 반드시 실행되어야 합니다.
---- 확장 <<extend>> : 하나의 유스케이스가 실행될 때 특정 상황에 대해 실행하는 경우를 말합니다.
---> 점선 화살표에 <<include>> 또는 <<extend>> 를 포함시키면 됩니다.
유스케이스 다이어그램 만들때 주의사항
규모가 너무 커지면 상당히 복잡해질 수 있는 다이어그램 입니다.
어플리케이션에서 큰 기능 단위로 나누어 확인할 수 있으면 보기 편하고 좋습니다.
3. 시퀀스 다이어그램 (Sequence Diagram)
시스템의 동작을 시간 순서에 따라 표현합니다.
여러 시스템에서 동일한 시간선을 가지고 동작의 흐름을 표현하기 편리한 다이어그램 입니다.
dispatch : 보내다 라는 뜻으로, 동작의 시작/요청 을 의미합니다.
callback : 특정 동작이 끝난 뒤에 실행되는 부분/함수 를 의미합니다.
시간의 흐름에 따라 하나의 동작이 어느 시스템에서 어떤 순서대로 작동하는지 상세히 표현 가능합니다.
시퀀스 다이어그램 에서 구성요소와 규칙
공통적으로 약속된 시퀀스 다이어그램의 표현 규칙은 다음과 같습니다.
- 액터(Actor) : 시스템, 어플리케이션에 서비스를 요청, 실행하고 결과를 받는 주체입니다.
- 시스템(시스템, 어플리케이션, 객체) : 각 어플리케이션, 또는 외부 서비스, 서버, 시스템이 될 수 있으며, 각 각 생명선과 실행/동작을 갖습니다.
- 생명선(Lifeline) : 객체가 동작하는 시간을 표현한 것이며, 시스템 마다 생명선이 존재합니다.
- 실행(Activation) : 실행/동작 을 의미하며, 해당 시스템에서 동작하는 시간(시퀀스)에, 네모 상자로 표현합니다.
- 메시지(Message) : 객체간에 요청/응답 되는 전문, 메시지를 말합니다. 화살방향선으로 어느 시스템으로 이동되는지 표현합니다.
메시지 처리 방식에 따라 표현도 가능합니다.(동기/비동기)
- 동기 메시지(Synchronous Message): 메시지를 보낸 객체가 메시지의 응답을 기다립니다. 동기 메시지 호출은 꽉찬 화살표에 실선으로 표시합니다.
- 비동기 메시지(Asynchronous Message): 메시지를 보낸 객체가 메시지의 응답을 기다리지 않고 다른 작업을 수행합니다. 비동기 메시지 호출은 빈 화살표에 실선으로 표시합니다.
- 자체 메시지(Self message): 객체가 자신에게 메시지를 보냅니다. 생명선으로 회귀하는 화살표를 그립니다.
- 반환 메시지(Return/Reply Messages): 이전 호출의 반환을 기다리는 객체에게 다시 반환되는 메시지입니다. 반환 메시지는 빈 화살표 점선으로 표시합니다.
정리....
지금까지 다룬 UML은 다음과 같습니다.
1. 클래스 다이어그램 (Class Diagram): 시스템의 클래스들과 그들 간의 관계를 표현합니다. 클래스, 속성, 메서드, 관계 등을 나타내며, 객체 지향 설계에서 가장 기본적으로 사용됩니다.
2. 유즈케이스 다이어그램 (Use Case Diagram): 시스템의 기능적 요구사항을 나타냅니다. 액터(사용자 또는 시스템)와 유즈케이스(시스템이 수행하는 특정 기능) 간의 상호 작용을 보여줍니다.
3. 시퀀스 다이어그램 (Sequence Diagram): 시스템의 동작을 시간 순서에 따라 표현합니다. 객체 간의 상호 작용과 메시지 전달을 보여줍니다.
검색결과 다음의 UML이 더 있었으나, 평소에 자주 쓰며 쉽다보니 간단하게 이미지만 남겨보겠습니다.
상태 다이어그램 (State Diagram): 시스템이나 객체의 상태 변화를 어떻게 처리하는지를 보여줍니다.
액티비티 다이어그램 (Activity Diagram): 시스템이 수행하는 작업 흐름을 표현합니다. 프로세스나 작업의 순서를 보여줍니다.
컴포넌트 다이어그램 (Component Diagram): 시스템을 구성하는 컴포넌트와 그들 간의 의존성을 보여줍니다.
배치 다이어그램 (Deployment Diagram): 시스템의 물리적인 배치를 표현합니다. 하드웨어나 네트워크와 소프트웨어 구성 요소 간의 관계를 보여줍니다.
컴포넌트 다이어그램
https://www.edrawsoft.com/kr/diagram-tutorial/what-is-the-component-diagram.html
'IT기술 > CS(ComputerScience)' 카테고리의 다른 글
[CS] 직렬화(Serializable) 이해하기 (1) | 2024.10.02 |
---|---|
[CS] 인증 / 비인증 결제 (0) | 2024.09.10 |
[CS] 폭포수(waterfall) 방법론과 에자일(agile) 방법론 (0) | 2024.05.29 |
[MSA] 마이크로 서비스 아키텍처, 설계 전략, 사례 (1) | 2024.05.28 |
[MSA] 마이크로서비스 아키텍처, 모노리틱 아키텍처 이해하기 (0) | 2024.05.28 |