EMF learning, for scalable, customizable model validation-learning from a variety of implementation methods

Self -:

http://blog.csdn.net/javaman_chen/article/details/6057033

http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-emfvldt/

http://blog.csdn.net/james999/article/details/1624747

The EMF Validation Framework provides a validation framework for EMF Eobjects, which provides more complex and comprehensive validation compared to the EMF Evalidator API and is easy to use and extensible. The EMF Validation Framework provides a flexible way to validate definitions, supporting two validation triggering mechanisms: Batch and Live. It supports the implementation of constraints in both JAVA and OCL languages, and it also supports model scanning algorithms when customizing validation, and provides a Validation Client Context to circumvent unnecessary validation.

The validation of the EMF model is done primarily through the invocation of the Modevalidationservice class, which also declares a factory method Newvalidator () to obtain the IValidator implementation class. The IValidator executor obtains the matching constraint from the Validation service module for validation. The IValidator has two sub-interfaces, namely Ilivevalidator and Ibatchvalidator, and the model is validated in live or batch mode, and the pattern is specified by Evaluationmode.

The following steps are required to verify the overall:

1. Build Constraints.

2. Injection verification Environment

3. Binding Constraints to Application

4. Writing the Verification body

1. Building constraints

Currently supports three ways: Java code,emf Model, and OCL. all constraints must implement the Imodelconstraint interface, define the logic for validation execution (validate ()), and have a constraint descriptor (a class that implements the Iconstraintdescriptor interface). The descriptor contains the source information for this constraint, such as whether the validation mode is live or batch, the target object for validation, and so on. There are different implementations under different constraint model types. Because the framework of the validation framework relies on the description and declaration of Plugin.xml to register the corresponding constrain implementations, different parser are responsible for parsing and managing.

1.1 java mode. the construction of constraints is accomplished primarily by inheriting abstractmodelconstraint abstract classes. Abstractmodelconstraint uses the Ivalidationcontext interface as a method parameter for validate () and returns the Istatus object used to encapsulate the validation results. Validate (Ivalidationcontext ctx)

Ivalidationcontext Object

(1) Provides information about the current validation environment, including:
Target: the object being validated;
EventType: Represents an event that triggers a validation operation in live mode;
Currentconstraintid: The currently executed constraint ID, and so on ...

(2) provides some methods to improve the efficiency of validation, such as can be used to specify that some target object is "qualified" can not perform certain validation methods, cache validation objects.

In the Validate method, if the constraint is evaluated without passing, you can call the Ivalidationcontext interface definition of the Createfailurestatus (Object ... args) method to return the error state type in contrast, if the evaluation succeeds, The Createsuccessstatus () method can be called to return a success status type.

1.2 OCL

Using the EMF OCL is very simple, using queryfactory to construct a query object, set the expression (Express), and the context on which the expression depends (typically classifier in the EMF OCL). The given Eobject object is then checked and evaluated. --it's so simple.

Query query = QueryFactory.eINSTANCE.createQuery ("Book.allinstances ()->select (B:book | b <> Self and b.title = Self.title) ", LibraryPackage.eINSTANCE.getBook ()); Query.setextentmap (extents); Collection result = Query.evaluate (MyBook);

2. Injection Verification Environment

The injection of the constraint is completed by implementing the Org.eclipse.emf.validation.constraintProviders extension point.

3. Binding with Application

This feature is implemented by org.eclipse.emf.validation.constraintBindings extension points.

It can only be run in a ECLIPSERCP environment, and the implementation of the extension point is cumbersome.

4. Writing Verification Topics , the reference validation logic is changed

The validation logic for batch is:

2. Specifies the validation object that can make a eobject or its collection List objects = Myresource.getcontents ();
4. build Ibatchvalidator by validating service Modelvalidationservice
6. specified as batch mode by Evaluationmode.batch IValidator validator = modelvalidationservice.g  Etinstance (). Newvalidator (Evaluationmode.batch);
8. Validator.setincludeliveconstraints (true); Constraint validation constraints that contain live mode need not be specified here, because subsequent validations need to be registered as application instead of added, and constraints can be set through the filter, which makes it difficult to add new constraints to the use of the validation.
10. //You can add a constraint to the filter settings validate.addconstraintfilter (new Iconstraintfilter () {...
12. The validation of the model returns the Istatus object istatus results = Validator.validate (objects);   
14. determine the validation status if (!results.isok ()) {errordialog.openerror (null, "Validation", "Validation Failed", Results); }

Another way//just replace the implementation of the off-the-shelf validator

Users can also write their own implementation of the Evalidator, and then inject the implementation class into the Evalidator registry, the same can be done for model validation operations,
This approach does not require the implementation of the extension point, so only osgi environments are required.

1. Writing the Evalidator implementation

(1) If the constraint is indicated directly in the model, the corresponding Evalidator implementation class can be generated directly through the *.genmodel file.

2. Adding to the Evaldator registry

corresponding Code

3. Write the validation code for the model

1. Set validation target object Target=gettartget ();
   
2. Diagnostician diagnostician=New Diagnostician ();
3. Basicdiagnostic diagnostic=diagnostician.createdefaultdiagnostic (target);
4. Map<object, object> context = Diagnostician.createdefaultcontext ();
5. Perform validation operations Diagnostician.validate (library, diagnostic, context);
   

Evaluation:

There are two points that can hinder the implementation of extensible, customizable validation:

1. Not only need to verify the logic implementation, but also need to register, set the extension point can operate to specific configuration constraints, can not arbitrarily add custom constraints

2. Each constraint corresponds to a piece of code, how to add a custom validation needs to think, here can refer to the implementation of the OCL verification engine, PKU Master's thesis

EMF learning, for scalable, customizable model validation-learning from a variety of implementation methods