Home » Eclipse Projects » Papyrus for Real Time » Sharing attributes(attribute sharing or parameter passing between capsules)
| Sharing attributes [message #1792649] |
Fri, 20 July 2018 14:08  |
 Sneha Sahu
Messages: 20
Registered: June 2018 |
Junior Member |
|
|
I have 2 capsules with few attributes of their own.
For instance, cap1->atr1.1, atr1.2 & cap2->atr2.1, atr2.2, atr2.3
Now, I want to use the value of atr2.1 to compute the next value of atr1.1
Is there a possibility to pass int values as parameter,
or,
any other way to read the current value of an attribute from another capsule?
(either at capsule level or through port communication )
I tried to make an object of cap2 in cap1 and the read cap2->atr1. But getting error saying cap2 'has no member named atr1' & 'cap2 was not declared in the scope of cap1'
Please assist.
Thanks and Regards,
Sneha Sahu
[Updated on: Fri, 20 July 2018 14:09] Report message to a moderator |
|
|
| Re: Sharing attributes [message #1792661 is a reply to message #1792649] |
Fri, 20 July 2018 15:47  |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
By "passing in values as parameters" I assume you mean passing them as part of a message from one capsule to another. If so, then yes, you can do that, and not just for ints but for any type using protocol message parameters.
When you create a protocol message (Model Explorer->right-click the protocol and select either in, out or inout protocol message) and select it, in the Properties view under the UML-RT tab you see a table of message parameters. If you click the green [+] button, it will give you a choice of types. If you created the model as a C++ model or manually added the AnsiCLibrary, you will see Ansi C types. But you should also see UML primitive types. You can also select user defined classes as the type of the data. Furthermore, you can add several parameters. By default the parameter's name is 'data', but you can change it by clicking on it in that table.
See the attached model as an example. It has a protocol called Protocol1 with an out message called 'm' that has a single parameter called 'data' of type int. There are capsules Capsule1 with attribute x, and port p1 of type Protocol1 and Capsule2 with attribute y and port ~p1 of type Protocol1 as well. Inside Capsule1 you can send the value of attribute x as follows:
In general:
port_name.message_name(parameter1, ..., parametern).send();
So you just need to use one of your local attributes as a message parameter.
On the receiving side, the action of the transition receiving the message (as well as the entry action of the transition's target state) you have direct access to the parameters of the message. So in this model, in Capsule2 there is a transition that receives m, and in its action you can use the variable 'data' which has type int (as declared in the protocol), so you can assign it to the local attribute y, e.g.
This is the standard approach to share data between capsules.
Technically you could have access to attributes in other classes as the generated code is C++, and you declare the attributes to be public and add a dependency between the capsules. But I strongly discourage it. You really should not try accessing attributes directly from other capsules. There are several reasons for this: first, it is not allowed in UML-RT. It can technically be done with this tool because it generates C++ and C++ allows this sort of thing, but UML-RT itself doesn't, and if in the future there is a different generator there is no guarantee that this sort of thing would be allowed, so your model would not work then. The second reason is that it is not allowed by UML-RT because the whole point of a capsule is to encapsulate data and behaviour: hide it from its environment (other capsules) so that the only means of communication is through ports. And the reason for this is well known by anyone with experience developing concurrent systems: capsules are concurrent, active classes, this is, their instances can be thought of as (logical) threads executing independently of each other and if concurrent threads communicate with each other by sharing variables (which is effectively what happens when a capsule has access to the attribute of another capsule) then you quickly run into a very large number of safety (consistency) problems and errors, like multiple threads attempting to write on the same variable, or one reading while another is writing resulting in an inconsistent state, etc. In the case of capsules, since they are logically concurrent, you do not have any guarantees about how the runtime system schedules their execution, and therefore you cannot always predict the exact order in which actions get executed, which will lead to the problems mentioned above. And to deal with these problems, you have to introduce complicated mechanisms such as semaphores, locks, mutexes, etc. Not only this makes the program more complicated and difficult to understand, but also, in the context of Papyrus-RT-generated code, these mechanisms will interfere with the runtime system and will likely lead to deadlock and other nasty situations. For all these reasons, UML-RT was designed such that direct access to shared memory is not allowed and all capsule communication should be through message passing. I recommend you to read a bit more on concurrent programming, message passing vs shared memory, mutual exclusion, etc. to understand why such direct access would be a very bad idea. There are vast amounts of literature on the subject, but you can google a bit on these issues to find out.
|
|
| |
Goto Forum:
Current Time: Sat Apr 27 04:39:55 GMT 2024
Powered by FUDForum. Page generated in 0.03087 seconds |
] 
Search
Help
Register
Login
Home
