라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
UML (3)
[UML 제대로 알기] ④ 닷넷 환경 UML 툴 활용 가이드

[UML 제대로 알기] ④ 닷넷 환경 UML 툴 활용 가이드

 

연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

 

케이스 도구는 양날의 검이다. 활용도에 따라서 소프트웨어를 죽일 수 도 있다. 래쇼날 로즈(이하 로즈) 같은 케이스 도구는 능숙하게 다룰 수 있어야 되기까지 많은 학습 곡선을 필요로 한다. 능숙해진 다음에도 여전히 불편하다.

하지만 IDE와 통합된 케이스 도구는 코드의 자동 생성 등의 많은 편리한 도구를 제공한다. IDE와 통합된 케이스 도구는 UML이라는 것에 너무 얽매이지만 않고 자유롭게만 사용한다면 아주 훌륭한 프로젝트 도우미가 될 수 있다.

전통적으로 MS의 개발 플랫폼에서 사용하는 개발 도구는 MS가 100% 독점하다시피 해 왔다. STL이나 MFC를 개발하거나 사용하는 도구는 거의 비주얼 C++가 독점적이었고, COM 기반의 개발을 위해 사용되는 도구는 거의가 비주얼 베이직이었다(COM 개발을 위해 비주얼 C++를 사용하는 경우도 많이 봤지만 그 당시 이슈가 되던 RAD와는 거리가 먼 환경이었다). 물론 볼랜드의 델파이 등을 많이 사용하기도 했지만 MS의 막강한 개발 도구 비주얼 스튜디오를 넘기에는 벅차 보였다.

닷넷 환경이 발표되고, 닷넷이 산업계에서 서서히 자리를 잡아가자 닷넷 개발 도구의 필요성이 절실해 졌고, 당연히 MS의 비주얼 스튜디오 닷넷이 닷넷 개발 도구의 최강자 자리를 당연히(!) 차지했다. 사실, 비주얼 스튜디오 닷넷이 없으면 닷넷 개발이 불가능하다고 생각하는 사람들도 많다.

볼랜드가 C# 빌더 등의 닷넷 환경을 지원하는 도구를 내 놓았고, 기타 여러 벤더들이 제품을 출시했지만 MS의 아성을 무너트리기에는 역부족이다. 비주얼 스튜디오 닷넷은 닷넷 환경이 존재하는 한 닷넷 기반 IDE의 최강자로서 그 자리를 내놓지는 않을 듯 하다.

그렇다면 비주얼 스튜디오 닷넷에는 약점이 없을까? 아니다, 분명히 약점은 존재한다. 그것도 아주 커다란, 치명적인 약점이 있다. MS는 닷넷 환경을 분명한 객체지향 개발 환경(닷넷 환경에서의 CBD는 객체지향이 없이는 존재할 수 없다)이라고 했다. 객체지향 개발 환경이라면 객체지향 설계 도구가 없다면 그 활용 범위가 반감될 수밖에 없는데, 비주얼 스튜디오 닷넷 엔터프라이즈 아키텍트 버전에 포함된 비지오가 어느 정도 그런 기능을 해 주긴 하지만, 다른 객체지향 개발 도구인 로즈나 볼랜드 투게더(이하 투게더) 등의 편리함과 기능성에는 결코 미치지 못한다.

설계 도구와 개발 도구의 진정한 결합. 이상적인 환경이지만 사실 구현하기 어려운 개발 환경임에 틀림없다. 비주얼 스튜디오 닷넷은 분명 막강한 개발 환경이고, 비주얼 스튜디오 닷넷을 사용하면서 투게더 또는 로즈 같은 개발 도구를 같이 사용할 수는 없을까 하는 생각을 누구나 한번쯤은 해 보았을 것이다. 정말 그럴 수 있을까? 대답은 "물론 있다"이다. 로즈와 투게더는 비주얼 스튜디오 닷넷 XDE를 제공한다(물론 구입해야 한다).

래쇼날 로즈 2000 XDE
객체지향 모델링 도구 중 가장 유명하며, 많이 사용되는 도구인 로즈는 2002년 MS의 비주얼 스튜디오 닷넷에 애드인되어 사용될 수 있는 ‘래쇼날 로즈 2000 XDE for 비주얼 스튜디오 닷넷’을 발표했다(어찌된 일인지 아는 사람도 별로 없고 사용하는 사람은 더더욱 없다). 로즈 XDE를 가지고 있다면 그 자리에서 설치해 보기를 바란다. 물론 설치하는 시스템에 비주얼 스튜디오 닷넷이 설치되어 있어야 한다.

사용자 삽입 이미지
<화면 1> 로즈가 설치된 비주얼 스튜디오 닷넷 2003


로즈를 처음 설치하고 나면 처음엔 아무것도 없다. 도구상자에 뭔가 추가된 것도 아니고, 특별히 뭔가가 설치되었다는 느낌을 받을 수가 없는데(굳이 뭔가 설치되었다는 느낌이라면 아마 비주얼 스튜디오 닷넷의 실행 속도가 눈에 띄게 느려졌다는 느낌이 될 것이다) 솔루션 탐색기를 눈여겨 보면 평소에 볼 수 없던 아이콘이 하나 생겨있음을 알 수 있다. 그 아이콘을 주저 없이 클릭해 보자.

사용자 삽입 이미지
<화면 2> 추가된 동기화 아이콘


동기화 아이콘을 클릭하면 로즈와 비주얼 스튜디오 닷넷이 동기화되어 mdx 파일을 생성한다. 그리고 Model Explorer 창이 새로 생기고 프로젝트에 포함되어 있는 개체들을 탐색할 수 있게 해준다.

사용자 삽입 이미지
<화면 3> 로즈 XDE를 이용하여 Iterator 패턴을 디자인한 모습


로즈를 사용하여 모델링을 어느 정도 마쳤으면, 다시 동기화 버튼을 눌러 순 공학할 수 있다.

사용자 삽입 이미지
<화면 4> 로즈가 생성한 C# 코드


감동의 기능


[1] 너무 깔끔한 코드를 생성하고 닷넷 환경에서 권장하는 주석 내용들을 그대로 생성해준다. 다른 도구들은 생성한 코드의 indentation이 잘 되지 않거나 참조한 라이브러리의 네임 스페이스를 제대로 표시하지 않는 경우가 많은데, 그런 단점이 사라졌다.

[2] 참조한 라이브러리의 개체들을 모두 설계에 사용할 수 있게 해준다. 다른 모델링 도구들은 기본으로 포함되거나 직접 작성한 개체들만이 사용가능 한 경우가 대부분인데, 최상의 도구다운 기능을 보여준다.

[3] 깔끔하고 예쁜 출력을 지원한다. 다른 설계 도구의 경우 한 페이지 또는 두 페이지에 깔끔하게 출력할 수 있는 기능에 대한 지원이 부족한데, 깔끔하고 예쁘장한 산출물을 만들 수 있도록 도와준다.

[4] ASP.NET/ASP/Service Page 들에 대한 설계를 지원한다. Web Presentation Pattern을 응용한 설계가 필요할 때 아주 유용하다.


단점이라면, C#으로 작성한 메쏘드의 수정이 아주 불편하다. 또한, RUP를 너무 강조하는 경향이 있어 닷넷의 빠른 개발과는 어울리지 않는 부분이 엿보이고, 일일이 동기화를 해 주어야 코드와 설계가 연동이 되는데, 에러를 자주 발생하여 동기화가 되지 않는 경우가 빈번히 발생한다.

볼랜드 투게더
비주얼 스튜디오 닷넷에서 다른 유명한 설계 도구인 투게더를 사용할 수 있다. 투게더 역시 로즈와 마찬가지로 비주얼 스튜디오 닷넷에 애드인되어 설치된다. ‘볼랜드 투게더 for 비주얼 스튜디오 닷넷 2.0’을 설치하면 비주얼 스튜디오 닷넷에 투게더 VS.NET Model View라는 창이 생성된다.

사용자 삽입 이미지
<화면 5> 투게더 for 비주얼 스튜디오 닷넷 Model View


또한 솔루션 탐색기에 ModelSupport라는 폴더가 생성되고 폴더 내부에는 .txvpak이라는 확장자를 가지는 모델 파일이 생성된다. 이 파일을 더블클릭하여 모델링 도구를 사용하여 설계할 수 있는 설계 창을 열 수 있다.

사용자 삽입 이미지
<화면 6> 투게더를 사용해서 Iterator 패턴을 디자인 한 모습


투게더는 로즈와 달리, 코드의 실시간 생성을 지원한다. <화면 6>에서 보이는 클래스 아이콘을 더블클릭하면 코드를 곧 바로 생성하게 된다. 코드를 수정하건, 설계를 수정하건 간에 설계 또는 코드의 수정 사항이 즉시 상호간에 적용되게 되어있다.

감동의 기능


[1] 필자가 투게더를 사용해 보고 가장 감동적이었던 기능은 시퀀스 다이어그램을 실시간으로 생성해 주는 기능이었다. 메쏘드가 특정 객체들을 사용하도록 구성되었으면, 투게더는 그 메쏘드의 시퀀스 다이어그램을 아주 믿을만한 수준으로 자동 생성해 준다. <화면 7>은 Petshop 3.0의 AccountController 클래스의 CreateAccount 메쏘드의 시퀀스를 자동 생성한 것이다.


 

사용자 삽입 이미지
<화면 7> 자동 생성한 시퀀스 다이어그램


 


[2] 여러 디자인 패턴에 기반한 설계를 지원한다(로즈 역시 이 기능을 지원한다). GOF 디자인 패턴에 기반하여 설계를 하고자 하면 투게더는 디자인 패턴에서 각 객체들의 역할을 보여주며 각 역할을 하는 객체를 추가하고 삭제하는 Node by Pattern 도구를 지원한다. 투게더는 디자인패턴에 기반한 설계를 쉽고 오류 없이 할 수 있도록 도와주며 특히 디자인 패턴을 공부하는 사람에게 아주 유용한 도구가 될 수 있다.


