1 Shyness in Programming Karl Lieberherr Demeter Research Group Northeastern University Boston

2 XAspects Go to slide 49

3 Coupling Aspect-Oriented and Adaptive Programming: Shyness in Programming PhD Visitation Weekend 2003

4 Our Intuition behind AOP Our Aspect-Oriented Programming (AOP) intuition has been: "adaptiveness". It comes in two flavors: adaptiveness –to the class graph ("painting the class graph in broad strokes with code") and –to the call graph of the traversal ("picking points in the graph where additional code gets called").

5 MIT Technology Review 2001 Aspect-oriented programming is called “adaptive programming” at Northeastern University.

6 Definitions y is x-shy if: (1) y relies only on minimal information of x (2) y can adapt to small changes in x (3) y is loosely coupled with x (4) y can work with x1, x2,... which are close or similar to x. What is a concern? A concern is something that the programmer cares about.

7 Examples of concerns the programmer has to deal with Production concerns –How do I compute the price allowing for multiple pricing schemes? Non-Production concerns –What do I have to print to understand why this program does not work? –Are all objects of class A created in class Afactory?

8 Scattering and Tangling: Static aspect i is scattered across many classes (i = 1,2,3) class X tangles aspects 1, 2 and 3 aspect1aspect2aspect3 class A consisting of three aspects classes for aspect1 classes for aspect2 classes for aspect3 Class X class diagram Adding to classes

9 Scattering and Tangling: Dynamic program execution involving three aspects (colors r b g) program call tree (classes executing method calls) Each aspect (colors) is scattered across many classes (shapes) Class tangles all three aspects At those calls the aspect enhances the behavior classes this(s) target(t) f(..) Enhancing calls t.f(..);

10 AP-Concern-shy Program with multiple building blocks, say b1:B1 and b2:B2, that are woven together: b1*b2. b1 relies only on partial information about b2 which makes b1 more robust and reusable. Goal: b1 should be loosely coupled to b2. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

11 Law of Demeter (LoD) for Concerns A concern implementation should not rely on too much information about other concern implementations. (Classic LoD: A method should not rely on too much information about other classes/objects.) Ian Holland PhD 1992: Vice President of Architecture and Systems Engineering at Kronos Incorporated in Chelmsford, MA empls.

12 Adaptive Programming. AP-Concern-shy: concerns shy of other concerns –AP-Structure-shy: concerns shy of graph structure AP-WildCard: aspects shy through wildcards –AspectJ: *,.., this, target, args, call, execution, … (call graph) AP-Strategy: three level model using strategies –AP-Call: aspects shy of call graph using strategies »AspectJ: cflow –AP-Demeter: behavior shy of class graph using strategies; advice on traversal »AP-DJ: ClassGraph, Strategy, Visitor (in Java) »AP-DAJ: Strategy enhances ClassGraph; Visitor enhances traversal defined by Strategy (in AspectJ) »AP-DemeterJ (new programming language) Best of both worlds 50 pages of theory

13 Adaptive Programming. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter AP-Concern-shy –AP-Graph-shy AP-CallGraph-shy AP-ClassGraph-shy –AP-WildCard –AP-Strategy Alternative organization: X-shy subX-shy Mechanism-to-achieve-shyness

14 AP-Structure-shy Program with multiple building blocks including b1and b2:Graph, that are woven together. b1 relies only on partial information about b2 which makes b1 more robust and reusable. Goal: b1 should be loosely coupled to b2. b1 enhances b2 at nodes and edges. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

15 AP-WildCard Program with multiple building blocks including b1 and b2:Graph, that are woven together. b1 uses wildcard techniques which makes b1 more robust and reusable. Goal: b1 should be loosely coupled to b2. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

16 AP-Strategy Program with multiple building blocks including b1:Strategy and b2:Graph, that are woven together. b1 reveals only partial information about b2 which makes b1 more robust and reusable. b1 is written against an abstraction of b2 so that the application to b2 is well defined. Goal: b1 should be loosely coupled to b2. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter One contributor: Ignacio Silva-Lepe PhD 1994 Currently at IBM Watson Research Lab

17 A General Strategy-based Adaptive Mechanism Three layers of graphs: Bottom, Middle, Top –Bottom layer: trees to select subtrees guided by top layer. Each bottom layer tree has a graph from the –Middle layer associated with it that contains meta- information about the bottom layer tree. Acts as an abstraction barrier between the top and bottom layers. Used to reduce search space. –Top layer graph is basically a subgraph of the transitive closure of the middle layer graph, decorated with additional information attached to the edges. From TOPLAS 2003 paper (Lieberherr, Patt-Shamir, Orleans)

