Preface

Aspects are a natural evolution of the object-oriented paradigm. They provide a solution to some difficulties you may have encountered with modularizing your object-oriented code: sometimes functionality just doesn't fit! You've probably found yourself repeating the same lines of code in lots of different object-oriented classes because those classes each need that functionality, and so you can't easily wrap it up in a single place. Good examples of this kind of code are audit trails, transaction handling, concurrency management, and so on. You can now modularize such code with aspects.

We've seen similar levels of enthusiasm with adopting aspects as there were with adopting objectsan enthusiasm we share; but starting out with aspects can be a tricky business. Making the shift to aspect-oriented thinking may not be as tough as many people found the shift to object-oriented thinking, but aspects still might take a little getting used to. The big question that springs to mind when trying out aspect-orientation for the first time is "What are my aspects?" and early adopters have taken various approaches to try to address it.

We've heard of practitioners trying to apply aspects, but who can't think of any except those typical, and somewhat trivial ones. The usual examples are out there to be tried: logging, debugging, coordination. But to make fluent use of aspects, you also want to be able to use them for concerns that are specific to your own code.

We've heard of others who have made so many tiny aspects that the classes in their core system have no functionality whatsoever! They achieved so much "separation of concerns" that they could hardly work out the control-flow of their programs.

Another typical approach to answering the "what are my aspects" question is to just program vanilla OO code, and then try to spot the functionality that doesn't quite fit in. That approach has some serious disadvantages. In particular, it keeps you from being able to reason about aspects until you start to code. After all, you probably don't wait until you start to write code before figuring out what your classes should be (even if they're only a starting point). It's the same deal with aspects.

Besides being somewhat confusing, early adoption of a paradigm has some risks. Aspect-orientation is in an exciting phase of growth, but that means that new languages and new possibilities are coming out frequently, and that the basic notions of an "aspect" shifts subtly as new philosophies are revealed. There are different styles of decomposition, even within aspect-orientation. Which should you choose?

In this book we describe the Theme approach for identifying aspects in requirements, and modeling them at design. A major strength of the Theme approach is that it allows you to identify and model aspects regardless of the aspect-oriented programming language you choose. Our intention in developing the Theme approach was to enable it to withstand these shifts by keeping it separate from any particular programming language and by offering a general-purpose way to identify and describe aspects, regardless of their definition at the code level.

In addition to talking about the Theme approach and how to apply it, we also describe the different "worlds" of aspect-orientation, and how the Theme approach fits into them. You will come away from reading this book with not just tools for analysis and design, but also with an understanding of the general field of AO as it stands today. That knowledge will help you make more informed choices when picking an aspect-oriented implementation language, and decomposition paradigm.