Hi Bob, thanks for looking at this. (Also thanks for the other replies from you and Tom, I just had no time to continue with my work on that.)
We let eclipse UML2 do the work when applying a stereotype, see addAllStereotypes(...) in CoreHelperEUMLImpl. I've recently wrote an article about what happens in the dev wiki, see http://argouml.tigris.org/wiki/UML2%2C_Profiles_and_XMI where I used XMLDump a lot. I'd say that option a) is not the case, so I tend towards b). As you can see, the class itself is not altered when applying a stereotype. To check for applied stereotypes, we also use a eclipse UML2 method. Does that give you any idea from how to create and listen the events properly for applying/unapplying stereotypes? Thomas -------- Original-Nachricht -------- > Datum: Wed, 9 Feb 2011 03:25:09 +0000 > Von: Bob Tarling <[email protected]> > An: [email protected] > Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for tagged > values? > I've been looking at a similar issue for stereotypes and I think the > clue comes from looking at the View->XMLDump results having added > stereotypes to a class. > > Here I created a class Test and added all the possible stereotypes. > The XMI portion of the dump is below. > > Notice that the tags that represent the stereotype attachments to the > class are outside the </uml:Model> end tag. > > I suspect either > a) We are creating the sterotypes (and tagged values??) in the wrong place > or > b) There is no way to listen for stereotypes being added to an > element. Instead we need to listen for them being added to the > repository and when detected determine what element they should be > attached to. > > <xmi:XMI xmi:version="2.1" > xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xmlns:UML22StandardElements="http:///schemas/UML22StandardElements/_EshpMAjiEeC74rHqA76v5A/0" > xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" > xmlns:uml="http://schema.omg.org/spec/UML/2.2" > xsi:schemaLocation="http:///schemas/UML22StandardElements/_EshpMAjiEeC74rHqA76v5A/0 > http://argouml.org/profiles/uml22/default-uml22.xmi#_Es-VIAjiEeC74rHqA76v5A > http://schema.omg.org/spec/UML/2.2 > http://www.eclipse.org/uml2/3.0.0/UML"> > <uml:Model xmi:id="_SUdPoDPxEeCIdeSzV50Lfg" name="untitledModel"> > <packagedElement xmi:type="uml:Class" > xmi:id="_SxMO8DPxEeCIdeSzV50Lfg" name="Test"/> > <profileApplication xmi:type="uml:ProfileApplication" > xmi:id="_SUnAoDPxEeCIdeSzV50Lfg" > applyingPackage="_SUdPoDPxEeCIdeSzV50Lfg"> > <xmi:Extension extender="http://www.eclipse.org/emf/2002/Ecore"> > <eAnnotations xmi:type="ecore:EAnnotation" > xmi:id="_SUnAoTPxEeCIdeSzV50Lfg" > source="http://www.eclipse.org/uml2/2.0.0/UML"> > <references xmi:type="ecore:EPackage" > href="http://argouml.org/profiles/uml22/default-uml22.xmi#_Es-VIAjiEeC74rHqA76v5A"/> > </eAnnotations> > </xmi:Extension> > <appliedProfile xmi:type="uml:Profile" > href="http://argouml.org/profiles/uml22/default-uml22.xmi#_PB5O8MoqEd6otN4YcPG1_w"/> > </profileApplication> > </uml:Model> > <UML22StandardElements:focus xmi:id="_XG6ckDPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:implementationClass > xmi:id="_Y614UDPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:auxiliary xmi:id="_az0MIDPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:metaclass xmi:id="_bkeNADPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:realization xmi:id="_cbhw0DPyEeCIdeSzV50Lfg" > base_Classifier="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:specification > xmi:id="_c_QI8DPyEeCIdeSzV50Lfg" > base_Classifier="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:type xmi:id="_dlC9oDPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > <UML22StandardElements:utility xmi:id="_eFpwUDPyEeCIdeSzV50Lfg" > base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> > </xmi:XMI> > > Bob > > On 31 January 2011 17:41, Bob Tarling <[email protected]> wrote: > > I had hoped that the tagged values tab would move into a control on > > the properties panel. > > > > The properties panel is driven by a configuration XML file for the > > model subsystem where the property names are specified in that file. > > So there is no need to map the UML2 property names to UML1.x > > > > Bob > > > > On 31 January 2011 11:31, Tom Morris <[email protected]> wrote: > >> On Mon, Jan 31, 2011 at 5:00 AM, Thomas Neustupny <[email protected]> wrote: > >> > >>> my work on tagged values for UML2 (using stereotype properties) is > stalling because I'm just not keen enough to work with the model event pump. > At least this is what I'm guessing, because while with MDR events are fired > when choosing a tag definition in the tagged values pane, nothing happens > when doing the same with eUML. > >>> > >>> Can someone explain to me what I should do? I've read > >>> http://argouml.tigris.org/wiki/%3C%3CSubsystem%3E%3E_Model, but still > have no solution. > >> > >> A lot of this stuff at the top of that page is of historical interest > >> only or no interest at all. The main thing to understand is that both > >> the event listener registration and listener processing itself needs > >> to be correct and the name of the events/properties, as well as their > >> source, is tied to the UML metamodel. If you're listening to a UML > >> 1.4 source for a UML 1.4 property name and this has changed in UML > >> 2.x, your listener code will never get invoked. > >> > >> When I was working on the UML 1.3 to UML 1.4 conversion the event > >> processing is where a large portion of the time went, so I wouldn't be > >> surprised if the same were true when moving to UML 2.x. > >> > >> If you look at the current event pump implementation, you'll see that > >> each event basically gets replicated. This is because relationships > >> are asymmetric in MDR and it only fires an event for what it considers > >> to be the "owning" end of the relationship, with the associated > >> property name. The old NSUML event registration code basically > >> expected to be able to register for either end, so the event pump > >> looks up the inverse property and fires events for that too. I think > >> either Bogdan or I replicated all this machinery for the eUML > >> implementation already, so this is primarily background information > >> rather than something you should need to actively worry about. > >> > >> As I recall there's also some simple property name mapping which will > >> map from UML 2.x property names back to UML 1.4 equivalent names, but > >> this is likely to only be effective in the simplest of cases. If > >> you're listening to the wrong object, it won't matter what the > >> property names are. > >> > >> If you've got a specific question I'd be happy to answer it, but there > >> is not going to be any magic bullet here. It's just going to require > >> going through and conditionalizing things that have changed between > >> the two metamodels (or providing mappings within the event pump, where > >> that's possible). > >> > >> Tom > >> > >> ------------------------------------------------------ > >> > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2701698 > >> > >> To unsubscribe from this discussion, e-mail: > [[email protected]]. > >> To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] > >> > > > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2702922 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, > email: [[email protected]] -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2702984 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
