1. Adaptive Object-Oriented Software Development
The Demeter Method
First lecture, first class Sep25.
11/10/2018
AOOP / Demeter

2. Introduction Software engineering Programming languages
Hands-on, practical, useful
What the course is about
11/10/2018
AOOP / Demeter

3. Summary of Course
How to design and implement flexible object-oriented software using the principles of adaptiveness in combination with UML and Java.
How to design and implement flexible 100% pure Java software.
What audience will learn
11/10/2018
AOOP / Demeter

4. Who is in Attendance?
Software developers who have some experience with object-oriented programming.
Should know concepts of OOP, like classes, methods, and late binding.
11/10/2018
AOOP / Demeter

5. Agenda for Adaptive Object-Oriented Software/Demeter
Adaptive Programming
Aspect-Oriented Progr.
Demeter/Java
Java
Java environment
UML
XML
strategy graphs
class graphs
object graphs
state graphs
principles
heuristics
patterns
idioms
theorems
algorithms
requirements
domain analysis
design
implementation
use cases
interfaces
traversals
visitors
packages
Demeter Method
iterative development
spiral model
11/10/2018
AOOP / Demeter

6. Agenda
UML class diagrams. Perspective: analysis, design, implementation
Class graphs as special cases of UML class diagrams
Textual representation of class graphs
Default implementation of UML class diagrams as class graphs
topics covered and time allotted to each
11/10/2018
AOOP / Demeter

7. Agenda: UML collaborations as use case realizations
Participants
Behavior/Structure separation
Provided and required interface
11/10/2018
AOOP / Demeter

8. 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 ...
11/10/2018
AOOP / Demeter

9. Important concepts
Specification-level and instance-level collaborations
Roles
Connectors
Two aspects of collaborations: structural and behavioral
11/10/2018
AOOP / Demeter

10. High-level view of collaborations
A collaboration defines a context in which a behavior can be specified in terms of interactions between the participants of the collaboration.
A model describes a whole system; a collaboration is a slice or projection of that model.
11/10/2018
AOOP / Demeter

11. Specification-level and instance-level collaborations
Specification-level collaborations
great for imposing abstract patterns that you want to impose upon a system
Instance-level collaborations
show actual imprint of pattern upon a real system
11/10/2018
AOOP / Demeter

12. Instance-based collaborations
A group of collaborating objects performing some task together.
Not general; useful as examples.
11/10/2018
AOOP / Demeter

13. Specification-based collaborations
A group of collaborating roles specifying some task.
General; useful to specify behavior.
Has structural and behavioral part.
11/10/2018
AOOP / Demeter

14. Structural Part of a Bank (for bank-related collaborations)
/Party
/FinancialAsset
owns
0..*
0..*
uses
/BankingFacility
controls
0..*
11/10/2018
AOOP / Demeter

15. What are AP&PC? Adaptive Plug&Play Component
AP&PC are a language construct that captures behaviour involving several roles (cross-cuts class boundaries)
the programmer uses classes to implement the primary data (object) structure
the programmer uses AP&PC to implement higher-level behavior cross-cutting the primary structure in a modular way
11/10/2018
AOOP / Demeter

16. What are AP&PC ? AP&PC have provided and expected interfaces
The expected interface consists of an ideal role 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
AP&PC can be deployed into PGs or concrete class graphs and/or composed/refined by 3rd parties (reuse) by mapping interfaces via explicit connectors
11/10/2018
AOOP / Demeter

17. AP&PC + ... 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

18. AP&PC
A set of roles forming a graph called the participant graph (represented, e.g., by a UML class diagram). Participant
formal argument to be mapped
expects function members
(reimplementations)
local data and function members
11/10/2018
AOOP / Demeter

19. AP&PC (continued) Local classes: visibility: AP&PC
AP&PC-level data and function members. There is a single copy of each global data member for each deployment
11/10/2018
AOOP / Demeter

20. What is an AP&PC?
any identifiable slice of functionality that describes a meaningful service, involving, in general, several roles,
with well-defined expected and provided interfaces,
formulated for an ideal ontology - the expected interface
subject to deployment into several concrete ontologies by 3rd parties
subject to composition by 3rd parties
subject to refinement by 3rd parties
An ontology is, in simple terms, a collection of roles with
relations among them plus constraints on the relations.
11/10/2018
AOOP / Demeter

