Tag Archives: 모델링

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

마이크로 서비스 아키텍쳐(Micro Service Architecture)는 줄여서 MSA라고 부르며 서비스를 기능별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴으로, 기본 컨셉은 하나의 서비스는 한가지 일에 초점을 맞춘다는 것입니다. 또 다른 서비스와의 연계는 API로 구현합니다.

마이크로 서비스 아키텍쳐 구현 프로세스는 크게 4단계로 나눌 수 있는데, 구체적인 처리 절차는 다음과 같습니다.

STEP 1. 기능별로 서비스 어플리케이션 구분

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 2. 서비스 이미지 개발

– 이때 각각의 서비스 어플리케이션은 수샙, 수백여개의 서비스들로 구성되며, 각 서비스는 적절한 CPI, Memory, I/O리소스를 제공받아야 하고, 배포는 빠르고 효율적이어야 함. 참고로 배포 방법은 서버마다 전체 서비스를 적용하는 방법, 서비스를 VM위에 적용하는 방법, 서비스를 도커 콘테이너 위에 적용하는 방법 등이 있습니다.

– 서버별로 서비스를 적용하면 배포 및 서비스의 시작속도가 빠르다는 장점이 있습니다. 그러나 한 서비스 인스턴스가 CPU와 메모리를 모두 사용하는 문제점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 서비스를 VM에 적용하면 서비스별로 고정된 자원을 사용할 수 있고 클라우드 인프라 기능을 활용할 수 있다는 장점이 있습니다. 반면에 의도 해던 기능 외의 다른 VM의 기능은 낭비된다는 단점이 있고, 또 VM 자체를 관리해주어야 하는 오버해드를 가지고 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– 마지막으로 서비스를 도커 콘테이너에 적용하는 방법이 있는데, 이는 VM의 장점을 거의 포함하면서 VM 보다는 가볍다는 잇점이 있습니다. 반면에 VM보다는 다소 기능이 떨어 질 수 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 3. 클라이언트에서 필요한 서비스 선택

– 실제 서비스 설계시 클라이언트에서 어떤 기능을 필요로 하는지 모델링을 할텐데, 이때 기능에 중복성을 없애면서 통신을 최소 하는 방향으로의 설계가 바람직합니다.

– 최적화 된 클라이언트의 구현 방법으로 API Gateway와 IPC(Inter-process Communiation)의 두가지 방법이 있습니다.

– API Gateway는 내부 시스템 아키텍쳐를 캡슐화 해서 클라이언트에 적합한 API를 제공하는 방식인데, 이는 주로 Netty, Vert.x, Node.js, Nginx와 같은 비동기, 논블로킹 I/O를 지원하는 플랫폼으로 개발됩니다. 또 통신 규격의 다양화로 이중 가장 효율적인 것을 선택할 수 있다는 장점이 있으며, Auto Scaling 및 IP 주소 변경에 유연하게 대응할 수 있다는 장점이 있습니다. 마지막으로 서비스 오류 핸들링을 용이하게 할 수 있다는 장점이 있는데, 넷플릭스의 Hystrix가 바로 그 예입니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

– IPC(Inter-process Communication)은 서비스-클라이언트, 서비스-서비스간 통신 구현 방식인데, 구현 방법에 따라 동기적(request)/비동기적(message-based) 방식으로 나뉩니다. 주로 HTTP Rest나 Thrift 프로토콜을 많이 사용하며, 서비스 오류 핸들링이 용이하다는 장점이 있습니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

STEP 4. 인스턴스 선택/관리

– 서비스가 가상화되먄 여러 인스턴스로 실행 시킬 수 있습니다. 이때 Auto Scaling 혹은 장애 등으로 IP 주소가 변화될 수 있습는데, 장애를 막기 위해 서비스 레지스트리에 자신의 상태를 전달합니다. 이때 상태 전달을 hearbeat이라고 호칭합니다.

마이크로 서비스 아키텍쳐 (MSA, Micro Service Architecture)의 장단점 및 구현 방법

 

마이크로 서비스 아키텍쳐의 장점을 요약하면 다음과 같습니다.

  • 빠른 복구
  • Scaling
  • 서비스 확장 용이
  • 대규모 장애 확률 감소
  • 협업 용이

 

반면에 마이크로 서비스 아키텍쳐의 단점은 다음과 같습니다.

  • 복잡함
  • 트렌잭션 관리 어려움
  • 다중 테스트
  • 소규모 장애 확률 증가

 

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문

UML은 표준 표기법으로써 그 자리를 확고히 했다. 이제는 한 걸음 더 나아가 UML을 보다 효과적으로 사용할 수 있는 방법을 생각해 볼 때이다.

음계를 이용하여 아름다운 음악을 작곡하듯이 UML을 이용하여 좋은 소프트웨어를 개발하는, 이른바 UML 사용의 베스트 프렉티스를 생각해야 한다. 간혹 베스트 프렉티스가 UML 표준을 준수하지 않는 경우도 있는데 중요한 것은 표준 준수 여부가 아니라 어느 것이 더 효과적이냐는 것이다. 성공적인 소프트웨어 개발을 위해서라면 표준을 넘나들 수도 있어야 한다.

이에 이번 글에는 유즈 케이스를 중심으로 UML을 잘 표현하기 위한 시맨틱을 제대로 정리하고 사용하는 방법에 대한 고찰해 보겠다.

* UML에서 유스케이스는 액터, 유스케이스, 유스케이스 다이어그램 등을 모두 포함하는 전체를 지칭하는 [유스케이스]와 특정 기능을 설명하는 유스케이스의 두 가지로 쓰인다. 이 글에서는 구분을 위해 전체를 지칭하는 것은 대괄호를 붙여 [유스케이스]로 사용하고 특정 기능을 설명하는 유스케이스는 그냥 유스케이스로 쓰겠다.

[유스케이스]는 시스템이 사용자에 의해서 어떠한 형태로 사용되는지를 기술하는 UML의 표준 표기법이다. 다르게 말하면 시스템이 갖추어야 하는 여러 기능적, 비기능적 요구사항(주로 기능적 요구사항)을 표현하는 방법이 [유스케이스]이다. 이전에도 요구사항을 기술하는 방법은 여러 가지가 있었지만 모델링의 표기법이 UML로 통합되면서 유스케이스가 요구사항을 기술하는 일반적인 방법으로 사용되어 오고 있다.

그런데 [유스케이스]는 표준 표기법임에도 불구하고 UML의 다른 표기법에 비해 그 구성 요소가 적고 그것들을 활용해서 표현하는 방식에 있어서 자유도가 매우 높다. UML의 구성 요소 중 UML 사용의 시맨틱적 요소가 가장 큰 것이 [유스케이스]라 할 수 있다. 유스케이스 사용의 다양한 방식들 중 많은 사람들의 지지를 받고 있는 이른바 베스트 프랙티스를 살펴봄으로써 유스케이스의 효과적인 사용법을 알아보기로 하자.

[유스케이스]의 큰 그림
[유스케이스]는 크게 [유스케이스] 모델과 [유스케이스] 기술서로 구성되어 있다. [유스케이스] 모델에 관한 것은 표준에 의해 정의되어 있지만 유감스럽게도 [유스케이스] 기술서는 특별히 표준이라 할 수 있는 것이 없다. 다만 방법론을 다루는 쪽이나 [유스케이스]를 많이 사용해 본 사람들이 [유스케이스] 기술서 작성을 언급할 뿐이다. [유스케이스] 모델은 [유스케이스]의 구성 요소인 액터와 유스케이스, 그리고 그들의 전체적인 관계를 다이어그램의 형태로 가진다. [유스케이스] 모델을 통해 시스템의 전체적인 개요와 구성을 쉽게 알 수 있다. [유스케이스] 모델에 나타난 구성 요소의 세부적인 내용은 [유스케이스] 기술서에 작성한다.

