Building Modular Object-Oriented Systems with Reusable Collaborations Karl Lieberherr, David Lorenz and Mira Mezini (C) 2000 by the authors 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Authors Presenter: Karl Lieberherr, Northeastern University, Boston and UBS AG, Zurich (lieber@ccs.neu.edu) David Lorenz, Northeastern University, Boston (lorenz@ccs.neu.edu) Mira Mezini, University of Siegen, Germany (mira@ccs.neu.edu) 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Disclaimer The material presented in this tutorial does not represent an official UBS process. 12/28/2018 Collaborations/Adapters

The Future of Software Engineering Editor: A. Finkelstein Software Engineering: a Roadmap by A. Finkelstein and Jeff Kramer: Key Research Pointers We need to be able to build systems that are more resilient or adaptive under change … We need to devise and support new structuring schemes and methods for separating concerns in software systems development. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Same book: Tables Software Maintenance and Evolution 5.2 How can software be designed so that it can easily be evolved 5.3 More effective tools and methods for program comprehension ... Software Architecture 6.3 Software Architecture that adapt themselves to their physical setting 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Same book: Tables Object-oriented modeling 7.1 To identify appropriate language means for modeling an “aspect” of a system 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Overview Tangling and Crosscutting in Object-Oriented Systems Discussion of solution approaches: Design patterns, AspectJ, Hyper/J, Demeter Problems with structuring software - function versus object structuring Reconciliation of both worlds: Adaptive Plug-and-Play Components (AP&PC) as the component construct AP&PC for generic higher-level collaborative behavior Tools Summary 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Part 1: Contents A quick introduction to collaborations Idea Program development view: why adapters Crosscutting and tangling The goal Some related approaches Collaborations: Booch, SAP Examples: synchronization, counting, flying Definition of collaboration 12/28/2018 Collaborations/Adapters

