oopsla98

Contents: 

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

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: 

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: 

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.

Slide6: 

C1 C2 C3 C4 C5 Collab-1 Collab-2 Collab-3 Collab-4 C1 C2 C3 C4 C5 OOAD Implementation

Slide7: 

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]

Slide8: 

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]

Slide9: 

C1 C2 C3 C4 C5 P1 P2 P3 C1 C3 C2 C4 APPL 1 APPL n

Slide10: 

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

Slide11: 

C1 C2 C3 C4 C5 P1 P2 P3 APPL 1 APPL 1 C2 C3 C4 C5 C1

Slide12: 

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.

Slide13: 

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

Slide14: 

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)

Slide15: 

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

Slide16: 

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.

Slide17: 

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

Slide18: 

base collaboration - incrementally refine whole collaborations similar to individual classes

Slide19: 

- reuse refinements with different bases

Slide20: 

- combine several refinements of the same base base collaboration

Slide23: 

Pricing AgingPricing FrequentCustomer Pricing Aging&FrequentCustomer Pricing

Slide24: 

higher-level collaboration lower-level collaboration

Slide25: 

LineItemParty :LineItemParty LineItemParty float price() LineItemParty float price() OrderParty :OrderParty LineItemParty :LineItemParty lineItem :LineItemParty 1:lineItem = next() 2: price() total()

Slide26: 

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

Slide28: 

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

Slide29: 

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

Slide30: 

P1 main-entry ... C1 C2 C4 C3 participant-to-class name map expected interface name map link-to-path map

Slide31: 

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

Slide32: 

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

Slide33: 

Pricing price AgingPricing SpecialPricing price FrequentCustomerPricing SpecialPricing price AgingDelta FrequentCustomerDelta reducedPrice reducedPrice AgingPricing SpecialPricing price AgingDelta reducedPrice Pricing price AgingPolicy = AgingDelta + Pricing AgingDelta = AgingPricing + SpecialPricing AgingAndFrequentCustomerPolicy = AgingDelta + FrequentCustomerDelta + Pricing FrequentCustomerDelta = FrequentCustomerPricing + SpecialPricing AgingPolicy AgingAndFrequentCustomerPolicy

Slide34: 

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

Slide35: 

visitor pattern (GOF) role modeling with template classes (VanHilst & Notkin) mixin-layers (Smaragdakis & Batory) contracts (Holland) SOP (Harrison & Ossher) Aspect-oriented programming: AP = AOP with strategy graphs

Slide36: 

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

Subject-Oriented ProgrammingHow are APPCs different? : 

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 ProgrammingHow are APPCs different? : 

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: 

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

Slide40: 

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

Slide41: 

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

Roles graphs play in OODunder refinement relations: 

Roles graphs play in OOD under 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.

Roles graphs play in OODunder refinement relations: 

Roles graphs play in OOD under refinement relations PSG PSG subtraversal

Roles graphs play in OODunder refinement relations: 

Roles graphs play in OOD under refinement relations

Applications of strategy graphs: 

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: 

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: 

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)

Key concepts: 

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

Key concepts: 

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: 

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.

Strategies, constraint map: 

Strategies, constraint map For all 0<i<n+1, Source(pi)=N(ai-1) and Target(pi)= N(ai).

Slide52: 

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

Key concepts: 

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

Slide54: 

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

Key concepts: 

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: 

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

Slide57: 

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

Key concepts: 

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

Slide59: 

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

Slide60: 

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

Slide61: 

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

Demeter/Java: 

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: 

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: 

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: 

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: 

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: 

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: 

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: 

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