Strategy for mapping of Modeler packages to surrogate modules and surrogate objects (Integration for IBM Rational DOORS)
You should decide how to map the Packages in your Modeler model to surrogate modules or surrogate objects in DOORS.
Each Integration for IBM Rational DOORS Mapping has a root item in the Modeler model:
• The root item can be the Model or any Package in that Model.
• You can create many Mappings for a model, but each Package in a model can be involved with only one mapping. This means that if you select the Model as a root item for a Mapping, you cannot not create any other Mappings for that model.
• Make use of Requirements Mappings to synchronize requirements, and Surrogate Mappings to synchronize model elements.
Tell me more...
• When deciding on Packages to use as root items for Mappings, consider the number of child items in each Package (affects the time taken for synchronizations), how often the content of each Package is likely to change (affects how often synchronizations are required), and how linked the content of the each Package relates to the content of other root item Packages.
Each Integration for IBM Rational DOORS Mapping has a root object in a DOORS module:
• The root object can be the surrogate module or any valid object in that module.
• A surrogate module can have many root objects for Mappings. These Mappings can be from a single model or multiple models.
• Each object in a module can be involved with only one Mapping. This means that if you select the surrogate module as a root object for a Mapping, no other Mappings can use that module unless they are sharing the same root item.
• When deciding on objects to use as root objects for Mappings, consider the size of surrogate modules, the number of surrogate modules, and the access permissions required for those surrogate modules.
Synchronizing DOORS requirements to multiple Modeler models
When working with Requirements Mappings, more than one model can be synchronized with the same requirements in a DOORS module. In this scenario, two or more models have Packages that are synchronized with the same root item in a shared DOORS surrogate module.
There is a restriction in that the DOORS requirements and links can be updated from only one of the Modeler models:
• From this model, bi-directional and uni-directional synchronizations can be performed as required, with requirements and their associated items and traceability links being maintained in Modeler or DOORS.
• From the other models, only uni-directional synchronizations from DOORS to Modeler can be performed. If the users of these other models want to maintain the requirements, they must do so through the DOORS environment, not Modeler.
• If DOORS requirements have been synchronized with a Modeler model using Studio version 7.4 or earlier and you now want to synchronize those requirements with multiple Modeler models, after upgrading to Modeler 8.2 you·must synchronize the original Modeler model with the requirements before synchronizing those requirements with any other Modeler models.
This synchronization creates the required ART Model Element Type ID and ART Model Element ID hidden attributes in the DOORS Module.
• When synchronizing DOORS requirements to multiple Modeler models, all but one of the models must use an object synchronization direction of 'DOORS -> Modeler' and a link synchronization direction of 'DOORS -> Modeler'. Failure to do this will result in objects being deleted from DOORS.
• We recommend that you back up your Modeler models and DOORS modules before synchronizing DOORS requirements to multiple models.
Each model should be synchronized regularly to keep all the models in step.
