Refactoring Models
The traditional way of modeling is solely through adding and deleting Fact Expressions. To alter the model this can be a cumbersome approach as 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 nominalizing 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'.
- Deletion can happen on the entire Object/Fact Type, also affecting related Types
- Delete the expression in its entirety, again affecting the related expressions
- 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 deletion 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
Create Fact/Object/Label Type
Though the process of entering fact expressions and going through Classification and Qualification will present the Fact Type, and Object/Label Types. An experienced modeler may want to enter a refactoring mode, and circumvent this process at times.
CaseTalk allows modelers to quickly define Label Types by simply creating them. Similarly, Object Types with default Object Type Expression, and a single role can be created. And once Types are entered in the model, they may be referred to by a Fact Type. The creation of Fact Type is done by selecting which other Types play a role in this fact type, and CaseTalk creates the fact type with a dummy expression.
Naturally the expressions and structures created need to be fixed and amended further, but it allows modelers to quickly create a mock-up, and postpone correct detailed modeling down the road. CaseTalk will mark all expressions as incomplete and report them during the model well-formedness checks.
Create subtype
When Object Types are referred to by related Fact Types, and some of these are really expressions involving a subtype of the Object Type, this feature will help you create a subtype and move specified Fact Expressions with it.
Whereas F1 and F2 are modelled with Person in mind, and only later is realized the F2 should be connected to Employee, being a subtype of Person. The feature allows users to select Person and create the subtype Employee and move F2 with it, creating F3.
F1: "<Person> is born on <Day>." F2: "<Person> started working on <Date>." F3: "<Employee> started working on <Date>."
Add role
Generalizations can be a great modeling concept. An Object Type containing many roles to specific instances, while some Fact Types are connected to the generalization.
[Person] O1: '<Customer>' O2: '<Employee>' O3: '<Account>'
Adding a new role with a new variant (such as Account) can be accomplished by selecting the Object Type and add a role. It'll create an Object Type Expression with just this role in its structure.
Generalization can be extended this way very quickly, especially in combination with the substitution editing to have them referred to in related Fact Expressions.
Split Fact Type
Fact types which contain multiple roles of which a certain set should've been an object type, is easily corrected using this function. The following screenshot shows how roles can be selected and split off into a separate object type. This function can be performed on a selection of roles within the fact type. The function also works on a fact type level if there is only a single UC, or a preferred UC. In that case the roles under that UC will then be used to split the fact type.
