Creative Commons License

Software Dev

프로그래밍기본
객체지향
프로젝트관리
알고리즘
데이타베이스

소프트웨어 개발에 필수적이고 필요한 주제에 대한 강의 및 공유

.

객체지향

객체재향 프로그래밍 패러다임과 각종 기법 및 방법론에 대해 다룹니다

[UML] Use Case

작성자 : 박종명
최초 작성일 : 2008-05-13 (화요일)
최종 수정일 : 2008-05-13 (화요일)
조회 수 : 6673

Key Word

Use Case Diagram

사용자 시점, 사용자 참여, 시스템의 쓰임새, 용도


1.
유스케이스(Use Case)

 

시스템의 개발을 시작하기 전에 반드시 개발하려는 시스템의 분석단계가 선행되어야 한다. 이와 같은 시스템 분석단계에서 사용자 관점에서의 사용자의 요구사항 을 알아내는 과정이 필요하다. 즉 사용자가 어떻게 시스템을 사용하느냐에 관한 정보를 수집하여 사용자 시점에서 본 시스템의 그림이 나와야 한다. 결론적으로 유스케이스란 사용자의 입장에서 본 시스템의 행동을 일컫는다

 

1.1 유스케이스(Use Case)  뜻 풀이

유스케이스(Use Case)를 직독하면 사용 케이스 즉 사용 방식 쯤으로 해석할 수있다. 그러나 조금 더 의미론적으로 해석해 보면 시스템의 기능, 쓰임새, 사용사례 가 더 적합한 듯 하다. 시스템이 추구해야 할 기능들, 쓰임새들, 사용사례의 집합체가 바로 유스케이스이다.

 

1.2 유스케이스(Use Case) 의 목적 및 역할

① 시스템 사용자를 시스템 분석과 설계의 초기 단계에 포함(참여)시킬 수 있다

사용자의 시점(입장)에서 시스템을 모델링 할수 있다.

 

1.3 기본 흐름(성공흐름) VS 대체 흐름

유스케이스를 구성하는 항목은 두 가지 이다.

시스템이 사용자의 요구기능을 성공적으로 수행될때의 기본흐름(성공흐름)과 기능의 수행도중 실패할 경우에 적절히 대체해야할 대체흐름(대안흐림)을 명확히 해야 할 필요가 있다.

 

   

2 유스케이스 다이어그램 (Use Case Diagram)

 

시스템의 기능과 이러한 기능을 이용하는 행위자, 기능이 속해 있는 시스템 경계등을 한눈에 쉽게 파악하기 위해 시각화한 것. 유스케이스를 시각화한 설계도에 해당한다. 유스케이스를 시각화하면 정보를 보다 확실하고 빠르게 전달될 수 있다

 

2.1 등장 인물

유스케이스에는 대표적으로 기능을 이용하는 사용자가 존재한다. 이를 Actor(행위자)라 한다. 그리고 Actor 가 사용하는 기능을 Use Case 라 한다. 그리고 이러한 기능들은 특정 시스템 영역내에 위치하게 된다.

 

등장인물

설명

Actor (행위자)

유스케이스를 시작시키고, 그 결과를 받음

Use Case

시스템의 기능, 쓰임새, 사용사례

System

기능들을 포함하고 있는 시스템 영역 (시스템 경계)

 




Actor

일반적으로 Actor 는 시스템의 기능을 시작시키고 결과를 통보 받는다. Actor 는 보통 사용자를 나타내지만 경우에 따라서는 시스템 혹은 특정 장치가 될 수 도 있다.(사용자 Actor / 시스템 Actor)

특정 기능의 수행결과를 반드시 사용자가 받아야 되는 것은 아니기 때문이다. 또한 특정 기능을 요청하는 주체 역시 또 다른 시스템이 될 수 있다.

 

√ 시스템

시스템의 영역을 표시함으로써 시스템과 외부 세계와의 곙계를 명확히 할 수 있다.

일반적으로 Actor System 영역 바깥쪽에 위치하고 Use Case System 영역내에 위치한다

 

√ 방향성

방향성을 반드시 표현해야 할 필요는 없다.

일반적으로 Actor Use Case 를 시작시키고 Use Case 의 진행단계가 끝나면 결과를 받는다. Use Case 를 시작시킨 Actor 는 왼쪽에 위치하고 결과를 받는 Actor 는 오른쪽에 위치하여 ->방향성을 가진다

 

 

 

3. 유스케이스 사이의 관계 4가지

 

유스케이스 간에도 관계가 있다.

포함,확장,일반화,그룹화가 그것이다.



 

관계

설명

포함(Inclusion)

공통적인 기능요소를 별도의 유스케이스로 만듦

이를 다른 유스케이스에서 재사용

확장(Extension)

