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.
Papyrus/customizations/robotics/modular
Contents
Modular and Role based design
Supported diagrams
Component definition diagram
A component definition diagram models the internal structure and external interface of a component. The former includes parameters, activities and functions, the latter ports that provide or require services
Service definition
The goal of the service definition diagram is to defines services, as defined in the RobMoSys service meta-model: A Service allows interaction (i.e. regular exchange of information) between software components. A Service consists of service-properties (defined in an external metamodel) and a communication-pattern-usage.
In the UML realisation, we have used the concepts of templates and template binding. A communication pattern is defined as a template with one or more formal parameters. A service definition binds the formal parameters to concrete communication objects, for instance the formal parameter ``Message of a Push pattern is bound to a concrete data type definition.
Datatype definition diagram
This diagram is used to define data types, including those with variable elements.
The Palette it shown below.
The UML realisation is based on datatype definitions.
Not all data types are communication objects. 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.
Toggle between data-type and communication object
System assembly
A set of component instances that are ``wired together via their ports. At this level, it is also possible to configure component instances.
