Skip to content

Use case Diagram(이하 유스케이스 다이어그램)는 시스템 요구사항을 시각적으로 표현하고 이해 관계자들간 커뮤니케이션을 원활하게 하기 위해서 사용되는 도구입니다. 사용자 요구사항으로부터 기능을 식별하고 API 엔드포인트로 매핑하는데 활용될 수 있습니다.

  • 유스케이스 다이어그램은 시스템과 액터의 관계를 표현합니다.
  • 시스템은 무슨 일을 할 수 있는지, 어떤 기능을 제공할 수 있는지를 정의하고, 액터는 시스템의 어떤 기능을 사용할 수 있는가를 정의합니다.
  • 유스케이스 다이어그램은 개발 초기에 작성하며 다음과 같은 상황에서 사용됩니다:
    • 비즈니스 모델링: 개발자, 기획자, 고객 사이의 이해관계를 공유하는데 사용됩니다.
    • 시스템 요구사항 식별: 시스템 설계도인 클래스 다이어그램, API 설계, 액티비티 다이어그램, 사용자 인터페이스, ERD를 설계하는데 사용됩니다.
    • 테스팅: 테스트를 수행할때 어떤 테스트가 존재하는지 식별이 가능합니다.

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

  • Use Case: 시스템이 할 수 있는 일을 동사 형태로 정의합니다. 관찰 가능한 결과를 산출해야 합니다. 예를 들면 게시글, 사용자 유저 정보, 계산 수행 결과가 있습니다.
  • Actor: 시스템에 접근하여 유스케이스를 실행할 수 있는 존재를 액터라고 부릅니다. 인간, 회사, 기계, 외부 시스템이 그 예시입니다.
  • System: 모델링하고자 하는 소프트웨어의 경계를 나타내는 요소입니다. 전체 시스템을 하위 시스템의 계층으로 구분할 수도 있습니다. 시스템 경계 안에 있는 요소들은 소프트웨어의 책임과 기능을 나타냅니다.
  • Relationships: 시스템의 유스케이스와 액터 간의 상호작용을 나타내는 요소입니다.
    • Association: 액터와 유스케이스 간의 직접적인 상호작용을 나타내는 관계입니다. 실선으로 연결되며, 선 끝에 화살표가 있는 경우도 있습니다. 예를 들어 고객 액터와 계좌 조회 유스케이스 간의 연관 관계는 "고객이 계좌 조회 기능을 사용할 수 있다" 로 표현됩니다.
    • Generalization: 일반화라는 뜻을 가지고 있습니다. 하나의 유스케이스나 액터가 다른 유스케이스나 액터의 일반화 개념을 나타냅니다. 예를 들어 직원 액터는 은행 직원과 관리자 액터의 일반화가 될 수 있습니다.
    • Include: 한 유스케이스가 다른 유스케이스를 반드시 포함해야 하는 관계입니다. 예를 들어 사용자가 게시글을 쓰기 위해선 로그인해야 할 경우, 게시글 쓰기 유스케이스는 로그인 유스케이스를 포함할 수 있습니다.
    • Extend: 한 유스케이스가 조건에 따라 다른 유스케이스를 확장할 수 있는 관계입니다. 기본 유스케이스에 옵션으로 사용할 수 있는 유스케이스라고 보면 됩니다.

실습#

자동차 렌탈 시스템을 예시로 들겠습니다. 먼저 액터를 식별해 봅시다. 자동차를 렌탈할 유저인 손님과 자동차 렌탈 서비스 직원, 카드 결제 인증 시스템(사람이 아니어도 됩니다)을 액터로 식별할 수 있을 것입니다. 모든 액터가 주체적일 필요는 없습니다. 카드 결제 인증 시스템은 손님에 의해 수동적으로 호출될 수 있습니다.

actors.png

다음으로는 유스케이스를 식별해봅시다. 시스템이 제공해야 하는 기능들이기 때문에 동사의 형태를 띄게 됩니다. 아래는 유저 정보에 접근하는 기능들에 대한 유스케이스입니다.

