Home » Modeling » OCL » abstract derive function
|
| Re: abstract derive function [message #69932 is a reply to message #69911] |
Fri, 17 April 2009 12:45   |
|
--=-rY9yCF+6T34cgWOzFpyd
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Marc,
The signature of the operation, as defined in your model, does this
simply by declaring what the operation's parameters are.
If you need to stipulate that some parameters must not be used in
computing the operation's result, then that is not possible. OCL cannot
express constraints limiting the access to variables. The best that you
can do is a postcondition constraint requiring that certain messages
(operation calls or signal sends) not occur during the execution of the
operation body, but that is a wider scope than the operation itself (it
would also include other concurrent invocations on the same objects in
other contexts).
I'm not sure that I understood your intent ...
FYI, a let operation is simply a means of defining local variables for
simplifying the structure of an expression.
HTH,
Christian
On Thu, 2009-04-16 at 15:18 +0000, Terrasson Marc wrote:
> Hi.
>
> In OCL, we can specify derived values :
>
> context My_Class::My_Method : My_Type
> derive param1 + param2
>
>
> I want to specify from which input parameters derive a value (here it is
> param1 and param2) but abstract the body (the addition).
> Is it possible? And if it is, how can I do?
>
> I thought to use let expression but it didn't work (or I mistook when I
> wrote my expression)
>
> Regards.
>
> Marc
>
--=-rY9yCF+6T34cgWOzFpyd
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Marc,<BR>
<BR>
The signature of the operation, as defined in your model, does this simply by declaring what the operation's parameters are.<BR>
<BR>
If you need to stipulate that some parameters must not be used in computing the operation's result, then that is not possible. OCL cannot express constraints limiting the access to variables. The best that you can do is a postcondition constraint requiring that certain messages (operation calls or signal sends) not occur during the execution of the operation body, but that is a wider scope than the operation itself (it would also include other concurrent invocations on the same objects in other contexts).<BR>
<BR>
I'm not sure that I understood your intent ...<BR>
<BR>
FYI, a let operation is simply a means of defining local variables for simplifying the structure of an expression.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2009-04-16 at 15:18 +0000, Terrasson Marc wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi.
In OCL, we can specify derived values :
context My_Class::My_Method : My_Type
derive param1 + param2
I want to specify from which input parameters derive a value (here it is
param1 and param2) but abstract the body (the addition).
Is it possible? And if it is, how can I do?
I thought to use let expression but it didn't work (or I mistook when I
wrote my expression)
Regards.
Marc
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-rY9yCF+6T34cgWOzFpyd--
|
|
|
| Re: abstract derive function [message #70050 is a reply to message #69932] |
Mon, 27 April 2009 09:44 |
 Terrasson Marc
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi Christian and thank you for your reply.
Actually, in order to perform information/data flow analysis, I want to
stipulate which inputs will intervene in the modification of which outputs.
But as you said :
OCL cannot express constraints limiting the access to variables.
It seems I have to find another way to do so.
Unless I am wrong? Tell me I am, please :'(
Thank again.
Marc.
Christian W. Damus wrote:
> Hi, Marc,
> The signature of the operation, as defined in your model, does this
> simply by declaring what the operation's parameters are.
> If you need to stipulate that some parameters must not be used in
> computing the operation's result, then that is not possible. OCL cannot
> express constraints limiting the access to variables. The best that you
> can do is a postcondition constraint requiring that certain messages
> (operation calls or signal sends) not occur during the execution of the
> operation body, but that is a wider scope than the operation itself (it
> would also include other concurrent invocations on the same objects in
> other contexts).
> I'm not sure that I understood your intent ...
> FYI, a let operation is simply a means of defining local variables for
> simplifying the structure of an expression.
> HTH,
> Christian
> On Thu, 2009-04-16 at 15:18 +0000, Terrasson Marc wrote:
>> Hi.
>>
>> In OCL, we can specify derived values :
>>
>> context My_Class::My_Method : My_Type
>> derive param1 + param2
>>
>>
>> I want to specify from which input parameters derive a value (here it is
>> param1 and param2) but abstract the body (the addition).
>> Is it possible? And if it is, how can I do?
>>
>> I thought to use let expression but it didn't work (or I mistook when I
>> wrote my expression)
>>
>> Regards.
>>
>> Marc
>>
|
|
|
| Re: abstract derive function [message #70071 is a reply to message #69932] |
Mon, 27 April 2009 10:16 |
Matteo Bordin
Messages: 19
Registered: July 2009 |
Junior Member |
|
|
Hello Christian,
just to clarify Marc's question (Marc is a collegue of mine).
We are investigating on a way to describe contracts with UML. OCL
pre/post conditions well serve for the purpose of specifying the
behavioural contract, but we would also like to express information/data
flow contracts. In our context, an information flow contract specifies
from which (in or inout) parameters and class properties the final value
of an (in) out parameters may be derived.
It is clear to me that a post condition can be seen as a "super-set" of
an information flow contract - i.e. you can extract an information flow
contract from a post condition. Unfortunately, for an information flow
contract to be extracted from a postcondition, we would require
postconditions to be ALWAYS and COMPLETELY specified: this is unlikely,
and in general would be too much of an effort for the average user. This
is why we were interested in using OCL "derives" annotation.
In the case "derives" annotation could not be used (as it seems), we
would consider activity diagrams and map an information flow as an
object flow across StructuredFeatureReadAction,
StructuredFeatureWriteAction and Action Parameters.
Thanks you.
Matteo
Christian W. Damus wrote:
> Hi, Marc,
>
> The signature of the operation, as defined in your model, does this
> simply by declaring what the operation's parameters are.
>
> If you need to stipulate that some parameters must not be used in
> computing the operation's result, then that is not possible. OCL cannot
> express constraints limiting the access to variables. The best that you
> can do is a postcondition constraint requiring that certain messages
> (operation calls or signal sends) not occur during the execution of the
> operation body, but that is a wider scope than the operation itself (it
> would also include other concurrent invocations on the same objects in
> other contexts).
>
> I'm not sure that I understood your intent ...
>
> FYI, a let operation is simply a means of defining local variables for
> simplifying the structure of an expression.
>
> HTH,
>
> Christian
>
> On Thu, 2009-04-16 at 15:18 +0000, Terrasson Marc wrote:
>> Hi.
>>
>> In OCL, we can specify derived values :
>>
>> context My_Class::My_Method : My_Type
>> derive param1 + param2
>>
>>
>> I want to specify from which input parameters derive a value (here it is
>> param1 and param2) but abstract the body (the addition).
>> Is it possible? And if it is, how can I do?
>>
>> I thought to use let expression but it didn't work (or I mistook when I
>> wrote my expression)
>>
>> Regards.
>>
>> Marc
>>
|
|
|
| Re: abstract derive function [message #70090 is a reply to message #70071] |
Tue, 28 April 2009 12:10 |
|
--=-qjITXYufTfsbQi3TR9mZ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Matteo,
Yes, if you're modeling behaviour with Actions and Activities, then you
will certainly be able to constrain the modeling of *methods* for your
operations. That makes sense to me, and it matches what your intent is,
anyway; constraining the specification doesn't really mean anything :-)
Cheers,
Christian
On Mon, 2009-04-27 at 12:16 +0200, Matteo Bordin wrote:
> Hello Christian,
>
> just to clarify Marc's question (Marc is a collegue of mine).
>
> We are investigating on a way to describe contracts with UML. OCL
> pre/post conditions well serve for the purpose of specifying the
> behavioural contract, but we would also like to express information/data
> flow contracts. In our context, an information flow contract specifies
> from which (in or inout) parameters and class properties the final value
> of an (in) out parameters may be derived.
>
> It is clear to me that a post condition can be seen as a "super-set" of
> an information flow contract - i.e. you can extract an information flow
> contract from a post condition. Unfortunately, for an information flow
> contract to be extracted from a postcondition, we would require
> postconditions to be ALWAYS and COMPLETELY specified: this is unlikely,
> and in general would be too much of an effort for the average user. This
> is why we were interested in using OCL "derives" annotation.
>
> In the case "derives" annotation could not be used (as it seems), we
> would consider activity diagrams and map an information flow as an
> object flow across StructuredFeatureReadAction,
> StructuredFeatureWriteAction and Action Parameters.
>
> Thanks you.
>
> Matteo
-----8<-----
--=-qjITXYufTfsbQi3TR9mZ
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Matteo,<BR>
<BR>
Yes, if you're modeling behaviour with Actions and Activities, then you will certainly be able to constrain the modeling of *methods* for your operations. That makes sense to me, and it matches what your intent is, anyway; constraining the specification doesn't really mean anything :-)<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Mon, 2009-04-27 at 12:16 +0200, Matteo Bordin wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hello Christian,
just to clarify Marc's question (Marc is a collegue of mine).
We are investigating on a way to describe contracts with UML. OCL
pre/post conditions well serve for the purpose of specifying the
behavioural contract, but we would also like to express information/data
flow contracts. In our context, an information flow contract specifies
from which (in or inout) parameters and class properties the final value
of an (in) out parameters may be derived.
It is clear to me that a post condition can be seen as a "super-set" of
an information flow contract - i.e. you can extract an information flow
contract from a post condition. Unfortunately, for an information flow
contract to be extracted from a postcondition, we would require
postconditions to be ALWAYS and COMPLETELY specified: this is unlikely,
and in general would be too much of an effort for the average user. This
is why we were interested in using OCL "derives" annotation.
In the case "derives" annotation could not be used (as it seems), we
would consider activity diagrams and map an information flow as an
object flow across StructuredFeatureReadAction,
StructuredFeatureWriteAction and Action Parameters.
Thanks you.
Matteo
</PRE>
</BLOCKQUOTE>
-----8<-----
</BODY>
</HTML>
--=-qjITXYufTfsbQi3TR9mZ--
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:50:02 GMT 2024
Powered by FUDForum. Page generated in 0.04016 seconds |
] 
Search
Help
Register
Login
Home
