Modularizing Design Patterns with Aspects: A Quantitative Study Alessandro Garcia Cláudio Sant’Anna Eduardo Figueiredo Uirá Kulesza Carlos Lucena Arndt von Staa Software Engineering Laboratory - Computer Science Department Pontifical Catholic University of Rio de Janeiro – PUC-Rio {afgarcia; claudio; emagno; uira; lucena, arndt}@les.inf.puc-rio.br ABSTRACT aspect-oriented approaches [13, 19] support improved Design patterns offer flexible solutions to common problems in modularization of the crosscutting concerns relative to the software development. Recent studies have shown that several patterns. design patterns involve crosscutting concerns. Unfortunately, To the best of our knowledge, Hannemann and Kiczales [9] have object-oriented (OO) abstractions are often not able to modularize developed the only systematic study that explicitly investigated those crosscutting concerns, which in turn decrease the system the use of aspects to implement classical design patterns. They reusability and maintainability. Hence, it is important verifying performed a preliminary study in which they developed and whether aspect-oriented approaches support improved compared Java [11] and AspectJ [2] implementations of the GoF modularization of crosscutting concerns relative to design patterns. Their findings have shown that AspectJ implementations patterns. Ideally, quantitative studies should be performed to improve the modularity of most patterns. However, these compare OO and aspect-oriented implementations of classical improvements were based on some attributes that are not well patterns with respect to important software engineering attributes, known in software engineering, such as composability and such as coupling and cohesion. This paper presents a quantitative (un)pluggability. Moreover, this study was based only on a study that compares aspect-based and OO solutions for the 23 qualitative assessment and empirical data is missing. To solve this Gang-of-Four patterns. We have used stringent software problem, this previous study should be replicated and engineering attributes as the assessment criteria. We have found supplemented by quantitative case studies in order to improve our that most aspect-oriented solutions improve separation of pattern- knowledge body about the use of aspects for addressing the related concerns, although only 4 aspect-oriented implementations crosscutting property of design patterns. have exhibited significant reuse. This paper complements Hannemann and Kiczales’ work [9] by performing quantitative assessments of Java and AspectJ Keywords implementations for the 23 GoF patterns. Our study was based on Design patterns, aspect-oriented programming, metrics. well-known software engineering attributes such as separation of concerns, coupling, cohesion, and size. We have found that most 1. INTRODUCTION aspect-oriented solutions improved the separation of pattern- Since the introduction of the first software pattern catalog related concerns. In addition, we have found that: containing the 23 Gang-of-Four (GoF) patterns [5], design (i) the use of aspects helped to improve the coupling and patterns have quickly been recognized to be important and useful cohesion of some pattern implementations; in real software development. A design pattern describes a proven (ii) the “aspectization” of design patterns reduced the number of solution to a design problem with the goal of assuring reusable attributes of 10 patterns, and decreased the number of and maintainable solutions. Patterns assign roles to their operations and respective parameters of 12 patterns; participants, which define the functionality of the participants in (iii) only 4 design patterns implemented in AspectJ have the pattern context. However, a number of design patterns involve exhibited significant reuse; crosscutting concerns in the relationship between the pattern roles (iv) the relationships between pattern roles and application- and participant classes in each instance of the pattern [9]. The specific concerns are sometimes so intense that it seems not pattern roles often crosscut several classes in a software system. trivial to separate those roles in aspects; and Moreover, recent studies [7, 8, 9] have shown that object-oriented (v) the use of coupling, cohesion and size measures was helpful abstractions are not able to modularize these pattern-specific to assist the detection of opportunities for aspect-oriented concerns and tend to lead to programs with poor modularity. In refactoring of design patterns. this context, it is important to systematically verify whether 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 AOSD 05 Chicago Illinois USA results with respect to separation of concerns, and Section 4 © 2005 ACM 1-59593-042-6/05/03....$5.00 Permission to make digital or hard copies of all or part of this work for presents the study results in terms of coupling, cohesion and size personal or classroom use is granted without fee provided that copies are attributes. These results are interpreted and discussed in Section 5. not made or distributed for profit or commercial advantage and that Section 6 introduces some related work. Section 7 includes some copies bear this notice and the full citation on the first page. To copy concluding remarks. otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee 3 2. STUDY SETTING Mediator role of the pattern and a Button class plays the This section describes the configuration of our empirical study. Colleague role. This study supplements the Hannemann and Kiczales work that is Figure 1 depicts the class diagram of the OO implementation of presented in Section 2.1. Section 2.2 uses the Mediator pattern to the Mediator pattern. The interfaces GUIMediator and illustrate the crosscutting property of some design patterns. GUIColleague are defined to realize the roles of the Mediator Section 2.3 introduces the metrics used in the assessment process. pattern. Specific application classes must implement these Section 2.4 describes our assessment procedures. interfaces based on the role that they need to play. In the example presented, the Button class implements the GUIColleague 2.1 Hannemann & Kiczales’ Study interface. The Label class implements the interface Several design patterns exhibit crosscutting concerns [9]. In this GUIMediator in order to manage the actions to be executed when context, Hannemann and Kiczales (HK) have undertaken a study buttons are clicked. Figure 1 also illustrates how the OO in which they have developed and compared Java [11] and implementation of the Mediator pattern is spread across the code AspectJ [2] implementations of the 23 GoF design patterns [5]. of the application classes. The shadowed attributes and methods They claim that programming languages affect pattern represent code necessary to implement the Colleague role of the implementation. Hence it is natural to explore the effect of aspect- Mediator pattern in the application context. oriented programming techniques on the implementation of the GoF patterns. For each of the 23 GoF patterns they developed a representative example that makes use of the pattern, and implemented the example in both Java and AspectJ. Design patterns assign roles to their participants; for example, the Mediator and Colleague roles are defined in the Mediator pattern. A number of GoF patterns involve crosscutting structures in the relationship between roles and classes in each instance of the pattern [9]. For instance, in the Mediator pattern, some operations Figure 1. The OO Design of the Mediator Pattern that change a Colleague must trigger updates to the corresponding Mediator; in other words, the act of updating crosscuts one or Figure 2 illustrates the source code of the Button class. The more operation in each Colleague in the pattern. necessary changes to implement the Colleague role are shadowed. The Button class implements the GUIColleague interface by Two kinds of pattern roles are identified in the HK study, which defining an attribute to reference a mediator (line 4) and the are called defining and superimposed roles. A defining role respective setMediator() method (line 6-8). Moreover, the defines a participant class completely. In other words, classes clicked() method of the Button class defines the functionality playing a defining role have no functionality outside the pattern. to communicate with the mediator (line 21). The unique role of the Façade pattern is an example of defining 01 public class Button extends JButton role. A superimposed role can be assigned to participant classes 02 implements GUIColleague { that have functionality outside of the pattern. An example of 03 04 private GUIMediator mediator; superimposed role is the Colleague role of the Mediator pattern, 05 since a participant class playing this role usually has functionality 06 public void setMediator(GUIMediator mediator){ 07 this.mediator = mediator; not related to the pattern. These kinds of roles are used by the 08 } authors to analyze the crosscutting structure of design patterns. 09 public Button(String name) { 10 super(name); In the HK study, the goal of the AspectJ implementations is to 11 this.setActionCommand(name); 12 this.addActionListener( modularize the pattern roles. The authors have reported that 13 new ActionListener() { modularity improvements