Software engineering Research Challenges in Software Architecture and Software Product Families...

soft

ware

en

gin

eeri

ng

Research Challenges in Software Architecture and Software Product Families

University of Antwerp, March 2004

Jan BoschProfessor of Software Engineering

University of Groningen, [email protected]

http://www.cs.rug.nl/~bosch

Research Challenges in SA and SPFs 2soft

ware

en

gin

eeri

ng

Overview

• introduction• trends in software engineering• software product families

– adoption– maturity model

• software architecture– explicit design decisions

• conclusions


ware

en

gin

eeri

ng

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 BakalisPh.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)


ware

en

gin

eeri

ng

Current Research Topics

variabilitymanagementEU project CONIPF

design erosion

usabilityEU project STATUS

softwarearchitecture

softwareproductfamilies

evaluation/maturitymodels

feature-basedarchitectural centricsystem construction

modifiabilityassessment

modeling designdecisions explicitly

explicit architectureinformation

architecture assessment

software variabilitymanagement


ware

en

gin

eeri

ng

Industrial Partners

• 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

• Philips Research, Medical,Consumer Electronics and PDSL

• Baan• Thales Naval

Netherlands• Robert Bosch GmbH• Information Highway

Group• LogicDIS• ICT Embedded

currently ongoing cooperation


ware

en

gin

eeri

ng

Agrarian age

Industrial age

Information age

Bioterial age

1760

360 years

50 years

20 years

Time

Eco

nom

ic v

alu

e a

dded

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

6000 BC

Where are we going?How fast?


ware

en

gin

eeri

ng

Innovation Adoption*maturity = 50 million users in the US

radio

38 years

phone

25 years

cable

10 years

internet

5 years

tech

nolo

gy

ma

turi

ty*

yea

rs

technologies

TV

13 years


ware

en

gin

eeri

ng

Innovation: Tactics

• follower: watch trends and react accordingly (reactive)

• shaper: create the technology underlying new trends (proactive)


ware

en

gin

eeri

ng

Trend: software size

software needs in products constantly increasing

1990 1995 2000 2005

10

100

1000

pers

on y

ears

per

pro

duct

1000

10000

typi

cal n

umbe

r of e

rrors

per p

rodu

ct

Philips


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Examples

• car engine controllers• steer by wire• telecom switches• Transmeta’s Crusoe chip


ware

en

gin

eeri

ng

Mobile Phones

GSM 900

GSM 900/1800

GSM 900/1900

GSM 900/1800/1900

GSM 1900


ware

en

gin

eeri

ng

BPM @ Intershop


ware

en

gin

eeri

ng

Software Product Families

product-familyarchitecture

component set

product 1 product 2 product n

external

internal

...


ware

en

gin

eeri

ng

Trend: Variability

mechanical parts

electronic parts (HW)

software parts (SW)

variability(flexibility of SW)

standardization(economies of scale)


ware

en

gin

eeri

ng

Trend: Variability

marketing development customer

req.

SW

product

post fielding upgradeslicense key driven conf.3rd part software


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Trend: Later Binding

trend is towards later binding and increased automation

requirementsengineering

architecturedesign

detaileddesign

implementationproducer-siteconfiguration

installation-siteconfiguration

start-up run-time

architecturalconfiguration

T C F

testing T C F

T C Ftraditional current future

feature selection &ciomposition

T C F

legend

multi-dimensionalcomposition of concerns

(e.g. AOP)T C F


ware

en

gin

eeri

ng

Software Challenge

increasing SW sizeper product

develop fewer products

increasing variabilityrequirements

develop more products

Software Product Families


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Overview




• conclusions


ware

en

gin

eeri

ng

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

R&D organization– component value not linear


ware

en

gin

eeri

ng

Component value not linear

100%product-specific

requirements covered

component value

100%

actualrelation

reduced value dueto inefficiencies

assumed relation


ware

en

gin

eeri

ng

Decision Dimensionsfeature

selection

new commonfeatures

existing, evolvingcomponents

old, genericcomponents

architectureharmonisation

componentcentric

iterativeharmonisation

revolutionaryadoption

organization

mixedresponsibility

virtualteam

componentunit

funding

"barter"

taxation

licensing/royalty

sharedcomponent

scoping

onlycommonfeaturescomponent

with plug-in

encompassingcomponent


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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

– good understanding of product needs, no organizational changes

– loyalty conflicts


ware

en

gin

eeri

ng

R&D Organization

• Component unit– clear responsibilities, clear

interfaces for decision making– “local optimization”, perfectionism


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Funding

• Licensing/royalty– market pressures, COTS

replacement easily identified– component needs to be mature, if

core competence, still no market pressure


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng


• Encompassing component– efficient development in case of

complex QAs– larger component team


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Decision Framework

• Increasing “maturity”– Feature selection: all components– Architecture harmonisation:

revolutionary architecture adoption– Organization: component unit– Funding: licensing/royalty– Shared component scoping:

encompassing component


ware

en

gin

eeri

ng

SummaryEarly successes Increasing scope Increasing

maturity

