드디어 강좌의 종착역에 도달했군요. 마지막으로 UML에 대해서 정리를 해보고 어떻게 이용할 수 있을지 운을 띄우도록 하겠습니다. 실제로 UML을 활용해서 각자가 원하는 가치를 만들어내는 것은 여러분들의 몫이 될 테니까요.
모델링 언어 UML
UML(Unified Modeling Language)이란 말 그대로 모델링을 위한 언어를 통합시킨 것입니다. 특징적인 점은 그래픽 요소가 강한 표준 언어라는 점이죠. 굳이 소프트웨어 개발을 위해서만 UML을 쓸 수 있는 것은 아니지만, 주로 소프트웨어 개발을 위해 도움을 주는 방향으로 발전되어 왔습니다. 그러나, 모델링을 능숙하게 하기 위해서는 다양한 현상이나 개념들을 UML로 표현해 보는 방법도 좋은 수련이 된다고 할 수 있겠죠.
UML이 있기 이전에도 소프트웨어 개발을 위한 요구사항 수집이나 분석 및 설계 등을 위해 모델링이 쓰이기 시작했습니다. 글로만 작성된 문서는 내용이 많아지면 전체를 한눈에 파악하기가 상당히 힘들어집니다. 또한, 다른 사람과 의사소통 하는데 상당히 어려움을 갖게 되죠.
소프트웨어 개발 과정에서 모델링을 이용하기 이전에 이미 많은 분야에서 모델링이 쓰였습니다. 여러분도 건축에서 쓰이는 많은 도면을 한번쯤은 보신 일이 있으시리라 생각이 듭니다. 디자이너들이 의상을 모델링 한 도면을 언뜻 보신 분도 있을 듯 하구요. 이른바 샘플이라고 하는 것들은 모델과 유사한 것들이죠. 또한, 수학이나 과학의 공식들도 하나의 모델이라고 볼 수 있습니다.
그림 21-1. OMG의 로고
UML은 흔히 Booch, Rumbaugh와 Jacobson이 만든 것으로 오인하는 분들이 많습니다. 앞의 세 분들이 UML의 초안을 만들어내고 발전하는데 많은 기여를 한 것은 사실입니다. 그러나, UML에는 이미 존재해있던 많은 지적 자산들이 축적되어 있다고 볼 수 있습니다.
UML의 많은 모델링 요소들과 다이어그램은 개발 현장에서 필요성을 인정 받아 널리 쓰이던 것들이 UML이라는 이름으로 꾸러미 지어진 것입니다. 기왕 모델링 하는 김에 서로 통일된 언어로 하자는 것이죠. 1997년 후반 UML1.1이 OMG에 의해 표준으로 채택된 이래 발전을 거듭하여 현재는 UML 1.4버전까지 등장했습니다.
우리가 UML을 단순히 기술로써 다룬다면 제대로 써보지 못할지 모릅니다. UML의 심장을 이루고 있는 진정한 쓰임새를 알아야 우리에게 가치를 줄 수 있을 것입니다. 모델링은 복잡한 개체나 현상을 이해하기 위한 방편입니다. UML은 그러한 모델링을 해나가는데 아주 유용한 도구입니다.
UML은 모델링을 하기 위해 단순히 도구들-즉, 클래스나 관계와 같은 모델링 요소들만을 제공하는 것이 아닙니다. 모델링 요소와 이들 간의 규칙, 다이어그램들 안에는 문제 해결에 유용한 선조들의 자산이 녹아 있습니다.
물론 우리나라 선조님들은 아니죠. 소프트웨어 개발을 위해 다양한 문제 해결을 하려고 고민했던 이들이 많은 모델 표기법이나 규칙을 만들었고, 다양한 경험과 지식들이 UML이라는 이름으로 녹아 들어 하나의 모습을 하게 된 것입니다.
통합을 위한 언어 UML
소프트웨어 개발을 바라보는 시각은 무척 다양합니다. 우선 고객과 개발자의 관점은 확연하게 다릅니다. 개발자의 경우는 시스템의 기능이나 기술에 관심이 많지만, 고객은 풍부한 기능보다는 자신의 업무에 유용한지를 더 생각할 것입니다. 또한, 고객 측면에서는 어떠한 기술이 사용되었는지는 크게 중요하지 않을 수도 있습니다.
UML은 유스케이스(Use Case)와 유스케이스 실체화(Use Case Realization)를 통해 고객의 관점과 개발자의 관점을 연결시켜줍니다. 시스템 개발의 궁극적인 목적은 고객의 요구를 충족시켜주는 것입니다. 그러한 면에서 유스케이스를 실현하는 일은 시스템이 제대로 만들어졌는지를 검증하는 일이라 하겠습니다.
UML에서는 그림 21-2와 같이 추적 다이어그램을 통해 유스케이스와 유스케이스 실체화 간의 추적 기능을 제공합니다. 이를 통해 시스템의 모델이 유스케이스를 충족했는지 검증하는 역할을 수행할 수 있습니다.
그림 21-2. 유스케이스 추적 다이어그램
유스케이스 실체화는 Collaboration으로 연결됩니다. 그림 21-2에서 점선으로 연결된 타원은 유스케이스 실체화를 나타내기도 하지만, Collaboration을 묘사하기도 합니다. Collaboration이란 하나 이상의 객체가 작용해서 어떠한 기능을 수행하는 모습을 모델링 한 것입니다.
결국 고객의 요구 사항에 대한 시스템의 기여를 나타내는 유스케이스는 객체들이 모여서 만들어내는 Collaboration에 의해 수행된다는 것이죠.
개발자 사이에서도 다양한 관점이 존재합니다. 소규모 개발에 있어서는 굳이 역할을 구분함 없이 목표를 향해 무조건 개발하게 되어 있습니다만 그 규모가 커지면 이러한 접근법은 성공하기 어렵습니다. 따라서, 명확히 역할을 구분하고, 이에 따라 책임을 분산하게 됩니다.
이렇게 되면 시스템을 바라보는 시각도 단편적이 될 수 있습니다. 대형 프로젝트를 수행하게 되면 개개인의 역할과 개인적 성향에 따라 서로 다른 수많은 관점으로 시스템을 바라봅니다. 이를 조율할 수 있는 도구가 필요한데 이것이 또한 UML입니다.
UML은 시스템을 모델링 할 수 있는 다양한 관점을 제공합니다. 기본적으로 RUP에서 크게 구분하는 관점은 전에도 말씀 드린 것처럼 5가지 관점입니다. 분석과 설계 과정에서 시스템의 정적인 측면과 동적인 측면을 동시에 바라보는 논리적인 관점이 있습니다. 그림 21-3에 보이는 Design View가 이를 나타낸다고 볼 수 있습니다.
논리적인 요소들 즉, 클래스, 인터페이스나 이들을 묶은 Collaboration을 컴포넌트로 매핑시켜 구현을 위한 모델을 만들게 되는데 이를 Implementation View라고 합니다. 실제 구동 환경을 살펴본 모델인 Process View가 있습니다. 또한, 시스템이 실제로 설치되고, 배치되는 모습을 표현한 Deployment View가 있습니다. 여기에 이들 모두를 검증하고 통합시켜주는 수단인 Use Case View가 있죠.
그림 21-3. 4+1 View
시스템 분석 및 설계를 담당한 사람이라면 Design View에만 관심이 집중될 것입니다. 구현을 담당한 프로그래머라면 Implementation View에 초점을 맞추거나, 더러는 Process View쪽에 비중을 두는 역할자도 있을 것입니다. 시스템 배포 전문가나 시스템 엔지니어라면 Deployment View의 모델에만 관심을 갖을 것입니다.
그러나, 이들 모두는 결국 고객이 원하는 시스템의 가치를 만들어내는 것이 최종 목적입니다. 따라서, 이들 다양한 관점 사이에 충돌이 생길 경우에 이를 조정하고 통합시키는 수단이 Use Case View라고 볼 수 있습니다.
UML은 이들 관점 모두를 표현할 수 있는 도구를 제공함과 동시에 UML에 흡수된 규칙과 관습 등을 통해 위에서 설명한 통합의 기초를 제공해준다고 말할 수 있습니다. 실제로 이러한 통합을 수행하는 사람이 필요한데 이러한 지휘자를 아키텍트(Architect)라고 부릅니다.
결론적으로 UML은 단순히 모델링 언어를 통일시킨(Unified) 언어일 뿐만 아니라 시스템을 바라보는 다양한 관점까지 통일시킨 유용한 도구라고 할 수 있습니다. 이러한 측면에서 UML을 이해하고 사용해야만 유익한 결과를 얻을 수 있을 것입니다.
참고 문헌
마지막으로 제가 이 강좌를 쓰면서 참고했던 서적과 웹 사이트를 언급하죠. 좀 더 깊은 이해를 원하시는 분들이라면 해당 서적이나 사이트가 많은 도움을 줄 수 있을 것입니다.
참고 서적
Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley
UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley
The Rational Unified Process An Introduction Second Edition, Philippe Kruchten
The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
The Unified Modeling Language User Guide, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
Developing Enterprise Java Applications with J2EETM and UML, Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley
초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북
유용한 사이트
OMG UML Resource Page… http://www.omg.org/uml/
Cetus Links … http://www.cetus-links.org/
모델링 언어 UML
UML(Unified Modeling Language)이란 말 그대로 모델링을 위한 언어를 통합시킨 것입니다. 특징적인 점은 그래픽 요소가 강한 표준 언어라는 점이죠. 굳이 소프트웨어 개발을 위해서만 UML을 쓸 수 있는 것은 아니지만, 주로 소프트웨어 개발을 위해 도움을 주는 방향으로 발전되어 왔습니다. 그러나, 모델링을 능숙하게 하기 위해서는 다양한 현상이나 개념들을 UML로 표현해 보는 방법도 좋은 수련이 된다고 할 수 있겠죠.
UML이 있기 이전에도 소프트웨어 개발을 위한 요구사항 수집이나 분석 및 설계 등을 위해 모델링이 쓰이기 시작했습니다. 글로만 작성된 문서는 내용이 많아지면 전체를 한눈에 파악하기가 상당히 힘들어집니다. 또한, 다른 사람과 의사소통 하는데 상당히 어려움을 갖게 되죠.
소프트웨어 개발 과정에서 모델링을 이용하기 이전에 이미 많은 분야에서 모델링이 쓰였습니다. 여러분도 건축에서 쓰이는 많은 도면을 한번쯤은 보신 일이 있으시리라 생각이 듭니다. 디자이너들이 의상을 모델링 한 도면을 언뜻 보신 분도 있을 듯 하구요. 이른바 샘플이라고 하는 것들은 모델과 유사한 것들이죠. 또한, 수학이나 과학의 공식들도 하나의 모델이라고 볼 수 있습니다.
그림 21-1. OMG의 로고
UML은 흔히 Booch, Rumbaugh와 Jacobson이 만든 것으로 오인하는 분들이 많습니다. 앞의 세 분들이 UML의 초안을 만들어내고 발전하는데 많은 기여를 한 것은 사실입니다. 그러나, UML에는 이미 존재해있던 많은 지적 자산들이 축적되어 있다고 볼 수 있습니다.
UML의 많은 모델링 요소들과 다이어그램은 개발 현장에서 필요성을 인정 받아 널리 쓰이던 것들이 UML이라는 이름으로 꾸러미 지어진 것입니다. 기왕 모델링 하는 김에 서로 통일된 언어로 하자는 것이죠. 1997년 후반 UML1.1이 OMG에 의해 표준으로 채택된 이래 발전을 거듭하여 현재는 UML 1.4버전까지 등장했습니다.
우리가 UML을 단순히 기술로써 다룬다면 제대로 써보지 못할지 모릅니다. UML의 심장을 이루고 있는 진정한 쓰임새를 알아야 우리에게 가치를 줄 수 있을 것입니다. 모델링은 복잡한 개체나 현상을 이해하기 위한 방편입니다. UML은 그러한 모델링을 해나가는데 아주 유용한 도구입니다.
UML은 모델링을 하기 위해 단순히 도구들-즉, 클래스나 관계와 같은 모델링 요소들만을 제공하는 것이 아닙니다. 모델링 요소와 이들 간의 규칙, 다이어그램들 안에는 문제 해결에 유용한 선조들의 자산이 녹아 있습니다.
물론 우리나라 선조님들은 아니죠. 소프트웨어 개발을 위해 다양한 문제 해결을 하려고 고민했던 이들이 많은 모델 표기법이나 규칙을 만들었고, 다양한 경험과 지식들이 UML이라는 이름으로 녹아 들어 하나의 모습을 하게 된 것입니다.
통합을 위한 언어 UML
소프트웨어 개발을 바라보는 시각은 무척 다양합니다. 우선 고객과 개발자의 관점은 확연하게 다릅니다. 개발자의 경우는 시스템의 기능이나 기술에 관심이 많지만, 고객은 풍부한 기능보다는 자신의 업무에 유용한지를 더 생각할 것입니다. 또한, 고객 측면에서는 어떠한 기술이 사용되었는지는 크게 중요하지 않을 수도 있습니다.
UML은 유스케이스(Use Case)와 유스케이스 실체화(Use Case Realization)를 통해 고객의 관점과 개발자의 관점을 연결시켜줍니다. 시스템 개발의 궁극적인 목적은 고객의 요구를 충족시켜주는 것입니다. 그러한 면에서 유스케이스를 실현하는 일은 시스템이 제대로 만들어졌는지를 검증하는 일이라 하겠습니다.
UML에서는 그림 21-2와 같이 추적 다이어그램을 통해 유스케이스와 유스케이스 실체화 간의 추적 기능을 제공합니다. 이를 통해 시스템의 모델이 유스케이스를 충족했는지 검증하는 역할을 수행할 수 있습니다.
그림 21-2. 유스케이스 추적 다이어그램
유스케이스 실체화는 Collaboration으로 연결됩니다. 그림 21-2에서 점선으로 연결된 타원은 유스케이스 실체화를 나타내기도 하지만, Collaboration을 묘사하기도 합니다. Collaboration이란 하나 이상의 객체가 작용해서 어떠한 기능을 수행하는 모습을 모델링 한 것입니다.
결국 고객의 요구 사항에 대한 시스템의 기여를 나타내는 유스케이스는 객체들이 모여서 만들어내는 Collaboration에 의해 수행된다는 것이죠.
개발자 사이에서도 다양한 관점이 존재합니다. 소규모 개발에 있어서는 굳이 역할을 구분함 없이 목표를 향해 무조건 개발하게 되어 있습니다만 그 규모가 커지면 이러한 접근법은 성공하기 어렵습니다. 따라서, 명확히 역할을 구분하고, 이에 따라 책임을 분산하게 됩니다.
이렇게 되면 시스템을 바라보는 시각도 단편적이 될 수 있습니다. 대형 프로젝트를 수행하게 되면 개개인의 역할과 개인적 성향에 따라 서로 다른 수많은 관점으로 시스템을 바라봅니다. 이를 조율할 수 있는 도구가 필요한데 이것이 또한 UML입니다.
UML은 시스템을 모델링 할 수 있는 다양한 관점을 제공합니다. 기본적으로 RUP에서 크게 구분하는 관점은 전에도 말씀 드린 것처럼 5가지 관점입니다. 분석과 설계 과정에서 시스템의 정적인 측면과 동적인 측면을 동시에 바라보는 논리적인 관점이 있습니다. 그림 21-3에 보이는 Design View가 이를 나타낸다고 볼 수 있습니다.
논리적인 요소들 즉, 클래스, 인터페이스나 이들을 묶은 Collaboration을 컴포넌트로 매핑시켜 구현을 위한 모델을 만들게 되는데 이를 Implementation View라고 합니다. 실제 구동 환경을 살펴본 모델인 Process View가 있습니다. 또한, 시스템이 실제로 설치되고, 배치되는 모습을 표현한 Deployment View가 있습니다. 여기에 이들 모두를 검증하고 통합시켜주는 수단인 Use Case View가 있죠.
그림 21-3. 4+1 View
시스템 분석 및 설계를 담당한 사람이라면 Design View에만 관심이 집중될 것입니다. 구현을 담당한 프로그래머라면 Implementation View에 초점을 맞추거나, 더러는 Process View쪽에 비중을 두는 역할자도 있을 것입니다. 시스템 배포 전문가나 시스템 엔지니어라면 Deployment View의 모델에만 관심을 갖을 것입니다.
그러나, 이들 모두는 결국 고객이 원하는 시스템의 가치를 만들어내는 것이 최종 목적입니다. 따라서, 이들 다양한 관점 사이에 충돌이 생길 경우에 이를 조정하고 통합시키는 수단이 Use Case View라고 볼 수 있습니다.
UML은 이들 관점 모두를 표현할 수 있는 도구를 제공함과 동시에 UML에 흡수된 규칙과 관습 등을 통해 위에서 설명한 통합의 기초를 제공해준다고 말할 수 있습니다. 실제로 이러한 통합을 수행하는 사람이 필요한데 이러한 지휘자를 아키텍트(Architect)라고 부릅니다.
결론적으로 UML은 단순히 모델링 언어를 통일시킨(Unified) 언어일 뿐만 아니라 시스템을 바라보는 다양한 관점까지 통일시킨 유용한 도구라고 할 수 있습니다. 이러한 측면에서 UML을 이해하고 사용해야만 유익한 결과를 얻을 수 있을 것입니다.
참고 문헌
마지막으로 제가 이 강좌를 쓰면서 참고했던 서적과 웹 사이트를 언급하죠. 좀 더 깊은 이해를 원하시는 분들이라면 해당 서적이나 사이트가 많은 도움을 줄 수 있을 것입니다.
참고 서적
Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley
UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley
The Rational Unified Process An Introduction Second Edition, Philippe Kruchten
The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
The Unified Modeling Language User Guide, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley
Developing Enterprise Java Applications with J2EETM and UML, Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley
초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북
유용한 사이트
OMG UML Resource Page… http://www.omg.org/uml/
Cetus Links … http://www.cetus-links.org/