Refactoring Models

Traditional Modeling

The traditional way of modeling is solely through adding and deleting Fact Expressions. To alter the model this can be a cumbersome approach for it requires the user to understand the many dialogs warning about generalizations, pattern matching, ignoring warnings, and later remove unneeded expressions without breaking the information model as desired.

Validation

The refactoring of fact structures can also be treacherous, for the fact expressions are not validated to start with, these are also refactored. To remember which fact expressions are entered as a whole, or adjusted through refactoring, CaseTalk will mark those affected, and warn users through model well-formedness checking. Every expression affected by it, must be acknowledged to be correct by editing the flagged expressions (optionally fix) and commit by using the ok-buttons.

A warning example:

  All generated expressions require validated semantics.
  * Expression is generated "Graduation Date":"F9"

Refactoring Methods

There are many possible steps to alter an information model, and just as many ways to proceed. The list below shows the available steps, and does not prescribe how to alter your models.

Replace Object Type

Replacing an Object Type by another Object Type with a different name and/or structure can be very helpful in comparison to adding a new fact expression elsewhere. This article walks the reader through the steps involved to replace the identity of a modelled Object Type. Replace Identification

Copy Expressions

Fact Expressions sometimes look very similar to their Object Type Expressions. Whereas Fact Expressions cannot be substituted in other expressions, the only way forward is to enter the same text as an Object Type Expression. Until you realize there's a function to do that for you. Use the context menu on the expression, and select Copy to Object/Fact Type Expression. This easily copies the text from F1 to O1 or the other way around. It is also a quick way to enter a duplicate for further editing to add different phrasings.

 F1: "John marries Mary."
 O1: 'John marries Mary'

Alter role played by

Once classification and qualification is completed, the roles are played by either an Object Type or a Label Type. If the modeler realizes the role should've been played by a different Object/Label Type, traditionally the cla/qua needs to be done from the start. Using the Alter role played by this can be a thing of the past. Select a Role in a diagram, open the context menu and navigate to Repository\Alter Role Played By... CaseTalk will then prompt with a potential list of candidates to by which the role could be played. It enables fact expressions to quickly change from F1 to something like F2.

 F1: "<Person> lives in <city_name>."
 F2: "<Person> lives in <Location>."

Nominalize label type

During the classification/qualification modelers may determine value should be modelled as a Label Type. In a later modeling phase, a realization may come that the previously though Label Type should have been an Object Type, for there's more information attached to it. Using the context menu on a Label Type in the diagram, allows to Nominalize Label Types. E.g. city_name as label type, can quickly be transformed into an Object Type City which in turn is identified by city_name.

 F1: "<Person> lives in <city_name>."
 F2: "<Person> lives in <City>."

Reduce Object Type

This step does exactly the opposite of Nominalize Label Type. For it reduces Object Type such as the City from the previous paragraph, into a city_name as a label type.

Delete Expression

Expressions have a structure with Roles, and can be used in other Expressions through substitutions. Deleting an Expression therefor can have serious side effects. If there's no other expression in the same Object/Fact Type, it'll even delete that as well. So, when deleting an expression, CaseTalk will prompt 'what to delete'.

1. Deletion can happen on the entire Object/Fact Type, also affecting related Types
2. Delete the expression in it's entirety, again affecting the related expressions
3. Or only delete the local expression and not affecting related expressions.

When refactoring is taking place, usually a local delete is chosen.

Edit expression substitution

Object/Fact Type may contain multiple phrasings and Object Type Expressions. These object type expressions are used in related expressions through so-called substitutions. If an expression is generated back, all possible substitutions are considered, used and generated. Sometimes that is undesirable, and choices need to be enforced. Using context menus on expressions, users may edit and set which substitutions are correct, and which ones are not.

By using this feature, nested Object Type Expressions can easily be added and removed, without the need to re-enter the original expressions.

Edit expression

Entering expressions are prone to typing errors, and a quick edit is desirable instead of entering the correct expression as new. Different levels of expressions are presented in the repository panel/window. When using the context menu to edit such an expression, the soft semantics may be updated, but also the ordering of classified Object Fact types may be moved to a different location within the expression using drag and drop.

This allows for quick adjustments in expressions and the order of elements within.

Delete Object/Fact Type

Deleting an Object/Fact Type will most likely lead to a surprising effect, it'll also delete the entire nested structure, meaning all roles within, and Objects and Labels played by those roles. When the need is only to delete the local Type, best is to delete the expressions locally as described earlier. This delete can also be performed from the diagram, which will by default only delete the local Object/Fact Type, and not related Fact Types.

Combine/Split Label Types

Various Label Types are created during the process of Classification and Qualification of Fact Expressions. Later in the modeling process, some Label Types are redundant and need to be combined into one, or split because they're not detailed and specific enough.

Through the Combine/Split wizards the following conversions are made possible:

 Split:   name into: first_name, last_name
 Combine: product_name, first_name, last_name into: name