[유스케이스] 모델
[유스케이스]는 소프트웨어 시스템이 무엇을 만들어야 하는지, 어떠한 기능을 제공해야 하는지를 기술하는 표기법을 통칭해서 부르는 말이다. [유스케이스]는 시스템을 사용하는 사용자와 내가 만들어야 하는 시스템 자체를 설명하는 방법이다. [유스케이스]에서는 시스템을 사용하는 사용자를 액터(actor)라 하고 시스템의 행동을 유스케이스(use case)라고 한다. 그리고 내가 만들려고 하는 소프트웨어 시스템을 주제영역(subject)이라고 한다. 내가 만들 시스템에 대한 유스케이스들은 주제영역 안에 존재하고 주제영역 밖의 액터와 연결된다. <그림 1>은 [유스케이스] 다이어그램의 전형적인 예이다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 1> [유스케이스] 다이어그램의 전형적인 예

 
액터라고 해서 모두 사용자를 지칭하는 것만은 아니다. 주제영역으로 정의되는 시스템과 연결되어 상호작용하는 외부 시스템도 액터로 정의한다. 하나의 시스템을 여러 팀이 나누어 개발할 때 다른 팀에서 만든 모듈도 나의 팀의 관점에서 본다면 액터로 정의할 수 있다. 쉽게 말해서 내가 만들어야 하면 유스케이스이고 남이 만들면 액터가 된다. <그림 1>과 같은 [유스케이스] 다이어그램을 통해 시스템이 어떠한 액터들과 상호작용하며 어떤 기능을 액터에게 제공하는 지를 일목요연하게 알 수 있다.

[유스케이스] 모델 구성 요소에 대한 세부적인 내용은 [유스케이스] 기술서에 정의하고 [유스케이스] 다이어그램에서는 어떤 [유스케이스] 기술서와 연결되는지 정도를 첨가해 주면 된다. 이는 현존하는 대부분의 UML 모델링 툴이 지원해 주는 기능이다.

‘역할’을 뜻하는 액터
액터는 시스템의 사용자 측면을 정의할 때 사용한다. 액터는 보통 특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 시스템이 수행하는 역할이라고 정의하고 <그림 2>와 같이 표기한다.

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 2> 액터를 형상화한 모습

여기서 주목해야 할 것은 역할이라는 말이다. 액터의 표기법이 사람 모양을 하고 있어서 사람만이 액터라는 선입견을 가질 수 있는데 사람과는 관계가 없고 그 사람이 수행하는 역할과 더 밀접한 관계가 있다.

액터는 역할에 더 가깝기 때문에 사람 이름보다 직책 이름이 많이 사용된다. 만약 웹사이트 애플리케이션이라면 사이트 회원, 비회원, 관리자 등이 액터로 사용될만한 것들이다.

관심을 갖고 있는 주제영역 시스템과 상호작용하는 외부 시스템도 전형적인 액터이다. 외부 시스템은 주제영역 내의 시스템의 요청에 따라 정보를 제공하는 것이 일반적이다. 전자상거래가 필요한 시스템이라면 외부 시스템으로 신용 정보나 금융 정보 등을 제공하는 시스템을 생각할 수 있고, 여행 상품을 제공하는 시스템이라면 외부 시스템으로 호텔 예약 시스템이나 교통편 예약 시스템 등을 생각할 수 있겠다. 다음은 액터의 전형적인 사례이다.

◆ 사람 : 텔레마케터, 관리자 등
◆ 외부 시스템 : 신용 정보 시스템, 예약 시스템 등
◆ 장치 : 온도 감응 장치, 출입 통제 장치 등
◆ 외부 조직 : 금융감독원, 보안 조직 등
◆ 이벤트 : 매일 밤 12시, 월급날 등

이벤트도 액터?
액터는 시스템의 기능적 요구사항을 정의할 때 매우 유용하게 사용된다. 특히 이벤트 발생 시점과 같은 액터는 시스템의 기능적 요구사항을 정의하는 데 매우 유용하다. 주기적으로 수행되는 배치 작업이 일반화되어 있는 현대의 시스템에서 이벤트 발생 시점은 매우 훌륭한 액터가 된다.

사실 시간과 같은 이벤트를 액터로 해도 되느냐 하는 부분에 대해서는 논란의 여지가 있는 것도 사실이다. 액터는 시스템을 사용함으로써 원하는 목적을 달성하려는 사람 혹은 외부 시스템으로 정의하기도 하는데, 시간 자체는 특별한 목적을 가지지 않기 때문에 액터로 해서는 안 된다고 주장하는 경우도 있다.

[유스케이스]는 그 사용에 있어 자유도가 높기 때문에 이러한 논쟁이 유달리 많기도 하다. 중요한 것은 시스템의 요구사항을 [유스케이스]로 정의하고 보다 많은 사람이 그것을 통해 서로의 생각을 얼마나 잘 공유할 수 있느냐는 것이다. 이벤트를 액터로 하는 것은 시스템의 기능 정의에 많은 도움이 된다고 생각한다.

액터의 분류
[유스케이스]의 창시자인 이바 야콥슨은 액터를 주요(primary) 액터와 보조(secondary) 액터의 두 가지로 분류했다. 주요 액터는 시스템에 어떠한 작업의 실행을 요구하는 능동적인 입장의 액터로 유스케이스를 기동하는 역할을 수행한다. 보조 액터는 시스템의 요청에 따라 수동적으로 어떤 작업을 해 주는 액터로써 유스케이스로부터 어떠한 요청이나 메시지를 전달 받는 액터를 말한다. 최근에는 액터를 더 세분화해서 분류하기도 하는데, 액터의 성격에 따라 크게 네 가지로 나눌 수 있다.

◆ 유스케이스를 기동시키는 액터
◆ 시스템의 요청에 따라 정보를 제공하는 외부 액터
◆ 시스템이 제공하는 정보를 단순히 수신하는 액터
◆ 다른 액터와 시스템간의 상호 작용을 돕는 프록시 역할의 액터

네 가지 액터 유형 중 특이한 것이 프록시 역할을 하는 액터이다. 액터는 유스케이스와 연결될 뿐 액터와 액터는 서로 연결되지 않게 하는 것이 일반적인 액터의 설계 방식으로 여겨져 왔다. 그러나 액터끼리 서로 연결되게 모델링을 하는 것이 시스템을 좀 더 이해하기 쉽게 만드는 경우도 있다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 3> 전화로 예약을 받는 시스템

 
<그림 3>은 전화로 예약을 받는 시스템의 예이다. 시스템을 직접 사용하는 사용자는 전화를 받는 창구 직원이 되겠지만 예약이라는 목적을 가지는 것은 고객이기 때문에 고객이 창구 직원에게 전화를 걸어 시스템을 사용하는 것은 <그림 3>처럼 모델링하는 것이 보다 효과적이게 된다. <그림 3>과 같은 시스템은 보통 클라이언트/서버 유형이 애플리케이션인 경우가 많은데 이후 시스템을 웹으로 확장시켜 고객이 직접 웹 사이트를 통해 예약이 가능하도록 하게 되면 창구 직원 액터가 웹을 통한 예약 유스케이스로 변환될 수도 있다.

유스케이스
시스템이 액터에게 주목한 만한 결과를 내놓기 위해 수행하는 여러 작업들의 집합을 유스케이스라고 한다. 즉, 앞서 나온 예약 접수나 구매 주문, 주문 현황 점검과 같은 것들이 유스케이스이다. 유스케이스는 시스템이 수행하는 특정 기능에 대해서 그 기능의 수행을 원하는 액터와 시스템간의 상호 작용과 시스템 내부에서 발생하는 모든 가능한 사항을 기술한다. 유스케이스는 <그림 4>와 같이 표기한다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 4> 유스케이스

 
유스케이스의 구성 요소는 여러 가지가 있지만 이름과 작업 흐름이 제일 중요하다. 유스케이스 이름은 [유스케이스] 모델에서 중요하고 작업 흐름은 [유스케이스] 기술서에서 중요하다. 유스케이스의 이름을 지을 때는 동사나 동사구의 형태로 능동형을 사용하는 것이 좋다. 유스케이스의 작업 흐름을 기술할 때 유의해야 할 점은 ‘무엇’에 대한 것을 작성해야 한다는 것이다.

간혹 유스케이스가 무엇이 아닌 ‘어떻게’를 기술하게 작성하는 경우가 있는데, 이는 그리 바람직하지 않은 모습이다. 유스케이스는 시스템이 무엇을 제공하고 액터는 무엇을 얻는가를 기술하는 방편이지 시스템을 어떻게 구축할 것인가에 대한 것은 아니다.

유스케이스 간의 관계
유스케이스와 유스케이스 사이에는 서로 밀접하게 연관되어 있어 상호간에 관계를 가지는 경우가 있다. 유스케이스는 포함(include), 확장(extend), 일반화(generalization)의 세 가지 관계 유형이 있다.