Collaborations/Adapters public class Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { return loc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { return loc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { return dim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { return dim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); void adjustDimensions() throws RemoteException { dim.adjust(); class AdjustableLocation { protected double x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; synchronized double get_x() { return x_; } synchronized void set_x(int x) {x_ = x;} synchronized double get_y() { return y_; } synchronized void set_y(int y) {y_ = y;} synchronized void adjust() { x_ = longCalculation1(); y_ = longCalculation2(); class AdjustableDimension { protected double width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; synchronized double get_width() { return width_; } synchronized void set_w(int w) {width_ = w;} synchronized double get_height() { return height_; } synchronized void set_h(int h) {height_ = h;} width_ = longCalculation3(); height_ = longCalculation4(); interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; From Crista Lopes PhD thesis (NU/Xerox) public class Shape { protected double x_= 0.0, y_= 0.0; protected double width_=0.0, height_=0.0; double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); } void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); coordinator Shape { selfex adjustLocation, adjustDimensions; mutex {adjustLocation, get_x, set_x, get_y, set_y}; mutex {adjustDimensions, get_width, get_height, set_width, set_height}; portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjustLocation() {}; void adjustDimensions() {}; Write this Instead of writing this 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Idea How can we make enhancements (e.g., extension, evolution and adaptation) easier? Localize enhancements! But: An enhancement might intrinsically influence many methods or classes. The code needed for the enhancement might be spread over a good fraction of the program. Solution: Allow programmer to refer to many points in execution of program in a localized manner. Allow additional actions to be executed at those points. 12/28/2018 Collaborations/Adapters

Two things are important! Specify additional or modified actions. Actions come first! when to call those actions. Specification may cut across many methods. Crosscutting comes second. We use separate constructs to specify crosscuts and actions on crosscuts. 12/28/2018 Collaborations/Adapters

Program development view Start with simple program Get to the desired program by applying a sequence of changes to the simple program For example: start with simple program P that can print application objects and extend it with behaviors B1, B2, … Bn, and a synchronization policy S and a distribution policy D and a historization policy H. 12/28/2018 Collaborations/Adapters

Program development view Synthesis (adapters) Separation of concerns Desired System Implementation model Use Cases + system issues Collaborations (Role models) 12/28/2018 Collaborations/Adapters

Program development view Final program 1 = P + B1 + B2 + … + Bn + S + D + H + … Final program 2 = P + B1 + B2 + … + Bn + S1 + D1 + H1 + … Final program 3 = P1 + B1 + B2 + … + Bn + S + D + H + … 12/28/2018 Collaborations/Adapters

Program development view We want the individual changes to be generic and therefore they need to be instantiated. Final program 1 = P + A1(B1)+ A2(B2)+ … + An+1(Bn)+ An+2(S) + An+3(D) + An+4(H) + … The A functions are adapters that adapt the generic changes to the specific context. 12/28/2018 Collaborations/Adapters

Discussion of adapters Adapters express the crosscutting. Do they add complexity? They add complexity but they remove complexity elsewhere: the enhancements become decoupled and reusable. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Constructs to use UML collaborations (adapted) for expressing actions decoupled from adapters. New: allow rewriting of methods. Composite adapters to express the crosscutting that maps actions to execution points. May contain arbitrary Java code to implement required interface of collaboration with provided interfaces 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Terminology The collaboration-adapter language is also called the AP&PC (Adaptive Plug-and-Play Component) language: based on terminology in our OOPSLA ‘98 paper In a later paper we also used the term: “aspectual component” for AP&PC. No longer used. 12/28/2018 Collaborations/Adapters

Cross-cutting of aspects better program ordinary program Basic classes: structure Class A Aspect 1 Slice of functionality Aspect 2 Class B avoid tangled programs AOP Slice of functionality Aspect 3 Class C 12/28/2018 Collaborations/Adapters

The goal: Tangling control The goal is to separate program enhancements (each enhancement in a single place) and minimize dependencies between them (loose coupling): less tangled code, more natural code, smaller code enhancements are easier to reason about, debug and maintain a large class of modifications in the definition of one enhancement has a minimum impact on the others more reusable, can plug/unplug enhancements as needed 12/28/2018 Collaborations/Adapters

Rough correspondences 12/28/2018 Collaborations/Adapters

Example: Write accesses: AspectJ application Example: Write accesses: AspectJ class Point { int _x = 0; int _y = 0; void set(int x, int y) { _x = x; _y = y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } int getX(){ return _x; } int getY(){ return _y; } aspect aspect ShowAccesses { static before Point.set, Point.setX, Point.setY { System.out.println(“W”); } 12/28/2018 Collaborations/Adapters

AOP example with collaboration class Point { int _x = 0; int _y = 0; void set(int x, int y) { _x = x; _y = y; } void setX(int x) { _x = x; } void setY(int y) { _y = y; } int getX(){ return _x; } int getY(){ return _y; } collaboration ShowWAccesses { participant Data-To-Access{ expect void writeOp(*);} replace void writeOp(){ System.out.println(“W”); expected(*);} } An AC is a better aspect description unit. An aspect written with an AC is more concise and reusable than Aspect/j aspects, due to name maps! Aspects are written independently of applications, or particular classes in the application. They are generic with respect to the primary module structure of the application. adapter AddShowWAccesses { //connects appl, ShowWAccesses ... Point is Data-To-Access { … writeOp = set* ... } 12/28/2018 Collaborations/Adapters

Quote by Grady Booch, Aug. 30, 1999 From the perspective of software architecture, we have found that collaborations are the soul of an architecture, meaning that they represent significant design decisions that shape the system’s overall architecture. We have been using collaborations to capture the semantics … of e-business ... 12/28/2018 Collaborations/Adapters

SAP View of Components (www.sap.com/banking) Quote: A Business Component represents the functionality of a set of semantically related Business Objects and their standard business interfaces, the BAPIs (Business Application Programmer Interfaces). In UML those components are called collaborations. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Example 1: outline ReadersWriters pattern Have a data structure with read and write methods that are used in a multi-threaded environment Rule no reader and at most one writer or several readers and no writer 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Example 1: plan Describe synchronization pattern as a UML-style (Unified Modeling Language) collaboration. Describe instantiation of pattern using an adapter. 12/28/2018 Collaborations/Adapters

Example 1: collaboration collaboration ReadersWriters { protected int activeReaders_ = 0; ... participant DataToProtect { expect Object read(Object[] args); expect void write(Object[] args); replace Object read(Object[] args){ // around beforeRead(); Object r = expected(args); afterRead(); return r;} replace write(Object[] args){ // around beforeWrite(); expected(args); afterWrite();} 12/28/2018 Collaborations/Adapters

Example 1: collaboration protected boolean allowReader() { return waitingWriters_ == 0 && activeWriters_ == 0;} protected boolean allowWriter() { return activeReaders_ == 0 && protected synchronized void beforeRead() { ++ waitingReaders_; while (!allowReader()) try {wait();} catch (...) {} -- waitingReaders_; ++ activeReaders_; } ... } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Example 1: adapter adapter ReadersWritersUse { MyHashtable is ReadersWriters.DataToProtect with { read = {clone(), get(Object), contains(Object), elements(), isEmpty(), ...} write = {clear(), put(Object,Object), remove(Object), ... }// remaining methods } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Example 1: discussion Simple case: one class only. Typical case: one collaboration affects many classes. One collaboration may affect program at many different join points. Collaboration localizes many changes cutting across one or several classes. Adapter describes the crosscutting. 12/28/2018 Collaborations/Adapters

Collaboration-adapter language We find it to be very expressive for AOP in general see OOPSLA’ 98 paper (Mezini/Lieberherr) and follow-on technical report with David Lorenz 12/28/2018 Collaborations/Adapters

Example 2: synchronization collaboration BoundedDataStructure { participant D { expect void put (Object o); expect Object take(); expect int used(); expect int length(); } protected boolean full=false; protected boolean empty=true; replace synchronized void put (Object o){ while (full) {try { wait(); }} catch (InterruptedException e) {}; expected(); if (used()==1) notifyall(); empty=false; if (used()==length()) full=true; } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Example 2: continued replace synchronized Object take (Object o){ while (empty) try { wait(); } catch (InterruptedException e) {}; Object r = expected(); if (used()==length() - 1) notifyall(); full=false; if (used()==0) empty=true; return r;} } // end participant } // end collaboration 12/28/2018 Collaborations/Adapters

Example 2: Adapter 1: Use the coordinator with basic Buffer adapter BoundedDataStructureToBuffer { Buffer is BoundedDataStructure.D with { // adaptation body: in Java void put (Object o){ in(o); } Object take() {return out(); } int used() {return usedSlots; } int length() {return array.length; } } } 12/28/2018 Collaborations/Adapters

Example 2: Adapter 2: Use the coordinator with basic BoundedStack adapter BoundedDataStructureToMyStack { BoundedStack is BoundedDataStructure.D with { void put (Object o){ push(o); } Object take() {return pop(); } int used() {return size(); } int length() {return limit(); } } } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Implement required interface in terms of provided interface. The adaptation bodies are written in terms of three self variables: The environment of the participant, the base environment and the adapter environment. Adapters express the crosscutting. 12/28/2018 Collaborations/Adapters

A simple multi-class collaboration Solve simple counting problems Define Count collaboration and use it twice Demonstrates concept of adaptive programming used in Demeter. Aaptive programming is good to express certain kinds of crosscuts in a robust way Example of a functional aspect 12/28/2018 Collaborations/Adapters

Example 3: Count Collaboration collaboration Counting { participant Source { expect TraversalGraph getT(); // new TraversalGraph(classGraph, // new Strategy(“from Source to Target”)); public int count (){ // traversal/visitor weaving getT().traverse(this, new Visitor(){ int r; public void before(Target host){ r++; } public void start() { r = 0;} …) } } // ClassGraph classGraph = new ClassGraph(); can we really program with strategies? Here is how. 12/28/2018 Collaborations/Adapters

Example 3: Count Collaboration participant Target {} } Use in Bus simulation example: Source -- BusRoute Target -- Person can we really program with strategies? Here is how. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Count all persons waiting at any bus stop on a bus route Use 1 from BusRoute via BusStop to Person busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* 12/28/2018 Collaborations/Adapters

Collaborations/Adapters count all persons waiting at any bus stop on a bus route Use 2 from BusRoute via BusStop to Person villages BusRoute BusStopList buses VillageList busStops 0..* 0..* BusStop BusList Village waiting 0..* passengers Bus PersonList Person 0..* 12/28/2018 Collaborations/Adapters

Collaborations/Adapters adapter CountingForBusRoute1 { BusRoute is Counting.Source with { TraversalGraph getT() {return new TraversalGraph(classGraph1, new Strategy(“from BusRoute via BusStop to Person”));} } Person is Counting.Target { } // ClassGraph classGraph = new ClassGraph(); 12/28/2018 Collaborations/Adapters

Collaborations/Adapters adapter CountingForBusRoute2 { BusRoute is Counting.Source with { TraversalGraph getT() {return new TraversalGraph(classGraph2, new Strategy(“from BusRoute via BusStop to Person”));} } Person is Counting.Target { } // ClassGraph classGraph = new ClassGraph(); Note that only class graph changed 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Discussion Program (collaboration and adapter) adapts to changing class graph Collaborations work well both for non-functional aspects (like synchronization) as well as functional aspects (like counting) 12/28/2018 Collaborations/Adapters

Summary of three examples Enhance sequential data structure with readers/writers synchronization policy: add new data for collaboration: activeReaders_, ... Enhance sequential, bounded data structure with mutual exclusion synchronization policy: add new data : full, empty. Enhance program with counting behavior 12/28/2018 Collaborations/Adapters

A special case of collaborations: Personalities Only one collaborator We will use AP&PCs but personalities make a simple case very understandable 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Popular Functions The popular functions in Zoo System …and their sub-functions Fly() popular function Encapsulate this sequence. Always the same for any class... 12/28/2018 Collaborations/Adapters

Mapping Popular Functions Swim() Fly() Walk() 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Personality - Concept Encapsulate popular functions independent of any specific class hierarchy Not abstract classes Embody one, and only one role Not interfaces (a-la Java) More constrained Contain behavior implementation 12/28/2018 Collaborations/Adapters

Personality - Architecture Users of the object only deal with the Personality’s “Provided Interface” (“Trainer”) (“Flier”) (“Pelican”) The role behavior is encapsulated here... …and defined in terms of the “Required Interface”, which classes in the hierarchy must implement. 12/28/2018 Collaborations/Adapters

Personality - Components Provided interface popular functions go here Required interface functions to be implemented by personifying class Private functions no visibility either upstream or downstream Role-specific attributes to keep the role’s state Constructor to initialize the role-specific attributes 12/28/2018 Collaborations/Adapters

Personality - Definition Syntax Each method in the provided interface is declared and defined. Each method in the required interface is declared but not defined. 12/28/2018 Collaborations/Adapters

Personality as a collaboration collaboration Flying { participant FlyingThing { expect void takeOff(), expect void ascend(), public void fly (int x, int y,int altitude){ … takeOff(); … ascend(); … } 12/28/2018 Collaborations/Adapters

Personality - Usage Syntax Declare intent... The Bat class implements the required interface of the Flier personality Implementation of the Bat class. Nothing to do with the Flier personality here... 12/28/2018 Collaborations/Adapters

Usage expressed with adapter adapter FlyingBat { Bat is Flying.FlyingThing with { void takeOff() { … } void ascend() { … } … } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Insertion Based on feedback from teaching the material ... 12/28/2018 Collaborations/Adapters

Factoring out similarities that cut across dominant decomposition Specific Behavior 1 Adapters s1 s2 Generic Behavior Specific Behavior 2 AOP solution: less redundancy, cheaper, requires tool support Traditional solution: redundancy 12/28/2018 Collaborations/Adapters

Handling of Multiple Structures Specific Counting Adapters s1 s2 Generic Counting Specific Counting AOP solution: less redundancy, cheaper, requires tool support Traditional solution: redundancy 12/28/2018 Collaborations/Adapters

Example : The Publisher-Subscriber Protocol Have two collaborating participants 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Publisher collaboration PublisherSubscriberProtocol { participant Publisher { expect void changeOp(Object[] args); protected Vector subscribers = new Vector(); public void attach(Subscriber subsc) { subscribers.addElement(subsc);} public void detach(Subscriber subsc) { subscribers.removeElement(subsc);} replace void changeOp() { expected(); for (int i = 0; i < subscribers.size(); i++) {((Subscriber)subscribers.elementAt(i)). newUpdate(this);}} 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Subscriber participant Subscriber { expect void subUpdate(Publisher publ); protected Publisher publ; public void newUpdate(Publisher aPubl) { publ = aPubl; subUpdate(publ);} } 12/28/2018 Collaborations/Adapters

Classes for deployment Class Point { void set(…) } class InterestedInPointChange { void public notifyChange() { System.out.println("CHANGE ..."); 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Deployment 1 adapter PubSubConn1 { Point is Publisher with { changeOp = set*;} InterestedInPointChange is Subscriber with { void subUpdate(Publisher publ) { notifyChange(); System.out.println(”on Point object " + ((Point) publ).toString()); } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Red: expected replaced Blue: from adapter Deployment 1 Publisher Point changeOp calls newUpdate attach(Subscriber) detach(Subscriber) set InterestedInPointChange Subscriber subUpdate(Publisher) newUpdate(Publisher) subUpdate(Publisher) notifyChange() 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Deployment 2 connector PubSubConn2 { TicTacToe is Publisher with { changeOp = {startGame, newPlayer, putMark, endGame}}; {BoardDisplay, StatusDisplay} is Subscriber with { void subUpdate(Publisher publ) { setGame((Game) publ); repaint(); } }; 12/28/2018 Collaborations/Adapters

Collaborations/Adapters End insertion 12/28/2018 Collaborations/Adapters

What is a collaboration? any identifiable slice of functionality that describes a meaningful service, involving, in general, several concepts, with well-defined required and provided interfaces, formulated for an ideal ontology - the required interface subject to deployment into several concrete ontologies by 3rd parties (instantiation of collaboration) subject to composition by 3rd parties subject to refinement by 3rd parties An ontology is, in simple terms, a collection of concepts with relations among them plus constraints on the relations. 12/28/2018 Collaborations/Adapters

Collaboration deployment/composition Deployment is mapping idealized ontology to concrete ontology specified by adapters separately from components without mentioning irrelevant details of concrete ontology in map to keep deployment flexible non-intrusive, parallel, and dynamic deployment Composition is mapping the provided interface of (lower-level) components to the required interface of a (higher-level) component deployment is a special case of composition, where the lower level component is a concrete ontology (no required interface) 12/28/2018 Collaborations/Adapters

Using the required interface Two basic possibilities using them unchanged as subroutines: calling functions in the required interface to build functions in the provided interface modifying the functions in the required interface: wrapping them with additional functionality and putting them into the provided interface 12/28/2018 Collaborations/Adapters

Similarity to hardware description languages Hardware components input/output signals instantiated with actual parameters connected by wires (statically) primitive building blocks are gates (or, not) and memory elements Software components input/output methods instantiated with actual parameters connected by adapters (statically or dynamically) primitive building blocks are basic classes with basic methods 12/28/2018 Collaborations/Adapters

Karl Lieberherr, David Lorenz and Mira Mezini Building Modular Object-Oriented Systems with Reusable Collaborations Part 2 Karl Lieberherr, David Lorenz and Mira Mezini 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Part 2: Contents Problems with software structuring: data/functions Reconciling data/functions A closer look at collaborations with ShowReadAccess example Inheritance between collaborations and adapters 12/28/2018 Collaborations/Adapters

Problems with Software Structuring Data (Shapes) + Functions (Colors) 1st Generation Spaghetti-Code 4th Generation object decomposition 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 2nd & 3rd Generation : functional decomposition

Problems with Functional Decomposition Advantage: easy integration of new functions Disadvantage: Data spread around integration of new data types ==> modification of several functions functions tangled due to use of shared data Difficult to localize changes ! 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

Problems with Object Decomposition Advantage: easy integration of new data Disadvantage: functions spread around integration of new functions ==> modification of several objects objects tangled due to higher-level functions involving several classes Difficult to localize changes ! 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

Problems with Object Decomposition high-level behavior scattered around the implementation of several classes OOAD Z Collab-1 C1 C4 C2 C3 C5 Collab-4 Collab-2 Collab-3 C1 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 C4 C2 C3 C5 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 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

Problems with Object Decomposition 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 implementation separate higher-level functions are mixed together During maintenance/evolution individual collaborations need to be factored out of the tangled code

So what? NO ! So, let’s organize!! Let’s have component “Forget about objects” [Udell, BYTE, May 94] NO ! So, let’s organize!! Let’s have component constructs that capture functions cross cutting class boundaries !! Let’s have AP&PC to reconcile functions and objects 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 ACs will support. So why?

Reconciling objects and functions: the intuition behind collaborations/adapters modification 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 result required provided adapters Concrete application

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

definition result deployment 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

definition deployment result 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

CounterImpl DataWithCounter StackImpl QueueImpl LockImpl DataWithLock 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 LockImpl DataWithLock

ShowReadWriteAccesses Weaved Code AutoReset Shapes ShowReadWriteAccesses Point 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 Line NewInstanceLogging Rectangle

DataWithCounter&Lock DataWithLock DataWithCounter&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

A closer look at collaborations A slice of high-level, system/application level functionality. Slice: not self-contained. High-level: three meanings multi-party functionality involving several participants one participant may be mapped to a set of otherwise not structurally related classes two neighboring participants may be mapped to classes that are “far apart” (many intermediate classes) 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Examples Publisher-subscriber protocol: it applies in general to multiple sets of classes in different places in a system's object structure. Logging execution behavior Synchronization 12/28/2018 Collaborations/Adapters

Informal collaboration description: ShowReadAccess ``For any data type in an application, say DataToAccess, any read access operation, AnyType readOp() defined for DataToAccess, and any invocation of this operation on an instance of DataToAccess called, dataInstance, display Read access on <string representation of dataInstance>´´. 12/28/2018 Collaborations/Adapters

Example of a collaboration for ShowReadAccess collaboration ShowReadAccess { participant DataToAccess { expect Object readOp(); replace Object readOp() { System.out.println("Read access on " + this.toString()); return expected(); // this calls the // expected version of readOp() } 12/28/2018 Collaborations/Adapters

Concrete class graph: in Java class Point { private int x = 0; private int y = 0; void set(int x,int y) {this.x = x;this.y = y;} void setX(int x) { this.x = x; } void setY(int y) { this.y = y; } int getX(){ return this.x; } int getY(){ return this.y; } } class Line { ... } class Rectangle {... } 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Deployment adapter ShowReadAccessConn1 { Point is ShowReadAccess.DataToAccess with {readOp = get*}; } adapter ShowReadAccessConn3 { {Point, Line, Rectangle} is ShowReadAccess.DataToAccess with {readOp = get*; } 12/28/2018 Collaborations/Adapters

Inheritance between components collaboration ShowReadWriteAccess extends ShowReadAccess { participant DataToAccess { expect void writeOp(Object[] args); replace void writeOp(Object[] args){ System.out.println( "Write access on " + this.toString()); expected(args);}} } 12/28/2018 Collaborations/Adapters

Inheritance between adapters adapter ShowReadWriteAccessConn2 extends ShowReadAccessConn3 { {Point,Line,Rectangle} is DataToAccess with { writeOp = set*; } 12/28/2018 Collaborations/Adapters

Collaborations have flavor of classes Common Have local data and function members One collaboration can inherit from another collaboration Different collaboration/adapter separation. Adaptation code is a part of the instantiation of the collaboration. 12/28/2018 Collaborations/Adapters

What are collaborations? Collaborations are language constructs that capture behaviour involving several classes (cross-cuts class boundaries) the programmer uses classes to implement the primary data (object) structure the programmer uses collaborations to implement higher-level behavior cross-cutting the primary structure in a modular way 12/28/2018 Collaborations/Adapters

What are collaborations? Collaborations have provided and required interfaces The required interface consists of an ideal class graph (Participant Graph, PG) to enable defining one aspect of the system with limited knowledge about the object model and/or other aspects defined by other collaborations Collaborations can be deployed into PGs or concrete class graphs and/or composed/refined by 3rd parties (reuse) by mapping interfaces via explicit adapters. 12/28/2018 Collaborations/Adapters

Collaborations (AP&PC) minimal assumptions on application structure Participant Graph P1 P3 P2 + required interfaces Behavior Definition P P1 meth 1,1 add new functionality + enhance the required provided = everything declared public ... written to the PG similar to an OO program is written to a concrete class graph meth 1,k P3 meth 3,1 ... meth 3,j

Collaboration Definition A set of participants forming a graph called the participant graph (represented, e.g., by a UML class diagram). Participant formal argument to be mapped required function members (keyword expect) reimplementations (keyword replace) local data and function members 12/28/2018 Collaborations/Adapters

Definition (continued) Local classes: visibility: collaboration Collaboration-level data and function members. There is a single copy of each global data member for each deployment 12/28/2018 Collaborations/Adapters

Deployment/Composition of Collaborations Specified by adapters separately from collaborations Adapters use regular-expressions to express sets of method names and class names and interface names code where simple method name mapping is not enough graphs and regular expression-like constructs for mapping graphs 12/28/2018 Collaborations/Adapters

Deploying/Composing AP&PCs participant-to-class name map Application Participant Graph P1 P3 required/provided adapters P2 link-to-paths map Behavior Definition P1 m 1,1 ... m 1,k AP&PC Compiler (CG-to-PG compatability?) P1 executable Java code

Karl Lieberherr, David Lorenz and Mira Mezini Building Modular Object-Oriented Systems with Reusable Collaborations Part 3 Karl Lieberherr, David Lorenz and Mira Mezini 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Part 3: Contents Connection to Law of Demeter Design issues with collaborations Application in EJB and XML Focus on adapters use of traversal strategies XPath (XML) and traversal strategies UML and collaborations Tools: AP Library, DJ, Demeter/Java Summary 12/28/2018 Collaborations/Adapters

Connection to Law of Demeter Law of Demeter and knowledge about structural object model. 12/28/2018 Collaborations/Adapters

Participant Graph Where Have We Seen That Before ? Quote: Avoid traversing multiple links or methods. A method should have limited knowledge of an object model. A method must be able to traverse links to obtain its neighbors and must be able to call operations on them, but it should not traverse a second link from the neighbor to a third class. Rumbaugh and the Law of Demeter (LoD) 12/28/2018 Collaborations/Adapters

Adaptive Following LoD C A FRIENDS a S X c b are not accidentally friends other classes exist for other reasons participant graph: makes some “far” away classes into friends B a:From S to A b:From S to B c:From S via X to C 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Design issues What goes into collaborations and what goes into adapters? Depends on reuse of collaboration C. Consider n reuses of the same collaboration: A1(C), A2(C), … ,An(C) The goal is to put enough information into collaboration C so that in the adapters there is minimal repetition. 12/28/2018 Collaborations/Adapters

Application to business modelling: Analysis, Design, Implementation Motivation How to eliminate redundancy from business processes and how to systematically translate them to implementations. Technical problem/ Research question How to express processes in terms of collaborations and adapters. How to add implementation details using collaborations and adapters. The approach Develop an ideal business model for each business process and describe process in that model. Use (cross-cutting) adapters to instantiate processes several times in big UML class graph. Unanswered questions Interactions between processes (composition), Can implementation be constructed using collaborations and adapters? 12/28/2018 Collaborations/Adapters

Aspect-oriented design Requires good abstraction skills. Find abstractions that can be reused (in a crosscutting manner) several times so that the different reuses contain minimal redundancy can be adapted easily and robustly to the changing contexts 12/28/2018 Collaborations/Adapters

Program development view Synthesis (adapters) Separation of concerns Desired System Implementation model Use Cases + system issues Collaborations (Role models) 12/28/2018 Collaborations/Adapters

Are adapters really needed? No, see AspectJ. But limits reusability. 12/28/2018 Collaborations/Adapters

An application in Java technology Separation of concerns an important issue in Enterprise Java Beans. Later also discuss XML application 12/28/2018 Collaborations/Adapters

Enterprise Java Beans (EJB) and collaborations and adapters EJB: a hot Java component technology from SUN/IBM Collaborations and adapters: a conceptual tool for the design of enterprise Java beans (and other components) 12/28/2018 Collaborations/Adapters

Enterprise JavaBeans (EJB) Addresses aspectual decomposition. An enterprise Bean provider usually does not program transactions, concurrency, security, distribution, persistence and other services into the enterprise Beans. An enterprise Bean provider relies on an EJB container provider for these services. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters EJB Beans Containers: to manage and adapt the beans. Intercept messages sent to beans and can execute additional code. Similar to reimplementation of required interface in collaboration. 12/28/2018 Collaborations/Adapters

Collaborations for EJB design/implementation Use collaborations to model transactions, concurrency, security, distribution and other system level issues. Translate collaborations and adapters to deployment descriptors (manually, or by tool). 12/28/2018 Collaborations/Adapters

Example: Use AP&PC for EJB persistence As an example we consider how persistence is handled by EJB containers. The deployment descriptor of a bean contains an instance variable ContainerManagedFields defining the instance variables that need to be read or written. This will be used to generate the database access code automatically and protects the bean from database specific code. 12/28/2018 Collaborations/Adapters

Collaboration: Persistence collaboration Persistence {PerMem p; participant Source { expect Target[] targets; expect void writeOp();} // for all targets: writeOp participant Target { expect void writeOp(); replace void writeOp() { // write to persistent memory p expected();}}} 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Deployment adapter PersistenceConn1 { ClassGraph g = ; // from Company to * Company is Persistence.Source; Nodes(g) is Persistence.Target; with {writeOp = write*}; // must be the same writeOp for both // Source and Target } 12/28/2018 Collaborations/Adapters

Generate deployment descriptor Adapter contains information about ContainerManagedFields Adapter localizes information; it is not spread through several classes 12/28/2018 Collaborations/Adapters

Collaborations/Adapters AOP idea in XML Java server page contains XML description (concern: structure of info.) Java code (concern: how to compute info.) XSL description (concern: how to display information) Three integrated concerns: Structure, Retrieval, Display 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Focus on adapters Adapters: map generic behavior to concrete behavior. It would be helpful if they could be made robust to structural changes … If the participant graph of a collaboration needs to be embedded into a complex application class graph, the adapter might be brittle with respect to changes in the class graph. 12/28/2018 Collaborations/Adapters

Earlier viewgraph: Adapter 2 adapter CountingForBusRoute2 { BusRoute is Counting.Source with { TraversalGraph getT() {return new TraversalGraph(classGraph2, new Strategy(“from BusRoute via BusStop to Person”));} } Person is Counting.Target { } // ClassGraph classGraph = new ClassGraph(); Note that only class graph changed 12/28/2018 Collaborations/Adapters

Specification and Efficient Implementation (Graph Theory of OOP/OOD) Traversal Strategies Specification and Efficient Implementation (Graph Theory of OOP/OOD) 12/28/2018 Collaborations/Adapters

Collaborations/Adapters What they can do Define subgraphs succinctly Define path sets succinctly Applications define cross-cutting functions writing adaptive programs marshaling objects storing objects persistently etc. 12/28/2018 Collaborations/Adapters

Applications of Traversal Strategies Defining mapping from high-level graph to a low-level graph without committing to all details of low-level graph in definition of mapping. Low-level graph is parameter to definition of mapping. Exploit structure of low-level graph in definition of mapping. 12/28/2018 Collaborations/Adapters

S is a traversal strategy for G F=t F D D E E B B C C S G A = s A

Other applications of traversal strategies Specify mapping between graphs (adapters) 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 12/28/2018 Collaborations/Adapters

Other applications of traversal strategies 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 library (Xerox PARC) 12/28/2018 Collaborations/Adapters

Traversal strategy definition: embedded, positive strategies Given a graph G, a strategy graph S of G is any connected subgraph of the transitive closure of G. The transitive closure of G=(V,E) is the graph G*=(V,E*), where E*={(v,w): there is a path from vertex v to vertex w in G}. 12/28/2018 Collaborations/Adapters

S is a strategy for G F=t F D D E E B B C C S G A = s A

Collaborations/Adapters Discussion Seems strange: define a strategy for a graph but strategy is independent of graph. Many very different graphs can have the same strategy. Better: A graph G is an instance of a graph S, if S is a connected subgraph of the transitive closure of G. (call G: concrete graph, S: abstract graph). 12/28/2018 Collaborations/Adapters

Discussion: important is concept of instance/abstraction A graph G is an instance of a graph S, if S is a connected subgraph of the transitive closure of G. (call G: concrete graph, S: abstract graph). A graph S is an abstraction of graph G iff G is an instance of S. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Improved definition Want a stronger form of instance called refinement. Based on experience. Concept of graph refinement: A graph G is a refinement of a graph S, if S is a connected subgraph of the pure transitive closure of G with respect to the node set of S. 12/28/2018 Collaborations/Adapters

Pure transitive closure The pure transitive closure of G=(V,E) with respect to a subset W of V is the graph G*=(V,E*), where E*={(i,j): there is a W-pure path from vertex i to vertex j in G}. A W-pure path from i to j is a path where i and j are in W and none of the inner points of the path are in W. 12/28/2018 Collaborations/Adapters

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 strong refinement G2 F F D D E E B B C C G2 G1 A A refinement: connectivity of G2 is in pure form in G1 and G1 contains no new connections in terms of nodes of G2 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 pure form in G1 Allows extra connectivity. G1 A A

XPath: navigation language of XML A subset of the traversal strategies navigation language (for adaptive navigation) is contained in Xpath Can write robust XML code using same techniques as in Demeter //Chapter//Paragraph = from Root via Chapter to Paragraph 12/28/2018 Collaborations/Adapters

Xpath capabilities for emulating traversal strategies The main way is by using //Target : so the topology of the Class Graph can have the freedom to change while we are still able to get to the Target used //Target1//Target2 to emulate Demeter's "via". one can use //not Target1//Target2 to emulate Demeter's "bypass" (for all these the source is the selected ELEMENT) 12/28/2018 Collaborations/Adapters

Xpath capabilities for emulating traversal strategies by using combinations of one or both ways within a path description ex: //Node1/Node2//Target will emulate a Demeter "via ->Node1,*,Node2" (via edge). 12/28/2018 Collaborations/Adapters

Collaborations/Adapters XPath Is both more powerful and less powerful than traversal strategy language Traversal strategy language is more powerful because a traversal specification can be an arbitrary graph Xpath is more powerful because it can express conditional traversals 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Collaborations in UML 1.1 UML: A collaboration consists of a set of ClassifierRoles and AssociationRoles. A ClassifierRole specifies one participant of a collaboration. A collaboration may be presented at two levels: specification-level and instance- level. AP&PC: A collaboration consists of a set of participants and a participant graph. We use same terminology for specification and instance level. Correspondences: participant graph::nodes: ClassifierRoles, participant graph::edges: AssociationRoles 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Collaborations in UML 1.1 UML: Each participant specifies the required set of features a conforming instance must have. The collaboration also states which associations must exist between participants. AP&PC: Each participant has a required interface. The participant graph is part of the required interface. Correspondences: Both separate behavior from structure. Both use the UML class diagram notation to specify the associations between participants. ClassifierRole names start with a /. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Collaborations in UML 1.1 UML: The term of classifier role and classifier is strange. Why not use participant role and participant? The base classifier must have a subset of the features required by the classifier role. With AP&PC we are more flexible: we have an adapter that allows to implement the required features. The base classifier must only provide enough “ingredients” to implement the required interface. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Collaborations in UML 1.1 UML: A collaboration may also reference … needed for expressing structural requirements such as generalizations between the classifiers … AP&PC: All structural requirements are represented by the participant graph. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Collaborations in UML 1.1 UML: An interaction specifies the communication between a set of interacting instances performing a specific task. Not sufficient to generate code. AP&PC: Interactions are specified using Java code or Interaction Schemata, an improved form of interaction diagrams (see TOOLS ‘99 paper by Sangal, Farrel, Lieberherr, Lorenz). 12/28/2018 Collaborations/Adapters

Tools available from Demeter Group AP Library: very good implementation of traversal strategies based on automata theory: for important kind of crosscutting DJ: For expressing visitor-style collaborations using only Java No tool yet that supports all features of collaborations and adapters presented here 12/28/2018 Collaborations/Adapters

Tool Demeter/Java: how can XML use OO/AOP? Schema (similar to an XML schema) Object descriptions (e.g., XML documents) Demeter produces: Java classes with basic capabilities to process descriptions: parser, various kind of visitor classes for printing, copying, comparing, etc. Java objects e.g., produced by the parser from object descriptions. Behavior (Java with support for traversal/visitor programming) Synchronization descriptions (COOL) Remote invocation/data transfer descriptions (RIDL) 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Some Related Work Other groups (see Demeter home page) Xerox PARC: influential AOP paper applies AOP to other areas than OO. AspectJ tool. IBM Watson Research Lab. Subject-Oriented Programming. Multidimensional separation of concerns. Hyper/J tool. University of Twente (Netherlands): Composition Filters etc. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Summary of tutorial Collaborations (an improved form of UML collaborations or role modeling collaborations) are suitable for expressing object-oriented systems in a more modular way following the ideas of aspect-oriented programming. Traversal strategies are convenient to express common crosscutting robustly. 12/28/2018 Collaborations/Adapters

Collaborations/Adapters Summary More information: www.ccs.neu.edu/research/demeter 12/28/2018 Collaborations/Adapters