라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
[UML 제대로 알기] ⑤ 표준 넘나드는 UML의「적절한 사용」

[UML 제대로 알기] ⑤ 표준 넘나드는 UML의「적절한 사용」

 

연재순서
1회.
가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

 

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

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

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

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


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

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

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

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

사용자 삽입 이미지
<그림 1> [유스케이스] 다이어그램의 전형적인 예


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

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

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

사용자 삽입 이미지
<그림 2> 액터를 형상화한 모습
여기서 주목해야 할 것은 역할이라는 말이다. 액터의 표기법이 사람 모양을 하고 있어서 사람만이 액터라는 선입견을 가질 수 있는데 사람과는 관계가 없고 그 사람이 수행하는 역할과 더 밀접한 관계가 있다.

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

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


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


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

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

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

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


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


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

사용자 삽입 이미지
<그림 3> 전화로 예약을 받는 시스템


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

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

사용자 삽입 이미지
<그림 4> 유스케이스


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

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

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

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

사용자 삽입 이미지
<그림 5> 포함 관계


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

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

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

사용자 삽입 이미지
<그림 6> 포함 관계의 전형적인 예


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

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

사용자 삽입 이미지
<그림 7> 확장 관계


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

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

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

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

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

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

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

사용자 삽입 이미지
<그림 8> 일반화 관계


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

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

사용자 삽입 이미지
<그림 9> 유스케이스의 레벨 개념


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

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

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

사용자 삽입 이미지
<그림 10> 상위와 하위 레벌 유스케이스


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

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


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


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


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


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

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


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

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


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


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

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

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

 <표 1> [유스케이스] 기술서의 간략화한 양식
사용자 삽입 이미지

유스케이스 25 로그인
주요액터: 사용자
범위: 애플리케이션
레벨: 하위기능
사용자는 시스템에 자신을 알리기 위해 로그인을 한다. 사용자는 사용자이름과 패스워드를 입력한다. 시스템은 사용자를 확인하기 위해 사용자가 제시한 사용자이름과 패스워드를 검증한다. 사용자 이름과 패스워드가 일치하면 시스템은 사용자에게 시스템을 사용할 수 있는 권한을 준다.
만약 사용자가 제시한 사용자이름과 패스워드가 관리자 레벨의 것일 경우 사용자는 시스템을 조작할 수 있는 권한을 함께 부여 받는다.
만약 사용자이름이 존재하지 않거나 패스워드가 틀릴 경우 권한의 부여는 거부되고 사용자는 시스템을 이용할 수 없게 된다.
사용자 삽입 이미지

 <표 2> RUP에서 제시하고 있는 유스케이스 기술서 양식
사용자 삽입 이미지

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…

사용자 삽입 이미지

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

사용자 삽입 이미지
<그림 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을 통해 잘 표현해 보기를 바란다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

이경원 (한국오라클)

2005/04/11

 

[UML 제대로 알기] ④ 닷넷 환경 UML 툴 활용 가이드

 

연재순서
1회.가능성·확장성 품고 등장한 UML 2.0
2회.초보자를 위해 다각도로 살펴본 UML
3회.바로 알고 제대로 쓰는 UML 실전 모델링
4회.닷넷 환경에서 UML 툴 활용 가이드
5회.표준을 넘나드는 UML의 적절한 사용

 

케이스 도구는 양날의 검이다. 활용도에 따라서 소프트웨어를 죽일 수 도 있다. 래쇼날 로즈(이하 로즈) 같은 케이스 도구는 능숙하게 다룰 수 있어야 되기까지 많은 학습 곡선을 필요로 한다. 능숙해진 다음에도 여전히 불편하다.

하지만 IDE와 통합된 케이스 도구는 코드의 자동 생성 등의 많은 편리한 도구를 제공한다. IDE와 통합된 케이스 도구는 UML이라는 것에 너무 얽매이지만 않고 자유롭게만 사용한다면 아주 훌륭한 프로젝트 도우미가 될 수 있다.

