See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/319185695

Design patterns: Current challenges, trends, and research directions

Technical Report · July 2016

DOI: 10.13140/RG.2.2.23108.12162

CITATIONS READS

5 6,642

2 authors:

Alireza Rouhi Bahman Zamani

Azarbaijan Shahid Madani University University of Isfahan
17 PUBLICATIONS   53 CITATIONS    72 PUBLICATIONS   309 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MDE of Bidirectional Transformations View project

Model Based Testing View project

All content following this page was uploaded by Alireza Rouhi on 20 August 2017.

The user has requested enhancement of the downloaded file.

T ECHNICAL R EPORT
Report No. UI-SE-MDSERG-2015-02
Date: July 13, 2016

Design Patterns: Current Challenges,

Trends, and Research Directions

Alireza Rouhi
Bahman Zamani

Department of Software Engineering

University of Isfahan
Hezar-Jerib Ave.
Isfahan

Tel: +98-31-37934537
Fax: +98-31-36699529 , +98-31-37932670
zamani@eng.ui.ac.ir
http://mdse.bahmanzamani.com/
Design Patterns: Current Challenges,
Trends, and Research Directions
Alireza Rouhi and Bahman Zamani
Department of Software Engineering
University of Isfahan
Isfahan, Iran.
{rouhi, zamani}@eng.ui.ac.ir

Abstract: Design patterns solve recurring design problems. We can

classify the literature on design patterns into two main categories:
1) Pattern Application, i.e., applying design patterns on a design
model which is a forward engineering approach, and 2) Pattern De-
tection and Identification, i.e, extracting applied design patterns from
a given source code which is a reverse engineering approach. With
the above classification in mind, this report intends to explore the
current challenges behind the design patterns and related tools.
 Design Patterns: Current Challenges,
Trends and Research Directions
Alireza Rouhi and Bahman Zamani
Department of Software Engineering
University of Isfahan
Isfahan, Iran.
{rouhi, zamani}@eng.ui.ac.ir

Abstract: Design patterns solve recurring design problems. We can

classify the literature on design patterns into two main categories:
1) Pattern Application, i.e., applying design patterns on a design
model which is a forward engineering approach, and 2) Pattern De-
tection and Identification, i.e, extracting applied design patterns from
a given source code which is a reverse engineering approach. With
the above classification in mind, this report intends to explore the
current challenges behind the design patterns and related tools.

1 Introduction
Patterns are solutions to recurring design problems [GHJV94, SFJ96]. In this report,
to investigate the issues regarding design patterns, we move on to the current state
of design patterns’ challenges, trends, and research directions. Based on studying
the past and the current researches, we classify the design pattern research field into
two broad categories: 1) design pattern application 2) design pattern detection and
identification (see Figure 1). Design Pattern Application is aimed at applying pattern
solutions in the software design, i.e., it is a forward engineering approach. However,
the Pattern Detection and Identification is a backward and reverse engineering ap-
proach which intends to detect and identify the applied design patterns in the given
source codes. As we know, a design pattern as a solution to a recurring problem
has several components and constituent elements such as the pattern intent, moti-
vation, applicability/known uses, and consequences, to name a few [GHJV94]. Thus,
most of the existing pattern detection tools use other terms such as design motifs
in [Gué07a], i.e. the solution components of design patterns which can be extracted
from the source code or design model in a more tangible way.
In the following, we will explore the details of these techniques through investigating
their practical applications and related researches and studies.

1
 Design Patterns

Pattern Application Pattern Detection and Identification

Design Model Source Code

Figure 1: Pattern Detection, Identification, and Application

2 Pattern Application

The main drawbacks on the way of pattern application include: expertise and knowl-
edge requirements in the application of correct design patterns; lack of formal basis
and techniques to aid in the systematic pattern selection and application; and little
support to verify the correctness of the applied design patterns and their relationships
[Kim08, FBB+ 14].

2.1 Transformation-based Pattern Application

In order to apply systematically a design pattern to a model, [Lan14] uses model

transformation for the application and verification of design patterns in a design
model. Here, first a model is developed regardless of any design pattern in mind and
then in the next step, the produced model can be refactored to improve its quality
through the introduction of suitable design patterns. Finally, model transformation
verification can be used to verify that the existing model restrictions are preserved.
In order to provide qualitative and continuous services in the cloud-based systems, [AB14]
applies a self-adaptive architecture based on the adaptation patterns in the form of a
Pattern Language (PL) recovered from the architecture adaptation log of the underlie
running system.
Refactoring a design model using design patterns has been experienced in [FCSK03].
Here, based on the defined metamodel of the design pattern with matching its problem
specification against the design model, refactoring automated through transformation
on the level of the design pattern metamodel.

2
2.2 Applying PLs in Practice
With the emergence of patterns, pattern collections and PLs in various contexts,
designers are encouraged to use the PLs in a practical sense to solve common software
problems as a whole [HGY14].

2.2.1 Providing a framework for applying patterns of PLs in software

development

