Unified Modeling Language version 2.0

모델 중심 개발

머리말

1990년대 초반에는 객체 패러다임과 관련 기술들이 큰 주목을 받았다 이 패러다임에 기반한 새로운 프로그래밍 언어들(Smalltalk, Eiffel, C++, Java)이 고안 및 채택되었다. 이런 과정에서 객체 지향(OO) 소프트웨어 디자인 방식과 모델링 표기법이 과잉으로 공급되었다. 따라서 OO 분석 및 디자인 방식을 다룬 개론서(800 페이지)에서 Graham은 50 개의 발달 가능성이 있는 방식을 추려냈다. [Graham01]

객체 패러다임이 비교적 작은 개념들(캡슐화, 상속, 다형성)로 구성된다면 수 많은 중복과 개념상의 재정비에 불과하다. 그리고 대부분이 표기법과 중요하지 않는 차이들로 인해 모호해졌다. 이것은 많은 혼란을 낳았고 쓸데없는 시장 분리를 만들었다. 결국 새롭고 유용한 패러다임을 만들어야 하는 지경에 이르렀다. 소프트웨어 개발자들은 호환되지 않는 언어, 툴, 방식, 벤더들 사이에서 선택의 어려움을 겪어야만 했다. 이러한 이유 때문에, Rational 소프트웨어가 Grady Booch, Ivar Jacobson, Jim Rumbaugh가 중심이 된 Unified Modeling Language (UML) 이니셔티브를 제안했을 때 반응은 즉각적이고 호의적이었다. 새로운 것을 제안하려고 했던 것은 아니었지만 산업계의 선각자들의 공동 노력을 통해, 최고의 기능을 가진 여러 OO 방식들을 하나의 벤더 독립적인 모델링 언어와 표기법으로 탄생시켰다. 이 때문에 UML은 빠르게 표준으로 자리잡았다. 1996년에 Object Management Group이 이를 채택한 후에 산업 표준 [OMG03a] [OMG04] [RJB05]이 되었다.

이후, UML은

• 대부분의 모델링 툴 벤더들에 의해 채택 및 지원되었다.
• 전 세계 대학들과 전문 연구 프로그램 분야에서 컴퓨터 공학 및 엔지니어링 커리큘럼으로 자리잡았다.
• 학계와 연구소에서 편리한 공통 언어로 사용되고 있다.

UML은 복잡한 소프트웨어를 다룰 때 모델링의 가치를 일깨워주었다. 이렇게 유용한 기술은 소프트웨어 역사 만큼 오래되었음에도, 대부분의 개발자들은 그저 유용한 모니터 툴로서 인식하고 있다. 여전히 이러한 태도들이 지배적이다. 바로 이것이 모델 중심의 방식들이 커뮤니티에서 상당한 저항에 부딪치는 이유이기도 하다.

이렇게 된 데에는 그럴듯한 이유들이 있다. (혁신적인 것이라면 불신하고 보는 인간 본성 같은 터무니 없는 이유도 물론 있다.) 가장 큰 이유는 소프트웨어 모델이 심각할 정도로 정확하지 않다는 점이다. 모델의 실제 가치는 정확성에 비례한다. 모델이 소프트웨어 시스템에 대해 진실을 보여주고 있다는 신뢰를 얻지 못하면 쓸모가 없다. 잘못된 결론을 낼 수 있기 때문이다. 소프트웨어 모델의 가치를 높일 수 있는 핵심은 모델과 시스템들간 차이를 좁히는 것이다. 이상하게 들릴지도 모르겠지만 소프트웨어 분야에서 이를 실현하기는 쉽다.

몇몇 정확하지 않은 소프트웨어 모델링은 현재 프로그래밍 언어들이 지나치게 자세하고 민감하기 때문이기도 하다. 잘못 정렬된 포인터 또는 초기화 되지 않은 변수들 같은 작은 과실과 쉽게 분간할 수 있는 코드 오류가 엄청난 결과를 가져올 수 있다. 예를 들어, 중첩 switch 구문에서 한 개의 브레이크 소실로 인해 미국의 많은 부분을 담당하고 있는 장거리 전화 서비스에 오류가 생기고 이로 인해 거대한 경제적 손실을 일으킬 수 있는 것이다. [Lee92]. 그와 같은 미미한 세부 사항들이 그와 같은 엄청난 결과를 일으켰다면 어떻게 우리가 모델링이 정확하다고 믿을 수 있겠는가?

위로

모델 중심 개발

이 같은 문제에 대한 솔루션은 한 개 이상의 자동화된 모델 변형을 통해 해당 소프트웨어 구현에 모델을 연결시키는 것이다. 아마도 이것에 대한 가장 성공적인 예가 컴파일러일 것이다. 컴파일러는 고급 언어 프로그램을 머신 언어 구현으로 바꾼다. 이 경우, 모델은 고급 언어 프로그램이고, 모든 유용한 모델들이 그러하듯, 별 관련이 없는 기저의 컴퓨팅 특성들(내부 단어 크기, 누산기와 인덱스 레지스터의 개수, ALU의 유형 등)은 숨긴다.

몇 가지 다른 엔지니어링 미디어가 모델과 해당 엔지니어링 객체간 강결합을 제공한다는 점이 흥미롭다. 여러분이 모델링하고 있는 객체는 하드웨어가 아닌 소프트웨어이기 때문이다. 물리적 객체(예를 들어, 자동차, 빌딩, 다리)의 모델에는 해당 모델의 물리적 특성들을 추상화 하는 비공식 단계들이 포함된다. 이와 비슷하게 물리적 객체들을 사용하여 추상 모델을 구현할 때, 추상 모델을 구체 모델로 비공식으로 변형한다. . 이러한 비공식 단계 때문에 앞서 언급한 부정확성 문제가 발생하는 것이다. 하지만 공식적으로도 수행될 수 있다.

