Demeter Interfaces: AP without Surprises Prof. Karl Lieberherr and Therapon Skotiniotis, Jeffrey Palm.

Demeter Interfaces: AP without Surprises

Prof. Karl Lieberherrand

Therapon Skotiniotis, Jeffrey Palm

Demeter Interfaces @ ETH 2

Sustaining change

• Software systems continuously evolve

• Software engineers developed principles to ease evolution – Interfaces – Information hiding – Black-Box principle

• Support alterations without affecting clients.


Second view: Working with incomplete information

• Scientists (e.g., biologists) need to reason about reactive systems (e.g., cells or organs or organisms) which are incompletely known.

• How can we specify behavior without knowing the details of the structure.

• Define interface that captures the scope of the allowed details.


Sustaining change

• Can we sustain changes to interfaces?– information-hiding is good to protect against

changes in data representation. – Does not help with changes to interfaces.

• Need to protect against interface changes.• AP lets the program recover from (or adapt

to) interface changes. – This is similar to the shyness metaphor in the

Law of Demeter (LoD): structure evolves over time, thus communicate with just a subset of the visible objects.


Decoupling of Interface

– Black-box Principle: the representation of objects can be changed without affecting clients.

– AP Principle: the interface of objects can be changed within certain parameters without affecting clients.

• AP Principle builds on top of the Black-Box principle.

• AOP Principle: the interface or implementation of objects can be changed within certain parameters without affecting aspect clients.


Role of Demeter Interfaces• Make precise what

is meant by “within certain parameters”.– Static verification

• Demeter Interface controls how interface is allowed to change.

AP Principle

Black-box Principle

AOP Principle

: controls changes to

Paradigm/Impl.

Interface

Client

AdaptiveDemeterInterface

DemeterClient

ObjectOriented

Interface

Client

AspectOriented

AspectInterface

AspectClient


Outline

• Introduction to AP (in DAJ)• Problems with AP • Solution: Demeter Interfaces• Evaluation of Demeter Interfaces

– Solve AP problems– Higher modularity and reuse

• Future challenges of Demeter Interfaces


Introduction to AP

• An AP program is made up of :– a data structure – a traversal

specification– a computation

• For OO programs – class graph

(Class Diagram)– traversal

( DSL language) – visitor

(Specialized Class)


Class graph in DAJ

• Textual notation for specifying the class graph

F G

A

C = <d>D [<f> F] <e>E.

A : F G

D

E

C

e

d

Ff

1

0..1

1


Class graph in DAJ (cont)

• The textual notation also defines an input grammar. – Text in double quotes denotes syntax tokens.

C = “date” <d>D “event”<e>E.

D = <m> int “/” <d> int “/” <y> int.

E = String.

date 10/11/2006 event Party

Event.cd

Input.txt


Strategy specifications in DAJ

• Defines a navigation specification on a class graph. – Target to sourcefrom A to B

– With explicit intermediate nodes and edgesfrom A via C to B from A bypassing C to B from A via -> C,d,D to B

– Abstracting nodes with “*” patternfrom A via C to *


Visitors in DAJ

• Specialized classes with methods that are executed before or after a node is reached

class BalancedParenthesis{ int openParen = 0;int closeParen = 0;

void before(OpenParen op){ openParen++;}void after(CloseParen co) { closeParen++;}int return(){ return openParen – closeParen;}

}

Before traversing an object of type OpenParen

After traversing an object of type CloseParen

Value returned by the Visitor at the end of the traversal


Putting it all together

• Traversal files hold traversal specifications that link visitors to strategies.

aspect CheckParens { declare strategy: toAll:"from Expression to *"; declare traversal: int unbalanced():

toAll(BalancedParenthesis); }

• Traversal files are extensions to AspectJ’s aspects. • Traversal methods become (public) methods of their

source classes


AP, what is it good for?

• Removes hard-coded structural information. – {x = a.b.c.d.f;}

• Encapsulates structural traversal concerns, increasing code modularity.

