Community
Participate
Working Groups
Papyrus users are complaining that OCL Constraints are not validated (Bug 413512). This is not surprising because the UML2 project is OCL-blind. Suggest introducing a new extension point to map OpaqueExpression 'body-language-name' to 'body-language-support'. The only thing the UML2 project would then need to know about OCL is that the default body language name is the three letter string "OCL". The 'body-language-support' would provide at least a validation API for M1 checking and an execution API for M2 usage. It might also be appropriate to migrate some of the invocation/validation delegates support to an import/export API, thereby enabling e.g. ALF constraints to provide corresponding functionality. I'll work on the validation/execution API.
Created attachment 239811 [details] Constraint validation support Attached patch introduces a body_support extension point for a BodyLanguageSupport class that Opaque**** classes use to validate their bodies. The edw/427152 branch in OCL GIT has the OCL implementation of the BodyLanguageSupport. Seems to work sensibly in UML editor and apart from some minor ergonomic issues works in Papyrus too. [This fixes M1 constraint usage. Still to look at M2; probably just an extra BodyLanguageSupport method.]
Created attachment 239893 [details] Additional body-language constraints To simplify review I've partitioned the earlier patch into three steps 1) additional constraints in UML model (this attachment) 2) Reload GenModel and regenerate (you can do this without a bloated attachment) 3) additional support (next attachment) The new constraints are: OpaqueAction::body_language_size OpaqueAction::body_language_text OpaqueBehavior::body_language_size OpaqueBehavior::body_language_text OpaqueExpression::body_language_text to support syntax validation at M1 InstanceSpecification::instance_constraints to support validation of UML M0 artifacts by UML M1
Created attachment 239894 [details] Body Language Support This introduces a new body_support extension point maintaining a BodyLanguageSupport.Registry with an extensible API.
This improvement may have a bad ergonomic consequence. a) the UML 2.4.1 metamodel has large numbers of OCL errors in, so users will be swamped with annoying errors they can do nothing about. UML 2.5 should be much better, but SysML etc etc may not. b) interpreted execution of large numbers of OCL constraints on big models may push a very poor validation time over the threshold to unacceptable. a) can be mitigated by a Model-level EAnnotation to explicitly enable/disable body validation; default polarity for old models is disabled. New models get enabled by default. b) can be mitigated by a UML Model Editor Enable/Disable Body Validation.
Thanks for the patches. I've applied them locally to review and run some tests with the correspond branch of the OCL repository. I'm not particularly concerned about the "bad ergonomic consequences" mentioned in comment 4 as on my 2012 MacBook Pro it doesn't take more than 15 seconds to validate the UML Metamodel, turning up 168 OCL parsing errors. However, filtering of constraints (both by the user in the Preferences and by code in the validation API) is a capability provided by the EMF Validation Framework component that applications such as Papyrus use. So, implementing this OCL constraint validation in an application using that framework, one could provide as much end-user control as required over exactly how much OCL is validated and when, to mitigate this cost, more readily than in a UML2 implementation. I do have two concerns about the proposed design: (a) for InstanceSpecifications, validation would evaluate all constraints (in supported languages) defined on the classifiers of an instance specification, accessing the instance's slot values in property navigation expressions. This really doesn't make sense to me because (as already remarked in bug 417062 comment 4), InstanceSpecifications are not run-time instances, but merely (partial) models describing run-time instances (even deliberately describing invalid instances). Even if a user did want to check the instance's classifiers' constraints on it, this would need to be enabled by some kind of tag (a new stereotype in a new profile?), and that is beyond the UML2 project's mandate (b) the constraints defined in the UML metamodel, itself, should be those that pertain to well-formedness of UML models. I'm not sure that the well-formedness of the text of opaque expressions is a concern of the UML metamodel. Eclipse provides mechanisms for language providers such as OCL to add validation of these expressions, whether by EMF-V or some ad hoc action or something more suitable for the particular language. I can understand the motivation to provide a common API in UML2 for language providers to plug into for a uniform user experience, but I don't know that a uniform user experience is necessary for different languages Overall, I think this particular validation use case is best implemented by a UML modeling application such as Papyrus, not by the UML2's UML implementation. So, resolving as wont-fix.
A Papyrus-based approach cannot provide validation within the UML Model editor; the contributed solution does because it extends the standard EValidator framework. EMFv predates the standard EValidator framework and has poor extensibility. The optional validity of InstanceSpecifications is certainly a problem; so much so that it should have a UML-defined 'tag'. Eclipse UML could easily add a validatable flag in the 'Ecore' profile. It seems a real shame that Eclipse UML must impose a uniform experience of zero body language validation forcing applications to design custom validation frameworks that will forever compete with and be inconsistent with the standard framework. Surely Eclipse should be extensible?
With the advent of EMF' AnnotationValidators, EMF now supports validation of extensions. Perhaps UML should too. The problem of InstanceSpecification optional validation is addressed by the Validation stereotype of the Eclipse OCL OCLforUML profile pending its promotion to an OMG profile. The lack of UML support for body validation is currently addressed in the UML Editor by the OCL->Validate menu option, which can be helpful, but also confusing. Why do two different Validate options exist and behave differently? (OCL->Validate is also needed in the GenModel editor.) Papyrus has to add an extra validation source that occasionally gets lost.
