As your Corticon projects evolve, you might have need to change the name of some entities, attributes, and associations to better describe their meaning.

To avoid time consuming manual work and automate a potentially tedious process, Corticon lets you refactor the name of an entity, attribute, or association so that each change is automatically applied to all instances of the name in all assets in the project.

How does refactoring differ from renaming? When you rename a vocabulary element, only the vocabulary changes while the project assets that use that element are not updated, and will likely become invalid. But when you refactor the name of a vocabulary element, Corticon Studio updates all the Rulesheets, Ruleflows, and Ruletests which use that element, and maintains the validity of your project.

Note: Backup the project's rule assets before refactoring the Vocabulary since refactoring modifies and automatically saves rule assets.

To refactor an entity, attribute, or association name, do the following:

  1. Open the project's Vocabulary.
  2. Click on the name you want to change and highlight it.
  3. Either right-click on the item to choose Refactor in the context menu, or choose the menu action Vocabulary > Refactor.
  4. The Refactor Vocabulary dialog box opens for the selected item:


  5. Type in a preferred name, and then click OK:


The change is applied throughout the project, and then all the changed files in the project are saved.

If Refactor determines the new name you have entered is currently used by another attribute in the entity, or currently used in the parent entity name, the name is disallowed and the OK button is disabled. When this occurs, type a new unused name in the Refactor Vocabulary dialog box and select OK.

Note: CTRL-Z or Undo options are unavailable. To revert a refactored name to the original value, use the Refactor feature again and change the name back.

Important: Allow the process to finish

Refactoring on a large project might take a minute or more. Although an automated process, refactoring is a non-trivial operation that requires parsing all dependent assets to properly perform the changes. The refactoring process first searches the assets and locates where entities, attributes, and associations are used. Then it replaces the old term with a new term at each location.

While processing, Refactor blocks use of the UI to prevent other edits to be performed. This avoids any possibility of the renaming operation undoing simultaneous edits made by users, or encountering other concurrency issues.

Also, any unsaved changes in other open editors are saved by the refactoring process.

Note: Do not cancel the refactoring process once started, to do so could leave the assets in an invalid state as some of the files would be updated but not all of them.

Important: Expressions that cannot be refactored

Within a Rulesheet, there are a small number of expression types that cannot be refactored automatically:

  • When two entities have an attribute with the same name and the expression assigns the value of one attribute to the other. For example: A.name = B.name
  • When entities and attributes share the same name. For example: Name.name
  • When an entity would be refactored to the same name as an existing alias in a Rulesheet. Refactor detects when this can occur, stops the operation, and displays a message recommending a new name be chosen for the entity, or a Rulesheet alias be changed.

If expressions that cannot be refactored are encountered, the Refactor operation still continues to refactor other expressions until the operation is finished. The expressions that could not be refactored are left unchanged and flagged as errors in the Problems view, and an alert is given as shown:



To update those expressions correctly, review the list of errors in the Problems view, and manually edit the Rulesheets accordingly.