I'm not in a position to check the code at the moment so I'll assume what you say is correct and that EUML is placing the stereotypes links in the correct place for us (although I am surprised this is not at least within the model).
That leaves me stumped for the moment on what we should be listening to. If something is added at the top level then do we have an element to be listening to to detect the addition to it? If we can find what that element is we need to be listening to then I think I can work out how to get the event pump to simulate that the event actually came from the element the stereotype is applied to. I think doing that would keep the rest of the application simpler. Bob On 9 February 2011 10:45, Thomas Neustupny <[email protected]> wrote: > 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]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703001 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]]
