Adaptive Plug and Play Components for Evolutionary Software Development Mira Mezini University of Siegen mira@informatik.uni-siegen.de Karl Lieberherr Northeastern University lieber@ccs.neu.edu

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

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

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

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.

What's the problem? TANGLING OOAD Z customer service center teller service self-service Collab-1 C1 C4 C2 C3 C5 Collab-4 Collab-2 Collab-3 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 C1 C4 C2 C3 Implementation C5 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 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

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] Collaborations are not explicit in the software. This is what APPCs will support. So why?

through a soda straw'’ 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]

one generic collaboration Adaptive? one generic collaboration P2 P3 P1 reused APPL 1 C1 C1 APPL C2 C4 n C2 C3 C3 C4 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? C5 with a family of concrete applications

G1 refinement G2 Concrete:G1 F F D D E E B B C C Generic:G2 A A refinement: connectivity of G2 is in G1 and G1 contains no new connections in terms of nodes of G2 A A

one generic collaboration Adaptive? one generic collaboration P2 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 concrete application

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.

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

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

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 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.2: cost(qty,unitPr,item) 3.1: ch=next() ChargerParty ChargerParty ch: ChargerParty pricing component: collaboration diagram

But, why adaptive? Well, let me explain by an example ... design is fairly simple complexity is a problem with this application generator’s 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.

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

1. decoupled white-box composition Plug and Play? 1. decoupled white-box composition - incrementally refine whole collaborations similar to individual classes 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?

1. decoupled white-box composition Plug and Play? 1. decoupled white-box composition - 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?

1. decoupled white-box composition Plug and Play? 1. decoupled white-box composition - combine several refinements of the same base refinement 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? refinement

Why decoupled white-box composition? could have different pricing refinements e.g. AgingPricing 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.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;} 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

Why decoupled white-box composition? could have different pricing refinements 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) price() { basicPr = pricer.basicPrice(item); . . . return quotePr;} e.g. FrequentCustomerPricing 4. history() 5. freqReduction() if (customer.frequent()) { hist = customer.get History(); freqRed = item.freqReduction(hist); quotePr = quotePr * freqRed} customer: Customer 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 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

higher-level collaboration lower-level collaboration Plug and Play? 2. decoupled 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

2. decoupled black-box composition Plug and Play? 2. decoupled black-box composition 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 LineItemParty lineItem :LineItemParty :LineItemParty LineItemParty

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

+ What do APPCs look like? Interface Class Graph Behavior Definition expected interfaces minimal assumptions on the structure of the applications + written to the ICG similar to an OO program written to a concrete class graph Behavior Definition P 1 main-entry 3 m 1,1 1,k ... 3,1 3,j P2 P3 main control flow of the collaboration

What do APPCs look like? 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); }

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

How do I attach APPCs to applications? participant-to-class name map Interface Class Graph Application C1 expected interface name map P2 P3 P1 C4 link-to-path map Behavior Definition C2 C3 P 1 main-entry m 1,1 ... m 1,k adaptive compiler (CG-to-ICG compatability?) executable Java code

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 Quote HWProduct cust taxes Pricing APPC Tax Customer Tax Tax Tax adaptive compiler (CG-to-ICG compatability?)

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 Quote HWProduct cust taxes Pricing APPC Tax Customer Tax Tax Tax adaptive compiler (CG-to-ICG compatability?)

How does white-box composition of APPCs work? AgingPricing SpecialPricing Pricing AgingPolicy = AgingDelta + Pricing AgingDelta = AgingPricing + SpecialPricing reducedPrice price price AgingDelta AgingPolicy AgingPricing SpecialPricing FrequentCustomerPricing SpecialPricing Pricing price price price reducedPrice reducedPrice AgingDelta FrequentCustomerDelta AgingAndFrequentCustomerPolicy AgingAndFrequentCustomerPolicy = AgingDelta + FrequentCustomerDelta + Pricing FrequentCustomerDelta = FrequentCustomerPricing + SpecialPricing

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

Related Work SOP (Harrison & Ossher) visitor pattern (GOF) Adaptive Programming Rondo APPCs 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

Future Work Implement APPCs using Java Beans Formal semantics of APPCs Develop a library of APPCs to replace an existing framework

Subject-Oriented Programming How 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.

Subject-Oriented Programming How 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)

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

G1 compatible G2 F F D D E E B B C C G2 G1 A A Compatible: connectivity of G2 is in G1 G1 A A

G1 refinement G2 F F D D E E B B C C G2 G1 A A refinement: connectivity of G2 is in G1 and G1 contains no new connections in terms of nodes of G2 G1 A A

Roles graphs play in OOD under refinement relations Small graph G PSG Big graph G PSG G: class graph (CG) or interface class graph (ICG). ICG is a view on a class graph. PSG: positive strategy graph.

Roles graphs play in OOD under refinement relations PSG PSG subtraversal

Roles graphs play in OOD under refinement relations

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

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

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)

Strategy graph and base graph are directed graphs 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.

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)

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 = <a0 a1 … an>, 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 0<i<n+1, Source(pi)=ai-1 and Target(pi)= ai. 9/20/2018 AOO/Demeter

Strategies, constraint map For all 0<i<n+1, Source(pi)=N(ai-1) and Target(pi)= N(ai). 9/20/2018 AOO/Demeter

PathSet(G , S) F=t F D D E E B B C C S G A = s A

Strategy graph and base graph are directed graphs 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). Surprise?: co-NP-complete

G1 path-set-refinement G2 B=t B G2 X Y A=s G1 A

Strategy graph and base graph are directed graphs 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. Surprise? Co-NP-complete. Equivalent to path-set-refinement

Strategy graph and base graph are directed graphs 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.

G1 path-set-refinement G2 G1 expansion G2 B=t B G2 X Y A=s G1 A

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

Refinement means: no surprises not G1 refinement G2 G1 expansion G2 B C C B G2 A G1 A

Refinement means: no surprises G1 refinement G2 B C C B X G2 A G1 A

Refinement means: no surprises G1 expansion G2 not G1 refinement G2 B C B C G1 G2 A A

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

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

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

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

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

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

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

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

Still questions ?!