Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » How to define an OCL constraint for a modelElements association relationship
How to define an OCL constraint for a modelElements association relationship [message #832855] Fri, 30 March 2012 17:17 Go to next message
Elvis Dowson is currently offline Elvis Dowson
Messages: 38
Registered: December 2011
Member
Hi,
I have an EMF meta-model diagram, that I developed for a GMF editor.

In the attached meta-model diagram. I have a Workspace object that can contain modelElements. The ModelElement class is an abstract class, and just below it, it is inherited by a Project, DesignRepository and KnowledgeRepository.

How can I define the OCL constrain for the modelElements -> 0..* relationship?

index.php/fa/7701/0/

The OCL constrain annotation could look like this, but I'm not sure how to properly write the derive value

Key = derive
Value = let modelElements : Set(gmfdesigneditor::ModelElement) = self.objects->select(oclIsKindOf(gmfdesigneditor::ModelElement))->collect(oclAsType(gmfdesigneditor::ModelElement))->asSet() in modelElements->symmetricDifference(modelElements.modelElements->asSet())

I think the last few statements are wrong in the above value declaration, i.e. in modelElements->symmetricDifference(modelElements.modelElements->asSet())

Elvis Dowson
Re: How to define an OCL constraint for a modelElements association relationship [message #833023 is a reply to message #832855] Fri, 30 March 2012 21:48 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4087
Registered: July 2009
Senior Member
Hi

Your primary question does not make sense to me:

"How can I define the OCL constrain for the modelElements -> 0..* relationship?"

0..* is the multiplicity of, not the target of, a relationship, and you
do not say how you want to constrain it.

By inspection modelElements.modelElements is wrong since the first
modelElements is a let variable of type
Set(gmfdesigneditor::ModelElement) and there is no
ModelElement.modelElements feature.

You appear to be trying to program an EAnnotation directly. You will
find the OCLinEcore editor helpful; see the tutorial.

Qualified types are inadequately specified in OCL type expressions such
as oclAsType, and consequently inadequately supported in the Ecore/UML
OCL binding. This has been resolved for the new Pivot-binding of OCL in
Juno. You shouldn't need qualified names so this should not be a problem.

Regards

Ed Willink

On 30/03/2012 18:17, Elvis Dowson wrote:
> Hi,
> I have an EMF meta-model diagram, that I developed for a GMF editor.
>
> In the attached meta-model diagram. I have a Workspace object that can contain modelElements. The ModelElement class is an abstract class, and just below it, it is inherited by a Project, DesignRepository and KnowledgeRepository.
>
> How can I define the OCL constrain for the modelElements -> 0..* relationship?
>
>
>
> The OCL constrain annotation could look like this, but I'm not sure how to properly write the derive value
>
> Key = derive
> Value = let modelElements : Set(gmfdesigneditor::ModelElement) = self.objects->select(oclIsKindOf(gmfdesigneditor::ModelElement))->collect(oclAsType(gmfdesigneditor::ModelElement))->asSet() in modelElements->symmetricDifference(modelElements.modelElements->asSet())
>
> I think the last few statements are wrong in the above value declaration, i.e. in modelElements->symmetricDifference(modelElements.modelElements->asSet())
>
> Elvis Dowson
>
Re: How to define an OCL constraint for a modelElements association relationship [message #833029 is a reply to message #833023] Fri, 30 March 2012 22:02 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis Dowson
Messages: 38
Registered: December 2011
Member
Hi Ed,
I want to constrain the modelElements relationship, so that:

a. it refers to either a Project or DesignRepository or KnowledgeRepository element

b. it correctly preserves the hierarchy of a Project model element containing either a DesignRepository or KnowledgeRepository element.

Elvis Dowson
Re: How to define an OCL constraint for a modelElements association relationship [message #833370 is a reply to message #833029] Sat, 31 March 2012 11:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4087
Registered: July 2009
Senior Member
Hi

for a)

In Complete OCL (unchecked)

context Workspace
inv ValidModelElementType: modelElements->forAll(oclIsTypeOf(Project) or
oclIsTypeOf(DesignRepository) or oclIsTypeOf(KnowledgeRepository))

which is pretty klunky and inextensible. Assuming you can have further
ModelElement derivations I would recommend that you introduce an
additional abstract/interface class that reflects the role, such as
Repository, so that you can just do

context Workspace
inv IsRepository: modelElements->forAll(oclIsKindOf(Repository))

for b)

Your comment is meaningless. What is correct/incorrect. A Project can
only contain DesignRepository or KnowledgeRepository elements so a valid
model is inherently plausible. If you have stronger requirements I
recommend modeling them directly, or be very clear about what your
stronger requirements are.

Regards

Ed Willink


On 30/03/2012 23:02, Elvis Dowson wrote:
> Hi Ed,
> I want to constrain the modelElements relationship, so that:
>
> a. it refers to either a Project or DesignRepository or
> KnowledgeRepository element
>
> b. it correctly preserves the hierarchy of a Project model element
> containing either a DesignRepository or KnowledgeRepository element.
>
> Elvis Dowson
Re: How to define an OCL constraint for a modelElements association relationship [message #833377 is a reply to message #833370] Sat, 31 March 2012 11:28 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis Dowson
Messages: 38
Registered: December 2011
Member
Hi,

Edward Willink wrote on Sat, 31 March 2012 13:06

for a)

In Complete OCL (unchecked)

context Workspace
inv ValidModelElementType: modelElements->forAll(oclIsTypeOf(Project) or
oclIsTypeOf(DesignRepository) or oclIsTypeOf(KnowledgeRepository))

which is pretty klunky and inextensible. Assuming you can have further
ModelElement derivations I would recommend that you introduce an
additional abstract/interface class that reflects the role, such as
Repository, so that you can just do

context Workspace
inv IsRepository: modelElements->forAll(oclIsKindOf(Repository))


I do have further ModelElement derivations, for example, a DesignRepository can contain DesignElements (Abstract), which can be of type DesignFolder, Structure and Component, as shown in the following diagram.

index.php/fa/7713/0/

Given this, could you please tell me what OCL is appropriate for the modelElements relationship?

Should I make the OCL specific and mention the additional allowable relationships, for DesignFolder, Structure and Component, as shown below:

context Workspace
inv ValidModelElementType: modelElements->forAll(oclIsTypeOf(Project) or 
oclIsTypeOf(DesignRepository) or oclIsTypeOf(KnowledgeRepository)) or
oclIsTypeOf(DesignFolder) or oclIsTypeOf(Structure)) or oclIsTypeOf(Component))


