# Check

### Description of the Check language

Xpand also provides a language to specify constraints that the model has to fulfill in order to be correct. This language is very easy to understand and use. Basically, it is built around the expression syntax that has been discussed in detail in the previous section. Constraints specified in the Check language have to be stored in files with the file extension `.chk` . Furthermore, these files have to be on the Java classpath, of course, in order to be found. Let us look at an example, in order to understand what these constraints look like and what they do:

    import data;
    context Attribute ERROR
      "Names have to be more than one character long." :
      name.length > 1;

Now, let us look at the example line by line:

1. First, the metamodel has to be imported.

2. Then, the context is specified for which the constraint applies. In other words, after the `context` keyword, we put the name of the metaclass that is going to be checked by the constraint. Then, there follows either `ERROR` or `WARNING`, These keywords specify what kind of action will be taken in case the constraint fails:

   Table 7. Types of action for Check constraints

   `WARNING` | If the constraint fails, the specified message is printed, but the workflow execution is not stopped.
   `ERROR` | If the constraint fails, the specified message is printed and all further processing is stopped.

3. Now, the message that is put in case that the constraint fails is specified as a string. It is possible to include the value of attributes or the return value of functions into the message in order to make the message more clear. For example, it would be possible to improve the above example by rewriting it like this:

       import data;
       context Attribute ERROR
         "Name of '" + name + "too short. Names have to be more than one character long." :
         name.length > 1;

4. Finally, there is the condition itself, which is specified by an expression, which has been discussed in detail in the previous section. If this expression is `true`, the constraint is fulfilled.

### Important

Please always keep in mind that the message that is associated with the constraint is printed, if the condition of the constraint is `false`! Thus, if the specified constraint condition is `true`, nothing will be printed out and the constraint will be fulfilled.

#### Guard Conditions

The Check language of Xpand also provides so called . These conditions allow to apply a check constraint only to model elements that meet certain criteria. Specifying such a guard condition is done by adding an if clause to the check constraint. The if clause has to be added after the context clause as demonstrated by the following example:

    import data;
    context Attribute if name.length > 1 ERROR
      "Attribute names have to start with an 'a'" :
      name.startsWith("a");

### The workflow component CheckComponent

The workflow component `org.eclipse.xtend.check.CheckComponent` allows to integrate model validation constraints using the Check into a modeling workflow using MWE.

This component provides the following configuration properties:

Table 8. Properties

Name of property | Description
--- | ---
`checkFile` | This property allows to add files containing constraints written in the Check language to the validation component.
`emfAllChildrenSlot` | Name of a workflow slot that contains an EMF object, which has to be validated including all child elements that it contains. This property only works in conjunction with EMF based models.
`expression` | This property allows to set a check expression for the validation component. This property only works in conjunction with non-EMF based models.
`abortOnError` | This boolean property determines if the workflow will be aborted or not if one of the validation constraints fails.
`warnIfNothingChecked` | If this boolean property will be set to true , a warning will be generated if there were no validation checks. Otherwise, no warning will be issued.