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

Components in Product Lines - The Next Steps PowerPoint PPT Presentation


  • 54 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

Rob van Ommering

Philips Research

EuroMicro 2005, Porto, Portugal,

September 1st, 2005


Introducing my domain…

1965

1979

1 kB

2000

1990

64 kB

2 MB


(1) Complexity


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

Was:

  • Yearly cycle of product introduction

    • Christmas

    • World championship

      Is:

  • Decreasing to 6 (or even 3) months

    • Otherwise loose shelf space in shop


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

  • Introduction

  • Product families, populations, lines

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Philips TV product family

cineo

flat

projection

wide screen

designer


STB

VCR

DVD

Audio

Related product families


VCR

TVCR

TV

+

=

DVD

TV-DVD

TV

+

=

HD

Tivo

TV

+

=

STB

Digital TV

TV

+

=

Audio

Home Theater

TV

+

=

Convergence


PDA + GPS

GSM + DigCam

GPS + GSM

CD-RW, DVD, Card, TV

PDA + GSM + DigCam

Convergence yesterday :-)


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:


Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


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

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…

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

We can now build systems:

m provides

m

m requires

m’

m’’

…in both dimensions…


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

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

Components can instantiate other components:

CC

C1

C3

C2


Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


Setting Diversity

Creating different products…

P1

P2

P3

C1

C1

C1

x

7

42

…by setting diversity parameters differently


x

Selecting Components

Creating different products…

P3

C1

P1

P2

C1

C1

C2

C3

C2

C3

…by selecting different subcomponents


Parameterization

C1

Spreadsheet ofdiversity calculations

C2

C3

Partial evaluation is usedto create resource efficientconfigurations.


Reflection

A component can observe whether interfaces are actually connected.

C1

This allows components to adapt themselves to their environment automatically.


Reflection

A component can observe whether interfaces are actually connected.

Special notation for this common design pattern


Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


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


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:

 LoC modified

in branches

 LoC modified

on main line

code size ==

LoC created


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

clones

modified

created

deleted


Comparing Various Subsystems


Some Open-Source Packages

Apache

Linux

Mono

Subversion


Zooming in…


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


Contents

  • Introduction

  • Product families and populations

  • Koala 101

  • Configuration and reflection

  • Calculating system properties

  • Evolution and branching

  • Current and future challenges


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…


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?

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?

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?


Thank

You!

Limited availability…


  • Login