DAIMI Henrik Bærbak Christensen 1 Product Lines Architectural Reuse
Dec 20, 2015
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???