Demeter Interfaces: Adaptive Programming without Surprises

1
Demeter Interfaces Adaptive Programming
without Surprises

• Therapon Skotiniotis,
• Jeffrey Palm, Karl Lieberherr

College of Computer and Information
Science Northeastern University
2
Sustaining change

• Adaptive Programming (AP)
• Traversal related concerns over data structures.
• Graph based model of underlying data structure.
• Recover from, or adapt to, structural
  changes.Law of Demeter (LoD) talk only to your
  friends
• Removes hard-coded structural information.
• x a.b.c.d.f
• Encapsulates structural traversal concerns,
  increasing code modularity.

3
Some principles

• AP Principle builds on top of the Black-Box
  principle.
• Black- Box Principle, the representation of
  objects can be changed, within the constraints of
  the objects interface, without affecting
  clients.
• AP Principle, the interface of objects can be
  changed within certain parameters without
  affecting clients.

4
Role of Demeter Interfaces

• Make precise what is meant by within certain
  parameters
• Static verification
• Demeter Interfaces control how Object interfaces
  are allowed to change.

Paradigm Interface Client
Adaptive DemeterInterface DemeterClient
Object Oriented Interface Client
AP Principle
Black-box Principle
controls changes to
5
Adaptive Programming

• An AP program consists of
• a data structure
• traversal specification(s)
• computation

• In OO programs
• class graph (Class Diagram)
• traversal (DSL)
• visitor (Specialized Class)

6
Adaptive Programming in DAJ

• Adaptive Programming in Java/AspectJ
• Class Dictionary
• Textual representation of a Class Diagram
• Traversal File
• Strategy and traversal declarations
• Visitors
• Specialized Java classes

data structure
traversal specification(s)
computation
7
Running example in DAJ

• A simple equation system.
• Each equation defines one new variable
• Variables have global scope

( x 5 y (x - 2) z ((y-x) (y9)))

• Implement a semantic checker.
• Each variable used must have been defined.

8
Class Diagram for simple equations
1
EqSystem
Equation
lhs
rhs
Expr
rrand
lrand
EqSystem List(Equation). List(S) ( S ).
Compound
Simple
op
Equation ltlhsgt Variable ltrhsgt Expr.
Op
Variable
Numerical
Simple Numerical Variable.

Ident
Integer
Add
Times
9
Class Graph for simple equations
1
EqSystem
Equation
lhs
rhs
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
10
Writing the strategy

• A simple equation system.
• Each equation defines one new variable
• Variables have global scope
• Capture variable definitions
• Left-hand-side of equation defines one variable
• Capture variable references
• Right-hand-side of equation can refer to
  variable(s).

11
Strategy specifications in DAJ

• Defines a navigation specification on a class
  graph.

Source to target from Equation to Variable
12
Strategy specifications in DAJ

• Defines a navigation specification on a class
  graph.

Source to target through intermediate nodes from
Equation via Exp to Variable
13
Strategy specifications in DAJ

• Defines a navigation specification on a class
  graph.

Source to target through intermediate edges from
Equation via -gtCompound,op,Op to Ident
14
Strategy specifications in DAJ

• Defines a navigation specification on a class
  graph.

Source to target abstracting over
nodes/edges from Equation via
-gtCompound,, to
15
Writing the strategy for DefinedVars

• Capture variable definitions
• Left-hand-side of equation defines one
  variablefrom EqSystem via -gt,lhs,
• to Variable

16
Defined Variables.
EqSystem
Equation
lhs
rhs
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
17
Writing the strategy forUsedVars

• Capture variable references
• Right-hand-side of equation can refer to
  variable(s).from EqSystem
• via -gt,rhs,
• to Variable

18
Used Variables.
EqSystem
Equation
lhs
rhs
Expr
rrand
lrand
Compound
Simple
op
Op
Variable
Numerical

Ident
Integer
Add
Times
19
Defining Traversals

• Traversal files extend AspectJ aspects to allow
  inter-type declarations.
• Traversal specifies
• Method signature m and strategy with a Visitor
• Generate method m in strategys source class
• m traverses the data structure based on the
  strategy executing visitor methods along the way

aspect SemanticChecker declare strategy
definedVars"from EqSystem via -gt,lhs, to
Variable" declare strategy usedVars"from
EqSystem via -gt,rhs, to Variable" declare
traversalvoid getDefined()definedVars(CollectDef
) declare traversalvoid getUsed()usedVars(Coll
ectDef)
20
Visitors

