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/input-models"
m (Francois.le-fevre.cea.fr moved page Papyrus/Qompass/designer/input-models to Papyrus/Designer/input-models: product name changed) |
|||
| Line 1: | Line 1: | ||
= Input models = | = Input models = | ||
| − | + | Papyrus designer supports two different kinds of input models. | |
| − | + | - A model that is quite close to the code that should be generated. In this case, a direct code generator is used. This generator supports structural parts of the model such as classes with their attributes and operations as well as relationships such as inheritance. Please continue [[Papyrus/Designer/code-generation|here]] | |
| − | + | ||
| − | + | ||
| − | In the context of this page, the input models are discussed without referring to a specific example. Sample models are available via the | + | - A model containing higher level concepts such as state-machines or component-based aspects. In this case, a model-to-model transformation is applied first to your input model producing a temporary model. The "standard" direct code generator is then applied to the temporary model. |
| + | |||
| + | In case of the 2nd option, the set of input models contain additional sub-models that are shortly described in the sequel: | ||
| + | |||
| + | - the hardware platform and | ||
| + | - the deployment model. | ||
| + | |||
| + | In the context of this page, the input models are discussed without referring to a specific example. Sample models are available via the SW Designer | ||
online help or via the "create-new example" dialog of Eclipse. | online help or via the "create-new example" dialog of Eclipse. | ||
| − | == | + | == Application model == |
| − | + | === Application model with components === | |
| − | characterized by the transferred data or by the provided/required services. Interactions are realized by the design patterns described | + | |
| + | Components can be modeled via UMLs composite structure diagram, i.e. the possibility to describe a component with its ports and eventually an internal structure consisting of instances of other components that are wired via connectors. | ||
| + | Ports are characterized by the transferred data or by the provided/required services. Interactions are realized by the design patterns described | ||
in section <a href="connector-container.html">Connector/Container</a>. | in section <a href="connector-container.html">Connector/Container</a>. | ||
| − | + | ||
| − | + | === Application model with state-machines === | |
| − | + | ||
| + | A class can contain a state-machine. There are some rules and restrictions how state-machines can be used. | ||
| + | |||
| + | - In case of C++, code generation supports all state-machine features, as described in the OMG document PSSM (precise semantics of state-machines), e.g. parallel region and nested state-machines. Time-events must be described using MARTE's value specification language, e.g. for 10ms, you currently need to specify {value=10, unit=ms} | ||
| + | - In case of Java, code generation supports only single-region state-machines | ||
== Platform model == | == Platform model == | ||
Revision as of 10:09, 5 April 2023
Contents
Input models
Papyrus designer supports two different kinds of input models.
- A model that is quite close to the code that should be generated. In this case, a direct code generator is used. This generator supports structural parts of the model such as classes with their attributes and operations as well as relationships such as inheritance. Please continue here
- A model containing higher level concepts such as state-machines or component-based aspects. In this case, a model-to-model transformation is applied first to your input model producing a temporary model. The "standard" direct code generator is then applied to the temporary model.
In case of the 2nd option, the set of input models contain additional sub-models that are shortly described in the sequel:
- the hardware platform and - the deployment model.
In the context of this page, the input models are discussed without referring to a specific example. Sample models are available via the SW Designer online help or via the "create-new example" dialog of Eclipse.
Application model
Application model with components
Components can be modeled via UMLs composite structure diagram, i.e. the possibility to describe a component with its ports and eventually an internal structure consisting of instances of other components that are wired via connectors. Ports are characterized by the transferred data or by the provided/required services. Interactions are realized by the design patterns described in section <a href="connector-container.html">Connector/Container</a>.
Application model with state-machines
A class can contain a state-machine. There are some rules and restrictions how state-machines can be used.
- In case of C++, code generation supports all state-machine features, as described in the OMG document PSSM (precise semantics of state-machines), e.g. parallel region and nested state-machines. Time-events must be described using MARTE's value specification language, e.g. for 10ms, you currently need to specify {value=10, unit=ms} - In case of Java, code generation supports only single-region state-machines
Platform model
A hardware architecture is described in a similar way as the logical architecture by composition of elements. A class called "HWArchitecture" represents the complete platform. The attributes of this class represent nodes. Each node is typed with a class that captures the properties of this node. Each node can have a further internal structure, a hierarchical structure can thus be modeled.
Deployment model
The deployment of an application consists to define the component instance, their configuration and their allocation to an execution node. The UML composite structure defines the roles that are played by each component of the system. The deployed component is always an instance of a component that has a specfied allocation to an execution resource (node or thread) and a specific configuration. In UML, an instance is defined by an "InstanceSpecification", the values of properties are given via "slots". In case that the property represents a sub-component, the associated value is a further instance specification. The resulting hierarchical structure is quite difficult to maintain and is automatically generated and maintained by tools.
A component-based system requires a configuration. The configuration attribute of a timer for instance define its frequency. The values of this configuration attribute can be defined at two different levels.
- on declaration level by associating a default value with an attribute
- on instance level, by specify a corresponding slot value
Once all component are instantiated and configured, they can be allocated.
The allocation phase consists of defining the relation between the the instances of software components and those of the platform elements. The Figure below describes the deployment of the component DeviceControlMonitor and PGController on the hardware platform. The MARTE "Allocate" relationship is used to describe the allocation model.
The allocation can be refined by introducing local resources of the platform between the application the hardware platforms -- in MARTE via the concept of a "SwSchedulableResource".