Applying suitable and correct patterns of several and inter-connected PLs in practice
together with solving a real business and practical case study have been presented
in [HGY14]. The authors in [HGY14] claims that usage of their proposed framework
for applying patterns not only will provide solutions to specific design problems but
also will help them on how, when, and on what order to apply patterns. The main
steps of [HGY14] framework are (1) adapting existing patterns first, if it is possible
and there are matched patterns with the constraints of current problem context, and
(2) if there is not any pattern match, divide the problem to subproblems and repeat
the step (1) again.

2.2.2 Pattern Language Verifiers (PLVs) in Model-Driven Design

Use of a unique “Sign” stereotype as the indication of a single applied pattern which
is specified by a model designer, [Zam09] verifies the used pattern structure and its
relationships with other applied patterns through the proposed PLV modules, i.e.,
lexical, syntactical and semantical verification modules. In other words, a design
model is developed using patterns of a PL, i.e. Patterns of Enterprise Application
Architecture (PofEAA), then the PLV, named ArgoPLV, verifies that whether the
applied patterns and their relationships are correct or not.

3 Pattern Detection and Identification

Exploring the researches which have been conducted in the last two decades reveals
many projects which aimed at the detection and identification of the design patterns in
the existing design model or source code [AFC98, BP00, AACGJ01, AAG01, GJ01,
Don02, HHHL03, CDLD+ 05, TCSH06, Gué07a, GA08, SW08, vDMT10b, AFZ11,
AFMR11, FZM11, EBM12, EBL13, FMR13, AZY14, YZC15, ZFS15]. This is typical
because of the philosophy of software patterns which is to detect and identify the best
practices from the existing models or codes to convey them as recurring solutions

3
to the same problems in the same domain and problem space in the future. Of
course, this process is an approximate approach. Therefore, probably the detected
and identified pattern instances will be approximate and hence controversial and
debatable. Usually, two metrics are used to evaluate the pattern detection tools and
methods applicability: precision and recall. These metrics are defined in [Gué07a]
as follows (Note: here, a design motif is formed from an inter-class structure which
per se is constructed with some defined micro-architectures/µA):

| {true µA} ∩ {identif ied µA} |

precision = (1)
| {identif ied µA} |

| {true µA} ∩ {identif ied µA} |

recall = (2)
| {true µA} |

Design pattern detection and identification is a reverse engineering approach which

helps to analyze and understand the legacy code design and intentions for mainte-
nance and upgrading purposes as well as transferring and reusing in between design
knowledge in the development of similar projects [vDMT10b, AZY14, YZC15]. There-
fore, many tools regarding pattern detection and identification have been presented
to help designers understand and analyze the details of the existing source code.
Authors in [AFC98] present a design pattern recovery process which tries to recover
five of seven structural design patterns of the Gang-of-Four (GoF) [GHJV94] book,
i.e. the adapter, the proxy, the composite, the bridge and the decorator in the object-
oriented software development and design. Here, a four step process has been intro-
duced which extracts design patterns using the structural properties of the corre-
sponding class diagrams. The mentioned process is depicted in Figure 2. To cope
with the combinatorial state explosion problem of the involved classes and in be-
tween relationships of the detected patterns, a multi-stage reduction technique with
the exploitation of the metrics and constraints of classes and their relations is used to
reduce the matched candidates in the final result of extracted design patterns. Due
to the conservative aspect which is taken by the proposed process, it is impossible to
have the false negative results in the detected patterns. However, there maybe some
false positive results in the recovered design patterns which needs manual inspection
to verify from the expert and designer side.
The basic design pattern detection techniques are shown in the Figure 3. Accord-
ing to the literature, the pattern detection analysis approach taken by most of the
tools is static or dynamic. Furthermore, static or dynamic analysis is accomplished
structural, considering only the structural elements of the programs or behavioral
which takes into account the program execution traces too. Due to the important

4
 AOL
Pattern
Library

C++ Source Code2AOL Code AOL

Code Translator Specifications
Pattern
Pattern Recognizer
Candidates
CASE
Tool CASE2AOL Design AOL
OMT Translator Specifications
Design

D
Metrics
Constraint
Evaluation
Decorated Rj
AOL AST Metrics Constraints
AST
Parser Extractor Evaluator Structural
Constraint
Evaluation
S
Delegation
JAVA Engine Constraint
Evaluation
P

Figure
Figure 2. Pattern
2: Pattern Extraction
Extraction Process.
Process [AFC98]

