Design Patterns Evolution in some Open Source Sy...       ...
Design Patterns Evolution in some Open Source Sy...      ...
Design Patterns Evolution in some Open Source Sy...       ...
Design Patterns Evolution in some Open Source Sy...      ...
Design Patterns Evolution in some Open Source Sy...       ...
Design Patterns Evolution in some Open Source Sy...         ...
Design Patterns Evolution in some Open Source Sy...      ...
Upcoming SlideShare
Loading in …5

Technical report jada


Published on

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Technical report jada

  1. 1. Design Patterns Evolution in some Open Source Sy... Design Patterns Evolution in some Open Source Systems - Technical Report Authors: Alessandro Bianchi, Fabio Leuzzi, Fulvio Rotella Dipartimento di Informatica, University of Bari Via Orabona, 4 - 70125 Bari, Italy Date June, 19th 2008 Abstract Design patterns are solutions to recurring design prob lems: a rich literature deals with them, and, generally, b oth researchers and practitioners acknowledge their usefulness in increasing reusab ility and in improving maintainab ility of software systems. Nevertheless, few empirical studies investigated the evolution of design Our research is aimed at collecting knowledge ab out how design patterns evolve through the evolution of software systems adopting them. More precisely, we are now replicating the empirical study executed b y other researchers, which investigated the evolution of design patterns in three Open Source System (OSS) projects. Here, we report on data we collected ab out 39 OSS projects. More detailed comments are provided in ordinary pub b lications. 1. Introduction Software engineering community devoted particular attention to design patterns, since the seminal work carried out by Alexander and colleagues in the late 70s in architecture field [1]. Later, the Gang Of Four (in [2]) defined a design pattern as a description of communicating classes that represents a common solution to a common design problem; at the same time they provided a basic catalogue of design patterns. Design patterns have been then discussed from both researchers and practitioners viewpoints: all of them acknowledged their usefulness in increasing reusability and comprehensibility of software systems, and therefore in improving their development, evolution and migration (examples of this consolidated literature are [3], [4], [5]). Nowadays, benefits of design patterns with respect to several specific issues are largely acknowledged. For example, it has been showed that a proper usage of design patterns supports maintenance activities ([6]) and can reduce the number of defects in software ([7], and [8]). Application of design patterns in Human-Computer Interaction is discussed in [9]; their usage in web applications is commented in [10], and [11]. The relationship between design patterns and Aspect Oriented Programming is empirically studied in [12],1 of 7 18/12/08 01:18
  2. 2. Design Patterns Evolution in some Open Source Sy... and [13]. The usefulness of design patterns in migration of software systems towards new platforms is stated in [14], and [15]. At the same time several tools have been presented for supporting developers in implementing, documenting and detecting design patterns [16], [17], [18], and [19]. Nevertheless, few studies investigated the evolution of design patterns adopted in software system, in order to build a model for describing their impact in software maintenance and migration. Among these, Aversano et al. ([20]) discussed results from an empirical study aimed at analyzing how design patterns change during software systems lifetime, and to what extent such changes cause modifications to other classes not part of the design pattern. The main weakness of this study is the small experimental sample taken into account, and therefore the external validity of the findings is low. In order to overcome the threat to external validity, our research replicates part of the study developed by [20]. More precisely, we executed a survey, in the sense defined in [21], on 39 Java OSS projects from the FreshMeat repository. Each OSS included a number of releases ranging from 5 to 54. In this report we only present the collected data; more detailed comments are provided in ordinary pubblications. The chapter is organized as follows: Section 2 comments on the literature related to the present research; Section 3 presents the process we followed in our investigation; Section 4 depicts the collected data; Section 5 shows the trends of the design patterns along the successive releases of the 39 OSS projects taken into account; Section 6 concludes the report. 2. Related Work The literature about benefits and disadvantages or difficulties of design patterns application in software systems is very rich, and its discussion is outside the purpose of the present work: anyway, the most important papers about them have been cited in previous section. Here, it is worth focusing on empirical studies about design patterns. The usefulness of design patterns in software maintenance is the main finding of the controlled experiments reported in both [22] and [6]. The former investigated nine maintenance tasks in four programs that employ various design patterns and compares designs with patterns to simpler alternatives. The latter showed that perfective maintenance activities on an OSS requires less effort if design patterns are adopted. Note that both these studies did not investigate the evolution of design patterns. Several papers propose techniques and tools for detecting design patterns from existing software systems, for example [23], [24], [25]. In our study we used the tool Pattern3, presented in [19]: this tool implements an approach, which is based on similarity scoring between graph vertices. It takes as inputs both the system and the pattern graph and computes similarity scores between their vertices. Due to the nature of the underlying graph algorithm, this approach is able to recognize not only patterns in their basic form, but also modified versions.2 of 7 18/12/08 01:18
  3. 3. Design Patterns Evolution in some Open Source Sy... The main experimental studies concerning the evolution of design patterns along software systems evolution have been executed by Bieman and colleagues. In [26], they took into account an industrial C++ software system: the evolution of its structure was studied along 39 successive releases. It resulted that classes involved in design patterns are changed more often than other classes. Later, in [27], the study was carried out considering the C++ system previously studied, two additional proprietary systems and two additional OSS projects; for all of them several releases were considered. The previous finding was confirmed, except for one of the OSS projects. Another empirical study of design patterns evolution is the investigation executed by Aversano and colleagues [20]. They took into account the evolution of three Java Open Source Software (OSS) projects, for investigating: the change frequency of design patterns; whether some patterns are more prone to a particular kind of change; whether there is a relationship between the pattern co-change in terms of classes and source code lines, and the pattern type; the relationship between pattern targets changes and pattern client changes. This study found that the pattern change frequency and amount of co-change does not depend on the pattern type, but rather on the role played by the pattern to support the application features. The experimental samples taken into account in all previous studies are small, never greater than five software systems. All these studies acknowledge this determines a threat, which makes low external validity of their findings. In order to overcome such a problem, the research we are executing considers a greater number of OSS projects. In the current stage of the research, the evolution of design patterns is studied for 39 OSS projects, and for each of them a number of releases ranging from 5 to 54 has been considered. More precisely, our research is aimed at replicating the empirical study in [20]: we investigate the same research questions and the design patterns are detected in each OSS using the same tool: Pattern3 [19]. 3. The Experimental Process The purpose of our research is to gather information about the evolution of design patterns with respect to the evolution of software systems adopting them. To this end, we replicated part of the study in [20] with a larger experimental sample. In order to execute the study, the following process was executed: step1: experimental sample identification; step2: data collection; step3: data analysis; step4: discussion of results. In the following we present the first two steps of the process, which are preliminary to the study; data analysis and their results will be discussed in ordinary publications. 3.1. Experimental sample identification3 of 7 18/12/08 01:18
  4. 4. Design Patterns Evolution in some Open Source Sy... Two of the most popular repositories of OSS projects are SourceForge and FreshMeat. Unfortunately, both of them host only the current version and few latest versions for most of the OSS projects. Thus, for accessing a larger number of releases for each OSS, in our investigation we took into account the mirrors of each OSS linked in the main repository. Both SourceForge and FreshMeat allow sorting OSS projects according to some criteria. More precisely FreshMeat allows sorting projects with respect to: popularity, expressed as taking into account the number of download for each OSS and the number of subscriptions; vitality, expressed as (number of announcements of a new release * age of the OSS) / (time elapsed since the last announcement of a new release); ratingexpressed by subscribers. On the other side, SourceForge provides the lists of the most downloaded and most active OSS projects, but unfortunately it does not indicate how these indicators are measured. For the purposes of the present work, we took into account both the FreshMeat vitality criterion. Note that the list of most vital FreshMeat projects is very similar to the list of most active SourceForge projects. Looking at logs of past years, we saw that only few changes happened during the Christmas Holidays, so on December, 24th 2007, the list of the 100 most vital FreshMeat OSS projects has been downloaded. The list downloaded when we are writing, in May 2008, shows only few, minor changes. From that list we removed all the OSS projects written in a programming language different from Java, because the tool we used for studying design patterns allows processing only Java bytecode. Secondly, we removed from the list the OSS projects for which the total number of available releases is lower than 5. Moreover, we added to the list some very popular OSS projects, mainly taken from SourceForge repository. In this way an experimental sample of 39 OSS projects has been obtained. For each OSS project the number of releases ranges from 5 to 54, for a total number of 428 systems to be analyzed (listed in Table 1). 3.2. Data Collection In order to download all the available releases of the 39 selected OSS projects, a batch program, called JADORE (JAva DOwnload and REtrieval), was developed. JADORE reads the name of each OSS from the list, builds the proper queries for Google, and then downloads the jar files from the sites returned by Google. JADORE was run on December, 27th 2007, and after Christmas holidays (January, 3rd 2008) we got the results: only in 8 cases we had to repeat the download process. To collect data about design pattern usage within selected OSS projects, we adopted a graph-matching based approach proposed by Tsantalis and colleagues in [19] and successfully adopted with the same purposes in [20]. This approach is based on similarity scoring between graph vertices. It takes as inputs both the system and the4 of 7 18/12/08 01:18
  5. 5. Design Patterns Evolution in some Open Source Sy... pattern graph (clich�) and computes similarity scores between their vertices. Due to the nature of the underlying graph algorithm, this approach is able to recognize not only patterns in their basic form but also modified versions (variants). The pattern analysis has been performed using a tool, developed by Tsantalis and colleagues to support the approach, which analyzes Java bytecode. The tool allows detecting the following patterns: Object Adapter-Command (AC), Composite (C), Decorator (D), Factory Method (FM), Observer (O), Prototype (P), Singleton (S), State-Strategy (SS), Template Method (TM), and Visitor (V). Note that design patterns catalogues (for example [2]) distinguish Object Adapter from Command, as well as State is considered different from Strategy, but, because of the similarities between them, the Tsantalis tool detects Adapter/Command and State/Strategy. Moreover, due to the high number of systems to process, we integrated the tool developed by Tsantalis and colleagues in the JADA (JAva Design pattern Analysis) environment. JADA gets in input the list of the systems, for each of them detects the design patterns by calling the Tsantalis tool, and returns results in an XML file. In this way only one week-end was sufficient to process all the 428 OSS projects, so getting a total of 27855 design patterns. 4. Collected Data Data obtained in the previous step are easily organized so that for each OSS we can see the number of each design pattern in each release. Table 2 reports the collected data. In the table, each row refers to a release of an OSS, and then it is reported: the total number of Factory Methods patterns detected in that release of that OSS; the total number of Prototype patterns; the total number of Singleton; the total number of Object Adapter- Command; the total number of Composite; the total number of Decorator; the total number of Observer; the total number of State/Strategy; the total number of Template Method; the total number of Visitor. Table 3 summarizes the total number of instances of the design patterns in all the releases of all the OSS projects taken into acocunt. The Grand Total, i.e. the total number of detected design patterns is 27855. 5. Trends In order to analyze the evolution of design patterns through successive releases of OSS projects, the lineplots of all design patterns in each OSS are here reported: for each OSS a unique figure shows the trends of all the design patterns adopted in that OSS. Therefore, if in an OSS a design pattern is never adopted, that design pattern is not represented in that figure. 6. Conclusions In this technical report data about the number of design patterns detected in the5 of 7 18/12/08 01:18
  6. 6. Design Patterns Evolution in some Open Source Sy... successive releases of 39 OSS projects are reported. This dataset will be used for more detailed analysis. References 1. C. Alexander, S. Ishikawa, M. Silverstein Murray Silverstein, Max Jacobson, Ingrid Fiksdhl-King, and Shlomo Angel. (1977). A Pattern Language. Oxford University Press, New York 2. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. (1995). Design Patterns - Elements of Reusab le Ob ject-Oriented Software. Addison-Wesley 3. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M.Stal. (1996). Pattern- Oriented Software Architecture. Wiley 4. L. Rising. (1998). The Patterns Handb ook. Cambridge Univ. Press 5. C. Larman. (2001). Applying UML and Patterns: An Introduction to Ob ject- Oriented Analysis and Design and the Unified Process. second ed. Prentice Hall. 6. T.H. Ng, S.C. Cheung, W.K. Chan, and Y.T. Yu. (2006). Work Experience versus Refactoring to Design Patterns: A Controlled Experiment. Proceedings of the ACM SIGSOFT symposium on The foundations of software engineering (FSE06), Portland, Oregon, pp. 12-22. 7. Y.-G. Gueheneuc, and H. Albin-Amiot. (2001). Using Design Patterns and Constraints to Automate the Detection and Correction of Inter-Class Design Defects. Proc. 39th Intl Conf. and Exhib ition Technology of Ob ject-Oriented Languages and Systems, pp. 296-305. 8. M. Vokac. (2004). Defect Frequency and Design Patterns: An Empirical Study of Industrial Code. IEEE Transactions on Software Engineering, 30(12), pp. 904-917. 9. A. Gaffar, A. Seffah, and J.A. Van der Poll. (2005). HCI Pattern Semantics in XML: a Pragmatic Approach. ACM SIGSOFT Software Engineering Notes, 30(4), pp.1 - 7. 10. M. Y. Ivory, and R. Megraw. (2005). Evolution of Web Site Design Patterns. ACM Transactions on Information Systems, 23(4), pp.463-497. 11. L. Baresi, and S. Morasca. (2007). Three Empirical Studies on Estimating the Design Effort of Web Applications. ACM Transactions on Software Engineering and Methodology, 16(4). 12. A. Garcia, C. SantAnna, E. Figueiredo, U. Kulesza, C. Lucena, A. von Staa. (2005). Modularizing Design Patterns with Aspects: A Quantitative Study. Proceedings of the 4th international conference on Aspect-oriented Software Development, pp. 3-14. 13. N. Cacho, C. SantAnna, E. Figueiredo, A. Garcia, T. Batista, and C. Lucena. (2006). Composing Design Patterns: A Scalability Study of Aspect-Oriented Programming. Proceedings of the 5th international conference on Aspect-oriented Software Development, pp.109-121. 14. B. Kumar M, R. Lakshminarayanan, and Y.N. Srikant. (2000) A Study of Automatic Migration of Programs Across the Java Event Models. ACM SIGSOFT Software Engineering Notes, 25(3), pp. 24-29. 15. D. Distante S. Tilley, G. Canfora, and S. Huang. (2006). Redesigning Legacy Applications for the Web with UWAT+: A Case Study. Proceedings of the International Conference on Software Engineering. pp. 482-491. 16. J.K.H. Mak, C.S.T. Choy, D.P.K.Lun. (2004). Precise Modeling of Design Patterns in6 of 7 18/12/08 01:18
  7. 7. Design Patterns Evolution in some Open Source Sy... UML. Proceedings of the International Conference on Software Engineering. pp.252-261. 17. A. Blewitt, A. Bundy, and I. Stark. (2005). Automatic Verification of Design Patterns in Java. Proceedings of the Automated Software Engineering Conference. pp.224-232. 18. L. Wendehals, and A. Orso. (2006). Recognizing Behavioral Patterns at Runtime using Finite Automata. Proceedings of the 2006 international Workshop On Dynamic systems Analysis, pp. 33-39. 19. N. Tsantalis, A. Chatzigeorgiou, G. Stephanides, and S.T. Halkidis (2006). Design Pattern detection using similarity scoring. IEEE Transactions on Software Engineering, 32(11), pp. 896-909. 20. L. Aversano, G. Canfora, L. Cerulo, C. Del Grosso, and M. Di Penta. (2007). An Empirical Study on the Evolution of Design Patterns. Proceedings of the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering (ESEC/FSE07), Cavtat, Croatia, pp. 385-394. 21. A. Bianchi, F. Lanubile, and T. Mallardo. (2008). Empirical Studies in Software Migration and Reverse Engineering. to appear. 22. L. Prechelt, B. Unger, W. F. Tichy, P. Broossler, and L. G. Votta. (2001). A Controlled Experiment in Maintenance Comparing Design Patterns to Simpler Solutions. IEEE Transactions on Software Engineering, 27(12), pp. 1134-1144. 23. R.K. Keller, R. Schauer, S. Robitaille, and P. Pag�. (1999) Pattern- Based Reverse- Engineering of Design Components, Proceedings of International Conference on Software Engineering. Los Angeles, pp. 226- 235. 24. I. Philippow, D. Streitferdt, M. Riebish, S. Naumann. (2005). An Approach for Reverse Engineering of Design Patterns. Software System Model, 4(1), pp. 55-79. 25. Andrea De Lucia, Vincenzo Deufemia, Carmine Gravino, Michele Risi. (2007). A Two Phase Approach to Design Pattern Recovery. Proceedings of the 11th European Conference on Software Maintenance and Reengineering, pp. 297-306. 26. J.M. Bieman, D. Jain and H.J. Yang. (2001). OO Design Patterns, Design Structure, and Program Changes: An Industrial Case Study. Proceedings of International Conference on Software Maintenance. IEEE Computer Society Press, pp. 580-589. 27. J.M. Bieman, G. Straw, H. Wang, P.W. Munger, and R.T. Alexander. (2003). Design Patterns and Change Proneness: An Examination of Five Evolving Systems. Proceedings of the 9th International Software Metrics Symposyum , pp.40-49.7 of 7 18/12/08 01:18