hyeonsig notes

Unified Modeling Language(UML)[각주:1]은 어원에서 살펴볼 수 있듯이 모델링과 관련된 기술입니다. 다양한 객체 지향 개발방법의 효율적인 분석과 설계를 위해 모델 표기 방법을 통일하여 만든 모델링 언어입니다.

UML이 처음부터 현재의 위치에 자리 잡은 것은 아닙니다. 초기 다양한 언어들이 경쟁했고, 최종적으로 Rational사의 UML이 승자가 되었습니다. UML은 객체 지향 개발방법을 주장한 Grady Booch의 Object-Oriented Design(OOD)와 James Rumbaugh의 Object Modeling Technique(OMT) 그리고 Ivar Jacobson의 Object-Oriented Software Engineering(OOSE)를 통합한 언어입니다. 조금 더 정확히 이야기하면, 표기법을 통일하기 전에 개발 방법론의 통합에 대한 이야기(Unified Method)가 있었으나 실패(?)하고 Notation을 통일하는 것에 중점을 둬 UML이 등장하게 되었습니다. 최근에는 객체 지향 개발방법론뿐만 아니라 소프트웨어 공학에서 사용하는 표준화된 범용 모델링 언어로 사용되고 있습니다.


History

UML의 역사를 그림 한 장으로 표현하면 다음과 같습니다. UML은 1980년대 후반에서 1990년대 초반에 개발된 객체 지향 개발방법에 뿌리를 두고 있으며, 1990년대 중·후반 이후로 빠른 속도로 발전하고 있습니다. UML 역사에 대한 조금 더 자세한 내용은 여기에서 확인하실 수 있습니다.

더보기


그림에서 보실 수 있듯이 2005년도에 UML 2.0이 발표되었습니다. 2013년 10월 기준으로 가장 최신 버전은 UML 2.5β입니다.
이 단락에서는 UML 2.0에 대하여 조금 더 자세히 알아보겠습니다. 각 다이어그램별로 변경된 내용은 다이어그램을 소개할 때 설명할 것이므로, 주요 변경사항에 대해서만 설명하겠습니다.

정확한 언어 정의

Model-driven Development(MDD)에 필요한 고급 자동화를 지원
모델의 모호함과 부정확성을 제거하고, 프로그램이 모델의 변형 및 조작을 가능하게 함


향상된 언어 구조

사용자가 언어에 보다 쉽게 접근할 수 있으며, 도구간 내부 작동을 활성화 할 수 있는 모듈식 구조


규모가 큰 시스템의 모델링 향상

시스템이 더 복잡해지고 있으므로, 이를 지원하기 위해 유연한 새로운 계층 기능이 언어에 추가되어 소프트웨어 모델링을 지원


도메인 스팩의 특성화 지원 향상

"확장" 메커니즘 이용

기본적인 언어가 보다 정확하고 단순해지도록 정리되었음


다양한 모델링 개념들의 정리, 개념화, 정의

보다 단순하고 일관성 있는 언어

중복된 개념을 제거하고, 많은 정의들을 정리했으며, 텍스트 정의와 예제 추가


UML Diagram

UML 2.0에서 제공하는 다이어그램의 종류는 다음과 같습니다.

모델 계층 다이어그램 설명
정적 구조다이어그램 클래스(Class) 클래스 구조를 나타내는 다이어그램
오브젝트(Object) 인스턴스 구조를 나타내는 다이어그램
컴포넌트(Component) 시스템을 구성할 컴포넌트들의 구조를 나타내는 다이어그램
컴포지트(Composite) 시스템을 실행할 때의 구조를 나타내는 컴포지트 구조를 표현
패키지(Package) 내부에 모델 요소를 포함할 수 있는 패키지 구성을 표현
디플로이먼트(Deployment) 시스템의 물리적인 하드웨어 구성을 나타내는 다이어그램
동적 인터액션 시퀀스(sequence) 오브젝트 사이의 메시지 교환을 나타내는 다이어그램
타이밍(Timing) 한 상태에서 객체가 얼마나 오랜 시간을 지체하는지 명시
커뮤니케이션(Communication) 오브젝트 사이의 메시지 교환을 나타내는 다이어그램
인터액션 + 행위 인터액션(Interaction) 오브젝트 간의 메시지 교환을 액티비티 다이어그램과 같은 형태로 나타내는 다이어그램
인터액션내 행위 액티비티(Activity) 액티비티의 실행순서나 실행조건, 실행자의 관계를 표현
스테이트 머신(State-Mac.) 상태 전이와 상태 전이에 따른 액션을 나타내는 다이어그램
요구분석 유즈케이스(Use-Case) 시스템이 제공할 서비스와 그 이용자의 관계를 표현


UML 사용의 장점

UML을 도입하면 어떤 장점이 있을까요? 조금 시간을 두고 생각해보면, 셀 수 없이 많은 장점을 찾아낼 수 있을 것입니다. 그리고 찾아낸 장점을 범주화하면 몇 개의 큰 카테고리로 묶을 수 있을 것입니다.

