1. KOALA, Robocop, KobrA, PECOS and Pin
COMPONENT MODELS
Aneta Vulgarakis

2. C[K]omponent Organizer and Linking Assistent
KOALA component model
C[K]omponent Organizer and Linking Assistent
Developed and used by Philips for development of software in consumer electronics

3. KOALA – component definition
Component is a unit of design, development and reuse
Interact between the environment or other components ONLY through explicit interfaces
Koala components are defined in its:
IDL (interface definition language)
CDL (component definition language)
DDL (data definition language)
Syntactically: KOALA components are defined in ADL-like language
Semantically: KOALA components are units of computation and control connected together in an architecture
C influenced syntaxes

4. KOALA – interface definition
Interfaces are represented as squares with triangles
The tip of the triangle represents the direction of the function call
Two types of interfaces:
provides interface = methods to access the component from outside
requires interface
Koala component may behave like a system by itself
provides
interface
required

5. KOALA – component composition
Repository for KOALA components is the KoalaModel Workspace
Composition of components is only possible in the design phase
Connect:
Provides interfaces to requires interfaces;
Provides interfaces to provides interfaces;
Requires interfaces to requires interfaces.
Combination of components is a composite component
KOALA configuration is a list of components and a list of connectors between the components

6. KOALA – component composition (cont’d)
Three kinds of connectors:
Binding – connect requires interface of a component to a provides interface of the same type of another component
- provides interfaces are wider than requires interfaces => possible evolution of components
- adding new functionalities to a component and still compatible with former versions
- represented as a line
Glue code – connects requires interface of a component to a provides interface of a different type of another component
- written in C or limited expression language within Koala
- represented as “m” (for modules)
Switch – special glue code that switches binding between components
- chooses between provides interfaces of different components at run time
- represented as a “switch” note

7. KOALA – component composition (cont’d)
subcomponent
module
switch
interface
In deployment phase Koala components are compiled into a programming
language and executed in the runtime environment of that language
NO NEW COMPOSITION OF COMPONENT INSTANCES IS POSSIBLE!

8. KOALA – example
Stopwatch device for counting down from a specific number e.g. 100
Stopwatch device comprises Countdown and Display component
Interface of Countdown component specifies the signature of function ‘count’ which Countdown component implements
Countdown component definition defines its provides interface ICount and its implementation ‘c_impl’

9. KOALA – example (cont’d)

10. KOALA – basic principles of CBSE
Reusability –ok
Composition possible only at design time
The builder can retrieve (composite) components from the repository – reuse
Substitutability – no ?
subtyping: new versions of a component are backward compatible with old versions
Use subtyping for achieving substitutability
Component A can be replaced by component B if it is a B subtype of A
HOWEVER there are no direct constructs for replacing components by other components in the Koala language
Extensibility – ok- at design and compile time
New components can be added
Possible to create a new interface type that contains all the functions of the previous interface plus some additional ones at design time
Composibility - not ideal
Only possible at design phase

11. KOALA – summary Component is a unit of design, development and reuse
Koala components are constructed as CDL files and deposited into repository KoalaModel Workspace
In design phase Koala components are composed by method calls through connectors
In deployment phase no new composition is possible => there is no assembler
Koala components are compiled into C and executed in the rum-time environment of that language

12. Robocop component model
Developed in Eindhoven University
Variant of the Koala model

13. Robocop – the project
Defines an open, CB architecture for the middleware layer of high-volume consumer electronics
The architecture consists of:
development and execution framework
optional download and resource framework
At development level the component is a collection of models and relationship between these models
Allow system builders to reason about a-priori about systems composed from components
At execution level there is a binary component model, which combines element of OMG,CORBA,COM and KOALA

