From the Back Cover
“A refreshingly new approach toward improving use-case modeling by fortifying it with aspect orientation.”

—Ramnivas Laddad, author of AspectJ in Action “Since the 1980s, use cases have been a way to bring users into software design, but translating use cases into software has been an art, at best, because user goods often don’t respect code boundaries. Now that aspect-oriented programming (AOP) can express crosscutting concerns directly in code, the man who developed use cases has proposed step-by-step methods for recognizing crosscutting concerns in use cases and writing the code in separate modules. If these methods are at all fruitful in your design and development practice, they will make a big difference in software quality for developers and users alike.

—Wes Isberg, AspectJ team member“This book not only provides ideas and examples of what aspect-oriented software development is but how it can be utilized in a real development project.”

—MichaelWard, ThoughtWorks, Inc. “No system has ever been designed from scratch perfectly; every system is composed of features layered in top of features that accumulate over time. Conventional design techniques do not handle this well, and over time the integrity of most systems degrades as a result. For the first time, here is a set of techniques that facilitates composition of behavior that not only allows systems to be defined in terms of layered functionality but composition is at the very heart of the approach. This book is an important advance in modern methodology and is certain to influence the direction of software engineering in the next decade, just as Object-Oriented Software Engineering influenced the last.”

—Kurt Bittner, IBM Corporation “Use cases are an excellent means to capture system requirements and drive a user-centric view of system development and testing. This book offers a comprehensive guide on explicit use-case-driven development from early requirements modeling to design and implementation. It provides a simple yet rich set of guidelines to realize use-case models using aspect-oriented design and programming. It is a valuable resource to researchers and practitioners alike.”

—Dr. Awais Rashid, Lancaster University, U.K., and author of Aspect-Oriented Database Systems “AOSD is important technology that will help developers produce better systems. Unfortunately, it has not been obvious how to integrate AOSD across a project’s lifecycle. This book shatters that barrier, providing concrete examples on how to use AOSD from requirements analysis through testing.”

—Charles B. Haley, research fellow, The Open University, U.K.

Aspect-oriented programming (AOP) is a revolutionary new way to think about software engineering. AOP was introduced to address crosscutting concerns such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling in a more effective manner. Unlike conventional development techniques, which scatter the implementation of each concern into multiple classes, aspect-oriented programming localizes them.

Aspect-oriented software development (AOSD) uses this approach to create a better modularity for functional and nonfunctional requirements, platform specifics, and more, allowing you to build more understandable systems that are easier to configure and extend to meet the evolving needs of stakeholders.

In this highly anticipated new book, Ivar Jacobson and Pan-Wei Ng demonstrate how to apply use cases—a mature and systematic approach to focusing on stakeholder concerns—and aspect-orientation in building robust and extensible systems. Throughout the book, the authors employ a single, real-world example of a hotel management information system to make the described theories and practices concrete and understandable.

The authors show how to identify, design, implement, test, and refactor use-case modules, as well as extend them. They also demonstrate how to design use-case modules with the Unified Modeling Language (UML)—emphasizing enhancements made in UML 2.0—and how to achieve use-case modularity using aspect technologies, notably AspectJ.

Key topics include Making the case for use cases and aspects Capturing and modeling concerns with use cases Keeping concerns separate with use-case modules Modeling use-cases slices and aspects using the newest extensions to the UML notation Applying use cases and aspects in projects

Whatever your level of experience with aspect-oriented programming, Aspect-Oriented Software Development with Use Cases will teach you how to develop better software by embracing the paradigm shift to AOSD.



About the Author

Ivar Jacobson is one of the “fathers” of components and component architecture, use cases, modern business engineering, the Unified Modeling Language, and the Rational Unified Profess. He is the principal author of five best-selling books on these methods and technologies, in addition to being the coauthor of the two leading books on the Unified Modeling Language. Ivar is an executive technical consultant to IBM Rational and founder of Ivar Jacobson International. He is also currently focusing his efforts on his new software company, Jaczone AB, where he and his daughter and cofounder, Agneta Jacobson, develop intelligent agents for software development.