추상화와 자동화의 강력한 결합으로 새로운 모델링 기술과 이에 상응하는 개발 방식들(모델 중심 개발 (MDD) [Brown04] [Booch04])을 탄생시켰다. MDD의 대표적인 특징은 모델들이 소프트웨어 디자인의 주요 객체들이 되면서 해당 프로그램 코드로의 초점을 분산시켰다는 점이다. 이들은 다양한 자동화/반자동화 프로세스들이 프로그램들과 관련 모델들을 유추할 수 있는 청사진으로서 작용한다. 오늘날 MDD에서 사용되는 자동화 정도는 간단한 뼈대 코드를 유추하는 것부터 완전한 자동 코드를 생성하는 것 까지 다양하다. 분명한 것은 자동화 레벨이 높아질수록 모델은 더욱 정확해지고 MDD의 효용도 높아진다.

모델 중심 방식으로 소프트웨어를 개발하는 것은 전혀 새로운 것이 아니며 과거에도 사용되었다. 지금 이렇게 주목을 받고 있는 이유는 지원 기술이 성숙해졌기 때문이다. 이전보다 더 많이 자동화 되었다. 효율성 뿐만 아니라 확장성, 그리고 레거시 툴과 메소드와 통합되는 툴 기능까지 있다. 기술이 성숙하면서 MDD 표준이 만들어지게 되었다. 이들 표준들 중 하나가 바로 개정된 버전의 Unified Modeling Language이다.

위로

UML 1 개정의 이유

UML2.0은 UML 표준의 첫 번째 중요 개정이다. 이것 외에도 몇 가지 중요하지 않은 개정들 [OMG04] [RJB05]이 있다. 왜 UML을 개정해야 했을까?

가장 중요한 동기는 MDD 툴과 메소드를 보다 잘 지원하기 위해서이다. 과거 10년 동안, 많은 벤더들이 전통적인 CASE(computer-aided software engineering) 툴 보다 한층 더 수준 높은 자동화를 지원하는 UML 기반의 툴을 개발했다.

수준 높은 자동화를 지원하기 위해서는 원래 표준보다 더 정확한 방식으로 UML을 정의해야 했다. (원래의 UML 표준은 디자인의 비공식 캡쳐와 통신을 위한 보조 툴로서 기획되었다.) 불행히도 이러한 정의는 벤더마다 다양하여 원래 표준이 제거하려고 했던 부분을 따라야 하는 이상한 경우가 생겼다. 새로운 버전은 이러한 점을 수정한 것이다.

10년 동안 중요한 새로운 기술들(웹 기반 애플리케이션과 서비스 지향 아키텍쳐)이 생겨났고 새로운 모델링 기능들이 정의되었다. 이 모든 것들은 실제로 기존의 UML 개념들을 적절히 조합하여 정의된 것이다.

그동안 산업은 모델링 언어의 사용, 구조화, 정의하는 적절한 방식을 많이 터득했다. 이제는 메타 모델링과 모델 변형에 대한 이론이 부상하고 있고, 모델링 언어가 정의되는 방식도 요구하는 추세이다. 현재의 프로그래밍 언어 디자인의 이론에 견줄만한 모델링 언어 디자인의 체계적인 이론이 부족하지만 UML에 통합되어 생명력을 늘릴 수 있다.

위로

UML 2.0 기능

새로운 UML 2.0의 특징은 다음과 같이 다섯 개의 주요 범주로 설명할 수 있겠다. 중요한 것부터 설명하겠다.

• 매우 정확해진 언어 정의: 이렇게 정확해진 데에는 MDD에 필요한 고급 자동화를 지원해야 하기 때문이다. 자동화에는 모델의 모호함과 부정확성을 없애고 컴퓨터 프로그램이 모델을 변형 및 조작할 수 있도록 했다.
• 향상된 언어 구조: 새로운 사용자가 언어에 보다 쉽게 접근할 수 있고 툴들 간 내부 작동을 활성화 할 수 있는 모듈식이다.
• 규모가 큰 소프트웨어 시스템의 모델링 향상: 현대식의 소프트웨어 애플리케이션은 기존 스탠드얼론 애플리케이션들과 복잡한 시스템들이 통합된 것이다. 시스템은 더욱더 복잡해지고 있는 추세이다. 이를 지원하기 위해 유연한 새로운 계층 기능이 언어에 추가되어 소프트웨어 모델링을 지원한다.
• 도메인 스팩의 특성화 지원 향상: UML을 실제로 사용하면 소위 말하는 " 확장" 메커니즘의 가치를 느낄 수 있다. 기본적인 언어가 보다 정확하고 단순해지도록 정리되었다.
• 다양한 모델링 개념들의 정리, 개념화, 정의: 보다 단순하고 일관성 있는 언어가 되었다. 중복된 개념을 제거하고, 많은 정의들을 정리하고, 텍스트 정의와 예제를 추가했다.

이제 부터는 보다 자세히 설명하도록 하겠다.

정확도

대부분의 초기 소프트웨어 모델링 언어는 비공식적으로 정의되었다. 정확도에 대한 관심도 별로 없었다. 대게, 모델링 개념들은 정확하지 않은 자연 언어로 설명되었다. 그 당시에는 이것으로 충분했다. 대부분의 모델링 언어들이 문서화나 디자인 스케치[Fowler04]에 사용되었다. 기본 개념은 디자인의 핵심 속성들을 전달하는 것이다. 상세한 부분은 구현 시에 다루어지도록 했다.

바로 이것이 혼란의 원인이다. 그와 같은 언어로 표현된 모델들을 사람들마다 다르게 해석하기 때문이다. 더욱이 모델 해석에 대한 의문점이 명료하게 다루어지지 않으면 차이점을 끝내 발견하지 못하다가 결국 개발의 마지막 단계에서나 발견되곤 했다. (그 문제를 픽스하는 비용이 더 크다.)

이러한 모호함을 줄이기 위해 UML 첫 표준 정의가 메타모델(metamodel)을 사용하여 정의되었다. 메타모델은 각 UML 모델링 개념의 특징과, 다른 모델링 개념들과의 관계를 정의하는 모델이다. 이 메타모델은 UML의 한 요소를 사용하여 정의되었고 Object Constraint Language (OCL)로 작성된 정식 제약으로 보완되었다.