role of behavioral
with linear complexity, a candidate elements
set for eachin pattern
the design
ele- pattern specification,
tation, the false positive
with cubic complexity [1], in rate
practice, since
ment. of pattern detection results can be reduced with sign the combination
patterns of both static and
are micro-architectures, typical values
In other words, let p = (< e1 ; : : : ; ek >; R) a pattern
dynamic analysis as well as structural and ShPath(ej ; emin ) are limited and usually below 4. A
behavioral analysis [Bin12].
e1 ; : :to: ; ethe
(with elements Due k structural similarity between patterns
) belonging to a pattern collection consequence
like thetheStrategy
complexity
andobserved
State ininthe
practical cases
P , let Mp =< GoFm1 ; : catalog
: : ; mk >[GHJV94],
be the tupleusing
of metrics
only char- almostcan
static analysis linear with the
increase size
the of Cmin
pattern .
detection
acterizing pattern p , where each m
false positive rate.i As a result, the analysis approach must take into account both
is an array of the met-
rics listed in Section
of the3.2 and corresponding
static and dynamic toanalysis
each pattern
in order 3.3.2 Structural
to distinguish and Delegation
correctly Constraints Evalu
aforementioned
element, then candidates for the elements
similar patterns. Following ei this section, we introduce
are elements of tion some of the important and
the set: invaluable tools in the pattern detection field.The previous stages have only imposed, for each patt
2.1.
constituent, the presence of certain pattern relationshi
GENERAL NOTIONS 9

Ci fxjx 2 D ^ 8mi 2 Mp : 8mij 2 mi mijx  mij g

def
= without worrying about the exact identity of the classes
What to Analyze
volved in the relations.
Clearly, the same design element x could be in more than
Structure In the lastBehaviour two stages, exact design pattern constrai
one Ci . However, actual pattern instances are types are applied to tuples < r1 (y ) : : : y : : : rn (y ) > wh
surely within
2
Static
r y R y
How to analyze