Pan-Wei Ng, Ph.D., plays multiple roles in Ivar Jacobson International (IJI). As a member of the IJI Technology Office, Pan-Wei defines best practices in architecture, use cases, iterative development, business modeling, active software, and aspects. He develops materials for some of these best practices and conducts research in other best practice areas. Pan-Wei also actively works on customer accounts to enable companies and project teams to adopt these best practices quickly and safely. These projects range from telecommunication and defense to business applications; from command and control systems to business applications, middleware messaging systems, and embedded systems; from in-house development to outsource development and product development. Pan-Wei works alongside practitioners and ensures that the best practices developed are both relevant and practical.

Excerpt. © Reprinted by permission. All rights reserved.
What Is Aspect-Oriented Programming?

That you have picked up this book tells us that you are a member of the software development community: a tester, a developer, a project leader, a project manager, an architect, an analyst, or a member involved in one of the many other aspects of developing. We also know that you are someone who wants to improve the way you develop software. You want your system to be more maintainable, more extensible, more reusable, and if you are a project leader, you want your team to be more productive. You know that these goals are not always easy to achieve.

Why is software development so difficult? One reason is that there are many things to watch out for. On the human side, you have to watch out for time, budget, resources, skills, and so forth. Frequently, as a team member, you have many tasks—some of them beyond what you are paid for. You report to two different people and each expects 100 percent from you, so you must give 200 percent to your work. As the developer, you must understand the application, the domain, and the idiosyncrasies of the platform. When you design the system, you need to deal with and balance many difficult concerns: how the system meets its intended functionality, how it achieves performance and reliability, how it deals with platform specifics, and so forth. You may find that your code—your classes, your operations, your procedures—must perform many functions, which may lead to spaghetti code, an indication of poor design. So, you need to improve design—improve modularity and provide better separation of concerns. Just as each team member must be clearly focused on his or her work, each component, each class, each operation must be focused on what is its specific purpose.

But there is a limit to what you can do with existing techniques. No matter how far you go, you find that many parts of your system have code fragments that have to do with logging, authorization, persistence, debugging, tracing, distribution, exception handling, and other such tasks. Sometimes, a sizeable portion of an operation or class has nothing to do with what it is supposed to do. Aspect-oriented programming (AOP) refers to such redundancy as crosscutting concerns because you find these code fragments in many operations and classes in your system—they cut across operations and classes. Crosscutting concerns are not limited to the technical concerns such as authorization and persistence. They include system and application functionality, and you find that a change in functionality often results in changes in many classes too.

AOP gives you the means to separate code that implements crosscutting concerns and modularize it into aspects. Aspect-orientation provides the mechanism to compose crosscutting behaviors into the desired operations and classes during compile time and even during execution. The source code for your operations and classes can be free of crosscutting concerns and therefore easier to understand and maintain. What Is Aspect-Oriented Software Development?

In order to progress beyond AOP, you need a holistic approach to developing software systems with aspects from requirements, to analysis and design, to implementation and test. This is aspect-oriented software development (AOSD).

AOSD is about better modularity for the entire system, encompassing concerns of many different kinds—better modularity for functional requirements, nonfunctional requirements, platform specifics, and so on—and keeping them separate from each other. Keeping all concerns separate allows you to construct systems that have a more understandable structure and are easily configured and extended to meet the evolving needs of stakeholders.

AOSD is not just AOP. It encompasses a whole range of techniques to help you achieve better modularity. These techniques include object orientation, component-based development, design patterns, object-oriented frameworks such as J2EE and .NET, and more. AOSD does not compete with existing techniques but is built on top of them. AOSD with Use Cases

How do you conduct AOSD? How do you identify aspects? When do you use classes as opposed to aspects? How do you specify aspects? You need a sound and systematic approach to help you conduct AOSD. The development community is crying out for this kind of systematic approach to software development.

In fact, there is such a systematic approach—and a mature one too. It is called the use-case-driven approach. It provides a sound method for developing applications by focusing on realizing stakeholder concerns and delivering value to the user.

It is well known that aspect orientation helps modularize crosscutting concerns during implementation, but there is a need to modularize crosscutting concerns much earlier, even during requirements. Use-cases are an excellent technique for this purpose. Use-cases are crosscutting concerns, since the realization of use cases touches several classes. In fact, you can model most crosscutting concerns with use-cases, and we demonstrate use-case modeling in the book.