주: UML 클래스 다이어그램에서 정의된 개념들로 구성된 UML의 하위 세트를 Meta-Object Facility (MOF)라고 한다. 이 하위세트는 다른 모델링 언어를 정의하는데도 사용된다.

이렇게 조합하여 UML의 추상 신택스에 대한 공식 스팩을 선보였다. 이것은 실제 표기법이나 구체적 신택스 (텍스트와 그래픽)와 무관하기 때문에 모델을 표현하는데 사용되었다. 다시 말해서 이것은 해당 모델이 잘 구성되었는지 여부를 결정할 때 사용할 수 있는 규칙 세트를 정의한 것이다. 예를 들어, 그와 같은 규칙들을 사용하여 우리가 두 개의 UML 클래스들을 상태 머신 이동에 의해 연결하는 것이 옳지 않다는 것을 결정할 수 있는 것이다.

하지만 초기 UML 메타모델에 사용된 정확도로는 MDD를 완전히 지원할 수 없었다. ([Stevens02]). 특히 UML 모델링 개념의 의미론(또는 의미)에 대한 스팩은 자동 코드 생성 또는 확인 같은 MDD 지향 작동에는 부적합했다.

결과적으로 UML 2.0에서 정확도는 매우 증가했다.

• 메타모델 인프라의 리팩토링: UML 2.0의 인프라는 소프트웨어 애플리케이션의 모델링에 직접 사용하기에는 다소 부족하고 추상적인 저급의 모델링 개념과 패턴들로 구성된다. 하지만 이렇게 단순하기 때문에 의미와 규칙을 명확히 표현하는 것이 더 쉬워졌다. 이렇게 잘 정리된 개념들은 다양한 방식들로 조합되어 보다 복잡한 사용자 레벨의 모델링 개념들을 만들어낸다. 예를 들어, UML1에서 소유권(ownership) (다른 엘리먼트를 소유한 엘리먼트), 네임스페이스 (고유의 이름을 가진 엘리먼트의 네임드 컬렉션), 클래스파이어(기능에 따라 나뉠 수 있는 엘리먼트) 등 이들 모두 하나의 의미론적 복합 개념으로 묶이게 되었다. 새로운 UML 2.0 인프라에는 이들 개념이 분리되었고 신택스와 의미도 개별적으로 정의된다.
• 확장되고 보다 정확해진 의미 설명: UML 1 모델링 개념에서 의미론의 정의는 문제가 많았다. 디스크립션 레벨은 일관성이 없었고 확장 디스크립션과 상세 디스크립션이 있는 몇 가지 영역(상태 머신)이 있었지만 다른 것에는 어떤 설명도 없었다. UML 2.0 스팩은 의미를 강조하였다. 특히 기본적인 작동 원동력의 핵심 분야의 의미에 더욱 신경을 썼다. (참고자료)
• 분명하게 정의된 역할 의미: UML 2.0 스팩은 원 버전의 심각한 의미 차이를 명확히 했다. 그 프레임웍은 그림 1에 묘사되어 있고 아래 참고자료 섹션에도 설명되어 있다. [Selic04]. 특히 이 프레임웍에서는 다음과 같은 이슈들이 분명히 다루어졌다.
  • 런타임 시 링크와 인스턴스의 구조적 의미
  • 구조와 작동의 관계
  • 현재 UML의 모든 고급 작동 형식에서 공유되고 있는 의미의 기초 또는 일상성 모델(스테이트 머신, 액티비티, 인터랙션)과 잠재적인 미래 모델. 또한 다양한 형식을 사용하여 표현되는 객체의 작동은 서로 인터랙팅 하는지를 확인한다.

새로운 언어 아키텍쳐

UML 2.0이 정확성이 향상되면서 언어 정의도 더 커졌다. 심지어 새로운 모델링 기능에 대한 설명도 없는 경우도 생겼다. 원래 UML이 너무나 ‘풍부’했기 때문에 비평을 받았다는 사실을 생각해보면 걱정스럽지 않을 수 없다. (다시 말해서, 배우고 사용하기에는 너무 ‘둔중’했다.)

일반적으로 UML이 오늘날의 소프트웨어 문제들 중 가장 복잡한 요소를 다루려고 했고 이 같은 문제들은 강력한 툴을 사용해서 해결해야 한다는 사실을 무시했기 때문에 그러한 비평이 생긴 것이다. (자동차와 전자기술 같은 성공적인 기술은 결코 단순해지지 않는다. 머신에 끊임없이 요구하는 것이 인간 본성이다. 결국 보다 강력한 툴들이 생기기 마련이다. 어떤 누구도 기본적인 소도구만으로 마천루를 지을 수 있다고 생각하지 않는다.)

언어의 복잡성 문제를 다루기 위해 UML 2.0은 언어 모듈을 선택적으로 사용할 수 있는 방식으로 구성했다. 일반적인 구조는 그림 2에 나와있다. 이것은 공유 개념들(클래스와 관련 개념)로 이루어진 기초로 구성된다. 그 위에는 하위 언어 또는 언어 단위의 모음들이 수직적으로 구성되어 있다. 이들 각각은 특정 형태나 양상을 모델링 하는데 알맞다. (표 1). 이러한 언어 단위들은 일반적으로 독립적이며 따라서 독립적으로 사용할 수 있다. (이것은 UML 1의 경우가 아니다. 액티비티 형식주의는 상태 머신의 형식주의에 전적으로 기반하고 있다.)

더욱이 수직적 언어 단위들은 최대 세 가지 레벨들로 구성된다. 이 레벨들은 아래 레벨에서 사용했던 것에 더 많은 모델링 기능을 추가한다. 주어진 언어 단위 내에서 특정 하위세트만 사용할 수 있다.

이 아키텍쳐는 여러분에게 가장 잘 맞는 UML의 하위세트만 배우고 사용할 수 있다는 것을 함축하고 있다. 영어를 잘 구사하기 위해 영어에 대한 모든 것을 알아야 할 필요가 없듯, UML을 효과적으로 사용하기 위해 UML의 전체 범위를 알 필요는 없는 것이다. 좀더 능숙해지면 필요한 모델링 개념들만 도입할 수 있다.

