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. ECOOP 06

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 object’s interface, without affecting clients. • AP Principle, the interface of objects can be changed within certain parameters without affecting clients. ECOOP 06

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. AP Principle Black-box Principle : controls changes to ECOOP 06

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) ECOOP 06

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 ECOOP 06

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) + (y+9))) • Implement a semantic checker. • Each variable used must have been defined. ECOOP 06

8. Class Diagram for simple equations 1 …* EqSystem Equation lhs rhs Expr rrand lrand EqSystem = List(Equation). List(S) ~ “(“ S “)”. Compound Simple op Equation = <lhs> Variable <rhs> Expr. Op Variable Numerical Simple : Numerical | Variable. … Ident Integer Add Times ECOOP 06

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

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). ECOOP 06

11. Strategy specifications in DAJ • Defines a navigation specification on a class graph. Source to target from Equation to Variable ECOOP 06

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 ECOOP 06

13. Strategy specifications in DAJ • Defines a navigation specification on a class graph. Source to target through intermediate edges from Equation via ->Compound,op,Op to Ident ECOOP 06

14. Strategy specifications in DAJ • Defines a navigation specification on a class graph. Source to target abstracting over nodes/edges from Equation via ->Compound,*,* to * ECOOP 06

15. Writing the strategy for DefinedVars • Capture variable definitions • Left-hand-side of equation defines one variablefrom EqSystem via ->*,lhs,* to Variable ECOOP 06

16. Defined Variables. EqSystem Equation lhs rhs Expr rrand lrand Compound Simple op Op Variable Numerical … Ident Integer Add Times ECOOP 06

17. Writing the strategy forUsedVars • Capture variable references • Right-hand-side of equation can refer to variable(s).from EqSystem via −>*,rhs,* to Variable ECOOP 06

18. Used Variables. EqSystem Equation lhs rhs Expr rrand lrand Compound Simple op Op Variable Numerical … Ident Integer Add Times ECOOP 06

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 strategy’s source class • m traverses the data structure based on the strategy executing visitor methods along the way aspect SemanticChecker{ declarestrategy: definedVars:"from EqSystem via ->*,lhs,* to Variable"; declarestrategy: usedVars:"from EqSystem via ->*,rhs,* to Variable"; declare traversal:void getDefined():definedVars(CollectDef); declare traversal:void getUsed():usedVars(CollectDef); } ECOOP 06

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());} } ECOOP 06

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! ECOOP 06

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. ECOOP 06

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 ECOOP 06

24. ESystem * Definition body def Body DThing * UThing Thing 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 = <def> DThing ”=” <body> Body. Body = List(UThing). UThing = Thing. DThing = Thing. Thing = . List(S) ˜ ”(” S ”)”. } A list of traversal files that will use this Demeter Interface ECOOP 06

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 ECOOP 06

26. ESystem ESystem ESystem Definition Definition Definition Body DThing Body DThing Body DThing UThing Thing UThing Thing UThing Thing 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. ECOOP 06

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 • && || ! ECOOP 06

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 ECOOP 06

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 traversal:void printDefined():gdefinedVars(DVisitor); declare traversal:void 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 ECOOP 06

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 ECOOP 06

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 ECOOP 06

32. ESystem Definition Body DThing UThing Thing 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 ECOOP 06

33. One (or more) mapping for each implemented Demeter Interface Mappings cd 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 • We can map • A class to a classuse Variable as Thing • An edge to an edgeuse ->A,b,B as ->F,g,G • A strategy to a classuse ->*,lhs,* to Variable as DThing ECOOP 06

34. Putting it all together • Phase I • AP code can be developed and statically checked • Phase II • Mappings expanded • Constraints re-verified ECOOP 06

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. ECOOP 06

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) + (y+9))) ECOOP 06

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. ECOOP 06

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 series[Lämmel et. al.] • Investigate the similarities between SYB and DIs (types  classes, kinds  DIs). ECOOP 06

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. ECOOP 06

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 ECOOP 06

41. Thank you ECOOP 06

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) + (y+9))) ECOOP 06

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. AP Principle Black-box Principle AOP Principle : controls changes to ECOOP 06

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. ECOOP 06

45. Software Evolution • Software Systems continuously evolve. • System components • Allow for localized extensions/modifications • Guarantees of system’s 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. ECOOP 06

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 ECOOP 06