Kein Folientitel

1
Adaptive Plug and Play Components for
Evolutionary Software Development
Mira Mezini University of Siegen mira_at_informatik.u
ni-siegen.de
Karl Lieberherr Northeastern University lieber_at_ccs
.neu.edu
2
Contents

• Overview of our approach to encapsulate reusable
  collaborative behavior (e.g., business rules)
  basics of APPCs.
• Some graph theory behind APPCs and adaptive
  programming in general.
• Future work
• Conclusions

3
IBM connections for ingredients to adaptive
plug-and-play components (APPCs)

• Some ingredients
• 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

4
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
5
IBM San Francisco Project
Benefits of Commands The 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.
6
What's the problem? TANGLING
OOAD
Collab-1
C1
C4
C2
C3
C5
Collab-4
Collab-2
Collab-3
C1
C4
C2
C3
Implementation
C5
7
What's the problem?
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
8
What's the problem?
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
9
Adaptive?
one generic collaboration
P2
P3
P1
reused
APPL
1
C1
C1
APPL
C2
C4
n
C2
C3
C3
C4
C5
with a family of concrete applications
10
G1 refinement G2
ConcreteG1
F
F
D
D
E
E
B
B
C
C
GenericG2
refinement connectivity of G2 is in G1 and G1
contains no new connections in terms of nodes of
G2
A
A
11
Adaptive?
one generic collaboration
P2
P3
P1
reused
with different mappings
of participants to classes
APPL
1
C1
APPL
1
C1
C4
C4
C5
C5
C2
C3
C2
C3
of the same concrete application
12
Adaptive?

• 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.

13
But, why adaptive? Well, let me explain by an
example ...

• 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 customers
• specific needs
• customers specific requirements recorded in a
  questionnaire
• the installation guide described the options and
  the consequences associated
• with questions on the questionnaire

consider the pricing component ...
14
But, why adaptive? Well, let me explain by an
example ...
PriceServerParty
LineItemParty
float basicPrice(ItemParty item) Integer
discount(ItemParty item, Integer qty, Customer
cust)
quantity
ItemParty
Float additionalCharges(Float unitPrice Integer
qty)
Customer
ChargerParty
ChargerParty
Float cost(Integer qty, Float unitPrice,
ItemParty item)
pricing component class diagram
15
But, why adaptive? Well, let me explain by 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
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
item ItemParty
3.2 cost(qty,unitPr,item)
3.1 chnext()
ChargerParty
ch ChargerParty
ChargerParty
pricing component collaboration diagram
16
But, why adaptive? Well, let me explain by an
example ...

• design is fairly simple
• complexity is a problem with this application
  generators component, though
• the complexity results from numerous, and
  arbitrary, pricing schemes in
• use by industry and by the representation of
  these schemes in the system. The
• price 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.

17
But, why adaptive? Well, let me explain by an
example ...

• 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

18
Plug and Play?
1. decoupled white-box composition
- incrementally refine whole collaborations
similar to individual classes
base collaboration
19
Plug and Play?
1. decoupled white-box composition
- reuse refinements with different bases
20
Plug and Play?
1. decoupled white-box composition
- combine several refinements of the same base
base collaboration
21
(No Transcript)
22
(No Transcript)
23
or combinations of the latter
Pricing
FrequentCustomer Pricing
AgingPricing
AgingFrequentCustomer Pricing
24
Plug and Play?
2. decoupled black-box composition
higher-level collaboration
lower-level collaboration
25
Plug and Play?
2. decoupled black-box composition
OrderParty
LineItemParty
LineItemParty
float price()
total()
float price()
OrderParty
1lineItem next()
2 price()
LineItemParty
LineItemParty
lineItem LineItemParty
LineItemParty
LineItemParty
26
Plug and Play?

• 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''.

27
What do APPCs look like?
28
What do APPCs look like?
APPC Pricing Interface Class Graph
// structural interface
LineItemParty ltitemgt ItemParty ltpricergt
PricerParty ltcustomergt Customer ItemParty
ltchargesgt 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)
29
What do APPCs look like?
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
30
How do I attach APPCs to applications?
participant-to-class name map
Interface Class Graph
Application
C1
expected interface name map
P1
C4
link-to-path map
Behavior Definition
C2
C3
main-entry
...
adaptive compiler (CG-to-ICG compatability?)
executable Java code
31
How do I attach Pricing APPC to applications?
Map 1
HWAppl float regularPrice() Pricing
with LineItemParty Quote
PricerParty HWProduct basicPrice
regPrice discount regDiscount
ItemParty HWProduct ChargerParty
Tax cost taxCharge
Application
prod
HWProduct
Quote
cust
taxes
Pricing APPC
Tax
Customer
Tax
Tax
Tax
adaptive compiler (CG-to-ICG compatability?)
32
How do I attach Pricing APPC to applications?
Map 2
HWAppl float regularPrice() Pricing
with LineItemParty Quote
PricerParty Customer
basicPrice negProdPrice
discount negProdDiscount ItemParty
HWProduct ChargerParty Tax cost
taxCharge
Application
prod
HWProduct
Quote
cust
taxes
Pricing APPC
Tax
Customer
Tax
Tax
Tax
adaptive compiler (CG-to-ICG compatability?)
33
How does white-box composition of APPCs work?
AgingPricing
SpecialPricing
Pricing
AgingPolicy AgingDelta Pricing
AgingDelta AgingPricing SpecialPricing
price
reducedPrice
price
AgingDelta
AgingPolicy
AgingPricing
SpecialPricing
FrequentCustomerPricing
SpecialPricing
Pricing
price
price
price
reducedPrice
reducedPrice
AgingDelta
FrequentCustomerDelta
AgingAndFrequentCustomerPolicy
AgingAndFrequentCustomerPolicy AgingDelta
FrequentCustomerDelta Pricing
FrequentCustomerDelta FrequentCustomerPricing
SpecialPricing
34
How does black-box composition of APPCs work?
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 ltcustomergt Customer
ltlineItemsgt 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

