UseCase Diagram

유즈케이스란 "어떤 대상을 사용하는 한가지 사례, 방식" 이라는 의미입니다.
그래서 유즈케이스들을 모두 모아 놓으면 결국 그 대상을 사용하는 방법의 모든 것,
즉 대상이 제공하는 모든 서비스의 집합이 됩니다.

그런 의미에서 유즈케이스 다이어그램은 전자상가에서 볼 수 있는 상품의
주요기능을 적어놓은 선전용 전단과 유사한 의미를 가집니다. 유즈케이스
다이어그램은 사용자가 나중에 인도받게 될 SW시스템의 기능과 서비스의 내용을
직관적으로 파악할 수 있게 합니다.

누구나 알 수 있는 그림의 형태로 이 모든 것이 정의되기 때문에 SW에 대한 지식이
없는 사용자들이 쉽게 이해하고 동의할 수 있습니다.

자 그럼 유즈케이스 다이어그램의 세계로 떠나 볼까요 ?

 

 1. 개요

 

UML의 9개 다이어그램은 각기 독립적인 의도와 목적으로 사용됩니다. 그렇기 때문에 어떤 다이어그램부터 공부해야 하는가 하는 순서는 없다고 할 수 있습니다. 하지만 대부분의 UML관련 교재나 자료에서 유즈케이스 다이어그램을 UML의 여러 다이어그램 중에서 제일 먼저 소개합니다. 왜 그럴까요 ? 유즈케이스 다이어그램을 가장 먼저 공부해야 하는 이유는 다음과 같습니다. 유즈케이스 다이어그램은 대개의 경우 다른 다이어그램들보다 먼저 작성됩니다. 유즈케이스 다이어그램은 다른 다이어그램을 작성할 때의 기준이 됩니다. 다른 다이어그램들은 유즈케이스 다이어그램에서 정의한 내용을 보다 상세하고 구체적으로 추가 정의하는 형태로 작성될 때가 많습니다. 유즈케이스 다이어그램은 다른 UML 다이어그램들과 유기적인 관계를 가지고 있습니다. 현장에서 UML을 적용할 때의 중요한 성공요인은 모델링과정에서 항상 이러한 유기적인 관계를 염두에 두고 모델간의 의미적, 문법적 일관성을 유지하는 것입니다. 즉, UML의 9개 다이어그램은 각기 고유의 목적이 있어 독립적이며, 특성에 맞게 적용하면 되지만, 종합적인 면에서 서로 유기적인 연관성을 가진다는 것도 알아두시기 바랍니다.

유즈케이스 다이어그램은 "사용자의 시각에서 SW 시스템의 범위와 기능을 쉽게 설명하고 정의한 모델"입니다. 또한 "SW 시스템의 기능적 요구사항에 대한 베이스라인"입니다. 유즈케이스 다이어그램은 건물을 짓기전에 미리 건물의 설계도를 작성하는 것처럼 나중에 완성될 SW 시스템의 모습을 개념적으로 정의하여 여러 관련자들과 의견을 나누고 합의하는 과정에서 사용됩니다. 우리는 이 유즈케이스 다이어그램을 통해 이후 완성될 SW 시스템의 모습을 상상하는 최초의 시도를 하게 되는 것입니다.