Use Cases.png

유스케이스 다이어그램에서 매우 중요한 관계를 그려보겠습니다. 관계는 위에서 설명했듯이 Association (호출), Generalization (일반화), Include(포함), Extend(확장)으로 나뉘어집니다.

Association Relationship#

Invocation Relationship으로도 불리우는 관계는 액터와 유스케이스가 직접적인 상호작용을 취하게 됩니다. 액터가 유스케이스를 직접 호출하기도 하고, 유스케이스가 수동적인 액터에게 요청을 전달하기도 합니다.

아래 그림은 “손님이 건넨 카드를 사용하여 직원이 카드 결제 인증 시스템에게 결제요청을 보내기” 시나리오에 해당하는 유스케이스 다이어그램입니다:

Make Payment.png

직원은 Make Payment 유스케이스를 호출하며, 카드결제 인증 시스템은 Make Payment에 의해 호출됩니다.

Generalization Relationship#

일반화 관계는 액터에서도 적용이 가능하고 유스케이스에서도 적용이 가능합니다.

  1. 액터 간 일반화 관계: 부모 액터의 Association을 자식 액터가 상속을 받아 부모가 호출할 수 있는 모든 유스케이스들을 자식 액터도 호출할 수 있게 됩니다.

    Actor Generalization.png

  2. 유스케이스 간 일반화 관계: 부모 유스케이스는 추상적인 기능 (Placeholder)을 상징하고, 이것을 구체적인 기능 (Specialized)으로 나눌 수 있습니다.

    Usecase Generalization.png

Include Relationship#

포함 관계의 유스케이스는 Base 유스케이스와 Included 유스케이스로 구분이 됩니다. Base 유스케이스가 호출되면 언제나 Included 유스케이스를 함께 호출하게 됩니다. 가장 대표적인 사례로 “로그인”을 들 수 있습니다. 로그인을 해야만 사용이 가능한 모든 Base 유스케이스들은 Login 유스케이스를 Include하게 됩니다.

Include Relationship.png

Extend Relationship#

확장 관계의 유스케이스는 Base 유스케이스와 Extended 유스케이스로 구분이 됩니다. Base 유스케이스가 호출되면 조건부로 Extended 유스케이스가 호출될 수도 있습니다. 예를 들어 게시판에 글을 쓸때 이미지를 업로드할 수도 있고 태그를 달 수도 있습니다. 이때 Post Article이 Base 유스케이스가 되고, Upload Image와 Select Tags들은 Extended 유스케이스가 될 수 있습니다.

Extend and Include Relationships.png

유스케이스 명세서: 커뮤니티 서비스#

1. 액터#

  • 사용자 (일반화)
    • 회원
    • 관리자

2. 유스케이스#

UC01: 로그인#

  • 액터: 회원
  • 설명: 회원이 인증을 받고 권한이 있는 기능에 접근할 수 있게 함.
  • 선행조건: 사용자가 등록된 계정을 가지고 있음.
  • 기본 흐름:
    1. 사용자가 로그인 페이지로 이동.
    2. 사용자가 사용자명과 비밀번호를 입력.
    3. 시스템이 자격 증명을 확인.
    4. 시스템이 권한이 있는 기능에 대한 접근을 허용.
  • 대안 흐름:
    • 자격 증명이 유효하지 않은 경우, 시스템이 오류 메시지를 표시.
  • 후행조건: 사용자가 로그인되어 권한이 있는 기능에 접근할 수 있음.
  • 관계: UC03, UC04, UC05에 의해 포함됨

UC02: 글 보기#

  • 액터: 회원
  • 설명: 회원이 인증 없이 글을 볼 수 있게 함.
  • 선행조건: 없음
  • 기본 흐름:
    1. 사용자가 볼 글을 선택.
    2. 시스템이 글 내용을 표시.
  • 후행조건: 사용자가 글을 봄.

