Technical report jada

Design Patterns Evolution in some Open Source Sy... http://www.di.uniba.it/~bianchi/ricerca/ﬂoss/design_...

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


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


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 identification

3 of 7 18/12/08 01:18


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 the

4 of 7 18/12/08 01:18


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 the

5 of 7 18/12/08 01:18


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 Int'l 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. Sant'Anna, 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. Sant'Anna, 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 in

6 of 7 18/12/08 01:18


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

Technical report jada

More Related Content

What's hot (8)

Similar to Technical report jada (20)

More from University of Bari (Italy) (11)

Recently uploaded (20)

Technical report jada