You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Validation and verification are important activities when working with models. Validation means checking external consistency, i.e. that a model corresponds to what it models (usually the real world), whereas verification means checking internal consistency, i.e. that the model isn't contradicting itself. Validation in Ecore relies on capturing knowledge about a domain in the form of constraints, so that you can check that an actual object structure that conforms to a model, also satisfies additional constraints in a domain. 

As mentioned in the Ecore page, an Ecore model can be thought of as a way of constraining what objects structures are legal. By using types and multiplicity you can constrain what objects can be linked and how many, but there are still many constraints that cannot be captured with the concepts available in Ecore. To capture such constraints, Ecore provides a mechanism for validation that supports both hand-written Java code and interpreted queries using languages like OCL.

Suppose you are modelling an organisation with organisational units (OrgUnit), employees (Person) and roles (Role), and you want to capture the fact that people names can only have letters, spaces and dashes (-), and all OrgUnit should have a manager, i.e. an employee with a role labeled 'manager'. The first rule can be checked by hand-editing the setter-method for the name, but it may be better to somehow indicate that a rules is violated, rather than throwing an exception. The second rule can be easily coded, but it is more difficult to ensure the code is always run when relevant object properties are changed, since several objects and properties are involved. Ecore's mechanism relies on separating such domain rules or constraints from the checks that are part of the core model and enforced in the generated code. A validator object is created and is asked to validate all constraints for a particular object tree, and so-called diagnostic objects report any violations. The standard editors use this mechanism, and mark all invalid objects with a red (error) or yellow (warning) marker, depending on the severity.

 

  • No labels