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

2. Demeter Interfaces @ 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.

3. Demeter Interfaces @ 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.

4. Demeter Interfaces @ 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. In the 21 century we 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.

5. Demeter Interfaces @ 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.

6. Demeter Interfaces @ ETH6 Karl What kind of aspects satisfy the AP principle? We interpret “clients” loosely to mean programs that “use” this program. –aspects that use cflow or wildcards are interface-shy

7. Demeter Interfaces @ ETH7 Karl Rethink AOP Principle! Claim: AP Principle = AOP Principle because implementations can be changed anyway (within limits of interface).

8. Demeter Interfaces @ ETH8 How to achieve robustness to interface changes Build model of base program. Program in model-shy way. Keep model synchronized with base program when base program evolves in a base-program- shy way. This is at a more conceptual level than avoiding unanticipated captures and accidental misses when the base program evolves Old technique: program directly in shy way with respect to base program.

9. Demeter Interfaces @ ETH9 Not just extra level of indirection Extra level of indirection plus two structure-shy applications.

10. Demeter Interfaces @ ETH10 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

11. Demeter Interfaces @ ETH11

12. Demeter Interfaces @ ETH12 Demeter Interfaces: incremental development p1 –add behavior B p2 –add behavior B … What are the assumptions that B makes on the programs? interface(p1) != interface(p2)

13. Demeter Interfaces @ ETH13 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

14. Demeter Interfaces @ ETH14 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)

15. Demeter Interfaces @ ETH15 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 1 0..1 1

16. Demeter Interfaces @ ETH16 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

17. Demeter Interfaces @ ETH17 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 *

18. Demeter Interfaces @ ETH18 Class Diagram for simple equations EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs lhs op OpenParenCloseParen 0..1 *

19. Demeter Interfaces @ ETH19 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

20. Demeter Interfaces @ ETH20 Putting it all together Traversal aspects hold traversal specifications that link visitors to strategies. aspect CheckParens { declare strategy: toAll:"from Expression to *"; declare traversal: int unbalanced(): toAll(BalancedParenthesis); } Traversal aspects are extensions to AspectJ’s aspects. Traversal methods become (public) methods of their source classes

21. Demeter Interfaces @ ETH21 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.

22. Demeter Interfaces @ ETH22 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.

23. Demeter Interfaces @ ETH23 Class Diagram for simple equations EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs lhs op OpenParenCloseParen 0..1 *

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

25. Demeter Interfaces @ ETH25 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.

26. Demeter Interfaces @ ETH26 Writing the strategy: definedVars Capture definitions –Left-hand-side of equation defines one variable from EqSystem via ->*,lhs,* to Variable

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

28. Demeter Interfaces @ ETH28 Writing the strategy: usedVars Capture variable references –Right-hand-side of equation can refer to variable(s) multiple times. from EqSystem via −>*,rhs,* to Variable

29. Demeter Interfaces @ ETH29 Referenced variables. EqSystem Equation CompoundSimple Expr Op Add Times … Numerical Variable Ident Integer lrand rrand rhs op lhs OpenParenCloseParen 0..1 *

30. Demeter Interfaces @ ETH30 Traversal Aspects Visitors collect definitions and references. aspect SemanticChecker { declare strategy: definedVars:"from EqSystem via ->*,lhs,* to Variable"; declare strategy: usedVars:"from EqSystem via ->*,rhs,* to Variable"; declare traversal:void getDefined():definedVars(CollectDef); declare traversal:void getUsed():usedVars(CollectDef); } class CollectDef { void before(Variable v){System.out.println(v.toString());} }

31. Demeter Interfaces @ ETH31 Withstanding change Our program still works after –Changing infix notation to postfix or prefix We are really changing the order of member 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!

32. Demeter Interfaces @ ETH32 Problems with AP Hard coded name dependencies –Altering class (or edge) names that strategies or visitors depend on, e.g., lhs or Variable AP code unnecessarily hard to understand –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

33. Demeter Interfaces @ ETH33 Demeter Interfaces An interface between class graph and adaptive code. Demeter Interface Visitor ClassGraph Traversal Aspect

34. Demeter Interfaces @ ETH34 Demeter Interfaces Interface Class Graph –An abstraction on Class Graphs Accepts a list of traversal aspects 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 aspects that will use this Demeter Interface

35. Demeter Interfaces @ ETH35 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 * *

36. Demeter Interfaces @ ETH36 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 * * Ids -> Things

37. Demeter Interfaces @ ETH37 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 * *

38. Demeter Interfaces @ ETH38 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 –&& || !

39. Demeter Interfaces @ ETH39 Traversal Aspects 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

40. Demeter Interfaces @ ETH40 Visitors Visitors remain unchanged. No! Variable -> Thing class CollectDef { void before(Variable v){System.out.println(v.toString());} }

41. Demeter Interfaces @ ETH41 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.

42. Demeter Interfaces @ ETH42 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

43. Demeter Interfaces @ ETH43 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

44. Demeter Interfaces @ ETH44 A bit on implementation Phase I –AP code can be developed and statically checked Phase II –Mappings expanded and re- verify constraints

45. Demeter Interfaces @ ETH45 Surprise! No hard coded name dependencies –Mapping decouples naming dependencies Easier to understand AP code –No more noise, the ICG, traversal aspects 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.

46. Demeter Interfaces @ ETH46 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

47. Demeter Interfaces @ ETH47 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.

48. Demeter Interfaces @ ETH48 Future Challenges 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.

49. Demeter Interfaces @ ETH49 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

50. Demeter Interfaces @ ETH50 Related Work Mezini, Lieberherr, APPC, OOPSLA 98 Kiczales, Mezini: Modular Reasoning, ECOOP 2005 Sullivan, Griswold et al. XPI: FSE 2005 and IEEE Software 2006

51. Demeter Interfaces @ ETH51 Conclusions Demeter Interfaces: Sustain change / control uncertainty about structure of objects Next: Aspect Interfaces: Sustain change / control uncertainty about behavior and structure of objects

52. Demeter Interfaces @ ETH52 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.

53. Demeter Interfaces @ ETH53 Demeter Interfaces By nature challenging: is it too restrictive or too permissive? Define the scope of validity of a generic piece of software where many details of the context of use are left open. The Demeter Interface limits the possibility for the details.