유즈케이스 다이어그램을 작성하는 시기는 SW개발 프로젝트를 시작하는 시기입니다. 구체적으로 프로젝트 개발 초기단계 중에서도 다음과 같은 시점에 유즈케이스 다이어그램을 작성하게 됩니다. SW 프로젝트의 개발 범위를 정의하는 단계 SW에 대한 요구사항을 정의하는 단계 SW의 세부기능을 분석하는 단계 SW가 아닌 업무영역(Business Domain)을 이해하고 분석하는 단계 특히  의 경우는 작성내용이 SW의 기능이 아닌 업무지식를 내용으로 하고 있기에 "비즈니스 유즈케이스 다이어그램"이라고 합니다. 이러한 유즈케이스 다이어그램을 작성하기 전에 먼저 선행되어야 할 사항은 시스템에 대한 사용자의 요구사항이 수렴되고 정의되어야 합니다.

   2. 구성요소 : 액터와 유즈케이스

 

           

 

	유즈케이스 다이어그램의 구성요소는 다음과 같습니다.

	액터의 표기 액터는 왼쪽과 같은 사람모양의 그림입니다. 작대기로 만든 사람이라는 의미로 "스틱맨"이라는 애칭으로 부르기도 합니다. 스틱맨의 아래에 액터의 이름을 명사로 표시합니다. 액터의 정의, 의미 액터는 시스템의 외부에 존재하면서 시스템과 교류 혹은 상호작용(interaction) 하는 것입니다. 액터는 자신에 대해 시스템이 서비스를 해 주기를 요청하는 존재들이고 , 시스템이 정보를 제공하는 대상이기도 합니다. 액터는 시스템의 일부가 아니라 외부에 독립적으로 존재합니다. 시스템의 사용자로서, 액터는 다음의 3가지 부류로 나눌 수 있습니다. ※ 아래의 각 그림을 클릭하세요. SW의 사용자 혹은 SW가 제공하는 정보를 얻는 사람 SW와 상호작용하는 외부의 독립된 SW 시스템 SW로 정보를 주고, 받는 하드웨어 장치
	액터명 정의시 주의사항 액터가 사람일 경우는 액터 명은 직책이나 조직,개인 이름이 아닌 그 사람의 역할(Role)입니다. 즉, 결재 시스템에서 결재하는 사람이 액터로 식별되었다면 그 이름은 팀장이 아닌, 결재하는 사람의 역할로서 "결재자"가 액터 명이 되어야 합니다.

액터의 예 결재 시스템에서 : 상신자, 합의자, 결재자, 통보자 전자 상거래 시스템에서 : 회원, 구매자, 배달자, 관리자, 배송시스템, 결재시스템 병원관리시스템에서 : 의사, 간호사, 환자, 수납책임자, 약사 소방경보시스템에서 : 관리자, 연기센서, 온도센서, 경보기 액터의 식별방법 SW가 담당할 문제영역에 따라 액터는 항상 다르게 정의됩니다. 액터를 식별하는 것은 생각보다는 어려운 작업이고, 액터를 정의하는 사람에 따라, 경험수준에 따라 차이가 있습니다. 따라서 액터를 정의하는 과정에서 관련 당사자들이 지속적으로 의견을 나누고, 결과는 반드시 리뷰하는 과정이 필요합니다. UML을 적용하여 SW를 잘 만들려면 액터부터 정확히 식별해야 합니다. 다음은 액터를 식별하는데 도움을 얻을 수 있는 질문들입니다. 시스템의 주요기능을 누가 사용하는가 ? 자신의 일상적인 업무를 수행하기 위해 시스템 지원을 필요로 하는 것은 누구(무엇)인가? 시스템이 운영될 수 있도록 관리 및 유지하는 것은 누구인가 ? 시스템이 취급하여야 하는 하드웨어 장치는 무엇인가? 시스템이 상호작용하여야 하는 다른 시스템은 무엇인가? 시스템이 제공하는 산출물에 관심을 갖는 대상은 무엇인가?

