[udm-dev] udm_ns release

[Endre Magyari]

Feng,


	I think is rather a modelling problem - of course MetaGme2uml could be  
smart enough to ignore such cases,
	but as I see it, in the GME model the "In Root Folder?=Yes" flag on  
BaseComponent asbtract base class has no meaning:
	- BaseComponent is an abstract base class, so it can not be instantiated  
anywhere
	- This flag does not allow for the derived model PrimitiveComponent to be  
created directly in Root Folder
	- Has no influence upon the derived model CompoundComponent also, because  
this is explicitly allowed to be created directly in Root Folder
	
	So I'd recomend changing the value of the "In Root Folder?" flag to false  
for the abstract base class "BAseComponent" in the GME model.
	This way, the MetaGme2Uml interpreter generates a single composition  
relationship, between Root Folder (as parent) and CompoundComponent(as  
child)


Endre.



On Wed, 29 Jun 2005 09:49:03 -0500, Feng Shi <fengshi at isis.vanderbilt.edu>  
wrote:

> 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