전통적으로 MS의 개발 플랫폼에서 사용하는 개발 도구는 MS가 100% 독점하다시피 해 왔다. STL이나 MFC를 개발하거나 사용하는 도구는 거의 비주얼 C++가 독점적이었고, COM 기반의 개발을 위해 사용되는 도구는 거의가 비주얼 베이직이었다(COM 개발을 위해 비주얼 C++를 사용하는 경우도 많이 봤지만 그 당시 이슈가 되던 RAD와는 거리가 먼 환경이었다). 물론 볼랜드의 델파이 등을 많이 사용하기도 했지만 MS의 막강한 개발 도구 비주얼 스튜디오를 넘기에는 벅차 보였다.

닷넷 환경이 발표되고, 닷넷이 산업계에서 서서히 자리를 잡아가자 닷넷 개발 도구의 필요성이 절실해 졌고, 당연히 MS의 비주얼 스튜디오 닷넷이 닷넷 개발 도구의 최강자 자리를 당연히(!) 차지했다. 사실, 비주얼 스튜디오 닷넷이 없으면 닷넷 개발이 불가능하다고 생각하는 사람들도 많다.

볼랜드가 C# 빌더 등의 닷넷 환경을 지원하는 도구를 내 놓았고, 기타 여러 벤더들이 제품을 출시했지만 MS의 아성을 무너트리기에는 역부족이다. 비주얼 스튜디오 닷넷은 닷넷 환경이 존재하는 한 닷넷 기반 IDE의 최강자로서 그 자리를 내놓지는 않을 듯 하다.

그렇다면 비주얼 스튜디오 닷넷에는 약점이 없을까? 아니다, 분명히 약점은 존재한다. 그것도 아주 커다란, 치명적인 약점이 있다. MS는 닷넷 환경을 분명한 객체지향 개발 환경(닷넷 환경에서의 CBD는 객체지향이 없이는 존재할 수 없다)이라고 했다. 객체지향 개발 환경이라면 객체지향 설계 도구가 없다면 그 활용 범위가 반감될 수밖에 없는데, 비주얼 스튜디오 닷넷 엔터프라이즈 아키텍트 버전에 포함된 비지오가 어느 정도 그런 기능을 해 주긴 하지만, 다른 객체지향 개발 도구인 로즈나 볼랜드 투게더(이하 투게더) 등의 편리함과 기능성에는 결코 미치지 못한다.

설계 도구와 개발 도구의 진정한 결합. 이상적인 환경이지만 사실 구현하기 어려운 개발 환경임에 틀림없다. 비주얼 스튜디오 닷넷은 분명 막강한 개발 환경이고, 비주얼 스튜디오 닷넷을 사용하면서 투게더 또는 로즈 같은 개발 도구를 같이 사용할 수는 없을까 하는 생각을 누구나 한번쯤은 해 보았을 것이다. 정말 그럴 수 있을까? 대답은 "물론 있다"이다. 로즈와 투게더는 비주얼 스튜디오 닷넷 XDE를 제공한다(물론 구입해야 한다).

래쇼날 로즈 2000 XDE
객체지향 모델링 도구 중 가장 유명하며, 많이 사용되는 도구인 로즈는 2002년 MS의 비주얼 스튜디오 닷넷에 애드인되어 사용될 수 있는 ‘래쇼날 로즈 2000 XDE for 비주얼 스튜디오 닷넷’을 발표했다(어찌된 일인지 아는 사람도 별로 없고 사용하는 사람은 더더욱 없다). 로즈 XDE를 가지고 있다면 그 자리에서 설치해 보기를 바란다. 물론 설치하는 시스템에 비주얼 스튜디오 닷넷이 설치되어 있어야 한다.

사용자 삽입 이미지
<화면 1> 로즈가 설치된 비주얼 스튜디오 닷넷 2003