21. Collaboration deployment/composition
Deployment is mapping idealized ontology to concrete ontology
specified by connectors 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 one (lower-level) collaboration to the expected interface of another (higher-level) collaboration
deployment is a special case of composition, where the lower level
collaboration is a concrete ontology (no expected interface)
11/10/2018
AOOP / Demeter

22. The goal
The goal is to separate concerns (each decision in a single place) and minimize dependencies between them (loose coupling):
less tangled code, more natural code, smaller code
concerns easier to reason about, debug and change
a large class of modifications in the definition of one concern has a minimum impact on the others
more reusable, can plug/unplug as needed
11/10/2018
AOOP / Demeter

23. Deployment/Composition of AP&PCs
Specified by connectors separately from AP&PC
Connectors use
regular-expressions to express sets of method names and class names and interface names
standard code everywhere simple method name mapping is not enough
regular expression-like constructs for mapping graphs
11/10/2018
AOOP / Demeter

24. Deploying/Composing AP&PC
participant-to-class
name map
Application
Ideal Class Graph P1 P3
expected/provided interface map P2
link-to-paths
map
Behavior Definition P1 m
1,1
... m
1,k
APPC Compiler P1
executable
Java code

25. one slice of behavior reused with several applications
One AP&PC deployed into several applications
Application
participant-to-class
name map
Interface Class Graph P1 P2 P3
expected interface
map
Behavior Definition P1
participant-to-class
name map m
1,1
... m
1,k
expected interface
map
Application
one slice of behavior reused
with several applications
11/10/2018
AOOP / Demeter

26. Software Structure with AP&PCs
Collaborations are not explicit in the software. This is what AP&PCs will support. So why? P2 P2 P6 P1
11/10/2018
AOOP / Demeter

27. Ideal 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)
11/10/2018
AOOP / Demeter

28. Collaborations in UML 1.3
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: ClassifierRole, edges: AssociationRole, AssociationEndRole
11/10/2018
AOOP / Demeter

29. Collaborations in UML 1.3
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 /.
11/10/2018
AOOP / Demeter

30. Collaborations in UML 1.3 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 a connector (or adapter) that allows to implement the required features. The base classifier must only provide enough “ingredients” to implement the required interface.
11/10/2018
AOOP / Demeter

31. Collaborations in UML 1.3
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.
11/10/2018
AOOP / Demeter

32. Collaborations in UML 1.3
UML: An interaction specifies the communication between a set of interacting instances performing a specific task. Seems 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).
11/10/2018
AOOP / Demeter

33. UML ClassifierRole Diagram for Interest Calculation Collaboration
Position
Instrument
getInstrument 1
getInterestElements
0..*
InterestElement
11/10/2018
AOOP / Demeter

34. Interest Calculation Collaboration
Red: provided
Blue: required
Interest Calculation Collaboration
Position
interest (from,to){create interest elements for from-date to to-date using position and instrument information and add interest of all InterestElements}, getInstrument, getInterestElements
Instrument
getDaysInYear(y), ...
InterestElement interest (), ...
11/10/2018
AOOP / Demeter

35. Usage for Germany connector InterestInGermany
AlterSparKontoPosition is Position …
SparInstrument is Instrument with {
int getDaysInYear(Year y)
{return anzTageProJahr(y.conv());}...}
ZinsElement is InterestElement ...
11/10/2018
AOOP / Demeter

36. Examples of collaborations
Traversal/visitor style of programming
participant graph: roles participating in traversal
behavior: traversal through roles plus visitors
connectors: mapping of role names to classes and role methods to class methods (editor)
required interface: participant graph plus methods called from visitors
11/10/2018
AOOP / Demeter

37. Agenda UML interaction diagrams sequence diagrams
collaboration diagrams
improving interaction diagrams to make them specification languages
11/10/2018
AOOP / Demeter

38. Agenda Class graphs in textual form (construction, alternation)
object graphs (graphical and textual form)
object graphs defined by class graphs
add repetition classes and optional parts
translating class graphs to Java
topics covered and time allotted to each
11/10/2018
AOOP / Demeter

39. Agenda annotating class graph with syntax: class dictionary
printing objects and language defined by class dictionary
grammars, parsing, ambiguous grammars, undecidable problem
LL(1) grammars, robustness of sentences
etc.
topics covered and time allotted to each
11/10/2018
AOOP / Demeter

40. Overview good separation of concerns is the goal
concerns should be cleanly localized
programs should look like designs
Big picture
11/10/2018
AOOP / Demeter

