|
| Re: [OCLinEcore] Possibility of defining an attribute as a list of list [message #558538 is a reply to message #558438] |
Mon, 13 September 2010 12:06   |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Simon,
Remember that the files you are editing mixes your ecore model
definition with the constraints you want to add to them. So
>
> property parallelTransitions : Set(Set(Transition));
>
This is not valid. You are defining a class of your model, and the OCL
Set type is not a valid type of your ecore model. So here, you have to
deal with what emf types offers you (helped in this case by the textual
OCLInEcore editor): the EMF types or the types you create in your model.
>
> However, I only got this working:
>
> property parallelTransitions : ParallelTransition[*];
>
> class ParallelTRansition {
> property transitions : Transition[*];
> }
>
> But this is quite a workaround as the additional data structures have to
> be created each time the transition data changes ....
In this case, you always have to deal with EMF its capabilities, it's
not a problem of OCL. If you don't need to serialize the
parallelTransitions, and just need the generated Java API to be managed
prortgamatically, you could try the attribute EEList:
attribute parallelTransitions : ecore_0::EEList<?>[*] { transient };
Of course you'd lose the type (Transition) of your property, without any
chance to serialize your parallel transitions, so it's not probably very
useful.
Otherwise, you will need other modeling mechanisms as the one you have
mentioned. You may want to forward the question to the EMF newsgroup to
ask the EMF's gurus about the better solution to this.
> I was only able to do this using generics. Is there another way, as
> generics are not supported by OCL or QVTo or Acceleo?
Note that although OCL language doesn't support generics in the
constraints, you could still create your EMF model using generics when
needed, as long as, you don't require to include the use of the generic
type inside the OCL constraint. Look at the following simple example
I've just tested:
import ecore_0 : 'http://www.eclipse.org/emf/2002/Ecore#/';
package Test : Test = 'http://test'
{
class Animal;
class Pork extends Animal;
class Cow extends Animal;
class GroupOfAnimals<A> extends Animal
{
property animal : A[*];
operation isAGroupOfCows() : Boolean[1]
{
body: animal->forAll(oclIsTypeOf(Cow));
}
}
class Farm
{
property content : Animal[*] { composes };
}
}
In our farm, you may create a SetOfAnimals, which refers to several
animals. The "isAGroupOfCows()" operation only evaluates to false if
your group contains something different to a cow.
Regards,
Adolfo.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02968 seconds
] 
Search
Help
Register
Login
Home
