1 / 43

Components in Product Lines - The Next Steps

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.

alain
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Components in Product Lines -The Next Steps Rob van Ommering Philips Research EuroMicro 2005, Porto, Portugal, September 1st, 2005

  2. Introducing my domain… 1965 1979 1 kB 2000 1990 64 kB 2 MB

  3. (1) Complexity

  4. 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

  5. (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

  6. Summary… Software Grows Exponentially (Moore’s Law) Need more people... Need more time... Shorter lead time… More product variation... Market demands...

  7. Contents of my talk • Introduction • Product families, populations, lines • Koala 101 • Configuration and reflection • Calculating system properties • Evolution and branching • Current and future challenges

  8. Philips TV product family cineo flat projection wide screen designer

  9. STB VCR DVD Audio Related product families

  10. VCR TVCR TV + = DVD TV-DVD TV + = HD Tivo TV + = STB Digital TV TV + = Audio Home Theater TV + = Convergence

  11. PDA + GPS GSM + DigCam GPS + GSM CD-RW, DVD, Card, TV PDA + GSM + DigCam Convergence yesterday :-)

  12. 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

  13. A product line is:

  14. Contents • Introduction • Product families and populations • Koala 101 • Configuration and reflection • Calculating system properties • Evolution and branching • Current and future challenges

  15. 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, …)

  16. 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)

  17. 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

  18. Building Systems We can now build systems: m provides m m requires m’ m’’ …in both dimensions…

  19. 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

  20. 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

  21. Compound Component Components can instantiate other components: CC C1 C3 C2

  22. Contents • Introduction • Product families and populations • Koala 101 • Configuration and reflection • Calculating system properties • Evolution and branching • Current and future challenges

  23. Setting Diversity Creating different products… P1 P2 P3 C1 C1 C1 x 7 42 …by setting diversity parameters differently

  24. x Selecting Components Creating different products… P3 C1 P1 P2 C1 C1 C2 C3 C2 C3 …by selecting different subcomponents

  25. Parameterization C1 Spreadsheet ofdiversity calculations C2 C3 Partial evaluation is usedto create resource efficientconfigurations.

  26. Reflection A component can observe whether interfaces are actually connected. C1 This allows components to adapt themselves to their environment automatically.

  27. Reflection A component can observe whether interfaces are actually connected. Special notation for this common design pattern

  28. Contents • Introduction • Product families and populations • Koala 101 • Configuration and reflection • Calculating system properties • Evolution and branching • Current and future challenges

  29. 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

  30. 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

  31. Show over time in a single picture:  LoC modified in branches  LoC modified on main line code size == LoC created

  32. 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)

  33. Refined Measurement clones modified created deleted

  34. Comparing Various Subsystems

  35. Some Open-Source Packages Apache Linux Mono Subversion

  36. Zooming in…

  37. 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

  38. Contents • Introduction • Product families and populations • Koala 101 • Configuration and reflection • Calculating system properties • Evolution and branching • Current and future challenges

  39. 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…

  40. 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…

  41. 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

  42. 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?

  43. Thank You! Limited availability…

More Related