3. A. Usecase Diagram

 

 

심원도
E-mail:wideeye@www.plasticsoftware.com
플라스틱 소프트웨어
Homepage:www.plasticsoftware.com

지난 회에서 우리는 UML의 전체 구성에 대하여 알아보았다. 전체적인 구성을 보았으니 앞으로 각 다이어그램을 하나씩 보도록 하자.  이번 회에는 유스케이스 다이어그램에 관하여 알아보도록 하겠다.  많은 다이어그램 중에 왜 유스케이스 다이어그램을 가장 먼저 설명을 하는가에 대한 의문이 일것이다.  물론 필자의 마음일 수도 있지만 이 보다도 더 명확한 이유가 존재한다.  독자 여러분이 어떠한 방법론을 배우고 있다 하더라도 프로젝트를 수행함에 있어서 가장 먼저 수행되는 일이 동일할 것이다. 그것은 프로젝트가 무엇인지에 대한 기술이다. 프로젝트가 무엇인지 모르고 어떻게 프로젝트를 수행하겠는가?  이렇게 프로젝트가 무엇인지에 대해서 알아보는 것이 요구분석(Requirement Analysis)이다.  글의 흐름으로 보아 유스케이스 다이어그램이 요구분석을 위한 다이어그램이라는 것을 유추할 수 있을 것이다.  결국 유스케이스 다이어그램은 프로젝트 수행시 가장 먼저 나오는 다이어그램이고 다른 다이어그램의 배경이 되는 중요한 다이어그램이다.  이제부터 유스케이스 다이어그램을 자세히 알아보도록 하겠다.

 

1. 표기(Notation)과 의미(Semantics)

(1) 유스케이스(Usecase)

그림 1. 유스케이스

유스케이스의 표기는 그림 1에서와 같이 타원으로 표시하고 이름을 속에 명시하게된다.

(2) 유스케이스의 의미.

유스케이스는 말 그대로 쓰임새를 나타낸다. 다시 말해 한 프로젝트의 결과물이 작동하여 사용되는 쓰임새를 분류하여 나타내는 것이다. 예를 들어 우리가 늘 상주하는 집을 들면 집이 사용되어지는 예를 들 수가 있다. 집은 식사를 위한 장소를 사용되어질 수 있고 아니면 휴식을 위한 장소 아니면 수면을 취하기 위한 장소.. 등등 여러가지 용도의 사용 예를 들 수 있다. 결국 이러한 여러 사용 예들이 집의 구조를 결정하는 사항이 될 것이다.

(3) 액터(Actor)

그림 2 - 액터

그림 3 - 스테레오 타입이 액터인 클래스

액터의 경우 그림 2에서 보는 바와 같이 스틱맨으로 표시하고 그 하단에 액터의 이름을 명시한다.  또한 그림 3와 같이 스테레오타입(Stereotype)을  'Actor' 로 가지는 클래스로 표기하기도 한다.

(4) 액터의 의미

액터는 구축해야할 시스템과 상호 교류하는 어떠한 사람이나 어떤 것이 될 수 있다. 예를 들어 입출금할 수 있는 ATM기계를 보면 입출금을 하는 행위자인 손님의 경우 하나의 액터가 될 수 있다. 그리고 ATM기계가 입출금의 처리를 위해 연결하는 은행의 주 전산망 또한 하나의 액터가 될 수 있다. 이렇듯이 구축하고자 하는 시스템의 쓰임새와 교류하는 외부적인 것들의 추상적인 역할을 액터라고 한다.

 

2. 액터들간의 관계(Relationship)

(1) 일반화(Generalization) 관계의 표기

그림 4 -액터와 액터 사이의 일반화 관계

(2) 일반화 관계의 의미

일반화 관계는 객체지향의 상속의 의미와 유사하다. 일반화된 액터의 모든 특성을 특수한 액터가 모두 가지게 된다. 그림 4에서와 같이 고객 액터의 모든 특성을 상업고객이 모두 포함하게 된다.

 

3. 액터와 유스케이스, 유스케이스와 유스케이스 사이의 관계

유스케이스와 유스케이스사이의 관계를 말하기에 앞서 알아두어야 할 사항이 있다. 현재 UML의 표준화된 버전은1.1 이다. 하지만 현시점에도 계속 버전업을 위한 수정이 가해지고 있다. 결과적으로 현재 1.3 RTF라는 표준화되지 않은 버전 또한 나와 있다.  유스케이스와 유스케이스와의 관계에서 1.1버전과 1.3버전의 차이점이 존재함을 유념하기 바란다.  필자는 표준인 1.1 을 대상으로 설명을 하도록 하겠다.