or should I make the OCL a bit more generic, and additional refer to only the generic DesignElement abstract class, as shown below:

context Workspace
inv ValidModelElementType: modelElements->forAll(oclIsTypeOf(Project) or 
oclIsTypeOf(DesignRepository) or oclIsTypeOf(KnowledgeRepository)) or
oclIsTypeOf(DesignElements)


Elvis Dowson

[Updated on: Sat, 31 March 2012 11:39]

Report message to a moderator

Re: How to define an OCL constraint for a modelElements association relationship [message #833386 is a reply to message #833377] Sat, 31 March 2012 11:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4087
Registered: July 2009
Senior Member
Hi

I really do not understand the problem.

You have some plausible models that mostly prevent stupid things
happening. I suggested the Repository interface to capture a common
behaviour, but if you have control you can get the hierarchy right in
the design without needing OCL to enforce it.

What are you actually trying to protect against?

Regards

Ed Willink

On 31/03/2012 12:28, Elvis Dowson wrote:
> Hi,
>
> Edward Willink wrote on Sat, 31 March 2012 13:06
>> for a)
>>
>> In Complete OCL (unchecked)
>>
>> context Workspace
>> inv ValidModelElementType: modelElements->forAll(oclIsTypeOf(Project) or
>> oclIsTypeOf(DesignRepository) or oclIsTypeOf(KnowledgeRepository))
>>
>> which is pretty klunky and inextensible. Assuming you can have further
>> ModelElement derivations I would recommend that you introduce an
>> additional abstract/interface class that reflects the role, such as
>> Repository, so that you can just do
>>
>> context Workspace
>> inv IsRepository: modelElements->forAll(oclIsKindOf(Repository))
>
> I do have further ModelElement derivations, for example, a DesignRepository can contain DesignElements (Abstract), which can be of type DesignFolder, Structure and Component, as shown in the following diagram.
>
>
>
> Given this, could you please tell me what OCL is appropriate for the modelElements relationship?
>
> Elvis Dowson
>
Re: How to define an OCL constraint for a modelElements association relationship [message #833410 is a reply to message #833386] Sat, 31 March 2012 12:37 Go to previous messageGo to next message
Elvis Dowson is currently offline Elvis Dowson
Messages: 38
Registered: December 2011
Member
Hi Ed,

Edward Willink wrote on Sat, 31 March 2012 13:41

Hi
I really do not understand the problem.

You have some plausible models that mostly prevent stupid things
happening. I suggested the Repository interface to capture a common
behaviour, but if you have control you can get the hierarchy right in
the design without needing OCL to enforce it.

What are you actually trying to protect against?


The problem that I have, is one of having a fundamental understanding of what OCL can be used for, for developing GMF-based diagram editors based on Ecore models.

If I were to create a simple Ecore model, a default Editor, and instantiate objects, one has to manually set the relationships between model objects.

My first impression, while reading the book 'Eclipse Modeling Project: A Domain-Specific Language Toolkit', after going through the MindMap example, section 3.3.2 page 41, for implementing a derived reference using OCL,
was that OCL could be used to automatically set the relationships between model elements.

In my example editor, what I'd like to achieve is, if I were to create a Workspace, and then a DesignRepository and a KnowledgeRepository, the Workspace element's modelElements relationship should automatically set its reference to the newly created DesignRepository and KnowledgeRepository.

Best regards,

Elvis Dowson

[Updated on: Sat, 31 March 2012 12:38]

Report message to a moderator

Re: How to define an OCL constraint for a modelElements association relationship [message #833466 is a reply to message #833410] Sat, 31 March 2012 14:31 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4087
Registered: July 2009
Senior Member
Hi

Thanks for the background. That book is still in my in-tray. The part
you reference is not wrong but is seriously out of date (printed 2009);
why use an 'assembler' approach when you can use a 'high level language'?

In the Helios release, June 2010, EMF added
invocation/setting/validation delegates which are exploited by OCL to
make annotations work without any handwritten Java. OCL added the
OCLinEcore Xtext-based editor to allow OCL embedded in Ecore to be
edited directly with the added benefit of syntax checking; the Indigo
release added semantic checking.

OCL should be used to express constraints that cannot be captured by the
implicit constraints associated with relationship multiplicities, types
and inheritance. OCL can be used to narrow the implicit constraints, but
it is much better to get the model right, since very few tools will do
symbolic analysis of OCL constraints to discover that a model that says
A.z can contain Y instances is actually constrained to only have Z
instances.

So you might have an OCL constraint to check that:

a name is a valid Java identifier
the modified date is not earlier than the created date
uid is unique throughout the model
a component is not a sub-component of itself
....


In your specific case perhaps

Recommended workflow if you like pictures:

Edit xxx.ecore, xxx.ecorediag with Ecore Diagram
Edit xxx.ecore with OCLinEcore editor to add the OCL.

and you might end up with

import ecore : 'http://www.eclipse.org/emf/2002/Ecore#/';

package elvis : pfx = 'platform:/resource/Temp/elvis.ecore'
{
class Workspace
{
invariant UniqueIds: objects->isUnique(uid);
attribute name : String;
attribute location : String;
property objects : elvis::BaseElement[*] { ordered composes };
property modelElements : elvis::ModelElement[*] {
ordered,derived,volatile }
{
derivation:
objects->select(oclIsKindOf(ModelElement)).oclAsType(ModelElement)->asOrderedSet();
}
}
class BaseElement
{
invariant IsIdentifier: name.matches('[A-Za-z][0-9A-Za-z]*');
-- invariant Causal: modified >= created;
attribute name : String;
attribute uid : String;
attribute created : ecore::EDate[?] { ordered };
attribute modified : ecore::EDate[?] { ordered };
}
class ModelElement extends elvis::BaseElement;
class DesignRepository extends elvis::ModelElement
{
property designElements : elvis::DesignElement[*] { ordered
composes };
}
class DesignElement extends elvis::ModelElement;
class DesignFolder extends elvis::DesignElement;
class Component extends elvis::DesignElement
{
invariant ACyclic: self->closure(parent)->excludes(self);
property subcomponents#parent : elvis::Component[*] { ordered };
property parent#subcomponents : elvis::Component[?] { ordered };
}
class Structure extends elvis::DesignElement;
}

in which I've changed modelElements to a derived property with an OCL
definition; perhaps this is what you meant.

[regex matching is new in JunoM6. EDate comparison doesn't seem to work;
will investigate.]

M6 also introduces a selectByKind that makes the double type in
select(oclIsKindOf(ModelElement)).oclAsType(ModelElement) unnecessary.

Regards

Ed Willink

On 31/03/2012 13:37, Elvis Dowson wrote:
> Hi Ed,
>
> Edward Willink wrote on Sat, 31 March 2012 13:41
>> Hi
>> I really do not understand the problem.
>>
>> You have some plausible models that mostly prevent stupid things
>> happening. I suggested the Repository interface to capture a common
>> behaviour, but if you have control you can get the hierarchy right in
>> the design without needing OCL to enforce it.
>>
>> What are you actually trying to protect against?
>
>
> The problem that I'm facing is one having a fundamental understanding
> of what OCL can be used for, when developing GMF-based diagram
> editors, based on Ecore models.
>
> If I were to create a simple Ecore model, a default Editor, and
> instantiate objects, one has to manually set the relationships between
> model objects.
>
> My first impression, while reading the book 'Eclipse Modeling Project:
> A Domain-Specific Language Toolkit', after going through the MindMap
> example, section 3.3.2 page 41, for implementing a derived reference
> using OCL,
> was that OCL could be used to automatically set the relationships
> between model elements.
>
> In my example editor, what I'd like to achieve is, if I were to create
> a Workspace, and then a DesignRepository and a KnowledgeRepository,
> the Workspace element's modelElements relationship should
> automatically set its reference to the newly created DesignRepository
> and KnowledgeRepository.
>
> Best regards,
>
> Elvis Dowson
Previous Topic:OCL AST
Next Topic:problems about EMF Incubating components
Goto Forum:
  


Current Time: Tue Oct 21 13:56:19 GMT 2014

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

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