Home » Modeling » Epsilon » [HUTN] Difference between the implementation and the HUTN specification
| [HUTN] Difference between the implementation and the HUTN specification [message #552014] |
Tue, 10 August 2010 14:23  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I'm trying out Epsilon and HUTN for the first time, in the context of a
course in model-based development. So far, I've managed to create an
Ecore model, a config file for the model using HUTN and an instance of
the model using HUTN.
There seems to be some parts of the specification that is not
implementet. At least, I haven't been able to specify ParametricConfig
objects or defining a scope IdentifierConfig rules, based on the HUTN
specification I'm reading
(http://www.omg.org/cgi-bin/doc?formal/2004-08-01). In addition, there
seems to be some differences between the implementation and the
specification, e.g. the HUTN metamodel has the class IdentifierConfig,
while Epsilon uses IdentifierRule.
Is there a place where I can find more information about the difference
between the implementation and the HUTN specification?
Best regards,
Hallvard Trætteberg
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #552077 is a reply to message #552014] |
Tue, 10 August 2010 17:58  |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
Reply hidden below 
| Hallvard Traetteberg wrote on Tue, 10 August 2010 10:23 | Hi,
I'm trying out Epsilon and HUTN for the first time, in the context of a
course in model-based development. So far, I've managed to create an
Ecore model, a config file for the model using HUTN and an instance of
the model using HUTN.
|
Thanks for trying out Epsilon and HUTN. Sounds like you're already an expert!
| Quote: | There seems to be some parts of the specification that is not
implementet.
|
You're right - there are some differences between the HUTN specification and the implementation in Epsilon. The most complete description of the Epsilon HUTN implementation is in this paper: http://www.springerlink.com/content/p05h270213197718/
| Quote: | At least, I haven't been able to specify ParametricConfig
objects or defining a scope IdentifierConfig rules, based on the HUTN
specification I'm reading
(http://www.omg.org/cgi-bin/doc?formal/2004-08-01). In addition, there
seems to be some differences between the implementation and the
specification, e.g. the HUTN metamodel has the class IdentifierConfig,
while Epsilon uses IdentifierRule.
|
With regard to the parts of the specification you mention, parametric configurations are not supported in Epsilon HUTN. Identifier configurations can be specified in Epsilon HUTN, and I'm currently writing some documentation for this feature. Briefly, this can be achieved by:
1) Create a Epsilon HUTN configuration model:
a) File | New | Epsilon | EMF Model
b) Fill in name with something like "families_config.model"
c) Fill in metamodel URI with "http://www.eclipse.org/gmt/epsilon/hutnConfig"
d) For root instance type, select Configuration
2) Create the configuration rules:
a) Open the model file created by step 1
b) Right-click the configuration object
c) Select new child, and then the type of rule you'd like to configure
d) Right-click the resulting object and click Show Properties View.
3) Tell the HUTN file to use the configuration model
a) Open the HUTN source
b) In the preamble, add a configFile value. The resulting HUTN should look similar to this:
@Spec {
metamodel "families" {
nsUri: "families"
configFile: "families_config.model"
}
}
families {
...
}
(The configFile value is a path relative to the HUTN source file).
I'm writing an article describing this process in more detail. I'll add a link here when it's finished.
| Quote: | Is there a place where I can find more information about the difference
between the implementation and the HUTN specification?
|
We don't keep a list, mainly because the OMG specification doesn't provide any test cases against which we can test the compliance of the Epsilon HUTN implementation.
Having said that, the main areas I know to be unimplemented are:
o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
o Inline configuration (Section 7 of the HUTN specification)
Some elements of the specification are implemented differently:
o Configuration is specified in a model (as described above)
o References to model elements stored in a separate file use an EMF URI.
Cheers,
Louis.
[Updated on: Tue, 10 August 2010 17:58] Report message to a moderator |
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #552160 is a reply to message #552077] |
Wed, 11 August 2010 06:57 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Louis,
Comments inlined:
On 10.08.10 19.58, Louis Rose wrote:
>
> Quote:
>> There seems to be some parts of the specification that is not
>> implementet.
>
> You're right - there are some differences between the HUTN specification
> and the implementation in Epsilon. The most complete description of the
> Epsilon HUTN implementation is in this paper:
> http://www.springerlink.com/content/p05h270213197718/
Yes, I read it and may in fact include it in the curriculum!
> Briefly, [creating a Configuration] can be achieved by:
A managed to do this, based on existing information. I also guessed from
the HUTN config model (lack of a ParametricRule class) that there wasn't
support for ParametricConfig. However, a summary of missing parts and
differences wrt. the specification would have helped ;-)
> I'm writing an article describing this process in more detail. I'll add
> a link here when it's finished.
Good!
> o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
This is a nice feature, but I guess a bit complex to implement.
> o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
This shouldn't be that hard, should it. Since the parser already
supports adjectives. Isn't it a matter of searching for an attribute
that has an enum as its type, with the relevant name/literal (in this
case 'poodle')?
> o Inline configuration (Section 7 of the HUTN specification)
That's what I tried first, but having a separate config file is good enough.
> o References to model elements stored in a separate file use an EMF URI.
Interesting! How is this used?
Hallvard
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #552226 is a reply to message #552160] |
Wed, 11 August 2010 11:17 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
| Hallvard Traetteberg wrote on Wed, 11 August 2010 02:57 | A managed to do this, based on existing information. I also guessed from
the HUTN config model (lack of a ParametricRule class) that there wasn't
support for ParametricConfig. However, a summary of missing parts and
differences wrt. the specification would have helped 
|
Yes, I can see how that would have been useful! I'll put together a short article on the Epsilon website to describe the parts of the specification that we don't currently support.
| Quote: | > o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
This is a nice feature, but I guess a bit complex to implement.
|
Yes, it requires some changes to the parser, so we've not yet implemented this.
| Quote: | > o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
This shouldn't be that hard, should it. Since the parser already
supports adjectives. Isn't it a matter of searching for an attribute
that has an enum as its type, with the relevant name/literal (in this
case 'poodle')?
|
I agree that this is easier to implement. However, the HUTN specification requires a configuration rule for the use of enumeration adjectives. We're not implementing any further configuration rules yet, as we're thinking about adding inline configuration first.
| Quote: | > o Inline configuration (Section 7 of the HUTN specification)
That's what I tried first, but having a separate config file is good enough.
|
A separate config model allows re-use across HUTN source files too. But it is a deviation from the specification, so we're thinking of also supporting inline configuration.
| Quote: | > o References to model elements stored in a separate file use an EMF URI.
Interesting! How is this used?
|
To specify a reference value, the identifier can be defined in the current file (the default usage), or an EMF URI (to reference a model element stored in a different model). For example:
Person "me" {
friends: Person "you", Person "platform:/resource/another.project/models/People.model#//@contents.0"
}
Person "you {}
This uses the EMF URI syntax described here:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
For the example above, it references the file "People.model" stored in the "models" directory of a workspace project called "another.project". The model element references is the first element (0) of the "contents" feature of the root model element.
On a related note, Epsilon HUTN has a pretty comprehensive set of acceptance tests, which demonstrate the features of the implementation. They're stored in our Subversion repository, and can be viewed online here:
http://dev.eclipse.org/viewsvn/index.cgi/trunk/tests/org.ecl ipse.epsilon.hutn.test.acceptance/src/org/eclipse/epsilon/hu tn/test/acceptance/?root=Modeling_EPSILON
Here's the acceptance test for adjectives, for example:
http://dev.eclipse.org/viewsvn/index.cgi/trunk/tests/org.ecl ipse.epsilon.hutn.test.acceptance/src/org/eclipse/epsilon/hu tn/test/acceptance/valid/Adjectives.java?root=Modeling_EPSIL ON&view=markup
Cheers,
Louis.
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #552262 is a reply to message #552226] |
Wed, 11 August 2010 13:28 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 11.08.10 13.17, Louis Rose wrote:
> Quote:
>> > o References to model elements stored in a separate file use an EMF URI.
>>
>> Interesting! How is this used?
>
>
> To specify a reference value, the identifier can be defined in the
> current file (the default usage), or an EMF URI (to reference a model
> element stored in a different model). For example:
>
> Person "me" {
> friends: Person "you", Person
> " platform:/resource/another.project/models/People.model#//@co ntents.0 "
> }
>
> Person "you {}
>
> This uses the EMF URI syntax described here:
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
Nice! Since it's possible to customize the fragment part (the part after
the '#') by specializing the resource implementation, you can make the
syntax a bit nicer, e.g. support identifiers and keys. Is the URI
resolved with the current model's URI as the base? If so, the URI to
files "nearby" could be relative and significantly shorter.
> On a related note, Epsilon HUTN has a pretty comprehensive set of
> acceptance tests, which demonstrate the features of the implementation.
> They're stored in our Subversion repository, and can be viewed online here:
Thanks!
I'll be trying out the other Epsilon languages soon, so there will
likely be more questions from me ;-)
Hallvard
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #552316 is a reply to message #552262] |
Wed, 11 August 2010 17:15 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
| Hallvard Traetteberg wrote on Wed, 11 August 2010 09:28 | On 11.08.10 13.17, Louis Rose wrote:
> Quote:
>> > o References to model elements stored in a separate file use an EMF URI.
>>
>> Interesting! How is this used?
>
>
> To specify a reference value, the identifier can be defined in the
> current file (the default usage), or an EMF URI (to reference a model
> element stored in a different model). For example:
>
> Person "me" {
> friends: Person "you", Person
> " platform:/resource/another.project/models/People.model#//@co ntents.0 "
> }
>
> Person "you {}
>
> This uses the EMF URI syntax described here:
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
Nice! Since it's possible to customize the fragment part (the part after
the '#') by specializing the resource implementation, you can make the
syntax a bit nicer, e.g. support identifiers and keys.
|
Yes, this will work today with Epsilon HUTN because it uses EMF to parse URIs.
| Quote: | Is the URI
resolved with the current model's URI as the base? If so, the URI to
files "nearby" could be relative and significantly shorter.
|
Currently, the URI has to be absolute, and not relative. However, support for relative URIs sounds like a good idea. Would you file an enhancement request in our Bugzilla? ( https://bugs.eclipse.org/bugs/enter_bug.cgi?product=GMT& component=Epsilon)
| Quote: | I'll be trying out the other Epsilon languages soon, so there will
likely be more questions from me
|
Great! Do let us know if you have any further queries or feedback.
Cheers,
Louis.
|
|
| | | | | | |
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #592792 is a reply to message #552014] |
Tue, 10 August 2010 17:58 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
Reply hidden below :)
Hallvard Traetteberg wrote on Tue, 10 August 2010 10:23
> Hi,
>
> I'm trying out Epsilon and HUTN for the first time, in the context of a
> course in model-based development. So far, I've managed to create an
> Ecore model, a config file for the model using HUTN and an instance of
> the model using HUTN.
Thanks for trying out Epsilon and HUTN. Sounds like you're already an expert!
Quote:
> There seems to be some parts of the specification that is not
> implementet.
You're right - there are some differences between the HUTN specification and the implementation in Epsilon. The most complete description of the Epsilon HUTN implementation is in this paper: http://www.springerlink.com/content/p05h270213197718/
Quote:
> At least, I haven't been able to specify ParametricConfig
> objects or defining a scope IdentifierConfig rules, based on the HUTN
> specification I'm reading
> (http://www.omg.org/cgi-bin/doc?formal/2004-08-01). In addition, there
> seems to be some differences between the implementation and the
> specification, e.g. the HUTN metamodel has the class IdentifierConfig,
> while Epsilon uses IdentifierRule.
With regard to the parts of the specification you mention, parametric configurations are not supported in Epsilon HUTN. Identifier configurations can be specified in Epsilon HUTN, and I'm currently writing some documentation for this feature. Briefly, this can be achieved by:
1) Create a Epsilon HUTN configuration model:
a) File | New | Epsilon | EMF Model
b) Fill in name with something like "families_config.model"
c) Fill in metamodel URI with "http://www.eclipse.org/gmt/epsilon/hutnConfig"
d) For root instance type, select Configuration
2) Create the configuration rules:
a) Open the model file created by step 1
b) Right-click the configuration object
c) Select new child, and then the type of rule you'd like to configure
d) Right-click the resulting object and click Show Properties View.
3) Tell the HUTN file to use the configuration model
a) Open the HUTN source
b) In the preamble, add a configFile value. The resulting HUTN should look similar to this:
@Spec {
metamodel "families" {
nsUri: "families"
configFile: "families_config.model"
}
}
families {
...
}
(The configFile value is a path relative to the HUTN source file).
I'm writing an article describing this process in more detail. I'll add a link here when it's finished.
Quote:
> Is there a place where I can find more information about the difference
> between the implementation and the HUTN specification?
We don't keep a list, mainly because the OMG specification doesn't provide any test cases against which we can test the compliance of the Epsilon HUTN implementation.
Having said that, we do keep a list internally. The main areas that aren't implemented are:
o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
o Inline configuration (Section 7 of the HUTN specification)
Some elements of the specification are implemented differently:
o Configuration is specified in a model (as described above)
o References to model elements stored in a separate file use an EMF URI.
Cheers,
Louis.
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #592829 is a reply to message #592792] |
Wed, 11 August 2010 06:57 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Louis,
Comments inlined:
On 10.08.10 19.58, Louis Rose wrote:
>
> Quote:
>> There seems to be some parts of the specification that is not
>> implementet.
>
> You're right - there are some differences between the HUTN specification
> and the implementation in Epsilon. The most complete description of the
> Epsilon HUTN implementation is in this paper:
> http://www.springerlink.com/content/p05h270213197718/
Yes, I read it and may in fact include it in the curriculum!
> Briefly, [creating a Configuration] can be achieved by:
A managed to do this, based on existing information. I also guessed from
the HUTN config model (lack of a ParametricRule class) that there wasn't
support for ParametricConfig. However, a summary of missing parts and
differences wrt. the specification would have helped ;-)
> I'm writing an article describing this process in more detail. I'll add
> a link here when it's finished.
Good!
> o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
This is a nice feature, but I guess a bit complex to implement.
> o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
This shouldn't be that hard, should it. Since the parser already
supports adjectives. Isn't it a matter of searching for an attribute
that has an enum as its type, with the relevant name/literal (in this
case 'poodle')?
> o Inline configuration (Section 7 of the HUTN specification)
That's what I tried first, but having a separate config file is good enough.
> o References to model elements stored in a separate file use an EMF URI.
Interesting! How is this used?
Hallvard
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #592836 is a reply to message #552160] |
Wed, 11 August 2010 11:17 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
Hallvard Traetteberg wrote on Wed, 11 August 2010 02:57
> A managed to do this, based on existing information. I also guessed from
> the HUTN config model (lack of a ParametricRule class) that there wasn't
> support for ParametricConfig. However, a summary of missing parts and
> differences wrt. the specification would have helped ;)
Yes, I can see how that would have been useful! I'll put together a short article on the Epsilon website to describe the parts of the specification that we don't currently support.
Quote:
> > o Parameterisied classifiers. (e.g. Co-ordinate "x" (3,5))
>
> This is a nice feature, but I guess a bit complex to implement.
Yes, it requires some changes to the parser, so we've not yet implemented this.
Quote:
> > o Enumerations as adjectives. (e.g. poodle Dog "Fido" {})
>
> This shouldn't be that hard, should it. Since the parser already
> supports adjectives. Isn't it a matter of searching for an attribute
> that has an enum as its type, with the relevant name/literal (in this
> case 'poodle')?
I agree that this is easier to implement. However, the HUTN specification requires a configuration rule for the use of enumeration adjectives. We're not implementing any further configuration rules yet, as we're thinking about adding inline configuration first.
Quote:
> > o Inline configuration (Section 7 of the HUTN specification)
>
> That's what I tried first, but having a separate config file is good enough.
A separate config model allows re-use across HUTN source files too. But it is a deviation from the specification, so we're thinking of also supporting inline configuration.
Quote:
> > o References to model elements stored in a separate file use an EMF URI.
>
> Interesting! How is this used?
To specify a reference value, the identifier can be defined in the current file (the default usage), or an EMF URI (to reference a model element stored in a different model). For example:
Person "me" {
friends: Person "you", Person " platform:/resource/another.project/models/People.model#//@co ntents.0 "
}
Person "you {}
This uses the EMF URI syntax described here:
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
For the example above, it references the file "People.model" stored in the "models" directory of a workspace project called "another.project". The model element references is the first element (0) of the "contents" feature of the root model element.
On a related note, Epsilon HUTN has a pretty comprehensive set of acceptance tests, which demonstrate the features of the implementation. They're stored in our Subversion repository, and can be viewed online here:
http://dev.eclipse.org/viewsvn/index.cgi/trunk/tests/org.ecl ipse.epsilon.hutn.test.acceptance/src/org/eclipse/epsilon/hu tn/test/acceptance/?root=Modeling_EPSILON
Here's the acceptance test for adjectives, for example:
http://dev.eclipse.org/viewsvn/index.cgi/trunk/tests/org.ecl ipse.epsilon.hutn.test.acceptance/src/org/eclipse/epsilon/hu tn/test/acceptance/valid/Adjectives.java?root=Modeling_EPSIL ON&view=markup
Cheers,
Louis.
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #592842 is a reply to message #592836] |
Wed, 11 August 2010 13:28 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 11.08.10 13.17, Louis Rose wrote:
> Quote:
>> > o References to model elements stored in a separate file use an EMF URI.
>>
>> Interesting! How is this used?
>
>
> To specify a reference value, the identifier can be defined in the
> current file (the default usage), or an EMF URI (to reference a model
> element stored in a different model). For example:
>
> Person "me" {
> friends: Person "you", Person
> " platform:/resource/another.project/models/People.model#//@co ntents.0 "
> }
>
> Person "you {}
>
> This uses the EMF URI syntax described here:
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
Nice! Since it's possible to customize the fragment part (the part after
the '#') by specializing the resource implementation, you can make the
syntax a bit nicer, e.g. support identifiers and keys. Is the URI
resolved with the current model's URI as the base? If so, the URI to
files "nearby" could be relative and significantly shorter.
> On a related note, Epsilon HUTN has a pretty comprehensive set of
> acceptance tests, which demonstrate the features of the implementation.
> They're stored in our Subversion repository, and can be viewed online here:
Thanks!
I'll be trying out the other Epsilon languages soon, so there will
likely be more questions from me ;-)
Hallvard
|
|
|
| Re: [HUTN] Difference between the implementation and the HUTN specification [message #592861 is a reply to message #552262] |
Wed, 11 August 2010 17:15 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Hallvard,
Hallvard Traetteberg wrote on Wed, 11 August 2010 09:28
> On 11.08.10 13.17, Louis Rose wrote:
> > Quote:
> >> > o References to model elements stored in a separate file use an EMF URI.
> >>
> >> Interesting! How is this used?
> >
> >
> > To specify a reference value, the identifier can be defined in the
> > current file (the default usage), or an EMF URI (to reference a model
> > element stored in a different model). For example:
> >
> > Person "me" {
> > friends: Person "you", Person
> > " platform:/resource/another.project/models/People.model#//@co ntents.0 "
> > }
> >
> > Person "you {}
> >
> > This uses the EMF URI syntax described here:
> > http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .emf.doc/references/javadoc/org/eclipse/emf/common/util/URI. html
>
> Nice! Since it's possible to customize the fragment part (the part after
> the '#') by specializing the resource implementation, you can make the
> syntax a bit nicer, e.g. support identifiers and keys.
Yes, this will work today with Epsilon HUTN because it uses EMF to parse URIs.
Quote:
> Is the URI
> resolved with the current model's URI as the base? If so, the URI to
> files "nearby" could be relative and significantly shorter.
Currently, the URI has to be absolute, and not relative. However, support for relative URIs sounds like a good idea. Would you file an enhancement request in our Bugzilla? ( https://bugs.eclipse.org/bugs/enter_bug.cgi?product=GMT& component=Epsilon)
Quote:
> I'll be trying out the other Epsilon languages soon, so there will
> likely be more questions from me ;)
Great! Do let us know if you have any further queries or feedback.
Cheers,
Louis.
|
|
| | | | | | |
Goto Forum:
Current Time: Tue Apr 16 05:52:19 GMT 2024
Powered by FUDForum. Page generated in 0.33857 seconds |
] 
Search
Help
Register
Login
Home