포함 관계
하나의 유스케이스가 유스케이스 내의 작업 흐름의 과정 안에 다른 유스케이스의 작업 흐름을 포함하게 하는 관계이다. 포함 관계는 <그림 5>와 같이 표기한다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 5> 포함 관계

 
유스케이스는 액터와 시스템간의 상호 작용이나 시스템 내부의 작업 등을 기술한다. 이때 여러 유스케이스에서 비슷한 작업이 공통으로 발생하는 경우가 있을 수 있다. 이때 이렇게 공통으로 발생하는 유스케이스의 특정 부분을 하나의 유스케이스로 따로 분리하고 포함 관계를 통해 정의하는 것이 가능하다. 이는 프로그램에서 서브 루틴을 호출하는 개념과 유사하다.

포함 관계에서 유스케이스는 ‘포함하는(including) 유스케이스’와 ‘포함되는(included) 유스케이스’로 나눌 수 있다. 유스케이스는 액터가 그 작업 흐름을 기동시키는데, 포함 관계에서 ‘포함되는 유스케이스’는 액터가 아닌 ‘포함하는 유스케이스’가 작업 흐름을 기동시킨다. 그래서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 없으면 제 구실을 하지 못하고 ‘포함하는 유스케이스’에 합쳐져야 제 기능을 하게 된다.

포함 관계에서 ‘포함되는 유스케이스’를 ‘포함하는 유스케이스’에 포함시킬지 여부는 ‘포함하는 유스케이스’에서 결정한다. 보통 조건절과 같은 내용이 ‘포함하는 유스케이스’에 들어가게 되고 조건절의 만족 여부에 따라 ‘포함되는 유스케이스’를 수행할 지가 결정된다. <그림 6>과 같은 유스케이스가 포함 관계의 가장 전형적인 예이다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 6> 포함 관계의 전형적인 예

 
주문 결제 유스케이스는 액터가 결정한 결제 형태에 따라 현금 결제, 카드 결제, 포인트 결제 유스케이스 중에 하나를 포함하게 된다. 포함 관계는 유스케이스 간의 관계를 설정할 때 가장 쉽게 사용할 수 있는 관계 설정 방법이다.

확장 관계
하나의 유스케이스의 흐름이 다름 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계이다. 확장 관계는 <그림 7>과 같이 표기한다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 7> 확장 관계

 
확장 관계에서 유스케이스는 ‘확장되는 유스케이스’와 ‘확장하는 유스케이스’로 나눌 수 있다. ‘확장되는 유스케이스’가 액터와 상호작용하면서 작업 흐름을 수행하던 중 확장하는 조건이 만족하게 되면 그 만족되는 시점에서 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’에 합쳐져서 작업 흐름을 수행한다. 예를 들면 특정 작업을 수행하던 중 사용자가 도움말 버튼을 눌러서 도움말 내용을 확인하는 것 같은 작업이 전형적인 확장 관계이다.

확장 관계에서는 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 특정 지점으로 합쳐지게 되는데, 이 지점을 확장 지점(Extension point)이라고 한다. 확장 지점은 ‘확장되는 유스케이스’에 위치하게 되고 ‘확장되는 유스케이스’는 여러 개의 확장 지점을 가질 수 있다. ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 어떤 확장 지점으로 확장될 것인가는 확장 관계에 표시한다. 확장 관계는 확장하는 조건과 어떤 확장 지점으로 확장될 것인가에 대한 정보를 보유한다.

유스케이스가 합쳐져서 보다 큰 작업을 한다는 점에서는 포함 관계와 확장 관계가 크게 다를 바는 없지만 그 적용되는 방법과 내용상에 있어서는 몇 가지 차이점이 존재한다.

첫째, 포함 관계는 ‘포함하는 유스케이스’가 주 흐름 유스케이스이고 ‘포함되는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것인 데 반해 확장 관계에서는 ‘확장되는 유스케이스’가 주 흐름 유스케이스이고 ‘확장하는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것이 된다.

둘째, 포함 관계에서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 정상적으로 동작하기 위해서 반드시 필요한 필수 요소인 데 반해 확장 관계에서 ‘확장하는 유스케이스’는 선택 사항으로써 ‘확장되는 유스케이스’는 ‘확장하는 유스케이스’와 상관없이 독립된 기능을 수행할 수 있다.

보통 유스케이스에 내용을 추가할 때는 포함 관계나 확장 관계 중 어느 방법을 사용하더라도 큰 무리가 없다. 약간의 차이가 있다면 포함 관계로 내용을 추가하려고 할 때에는 내용 추가의 기반이 되는 ‘포함하는 유스케이스’의 내용 변경이 반드시 동반되어야 하는 데 반해 확장 관계로 내용을 추가할 때는 내용 추가의 기반이 되는 ‘확장되는 유스케이스’의 내용 변경이 불필요하다는 것이다. 따라서 이미 존재하는 유스케이스 도큐먼트 내용의 수정이 가능한지 불가능한지 여부가 포함 관계로 내용을 추가할 것인지 확장 관계로 내용을 추가할 것인지를 선택하는 기준이 될 수 있다.

일반화 관계
유스케이스 간의 일반화 관계는 객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미이다. 일반화 관계는 <그림 8>과 같이 표기한다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 8> 일반화 관계

 
자식 유스케이스는 새로운 작업 흐름이나 별도의 속성, 확장 지점, 다른 유스케이스와의 관계 등을 정의할 수 있다. 하나의 유스케이스는 여러 개의 부모 유스케이스를 가질 수 있고, 자신이 여러 유스케이스의 상위 유스케이스가 될 수도 있다.

유스케이스의 레벨
UML에 정의되어 있는 [유스케이스]의 표준에는 유스케이스에 대한 레벨이나 범위에 대한 개념이 없다. 레벨이나 범위는 유스케이스를 작성하는 과정에서 그 필요성이 자연스럽게 도출된 개념들이다. 레벨이 높은 유스케이스가 넓은 범위의 내용을 광범위하게 다루고 레벨이 낮은 유스케이스가 보다 적은 범위의 내용을 상세히 다룬다. <그림 9>는 유스케이스의 레벨에 대한 개념을 보여준다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 9> 유스케이스의 레벨 개념

 
보통 유스케이스의 레벨은 그 유스케이스를 필요로 하는 사람에 따라 다르게 구성된다. 전체 시스템을 개괄적으로 보기를 원하는 매니저나 관리자들은 보다 높은 레벨로 구성된 유스케이스를 필요로 한다. 이들에게는 어떻게 유스케이스가 수행되는가는 주 관심 분야가 아니고 보다 높은 레벨의 관점으로 시스템을 바라보고 싶어 한다. 반면 요구사항 분석을 통해 시스템 전체의 모습을 구성해야 하는 시스템 분석가들은 보다 세부적으로 어떠한 기능을 수행하는지를 볼 수 있는 수준이 필요하다.

반면 개발자들은 요구되는 기능을 어떻게 실제로 구현할 것인지를 정의할 수 있는 수준의 유스케이스를 필요로 한다. 유스케이스를 통해 요구사항에 대한 의사소통을 하는 사람의 역할이 무엇이냐에 따라 유스케이스는 다른 레벨의 형태를 띠게 된다.

유스케이스의 레벨에 관련해서는 ‘왜’라는 물음과 ‘어떻게’란 물음이 중요한 역할을 한다. <그림 10>에서와 같이 유스케이스의 작업 흐름 내용에 대해서 ‘왜’라는 물음에 대한 답이 상위 레벨 유스케이스가 되고 ‘어떻게’라는 물음에 대한 답이 하위 레벨 유스케이스가 된다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 10> 상위와 하위 레벌 유스케이스

 
적절한 레벨은?
유스케이스가 많이 사용됨에 따라 유스케이스가 어느 정도의 범위를 커버하도록 구성하는 것이 가장 적절한지에 대한 많은 고민이 있어왔다. 유스케이스를 작성하는 데 있어서 전형적으로 등장하는 좋지 않은 예 중에 하나가 같은 레벨의 유스케이스 간에 상세화 정도의 차이가 생기는 것이다. 같은 레벨의 유스케이스는 비슷한 정도의 범위를 비슷한 상세화 정도로 기술해야 한다.