Feature selection New, but common features

Existing, but evolving, components

All components

Architecture harmonisation

Component-centric

Iterative product architecture harmonisation

Revolutionary architecture adoption

R&D organization Mixed responsibility for product teams

Virtual component teams

Component units

Funding “Barter” Taxation Licensing


Only common features

Complete components with plug-ins

Encompassing component


ware

en

gin

eeri

ng

Overview




• conclusions


ware

en

gin

eeri

ng

SPF Assessment Framework

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.

FOCUS


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Aspect - ArchitectureArchitectural “Maturity” Levels

standardizedinfrastructure

platform

softwareproduct

line

configurableproduct base

productpopulation

program ofproduct lines

independentproducts


ware

en

gin

eeri

ng product populationsprogram of

software product families

Architectural “Maturity” Levels

software product family

configurableproduct

increase product size(hierarchical SPFs)

increase PF scope decrease derivationcost

Nokia telecom switches Philips consumerelectronics

Telelarm


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Standardized Infrastructure

• description– operating system– database– GUI– etc.

some additional proprietary glue code might be present

P D


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Platform

• description: – functionality common to all

products in the product family is captured

– infrastructure is typically also included

P D


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Software Product Family

• description: domain assets capture functionality common to several or most products

P D

product familyarchitecture

component set

product 1 product 2 product n

external

internal

...


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Configurable Product (Base)

A D

marketing development customer

req.

SW

productpost fielding upgradeslicense key driven conf.3rd part software


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Two Dimensions of “Maturity”

organizationalmaturity

domain maturity(stability)

low

medium

high

low medium high

CPBPL

SI/PLIP/SI

example


ware

en

gin

eeri

ng

Variation Binding Times

RE AD CD impl. comp link inst. start run

SI

PL

SPL

CPB


ware

en

gin

eeri

ng

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.


ware

en

gin

eeri

ng

CMMI Levels

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


ware

en

gin

eeri

ng

Organizational Maturity

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Hierarchical Product Families

organization

scope 1

scope 1.2scope 1.1

CPX CPY CPZ

PB

production-siteconfiguration

installation-timeconfiguration

RT P RT P

run-timeconfiguration

PC PPA P

sharedartefacts

sharedartefacts

sharedartefacts

infrastructurecomponent



scope 1.1.1

pro

duct p

opula

tions


ware

en

gin

eeri

ng

Overview




• conclusions


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Software Architecture

• software architectureArchitecture 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 requirementsQuality requirements can be categorised into development QRs, e.g. maintainability, and operational QRs, e.g. performance and reliability


ware

en

gin

eeri

ng

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.


ware

en

gin

eeri

ng

Architectuur – 3 dimensions

business technology(software)

organisation

aspect

viewpoint

run-time

development

process

conceptual

infrastructurerepresentation

design

assessment

evolution

technology


ware

en

gin

eeri

ng

Software Architecture Use

Three types of SA use:• single system• software product families• standardized domain architecture

component framework [szyperski 98]


ware

en

gin

eeri

ng

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!


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

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


ware

en

gin

eeri

ng

Example – Fire Alarm System

Input

Input

Input

Input

Input

Input

Deviation

DeviationOuput

Ouput

Ouput

Scheduler 1. restructuring2. design rule:operation tick()

4. design constraint:tick() exec. time < X ms

5. rationale: least resource consumingmechanism to achieve concurrency

3. design rule: registerat scheduler on creation


ware

en

gin

eeri

ng

Architecture Design Decisions

software architecture=

domain model+

ADD1+…+

ADDn


ware

en

gin

eeri

ng

Architecture Notation Problems

• no SOC at the architectural level• withdrawing DD’s is hard• imposing new DD’s is hard

DD1DD2DD3DD4DD5DD6DD7

DD1DD2DD3DD5DD6DD7

DD8DD4

DD2


ware

en

gin

eeri

ng

How to model ADDs?

• traditional composition techniques lack expressiveness

• some initial, partial ideas– implementation: architectural fragments– design: ASICO

inheritance

aggregation

superimpositionaspect weavingSOPetc.


ware

en

gin

eeri

ng

Architectural Fragments


ware

en

gin

eeri

ng

Example: Observer Pattern

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;

observer interface update(Object); end; initial begin subject.addDependent(observer); end;end; // Observer

LayOM – Layered Object Model


ware

en

gin

eeri

ng

Example: Measurement System

architecture MeasurementSystemArchitecture roles sensor interface read end; actuator interface activate end; trigger acquaintances item-factory; methods trigger begin item-factory.trigger; proceed;

end; end;

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 start; end;end; // MeasurementSystemArchitecture


ware

en

gin

eeri

ng


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

frag

men

t 1fr

agm

ent 2

frag

men

t 3do

mai

n co

mps

.


ware

en

gin

eeri

ng



ware

en

gin

eeri

ng

Conclusion




• conclusions


ware

en

gin

eeri

ng

Software engineering Research Challenges in Software Architecture and Software Product Families...

Documents

Transcript of Software engineering Research Challenges in Software Architecture and Software Product Families...