유즈 케이스(Use Case)를 활용한 UML 표기법 입문 | ||||||||||||||||||||||||||||||||||||||
 483  0  0  0 | ||||||||||||||||||||||||||||||||||||||
| 음계를 이용하여 아름다운 음악을 작곡하듯이 UML을 이용하여 좋은 소프트웨어를 개발하는, 이른바 UML 사용의 베스트 프렉티스를 생각해야 한다. 간혹 베스트 프렉티스가 UML 표준을 준수하지 않는 경우도 있는데 중요한 것은 표준 준수 여부가 아니라 어느 것이 더 효과적이냐는 것이다. 성공적인 소프트웨어 개발을 위해서라면 표준을 넘나들 수도 있어야 한다. 이에 이번 글에는 유즈 케이스를 중심으로 UML을 잘 표현하기 위한 시맨틱을 제대로 정리하고 사용하는 방법에 대한 고찰해 보겠다. * UML에서 유스케이스는 액터, 유스케이스, 유스케이스 다이어그램 등을 모두 포함하는 전체를 지칭하는 [유스케이스]와 특정 기능을 설명하는 유스케이스의 두 가지로 쓰인다. 이 글에서는 구분을 위해 전체를 지칭하는 것은 대괄호를 붙여 [유스케이스]로 사용하고 특정 기능을 설명하는 유스케이스는 그냥 유스케이스로 쓰겠다.
[유스케이스]는 시스템이 사용자에 의해서 어떠한 형태로 사용되는지를 기술하는 UML의 표준 표기법이다. 다르게 말하면 시스템이 갖추어야 하는 여러 기능적, 비기능적 요구사항(주로 기능적 요구사항)을 표현하는 방법이 [유스케이스]이다. 이전에도 요구사항을 기술하는 방법은 여러 가지가 있었지만 모델링의 표기법이 UML로 통합되면서 유스케이스가 요구사항을 기술하는 일반적인 방법으로 사용되어 오고 있다. 그런데 [유스케이스]는 표준 표기법임에도 불구하고 UML의 다른 표기법에 비해 그 구성 요소가 적고 그것들을 활용해서 표현하는 방식에 있어서 자유도가 매우 높다. UML의 구성 요소 중 UML 사용의 시맨틱적 요소가 가장 큰 것이 [유스케이스]라 할 수 있다. 유스케이스 사용의 다양한 방식들 중 많은 사람들의 지지를 받고 있는 이른바 베스트 프랙티스를 살펴봄으로써 유스케이스의 효과적인 사용법을 알아보기로 하자. [유스케이스]의 큰 그림 [유스케이스]는 크게 [유스케이스] 모델과 [유스케이스] 기술서로 구성되어 있다. [유스케이스] 모델에 관한 것은 표준에 의해 정의되어 있지만 유감스럽게도 [유스케이스] 기술서는 특별히 표준이라 할 수 있는 것이 없다. 다만 방법론을 다루는 쪽이나 [유스케이스]를 많이 사용해 본 사람들이 [유스케이스] 기술서 작성을 언급할 뿐이다. [유스케이스] 모델은 [유스케이스]의 구성 요소인 액터와 유스케이스, 그리고 그들의 전체적인 관계를 다이어그램의 형태로 가진다. [유스케이스] 모델을 통해 시스템의 전체적인 개요와 구성을 쉽게 알 수 있다. [유스케이스] 모델에 나타난 구성 요소의 세부적인 내용은 [유스케이스] 기술서에 작성한다. [유스케이스] 모델 [유스케이스]는 소프트웨어 시스템이 무엇을 만들어야 하는지, 어떠한 기능을 제공해야 하는지를 기술하는 표기법을 통칭해서 부르는 말이다. [유스케이스]는 시스템을 사용하는 사용자와 내가 만들어야 하는 시스템 자체를 설명하는 방법이다. [유스케이스]에서는 시스템을 사용하는 사용자를 액터(actor)라 하고 시스템의 행동을 유스케이스(use case)라고 한다. 그리고 내가 만들려고 하는 소프트웨어 시스템을 주제영역(subject)이라고 한다. 내가 만들 시스템에 대한 유스케이스들은 주제영역 안에 존재하고 주제영역 밖의 액터와 연결된다. <그림 1>은 [유스케이스] 다이어그램의 전형적인 예이다.
액터라고 해서 모두 사용자를 지칭하는 것만은 아니다. 주제영역으로 정의되는 시스템과 연결되어 상호작용하는 외부 시스템도 액터로 정의한다. 하나의 시스템을 여러 팀이 나누어 개발할 때 다른 팀에서 만든 모듈도 나의 팀의 관점에서 본다면 액터로 정의할 수 있다. 쉽게 말해서 내가 만들어야 하면 유스케이스이고 남이 만들면 액터가 된다. <그림 1>과 같은 [유스케이스] 다이어그램을 통해 시스템이 어떠한 액터들과 상호작용하며 어떤 기능을 액터에게 제공하는 지를 일목요연하게 알 수 있다. [유스케이스] 모델 구성 요소에 대한 세부적인 내용은 [유스케이스] 기술서에 정의하고 [유스케이스] 다이어그램에서는 어떤 [유스케이스] 기술서와 연결되는지 정도를 첨가해 주면 된다. 이는 현존하는 대부분의 UML 모델링 툴이 지원해 주는 기능이다. ‘역할’을 뜻하는 액터 액터는 시스템의 사용자 측면을 정의할 때 사용한다. 액터는 보통 특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 시스템이 수행하는 역할이라고 정의하고 <그림 2>와 같이 표기한다.
여기서 주목해야 할 것은 역할이라는 말이다. 액터의 표기법이 사람 모양을 하고 있어서 사람만이 액터라는 선입견을 가질 수 있는데 사람과는 관계가 없고 그 사람이 수행하는 역할과 더 밀접한 관계가 있다. 액터는 역할에 더 가깝기 때문에 사람 이름보다 직책 이름이 많이 사용된다. 만약 웹사이트 애플리케이션이라면 사이트 회원, 비회원, 관리자 등이 액터로 사용될만한 것들이다. 관심을 갖고 있는 주제영역 시스템과 상호작용하는 외부 시스템도 전형적인 액터이다. 외부 시스템은 주제영역 내의 시스템의 요청에 따라 정보를 제공하는 것이 일반적이다. 전자상거래가 필요한 시스템이라면 외부 시스템으로 신용 정보나 금융 정보 등을 제공하는 시스템을 생각할 수 있고, 여행 상품을 제공하는 시스템이라면 외부 시스템으로 호텔 예약 시스템이나 교통편 예약 시스템 등을 생각할 수 있겠다. 다음은 액터의 전형적인 사례이다. ◆ 사람 : 텔레마케터, 관리자 등
◆ 외부 시스템 : 신용 정보 시스템, 예약 시스템 등 ◆ 장치 : 온도 감응 장치, 출입 통제 장치 등 ◆ 외부 조직 : 금융감독원, 보안 조직 등 ◆ 이벤트 : 매일 밤 12시, 월급날 등 이벤트도 액터? 액터는 시스템의 기능적 요구사항을 정의할 때 매우 유용하게 사용된다. 특히 이벤트 발생 시점과 같은 액터는 시스템의 기능적 요구사항을 정의하는 데 매우 유용하다. 주기적으로 수행되는 배치 작업이 일반화되어 있는 현대의 시스템에서 이벤트 발생 시점은 매우 훌륭한 액터가 된다. 사실 시간과 같은 이벤트를 액터로 해도 되느냐 하는 부분에 대해서는 논란의 여지가 있는 것도 사실이다. 액터는 시스템을 사용함으로써 원하는 목적을 달성하려는 사람 혹은 외부 시스템으로 정의하기도 하는데, 시간 자체는 특별한 목적을 가지지 않기 때문에 액터로 해서는 안 된다고 주장하는 경우도 있다. [유스케이스]는 그 사용에 있어 자유도가 높기 때문에 이러한 논쟁이 유달리 많기도 하다. 중요한 것은 시스템의 요구사항을 [유스케이스]로 정의하고 보다 많은 사람이 그것을 통해 서로의 생각을 얼마나 잘 공유할 수 있느냐는 것이다. 이벤트를 액터로 하는 것은 시스템의 기능 정의에 많은 도움이 된다고 생각한다. 액터의 분류 [유스케이스]의 창시자인 이바 야콥슨은 액터를 주요(primary) 액터와 보조(secondary) 액터의 두 가지로 분류했다. 주요 액터는 시스템에 어떠한 작업의 실행을 요구하는 능동적인 입장의 액터로 유스케이스를 기동하는 역할을 수행한다. 보조 액터는 시스템의 요청에 따라 수동적으로 어떤 작업을 해 주는 액터로써 유스케이스로부터 어떠한 요청이나 메시지를 전달 받는 액터를 말한다. 최근에는 액터를 더 세분화해서 분류하기도 하는데, 액터의 성격에 따라 크게 네 가지로 나눌 수 있다. ◆ 유스케이스를 기동시키는 액터
◆ 시스템의 요청에 따라 정보를 제공하는 외부 액터 ◆ 시스템이 제공하는 정보를 단순히 수신하는 액터 ◆ 다른 액터와 시스템간의 상호 작용을 돕는 프록시 역할의 액터 네 가지 액터 유형 중 특이한 것이 프록시 역할을 하는 액터이다. 액터는 유스케이스와 연결될 뿐 액터와 액터는 서로 연결되지 않게 하는 것이 일반적인 액터의 설계 방식으로 여겨져 왔다. 그러나 액터끼리 서로 연결되게 모델링을 하는 것이 시스템을 좀 더 이해하기 쉽게 만드는 경우도 있다.
<그림 3>은 전화로 예약을 받는 시스템의 예이다. 시스템을 직접 사용하는 사용자는 전화를 받는 창구 직원이 되겠지만 예약이라는 목적을 가지는 것은 고객이기 때문에 고객이 창구 직원에게 전화를 걸어 시스템을 사용하는 것은 <그림 3>처럼 모델링하는 것이 보다 효과적이게 된다. <그림 3>과 같은 시스템은 보통 클라이언트/서버 유형이 애플리케이션인 경우가 많은데 이후 시스템을 웹으로 확장시켜 고객이 직접 웹 사이트를 통해 예약이 가능하도록 하게 되면 창구 직원 액터가 웹을 통한 예약 유스케이스로 변환될 수도 있다. 유스케이스 시스템이 액터에게 주목한 만한 결과를 내놓기 위해 수행하는 여러 작업들의 집합을 유스케이스라고 한다. 즉, 앞서 나온 예약 접수나 구매 주문, 주문 현황 점검과 같은 것들이 유스케이스이다. 유스케이스는 시스템이 수행하는 특정 기능에 대해서 그 기능의 수행을 원하는 액터와 시스템간의 상호 작용과 시스템 내부에서 발생하는 모든 가능한 사항을 기술한다. 유스케이스는 <그림 4>와 같이 표기한다.
유스케이스의 구성 요소는 여러 가지가 있지만 이름과 작업 흐름이 제일 중요하다. 유스케이스 이름은 [유스케이스] 모델에서 중요하고 작업 흐름은 [유스케이스] 기술서에서 중요하다. 유스케이스의 이름을 지을 때는 동사나 동사구의 형태로 능동형을 사용하는 것이 좋다. 유스케이스의 작업 흐름을 기술할 때 유의해야 할 점은 ‘무엇’에 대한 것을 작성해야 한다는 것이다. 간혹 유스케이스가 무엇이 아닌 ‘어떻게’를 기술하게 작성하는 경우가 있는데, 이는 그리 바람직하지 않은 모습이다. 유스케이스는 시스템이 무엇을 제공하고 액터는 무엇을 얻는가를 기술하는 방편이지 시스템을 어떻게 구축할 것인가에 대한 것은 아니다. 유스케이스 간의 관계 유스케이스와 유스케이스 사이에는 서로 밀접하게 연관되어 있어 상호간에 관계를 가지는 경우가 있다. 유스케이스는 포함(include), 확장(extend), 일반화(generalization)의 세 가지 관계 유형이 있다. 포함 관계 하나의 유스케이스가 유스케이스 내의 작업 흐름의 과정 안에 다른 유스케이스의 작업 흐름을 포함하게 하는 관계이다. 포함 관계는 <그림 5>와 같이 표기한다.
유스케이스는 액터와 시스템간의 상호 작용이나 시스템 내부의 작업 등을 기술한다. 이때 여러 유스케이스에서 비슷한 작업이 공통으로 발생하는 경우가 있을 수 있다. 이때 이렇게 공통으로 발생하는 유스케이스의 특정 부분을 하나의 유스케이스로 따로 분리하고 포함 관계를 통해 정의하는 것이 가능하다. 이는 프로그램에서 서브 루틴을 호출하는 개념과 유사하다. 포함 관계에서 유스케이스는 ‘포함하는(including) 유스케이스’와 ‘포함되는(included) 유스케이스’로 나눌 수 있다. 유스케이스는 액터가 그 작업 흐름을 기동시키는데, 포함 관계에서 ‘포함되는 유스케이스’는 액터가 아닌 ‘포함하는 유스케이스’가 작업 흐름을 기동시킨다. 그래서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 없으면 제 구실을 하지 못하고 ‘포함하는 유스케이스’에 합쳐져야 제 기능을 하게 된다. 포함 관계에서 ‘포함되는 유스케이스’를 ‘포함하는 유스케이스’에 포함시킬지 여부는 ‘포함하는 유스케이스’에서 결정한다. 보통 조건절과 같은 내용이 ‘포함하는 유스케이스’에 들어가게 되고 조건절의 만족 여부에 따라 ‘포함되는 유스케이스’를 수행할 지가 결정된다. <그림 6>과 같은 유스케이스가 포함 관계의 가장 전형적인 예이다.
주문 결제 유스케이스는 액터가 결정한 결제 형태에 따라 현금 결제, 카드 결제, 포인트 결제 유스케이스 중에 하나를 포함하게 된다. 포함 관계는 유스케이스 간의 관계를 설정할 때 가장 쉽게 사용할 수 있는 관계 설정 방법이다. 확장 관계 하나의 유스케이스의 흐름이 다름 유스케이스 내의 작업 흐름의 과정에 추가되어 작업 흐름을 확장하는 관계이다. 확장 관계는 <그림 7>과 같이 표기한다.
확장 관계에서 유스케이스는 ‘확장되는 유스케이스’와 ‘확장하는 유스케이스’로 나눌 수 있다. ‘확장되는 유스케이스’가 액터와 상호작용하면서 작업 흐름을 수행하던 중 확장하는 조건이 만족하게 되면 그 만족되는 시점에서 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’에 합쳐져서 작업 흐름을 수행한다. 예를 들면 특정 작업을 수행하던 중 사용자가 도움말 버튼을 눌러서 도움말 내용을 확인하는 것 같은 작업이 전형적인 확장 관계이다. 확장 관계에서는 ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 특정 지점으로 합쳐지게 되는데, 이 지점을 확장 지점(Extension point)이라고 한다. 확장 지점은 ‘확장되는 유스케이스’에 위치하게 되고 ‘확장되는 유스케이스’는 여러 개의 확장 지점을 가질 수 있다. ‘확장하는 유스케이스’가 ‘확장되는 유스케이스’의 어떤 확장 지점으로 확장될 것인가는 확장 관계에 표시한다. 확장 관계는 확장하는 조건과 어떤 확장 지점으로 확장될 것인가에 대한 정보를 보유한다. 유스케이스가 합쳐져서 보다 큰 작업을 한다는 점에서는 포함 관계와 확장 관계가 크게 다를 바는 없지만 그 적용되는 방법과 내용상에 있어서는 몇 가지 차이점이 존재한다. 첫째, 포함 관계는 ‘포함하는 유스케이스’가 주 흐름 유스케이스이고 ‘포함되는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것인 데 반해 확장 관계에서는 ‘확장되는 유스케이스’가 주 흐름 유스케이스이고 ‘확장하는 유스케이스’가 주 흐름 유스케이스에 내용을 추가하는 것이 된다. 둘째, 포함 관계에서 ‘포함되는 유스케이스’는 ‘포함하는 유스케이스’가 정상적으로 동작하기 위해서 반드시 필요한 필수 요소인 데 반해 확장 관계에서 ‘확장하는 유스케이스’는 선택 사항으로써 ‘확장되는 유스케이스’는 ‘확장하는 유스케이스’와 상관없이 독립된 기능을 수행할 수 있다. 보통 유스케이스에 내용을 추가할 때는 포함 관계나 확장 관계 중 어느 방법을 사용하더라도 큰 무리가 없다. 약간의 차이가 있다면 포함 관계로 내용을 추가하려고 할 때에는 내용 추가의 기반이 되는 ‘포함하는 유스케이스’의 내용 변경이 반드시 동반되어야 하는 데 반해 확장 관계로 내용을 추가할 때는 내용 추가의 기반이 되는 ‘확장되는 유스케이스’의 내용 변경이 불필요하다는 것이다. 따라서 이미 존재하는 유스케이스 도큐먼트 내용의 수정이 가능한지 불가능한지 여부가 포함 관계로 내용을 추가할 것인지 확장 관계로 내용을 추가할 것인지를 선택하는 기준이 될 수 있다. 일반화 관계 유스케이스 간의 일반화 관계는 객체 지향 개념에서의 상속 관계와 유사해서 자식 유스케이스가 부모 유스케이스가 가지는 속성, 작업 흐름, 확장 지점, 다른 유스케이스와의 관계 등을 모두 가진다는 의미이다. 일반화 관계는 <그림 8>과 같이 표기한다.
자식 유스케이스는 새로운 작업 흐름이나 별도의 속성, 확장 지점, 다른 유스케이스와의 관계 등을 정의할 수 있다. 하나의 유스케이스는 여러 개의 부모 유스케이스를 가질 수 있고, 자신이 여러 유스케이스의 상위 유스케이스가 될 수도 있다. 유스케이스의 레벨 UML에 정의되어 있는 [유스케이스]의 표준에는 유스케이스에 대한 레벨이나 범위에 대한 개념이 없다. 레벨이나 범위는 유스케이스를 작성하는 과정에서 그 필요성이 자연스럽게 도출된 개념들이다. 레벨이 높은 유스케이스가 넓은 범위의 내용을 광범위하게 다루고 레벨이 낮은 유스케이스가 보다 적은 범위의 내용을 상세히 다룬다. <그림 9>는 유스케이스의 레벨에 대한 개념을 보여준다.
보통 유스케이스의 레벨은 그 유스케이스를 필요로 하는 사람에 따라 다르게 구성된다. 전체 시스템을 개괄적으로 보기를 원하는 매니저나 관리자들은 보다 높은 레벨로 구성된 유스케이스를 필요로 한다. 이들에게는 어떻게 유스케이스가 수행되는가는 주 관심 분야가 아니고 보다 높은 레벨의 관점으로 시스템을 바라보고 싶어 한다. 반면 요구사항 분석을 통해 시스템 전체의 모습을 구성해야 하는 시스템 분석가들은 보다 세부적으로 어떠한 기능을 수행하는지를 볼 수 있는 수준이 필요하다. 반면 개발자들은 요구되는 기능을 어떻게 실제로 구현할 것인지를 정의할 수 있는 수준의 유스케이스를 필요로 한다. 유스케이스를 통해 요구사항에 대한 의사소통을 하는 사람의 역할이 무엇이냐에 따라 유스케이스는 다른 레벨의 형태를 띠게 된다. 유스케이스의 레벨에 관련해서는 ‘왜’라는 물음과 ‘어떻게’란 물음이 중요한 역할을 한다. <그림 10>에서와 같이 유스케이스의 작업 흐름 내용에 대해서 ‘왜’라는 물음에 대한 답이 상위 레벨 유스케이스가 되고 ‘어떻게’라는 물음에 대한 답이 하위 레벨 유스케이스가 된다.
적절한 레벨은? 유스케이스가 많이 사용됨에 따라 유스케이스가 어느 정도의 범위를 커버하도록 구성하는 것이 가장 적절한지에 대한 많은 고민이 있어왔다. 유스케이스를 작성하는 데 있어서 전형적으로 등장하는 좋지 않은 예 중에 하나가 같은 레벨의 유스케이스 간에 상세화 정도의 차이가 생기는 것이다. 같은 레벨의 유스케이스는 비슷한 정도의 범위를 비슷한 상세화 정도로 기술해야 한다. 레벨은 크게 요약(summary), 사용자 목적(user goal), 하위 기능(sub function)으로 나눌 수 있다. 사용자 목적 레벨이 요구사항을 분석하는 데 가장 적절한 수준이다. 사용자 목적 레벨에서 ‘왜’라는 질문을 통해서 내용을 정리하면 요약레벨의 유스케이스가 되고 ‘어떻게’라는 질문을 통해서 내용을 상세화하면 하위 기능 유스케이스가 된다. 사용자 목적 레벨의 유스케이스를 판단할 때 다음과 같은 정도의 기준을 사용할 수 있다. ◆ 액터가 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도의 작업
◆ 작업이 완료되었을 때 액터가 자리를 뜨는데 어려움이 없는 정도 하나의 유스케이스는 사건 흐름에 보통 3~9 스텝 정도를 밟는 것이 좋다. 단 2스텝으로 끝나버린다거나 10스텝 이상으로 길어지는 것은 유스케이스를 이해하는 데 별로 좋지 않다. 만약 스텝이 길다면 다음의 예와 같은 스텝들을 하나의 스텝으로 합쳐서 스텝의 수를 조절할 수 있다. ◆ 같은 액터가 여러 스텝을 점유한 경우
◆ 액터가 사용자 인터페이스를 사용하는 부분을 여러 스텝을 통해 기술한 경우 그래도 스텝이 길다면 그 유스케이스는 너무 큰 유스케이스이거나 너무 상세화된 유스케이스인 경우가 대부분이다. 유스케이스가 크다면 여러 개의 유스케이스로 나누는 것을 고려해야 하고 너무 상세화된 유스케이스라면 ‘왜’라는 질문을 통해 레벨을 높이도록 해야 한다. [유스케이스] 기술서 앞에서 [유스케이스]라고 하는 요구사항 분석 설계 표기법에 사용하는 여러 요소들에 대해 살펴보았다. UML이 [유스케이스]에 대해 표준으로 정의하고 있는 것은 액터나 유스케이스, 유스케이스 간의 관계와 같은 구성 요소와 그들이 서로 어떻게 연계되어 전체적인 모습을 보여주는 지와 같은 것들이다. 이것은 요구사항 분석 설계 메커니즘으로써의 [유스케이스]의 반쪽밖에 되지 않는다. [유스케이스]의 또 다른 반쪽은 [유스케이스] 기술서라고 하는 문서의 형태로 존재하는데, 이는 표준으로 정의되어 있지 않다. 오히려 방법론 등에서 [유스케이스] 기술서를 어떠한 형태로 어떻게 작성해야 하는지를 제시하고 있다. 그래서 다양한 형태의 [유스케이스] 기술서가 정의되어 사용되고 있다. 그러면서 베스트 프랙티스가 정립되면서 표준이라 할 수 있을 정도의 [유스케이스] 기술서가 만들어 졌다. 구성 요소 [유스케이스] 기술서에는 대체로 다음과 같은 내용들이 들어가게 된다. ◆ 이름 : 유스케이스의 이름
◆ 반복 : 반복이 이루어진 횟수. 버전과 유사한 개념 ◆ 액터 : 유스케이스와 관련된 액터들의 목록 ◆ 범위 : 유스케이스가 어떤 수준의 범위를 다루는지에 대한 설명 ◆ 레벨 : 유스케이스가 어느 레벨의 것인지에 대한 설명 ◆ 요약 : 유스케이스가 어떠한 일을 하는 지를 개략적으로 설명하는 내용 ◆ 주 작업 흐름 : 유스케이스가 수행하는 작업의 흐름을 여러 스텝으로 기술한 내용 중 가장 전형적으로 발생하는 것. 유스케이스가 설명하는 업무의 80% 정도가 주 작업 흐름에서 커버한다. ◆ 대안 흐름 : 주 작업 흐름을 따르는 과정에 조건에 따라 다르게 작업하는 것을 기술한 내용 ◆ 예외 흐름 : 작업 흐름이 진행되는 과정에서 예외사항이 발생하였을 경우 어떻게 처리해야 하는 지를 기술한 내용 ◆ 사전 조건 : 유스케이스가 제대로 작동하기 위해 사전에 만족되어야 하는 조건을 기술 ◆ 사후 조건 : 유스케이스가 끝나면 어떠한 결과가 제공되는지를 기술 ◆ 비즈니스 룰 : 유스케이스의 작업 흐름과 관련해서 업무 규칙에 관한 내용을 기술 ◆ 사용자 화면 : 사용자 인터페이스 화면에 대한 내용 ◆ 작성자 : 유스케이스의 작성자 ◆ 작성일 : 유스케이스 작성일 몇 가지의 기술서 작성 양식 앞에서 여러 가지 [유스케이스] 기술서의 구성 요소에 대해서 설명했지만 일반적으로는 [유스케이스] 기술서의 구성 요소들 중 필요한 것을 선별하여 [유스케이스] 기술서 양식을 만들어서 [유스케이스]의 내용을 만드는 데 사용하게 된다. [유스케이스] 기술서의 양식은 프로젝트의 규모나 문서화를 얼마나 세세하게 할 것인지 등을 살펴보고 적합한 수준에서 결정한다. 프로젝트의 규모가 크거나 프로젝트에 대한 위험 부담이 높은 프로젝트에서는 대개 엄격한(rigorous) 방법론을 사용하는 것이 일반적이다. 엄격한 방법론에서는 산출물의 형식이나 내용의 유무를 중요하게 생각한다. [유스케이스] 기술서에도 예외가 아니어서 항목이나 내용이 많고 그 내용을 규칙에 따라 작성하도록 요구한다. 유스케이스의 엄격한 양식에는 앞서 기술한 [유스케이스] 기술서의 구성 요소가 거의 대부분 들어간다. 프로젝트의 규모가 작아서 산출물 작성의 형식에 그리 큰 비중을 두지 않는 경우나 혹은 기민한 방법론을 채택해서 산출물의 신속한 작성과 변경이 요구되는 경우는 [유스케이스] 기술서의 형식을 간략하게 사용하는 경우도 있다. <표 1>은 간략화한 양식의 예이다.
점증적이며 반복적인 작성 프로세스 소프트웨어 개발 방법론에서는 점증적·반복적 접근이 많이 사용되는데 [유스케이스]의 작성에도 예외는 아니다. 대부분의 [유스케이스] 작성 프로세스가 반복을 통해 점증적으로 [유스케이스]의 내용을 추가하는 방식을 취하고 있다. <그림 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을 통해 잘 표현해 보기를 바란다.@ Tags: RUP UML usecase 개발자 결제 관계 다이어그램 레벨 모델링 모듈 부모 사용자 상속 액터 예산 외부 요구사항 요소 윈도우즈 유스케이스 유즈케이스 음계 이벤트 일반화 작곡 정의 주문 표기법 프록시 
 | ||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
| Login for comment |
31437 