레벨은 크게 요약(summary), 사용자 목적(user goal), 하위 기능(sub function)으로 나눌 수 있다. 사용자 목적 레벨이 요구사항을 분석하는 데 가장 적절한 수준이다. 사용자 목적 레벨에서 ‘왜’라는 질문을 통해서 내용을 정리하면 요약레벨의 유스케이스가 되고 ‘어떻게’라는 질문을 통해서 내용을 상세화하면 하위 기능 유스케이스가 된다. 사용자 목적 레벨의 유스케이스를 판단할 때 다음과 같은 정도의 기준을 사용할 수 있다.

◆ 액터가 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도의 작업
◆ 작업이 완료되었을 때 액터가 자리를 뜨는데 어려움이 없는 정도

하나의 유스케이스는 사건 흐름에 보통 3~9 스텝 정도를 밟는 것이 좋다. 단 2스텝으로 끝나버린다거나 10스텝 이상으로 길어지는 것은 유스케이스를 이해하는 데 별로 좋지 않다. 만약 스텝이 길다면 다음의 예와 같은 스텝들을 하나의 스텝으로 합쳐서 스텝의 수를 조절할 수 있다.

◆ 같은 액터가 여러 스텝을 점유한 경우
◆ 액터가 사용자 인터페이스를 사용하는 부분을 여러 스텝을 통해 기술한 경우

그래도 스텝이 길다면 그 유스케이스는 너무 큰 유스케이스이거나 너무 상세화된 유스케이스인 경우가 대부분이다. 유스케이스가 크다면 여러 개의 유스케이스로 나누는 것을 고려해야 하고 너무 상세화된 유스케이스라면 ‘왜’라는 질문을 통해 레벨을 높이도록 해야 한다.

[유스케이스] 기술서
앞에서 [유스케이스]라고 하는 요구사항 분석 설계 표기법에 사용하는 여러 요소들에 대해 살펴보았다. UML이 [유스케이스]에 대해 표준으로 정의하고 있는 것은 액터나 유스케이스, 유스케이스 간의 관계와 같은 구성 요소와 그들이 서로 어떻게 연계되어 전체적인 모습을 보여주는 지와 같은 것들이다. 이것은 요구사항 분석 설계 메커니즘으로써의 [유스케이스]의 반쪽밖에 되지 않는다.

[유스케이스]의 또 다른 반쪽은 [유스케이스] 기술서라고 하는 문서의 형태로 존재하는데, 이는 표준으로 정의되어 있지 않다. 오히려 방법론 등에서 [유스케이스] 기술서를 어떠한 형태로 어떻게 작성해야 하는지를 제시하고 있다. 그래서 다양한 형태의 [유스케이스] 기술서가 정의되어 사용되고 있다. 그러면서 베스트 프랙티스가 정립되면서 표준이라 할 수 있을 정도의 [유스케이스] 기술서가 만들어 졌다.

구성 요소
[유스케이스] 기술서에는 대체로 다음과 같은 내용들이 들어가게 된다.

◆ 이름 : 유스케이스의 이름
◆ 반복 : 반복이 이루어진 횟수. 버전과 유사한 개념
◆ 액터 : 유스케이스와 관련된 액터들의 목록
◆ 범위 : 유스케이스가 어떤 수준의 범위를 다루는지에 대한 설명
◆ 레벨 : 유스케이스가 어느 레벨의 것인지에 대한 설명
◆ 요약 : 유스케이스가 어떠한 일을 하는 지를 개략적으로 설명하는 내용
◆ 주 작업 흐름 : 유스케이스가 수행하는 작업의 흐름을 여러 스텝으로 기술한 내용 중 가장 전형적으로 발생하는 것. 유스케이스가 설명하는 업무의 80% 정도가 주 작업 흐름에서 커버한다.
◆ 대안 흐름 : 주 작업 흐름을 따르는 과정에 조건에 따라 다르게 작업하는 것을 기술한 내용
◆ 예외 흐름 : 작업 흐름이 진행되는 과정에서 예외사항이 발생하였을 경우 어떻게 처리해야 하는 지를 기술한 내용
◆ 사전 조건 : 유스케이스가 제대로 작동하기 위해 사전에 만족되어야 하는 조건을 기술
◆ 사후 조건 : 유스케이스가 끝나면 어떠한 결과가 제공되는지를 기술
◆ 비즈니스 룰 : 유스케이스의 작업 흐름과 관련해서 업무 규칙에 관한 내용을 기술
◆ 사용자 화면 : 사용자 인터페이스 화면에 대한 내용
◆ 작성자 : 유스케이스의 작성자
◆ 작성일 : 유스케이스 작성일

몇 가지의 기술서 작성 양식
앞에서 여러 가지 [유스케이스] 기술서의 구성 요소에 대해서 설명했지만 일반적으로는 [유스케이스] 기술서의 구성 요소들 중 필요한 것을 선별하여 [유스케이스] 기술서 양식을 만들어서 [유스케이스]의 내용을 만드는 데 사용하게 된다. [유스케이스] 기술서의 양식은 프로젝트의 규모나 문서화를 얼마나 세세하게 할 것인지 등을 살펴보고 적합한 수준에서 결정한다.

프로젝트의 규모가 크거나 프로젝트에 대한 위험 부담이 높은 프로젝트에서는 대개 엄격한(rigorous) 방법론을 사용하는 것이 일반적이다. 엄격한 방법론에서는 산출물의 형식이나 내용의 유무를 중요하게 생각한다. [유스케이스] 기술서에도 예외가 아니어서 항목이나 내용이 많고 그 내용을 규칙에 따라 작성하도록 요구한다. 유스케이스의 엄격한 양식에는 앞서 기술한 [유스케이스] 기술서의 구성 요소가 거의 대부분 들어간다.

프로젝트의 규모가 작아서 산출물 작성의 형식에 그리 큰 비중을 두지 않는 경우나 혹은 기민한 방법론을 채택해서 산출물의 신속한 작성과 변경이 요구되는 경우는 [유스케이스] 기술서의 형식을 간략하게 사용하는 경우도 있다. <표 1>은 간략화한 양식의 예이다.

 <표 1> [유스케이스] 기술서의 간략화한 양식
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
유스케이스 25 로그인
주요액터: 사용자
범위: 애플리케이션
레벨: 하위기능
사용자는 시스템에 자신을 알리기 위해 로그인을 한다. 사용자는 사용자이름과 패스워드를 입력한다. 시스템은 사용자를 확인하기 위해 사용자가 제시한 사용자이름과 패스워드를 검증한다. 사용자 이름과 패스워드가 일치하면 시스템은 사용자에게 시스템을 사용할 수 있는 권한을 준다.
만약 사용자가 제시한 사용자이름과 패스워드가 관리자 레벨의 것일 경우 사용자는 시스템을 조작할 수 있는 권한을 함께 부여 받는다.
만약 사용자이름이 존재하지 않거나 패스워드가 틀릴 경우 권한의 부여는 거부되고 사용자는 시스템을 이용할 수 없게 된다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문

 <표 2> RUP에서 제시하고 있는 유스케이스 기술서 양식
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
1. Use Case Name
1.1. Brief Description
…text…
1.2. Actors
…text…
1.3. triggers
…text…
2. Flow of events
2.1. Basic flow
…text…
2.2. Alternative flows
2.2.1. Condition 1
…text…
2.2.2. Condition 2
…text…
2.2.3. …
3. Special Requirements
3.1. platform
…text…
3.2. …
4. Preconditions
…text…
5. Postconditions
…text…
6. Extension Points
…text…

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문


점증적이며 반복적인 작성 프로세스

소프트웨어 개발 방법론에서는 점증적·반복적 접근이 많이 사용되는데 [유스케이스]의 작성에도 예외는 아니다. 대부분의 [유스케이스] 작성 프로세스가 반복을 통해 점증적으로 [유스케이스]의 내용을 추가하는 방식을 취하고 있다. <그림 11>은 세 번의 반복을 통해 점진적으로 유스케이스의 항목을 추가해 나가는 유스케이스 작성 프로세스의 모습을 간략히 한 모습이다.

 

