Product Line

Research Challenges in
Software Architecture and

Software Product Families
oftware engineering
Jan Bosch
Professor of Software Engineering
University of Groningen, Netherlands
Jan.Bosch@cs.rug.nl
http://www.cs.rug.nl/~bosch
University of Antwerp, March 2004

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

Current Research Topics
architecture assessment
usability modifiability
EU project STATUS assessment
software
modeling design architecture variability
decisions explicitly management
EU project CONIPF
feature-based
architectural centric
oftware engineering
system construction evaluation/

maturity
design erosion
software
models
product
explicit architecture families software variability
information management
Industrial Partners
• Ericsson Software • Philips Research, Medical,
Technology Consumer Electronics and
• Althin Medical PDSL
• Axis Communications • Baan
• Symbian (earlier Ericsson • Thales Naval Netherlands
Mobile) • Robert Bosch GmbH
• EC-Gruppen
• Securitas Larm • Information Highway
• Ericsson Software Group
Architecture Research Lab • LogicDIS
oftware engineering
• Nokia • ICT Embedded

• CombiTech Software
• Vertis Information
Technology
• Rohill Technologies
currently ongoing cooperation

Where are we going? Bioterial age
20 years
How fast?
Information age
50 years
Industrial age
360 years
Agrarian age
oftware engineering
Source: “The Coming Biotech Age”, Richard W. Oliver- McGraw-Hill

6000 BC 1760
Time

Innovation Adoption
*maturity = 50 million users in the US
technology maturity*
years 38 years
25 years
13 years
oftware engineering
10 years
5 years
technologies
radio phone TV cable internet

Innovation: Tactics
• follower: watch
trends and react
accordingly
(reactive)
• shaper: create the
technology
underlying new
oftware engineering
trends (proactive)

Trend: software size
software needs in products constantly increasing

person years per product
Philips
typical number of errors

1000
10000
per product
100
oftware engineering
1000
10
1990 1995 2000 2005

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
oftware engineering
– from stand-alone to signal exchange to

behavioural integration

Trend: Variability
Variability needs in software are

constantly increasing
because
• variability moves from mechanics and
hardware to software
oftware engineering
• design decisions are delayed as long

as economically feasible

Examples
• car engine controllers

• steer by wire
• telecom switches
• Transmeta’s Crusoe chip
oftware engineering

Mobile Phones
GSM 900
GSM 1900
GSM 900/1800
oftware engineering
GSM 900/1900
GSM 900/1800/1900

BPM @ Intershop
oftware engineering

product-family component set

architecture
external
internal
oftware engineering
...
product 1 product 2 product n

Trend: Variability
software parts (SW)
variability electronic parts (HW) standardization

(flexibility of SW) (economies of scale)
oftware engineering
mechanical parts

Trend: Variability
marketing development customer
req.
SW
oftware engineering
product
post fielding upgrades
license key driven conf.
3rd part software

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
oftware engineering
• software variability is expressed through

variation points and associated variants
• variation points delay design decisions

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
oftware engineering
– open – possible to add new variants to set

– closed – set of variants is closed
• can be introduced and bound at any level

Trend: Later Binding
trend is towards later binding and

increased automation
multi-dimensional
composition of concerns T C F
(e.g. AOP)
feature selection &

T C F
ciomposition
testing T C F
oftware engineering
architectural
T C F
configuration
requirements architecture detailed producer-site installation-site

implementation start-up run-time
engineering design design configuration configuration
legend T traditional C current F future

Software Challenge
increasing SW size increasing variability

per product requirements
develop fewer products develop more products

oftware engineering

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
oftware engineering
• SVM in product derivation – Sybren and

Marco
• variability assessment – Sybren
• case studies – Jilles, Michel, Sybren and
Marco
Overview
• introduction
– adoption
– maturity model
oftware engineering
• conclusions
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
oftware engineering
– high degree of “organizational noise”

