즉, 코딩하기 전에 설계도를 그린다는 것이다.
건물을 짓거나 자동차를 설계할때 우리는 설계도를 그린다.
소프트웨어도 별개는 아닐 터 설계도를 그리는 작업중 하나가 UML이다.
그럼 다이어그램의 유형부터 보자.
일단 깊게 들어가기 이전에 UML을 왜 써야 할까?
자동차 디자이너가 자동차 모양을 구상할때 가장 먼저 하는 일은 스케치북에 그리고
어마어마한 찰흙 덩어리를 자르고 사포로 문지르며 스케치한 모델을 만든다.
건축가는 건물을 설계하고 조감도를 그리고 축소 모델을 만들어서 건축주에게 Confirm을 받는다.
옷을 디자인할때도 스케치하고 재단해서 샘플 모델을 만들어서 피팅을 한다.
눈치가 빠른 분들은 위의 3가지 상황에서 공통적으로 튀어 나오는 단어를 찾았을 것이다.
그것은 바로 ‘모델’이다.
어떤 것이 실제로 만들어질지 또는 잘 작동하는지 알아보기 위해 만드는 것이 모델이다.
공통적인 개념으로 모델은 어떤 것을 미리 시험해 본다는 의미가 내포된 것이라 할 수 있다.
그럼 왜 소프트웨어 모델을 만들어야 하는가?
그림 그릴 시간에 그냥 코드 짜겠다. 굳이 꼭 모델을 만들어서 설계를 해야하나?
우리가 남이가..척하면 딱인데 뭘… 대부분 이런 반응들이다. 맞다.
적어도 내 생각에는 그림 그릴 시간보다 코드 짜는 시간이 덜 들어간다면 그렇게 해도 좋다.
모델링하는 비용보다 코딩하는 비용이 적다면 그렇게 해야 한다. 천편일률적으로 지켜야 한다는 것은 아니다.
효율과 효과를 따지면서 해야 한다.
생활속으로 들어가자.
우리는 일단 프로젝트가 진행되면 대강 사이즈 나오고 그에 맞춰서 처음에 어떻게 만들자고 칠판에 열심히 그리고 짧게 정리한다. 그렇게 하고 팀원들끼리 구현에 들어간다.
어라! 문서로 끄적이고 칠판에 그린다!? 모델링이다.
거창하게 두툼한 문서로 만들어서 클래스 하나, 알고리즘 하나, 한땀한땀 그리는게 아니라 팀원들끼리 어떻게 하자고 의사소통을 원활하게 하기위해 그린 그림이다.
우리는 많든 적든 이미 모델링을 사사건건 하고 있는 것이다.
그러면 UML을 표현하는 수준은 어디까지인가?
위에서도 이야기했지만 의사소통이 가능한 수준이다. 모델링 단계에서 세세한 것이 나올리 만무하다.
최대한 심플하게 미니멀리즘을 가지고 그려야 한다.
나와 팀원들이 이해할 수 있는 최소한의 기준으로 그림을 그리는 것이다.
그렇다면 문서화는 어떻게 해야 하나?
문서는 필수다. 코드를 보면 이해가 가는 수준은 작성하지 않아도 된다.
하지만 복잡한 DB의 스키마, 재사용이 복잡한 프레임워크등 복잡해서 코드를 봐도 이해하기 힘든 부분들에 한해서 작성한다면 짧은 문서로 가능할 것이다.
UML은 소프트웨어 작업을 하기위한 도구이다.
UML을 그리는 것이 목적이 되선 안된다.
다음편에는 종류를 알아보고 몇가지 다이어그램을 소개하겠다.
To infinity and beyond! 