유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 11> 점진적으로 유스케이스 항목을 추가해 나가는 모습

 
초기(Initial) 단계에서는 시스템의 범위를 정하고 액터와 유스케이스를 찾는다. 여기서 액터와 유스케이스는 이름과 간략한 요약 정도만을 기술해 주면 된다. 기반(Base) 단계에서는 초기 단계에서 찾아낸 액터와 유스케이스의 내용을 보강한다. 각 유스케이스에 대해서 사건 흐름을 기술하고 선행 조건과 사후 조건을 기술한다. 상세(Elaboration) 단계에서는 유스케이스의 모든 세부 항목을 완성 시키는 단계이다. 각 유스케이스에 사건 흐름에 대해 대안 흐름과 예외 흐름을 추가한다.

코번의 12 단계 정의
writing effective use case의 저자인 코번은 유스케이스를 작성하는 12단계를 정의했다.

[1] 시스템의 범위와 경계 설정
[2] 시스템에 관계된 모든 액터 찾기
[3] 액터가 시스템을 통해 얻으려고 하는 목적들 찾기
[4] 각 액터에 대한 최상위 유스케이스(summary use case) 설정
[5] 최상위 유스케이스들에 대한 정제 작업(시스템 범위의 재확인)
[6] 상세 작업을 할 유스케이스 선택
[7] 이해 관계자와 그들의 목적, 선행 조건, 후행 조건 등을 뽑아냄
[8] 주 성공 작업 흐름 작성
[9] 대안 흐름과 예외 흐름 찾기
[10] 대안 흐름과 예외 흐름 작성
[11] 복잡한 스텝을 하위 유스케이스로, 자잘한 스텝들은 모아서 하나로 합치는 작업 수행
[12] 유스케이스 조절 작업(읽기는 쉬운지, 구색은 갖췄는지, 이해 관계자는 만족하는지) 수행

코번의 12단계도 앞서 설명한 작업 절차와 그리 큰 차이는 보이지 않는다. 중요한 것은 반복적으로 점증적으로 [유스케이스]를 작성해 나간다는 것이다.

UML을 제대로 사용하려면 이것은 기억하자
[유스케이스] 모델과 [유스케이스] 기술서 등 [유스케이스]와 관련한 여러 가지를 살펴보았다. 이제는 [유스케이스]와 관련해서 유의해야 할 점을 짚어 보기로 하자.

액터와 유스케이스의 연결
UML 표준에는 액터와 유스케이스의 연결에 단순한 직선 연결만을 사용하고 있는데 화살표를 사용해서 나름의 의미를 부여하는 경우도 있다. 다음은 화살표 사용의 몇 가지 사례이다.

◆ 주요 액터가 유스케이스를 기동하는 경우에만 액터에서 유스케이스 쪽으로 화살표 머리 사용
◆ 주요 액터가 유스케이스를 기동하거나 유스케이스가 보조 액터를 기동하는 경우 기동하는 쪽으로 화살표 머리 사용.
◆ 단 방향 커뮤니케이션에만 화살표 머리 사용. 기대되는 응답이 없는 경우에 사용한다(예 : 프린터로 명령을 보내는 경우, 정부 기관에 내용을 통보하는 경우)

[유스케이스] 다이어그램에서 화살표를 사용할 때에는 데이터의 흐름이 아니라 커뮤니케이션의 기동 방향을 보여주는 데 사용하는 것이 좋다. 데이터는 보통 액터와 유스케이스 사이에 양방향으로 흐르는 것이 일반적이기 때문에 데이터의 흐름으로 화살표를 사용하게 되면 양방향 화살표가 되게 되고 이것은 다이어그램을 어지럽히는 원인이 된다.

전통적인 실수들
[유스케이스]를 작성하는 데 있어서 다음과 같은 실수가 자주 발생한다.

액터가 없는 유스케이스, 시스템이 없는 유스케이스
액터와 유스케이스는 반드시 서로 연결되어 있어야 한다. ‘포함되는 유스케이스’나 ‘확장하는 유스케이스’의 경우도 포함 또는 확장되어 액터와 연결된다. 간혹 혼자 동떨어져 있는 유스케이스가 있는 시스템이 보이기도 하는데 이는 잘못 작성된 것이다.◆ 사용자 인터페이스의 내용을 너무 상세히 담고 있는 [유스케이스]
[유스케이스]는 기능적 요구사항을 담는 것이기 때문에 사용자 인터페이스의 상세한 내용은 담지 않는다. 다만 사용자 인터페이스를 상세하게 설명한 문서에 대한 참조 정도를 추가하면 된다.

너무 낮은 레벨의 [유스케이스]
구현에 대한 상세한 내용이 담겨 있는 [유스케이스]는 적절하지 않다. [유스케이스]에 소스코드 레벨의 설명이 들어 있는 경우가 간혹 있는데 ‘왜’라는 물음을 통해 상위레벨의 [유스케이스]로 만드는 것이 좋다.

전산인의 언어를 사용한 유스케이스
[유스케이스]는 요구사항을 기술하고 그것을 통해 여러 관여자 들과 의사소통을 하기 위해 만드는 것이다. [유스케이스]에 사용하는 용어는 많은 사람이 이해할 수 있도록 보편적인 용어를 사용해야 한다.

애플리케이션 관점의 유스케이스
유스케이스는 액터의 관점에서 기술해야 한다. 시스템의 관점에서 기술한 유스케이스는 적절하지 않다.

‘~해야 한다’ 식의 표현
요구사항을 기술하는 전통적인 방법에서는 ‘시스템은 ~해야 한다’는 식의 표현이 자주 등장한다. 이러한 표현을 [유스케이스]에서는 사용하지 않는 것이 좋다. 만약 고객의 요구로 ‘~해야 한다’는 식의 표현을 넣어야 한다면 [유스케이스]의 요약 부분에 넣는 것이 좋다. 작업 흐름 부분에는 ‘~해야 한다’가 아닌 ‘~한다’라는 표현을 사용해야 한다.

유스케이스 작성에 대한 10가지 잘못
[1] 다른 형태의 요구사항 문서는 만들 필요가 없다. [유스케이스]면 요구사항을 충분히 반영할 수 있다.
아니다. 요구사항 문서는 요구사항을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 요구사항은 ER모델이 적합하고, 화면 구조에 대한 요구사항은 그래픽이 가미된 문서가 더 적합하다.

[2] 읽는 사람이 [유스케이스]의 목적에 대해 이해하기 힘들게 한다. [유스케이스]의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 [유스케이스]를 실제로 구현할 때 어떻게 해도 상관없을 것이다.
[유스케이스]를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 [유스케이스]를 작성할 필요가 있다. 간혹 어떻게 [유스케이스]를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다.

[3] [유스케이스]의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 사용자는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가?
[유스케이스]는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 [유스케이스]를 작성해야 한다.

[4] [유스케이스] 기술서에 비기능적 요구사항과 사용자 인터페이스 디테일을 포함시킨다.
유스케이스의 작업 흐름에 사용자 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 사용자 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다.

[5] 초기 [유스케이스] 다이어그램에 포함 관계와 확장 관계를 많이 사용한다. 그러면 유스케이스를 작은 단위의 것으로 나눌 수가 있다.
초기 버전의 유스케이스는 상위레벨의 유스케이스를 작성하고 반복을 거치면서 보다 상세화한 유스케이스를 작성하는 것이 좋다. CRUD를 처리하는 유스케이스가 대표적인데, 초기에는 ‘관리하다’라는 유스케이스로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 유스케이스로 세분화한다.

[6] 비즈니스 룰을 정의하는 것에는 관여하지 말라.
비즈니스 룰을 만들고 사용하는 것은 사용자이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 [유스케이스]를 통해 표현하도록 독려해야 한다.

[7] [유스케이스]의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다.
[유스케이스]는 요구사항에 대한 표준 표기법인데, 소프트웨어 시스템에 대한 요구사항을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다.

[8] 만약 사용자를 [유스케이스] 정의에 관여시킨다면 그냥 그래라. 왜 사용자와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다.
될대로 되라는 식의 태도는 좋지 않다. 사용자에게 [유스케이스]를 충분히 이해시키고 [유스케이스]를 통해 효과를 볼 수 있도록 노력해야 한다.

[9] [유스케이스]를 한 번에 아주 상세하게 만들어라.
반복적으로 점증적으로 [유스케이스]를 작성하는 것이 좋다.

[10] [유스케이스]를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다.
반복적으로 점증적으로 작성하고 중간중간 계속 사용자나 도메인 전문가의 피드백을 받아야 한다.