• Programs remain “correct” after certain modifications to the underlying data structure.


Running example in DAJ

• A simple equation system.– each equation defines a new variable– variables have global scope

( x = 5; y = (x − 2); z = ((y−x) + (y+9)))

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


Class Diagram for simple equations

EqSystem Equation

Compound Simple

Expr

Op

Add Times…

Numerical Variable

IdentInteger

lrand

rran

drhs

lhs

op

OpenParen CloseParen

0..1 0..1

*


Class Graph for simple equations

EqSystem Equation

Compound Simple

Expr

Op

Add Times…

Numerical Variable

IdentInteger

lrand

rran

d

rhs

op

lhs


0..1 0..1

*


Writing the strategy

• A simple equation system– each equation defines a new variable– Variables have global scope

• Capture definitions – Left-hand-side of equation defines one

variable• Capture variable references

– Right-hand-side of equation may refer to variable(s) multiple times.


Writing the strategy: DefinedIdents

• Capture definitions – Left-hand-side of equation defines one

variable

from EqSystem via ->*,lhs,*

to Variable


Defined variables.EqSystem Equation

Compound Simple

Expr

Op

Add Times…

Numerical Variable

IdentInteger

lrand

rran

d

rhs

op

lhs


0..1 0..1

*


Writing the strategy:UsedIdents

• Capture variable references– Right-hand-side of equation can refer to

variable(s) multiple times.

from EqSystem

via −>*,rhs,*

to Variable


Referenced variables.EqSystem Equation

Compound Simple

Expr

Op

Add Times…

Numerical Variable

IdentInteger

lrand

rran

d

rhs

op

lhs


0..1 0..1

*


Traversal Files

• Visitors collect definitions and references.

aspect SemanticChecker { declare strategy: definedIds:"from EqSystem via ->*,lhs,* to Variable"; declare strategy: usedIds:"from EqSystem via ->*,rhs,* to Variable"; declare traversal:void getDefined():definedIds(CollectDef); declare traversal:void getUsed():usedIds(CollectDef); }

class CollectDef { void before(Variable v){System.out.println(v.toString());}}


Withstanding change

• Our program still works after – Changing infix notation to postfix or prefix

• We are really changing the order of members definitions in Compound

– Refactor Compound and move llrand and rrand to classes denoting math operators• This does not affect our 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!


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.– AP program compiles fine but gives wrong

results


Demeter Interfaces

• An interface between class graph and adaptive code.

Demeter Interface

Visitor

ClassGraph

Traversal File


Demeter Interfaces

• Interface Class Graph– An abstraction

on Class Graphs

• Accepts a list of traversal files

di ExprICG with SemanticChecker{ ESystem = List(Definition). Definition = <def> DThing ”=” <body> Body.Body = List(UThing).UThing = Thing.DThing = Thing.Thing = .List(S) ˜ ”(” S ”)”.}

List(s) defines collections whose elements are of type SA list of traversal files that will

use this Demeter Interface


Interface Class Graph (ICG)

ESystem

Definition

Body DThing

UThing Thing

• Contains only the relevant nodes and edges – For a semantic

checker, definitions and references

• Strategies are defined on the ICG

• Visitors use classes in the ICG

body def

*

*


Strategies

ESystem

Definition

Body DThing

UThing Thing

• Defined entities – gdefinedIds = from ESystem via DThing to Thing

– gusedIds =from ESystem via UThing to Thing

ESystem

Definition

Body DThing

UThing Thing

ESystem

Definition

Body DThing

UThing Thing

*

*


Constraints• Recall

– One new variable per equation

– unique(from Definition via DThing to Thing)

• Strategies are non-empty– nonempty(gdefinedIds)– nonempty(gusedIds)

ESystem

Definition

Body DThing

UThing Thing

unique

*

*


Constraints• Define conditions that need to hold of

the underlying data structure in terms of paths.

• Language of constraints provides – unique(s) , nonempty(s), – subset(s1,s2), equal(s1,s2)

• Logical connectives– && || !


