ProductLine Architectures

1
Product-Line Architectures

• Don Batory
• Department of Computer Sciences
• University of Texas at Austin

2
Introduction

• In 1500s, accepted truth that the Earth was the
  center of the Universe
• Geocentricity was obvious and largely accurate
• lunar eclipses
• positions of fixed stars
• but planetary motion caused problems...

3
Retrograde Motions...

• complex models (spheres inside spheres)
  ultimately failed to predict planetary positions
  accurately

4
A Revolution

• In 1543, Copernicus proposed a radically
  different explanation of our universe
• heliocentricity elegantly explains retrogrades,
  forms basis of todays understanding of
  planetary systems
• (Extreme) example of how science evolves
• negating commonly held truths yields models of
  the universe that not only are consistent with
  known facts, but are more powerful and lead to
  deeper understandings
• more common examples lead to incremental advances

5
Universe of Software
6
Looking Ahead...

• What software design and construction
  technologies lie in the future?
• How will we understand software?
• What will be our unit of encapsulation?
• How will we produce specify software?
• try negating obvious truths and see if a
  consistent explanation of software remains

7
Some Changeable Truths
Today
one-of-a-kind applications design expressed in
objects and classes code our implementations
---------------refinements
8
Product Line Architectures

• blue-print for creating families of related
  applications
• acknowledges companies dont build individual
  products, but rather product families
• importance amortize costs of software design and
  development over multiple products
• most innovative work on software design next 10
  years
• motivation not new McIlroy 69, Parnas
  families 76
• now! Jacobsson and Griss variation points

9
From Components to Refinements

• Newest OO methodologies not based purely on
  objects/classes but on components
• components are encapsulated suites of classes
  scaling unit of design to packages/frameworks
• ex Catalysis, Rational advocating
  component-based software designs
• OO, COM, Corba, Java Beans...

10
Perspective

• Ive been working on component-based PLA design
  methodologies for 15 years
• encountered domains where components cannot be
  implemented as OO packages, COM, Corba,
• because performance would be horrendous
• Doesnt mean that components cant exist for
  these domains
• rather, components must be implemented
  differently
• ex metaprograms, rule sets of program
  transformation systems

11
Generalization...

• Todays notion of components is too
  implementation oriented or implementation-specific
  
• Key idea separate component abstraction from its
  implementation
• OO, COM, , metaprograms, program transformation
  systems are implementation technologies
• Abstraction that unifies the spectrum of
  component implementations is

Refinement
12
What are Refinements?

• Changes to an application (when adding a feature)
  are not localized
• Refinements are central to a general theory of
  Product-Line Architectures
• abstracts away component implementation details
  yielding common set of abstractions for all
  domains/PLAs

application
13
Benefit of Refinements...

• Significant conceptual economy
• one way in which to conceptualize PLAs
• many ways in which refinements can be implemented
• choice is often domain-specific

conceptual building-blocks of PLAs
14
Towards Software Plug-and-Play...

• Programming with todays components is analogous
  to (old-fashioned) wire-wrapping hardware chips
• traditional library paradigm
• very successful, largely manual process

15
Plug-and-Play

• Software construction allows for much greater
  degrees of automation
• want intelligent components to know how to
  wire-wrap themselves
• dont manually specify myriad connections
• Hardware Plug-and-Play
• standardized (hardware) interfaces
• novices can do tasks of high-paid experts

16
Software Plug-and-Play

• Do the same for software
• standardized (software) interfaces
• applications of PLA are specified/assembled as
  compositions of components
• enable average programmers the ability to code
  like experts

Codeless Programming!
17
Motivations ...

• Need for
• Product-Line Architectures
• Refinements
• Software Plug-and-Play
• are clear...

How to achieve?
18
Many Relevant Results...

• extensible systems, open systems
• domain-specific software architectures
• aspect-oriented programming

• subject-oriented programming
• feature-oriented programming
• generative programming

Note approaches are NOT identical, essential
problems they solve are similar
19
Common to Models of PLAs

• define set of features that arise in a family of
  applications
• each feature has 1 implementations
• an application specified by its set of features
  w. implementations