로즈를 처음 설치하고 나면 처음엔 아무것도 없다. 도구상자에 뭔가 추가된 것도 아니고, 특별히 뭔가가 설치되었다는 느낌을 받을 수가 없는데(굳이 뭔가 설치되었다는 느낌이라면 아마 비주얼 스튜디오 닷넷의 실행 속도가 눈에 띄게 느려졌다는 느낌이 될 것이다) 솔루션 탐색기를 눈여겨 보면 평소에 볼 수 없던 아이콘이 하나 생겨있음을 알 수 있다. 그 아이콘을 주저 없이 클릭해 보자.

사용자 삽입 이미지
<화면 2> 추가된 동기화 아이콘


동기화 아이콘을 클릭하면 로즈와 비주얼 스튜디오 닷넷이 동기화되어 mdx 파일을 생성한다. 그리고 Model Explorer 창이 새로 생기고 프로젝트에 포함되어 있는 개체들을 탐색할 수 있게 해준다.

사용자 삽입 이미지
<화면 3> 로즈 XDE를 이용하여 Iterator 패턴을 디자인한 모습


로즈를 사용하여 모델링을 어느 정도 마쳤으면, 다시 동기화 버튼을 눌러 순 공학할 수 있다.

사용자 삽입 이미지
<화면 4> 로즈가 생성한 C# 코드


감동의 기능


[1] 너무 깔끔한 코드를 생성하고 닷넷 환경에서 권장하는 주석 내용들을 그대로 생성해준다. 다른 도구들은 생성한 코드의 indentation이 잘 되지 않거나 참조한 라이브러리의 네임 스페이스를 제대로 표시하지 않는 경우가 많은데, 그런 단점이 사라졌다.

[2] 참조한 라이브러리의 개체들을 모두 설계에 사용할 수 있게 해준다. 다른 모델링 도구들은 기본으로 포함되거나 직접 작성한 개체들만이 사용가능 한 경우가 대부분인데, 최상의 도구다운 기능을 보여준다.

[3] 깔끔하고 예쁜 출력을 지원한다. 다른 설계 도구의 경우 한 페이지 또는 두 페이지에 깔끔하게 출력할 수 있는 기능에 대한 지원이 부족한데, 깔끔하고 예쁘장한 산출물을 만들 수 있도록 도와준다.

[4] ASP.NET/ASP/Service Page 들에 대한 설계를 지원한다. Web Presentation Pattern을 응용한 설계가 필요할 때 아주 유용하다.


단점이라면, C#으로 작성한 메쏘드의 수정이 아주 불편하다. 또한, RUP를 너무 강조하는 경향이 있어 닷넷의 빠른 개발과는 어울리지 않는 부분이 엿보이고, 일일이 동기화를 해 주어야 코드와 설계가 연동이 되는데, 에러를 자주 발생하여 동기화가 되지 않는 경우가 빈번히 발생한다.

볼랜드 투게더
비주얼 스튜디오 닷넷에서 다른 유명한 설계 도구인 투게더를 사용할 수 있다. 투게더 역시 로즈와 마찬가지로 비주얼 스튜디오 닷넷에 애드인되어 설치된다. ‘볼랜드 투게더 for 비주얼 스튜디오 닷넷 2.0’을 설치하면 비주얼 스튜디오 닷넷에 투게더 VS.NET Model View라는 창이 생성된다.

사용자 삽입 이미지
<화면 5> 투게더 for 비주얼 스튜디오 닷넷 Model View


또한 솔루션 탐색기에 ModelSupport라는 폴더가 생성되고 폴더 내부에는 .txvpak이라는 확장자를 가지는 모델 파일이 생성된다. 이 파일을 더블클릭하여 모델링 도구를 사용하여 설계할 수 있는 설계 창을 열 수 있다.

사용자 삽입 이미지
<화면 6> 투게더를 사용해서 Iterator 패턴을 디자인 한 모습


투게더는 로즈와 달리, 코드의 실시간 생성을 지원한다. <화면 6>에서 보이는 클래스 아이콘을 더블클릭하면 코드를 곧 바로 생성하게 된다. 코드를 수정하건, 설계를 수정하건 간에 설계 또는 코드의 수정 사항이 즉시 상호간에 적용되게 되어있다.