Traversal Files and constraints

aspect SemanticChecker with DVisitor{ declare strategy: gdefinedIdents:

”from ESystem via DThing to Thing”. declare strategy: gusedIdents: ”from ESystem via UThing to Thing”. declare strategy definedIdent: ”from Definition via DThing to Thing”. declare traversal:void printDefined():gdefinedIdents(DVisitor); declare traversal:void printUsed():gusedIdents(DVisitor);

declare constraints: unique(definedIdent), nonempty(gusedIdents), nonempty(gdefinedIdents).}

Accepts a list of Visitors that will be used in traversals

Constraints on strategies make implicit assumptions

about the class graph explicit


Visitors

• Visitors remain unchanged.

class CollectDef { void before(Variable v){System.out.println(v.toString());}}


Connecting Demeter Interfaces

with a concrete class graph• Class graphs have to explicitly state

which Demeter Interfaces they implement

• Provide a mapping to the ICG entities for each Demeter Interface a class graph implements.


All ICG entities need to be mapped

ESystem

Definition

Body DThing

UThing Thing

EqSystem Equation

Compound Simple

Expr

Op

Add Times…Numerical Variable

IdentInteger

lrand

rran

d

rhs lhsop

OpenParen CloseParen0..1 0..1

*

*

* Equation

Variable

Compound Simple

Expr

VariableVariable

Equation

Variable


Mappingscd InfixEQSystem implements ExprICG {EquationSystem = <eqs> List(Equation).// Same as before.

for ExprICG ( use EquationSystem as ESystem, use Equation as Definition, use Expr as Body, use (−>*,lhs,Variable) as DThing, use (−>*,rhs,* to Variable) as UThing, use Variable as Thing)}

List of implemented Demeter Interfaces

One mapping for each implemented Demeter Interface

We can map 1. A class to a class

use Variable as Thing

2. An edge to an edgeuse ->A,b,B as ->F,g,G

3. A strategy to a classuse ->*,lhs,Variable as DThing


A bit on implementation

• Phase I– AP code can be

developed and statically checked

• Phase II– Mappings

expanded and re-verify constraints


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

• No more implicit assumptions– Constraints have made these explicit and

statically verifiable! (Phase I and Phase II)– Naïve addition of one argument functions

gives a compile time error, unique fails.


Modularity

• Demeter Interfaces – Provides an explicit interface – Smaller interface between AP code and

the rest of the system– Hides class graph information that is

irrelevant to AP code– Linguistic units for Demeter Interfaces


Reuse

• Multiple Demeter Interfaces can be used on a single class graph

• Multiple mappings of the a Demeter Interface on the same class graph

• Easier reuse of Demeter Interfaces across different class graphs– Reuse of traversals and visitor code.


Future Challenges

• Extend mapping mechanism– Partly defined mappings and use of

inference/unification.

• Composition of Demeter Interfaces– Attachment at leaf nodes– Attachment at intermediate nodes– Composition exposes certain details of the new

composite interface while hiding others

• Interfaces for general purpose Aspects.– Sequence diagrams as an abstraction of the

dynamic call graph.


Interfaces for general purpose AOP

• Aspects add/replace behavior based on messages between objects

• Specify the communication protocol between components (abstraction of dynamic call graph)– Expose/hide messages to/from aspects

• Constraints on communication protocol – Stop aspects form breaking invariants.– Runtime verification


Conclusions

• Demeter Interfaces: Sustain change / control uncertainty about structure of objects

• Aspect Interfaces: Sustain change / control uncertainty about behavior and structure of objects


DIs and partial information

• DIs are about programming with partial information about object structure.

• DIs are about knowing exactly what you can depend on in the details of the object structure that you don’t know yet.


Demeter Interfaces

• By nature hard to define• Define the scope of validity of a

generic piece of software where many details are left open

• The Demeter Interface limits the possibility for the details.

Demeter Interfaces: AP without Surprises Prof. Karl Lieberherr and Therapon Skotiniotis, Jeffrey Palm.

Documents