Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » OCL in Transition's Guard to access trigger properties
OCL in Transition's Guard to access trigger properties [message #481353] Thu, 20 August 2009 11:19 Go to next message
Timothy Marc is currently offline 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
Re: OCL in Transition's Guard to access trigger properties [message #481393 is a reply to message #481353] Thu, 20 August 2009 15:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4036
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
Re: OCL in Transition's Guard to access trigger properties [message #492125 is a reply to message #481393] Sun, 18 October 2009 17:36 Go to previous messageGo to next message
Balazs Polgar is currently offline 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
Re: OCL in Transition's Guard to access trigger properties [message #492141 is a reply to message #492125] Mon, 19 October 2009 02:12 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4036
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
>
Previous Topic:OCL Parsing order matters! Is there a solution?
Next Topic:OCL Syntax check
Goto Forum:
  


Current Time: Tue Sep 02 05:24:44 EDT 2014

Powered by FUDForum. Page generated in 0.04429 seconds