감동의 기능


[1] 필자가 투게더를 사용해 보고 가장 감동적이었던 기능은 시퀀스 다이어그램을 실시간으로 생성해 주는 기능이었다. 메쏘드가 특정 객체들을 사용하도록 구성되었으면, 투게더는 그 메쏘드의 시퀀스 다이어그램을 아주 믿을만한 수준으로 자동 생성해 준다. <화면 7>은 Petshop 3.0의 AccountController 클래스의 CreateAccount 메쏘드의 시퀀스를 자동 생성한 것이다.


 

사용자 삽입 이미지
<화면 7> 자동 생성한 시퀀스 다이어그램


 


[2] 여러 디자인 패턴에 기반한 설계를 지원한다(로즈 역시 이 기능을 지원한다). GOF 디자인 패턴에 기반하여 설계를 하고자 하면 투게더는 디자인 패턴에서 각 객체들의 역할을 보여주며 각 역할을 하는 객체를 추가하고 삭제하는 Node by Pattern 도구를 지원한다. 투게더는 디자인패턴에 기반한 설계를 쉽고 오류 없이 할 수 있도록 도와주며 특히 디자인 패턴을 공부하는 사람에게 아주 유용한 도구가 될 수 있다.


단점이라면 생성된 코드가 그다지 깔끔하지 않아 재 정렬을 해줘야 한다는 점 등이다. 앞에서 설명한 두 가지 도구의 치명적인 단점이 하나 있다. 닷넷 환경에서는 실행할 때 참조되는 라이브러리를 복사하고 실행시 참조하므로 개발 중 라이브러리를 수정하고 다시 컴파일하여도 누군가 파일을 사용 중이기 때문에 덮어쓸 수 없다는 메시지를 절대로 보여주지 않는다. 하지만 앞의 두 도구는 모델링에 사용하고 있는 참조되는 라이브러리를 ‘물고’있기 때문에 참조하는 프로젝트를 종료하고 컴파일한 후 다시 비주얼 스튜디오 닷넷을 실행하여 계속 진행해야 한다.

그리고 전통적으로 닷넷 개발에서는 RUP 같은 개발 방법론이 사용되지 않아, 만약 UML을 그렇게 많이 사용하지 않는 개발자라거나 다른 개발 방법론을 준수하는(MSF 등의) 프로젝트라면 사용할 수 있는 다이어그램은 클래스 다이어그램뿐이고, 너무 많은 도구를 제공함으로서 개발에 혼란이 오며, 비주얼 스튜디오 닷넷 자체가 너무 느려져서 개발자의 '성질'에 나쁜 영향을 끼칠 수 있다는 것이다.

비주얼 스튜디오 닷넷 2005에 포함된 모델링 도구
MS도 닷넷 환경이 객체지향 환경이고, 객체를 모델링 할 수 있는 통합된 개발 도구가 필요하다는 것을 모를 리가 없다. 그래서 MS는 비주얼 스튜디오 닷넷의 차기 버전인 비주얼 스튜디오 닷넷 2005에 그런 모델링 도구를 추가했다(전체적으로는 투게더와 비슷한 모습이고, 필자가 현재 기사를 작성하고 있는 시점에서는 클래스 다이어그램 기능 이외의 기능은 들어있지 않다).

비주얼 스튜디오 닷넷 2005의 클래스 다이어그램 기능을 알아보자. 비주얼 스튜디오 닷넷 2005는 특별히 이전 버전과 비교해서 달라진 기능이 없다. 웹 프로젝트를 다른 프로젝트와 구분해서 생성하는 정도가 외관상으로 볼 때 달라진 기능이라 할 것이다. 비주얼 스튜디오 닷넷에서 클래스 다이어그램을 그리고 실시간으로 변경될 수 있는 기능을 사용하려 한다면 이전 버전에서 새 항목 추가 메뉴를 선택하는 것과 같이 한다. 새 항목 추가 다이얼로그 박스를 유심히 살펴보면 클래스 다이어그램이라는 항목 아이콘이 보이고 그 항목을 사용하여 클래스 다이어그램을 작성할 수 있다.

