Components in product lines the next steps
This presentation is the property of its rightful owner.
Sponsored Links
1 / 43

Components in Product Lines - The Next Steps PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

Components in Product Lines - The Next Steps. Rob van Ommering Philips Research EuroMicro 2005, Porto, Portugal, September 1 st , 2005. Introducing my domain…. 1965. 1979. 1 kB. 2000. 1990. 64 kB. 2 MB. (1) Complexity. Price. (2) Diversity. Image. UTV. quality. Connectivity.

Download Presentation

Components in Product Lines - The Next Steps

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Components in product lines the next steps

Components in Product Lines -The Next Steps

Rob van Ommering

Philips Research

EuroMicro 2005, Porto, Portugal,

September 1st, 2005


Introducing my domain

Introducing my domain…

1965

1979

1 kB

2000

1990

64 kB

2 MB


1 complexity

(1) Complexity


2 diversity

Price

(2) Diversity

Image

UTV

quality

Connectivity

Sound

1394

AC3

100 Hz

P50

Dolby

Broadcasting

Standard

AP

US

Region

Eu

DTV

MTV

TiVo

Txt

menus

TVCR

EPG

Data

Processing

PTV

animation

HD

DVD

Storage

Device

3D

FTV

LCTV

VCR

User

Interface

Video Output Device


3 lead time

(3) Lead Time

Was:

  • Yearly cycle of product introduction

    • Christmas

    • World championship

      Is:

  • Decreasing to 6 (or even 3) months

    • Otherwise loose shelf space in shop


Summary

Summary…

Software Grows

Exponentially

(Moore’s Law)

Need more people...

Need more time...

Shorter lead time…

More product variation...

Market demands...


Contents of my talk

Contents of my talk

  • Introduction

  • Product families, populations, lines

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Philips tv product family

Philips TV product family

cineo

flat

projection

wide screen

designer


Related product families

STB

VCR

DVD

Audio

Related product families


Convergence

VCR

TVCR

TV

+

=

DVD

TV-DVD

TV

+

=

HD

Tivo

TV

+

=

STB

Digital TV

TV

+

=

Audio

Home Theater

TV

+

=

Convergence


Convergence yesterday

PDA + GPS

GSM + DigCam

GPS + GSM

CD-RW, DVD, Card, TV

PDA + GSM + DigCam

Convergence yesterday :-)


A product population is

A product population is:

- a set of products with many commonalities, - but also with many differences, - developed by different sub-organizations, - each with its own time-line / lifecycle.

SingleProduct

ProductFamily

ProductPopulation

UnrelatedProducts

DecompositionDedicated components

CompositionCOTS


A product line is

A product line is:


Contents

Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Module

Module

A Koala module is:

- a non-reusable unit of code - with variation points

Mindset: a Koala module can (at least in in principle):

- be written in any language (C, Koala, HTML, makefile, …) - have any form (source, object, library, …)


Variation points

Variation Points

Koala has a two-level parameterization mechanism:

Name: rType: ISomething

Level I

Level II

interface ISomething{ int p; int q = 7; int f(x); int g(x) = 1 + f(x);}

This is Koala’s Interface Definition Language (IDL)


Modules also provide stuff

Modules also provide stuff…

Same two-level mechanism:

Name: pType: ISomething

Level I

interface ISomething{ int p; // defined in module int q = 7; int f(x); // defined in module int g(x) = 1 + f(x);}

Level II


Building systems

Building Systems

We can now build systems:

m provides

m

m requires

m’

m’’

…in both dimensions…


Component

Component

A Koala component is:

- a reusable … - … unit of encapsulation … - … still with variation points- providing stuff

C

m

m’’

m’

Note how:

- modules are internal - some interfaces are internal - some interfaces are external


Component definition

Component Definition

A component is described in a Component Definition Language (CDL):

p

component C{provides IXxx p;

requires IYyy r;

containsmodule m;

connects p = m; m = r;}

C

m

r


Compound component

Compound Component

Components can instantiate other components:

CC

C1

C3

C2


Contents1

Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Setting diversity

Setting Diversity

Creating different products…

P1

P2

P3

C1

C1

C1

x

7

42

…by setting diversity parameters differently


Selecting components

x

Selecting Components

Creating different products…

P3

C1

P1

P2

C1

C1

C2

C3

C2

C3

…by selecting different subcomponents


Parameterization

Parameterization

C1

Spreadsheet ofdiversity calculations

C2

C3

Partial evaluation is usedto create resource efficientconfigurations.


Reflection

Reflection

A component can observe whether interfaces are actually connected.

C1

This allows components to adapt themselves to their environment automatically.


Reflection1

Reflection

A component can observe whether interfaces are actually connected.

Special notation for this common design pattern


Contents2

Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Configuration management

Internal diversity

C2

Structural diversity

C3

C2

Configuration Management

Distinguish between:

