1. software engineering Research Challenges in Software Architecture and Software Product Families University of Antwerp, March 2004 Jan Bosch Professor of Software Engineering University of Groningen, Netherlands Jan.Bosch@cs.rug.nl http://www.cs.rug.nl/~bosch

2. software engineering Research Challenges in SA and SPFs2 Overview introduction trends in software engineering software product families –adoption –maturity model software architecture –explicit design decisions conclusions

3. software engineering Research Challenges in SA and SPFs3 Software Engineering group Senior members prof. dr. ir. Jan Bosch dr. Jos Nijhuis (APr) dr. Rein Smedinga (APr) Post-docs dr. Theo Dirk Meijler dr. Jilles van Gurp dr. Lisette Bakalis Ph.D. students Michel Jaring (2004) Eelke Folmer (2005) Sybren Deelstra (2006) Marco Sinnema (2006) Anton Jansen (2006) Fernando Erazo (2007) Ivor Bosloper (2007) Johanneke Siljee (2007) Industrial Ph.D. students Rob van Ommering (Philips Research) Jan Gerben Wijnstra (Philips Research) Alessandro Maccari (Nokia Research/Mobile Phones) Ernst Kesseler (Dutch Aerospace Laboratory) Sylvia Stuurman (Open Universiteit) Emil Petkov (UK)

4. software engineering Research Challenges in SA and SPFs4 Current Research Topics variability management EU project CONIPF design erosion usability EU project STATUS software architecture software product families evaluation/ maturity models feature-based architectural centric system construction modifiability assessment modeling design decisions explicitly explicit architecture information architecture assessment software variability management

5. software engineering Research Challenges in SA and SPFs5 Industrial Partners Ericsson Software Technology Althin Medical Axis Communications Symbian (earlier Ericsson Mobile) EC-Gruppen Securitas Larm Ericsson Software Architecture Research Lab Nokia CombiTech Software Vertis Information Technology Rohill Technologies Philips Research, Medical, Consumer Electronics and PDSL Baan Thales Naval Netherlands Robert Bosch GmbH Information Highway Group LogicDIS ICT Embedded currently ongoing cooperation

6. software engineering Research Challenges in SA and SPFs6 Agrarian age Industrial age Information age Bioterial age 1760 360 years 50 years 20 years Time Economic value added Source: “The Coming Biotech Age”, Richard W. Oliver- McGraw-Hill 6000 BC Where are we going? How fast?

7. software engineering Research Challenges in SA and SPFs7 Innovation Adoption *maturity = 50 million users in the US radio 38 years phone 25 years cable 10 years internet 5 years technology maturity* years technologies TV 13 years

8. software engineering Research Challenges in SA and SPFs8 Innovation: Tactics follower: watch trends and react accordingly (reactive) shaper: create the technology underlying new trends (proactive)

9. software engineering Research Challenges in SA and SPFs9 Trend: software size software needs in products constantly increasing 1990199520002005 10 100 1000 person years per product 1000 10000 typical number of errors per product Philips

10. software engineering Research Challenges in SA and SPFs10 Trend: systems of systems systems increasingly need to be integrated with other systems Information systems –from manual data exchange to behavioural integration embedded/technical systems –from stand-alone to signal exchange to behavioural integration

11. software engineering Research Challenges in SA and SPFs11 Trend: Variability Variability needs in software are constantly increasing because variability moves from mechanics and hardware to software design decisions are delayed as long as economically feasible

12. software engineering Research Challenges in SA and SPFs12 Examples car engine controllers steer by wire telecom switches Transmeta’s Crusoe chip

13. software engineering Research Challenges in SA and SPFs13 Mobile Phones GSM 900 GSM 900/1800 GSM 900/1900 GSM 900/1800/1900 GSM 1900

14. software engineering Research Challenges in SA and SPFs14 BPM @ Intershop

15. software engineering Research Challenges in SA and SPFs15 Software Product Families product-family architecture component set product 1product 2product n external internal...

