Aspect-Oriented Software Development with Use Cases

Despite the title of my review I would like to say that first up great book. The only criticism I would offer is that the Requirements Engineering world has unified around i* approaches [...]which are especially good at capturing and expressing non-functional requirements. I think pushing use cases at non-functional requirements is a little nieve given the semantics. What appears to be happening in places is a merging of i* and Use Case approaches (especially at System Engineering leves)[...]. i* doesn't break the intent of what Jacobson and Ng attempt with so-called "Infrastructure Use Cases". i* is simply designed for functional and non-functional modelling - rather than trying to use a screw-driver as a hammer. Why bother? Use case have come from the C++ world where software developers would scratch a quick "requirement" model before diving into coding. Agile methods have diluted this to "User Stories" which look remarkably like "features" as expressed by Jacobson/Ng. (In i* "features" whould be variously hard or soft goals.) So what would be ideal? The next edition moulds Aspects, Goals (i*) and Use Cases together.

Nothing more to say. Clear explanation that Aspect Programming fills the gap in software engineering, and that this it is more than just fancy logging mechanism. But this book makes also clear that Aspect Programming must be used from very early stages of software design process, but not simply as add-on to object oriented design. Worth to read, despite whether you will use Aspect Programming or not. If not, you will know the limitation of Object Oriented paradigm. If yes, you will know how to use Aspect programming right

Jacobson and Ng present a detailed exposition of what aspect oriented programming means. As implemented in the AspectJ language, an extension to Java for expressly this purpose. They explain that object oriented programming has a conceptual limitation. Indeed, it is good to separate code into components using OO. But in general you have M concerns and N components, where M>N. Sometimes, M>>N. So if you imagine an M x N matrix, then you can easily see how entanglement arises. A given component may have code from multiple concerns. Which makes it harder to implement and maintain. <br /> <br />The authors describe how if you start at the design level, with use cases, that these can effectively be considered concerns. Then, taking these use cases and using AspectJ, you can design and write code that keeps the use cases/concerns separate as much as possible. While being able to compose code for several concerns when necessary. Use cases are of course widely used in many design processes. An attraction of this book is in showing how starting with the familiarity of use cases, you can logically understand and implement an aspect oriented coding. <br /> <br />The book is primarily written at the design level. While some small code fragments are offered as examples, you should have some earlier knowledge of AspectJ. The book is not, per se, a syntax manual on the latter.

No one has reviewed this?? This is a great book. Jacobson describes it as the result of a kind of epiphanal realization that AOP could solve an inherent problem in use case design. This is how the book hooked me: rather than just showing AOP as a series of stunts, or explaining it w/the usual little examples (logging, exceptions, etc.), this book starts w/the strategic implications and then works down to the tactical. The basic premise is that the so called separation of concerns is always followed by a required recomposition of said concerns and that aspects provide a means of recomposing w/out introducing 'leaks' and the like. It's pathetic that no one is reading this book. Ballmer was mooning last week about how he's going to erase Rational (and with it the UML). Jacobson and use cases are the best part of the UML and one of the great things about this book is it opens the door to a conception of a different design approach that short circuits some of the flab from the RUP req/spec cycle (which, when trying to be iterative, tends instead toward rapid repeat waterfall). Despite the apparent dearth of readership, I predict this book will be seen as one of the most important of this decade.