Hi Thomas
I'm not sure if I follow all the purpose of getRootElements but then
again I'm not if need to right now.
What I have confirmed is what you have said (that standard euml is
used to link the model element with a stereotype) - i.e. this line in
CoreHelperEUMLImpl.addAllStereotypes is clearly out of our control for
how it attaches and so we can assume the stereotype is correctly
placed in the repository
((Element) modelElement).applyStereotype((Stereotype) o);
What you might consider if we find no better way to solve this is to
generate some event of our own.
We could have addAllStereotypes call the event pump instructing it to
fire an event with a "stereotype" property after we have either
applied a stereotype.
So this event would look the same as what currently happens in MDR and
so all our existing code that looks for stereotype events should work.
Regards
Bob
On 9 February 2011 16:25, Thomas Neustupny <[email protected]> wrote:
> Hi Bob,
>
> it took me so much time to get the persistence of stereotype applications
> running. Currently this is handled by managing the root elements of the
> project instance. It is done by calling the (new) method updateRoots() in
> ProjectImpl, which uses Model.getModelManagementHelper().getRootElements(m),
> which in turn calls ((EObject) model).eResource().getContents() on all
> models. So it's an EMF functionality, not UML2. (All this is not called via
> some event handling IIRC, but I'm not sure.)
>
> So, this is how the stereotype-related "model-outside" elements are handled.
> Beat me if you think that's sick, but I found no other way to get it reliable
> loaded/saved with eUML.
>
> So, the element we should listen to probably is not a UML2 element, but an
> eCore element (the eResource, which is an EObject)?
>
> Thomas
>
> -------- Original-Nachricht --------
>> Datum: Wed, 9 Feb 2011 12:20:40 +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'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]]
>
> --
> Schon gehört? GMX hat einen genialen Phishing-Filter in die
> Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
>
> ------------------------------------------------------
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703042
>
> 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=2703111
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]]
