demeter interfaces: ap without surprises prof. karl lieberherr and therapon skotiniotis, jeffrey...
TRANSCRIPT
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.
Demeter Interfaces @ ETH 3
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.
Demeter Interfaces @ ETH 4
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.
Demeter Interfaces @ ETH 5
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.
Demeter Interfaces @ ETH 6
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
Demeter Interfaces @ ETH 7
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
Demeter Interfaces @ ETH 8
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)
Demeter Interfaces @ ETH 9
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
Demeter Interfaces @ ETH 10
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
Demeter Interfaces @ ETH 11
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 *
Demeter Interfaces @ ETH 12
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
Demeter Interfaces @ ETH 13
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
Demeter Interfaces @ ETH 14
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.
Demeter Interfaces @ ETH 15
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.
Demeter Interfaces @ ETH 16
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
*
Demeter Interfaces @ ETH 17
Class Graph for simple equations
EqSystem Equation
Compound Simple
Expr
Op
Add Times…
Numerical Variable
IdentInteger
lrand
rran
d
rhs
op
lhs
OpenParen CloseParen
0..1 0..1
*
Demeter Interfaces @ ETH 18
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.
Demeter Interfaces @ ETH 19
Writing the strategy: DefinedIdents
• Capture definitions – Left-hand-side of equation defines one
variable
from EqSystem via ->*,lhs,*
to Variable
Demeter Interfaces @ ETH 20
Defined variables.EqSystem Equation
Compound Simple
Expr
Op
Add Times…
Numerical Variable
IdentInteger
lrand
rran
d
rhs
op
lhs
OpenParen CloseParen
0..1 0..1
*
Demeter Interfaces @ ETH 21
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
Demeter Interfaces @ ETH 22
Referenced variables.EqSystem Equation
Compound Simple
Expr
Op
Add Times…
Numerical Variable
IdentInteger
lrand
rran
d
rhs
op
lhs
OpenParen CloseParen
0..1 0..1
*
Demeter Interfaces @ ETH 23
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());}}
Demeter Interfaces @ ETH 24
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!
Demeter Interfaces @ ETH 25
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 @ ETH 26
Demeter Interfaces
• An interface between class graph and adaptive code.
Demeter Interface
Visitor
ClassGraph
Traversal File
Demeter Interfaces @ ETH 27
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
Demeter Interfaces @ ETH 28
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
*
*
Demeter Interfaces @ ETH 29
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
*
*
Demeter Interfaces @ ETH 30
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
*
*
Demeter Interfaces @ ETH 31
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– && || !
Demeter Interfaces @ ETH 32
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
Demeter Interfaces @ ETH 33
Visitors
• Visitors remain unchanged.
class CollectDef { void before(Variable v){System.out.println(v.toString());}}
Demeter Interfaces @ ETH 34
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.
Demeter Interfaces @ ETH 35
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
Demeter Interfaces @ ETH 36
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
Demeter Interfaces @ ETH 37
A bit on implementation
• Phase I– AP code can be
developed and statically checked
• Phase II– Mappings
expanded and re-verify constraints
Demeter Interfaces @ ETH 38
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.
Demeter Interfaces @ ETH 39
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
Demeter Interfaces @ ETH 40
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.
Demeter Interfaces @ ETH 41
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.
Demeter Interfaces @ ETH 42
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
Demeter Interfaces @ ETH 43
Conclusions
• Demeter Interfaces: Sustain change / control uncertainty about structure of objects
• Aspect Interfaces: Sustain change / control uncertainty about behavior and structure of objects
Demeter Interfaces @ ETH 44
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 @ ETH 45
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.