Aspect-Oriented Analysis and Design: The Theme Approach
Be the First to Write a Review and tell the world about this title!People who purchase this book frequently purchase: - Aspect-Oriented Software Development with Use Cases; Ivar Jacobson, et al, $41.95, 30% Off!
- Java in a Nutshell, 5th Edition; David Flanagan, $28.50, 37% Off!
- Aspect-Oriented Software Development; Robert E. Filman, et al, $41.95, 30% Off!
- The Zen of CSS Design: Visual Enlightenment for the Web (Voices That Matter); Dave Shea, et al, $28.50, 37% Off!
Books on similar topics, in best-seller order:Books from the same publisher, in best-seller order:
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. 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 objects – an 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 what so ever! 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.
Audience
For a wide range of situations, AOSD improves the software development process.
This book offers a high-level introduction to the aspect-oriented approach,
and gives instruction on a useful approach for identifying aspects in requirements,
and for designing them in an aspect-oriented way using UML with a small number
of extensions.
We have written this book for practitioners and early adopters of aspect-orientation.
This book will be particularly helpful for those who are trying to answer the
common questions of "What is an aspect?" and "Which aspects should
I be coding?" This book gives you a starting point for thinking about aspects,
and accounting for them in your requirements and design.
Even if you've been using aspect-oriented languages for a while, you can read
this book to learn more about identifying aspect functionality in requirements
documentation and how to plan for aspect-design and implementation. The Theme
approach gives a flexible way to identify aspect-functionality, and a UML-based
design modeling language that can describe aspects independently of programming
language. Whatever your aspect-oriented programming language, the analysis and
design approach and principles described in this book will be helpful and informative.
This book is also useful if you don't have the luxury of programming using
an aspect-oriented language, but would still like to consider aspects in requirements
analysis and design. This book talks about how to fuse aspect-oriented analysis
and design with object-oriented implementation.
Of course, this book would also be helpful to academics or students wishing
to learn more about the aspect-oriented paradigm.
For all readers, we assume that you are familiar with the object-oriented paradigm,
and are comfortable with the UML notation.
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) 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. 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 formulation was worked on in collaboration with IBM Research, and
so the design model has benefited considerably from subject-oriented programming
principles. Nonetheless, as you'll see reading this book, we see the Theme approach
as encompassing different aspect schools of thought, and so we 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 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. Theme/Doc helps you find the aspects in your requirements. Theme/UML
helps you design them. Together, they form the Theme approach.
How to Read This Book
Of course, the most straightforward way to read this book is from start to
finish. The book follows the basic structure of introduction and motivation
(Chapters 1 and 2), overview and illustration of the approach (Chapters 3-8)
and examples of its application (Chapters 9 and 10).
However, different parts of the book may be of more interest than others, depending
on your perspective. If you're not sure what an aspect even is, then Chapters
1, 3 and 5 will be of lots of help. They go over the basic concepts and walk
you through finding aspects in a set of requirements.
If you're not convinced aspects are all that great, and are asking the question
"Why do we need them anyway?" then Chapter 2 will be for you. Chapters
9 and 10 will also provide you with examples of how aspects can be applied in
different kinds of systems.
If you'd like instruction on capturing aspects in design, then Chapters 6 and
7, which provide details of Theme/UML will walk you through designing the aspects
and the core of your system, and on capturing the specification of their composition.
Table of Contents
Preface.
1. Introduction.
2. The Object-Oriented Way.
3. The Theme Approach.
4. Analysis.
5. Theme Design.
6. Theme Composition.
7. Map to Implementation.
8. Case Study: Phone Features.
9. Case Study: Usage Licensing.
Appendix. The Crystal Game.
Index.
Other Loose Elements.
|
