3/7/2003 abb rapid change 1 how to address rapidly changing data representations in an evolving...

3/7/20033/7/2003 ABB rapid changeABB rapid change 11

How To Address Rapidly Changing Data How To Address Rapidly Changing Data Representations in an Evolving Scientific Representations in an Evolving Scientific

Domain Using Aspect-oriented Domain Using Aspect-oriented Programming Techniques.Programming Techniques.

Karl Lieberherr ([email protected])Karl Lieberherr ([email protected])

College of Computer and Information College of Computer and Information ScienceScience

Northeastern UniversityNortheastern University

BostonBoston


MotivationMotivation

From: Computational Challenges in From: Computational Challenges in Structural and Functional Genomics by J. Structural and Functional Genomics by J. Head-Gordon, Head-Gordon, IBM SYSTEMS JOURNAL, VOL 40, NO 2, 2001.


Some Quotes From Head-Some Quotes From Head-Gordon.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.


Some Quotes From Head-Some Quotes From Head-Gordon (Refinement).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.


More Quotes From Head-More Quotes From Head-Gordon.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.


Protect Against Changes.Protect Against Changes.

Protection against changes in data representation and interfaces. Protection against changes in data representation and interfaces. Traditional technique: information-hiding is good to protect Traditional technique: information-hiding is good to protect against changes in data representation. Does not help with against changes in data representation. Does not help with changes to interfaces.changes to interfaces.

Need more than information hiding to protect against interface Need more than information hiding to protect against interface changes: restriction through shy programming, called Adaptive changes: restriction through shy programming, called Adaptive Programming (AP).Programming (AP).

Implementation Interface Client

Information Hiding Shy Programming


Problem with Information HidingProblem with Information Hiding

Shy Programming builds on the observation that Shy Programming builds on the observation that traditional black-box composition is not traditional black-box composition is not restricting enough. We use the slogan: restricting enough. We use the slogan: information hiding is not hiding enough. information hiding is not hiding enough. Blackbox composition Blackbox composition isolates the isolates the implementation from the interfaceimplementation from the interface, but , but does not does not decouple the interface from its clients.decouple the interface from its clients.


Cover unimportant parts of the Cover unimportant parts of the interfaceinterface

To permit interfaces to evolve, self-discipline is To permit interfaces to evolve, self-discipline is required to prevent from programming required to prevent from programming extensively against the interface. Certain parts of extensively against the interface. Certain parts of the interface are best left as if they were the interface are best left as if they were covered. covered.

Implementation Interface Client

Information Hiding Shy Programming


Shy Programming = Shy Programming = Adaptive ProgrammingAdaptive Programming

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


Decoupling of InterfaceDecoupling of Interface

We summarize the commonalities and differences We summarize the commonalities and differences between black-box composition and Shy Programming between black-box composition and Shy Programming into two principles.into two principles.– Black-box PrincipleBlack-box Principle: the representation of objects can be : the representation of objects can be

changed without affecting clients.changed without affecting clients.

– Shy-Programming PrincipleShy-Programming Principle: the interface of objects can be : the interface of objects can be changed within certain parameters without affecting clients.changed within certain parameters without affecting clients.

It is important to notice that the Shy-Programming It is important to notice that the Shy-Programming Principle builds on top of the Black-Box principle.Principle builds on top of the Black-Box principle.


Manager Metaphor.Manager Metaphor.

A manager M is managing a set of group leaders A manager M is managing a set of group leaders G, each one managing a set of workers W. We G, each one managing a set of workers W. We consider issues related to informing M and consider issues related to informing M and requesting information from M. We use this requesting information from M. We use this example to illustrate three points.example to illustrate three points.– MicromanagerMicromanager – no information restriction. – no information restriction.– ShynessShyness – helps information restriction. – helps information restriction.– Complex requestsComplex requests – help information restriction and – help information restriction and

optimization.optimization.

Want to learn about coping with rapidly changing interfaces.M

G

W



MicromanagerMicromanager – no information restriction. – no information restriction.– If the manager is a micromanager (a manager that If the manager is a micromanager (a manager that

wants to know about and rely on all the details of the wants to know about and rely on all the details of the worker’s projects), the managing approach is worker’s projects), the managing approach is brittlebrittle because when there is a change in the details of one because when there is a change in the details of one of the worker’s projects, the manager needs to be of the worker’s projects, the manager needs to be notified.notified. M

G

W



MicromanagerMicromanager – no information restriction (continued). – no information restriction (continued).– An object-oriented program written in the usual way An object-oriented program written in the usual way

