Considerations for dividing a project into units

By default, every package you create is a unit (a separate file on your file system). In addition, components and diagrams are units. By default, all other design elements are not units and are stored in the file of the parent unit. Therefore, a model consists of the project file (*.rpyx, .rpy before version 8.3), package files (*.sbsx, .sbs before version 8.3), component files (*.cmpx, .cmp before version 8.3), and various diagram files.

However, you can override these defaults according to the organization and requirements for a project, either on a unit‑by‑unit basis or by establishing new policies for creating units. For example, you can choose to make a particular class its own unit. Alternatively, you can set up the product so every new class you create is a unit.

Sometimes it makes sense to override the default settings and store a class or several classes in a separate file, such as when a package is maintained by two team members, who often have usage conflicts. While team member A is designing the behavior of a certain element in the package as drawn in a statechart of one of the classes, team member B defines a new family of types to be used by all the classes in that package. In this case, you might want to make the class with the statechart a separate unit.

This applies to diagrams as well. Rhapsody stores diagrams as units, enabling you to apply changes to the diagram without changing the actual model elements that show in it. The colors, element layout, comments, and other graphic characteristics of the diagrams can be changed regardless of the unit status (read‑only or read/write) of the elements it contains. However, the diagram is often just a "view" that reflects certain aspects of the package to which it belongs. In this case, changing these aspects (for instance, changing the multiplicity of a relation, or deleting a class) requires a change in the diagram, and vice versa. Because of the associative nature of the product, some changes in the diagram require the design elements to be checked out (for example, adding relations and changing relations).

Sometimes it makes sense to override the default settings in the opposite direction, to reduce the complexity, both in the number of files and in the need to execute configuration management operations. For example, suppose you need to define 50 events in a package. To keep the design readable, you split these 50 events into three subpackages with meaningful names and appropriate descriptions. You might want to create the packages without ending up with three new files. In this case, you can override the default behavior to prevent the creation of packages as units.

In addition to defining units individually, you can use properties to define new policies for creating units. For example, you can prevent all new diagrams from becoming separate units. Or, you can override the default policy for classes so all new classes are automatically stored as units.