Product Lines

Leveraging Architecture Two ways to do it (at least) Product Lines Use the architecture and core software as a theme with variations to produce multiple products Frameworks “Harden” interfaces to the core software, then sell (or give) the architecture and core software to software vendors as an application platform

Examples Product line: MS Office Office for Windows Office for Windows CE Office for Mac Office Student and Teacher Edition Framework: J2EE (practice calling it “Java EE 5” now)

Things that can be reused Requirements Architectural design Elements (code, but not just code) Modeling and analysis Testing Project planning Processes, methods and tools People Exemplar systems Defect elimination

Product Line Scope Too narrow and the investment is not worth it Too broad and the common parts can be too hard to build or not powerful enough

Architecture for product lines For the most part, designing an architecture is the same, product line or not Additional Factors Identifying variation points Supporting variation points Evaluation must include multiple products

What’s a variation point? An aspect of the system in which the various products require different platform features Example: Office runs on several operating systems Example: Office Student and Teacher edition Word, PowerPoint, Excel, Outlook (not Access) License limited to 3 PCs

Identifying Variation Points Variation points can be discovered at any point in the software lifecycle, especially Business planning Requirements Architecture Implementation Continuous process Starts with the initial design Can continue with each new product

Supporting Variation Points Elements can be included or omitted Include different numbers of elements Select versions of elements

Supporting Variation (cont.) OO techniques Generalization Polymorphism Build extension points into the element Build-time parameterization Reflection – behavior based on context

Evaluation In addition to the normal evaluation: Focus on variation points Need to understand consequences of variations Example: running on different operating systems implies differences in documentation Example: running on Windows CE implies different optimizations

Problem Areas Adoption – the first hurdle! Evolution and the forces that drive it External vendor supplied parts External feature demand Internal new project needs In the product or the platform? Updating older products

Organizational Structure Platform development team Core assets Buy back Stakeholders Business Units Development teams Marketing

summary