Fragments in UML models

The elements in the UML model do not need to be in the same file. You can divide a single UML model into fragments, collections of elements that are stored in separate files but are actually part of the main model. The ability to divide a model into fragments is particularly useful in team development environments where several teams work on a shared model.

You can divide a model into fragments by extracting packages, classifiers, and diagrams into physical subunits. Although the fragments are stored in separate files, you can open and edit the model as though it were in a single file. In this case, the complete model, including both the main model and all of the fragments of that model, is referred to as the logical model.

When you open a model that contains fragments, you can see the fragmented elements in the Project Explorer view, but not the contents of the fragments. These closed fragments are indicated by an overlay with a red strike through it:

A model that contains two closed fragments
When you access any of the elements in the fragment, such as by opening the fragmented package manually or by opening a diagram that contains one or more of the elements in the fragment, the fragment is loaded and the overlay on the package changes to indicate the open fragment:
The same model with the two fragments opened and expanded
In this way, fragmenting models allows a team to work on the same model without editing the same file.

The ability to save portions of a model as fragments is helpful for the following reasons:

You can open a fragment by opening or expanding it in the Project Explorer view, accessing the elements in the fragment (such as by opening a diagram that contains one or more of the elements in the fragment), or by right-clicking the model (or any other container of fragments) and then clicking Open All Sub-Fragments.

Best practices for using model fragments

Consider the following best practices if you use model fragments:

  • Structure the model into several small fragments so that fewer merges are required.
  • Fragments should be fairly independent, with minimal cross-fragment references.
  • Store fragments in the same project as the main model, using a well-defined directory structure. If you must move a fragment, use refactoring and ensure that all associated fragments are present so that cross-references are updated.
  • If fragments are in separate projects, use pathmaps to identify their locations.
  • Your workspace should contain all the fragments that belong to the model you are working on, including all referenced fragments.
  • Do not create excessive fragments. Fragments do not help in small models and might even have a negative impact.
  • Carefully manage the fragments; mismanaged fragments can result in corrupt models.

Absorbing model fragments

If a model contains fragments that are no longer required, you can absorb the model elements in a fragment back into the parent model file. When elements are absorbed, the connection between the parent model file and the fragment file are broken, and the fragment file is deleted.

Repairing model fragments

If a model includes fragments that contain broken cross-references, or references to missing fragments, you can repair these problems by using the Model Editor view.


Feedback