UML 다이어그램 정리 (종류, 사용법)

ZEDY·2024년 3월 29일
serveruml
0

개발

목록 보기
1/11

서론

들어가기에 앞서 : UML을 작성해야 하는 이유

개발은 코드 짜는거 아니야? 라고 단순하게 생각할 수 있습니다.
하지만, 코드는 도구일 뿐 그 코드를 '어떻게' '왜' 그렇게 설계했는지가 무엇보다 중요하다고 생각합니다.

소프트웨어 개발은 복잡한 과정으로, 수많은 요구사항과 기능을 충족시키기 위해 체계적인 계획과 설계가 필요합니다. 이러한 설계는 개발의 초기 단계에서부터 시작되며, UML(Unified Modeling Language)은 이러한 설계를 시각적으로 표현하고 이해하기 쉽게 도와주는 강력한 도구입니다.

UML은 다양한 다이어그램을 제공하여 시스템의 다양한 측면을 모델링하고 문제를 해결하는 데 도움을 줍니다. 이러한 다이어그램을 작성하는 과정은 개발자들이 시스템을 보다 명확하게 이해하고, 요구사항을 명세화하며, 설계 결정을 내리는 데 도움이 됩니다.

본격적인 개발을 시작하기 전에 UML을 작성하는 것은 다음과 같은 이유로 중요합니다.

  1. 요구사항 이해 : UML 다이어그램을 작성하는 과정은 개발자들이 시스템의 요구사항을 이해하고 명세화하는 데 도움을 줍니다. 이를 통해 개발자들은 시스템의 기능과 동작을 명확히 파악할 수 있습니다.

  2. 설계 결정 지원 : UML은 시스템의 구조, 동작, 상호 작용 등을 시각적으로 표현하는 다양한 다이어그램을 제공합니다. 이러한 다이어그램을 작성하고 검토함으로써 개발자들은 설계 결정을 내리는 데 도움을 받을 수 있습니다.

  3. 팀 협업 강화 : UML 다이어그램은 개발 팀 간의 의사 소통을 강화하고 협업을 촉진합니다. 시스템의 구조와 동작에 대한 시각적인 표현은 팀원들이 이해하기 쉽고 토론하기 용이하도록 돕습니다.

  4. 변경 관리 : 개발 초기에 UML을 작성함으로써 시스템의 구조와 요구사항을 명확히 이해하고 문제를 미리 파악할 수 있습니다. 이를 통해 나중에 발생할 수 있는 변경에 대비하고, 변경을 관리할 수 있습니다.

필자의 경험을 섞어서 이야기를 해보겠습니다.

저는 이미 개발 중인 어플리케이션의 중간 투입으로 백엔드 서버 개발자로 투입된 적이 있습니다. 이 경험을 통해 UML 작성의 중요성과 그 이점을 명확하게 이해하게 되었습니다.

처음에는 이미 존재하는 백엔드 서버 코드를 '뜯어보는' 과정이 저에게 주어졌습니다. 하지만 코드만으로는 전반적인 시스템 구조와 각 모듈 간의 관계를 이해하기 어려웠습니다. 그래서 UML을 활용하여 기존 코드를 분석하고 문제를 해결하는 데 큰 도움이 되었습니다.

UML을 사용하여 클래스 다이어그램을 작성하고 기존 코드의 클래스와 메서드 간의 관계를 시각적으로 파악할 수 있었습니다. 이를 통해 코드의 구조를 더 잘 이해하고, 수정이 필요한 부분을 빠르게 식별할 수 있었습니다.

또한, 유즈케이스 다이어그램을 통해 시스템의 기능적 요구사항을 명확히 이해하고, 이를 기반으로 개발해야 할 기능을 파악할 수 있었습니다. 이는 새로운 기능을 추가하거나 기존 기능을 변경할 때 개발자들 간의 의사 소통을 원활하게 해주었습니다.

또한, UML 다이어그램을 작성하는 과정에서 시스템의 설계 결정에 대해 토론할 수 있는 기회를 가졌습니다. 이는 팀 간의 협업을 강화하고, 개발자들이 서로의 의견을 공유하고 존중할 수 있도록 도왔습니다.

전체적으로 UML을 작성하는 과정은 개발 초기에 시스템을 명확하게 이해하고 문제를 미리 파악하는 데 큰 도움이 되었습니다. 또한, 기존 코드를 분석하고 이해하는 데도 많은 도움이 되었으며, 팀 간의 협업을 강화하고 효율적인 개발을 가능하게 했습니다.

본론

그래서 UML이 뭔데?

