Eclipse Community Forums: OCL » OCL in Transition's Guard to access trigger properties

Help

Home

Home » Modeling » OCL » OCL in Transition's Guard to access trigger properties

Show: Today's Messages :: Show Polls :: Message Navigator

OCL in Transition's Guard to access trigger properties [message #481353]

Thu, 20 August 2009 15:19

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Hi all,

i have a problem concerning guards and transitions and triggers. The
semnatics of an UML StateMachine is, that it is possible to access the
information carried by an event within the expression of a guard. In my
case, i want to compare a signal value with a value of the context
classifier of my transition's guard. My current approach is

self.data = self.Transition.Trigger.Signal.data

But i think this is not correct. Unfortunately, there is no convenient
example for this, mostly the example state only pseudo-ocl.

Thanks

Timothy

Report message to a moderator

Re: OCL in Transition's Guard to access trigger properties [message #481393 is a reply to message #481353]

Thu, 20 August 2009 19:03

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Timothy

Please ask UML questions on the UML newsgroup.

You will need to privide much more context to identify 'self' to allow
anyone not teleppathic to understand. The use of
Transition.Trigger.Signal looks really wierd. They look like class not
property names, but what is 'self'? Also do you mean to do so many
implicit collects?

Regards

Ed Willink

Timothy Marc wrote:
> Hi all,
>
> i have a problem concerning guards and transitions and triggers. The
> semnatics of an UML StateMachine is, that it is possible to access the
> information carried by an event within the expression of a guard. In my
> case, i want to compare a signal value with a value of the context
> classifier of my transition's guard. My current approach is
>
> self.data = self.Transition.Trigger.Signal.data
>
> But i think this is not correct. Unfortunately, there is no convenient
> example for this, mostly the example state only pseudo-ocl.
>
> Thanks
>
> Timothy

Report message to a moderator

Re: OCL in Transition's Guard to access trigger properties [message #492125 is a reply to message #481393]

Sun, 18 October 2009 21:36

Balazs Polgar

Messages: 1
Registered: July 2009

Junior Member

Hello,

I'm also interested in the answer for Timothy's question (if I understood him well):

We have a transition that is triggered by a SignalEvent, and want to formulate the guard as an OCL expression (this is possible according to the OCL standard). The SignalEvent is generated because a Signal is received, which in our case has some attributes. According to the UML standard these attributes can be referenced in the guard expression. The question is how can we do this if we use OCL?

My expectation would be to use these similarly to the attributes of the context (which - in case of guard expressions - is the context of the state machine that contains the transition, i.e., typically the class the behavior of which is described by the state machine). Or similarly as the parameters of an Operation in a pre- or postcondition.

Example:

Signal S
  int targetID  -- an attribute of signal S

Class A
  int ID  -- an attribute of class A 
  ReceptionOfS -- declaration that class A can receive instances of signal S
  statemachine SM -- behavior of A is defined by SM
    transition T -- SM contains this T transition
      trigger: SignalEvent(Si) -- the reception of an Si instance of signal S triggers the transition
      guard: want to check if the targetID in Si is the same as the ID of A

I would expect to write 'ID=targetID' (or maybe 'ID=Si.targetID').

But as far as I have seen it is not supported in the current implementation. Is it right? And if yes are there any plans about it?

Thanks in advance,
Balazs

Report message to a moderator

Re: OCL in Transition's Guard to access trigger properties [message #492141 is a reply to message #492125]

Mon, 19 October 2009 06:12

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Balazs

As in the earlier reply; please ask UML questions on the UML newsgroup.

Don't the ^ or ^^ operators do this?

Regards

Ed Willink

polgar@mit.bme.hu wrote:
> Hello,
>
> I'm also interested in the answer for Timothy's question (if I
> understood him well):
>
> We have a transition that is triggered by a SignalEvent, and want to
> formulate the guard as an OCL expression (this is possible according to
> the OCL standard). The SignalEvent is generated because a Signal is
> received, which in our case has some attributes. According to the UML
> standard these attributes can be referenced in the guard expression. The
> question is how can we do this if we use OCL?
>
> My expectation would be to use these similarly to the attributes of the
> context (which - in case of guard expressions - is the context of the
> state machine that contains the transition, i.e., typically the class
> the behavior of which is described by the state machine). Or similarly
> as the parameters of an Operation in a pre- or postcondition.
>
> Example:
>
>
> Signal S
> int targetID -- an attribute of signal S
>
> Class A
> int ID -- an attribute of class A ReceptionOfS -- declaration that
> class A can receive instances of signal S
> statemachine SM -- behavior of A is defined by SM
> transition T -- SM contains this T transition
> trigger: SignalEvent(Si) -- the reception of an Si instance of
> signal S triggers the transition
> guard: want to check if the targetID in Si is the same as the ID of A
>
>
> I would expect to write 'ID=targetID' (or maybe 'ID=Si.targetID').
>
> But as far as I have seen it is not supported in the current
> implementation. Is it right? And if yes are there any plans about it?
>
> Thanks in advance,
> Balazs
>

Report message to a moderator

Previous Topic:	OCL Parsing order matters! Is there a solution?
Next Topic:	OCL Syntax check

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 07:30:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter