기본적으로 사용자가 작성하는 모든 패키지는 단위(파일 시스템의 개별 파일)입니다. 또한 컴포넌트 및 다이어그램도 단위입니다. 기본적으로 그 외의 모든 요소는 단위가 아니므로, 상위 단위의 파일에 저장됩니다. 따라서 모델은 프로젝트 파일(*.rpy), 패키지 파일(*.sbs), 컴포넌트 파일(*.cmp) 및 다양한 다이어그램 파일로 구성됩니다.
그러나 단위별로 또는 단위 작성을 위한 새 정책을 설정하여 프로젝트의 구성 및 요구사항에 따라 이러한 기본값을 대체할 수 있습니다. 예를 들어 특정 클래스를 고유 단위로 설정할 수 있습니다. 또는 작성하는 모든 새 클래스가 단위가 되도록 제품을 설정할 수 있습니다.
사용 충돌을 자주 일으키는 두 명의 팀 구성원이 패키지를 유지보수하는 경우, 기본 설정을 대체하고 하나의 클래스 또는 여러 클래스를 개별 파일에 저장해야 합니다. 팀 구성원 A는 클래스 중 하나의 상태 차트에 그려진 패키지 내 특정 요소의 동작을 디자인하고, 팀 구성원 B는 해당 패키지 내의 모든 클래스에 사용될 새 유형군을 정의합니다. 이 경우 상태 차트가 있는 클래스를 별도의 단위로 설정할 수 있습니다.
이는 다이어그램에도 적용됩니다. Rational Rhapsody에서는 다이어그램이 단위로 저장되므로, 다이어그램에 표시되는 실제 모델 요소를 변경하지 않고 변경사항을 다이어그램에 적용할 수 있습니다. 다이어그램의 색상, 요소 레이아웃, 설명 및 기타 그래픽 특성은 포함된 요소의 단위 상태(읽기 전용 또는 읽기/쓰기)에 관계없이 변경할 수 있습니다. 그러나 다이어그램은 대개 속해 있는 패키지의 특정 측면을 반영하는 "보기"일 뿐입니다. 이 경우 이러한 측면을 변경(예: 관계의 다중성 변경 또는 클래스 삭제)하려면 다이어그램을 변경해야 합니다. 반대의 경우도 마찬가지입니다. 제품의 결합적 특성 때문에 다이어그램을 변경할 때 디자인 요소를 체크아웃해야 합니다(예: 관계 추가 및 관계 변경).
파일 수 및 구성 관리 조작 실행 필요성의 측면에서 복잡성을 줄이기 위해 기본 설정을 반대로 대체해야 하는 경우도 있습니다. 예를 들어 한 패키지에 50개의 이벤트를 정의해야 한다고 가정합시다. 이 50개의 이벤트를 의미 있는 이름과 적절한 설명을 포함하는 세 개의 서브패키지로 분할하면 디자인을 쉽게 읽을 수 있습니다. 이러한 세 파일을 생성하지 않고 패키지를 작성하고자 할 수도 있습니다. 이 경우 패키지가 단위로 작성되지 않도록 기본 동작을 대체할 수 있습니다.
단위를 개별적으로 정의하는 것 외에도, 특성을 사용하여 단위 작성을 위한 새 정책을 정의할 수 있습니다. 예를 들어 모든 새 다이어그램이 개별 단위가 되지 않도록 할 수 있습니다. 또는 새 클래스가 모두 단위로 자동 저장되도록 클래스의 기본 정책을 대체할 수 있습니다.