Scenarios (CM tool integration)
Three scenarios are described for using a CM tool with Modeler:
1. Using your CM tool to back up Models.
2. Using your CM tool to store Models with multi-user access of Packages in Modeler.
3. Using your CM tool to store Models with single user access of Packages in Modeler.
Using your CM tool to back up Models
When you use a CM tool to back up Models, the definitive Model resides in a Modeler database. The CM tool is used only to store and version 'snap shots' of a Model and its Packages.
In this scenario, a Model is managed within the Modeler environment in the normal way. The Model is permanently checked out from the CM tool. When a back up is required, a check in operation (keeping files checked out) is performed.
You may want to integrate Modeler with your CM tool in this way during the initial analysis phase of a project, when users are collaborating, the design is fluid and change control through the CM tool is not critical.
Using your CM tool to store Models with multi-user access of Packages in Modeler
Use this set up when you want only one team of users to change a Package at any given time. In this scenario, a team of users can change a checked out Package, through the multi-user support of Modeler. As in the previous scenario, the CM tool allows a user to check out a CM tool Package to a Modeler Model. The Modeler access permissions ensure that only team members can change the Checked out Package in Modeler.
If a team wants to change a CM tool Model, they check out the Packages they want to change to a Modeler database, make the required changes using Modeler, and then check in the Packages they changed to the CM tool Model.
Using the CM tool and Modeler in this way has to be carefully managed, because from the CM tool's perspective, a Package is checked out to a user, and from the Modeler perspective, a Package is checked out to a Model. Both tools provide separate access control mechanisms.
You may want to integrate Modeler with your CM tool in this way during the detailed design phase of a project, when multi-user access to the model in Modeler is desirable and change control through the CM tool is important.
* 
You cannot use your CM tool to check out multiple versions of a Package or Model file for parallel development, because package and Model files cannot be merged.
When making changes, you should check out the required Packages as a set, make the required changes, and then check in those Packages as a set. Working with sets of Packages keeps the CM tool package files in a complete and consistent state.
Using your CM tool to store Models with single user access of Packages in Modeler
Use this set up when you want only one user to change a Package at any given time. The CM tool allows a user to check out a CM tool Package to a Modeler Model. The Modeler access permissions ensure that only the user that checked out the Package can change the Package in the Modeler environment.
When you store your Model in the CM tool, the definitive Model resides in the CM tool. If a user wants to change a CM tool Model, they check out the Packages they want to change to a local Modeler database (to which only they have access), make the required changes using Modeler, and then check in the changed Packages to the CM tool Model. Through the access control of the CM tool and Modeler, you ensure that only one user changes a Package at any given time.
It is important to remember that there may be working copies of the CM tool Model in many Modeler databases, but the definitive Model is stored in the CM tool.
You may want to integrate Modeler with your CM tool in this way during the release and maintenance phases of a project, when users need to generate code from stable models that cannot be changed by other users, or when change control through the CM tool needs to be enforced on an individual basis.
* 
You cannot use your CM tool to check out multiple versions of a Package or Model file for parallel development, because package and Model files cannot be merged.
When making changes, you should check out the required Packages as a set, make the required changes, and then check in those Packages as a set. Working with sets of Packages keeps the CM tool package files in a complete and consistent state.
Was this helpful?