표 1. UML 2.0의 언어 단위

호환성의 정의와 구조도 UML 2.0에서 매우 단순해졌다. UML 1에서 호환성의 기본 단위들은 메타모델의 패키지에 의해 정의되었다. 말 그대로 수 백 개의 조합이 가능했다. (사실, UML 1이 호환 대상에 불완전한 호환 개념을 정했기 때문에 벤더들은 아무 조합에나 호환성을 주장할 수 있었다.) 따라서 모델들을 교환할 수 있는 두 개 이상의 모델링 툴들을 찾기 힘든 것이다.

UML 2.0에서, 단 세 개의 호환성 레벨만 정의된다 그리고 계층적 언어 단위 레벨에 순응하는 것은 0으로 표시되었다. 레벨(n)의 모델이 더 높은 레벨(n+1)에 있는 모델들에도 호환되도록 정의되었다. 다시 말해서, 주어진 레벨과 호환되는 툴은 각 레벨에 순응하는 툴에서도 모델들을 반입할 수 있다. 이때 손실되는 정보도 없다.

주: UML 2는 4 번째 레벨(Level 0)도 정의한다. 하지만 이것은 툴 구현자들이 주로 사용하는 내부 레벨이다.

네 가지 유형의 호환성이 정의되어 있다.

• 추상 신택스 호환
• 구체적 신택스(UML 표기법) 호환
• 추상/구체적 신택스 호환성
• 추상/구체적 신택스에 대한 호환과 다이어그램 교환 표준[OMG03b]에 대한 호환

최대 12 개의 다른 호환성 조합이 이들 간 확실한 종속관계와 함께 명시되었다. (예를 들어, 추상/구체적 신택스 호환은 구체적 신택스 호환에만 순응하거나 추상 신택스 호환에만 순응한다.) 결과적으로 UML 2.0에서 다중 벤더들이 제공하는 호환 툴들 간 모델 교환이 더욱 확실해 진 것이다.

대규모 시스템 모델링 기능

UML 2.0에 추가된 기능들은 비교적 적은 편이다. 이게 다 불명예스러운 제 2의 시스템 효과[Brooks95]를 피하기 위해서 이다. 다양한 사용자 커뮤니티가 요구하는 과도한 새로운 기능들 때문에 언어는 부풀려진다. 사실 대부분의 새로운 모델링 기능들은 기존 기능들의 단순한 확장일 뿐이고, 이것은 대규모의 소프트웨어 시스템을 모델링 하는데 사용할 수 있다.

더욱이 확장은 똑 같은 기본 방식을 사용하여 이루어진다. 같은 개념을 각기 다른 추상화 레벨에 반복적으로 적용하면 된다. 다시 말해서, 해당 유형의 모델 엘리먼트들을 조합하여 단위로 만들고 다음 추상화 레벨에서 같은 방식으로 조합되도록 할 수 있다. 이것은 프로그래밍 언어의 프로시저가 다른 프로시저 안에서 중첩되는 방식과 비슷하다.

다음 모델링 기능들은 위에 설명한 방식으로 확장되었다.

• 복잡한 구조(Complex structures)
• 액티비티(Activities)
• 인터랙션(Interactions)
• 상태 머신(State machines)

위 세가지 요소는 UML 2.0에서 거의 90% 이상을 차지하고 있다.

복잡한 구조(Complex structures)

이 기능 세트는 UML-RT [SR98], Acme [GMW97], SDL [ITU02] 같은 다양한 아키텍쳐 디스크립션 언어들에 기반하고 있다. 그래프로 개념을 나타내는 특징이 있다. 한 개 이상의 포트(port)를 갖고 있는 파트(part)라고 하는 기본 구조적 노드들은 커넥터(connector)라고 하는 통신 채널을 통해 서로 연결된다. (그림 3) 이러한 집합체들은 자신의 포트를 갖고 있는 더 높은 레벨 안에서 캡슐화 되어 다른 상위 레벨에 조합될 수 있다.

이 개념들은 협업에 대한 UML 1 정의에서도 이미 있었다. 단 반복적으로 적용되지 않는 점만 다르다. 반복을 적용하기 위해서는 협업 구조가 클래스 스팩 내에 중첩되어야 한다. 다시 말해서, 그 클래스의 모든 인스턴스들이 클래스 정의로 지정된 내부 구조를 갖고 있어야 한다. 예를 들어, 그림 3에서 /a:A 파트와 /b:B 는 파트 /c:C 내에서 중첩된다. 이것은 합성 구조 클래스 C의 인스턴스를 나타낸다. 이 클래스의 다른 인스턴스들도 같은 구조적 패턴을 갖고 있다. (모두 포트, 파트, 상호연결 등의 개념을 갖고 있다.)

이 세 가지 기본 개념을 반복적으로 적용하는 것으로 임의의 복잡한 소프트웨어 아키텍쳐를 모델링 할 수 있다.

액티비티(Activities)

UML의 액티비티들은 다양한 종류의 흐름들을 모델링하는데 사용된다. 신호(signal)나 데이터(data) 흐름 뿐만 아니라, 알고리즘 (algorithmic) 흐름 또는 절차적(procedural) 흐름을 모델링 한다. 그와 같은 흐름 기반의 디스크립션에 의해 자연스럽게 렌더링 되는 수 많은 도메인과 애플리케이션들이 있음은 당연한 것이다. 특히 이러한 형식은 비즈니스-프로세스 모델러 뿐만 아니라 시스템 엔지니어들도 채택하고 있다. 불행히도 UML 1 버전의 액티비티 모델링의 경우, 흐름 유형에 제한이 많이 있었다. 액티비티가 기본 상태 머신 형식의 상단에 놓이게 되어서 상태 머신의 의미를 제약하기 때문이다.

