1. Adaptive Plug and Play Components for
Evolutionary Software Development
Mira Mezini
University of Siegen
Karl Lieberherr
Northeastern University

2. No language constructs that capture collaborations
Motivation
OOAD
Collab-1 Z C1 C4 C2 C3 C5
Collab-4
Collab-2
Collab-3 C1 C2 C3 C4 C5
Object-oriented languages do not provide adequate constructs to capture
collaborations between several classes.
Has been recognized in different forms in the object-oriented community:
OO accommodates the addition of new variants of data types better than
procedural programming but, the opposite is true when new operations on existing
data types are needed
visitor pattern: the matter of concern -- definition of new operations on
an existing object structure (aggregation is involved besides inheritance)
several works complain the lack of constructs for expressing
collaboration-based designs
Implementation
Collaboration --
a distinct (relatively independent aspect of an application that involves several
participants, or roles
roles played by application classes
each class may play different roles in different collaborations
each role embodies a separate aspect of the overall class behavior
--> Tangling
Collaboration-based design s Require to view oo applications in two different ways:
(a) in terms of participants or types involved
(b) in terms of the tasks or concerns of the design

3. “OO technology has not met its expectations
What is the problem?
“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
What is the problem?
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
Collaborations are not explicit in the software. This is what APPCs will support. So why?

5. Both difficult without constructs that capture
What is the problem?
Both difficult without
constructs that capture
collaborations C1 C2 C3 C4 C5
Collaborations are not explicit in the software. This is what APPCs will support. So why?

6. During implementation separate collaborations are mixed together
What is the problem?
During implementation
separate collaborations
are mixed together
in den vorherigen Kapiteln wurde erklärt:
1. in der Informatik darum, Rechnermodelle zu bauen, die Prozessen in der
reellen Welt simulieren.
2. Es gibt formale Mitteln, die es erlauben, die Modelle in eine für den
Rechner verständlich en Sprache zu schreiben.t.
In dieser Vorlesung erden wir das sogenannte objekt-orientierte Programmiermodel als das Mittel für die Beschreibung der Modelle benutzen.
Mit anderen Worten, werden wir objekt-orientierte Rechnermodelle der reellen
Welt bauen. Wir werden zuerst, die Konstrukte des objekt-orientierten Programmiermodels kennenlernen, d.h. die Bestandteile unsere Toolboxes.
Als zweites werden wir kurz
During maintenance individual
collaborations need to be
factored out of the tangled code

7. Unit of reuse is generally not a class, but a slice of behavior
What is the problem?
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?
Collaborations are not explicit in the software. This is what APPCs will support. So why?

8. “because frameworks are described with programming
What is the problem?
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]
Collaborations are not explicit in the software. This is what APPCs will support. So why?

9. So, what? Forget about objects? What is the problem? C1 C4 C2 C3 C5
Collaborations are not explicit in the software. This is what APPCs will support. So why?

10. No. The point is merely that objects are too low-level.
What is the problem?
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
Collaborations are not explicit in the software. This is what APPCs will support. So why?
Let’s organize. Let’s have components on top of them.

11. Design Goals: Adaptiveness
one generic
collaboration P3 P1
reused
APPL 1 C1 C1
APPL C2 C4 n C2
Requirements on the design:
Generic specification of the collaboration with respect to the class
structure it will be applied to: \
(a) the same component to be used with several different
concrete applications, and
(b) one 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 C3 C3 C4 C5
with a family of concrete applications

12. origine: an application generator from IBM (‘70)
But, why adaptive? An example ...
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
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
consider the pricing component ...

13. But, why adaptive? An example ...
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)
pricing component: class diagram

14. design applies to several applications with different classes playing
But, why adaptive? An example ...
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
price()
1: basicPrice (item)
2: discount(item, qty,cust)
lineItem: LineItemParty
pricer: PriceServerParty
3: additionalCharges(unitPr, qty)
additionalCharges(…){
Integer total;
forall ch in charges{
total = total + ch.cost(…)}
return total}
design is fairly simple
complexity is a problem with this application generator’s component, though:
the pricing component is described in nearly twenty pages of the
installation guide
the complexity results from numerous, and arbitrary, pricing schemes in
use by industry and by the representation of these schemes in the system
item: ItemParty
3.2: cost(qty,unitPr,item)
3.1: ch=next()
ChargerParty
pricing component:
collaboration diagram
ChargerParty
ch: ChargerParty

15. Design Goals: Adaptiveness
one generic
collaboration P3 P1
reused
with different mappings
of participants to classes
APPL 1 C1
APPL C1 1 C4 C4 C5 C5 C2 C3 C2 C3
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
of the same application

16. But, why adaptive? An example ...
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. + ... How do APPCs look like? expected interfaces minimal
assumptions on
application structure +
Interface Class Graph P1 P2 P3
Behavior Definition P P1
main-entry
main control flow of the collaboration
written to the ICG similar to an OO program written
to a concrete class graph
meth
1,1
...
meth
1,k P3
meth
3,1
...
meth
3,j

