Koala component model (1)

Koala Component Model
26 April 2015 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/w
orkpackages/workpackage1/Task1dot1/reports/Philips/Koala/
ares2Final.pdf

Koala component model (1)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à Koala component model (1)

Similaire à Koala component model (1) (20)

Plus de Saransh Garg

Plus de Saransh Garg (15)

Dernier

Dernier (20)

Koala component model (1)

Notes de l'éditeur