20
Classic Example of PLA
(and how not to implement PLAs)

• Booch Components
• 400 data structure templates
• 18 varieties of dequeues 3 x 3 x
  2Feature Implementationconcurrency (sequent
  ial, guarded, synchronized)memory
  allocation (bounded, unbounded,
  dynamic)ordering (unordered, ordered)

21
Oops... Problems...

• What happens when new feature added?
• ex persistence
• No conventional library could encompass enormous
  spectrum of data structures (or PLAs) that are
  encountered in practice

Library doubles in size!
22
Library Scalability Problem
n features product line of 2n applications
n features with m implementations
(1m)n applications
Libraries of PLAs shouldnt contain components
that implement combinations of features
23
How to Implement PLAs

• Libraries should contain components that
  implement individual, largely orthogonal
  features
• component libraries are small O(nm)
• exponential numbers O((1m)n) applications
  constructed from component compositions
• ex Singhals Components

24
Singhal Components

• Reengineered Booch Components V1.47
• Singhal Components
• 1/4 size, larger product line
• more efficient
• easy to extend

25
P3 Generator

• Generator of Java Container structures
• 9 primitive data structures that can be composed
  
• ex can generate a data structure where
• elements stored in ascending order on field A,
  and
• hash-accessable on field B, and
• key-accessable via red-black tree on field C
• P3 equivalent to product-line or library of tens
  of thousands of containers
• generated software typically has faster execution
  times
• optimize where static libraries cannot

26
What About Other Domains?

• Lots of success stories
• mostly independent
• common set of ideas that are being reinvented
• spend a few minutes explaining them...

others
27
GenVoca

• Simple, powerful, and abstract model of PLAs
• name derived from first PLAs based on this
  approach Genesis and Avoca
• Takes idea of components that export and import
  standardized interfaces to its logical
  conclusion

28
GenVoca

• Domain of applications Product Line
• has fundamental abstractions
• define standardized interfaces (virtual
  machines) to abstractions
• may have multiple, interrelated classes
• virtual because clients of interface dont know
  how interface is implemented

29
Realms

• Set of components that implement the same virtual
  machine is realm
• is library of plug-compatible, interchangeable
  components
• lots of parameters - look only at realm parameters

S y, z, w R g xS , h xS , i
xS
30
Parameters

• Consider gxS R
• parameters define imported interfaces
• g defines a refinement of R into S
• refinement doesnt depend on specific
  implementation of S

31
Type Equations

• Application is a named composition of components
  called a type equation

S y, z, w R g xS , h xS , i xS

Software Plug-and-Play
A1 g y A2 g w A3 h w
32
Grammars and Product Lines

• Realms define grammars whose sentences are
  applications
• Set of all sentences product line

S y, z, w R g xS , h xS , i xS

S y z wR g S h S i
S
33
Recursion and Symmetry

• Symmetric components
• export import same interface
• composable in virtually arbitrary orders
• of realm W have parameters of type W
• ex mnp, nmp, mmp ...

W m xW , n xW , p W m W n W
p
34
Why is Symmetry Important?

• Applications can have open-ended sets of features
• symmetric components are the way additional
  features are added to an application
• not changing fundamental abstractions, only
  enriching them

35
Design Rules

• Although equations may be type correct, there are
  always combinations of components that dont make
  sense
• semantic correctness of compositions
• domain-specific constraints called design rules
  that preclude illegal component compositions

36
Product-Line (Domain) Model

• Is an attribute grammar
• realms of components define grammar
• design rules are semantic constraints per rule
• Generator
• configuration-tool or compiler that implements PL
  model

37
Model Says Nothing About...

• When to compose refinements?
• dynamic (run-time)
• static (compile-time)
• How to implement refinements?
• Mixins, OO packages, COM, Corba,
• metaprograms
• program transformation systems

38
Examples...
39
What does this mean?
Designers who wanted to create product-line
architectures by assembling customized
applications via plug-and-play...
40
What is Gained?

• PLAs of complexity and diversity that cant be
  built in any other way
• handful of applications tens of thousands of
  apps
