Re: duplicated parameters in "create" methods

Hi,
I am not sure, but this seems like a bug in the spec. My understanding 
is that the name attribute should be redefined in the class that 
interits from both NamedElements. Anyway, even if that is the case, you 
will still need to have a more complex logic to decide which attributes 
to ignore. You may even need to create some artifical classes in order 
to make the resulting model equivalent.
Martin

Bin Fu wrote:

> Hi, Martin,
> 
> it is same as you described, there are attributes with same name declared in
> the several superclasses e.g. attribute “nameâ€. And I think it is the reason
> for duplicated parameters. Therefore, when I convert MOF 2.0 to MOF 1.4, I
> ignore the attributes whose “redefinedProperty†is set. After this new MOF 1.4
> + xmi 1.2 file was imported into MDR, I found that there are much fewer
> duplicated parameters, but there are still some. For example, in specification of
> UML 2.0, there are two classes owning un-redefined attribute ‘name’  (class
> ‘NamedElement’ in package InfrastructureLibrary.Core.Abstractions.Namespaces
> and class ‘NameElement’ in package
> InfrastructureLibrary.Core.Basic.NamedElement, both classes of ‘NameElement’ do not indirectly or directly inherit from
> each other), but there are some classes directly or indirectly inherit the
> attribute 'name' from both of the class ‘Namedelement’ e.g class ‘Enumeration’
> in package ‘uml.classes.kernel’, and it causes that they have two parameters
> of ‘name’ in their ‘create’ methods. Similar case also happens to
> ‘isAbstract’ ect.
> 
> I don’t know if it is a bug in specification of UML2.0 defined in xmi
> format, or I should consider any other parameters to ignore more attributes besides
> considering ‘redefinedProperty’. At the end of this email, I append xmi code
> of both un-redefined attributes ‘name’ in both classes of 'NamedElement'
> which are cut from UML 2.0 specification.
> 
> By the way, thanks for your answer in another mailing list concerning
> ‘operation’ of MOF 2.0, and that problem has been solved with your suggestion.
> 
> Regards
> 
> 
> Fu, Bin
> 
> 
> <ownedClassifier xsi:type="cmof:Class"
> xmi:id="_InfrastructureLibrary_Core_Basic_NamedElement" name="NamedElement" isAbstract="true"
> superClass="_InfrastructureLibrary_Core_Abstractions_Elements_Element">
>   <ownedAttribute xsi:type="cmof:Property" xmi:id="S.005.1032.00.98"
> lower="0" name="name" type="String" default=""/>
> </ownedClassifier>
> 
> 
> <ownedClassifier xsi:type="cmof:Class"
> xmi:id="_InfrastructureLibrary_Core_Abstractions_Namespaces_NamedElement" name="NamedElement" isAbstract="true"
> superClass="_InfrastructureLibrary_Core_Abstractions_Ownerships_Element">
> …
>   <ownedAttribute xsi:type="cmof:Property" xmi:id="S.005.1031.59.12"
> lower="0" name="name" type="String" default=""/>
> …
> </ownedClassifier>
> 
> 
> 
> 
>>It seems that your metamodel does not conform to MOF 1.4 in a sense that 
>>it contains classes that "override" or "redefine" features from their 
>>superclasses. I suspect that several superclasses of the 
>>InstanceSpecification define attribute named "name". In MOF there is a 
>>constraint saying that names of all elements contained transitively via 
>>inheritance in a given element have to be unique - i.e. features 
>>overriding, overloading and hiding is not supported.
>>Martin
>>
>>Bin Fu wrote:
>>
>>
>>>Hi, 
>>>
>>>In the generated JMI interfaces, I found that most of interfaces with
>>>name ending of "Class" have parameter duplications in their "create"
>>
>>methods
>>
>>>e.g. in "InstanceSpecificationClass.java",
>>>…
>>>public InstanceSpecification
>>>createInstanceSpecification(java.util.Collection name,
>>
>>java.util.Collection
>>
>>>visibility, java.util.Collection name,
>>>java.util.Collection name, java.util.Collection name,
>>
>>java.util.Collection
>>
>>>visibility,
>>>java.util.Collection visibility);
>>>…
>>>
>>>What could be the reason for it? There is no attribute duplication in
>>
>>the
>>
>>>xmi source file. 
>>>
>>>Thanks a lot!
>>>
>>>Fu, Bin
>>>
>>
>>
>