단점이라면 생성된 코드가 그다지 깔끔하지 않아 재 정렬을 해줘야 한다는 점 등이다. 앞에서 설명한 두 가지 도구의 치명적인 단점이 하나 있다. 닷넷 환경에서는 실행할 때 참조되는 라이브러리를 복사하고 실행시 참조하므로 개발 중 라이브러리를 수정하고 다시 컴파일하여도 누군가 파일을 사용 중이기 때문에 덮어쓸 수 없다는 메시지를 절대로 보여주지 않는다. 하지만 앞의 두 도구는 모델링에 사용하고 있는 참조되는 라이브러리를 ‘물고’있기 때문에 참조하는 프로젝트를 종료하고 컴파일한 후 다시 비주얼 스튜디오 닷넷을 실행하여 계속 진행해야 한다.

그리고 전통적으로 닷넷 개발에서는 RUP 같은 개발 방법론이 사용되지 않아, 만약 UML을 그렇게 많이 사용하지 않는 개발자라거나 다른 개발 방법론을 준수하는(MSF 등의) 프로젝트라면 사용할 수 있는 다이어그램은 클래스 다이어그램뿐이고, 너무 많은 도구를 제공함으로서 개발에 혼란이 오며, 비주얼 스튜디오 닷넷 자체가 너무 느려져서 개발자의 '성질'에 나쁜 영향을 끼칠 수 있다는 것이다.

비주얼 스튜디오 닷넷 2005에 포함된 모델링 도구
MS도 닷넷 환경이 객체지향 환경이고, 객체를 모델링 할 수 있는 통합된 개발 도구가 필요하다는 것을 모를 리가 없다. 그래서 MS는 비주얼 스튜디오 닷넷의 차기 버전인 비주얼 스튜디오 닷넷 2005에 그런 모델링 도구를 추가했다(전체적으로는 투게더와 비슷한 모습이고, 필자가 현재 기사를 작성하고 있는 시점에서는 클래스 다이어그램 기능 이외의 기능은 들어있지 않다).

비주얼 스튜디오 닷넷 2005의 클래스 다이어그램 기능을 알아보자. 비주얼 스튜디오 닷넷 2005는 특별히 이전 버전과 비교해서 달라진 기능이 없다. 웹 프로젝트를 다른 프로젝트와 구분해서 생성하는 정도가 외관상으로 볼 때 달라진 기능이라 할 것이다. 비주얼 스튜디오 닷넷에서 클래스 다이어그램을 그리고 실시간으로 변경될 수 있는 기능을 사용하려 한다면 이전 버전에서 새 항목 추가 메뉴를 선택하는 것과 같이 한다. 새 항목 추가 다이얼로그 박스를 유심히 살펴보면 클래스 다이어그램이라는 항목 아이콘이 보이고 그 항목을 사용하여 클래스 다이어그램을 작성할 수 있다.

사용자 삽입 이미지
<화면 8> 비주얼 스튜디오 닷넷 2005의 새 항목 추가 다이얼로그 박스


 

사용자 삽입 이미지
<화면 9> 비주얼 스튜디오 닷넷 2005를 사용해서 Iterator 패턴을 디자인 한 모습


장점


[1] 아무래도 비주얼 스튜디오 닷넷에 애드인된 것이 아닌 빌트인된 모델링 도구이다 보니 애드인된 도구보다는 강한 결합성을 가진다. 빌트인되었을 때의 가장 큰 기대점은 아무래도 성능적인 측면인데 아직 베타 버전이기에 평가 내리기가 이른 듯 하다. 하지만 꽤 만족할만한 성능을 보여주고 있으며, C# 또는 비주얼 베이직 닷넷에 종속적인 멤버들만을 포함하므로 닷넷 개발에 어울리는 도구가 될 듯 하다.

[2] 비주얼 스튜디오 닷넷에 포함된 도구이다 보니 닷넷 개발에 가장 어울리는 코드를 생성하고 다른 도구들과 통합하여 사용할 수 있다. 닷넷에 추가된 수많은 새로운 개념들과 도구들을 사용할 수 있다.

[3] 비주얼 스튜디오 닷넷에는 지면 관계상 다 소개할 수는 없지만 모델링에 관계된 많은 새로운 도구들이 추가되었다. XML 디자인이나 데이터베이스 디자인, 배포 디자인까지 비주얼 스튜디오 닷넷에서 할 수 있다. 이런 기능들은 평소 비주얼 스튜디오를 사용하던 개발자들에게 아주 친숙한 환경을 제공해 줄 수 있다.


단점이라면, 그 외에 아무것도 없다는 것이다. 또한, 현재 베타 버전에서는 다른 라이브러리에 포함된 개체들을 클래스 다이어그램에 포함하는 인터페이스가 상당히 불편하다. 이는 개선되어야 할 점이다. 사실 투게더나 로즈같은 훌륭한 도구들을 사용하던 입장에서 비주얼 스튜디오 닷넷 2005의 설계 도구를 테스트 하는 입장에서는 전혀 새로울 것도 없고 감동적일 것도 없다.

또한 MS가 자사의 객체지향 개발 방법론을 연구하고 있다는 소문이 풍문에 들려오는 것을 보면, 정식 제품에는 다른 도구가 추가될 지도 모르고, 로즈나 투게더 같은 도구 정도의 많은 기능은 아니더라도 다른 많은 도구들이 추가될 것으로 보인다.

독이 될 수도 갈라드리엘의 별이 될수도
UML은 좋은 도구다. 하지만 대부분의 개발 팀에는 도움이 되기보다는 방해가 되기 일쑤다. UML에는 너무나 많은 것이 있고, 다 활용하기는 벅차고, 그렇다고 사용하지 않기에는 또 뭔가 빠진 듯한 느낌이 드는 것이 그것이다. 늘 절제하는 마음으로 UML을 사용한다면, UML은 아주 좋은 도구가 된다.

필자는 항상 이런 얘기를 한다. "로즈가 설치되어 있는 책상 위에는 항상 연필과 지우개, 그리고 종이가 있어야 한다" 특히 개발자의 입장에서는 UML이라는 도구는 독이 될 때는 한 모금에 사람을 죽일 수도 있는 치명적이 독이 될 수도, 또는 길을 안내해주는 갈라드리엘의 별이 될 수도 있다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

김상훈 (동명정보대학 정보기술 연구원)

2005/03/31

 

사용자 삽입 이미지

원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134439,00.htm

  Comments,     Trackbacks
[UML 제대로 알기] ② 초보자를 위해 다각도로 살펴본 UML

[UML 제대로 알기] ② 초보자를 위해 다각도로 살펴본 UML

 

연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

 

7년 전 필자는 UML이라는 단어조차 들어본 적 없었다. 국내에서는 그래도 꽤 잘하는 비주얼 베이직 프로그래머라고 자부했는데 당시 봇물같이 쏟아지던 약어들에 질려 UML이라는 알파벳 세 글자로 이루어진 '신규어'에 별 신경을 쓰지 않았다.

몇 년이 지난 후, 필자도 객체지향이라는 무림 강호에 몸을 던지지 않을 수 없는 시점에 이르러서, 그 몇 년 전에 들었던 UML이라는 것이 무림에 출사표를 던지기 위한 필수 무공이었다는 사실을 깨달았다. 그리고 그 이름도 원망스러운 디자인 패턴!

비주얼 베이직이라는 한물간 초식에서는 ‘꽤’ 강자라고 생각했던 필자는 객체지향이라는 드넓은 무림에 발을 들여서는 초고수가 되어야 되겠다는 결심을 했고, 높은 내공을 쌓기 위한 필수 비급이라는 UML과 디자인 패턴을 익히기 시작했다. 그러면서 필자가 느낀 것은? ‘초고수는 아무나 하는 것이 아니구나’하는 것이었다.

필자는 디자인 패턴에 한이 맺힌 사람이다. 디자인 패턴을 며칠 밤씩 새워 가면서 공부할 때 느낀 고통은 이루 말할 수 없다. 가끔씩 감동을 느낄 때도 있었지만 대부분의 경우가 이해하기 힘들고 패턴에 따라 프로그램을 작성하기는 더 힘든 경우가 많았다.

결국은 객체지향에 대한 기초 지식이 부족하기 때문이라는 사부님의 조언을 듣고는 HTDP와 SICP 등의 패러다임 입문서, 리스코프나 메이어 등의 객체지향 이론서 등을 짧은 영어 실력에 열심히 번역하며 읽었다. 객체지향 디자인을 제대로 이해하기 위해서는 UML은 필수사항이었고, UML에 관련된 책도 열심히 사서 읽었다. 그때부터 필자의 머릿속에는 이상한 고정 관념이 생기기 시작했다.


"디자인 패턴도 모르는 개발자가 무슨 개발을..."
"UML은 자유롭게 쓸 수 있어야 개발을 한다고 할 수 있지..."


결국은 내공이 좀 쌓이고, 디자인 패턴과 UML을 어렵지 않게 응용해서 프로그램을 짤 수 있는 수준이 되었을 무렵에, 필자는 병적으로 디자인 패턴과 UML에 집착하기 시작했다. 래쇼날 로즈 등의 케이스 툴을 사용해 설계를 하고 있으면, 화면에 보여 지는 여러 예쁜 아이콘들을 보면서 ‘아, 나는 살아 있구나’하는 존재의 가치를 느끼곤 했다.

그렇게 열심히 익힌 기술들을 이용해서 프로그램을 열심히 개발하던 어느 날 밤, 필자는 어떤 의문을 가지게 되었다. 왜 내가 동작하는 코드를 개발하지 않고 그림을 그리고 있을까? 프로그램을 작성하는 목적이 잘 동작하는 프로그램을 작성하는 것이지 출력해서 벽에 걸어놓을 미술 작품을 만들고자 하는 것이 아니지 않은가?

필자는 플라톤의 동굴의 비유에 비견될 만한 엄청난 진리를 깨달았다. UML이든, 디자인 패턴이든 꼭 필요한 부분에만 사용하면 되는 것이고, 프로그램을 작성하기 전 개념을 잡거나 최종적으로 정리하는데 유용한 도구, 특히 UML은 개발자들 간의 상호 커뮤니케이션에 아주 유용한 도구가 될 수 있다는 것을 알게 되었다.

필자는 UML 케이스 툴을 만드는 업체에 근무하는 개발자 몇 명을 잘 알고 있다. 대학원에서 꽤 실력을 쌓아 어렵게 취업한 후배들인데, 업체에 근무한지 3개월쯤 되면 이런 말을 한다.


