Model Management

GuardIEn automates many of the checks and tasks that are necessary to successfully manage multiple 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.

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:

• Multiple development models which are merged into a common integration test and production model. GuardIEn allows the definition of a master model for each deliverable so that it is always migrated from the correct model. Any other development models that contain the deliverable are tracked and updated as required.
  
  
• Simultaneous development of more than one system release (parallel development). GuardIEn contains facilities to 'baseline' the objects in each model to facilitate the migration of changed objects from one release to the next whilst not overwriting deliverables that have been changed in the subsequent release.
  
  
• Facilities for maintaining a single view of a system or set of linked systems that are constructed from multiple models. This is a form of model architecture that is often used when adopting component based development approaches.
  
  
• Facilities for the distribution and receipt of common objects across projects.

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.