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.