History of Aspect-Oriented Analysis and Design and The Theme Approach

Analysis and design approaches for software engineering paradigms have traditionally emerged after people have explored the ideas at the programming level for a while. From there, application of the ideas tends to move backwards through the software lifecycle. This is true of aspect-oriented analysis and design and so before we look at the origins of Theme, we'll first take a quick look at what was happening at the code level from the early 1990s.

It's hard to choose where to begin a history of aspect-oriented programming, as a lot of the work we talk about as AOP emerged from the creators' previous work in the general area. We could also take a broader view in the larger context of software engineering, as many researchers have been working on improving software modularization for decades in work that is not viewed under the "Aspect" umbrella. We'll take the easy way out here, and simply mention the four main approaches to improved modularization that are popularly regarded as being the origins of aspect-oriented software development.

The most well known approach is the one popularized by the AspectJ language, which was first developed by a team from Xerox PARC in 1997, led by Gregor Kiczales. Previously, the team had worked on metaobject protocols and reflection, with ideas evolving to the modularisation of "crosscutting" concerns. Meanwhile, in 1993, a team from IBM T.J. Watson Research Center, led by William Harrison and Harold Ossher, published work on "subject-oriented programming". Subject-oriented programming (and its later incarnations as multi-dimensional separation of concerns co-led by Peri Tarr) looks at flexible decomposition and composition of software modules based on different dimensions of concern. The academic community was also hard at work; the next two approaches emerged from university research. At the University of Twente in The Netherlands, Mehmet Aksit and his team had been working on Composition Filters since the early 1990s. With this approach, behavior is modularized in "filters" that can be used to capture and enhance the execution of object behavior. Karl Lieberherr at Northeastern University in the US defined the Demeter Method in the mid 1990s that provides abstractions of the class structure and navigation to support better separation of this knowledge from an operation's behavior. Crista Lopes worked with both Karl Liberherr and Gregor Kiczales in developing D-Java, and the first official set of "Aspect languages" in 1997. Fast-forward to 2004 and aspect-oriented programming languages are coming out of the woodwork! Notably, though, each of the new ones is rooted in principles that originated from one or more of the original four.

Back to analysis and design. In those early years of aspect-oriented programming, there was little to no work being published on supporting aspect-like principles at earlier stages in the development lifecycle. The Theme approach to aspect-oriented design was the first approach to incorporate aspects into the UML, with Siobhán giving some early ideas their first "outing" at an OOPSLA workshop in 1997. Its further formulation was worked on in collaboration with IBM Research, in particular with Peri Tarr, Harold Ossher and William Harrison, and also with Robert Walker from (at the time) the University of British Columbia. The design model benefited considerably from subject-oriented programming principles to the extent that it was labeled "subject-oriented design" for a few years. However, as you'll see reading this book, we see the Theme approach as encompassing different aspect schools of thought, and so Siobhán re-labeled the work on "subject-oriented design" to "Theme/UML" in 2001.

Identifying and visualizing concerns in documentation was initially explored by Elisa with Gail Murphy of University of British Columbia, and Christa Schwanninger of Siemens AG. That work motivated Theme/Doc's emergence in 2003 as the aspect-oriented analysis part of the Theme approach. Theme/Doc is intended as a complement to your existing analysis process, and is the missing link between having a set of requirements, and knowing what aspects should be designed using Theme/UML.

In forming the Theme approach, we kept in mind the real goals of the programmer: to understand the problem space (the requirements), and design appropriately. Our goal was to create an approach that allows the developer to map requirements to design to code. Theme/Doc and Theme/UML provide this mechanism. Theme/Doc helps you find the aspects in your requirements. Theme/UML helps you design them. Together, they form the Theme approach.