18 Middle graph: Abstraction barrier Bottom tree: select subtrees A B A B C Top graph: subgraph of transitive closure of middle layer C A B c1:C c2:C c3:C

19 Strategy-based adaptiveness The call graph application (AspectJ): –Top: computational pattern, –Middle: static call graph, –Bottom: call tree. The standard application (Demeter): –Top: strategy graph, –Middle: class graph, –Bottom: object trees.

20 AP-Call Program with multiple building blocks including b1:CrossCut and b2:CallGraph, that are woven together. b1 reveals only partial information about b2 which makes b1 more robust and reusable. Advice on b2 at b1. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

21 AP-AspectJ Program with multiple building blocks including b1:PointCut and b2:CallGraph, that are woven together. b1 reveals only partial information about b2 which makes b1 more robust and reusable. Advice on b2 at b1. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

22 AP-AspectJ Many AspectJ programs are adaptive (designed for a family of Java programs) –Context: Java program or its execution tree (lexical joinpoints or dynamic join points) Features enabling adaptiveness: –*,.. (wildcards) –cflow, + (graph transitivity) –this(s), target(s), args(a), call (…), … (inheritance as wild card) pc(Object s, Object t): this(s) && target(t) && call(… f …)

23 AP-COOL Program with multiple building blocks including b1:Coordinator and b2:CallGraph, that are woven together. b1 reveals only partial information about b2 which makes b1 more robust and reusable. Advice on b2 at b1. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter Crista Lopes, PhD 1997 Assistant Professor at UC Irvine, first PhD thesis on AOP.

24 AP-Demeter Program with multiple building blocks including b1:Strategy and b2:ClassGraph, that are woven together. b1 reveals only partial information about b2 which makes b1 more robust and reusable. Advice on traversal defined by b1 and b2. AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

25 AP-DJ Program in terms of ClassGraph-, Strategy- and Visitor-objects. Example: –in Java: cg.traverse(o, s, v); AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter The easiest tool to learn good structure-shy programming

26 AP-DAJ Program in terms of Strategy-objects that introduce traversal methods into ClassGraph- objects (adaptiveness to class graph). Enhance the execution of the traversal methods with Visitor-objects that may modify the run-time traversal (adaptiveness to the traversal execution). Example: In AspectJ: declare traversal f(): s V; o.f(); AP-Concern-shy –AP-Structure-shy AP-WildCard AP-Strategy –AP-Call –AP-Demeter

27 Isolated join points crosscutting Connected join points base Adaptive to family of bases

28 Demeter crosscutting I Connected join points Class graph or Object graph From Company to Salary From BusRoute via BusStop to Person Adaptive to family of class graphs

29 Isolated join points Demeter crosscutting II Connected join points Static call graph or Dynamic call graph …_salary(Employee, Object) From Company to Salary Adaptive to family of traversal call graphs

30 Isolated join points AspectJ crosscutting I Class graph or Object graph Company.cache(){}Vector BusRoute.busses;

31 Isolated join points AspectJ crosscutting II Connected join points Static call graph or Dynamic call graph target(Employee) cflow Adaptive to family of call graphs

32 Demeter crosscutting Connected join points Graph From BusRoute via Bus to Person Isolated join points …_salary(Employee, Object) Adaptive to family of graphs

33 How are AP and AOP coupled? AOP: module-shy programming –Modularize programs that cut across modules (with minimal reliance on information in modules). –Programming is module-shy if the modular structure of the program does not prevent concerns that cut across other concerns to be modularized. AP: concern-shy programming Can we view concern implementations as modules?

34 Many open questions Doug Orleans: Simple model of AOP: Fred Johan Ovlinger: Modules and Aspects Pengcheng Wu: Statically Executable Advice Theo Skotiniotis: Contracts for Aspects

35 The End

36 Crosscutting in Demeter generated Java program structure-shy functionality structure synchronization Demeter program replicated!

37 range of AOP languages means of … join points add memberssignaturesclass members static JPM DemeterJ, DAJ dynamic JPM static JPM 1 static JPM 2 static JPM 3 AspectJ dynamic JPM JPM when traversal reaches object or edge class members points in execution call, get, set… join points visitor method signatures traversal spec. s class graph g class names class graph signatures w/ wildcards & other properties of JPs identifying visitor method bodies s + g (result = traversal implementation) add members class graph with tokens=grammar (result = parsing and printing implementation) advice specifying semantics at