유즈케이스의 표기 왼쪽과 같은 타원 모양의 그림으로 표기합니다. 유즈케이스 아래에는 유즈케이스 명을 짧은 문장 혹은 행위를 나타내는 명사형으로 표시합니다. 경우에 따라 유즈케이스 명을 타원 안에 표기하기도 합니다. 유즈케이스의 정의, 의미 유즈케이스는 시스템이 제공하는 서비스 혹은 기능 입니다. 유즈케이스는 시스템이 액터에게 제공하는 사용자 관점의 기능단위입니다. 유즈케이스는 액터의 요청에 반응하여 원하는 처리를 수행하거나 원하는 정보를 제공합니다. 유즈케이스는 액터와 한 번이상의 상호작용을 통한 한 의미있는 묶음의 시스템 행위입니다. 유즈케이스는 그 자체로 의미있는 자기완결형(Self Contained)의 서비스 단위입니다. 유즈케이스는 사용자의 관점으로 정의해야 합니다. "유즈케이스는 의미있는 한 묶음의 시스템 행위" 라는 것의 예를 들어보면, 어떤 시스템에 유즈케이스 "주문하다" 가 있다고 가정해 봅시다. 이 유즈케이스는 액터인 고객과 다음의 그림처럼 표기되고, 그 교류는 다음과 같습니다. ※ 아래의 깜박이는 글씨를 클릭하세요. 이 예에서 유즈케이스는 액터와 여러 번의 교류를 하고 있음을 알 수 있고, 하나의 자기완결적인 행위(위 예에서는 주문에 대한 행위)를 담당하고 있다는 것도 알 수 있습니다. 유즈케이스의 예 결재 시스템에서 : 상신하다, 결재하다, 통보하다 전자 상거래 시스템에서 : 상품정보 조회, 주문, 배송, 결재 병원관리시스템에서 : 과거 병력 조회, 진료기록 입력, 진료비 계산 소방경보시스템에서 : 화재 감시, 경보음 출력 유즈케이스의 식별방법 다음은 유즈케이스를 정의하는 데 도움을 주는 질문들입니다. 액터가 어떤 기능을 시스템으로부터 요구하는가 ? 액터는 시스템을 통해 무슨 일을 수행하는가 ? 액터가 시스템에 있는 정보를 읽고, 작성하고, 저장하고, 수정하고, 삭제하여야 하는가? 시스템의 이벤트에 대하여 액터가 통보받아야 하는가 ? 액터가 시스템에게 어떤 사항을 통보하여야 하는가 ? 시스템의 새로운 기능을 통하여 액터의 업무가 단순화되거나 효율화 될 수 있는가? 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디로 가는가? 유즈케이스 식별시의 주의사항 유즈케이스는 사용자 관점에서 정의해야 합니다. 유즈케이스는 구현방법이나 물리적 환경과는 상관없이 독립적으로 정의되어야 합니다. 사용자와 교류없이 시스템 내부에서 수행되는 기능은 유즈케이스가 아닙니다. 유즈케이스는 반드시 하나 이상의 액터와 상호작용 해야 합니다. 유즈케이스의 이름은 짧은 문장이나 행위를 표현할 수 있은 명사형으로 정의해야 합니다. 예) 강좌(X) , 수강하다(O), 상품 조회(O)   3. 구성요소 : 관계   이번에는 액터-유즈케이스, 혹은 액터-액터, 유즈케이스-유즈케이스 사이에 정의되는 관계에 대해 학습하겠습니다. 유즈케이스 다이어그램에서 관계를 정의하는 것은 액터나 유즈케이스를 식별하는 것 만큼 중요합니다. 유즈케이스 다이어그램에서 사용되는 관계의 종류는 다음과 같습니다. 정의 및 특징 communicates는 액터와 유즈케이스 사이에 정의되는 관계입니다. communicates관계는 두 개체가 일반 상호작용 관계에 있다는 것을 의미합니다. 즉, 액터가 특정 사용목적을 가지고, 유즈케이스와 상호작용할 때 정의합니다. 액터는 서비스를 요구 하는 입장, 유즈케이스는 서비스를 제공하는 입장에 있습니다. 혹은 액터는 정보를 통보받거나 요구하는 입장, 유즈케이스는 정보를 제공하는 입장에 있습니다. 표기법 화살표 없는 실선으로 표현합니다. 모델 설명 학생(액터)는 수강하다(유즈케이스)와 교류하고 있습니다. 즉 학생 액터는 수강하다라는 유즈케이스의 서비스를 받습니다. (또는 사용합니다.) 한쪽 화살표를 가진 실선으로 표현합니다. 모델 설명 알람을 울리다(유즈케이스)가 잠꾸러기 (액터)에게 알람을 울리고 있습니다. 이 경우 화살표의 방향은 communication을 누가 개시하느냐에 따라 달라집니다. 위의 예는 "알람을 울리다"라는 유즈케이스가 교류를 시작하고 있음을 알 수 있습니다. (이렇게 유즈케이스가 액터에 먼저 communication하는 예는 흔하지 않습니다) 정의 및 특징 generalization은 액터와 액터, 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. generalization관계는 두 개체가 일반화 관계에 있음을 의미합니다. 즉, 보다 보편적인 것과 보다 구체적인 것 사이의 관계입니다. (is-a 관계라고도 합니다.) generalization관계는 상속(inheritance) 특성을 가집니다. 표기법 삼각형 화살표가 붙은 실선으로 표현합니다. 모델 설명 인터넷 고객(액터)와 고객(액터)는 일반화 관계가 있습니다. 즉, 인터넷 고객은 고객이 가진 특성을 모두 가지고 있고, 자신만의 특성을 추가적으로 가집니다.(상속) 사용자 인증(유즈케이스)와 패스워드 확인 (유즈케이스)는 일반화 관계가 있습니다. 즉, 사용자 인증은 보다 보편적인 것, 패스워드 확인은 보다 더 구체적인 방법으로서 상호간 관계를 가집니다. 정의 및 특징 include는 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. include관계는 한 유즈케이스가 다른 유즈케이스의 서비스 수행을 요청하는 관계입니다. 즉, 한 유즈케이스가 자신의 서비스 수행 도중에 다른 유즈케이스의 서비스를 사용할 필요가 있을 때 정의합니다. 이 경우 수행요청을 의뢰받은 서비스는 반드시 수행됩니다. 이때 수행의뢰를 받은 유즈케이스는 공통 서비스를 가진 존재입니다. 이렇게 수행될 때 Shared Service를 수행한다라고 합니다. 보통의 경우에 요청된 유즈케이스는 두 개 이상의 유즈케이스로부터 서비스 수행을 요청받습니다. 표기법 화살표 붙은 점선에 <<include>> 스테레오타입을 정의합니다. 화살표의 방향은 수행을 의뢰하는 쪽에서 수행될 유즈케이스쪽으로 향합니다. 모델 설명 로그인(유즈케이스)과 계좌이체 (유즈케이스)는 Shared Service인 사용자인증(유즈케이스)의 서비스 수행을 의뢰합니다. 즉, 로그인과 계좌이체 유즈케이스는 자신의 서비스 수행단계 중 특정한 시점에서 사용자 인증 서비스의 수행을 요청하는 것입니다. 정의 및 특징 extend는 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. extend 관계는 include 관계와 마찬가지로 한 유즈케이스가 다른 유즈케이스의 서비스 수행을 요청하는 관계입니다. 다만, include관계와는 달리 수행요청을 의뢰받은 서비스는 수행되지 않을 수도 있습니다. 즉 수행을 의뢰하는 유즈케이스는 조건에 따라 수행을 의뢰할 수도 있고 의뢰하지 않을 수도 있습니다. 이것이 include관계와의 차이점입니다. 수행을 의뢰할 조건을 extension point 라고 합니다. include와는 달리 하나의 유즈케이스에 의해 서비스 수행을 요청받을 수도 있습니다. 표기법 화살표 붙은 점선에 <<extend>> 스테레오타입을 정의합니다. 화살표는 include와 반대로 수행될 유즈케이스에서 수행을 의뢰하는 쪽으로 향함합니다. 모델 설명 고객목록조회(유즈케이스)는 고객상세 정보 조회(유즈케이스)의 서비스 수행을 의뢰합니다. 그런데 무조건 의뢰하는 것이 아니고, 고객의 요청이 있을 경우에 한해 상세정보조회 서비스의 수행을 요청합니다.   4. 사례연구   다음은 어느 회사의 간단한 인사시스템의 유즈케이스 다이어그램입니다. 유즈케이스 다이어그램의 실 사례를 편안한 마음으로 보시면서 이 다이어그램이 의미하는 시스템 영역과 기능을 정리할 수 있는지 판단해 보시기 바랍니다. 어느 회사의 간단한 인사관리시스템입니다. 이 시스템의 사용자는 액터인 인사담당자와 시스템관리자입니다. 인사담당자에게 시스템은 인사정보를 신규등록하고 수정하고 인사현황 조회를 서비스합니다. 그리고 이를 위해 사원 검색 서비스를 공통 서비스로 분리하여 정의하였습니다. 시스템 관리자는 기준정보를 관리합니다. 실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록 하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된 주변정보를 제공합니다. 이 문제영역에 대한 분석을 통해 실제 유즈케이스 다이어그램을 작성하고 이를 소개하도록 하겠습니다. 여러분은 "문제영역" 설명을 보시고 현재까지의 지식을 총 동원하여 나름대로 유즈케이스 다이어그램을 작성해 보십시오. 그런 다음 "문제영역에 대한 유즈케이스 다이어그램" 항목의 기준모델과 비교해 보시기 바랍니다. 모델링은 눈으로 익히는 것이 아니라 손과 머리로 익히는 것입니다. A병원은 이번 기회에 SW시스템을 구축하여 업무의 일부를 자동화 하기를 원합니다. A병원에는 기존시스템으로 병원의 수입과 지출을 관리하는 "회계시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의 병력및 진료정보, 의료진 정보의 각종 정보관리와 진료예약 처리 및 수납지원을 수행하는 신규 시스템을 구축하기를 원하고 있습니다. 병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다. 진료비는 진료정보를 입력하면 자동 산정됩니다. 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다. 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다. 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다. 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회, 발행하고, 진료예약을 확정하기를 원합니다.

 

  5. 작성단계 및 주의사항

 