C1 ; : : :fields
Analysis ; Cnand k ( ) k (
call graph
) . In the first stage structural constraints
the tuples extracted from the set collection
(program)
. method signatures
applied and the data S of the candidate tuples formed w
setflow
To further reduce the search space, let’s chooseassociations,
the Ci sets, for example the set Cmin with minimum num-
one of inheritance
the sets r k ( y ) 2 R k y ) that satisfy those constraints is p
(

ber of elements; emin (the corresponding

Dynamic duced as output. Let R = fpjp =< r1 (y) : : : rn (y) > ^y
Cmin ^ 8rk (object y) 2creation
Rk (y)g, a tuple in S satisfies all the
pattern element) execution traces
Analysis object relationships
can be regarded as a node in a graph representing
tern, where the remaining n , 1 pattern constituents must
(traces) the pat-
lations in R S , where RS is a subset of R representing
be reachable from Cmin elements in a number Figure of steps 2.1.1. structural
con- Program analyses relations (i.e. without delegation constraints):
Figurestructure.
strained by the pattern 3: The basicReduceddesign patternsets
candidate S def
detection techniques = fxjx(adapted
=< x1 : : from 2R ^
: xn >[KB09])
Rj (y) with j 6= min, j = 1; : : : ; n and y 2 Cmin can be 8 r 2 Rwith s ; : : : et ) ) r(xp ; xs : : : xt )g
r(ep ; eindi-
S : 100%
defined as: by a score. Scores are typically expressed by a percentage,
cating total condence. Scores might 5be taken where intop;account
s and twhen computing
are generic indices of a subset of patt
Rj (y) = fxjx 2 D ^ ShPath
def
(x; y )and
precision = ShPath
recall of(epattern g
j ; emin )detection tools as Pettersson
elements that participateset al. [54 given relation r.
at ]a re-
ports. This thesis presents a novel approach The to compute precision and recall
set S is taken as input of the second stage in wh
of a pattern detection tool that reports scores; see Chapter 9 for more details.
the delegation constraints are checked and the final set P
where ShPath(x; y ) is theProgram
shortest Analyses.
path between Mosttwopattern detection
tuples that algorithms
satisfy also match descrip-
these constraints is produced as o
classes x and y in a design,tions of the expected structure and the behaviour of sought patterns against
measured as the number of re- put of the whole process. Checking delegation constrai
the information
lations on the design that must be traversedabout
to reachthe ystructure
from andinvolves behaviour of program
verifying that elements.
a given method of a given patt
x, independently on the nature
Relevant
of theprogram analyses can be categorized
relations. in two orthogonal
constituent actually calls dimensions,
a method of another pattern co
with two subcategories each:
Notice that, even if theoretically speaking, Rj (y ) com- stituent. Information about calls contained in each meth
 Structural Source Traces
Traces
Behavioral 3. EVALUATION RESULTS
Patterns Code Patterns
We used our prototype implementatio
Tool Suite to evaluate the approach by an
Static Program Dynamic Abstract Window Toolkit, the Java Gener
Analysis Execution Analysis Standard Widget Toolkit, and JUnit 3.8
Document results are given in [4].
Process Step Pattern Accepted / Rejected We compared the analysis results of J
Data Flow Candidates Pattern Candidates proaches. In accordance with them we
the Composite, Decorator and Template
We also detected several Observer candi
Figure 1: The pattern detection process
Figure 4: The Reclipse pattern detection process [vDMT10b] namic analysis revealed that only one of t
rithm then applies the different rules to the abstract syntax rect Observer behavior. The other can
graph and tags parts whose structure complies to a pattern positives.
3.1 PTIDEJ with annotations. For details we refer to [3].

Pattern Variants and Rating of Pattern Candidates 4. CONCLUSIONS AND FUT

In this paper 1we presented our rever
The Pattern TraceInIdentification, Detection,
order to enable the recognition and Enhancement
of different pattern vari-in Java (PTIDEJ)
proach. The major advantages compared
ants with a single specification, we introduce the concept
is also a reverse engineering tool suite which contains several modulesareaimed at the of static and dynam
the combination
of additional constraints. They allow to specify conditions detection of patterns as well as its flexible
identification of design patterns applied in multiple source code
whose satisfaction is desired but not mandatory to consti- formats specifically
structural and behavioral pattern specific
programs written intuteJava [Gué07b].
an actual pattern instance. the re-engineer to extend and adapt the
For example, many patterns describe certain properties, Furthermore, the approach allows to sp
like the visibility of an attribute or a class being abstract, tural variants of a pattern at one go by m
which are not essential and are therefore often neglected constraints which are used to automatic
3.2 Reclipse in implementations. Hence, we mark such constraints as pattern candidates.
additional. This way, we detect both, candidates with and We obtained evaluation results which
without the specified properties.
The Reclipse 2 , based on the From UML to Java And Back
We use the information given by the satisfaction of ad- Again approach andisitsa implementation are m
(FUJABA),
enough to be applied to real systems.
reverse engineeringditional
tool suite aimedtoatseparate
constraints detecting thefrom
reliable GoFless design patternsIninthethe
reliable Javawe plan to allow the us
future,
source code has been results. This is done
developed as an automatically
eclipse plug-inby rating
at each pattern
the University of Paderborn.
ues in metric-based constraints and the
candidate with a percental value that relates the number of thresholds that are hard to determine.
This tool integratesconstraints
structural analysis
satisfied by a with a subsequent
candidate to the total dynamic
number of analysis to recover
integrate the concept of additional const
design patterns which constraints in the in
are similar corresponding
their structurepatterntoo,
specification.
such as the The State and Strategy
havioral patterns and intend to provide
more constraints are satisfied the higher is the rating value. the interpretation
design patterns. Figure 4 illustrates the pattern detection
The rating quantifies the degree of a pattern candidate’s
steps involved in the Re- of dynamic analysis re
clipse tool suite. Here, to have
compliance a formal
to its andand
specification independent notation
helps the reverse engineerfor the specification
5. REFERENCES
of design patterns, to a distinguish
metamodel truehas
frombeen
false positives.
developed Moreover, a thresh-vDMT10a].
[vDMT10b,
old can be set in order to display only pattern candidates [1] E. Gamma, R. Helm, R. Johnson, and
with a rating higher than the threshold. Design Patterns. Addison-Wesley, 199
[2] M. Meyer. Pattern-based Reengineeri
3.3 DPJF Dynamic Analysis Systems. In Proc. of the 13th Workin
The dynamic analysis is based on traces of the pattern can- Reverse Engineering, pages 305–306,
didates. To obtain these traces, the system under analysis [3] J. Niere, W. Schäfer, J. P. Wadsack,
Recently, a novel research
is executed withand amethod
relatively complete
calls between literature
instances on the design
of classes pattern
J. Welsh. Towards Pattern-Based Des
detection tools has whichbeen aredonepartby of Alexander
a candidate are Binun at the
recorded. University
Note that we of Bonn of the 24th International Confe
Proc.[Bin12].
only trace the candidates’ behavior instead of the whole sys- Engineering, pages 338–348, 2002.
One of the contribution of this research is presenting a tool named Detection
tem which drastically reduces the search space for the dy-
of
3 [4] M. von Detten, M. Meyer, and D. Tra
Patterns by Joining Forces
namic analysis.(DPJF) which is claimed that it has won the game of
A Reverse Engineering Tool Suite. Te
precision and recall in Thecompeting
expected behavior
with forthea given pattern is formally
contemporary toolsspec- tr-ri-10-312,
in the design pattern University of Paderborn,
ified with special sequence diagrams. They describe interac- [5] M. von Detten and M. C. Platenius. I
detection of varioustions Java codedelements
between benchmarks (seepatterns
in structural Figureand 5).determine
Furthermore, DPJF has a
Dynamic Design Pattern Detection in
which method calls may occur in which order between the Objects. In Proc. of the 7th Internati
1
http://www.ptidej.net/tools/
classes that participate in a pattern candidate. pages 15–19, 2009.
2
http://www.fujaba.de/projects/reengineering/reclipse.html
During the analysis step, the traces are compared to the [6] L. Wendehals. Struktur- und verhalten
3 corresponding behavioral patterns. For this purpose, a spe-
https://sewiki.iai.uni-bonn.de/research/dpd/dpjf/start Entwurfsmustererkennung (Structural
cial automaton is automatically generated for each behav- Design Pattern Detection). PhD thesi
ioral pattern. If a trace matches the pattern, it is accepted Paderborn, 2007. In German.
and rejected otherwise [7]. 6 [7] L. Wendehals and A. Orso. Recognizi
If the majority of a candidate’s traces match the behav- Patterns at Runtime using Finite Aut
ioral pattern, the candidate likely is an actual design pattern of the 4th ICSE Workshop on Dynam
instance. If most of the traces for a candidate do not match 33–40, 2006.
the behavioral pattern, it is assumed to be a false positive
which is only structurally similar to the actual pattern.

