티스토리 뷰
발생일: 2010.02.16
문제:
오랜만에 회사 온라인 강의를 신청해 들어볼까 싶어서 교육 사이트를 둘러보다가,
'알기 쉬운 UML' 강좌의 화려한 플래시에 혹~ 해서 신청 버튼을 눌러버렸다.
UML 은 이미 대략적인 개요를 알고 있고, (여러 다이어그램 중 클래스 다이어그램만 마음 먹은대로 쓸 수 있는 수준이다)
업무를 포함하여 평소에는 다이어그램을 쓸 일이 거~~의 없어서 그다지 관심있는 편은 아니었다.
다만, 얼마 전 IBM 의 UML 컬럼 강좌을 보고서는,
문제:
오랜만에 회사 온라인 강의를 신청해 들어볼까 싶어서 교육 사이트를 둘러보다가,
'알기 쉬운 UML' 강좌의 화려한 플래시에 혹~ 해서 신청 버튼을 눌러버렸다.
UML 은 이미 대략적인 개요를 알고 있고, (여러 다이어그램 중 클래스 다이어그램만 마음 먹은대로 쓸 수 있는 수준이다)
업무를 포함하여 평소에는 다이어그램을 쓸 일이 거~~의 없어서 그다지 관심있는 편은 아니었다.
다만, 얼마 전 IBM 의 UML 컬럼 강좌을 보고서는,
'+ methodName ( ParameterName: ParameterType ) : ReturnType ...'
'요고요고 띄어쓰기도 좋고, 깔끔하니 있어 보이는데~'
하는 생각이 들어서 작성 기법에 개인적으로 후한 점수를 주기는 했다.
여튼, (서론이 굉장히 길었다... )
강의 시작이 보름이나 지난 오늘에야 접속해서 내용을 훑어보던 중,
이런 생각이 들었다.
'TDD 를 하다보면 Test Case 를 먼저 작성하는데게 되는데, 그럼 UML 자체가 의미없지 않은가?'
'XP 에서 추구하는 가치 측면에서 보면 UML 도 어쩌면 비효율적이고 구시대적인 문서가 아닌가?
해결책:
아래 포스트에서 해답이 될 만한 답변을 얻었다.
너무 근시안적으로 사고하지 않았나 싶다.
다이어그램을 그리는 주목적을 잊고 도구적인 측면으로만 생각하고 있었다.
특히, 애니메이션을 하다 프로그래밍에 뛰어든 나는,
습관적으로 '어떻게 하면 더 예쁘게 그릴까'에만 너무 많은 초점을 두고 있었다...
(이건 코드를 작성할 때도 마찬가지다. 너무 "깔끔"한 코드에만 연연하고 있는 건 아닐까.. 란 생각도 들었다)
"먼저 여러분이 다이어그램을 무엇을 위해 그리고 있는지 명심하라.
첫 번째 가치는 의사소통이다.
효율적인 의사소통은 중요한 것을 선택하고 덜 중요한 것은 무시하는 것을 의미한다."
첫 번째 가치는 의사소통이다.
효율적인 의사소통은 중요한 것을 선택하고 덜 중요한 것은 무시하는 것을 의미한다."
우리가 UML 을 그리고자 한다면, 그건 효율적인 커뮤니케이션을 위함일 것이다.
위에서 했던 질문에 대한 답변을 자연스레 얻을 수 있다.
반응형
댓글
공지사항