아름다운 표현 양식이 되길 바라며
요구사항을 수집하는 일은 오래 걸리거나, 잘못된 것을 기록하거나, 발생하지 않을 일을 추측하거나, 시간에 맞춰 허겁지겁 끝내는 등과 같은 결과를 초래하는 경우가 많다. 이는 요구사항 수집이 비생산적인 경로를 거치거나, 요구사항 수집을 무시하거나, 요구사항 수집 자체만을 위해 매달리거나, 요구사항을 한 사람이 결정하기 때문에 발생한다.

[유스케이스]는 이러한 요구사항 수집에 사용하기 좋은 방법 중 하나이다. [유스케이스]의 표준을 따라 보편화된 방법으로 요구사항을 기술하면 보다 많은 사람들이 사용할 수 있을 것이다. 물론 표준에 대한 준수 여부보다는 [유스케이스]의 내용을 어떠한 생각을 가지고 채워 넣었느냐가 더욱 중요하다.

UML은 단순한 표기법에 지나지 않지만 아주 좋은 표기법임에는 틀림없다. 마치 한글처럼. 아름다운 우리말을 한글이 잘 표현하듯이 소프트웨어 개발에 대한 여러분의 멋진 생각들을 UML을 통해 잘 표현해 보기를 바란다.@

백줄 글보다 낫다「다이어그램 작성 프로그램」

소프트웨어 개발이 어려운 이유 중 하나가 소프트웨어 자체와 그 개발 과정이 가시적이지 못하기 때문이다. 개발 진행이 소프트웨어 개발과 유사하다고 이야기하는 건축의 경우에도 시간이 흐르면 한 층 한 층 올라가는 건물을 볼 수 있다. 심지어 눈에 보이지 않는 전류의 흐름을 이용하는 전자제품의 경우에도 눈에 보이는 무언가를 개발 중에 볼 수 있다. 하지만 소프트웨어의 경우는 그 결과물조차 눈에 보이지 않고 컴퓨터 상에서 동작하는 논리적 결합물일 뿐이고, 이의 개발이 진행되는 동안에는 이 불가시성에 불확실성이 더해지기 마련이다.

보다 원론적으로 건축 전문가들은 모델하우스조차 없는 상황에서 설계도라는 모델만을 가지고 의사를 전달하기도 한다. 소프트웨어 개발에 있어서도 사용자와 개발자간에, 업무 전문가와 개발자간에, 개발자와 개발자간에 정보 전달의 도구로 이런 모델들을 사용할 수 있을 것이다. 실제로 소프트웨어 개발을 위한 수많은 모델들이 개발되었고, 개발되고 있는 상황이다. 하지만 모든 개발자가 제도판과 삼각자를 이용한 모델 작성에 익숙한 것은 아니다. 개발자에게 가장 친숙하고 가까이 있는 도구가 바로 컴퓨터이고 컴퓨터에 이러한 모델링이 가능하도록 능력을 더해주는 소프트웨어가 개발자의 제도판 역할을 해줄 것이다.

먼저 노파심에서 앞서와 같이 모델을 작성하는 경우 건축을 위해 반드시 필요한 설계도에 해당하는 모델과 사용자의 이해를 돕기 위해 작성하는 모델하우스에 해당하는 경우 모두 이의 비용이 공사비에 포함되고 이는 입주자(사용자)가 부담해야 하는 비용이라는 점을 이야기한다. 개발 중에 사용자에게 전달하는 문서의 저작 비용은 무료가 아니라는 점을 꼭 기억하자.

소프트웨어 개발의 경우 이러한 모델에도 건축의 경우와는 또 다른 제약이 존재한다. 실제 물리적 동작을 수행하는 모델보다는 다이어그램의 형태로 작성되는 논리적 모델이 대부분이라는 점이다. 건축을 위한 논리적 모델인 설계도를 누구나 이해하지는 못할 것이다. 마찬가지로 소프트웨어를 가시화해 주는 여러 다이어그램 또한 이를 이해하기 위한 사전 지식을 필요로 한다.특히 일정 수준 교육이 되어 있는 개발자라는 전문가 집단 내부에서 사용되는 다이어그램과 달리 사용자와의 의사소통시 사용되는 다이어그램의 경우에는 비전문가도 알아볼 수 있도록 쉬워야 한다는 필요성도 존재한다.

반면에 ‘동일하거나 유사한 정보를 전달하는 데 이 방법이 답이다’라고 말할 수 있는 방법은 존재하지 않는다. 비교적 최근에 소개된 UML보다 전통적인 플로우차트가 더 유용할 수도 있으며, 경우에 따라서는 정보를 축약한 다이어그램보다 풀어써 놓은 문장이 더 나을 수도 있다. 이렇게 읽기 편한 다이어그램을 작성하기 위한 노력은 경험과 사용자에 대한 이해, 방법론과 다이어그램 자체에 대한 이해, 나아가 인지과학의 영역까지 이야기되어야 할지 모른다. 이번 글은 읽기 편한 다이어그램의 작성이라는 광범위한 주제가 아니라 보다 편하게 다이어그램을 만들 수 있는 소프트웨어들을 살펴보는 것이 목적임을 미리 밝힌다.

비주얼 개발자
어찌 보면 현재의 소프트웨어 개발자는 프로그래밍 언어보다 다양한 다이어그램을 능숙하게 그려낼 수 있는 능력을 갖추어야 할 것으로 보인다. 데이터베이스를 표현하는 ERD, ORM 등의 다이어그램과 네트워크 구성도, 하드웨어 구성도, UML 다이어그램 등 개발자가 전문가로 인정받는 영역뿐 아니라, 일정 관리를 위한 Gannt, PERT/CPM 차트, 비용 산정을 위한 IDEF3, 워크플로우 다이어그램 등 관리 영역, 심지어 프로그램이 속한 업무 영역에 해당하는 다이어그램까지 이해하고 있어야 하며 게다가 사용자 인터페이스의 절반 이상은 개발자의 몫이기도 하다.

소프트웨어와 이의 개발 과정을 가시화하기 어렵다는 난제를 해결하기 위한 노력이 축적된 결과 개발자는 프로그래밍 언어를 능숙하게 다루는 것은 기본이요 남들보다 뛰어난 가시화 능력을 지니고 있어야 한다. 눈으로 들어오는 정보에 남들보다 민감하고 까다로워야 하는 것이 소프트웨어 개발자이고 이 눈높이에 맞추어 남들이 쉽게 알아볼 수 있는-비주얼하다고 표현되는 결과물을 만들 수 있어야 개발자인 셈이다.

이들 중 현재 보편적으로 개발자가 작성할 줄 알아야 하고 읽을 줄 알아야 한다고 여겨지는 UML과 DFD, ERD의 작성이 가능한 프로그램들을 살펴보려 한다. 최근의 CASE(Computer Aided Software Engineering) 도구들은 대부분 이러한 다이어그램의 작성을 지원한다. 글에서 살펴보고자 하는 프로그램들은 CASE라기보다는 소프트웨어와 무관한 다이어그램들을 작성하면서 소프트웨어 관련 다이어그램을 작성할 수도 있는, 어찌 보면 범용 그래픽 프로그램에 해당하는 프로그램이 더 정확한 표현이 될 것이다.

오피스의 핵심으로 떠오른 ‘비지오’
먼저 가장 지명도 높은 다이어그램 작성 프로그램인 비지오를 살펴보자. 비지오의 경우 간단한 제도, 비즈니스 다이어그램, 소프트웨어 다이어그램 영역에서는 명품으로 인정받는 소프트웨어로, 마이크로소프트가 원 제작사를 인수해 오피스 추가 제품군에 포함시킨 제품이다.

앞서 기사에서 살펴볼 프로그램들이 범용 그래픽 소프트웨어로 볼 수 있다는 이야기를 했었다. 비지오 또한 범용 제품이다. 감사, 워크플로우, 업무 흐름도, 조직도 등의 비즈니스 다이어그램과 전기 회로, 사무실 배치도 등의 제도 기능, 그리고 UML을 포함하는 소프트웨어 다이어그램까지 미리 작성된 다양한 스텐실(비지오 전용의 클립아트라 볼 수 있다)을 이용해 드래그 앤 드롭 방식으로 작성할 수 있다. 아울러 원하는 스텐실이 없을 경우에는 얼마든지 새로운 요소를 작성하고 재사용할 수 있는 범용성을 갖추고 있다.

