Often when working in large teams and on large projects it may be necessary to send some parts of the model to a different team for modeling purposes. One example is to import an analysis model into a design model so that «trace» relationships can be established. Another example is importing the interfaces of a shared component in order to reuse the published classes.

Modeler provides a Component Sharing Wizard to support the movement of Packages between different models. The Component Sharing Wizard includes functionality for assessing the dependencies between Packages and storing a textual description with the file. An option is also available to difference the model with a Component Sharing Wizard file before import. When exporting Packages to disk, the Component Sharing Wizard zips up the data to a single compressed file, so that it can be emailed easily or checked into a CM project.

When sharing components and Packages that are evolving, it is assumed that the subscribing team requires read access but not write access. UML dependency relationships, such as «trace», can be used to trace a model to items in read-only Packages without having to unprotect them.

From Modeler, right-click a Package and select Tools > Component Wizard > Export To Directory to export set of Packages to a file. The component information is zipped into a compressed format so that can be emailed between sites or checked into a CM tool. To import the file, right-click the Package in which you want the exported Package to reside, and select Tools > Component Wizard > Import From Directory.

Alternatively, from Modeler, right-click a Package and select Tools > Component Wizard > Export To Model to export Packages from a publishing model into a subscribing model. You can use the Import From Model command to import Packages from a publishing model.

This can be used to reuse a Package, share it between two models or allow it to be worked on remotely.

The Component Sharing Wizard reports dependencies to other parts of the model that may also need to be shared.

Version the publishing model and then export the relevant Packages from the protected version using the Component Sharing Wizard.

Interfaces should be put in a shared Package that is updated as a whole. Where possible, separate private Packages from public Packages and only share the public Packages to reduce the coupling between models.

It is not possible for a model to have more than one root model object. This means that the Component Sharing Wizard can only export and import Packages and their contents. If you want to share a whole model inside another model then the publishing model will need to have a single root Package, for example, named after the model. To import an analysis model into a design model, for example, create a single root Package in the analysis model and put all the Packages and items in the model under this root Package. You can then share the root Package and all its children in other models.

Ensure, where possible, that the Packages that need to be shared have a common root Package so that you can move a complete Package hierarchy as one.

Although there may be more than one subscribing model, there should only ever be one publishing model. Packages imported into the subscriber model should always be protected so they are read-only.

If you want to share a whole model using the Component Sharing Wizard then create a single root Package, for example, named after the model, and move everything into it. You can then share the single root Package and all its children.

To make appropriate use of this architecture it is strongly recommended that Full Logging is enabled and the database is backed up regularly. It is also prudent to periodically test the integrity of the backup processes by exercising the restoration capabilities.