adaptive plug and play components for

2

Z

C1

C2 C3

C4

C5

Collab-1

Collab-2Collab-2 Collab-3Collab-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 encapsulation beyond single objects

Late binding beyond single classes

5

C1

C2 C3

C4

C5

Both difficult without constructs that capture

collaborations

6

During implementationseparate collaborations

are mixed together

During maintenance individualcollaborations 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?



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 certainprinciples, 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

APPL1APPLn

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 ChargerParty

Float cost(Integer qty, Float unitPrice, ItemParty item)

14

lineItem: LineItemPartypricer: PriceServerParty

item: ItemParty

price() 1: basicPrice (item)2: discount(item, qty,cust)

3: additionalCharges(unitPr, qty)

ch: ChargerParty 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

C4C5

P1

P2

P3

APPL1

APPL1

C2 C3

C4C5

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

PP1

P3

main-entry

...

meth3,1

...

P2P3

meth3,j

meth1,k

meth1,1

main control flow of the

collaboration

18

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

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

P1 main-entry

m 1,1m 1,k...

P2 P3

participant-to-classname map

expected interfacename map

link-to-pathsmap

21

HWProductQuote

cust

Customer Tax Tax

prod

taxes

Tax Tax

Pricing APPC

HWAppl::+ {float regularPrice() = Pricing with { LineItemParty = Quote; PricerParty = HWProduct {

basicPrice = regPrice; discount = regDiscount };

ItemParty = HWProduct; ChargerParty = Tax ;}

22

HWProductQuote

cust

Customer Tax Tax

prod

taxes

Tax 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

P2P3

P1

P6P2

P5 P3

P4P1

P2

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

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> Customer <lineItems> 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()


item: ItemParty


3: additionalCharges(unitPr, qty)


3.2: cost(qty,unitPr,item)

price() { discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr);

return quotePr;}

4. stockTime5. stockTimeLimit

if (item.stockTime() > item.stockTimeLimit() {quotePr := quotePr - quotePr * 0.1;}

31

price() { basicPr = pricer.basicPrice(item); . . .

return quotePr;}


item: ItemParty


3: additional Charges(unitPr, qty)


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

refinement

refinement

35

Pricing

AgingPricingFrequentCustomer

Pricing

Aging&FrequentCustomerPricing

36

AgingPricing modifies Pricing {

mixin-like behavior definition

LineItemParty { price() { super.price();

reducedPrice(...); }

reducedPrice(...); } }

super not staticallybound

super not staticallybound

37

mixin-like behavior definition (late binding of super)

Pricing APPC


price() { . . . super . . .}

}


price() { . . . super . . .}

}

FrequentPricing modifies Pricing {

price() { . . . super . . .}

}

Pricing APPC

38

static declaration of the assumed specialization interface

Pricing APPC


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 underlyingimplementation 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):

adaptive plug and play components for

Documents