Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Papyrus/customizations/robotics/servicedef"
| Line 1: | Line 1: | ||
| − | = Service definition | + | = Service definition principle = |
| − | A service | + | Defining a service in Papyrus for Robotics is defining a communication mean between components. A service is indeed a way to synchronize and exchange data between components. It is a generic mechanism, i.e. it is reusable between several components and it is not component-specific. |
| + | |||
| + | A service definition is based on a given communication pattern and on a set of associated Communication Objects. Service definitions reference one of the 4 communication patterns identified in RobMoSys. Depending on the communication pattern, a service definition needs to reference one or more communication objects, i.e. the object(s) that are exchanged by an interaction. This is outlined in the following for each pattern: | ||
| − | + | * '''Push''': a single "message" element | |
| + | * '''Send''': a single "message" element | ||
| + | * '''Query''': a "request" message and a corresponding "reply" message | ||
| + | * '''Event''': a "message", a "parameter" and a "state" object | ||
| − | + | For more details on each pattern, see [[https://robmosys.eu/wiki/_media/modeling:metamodels:patternsemmantics.png communication patterns]]. A new '''action/coordination''' pattern is currently under definition with a "goal", a "response" and a "feedback" object. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | A Communication Object defines the data conveyed by a given service. Communication objects and data types have both a set of typed attributes. The only difference is that communication objects can directly be referenced from service definitions. In order to avoid duplicates, the palette of the diagram only enables the creation of the different data-type variants. At any moment, a data-type can be converted into a communication object and vice versa, as shown in the following dialog: | |
| + | <center> | ||
| + | [[Papyrus-customizations-robotics-datatype-commobj-convert.png]]<br/> | ||
| + | DataType to CommunicationObject conversion menu | ||
| + | </center> | ||
| − | + | == How to edit == | |
| − | + | We can create a service definition with Papyrus for Robotics in a specific service definition model. We use the palette to create a new service definition. The tool will prompt for the different communications objects. They are either already defined in another service definition model or edited in the service definition model itself. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | Papyrus | + | |
| − | + | ||
| − | + | ||
| − | + | ||
It is recommended to use a textual editor for editing the data types. This editor is available via the F2 short-cut or inside the property view (the latter is recommended, since the editors directly in the diagram use a constraint area). | It is recommended to use a textual editor for editing the data types. This editor is available via the F2 short-cut or inside the property view (the latter is recommended, since the editors directly in the diagram use a constraint area). | ||
| − | As shown below, Papyrus offers an xtext editor provided content assist (control-space) and validation. If the validation does not pass, the editor contents is stored in an annotation awaiting corrections. | + | As shown below, Papyrus offers an xtext editor provided content assist (control-space) and validation. If the validation does not pass, the editor contents is stored in an annotation awaiting corrections. We can specify attributes along with their type and a comment which becomes part of the attribute's description. In order to obtain completion assistance, we write the prefix of package containing the type (but please note that this only covers models already loaded into the resource set - use the type selection attribute to load additional registered models). |
| − | + | ||
<center> | <center> | ||
| Line 51: | Line 30: | ||
Textual editor for communication objects, data types and enumerations | Textual editor for communication objects, data types and enumerations | ||
</center> | </center> | ||
| + | |||
| + | == A service definition from scratch == | ||
| + | |||
| + | |||
| + | |||
| + | TO BE COMPLETED LATER | ||
Revision as of 11:15, 6 August 2020
Service definition principle
Defining a service in Papyrus for Robotics is defining a communication mean between components. A service is indeed a way to synchronize and exchange data between components. It is a generic mechanism, i.e. it is reusable between several components and it is not component-specific.
A service definition is based on a given communication pattern and on a set of associated Communication Objects. Service definitions reference one of the 4 communication patterns identified in RobMoSys. Depending on the communication pattern, a service definition needs to reference one or more communication objects, i.e. the object(s) that are exchanged by an interaction. This is outlined in the following for each pattern:
- Push: a single "message" element
- Send: a single "message" element
- Query: a "request" message and a corresponding "reply" message
- Event: a "message", a "parameter" and a "state" object
For more details on each pattern, see [communication patterns]. A new action/coordination pattern is currently under definition with a "goal", a "response" and a "feedback" object.
A Communication Object defines the data conveyed by a given service. Communication objects and data types have both a set of typed attributes. The only difference is that communication objects can directly be referenced from service definitions. In order to avoid duplicates, the palette of the diagram only enables the creation of the different data-type variants. At any moment, a data-type can be converted into a communication object and vice versa, as shown in the following dialog:
Papyrus-customizations-robotics-datatype-commobj-convert.png
DataType to CommunicationObject conversion menu
How to edit
We can create a service definition with Papyrus for Robotics in a specific service definition model. We use the palette to create a new service definition. The tool will prompt for the different communications objects. They are either already defined in another service definition model or edited in the service definition model itself.
It is recommended to use a textual editor for editing the data types. This editor is available via the F2 short-cut or inside the property view (the latter is recommended, since the editors directly in the diagram use a constraint area).
As shown below, Papyrus offers an xtext editor provided content assist (control-space) and validation. If the validation does not pass, the editor contents is stored in an annotation awaiting corrections. We can specify attributes along with their type and a comment which becomes part of the attribute's description. In order to obtain completion assistance, we write the prefix of package containing the type (but please note that this only covers models already loaded into the resource set - use the type selection attribute to load additional registered models).
Textual editor for communication objects, data types and enumerations
A service definition from scratch
TO BE COMPLETED LATER