Modeler:8/RepositoryRules

Model Well-formedness

This window shows the well-formedness 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.

Elements must comply with mandatory custom metadata

Information elements may have custom attributes. These custom attributes may be set to be mandatory. This rule makes sure the various model elements indeed have these mandatory custom attributes set.

Generalized Object Types needs a key

Generalized object types may contain various object type expressions for each role, and a uniqueness constraint on top of each role. If that happens, CaseTalk does not know what to select for a potential primary key for a database artifact. Therefor the Object Type must either have an artificial key, or one UC needs to be set as preferred.

URIs require fresh and valid content

Custom attributes and annotations may contain links to external documentation or content using URIs. CaseTalk may check external sources (URIs) for validity and content changes.

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.

Totality constraint must include all subtypes

Supertypes may be forced to be one of the subtypes by adding a totality constraint on the subtype. When that occurs, all subtypes should be under this constraint.

Derivable subtypes must have a type declaration

When a subtype is marked as derivable, the supertype must have a binary fact expression related to it, which specified which subtype it actually is. This fact type must be populated with all potential subtype names.

Populations must comply with uniqueness constraint

The populations are checked against the placed uniqueness constraint. No violation must occur.

Populations must comply with totality constraint

The populations are checked against the placed totality constraint. No violation must occur.

Populations must comply with subset constraint

The populations are checked against the placed subset constraint. No violation must occur.

Populations must comply with data type

The populations are checked against the specified data type in label types. No violation must occur.

Populations must be confirmed

Populations can have three states. Unconfirmed, confirmed or Counter Example. None should remain unconfirmed in a valid model.

Populations could complete model

To render a knowledge graph, some populations require more population under a different object/fact type. This rule checks for lacking instances to be able to render a more complete knowledge graph.

Value constraint must comply with data type

Similar to populations needing to comply with specified label types, the value constraints must comply with the same data type.

Default values must comply with data type

Roles may be configured to provide a default value. These default values must comply to the specified data type in the label type.

Data type must be known

Using the data type dialog, even types unknown to casetalk, can be configured to be a subtype of some other or some technical data type. For all data types not known to casetalk, such subtype must be specified.

Data type cannot be default

While modeling, casetalk does not automatically derive data types. When those are not derived yet, and not specified, they remain default. These should be specified.

Facts require proper verbalizations

When refactoring occurs, expressions may alter. CaseTalk keeps track of those to make sure the verbiage is verified and validated by modelers. Unchecked expressions are considered a violation.

External expressions must be supported

Expressions imported from other models are considered to be external expressions. CaseTalk remembers the origin, the namespace. The current model needs to be set to allow the import of the external namespace. This rule is added to safeguard the proper re-use of namespaces.

External substitutions must be supported

Fact expressions may substitute other object type expressions. When that happens, those object type expression may only be local or from a supported external namespace.

Expressions must be current

Expressions merged from another versioned model, must be up to date. When the server reports a newer version of the imported namespace, these expressions may need to be updated.

Namespaces support may not be recursive

To safeguard proper namespace re-use, casetalk supports grants on namespace uses. These references should never be recursive.

Expressions should not be redundant

Expressions may be edited or added, but should never sound like other expressions. One of them is then considered redundant.

Types must be depicted

CaseTalk keeps track of object/fact/label types in diagrams. If some are not shown in any diagram, they are considered a violation of this rule. A way to solve it is to add them to at lest one diagram.

Expressions and substitutions must use one locale

Expressions can be entered in various language locales. When expressions are getting substituted into others, both need to be of the same locale.

Uniqueness constraints must be unique

Uniqueness Constraints may be named, and those names represent meaning. The combination of roles need to be unique and potentially named. Therefor all named constraints must be unique across the model.

Cannot lexicalize recursion

FCO-IM enables recursion modeling, but CaseTalk cannot derive a database structure for this. Violations of this pattern are reported.

Vocabulary names must be unique

...

Unique label types must be nominalized

Roles played by a label type, which are also under a narrow UC, should really be modeled as object types. The violations are reported as nominalizable label types.

Substitutions must exist

...

Primary key must occur only once

UCs may be marked as preferred to allow CaseTalk to render them as primary keys for database artifacts. Multiple UCs cannot be marked as preferred at the same time for a single database table.

Expressions must be meaningful

...

Used namespace must be up to date

External models merged into the current model, come with a version number from the casetalk server. If casetalk detects a newer version of this model, it reports the OTFTs which need to be updated.

Subtype declaration must be consistent

Binary facts which verbalize subtype types, and contain subtype names in the population, must contain all subtypes to be in the population.

Custom Rules

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