Model Management

GuardIEn automates many of the checks and tasks that are necessary to successfully manage multiple CA Gen models. It allows the project to define its model architecture using a rules based approach. The migration rules specify the points in the deliverable life-cycle that indicate that a migration is required, the preconditions and post-conditions for the migration and which model or models are to be targeted.

To ensure that the migration is performed from the correct model for each deliverable, GuardIEn allows the nomination of a 'master' model for each deliverable. This indicates the model where changes are to be initially applied, and hence which model to use to update the other development models when a new version is to be migrated. This greatly reduces the risk that the production system is updated from the wrong model, or that the master version of the deliverable is accidentally overwritten by migration from the wrong model.

GuardIEn also performs 'enabling' object checking, automatically adding required objects into the migration. This greatly reduces the number of migration failures since missing enabling objects are the most common reason why a migrate does not succeed

The diagram below illustrates the linking of two status changes in the life-cycle to corresponding migration paths in the model architecture.

Migration Rules

GuardIEn's migration rules provide great flexibility in enabling the product to be able to address most model architectures. The diagram below illustrates some of the typical model architectures that GuardIEn supports. Examples include:

Example Model Architectures

To ensure that the migration is performed from the correct model for each deliverable, GuardIEn allows the nomination of a 'master' model for each deliverable. This indicates which model will be used to apply the changes to, and hence which model to use to update the other development models when a new version is to be migrated. This greatly reduces the risk that the production system is updated from the wrong model, or that the master version of the deliverable is accidentally overwritten by migration from a 'slave' development model.