Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Papyrus/Designer/example-walkthrough"
(Created page with "= Qompass Designer Examples = Qompass designer for Papyrus comes with a set of examples. All of these can be accessed via File->New->Example and the category Papyrus examples...") |
(→Producer Consumer) |
||
| Line 16: | Line 16: | ||
== Producer Consumer == | == Producer Consumer == | ||
| − | The producer consumer example consists of two interacting components that are part of the obligatory system component. These components communicate in a data flow style in two different variants. In the first, the (data) consumer is invoked from the environment to push new data. In the second, the consumer component asks for new data. Therefore, the two different variants are | + | The producer consumer example consists of two interacting components that are part of the obligatory system component. These components communicate in a data flow style in two different variants. In the first, the (data) consumer is invoked from the environment to push new data. In the second, the consumer component asks for new data. Therefore, the two different variants are denoted as Push and Pull-Consumer respectively. |
| − | + | ||
| + | The flow-port characteristic is specified by means of the port-kind attribute within the FCM profile. The port kind is associated with mapping rules that determine which interfaces must be implemented by a port (derived provided) and which interfaces can be called through a port. In case of the data-flow ports, the ports correspond | ||
| + | |||
| + | * Push-producer: required interface with single "push" operation | ||
| + | * Push-consumer: provided interface with single "push" operation (same interface as for push producer) | ||
| + | * Pull-consumer: required interface with pull operation and boolean query whether data is available. | ||
| + | |||
| + | In the push variant, the producer can directly call the push operation that is provided by a consumer. | ||
| + | In case of the pull variant, both components call operations to obtain data. Thus, an additional component is needed in order to implement the interaction. In case of the example, this is a FIFO queue that provides suitable ports for the consumer and producer. | ||
| + | |||
| + | The hardware architecture is unchanged compared to the Hello world example | ||
Revision as of 18:19, 9 June 2014
Qompass Designer Examples
Qompass designer for Papyrus comes with a set of examples. All of these can be accessed via File->New->Example and the category Papyrus examples. A hosting project must already exist.
All examples contain embedded comments. In the sequel, we go through some of the examples, starting with a simple HelloWorld program based on Qompass.
Hello World
The Hello World example consists of two software components, System and HelloWorld. The former is a component that all Qompass applications use. It represents the software architecture. The HelloWorld components is a part within the system, i.e. the system has or contains a Hello World component. On the UML level, the part is attribute with composite aggregation typed with the HelloWorld component. It is important to separate the composition on the instance level from the definition of components: the component HelloWorld is not defined within the system, its instances can also appear in other composites.
The hardware model has a quite similar structure compared to the software components: A component representing the hardware architecture contains a single node (called MonoNode) on which we want to deploy our Hello World component. In case of the Hello World component, the main instance is the instance of the system, containing a hello-world component as a sub-instance.
Producer Consumer
The producer consumer example consists of two interacting components that are part of the obligatory system component. These components communicate in a data flow style in two different variants. In the first, the (data) consumer is invoked from the environment to push new data. In the second, the consumer component asks for new data. Therefore, the two different variants are denoted as Push and Pull-Consumer respectively.
The flow-port characteristic is specified by means of the port-kind attribute within the FCM profile. The port kind is associated with mapping rules that determine which interfaces must be implemented by a port (derived provided) and which interfaces can be called through a port. In case of the data-flow ports, the ports correspond
- Push-producer: required interface with single "push" operation
- Push-consumer: provided interface with single "push" operation (same interface as for push producer)
- Pull-consumer: required interface with pull operation and boolean query whether data is available.
In the push variant, the producer can directly call the push operation that is provided by a consumer. In case of the pull variant, both components call operations to obtain data. Thus, an additional component is needed in order to implement the interaction. In case of the example, this is a FIFO queue that provides suitable ports for the consumer and producer.
The hardware architecture is unchanged compared to the Hello world example