300
 Figure 5: Precision and recall on some benchmark projects [BK12]

reasonable speed too [BK12]. To obtain qualitative pattern detection results in terms
of precision and recall as well as improving the query speed, [Bin12] applies both of
structural and behavioral analyses to detect design motifs in the source code.
A summary of the literature and state of research on the design pattern detection
and related tools are illustrated in Figure 6.

3.4 VPML
Visual Pattern Modeling Language (VPML) [EBL13] intends to detect design patterns
on the Meta-Object Facility (MOF)4 -based modeling languages. Each pattern is
modeled using VPML. Then, the modeled pattern through mapping to a Query,
View, Transformations (QVT)-R 5 transformation, runs on a given model to detect its
used pattern instances. [EBL13] claims that its presented approach with prototyping
on the Eclipse detects some of the GoF design patterns [GHJV94] on the given Unified
Modeling Language (UML) models and Control Flow patterns on the given Business
Process Model Notation (BPMN)6 models.
4
http://www.omg.org/spec/MOF/
5
http://www.omg.org/spec/QVT/
6
http://www.omg.org/spec/BPMN/

7
 &ƵũĂďĂ ϵ ϭϬ y y y ϭϬ &ƵũĂďĂ ϯϯ ϰϳ y y y ϰϬ
W/EKd ϭϴ ϵ ϳϴ ϯϰ ϭϰ ϭϴ W/EKd ϱϬ ϭϯ ϯϭ Ϯϰ ϭϴ Ϯϰ
Wd/: ϮϬ ϭϱ Ϯϰ ϯϯ Ϭ ϮϬ Wd/: ϯϯ ϭϴ ϭϮ ϭϴ Ϭ ϭϴ
^^ ϱϭ ϲϯ ϳϬ y ϴϬ ϲϲ ^^ ϰϯ ϱϮ ϰϰ y Ϯϰ ϰϰ
W:& ϭϬϬ ϭϬϬ ϭϬϬ ϭϬϬ ϭϬϬ ϭϬϬ W:& ϲϳ ϲϱ ϴϵ ϵϮ ϵϲ ϴϵ

(a) Precision (b) Recall

ϭϬϬ ϭϬϬ
ϵϬ ϵϬ
ϴϬ ϴϬ
ϳϬ ϳϬ
ϲϬ &ƵũĂďĂ ϲϬ &ƵũĂďĂ
ϱϬ ϱϬ
W/EKd W/EKd
ϰϬ ϰϬ
Wd/: Wd/:
ϯϬ ϯϬ
ϮϬ ^^ ^^
ϮϬ
ϭϬ W:& ϭϬ W:&
Ϭ Ϭ

(c) : Precision (graph for Fig. 20a) (d) Recall (graph for Fig. 20b)

Figure 20: Precision and recall on all benchmark projects. The inability of a tool to detect a pattern is indicated by an ’X’ in
the table and a holeFigure 6: The applied basic techniques of analyzed tools [Bin12]
in the graph

3.5 MARPLE-DPD

Metrics and ARchitecture Reconstruction PLugin for Eclipse-Design Pattern Detec-

Load +
Query
ůůĞǀĂůƵĂƚĞĚƉĂƚƚĞƌŶƐ
ƌŐŽ dĞĂŵ
:,ϱ :,ϲ :ĂǀĂ/K Initialisation
td
hD> ŽƌĞ ƌŐŽ dĞĂŵ
tion (MARPLE-DPD) is a tool
&ƵũĂďĂ 60,0 180,0

suite:,ϱ
time (seconds)
600,0 which
50,0 detects design
:,ϲ :ĂǀĂ/K td
hD> ŽƌĞpatterns in the Java source Query
ůůĞǀĂůƵĂƚĞĚ ƉĂƚƚĞƌŶƐ
ƌŐŽ dĞĂŵ
WƚŝĚĞũ 2,3 4,2 2,9

4,9 :,ϱ :,ϲ :ĂǀĂ/K td
codes by using machine learning
WŝŶŽƚ;ĂůůͿ
WƚŝĚĞũ
1,0
39,3
6,0
99,2
2,0
9,0
17,0
^^


55,0


techniques
4,0
0,9
14,7 5,2 (see
1 2Figure
15 7 for more details on its ar-
0,7 WƚŝĚĞũ 37,0 95,0 6,1

hD>


ŽƌĞ
9,8
4 14 5 40 56 6
chitecture). After analyzingW:&ƌĞƐƚĂƌƚ
^^
W:&
1,6
5,2
9,3
18,0
3,0
7,0
13,1
the 55,1
source
W:&ĨŝƌƐƚƐƚĂƌƚ
54,8 77,0
1,3
35
8,0
code
150 49
and
390
constructing
550 60
the Abstract Syntax ^^
W:&
0,7
1,2
4,1
4,0
2,0
2,0
11,1
14,8
40,1
21,0
0,6
2,0

