[펌] [안영회의 UML 강좌2] - UML 이란?

##########0*하나의 시스템을 만들 때, 궁극적으로는 소프트웨어 혹은 프로그램을 만들 때가 되겠군요. 아주 간단한 프로그램이 아닌 다음에야 어떻게 만들지 신중하게 고려해야 합니다. 프로그램은 대체로 현실에 있어서의 어떤 해결책을 제공하는 것이죠. 다음 그림을 보죠.

##########1*
[소프트웨어 프로그램 개발 과정]

현실 세계의 문제 해결을 위해 프로그램을 만들기 위해서 일단 현실에서의 요구 사항을 분석해야 합니다. 자신이 필요로 하는 프로그램을 만드는 것도 쉬운 일이 아닙니다. 더군다나 다른 사람을 위한 프로그램 개발자야 어떠하겠습니까? 게다가 프로그램 사용자가 다수라면 더 복잡해집니다. 간단하게 누구의 요구는 받아주고, 누구의 요구는 묵살할 수는 없는 일이니까요. 이렇듯 복잡한 현실 세계의 요구 사항을 파악하기 위해서 모델링을 합니다. 앞에 언급한 것처럼 모델링이란 현상을 단순화, 일반화 또는 추상화 하는 과정입니다. 모델을 현실과 동일하게 만드는 일은 불가능합니다. 설령 그렇게 했다고 하면 이미 그것은 모델이 아니니까요. 모델링을 할 때 가장 중요한 것은 많은 관점들을 찾아내고 조정하는 것입니다. 프로그램을 사용할 사람들의 관점에 따라 그들이 원하는 것은 판이하게 다를 것입니다. 또한, 이들 프로그램의 개발자들을 위한 모델 역시 다양할 수 있습니다. 사용자 관점은 프로그램의 가치를 반영하는 반면, 일반적으로 개발자들에 제공되는 모델이 다양할수록 개발에 대한 이해가 높아질 수 있겠죠. UML은 이러한 다양한 관점을 다룰 수 있는 효과적인 도구가 될 수 있음을 보게 될 것입니다.

UML의 역사

이제 UML에 대한 이해를 하기에 앞서 간략하게 UML의 역사를 되돌아 보도록 하겠습니다. Grady Booch, James Rumbaugh와 Ivar Jacobson, 세 사람은 80년대부터 각자의 객체지향 방법론을 연구합니다. 1994년 Booch가 세운 Rational사에 Rumbaugh가 합류하고, 일년 후 Jacobson이 합류하면서 이들의 연구는 하나로 결집되어 UML 드레프트(draft) 버전을 만들어냅니다. 이것은 소프트웨어업계에 큰 반향을 일으키며 Microsoft, Oracle, HP, DEC, TI 등 유수의 멤버로 결성된 UML 컨소시엄을 발족하게 됩니다.

1997년 UML 컨소시엄은 UML 버전 1.0을 만들어 내고 이를 OMG(Object Management Group)에 제출합니다. 그 해 말에 OMG는 이를 수정한 UML 1.1을 표준 모델링 언어로 채택하기에 이르죠. 현재 1.3 스펙에 이어 1.4 버전까지 논의되고 있습니다.

UML은 많은 모델링 도구들로 이루어져 있는데 이는 모두 새로운 개념이 아닙니다. UML은 산재한 많은 모델링 언어들을 통합해서 장점을 취합하기 위한 방안이라고 볼 수 있죠. 또한 OMG와 같은 권위 있는 표준 기구를 통해 UML을 표준 모델링 언어로 채택해서 이를 적용한 모델러가 다르더라도 모델을 통한 의사소통이 가능하게 된 것입니다.

UML의 구성

UML은 다양한 모델링 도구로서의 다이어그램 들을 통일시킨 것입니다. 다음은 UML의 주요 다이어그램의 명칭들을 나열한 것입니다.

• 클래스 다이어그램(Class Diagram)
  
• 객체 다이어그램(Object Diagram)
  
• 쓰임새 다이어그램(Use-case Diagram)
  
• 상태 다이어그램(State Diagram)
  
• 시퀀스 다이어그램(Sequence Diagram)
  
• 활동 다이어그램(Activity Diagram)
  
• 협력 다이어그램(Collaboration Diagram)
  
