유즈케이스 다이어그램 (Use Case Diagram)

유즈케이스 다이어그램 (Use Case Diagram) 가이드

1. 액터 (Actor)

시스템 외부에서 시스템과 상호작용하는 사람 또는 외부 시스템을 의미합니다. (졸라맨 모양과 명사로 표기)

사용자와 유사한 개념이지만, 하나의 사용자가 상황에 따라 여러 액터의 역할을 수행할 수도 있습니다.

액터의 분류 및 심화 개념

• Primary Actor (주 액터): 시스템을 통해 본인의 목표를 달성하려는 주체입니다. 유즈케이스를 시작(Initiate)하는 역할을 하며, 주로 시스템 경계의 왼쪽에 배치합니다. (예: 고객, 회원, 관리자)
• Secondary Actor (부 액터): 주 액터의 목표 달성을 위해 시스템에 도움을 주는 외부 존재입니다. 시스템의 요청에 응답하며, 주로 시스템 경계의 오른쪽에 배치합니다. (예: 결제 PG사, 외부 인증 서버, DB 시스템)
• 일반화/상속 (Generalization): 액터 간의 공통적인 속성이 있을 때 사용합니다.
  • 예: '비회원'과 '정회원'의 공통 기능을 '사용자'라는 상위 액터로 추상화하여 화살표(빈 삼각형)로 연결합니다.

---

2. 유즈케이스 (Use Case)

시스템이 액터에게 제공하는 개별적인 기능적 단위입니다. (타원형으로 표기)

유즈케이스 이름은 '상품', '로그인창' 같은 명사보다 '상품 조회', '로그인'과 같이 동사 위주로 명확하게 표현합니다.

액터는 하나 이상의 유즈케이스에 연결되어야 하지만, 일부 유즈케이스는 내부적 기능이므로 액터에 직접 연결되지 않을 수도 있습니다. 즉, 내부 처리 유즈케이스(예: '로그 기록 저장')는 액터 없이 시스템 내부에서만 동작합니다.

※ 사용자 관점에서 "무엇을 하는가"에 초점을 맞추며, '로그인', '주문하기'와 같이 가치 있는 기능 단위로 작성합니다.

---

3. 시스템 경계 (System Boundary)

설계하고자 하는 시스템의 물리적/논리적 범위를 정의합니다. (사각형으로 표기)

사각형 안에는 유즈케이스를 배치하고, 사각형 밖에는 액터를 배치하여 시스템 내부 기능과 외부 요소를 명확히 구분합니다.

---

4. 관계 (Relationship)

액터와 유즈케이스, 또는 유즈케이스 간의 상호작용을 나타냅니다.

관계(Relationship)의 종류와 사용법

• 연관 관계 (Association): 액터와 유즈케이스 간의 가장 기본적인 연결입니다. (실선으로 표기)
  
• 포함 관계 (Include): 하나의 유즈케이스를 수행할 때 반드시 함께 실행되어야 하는 하위 기능입니다. (점선 화살표 + <<include>>)
  
• 확장 관계 (Extend): 특정 조건이 만족될 때만 선택적으로 실행되는 부가 기능입니다. (점선 화살표 + <<extend>>)
  
• 일반화 관계 (Generalization): 유즈케이스 간의 추상화 및 그룹화 관계를 나타냅니다. (실선 화살표 + 빈 삼각형)
  

다중성 (Multiplicity)

연관 관계 실선 끝에 숫자를 표기하여 상호작용에 참여하는 액터의 수나 관계의 빈도를 명시합니다.

• 1: 정확히 1명 참여
• 0..1: 참여하지 않거나 최대 1명 참여 (선택적)
• * (또는 0..*): 인원 제한 없이 다수 참여 가능
• 1..*: 최소 1명 이상 필수 참여
• n..m: 최소 n명에서 최대 m명까지 참여 가능

---

5. 작성 시 주의사항 (Tips)

1. 적절한 입도(Granularity) 유지: '아이디 입력' 같이 너무 세세한 단위보다는, 사용자에게 의미 있는 '로그인' 단위로 묶어서 표현하세요.
2. 순서도(Flowchart)와 혼동 주의: 유즈케이스 다이어그램은 기능의 '목록'이지 '절차'가 아닙니다. 흐름이 중요하다면 활동 다이어그램(Activity Diagram)을 활용하세요.
3. 액터의 위치 엄수: 액터는 외부 요인이므로 반드시 시스템 경계(사각형) 밖에 위치해야 합니다.
4. 다중성 표기는 필요한 경우에만: 특별한 비즈니스 제약이 없다면 생략하는 것이 관례이며 다이어그램이 훨씬 깔끔해집니다.
5. 화살표 방향 확인: Include는 원본에서 하위 기능으로, Extend는 확장 기능에서 원본 기능 방향으로 향합니다. 방향에 따라 의미가 완전히 달라지니 주의하세요.
6. 이해관계자와의 소통 도구: 엄격한 UML 규칙 준수도 좋지만, 누구나 시스템 기능을 한눈에 이해할 수 있도록 명료하게 그리는 것이 가장 본질적인 목적입니다.