The concept of Extended Design Spaces provides a facility for the semi-formal specification of both a given application's requirements and the properties of reusable items. This can be used favorably to support the retrieval, selection, parameterization, and combination of reusable components.

In the context of architecture-based component selection, the demands concerning specific classes of services are stated by characterizations along the corresponding Design Space. Available components from the reuse pool are in the same way characterized along the corresponding Design Spaces. This approach is facilitated by the introduction of composite types like sets for the Design Space characterization, which allow to easily describe reusable items whose exact properties are not known before their instantiation or deployment in an actual implementation. The Design Space notation is thus used as a common vocabulary for requirements and component specification alike.

Matching between requirements and components can then be supported in two ways. First, the requirements descriptions can be directly matched against the descriptions of available components. Second, the design rules (correlations between the requirements dimensions and the structural dimensions) provide guidance for the mapping between requirements and structural design decisions. Applying these rules to the requirements space characterization of an application yields hints concerning structural design decisions, which can be then matched against the characterizations of the components.

In summary, the deployment of Design Spaces to support the retrieval of reusable artefacts has the following advantages:

• The architecture of a software system plays a key role concerning the adherence of an application to its non-functional requirements. This has also to be observed in component-based approaches to software development. As a consequence, components always have to be considered within their architectural context. This is especially important during component retrieval and selection. In current practice, however, this is often neglected; the component selection is mostly based upon functional properties of the reusable assets, while non-functional aspects are only considered implicitly by the experts.
• The deployment of Design Spaces allows to select reusable artefacts already in an early stage of development, based on requirements. This is especially important in architecture-centric development processes, as the various development steps can then be driven by and towards the abstractions identified by the system architecture. Moreover, it is possible to perform architectural analysis, taking the properties of reusable components into account. This allows to predict certain non-functional properties of the complete system already in an early stage of the development process.
• The Design Space profile of an application can also be exploited to guide the parameterization of the components, i.e., the assignment of their generic parameters. The evaluation of design rules yield (sets of) recommended alternatives in the structural Design Space, which can then be used as constraints for the generic parameters.

Besides this, the selection of reusable components using the Design Space approach can be combined with constructive support for the implementation of new functionality, if no reusable items for a specific purpose can be found. In that case, the structural recommendations gained by evaluating the correlations can facilitate the implementation of the missing functionality.