|
|
| Re: OCL for InstanceSpecifications on M1 [message #722155 is a reply to message #721237] |
Sun, 04 September 2011 19:10   |
 Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Ed,
thanks for your answer.
>OCL doesn't really care about M levels. If classes have
>constraints/expressions they can be exploited when validating/evaluating
>instances.
Well, that's indeed the theory and good if Eclipse OCL support this kind of
constraint checking. But I was not sure, since the UML InstanceSpecification
mechanism is sort of indirect instances (compared to the instance
specification of the M-levels), where the classifier of an instancespec is
directly defined via the classifier-association.
>You are using UML, and it was only just before Indigo that I discovered
>that the UML to Ecore conversion used a distinct EAnnotation source URI to
>the Ecore delegates URI and so UML-derived Ecore did not validate. I
>upgraded the OCL support for UML to translate the 'old' URI so that in
>principle constraints defined in a UML meta-model could work for instances
>of corresponding Ecore meta-model elements. I cannot say that this has been
>very thoroughly tested. It's really all waiting till I have time to enhance
>the OCLinEcore syntax sufficiently to justify the rename to UnifiedOCL that
>supports either Ecore or UML meta-models. (The OCLinEcore and Xtext OCL
>Console will already load a UML meta-model). You may need to do a load and
>save of the UML-derived *.ecore file with the Indigo OCLinEcore editor in
>order to get the translation that then allows genmodel to work correctly.
I do not understand either the problem you described or/and the solution you
presented. All I want to do is to check whether a given UML
InstanceSpecifications comply with rules defined in an external OCL
document. Is this possible?
Timothy
"Ed Willink" schrieb im Newsbeitrag news:j3ng53$ieg$1@news.eclipse.org...
Hi
It should work:
OCL doesn't really care about M levels. If classes have
constraints/expressions they can be exploited when validating/evaluating
instances.
But:
You are using UML, and it was only just before Indigo that I discovered
that the UML to Ecore conversion used a distinct EAnnotation source URI
to the Ecore delegates URI and so UML-derived Ecore did not validate. I
upgraded the OCL support for UML to translate the 'old' URI so that in
principle constraints defined in a UML meta-model could work for
instances of corresponding Ecore meta-model elements. I cannot say that
this has been very thoroughly tested. It's really all waiting till I
have time to enhance the OCLinEcore syntax sufficiently to justify the
rename to UnifiedOCL that supports either Ecore or UML meta-models. (The
OCLinEcore and Xtext OCL Console will already load a UML meta-model).
You may need to do a load and save of the UML-derived *.ecore file with
the Indigo OCLinEcore editor in order to get the translation that then
allows genmodel to work correctly.
Regards
Ed Willink
On 01/09/2011 09:30, Timothy Marc wrote:
> Hi all,
>
> this might be a silly question, but I'm really not sure about the answer
> (maybe I got something wrong when talking about instances at M1 level):
>
> I need to create InstanceSpecifications of a particular classifier (mostly
> signal and class) at M1 level. So I use the well-known
> InstanceSpecification element provided by UML2 Superstructure for the
> in-model instantiation of classifier.
>
> Let's construct a simple example:
>
> Class A{
> + attA : Integer [0..1]
> }
>
> Now, assume there some OCL constraints applied on the classifier for which
> I have to create the InstanceSpecification like
>
> context ClassA
> inv attA: self.attA > 0 and self.attA <= 10
>
> To check whether the constraint works, I create two
> InstanceSpecifications:
>
> ins1:ClassA{
> slot -> attA = LiteralInteger(value=-5)
> }
>
> insValid:ClassA{
> slot -> attA = LiteralInteger(value=5)
> }
>
> Will the OCL engine complain about the first InstanceSpecification that do
> not comply with the restriction given by the constraint? I have really no
> idea whether the Eclipse OCL is aware of InstanceSpecification as in-model
> instances at the same M-level (M1) where the defining context is located
> as well.
>
> Thanks for a nice answer.
>
> Timothy
|
|
|
| Re: OCL for InstanceSpecifications on M1 [message #722261 is a reply to message #722155] |
Mon, 05 September 2011 07:34 |
Ed Willink
Messages: 5925
Registered: July 2009 |
Senior Member |
|
|
Hi
I'm at a loss how to help, since you seem to be looking for problems
without understanding solutions and without presenting any candidate
executable solution for assessment.
As far as I can see, for you, an InstanceSpecification is just a
meta-model element with constraints that you wish to evaluate on a
model. So what is the problem? OCL supports constraints on meta-models.
It is not relevant whether InstanceSpecification is part of the UML or not.
Regards
Ed Willink
On 04/09/2011 20:10, Timothy Marc wrote:
> Ed,
>
> thanks for your answer.
>
>> OCL doesn't really care about M levels. If classes have
>> constraints/expressions they can be exploited when
>> validating/evaluating instances.
> Well, that's indeed the theory and good if Eclipse OCL support this
> kind of constraint checking. But I was not sure, since the UML
> InstanceSpecification mechanism is sort of indirect instances
> (compared to the instance specification of the M-levels), where the
> classifier of an instancespec is directly defined via the
> classifier-association.
>
>> You are using UML, and it was only just before Indigo that I
>> discovered that the UML to Ecore conversion used a distinct
>> EAnnotation source URI to the Ecore delegates URI and so UML-derived
>> Ecore did not validate. I upgraded the OCL support for UML to
>> translate the 'old' URI so that in principle constraints defined in a
>> UML meta-model could work for instances of corresponding Ecore
>> meta-model elements. I cannot say that this has been very thoroughly
>> tested. It's really all waiting till I have time to enhance the
>> OCLinEcore syntax sufficiently to justify the rename to UnifiedOCL
>> that supports either Ecore or UML meta-models. (The OCLinEcore and
>> Xtext OCL Console will already load a UML meta-model). You may need
>> to do a load and save of the UML-derived *.ecore file with the Indigo
>> OCLinEcore editor in order to get the translation that then allows
>> genmodel to work correctly.
>
> I do not understand either the problem you described or/and the
> solution you presented. All I want to do is to check whether a given
> UML InstanceSpecifications comply with rules defined in an external
> OCL document. Is this possible?
>
> Timothy
>
> "Ed Willink" schrieb im Newsbeitrag
> news:j3ng53$ieg$1@news.eclipse.org...
>
> Hi
>
> It should work:
>
> OCL doesn't really care about M levels. If classes have
> constraints/expressions they can be exploited when validating/evaluating
> instances.
>
> But:
>
> You are using UML, and it was only just before Indigo that I discovered
> that the UML to Ecore conversion used a distinct EAnnotation source URI
> to the Ecore delegates URI and so UML-derived Ecore did not validate. I
> upgraded the OCL support for UML to translate the 'old' URI so that in
> principle constraints defined in a UML meta-model could work for
> instances of corresponding Ecore meta-model elements. I cannot say that
> this has been very thoroughly tested. It's really all waiting till I
> have time to enhance the OCLinEcore syntax sufficiently to justify the
> rename to UnifiedOCL that supports either Ecore or UML meta-models. (The
> OCLinEcore and Xtext OCL Console will already load a UML meta-model).
> You may need to do a load and save of the UML-derived *.ecore file with
> the Indigo OCLinEcore editor in order to get the translation that then
> allows genmodel to work correctly.
>
> Regards
>
> Ed Willink
>
> On 01/09/2011 09:30, Timothy Marc wrote:
>> Hi all,
>>
>> this might be a silly question, but I'm really not sure about the
>> answer (maybe I got something wrong when talking about instances at
>> M1 level):
>>
>> I need to create InstanceSpecifications of a particular classifier
>> (mostly signal and class) at M1 level. So I use the well-known
>> InstanceSpecification element provided by UML2 Superstructure for the
>> in-model instantiation of classifier.
>>
>> Let's construct a simple example:
>>
>> Class A{
>> + attA : Integer [0..1]
>> }
>>
>> Now, assume there some OCL constraints applied on the classifier for
>> which I have to create the InstanceSpecification like
>>
>> context ClassA
>> inv attA: self.attA > 0 and self.attA <= 10
>>
>> To check whether the constraint works, I create two
>> InstanceSpecifications:
>>
>> ins1:ClassA{
>> slot -> attA = LiteralInteger(value=-5)
>> }
>>
>> insValid:ClassA{
>> slot -> attA = LiteralInteger(value=5)
>> }
>>
>> Will the OCL engine complain about the first InstanceSpecification
>> that do not comply with the restriction given by the constraint? I
>> have really no idea whether the Eclipse OCL is aware of
>> InstanceSpecification as in-model instances at the same M-level (M1)
>> where the defining context is located as well.
>>
>> Thanks for a nice answer.
>>
>> Timothy
>
|
|
|
| Re: OCL for InstanceSpecifications on M1 [message #726685 is a reply to message #722155] |
Mon, 19 September 2011 08:47 |
Peter Mising name
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Timothy,
there is no problem to do what you want. I use OCL in this way.
Hava a look at the following Code:
Helper helper = getOcl().createOCLHelper();
if (contextElement != null && contextElement instanceof
InstanceSpecification) {
helper.setInstanceContext(contextElement);
String oclCon="here your ocl constraint";
Constraint inv = helper.createInvariant(oclCon);
Query query = getOcl().createQuery(inv);
boolean result = query.check(contextElement);
}
Peter
Am So 04.09.11 21:10, schrieb Timothy Marc:
> Ed,
>
> thanks for your answer.
>
>> OCL doesn't really care about M levels. If classes have
>> constraints/expressions they can be exploited when
>> validating/evaluating instances.
> Well, that's indeed the theory and good if Eclipse OCL support this kind
> of constraint checking. But I was not sure, since the UML
> InstanceSpecification mechanism is sort of indirect instances (compared
> to the instance specification of the M-levels), where the classifier of
> an instancespec is directly defined via the classifier-association.
>
>> You are using UML, and it was only just before Indigo that I
>> discovered that the UML to Ecore conversion used a distinct
>> EAnnotation source URI to the Ecore delegates URI and so UML-derived
>> Ecore did not validate. I upgraded the OCL support for UML to
>> translate the 'old' URI so that in principle constraints defined in a
>> UML meta-model could work for instances of corresponding Ecore
>> meta-model elements. I cannot say that this has been very thoroughly
>> tested. It's really all waiting till I have time to enhance the
>> OCLinEcore syntax sufficiently to justify the rename to UnifiedOCL
>> that supports either Ecore or UML meta-models. (The OCLinEcore and
>> Xtext OCL Console will already load a UML meta-model). You may need to
>> do a load and save of the UML-derived *.ecore file with the Indigo
>> OCLinEcore editor in order to get the translation that then allows
>> genmodel to work correctly.
>
> I do not understand either the problem you described or/and the solution
> you presented. All I want to do is to check whether a given UML
> InstanceSpecifications comply with rules defined in an external OCL
> document. Is this possible?
>
> Timothy
>
> "Ed Willink" schrieb im Newsbeitrag news:j3ng53$ieg$1@news.eclipse.org...
>
> Hi
>
> It should work:
>
> OCL doesn't really care about M levels. If classes have
> constraints/expressions they can be exploited when validating/evaluating
> instances.
>
> But:
>
> You are using UML, and it was only just before Indigo that I discovered
> that the UML to Ecore conversion used a distinct EAnnotation source URI
> to the Ecore delegates URI and so UML-derived Ecore did not validate. I
> upgraded the OCL support for UML to translate the 'old' URI so that in
> principle constraints defined in a UML meta-model could work for
> instances of corresponding Ecore meta-model elements. I cannot say that
> this has been very thoroughly tested. It's really all waiting till I
> have time to enhance the OCLinEcore syntax sufficiently to justify the
> rename to UnifiedOCL that supports either Ecore or UML meta-models. (The
> OCLinEcore and Xtext OCL Console will already load a UML meta-model).
> You may need to do a load and save of the UML-derived *.ecore file with
> the Indigo OCLinEcore editor in order to get the translation that then
> allows genmodel to work correctly.
>
> Regards
>
> Ed Willink
>
> On 01/09/2011 09:30, Timothy Marc wrote:
>> Hi all,
>>
>> this might be a silly question, but I'm really not sure about the
>> answer (maybe I got something wrong when talking about instances at M1
>> level):
>>
>> I need to create InstanceSpecifications of a particular classifier
>> (mostly signal and class) at M1 level. So I use the well-known
>> InstanceSpecification element provided by UML2 Superstructure for the
>> in-model instantiation of classifier.
>>
>> Let's construct a simple example:
>>
>> Class A{
>> + attA : Integer [0..1]
>> }
>>
>> Now, assume there some OCL constraints applied on the classifier for
>> which I have to create the InstanceSpecification like
>>
>> context ClassA
>> inv attA: self.attA > 0 and self.attA <= 10
>>
>> To check whether the constraint works, I create two
>> InstanceSpecifications:
>>
>> ins1:ClassA{
>> slot -> attA = LiteralInteger(value=-5)
>> }
>>
>> insValid:ClassA{
>> slot -> attA = LiteralInteger(value=5)
>> }
>>
>> Will the OCL engine complain about the first InstanceSpecification
>> that do not comply with the restriction given by the constraint? I
>> have really no idea whether the Eclipse OCL is aware of
>> InstanceSpecification as in-model instances at the same M-level (M1)
>> where the defining context is located as well.
>>
>> Thanks for a nice answer.
>>
>> Timothy
>
|
|
|
Powered by
FUDForum. Page generated in 0.02435 seconds
Search
Help
Register
Login
Home
