Model partitioning

You can develop a model in a single file and then divide the model into multiple files, which are called model partitions. You might consider partitioning a model when the size or packaging structure of the model becomes unmanageable.

You should only partition a model in extreme circumstances, because model partitioning can hinder team collaboration and development if you do not do it properly. Before you consider partitioning a model, you should ensure that you have an effective architecture for your model and that you assign effective ownership of it, so that you can minimize the partitions and reduce non-trivial merges.

Effective model architecture and ownership

An effective model architecture relies heavily on decomposition. The following principles of decomposition are the same ones that drive object-oriented development, component-based design, and service-oriented architectures:

If your decomposed model still contains a high number of dependencies, you have two options:

After you establish an effective architecture, you can assign ownership of architectural components to individuals or small teams. When only one person, or a small team in close proximity, works on a logical package or branch in a model, you minimize non-trivial merges with that model, regardless of whether you store the model in a single modeling file or in multiple modeling files.

You cannot avoid non-trivial merging by partitioning models into multiple modeling files because architectural interdependencies are logical, not physical. If you partition a model into multiple modeling files, the representations of the element interdependencies become cross-file references instead of in-file references.

Merge conflicts that occur because of broken cross-file references are difficult to resolve. Cross-file references represent potential breaking points because you expose files in the host file system. Therefore, if you move, rename, or otherwise modify the files outside of the Eclipse environment, Eclipse cannot track the cross-file references.

When to partition a model

You should consider partitioning a model into multiple files in the following situations:

Some configuration management policies enable parallel development, in which multiple team members work on a model at the same time. During parallel development, uncoordinated changes can impact a file, and the logical model or model subset that the file represents. You must merge any changes before you can save the model file in the configuration management system. A trivial merge occurs when changes do not conflict, so the model merge tool merges the changes automatically. A non-trivial merge occurs when multiple users deliver conflicting changes and a user must determine which changes to accept.

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. You should also identify common components and stabilize them first because changes to common components can create conflicts that affect all other partitions.

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 stabilize, you can then divide the subsystem.

Synchronized workspaces

To avoid data corruption when you work with model partitions, you should always work in a synchronized workspace that contains all the partitions at the same revision level.

Example

The following example shows what can happen if you work with partitions of a model in an unsynchronized workspace.

In a configuration management system, a model has two partitions, model X and model Y. Both models are at version 20. Model X contains one package, called P1. Model Y is empty.

Two users engage in the following workflow:

  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.
  5. When User B tries to save his changes, 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 saves his changes with the newer model version (model X, version 21), he overwrites the changes that User A made.

Related tasks
Organizing models for team development
Partitioning models
Terms of use | Feedback
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.