유즈케이스 다이어그램을 작성하는 순서는 딱 정해진 바는 없습니다. 그러나 프로젝트 현장에서는 다음의 순서대로 작성하는 것이 일반적입니다. 물론 순서를 꼭 지켜야만 하는 것은 아닙니다. 액터를 식별합니다. 시스템의 모든 사용자의 역할을 식별합니다. 시스템과 상호작용하는 타 시스템를 식별합니다. 시스템과 정보를 주고받는 하드웨어나 지능형 장치를 식별합니다. 유즈케이스를 식별합니다. 액터가 요구하는 서비스를 식별합니다. 액터가 요구하는 정보를 식별합니다. 액터가 시스템과 상호작용하는 행위를 식별합니다. 관계를 정의합니다. 액터와 액터간의 관계를 분석하고 정의(generalization 관계)합니다. 액터와 유즈케이스간의 관계를 분석하고 정의(communicates)합니다. 유즈케이스와 유즈케이스 간의 관계를 분석하고 정의(include, extend, generalization) 합니다. 유즈케이스를 구조화(factoring)합니다. 두 개 이상의 유즈케이스에 존재하는 공통 서비스 추출합니다. 추출된 서비스를 유즈케이스로 정의합니다. 공통 서비스를 사용하는 유즈케이스와 신규 유즈케이스의 관계를 정의(include)합니다. 조건에 따른 서비스 수행부분을 분석하여 추출합니다. 추출된 서비스를 독립 유즈케이스로 정의합니다. 추출된 서비스를 사용하는 유즈케이스와 관계를 정의(extend)합니다.

