SKIP THE SHIPPING
Use code NOSHIP during checkout to save 40% on eligible eBooks, now through January 5. Shop now.
Register your product to gain access to bonus material or receive a coupon.
An introduction for developers who need practical information to make the significant shift to aspect-oriented development.
° The first proven methodology for moving beyond aspect-oriented programming to the discipline of analysis and design
° Introduces aspects, helps the reader identify them, and provides guidance on successful implementation
° The aspect-oriented model is particularly well-suited for transaction handling, tracing, database compatibility, performance management, exception handling, and more
"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.
Introduction to Aspect-Oriented Analysis and Design
Download the Sample
Chapter related to this title.
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.
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.
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.
Download the Index
file related to this title.