1. 3/7/2003 ABB rapid change 1 How To Address Rapidly Changing Data Representations in an Evolving Scientific Domain Using Aspect-oriented Programming Techniques. Karl Lieberherr (lieber@ccs.neu.edu) College of Computer and Information Science Northeastern University Boston

2. 3/7/2003ABB rapid change2 Motivation  From: Computational Challenges in Structural and Functional Genomics by J. Head-Gordon,  From: Computational Challenges in Structural and Functional Genomics by J. Head-Gordon, IBM SYSTEMS JOURNAL, VOL 40, NO 2, 2001.

3. 3/7/2003ABB rapid change3 Some Quotes From Head- Gordon.   Although techniques for warehousing are as vital in the sciences as in business, functional warehouses tailored for specific scientific needs are few and far between.   A key technical reason for this discrepancy is that our understanding of the concepts being explored in an evolving scientific domain change constantly, leading to rapid changes in data representation.

4. 3/7/2003ABB rapid change4 Some Quotes From Head- Gordon (Refinement).   … evolving scientific domains change constantly, leading to rapid changes in data representation.   Not only changes in data representation but also changes in interfaces – need protection against changes in interfaces.   Examples: additional or modified fields or arguments; additional or modified types.

5. 3/7/2003ABB rapid change5 More Quotes From Head- Gordon.   When the format of source data changes, the warehouse must be updated to read that source or it will not function properly. The bulk of these modifications involve extremely tedious, low-level translation and integration tasks that typically require the full attention of both database and domain experts. Given the lack of the ability to automate this work, warehouse maintenance costs are prohibitive, and warehouse “up-times” severely restricted.

6. 3/7/2003ABB rapid change6 Protect Against Changes.  Protection against changes in data representation and interfaces. Traditional technique: information-hiding is good to protect against changes in data representation. Does not help with changes to interfaces.  Need more than information hiding to protect against interface changes: restriction through shy programming, called Adaptive Programming (AP). ImplementationInterfaceClient Information HidingShy Programming

7. 3/7/2003ABB rapid change7 Problem with Information Hiding  Shy Programming builds on the observation that traditional black-box composition is not restricting enough. We use the slogan: information hiding is not hiding enough. Blackbox composition isolates the implementation from the interface, but does not decouple the interface from its clients.

8. 3/7/2003ABB rapid change8 Cover unimportant parts of the interface  To permit interfaces to evolve, self-discipline is required to prevent from programming extensively against the interface. Certain parts of the interface are best left as if they were covered. ImplementationInterfaceClient Information HidingShy Programming

9. 3/7/2003ABB rapid change9 Shy Programming = Adaptive Programming  This disciplined programming is referred to as shy programming. Shy programming lets the program recover from (or adapt to) interface changes. Shy programming is also called Adaptive Programming (AP). This is similar to the shyness metaphor in the Law of Demeter (LoD): structure evolves over time, thus an object communicates with only a subset of the visible objects.

10. 3/7/2003ABB rapid change10 Decoupling of Interface  We summarize the commonalities and differences between black-box composition and Shy Programming into two principles. –Black-box Principle: the representation of objects can be changed without affecting clients. –Shy-Programming Principle: the interface of objects can be changed within certain parameters without affecting clients.  It is important to notice that the Shy-Programming Principle builds on top of the Black-Box principle.

11. 3/7/2003ABB rapid change11 Manager Metaphor.  A manager M is managing a set of group leaders G, each one managing a set of workers W. We consider issues related to informing M and requesting information from M. We use this example to illustrate three points. –Micromanager – no information restriction. –Shyness – helps information restriction. –Complex requests – help information restriction and optimization. Want to learn about coping with rapidly changing interfaces. M G W

12. 3/7/2003ABB rapid change12 Manager Metaphor.  Micromanager – no information restriction. –If the manager is a micromanager (a manager that wants to know about and rely on all the details of the worker’s projects), the managing approach is brittle because when there is a change in the details of one of the worker’s projects, the manager needs to be notified. M G W

