Modeler:8/RepositoryRules

Model Well-formednes

This window shows the well-formednes rules for the active model. This window shows the basic rules to which your model should comply. It shows both errors and warnings. Errors need to be solved before any model generation can be started. Warnings are optional and are indicators to the modeler where to potentially improve the model.

It is advised to perform these rule checks regularly to keep the model in order.

---

Every fact type must have an intra UC

There must exist at least one Uniqueness Constraint on the roles within the object of fact type. Violations will be marked as an error, unless the model transformation settings are set to assume a wide UC when none is specified. Once this setting is turend on, these rules are considered to be a warning.

The N rule must be valid for every nominalized fact type

All roles within a nominalized fact type must be covered under a single uniqueness constraint. Generalizations are an exception to this rule. As long as all roles inside an Object Type are covered by UC's the model should be correct.

Note: This rule is nuanced newer versions of CaseTalk. It follows the object type expressions instead of the object type as a whole. This allows both regular object types, and generalizations, to be correct as long as each UC matches a corresponding object type expression.

The N-1 rule must be valid for every fact type

Facts are required to have one or more uniqueness constraint over N-1 roles. The uniqueness constraint should cover all roles, or all roles minus one.

Note: Similar to the newer N-Rule, CaseTalk will apply this rule on Fact Type Expressions instead of the Fact Type as a whole. This again allows generalizations which require various verbiage under the same fact type, while guaranteeing a correct model.

The subtype rule must be valid for every subtype

In a fact type that is a subtype, all roles have a single role uniqueness constraint. For nominalized subtypes, all object type expressions concern exactly one role.

The alias of an object/fact type must be unique

Object / fact types names must be unique throughout the model. This list of names includes the alias set at the fact property dialog.

All object type expressions must be used

Object types expressions generally are created during qualification of fact expressions. This rule states that the object type expressions should be verbalized as part of another object types of fact type expression.

Non-lexical object types without totality constraints must have a fact type expression

Object types which have no fact type expression, must be used in another fact type through a totality constraint.

The actual population of every fact type must be verbalizable

Every population tuple must be referenced in a fact type expression.

A strict equality constraint must apply on each subtype tuple

Subtypes must have a corresponding population in regard to their supertype.

Fact types may not contain redundant role combinations

A fact type which contains a combination of roles with the same 'played by' as a in another fact type, may contain redundant information. This could indicate a potential object type to be created.

The population should match the value constraints

The population should obey the value constraints of the corresponding label type.

Facts must have at least one sample population

Facts should have at least one tuple in the example population. This may occur when the population is cleared, or the facts are added to CaseTalk through reverse engineering. For proper verbalization and validation at least a single example population is required for every expression.

Roles must have distinct semantic meanings

Multiple roles within the same fact, which are playing the same object or label type, should have distinct names. You may solve this may adding role fixes, or by inserting additional object types which are named differently for each role.

Note: Newer versions of CaseTalk also consider the result of any rolefix as a regular otft name. Therefor the result of a rolefix must be unique among all OTFT's.

Label types must contain a datatype definition

All label types contain value types. For system generation the datatypes can be derived by CaseTalk, but should really be set by the modeler. All label types which have the 'default' as datatype will show up under this rule.

Fact types may not contain object types

Fact types with a single uniqueness constraint, containing more than 2 roles, and also having 1 role not under this constraint, may contain a structure where the roles under this uc may be split into an object type.

Binary fact types must have grouping preference

Binary fact types, with 2 uniqueness constraints, should specify the grouping preferences on the roles. If both are set to 'automatic', the binary fact type remain ungrouped.

All generated expressions require validated semantics

The generated fact types due to reverse engineering, or the new refactoring functions in CaseTalk, the manual process of entering fact expressions is skipped. Therefor these are all marked as unverified. The modeler should confirm, replace or update these so-called generated expressions.

Label types must be used

The new refactoring functions also allow to create Label Types ahead of time. This allows generic Label Types to be used later in the modeling process. If these Label Types are created, but not used, they'll show up under this rule.

Other

• Elements must comply with mandatory custom metadata
• Generalized Object Types needs a key
• URIs require fresh and valid content

Fact Types must be named

Newer versions of CaseTalk allow users to enter fact types without naming them just yet. However to meaningfully generate artifacts, these should be named at some stage. Therefor this rule checks for nameless fact types.

More

• Totality constraint must include all subtypes
• Derivable subtypes must have a type declaration
• Populations must comply with uniqueness constraint
• Populations must comply with totality constraint
• Populations must comply with subset constraint
• Populations must comply with data type
• Populations must be confirmed
• Populations could complete model
• Value constraint must comply with data type
• Default values must comply with data type
• Data type must be known
• Data type cannot be default
• Facts require proper verbalizations
• External expressions must be supported
• External substitutions must be supported
• Expressions must be current
• Namespaces support may not be recursive
• Expressions should not be redundant
• Types must be depicted
• Expressions and substitutions must use one locale
• Uniqueness constraints must be unique
• Cannot lexicalize recursion
• Vocabulary names must be unique
• Unique label types must be nominalized
• Substitutions must exist
• Primary key must occur only once
• Expressions must be meaningful
• Used namespace must be up to date
• Subtype declaration must be consistent

Custom Rules

For more information on adding your own rules, please continue here.