16. software engineering Research Challenges in SA and SPFs16 Trend: Variability mechanical parts electronic parts (HW) software parts (SW) variability (flexibility of SW) standardization (economies of scale)

17. software engineering Research Challenges in SA and SPFs17 Trend: Variability marketingdevelopment customer req. SW product post fielding upgrades license key driven conf. 3 rd part software

18. software engineering Research Challenges in SA and SPFs18 Variability software variability is the ability of a software system or artefact to be extended, changed, customized or configured for use in a particular context software variability reflects problem domain variation, e.g. expressed through feature models software variability is expressed through variation points and associated variants variation points delay design decisions

19. software engineering Research Challenges in SA and SPFs19 Variation Points variation point in the lifecycle –implicit – implicitly present in system –designed – delayed design decision lead to VP –bound – variation has been connected to VP rebindable – variant can be bound to different variants permanent – variant has been bound permanently times –open – possible to add new variants to set –closed – set of variants is closed can be introduced and bound at any level

20. software engineering Research Challenges in SA and SPFs20 Trend: Later Binding trend is towards later binding and increased automation

21. software engineering Research Challenges in SA and SPFs21 Software Challenge increasing SW size per product develop fewer products increasing variability requirements develop more products Software Product Families

22. software engineering Research Challenges in SA and SPFs22 SVM Research in Groningen conceptual framework – Jilles van Gurp, Sybren Deelstra, Marco Sinnema, Theo Dirk Meijler visualizing variability and variability dependencies – Michel Jaring explicit modelling of architectural design decisions – Anton Jansen SVM in product derivation – Sybren and Marco variability assessment – Sybren case studies – Jilles, Michel, Sybren and Marco

23. software engineering Research Challenges in SA and SPFs23 Overview introduction trends in software engineering software product families –adoption –maturity model software architecture –explicit design decisions conclusions

24. software engineering Research Challenges in SA and SPFs24 Adopting an SPF requires changes that cross-cut the organization, i.e. BAPO potential problems: –mismatch between shared components and product needs –design erosion of shared components –complex interface –high degree of “organizational noise” –inefficient knowledge management –evolution causes ripple effects through the R&D organization –component value not linear

25. software engineering Research Challenges in SA and SPFs25 Component value not linear

26. software engineering Research Challenges in SA and SPFs26 Decision Dimensions

27. software engineering Research Challenges in SA and SPFs27 Feature Selection Oldest, most generic, lowest components –little resistance, variability well understood, one infrastructure –substantial investment due to erosion, low pay- off, COTS replacement Existing, but evolving, components –cross-portfolio changes easy, behaviour well understood –little time for pay-back on product-specific components, cost of implementing superset of features

28. software engineering Research Challenges in SA and SPFs28 Feature Selection New, but common features –no lost product-specific development effort, future evolution less expensive –high degree of uncertainty wrt new features, DE unit may lack market understanding

29. software engineering Research Challenges in SA and SPFs29 Architecture Harmonisation component-centric –no effort required, product teams independent –high integration cost, organizational tension, Iterative product architecture harmonisation –reduces integration cost –harmonisation cost no immediate ROI, reference architecture agreement

30. software engineering Research Challenges in SA and SPFs30 Architecture Harmonisation Revolutionary architecture adoption –low integration cost, easy product integration, high degree of user interface harmonisation –cost of harmonisation taken in one release cycle

31. software engineering Research Challenges in SA and SPFs31 R&D Organization Mixed responsibility for product teams –simple, no organizational changes, all component extensions useful –high design erosion, schedule pressure from product development Virtual component team –good understanding of product needs, no organizational changes –loyalty conflicts

32. software engineering Research Challenges in SA and SPFs32 R&D Organization Component unit –clear responsibilities, clear interfaces for decision making –“local optimization”, perfectionism

33. software engineering Research Challenges in SA and SPFs33 Funding “Barter” –no visible changes, little overhead, easy to initiate –“handshake deals” easy to violate, project delays easily propagate, setbacks may easily kill initiative Taxation –more trustworthy and long term focus (roadmaps and release plans) –changes become visible (budget & organization), no competitive pressure for component team

