|
| Re: Unexpected message to capsule Instance Top [message #1837526 is a reply to message #1836602] |
Mon, 01 February 2021 19:21  |
 Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
It's not exactly clear what your model actually looks like (you could've attached a screenshot from the tool, or the model itself). It's also unclear whether all "units" are the same type of capsule. And since you don't show the state machine(s) of your capsules, it's unclear what the behaviour is going to be.
Assuming that your "Central control" has exactly one port connected to the "units", when you do a "port.message(data).send()" you are sending the message to *all* capsule instances connected, so if the receiving instances are in a state that is not expecting the message, then you will get that "Unexpected message" in stdout. So the behaviour you are seeing is because of the design of the state machine(s) in your units, and which state each of them is when the "control" sends the message to all.
It sounds like you have a design problem. I assume that all "units" are the same type of capsule. If you send a message to another capsule, by definition (by the semantics of UML-RT) the other capsule is going to react to it somehow, either by taking a transition or showing an "Unexpected message". Therefore, if you send a message to all "unit" capsules, all of them will either take a transition or give you an "Unexpected message". Hence, if you don't want some capsule to do anything, then the "sender" should not send it a message! Now, if all "unit" capsules are connected to the "control" on the same port, the "port.message(data).send()" will send message to all of them. But if you want to send a message to only one of the units, there is an alternative: you set the port's "replication" to some natural number n > 1 (in your case n = 4) so the port becomes an array of n (=4) ports, and in your action code you use the "sendAt" operation: "port.message(data).sendAt(index)" where "index" is the port's index starting from 0. So the logic of the "control" should be the one to decide which "unit" should receive the message.
Alternatively, if you insist on broadcasting the message with "send" instead of "sendAt", you could redesign the state machine(s) of your unit(s) so that they ignore the message from "control" once they are in another state. It is possible for the different "units" to coordinate, once one of them have received the message, but this would involve all of them being able to communicate with one another, perhaps through a shared capsule (maybe the "control" capsule itself), and implement a logic that would be something like this: "I received a message, then I ask the 'control' if no-one else has received the message, and if the 'control' confirms this, I take the message and tell control that I took it". But, while this coordination protocol is a very interesting thing to do *correctly*, it is a tricky one to do *correctly* and likely to end up having race-conditions (for example, two capsules may end up "taking" the message), so, unless you are familiar with this sort of coordination protocols, I would avoid it, and stick to the first option: letting the "control" capsule decide who gets the message and use "sendAt".
[Updated on: Mon, 01 February 2021 19:25] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02963 seconds
] 
Search
Help
Register
Login
Home