The underlying concept in aspect orientation is similar to the concept of use-case-driven development. This means that you get a seamless transition from expressing requirements of stakeholder concerns with use-cases to implementing them with aspects.

Briefly, you conduct AOSD with use-cases as follows: You model crosscutting concerns with use-cases. You design use-cases in terms of overlays on top of classes—overlays called use-case slices and use-case modules. You use aspect technology to compose use-cases slices and use-case modules to form the complete model for the system.

We use a home-construction analogy to explain the approach further. Let’s say you have a new house, but it is just an empty house with no fixtures— no lights, no phone lines, no wiring, no gas, and no Internet! Each missing fixture or service is a distinct concern, evidenced by the fact that you need to call different specialists to install each fixture or service. The fixtures and services are crosscutting concerns—they cut across different rooms (i.e., objects). They are analogous to use-cases. To determine how he or she will go about his or her job, each specialist must design a plan, often in terms of a diagram based on the floor plan. The floor plan shows where the rooms and the walls are. The electrician makes a photocopy of the floor plan and draws how she intends to install electric wiring; the plumber sketches out how he plans to run water pipes around the house; and so on. Each specialist can work separately, but all of them base their work on the same floor plan. The overall work to be done is the sum of all these diagrams.

If each specialist were to draw his or her diagram on a transparency, the transparencies could be merged by overlaying them on a projector. These overlays are analogous to what we call use-case slices and use-case modules. As long as the overlays are based on the same dimensions of the floor plan, you can get a perfect image on the screen showing all the work to be done. If there is a need to change the laying of Internet lines, you just rework the overlay that describes that plan and update the merged model. When you project it with the other overlays, you get the updated image of the house. You can easily stack more overlays on the picture or swap in and out overlays. You get a coherent image provided that the dimensions correspond to each other. This represents the architectural work involved.

Systems developed using use-case slices and use-case modules have a clear separation of crosscutting concerns. You can evolve them and extend them. It is easier to make each slice reusable. You can automatically generate certain slices because they do not interfere with other slices. You get better maintainability, better extensibility, and greater productivity with this approach.

The development community can gain even more from conducting AOSD with use-cases. We believe that the adoption of aspect orientation will accelerate significantly by basing it on the use-case-driven approach because this approach has already been widely accepted as a means to drive system development, testing, and delivery. Much literature on the use-case-driven approach is readily available for the development community. A good number of professionals, even companies, exist primarily to instruct and promote its use. Project teams both large and small have been successful in adopting the approach. Thus, it is attractive and even natural to base AOSD on the use-case-driven approach. What This Book Is

This book systematically outlines how to conduct AOSD with use-cases. We cover requirements, analysis, design, implementation, and test. We demonstrate how to model crosscutting concerns and aspects with UML and how to establish a resilient architecture that is based on use-cases and aspects. We highlight key changes in practice and the paradigm shifts that you must note when applying AOSD. We give pointers on how you can quickly reap the benefits of AOSD in your projects.

We demonstrate how you conduct AOSD in a mixed environment of object-oriented frameworks such as J2EE, object-oriented design patterns, AOP, and so on, because we recognize that these are the challenges you face in practice. We show you how to map aspect and use-case analysis to different design and implementation technologies.

We spend a great deal of time in this book describing how to establish a firm architecture based on use-cases and aspects—an architecture that is resilient to changes.

Some of you may be familiar with earlier works by Ivar Jacobson, such as Object-Oriented Software Engineering: A Use-Case Driven Approach (Addison-Wesley, 1992) and The Unified Software Development Process (Addison-Wesley, 1999). This book should be read in conjunction with those books.

Some of you may have read books on aspect orientation and wondered about its implications for software development as a whole. This is the book for you. Newcomers to aspect orientation will learn its principles and application. If you are familiar with the use-case-driven approach, you should readily recognize the benefits and implications of aspect orientation. This book will help you to appreciate the larger context of aspects—not just AOP, but AOSD.

