유스 케이스는 요구사항을 수집하는 데 중요한 요소이자 요구사항 및 분석 모델을 구성하기 위한 핵심 요소입니다. 예를 들어 관련 요구사항과 유스 케이스에 대해 작업할 경우, 일반적으로 하나 이상의 유스 케이스와 액터에 액세스해야 합니다. 유스 케이스에 대해 자세히 설명하는 경우, 단일 유스 케이스와 상세 보기(시나리오 세트), 활동 다이어그램 또는 상태 차트 중 하나(또는 일부 기타 정규 스펙 언어)에서 작업해야 합니다. 협업을 고려할 경우, 단일 유스 케이스와 관련된 클래스 세트를 작성하고 해당 유스 케이스에 바인드되는 시나리오를 세분화해야 합니다. 패키지는 유스 케이스를 일관된 세트(예: 일반화, «includes» 또는 «Extends» 관계 또는 공통 액터 세트와의 연관을 통해 관련된 요소)로 구분할 수 있습니다. 이 경우 패키지에는 유스 케이스 및 해당 액터, 활동 다이어그램, 상태 차트, 시퀀스 다이어그램이 포함될 수 있습니다.
프레임워크 기반 모델 구성은 유스 케이스 기반 접근 방법의 몇 가지 제한사항을 해결해 줍니다. 이 구성은 여전히 소형 시스템을 대상으로 하지만 공유 요소와 공통 요소에 대한 프레임워크 패키지가 추가됩니다. 프레임워크 패키지에는 사용점(대상 애플리케이션 환경에 서비스를 제공하는 데 사용될 클래스) 및 확장점(유스 케이스 패키지에 있는 클래스에 따라 서브클래스로 그룹화된 클래스)에 대한 서브패키지가 있습니다. 제대로 작동하는 또 다른 프레임워크 영역 구성 방법도 있습니다. 예를 들어 프레임워크는 대개 일관된 패턴 세트로 구성되는데, 이러한 패턴을 통해 프레임워크를 서브패키지로 구성할 수 있습니다. 이 구성은 공통 프레임워크 내에서 소형 애플리케이션을 구성할 때 적합하지만, 유스 케이스 접근 방법과 같은 방식으로 재사용이 제한될 수 있습니다.
또 다른 접근 방식은 아키텍처를 논리적 측면(유형, 클래스 및 기타 디자인 타임 모델 요소 구성)과 실제 측면(인스턴스, 오브젝트, 서브시스템 및 기타 런타임 요소 구성)으로 구분하는 것입니다. 논리적 아키텍처는 대개 도메인으로 구성되고, 실제 아키텍처는 컴포넌트 또는 서브시스템을 순환합니다. 모델을 이 방식으로 구조화할 경우 도메인, 서브시스템 또는 컴포넌트가 단일 작업자 또는 팀에 지정될 CI가 됩니다. 대형 요소일 경우 도메인 내의 하위 주제, 서브컴포넌트 또는 다른 기준(예: 팀 조직)에 따라 서브패키지로 세분화할 수 있습니다.
클래스를 기준으로 모델을 구분할 수도 있습니다. ROPES에 정의된 도메인은 디바이스 I/O, 사용자 인터페이스 또는 알람 관리 등의 공통 어휘를 사용하는 주제 영역입니다. 각 도메인은 여러 개의 클래스를 포함하고, 시스템 레벨 유스 케이스 협업은 여러 도메인의 클래스를 포함합니다. 대부분의 도메인에는 하위 레벨 디바이스 드라이버, 항공 항법 또는 통신 프로토콜 등과 같은 다소 특수화된 전문 지식이 필요합니다. 이러한 요소는 단일 작업자 또는 팀에서 개발하고 조작하기 때문에 워크플로우 및 논리적 관점에서는 그룹화하는 것이 좋습니다. 대부분의 프로젝트에서는 클래스를 도메인별로 그룹화하고 도메인을 CI로 설정하는 것이 좋습니다.
경우에 따라 직관적으로 모델을 컴포넌트별로 구성할 수 있습니다. IBM® Rational® Rhapsody®의 UML 컴포넌트는 실행 파일, 라이브러리 및 기타 실제 2진 결과물을 정의하는 데 사용되는 기본 구성 요소입니다. 이러한 각 컴포넌트는 모델 요소에서 생성된 코드로부터 컴파일됩니다. 컴포넌트를 구성하는 모델 요소를 컴포넌트 범위라고 합니다. 특정 컴포넌트에 맵핑된 모든 모델 요소를 포함하는 최상위 레벨 패키지를 사용하면 단순하고 사용이 간편한 구조가 만들어집니다. 이 접근 방법은 여러 컴포넌트에 있는 동일한 디자인 요소의 재사용이 제한됩니다. 그러나 컴포넌트 레벨 재사용이 가능하므로 효율적입니다. 즉, 재사용될 디자인 레벨 요소를 라이브러리에 지정한 다음 이 라이브러리를 여러 컴포넌트에 사용합니다.
단순한 솔루션은 팀 구성원별로 한 개의 패키지를 지정하는 것입니다. 즉, Sam이 작업하는 모든 사항은 SamPackage에 있고, Julie가 작업하는 모든 사항은 JuliePackage에 있습니다. 매우 작은 프로젝트 팀에게는 이 솔루션이 실행 가능한 모델입니다. 그러나 Sam이 무엇을 작업하고 Julie가 무엇을 작업할지가 문제입니다. Sam이 SamPackage의 다른 부분에서 작업 중일 때 Susan이 Sam의 클래스를 조금이라도 업데이트할 경우에도 문제가 발생할 수 있습니다. 또한 이 구성을 사용할 경우 모델 구조에 팀 조직 종속 항목이 추가되므로, 프로젝트 팀을 변경(예: 다른 태스크에 팀 구성원 지정)하는 것이 더욱 어려워지며 재사용 가능성도 제한됩니다.