[목차여기]
UML(Unified Modeling Language)
UML은 통합 모델링 언어이다. '통합', '모델링', '언어' 이렇게 단어를 하나씩 떼어 보면 그 정의를 짐작할 수 있다. 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법이다. 소프트웨어 설계 제안, 이미 완성된 소프트웨어 구현에 대한 다이어그램을 그릴 때 UML을 사용한다. 우리는 프로그램에 대해서 코드를 설명하지 않아도 그림으로 설명이 가능하다. 즉, UML은 의미를 가진 그림 요소이며 프로그램을 다이어그램화 한 것이다.
*다이어그램 : 점, 선, 기호를 사용하여 어떤 상황의 상호 관계나 과정 및 구조 등을 이해시키는 그림.
다이어그램
다이어그램에는 여러 수준의 다이어그램이 존재한다.
- 개념(분석)
- 설계 ⭐️
- 구현 ⭐️
설계 차원과 구현 차원의 다이어그램은 소스코드와 관계가 깊다. 왜냐하면 설계 차원의 다이어그램은 결국 소스코드로 바꾸기 위해 그리는 것이며, 구현 차원 다이어그램도 이미 있는 소스코드를 설명하려고 그리기 때문이다. 따라서 이 두 차원은 반드시 일정한 규칙과 의미론을 지켜야 한다.
반면, 개념 차원에 속한 다이어그램은 소스코드와 관계가 깊지 않다. 이 차원의 다이어그램은 의미하는 바가 모호하거나 해석에 따라 달라질 수 있다. 예를 들어, '판다는 동물이다.'라는 문장을 생각해 보자. 이 문장을 표현하는 개념 차원 다이어그램은 아래 사진처럼 만들 수 있다.
"Animal은 Panda를 일반화한 것이다. Panda는 Animal의 특정한 경우다." => 다이어그램에 들어 있는 의미는 이것이 전부다.
이 다이어그램의 의도는 에버랜드의 푸바오가 동물이라는 것을 말하는 것일 수도 있고, 판다라는 생물종이 동물의 왕국에 속한다는 것을 말하는 것일 수도 있다. 즉, 이 다이어그램은 어떻게 해석하느냐에 따라 의미가 달라진다.
하지만, 설계 차원이나 구현 차원에 있다면 의미를 명확히 할 수 있다.
public class Animal {}
public class Panda extends Animal {}
따라서, 앞으로 우리는 설계 차원과 구현 차원의 다이어그램을 그릴 것이다.
UML을 사용하는 이유
왜 모델을 만들어야 할까?
우리가 비행기를 설계한다고 생각해 보자. 만약 설계대로 비행기를 만들어서 시험해본다면? 그리고 그것이 실패한다면? 상당한 비용과 리소스가 낭비된 것이다. 따라서 비행기가 실제로 잘 작동하는지 시험해 보기 위하여 모델링이 필요하다.
왜 소프트웨어 모델을 만들까?
UML은 코드로 시험하는 것보다 UML로 시험하는 것이 비용이 적게 들 때 사용한다. 하지만, 사실 UML 다이어그램은 확고한 시험 기준이 없다. 우리가 UML 다이어그램에 여러 원칙과 패턴을 적용하여 평가할 수 있지만 결국 주관적일 수밖에 없다. 그럼에도 불구하고 UML을 사용하는 이유는 코드를 파기하는 것보다 UML을 다시 작성하는 것이 훨씬 비용이 적게 들기 때문이다.
비행기를 만들어놓고 실패한다면 그 비행기를 만들기 위해 사용된 철, 콘크리트, 기름 등 이것들은 모두 의미가 없게 되며 처음부터 다시 제작해야된다. 하지만 UML을 계속 수정하는 것은 적어도 이것들이 낭비되진 않는다.
UML을 효과적으로 사용하려면
설계에 대하여 사람들과 의사 소통하고, 반복을 통해 다듬으며 행위를 가장 먼저 생각하도록 한다.
당연한 얘기일 수 있지만 UML은 소프트웨어 개발자들끼리 소통할 때 유용하다. 말로 아이디어를 전달하는 것보다 그림을 통해 전달하면 더 이해하기 쉽다. 그리고 아무리 뛰어난 개발자라고 한 들, 한 번에 완벽한 UML을 그릴 수 없다. 행위를 가장 먼저 생각하며(전화를 걸기위해 다이얼을 누른다, 통화 버튼을 누른다 등) 점점 확장해나가는 것이 좋다.
나의 상황에 대입해보자면 관계형 데이터베이스를 설계할 때 처음부터 한 번에 테이블을 결정하기 쉽지 않다. 팀원들과 고민에 고민을 거듭어 가며 테이블을 결정하고 컬럼을 채워나가듯이 UML도 의사소통하며 반복을 통해 다듬는 것이 좋다고 생각한다. 행위가 치트키
UML을 사용하는 이유는
- 코드를 파기하는 것보다 UML을 다시 작성하는 것이 훨씬 비용이 적게 든다.
- 시스템에 대한 이해가 다른 사람과 같은지 확인할 수 있는 수단이다.
- 객체 지향 설계를 더 잘 표현하는 방법이다. (소스코드를 더 정확하게 알 수 있다.)
- 설계자의 생각을 진화시키게 한다.
'Knowledge > 디자인 패턴' 카테고리의 다른 글
[구조 패턴] 어댑터 | 퍼싸드 | 컴포지트 | 브리지 패턴 (with 예시 코드) (0) | 2024.07.25 |
---|---|
SOLID란? - 객체지향 개발의 원칙 (0) | 2024.04.08 |
클래스 다이어그램 그리기 - 기본편 (0) | 2024.04.06 |