Title: Research Challenges in Software Architecture and Software Product Families
1Research Challenges in Software Architecture and
Software Product Families
- Jan BoschProfessor of Software
EngineeringUniversity of Groningen,
NetherlandsJan.Bosch_at_cs.rug.nlhttp//www.cs.rug.
nl/bosch
University of Antwerp, March 2004
2Overview
- introduction
- trends in software engineering
- software product families
- adoption
- maturity model
- software architecture
- explicit design decisions
- conclusions
3Software Engineering group
- Senior members
- prof. dr. ir. Jan Bosch
- dr. Jos Nijhuis (APr)
- dr. Rein Smedinga (APr)
- Post-docs
- dr. Theo Dirk Meijler
- dr. Jilles van Gurp
- dr. Lisette Bakalis
- Ph.D. students
- Michel Jaring (2004)
- Eelke Folmer (2005)
- Sybren Deelstra (2006)
- Marco Sinnema (2006)
- Anton Jansen (2006)
- Fernando Erazo (2007)
- Ivor Bosloper (2007)
- Johanneke Siljee (2007)
- Industrial Ph.D. students
- Rob van Ommering(Philips Research)
- Jan Gerben Wijnstra (Philips Research)
- Alessandro Maccari(Nokia Research/Mobile Phones)
- Ernst Kesseler (Dutch Aerospace Laboratory)
- Sylvia Stuurman(Open Universiteit)
- Emil Petkov (UK)
4Current Research Topics
architecture assessment
usabilityEU project STATUS
modifiabilityassessment
softwarearchitecture
modeling designdecisions explicitly
variabilitymanagementEU project CONIPF
feature-basedarchitectural centricsystem
construction
evaluation/maturitymodels
softwareproductfamilies
design erosion
explicit architectureinformation
software variabilitymanagement
5Industrial Partners
- Philips Research, Medical,Consumer Electronics
and PDSL - Baan
- Thales Naval Netherlands
- Robert Bosch GmbH
- Information Highway Group
- LogicDIS
- ICT Embedded
- Ericsson Software Technology
- Althin Medical
- Axis Communications
- Symbian (earlier Ericsson Mobile)
- EC-Gruppen
- Securitas Larm
- Ericsson Software Architecture Research Lab
- Nokia
- CombiTech Software
- Vertis Information Technology
- Rohill Technologies
currently ongoing cooperation
6Where are we going?How fast?
20 years
50 years
Economic value added
360 years
Source The Coming Biotech Age, Richard W.
Oliver- McGraw-Hill
6000 BC
1760
Time
7Innovation Adoption
maturity 50 million users in the US
technology maturityyears
technologies
8Innovation Tactics
- follower watch trends and react accordingly
(reactive) - shaper create the technology underlying new
trends (proactive)
9Trend software size
- software needs in products constantly increasing
Philips
1000
10000
typical number of errorsper product
person years per product
100
1000
10
1990
1995
2000
2005
10Trend systems of systems
- systems increasingly need to be integrated with
other systems - Information systems
- from manual data exchange to behavioural
integration - embedded/technical systems
- from stand-alone to signal exchange to
behavioural integration
11Trend Variability
- Variability needs in software are constantly
increasing - because
- variability moves from mechanics and hardware to
software - design decisions are delayed as long as
economically feasible
12Examples
- car engine controllers
- steer by wire
- telecom switches
- Transmetas Crusoe chip
13Mobile Phones
GSM 900
GSM 1900
GSM 900/1800
GSM 900/1900
GSM 900/1800/1900
14BPM _at_ Intershop
15Software Product Families
product-familyarchitecture
component set
external
internal
...
product 1
product 2
product n
16Trend Variability
software parts (SW)
electronic parts (HW)
variability(flexibility of SW)
standardization(economies of scale)
mechanical parts
17Trend Variability
marketing
development
customer
req.
SW
product
post fielding upgrades
license key driven conf.
3rd part software
18Variability
- 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 - software variability is expressed through
variation points and associated variants - variation points delay design decisions
19Variation 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
- open possible to add new variants to set
- closed set of variants is closed
- can be introduced and bound at any level
20Trend Later Binding
- trend is towards later binding and increased
automation
21Software Challenge
increasing SW sizeper product
increasing variability requirements
develop fewer products
develop more products
22SVM 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 - SVM in product derivation Sybren and Marco
- variability assessment Sybren
- case studies Jilles, Michel, Sybren and Marco
23Overview
- introduction
- trends in software engineering
- software product families
- adoption
- maturity model
- software architecture
- explicit design decisions
- conclusions
24Adopting 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
- high degree of organizational noise
- inefficient knowledge management
- evolution causes ripple effects through the RD
organization - component value not linear
25Component value not linear
26Decision Dimensions
27Feature 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
understood - little time for pay-back on product-specific
components, cost of implementing superset of
features
28Feature 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
29Architecture Harmonisation
- component-centric
- no effort required, product teams independent
- high integration cost, organizational tension,
- Iterative product architecture harmonisation
- reduces integration cost
- harmonisation cost no immediate ROI, reference
architecture agreement
30Architecture Harmonisation
- Revolutionary architecture adoption
- low integration cost, easy product integration,
high degree of user interface harmonisation - cost of harmonisation taken in one release cycle
31RD 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
- good understanding of product needs, no
organizational changes - loyalty conflicts
32RD Organization
- Component unit
- clear responsibilities, clear interfaces for
decision making - local optimization, perfectionism
33Funding
- Barter
- no visible changes, little overhead, easy to
initiate - handshake deals easy to violate, project delays
easily propagate, setbacks may easily kill
initiative - Taxation
- more trustworthy and long term focus (roadmaps
and release plans) - changes become visible (budget organization),
no competitive pressure for component team
34Funding
- Licensing/royalty
- market pressures, COTS replacement easily
identified - component needs to be mature, if core competence,
still no market pressure
35Shared component scoping
- Only common features
- efficient way of achieving early success
- complex interface, inefficient knowledge
management - Complete component with plug-in capability
- simple interface, component knowledge in one
place - integration cost
36Shared component scoping
- Encompassing component
- efficient development in case of complex QAs
- larger component team
37Decision Framework
- Initial Adoption - early successes
- Feature selection new, but common features
- Architecture harmonisation component-centric
- Organization mixed responsibility for product
teams - Funding barter
- Shared component scoping only common features
38Decision Framework
- Expanding scope
- Feature selection existing, but evolving,
components - Architecture harmonisation iterative product
architecture harmonisation - Organization virtual component team
- Funding taxation
- Shared component scoping complete components
with plug-in capability
39Decision Framework
- Increasing maturity
- Feature selection all components
- Architecture harmonisation revolutionary
architecture adoption - Organization component unit
- Funding licensing/royalty
- Shared component scoping encompassing component
40Summary
41Overview
- introduction
- trends in software engineering
- software product families
- adoption
- maturity model
- software architecture
- explicit design decisions
- conclusions
42SPF 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
2002andFrank 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.
43Aspect - 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
- Reactive
- Awareness
- Extrapolate
- Proactive
- Strategic
44Aspect - ArchitectureArchitectural Maturity
Levels
45Architectural Maturity Levels
software product family
product populations
program of software product families
configurable product
increase product size (hierarchical SPFs)
increase PF scope
decrease derivation cost
Nokia telecom switches
Philips consumerelectronics
Telelarm
46Independent 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 - Domain emerging
- Software variability management absent
- Example most SMEs and several large companies
47Standardized Infrastructure
- description
- operating system
- database
- GUI
- etc.
- some additional proprietary glue code might be
present
D
P
48Standardized 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
phases of maturing domain - Software variability management limited
variation points from the infrastructure
components - Example Vertis Information Technology
49Platform
- description
- functionality common to all products in the
product family is captured - infrastructure is typically also included
D
P
50Platform
- 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 - Domain mature
- Software variability management managed at
platform level - Example Symbian OS
51Software Product Family
- description domain assets capture functionality
common to several or most products
component set
product familyarchitecture
external
internal
...
product 1
product 2
product n
D
P
52Software 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 - Software variability management many variation
points and dependencies between them - Example Axis Communications AB
53Configurable Product (Base)
marketing
development
customer
req.
SW
product
post fielding upgrades
license key driven conf.
3rd part software
D
A
54Configurable 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
- Software variability management automated
selection and verification of variants at
variation points has been optimized - Example TeleLarm AB
55Two Dimensions of Maturity
domain maturity(stability)
PL
CPB
high
medium
example
IP/SI
SI/PL
low
organizationalmaturity
low
medium
high
56Variation Binding Times
CPB
SPL
PL
SI
comp
RE
AD
CD
impl.
link
inst.
start
run
57Process Maturity
- We follow CMMI (staged representation)
- Aspects
- Predictability How predictable is software
development at each level. - Repeatability How repeatable is the development
process at each level. - Quantifiability How quantifiable is software
development.
58CMMI Levels
- Level 1 Initial
- Level 2 Managed
- Level 3 Defined
- Level 4 Quantitatively Managed
- Level 5 Optimizing
59Organizational Maturity
- Aspects
- Geographic distribution
- Culture
- Roles Responsibilities
- Product life cycle
- Levels
- Unit oriented
- Business lines oriented
- Business group/division
- Inter-division/companies
- Open business
60Organizational Models
- development department
- business units
- unconstrained model
- asset responsibles
- mixed responsibility
- domain engineering units
- single domain engineering unit
- one software architecture unit component units
- hierarchical domain engineering units
61Hierarchical Product Families
product populations
62Overview
- introduction
- trends in software engineering
- software product families
- adoption
- maturity model
- software architecture
- explicit design decisions
- conclusions
63Architecture-centric SE
- software engineering community has evolved
through - project-centric SE
- product-centric SE
- architecture-centric SE
- software architecture is core to modern software
development and evolution
64Software Architecture
- 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 - quality requirements
- Quality requirements can be categorised into
development QRs, e.g. maintainability, and
operational QRs, e.g. performance and reliability
65Why software architecture?
- first class representation of SA during
- design
- stakeholder-based assessment
- assessment of quality attributes
- implementation
- configuration management
- software product lines
- run-time
- dynamic software architectures, post-fielding
upgrades, dynamic reorganization, etc.
66Architectuur 3 dimensions
viewpoint
conceptual
process
development
aspect
run-time
business
technology(software)
organisation
infrastructure
representation
design
assessment
evolution
technology
67Software Architecture Use
- Three types of SA use
- single system
- software product families
- standardized domain architecture
- component framework szyperski 98
68Community 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 - inflexible architecture is good/fact of life!
69Flexible Architectures?
- why is SW architecture hard to change?
- ignored aspect of the problem
- loss of design knowledge vaporizes during
- architecture design
- component development
- system evolution
- ? architecture design decisions are lost
70Consequences
- lack of first-class representation
- design decisions cross-cutting and intertwined
- high cost of change
- design rules and constraints violated
- obsolete design decisions not removed
71Architecture Design Decisions
- architecture design decisions consists of
- restructuring effect
- design rules
- design constraints
- rationale - new principles, guidelines, etc.
- and are taken in response to
- functional requirements
- quality requirements
72Example Fire Alarm System
1. restructuring
2. design ruleoperation tick()
3. design rule register at scheduler on creation
4. design constrainttick() exec. time lt X ms
5. rationale least resource consumingmechanism
to achieve concurrency
73Architecture Design Decisions
- software architecture domain
modelADD1ADDn
74Architecture Notation Problems
- no SOC at the architectural level
- withdrawing DDs is hard
- imposing new DDs is hard
DD4
DD8
DD2
75How to model ADDs?
- traditional composition techniques lack
expressiveness - some initial, partial ideas
- implementation architectural fragments
- design ASICO
76Architectural Fragments
77Example Observer Pattern
- observer
- interface
- update(Object)
- end
- initial
- begin
- subject.addDependent(observer)
- end
- end // Observer
- architecture Observer
- roles
- subject
- variables
- dependents Collection
- methods
- addDependent(newDependent Object)
- begin ... end
- removeDependent(aDependent Object)
- begin ... end
- observedMethod()
- begin
- for each d in dependents do
d.update(self) - proceed
- end
- end
-
LayOM Layered Object Model
78Example Measurement System
- item-factory
- layers
- prototype-item PartOf(measurement-item)
- methods
- trigger
- begin
- measurement-item mi
- mi prototypeItem.copy
- if (inCalibration) then
mi.calibrate end - mi.start
- end
- calibrate(measurement-item mi)
- begin prototype-item.become(mi) end
- end
- measurement-item
- acquaintances
- sensor
- actuator
- interface
- architecture MeasurementSystemArchitecture
- roles
- sensor
- interface
- read
- end
- actuator
- interface
- activate
- end
- trigger
- acquaintances
- item-factory
- methods
- trigger
- begin item-factory.trigger proceed
end - end
79Example Measurement System
- application MeasurementSystem-example begin
- architectures
- aMS MeasurementSystemArchitecture where
- c is-a sensor with layers
- a Adapter(accept value as getFrame)
- end
- tr is-a trigger
- l is-a actuator
- bci is-a measurement-item with layers
- sensor Acquaintance(c)
- actuator Acquaintance(l)
- end
- end
- o1 Observer where
- tr is-a subject with layers
- a Adapter(accept trigger as
observedMethod) - end
- ui is-a observer,
- end
- o2 Observer where
- c is-a subject with layers
- a Adapter(accept getFrame as
observedMethod) - end
- ui is-a observer
- end
- components
- c Camera
- tr LightContactTrigger
- l Lever
- bci BeerCanItem
- ui UserInterface
- end // MeasurementSystem-example
fragment 3
fragment 1
domain comps.
fragment 2
80Example Measurement System
81Conclusion
- introduction
- trends in software engineering
- software product families
- adoption
- maturity model
- software architecture
- explicit design decisions
- conclusions
82Frågor???
Questions???