• 컴포넌트 다이어그램(Component Diagram)
  
• 배치 다이어그램(Deployment Diagram)

이들 다이어그램은 시스템(소프트웨어라고 할 수도 있으나 좀더 명확한 표현을 위해 시스템이란 용어를 사용)의 정적인 구조를 보여주는 것과 동적인 행동을 나타내는 것으로 크게 양분할 수도 있습니다.

UML은 왜 이렇게 많은 다이어그램을 포함하고 있는 것일까요? 그 이유는 다양한 관점을 반영하여 개발하고자 하는 시스템에 대한 많은 뷰(View)를 제공하기 위함이죠. 시스템 개발에는 많은 이해관계자가 존재합니다. 시스템 개발을 의뢰한 고객이나 장차 이를 사용하게 될 사용자를 비롯해서, 다양한 역할을 갖는 개발자와 프로젝트 관리자 등 많은 사람들이 관여하게 되는 것은 당연한 일이죠.

UML은 이들 중 누구 하나의 관점만을 표현한다면 가치가 낮아질 것입니다. 따라서, 많은 이해 관계자들의 관점에 맞는 뷰를 보여주는 것입니다. 고객이 바라볼 때 이 시스템은 어떤 모습이 될 것인지를 보여주고, 개발자가 바라볼 때 이 시스템이 어떤 구성과 동작으로 이뤄질 지를 보여주는 것입니다. 고객 역시 하나의 관점을 지니지는 않습니다. 음료수 자동판매기 시스템의 이용자는 대부분 음료수를 뽑아 마시길 원하지만, 수금을 하고, 음료수를 채워넣는 사람들도 시스템의 이용자라고 볼 수 있죠. 마찬가지로 개발자 역시 자신이 맡은 부분에 따라 시스템을 상이한 수준에서 바라볼 것입니다. 전체적인 아키텍쳐를 결정할 사람은 보다 높은 수준에서 시스템을 추상적으로 보길 원할 것이고, 직접 코딩을 할 사람들에게는 이러한 모호한 다이어그램보다는 상세한 객체의 구조와 상호작용을 보여주는 모델을 필요로 할 것입니다.

UML에 이렇게 많은 다이어그램이 존재하게 됨으로 해서 또 한가지 중요한 것은 이들 간의 통합 혹은 무결성(Integrity) 보장입니다. 서로 다른 뷰를 제공하지만 결국 시스템은 하나입니다. 따라서, 이들 다양한 다이어그램이 서로 개별적으로서만 의미를 지니는 것이 아니라, 상호 연관성이 있어야 하고, 때에 따라서는 변환도 가능해야 합니다. UML 모델링 지원 도구인 Rational Rose의 경우 이러한 다이어그램간의 무결성을 보장합니다.

UML을 이용한 모델링, 어떻게 할 것인가?

그렇다면 이러한 모델링을 어떻게 어느 정도까지 수행해야 할 것인가? 일반적으로 시스템을 개발하는 프로젝트는 시간과 예산의 제약을 받으면서 고객의 요구를 충족시켜 줄 수 있어야 합니다. 고객의 요구를 파악하기란 쉬운 일이 아니죠. 오늘날의 시스템은 다수의 사용자를 갖게 되고 통합화 되는 추세라, 고객의 요구사항을 파악하는 것은 더욱 어려워지고 있습니다.

요구사항을 정확히 파악하기 위해서는 반복적인 분석과 설계 과정을 행하는 것이 좋죠. 그렇게 되면 모델링에 많은 노력이 가해집니다. 많은 모델을 만들어낼수록 상대적으로 많은 뷰를 나타낼 수 있고, 요구사항에 근접해간다고 볼 수 있습니다. 그러나, 모델링 작업은 시간과 자원을 필요로 합니다. 분석 전문가나 모델러가 필요하고, 고객 및 개발자와 오랜 시간의 공동작업도 필요하게 되죠.

모델링을 어느 정도 까지 해야 한다는 정답은 없습니다. 경험에 의존해야 하고, 각 조직의 환경이 반영되기 마련이죠. 따라서, 이들 다이어그램을 익히고 나서 프로젝트에 필요한 UML 다이어그램의 적절한 조합을 만들어내는 일이 필요하겠습니다.

##########2*
[UML 로고]