38 Adaptiveness The next 7 viewgraphs show how two traversals (parts of an adaptive program) adapt to two different class graphs.

39 Class graph: Find undefined things System Body Thing * * * definedThings usedThings definedThings= from System bypassing Body to Thing usedThings = from System through Body to Thing * Definition def body Ident S D T B

40 M1: Equation System EquationSystem Equation_List Equation Variable equations * lhs rhs Expression Simple Compound Numerical Expression_List * Add op args Ident

41 M1: Equation System definedThings = from EquationSystem bypassing Expression to Variable EquationSystem Equation_List Equation Variable equations * lhs rhs Expression Simple Compound Numerical Expression_List * Add op args Ident S D T B

42 M1: Equation System usedThings = from EquationSystem through Expression to Variable EquationSystem Equation_List Equation Variable equations * lhs rhs Expression Simple Compound Numerical Expression_List * Add op args Ident S D T B

43 CS1: Grammar Grammar EParse BParse Production Entry0..* entries Body Part NonTerm 0..* parts Concrete Abstract lhs rhs

44 CS1: Grammar Grammar EParse BParse Production Entry0..* entries Body Part NonTerm 0..* parts Concrete Abstract lhs definedThings = from Grammar bypassing Body to NonTerm rhs S D T B

45 CS1:Grammar Grammar EParse BParse Production Entry0..* entries Body Part NonTerm 0..* parts Concrete Abstract lhs usedThings = from Grammar through Body to NonTerm rhs S D T B

46 P1P1 P2P2 P3P3 P1P1 P6P6 P2P2 P5P5 P3P3 P4P4 P1P1 P2P2 Software Structure with ACs 46 P1P1 P2P2 P3P3 P1P1 P6P6 P2P2 P5P5 P3P3 P4P4 P1P1 P2P2 Software Structure with ACs 46 P1P1 P2P2 P3P3 P1P1 P6P6 P2P2 P5P5 P3P3 P4P4 P1P1 P2P2 Software Structure with ACs

47 AP-structure-shy: notion of crosscutting B2 = program and its execution trees or an abstraction thereof: UML class diagram and its object diagrams. A program b1*b2 is aspect-oriented if it is crosscutting. Examples: Adaptive, aspect-oriented programs: Policies (Concurrency, Distribution, Authentication, Logging), Adaptive Method, Law of Demeter Checker in AspectJ

48 Scattering B2 is a graph. Count number of nodes and edges that are enhanced. Scat(b1*b2) = number of nodes and edges in b2 enhanced by b1. The higher the number, the more the crosscutting. A program b1*B2 is crosscutting if there is an infinite sequence R1, R2, … of B2 so that Scat(b1*R1), Scat(b1*R2), … is strictly increasing.

49 XAspects: An Extensible System for Domain­Specific Aspect Languages Macneil Shonle Ankit Shah Karl Lieberherr

50 Goal of AOSD Decompose problem into –Representation languages that support structure-shy representations of objects (Object representation concern for input/output/intermediate objects) Benefit: define objects in a structure-shy way. Need structure- shy language design (not XML). –domain-specific aspect languages that support concern- shy representations of concerns. Aspect languages are IO-languages-shy.

51 Why Domain-Specific Aspect Languages? Concerns whose implementation in the chosen PL is either scattered or the concern implementation duplicates information of other concerns. Example: Use case U1 concern implemented by adaptive method: –Is scattered (follow Law of Demeter): traversal methods are spread over many modules –Duplicates (Law of Demeter is violated): traversal is modularized in one method BUT duplication of class graph

52 DSL Domain Specific Languages (DSL) are programming languages which sacrifice generality for closeness to a particular problem area. By reducing the conceptual distance between the problem space and the language used to express the problem, programming becomes simpler, easier, and more reliable. The amount of code which must be written is reduced -- increasing productivity and decreasing maintenance costs.

53 Shyness can be defined in many different ways: An implementation of a concern C_1 is C_2-shy if: The C_1 implementation relies only on minimal information of C_2 implementations. The C_1 implementation can adapt to small changes in C_2 implementations. The C_1 implementation is loosely coupled with C_2 implementations. The C_1 implementation can work with a family C'_2, C''_2, C'''_2, … of C_2 implementations that are “similar”.

