| Specifying a datatype in HUTN in Epsilon [message #1834735] |
Tue, 17 November 2020 05:21  |
|
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 64 times)
[Updated on: Tue, 17 November 2020 05:47] Report message to a moderator |
|
|
| Re: Specifying a datatype in HUTN in Epsilon [message #1834746 is a reply to message #1834735] |
Tue, 17 November 2020 10:12  |
|
Hi Joern,
I've noticed that your metamodel contains multiple nested packages (which are in general problematic [1]), each of which is treated as a separate metamodel by EMF. Therefore, you need to include two metamodel declarations in your HUTN document:
@Spec {
metamodel "uml14" {
nsUri: "http://jgsuess.net/uml14"
}
metamodel "uml14core" {
nsUri: "http://jgsuess.net/uml14/core"
}
}
package {
Model {
ownedElement: Class {
name: "This parses"
}
}
}
The syntax of HUTN is specified in [2] and in the OMG spec linked at the bottom of that article. A useful trick to find out the expected syntax for a feature in HUTN is to define a small model using Epsilon's "EMF Model" wizard and then right-click on the .model file and select "HUTN -> Generate HUTN".
Having said this, you may also want to consider Flexmi [3] as an alternative reflective textual syntax, which is much more powerful and actively maintained than HUTN. In Flexmi, your model would look like this:
<?nsuri http://jgsuess.net/uml14?>
<?nsuri http://jgsuess.net/uml14/core?>
<model>
<class name="This parses"/>
</model>
What's more, Flexmi files are proper EMF resources and don't need to be converted to XMI before they can used in e.g. Epsilon programs. You can experiment with Flexmi here: https://www.eclipse.org/epsilon/live/
Does this answer your question?
Thanks,
Dimitris
[1] https://cedric.brun.io/eclipse/ecore-design-checklist-part1/ (search for "nested epackages")
[2] https://www.eclipse.org/epsilon/doc/articles/hutn-basic/
[3] https://www.eclipse.org/epsilon/doc/flexmi/
|
|
|
| Re: Specifying a datatype in HUTN in Epsilon [message #1834784 is a reply to message #1834746] |
Tue, 17 November 2020 21:40 |
|
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.02672 seconds
] 
Search
Help
Register
Login
Home