corresponds to the manager that likes to micromanage. It is corresponds to the manager that likes to micromanage. It is full of detailed knowledge of the class graph. An alternative full of detailed knowledge of the class graph. An alternative way of formulating the same idea is to observe that it is good way of formulating the same idea is to observe that it is good when the workers are shy. A shy worker will when the workers are shy. A shy worker will only share only share minimal, high-level information with the group leaderminimal, high-level information with the group leader. And . And this will prevent a brittle situation where the group leaders this will prevent a brittle situation where the group leaders and manager rely on too much detail.and manager rely on too much detail.

M

G

W



ShynessShyness – helps information restriction – helps information restriction – It is good for the workers to be It is good for the workers to be shyshy and only talk to their and only talk to their

group leader and not to the manager directly. (group leader and not to the manager directly. (ShynessShyness has has twotwo facets: talk only to a facets: talk only to a fewfew friendsfriends AND share AND share minimalminimal information with them. Here we use the first facet while in the information with them. Here we use the first facet while in the previous point we used the second facet.) The group leader previous point we used the second facet.) The group leader will abstract the information from the workers and only pass will abstract the information from the workers and only pass on the abstract information to the manager. This will prevent on the abstract information to the manager. This will prevent the manager from micromanaging. This variant can be viewed the manager from micromanaging. This variant can be viewed as an application of the as an application of the Law of DemeterLaw of Demeter (LoD) which states (LoD) which states that an object should talk only to closely related objects. The that an object should talk only to closely related objects. The closely related object for a worker is the group leader and not closely related object for a worker is the group leader and not the manager.the manager.

M

G

W



ShynessShyness – helps information restriction – helps information restriction (continued).(continued).– The motivation is that when things change at the The motivation is that when things change at the

worker level, the manager worker level, the manager does not have to be does not have to be informed necessarilyinformed necessarily. The group leader will be . The group leader will be informed and will decide whether the information informed and will decide whether the information needs to be passed up.needs to be passed up.

M

G

W

shielded



Complex requestsComplex requests – help information restriction and – help information restriction and optimization.optimization.– The manager does not want to be bothered by many simple The manager does not want to be bothered by many simple

requests from the many workers. Instead the manager prefers requests from the many workers. Instead the manager prefers to get a complex request from time to time from a group to get a complex request from time to time from a group manager. The complex request offers the manager the manager. The complex request offers the manager the possibility to possibility to see all the requests as a wholesee all the requests as a whole and to optimize and to optimize the overall result which would not be possible if simple the overall result which would not be possible if simple requests come one by one and need to be satisfied requests come one by one and need to be satisfied immediately before the totality of all simple requests is seen. immediately before the totality of all simple requests is seen.



Complex requestsComplex requests – help information restriction – help information restriction and optimization (continued).and optimization (continued).– The same point applies to programming: instead of The same point applies to programming: instead of

sending an object a lot of individual data access sending an object a lot of individual data access requests, it is better to send one complex request that requests, it is better to send one complex request that can be treated as a whole and optimized accordingly.can be treated as a whole and optimized accordingly.


Aspect-oriented Programming Aspect-oriented Programming (AOP).(AOP).

AOP is programming with aspects. An aspect is AOP is programming with aspects. An aspect is a complex request to modify the execution of a a complex request to modify the execution of a program. May expose a large interface. This can program. May expose a large interface. This can be implemented efficiently by inserting code at be implemented efficiently by inserting code at compile time into the program. An aspect should compile time into the program. An aspect should be shy with respect to the program it modifies. be shy with respect to the program it modifies.


AOSD: not every concern fits into AOSD: not every concern fits into a component: a component: crosscuttingcrosscutting

CM1 CM2 CM3 CM4 CM5 CM6

CR1 x

CR2 x

CR3 x

CR4 x x x x

Goal: find new component structures that encapsulate “rich” concerns


A Reusable Aspect.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


Good Aspects Are Shy.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); }}


Lessons From Manager Lessons From Manager Metaphor.Metaphor.

Information hiding does not hide enough.Information hiding does not hide enough. Information hiding makes all public interfaces Information hiding makes all public interfaces available and (Micromanager) makes the point available and (Micromanager) makes the point that only an abstraction of those interfaces that only an abstraction of those interfaces should be visible at higher levels. should be visible at higher levels.


Lessons From Manager Lessons From Manager Metaphor (Continued).Metaphor (Continued).

