ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1949 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
Aspect-Oriented Analysis and Design
Siobhan Clarke, Elisa Baniassad
Addison Wesley
Simon Sebright
Appeared in:

This is an academic book. The authors are academics, and the contents of the book are distillations of their research. It reads academically in that it is very factual, self consistent and dry. There is a lot of UML.

They present a combination of their work into aspect-oriented techniques, which they call the theme approach. It consists of two parts - Theme/Doc and Theme/UML. They constantly refer to these as "tools" and that they can regenerate diagrams, and extend UML, but I didn't see anything saying if or where one could acquire these tools, so I assume they are in development, which reinforces the academic nature of this.

The theme approach is to treat all concerns in the requirements as themes. Theme/Doc allows you to associate requirements with themes and identify aspect or cross-cutting themes. Theme/UML is a UML extension allowing you to design the themes in UML and combine them using various notations into a final model.

There are a couple of case studies used in the book, a mobile multi-player game, a mobile phone system and licensing. I didn't really get the feeling that these were really presenting me with full solutions, but they get the point across of how to identify aspect themes.

This is really quite leading edge stuff, and wouldn't be directly useful without the tool support they seem to have. Also, it all ends in a UML model, and then you have to create the code, making it all seem a little pointless. The idea was to have code represent the requirements more closely, but their process ends only with a model, and you have to make decisions about how that gets implemented. True, if you use an aspect-oriented language you can benefit from whatever aspects it supports.

I decided to review this to learn a bit about aspects, and I certainly did. But, I found the book somewhat repetitive. They have a style of telling you something in overview, telling you in detail and then telling you with example.

In summary, well written but quite narrow in scope.