얼핏 생각하면 객체지향 개발을 한다면 비지오의 UML 기능만을 사용하게 될 것 같지만 실제 분석과 설계 단계에서는 소프트웨어 다이어그램에 못지않게 비즈니스 영역의 다이어그램을 이용하게 된다. 일례로 전사적 차원의 개발이 진행된다면 조직 내외의 업무 흐름과 조직 체계를 분석해야만 제대로 된 업무용 소프트웨어를 만들 수 있으니 조직도와 업무 흐름도 등이 요긴하게 사용될 것이다. 이런 시각에서 편의상 비즈니스 다이어그램, 소프트웨어 다이어그램, 기타 다이어그램으로 분류해 먼저 비지오(2003 기준)가 직접적으로 지원하는 소프트웨어 개발 관련 다이어그램을 분류해 살펴보겠다.

백줄 글보다 낫다「다이어그램 작성 프로그램」
<화면 1> 비지오의 사무공정 분류의 다이어그램 선택 화면


업무를 모델링하는 비즈니스 다이어그램
솔직히 ‘이것은 비즈니스 다이어그램에 속한다’라고 정의하는 것은 필자의 능력을 벗어난 일이라 생각한다. 공장자동화를 위한 소프트웨어라면 조직도보다 전기, 배관 등을 포함하는 공정도가 더 유용할 것이다. 주관적인 판단으로 경영학의 냄새가 풍기고 개발의 여러 단계 중 분석 단계에서 업무를 살펴보고 이를 정리할 때 유용하리라 생각하는 다이어그램들을 이 분류에 포함해 보았다.

먼저 비지오는 조직도의 작성을 지원한다. 결과물은 박스로 표시된 부서와 부서원 그리고 이를 이어주는 선으로 구성되지만 원래 조직도라는 것이 조직의 크기에 따라 양적인 차이가 있을 뿐 복잡한 다이어그램은 아닐 것이다. 하지만 그 유용성은 여타 다이어그램에 못지않을 것이다. 이러한 이유에서인지 비지오에서는 조직도가 별도의 다이어그램 범주로 분리되어 있다.

다음으로 사무공정에 해당하는 다이어그램들로 감사 다이어그램, 결함의 체계적 분석 다이어그램, 기본 순서도, 데이터 흐름도(DFD : Data Flow Diagram), 부서간 업무 흐름도, 워크플로우 다이어그램, 인과관계 다이어그램, EPC(Event-Process Chain) 다이어그램, TQM(Total Quality Management) 다이어그램 등의 작성이 지원되며 이들 다이어그램은 사무공정으로 분류되어 있다. 사무를 지원하는 프로그램을 작성하기 위해서는 이러한 다이어그램을 통한 업무 분석이 필요하다는 반증이 될 것이다. 얼핏 DFD는 소프트웨어 다이어그램이고 다른 다이어그램도 제각각의 특성을 지니고 있는 듯한데 이러한 다이어그램들을 사무공정이라는 분류 아래로 모은 이유가 무엇일까? 그 해답은 이 다이어그램들이 6-시그마, ISO-9000에서 사용되는 필수 프로세스들이라는 점이다. 바로 사무공정의 품질을 위해 분석한 정보들을 담는 모델들인 것이다. 보다 나은 품질의 소프트웨어 개발을 위해서는 보다 나은 사무공정의 분석이 필요하고 이 다이어그램들이 이러한 역할을 수행한다.

소프트웨어 설계도 소프트웨어 다이어그램
이제 소프트웨어의 개발 과정에서 목표 소프트웨어를 모델링하기 위해 사용되는 다이어그램들을 살펴보자. 비지오의 경우 MS의 제품답게 COM, OLE 등 자체 기술을 지원하는 모델들이 적지 않게 포함되어 있다. 먼저 데이터 흐름도를 지원한다. 앞서 비즈니스 다이어그램에 포함된 데이터 흐름도의 경우 동그라미와 굽은 화살표로 구성되는 YourDon-DeMarco 표기법의 데이터 흐름도이고, 소프트웨어 다이어그램 분류에 포함된 데이터 흐름도는 Gane-Sarson 표기법의 데이터 흐름도이다. 표기법의 이름은 모두 이를 개발한 사람의 이름이다. 이 둘의 작성법은 유사하나 최근의 CASE 도구나 서적 등에서는 Gane-Sarson 표기법을 사용하는 경우가 많아 보인다.

다음으로는 엔터프라이즈 응용 프로그램 다이어그램이다. 기업의 업무 시스템은 단순히 클라이언트 상에서만 동작하는 프로그램이 아니라 데이터 서버, 미들웨어, 웹 서버, 프록시, 웹 클라이언트, 클라이언트 등 다양한 계층(Tier)으로 구분된 하드웨어 및 소프트웨어들이 네트워크를 통한 유기적 결합 위에서 동작하는 경우가 대부분이다. 이러한 전체 시스템 구성도를 작성할 수 있도록 제공된 템플릿이 엔터프라이즈 응용 프로그램 다이어그램이다.

프로그램 내부의 흐름을 모델링하는 경우 프로그램 구조 다이어그램을 사용한다. 스택, 배열, 힙 등 메모리 구조와 스위치, 호출, 데이터 흐름, 함수 등 언어를 구조화시킨 다이어그램을 작성할 수 있다. 비슷한 용도로 사용할 수 있는 N-S(Nassi-Shneiderman) 차트의 경우도 온라인에서 작성에 필요한 스텐실을 다운받을 수 있다. 소프트웨어 분류에는 이외에 COM과 OLE의 퍼블릭 인터페이스와 이의 호출 관계를 모델링할 수 있는 COM과 OLE 다이어그램, 데이터 구조를 모델링하는 Jackson 다이어그램(창안자의 이름이 마이클 잭슨이다. 가수 마이클 잭슨만큼 유명인사이다), 실시간 시스템 모델링에 사용되는 ROOM 다이어그램을 지원하며, 윈도우 XP 인터페이스를 모델링할 수 있는 스텐실을 제공한다.

소프트웨어 분류의 다이어그램 중 가장 강력한 기능을 맛볼 수 있는 부분이 UML 다이어그램이다. 다이어그램 작성 중 UML 스텐실을 여는 경우 단지 UML에 사용되는 스텐실들을 끌어놓기 할 수 있을 뿐이지만 시작부터 UML작성을 선택하고 다이어그램 작성을 시작하는 경우 CASE 도구로 변모한 비지오를 만날 수 있다. UML에 사용되는 표기, 제약 등이 자동으로 처리되고 다이어그램 구성 요소가 목록으로 만들어지며, 비주얼 베이직, 비주얼 C++ 코드의 포워드, 리버스 엔지니어링도 가능하다.

기타 소프트웨어 개발 관련 다이어그램
비지오에서 사무공정과 소프트웨어 분류 외의 분류에 나누어진 다이어그램들의 경우도 소프트웨어 개발과 무관한 다이어그램들은 아니다. 우선 네트워크 분류의 다이어그램들은 네트워크 장비의 구성과 연결, LDAP, 액티브 디렉토리 등 디렉토리 서비스의 구성을 표현할 수 있다. 다음으로 데이터베이스 분류에는 IDEF1x 표기법의 엔티티 관계도(ERD : Entity Relationship Diagram)와 스키마, 타임, 엔티티, 상수, 함수, 규칙을 요소로 작성되는 Express-G 다이어그램, 객체와 관계 데이터베이스를 모두 지원하고 이들간의 연결고리 역할을 수행할 수 있는 ORM(Object Role Model) 다이어그램이 포함되어 있다.

UML의 경우와 마찬가지로 시작부터 ERD 작성을 선택하고 다이어그램 작성을 시작한 경우 비지오는 ERD를 지원하는 CASE 도구 역할을 수행한다. 데이터베이스로부터 리버스 엔지니어링이 가능하고 변경된 결과를 포워드 엔지니어링으로 데이터베이스에 반영할 수 있다. 이때 데이터베이스의 연결은 데이터베이스의 네이티브 드라이버가 아닌 ODBC, OLEDB를 사용해야 한다. 비주얼 스튜디오에 포함된 비지오 아키텍트 버전의 경우 ORM과 논리적 모델과 물리적 모델간의 자동 변환을 지원한다. 개념적 모델을 ORM으로 작성하고 이를 논리적, 물리적 ERD로 전개하는 것이 가능하다는 이야기이다. 객체지향 개발을 수행할 때 객체의 상태를 영속적으로 보관하는 장소로 관계 데이터베이스를 사용하는 경우 이들간의 불일치를 조정하기 위해 또 다른 ORM(Object-Relational Mapping)을 수행한다. ORM 다이어그램에서 표현되는 관계는 UML에서 사용되는 객체간의 관계를 완벽하게 지원하므로 객체와 관계 데이터베이스간의 맵핑을 수행하는 경우에도 ORM 다이어그램은 유용한 수단이 될 수 있다.

