UML

UML 소개
Visual Modeling with Rational Rose 2002 and UML

들어가며

UML은 소프트웨어를 보는 여러 관점들을 기술하기 위한 표현언어(Notation)입니다. 소프트웨어를 개발하는 당사자는 프로그래머 혹은 개발자이지만, 소프트웨어 개발에 참여하는 관련자들은 개발자 외에도 많은 사람들이 있습니다. 또한, 이들 사람들은 각자의 관심사가 다르므로, 소프트웨어를 생각하는 방법도 다릅니다.
따라서, 이러한 다양한 관점들을 여러 다이어그램 형태로 표현할 수 있도록 제안된 표준언어가 UML입니다.


1. UML의 역사

UML이 표준 언어로 정해지기 전에 많은 소프트웨어 기술 방법과 개발 방법론이 있었습니다.

대표적인 것으로는 OMT (Object Modeling Technique), Booch 메소드, OOSE(Object Oriented Software Engineering) 등이 있었습니다. 이 당시에는 기술 언어보다는 소프트웨어를 개발할 때 어떤 것들을 고려해야 하고 어떤 일들을 수행해야 하는지를 정리한 개발 방법론이 중요했습니다. 따라서, 기술 언어는 개발 방법론을 만든 사람들이 필요에 따라 정의하고 사용하였습니다.

이러한 다양한 개발방법론은 각각 고유의 장점들을 가지고 있었습니다. 예를 들어, OMT는 분석 단계에서 풍부한 가이드라인을 제시하고 있었고, Booch 메소드는 객체 지향 설계에 대한 많은 적용 사례와 내용을 가지고 있었습니다. 이러한 이유로 개발방법 론을 하나의 표준으로 정할 순 없습니다.

하지만, 문제는 하나의 개발방법론에서 사용하는 언어요소가 다른 개발방법론에서는 다르게 사용되는 경우가 생겼고, 이는 많은 소프트웨어 관계자들에게 혼동을 가져다 주었고 이로 인해 언어를 통일하자는 분위기가 만들어졌습니다.

 

소프트웨어 개발 업체들은 소프트웨어 개발 언어의 표준을 정의하기 위한 컨소시엄을 만들고 OMG (Object Management Group)에 표준안을 제안하였고, 이러한 제안들이 Unified Method 0.8(1994), UML 0.9(1996), UML 1.0(1997), UML 1.1을 거쳐 현재 사용되는 버전인 UML 1.4까지 발전하였습니다. OMG는 UML 2.0에 대한 RFP (Reques For Proposal)를 제안하여 여러 연구기관 및 조직에서 제안서를 받아 조만간 UML 2.0이 발표될 예정입니다.
 

2. UML의 구성

UML언어의 구성은 크게 모데링 요소, 요소들 간의 관계, 그리고 다이어그램으로 분류할 수 있습니다.

여기에서 모델은 실 세계의 사물이나 개념을 바라보는 사람의 관심사에 따라 중요한 부분을 기술하고 사소한 부분을 생략하는 추상화를 거쳐 만들어 지는 형상입니다.

소프트웨어의 모든 부분을 단일한 모델링 요소로 표현할 수 없고 그러할 필요도 없습니다.
UML에서는 기본적인 모델링 관점을 제시하고 이 외의 부분에 대해서는 UML 요소를 확장할 수 있는 메커니즘을 제공하고 있습니다.

 

3. 모델링 요소

모델링 요소에는 크게 구조 요소, 행위 요소, 조직화 요소로 나눌 수 있습니다.

· '구조 요소'란 프로그램 언어에서 흔히 사용되는 클래스, 인터페이스, 파일 혹은 컴퓨터처럼 하나의 단위를 구성하는 것을 말합니다.
- UML에서는 파일은 컴포넌트에 해당하고, 컴퓨터는 노드에 해당합니다.

· '행위 요소'란 구조요소들 간의 상호작용이나 구조요소 자체의 행위를 기술하는 단위입니다. 프로그램에서 어떤 이벤트가 발생하였을 때 여러 구조 요소들이 협동하여 이를 처리하는 것을 표현하기 위해서는 구조 요소들간의 상호작동을 표현해야 합니다. 또한, 어떤 클래스가 상태에 따라 다른 행동을 하는 경우, 이러한 상태를 자세히 기술할 필요가 있습니다.
- UML 에서는 상호작동 다이어그램(Interaction Diagram),
상태 다이어그램(State Diagram)에 포함된 요소들을 행위 요소라고 할 수 있습니다. 예를 들어, 이벤트, 시그널, 상태 등의 요소가 있습니다.

