Nested Collaborations

Collaboration reuse We want to reuse collaborations at two levels: Refined collaborations similar to is-a relationship between classes Nested collaborations similar to has-a relationship between classes This idea was already in contracts (Helm, Holland et al.) and in Holland’s thesis.

Boolean Collaborations Collaboration is trivial: only one participant Example is realistic because we want to record the result history. Example indicates that each subcollaboration should be represented by an object. Only in special cases can collaborations be implemented by code insertion only.

Recording And Collaboration collaboration And { participant D { boolean res; public Vector r = new Vector();// result history public boolean andR() { res = input1() and input2(); r.append(new Boolean(res); return res;} expect boolean input1(); expect boolean input2(); } Each time andR() is called, return value will be stored in a vector local to participant D.

Recording Or Collaboration collaboration Or { participant D { boolean res; public Vector r = new Vector();// result history public boolean orR() { res = input1() or input2(); r.append(new Boolean(res); return res;} expect boolean input1(); expect boolean input2(); } Each time orR() is called, return value will be stored in a vector local to participant D.

Compose Collaborations And AndOr Or

collaboration AndOr { participant D { expect boolean input1(); expect boolean input2(); expect boolean input3(); public boolean andOrR() {return AndAdapter.D.andR();} public void andOrStatistics() { System.out.println(AndAdapter.D.r(true); System.out.println(AndAdapter.D.r(false); System.out.println(OrAdapter.D.r(true); System.out.println(OrAdapter.D.r(false); } adapter AndAdapter { AndOr.D plays And.D { boolean input1() {return AndOr.D.input1();} boolean input2() {return OrAdapter.D.orR();}}} adapter OrAdapter { AndOr.D plays Or.D { boolean input1() {return AndOr.D.input2();} boolean input2() {return AndOr.D.input3();}}}

Conflict with Result Vector? No: each adapter has its own

Hardware-style Components Can be expressed with nested collaborations Adapters are used to instantiate components It is important to name adapters How should collaborations be implemented? Adapted collaborations should be represented as objects.

Methods versus Signals The model we use uses methods for input. An alternative model would be to use signals on ports.

Counting Collaboration Have CountingAdapter.BusRoute Adapter creates adapter object When count() is invoked, count() on adapter object is invoked? BusRoute.count() calls CountingAdapter.BusRoute.count(). But we might have another adapter. Need to rename count in adapter in that case.

Better example Pricing and Summing: add Order participant to participant graph of Pricing. Call it OrderPricing because it computes the cost of an order not just of a line item. Both negotiated and regular price. Mapping for Pricing is identity? Mapping for Summing is Source -> Order, Target -> LineItem.

LineItemPricing example collaboration LineItemPricing { private int qty; private float unitPrice; participant LineItem { //OrderUnit abstract Product getProduct(); // abstract instead of expect abstract Pricer getPricer(); abstract Customer getCustomer(); abstract int getQuantity(); public float price() { qty = getQuantity(); prod = getProduct(); k = getCustomer(); unitPrice = getPricer().unitPrice(prod, k); float price = unitPrice + getProduct().extraCosts(); return price; } Expected Interface Beilspil SAP und Telecom Australia Provided Interface LineItem = Product Pricer Customer <quantity> int. Product = List(ExtraCost). Customer = . Pricer = . ExtraCost = .

abstract ExtraCost[] getExtraCosts(); private float extraCosts() { participant Product { abstract ExtraCost[] getExtraCosts(); private float extraCosts() { float total = 0; while (getExtraCosts().hasElement()) total =+ getExtraCosts().next().getAmount(qty, unitPrice, this); return total; } } participant Pricer { abstract float getBasicPrice(Product prod); abstract float getDiscount(Product prod, Customer k); private float unitPrice(Product prod, Customer k) { float basicPr = getBasicPrice(prod); return basicPr - (getDiscount(prod, k) * basicPr);} participant ExtraCost{ abstract float getAmount(int qty, float unitPrice, Product prod); Beilspil SAP und Telecom Australia

LineItemPricing added and modified behavior LineItemPricing pg pg’

OrderPricing Source Summing Order Target LineItem LineItemPricing

Missing: pg for each collaboration OrderPricing Source Summing Order Target LineItem LineItemPricing

OrderPricing PriceForLineItem SumForPrice Order Source sum price ProductCategory Summing LineItem toSum Target OfficeProduct price LineItem LineItemPricing Product Pricer Customer

RPriceForLineItem SumForRPrice NPriceForLineItem SumForNPrice OrderPricing sum rprice Order sum nprice ProductCategory Source Source Summing Summing LineItem toSum toSum Target Target OfficeProduct price price LineItem LineItemPricing LineItem LineItemPricing Product Pricer Customer Product Pricer Customer

Summing Collaboration collaboration Summing { participant Source { expect TraversalGraph getT(); public int sum (){ // traversal/visitor weaving getT().traverse(this, new Visitor(){ int r; public void before(Target host){ r=r+host.toSum(); } public void start() { r = 0;} …) } } participant Target { expect int toSum();} } can we really program with strategies? Here is how. Base: regular Meta variable: bold Keywords: underscore

Composed collaboration OrderPricing // Participant graph: first only for negotiated price, followed by regular // price Order = <productCategories> List(ProductCategory) Customer. ProductCategory = Name List(LineItem). LineItem = OfficeProduct Pricer Customer <quantity> int. OfficeProduct = <extraCosts> List(Tax). Tax = . Customer = . Pricer = . // Customer in Order is transported to Customer in LineItem

Adapter SumForPrice adapter SumForPrice { Order is Summing.Source with { TraversalGraph getT() { ClassGraph classGraph1 = new ClassGraph(); return new TraversalGraph(classGraph1, new Strategy(“from Order to LineItem”));} } LineItem is Summing.Target with int toSum{ NegPriceForOrder.LineItem.price();}

Adapter NegPriceForLineItem LineItem is LineItemPricing.LineItem OfficeProduct is LineItemPricing.Product Customer is LineItemPricing.Pricer with { float getBasicPrice (Product p) { return negotiatedPrice(p);} float getDiscount(Product p, Customer c) { return negotiatedDiscount(p);}} Tax is ExtraCost with { … } }

NegOrderPricing Aspect Pattern collaboration NegOrderPricing { participant Order { public int negPrice (){ SumForPrice.Order.sum();} // participant graph and the adapters SumForPrice and // NegPriceForOrder seen earlier } can we really program with strategies? Here is how. Base: regular Meta variable: bold Keywords: underscore

Now add regular price computation Need a new adapter for summing regular prices: notice need to parameterize adapters Need a new adapter for computing regular price Need to distinguish between two price methods: regPrice and negPrice.

Adapter SumRegForPrice adapter SumForRegPrice { Order is Summing.Source with { TraversalGraph getT() { ClassGraph classGraph1 = new ClassGraph(); return new TraversalGraph(classGraph1, new Strategy(“from Order to LineItem”));} } LineItem is Summing.Target with int toSum{ RegPriceForLineItem.LineItem.price();}

Adapter RegPriceForOrder LineItem is LineItemPricing.LineItem OfficeProduct is LineItemPricing.Product OfficeProduct is LineItemPricing.Pricer with { float getBasicPrice (Product p) { return p.regPrice();} float getDiscount(Product p, Customer c) { return p.regDiscount();}} Tax is ExtraCost with { … } }

OrderPricing Aspect Pattern collaboration OrderPricing { participant Order { public int negPrice (){ SumForPrice.Order.sum();} // participant graph and the adapters SumForPrice and // NegPriceForOrder seen earlier public int regPrice (){ SumForRegPrice.Order.sum();} // participant graph and the adapters SumRegForPrice and // RegPriceForOrder seen earlier } can we really program with strategies? Here is how. Base: regular Meta variable: bold Keywords: underscore

Role of Pricer is once played by Kunde and once by Büromaterial connector NegotiatedPrice { Bestellung is LineItemParty; Kunde is Pricer with { float getBasicPrice (Product p) { return verhandelterPreis (p);} float getDiscount(Product p, Customer c) { return verhandelterDiscount (p);} } Büromaterial is Product with { ExtraCost[] extraCosts () { ... }; } Steuer is Zusatzkosten with { float getAmount (...) { ... }; } connector RegularPrice { Bestellung is LineItemParty; Büromaterial is Pricer with { float getBasicPrice(Product p) { return p.regPreis();} float getDiscount(Product p, Customer c) { return p.regDiscount(c);} }; Büromaterial is Product with { ExtraCost[] extraCosts() { ... }; } Steuer is ExtraCost with { float getAmount (...) { ... }; } } Role of Pricer is once played by Kunde and once by Büromaterial

Need for collaboration composition Need two instances of the summing collaboration. Need to instances of the line item cost collaboration.

Collaborations Collaboration Participant graph: for each participant a provided and required interface Set C of reused collaboration names and the corresponding adapters

Tim Sheard Mark meta variables express meta code show how base code can become meta code

Example : Count Aspect Pattern aspect pattern Counting { participant Source { expect TraversalGraph getT(); public int count (){ // traversal/visitor weaving getT().traverse(this, new Visitor(){ int r; public void before(Target host){ r++; } public void start() { r = 0;} …) } } participant Target {} } can we really program with strategies? Here is how. Base: Meta variable: bold Keywords: underscore

Adapter 1 classGraph1 is fixed and therefore the traversal is fixed adapter CountingForBusRoute1 { BusRoute is Counting.Source with { TraversalGraph getT() { ClassGraph classGraph1 = new ClassGraph(); return new TraversalGraph(classGraph1, new Strategy(“from BusRoute via BusStop to Person”));} } Person is Counting.Target { }

Aspect Pattern Partial Evaluation Because the class graph is fixed for CountingForBusRoute1, it can be frozen and a more efficient specialization can be produced. aspect specialization CountingForBusRoute1 freeze getT() in getT().traverse(…) Visitor constant too!

Aspect pattern example aspect pattern Pricing { private int qty; private float unitPrice; participant LineItemParty { //OrderUnit abstract Product getProduct(); // abstract instead of expect abstract Pricer getPricer(); abstract Customer getCustomer(); abstract int getQuantity(); public float price() { qty = getQuantity(); prod = getProduct(); k = getCustomer(); unitPrice = getPricer().unitPrice(prod, k); float price = unitPrice + getProduct().extraCosts(); return price; } Expected Interface Beilspil SAP und Telecom Australia Provided Interface LineItemParty = Product Pricer Customer <quantity> int. Product = List(ExtraCost). Customer = . ? Pricer = .

abstract ExtraCost[] getExtraCosts(); private float extraCosts() { participant Product { abstract ExtraCost[] getExtraCosts(); private float extraCosts() { float total = 0; while (getExtraCosts().hasElement()) total =+ getExtraCosts().next().getAmount(qty, unitPrice, this); return total; } } participant Pricer { abstract float getBasicPrice(Product prod); abstract float getDiscount(Product prod, Customer k); private float unitPrice(Product prod, Customer k) { float basicPr = getBasicPrice(prod); return basicPr - (getDiscount(prod, k) * basicPr);} participant ExtraCost{ abstract float getAmount(int qty, float unitPrice, Product prod); Beilspil SAP und Telecom Australia

Aspect Patterns: Adapters adapter RegularPrice { Bestellung is LineItemParty; Büromaterial is Pricer with { float getBasicPrice(Product p) { return p.regPreis();} float getDiscount(Product p, Customer c) { return p.regDiscount(c);} }; Büromaterial is Product with { ExtraCost[] extraCosts() { ... }; } Steuer is ExtraCost with { float getAmount (...) { ... }; } } Beilspil SAP und Telecom Australia Price computation Office material vendor Java code

Role of Pricer is once played by Kunde and once by Büromaterial adapter NegotiatedPrice { Bestellung is LineItemParty; Kunde is Pricer with { float getBasicPrice (Product p) { return verhandelterPreis (p);} float getDiscount(Product p, Customer c) { return verhandelterDiscount (p);} } Büromaterial is Product with { ExtraCost[] extraCosts () { ... }; } Steuer is Zusatzkosten with { float getAmount (...) { ... }; } adapter RegularPrice { Bestellung is LineItemParty; Büromaterial is Pricer with { float getBasicPrice(Product p) { return p.regPreis();} float getDiscount(Product p, Customer c) { return p.regDiscount(c);} }; Büromaterial is Product with { ExtraCost[] extraCosts() { ... }; } Steuer is ExtraCost with { float getAmount (...) { ... }; } } Role of Pricer is once played by Kunde and once by Büromaterial

adapter SalesPrice { Bestellung is LineItemParty; Büromaterial is Pricer with { float getBasicPrice(Product p) { return p.salesPrice();} float getDiscount(Product p, Customer c) {return p.salesDiscount(c);} }; Büromaterial is Product with { ExtraCost[] extraCosts() { ... }; } Steuer is ExtraCost with { float getAmount (...) { ... }; } }

Example: Feature-oriented Programming Dependent aspects Order of deployment is relevant

DataWithCounter : pairwise interaction Data/Counter aspect pattern DataWithCounter { private participant Counter { int i=0; void reset(){i=0;}; void inc(){…}; void dec(){…};} participant DataStructure { protected Counter counter; expect void initCounter(); expect void make_empty(); expect void push(Object a); expect void pop(); replace void make_empty(){counter.reset();expected();} replace void push(Object a){counter.inc(); expected(a);} replace void pop() {counter.dec();expected();} }

DataWithCounter : pairwise interaction Data/Counter make_empty push pop make_empty push pop

DataWithLock Pattern pairwise interaction Data/Lock aspect pattern DataWithLock { participant Data { Lock lock; expect void initLock(); expect AnyType method_to_wrap(Object[] args); replace AnyType method_to_wrap(Object[] args) { if (lock.is_unlocked()) { lock.lock(); expected(Object[] args); lock.unlock(); }}} private participant Lock {boolean l = true; void lock(){…}; void unlock(){…}; boolean is_unlocked(){return l}; }

DataWithLock Pattern pairwise interaction Data/Lock method_to_wrap method_to_wrap

DataWithCounter StackImpl Counter QueueImpl DataWithLock Lock 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 QueueImpl DataWithLock Lock

First adapter adapter addCounterAndLock { StackImpl is DataWithCounter.DataStructure with { void initCounter() {counter = new Counter();} void push(Object obj) {push(obj));} // use name map instead Object top() {return top();} ... } StackImpl is DataWithLock.Data method_to_wrap = {pop, push, top, make_empty, initCounter}; }; QueueImpl is DataWithCounter.DataStructure with { ... } is DataWithLock.Data with { ... };

DataWithCounterAndLock DataWithLock DataWithCounterAndLock 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

DataWithCounter : pairwise interaction Data/Counter make_empty push pop make_empty push pop

DataWithLock Pattern pairwise interaction Data/Lock method_to_wrap method_to_wrap

DataWithCounterAndLock pattern composition make_empty push pop make_empty’ push’ pop’ DataWithCounter DataWithLock make_empty’’ push’’ pop’’ to-wrap Name stays the same, but behavior changes Should composed component have its interface computed? Yes?

Method flow diagram Composition of aspect patterns defines method flow Methods come in and out of patterns Patterns may create new methods and absorb methods Graph: nodes are pattern, edges are methods What about participant graph? Participant name part of method name. Should nodes have ports? Multiple edges in, multiple edges out

Create composed aspects prior to deployment aspect pattern DataWithCounterAndLock uses DataWithCounter, DataWithLock { participant Data { expect void make_empty(); expect void push(Object a); expect void pop(); } adapter DataWithCounterA { Data is DataWithCounter.DataStructure} // identity name map adapter DataWithLockA { Data plays DataWithLock.Data with { method-to-wrap = replaced methods of DataWithCounterA } } // ordering of adapters is relevant

Create composed aspects prior to deployment Do we need this nested adapter syntax? aspect pattern DataWithCounterAndLock { participant Data = DataWithCounter.DataStructure is DataWithLock.Data with { method-to-wrap = {make_empty, pop, push}}; }

Create composed aspects prior to deployment aspect pattern DataWithCounterAndLock { participant Data = DataWithCounter.DataStructure is DataWithLock.Data with { method-to-wrap = {make_empty, pop, top, push}}; } Instantiate DataWithCounter and DataWithLock

Second connector: Deploy composed component connector addCounter&Lock { StackImpl is DataWithCounterAndLock.Data with { void make_empty() {empty();} void initCounter() { counter = new Counter();} void push(Object obj) {push(obj);} ... }; QueueImpl is DataWithCounterAndLock.Data with {...}; }

Doug Schmidt Apply collaborations and adapters to express middleware: Namingserver, EventChannel Express basic patterns, compose them to core functionality. Add synchronization, persistence, and later real-time aspects. Compare handwritten code with generated code.