"UML에 이렇게 많은 것들이 있는 줄 몰랐어요. 무척 힘드네요"


1년쯤 근무하면 이런 말들을 한다.


"개발자라면 UML은 반드시 알아야죠. UML의 구석구석을 모르고 어떻게 제대로 된 프로그램을 작성할 수 있습니까?"


3년쯤 근무한 후배는 이런 말을 한다.


"UML요? 꼭 쓸데만 쓰면 되지 오버해서 쓰면 나중에 감당 못하죠"


악순환의 반복이랄지, 디자인 패턴과 UML이 남긴 폐해랄지, 이런 현상은 매년 계속된다.

아키텍트 입장에서 UML
필자가 조선 업계에서 근무할 때, 새로운 시리즈를 시작할 경우(배는 하나의 설계로 여러 척을 찍어낸다) 먼저 모형을 만들어서 테스트를 하는 것을 본 적이 있다. 모형을 만들어 수영장 같은 곳에서 테스트를 해 보고 실제로 배가 목표한 만큼의 성능을 낼 수 있는지 테스트 한다. 또한, 배를 설계할 때 거대한 캐드 시스템으로 설계한 후 파도와 바람 등에 견딜 수 있는지를 테스트한다.

배를 만들 때는 엄청난 비용과 시간이 소모되기 때문에 모형을 만들거나 컴퓨터상에서 수치로 테스트한다. 컴퓨터로 만들건, 정말 모형을 만들건, 그렇게 만들어진 것을 모델이라고 하고, 대부분의 경우 모형을 만드는 비용이 실제 배를 만드는 것보다 비용이 훨씬 적게 소모되므로 모델 테스트를 한다. 이런 모델을 만들어 테스트 해보는 과정을 ‘모델링’이라고 부른다.

배를 지을 때도 선실의 세부 구조나 엔진의 동작들은 모델링하지 않는다. 모델링이라는 것은 어떤 것이 실제로 잘 동작하는지를 알아보려고 만드는 것이다. 실제 크기대로 배를 지어 바다에서 항해해 가며 파도와 바람의 영향을 최소화하거나 풍랑에 버틸 수 있을지를 테스트 해 본다는 것은 비용이 너무 많이 드는 일이다. 모델을 만드는 이유는 모델을 만드는 비용이 실제 물건을 만드는 것보다 훨씬 적은 비용으로 설계가 제대로 되었는지 알고 싶어서이다.

소프트웨어를 만들 때도 이와 같은 이치가 적용된다. 하지만 소프트웨어를 설계할 때 사용하는 이 UML이라는 것은 조선 엔지니어나 토목 엔지니어들이 모델링을 하기 위해 사용하는 미니어처나 캐드 모델과 비교해 볼 때 훨씬 비효율적이고 테스트하기 곤란하다. UML 다이어그램에는 다른 공학 모델과 비교해 보았을 때 확고한 시험 기준을 세우기도 곤란하고 평가를 내릴 때도 주관적인 관점이 상당부분 차지할 수 밖에 없다.

조선이나 건축에서 모델을 만드는 것은 실제 배나 건물을 짓는 것과 비교할 때 비교도 할 수 없을 만큼의 적은 비용이 들지만, 소프트웨어를 설계하는 입장에서 실제 프로그램을 작성하는 것과 UML을 사용한 설계를 비교했을 때 비용적인 측면에서나 생산성적인 측면에서나 그렇게 차이 나지 않는다.

사실, UML을 사용해서 테스트하는 것보다 소스코드를 직접 수정하는 것이 비용이 훨씬 적게 들고 손쉬운 경우도 있다. 개발자의 입장에서는 더욱 그러하다. 하지만 UML을 사용해야 하는 이유는 무엇일까? 잘 사용하면 비용 절감의 효과를 가져 올 수 있고, 포괄적인 설계가 가능하다는 것이다.

UML 다이어그램이라는 것은 앞서 이야기 했듯이 다른 공학에 비해 모델을 사용했을 때 실제 건축물(소프트웨어에서는 실제 동작하는 코드)을 작성하는 것보다 비용이 명확하게 절약되는지가 명확하지 않다. 필자는 실제 프로그램을 작성하는 것보다 UML 다이어그램을 작성하는 것이 훨씬 시간이 많이 드는 경우를 허다하게 봤다(사실 그렇게 하지 않으면 제대로 된 프로그램이 나오지 않는 경우가 대부분이다).

UML 다이어그램은 세부적인 설계를 하기 보다는 포괄적인 설계를 구성하였을 때 그 전체적인 비용의 절감 효과를 가져 올 수 있다. 세부적인 그림을 UML 다이어그램으로 표시하기 보다는 전체적인 그림을 UML 다이어그램으로 표시하고 세부적인 표현은 코드로 작성하는 등의 탄력성 있는 설계 운영이 전체를 UML로 설계하는 것보다 훨씬 나은 효율을 가져올 수 있다는 것이다.

실제로 아키텍트들의 설계는 이러해야 한다. 아키텍트들은 UML 다이어그램을 세부적으로 표현하기 보다는 전체적인 그림을 그리고, 그린 그림이 실제 소프트웨어로 동작했을 때 바르게 동작할 수 있을 것인지를 개발자들과 토론하고 설계를 수정한다.

필자는 프로젝트를 시작할 때 전체 소프트웨어의 요구사항을 격자 형태로 나누고 각 부분을 개개의 개발자들에게 할당하는 경우를 본 적이 있다. 큰 부분으로 나뉜(이 큰 부분으로 나누는 것조차 PM급의 아키텍트가 하지 않는다. 그러한 큰 부분은 대 부분의 기업형 응용 프로그램이라면 부서별 또는 업무별로 자연스럽게 할당되어 있기 마련이다) 업무 분할대로 각 개발자가 ER-Diagram부터 클래스 다이어그램, 컴포넌트 다이어그램까지 작성하는 경우를 실제로 본 적이 있다.

큰 수정 없이 프로젝트가 진행되어 다행이었지만, 한 부분이라도 어긋난 부분이 있었다면 엄청난 비용이 소모되었을 것이다(사실 그렇게 작성된 프로그램은 전체적인 소프트웨어의 부품이 유기적으로 동작하는 소프트웨어가 아니고 각 부품이 각기 따로 동작하는 작은 프로그램들의 집합일 수밖에 없고, 실제로도 그러했다).

개발자 입장에서 UML
자, 이제 개발자 입장에서 UML을 생각해 보자. 실제로 개발자가 UML 다이어그램의 모든 부분을 다 알아야 하는가? 개발자가 프로그램을 작성하기 위해서 UML의 메타 모델을 모조리 이해하고 각 프로젝트와 다른 케이스 도구들에서 쓰이는 스테레오 타입들을 다 알아야 한다는 것이다.

필자는 여기에 반대한다. 필자는 주로 닷넷 기술들을 가지고 소프트웨어를 작성하고 강의하고 컨설팅을 수행하는데, 사실 닷넷 기술은 너무 빠른 속도로 변화하고 있다. 곧 출시될 비주얼 스튜디오 2005와 MS-SQL 서버 2005는 닷넷 프레임워크 2.0을 기반으로 하는데, 닷넷 프레임워크 2.0은 1.1 버전과는 상당히 다른 모습을 보여준다.

C#이나 비주얼 베이직 닷넷 같은 언어적인 측면에서만 봐도, 겉으로 보기에도 제네릭(Generic)이 포함되는 등 상당히 많은 부분이 변하였다(필자는 이 부분에서 상당히 불만이 많다. MS는 이런 부분을 발표만 하고는 다른 이야기가 없다.

여러 잡지에 소개되는 글들을 봐도 이런 기능들이 추가되었다. 이런 내용만 있지 실제적으로 테스트 해 볼 수 있는 코드를 제시하거나 근본적인 변화를 이야기하는 경우는 드물다). ASP.NET 2.0만 해도 ASP.NET 프레임워크가 전체적으로 변화한 부분도 몇 군데 있을 뿐더러 사용자 정의 컨트롤이 상당히 많이 추가되고 변화함으로 인해서 새로 익혀야 할 부분이 늘어났다.

사용자 삽입 이미지



ADO.NET도 마찬가지다. 개발자의 부담은 가중되고 실제적으로 필드에서 사용되어야 할 코드와 컨트롤들의 사용법을 익히는 것과 UML의 전체적인 내용을 학습하는 것 사이에서 갈등하게 된다.

디자인 패턴도 이럴 때 부담이 된다. 개발자 누구나가 디자인 패턴과 UML을 사용할 수 있어야 하고 열심히 학습해야 한다는 것은 알고 있지만, 현실적으로 당장 사용하여야 할 요소 기술과 끝이 보이지 않는 기반 기술을 사이에 두고 갈등하다 보면 당연히 당장 사용하게 되는 요소 기술 쪽으로 치우칠 수밖에 없다.

이럴 때 누군가에게 "UML을 조금 알아야 되겠는데 어떤 책을 봐야 되겠습니까?"라고 물어보면 그 누군가는 책을 산더미처럼 던져주고(보통 이런 경우에 이유 없이 원서를 권하는 경우가 많다. 안 그래도 바빠 죽겠는데 원서가 포함된 책 뭉텅이를 받은 개발자의 입에서는 욕 빼고는 나올 것이 없다) 이 책의 내용들을 거의 다 숙지해야 제대로 쓸 수 있다는 교과서의 화신 같은 이야기를 하게 된다. 사실, 이 말은 격무에 시달리는 개발자들에게 UML을 공부하지 말라는 이야기와 동일하게 밖에는 안 들린다.

개발자들은 프로젝트에 투입될 때 UML의 어떤 부분을 알아야 하는가? 사실 UP의 모든 부분을 다 안다는 것은 업무 형태와 업무량으로 볼 때 거의 불가능 하다고 볼 수 있다. 그렇다고 UML을 전혀 모르는 상태에서 개발에 투입되었다면 그 개발자의 앞길은 십자가를 지고 골고다 언덕을 오르는 예수님의 모습처럼 보일 것이 뻔하다. UML을 효과적으로 사용하기 위한 효과적인 길을 알아보자.

