Adaptive Plug and Play Components for

1. Adaptive Plug and Play Components for Evolutionary Software Development Mira Mezini University of Siegen mira@informatik.uni-siegen.de Karl Lieberherr Northeastern University lieber@ccs.neu.edu

2. No language constructs that capture collaborations C1 C4 C2 C3 C5 Motivation OOAD Collab-1 Z C1 C4 C2 C3 C5 Collab-4 Collab-2 Collab-3 Implementation --> Tangling

3. What is the problem? “OO technology has not met its expectations when applied to real business applications partly due to the fact thatthere is no place where to put higher-level operationswhich 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]

4. What is the problem? Unit of reuse is generally not a class, but a slice of behavior affecting several classes • Unit of encapsulation beyond single objects • Late binding beyond single classes

5. C1 C4 C2 C3 C5 What is the problem? Both difficult without constructs that capture collaborations

6. What is the problem? During implementation separate collaborations are mixed together During maintenance individual collaborations need to be factored out of the tangled code

7. What is the problem? Unit of reuse is generally not a class, but a slice of behavior affecting several classes Isn’t that at the core of application frameworks?

8. What is the problem? Indeed, but ... • “because frameworks are described with programming • languages, it is hard to learn the collaborative patterns • of a framework by reading it … • it might be better to improve oo languages so that • they can express collaborations more clearly” • [ Johnson, CACM, Sep. ‘97]

9. C1 C4 C2 C3 C5 What is the problem? So, what? Forget about objects?

10. What is the problem? No. The point is merely that objects are too low-level. If we don’t follow certain principles, we easily end up with “hyper spaghetti’’ objects Let’s organize. Let’s have components on top of them.

11. Design Goals: Adaptiveness P2 one generic collaboration P3 P1 reused APPL 1 C1 C1 APPL C2 n C4 C2 C3 C3 C4 C5 with a family of concrete applications

12. But, why adaptive? An example ... • origine: an application generator from IBM (‘70) • 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 consider the pricing component ...

13. But, why adaptive? An example ... PriceServerParty LineItemParty float basicPrice(ItemParty item) Integer discount(ItemParty item, Integer qty, Customer cust) quantity ItemParty Float additionalCharges(Float unitPrice Integer: qty) Customer ChargerParty ChargerParty Float cost(Integer qty, Float unitPrice, ItemParty item) pricing component: class diagram

14. But, why adaptive? An example ... price() { basicPr = pricer.basicPrice(item); discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr); quotePr = uniPr + item.additionalCharges(unitPr, qty); return quotePr;} design applies to several applications with different classes playing the participant roles price() 1: basicPrice (item) 2: discount(item, qty,cust) lineItem: LineItemParty pricer: PriceServerParty 3: additionalCharges(unitPr, qty) additionalCharges(…){ Integer total; forall ch in charges{ total = total + ch.cost(…)} return total} item: ItemParty 3.2: cost(qty,unitPr,item) 3.1: ch=next() pricing component: collaboration diagram ChargerParty ChargerParty ch: ChargerParty

15. Design Goals: Adaptiveness P2 one generic collaboration P3 P1 reused with different mappings of participants to classes APPL 1 C1 APPL C1 1 C4 C4 C5 C5 C2 C3 C2 C3 of the same application

16. But, why adaptive? An example ... • need to represent several pricing schemes: • discounts depending on the number of ordered units, • pre-negotiated prices possible, • depending on the time of the year (high/low season), • … etc. • with the same role played by different classes in • different schemes

17. minimal assumptions on application structure P3 P2 + expected interfaces main control flow of the collaboration meth meth meth meth 1,1 3,1 1,k 3,j How do APPCs look like? Interface Class Graph P1 Behavior Definition P P1 main-entry written to the ICG similar to an OO program written to a concrete class graph ... P3 ...

