Modularizing Design Patterns with Aspects: A Quantitative Study

Abstract:

Design patterns offer flexible solutions to common problems in software development. Recent studies have shown that several design patterns involve crosscutting concerns. Unfortunately,object-oriented (OO) abstractions are often not able to modularize those crosscutting concerns, which in turn decrease the system reusability and maintainability.

Hence, it is important verifying whether aspect-oriented approaches support improved modularization of crosscutting concerns relative to design patterns. Ideally, quantitative studies should be performed to compare OO and aspect-oriented implementations of classical patterns with respect to important software engineering attributes, such as coupling and cohesion. This paper presents a quantitative study that compares aspect-based and OO solutions for the 23 Gang-of-Four patterns.

We have used stringent software engineering attributes as the assessment criteria. We have found that most aspect-oriented solutions improve separation of pattern-related concerns, although only 4 aspect-oriented implementations have exhibited significant reuse.

Introduction:

Since the introduction of the first software pattern catalog containing the 23 Gang-of-Four (GoF) patterns [5], design patterns have quickly been recognized to be important and useful in real software development. A design pattern describes a proven solution to a design problem with the goal of assuring reusable and maintainable solutions. Patterns assign roles to their participants, which define the functionality of the participants in the pattern context. However, a number of design patterns involve crosscutting concerns in the relationship between the pattern roles and participant classes in each instance of the pattern [9]. The pattern roles often crosscut several classes in a software system. Moreover, recent studies [7, 8, 9] have shown that object-oriented abstractions are not able to modularize these pattern-specific concerns and tend to lead to programs with poor modularity. In this context, it is important to systematically verify whether aspect-oriented approaches [13, 19] support improved modularization of the crosscutting concerns relative to the patterns.

To the best of our knowledge, Hannemann and Kiczales [9] have developed the only systematic study that explicitly investigated the use of aspects to implement classical design patterns. They performed a preliminary study in which they developed and compared Java [11] and AspectJ [2] implementations of the GoF patterns. Their findings have shown that AspectJ implementations improve the modularity of most patterns. However, these improvements were based on some attributes that are not well known in software engineering, such as composability and (un)pluggability. Moreover, this study was based only on a qualitative assessment and empirical data is missing. To solve this problem, this previous study should be replicated and supplemented by quantitative case studies in order to improve our knowledge body about the use of aspects for addressing the crosscutting property of design patterns.

This paper complements Hannemann and Kiczales’ work [9] by performing quantitative assessments of Java and AspectJ implementations for the 23 GoF patterns. Our study was based on well-known software engineering attributes such as separation of concerns, coupling, cohesion, and size. We have found that most aspect-oriented solutions improved the separation of pattern-related concerns. In addition, we have found that:

    • The use of aspects helped to improve the coupling and cohesion of some pattern implementations;
    • The “aspectization” of design patterns reduced the number of attributes of 10 patterns, and decreased the number of operations and respective parameters of 12 patterns;
    • Only 4 design patterns implemented in AspectJ have exhibited significant reuse;
    • The relationships between pattern roles and application- specific concerns are sometimes so intense that it seems not trivial to separate those roles in aspects; and
    • The use of coupling, cohesion and size measures was helpful to assist the detection of opportunities for aspect-oriented refactoring of design patterns.

The remainder of this paper is organized as follows. Section 2 presents our study setting, while giving a brief description of Hannemann and Kiczales’ study. Section 3 presents the study results with respect to separation of concerns, and Section 4 presents the study results in terms of coupling, cohesion and size attributes. These results are interpreted and discussed in Section 5. Section 6 introduces some related work. Section 7 includes some concluding remarks.

Conclusion:

This paper presented a quantitative study comparing the AO and OO implementations of the GoF patterns. The results have shown that most aspect-oriented implementations provided improved separation of concerns. However, some patterns resulted in higher coupled components, more complex operations, and more LOCs in the AO solutions. Another important conclusion of this study is that separation of concerns can not be taken as the only factor to conclude for the use of aspects. It must be analyzed in conjunction with other important factors, including coupling, cohesion, and size. Sometimes, the separation achieved with aspects can generate more complicated designs. However, since this is a first exploratory study, to further confirm the findings, other rigorous and controlled experiments are needed.

It is important to notice that from this experience, especially in a non-rigorous area such as software engineering, general conclusions cannot be drawn. The scope of our experience is indeed limited to:

    • (a) the patterns selected for this comparative study,
    • (b) the specific implementations from the GoF book [5] and the HK study [9], (c) the Java and AspectJ programming languages, and
    • (d) a given subset of application scenarios that were taken from our development background.

However, the goal was to provide some evidence for a more general discussion of what benefits and dangers the use of AO abstractions might create, as well as what and when features of the AO paradigm might be useful for the modularization of classical design patterns. Finally, it should also be noted that properties such as reliability must be also examined before one could establish preference recommendations of one approach relative to the other.