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]]

Reply via email to