8.5 Component Models

A component has a name, a collection of ports by which it communicates with the outside world, and optionally a description of its internals. A syntax example:

component MyComponent
{
  provides MyInterface1 myPort1;
  requires MyInterface2 myPort2;
  requires MyInterface3 myPort3;
  /*
   * internals description....
   */
}

In this example a number of keywords are introduced: component, provides, and requires.

The example defines a component named MyComponent with three ports.

8.5.1 Ports

A component provides some functionality, and requires functionality of other components. Communication between components is performed through their ports, which are instances of interfaces. Each port has a direction according to its intention (provides or requires), the interface it implements and a local name. A component refers to these ports in its behaviour.

8.5.1.1 Injection

A requires port can be specified to be injected:

  requires injected MyInterface myPort;

The intention is, that binding such a port will occur at a high level in the system hierarchy to some component port someComponent.somePort, and that more than one injected port can be bound to that port. For that reason MyInterface cannot define out events.

See System Components for a detailed description of the binding of injected ports.

8.5.2 Internal Description

The component’s internal description comes in three flavors:

• Behavioural: Like in the interface protocol the internals are given as a behavioural description, in which for each event the required actions are given. See Interface and Component Behaviour.
• Compositional: The functionality is described as the composition of a number of sub components. See System Components.
• Hand-written: The internals are missing indicating the intention to have a hand-written implementation of the component. This implementation must be such that it satisfies the specified ports. The component is a place-holder only.