의사소통 수단으로서 UML
초보 개발자라면, 우선 UML의 표기법에 익숙해져야 한다. 이렇게 생긴 아이콘은 클래스고, 이렇게 생긴 화살표는 실제화고(물론 실제화를 이해하기 위해서는 객체지향을 이해하여야 한다는 원론적인 이야기를 피하기는 힘들다. 산 너머 산이다) 이렇게 생긴 화살표는 집단화이고 등의 표기법(Notation)을 익히는 것이 중요하다. 개발은 혼자 하는 것이 아니기 때문이다. UML은 개발자들끼리 설계 개념에 대한 의견을 주고받을 때 굉장히 편리한 도구로 사용될 수 있다. UML의 표기는 매우 명확한 의미를 전달해 줄 수 있다.

개발 경로로서의 UML
UML은 기업 형 소프트웨어를 작성할 때 구조의 개발 경로를 작성할 때 유용하다. PM이 이렇게 개발해라 하는 지시를 내리면 사실 그 지시라는 것은 추상화 된 개념이라서 바로 프로그램으로 옮기기가 곤란한 경우가 대부분이다. 이런 경우, 어떤 객체를 먼저 작성하여야 하고 어떤 객체는 어떤 객체에 의존하고 하는 식의 로드맵이 필요한데, UML은 이런 도구로서도 훌륭하다.

개발 경로로서 UML 다이어그램을 활용하려 한다면, 클래스 다이어그램, 객체 다이어그램, 시퀀스 다이어그램, 협력 다이어그램을 읽을 수 있고 작도할 수 있어야 한다. UML 표기법을 완벽하게 익힐 필요까지는 없을 테고, 적당히 다른 사람과 상호 통신할 수 있을 정도의 수준이면 충분하다.

스테레오 타입 등은 잘 알아야 하지 않느냐고? 처음엔 잘 몰라도 된다. "<<", ">>"가 붙은 기호는 스테레오 타입이라고만 아는 것으로 충분하다. UML이라는 것은 쓰다보면 이해가게 되어있는 아주 신기한 물건이다.

언제 다이어그램을 그려야 하는가?
UML은 도구일 뿐 그 자체가 목적이 되어서는 안된다. UML이 목적이 되는 경우도 물론 있긴 하다(대부분의 경우 UML이 목적이 되는 경우는 작성된 소프트웨어가 클라이언트 또는 감리에 의해 검수 받을 때뿐이다). UML을 남용하는 것은 소프트웨어 개발에 큰 걸림돌이 될 수 있다. 하지만 남용하지 말고 아껴서 사용한다면 큰 도움을 줄 수 있다. 예전의 ‘약 좋다고 남용 말고..."라는 표어는 UML에서 그대로 통한다.

다이어그램을 그려야 하는 경우 어떤 지침을 따르는 것이 좋을까? 모든 개발자들이 설계에서 특정한 부분의 구조를 이해해야 할 경우 다이어그램을 그리는 것이 좋다. 그림이 완벽할 필요는 없다. 모든 개발자들이 이해했다고 생각되면 그만 그리면 된다.

개발자들 간에 구조에 대한 분쟁이 일어날 경우 그림을 그리고 그림을 판독할 수 있는 중재자를 구할 때. UML 다이어그램은 아주 명확한 의미를 전달 할 수 있기 때문에 같은 생각이지만 다른 말을 통일시켜주는 역할을 할 수 있다. 새로운 아이디어를 떠올리고 그 아이디어를 주위 개발자 또는 상급자에게 칭찬받고 싶을 때 UML 다이어그램을 작성한다. 말로 떠드는 것보다 한번 보여주는 것이 200%의 효과를 발휘한다.

“백문이 불여일견”일 필요가 있을 때 UML 다이어그램을 작성한다. 그리고 마지막으로 클라이언트에게 ‘있어 보이는’ 문서를 보여줘야 할 필요가 있을 때 작성한다. 부차적인 설명이 없이도 다들 이해하리라 믿는다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

김상훈 (동명정보대학 정보기술원 연구원)

2005/03/22

 

사용자 삽입 이미지

 

원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134386,00.htm

  Comments,     Trackbacks
[UML 제대로 알기] ① 가능성·확장성 품고 등장한 UML 2.0

[UML 제대로 알기] ① 가능성·확장성 품고 등장한 UML 2.0

 

연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

 

UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 알아보고 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠파장에 대해 알아본다. 또한 UML 2.0에서 개발자들이 주목해야 하는 세부 내용도 간단히 검토해 보자.

UML 2.0의 실로 엄청난 중요성을 미리 알고 대비할 것인지, 뒷짐 지고 좀 더 지켜볼지는 이번 글을 보고 판단해 주기를 바란다.

필자는 지난 2004년 마이크로소프트웨어 8월호에 MDA 관련 글을 기고하던 당시부터 지금까지 필자의 소속 회사가 지난 10여 년간 전문적으로 개발해 오던 인적 자원 관리(HRM) 시스템에 대한 획기적인(?) 개선 방안으로 MDA 기반의 시스템 개발을 추진하고 있다. 필자가 본격적으로 UML 2.0을 검토하기 시작한 것도 8월을 전후해서였다.

그러나 회사에서 표준으로 사용하는 모델링 도구 제작 업체에서는 4개월 전만 해도 UML 2.0을 지원하지 않았고, MDA 패러다임을 표방하면서도 아쉽게도 그 요체인 UML 2.0은 그저 각종 문서나 자료들을 통해서만 접할 수 있었다. 인사 비즈니스 프로세스 개선 작업(BPI)과 같은 초기 설계 작업은 UML 1.4 기반으로 추진해야 했고, 올 연말로 예정됐던 도구 공급사의 차기 버전을 기대해야 하는 상황이었다.

그러던 얼마 전, 필자는 해당 업체로부터 UML 2.0을 충실히 지원하게 된 새 버전의 케이스 도구를 입수했다. 비록 필자가 이미 여러 책이나 자료들을 통해 UML 2.0을 검토했었음에도, 막상 본격적으로 UML 2.0 지원 모델링 도구를 설치하고 작업을 착수하려던 그 순간의 첫 느낌을 말로 하자면 막막함 그 자체였다.

그 모델링 도구의 새로운 버전이 완전히 개편된 새로운 사용자 인터페이스로 구성됐으며 내부적으로도 상당한 기술적인 패러다임 전환이 있었던 것도 한 원인이었겠지만, 무엇보다도 근본적으로 UML 2.0이 내포한 그 가능성과 확장성에 대한 놀라움과 설렘이 교차하면서 만들어낸 미묘한 흥분과 두려움이었다는 것이 적절한 것 같다. 1620년 메이플라워호를 타고 미지의 땅 아메리카에 첫 발을 내디뎠던 이주민들의 마음이 이렇지 않았을까?

UML의 사회적 파장
UML 2.0 발표와 더불어 개발자들이 주목해야 하는 세부 내용을 살펴보기 전에 우선, UML을 중심으로 소프트웨어 업계에서 벌어지는 경제적, 사회적 현상들을 통해 향후 UML 2.0 발표 이후 소프트웨어 업계에 불어 닥칠 파장에 대해 미리 가늠해 보는 시간을 가져 보기로 하겠다.

IT 시장 변화에 주목하자
이 시대 소프트웨어 산업에 종사하는 사람이, 딴 세상에 사는 사람(beings in heaven)이 아닌 이상, 자본주의 시대를 살아가는 현대인으로서 공급과 수요를 결정하는 시장 논리로부터 자유로울 수는 없다.

우리는 종종 뛰어난 기술력을 갖추고 있음에도 망하는 반면, 특별한 기술력을 가지고 있지 않음에도 번창하는 사람이나 기업을 종종 목격하곤 한다. 즉, 기술력이 곧 성공을 의미하지는 않는다. 마찬가지 논리로, UML 2.0이 아니라 그 어떤 뛰어난 기술이 존재한다 하더라도 IT 시장에서 그 기술력을 필요로 하지 않거나 수용할 수 없다면, 그 기술력의 시장 가치는 무의미할 수밖에 없다.

2000년을 전후해서 전세계적으로 Y2K 문제가 사회적 문제로 부각되고 시스템의 대공황 사태가 예고되던 시절, 아이러니컬하게도 당시 소프트웨어 산업에서는 사양길로 접어들었던 프로그래밍 언어의 전문가들이 국내의 IMF 사태와 맞물려 고액 연봉으로 대접 받으면서 해외로 진출했던 일이 기억난다. 역시 기술의 가치(technology value)는 시장 원리(market behavior)에 의해 결정될 수밖에 없음을 인정하지 않을 수 없다.

그런 관점에서 UML 2.0이 공식적으로 공표되는 전후의 소프트웨어 산업계 판도를 살펴보는 것은 의의가 있다. 세계적으로 이미 프로그램 개발 도구 시장은 그 성장세가 둔화됐고, 모델링 도구는 빠른 속도로 보편화되어 가고 있다. 지난 몇 년간 일어났던 IT 업계의 큰 사건들을 살펴보면 그러한 사실을 쉽게 확인할 수 있다.

이를테면 예전에는 비싸게 판매하던 개발 도구를 점차 저렴하게 행사 가격으로 판매한다거나, 개발자 저변 확산이라는 명목 하에 학교나 학원을 중심으로 무료로 배포하고 있다. 심지어는 이클립스 등과 같은 막강한 개발 도구를 오픈소스로서 인터넷을 통해 무료로 배포하고 있다.

몇 년 전 세계적인 소프트웨어 업체인 MS에서는 비지오(Visio)라는 2D 전용 도구 개발 업체를 인수했고, IBM은 세계적인 모델링 도구 전문 개발 업체인 래쇼날을 인수합병했으며, 연이어 볼랜드에서는 투게더를 사들였다. 한편, 국내외 UML 관련 포럼이나 협회들에서는 앞다퉈 UML 관련 인증 제도를 만들어 발표하면서 그 인지도를 넓혀 가기 위한 대대적인 작업을 벌이고 있다.

UML 인증 제도의 필요성이라든지, 인증 제도 자체의 신빙성이나 효용성에 대해 논하기 이전에, 어떠한 사상이나 개념이 제도화 되는 과정을 거치고 있다는 사실은 그 사상이나 개념이 해당 분야에서 도입기(intro)와 성장기(growth)를 거쳐 성숙기(mature)에 진입하고 있음을 암시하는 것이다.