UML 2.0은 상태 머신 기초를 훨씬 더 일반적인 의미로 바꾸어 그 모든 제한사항을 없앴다. (사실 의미 기초는 변형된 Petri nets [pet]로 나타난다.) 게다가 수 많은 산업 표준의 비즈니스 프로세싱 형식(주로 BPEL4WS [BPEL03]) 때문에 새로운 고급 모델링 기능들이 기본 형식에 많이 추가되었다. 기능은 다음과 같다.

• 인터럽트 액티비티 흐름
• 세련된 동시 제어 형식
• 다양한 버퍼링 스키마

결과적으로 광범위한 흐름 유형을 나타낼 수 있는 풍부한 모델링 툴셋이 탄생했다.

복잡한 구조와 마찬가지로 액티비티들과 액티비티의 상호 연결 흐름을 반복적으로 그룹핑하여 뚜렷하게 정의된 인풋과 아웃풋을 가진 고급 액티비티로 나타낼 수 있다. 다른 액티비티들과 이들을 결합하여 보다 복잡한 액티비티를 구성할 수도 있다.

인터랙션(Interactions)

UML 1의 인터랙션은 협업 다이어그램 상의 순차적인 메시지 주석으로 나타나거나 개별 시퀀스 다이어그램으로 표현되었다. 안타깝게도 이 두 가지 기본적인 기능들에는 다음 사항들이 빠져있다.

1. 보다 확장된(고급 레벨의) 시퀀스에서 반복될 수 있는 재사용 시퀀스 기능. 예를 들어 패스워드를 확인하는 시퀀스는 애플리케이션의 여러 컨텍스트에서 나타날 수 있다. 그와 같은 반복 시퀀스를 개별 단위들로 패키징하는 기능이 없으면 여러 번 이들을 정의해야 한다. 이는 오버헤드 문제 뿐만 아니라 모델 관리가 복잡해진다는 문제가 있다.
2. 복잡한 시스템의 인터랙션을 표현하는 다양한 복잡한 제어 흐름의 모델링 기능 여기에는 반복적인 연속 발생, 대안 실행 경로, 동시성, 순서와 무관한 실행 등이 포함되어 있다.

다행히도 복잡한 인터랙션을 지정하는 기능은 통신 도메인에서도 연구되고 있다. 통신 프로토콜[ITU04]을 정의했던 수년 간의 경험을 바탕으로 이 분야에서 표준이 진화하고 있다. 이 표준은 UML 2.0에서 인터랙션을 표현하는 기초로서 사용되었다.

무엇보다도 개별적인 네임드 모델링 단위로서 인터랙션을 도입했다는 점이 혁신적이다. 이 같은 인터랙션은 복잡한 객체간 통신 시퀀스를 나타낸다. 심지어 매개변수화되어서 컨텍스트와 관계 없는 인터랙션 패턴 스팩도 적용될 수 있다.

매크로 호출과 비슷한 상위 인터랙션 내에서 이러한 인터랙션 패키지들을 반복적으로 호출 할 수 있다. (그림 4) 이들을 임의 단계로 중첩 시킬 수 있다. 더욱이 인터랙션들은 루프(여러 번 반복되어야 하는 인터랙션)같이 복잡한 제어 구조체에서 피연산함수 역할을 한다. UML 2.0은 이러한 유형의 편리한 모델링 구조체들을 많이 정의하고 있다. 각 레벨에서 복잡한 엔드투엔드 작동을 모델링 하는데 사용할 수 있다.

그림 4는 확장된 인터랙션 모델을 묘사하고 있다. 이 경우, ATMAccess 인터랙션은 CheckPIN 이라고 하는 저수준 트랜잭션을 처음으로 호출한다. 나중에 발생하는 인터랙션은 매개변수를 갖고 있다. (이 경우, 무효 PIN이 트랜잭션이 취소되기 전에 입력될 수 있는 회수). 그 후, 클라이언트는 어떤 종류의 인터랙션이 필요한지, DispenseCash 인터랙션이나 PayBill 인터랙션중 어떤 것을 수행할지를 지정하는 비동기식 메시지를 보낸다.

UML 2.0의 인터랙션은 (위 예제 처럼) 시퀀스 다이어그램으로 표현될 수 있다. 또한 (UML 1에 정의된 협업 기반의 형태가 포함된) 다이어그램 유형으로도 그려진다. 심지어 그래픽이 없는 표로 그려질 수도 있다.

상태 머신(State machines)

UML 2.0의 상태 머신에 추가된 새로운 기능은 이전 경우와 비슷하다. 기본 개념은 혼합 상태를 완전히 모듈식으로 만들 수 있다. 변환 엔트리와 변환 종료점을 분명히 묘사된다. 따라서 재사용 가능한 개별적인 상태 머신 스팩에 의해 그 상태의 내부 분해를 정의할 수 있다. 다시 말해서, 같은 스팩이 상태 머신이나 다른 상태 머신 내의 여러 부분에서 재사용 될 수 있다. 여러 상황에서 공유된 작동 패턴의 스팩이 단순해진다.

그 외에도 클래스와 하위 클래스들간 상태 머신 상속에 대한 정의도 주목할 만 하다.

언어 부분의 기능들

UML 1에서는 UML의 가장 일반적인 사용법은 특정 문제나 도메인에 UML 프로파일을 정의하고, 일반 UML 대신에 프로파일을 사용할 것을 지시하고 있다. 프로파일은 일반적으로 domain specific languages(DSL)라고 알려진 것을 만드는 방식이다.

이 UML 프로파일에 대한 대안으로는 MOF 표준과 툴을 사용하는 새로운 커스텀 모델링 언어를 정의하는 것이 있다. 이 방식은 명확한 상태를 제공하며 문제에 대한 최적의 언어를 정의할 수 있는 장점이 있다. 언뜻 보기에 이것은 DSL에 좋은 방식이지만 보안상의 위험성이 있다.

머리말에서도 언급했듯이 너무나 많은 다양성 때문이 UML이 없애고자 했던 일종의 분파(fragmentation)가 생기고 말았다. 사실 바로 이러한 점이 광범위하고 빠르게 채택된 이유이기도 하다.

