1

Product-Line Architectures

Don BatoryDepartment of Computer SciencesUniversity of Texas at Austin

2

IntroductionIn 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 today’s 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

class foo { int a; int b; …}

class bar { …}

...

Classes!

Today we elegantly express software as hierarchies of classes and webs of interconnected objects

Global varsand functions

int global;

int func( ) { ... }

void main( ) { global = func( ); …}

...

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

product-line architectures PLAsdesigns expressed in components

codeless programming(software plug-and-play)

Tomorrow

---------------refinements

8

Product Line Architecturesblue-print for creating families of related

applications

acknowledges companies don’t 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 I’ve 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

Doesn’t mean that components can’t exist for these domains

• rather, components must be implemented differently

• ex: metaprograms, rule sets of program transformation systems

11

Generalization...Today’s 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

conceptualbuilding-blocks

of PLAs

14

Towards Software Plug-and-Play...Programming with today’s

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

• don’t 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

Application#4 =

17

Motivations ...Need for:

Product-Line Architectures Refinements Software Plug-and-Play

are clear...

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 PLAsdefine 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

Booch Components 400+ data structure templates 18 varieties of dequeues = 3 x 3 x 2

Feature Implementation

concurrency (sequential, guarded, synchronized)

memory allocation (bounded, unbounded, dynamic)

ordering (unordered, ordered)

(and how not to implement PLAs)

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 ®

(1+m)n applications

Libraries of PLAs shouldn’t contain components that implement combinations of features

23

How to Implement PLAsLibraries should contain components

that implement individual, largely orthogonal features

component libraries are small O(n*m)

exponential numbers O((1+m)n) applications constructed from component compositions

ex: Singhal’s Components

24

Singhal Components Reengineered Booch Components V1.47

Singhal Components• 1/4 size, larger product line• more efficient• easy to extend

Booch Singhal# of Components 82 22Lines of Code 11,067 2,760Domain Cardinality 169 208

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

Database Systems ProtocolsCompilers Radio SoftwareAvionics Audio Signal Processing

+ others

27

GenVocaSimple, 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

GenVocaDomain of applications = Product

Line

has fundamental abstractions

define “standardized” interfaces (virtual machines) to abstractions

• may have multiple, interrelated classes• “virtual” because clients of interface don’t know

how interface is implemented

29

RealmsSet 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[ x:S ], h[ x:S ], i[ x:S ] }

30

ParametersConsider g[x:S] : R

parameters define imported interfaces

g defines a refinement of R into S• refinement doesn’t depend on specific

implementation of S

interface R

interface Sg

31

Type EquationsApplication is a named composition

of components called a type equationS = { y, z, w }R = { g[ x:S ], h[ x:S ], i[ x:S ] }

A1 = g[ y ];A2 = g[ w ];A3 = h[ w ];

32

Grammars and Product LinesRealms define grammars whose sentences

are applications

Set of all sentences = product line

S = { y, z, w }R = { g[ x:S ], h[ x:S ], i[ x:S ] }

S := y | z | wR := g S | h S | i S

33

Recursion and Symmetry Symmetric components

export & import same interfacecomposable in virtually arbitrary ordersof realm W have parameters of type W

ex: m[n[p]], n[m[p]], m[m[p]] ...

W = { m[ x:W ], n[ x:W ], 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 RulesAlthough equations may be type

correct, there are always combinations of components that don’t make sense

semantic correctness of compositions

domain-specific constraints called design rules that preclude illegal component compositions

36

Product-Line (Domain) ModelIs an attribute grammar

realms of components define grammardesign rules are semantic constraints per rule

Generatorconfiguration-tool or compiler that implements

PL model

Type equation ApplicationGenerator

37

Model Says Nothing About...When to compose refinements?

dynamic (run-time)static (compile-time)

How to implement refinements?Mixins, OO packages, COM, Corba, …metaprogramsprogram transformation systems

38

Examples...

PLAs

OO…

MetaProgramming

Transformation Syst

Static

databasesavionicscompilers

data structures

protocols

Dynamic

protocols

audio signalprocessing

??

radio software

39

What does this mean?

class foo { int a; int b; …}

class bar { …}

...

Classes!

Conceptualize software designs in layered/component-based refinements

Refinements!

TypeEquation

A1 = A[ B[ C ] ];

...

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

can’t 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... 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 won’t use it until they use it”

Terminology Arms Race• ex#1: “software architecture”• ex#2: Rational Software

44

Non-Technical Problems... Not ready for prime time

“That’s not possible!”

“My software is too complicated to be built that way!”

45

Technical ProblemsOpen problem: testing

can synthesize applications quicklystill have to test applicationsnot clear how to reduce tests to reduce

product release time

Incompatible World ViewsBoston Gas Station Storyex: 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

class

subclass

subclassing relationship

47

Large Scale Refinement Adds new data members and methods

simultaneously to several classes

class class class

subclass subclass subclass

48

Relationship to GenVoca GenVoca components are consistent

refinements of multiple classes

application classes

49

Scalability

application classes

Jak = blue[ black[ orange[ yellow ]]];

corresponds to over 500 classes, 26K lines of code

50

Technical ProblemsCan 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 macrosparameterized inheritanceP3 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 didn’t 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 RemarksHow 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 RemarksThis presentation motivated

directions for future software development

product-line architecturesrefinements as generalizations of

componentscodeless programming of software plug-

and-play

GenVoca is one approach that has achieved all 3...

55

Concluding RemarksWhen & how will “GenVoca” ideas take

hold?ideas constantly reinvented

– plug-compatible components isn’t rocket science;– refinements aren’t 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

57

Timing 4:40 up to PLA 12:20 past how to achieve *14

min 20:20 up to GenVoca (20 min)

*22.5 min 29:30 up to interesting (10 min gen) 34:00 up to problems (17 finish)

*34 min

total: 47 min