표준화의 숨은 뜻
UML을 논하면서 표준화(standardization)라는 키워드를 빼놓을 수 없다. UML이 발표되기 전에 국방이나
MIS분야 엔지니어들에게 친숙한 IDEF라든지 DFD, ER 혹은 Petri nets 등과 같은 정형 기법(formal method)으로 통칭되는 수많은 표기법(notation)과 지원 케이스 도구들이 존재했음에도 불구하고(참고자료:[1]번혹은[2]번등), UML은 가장 단기간 동안 소프트웨어 공학 분야에서만큼은 빠른 속도로 사실상의 표준(de-facto)의 위치를 확보했다. 언뜻 생각해 보면 UML이 여타 표기법들을 교통정리해 준 안도감(?)이 들 수도 있겠지만, 겉으로 잘 드러나지 않는 그 내막에는 무서운 음모(?)가 도사리고 있다.

표준화 작업에 주도적인 역할을 수행하는 업체들이 왜 그토록 천문학적인 자본을 투자하면서 공개적인 표준화 작업에 동참하는 것일까? 여러 가지 복합적인 이유들이 있을 수 있겠지만, 결론적으로 표준화 경쟁이다.

유명한 예로, 1970년대부터 시작됐던 빅터(Victor)의 VHS 방식과 소니의 베타 방식으로 대표되는 비디오 표준 전쟁을 들 수 있고, 최근에는 유럽과 미국을 중심으로 벌어지고 있는 위성방송 표준화 전쟁을 들 수 있다. 표준화 전쟁에서의 승패는 곧 기업의 운명을 좌우하는 것이다.

표준화의 이면에는 높은 진입 장벽을 통해 허가 받지 않은 침입자(intruder)를 봉쇄하려는 무서운 저의가 자리 잡고 있다. 시야를 좀 더 넓혀 보면, 의사나 판사, 회계사 등. 통속적인 표현으로 소위 ‘사’자로 끝나는 직업들에 대한 사회적 가치관을 살펴보면 쉽게 이해할 수 있다.

사람 몸을 열어서 칼질하고, 같은 인간으로서 다른 인간을 판단하고, 숫자 가지고 씨름하는 직업이 산업혁명 이전에는 별볼일 없는 직업이었다. 인류의 보편적인 가치관으로 판단하더라도 결코 즐거운 일이 될 수 없음에도 불구하고 전세계적으로 공히 가장 선호하는 직업이자 사회적으로도 가장 대접받는 직업이 된 현실에 미루어 짐작해 보면, 왜 그토록 세계적인 소프트웨어 업체들이 표준화를 통해 높은 진입 장벽을 구축하고 제도화에 전념하는지 그 이유를 충분히 이해할 수 있다.

어려운 시험을 통과하지 않고 누구라도 일정한 요건만 갖추면 수행할 수 있는 일반적인 직종 중의 하나라면 그렇게들 동경하는 직종이 됐겠는가? UML 2.0이 경제적으로나 사회적으로 주목 받는 이유 중의 하나는 바로 그러한 맥락에서 비전문인과 전문가를 구별하는 높은 장벽(?)을 쌓을 수 있는 재료(material)를 확보하고 토대를 마련했다는 점에서 의의가 있는 것이다.

주목해야 할 UML 2.0의 핵심 메커니즘
1997년 11월 UML 1.1로 시작된
OMG의 표준화 노력은 2001년 5월 UML 1.4 발표와 더불어 부분적인 개정 작업(minor version upgrade)의 막을 내리고, 대대적인 수술 작업을 거쳐 2004년 연말을 전후로 드디어 그 실체를 드러내었다.

그 동안 쟁쟁한 세계적인 소프트웨어 벤더들간의 보이지 않는 이해 관계(?)에 얽혀 2002년 말로 예정됐던 최종 발표 시한을 2년여를 연장하면서 이제서야 그 대단원의 막이 마무리되고 있다. 향후 UML 2.0의 일정은 명실상부한 국제 표준(de jure)으로 자리매김하기 위해 ISO 설계 표준으로 추진 중인 것으로 알려져 있다.

UML 2.0이 주목 받는 가장 중요한 이유는 무엇일까? 처음 세상에 나오고 나서는 여기저기서 수많은 비판을 받았지만, 그것은 UML이 어떠한 플랫폼이나 도메인에도 의존하지 않고 소프트웨어 개발의 전 공정(SDLC)을 지원하는 방향으로 지향해왔다는 데에 그 원인을 찾을 수 있다. 즉, 요구사항 획득으로부터 마지막 테스트까지 모두 지원하는 표기법으로서 진화해 왔다는 것이다.

그리고 점진적으로 UML 2.0부터는 실행 모델(executable UML)이라는 기법을 수용함으로써, 소프트웨어 공학에서 궁극적으로 염원하던 분석 설계(analysis & design)와 실제 구현(implementation) 간의 차이(chasm)를 극복하는 성과를 보였기 때문이다.

OMG의 UML 2.0에 대한 제안요청서(RFP)의 주제이자 현재 채택된 명세서 초안은 크게 4가지의 영역으로 분류된다. CASE 도구 벤더들간의 모델 호환성 문제를 다루고 있는 다이어그램 호환(Diagram Interchange) 영역과 모델 수준에서의 요소(elements) 제어 및 제약 문제를 다루고 있는 OCL(Object Constraint Language) 영역, UML뿐만 아니라 OMG가 주관하는 각종 표준의 통합과 정의에 활용되는 메타 모델 수준의 기본 구조체(constructs)를 명시하고 있는 하부구조(Infrastructure), 그리고 메타 모델을 기반으로 사용자 수준에서 모델을 활용하여 시스템의 구조(structure)와 행위(behavior)를 정의하고 있는 14개의 다이어그램을 정의하고 있는 상부구조(Superstructure)로 분류할 수 있다.

UML 2.0의 본질을 제대로 이해하려면 핵심인 하부구조로부터 차근차근 살펴보는 것이 순서이겠지만, 지면과 주제를 고려할 때, 일반인들이나 설계자들이 UML 2.0을 처음 대면하는 경우 가장 먼저 관심을 가지게 되는 UML 구조체(user-level constructs)인 상부구조로부터 이야기를 풀어가는 방식을 택하기로 하겠다.

사용자 삽입 이미지
<그림 1> UML 2.0 표준 다이어그램

*빨간 밑줄: 새롭게 추가된 다이어그램, 녹색 밑줄: 명칭이 변경된 다이어그램

상부 구조는 크게 6개의 다이어그램으로 구성된 구조형 다이어그램(Structural Diagram)군과 7~8개의 다이어그램으로 구성된 행위형 다이어그램(Behavioral Diagram) 군으로 분류할 수 있는데, 각 군의 대표적인 복합 구조 다이어그램(Composite Structure Diagram)과 순차도(Sequence Diagram)를 중심으로 그 특징과 의의를 살펴보도록 하겠다.

이어서 UML 2.0의 기반을 설명하고 있는 하부구조의 의미는 무엇인지, 그리고 실제 설계 작업에서 하부구조의 접근법은 어떠한 방식으로 활용하게 될 것인지 논의하기로 하겠다.

상부구조 - 구조형 다이어그램
일명 아키텍처 다이어그램(architectural diagram)이라고도 불리는 복합 구조 다이어그램(composite structure diagram)은 UML의 핵심 다이어그램인 클래스 다이어그램의 변형된 형태이다. 이는 시스템 구조 설계에 있어 또 다른 핵심 축으로 평가 받고 있으며 가장 주목 받는 다이어그램 중의 하나이다.

복합 구조 다이어그램은 기본적으로 시스템 혹은 컴포넌트의 내부 구조(internal structure)를 명시적으로 중첩시켜 표현하고 있으며, 시스템 아키텍처의 보다 섬세한 분석과 설계 사상을 담을 수 있게 된 점이 가장 큰 매력으로 꼽을 수 있다.

그렇다면 왜 복합 구조 다이어그램이 주목받는지, 그리고 복합 구조 다이어그램은 왜 탄생하게 되었으며, 향후 어떠한 용도로 활용하게 될까? 보는 시각에 따라 의견을 달리 할 수 있겠지만, UML 1.x은 근본적으로 OOAD 수준의 설계 사상을 표현하기에 최적화된 표기법으로 평가되어 왔다.

UML 1.x에도 비록 컴포넌트 다이어그램이라는 것이 있기는 했지만, 실제 너무 빈약한 문맥(semantics)으로 인해 별로 활용되지 못했으며, 강경한 컴포넌트 신봉자들이나 대용량 시스템 혹은 전체 시스템을 통합적으로 표현하기 원했던 아키텍처 전문가 진영 개발자들에게는, 그저 객체 옹호론자들이 제시하는 옹색한 명분(?)에 지나지 않았다. 사실 UML 1.x 자체에도 명시하고 있듯이, 컴포넌트 다이어그램은 몇몇 다이어그램들과 더불어 클래스 다이어그램에 일종의 간단한 확장 메커니즘을 통한 단순한 관점(view) 변경 수준에 지나지 않았다.

비즈니스 컴포넌트에 관심이 많았던 컴포넌트 신봉자들의 경우, UML 1.x의 스테레오타입(stereotype)등의 확장 메커니즘을 통해 그럭저럭 UML 1.x과의 관계를 유지하면서도 BPM이라는 포괄적이고 확장된 별도의 비즈니스 컴포넌트 표기법을 병행하며 UML 1.x의 미비한 부분을 채워 나갔다.

아키텍처 전문가 진영에서는 상황이 조금 달랐는데, 대다수의 아키텍처 전문가 진영에서 관심을 가지고 있던 임베디드 혹은 리얼타임 도메인에서는 단순히 UML 1.x 정도의 확장 메커니즘으로는 그들이 필요로 하는 아키텍처를 통한 시뮬레이션 등과 같은 시스템의 섬세한 분석 및 설계라는 목적 달성이 거의 불가능했고, 그러한 목적 달성을 위해 UML의 확장 메커니즘을 활용한다는 것은 차라리 자신들만의 특정 영역에 필요한 표기법을 자체 정의하여 사용하는 것이 훨씬 경제적이었다는 것이다.