In Shy Programming, only high-level information about In Shy Programming, only high-level information about the class or call graph is visible at the (shy) the class or call graph is visible at the (shy) programming level and this shields the program from programming level and this shields the program from many changes to the class or call graph in the same way many changes to the class or call graph in the same way as the manager is shielded from many of the changes in as the manager is shielded from many of the changes in the workers’ projects. The role of the group leader is the workers’ projects. The role of the group leader is played by the glue code that maps high-level played by the glue code that maps high-level information to low-level information and vice-versa. information to low-level information and vice-versa. Shy Programming is graph-shy.Shy Programming is graph-shy.


Application to Scientific Application to Scientific WarehousesWarehouses

Need shy programming and shy knowledge Need shy programming and shy knowledge representation techniques.representation techniques.

Need domain-specific aspect languages that Need domain-specific aspect languages that are X-shy.are X-shy.


Another Good Example of AOP.Another Good Example of AOP.

BusRoute BusStopList

BusStopBusList

Bus PersonList

Person

passengers

buses

busStops

waiting

0..*

0..*

0..*

find all persons waiting at any bus stop on a bus route

OO solution:one methodfor each redclass


Traversal Traversal Strategy.Strategy.


BusStopBusList

Bus PersonList

Person

passengers

buses

busStops

waiting

0..*

0..*

0..*

from BusRoute through BusStop to Person


A complex request


Robustness of Robustness of Strategy.Strategy.


BusStopBusList

Bus PersonList

Person

passengers

busesbusStops

waiting

0..*

0..*

0..*

from BusRoute through BusStop to Person

VillageList

Village

villages

0..*


Complex request is class-graph shy


Writing Aspect-oriented Writing Aspect-oriented Programs With Programs With Strategies.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 requestplays role ofmanagerComplex request is class-graph shy


Writing Aspect-Oriented Writing Aspect-Oriented Programs With Programs With Strategies.Strategies.

// Prepare current class graphMain.cg = new ClassGraph();

int r = aBusRoute.countWaitingPersons();

String WPStrategy=“from BusRoute through BusStop to Person”


ObjectGraph: in UML Notation.ObjectGraph: in UML Notation.

Route1:BusRoute

:BusStopListbusStops

CentralSquare:BusStop

:PersonList

waiting

Paul:Person Seema:Person

:BusListbuses

Bus15:Bus

:PersonList

passengers

Joan:Person

Eric:Person


ObjectGraphSlice.ObjectGraphSlice.

Route1:BusRoute

:BusStopListbusStops

CentralSquare:BusStop

:PersonList

waiting

Paul:Person Seema:Person

BusListbuses

Bus15:Bus

:PersonList

passengers

Joan:Person

Eric:Person


Summary So Far.Summary So Far.

Aspect-oriented software development helps Aspect-oriented software development helps to create software that is to create software that is – More flexible; supports easy adaptation to More flexible; supports easy adaptation to

rapidly changing interfaces.rapidly changing interfaces.– Easier to understand and also shorter.Easier to understand and also shorter.– Supports the Shy Programming Principle.Supports the Shy Programming Principle.


Goal of AOSD.Goal of AOSD.

Decompose problem into Decompose problem into – Representation languages that support structure-shy Representation languages that support structure-shy

representations of objects (Object representation representations of objects (Object representation concern for input/output/intermediate objects)concern for input/output/intermediate objects) Benefit: define objects in a structure-Benefit: define objects in a structure-shyshy way. Need structure- way. Need structure-

shy language design (not XML). shy language design (not XML).

– domain-specific aspect languages that support concern-domain-specific aspect languages that support concern-shyshy representations of concerns. Aspect languages are representations of concerns. Aspect languages are representation-languages-representation-languages-shyshy..


XAspects: Tool Support for Shy-XAspects: Tool Support for Shy-programming and Complex programming and Complex

Requests.Requests. Two kinds of languagesTwo kinds of languages

– Class dictionary languages: allow shy representations of Class dictionary languages: allow shy representations of objects. Used for representing objects: one class objects. Used for representing objects: one class dictionary per domain. dictionary per domain. At the base level.At the base level.

– Aspect-specific languages: For representing Aspect-specific languages: For representing abstractions of programming concerns shy of other abstractions of programming concerns shy of other concerns. Implemented using class dictionaries.concerns. Implemented using class dictionaries. At the meta level.At the meta level.


XAspects and Manager Example.XAspects and Manager Example.

Sentence of language corresponds to a Sentence of language corresponds to a complex request.complex request.

Languages should be shy of each other.Languages should be shy of each other. A language should not be a micro-manager A language should not be a micro-manager

of other languages.of other languages.


Why Not a General-purpose Why Not a General-purpose Aspect Language?Aspect Language?

A la AspectJ: we use it in XAspect as one possible A la AspectJ: we use it in XAspect as one possible language (plug in) and also AspectJ plays the role language (plug in) and also AspectJ plays the role of central language into which all aspect of central language into which all aspect languages are translated.languages are translated.