웹 다이어그램 분류의 웹 사이트 개념도와 맵의 경우 웹 사이트의 구성과 서버 구성을 표현할 수 있으며, 프로젝트 일정 분류의 Gannt 차트, PERT 차트 등은 프로젝트의 일정을 점검하고 진행 상태를 시각화하는 데 핵심적인 수단이 되어준다. 이들 일정 관련 차트의 경우 엑셀, 아웃룩, 프로젝트 등 MS 제품들과 연계가 가능하다.

백줄 글보다 낫다「다이어그램 작성 프로그램」
<화면 2> 비지오의 다이어그램 갤러리


끌어놓기만 알면 어떤 다이어그램도 그릴 수 있다 – 스마트 드로우
그림을 편집하는 일이 주 업무인 사람이 포토샵은 필요 없고 자신은 모든 작업을 그림판에서 한다고 주장하는 경우는 없을 것이라 생각한다. ‘글에 능한 자는 붓을 가리지 않는다’라고 하지만 서예 전문가일수록 남들보다 좋은 붓을 가지게 되는 것이 당연한 현상이다. 파워포인트의 그리기 기능으로 못 그릴게 무어냐고 하면 할 말은 없지만 짧은 시간을 투자해 양질의 다이어그램을 작성하는 것이 전문 도구를 선택하는 이유가 될 것이다. 스마트드로우의 경우 비지오에서 작성 가능한 소프트웨어 관련 다이어그램의 대부분을 작성할 수 있다.

ERD나 UML 다이어그램을 작성하는 경우 규칙을 점검해주는 CASE 툴의 기능을 제공하지는 않지만 스마트드로우는 다이어그램을 보다 수월하고 보기 좋게 그릴 수 있게 해주는 전문 다이어그램 도구이다. 비지오와 비교해 특징적인 면은 홈페이지의 튜토리얼에서 확인할 수 있듯이 Catalyst, Fusion, SSADM 등의 방법론을 명시적으로 지원한다는 점이다. UML의 경우도 UML로 ‘Unified’되기 이전의 세 친구(three amigos)의 방법론에 사용되던 다이어그램을 지원한다.
구체적으로 Booch의 OOAD(Object Oriented Analysis and Design), Rumbaugh의 OMT(Object Modeling Technique), Jacobson의 OOSE(Object Oriented Software Engineering)가 이에 해당한다.

UML의 경우 Jacobson의 UseCase 다이어그램을 시발점으로 다이어그램의 작성이 이루어지는 것이 일반적이나 굳이 표준의 UML을 따르지 않고 객체지향 분석 설계를 수행하는 경우나 기존에 이러한 방법론들을 기준으로 작성된 다이어그램들을 재작성하는 경우 등에 이들 다이어그램들을 이용할 수 있을 것이다. 스마트드로우의 GUI 디자인 기능은 비지오를 뛰어넘는 기능들이 제공된다. 비지오의 최신 버전이 윈도우 XP 스타일의 UI를 그릴 수 있는 기능만을 제공하고 있으나 스마트드로우의 경우 매킨토시 UI와 웹 UI를 작성할 수 있는 기능을 제공하고 있다. 비지오의 경우 기본 지원 스텐실에서 빠져버린 N-S 차트의 경우도 스마트드로우의 소프트웨어 기본 심벌에 포함되어 있다.

스마트드로우에서 끌어놓기에 사용되는 클립아트들은 심벌이라 불리며 프로그램 설치시 심벌들을 설치하거나, 설치 후 필요로 하는 심벌을 선택한 경우에 해당 심벌만을 자동으로 설치하는 방식을 지원해 상대적으로 하드디스크의 공간을 많이 차지하는 심벌에 대한 배려를 담고 있기도 하다.

백줄 글보다 낫다「다이어그램 작성 프로그램」   백줄 글보다 낫다「다이어그램 작성 프로그램」
<화면 3> Dia를 이용한 UML 작성 화면   <화면 4> 스마트드로우 홈페이지의 N-S 차트 예제


Gnome판 비지오 Dia
비지오와 스마트드로우가 윈도우 기반의 프로그램이라면 Dia의 경우 Gnome이 동작하는 리눅스, 유닉스 등이 동작하는 환경을 기반으로 하는 프로그램이다. 프로젝트 공식 사이트에서 윈도우의 상업용 프로그램인 비지오와 같은 프로그램이라고 소개하고 있을 정도로 비지오에서 제공되는 기능과 동일하거나 유사한 기능들을 하나하나씩 추가해나가고 있는 프로젝트이다. 현재 버전 0.93이 최신판으로 아직 1.0 버전에 다다르지 않은 프로그램치고는 상당히 잘 알려진 프로그램이다. 윈도우에서 비지오 등으로 작업을 해본 사용자가 리눅스 등을 사용하는 경우의 답답함을 어느 수준 이상 해소해 준 프로그램이라고 할 수 있겠다.

상업용이 아니고 아직 1.0이라는 궤도에 오르지 않은 프로그램이다보니 비지오의 스텐실에 해당하는 셰이프들은 상대적으로 적은 편이다. UML과 ERD, 네트워크 다이어그램, 간단한 회로도, 기본적인 플로우차트가 현재 지원되는 셰이프들이다. Dia에서 작성된 다이어그램과 셰이프들은 XML 형태로 저장된다. 아울러 현재까지는 사용되고 있지 않으나 파이썬 스크립팅 기능을 포함하고 있어 비지오에서 VBA 기반으로 이루어지는 기능들을 구현할 수 있을 것으로 예상되며. 사용자 층이 넓어지면 이러한 XML + 파이썬 스크립팅을 통해 비지오의 CASE 도구 기능들도 구현될 것으로 기대해본다.

<화면 5> 스마트드로우의 피시본(fishbone)-인과 관계다이어그램


다이어그램에 대한 충분한 학습과 이해가 우선과제
안다고 생각하는 것보다는 말로써 이를 이야기하는 것이 어렵고, 말보다 글로써 이를 전하는 것이 어렵고, 남에게 이를 가르치는 것이 더 어렵다고 한다. 결국 무엇인가를 제대로 알았다고 표현하는 수준은 누군가에게 이를 가르칠 수 있어야 하는 수준이라는 생각을 해보게 된다. 이렇게 보면 다이어그램으로 무엇인가를 표현한다는 것은 글로써 전하는 것과 가르치는 수준에 걸쳐 있을 것이다. 글보다 축약되고 정리된 형태가 다이어그램이기 때문이다.

분명한 것은 다이어그램으로 무엇인가를 모델링한다는 수준은 해당 모델링 대상을 알고, 이를 말로 설명하는 수준을 넘어서 글로 정리할 수 있고, 이를 다시 다이어그램의 문법에 맞게 축약할 수 있는 수준일 것이라는 점이다. 이를 위해서는 모델링 대상의 이해만큼 다이어그램의 문법에 대한 학습과 이해가 선행돼야 할 것이다. 도구들은 일반적인 규칙에서 벗어나지 않는 다이어그램을 그릴 수 있는 도구이지 대상과 일치하는 정확한 모델을 그려주는 것은 아니라는 점을 기억하자. @

UML은 무엇을 위해 있는 것일까?

내가 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 종류가 있고, 거래처로부터의 수주에는 상품마다 명세서를 작성한다」라는 일을 아래와 같은 그림으로 표현할 수 있다.

UML은 무엇을 위해 있는 것일까?

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

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

UML은 무엇을 위해 있는 것일까?

그 밖에도 상태나 상태가 변화하는 타이밍을 나타내는 「스테이트 머신(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을 통해 같은 것을 볼 수 있게 되면, 정보의 전달은 더 부드럽게 될 것이다. @