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

Demeter ETH2 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 ETH3 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 ETH4 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 ETH5 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 ETH6 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. InterfaceClient Adaptive Demeter Interface Demeter Client Object Oriented InterfaceClient Aspect Oriented Aspect Interface Aspect Client

Demeter ETH7 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 ETH8 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 ETH9 Class graph in DAJ Textual notation for specifying the class graph FG A C = D [ F] E. A : F G D E C e d F f

Demeter ETH10 Class graph in DAJ (cont) The textual notation also defines an input grammar. –Text in double quotes denotes syntax tokens. C = “date” D “event” E. D = int “/” int “/” int. E = String. date 10/11/2006 event Party Event.cd Input.txt

Demeter ETH11 Strategy specifications in DAJ Defines a navigation specification on a class graph. –Target to source from A to B –With explicit intermediate nodes and edges from A via C to B from A bypassing C to B from A via -> C,d,D to B –Abstracting nodes with “ * ” pattern from A via C to *

Demeter ETH12 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 ETH13 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 ETH14 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 ETH15 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 ETH16 Class Diagram for simple equations EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs lhs op OpenParenCloseParen 0..1 *

Demeter ETH17 Class Graph for simple equations EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs op lhs OpenParenCloseParen 0..1 *

Demeter ETH18 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 ETH19 Writing the strategy: DefinedIdents Capture definitions –Left-hand-side of equation defines one variable from EqSystem via ->*,lhs,* to Variable

Demeter ETH20 Defined variables. EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs op lhs OpenParenCloseParen 0..1 *

Demeter ETH21 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 ETH22 Referenced variables. EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs op lhs OpenParenCloseParen 0..1 *

Demeter ETH23 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 ETH24 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 ETH25 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 ETH26 Demeter Interfaces An interface between class graph and adaptive code. Demeter Interface Visitor ClassGraph Traversal File

Demeter ETH27 Demeter Interfaces Interface Class Graph –An abstraction on Class Graphs Accepts a list of traversal files di ExprICG with SemanticChecker{ ESystem = List(Definition). Definition = DThing ”=” Body. Body = List(UThing). UThing = Thing. DThing = Thing. Thing =. List(S) ˜ ”(” S ”)”. } List(s) defines collections whose elements are of type S A list of traversal files that will use this Demeter Interface

Demeter ETH28 Interface Class Graph (ICG) ESystem Definition BodyDThing UThingThing 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 bodydef * *

Demeter ETH29 Strategies ESystem Definition BodyDThing UThingThing Defined entities –gdefinedIds = from ESystem via DThing to Thing –gusedIds = from ESystem via UThing to Thing ESystem Definition BodyDThing UThingThing ESystem Definition BodyDThing UThingThing * *

Demeter ETH30 Constraints Recall –One new variable per equation –unique(from Definition via DThing to Thing) Strategies are non- empty –nonempty(gdefinedIds) –nonempty(gusedIds) ESystem Definition BodyDThing UThingThing unique * *

Demeter ETH31 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(s 1,s 2 ), equal(s 1,s 2 ) Logical connectives –&& || !

Demeter ETH32 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 ETH33 Visitors Visitors remain unchanged. class CollectDef { void before(Variable v){System.out.println(v.toString());} }

Demeter ETH34 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 ETH35 All ICG entities need to be mapped ESystem Definition BodyDThing UThingThing EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrandrrand rhs lhs op OpenParenCloseParen 0..1 * * * Equation Variable CompoundSimple Expr Variable Equation Variable

Demeter ETH36 Mappings cd InfixEQSystem implements ExprICG { EquationSystem = 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 edge use ->A,b,B as ->F,g,G 3.A strategy to a class use ->*,lhs,Variable as DThing

Demeter ETH37 A bit on implementation Phase I –AP code can be developed and statically checked Phase II –Mappings expanded and re- verify constraints

Demeter ETH38 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 ETH39 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 ETH40 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 ETH41 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 ETH42 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 ETH43 Conclusions Demeter Interfaces: Sustain change / control uncertainty about structure of objects Aspect Interfaces: Sustain change / control uncertainty about behavior and structure of objects

Demeter ETH44 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 ETH45 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.