– inefficient knowledge management
– evolution causes ripple effects through the R&D
organization
– component value not linear
Component value not linear
component value
100%
reduced value due
to inefficiencies
n
tio
la
re
ed
m
oftware engineering
su
as
actual
relation
product-specific
100% requirements covered

Decision Dimensions
architecture
harmonisation
feature
selection
new common revolutionary

features adoption
existing, evolving iterative

components harmonisation
old, generic
components component
centric
only
common mixed
component features responsibility
with plug-in
virtual
team
encompassing
oftware engineering
"barter"
shared component component
component unit
scoping
taxation
organization
licensing/
royalty
funding

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
oftware engineering
understood
– little time for pay-back on product-specific
components, cost of implementing superset of
features
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
oftware engineering

Architecture Harmonisation
• component-centric
– no effort required, product teams
independent
– high integration cost, organizational
tension,
• Iterative product architecture
harmonisation
oftware engineering
– reduces integration cost

– harmonisation cost no immediate ROI,
reference architecture agreement
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
oftware engineering

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
oftware engineering
– good understanding of product needs,

no organizational changes
– loyalty conflicts
R&D Organization
• Component unit
– clear responsibilities, clear interfaces
for decision making
– “local optimization”, perfectionism
oftware engineering

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
oftware engineering
– more trustworthy and long term focus (roadmaps

and release plans)
– changes become visible (budget & organization),
no competitive pressure for component team
Funding
• Licensing/royalty
– market pressures, COTS replacement
easily identified
– component needs to be mature, if core
competence, still no market pressure
oftware engineering

Shared component scoping
• Only common features

– efficient way of achieving early success
– complex interface, inefficient
knowledge management
• Complete component with plug-in
capability
oftware engineering
– simple interface, component knowledge

in one place
– integration cost
Shared component scoping
• Encompassing component
– efficient development in case of
complex QAs
– larger component team
oftware engineering

Decision Framework
• Initial Adoption - early successes
– Feature selection: new, but common
features
– Architecture harmonisation: component-
centric
– Organization: mixed responsibility for
product teams
oftware engineering
– Funding: “barter”
– Shared component scoping: only
common features

Decision Framework
• Expanding scope
– Feature selection: existing, but
evolving, components
– Architecture harmonisation: iterative
product architecture harmonisation
– Organization: virtual component team
oftware engineering
– Funding: taxation
– Shared component scoping: complete
components with plug-in capability

Decision Framework
• Increasing “maturity”
– Feature selection: all components
– Architecture harmonisation:
revolutionary architecture adoption
– Organization: component unit
– Funding: licensing/royalty
oftware engineering
– Shared component scoping:

encompassing component

Summary
Early successes Increasing scope Increasing
maturity
Feature selection New, but Existing, but All components

common evolving,
features components
Architecture Component- Iterative product Revolutionary
harmonisation centric architecture architecture
harmonisation adoption
R&D organization Mixed Virtual Component units

oftware engineering
responsibility component
for product teams
teams
Funding “Barter” Taxation Licensing
Shared Only common Complete Encompassing
component features components component
scoping with plug-ins
Overview
• introduction
– adoption
– maturity model
oftware engineering
• conclusions
SPF Assessment Framework
FOCUS
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
oftware engineering
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.

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
oftware engineering
• Reactive
• Awareness
• Extrapolate
• Proactive
• Strategic
Aspect - Architecture
Architectural “Maturity” Levels
independent
products
standardized
infrastructure
platform
product
oftware engineering
population
software
product
line
program of
product lines
configurable
product base

Architectural “Maturity” Levels
software product family
program of configurable
product populations
software product families product
oftware engineering
increase product size increase PF scope decrease derivation

(hierarchical SPFs) cost
Nokia telecom switches Philips consumer Telelarm
electronics
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
oftware engineering
• Domain: emerging
• Software variability management: absent
• Example: most SMEs and several large
companies
Standardized Infrastructure
• description
– operating system
– database
– GUI
– etc.
some additional proprietary glue code
oftware engineering
might be present
P D

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
oftware engineering
phases of maturing domain