34. software engineering Research Challenges in SA and SPFs34 Funding Licensing/royalty –market pressures, COTS replacement easily identified –component needs to be mature, if core competence, still no market pressure

35. software engineering Research Challenges in SA and SPFs35 Shared component scoping Only common features –efficient way of achieving early success –complex interface, inefficient knowledge management Complete component with plug-in capability –simple interface, component knowledge in one place –integration cost

36. software engineering Research Challenges in SA and SPFs36 Shared component scoping Encompassing component –efficient development in case of complex QAs –larger component team

37. software engineering Research Challenges in SA and SPFs37 Decision Framework Initial Adoption - early successes –Feature selection: new, but common features –Architecture harmonisation: component- centric –Organization: mixed responsibility for product teams –Funding: “barter” –Shared component scoping: only common features

38. software engineering Research Challenges in SA and SPFs38 Decision Framework Expanding scope –Feature selection: existing, but evolving, components –Architecture harmonisation: iterative product architecture harmonisation –Organization: virtual component team –Funding: taxation –Shared component scoping: complete components with plug-in capability

39. software engineering Research Challenges in SA and SPFs39 Decision Framework Increasing “maturity” –Feature selection: all components –Architecture harmonisation: revolutionary architecture adoption –Organization: component unit –Funding: licensing/royalty –Shared component scoping: encompassing component

40. software engineering Research Challenges in SA and SPFs40 Summary Early successesIncreasing scopeIncreasing maturity Feature selectionNew, but common features Existing, but evolving, components All components Architecture harmonisation Component- centric Iterative product architecture harmonisation Revolutionary architecture adoption R&D organizationMixed responsibility for product teams Virtual component teams Component units Funding“Barter”TaxationLicensing Shared component scoping Only common features Complete components with plug-ins Encompassing component

41. software engineering Research Challenges in SA and SPFs41 Overview introduction trends in software engineering software product families –adoption –maturity model software architecture –explicit design decisions conclusions

42. software engineering Research Challenges in SA and SPFs42 SPF Assessment Framework Assess the maturity of an organization regarding SPFs: 4 aspects Business Architecture Process Organization Based on J. Bosch, Maturity and Evolution in Software Product Lines: Approaches, Artefacts and Organization, Proceedings SPLC2, August 2002 and Frank van der Linden, Jan Bosch, Erik Kamsties, Kari Känsälä, Lech Krzanik, Henk Obbink A Maturity Framework for Software Product Families Evaluation, Product Family Engineering Workshop (PFE5), 2003. FOCUS

43. software engineering Research Challenges in SA and SPFs43 Aspect - Business Aspects Identity – integration between SPF and organization Vision – short, medium or long term perspective Objectives – none, qualitative, quantitative Strategic planning - e.g. roadmapping, ad-hoc to institutionalized process Levels Reactive Awareness Extrapolate Proactive Strategic

44. software engineering Research Challenges in SA and SPFs44 Aspect - Architecture Architectural “Maturity” Levels

45. software engineering Research Challenges in SA and SPFs45 product populations program of software product families Architectural “Maturity” Levels software product family configurable product increase product size (hierarchical SPFs) increase PF scopedecrease derivation cost Nokia telecom switchesPhilips consumer electronics Telelarm

46. software engineering Research Challenges in SA and SPFs46 Independent Products Product family architecture: not established Product quality: ignored or managed in an ad-hoc fashion Reuse level: Although ad-hoc reuse may occur, there is no institutionalized reuse Domain: emerging Software variability management: absent Example: most SMEs and several large companies

47. software engineering Research Challenges in SA and SPFs47 Standardized Infrastructure description –operating system –database –GUI –etc. some additional proprietary glue code might be present P D

48. software engineering Research Challenges in SA and SPFs48 Standardized Infrastructure Product family architecture: specified external components Product quality: infrastructure supports certain qualities, for the remaining qualities an over- engineering approach is used Reuse level: only external components Domain: later phases of emerging or the early phases of maturing domain Software variability management: limited variation points from the infrastructure components Example: Vertis Information Technology

