1 / 55

Generic Programming using Adaptive and Aspect-Oriented Programming

Generic Programming using Adaptive and Aspect-Oriented Programming. Karl Lieberherr, The Demeter Group College of Computer Science Northeastern University, Boston. Overview. Generic programming Aspect-oriented and Adaptive Programming Adaptive Plug-and-Play Components

yoko
Download Presentation

Generic Programming using Adaptive and Aspect-Oriented Programming

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. Generic Programming using Adaptive and Aspect-Oriented Programming Karl Lieberherr, The Demeter Group College of Computer Science Northeastern University, Boston Generic Programming/Dagstuhl

  2. Overview • Generic programming • Aspect-oriented and Adaptive Programming • Adaptive Plug-and-Play Components • Pricing Policies (from an IBM code generator) • Graph Algorithms (Cycle checking) • Demeter/Java • Conclusions Generic Programming/Dagstuhl

  3. What is Generic Programming? • Expressing algorithms with minimal assumptions about data abstractions, and vice versa, thus making them as interoperable as possible • Lifting of a concrete algorithm to as a general level as possible without losing efficiency Generic Programming/Dagstuhl

  4. What is Generic Programming? • Lifting of a concrete algorithm to as a general level as possible without losing efficiency i.e., the most abstract form such that when specialized back to the concrete case the result is just as efficient as the original algorithm. • From Dagstuhl 98 conference on generic programming Generic Programming/Dagstuhl

  5. What is Generic Programming? • Generic programming is about making programs more adaptable by making them more general • Embody non-traditional kinds of polymorphism • Parameters of a generic program are rich in structure (programs, types, graphs). • From Workshop on Gen. Prog. Sweden 98 Generic Programming/Dagstuhl

  6. How does Aspect-Oriented Programming help? • Tease out bigger chunks than classes • Tease out issues which cross-cut many classes • Describe different issues separately making minimal assumptions among them: Avoid tangling of issues • Express issues by aspect descriptions which are compiled into behavior by a weaver Generic Programming/Dagstuhl

  7. Many evolution problems come from tangled designs/programs • Code for a requirement is spread through many artifacts. In each artifact, code for different requirements is tangled together. • For example: • Information structure is tangled with behavior. We want structure-shyness (Lieberherr ‘92). • Synchronization code is tangled with sequential code. Generic Programming/Dagstuhl

  8. Eliminating drawbacks with Aspect-Oriented Programming (AOP) • Solution: Split software into cooperating, loosely coupled components and aspect-descriptions. • Untangles designs/programs and eliminates redundancy. • Aspect description examples: marshalling, synchronization, information structure etc. Generic Programming/Dagstuhl

  9. Cross-cutting of components and aspects better program easier to understand! ordinary program structure-shy functionality Components structure Aspect 1 synchronization Aspect 2 Generic Programming/Dagstuhl

  10. What is adaptive programming (AP)? A special case of AOP • One of the aspects or the components use graphs which are referred to by traversal strategies. • A traversal strategy defines traversals of graphs without referring to the details. • Adaptive programming is aspect-oriented programming with traversal strategies. Generic Programming/Dagstuhl

  11. Flexibility versus Complexity • AP adds flexibility • BUT simplifies designs and programs • Partial evaluation makes efficient Generic Programming/Dagstuhl

  12. Families: Nature Analogy for AP same seeds in different climates: similar trees same strategy in different class graphs: similar traversals warm climate cold climate Generic Programming/Dagstuhl

  13. Why Traversal Strategies? • Law of Demeter: a method should talk only to its • friends: • arguments and part objects (computed or stored) • and newly created objects • Dilemma: • If followed: Small method problem of OO • If not followed: Unmaintainable code • Traversal strategies are the solution to this dilemma 10 year anniversary Widely used, for example, at JPL for the Mars exploration software. Graph patterns: for implementing patterns Generic Programming/Dagstuhl

  14. Software Architecture View • Software architectures where connections necessary for a specific behavior are specified approximately, yet precisely, using regular expression-like constructs. • Improves on conventional architectures by supporting structure-shyness allowing both simpler and more flexible architectures. Generic Programming/Dagstuhl

  15. Implementation of traversal strategies • Based on novel applications and variations of standard techniques: • Intersection of non-deterministic finite automata • Simulation of non-deterministic finite automata Generic Programming/Dagstuhl

  16. How to do the interesting work? • Traversal strategies only navigate. • Visitors and adaptive plug and play components (APPCs) specify what is done in addition to navigation. • APPCs • change group of classes during a traversal • plug-and-play organization based on ports • parameterized by traversal strategies Generic Programming/Dagstuhl

  17. Adaptive Plug-and-Play Components (APCCs) • Specify two interfaces • to the class structure they are supposed to visit • to other APPCs they may be connected to Generic Programming/Dagstuhl

  18. Pricing Policies with APPCs • APPC Pricing • Interface • s1 = from lineItem: LineItemParty via item: ItemParty to charges: ChargesParty; • s2 = from lineItem: LineItemParty to pricer: PricerParty; • s3 = from lineItem: LineItemParty to customer: Customer; • PricerParty [ • Float basicPrice(ItemParty item); • Integer discount(ItemParty item, Integer qty, Customer: customer); ] • ChargesParty [ • Float cost(Integer qty, Float unitP, ItemParty: item ); ] Generic Programming/Dagstuhl

  19. Pricing Policies with APPCs APPC Pricing Behavior LineItemParty { public Float price (Integer qty ){ Float basicPrice, unitPrice; Integer discount; basicPrice = pricer.basicPrice(); discount = pricer.discount(item, qty, customer); unitPrice = basicPrice - (discount * basicPrice); return (unitprice + additionalCharges(unitPrice, qty)); } Float additionalCharges(float unitP, Integer qty) { Interger total = 0; during s1 { ChargesParty{total += cost(qty, unitP, item); } return total;} } } } Generic Programming/Dagstuhl

  20. Generic Programming/Dagstuhl

  21. Pricing Policies with APPCs • Let us generate different pricing schemes out of the generic pricing component • specified by the pricing adaptive plug-and-play component … • Scheme 1: Regular Pricing • each product has a base price which can be discounted depending on the number of the • units ordered • Scheme 2: Negotiated Pricing: • A customer may have negotiated certain prices and discounts for particular items Generic Programming/Dagstuhl

  22. Pricing Policies with APPCs Scheme 1: Regular Price Quote::+ {float regPrice() = Pricing with { LineItemParty = Quote; PriceParty = HWProduct [basicPrice = regPrice; discount = regDiscount;] ItemParty = HWProduct; ChargesParty = Tax [cost = taxCharge] } } Roles LineItemParty PriceParty ItemParty ChargesParty Played by Quote HWProduct Tax Generic Programming/Dagstuhl

  23. Pricing Policies with APPCs Scheme 2: Negotiated Price Quote::+ {Float negPrice() = Pricing with { LineItemParty = Quote; PriceParty = Customer; [basicPrice = negProdPrice; discount = negProdDiscount;] ItemParty = HWProduct; ChargesParty = Tax; [cost = taxCharge] } } Roles LineItemParty PriceParty ItemParty ChargesParty Played by Quote Customer HWProduct Tax Generic Programming/Dagstuhl

  24. APPC Compositions Graph algorithms Marking: Basic Marking Algorithm Cycle: Cycle Checking addition Connected: Connected Component Addition Generic Programming/Dagstuhl

  25. Composing APPCs APPC Marking { Interface s = from Graph to Adjacency to Vertex to Adjacency Behavior Adjacency { bool marked = false; myRole() { bool visited = marked; if (marked == false) { marked = true; next()}; return visited;} } } Generic Programming/Dagstuhl

  26. Composing APPCs APPC Connectivity { Interface s: from Graph to-stop Adjacency Behavior Integer count = 0; return count; Adjacency { myRole() { if ( next() == false ) { count += 1; } } } } Generic Programming/Dagstuhl

  27. Composing APPCs APPC CycleCheck { Interface s = from Graph to Adjacency to Vertex to Adjacency Behavior Stack stack = Stack new(); Adjacency { myRole() { if (stack.includes(this)) { System.out.printIn(``cycle'' + stack.print) } else { stack.add(this); } next(); stack.remove(this); } } } Generic Programming/Dagstuhl

  28. Composing APPCs Want to do connectivity and cycle check simultaneously Generic Programming/Dagstuhl

  29. Instantiating APPC Compositions ConnectivityAndCycleCheck = (Connectivity compose DGCycleCheck) (Marking) (Connectivity => CycleCheck => Marking, {Connectivity, CycleCheck} <= Marking) // INSTANTIATING FOR CONCRETE GRAPH STRUCTURE s = Network via Adjacency through neighbors via Node through <-source to Adjacency Network ::+ {void connectivityAndCycleCheck() = ConnectivityAndCycleCheck during s} with {Network = Graph; Node = Vertex; } Generic Programming/Dagstuhl

  30. Adaptive Plug-and-Play Components • Builds on Batory’s mixin layers (ECOOP 98) and supports adaptiveness by parameterization with traversal strategies • Modification of a group of collaborating classes • Encapsulate group of related adaptive programs Generic Programming/Dagstuhl

  31. Tools using Demeter ideas: Demeter/C++, Demeter/CLOS (BBN), Demeter/Perl5 (MIT), AspectJ (Xerox PARC) Goal of Demeter/Java • Avoid code tangling and redundancy • traversal strategies and visitors untangle structure and behavior • visitors and adjusters untangle code for distinct behaviors • COOL untangles synchronization issues and behavior • RIDL untangles remote invocation issues and behavior and structure Generic Programming/Dagstuhl

  32. Success indicators • Used in several commercial projects (HP (printer family installation), GTE (compiler), Motorola (pattern generator), Novell (schema comparator) • AspectJ from Xerox PARC based on Cristina Lopes Ph.D. thesis (1998) at Northeastern University supported by Xerox PARC. Generic Programming/Dagstuhl

  33. Success indicators: Commercialization effort StructureBuilder from Tendril Software Inc. Has support for traversals and generates code controlled by structure. www.tendril.com Generic Programming/Dagstuhl

  34. Conclusions • APPCs as a useful abstraction for generic programming • How to use them with C++ and STL: simulate them using the visitor design pattern • Traversal strategies are a key component of APPCs Generic Programming/Dagstuhl

  35. Some Connections • Complete traversals: APPCs need that too • Polytypic Programming: APPCs are polytypic • Konstanz team: Generic graph algorithms: APPCs seem to help • Traversal Strategy Graphs: can be explained in terms of temporal logic (CTL formulas) Generic Programming/Dagstuhl

  36. Partial Evaluation: Ray Tracing Viewpoint determines how scene appears. Avoid recomputations from viewpoint to viewpoint (imagine flying over scene). For example, intersection of objects can be computed once and reused for several viewpoints. Generic Programming/Dagstuhl

  37. Partial Evaluation: Ray Tracing Scene(S) ViewPoint(VP) ViewPoint(VP) P(S,VP) P(VP) S fixed Scene with light info Scene with light info Generic Programming/Dagstuhl

  38. Partial Evaluation: Ray Tracing Scene(S) ViewPoint(VP) ViewPoint(VP) P(VP) S fixed In C P(S,VP) PE for C PE for C PE for C Scene with light info in C Output = Scene with light info in C Generic Programming/Dagstuhl

  39. Partial Evaluation: Adaptive Programming Component SG CG OG OG P(SG,CG,OG) P(OG) CG fixed SG fixed APPCs fixed APPCs ClassGraph CG ObjectGraph OG StrategyGraph SG PE for graph language PE for graph language Output = Graph Language with code annotations Output Generic Programming/Dagstuhl

  40. Ray tracing freeze scene transform program to gain efficiency domain specific computation use general partial evaluation algorithms AP freeze class graph freeze strategy graph transform program to gain efficiency general-purpose computation use specialized partial evaluation algorithms (automata intersection) Similarities Generic Programming/Dagstuhl

  41. Ray tracing use general partial evaluation algorithms for a programming language such as C. AP use specialized partial evaluation algorithms (automata intersection) partial evaluation is done for a graph language Similarities Generic Programming/Dagstuhl

  42. Partial Evaluation: Adaptive Programming Component CG’ OG SG CG OG P(CG’,OG) CG partially fixed SG fixed P(SG,CG,OG) ClassGraph CG ObjectGraph OG StrategyGraph SG Output Output Generic Programming/Dagstuhl

  43. Aspect-Oriented Programming Generic Programming/Dagstuhl

  44. Aspect-Oriented Programming • Background aspects • synchronization • remote invocation • Foreground aspects • visitors • APPCs Generic Programming/Dagstuhl

  45. Aspect-Oriented Programming • Implementation requires special purpose partial evaluators. Example: P(SG,CG,OG) P(OG) CG fixed SG fixed PE for graph language Generic Programming/Dagstuhl

  46. Aspect-Oriented Programming • Expansion of aspect description • bounded • synchronization • unbounded • structure Generic Programming/Dagstuhl

  47. STL view data structures algorithms glue = iterators parameterized by iterators Generic Programming/Dagstuhl

  48. Demeter view adaptive algorithms data structures glue = traversal strategies Generic Programming/Dagstuhl

  49. Demeter view Generic Programming/Dagstuhl

  50. Demeter View • Adaptive program: strategies as parameters • Class graph: intended home for traversal strategies • Glue = traversal strategies = adapt strategy parameters to specific class graph and check constraints Generic Programming/Dagstuhl

More Related