In this book, we use a single example of a Hotel Management System, which you become familiar with as we progress through the book. By building upon a single example, we keep our discussion of aspect orientation and use-cases focused and concrete. What This Book Is Not

This book is not a programming book. We do not go into details about AOP languages or aspect-oriented frameworks that are currently available. For those details, refer to guide books and tutorials. This book is about aspectoriented software development (not just programming). The emphasis is on a software development approach from requirements to code, applying a number of techniques in a balanced and iterative manner to help you succeed in building your software systems.

This book does not attempt to be an aspect-oriented design cookbook. We do not attempt to discuss all conceivable crosscutting concerns (synchronization, transaction management, caching, etc.). Nevertheless, we believe that the breadth of this book provides the principles and the basis for you to deal with many kinds of crosscutting concerns that you will encounter in practice. What You Need Before Reading This Book

There are several prerequisites to getting the most out of this book. You must have at least some understanding of the Unified Modeling Language (UML). We include some explanation of UML in this book, but we largely expect you to know the basics. We expect you to know what classes are and that you can read use-case diagrams, class diagrams, sequence diagrams, and collaboration diagrams. Incidentally, the last two are called interaction diagrams and communication diagrams in UML 2.0.

If you have ever applied use-case-driven development in a project, then you will really benefit from this book—even if you do not have any background in aspect orientation. We had you in mind when we wrote this book and spent some time to ground you in the basics of AOP.

If you are knowledgeable about aspect orientation and have little idea about use-case-driven development, do not fret. We have you in mind, too. Part II is devoted to acquainting you with use cases and use-case realizations.

We show some code examples in AspectJ to give you a concrete picture of our proposed extension to the UML notation to support AOSD. AspectJ is a language extension of Java that supports AOP. Some understanding of Java is therefore helpful. However, we want to highlight that this is not an AOP book. This book does not intend to teach you the complete AspectJ syntax.

Since we are showing you how to apply AOSD in a mixed environment and how to deal with platform specifics, we need to use some platform to make our discussion concrete. For this purpose, we chose J2EE, so some knowledge of J2EE is useful. If you have ever heard about servlets and EJBs, you should have sufficient background. If you know the J2EE core patterns, better still.

So, welcome—and read this book. How to Read This Book

We organized this book into five parts: Part I, The Case for Use Cases and Aspects

Part I is basically an expansion of this preface. The goal is to help you understand what AOSD with use cases is all about. We highlight some basic cases of crosscutting—peers and extensions—and how aspects solve them. Through some simple code examples, we introduce AspectJ, which is currently the most popular AOP technology. We provide an overview of use-case-driven development as it is today—what use cases are, how use cases are realized, and how they are mapped to classes—and what we expect it to be like tomorrow—with aspects, use case slices and use case modules. Part II, Modeling and Capturing Concerns with Use Cases

Whether you are familiar with use cases or not, you should read Part II. It gives you an overview of the use-case technique and clarifies common misconceptions about use cases. Part II also enhances the use-case modeling technique to provide a seamless transition from use-case modeling to aspect-oriented analysis and design. In particular, we show how pointcuts are modeled within use cases. Part II culminates by walking through a rich example of applying use-case modeling to different crosscutting concerns— both functional and nonfunctional. They are modeled with use cases of different kinds—application use cases and infrastructure use cases. Subsequent parts of the book demonstrate how to drive these different kinds of use cases all the way to implementation. Part III, Keeping Concerns Separate with Use Case Modules

Part III goes deeper into the concept of use-case slices and use-case modules. Use-case slices help you keep the specifics of a use case separate in the design model. They are the overlays we mentioned to keep crosscutting concerns separate. We show you how to model use-case slices and aspects with UML and how our extensions to the UML notation map to AOP. We use this notation and the underlying concepts in Part IV, and the notation is summarized in Appendix B. Part IV, Establishing an Architecture Based on Use Cases and Aspects

The most important determinant to the success of a project lies in its architecture. Part IV demonstrates how to get good architecture, step by step. Among other things, a good architecture keeps concerns of different kinds separate. It separates the use-case-specific from the use-casegeneric, the application-specific from the application-generic; the platform-specific from the platform-independent; and so on. This separation not only makes your system more understandable and maintainable, it also makes your system extensible. It makes parts of your system reusable without causing those parts to be entangled. It also provides room for significant automation when implementing the system.

