Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Papyrus/Designer/example-walkthrough"

m (Francois.le-fevre.cea.fr moved page Papyrus/Qompass/designer/example-walkthrough to Papyrus/Designer/example-walkthrough: product name changed)
Line 1: Line 1:
= Qompass Designer Examples =
+
= Papyrus SW 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.
+
Papyrus SW designer 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.
+
All examples contain embedded comments. In the sequel, we go through some of the examples, starting with a simple HelloWorld program.
  
  
Line 9: Line 9:
  
  
In the sequel, we outline a simple hello world example using qompass designer. Please note that the example
+
In the sequel, we outline a simple hello world example provided by SW designer. Please note that the example
can be found via File->New->Example in the category Qompass examples. There are also two cheat-sheets that explain how
+
can be found via File->New->Example in the category Papyrus Examples. There are also two cheat-sheets that explain how
 
to create your own example from scratch.
 
to create your own example from scratch.
  
As for all Qompass examples, there are three different parts that needs to be modeled
+
As for all component-based SW Designer examples, there are three different parts that needs to be modeled
  
 
* The software components
 
* The software components
Line 19: Line 19:
 
* A so-called deployment plan, i.e. a set of component instance definitions along with their configuration and allocation of software components to hardware nodes
 
* A so-called deployment plan, i.e. a set of component instance definitions along with their configuration and allocation of software components to hardware nodes
  
 +
Please note, that the information above is no longer true for all SW designer examples - some do not use a deployment plan, as the application is not a distributed application. in the same context, a platform description is also optional if the application is running in a single process and the application code uses OS calls, if needed.
  
 
In the sequel, we will go through all of these items with a focus on the the definition of the software components.
 
In the sequel, we will go through all of these items with a focus on the the definition of the software components.
Line 28: Line 29:
 
==== The hello-world component ====
 
==== The hello-world component ====
  
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 Hello World example consists of two software components, System and HelloWorld. The former is a component that all SW designer 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 hello-world component is shown in the following screen shot.
 
The hello-world component is shown in the following screen shot.
Line 38: Line 39:
  
 
The hello world component inherits from a component called <em>CStart</em>. This is an abstract component defined in the
 
The hello world component inherits from a component called <em>CStart</em>. This is an abstract component defined in the
Qompass core model library. It owns a port (called start) that provides the pre-defined interface <em>IStart</em>. This
+
core component model library. It owns a port (called start) that provides the pre-defined interface <em>IStart</em>. This
 
interface has a single operation <em>run</em>. Components that provide an interface via a port need to implement this
 
interface has a single operation <em>run</em>. Components that provide an interface via a port need to implement this
 
interface. This include ports that are inherited. In our case, the hello world component needs to implement the <em>IStart</em>
 
interface. This include ports that are inherited. In our case, the hello world component needs to implement the <em>IStart</em>
 
interface, i.e. contain an operation "run" as well as a behavior for this operation.<br>
 
interface, i.e. contain an operation "run" as well as a behavior for this operation.<br>
Qompass supports the user by automatically creating derived operations for interfaceS provided via a port, i.e. the operation
+
SW Designer supports the user by automatically creating derived operations for interfaceS provided via a port, i.e. the operation
 
signature is copied (and synchronized on demand) from the interface. The developer needs to provide behavior. In UML, behavior
 
signature is copied (and synchronized on demand) from the interface. The developer needs to provide behavior. In UML, behavior
 
can be specified either via activities or by embedding code in a programming language (opaque behavior) into the model.
 
can be specified either via activities or by embedding code in a programming language (opaque behavior) into the model.
Currently, Qompass focuses on the latter,in particular in form of embedded C++ code. A simple C/C++ view allows to enter
+
Currently, Designer focuses on the latter,in particular in form of embedded C++ code. A simple C/C++ view allows to enter
 
the code, as shown in the following screenshot (there is ongoing work concerning a CDT editor integration)
 
the code, as shown in the following screenshot (there is ongoing work concerning a CDT editor integration)
  
Line 62: Line 63:
 
==== A system component ====
 
==== A system component ====
  
All Qompass applications need to define a top-level component, typically called <em>System</em> that aggregates its components,
+
All SW Designer applications need to define a top-level component, typically called <em>System</em> that aggregates its components,
 
in our case the hello-world component.  It is defined by means of a composite class, contained components are
 
in our case the hello-world component.  It is defined by means of a composite class, contained components are
 
modeled via attributes (use composite aggregation for these) typed by the contained components. Note that we define a role (or part)
 
modeled via attributes (use composite aggregation for these) typed by the contained components. Note that we define a role (or part)
Line 99: Line 100:
 
instance to processing resources such as threads or directly to a node of the platform definition.
 
instance to processing resources such as threads or directly to a node of the platform definition.
  
In case of the hello world component, the message that should be written is a configuration attribute. Qompass provides a
+
In case of the hello world component, the message that should be written is a configuration attribute. SW Designer provides a
 
dialog that simplifies the configuration of this attribute. The dialog lists instances and their configuration attributes and
 
dialog that simplifies the configuration of this attribute. The dialog lists instances and their configuration attributes and
 
enables the user to provide a value in a text field. On the model level, a corresponding slot and a value specification are
 