다행히도 프로파일 메커니즘은 실제로 많은 경우, 편리한 솔루션을 제공한다. 다양한 DSL 간 많은 공유점이 있기 때문이다. 어떤 객체 지향 모델링 언어도 클래스, 애트리뷰트, 연결, 인터랙션 등의 개념을 정의할 필요가 없다. 범용의 모델링 언어인 UML은 이 같이 편리하고 잘 정의된 개념들이 있다. 많은 DSL을 시작할 좋은 출발점이다.

하지만 여기에는 개념적인 재사용 그 이상이 있다. 정의에 따르면 UML 프로파일은 표준 UML과 호환이 되어야 한다. 다시 말해서, UML 프로파일은 도메인 스팩에 맞춰 해석을 하는 개념을 제한함으로서 표준 UML 개념들을 특화 할 수 있다. 예를 들어, 제한을 통해 다중 상속을 막거나, 클래스가 특정 유형의 애트리뷰트를 갖도록 한다.

• 표준 UML을 지원하는 어떤 툴도 프로파일에 기반한 모델을 조작하는데 사용될 수 있다.
• 표준 UML에 대한 어떤 지식도 직접 적용할 수 있다.

따라서 다양성에서 기인한 분파 문제들 대부분 해결될 수 있다. 통신 분야에서 광범위하게 사용되는 DSL인 SDL 언어[ITU02]를 담당하는 국제적인 표준 기구도 SDL을 UML profile [ITU00] [ITU03]로서 재정의하였다.

모든 DSL이 UML 프로파일로 실현되어야 한다는 것을 의미하지 않는다. 실제로 DSL 개념에 적용될 수 있는 필수적인 기본 개념들이 UML에는 부족하다. 하지만 UML이 일반화되면 더욱 광범위하게 적용될 것이다.

상황이 이렇기 때문에 UML 2.0의 프로파일링 메커니즘이 조정되었고 기능도 확장되었다. 일반 개념과 UML 개념들 간 개념적 연관관계도 정의되었다. 실제로 UML 2.0 표준은 기존 UML 메타클래스의 하위 클래스인 것처럼 정의된다. OCL 같은 언어를 사용하여 제한 사항을 작성하는 매커니즘은 완전히 정의되었다.

개별 모델링 개념을 제한하는 것 외에도, UML 20. 프로파일은 잘못되었거나 DSL에 필요하지 않은 UML 개념을 숨긴다.

마지막으로, UML 2.0 프로파일링 매커니즘은 여러 도메인 스팩에서 복잡한 UML 모델을 볼 수 있는 메커니즘으로 사용될 수 있다. 이중 어떤 것은 DSL로는 불가능하다. 어떤 프로파일이든 기저의 UML 모델에 영향을 주지 않고 적용 될 수 있고 또는 적용되지 않을 수도 있다. 예를 들어, 퍼포먼스 엔지니어는 모델을 통해 퍼포먼스 모델링을 분석하면서 다양한 퍼포먼스 관련 평가를 모델의 엘리먼트에 붙일 수 있다. 이것이 자동화된 퍼포먼스 분석 툴로 사용되어 기본적인 퍼포먼스 속성들을 결정할 수 있다. 동시에 퍼포먼스 모델러와는 독립적으로 신뢰성을 다루는 엔지니어가 신뢰성 스팩의 뷰를 관련 모델에 두고 전체 시스템의 신뢰성 문제를 결정할 수 있다.

기타

UML 2.0은 수 많은 영역을 다루고있다. 중복 개념들을 제거하고 많은 부분을 수정했다. (혼란스러운 설명 부분은 명확히 했고 용어와 스팩 포맷을 표준화했다.)

중복을 없애고 엉성하게 정의된 개념들을 정리했다는 점은 UML 2.0의 중요한 요소이다. 다음 세 가지 주요 영역에서 그러한 요구 사항들이 적용되었다.

• 액션과 액티비티(Actions and activities)
• 템플릿(Templates)
• 컴포넌트 기반 디자인 개념(Component-based design concepts)

액션은 UML 1.5에 도입되었다. 액션의 개념적 모델은 데이터 흐름과 제어 흐름 컴퓨팅 모델을 모두 수용할 수 있도록 만들어졌다. 결국 액티비티 모델 개념과 매우 비슷해졌다. UML 2.0은 이러한 유사점을 사용하여 액션과 액티비티에 대한 일반적인 문법 및 의미 구조를 제공하고 있다. 다른 레벨들에서 모델링하기 때문에 여러분에게는 다른 추상화 레벨에서 발생하는 형식으로 보여진다. 전체적인 단순함과 명확성에 기여했다.

UML 1에서, 템플릿은 매우 일반적으로 정의되었다. 어떤 UML 개념이라도 템플릿으로 만들어질 수 있었다. 불행히도 일반성은 이러한 애플리케이션에게는 장애가 된다. 왜냐하면 의미 없는 템플릿 유형과 템플릿 대체품에도 적용되기 때문이다. UML 2.0의 템플릿 메커니즘은 분류자, 연산, 패키지로 제한되었다. 처음 두 가지는 대중적인 프로그래밍 언어에 있는 템플릿 메커니즘 뒤에 모델링 된다.

컴포넌트 기반 디자인에서, UML 1은 혼란스러운 개념이 많았다. 클래스, 컴포넌트, 하위시스템을 사용할 수 있었다. 이러한 개념들은 분명하지 않은 부분에서는 미묘하게 달랐다. 주어진 상황에서 어떤 것을 사용할 지에 대한 명확한 선이 없었다. 하위시스템(subsystem)이 그저 "큰 " 컴포넌트인가? 그렇다면 하위시스템이 되기 전에 컴포넌트 크기는 어느 정도가 되어야 하나? 클래스는 캡슐화를 제공했고 인터페이스를 만들었지만 컴포넌트와 하위시스템도 마찬가지였다.

