You can develop a model in a single file and then divide the model into multiple files. Each new file is a model partition.
You should only partition a model after its abstraction level stabilizes. When the abstraction level of a model is stable, the partitioning is less likely to change.
Early versions of a model often depict the top-level subsystems of a system. You should not separate the model until you define top-level subsystems that are likely to survive future iterations. When the top-level subsystems are mature and stable, you can separate them to enable parallel development and to improve the speed with which the model opens. When the contents of an individual subsystem stabilizes, you can then divide the subsystem.
You should try to minimize the dependencies between models to reduce the likelihood that a change in one model affects another.
If you allow dependencies between models, widespread conflicts can occur in a merge. These conflicts are usually out-of-context merges, which can be more challenging to resolve. A partitioned model can be more difficult to merge than a single model. For example, if you merge partitioned models that contain diagrams with references to other models, you cannot fully resolve the references during the merge.
You can reduce the number of required merges by establishing an ownership policy, so that each file has only one owner who can make changes.
To practice model ownership, you should establish the size and scope of each model so that a single person can work on it. When only one person changes a model at one time, no conflicts arise when you deliver the model to a shared work area, which eliminates the need for merges at integration time and speeds the integration process.
To avoid broken references, you should not move model partitions outside your configuration management system.
If you move a model partition outside your configuration management system, you break the references in the model. When you reintegrate the model into the configuration management system, you must resolve all broken references. Depending on the complexity of the model, the types of changes made, and the number of broken references, this task can be an inefficient use of resources.
To avoid data corruption when you work with partitions of a composite model, you should always work in a synchronized workspace that contains all the partitions of the composite, with each partition at the same revision level.
Example
The following example shows what can happen if you work with partitions of a composite model in an unsynchronized workspace.
If User B selects the existing version in the workspace (model X, version 20), he might have to repeat the operation that prompted the checkout.
However, if User B selects the newer model version (model X, version 21), all the changes that User A made to the model are lost when User B saves the model.
Related tasks
Organizing models for team development
Partitioning models