49. software engineering Research Challenges in SA and SPFs49 Platform description: –functionality common to all products in the product family is captured –infrastructure is typically also included P D

50. software engineering Research Challenges in SA and SPFs50 Platform Product family architecture: only the features common to all products are captured Product quality: inherited from the platform Reuse level: reuse of internal platform components Domain: mature Software variability management: managed at platform level Example: Symbian OS

51. software engineering Research Challenges in SA and SPFs51 Software Product Family description: domain assets capture functionality common to several or most products P D product family architecture component set product 1product 2product n external internal...

52. software engineering Research Challenges in SA and SPFs52 Software Product Family Product family architecture: fully specified Product quality: a key priority for development Reuse level: managed Domain: late stages of maturing or the early stages of the established phase Software variability management: many variation points and dependencies between them Example: Axis Communications AB

53. software engineering Research Challenges in SA and SPFs53 Configurable Product (Base) A D marketingdevelopmentcustomer req. SW product post fielding upgrades license key driven conf. 3 rd part software

54. software engineering Research Challenges in SA and SPFs54 Configurable Product (Base) Product family architecture: enforced Product quality: quality attributes are implemented as variation points in the architecture and components Reuse level: automatic generation of product family members Domain: established Software variability management: automated selection and verification of variants at variation points has been optimized Example: TeleLarm AB

55. software engineering Research Challenges in SA and SPFs55 Two Dimensions of “Maturity” organizational maturity domain maturity (stability) low medium high lowmediumhigh CPB PL SI/PL IP/SI example

56. software engineering Research Challenges in SA and SPFs56 Variation Binding Times READCDimpl. comp linkinst.startrun SI PL SPL CPB

57. software engineering Research Challenges in SA and SPFs57 Process Maturity We follow CMMI (staged representation) Aspects : –Predictability: How predictable is software development at each level. –Repeatability: How repeatable is the development process at each level. –Quantifiability: How quantifiable is software development.

58. software engineering Research Challenges in SA and SPFs58 CMMI Levels Level 1: Initial Level 2: Managed Level 3: Defined Level 4: Quantitatively Managed Level 5: Optimizing

59. software engineering Research Challenges in SA and SPFs59 Organizational Maturity Aspects Geographic distribution Culture Roles & Responsibilities Product life cycle Levels Unit oriented Business lines oriented Business group/division Inter-division/companies Open business

60. software engineering Research Challenges in SA and SPFs60 Organizational Models development department business units –unconstrained model –asset responsibles –mixed responsibility domain engineering units –single domain engineering unit –one software architecture unit + component units hierarchical domain engineering units

61. software engineering Research Challenges in SA and SPFs61 Hierarchical Product Families product populations

62. software engineering Research Challenges in SA and SPFs62 Overview introduction trends in software engineering software product families –adoption –maturity model software architecture –explicit design decisions conclusions

63. software engineering Research Challenges in SA and SPFs63 Architecture-centric SE software engineering community has evolved through project-centric SE product-centric SE architecture-centric SE software architecture is core to modern software development and evolution

64. software engineering Research Challenges in SA and SPFs64 Software Architecture software architecture Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. [IEEE Standard P1471] quality requirements Quality requirements can be categorised into development QRs, e.g. maintainability, and operational QRs, e.g. performance and reliability

65. software engineering Research Challenges in SA and SPFs65 Why software architecture? first class representation of SA during design –stakeholder-based assessment –assessment of quality attributes implementation –configuration management –software product lines run-time –dynamic software architectures, post-fielding upgrades, dynamic reorganization, etc.

66. software engineering Research Challenges in SA and SPFs66 Architectuur – 3 dimensions businesstechnology (software) organisation aspect viewpoint run-time development process conceptual infrastructurerepresentation design assessment evolution technology

67. software engineering Research Challenges in SA and SPFs67 Software Architecture Use Three types of SA use: single system software product families standardized domain architecture component framework [szyperski 98]

