Transcript No language constructs that capture collaborations OOAD Collab-1 Z C1 C2 C4 C3 C5 Collab-2 C1 Collab-4 Collab-3 C4 C2 C3 C5 Implementation “OO technology has not met its expectations when applied to real business applications partly due to the fact that.

1
No language
constructs that
capture
collaborations
OOAD
Collab-1
Z
C1
C2
C4
C3
C5
Collab-2
C1
Collab-4
Collab-3
C4
C2
C3
C5
Implementation
2
“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]
3
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
4
Both difficult without
constructs that capture
collaborations
C1
C4
C2
C3
C5
5
During implementation
separate collaborations
are mixed together
During maintenance individual
collaborations need to be
factored out of the tangled code
6
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?
7
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]
8
So, what?
Forget about objects?
C1
C4
C2
C3
C5
9
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.
10
P2
P1
APPL1
C2
C1
P3
C1
C4
C3
C3
C5
C2
APPLn
C4
11
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
12
PriceServerParty
LineItemParty
float basicPrice(ItemParty item)
Integer discount(ItemParty item, Integer qty, Customer cust)
quantity
ItemParty
Customer
Float additionalCharges(Float unitPrice Integer: qty)
ChargerParty
ChargerParty
Float cost(Integer qty, Float unitPrice, ItemParty item)
13
price() {
basicPr = pricer.basicPrice(item);
discount = pricer.discount(item, qty, cust);
unitPr = basicPr - (discount * basicPr);
quotePr = uniPr + item.additionalCharges(unitPr, qty);
return quotePr;}
price()
design applies to several
applications with
different classes playing
the participant roles
1: basicPrice (item)
2: discount(item, qty,cust)
lineItem: LineItemParty
pricer: PriceServerParty
3: additionalCharges(unitPr, qty)
item: ItemParty
3.1: ch=next()
ChargerParty
ChargerParty
3.2: cost(qty,unitPr,item)
additionalCharges(…){
Integer total;
forall ch in charges{
total = total + ch.cost(…)}
return total}
ch: ChargerParty
14
P2
P3
P1
APPL
1
C1
C1
C4
C5
C2
C3
APPL
C4
C5
C2
C3
15
1
 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
16
minimal
assumptions on
application structure
P1
P2
P3
+
expected interfaces
P
P1
written to the ICG
similar to an OO
program written
to a concrete class
graph
main-entry
meth
... 1,1
meth
1,k
main control
flow of the
collaboration
P3
meth
3,1
...
meth
3,j
17
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); }
18
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; }
}
19
participant-to-class
name map
P2
P1
P1
main-entry
m
1,1
..
m.
1,k
P3
expected interface
name map
link-to-paths
map
20
HWAppl::+
{float regularPrice() = Pricing with {
LineItemParty = Quote;
Pricing APPC
PricerParty = HWProduct {
basicPrice = regPrice;
discount = regDiscount };
ItemParty = HWProduct;
ChargerParty = Tax ;}
Quote
cust
Customer
prod
HWProduct
taxes
Tax
Tax
Tax
Tax
21
HWAppl::+
{float negotiatedPrice() = Pricing with {
LineItemParty = Quote;
Pricing APPC
PricerParty = Customer {
basicPrice = negProdPrice;
discount = negProdDiscount };
ItemParty = HWProduct;
ChargerParty = Tax;}
Quote
prod
HWProduct
taxes
cust
Customer
Tax
Tax
Tax
Tax
22
higher-level collaboration
lower-level collaboration
23
24
25
26
may be any of the
pricing schemes
OrderParty
LineItemParty
LineItemParty
float
price()
float price()
total()
:OrderParty
1:lineItem = next()
:LineItemParty
2: price()
lineItem :LineItemParty
27
Expected interface of one APPC mapped to main entry of another APPC.
APPC Total {
HWAppl ::+ {float totalReg =
Interface-Class-Graph:
Total with {
OrderParty = Order;
LineItemParty = Quote
OrderParty = <customer> Customer
<lineItems> SetOf(LineItemParty)
LineItemParty { float price(); }
}
{price = regularPrice};
Behavior-Definition:
OrderParty {
main-entry float total()
{
...
while lineItems.hasElements()) {
total += nextLineItem.price(); }
return total; }
}
}
Pricing APPC
HWAppl::+
{float regularPrice() =
Pricing with { . . . }
28
incrementally refine entire collaborations
similar to individual classes
base collaboration
refinement
29
price() {
discount = pricer.discount(item, qty, cust);
unitPr = basicPr - (discount * basicPr);
if (item.stockTime() > item.stockTimeLimit()
{quotePr := quotePr - quotePr * 0.1;}
return quotePr;}
price()
1: basicPrice (item)
2: discount(item, qty,cust)
lineItem: LineItemParty
4. stockTime
5. stockTimeLimit
pricer: PriceServerParty
3: additionalCharges(unitPr, qty)
item: ItemParty
3.1: ch=next()
3.2: cost(qty,unitPr,item)
ChargerParty
ChargerParty
ch: ChargerParty
30
price() {
basicPr = pricer.basicPrice(item);
...
if (customer.frequent()) {
hist = customer.get History();
freqRed = item.freqReduction(hist);
quotePr = quotePr * freqRed}
return quotePr;}
1: basicPrice (item)
2: discount(item, qty,cust)
price()
lineItem: LineItemParty
5. freqReduction()
pricer: PriceServerParty
3: additional
Charges(unitPr, qty)
customer: Customer
item: ItemParty
3.1: ch=next()
ChargerParty
ChargerParty
4. history()
3.2: cost(qty,unitPr,item)
ch: ChargerParty
31
(a) reuse refinements with different bases
base collaboration
refinement
32
(a) reuse refinements with different bases
base collaboration
refinement
33
(b) combine several refinements of the
same base without conflicts
refinement
refinement
base collaboration
refinement
34
Pricing
AgingPricing
FrequentCustomer
Pricing
Aging&FrequentCustomer
Pricing
35
 mixin-like behavior definition
AgingPricing modifies Pricing {
LineItemParty {
price() {
super.price();
super not
statically
bound
reducedPrice(...); }
reducedPrice(...); } }
36
 mixin-like behavior definition (late binding of super)
AgingPricing modifies
Pricing {
price() { . . . super . . .}
AgingPricing modifies
Pricing {
price() { . . . super . . .}
}
}
Pricing APPC
FrequentPricing modifies
Pricing {
price() { . . . super . . .}
}
Pricing APPC
37
 static declaration of the assumed specialization interface
AgingPricing modifies Pricing {
price() { . . . super . . .
. . . reducedPrice}
}
reducedPrice();
FrequentPricing modifies Pricing {
price() { . . . super . . .
. . . reducedPrice }
}
reducedPrice()
Pricing APPC
38
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
39
Separate compilation and Java Beans as underlying
implementation technology
Formal semantics
Library of APPCs to investigate their suitability in
supporting component-oriented programming
40
Adaptive
Programming
Rondo
APPCs
visitor pattern (GOF)
role modeling with template classes (VanHilst & Notkin)
mixin-layers (Smaragdakis & Batory)
contracts (Holland)
AOP (Kiczales & Lopes):
SOP (Harrison & Ossher)
41
42