본문 바로가기

IT_Story/UML

UML Use Case Diagram

  Use Case?

 

1. Use Case 정의.

 

기존 프로젝트의 실패원인을 들자면 여러가지가 있을것이다. 하지만 중의 하나가 의사소통의 부재를 들수 있다. 프로젝트의 시작시 프로젝트의 결과물을 사용하는 사용자 혹은 프로젝트를 맡긴 의뢰인과의 대화결여로 인하여 프로젝트 자체의 형태가 바뀌게 된다.  이러한 일을 막기 위해 우리는 Use Case Diagram 사용하여 프로젝트의 기능적인 면을 담을 있을 것이다.

Use Case 것은 그대로 사용의 사례로서 시스템 사용의 사례들을 그려 놓은 것이다.

예를 들어 어떠한 건물을 만든다고 생각하자. 실제로 이러한 건물은 먼저 설계를 하여야 한다. 건물의 설계에서 건물이 주로 어디에 어떻게 사용될지를 생각하게 된다. 이렇게 건물의 주요 용도를 사용자와의 상호작용으로 표시한 것을 Use Case 한다.

 

2.   Use Case 특징.

 

 1)   의사 소통 수단이다.

 

의뢰인 혹은 사용자와 개발자는 시스템의 형태에 대해서 결정하여야 한다. 이러한 결정을 위해서는 시스템의 주요기능이 나타날 있는 Diagram 필요한데 Diagram Use Case Diagram이다. 

 

 2)   구현 독립적이다. 

Use Case 경우 외부에서 시스템을 바라보아서 기능을 나타낸다. 외부에서 하나의 Use Case에서 Use Case 내부적 수행 과정은 블랙박스로 외부에 나타나지 않아야 한다. 이처럼 Use Case Diagram 그릴 시스템의 내부적인 수행 과정은 포함시키지 말아야한다.

시스템의 정확한 기능을 추출하기 위해 의뢰인은 Use Case Diagram 보고 시스템의 기능을 완전이 이해할 있어야 한다.  시스템의 기능을 알려주기 위해서 내부의 구현까지 의뢰인에게 알려야 필요성은 없다. 오히려 의뢰인의 이해를 감소시키는 영향을 미치기도 한다.

반드시 Use Case Diagram에서 시스템의 내부는 숨겨져야 한다.

 

 3)   테스트의 기본이다. 

의뢰인과 개발자간의 합의로 인해 시스템의 기능이 확정된다. 이러한 확정된 기능은 앞으로 분석과 구현의 기본이 된다. 개발도중 중간결과를 초기에 정한 Use Case Diagram 비교하여 오류를 수정할 있다.

이와 같이 Use Case Diagram 앞으로 개발되는 중간결과물에 대한 테스트의 기본이 있다.

 

3.     Process에서의 Use Case Diagram. 

어떠한 시스템의 개발이던지 시스템 개발의 시작은 항상 시스템에 대한 요구의 분석으로 시작할 것이다.  혼자서 자기의 프로그램의 개발하는 형태라든가 아니면 의뢰인의 수주를 받아서 프로그램을 개발하는 형태등.. 여러가지의 어떠한 개발의 형태에도 적용되어야 것이 시스템의 어떠한 기능과 어떠한 크기등등의 여러가지 제반사항을 시스템 개발의 초기에 마련하는 것이다. 이러한 시스템에 대한 요구분석을 기록할 있는 Diagram Use Case Diagram이다. 결국 Use Case Diagram 개발프로세스의 초기에 사용되어진다.

 

II.     표기와 의미. 

1.     Actor Notation 의미.

 

1)   표기법.

 

             [그림 1]

 

Actor 표기는  그림 1 같이 ‘Stick man’으로 표시하거나 Stereotype Actor 가지는 Class 표기한다.

 

2)    의미. 

a.          Actor 시스템과 상호작용하는 어떤 사람이나 어떤 것이다.  시스템과의 상호작용이란 시스템과 어떠한 정보의 교환을 한다는 의미이다.

b.         Actor 시스템의 개인 사용자가 아니라 하나의 역할을 나타낸다. 예를들어 홍길동이란 사람이 보험회사에 보험을 들려고 한다. 여기서 홍길동이란 개인이 Actor 되는 것이 아니라 그의 역할 보험가입자가 Actor 되는 것이다.

 

3)   예제 

 

                                                   [그림 2]

 

2.   Use Case Notation 의미.

 

1)   표기법.


 

    [그림 3]

 

Use Case 표기는 그림 3 같이 Use Case 이름을 포함한 타원으로 표시한다.

 

2) 의미.

 

a.     Use Case 시스템의 핵심적인 기능을 표현한 하나의 단위이다.  이러한 핵심적인 기능은 Actor와의 상호작용에 의해서 나타내어진다.

 

b.    Use Case 사용자나 혹은 의뢰인의 입장에서 기능적인 요구사항이다. 시스템의 핵심적인 기능은 사용자나 의뢰인의 입장에서 반드시 필요한 사항이어야 한다.

 

3)       예제.


 

  [그림 4]

 

3.    Actor사이의 Relationship 의미.

 

1)    표기법.

                     [그림 5]

              Generalization Realtionship 표기는 위의 그림과 같이 닫혀진 화살표로 나타낸다. 

2)   의미. 

Generalization 의미는 상속의 의미와 유사하다. 위의 그림에서 있듯이  Custormer Commercial Customer Generalization 관계를 가진다.  Customer 일반적 역할을 가진 Actor 모든 행위를 Commercial Customer Actor 가지는 것이다.

 

4.        Use Case사이의 Relationship 의미.


 

1)  표기법

                     [그림 6]

그림 6 Relationship Association Relationship으로 실선으로 표시한다.

 

                    [그림 7]

