| = Input models = |
| |
| The set of input models contains three sub-models that are shortly described in the sequel: |
| |
| *1 the software component model, |
| *2 the hardware platform and |
| *3 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 Qompass |
| online help or via the "create-new example" dialog of Eclipse. |
| |
| == Component model == |
| |
| We use the UML MARTE component model that describes components (with their internal behavior), and the interaction points (ports) |
| 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>. |
| The concurrent behavior is specified via the HLAM (High Level Application Modeling) sub-profile of MARTE. This concurrency model |
| identifies the components that possesses execution resources (RtUnit) and the shared ones (PpUnit) which do not have execution resources, |
| but resources that manage the concurrent access. |
| |
| == 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". |
