Koala component model (1)

Koala Component Model

15 April 2023 Component Based Tech 1

Agenda

• Present Challenges• The Koala Model• Extensions to the Model• Diversity• Execution


Present Challenges in Consumer Electronics

• The increasing size of products• More complex control functions• Growing diversity of the products• Significant decrease in development time


The Koala Model

• It is aimed at:– Managing the increasing complexity by handling

architecture– Handling the diversity by software reuse

• KOALA Model: C[K]omponent Organiser and Linking Assistant

• Developed by Philips


The Koala Model

• Components and configurations are considered as separate entities

• It is a unit of design, development and reuse• Koala Components are defined in its:– IDL (Interface Definition Language)– CDL (Component Definition Language)

• Interaction between environment or other components are only through explicit interfaces


Components

• Component is a encapsulated piece of software• It is a unit of development and architectural design• A self-contained entity


Interfaces

• It describes connection between components at higher levels

• Type of interfaces:– Provides Interface– Requires Interface

• Interface Definition Language is used to list all prototype in C syntax. Example:


Configurations

• It is a set of components connected together• Definition specifies the components and

interfaces that connects the components.


Implementation

• Components are implemented as a set of C and header files in a single directory

• A call for a requires interface(r_f) by a provides interface(c_p_f) can be defined as:

#define r_f(...) c_p_f(...)

• Statements are generated by a small tool called Koala that reads CDL and IDL


Extensions to the Model

• Compound Components: When building large systems consisting of

hundreds of components, it becomes unfeasible to interconnect them in a single description: the description gets too large to be understandable, cannot be easily maintained by a team of people, and different expertise areas are needed for different parts of the configuration.

Therefore we make the component model recursive.



• Gluing Interfaces: A direct connection between interfaces is not

always sufficient. It assumes that components are completely

tuned to each other in their interfaces, and this is often not the case.

Therefore we introduce modules.



• Multiple Instantiation In our systems, most components occur only once

in a single configuration, and the implementation techniques described above are then sufficient.

For some components, mostly of a service nature, it would be convenient to be able to instantiate them more than once.

For that we need to explicitly define the component as multiply instantiable



• Packages We assume that component type and interface

type names are globally unique. This is not a necessary element of our approach. It is relatively simple to add the notion of a

package with private and public types and with import statements (as in Java).


Diversity

• How do we manage diversity? First of all, the strict separation between components and configurations already allows us to create a multitude of configurations with a single set of components, adding glue wherever necessary to match the components. In this section we extend our model with several other features. We shall both deal with internal diversity (within components) and with structural diversity (between components).


Diversity

• Interface Compatibility We follow the COM convention that an interface type, once defined, may never be changed anymore. Still, new generations of components may require the definition of new interface types that are small extensions of existing types. Therefore we allow the tip of an interface to be bound to the base of another interface if the first interface is of a subtype of the second.


Diversity

• Diversity Interfaces We believe that components can only be made reusable if they are ‘heavily parameterized’ .

• Interfaces containing diversity functions are called diversity interfaces (though in the model, diversity functions can be (and are) freely intermixed with ‘normal’ requires functions).


Diversity

• Late Binding The trend in binding techniques is to shift the moment of binding from compile time to link time to initialization time to run time. Our model supports various forms of late binding, but to explain this, we must introduce another time scale, relevant for the development of embedded software.


Diversity

• Switches A switch is an element that can be used to route connections between interfaces. Its top must be connected to the tip of one interface, and each of its ‘bottoms’ can be connected to the base of a different interface. The switch setting is controlled through a diversity interface. Our binding tool Koala knows about switches.


Diversity

• Switches.Diagram: component A uses B1 in one product, and B2 in another product. We can simply define two configurations to implement this, but A may be part of a complex compound component, and we do not want to duplicate the rest of that. Our basic solution is to insert a module between the requires interface of A and the provides interfaces of B1 and B2. As this is a recurring pattern, we introduce a special concept for this.


Diversity

• Function Binding How can individual diversity parameters be set to a constant value at configuration time? An interface is connected with its tip to perhaps other interfaces, but ultimately through a chain of such bindings to a module.


Diversity

• Optional Interfaces An optional interface has an implicit extra function called iPresent, which acts as a boolean diversity parameter. It is true if the tip of the interface is connected to a non optional interface, false if the tip is not connected at all, and defined within the module if the tip is connected to a module.


Execution Architecture

• The basic rule in our approach is to make components configuration independent as much as possible. As an illustration, we shall show in this section how we define the execution architecture. Our approach is to define components in such a way that the actual execution architecture can be established at configuration time



• Events How do we deal with events? Instead of

defining some event handling mechanism in our model, we just advise component designers to signal events through outgoing (requires) interfaces (just like in Visual Basic).



• Events Another component that uses services of the

component can provide an event-handling interface that can be connected to the event-signaling interface.



• Threads and Tasks Each component may implement its time

consuming activities in terms of tasks, which are scheduled synchronously by a task manager running in a global thread. To do so, a component requires a thread ID through a virtual thread interface, and creates its tasks on such virtual threads.



• Threads and Tasks At configuration time, the (many) virtual

threads are mapped to the (few) physical threads, thus enabling Gomaa’s principle of Task Inversion .


Reference Paper

Koala Component Model for Consumer Electronics Product Software:https://distrinet.cs.kuleuven.be/projects/SEESCOA/internal/workpackages/workpackage1/Task1dot1/reports/Philips/Koala/ares2Final.pdf


Koala component model (1)

Education

Transcript of Koala component model (1)