Home » Archived » GMT (Generative Modeling Technologies) » Re: [ATL][AM3] editing Models
| | |
| Re: [ATL][AM3] editing Models [message #381242 is a reply to message #381241] |
Wed, 12 March 2008 12:21   |
 Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello,
I just wanted to precise that the Families metamodel lacks some fields
required for code generation, but does not lack any field for usage as a
metamodel.
Regards,
Frédéric Jouault
Freddy Allilaire a écrit :
> Hi Adil,
>
> "Families" metamodel misses some required fields (if you click on
> "Details" button, you will see the list of problems).
>
> "Ns Prefix" and "Ns URI" properties of root packages (Families &
> PrimitiveTypes) should be answered.
> "Instance Type Name" property (and maybe Instance Class Name) of String
> DataType should also be answered.
>
> Regards,
> Freddy.
>
> adil a écrit :
>> Hello,
>> I tested the creation of models according to their metamodels using
>> the EMF Generated Editor. To this end, I used the Families.ecore
>> metamodel ( the example Provided With ATL_UML2_Bundle_2.0.0RC2_Windows
>> ) and I want Create a model that conforms to "Families.ecore". So,
>> With a right click on the Families.ecore metamodel, I Point (New >
>> Other... Eclipse Modeling Framework> but I can't generate the genmodel
>> file. In the Step "Ecore Import", When I click the load button, I have
>> the message " problems were detected while validating and converting
>> the ecore models". how I can resolve this problem? best regards,
>> Adil.
>>
>
|
|
|
| Re: [ATL][AM3] editing Models [message #381243 is a reply to message #381242] |
Wed, 12 March 2008 12:44 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Frédéric,
It seems like generally an awfully good idea to have Ecore instances
that are well formed with respect to the constraints defined for Ecore.
Computing default values for properties that must be set would seem to
be a good approach. I.e., set the nsPrefix to be the same as the name
of the package and set instanceClassName to be java.lang.Object for data
types. The nsURI seems like a pretty important thing even from just a
metamodel point of view as a way to uniquely identify the model. But
then again, I don't really know the context of this very well, so maybe
what I'm saying isn't all that sensible; maybe it is best that folks
need to go in an manually add such information to ensure it's sensible...
Frédéric Jouault wrote:
> Hello,
>
> I just wanted to precise that the Families metamodel lacks some fields
> required for code generation, but does not lack any field for usage as
> a metamodel.
>
>
> Regards,
>
> Frédéric Jouault
>
> Freddy Allilaire a écrit :
>> Hi Adil,
>>
>> "Families" metamodel misses some required fields (if you click on
>> "Details" button, you will see the list of problems).
>>
>> "Ns Prefix" and "Ns URI" properties of root packages (Families &
>> PrimitiveTypes) should be answered.
>> "Instance Type Name" property (and maybe Instance Class Name) of
>> String DataType should also be answered.
>>
>> Regards,
>> Freddy.
>>
>> adil a écrit :
>>> Hello,
>>> I tested the creation of models according to their metamodels using
>>> the EMF Generated Editor. To this end, I used the Families.ecore
>>> metamodel ( the example Provided With
>>> ATL_UML2_Bundle_2.0.0RC2_Windows ) and I want Create a model that
>>> conforms to "Families.ecore". So, With a right click on the
>>> Families.ecore metamodel, I Point (New > Other... Eclipse Modeling
>>> Framework> but I can't generate the genmodel file. In the Step
>>> "Ecore Import", When I click the load button, I have the message "
>>> problems were detected while validating and converting the ecore
>>> models". how I can resolve this problem? best regards,
>>> Adil.
>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [ATL][AM3] editing Models [message #381244 is a reply to message #381243] |
Wed, 12 March 2008 19:19 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Ed,
> It seems like generally an awfully good idea to have Ecore instances
> that are well formed with respect to the constraints defined for Ecore.
> Computing default values for properties that must be set would seem to
> be a good approach. I.e., set the nsPrefix to be the same as the name
> of the package and set instanceClassName to be java.lang.Object for data
> types.
I agree that we should always provide .ecore files with nsURI and
nsPrefix set.
> The nsURI seems like a pretty important thing even from just a
> metamodel point of view as a way to uniquely identify the model.
However, I cannot agree that an nsURI (i.e., an *XML* namespace URI) is
generally an important part of a metamodel (i.e., an *MDE* entity). On
the contrary, I do believe that a metamodel should not refer to any
specific technology/platform.
The same remark holds for the usage of Java classes/objects in a metamodel.
This is why we have historically only been setting default values for
nsURI, nsPrefix, and instanceClassName at .ecore file load time. At this
point, we have already committed to Java and XMI. Therefore, I consider
it normal to "bind" the metamodel to the actual platform.
The problem with this approach is that the binding does not persist. My
preference definitely goes to a separate specification of the binding
(i.e., in another file, not in the metamodel), which allows different
bindings on different platforms or for different usages. However, this
is not how EMF currently works. This is why I agree that we should
persist the platform binding in the .ecore files.
Best regards,
Frédéric Jouault
|
|
|
| Re: [ATL][AM3] editing Models [message #381746 is a reply to message #381244] |
Wed, 12 March 2008 20:03 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Frédéric,
Comments below.
Frédéric Jouault wrote:
> Ed,
>
>
> > It seems like generally an awfully good idea to have Ecore instances
> > that are well formed with respect to the constraints defined for Ecore.
> > Computing default values for properties that must be set would seem to
> > be a good approach. I.e., set the nsPrefix to be the same as the name
> > of the package and set instanceClassName to be java.lang.Object for
> data
> > types.
>
> I agree that we should always provide .ecore files with nsURI and
> nsPrefix set.
>
>
>
> > The nsURI seems like a pretty important thing even from just a
> > metamodel point of view as a way to uniquely identify the model.
>
> However, I cannot agree that an nsURI (i.e., an *XML* namespace URI)
> is generally an important part of a metamodel (i.e., an *MDE* entity).
> On the contrary, I do believe that a metamodel should not refer to any
> specific technology/platform.
I'm not sure why you consider it technology or platform specific. It's
certainly a MOF concept and there it's platform neutral. And in a sense
even Java package names are namespaces in this same way. In all cases,
the idea is to provide something to ensure that entity can be uniquely
identified by something human readable and something other than its
physical location.
>
> The same remark holds for the usage of Java classes/objects in a
> metamodel.
That's certainly true if the model is meant to be used for more than Java.
>
>
> This is why we have historically only been setting default values for
> nsURI, nsPrefix, and instanceClassName at .ecore file load time. At
> this point, we have already committed to Java and XMI. Therefore, I
> consider it normal to "bind" the metamodel to the actual platform.
UML generally supports things like stereo types so you can augment the
model with things that aren't intrinsic to the model. It is after all
important that a type representing int verses one that representing
String be bound correctly.
>
> The problem with this approach is that the binding does not persist.
Indeed.
> My preference definitely goes to a separate specification of the
> binding (i.e., in another file, not in the metamodel), which allows
> different bindings on different platforms or for different usages
Yes, it's often a question of whether annotations are stored on the
object or stored separate and associated with an object. In a certain
sense, those two are equivalent.
> . However, this is not how EMF currently works. This is why I agree
> that we should persist the platform binding in the .ecore files.
Indeed, Ecore is very much focused on working primarily with Java. And
we've taken pragmatic liberties and in a pure sense might not sit so
well. Most folks are pragmatists rather than purists though... In any
case, EMF as a whole could be used for anything... It will be
interesting to see how the C# work unfolds.
>
>
> Best regards,
>
> Frédéric Jouault
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: [ATL][AM3] editing Models [message #613611 is a reply to message #381241] |
Wed, 12 March 2008 12:21 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello,
I just wanted to precise that the Families metamodel lacks some fields
required for code generation, but does not lack any field for usage as a
metamodel.
Regards,
Frédéric Jouault
Freddy Allilaire a écrit :
> Hi Adil,
>
> "Families" metamodel misses some required fields (if you click on
> "Details" button, you will see the list of problems).
>
> "Ns Prefix" and "Ns URI" properties of root packages (Families &
> PrimitiveTypes) should be answered.
> "Instance Type Name" property (and maybe Instance Class Name) of String
> DataType should also be answered.
>
> Regards,
> Freddy.
>
> adil a écrit :
>> Hello,
>> I tested the creation of models according to their metamodels using
>> the EMF Generated Editor. To this end, I used the Families.ecore
>> metamodel ( the example Provided With ATL_UML2_Bundle_2.0.0RC2_Windows
>> ) and I want Create a model that conforms to "Families.ecore". So,
>> With a right click on the Families.ecore metamodel, I Point (New >
>> Other... Eclipse Modeling Framework> but I can't generate the genmodel
>> file. In the Step "Ecore Import", When I click the load button, I have
>> the message " problems were detected while validating and converting
>> the ecore models". how I can resolve this problem? best regards,
>> Adil.
>>
>
|
|
|
| Re: [ATL][AM3] editing Models [message #613617 is a reply to message #381242] |
Wed, 12 March 2008 12:44 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Frédéric,
It seems like generally an awfully good idea to have Ecore instances
that are well formed with respect to the constraints defined for Ecore.
Computing default values for properties that must be set would seem to
be a good approach. I.e., set the nsPrefix to be the same as the name
of the package and set instanceClassName to be java.lang.Object for data
types. The nsURI seems like a pretty important thing even from just a
metamodel point of view as a way to uniquely identify the model. But
then again, I don't really know the context of this very well, so maybe
what I'm saying isn't all that sensible; maybe it is best that folks
need to go in an manually add such information to ensure it's sensible...
Frédéric Jouault wrote:
> Hello,
>
> I just wanted to precise that the Families metamodel lacks some fields
> required for code generation, but does not lack any field for usage as
> a metamodel.
>
>
> Regards,
>
> Frédéric Jouault
>
> Freddy Allilaire a écrit :
>> Hi Adil,
>>
>> "Families" metamodel misses some required fields (if you click on
>> "Details" button, you will see the list of problems).
>>
>> "Ns Prefix" and "Ns URI" properties of root packages (Families &
>> PrimitiveTypes) should be answered.
>> "Instance Type Name" property (and maybe Instance Class Name) of
>> String DataType should also be answered.
>>
>> Regards,
>> Freddy.
>>
>> adil a écrit :
>>> Hello,
>>> I tested the creation of models according to their metamodels using
>>> the EMF Generated Editor. To this end, I used the Families.ecore
>>> metamodel ( the example Provided With
>>> ATL_UML2_Bundle_2.0.0RC2_Windows ) and I want Create a model that
>>> conforms to "Families.ecore". So, With a right click on the
>>> Families.ecore metamodel, I Point (New > Other... Eclipse Modeling
>>> Framework> but I can't generate the genmodel file. In the Step
>>> "Ecore Import", When I click the load button, I have the message "
>>> problems were detected while validating and converting the ecore
>>> models". how I can resolve this problem? best regards,
>>> Adil.
>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [ATL][AM3] editing Models [message #613618 is a reply to message #381243] |
Wed, 12 March 2008 19:19 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Ed,
> It seems like generally an awfully good idea to have Ecore instances
> that are well formed with respect to the constraints defined for Ecore.
> Computing default values for properties that must be set would seem to
> be a good approach. I.e., set the nsPrefix to be the same as the name
> of the package and set instanceClassName to be java.lang.Object for data
> types.
I agree that we should always provide .ecore files with nsURI and
nsPrefix set.
> The nsURI seems like a pretty important thing even from just a
> metamodel point of view as a way to uniquely identify the model.
However, I cannot agree that an nsURI (i.e., an *XML* namespace URI) is
generally an important part of a metamodel (i.e., an *MDE* entity). On
the contrary, I do believe that a metamodel should not refer to any
specific technology/platform.
The same remark holds for the usage of Java classes/objects in a metamodel.
This is why we have historically only been setting default values for
nsURI, nsPrefix, and instanceClassName at .ecore file load time. At this
point, we have already committed to Java and XMI. Therefore, I consider
it normal to "bind" the metamodel to the actual platform.
The problem with this approach is that the binding does not persist. My
preference definitely goes to a separate specification of the binding
(i.e., in another file, not in the metamodel), which allows different
bindings on different platforms or for different usages. However, this
is not how EMF currently works. This is why I agree that we should
persist the platform binding in the .ecore files.
Best regards,
Frédéric Jouault
|
|
|
| Re: [ATL][AM3] editing Models [message #613622 is a reply to message #381244] |
Wed, 12 March 2008 20:03 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Frédéric,
Comments below.
Frédéric Jouault wrote:
> Ed,
>
>
> > It seems like generally an awfully good idea to have Ecore instances
> > that are well formed with respect to the constraints defined for Ecore.
> > Computing default values for properties that must be set would seem to
> > be a good approach. I.e., set the nsPrefix to be the same as the name
> > of the package and set instanceClassName to be java.lang.Object for
> data
> > types.
>
> I agree that we should always provide .ecore files with nsURI and
> nsPrefix set.
>
>
>
> > The nsURI seems like a pretty important thing even from just a
> > metamodel point of view as a way to uniquely identify the model.
>
> However, I cannot agree that an nsURI (i.e., an *XML* namespace URI)
> is generally an important part of a metamodel (i.e., an *MDE* entity).
> On the contrary, I do believe that a metamodel should not refer to any
> specific technology/platform.
I'm not sure why you consider it technology or platform specific. It's
certainly a MOF concept and there it's platform neutral. And in a sense
even Java package names are namespaces in this same way. In all cases,
the idea is to provide something to ensure that entity can be uniquely
identified by something human readable and something other than its
physical location.
>
> The same remark holds for the usage of Java classes/objects in a
> metamodel.
That's certainly true if the model is meant to be used for more than Java.
>
>
> This is why we have historically only been setting default values for
> nsURI, nsPrefix, and instanceClassName at .ecore file load time. At
> this point, we have already committed to Java and XMI. Therefore, I
> consider it normal to "bind" the metamodel to the actual platform.
UML generally supports things like stereo types so you can augment the
model with things that aren't intrinsic to the model. It is after all
important that a type representing int verses one that representing
String be bound correctly.
>
> The problem with this approach is that the binding does not persist.
Indeed.
> My preference definitely goes to a separate specification of the
> binding (i.e., in another file, not in the metamodel), which allows
> different bindings on different platforms or for different usages
Yes, it's often a question of whether annotations are stored on the
object or stored separate and associated with an object. In a certain
sense, those two are equivalent.
> . However, this is not how EMF currently works. This is why I agree
> that we should persist the platform binding in the .ecore files.
Indeed, Ecore is very much focused on working primarily with Java. And
we've taken pragmatic liberties and in a pure sense might not sit so
well. Most folks are pragmatists rather than purists though... In any
case, EMF as a whole could be used for anything... It will be
interesting to see how the C# work unfolds.
>
>
> Best regards,
>
> Frédéric Jouault
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 21:56:20 GMT 2024
Powered by FUDForum. Page generated in 0.04200 seconds |
] 
Search
Help
Register
Login
Home
