Adaptive Plug and Play Components for

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

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

IBM San Francisco ProjectBenefits of CommandsThe 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

Zcustomer servicecenter

teller service

self-service

C1

C2 C3

C4

C5

Collab-1

Collab-2 Collab-3Collab-4

C1

C2 C3

C4

C5

OOAD

Implementation

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

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

C1

C2 C3

C4

C5

P1

P2

P3

C1

C3

C2

C4

APPL1

APPLn

9

C1

C2 C3

C4C5

P1

P2

P3

APPL1

APPL1

C2 C3

C4C5

C1

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

• 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

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)

13

lineItem: LineItemParty pricer: 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;}

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 inuse by industry and by the representation of these schemes in the system. Theprice 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

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

refinement

base collaboration

- incrementally refine whole collaborations similar to individual classes

17

refinement

- reuse refinements with different bases

base collaboration

18

- combine several refinements of the same base

base collaboration

refinement

refinement

refinement

19


item: ItemParty


3: additionalCharges(unitPr, qty)



price() { basicPr = pricer.basicPrice(item); discount = pricer.discount(item, qty, cust); unitPr = basicPr - (discount * basicPr); quotePr = uniPr + item.additionalCharges(unitPr, qty);

return quotePr;}

4. stockTime5. stockTimeLimit

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

20


item: ItemParty


3: additional Charges(unitPr, qty)



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

Pricing

AgingPricingFrequentCustomer

Pricing

Aging&FrequentCustomerPricing

22

higher-level collaboration

lower-level collaboration

23

LineItemParty:LineItemParty

LineItemParty

float price()

LineItemParty

float price()

OrderParty

:OrderParty

LineItemParty:LineItemParty lineItem :LineItemParty

1:lineItem = next() 2: price()

total()

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

P1

expected interfaces

minimal assumptions on the structure of the applications

+

written to the ICG similar

to an OO program writtento a concrete class graph

P1

P

main-entry

3

m1,1

m1,k

...

m1,1

m1,k

...

P2P3

main control flow of the collaboration

26

APPC Pricing { Interface Class Graph: // structural interface

LineItemParty = <item> ItemParty <pricer> PricerParty <customer> Customer ItemParty = <charges> 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

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

P1

P1main-entry

m 1,1m 1,k...

P2 P3C1

C2

C4

C3

participant-to-classname map

expected interfacename map

link-to-pathmap

29

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 {

cost = taxCharge};}

30

HWProductQuote

cust

Customer Tax Tax

prod

taxes

Tax Tax

Pricing APPC

HWAppl::+ {float regularPrice() = Pricing with { LineItemParty = Quote; PricerParty = Customer { basicPrice = negProdPrice; discount = negProdDiscount }; ItemParty = HWProduct; ChargerParty = Tax {

cost = taxCharge};}

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

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

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

Pricing

price

AgingPricing SpecialPricing

price

FrequentCustomerPricing SpecialPricing

price

AgingDelta FrequentCustomerDelta

reducedPrice reducedPrice

AgingPriicng SpecialPricing

price

AgingDelta

reducedPrice

Pricing

price

AgingPolicy = AgingDelta + Pricing

AgingDelta = AgingPricing + SpecialPricing

AgingAndFrequentCustomerPolicy = AgingDelta + FrequentCustomerDelta + Pricing

FrequentCustomerDelta = FrequentCustomerPricing + SpecialPricing

AgingPolicy

AgingAndFrequentCustomerPolicy

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

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

Implement APPCs using Java Beans

Formal semantics of APPCs

Develop a library of APPCs to replace an existing framework

38

Subject-Oriented ProgrammingHow 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

Subject-Oriented ProgrammingHow 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

Underlying ideas

• Graph1 refinement Graph2

• Graphs can play the following roles:– interface class graph– (application class) graph– positive strategy graph

41

A A

B BC C

D DE E

F F

G1

G2

G1 compatible G2

Compatible: connectivity of G2 is in G1

42

A A

B BC C

D DE E

F F

G1

G2

G1 refinement G2

refinement: connectivity of G2

is in G1 and G1 contains nonew connections in terms ofnodes of G2

43

Roles graphs play in OODunder refinement relations

• Small graph– G

– PSG

– 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 OODunder refinement relations

SMALL BIG INTENTCG CG evolutionICG CG viewCG ICG viewICG ICG layeringPSG CG APPSG ICG improved AP

PSG PSG subtraversal

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

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

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

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: PathSetst(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

B BC C

D DE E

F=t F

G1

G2

PathSet(G1 ,G2)

50

Key concepts

• A strategy graph G1 is a path-set-refinement of a strategy graph G2 if for all base graphs G3: PathSet(G3,G1) PathSet(G3,G2).


51

A=s A

B=tB

YX

G1

G2

G1 path-set-refinement G2

52

Key concepts

• A strategy graph G1 is an expansion of a strategy graph G2 if for any path p1 (from s to t) in G1 there exists a path p2 (from s to t) in G2 such that p1 is an expansion of p2.


53

Key concepts

• A strategy graph G1 is a dual-expansion of a strategy graph G2 if for any path p2 (from s to t) in G2 there exists a path p1 (from s to t) in G1 such that p1 is an expansion of p2.


54

A=s A

B=tB

YX

G1

G2

G1 path-set-refinement G2

G1 expansion G2

55

Key concepts

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

56

A A

BB

G1

G2

not G1 refinement G2

C C

Refinement means: no surprises

G1 expansion G2

57

A A

BB

G1

G2

G1 refinement G2

C C


X

58

A

B

G1G2

G1 expansion G2

not G1 refinement G2

C


A

B C

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

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

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

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

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

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

Adaptive Plug and Play Components for

Documents

Transcript of Adaptive Plug and Play Components for