68. software engineering Research Challenges in SA and SPFs68 Community Assumptions software architecture is hard to change consequently, design architectures carefully –architecture assessment –architecture design software architecture is static, the stable part of the system inflexible architecture is good/fact of life!

69. software engineering Research Challenges in SA and SPFs69 Flexible Architectures? why is SW architecture hard to change? ignored aspect of the problem loss of design knowledge – vaporizes during –architecture design –component development –system evolution  architecture design decisions are lost

70. software engineering Research Challenges in SA and SPFs70 Consequences lack of first-class representation design decisions cross-cutting and intertwined high cost of change design rules and constraints violated obsolete design decisions not removed

71. software engineering Research Challenges in SA and SPFs71 Architecture Design Decisions architecture design decisions consists of restructuring effect design rules design constraints rationale - new principles, guidelines, etc. and are taken in response to functional requirements quality requirements

72. software engineering Research Challenges in SA and SPFs72 Example – Fire Alarm System 1. restructuring 2. design rule: operation tick() 4. design constraint: tick() exec. time < X ms 5. rationale: least resource consuming mechanism to achieve concurrency 3. design rule: register at scheduler on creation

73. software engineering Research Challenges in SA and SPFs73 Architecture Design Decisions software architecture = domain model + ADD1 + … + ADDn

74. software engineering Research Challenges in SA and SPFs74 Architecture Notation Problems no SOC at the architectural level withdrawing DD’s is hard imposing new DD’s is hard DD1 DD2 DD3 DD4 DD5 DD6 DD7 DD1 DD2 DD3 DD5 DD6 DD7 DD8 DD4 DD2

75. software engineering Research Challenges in SA and SPFs75 How to model ADDs? traditional composition techniques lack expressiveness some initial, partial ideas –implementation: architectural fragments –design: ASICO inheritance aggregation superimposition aspect weaving SOP etc.

76. software engineering Research Challenges in SA and SPFs76 Architectural Fragments

77. software engineering Research Challenges in SA and SPFs77 Example: Observer Pattern architecture Observer roles subject variables dependents : Collection; methods addDependent(newDependent : Object) begin... end; removeDependent(aDependent : Object) begin... end; observedMethod() begin for each d in dependents do d.update(self); proceed; end; observer interface update(Object); end; initial begin subject.addDependent(observer); end; end; // Observer L ay OM – Layered Object Model

78. software engineering Research Challenges in SA and SPFs78 Example: Measurement System architecture MeasurementSystemArchitecture roles sensor interface read end; actuator interface activate end; trigger acquaintances item-factory; methods trigger begin item-factory.trigger; proceed; end; end; item-factory layers prototype-item : PartOf(measurement-item); methods trigger begin measurement-item mi; mi := prototypeItem.copy; if (inCalibration) then mi.calibrate; end; mi.start; end; calibrate(measurement-item mi) begin prototype-item.become(mi); end; end; measurement-item acquaintances sensor; actuator; interface start; end; end; // MeasurementSystemArchitecture

79. software engineering Research Challenges in SA and SPFs79 Example: Measurement System application MeasurementSystem-example begin architectures aMS : MeasurementSystemArchitecture where c is-a sensor with layers a : Adapter(accept value as getFrame); end; tr is-a trigger; l is-a actuator; bci is-a measurement-item with layers sensor : Acquaintance(c); actuator : Acquaintance(l); end; o1 : Observer where tr is-a subject with layers a: Adapter(accept trigger as observedMethod); end; ui is-a observer, end; o2: Observer where c is-a subject with layers a: Adapter(accept getFrame as observedMethod); end; ui is-a observer; end; components c : Camera; tr : LightContactTrigger l : Lever; bci : BeerCanItem; ui : UserInterface; end; // MeasurementSystem-example fragment 1 fragment 2 fragment 3 domain comps.

80. software engineering Research Challenges in SA and SPFs80 Example: Measurement System

81. software engineering Research Challenges in SA and SPFs81 Conclusion introduction trends in software engineering software product families –adoption –maturity model software architecture –explicit design decisions conclusions

82. software engineering Research Challenges in SA and SPFs82