Community
Participate
Working Groups
Version of OCL OCL for the UML Metamodel Version: 4.0.0.v20120611-1210 When I write this query on a class : self.getAppliedStereotypes() Results: Evaluation failure No implementation for 'UML::uml::Element.getAppliedStereotypes()'
I've just pushed my bug/365447 branch that adds support for stereotypes so that the functionalirty of getAppliedStereotypes() should be available as oclType().appliedStereotype. Just needs the wrapping operation to give it the API name. There are 299 Operations in the Eclipse UML 4.0 metamodel; probably none of them have operation bodies. Rather than write all 299 again, the plan is to auto-generate them from the UML 2.4.1/2.5 specification so that they are consistent and evolve to being correct. Si milar auto-generation will support the MDT/UML2 code. I can do perhaps 10 operations now, if you really need them, but 299 by hand is no fun. I hope to have auto-generation in perhaps a month. (About 20 validation rules in OCL 4.0 are already auto-generated.).
(In reply to comment #1) > I can do perhaps 10 operations now, if you really need them, but 299 by hand is > no fun. I hope to have auto-generation in perhaps a month. (About 20 validation > rules in OCL 4.0 are already auto-generated.). Not so bad: 299 Operations, but only 81 Queries and many are quite trivial but all have to be reverse-engineered from the MDT/UML2 Java.
This proves to be rather easy; just introduce an EInvokeOperation to support an EObject domain invocation of eInvoke. Pushed to master.
Supporting e.g. getAppliedStereotypes() for parsing at M2 (e.g. in a Profile) and execution at M1 (e.g. when validating a diagram) is relatively straightforward; the user model extends the MDT/UML2 metamodel in which Element::getAppliedStereotypes() is available. With extension_xxx and base_xxx available the extended MDT/UML2 methods may be less useful since they lose type information. Supporting e.g. getAppliedStereotypes() for parsing at M1 (e.g. in a user Class invariant) and execution at M0 (e.g. when the user objects exist) is troublesome. User objects do not normally extend Element, so the operation is not visible. If a static OclElement::getAppliedStereotypes() existed/was synthesized then all user types would have all the MDT/UML2 API added; can't be right. Therefore an M1 activation should be e.g. self.oclType().getAppliedStereotypes() to explicitly climb to the meta-level. This is now parseable, but is it executable? When using EMF, all UML instances are EObject and so they have EClasses but no UML Classes and so no Element objects on which to invoke getAppliedStereotypes(). Options: - create the UML by Ecore2UML conversion -- but stereotypes won't exist - create the UML by finding and loading the original UML resource -- but it may not be findable - create the Pivot from the EClass -- but stereotypes won't exist and all UML ops need implementing for Pivot It seems execution from M0 is only practical if the UML2Ecore converter copies a stereotype description into the EAnnotations. Since access from M0 requires enhanced MDT/UML2 modeling this is an enhancement. Bug 400850 raised. This bug is solely concerned with access from M1.
Working for M5, additional tests clarifying M1/M0 behaviour added for M6.
CLOSED after more than a year in RESOLVED state.
and CLOSE
