설계할때 유스케이스, 클래스, 시퀀스, 스테이트, 액티비티 다이어그램 정도를 사용해 왔습니다.
꼭 필요한 경우도 있었지만, 보통은 문서화를 위해 UML을 사용했다고 보면 될것 같습니다.
그래서 UML은… 뭐 뭐랄까? 좋은 설계와 커뮤니케이션을 위해 원칙적으로는 필요한건 맞는데, 시간과 노력을 쏟는것에 비해 효과가 떨어지는것 같습니다.
애자일 관련 책을 보면 UML을 무조건 배척하는 것이 아닌 공존을 이야기하고 있는데… 막상 설계 문서를 꼭 요구하는 프로젝트는 별다른 대안이 없이 모든것을 UML로 그리고 있습니다.
다른분들은 설계나 문서화시 어떤식으로 소프트웨어 구조나 동작을 설명하시나요?
저는 설계 시점에서 이런 시각화 도구를 쓰는 것에 반대입니다.
코드로 빨리빨리 쳐보고 테스트해보는 시간도 소중한데 언제 바뀔지도 모르는 비지니스를 UML 도구 익히는데도 한 세월 걸리는데다 그런 시각화 도구들이 대부분 없는 것보다야 생산성이 좋지만 생산성이 좋다고 생각하지는 않습니다.
그래서 할거라면 코드 기반으로 UML을 제네레이트 시켜주는 도구를 쓰는 것이 그나마 나은 선택같습니다.
무료는 UML이 좀 개떡같이 나오는데 유료 Drawing(TALA) 은 꽤 정돈이 잘되어서 튀어나옵니다.
저는 1차 릴리즈를 끝내고 문서화를 위해 이런 도구를 이용해서 UML을 뽑는게 맞지않을까 생각합니다.
시간낭비라고 생각하기 때문입니다.
코드도 치다보면 추상화 레벨도 계속해서 바뀌는데 문서 업데이트는 어느 세월에…ㅠ
저는 규모의 문제라고 생각합니다. 시각화 도구는 중요하기는 하지만 대부분 개발 설계 기간이 전체 개발 기간에 잘 반영 안되는 경향이 있어서 부담되는 활동이긴 합니다.
저는 유스케이스, (부분) 시퀀스, (부분) 상태, (부분) 액티비티를 사용하는 편입니다.
UML을 가끔씩 사용하니 항상 제자리 걸음이기도 하고, 어떤 프로젝트는 시간도 부족한데 설계문서까지 완벽하게 제출하는 것을 원해서 항상 어려움을 겪고 있습니다.
결국엔 프로젝트 막바지에 설계문서의 UML을 실제 구현된 대로 다 업데이트하기는 하지만, 이걸 누가 과연 볼까? 라고 생각해보면… 그건 또 아니라서, 문서 업데이트에 너무 시간을 낭비하는게 아닌가 하는 생각까지 듭니다.
타협점을 찾아야 하는데, 수주 받아서 하는 프로젝트는 쉽지 않네요.
분석, 설계 시간을 충분히 주는 회사는 찾아 보기 힘들죠…
아마 대부분이 개발 막바지에 산출물로 만들겁니다.
저 역시 돌아 다니는 모든곳에서 그렇게 작업 해왔습니다.