으로써 그 자리를 확고히 했다. 이제는 한 걸음 더 나아가 을 보다 효과적으로 사용할 수 있는 방법을 생각해 볼 때이다. 를 이용하여 아름다운 음악을 하듯이 을 이용하여 좋은 소프트웨어를 개발하는, 이른바 사용의 베스트 프렉티스를 생각해야 한다. 간혹 베스트 프렉티스가 을 준수하지 않는 경우도 있는데 중요한 것은 준수 여부가 아니라 어느 것이 더 효과적이냐는 것이다. 성공적인 소프트웨어 개발을 위해서라면 을 넘나들 수도 있어야 한다. 이에 이번 글에는 유즈 케이스를 중심으로 을 잘 표현하기 위한 시맨틱을 제대로 정리하고 사용하는 방법에 대한 고찰해 보겠다.
* 에서 , , 등을 모두 포함하는 전체를 지칭하는 []와 특정 기능을 설명하는 의 두 가지로 쓰인다. 이 글에서는 구분을 위해 전체를 지칭하는 것은 대괄호를 붙여 []로 사용하고 특정 기능을 설명하는 는 그냥 로 쓰겠다.
[]는 시스템이 에 의해서 어떠한 형태로 사용되는지를 기술하는 이다. 다르게 말하면 시스템이 갖추어야 하는 여러 기능적, 비기능적 (주로 기능적 )을 표현하는 방법이 []이다. 이전에도 을 기술하는 방법은 여러 가지가 있었지만 로 통합되면서 을 기술하는 일반적인 방법으로 사용되어 오고 있다. 그런데 []는 임에도 불구하고 의 다른 에 비해 그 구성 가 적고 그것들을 활용해서 표현하는 방식에 있어서 자유도가 매우 높다. 의 구성 사용의 시맨틱적 가 가장 큰 것이 []라 할 수 있다. 사용의 다양한 방식들 중 많은 사람들의 지지를 받고 있는 이른바 베스트 프랙티스를 살펴봄으로써 의 효과적인 사용법을 알아보기로 하자. []의 큰 그림 []는 크게 [] 모델과 [] 기술서로 구성되어 있다. [] 모델에 관한 것은 에 의해 되어 있지만 유감스럽게도 [] 기술서는 특별히 이라 할 수 있는 것이 없다. 다만 방법론을 다루는 쪽이나 []를 많이 사용해 본 사람들이 [] 기술서 작성을 언급할 뿐이다. [] 모델은 []의 구성 , 그리고 그들의 전체적인 의 형태로 가진다. [] 모델을 통해 시스템의 전체적인 개요와 구성을 쉽게 알 수 있다. [] 모델에 나타난 구성 의 세부적인 내용은 [] 기술서에 작성한다. [] 모델 []는 소프트웨어 시스템이 무엇을 만들어야 하는지, 어떠한 기능을 제공해야 하는지를 기술하는 을 통칭해서 부르는 말이다. []는 시스템을 사용하는 와 내가 만들어야 하는 시스템 자체를 설명하는 방법이다. []에서는 시스템을 사용하는 (actor)라 하고 시스템의 행동을 (use case)라고 한다. 그리고 내가 만들려고 하는 소프트웨어 시스템을 주제영역(subject)이라고 한다. 내가 만들 시스템에 대한 들은 주제영역 안에 존재하고 주제영역 밖의 와 연결된다. <그림 1>은 [] 의 전형적인 예이다.  
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 1> [] 의 전형적인 예
  라고 해서 모두 를 지칭하는 것만은 아니다. 주제영역으로 되는 시스템과 연결되어 상호작용하는 시스템도 한다. 하나의 시스템을 여러 팀이 나누어 개발할 때 다른 팀에서 만든 도 나의 팀의 관점에서 본다면 할 수 있다. 쉽게 말해서 내가 만들어야 하면 이고 남이 만들면 가 된다. <그림 1>과 같은 [] 을 통해 시스템이 어떠한 들과 상호작용하며 어떤 기능을 에게 제공하는 지를 일목요연하게 알 수 있다. [] 모델 구성 에 대한 세부적인 내용은 [] 기술서에 하고 [] 에서는 어떤 [] 기술서와 연결되는지 정도를 첨가해 주면 된다. 이는 현존하는 대부분의 툴이 지원해 주는 기능이다. ‘역할’을 뜻하는 는 시스템의 측면을 할 때 사용한다. 는 보통 특정 작업을 완수할 목적으로 시스템과 상호 작용하는 사람이나 시스템이 수행하는 역할이라고 하고 <그림 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>
  자식 는 새로운 작업 흐름이나 별도의 속성, 확장 지점, 다른 와의 등을 할 수 있다. 하나의 는 여러 개의 를 가질 수 있고, 자신이 여러 의 상위 가 될 수도 있다. 되어 있는 []의 에는 에 대한 이나 범위에 대한 개념이 없다. 이나 범위는 를 작성하는 과정에서 그 필요성이 자연스럽게 도출된 개념들이다. 이 높은 가 넓은 범위의 내용을 광범위하게 다루고 이 낮은 가 보다 적은 범위의 내용을 상세히 다룬다. <그림 9>는 에 대한 개념을 보여준다.  
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 9> 개념
  보통 은 그 를 필요로 하는 사람에 따라 다르게 구성된다. 전체 시스템을 개괄적으로 보기를 원하는 매니저나 관리자들은 보다 높은 로 구성된 를 필요로 한다. 이들에게는 어떻게 가 수행되는가는 주 관심 분야가 아니고 보다 높은 의 관점으로 시스템을 바라보고 싶어 한다. 반면 분석을 통해 시스템 전체의 모습을 구성해야 하는 시스템 분석가들은 보다 세부적으로 어떠한 기능을 수행하는지를 볼 수 있는 수준이 필요하다. 반면 들은 요구되는 기능을 어떻게 실제로 구현할 것인지를 할 수 있는 수준의 를 필요로 한다. 를 통해 에 대한 의사소통을 하는 사람의 역할이 무엇이냐에 따라 는 다른 의 형태를 띠게 된다. 에 관련해서는 ‘왜’라는 물음과 ‘어떻게’란 물음이 중요한 역할을 한다. <그림 10>에서와 같이 의 작업 흐름 내용에 대해서 ‘왜’라는 물음에 대한 답이 상위 가 되고 ‘어떻게’라는 물음에 대한 답이 하위 가 된다.  
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
<그림 10> 상위와 하위 레벌
  적절한 은? 가 많이 사용됨에 따라 가 어느 정도의 범위를 커버하도록 구성하는 것이 가장 적절한지에 대한 많은 고민이 있어왔다. 를 작성하는 데 있어서 전형적으로 등장하는 좋지 않은 예 중에 하나가 같은 간에 상세화 정도의 차이가 생기는 것이다. 같은 는 비슷한 정도의 범위를 비슷한 상세화 정도로 기술해야 한다. 은 크게 요약(summary), 목적(user goal), 하위 기능(sub function)으로 나눌 수 있다. 목적 을 분석하는 데 가장 적절한 수준이다. 목적 에서 ‘왜’라는 질문을 통해서 내용을 정리하면 요약가 되고 ‘어떻게’라는 질문을 통해서 내용을 상세화하면 하위 기능 가 된다. 목적 를 판단할 때 다음과 같은 정도의 기준을 사용할 수 있다.
