Keeping concerns separate not only makes the system more understandable and extensible, it also gives rise to significant savings in terms of development effort. Aspect orientation—a powerful technique indeed—can help you achieve this. Nevertheless, aspects and even use cases are not silver bullets. They are but just two best practices in software development. In addition to use cases and aspects, you must build the system from the basis of a solid architecture, and you must progress iteratively, tailoring the approach to meet your project’s needs. Once you master and balance these best practices, you can ensure success in your project.
As you know, successful software development is about being able to build and evolve a system incrementally to meet the evolving needs of the stakeholders. You give the development team some new or changed requirements, and the development team produces the changed system, as depicted in Figure 21-1.
Thus, software development is about changing from “something” to “something else.” Even the first development step is a change from “nothing” to “something.” In each development step, you add a new extension to the existing system to address some stakeholder concern, and as far as possible, you want to have minimal impact on that which already exists and already works. Thus, new extensions must be clearly separated from preceding extensions. This is achieved through use-case slices. Here, extension refers to a new concern or capability that you will add to the system at each point in time. Thus, you can have extensions comprising application use-case slices, application-extension use-case slices, infrastructure use-case slices, platform-specific use-case slices, and so on. Extensions occur during the whole life cycle of the system—over all releases, iterations, and builds. Organizing the system development as successive extensions makes the system easier to understand, grow, shrink, and maintain; the cost, quality, and time measures dramatically improve.
Obviously, we view aspect orientation as an extremely important contribution to the software world. Being able to separate use cases or extensions of various kinds and keep them separate all the way down, and later being able to compose them, gives us a tremendous boost in all measures: costs, quality, and time.
Keep in mind, though, that software development is much more than aspects and use-case-driven approaches. Several key practices discussed in this book can help you become successful in software development:
Every software development approach must start with capturing stakeholder concerns and must provide guidelines for analyzing, designing, implementing, and testing the system with respect to those concerns. Use-case-driven development precisely deals with stakeholder concerns. By walking through usages of the system, you have a better understanding of stakeholder concerns and their acceptance criteria. In Part II, we discussed how to model concerns with use cases. In Part III, we showed how to drive the development of each use case with use-case slices and use-case modules.
Every software system must be built on top of a sound and resilient architecture. A resilient architecture keeps concerns of various kinds separate, which localizes changes and prevents changes from propagating to other parts of the system. In Part IV, we explained how to keep variations from the core, nonfunctional requirements from functional requirements, platform-specific from the platform-independent elements, and tests from the subject being tested. We also showed you how to establish such an architecture with an accompanying architecture description.
Every project and team has its own specific characteristics. In Part V, we recommended ways to tailor our approach to apply to different project conditions.
Every system has to be built iteratively, and in each iteration, you introduce some useful capability into the system. In Part V, we have described how to estimate, plan, and track iterative development projects and explained the productivity gains you can achieve by keeping concerns separate.
Once you have started to adopt aspect orientation, you will find even greater advantages in using it. In this book, we dealt largely with the more technical aspects of software development, but there are other dimensions, each with its own set of best practices.
The technical dimension has best practices for modeling, programming, reuse, architecture, platforms, and so on.
The project management dimension has best practices for planning, tracking, project metrics, configuration management, contract specifications, and so on.
The human dimension has best practices on requirements elicitation, brainstorming, reviews, and so on.
The organization dimension has best practices for organization structures (project versus product organization structures), outsourcing, process improvement, and so on.
A major project management woe is how to adapt and compose all these different best practices to formulate an effective project plan. Moreover, the emphasis on each dimension changes as a project evolves. A best practice may be extremely important in the beginning of a project but less so later on. Another may be more important at the end of a project. An effective project manager is one who can successfully balance these best practices.
The concepts of aspect orientation and extensibility provide the foundation for experts to define best practices separately, in a composable manner. We foresee a “best-practice weaver” who will compose project-relevant parts of the best practices together, eliminating static process descriptions that must be deciphered by the project teams. We also foresee automation to guide project managers in composing best practices to form a detailed plan for his or her team. Such possibilities represent a significant change to software development, but that is the subject of another book. For now, it is time to apply aspects in your project.