But only using AspectJ is limiting:But only using AspectJ is limiting:– Aspects interact in complex ways. Need special Aspects interact in complex ways. Need special

languages for better separation.languages for better separation.– Example: Visitor pattern as a concern can not be well Example: Visitor pattern as a concern can not be well

separated in AspectJ (unless we resort to heavy use of separated in AspectJ (unless we resort to heavy use of reflection: performance problem). Structure-shyness.reflection: performance problem). Structure-shyness.


Why Do We Need XAspects.Why Do We Need XAspects.

Separation of external interface and semanticsSeparation of external interface and semantics Structure-shynessStructure-shyness

– Can build DSL objects using constructors and use Can build DSL objects using constructors and use AspectJ to implement meaning of DSL objects. Is AspectJ to implement meaning of DSL objects. Is inconvenient (sentence is shorter than abstract inconvenient (sentence is shorter than abstract syntax tree = object) and syntax tree = object) and

Lack of static checking in AspectJLack of static checking in AspectJ– Hinders static checking of DSL objectsHinders static checking of DSL objects

Improved AspectJ => makes implementation of plugins easier


C Is X-shy.C Is X-shy.

A concern C is X-shy if C can adapt to small A concern C is X-shy if C can adapt to small changes in X or if C relies only on minimal changes in X or if C relies only on minimal information of X (topological).information of X (topological).

Domain-specific aspect languages allow Domain-specific aspect languages allow problems to be decomposed to support problems to be decomposed to support concern-shy representations of concerns.concern-shy representations of concerns.


Problems With Multiple Domain-Problems With Multiple Domain-specific Aspect Languages.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.


IdeaIdea

n*n n

AspectJ


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.


AJC: XAJC: PLUG-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.


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.


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.


3. Initial Bytecode Generation.

The AspectJ compiler generates bytecodes from the plug-in defined external interfaces and the remainder of the program.


4. Crosscutting Analysis.

The XAspects compiler provides each plug-in the binary of the program to perform reflection or other analysis on it.


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


6. Final Bytecode Generation.

Finally, the new behavioral code is woven into the existing code to create the complete program.


AJC: XAJC: PLUG-INS:

Source Code Identification

Generation of External Interfaces

Initial Bytecode Generation

Crosscutting Analysis

Generation of Semantics

Final Bytecode Generation


Plug-ins Currently Available.

Class dictionary plug-inClass dictionary plug-in Coordination plug-inCoordination plug-in Traversal plug-inTraversal plug-in AspectJ plug-in (includes Java)AspectJ plug-in (includes Java)

DependenciesDependencies– Traversal plug-in depends on Class dictionary Traversal plug-in depends on Class dictionary

plug-in and AspectJ plug-in.plug-in and AspectJ plug-in.


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.


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.


Too Many Languages?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.


Too Many Languages?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.


Another Weakness of General Another Weakness of General Aspect-oriented Programming …Aspect-oriented Programming …

is the difficultly of using the language correctly. A is the difficultly of using the language correctly. A novice can easily create an infinite loop in AspectJ if novice can easily create an infinite loop in AspectJ if an advice happens to apply to itself. More subtle an advice happens to apply to itself. More subtle misapplications of advice can also occur. If a custom misapplications of advice can also occur. If a custom aspect language is created for a specific domain these aspect language is created for a specific domain these misapplications can be checked by the plug-in. While misapplications can be checked by the plug-in. While a reusable AspectJ aspect might be able to implement a reusable AspectJ aspect might be able to implement some of the functionalities of an XAspects plug-in, it some of the functionalities of an XAspects plug-in, it cannot perform some of the compile time checks cannot perform some of the compile time checks needed to ensure that the aspect is being used needed to ensure that the aspect is being used correctly. correctly.


Conclusions.Conclusions.

Aspect-Oriented Software Development Aspect-Oriented Software Development (AOSD) is a useful technology for the rapidly (AOSD) is a useful technology for the rapidly evolving area of scientific warehouses.evolving area of scientific warehouses.

XAspects is a tool that supports AOSD in a XAspects is a tool that supports AOSD in a more powerful way than a general purpose more powerful way than a general purpose aspect-oriented language. aspect-oriented language.


The EndThe End


Lessons From Manager Lessons From Manager Metaphor (Continued).Metaphor (Continued).

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

3/7/2003 abb rapid change 1 how to address rapidly changing data representations in an evolving...

Documents

interface changes

rapid changeprotect

format of source data

rapid changesome quotes

rapid changemore quotes

adaptive programming

headgordon refinement

changing data representations