In Part IV, there are plenty of useful tips and guidelines to such an architecture. You might need to refer to Appendix B on the notations used in the book as you read Part IV. Part V, Applying Use Cases and Aspects in a Project

You might be at the beginning, middle, or final stages of your project: No matter what stage you are at, you can apply the practices advocated in this book. In Part V, we demonstrate how to tailor our approach to different project scenarios. We also show you how to effectively manage a project that is based on use cases and aspects. How This Book Came About

Research papers often have many authors, and you may wonder what each author contributed to the work. Here, we reminisce about how this book came about and explain our individual contributions to the concepts and pragmatics described in this book. In the Beginning
By Ivar

The first time I heard the term aspect-oriented programming was back in 1997. I immediately saw it as an interesting technology, but at the time, I couldn’t take a serious look at. I was working on the first version of UML, and on getting Rational Unified Process (RUP) right, and I was initiating an effort on active software processes—actually what is now Jaczone Way-Pointer. When I finally had time to take a good look at aspects, it was in September 2002. I downloaded a lot of papers and studied them for a couple of days. Then I contacted Harold Ossher at IBM Research and Karl Lieberherr at Northeastern University in Boston. They are two of the leaders in this space. The most well-known person on aspects is Gregor Kizcales. I tried to get his attention as well, but he was too busy at that time. However, he contributed to this book by reviewing it extensively, and we benefited significantly from his comments.

In November 2002, I visited the IBM folks and spent a day with them learning about their work. After the meeting, I was very impressed and excited about what they had done. I left their office and rushed to Newark airport; I had to run to the gate. This is normal. I was on my way to Stockholm. When I was seated in the plane, I ordered some champagne and began to relax and think a little. Suddenly, it struck me. Didn’t I do something similar before? Didn’t I write a paper on the same subject for OOPSLA ’86—the very first OOPSLA conference?

When I got to Stockholm, I hunted for the paper. It was a paper that discussed a topic that I mentioned as future work in my Ph.D. thesis from 1985. However, the ideas in the paper had generated no interest, so I decided to leave the subject. I felt it was too early to push those ideas and just forgot about them. Besides, my work on component-based development with objects and use cases was so successful that there was no room for new inventions. However, now I wanted to find the paper. I went to the publisher’s Web site and found it. I had to pay $95 to download it! My own paper!

The title of the paper is “Language Support for Changeable Large Real-Time Systems” Jacobson 1986. In that paper, I introduced several concepts— existion, which represents a base, and extension, which represents separate functionality that you want to add to the existion. Instead of modifying the existion to invoke an extension, we used a mechanism to allow the extension to add behavior into the existion. Thus, from the perspective of the existion, no modification was needed. This meant that you could add extension after extension without breaking the existion. The key idea is this: By keeping extensions separate from the base from the developer’s perspective, the system is much easier to understand, maintain, and extend.

The basic idea sounded very much like what aspect-orientation research is trying to achieve. But I needed confirmation. Two hours after I downloaded the paper, I sent it to Karl Lieberherr. He responded, “Wow, Ivar, this is an early paper on aspect-orientation.” He asked me if I had anything more. Since I throw away everything I don’t work with, my first thought was that there was nothing more. However, I was excited, and my thoughts went back to the time before the paper. My memory asked me, “Didn’t you file a patent for a similar work?”

The patent was filed in 1981, and I filed it as an employee of Ericsson. I called the Ericsson patent department and asked if they had saved the application. After a week, they produced a copy of the application—in Swedish. The application used typical patent language, so I had actually never understood it. It was written by a patent engineer. However, attached to the application was an internal Ericsson paper that described the whole idea in a couple of pages. It was quite a detailed paper with a practical example. This paper was also in Swedish. I had both documents translated into English by a professional translator, and you can find them on www.ivarjacobson.com (look for published papers and aspect-oriented software development).