Tree
(a) (AST),
Time for theanddetection
initialisation analysis is performed by the time
(b) Initialization other two steps named(c) Joiner (which
Pure analysis time
collects detected pattern instances) and Classifier (which determines the correct and
ϭϬϬ ϭϬϬ
incorrect
ϵϬ detected candidate patterns). ϵϬ
ϴϬ ϴϬ
To the
ϳϬ best of our knowledge, none of the aforementioned
ϲϬ WŝŶŽƚ;ĂůůͿ
ϳϬ
ϲϬ
tools [Gué07b, vDMT10b,
Bin12]
ϱϬ consider the relationships between
WƚŝĚĞũ detected design
ϱϬ patterns. WƚŝĚĞũ
ϰϬ ϰϬ ^^
ϯϬ ^^ ϯϬ
W:&
ϮϬ W:& ϮϬ
ϭϬ ϭϬ
Ϭ Ϭ

4 Conclusion
:,ϱ :,ϲ :ĂǀĂ/K td ƌŐŽ
hD>
dĞĂŵ
ŽƌĞ
:,ϱ :,ϲ :ĂǀĂ/K td ƌŐŽ
hD>
dĞĂŵ
ŽƌĞ

(d) Time for initialisation and analysis (e) Pure analysis time

FigureIn
21:this report,
Response timeswe classified
of each the state
tool for detecting of research
all evaluated onIndesign
patterns. patterns
the tables, the fastestinto twoproject
time per mainis red and
a bomb indicates that1)
categories: thepattern
tool crashed on that project.
application, and In 2)
the pattern
graphs, Fujaba is not shown
detection and since it is an order of
identification. We magnitude
slowertried
than most
to explore and present current challenges and issues regarding the aforemen-tools for
other tools, which would have distorted the graphs. Pure analysis time is indicated only for the
which it can be measured separately.

8
 static RestrictedCreationClass rcc ;
private RestrictedCreationClass () {
...
}
}
Listing 1. Restricted creation micro pattern example.

3.1. Micro-structures detector

