UML - 개요

- 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다.

 

- UML을 사용하는 방법들

UML을 어떻게 사용해야 한다는것에 대해서 몇 가지 논쟁이 있다. 사람들이 UML을 사용하는 방식에는 스케치, 청사진, 프로그래밍 언어 방식이 있다.

 

스케치방식은 일반적으로 사람들이 가장 많이 사용하는 방식이다. 이 방식에서는 코드나 요구사항을 누락없이 모두 표현하지는 않는다. 중요한 문제점이나 이슈에 대해 시각화를 하기 원할때나 의사소통을 하기 위해 사용한다. 사람들이 UML을 사용할 때에는 특정 다이어그램이나 표기법만 사용하는 경향이 있다. UML의 엄격한 규칙을 모두 지키면서 쓰려고 하지는 않는다.

 

청사진 방식은 완전성에 집중한다. 완전한 설계를 하면 프로그래머는 해당 설계를 보고 따라가기만 하면 되는 수준으로 사용하는 방식이다. 스케치와 청사진의 경계는 모호한 경향이 있지만 스케치방식은 중요한 문제나 현안들만 강조하는 반면 청사진 방식은 설계를 완전하게 함으로써 프로그래머가 따라가기만하면 되는 수준으로 설계하는데 목적이 있다.

프로그래밍 언어처럼 UML을 사용하는 방식이다. UML의 모든 표준을 따르고 요구사항을 완벽하게 설계해서 결국에는 다이어그램을 어떤 툴에 의해 코드로 변경할 수 있을정도로 사용하는 방식이다. 솔직히 개발자여서 그런지 몰라도 나는 이 방식에는 좀 회의적이다.

 

또한 UML은 두 가지를 표현하는데 하나는 소프트웨어적인 관점을 그리고 개념적인 관점을 표현한다. 

소프트웨어적인 관점에서는  말 그대로 소프트웨어 시스템 구성 요소를 잘 표현한다. 반면 개념적인 관점에서는 도메인의 개념을 표현한다. 

---

- 적법한 UML

적법한 UML이란 무엇인지에 생각할 때 두 가지 관점에서 생각할 필요가 있다.

규범적인 규칙이란 공식적인 단체에 의해 관리되는 해당 언어가 무엇이 적법하고 그렇지 않은지 또는 해당 언어가 무엇을 표현할 수 있는지에 대한것이다.

 

기술적인 규칙이란 실제 사용되는것을 보고 이해하는 규칙이다. 흔히 UML을 생각할 때 화려한 다이어그램이나 아주 정밀한 규칙을 모든 설계자들이 지키면서 할 것 같지만 실상은 그렇지 않다. 한국사람이 한국말을 할 때 한글의 모든 규칙을 알거나 따져서 말하지 못하듯이 관례에 의해 사용하는 측면도 상당히 많다.

 

UML 사용에 있어서 중요한것은 "UML이 모든것이 아니다"라는 사실을 아는것이 중요하다. UML을 잘 사용하면서 설계까지 잘한다면 당연히 최고다. 하지만 UML을 사용하는것 자체가 더 좋은 아이디어로 좋은 설계를 하기 위함이라는점을 생각해본다면 UML을 아주 잘 사용하고 좋지못한 설계를 하는것보다 UML을 스케치수준으로 사용하더라도 좋은 설계를 하는것이 더 적절하다.

---

- UML의 범위

가끔 UML을 신봉하는 사람들은 다른 툴을 쓰거나 대충 종이에 그려서 논의하면 더 간단하고 명확하게 표현할 수 있는 사안을 억지로 UML을 이용하여 표현하려는 경향이 있다. 아무리 UML을 잘해서 대부분의 사안을 UML로 표현할 수 있더라도, 어떤 사안은 UML이 아니어도 괜찮다는 유연한 사고방식을 갖는것이 중요하다.

 

예를 들어 만약 어떤 상태변수에 따른 결과값이 도출되어야할 때 액티비티 다이어그램으로 표현할 수도 있지만, 상태변수에 따라 가질 수 있는 상태값과 그에 따른 결과값을 표로 구성하고 보는것이 더 명확할 것이다.

UML은 모든것을 표현하지 않는다.