3 Position: Compose software with software cocktail mixers

In this position paper we sketch such a generic software extension model. We argue that component-uses must have an abstract view of the component. Subcomponents should only be accessed by symbolic names; the actual mapping of the view to the real layout of the component should be left to the compiler. To decouple uses from definitions, software components should be defined by composition using definition composition operators. Looking at all compositions of component-definitions, the compiler is enabled to calculate the view mapping. When a component is extended, component-uses only have to be recompiled. Since in the model software is constructed by composition and multiple views of components are mixed in order to find out the final shape of the component, we call the model a software cocktail mixer and the composition process the mix of a software cocktail.

However, the model is current work and not yet stable. We would like to discuss its basics with other researchers in order to find new ideas how to characterize software extensibility and composability.

An component-definition is a definition of a software item. It is composed of a name (from domain Ident) and a family of subcomponent-sets. D, the definition-universe, is the set of all considered component-definitions. Each subcomponent consists of a named attribute value. Attribute domains can consist of code, data, specification items, or names. Components may be defined recursively. We keep several separate subcomponent-sets because these denote different features of the component.
Example 2 Components may correspond to classes, and component-definitions to class definitions. Class attributes and class methods form two distinct subcomponent sets.

class person is attributes name:STR; age :STR; methods reset_name: STR -> STR; end;

$\bullet$

Software components are not only defined but also used: A subcomponent-projection is a function which projects a component to a subcomponent. An component-use is a point in the software system which applies an subcomponent-projection. The set of all considered component-uses is called U, the use-universe. More precisely, the subcomponent-projection is a partial function   which projects a component-use, an component-definition and a subcomponent name to the subcomponent. Access to subcomponents is only allowed via this projection function.

Because several definitions of a component (with the same name) are allowed, several component-uses may have different views of a component. The function get realizes the view mapping. It is calculated specific for each component-use by the compiler after looking at all component-definitions and component-uses. The view mapping may be quite simple:
Example 3 Consider as component-definitions class definitions and as subcomponent-sets class attributes. Accessing attributes and methods of classes corresponds to the executing the get-function. $\bullet$