adaptive plug and play components for
DESCRIPTION
Adaptive Plug and Play Components for. Evolutionary Software Development. Mira Mezini University of Siegen [email protected]. Karl Lieberherr Northeastern University [email protected]. IBM connections for ingredients to adaptive plug-and-play components (APPCs). - PowerPoint PPT PresentationTRANSCRIPT
1
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
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)
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
lineItem: LineItemParty pricer: PriceServerParty
item: ItemParty
price() 1: basicPrice (item)2: discount(item, qty,cust)
3: additional Charges(unitPr, qty)
ch: ChargerParty 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
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).
Strategy graph and base graph are directed graphs
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.
Strategy graph and base graph are directed graphs
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.
Strategy graph and base graph are directed graphs
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
Refinement means: no surprises
X
58
A
B
G1G2
G1 expansion G2
not G1 refinement G2
C
Refinement means: no surprises
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
65