In the preceding parts of this book, we demonstrated how you can systematically capture and model concerns with use cases and, with aspect orientation techniques, preserve the separation of use cases all the way to code and test. How far you apply our approach in a project depends on a number of factors. Every project is different, and you must tailor your approach. Frequently, you will apply aspect orientation in conjunction with several other techniques. The key idea is to find the right balance and steer the project to success. In this chapter, we enumerate different project scenarios and prescribe a roadmap for you to find that balance for these scenarios.
In the preceding parts of this book, we went into great detail on the theoretical basis for aspects. We provided a systematic approach for applying use cases and aspects to achieve better separation of concerns. We demonstrated how to apply the approach from requirements to code and how to establish a resilient architecture based on the approach.
It is time for you to apply the approach to your project. We recognize that every project is different—different complexity, different technologies, different levels of formality, and so on. Every project team is different as well, with various backgrounds and skill sets. You definitely need to tailor the approach to suit the specific needs of your project.
In this chapter, we discuss how you can adopt aspect orientation, specifically, the approach described in this book. This chapter is not about adopting a new approach in an organization. Adopting a new technology in an organization means organizational change, and it involves getting a champion, identifying pilot projects, and more—that is an entirely separate topic.
Rather, the premise is this: given that you want to apply use cases and aspects on an already chosen project, what should you do in that project? Which areas of our approach should you apply? How do you balance your existing approach with the new approach?
The remainder of this chapter is a guide to adopting the approach to a project discussed in this book. In particular, we look at the following considerations:
Selecting the areas (or disciplines) within the methodology you want to adopt—requirements, design, implementation, testing, and so on.
Balancing current and proposed approaches for software development at different phases of a project.
For each consideration, we discuss some of the adoption challenges you are likely to face and show you how to resolve them.
In the earlier parts of this book, we described how you capture and model concerns with use cases. We demonstrated how you specify use cases and analyze them, and how you can keep the realization of use cases separate during analysis as distinct use-case slices. These use-case slices are then designed, implemented, and tested with the available aspect technologies. Do you want to apply our approach during requirements and analysis? Do you want to apply it during design and implementation? During testing? How far you apply our approach depends on the aspect technologies available on your target platform.
It is important that you capture stakeholder concerns correctly and accurately. The use-case specification technique attempts to do just that. Use cases capture stakeholder concerns, and the final deliverable is in the form of working use cases. Use-case analysis is part of the requirements and should be applied together with use-case modeling to better understand the requirements for the system. It is through this understanding that you shape and structure the system and keep the different concerns about the system separate.
You can most definitely apply use-case modeling and analysis to any project, since they are applicable to any software development in general—aspect-oriented, object-oriented, or otherwise. They are not limited to a specific aspect technology like AOP or AspectJ. Nevertheless, how far and how detailed you want to apply use-case modeling and analysis depends on the technology available in your development and target environment. If, for instance, you do not have any AOP technology available, you can still identify use-case slices, but you would probably not describe pointcuts in detail during use-case modeling and analysis. If AOP is available, you will probably specify pointcuts in greater detail.
We encourage you to write use cases for infrastructure services and explore the different scenarios in which they are applied. Frequently, only the basic flows of infrastructure services are described. When actual design and implementation occurs, there are many open and unresolved issues simply because they have not been sufficiently analyzed. Again, how far you want to go in writing use cases for the infrastructure services depends on the project. If you need to develop the infrastructure service, then you want to specify it in detail. If it is already existing, perhaps reused from a previous project, and your project team is familiar with it, you will need less detail. In this case, identifying the key scenarios the infrastructure services need to handle is quite sufficient.
While use-cases modeling and analysis are simple concepts, their application requires some practice. Writing use cases at an appropriate level of detail that meet your project’s needs take some experience. Writing effective use cases that are easily understood by customers and by the development team also takes some experience. Fortunately, the use-case technique has gained widespread acceptance, and most practitioners have some understanding of use cases.
The introduction of use-case slices and the use-case structure represent the key differences between our approach and those applying just object orientation. The use-case slice concept is probably new to members of your project team. AOP and AspectJ (if your project team is using it) also are probably new to the project team. This represents a barrier for your team members. Your team must learn how to model aspects and use-case slices, and how to specify pointcuts. They also have to learn how this maps to an aspect technology such as AOP. A large part of this book is about doing just that.
To overcome the barrier, choose a particular concern that you want to solve through our approach. Express the concern as a use-case, and drive it all the way to code and test. You should not emphasize too much analysis and design at this point. Just dive in and quickly get out a working executable, much like a prototype solution. By developing this little prototype, you gain the experience of applying our approach and how use cases lead to use-case slices and how they are implemented in code. With a better understanding, you can proceed to apply the approach on the architecturally significant use cases.
A team attempting to implement infrastructure services is faced with two options: use either an aspect technology or an architecture framework such as J2EE. For example, most architecture frameworks have some support for security. Frequently, a combination is used, as implementation aspects provide the glue from the application layer to invoke such services. Early in the project, as you develop the architecture, you establish guidelines to achieve that balance. In Part IV, we provided several examples.
What if you do not apply use cases to capture stakeholder concerns? Would our approach work for design and implementation? The answer is a resounding yes. If you capture concerns as features, then you have feature-specific slices and non-feature-specific slices in place of use-case slices and non-use-case-specific slices. The approach during design and implementation would be similar. But still, we recommend that you do use cases, since they capture stakeholder concerns, and they capture what the system is supposed to do for each user in a manner that facilitates the identification of test cases.
If you are a risk-adverse person, then testing represents the most profitable area for you to apply our approach. Testing often requires the introduction of control and instrumentation code. With use-case slices, you can, in a blink, remove all such code from the final delivered system. Thus, it is a small wonder that the logging example is one of the most frequently used examples to introduce aspect orientation. You want to remove such instrumentation code in the final system and, hence, aspect orientation is a welcome solution to many project teams. In addition, our approach through use-cases helps you to systematically identify and organize test cases.
You might not have the luxury of adopting aspect orientation on a completely new project. Your project might be an enhancement to an existing system. In general, when you adopt aspect orientation, you might be in any of the project phases enumerated in Figure 20-1.
Planning Stage. If you are developing a new system, you have a clean slate. You can easily apply the entire approach in this book—from requirements to code as well as in the development of the architecture and the rest of the system.
Early Elaboration. If you have already completed some initial iterations, you likely have a number of use cases working and several infrastructure services in place. You can definitely apply use-case slices on those areas that you have yet to develop. For those infrastructure services that you have already developed, consider whether it is worthwhile to redesign them as use-case slices.
Late Elaboration. If you have a firm architecture in place, you are unlikely to make any revisions or changes unless there are significant productivity gains. Consider the possibility of using code templates and pointcut parameterization to help you incorporate infrastructure services and platform specifics into the system. AspectJ, as a programming technique, also provides the means for you to determine whether dependencies between layers and packages are violated.
Construction. If you are nearing the completion of your project, you are unlikely to make significant changes. But during this time, there is heavy emphasis on testing, tracing, and debugging. You can apply our methods to testing—identifying test cases from use cases, designing and implementing test slices, and so on.
Enhancements. If you have already delivered the system, your users might have some enhancement requests, or you might want to customize the system for another group of users, possibly at a different site. Such revisions can be mapped into either new use cases or extension use cases. Implementing them using aspect technology makes such revisions composable, and you can easily select the ones needed for a particular end-user group.
Every project has its own individual characteristics. No two projects are the same. Although the same general principles of sound software engineering apply, they need to be tailored to the specific needs of a project. Our approach, to keep concerns separate as use cases and maintain that separation all the way to code and test, is not exempt. When you attempt to apply our approach to your project, you need to do some tailoring. But how can you tailor the approach when the team is unfamiliar with it?
This chapter enumerated various project scenarios and prescribed some tailoring considerations. Nevertheless, the rest is up to you. It is useful to choose a specific concern in your project and solve it with use-case slices and aspects. Produce a prototype solution and from it gain some experience. Thereafter, you can tackle larger problems.