Research Challenges in Software Architecture and Software Product Families - PowerPoint PPT Presentation

Loading...

PPT – Research Challenges in Software Architecture and Software Product Families PowerPoint presentation | free to download - id: 92b10-NmQ2M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Research Challenges in Software Architecture and Software Product Families

Description:

software engineering. Research Challenges in Software Architecture and ... or managed in an ad-hoc fashion ... Domain: emerging. Software ... – PowerPoint PPT presentation

Number of Views:206
Avg rating:3.0/5.0
Slides: 83
Provided by: bos41
Learn more at: http://lore.ua.ac.be
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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???
About PowerShow.com