54 Shy: a useful term AP = concern-shy programming –D*J: class-graph-shy programming AOP = module-shy programming –AspectJ is call-graph-shy programming –AspectJ is class-graph-shy programming –AspectJ-DAJ is better class-graph-shy programming Obliviousness: program is aspect-shy D*J = DemeterJ/DJ/DAJ

55 Related Work D AspectJ DemeterJ DAJ

56 Related Work: SDP NSF Workshop Jim Hugunin: The Next Steps For Aspect-Oriented Programming Languages (in Java) Don Batory: ExCIS: An Integration of Domain-Specific Languages and Feature-Oriented Programming

57 Related Work: Jim Hugunin While aspect libraries can provide some domain specific support in a general purpose AOP language such as AspectJ, it is likely that some domains will be important enough to warrant the creation of domain-specific AOP languages. Some engineering approaches to encourage that sort of work are discussed in the next section.

58 Jim Hugunin The next obvious step for this extensibility is to provide clearly documented and stable public APIs for adding things like custom pointcut designators or new static program transformations through extensions of the declare language space. This would make it easy for other Java- based AOP languages such as DemeterJ [10] to be implemented as a compatible extension to AspectJ. Further into the future, work is needed to determine the right way to enable programmers to extend these languages without operating on the compiler.

59 Work to be done (Batory) Debuggers. Domain-specific languages are not new languages, but rather extensions of current, standard languages. So, standard development environments and debuggers can be used with DSLs. However, if the programmer works in the context of the base language (C++, Java, etc.) rather than the extended language, much of the simplicity obtained by using the DSL is lost. Therefore, DSL specific debuggers are required.

60 Work to be done (Batory) Visual Programming Tool-kit. The ExCIS tool-kit supports the construction of domain-specific languages. This simplifies the problem of producing a DSL, but does not assist in providing an interface between the user and the DSL. An equivalent tool-kit for the construction of visual programming environments linked to a domain- specific language is needed. Such a tool-kit would allow the DSL designer to easily specify a visual programming interfacethat would generate the required DSL code. Some degree of round-trip engineering would be supported.

61 Work to be done (Batory) Visual Programming Tool-kit. The ExCIS tool- kit supports the construction of domain-specific languages. This simplifies the problem of producing a DSL, but does not assist in providing an interface between the user and the DSL. An equivalent tool-kit for the construction of visual programming environments linked to a domain- specific language is needed. Such a tool-kit would allow the DSL designer to easily specify a visual programming interface that would generate the required DSL code.

62 Work to be done (Batory) Program Composition Validation. The mechanisms used for the construction of programs using feature-based components lend themselves to automated validation for correct composition. Preliminary work shows that relatively simple mechanisms can be employed to validate a proposed composition of features [2]. More sophisticated algorithms from model checking may extend our capability to compose correct systems [9].

63 Work to be done (Batory) Program Composition Optimization. Any given program feature can usually be implemented in a variety of ways. The best implementation for an application will depend upon non-functional requirements such as performance constraints or resource usage. A feature component library contains not only components, but also a characterization of the component. By specifying both functional and non- functional requirements, the system assembler can optimize the selection of components to satisfy both types of requirements [3].

64 Need for Domain-Specific AL We conjecture that this gap between domain- specific aspect languages and general purpose aspect languages will always exist because any general solution cannot cover all possible ways an aspect can crosscut a system. By their nature concerns are related to the problem domain, and there is an innite variety of forms that problem domains can take.

65 Aspect Libraries AspectJ has some support for particular domains via abstract aspect libraries: The pointcut sets described by an abstract aspect can be defined later by a concrete aspect. Only a limited set of problems has thus far created useful aspect libraries.

66 Problem with multiple DSLs A tool for each concern that translates to AspectJ. The fragmentation of tools causes problems when each concern relies on the solutions provided by the other tools. While a parser can be orthogonal to the rest of the program, a traversal through the program cannot be orthogonal.

67 Plug-in Architecture The fragmentation problem can be solved by forcing each domain-specific solution to conform to particular framework and by defining a common language with which the domain-specific tools can communicate. The XAspects tool provides a plug-in framework that integrates domain-specific languages such that the tools become extensions of the AspectJ language. Rules on what a plug-in can do are introduced in order to enhance the integration.

68 Example 01 aspect(ClassDictionary) CompactDisc { 02 CD = "cd" String "by" Artist "," 03 "(" UPCNumber ")" "."; 04 Artist : SingleArtist | MultipleArtist; 05 SingleArist = Name; 06 MultipleArist = Name "," CommaList(Name); 07 Name = String; 08 UPCNumber = String; 09 CommaList(S) ~ S { "," S }; 10 }

