본문 바로가기

computer/DataBase

유스케이스 상세화 과정

유스케이스 상세화 과정

 

시나리오 검토와 정련(옵션)

유스케이스 이벤트 흐름 상세화

유스케이스 이벤트 흐름 구조화

액터와 다른 유스케이스들과의 관계 전개

유스케이스 특별 요구 사항 묘사

통신 프로토콜 정의

유스케이스 사전 조건 묘사(옵션)

유스케이스 사후 조건 묘사(옵션)

확장 포인트 묘사(옵션)

결과 검토

 

 

Use-Case Specification

 

1.         Use-Case Name

1.1          Brief Description

 

2.         Flow of Events

2.1          Basic Flow

2.2          Alternative Flows

2.2.1     <First Alternative Flow>

2.2.2     <Second Alternative Flow>

 

3.         Special Requirements

3.1          <First Special Requirement>

 

4.         Preconditions

4.1          <Precondition One>

 

5.         Postconditions

5.1          <Postcondition One>

 

6.         Extension Points

6.1          <Name of Extension Point>

 

 

<분기 형식의 유스케이스 예제>

유스케이스

유스케이스 이벤트 흐름

주문을 관리한다

Main Flow

Sub Flow 1 주문을 접수한다

Sub Flow 2 주문 정보를 조회, 수정, 삭제한다.

Sub Flow 3 미등록 고객은 새로 등록한다.

Sub Flow 1 주문을 접수한다.

전화번호로 고객을 확인한다.

Sub Flow 4 상품 입력

주문 정보를 저장한다.

Sub Flow 2 주문 정보를 조회, 수정, 삭제한다.

Sub Flow 3 미등록 고객은 새로 등록한다.

Sub Flow 4 상품 입력

주문 상품의 이름과 수량을 입력한다.

시스템은 입력된 상품의 상품 정보를 표기한다.

상품별로 수량을 곱한 상품별 합계 공급가액을 계산한다.

주문 상품이 입력될 때마다 총합계 금액을 별도로 표기한다.

 


<유스케이스 명세서 사례>

1.         유스케이스 이름 : 주문을 관리한다.

1.1           Purpose

주문을 관리하다 유스케이스의 목적은 주문 담당자가 약사로부터 상품을 주문 받아 주문서를 작성하는 주문서 접수와 작성되어 저장된 주문서의 수정과 삭제를 관리하는 것이다.

1.2           Local View

<유스케이스 실현관계 UML 삽입 자리>

 

2.         Flow of Events

주문서 관리는 첫 화면에 기존의 주문서를 조회 결과를 나타내면서 시작된다. 이 유스케이스에는 주문서 접수, 주문서 수정/삭제, 그리고 주문서 삭제 흐름을 포함하고 있으며 주문 담당자는 주문서를 새로 접수하거나, 주문서를 조회하고 수정하거나, 혹은 주문서를 삭제한다.

2.1           주문서 접수 – Basic Flow

이 유스케이스는 주문 담당자가 새 주문서 작성 버튼을 누르면서 시작한다. 새 주문서 작성 버튼을 누르면 주문서 번호를 정해진 규칙에 따라 새로 생성하고 고객을 새로 지정하며 주문 받은 상품을 입력하고 주문서를 저장한다.

2.1.1      고객지정

2.1.1.1      창의 리스트 박스에서 해당 고객 지정으로 해당 고객 정보 조회

2.1.1.2      이 정보에는 고객 코드, 고객 이름, 고객 주소가 포함된다.

2.1.1.3      주문서를 조회할 때는 창의 리스트 박스에 지정된 고객에 대한 정보가 조회된다.

2.1.2      주문서 번호 생성

주문서 번호는 두 개의 부분으로 구성된다. 앞의 8자리는 년도를 포함한 날짜 부분이고 뒤에는 해당일의 일련 번호이다. 두 부분의 연결은 대쉬(-)로 연결한다. 날짜 부분은 2003년 8월 1 이라면 20030801이 되고 일련 번호는 해당일의 저장된 주문서 번호 중 가장 높은 숫자에 1을 더한 숫자로 지정하되 해당일의 첫 주문서라면 0001이 된다. 이 두 부분을 합하면 20030801-0001이 주문서 번호가 된다.

2.1.3      주문서 접수

2.1.3.1      새 주문서 버튼으로 주문서 번호 생성 후 주문서 접수 준비

2.1.3.2      고객 리스트 박스에서 고객을 지정한다(고객 정보 자동 나열).

2.1.3.2.1             상품 리스트에서 주문 상품을 지정한다.

2.1.3.2.2             주문 상품의 주문 수량을 입력한다.

2.1.3.2.3             주문 상품 입력이 끝나면 주문서를 저장한다.

2.2           Alternative Flow

2.2.1      주문서 조회

2.2.1.1      조회할 고객을 지정한다.

2.2.1.2      조회 기간을 입력한다.

2.2.1.3      조회된 주문서 번호 중에 원하는 주문서 번호를 지정한다.

2.2.1.4      지정된 주문서 번호에 해당하는 주문서를 나타낸다.

2.2.2      주문서 수정

2.2.2.1      조회된 주문서를 대상으로 수정 버튼을 누른다.

2.2.2.2      주문서 수량을 수정한다.

2.2.2.3      수정된 주문서를 저장한다.

2.2.3      주문서 삭제

2.2.3.1      조회된 주문서를 대상으로 삭제 버튼을 누른다.

2.3           Exceptional Flows

2.3.1      주문 상품이 리스트에 없을 경우

2.3.1.1      리스트에 없는 상품을 주문은 재고가 없어 주문 접수 불가

2.3.2      주문 상품의 재고가 부족한 경우

2.3.2.1      먼저 재고 수량만큼만 주문 수량을 접수한다.

 

3.         Special Requirements

3.1           고객 정보 조회 검색 시간

3.1.1      고객 정보 조회 검색 시간은 30초 이내에 완료되어야 한다.

 

4.         Pre-conditions

일반적인 가설 : 이것은 네트워크와 서버가 정상적으로 작동하는 것을 가정한 것이다.

4.1           Logged into the System

4.1.1      주문 담당자는 반드시 먼저 login 하여 주문 접수 가능한 상태에 있어야 한다.

4.2           Access to Order Functionality

4.2.1      주문 담당자는 주문 관리 기능에 대한 기능을 잘 이해하고 관리할 수 있다.

4.2.2      고객 리스트와 상품 리스트가 준비 완료되어 있어야 한다.

4.2.3      모든 고객에 대한 완벽한 정보가 리스트에 모두 입력되어 있어야 한다.

4.2.4      모든 상품에 대한 정보가 리스트에 모두 입력되어 있어야 한다.

 

5.         Post-conditions

5.1           주문서가 접수되거나 수정, 삭제 되었을 때

5.1.1      확인 메시지를 주문서 번호와 함께 나타낸다.

5.2           권한 없는 버튼 작동 경우

5.2.1      작동할 수 없는 원인에 대한 메시지를 나타낸다.

 

6.         Appendix

6.1           나타낼 고객 정보 항목 : 고객 이름, 고객 주소, 고객 코드

6.2           나타낼 상품 정보 항목 : 상품 코드,상품 이름, 상품 재고, 상품 단가(상품별 합계, 주문서 합계)

 

출처 : Tong - I제로I님의 UML / OOAD통