Home » Modeling » Epsilon » EVL constraints over instance pairs/triples/etc
| EVL constraints over instance pairs/triples/etc [message #10512] |
Mon, 02 February 2009 14:28  |
 No real name
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi there,
In EVL is it possible to define constraints whose context is a
pair/triple/etc of model elements?
I have a situation where it would be good to validate a constraint of the
form:
context X {
constraint CheckXPair {
check {
var otherX := MyModel!X.all.select(i | not(i = self));
// some check involving self and otherX ...
}
message : 'Error'
}
}
And so, we're doing a check for each pair of instances of X. However, I
guess when the rule is being evaluated, then each pair of instances will
be evaluated twice. E.g., if x1 and x2 are instances of X, then the rule
would be evaluated when self is x1, and otherX is x2; and the rule would
also be evaluated when self is x2, and otherX is x1. The occurrence of two
evaluations per pair leads to redundant checking in my case, and so being
able to restrict this (to sets of instances) would be great. Do you have
any suggestions? I may be asking something misguided so apologies in
advance.
In general, it would seem quite handy and natural to be able to express a
constraint for n-tuples of instances, e.g., for pairs/triples of
instances. This though, would give rise to a difficulty when referring to
the context, self, directly; but perhaps it could be referenced via a
Collection called self, e.g., self(0), denoting self.at(0), self(1), etc?
Best,
Edd
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10545 is a reply to message #10512] |
Mon, 02 February 2009 14:55  |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
You can avoid the duplicate error messages by using extended properties
(see
http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
for a detailed discussion). For example, if you have an ECore model and
you want to check for duplicate names between EClasses, you can use the
following constraint:
context EClass {
constraint CheckUniqueName {
guard : not self.~checked.isDefined()
check {
var others := EClass.all.select(c|c.name = self.name and c <> self);
if (others.size() > 0) {
for (other in others) {
other.~checked := true;
}
return false;
}
else {
return true;
}
}
message : 'Duplicate name ' + self.name
}
}
So, when you find a duplicate, you create an extended property
(~checked) on all the others, and then set an appropriate guard so that
when EVL attempts to run the constraint for the others, they won't pass
through it.
I see your point with defining constraints for n-tuples; my main concern
is that this can easily lead to an explosion of the search space. Also,
most of the times you don't know n; e.g. you may have 3 or 5 classes
with the same name (wrt the previous example)...
Cheers,
Dimitris
Edward Turner wrote:
> Hi there,
>
> In EVL is it possible to define constraints whose context is a
> pair/triple/etc of model elements?
>
> I have a situation where it would be good to validate a constraint of
> the form:
>
> context X {
> constraint CheckXPair {
> check {
> var otherX := MyModel!X.all.select(i | not(i = self));
> // some check involving self and otherX ...
> }
> message : 'Error'
> }
> }
>
> And so, we're doing a check for each pair of instances of X. However, I
> guess when the rule is being evaluated, then each pair of instances will
> be evaluated twice. E.g., if x1 and x2 are instances of X, then the rule
> would be evaluated when self is x1, and otherX is x2; and the rule would
> also be evaluated when self is x2, and otherX is x1. The occurrence of
> two evaluations per pair leads to redundant checking in my case, and so
> being able to restrict this (to sets of instances) would be great. Do
> you have any suggestions? I may be asking something misguided so
> apologies in advance.
>
> In general, it would seem quite handy and natural to be able to express
> a constraint for n-tuples of instances, e.g., for pairs/triples of
> instances. This though, would give rise to a difficulty when referring
> to the context, self, directly; but perhaps it could be referenced via a
> Collection called self, e.g., self(0), denoting self.at(0), self(1), etc?
>
> Best,
>
> Edd
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10578 is a reply to message #10545] |
Mon, 02 February 2009 15:13 |
Eclipse User |
|
|
|
Originally posted by: szchaler.acm.org
Hi Dimitrios,
Just briefly: The "explosion of search space" argument doesn't really
seem to hold. You essentially do a complete search of the (EClass x
EClass) space with your code, too. And you could implement checks on
n-tuples such that they would implicitly use your ~checked solution to
create tuples to be checked. Also, I'm not sure that you really often
don't know n. Your unique name example can essentially be encoded with
n=2. Your code below effectively does this, even though slightly
inefficiently (Note that it would be enough to select the first element
that we come across that has the same name as self, but is not self. If
any such element exists, uniqueness does no longer hold.)
So, it may actually be the case that implementing n-tuples as a language
feature may on average allow for better optimisations (or at least more
consistent optimisations). In any case, it allows for (c)leaner code :-)
Cheers,
Steffen
Dimitris Kolovos wrote:
> Hi Ed,
>
> You can avoid the duplicate error messages by using extended
> properties (see
> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
> for a detailed discussion). For example, if you have an ECore model
> and you want to check for duplicate names between EClasses, you can
> use the following constraint:
>
> context EClass {
>
> constraint CheckUniqueName {
>
> guard : not self.~checked.isDefined()
>
> check {
> var others := EClass.all.select(c|c.name = self.name and c
> <> self);
> if (others.size() > 0) {
> for (other in others) {
> other.~checked := true;
> }
> return false;
> }
> else {
> return true;
> }
> }
>
> message : 'Duplicate name ' + self.name
>
> }
> }
>
> So, when you find a duplicate, you create an extended property
> (~checked) on all the others, and then set an appropriate guard so
> that when EVL attempts to run the constraint for the others, they
> won't pass through it.
>
> I see your point with defining constraints for n-tuples; my main
> concern is that this can easily lead to an explosion of the search
> space. Also, most of the times you don't know n; e.g. you may have 3
> or 5 classes with the same name (wrt the previous example)...
>
> Cheers,
> Dimitris
>
> Edward Turner wrote:
>> Hi there,
>>
>> In EVL is it possible to define constraints whose context is a
>> pair/triple/etc of model elements?
>>
>> I have a situation where it would be good to validate a constraint of
>> the form:
>>
>> context X {
>> constraint CheckXPair {
>> check {
>> var otherX := MyModel!X.all.select(i | not(i = self));
>> // some check involving self and otherX ...
>> }
>> message : 'Error'
>> }
>> }
>>
>> And so, we're doing a check for each pair of instances of X. However,
>> I guess when the rule is being evaluated, then each pair of instances
>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>> the rule would be evaluated when self is x1, and otherX is x2; and
>> the rule would also be evaluated when self is x2, and otherX is x1.
>> The occurrence of two evaluations per pair leads to redundant
>> checking in my case, and so being able to restrict this (to sets of
>> instances) would be great. Do you have any suggestions? I may be
>> asking something misguided so apologies in advance.
>>
>> In general, it would seem quite handy and natural to be able to
>> express a constraint for n-tuples of instances, e.g., for
>> pairs/triples of instances. This though, would give rise to a
>> difficulty when referring to the context, self, directly; but perhaps
>> it could be referenced via a Collection called self, e.g., self(0),
>> denoting self.at(0), self(1), etc?
>>
>> Best,
>>
>> Edd
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10611 is a reply to message #10578] |
Mon, 02 February 2009 15:28 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Please see comments below.
Cheers,
Dimitris
Steffen Zschaler wrote:
> Hi Dimitrios,
>
> Just briefly: The "explosion of search space" argument doesn't really
> seem to hold. You essentially do a complete search of the (EClass x
> EClass) space with your code, too. And you could implement checks on
> n-tuples such that they would implicitly use your ~checked solution to
> create tuples to be checked. Also, I'm not sure that you really often
> don't know n. Your unique name example can essentially be encoded with
> n=2.
So say you have c1, c2 and c3 all with the same name. My point was that
if you set n=2 then you won't get error messages for both c1,c2 and
c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and c1,c2
- while what you want is to just get one message saying "c1,c2,c3 are
all named X".
Your code below effectively does this, even though slightly
> inefficiently (Note that it would be enough to select the first element
> that we come across that has the same name as self, but is not self. If
> any such element exists, uniqueness does no longer hold.)
If it selected only the first then it would know that the constraint had
failed but it wouldn't be able to mark the "others" as "checked" in
order to avoid the extraneous evaluations (and subsequent error messages).
>
> So, it may actually be the case that implementing n-tuples as a language
> feature may on average allow for better optimisations (or at least more
> consistent optimisations). In any case, it allows for (c)leaner code :-)
I agree; I just can't think of a good way to encode this in the general
case. Any further thoughts on syntax/semantics of such an extension to
EVL would be really welcome!
>
> Cheers,
>
> Steffen
>
> Dimitris Kolovos wrote:
>> Hi Ed,
>>
>> You can avoid the duplicate error messages by using extended
>> properties (see
>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>> for a detailed discussion). For example, if you have an ECore model
>> and you want to check for duplicate names between EClasses, you can
>> use the following constraint:
>>
>> context EClass {
>> constraint CheckUniqueName {
>> guard : not self.~checked.isDefined()
>> check {
>> var others := EClass.all.select(c|c.name = self.name and c
>> <> self);
>> if (others.size() > 0) {
>> for (other in others) {
>> other.~checked := true;
>> }
>> return false;
>> }
>> else {
>> return true;
>> }
>> }
>> message : 'Duplicate name ' + self.name
>> }
>> }
>>
>> So, when you find a duplicate, you create an extended property
>> (~checked) on all the others, and then set an appropriate guard so
>> that when EVL attempts to run the constraint for the others, they
>> won't pass through it.
>>
>> I see your point with defining constraints for n-tuples; my main
>> concern is that this can easily lead to an explosion of the search
>> space. Also, most of the times you don't know n; e.g. you may have 3
>> or 5 classes with the same name (wrt the previous example)...
>>
>> Cheers,
>> Dimitris
>>
>> Edward Turner wrote:
>>> Hi there,
>>>
>>> In EVL is it possible to define constraints whose context is a
>>> pair/triple/etc of model elements?
>>>
>>> I have a situation where it would be good to validate a constraint of
>>> the form:
>>>
>>> context X {
>>> constraint CheckXPair {
>>> check {
>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>> // some check involving self and otherX ...
>>> }
>>> message : 'Error'
>>> }
>>> }
>>>
>>> And so, we're doing a check for each pair of instances of X. However,
>>> I guess when the rule is being evaluated, then each pair of instances
>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>> The occurrence of two evaluations per pair leads to redundant
>>> checking in my case, and so being able to restrict this (to sets of
>>> instances) would be great. Do you have any suggestions? I may be
>>> asking something misguided so apologies in advance.
>>>
>>> In general, it would seem quite handy and natural to be able to
>>> express a constraint for n-tuples of instances, e.g., for
>>> pairs/triples of instances. This though, would give rise to a
>>> difficulty when referring to the context, self, directly; but perhaps
>>> it could be referenced via a Collection called self, e.g., self(0),
>>> denoting self.at(0), self(1), etc?
>>>
>>> Best,
>>>
>>> Edd
>>>
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10644 is a reply to message #10545] |
Mon, 02 February 2009 16:09 |
No real name
Messages: 92
Registered: July 2009 |
Member |
|
|
> Hi Ed,
Hia Dimitris,
> You can avoid the duplicate error messages by using extended properties
> (see
> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
> for a detailed discussion).
Thanks for the link, I'd missed that feature of Epsilon. Yep, I should be
able to avoid performing redundant checks using extended properties (in
the case that I mentioned, possibly by attaching Collections to instances).
> I see your point with defining constraints for n-tuples; my main concern
> is that this can easily lead to an explosion of the search space.
Yes, part of my original post mentioned redundant checking, and so it
wouldn't be very nice if I blew up the search space with lots of
redundancy, by checking a constraint over say, 5 instances.
> Also, most of the times you don't know n; e.g. you may have 3 or 5 classes
> with the same name (wrt the previous example)...
Yes I agree in some cases you don't know n. Originally, I'd really only
thought of those modelling cases where conceptually it is natural for one
to think of a constraint when you happen to know n, and then you define
the constraint in terms of the specific model elements (while thinking
less programmatically) -- e.g., some condition C involving "two instances
of class, M, and 2 instances of N".
Then, maybe writing the constraint in an adapted form:
context {m1 : M, m2 : M, n1 : N, n2 : N} {
constraint C {
// blah blah, refer to m1, m2, n1, n2, blah, blah
....
}
}
So, the computation engine would instantiate m1, m2, n1, n2, and the guard
could constrain further the instances, e.g., not(m1 = m2). This constraint
would just be syntactic sugar for an equivalent one expressed with a
single context and nested loops inside it -- and any necessary
guards/conditions.
Anyway, I thought I might clarify bits of my original post if anything was
unclear.
As always, thank you for your speedy reply!
Edd
> Cheers,
> Dimitris
> Edward Turner wrote:
>> Hi there,
>>
>> In EVL is it possible to define constraints whose context is a
>> pair/triple/etc of model elements?
>>
>> I have a situation where it would be good to validate a constraint of
>> the form:
>>
>> context X {
>> constraint CheckXPair {
>> check {
>> var otherX := MyModel!X.all.select(i | not(i = self));
>> // some check involving self and otherX ...
>> }
>> message : 'Error'
>> }
>> }
>>
>> And so, we're doing a check for each pair of instances of X. However, I
>> guess when the rule is being evaluated, then each pair of instances will
>> be evaluated twice. E.g., if x1 and x2 are instances of X, then the rule
>> would be evaluated when self is x1, and otherX is x2; and the rule would
>> also be evaluated when self is x2, and otherX is x1. The occurrence of
>> two evaluations per pair leads to redundant checking in my case, and so
>> being able to restrict this (to sets of instances) would be great. Do
>> you have any suggestions? I may be asking something misguided so
>> apologies in advance.
>>
>> In general, it would seem quite handy and natural to be able to express
>> a constraint for n-tuples of instances, e.g., for pairs/triples of
>> instances. This though, would give rise to a difficulty when referring
>> to the context, self, directly; but perhaps it could be referenced via a
>> Collection called self, e.g., self(0), denoting self.at(0), self(1), etc?
>>
>> Best,
>>
>> Edd
>>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10677 is a reply to message #10611] |
Mon, 02 February 2009 16:53 |
| Eclipse User |
|
|
|
Originally posted by: szchaler.acm.org
This is a multi-part message in MIME format.
--------------020108040907030506060107
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Dimitrios,
Comments below...
Dimitris Kolovos wrote:
<snip />
>> Just briefly: The "explosion of search space" argument doesn't really
>> seem to hold. You essentially do a complete search of the (EClass x
>> EClass) space with your code, too. And you could implement checks on
>> n-tuples such that they would implicitly use your ~checked solution
>> to create tuples to be checked. Also, I'm not sure that you really
>> often don't know n. Your unique name example can essentially be
>> encoded with n=2.
> So say you have c1, c2 and c3 all with the same name. My point was
> that if you set n=2 then you won't get error messages for both c1,c2
> and c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and
> c1,c2 - while what you want is to just get one message saying
> "c1,c2,c3 are all named X".
Agreed. However, you may be able to extend your guard concept to avoid
just that (see below for an initial idea).
>
> Your code below effectively does this, even though slightly
>> inefficiently (Note that it would be enough to select the first
>> element that we come across that has the same name as self, but is
>> not self. If any such element exists, uniqueness does no longer hold.)
>
> If it selected only the first then it would know that the constraint
> had failed but it wouldn't be able to mark the "others" as "checked"
> in order to avoid the extraneous evaluations (and subsequent error
> messages).
Agreed. I missed that subtlety :-(
>>
>> So, it may actually be the case that implementing n-tuples as a
>> language feature may on average allow for better optimisations (or at
>> least more consistent optimisations). In any case, it allows for
>> (c)leaner code :-)
>
> I agree; I just can't think of a good way to encode this in the
> general case. Any further thoughts on syntax/semantics of such an
> extension to EVL would be really welcome!
Well, in OCL we used to have a syntax for invariants over tuples that
was very much like what Edd has proposed in his other post. In EVL you
might want to write something like this:
context (ec1: EClass, ec2: EClass) {
constraint CheckUniqueName {
guard : isUnique(ec1.name)
check {
return (ec1.name <> ec2.name) or (ec1 == ec2);
}
message : 'Duplicate name ' + self.name
}
}
I've also added an initial idea of how one could use the guards to
advise further optimisation with a specialised isUnique feature. Maybe
taking this out of guard and into a separate section is a better idea :-)
Steffen
>
>>
>> Cheers,
>>
>> Steffen
>>
>> Dimitris Kolovos wrote:
>>> Hi Ed,
>>>
>>> You can avoid the duplicate error messages by using extended
>>> properties (see
>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>> for a detailed discussion). For example, if you have an ECore model
>>> and you want to check for duplicate names between EClasses, you can
>>> use the following constraint:
>>>
>>> context EClass {
>>> constraint CheckUniqueName {
>>> guard : not self.~checked.isDefined()
>>> check {
>>> var others := EClass.all.select(c|c.name = self.name and
>>> c <> self);
>>> if (others.size() > 0) {
>>> for (other in others) {
>>> other.~checked := true;
>>> }
>>> return false;
>>> }
>>> else {
>>> return true;
>>> }
>>> }
>>> message : 'Duplicate name ' + self.name
>>> }
>>> }
>>>
>>> So, when you find a duplicate, you create an extended property
>>> (~checked) on all the others, and then set an appropriate guard so
>>> that when EVL attempts to run the constraint for the others, they
>>> won't pass through it.
>>>
>>> I see your point with defining constraints for n-tuples; my main
>>> concern is that this can easily lead to an explosion of the search
>>> space. Also, most of the times you don't know n; e.g. you may have 3
>>> or 5 classes with the same name (wrt the previous example)...
>>>
>>> Cheers,
>>> Dimitris
>>>
>>> Edward Turner wrote:
>>>> Hi there,
>>>>
>>>> In EVL is it possible to define constraints whose context is a
>>>> pair/triple/etc of model elements?
>>>>
>>>> I have a situation where it would be good to validate a constraint
>>>> of the form:
>>>>
>>>> context X {
>>>> constraint CheckXPair {
>>>> check {
>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>> // some check involving self and otherX ...
>>>> }
>>>> message : 'Error'
>>>> }
>>>> }
>>>>
>>>> And so, we're doing a check for each pair of instances of X.
>>>> However, I guess when the rule is being evaluated, then each pair
>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>> instances of X, then the rule would be evaluated when self is x1,
>>>> and otherX is x2; and the rule would also be evaluated when self is
>>>> x2, and otherX is x1. The occurrence of two evaluations per pair
>>>> leads to redundant checking in my case, and so being able to
>>>> restrict this (to sets of instances) would be great. Do you have
>>>> any suggestions? I may be asking something misguided so apologies
>>>> in advance.
>>>>
>>>> In general, it would seem quite handy and natural to be able to
>>>> express a constraint for n-tuples of instances, e.g., for
>>>> pairs/triples of instances. This though, would give rise to a
>>>> difficulty when referring to the context, self, directly; but
>>>> perhaps it could be referenced via a Collection called self, e.g.,
>>>> self(0), denoting self.at(0), self(1), etc?
>>>>
>>>> Best,
>>>>
>>>> Edd
>>>>
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
--------------020108040907030506060107
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dimitrios,<br>
<br>
Comments below...<br>
<br>
Dimitris Kolovos wrote:<br>
<snip /><br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite">
<blockquote type="cite">Just briefly: The "explosion of search space"
argument doesn't really seem to hold. You essentially do a complete
search of the (EClass x EClass) space with your code, too. And you
could implement checks on n-tuples such that they would implicitly use
your ~checked solution to create tuples to be checked. Also, I'm not
sure that you really often don't know n. Your unique name example can
essentially be encoded with n=2. </blockquote>
So say you have c1, c2 and c3 all with the same name. My point was that
if you set n=2 then you won't get error messages for both c1,c2 and
c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and c1,c2
- while what you want is to just get one message saying "c1,c2,c3 are
all named X".
<br>
</blockquote>
Agreed. However, you may be able to extend your guard concept to avoid
just that (see below for an initial idea).<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite"><br>
Your code below effectively does this, even though slightly
<br>
<blockquote type="cite">inefficiently (Note that it would be enough
to select the first element that we come across that has the same name
as self, but is not self. If any such element exists, uniqueness does
no longer hold.)
<br>
</blockquote>
<br>
If it selected only the first then it would know that the constraint
had failed but it wouldn't be able to mark the "others" as "checked" in
order to avoid the extraneous evaluations (and subsequent error
messages).
<br>
</blockquote>
Agreed. I missed that subtlety :-(<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite">
<blockquote type="cite"><br>
So, it may actually be the case that implementing n-tuples as a
language feature may on average allow for better optimisations (or at
least more consistent optimisations). In any case, it allows for
(c)leaner code :-)
<br>
</blockquote>
<br>
I agree; I just can't think of a good way to encode this in the general
case. Any further thoughts on syntax/semantics of such an extension to
EVL would be really welcome!
<br>
</blockquote>
Well, in OCL we used to have a syntax for invariants over tuples that
was very much like what Edd has proposed in his other post. In EVL you
might want to write something like this:<br>
<blockquote>
<pre>context (ec1: EClass, ec2: EClass) {
constraint CheckUniqueName {
guard : isUnique(ec1.name)
check {
return (ec1.name <> ec2.name) or (ec1 == ec2);
}
message : 'Duplicate name ' + self.name
}
}
</pre>
</blockquote>
I've also added an initial idea of how one could use the guards to
advise further optimisation with a specialised isUnique feature. Maybe
taking this out of guard and into a separate section is a better idea
:-)<br>
<br>
Steffen<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite"><br>
Cheers,
<br>
<br>
Steffen
<br>
<br>
Dimitris Kolovos wrote:
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
You can avoid the duplicate error messages by using extended properties
(see
<a class="moz-txt-link-freetext" href=" http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/"> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/</a>
for a detailed discussion). For example, if you have an ECore model and
you want to check for duplicate names between EClasses, you can use the
following constraint:
<br>
<br>
context EClass {
<br>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10710 is a reply to message #10677] |
Tue, 03 February 2009 10:22 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Sounds interesting - but we'd have to precisely define the semantics and
scope of isUnique... I'm inclined to keep things as they are for now as
the extended properties feature provides a sensible workaround, but will
definitely consider providing more focused support for this if similar
requests keep coming.
Cheers,
Dimitris
Steffen Zschaler wrote:
<stuff deleted>
> Well, in OCL we used to have a syntax for invariants over tuples that
> was very much like what Edd has proposed in his other post. In EVL you
> might want to write something like this:
>
> context (ec1: EClass, ec2: EClass) {
> constraint CheckUniqueName {
> guard : isUnique(ec1.name)
> check {
> return (ec1.name <> ec2.name) or (ec1 = ec2);
> }
> message : 'Duplicate name ' + self.name
> }
> }
>
>
> I've also added an initial idea of how one could use the guards to
> advise further optimisation with a specialised isUnique feature. Maybe
> taking this out of guard and into a separate section is a better idea :-)
>
> Steffen
>>
>>>
>>> Cheers,
>>>
>>> Steffen
>>>
>>> Dimitris Kolovos wrote:
>>>> Hi Ed,
>>>>
>>>> You can avoid the duplicate error messages by using extended
>>>> properties (see
>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>> for a detailed discussion). For example, if you have an ECore model
>>>> and you want to check for duplicate names between EClasses, you can
>>>> use the following constraint:
>>>>
>>>> context EClass {
>>>> constraint CheckUniqueName {
>>>> guard : not self.~checked.isDefined()
>>>> check {
>>>> var others := EClass.all.select(c|c.name = self.name and
>>>> c <> self);
>>>> if (others.size() > 0) {
>>>> for (other in others) {
>>>> other.~checked := true;
>>>> }
>>>> return false;
>>>> }
>>>> else {
>>>> return true;
>>>> }
>>>> }
>>>> message : 'Duplicate name ' + self.name
>>>> }
>>>> }
>>>>
>>>> So, when you find a duplicate, you create an extended property
>>>> (~checked) on all the others, and then set an appropriate guard so
>>>> that when EVL attempts to run the constraint for the others, they
>>>> won't pass through it.
>>>>
>>>> I see your point with defining constraints for n-tuples; my main
>>>> concern is that this can easily lead to an explosion of the search
>>>> space. Also, most of the times you don't know n; e.g. you may have 3
>>>> or 5 classes with the same name (wrt the previous example)...
>>>>
>>>> Cheers,
>>>> Dimitris
>>>>
>>>> Edward Turner wrote:
>>>>> Hi there,
>>>>>
>>>>> In EVL is it possible to define constraints whose context is a
>>>>> pair/triple/etc of model elements?
>>>>>
>>>>> I have a situation where it would be good to validate a constraint
>>>>> of the form:
>>>>>
>>>>> context X {
>>>>> constraint CheckXPair {
>>>>> check {
>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>> // some check involving self and otherX ...
>>>>> }
>>>>> message : 'Error'
>>>>> }
>>>>> }
>>>>>
>>>>> And so, we're doing a check for each pair of instances of X.
>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>> and otherX is x2; and the rule would also be evaluated when self is
>>>>> x2, and otherX is x1. The occurrence of two evaluations per pair
>>>>> leads to redundant checking in my case, and so being able to
>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>> any suggestions? I may be asking something misguided so apologies
>>>>> in advance.
>>>>>
>>>>> In general, it would seem quite handy and natural to be able to
>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>> pairs/triples of instances. This though, would give rise to a
>>>>> difficulty when referring to the context, self, directly; but
>>>>> perhaps it could be referenced via a Collection called self, e.g.,
>>>>> self(0), denoting self.at(0), self(1), etc?
>>>>>
>>>>> Best,
>>>>>
>>>>> Edd
>>>>>
>>>
>
> --
> Dr. rer. nat. Steffen Zschaler
> Senior Research Associate
>
> Lancaster University
> Lancaster, United Kingdom
>
> Email szschaler@acm.org
> Phone +44 (01524) 510354
> WWW http://www.steffen-zschaler.de/
>
> --
> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
> Model-Driven Architecture Foundations and Applications.
> http://www.ecmda-fa.org/
>
> Consider submitting to QoSA 2009, the 5th International Conference on
> the Quality of Software-Architectures.
> http://qosa.ipd.uka.de/
>
> Consider submitting to MiSE 2009, the 3rd International Workshop on
> Models in Software Engineering
> http://wikiserver.sse.cs.tu-bs.de/mise09
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10742 is a reply to message #10710] |
Tue, 03 February 2009 10:32 |
| Eclipse User |
|
|
|
Originally posted by: szchaler.acm.org
This is a multi-part message in MIME format.
--------------040502000406070102000904
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Yea, I realised that defining the semantics would not be too easy.
Here's what I thought about this on my way home (so, not necessarily all
too well-thought-through, but I'll throw it on the table anyway...)
When defining constraints for tuples, we could redefine guard to only
accept iterator-based expressions, iterating over the tuples. These
would then be evaluated as follows (let itGuard be the expression in the
guard):
1. Let lTuples = List{}
2. While still untested combinations available
1. Assign new instances to each element of the tuple. Store the
whole tuple in variable currentTuple
2. lTuples := lTuples.including (currentTuple)
3. if (lTuples.itGuard)
1. Perform checks on currentTuple as usual, potentially
printing error message
4. else
1. lTuples := lTuples.excluding (currentTuple)
I think, this should at least allow us to deal with the isUnique issue
below. Still need to think about if it also works usefully for other cases.
Steffen
Dimitris Kolovos wrote:
> Hi Steffen,
>
> Sounds interesting - but we'd have to precisely define the semantics
> and scope of isUnique... I'm inclined to keep things as they are for
> now as the extended properties feature provides a sensible workaround,
> but will definitely consider providing more focused support for this
> if similar requests keep coming.
>
> Cheers,
> Dimitris
>
> Steffen Zschaler wrote:
> <stuff deleted>
>> Well, in OCL we used to have a syntax for invariants over tuples that
>> was very much like what Edd has proposed in his other post. In EVL
>> you might want to write something like this:
>>
>> context (ec1: EClass, ec2: EClass) {
>> constraint CheckUniqueName {
>> guard : isUnique(ec1.name)
>> check {
>> return (ec1.name <> ec2.name) or (ec1 = ec2);
>> }
>> message : 'Duplicate name ' + self.name
>> }
>> }
>>
>> I've also added an initial idea of how one could use the guards to
>> advise further optimisation with a specialised isUnique feature.
>> Maybe taking this out of guard and into a separate section is a
>> better idea :-)
>>
>> Steffen
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Steffen
>>>>
>>>> Dimitris Kolovos wrote:
>>>>> Hi Ed,
>>>>>
>>>>> You can avoid the duplicate error messages by using extended
>>>>> properties (see
>>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>>> for a detailed discussion). For example, if you have an ECore
>>>>> model and you want to check for duplicate names between EClasses,
>>>>> you can use the following constraint:
>>>>>
>>>>> context EClass {
>>>>> constraint CheckUniqueName {
>>>>> guard : not self.~checked.isDefined()
>>>>> check {
>>>>> var others := EClass.all.select(c|c.name = self.name
>>>>> and c <> self);
>>>>> if (others.size() > 0) {
>>>>> for (other in others) {
>>>>> other.~checked := true;
>>>>> }
>>>>> return false;
>>>>> }
>>>>> else {
>>>>> return true;
>>>>> }
>>>>> }
>>>>> message : 'Duplicate name ' + self.name
>>>>> }
>>>>> }
>>>>>
>>>>> So, when you find a duplicate, you create an extended property
>>>>> (~checked) on all the others, and then set an appropriate guard so
>>>>> that when EVL attempts to run the constraint for the others, they
>>>>> won't pass through it.
>>>>>
>>>>> I see your point with defining constraints for n-tuples; my main
>>>>> concern is that this can easily lead to an explosion of the search
>>>>> space. Also, most of the times you don't know n; e.g. you may have
>>>>> 3 or 5 classes with the same name (wrt the previous example)...
>>>>>
>>>>> Cheers,
>>>>> Dimitris
>>>>>
>>>>> Edward Turner wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> In EVL is it possible to define constraints whose context is a
>>>>>> pair/triple/etc of model elements?
>>>>>>
>>>>>> I have a situation where it would be good to validate a
>>>>>> constraint of the form:
>>>>>>
>>>>>> context X {
>>>>>> constraint CheckXPair {
>>>>>> check {
>>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>>> // some check involving self and otherX ...
>>>>>> }
>>>>>> message : 'Error'
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> And so, we're doing a check for each pair of instances of X.
>>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>>> and otherX is x2; and the rule would also be evaluated when self
>>>>>> is x2, and otherX is x1. The occurrence of two evaluations per
>>>>>> pair leads to redundant checking in my case, and so being able to
>>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>>> any suggestions? I may be asking something misguided so apologies
>>>>>> in advance.
>>>>>>
>>>>>> In general, it would seem quite handy and natural to be able to
>>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>>> pairs/triples of instances. This though, would give rise to a
>>>>>> difficulty when referring to the context, self, directly; but
>>>>>> perhaps it could be referenced via a Collection called self,
>>>>>> e.g., self(0), denoting self.at(0), self(1), etc?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Edd
>>>>>>
>>>>
>>
>> --
>> Dr. rer. nat. Steffen Zschaler
>> Senior Research Associate
>>
>> Lancaster University
>> Lancaster, United Kingdom
>>
>> Email szschaler@acm.org
>> Phone +44 (01524) 510354
>> WWW http://www.steffen-zschaler.de/
>>
>> --
>> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
>> Model-Driven Architecture Foundations and Applications.
>> http://www.ecmda-fa.org/
>>
>> Consider submitting to QoSA 2009, the 5th International Conference on
>> the Quality of Software-Architectures.
>> http://qosa.ipd.uka.de/
>>
>> Consider submitting to MiSE 2009, the 3rd International Workshop on
>> Models in Software Engineering
>> http://wikiserver.sse.cs.tu-bs.de/mise09
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
--------------040502000406070102000904
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yea, I realised that defining the semantics would not be too easy.
Here's what I thought about this on my way home (so, not necessarily
all too well-thought-through, but I'll throw it on the table anyway...)<br>
<br>
When defining constraints for tuples, we could redefine guard to only
accept iterator-based expressions, iterating over the tuples. These
would then be evaluated as follows (let itGuard be the expression in
the guard):<br>
<ol>
<li>Let lTuples = List{}</li>
<li>While still untested combinations available</li>
<ol>
<li>Assign new instances to each element of the tuple. Store the
whole tuple in variable currentTuple</li>
<li>lTuples := lTuples.including (currentTuple)</li>
<li>if (lTuples.itGuard)</li>
<ol>
<li>Perform checks on currentTuple as usual, potentially printing
error message</li>
</ol>
<li>else</li>
<ol>
<li>lTuples := lTuples.excluding (currentTuple)</li>
</ol>
</ol>
</ol>
I think, this should at least allow us to deal with the isUnique issue
below. Still need to think about if it also works usefully for other
cases.<br>
<br>
Steffen<br>
<br>
Dimitris Kolovos wrote:
<blockquote cite="mid:gm95sm$c4r$1@build.eclipse.org" type="cite">Hi
Steffen,
<br>
<br>
Sounds interesting - but we'd have to precisely define the semantics
and scope of isUnique... I'm inclined to keep things as they are for
now as the extended properties feature provides a sensible workaround,
but will definitely consider providing more focused support for this if
similar requests keep coming.
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
Steffen Zschaler wrote:
<br>
<stuff deleted>
<br>
<blockquote type="cite">Well, in OCL we used to have a syntax for
invariants over tuples that was very much like what Edd has proposed in
his other post. In EVL you might want to write something like this:
<br>
<br>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10774 is a reply to message #10644] |
Tue, 03 February 2009 10:32 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Edd,
Edward Turner wrote:
<stuff deleted>
> Yes I agree in some cases you don't know n. Originally, I'd really only
> thought of those modelling cases where conceptually it is natural for
> one to think of a constraint when you happen to know n, and then you
> define the constraint in terms of the specific model elements (while
> thinking less programmatically) -- e.g., some condition C involving "two
> instances of class, M, and 2 instances of N".
If you have such composite patterns that you'd like to validate (or
otherwise manage), it may be a good idea to define an external model
where you explicitly capture them. The respective metamodel would look
something like this:
@namespace(uri="mypatterns", prefix="mypatterns")
package mypatterns;
import "mydsl"
class MyPattern {
ref mydsl.N[*] n;
ref mydsl.M[*] m;
}
and then you could write constraints in the context of MyPattern:
context MyPattern {
constraint C {
check {
-- You can access the parts of the pattern: self.m, self.n
}
}
}
Does this sound as a sensible thing to do in your case?
>
> Then, maybe writing the constraint in an adapted form:
>
> context {m1 : M, m2 : M, n1 : N, n2 : N} {
> constraint C {
> // blah blah, refer to m1, m2, n1, n2, blah, blah
> ....
> }
> }
> So, the computation engine would instantiate m1, m2, n1, n2, and the
> guard could constrain further the instances, e.g., not(m1 = m2). This
> constraint would just be syntactic sugar for an equivalent one expressed
> with a single context and nested loops inside it -- and any necessary
> guards/conditions.
>
> Anyway, I thought I might clarify bits of my original post if anything
> was unclear.
>
> As always, thank you for your speedy reply!
>
> Edd
>> Cheers,
>> Dimitris
>
>> Edward Turner wrote:
>>> Hi there,
>>>
>>> In EVL is it possible to define constraints whose context is a
>>> pair/triple/etc of model elements?
>>>
>>> I have a situation where it would be good to validate a constraint of
>>> the form:
>>>
>>> context X {
>>> constraint CheckXPair {
>>> check {
>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>> // some check involving self and otherX ...
>>> }
>>> message : 'Error'
>>> }
>>> }
>>>
>>> And so, we're doing a check for each pair of instances of X. However,
>>> I guess when the rule is being evaluated, then each pair of instances
>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>> The occurrence of two evaluations per pair leads to redundant
>>> checking in my case, and so being able to restrict this (to sets of
>>> instances) would be great. Do you have any suggestions? I may be
>>> asking something misguided so apologies in advance.
>>>
>>> In general, it would seem quite handy and natural to be able to
>>> express a constraint for n-tuples of instances, e.g., for
>>> pairs/triples of instances. This though, would give rise to a
>>> difficulty when referring to the context, self, directly; but perhaps
>>> it could be referenced via a Collection called self, e.g., self(0),
>>> denoting self.at(0), self(1), etc?
>>>
>>> Best,
>>>
>>> Edd
>>>
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10804 is a reply to message #10742] |
Tue, 03 February 2009 10:43 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Thanks. I agree; I think this needs a bit more thought before casting in
stone (err... Java).
Cheers,
Dimitris
Steffen Zschaler wrote:
> Yea, I realised that defining the semantics would not be too easy.
> Here's what I thought about this on my way home (so, not necessarily all
> too well-thought-through, but I'll throw it on the table anyway...)
>
> When defining constraints for tuples, we could redefine guard to only
> accept iterator-based expressions, iterating over the tuples. These
> would then be evaluated as follows (let itGuard be the expression in the
> guard):
>
> 1. Let lTuples = List{}
> 2. While still untested combinations available
> 1. Assign new instances to each element of the tuple. Store the
> whole tuple in variable currentTuple
> 2. lTuples := lTuples.including (currentTuple)
> 3. if (lTuples.itGuard)
> 1. Perform checks on currentTuple as usual, potentially
> printing error message
> 4. else
> 1. lTuples := lTuples.excluding (currentTuple)
>
> I think, this should at least allow us to deal with the isUnique issue
> below. Still need to think about if it also works usefully for other cases.
>
> Steffen
>
> Dimitris Kolovos wrote:
>> Hi Steffen,
>>
>> Sounds interesting - but we'd have to precisely define the semantics
>> and scope of isUnique... I'm inclined to keep things as they are for
>> now as the extended properties feature provides a sensible workaround,
>> but will definitely consider providing more focused support for this
>> if similar requests keep coming.
>>
>> Cheers,
>> Dimitris
>>
>> Steffen Zschaler wrote:
>> <stuff deleted>
>>> Well, in OCL we used to have a syntax for invariants over tuples that
>>> was very much like what Edd has proposed in his other post. In EVL
>>> you might want to write something like this:
>>>
>>> context (ec1: EClass, ec2: EClass) {
>>> constraint CheckUniqueName {
>>> guard : isUnique(ec1.name)
>>> check {
>>> return (ec1.name <> ec2.name) or (ec1 = ec2);
>>> }
>>> message : 'Duplicate name ' + self.name
>>> }
>>> }
>>>
>>> I've also added an initial idea of how one could use the guards to
>>> advise further optimisation with a specialised isUnique feature.
>>> Maybe taking this out of guard and into a separate section is a
>>> better idea :-)
>>>
>>> Steffen
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Steffen
>>>>>
>>>>> Dimitris Kolovos wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> You can avoid the duplicate error messages by using extended
>>>>>> properties (see
>>>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>>>> for a detailed discussion). For example, if you have an ECore
>>>>>> model and you want to check for duplicate names between EClasses,
>>>>>> you can use the following constraint:
>>>>>>
>>>>>> context EClass {
>>>>>> constraint CheckUniqueName {
>>>>>> guard : not self.~checked.isDefined()
>>>>>> check {
>>>>>> var others := EClass.all.select(c|c.name = self.name
>>>>>> and c <> self);
>>>>>> if (others.size() > 0) {
>>>>>> for (other in others) {
>>>>>> other.~checked := true;
>>>>>> }
>>>>>> return false;
>>>>>> }
>>>>>> else {
>>>>>> return true;
>>>>>> }
>>>>>> }
>>>>>> message : 'Duplicate name ' + self.name
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> So, when you find a duplicate, you create an extended property
>>>>>> (~checked) on all the others, and then set an appropriate guard so
>>>>>> that when EVL attempts to run the constraint for the others, they
>>>>>> won't pass through it.
>>>>>>
>>>>>> I see your point with defining constraints for n-tuples; my main
>>>>>> concern is that this can easily lead to an explosion of the search
>>>>>> space. Also, most of the times you don't know n; e.g. you may have
>>>>>> 3 or 5 classes with the same name (wrt the previous example)...
>>>>>>
>>>>>> Cheers,
>>>>>> Dimitris
>>>>>>
>>>>>> Edward Turner wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> In EVL is it possible to define constraints whose context is a
>>>>>>> pair/triple/etc of model elements?
>>>>>>>
>>>>>>> I have a situation where it would be good to validate a
>>>>>>> constraint of the form:
>>>>>>>
>>>>>>> context X {
>>>>>>> constraint CheckXPair {
>>>>>>> check {
>>>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>>>> // some check involving self and otherX ...
>>>>>>> }
>>>>>>> message : 'Error'
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> And so, we're doing a check for each pair of instances of X.
>>>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>>>> and otherX is x2; and the rule would also be evaluated when self
>>>>>>> is x2, and otherX is x1. The occurrence of two evaluations per
>>>>>>> pair leads to redundant checking in my case, and so being able to
>>>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>>>> any suggestions? I may be asking something misguided so apologies
>>>>>>> in advance.
>>>>>>>
>>>>>>> In general, it would seem quite handy and natural to be able to
>>>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>>>> pairs/triples of instances. This though, would give rise to a
>>>>>>> difficulty when referring to the context, self, directly; but
>>>>>>> perhaps it could be referenced via a Collection called self,
>>>>>>> e.g., self(0), denoting self.at(0), self(1), etc?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Edd
>>>>>>>
>>>>>
>>>
>>> --
>>> Dr. rer. nat. Steffen Zschaler
>>> Senior Research Associate
>>>
>>> Lancaster University
>>> Lancaster, United Kingdom
>>>
>>> Email szschaler@acm.org
>>> Phone +44 (01524) 510354
>>> WWW http://www.steffen-zschaler.de/
>>>
>>> --
>>> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
>>> Model-Driven Architecture Foundations and Applications.
>>> http://www.ecmda-fa.org/
>>>
>>> Consider submitting to QoSA 2009, the 5th International Conference on
>>> the Quality of Software-Architectures.
>>> http://qosa.ipd.uka.de/
>>>
>>> Consider submitting to MiSE 2009, the 3rd International Workshop on
>>> Models in Software Engineering
>>> http://wikiserver.sse.cs.tu-bs.de/mise09
>>>
>
> --
> Dr. rer. nat. Steffen Zschaler
> Senior Research Associate
>
> Lancaster University
> Lancaster, United Kingdom
>
> Email szschaler@acm.org
> Phone +44 (01524) 510354
> WWW http://www.steffen-zschaler.de/
>
> --
> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
> Model-Driven Architecture Foundations and Applications.
> http://www.ecmda-fa.org/
>
> Consider submitting to QoSA 2009, the 5th International Conference on
> the Quality of Software-Architectures.
> http://qosa.ipd.uka.de/
>
> Consider submitting to MiSE 2009, the 3rd International Workshop on
> Models in Software Engineering
> http://wikiserver.sse.cs.tu-bs.de/mise09
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #10827 is a reply to message #10774] |
Tue, 03 February 2009 11:24 |
No real name
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Dimitris,
Dimitris Kolovos wrote:
...
> If you have such composite patterns that you'd like to validate (or
> otherwise manage), it may be a good idea to define an external model
> where you explicitly capture them. The respective metamodel would look
> something like this:
> @namespace(uri="mypatterns", prefix="mypatterns")
> package mypatterns;
> import "mydsl"
> class MyPattern {
> ref mydsl.N[*] n;
> ref mydsl.M[*] m;
> }
> and then you could write constraints in the context of MyPattern:
> context MyPattern {
> constraint C {
> check {
> -- You can access the parts of the pattern: self.m, self.n
> }
> }
> }
> Does this sound as a sensible thing to do in your case?
Yes, this is definitely one solution that I can and will use; thank you
for the suggestion :-).
Best,
Edd
>>
>> Then, maybe writing the constraint in an adapted form:
>>
>> context {m1 : M, m2 : M, n1 : N, n2 : N} {
>> constraint C {
>> // blah blah, refer to m1, m2, n1, n2, blah, blah
>> ....
>> }
>> }
>> So, the computation engine would instantiate m1, m2, n1, n2, and the
>> guard could constrain further the instances, e.g., not(m1 = m2). This
>> constraint would just be syntactic sugar for an equivalent one expressed
>> with a single context and nested loops inside it -- and any necessary
>> guards/conditions.
>>
>> Anyway, I thought I might clarify bits of my original post if anything
>> was unclear.
>>
>> As always, thank you for your speedy reply!
>>
>> Edd
>>> Cheers,
>>> Dimitris
>>
>>> Edward Turner wrote:
>>>> Hi there,
>>>>
>>>> In EVL is it possible to define constraints whose context is a
>>>> pair/triple/etc of model elements?
>>>>
>>>> I have a situation where it would be good to validate a constraint of
>>>> the form:
>>>>
>>>> context X {
>>>> constraint CheckXPair {
>>>> check {
>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>> // some check involving self and otherX ...
>>>> }
>>>> message : 'Error'
>>>> }
>>>> }
>>>>
>>>> And so, we're doing a check for each pair of instances of X. However,
>>>> I guess when the rule is being evaluated, then each pair of instances
>>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>>> The occurrence of two evaluations per pair leads to redundant
>>>> checking in my case, and so being able to restrict this (to sets of
>>>> instances) would be great. Do you have any suggestions? I may be
>>>> asking something misguided so apologies in advance.
>>>>
>>>> In general, it would seem quite handy and natural to be able to
>>>> express a constraint for n-tuples of instances, e.g., for
>>>> pairs/triples of instances. This though, would give rise to a
>>>> difficulty when referring to the context, self, directly; but perhaps
>>>> it could be referenced via a Collection called self, e.g., self(0),
>>>> denoting self.at(0), self(1), etc?
>>>>
>>>> Best,
>>>>
>>>> Edd
>>>>
>>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564496 is a reply to message #10512] |
Mon, 02 February 2009 14:55 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
You can avoid the duplicate error messages by using extended properties
(see
http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
for a detailed discussion). For example, if you have an ECore model and
you want to check for duplicate names between EClasses, you can use the
following constraint:
context EClass {
constraint CheckUniqueName {
guard : not self.~checked.isDefined()
check {
var others := EClass.all.select(c|c.name = self.name and c <> self);
if (others.size() > 0) {
for (other in others) {
other.~checked := true;
}
return false;
}
else {
return true;
}
}
message : 'Duplicate name ' + self.name
}
}
So, when you find a duplicate, you create an extended property
(~checked) on all the others, and then set an appropriate guard so that
when EVL attempts to run the constraint for the others, they won't pass
through it.
I see your point with defining constraints for n-tuples; my main concern
is that this can easily lead to an explosion of the search space. Also,
most of the times you don't know n; e.g. you may have 3 or 5 classes
with the same name (wrt the previous example)...
Cheers,
Dimitris
Edward Turner wrote:
> Hi there,
>
> In EVL is it possible to define constraints whose context is a
> pair/triple/etc of model elements?
>
> I have a situation where it would be good to validate a constraint of
> the form:
>
> context X {
> constraint CheckXPair {
> check {
> var otherX := MyModel!X.all.select(i | not(i = self));
> // some check involving self and otherX ...
> }
> message : 'Error'
> }
> }
>
> And so, we're doing a check for each pair of instances of X. However, I
> guess when the rule is being evaluated, then each pair of instances will
> be evaluated twice. E.g., if x1 and x2 are instances of X, then the rule
> would be evaluated when self is x1, and otherX is x2; and the rule would
> also be evaluated when self is x2, and otherX is x1. The occurrence of
> two evaluations per pair leads to redundant checking in my case, and so
> being able to restrict this (to sets of instances) would be great. Do
> you have any suggestions? I may be asking something misguided so
> apologies in advance.
>
> In general, it would seem quite handy and natural to be able to express
> a constraint for n-tuples of instances, e.g., for pairs/triples of
> instances. This though, would give rise to a difficulty when referring
> to the context, self, directly; but perhaps it could be referenced via a
> Collection called self, e.g., self(0), denoting self.at(0), self(1), etc?
>
> Best,
>
> Edd
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564518 is a reply to message #10545] |
Mon, 02 February 2009 15:13 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Dimitrios,
Just briefly: The "explosion of search space" argument doesn't really
seem to hold. You essentially do a complete search of the (EClass x
EClass) space with your code, too. And you could implement checks on
n-tuples such that they would implicitly use your ~checked solution to
create tuples to be checked. Also, I'm not sure that you really often
don't know n. Your unique name example can essentially be encoded with
n=2. Your code below effectively does this, even though slightly
inefficiently (Note that it would be enough to select the first element
that we come across that has the same name as self, but is not self. If
any such element exists, uniqueness does no longer hold.)
So, it may actually be the case that implementing n-tuples as a language
feature may on average allow for better optimisations (or at least more
consistent optimisations). In any case, it allows for (c)leaner code :-)
Cheers,
Steffen
Dimitris Kolovos wrote:
> Hi Ed,
>
> You can avoid the duplicate error messages by using extended
> properties (see
> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
> for a detailed discussion). For example, if you have an ECore model
> and you want to check for duplicate names between EClasses, you can
> use the following constraint:
>
> context EClass {
>
> constraint CheckUniqueName {
>
> guard : not self.~checked.isDefined()
>
> check {
> var others := EClass.all.select(c|c.name = self.name and c
> <> self);
> if (others.size() > 0) {
> for (other in others) {
> other.~checked := true;
> }
> return false;
> }
> else {
> return true;
> }
> }
>
> message : 'Duplicate name ' + self.name
>
> }
> }
>
> So, when you find a duplicate, you create an extended property
> (~checked) on all the others, and then set an appropriate guard so
> that when EVL attempts to run the constraint for the others, they
> won't pass through it.
>
> I see your point with defining constraints for n-tuples; my main
> concern is that this can easily lead to an explosion of the search
> space. Also, most of the times you don't know n; e.g. you may have 3
> or 5 classes with the same name (wrt the previous example)...
>
> Cheers,
> Dimitris
>
> Edward Turner wrote:
>> Hi there,
>>
>> In EVL is it possible to define constraints whose context is a
>> pair/triple/etc of model elements?
>>
>> I have a situation where it would be good to validate a constraint of
>> the form:
>>
>> context X {
>> constraint CheckXPair {
>> check {
>> var otherX := MyModel!X.all.select(i | not(i = self));
>> // some check involving self and otherX ...
>> }
>> message : 'Error'
>> }
>> }
>>
>> And so, we're doing a check for each pair of instances of X. However,
>> I guess when the rule is being evaluated, then each pair of instances
>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>> the rule would be evaluated when self is x1, and otherX is x2; and
>> the rule would also be evaluated when self is x2, and otherX is x1.
>> The occurrence of two evaluations per pair leads to redundant
>> checking in my case, and so being able to restrict this (to sets of
>> instances) would be great. Do you have any suggestions? I may be
>> asking something misguided so apologies in advance.
>>
>> In general, it would seem quite handy and natural to be able to
>> express a constraint for n-tuples of instances, e.g., for
>> pairs/triples of instances. This though, would give rise to a
>> difficulty when referring to the context, self, directly; but perhaps
>> it could be referenced via a Collection called self, e.g., self(0),
>> denoting self.at(0), self(1), etc?
>>
>> Best,
>>
>> Edd
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564532 is a reply to message #10578] |
Mon, 02 February 2009 15:28 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Please see comments below.
Cheers,
Dimitris
Steffen Zschaler wrote:
> Hi Dimitrios,
>
> Just briefly: The "explosion of search space" argument doesn't really
> seem to hold. You essentially do a complete search of the (EClass x
> EClass) space with your code, too. And you could implement checks on
> n-tuples such that they would implicitly use your ~checked solution to
> create tuples to be checked. Also, I'm not sure that you really often
> don't know n. Your unique name example can essentially be encoded with
> n=2.
So say you have c1, c2 and c3 all with the same name. My point was that
if you set n=2 then you won't get error messages for both c1,c2 and
c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and c1,c2
- while what you want is to just get one message saying "c1,c2,c3 are
all named X".
Your code below effectively does this, even though slightly
> inefficiently (Note that it would be enough to select the first element
> that we come across that has the same name as self, but is not self. If
> any such element exists, uniqueness does no longer hold.)
If it selected only the first then it would know that the constraint had
failed but it wouldn't be able to mark the "others" as "checked" in
order to avoid the extraneous evaluations (and subsequent error messages).
>
> So, it may actually be the case that implementing n-tuples as a language
> feature may on average allow for better optimisations (or at least more
> consistent optimisations). In any case, it allows for (c)leaner code :-)
I agree; I just can't think of a good way to encode this in the general
case. Any further thoughts on syntax/semantics of such an extension to
EVL would be really welcome!
>
> Cheers,
>
> Steffen
>
> Dimitris Kolovos wrote:
>> Hi Ed,
>>
>> You can avoid the duplicate error messages by using extended
>> properties (see
>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>> for a detailed discussion). For example, if you have an ECore model
>> and you want to check for duplicate names between EClasses, you can
>> use the following constraint:
>>
>> context EClass {
>> constraint CheckUniqueName {
>> guard : not self.~checked.isDefined()
>> check {
>> var others := EClass.all.select(c|c.name = self.name and c
>> <> self);
>> if (others.size() > 0) {
>> for (other in others) {
>> other.~checked := true;
>> }
>> return false;
>> }
>> else {
>> return true;
>> }
>> }
>> message : 'Duplicate name ' + self.name
>> }
>> }
>>
>> So, when you find a duplicate, you create an extended property
>> (~checked) on all the others, and then set an appropriate guard so
>> that when EVL attempts to run the constraint for the others, they
>> won't pass through it.
>>
>> I see your point with defining constraints for n-tuples; my main
>> concern is that this can easily lead to an explosion of the search
>> space. Also, most of the times you don't know n; e.g. you may have 3
>> or 5 classes with the same name (wrt the previous example)...
>>
>> Cheers,
>> Dimitris
>>
>> Edward Turner wrote:
>>> Hi there,
>>>
>>> In EVL is it possible to define constraints whose context is a
>>> pair/triple/etc of model elements?
>>>
>>> I have a situation where it would be good to validate a constraint of
>>> the form:
>>>
>>> context X {
>>> constraint CheckXPair {
>>> check {
>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>> // some check involving self and otherX ...
>>> }
>>> message : 'Error'
>>> }
>>> }
>>>
>>> And so, we're doing a check for each pair of instances of X. However,
>>> I guess when the rule is being evaluated, then each pair of instances
>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>> The occurrence of two evaluations per pair leads to redundant
>>> checking in my case, and so being able to restrict this (to sets of
>>> instances) would be great. Do you have any suggestions? I may be
>>> asking something misguided so apologies in advance.
>>>
>>> In general, it would seem quite handy and natural to be able to
>>> express a constraint for n-tuples of instances, e.g., for
>>> pairs/triples of instances. This though, would give rise to a
>>> difficulty when referring to the context, self, directly; but perhaps
>>> it could be referenced via a Collection called self, e.g., self(0),
>>> denoting self.at(0), self(1), etc?
>>>
>>> Best,
>>>
>>> Edd
>>>
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564543 is a reply to message #10545] |
Mon, 02 February 2009 16:09 |
No real name
Messages: 92
Registered: July 2009 |
Member |
|
|
> Hi Ed,
Hia Dimitris,
> You can avoid the duplicate error messages by using extended properties
> (see
> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
> for a detailed discussion).
Thanks for the link, I'd missed that feature of Epsilon. Yep, I should be
able to avoid performing redundant checks using extended properties (in
the case that I mentioned, possibly by attaching Collections to instances).
> I see your point with defining constraints for n-tuples; my main concern
> is that this can easily lead to an explosion of the search space.
Yes, part of my original post mentioned redundant checking, and so it
wouldn't be very nice if I blew up the search space with lots of
redundancy, by checking a constraint over say, 5 instances.
> Also, most of the times you don't know n; e.g. you may have 3 or 5 classes
> with the same name (wrt the previous example)...
Yes I agree in some cases you don't know n. Originally, I'd really only
thought of those modelling cases where conceptually it is natural for one
to think of a constraint when you happen to know n, and then you define
the constraint in terms of the specific model elements (while thinking
less programmatically) -- e.g., some condition C involving "two instances
of class, M, and 2 instances of N".
Then, maybe writing the constraint in an adapted form:
context {m1 : M, m2 : M, n1 : N, n2 : N} {
constraint C {
// blah blah, refer to m1, m2, n1, n2, blah, blah
....
}
}
So, the computation engine would instantiate m1, m2, n1, n2, and the guard
could constrain further the instances, e.g., not(m1 = m2). This constraint
would just be syntactic sugar for an equivalent one expressed with a
single context and nested loops inside it -- and any necessary
guards/conditions.
Anyway, I thought I might clarify bits of my original post if anything was
unclear.
As always, thank you for your speedy reply!
Edd
> Cheers,
> Dimitris
> Edward Turner wrote:
>> Hi there,
>>
>> In EVL is it possible to define constraints whose context is a
>> pair/triple/etc of model elements?
>>
>> I have a situation where it would be good to validate a constraint of
>> the form:
>>
>> context X {
>> constraint CheckXPair {
>> check {
>> var otherX := MyModel!X.all.select(i | not(i = self));
>> // some check involving self and otherX ...
>> }
>> message : 'Error'
>> }
>> }
>>
>> And so, we're doing a check for each pair of instances of X. However, I
>> guess when the rule is being evaluated, then each pair of instances will
>> be evaluated twice. E.g., if x1 and x2 are instances of X, then the rule
>> would be evaluated when self is x1, and otherX is x2; and the rule would
>> also be evaluated when self is x2, and otherX is x1. The occurrence of
>> two evaluations per pair leads to redundant checking in my case, and so
>> being able to restrict this (to sets of instances) would be great. Do
>> you have any suggestions? I may be asking something misguided so
>> apologies in advance.
>>
>> In general, it would seem quite handy and natural to be able to express
>> a constraint for n-tuples of instances, e.g., for pairs/triples of
>> instances. This though, would give rise to a difficulty when referring
>> to the context, self, directly; but perhaps it could be referenced via a
>> Collection called self, e.g., self(0), denoting self.at(0), self(1), etc?
>>
>> Best,
>>
>> Edd
>>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564575 is a reply to message #10611] |
Mon, 02 February 2009 16:53 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020108040907030506060107
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Dimitrios,
Comments below...
Dimitris Kolovos wrote:
<snip />
>> Just briefly: The "explosion of search space" argument doesn't really
>> seem to hold. You essentially do a complete search of the (EClass x
>> EClass) space with your code, too. And you could implement checks on
>> n-tuples such that they would implicitly use your ~checked solution
>> to create tuples to be checked. Also, I'm not sure that you really
>> often don't know n. Your unique name example can essentially be
>> encoded with n=2.
> So say you have c1, c2 and c3 all with the same name. My point was
> that if you set n=2 then you won't get error messages for both c1,c2
> and c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and
> c1,c2 - while what you want is to just get one message saying
> "c1,c2,c3 are all named X".
Agreed. However, you may be able to extend your guard concept to avoid
just that (see below for an initial idea).
>
> Your code below effectively does this, even though slightly
>> inefficiently (Note that it would be enough to select the first
>> element that we come across that has the same name as self, but is
>> not self. If any such element exists, uniqueness does no longer hold.)
>
> If it selected only the first then it would know that the constraint
> had failed but it wouldn't be able to mark the "others" as "checked"
> in order to avoid the extraneous evaluations (and subsequent error
> messages).
Agreed. I missed that subtlety :-(
>>
>> So, it may actually be the case that implementing n-tuples as a
>> language feature may on average allow for better optimisations (or at
>> least more consistent optimisations). In any case, it allows for
>> (c)leaner code :-)
>
> I agree; I just can't think of a good way to encode this in the
> general case. Any further thoughts on syntax/semantics of such an
> extension to EVL would be really welcome!
Well, in OCL we used to have a syntax for invariants over tuples that
was very much like what Edd has proposed in his other post. In EVL you
might want to write something like this:
context (ec1: EClass, ec2: EClass) {
constraint CheckUniqueName {
guard : isUnique(ec1.name)
check {
return (ec1.name <> ec2.name) or (ec1 == ec2);
}
message : 'Duplicate name ' + self.name
}
}
I've also added an initial idea of how one could use the guards to
advise further optimisation with a specialised isUnique feature. Maybe
taking this out of guard and into a separate section is a better idea :-)
Steffen
>
>>
>> Cheers,
>>
>> Steffen
>>
>> Dimitris Kolovos wrote:
>>> Hi Ed,
>>>
>>> You can avoid the duplicate error messages by using extended
>>> properties (see
>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>> for a detailed discussion). For example, if you have an ECore model
>>> and you want to check for duplicate names between EClasses, you can
>>> use the following constraint:
>>>
>>> context EClass {
>>> constraint CheckUniqueName {
>>> guard : not self.~checked.isDefined()
>>> check {
>>> var others := EClass.all.select(c|c.name = self.name and
>>> c <> self);
>>> if (others.size() > 0) {
>>> for (other in others) {
>>> other.~checked := true;
>>> }
>>> return false;
>>> }
>>> else {
>>> return true;
>>> }
>>> }
>>> message : 'Duplicate name ' + self.name
>>> }
>>> }
>>>
>>> So, when you find a duplicate, you create an extended property
>>> (~checked) on all the others, and then set an appropriate guard so
>>> that when EVL attempts to run the constraint for the others, they
>>> won't pass through it.
>>>
>>> I see your point with defining constraints for n-tuples; my main
>>> concern is that this can easily lead to an explosion of the search
>>> space. Also, most of the times you don't know n; e.g. you may have 3
>>> or 5 classes with the same name (wrt the previous example)...
>>>
>>> Cheers,
>>> Dimitris
>>>
>>> Edward Turner wrote:
>>>> Hi there,
>>>>
>>>> In EVL is it possible to define constraints whose context is a
>>>> pair/triple/etc of model elements?
>>>>
>>>> I have a situation where it would be good to validate a constraint
>>>> of the form:
>>>>
>>>> context X {
>>>> constraint CheckXPair {
>>>> check {
>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>> // some check involving self and otherX ...
>>>> }
>>>> message : 'Error'
>>>> }
>>>> }
>>>>
>>>> And so, we're doing a check for each pair of instances of X.
>>>> However, I guess when the rule is being evaluated, then each pair
>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>> instances of X, then the rule would be evaluated when self is x1,
>>>> and otherX is x2; and the rule would also be evaluated when self is
>>>> x2, and otherX is x1. The occurrence of two evaluations per pair
>>>> leads to redundant checking in my case, and so being able to
>>>> restrict this (to sets of instances) would be great. Do you have
>>>> any suggestions? I may be asking something misguided so apologies
>>>> in advance.
>>>>
>>>> In general, it would seem quite handy and natural to be able to
>>>> express a constraint for n-tuples of instances, e.g., for
>>>> pairs/triples of instances. This though, would give rise to a
>>>> difficulty when referring to the context, self, directly; but
>>>> perhaps it could be referenced via a Collection called self, e.g.,
>>>> self(0), denoting self.at(0), self(1), etc?
>>>>
>>>> Best,
>>>>
>>>> Edd
>>>>
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
--------------020108040907030506060107
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Dimitrios,<br>
<br>
Comments below...<br>
<br>
Dimitris Kolovos wrote:<br>
<snip /><br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite">
<blockquote type="cite">Just briefly: The "explosion of search space"
argument doesn't really seem to hold. You essentially do a complete
search of the (EClass x EClass) space with your code, too. And you
could implement checks on n-tuples such that they would implicitly use
your ~checked solution to create tuples to be checked. Also, I'm not
sure that you really often don't know n. Your unique name example can
essentially be encoded with n=2. </blockquote>
So say you have c1, c2 and c3 all with the same name. My point was that
if you set n=2 then you won't get error messages for both c1,c2 and
c2,c1 but you'll still get error messages for c1,c3 and c2,c3 and c1,c2
- while what you want is to just get one message saying "c1,c2,c3 are
all named X".
<br>
</blockquote>
Agreed. However, you may be able to extend your guard concept to avoid
just that (see below for an initial idea).<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite"><br>
Your code below effectively does this, even though slightly
<br>
<blockquote type="cite">inefficiently (Note that it would be enough
to select the first element that we come across that has the same name
as self, but is not self. If any such element exists, uniqueness does
no longer hold.)
<br>
</blockquote>
<br>
If it selected only the first then it would know that the constraint
had failed but it wouldn't be able to mark the "others" as "checked" in
order to avoid the extraneous evaluations (and subsequent error
messages).
<br>
</blockquote>
Agreed. I missed that subtlety :-(<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite">
<blockquote type="cite"><br>
So, it may actually be the case that implementing n-tuples as a
language feature may on average allow for better optimisations (or at
least more consistent optimisations). In any case, it allows for
(c)leaner code :-)
<br>
</blockquote>
<br>
I agree; I just can't think of a good way to encode this in the general
case. Any further thoughts on syntax/semantics of such an extension to
EVL would be really welcome!
<br>
</blockquote>
Well, in OCL we used to have a syntax for invariants over tuples that
was very much like what Edd has proposed in his other post. In EVL you
might want to write something like this:<br>
<blockquote>
<pre>context (ec1: EClass, ec2: EClass) {
constraint CheckUniqueName {
guard : isUnique(ec1.name)
check {
return (ec1.name <> ec2.name) or (ec1 == ec2);
}
message : 'Duplicate name ' + self.name
}
}
</pre>
</blockquote>
I've also added an initial idea of how one could use the guards to
advise further optimisation with a specialised isUnique feature. Maybe
taking this out of guard and into a separate section is a better idea
:-)<br>
<br>
Steffen<br>
<blockquote cite="mid:gm73fa$nkm$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite"><br>
Cheers,
<br>
<br>
Steffen
<br>
<br>
Dimitris Kolovos wrote:
<br>
<blockquote type="cite">Hi Ed,
<br>
<br>
You can avoid the duplicate error messages by using extended properties
(see
<a class="moz-txt-link-freetext" href=" http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/"> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/</a>
for a detailed discussion). For example, if you have an ECore model and
you want to check for duplicate names between EClasses, you can use the
following constraint:
<br>
<br>
context EClass {
<br>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564591 is a reply to message #10677] |
Tue, 03 February 2009 10:22 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Steffen,
Sounds interesting - but we'd have to precisely define the semantics and
scope of isUnique... I'm inclined to keep things as they are for now as
the extended properties feature provides a sensible workaround, but will
definitely consider providing more focused support for this if similar
requests keep coming.
Cheers,
Dimitris
Steffen Zschaler wrote:
<stuff deleted>
> Well, in OCL we used to have a syntax for invariants over tuples that
> was very much like what Edd has proposed in his other post. In EVL you
> might want to write something like this:
>
> context (ec1: EClass, ec2: EClass) {
> constraint CheckUniqueName {
> guard : isUnique(ec1.name)
> check {
> return (ec1.name <> ec2.name) or (ec1 = ec2);
> }
> message : 'Duplicate name ' + self.name
> }
> }
>
>
> I've also added an initial idea of how one could use the guards to
> advise further optimisation with a specialised isUnique feature. Maybe
> taking this out of guard and into a separate section is a better idea :-)
>
> Steffen
>>
>>>
>>> Cheers,
>>>
>>> Steffen
>>>
>>> Dimitris Kolovos wrote:
>>>> Hi Ed,
>>>>
>>>> You can avoid the duplicate error messages by using extended
>>>> properties (see
>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>> for a detailed discussion). For example, if you have an ECore model
>>>> and you want to check for duplicate names between EClasses, you can
>>>> use the following constraint:
>>>>
>>>> context EClass {
>>>> constraint CheckUniqueName {
>>>> guard : not self.~checked.isDefined()
>>>> check {
>>>> var others := EClass.all.select(c|c.name = self.name and
>>>> c <> self);
>>>> if (others.size() > 0) {
>>>> for (other in others) {
>>>> other.~checked := true;
>>>> }
>>>> return false;
>>>> }
>>>> else {
>>>> return true;
>>>> }
>>>> }
>>>> message : 'Duplicate name ' + self.name
>>>> }
>>>> }
>>>>
>>>> So, when you find a duplicate, you create an extended property
>>>> (~checked) on all the others, and then set an appropriate guard so
>>>> that when EVL attempts to run the constraint for the others, they
>>>> won't pass through it.
>>>>
>>>> I see your point with defining constraints for n-tuples; my main
>>>> concern is that this can easily lead to an explosion of the search
>>>> space. Also, most of the times you don't know n; e.g. you may have 3
>>>> or 5 classes with the same name (wrt the previous example)...
>>>>
>>>> Cheers,
>>>> Dimitris
>>>>
>>>> Edward Turner wrote:
>>>>> Hi there,
>>>>>
>>>>> In EVL is it possible to define constraints whose context is a
>>>>> pair/triple/etc of model elements?
>>>>>
>>>>> I have a situation where it would be good to validate a constraint
>>>>> of the form:
>>>>>
>>>>> context X {
>>>>> constraint CheckXPair {
>>>>> check {
>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>> // some check involving self and otherX ...
>>>>> }
>>>>> message : 'Error'
>>>>> }
>>>>> }
>>>>>
>>>>> And so, we're doing a check for each pair of instances of X.
>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>> and otherX is x2; and the rule would also be evaluated when self is
>>>>> x2, and otherX is x1. The occurrence of two evaluations per pair
>>>>> leads to redundant checking in my case, and so being able to
>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>> any suggestions? I may be asking something misguided so apologies
>>>>> in advance.
>>>>>
>>>>> In general, it would seem quite handy and natural to be able to
>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>> pairs/triples of instances. This though, would give rise to a
>>>>> difficulty when referring to the context, self, directly; but
>>>>> perhaps it could be referenced via a Collection called self, e.g.,
>>>>> self(0), denoting self.at(0), self(1), etc?
>>>>>
>>>>> Best,
>>>>>
>>>>> Edd
>>>>>
>>>
>
> --
> Dr. rer. nat. Steffen Zschaler
> Senior Research Associate
>
> Lancaster University
> Lancaster, United Kingdom
>
> Email szschaler@acm.org
> Phone +44 (01524) 510354
> WWW http://www.steffen-zschaler.de/
>
> --
> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
> Model-Driven Architecture Foundations and Applications.
> http://www.ecmda-fa.org/
>
> Consider submitting to QoSA 2009, the 5th International Conference on
> the Quality of Software-Architectures.
> http://qosa.ipd.uka.de/
>
> Consider submitting to MiSE 2009, the 3rd International Workshop on
> Models in Software Engineering
> http://wikiserver.sse.cs.tu-bs.de/mise09
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564615 is a reply to message #10710] |
Tue, 03 February 2009 10:32 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040502000406070102000904
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Yea, I realised that defining the semantics would not be too easy.
Here's what I thought about this on my way home (so, not necessarily all
too well-thought-through, but I'll throw it on the table anyway...)
When defining constraints for tuples, we could redefine guard to only
accept iterator-based expressions, iterating over the tuples. These
would then be evaluated as follows (let itGuard be the expression in the
guard):
1. Let lTuples = List{}
2. While still untested combinations available
1. Assign new instances to each element of the tuple. Store the
whole tuple in variable currentTuple
2. lTuples := lTuples.including (currentTuple)
3. if (lTuples.itGuard)
1. Perform checks on currentTuple as usual, potentially
printing error message
4. else
1. lTuples := lTuples.excluding (currentTuple)
I think, this should at least allow us to deal with the isUnique issue
below. Still need to think about if it also works usefully for other cases.
Steffen
Dimitris Kolovos wrote:
> Hi Steffen,
>
> Sounds interesting - but we'd have to precisely define the semantics
> and scope of isUnique... I'm inclined to keep things as they are for
> now as the extended properties feature provides a sensible workaround,
> but will definitely consider providing more focused support for this
> if similar requests keep coming.
>
> Cheers,
> Dimitris
>
> Steffen Zschaler wrote:
> <stuff deleted>
>> Well, in OCL we used to have a syntax for invariants over tuples that
>> was very much like what Edd has proposed in his other post. In EVL
>> you might want to write something like this:
>>
>> context (ec1: EClass, ec2: EClass) {
>> constraint CheckUniqueName {
>> guard : isUnique(ec1.name)
>> check {
>> return (ec1.name <> ec2.name) or (ec1 = ec2);
>> }
>> message : 'Duplicate name ' + self.name
>> }
>> }
>>
>> I've also added an initial idea of how one could use the guards to
>> advise further optimisation with a specialised isUnique feature.
>> Maybe taking this out of guard and into a separate section is a
>> better idea :-)
>>
>> Steffen
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Steffen
>>>>
>>>> Dimitris Kolovos wrote:
>>>>> Hi Ed,
>>>>>
>>>>> You can avoid the duplicate error messages by using extended
>>>>> properties (see
>>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>>> for a detailed discussion). For example, if you have an ECore
>>>>> model and you want to check for duplicate names between EClasses,
>>>>> you can use the following constraint:
>>>>>
>>>>> context EClass {
>>>>> constraint CheckUniqueName {
>>>>> guard : not self.~checked.isDefined()
>>>>> check {
>>>>> var others := EClass.all.select(c|c.name = self.name
>>>>> and c <> self);
>>>>> if (others.size() > 0) {
>>>>> for (other in others) {
>>>>> other.~checked := true;
>>>>> }
>>>>> return false;
>>>>> }
>>>>> else {
>>>>> return true;
>>>>> }
>>>>> }
>>>>> message : 'Duplicate name ' + self.name
>>>>> }
>>>>> }
>>>>>
>>>>> So, when you find a duplicate, you create an extended property
>>>>> (~checked) on all the others, and then set an appropriate guard so
>>>>> that when EVL attempts to run the constraint for the others, they
>>>>> won't pass through it.
>>>>>
>>>>> I see your point with defining constraints for n-tuples; my main
>>>>> concern is that this can easily lead to an explosion of the search
>>>>> space. Also, most of the times you don't know n; e.g. you may have
>>>>> 3 or 5 classes with the same name (wrt the previous example)...
>>>>>
>>>>> Cheers,
>>>>> Dimitris
>>>>>
>>>>> Edward Turner wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> In EVL is it possible to define constraints whose context is a
>>>>>> pair/triple/etc of model elements?
>>>>>>
>>>>>> I have a situation where it would be good to validate a
>>>>>> constraint of the form:
>>>>>>
>>>>>> context X {
>>>>>> constraint CheckXPair {
>>>>>> check {
>>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>>> // some check involving self and otherX ...
>>>>>> }
>>>>>> message : 'Error'
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> And so, we're doing a check for each pair of instances of X.
>>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>>> and otherX is x2; and the rule would also be evaluated when self
>>>>>> is x2, and otherX is x1. The occurrence of two evaluations per
>>>>>> pair leads to redundant checking in my case, and so being able to
>>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>>> any suggestions? I may be asking something misguided so apologies
>>>>>> in advance.
>>>>>>
>>>>>> In general, it would seem quite handy and natural to be able to
>>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>>> pairs/triples of instances. This though, would give rise to a
>>>>>> difficulty when referring to the context, self, directly; but
>>>>>> perhaps it could be referenced via a Collection called self,
>>>>>> e.g., self(0), denoting self.at(0), self(1), etc?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Edd
>>>>>>
>>>>
>>
>> --
>> Dr. rer. nat. Steffen Zschaler
>> Senior Research Associate
>>
>> Lancaster University
>> Lancaster, United Kingdom
>>
>> Email szschaler@acm.org
>> Phone +44 (01524) 510354
>> WWW http://www.steffen-zschaler.de/
>>
>> --
>> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
>> Model-Driven Architecture Foundations and Applications.
>> http://www.ecmda-fa.org/
>>
>> Consider submitting to QoSA 2009, the 5th International Conference on
>> the Quality of Software-Architectures.
>> http://qosa.ipd.uka.de/
>>
>> Consider submitting to MiSE 2009, the 3rd International Workshop on
>> Models in Software Engineering
>> http://wikiserver.sse.cs.tu-bs.de/mise09
>>
--
Dr. rer. nat. Steffen Zschaler
Senior Research Associate
Lancaster University
Lancaster, United Kingdom
Email szschaler@acm.org
Phone +44 (01524) 510354
WWW http://www.steffen-zschaler.de/
--
Consider submitting to ECMDA-FA 2009, the 5th European Conference on
Model-Driven Architecture Foundations and Applications.
http://www.ecmda-fa.org/
Consider submitting to QoSA 2009, the 5th International Conference on
the Quality of Software-Architectures.
http://qosa.ipd.uka.de/
Consider submitting to MiSE 2009, the 3rd International Workshop on
Models in Software Engineering
http://wikiserver.sse.cs.tu-bs.de/mise09
--------------040502000406070102000904
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Yea, I realised that defining the semantics would not be too easy.
Here's what I thought about this on my way home (so, not necessarily
all too well-thought-through, but I'll throw it on the table anyway...)<br>
<br>
When defining constraints for tuples, we could redefine guard to only
accept iterator-based expressions, iterating over the tuples. These
would then be evaluated as follows (let itGuard be the expression in
the guard):<br>
<ol>
<li>Let lTuples = List{}</li>
<li>While still untested combinations available</li>
<ol>
<li>Assign new instances to each element of the tuple. Store the
whole tuple in variable currentTuple</li>
<li>lTuples := lTuples.including (currentTuple)</li>
<li>if (lTuples.itGuard)</li>
<ol>
<li>Perform checks on currentTuple as usual, potentially printing
error message</li>
</ol>
<li>else</li>
<ol>
<li>lTuples := lTuples.excluding (currentTuple)</li>
</ol>
</ol>
</ol>
I think, this should at least allow us to deal with the isUnique issue
below. Still need to think about if it also works usefully for other
cases.<br>
<br>
Steffen<br>
<br>
Dimitris Kolovos wrote:
<blockquote cite="mid:gm95sm$c4r$1@build.eclipse.org" type="cite">Hi
Steffen,
<br>
<br>
Sounds interesting - but we'd have to precisely define the semantics
and scope of isUnique... I'm inclined to keep things as they are for
now as the extended properties feature provides a sensible workaround,
but will definitely consider providing more focused support for this if
similar requests keep coming.
<br>
<br>
Cheers,
<br>
Dimitris
<br>
<br>
Steffen Zschaler wrote:
<br>
<stuff deleted>
<br>
<blockquote type="cite">Well, in OCL we used to have a syntax for
invariants over tuples that was very much like what Edd has proposed in
his other post. In EVL you might want to write something like this:
<br>
<br>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564641 is a reply to message #10644] |
Tue, 03 February 2009 10:32 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Hi Edd,
Edward Turner wrote:
<stuff deleted>
> Yes I agree in some cases you don't know n. Originally, I'd really only
> thought of those modelling cases where conceptually it is natural for
> one to think of a constraint when you happen to know n, and then you
> define the constraint in terms of the specific model elements (while
> thinking less programmatically) -- e.g., some condition C involving "two
> instances of class, M, and 2 instances of N".
If you have such composite patterns that you'd like to validate (or
otherwise manage), it may be a good idea to define an external model
where you explicitly capture them. The respective metamodel would look
something like this:
@namespace(uri="mypatterns", prefix="mypatterns")
package mypatterns;
import "mydsl"
class MyPattern {
ref mydsl.N[*] n;
ref mydsl.M[*] m;
}
and then you could write constraints in the context of MyPattern:
context MyPattern {
constraint C {
check {
-- You can access the parts of the pattern: self.m, self.n
}
}
}
Does this sound as a sensible thing to do in your case?
>
> Then, maybe writing the constraint in an adapted form:
>
> context {m1 : M, m2 : M, n1 : N, n2 : N} {
> constraint C {
> // blah blah, refer to m1, m2, n1, n2, blah, blah
> ....
> }
> }
> So, the computation engine would instantiate m1, m2, n1, n2, and the
> guard could constrain further the instances, e.g., not(m1 = m2). This
> constraint would just be syntactic sugar for an equivalent one expressed
> with a single context and nested loops inside it -- and any necessary
> guards/conditions.
>
> Anyway, I thought I might clarify bits of my original post if anything
> was unclear.
>
> As always, thank you for your speedy reply!
>
> Edd
>> Cheers,
>> Dimitris
>
>> Edward Turner wrote:
>>> Hi there,
>>>
>>> In EVL is it possible to define constraints whose context is a
>>> pair/triple/etc of model elements?
>>>
>>> I have a situation where it would be good to validate a constraint of
>>> the form:
>>>
>>> context X {
>>> constraint CheckXPair {
>>> check {
>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>> // some check involving self and otherX ...
>>> }
>>> message : 'Error'
>>> }
>>> }
>>>
>>> And so, we're doing a check for each pair of instances of X. However,
>>> I guess when the rule is being evaluated, then each pair of instances
>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>> The occurrence of two evaluations per pair leads to redundant
>>> checking in my case, and so being able to restrict this (to sets of
>>> instances) would be great. Do you have any suggestions? I may be
>>> asking something misguided so apologies in advance.
>>>
>>> In general, it would seem quite handy and natural to be able to
>>> express a constraint for n-tuples of instances, e.g., for
>>> pairs/triples of instances. This though, would give rise to a
>>> difficulty when referring to the context, self, directly; but perhaps
>>> it could be referenced via a Collection called self, e.g., self(0),
>>> denoting self.at(0), self(1), etc?
>>>
>>> Best,
>>>
>>> Edd
>>>
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564663 is a reply to message #10742] |
Tue, 03 February 2009 10:43 |
Dimitrios Kolovos
Messages: 1776
Registered: July 2009 |
Senior Member |
|
|
Thanks. I agree; I think this needs a bit more thought before casting in
stone (err... Java).
Cheers,
Dimitris
Steffen Zschaler wrote:
> Yea, I realised that defining the semantics would not be too easy.
> Here's what I thought about this on my way home (so, not necessarily all
> too well-thought-through, but I'll throw it on the table anyway...)
>
> When defining constraints for tuples, we could redefine guard to only
> accept iterator-based expressions, iterating over the tuples. These
> would then be evaluated as follows (let itGuard be the expression in the
> guard):
>
> 1. Let lTuples = List{}
> 2. While still untested combinations available
> 1. Assign new instances to each element of the tuple. Store the
> whole tuple in variable currentTuple
> 2. lTuples := lTuples.including (currentTuple)
> 3. if (lTuples.itGuard)
> 1. Perform checks on currentTuple as usual, potentially
> printing error message
> 4. else
> 1. lTuples := lTuples.excluding (currentTuple)
>
> I think, this should at least allow us to deal with the isUnique issue
> below. Still need to think about if it also works usefully for other cases.
>
> Steffen
>
> Dimitris Kolovos wrote:
>> Hi Steffen,
>>
>> Sounds interesting - but we'd have to precisely define the semantics
>> and scope of isUnique... I'm inclined to keep things as they are for
>> now as the extended properties feature provides a sensible workaround,
>> but will definitely consider providing more focused support for this
>> if similar requests keep coming.
>>
>> Cheers,
>> Dimitris
>>
>> Steffen Zschaler wrote:
>> <stuff deleted>
>>> Well, in OCL we used to have a syntax for invariants over tuples that
>>> was very much like what Edd has proposed in his other post. In EVL
>>> you might want to write something like this:
>>>
>>> context (ec1: EClass, ec2: EClass) {
>>> constraint CheckUniqueName {
>>> guard : isUnique(ec1.name)
>>> check {
>>> return (ec1.name <> ec2.name) or (ec1 = ec2);
>>> }
>>> message : 'Duplicate name ' + self.name
>>> }
>>> }
>>>
>>> I've also added an initial idea of how one could use the guards to
>>> advise further optimisation with a specialised isUnique feature.
>>> Maybe taking this out of guard and into a separate section is a
>>> better idea :-)
>>>
>>> Steffen
>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Steffen
>>>>>
>>>>> Dimitris Kolovos wrote:
>>>>>> Hi Ed,
>>>>>>
>>>>>> You can avoid the duplicate error messages by using extended
>>>>>> properties (see
>>>>>> http://epsilonblog.wordpress.com/2008/01/30/extended-propert ies-in-eol/
>>>>>> for a detailed discussion). For example, if you have an ECore
>>>>>> model and you want to check for duplicate names between EClasses,
>>>>>> you can use the following constraint:
>>>>>>
>>>>>> context EClass {
>>>>>> constraint CheckUniqueName {
>>>>>> guard : not self.~checked.isDefined()
>>>>>> check {
>>>>>> var others := EClass.all.select(c|c.name = self.name
>>>>>> and c <> self);
>>>>>> if (others.size() > 0) {
>>>>>> for (other in others) {
>>>>>> other.~checked := true;
>>>>>> }
>>>>>> return false;
>>>>>> }
>>>>>> else {
>>>>>> return true;
>>>>>> }
>>>>>> }
>>>>>> message : 'Duplicate name ' + self.name
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> So, when you find a duplicate, you create an extended property
>>>>>> (~checked) on all the others, and then set an appropriate guard so
>>>>>> that when EVL attempts to run the constraint for the others, they
>>>>>> won't pass through it.
>>>>>>
>>>>>> I see your point with defining constraints for n-tuples; my main
>>>>>> concern is that this can easily lead to an explosion of the search
>>>>>> space. Also, most of the times you don't know n; e.g. you may have
>>>>>> 3 or 5 classes with the same name (wrt the previous example)...
>>>>>>
>>>>>> Cheers,
>>>>>> Dimitris
>>>>>>
>>>>>> Edward Turner wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> In EVL is it possible to define constraints whose context is a
>>>>>>> pair/triple/etc of model elements?
>>>>>>>
>>>>>>> I have a situation where it would be good to validate a
>>>>>>> constraint of the form:
>>>>>>>
>>>>>>> context X {
>>>>>>> constraint CheckXPair {
>>>>>>> check {
>>>>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>>>>> // some check involving self and otherX ...
>>>>>>> }
>>>>>>> message : 'Error'
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> And so, we're doing a check for each pair of instances of X.
>>>>>>> However, I guess when the rule is being evaluated, then each pair
>>>>>>> of instances will be evaluated twice. E.g., if x1 and x2 are
>>>>>>> instances of X, then the rule would be evaluated when self is x1,
>>>>>>> and otherX is x2; and the rule would also be evaluated when self
>>>>>>> is x2, and otherX is x1. The occurrence of two evaluations per
>>>>>>> pair leads to redundant checking in my case, and so being able to
>>>>>>> restrict this (to sets of instances) would be great. Do you have
>>>>>>> any suggestions? I may be asking something misguided so apologies
>>>>>>> in advance.
>>>>>>>
>>>>>>> In general, it would seem quite handy and natural to be able to
>>>>>>> express a constraint for n-tuples of instances, e.g., for
>>>>>>> pairs/triples of instances. This though, would give rise to a
>>>>>>> difficulty when referring to the context, self, directly; but
>>>>>>> perhaps it could be referenced via a Collection called self,
>>>>>>> e.g., self(0), denoting self.at(0), self(1), etc?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Edd
>>>>>>>
>>>>>
>>>
>>> --
>>> Dr. rer. nat. Steffen Zschaler
>>> Senior Research Associate
>>>
>>> Lancaster University
>>> Lancaster, United Kingdom
>>>
>>> Email szschaler@acm.org
>>> Phone +44 (01524) 510354
>>> WWW http://www.steffen-zschaler.de/
>>>
>>> --
>>> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
>>> Model-Driven Architecture Foundations and Applications.
>>> http://www.ecmda-fa.org/
>>>
>>> Consider submitting to QoSA 2009, the 5th International Conference on
>>> the Quality of Software-Architectures.
>>> http://qosa.ipd.uka.de/
>>>
>>> Consider submitting to MiSE 2009, the 3rd International Workshop on
>>> Models in Software Engineering
>>> http://wikiserver.sse.cs.tu-bs.de/mise09
>>>
>
> --
> Dr. rer. nat. Steffen Zschaler
> Senior Research Associate
>
> Lancaster University
> Lancaster, United Kingdom
>
> Email szschaler@acm.org
> Phone +44 (01524) 510354
> WWW http://www.steffen-zschaler.de/
>
> --
> Consider submitting to ECMDA-FA 2009, the 5th European Conference on
> Model-Driven Architecture Foundations and Applications.
> http://www.ecmda-fa.org/
>
> Consider submitting to QoSA 2009, the 5th International Conference on
> the Quality of Software-Architectures.
> http://qosa.ipd.uka.de/
>
> Consider submitting to MiSE 2009, the 3rd International Workshop on
> Models in Software Engineering
> http://wikiserver.sse.cs.tu-bs.de/mise09
>
|
|
|
| Re: EVL constraints over instance pairs/triples/etc [message #564690 is a reply to message #10774] |
Tue, 03 February 2009 11:24 |
No real name
Messages: 92
Registered: July 2009 |
Member |
|
|
Hi Dimitris,
Dimitris Kolovos wrote:
...
> If you have such composite patterns that you'd like to validate (or
> otherwise manage), it may be a good idea to define an external model
> where you explicitly capture them. The respective metamodel would look
> something like this:
> @namespace(uri="mypatterns", prefix="mypatterns")
> package mypatterns;
> import "mydsl"
> class MyPattern {
> ref mydsl.N[*] n;
> ref mydsl.M[*] m;
> }
> and then you could write constraints in the context of MyPattern:
> context MyPattern {
> constraint C {
> check {
> -- You can access the parts of the pattern: self.m, self.n
> }
> }
> }
> Does this sound as a sensible thing to do in your case?
Yes, this is definitely one solution that I can and will use; thank you
for the suggestion :-).
Best,
Edd
>>
>> Then, maybe writing the constraint in an adapted form:
>>
>> context {m1 : M, m2 : M, n1 : N, n2 : N} {
>> constraint C {
>> // blah blah, refer to m1, m2, n1, n2, blah, blah
>> ....
>> }
>> }
>> So, the computation engine would instantiate m1, m2, n1, n2, and the
>> guard could constrain further the instances, e.g., not(m1 = m2). This
>> constraint would just be syntactic sugar for an equivalent one expressed
>> with a single context and nested loops inside it -- and any necessary
>> guards/conditions.
>>
>> Anyway, I thought I might clarify bits of my original post if anything
>> was unclear.
>>
>> As always, thank you for your speedy reply!
>>
>> Edd
>>> Cheers,
>>> Dimitris
>>
>>> Edward Turner wrote:
>>>> Hi there,
>>>>
>>>> In EVL is it possible to define constraints whose context is a
>>>> pair/triple/etc of model elements?
>>>>
>>>> I have a situation where it would be good to validate a constraint of
>>>> the form:
>>>>
>>>> context X {
>>>> constraint CheckXPair {
>>>> check {
>>>> var otherX := MyModel!X.all.select(i | not(i = self));
>>>> // some check involving self and otherX ...
>>>> }
>>>> message : 'Error'
>>>> }
>>>> }
>>>>
>>>> And so, we're doing a check for each pair of instances of X. However,
>>>> I guess when the rule is being evaluated, then each pair of instances
>>>> will be evaluated twice. E.g., if x1 and x2 are instances of X, then
>>>> the rule would be evaluated when self is x1, and otherX is x2; and
>>>> the rule would also be evaluated when self is x2, and otherX is x1.
>>>> The occurrence of two evaluations per pair leads to redundant
>>>> checking in my case, and so being able to restrict this (to sets of
>>>> instances) would be great. Do you have any suggestions? I may be
>>>> asking something misguided so apologies in advance.
>>>>
>>>> In general, it would seem quite handy and natural to be able to
>>>> express a constraint for n-tuples of instances, e.g., for
>>>> pairs/triples of instances. This though, would give rise to a
>>>> difficulty when referring to the context, self, directly; but perhaps
>>>> it could be referenced via a Collection called self, e.g., self(0),
>>>> denoting self.at(0), self(1), etc?
>>>>
>>>> Best,
>>>>
>>>> Edd
>>>>
>>
|
|
|
Goto Forum:
Current Time: Wed Sep 25 15:54:41 GMT 2024
Powered by FUDForum. Page generated in 0.06417 seconds |
] 
Search
Help
Register
Login
Home