(1) 통신(Communicates) 관계

그림 5 - 통신(Association) 관계

(2) 통신 관계의 의미

통신관계의 의미는 이러한 관계로 묶인 두 개체가 상호 작용을 한다는 의미이다.  그림 5에서와 같이 현금자동출납기계의 시스템에서 그 사용자와 사용자확인의 유스케이스는 상호작용을 하게 된다. 이를 관계로 표시한 것이 통신 관계이다. 참고로 UML1.3 RTF의 경우 통신관계는 연관(Association) 관계로 대체되어 사용되게 된다.

(3) 확장(Extends) 관계

그림 6 - 확장(Extends) 관계

(4) 확장 관계의 의미

확장(Extends)관계는 유스케이스가 어떤한 조건이 만족할 경우 확장할 수 있는 확장시점(Extention Point)를 가지고 그 때 연관된 유스케이스를 포함하는 관계이다 예를 들면 그림 6에서와 같이 추가 요구시라는 확장시점에서 카탈로그요구의 유스케이스가 주문접수의 유스케이스에 포함되게 된다.

(5) 사용(Uses) 관계

그림 7 - 사용(Uses) 관계

(6) 사용 관계의 의미

사용관계는 특정한 유스케이스가 다른 유스케이스를 포함하고 있는 경우를 나타낸다. 그림 7에서는 고객확인의 유스케이스가 주문접수의 유스케이스와 주문조사의 유스케이스를 모두 포함하게 되는 경우이다. UML 1.3 RTF에서는 Uses의 관계가 include의 관계로 이름이 바뀌어서 사용되게 된다.

(7) 일반화(Generalization) 관계

그림 8 - 일반화(Generalization) 관계

(8) 일반화 관계의 의미

일반화 관계는 액터 사이의 일반화 관계와 동일하게 객체지향의 상속의 개념과 유사하다.

 

4. 액터와 유스케이스의 추출법.

실제로 시스템을 구축하기 위해 유스케이스 다이어그램을 그릴 때 액터와 유스케이스를 만들기가 막막할 것이다. 물론 정확한 액터와 유스케이스를 추출하기 위해서는 여러 번의 반복이 필요하지만 처음으로 추출할려는 사람은 다음과 같은 대충의 지표 등을 통해 추출해보는 것도 좋다.

(1) 액터의 추출법

1. 시스템의 주기능을 사용하는 사람은 누구인가.
2. 누가 시스템으로부터 업무 지원을 받는가?
3. 누가 시스템을 운영, 유지 보수하는가?
4. 시스템과 정보를 교환하는 외부 시스템은 무엇인가?
5. 시스템이 내어놓은 결과물에 누가 관심을 가지는가?

(2) 유스케이스 추출법

1. Actor가 요구하는 시스템의 주요 기능은 무엇인가?
2. Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?
3. 시스템이 Actor에게 주는 어떠한 Event가 있는가?,  Actor가 시스템에는 어떠한 Event가 있는가?
4. 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?
5. 시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

 

5. 시나리오

유스케이스 다이어그램을 그리면서 빠뜨려서는 안될 내용이 시나리오이다. 유스케이스 다이어그램을 완성하였다면 유스케이스 다이어그램의 명세가 필요하게 된다. 즉 유스케이스 다이어그램이 무엇을 해야하고 어떻게 해야하는가에 같은 부연 설명이 필요한 것이다. 유스케이스는 순서에 의해 배열이 가능하고 이러한 순서를 일반적인 자연어 문장으로 표현하되 외부인이 보아도 알기쉬운 정도로 쉽게 기술하여야 한다.

마무리?

유스케이스 다이어그램은 다른 다이어그램을 그리기 위한 바탕이 되는 다이어그램이다. 즉 유스케이스 다이어그램이 잘못 되었다면 결과물은 잘못된 것일 수밖에 없다. 유스케이스 다이어그래이 잘 되었다면 이후 그려나갈 다른 다이어그램이 원래의 목적에 맞게 그릴 수 있는지 비교할 수 있는 좋은 바탕이 될 수 있다.
참고로 유스케이스 다이어그램을 잘 그리기 위해 다음의 단계로 넘어가는 것을 주저하지 말기 바란다. 프로젝트를 잘 수행하기 위해서는 여러 번의 반복적 개발을 통해 오류의 수정 과정이 필요하고 이에 유스케이스 다이어그램을 수정하는 일도 포함된다. 즉 어느 정도 유스케이스 다이어그램이 완성되면 다음의 다이어그램을 진행하길 바란다.