18. How do APPCs look like? APPC Pricing { // class diagram
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: How do APPCs look like?
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. How do I plug APPCs into the applications?
participant-to-class
name map
Interface Class Graph
Structure P1
expected interface
name map P2 P3
link-to-paths
map
Behavior Definition
main-entry P1 m
1,1
... m
1,k
adaptive compiler
(CG-to-ICG compatability?)
executable
Java code

21. How do I plug APPCs into the applications?
Map 1
Application
Structure
HWAppl::+
{float regularPrice() = Pricing with {
LineItemParty = Quote;
PricerParty = HWProduct {
basicPrice = regPrice;
discount = regDiscount };
ItemParty = HWProduct;
ChargerParty = Tax ;}
prod
Quote
HWProduct
cust
taxes
Pricing APPC
Tax
Customer
Tax
Tax
Tax
adaptive compiler
(CG-to-ICG compatability?)

22. How do I plug APPCs into the applications?
Map 2
HWAppl::+
{float negotiatedPrice() = Pricing with {
LineItemParty = Quote;
PricerParty = Customer {
basicPrice = negProdPrice;
discount = negProdDiscount };
ItemParty = HWProduct;
ChargerParty = Tax;}
Application
Structure
prod
HWProduct
Quote
cust
taxes
Pricing APPC
Tax
Customer
Tax
Tax
Tax
adaptive compiler
(CG-to-ICG compatability?)

23. higher-level collaboration lower-level collaboration
Design Goals: Plug and Play
1. black-box composition
higher-level collaboration
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
lower-level collaboration

24. Design Goals: Plug and Play
1. black-box composition P1 P2 P3 P6 P5 P4
Collaborations are not explicit in the software. This is what APPCs will support. So why?

25. Design Goals: Plug and Play
1. black-box composition
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
. . . decoupled

26. Design Goals: Plug and Play
1. black-box composition
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
. . . decoupled

27. Why decoupled black-box composition?
may be any of the
pricing schemes
OrderParty
LineItemParty
LineItemParty
float price()
total()
float price()
:OrderParty
1:lineItem = next()
2: price()
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?
:LineItemParty
lineItem :LineItemParty

28. How do I compose APPCs?
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. incrementally refine entire collaborations
Design Goals: Plug and Play
2. white-box composition
incrementally refine entire collaborations
similar to individual classes
base collaboration
refinement
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''.

30. Why white-box composition?
e.g. AgingPricing
could have different pricing refinements
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;}
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)
design is fairly simple
complexity is a problem with this application generator’s component, though:
the pricing component is described in nearly twenty pages of the
installation guide
the complexity results from numerous, and arbitrary, pricing schemes in
use by industry and by the representation of these schemes in the system
3.1: ch=next()

31. Why white-box composition?
e.g. FrequentCustomerPricing
could have different pricing refinements
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
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)
design is fairly simple
complexity is a problem with this application generator’s component, though:
the pricing component is described in nearly twenty pages of the
installation guide
the complexity results from numerous, and arbitrary, pricing schemes in
use by industry and by the representation of these schemes in the system

32. (a) reuse refinements with different bases
Design Goals: Plug and Play
2. white-box composition
. . . but decoupled
(a) reuse refinements with different bases
base collaboration
refinement
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''.

33. (a) reuse refinements with different bases
Design Goals: Plug and Play
2. white-box composition
. . . but decoupled
(a) reuse refinements with different bases
base collaboration
refinement
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?

34. (b) combine several refinements of the same base without conflicts
Design Goals: Plug and Play
2. white-box composition
. . . but decoupled
(b) combine several refinements of the
same base without conflicts
refinement
base collaboration
OK, we want a construct
(1) orthogonal to the standard object-oriented models -
not substitute, rather complement classes
(2) support a decomposition granularity that lies between classes and package
modules a la Oberon
But, what do we mean by adaptive?

35. Aging&FrequentCustomer
Why decoupled white-box composition?
could have different pricing refinements
or combinations of the latter
Pricing
FrequentCustomer
Pricing
AgingPricing
design is fairly simple
complexity is a problem with this application generator’s component, though:
the pricing component is described in nearly twenty pages of the
installation guide
the complexity results from numerous, and arbitrary, pricing schemes in
use by industry and by the representation of these schemes in the system
Aging&FrequentCustomer
Pricing

36. super not statically bound
How does white-box composition of APPCs work?
mixin-like behavior definition
super not
statically
bound
AgingPricing modifies Pricing {
LineItemParty {
price() {
super.price();
reducedPrice(...); }
reducedPrice(...); } }

37. } } } How does white-box composition of APPCs work?
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

38. } } How does white-box composition of APPCs work?
static declaration of the assumed specialization interface
AgingPricing modifies Pricing {
price() { super . . .
. . . reducedPrice}
reducedPrice(); }
FrequentPricing modifies Pricing {
price() { super . . .
. . . reducedPrice }
reducedPrice() }
Pricing APPC

39. Larger-grained constructs that complement classes
Summary
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

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

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

42. Still questions ?!