COM은 Component 기반의 프로그램을 위한 개념이기 때문에 이를 지원하기 위한 도구로써
UML은 매우 강력하다.
UML은 반드시 Component를 위한 언어는 아니지만,
C++, JAVA와 같은 Object기반의 언어라던가
ATL/COM같은 Component기반의 개념 및 라이브러리에서는 막강한 힘을 발휘한다.
특히, 여러 사람이 작업할때 UML로 만들어진 문서가 있다면,
소프트웨어 내부를 속속들이 들여다 볼수 있다.
UML은 어찌보면 소프트웨어라는 제품의 설계도이기 때문이다.
요구사항에 주로 쓰이는 Use Case라던지
객체지향 및 컴포넌트의 구조를 명시한 Class Diagram
소프트웨어 진행 및 상태을 나타내는 Sequence Diagram이나 State Diagram등의
UML구성요소들은 각각의 쓰임새에 맞게 매우 강력하고, 표준화되어 있다.
문제는......
다른 여러 도구나 개념이 그렇듯이 UML에 대한 학습이다.
이렇게 강력하고 사용한기 좋은 UML이 잘 쓰이지 않는 가장 큰 이유는
내 생각에는 개발자들의 귀잖음이 말하는...
"그건 오히려 방해만 되" 라는 표현이다.
물론 그것이 꼭 틀린말은 아닐 것이다.
그래도 이왕이면 공부해보고, 써본후에 그런 말을 해보는 것이 낫지 않을까?
나의 경우엔 실제로 UML을 프로젝트 단위에서 작성해서 이를 프로젝트에 구현해본 결과
생각보다 큰 효과를 낼수 있었다.
고객의 요구사항을 명확히 정의할수 있었고,
개발자들의 소프트웨어 설계를 공유하고 통합할수 있었다.
뭐 안쓰겠다면 어쩔수 없는 일이지만^^
강력한 UML이 보다 널리 이용되길...
이왕이면 외국 Rational Rose보다는 국산 Plastic Software의 사용이 많아지길
기대해본다.