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, Germany
  (mira_at_ccs.neu.edu)

3
Disclaimer

• The material presented in this tutorial does not
  represent an official UBS process.

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.

5
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

6
Same book Tables

• Object-oriented modeling
• 7.1 To identify appropriate language means for
  modeling an aspect of a system

7
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

8
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

9
From Crista Lopes PhD thesis (NU/Xerox)
Instead of writing this
10
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.

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

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

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

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.

17
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

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

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

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

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.

26
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

27
Example 1 plan

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

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

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

30
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

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

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

33
Example 2 synchronization

• collaboration BoundedDataStructure
• participant D
• expect void put (Object o)
• expect Object take()
• expect int used()
• expect int length()
• protected boolean fullfalse protected
  boolean emptytrue
• replace synchronized void put (Object o)
• while (full) try wait()
• catch (InterruptedException e)
• expected()
• if (used()1) notifyall()
• emptyfalse
• if (used()length()) fulltrue

34
Example 2 continued

• replace synchronized Object take (Object o)
• while (empty) try wait()
• catch (InterruptedException e)
• Object r expected()
• if (used()length() - 1) notifyall()
• fullfalse
• if (used()0) emptytrue return r
• // end participant
• // end collaboration

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

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

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

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

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()
40
Example 3 Count Collaboration
participant Target
Use in Bus simulation example Source --
BusRoute Target -- Person
41
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..
42
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..
43
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()

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

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

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

47
A special case of collaborationsPersonalities

• Only one collaborator
• We will use APPCs but personalities make a
  simple case very understandable

48
Popular Functions
49
Mapping Popular Functions
50
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

51
Personality - Architecture
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 roles state
• Constructor
• to initialize the role-specific attributes

53
Personality - Definition Syntax
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()
55
Personality - Usage Syntax
56
Usage expressed with adapter
adapter FlyingBat Bat is Flying.FlyingThing
with void takeOff()
void ascend()
57
Insertion

• Based on feedback from teaching the material ...

58
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
59
Handling of Multiple Structures
Adapters
Specific Counting
s1
Generic Counting
s2
Specific Counting
AOP solution less redundancy, cheaper, requires
tool support
Traditional solution redundancy
60
Example The Publisher-Subscriber Protocol

• Have two collaborating participants

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

62
Subscriber

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

63
Classes for deployment

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

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

65
Deployment 1
Red expected replaced
Blue from adapter
Point
Publisher
changeOp calls newUpdate attach(Subscriber) deta
ch(Subscriber)
set
InterestedInPointChange
Subscriber
subUpdate(Publisher) newUpdate(Publisher)
subUpdate(Publisher) notifyChange()
66
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()

67
End insertion
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.
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)

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

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

72
Building Modular Object-Oriented Systems with
Reusable CollaborationsPart 2

• Karl Lieberherr, David Lorenz and Mira Mezini

73
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

74
Problems with Software Structuring
Software Data (Shapes)
Functions (Colors)
1st Generation Spaghetti-Code
2nd 3rd Generation functional decomposition
75
Problems with Functional Decomposition

• Disadvantage Data spread around
• integration of new data types gt
• modification of several functions
• functions tangled due to use of shared
• data
• Difficult to localize changes !

Advantage easy integration of new functions
76
Problems with Object Decomposition

• Disadvantage functions spread around
• integration of new functions gt
• modification of several objects
• objects tangled due to higher-level
• functions involving several classes
• Difficult to localize changes !

Advantage easy integration of new data
77
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
78
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
79
So what?
NO !
So, lets organize!! Lets have component
constructs that capture functions cross
cutting class boundaries !! Lets have APPC to
reconcile functions and objects
80
Reconciling objects and functionsthe intuition
behind collaborations/adapters
modification
result
required
provided
adapters
Concrete application
81
collaborations
82
definition
result
deployment
83
definition
deployment
result
84
CounterImpl
DataWithCounter
StackImpl
QueueImpl
LockImpl
DataWithLock
85
Weaved Code
Shapes
AutoReset
ShowReadWriteAccesses
Point
Line
NewInstanceLogging
Rectangle
86
DataWithCounter
DataWithLock
DataWithCounterLock
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)

88
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

89
Informal collaboration descriptionShowReadAccess

• 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 ltstring representation of
  dataInstancegt.

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

91
Concrete class graph in Java

• class Point
• private int x 0
• private int y 0
• void set(int x,int y) this.x xthis.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 ...

92
Deployment

• adapter ShowReadAccessConn1
• Point is ShowReadAccess.DataToAccess
• with readOp get
• adapter ShowReadAccessConn3
• Point, Line, Rectangle
• is ShowReadAccess.DataToAccess
• with readOp get

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)

94
Inheritance between adapters

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

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.

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

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.

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

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

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

102
Deploying/Composing APPCs
participant-to-class name map
Application
Participant Graph
P1
P3
required/provided adapters
P2
link-to-paths map
Behavior Definition
P1
...
APPC Compiler (CG-to-PG compatability?)
P1
executable Java code
103
Building Modular Object-Oriented Systems with
Reusable CollaborationsPart 3

• Karl Lieberherr, David Lorenz and Mira Mezini

104
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

105
Connection to Law of Demeter

• Law of Demeter and knowledge about structural
  object model.

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)
107
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
aFrom S to A bFrom S to B cFrom S via X
to C
108
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.

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?

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

111
Program development view
Synthesis (adapters)
Separation of concerns
Desired System
Implementation model
Use Cases system issues
Collaborations (Role models)
112
Are adapters really needed?

• No, see AspectJ.
• But limits reusability.

113
An application in Java technology

• Separation of concerns an important issue in
  Enterprise Java Beans.
• Later also discuss XML application

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)

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.

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

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

118
Example Use APPC 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.

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

120
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

121
Generate deployment descriptor

• Adapter contains information about
  ContainerManagedFields
• Adapter localizes information it is not spread
  through several classes

122
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

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

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

125
Traversal Strategies

• Specification and Efficient Implementation
• (Graph Theory of OOP/OOD)

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

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.

128
S is a traversal strategy for G
Ft
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

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)

131
Traversal strategy definitionembedded, 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.

132
S is a strategy for G
Ft
F
D
D
E
E
B
B
C
C
S
G
A s
A
133
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).

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.

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

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.

137
G1 compatible G2
F
F
D
D
E
E
B
B
C
C
G2
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
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
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

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)

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 -gtNode1,,Node2" (via
  edge).

143
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

144
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.
• APPC A collaboration consists of a set of
  participants and a participant graph. We use same
  terminology for specification and instance level.
  
• Correspondences participant graphnodes
  ClassifierRoles, participant graphedges
  AssociationRoles

145
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.
• APPC 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
  /.

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

147
Collaborations in UML 1.1

• UML A collaboration may also reference needed
  for expressing structural requirements such as
  generalizations between the classifiers
• APPC All structural requirements are
  represented by the participant graph.

148
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.
• APPC Interactions are specified using Java code
  or Interaction Schemata, an improved form of
  interaction diagrams (see TOOLS 99 paper by
  Sangal, Farrel, Lieberherr, Lorenz).

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

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

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

153
Summary

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