가이드라인: 유스 케이스 모델
유스 케이스 모델은 시스템 디자인 기능 및 환경에 관한 모델이며 고객과 개발자 간의 계약 역할을 합니다. 이 가이드라인은 유스 케이스 모델을 개발하기 위한 로드맵입니다.
관계
기본 설명

설명

유스 케이스 모델은 시스템 디자인 기능 및 환경에 관한 모델이며 고객과 개발자 간의 계약 역할을 합니다. 유스 케이스는 시스템 개발 기간 내내 통합 스레드 역할을 합니다. 같은 유스 케이스 모델은 요구사항 원칙의 결과이며 분석 및 디자인과 테스트 원칙의 입력으로 사용됩니다.

아래 다이어그램은 재활용품 수집기 시스템에 대한 유스 케이스 모델의 파트를 표시합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

액터와 유스 케이스를 포함한 유스 케이스 모델의 예제를 표시하는 유스 케이스 다이어그램

시스템을 모델링하는 방법은 여러 가지가 있습니다. 각 방법은 각기 다른 목적에 적합합니다. 그러나 유스 케이스 모델의 가장 중요한 목적은 고객이나 사용자에게 시스템의 동작을 알리는 것입니다. 따라서 모델은 이해하기 쉬워야 합니다.

시스템과 상호작용할 수 있는 사용자 및 다른 모든 시스템은 액터입니다. 액터는 시스템 사용자를 나타내므로 시스템의 한계를 정하고 수행하기로 되어 있는 작업을 보다 명확히 나타내는 데 도움을 줍니다. 유스 케이스는 액터의 요구를 기반으로 개발됩니다. 이를 통해 시스템이 사용자가 예상한 대로 동작하도록 합니다.

유스 케이스 모델의 발전 방법

액터와 유스 케이스는 둘 다 고객 및 잠재적 사용자의 요구사항을 필수 정보로 사용하여 찾을 수 있습니다. 발견된 액터와 유스 케이스에 대해서는 간략하게 설명해야 합니다. 유스 케이스를 자세히 설명하기 전에 고객은 유스 케이스 모델을 검토하여 유스 케이스 및 액터가 모두 발견되었는지와 유스 케이스 및 액터가 고객이 필요로 하는 내용을 제공할 수 있는지를 확인해야 합니다.

반복 개발 환경에서, 각 반복에 대해 자세히 설명해야 할 유스 케이스 서브세트를 선택합니다. 타스크: 유스 케이스 우선순위 결정을 참조하십시오.

액터와 유스 케이스가 발견되면 각 유스 케이스의 이벤트 플로우가 자세히 설명됩니다. 이 설명은 시스템이 액터와 상호작용하는 방법과 시스템이 각 개별 경우에서 수행하는 작업을 표시합니다.

마지막으로, 유스 케이스의 설명을 포함하여 완료된 유스 케이스 모델이 검토되고, 개발자와 고객은 해당 모델을 사용하여 시스템이 수행해야 하는 작업에 대해 합의합니다.

기능 분해 방지

유스 케이스 모델이 변질되어 시스템 기능이 분해되는 것은 드문 일이 아닙니다. 이런 일을 막으려면 다음 증상에 대해 감시하십시오.

  • "작은" 유스 케이스(이벤트 플로우의 설명이 하나 또는 몇 개의 문장만으로 이루어짐을 의미함)
  • "많은" 유스 케이스(유스 케이스의 수가 수십이 아니라 수백 개임을 의미함)
  • "이 특정 데이터에 대해 이 조작 수행" 또는 "이 특정 데이터에 대해 이 기능 수행" 등과 같은 구문의 유스 케이스 이름. 예를 들어, "ATM 시스템에 주민 등록 번호 입력"은 ATM 시스템을 사용하여 이 작업만 수행할 사람은 아무도 없으므로 이 시스템의 독립 유스 케이스로 모델링해서는 안됩니다. 유스 케이스는 액터에게 가치를 제공하는 전체 이벤트 플로우입니다.