• Software variability management: limited
variation points from the infrastructure
components
• Example: Vertis Information Technology
Platform
• description:
– functionality common to all products in
the product family is captured
– infrastructure is typically also included
oftware engineering
P D

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
oftware engineering
• Domain: mature
• Software variability management:
managed at platform level
• Example: Symbian OS
Software Product Family
• description: domain assets capture
functionality common to several or
most products
product family component set
architecture
external
internal
oftware engineering
...
product 1 product 2 product n

P D

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
oftware engineering
• Software variability management: many

variation points and dependencies
between them
• Example: Axis Communications AB
Configurable Product (Base)
marketing development customer
req.
SW
product
oftware engineering
post fielding upgrades

license key driven conf.
3rd part software
A D

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
oftware engineering
• Software variability management:

automated selection and verification of
variants at variation points has been
optimized
• Example: TeleLarm AB
Two Dimensions of “Maturity”
domain maturity
(stability)
high PL CPB
medium example
oftware engineering
low IP/SI SI/PL

organizational
low medium high maturity

Variation Binding Times
CPB
SPL
PL
oftware engineering
SI
RE AD CD impl. comp link inst. start run

Process Maturity
• We follow CMMI (staged

representation)
• Aspects :
– Predictability: How predictable is
software development at each level.
– Repeatability: How repeatable is the
oftware engineering
development process at each level.

– Quantifiability: How quantifiable is
software development.

CMMI Levels
• Level 1: Initial
• Level 2: Managed
• Level 3: Defined
• Level 4: Quantitatively Managed
• Level 5: Optimizing
oftware engineering

Organizational Maturity
Aspects
• Geographic distribution
• Culture
• Roles & Responsibilities
• Product life cycle
Levels
• Unit oriented
oftware engineering
• Business lines oriented

• Business group/division
• Inter-division/companies
• Open business
Organizational Models
• development department
• business units
– unconstrained model
– asset responsibles
– mixed responsibility
• domain engineering units
– single domain engineering unit
oftware engineering
– one software architecture unit + component

units
• hierarchical domain engineering units

Hierarchical Product Families
product populations
infrastructure infrastructure infrastructure
component component component
organization
scope 1
shared
artefacts
scope 1.1 scope 1.2

shared shared
artefacts artefacts
PA PB PC P P
production-site
configuration
oftware engineering
installation-time
configuration
CPX CPY CPZ
run-time
configuration
RT P RT P
scope 1.1.1

Overview
• introduction
– adoption
– maturity model
oftware engineering
• conclusions
Architecture-centric SE
software engineering community has
evolved through
• project-centric SE
• product-centric SE
• architecture-centric SE
oftware engineering
software architecture is core to

modern software development and
evolution
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]
oftware engineering
• quality requirements
Quality requirements can be categorised into
development QRs, e.g. maintainability, and
operational QRs, e.g. performance and reliability

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

Architectuur – 3 dimensions
viewpoint
conceptual
process
development
run-time aspect
representation business technology organisation infrastructure

oftware engineering
(software)
design
assessment
evolution
technology
Software Architecture Use
Three types of SA use:

• single system
• standardized domain architecture
component framework [szyperski 98]
oftware engineering

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
oftware engineering
inflexible architecture is good/fact of life!

Flexible Architectures?
• why is SW architecture hard to change?

• ignored aspect of the problem
• loss of design knowledge – vaporizes
during
– architecture design
oftware engineering
– component development
– system evolution
 architecture design decisions are lost

Consequences
• lack of first-class representation

• design decisions cross-cutting and
intertwined
• high cost of change
• design rules and constraints violated
oftware engineering
• obsolete design decisions not

removed

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
oftware engineering
• functional requirements
• quality requirements

