20세기
말을
되돌아보며 --
정확히 1997년 Object Management Group (OMG)이 Unified Modeling Language (UML)을
발표했다. UML의
목표
중
하나는
개발
커뮤니티에
안정적이고, 일반적인
디자인
언어를
제공하는
것이었다. UML은 IT 전문가들이
수년
동안
바라던
통합된
표준
모델링
표기법을
탄생시켰다. UML을
사용하여 IT 전문가들은
시스템
구조와
디자인
계획을
읽고
분산시킬
수
있다. 건축가들이
빌딩의
청사진을
사용하는
것처럼
말이다.
이제 21세기가
되었고 UML은
전문성을
확립하게
되었다. 내가
보고
있는
이력서의 75 퍼센트
정도가 UML을
알고
있다고
쓰여있다. 하지만
면접을
통해
이야기를
해보면
이들이
진정으로 UML을
알지
못하고
있다는
것이
명확해진다. 일반적으로
당시
이슈가
되는
키워드
로서
알고
있거나
표면적인
면만
알고
있는
경우가
대부분이었다. 이것이
바로
내가
이
글을
쓴
이유이다. 이
글을
다
읽었다고
해서
이력서에 UML을
충분히
알고
있다고
쓸
수는
없겠지만, 이
언어를
보다
심도
깊게
연구할
출발선에는
설
정도는
된
것이다.
배경
지식
UML은
컴퓨터
애플리케이션을
모델링
할
수
있는
통합
언어이다. 주요
작성자들은 Jim Rumbaugh, Ivar Jacobson, Grady Booch이고
이들은
원래
그들만의
꽤
괜찮은
방식(OMT, OOSE, Booch)을
갖고
있었다. 결국
이들은
힘을
합쳤고
개방형
표준을
만들었다. (어디서
많이
들어본
소리인가? J2EE, SOAP, Linux도
비슷한
현상이다.) UML이 표준
모델링
언어가
된
한
가지
이유는
이것이
프로그래밍
언어에
독립적이라는데
있다. (IBM Rational의 UML 모델링
툴은 .NET 뿐만
아니라 J2EE에서도
사용된다.) 또한 UML 표기법
세트는
언어이지
방법론이
아니다. 언어인
것이
중요한
이유는
방법론과는
반대로
언어는
기업이
비즈니스를
수행하는
방식에
잘
맞는다.
UML은
방법론이
아니기
때문에 (IBM Rational Unified Process® lingo의 "객체(artifacts)" 같은) 어떤
형식적인
작업
생성물들이
필요
없다. 하지만
정해진
방법론
안에서
쓰이면, 애플리케이션을
개발할
때
애플리케이션을
쉽게
이해할
수
있도록
도와주는
여러
가지
유형의
다이어그램을
제공한다. 이
다이어그램은
현재
사용하고
있는
것의
언어와
원리를
잘
소개하고
있다. 사용중인
방법론에서
생긴
작업
생산품들에
표준 UML 다이어그램을
배치하여 UML에
능숙한
사람들이
프로젝트에
쉽게
참여하여
생산성을
높일
수
있도록
한다. 가장
유용한
표준 UML 다이어그램은
사용
케이스
다이어그램, 클래스
다이어그램, 시퀀스
다이어그램, 스테이트
차트
다이어그램, 액티비티
다이어그램, 컴포넌트
다이어그램, 전개
다이어그램
등이
있다.
각
유형의
다이어그램을
자세히
설명하지는
않겠다. 대신, 각
다이어그램에
대한
일반적인
개념을
소개하고
자세한
것은
나중에
다루도록
하겠다.
사용
케이스
다이어그램
사용
케이스는
시스템에서
제공한
기능
단위를
설명한다. 사용
케이스
다이어그램의
주요
목적은, 다른
사용
케이스들
간
관계
뿐만
아니라
주요
프로세스에
대한 "액터(actors)" (시스템과
인터랙팅하는
사람)들과의
관계를
포함하여, 개발
팀들이
시스템의
기능적
요구
사항들을
시각화
하는
데
있다. 사용
케이스
다이어그램은
사용
케이스
그룹들을
보여준다. 완전한
시스템에
대한
모든
사용
케이스이거나
관련된
기능을
가진
특정
사용
케이스
그룹(예를
들어, 보안
관리에
관련된
사용
케이스
그룹)의
사용
케이스일
수도
있다. 사용
케이스
다이어그램에
대한
사용
케이스를
보여주려면
다이어그램
중간에
타원을
그려서, 타원의
중앙
또는
아래에
사용
케이스
이름을
적어놓는다. 사용
케이스
다이어그램에
액터(시스템
사용자)를
그리려면
다이어그램의
왼쪽이나
오른쪽에
사람
모양을
그려
넣는다. (얼마나
예쁘게
그리는가는
여러분에게
달려있다.) 액터와
사용
케이스들간
관계는
그림 1에
나타나있다.
|
그림 1: 사용
케이스
다이어그램
|
사용
케이스
다이어그램은
시스템의
고급
기능과
시스템의
범위를
설명하는데
사용된다. 그림 1의
사용
케이스
다이어그램을
통해, 시스템이
제공하는
기능을
쉽게
표현할
수
있다. 이러한
시스템에서는
밴드
매니저가
밴드가
발매한 CD에
대한
판매
통계
리포트와 Billboard 200 보고서를
볼
수
있다. 또한
레코드
매니저는
특정 CD에
대한
판매
통계
보고서와 Billboard 200 보고서를
볼
수
있다. 이
다이어그램에서는 Billboard Reporting Service라고
하는
외부
시스템에서
우리
시스템이 Billboard 리포트를
전달하고
있다는
것도
볼
수
있다.
또한, 이
다이어그램에
사용
케이스가
없다는
것은
시스템이
수행하지
않은
일을
보여주고
있는
것이다. 예를
들어, 이
다이어그램은
밴드
매니저가 Billboard 200의
다른
앨범들에
수록된
노래를
듣는
방식은
나와있지
않다. Billboard 200에서 Listen to Songs 라는
사용
케이스에
대한
어떤
레퍼런스도
볼
수
없다. 이것은
중요한
포인트이다. 그와
같은
다이어그램에
제공된
명확하고
간단한
사용
케이스
설명을
통해
프로젝트
스폰서는
시스템에
필요한
기능이
존재하는지
여부를
쉽게
볼
수
있는
것이다.
클래스
다이어그램
클래스
다이어그램은
다른
엔터티들(사람, 제품, 데이터)이
서로
어떻게
관계를
맺고
있는지를
보여준다. 다시
말해서, 이것은
시스템의
정적
구조라고
할
수
있다. 클래스
다이어그램은
록밴드, 씨디, 라디오
연주를
논리적
클래스로
나타내는데
사용될
수
있다. 또는
대출, 주택
저당
대출, 자동차
대출, 이자율을
나타내는데도
쓰일
수
있겠다. 클래스
다이어그램은
주로
프로그래머들이
다루는
구현
클래스들을
보여주는데
쓰인다. 구현
클래스
다이어그램은
논리적
클래스
다이어그램과
같은
클래스를
보여준다. 하지만
이
구현
클래스
다이어그램은
같은
애트리뷰트로는
그릴
수
없다. Vectors와 HashMaps 같은
것에
대한
레퍼런스를
갖고
있기
때문이다.
그림 2에서는
세
개의
섹션으로
클래스
다이어그램을
설명하고
있다. 위
섹션은
클래스의
이름을, 중간
섹션은
클래스의
애트리뷰트를, 가장
아래
섹션은
클래스의
연산("그림 2에서는
세
개의
섹션으로
클래스
다이어그램을
설명하고
있다. 위
섹션은
클래스의
이름을, 중간
섹션은
클래스의
애트리뷰트를, 가장
아래
섹션은
클래스의
연산 ("메소드")을
보여주고
있다.
|
그림 2: 클래스
다이어그램의
클래스
객체
|
내
경험으로는
거의
모든
개발자들은
이
다이어그램이
무엇을
하고
있는지를
안다. 하지만
대부분의
프로그래머들은
관계도를
잘못
그리고
있다. 그림 3과
같은
클래스
다이어그램의
경우
상속
관계주 1를
그릴
때에는
화살표
방향을
위로
향하게
하여
수퍼
클래스를
지시하게
하면서
화살표
모양은 완벽한
삼각형이
되도록
해야
한다. 상관
관계는
두
클래스들이
서로를
인식하고
있다면
일직선이
되어야
하고, 클래스의
한
편만
알고
있는
관계라면
화살표
표시가
되어있는
선을
그어야
한다.
|
그림 3: 그림 2의
클래스
객체가
포함된
클래스
다이어그램
|
그림 3에서, 상속
관계와
두
개의
상관
관계를
보았다. CDSalesReport 클래스는 Report 클래스에서
상속을
받고, CDSalesReport는
한
개의 CD와
관련이
되어
있지만, CD 클래스는 CDSalesReport에
대해
아무것도
모르고
있다. CD와 Band 클래스는
서로에
대해
알고
있고, 두
클래스는
서로
연관되어
있다.
클래스
다이어그램에는
이
보다
더
많은
개념들을
적용할
수
있다. 나중에
설명하도록
하겠다.
시퀀스
다이어그램
시퀀스
다이어그램은
특정
사용
케이스에
대한
상세한
흐름이나
심지어는
특정
사용
케이스의
일부분
까지도
보여준다. 대부분이
설명을
포함하고
있다. 시퀀스에서
다른
객체들
간의
호출관계를
보여주고
있고, 다른
객체들로의
다른
호출까지
상세하게
보여줄
수
있다.
시퀀스
다이어그램은 2차원으로
그려진다. 수직
차원은
발생
시간
순서로
메시지/호출
시퀀스를
보여주고
있다. 수평
차원은
메시지가
전송되는
객체
인스턴스를
나타내고
있다.
시퀀스
다이어그램은
그리기가
매우
간단하다. 다이어그램의
상단에
각
클래스
인스턴스를
박스
안에
놓아
클래스
인스턴스(객체)를
구분한다. (그림 4) 박스
안에
클래스
인스턴스
이름과
클래스
이름을
스페이스/콜론/스페이스 " : "로
분리시킨다. (예, myReportGenerator : ReportGenerator) 클래스
인스턴스가
메시지를
또
다른
클래스
인스턴스로
보내면
클래스
인스턴스를
받는
곳을
가리키는
화살표를
긋는다. 그
라인
위에
메시지/메소드
이름을
적는다. 중요한
메시지의
경우는
원래의
클래스
인스턴스를
다시
향하도록
점선
화살표를
그릴
수
있다. 점선
위에
리턴
값을
라벨링한다. 개인적으로는
리턴
값을
포함하곤
하는데
상세한
부분을
읽기
쉽기
때문이다.
시퀀스
다이어그램을
읽기는
매우
간단하다. 시퀀스를
시작하는 "드라이버(driver)" 클래스
인스턴스가
있는
왼쪽
상단
코너부터
시작한다. 그런
다음, 다이어그램
아래쪽을
각
메시지를
따라간다. 그림 4의
시퀀스
다이어그램
예제에서
전송
메시지에
대한
리턴
메시지는
선택적인
것임을
기억하라.
|
그림 4: 시퀀스
다이어그램
|
그림 4의
시퀀스
다이어그램을
읽다
보면 CD Sales Report가
어떻게
만들어지는지를
알
수
있다. aServlet 객체가
우리의
드라이버
예제이다. aServlet은
메시지를 gen이라고
하는 ReportGenerator 클래스
인스턴스로
보낸다. 이
메시지는 generateCDSalesReport 라는
라벨링이
붙는다. ReportGenerator 객체가
이
메시지
핸들러를
구현한다는
의미이다. 자세히
보면, generateCDSalesReport 메시지
라벨은
괄호
안에 cdId가
있다. gen 인스턴스가 generateCDSalesReport 메시지를
받으면 CDSalesReport로
연속
호출을
하고 aCDReport 라고
하는 CDSalesReport의
실제
인스턴스가
리턴
된다. gen 인스턴스는
리턴된 aCDReport 인스턴스에
호출하면서
여기에
각
메시지
호출에
대한
매개변수를
전달한다. 시퀀스의
끝에서 gen 인스턴스는
콜러였던 aServlet에 aCDReport를
리턴한다.
그림 4의
시퀀스
다이어그램은
전형적인
시퀀스
다이어그램을
상세히
설명한
것이다. 하지만
충분히
이해할
수
있을
것이다. 또한
초보
개발자들에게는
각
레벨
마다
시퀀스를
끊어서
이해하는
것도
좋은
방법이다.
스테이트
차트
다이어그램
스테이트
차트
다이어그램은
클래스가
개입된
다양한
상태(state)를
모델링
하고
그
클래스가
상태간
어떻게
이동하는지를
모델링
한다. 모든
클래스는
상태를
갖고
있지만
각각의
클래스가
스테이트
차트
다이어그램을
가질
수
없다. "중요한" 상태, 말하자면
시스템
작동
중
세
개
이상의
잠재적
상태가
있는
클래스일
경우만
모델링
되어야
한다.
그림 5에서
보듯, 스테이트챠트
다이어그램에는
다섯
개의
기본
엘리먼트들이
사용된다. 시작점(짙은
원), 스테이트
간
이동(화살표), 스테이트(모서리가
둥근
직사각형), 결정
포인트(속이
비어있는
원), 한
개
이상의
종료점(원
내부에
짙은
원이
그려져
있음)이
바로
그것이다. 스테이트챠트
다이어그램을
그리려면
시작점과
클래스의
초기
상태를
향하는
화살표로
시작한다. 다이어그램
어디에나
이
스테이트를
그릴
수
있고
스테이트
이동
라인을
사용하여
연결한다.
|
그림 5:시스템
작동
중
클래스가
실행되는
다양한
상태를
보여주는
스테이트
차트
다이어그램
|
그림 5의
스테이트
차트
다이어그램은
중요한
정보를
보여주고
있다. 예를
들어, 대출
프로세스가 Loan Application 상태에서
출발한다고
말할
수
있다. 결과에
따라
사전
승인
프로세스가
완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로
옮겨간다. 이동하는
동안
내린
결정은
결정
포인트로
보여진다. 이동
라인
상의
비어있는
원이
바로
그것이다. 이
예제를
보면 Loan Closing 상태를
거치지
않고는
대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로
갈
수
없음을
알
수
있다. 또한, 모든
대출이 Loan Rejected 상태
또는 Loan in Maintenance 상태에서
끝난다는
것도
알
수
있다.
액티비티
다이어그램
액티비티
다이어그램은
액티비티를
처리하는
동안
두
개
이상의
클래스
객체들
간
제어
흐름을
보여준다. 액티비티
다이어그램은
비즈니스
단위
레벨에서
상위
레벨의
비즈니스
프로세스를
모델링
하거나
저수준
내부
클래스
액션을
모델링
하는데
사용된다. 내가
경험한
바로는
액티비티
다이어그램은
기업이
현재
어떻게
비즈니스를
수행하는지, 또는
어떤
것이
비즈니스에
어떤
작용을
하는지
등의
고차원
프로세스를
모델링
할
때
가장
적합하다. 액티비티
다이어그램은
언뜻
보기에
시퀀스
다이어그램
보다는
덜
기술적이기
때문에
비즈니스
마인드를
가진
사람들이
빠르게
이해할
수
있다.
액티비티
다이어그램의
표기법은
스테이트
차트
다이어그램과
비슷하다. 스테이트
차트
다이어그램과
마찬가지로
액티비티
다이어그램은
초기
액티비티에
연결된
실선으로
된
원에서
시작한다. 이
액티비티는
모서리가
둥근
직사각형을
그려
그
안에
액티비티
이름을
적어
넣으면서
모델링
된다. 액티비티들은
이동
라인을
통해
다른
액티비티들에
연결되거나
결정
포인트의
조건에
제약을
받는
다른
액티비티들에
연결하는
결정
포인트로
연결될
수
있다. 모델링
된
프로세스를
종료하는
액티비티는 (스테이트
차트
다이어그램에서처럼) 종료
포인트에
연결된다. 이
액티비티들은
수영
레인으로
그룹핑
될
수
있다. 이것은
실제로
액티비티를
수행하는
객체를
나타내는데
사용된다. (그림 6)
|
그림 6: 두
개의
객체(밴드
매니저와
리포팅
툴)에
의한
액티비티
제어를
나타내는
두
개의
수영
레인으로
되어있다.
|
그림 5의
스테이트
차트
다이어그램은
중요한
정보를
보여주고
있다. 예를
들어, 대출
프로세스가 Loan Application 상태에서
출발한다고
말할
수
있다. 결과에
따라
사전
승인
프로세스가
완료되면 Loan Pre-approved 상태나 Loan Rejected 상태로
옮겨간다. 이동하는
동안
내린
결정은
결정
포인트로
보여진다. 이동
라인
상의
비어있는
원이
바로
그것이다. 이
예제를
보면 Loan Closing 상태를
거치지
않고는
대출이 Loan Pre-Approved 상태에서 Loan in Maintenance 상태로
갈
수
없음을
알
수
있다. 또한, 모든
대출이 Loan Rejected 상태
또는 Loan in Maintenance 상태에서
끝난다는
것도
알
수
있다.
액티비티
다이어그램
예제는
두
개의
객체(밴드
매니저와
리포팅
툴)에
의한
액티비티
제어를
나타내는
두
개의
수영
레인으로
되어있다. 프로세스는
한
밴드에
대한
판매
리포트를
보는
밴드
매니저로
시작한다. 리포팅
툴은
사람이
관리하는
모든
밴드들을
검색하여
디스플레이하고
이중
한
개를
고를
것을
요청한다. 밴드
매니저가
한
밴드를
선택하면
리포팅
툴은
판매
정보를
검색하여
판매
리포트를
디스플레이
한다.
컴포넌트
다이어그램
컴포넌트
다이어그램은
시스템을
물리적으로
볼
수
있도록
한다. 이것의
목적은
소프트웨어가
시스템의
다른
소프트웨어
컴포넌트들(예를
들어, 소프트웨어
라이브러리)에
대해
소프트웨어가
갖고
있는
종속
관계를
보여주는
것이다. 이
다이어그램은
매우
고급
레벨에서
볼
수
있거나
컴포넌트
패키지
레벨에서
볼
수
있다. 주 2
컴포넌트
다이어그램의
모델링은
이
예제에
잘
설명되어
있다. 그림 7은
네
개의
컴포넌트인 Reporting Tool, Billboard Service, Servlet 2.2 API, JDBC API를
보여주고
있다. Reporting Tool에서
출발하여 Billboard Service, Servlet 2.2 API, JDBC API로
가는
화살표는 Reporting Tool이
이들
세
개의
컴포넌트에
종속되어
있음을
나타낸다.
|
그림 7: 컴포넌트
다이어그램은
다양한
소프트웨어
컴포넌트들
간
종속관계를
보여준다.
|
전개
다이어그램
전개
다이어그램은
하드웨어
환경에
시스템이
물리적으로
어떻게
전개되는지를
보여준다. 목적은
시스템의
다양한
컴포넌트들이
어디에서
실행되고
서로
어떻게
통신하는지를
보여주는
것이다. 다이어그램이
물리적
런타임을
모델링
하기
때문에
시스템
사용자는
이
다이어그램을
신중하게
사용해야
한다.
전개
다이어그램의
표기법에는
컴포넌트
다이어그램에서
사용되던
표기법
요소들이
포함된다. 이외에
노드
개념을
포함하여
두
가지
정도
추가되었다. 노드는
물리적
머신
또는
가상
머신
노드(메인프레임
노드)를
표현한다. 노드를
모델링
하려면 3차원
큐브를
그려
큐브
상단에
노드
이름을
적는다. 시퀀스
다이어그램에서
사용되던
네이밍
규칙([instance name] : [instance type]) (예, "w3reporting.myco.com : Application Server").
|
그림 8: 전개
다이어그램. Reporting Tool 컴포넌트가 WebSphere 내부에서
그려지기
때문에(w3.reporting.myco.com 노드의
내부에서
그려짐), 사용자들은
로컬
머신에서
실행되는
브라우저를
통해 Reporting Tool에
액세스
하면서
기업
인트라넷을
통해 HTTP에
연결할
수
있다는
것을
알
수
있다.
|
그림 8의
전개
다이어그램은
사용자가
로컬
머신에서
실행되고
기업의
인트라넷에서 HTTP를
통해 Reporting Tool에
연결되는
브라우저를
사용하여 Reporting Tool에
접근하는
것을
보여주고
있다. 이
툴은
물리적으로 w3reporting.myco.com 이라고
하는 Application Server에서
실행된다. 이
다이어그램은 IBM WebSphere 내부에서
그려진 Reporting Tool 컴포넌트를
보여준다. 이것은
결과적으로 node w3.reporting.myco.com에서
그려지게
되어있다. Reporting Tool은
자바를
사용하여
리포팅
데이터베이스를 IBM DB2의 JDBC 인터페이스에
연결하여
원시 DB2 통신을
사용하는 db1.myco.com 서버상에서
실행되는
실제 DB2 데이터베이스와
통신한다. 리포팅
데이터베이스와
통신하는
것
외에도 Report Tool 컴포넌트는 SOAP over HTTPS를
통해 Billboard Service와
통신한다.
결론
이
글은 Unified Modeling Language에
대한
간단한
입문서에
불과하지만
여러분이
이
정보를
실제
프로젝트에
적용하거나
더
깊게 UML을
연구하기를
바란다. UML 다이어그램을
소프트웨어
개발
프로세스에
통합시키는
여러
소프트웨어
툴이
있지만, 자동화된
툴이
없더라도
화이트보드에
마커와
펜을
사용하여 UML 다이어그램을
그려도
좋다.
주
1 상속과
기타
객체
지향
원리에
대한
기타
자세한
정보는 http://java.sun.com/docs/books/tutorial/java/concepts/inheritance.html을
참조하기
바란다.
2 컴포넌트
패키지
레벨은
프로그래밍
언어에
중립적인
방식으로 .NET의
네임스페이스(System.Web.UI)나
자바의
패키지(java.util) 같은
클래스
컨테이너
레벨을
참조하는
것이다.
참고자료
편집자 note: The Rational Edge.
원문
게재일: 2003 년 11 월 25 일
출처 : http://www.ibm.com/developerworks/kr/library/769.html