UML 2.0에서 이 모든 개념들이 정비되어 컴포넌트들은 일반적인 클래스의 특별한 경우로서 정의되었다. 하위시스템들도 컴포넌트 개념 중에 단지 특별한 경우이다. 이들간 본질적인 차이점이 명확하게 구분되어 특정 목적에 맞춰 어떤 개념을 사용할 것인지를 결정할 수 있다.

의미와 표기법 스팩도 강화되었다. 각 메타클래스 스팩에는 의미상의 변이 포인트, 표기법 옵션, UML 1 스팩과의 관계 등을 분명히 정의한 정보들이 갖춰져 있다. 마지막으로 용어도 일관성 있게 정의되어 기존 용어(유형, 인스턴스, 스팩, 발생)가 모든 컨텍스트에서 일반적은 의미를 지니게 되었다.

위로

요약

UML 2.0은 모델 중심의 방식을 위해 존재한다. 스케치 툴로서 사용하고자 하는 사람들도 UML 1 처럼 비공식적으로 사용할 수 있다. 언어의 룩앤필도 별로 변경되지 않았다.

하지만 MDD에서는 이제 표준화 방식으로 사용할 수 있다. UML 2.0은 정확성이 향상되었다. 완전히 자동화된 코드 생성 기능을 사용할 수 있다.

언어 구조는 모듈식과 점진적은 방식으로 채택하도록 구성되었다. 관심 있는 언어의 일부를 공부하고 나머지는 무시해도 된다. 경험과 지식이 늘어날수록 새로운 기능을 선택적으로 사용할 수 있다. 순응성 정의도 상당히 간단해져서 보조 툴들간 상호운용성과 다양한 벤더들의 툴들간 상호 운용성이 향상되었다.

새롭게 추가된 부분은 얼마 안된다. (언어가 팽창되는 것을 방지하기 위해서이다.) 그리고 이 모든 것들은 실제로 매우 크고 복잡한 시스템을 모델링 할 수 있는 반복 원리에 따라 디자인되었다. 특히, 소프트웨어 아키텍쳐, 복잡한 시스템 인터랙션, 플로우 기반 모델이 확장되어 비즈니스 프로세스 모델링과 시스템 엔지니어링 같은 애플리케이션에 이상적으로 쓰이도록 변모하였다.

언어 확장 메커니즘도 단순하게 재구성되었다. UML에 기반하여 도메인 스팩의 언어들을 정의할 때 보다 직접적인 방식을 사용할 수 있다. 이러한 언어들은 UML 툴과 전문성을 활용할 수 있다는 장점이 있다.

전체적으로 볼 때, 고급의 소프트웨어 시스템을 보다 빠르고 신뢰성 있게 구현할 수 있는 차세대 모델링 언어가 되었다. 중요한 것은, 개별 컴포넌트들이 큰 규모에 통합될 때 하드웨어 디자인에서 발생하는 단계들과 견줄 수 있는 고급 레벨의 프로그램 디자인이란 점이다.

위로

참고자료

• [BPEL03] BEA, et al., Business Process Execution Language for Web Services (Version 1.1), 5 May 2003, 2003
  
  
• [Brooks95] Brooks Jr., F., The Mythical Man-Month (1995 edition), Addison-Wesley, 1995.
  
  
• [Brown04] Brown, A., An Introduction to Model Driven Architecture, IBM Rational Developer Works, 2004.
  
  
• [Fowler04] Fowler, M., UML Distilled (3rd edition), Addison-Wesley, 2004.
  
  
• [GMW97] Garlan, D., Monroe, R., and Wile, D., Acme: an architecture description interchange language, in Proceedings of the 1997 Conference of the Centre for Advanced Studies on Collaborative Research, Association For Computing Machinery (ACM), 1997.
  
  
• [Graham01] Graham, I., Object-Oriented Methods: Principles and Practice (3rd edition), Addison-Wesley, 2001
  
  
• [ITU00] International Telecommunications Union, ITU Recommendation Z.109: SDL Combined with UML, ITU-T, 2000.
  
  
• [ITU02] International Telecommunications Union, ITU Recommendation Z.100: Specification and Description Language (SDL), (08/02), ITU-T, 2002.
  
  
• [ITU04] International Telecommunications Union, ITU Recommendation Z.120: Message Sequence Chart (MSC), (04/04), ITU-T, 2004.
  
  
• [ITU05] International Telecommunications Union, Study Group 17: Question 13/17 -- System Design Languages Framework and Unified Modelling Language, ITU-T Study Group 17, 2003.
  
  
• [Lee92] Lee, L. The Day the Phones Stopped Ringing, Plume Publishing, 1992.
  
  
• [Booch04] Booch, G., et al., An MDA Manifesto, in Frankel, D., and Parodi, J. (eds.), The MDA Journal, Meghan-Kiffer Press, 2004.
  
  
• [OMG03a] Object Management Group, Unified Modeling Language (UML), Version 1.5, OMG document formal/03-03-01, 2003.
  
  
• [OMG03b] Object Management Group, UML 2.0 Diagram Interchange, Final Adopted Specification, OMG document ptc/03-09-01, 2004.
  
  
• [OMG04] Object Management Group, UML 2.0 Superstructure, Available Specification, OMG document ptc/04-10-02, 2004.
  
  
• [RJB05] Rumbaugh, J., Jacobson, I., and Booch, G., The Unified Modeling Language Reference Manual (2nd edition), Addison-Wesley, 2005.
  
  
• [Stevens02] Stevens, P., On the interpretation of binary associations in the Unified Modeling Language, Journal of Software and Systems Modeling, vol.1, no.1, Springer-Verlag, September 2002.
  
  
• [Selic04] Selic, B., On the Semantic Foundations of Standard UML 2.0, in Bernardo, M., and Corradini, F. (eds.), Formal Methods for the Design of Real-Time Systems, Lecture Notes in Computer Science vol. 3185, Springer-Verlag, 2004.
  
  
• [SR98] Selic, B. and Rumbaugh, J. Using UML for Modeling Complex Real-Time Systems. Unpublished white paper, Apr. 4, 1998,
  
  
• Rational Application Developer, Rational Software Architect Trials and betas page.
  
  
• IBM Software Developer Platform homepage
  
  
• developerWorks Rational content area.
  
  
• IBM Rational marketing pages.
  
  
• developerWorks blogs.
  
  
• Rational Software Architect, Software Modeler, Application Developer and Web Developer forum.
  
  
• Browse for books