UML(Uniform Modeling Language)은 소프트웨어 개발에서 시스템의 설계, 분석, 구현 등을 시각적으로 표현하기 위한 표준화된 언어입니다. UML 다이어그램은 이러한 UML 언어를 사용하여 시스템의 다양한 측면을 모델링하고 표현하는데 사용됩니다. 다양한 UML 다이어그램 유형이 있으며, 각각의 유형은 특정한 측면이나 관점에서 시스템을 나타냅니다.

UML 다이어그램 종류 및 특징

1. 클래스 다이어그램(Class Diagram)

  • 클래스 다이어그램은 시스템의 클래스들과 그들 간의 관계를 표현합니다.
  • 클래스, 속성, 메서드, 관계 등을 나타내며, 객체 지향 설계에서 가장 기본적으로 사용됩니다.
  • 본격적으로 코드 작성하기 전, 함께 협업을 하는 서버 담당 개발자들끼리 모여 함께 설계를 하곤 합니다.
  • 개발 통일성을 유지하는게 생각보다 중요합니다. 왜냐하면 혼자 개발하는 것이 아니고, 자신이 개발한 것을 다른 사람이 추가 개발할 가능성이 있기 때문입니다.

2. 유즈케이스 다이어그램(Use Case Diagram)

  • 유즈케이스 다이어그램은 시스템의 기능적 요구사항을 나타냅니다.
  • 액터(사용자 또는 시스템)와 유즈케이스(시스템이 수행하는 특정 기능) 간의 상호 작용을 보여줍니다.
  • 보통 기획 단계에서 진행합니다. 저는 피그잼을 사용합니다.
  • 사용자가 시스템을 키는 순간부터 끄는 순간까지 어떤 플로우로 작동할 것인가 기능적으로 나타낸 것을 의미 합니다.

3. 시퀀스 다이어그램(Sequence Diagram)

  • 시퀀스 다이어그램은 시스템의 동작을 시간 순서에 따라 표현합니다.
  • 객체 간의 상호 작용과 메시지 전달을 보여줍니다.
  • 시스템 자체에서 어떻게 데이터를 전달할 것인지 나타낸 것입니다.

4. 상태 다이어그램(State Diagram)

  • 상태 다이어그램은 시스템이 객체의 상태 변화를 어떻게 처리하는지를 보여줍니다.
  • 객체가 특정 조건에서 어떤 행동을 취하고 다른 상태로 전이하는 과정을 표현합니다.

5. 활동 다이어그램(Activity Diagram)

  • 활동 다이어그램은 시스템이 수행하는 작업 흐름을 표현합니다.
  • 프로세스나 작업의 순서를 보여줍니다.

6. 컴포넌트 다이어그램(Component Diagram)

  • 컴포넌트 다이어그램은 시스템을 구성하는 컴포넌트와 그들 간의 의존성을 보여줍니다.
  • 시스템의 구조를 이해하고 컴포넌트 간의 관계를 파악하는 데 사용됩니다.

7. 배치 다이어그램(Deployment Diagram)

  • 배치 다이어그램은 시스템의 물리적인 배치를 표현합니다.
  • 하드웨어나 네트워크와 소프트웨어 구성 요소 간의 관계를 보여줍니다.

UML 다이어그램은 개발 과정에서 요구사항 분석, 설계, 구현, 테스트 등 다양한 단계에서 사용됩니다. 이러한 다이어그램을 통해 시스템의 구조와 동작을 시각적으로 이해하고 문제를 해결할 수 있습니다.

그래서 백엔드 서버 개발자가 작성해야하는 UML이 뭔데?