기존 유스케이스에 진행단계를 추가 (or 대체흐름 표시)

일반화(Generalization)

유스케이스의 상속(일반화)

그룹화(Grouping)

유스케이스들의 그룹화(패키지)

 

 

3.1 포함과 확장

유스케이스의 중요한 개념인 포함과 확장에 대해 자세히 알아보자

유스케이스의 포함과 확장은 유스케이스의 효과적인 재사용성을 가능케 한다.

 

① 포함

    특정 유스케이스가 수행되는 과정 중 다른 유스케이스에서도 중복적으로 수행하게 될 공통적인 진행단계가 있다면

    이러한 중복적인 진행단계를 뽑아 내어 별도의 유스케이스를 따로 만들고     이렇게 만들어진 유스케이스를 여러

    곳에서 재사용하는 기법을 유스케이스 포함이라고 한다.     만일 회원가입이라는 유스케이스가 있다면 주소를 입력

    하기 위해 우편번호 찾기기능이 제공되어야 할 것이다그러나 우편번호 찾기와 같은 기능은 회원가입뿐만 아

    니라 회원정보수정에서도 똑같이 사용될 수 있다따라서 우편번호 찾기를 별도의 유스케이스로 만들고 회원가

    입회원정보수정에서 재사용 하면 된다이때 회원가입유스케이스는 우편번호 찾기유스케이스를 포함한다

    할 수 있다.

 

유의 사항 >>

포함된 유스케이스는 절대로 단독으로 존재할 수 없다.

전체 유스케이스의 부분으로만 존재한여야 한다.

 

 

 

② 확장

    기존의 유스케이스에 몇 가지 진행단계를 덧붙여서 새로운 유스케이스를 만들어 내는 기법을 유스케이스 확장이라

    고 한다. 이때 재사용되는 유스케이스는 기존 유스케이스가 된다. 만일 사용자가 로그인을 하면 새 쪽지 알림기능

    을 추가적으로 구현한다면 로그인유스케이스를 확장하는 것이 된다. 즉 기존의 로그인유스케이스는 새 쪽지 알

    림유스케이스로 확장되었다고 할 수 있다.

 

특정 유스케이스의 이벤트 흐름중 대체흐름과 같은 특수한 경우에도 확장을 이용하기도 한다.

그러나 대부분 이러한 경우는 유스케이스의 대체흐름으로 기술하는 것이 좋다

 



√ 확장 포인트 (Extension point)

유스케이스의 확장은 기본 유스케이스의 진행 단계에서 특정한 경우에만 수행될 있다. 이 경우를 확장 포인트라고 하

는데 위의 예에서 새 쪽지 알림확장 유스케이스는 마지막 로그아웃 이후 새 쪽지가 도착한 경우에만 수행된다.
확장 포인터는 이와 같이 특정 조건이 될수도 있지만 특정 시점이 될 수도 있다. , ‘무엇 무엇을 하고 난 후 확장 유스케이스 실행과 같이

 

③ 일반화

클래스의 상속처럼 유스케이스간에도 상속이 가능하다. 이 개념은 클래스의 상속 개념과 거의 동일하다.




④ 그룹화

관련된 유스케이스를 패키지로 그룹화 할 수 있다.



4. 유스케이스 명세서

 

각각의 유스케이스는 상세한 시나리오를 가진다.

시스템이 갖추어야할 많고 복잡한 기능들에 대한 요구사항은 Use Case 다이어그램만으로 불충분 할 수도 있다.

지금까지 알아본 유스케이스 다이어그램은 액터와 유스케이스의 정의, 둘간의 관계, 유스케이스간의 관계, 시스템 영역등을 기술하여 요구사항에 대한 상위수준의 이해를 도와준다. 그러나 요구사항을 보다 명확하고 구체적으로 기술하여 사용자와의 세세한 합의가 필요하거나 개발자의 시스템 구축을 위한 정보로써 보다 상세할 필요가 있다면 요구사항에 대한 자세한 명세서가 필요하다. 시스템 영역내에 위치하는 유스케이스는 실제 시스템의 기능이 되므로 개발자에게 보다 자세한 정보를 알려 줄 필요도 있다.

유스케이스를 보다 자세히 기술한 문서를 유스케이스 명세서(Use Case Specification)라고 한다.

 

유스케이스의 상세한 시나리오를 위해 유스케이스 명세서 라는 별도의 설계문서를 작성할 수도 있지만 간단하게 유스케이스 다이어그램의 특정 영역에 간단히 표기하는 것으로도 충분할 수 있다.

역시 여러 제반 조건, 상황등에 따라 유연하게 선택되어져야 할 것이다.

 

  

4.1 유스케이스 명세서 작성 순서

