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

Attila Vizhanyo viza at isis.vanderbilt.edu
Fri Nov 4 10:42:14 CST 2005 

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