첫째, 팀 구성원의 의사소통 효율의 향상을 이야기할 수 있습니다. 실제로 프로젝트 또는 어떤 일을 진행하다 보면, 의사소통으로 소비되는 비용이 매우 비싸다는 것을 알 수 있습니다. 특히, 조직/팀 구성원이 많을수록 의사소통 비용은 급격하게 증가할 것입니다. UML은 모델링 도구입니다. 모델링의 장점은 이해하기 쉽고, 서로 약속된 표현법을 활용하므로 오해의 소지가 줄어듭니다. 이처럼 UML을 활용하면, 의사소통 비용을 줄일 수 있습니다. 추가로 데이터 모델을 활용하면 금상첨화겠죠?

둘째, UML은 국제 표준(de jure)[각주:2]입니다. 최근에는 객체 지향 개발방법뿐만 아니라 다양한 개발방법에서 활용하고 있으며, 설명서를 UML에 기반을 두어 작성하고 있습니다. 소프트웨어 아키텍처 패턴이나 디자인 패턴을 소개하는 문서를 살펴보신 적이 있으신가요? UML을 이해하지 못하는 경우 해당 패턴을 이해하기 매우 어려울 것입니다. 그러나 UML을 정확히 이해하고 있으면, UML로 작성된 방대한 정보에 쉽게 접근할 수 있고, 이 정보를 기반으로 다양한 아이디어를 도출할 수 있을 것입니다.

마지막으로 문서화가 쉽습니다. 필자는 문서화를 매우 중요하게 생각합니다. 아마 필자뿐만 아니라 대부분 동의하실 것으로 예상합니다. 그러나 프로젝트를 진행하다 보면, 프로젝트 일정과 비용 등으로 말미암아 문서화를 진행하지 못하는 경우를 자주 볼 수 있었습니다. UML과 같은 모델링 정보는 프로젝트의 생산성 향상뿐만 아니라 훌륭한 문서화 도구가 될 수 있습니다.


UML 사용의 문제

앞 단락에서 UML을 도입할 때의 장점을 살펴봤습니다만, 이 단락에서는 UML을 사용할 때의 단점에 대해 알아보겠습니다. 솔직히 말씀드려서 문제라고 하기는 조금 어색하고 고려사항이라고 보는 것이 좋을 것 같습니다.

첫째, UML을 도입/사용하는 이유가 명확해야 합니다. 프로젝트와 관련된 내용을 고려한 후, UML의 도입 방향을 제시해야 합니다. 굳이 사용하지도 않을 UML을 작성하면, 쓸데없이 시간과 비용이 소비됩니다. 예를 들어, 아주 적은 비용과 짧은 시간이 주어진 프로젝트에서 앞에서 이야기한 13가지의 UML 다이어그램을 모두 도입하는 것은 불가능하겠지요? 

둘째, UML 다이어그램을 작성하기는 쉽지 않습니다. UML 다이어그램은 모델링 과정이므로 다양한 경험과 숙련도가 필요합니다. UML을 이해하고 있는 것과 보는 것, 그리고 작성하는 것은 서로 다른 우주라고 볼 수 있습니다. 또한, 고객이 요구하는 요구사항을 분석하여 UML 2.0에서 제시하는 13개의 다이어그램을 모두 효과적으로 작성할 수 있는 전문가를 만나는 것도 현실적으로 어려운 일입니다.

마지막으로 UML 활용 방안의 문제입니다. 매우 잘 작성된 UML 다이어그램이라도 프로젝트 구성원이 UML 다이어그램을 이해하지 못하면 그림의 떡일 뿐입니다. 기본적으로 도구를 활용하는 데에는 추가적인 비용이 소요됩니다. 어떤 도구든지 비용대비 효율성을 고려하여 합당하다고 인정될 때 사용하는 것이 좋을 것 같습니다.


마치면서

지금까지 UML에 대하여 간단히 알아봤습니다. 실제 UML의 스펙을 살펴보면, 웬만한 전공서적 1권 이상의 분량임에 놀라실 것입니다. 여유가 되신다면 한 번쯤 도전해 보는 것도 나쁘지는 않습니다만, 시중에 UML과 관련된 도서들이 많이 출간된 상태이므로 개인적인 의견으로는 좋은 UML 책을 선정하여 보는 것이 생산적인 일이라고 생각합니다.


References

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://i-bada.blogspot.kr/2012/04/umlunified-modeling-language-20.html

이노우에 타케시, 다이어그램으로 쉽게 배우는 UML

아사이 마이외, UML 실무 테크닉

  1. 통합 모델링 언어(표준화된 모델링 언어) [본문으로]
  2. ISO/IEC 19505-1:2012외 [본문으로]
DISQUS 로드 중…
댓글 로드 중…

블로그 정보

hyeonsig notes - 천사마음

Carpe Diem~♥ 내일이 기대되는 사람이 되자.

최근에 게시된 글