Home » Modeling » OCL » How to define an OCL constraint for a modelElements association relationship
|
| 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   |
 Ed Willink
Messages: 7655
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 #833377 is a reply to message #833370] |
Sat, 31 March 2012 11:28 |
Elvis Dowson
Messages: 65
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.
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 |
Ed Willink
Messages: 7655
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 |
Elvis Dowson
Messages: 65
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 |
Ed Willink
Messages: 7655
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
|
|
|
Goto Forum:
Current Time: Fri Apr 19 23:24:29 GMT 2024
Powered by FUDForum. Page generated in 0.03904 seconds |
] 
Search
Help
Register
Login
Home
