UML Diagram_Usecase-Diagram

Usecase Diagram

유스케이스 다이어그램은 프로젝트에 대한 요구사항을 정의하고 세부기능을 분석하여 개발 범위를 정할 때 작성한다. 즉, 요구사항 정의 단계에서 고객도 이해할 수 있도록 문서화하는 것을 말한다.

1-1. 구성요소(Component)

ACTOR(액터)

시스템의 외부에서 시스템과 상호작용하는 사람

• 사용자 액터

일반 사용자(ex: 도서대출자)

관리자(ex: 사서)

시스템관리자(일반적으로 제외)

• 외부시스템 액터

ex: SMS 전송 시스템, 도서주문 시스템

• 장치 액터

ex: 휴대폰, 냉장고, 에어컨

USECASE(유스케이스)

시스템이 제공할 기능적 단위

-표기방법

"~하기"의 동사 형태로 나타낸다.

ACTOR/USECASE간 관계

특정기능을 위하여 어떤 액터들이 상호작용을 하는지 표현

• 액터와 유스케이스 사이의 연관 관계

해당 유스케이스 기능과 관련 있는 액터 명시

• 액터와 액터 사이의 일반화 관계(상속관계)

상위 액터의 특성이 하위 액터에도 적용됨을 뜻함

• 유스케이스 사이의 포함 관계 <<include>>

복수 개의 유스케이스에 존재하는 공통적인 기능을 추출해 별도의 유스케이스를 정의하는 것

• 유스케이스 사이의 확장 관계 <<extend>>

기존 유스케이스와 성격이 다른 추가적인 기능을 별도의 유스케이스로 표현하는 것

※예제, 당근마켓 usecase-diagram

<<include>>: 당근마켓 시스템의 복수개의 유스케이스에 존재하는 공통적인 기능을 추출해 별도의 유스케이스로 만듦

당근마켓에서 사용자가 판매게시물을 올리고, 게시물 작성자에게 채팅을 보내기 위해서는 반드시 사용자가 해당 지역에 위치함을 인증해야 한다. 이와 같이 복수 개의 유스케이스에서 공통적으로 필요로 하는 기능인 "지역 인증하기"가 <<include>>의 예이다.

<<exctend>>: 당근마켓 시스템의 기존의 유스케이스와 성격이 다른 추가적인 기능을 별도의 유스케이스로 만듦

당근마켓에서 사용자가 상품을 구매할 때 당근페이를 통해 송금할 수 있다. 하지만 반드시 당근페이만을 사용해야하는 것은 아니다. 따라서 "송금하기"가 <<extend>>의 예이다.

※패키지별 구조화

1-2. 요구사항 정의 프로세스

유스케이스 모델이 나오면 각각의 유스케이스 모델별로 유스케이스 명세서를 만든다.

- 유스케이스 상세화: 유스케이스 모델의 개별 유스케이스에 대한 명세서를 작성한다.

- 유스케이스 구조화: 유스케이스 모델과 명세서에 대한 확장성과 가독성을 높인다.

- 유스케이스 조직화: 서로 관련 있는 유스케이스끼리 패키지를 이용해 조직화함으로써 유스케이스 모델의 규모와 복잡성을 관리한다.

유스케이스 명세서

유스케이스 모델에 기술된 개별 유스케이스에 대한 구체적이고 상세한 기능을 정의한 문서

유스케이스 명세서를 구성하는 주요 항목

1)개요

개별 유스케이스에 대한 간략한 설명

모든 이해관계자들은 가장 먼저 명세서의 개요 항목을 통해서 유스케이스를 이해한다.

2)관련 액터

: 유스케이스와 상호작용을 하는 모든 액터를 나열한다.

: 유스케이스를 개발하기 위해 필요한 외부 인터페이스를 파악하는데 도움이 된다.

-주 액터: 실제 유스케이스를 사용하는 액터

-보조 액터: 주 액터를 제외하고 해당 유스케이스와 연관된 모든 액터들

유스케이스를 개발하기 위해 필요한 외부 인터페이스를 파악하는데 도움이 된다.

3)우선 순위

유스케이스의 중요성을 의미

기능의 중요도+개발의 난이도

유스케이스에 대한 프로젝트 관리시 활용

-우선순위 항목은 개발의 순서를 결정할 때 활용

4)선행 조건

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

5)후행 조건

유스케이스의 수행이 완료된 후에 만족되어야 하는 조건

6)시나리오

-기본 시나리오: 가장 일반적이고 정상적인 하나의 상황

-대안 시나리오: 특수한, 비정상적인 상황

대안시나리오는 다시 선택 시나리오와 예외 시나리오로 분류

-선택 시나리오: 액터의 능동적인 옵션 선택, 시스템의 상태에 따른 선택, 데이터의 유형에 따른 선택

-예외 시나리오: 부적절한 입력 형식 예외, 입력 시간 경과 예외, 시스템 처리 예외

(1)로그인 관리하기

기본시나리오

-사용자는 국가를 선택한다.

-사용자는 핸드폰 번호를 입력한다.

-시스템은 SMS 전송 시스템에게 적절한 인증번호를 전달함으로써 사용자 인증을 요청한다.

-시스템은 Timer 시스템에게 5분을 전달함으로써 사용자가 적절한 시간내에 인증번호를 입력할 수 있도록 한다.

-사용자는 SMS 전송 시스템으로부터 받은 인증번호를 입력한다.

-시스템은 사용자가 5분이내로 올바른 인증번호를 입력하였다면 사용자를 로그인 상태로 바꾼다.

대안시나리오

A.잘못된 핸드폰 번호 입력시

