내가 UML을 처음으로 본 것은 1999년, 자바 프로그래밍을 시작했던 시기였다. 당시는 아직 별로 보급돼 있지 않았고,「UML이란 무업인가」「무엇을 위해서 사용하는가」「방법을 잘 모르는 채 우선 사용하는 것은 아닌가」라는 의문이 있는 정도에 지나지 않았다.

OMG(Object Management Group: 객체 지향 기술의 표준화를 행하는 단체)가 정식으로 UML을 인정하고 나서 약 10년이 된 최근에는 시스템 개발에 종사하는 사람 중에서 ML이라는 말을 들은 적이 없다는 사람은 거의 없는 게 아닐까.

실제로 개발 현장에서 UML 자체를 설명해야 하는 경우는 거의 사라졌고, 사용할 수 없어도 읽을 수 있다는 사람은 꽤 늘어난 것으로 생각한다. SNS나 웹 2.0과 같이 시스템 업계와 관련 없는 사람이라도 알고 있는 수준까지는 이르지 못했지만, UML이라는 단어를 자연스레 사용할 수 있게 된 것은 개발자끼리의 커뮤니케이션이 보다 쉬워진다는 뜻에서 매우 기쁜 일이다.

여기에서는 UML에 대해 어떤 지식도 가지지 않는 사람을 대상으로 UML로 무엇이 가능한지, 또 무엇을 위해서 있는지 라는 질문에 대한 답에서부터 실제의 개발 현장에서 UML이 어떻게 사용되고 있는지를 설명하고자 한다.

UML이란 무엇인가
UML이라고 하는 단어는 Unified Modeling Language의 머리글자를 취한 것으로, 따로 번역한 것은 존재하지 않고 그대로「UML」이라고 한다. UML은 객체 지향 기술을 사용해 시스템을 설계할 때에 이용하는 그림과 그 목적 및 기법을 정한 것이다.

랭귀지(Language)라고 부르면서도 C나 자바와 같은 프로그램 언어가 아니고, 어디까지나 그림의 쓰는 법이나 읽는 법을 결정하고 있을 뿐이다.

UML이 탄생할 때까지 수많은 기법이 난립해 개발자를 괴롭히고 있었지만, OMG가 표준 기법으로 UML를 인정하고 나서는 개발자의 공통 언어로 단번에 보급하게 되었다. 그 덕분에 온세상의 개발자가 말의 벽을 넘고 설계서를 쓰거나 읽을 수 있게 되었다.

또 조사 하나로 반대의 의미가 되기도 하는 애매한 표현으로 문장을 쓰는 것보다도, UML의 그림을 서로 보여주는 것으로 정확하게 뜻을 전달할 수 있다는 것이 점차 널리 인정되면서 UML은 더욱 널리 쓰이게 되었다.

UML의 관리 자체는 OMG가 하고 있지만, 이용에 대한 제약 없이 누구나 자유롭게 사용할 수 있다. 2003년에는 버전 2.0이 나오면서 한층 더 엄밀하게 정의할 수 있게 되었다. 이와 같이 기본적인 사용법은 변하지 않은 채 모호성을 배제한 표기를 할 수 있도록 UML도 진화하고 있다.

UML로 무엇이 가능한 것인가
UML 2.0에서는 전부 13종류의 다이어그램이 규정되고 있다. 이 다이어그램들을 목적에 맞추어 구분하여 사용하는 것으로 정적 또는 동적으로 시스템을 시각적으로 표현할 수 있다. 실제 현장에서 잘 사용되는 다이어그램을 몇 개 소개한다.

클래스 다이어그램
클래스 다이어그램에서는 시스템화 대상인 업무의 주요한 정보를「클래스」로서 정의해 클래스의 특성이나 클래스 간의 관련 등을 정적으로 나타낸다. 예를 들면「거래처에 법인과 개인의 2 종류가 있고, 거래처로부터의 수주에는 상품마다 명세서를 작성한다」라는 일을 아래와 같은 그림으로 표현할 수 있다.



클래스 그림 중에 있는 「1」이나 「*」은 다중도로 불려 각각 「1개」「복수」라고 읽는다. 따라서 이 다이어그램은 거래처 1개에 대해서 복수의 수주가 있는, 1개의 수주에는 복수의 상품 명세가 있다는 의미가 된다.