기능 분해를 막으려면, 유스 케이스 모델이 다음과 같은 질문에 응답하는 데 도움이 되도록 하십시오.

  • 시스템의 컨텍스트는 무엇입니까?
  • 시스템을 빌드한 이유는 무엇입니까?
  • 시스템 사용 시 사용자가 달성하고자 하는 목적은 무엇입니까?
  • 시스템이 사용자에게 주는 가치는 무엇입니까?

비기능적 요구사항

유스 케이스가 시스템에 대한 기능적 요구사항을 캡처하는 매우 좋은 방법임은 확실합니다. 그런데 비기능적 요구사항에 대해서는 어떻습니까? 비기능적 요구사항은 무엇이며 어디서 캡처합니까?

비기능적 요구사항은 흔히 사용성, 신뢰성, 성능 및 대체성 요구사항으로 분류됩니다(또한 개념: 요구사항 참조). 모든 법률 및 규제 요구사항에 대한 준수의 필요성을 지정하는 요구사항입니다. 또한 사용된 운영 체제, 플랫폼 환경, 호환성 문제 또는 적용되는 모든 응용프로그램 표준으로 인한 디자인 제한조건일 수도 있습니다. 일반적으로 둘 이상의 디자인 옵션을 허용하지 않는 요구사항은 모두 디자인 제한조건으로 간주해야 한다고 볼 수 있습니다.

많은 비기능적 요구사항이 개별 유스 케이스에 적용되고 해당 유스 케이스의 특성 범위 내에서 캡처됩니다. 이러한 경우 비기능적 요구사항은 유스 케이스의 이벤트 플로우 범위 내에서 캡처되거나 유스 케이스의 특수 요구사항으로 캡처됩니다(가이드라인: 유스 케이스 참조).

예제:

재활용품 수집기 시스템에서 폐품 반환 유스 케이스 특정의 비기능적 요구사항은 다음과 같습니다.

시스템은 95% 이상의 신뢰도로 폐품을 인식할 수 있어야 합니다.

대개의 경우 비기능적 요구사항은 전체 시스템에 적용됩니다. 해당 요구사항은 보충 스펙에 캡처됩니다(중간 산출물: 보충 스펙 참조).

예제:

재활용품 수집기 시스템에서 전체 시스템에 적용되는 비기능적 요구사항은 다음과 같습니다.

시스템에는 한 번에 한 명의 사용자만 허용됩니다.

내용 대 방법의 딜레마

유스 케이스가 "시작하고 끝나는" 세부사항 레벨을 판별하는 방법을 배우는 것은 가장 어려운 일 중 하나입니다. 기능이 시작되고 유스 케이스가 시작되는 지점은 어디이며, 유스 케이스가 끝나고 디자인이 시작되는 지점은 어디입니까? 대개의 경우 유스 케이스 또는 소프트웨어 요구사항은 시스템이 수행하는 "내용"은 제시하지만 시스템이 해당 작업을 수행하는 "방법"은 제시하지 않습니다. 다음 그래프를 검토하십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

한 사람의 목적지가 다른 사람의 시작점이 될 수 있습니다.

각자 처한 환경에 따라 다른 컨텍스트를 사용하여 "목적"과 "방법"의 대상을 결정합니다. 특정 세부사항을 유스 케이스 모델에서 제외할지 여부를 판별할 때 이를 고려해야 합니다.

구체적 유스 케이스와 추상 유스 케이스 사이에는 차이가 있습니다. 구체적 유스 케이스는 액터에 의해 시작되며 전체 이벤트 플로우를 구성합니다. "전체"라는 용어는 유스 케이스의 인스턴스가 액터에 의해 호출된 전체 오퍼레이션을 수행함을 의미합니다.

추상 유스 케이스는 그 자체로 인스턴스화되지 않습니다. 추상 유스 케이스는 다른 유스 케이스에 포함되어 있거나(가이드라인: 포함 관계 참조) 다른 유스 케이스로 확장하거나(가이드라인: 확장 관계 참조) 다른 유스 케이스를 일반화합니다(가이드라인: 유스 케이스 일반화 참조). 구체적 유스 케이스가 인스턴스화되면 해당 유스 케이스의 인스턴스가 작성됩니다. 또한 이 인스턴스는 연관된 추상 유스 케이스에 의해 지정된 동작을 나타냅니다. 따라서, 추상 유스 케이스에서는 독립 인스턴스가 작성되지 않습니다.