· '조직화 요소'는 모델링 요소들을 하나의 단일한 단위로 그룹화하기 위해 사용됩니다. 예를 들어 자바언어에서 패키지는 여러 클래스들을 하나로 묶는 단위가 됩니다.
- UML에서는 패키지를 일반적인 그룹화 단위로 사용합니다.

· 앞에 소개한 세 요소 외에 UML에서는 노트와 같은 기타 요소들을 제공하고 있습니다. 노트는 모델링을 수행하는 사람이 자신의 생각을 표현할 마땅한 요소가 없는 경우 코멘트처럼 자유롭게 기술하려고 할 때 사용됩니다.
 

다음은 구조요소의 예입니다.

· 클래스: 동일한 속성, 오퍼레이션, 관계를 가지는 객체들의 집합
· 인터페이스: 클래스나 컴포넌트가 제공하는 오퍼레이션들의 모음

위 다이어그램에서는 Shape 클래스와 ISpellChecker 인터페이스를 보여주고 있습니다.

· Shape 클래스
- 가시성(Visibility)은 클래스의 외부에서 이 클래스에 대한 접근 가능 권한을 보여주고 있습니다. (+ : public, - : private, # : protected)
- 클래스는 이름, 속성, 오퍼레이션 세 부분으로 표현됩니다.
- invalidateRegion 오퍼레이션은 그릴 필요가 있는 영역만을 다시 그리기 위해 display가 사용하거나 다른 자식 클래스에서 사용될 수 있습니다.

· ISpellChecker 인터페이스
- ISpellChecker 인터페이스는 각 오퍼레이션의 구현은 없고 선언 만 있어서 다른 클래스가 이 인터페이스를 상속하여 구현합니다. 따라서 인터페이스 클래스는 오퍼레이션을 사용하려는 클라이언트와 인터페이스를 구현하는 클래스 간의 약속을 표현할 수 있습니다.
- lookupWord 메소드는 특정 스펠링을 체크하기 위해 필요한 오퍼레이션



4. 요소들 간의 관계

관계에는 의존(Dependency), 연관(Association), 일반화(Generalization)와 실현 (Realization)이 있습니다.
 

다음은 이들 관계의 예를 보여주고 있습니다.

· Window 클래스는 Event 클래스로의 의존관계를 가지는 데, 이 관계는 handleEvent 오퍼레이션을 수행할 때 Event 객체를 인자로 받아서 처리하기 때문에 Window 클래스는 Event 클래스가 잘 구현되어 있어야만 완전해집니다.

· 반면, DialogBox 클래스에서 생성되는 객체는 확인 버튼 및 취소 버튼을 가지고 있어야 하기 때문에 자신이 생성될 때 이 들 버튼도 함께 생성해야만 합니다. 이렇게 객체의 라이프 사이클(생성에서 소멸)을 거쳐 관계를 가져야 할 때 우리는 객체간의 구조적 관계라고 합니다. 반면 위의 Event 객체를 통한 의존 관계는 handleEvent 메소드의 수행이 끝나면 없어지므로 구조적 관계가 아닙니다.

· ConsoleWindow와 DialogBox는 일종의 Window(IsA 관계)로 display와 handleEvent 오퍼레이션을 상속 받게 됩니다. ConsoleWindow는 Window이므로 Window가 할 수 있는 모든 일을 상속받아 자신도 그러한 일을 할 수 있습니다. IsA 관계는 ConsoleWindow Is A Window.로 부터 도출된 용어입니다.
 

5. 다이어그램들

· UML이 제공하는 각 다이어그램은 특정 관계자의 시각으로 표현된 소프트웨어의 부분 명세를 표현합니다. 참고로, 소프트웨어를 개발하는 데 관련된 사람에는 개발자, 고객, 시스템 분석가, 도메인 전문가, 프로젝트 팀장, 재정 담당자, 품질 관리자, 테스팅 담당자 등 여러 역할에 해당하는 사람이 있다.

· UML에는 총 9개의 다이어그램이 제공되고 있습니다. 크게 정적 관점과 동적 관점에서 나누어 보면 다음과 같습니다.

▶ 정적 관점
- Use case 다이어그램
- 클래스 다이어그램
- 객체 다이어그램
- 컴포넌트 다이어그램
- 배치(deployment) 다이어그램

▶ 동적 관점
- 시퀀스(sequence) 다이어그램
- 콜레보레이션(collaboration) 다이어그램
- 상태차트 다이어그램
- 활동(activity) 다이어그램


6. Use Case다이어그램

· 시스템의 구현 기능을 사용자 관점에서 표현합니다.
· 사용자에 의해 보여지는 시스템의 기능들을 표현하고, 개발 초기에 작성됩니다.
· 목적
- 소프트웨어가 구현해야 하는 범위 혹은 컨텍스트를 표현하고 있습니다 (시스템 경계).
- 시스템에 대한 요구사항들을 표현
- 소프트웨어 구현에 대한 기반이 되며 테스트 케이스 즉, 소프트웨어가 구현 완료되었을 때 어떤 테스트들을 통과해야 하는 지를 기술하는 데 사용될 수 있습니다.
· 시스템 분석가들과 도메인 전문가들에 의해 작성됨

 

위 다이어그램에서는 크게 타원으로 표현된 유스케이스와 사람 모양의 아이콘인 액터를 통해 소프트웨어가 구현해야 하는 기능과 어떤 외부 요소와 연관되는 지를 표현하고 있습니다.
예를 들어, 카드 결제 처리하기 유스케이스는 고객과 유통 기관으로부터 카드 사용에 대한 정보를 얻어서 처리하는 신용카드 관리 시스템의 주 기능입니다. 시스템 경계는 소프트웨어가 구현해야 하는 기능의 경계를 보여주며, 소프트웨어 외부에서 구현하는 기능은 액터로 표현됩니다.


7. 클래스 다이어그램

· 시스템의 Vocabulary를 표현하고, 시스템을 구성하는 클래스와 클래스간의 관계를 표현
· 소프트웨어를 구현하기 위한 기반 모델로 사용되고 개발을 거치면서 상세화됩니다. 이상적인 경우에는 이 클래스 다이어그램과 프로그램 소스 코드가 일치하게 됩니다.
· 목적
- 시스템 상의 개념들에 대해 이름을 부여하고 이에 기반하여 모델을 작성하기 위해 사용됩니다.
- 논리적 DB 스키마를 기술하기 위해 ER 다이어그램 대신에 사용될 수 있습니다. 시스템 분석가, 설계자, 구현자들에 의해 작성됨
· 위 클래스 다이어그램은 특정 회사의 조직 구성과 인적 정보에 대한 다이어그램을 보여주고 있습니다. 회사의 사무를 다루는 여러 소프트웨어들이 위와 같은 클래스 및 관계를 필요로 할 수 있습니다.

사각형으로 클래스가 기술되고 이들 간의 구조적인 관계를 연관 혹은 상속 관계로 표현되고 있고, 일시적 관계를 통해 맺어지는 의존 관계가 표현되어 있습니다.
· 클래스간의 구조적인 관계는 실제 클래스로부터 객체가 만들어져서 프로그램 수행이 될 때, 객체의 라이프 사이클을 거쳐 몇 개의 다른 객체와 관계가 맺어지는 지를 표현하기 위해 다중성(Multiplicity)를 사용합니다. 이는 연관 관계의 양쪽 끝에 0, 1, * 등으로 표현되어 있습니다.
· Department 클래스 입장에서 살펴보면, 하나의 Department 객체는 Company 객체 하나와 연관을 맺고 있습니다. 반대로, Company 객체 하나는 하나에서 n개의 Department 객체를 가지고 있습니다.


8. 객체 다이어그램

· 객체들과 이 들간의 링크를 보여주고, 분석 및 설계 과정에서 작성됨
· 목적
- 데이터 및 객체 구조를 보여줌
- 시스템 수행 중 특정 시점에서의 스냅샷(객체간의 연결 관계)을 보여줌
· 시스템 분석가, 설계자, 구현자에 의해 작성됨
· 참고로 클래스는 객체가 만들어지는 틀입니다. 따라서 동일 클래스에서 생성된 모든 객체들은 동일한 구조를 가지게 됩니다. 하지만, 객체들은 프로그램 수행 중에 다른 값들을 가질 수 있습니다. 클래스 다이어그램은 수행 중인 객체들의 공통적인 구조를 표현하기 위해 사용되고, 객체 다이어그램은 수행의 특정 싯점에서의 객체가 가진 값들과 관계를 표현합니다. 링크는 수행 중에 만들어졌다가 다른 링크로 변경되거나 없어질 수 있습니다.

· 위 객체 다이어그램은 앞의 클래스 다이어그램을 만족하는 수행의 특정 시점에서의 객체 다이어그램입니다.
앞의 클래스 다이어그램에서 Company 객체는 하나 이상의 Department 객체를 가진다고 하였으며, 위 다이어그램에서는 하나의 회사가 영업부서와 연구개발부서를 가지고 있음을 보여주고 있습니다. 또한, Department 는 자신으로의 구조적인 관계를 가지고 있다고 하였으므로, 영업부서는 서울 영업소를 가지고 있습니다.
 

9. 컴포넌트 다이어그램

· 구현의 물리적 구조를 표현

· 아키텍처 명세의 일부로 작성됩니다. 소프트웨어 소스코드를 특정 부 시스템들로 나누고 이 부 시스템들의 계층 구조에 소스 코드 파일들을 분할시켜서 소프트웨어에 대한 큰 그림을 보여줄 수 있습니다.
· 목적
- 소스 코드(파일 또는 디렉토리)를 구조화
- 특정 버전의 각 소스 코드들을 묶어서 하나의 수행 릴리즈를 구성할 수 있습니다.
- 아키텍트와 프로그래머에 의해 작성

 

▪ 위 다이어그램은 소프트웨어 일부에 대한 컴포넌트 다이어그램을 보여주고 있습니다.
- index.html 이 웹 브라우저에 로드가 되었을 때, 사용자가 검색 페이지를 요청할 수 있습니다.
- 검색 페이지 상에서 검색어를 입력하고 검색을 수행하면, find.exe 가 수행됩니다.
- Find.exe가 수행될 때 데이터베이스를 사용하기 위한 라이브러리(dbaccess.dll)을 필요로합니다.

 

10. 배치(Deployment) 다이어그램

▪ 시스템의 하드웨어 토폴로지를 표현
▪ 아키텍처 명세의 일부로 작성합니다. 소프트웨어 개발 초기에 소프트웨어가 수행되기 위한 컴퓨팅 환경에 대한 큰 그림을 필요로 합니다.

 

▪ 목적
- 컴포넌트들의 분산 구조를 명세
- 성능 상의 병목 지점을 파악하기 위해 사용
▪ 아키텍트, 네트워크 전문가, 시스템 엔지니어에 의해 작성됨

▪ 위 다이어그램은 컴퓨팅 자원을 의미하는 노드들과 이들 간의 통신 경로를 보여주고 있습니다.
- 시스템이 인터넷과 연동하기 위한 네트워크 및 컴퓨팅 자원의 배치를 보여준다.

- 네트워크도 하나의 노드로 표현되며, 캐쉬서버는 인터넷으로부터 액세스한 파일들을 다시 가져오지 않도록 캐쉬해두기 위한 컴퓨터이다.

11. 시퀀스 다이어그램

▪ 동적 행위를 표현(시간 중심)
▪ 목적
- 제어 흐름을 모델링
- 시스템 수행의 전형적인 시나리오를 보여줌
▪ 소프트웨어의 모든 시나리오를 시퀀스 다이어그램으로 표현할 수는 없으며, 중요하고 관리되어야 하는 시나리오만을 다이어그램으로 작성하여야 합니다.

▪ 객체간의 메시지 전달 과정을 시간 순서대로 보여주는 다이어그램이다
- 점선화살표(committed)는 메소드 호출 후의 리턴 과정을 보여준다.
- 각 객체에 대해 수직 점선은 객체의 라이프 사이클(생성 후 소멸 시까지)을 보여주며, 점선 위의 수직 사각형은 현재 시퀀스 다이어그램이 보여주는 focus of control을 표현 한다.
- 객체를 생성하는 생성자 및 소멸시키는 소멸자는 스테레오 타입을 사용하여 create, destroy 메시지로 표현되어 있다.
- X 표시는 객체의 소멸 시점을 보여준다.


12. 협동(Collaboration) 다이어그램

▪ 동적 행위를 표현(메시지 중심)
▪ 목적
- 제어 흐름을 모델
- 객체 구조와 제어 흐름을 함께 보여줌
▪ 이 다이어그램은 시퀀스 다이어그램과 표현력(expressiveness)이 같고, 이 두 다이어그램을 상호작동(Interaction) 다이어그램이라고 합니다.

이전의 시퀀스 다이어그램과 동등한 협동(Collaboration) 다이어그램입니다. 내용은 같으나, 객체 간의 연결 관계 및 메시지 순서를 중심으로 보여주고 있습니다.


13. 상태 차트 다이어그램

▪ 동적 행위를 표현(이벤트 중심)
▪ 목적
- 객체의 생성에서 소멸까지의 라이프사이클을 모델링 합니다.
- 이벤트-반응이 중요한 객체를 모델링하기 위해 사용됩니다. (사용자 인터페이스, 장치 등)
▪ 상태 차트 다이어그램은 일반적으로 하나의 클래스에 대해 기술되어 집니다.

상태 차트 다이어그램은 한 객체의 행위를 이벤트에 대한 상태의 변경으로 설명하고 있습니다.
- 수행 시 객체의 각 속성에 대한 값들이 하나의 상태를 이루며, 상태 전이는 객체에 대해 오퍼레이션이 수행될 때 이루어진다.

▪ 위 다이어그램은 온도 조절기 클래스가 가지는 상태들과 상태들간의 전이를 보여준다.
- 객체가 생성되면 initial state 로 들어오며, 별도 오퍼레이션 수행 없이 Idle 상태로 전이된다
- Idle 상태에서 tooHot 또는 tooCool 이벤트가 발생하면( 또는 오퍼레이션이 수행되면) 각각 Cooling 상태, Heating 상태로 전이되며, shutDown 이벤트가 발생하면 final stated 로 전이한다.
- Heating 상태는 내부에 Activating 상태와 Active 상태를 포함하며, Heating 상태로 전이되면 바로 내부의 Initial 상태로 들어오며,   별도   이벤트   발생 없이  바로 Activating 상태로 전이된다.
 

14. 활동 다이어그램

· 동적 행위를 표현(활동 중심)
· 목적
- 비즈니스 워크플로우(일의 흐름)를 모델링 합니다.

· 위 다이어그램은 물품을 주문하고 이에 대한 지불이 이루어지는 일의 단계를 보여주고 있습니다.
- fork는 일이 두 개로 쪼개져서 병렬적으로 수행되는 것을 표현합니다. 반면에, join은 둘 이상의 일이 모두 완료되어 모이면 다음 작업을 개시하는 관계를 표현합니다.


[나가며]
지금까지 UML이 무엇이고 어떻게 발전되어 왔는지, 그리고, 어떤 구성요소들을 가지고 있는지를 간단하게 살펴보았습니다.
UML은 현재 많은 소프트웨어 개발 업체 및 소프트웨어 관련 조직들에서 표준으로 사용하고 있는 언어입니다.

현재까지는 소프트웨어 문서화의 용도로 많이 사용되고 있지만, 모델링 기술의 발전과 도구의 지원 등으로 개발자들이 소스 코드 대신에 모델을 통해 사고할 수 있는 방향으로 발전해나가고 있습니다.
본 강의에서 소개된 것은 UML이 무엇인 지에 대한 개념을 잡기 위해 매우 간략하게 기술되어 있습니다. 텀 프로젝트를 수행하는 과정에서 필요한 다이어그램 및 모델 요소들에 대해서 보다 자세하게 다룰 예정에 있습니다.

본 강의에서 참고한 자료 및 이 후 참고할 자료는 다음과 같습니다.
1) Terry Quatrani, Visual Modeling with Rational Rose 2002 and UML, Addison Wesley, 2003
2) Peter Eeles, Kelli Houstion, and Wojtek Kozaczynski,
Building J2EE Applications with the Rational Unified Process, Addison Wesley, 2003
3) Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley, 1999