The first part of this book focused on programming language issues in software development. However, most developers know that programming is only a small fraction of the work required to produce and maintain a high-quality software system. Indeed, some experts have suggested that actual programming can be as little as 5% of total system effort. Engineering high-quality software is a difficult and uncertain undertaking, as is evidenced by the current variety of processes, methods, and tools. Processes are required (and exist to varying degrees of usefulness) to handle a myriad of complex tasks, including gathering requirements from the clients of the software, analyzing the requirements and designing and producing the software, testing the system and feeding test results back to the development team, ensuring that the new system integrates with existing business processes, deploying the system to the end users, ensuring the system stays up and running for as long as it is needed, and evolving the system as the needs of the users change. To complicate matters, these activities are not necessarily sequential. Adding to the complexity, the requirements may change at any time during the development cycle. Software engineering needs flexible development methods, technologies, and tools if there is to be any hope of a development team producing, in a timely manner, a high-quality and useful software system. Some of the key notions of software engineering are described in the sidebar.
Key Software Engineering Terminology Software engineering. The processes, methods, and tools that support a software development team in building a high-quality and useful software system. Software process. A series of actions that should be taken in developing a software system, such as gathering the requirements, analyzing the requirements, specifying the system, designing the system, and so forth. Most software processes break down these high-level actions to successively smaller action granularities. Software method. The way to achieve each action in a software process. A software method describes how to produce the required output for each step in the process, with advice on appropriate notation for representing the elements of the output. For example, in the software design step of the software process, a UML class diagram is generally part of the required output. Object-oriented methods that describe how to produce a class diagram include descriptions on identifying objects of interest, grouping them based on type, identifying relationships between objects, and so on. Software model. A representation of the software at varying levels of abstraction, depending on the step in the development process. For example, a UML class diagram is a model of the structure of the system. |
We tend to measure system quality in terms of various properties. Often, generically termed "ilities," these properties include correctness, efficiency, maintainability, portability, reliability, predictability, interoperability, fault tolerance, recoverability, learnability, analyzability, adaptability, reusability, robustness, testability, verifiability, comprehensibility, consistency, traceability, evolvability, measurability, and modularity. High quality is clearly a tall order.
None of this is news. Currently, for each point in the development cycle, many methods purport to help control complexity, often accompanied by tools to help realize the method. Where does aspect-oriented software development fit in? The early focus on software engineering as programming has broadened, as the field has matured, to an understanding of the importance of the entire software lifecycle. Much of the work described in this section is characterized by the recognition that the benefits of an aspect-oriented approach to modularization can be realized at earlier stages in the development cycle than programming. Further work attempts to achieve another ility:traceability of aspects from the requirements to the implementation. Classic software engineering lauds modularization and traceability as important properties for easing comprehensibility and maintainability of systems. Adding aspects to the development mix does not change the need for these fundamental propertiesindeed, aspects emerged as a technology motivated to improve them. It is a further measure of the maturing of the field that we are also seeing a number of evaluations and experience reports of usage of AOSD in software development in this section.
Broadly speaking, all these tasks and qualities are within the realm of software engineering. Aspects extend conventional programming technology; they likewise need to extend software engineering technology. Some of the papers in this part provide insight into processes and methods for aspects at stages of the lifecycle other than programming. Some describe interesting experiences with using aspects in real projects, while still others explore the integration of aspects with existing software engineering methods, such as component-based development. Our selection is not comprehensive; a single book is too small to include all the interesting work on this topic. We hope that the set of papers here informs the reader as to the kind of work that is ongoing in aspect-oriented software engineering and provides a guide towards further investigation of the field.
THE CHAPTERS
Our first chapter, Chapter 17, "Engineering Aspect-Oriented Systems," by Gordon S. Blair, Lynne Blair, Awais Rashid, Ana Moreira, João Araújo, and Ruzanna Chitchyan, presents a study of existing approaches to aspect-oriented software engineering. The chapter begins by examining methods for including aspects in requirements engineering. Later sections examine approaches such as consideration for aspects at the specification, design, and implementation phases and discuss how approaches support evolution and aspect interaction. Each section has its own criteria for comparing approaches. For example, requirements engineering is examined with respect to issues such as support for aspectual concepts and the ability to map to artifacts later in the lifecycle; specification approaches are considered with respect to their capability for specification verification, their degree of tool support, and their extent of language independence. Many of the design comparison criteria are based on quality properties such as assessing the traceability, reusability, and comprehensibility of the designs that result from using the approaches. A theme running throughout the chapter is that of providing guidelines for the selection of a particular approach (or set of approaches) for actual use. This chapter provides an excellent starting point for those readers investigating how they can go about realizing the benefits of aspects earlier in software development than coding.
Chapter 18, "Aspect-Orientation in the Software Lifecycle: Fact and Fiction," by Pedro Clemente, Juan Hernández, José Luis Herrero, Juan Manuel Murillo, and Fernando Sánchez, illustrates the effect of introducing aspects late in the development process. The difficulties encountered by applying aspects only to the implementation and not to the design ranged from errors injected by programmers making localized changes without consideration of the design as a whole to maintenance problems that arise because the design documents no longer reflect the code. The authors describe attempting to ameliorate these difficulties by capturing aspects earlier in the lifecycle, using two different approaches. This paper reinforces the view that it is important to be able to trace elements of the implementation back to the design.
In the early 1990s, there was no single, standard approach to designing object systems; rather, there was considerable discussion of the underlying nature of object-orientation. As might be expected from the maturity of AOSD, the current AO situation is similar. Notwithstanding the lack of consensus about most things, there is nonetheless one opinion shared by all researchers on aspect-oriented designall approaches are based, at least to some extent, on the current standard for object-oriented design, the Unified Modeling Language (UML). UML, as applied to object-oriented software engineering, is well known and well understood. Extending UML to aspect-oriented design requires three additional high-level capabilities of UML. First, we want to modularize crosscutting concerns into separate design models. Aspect-oriented software development is all about modularizing concerns; a design language must support that. Second, we want a means to describe how separate design models should be integrated (composed). Separated concerns need to be integrated into a working system, and designers need to be able to say how that should happen. For example, a designer may want to express the idea that a specific crosscutting behavior should be executed when a certain condition occurs. Finally, we want a design approach that includes the semantics for actually composing (or "weaving," in AOP terms) the designs based on what the designer has previously specified. Composing design models provides a means for the designer to verify the decomposition into separate models and to validate the specification of how the design models should be composed.
Standard UML was not designed with aspects in mind, and so broadly speaking, current aspect-oriented design approaches fall into two categories: extend UML constructs and semantics to deal with aspects, or use standard UML in new ways.
The next two chapters explore these two ideas. Chapter 19, "Generic Aspect-Oriented Design with Theme/UML," by Siobhán Clarke and Robert Walker, is rooted in the notion of multi-dimensional separation of concerns, (as described in Chapter 3, "N Degrees of Separation: Multi-Dimensional Separation of Concerns Degrees of Separation: Multi-Dimensional Separation of Concerns"). Different kinds of concerns, including aspects, are modeled separately and composed at a later stage. For the most part, standard UML is used to model each individual concern. Theme/UML extends UML templates to allow designers of an aspect to reason about join points without referring to them by name. The main extension to the UML is a new kind of relationship, the composition relationship, which allows a designer to specify both how the design models relate to each other and how they should be composed.
Theme/UML extends standard UML. This has the advantage of providing linguistic structures close to the user's conceptual notions of aspects, but the disadvantage of requiring extending standard UML tools. Chapter 20, "Expressing Aspects Using UML Behavioral and Structural Diagrams," by Tzilla Elrad, Omar Aldawud, and Atef Bader, describes an approach that stays within standard UML, relying on advanced features of UML statecharts to express aspects. Concurrent statecharts describe different behaviors, some of which may crosscut. This chapter shows how to use standard (though advanced) features of statecharts, including event broadcasting, to achieve implicit weaving. This has the benefit of allowing the use of standard UML tools but adds the additional complexity of using UML constructs in novel ways.
Other aspect design approaches avoid adding constructs to the UML by using stereotypes of existing UML constructs that map the AspectJ model. Many of these approaches are strongly tied to varying versions of AspectJ and depend on it for their semantics. These also have the advantage of allowing designers to use existing case tools, and they are familiar to existing AspectJ programmers. References to design approaches that take this perspective can be found at [2]. Ultimately, we need to gain experience with the different approaches to aspect-oriented design. It is important that this experience is assessed in conjunction with studies on different aspect-oriented programming models (and indeed, aspect models across the whole development lifecycle) to gain insight into traceability and other ilities. Standardization would be useful, but considerable work is needed to agree upon the basic aspect model before standardization is appropriate.
Chapter 21, "Concern Modeling for Aspect-Oriented Software Development," by Stanley Sutton, Jr. and Isabelle Rouvellou, discusses the necessity of having a model of the concerns of a system that is independent of development artifacts and the software lifecycle. Such a model needs links into all development artifacts, allowing the analysis of these artifacts for properties such as traceability, impact of change, and applicability for reuse. From a software engineering perspective, such a model is an important addition to a developer's toolset; this kind of analysis is critical for understanding the system as a whole and for managing its evolution. This sounds great in theory, but does such a model exist? The model described in the chapter, Cosmos, represents a good basis from which to evaluate and evolve concern schema. Cosmos speaks to the core of a fundamental difficulty we have in our field: What is a concern? How do we characterize it? How do we recognize it when we come across it? Focusing on schemas like Cosmos helps the AOSD community gain a common understanding of exactly what a "concern" isan important goal towards converging on standards for supporting technologies.
The theme of concern modeling is echoed at the programming level in Chapter 22, "Design Recommendations for Concern Elaboration Tools," by Gail Murphy, William G. Griswold, Martin P. Robillard, Jan Hannemann, and Wesley Leong. Here, the focus is on elaborating concrete concerns in codeonce a programmer has identified a concern of interest, a tool should help find all code that relates to that concern. The benefits of such a tool are clearwhen all the code for a concern can be clearly identified, modifying it becomes less problematic and the impact of modifications more readily identifiable. This chapter describes a study of three existing concern elaboration tools and presents a set of challenges and recommendations for the kinds of issues a concern elaboration tool should handle.
This part includes some experimental studies relating to the efficacy of aspect-oriented programming. Chapter 23, "An Initial Assessment of Aspect-Oriented Programming," by Robert J. Walker, Elisa L. A. Baniassad, and Gail C. Murphy, reports on two experiments that assessed how easy aspect programs are to debug and modify. Though the work was based on an early version of AspectJ, it nonetheless highlights some interesting points that remain relevant. The scope and extent to which aspects impact the base code is fundamental to understanding the program as a whole. Programmers need a language that provides a narrow, well-defined interface between the aspects and the base, with constructs that provide appropriate levels of encapsulation for crosscutting code. From a software engineering perspective, this oft-cited work has been highly influential in many ways. Languages like AspectJ have evolved that provide considerable improvement in these areas. In addition, this work serves as an example as to the kinds of studies that can be performed, with many researchers building from or analyzing the methods and the results.
Chapter 24, "Aspect-Oriented Dependency Management," by Martin Nordberg III, analyzes aspect-oriented programs to assess the level of dependencies between modules that are introduced by aspects. Given some of the hand-waving claims relating to the modularization capabilities of aspect-oriented programming, it is always refreshing (indeed, essential for software engineering) to view these claims from different perspectives. In general, when examined from the perspective of levels of coupling, aspect-oriented programming appears to perform well in reducing coupling between modules, but, interestingly, this is not true in every case. Based on studies of different patterns of software, the chapter provides guidelines for when to use standard object-orientation, aspect-orientation, or a combination of both. In the rush of (justified) enthusiasm for the aspect-oriented paradigm, we recognize a danger of treating it as the ideal hammer for every nail (and screw). More studies such as those described in this chapter will help us refine the technology to achieve the greatest benefit.
Chapter 25, "Developing Software Components with Aspects: Some Issues and Experiences," by John Grundy and John Hosking, presents further experience of combining the use of aspects with existing established approachesin this case, with the current "sharpest tool in the programmer's toolbox" [Chapter 24], component-based programming. An acknowledged difficulty with component-based software engineering relates to specifying how components that have been designed without specific knowledge of each other should nevertheless work together, especially when knowledge of the internal details of components is required. This chapter combines components with aspects, using aspects to encapsulate crosscutting behaviors, thereby removing from a component any intimate knowledge of other components. Results appear encouraging, though potential disadvantages are readily acknowledged. Nonetheless, this trend towards experimenting with combinations of existing paradigms is to be encouraged, as much can be learned from the advantages and disadvantages of any approach, and much can be gained by combining the best of all.
Chapter 26, "Smartweaver: A Knowledge-Driven Approach for Aspect Composition," by J. Andrés Díaz Pace, Marcelo Campo, and Frederico Trilnik, takes a small step towards combining the aspect paradigm with knowledge-based engineering. Here, a tool provides guidance to a programmer relating to the tasks that need to be completed and templates to be filled in to achieve some of those tasks. The authors have ambitious goals for their tool; we look forward to monitoring their progress. Further exploration of how agents can support the aspect-oriented software engineering process is to be welcomed.
Having introduced the full set of papers in this part of the book, it is time to consider the coverage of current AOSD research against software engineering in the large. At the start of this introduction, we characterized the range of the software engineering field. Clearly, aspects do not currently permeate it all. (This is not to say that it is necessary or even appropriate that they do so.) Nevertheless, it is worthwhile to determine which areas are not addressed by aspects and to assess whether any perceived gap is one that should be filled. Take, for example, ensuring that a new system integrates with existing business processa task we included as a necessary one to achieve a successful deployment of software within an organization, and therefore within the remit of software engineering. Intuitively, we might suggest that this is partly a management task and partly a business process-engineering task, and therefore aspects would not help. On the other hand, it might be considered partially an analysis task that might impact the design of a system, and therefore aspects are appropriate. Another example of a software engineering area not addressed in this part is testing. Encouragingly, work is emerging in examining different approaches to unit-testing aspect programs [1]. In general, we envision that further aspect activity will emerge across the broad scope of software engineering (including both development activities and quality "ilities").
Notwithstanding current limitations and potential gaps, we are excited by the range and momentum of current aspect-oriented software engineering research, especially when we consider the age of the field. Clearly, more needs to be done. The object-oriented paradigm seems a good role model for many reasons, not least because of its success. We suspect one reason for the pervasiveness of objects in current software development practice is a common, standard understanding of the relevant constructs. Such a common understanding currently eludes the aspect community, but is likely to develop over time. As aspect-oriented software development becomes mainstream, the range of supporting tools available to software engineers will grow, complementing and supporting each other across the lifecycle. Core principles will be absolute, making a move from one aspect-oriented language to another (regardless of the stage of the development lifecycle each language supports) as straightforward as moving, for example, from C++ to Java, or from UML to C++particulars of the language need to be learned, but not the fundamental, core principles. We look forward to watching the aspect-oriented paradigm improve software engineering.
REFERENCES
1. Afanti Project. http://www.fit.ac.jp/~zhao/afanti.html.
2. Aspect-oriented Modeling 2002. Workshop on Aspect-Oriented Modeling with UML (AOSD). Enschede, The Netherlands. http://lglwww.epfl.ch/workshops/aosd-uml/index.html.