액터가 시스템에서 "보고" 인스턴스화할 대상은 구체적 유스 케이스이므로 이 둘을 구별해야 합니다.

추상 유스 케이스는 기울임체로 이름을 작성하여 추상임을 표시합니다.

예제:

함께 표시된 텍스트에서 설명되는 다이어그램

타스크 작성 유스 케이스는 주문 등록 유스 케이스에 포함되어 있습니다. 타스크 작성은 추상 유스 케이스입니다.

창고 관리 시스템에서 타스크 작성 추상 유스 케이스는 주문 등록 유스 케이스에 포함되어 있습니다. 주문 등록이 시작되면 주문 등록의 인스턴스는 주문 등록 이벤트 플로우 수행은 별도로 하고 포함된 타스크 작성 유스 케이스에 설명된 이벤트 플로우를 수행하도록 작성됩니다. 타스크 작성은 단독으로 수행되지 않고 항상 주문 등록의 파트나 포함되어 있는 다른 유스 케이스의 파트로 수행됩니다. 따라서 타스크 작성은 추상 유스 케이스입니다.

유스 케이스 모델 구조화

유스 케이스 모델을 구조화하는 주된 이유는 세 가지가 있습니다.

  • 유스 케이스를 보다 더 이해하기 쉽게 하기 위함
  • 많은 유스 케이스 안에 설명된 공통 동작을 파티션하기 위함
  • 유스 케이스 모델 유지보수를 보다 용이하게 하기 위함

그러나 구조화는 수행할 첫 번째 작업이 아닙니다. 해당 동작에 대해 좀 더 많이 알게 되기 전에는 유스 케이스의 간략한 설명을 두 문장이 넘게 구조화해도 무의미합니다. 동작에 대한 정확하고 충분한 이해를 바탕으로 결정하려면 적어도 유스 케이스의 이벤트 플로우에 대해 단계별 아웃라인이 설정되어 있어야 합니다.

유스 케이스를 구조화하기 위한 세 가지 유형의 관계가 있습니다. 이 관계를 사용하여 다른 유스 케이스에 재사용할 수 있거나 유스 케이스의 특수사항 또는 선택사항에 해당하는 유스 케이스의 일부를 분리합니다. 수정을 나타내는 유스 케이스를 일컬어 추가 유스 케이스라고 합니다. 수정되는 유스 케이스는 기본 유스 케이스라고 합니다.

  • 유스 케이스가 결과를 얻는 데 사용된 방법이 아니라 해당 결과에만 의존하는 기능을 나타내는 기본 유스 케이스의 파트가 있는 경우, 해당 파트를 추가 유스 케이스로 분리할 수 있습니다. 추가는 포함 관계를 사용하여 기본 유스 케이스에 명시적으로 삽입됩니다. 또한 가이드라인: 포함 관계를 참조하십시오.
  • 선택적이거나 유스 케이스의 기본 목적을 이해하는 데 필요하지 않은 기본 유스 케이스의 파트가 있는 경우, 기본 유스 케이스의 구조를 단순화하기 위해 해당 파트를 추가 유스 케이스로 분리할 수 있습니다. 추가는 확장 관계를 사용하여 기본 유스 케이스에 내재적으로 삽입됩니다. 또한 가이드라인: 확장 관계를 참조하십시오.
  • 동작 및 구조의 공통성이 있고 목적의 유사성이 있는 유스 케이스가 있는 경우, 해당 공통 파트는 추가 유스 케이스(하위)에 의해 상속되는 기본 유스 케이스(상위)로 분리될 수 있습니다. 하위 유스 케이스는 상위 유스 케이스에서 상속하는 구조에 새 동작을 삽입하고 기존 동작을 수정할 수 있습니다. 또한 중간 산출물 가이드라인: 유스 케이스 일반화를 참조하십시오.

액터 일반화를 사용하여 액터 각각의 전문화 방식을 표시할 수 있습니다. 또한 가이드라인: 액터-일반화를 참조하십시오.

예제:

주문 관리 시스템에 대한 유스 케이스 모델의 파트를 검토하십시오.

