1. 유용한 단축키
2. 시퀀스 다이어그램 기능
3. 형상관리 제약사항
4. 노트 연결 제약사항
5. UML2 Nesting connector
6. 프레임없는 이미지 복사

유용한 단축키
F3 다이어그램 작성시 연속 선 긋기
Shift + F3 다이어그램 작성시 마지막에 선택한 UML 요소 재 선택
F4 색깔 등의 모양 바꾸기
Ctrl + F4 현재 윈도우 닫기
F12 소스 보기


시퀀스 다이어그램 기능
EA에서 시퀀스 다이어그램을 작성하다가 놀라운 기능을 발견했다.

시퀀스를 작성하다 보면 중첩 호출을 표현할 때 섬세한 마우스질을 요구했다. 그런데, EA에는 activation level을 높였다 내렸다 할 수 있는 버튼이 만들어졌다. 호~

(4/22 22:00 추가)
UML 2.1의 Interaction Use 지원 > Interaction Occurence 요소
스펙에서는 InteractionUse는 상호작용(interaction)에 대한 참조를 의미한다.
EA에서는 Interaction Occurence로 표시한다. 사용법은 기존의 상호작용도(Interaction diagram)를 D&D 하면 된다.

Rose에서는 노트를 만들고, 그 위에 다이어그램을 떨어뜨려서 링크를 만들었는데. 다이어그램에서 중복을 제거하고 가독성을 높이는데 용이하다. 프로그램에서 공통 함수 빼내는 것과 같다.


형상관리 제약사항

Rose 이후의 주류 모델링 도구들이 너무나 불편해서, 90년대 후반에 나온 Rose에 대략은 기능 보강을 한 정도인 EA에 대해서 지나치게 호평만 했다. 특히, EA의 버전 관리 지원은 최상급에서는 RSA의 형상관리 문제에 비교해 훌륭하다고 한 것인데 실전에서는 역시 문제가 발생했다.

XML로 저장하는 일반 모델 파일의 형상관리는 OK이다. 마지막 작업자가 체크인(Check in)을 안하면 다음 작업자가 모델링을 못하는 File-lock 방식에 불평을 하는 팀원도 있었지만, 모델링은 Optimistic lock보다는 File lock(Pessimitic lock) 방식이 좋다. CVS/SVN에 익숙한 개발자가 File lock기반의 VSS가 불편하다고 하는 것처럼,  VSS에 익숙한 개발자들만 있는 곳에서 CVS의 Optimistic lock을 심하게 불평하는 경우도 있다.(CVS를 실제 프로젝트에서는 못쓴다고..ㅡㅡ;)

EA로 형상관리할 때 진짜 문제는 코드와 모델을 싱크한 경우에 발생했다. EA에서는 XML 단위로 모델만 형상관리하지만, 코드 전체가 XML로 저장할 이유는 없다. 확실치 않지만 참조 형태로 연결하는 것 같은데, 이를 CI/CO할 때 시스템 자원을 많이 썼고, SVN에 이를 넣다가 한 PC가 죽어 버리자 Integrity가 깨져서... 스프링 내부 메커니즘 교육용으로 이틀에 걸쳐 수 시간을 쏟은 그림이 사실상 백지로 변했다.


이렇게... 젠장.. 노트만 남았다. 결론, 리버스 하여 코드와 연결시킨 모델의 경우는 윈도우에서 SVN/CVS/VSS 등을 이용해서 형상관리 하거나 형상관리를 끊은 상태에서 백업을 잘 해두자. ㅡㅡ;

코드와 모델을 동기화 하는 것은 대규모 프로젝트에서는 권장할 수 없는 방식이다. 메커니즘 분석을 위해서나 솔루션 개발팀에서 고려할만한 일이다. 보편적인 SI 환경에서는 모델과 코드를 동기화 하는 것이 득보다 실이 많다.

또 하나 EA의 불편함은 CI/CO만 있고, Update를 못한다는 사실이다. 그래서, EA의 명령을 쓰지말고, SVN/CVS/VSS 등의 윈도우 클라이언트로 모델을 관리하는 것이 Best Practices라고 할 수 있다.

노트 연결 제약 사항
노트 링크가 걸리는 UML 요소가 제약이 있어 불편하다. 시퀀스 작성할 때 메시지에 연결이 불가능해 노트와 메시지의 색을 맞춰주거나 하는 방법을 동원해야 한다.

UML2 Nesting connector

