[프로젝트 방법론] 유즈케이스 작성 및 API 설계

프로젝트를 기획하고 개발에 들어가기 직전에 유즈케이스(Use Case) 작성과 API 설계 과정을 거쳐야 합니다.

 

1. 유즈케이스

유즈케이스 또는 유즈케이스 다이어그램이란 사용자, 그리고 사용자가 수반한 다른 유즈 케이스 간의 관계를 보여주는 사용자-시스템 간 상호작용의 표현이다. 유즈케이스 다이어그램은 각기 다른 종류의 시스템 사용자와 각기 다른 유즈 케이스 를 식별할 수 있으며 다른 유형의 다이어그램이 수반되기도 한다. 유즈케이스는 보통 원이나 타원으로 표현된다.

(위키피디아 인용)

 

우리는 개발에 앞서 유즈케이스를 만듦으로써 하고자 하는 것을 더욱 명확하게 할 수 있다. 그래서 어떤 시스템이나 서비스를 설계할 때 전체적인 사용자의 이용패턴을 분석해 놓은 것이라고 보면된다.

 

대표적인 도구로는 Lucidchart라는 것이 있고 UI가 상당히 이쁘다. 하지만 유료플랜을 사용하지 않으면 많은 제약이 있어 무료 도구 중에 diagrams.net(구 draw.io) 라는 것을 많이 사용한다. 

 

app.diagrams.net 으로 들어가면 예전 draw.io의 시작페이지로 열려 연동하기 원하는 플랫폼을 선택할 수 있으니 참고하자.

 

단점이 있다면 diagrams.net에는 유즈케이스 전용 템플릿이 없기 때문에 그냥 원하는 템플릿 혹은 blank 페이지를 선택하여 개조해서 사용하면 된다.

 

 

2. 유즈케이스 구성요소

시스템 (Systems)

개발하고자 하는 그 자체를 말하며, 웹사이트, 소프트웨어 컴포넌트, 애플리케이션 등 다양한 시스템을 말할 수도 있는 것이다.

 

시스템의 범위를 정의하고 flow가 발생하는 영역의 경계를 정의한다.

 

더 쉽게 말해서 사각형 박스 범위 안에 있는 흐름은 시스템 안에서만 일어나고, 범위 밖에 있는 흐름은 시스템 안에서 일어나지 않는다.

 

사각형 형태로 표시하고, 상단에 시스템의 이름을 정의한다.

예시에선 회색 사각형이 시스템에 해당하는 영역이다.

 

 

액터 (Actors)

시스템 외부에서 시스템과 상호작용하여 특정한 행위를 하는 객체를 뜻한다.

 

액터는 사람이 될 수도 있고, 회사, 또 다른 시스템, 또는 외부 장비가 될 수도 있다..

 

액터는 반드시 하나 이상의 유즈케이스들과 상호작용해야하며 액터 이름은 개인적이거나 무언가를 특정하여 지정하면 안된다.

• 예시) Bryan, Chase Bank(X) -> Customer, Bank(O)

 

액터에는 두 가지 종류가 있다.

1. 프라이머리 액터(Primary Actor): 시스템을 사용하고, 직접적으로 이득을 보는 액터로 보통 졸라맨으로 표현된다. 일반적으로 시스템의 왼쪽에 위치한다.

 

2. 세컨더리 액터(Secondary Actor): 프라이머리 액터가 목적을 달성하기 위해 도움을 주는 액터이며 사각형 박스에
<<actor>> 를 입력하여 표기한다. 일반적으로 시스템의 오른쪽에 위치한다.

 

 

유즈케이스

시스템 내에서 일련의 작업을 수행하기 위한 행위들을 나타내며 타원형으로 표기한다.

• 예시) 은행 앱의 경우 로그인, 잔고 확인, 환전, 결제 등이 될 수 있다.

 

관계 (Relationships)

선(line) 또는 화살표(Arrow)로 나타내며, 이어진 2개의 액터 또는 유즈케이스들이 서로 상호작용함을 알려주는 표기이다.

 

관계 종류로는 4가지가 있다.

 

1. 연관 관계 (Association)

유즈케이스와 액터 사이에 상호작용이 있다는 뜻으로, 보통 실선으로 표시한다.

사용자는 로그인과 결제 행위를 모두 하지만, 은행 입장에서는 로그인 과정에 관여하지 않아도 된다.

때문에 사용자는 로그인과 결제 모두와 연관 관계를 가지며, 은행은 결제에만 연관 관계를 가진다.

 