그림 7 Relationship Extend Relationship으로 열린 머리의 점선 화살표로 나타낸다. 화살표 위에는 <<Extend>>’ 적어준다.

 

 

                   [그림 8]

그림 8 Relationship Include Relationship으로 열린 머리의 점선 화살표로 나타낸다. 화살표 위에는 ‘<<Include>>’ 적어준다.

 

 [그림 9]

그림 9 Relationship Generalization Relationship으로 닫힌 머리의 속이 실선 화살표로 나타낸다.

 

2)  의미

 

a.        Extend Relationship : Extend Relationship 사용할려는 Use Case 사용되어지는 Use Case 행위를 선택적으로 포함하는 것을 의미한다.

 

b.       Include Relationship : Include Relationship 사용할려는 Use Case 사용되어지는 Use Case 행위를 필수적으로 포함하는 것을 의미한다.

 

c.      Generalization Relationship : Generalization Relationship 클래스들 사이의 상속관계와 유사한 관계로 자식 Use Case 행위는 모든 부모 Use Case 행위를 받아오는 것이다.

 

3)  예제                      

  [그림 10]

그림 10에서 보는 바와 같이 사용자 인증 Use Case 행위는 반드시 주문처리 Use Case 행위에 포함되어야 한다. 이것이 include relationship 관계이다. 그리고 주문처리의 행위는 급한 주문 처리 Use Case 행위의 어떤 조건에 부합되었을 포함되어진다.  이것은 extend 관계가 된다.  패스워드 검색 Use Case 행위는 사용자 인증 Use Case 행위를 상속받아서 사용한다. 이것이 Generalization 관계이다.

 

5.       Actor Use Case사이의 Relationship 의미.

 

1)  표기법.

      [그림 11]

 

그림 11 Relationship Association Relationship으로 실선으로 표시한다.

 

2)   의미.

 

Association Relationship Actor Use Case사이의 관계로 Actor Use Case간의 정보교환을 의미한다.

 

3)   예제.


세일즈맨의 Actor 주문을 받다의 Use Case 상호작용을 통해 정보를 주고 받는다.

 

III.        이외의 특징들.

 

1.       Actor 추출법.

 

우리는 시스템과의 상호작용을 하는 Actor 몇가지 질문을 통해 대상을 Actor 간주할 있다.

 

1)      시스템의 주기능을 사용하는 사람은 누구인가?

2)       누가 시스템으로부터 업무 지원을 받는가?

3)       누가 시스템을 운영, 유지 보수하는가?

4)       시스템과 정보를 교환하는 외부 시스템은 무엇인가?

5)       시스템이 내어놓은 결과물에 누가 관심을 가지는가?

 

2.      Use Case 추출법.

 

Actor 같이 Use Case또한 여러가지 질문을 통해 찾아낼 있다.

 

1)       Actor 요구하는 시스템의 주요 기능은 무엇인가?

2)      Actor 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하느가?

3)      시스템이 Actor에게 주는 어떠한 Event 있는가?,  Actor 시스템에 주는 어떠한 Event 있는가?

4)     시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가?

5)   시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

 

3.     Event Flow.

 

Actor Use Case 추출이 되었다면 우리는 시나리오를 작성하기 위한 단계로  Event flow 만들어야 한다. Event Flow Use Case 행위들의 흐름을 나타낸다. Event flow내에 Use Case 행위의 시작과 끝이 어떻게 나타나는지 표시하게 된다. Evnet flow에는 Main flow of Event Alternate Flow of Event, Exceptional flow of event 세가지가 존재한다.

 

1)       Main Flow of Event

 

Use Case 행위의 중심적 흐름을 나타낸다. 인터넷 쇼핑몰 시스템의 예를들어 설명하면 다음과 같다.

 

사용자가 쇼핑몰 시스템을 로그온하면서 Use Case 시작되고 시스템은 사용자의 암호를 확인하고 사용자가 물품을 선택하게 있도록 Select, Deselect, Deselect All, Cancel 선택사항을 표시한다.

 

2)   Alternate Flow of Event

 

Main Flow of Event 선택적인 상황이 발생할 경우를 나타낸다. 위의 예에 이어서 설명하면 다음과 같다.

 

사용자가 Select 선택했을 경우 : 물품의 가격과 제반사항을 표시한다.

사용자가 Deselect 선택했을 경우 :  물품을 선택하게 있는 표시를 한다.

사용자가 Cancel 선택했을 경우 : ……..

 

3)      Exceptional Flow of Event

 

예외적인 상황이 발생할 경우를 나타낸다. 위의 예에 이어서 설명하면 다음과 같다.

 

사용자가 선택한 물품을 다시 선택하였을 경우 : 사용자에게 적당한 경고의 문구를 표시한다.

 

4.      Senarios.

 

시스템에서 여러가지의 Use Case 나오고 그에 따라  이벤트의 흐름이 나타난다. 이벤트의 흐름은 절에서 보았듯이 Main Flow Alternative Flow 있다. 이렇듯이 이벤트의 흐름은 여러가지가 나올 있다. 이러한 이벤트의 흐름을 실례(Instance)화하여 텍스트로 나타낸 것을 시나리오라고 한다.  시나리오 또한 여러가지가 나올 있다.

 

5.  실제화(Realization).

 

실제 Use Case 다이어그램에서는 구현에 관한 사항은 생각치 말고 표현하지 말아야 한다. 하지만 내부 구현이 필요한 경우 이것의 구현은 Collaboration으로 표현한다. Collaboration Use Case 클래스나 오브젝트들 사이의 관계와 상호작용으로 나타낸다. 하지만 Use Case Diagram에서의 Collaboration 표기는 점선 타원으로 표시한다. 이러한 Collaboration Interaction Diagram Activity Diagram 표현하기 위한 기본이 된다.