Compilation Phases The XAspects compiler and each plug-in tool communicate with each other four times: 1. The XAspects compiler identies in the source code all program text that belongs to the plug-in and providesthat text to the plug-in. 2. The plug-in generates source les that dene the external (i.e. program visible) components introduced by the language that the plug-in implements. 3. The XAspects compiler provides the plug-in the complete binary of the program. 4. The plug-in generates behavioral changes to the generated program in the form of AspectJ source code.

Source Code Identication The input files to the XAspects compiler are Java and AspectJ source files that are allowed to include one minor syntactic extension: When the aspect keyword is followed by parentheses the parentheses must contain a valid type name for a class that can be found on the current class path.

Generation of External Interfaces The XAspects compiler then queries each plug-in to provide a set of source files that describe the program visible interfaces generated by the plug-ins. For example, the ClassDictionary plug- in at this point will provide the list of classes, methods and fields that were described by the grammar.

72 External Interfaces The external interfaces are described through AspectJ source code. Therefore the external interfaces can express new classes or modications to existing classes via inter-type declarations.

73 External Interfaces The AspectJ source code generated needs to meet the following restrictions: All new classes generated must be generated for the same package in which the aspect body was defined. All new classes generated must have a name that appeared as an identifier token in the aspect body. This restriction allows the user of the plug-in to have full control over the names generated.

74 External Interfaces All new public fields or new public methods introduced to existing classes (via inter-type declarations) must have a name that appeared as an identifier token in the aspect body. The fields or methods introduced to new classes do not have to be named by identifiers present in the aspect body because any further changes to that class will be done by external inter-type declarations or plug-ins. Any name clashes that arise can be handled in those changes.

Crosscutting Analysis After the external interfaces are generated by the plug-ins, the rest of the AspectJ and Java source is compiled with those interfaces. At this point the structure of the program is complete and plug-ins cannot add new fields to any of the classes. Because the structure of the program is fixed the complete bytecodes for the program can be provided to each plug-in. Because each plug-in is ultimately generating Java bytecodes, the changes made by all plug-ins are in the same language.

76 Crosscutting Analysis During this phase, domain-specific aspect languages can perform structural analysis on the program. For example, the Traversal plug-in can generate concrete paths based on the traversal rules specified.

Generation of Semantics Finally, each plug-in can provide semantic changes by using AspectJ's dynamic join-point model. The implementation of stub functions can be specified by using AspectJ's around advice. New private methods can also be introduced at this point by using inter-type declarations. Note that a private inter-type declaration does introduce a private method to the class, rather it introduces a method to the class that is only visible by the generating aspect. For example, the Traversal plug-in can generate private methods to each of the classes it needs to traverse: these private methods cannot be called by other parts of the program.

78 Advantages of XAspects The XAspects system is unique because it separates conceptually two different provisions of a domain-specific language: the langauge's external interface and its semantics. The separation of these two concepts allows for the plug-ins to passively cooperate with each other.

79 Advantages of XAspects The XAspects infrastructure essentially reduces the problem for a domain-specific language to the problem of reading in Java code and producing changes and additions to that code. Dependency issues among domain- specific languages are reduced: each plug-in only has to worry about the properties of Java classes, and not the properties of constructs of other domain-specific languages that created those classes.

80 Advantages of XAspects It could be argued that it is not feasible to introduce many little domain-specific languages that the programmers have to work with. However, the inherent complexity of a project may require that the programmers address the issues of composition of aspect languages on a conceptual level. A conscious language design that addresses the aspect composition issues systematically can simplify the programmer's job: Without such an approach, the programmers will have to do this at the lower level of a general purpose aspect language, which results in more code that actually needs to be written, some of which will be redundant with the structure of the program and could have been automatically generated.

81 Future work Add Multi-Java as a plug-in. HyperJ like features. Composition filters. Sandbox for experimenting with multiple AOP approaches.

82 End

83 Mitch Suggestion Spectrum –Oblivious Nothing at all –Information-Hiding Well defined interface –Shyness Goes inside; information restriction Program, structure, class graph, call graph, concern, aspect

84 Goal of AOSD Decompose into domain-specific languages DL1, … and aspect-specific languages AS1, … –Dli have minimal overlap –As1 is shy of Dli and other Asi (elements of AS1 are shy of elements of DL1 and elements of