14. Robocop – component definition
Component is a set of models each providing information about the component
Different types of models are possible such as:
- functional model
- non-functional model: describes timing, reliability, memory usage
Components are logically subdivided in services (similar to public classes in OO language
Services are instantiated in run-time and are logically equivalent to objects in OO programming
Robocop Component
Resource Model
Simulation Model
Documentation
Executable Component
Functional Model
Source Code …

15. Robocop – interface definition
Interface definitions are specified in an Interface Definition Language (IDL) – Robocop IDL (RIDL)
Interfaces are defined separately from services => multiple services can provide implementation of the same interface
Each service has a special management interface, service interface
Service interface contains operations for obtaining provided services from the service and binding the required interface to the provided interface of another server

16. Robocop – interface definition (cont’d)
Robocop convention:
User of some functionality is called a client
Provider is called a server
For minimizing coupling between clients and servers:
The functionality is encapsulated in services that expose their functionality through interfaces – provided interfaces
Required interface and 3rd party binding – clients specify what they need but not who will provide it, this is responsibility of the 3rd party
Multiple interfaces – supported from provided and required side

17. Robocop – component composition
Components can be composed from several models
The composition of components is called application
Robocop framework can calculate system properties from composition of components
During run-time a Robocop platform can execute a component that resides on the platform or request a component from the repository
=> possible dynamic binding of services required by a component to services provided by another component

18. Robocop– basic principles of CBSE
Reusability - ok
It is possible to use third party components and reuse old ones
Substitutability – ?
Extensibility – ok
Add new functionality to the system at design time, compile time and run-time
Composibility
At design and deployment phase ???

19. Robocop – summary
Component is a set of models each providing information about the component
Components are logically subdivided in services
Interface definitions are specified in an Robocop IDL (RIDL)
Interfaces are defined separately from services => multiple services can provide implementation of the same interface
Components can be composed from several models and the composition of components is called application

20. KobrA component model Komponentenbasierte Anwendungsentwicklung
Supported by the German Ministry of Research and Technology (BMBF)
- Variation of UML model driven representation of components-

21. KobrA – component and interface definition
Component is a UML component
Component specification = what it does
Describes all the properties of components instances that are visible to other component instances
Specification of a component is the interface of the component
Two interfaces:
Requires interface = imported, supplied or used interface
Provides interface = supplied or server interface
KobrA component may behave as a system by itself

22. KobrA – component vs. system
Many approaches see component development and component assembly as different activities
Development with components ≠ development of components
In KobrA component development and assembly are the same thing
=> A system = a component + = + =

23. KobrA – example
Bookstore which wishes to maintain a database of its book stock
The bookstore sells its books by and Automatic Teller Machine (ATM)
The specification of the bookstore component is:

24. KobrA – component composition
KobrA components are composed by direct method calls only in the design phase
Construction of KobrA components in a visual builder ex Visual UML
Repository of KobrA components is a file system
stores a set of UML diagrams
not possible to form a composite component in KobrA, only system template
Design Deployment Run-time
Component life-cycle

25. KobrA – example of component composition
New ATM component is constructed
BookStore and Book components are retrieved from the repository
Components ATM, BookStore and Book are composed by direct method calls to a book store system

26. KobrA – basic principles of CBSE
Reusability - ok? depends on the understanding of a CM
At design phase new components can be deposited in the repository and components can be retrieved from the repository
MARMOT approach developed especially for embedded systems
Substitutability – ?
Extensibility – ?
Composibility
Only possible at design time but it is treated as a system template

27. KobrA – summary Component is a UML component
Components are constructed as a component specification and deposited into the repository
The repository is a file system which stores a set of UML diagrams
Kobra components are composed by direct method calls into a system template
No new composition is possible in the deployment phase => no assembler

28. PErvasive COmponent System
PECOS component model
PErvasive COmponent System
Collaborative project between ABB Corporate Research Centre and academia

29. PECOS – component definition
Component is a black box with ports
The component has
a name
number of property bundles – used to store non-functional properties (e.g. WCET)
set of ports
defined behavior
Ports are for data exchange between components
Components are specified with CoCo language, which is developed within PECOS project
CoCo specifies only the properties and ports of a component, but not its behaviour

30. PECOS – component definition (cont’d)
Behavior is a function, procedure or an algorithm that reads and writes data available at its ports
Three types of components:
Passive components : - do not have their own thread of control
- they are scheduled by it closest active ancestor
Active components : - have their own thread of control
- used for very fast or very slow activities such as hardware registers or writing to slow memory
Event components : - have their own thread of control
- execution of the behavior is triggered by event

31. PECOS – interface definition
The interface is port based
Connected ports represent the same shared variable
Port is specified with:
Unique name within a component
type of data passed over the port
range of values that can pass through the port
direction of the port (in, out, inout)
Ports can be only connected if they have same type and their directions are complementary (in port to out port)
Components may have no input or output ports

32. PECOS – UML diagram showing the structure of a component
UML Meta model of a component, defining relations between different types
of components and properties characterizing a component

33. PECOS – component example
Clock component may be specified in CoCo like:
component Clock {
properties {
memsize=32;
description=“This is my first clock.”; }
output long msecs;
This is a passive component, with 2 properties memsize and description and an output port msecs of type long

34. PECOS – component composition
The composition is done at only at design time (no repository)
Sub-components don’t have implementation at design time
Components are composed by connectors that link their ports
No new composition possible at deployment phase
Design Deployment Run-time
Component life-cycle

35. PECOS – component composition (cont’d)
Connector describes data sharing between ports
It is described by:
Name
Type
List of ports that it connects
Two types of components
Leaf component – “black box” directly implemented in the host programming language
Composite component – contains sub-components (not visible outside the composite component) connected with internal ports

36. PECOS – example component composition
PECOS system called Device. There are four sub-components
EventLoop component is an active component used to handle graphical events such as mouse click
The system Device has no ports because it is the application to be run

37. PECOS – example component composition (cont’d)

38. PECOS – basic principles of CBSE
Reusability ?
no repository at design phase => components constructed from scratch
at design phase the builder has to construct a complete system of components and their composition
Composition of component instances is the same as in that of the components in the design phase
can we make our own repository???
Substitutability – ?
Extensibility – ?
PECOS components contain non-functional properties (memory consumption, WCET…)
extensible architecture at design time and compile time
Composibility
Possible at design phase only

39. PECOS – summary
Components are defined in ADL-like language called CoCo and constructed in a programming environment such as Eclipse
At design phase composite components are made by linking their ports with connectors
No repository in PECOS
Implementation is usually done in Java or C++ => run-time environment in deployment phase is that for Java or C++
Suitable for small, very resource constrained embedded systems

40. Pin component model

41. Pin – component definition
Component is an architectural unit that specifies a stimulus-response behavior by set of ports (pins)
Components are defined in CCL(Construction and Composition Language)
Components is represented by:
set of sink pins
set of source pins
and component’s behavior
sink pins
source pins

42. Pin – component interface
Pins are interaction points between components
Sink pins – used to receive communication (stimuli)
Source pins – used to initiate communication (responses) with its environment
Behavior of a component is described by parallel composition of its reactions to sink and source pins

43. Pin – component example
Component AComp which is described with structural and behavior aspects in CCL
Structurally it has:
asynchronous sink pin – receive and
two synchronous (unicast) source pins – send and publish
Behaviorally it has a threaded mission, takes receive, send and publish as parameters

44. Pin – component composition
Components can only interact through their pins
Composition is done at design phase by connectors which link source pins of one component to sink pins of another one
No repository
In deployment phase components are executed in Pin run-time environment

45. Pin – component composition (cont’d)
Two types of connectors:
synchronous connector – connects one source pin of a component to one sink pin of another
asynchronous connector – connects one source pin of a component to multiple sink pins of another
Only components within the composite component (assembly) can interact with each other
The pins of an assembly are connected with the pins of its components by assembly junction
Two types of assembly junctions:
Null junctions – connect components of same environment type
Gateway junctions – connect components in different environments

46. Pin – basic principles of CBSE
Reusability ?
no repository at design phase => components constructed from scratch
at design phase the builder has to construct a complete system of components and their composition
Composition of component instances is the same as in that of the components in the design phase
can we make our own repository???
Substitutability – ?
Extensibility – ?
Composibility
Possible at design phase from scratch

47. Pin – summary
Component is an architectural unit that specifies a stimulus-response behavior by set of ports (pins)
Components are defined in CCL which is an ADL language
Components composed with connectors that link source pins of one component to sink pins of another component
No repository in Pin
In deployment phase implementations are generated in CCL processor and components are executed in Pin run-time environment

48. References
Rob Van Ommering, Frank van der Linden, Jeff Kramer and Jeff Magee; “The Koala Component Model for Consumer Electronics Software”, IEEE Computer, March 2000, p78-85
Johan Muskens, Otso Virtanen, Michel Chaudron and Ronan Mac Laverty; “Maintaining Terminal Integrity and Context-Aware Reconfiguration”, ECOOP 2004, Oslo, Norway, June 2004
Johan Muskens; “Managament of Component Based Embedded Software Systems”, December 2005 (not yet published)
Hugh Maaskant; “ A Robust Component Model for Consumer Electronic Products”, Philips Research Book Series Volume3, p

49. References (cont’d)
Mikael Åkerholm and Johan Fredriksson; ”A Sample of Component Technologies for Embedded Systems”, Technical Report, MRTC, November, 2004
Kung-Kiu Lau and Zheng Wang; ”A Survey of Software Component Models”, (second edition) Pre-print CSPP-38, School of Computer Science, The University of Manchester, May 2006
Peter Müller, Christian Zeidler and Christian Stich; “PECOS – Pervasive Component Systems ”, Workshop on ”Open Source Technologie in der Automatisierungstechnik”, GMA Kongress 2001
Anders Möller, Mikael Åkerholm, Johan Fredriksson and Mikael Nolin;
“Evaluation of Component Technologies with Respect to Industrial Requirements”, 30th EUROMICRO Conference (EUROMICRO'04) p   

50. References (cont’d)
Colin Atkinson, Joachim Bayer and Dirk Muthig; “Component Based Product Line Development: The KobrA Approach”, 1st International Software Product Line Conference, Pittsburgh, August.
C. Atkinson, J. Bayer, O. Laitenberger and J. Zettel; “Component Based Software Engineering: The KobrA Approach”, 3rd International Workshop on Component-based Software Engineering, Limerick, Ireland.
Colin Atkinson, Barbara Paech, Jens Reinhold and Torsten Sander; “Developing and Applying Component-Based Model-Driven Architectures in KobrA”, Proceedings. Fifth IEEE International Enterprise Distributed Object Computing Conference, EDOC '01.