50
KOALA, Robocop, KobrA, PECOS and Pin Aneta Vulgarakis COMPONENT MODELS

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

  • View
    217

  • Download
    0

Embed Size (px)

Citation preview

KOALA, Robocop, KobrA, PECOS and Pin

Aneta Vulgarakis

COMPONENT MODELS

KOALA component model

C[K]omponent Organizer and Linking AssistentDeveloped 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 interface

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)

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!

subcomponent

module switch

interface

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

Robocop component model

Developed in Eindhoven UniversityVariant 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

KobrA component model

Komponentenbasierte AnwendungsentwicklungSupported 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

PECOS component model

PErvasive COmponent SystemCollaborative 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

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, p167-192

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) p56 - 63  

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, 2001. EDOC '01.