제품은 계층 구조 저장소라는 패러다임을 지원합니다. 이 기능을 사용할 경우, 모델을 저장하면 Rational Rhapsody에서 UML 패키지를 해당 범위에 포함된 디자인 요소가 있는 디렉토리에 맵핑합니다. 계층 구조를 사용할 필요가 없습니다. 이 도구는 기본적으로 일반 구조를 사용합니다. 패키지의 일부 또는 전체를 계층 구조로 이동할 수 있습니다.
프로젝트 재구성은 한 번에 수행하거나 점차적으로 몇 개의 패키지를 한 번에 자체 패키지로 이동하는 방식으로 수행하여, 특정 모델 영역의 복잡성을 줄일 수 있습니다.
저장소 구조는 프로젝트 구성에 따라 달라지며, 다른 프로젝트 결정사항과 마찬가지로 장단점이 있습니다.
전체 모델을 하나의 파일에 저장할 경우 충돌을 방지할 수는 있지만 실제적으로 병렬 개발이 불가능합니다. 그러나 모든 디자인 요소 및 다이어그램을 단위로 만드는 것은 지나친 조치일 수 있으며, 태스크 수행을 위해 체크아웃해야 하는 파일이 많아질 수 있습니다.
마찬가지로, Rational Rhapsody 프로젝트 저장소를 구조화할 때 저장소를 한 끝단(단일 디렉토리에 수백 개의 파일이 있음)에서 다른 끝단(각 단일 파일을 포함하는 수백 개의 디렉토리가 있음)으로 이동하는 것은 계층 구조 저장소 기능을 효율적으로 사용하는 것이 아닙니다.
예를 들어 패키지 파일(*.sbs)이 120개, 다른 유형의 단위 파일이 80개인 총 200개의 단위를 포함하는 프로젝트 A와 20개가 패키지인 총 200개의 단위를 포함하는 프로젝트 B가 있다고 간주합시다.
프로젝트 A를 순수한 트리 구조(모든 UML 패키지가 파일 시스템의 디렉토리에 맵핑됨)로 이동하면 각 디렉토리에 평균 1.66개의 파일이 있습니다. 즉, 어떤 디렉토리에는 파일이 한 개만 포함되어 있고, 다른 디렉토리에는 두 개의 파일이 포함되어 있을 수 있습니다. 이러한 구조는 장점은 거의 없고 프로젝트 크기가 커질 수 있습니다.
그렇지 않고 프로젝트 B를 순수한 트리 구조로 이동할 경우 디렉토리에 상호 관련된 기능의 파일이 평균 10개 포함되어 있습니다. 이는 적절한 숫자입니다. 이 방법을 사용하면 일반 저장소에서 발생하는 여러 가지 문제가 해결되며, 새 디렉토리의 관점에서 더 적은 수의 파일이 추가됩니다.
프로젝트를 계층 구조로 저장할지 여부를 결정할 때 이러한 요인을 고려하십시오. 전체 프로젝트가 같은 구조일 필요가 없습니다. 일부 패키지는 계층 구조에 저장될 수 있고, 다른 패키지는 상위 폴더의 일반 구조에 남아 있을 수 있습니다.