Research Challenges in Software Architecture and Software Product Families

1
Research 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
2
Overview

• introduction
• trends in software engineering
• software product families
• adoption
• maturity model
• software architecture
• explicit design decisions
• conclusions

3
Software 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)

4
Current 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
5
Industrial 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
6
Where 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
7
Innovation Adoption
maturity 50 million users in the US
technology maturityyears
technologies
8
Innovation Tactics

• follower watch trends and react accordingly
  (reactive)
• shaper create the technology underlying new
  trends (proactive)

9
Trend 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
10
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
• from stand-alone to signal exchange to
  behavioural integration

11
Trend 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

12
Examples

• car engine controllers
• steer by wire
• telecom switches
• Transmetas Crusoe chip

13
Mobile Phones
GSM 900
GSM 1900
GSM 900/1800
GSM 900/1900
GSM 900/1800/1900
14
BPM _at_ Intershop
15
Software Product Families
product-familyarchitecture
component set
external
internal
...
product 1
product 2
product n
16
Trend Variability
software parts (SW)
electronic parts (HW)
variability(flexibility of SW)
standardization(economies of scale)
mechanical parts
17
Trend Variability
marketing
development
customer
req.
SW
product
post fielding upgrades
license key driven conf.
3rd part software
18
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
• software variability is expressed through
  variation points and associated variants
• variation points delay design decisions

19
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
• open possible to add new variants to set
• closed set of variants is closed
• can be introduced and bound at any level

20
Trend Later Binding

• trend is towards later binding and increased
  automation

21
Software Challenge
increasing SW sizeper product
increasing variability requirements
develop fewer products
develop more products
22
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
• SVM in product derivation Sybren and Marco
• variability assessment Sybren
• case studies Jilles, Michel, Sybren and Marco

23
Overview

• introduction
• trends in software engineering
• software product families
• adoption
• maturity model
• software architecture
• explicit design decisions
• conclusions

24
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
• high degree of organizational noise
• inefficient knowledge management
• evolution causes ripple effects through the RD
  organization
• component value not linear

25
Component value not linear
26
Decision Dimensions
27
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
  understood
• little time for pay-back on product-specific
  components, cost of implementing superset of
  features

28
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

29
Architecture 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

30
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

31
RD 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

32
RD Organization

• Component unit
• clear responsibilities, clear interfaces for
  decision making
• local optimization, perfectionism

33
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
• more trustworthy and long term focus (roadmaps
  and release plans)
• changes become visible (budget organization),
  no competitive pressure for component team

34
Funding

• Licensing/royalty
• market pressures, COTS replacement easily
  identified
• component needs to be mature, if core competence,
  still no market pressure

35
Shared 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

36
Shared component scoping

• Encompassing component
• efficient development in case of complex QAs
• larger component team

37
Decision 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

38
Decision 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

39
Decision Framework

• Increasing maturity
• Feature selection all components
• Architecture harmonisation revolutionary
  architecture adoption
• Organization component unit
• Funding licensing/royalty
• Shared component scoping encompassing component

40
Summary
41
Overview

• introduction
• trends in software engineering
• software product families
• adoption
• maturity model
• software architecture
• explicit design decisions
• conclusions

42
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
  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.

43
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
• Reactive
• Awareness
• Extrapolate
• Proactive
• Strategic

44
Aspect - ArchitectureArchitectural Maturity
Levels
45
Architectural 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
46
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
• Domain emerging
• Software variability management absent
• Example most SMEs and several large companies

47
Standardized Infrastructure

• description
• operating system
• database
• GUI
• etc.
• some additional proprietary glue code might be
  present

D
P
48
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
  phases of maturing domain
• Software variability management limited
  variation points from the infrastructure
  components
• Example Vertis Information Technology

49
Platform

• description
• functionality common to all products in the
  product family is captured
• infrastructure is typically also included

D
P
50
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
• Domain mature
• Software variability management managed at
  platform level
• Example Symbian OS

51
Software 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
52
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
• Software variability management many variation
  points and dependencies between them
• Example Axis Communications AB

53
Configurable Product (Base)

marketing
development
customer
req.
SW
product
post fielding upgrades
license key driven conf.
3rd part software
D
A
54
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
• Software variability management automated
  selection and verification of variants at
  variation points has been optimized
• Example TeleLarm AB

55
Two Dimensions of Maturity
domain maturity(stability)
PL
CPB
high
medium
example
IP/SI
SI/PL
low
organizationalmaturity
low
medium
high
56
Variation Binding Times
CPB
SPL
PL
SI
comp
RE
AD
CD
impl.
link
inst.
start
run
57
Process 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.

58
CMMI Levels

• Level 1 Initial
• Level 2 Managed
• Level 3 Defined
• Level 4 Quantitatively Managed
• Level 5 Optimizing

59
Organizational Maturity

• Aspects
• Geographic distribution
• Culture
• Roles Responsibilities
• Product life cycle
• Levels
• Unit oriented
• Business lines oriented
• Business group/division
• Inter-division/companies
• Open business

60
Organizational 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

61
Hierarchical Product Families
product populations
62
Overview

• introduction
• trends in software engineering
• software product families
• adoption
• maturity model
• software architecture
• explicit design decisions
• conclusions

63
Architecture-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

64
Software 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

65
Why 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.

66
Architectuur 3 dimensions
viewpoint
conceptual
process
development
aspect
run-time
business
technology(software)
organisation
infrastructure
representation
design
assessment
evolution
technology
67
Software Architecture Use

• Three types of SA use
• single system
• software product families
• standardized domain architecture
• component framework szyperski 98

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

69
Flexible 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

70
Consequences

• 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

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

72
Example 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
73
Architecture Design Decisions

• software architecture domain
  modelADD1ADDn

74
Architecture Notation Problems

• no SOC at the architectural level
• withdrawing DDs is hard
• imposing new DDs is hard

DD4
DD8
DD2
75
How to model ADDs?

• traditional composition techniques lack
  expressiveness
• some initial, partial ideas
• implementation architectural fragments
• design ASICO

76
Architectural Fragments
77
Example 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
78
Example 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

79
Example 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
80
Example Measurement System
81
Conclusion

• introduction
• trends in software engineering
• software product families
• adoption
• maturity model
• software architecture
• explicit design decisions
• conclusions

82
Frågor???
Questions???