DAIMI Henrik Bærbak Christensen 1

Product Lines

Architectural Reuse

DAIMI Henrik Bærbak Christensen 2

A Simplified Development Process

FunctionalRequirements

QualityRequirements

SoftwareArchitecture

ArchitecturalRequirements

Implementation?

DAIMI Henrik Bærbak Christensen 3

Architectural Reuse

  “A software architecture represents a significant investment of time and effort. So it is natural to want to maximize the return on this investment by re-using an architecture across multiple systems.”– Architectures are valuable intellectual property

– reusing asset is cheaper than reinventing it…

DAIMI Henrik Bærbak Christensen 4

Definition

  Software product line– a set of software-intensive systems sharing a

common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

  Assets– base architecture– architectural (tailorable) elements– designs, documentation, test plans, project

management artifacts…

DAIMI Henrik Bærbak Christensen 5

War stories

  Nokia– 25-30 models per year (up from 4 models per year)

  Motorola– 400% productivity improvement for one-way pagers

  HP– time to market reduced by factor 7– productivity increase by factor 6– family of printer systems

  Cummins Inc– reduce production time 1 year → 1 week– diesel engine software

DAIMI Henrik Bærbak Christensen 6

Nuts and Bolts

  Success:   Commonalities shared by products can be

exploited through reuse of assets.– Requirements: most are common no req. analysis– Arch. design: is stable– Elements: code and design reused– Modeling / analysis: real-time analysis reused– Testing: already in place– Project planning: budget, work-break-down, known

with high confidence

DAIMI Henrik Bærbak Christensen 7

Nuts and Bolts

– Processes, methods, tools: SCM, tool environments, coding standards, can be transferred

– People: transferable between projects– Exemplar systems: Deployed systems serves as high-

quality prototypes– Defect elimination: Previous generations’ defects

have been eliminated.

DAIMI Henrik Bærbak Christensen 8

Why not reuse libraries?

  Appealing idea– “library of snippets from previous projects; everybody

must check here before coding himself”

  Does not work because:– library too sparse: nothing found– library too rich: difficult to search– elements too small: easier to rewrite than understand– elements too large: not right for problem at hand– GIGO: garbage in garbage out

  Architectural models differs !!!

DAIMI Henrik Bærbak Christensen 9

Why product lines works!

  Product lines works because– very strict architectural context for elements– architecture is defined– functionality / domain is fixed at overall level– quality attributes are defined and known– strategic / planned reused, not opportunistic

DAIMI Henrik Bærbak Christensen 10

Product line architectures

  Product line– Commonality: The core architecture

• defines flow of control• defines element types• defines variability points

  Variability points– Framework techniques in OO– Static techniques (often using CM tools)

• conditional compilation [ #ifdef in C ]• conditional linkage [library V1 or V2]

– Dynamic techniques• shared libraries / DLL• parameterization [windows registry/ini files, etc]

DAIMI Henrik Bærbak Christensen 11

Evaluation

  Basically the same architectural evaluation techniques can be applied– QAW, ATAM, …

  Special focus on variability points

DAIMI Henrik Bærbak Christensen 12

Adoption strategies

  Top-down– business drivers and goals point towards PLA

  Bottom-up– developers detect needless duplication

  Growth– Proactive

• up-front design “revolution”

– Reactive• evolution

  But – lot of domain knowledge critical in any case: “You will build it three times before you know the points of variability”

DAIMI Henrik Bærbak Christensen 13

Maintenance / Evolution

  Adding features– spin-off in separate product (line?)

• back to multiple maintenance of similar systems• redundency

– include in product line• upgrading old products?

– keeping products in sync is expensive…

• sufficient commonality between products?

DAIMI Henrik Bærbak Christensen 14

Organizational structure

  Suggestions by Bosch– Development department = single unit– Business units = separate teams

• those needing function X add it to product line, supports it

– Domain engineering unit = parts department• one unit responsible for core assets

• other units derive products from product line

– Hierarchical domain engineering unit• very large product lines may need hierarchical decomp.

  Tracz: Only parts department will work!– projects will have their own agenda that does not match that of

the product line…• why should project X help project Y when we are pressed for time

already???