41. Adaptive Programming Programs adapt to interesting context changes
Structure-shy behavior
Succinct representation of traversals
Programming in terms of graph constraints
11/10/2018
AOOP / Demeter

42. Cross-cutting of components and aspects
better program
ordinary program
structure-shy
functionality
Components
structure
Aspect 1
avoid tangled programs
AOP
synchronization
Aspect 2
11/10/2018
AOOP / Demeter

43. Aspect-Oriented Programming
components and aspect descriptions
High-level view,
implementation may
be different
From Gregor:
maybe source code should say: intermediate source code
add:
picture of a preprocessor style implementation of an AOP system
not all AOP systems will be preprocessor like. It is reasonable
to expect that in the future the better ones won’t be
this is a picture of what AOP is equivalent to, not necessarily how it works.
general AOP
Source Code
(tangled code)
weaver
(compile-
time)
11/10/2018
AOOP / Demeter

44. Examples of Aspects Synchronization of methods across classes
Remote invocation (using Java RMI)
Quality of Service (QoS)
Failure handling
External use (e.g., being a Java bean)
Replication, Migration
etc.
11/10/2018
AOOP / Demeter

45. Connections explain adaptive programming in terms of patterns
Aspect-Oriented Programming (AOP) is a generalization of Adaptive Programming (AP)
correspondence:
adaptive program : object-oriented program = sentence : object graph
explain how individual topics fit together
11/10/2018
AOOP / Demeter

46. Vocabulary Graph, nodes, edges, labels
Class graph, construction, alternation
Object graph, satisfying class graph
UML class diagram
Grammar, printing, parsing
Define terms, glossary
11/10/2018
AOOP / Demeter

47. Vocabulary Traversals, visitors Strategy graphs, path set 11/10/2018
Define terms, glossary
11/10/2018
AOOP / Demeter

48. Overview this lecture Basic UML class diagrams
Traversals/Collaborating classes
Traversal strategy graphs
Adaptive programming
Tools for adaptive programming
Demeter/Java and AP/Studio
11/10/2018
AOOP / Demeter

49. 1: Basic UML class diagrams
Graph with nodes and directed edges and labels for nodes and edges
Nodes: classes, edges: relationships
labels: class kind, edge kind, cardinality
explain details
give an example
exercise to re-enforce learning
11/10/2018
AOOP / Demeter

50. 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..*
11/10/2018
AOOP / Demeter

51. 2: Traversals / Collaborating classes
To process objects we need to traverse them
Traversal can be specified by a group of collaborating classes
11/10/2018
AOOP / Demeter

52. Collaborating Classes
use connectivity in class graph to define them succinctly
using strategy graphs
separating structure from behavior
teasing out the structure aspect
from Customer to Agent
from Company to Employee
11/10/2018
AOOP / Demeter

53. 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
11/10/2018
AOOP / Demeter
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

54. 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..*
11/10/2018
AOOP / Demeter

55. 3: 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
11/10/2018
AOOP / Demeter

56. 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..*
11/10/2018
AOOP / Demeter

57. 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..*
11/10/2018
AOOP / Demeter

58. 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..*
11/10/2018
AOOP / Demeter

59. 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..*
11/10/2018
AOOP / Demeter

60. 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
11/10/2018
AOOP / Demeter

61. 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..*
11/10/2018
AOOP / Demeter

62. 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..*
11/10/2018
AOOP / Demeter

63. 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
11/10/2018
AOOP / Demeter

64. Benefits of participant graph
Shields program from details of application class graph
Makes program more robust and simpler
11/10/2018
AOOP / Demeter

65. 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
11/10/2018
AOOP / Demeter

66. 4: Adaptive Programming
How can we use strategies to program?
Need to do useful work besides traversing: visitors
Incremental behavior composition using visitors
11/10/2018
AOOP / Demeter

67. 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.
11/10/2018
AOOP / Demeter