일반 고객과 인터넷 고객은 각각의 특성이 약간 다르므로 서로 구분하면 도움이 됩니다. 그러나 인터넷 고객은 고객의 특성을 모두 나타내므로 인터넷 고객은 액터 일반화에 따라 표시된 고객의 전문화라고 할 수 있습니다.

이 다이어그램의 구체적 유스 케이스는 고객 액터에 의해 시작된 전화 주문 및 인터넷 고객에 의해 시작된 인터넷 주문입니다. 이 유스 케이스는 둘 다 보다 더 일반적인 주문 제출 유스 케이스의 변형으로, 이 예제에서는 추상입니다. 카탈로그 요청 유스 케이스는 기본적인 주문 제출 목적의 파트에 해당하지 않는 선택적 동작 세그먼트를 나타냅니다. 이 유스 케이스는 주문 제출 유스 케이스를 단순화하기 위해 추상 유스 케이스로 분리되었습니다. 고객 데이터 제공 유스 케이스는 해당 결과만이 주문 제출 유스 케이스에 영향을 주는 독립 기능이므로 분리된 동작의 세그먼트를 나타냅니다. 고객 데이터 제공 유스 케이스도 또한 다른 유스 케이스에 재사용될 수 있습니다. 카탈로그 요청 및 고객 데이터 제공은 둘 다 이 예제에서 추상입니다.

함께 표시된 텍스트에서 설명되는 다이어그램

이 유스 케이스 다이어그램은 주문 관리 시스템에 대한 유스 케이스 모델의 파트를 보여줍니다.

다음 표는 각기 다른 세 개의 유스 케이스 관계를 자세히 비교하여 보여줍니다.

질문 확장 포함 일반화
관계의 방향은 무엇입니까? 추가 유스 케이스는 기본 유스 케이스를 참조합니다. 기본 유스 케이스는 추가 유스 케이스를 참조합니다. 추가 유스 케이스(하위)는 기본 유스 케이스(상위)를 참조합니다.
관계는 다중성을 갖고 있습니까? 예, 추가 측면에 대해서 그렇습니다. 아니오. 두 번 이상 같은 동작 세그먼트를 포함해야 하는 경우 해당 세그먼트를 기본 유스 케이스에 지정해야 합니다. 아니오
관계는 조건을 갖고 있습니까? 아니오. 포함 관련 조건을 표시해야 하는 경우, 기본 유스 케이스에 명시적으로 표명해야 합니다. 아니오
추가 유스 케이스가 추상입니까? 대개는 그렇지만 반드시 그렇다고는 할 수 없습니다. 대개는 그렇지 않고 그럴 수도 있습니다.
기본 유스 케이스는 추가에 의해 수정됩니까? 확장은 기본 유스 케이스의 동작을 내재적으로 수정합니다. 포함은 기본 유스 케이스의 영향을 명시적으로 수정합니다. 기본 유스 케이스(상위)가 인스턴스화되면, 하위에 의해 영향받지 않습니다. 추가의 효과를 얻으려면 추가 유스 케이스(하위)를 인스턴스화해야 합니다.
기본 유스 케이스는 완전하고 의미가 있어야 합니까? 추가사항 외에도 그렇습니다. 추상인 경우에는 그렇지 않습니다.
기본 유스 케이스는 완전하고 의미가 있어야 합니까? 아니오 아니오 기본 유스 케이스(상위)와 마찬가지로 그렇습니다.
추가 유스 케이스는 기본 유스 케이스의 속성에 액세스할 수 있습니까? 아니오. 포함이 캡슐화되어 있으면, 단지 그 자체만 "봅니다". 예. 정상 상속 메커니즘에 의해 할 수 있습니다.
기본 유스 케이스는 추가 유스 케이스의 속성을 액세스할 수 있습니까? 아니오. 기본 유스 케이스는 추가가 없어도 적절히 형성되어 있어야 합니다. 아니오. 기본 유스 케이스는 추가의 영향에 대해서만 알고 있습니다. 추가는 캡슐화됩니다. 아니오. 기본 유스 케이스(상위)는 추가(하위)가 없어도 이런 의미에사 적절히 형성되어야 합니다.

