- Software Development and the Object-Oriented Paradigm
- The Case for Aspects
- What Is an Aspect?
- Why Consider Aspects in Analysis and Design?
- Aspects and Other Concerns
- The Theme Approach
- Applying the Theme Approach
- Theme: Symmetric or Asymmetric?
- Fitting Theme into Your Existing Development Process
- What About Implementation?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Why Consider Aspects in Analysis and Design?
As with systems in any programming paradigm, aspect-oriented systems need to be designed with good software engineering practices in mind. The analysis and design of a system are at least as important as the implementation itself, and many professionals consider these phases to be more significant in their contribution to the success of a project as a whole.
In any development effort, it is helpful for a developer to be able to consider the structure of the final implementation at all stages of the software lifecycle. Otherwise, the developer would have to make a mental leap to get from a particular way of encoding design to another way of coding the software. In other words, developers must be able to easily map their designs to the code in order for the design to continue to make sense during the development lifecycle.
In addition to seamless traceability between the design and code, we also consider the benefits of separating aspects in the design for the design’s own sake. The same benefits derived at the code level through applying aspect orientation can be derived at the design level. In the infancy of aspect orientation, developers simply used object-oriented methods and languages (such as standard UML) for designing their aspects. This proved difficult, as standard UML was not designed to provide constructs to describe aspects: Trying to design aspects using object-oriented modeling techniques proved as problematic as trying to implement aspects using objects. Without the design constructs to separate crosscutting functionality, similar difficulties in modularizing the designs occur, with similar maintenance and evolution headaches. We need special support for designing aspects, as we can then improve the design process and provide better traceability to aspect-oriented code.
A similar set of problems arises when analyzing requirements documentation to determine how to design a system. Approaches for decomposing requirements from an object-oriented perspective simply don’t go far enough when trying to plan for aspect orientation. Heuristics and tools to support such an examination are helpful to the developer.