일반적으로 유스케이스 명세서에는 다음과 같은 항목들이 순차적으로 기술된다

 

행위자

선행 조건

진행단계

종료조건

행위자

유스케이스를 시작하는 행위자

 

유스케이스가 시작되기 위해 필요한 선행조건

 

시나리오의 진행단계

 

유스케이스 수행 결과로 만족되어야 하는 조건

 

유스케이스의 결과를 받는 행위자

 

 

이와 더불어 유스케이스의 우선순위 및 기타 항목이 추가 기술되기도 한다.

 

 

4.2 유스케이스 명세서 샘플

쇼핑몰의 상품구매에 대한 간단한 샘플 시나리오를 만들어 보자.

이 샘플은 말 그대로 샘플을 위한 명세서 임을 기억하자. 상황은 요구사항에 따라 달라진다.

 

유스케이스 명

 상품 구매

개요

 장바구니에 있는 상품을 결제를 통해 구매한다

우선 순위

 

선행 조건

 고객은 로그인이 되어 있어야 하며 장바구니에 상품이 존재해야

 한다

진행 단계

(이벤트 흐름)

 기본흐름

1.       고객은 장바구니 메뉴에서 구매하기를 선택한다.

2.       시스템은 구매할 상품을 확인한 후 배송정보와 결제정보를 입력받는 페이지를 보여준다

3.       고객은 배송정보와 결제정보를 입력하고 구매하기를 선택한다.

4.       시스템은 고객이 입력한 정보를 재확인 시킨다.

5.       고객은 정보를 재확인하고 최종적으로 구매하기를 선택한다

6.       시스템은 결제대행사를 통해 결제를 처리하고 주문내용을
출고시스템에 통보한 후 주문완료 페이지를 보여준다.

 

 대체흐름

카드유효기간 만료, 한도초과등으로 결제가 불가할 경우

1.       시스템은 고객이 결제할 수 없는 이유를 알려준다.

2.       사용자는 다른 결제수단을 선택하여 결제를 시도한다.

종료 조건

상품 출고 준비, 포인트 적립

기타 요구사항

고객의 결제정보에 대한 암호화 처리

 

 

 

5. 결론

 

키워드 : 사용자 시점, 사용자 참여, 시스템의 쓰임새

 

개인적으로 유스케이스 다이어그램은 시스템 개발자와 사용자(또는 의로인)와의 요구사항에 대한 의사소통을 보다 원활하게 도와주는 표기법이라 여겨진다. 일반적으로 말보다는 글이, 단순히 나열된 글 보다는 표와 같이 형식을 가진 글이 , 형식화된 글보다는 그림이 사람의 이해도를 높인다. 개발 초기 요구사항 분석단계에서 시스템이 제공하여야 할 기능요소와 사용자와의 상호작용 흐름을 잘 표현할 수 있는 좋은 수단인 것 같다.

 

‘UML 실전에서는 이것만 쓴다의 저자 로버티 C. 마틴은 유스케이스를 최대한 단순하게 유지하라고 강조한다.

그는 모든 요구사항은 내일이면 다 바뀐다를 주장하며 유스케이스를 그때 그때 단순하게 작성하는 요구사항이라고 정의 내리고 있다. 유스케이사간의 관계라던지 선행,후행 조건 따위를 의미없이 논쟁하는 불필요한 짓은 일체 하지 말라고 한다.

 

나 역시도 틀린 말은 아니라고 본다.

시스템 사용자(의뢰자)는 시스템 초기 설계시 분명한 요구사항을 원활히 표현하지 못하는 경우도 허다하고 현실적이지 못하고 시스템 이해 부족으로 발생하는 요구사항의 오류를 범하기도 한다. 물론 아무리 많은 공을 들여 요구사항을 분석했다고 하여도 시스템 개발 중간에 대체로 요구사항이 변경되거나 개발 중인 시스템을 상당부분 고칠수 밖에 없는 추가 요구사항을 내놓기도 한다. 분명한 것은 요구사항 분석을 기록하는 유스케이스 다이어그램을 거추장스럽게 치장하는데 시간을 낭비할 필요가 없는 것이다. 중요한 것은 요구사항, 요구사항 이해, 요구사항이 잘 반영된 시스템 설계이다. 유스케이스 다이어그램 그 자체가 중요한 것은 아니다. 유스케이스 다이어그램 작성이 목표가 되어서는 안될것이다.


빠짐없이 잘 이해된 요구사항을 표준적이고 약속된 표기법을 이용해 서로가 쉽게 해석할 수 있는 다이어그램을 요구사항 분석,설계의 수단으로 사용하여야 할 것이다.