이해를 돕기 위한 유스 케이스 모델 조직의 또 다른 측면은 유스 케이스를 패키지로 그룹화하는 것입니다. "리프"가 액터나 유스 케이스인 유스 케이스 패키지의 계층 구조로 유스 케이스 모델을 조직할 수 있습니다. 또한 가이드라인: 유스 케이스 패키지를 참조하십시오.

함께 표시된 텍스트에서 설명되는 다이어그램

이 그래프는 유스 케이스 모델 계층 구조를 표시합니다. 화살표는 가능한 소유권을 표시합니다.

유스 케이스는 항상 액터에 관련됩니까?

각 유스 케이스의 실행은 하나 이상의 액터와의 커뮤니케이션을 포함합니다. 유스 케이스 인스턴스는 항상 액터가 시스템에 어떤 작업 수행을 요청함으로써 시작됩니다. 이는 모든 유스 케이스가 액터와 커뮤니케이션 연관 관계가 있음을 의미합니다. 이 규칙의 이유는 시스템에서 사용자가 필요로 하는 기능성만 제공하고 그 외에는 제공하지 않도록 강제하는 것입니다. 아무도 요청하지 않은 유스 케이스를 가지고 있으면 유스 케이스 모델 또는 요구사항에 무언가 문제가 있음을 나타내는 것입니다.

그러나 이 규칙에는 몇 가지 예외가 있습니다.

  • 유스 케이스가 추상(개별로 인스턴스화할 수 없음)인 경우, 해당 동작은 어떤 액터와의 상호작용도 포함할 수 없습니다. 이런 경우, 해당 추상 유스 케이스에서 액터로의 어떠한 커뮤니케이션 연관 관계도 없습니다.
  • 상위 유스 케이스가 모든 액터 커뮤니케이션을 설명하는 경우, 일반화 관계의 하위 유스 케이스는 연관된 액터를 가질 필요가 없습니다.
  • 포함 유스 케이스가 모든 액터 커뮤니케이션을 설명하는 경우 포함 관계의 기본 유스 케이스는 연관된 액터를 가질 필요가 없습니다.
  • 유스 케이스는 스케줄(예: 주 1회 또는 일 1회)에 따라 인스턴스화할 수 있으며, 이 경우 시스템 클럭이 개시자가 됩니다. 시스템 클럭은 시스템 내부에 있으며, 유스 케이스는 액터에 의해 시작되지 않고 내부 시스템 이벤트에 의해 시작됩니다. 유스 케이스에서 발생하는 다른 액터 상호작용이 없는 경우, 액터에 대해 어떠한 연관도 없습니다. 그러나 명확히 하기 위해 유스 케이스 다이어그램에서 가공의 액터 "시간"을 사용하여 유스 케이스의 시작 방법을 표시할 수 있습니다.

조사 설명

유스 케이스 모델의 조사 설명은 다음과 같습니다.

  • 시스템의 기본 유스 케이스(시스템이 빌드된 이유)는 어느 것인지를 설명합니다.
  • 시스템에 대한 중요한 기술적 사실을 요약합니다.
  • 시스템 한계 즉, 시스템에서 수행해서는 안 되는 작업을 지시합니다.
  • 시스템 환경을 요약합니다(예: 대상 플랫폼 및 기존 소프트웨어).
  • 일반적으로 시스템에서 유스 케이스가 수행되는 모든 시퀀스를 설명합니다.
  • 유스 케이스 모델에 의해 처리되지 않는 기능성을 지정합니다.

예제:

다음은 재활용품 수집기의 유스 케이스 모델에 대한 샘플 조사 설명입니다.

이 모델은 세 개의 액터와 세 개의 유스 케이스를 포함합니다. 기본 유스 케이스는 항목 재활용으로, 재활용품 수집기의 기본 목적을 나타냅니다.

지원 유스 케이스는 다음과 같습니다.

  • 매일 보고서 인쇄. 운영자가 많은 항목이 재활용된 방식에 대한 보고서를 받도록 허용합니다.

  • 폐품 관리. 폐품 유형에 대한 반환 값을 변경하거나 새 폐품 유형을 추가하도록 허용합니다.