순서도
순서도에서는 처리의 흐름이나 실행 타이밍이라는 동적인 시스템의 행동을 나타낸다. 세세한 논리를 기술할 수 없지만, 문장으로 하는 설명과 비교해서 이해하기 쉽기 때문에 복잡한 처리를 설명할 때 등에 사용된다.



그 밖에도 상태나 상태가 변화하는 타이밍을 나타내는 「스테이트 머신(state machine) 다이어그램」이나 시스템의 기능과 그 실행자의 관계를 나타내는「유즈 케이스(use case) 다이어그램」등도 자주 사용된다.

UML의 용도
사실 UML은 기법을 결정하고 있을 뿐 그 사용법까지는 정의하고 있지 않다. 즉 UML 사용방법은 이용자에게 맡고 있기 때문에 기술 방법만 지키면 자유롭게 UML을 사용할 수 있다. 그렇다고는 해도 실제의 시스템 개발의 현장에서는 주로 3가지의 용도로 쓰이는 경우가 많다.

용도 1. 모델링
요건 정의 국면에서는, 현행 시스템을 이해하는 것이나「무엇을 만들까?」를 의식해 유저의 요건을 묻기 위해서 모델링이라고 하는 기법을 사용해 시스템의 전체상을 그리는 작업을 하는 일이 있다. 이 작업을 실시하는 사람을 모델러라고 부르고 모델링에 의해서 작성하는 그림을 개념 모델이라고 부른다.

개념 모델 자체는 어떠한 표현을 해도 상관없지만, 일반적으로는 UML의 클래스 다이어그램을 사용하는 것이 많은 듯하다. 그 이유 중 하나는 설계자가 이해하기 쉽기 때문이다.

UML을 사용한 모델링에서는 유저의 머릿속에 있는 요건을 정보로 정리하고 그 정보끼리의 관계를 정의해 도식화하는 것으로 시스템의 요건을 전체상으로서 파악한다. 실제로 이 작업을 보고 있으면, 마치 최초부터 거기에 존재했나 싶을 정도로 클래스 다이어그램이 완성되어 가는 모습에 매우 놀란다.

또 클래스 다이어그램의 읽는 법이 몇 가지는 결정돼 있긴 하지만 기억할 것은 많지 않다. 직감적으로 판단할 수 있기 때문에 UML에 익숙하지 않은 유저도 이해하기 쉬어서 개념 모델(클래스 다이어그램)에 대한 평가는 대체로 높다.

만약 클래스 다이어그램을 사용하지 않고 말만으로 유저의 요건을 정리하려고 하면, 부분적인 요건의 상세화는 할 수 있지만 전체를 파악하는 것이 어려워 주제가 희미해져 버리는 약점이 있다.

한편 클래스 다이어그램을 유저와 함께 만들어내 가는 모델링에서는 전체상을 시각적으로 이해할 수 있어 유저 자신이 깨닫지 못했던 과제도 발견할 수 있다는 장점이 있다.

단지 모델링의 단계에서 작성하는 클래스 다이어그램은 다음에 설명하는 설계 레벨의 클래스 다이어그램에 비해 매우 입도가 엉성하고 정보도 부족한 것이 많기 때문에 그대로는 프로그래밍할 수 없다. 그 대신 유저와 개발자의 사이에 「대체로 이런 느낌」이라고 하는 시스템에 대한 요구를 합의할 수 있어 요건 정의 국면에서는 매우 유효하다.

이와 같이 모델링에서는 UML의 클래스 다이어그램을 사용하는 것이 일반적입니다만 추상도가 높은 클래스 다이어그램의 정보를 구체화해 보충하는 스테이트 머신 다이어그램나 오브젝트 다이어그램도 잘 사용된다.

덧붙여 시스템 기능을 드러내기 위해서 유즈 케이스 다이어그램을 사용하기도 하지만, 보통 개발 현장에서는 기능 일람으로 대용하는 것이 많은 듯하다.

용도 2. 설계
이와 같이 요건 정의 국면에 UML을 사용해 작성한 그림은 설계에서 보다 구체화된다. 예를 들면, 개념 모델(클래스 다이어그램)이나 스테이트 머신 다이어그램으로부터 데이터베이스의 논리 설계를 행하거나 실제 이미지에 접근하기 위해서 클래스의 상세화를 한다.