35
Related Work
SOP (Harrison Ossher)
visitor pattern (GOF)
role modeling with template classes (VanHilst
Notkin)
mixin-layers (Smaragdakis Batory)
contracts (Holland)
Aspect-oriented programming AP AOP with
strategy graphs
36
Future Work
Implement APPCs using Java Beans
Formal semantics of APPCs
Develop a library of APPCs to replace an existing
framework
37
Subject-Oriented ProgrammingHow are APPCs
different?

• Both subjects and APPCs use the idea of an
  interface class graph
• subjects only inheritance edges
• 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.

38
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)

39
Underlying ideas

• Graph1 refinement Graph2
• Graphs can play the following roles
• interface class graph
• (application) class graph
• positive strategy graph
• have a source and a target

40
G1 compatible G2
F
F
D
D
E
E
B
B
C
C
G2
Compatible connectivity of G2 is in G1
G1
A
A
41
G1 refinement G2
F
F
D
D
E
E
B
B
C
C
G2
refinement connectivity of G2 is in G1 and G1
contains no new connections in terms of nodes of
G2
G1
A
A
42
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.
43
Roles graphs play in OODunder refinement
relations
PSG PSG
subtraversal
44
Roles graphs play in OODunder refinement
relations
45
Applications of strategy graphs

• Specify mapping between graphs (adaptors)
• 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 Strategy graphs, 1997 NU
  TR
• Lieberherr/Patt-Shamir Dagstuhl 98 Workshop on
  Generic Programming (LNCS)

48
Key concepts
Strategy graph and base graph are directed graphs

• 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.

49
Key concepts

• A path p in G is an expansion of path p in S if
  OrderedNodes(p) can be obtained by deleting some
  elements from OrderedNodes(p).
• OrderedNodes(p) is the ordered sequence of nodes
  in p in the order the nodes appear in p.
• Recall Nodes(S) ? Nodes(G)

50
Strategies, constraint map

• Let S be a strategy graph, let G be a base graph
  with Nodes(S) ? Nodes(G). Given a strategy-graph
  path p lta0 a1 angt, we say that a path p in
  G is a expansion of p if there exist paths p1,
  ,pn in G such that p p1 . p2 pn and For all
  0ltiltn1, Source(pi)ai-1 and Target(pi) ai.

51
Strategies, constraint map

• For all 0ltiltn1, Source(pi)N(ai-1) and
  Target(pi) N(ai).

52
PathSet(G , S)
Ft
F
D
D
E
E
B
B
C
C
S
G
A s
A
53
Key concepts
Strategy graph and base graph are directed graphs

• 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).
• Surprise? co-NP-complete

54
G1 path-set-refinement G2
Bt
B
G2
X
Y
As
G1
A
55
Key concepts
Strategy graph and base graph are directed graphs

• 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.
• Surprise? Co-NP-complete. Equivalent to
  path-set-refinement

56
Key concepts
Strategy graph and base graph are directed graphs

• 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.

57
G1 path-set-refinement G2 G1 expansion G2
Bt
B
G2
X
Y
As
G1
A
58
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.
• Polynomial. Implies path-set-refinement and
  expansion

59
Refinement means no surprises
not G1 refinement G2
G1 expansion G2
B
C
C
B
G2
A
G1
A
60
Refinement means no surprises
G1 refinement G2
B
C
C
B
X
G2
A
G1
A
61
Refinement means no surprises
G1 expansion G2 not G1 refinement G2
B
C
B
C
G1
G2
A
A
62
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

63
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

64
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

65
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

66
Tendril Software

• Sequence Graph
• Actions Execute, Find, Add, Delete, etc. (only a
  few more)
• parameterized by code fragments
• Currently a tree, order on edges determines code
  generation order.
• Object transportation based on variable names
• variable used as output is available in any
  action that comes later in the sequence graph

67
Tendril Software

• Unique approach to make UML sequence diagrams not
  only documentation but useful for specifying
  code.
• Download product from www.tendril.com
• Connection
• APPCs formalize collaboration diagrams
• Sequence graphs formalize sequence diagrams

68
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

69
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

70
Still questions ?!