- Copyright 2005
- Dimensions: 7" x 9-1/4"
- Edition: 1st
-
Book
- ISBN-10: 0-321-24674-8
- ISBN-13: 978-0-321-24674-5
"Developers who are using aspect-oriented programming will appreciate this contribution to aspect-oriented analysis and design. The authors are pioneers in this area and have elaborated on past research to produce a detailed methodology and notation for early aspects."
—Ron Bodkin, Chief Technology Officer, New Aspects of Software
"Aspect-orientation is a powerful approach for programming complex systems. There is a lot to be gained from applying this approach during modeling and designing, as well. The Theme approach in this book represents an important advancement in AOP adoption by providing practitioners means to apply aspect-orientation early on."
—Ramnivas Laddad, Author of AspectJ in Action
"Clarke & Baniassad have written an interesting book that shows how to use aspects to solve a difficult problem: composing independent program fragments with overlapping functionality. The included case studies well illustrate the principles. I recommend the book.
—Charles B. Haley, Research Fellow, The Open University
"This book presents a very useful set of techniques for helping software developers to identify the aspects. I am sure that this book will rapidly become a landmark reference for the software community!"
—João M. Fernandes, Ph.D., Universidade do Minho
Aspect-oriented software development (AOSD) is emerging as a viable approach for allowing the separate expression of multiple concerns along with "weaving" technologies for knitting together these separate expressions into coherent systems. Thanks to its great promise as an approach to simplifying the development of complex systems, many expert observers view AOSD as a worthwhile successor to the prevalent object-oriented paradigm.
In this new book, two AOSD experts apply theory to the practical realm of real-world development. They explain the different kinds of aspects, help the reader identify them, and provide guidance on successful design and implementation. The result is an applicable and easy-to-digest methodology for simplifying and optimizing the development of software systems.
Aspect-Oriented Analysis and Design: The Theme Approach will be particularly helpful for developers who are trying to answer the common questions of "What is an aspect?", "Which aspects should I be coding?", and "How do I design aspects?" Readers will come away with a starting point for thinking about aspects and accounting for them in requirements and design.
Meanwhile, seasoned AO practitioners will learn more about different models of decomposition, identifying aspect functionality in requirements documentation, designing aspects, and how to map aspect designs to code. The authors’ groundbreaking Theme approach to AOSD offers both a flexible way to identify aspect functionality and a UML-based design modeling language that can describe aspects independently of programming language.
In short, practitioners and early adopters of AO alike will appreciate this book’s practical information on how to make the significant shift to AOSD.
© Copyright Pearson Education. All rights reserved.
Online Sample Chapter
Introduction to Aspect-Oriented Analysis and Design
Downloadable Sample Chapter
Download the Sample
Chapter related to this title.
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.
Preface
Untitled Document
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 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 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.
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.
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 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.
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-6), guidance
on mapping your designs to some AOP languages in Chapter 7 and examples of its
application (Chapters 8 and 9).
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 4 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
8 and 9 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 5 and
6, 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.
Index
Download the Index
file related to this title.