UML 만들기

UML (Uniform/Unified Modeling Language)?

소프트웨어나 시스템을 ‘그림’으로 표현하는 표준 기법
설계와 커뮤니케이션, 문서화를 위한 공용 시각 언어

• 설계 개념의 공유 : 팀 혹은 미래의 나에게 ‘구조’에 대한 ‘직관적 설명’
  
• 분석 / 검증 : 클래스의 표현이 누락된 부분 / 순환 참조 / 수명 문제 등의 문제 검토
  
• 문서화 : ‘만들 클래스의 구조’를 시각적으로 표현하여 문서에 포함하기 좋음
  

간단한 기호 설명

상속: 자식 ─▷ 부모(속 빈 삼각화살) → is-a

실체화(인터페이스 구현): 점선 삼각화살

합성: ◆— 소유/수명 함께감 (소유자 죽으면 부품도 소멸)

집합: ◇— 약한 소유(거의 안 씀; 헷갈리면 연관으로)

연관: — 필드/포인터 참조

의존: - - - > 파라미터/임시 사용

다중성: 1, 0..1, , 1.. 꼭 표기

사용 플랫폼

draw.io

첫 UML 제작

피드백 - (By. 손승현 튜터님)

UML 자체 : 현재 여러 표현이 ‘모호’하다

• 부모, 혹은 데이터 표현 구조체는 ‘위쪽’으로
  사용하는 클래스나 자식 클래스는 ‘아래쪽’으로 놓으면
  전반적인 흐름이 정리됨
  

• 특정 클래스/구조체를 ‘색’을 통한 구분
  (시각적 효과)
  

• 화살표의 의미를 파악하기 힘듦
  텍스트 or 화살표에 대한 의미 설명이 필요
  

클래스 구조

• PlayerBase, EnemyBase로 만들고
  세부 직업/몬스터를 구현하는 방식 고려
  

• Input 부분은 Player가 소지하여
  처리할수도 있음
  

• GameManager가 ‘정확히’ 무엇을 관리해야 하는가?
  (EnemyData를 관리해야할 이유?)
  

피드백 적용한 UML

UML 부분

• 각각의 용도에 맞도록 ‘색’을 추가하여
  가시성을 개선
  (+ 색별 설명 추가)
  

• 텍스트를 추가하여 추가적인 설명
  

클래스 부분

• Manager를 더 세부적으로 추가
  (EnemySpawnManager, BattleManager 등)
  

• GameManager는 Player를 가지고 그를 이용하여
  입력과 Inventory 호출 등을 처리
  (이 방식이 아니더라도 별도의 MainGame 등을 만들어 처리 가능)
  

후기

해당 UML 프로젝트

사실상 몇시간을 들여서 만드는 것이 과연 옳은가?
라고 여기게 되는 작업이긴 하였지만…

지금 다시 보니 ‘시각적’으로 ‘구조’를 표현하기는
이만한 것이 없다고 다시금 여긴다

• 사실 문서화 작업 대부분이
  ‘이만큼 시간을 쏟아서 해야 하나?’
  같은 느낌을 주지만
  막상 완성하면 ‘잘만들었네’ 싶은 느낌이 든다