7 - Architetture Software - Software product line

3,138 views

Published on

Published in: Technology, Business

7 - Architetture Software - Software product line

  1. 1. Software Product Lines Paolo Ciancarini
  2. 2. Agenda•  Design for reuse•  Software product lines•  Organizational strategies
  3. 3. MotivationComplexity, size, and number of software-intensive systems a major problem forsoftware companies•  routine functionality is custom-written repeatedly from scratch, over and over•  a quagmire of data formats and applications•  ambiguities and interoperability conflicts not only across different companies but even among groups within the same company
  4. 4. Family of systemsThere is a need to•  reduce the development effort•  increase productivitymoving from designing single products to producingengineering families of products•  identifying generic solutions to common problems•  building related products by assembling components•  providing universal platforms•  synthesizing systems automatically
  5. 5. Product Line Architecture (PLA)Product Line Architecture:a common design framework that•  standardizes & maximizes reuse potential of all software artifacts generated during development -  these artifacts include requirements, designs and patterns, and, of course, actual code components•  specifies common functionality across systems•  clearly identifies variation points
  6. 6. Capturing PLA•  Common core: features common to all products•  FA: features specific to product A•  FB: features specific to product B•  Product A = Common core + FA•  Product B = Common core + FB Common FA Common FB core core Product A Product B
  7. 7. Lessons from other industries•  Any customer can have Any customer can a car painted any have a car painted colour that he wants so any colour that he long as it is black” - wants so long as it is Henry Ford black” Henry Ford
  8. 8. Architecture and standard componentsArchitecture was simple and flexibleBuilt from standard parts
  9. 9. Standards and diversityWhat varied? Use features to satisfy diversity of needsWhy it worked? Standard architecture and common partsWhat resulted? Product and assembly lines
  10. 10. The role of architecture in sw
  11. 11. Component based developmentSoftware factories exploit component-baseddevelopment (CBD)•  They engineer applications by composing prefabricated components in the hope that this will increase software reuse•  Strategy: building software systematically and opportunistically exploting reference architectures about a domain and competitive knowledge for systems in that domain
  12. 12. DomainWhat is a domain?•  Area of expertise with specialized particular tasks•  Populated by products with reusable structuresExample: software for a car•  Console•  Engine•  Brakes•  …
  13. 13. Domains vs product lines Domains are in the problem space, product lines are in the solution space•  Domain •  Product line•  Consumer electronics •  Philips Digital TVs•  Avionics •  Boeing 747 Family•  Compilers •  GNU compiler suite•  Videogames •  Games using the same engine
  14. 14. Multimedia Product Line VCR Features:" •  Play Tape" Answering machine Features:" •  Rewind Tape" •  Play Announcement" •  Forward Tape" •  Record Announcement" •  Button Control" •  Rewind Announcement" •  Signal Handling" •  Play Message" •  Record Message" •  Rewind Message" •  Forward Message"Audio Player Features " •  Display Messages"•  Play Tape" •  Button Control"•  Record Tape" •  Signal Handling"•  Rewind Tape"•  Forward Tape"•  Button Control"•  Signal Handling"
  15. 15. Product lines•  Product line technology builds families of products exploiting some common core assets and managing their variability•  Ex.: Boeing 757 e 767 share 60% of components•  Ex.: Mercedes Benz class E models share 70%•  Scale economies and efficiency•  Integrating rather than creating
  16. 16. Software reuseWhy is software reuse critical?•  provides predictable behavior (better testing)•  enables shorter delivery timeframes•  reduces repeated building from scratch of common functionalityHistory of the concept dated back to 1950 s•  subroutine libraries•  standardized class libraries
  17. 17. Old ways to reusing softwareOld definitions of sw reuse include:•  Re-use is considered as a means to support the construction of new programs using in a systematical way existing designs, design fragments, program texts, documentation, or other forms of program representation.•  Reusability is the extent to which a software component can be used (with or without adaptation) in multiple problem solutions.
  18. 18. Reusable assets Reference Design Architecture Pattern Legacy Architectural Application Mechanism Pattern Packaged Language Application Development Reference Method Model Architectural Programming Decision Pattern Pattern Component Library Component Architectural Pattern Architectural Application Style Framework
  19. 19. ReuseReuse aspects•  It is not an end in itself but a means to increase productivity and improve quality•  Reusable components are not limited to code•  Software components may need adaptation -  Adaptive design Community & Enterprise Information Portals -  Variant design Health ••• other vertical•  Horizontal and Care Financial Insurance domains vertical reuse E-Business facilities ••• other (Appl. dev., Intelligence, Integration, …) facilities Metamodel Interoperability ••• Distributed Run-time Middleware
  20. 20. BenefitsBy planning ahead in support of families ofmultiple systems, an organization•  reduces the development time and cost of new products•  reduces risk and improves quality•  manages its legacy assets more efficiently•  evolves a common marketing strategy•  makes decisions based on the (value of) the asset base and the strategic goals
  21. 21. Software product lines (SPL)Definition by Clemens and Northrop (SEI, 2002):•  A set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment•  They are developed from a common set of core assets in a prescribed way•  Example: software for TV sets (Philips)
  22. 22. SPL metamodel Product lines -  Exploit commonality -  Bound variability
  23. 23. Why SPL work?Product lines amortize the investment in these core assets:•  requirements (and requirements analysis)•  domain models•  software architecture (and design)•  performance engineering•  documentation•  test plans, test cases, and test data•  people: their knowledge and skills•  processes, methods, and tools•  budgets, schedules, and work plans•  components and services
  24. 24. A few success stories•  Celsius tech: family of naval command and control systems•  Ericsson AXE: family of telecommunications switches•  Lucent Technologies: 5ESS telecom switch•  US Naval Undersea Warfare Center: A-7°•  SALION: Acquisition Management Systems•  Toshiba: Electric Power Generation Plant•  BOEING: Bold Stroke Avionics SW Family•  BOSCH: Gasoline Systems•  CUMMINS Inc.: Diesel SPL•  LSI: RAID controller firmware SPL•  GM: General Motors Powertrain (GMPT)•  PHILIPS: Medical Systems•  Nokia: mobile phones
  25. 25. SPL issues•  ROI: when are they convenient?•  Organization of work•  Domain engineering and scoping•  Design for reuse of commonality•  Control of variability
  26. 26. ROI of SPL ROI
  27. 27. ROI of SPL
  28. 28. Convenience of Product Lines 29
  29. 29. Key concepts
  30. 30. Organization by product lines (from Krueger 2009)
  31. 31. Single system perspective (from Krueger 2009)
  32. 32. Product Line EngineeringPL Engineering uses domain-driven, model-based methodology for building software•  Two complementary processes -  Modeling (domain engineering) -  Development (applications engineering)
  33. 33. Product Line Engineering Domain Engineering Experts " Technology" Domain Experts & 1. Modeling (Domain Engineering, Domain
 a.k.a Design-for-Reuse)" knowledge" Refers to original design, i.e.,
 the use of first principles" " Solution 
 models"Domain Experts & IT technicians New
 Domain Expert requirements"Development (Application Engineering, 
 2. a.k.a design-with-Reuse)" Product" refers to routine practice, i.e., 
 the use of known solutions"
  34. 34. Reusable assetsReuse in general needs to be planned for•  create a reusable asset, i.e. one that is fully documented, has good code and robust scripts; is verified independently with high confidence•  create a usable asset, i.e. one that is adaptable and that is usable in a variety of simulatorsDesign for reuse/use involves•  analysis to identify explicitly variations to anticipate adaptations, and•  design for adaptability, engineered a priori to create assets for future developments
  35. 35. ProblemsDesign for commonality•  standardizing assets by encapsulating common featuresAnalysis of variation•  must explicitly identify variations that anticipate adaptationsControl of variability•  provide assets flexibility without compromising commonality
  36. 36. Levels of reuse•  Domain-independent components -  Designed for reuse to fit any product (e.g., general purpose class libraries)•  Domain-specific components -  Designed for reuse to fit several different products in a given market (e.g., multi-media, jpeg encoders, data communications, digital signal processing, ...)•  Product-specific components -  Designed for reuse within a specific application (to generate various instances or products)
  37. 37. SPL: main issuesThere are several issues to consider•  Scoping the SPL (i.e. identify domain and assets)•  Define a reference architecture•  Define a PLA•  Identification of reusable components at the appropriate level of abstraction•  Variability management•  Architectural compliance•  SPL maintenance
  38. 38. What is SPL scoping?•  the initial phase of a SPL, aims to identify products, features, potential of the market domain and reusable assets•  determines the viability of the SPL•  maximizes the economical value of the SPL•  Essential factors in SPL:-  Investment-  Management-  Planning-  Business strategy } scoping
  39. 39. Traditional Engineering Model Domains! Individual ! applications! Individual ! domains! Systems! Individual
 implementations! Assets!
  40. 40. SPL Model Domains! Domain
 models! • Variability analysis! <<includes>>! Start
 Startup! compressor! <<extends>>! <<extends>>! Shutdown! Operator! <<includes>>! Alarm
 <<includes>>! Plant! detected! Remote! Operate! Shutdown! <<extends>>! <<includes>>! <<includes>>! Local! Remote! <<includes>>! Local
 Shutdown! Stop
 compressor! • Features! 2 2 CapsuleC CapsuleB CapsuleA Class Diagram (domain model) :CapsuleA Collaboration Diagram (role model) :CapsuleB CapsuleC connection Reusable 
 network :CapsuleB CapsuleC Component! Systems! Cn Cn Cn •••" Cn Cn Assets! Architectural
 Framework!
  41. 41. Product Lines and UML Domain Analysis Problem Analysis Solution Analysis Specify basic problem Describe implementationIdentify the entities overall functionality, and of the solution in terms ofand their relations in the identify and specify system interactions betweenapplications domain" features" classes and permitted (expected) overall system behavior" Problem Model (Activity diagram) Behavioral Model (traces + constraints) Domain Model (class diagram) Requirements Model Implementation Model (Use Case diagram) (Collaboration diagram)
  42. 42. Variability in requirementsOptional requirements Cross-cutting aspectsOptional scenarios Varying flow of events
  43. 43. Eriksson, Börstler,Borg, Softwareproduct linemodeling madepractical CACM,Dec. 2006
  44. 44. A reference domain for automotive From Bak, Exemplar of Automotive Architecture with Variability, 2010
  45. 45. Software Defined Radios•  Variation points in radio configuration, board configuration, software configuration
  46. 46. SDRs PL•  By applying product line techniques to SDRs•  Can manage different configurations of the radio -  Deploying components on alternative hosts -  Deployments with –  No waveforms –  One waveform –  Different combinations of waveforms•  Can show radio in different states as radio starts up or transitions from one waveform to another
  47. 47. SPL according to SEI(5th framework, 2007)
  48. 48. SPL according to SEI
  49. 49. SPL according to SEI
  50. 50. Two approaches to start a SPL•  Proactive: Develop the core assets first •  Develop the scope first and use it as a “mission” statement. •  Products come to market quickly with minimum code writing. •  Requires upfront investment and predictive knowledge•  Reactive: Start with one or more products •  From them, generate the product line core assets and then the future products; the scope evolves more dramatically •  Much lower cost of entry •  The architecture and other core assets must be robust, extensible, and appropriate to future product line needs
  51. 51. SummaryProduct Line Architectures, rather thansingle-product architectures, supportsystematic reuse•  represent recurrent requirements and architectures (i.e., components and interfaces) suitable for solving typical problems in a domain•  depict structures for design related products and provide models for integrating optional/ alternative components•  allow engineers to come up with the right solutions quickly and effectively
  52. 52. Architecture-Centric Development ActivitiesArchitecture-specific activities for SPL include:•  creating the business case for the system•  understanding the requirements•  creating and/or selecting the architecture•  documenting and communicating the architecture•  analyzing or evaluating the architecture•  implementing the system based on the architecture•  ensuring that the implementation conforms to the architecture
  53. 53. From SA to PLA•  Of all a product line’s core assets, the product line architecture is the most important one for ensuring technical success.•  If an organization already uses disciplined practices to develop single-product software under the aegis of a software architecture, it is well poised to •  define a product line architecture •  Identify the core assets •  Build products from those core assets.
  54. 54. Test questions•  What is a software product line?•  What is a product line architecture?•  What is variability management?
  55. 55. References•  Clemens & Northrop, Software Product Lines, Addison Wesley, 2002•  Gomaa, Designing SPL with UML, Addison Wesley, 2005•  Pohl & Böckle, SPL Engineering: foundations, principles, and techniques, Springer 2005•  vanderLinden & Schmid & Rommes, SPL in action, Springer, 2007•  van Gurp & Bosch & Svahnberg, On the notion of variability in SPL, Conf. on Sw Architecture, 2001•  Eriksson, Bostler, Borg, Software product line modeling made practical. An example from the Swedish defense industry, CACM 2006•  Krueger & Jackson, Requirements engineering for systems and software product lines, White paper IBM Rationa,l 2009
  56. 56. Conferences•  SPLC 2011, Munich, Germany•  Workshop on Variability in Software Product Line Architectures•  Wokshop on Product LinE Approaches in Software Engineering (PLEASE)
  57. 57. Sites•  www.sei.cmu.edu/productlines•  www.biglever.com
  58. 58. Questions?

×