RISE maintains the consistency of your model at all times. This includes not only relations between models elements but names of model elements as well. The purpose is to avoid the otherwise considerable work-effort needed to assure consistent naming throughout the life-cycle of the model. This naming and renaming behaviour corresponds to what other development environments, such as Visual Studio,  refer to as "refactoring". In RISE, however, name consistency is a matter of course and fully automated according to:

Of course, you may override automatically assigned names. If you manually rename an object that automatically received its name RISE will cease to cascade name changes to this object. Suppose, for instance, that you have implemented an interface for an entity named Document. This interface would contain a set of automatically created methods; NewDocument, GetDocument etc. If you rename the entity to File instead, this change cascades and the methods will be renamed to NewFile, GetFile etc. However, if you've manually changed a method name, e.g. GetDocument has been renamed to GetDocumentIfLarge, the name change will not cascade and this method will keep its name.

 

RISE provides a function called "Refactor model". This function is available in the File menu in the RISE Editor. The refactor function will generate a new model containing the shortest path - smallest number of operations - needed to create the same final result as the current model.

A RISE model consists of all changes made to the model during its entire life-cycle. In the early stages of a model you are likely to make a large number of changes. This means that the model might contain objects (entities, relations, attributes etc.) that have later proven obsolete and been deleted. Although these objects are not displayed in the project tree or drawings in the RISE Editor they are, however, still part of the life-cycle of your model. Also, when defining your entities, you'll gradually add attributes and modify their properties. This means the life-cycle of a single entity, or even a single attribute, might be considerable. Refactoring reduces every existing entity to a single operation, thus, significantly promoting the readability of your database scripts.

You should consider refactoring your model at suitable development checkpoints. In particular, it's a good idea to refactor prior to the first deployment (code generation) of your model. This will keep generated database scripts (DDL) reasonably sized and easy to read. It also prevents distributing, and making permanent, your initial design mistakes. 

 

 Don't refactor a model that should remain compatible with systems (databases) in use! A refactored model is a new model and it's incompatible with existing deployments.