At some point, you may want to change the meta model for an item type that currently, directly owns a part type so that, instead, the part type is owned by a container item. In this way, a set of parts can be reused, separately from the item type. Containers are often used, e.g., for requirements since they are typically, extensively reused. there is a refactoring tool that can then be used to update existing data to fit the new model. The refactoring operation will update the structure of all affected data (including Released data), across the entire database according to your refactoring configuration. This article describes how to configure and execute the refactoring.
- Updating the Meta Model to Support the Refactoring
- Configuring the Refactoring
- Executing the Refactoring
- Clean-up of Original Model
- What's Next?
Prerequisites
- Meta Modelling - Important Notes and Recommendations
- Assignment of the SW Architect role in the server
- An installation of the SystemWeaver Architect client (swArchitect)
- Familiar with the item and part types and data that will be changed
Example Data
From
To
Prerequisites
- Familiar with the SystemWeaver meta model building blocks (e.g., Items, Parts and Attributes)
- Assignment of the SW Architect role in the server
- An installation of the SystemWeaver Architect client (swArchitect)
- A test server to test the refactoring prior to rolling out in a production environment
- The meta model supporting the container item already exists
- Sole access to the database during update
Updating the Meta Model to Support the Refactoring
As mentioned in the Prerequisites, the meta model supporting the new container item model must exist prior to executing the refactoring. In the above example, you would to add the following metadata:
- The new container item type, e.g., REC1
- The new part type going from the owner of the new container item to the new container item, e.g., DERC
- The new part type going from the new container item to the item type that is being "contained"/grouped, e.g., IXRQ
Configuring the Refactoring
Once you have the meta model in place, you can stage the refactoring.
- In the swArchitect, navigate to the Refactorings tab and select Insert Item List.
- For Create list of item type, select the item type for the new container item.
- For and add this list with part type, select the new part type connecting the owner of the new container item to the new container item.
- For Then move parts of type, select the part type that will now be owned by the container item.
- For to list item with part type, select the new part type connecting the new container item to the parts.
Executing the Refactoring
When you are ready to perform the refactoring, it is best to have sole access to the database.
Click Execute to start the refactoring. If your configuration matches the meta model, you will receive a Confirm dialog.
If your settings do not match the meta model, you will receive an application error.
Confirm your configuration and click OK. The refactoring will start immediately. You will not receive a message when it is completed. Log in using the swExplorer and confirm the refactoring. You may need to select to view the new part type in the structure tree.
Clean-up of Original Model
If the original model will no longer be used, then consider deprecating the part that allows parts to be owned directly by the item. The other alternative is to leave it as-is and allow for both options:
Updating Configurations
View configurations and report definitions may need to be updated after the refactoring.
What's Next?
If you want the new type to be visible by default in a tree structure, you will need to update the affected structure tree view settings to include the new container.