개발자라고 해서 단순히 개발을 잘해서는 안됩니다.
내가 풀고자 하는 문제가 무엇인지 명확하게 이해해야하며, 어떻게 풀어야 하는지 누구보다 잘 이해해야 합니다.
그래서 저는 모든 다이어그램에 대해서 어느정도 이해도가 있어야 한다고 생각합니다.
그중에서도 백엔드 서버 개발자가 중심이 되어 작성해야 하는 UML은 다음과 같습니다.

  1. 클래스 다이어그램(Class Diagram)
  • 코드베이스의 구조를 모델링하는 과정입니다.
  • 클래스 다이어그램은 클래스, 속성, 메서드 및 다른 클래스와의 관계를 시각적으로 표현하여 백엔드 시스템의 전반적인 아키텍처를 이해하고 코드베이스에 변경 사항을 계획하는 데 도움이 됩니다.
  • 쉽게 설명을 하자면, 엔티티의 구성과 이에 따른 상호작용 및 모듈화 구조를 나타낸 것입니다.
  • 즉, 개체끼리의 관계를 시각화 한 것입니다.
      +--------------+           +----------------+
  |   Customer   |           |     Order      |
  +--------------+           +----------------+
  | -customerId  |           | -orderId      |
  | -name        |           | -orderDate    |
  | -email       |<>-------*-| -totalAmount  |
  +--------------+           +----------------+
  1. 시퀀스 다이어그램(Sequence Diagram)
  • 백엔드 시스템의 다양한 구성 요소 또는 모듈 간의 메시지 교환 또는 상호 작용의 흐름을 설명하는 데 사용됩니다.
  • 특정 작업 또는 프로세스 중에 발생하는 작업의 순서를 시각적으로 보여주어 백엔드 로직의 이해와 설계에 도움이 됩니다.
       Customer        OrderSystem        PaymentGateway
       |                  |                  |
       |---placeOrder()-->|                  |
       |                  |                  |
       |                  |---processPayment()->|
       |                  |                  |
       |<--orderConfirmed-|                  |
       |                  |                  |
  1. 컴포넌트 다이어그램(Component Diagram)
  • 컴포넌트 다이어그램은 시스템의 논리적 또는 물리적 컴포넌트 및 그들 간의 의존성을 표현합니다.
  • 백엔드 개발자는 컴포넌트 다이어그램을 사용하여 백엔드 애플리케이션의 다양한 구성 요소(예: 데이터베이스, API, 미들웨어, 외부 서비스) 및 그들 간의 관계를 시각적으로 파악할 수 있습니다.
  • 보통 이거는 서버 아키텍쳐 이미지로 구상을 하곤 합니다. 그러면 훨씬 이해하기 편리합니다. 아이콘 이미지로 쉽게 파악 가능합니다.
    +-----------+         +-------------+
|  Backend  |         |   Database  |
+-----------+         +-------------+
|           |  depends|             |
|           |-------->|             |
|           |         |             |
+-----------+         +-------------+
  1. 배치 다이어그램(Deployment Diagram)
  • 배치 다이어그램은 소프트웨어 컴포넌트가 하드웨어 노드에 배치되는 방식을 표현합니다. 백엔드 개발자는 배치 다이어그램을 사용하여 백엔드 애플리케이션이 서버, 가상 머신, 컨테이너 또는 클라우드 플랫폼에 어떻게 배치되는지를 시각적으로 이해하고 네트워크 구성 및 통신 프로토콜과 같은 세부 정보를 포함할 수 있습니다.
  • 솔직히 이거까지 작성해본 적은 통신연구실에 학부연구생으로 있을때 빼곤 없긴 합니다. 어플리케이션 프로젝트에서는 HW와 통신하는 로직이 없는 이상 별로 안합니다.
    +---------------+       +---------------+
|   Backend     |       |    Database   |
|   Server      |       |   Server      |
+---------------+       +---------------+
|               |       |               |
|               |       |               |
+---------------+       +---------------+

이러한 UML 다이어그램은 백엔드 개발자가 사용하는 일반적인 유형입니다. 그러나 사용되는 다이어그램의 종류는 프로젝트나 팀의 요구 사항, 개발 방법론에 따라 달라질 수 있습니다. UML의 목표는 백엔드 개발 프로세스 전반에 걸쳐 커뮤니케이션, 설계 명확성 및 개발 효율성을 향상시키는 것입니다.

도구

솔직히 말해서 협업하는 개발자끼리 모여서 직접 화이트보드에 그려가면서 작성을 하는게 좋긴 합니다. 소통하기 원활하고 바로바로 수정을 할 수 있습니다. 툴에 익숙해질 필요도 없고요.
하지만, 문서화를 시키는 것은 필수입니다.
그러기 위해서는 다음과 같은 도구들을 활용할 수 있습니다.

유저 플로우 다이어그램 등

  1. 피그마
  2. 피그잼

두개 다 유명한 툴이죠. 저는 UI를 짤 때 피그마를 활용해서 짭니다. 커뮤니티도 너무 잘되어 있어서 레퍼런스나 뭐.. 유용한거 찾기 너무 좋습니다.
피그잼은 유저 플로우나 개발 아키텍쳐를 주로 나타내곤 합니다.

서버 개발을 위한 다이어그램

  1. starUML
  2. draw.io

저는 둘다 써봤는데 draw.io는 자동으로 클라우드 저장이 됩니다.
구글 드라이브와 연동시켜서 협업을 할 수도 있어서 저는 draw.io가 훨씬 좋았습니다.
그리고 starUML은 조금 .. 불편했습니다. 설명이 불친절하다고 해야하나..
암튼 draw.io 추천드립니다.

결론

지금까지 UML에 대해 알아봤습니다.
본격적으로 개발하기 전, UML 설계하여 보다
1. 효율적이고
2. 유지보수가 용이하며
3. 협업하기 좋은
개발을 진행하기 바랍니다.

profile
ZEDY
Spring Boot 백엔드 주니어 개발자
다음 포스트

Java Method의 반환형을 interface로 하면 ?

0개의 댓글