가 한자리에 앉아서 한번(2분~20분)에 끝낼 수 있는 정도의 작업 ◆ 작업이 완료되었을 때 가 자리를 뜨는데 어려움이 없는 정도
하나의 는 사건 흐름에 보통 3~9 스텝 정도를 밟는 것이 좋다. 단 2스텝으로 끝나버린다거나 10스텝 이상으로 길어지는 것은 를 이해하는 데 별로 좋지 않다. 만약 스텝이 길다면 다음의 예와 같은 스텝들을 하나의 스텝으로 합쳐서 스텝의 수를 조절할 수 있다.
◆ 같은 가 여러 스텝을 점유한 경우 ◆ 인터페이스를 사용하는 부분을 여러 스텝을 통해 기술한 경우
그래도 스텝이 길다면 그 는 너무 큰 이거나 너무 상세화된 인 경우가 대부분이다. 가 크다면 여러 개의 로 나누는 것을 고려해야 하고 너무 상세화된 라면 ‘왜’라는 질문을 통해 을 높이도록 해야 한다. [] 기술서 앞에서 []라고 하는 분석 설계 에 사용하는 여러 들에 대해 살펴보았다. 이 []에 대해 으로 하고 있는 것은 , 간의 와 같은 구성 와 그들이 서로 어떻게 연계되어 전체적인 모습을 보여주는 지와 같은 것들이다. 이것은 분석 설계 메커니즘으로써의 []의 반쪽밖에 되지 않는다. []의 또 다른 반쪽은 [] 기술서라고 하는 문서의 형태로 존재하는데, 이는 으로 되어 있지 않다. 오히려 방법론 등에서 [] 기술서를 어떠한 형태로 어떻게 작성해야 하는지를 제시하고 있다. 그래서 다양한 형태의 [] 기술서가 되어 사용되고 있다. 그러면서 베스트 프랙티스가 정립되면서 이라 할 수 있을 정도의 [] 기술서가 만들어 졌다. 구성 [] 기술서에는 대체로 다음과 같은 내용들이 들어가게 된다.
◆ 이름 : 의 이름 ◆ 반복 : 반복이 이루어진 횟수. 버전과 유사한 개념 ◆ : 와 관련된 들의 목록 ◆ 범위 : 가 어떤 수준의 범위를 다루는지에 대한 설명 ◆ : 가 어느 의 것인지에 대한 설명 ◆ 요약 : 가 어떠한 일을 하는 지를 개략적으로 설명하는 내용 ◆ 주 작업 흐름 : 가 수행하는 작업의 흐름을 여러 스텝으로 기술한 내용 중 가장 전형적으로 발생하는 것. 가 설명하는 업무의 80% 정도가 주 작업 흐름에서 커버한다. ◆ 대안 흐름 : 주 작업 흐름을 따르는 과정에 조건에 따라 다르게 작업하는 것을 기술한 내용 ◆ 예외 흐름 : 작업 흐름이 진행되는 과정에서 예외사항이 발생하였을 경우 어떻게 처리해야 하는 지를 기술한 내용 ◆ 사전 조건 : 가 제대로 작동하기 위해 사전에 만족되어야 하는 조건을 기술 ◆ 사후 조건 : 가 끝나면 어떠한 결과가 제공되는지를 기술 ◆ 비즈니스 룰 : 의 작업 흐름과 관련해서 업무 규칙에 관한 내용을 기술 ◆ 화면 : 인터페이스 화면에 대한 내용 ◆ 작성자 : 의 작성자 ◆ 작성일 : 작성일
몇 가지의 기술서 작성 양식 앞에서 여러 가지 [] 기술서의 구성 에 대해서 설명했지만 일반적으로는 [] 기술서의 구성 들 중 필요한 것을 선별하여 [] 기술서 양식을 만들어서 []의 내용을 만드는 데 사용하게 된다. [] 기술서의 양식은 프로젝트의 규모나 문서화를 얼마나 세세하게 할 것인지 등을 살펴보고 적합한 수준에서 결정한다. 프로젝트의 규모가 크거나 프로젝트에 대한 위험 부담이 높은 프로젝트에서는 대개 엄격한(rigorous) 방법론을 사용하는 것이 일반적이다. 엄격한 방법론에서는 산출물의 형식이나 내용의 유무를 중요하게 생각한다. [] 기술서에도 예외가 아니어서 항목이나 내용이 많고 그 내용을 규칙에 따라 작성하도록 요구한다. 의 엄격한 양식에는 앞서 기술한 [] 기술서의 구성 가 거의 대부분 들어간다. 프로젝트의 규모가 작아서 산출물 작성의 형식에 그리 큰 비중을 두지 않는 경우나 혹은 기민한 방법론을 채택해서 산출물의 신속한 작성과 변경이 요구되는 경우는 [] 기술서의 형식을 간략하게 사용하는 경우도 있다. <표 1>은 간략화한 양식의 예이다.
 <표 1> [] 기술서의 간략화한 양식
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
25 로그인 주요: 범위: 애플리케이션 : 하위기능 는 시스템에 자신을 알리기 위해 로그인을 한다. 이름과 패스워드를 입력한다. 시스템은 를 확인하기 위해 가 제시한 이름과 패스워드를 검증한다. 이름과 패스워드가 일치하면 시스템은 에게 시스템을 사용할 수 있는 권한을 준다. 만약 가 제시한 이름과 패스워드가 관리자 의 것일 경우 는 시스템을 조작할 수 있는 권한을 함께 부여 받는다. 만약 이름이 존재하지 않거나 패스워드가 틀릴 경우 권한의 부여는 거부되고 는 시스템을 이용할 수 없게 된다.
 