왜냐하면 이미 아키텍처 전문가 진영에서는 UML 1.x가 발표되기 이전에 광범위하게 수많은 ADL(Architectural Description Language)과 관련 시뮬레이션 도구들이 개발되어 활용되고 있었으며, 굳이 UML에 순응하는(compliant) 방안을 모색하기 위해 UML을 연구하고 고민할 시간적 여유나 명분이 없었던 것이다.

그러나 그러한 두 진영에서 근본적으로 해결하지 못한 결정적인 문제는 자신들이 독자적으로 발전시켰던 표기법 중에 어떠한 것도 명실상부한 사실 표준(de-facto)으로 합의하지 못했다는 것이다. 가령, 아키텍처 전문가 진영에서 필요로 하는 시스템 시뮬레이션 기능을 구현하는 데 사용하는 정형 기법의 경우 동일한 도메인에서조차 연구소나 익숙한 기법에 따라 서로 달리 정의하고 필요한 시뮬레이션 도구를 개발해야 했다.

국제적인 공동 작업은 말할 것도 없이 국내에서 서로 다른 연구기관이 공동 작업을 수행하기 위해서도 사전에 일정한 표준 정형 기법을 합의하고 정립한 후 과제를 수행해야 했으며, 최종적으로 통합하는 과정에서는 결국에 모델 수준에서의 통합을 포기하고 구현 수준에서 테스트를 통해 통합하는 방식을 따라야 하는 문제점을 내포하고 있었다.

덧붙여 두 진영에서 해결하지 못한 결정적인 문제 중의 하나는 실제 구현(code)에 필요한 낮은 추상화 수준의 설계에 대해서만큼은 어설픈 UML 1.x의 메커니즘만한 수준의 방안을 제시하지 못했다는 것이다.

UML 2.0에서 새롭게 등장한 복합 구조 다이어그램은 바로 지금까지 앞서 살펴 본 아키텍처 전문가 진영으로 대표되는 임베디드 혹은 리얼타임 도메인의 핵심 개념이자 도구였던 SDL(Specification Description Language)을 수용하여 탄생한 다이어그램이다.

사용자 삽입 이미지
<그림 2> UML 2.0 복합 구조 다이어그램 예


UML을 잠시라도 살펴 본 경험이 있는 개발자들이라면, 복합 구조 다이어그램의 개략적인 형태만을 보고서도 쉽게 그 특징을 이해할 수 있을 것이다. 즉, 복합 구조 다이어그램은 매우 직관적인 형태를 취하고 있으며, 기존의 UML 1.x에서 단순한 패키지 개념의 서브시스템 내부를 구성하고 있는 클래스 다이어그램으로만 표현이 가능하던 시스템 내부 구조를 보다 섬세하게 설계할 수 있게 됐다.

그렇다고 <그림 2>와 같이 대부분의 UML 2.0을 기반으로 한 샘플들처럼 임베디드나 리얼타임 도메인과 같이 상대적으로 소프트웨어의 비중이 작은 단위 시스템이나, 특정 MIS 분야의 단위 서브시스템의 내부 설계에만 국한되어 복합 구조 다이어그램을 활용하겠다고 생각한다면, UML 2.0의 본질을 제대로 이해하지 못하고 있는 것이다.

복합 구조 다이어그램의 형태는 앞서 언급한 아키텍처 전문가 진영에서 아키텍처를 표기하는데 가장 많이 활용하는 아키텍처 스타일인 C&C(Component & Connector) 뷰 타입(view type)과도 일맥상통하는데, 복합 구조 다이어그램을 활용하고자 하는 모델의 추상 수준을 높이면 대규모 시스템의 아키텍처도 매우 유용하게 설계할 수 있게 된다.

<그림 2>에서 벤딩머신(VendingMachine)으로 되어 있는 부분을 인사시스템이라 정의하고 내부 부분(parts)들을 그것을 구성하고 있는 단위 시스템으로 정의하게 되면, 외부 인터페이스를 통해 회계시스템(AS)이나 고객관리시스템(CRM) 등과 주고받아야 할 데이터나 정보를 명시적으로 설계에 반영할 수 있을 것이다.

바로 설계자가 의도하는 어떠한 추상화 수준의 모델이라도 UML 2.0의 복합 구조 다이어그램은 보다 섬세하게 설계할 수 있도록 일관된 문맥(context)과 의미(semantics)를 제공하고 있는 것이다.

상부구조 - 행위형 다이어그램
UML 2.0 상부구조 중 구조형 다이어그램은 말 그대로 구조적인 혁명을 꾀했다면, 행위형 다이어그램 군에서는 시스템의 동적 설계를 제대로 반영하기 위해 기존의 행위형 다이어그램 군 소속 다이어그램의 의미(semantics)를 보강하고 정제함으로써, 진화 방식을 선택했다는 표현이 적절할 것 같다.

그 근거로서 앞서 복합 구조 다이어그램으로 대표되는 구조형 다이어그램에서 수용한 SDL의 경우와는 다르게 UML 1.x에서 이미 수용하던 MSC(Message Sequence Chart) 개념을 UML 2.0에 와서는 전폭적으로 수용하여 순차도(Sequence Diagram)를 중심으로 행위형 다이어그램들의 유기적 결합 통로를 확보함으로써 시스템의 모델 수준에서의 논리적인 실행을 그대로 설계에 반영할 수 있는 발판을 마련했다.

사용자 삽입 이미지
<그림 3> UML 2.0 순차도의 예


<그림 3>에서 보는 바와 같이 UML 2.0 순차도의 가장 두드러진 특징은, 기존의 UML 1.x에서 지원하지 못했던 시스템의 분기, 참조, 병렬 실행 등과 같은 세세한 부분들까지도 지원이 가능하도록 중첩된(nested) 표기법 체계를 설계 기법으로 도입했다는 사실이다.

MSC와 같은 기법에 익숙한 개발자들에게는 언뜻 보기에 별로 특이할 것이 없어 보일지 모르지만, 중요한 사실은 UML 2.0을 표준 표기법으로 수용함으로써 어떠한 비즈니스 도메인이나 기술 영역에서도 <그림 3>의 순차도 뿐만 아니라 UML 2.0의 다른 다이어그램들과 유기적인 연결고리를 가지고 활용함으로써 거의 무한대에 가까운 표현 수단을 확보할 수 있다는 사실이다.

UML 2.0 상부구조 중 행위형 다이어그램의 갱신에 대해 많은 관심을 가지는 사람은 임베디드 혹은 리얼타임 진영에 종사하고 있는 개발자들이겠지만, 기존의 비즈니스 프로세스 모델링 분야에서 종사하던 개발자 진영도 깊은 관심과 기대를 가지고 있다.

필자 또한 비즈니스 프로세스 모델링과 관련하여 행위 형 다이어그램의 특성과 최적 방안을 모색하고 있는데, 동일 비즈니스 도메인에서조차 개별 기업마다 그 특성과 비즈니스 프로세스 처리 방식이 천차만별인 문제를 해결하고자 등장했던 워크플로우 엔진 혹은 설계 시스템(workflow engine or system)과 같은 전문적인 도구의 기능을 충분히 대치할 방안이 마련된 것으로 평가되고 있다.

하부구조 - 메타 모델
소프트웨어 공학 분야에서는 이런 속설이 있다. 자신의 분야에서 메타 모델 기반의 접근을 하게 되면 하나의 논문이 된다. 매일 고객들과 씨름하면서 현장에서 일하는 개발자들에게는 먼 나라 이야기처럼 들리고, 현실적으로는 일정 규모의 연구소 혹은 학교에서나 다루어질 만한 주제로 치부됐던 것이 사실이다.

UML 2.0 하부구조(Infrastructure)는 일반적으로 UML 2.0을 지칭할 때 생각하는 UML 2.0 상부구조뿐만 아니라 OMG의 또 다른 메타 모델 집합인 MOF, CWM 뿐만 아니라 미래의 새로운 표준을 정의하기 위해 심혈을 기울여 정의한 메타 모델이다.

OMG에서 처음 메타 모델 4계층 개념을 발표했을 때에는 그저 개념적인 내용으로만 인식하지 못했지만, UML 2.0의 실체가 드러나고 그것을 지원하는 케이스 도구들의 기능들이 메타 모델 기반 설계 방식을 지원함으로써, 이제는 메타 모델이라는 주제가 현장에서조차 피해갈 수 없는 현실 문제로 다가올 것이다. 그러므로 이제는 메타 모델 4계층 개념을 충분히 이해하고 응용하는 노력을 기울일 필요가 있다.

사용자 삽입 이미지
<그림 4> OMG 4계층 메타 모델 예


글의 주제와 지면 관계상 메타 모델에 대한 깊이 있는 논의를 하지는 못하지만, <그림 4>의 예로 간단히 살펴보자. 시스템 분석가나 설계자들이 일반적인 모델링 케이스 도구를 통해 특정 도메인 시스템을 설계한다고 했을 때의 메타 모델 수준(level)이 바로 사용자 모델을 도식하게 되는 M1 수준이다.

M2 수준은 그러한 UML 기반의 설계를 가능케 하는 어트리뷰트, 클래스, 인스턴스 등과 같은 모델 요소를 정의하는 메타 모델이며, UML 2.0의 하부구조는 바로 위 4계층 메타 모델 관점에서 M2 수준의 UML 메타 모델이 된다. M3 수준에 위치한 MOF(Meta Object Facility)는 M2 수준에 속한 메타 모델을 정의하는 메타메타 모델이 된다.

참고로 CWM(Common Warehouse Metamodel)은 M2 레벨이며, MOF의 내부 구조는 추상화된 UML 하부구조와 동일한 방식으로 정의하고 있다. 자세한 사항은 OMG UML 2.0 Infrastructure, 7. Language Architecture를 참조한다.

앞에서 살펴 본 바와 같이 OMG에서 UML 2.0 관련 제안요청서(RFP)를 제기한 목적은 단순히 UML 2.0을 체계적으로 정리하고자 한 것이 아니라, OMG의 또 다른 표준인 MOF와 CWM 및 미래의 새로운 표준을 체계적으로 정의하기 위한 용도로 제기됐던 것이다. 여기서 우리가 주목해야 할 사항은 UML 2.0 하부구조에 대한 제안요청서를 통해 제기한 또 다른 목적이다.

