요즘 어느 정도 경력이 있는 개발자라면 UML을 작성하거나 , 작성된 UML을 이해하는게 그리 어렵지 않을 것이다. 하지만 내가 98년도에 프로젝트를 진행할 때 UML로 이용하여 설계를 진행한다고 했을때 과연 그게 무엇인지 도저히 감이 오지 않았다. 물론 그 당시에는 관련 책도 별로 없어서 아마존에서 책을 구매했던 기억이 난다. 그 당시 프로젝트를 관리했던 PM은 대학원에서 UML을 전공했으며 여러가지 국책 프로젝트를 UML로 진행한 경험이 있는 PM이었지만 지금 생각해보면 프로젝트 진행시에 UML을 언제 얼마나 사용을 해야 하는지 모르고 진행했던거 같다.
요즘도 많은 프로젝트 설계 시 UML을 작성하는데 엄청난 시간과 에너지를 낭비하는거 같다. 로버트 C.마틴의 UML for java programmer 라는 책을 보면 언제 다이어 그램을 그려야 하는가? 에 대한 답을 쉽게 찾을 수 있다. 아래 내용은 그 책에서 발췌한 내용이다.
다이어 그램을 그려야 할때
- 프로젝트에 참가한 사람들이 설계에서 특정한 부분의 구조를 이해해야 할때
- 특정 요소의 설계 방법에 상이한 의견을 가지고 있어, 의견을 모을 필요가 있을때
- 여러가지 설계 아이디어를 시도해보고 싶을 때
- 누군가에게 특정 코드 일부분의 구조를 설명할 때
- 프로젝트 마지막에 고객이 특정인을 위해 다이어그램을 요구할 때
다이어 그램을 그리지 말아야 할 경우
- 프로젝트 과정에 다이어그램을 그려야 한다는 공정이 들어갔을 때
- 다이어그램을 안그리면 죄책감이나 훌륭한 아키텍트가 아니라고 느낄 때
. 진정한 소프트웨어 아키텍트는 자신의 설계를 코딩하는 아키텍트이다.
- 코딩 전 포괄적인 문서를 만들기 위해 다이어그램을 그릴 때
- 다른 사람에게 어떻게 코딩을 하는지 보여주기 위해 이용할 때
Welcome to Chan's blog.
I will write articles about technology and trends related IT Paradigm, Computer Programming (especially java).
In addition, articles about things I am interested such as music, movie also will be posted.