유즈 케이스(Use Case)를 활용한 UML 표기법 입문
 <표 2> 에서 제시하고 있는 기술서 양식
유즈 케이스(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단계도 앞서 설명한 작업 절차와 그리 큰 차이는 보이지 않는다. 중요한 것은 반복적으로 점증적으로 []를 작성해 나간다는 것이다. 을 제대로 사용하려면 이것은 기억하자 [] 모델과 [] 기술서 등 []와 관련한 여러 가지를 살펴보았다. 이제는 []와 관련해서 유의해야 할 점을 짚어 보기로 하자. 의 연결 에는 의 연결에 단순한 직선 연결만을 사용하고 있는데 화살표를 사용해서 나름의 의미를 부여하는 경우도 있다. 다음은 화살표 사용의 몇 가지 사례이다.
◆ 주요 를 기동하는 경우에만 에서 쪽으로 화살표 머리 사용 ◆ 주요 를 기동하거나 가 보조 를 기동하는 경우 기동하는 쪽으로 화살표 머리 사용. ◆ 단 방향 커뮤니케이션에만 화살표 머리 사용. 기대되는 응답이 없는 경우에 사용한다(예 : 프린터로 명령을 보내는 경우, 정부 기관에 내용을 통보하는 경우)
[] 에서 화살표를 사용할 때에는 데이터의 흐름이 아니라 커뮤니케이션의 기동 방향을 보여주는 데 사용하는 것이 좋다. 데이터는 보통 사이에 양방향으로 흐르는 것이 일반적이기 때문에 데이터의 흐름으로 화살표를 사용하게 되면 양방향 화살표가 되게 되고 이것은 을 어지럽히는 원인이 된다. 전통적인 실수들 []를 작성하는 데 있어서 다음과 같은 실수가 자주 발생한다.
가 없는 , 시스템이 없는 는 반드시 서로 연결되어 있어야 한다. ‘포함되는 ’나 ‘확장하는 ’의 경우도 포함 또는 확장되어 와 연결된다. 간혹 혼자 동떨어져 있는 가 있는 시스템이 보이기도 하는데 이는 잘못 작성된 것이다.◆ 인터페이스의 내용을 너무 상세히 담고 있는 [] []는 기능적 을 담는 것이기 때문에 인터페이스의 상세한 내용은 담지 않는다. 다만 인터페이스를 상세하게 설명한 문서에 대한 참조 정도를 추가하면 된다. ◆ 너무 낮은 의 [] 구현에 대한 상세한 내용이 담겨 있는 []는 적절하지 않다. []에 소스코드 의 설명이 들어 있는 경우가 간혹 있는데 ‘왜’라는 물음을 통해 상위의 []로 만드는 것이 좋다. ◆ 전산인의 언어를 사용한 []는 을 기술하고 그것을 통해 여러 관여자 들과 의사소통을 하기 위해 만드는 것이다. []에 사용하는 용어는 많은 사람이 이해할 수 있도록 보편적인 용어를 사용해야 한다. ◆ 애플리케이션 관점의 의 관점에서 기술해야 한다. 시스템의 관점에서 기술한 는 적절하지 않다. ◆ ‘~해야 한다’ 식의 표현 을 기술하는 전통적인 방법에서는 ‘시스템은 ~해야 한다’는 식의 표현이 자주 등장한다. 이러한 표현을 []에서는 사용하지 않는 것이 좋다. 만약 고객의 요구로 ‘~해야 한다’는 식의 표현을 넣어야 한다면 []의 요약 부분에 넣는 것이 좋다. 작업 흐름 부분에는 ‘~해야 한다’가 아닌 ‘~한다’라는 표현을 사용해야 한다.
작성에 대한 10가지 잘못 [1] 다른 형태의 문서는 만들 필요가 없다. []면 을 충분히 반영할 수 있다. 아니다. 문서는 을 가장 잘 반영할 수 있는 형태의 문서로 만들어야 한다. 데이터베이스 설계에 대한 은 ER모델이 적합하고, 화면 구조에 대한 은 그래픽이 가미된 문서가 더 적합하다. [2] 읽는 사람이 []의 목적에 대해 이해하기 힘들게 한다. []의 이름을 지을 때 ‘작업하다’, ‘처리하다’와 같은 말을 사용하여 혼란스럽게 한다. 만약 읽는 사람을 혼란스럽게 하는 데 성공했다면 []를 실제로 구현할 때 어떻게 해도 상관없을 것이다. []를 이용해서 효과적으로 소프트웨어 시스템을 구현하기 위해서는 명확하게 []를 작성할 필요가 있다. 간혹 어떻게 []를 작성해야 하는지 모르는 경우에 이렇게 처리하는 경우가 있는데 좋지 않은 모습이다. [3] []의 범위에 대해 혼란스럽게 한다. 범위는 어차피 점점 퍼져나갈 것이고 나중에 리펙토링을 하면 된다. 는 어차피 생각을 계속 바꿀 것인데 왜 성가시게 범위를 미리 확정하겠는가? []는 만들려고 하는 시스템이 어떠한 범위를 다루는지를 표현하는 것에도 사용된다. 시스템의 범위를 명확히 하고 그것을 여러 관여자가 충분히 이해할 수 있도록 []를 작성해야 한다. [4] [] 기술서에 비기능적 인터페이스 디테일을 포함시킨다. 의 작업 흐름에 인터페이스에 대한 세부 내용을 포함시키면 작업 흐름이 늘어나게 된다. 인터페이스를 요약한 내용을 추가하면 되지 상세한 내용까지는 포함시킬 필요가 없다. [5] 초기 [] 에 포함 와 확장 를 많이 사용한다. 그러면 를 작은 단위의 것으로 나눌 수가 있다. 초기 버전의 는 상위를 작성하고 반복을 거치면서 보다 상세화한 를 작성하는 것이 좋다. CRUD를 처리하는 가 대표적인데, 초기에는 ‘관리하다’라는 로 하나로 만들고 이후에 반복을 통해 ‘생성’, ‘조회’, ‘수정’, ‘삭제’ 로 세분화한다. [6] 비즈니스 룰을 하는 것에는 관여하지 말라. 비즈니스 룰을 만들고 사용하는 것은 이지만 그것을 산출물로 표현하도록 하는 것은 매우 중요하다. 룰 자체를 만드는 것에는 관여할 필요가 없지만 그것을 []를 통해 표현하도록 독려해야 한다. [7] []의 작성에 도메인 전문가를 관여시키지 말라. 그들은 질문이나 해댈 뿐이다. []는 에 대한 인데, 소프트웨어 시스템에 대한 을 가장 잘 알고 있는 것은 도메인 전문가이다. 물론 이들이 작업을 성가시게 할 수도 있지만 좋은 결과를 내기 위한 고통이라 생각해야 한다. [8] 만약 를 [] 에 관여시킨다면 그냥 그래라. 왜 와의 미팅을 준비하는 데 골머리를 썩힐 것인가? 많은 양의 문서나 만들게 되고, 어쨌든 그들은 계속 마음을 바꾸게 될 것이다. 될대로 되라는 식의 태도는 좋지 않다. 에게 []를 충분히 이해시키고 []를 통해 효과를 볼 수 있도록 노력해야 한다. [9] []를 한 번에 아주 상세하게 만들어라. 반복적으로 점증적으로 []를 작성하는 것이 좋다. [10] []를 검증하거나 평가하지 말라. 재작업이나 만들어 낼 뿐이다. 반복적으로 점증적으로 작성하고 중간중간 계속 나 도메인 전문가의 피드백을 받아야 한다. 아름다운 표현 양식이 되길 바라며 을 수집하는 일은 오래 걸리거나, 잘못된 것을 기록하거나, 발생하지 않을 일을 추측하거나, 시간에 맞춰 허겁지겁 끝내는 등과 같은 결과를 초래하는 경우가 많다. 이는 수집이 비생산적인 경로를 거치거나, 수집을 무시하거나, 수집 자체만을 위해 매달리거나, 을 한 사람이 결정하기 때문에 발생한다. []는 이러한 수집에 사용하기 좋은 방법 중 하나이다. []의 을 따라 보편화된 방법으로 을 기술하면 보다 많은 사람들이 사용할 수 있을 것이다. 물론 에 대한 준수 여부보다는 []의 내용을 어떠한 생각을 가지고 채워 넣었느냐가 더욱 중요하다. 은 단순한 에 지나지 않지만 아주 좋은 임에는 틀림없다. 마치 한글처럼. 아름다운 우리말을 한글이 잘 표현하듯이 소프트웨어 개발에 대한 여러분의 멋진 생각들을 을 통해 잘 표현해 보기를 바란다.@

facebook posting twit

  • UPnP 프로토콜 개요
  • UPnP 네트워크의 구성요소
  • UPnP의 작동 방법
  • DLNA, UPnP 개요
  • 원격 부팅(Wake on-LAN : WOL)
  • 백줄 글보다 낫다「다이어그램 작성 프로그램」
  • UML은 무엇을 위해 있는 것일까?
  • 타임아웃 시간줄이기
  • XP 윈도우 창 속도 높이기
  • Windows XP에서 윈도우 창이 뜨는 속도를 높이는 방법
    Tagged on:                                                                                                             
  • Leave a Reply