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

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

“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]

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?

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?

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

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?

“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?

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?

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

(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?

(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?

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

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

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

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

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

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

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)

Still questions ?!