68. Writing Adaptive Programs with Strategies (Demeter/Java)
strategy: from BusRoute through BusStop to Person
BusRoute {
traversal waitingPersons(PersonVisitor) {
through BusStop to Person; } // from is implicit
int printCountWaitingPersons() // traversal/visitor weaving
= waitingPersons(PrintPersonVisitor);
PrintPersonVisitor {
before Person … }
PersonVisitor {init r = … }
can we really program with strategies? Here is how.
Extension of Java: keywords: traversal init
through bypassing to before after etc.
11/10/2018
AOOP / Demeter

69. 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
11/10/2018
AOOP / Demeter

70. 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
11/10/2018
AOOP / Demeter

71. Strategy Diagrams Class Diagrams Object Diagrams Adaptive Programming
are use-case based
abstractions of
Class Diagrams
New: abstractions of class diagrams
notice affinity to design patterns: some of them also talk about families
of class structures
explain strategies
define family of
Object Diagrams
11/10/2018
AOOP / Demeter

72. Strategy Diagrams Object Diagrams Adaptive Programming
define traversals of
explain strategies
Object Diagrams
11/10/2018
AOOP / Demeter

73. Strategy Diagrams Visitors Adaptive Programming guide and inform
explain strategies
Visitors
11/10/2018
AOOP / Demeter

74. Strategy Diagrams
BusRoute BusStop Person
Nodes: positive information: Mark corner stones in class graph: Overall topology
of collaborating classes. 3 nodes:
from BusRoute
through BusStop
to Person
explain strategies
11/10/2018
AOOP / Demeter

75. Strategy Diagrams Edges: negative information:
bypassing edges incident with Bus
BusRoute Person
Edges: negative information:
Delete edges from class diagram.
explain strategies
from BusRoute bypassing Bus to Person
11/10/2018
AOOP / Demeter

76. 5: Tools for Adaptive Programming
free and commercial tools available
11/10/2018
AOOP / Demeter

77. Free Tools on WWW DJ and AP Library Demeter/C++ Demeter/Java
Demeter/StKlos
Dem/Perl5
Dem/C++
Dem/CLOS
Demeter/Object Pascal
this technology is catching on
last four developed outside our group
11/10/2018
AOOP / Demeter

78. Commercial Tools available on WWW
StructureBuilder from Tendril Software Inc.
has support for DJ style actions
Neeraj Sangal, CEO
11/10/2018
AOOP / Demeter

79. Benefits of Demeter robustness to changes shorter programs
design matches program
more understandable code
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.
11/10/2018
AOOP / Demeter

80. Demeter/Java www.ccs.neu.edu/research/demeter class diagrams
functionality
strategies
visitors
etc.
Executable
Java code for your favorite
commercial Java Software Development Environment
more details on Demeter/Java
weaver
11/10/2018
AOOP / Demeter

81. Demeter/Java in Demeter/Java
structure (*.cd)
class diagrams
focus of this lecture
compiler/
weaver
structure-shy
behavior
(*.beh)
strategies and
visitors
structure-shy
communication
(*.ridl)
distribution
more details on Demeter components and aspects
structure-shy
object description
(*.input, at runtime)
synchronization (*.cool)
multi threading
11/10/2018
AOOP / Demeter

82. Cross-cutting in Demeter/Java
generated
Java program
Demeter/Java program
structure-shy
functionality
structure
replicated!
aspect descriptions are not just copied into programs, they may be replicated several times.
synchronization
11/10/2018
AOOP / Demeter

83. AP Studio visual development of traversal strategies relative
to class diagram
visual feedback about collaborating classes
visual development of annotated UML class diagrams
drawing class diagrams and visualizing strategies
11/10/2018
AOOP / Demeter

84. Strengths of Demeter/Java
Theory
Novel algorithms for strategies
Formal semantics
correctness theorems
Practice
Extensive feedback (8 years)
Reflective implementation
11/10/2018
AOOP / Demeter

85. Meeting the Needs Demeter/Java
Easier evolution of class diagrams (with strategy diagrams)
Easier evolution of behavior (with visitors)
Easier evolution of objects (with sentences)
11/10/2018
AOOP / Demeter

86. Real Life Used in several commercial projects
Implemented by several independent developers
Used in several courses, both academic and commercial
11/10/2018
AOOP / Demeter

87. Summary
What has been learned: Simple UML class diagrams, strategies and adaptive programs
How can you apply:
Demeter/Java takes adaptive programs as input
Document object-oriented programs with strategies
Design in terms of traversals and visitors
state what has been learned
define ways to apply training
11/10/2018
AOOP / Demeter

88. Where to get more information
Adaptive Programming book
UML Distilled
Demeter/Java home page
Course home page:
course/f98
11/10/2018
AOOP / Demeter

89. Feedback Request feedback of training session 11/10/2018
AOOP / Demeter