1

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

3 “OO technology has not met its expectations when applied to real business applications partly due to the fact that there is no place where to put higher-level operations 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]

4 Unit of reuse is generally not a class, but a slice of behavior affecting several classes 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 C2 C3 C4 C5 Both difficult without constructs that capture collaborations

6 During implementation separate collaborations are mixed together During maintenance individual collaborations need to be factored out of the tangled code

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

8 “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] Indeed, but...

9 C1 C2 C3 C4 C5 So, what? Forget about objects?

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

11 C1 C2 C3 C4 C5 P1 P2 P3 C1 C3 C2 C4 APPL 1 n

12 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

13 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)

14 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;} design applies to several applications with different classes playing the participant roles

15 C1 C2 C3 C4 C5 P1 P2 P3 APPL 1 1 C2 C3 C4 C5 C1

16 * 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 written to the ICG similar to an OO program written to a concrete class graph expected interfaces minimal assumptions on application structure + P1 P P3 main-entry... meth 3,1... P2 P3 meth 3,j meth 1,k meth 1,1 main control flow of the collaboration

18 APPC Pricing { Interface Class Graph: // structural interface ==> textual representation of UML // class diagram LineItemParty = ItemParty PricerParty Customer ItemParty = 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 Behavior Definition : int qty; float unitPprice ; //local variables LineItemParty { main-entry float 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 P1 main-entry m 1,1 m 1,k... P2 P3 participant-to-class name map expected interface name map link-to-paths map

21 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 ;}

22 HWProduct Quote cust Customer Tax prod taxes Tax Pricing APPC HWAppl::+ {float negotiatedPrice () = Pricing with { LineItemParty = Quote; PricerParty = Customer { basicPrice = negProdPrice; discount = negProdDiscount }; ItemParty = HWProduct; ChargerParty = Tax;}

23 higher-level collaboration lower-level collaboration

24 P1 P2 P3 P1 P6 P2 P5 P3 P4 P1 P2

25

26

27 LineItemParty float price() LineItemParty float price() OrderParty :OrderParty :LineItemParty lineItem :LineItemParty 1:lineItem = next() 2: price() total() may be any of the pricing schemes

28 Expected interface of one APPC mapped to main entry of another 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 }; } Pricing APPC HWAppl::+ {float regularPrice () = Pricing with {... }

29 refinement base collaboration incrementally refine entire collaborations similar to individual classes

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

31 price() { basicPr = pricer.basicPrice(item);... return quotePr;} 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) 4. history() 5. freqReduction() if (customer.frequent()) { hist = customer.get History(); freqRed = item.freqReduction(hist); quotePr = quotePr * freqRed} customer: Customer

32 refinement (a) reuse refinements with different bases base collaboration

33 refinement base collaboration (a) reuse refinements with different bases

34 (b) combine several refinements of the same base without conflicts base collaboration refinement

35 Pricing AgingPricing FrequentCustomer Pricing Aging&FrequentCustomer Pricing

36 AgingPricing modifies Pricing { ¶ mixin-like behavior definition LineItemParty { price() { super.price(); reducedPrice (...); } reducedPrice (...); } } super not statically bound super not statically bound

37 ¶ mixin-like behavior definition (late binding of super) Pricing APPC AgingPricing modifies Pricing { price() {... super...} } AgingPricing modifies Pricing { price() {... super...} } FrequentPricing modifies Pricing { price() {... super...} } Pricing APPC

38 · static declaration of the assumed specialization interface Pricing APPC AgingPricing modifies Pricing { price() {... super reducedPrice} reducedPrice(); } FrequentPricing modifies Pricing { price() {... super reducedPrice } reducedPrice() }

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

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

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

42