Revision as of 04:43, 5 June 2014

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".