2004.08.23 (2004-34호)

UML(Unified Modeling Language)은 소프트웨어 시스템에 대한 산출물을 가시화(visualizing), 정의(specifying), 구축(constructing) 그리고 문서화(documenting) 하기 위한 일종의 그래픽적인 표기법을 사용하는 언어이다.

UML의 변천사
UML은 원래 Booch, OMT(Object Modeling Technique)와 OOSE(Object-Oriented Software Engineering)에 의해 객체 모델링 언어로부터 파생되었다. OMG(Object Management Group Inc.)에서 1997년에 UML(Unified Modeling Language)를 처음 표준으로 채택한 이후, UML은 학계와 산업 등 여러 영역에서 상당히 폭넓게 채용되어 사용되며 성공적으로 자리잡았다. UML은 1997년에1.1 버전의 발표를 시작으로 1998년에 버전 1.3, 2000년에 버전 1.4를 발표하는 과정에서 그동안 제기되었던 UML 메타모델의 내부 문제를 해결했고, 모호한 표현을 좀 더 명확하게 하고, 명명의 일관성도 증진시켰다. UML 1.0부터 UML 2.0까지의 변화는 다음 그림과 같다.

UML 2.0 스펙
UML은 소프트웨어 시스템의 아키텍처를 묘사하기 위한 사실상의 표준 언어로써 많은 소프트웨어 개발자들이 사용하게 되었다. UML 덕분에 컴포넌트 아키텍처와 다양한 방법론들이 더불어 발전하게 되었으며, 이에 따라 소프트웨어 개발 방법론에서도 특정 경향이 나타났는데, UP(Unified Process)나 XP(eXtreme Programming)가 바로 그것이다. 또한 비주얼 모델링과 비주얼 프로그래밍 기술이 합쳐지는 추세를 보이는데, 이러한 추세를 기반으로 OMG에서는 UML 2.0에 다음과 같은 네 가지 스펙을 발표하였다.

• 기초적인 구성요소(Construct)를 재구성하고, 특화(Customizability)를 개선하기 위한 것과 관련된 내부구조(Infrastructure)
• 컴포넌트(Component), 활동(Activity), 상호작용(Interaction) 등과 같은 응용 구성요소(construct)를 개선하기 위한 상위구조(Superstructure)
• 기존 UML OCL(Object Constraint Language)의 정확성과 표현력을 개선하기 위한 것과 관련되는 OCL
• 다양한 툴들 사이의 모델 다이어그램을 교환할 수 있도록 하는 다이아그램 호환(Interchange)

주요 개선사항
UML 1.x 의 문제로 지적된 것은 크기가 너무 크고, 복잡하며, 또한 의미론(Semantics)이 모호하며, 구현과 관련된 부분이 충분하지 못해서 특화(Customizing)가 제한되어 있다는 것이다. 이 외에도 컴포넌트 기반의 개발방법을 제대로 지원하기 어렵고, 모델 다이어그램을 교환하기 위한 수단이 없다는 것도 또다른 문제점으로 나타났다. UML 2.0은 이런 문제가 많던 UML 1.x 전체에 대해 많은 개선을 했고, 주요한 변화사항은 다음과 같다.

• 구조의 순환적 분해와 컴포넌트 기반 개발방법에 대한 지원이다. UML 2.0은 복합 구조(Composite Structure) 다이아그램과 같은 새로운 주요 다이어그램들을 도입했고 시스템, 서브 시스템, 컴포넌트, 하위 컴포넌트 등 순환적인 분해를 할 수 있게 해주는 파트(Part), 포트(Port) 그리고 커넥터(Connector) 같은 새로운 구성요소들을 포함시켰다.
• UML 2.0은 활동(Behavior)들을 하위 활동들로 순환적 분해를 할 수 있도록 행위 다이아그램(Activity Diagram)과 순차 다이아그램(Sequence Diagram)을 확장시켰다. 예를 들자면, 액션 노드(Action Node)들을 하위 액션 노드들, 하위-하위 액션 노드들 등으로 분해할 수 있다.
• 구조적 모델과 행위적 모델 사이의 통합을 개선했다. 즉, 구조 다이아그램과 행위 다이아그램들을 문제없이 통합할 수 있도록 해준다. 예로, 자동차 엔진에 대한 복합 구조 다이아그램 내의 연료 공급 장치 부분은 선박 운행 시스템에 대한 행위 다이아그램 내에서의 동일한 부분에 대해 사용될 수 있다는 것이다.
• 실행 가능한 모델에 대한 지원이 또한 새롭게 UML 2.0에 추가된 사항이다. UML 2.0은 시뮬레이션과 프로그래밍 코드를 실행할 수 있는 실행 가능한 모델을 지원하는 통합된 행위적 의미(Action Semantics)를 완벽하게 포함하고 있다.

물론 이러한 새로운 부분들로 인해 언어의 크기가 커지는 것은 사실이다. 하지만 UML 2.0에서는 각각이 독립적인 여러 서브언어의 집합으로 모듈화 되어 있다. 따라서 특정 국가의 언어를 말하기 위해서 해당 언어 모두를 다 알고 있지 않아도 되는 것처럼 UML 2.0의 사용자는 자신의 문제를 해결하기 위한 부분만 단지 선택해서 사용할 수 있다.
어떤 점에서는, UML 2.0이 단지 추상화와 자동화의 레벨을 증가시킴에 따라, 그리고 3세대 프로그래밍 언어라 불리는 것에 의해 도입된 성공적인 기술의 패턴을 반복하고 있다. 따라서 UML 2.0은 지난 40여 년간 수렁에 빠진 상태였던 프로그래밍 언어의 올가미로부터 우리를 해방시킬 것을 약속할 수 있을 것이다.