Community
Participate
Working Groups
Build Identifier: The basic UML Element that a Stereotype can be applied to, is specified by one or more Properties that reference the basic Element and are called base_<NameOfTheExtendedType> by default. You can also define Stereotype associations that allow users to reference another Stereotyped Element. Consider the following design: <<Stereotype A>> <uml::Class> associates <<Stereotype B>> <uml::Operation>. If the UML Typesystem tries to handle calls to the associated stereotyped Elements features, it will fail, since the implementation does only take care of so called "dynamic values" (Implementation detail) that extend the UML Element "Class" (via looking for the "base_Class"-feature). A quick fix to the code would be the following solution: Class "org.eclipse.xtend.typesystem.uml2.profile.StereotypeType" should change the getDynamicValue(Object) as follows: private Object getDynamicValue(final Object value) { if (value instanceof EObject) { final EObject dynObject = (EObject) value; final EClass dynClass = dynObject.eClass(); EStructuralFeature baseClassFeature = null; EList<EStructuralFeature> structuralFeatures = dynClass.getEStructuralFeatures(); for (EStructuralFeature structuralFeature : structuralFeatures) { if(structuralFeature != null && structuralFeature.getName().startsWith("base_")) { baseClassFeature = structuralFeature; break; } } if(baseClassFeature != null){ return dynObject.eGet(baseClassFeature,true); } } return null; } Reproducible: Always Steps to Reproduce: 1. Create a Stereotype that extends any other Element than Class 2. Create a second Stereotype that references the first Stereotype by a Stereotype association 3. Write an Extension for the second this Stereotype that accesses one of the extended Elements features via the Stereotype assocation 4. Execute the Extension on the Stereotyped Element
I think this bug is caused elsewhere, not in the internal getDynamicValue method. Given a proper type comparison is in place, your process should receive an EList from ele.getValue holding the referenced elements. Given that none of their EClass have a "base_Class" property, the method safely returns "value" without further magic.
Sorry for the late response - I can have another look at it - this was more of a unproper workaround - given that a Stereotype can have more than one Elements it extends. When I applied the fix to the original implementation - I only got an DynamicEObjectImpl while debugging the method. No org.eclipse.uml2.uml.Element... that was another problem about it which then lead to the workaround.
Maybe you should check your problem against CVS Head / XPand 1.0.0 - there are some changes in the UmlTypeSystem in the treatment of Stereotypes. Looking forward for experience reports :)
Sadly I couldn't find any resolution to my problem in the repository. Most of the changes have been made back in 2009. @Moritz: Sorry for adding you to the CC-List without asking - saw your name in the JavaDoc-Comments of the classes mentioned above. Do you know those problems we have? Added you to the CC List of Bug 307281, too.
Hello Jochen Schmich, I tried to model stereotype associations. I modeled two Stereotypes A and B. B has a referenceto A called a. A:Property <a- B:NamedElement (see the example project attached) Inside a Define I tried to navigate this association like this: «DEFINE test FOR B» Name: «name» Ref-Name: «a.name» Ref-Typ: «a.type.name» -- Ref-Name: «base_NamedElement.name» «ENDDEFINE» This is the result: Name: b Ref-Name: a Ref-Typ: String -- Ref-Name: b So, I think the associations work. The only bug I see, is that the editor do not mark base_NamedElement as an error. Please give me feedback if I miss the point. Darius
Created attachment 176785 [details] example project
Created attachment 192572 [details] The Error messages Contents of the MWE log
Created attachment 192573 [details] The example project the example
Hi Darius, I'm verry sorry for not responding to your last comment THAT long. I had a look at your example project... I'm sorry but it is not sufficient to reproduce the bug. I also built an own example project (first time I used the Standard Eclipse UML Editor ever - but thanks to the Xpand tutorials I finally made it...). The project also contains a small profile with two and a model with some Elements that apply them. You'll also find a MWE Workflow and a Xtend script included. Running the workflow should lead to the messages in the attached logfile. I'll attach the code patch, too ASAP.
Created attachment 192575 [details] The patch Traverses every structural feature and picks the first one, that starts with "base_" - apply to workspace root
Experienced the same problem in my project after an upgrade to MagicDraw 17. The difference between the EMF export in MagicDraw 17 and previous versions is that in the old version the stereotype properties with a type also a stereotype were exported with the base class as type. MagicDraw 17 exports the correct type. The patch of Jochen works with one minor change. I replaced dynClass.getEStructuralFeatures() with dynClass.getEAllStructuralFeatures(). In my model a number of stereotypes extend other stereotypes.
Hello, Our customer uses tool to generate other formats from UML model (XML-schema’s and Excel spreadsheets at the moment, Edifact Message Implementation Guides at a later stage). This tool is based on Xtext, Xtend, and Xpand. We update EMF export of UML tool. However due to the change/improvement in the export, customer ran into a bug of Xtend which does not always map UML stereotypes correctly to its own type system. Maybe priority of this important issue could be raised? Thank you in advance, Saulius Pavalkis Customer Support Manager No Magic
Eclipse Indigo is already at RC4, this is code freeze now. So this won't make it into Indigo. I'll deal it for Indigo SR1.
Thank you very much, we appreciate this!
Yeah, thank you Karsten! @Saulius: Another issue with Stereotypes may be found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=307281
Sorry for taking ages. I could reproduce the problem with the given sample and applied the patch with the modification proposed by Peter Vermeulen.
Created attachment 200313 [details] Updated example project
Bug resolved before Xpand 1.2 release date => Closing