선 그릴 때 헷갈리기 쉬운 것이 방향성. UML2에서 포함관계를 표현하는 nesting connector는 포함하는 애가 뭔가(?) 쥐고 있다.

그림 출처: http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_packagediagram.html

프레임없는 이미지 복사

EA에서 그림 복사하거나 이미지 저장할 때 다이어그램 이름 앞에 cd와 같은 접두어가 붙어 보기 싫었는데... 옵션을 발견했다.

모델링 도구와 공동작업에서 모델링 작업의 버전관리의 어려움을 정리한 바 있다. IBM RSA(Rational Software Architect) 관련 트러블슈팅 일지를 보면 더욱 생생한 기록이 있다. 이번 프로젝트에서는 고객사에서 Sparxsystems의 EA를 선택했다. 가격대 성능비로 본다면, 경쟁자를 논할 수 없기에 합리적인 선택이다. RSA는 CVS의 optimistic lock에 기반하여 공동작업과 버전관리를 지원하고 있다. 파일에 lock을 거는 방식과 달리 동시에 모델을 수정할 수 있다. 그러나, 충돌을 한번이라도 겪어본 사람이라면 대답은 하나다. 툴의 기능적으로는 fancy하지만, 실무에서 쓸 수 없는 수준이라고 말할 수 있을 정도다. 그래서 Rose에서 CAT으로 나눠서 VSS 등을 이용하여 파일 시스템 수준에서 버전 관리를 하는 것이 유용하게 느껴졌다.

EA에서는 버전관리를 써본 일이 없다. 이번에 모델링 표준과 교육을 준비하면서 시도했다. 반 나절 시도를 통해 사용법, 활용 방안과 제약사항을 정리할 수 있었다. 문서화가 잘 되어 있어 빠른 학습이 가능했다. EA는 기본적으로 CVS, SVN(Subversion), TSS(Team Foundation Server), SCC(이건 뭐냐?) 등을 지원한다. 불편한 점은 SVN 클라이언트가 로컬에 설치되어 있어야 한다는 점이다. 이미 똘똘이(TortoiseSVN)를 쓰고 있는 상황인지라, 추가로 명령행에서 쓰는 SVN 클라이언트 설치하는 작업이 약간 번거롭기는 했다.

무엇보다 파일lock을 걸기 때문에 모델만 적절히 분할해놓으면 매우 실용적으로 공통작업을 수행할 수 있다. optimistic lock은 소스코드 공동작업에는 좋지만, 편집하는 화면과 저장하는 내용이 다른 유형의 산출물 즉, 오피스 류의 문서나 모델 공동작업에는 불편하다. EA와 SVN을 이용하여 훌륭한 모델링 공동 작업 환경을 구성할 수 있었다. 한가지 단점은 모델 파일을 xml 형태로 나눠서 저장할 때, 하위 디렉토리에 넣을 수가 없다는 점이다. 버그인지, 사용을 잘못하고 있는 것인지, 툴의 제약인지는 확실하지 않다. 하지만, 다른 모델링 도구와 비교해보면 애교로 봐줄 수 있는 내용이다.

결론: 현존하는 모델링 도구 중에 가장 훌륭한 버전 관리 기능을 제공한다.

에다가 물리적인 이름으로 정렬하지 않아서 굳이 패키지에 순번을 부여할 필요도 없다. (4/3 추가)

그래서 자유롭게 패키지 이름을 부여하고, 정렬도 마음대로 할 수 있다.

유스케이스에 대한 고객 검토를 하면서 예상대로 대혼란이 일어났다. 개발자(분석가)들에게 유스케이스 개념을 설명하는 것도 쉬운 일이 아니다. 하물며 현업 고객에게 타원 몇 개 덩그러니 그려놓고 업무 범위를 모두 포괄하는 것으로 보이냐고 물으면...

고객은 오히려 비즈니스 프로세스를 그린 그림은 쉽게 생각했다. 메뉴 구조도를 보여줘도 쉽게 애플리케이션 기능 구조를 파악한다. 메뉴 레벨 2단계를 유스케이스로 잡으라는 어처구니 없는 가이드를 비웃은 적이 있다. 유스케이스는 메뉴로 분할할 수 있는 것이 아니다. 기초도 모르는 사람이 전문가랍시고 가이드 한 것일 수도 있지만, 한편으로는 현장 상황을 반영한 어쩔 수 없는 자구책인지도 모른다.


