[udm-dev] decoupling GME paradigm names from generated C++
namespaceidentifiers
Zsolt Kalmar
kalmar at isis.vanderbilt.edu
Fri Nov 4 11:22:15 CST 2005
Guys,
I hope this change won't break the existing code. Biocomp PI meeting is
next week, and we are about to put out our stuff on the web and it
relies on current udm_ns2 version.
Thanks,
zsolt
> -----Original Message-----
> From: udm-dev-bounces at list.isis.vanderbilt.edu
> [mailto:udm-dev-bounces at list.isis.vanderbilt.edu] On Behalf
> Of Attila Vizhanyo
> Sent: Friday, November 04, 2005 10:42 AM
> To: Endre Magyari; Matthew J. Emerson
> Cc: udm-dev at list.isis.vanderbilt.edu
> Subject: [udm-dev] decoupling GME paradigm names from
> generated C++ namespaceidentifiers
>
>
> Endre,
>
> Everything you described below is correct. GReAT will manage
> the CreateNew call. I am forwarding this summary to the
> udm-dev list so that others know.
>
> Thanks,
> Attila
>
>
> -----Original Message-----
> From: Endre Magyari
> Sent: Friday, November 04, 2005 10:24 AM
> To: Matthew J. Emerson; Attila Vizhanyo
> Subject: Re: metamodel naming conventions and GReAT
>
>
> Ok, let's summarize, I understood the following:
>
> 1. We are decoupling between the UML package name and UML
> diagram name, by
> adding an extra string attribute in (GME) UML paradigm to UML
> package. 2. We also change the UML2XML interpreter: If there
> is present such an
> attribute, in the generated XML the Diagram's name will be that
> attribute's value
> 3. We don't change the code generator or anything below.
>
> For instance:
> 1. The paradigm name will be LampDiagramXXX.
> 2. In the GME UML model, the name of the UML package will be
> LampDiagramXXX, with an alias to "LampDiagram"
> 3. After processing with UML2XML, the name of the
> Uml::Diagram will be
> "LampDiagram"
> 4. After processing with Udm.exe, the name of the C++
> namespace will be
>
> "LampDiagram".
>
>
> <HUGE NOTE>
> When creating a MGA datanetwork with UDM in such an
> enviroment, one will
>
> have to call CreateNewDatanetwork differently:
>
> instead of:
> nw.CreateNew(argv[1],"LampDiagram", RootFolder::meta);
>
> will be:
> nw.CreateNew(argv[1],"LampDiagramXXX", RootFolder::meta);
>
> And you won't be able to figure out runtime if LampDiagram
> was an alias or
> not, and if it was, what is the real name.
> But If I recall correctly GReAT will generate the code cointaining
> CreateNew() calls, maybe the generation process can be aware of this
> aliasing ?
> </HUGE NOTE>
>
>
> Thanks,
> Endre
>
>
> On Fri, 4 Nov 2005 09:44:10 -0600, Matthew J. Emerson
> <mjemerson at isis.vanderbilt.edu> wrote:
>
> > You're right, that does sound a bit ugly. I vote for the alias
> attribute
> > method.
> >
> > --Matt
> >
> >> -----Original Message-----
> >> From: Attila Vizhanyo
> >> Sent: Friday, November 04, 2005 9:42 AM
> >> To: Matthew J. Emerson; Endre Magyari
> >> Subject: RE: metamodel naming conventions and GReAT
> >>
> >> These solutions are fine as well. The two drawbacks are:
> >> - Just taking a look at a UML package name, you will have no idea
> > which
> >> GME paradigm is the package compatible with. You must
> carefully look
> >> through the content of the class diagrams contained in the package.
> >> - No support of name decoupling for UML models. The MetaGme2Uml
> >> interpreter will provide no support for changing the UML package
> name.
> > The
> >> user can later manually change the UML package name, but
> again, the
> >> traceability will be lost between the GME paradigm name and UML
> > package
> >> name.
> >>
> >> If these are no concerns for you, then I don't mind to change
> > MetaGme2UMT
> >> interpreter, and leave UML2XML and UML/UMT models intact.
> >>
> >> --Attila
> >>
> >> -----Original Message-----
> >> From: Matthew J. Emerson
> >> Sent: Friday, November 04, 2005 9:10 AM
> >> To: Attila Vizhanyo; Endre Magyari
> >> Subject: RE: metamodel naming conventions and GReAT
> >>
> >> I think this is pretty user friendly and not ambiguous.
> >>
> >> I guess all you really need in UMT is a way to build an
> association
> >> between a top-level UML package (corresponding to one of the
> > metamodels)
> >> and a UMT FileType object, since the FileType object captures the
> name
> > of
> >> the metamodel registered with GME. So, you could
> accomplish this same
> > task
> >> in a few other ways, like making FileObjects into
> references to UML
> >> Packages, or building explicit connections between UML Package
> > references
> >> and FileTypes in the Configuration model.
> >>
> >> Implement the one that most appeals to you. ;)
> >>
> >> --Matt
> >>
> >> > -----Original Message-----
> >> > From: Attila Vizhanyo
> >> > Sent: Friday, November 04, 2005 9:02 AM
> >> > To: Endre Magyari
> >> > Cc: Matthew J. Emerson
> >> > Subject: RE: metamodel naming conventions and GReAT
> >> >
> >> > I'd agree, but as I wrote in my previous email:
> >> >
> >> > "...we need the GME paradigm name in UMT models,
> >> > so that the GReAT tools can perform the mapping automatically."
> >> >
> >> > If the GME paradigm name is missing from a UMT (equivalent to GME
> > UML)
> >> > model, then GReAT cannot perform the mapping between
> configuration
> > data
> >> > LampDiagramXXX (which refers to the GME paradigm to which
> > input/output
> >> > models can conform to) and LampDiagram UML package name, which
> >> corresponds
> >> > to the domain name in the generated code.
> >> >
> >> > The alias attribute would be empty by default. If the
> user whishes
> > to
> >> > refer to a domain with a different name then the UML
> package name,
> > he
> >> can
> >> > supply an alias name, in which case the UML2XML interpreter would
> > use
> >> the
> >> > alias for generating Udm xml files, and C++ namespace
> identifiers.
> > This
> >> > means a minor modification in the UML2XML tool and in
> the GME UML /
> > UMT
> >> > paradigms.
> >> >
> >> > Thanks,
> >> > Attila
> >> >
> >> > -----Original Message-----
> >> > From: Endre Magyari
> >> > Sent: Thursday, November 03, 2005 11:33 PM
> >> > To: Attila Vizhanyo
> >> > Cc: Matthew J. Emerson
> >> > Subject: Re: metamodel naming conventions and GReAT
> >> >
> >> >
> >> > I'd consider decoupling between the GME root object's
> name and the
> > UML
> >> > package's name, which means: MetaGME2UML.
> >> >
> >> > I think changing MetaGme2UML would be simpler; Anyway we
> are using
> >> > MetaGME2UML from command line or .vbs, right ? So adding
> one more
> >> > optional argument is not a big deal. If that extra
> argument exist,
> >> > instead propagating from the name of
> > the
> >> > root object in the MetaGME model, we will use that extra
> argument's
> >> value
> >> > for the UML package name.
> >> >
> >> > And then Great should be modified to use MetaGME2UML with this
> extra
> >> > parameter;
> >> >
> >> >
> >> > What do you think?
> >> >
> >> > Endre
> >> >
> >> >
> >> > On Thu, 03 Nov 2005 15:40:21 -0600, Attila Vizhanyo
> >> > <viza at isis.vanderbilt.edu> wrote:
> >> >
> >> > > Here is how names are propagated in GReAT:
> >> > > Users typically start off with a GME paradigm (MetaGME model)
> >> > >
> >> > > Name of the root object in the MetaGme model (which is of type
> >> > > RootFolder) ->
> >> > > UML package name in a GME UML or UMT model (translated by
> >> > > MetaGme2UMX) ->
> >> > > UML class diagram name in a UDM UML model (translated by
> >> Uml2Xml)
> >> > > ->
> >> > > C++ namespace identifier (generated by Udm.exe)
> >> > >
> >> > > I would decouple the names at level 2, i.e. at GME UML/ UMT
> model.
> >> > > This means that we'd need to maintain a mapping between GME
> > paradigm
> >> > > name and UDM UML class diagram names in these models.
> The reason
> >> > > for this is that we need the GME paradigm name in UMT
> >> models,
> >> > > so that the GReAT tools can perform the mapping
> automatically. A
> >> > > possible solution is to introduce a new attribute, called
> > 'alias'
> >> for
> >> > > UML package models, which indicates the namespace
> identifier the
> > user
> >> > > wants to use in his UDM user code.
> >> > >
> >> > > If we can agree upon this, we can add this
> functionality into the
> >> GReAT
> >> > > tools. The UML and UMT languages and the Uml2Xml
> interpreter are
> > also
> >> > > needed to be changed.
> >> > >
> >> > > What do you think?
> >> > >
> >> > > Thanks,
> >> > > Attila
> >> > >
> >> > > Endre Magyari wrote:
> >> > >
> >> > >>
> >> > >> Matt,
> >> > >>
> >> > >>> metamodels have those same names. So, it's not
> possible for me
> > to
> >> make
> >> > >>> a
> >> > >>> transformation where the name of the UML metamodel
> differs from
> > the
> >> > >>> name
> >> > >>> of the registered paradigm.
> >> > >>>
> >> > >>> Maybe this is an issue that could be addressed on the GReAT
> side
> >> > >>
> >> > >>
> >> > >> Probably; As I said, as far as the UDM's GME backend is
> > concerned,
> >> > >> there is no such requirement, the UML diagram name can differ
> > from
> >> the
> >> > >> GME paradigm name, which means that the C++ namespace name in
> > the
> >> > >> generated code can differ from the GME paradigm name.
> >> > >>
> >> > >>
> >> > >>
> >> > >> Thanks,
> >> > >> Endre
> >> > >>
> >> > >>
> >> > >>>
> >> > >>>> -----Original Message-----
> >> > >>>> From: Endre Magyari
> >> > >>>> Sent: Thursday, November 03, 2005 1:24 PM
> >> > >>>> To: Matthew J. Emerson; Attila Vizhanyo
> >> > >>>> Subject: Re: metamodel naming conventions and GReAT
> >> > >>>>
> >> > >>>>
> >> > >>>> Matt,
> >> > >>>>
> >> > >>>>
> >> > >>>> After studying this issue a little bit I discovered that
> > the
> >> > >>>
> >> > >>> name of
> >> > >>>
> >> > >>>> GME
> >> > >>>> paradigm is not coupled with the name of Uml diagram (or
> > contained
> >> > >>>> namespaces), at least not in UDM.
> >> > >>>> For instance:
> >> > >>>> 1. I rename the LampDiagram paradigm to LampDiagramXXX
> >> > >>>> 2. I unregister the paradigm 'LampDiagram'
> >> > >>>> 3. I register the paradigm 'LampDiagramXXX'
> >> > >>>> 4. In the CreateLampModel example I only change in the
> >> CreateNew
> >> > >>>> calls
> >> > >>>> the 2nd argument(metalocator) from LampDiagram to
> > LampDiagramXXX
> >> > >>>> 5. UML paradigm remains the same(so the Uml
> diagram's name
> > is
> >> > >>>
> >> > >>> still
> >> > >>>
> >> > >>>> LampDiagram, thus the C++ namespace is stilll LampDiagram)
> >> > >>>> 6. After these steps the CreateLampModel example is
> > working,
> >> > >>>
> >> > >>> which
> >> > >>>
> >> > >>>> means
> >> > >>>> that I could create an MGA file based on GME paradigm
> >> > "LampDiagramXXX"
> >> > >>>> using a UML diagram named "LampDiagram". So I guess
> these two
> > need
> >> > not
> >> > >>>
> >> > >>> to
> >> > >>>
> >> > >>>> be the same.
> >> > >>>>
> >> > >>>> The only coupling may come from the MetaGME2UML
> interpreter,
> > this
> >> > >>>
> >> > >>> creates
> >> > >>>
> >> > >>>> a corresponding UML diagram for a GME paradigm,
> such that the
> > UML
> >> > >>>
> >> > >>> diagram
> >> > >>>
> >> > >>>> will have the same name as the GME paradigm. If code is
> > generated
> >> > >>>
> >> > >>> after
> >> > >>>
> >> > >>>> this newly created UML paradigm, then the namespace
> name will
> > also
> >> be
> >> > >>>> affected.
> >> > >>>>
> >> > >>>> I don't know if Great is using MetaGME2UML; If it
> is we should
> > see
> >> > how
> >> > >>>
> >> > >>> can
> >> > >>>
> >> > >>>> be avoided the regeneration of the Uml diagram/code in such
> > cases.
> >> > >>>>
> >> > >>>> Thanks,
> >> > >>>> Endre
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> On Tue, 25 Oct 2005 08:27:15 -0500, Matthew J. Emerson
> >> > >>>> <mjemerson at isis.vanderbilt.edu> wrote:
> >> > >>>>
> >> > >>>> >
> >> > >>>> > I would find that to be a very useful feature, Endre.
> >> > >>>> >
> >> > >>>> > --Matt
> >> > >>>> >
> >> > >>>> > -----Original Message-----
> >> > >>>> > From: Endre Magyari
> >> > >>>> > Sent: Tue 10/25/2005 2:28 AM
> >> > >>>> > To: Attila Vizhanyo; Matthew J. Emerson
> >> > >>>> > Cc:
> >> > >>>> > Subject: Re: metamodel naming conventions and GReAT
> >> > >>>> >
> >> > >>>> > Attila,
> >> > >>>> >
> >> > >>>> > This is not possible at this time.
> >> > >>>> > But we can make it possible by a mechanism in GME backend
> > which
> >> > will
> >> > >>>
> >> > >>> map
> >> > >>>
> >> > >>>> > UML diagram names to GME paradigm names.
> >> > >>>> > The user will have to map the diagram 'C4ISR' to GME
> paradigm
> >> > >>>> > 'C4ISR_5_MM_DD' before accessing a GME
> datanetwork. Should I
> >> > >>>> > add this feature?
> >> > >>>> >
> >> > >>>> > Thanks,
> >> > >>>> > Endre
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> > On Mon, 24 Oct 2005 19:07:59 -0500, Attila Vizhanyo
> >> > >>>> > <viza at isis.vanderbilt.edu> wrote:
> >> > >>>> >
> >> > >>>> >> Matt,
> >> > >>>> >>
> >> > >>>> >> I dont have a clue if the udm code generator
> supports this
> >> > feature.
> >> > >>>
> >> > >>> If
> >> > >>>
> >> > >>>> >> yes, we can expose the corresponding interface
> in the GReAT
> >> tools.
> >> > >>>
> >> > >>> I'm
> >> > >>>
> >> > >>>> >> forwarding your question to Endre.
> >> > >>>> >>
> >> > >>>> >> Endre,
> >> > >>>> >>
> >> > >>>> >> Is there a way in Udm to decouple the name of a GME
> paradigm
> >> from
> >> > >>>
> >> > >>> the
> >> > >>>
> >> > >>>> >> generated C++ namespace identifier?
> >> > >>>> >> E.g. MetaGMEModel.mga -> MetaGMEModel.h: ... namespace
> > MyNSID
> >> > {...}
> >> > >>>> >> If yes, does it work correctly for UML models
> with multiple
> >> > >>>
> >> > >>> packages
> >> > >>>
> >> > >>>> >> (i.e. those with cross-links)?
> >> > >>>> >>
> >> > >>>> >> Thanks,
> >> > >>>> >> Attila
> >> > >>>> >>
> >> > >>>> >>
> >> > >>>> >> Matthew J. Emerson wrote:
> >> > >>>> >>
> >> > >>>> >>> Now, unfortunately, I've run into a different
> difficulty.
> > When
> >> I
> >> > >>>> >>> changed the name of my metamodel in GReAT to
> correspond to
> > the
> >> > >>>
> >> > >>> name of
> >> > >>>
> >> > >>>> >>> the metamodel I have registered with GME, the
> namespace of
> > my
> >> > >>>> generated
> >> > >>>> >>> DS-API changed names. So, now all of my external code
> > libraries
> >> > >>>
> >> > >>> that I
> >> > >>>
> >> > >>>> >>> link in to my transformation are broken.
> >> > >>>> >>>
> >> > >>>> >>> I don't want to have to edit all this code to adjust the
> >> > namespace
> >> > >>>> >>> qualifications every time I increment the version of my
> >> > >>>
> >> > >>> metamodel...is
> >> > >>>
> >> > >>>> >>> there someway for me to have my cake and eat it
> too here?
> >> > >>>> >>>
> >> > >>>> >>> I'd like to have my metamodel registered with GME as
> >> > >>>
> >> > >>> C4ISR_5_MM_DD.
> >> > >>>
> >> > >>>> I'd
> >> > >>>> >>> also like for the generated DS-API namespace name to
> remain
> >> C4ISR
> >> > >>>> >>> regardless of the version number. Finally, I
> need GReAT to
> > be
> >> > able
> >> > >>>
> >> > >>> to
> >> > >>>
> >> > >>>> >>> read the input models. Is there some way of
> divorcing the
> > name
> >> > >>>
> >> > >>> GReAT
> >> > >>>
> >> > >>>> >>> uses when looking up the paradigm in GME and the name it
> > uses
> >> > >>>> >>> internally for a metamodel?
> >> > >>>> >>>
> >> > >>>> >>> --Matt
> >> > >>>> >>>
> >> > >>>> >>>
> >> > >>>
> >> > >>>
> > --------------------------------------------------------------------
> >> --
> >> > >>>
> >> > >>>> -- >>>
> >> > >>>> >>> *From:* Matthew J. Emerson
> >> > >>>> >>> *Sent:* Monday, October 24, 2005 3:10 PM
> >> > >>>> >>> *To:* Attila Vizhanyo
> >> > >>>> >>> *Subject:* RE: metamodel naming conventions and GReAT
> >> > >>>> >>>
> >> > >>>> >>> Excellent, I have figured it out. You must also
> make sure
> > that
> >> > the
> >> > >>>
> >> > >>> UMT
> >> > >>>
> >> > >>>> >>> project includes a package with the same name as each of
> > the
> >> > >>>> metamodels
> >> > >>>> >>> referenced in the configuration model. After making that
> > change
> >> I
> >> > >>>
> >> > >>> no
> >> > >>>
> >> > >>>> >>> longer observe the error.
> >> > >>>> >>>
> >> > >>>> >>> Thanks,
> >> > >>>> >>>
> >> > >>>> >>> Matt
> >> > >>>> >>>
> >> > >>>> >>>
> >> > >>>
> >> > >>>
> > --------------------------------------------------------------------
> >> --
> >> > >>>
> >> > >>>> -- >>>
> >> > >>>> >>> *From:* Matthew J. Emerson
> >> > >>>> >>> *Sent:* Monday, October 24, 2005 2:57 PM
> >> > >>>> >>> *To:* Attila Vizhanyo
> >> > >>>> >>> *Subject:* metamodel naming conventions and GReAT
> >> > >>>> >>>
> >> > >>>> >>> Hi Attila,
> >> > >>>> >>>
> >> > >>>> >>> To enable people to have multiple versions of our
> metamodel
> >> > >>>
> >> > >>> registered
> >> > >>>
> >> > >>>> >>> with GME concurrently, we've starting appending
> a version
> >> number
> >> > >>>
> >> > >>> to
> >> > >>>
> >> > >>>> the
> >> > >>>> >>> paradigm name. So now, instead of C4ISR (the name of our
> >> > paradigm)
> >> > >>>> >>> showing up in the list of registered paradigms, we have
> >> > >>>
> >> > >>> C4ISR_5.10.24
> >> > >>>
> >> > >>>> >>> (and possibly other versions as well). Of
> course, a GReAT
> >> > >>>> >>> transformation has to know what paradigm(s) the
> input and
> >> output
> >> > >>>> models
> >> > >>>> >>> conform to, so if a user wants to change language
> versions,
> >> they
> >> > >>>
> >> > >>> have
> >> > >>>
> >> > >>>> >>> to alter the configuration model of our GReAT
> > transformation
> >> that
> >> > >>>> works
> >> > >>>> >>> on C4ISR models.
> >> > >>>> >>>
> >> > >>>> >>> I thought it would be sufficient if I simply updated the
> >> > >>>
> >> > >>> configuration
> >> > >>>
> >> > >>>> >>> model:
> >> > >>>> >>>
> >> > >>>> >>> Unfortunately, since we adopted this naming convention
> I've
> >> been
> >> > >>>> having
> >> > >>>> >>> trouble getting the GRE to read C4ISR models.
> Here's what
> > it
> >> > looks
> >> > >>>> like
> >> > >>>> >>> just before I start the GRE:
> >> > >>>> >>>
> >> > >>>> >>> You can see that the transformation expects the input
> model
> > to
> >> be
> >> > >>>> valid
> >> > >>>> >>> under version 5.10.24 of our C4ISR language. When I hit
> > okay, I
> >> > >>>> >>> immediately get the error,
> >> > >>>> >>>
> >> > >>>> >>> The most obvious thing would be that the input file,
> >> TestIn3.mga,
> >> > >>>
> >> > >>> is
> >> > >>>
> >> > >>>> >>> for a different version of the paradigm than 5.10.24.
> > However,
> >> I
> >> > >>>
> >> > >>> made
> >> > >>>
> >> > >>>> >>> sure that this is not the case - TestIn3.mga was built
> from
> >> > >>>
> >> > >>> scratch
> >> > >>>
> >> > >>>> >>> using C4ISR_5.10.24. I also verified that
> C4ISR_5.10.24 is
> >> > >>>
> >> > >>> registered
> >> > >>>
> >> > >>>> >>> with GME. I deleted the generated Configuration.mga file
> > before
> >> I
> >> > >>>> >>> invoked the master interpreter so that no
> reference to the
> > old
> >> > >>>> >>> metamodel name would hang around.
> >> > >>>> >>>
> >> > >>>> >>> So, do you know what might be causing this error? Does
> > GReAT
> >> not
> >> > >>>
> >> > >>> like
> >> > >>>
> >> > >>>> >>> something about the format of the paradigm name? Are
> >> > >>>
> >> > >>> non-alphanumeric
> >> > >>>
> >> > >>>> >>> paradigm names illegal? What exactly needs to
> happen if a
> > user
> >> > >>>
> >> > >>> needs
> >> > >>>
> >> > >>>> to
> >> > >>>> >>> change only the name of one of the metamodels
> involved in
> > their
> >> > >>>> >>> transformation?
> >> > >>>> >>>
> >> > >>>> >>> Thanks,
> >> > >>>> >>>
> >> > >>>> >>> Matt
> >> > >>>> >>>
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>> >
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >>
> >> >
> >
> >
>
>
> _______________________________________________
> udm-dev mailing list
> udm-dev at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/lis> tinfo/udm-dev
>
More information about the udm-dev
mailing list