그것은 바로 지금까지 M1 수준에서 UML을 활용하던 사용자들이 보다 수월하게 M2 수준에서 UML을 커스터마이징하여 활용할 수 있는 메커니즘을 제공하는, 즉 이원화된 메커니즘을 제공하여 사용자들이 유연하게 특정 기술 도메인이나 비즈니스 도메인에 최적화된 방식으로 설계를 수행할 수 있도록 하자는 데 그 취지가 있었다.

그 핵심이 바로 UML 프로파일(UML Profiles)이다. 지금 UML 2.0 작업과 동시에 진행되고 있는 대표적인 기술 도메인 프로파일로는 우리들에게 친숙한 EJB 프로파일(Profile for EJB), 닷넷 프로파일(Profile for .Net)을 들 수 있다. 프로파일을 간단히 설명하면, 일종의 특정 기술이나 비즈니스에 적절한 커스터마이징된 확장 메커니즘을 사전 정의해 놓고, 추상화 수준이 서로 다른 모델들간의 전환(transformation)을 자동화시키는 핵심 메커니즘이다.

플랫폼 독립 모델(PIM: Platform Independent Model)로부터 특정 플랫폼 종속 모델(PSM: Platform Specific Model)로의 자동화된 전환이라는 MDA의 사상이 바로 대표적인 일례라고 볼 수 있다. UML 프로파일은 향후 MDA를 통해서 달성하려고 하는, 아니 궁극적으로 UML 2.0을 통해 달성하게 될 소프트웨어 공학의 핵심 화두인 소프트웨어 개발 생산성 향상의 핵심 메커니즘으로 평가 받고 있다.

만약 이 글을 읽는 개발자가 속한 관련 분야에 MIS 분산 시스템 개발의 사실 표준으로 통용되는 J2EE나 닷넷 등과 같은 개발 기술 표준 프레임워크가 존재한다면 다행스러운 일이다. 모델링 도구 벤더에서 제공하는 EJB 프로파일이나 닷넷 프로파일과 같은 기술 메타 모델은 그대로 활용하고, 관심 비즈니스 영역에 해당하는 표준 도메인 프로파일을 활용하거나, 독자적으로 정의해 설계 작업을 추진해 나갈 수 있기 때문이다.

하지만 최악의 경우 관련 분야에 기술이나 도메인 프로파일이 존재하지 않고, 더욱이 활용할 만한 케이스 도구조차 존재하지 않는다면 난감하다. 하지만 UML 2.0을 충분히 지원하는 범용 혹은 상용 케이스 도구를 통해 구현된 방식이나 기능을 살펴보면 놀랄 만큼 간결하다. 문제는 UML 2.0의 프로파일 방식과 같은 메커니즘을 이해하는 것이 아니라, 그 동안 개발자들이 간과해 왔던 문제, 가령 “해당 비즈니스 도메인을 제대로 이해하고 있었는가?” 등과 같은 근본적인 문제를 되돌아보는 계기가 될 것으로 생각된다.

어떻게 대처할 것인가
지금까지 UML 2.0 출시를 전후해서 전개되어 왔던 소프트웨어 산업계의 전반적인 흐름과 사회적 파장, 그리고 UML 2.0의 상부 및 하부구조의 핵심 메커니즘을 중심으로 간단히 살펴보았다. 그렇다면 과연 어디서부터 어떻게 UML 2.0을 시작할 것인가?

기본 원칙에 충실하자
우선 스스로에게 UML 1.4는 제대로 이해하고 활용해 왔는가라는 질문을 던져 보아야 한다. 필자의 경우 하는 일이 하는 일인만큼 UML 2.0이 발표되기 이전에도 자바나 비주얼 베이직 등과 같은 프로그래밍 용어나 주제에 비해 상대적으로 UML(1.x), OOAD, CBD, 방법론 등이라는 용어가 훨씬 낯설지 않았다.

당연히 주변에는 상대적으로 코딩보다는 현장에서 분석(analysis)이나 설계(design)를 전문으로 하거나, 학교나 학원 등에서 학생들을 가르치는 사람들이 많았지만 그 중에 UML 1.x 관련된 OMG 무료 명세를 제대로 살펴보았거나, 가까이 두면서 참조하는 사람은 찾아보기 어려웠다.

필자 가까이에 ‘UML 1.4 사용자 지침서’를 한글로 번역했던 분을 통해 확인해 보아도, 국내 출판사에서 출간한 책 부수로 미루어 UML 원문은 차치하고서라도 핵심 내용만을 추려서 발간한 그 UML 사용자 지침서마저 꼼꼼히 살펴 본 사람은 별로 보지 못한 것 같다. 필자도 예외는 아닌데, 돈이 없어서 혹은 원서이기 때문에라는 것은 이유가 되지 않았던 것이다.

그런데 UML 2.0이 공식 발표되는 이 시점에도 상황은 예전이나 별반 다르지 않은 것 같다. UML 2.0으로 공식 공표되기 전에 이미 오래 전부터 OMG에는 UML 관련 명세를 1.5의 형태로 인터넷에 배포하고 있었지만, 살펴본 사람은 찾기 어려웠다. UML 1.1이 처음 발표되던 시점에는 표기법으로서의 표준화 경쟁에서 판정승이 나지 않았던 때여서 그랬다고 하더라도, UML 2.0이 공표되는 이 시점에는 이미 국내외 많은 대학의 컴퓨터 관련학과에서 필수 과목으로 개설되었을 만큼 그 중요도와 필요성이 검증된 마당에 애써 그 사실을 외면하는 것은 더 이상 이유가 될 수 없다.

물론 지금까지의 현실은 그렇지 못했던 것이 사실이다. UML 전문가들마저도 UML 1.x의 설계 도구로서의 완성도가 받쳐주지 못했고, 무엇보다도 고객들도 유기적으로 논리적인 설계 모델을 기대하지 않았기 때문에 UML이라는 포장지를 가지고 피상적이고 개념적으로 대충 구색 맞추기식 설계 산출물을 만들어 주면 그만이었다.

그러나 앞으로의 상황은 그렇지 못할 것이다. 당장은 아니겠지만 UML 2.0 표기법이 소프트웨어 산업 시장에서 보편적으로 활용되고 국내외에서 하나 둘 그 무한한 잠재력과 가능성이 증명되어 그 시장 가치가 확연히 드러나기 시작하는 시점에는 우리 주변의 고객들 또한 단순히 보기 좋은 산출물 정도의 설계를 요구하지는 않을 것이다.

그렇다면 어디서부터 어떻게 준비해야 할 것인가? 그 실마리는 처음 접하면 이해하기 어렵고 복잡한 UML 2.0 관련 명세나 두꺼운 책에서 찾을 것이 아니고, 누구나 알고 있으면서도 충실하지 못했던 가장 기본적이고 원칙적인 원리를 고민하는 것부터 시작해야 한다.

원칙 하나, 도메인을 철저하게 분석하자
시스템을 설계한다고 했을 때, UML과 같은 설계 기법을 동원하여 작업하는 시스템 분석 및 설계자 그룹 외에 매우 중요한 역할을 수행하는 집단이나 개인을 가리켜 도메인 전문가 혹은 비즈니스 분석가라고 한다. 가장 이상적인 시스템 설계자는 두 가지 능력 즉, 해당 도메인에 대한 공인된 전문적인 지식을 가지고 있으면서 동시에 설계 능력을 고루 갖춘 인재일 것이다.

그러나 현장에서 그런 핵심 인재를 찾기는 어려운 것이 사실이다. IT 업계로만 보더라도 시스템 설계자와 개발자 간에 차이가 좀처럼 좁혀지지 않는데, 전혀 그 분야와 전공이 다른 비즈니스 전문가와 시스템 전문가 간에 느끼는 갈등은 말할 필요도 없다. 시스템을 설계해 본 사람은 누구라도 공감하겠지만, 시스템을 제대로 설계하려면 해당 도메인을 충분히 이해하고 철저하게 분석해야 한다. 그렇지 않으면 제대로 된 시스템을 설계할 수 없다.

시스템 설계자 입장에서 문제는 해당 도메인을 제대로 이해하기 위한 충분한 시간도 주어지지 않고, 나름대로 시스템 설계자가 충분히 이해한 것을 객관적으로 검증해 줄 만한 기준도 마련되어 있지 않다는 것이다. 설사 객관적 기준이 있더라도 그것은 현실적으로 거의 불가능하다는 것이다.

가령 회계 시스템을 설계하려면 회계사 자격증을 갖춰야 하는가? 물론 아니다. 그런데 우리는 주변에서 타의든 자의든 특정 도메인 시스템을 반복해서 설계하는 설계자의 경우 점점 해당 도메인에 대한 이해력이 높아지고, 회계사와 같은 공인된 자격증은 취득하지 못하더라도 나름대로 그 전문성을 인정받아 시장에서 높이 평가되는 경우를 보곤 한다.

비단 시스템 설계자에게만 해당되는 문제는 아니다. 조각조각 할당된 부분만 열심히 해야 하는 개발자에게도 비슷한 현상은 쉽게 찾아 볼 수 있다.

설계하고자 하는 해당 도메인에 대한 철저한 분석 없이는 일정한 추상화 수준을 유지한 유기적인 모델을 만들어 낼 수가 없다. 몇몇 책이나 발표 자료에서 설계 팁으로 이야기 하듯이 해당 도메인에서 반복적으로 등장하는 명사(nouns)를 클래스명으로 명명한다는 식으로 설계를 진행하다 보면 점점 헤어나지 못하는 미궁으로 빠져들게 된다. 결국에는 UML 2.0이라는 강력한 설계 도구를 가지고도 설계 따로, 코딩 따로라는 늪에서 벗어날 수 없다.

UML 표준화를 주도하는 OMG에 대해서 많은 사람들은 단순히 CORBA, ORB 등과 관련한 국제적인 기술 표준화 단체 정도로만 인식하고 있다. 하지만 앞서 주장한 도메인 지식 혹은 도메인 표준에 대한 중요성에 대해서는, 그러한 기술 표준화 단체로 출범한 OMG에서 2002부터 발족하여 추진하고 있는 DTF(Domain Task Forces) 위원회의 활동을 살펴보면 쉽게 이해할 수 있다.

