[udm-dev] udm_ns release

[Feng Shi]

Endre,

There is a gme metamodel Signalflow.mga and its corresponding uml class
diagram Signalflow_uml.mga which is generated by MetaGME2UML. When I ran
the udmcopy on SignalFlow_1.mga, it has the following error:

Ambigious role specification for folder parents

In SignalFlow.mga, both BaseComponent and CompoundComponent are set in
the rootfolder, but CompoundComponent is inherited from BaseComponent.
In the automatically generated SignalFlow_uml.mga, these two classes are
contained in RootFolder and this causes the above error because the
parent role names are blank.

I'm not sure whether this is udm error or the metagme2uml interpreter
error.

Would you please take a look at this?

Thanks,
Feng

-----Original Message-----
From: udm-dev-bounces at list.isis.vanderbilt.edu
[mailto:udm-dev-bounces at list.isis.vanderbilt.edu] On Behalf Of Endre
Magyari
Sent: Tuesday, June 28, 2005 5:28 PM
To: Udm-dev at list.isis.vanderbilt.edu
Subject: Re: [udm-dev] udm_ns release



> Endre,
>
>> > 1. Uml2XMl error message
>>
>> Please send me a sample UML model on this, with a constraint which
>> generates an error, but otherwise it's correct.
>
> Please look at the project in udm_ns/testOCL

OK, I reproduced that.
I'm trying to fix this, it doesn't seem to be as easy as it was in case
of  
UdmOcl, but I hope I'll finish it in a couple of days.


>> > 2. Generated source code backward compatibility
>>
>> I still suggest the #typedef solution, upon the existence of a
switch:
>>
>> namespace A
>> {
>> 	namespace A
>> 	{
>> 		class B;
>> 	};
>>
>> 	#typedef B A::B;
>> };
>
> Endre did you try it on the samples?

No, I did not try it - it was just brainstroming.
I'm still seeking for a solution, either with "typedef", or with "using

namespace" directives which does not imply to change the whole
generator,  
but solves the issue of backward compatibility.
(pratically,  we would have two generators, one when there is only one  
namespace in the diagram and an other when there are more)


>>
>> > 3. Test projects clean up (Attila reported it)
>>
>> Ok, I got that.
>>
>> > 4. OCL source synchronization
>>
>> What is the problem here?
>> The latest suggested change it was reported through Anantha to Molnar
>
> OK. Linux version needs some changes. Are those reported, too?

I'll look at it, my schedule is to solve the OCL issue first.


Endre.
_______________________________________________
udm-dev mailing list
udm-dev at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/mailman/listinfo/udm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SignalFlow_meta.xme
Type: application/octet-stream
Size: 53437 bytes
Desc: SignalFlow_meta.xme
Url : http://list.isis.vanderbilt.edu/pipermail/udm-dev/attachments/20050629/c2173418/SignalFlow_meta-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SignalFlow_uml_meta.xme
Type: application/octet-stream
Size: 22064 bytes
Desc: SignalFlow_uml_meta.xme
Url : http://list.isis.vanderbilt.edu/pipermail/udm-dev/attachments/20050629/c2173418/SignalFlow_uml_meta-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SignalFlow_1.xme
Type: application/octet-stream
Size: 13639 bytes
Desc: SignalFlow_1.xme
Url : http://list.isis.vanderbilt.edu/pipermail/udm-dev/attachments/20050629/c2173418/SignalFlow_1-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Uml.xsd
Type: application/octet-stream
Size: 9600 bytes
Desc: Uml.xsd
Url : http://list.isis.vanderbilt.edu/pipermail/udm-dev/attachments/20050629/c2173418/Uml-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Uml.xsd
Type: application/octet-stream
Size: 9600 bytes
Desc: Uml.xsd
Url : http://list.isis.vanderbilt.edu/pipermail/udm-dev/attachments/20050629/c2173418/Uml-0003.obj