Dissertation is Complete
The final dissertation, as handed in to the library.
Eventually, I'll get around to fixing remaining bugs, and then will offer both the original and the newest version.
(Conforms to the NEU-library's hard-to-find thesis guidelines.)
For historical reasons, you can also download the thesis proposal, and the slides used to present it.
I presented a summary of the thesis proposal at at the OOPSLA 2002 Doctoral Symposium, which also generated some slides.
I also made some posters for the poster session.
They feature the dinocow. Unlike dogcows, dinocows don't do pixel-perfect alignment, nor do they go "Moof!", but they do decompose into modules and aspects.
There are basically three competing facets to programming: Programmers want to write Large, Complex programs, Quickly.
I'll discuss these ideas in the context of Object Oriented programming, as this is both the predominant programming paradigm, as well as the context in which I've worked.
The tools typically availible to tackle this task are modularity and teams of programmers.
allows the programmer to specify an interface to the rest of the world, behind which implementation details can be hidden.
This allows the construction of large programs, as each module can---hypothetically---be developed separately from the rest of the system.
However, in order to be effective, the granularity of the module must be in line with the size of the program.
This implies that class-sized modules will be too small for many real-world applications.
the programmer really wants to have the ability to apply interfaces to sets of collaborating classes.
Teams of programmers
allow programs to be constructed quickly.
Typically, this interacts well with modularity, by programmers taking ownership of modules.
allow complex behaviors to be succintly specified.
By assumption, complex behavior will need to touch widely separated parts of program, presumably in separate modules, owned by different teams.
However, this does not fit well in with the solutions to the other two requirements.
The encapsulation boundaries of modules hinders a external code from accessing internals of modules.
A single person owning all modules could conceivably modify several modules to acheive the desired effect, but this becomes infeasable when scaled up to teams of programmers.
The solution is to build aspectual features into the module system.
This allows us to leverage, rather than work-around, the encapsulation features.
My research demonstrates how the aspects and modules can be combined into a modularity layer around Java.
We allow each multi-class module---we call them collaborations---to be separately compiled and the composed into larger and larger program units.
Each collaboration defines an encapsulation interface with both imports and exports.
In addition to dealing with classes, methdods, and fields, collaborations support aspectual features.
We allow "aspectual methods" in one collaboration to be set up to intercept and control the executions of methods in other collaborations.
Thus, each module has both explit (the provided and required members) and implicit (execution interceptions) interfaces that are linked during composition.
This allows us to impose encapsulation and compositional reasoning onto aspects while retaining the obliviousness that makes them so useful.
FJacc, is a toy interpreter which allows programs written in a superset of featherweight java to be composed and evaluated.
This is an implementation of the rules that we use for our proof of statically type safe generic advice.
Since it lacks side-effects, io, and numbers, it's practical uses are somewhat limited.
However, for the curious who want a cheap way to explore ACs this is a very convenient entry point.
A proof-of-concept implementation for full Java is also availible.
It predates the formal analysis, and thus has some design flaws in how aspectual methods are handled (it will break if an aspectual method is both used and exported).
A re-implementation is underway.
The salient features of aspectual collaborations are:
- Collaborations are layers around Java
- Separate compilation
- Resusable, type safe, aspectual features