설계 국면에서는 「어떻게 만들까?」를 의식하지만, 자바 등의 객체 지향 언어로 개발하는 것이 전제가 되고 있는 경우 UML을 사용하고 설계도(클래스 다이어그램이나 순서도 등)를 쓰는 경우가 많다.

실제로 움직이는 물건을 만들기 위한 설계이므로, 모델링에 비해 보다 엄밀성이 요구되지만 이 때 표기 방법이 명확하게 정해져 있는 UML이 매우 도움이 된다(단, 업무 사양 등 개별의 논리를 UML로 표현할 수 없다).

설계에서 클래스 다이어그램을 사용하는 가장 큰 장점은 클래스 간 인터페이스를 빠른 단계에서 명확하게 할 수 있는 점이다. 설계에서 쓰는 클래스 다이어그램에는 클래스의 속성이나 관계뿐 아니라 조작도 나타내게 되어 있다.

예를 들면, 수주 클래스에 수주 등록이라는 조작을 하는 것으로 그 클래스를 사용해 수주 정보를 등록할 수 있는 것이다. 여기에서는 조작을 실행하기 위해서 필요한 (입력) 정보와 실행 결과의 (출력) 정보를 분명히 해 클래스의 인터페이스를 정의하지만, 그 조작 자체의 내용을 자세하게 나타내 보일 필요가 없기 때문에 필요한 정보를 최저한의 표기로 나타내 보일 수 있다.

덧붙여 설계 시에 클래스 다이어그램이나 순서도 등을 만드는 것은 필수가 아니고, 비교적 소규모의 시스템으로 개발 멤버 사이에 미리 설계 방법이 공유되어 있는 경우에는, 필요에 따라서 코딩제의 프로그램으로부터 리버스해 클래스 다이어그램 등을 작성해, 설계서를 나중에 작성하기도 한다. 리버스 기능은, 이후 설명하는 툴로 지원되고 있다.

용도 3. 프로그래밍
실행 환경에 의존하지 않는 UML 모델로부터 툴을 사용해 실제로 움직이는 프로그램으로 변환하는 기술을 MDA(Model Driven Architecture)라고 부른다. MDA에 준거하면, 모델링→설계→프로그래밍에의 변환을 모두 UML만으로 할 수 있게 된다.

그러나 실제 현장에서는 MDA는 거의 보급되어 있지 않고, 변함없이 프로그래머가 설계서를 보면서 손으로 코딩하는 스타일이 여전히 계속 되고 있다. 현시점에서는, 툴 그 자체가 지원하고 있는 기술이 미성숙하기도 해서, 실제 현장에서 MDA가 적극적으로 사용되는 것은 어쩔 수 없는 것 같다.

UML 툴의 종류
UML로 도표를 그릴 때 일반적으로 툴을 이용한다. 툴에는 무료로 사용할 수 있는 것으로부터 유료까지 다양하지만, 모두 UML로 정해져 있는 기법에 따른 도표를 그리는 기능을 대충 갖추고 있다.

일본에서는, 체인지 비전의 무상 UML 툴「JUDE/Community」가 널리 사용되고 있다. 현시점에서 이 툴은 UML 1.4밖에 안되지만, 기본적인 이용이면 문제 없이 사용할 수 있다. 유료 판의「JUDE/Professional」는 UML 2.0에 대응하고 있다.

그 밖에 유료 툴로 적당한 것에는 마이크로소프트의 「비지오(Visio)」가 있다. 또 프로그래밍을 하면서도 간편하게 사용하고 싶은 경우에는, 원시 코드와의 제휴가 간단한 오픈소스의 개발툴「이클립스(Eclipse)」의 플러그인(무료)도 다수 제공되고 있다.

UML의 기법은 누가 봐도 보통의 해석밖에 할 수 없게 엄밀하게 정의되고 있다. 이것은 일견 딱딱하게 생각되지만, 그 엄밀함에 의해서 애매함을 배제할 수 있는 장점은 매우 큰 것이다.

나는 UML의 존재 의의는, 시스템화 대상으로 하는 실무의 세계를 시스템의 세계에 변환하기 위한 수단을 제공하는 것이라고 생각하고 있다. 모든 개발자가 UML을 통해 같은 것을 볼 수 있게 되면, 정보의 전달은 더 부드럽게 될 것이다. @