위 그림은 유스케이스 이해가 어려운 이유를 단적으로 보여준다. 현행 업무가 시스템 도입으로 인해 변모하는 모습(TO-BE)를 담고 있어 애초부터 고객들에게 시스템에 대한 이해에 기반한 상상력을 요구한다. 다시 말해서, 지금은 이렇게 일하고 있는데 앞으로는 다르게 일할 것이라고... 프로토타입 화면도 보지 않고 과연 고객이 이를 알 수 있을까?

필자 스스로도 현재 사이트에서 족보에도 없는 산출물을 만들고 있다. 적어도 국내 SI 현장에선 아직도 개발 과정의 산출물을 넘어서지 못하는 모델이 대부분이다.(그나마도 못하는 경우가 더 많은 것으로 짐작한다.) 고객에게 물었다. 유지보수할 때 모델을 보세요? 고객이 유스케이스 명세를 보나요? 물론 '안본다'가 대답이다. 볼 수 있는 산출물을 만들면서 표준 방법론이라는 틀을 어기지 않으려다보니 족보에 없는 변종을 만들어냈다.

그렇다면 유스케이스가 개발자에게는 유용한가? 비슷한 고민을 하면서 내놓은 해결책을 책으로 발행한 것이 있었다. 거짓말처럼 내가 글을 쓰고 난 후, 10분도 안되서 지인이 알려준 책 서두에 나온 그림을 캡쳐해놓는다.


출처: Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens

월간마소 5월호에 기고했던 글, 다시 꺼낸 양날의 검 UML 2부 - UML의 전략적 활용에 독자 문의가 있어서 답변을 블로그에 올립니다.


예전에도 역공학 무용론을 피력하다가 제 블로그에서 논란을 일으킨 바가 있죠. 그 내용은 아래 글에 담겨 있습니다:
역공학에 대한 이해 한발만 더 나아가기

오해를 막기 위해 좀 정확하게 정리해보면
- 제가 말하는 역공학(Reverse Engineering)을 이란 UML을 사용한 경우게 국한됩니다. ISP는 어떤 상황을 전제로 하셨는지 모르지만... 현행 업무 분석을 위해 물리적 ERD를 역공학으로 도출하는 것과는 관련 없는 이야기죠.

- 또한, 개발 환경도 자바 혹은 J2EE에 국한된 것입니다. 제가 UML을 활용해본 경험은 모두 자바이거나 닷넷(C#)을 활용하는 경우였습니다.

- 제가 굳이 '아주 특수한 경우를 제외하고는 전혀 쓸모가 없다'라고 강조해서 표현한 이유는 이렇습니다.
1) 시스템개발에 경험이 많은 분들중에 UML 모델링 도구와 J2EE를 잘 모르시는 분들 혹은
2) 모델링 도구 판매를 목적을 가진 분들이
종종 마치 물리적인 ERD를 뽑아내는 것처럼 자바 코드에서 모델을 뽑아낼 수 있는 것처럼 이야기 합니다. 기본적으로는 맞습니다. 자바 코드에서 모델을 뽑을 수 있죠. 거의 대부분의 도구들이 클래스와 클래스 다이어그램 정도는 만들어줍니다. 특정 도구는 시퀀스도 그려주죠.

그러나, 프로그래밍 공부할때 짜보는 수준의 토이 프로그램이 아니라면 그려준 그림이 큰 의미를 갖지 않습니다. 솔루션의 코어 로직을 순수 자바 만으로 짰다면 얘기는 달라지지만

1) (소스가 없는) 각종 상용 솔루션을 쓰고
2) EJB나 서블릿과 같이 컨텐이너에 의존하여 수행되어 의존성 추출이 어렵고
3) JNDI 등에 의해 문자열로 의존관계가 드러나며
4) JSP의 의존 관계 역시 추출이 어려운

보편적인 SI환경에서는 역공학은 노력에 비해 건질 것이 별로 없다는 사실을 강조했을 뿐입니다. 역공학을 유용하게 쓸 수 있는 노하우을 말해주는 것이 아니라 '모델은 역공학으로 하면 된다'라고 무책임하게 말해버리는 분들을 자주 봐서... :)

저 역시 라이브러리를 분석할 때 역공학을 자주 사용합니다. 물리적 ERD를 추출하듯이 핵심적인 클래스의 관계가 드러나는 클래스다이어그램을 역공학으로 뽑아내면 매우 유용하죠. 특수한 목적을 가지고 잘 쓰면 유용합니다. 그러나, 일반화시켜서 제 견해를 말하자면 여전히 역공학의 경제성은 매우 낮다는 생각입니다.