이제 UML은 극소수 개발자만 쓰는가?
설계: 생각을 ‘차려’ 물질로 만드는 힘
중국 플랫폼의 API 문서를 보다가 아주 오랜만에 UML 순차도(sequence diagram)가 실제로 쓰이고 있는 장면을 목격했습니다.
실용적으로 쓰이는 UML 순차도 사례
프로그램 공급처가 다른 다수의 기기에서 작동하여 한번에 영향을 끼치는 범위가 넓은 API에 대한 설명이기에 꽤나 적절한 도식화란 생각이 들었습니다.
출처: https://mp.kuaishou.com/docs/develop/server/epay/applyIntra-new/serverIntra-new.html자신이 작성한 프로그램의 작동 방식을 다른 개발자에게 설명할 때 UML 순차도(Sequence diagram)는 꽤 유용합니다.
예전 경험을 떠올려 보면, 다른 사람이 작성한 프로그램을 빠르게 파악할 때에도 UML 순차도를 그려 보는 일은 유용했던 것 같습니다. 어떤 순서로 호출이 되는지 시각화하다 보면 관계가 드러나고 전체적인 감이 잡혔던 경험이 있습니다. 물론 직접 코드를 보면서 파악해야 하기 때문에 개발도구와 UML 작성 화면을 동시에 사용하는 번거로움을 감수해야 합니다. 그럼에도 불구하고 이점이 있을 때가 있습니다.
순차도에 그리는 과정에서 모든 호출 관계를 나타낼 필요는 없으니까 이를 취사선택하는 일이 고스란히 분석의 과정이기도 하고, 작성자의 의도를 나 자신의 기준으로 수렴하는 과정이기도 합니다. 동시에 표현 자체가 현재 자신이 알고자 하는 부분 혹은 중요하게 생각하는 부분에 대한 결정이기도 합니다.
가장 널리 쓰여 온 클래스도
하지만, UML 중에서 가장 널리 쓰이는 그림은 아마도 클래스도(class diagram)가 아닐까 싶습니다. 순차도를 그리다 보면 길고 장황하게 보일 때가 있는데, 이때 객체(혹은 클래스)들과의 관계를 일목요연하게 보고 싶은 욕구를 표현하는 그림은 단연 클래스도가 제격입니다.
클래스도의 또 다른 이점은 꼭 클래스만을 표현할 필요는 없다는 점입니다. 어떤 개념이든 경계를 짓고 관계를 만들고자 한다면 클래스도를 써서 표현할 수 있습니다.
UML 모델링의 꽃은 상태도
하지만, 개인적으로 가장 유용하다고 생각하는 그림은 상태도입니다. 대부분의 프로그램이 상태관리를 DBMS나 미들웨어들에 맡기기 때문에 사실 그릴 일이 많지는 않습니다. 하지만, 개발자가 엄격하게 상태 관리를 해야 하는 경우를 발견했다면 굉장히 강력한 힘을 발휘합니다.
하지만, 한때 전문 모델러 역할도 했던 제 경험 속에서도 두 번 밖에 (제대로) 활용한 적이 없을 정도로 자주 활용하지는 못했습니다. 다음 그림은 당시 제가 그렸던 상태도를 기준으로 하여 만든 교육 자료인데, 볼 때마다 당시 난제를 풀고 효과를 본 분들이 저에게 감사 인사를 했던 일이 떠올라 뿌듯합니다.
자신의 이름을 건 솔루션을 만들고 싶은 개발자라면 UML 순차도 활용을 권할 만합니다.
지난 설계: 생각을 ‘차려’ 물질로 만드는 힘 연재
1. 내가 아닌 다른 사람은 모델링을 왜 하게 되는가?
4. 설계가 잘 쓰이려면 독자와 쓰임새가 분명해야 한다
7. Event Driven의 기원과 현실적인 활용 방법
8. 모델링에 대한 메타 인지: 모델링이라는 생각 차림법