Information Detector Engine
Java Eclipse Micro Structures Detector In the micro-structures detecto
AST
Code JDT tracted by a set of visitors parsing a
Metrics Collector
code, provided by the Java develo
each visitor supports the detectio
DPD Joiner ports the found instances. The info
Recognition Model analysis and is characterized by 10
rules (Serialized to value is due to the fact that these k
XMI) mechanically recognizable (Gil and M
Classifier 1-to-1 correspondence between a m
of pieces) of code, and the algorith
is defined in terms of the source c
Figure 1. The architecture of MARPLE.
the complete list of supported mic
Figure 7: The architecture of MARPLE-DPD [ZFS15] Different micro-structures can b
using different techniques; the onl
3. MARPLE-DPD fer to two (or also only one) code e
tioned classification. Although, there are several well known support tools to detect
(see Section 2.1) are the central ele
Metrics and ARchitecture Reconstruction PLugin for Eclipse exploited in MARPLE. Micro-struct
and identify applied patterns
(MARPLE) 1 is ourintool
the source code
implementing DPD from(likeJavaReclipse
source code[vDMT10b],
and PTIDEJ
forming an exploration of the AST
[Gué07b], DPJF [Bin12], and MARPLE-DPD [ZFS15], to name a few), (iflack
other functionalities. The overall architecture of metrics and architec- of amore
needed) uni-complex analyses
ture reconstruction plugin for eclipse (MARPLE) is depicted in Fig. 1. and patterns
Ryder, 1990),
fied and popular formalism is one of the main obstacles on applying
DPD activities work on information extracted from the abstract syntax
design indynamic analysi
general [Zdu07, Zam09, ZB13].
trees (ASTs) of the Note
analyzed that most
system. Thisof the current
information commonly used design
is represented
3.2. Joiner
patterns have been presented in natural languages. Also, to the 2),
by elements, or facts, which are called micro-structures (see Section best of our knowl-
and by metrics that have been measured inside the system. Both these
edge, there is not kinds
any ofconsiderable
information are usedresearch
to have anand supporting
abstract tools regarding
and more consistent pattern
The Joiner analyzes the inform
tract groups of classes from the sys
inter-relationships view
in general andinstead
of the system, PLs in particular.
of directly relying on the code or on the
AST. candidate. In a pattern candidate,
As a result, presentingTheaarchitecture
unified formal
of MARPLE notation
consists of to representing
three main modules thatdesignthe classes areand
patterns organized according
interact through a common model. Joiner and Classifier are the prin- the conceptual organization of the
pattern inter-relationships will be one of the main research challengesis used in the near
in our project for DPD to
cipal modules used for DPD and represent the MARPLE-DPD module.
future. With a formal notation in hand for patterns and pattern inter-relationships, in Arcelli Fontana et al. (2012).
The Joiner represents the syst
it will be easy to develop support tools in this field.
• Information detector engine: Builds the model of the system and structures extracted by the MSD a
collects both micro-structures (through the micro-structures de- types. In this way, graph matching
tector) and metrics (through the metrics collector), storing them extraction of pattern candidates.
in the model. This module implements the first level of abstraction In particular, the Joiner uses reso
References provided by MARPLE.
• Joiner: Extracts all the potential design pattern candidates that sat-
to represent the graph. The graph
through SPARQL queries processed
isfy a given definition, working on the micro-structures extracted
[AACGJ01] Hervé Albin-Amiot, Pierreengine.
by the information detector Cointe, Y-G Guéhéneuc, and Narendra
3.3. Classifier
Jussien. Instantiating
• Classifier: and detecting
Makes inference on whether the design
groups patterns:
of classes de- Putting bits and
tected by the Joiner are (or not) realizations of design patterns.
pieces together. In Automated Software Engineering, 2001.(ASE 2001).
The Classifier evaluates the sim
This module helps to detect false positives identified by the Joiner,
Proceedings. 16th Annual International Conference on, viously166–173.
pages classified design patterns, d
and computes the similarity of the extracted patterns with known
are correct or not. It also ranks the
IEEE, 2001.
design 3 pattern implementations, expressing it in the form of a
suring the reliability of the decisio
confidence value.
different graphical views connecte
[AAG01] Hervé Albin-Amiot and Yann-Gaël Guéhéneuc. Meta-modeling inspected some
design instances, it is pos
The remainder of this section describes the Micro-structures de- incorrect. Every time new instances
patterns: Application to pattern detection and code synthesis.
tector (MSD), Joiner, and Classifier modules. them to theIn repository.
Pro- At any time
ceedings of ECOOP Workshop on Automating Object-Oriented Software
Development Methods, 2001. 3 http://www.eclipse.org/jdt/. 2

1 3
http://essere.disco.unimib.it/reverse/Marple.html. http://jena.apache.org/documentation/

[AB14] Aakash Ahmad and Muhammad Ali Babar. Towards a pattern language

9
 for self-adaptation of cloud-based architectures. In Proceedings of the
WICSA 2014 Companion Volume, page 1. ACM, 2014. 2
[AFC98] Giuliano Antoniol, Roberto Fiutem, and Luca Cristoforetti. Design pat-
tern recovery in object-oriented software. In Program Comprehension,
1998. IWPC’98. Proceedings., 6th International Workshop on, pages
153–160. IEEE, 1998. 3, 4, 5
[AFMR11] F Arcelli Fontana, Stefano Maggioni, and Claudia Raibulet. Under-
standing the relevance of micro-structures for design patterns detection.
Journal of Systems and Software, 84(12):2334–2347, 2011. 3
[AFZ11] Francesca Arcelli Fontana and Marco Zanoni. A tool for design pattern
detection and software architecture reconstruction. Information sciences,
181(7):1306–1324, 2011. 3
[AZY14] Awny Alnusair, Tian Zhao, and Gongjun Yan. Rule-based detection
of design patterns in program code. International Journal on Software
Tools for Technology Transfer, 16(3):315–334, 2014. 3, 4
[Bin12] Alexander Binun. High Accuracy Design Pattern Detection. PhD thesis,
University of Bonn, 2012. 5, 6, 7, 8, 9
[BK12] Alexander Binun and Günter Kniesel. DPJF-design pattern detec-
tion with high accuracy. In Software Maintenance and Reengineering
(CSMR), 2012 16th European Conference on, pages 245–254. IEEE,
2012. 7
[BP00] Federico Bergenti and Agostino Poggi. Improving uml designs using
automatic design pattern detection. In 12th International Conference on
Software Engineering and Knowledge Engineering (SEKE), pages 336–
343. Citeseer, 2000. 3
[CDLD+ 05] Gennaro Costagliola, Andrea De Lucia, Vincenzo Deufemia, Carmine
Gravino, and Michele Risi. Design pattern recovery by visual language
parsing. In Software Maintenance and Reengineering, 2005. CSMR 2005.
Ninth European Conference on, pages 102–111. IEEE, 2005. 3
[Don02] Jing Dong. Uml extensions for design pattern compositions. Journal of
object technology, 1(5):151–163, 2002. 3
[EBL13] Maged Elaasar, Lionel C Briand, and Yvan Labiche. VPML: an approach
to detect design patterns of MOF-based modeling languages. Software
& Systems Modeling, pages 1–30, 2013. 3, 7

10
 [EBM12] Ghizlane El Boussaidi and Hafedh Mili. Understanding design pattern-
swhat is the problem? Software: Practice and Experience, 42(12):1495–
1529, 2012. 3

[FBB+ 14] Michael Falkenthal, Johanna Barzen, Uwe Breitenbücher, Christoph

Fehling, and Frank Leymann. From pattern languages to solution imple-
mentations. In PATTERNS 2014, The Sixth International Conferences
on Pervasive Patterns and Applications, pages 12–21, 2014. 2

[FCSK03] Robert France, S Chosh, Eunjee Song, and Dae-Kyoo Kim. A meta-
modeling approach to pattern-based model refactoring. Software, IEEE,
20(5):52–58, 2003. 2

[FMR13] Francesca Arcelli Fontana, Stefano Maggioni, and Claudia Raibulet. De-
sign patterns: a survey on their micro-structures. Journal of Software:
Evolution and Process, 25(1):27–52, 2013. 3

[FZM11] Francesca Arcelli Fontana, Marco Zanoni, and Stefano Maggioni. Using
design pattern clues to improve the precision of design pattern detection
tools. Journal of Object Technology, 10(4):1–31, 2011. 3

[GA08] Y-G Guéhéneuc and Giuliano Antoniol. Demima: A multilayered ap-

proach for design pattern identification. Software Engineering, IEEE
Transactions on, 34(5):667–684, 2008. 3

[GHJV94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De-
sign Patterns: Elements of Reusable Object-Oriented Software. Addison-
Wesley Professional, 1st edition, 1994. 1, 4, 5, 7

[GJ01] Yann-Gaël Guéhéneuc and Narendra Jussien. Using explanations for

design-patterns identification. In IJCAI, volume 1, pages 57–64. Citeseer,
2001. 3

[Gué07a] Yann-Gaël Guéhéneuc. P-mart: Pattern-like micro architecture reposi-

tory. Proceedings of the 1st EuroPLoP Focus Group on Pattern Reposi-
tories, 2007. 1, 3, 4

[Gué07b] Yann-Gaël Guéhéneuc. Ptidej: A flexible reverse engineering tool suite.

In Software Maintenance, 2007. ICSM 2007. IEEE International Con-
ference on, pages 529–530. IEEE, 2007. 6, 8, 9

[HGY14] Hossam Hakeem, Hui Guan, and Hongji Yang. A framework of pat-
terns applicability in software development. In Computer Software and

11
 Applications Conference Workshops (COMPSACW), 2014 IEEE 38th
International, pages 486–491. IEEE, 2014. 3

[HHHL03] Dirk Heuzeroth, Thomas Holl, Gustav Hogstrom, and Welf Lowe. Auto-
matic design pattern detection. In Program Comprehension, 2003. 11th
IEEE International Workshop on, pages 94–103. IEEE, 2003. 3

[KB09] Günter Kniesel and Alexander Binun. Witnessing patterns: A data fu-
sion approach to design pattern detection. CS Department III, Uni.
Bonn, Germany, Technical report IAI-TR-2009-02, ISSN, pages 0944–
8535, 2009. 5

[Kim08] Dae-Kyoo Kim. Software quality improvement via pattern-based model

refactoring. In High Assurance Systems Engineering Symposium, 2008.
HASE 2008. 11th IEEE, pages 293–302. IEEE, 2008. 2

[Lan14] K Lano. Design patterns: applications and open issues. In Cyberpatterns,

pages 37–45. Springer, 2014. 2

[SFJ96] Douglas C Schmidt, Mohamed Fayad, and Ralph E Johnson. Software

patterns. Communications of the ACM, 39(10):37–39, 1996. 1

[SW08] Krzysztof Stencel and Patrycja Wegrzynowicz. Detection of diverse

design pattern variants. In Software Engineering Conference, 2008.
APSEC’08. 15th Asia-Pacific, pages 25–32. IEEE, 2008. 3

[TCSH06] Nikolaos Tsantalis, Alexander Chatzigeorgiou, George Stephanides, and

Spyros T Halkidis. Design pattern detection using similarity scoring.
Software Engineering, IEEE Transactions on, 32(11):896–909, 2006. 3

[vDMT10a] Markus von Detten, Matthias Meyer, and Dietrich Travkin. Reclipse-a
reverse engineering tool suite. Technical report, Technical Report tr-ri-
10-312, University of Paderborn, Germany, 2010. 6

[vDMT10b] Markus von Detten, Matthias Meyer, and Dietrich Travkin. Reverse
engineering with the reclipse tool suite. In Proceedings of the 32nd
ACM/IEEE International Conference on Software Engineering-Volume
2, pages 299–300. ACM, 2010. 3, 4, 6, 8, 9

[YZC15] Dongjin Yu, Yanyan Zhang, and Zhenli Chen. A comprehensive approach
to the recovery of design pattern instances based on sub-patterns and
method signatures. Journal of Systems and Software, 2015. 3, 4

12
 [Zam09] Bahman Zamani. On verifying the use of a pattern language in model
driven design. Dissertation, Concordia University, 2009. 3, 9

[ZB13] Bahman Zamani and Greg Butler. Pattern Language Verification in

Model Driven Design. Information Sciences, 237:343–355, 2013. 9

[Zdu07] Uwe Zdun. Systematic pattern selection using pattern language gram-
mars and design space analysis. Software: Practice and Experience,
37(9):983–1016, 2007. 9

[ZFS15] Marco Zanoni, Francesca Arcelli Fontana, and Fabio Stella. On applying
machine learning techniques for design pattern detection. Journal of
Systems and Software, 103:102–117, 2015. 3, 9

13

View publication stats