13. 3/7/2003ABB rapid change13 Manager Metaphor.  Micromanager – no information restriction (continued). –An object-oriented program written in the usual way corresponds to the manager that likes to micromanage. It is full of detailed knowledge of the class graph. An alternative way of formulating the same idea is to observe that it is good when the workers are shy. A shy worker will only share minimal, high-level information with the group leader. And this will prevent a brittle situation where the group leaders and manager rely on too much detail. M G W

14. 3/7/2003ABB rapid change14 Manager Metaphor.  Shyness – helps information restriction –It is good for the workers to be shy and only talk to their group leader and not to the manager directly. (Shyness has two facets: talk only to a few friends AND share minimal information with them. Here we use the first facet while in the previous point we used the second facet.) The group leader will abstract the information from the workers and only pass on the abstract information to the manager. This will prevent the manager from micromanaging. This variant can be viewed as an application of the Law of Demeter (LoD) which states that an object should talk only to closely related objects. The closely related object for a worker is the group leader and not the manager. MG W

15. 3/7/2003ABB rapid change15 Manager Metaphor.  Shyness – helps information restriction (continued). –The motivation is that when things change at the worker level, the manager does not have to be informed necessarily. The group leader will be informed and will decide whether the information needs to be passed up. M G W shielded

16. 3/7/2003ABB rapid change16 Manager Metaphor.  Complex requests – help information restriction and optimization. –The manager does not want to be bothered by many simple requests from the many workers. Instead the manager prefers to get a complex request from time to time from a group manager. The complex request offers the manager the possibility to see all the requests as a whole and to optimize the overall result which would not be possible if simple requests come one by one and need to be satisfied immediately before the totality of all simple requests is seen.

17. 3/7/2003ABB rapid change17 Manager Metaphor.  Complex requests – help information restriction and optimization (continued). –The same point applies to programming: instead of sending an object a lot of individual data access requests, it is better to send one complex request that can be treated as a whole and optimized accordingly.

18. 3/7/2003ABB rapid change18 Aspect-oriented Programming (AOP).  AOP is programming with aspects. An aspect is a complex request to modify the execution of a program. May expose a large interface. This can be implemented efficiently by inserting code at compile time into the program. An aspect should be shy with respect to the program it modifies.

19. 3/7/2003ABB rapid change19 AOSD: not every concern fits into a component: crosscutting Goal: find new component structures that encapsulate “rich” concerns

