Re: [argouml-dev] UML2: How to feed the model event pump for tagged values?

Thomas Neustupny <[email protected]>
Newsgroups gmane.comp.db.axion.devel
Message-ID <[email protected]>
Hi,

I answered in issue 6185, let's discuss there and probably later continue here on the more general topic.

Thomas

-------- Original-Nachricht --------
> Datum: Fri, 11 Feb 2011 00:07:53 +0000
> Von: Bob Tarling <[email protected]>
> An: [email protected]
> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for tagged values?

> Okay, patch is added to 6185, take a look at the technique - aybe this
> will work also for tagged values
> 
> Bob
> 
> On 10 February 2011 20:00, Bob Tarling <[email protected]> wrote:
> > I have a patch that gets stereotypes working with the method I suggested
> >
> > Its on another machine at the moment and the pub is my top priority
> right now
> >
> > I'll attach it to issue 6185 when I get back tonight or some tomorrow
> > at the latest.
> >
> > Cheers
> >
> > Bob
> >
> > On 10 February 2011 08:44, Thomas Neustupny <[email protected]> wrote:
> >> Hi Bob,
> >>
> >> how exactly would addAllStereotypes look like when using the event pump
> the way you suggested? I'd like to give it a try (make the whole UML2
> stereotype work based on that).
> >>
> >> Thomas
> >>
> >> -------- Original-Nachricht --------
> >>> Datum: Wed, 9 Feb 2011 21:55:34 +0000
> >>> Von: Bob Tarling <[email protected]>
> >>> An: [email protected]
> >>> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for
> tagged values?
> >>
> >>> 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]]
> >>
> >> --
> >> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> >> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> >>
> >> ------------------------------------------------------
> >>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703195
> >>
> >> 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=2703356
> 
> 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=2703419

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]]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.