Building Modular ObjectOriented Systems with Reusable Collaborations

1
Building Modular Object-Oriented Systems with
Reusable Collaborations

• Karl Lieberherr, David Lorenz and Mira Mezini
• (C) 2000 by the authors

2
Authors

• Presenter Karl Lieberherr, Northeastern
  University, Boston and UBS AG, Zurich
  (lieber_at_ccs.neu.edu)
• David Lorenz, Northeastern University, Boston
  (lorenz_at_ccs.neu.edu)
• Mira Mezini, University of Siegen/Darmstadt,
  Germany (mira_at_ccs.neu.edu)

3
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 (APPC) as the component
  construct
• APPC for generic higher-level collaborative
  behavior
• Tools
• Summary

4
From Crista Lopes PhD thesis (NU/Xerox)
Instead of writing this
5
Factoring out similarities that cut across
dominant decomposition
Adapters
Specific Behavior 1
s1
Generic Behavior
s2
Specific Behavior 2
AOP solution less redundancy, cheaper, requires
tool support
Traditional solution redundancy
6
AOP Idea for OO

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

7
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 (Aspect/J has also
  adopted this approach).

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

9
Program development view
Synthesis (adapters)
Separation of concerns
Desired System
Implementation model
Use Cases system issues
Collaborations (Role models)
10
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

11
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(Bn)
  An1(S) An2(D) An3(H)
• The A functions are adapters that adapt the
  generic changes to the specific context.

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

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

14
Terminology

• The collaboration-adapter language is also called
  the APPC (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 APPC. No longer used.

15
Cross-cutting of aspects
better program
ordinary program
Basic classes structure
Aspect 1
Class A
Slice of functionality
Aspect 2
Class B
Slice of functionality
Aspect 3
Class C
16
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

17
Rough correspondences
PICCOLA Components Scripts
18
Idea is relevant

• 10000 downloads of AspectJ between September
  1999 - January 2000

19
Example Write accesses AspectJ
application
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)
20
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()
adapter AddShowWAccesses //connects appl,
ShowWAccesses ... Point is Data-To-Access
writeOp set ...
21
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
  systems overall architecture.
• We have been using collaborations to capture the
  semantics of e-business ...

22
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

23
Example 1 plan

• Describe synchronization pattern as a UML-style
  (Unified Modeling Language) collaboration.
• Describe instantiation of pattern using an
  adapter.

24
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)
• beforeRead() Object r expected(args)
• afterRead() return r
• replace write(Object args)
• beforeWrite() expected(args)
• afterWrite()

25
Example 1 collaboration

• protected boolean allowReader()
• return waitingWriters_ 0
• activeWriters_ 0
• protected boolean allowWriter()
• return activeReaders_ 0
• activeWriters_ 0
• protected synchronized void beforeRead()
• waitingReaders_
• while (!allowReader())
• try wait() catch (...)
• -- waitingReaders_ activeReaders_
  ...

26
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), ...
• // write all - read

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

28
Example 2 The Publisher-Subscriber Protocol

• Have two collaborating participants

29
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 lt subscribers.size()
  i)
• ((Subscriber)subscribers.elementAt(i)
  ).
• newUpdate(this)

30
Subscriber

• participant Subscriber
• expect void subUpdate(Publisher publ)
• protected Publisher publ
• public void newUpdate(Publisher aPubl)
• publ aPubl
• subUpdate(publ)

31
Classes for deployment

• Class Point
• void set()
• class InterestedInPointChange
• void public notifyChange()
• System.out.println("CHANGE ...")

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

33
Deployment 1
Red expected
Blue from adapter
Point
Publisher
changeOp attach detach
set
InterestedInPointChange
Subscriber
subUpdate(Publisher) newUpdate(Publisher)
subUpdate() notifyChange()
34
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()

35
A multi-class collaboration using existing
structure

• Solve simple counting problems
• Define Count collaboration and use it twice
• Demonstrates concept of adaptive programming used
  in Demeter.
• Adaptive programming is good to express certain
  kinds of crosscuts in a robust way
• Example of a functional aspect

36
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()
37
Example 3 Count Collaboration
participant Target
Use in Bus simulation example Source --
BusRoute Target -- Person
38
Use 1
Count all persons waiting at any bus stop on a
bus route
from BusRoute via BusStop to Person
busStops
BusRoute
BusStopList
buses
0..
BusStop
BusList
waiting
0..
passengers
Bus
PersonList
Person
0..
39
Use 2
count all persons waiting at any bus stop on a
bus route
from BusRoute via BusStop to Person
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..
0..
BusStop
BusList
Village
waiting
0..
passengers
Bus
PersonList
Person
0..
40
Handling of Multiple Structures
Adapters
Specific Counting
s1
Generic Counting
s2
Specific Counting
AOP solution less redundancy, cheaper, requires
tool support
Traditional solution redundancy
41
Program development view
Synthesis (adapters)
Separation of concerns
Generic Counting
Desired System
Implementation model
Use Cases system issues
Collaborations (Role models)
42
Adapter 1

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

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

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

45
Problems with Object Decomposition
high-level behavior scattered around the
implementation of several classes
OOAD
Collab-1
Z
C1
C4
C2
C3
C5
Collab-4
Collab-2
Collab-3
C1
C4
C2
C3
Implementation
C5
Piccola paper OOD tends to obscure
component-based architecture
46
Problems with Object Decomposition
During implementation separate higher-level functi
ons are mixed together
During maintenance/evolution individual
collaborations need to be factored out of
the tangled code
47
Reconciling objects and functionsthe intuition
behind collaborations/adapters
modification
result
required
provided
adapters
Concrete application
48
S is a traversal strategy for G
Ft
F
D
D
E
E
B
B
C
C
S
G
A s
A
49
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

50
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
• use //Target1//Target2 to emulate Demeter's
  "via".
• one can use //not Target1//Target2 to emulate
  Demeter's "bypass"

51
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

52
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

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

54
Summary

• Collaborations (an improved form of UML
  collaborations or role modeling collaborations)
  and adapters 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
  graph-based crosscutting robustly.

55
Summary

• More information www.ccs.neu.edu/research/demeter

56
DataWithCounter
DataWithLock
DataWithCounterLock
57
Inheritance between components

• component 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)

58
Inheritance between adapters

• adapter ShowReadWriteAccessConn2 extends
  ShowReadAccessConn3
• Point,Line,Rectangle
• is DataToAccess with
• writeOp set

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

60
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

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

62
Collaborations (APPC)
minimal assumptions on application structure
Participant Graph
P1
P3
P2

required interfaces
Behavior Definition
P
P1
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

P3
...