🔯 USE CASE 다이어그램 (유스케이스)


동적(행위) 다이어그램으로 시스템 내의 활동들의 흐름을 보여줌
여러 업무 프로세스를 설명하는데 자주 활용

 

 

🔯 유스케이스 다이어그램 구성 요소


1) 시스템(System) 만들고자 하는 프로그램을 나타낸다.
2) 액터(Actor) 시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템)을 말한다.
3) 유스케이스(Usecase) 사용자 입장에서 바라본 시스템의 기능
시스템이 액터에게 제공해야 하는 기능으로 시스템의 요구사항을 나타낸다.
4) 관계(Relation) 액터와 유스케이스 사이의 의미있는 관계를 나타낸다. 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있으며 의존관계는 포함(Include), 확장(Extend)로 나눠진다.

 

🖤 액터

  • 시스템과 상호작용을 하는 시스템 외부의 존재 (개발 대상에 따라 달라질 수 있음)
  • 시스템 관점에서 바라본 사용자의 역할을 뜻해야함

 

 

🖤 유스케이스

개발 대상이 되는 시스템이 제공하는 개별적인 기능을 뜻함.
시스템 동작 하나의 기술, 사용자가 인지할 수 있는(눈에 보이는) 하나의 기능 단위

 

 

🔯 유스케이스 다이어그램 관계


🖤 액터와 유스케이스 간의 연관 관계 방향

유형 설명 연관 관계 방향
활성화 액터가 유스케이스를 활성화 시킴
수행결과 통보 유스 케이스 결과가 액터에게 통보 됨
외부 서비스 요청 외부 시스템에 서비스 실행을 요청함

 

🖤 유스케이스 다이어그램 관계 종류

유형 설명 관계 방향
연관 관계 유스케이스와 액터 사이에 상호작용이 있다는 뜻
포함 관계
<include>
한 유스케이스가 다른 유스케이스의 기능을 포함하는 관계
(두 개의 유스케이스 간의 의존성을 나타내며, 반드시 해야하는 관계)

 기본 유스케이스의 시나리오가 진행되면서 포함 유스케이스의 시나리오를 반드시 실행해야 한다는 뜻
(포함 유스케이스가 실행되지 않는다면 기본 유스케이스가 본연의 기능을 발휘하지 못하는것을 의미)

⦁ 포함관계로 나타낸 ‘포함 유스케이스’가 다른 유스케이스에서 사용된다면 더욱 가치있는것이 된다.
포함관계로 포함 유스케이스를 따로 만드는 큰 이유를 ‘재사용'에 두고 있다.

! 기존의 유스케이스에서 포함된 유스케이스 방향을 가리키는 점선 화살표를 그림
확장 관계
<extend>
기본 유스케이스에서 특정 조건이나 액터의 선택에 따라 발생하는 유스케이스 (선택적으로 할 수 있는 관계)

! 확장된 유스케이스에서 기존의 유스케이스 방향을 가리키는 점선 화살표를 그림
일반화(상속) 관계 유사한 유스케이스들 또는 액터들을 추상화한 하나의 유스케이스로 그룹핑하여 이해도를 높힌 관계

! 자식 유스케이스에서 부모 유스케이스 방향으로 삼각형 실선 화살표를 그림
의존관계 (점선)  포함관계
여러 유스케이스에서 공통적인 기능의 표현 (재사용) → 의존함
 확장관계
한 유스케이스에서 부가적인 부분 기능의 표현  의존하지 않음

⦁ 확장 관계와의 차이점
일반화 관계에 있는 자식 유스케이스들은 부모의 속성들을 물려받기 때문에, 부모 유스케이스가 해당된 모든 포함, 확장 관계를 만족해야 합니다.
반면에 확장 관계에 있는 유스케이스는 속성을 물려받은 것이 아니므로, 기존 유스케이스와 다른 유스케이스와의 관계를 만족하지 않아도 됩니다.
 

 

 

 

🔯 유스케이스 다이어그램 예시


🖤 유스케이스 다이어그램 상황별 예시 1

더보기
>> 위의 그림1~3 모두 어디에 중점적으로 의미를 두느냐에 따라 모델은 항상 달라진다.
그림1 : 유스케이스 다이어그램을 작성할 때 왼쪽 위에서 오른쪽 아래방향으로 시간적인 순서 가 되도록 작성하는 가이드에 맞춰서 표현한 예
그림2 : 그림1에서 <include> 포함관계를 같이 표시한 예
그림3 : 그림2가 너무 복잡해서 활성화 부분은 뺀 내용

답이 없다! 다만 include를 쓰느냐 마느냐의 문제는 재사용성에 중점을 두고 모델링을 하는 것이 좋다

 

* 유스케이스 다이어그램을 작성할 때 시나리오 흐름 즉 시퀀스 구조를 생각하면서 그리는 사람들이 존재

→ 이는 ‘제품주문’이라는 행위를 하기 위한 ‘제품조회'라는 사전조건과 ‘주문결제'라는 사후조건을 생각한 것이다.

 

  1. 연관관계(실선)는 액터와 유스케이스 사이에서만 사용 가능하다. 유스케이스와 유스케이스 사이에서는 사용할 수 없다.
  2. 의존관계(점선)는 유스케이스와 유스케이스 사이에서만 사용할 수 있다.
  3. 일반화 관계는 액터와 액터 사이, 유스케이스와 유스케이스 사이에서만 사용 가능하다.

🖤 유스케이스 다이어그램 상황별 예시 2

더보기

* ‘로그인’은 과연 포함 유스케이스일까??

그림1. (포함 유스케이스이다)
 아마도 ‘로그인’ 유스케이스는 다른 유스케이스 시나리오의 첫번째 부분을 담당
: 다른 유스케이스들의 ‘사전조건’이다. (인증과 같은 의미)
 하지만 모든 유스케이스 마다 로그인 유스케이스를 포함관계로 만들게 되면 아주 복잡 한 모델링이 될 것이다.
그림2. (포함 유스케이스가 아니다)
사전조건 역할의 유스케이스는 포함관계보다 독립적인 유스케이스로 정의하는게 가독성 을 높이고 관리가 용이하다.
독립적인 유스케이스로 둬도 개발자나 사용자들도 서로가 로그인을 해야만 다른 서비스 를 할 수 있다는 건 기정 사실처럼 알기 때문에 복잡하게 그리지 말자는 것!
액터의 입장에서 요구하는 진정한 서비스는 로그인 보다 그 외의 유스케이스이다!! 거 기에 포커스를 맞추자!!

🖤 유스케이스 다이어그램 상황별 예시 3

더보기

* 회원관리라는 한 유스케이스가 등록,조회,수정,탈퇴의 의미를 가질 때, 이 기능을 활성화 하는 액터인 회원, 관리자는 동일한 기능을 가져야 되지만? 회원등록과 같은 기능은 회원만 해당되는 기능이기 때문에 다음과 같이 회원등록을 독립적인 유스케이스로 뽑아내야 된다.

🖤 유스케이스 다이어그램 상황별 예시 4

더보기

* 유스케이스는 구체적이어야되고 사용자가 인지 할 수 있는 하나의 기능 단위여야 된다.

* 하나의 독립적인 기능을 구성하는 다양한 세부 상황은 하나의 유스케이스로 표현되어야 된다.

 

'DB > 요구사항확인' 카테고리의 다른 글

3. UML(Unified Modeling Language)  (0) 2022.05.26
1. 요구사항 확인  (0) 2022.05.23
유스케이스  (0) 2022.05.17