Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Access parent children relationship from a base class
Access parent children relationship from a base class [message #839495] Sun, 08 April 2012 20:25 Go to next message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi,
I have the following EMF meta-model, where a ModelElement has a parent/children containment relationship.

index.php/fa/7814/0/

What I would like to do is to specify that a DesignFolder should only contain a Structure and a Component.

The parent/children relationship is specified in my ModelElement base class.

My ecore model, as seen in the OCLinEcore Editor looks like this:

class DesignFolder extends DesignElement
    {
        property structures : Structure[*] { ordered composes };
        property components : Component[*] { ordered composes };
    }


How can I specify an OCL constraint to restrict creation of children for a DesignFolder, so that only a Structure or a Component can be instantiated under a DesignFolder?

I do not understand how to reference a property of a base class in a derived class, so that I can explicitly specify OCL constraints for the derived class.

For example, for a Structure element, I should only be able to specify subStructures under the Structure element. If I don't specify any model constraints, I can specify any class that inherits from ModelElement, to be a child of the Structure class, which is something that I want to avoid.

I choose this structure, because I want my GMF diagram to be able to recursively go down, one level to create sub-diagrams for any element that I choose.

Best regards,

Elvis Dowson

[Updated on: Sun, 08 April 2012 20:27]

Report message to a moderator

Re: Access parent children relationship from a base class [message #839733 is a reply to message #839495] Mon, 09 April 2012 05:35 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Elvis

If you only want "a Structure and a Component" then you should specify
exactly that:

class DesignFolder extends DesignElement
{
property structures : Structure[1] { ordered composes };
property components : Component[1] { ordered composes };
}


There is no point using OCL to express what is easily captured by
structure an multiplicities.

If you only want "a Structure or a Component" then you could specify
exactly that with an invariant

class DesignFolder extends DesignElement
{
invariant OnlyOne: structures->size() + components->size() = 1;
property structures : Structure[?] { ordered composes };
property components : Component[?] { ordered composes };
}

which will distinguish a well-formed model once you Validate. You could
arrange for your UI to create a candidate new model, validate it, and
reject the candidate thereby giving your user more timely feedback.

The need for an OCL constraint could again be avoided by:

class DesignFolder extends DesignElement
{
property elements : StructureOrComponent[1] { ordered composes };
}

abstract class StructureOrComponent {}
class Structure extends StructureOrComponent {}
class Component extends StructureOrComponent {}


I don't understand your problem with any ModelElement as Structure
subStructures. Using Java you may add anything to eContents(), but any
attempt to Validate will report the model as ill-formed; this is the
huge difference between modeling, which is typed, and XML, which is
extensible.

Regards

Ed Willink

On 08/04/2012 21:25, Elvis Dowson wrote:
> Hi,
> I have the following EMF meta-model, where a ModelElement has a parent/children containment relationship.
>
>
>
> What I would like to do is to specify that a DesignFolder, should only contain a Structure and a Component.
>
> The parent/children relationship is specified in my ModelElement base class.
>
> My ecore model, as seen in the OCLinEcore Editor looks like this:
>
>
> class DesignFolder extends DesignElement
> {
> property structures : Structure[*] { ordered composes };
> property components : Component[*] { ordered composes };
> }
>
>
> How can I specify an OCL constrain, to restrict creation of children for a DesignFolder, so that only a Structure or a Component can be instantiated, under a DesignFolder?
>
> What I do not understand is how to reference a property of a base class, in a derived class, so that I can explicitly specify OCL constraints on the derived class.
>
> For example, if I take the example further, for a Structure, I should only be able to specify subStructures under the Structure element. If I don't specify any model constraints, I can specify any class that inherits from ModelElement, to be a child of the Structure class, which is something that I want to avoid.
>
> I choose this structure, because I want my GMF diagram to be able to recursively go down, one level to create sub-diagrams for any element that I choose.
>
> Best regards,
>
> Elvis Dowson
>
>
Re: Access parent children relationship from a base class [message #840967 is a reply to message #839733] Tue, 10 April 2012 18:35 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi Ed,
What I would like to know is if it is possible for me to express OCL constraints in terms of parent and children references, as indicated in the ModelElement base class.

In GMF, one of the recommended strategies is to maintain parent children relationship, so by specifying both, the generated code knows both where to store newly created elements and where to retrieve existing elements.

So, instead of individually modeling for a Structure element, a parent and substructures relationship, or for a Component element, a parent and subcomponents relationship, I moved it to the base class, ModelElement, and modeled a generic parent children relationship.

This way, I can double click on any derived model element and open up a new diagram.

At the moment, When I right click on the default EMF generated editor, I have the possibility to instantiate a children of any derived base class from ModelElement. I want to restrict the type of children I can create, depending upon my current location in the knowledge element or design element EMF meta-model hierarchy.

I was wondering if there was a clean way to do this using OCL?

Best regards,

Elvis Dowson
Re: Access parent children relationship from a base class [message #841294 is a reply to message #840967] Wed, 11 April 2012 06:01 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Elvis

A meta-model imposes numerous constraints on the structure of a valid model:
- the vocabulary of names
- the connectivity of objects
- the multiplicities of relationships

Validation of a model against the meta-model reveals whether the model
conforms or not.

Meta-model based tooling may exploit the meta-model to reduce the
opportunities to accidentally or fraudulently create non-conformant
models, however creation is a dynamic activity that is beyond the scope
of the meta-model and so there will often be opportunities to abuse the
intent. In Java and EMF you can use EObject polymorphism to create an
almost arbitrary model, so you must use validation to guarantee
well-formedness.

The constraints that can be expressed structurally are limited, and so
to impose stronger constraints you need a stronger technology such as
OCL, which will give you stronger validation. But few tools will be able
to analyze arbitrary OCL expressions to prevent bad dynamic activity. As
I wrote before it is much easier to to create a hypothesis and validate it.

Use OCL for added strength not for basic capabilities.

Parent-Child relationships are the most basic of EMF's modeled
relationships; perhaps they are so basic that you have overlooked the
container/containment attributes and eContainer(), eContents(). Of
course you can use OCL to intervene at this level, but it just seems to
be crazy to do in OCL what can be done ten times better by the
underlying technology.

It seems that by ignoring EMF's parent/child modeling you have created
your own model parent/child relationships and these create polymorphism
bugs that give you spurious editing alternatives which you want OCL to fix.

As a general rule, if you find yourself fighting a technology, rethink.
Perhaps your usage of the technology is wrong or your choice of
technology is wrong.

Once you get your model right you should find few occasions where the
tooling fails. If these need fixing you could add a parent-specific
filter on the list of candidate children. e.g. a default root implementation

context EModelElement
def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) =
candidates

with overloads where appropriate and an invocation from somewhere in the
GMF editing.

Regards

Ed Willink


On 10/04/2012 19:35, Elvis Dowson wrote:
> Hi Ed,
> What I would like to know is if it is possible for me to
> express OCL constraints in terms of parent and children references, as
> indicated in the ModelElement base class.
>
> In GMF, one of the recommended strategies is to maintain parent
> children relationship, so by specifying both, the generated code knows
> both where to store newly created elements and where to retrieve
> existing elements.
>
> So, instead of individually modeling for a Structure element, a parent
> and substructures relationship, or for a Component element, a parent
> and subcomponents relationship, I moved it to the base class,
> ModelElement, and modeled a generic parent children relationship.
>
> This way, I can double click on any derived model element and open up
> a new diagram.
>
> At the moment, When I right click on the default EMF generated editor,
> I have the possibility to instantiate a children of any derived base
> class from ModelElement. I want to restrict the type of children I can
> create, depending upon my current location in the knowledge element or
> design element EMF meta-model hierarchy.
>
> I was wondering if there was a clean way to do this using OCL?
>
> Best regards,
>
> Elvis Dowson
Re: Access parent children relationship from a base class [message #843217 is a reply to message #841294] Thu, 12 April 2012 21:42 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi Ed,

Edward Willink wrote on Wed, 11 April 2012 08:01

A meta-model imposes numerous constraints on the structure of a valid model:
- the vocabulary of names
- the connectivity of objects
- the multiplicities of relationships

Validation of a model against the meta-model reveals whether the model
conforms or not.


I've done exact that. I always test my meta-model with an example model. The screenshot below shows the sample EMF generator editor. Because a parent-children containment relationship has been defined for my abstract ModelElement base class, I have the possibility to create multiple children of any derived type, in the generated EMF editor.

What I would like to do is to constrain this using OCL, so that under a design folder, knowledge elements do not appear (e.g. Knowledge Folder, Design Rule, etc).

I think its good abstraction, from a modeling stand point, because, unlike the previous EMF meta-model that I described in a related thread, I do not have explicit parent-subStructures and parent-subComponents containment relationships specified for a Structure and a Component model element. It is all now in the ModelElement base class, and I just want to gain access to this containment reference handle, so that I can constrain it in my derived base class. I mean, if I was coding in C++ or Java, surely I would be able to access this property, ... does this mean that with EMF, I cannot?

index.php/fa/7873/0/


Edward Willink wrote on Wed, 11 April 2012 08:01

Meta-model based tooling may exploit the meta-model to reduce the
opportunities to accidentally or fraudulently create non-conformant
models, however creation is a dynamic activity that is beyond the scope
of the meta-model and so there will often be opportunities to abuse the
intent. In Java and EMF you can use EObject polymorphism to create an
almost arbitrary model, so you must use validation to guarantee
well-formedness.

The constraints that can be expressed structurally are limited, and so
to impose stronger constraints you need a stronger technology such as
OCL, which will give you stronger validation. But few tools will be able
to analyze arbitrary OCL expressions to prevent bad dynamic activity. As
I wrote before it is much easier to to create a hypothesis and validate it.

Use OCL for added strength not for basic capabilities.

Parent-Child relationships are the most basic of EMF's modeled
relationships; perhaps they are so basic that you have overlooked the
container/containment attributes and eContainer(), eContents(). Of
course you can use OCL to intervene at this level, but it just seems to
be crazy to do in OCL what can be done ten times better by the
underlying technology.

It seems that by ignoring EMF's parent/child modeling you have created
your own model parent/child relationships and these create polymorphism
bugs that give you spurious editing alternatives which you want OCL to fix.


The following diagram shows the Ecore kernel model diagram:
index.php/fa/7874/0/

There is an EReference class, but if I were to consider my DesignFolder model element, how would I constraint it by only allowing a Structure or Component to be created under a design folder? i.e. the target of a children relationship should only be either a Structure or a Component. The problem that I am facing is, I don't know what OCL syntax to use, to access and specify the children relationship, inherited from the ModelElement abstract base class.

Edward Willink wrote on Wed, 11 April 2012 08:01

As a general rule, if you find yourself fighting a technology, rethink.
Perhaps your usage of the technology is wrong or your choice of
technology is wrong.

Once you get your model right you should find few occasions where the
tooling fails. If these need fixing you could add a parent-specific
filter on the list of candidate children. e.g. a default root implementation

context EModelElement
def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) =
candidates

with overloads where appropriate and an invocation from somewhere in the
GMF editing.


I'm reading the DSL book, and trying to follow the recommendations of the authors.
page 521, section 11.3.1, Eclipse Modeling Project - A Domain-Specific Language Toolkit - Addison Wesley - 2009

In some models, you might find it necessary to specify both the Containment Feature and a Children Feature for a Top Node Reference element. By specifying both, the generated code knows both where to store newly created elements and where to retrieve existing elements.


They have a bunch of simple examples, but the inheritance hierarchy is not very deep, mine isn't that deep either just 3 levels.

See the following EMF meta-model diagram for a Requirements Editor:
index.php/fa/7875/0/

The advantage of specifying it in this way, for GMF, is so that I can partition diagrams, and recursively create sub-nodes for a parent node, much like any UML editor, where you can create a package within a package, unto any level.

In UML editors, once you create a Class, you cannot end up containing a Package, and its this type of constraint that I would like to implement for my meta-model.

Best regards,

Elvis Dowson

[Updated on: Thu, 12 April 2012 21:58]

Report message to a moderator

Re: Access parent children relationship from a base class [message #843514 is a reply to message #843217] Fri, 13 April 2012 05:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

There are often many alternative solutions to a design problem.

An important part of the design is to assess the alternatives with their
distinct trade-offs to select the most satisfactory solution.

IMHO you are pursuing an unwise approach.

You might note that the UML meta-model has an ownedElements property at
its root, which is similar to your approach, but it then uses subset
properties to define class-specific derived ownedXXX properties; OCL is
then used for subtle rather than overt structural constraints.

I have suggested how you could use a filterCandidates OCL predicate to
workaround your problems.

I'm not sure that there is any further advice that I can give.

Regards

Ed Willink




On 12/04/2012 22:42, Elvis Dowson wrote:
> Hi Ed,
>
> Edward Willink wrote on Wed, 11 April 2012 08:01
>> A meta-model imposes numerous constraints on the structure of a valid model:
>> - the vocabulary of names
>> - the connectivity of objects
>> - the multiplicities of relationships
>>
>> Validation of a model against the meta-model reveals whether the model
>> conforms or not.
>
> I've done exact that. I always test my meta-model with an example model. The screenshot below shows the sample EMF generator editor. Because my parent-children containment relationship is specified for my abstract ModelElement base class, I have the possibility to create multiple children of any derived type, in the generated EMF editor.
>
> What I would like to do is to constrain this using OCL, so that under a design folder, knowledge elements do not appear (e.g. Knowledge Folder, Design Rule, etc).
>
> I think its good abstraction, from a modeling stand point, because, unlike the previous EMF meta-model that I described in a related thread, I do not have explicit parent-subStructures and parent-subComponents containment relationships specified for a Structure and a Component model element. It is all now in the ModelElement base class, and I just want to gain access to this containment reference handle, so that I can constrain it in my derived base class. I mean, if I was coding in C++ or Java, surely I would be able to access this property, ... does this mean that with EMF, I cannot?
>
>
>
>
> Edward Willink wrote on Wed, 11 April 2012 08:01
>> Meta-model based tooling may exploit the meta-model to reduce the
>> opportunities to accidentally or fraudulently create non-conformant
>> models, however creation is a dynamic activity that is beyond the scope
>> of the meta-model and so there will often be opportunities to abuse the
>> intent. In Java and EMF you can use EObject polymorphism to create an
>> almost arbitrary model, so you must use validation to guarantee
>> well-formedness.
>>
>> The constraints that can be expressed structurally are limited, and so
>> to impose stronger constraints you need a stronger technology such as
>> OCL, which will give you stronger validation. But few tools will be able
>> to analyze arbitrary OCL expressions to prevent bad dynamic activity. As
>> I wrote before it is much easier to to create a hypothesis and validate it.
>>
>> Use OCL for added strength not for basic capabilities.
>>
>> Parent-Child relationships are the most basic of EMF's modeled
>> relationships; perhaps they are so basic that you have overlooked the
>> container/containment attributes and eContainer(), eContents(). Of
>> course you can use OCL to intervene at this level, but it just seems to
>> be crazy to do in OCL what can be done ten times better by the
>> underlying technology.
>>
>> It seems that by ignoring EMF's parent/child modeling you have created
>> your own model parent/child relationships and these create polymorphism
>> bugs that give you spurious editing alternatives which you want OCL to fix.
>
>
>
> Edward Willink wrote on Wed, 11 April 2012 08:01
>> As a general rule, if you find yourself fighting a technology, rethink.
>> Perhaps your usage of the technology is wrong or your choice of
>> technology is wrong.
>>
>> Once you get your model right you should find few occasions where the
>> tooling fails. If these need fixing you could add a parent-specific
>> filter on the list of candidate children. e.g. a default root implementation
>>
>> context EModelElement
>> def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) =
>> candidates
>>
>> with overloads where appropriate and an invocation from somewhere in the
>> GMF editing.
>
> Best regards,
>
> Elvis Dowson
Re: Access parent children relationship from a base class [message #845054 is a reply to message #841294] Sat, 14 April 2012 17:40 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi Ed,

Edward Willink wrote on Wed, 11 April 2012 08:01

Once you get your model right you should find few occasions where the
tooling fails. If these need fixing you could add a parent-specific
filter on the list of candidate children. e.g. a default root implementation

context EModelElement
def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) = candidates

with overloads where appropriate and an invocation from somewhere in the
GMF editing.


Bear with me, because this is my first time with OCL, I'm trying to figure out where to enter the above OCL code using the OCLinEcore editor:

This is what my code looks like for the ModelElement:
    abstract class ModelElement extends BaseObject
    {        
        property attachments : Attachment[*] { ordered composes };
        property children#parent : ModelElement[*] { ordered composes };
        property parent#children : ModelElement[?] { ordered };
    }


If I modify the code as follows:
    abstract class ModelElement extends BaseObject
    {
        context EModelElement
        def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) = candidates;
        
        property attachments : Attachment[*] { ordered composes };
        property children#parent : ModelElement[*] { ordered composes };
        property parent#children : ModelElement[?] { ordered };
    }


I get an error: no viable alternative at input 'context'

If I press ctrl+space, there is no code completion for context, so I'm guessing its not an OCL keyword?

Also, there is no 'def' keyword, the code completion suggests 'definition'.

So, I'm having a hard time figuring out what I should exactly type in OCL, into the ecore file.

Best regards,

Elvis Dowson

Re: Access parent children relationship from a base class [message #845513 is a reply to message #845054] Sun, 15 April 2012 05:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The OCL specification defines an expression syntax, and an independent
document syntax - I used a snippet of independent document syntax. An
independent document can extend any class.

Eclipse OCL provides an integration of OCL expressions embedded within
Ecore models using the OCLinEcore editor. This is what you're using.
Completion assist is limited in Indigo and substantially better in Juno.
Embedded OCL can only extend the embedding classes.

So my example in the context of EModelElement affected all derived
classes. If your BaseObject is the base of all your relevant classes,
you want something like:

abstract class ModelElement extends BaseObject
{
operation filterChildCandidates(candidates : EClass[*]) :
EClass[*] {
body: candidates ;
}
property attachments : Attachment[*] { ordered composes };
property children#parent : ModelElement[*] { ordered composes };
property parent#children : ModelElement[?] { ordered };
}

Regards

Ed Willink


On 14/04/2012 18:40, Elvis Dowson wrote:
> Hi Ed,
>
> Edward Willink wrote on Wed, 11 April 2012 08:01
>> Once you get your model right you should find few occasions where the
>> tooling fails. If these need fixing you could add a parent-specific
>> filter on the list of candidate children. e.g. a default root
>> implementation
>>
>> context EModelElement
>> def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) =
>> candidates
>>
>> with overloads where appropriate and an invocation from somewhere in
>> the GMF editing.
>
>
> Bear with me, because this is my first time with OCL, I'm trying to
> figure out where to enter the above OCL code using the OCLinEcore editor:
>
> This is what my code looks like for the ModelElement:
>
> abstract class ModelElement extends BaseObject
> { property attachments : Attachment[*] { ordered
> composes };
> property children#parent : ModelElement[*] { ordered composes };
> property parent#children : ModelElement[?] { ordered };
> }
>
>
> If I modify the code as follows:
>
> abstract class ModelElement extends BaseObject
> {
> context EModelElement
> def: filterChildCandidates(candidates : Set(EClass)) :
> Set(EClass) = candidates;
> property attachments : Attachment[*] { ordered composes };
> property children#parent : ModelElement[*] { ordered composes };
> property parent#children : ModelElement[?] { ordered };
> }
>
>
> I get an error: no viable alternative at input 'context'
>
> If I press ctrl+space, there is no code completion for context, so I'm
> guessing its not an OCL keyword?
> Also, there is no 'def' keyword, the code completion suggests
> 'definition'.
> So, I'm having a hard time figuring out what I should exactly type in
> OCL, into the ecore file.
> Best regards,
>
> Elvis Dowson
>
>
Re: Access parent children relationship from a base class [message #845519 is a reply to message #845054] Sun, 15 April 2012 05:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The OCL specification defines an expression syntax, and an independent
document syntax - I used a snippet of independent document syntax. An
independent document can extend any class.

Eclipse OCL provides an integration of OCL expressions embedded within
Ecore models using the OCLinEcore editor. This is what you're using.
Completion assist is limited in Indigo and substantially better in Juno.
Embedded OCL can only extend the embedding classes.

So my example in the context of EModelElement affected all derived
classes. If your BaseObject is the base of all your relevant classes,
you want something like:

abstract class ModelElement extends BaseObject
{
operation filterChildCandidates(candidates : EClass[*]) :
EClass[*] {
body: candidates ;
}
property attachments : Attachment[*] { ordered composes };
property children#parent : ModelElement[*] { ordered composes };
property parent#children : ModelElement[?] { ordered };
}

Regards

Ed Willink


On 14/04/2012 18:40, Elvis Dowson wrote:
> Hi Ed,
>
> Edward Willink wrote on Wed, 11 April 2012 08:01
>> Once you get your model right you should find few occasions where the
>> tooling fails. If these need fixing you could add a parent-specific
>> filter on the list of candidate children. e.g. a default root
>> implementation
>>
>> context EModelElement
>> def: filterChildCandidates(candidates : Set(EClass)) : Set(EClass) =
>> candidates
>>
>> with overloads where appropriate and an invocation from somewhere in
>> the GMF editing.
>
>
> Bear with me, because this is my first time with OCL, I'm trying to
> figure out where to enter the above OCL code using the OCLinEcore editor:
>
> This is what my code looks like for the ModelElement:
>
> abstract class ModelElement extends BaseObject
> { property attachments : Attachment[*] { ordered
> composes };
> property children#parent : ModelElement[*] { ordered composes };
> property parent#children : ModelElement[?] { ordered };
> }
>
>
> If I modify the code as follows:
>
> abstract class ModelElement extends BaseObject
> {
> context EModelElement
> def: filterChildCandidates(candidates : Set(EClass)) :
> Set(EClass) = candidates;
> property attachments : Attachment[*] { ordered composes };
> property children#parent : ModelElement[*] { ordered composes };
> property parent#children : ModelElement[?] { ordered };
> }
>
>
> I get an error: no viable alternative at input 'context'
>
> If I press ctrl+space, there is no code completion for context, so I'm
> guessing its not an OCL keyword?
> Also, there is no 'def' keyword, the code completion suggests
> 'definition'.
> So, I'm having a hard time figuring out what I should exactly type in
> OCL, into the ecore file.
> Best regards,
>
> Elvis Dowson
>
>
Re: Access parent children relationship from a base class [message #845567 is a reply to message #843514] Sun, 15 April 2012 07:05 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi Ed,
Thanks for your earlier reply on where to define the OCL constraints. I think I'm beginning to understand this. You can embed OCL directly in the ecore model or in a separate text file. The OCL constraints that you were writing were so far, related to specifying those constraints in a separate text file.

I just found a wiki that describes how to do this here:
http://wiki.eclipse.org/EMF/Validation/Recipes

Edward Willink wrote on Fri, 13 April 2012 07:22

You might note that the UML meta-model has an ownedElements property at
its root, which is similar to your approach, but it then uses subset
properties to define class-specific derived ownedXXX properties; OCL is
then used for subtle rather than overt structural constraints.


Please do correct my interpretation of what you're trying to tell me here... you're saying that I should create additional containment properties for each class in my application's EMF meta-model, and subtly refine it using OCL?

And you're recommending that I apply the filterChildCandidates on the ModelElement base class, so that it doesn't directly contribute the base element containment relationship, to the derived classes that have similar owner/ownedXXX containment relationships?

I went through the UML Infrastructure 2.4.1 specification yesterday, and have found the ownedXXX containment relationships that you referred to earlier.

index.php/fa/7896/0/

index.php/fa/7897/0/

index.php/fa/7898/0/

Best regards,

Elvis Dowson


[Updated on: Sun, 15 April 2012 07:07]

Report message to a moderator

Re: Access parent children relationship from a base class [message #845580 is a reply to message #845567] Sun, 15 April 2012 07:23 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The EMFv support was one of the earlier attempts at OCL intregration;
I'm not sure that bit rot hasn't overtaken it; certainly EMF delegates
are much more powerful.

You will find that the CompleteOCLEObjectValidator eliminates most of
the difficulties.

I've added http://wiki.eclipse.org/EMF/Validation/Recipes to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=376701 for review during
the Juno RC documentation phase.

Regards

Ed Willink

On 15/04/2012 08:05, Elvis Dowson wrote:
> Hi Ed,
> Thanks for your earlier reply on where to define the OCL constraints. I think I'm beginning to understand this. You can embed OCL directly in the ecore model or in a separate text file. The OCL constraints that you were writing were so far, related to specifying those constraints in a separate text file.
>
> I just found a wiki that describes how to do this here:
> http://wiki.eclipse.org/EMF/Validation/Recipes
>
> Edward Willink wrote on Fri, 13 April 2012 07:22
>> You might note that the UML meta-model has an ownedElements property at
>> its root, which is similar to your approach, but it then uses subset
>> properties to define class-specific derived ownedXXX properties; OCL is
>> then used for subtle rather than overt structural constraints.
>
> Please do correct my interpretation of what you're trying to tell me here... :), you're saying that I should create additional containment properties for each class in my application's EMF meta-model, and subtly refine it using OCL?
>
> And you're recommending that I apply the filterChildCandidates on the ModelElement base class, so that it doesn't directly contribute the base element containment relationship, to the derived classes that have similar owner/ownedxxx containment relationships?
>
> I went through the UML Infrastructure 2.4.1 specification yesterday, and have found the ownedXXX containment relationships that you referred to earlier.
>
>
>
>
>
>
>
> Best regards,
>
> Elvis Dowson
>
>
>
Re: Access parent children relationship from a base class [message #845757 is a reply to message #845580] Sun, 15 April 2012 11:47 Go to previous message
Elvis Dowson is currently offline Elvis DowsonFriend
Messages: 65
Registered: December 2011
Member
Hi Ed,
Is there a link to a brief write up, on how to setup my Ecore project, so that it takes advantage of the CompleteOCLEObjectValidator class.

I found two threads, that talk about using the class:
http://www.eclipse.org/forums/index.php/t/286380/
http://www.eclipse.org/forums/index.php/t/217359/

The official documentation is just API related:
http://download.eclipse.org/modeling/mdt/ocl/javadoc/4.0.0/org/eclipse/ocl/examples/xtext/completeocl/validation/CompleteOCLEObjectValidator.html

What I'm not clear about is

a. Is there a way to directly specify in the ecore model, that I want to use the CompleteOCLEObjectValidator class, annotate the ecore model, and then have the genmodel generate all the required plugins automatically, with support for OCL validation using the CompleteOCLEObjectValidator class?

or

b. Do I have to at the moment, manually write a separate extension point plug-in (I haven't done this before), and extend the automatically generated edit domain, edit and editor plugins, to add support for OCL validation using the CompleteOCLEObjectValidator class?

If I could have some pointers to examples for either a or b, using the CompleteOCLEObjectValidator class, it would help me get started.

Best regards,

Elvis Dowson
Previous Topic:Problem when using ereference to another registered package
Next Topic:Using CompleteOCLEObjectValidator to validate Ecore model using OCL constraints defined in text file
Goto Forum:
  


Current Time: Thu Mar 28 13:26:43 GMT 2024

Powered by FUDForum. Page generated in 0.06769 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top