The OCL2.0 validation rule can be used in an active validation suite. In this case the validation rule will be executed on any change of constrained elements that are from the validation scope. Executing of the validation rule might be triggered even if no properties important to the validation rule actually changed and this can slow down the active validating speed. In order to avoid degradation of the performance you can create a binary validation rule that uses the OCL2.0 expression to validate model elements but also provides additional information for the modeling tool that allows to optimize triggering of executing after model elements change. For example, we want to check whether all classes have names. This can be done by creating the OCL2.0 validation rule and specifying the OLC2.0 expression:
name <> ‘’
The problem is that such validation rule actually is interested in a class property name value change but it will be executed on every property value of a class change. How we can fix this problem and inform the modeling tool to execute the validation rule only on the class property name change:
Create a constraint.
Set the stereotype «UML Standard Profile::Validation Profile::validationRule» for the validation rule.
Set the severity level, error message, and abbreviation.
Specify constrained element(s).
Specify the specification language OCL2.0
Enter the OCL2.0 expression as a body of the specification
public Map<Class<? extends Element>, Collection<SmartListenerConfig>> getListenerConfigurations()
Map<Class<? extends Element>, Collection<SmartListenerConfig>> configs =
new HashMap<Class<? extends Element>, Collection<SmartListenerConfig>>();
Collection<SmartListenerConfig> configsForClass = new ArrayList<SmartListenerConfig>();
9. Specify the validation rule’s implementation property value - a qualified name of the class
10. Add/import the created validation rule to a validation suite
See the MyOCLBasedValidationRuleImpl.java example in the <program installation directory>\openapi\examples\validation directory.
The implementation class must be in the classpath of the modeling tool or if the implementation class is in a plugin then the plugin’s classloader must be registered to the validation system (see Binary validation rule in the plugin).