Example – Fire Alarm System
Scheduler 1. restructuring
2. design rule:
operation tick()
Input
Input Ouput
3. design rule: register Deviation
at scheduler on creation
Input Deviation Ouput
oftware engineering
Input Ouput
4. design constraint:
tick() exec. time < X ms
Input 5. rationale: least resource consuming
mechanism to achieve concurrency
Input

Architecture Design Decisions
software architecture
=
domain model
+
ADD1
+
…
oftware engineering
+
ADDn

Architecture Notation Problems
• no SOC at the architectural level

• withdrawing DD’s is hard
• imposing new DD’s is hard
DD4 DD8
oftware engineering
DD1
DD1 DD2
DD2 DD3
DD3 DD5
DD2 DD4
DD5 DD6
DD6 DD7
DD7

How to model ADDs?
• traditional composition techniques lack
expressiveness inheritance
aggregation
oftware engineering
• some initial, partial ideas superimposition

– implementation: architectural fragmentsaspect weaving
– design: ASICO SOP
etc.

Architectural Fragments
oftware engineering

Example: Observer Pattern
architecture Observer observer
roles interface
subject update(Object);
variables end;
dependents : Collection; initial
methods begin
addDependent(newDependent : Object) subject.addDependent(observer);
begin ... end; end;
removeDependent(aDependent : Object) end; // Observer
begin ... end;
observedMethod()
begin
for each d in dependents do
oftware engineering
d.update(self);
proceed;
end;
end;
LayOM – Layered Object Model

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

end; sensor;
actuator;
interface
start;
end;
end; // MeasurementSystemArchitecture

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

oftware engineering

Conclusion
• introduction
– adoption
– maturity model
oftware engineering
• conclusions
oftware engineering

Product Line

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Product Line

Hochgeladen von

Copyright:

Verfügbare Formate

Research Challenges in

Software Architecture and

University of Antwerp, March 2004

Research Challenges in SA and SPFs 3

system construction evaluation/

• Nokia • ICT Embedded

Research Challenges in SA and SPFs 5

Source: “The Coming Biotech Age”, Richard W. Oliver- McGraw-Hill

Research Challenges in SA and SPFs 6

radio phone TV cable internet

Research Challenges in SA and SPFs 7

Research Challenges in SA and SPFs 8

software needs in products constantly increasing

typical number of errors

1990 1995 2000 2005

systems increasingly need to be

– from stand-alone to signal exchange to

Research Challenges in SA and SPFs 10

Variability needs in software are

• design decisions are delayed as long

Research Challenges in SA and SPFs 11

• car engine controllers

Research Challenges in SA and SPFs 12

Research Challenges in SA and SPFs 13

Research Challenges in SA and SPFs 14

product-family component set

product 1 product 2 product n

Research Challenges in SA and SPFs 15

software parts (SW)

variability electronic parts (HW) standardization

Research Challenges in SA and SPFs 16

marketing development customer

Research Challenges in SA and SPFs 17

• software variability is expressed through

Research Challenges in SA and SPFs 18

– open – possible to add new variants to set

Research Challenges in SA and SPFs 19

trend is towards later binding and

feature selection &

requirements architecture detailed producer-site installation-site

legend T traditional C current F future

Research Challenges in SA and SPFs 20

increasing SW size increasing variability

develop fewer products develop more products

Software Product Families

Research Challenges in SA and SPFs 21

• SVM in product derivation – Sybren and

– high degree of “organizational noise”

Research Challenges in SA and SPFs 25

new common revolutionary

existing, evolving iterative

Research Challenges in SA and SPFs 26

• New, but common features

Research Challenges in SA and SPFs 28

– reduces integration cost

• Revolutionary architecture adoption

Research Challenges in SA and SPFs 30

– good understanding of product needs,

Research Challenges in SA and SPFs 32

– more trustworthy and long term focus (roadmaps

Research Challenges in SA and SPFs 34

• Only common features

– simple interface, component knowledge

Research Challenges in SA and SPFs 36