UC03: 글 작성#

  • 액터: 회원
  • 설명: 회원이 새 글을 작성하고 게시할 수 있게 함.
  • 선행조건: 없음
  • 기본 흐름:
    1. 시스템이 UC01: 로그인 수행
    2. 사용자가 "새 글 작성" 옵션 선택.
    3. 사용자가 글 제목과 내용 입력.
    4. 사용자가 글 제출.
    5. 시스템이 글을 저장하고 게시.
  • 후행조건: 새 글이 게시되어 다른 사용자들이 볼 수 있음.
  • 관계:
    • UC01: 로그인 포함
    • UC06: 이미지 업로드에 의해 확장됨
    • UC07: 태그 선택에 의해 확장됨

UC04: 글 수정#

  • 액터: 회원
  • 설명: 회원이 기존 글을 수정할 수 있게 함.
  • 선행조건: 사용자가 글의 작성자임.
  • 기본 흐름:
    1. 시스템이 UC01: 로그인 수행
    2. 사용자가 수정할 글 선택.
    3. 사용자가 글 내용 수정.
    4. 사용자가 변경 사항 저장.
    5. 시스템이 글 업데이트.
  • 후행조건: 글이 새 내용으로 업데이트됨.
  • 관계:
    • UC01: 로그인 포함
  • UC06: 이미지 업로드에 의해 확장됨
  • UC07: 태그 선택에 의해 확장됨

UC05: 글 삭제#

  • 액터: 회원, 관리자
  • 설명: 회원이 자신의 글을 삭제하거나 관리자가 모든 글을 삭제할 수 있게 함.
  • 선행조건: 회원의 경우, 글의 작성자여야 함.
  • 기본 흐름:
    1. 시스템이 UC01: 로그인 수행
    2. 사용자가 삭제할 글 선택.
    3. 시스템이 확인 요청.
    4. 사용자가 삭제 확인.
    5. 시스템이 글 삭제.
  • 후행조건: 글이 시스템에서 삭제됨.
  • 관계: UC01: 로그인 포함 (회원의 경우)

UC06: 이미지 업로드#

  • 액터: 회원
  • 설명: 회원이 글 작성 중 이미지를 업로드할 수 있게 함.
  • 선행조건: 사용자가 글 작성 중임.
  • 기본 흐름:
    1. 사용자가 "이미지 업로드" 옵션 선택.
    2. 사용자가 이미지 파일 선택.
    3. 시스템이 이미지를 업로드하고 글에 첨부.
  • 후행조건: 이미지가 글에 첨부됨.
  • 관계: UC03: 글 작성을 확장함

UC07: 태그 선택#

  • 액터: 회원
  • 설명: 회원이 글 작성 중 태그를 추가할 수 있게 함.
  • 선행조건: 사용자가 글 작성 중임.
  • 기본 흐름:
    1. 사용자가 "태그 추가" 옵션 선택.
    2. 사용자가 글의 태그 입력 또는 선택.
    3. 시스템이 태그를 글과 연결.
  • 후행조건: 태그가 글과 연결됨.
  • 관계: UC03: 글 작성을 확장함

UC08: 사용자 차단#

  • 액터: 관리자
  • 설명: 관리자가 커뮤니티 서비스에서 사용자를 차단할 수 있게 함.
  • 선행조건: 관리자가 로그인한 상태임.
  • 기본 흐름:
    1. 관리자가 차단할 사용자 선택.
    2. 관리자가 차단 이유 제공.
    3. 시스템이 사용자를 차단하고 이유를 기록.
  • 후행조건: 사용자가 차단되어 더 이상 서비스에 접근할 수 없음.

3. 관계 요약#

  • UC01 (로그인)은 UC03 (글 작성), UC04 (글 수정), UC05 (글 삭제)에 의해 포함됨.
  • UC06 (이미지 업로드)와 UC07 (태그 선택)은 UC03 (글 작성)을 확장함.
  • UC02 (글 보기)는 회원 액터와 직접 연관됨.
  • UC08 (사용자 차단)과 UC05 (모든 글 삭제)는 관리자 액터와 연관됨.