1. 1

2. 2 IBM connections for ingredients to adaptive plug-and-play components (APPCs) Adaptive Programming developed with support from IBM: Cun Xiao, Ignacio Silva-Lepe both working for IBM Contracts, another ingredient to APPCs, developed with support from IBM: Ian Holland also working for IBM

3. 3 IBM San Francisco Project http://www.ibm.com/Java/Sanfrancisco Commands (similar to the Command pattern in the Design Patterns book) are objects with the sole purpose to provide a separate location for a specific piece of business logic processing. APPCs are similar to Commands

4. 4 IBM San Francisco Project Benefits of Commands The implementation of business logic affecting several distinct business objects through Commands clearly brings advantages to maintenance and also allows application designers to isolate activities. By encapsulating the business logic in a Command object, client programs are isolated from changes in that piece of logic. It then becomes much easier to replace, modify, or enhance a certain piece of logic without impacting its users. This approach increases the flexibility of the framework. Benefits of Commands are also benefits of APPCs. APPCs are even better than commands.

5. 5 Z customer service center teller service self-service C1 C2 C3 C4 C5 Collab-1 Collab-2Collab-3 Collab-4 C1 C2 C3 C4 C5 OOAD Implementation

6. 6 why do we need language constructs that capture collaborations? unit of reuse is generally not a class, but a slice of behavior affecting several classes this is the core of application frameworks but: “because frameworks are described with programming languages, it is hard for developers to learn the collaborative patterns of a framework by reading it … it might be better to improve oo languages so that they can express patterns of collaboration more clearly” [R. Johnson, CACM, Sep. ‘97]

7. 7 single methods often make sense in a larger context “oo technology can be a burden to the maintainer because functionality is often spread over several methods which must all be traced to get the "big picture".” [Wilde at al., IEEE Software, Jan ‘93] “object-oriented technology has not met its expectations when applied to real business applications and argues that this is partly due to the fact that there is no natural place where to put higher-level operations (such as business processes) which affect several objects. … if built into the classes involved, it is impossible to get an overview of the control flow. It is like reading a road map through a soda straw'’ [Lauesen, IEEE Software, April ‘98]

8. 8 C1 C2 C3 C4 C5 P1 P2 P3 C1 C3 C2 C4 APPL 1 n

9. 9 C1 C2 C3 C4 C5 P1 P2 P3 APPL 1 1 C2 C3 C4 C5 C1

10. 10 Requirements on the design: ä Generic specification of the collaboration with respect to the class structure it will be applied to. This serves two purposes: (a) allow the same component to be used with several different concrete applications, and (b) allow a collaborative component to be mapped in different ways, i.e., with different class-to-participant mappings, into the same class structure. ä Loose coupling of behavior to structure to make collaborative components robust under changing class structures and thus better support maintenance.

11. 11 from the domain of order entry systems originated from an application system generator developed at IBM (‘70) called Hardgoods Distributors Management Accounting System goal: encode a generic design for order entry systems which could be subsequently customized to produce an application meeting a customer’s specific needs customer’s specific requirements recorded in a questionnaire the installation guide described the options and the consequences associated with questions on the questionnaire

12. 12 LineItemParty PriceServerParty ItemParty quantity float basicPrice(ItemParty item) Integer discount(ItemParty item, Integer qty, Customer cust) Float additionalCharges(Float unitPrice Integer: qty) Customer ChargerParty Float cost(Integer qty, Float unitPrice, ItemParty item)

13. 13 lineItem: LineItemParty pricer: PriceServerParty item: ItemParty price() 1: basicPrice (item) 2: discount(item, qty,cust) 3: additionalCharges(unitPr, qty) ch: ChargerParty ChargerParty 3.1: ch=next() 3.2: cost(qty,unitPr,item) additionalCharges(…){ Integer total; forall ch in charges{ total = total + ch.cost(…)} return total} price() { basicPr = pricer.basicPrice(item); discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr); quotePr = uniPr + item.additionalCharges(unitPr, qty); return quotePr;}

14. 14 design is fairly simple complexity is a problem with this application generator’s component, though: the complexity results from numerous, and arbitrary, pricing schemes in use by industry and by the representation of these schemes in the system. The price depends on: the type of the customer (government, educational, regular, cash, etc.), the time of the year (high/low demand season), whether cost-plus or discounting applies whether prior price-negotiated prices involved, extra charges for the items such as taxes, deposits or surcharges … etc.

