1 / 57

Product-Line Architectures

Product-Line Architectures. Don Batory Department of Computer Sciences University of Texas at Austin. 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

keiran
Download Presentation

Product-Line Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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. Today we elegantly express software as hierarchies of classes and webs of interconnected objects Design int global; int func( ) { ... } void main( ) { global = func( ); … } ... class foo { int a; int b; … } class bar { … } ... Global vars and functions Classes! 1970s 1990s 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. Tomorrow product-line architecturesPLAs designs expressed in components codeless programming(software plug-and-play) 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 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 conceptual building-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. Application#4 = 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. extensible systems, open systems domain-specific software architectures aspect-oriented programming subject-oriented programming feature-oriented programming generative programming Many Relevant Results... 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 (sequential, 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 applicationsn features with m implementations ® (1+m)napplications Libraries of PLAs shouldn’t 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(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

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

  30. interface R g interface S Parameters • Consider 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

  31. Type Equations • Application is a named composition of components called a type equation S = { y, z, w }R = { g[ x:S ], h[ x:S ], i[ x:S ] } 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[ 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 interface • composable in virtually arbitrary orders • of 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 Rules • Although 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. Type equation Generator Application 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. PLAs OO… MetaProgramming Transformation Syst Static databases avionics compilers data structures protocols Dynamic protocols audio signal processing ?? radio software Examples...

  39. Conceptualize software designs in layered/component-based refinements Design class foo { int a; int b; … } class bar { … } ... Refinements! Classes! TypeEquation A1 = A[ B[ C ] ]; ... 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 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... 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 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 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. class subclassing relationship subclass OO Realizations of Refinements • A small-scale refinement adds new data members, methods, and/or overrides existing methods to a class

  47. class class class subclass subclass subclass Large Scale Refinement • Adds new data members and methods simultaneously to several classes

  48. application classes Relationship to GenVoca • GenVoca components are consistent refinements of multiple classes

  49. application classes 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

More Related