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

2. Collaborations/Adapters
Authors
Presenter: Karl Lieberherr, Northeastern University, Boston and UBS AG, Zurich
David Lorenz, Northeastern University, Boston
Mira Mezini, University of Siegen, Germany
12/28/2018
Collaborations/Adapters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21. Rough correspondences
12/28/2018
Collaborations/Adapters

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

107. Adaptive Following LoDC 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

153. Collaborations/Adapters
Summary
More information:
12/28/2018
Collaborations/Adapters