사용자 삽입 이미지
<화면 8> 비주얼 스튜디오 닷넷 2005의 새 항목 추가 다이얼로그 박스


 

사용자 삽입 이미지
<화면 9> 비주얼 스튜디오 닷넷 2005를 사용해서 Iterator 패턴을 디자인 한 모습


장점


[1] 아무래도 비주얼 스튜디오 닷넷에 애드인된 것이 아닌 빌트인된 모델링 도구이다 보니 애드인된 도구보다는 강한 결합성을 가진다. 빌트인되었을 때의 가장 큰 기대점은 아무래도 성능적인 측면인데 아직 베타 버전이기에 평가 내리기가 이른 듯 하다. 하지만 꽤 만족할만한 성능을 보여주고 있으며, C# 또는 비주얼 베이직 닷넷에 종속적인 멤버들만을 포함하므로 닷넷 개발에 어울리는 도구가 될 듯 하다.

[2] 비주얼 스튜디오 닷넷에 포함된 도구이다 보니 닷넷 개발에 가장 어울리는 코드를 생성하고 다른 도구들과 통합하여 사용할 수 있다. 닷넷에 추가된 수많은 새로운 개념들과 도구들을 사용할 수 있다.

[3] 비주얼 스튜디오 닷넷에는 지면 관계상 다 소개할 수는 없지만 모델링에 관계된 많은 새로운 도구들이 추가되었다. XML 디자인이나 데이터베이스 디자인, 배포 디자인까지 비주얼 스튜디오 닷넷에서 할 수 있다. 이런 기능들은 평소 비주얼 스튜디오를 사용하던 개발자들에게 아주 친숙한 환경을 제공해 줄 수 있다.


단점이라면, 그 외에 아무것도 없다는 것이다. 또한, 현재 베타 버전에서는 다른 라이브러리에 포함된 개체들을 클래스 다이어그램에 포함하는 인터페이스가 상당히 불편하다. 이는 개선되어야 할 점이다. 사실 투게더나 로즈같은 훌륭한 도구들을 사용하던 입장에서 비주얼 스튜디오 닷넷 2005의 설계 도구를 테스트 하는 입장에서는 전혀 새로울 것도 없고 감동적일 것도 없다.

또한 MS가 자사의 객체지향 개발 방법론을 연구하고 있다는 소문이 풍문에 들려오는 것을 보면, 정식 제품에는 다른 도구가 추가될 지도 모르고, 로즈나 투게더 같은 도구 정도의 많은 기능은 아니더라도 다른 많은 도구들이 추가될 것으로 보인다.

독이 될 수도 갈라드리엘의 별이 될수도
UML은 좋은 도구다. 하지만 대부분의 개발 팀에는 도움이 되기보다는 방해가 되기 일쑤다. UML에는 너무나 많은 것이 있고, 다 활용하기는 벅차고, 그렇다고 사용하지 않기에는 또 뭔가 빠진 듯한 느낌이 드는 것이 그것이다. 늘 절제하는 마음으로 UML을 사용한다면, UML은 아주 좋은 도구가 된다.

필자는 항상 이런 얘기를 한다. "로즈가 설치되어 있는 책상 위에는 항상 연필과 지우개, 그리고 종이가 있어야 한다" 특히 개발자의 입장에서는 UML이라는 도구는 독이 될 때는 한 모금에 사람을 죽일 수도 있는 치명적이 독이 될 수도, 또는 길을 안내해주는 갈라드리엘의 별이 될 수도 있다.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

김상훈 (동명정보대학 정보기술 연구원)

2005/03/31

 

사용자 삽입 이미지

 

원문 :http://www.zdnet.co.kr/techupdate/lecture/etc/0,39024989,39134587,00.htm

  Comments,     Trackbacks