  • versions

  • temporary variants

  • permanent variants

    of components.

    We use our CM system for:

  • versions

  • temporary variants

    But we use the component model for:

  • permanent variants


Roadmapping

ArchitectureProject

22

26

32

36

46

52

2

4

6

8

22

14

16

18

20

24

28

30

34

38

40

42

44

48

50

10

12

14

16

18

20

arch

R0.1

IROM

R1.0

IROM TR

R2.0

R2.1

IROM CR

AV-Link

Flash

infra

R1.0

R2.0

‘Chinese’ characters

uims

R0.1

R0.2

R0.3

R0.4

R1.0

R2.0

R2.1

R2.2

SubsystemEvolutionProjects

EDRIC

FDW

HC50.x

MCS

Eur & Eco HW

AP HW

tvplf

R0.1

atsc

R0.1

R0.2

R1.0

R2.0

R2.1

FDW

Eur, HC 50.3

AP

tvsvc

R1.0

R2.0

R2.1

Eur

AP

deal

R0.1

R0.2

R1.0

R2.0

R2.1

Eur

AP

fact

R0.1

R0.2

R1.0

R2.0

R2.1

FDW

Eur, HC 50.3

AP

apps

R1.0

R2.0

Now/Next EPG

Full EPG

epg

R0.1

R1.0

R2.0

infra

uims

tvplf (A)

tvplf(A+D)

tvsvc

apps

Txt Lvl 2.5

Chinese TXT

txplf

Gemstar/CC

Fact/Deal/Svc

FDW

Functional Tests

Alpha Tests

ProductRealizationProjects

cl8

tvplf, milo

tvsvc, apps, CC, GS

Fact/Deal/Svc

Functional Tests

Alpha Tests

cl9

Functional Tests

Alpha Tests

EMG

Functional Tests

Alpha Tests

cl4

Functional Tests

Alpha Tests

cl1/2a

Functional Tests

Alpha Tests

cl2b/6

Functional Tests

cl5

Roadmapping


Show over time in a single picture

Show over time in a single picture:

 LoC modified

in branches

 LoC modified

on main line

code size ==

LoC created


First impression

First Impression

  • Effort in branches is 10-20%.

  • Effort in rewrites is 50%!

  • A subsystem is either stable or non-stable.

  • Subsystems are stable (only) when no developers have been assigned.

  • Non-stable subsystems are completely rewritten in 3-4 years.

    To do:

  • Zoom in

  • Look at other software (in Philips, or Open Source)


Refined measurement

Refined Measurement

clones

modified

created

deleted


Comparing various subsystems

Comparing Various Subsystems


Some open source packages

Some Open-Source Packages

Apache

Linux

Mono

Subversion


Zooming in

Zooming in…


New impression

New Impression

  • Many people confirm rewrite every 3-4 year.

  • More difficult to measure in growing systems.

  • Open Source also shows rewrites on main line.

  • Stable subsystems are dead code!

    Spin-off:

  • Evolution browser helps to understand architecture


Contents3

Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Conway s law 1

Eindhoven

Brugge

Hamburg

Briarcliff

Southampton

Wien

Sunnyvale

Knoxville

Bangalore

Singapore

Conway’s Law -1

The structure of the organization should mirror the architecture of the software.

Software development shifts east…


Another shift ce ps 3 rd party

Applications

Applications

OS

OS

Middleware

A/V platform

A/V platform

Another Shift: CE  PS  3rd party

MBytes

It is no longer efficient to write all the software yourself…


Can i check more things statically

Can I check more things statically?

Multi-threading checking is a success, but transfer to our product division is cumbersome:

  • Gain expected but cost is high

  • Can I derive models from source code?

    ‘Our’ Robocop component model, in some sense a successor of Koala, defines a component as a set of models


Can i do more things dynamically

Can I do more things dynamically?

No problem w.r.t. binding technology:

  • Koala is prepared for that (need another back-end)

  • Were already expecting to go this way in 2000!

    But you also give up certain things:

  • Performance

  • Memory use

  • Source code browsing

  • Source code analysis

  • How can we combine the good things?


Components in product lines the next steps

Thank

You!

Limited availability…


  • Login