Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Papyrus for Real Time » Using timeout in action code and querying current state in another state machine
Using timeout in action code and querying current state in another state machine [message #1769292] Fri, 28 July 2017 17:00 Go to next message
reza ahmadi is currently offline reza ahmadiFriend
Messages: 47
Registered: September 2016
Member
Hi,

A couple of quick questions..

1. I wonder what would be the best way to use timeout event in action code (rather than as a trigger on transitions), e.g., in an state entry we have:

//setting the timer
timer1.informIn(UMLRTTimespec(1,0));

//Now I want to wait til timer1 timeouts
while(!timer1.timeout()) {} //something like this?

I have another question as well.
2. I wonder if it is possible to query current state in other state-machines. Assume we have two capsule parts connected to each other and one of the parts wants to know in what state the other capsule part currently is? Do we have utilities for these kind of things?

Thanks!

[Updated on: Fri, 28 July 2017 21:52]

Report message to a moderator

Re: Using timeout in action code and getting to know current state in another state machine [message #1769294 is a reply to message #1769292] Fri, 28 July 2017 17:24 Go to previous messageGo to next message
Ernesto Posse is currently offline Ernesto PosseFriend
Messages: 438
Registered: March 2011
Senior Member
The short answer to both of your questions is that there is no (simple) way of doing either.

I think you both of your questions suggest a design problem. Your design seems to be contrary to the UML-RT design philosophy or its semantics.

First timeouts: the idea of a timeout is to move a capsule from one state to another. Action code occurs in either a transition or in the entry or exit action of a state. The semantics of UML-RT state machines is a *run-to-completion* semantics. This is, whenever a message arrives, the state machine is an a (stable) state, an enabled transition is selected, and the transition chain is fully followed until it reaches another (stable) state. This entails the execution of exit actions, transition actions and entry actions according to the path of the transition chain. If you where able to stop in an action, for a timeout (or any other reason, like an infinite loop), you would not reach a stable state, and as such you would be blocking the capsule's controller and thus, blocking all capsule instances in the same controller. Hence, actions are intended to be *simple*. They should not do any kind of thing that could be blocking. In particular they should not wait for timeouts from a timing port, and they should not expect messages on ports and they should not engage in non-terminating loops or loops that expect any kind of external input. For this reason, the model library, such as the Timing protocol, do not offer operations to wait for timeouts.

The second issue (querying another capsule's state) is not allowed for a different reason, but it's also the semantics of UML-RT and quite intentional. The state of a capsule is internal. Querying another capsule's state would allow you to observe the internals of another capsule. The whole point of a capsule is to *encapsulate* its state (hence the name "capsule"). The only way in which capsules can interact is by exchanging messages through their ports. The interface of a capsule is its set of ports, and it defines the only points of contact between the capsule and its environment. And this is for a good reason. The theory and practice of concurrent programming has shown that direct access to someone else's internal state leads to a million problems. This is why UML-RT was designed this way.

If you really need to know the state of another capsule, that capsule should allow it (someone will tell you something private only if they want to let you know it). A simple way of doing this is to put all your states in a composite state and have an internal transition in this state that responds to a query message. (A transition from the composite state to itself with kind == Internal). An internal transition like this would be enabled in all states inside the composite state.

You might want to define the query message in a separate protocol which also defined the response. The response message should have a parameter, possibly a String, to encode the state. Then, in the action of that internal transition you can reply with the current state string. For example, something like:

stateQueryPort.currentStateResponseMessage(getCurrentStateString()).send();


where your capsule has a port called "stateQueryPort" typed by a protocol that has a message "currentStateResponseMessage(getCurrentStateString())" and a message "stateQuery" which is used as the trigger for that transition.

[Updated on: Fri, 28 July 2017 17:35]

Report message to a moderator

Re: Using timeout in action code and getting to know current state in another state machine [message #1769297 is a reply to message #1769294] Fri, 28 July 2017 18:13 Go to previous message
reza ahmadi is currently offline reza ahmadiFriend
Messages: 47
Registered: September 2016
Member
Thanks Ernesto!
Previous Topic:Changing return type of owned operations of classes
Next Topic:Passive Class with Usermade attribute type
Goto Forum:
  


Current Time: Tue Dec 03 08:10:03 GMT 2024

Powered by FUDForum. Page generated in 0.77602 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top