• Standard Java Classes
• before methods
• Before traversing an object of arg type
• after methods
• After traversing an object of arg type

class CollectDef void before(Variable
v)System.out.println(v.toString())
21
Withstanding change

• Our program still works after
• Changing infix notation to postfix or prefix.
• Refactor Compound to make subexpressions parts of
  the Operator Class.
• Does not affect paths to defined and used
  variables
• Adding new operations, e.g., exponentiation
• Variable references are now in the exponent field
  but our strategies can deal with it!

22
Problems with AP

• Hard coded name dependencies.
• Altering class (or edge) names that strategies or
  visitors depend on, e.g., lhs or Variable.
• Harder to understand AP code.
• Larger class graphs have too much noise.
• AP code dependency on implicit assumptions
• Adding one argument functions introduces two
  variable definitions with different scopes.
• No warnings or guarantees
• AP program gives wrong results.

23
Demeter Interfaces

• Interface Class Graph
• Introduce an interface between class graph and
  adaptive code.
• Constraints
• Explicitly define further structural restrictions

Demeter Interface
uses
implements
Traversal File
ClassGraph
Visitor
24
Interface Class Graph (ICG)

• Interface Class Graph. Mezini et. al. 98
• An abstraction on Class Graphs.
• Accepts a list of traversal files.

di ExprICG with SemanticChecker ESystem
List(Definition). Definition ltdefgt
DThing ltbodygt Body. Body List(UThing). UThin
g Thing. DThing Thing. Thing . List(S)
( S ).
A list of traversal files that will use this
Demeter Interface
25
Interface Class Graph (ICG)

• Contains only the relevant nodes and edges
• For a semantic checker, definitions and
  references
• Strategies and traversals are defined on the ICG
• Visitors use classes in the ICG

ESystem

Definition
body
def
Body
DThing

UThing
Thing
26
Strategies

• Defined entities
• gdefinedVars from Esystem via DThing to Thing
• gusedVars from Esystem via UThing to Thing
• Strategies are defined on the ICG.
• Visitors use classes in the ICG.

27
Constraints

• Define conditions that need to hold of the
  underlying data structure in terms of sets of
  paths.
• Constraint primitives
• unique(s) , nonempty(s),
• subset(s1,s2), equal(s1,s2)
• Logical connectives
• !

28
Capture assumptions using Constraints

• Further structural restrictions.
• Recall
• One new variable per equation
• unique(from Definition via DThing to Thing)
• Strategies are non-empty
• nonempty(gdefinedVars)
• nonempty(gusedVars)

ESystem
Definition
unique
Body
DThing
UThing
Thing
29
Traversal Files and constraints
aspect SemanticChecker with DVisitor declare
strategy gdefinedVars from ESystem via
DThing to Thing declare strategy gusedVars
from ESystem via UThing to Thing declare
strategy definedVar from Definition via
DThing to Thing declare traversalvoid
printDefined()gdefinedVars(DVisitor) declare
traversalvoid printUsed()gusedVars(DVisitor)
declare constraints unique(definedVar),
nonempty(gusedVars), nonempty(gdefinedVars).
Accepts a list of Visitors that will be used in
traversals
Constraints on strategies make implicit
assumptions about the class graph explicit
30
Visitors

• Visitors are defined against the ICG.

class CollectDef void before(Thing
t)System.out.println(t.toString())

• Abstracted self-contained component

Demeter Interface
uses
Traversal File
Visitor
31
Connecting Demeter Interfaces with a concrete
Class Graph

• Class graphs explicitly state which Demeter
  Interfaces they implement
• Provide a mapping to all the ICG entities for
  each Demeter Interface

Demeter Interface
uses
implements
Traversal File
ClassGraph
Visitor
32
All ICG entities need to be mapped


EqSystem
Equation
Equation
Equation
lhs
rhs
Expr
Expr
rrand
lrand

ICG
Compound
Simple
Compound
Simple
op
Op
Class Dictionary
Variable
Variable
Variable
Variable
Variable
Numerical

Add
Times
Ident
Integer
33
Mappings
cd InfixEQSystem implements ExprICG
EquationSystem lteqsgt List(Equation). // Same
as before. for ExprICG ( use EquationSystem as
ESystem, use Equation as Definition, use Expr
as Body, use (-gt,lhs,Variable) as DThing, use
(-gt,rhs, to Variable) as UThing, use Variable
as Thing)
List of implemented Demeter Interfaces