2. 포함 관계(Include)

포함 관계는 두 개의 유즈케이스 간의 의존성(dependency)을 나타낸다.

하나의 유즈케이스가 실행될 때 포함 관계에 있는 유즈케이스가 반드시 실행되어야 한다는 뜻을 가지고 있습니다. 기존의 유즈케이스에서 포함된 유즈케이스 방향을 가리키는 점선 화살표를 그리고, <<include>>를 화살표 중앙에 표시한다.

 

사용자가 로그인 작업을 수행할 때마다 비밀번호를 항상 확인해야만 한다. 이런 경우 비밀번호 확인이 로그인에 포함되었다고 볼 수 있고, 로그인 유즈케이스에서 비밀번호 확인 유즈케이스 방향으로 화살표를 그린 후 중앙에 <<include>>를 표시하여 포함 관계를 나타낸다.

 

3. 확장 관계 (Extend)

확장 관계는 두 개의 유즈케이스 간의 확장성을 나타냅니다.

하나의 유즈케이스가 실행될 때 포함 관계에 있는 유즈케이스가 특정 상황에서만 실행된다는 뜻을 가지고 있습니다.

 

확장된 유즈케이스에서 기존의 유즈케이스 방향을 가리키는 점선 화살표를 그리고, <<extend>>를 화살표 중앙에 표시한다.

 

사용자가 로그인 작업을 수행할 때마다 로그인 에러를 출력하진 않는다.

로그인 에러 출력은 오직 잘못된 비밀번호를 입력한 상황에서만 실행된다.

이러한 경우 Log에는 error가 출력되는 것이 로그인의 확장 관계에 있다고 볼 수 있고, 로그인 에러 출력 유즈케이스에서 로그인 유즈케이스 방향으로 화살표를 그린 후 중앙에 <<extend>>를 표시하여 포함 관계를 나타낸다.

 

 

4. 일반화 관계 (Generalization)

일반화 관계는 부모 유즈케이스와 자식 유즈케이스들 간의 상속관계를 나타낸다.

 

특정 유즈케이스들이 하나의 유즈케이스의 특수화된 유즈케이스라는 뜻을 가지고 있다. 자식 유즈케이스에서 부모 유즈케이스 방향으로 삼각형 실선 화살표를 그린다.

 

확장 관계와의 차이점

일반화 관계에 있는 자식 유즈케이스들은 부모의 속성들을 물려받기 때문에, 부모 유즈케이스가 해당된 모든 포함, 확장 관계를 만족해야 한다.

반면에 확장 관계에 있는 유즈케이스는 속성을 물려받은 것이 아니기 때문에 기존 유즈케이스와 다른 유즈케이스와의 관계를 만족하지 않아도 된다.

 

체크카드로 결제와 무통장입금 결제는 결제 유즈케이스와 특수화 관계에 있다.

때문에 체크카드와 무통장입금 결제는 결제 유즈케이스와 일반화 관계에 있다고 볼 수 있다.

 

체크카드와 무통장입금은 결제와 일반화 관계에 있기 때문에 해당 유즈케이스들이 실행될 시 부모 유즈케이스와 포함 관계에 있는 잔액 확인 유즈케이스를 실행해야만 하고, 실패 시 확장 관계에 있는 잔액 부족 알림을 실행해야 한다.

 

하지만 잔액 부족 알림 유즈케이스는 결제와 일반화 관계가 아닌 확장 관계이기 때문에, 결제와 포함 관계인 잔액 확인 유즈케이스와 포함관계에 있지 않다.

 

 

3. 유즈케이스 작성 순서

1. 시스템 정의

시스템 영역과 이름을 정의한다.

 

2. 액터 정의

사용자(Primary Actor)를 정의한다.

시스템과 상호작용하는 외부 시스템 (Secondary Actor)를 정의한다.

 

3. 유즈케이스 정의

Actor가 요구하는 서비스를 식별한다.

Actor들이 시스템과 상호작용하는 행위를 식별한다.

 

4. 관계 정의

Actor와 Actor 사이의 관계를 정의한다.

Actor와 유즈케이스 사이의 관계를 정의한다.

유즈케이스 간의 관계를 정의한다.

 

5. 유즈케이스 구조화

두 개 이상의 유즈케이스의 공통된 서비스를 추출하여 일반화시킨다.

 

 

 

Reference

• https://devjaewoo.tistory.com/15