Browse Books

Reviewer: Chenglie Hu

As a software development paradigm not yet commonly supported by programming languages, aspect orientation (AO) is still relatively new to software developers and has not been widely incorporated into an educational curriculum of any computing discipline. Yet, this book has already brought the practice to the next level: it describes how large software systems can, and should, be designed using the AO paradigm. An essential difficulty of an object-oriented (OO) paradigm is that software requirements do not align with the objects produced in the analysis and design. In other words, requirement units are not usually the same as those units in an OO model. This nonalignment may cause the units that encapsulate the requirements to be abandoned in favor of a modularization demanded by the OO design and coding paradigms. This results in a scattering (one single requirement is scattered across multiple classes or operations) and tangling (a single class or operation contains design details of multiple requirements) effect across an OO design. The consequences are that accommodating new requirements late in the development cycle may affect an unpredictable number of objects, and it could even become an impediment to comprehensibility, reuse, and traceability. For example, in a system for which logging is a requirement for all banking activities, many classes may end up having an aggregated object. If printing is another capability required of all banking activities late in the development, accommodating it does have some, if not all, of the problems mentioned earlier. There are, indeed, ways of coping with common concerns or behaviors under a pure OO paradigm. For example, one can use inheritance to address common concerns or behaviors by subtyping the classes to accommodate the additions so that the existing class structures are affected as little as possible. This vertical expansion of types may, however, quickly become difficult to manage, as newly introduced types often affect the existing configuration of type compatibility. In fact, such an approach is only beneficial if polymorphism is a main concern. Another way of dealing with common concerns or behaviors is to use design patterns, which allow changes to be made in an additive manner rather than an invasive one, improving the modularity of the overall design. Yet, design patterns can only address the difficulties mentioned above partially within the same OO paradigm. By contrast, aspect orientation addresses common concerns or behaviors by crosscutting the core system with aspects (modeled separately), and weaving the aspects at joint-points, thus providing a horizontal expansion of the system, which in many cases (for instance, the banking example above) is more advantageous. An aspect is a concern. A theme is an encapsulation of a concern. Yet, a theme may not necessarily be an aspect. As confusing as this may sound, this subtle distinction is, in fact, where the power of the theme approach lies. Themes are related in two ways: by either sharing concepts or by crosscutting (triggering a concern whose structure and behavior may be scattered across the code-base and tangled with code related to other concerns). The theme approach involves three stages: analysis, design, and composition. In the analysis stage, requirements are analyzed to extract themes (subsets of the requirements) using theme/doc notational diagrams, which allow a view of the relationships among the themes, leading to identification of the core/base system and the aspects. The main characteristic of the stage (and the power of the analysis) is that each theme is independently identified, irrespective of its possible structure. Then, in the design stage, themes are independently designed using the so-called theme/unified modeling language (UML) notational diagrams (a simple extension of the standard UML that allows cooperating class diagrams into a theme). In the last stage, sharing-concept themes are composed structurally, and so are crosscutting themes. Since the whole process works iteratively, adding more concerns requires just additional iterations. The book is organized as follows. Chapter 2 stresses the weaknesses of the OO approach (outlined above). Chapter 3 outlines the entire development process of the aspect-oriented theme approach and its adaptability to commonly used life cycle models. Three chapters (chapters 4, 5, and 6) are devoted to the three stages of AO, addressing criteria, techniques, and details of each stage. A concrete example-developing a system for playing Crystal Game (that has a set of 94 requirements)-is provided. Chapter 7 describes how to map a composed design to an implementation. Finally, two case studies are provided. The book is well written and easy to read (assuming one has an OO background). The authors are accomplished researchers in the area of AO software development, and the book grew out of their respective research interests. My impression is that while the theme approach certainly has its strengths, the analysis process (that determines the paradigm of an entire development cycle) deviates significantly from that of the object-oriented approach, thus making the transition from OO to AO (by abandoning the OO analysis mindset) somewhat difficult. Online Computing Reviews Service