Validation Overview for Domain-Specific Languages

As the author of a domain-specific language, you can add constraints to your domain models to check for semantic correctness beyond what you can express in the syntax of that language. Users of your domain-specific languages can validate the models that they create from those languages and display the results.

• You can specify constraints on a value property such as the following:

  •If the value property is a string, it must not contain spaces.

  •If the value property is a number, it must be smaller than another value property.

• You can specify constraints on a relation such as the following:

  •All the objects that are connected by a given relation must have different names.

  •Following the relation must not lead back to the same object.

You define each constraint as a method within a partial class. The partial class is for the class of the domain model object that you want to validate. The constraint method uses the property, the relationship, and the role names that are defined in the domain model.

To define a validation constraint, you must make sure that the following conditions are true:

• In DSL Explorer, in the Editor/Validation node, one or more of the Uses properties such as Uses Open and Uses Menu are True.

• The ValidationState attribute is applied to each class of element in which you want to define validation methods:

  [ValidationState(ValidationState.Enabled)]

• Each validation constraint is defined in a method that can have any name, but must have a ValidationMethod attribute similar to the following:

  [ValidationMethod (ValidationCategories.Open | ValidationCategories.Save | ValidationCategories.Menu ) ]

The validation framework applies each validation method to each object in the model that belongs to the class of the method or its subclasses. You can define a constraint on any domain class in the language, including the root model and its relations, and you can enable validation for any of the following events:

• Menu

  If you enable this option, users can validate a model by right-clicking anywhere in the model.

• Save

  If you enable this option, validation methods in the Save category are run when the user saves a model to a file. This helps them avoid inadvertently saving or processing an invalid model. A warning appears, but they can save the file anyway.

• Open

  If you enable this option, validation methods in the Open category are run when the user opens a model from a file.

• Load

  If you enable this option, validation methods in the Load category are executed before the model is saved. If errors are found, the user is warned that it might not be possible to re-open the model. This category is intended for errors such as name duplication, which could cause serialization exceptions.

• Custom

  If you enable this option, you invoke validation from your own code such as a custom menu command. You can group validation methods into categories. When your custom code invokes validation, it can specify which category to invoke.

Each of these categories has a global switch in the DslDefinition.dsl file, and you can enable each validation method separately for any combination of the categories.

Configuring Validation Settings

The following properties can be set at the model level. To change these properties, select the Validation node in the Domain-Specific Language Explorer, and go to the Properties window.

Running Validation on a Model

When a user is editing a model, that is, an instance of your domain-specific language, the following actions will run validation:

• Right-click the diagram and select Validate All

• Right-click the top node in the Explorer of your DSL and select Validate All

• Save the model

• Open the model

Any validation errors will appear in the Output and Error List windows. You can double-click an error in the Error List window to locate the model element that is the cause of the error.

Change History