• We can map
• A class to a classuse Variable as Thing
• An edge to an edgeuse -gtA,b,B as -gtF,g,G
• A strategy to a classuse -gt,lhs, to Variable
  as DThing

34
Putting it all together

• Phase I
• AP code can be developed and statically checked
• Phase II
• Mappings expanded
• Constraints re-verified

35
Surprise!

• No hard-coded name dependencies
• Mapping decouples naming dependencies
• Easier to understand AP code
• No more noise, the ICG, traversal files and
  visitors have all the information
• No more implicit assumptions
• Constraints have made these explicit and
  statically verifiable!
• Naïve addition of one argument functions gives a
  compile time error, unique fails.

36
Sustaining change

• AP Principle, the interface of objects can be
  changed within the constraints specified by the
  adaptive code without affecting clients.

• Changes to AST due to refactoring
• Adding new operators
• Adding new ways to define and use variables,
  e.g., one argument functions

• Changes to AST due to refactoring
• Adding new operators
• Adding new ways to define and use variables,
  e.g., one argument functions

( x 5 y (x - 2) z ((y-x) (y9)))
37
Modularity and Reuse

• Modular AP code
• Provide an explicit interface
• Smaller interface between AP code and rest of the
  system
• Hide irrelevant class graph information
• Linguistic units for Demeter Interfaces
• Reusable AP code
• Multiple Demeter Interfaces on a single class
  graph
• Multiple mappings of a Demeter Interface
• Easier reuse of AP code across different class
  graphs
• Reuse of traversals and visitor code.

38
Not just for Demeter

• Connection between Demeter and XML Lieberherr
  et. al.
• Interfaces for DTDs and XPath, comparison to
  recent work by Lämmel Scrap your XML-plate.
• Data-type generic programming Gibbons, Hinze
  et. al.
• DAJ and DIs provide a comparable way for
  data-type generic programming in OO
• Scrap Your Boilerplate paper seriesLämmel et.
  al.
• Investigate the similarities between SYB and DIs
  (types ? classes, kinds ? DIs).

39
Future Challenges

• Extend mapping mechanism
• Partly defined mappings and use of
  inference/unification.
• Composition of Demeter Interfaces
• Attachment at leaf nodes, intermediate nodes
• Control visibility of composite DI
• Extend DI Constraints to Object level constraints.

40
Conclusion

• Interface between AP code and Class Graph
• Define and verify interface properties
• Enforced on implementing clients
• AP code becomes more modular, reusable and
  resilient.
• Code for a whole family of applications

Thank you
41
Thank you
42
Sustaining change

• AP Principle, the interface of objects can be
  changed within certain parameters without
  affecting clients

• Changes to AST due to refactoring
• Adding new operators
• Adding new ways to define and use variables,
  e.g., one argument functions

• Changes to AST due to refactoring
• Adding new operators
• Adding new ways to define and use variables,
  e.g., one argument functions

( x 5 y (x - 2) z ((y-x) (y9)))
43
Role of Demeter Interfaces

• Make precise what is meant by within certain
  parameters
• Static verification
• Demeter Interfaces control how Object interfaces
  are allowed to change.

Paradigm Interface Client
Adaptive DemeterInterface DemeterClient
Object Oriented Interface Client
Aspect Oriented AspectInterface AspectClient
AP Principle
Black-box Principle
AOP Principle
controls changes to
44
Reuse

• Multiple Demeter Interfaces can be used on a
  single class graph
• Multiple mappings of a Demeter Interface on the
  same class graph
• Easier reuse of Demeter Interfaces across
  different class graphs
• Reuse of traversals and visitor code.

45
Software Evolution

• Software Systems continuously evolve.
• System components
• Allow for localized extensions/modifications
• Guarantees of systems properties
• Developed principles language support
• Information hiding, Black-Box principle
• Interfaces, Type Systems
• Can we sustain more drastic changes?
• Changes to interfaces?
• Information hiding is good for protecting against
  changes in data representation.

46
Outline

• Introduction to Adaptive Programming
• Problems with Adaptive Programming and their
  solution with Demeter Interfaces
• Evaluation of Demeter Interfaces
• Solve AP problems
• Higher modularity and reuse
• Demeter Interfaces and beyond
• Scrap your XML-plate (Lämmel),
• Data-type generic programming for OO
• Future challenges