The patent was about what we called a sequence variator. It works at the microprogram instruction level. The highlight of the design is this: A program has a list of instructions. To each instruction, I added a flag. If this flag is turned on, it means that there is an extension that needs to be executed at this point. The sequence variator fetches instructions from the extension and, thereafter, resumes at the next instruction. This branching is taken care of by the sequence variator. The developer of the original instructions does not need to code branch statements.

To make a long story short, Karl Lieberherr and Harold Ossher liked my early work. Karl wrote an email that compared my early work with modern aspect-orientation: extension aspect, extension point join point, and so on. I then wrote a couple of papers on aspects and use cases (see www.jaczone.com/papers) and as a result, I was invited to speak at an international conference on aspect orientation. I was very happy to be recognized for my early work. It spurred me to start a book on the technique, and I needed someone to work with me to make the approach practical.

I am often asked which is my favorite country. In addition to Sweden, where I grew up and have family, I have many favorites. Most countries have something that makes me feel happy and at home. Singapore is certainly one of them. In Singapore is Pan-Wei Ng. Pan-Wei was quite familiar with use-case-driven development, model-driven development, and similar methodologies. He had been helping me to review recent papers I’d written about use-case aspects, so I asked him to join me to write the book.

Pan-Wei immediately agreed, and we started work. That was sometime in December 2002. It took us almost two years to write this book. I leave it to Pan-Wei to tell you what happened thereafter and how we wrote the book together. Working Together
By Pan-Wei

Writing the book has not been easy. This was originally intended to be a 150-page book, but it has grown much. Ivar’s papers on use cases and aspects essentially set the framework for whole book, but they were not enough, and we needed to map Ivar’s concepts (specifically use-case slices) into implementation and a set of guidelines for practitioners. This was my contribution to the book. Of course, Ivar had earlier works on use-case-driven development and related topics, and I had quite a lot of resources to draw from.

During the writing, Ivar made hundreds of comments, some of which changed the direction of the book dramatically. While I did most of the writing, Ivar supervised and had many strong opinions about the foundational concepts that shaped the book: Modeling crosscutting concerns with use cases—peer and extension use cases Use-case slices and use-case modularity Model-driven development use case by use case Use-case-driven development (as per OOSE and USDP)

We discussed many issues together, and my contributions include the following: Mapping use-case slices to AOP—structural and behavioral context of operation extensions Platform specifics as extensions to platform-independent elements and infrastructure as extensions to the application

My main contribution lies in making Ivar’s ideas concrete through examples and discussing pros and cons of different approaches in the book. In doing so, I had to pull together existing practices in design patterns, J2EE patterns, layering, mock objects, and so on. Although these practices are mostly well described individually, finding a more adequate formulation to put them together was a challenge. This is why writing this book took longer than expected.

Many of these contributions would not have been possible without the foundations set by Ivar. But regardless of whether the contributions were made by Ivar or by me, we discussed and debated them heavily, often seeking the advice of others.

It was indeed lots of fun working on the book. It resulted in our becoming really good friends, and we plan to continue working together. This project inspired Ivar to form a company in Singapore and another in Korea. Life is exciting, and there is never a dull moment.

0321268881P12162004

FROM THE PUBLISHER

Aspect-oriented programming (AOP) is a revolutionary new way to think about software engineering. AOP was introduced to address crosscutting concerns such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling in a more effective manner. Unlike conventional development techniques, which scatter the implementation of each concern into multiple classes, aspect-oriented programming localizes them.

Aspect-oriented software development (AOSD) uses this approach to create a better modularity for functional and nonfunctional requirements, platform specifics, and more, allowing you to build more understandable systems that are easier to configure and extend to meet the evolving needs of stakeholders.

In this highly anticipated new book, Ivar Jacobson and Pan-Wei Ng demonstrate how to apply use cases-a mature and systematic approach to focusing on stakeholder concerns-and aspect-orientation in building robust and extensible systems. Throughout the book, the authors employ a single, real-world example of a hotel management information system to make the described theories and practices concrete and understandable.

The authors show how to identify, design, implement, test, and refactor use-case modules, as well as extend them. They also demonstrate how to design use-case modules with the Unified Modeling Language (UML)-emphasizing enhancements made in UML 2.0-and how to achieve use-case modularity using aspect technologies, notably AspectJ.