15. 15 let us generate different pricing schemes out of the generic pricing component specified by the pricing APPC … Scheme 1: Regular Pricing products have a base price which can be discounted depending on the number of the units ordered Scheme 2: Negotiated Pricing: a customer may negotiate certain prices and discounts for particular items

16. 16 refinement base collaboration - incrementally refine whole collaborations similar to individual classes

17. 17 refinement - reuse refinements with different bases base collaboration

18. 18 - combine several refinements of the same base base collaboration refinement

19. 19 lineItem: LineItemParty pricer: PriceServerParty item: ItemParty price()1: basicPrice (item) 2: discount(item, qty,cust) 3: additionalCharges(unitPr, qty) ch: ChargerParty ChargerParty 3.1: ch=next()3.2: cost(qty,unitPr,item) price() { basicPr = pricer.basicPrice(item); discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr); quotePr = uniPr + item.additionalCharges(unitPr, qty); return quotePr;} 4. stockTime 5. stockTimeLimit if (item.stockTime() > item.stockTimeLimit() {quotePr := quotePr - quotePr * 0.1;}

20. 20 lineItem: LineItemParty pricer: PriceServerParty item: ItemParty price() 1: basicPrice (item) 2: discount(item, qty,cust) 3: additional Charges(unitPr, qty) ch: ChargerParty ChargerParty 3.1: ch=next()3.2: cost(qty,unitPr,item) price() { basicPr = pricer.basicPrice(item);... return quotePr;} 4. history() 5. freqReduction() if (customer.frequent()) { hist = customer.get History(); freqRed = item.freqReduction(hist); quotePr = quotePr * freqRed} customer: Customer

21. 21 Pricing AgingPricing FrequentCustomer Pricing Aging&FrequentCustomer Pricing

22. 22 higher-level collaboration lower-level collaboration

23. 23 LineItemParty :LineItemParty LineItemParty float price() LineItemParty float price() OrderParty :OrderParty LineItemParty :LineItemParty lineItem :LineItemParty 1:lineItem = next()2: price() total()

24. 24 Requirements on the design: ¹ flexible composition mechanisms to support reusing existing collaborations to build more complex collaborations. Why? ä Loose coupling among collaborations in the sense that their definition does not make explicit commitments to a particular structure of composition. The aim is to facilitate putting the same components into several compositions in a flexible manner. ä A composition mechanism that maintains the ``encapsulation'' and independence of collaborations when involved in compositions with other components. The aim is to avoid name conflicts and allow simultaneous execution of several collaborations even if these may share a common ``parent''’.

25. 25 P1 expected interfaces minimal assumptions on the structure of the applications + written to the ICG similar to an OO program written to a concrete class graph P 1 P main-entry 3 m 1,1 m 1,k... m 1,1 m 1,k... P2 P3 main control flow of the collaboration

26. 26 APPC Pricing { Interface Class Graph: // structural interface LineItemParty = ItemParty PricerParty Customer ItemParty = ListOf(ChargerParty) // behavioral interface LineItemParty { int quantity();} PricerParty { float basicPrice(ItemParty item); float discount(ItemParty item, int qty, Customer customer); } ChargerParty { float cost(int qty, float unitP, ItemParty item); }

27. 27 Behavior Definition: LineItemParty { main-entry float price() { float basicPrice, unitPrice; int discount, qty; qty = this.quantity(); basicPrice = pricer.basicPrice(item); discount = pricer.discount(item, qty, customer); unitPrice = basicPrice - (discount * basicPrice); return (unitPrice + item.additionalCharges(unitPrice, qty));} } ItemParty { private float additionalCharges(float unitP, int qty) { float total; while (chargerParties.hasElement()) { nextCharge = chargerParties.next(); total =+ charge.cost(qty, unitP, itemInst); return total; } }

28. 28 P1 P 1 main-entry m 1,1 m 1,k... P2 P3 C1 C2 C4 C3 participant-to-class name map expected interface name map link-to-path map

29. 29 HWProductQuote cust Customer Tax prod taxes Tax Pricing APPC HWAppl::+ {float regularPrice() = Pricing with { LineItemParty = Quote; PricerParty = HWProduct { basicPrice = regPrice; discount = regDiscount }; ItemParty = HWProduct; ChargerParty = Tax { cost = taxCharge};}

30. 30 HWProductQuote cust Customer Tax prod taxes Tax Pricing APPC HWAppl::+ {float regularPrice() = Pricing with { LineItemParty = Quote; PricerParty = Customer { basicPrice = negProdPrice; discount = negProdDiscount }; ItemParty = HWProduct; ChargerParty = Tax { cost = taxCharge};}

31. 31 class Quote { …. public regPrice() { RegularPriceVisitor v = RegularPriceVisitor(); return {v.price (this);} …. } class RegularPriceVisitor { public price (Quote host) {... } private additionalCharges(float unitPrice, Integer qty) {... }

32. 32 APPC SpecialPricing modifies Pricing { Behavior-Definition: LineItemParty { public float price() { float calcPrice = super.price(); return reducedPrice(calcPrice); protected float reducedPrice(float calcPrice); } } mixin-like behavior definition - late binding of super static declaration of the assumed specialization interface +

33. 33 APPC AgingPricing modifies SpecialPricing { Interface-Class-Graph: //more behavioral interface ItemParty {Time stockTime();} Behavior Definition: LineItemParty { protected float reducedPrice(float calcPrice) {...} } APPC FrequentCustomerPricing modifies SpecialPricing { Interface-Class-Graph: //more behavioral interface Customer {... } ItemParty {... } Behavior Definition: LineItemParty { protected float reducedPrice(float calcPrice) {...} }

34. 34 Pricing price AgingPricingSpecialPricing price FrequentCustomerPricingSpecialPricing price AgingDeltaFrequentCustomerDelta reducedPrice AgingPriicngSpecialPricing price AgingDelta reducedPrice Pricing price AgingPolicy = AgingDelta + Pricing AgingDelta = AgingPricing + SpecialPricing AgingAndFrequentCustomerPolicy = AgingDelta + FrequentCustomerDelta + Pricing FrequentCustomerDelta = FrequentCustomerPricing + SpecialPricing AgingPolicy AgingAndFrequentCustomerPolicy

35. 35 well, operations in the expected interface of one (higher-level) APPC can be mapped to the result of instantiating another (lower-level) APPC. APPC Total { Interface-Class-Graph: OrderParty = Customer SetOf(LineItemParty) LineItemParty { float price(); } Behavior-Definition: OrderParty { main-entry float total() {... while lineItems.hasElements()) {... total += nextLineItem.price(); } return total; } } HWAppl ::+ {float totalReg = Total with { OrderParty = Order; LineItemParty = Quote {price = regularPrice}; }

36. 36 Adaptive Programming Rondo APPCs visitor pattern (GOF) role modeling with template classes (VanHilst & Notkin) mixin-layers (Smaragdakis & Batory) contracts (Holland) SOP (Harrison & Ossher)

37. 37 Implement APPCs using Java Beans Formal semantics of APPCs Develop a library of APPCs to replace an existing framework

38. 38 Subject-Oriented Programming How are APPCs different? Both subjects and APPCs use the idea of an interface class graph But APPCs use ideas from graph theory and automata theory to help map interface class graphs to concrete application class graphs: mapping may be controlled by strategy graphs.

39. 39 Subject-Oriented Programming How are APPCs different? APPCs support a traversal-visitor style of programming Traversals are specified by graphs (strategy graphs) that direct the navigation in both positive and negative ways Strategy graphs are automatically converted into traversal code (error-prone if done manually)

40. 40 Underlying ideas Graph1 refinement Graph2 Graphs can play the following roles: –interface class graph –(application class) graph –positive strategy graph

41. A A BB C C D D E E F F G1G1 G2G2 G 1 compatible G 2 Compatible: connectivity of G 2 is in G 1

42. A A BB C C D D E E F F G1G1 G2G2 G 1 refinement G 2 refinement: connectivity of G 2 is in G 1 and G 1 contains no new connections in terms of nodes of G 2

43. Roles graphs play in OOD under refinement relations Small graph –G –PSG Big graph –G –PSG –G G: class graph (CG) or interface class graph (ICG). ICG is a view on a class graph. PSG: positive strategy graph.

44. Roles graphs play in OOD under refinement relations PSG PSG subtraversal

45. 45 Applications of strategy graphs Specify mapping between graphs (adaptor) –Advantage: mapping does not have to refer to details of lower level graph  robustness Specify traversals through graphs –Specification does not have to refer to details of traversed graph  robustness Specify function compositions –without referring to detail of API  robustness

46. 46 Applications of strategy graphs Specify range of generic operations such as comparing, copying, printing, etc. –without referring to details of class graph  robustness. Used in Demeter/Java. Used in distributed computing: marshalling, D, AspectJ, Xerox PARC

47. 47 Theory of Strategy Graphs Palsberg/Xiao/Lieberherr: TOPLAS ‘95 Palsberg/Patt-Shamir/Lieberherr: Science of Computer Programming 1997 Lieberherr/Patt-Shamir: 1997 NU TR Lieberherr/Patt-Shamir: Dagstuhl ‘98 Workshop on Generic Programming (LNCS)

48. 48 Key concepts Strategy graph S with source s and target t of a base graph G. Nodes(S) subset Nodes(G) (Embedded strategy graph). A path p is an expansion of path p’ if p’ can be obtained by deleting some elements from p. S defines path set in G as follows: PathSet st (G,S) is the set of all s-t paths in G that are expansions of any s-t path in S. Strategy graph and base graph are directed graphs

49. A = s A BB C C D D E E F=t F G1G1 G2G2 PathSet(G 1,G 2 )

50. 50 Key concepts A strategy graph G 1 is a path-set-refinement of a strategy graph G 2 if for all base graphs G 3 : PathSet(G 3,G 1 )  PathSet(G 3,G 2 ). Strategy graph and base graph are directed graphs

51. A=s A B=t B Y X G1G1 G2G2 G 1 path-set-refinement G 2

52. 52 Key concepts A strategy graph G 1 is an expansion of a strategy graph G 2 if for any path p 1 (from s to t) in G 1 there exists a path p 2 (from s to t) in G 2 such that p 1 is an expansion of p 2. Strategy graph and base graph are directed graphs

53. 53 Key concepts A strategy graph G 1 is a dual-expansion of a strategy graph G 2 if for any path p 2 (from s to t) in G 2 there exists a path p 1 (from s to t) in G 1 such that p 1 is an expansion of p 2. Strategy graph and base graph are directed graphs

54. A=s A B=t B Y X G1G1 G2G2 G 1 path-set-refinement G 2 G 1 expansion G 2

55. 55 Key concepts Let G1=(V1,E1) and G2=(V2,E2) be directed graphs with V2 a subset of V1. Graph G 1 is a refinement of G 2 if for all u,v in V 2 we have that (u,v) in E 2 if and only if there exists a path in G 1 between u and v which does not use in its interior a node in V 2.

56. A A B B G1G1 G2G2 not G 1 refinement G 2 C C Refinement means: no surprises G 1 expansion G 2

57. A A B B G1G1 G2G2 G 1 refinement G 2 C C Refinement means: no surprises X

58. A B G1G1 G2G2 G 1 expansion G 2 not G 1 refinement G 2 C Refinement means: no surprises A B C

59. 59 Demeter/Java A tool (third year of development [1998]) for experimenting with adaptive programming Used by several prototyping projects in industry. Ideas made it into commercial products (HP) Available from Demeter/AP home page

60. 60 Strategy Graph Library A part of Demeter/Java: Takes as input a class graph and a strategy graph and produces a compact representation of the path set for the class graph. This compact representation can be used for generating Java code, etc. Distributed with Demeter/Java

61. 61 Ongoing work Johan Ovlinger: Class Graph Views, a generalization of APPCs –dynamically add/remove behavior at run-time –export robust interfaces to changing class graphs –not insertive but uses a layered approach –paper available

62. 62 Ongoing Work Structure Builder (Tendril Software Inc., www.tendril.com) –Code generation from sequence diagram-like structures, called sequence graphs –Sequence graphs: overview part / implementation part –Object-transportation automatic

63. 63 Conclusions APPCs: a useful new model for describing behavior in more reusable form Many goals in common with subject- oriented programming Key contributions: Decoupling/composition ideas and strategy graphs with algorithms for compiling and comparing graphs

64. 64 Conclusions What might be the most useful application of AP ideas to Subject-Oriented Programming? High-level specification of Adaptors. More: www.ccs.neu.edu/home/lieber

65. 65