18. How do APPCs look like? APPC Pricing { Interface Class Graph: // structural interface ==> textual representation of UML // class diagram LineItemParty = <item> ItemParty <pricer> PricerParty <customer> Customer ItemParty = <charges> ListOf(ChargerParty) // behavioral interface ==> set of expected interfaces 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); }

19. How do APPCs look like? Behavior Definition: int qty; float unitPprice; //local variables LineItemParty { main-entryfloat price() { float basicPrice, int discount; qty = this.quantity(); basicPrice = pricer.basicPrice(item); discount = pricer.discount(item, qty, customer); unitPrice = basicPrice - (discount * basicPrice); return (unitPrice + item.additionalCharges());} } ItemParty { private float additionalCharges() { float total; while (charges.hasElement()) { nextCharge = chargerParties.next(); total =+ charge.cost(qty, unitP, this); return total; } }

20. P3 P2 m m 1,k 1,1 How do I plug APPCs into the applications? Application participant-to-class name map Interface Class Graph Structure expected interface name map P1 link-to-paths map Behavior Definition main-entry P1 ... adaptive compiler (CG-to-ICG compatability?) executable Java code

21. How do I plug APPCs into the applications? Map 1 Application Structure HWAppl::+ {float regularPrice() = Pricing with { LineItemParty = Quote; PricerParty = HWProduct { basicPrice = regPrice; discount = regDiscount }; ItemParty = HWProduct; ChargerParty = Tax ;} prod Quote HWProduct cust taxes Pricing APPC Tax Customer Tax Tax Tax adaptive compiler (CG-to-ICG compatability?)

22. How do I plug APPCs into the applications? Map 2 HWAppl::+ {float negotiatedPrice() = Pricing with { LineItemParty = Quote; PricerParty = Customer { basicPrice = negProdPrice; discount = negProdDiscount }; ItemParty = HWProduct; ChargerParty = Tax;} Application Structure prod HWProduct Quote taxes cust Pricing APPC Tax Tax Tax Customer Tax adaptive compiler (CG-to-ICG compatability?)

23. Design Goals: Plug and Play 1. black-box composition higher-level collaboration lower-level collaboration

24. P1 P2 P4 P5 P3 P3 P2 P6 P1 P1 P2 Design Goals: Plug and Play 1. black-box composition

25. Design Goals: Plug and Play 1. black-box composition . . . decoupled

26. Design Goals: Plug and Play 1. black-box composition . . . decoupled

27. Why decoupled black-box composition? may be any of the pricing schemes OrderParty LineItemParty LineItemParty float price() total() float price() :OrderParty 2: price() 1:lineItem = next() lineItem :LineItemParty :LineItemParty

28. HWAppl::+ {float regularPrice() = Pricing with { . . . } Pricing APPC How do I compose APPCs? Expected interface of one APPC mapped to main entry of another APPC. APPCTotal { Interface-Class-Graph: OrderParty = <customer> Customer <lineItems> SetOf(LineItemParty) LineItemParty { floatprice(); } Behavior-Definition: OrderParty { main-entryfloat total() { ... while lineItems.hasElements()) { total += nextLineItem.price(); } return total; } } } HWAppl ::+ {floattotalReg = Total with { OrderParty = Order; LineItemParty = Quote {price = regularPrice}; }

29. base collaboration refinement Design Goals: Plug and Play 2. white-box composition incrementally refine entire collaborations similar to individual classes

30. if (item.stockTime() > item.stockTimeLimit() {quotePr := quotePr - quotePr * 0.1;} price() 1: basicPrice (item) 2: discount(item, qty,cust) lineItem: LineItemParty pricer: PriceServerParty 4. stockTime 3: additionalCharges(unitPr, qty) 5. stockTimeLimit item: ItemParty 3.2: cost(qty,unitPr,item) ChargerParty ChargerParty ch: ChargerParty Why white-box composition? e.g. AgingPricing could have different pricing refinements price() { discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr); return quotePr;} 3.1: ch=next()

31. if (customer.frequent()) { hist = customer.get History(); freqRed = item.freqReduction(hist); quotePr = quotePr * freqRed} 1: basicPrice (item) 2: discount(item, qty,cust) price() lineItem: LineItemParty pricer: PriceServerParty 4. history() 5. freqReduction() 3: additional Charges(unitPr, qty) customer: Customer item: ItemParty 3.1: ch=next() 3.2: cost(qty,unitPr,item) ChargerParty ChargerParty ch: ChargerParty Why white-box composition? e.g. FrequentCustomerPricing could have different pricing refinements price() { basicPr = pricer.basicPrice(item); . . . return quotePr;}

32. base collaboration refinement Design Goals: Plug and Play 2. white-box composition . . . but decoupled (a) reuse refinements with different bases

33. base collaboration refinement Design Goals: Plug and Play 2. white-box composition . . . but decoupled (a) reuse refinements with different bases

34. refinement base collaboration refinement refinement Design Goals: Plug and Play 2. white-box composition . . . but decoupled (b) combine several refinements of the same base without conflicts

35. Why decoupled white-box composition? could have different pricing refinements or combinations of the latter Pricing FrequentCustomer Pricing AgingPricing Aging&FrequentCustomer Pricing

36. How does white-box composition of APPCs work? • mixin-like behavior definition super not statically bound AgingPricingmodifiesPricing { LineItemParty { price() { super.price(); reducedPrice(...); } reducedPrice(...); } }

37. AgingPricingmodifies Pricing { AgingPricingmodifies Pricing { FrequentPricingmodifies Pricing { price() {. . .super . . .} price() {. . .super . . .} price() {. . .super . . .} Pricing APPC Pricing APPC } } } How does white-box composition of APPCs work? • mixin-like behavior definition (late binding of super)

38. AgingPricingmodifiesPricing { price() {. . .super . . . . . . reducedPrice} reducedPrice(); Pricing APPC } FrequentPricingmodifiesPricing { price() {. . .super . . . . . . reducedPrice } reducedPrice() } How does white-box composition of APPCs work? • static declaration of the assumed specialization interface

39. Summary Larger-grained constructs that complement classes in modeling collaborations Generic collaborations that can be reused with a family of applications Decoupled black-box composition of collaborations Definition of new collaborations as refinements of other collaborations

40. Future Work Separate compilation and Java Beans as underlying implementation technology Formal semantics Library of APPCs to investigate their suitability in supporting component-oriented programming

41. Adaptive Programming APPCs Rondo Related Work visitor pattern (GOF) role modeling with template classes (VanHilst & Notkin) mixin-layers (Smaragdakis & Batory) contracts (Holland) AOP (Kiczales & Lopes): SOP (Harrison & Ossher)

42. Still questions ?!