다음은 유즈케이스 다이어그램시 작성시 주의사항입니다. 액터와 유즈케이스의 명칭은 직관적으로 이해할 수 있는 명쾌한 것으로 정해야 하며, 모호한 명칭은 삼가합니다. 예) 전체정보를 피드백하다(X), 활동을 탐색하다(X), 신규회원정보 등록(O) 사용자 관점이라는 전제를 잊으면 안 되겠습니다. 예) Data Window 출력(X), 회원정보 검색(O) 모든 유즈케이스는 반드시 하나 이상의 액터와 교류해야 합니다. (단, include/extend 관계의 유즈케이스는 직접 actor와 관계를 갖지 않을 수도 있습니다. 그러나, 이 경우는 include/extend 요청 유즈케이스와 하나로 간주하므로 상관없다고 하겠습니다.) 유즈케이스의 추상화 레벨은 비슷한 레벨이어야 합니다. 즉, 어떤 것은 아주 개념적인데 비해 어떤 것은 구체적이어서는 안됩니다. 예) - 고객을 관리하다 vs. 고객정보를 입력하다.       - 회계시스템과 인터페이스하다 vs. 과정수강정보를 회계시스템에 제공 유즈케이스의 크기단위(granularity)는 일정해야 합니다. 즉 동일한 유즈케이스 다이어그램에서 어떤 것은 여러 유즈케이스로 나뉠만한 매우 큰 단위인데, 어떤 것은 여러 개의 작은 유즈케이스로 정의되어서는 안됩니다. 예) 파일관리 vs. 파일저장/파일열기