Modelo base 82

Component-based models are essential to support the concept of Emergent Software. Mainly because they provide the necessary information about components to realise autonomous software composition. The information provided supports autonomous component connections to form functioning software architectures, avoiding ran- dom component compositions and offline testing to find compositions that work. Furthermore, since component models allow developers to express features through interfaces that are explicitly expressed when coding components, the component- based model eliminates the need to use extra models to label the system code and

4.2. Assembly Module 74 define features. This extra models label code to define what parts of the system are adaptive and how to adapt them (e.g. what features could be replaced, and how to replace them). For example, feature models (such as in [32]) are often used to rep- resent how pieces of code interact with each other, and how they could be replaced to support adaptation. Using such models, the developers have to code the software and then describe a model capturing the relationship between different parts of the code, increasing development effort. The component model, on the other hand, is a way to abstract that need, integrating fundamental information for component adaptation in components. This characteristic reduces development efforts during the system design phase, facilitating the provision of software adaptation throughout the entire system, rather than to specific parts that was previously modelled.

This work uses the Dana1 _{component model described in [70]. Dana is a multi-}

purpose programming language that inherently provides a component-based model and runtime support to component adaptation in fine-grained complex modular structures. Component-based models require the definition of interfaces and com- ponents. Interfaces define functions signatures (i.e. function names, return types and the list parameters with their expected data types). Each interface expects at least one component implementing all functions defined by the interface. Compo- nents canprovide implementation for multiple interfaces andrequire other interfaces to support their own implementation. Also, multiple components might implement the same interface using different approaches, those are often referred to as com- ponent variants, and by replacing those variants in an executing software is how the adaptation process occurs. This ‘provide-require’ policy is a central part in a component-based model, allowing the language runtime to connect different compo- nents (following the provided-required policy) to create fully functioning software. Software evolution or adaptation is realised by replacing components in the resulting software architecture at runtime without interrupting the system services. Besides changing the implementation detail of a system’s functionality, online component replacement might also change the system’s architecture by adding a set of new

1_{Please refer to http://www.projectdana.com for more practical information on the language,} its component-based model and its online adaptation mechanism.

4.2. Assembly Module 75

Figure 4.2: Example of interfaces and components. Note that Multiplication requires an external interface (Addition) to complete its implementation. The code is written using the Dana programming language syntax.

components required to support the new component’s implementation.

An example of the Dana language syntax and its component-based model is illus- trated in Fig. 4.2. The image shows two interfaces (on the left side of the picture): Addition and M ultiplication. Each interface presents the definition of functions with the function’s name, return type, and a list of parameters with their types. On the right side of the image, two components providing implementation for aforemen- tioned interfaces are illustrated. TheM ultiplicationcomponent is a simple example that illustrates a component implementation depending on another interface. In this case, the M ultiplication component relies on the interface Addition to support its implementation. Therefore, whenever the M ultiplication component is used, any component providingAddition is required to be connected to it. Considering those interfaces and components used to create aCalculator program: if there are mul- tiple components providing Addition interface, the M ultiplication component, in order to work, could be connected to any component providing Addition. Further- more, we could also assume the existence of a M ultiplication component variant that, for example, does not require the Addition interface, thus implementing the M ultiplicationinterface in a different form. Therefore, in this example, there exists a variety of architectural options to realise the Calculator program, each option implementing the operation M ultiplication in a different way, by either connecting

4.2. Assembly Module 76 M ultiplication with a variety of Addition components or replacingM ultiplication with a variant that does not require the Additioninterface.

The Dana runtime provides basic functions to abstract the online architectural composition and adaptation process. The abstraction provided by the language supports, through a single function call, the realisation of software adaptation or composition, involving: loadingnew components to memory, pausing old compo- nent execution, transferring component states (when applicable – i.e. replacing

stateful components) andconnecting the new component to the requiring compo- nent. Dana transparently executes the aforementioned tasks without further actions of the developer. The Assembly module then interacts and further extends these low level functions to determine and control the composition and adaptation process at runtime. A list of functions provided by the Assembly module is detailed below.