그리고 늘 그렇지만 모든 것은 프로젝트의 성격, 제반 조건, 현재의 상황등에 유연하게 대처해햐 한다.
앞서 밝혔듯이 유스케이스 명세서는 대부분 필요하지만 전혀 필요하지 않을 수 도 있다.

 

 

* 참고 자료

- UML 실전에서는 이것만 쓴다 (로버트 C. 마틴)

- 초보자를 위한 UML 객체 지향 설계 (Joseph Schmuller)

- UML Components 컴포넌트 기반 소프트웨어 명세를 위한 실용적인 프로세스

(John Cheesman, John Daniels)

- 객체지향 CBD 개발 Bible (채흥석)


∵Commented by 이재학 at 2008-05-14 오후 2:17:43  
[질문1] 화살표의 방향성
=======================

Use Case의 '포함'부분의 그림과 '확장' 부분의 그림에서..
앞에서 '방향성을 반드시 표현해야 할 필요는 없다.' 고는 하셨는데...
시스템에서는 Actor가 입력을 받은 시스템이 처리하여 Actor에게 출력한다는
가정에서 인것으로 이해가 됩니다.

그럼...

(회원가입) ----> (우편번호찾기)
(회원정보수정) ----> (우편번호찾기)

이렇게 되면..

(회원가입), (회원정보수정)이 (우편번호찾기)를 포함하는 것으로 보이는데..이게 맞는가요?


흠...
UML이 모델링 언어라는 관점에서 볼 때는 화살표 자체가 가지는 방향성도
의미가 충분히 있을 것 같은데 말이죠..

앗! '------>' 가 방향성을 가지는 화살표가 아니라 그냥 표시일 뿐인가?


[질문2] 추상화 레벨
====================

예전에 제가 UML 공부할 때..
도대체 어느 선까지 내려가야 했는지 정말 어려웠습니다..
(회원가입)의 속을 들여다보면 (아이디중복체크), (본인인증) 등등의
Use Case(제가 보기엔 이런 것들도 Use Case네요..)가 있을 수 있자나요..
물론 더 안쪽으로 깊숙히 들어갈 수도 있구요..

결론 부분을 보면 최대한 단순화시키라는 내용인데요..
단순도 주관적으로 볼 때 단순이자나요..

정녕..모델러 맘대로 추상화레벨을 잡아야 하는가요?
단순화도..모델러가 단순하다고 느끼면 단순한 건가요? 모델은 의사소통의 도구로도 쓰이는데 말이죠..
아니면 모델러가 요구사항을 이해했을 당시의 추상화 레벨인가요?

p.s
제가 추상화 레벨때문에 누구한테 물어볼 사람도 없고..해서..
독학하다가 포기했었습니다..ㅜㅜ

강좌 좋아요~!! 별5개!!
∵Commented by 박종명 at 2008-05-14 오후 2:18:21  
[질문1] 에 대한 답변
=====================

본문글에서 언급한 방향성은 Actor 와 UseCase 간의 방향성에 관련한 내용이었습니다.
Actor와 UseCase 간의 상호작용은 Communicate-Association(커뮤니케이트 연관관계)로 정의됩니다.
즉 방향성은 Actor와 UseCase 의 커뮤니케이션의 방향,시작을 나타내는 역할을 합니다.
(이 연관관계는 방향성이 있는 실선으로 표시됩니다)

UseCase 의 포함과 확장에서의 점선과 방향은 UML 표준 표기법입니다.
저 같은 경우에는 아래와 같은 접근으로 생각합니다.
A 가 B 를 포함한다 : A ---> B
B 가 A 를 확장시킨다(A가 B로 인해 확장된다) : B ---> A


[질문2] 에 대한 답변
=====================

제 생각엔 유스케이스 다이어그램은 시스템의 기능집합의 개념으로 조금은 상위수준으로 추상화를
해야할 필요가 있다고 생각합니다.

언급하신 "(회원가입)의 속을 들여다보면 (아이디중복체크), (본인인증)" 의 경우
회원가입이라는 유스케이스에 포함관계로 간단히 정의하거나 설명만 달아도 될것으로 보입니다.

단, 실제 "본인인증" 이라는 것도 내부적으로는 복잡한 프로세스를 가질수도 있습니다.
그러나 이것은 실제 개발자에게 더 필요한 정보로써 필요시 유스케이스 명세서나
다른 다이어그램(시퀀스 등)으로 대체할수 있을것으로 보입니다.
(어떻게 보면 사용자는 본인인증이라는 과정이 개입된다는 정도만 알면 되지 않을까요?)

이 부분은 저도 똑같이 고민되고 아직도 조심스럽게 접근하고 있습니다^^;
알고 보니 모두 같은 고민을 하네요...
∵Commented by 이재학 at 2008-05-14 오후 2:19:00  
답변 감사감사
이름
비밀번호
홈페이지
YP <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요