Repository structure
By default, Rhapsody® stores all the repository files (class files, package files, diagram files, and so on) in a single directory, creating a "flat" list of files that represents a tree‑structured hierarchy of the UML design elements in the product. This storage method works best for smaller, less complex projects.
The product supports a paradigm known as hierarchical repository. With this feature, as you save your model, Rhapsody maps UML packages to directories containing the design elements included in their scope. You are not required to use the hierarchical scheme; by default, the tool uses the flat structure. You have the choice of moving some or all of your packages to a hierarchical structure.
Restructuring the project can be done as a one‑time effort, or by gradually moving several packages at a time to their own directories, reducing complexities in specific areas of the model.
Considerations for the repository structure
The structure of your repository depends on the organization of your project and, like other project decisions, involves trade‑offs.
Keeping an entire model in a single file prevents any conflict but practically disables parallel development. However, making every design element and diagram a unit can be overkill, and leads to many files that you need to check out in order to accomplish a task.
Analogously, when structuring a Rhapsody project repository, keep in mind that moving from one extreme (where you have hundreds of files located in a single directory) to the other extreme (where you have hundreds of directories containing a single file each) is probably not an effective use of the hierarchical repository feature.
For example, consider a project A that contains 200 units, out of
which 120 are package (*.sbs) files and 80 are other types of unit files, and
project B with 200 units, out of which 20 are packages.
If moved to a pure tree structure (where every UML package is mapped to a
directory in the file system), each directory in project A might have (on average)
1.66 files; many directories might contain a single file and many others might have two files. Such
a structure provides little advantage, and might increase the project size.
Alternatively, if you moved project B to a pure tree structure,
an average directory would contain 10 files with interrelated functionality, which is a reasonable
number. This method solves many of the problems faced by flat repositories, while adding fewer files
in terms of new directories.
Consider these factors when you decide whether to store a project in a hierarchical structure. The entire project does not have to have the same structure, some packages can be stored in a hierarchy, whereas others remain in a flat structure in their parent folder.