ProductLine Architectures - PowerPoint PPT Presentation

Loading...

PPT – ProductLine Architectures PowerPoint presentation | free to view - id: 920c7-NWFmM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

ProductLine Architectures

Description:

1. Product-Line Architectures. Don Batory. Department of Computer Sciences ... complex models (spheres inside spheres) ultimately failed to predict planetary ... – PowerPoint PPT presentation

Number of Views:33
Avg rating:3.0/5.0
Slides: 58
Provided by: donba1
Category:

less

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

Title: 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
    2 Feature Implementation concurrency (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 w R 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
About PowerShow.com