A Theory of Aspects as Latent Topics

Underlying the work on Aspect-Oriented Programming (AOP) there is a premise that no one ever challenged: the existence of cross-cutting concerns that find their way to programs in a tangled and scattered manner. We’ve all seen it. But do tangling and scattering of program concerns really exist in real programs? Do they have a strong effect or is this one of those academic non-issues? That was the question we set out to answer in a paper we published at OOPSLA 2008. And the answer was: yes, these effects do exist in real programs, they are noticeable and detectable, and they reveal a few insights on the nature of those concerns. But they raise even more questions for AOP. Here is a summary of our study. For all the details, read the paper [1].

Let me explain briefly how we detect aspects in this study. We don’t; we detect topics using an unsupervised topic modeling technique called Latent Dirichlet Allocation (LDA). This technique is used very successfully for topic modeling  in text. It works by finding co-occurrences of words in bags of words (files/texts/whatever); the topics emerge given the most frequent co-occurrences of groups of words. It’s a probabilistic model, meaning that it has some nice smoothing properties and a few other goodies such as the distribution (aka entropy) of those topics across files and within files — a direct measure of scattering and tangling of topics.

Let me back track a little. This work came to be because Erik, who, at the time, knew nothing about AOP, decided to run LDA on a few hundred Java projects we had laying around; then one day he showed me the latent topics that emerged from that experiment, and that’s when it hit me — holy crap!, these are aspects! So yeah, I wish I could tell this was all part of a grand plan, but it wasn’t; it was an accidental finding.

After that first experiment, we tuned a few things in our method of using LDA (like, for example, carefully selecting which words to use) and ran it again over a much larger collection of Java projects. Again, the surprising finding was that the topics that emerged with high entropy across that very large collection of Java programs included, among many others, the concerns that the AOP community had been using as examples of aspects in the first place: persistence, authentication, exception handling, concurrency, etc. This was very interesting, and immediately made me want to explore how the concept of latent topic related with the concept of aspect.

But something was still a bit off: we ran LDA on the entire collection of 5,000 projects or so; we were treating the entire collection as one big project. A such, and on second thoughts, it was not surprising to find that things like concurrency cut across many projects/files. The latent topics with high entropy read almost like a “list of things you need to deal with if you program in Java.” Perhaps if we ran it on a per project basis, things would look different.

Indeed, things looked different on a per-project basis. There was some overlap on generic things like string manipulation; but the interesting thing is that some of those topics were very specific to the projects in question. For example, for JHotDraw (a graphics editor) we got topics that are clearly related to drawing; for Jikes (a Java compiler) we got groups of words that are quite reasonable to find in a compiler; for CoffeeMud (a MUD game engine) we got this mysterious word “mob” prominently represented in several topics; we had to look into the documentation of that project to solve the mystery: it stands for Mobile OBject, a central concept in that engine — basically NPCs.

Then we plotted the topic distributions for 5 projects on the same plot and saw an interesting fact: some projects show more topic scattering than others.  CoffeeMud is noticeably more scattered. JHotDraw has a handful of very scattered topics, but most of the topics in it are a lot less scattered than all topics in all other projects. Jikes is the most regular one, with less variation.

Could this be a good metric for measuring the accidental complexity of projects? I.e. is the CoffeeMud code base a mess compared to, for example, the code base of Jikes? This is definitely an interesting conjecture, but it’s nothing more than a conjecture at this point. That relates to the second never-challenged assumption underlying AOP: that tangling and scattering are “bad” for software development. Our study here shows that there is scattering and tangling of topics, and gives us a nice mathematical framework for quantifying those effects, but it says absolutely nothing about whether that is a good thing or a bad thing.

The results raise a lot of questions for AOP, and the paper has a lengthy discussion regarding the findings. I’m going to end this summary with the issue that I think is more itchy.

A lot of scattered topics we saw emerging were clearly uses of specific APIs — string manipulation, list manipulation, xml, io, etc. This resonates with my experience; some things are used everywhere. “String manipulation,” for example, could be seen as an aspect of programs; it would be perfectly reasonable to want to understand what the entire program is doing wrt that. If AOP says that scattering is bad, does it mean that scattering of string manipulations is bad? Should we localize string manipulations in programs? Should we extract them out into a separate module and do reverse binding?

If that would be odd, then a question is raised about the reason for doing that for concerns such as logging and concurrency. At the very least, that practice, advocated by AOP from early on, requires a better justification.

I have my own view on these questions, but that’s a topic for another paper/post.

This work was a collaboration between myself, Pierre Baldi and Erik Linstead, with help from Suhil Bajracharya. Work in part supported by National Science Foundation grants EIA-0321390, CCF-0347902 and CCF-0725370 and a Microsoft Faculty Research Award.