Papyrus/Mars Discussion/Validation

Background

At the Papyrus Summit in October (EclipseCon Europe 2014), there was a brief discussion of a need to resolve a perceived impasse in the current state of the model validation solution in the Papyrus Luna release. In particular, that of the two most prominent validation frameworks in and around EMF, both need some degree of enhancement to fully satisfy Papyrus's requirements and the current solution is a combination of both, whereas perhaps aligning Papyrus fully with one framework and "doing what it takes" to make that work will be best in the long run.

State of the Art

This section attempts to capture an understanding of the current capabilities and liabilities of the various Eclipse components involved in validation in Papyrus, from the perspective of what Papyrus needs from them. This is not intended to be comprehensive, but to address only Papyrus's requirements.

EMF

The EMF core run-time and code generation frameworks include support for validation in generated and dynamic Ecore models.

Capabilities

• generated validators (EValidator) accommodating hand-written “extrinsic” constraints but also invoking the “intrinsic” constraints modeled in Ecore as operations
• validation delegates and operation delegates for integration of languages such as OCL and to support dynamic Ecore models such as are used in UML profiles

Limitations

• the EValidator registry is global. Unlike the package registry, validators cannot be plugged in per resource-set. Usage of custom validators requires creating a diagnostician with a custom validator registry, which usually is done the UI’s validation action.
• constraint messages support localization in the plugin.properties file, but only when implemented by custom Java code. Delegates have no means to specify messages
• likewise the severity of the diagnostics reported on constraint violations

EMF Validation

One of the extra EMF components logically comprising, affiliated with the GMF Run-time for diagrams, especially as a prerequisite for the EMF Transactions API for live validation of model edits.

Capabilities

• contribution of constraints by dynamic providers, extrinsic to (and in addition to) those that are defined in the Ecore model. Constraint bindings for application-specific validation of shared models
• pluggable constraint languages
• severities and messages supported for any constraint language
• localization of messages in plugin.properties
• constraint filtering API and user preferences for enablement
• live mode, intended primarily to support integrity checks in EMF Transactions

Limitations

• localization of messages in the plugin.properties relies on defining constraints in the plugin.xml, which doesn’t scale nicely. Custom constraint providers need to provide their own translation scheme
• it can be awkward to manage the comings and goings of dynamically-discovered constraints in the validation preference page

Other

• provides bare-bones integration with the EValidator API in the form of an example project: a validator that delegates to the EMFV API. Does not provide the inverse (an EMFV constraint provider delegating to EValidator) but actually the UML2 project does (for the UML metamodel constraints particularly; see below)

OCL

The OCL project provides implementations of the EMF delegate APIs for validation and other behaviours, and also specific support for validation of UML models with UML's peculiar semantics.

Capabilities

• provides a dynamic constraint provider that integrates UML constraints defined in profiles into the validation of profiled models
• supports an extended constraint semantics using tuples instead of boolean results to communicate status, severity, message, and more
• Validity view with detailed presentation of problems and integration with debugging facilities to analyse causes of constraint violation
• load OCL documents and evaluate their constraints on the model

UML2

The UML2 project provides some small extensions/plug-ins to the EMF Validation Framework, besides supporting generation of core EMF validation facilities for class models via Ecore.

Capabilities

• a constraint provider that delegates to UML’s generated EValidator to integrate the UML metamodel constraints into EMFV-based validation

Papyrus

Papyrus integrates, extends, and generates code targeting various of these validation frameworks, primarily for validation of UML models (particularly as extended by profiles).

Capabilities

• generation of EMFV-based validation plug-in for a profile, including
  • OCLpivot language for OCL constraints using the Pivot environment
  • severities, messages
  • profile-specific constraint bindings
• Validation view presenting validation problems: includes problem markers from workspace resources but also supports attachment of problems to resources that are not in the workspace (e.g., in CDO repositories, on the web, etc.)

Requirements

• extensible validation for DSMLs, contributing domain-specific constraints via profiles and/or other mechanisms
• users should be able to select which constraints to include/exclude in the validation operation
• it should not be necessary for a profile to define a stereotype extending a metaclass just to define constraints for that metaclass (this leads to required extensions). A profile should be able to constrain a referenced metaclass without reference to any stereotype

Next Steps

We need to be clear on what it is that is not working for Papyrus. Where is the extrinsic EMF Validation Framework (EMFv) falling short? What do we see as the motivation for migrating papyrus onto the EValidator? There is some overlap in these capabilities, and almost certainly some that could better or more appropriately be provided by other projects. So there are opportunities to rationalize/restructure/improve the implementation. But where should we spend our energy? One could imagine improving the EMF EValidator solution to:

• make it easier to customize messages for delegate-based constraints
• implement a resource-set validator registry and composite validators with a new plug-in mechanism that discovers additional context-specific validators at run-time
• enhance the core Ecore annotations to let a package (e.g. a UML profile) define constraints for EClasses in another package (e.g. the UML metamodel)

Or we could enhance the current EMFv-based solution by reorganizing existing capabilities:

• push the UML profile constraint provider into an optional feature of the EMFV project
• enhance the EMFv validator to delegate to the registered EValidators to integrate Ecore-modeled constraints (essentially generalize what we have in UML2 and push it into the EMFv project)
• fix issues in the UI, especially management of constraints in the preference page