20. 3/7/2003ABB rapid change20 A Reusable Aspect. abstract public aspect RemoteExceptionLogging { abstract pointcut logPoint(); after() throwing (RemoteException e): logPoint() { log.println(“Remote call failed in: ” + thisJoinPoint.toString() + “(” + e + “).”); } public aspect MyRMILogging extends RemoteExceptionLogging { pointcut logPoint(): call(* RegistryServer.*.*(..)) || call(private * RMIMessageBrokerImpl.*.*(..)); } abstract

21. 3/7/2003ABB rapid change21 Good Aspects Are Shy. abstract aspect CapabilityChecking { pointcut invocations(Caller c): this(c) && call(void Service.doService(String)); pointcut workPoints(Worker w): target(w) && call(void Worker.doTask(Task)); pointcut perCallerWork(Caller c, Worker w): cflow(invocations(c)) && workPoints(w); before (Caller c, Worker w): perCallerWork(c, w) { w.checkCapabilities(c); }

22. 3/7/2003ABB rapid change22 Lessons From Manager Metaphor.  Information hiding does not hide enough. Information hiding makes all public interfaces available and (Micromanager) makes the point that only an abstraction of those interfaces should be visible at higher levels.

23. 3/7/2003ABB rapid change23 Lessons From Manager Metaphor (Continued).  In Shy Programming, only high-level information about the class or call graph is visible at the (shy) programming level and this shields the program from many changes to the class or call graph in the same way as the manager is shielded from many of the changes in the workers’ projects. The role of the group leader is played by the glue code that maps high-level information to low-level information and vice-versa. Shy Programming is graph-shy.

24. 3/7/2003ABB rapid change24 Application to Scientific Warehouses  Need shy programming and shy knowledge representation techniques.  Need domain-specific aspect languages that are X-shy.

25. 3/7/2003ABB rapid change25 Another Good Example of AOP. BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..* find all persons waiting at any bus stop on a bus route OO solution: one method for each red class

26. 3/7/2003ABB rapid change26 Traversal Strategy. BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..* from BusRoute through BusStop to Person find all persons waiting at any bus stop on a bus route A complex request

27. 3/7/2003ABB rapid change27 Robustness of Strategy. BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..* from BusRoute through BusStop to Person VillageList Village villages 0..* find all persons waiting at any bus stop on a bus route Complex request is class-graph shy

28. 3/7/2003ABB rapid change28 Writing Aspect-oriented Programs With Strategies. class BusRoute { int countWaitingPersons() { Integer result = (Integer) Main.cg.traverse(this, WPStrategy, new Visitor(){ int r ; public void before(Person host){ r++; } public void start() { r = 0;} public Object getReturnValue() { return new Integer(r);} }); return result.intValue();} } String WPStrategy=“ from BusRoute through BusStop to Person” A complex request Complex request plays role of manager Complex request is class-graph shy

29. 3/7/2003ABB rapid change29 Writing Aspect-Oriented Programs With Strategies. // Prepare current class graph Main.cg = new ClassGraph(); int r = aBusRoute.countWaitingPersons(); String WPStrategy=“ from BusRoute through BusStop to Person”

30. 3/7/2003ABB rapid change30 ObjectGraph: in UML Notation. Route1:BusRoute :BusStopList busStops CentralSquare:BusStop :PersonList waiting Paul:PersonSeema:Person :BusList buses Bus15:Bus :PersonList passengers Joan:Person Eric:Person

31. 3/7/2003ABB rapid change31 ObjectGraphSlice. Route1:BusRoute :BusStopList busStops CentralSquare:BusStop :PersonList waiting Paul:PersonSeema:Person BusList buses Bus15:Bus :PersonList passengers Joan:Person Eric:Person

32. 3/7/2003ABB rapid change32 Summary So Far.  Aspect-oriented software development helps to create software that is –More flexible; supports easy adaptation to rapidly changing interfaces. –Easier to understand and also shorter. –Supports the Shy Programming Principle.

33. 3/7/2003ABB rapid change33 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 representation-languages-shy.

34. 3/7/2003ABB rapid change34 XAspects: Tool Support for Shy- programming and Complex Requests.  Two kinds of languages –Class dictionary languages: allow shy representations of objects. Used for representing objects: one class dictionary per domain.  At the base level. –Aspect-specific languages: For representing abstractions of programming concerns shy of other concerns. Implemented using class dictionaries.  At the meta level.

35. 3/7/2003ABB rapid change35 XAspects and Manager Example.  Sentence of language corresponds to a complex request.  Languages should be shy of each other.  A language should not be a micro-manager of other languages.

36. 3/7/2003ABB rapid change36 Why Not a General-purpose Aspect Language?  A la AspectJ: we use it in XAspect as one possible language (plug in) and also AspectJ plays the role of central language into which all aspect languages are translated.  But only using AspectJ is limiting: –Aspects interact in complex ways. Need special languages for better separation. –Example: Visitor pattern as a concern can not be well separated in AspectJ (unless we resort to heavy use of reflection: performance problem). Structure-shyness.

37. 3/7/2003ABB rapid change37 Why Do We Need XAspects.  Separation of external interface and semantics  Structure-shyness –Can build DSL objects using constructors and use AspectJ to implement meaning of DSL objects. Is inconvenient (sentence is shorter than abstract syntax tree = object) and  Lack of static checking in AspectJ –Hinders static checking of DSL objects Improved AspectJ => makes implementation of plugins easier

38. 3/7/2003ABB rapid change38 C Is X-shy.  A concern C is X-shy if C can adapt to small changes in X or if C relies only on minimal information of X (topological).  Domain-specific aspect languages allow problems to be decomposed to support concern-shy representations of concerns.

39. 3/7/2003ABB rapid change39 Problems With Multiple Domain- specific Aspect Languages.   The fragmentation of tools causes problems when each concern relies on the solutions provided by the other tools.   Next we present how XAspects addresses this problem.

40. 3/7/2003ABB rapid change40 Idea n*n n AspectJ

41. 3/7/2003ABB rapid change41 A Plug-in Architecture.   The fragmentation problem can be solved by forcing each domain-specific solution to conform to a 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 restricting what a plug-in can do are introduced in order to enhance the integration.

42. 3/7/2003ABB rapid change42 A JC :X AJC :P LUG - INS : 1.Source Code Identification 2. Generation of External Interfaces 3. Initial Bytecode Generation 4. Crosscutting Analysis 5. Generation of Semantics 6. Final Bytecode Generation Plugin Sequence Diagram.

43. 3/7/2003ABB rapid change43 1. Source Code Identification.   The XAspects compiler identifies in the source code all program text that belongs to the plug-in and provides that text to the plug-in.

44. 3/7/2003ABB rapid change44 2. Generation of External Interfaces.   The plug-in generates source files that define the external (i.e., program visible) components introduced by the language that the plug-in implements.

45. 3/7/2003ABB rapid change45 3. Initial Bytecode Generation.   The AspectJ compiler generates bytecodes from the plug-in defined external interfaces and the remainder of the program.

46. 3/7/2003ABB rapid change46 4. Crosscutting Analysis.   The XAspects compiler provides each plug- in the binary of the program to perform reflection or other analysis on it.

47. 3/7/2003ABB rapid change47 5. Generation of Semantics.   The plug-in generates behavioral changes to the generated program in the form of AspectJ source code. (Structural changes are prohibited during this phase, only methods can be modified, and only aspect private methods can be introduced.)

48. 3/7/2003ABB rapid change48 6. Final Bytecode Generation.   Finally, the new behavioral code is woven into the existing code to create the complete program.

49. 3/7/2003ABB rapid change49 A JC :X AJC :P LUG - INS : Source Code Identification Generation of External Interfaces Initial Bytecode Generation Crosscutting Analysis Generation of Semantics Final Bytecode Generation

50. 3/7/2003ABB rapid change50 Plug-ins Currently Available.  Class dictionary plug-in  Coordination plug-in  Traversal plug-in  AspectJ plug-in (includes Java)  Dependencies –Traversal plug-in depends on Class dictionary plug-in and AspectJ plug-in.

51. 3/7/2003ABB rapid change51 Advantages of XAspects.   The XAspects system is unique because it separates conceptually two different provisions of a domain-specific language: – –the language's external interface and structural modifications and – –the language's semantics.   The separation of these two concepts allows for the plug-ins to passively cooperate with each other.

52. 3/7/2003ABB rapid change52 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 because 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.

53. 3/7/2003ABB rapid change53 Too Many Languages?   It could be argued that it is not feasible to introduce many little domain-specific languages with which the programmers have to work.   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 programmers' job.

54. 3/7/2003ABB rapid change54 Too Many Languages?   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 written, some of which will be redundant with the structure of the program and could have been generated automatically.

55. 3/7/2003ABB rapid change55 Another Weakness of General Aspect-oriented Programming …  is the difficultly of using the language correctly. A novice can easily create an infinite loop in AspectJ if an advice happens to apply to itself. More subtle misapplications of advice can also occur. If a custom aspect language is created for a specific domain these misapplications can be checked by the plug-in. While a reusable AspectJ aspect might be able to implement some of the functionalities of an XAspects plug-in, it cannot perform some of the compile time checks needed to ensure that the aspect is being used correctly.

56. 3/7/2003ABB rapid change56 Conclusions.  Aspect-Oriented Software Development (AOSD) is a useful technology for the rapidly evolving area of scientific warehouses.  XAspects is a tool that supports AOSD in a more powerful way than a general purpose aspect-oriented language.

57. 3/7/2003ABB rapid change57 The End

58. 3/7/2003ABB rapid change58 Lessons From Manager Metaphor (Continued).  AOP is related to (Micromanager) through the observation that aspects should be loosely coupled to the base programs they modify. The aspect should not be brittle with respect to the detailed calling structure of the base program in the same way as the manager should not rely on the details of the workers’ project. There is an intermediary, called glue code, that maps the aspect to the detailed usage context. AOP is call- graph shy.