-시스템은 잘못된 전화번호 입력 알림을 출력한다.

-시스템은 핸드폰 번호를 다시 입력받는다.

B.일일 문자 인증 가능 건수 초과

-시스템은 믄자 인증 가능 횟수 초과 알림을 출력한다.

-시스템은 핸드폰 번호를 다시 입력받는다.

C.인증시간이 5분을 초과했을 경우

-시스템은 인증시간 초과알림을 출력한다.

-사용자가 인증번호를 다시 발급받는다.

-시스템은 SMS 전송 시스템에게 새로 발급받은 인증번호를 전달함으로써 사용자 인증을 요청한다.

(2)개인정보 관리하기

기본시나리오

-시스템은 사용자의 정보를 불러온다.

-사용자는 변경하고 싶은 정보를 수정한다.

-시스템은 사용자로부터 수정정보를 입력받고 해당 정보를 변경한다.

대안시나리오

A.사용자가 30일 이내에 닉네임을 변경했을 경우

-시스템은 닉네임 변경 불가 알림을 출력한다.

B.같은 동네에 동일한 닉네임의 사용자가 이미 존재하는 경우

-시스템은 닉네임 변경 불가 알림을 출력한다.

-시스템은 닉네임을 다시 입력받는다.

(3)지역 선택하기

기본시나리오

-시스템은 사용자의 현재 위치를 기준으로 근처동네 정보를 가져온다.

-사용자는 시스템이 가져온 근처동네를 선택하거나, 동명(읍,면)을 검색한다.

-시스템은 사용자가 입력한 동명을 기준으로, 근처동네 정보를 가져온다.

-사용자는 "내 동네"를 선택한다.

-사용자는 "내 동네"를 기준으로 정보를 받고 싶은 동네 범위를 선택한다.

대안시나리오

A.사용자가 존재하지 않는 동명을 검색한 경우

-시스템은 동명 검색 실패 화면을 출력한다.

-시스템은 동네 이름을 다시 입력받는다.

(4)판매게시물 검색하기

기본시나리오

-사용자는 게시물을 검색할 지역을 선택한다.

-사용자는 상품을 검색한다.

-시스템은 사용자가 선택한 지역, 해당 상품의 최신게시물 피드를 보여준다.

대안시나리오

A.사용자가 존재하지 않는 동명을 검색한 경우

-시스템은 동명 검색 실패 화면을 출력한다.

-시스템은 동네 이름을 다시 입력받는다.

(5)판매게시물 올리기

기본시나리오

-사용자는 게시물을 검색할 지역을 선택한다.

-사용자는 판매하고자 하는 물품의 제목, 카테고리, 내용을 필수적으로 입력한다.

-사용자는 판매하고자 하는 물품의 사진, 가격을 선택적으로 입력한다.

-시스템은 사용자가 올린 게시물을 게시물 피드에 올린다.

대안시나리오

A.사용자가 존재하지 않는 키워드를 검색한 경우

-시스템은 키워드 검색 실패 화면을 출력한다.

-시스템은 사용자가 원하는 경우, 해당 키워드 알림 설정을 등록한다.

(6)채팅하기(상품 문의하기)

기본시나리오

-사용자(구매자)는 게시물을 올린 판매자와 채팅을 시작한다.

-시스템은 판매자의 게시물 채팅목록에 해당 사용자(구매자)를 추가한다.

대안시나리오

A.사용자가 지역인증을 하지 않고 채팅을 시작하려고 하는 경우

-시스템은 지역인증 알림을 출력한다.

(7)지역인증하기

기본시나리오

-사용자는 시스템에게 지역인증을 요청한다.

-시스템은 GPS 시스템에게 사용자의 현재 위치 정보를 요청한다.

-시스템은 해당 지역의 등록된 GPS정보와 사용자의 위치정보가 일치하면 사용자의 지역인증상태를 변경한다.

대안시나리오

A.사용자의 선택지역과 현재위치가 일치하지 않을 경우

-시스템은 지역인증 실패 화면을 출력한다.

-시스템은 사용자에게 지역 재선택 여부를 물어본다.

(8)거래 후기 남기기

기본시나리오

-사용자는 거래 후기를 입력한다.

-시스템은 상대방에게 거래 후기를 등록한다.

(9)거래 상태 설정하기

기본시나리오

-사용자는 거래 상태를 설정한다.

-시스템은 판매 게시물의 거래 상태를 변경한다.

(10)끌올 설정하기

기본시나리오

-사용자는 끌올을 설정한다.

-시스템은 Timer 시스템에게 상품이 해당 시각으로부터 2일 12시간 내에 끌올 설정이 되었는지 확인한다.

-시스템은 해당 판매 게시물이 게시물 피드의 상단에 가도록 한다.

대안시나리오

A.사용자가 끌올하려는 상품이 2일 12시간 내에 끌올한 상품일 경우

-시스템은 끌올 실패 화면을 출력한다.

B.사용자가 하루에 5개의 상품을 끌올한 경우

-시스템은 끌올 실패 화면을 출력한다.

(11)약속잡기

기본시나리오

-사용자는 약속시간을 설정한다.

-시스템은 사용자가 입력한 약속 시간을 등록한다.

-시스템은 Timer에게 사용자가 설정한 약속시간을 전달함으로써 알림을 요청한다.

대안시나리오

A.사용자가 상대방과 대화를 나누지 않고 약속을 잡으려고 하는 경우

-시스템은 대화 후 약속을 잡을 수 있다는 알림을 출력한다.

B.사용자가 새벽시간에 약속을 잡으려는 경우

-시스템은 사용자에게 약속 시간을 재확인 받는다.