The component developer view clusters elements of the Component Metamodel that are relevant to the Component Supplier.

The component development view (shown in the figure below) needs to be rich enough and provide sufficient structures such that this model can serve as a consistent baseline for all the successive development steps (such as e.g. system composition/configuration) that rely on proper component models. At the same time, the component development view should avoid definition of too many low level details that are more related to internal knowledge that is not required for supporting composition with respect to the surrounding models. In this way, the component development view always is a trade-off between providing enough structures where needed and leaving enough design freedom for the internal realization.

The only interaction point of a component with other components is through services. Therefore, a component can specify several provided and/or required services. A special kind of service is the behavior-interface which is used by the behavior coordination layer to coordinate this component at run-time (i.e. to set propper configurations, to activate/deactivate certain component modes, etc.). Therefore, the behavior-interface interacts with the component's internal parameter structure and the component's lifecycle state automaton which also defines the component-specific run-time modes.

The component's services interact within a component with Activities and the component's Lifecycle. The component's Lifecycle affects the lifelines of services and the activation/deactivation of Activities.

Regarding a component's Services, as long as the component is initializing (during start-up) or as long as a component is in a fatal-error mode, then the provided services might be physically available but not ready to properly offer a service (i.e. not able to answer query requests).

The next component-internal structural element is an Activity, which is an abstract representation of a task (or more precisely of a thread). An activity wraps a functional block which by itself is passive and only gets active by the execution environment of its parent Activity. This is an effective decoupling of the design and implementation of functional parts within a component and the execution of the functions. This even allows configuration of the execution characteristics for individual functions even after the component has been fully implemented and shipped to e.g. a system builder and without affecting the component's internal implementation.

As mentioned above, it is important that a structural model provides enough details that are required to communicate the structural knowledge of a component to other developer roles as well as to provide a sound foundation for the later development steps. In this respect, it is equally important to mention which parts have been omitted on purpose in order not to intermix the responsibilities and concerns that become relevant in later development steps. The most important parts that have been omitted on purpose are: (1) the mapping of services to a particular communication middleware (which is the responsibility of another developer role) (2) the mapping of Activities to a particular execution container such as Windows/Linux threads, or QNX/RTAI real-time threads (again a responsibility of another developer role) and (3) the definition of the services by themselves (which might be the responsibility of domain experts).