[udm-dev] Re: decoupling GME paradigm names from generated C++ namespace identifiers

Endre Magyari endre at isis.vanderbilt.edu
Sat Nov 5 12:52:34 CST 2005


Done, checked in: UmlMeta.xme, Component.cpp, Component.h

Endre
On Fri, 4 Nov 2005 10:42:14 -0600, Attila Vizhanyo  
<viza at isis.vanderbilt.edu> wrote:

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




More information about the udm-dev mailing list