유스 케이스 패키지는 유스 케이스, 액터, 관계, 다이어그램 및 기타 패키지의 집합입니다. 이 패키지는 유스 케이스 모델을 작은 부분으로 나누어 구조화하는 데 사용됩니다.  
기타 관계:  다음 파트 유스 케이스 모델
역할:  요구사항 지정자 
선택 가능성/발생 시기:  <<유스 케이스 패키지>>를 제외시킬 수 있습니다.  
템플리트 및 보고서: 
     
예: 
     
UML 표시:  최상위 레벨 패키지 또는 <<유스 케이스 패키지>>로 정형화된 유스 케이스 모델의 패키지 
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

다음과 같은 사람들이 유스 케이스 패키지를 사용합니다.

  • 시스템 분석가는 유스 케이스 패키지를 사용하여 유스 케이스 모델을 구조화합니다.
  • 다음 버전의 시스템 요구사항을 파악하는 사람은 유스 케이스 패키지를 사용하여 유스 케이스 모델 구조를 이해합니다.
  • 요구사항 지정자는 작업하는 것과 다른 시스템 부분에 대한 참조용으로 유스 케이스 패키지를 사용합니다.
  • 테스터는 테스트 활동을 계획할 때 정보용으로 유스 케이스 패키지를 사용합니다.

등록 정보 페이지 맨 위

등록 정보 이름 

간략한 설명 

UML 표시 

이름  패키지 이름.   모델 요소에서 "Name" 속성 
간략한 설명  패키지의 목적 및 역할에 대한 간략한 설명.   "간단한 텍스트" 유형의 태그 값. 
유스 케이스  패키지에 직접 포함된 유스 케이스.   "소유" 집합을 통해 소유. 
액터  패키지에 직접 포함된 액터.   - " - 
관계  The relationships directly contained in the package.  - " - 
다이어그램  패키지에 직접 포함된 다이어그램.   - " - 
유스 케이스 패키지  패키지에 직접 포함된 패키지.   - " - 

시기 페이지 맨 위

유스 케이스 패키지 파티셔닝은 유스 케이스 모델이 플랫 구조로 유지하기엔 너무 커지면 바로 수행됩니다. 이 시기는 초기 단계 초반, 구현화 또는 형상 단계 후반일 수 있습니다.

책임 페이지 맨 위

요구사항 지정자는 다음 사항을 확인하여 패키지 무결성을 책임집니다.

  • 패키지가 요구사항을 충족하는지.
  • 패키지가 기타 패키지와 되도록 독립적인지.
  • 패키지의 직접적인 컨텐츠(유스 케이스, 액터, 관계, 다이어그램 및 패키지 포함) 존재가 적절하고 일관적인지.

유스 케이스 패키지를 책임지는 요구사항 지정자가 포함된 유스 케이스도 책임지는 것이 좋습니다. 자세한 정보는 가이드라인: 유스 케이스를 참조하십시오.

사용자 정의 페이지 맨 위

+ 별개의 기능 단위가 있는 계층적 모델 구조를 제공합니다. 유스 케이스 모델과 시스템이 상대적으로 큰 경우 플랫 모델 구조(패키지 미포함)보다 이해하기 쉽습니다.

+ 해당 전문 영역에 따라 여러 개발자 간에 작업 및 책임을 분배하는 좋은 기회를 제공합니다. 이것은 특히 대형 시스템을 빌드할 때 중요합니다. 또한 전체 시스템 기능에 대한 정보를 소수만이 보유하기 위해 개발자 간에 기밀성이 요구되는 경우 유스 케이스 패키지는 보안의 기초를 제공합니다.

+ 유스 케이스 패키지는 결합력이 강한 단위이므로 한 패키지를 변경해도 다른 패키지에 영향을 미치지 않습니다.

- 유스 케이스 패키지의 유지보수는 유스 케이스 모델링 팀의 추가 작업을 의미합니다.

- 유스 케이스 패키지의 사용은 개발자가 익혀야 할 또 다른 표기 개념이 있다는 것을 의미합니다.

이 기법을 사용하는 경우 사용할 패키지 레벨 수를 결정해야 합니다. 가장 좋은 방법은 각 유스 케이스 패키지에 대략 3 - 10개의 소단위(유스 케이스, 액터 또는 기타 패키지)를 포함시키는 것입니다. 아래 표는 지정된 수의 유스 케이스 및 액터를 사용해야 하는 패키지 수에 대한 몇 가지 제안사항을 제공합니다. 정확한 가이드라인을 제공하기는 어렵기 때문에 숫자가 중복됩니다.

  • 0-15: 유스 케이스 패키지가 필요하지 않습니다.
  • 10-50: 1 레벨의 유스 케이스 패키지를 사용합니다.
  • > 25: 2 레벨의 유스 케이스 패키지를 사용합니다.


Rational Unified Process   2003.06.15