이미 전략전술 통제(C4I), 재무(finance), 의료(healthcare), 제조(manufacturing), 우주항공(space), 통신(telecommunications), 운송(transportation) 등의 도메인을 필두로 그 표준화 작업을 진행 중에 있으며, 여러 표준화 단체들과 연합하여 다른 도메인으로까지 표준화 작업을 확장 중에 있다.

물론 아직까지 그 시도는 기술적인 관점에서의 접근이라는 한계를 크게 뛰어 넘고 있지는 못하지만 인터넷, 즉 IT 기술을 배제한 고전적 의미의 비즈니스는 점차 그 경쟁력을 잃어 가고 있는 현실을 생각할 때 OMG의 영향력은 쉽게 무시할 수 없는 것이 될 것이다.

원칙 둘, 모델의 추상 수준
사전적 의미로도 알 수 있듯이 모델은 본질적으로 어떤 특정 사물이나 현상에 비해 상대적으로 추상화되어 있는 무엇이기 때문에 똑같은 실체에 대한 서로 다른 모델은 서로 다른 추상화 수준(level of abstraction)을 가질 수밖에 없다.

사용자 삽입 이미지
<그림 5> 모델의 서로 다른 추상화 수준


<그림 5>를 보면 똑같은 자동차를 모델로 만든 것이지만, 상단의 자동차 그림(혹은 모델)은 추상화 수준이 높고 하단의 자동차는 추상화 수준이 낮다. 여기서 중요한 것은 추상화 수준의 높고 낮음은 상대적이라는 것이다. 우리가 UML에서 제시하는 여러 다이어그램을 가지고 모델을 제작한다는 것은 결국 목표하는 자동차나 건물 등과 마찬가지의 실체 즉, 특정 시스템 하나를 완성하기 위한 노력인 것이다.

즉, 설계 작업을 수행한다는 UML 1.4의 표기법을 동원하든 UML 2.0의 표기법을 동원하든 아니면 제3의 표기법을 활용하든 목표하는 시스템을 완성하기 위한 과정이지 다이어그램 혹은 표기법 자체가 목적이 되지는 않는다는 것이다. 이러한 똑같은 모델의 원리를 UML의 다이어그램을 가지고 설명할 수 있다. <그림 5>는 UML 1.4에서 제시하는 9개의 표준 다이어그램의 추상화 수준을 계량화하는 방안으로 방사형의 표로 도식해 본 것이다.

사용자 삽입 이미지
<그림 6> UML 1.4 다이어그램 추상화 분포


<그림 6>의 중앙에 위치한 지점을 설계자가 목적하는 목표 시스템의 코드 혹은 운영(run-time) 시스템이라고 한다면, 유스케이스 축에서 0.8으로 표시된 지점 정도의 추상화 수준으로 유스케이스를 작성한 것을 비즈니스 유스케이스라 할 수 있겠고, 0.4 정도의 지점 추상화 수준으로 작성한 것을 시스템 유스케이스라고 할 수 있을 것이다. 그렇게 가정해 본다면, 중앙에 가까운 지점의 추상화 수준으로 낮게 모델을 작성한다면 설계자가 목적하는 시스템은 보다 세세하게(detailed) 보이게 될 것이다.

유럽의 모든 길이 로마로 향하듯이, 어떠한 길(다이어그램)을 선택하더라도 종국에는 목적지(목표 시스템)에 도달할 수 있다. 하지만 각 다이어그램은 각자 목표하는 시스템으로 접근할 수 있는 추상화 수준의 한계를 가지고 있다.

가령, 유스케이스 다이어그램만을 가지고 시스템 설계를 완성할 수는 없는 것이다. 반면에, 클래스 다이어그램만 가지고 시스템 설계에 접근하다 보면 나무는 보고 숲을 보지 못하는 우를 범할 수 있다. 그러한 이유로 소프트웨어 설계에서 UML을 활용하여 목표 시스템을 설계할 때는 하나 이상의 다이어그램을 활용하게 된다.

대표적으로 많이 활용되는 다이어그램으로는 유스케이스, 클래스, 시퀀스 등을 들 수 있을 것이다. 문제는 여기서부터 시작 된다. 시스템 설계에 대표적인 3개의 다이어그램을 활용하든 아니면 9개의 다이어그램을 모두 활용하든 활용하는 다이어그램들이 각자 따로 존재하게 되는 것이다.

유스케이스 다이어그램 따로 클래스 다이어그램 따로 심지어는 동일한 시스템에 대한 유스케이스 다이어그램을 그리더라도 그리는 사람에 따라 서로 다른 추상화 수준(level of abstraction) 혹은 입도(granularity)의 유스케이스가 작성된다는 것이다. 이건 비즈니스 유스케이스니 이건 시스템 유스케이스니 하면서 무의미한 논쟁으로 치닫게 된다.

이러한 문제를 본질적으로 해결책하기 위해서는 그것이 UML 1.4이든 UML 2.0이든 각 다이어그램의 주된 용도(usage)와 목적(objectives), 그리고 그 한계를 충분히 이해하고, 각 다이어그램이 그러한 용도와 목적을 충족시키기 위해 제시하는 특성 표기법의 명확한 의미와 용도를 숙지해야 한다. 그 후에 활용하려는 다이어그램의 핵심 표기들 간의 추상화 수준에 대해 일관된 원칙(principle)을 우선 정립하고 설계 작업을 수행해야 한다.

가령 이러한 원칙 수립이 가능하다. 유스케이스 다이어그램을 통해 작성한 하나의 유스케이스를 하나의 활동도(Activity Diagram)로 도식하기로 했다면, 활동도의 활동(Activity)은 유스케이스 시나리오로 작성하는 사건 흐름(flow of event) 상의 단일 스텝(step)이라는 원칙을 설정하게 되면 일관된 설계 작업을 수행할 수 있다. 그러한 설계 전략을 위 <그림 6> 위에 상징적으로 표현해 보면, <그림 7>과 같이 도식할 수 있을 것이다.

사용자 삽입 이미지
<그림 7> 다이어그램 간의 추상화 수준 조정


지금까지 UML 1.4를 중심으로 모델의 추상 수준이라는 원리에 대해 살펴보았다. 그러한 모델의 추상 수준이라는 핵심 메커니즘은 본질적으로 UML 2.0이라고 해서 다르지 않다. 앞선 <그림 1>과 <그림 7>을 언뜻 비교해 보아도 UML 2.0에서는 표준 다이어그램의 개수로도 UML 1.4에 비해 수적으로 많이 늘어났으며(<그림 4>에서 빨간색으로 표시된 다이어그램), 이전부터 있었던 몇몇 다이어그램들은 명칭이 변경됐고(<그림 4>에서 초록색으로 표시된 다이어그램), 무엇보다도 전반적으로 모든 다이어그램들이 보다 섬세한 설계자의 의도를 반영할 수 있도록 세부적인 표기들이 많이 추가되고 세분화됐다. 즉, 사용할 수 있는 다이어그램 선택의 폭(width)이 넓어졌고, 설계자의 의도를 보다 정밀하게 반영할 수 있는 깊이(depth)도 깊어졌다.

원칙 셋, 모델 자체의 완성도를 높이자
앞서 소프트웨어 업계에서 최근 발생하고 있는 현상들을 통해 잠시 언급했지만, UML 관련 국내외 포럼이나 협회들을 중심으로 UML 자체 혹은 설계 능력 인증 제도가 점차 많아지고 있다. 필자가 인증 제도의 본질적인 목적이나 그 가치 자체를 부정하는 것은 아니지만, 올해 사회적으로 충격을 던져 주었던 대입 수능 시험에서의 대량 부정 사태라든지, 얼마 전부터 공공연하게 제기됐던 영어 관련 인증 제도 등에서 발생하고 있는 문제점 등에 비추어 UML 인증 제도에서도 충분히 발생할 수 있는 그 변별력 문제에 대해 우려를 감출 수 없다.

그러나 다행히도 UML 2.0이 가지고 있는 그 강력한 표현력(semantic expressiveness)과 섬세함(elements precision) 그리고 다이어그램들간의 유기적 연결성 지원(support for diagram interchange) 능력으로 인해 인증서를 가지고 있다고 들먹이지 않아도 모델 결과물 자체로 그 완성도를 검증(self verification)할 수 있다. 즉, 모델 결과물만으로도 충분히 설계자의모델링 역량을 충분히 증명할 수 있는기반을 제공하고 있는 것이다.

UML 2.0이 공식으로 발표되기 이전 특정 케이스 도구들을 중심으로 시도됐지만 UML 1.4의 제약으로 그 실효성(efficiency)을 의심받았던 코드 자동 생성(automatic code generation) 기능은 케이스 도구들이UML 2.0 엔진으로 교체함으로써 그 완성도를 높일 수 있게 됐다. 더 나아가 UML 2.0이 내포한 그 풍부한 표현력과 정교함은, 특정 플랫폼에 종속적인 코드를 생성해 내기 이전에 케이스 도구의 도움을 통해 모델들만을 가지고 사전에 시뮬레이션마저도 어려운 문제가 되지 않는다.

앞으로의 전망
지금까지 개발자들은 새로운 기술이나 제품이 출시되면, 여기저기서 화려한 수식어와 찬사로 밝은 미래를 전망하는 이야기에 너무나도 익숙해져 있다. 1997년 UML 1.1이 처음 세상에 나왔을 때도 마찬가지였다. 그런 맥락에서 단순히 UML 2.0이라는 새로운 패러다임에 무조건 주목하자고 주장하고 싶지는 않다. 실리에 밝은 국내외 소프트웨어 업체들과 협회들의 행보와 여러 가지 상황을 종합해 보아도 UML 2.0이 소프트웨어 산업계에 미칠 파장의 크기는 실로 엄청날 것으로 예상된다.

그것이 더 이상 거스를 수 없는 현실이라면 그러한 도전에 수동적으로 대처할 것인가, 아니면 능동적으로 대처할 것인가의 문제는 독자 스스로 선택할 문제이다. 혹시 이솝 우화에 나오는 거짓말하는 늑대 이야기에서처럼 중요하다는 말을 너무 자주 들어 개발자들이 UML의 중요성을 공허한 메아리 정도로만 치부하고 지나칠까 걱정될 뿐이다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

사용자 삽입 이미지

 

원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134178,00.htm

  Comments,     Trackbacks