1. Adaptive and Aspect-Oriented Object-Oriented Software Development
Karl Lieberherr
Demeter Research Group
For MIT Software Design Seminar
Daniel Jackson, host
First lecture, first class Sep25.
1/10/2019
AP and AOP/Demeter Research Group

2. Two alternatives: I decided for the second
Graph Theory of AP/AOP
Introduction to AP/AOP with highlights of theoretical foundations
1/10/2019
AP and AOP/Demeter Research Group

3. Learning map: Graph Theory AP/AOP
generalization
Learning map: Graph Theory AP/AOP
other relationships
numbers: order of coverage
correspondences
X:class path - concrete path
Y:object path - concrete path
traversal path - class path 8 1
graph
paths
labeled
FROM-TO
computation 3 2 5 9 10
object
graph
class
graph
strategy
graph
traversal
graph
propagation
graph 4 6
object traversal defined
by concrete path set
name map
constraint map 11
zig-zags
short-cuts 7
Algorithm 1
in: strategy + class graph
out: traversal graph 12
Algorithm 2
in: traversal + object graph
out: object traversal
1/10/2019
AP and AOP/Demeter Research Group

4. Learning map: Intro. AP/AOP
Law of Demeter
Control
Tangling
Aspect-Oriented
Programming
Adaptive
Programming
Cross-cutting
Traversal
Strategy Graph
APPC
Adaptive Plug-
and-Play
Components
Reflection
Open Implementation
Implementations:
DJ etc.
Rondo
Software Architecture:
Components
Connectors
1/10/2019
AP and AOP/Demeter Research Group

5. Adaptive Programming (AP)
Programs adapt to interesting context changes
Structure-shy behavior
Succinct representation of traversals
Programming in terms of graph constraints
1/10/2019
AP and AOP/Demeter Research Group

6. AP and AOP/Demeter Research Group
Cross-cutting
better program
ordinary program
basic structure
structure-shy
functionality
Aspect 1
avoid tangled programs
AOP
synchronization
Aspect 2
1/10/2019
AP and AOP/Demeter Research Group

7. AP and AOP/Demeter Research Group
Connection
Aspect-Oriented Programming (AOP) is a generalization of Adaptive Programming (AP): In AP traversal strategies must be used.
explain how individual topics fit together
1/10/2019
AP and AOP/Demeter Research Group

8. AP and AOP/Demeter Research Group
Brief History(NU)
1987
Law of Demeter
First traversal specifications, construct for AP and AOP
Synchronization, data transfer as an aspect
Fast and general compilation algorithm
APPCs (Adaptive Plug-and-Play Components): construct for AOP
1990
1993/95
1996/97
1998
1/10/2019
AP and AOP/Demeter Research Group

9. AP and AOP/Demeter Research Group
A simple example
Show structure-shyness, adaptiveness
Show complete program
1/10/2019
AP and AOP/Demeter Research Group

10. AP and AOP/Demeter Research Group
UML Class Diagram
busStops
BusRoute
BusStopList
buses
0..*
BusStop
BusList
Example for developing strategies and writing adaptive programs
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

11. Collaborating Classes
use connectivity in class graph to define them succinctly
using traversal strategy graphs
separating structure from behavior
teasing out the structure aspect
from Customer to Agent
from Company to Employee
1/10/2019
AP and AOP/Demeter Research Group

12. What's the problem? TANGLING
OOAD Z
customer service
center
teller service
self-service
Collab-1 C1 C4 C2 C3 C5
Collab-4
Collab-2
Collab-3
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 C1 C4 C2 C3
Implementation C5
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
1/10/2019
AP and AOP/Demeter Research Group
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

13. Collaborating Classes
find all persons waiting at any bus stop on a bus route
busStops
BusRoute
BusStopList
OO solution:
one method
for each red
class
buses
0..*
BusStop
BusList
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

14. Traversal Strategy Graphs
Want to define traversals succinctly
Use graph to express abstraction of class diagram
Express traversal intent: useful for documentation of object-oriented programs
1/10/2019
AP and AOP/Demeter Research Group

15. AP and AOP/Demeter Research Group
find all persons waiting at any bus stop on a bus route
Traversal Strategy
first try: from BusRoute to Person
busStops
BusRoute
BusStopList
buses
0..*
BusStop
BusList
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

16. AP and AOP/Demeter Research Group
find all persons waiting at any bus stop on a bus route
Traversal Strategy
from BusRoute through BusStop to Person
busStops
BusRoute
BusStopList
buses
0..*
BusStop
BusList
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

17. AP and AOP/Demeter Research Group
find all persons waiting at any bus stop on a bus route
Traversal Strategy
Altern.: from BusRoute bypassing Bus to Person
busStops
BusRoute
BusStopList
buses
0..*
BusStop
BusList
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