enables the user to provide a value in a text field. On the model level, a corresponding slot and a value specification are

Revision as of 10:53, 1 July 2021

Papyrus SW Designer Examples

Papyrus SW designer 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.


Hello World

In the sequel, we outline a simple hello world example provided by SW designer. Please note that the example can be found via File->New->Example in the category Papyrus Examples. There are also two cheat-sheets that explain how to create your own example from scratch.

As for all component-based SW Designer examples, there are three different parts that needs to be modeled

  • The software components
  • An abstraction of the hardware platform
  • A so-called deployment plan, i.e. a set of component instance definitions along with their configuration and allocation of software components to hardware nodes

Please note, that the information above is no longer true for all SW designer examples - some do not use a deployment plan, as the application is not a distributed application. in the same context, a platform description is also optional if the application is running in a single process and the application code uses OS calls, if needed.

In the sequel, we will go through all of these items with a focus on the the definition of the software components.

Definition of software components

The example consists of two components, detailed below

The hello-world component

The Hello World example consists of two software components, System and HelloWorld. The former is a component that all SW designer 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 hello-world component is shown in the following screen shot.

PapyrusQompass-examples-hw-hello-world.png
The Hello World component

The hello world component inherits from a component called CStart. This is an abstract component defined in the core component model library. It owns a port (called start) that provides the pre-defined interface IStart. This interface has a single operation run. Components that provide an interface via a port need to implement this interface. This include ports that are inherited. In our case, the hello world component needs to implement the IStart interface, i.e. contain an operation "run" as well as a behavior for this operation.
SW Designer supports the user by automatically creating derived operations for interfaceS provided via a port, i.e. the operation signature is copied (and synchronized on demand) from the interface. The developer needs to provide behavior. In UML, behavior can be specified either via activities or by embedding code in a programming language (opaque behavior) into the model. Currently, Designer focuses on the latter,in particular in form of embedded C++ code. A simple C/C++ view allows to enter the code, as shown in the following screenshot (there is ongoing work concerning a CDT editor integration)

PapyrusQompass-examples-c-cpp-view.png
C/C++ view

The code outputs "Hello World" and an additional message that is an attribute of the hello world component. The attribute message is declared as a UML String, but it does not have a particular contents on the level of the component definition. We will see in the section explaining deployment plans how this contents can be defined.

The specific start port enables a component to get the initial control. Its run operation is called at system start-up by a generated boot-loader.

A system component

All SW Designer applications need to define a top-level component, typically called System that aggregates its components, in our case the hello-world component. It is defined by means of a composite class, contained components are modeled via attributes (use composite aggregation for these) typed by the contained components. Note that we define a role (or part) within a composition, the hello world component declaration is not part of the system class. This role corresponds to an instance of a class in the deployment plan below.
In our simple hello world example, there is a single component only. Thus, there are no connections between components (so called assembly). Take a look at the producer-consumer example to see how the assembly can be done.

PapyrusQompass-examples-hw-system.png
The System component


Definition of an abstract hardware platform

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.

The main objective of this step is to define computational nodes on which the software can be allocated. A node is-a stereotyped class that defines for the moment only quite basic information about a computational node, such as the provided memory and operating system.


The following screenshot defines a platform for the Hello World component. The HWArchitecture class has a similar function for the platform as the System class has for the software: it represents the used notes and their interconnections. In this simple example, the hardware architecture contains a single node.

PapyrusQompass-examples-hw-platform.png
A platform for the Hello World component

Definition of a deployment plan

A deployment plan is a collection of instance specifications, stored within a UML package. It has two objectives. The first is to configure an instance of a component, i.e. to provide values for configuration attributes. The second is to allocate instance to processing resources such as threads or directly to a node of the platform definition.

In case of the hello world component, the message that should be written is a configuration attribute. SW Designer provides a dialog that simplifies the configuration of this attribute. The dialog lists instances and their configuration attributes and enables the user to provide a value in a text field. On the model level, a corresponding slot and a value specification are produced.

PapyrusQompass-examples-hw-configure-instance.png
configure instance dialog

The allocation is also simplified by means of a custom dialog. The instances of a system are shown by means of a tree structure and the user can either allocate leafs or a parent node. In our case, the whole system should be allocated to node "monoNode", as shown in the screenshot below. On the model level, allocation is a MARTE relationship.

PapyrusQompass-examples-hw-allocate.png
Allocation dialog

The last screenshot shows the resulting deployment plan, the package containing two instance specifications and the slots along with the configured values. You also see the allocation of the system component. Note, that the visualization of all instances in a diagram is often not useful for larger applications, since the graphical visualization does not provide additional information compared to the tree structure depicted by the dedicated dialog.

PapyrusQompass-examples-hw-deployment-plan.png
Resulting deployment plan

The last step is the code generation which can be executed via the context menu of a deployment plan. The code generation creates an CDT project which can be compiled and executed.

Compilation, Execution and Debugging

Use the "Run as->Local C++ application" menu entry to execute the sample application. You should see the text "Hello World: Test message".

If the compilation run fine and you do not see screen output, have a look at the troubleshooting section.

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

Copyright © Eclipse Foundation, Inc. All Rights Reserved.