• performance of synthesized applications
  comparable to (usually better than) expert-coded
  software
• improved productivity x 4 or more
• 8-fold reduction in errors reported
• Possible to build tools that automatically
  optimize equations (software designs)
• so novices can design and code like experts

41
But....

• Problems and limitations with every approach
• lots of technical problems, no show stoppers
• hardest problems are non-technical
• typical of technology transfer

42
Non-Technical Problems

• Legacy code
• companies have legacy code that they want to
  reuse in product-line applications
• willing to accept penalty of hacking source code
• reasonable for domains with little variation
• Corporate politics
• demonstrating PLA capabilities necessary but not
  sufficient
• egos, pre-existing methods, insecure funding
  can obscure technical goals
• adoption decisions made for non-technical
  reasons results are often confused for
  technical reasons

43
Non-Technical Problems...
Beyond Rational

• Think in terms of layered refinements and/or
  standardized interfaces
• greatest strength may be greatest weakness
• architects may not be open to new approaches
• Catch 22
• we wont use it until they use it
• Terminology Arms Race
• ex1 software architecture
• ex2 Rational Software

44
Non-Technical Problems...

• Not ready for prime time
• Thats not possible!
• My software is too complicated to be built
  that way!

45
Technical Problems

• Open problem testing
• can synthesize applications quickly
• still have to test applications
• not clear how to reduce tests to reduce product
  release time
• Incompatible World Views
• Boston Gas Station Story
• ex how to express refinements in OO?

46
OO Realizations of Refinements

• A small-scale refinement adds new data members,
  methods, and/or overrides existing methods to a
  class

47
Large Scale Refinement

• Adds new data members and methods simultaneously
  to several classes

48
Relationship to GenVoca

• GenVoca components are consistent refinements of
  multiple classes

49
Scalability
Jak blue black orange yellow
corresponds to over 500 classes, 26K lines
of code
50
Technical Problems

• Can express these ideas as mixins
• I.e. a class whose superclass is specified by a
  parameter
• Want clean implementation in Java
• neither Java nor Pizza supports parameterized
  inheritance
• need extensible Java (to add features to
  implement refinements)
• Jakarta Tool Suite (JTS)
• PLA for Java dialects
• GenVoca generator by which domain-specific
  dialects of Java are assembled from components

51
JTS

• (optional) features added to Java
• Lisp backquote/comma (to specify and manipulate
  code fragments)
• hygienic macros
• parameterized inheritance
• P3 generator of container data structures
• bootstrapped!
• Free!
• Visit web site in paper...

52
Concluding Remarks

• Heliocentricity was advanced in 1543, yet 60
  years later it made no impact
• people didnt care about retrograde motions
• Jean Bodin No one in his senses or imbued with
  the slightest knowledge of physics will ever
  think that the earth staggers up and down around
  its own center and that of the sun For if the
  earth were to be moved, we would see cities,
  fortresses, mountains thrown down Arrows shot
  straight up or stones dropped from towers would
  not fall perpendicularly, but either ahead or
  behind

53
Concluding Remarks

• How did heliocentricity take hold?
• telescope invented in early 1600s
• consistent with telescopic observations
• provided simple explanation consistent with other
  disparate results
• ex earth tides
• able to solve problems that were difficult or
  impossible otherwise

54
Concluding Remarks

• This presentation motivated directions for future
  software development
• product-line architectures
• refinements as generalizations of components
• codeless programming of software plug-and-play
• GenVoca is one approach that has achieved all 3...

55
Concluding Remarks

• When how will GenVoca ideas take hold?
• ideas constantly reinvented
• plug-compatible components isnt rocket science
• refinements arent new
• lots of experimental evidence of power
  capabilities
• much more in the future
• reducing software complexity
• standardizing abstractions of a domain/PLA is a
  powerful way of managing and controlling the
  complexity of software in a family of applications

56
The End
57
Timing

• 440 up to PLA
• 1220 past how to achieve 14 min
• 2020 up to GenVoca (20 min) 22.5 min
• 2930 up to interesting (10 min gen)
• 3400 up to problems (17 finish) 34 min
• total 47 min