18. Implementation (simplified OCL style)
class BusRoute {
Persons findWaiting() {
return this.busStops().waiting(); }
1/10/2019
AP and AOP/Demeter Research Group

19. Robustness of Strategy
find all persons waiting at any bus stop on a bus route
Robustness of Strategy
from BusRoute bypassing Bus to Person
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..*
0..*
BusStop
BusList
Village
waiting
0..*
passengers
Bus
PersonList
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

20. Implementation (simplified OCL style)
class BusRoute {
Persons findWaiting() {
return this.villages().busStops().waiting(); }
1/10/2019
AP and AOP/Demeter Research Group

21. Filter out noise in class diagram
only three out of seven classes
are mentioned in traversal
strategy!
from BusRoute through BusStop to Person
explain why strategy better
replaces traversal methods for the classes
BusRoute VillageList Village BusStopList BusStop
PersonList Person
1/10/2019
AP and AOP/Demeter Research Group

22. Even better: Participant graph
find all persons waiting at any bus stop on a bus route
Even better: Participant graph
from BusRoute through BusStop to Person
busStops
BusRoute
BusStop
0..*
waiting
0..*
buses
0..*
passengers
Bus
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

23. Map Participant graph to application class graph
from BusRoute through BusStop to Person
villages
BusRoute
BusStopList
buses
VillageList
busStops
0..*
0..*
BusStop
BusList
Village
waiting
0..*
passengers
Bus
PersonList
edge -> path
Person
0..*
1/10/2019
AP and AOP/Demeter Research Group

24. Map Participant graph to application class graph
from BusRoute through BusStop to Person
villages
BusRoute
BusStopList
VillageList
busStops
0..*
0..*
BusStop
Village
busStops
BusRoute
BusStop
0..*
edge -> path
1/10/2019
AP and AOP/Demeter Research Group

25. Benefits of Participant graph
Shields program from details of application class graph
Makes program more robust and simpler
1/10/2019
AP and AOP/Demeter Research Group

26. The Nature of Software Systems
Layered systems are ubiquitous
1/10/2019
AP and AOP/Demeter Research Group

27. AP and AOP/Demeter Research Group
AP Approach
Formulate specification of outer layer with approximate knowledge of inner layer.
Decouples outer layer from inner layer.
Define outer layer for a family of inner layers
AP generates implementation of outer layer using specification and information about the particular inner layer.
1/10/2019
AP and AOP/Demeter Research Group

28. AP and AOP/Demeter Research Group
AP Approach
If inner layer changes, AP can generate a new implementation of outer layer.
This allows programs written to the outer layer specification to run unchanged.
1/10/2019
AP and AOP/Demeter Research Group

29. AP Idea: X is robust: works with red and blue inner layer
1/10/2019
AP and AOP/Demeter Research Group

30. Why Traversal Strategies?
Law of Demeter: a method should talk only to its
friends:
arguments and part objects (computed or stored)
and newly created objects
Dilemma:
Small method problem of OO (if followed) or
Unmaintainable code (if not followed)
Traversal strategies are the solution to this dilemma
problem solved by traversal strategies
1/10/2019
AP and AOP/Demeter Research Group

31. Law of Demeter Principle
Each unit should have only limited knowledge about other units: only about units “closely” related to the current unit.
“Each unit should only talk to its friends.” “Don’t talk to strangers.”
Main Motivation: Control information overload. We can only keep a limited set of items in short-term memory.
1/10/2019
AP and AOP/Demeter Research Group

32. AP and AOP/Demeter Research Group
Law of Demeter
FRIENDS
1/10/2019
AP and AOP/Demeter Research Group

33. AP and AOP/Demeter Research Group
Application to OO
Unit = method
closely related =
methods of class of this/self and other argument classes
methods of immediate part classes (classes that are return types of methods of class of this/self)
In the following we talk about this application of the Law of Demeter Principle to OO
1/10/2019
AP and AOP/Demeter Research Group

34. Rumbaugh and the Law of Demeter
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.
1/10/2019
AP and AOP/Demeter Research Group

35. Adaptive Following LoDC A
FRIENDS a S X c b
a:From S to A
b:From S to B c:From S via X to C
1/10/2019
AP and AOP/Demeter Research Group

36. AP and AOP/Demeter Research Group
Adaptive Programming
How can we use strategies to program?
Need to do useful work besides traversing: visitors
Incremental behavior composition using visitors
1/10/2019
AP and AOP/Demeter Research Group

37. Writing Adaptive Programs with Strategies (DJ=pure Java)
String WPStrategy=“from BusRoute through BusStop to Person”
class BusRoute {
TraversalGraph WP = new TraversalGraph(Womble.classGraph,
new Strategy(WPStrategy));
int printCountWaitingPersons(){ // traversal/visitor weaving
WP.traverse(this, new Visitor(){ int r;
public void before(Person host){ r++; … }
public void start() { r = 0;}
... }
// ClassGraph classGraph = new ClassGraph();
can we really program with strategies? Here is how.
1/10/2019
AP and AOP/Demeter Research Group

38. AP and AOP/Demeter Research Group
Taxi driver analogy
Streets and intersections correspond to class graph
Traversal strategy determines how the taxi will navigate through the streets
You can take pictures before and after intersections
You can veto sub traversals
1/10/2019
AP and AOP/Demeter Research Group

39. Programming in Large Families
Two adaptive programs A1
Class Graphs A2
adaptive programming is programming in LARGE families
A1 family
Object-Oriented Programs
A2 family
1/10/2019
AP and AOP/Demeter Research Group

40. A very simplified quick intuition behind compilation algorithms
Apply automata theory to compiling AP
1/10/2019
AP and AOP/Demeter Research Group

41. Intersection of NDFA is similar to traversal graph constructionb a q1 q2 q3 q4 a b
a*b
ab* a b
q2q4
q1q3
q1q4
Intersection of two DFAs
1/10/2019
AP and AOP/Demeter Research Group

42. Traversal Graph Constructionq1 q2 q3 t1
any
any A B C D
A=B D.
B=C.
C=D.
D=. s2 q6 q7 t2 D A C D
from A via C to D
s1,s2
q1,q6
q2,q6
q3,q7
t1,t2 A B C D
1/10/2019
AP and AOP/Demeter Research Group

43. Integrated view of algorithms 1 and 2: for path existence
Both are similar to the intersection of two NDFAs
Algorithm 1: NDFA for strategy graph and NDFA for class graph: results in NDFA for traversal graph.
Algorithm 2: NDFA for traversal graph and NDFA for object graph: results in NDFA which tells us whether there is a non-empty traversal
1/10/2019
AP and AOP/Demeter Research Group

44. Recall: Intersection of NDFAs
An NDFA is a 5-tuple: M=(S,A,d,p0,F), S finite set of states, A is input alphabet, d is a state transition function which maps Ax(S union epsilon) to the set of subsets of S, p0 is the initial state, and F is the set of final states.
1/10/2019
AP and AOP/Demeter Research Group

45. Recall: Intersection of NDFAs
M1=(S1,A,d1,p0,F1) and M2=(S2,A,d2,q0,F2).
The NDFA for M1 intersect M2 is I=(S1xS2,A,d,(p0,q0),F1xF2), where for a in A, (p2,q2) in d((p1,q1),a) if and only if p2 in d1(p1,a) and q2 in d2(q1,a).
1/10/2019
AP and AOP/Demeter Research Group

46. In reality: more complex than automata
Deal with inheritance.
Want to minimize the NDFA while preserving its structure. Cannot use general purpose automata minimization.
Three levels of graphs: strategy-class-object; not just automata defining languages.
1/10/2019
AP and AOP/Demeter Research Group

47. Application to OCL: UML class diagram ClassGraph
0..*
Entry
EParse
entries
ClassGraph
BParse
ClassDef
Body
parts
Part
className
0..*
ClassName
super
ClassGraph -- concrete classes
self.{to Concrete}->size
Concrete
Abstract
1/10/2019
AP and AOP/Demeter Research Group

48. AP and AOP/Demeter Research Group
ClassGraph self.entries->
select(c:Entry|c.
oclIsTypeOf(ClassDef))->
collect(body)->
select (b:Body|b.
oclIsTypeOf(Concrete))
->size -- count concrete classes
ClassGraph -- count concrete classes
self.{to Concrete}->size
Which one is easier to write?
1/10/2019
AP and AOP/Demeter Research Group

49. AP and AOP/Demeter Research Group
Towards AOP
Functional decomposistion
Object decomposition
Combining them
1/10/2019
AP and AOP/Demeter Research Group

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

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

52. Problems with Object Decomposition
Advantage:
easy integration
of new data
Disadvantage: functions spread around
integration of new functions ==>
modifikation 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

53. Reconciling objects and functions: the intuition behind APPC
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
expected
provided
connectors
Concrete application

54. Informal aspect description: ShowRAccess
``For any data type in an application, say RDataToAccess, any read access operation, AnyType readOp() defined for RDataToAccess, and any invocation of this operation on an instance of RDataToAccess, dataInstance, display Read access on <string representation of dataInstance>}´´.
1/10/2019
AP and AOP/Demeter Research Group

55. Example of an APPC (Adaptive Plug-and-Play Component) for ShowRAccess
component ShowRAccess {
participant RDataToAccess {
expect Object readOp();
replace Object readOp() {
System.out.println("Read access on "
+ this.toString());
return expected(); // this calls the
// expected version of readOp() }
1/10/2019
AP and AOP/Demeter Research Group

56. Example of an APPC (Adaptive Plug-and-Play Component) for ShowRAccess
class ShowRAccess {
class RDataToAccess {// one participant
Object expected_readOp();
Object replaced_readOp() {
System.out.println("Read access on "
+ this.toString());
return expected_readOp(); }
1/10/2019
AP and AOP/Demeter Research Group

57. 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 {... }
1/10/2019
AP and AOP/Demeter Research Group

58. AP and AOP/Demeter Research Group
Deployment
connector ShowRAccessConn1 {
Point is ShowRAccess.RDataToAccess
with {readOp = get*}; }
connector ShowReadAccessConn3 {
{Point, Line, Rectangle}
is ShowRAccess.RDataToAccess
with {readOp = get*; }
1/10/2019
AP and AOP/Demeter Research Group

59. Inheritance between components
class ShowRWriteAccess extends ShowReadAccess {
participant RWDataToAccess extends RDataToAccess{
expect void writeOp(Object[] args);
replace void writeOp(Object[] args){
System.out.println(
"Write access on " +
this.toString());
expected(args);}}}
1/10/2019
AP and AOP/Demeter Research Group

60. Inheritance between components
class ShowRWAccess extends ShowRAccess{
class RWDataToAccess extends RDataToAccess{
void expected_writeOp(Object[] args);
void replaced_writeOp(Object[] args){
System.out.println("Write access on " +
this.toString());
expected_writeOp(args); }
1/10/2019
AP and AOP/Demeter Research Group

61. Inheritance between connectors
connector ShowReadWriteAccessConn2 extends ShowReadAccessConn3 {
{Point,Line,Rectangle}
is DataToAccess with {
writeOp = set*; }
1/10/2019
AP and AOP/Demeter Research Group

62. AP and AOP/Demeter Research Group
What are APPC?
APPC 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 APPC to implement higher-level behavior cross-cutting the primary structure in a modular way
1/10/2019
AP and AOP/Demeter Research Group

63. AP and AOP/Demeter Research Group
What are APPC ?
APPC have provided and expected interfaces
The expected 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 components
APPC can be deployed into PGs or concrete class graphs and/or composed/refined by 3rd parties (reuse) by mapping interfaces via explicit connectors
1/10/2019
AP and AOP/Demeter Research Group

64. APPC + ... Participant Graph expected interfaces Behavior Definition
minimal
assumptions on
application structure
Participant Graph P1 P3 P2 +
expected interfaces
Behavior Definition P P1
meth
1,1
add new functionality +
enhance the expected
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

65. AP and AOP/Demeter Research Group
APPC
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
expects function members (keyword expect)
reimplementations (keyword replace)
local data and function members
1/10/2019
AP and AOP/Demeter Research Group

66. AP and AOP/Demeter Research Group
APPC (continued)
Local classes: visibility: APPC
APPC-level data and function members. There is a single copy of each global data member for each deployment
1/10/2019
AP and AOP/Demeter Research Group

67. Benefits of following Law of Demeter in Demeter Style
robustness to changes
shorter programs
design matches program
more understandable code, intent in program
partially automated evolution
keep all benefits of OO technology
improved productivity
ideas can be used without tools
Applicable to design and documentation
of your current systems with immediate benefits.
1/10/2019
AP and AOP/Demeter Research Group

68. AP and AOP/Demeter Research Group
Summary
Law of Demeter
First traversal specifications, key subconstruct for AP and AOP
Synchronization as an aspect
Fast and general compilation algorithm
APPCs (Adaptive Plug-and-Play Components): general construct for AOP
1987
1990
1993
1996/97
1998
1/10/2019
AP and AOP/Demeter Research Group

69. AP and AOP/Demeter Research Group
Discussion
Womble works fine for class graph extractions; it does not get cardinalities of relationships always right.
Terminal wrapper rule relevant in Daniel Jackson’s work.
2 kinds of satisfiability algorithms: Davis-Putnam style, and random walk.
Has tool that finds objects satisfying class graph and constraints
Same tool: takes class graph and constraints and method and creates pair of states that satisfy method and class graph and constraints
Nested polymorphic containers: Polymorphism not needed if good traversal technology available. Law of Demeter and nested containers. Check with DJ.
1/10/2019
AP and AOP/Demeter Research Group