Specifying a datatype in HUTN in Epsilon [message #1834735] |
Tue, 17 November 2020 00:21  |
Eclipse User |
|
|
|
UML 1.4.2 is great as a standard backing for experiments. However, it has a a datatypes package which interfaces to the underlying primitive storage of the M2.
For example, it has:
Integer, backed by long
Name, backed by String, and even
String, backed by String.
I would like to use Epsilon's HUTN to specify a few models, but I have not found any information on the syntax to use for specifying such a datatype.
In short:
How do I specify the name of something against the attached metamodel in HUTN? Below is the intuitive solutions, that fails to parse saying:
Quote:no viable alternative at input 'ownedElement'
@Spec {
metamodel "uml14" {
nsUri: "http://jgsuess.net/uml14"
}
}
Model {
ownedElement: Class { name: "ThisDoesNotParse" }
}
Attachment: UML14.ecore
(Size: 76.31KB, Downloaded 93 times)
[Updated on: Tue, 17 November 2020 00:47] by Moderator
|
|
|
|
Re: Specifying a datatype in HUTN in Epsilon [message #1834784 is a reply to message #1834746] |
Tue, 17 November 2020 16:40  |
Eclipse User |
|
|
|
Thanks for your help. This is useful information. I had consulted the spec, and looked at the code, but was assuming that this was caused by the special nature of Datatypes.
On the matter of nested packages:: The nested packages are part of the UML1.4.2 iso standard, so the Gang of Four have to answer for this. In this sense, this is not 'my' metamodel. I merely packaged it into my XML namespace with OMG consent to ensure that it is clear that this is an EMF rendering of the MDR attached to the standard. And the MDR is already non-canonical.
I prefer the HUTN syntax, as it is even less verbose then Flexmi's. I agree with the design rationale set out in the HUTN standard. I also find that developers in general find it more amenable.
I assume that the issue you are referring to is a ambiguous scoped names in the resolution. I could not find an example of fully package-qualified names. I assume that this would be the way to work around the limitation.
UML 1.4.2 class names are unique across the package space, so I would not expect issues there.
|
|
|
Powered by
FUDForum. Page generated in 0.05285 seconds