Model partitioning

You can develop a model in a single file and then divide the model into multiple files. Each new file is a model partition.

Model partitioning can facilitate collaboration and development for teams that design complex systems, by doing the following things:
  • Preventing team members from working on the same portion of a model at the same time, when the team uses a configuration management system
  • Reducing the frequency and complexity of merge sessions between team members
  • Decreasing the amount of time that is required to load models
However, model partitioning can hinder team collaboration and development if it is done improperly. The following sections provide recommendations for proper model partitioning.

Abstraction levels

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.

Dependencies

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.

Ownership policies

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.

Broken references

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.

Synchronized workspaces

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.

In a configuration management system, a composite model is made up of two model partitions, model X and model Y. Both models are at version 20. Model X contains one package, P1. Model Y is empty.
  1. User A checks out the two models, both at version 20.
  2. User A makes several changes to P1, and moves P1 from model X to model Y.
  3. User A checks in model X and model Y. Both files are now at version 21.
  4. User B has model X, version 20, in his workspace and makes a change to P1. The configuration management system prompts User B to either check out the existing version in the workspace (model X, version 20) or the newer version (model X, version 21).

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

Terms of use | Feedback
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.