The good and bad feature of Complete OCL is that it's an independent
text document, hence the inability of any tool to load it
If you knew what the OCL was it could have been embedded in the
model to start with.
I'm toying with adding an EAnnotation/GenAnnotation to allow
references to the Complete OCL, but it will always be the case that
if I'm an Ecore modeller working for a company with very strong
style rules then in the past I would need to develop a custom Ecore
with stricter validation. Now I can just load a Complete OCL
document to tailor Ecore with my style rules.
Potentially some magic registry (e.g. the UMLX/QVTd/OCL Model
Registry) could allow the user to provide user-specific model
bindings and so reference the Complete OCL, but this requires tools
to explicitly use the Model Registry capability.
What might help is if there was an EMF Package Delegate that allowed
a load action to be configured via extension points, then every load
of *.uml could activate my package delegate that could go looking
for some Complete OCL. At present it is impossible for non-EMF code
to gain access before an Invocation/Setting/Validation/Query
delegate is invoked.
Similarly, I've been thinking DND would be much nicer than Load
Resource..., and if a DND of a Complete OCL onto a ResourceSet could
activate the EMF DND drop extension point, then use of Complete OCL
gets even easier.
On 06/02/2012 14:05, Kenn Hussey wrote:
Where are the Complete OCL invariants being defined? It seems
that that would be the right place to ensure that Complete OCL
is loaded (e.g., by adding a dependency). Or, if functionality
like this is desirable in Papyrus, perhaps it makes sense to
ensure that it's loaded there...
On Fri, Feb 3, 2012 at 2:15 AM, Ed
I'm trying to make Complete OCL validation work
User has Ecore/UML/... meta-model
User has Complete OCL complement to that meta-model
User has instance of that meta-model
User validates and the Complete OCL invariants are executed
Problem has always been that validation does not know that
Complete OCL exists so it is ignored and useless.
Solution: provide a Load Complete OCL Menu Action to enhance
the model and/or ResourceSet and/or EValidatorRegistry.
This can be applied at M1 or M2, so if a Complete OCL
document is loaded into an Ecore editor, the additional
constraints can enforce arbitrary style constraints such as
"interface-name must start with I".
So if Complete OCL can augment the UML Model Editor
externally at M2, shouldn't Stereotypes also provide OCL
that works internally at M2? I see Papyrus traffic that
seems to be wanting this.
Since MDT/UML2 has no dependencies on MDT/OCL this
capability is not directly supported by MDT/UML2, but is
there some form of delegate already in place that MDT/OCL
should be exploiting or is something new required?
mdt-uml2.dev mailing list
mdt-uml2.dev mailing list
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4791 - Release Date: