|
|
| Line 1: |
Line 1: |
| To make sure the model is well formed, CaseTalk can validate the model for you. It ranges from structural checks, to soft semantics and examples, to multi-model management aspects. The violations may range from error, warning to hint.
| | = 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. |
|
| |
|
| = Standard FCO-IM rules =
| | It is advised to perform these rule checks regularly to keep the model in order. |
| The following rules are present since the very first version of CaseTalk and are a hardcoded set of rules.
| |
|
| |
|
| == Every fact type must have an intra UC ==
| | [[File:ModelWellFormedness9.png]] |
| [[File:Every fact type must have an intra uc.png|thumb|UC Rules]] For each fact type, there must be at least one uniqueness constraint that concerns one or more roles of this fact type only. | |
| * The diagram ''UC Rules'' shows that neither the Fact Type nor the Object Type contains any UC.
| |
| * This severity level of this rule is demoted to a warning if the GLR configuration is set to "Assume wide UC".
| |
|
| |
|
| == The N rule must be valid for every nominalized fact type ==
| | The disablement of rules is saved inside the current project settings. |
| Every nominalized fact type with n roles only has exactly one uniqueness constraint over all n roles. Generalizations are an exception, therefor this is considered a warning, not an error.
| |
|
| |
|
| * In the diagram ''UC Rules'' the object type ''City'' should have (all) roles under a single UC.
| | = Full List = |
|
| |
|
| == The N-1 rule must be valid for every fact type ==
| | Click here for a full list of validation rules and their description: Integrity Checks. |
| 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. If a fact type with n roles has at least one uniqueness constraint on less than n-1 roles, then the fact type is splittable. The n-1 rule-test simply consists of the check that there are no UCs that are too small.
| |
| | |
| * In the diagram ''UC Rules'' the Fact Type contains 2 roles. An UC should exist over at least 1 role.
| |
| | |
| 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 subtype rule must be valid for every subtype ==
| |
| | |
| [[File:Proper Subtype.png|thumb]]
| |
| Every Object type which is marked as a subtype, must have one role, contain a single UC over this role, this single role mus be played by an Object Type, and the Role cannot have a TC on it. Additionally if the Object Type, played by the role, is not flagged as a supertype, this rule will show that as well.
| |
| * Figure ''Proper Subtype'' shows Student as a valid construction as subtype of the supertype Person.
| |
| | |
| == The alias of an object/fact type must be unique ==
| |
| | |
| Even though a Object/Fact Type name must be unique, and can have an alias, this rules warns users for potentially introducing alias names which correspond to other Object/Fact Type names.
| |
| | |
| == 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 or fact type expression.
| |
| | |
| == Non-lexical object types without totality constraints must have a fact type expression ==
| |
| [[File:OT with TC.png|thumb]]
| |
| If no totality constraint at all applies to any of the roles played by a certain nominalized fact type, then that fact type must have an existence postulating fact type expression.
| |
| * Diagram ''OT with TC'' shows the lack of Fact Type Expressions, but the existence of a TC over role 4 and 10 to make sure the city population exists in a fact.
| |
| | |
| ==The actual population of every fact type must be verbalizable==
| |
| Object type expressions verbalizing a population is not always sufficient to be verbalizable. Sometimes an additional fact type expression or totality constraint is required to guarantee the population really exists.
| |
| | |
| ==A strict equality constraint must apply on each subtype tupel==
| |
| The population under a subtype must correspond to the population of the supertype. Strictly speaking this is not saying anything about a strict equality constraint, since that is not yet fully supported in CaseTalk.
| |
| | |
| ----
| |
| | |
| = Extended Rules =
| |
| The following rules were added after CaseTalk was used for a while, and kept evolving to catch mistakes made by beginners and experienced modelers.
| |
| | |
| == Fact types may not contain redundant role combinations ==
| |
| [[File:Role redundancy.png|thumb]] Different fact types may contain sets of roles which have a similar construction. The set of roles and their played by object types may be modeled redundant. If so, it can be resolved by combining these role sets into an object type. The evaluation of this rule uses the UCs over more than a single role which has an equivalent set of played-by roles elsewhere.
| |
| * Diagram ''Role redundancy'' shows a potential redundancy for role 17+18 and 11+12.
| |
| | |
| == The population should match the value constraint ==
| |
| This rule checks the population values to be within the specified value constraints of label types.
| |
| | |
| ==Facts must have at least one sample population==
| |
| Fact types only exist by expressions and samples. Having no tuples makes validating the expression impossible. Therefor at least one sample must exist.
| |
| | |
| ==Roles must have distinct semantic meanings==
| |
| [[File:Semantic roles.png|thumb]]
| |
| More than one role can exist in a fact type. If multiple roles in a fact type are played by the same object type or label type, the modeler should either place a role-fix or insert an extra object type to make it distinguishable. Model transformations will fail if this is not handled first. (This is to prevent ending up with a table containing multiple columns with the same name.)
| |
| * The diagram ''Semantic Roles'' shows how role 20 and 21 are both played by Person and bear no distinction. Either an Object Type needs to be inserted in the model, or a Role should be named using a so-called Role-fix.
| |
| Additionally the fixed role name should not exists as a separate Object/Fact Type, or Alias name. This would violate unique names in the model.
| |
| | |
| ==Label types must contain a datatype definition==
| |
| Label types require some data type definition. CaseTalk is able to derive that from the population using a wizard. If not set yet, these label types trigger this warning rule.
| |
| | |
| == Fact types may not contain object types ==
| |
| Fact types with n roles, and n > 2, with a single UC covering N-1 roles, these roles under the UC may be candidate for nominalization.
| |
| | |
| == Binary fact types must have grouping preference ==
| |
| [[File:Role without grouping preference.png|thumb]]
| |
| Binary fact types where both roles are under a single uc, or both roles under their own uc, this fact type cannot be automatically grouped during transformation. Therefor to be optimized, at least one role needs a grouping preference.
| |
| * Diagram ''Role Without Grouping'' shows a fact type with two roles (14, 15) which form a on-to-one relationship between Student and Apprenticeship. This can be implemented by a single column in a table, but which table should CaseTalk choose without a user preference?
| |
| | |
| == All generated expressions require validated semantics ==
| |
| In later version of CaseTalk more model (re)factoring functions exist. This may lead to default generated expressions, which are not manually entered by an analyst. To guarantee model quality, these need to be manually verified.
| |
| | |
| == Label types must be used ==
| |
| Label types can only exist if played by at least one role. Label types found in the model without any role played by this label type, the label type should be removed.
| |
| | |
| ----
| |
| | |
| == Elements must comply with mandatory custom metadata ==
| |
| Since the introduction of custom attributes in CaseTalk some of these attributes may be set to being mandatory. This rule check for elements in the information model which lack the presence of certain custom attributes while the active definitions require them. Note rule checks only the selected custom attribute definition set.
| |
| | |
| == Generalized Object Types needs a key ==
| |
| Generalized object types may be modelled only with optional roles. This would prevent artifacts to contain a primary key. Therefor the fix can be as simple as setting the flag to generate an artificial key on those cases.
| |
| | |
| == Totality constraint must cover all subtypes ==
| |
| [[File:Derivable subtype.png|thumb]]
| |
| If a supertype exists, and a TC is placed on one or more subtypes, this rule checks to see if all subtypes are under this TC or not. If any of them is marked, than they should all be marked.
| |
| * Diagram ''Derivable subtype'' shows a TC between Teacher and Student which means that any Person needs to be either a Teacher or a Student.
| |
| | |
| == Derivable subtypes must have a type declaration ==
| |
| Subtypes can be flagged as derivable. In order to properly derive them, the supertype usually has a binary fact type which specifies of which subtype it actually is. The rule checks for a binary fact type attached to the supertype which also is populated with the subtype names.
| |
| * Diagram ''Derivable subtype'' shows Person and two derivable subtypes. The Fact Type ''Person Subtype'' contains the subtype indicator. This rule checks is the subtype names exist in the population.
| |
| | |
| ==Populations must comply with uniqueness constraints==
| |
| The example population should adhere to the uniqueness constraints applied to the corresponding roles.
| |
| | |
| == Populations must comply with totality constraints ==
| |
| If a tc mandates tuple existence, the population should comply to that. More tuples are required to satisfy this rule.
| |
| | |
| == Population must comply with subset constraints ==
| |
| Subset constraints mandate existence of a population in another fact type. Therefor this rule checks if that is the case within the model and the example population.
| |
| | |
| == Population must comply with datatype ==
| |
| Population values are set to be of a specific data type as specified in the corresponding label type. The values are parsed by CaseTalk to validate they meet the datatype requirements.
| |
| | |
| == Value constraints must comply with datatype ==
| |
| The population contains values and value constraints limits the range of these values. Therefor the limits specified must comply to these datatype themselves.
| |
| | |
| == Default values must comply with datatype ==
| |
| Roles may contain a default value. The specification of this value must also match the datatype from the label types.
| |
| | |
| == Data type must be known ==
| |
| Label types specify a datatype. These datatypes must be either one of the available types embedded in CaseTalk, or defined in one of the artifacts list of available types. If CaseTalk does not know it, go to "Tools\Data Types" to drag and drop it into the appropriate data type tree.
| |
| | |
| == Data type cannot be default ==
| |
| Until a datatype is specified, or derived by CaseTalk itself, the type is set to ''default''. This should not happen when the model needs to be forward engineered.
| |
| | |
| == Facts require proper verbalizations ==
| |
| When both an example population is absent, the soft semantics have been refactored and unconfirmed, this warnings notifies the user of a state which needs attention.
| |
| | |
| == External expressions must be supported ==
| |
| It is possible to merge fact expressions from another model file (aka namespace) into another. The expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces can be used and which not. This rule simple checks for expressions which were not yet marked as a valid merged namespace.
| |
| | |
| == External substitutions must be supported ==
| |
| It is possible to merge object type expressions from another model file (aka namespace) into another. The expressions are flagged as originating from a different namespace. CaseTalk allows architects to specify which namespaces can be used and which not. This rule simple checks for object type expressions which are used in fact expressions, but not yet marked as a valid merged namespace.
| |
| | |
| == External namespace must cover one version ==
| |
| In elaborate editions of CaseTalk various namespaces and versions of them are allowed to be merged into other models. It should however never occur to merge expressions from two distinct versions of the same namespace.
| |
| == Expressions must be current ==
| |
| Repeated merging of models with newer and newer versions may leave some older, previously merged expressions in the model. If those expressions are not used in any substitution, they are marked as expired expressions. If these are Object Type Expression and not substituted anywhere else, they are reported as unused and expires.
| |
| | |
| == Namespace support may not be recursive ==
| |
| Namespaces allow user to track re-use of information across models. Using grant/revoke of the allowed use of such a namespace may trigger a self reference. Namespace A uses B uses A. This is not allowed, and needs to be adressed.
| |
| | |
| == Expressions should not be redundant ==
| |
| Through merging it is possible to merge expressions which have similar soft semantics. This rule checks for those occurrences.
| |
| | |
| == Concepts must be qualified ==
| |
| Concepts may be added to the information model, without expressions, population or even roles. This is a convenient way to start adding terms and later qualify them. When concepts are not yet qualified they are listed by this rule. It does not stop model transformations, they are simply ignored and removed from the model.
| |
| | |
| ==Used namespace must be up to date==
| |
| Namespaces imported into the active model are found to have a newer version in the Teams Server, and therefor the Object/Fact Types from this namespace may need to be updated.
| |
| | |
| == Subtype declaration needs to be consistent ==
| |
| Once an object type is marked to be a subtype, and checked in into the Teams Server, this rule keeps an eye out for these Object Types to not fall back to a regular Object Type.
| |
| | |
| == Facts may not be merged from multiple namespaces ==
| |
| Facts contain expressions. These expressions should be originating from the same namespace, or be added in the current IG. The expressions should not originate from multiple sources. It is not an error, but a warning.
| |
| | |
| == Expressions and substitutions must use one Locale ==
| |
| The model file can be set to a Locale (country and language). The expressions can be similarly set. It is however a clear violation when an Object Type Expression has a different locale setting than the Fact Type Expression it is substituted in. This rule checks for these violations.
| |
| | |
| == Uniqueness Constraints must be unique ==
| |
| Uniqueness constraints may contain a name to identify a group of involved roles. Therefor this name must be unique along the Object/Fact type names. It is considered to be a warning since it may not generate failures in the artifacts. In the artifacts the UC Name is used to name primary or alternate keys.
| |
| | |
| == Cannot lexicalize recursion ==
| |
| Some objecttype has a role to itself. The current version of CaseTalk will not be able to lexicalize this model. It'll prevent a database schema to be derived.
| |
| | |
| == Vocabulary names must be unique ==
| |
| All object/fact type names must be unique. This is also the case when translations come into the model. Every OTFT Name in a specified Locale must be unique within the locale for all translated names.
| |
| | |
| = Custom SQL =
| |
| Users are now able to build their own additional set of rules using SQL.
| |
| | |
| There may be more validation rules active within to your environment. These may have been added by customizations. See also: [[Custom_SQL_Rules|Customization through own rules in SQL]]
| |
| | |
| ----
| |
| | |
| Back: [[:Modeler:Tutorial/Subtype and Generalisation|Subtype and Generalisation]]
| |
| | |
| Next: [[:Modeler:Tutorial/Version Management|Version Management]]
| |
| | |
| [[Category:Modeler]]
| |
