Design Patterns: Current Challenges, Trends ... - Dr. Bahman Zamani

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 [email protected] 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 Detection 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 Detection 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 approach 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, motivation, 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 Detection and Identification

Pattern Application

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 knowledge 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): precision =

recall =

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

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

(1)

(2)

Design pattern detection and identification is a reverse engineering approach which helps to analyze and understand the legacy code design and intentions for maintenance and upgrading purposes as well as transferring and reusing in between design knowledge in the development of similar projects [vDMT10b, AZY14, YZC15]. Therefore, 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 objectoriented software development and design. Here, a four step process has been introduced which extracts design patterns using the structural properties of the corresponding class diagrams. The mentioned process is depicted in Figure 2. To cope with the combinatorial state explosion problem of the involved classes and in between 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. According 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 Code

Code2AOL Translator

Code AOL Specifications

Pattern Recognizer CASE Tool OMT Design

CASE2AOL Translator

Pattern Candidates

Design AOL Specifications D Metrics Constraint Evaluation AOL Parser

AST

Metrics Extractor

Decorated AST

Constraints Evaluator

Rj Structural Constraint Evaluation S

JAVA Engine

Delegation Constraint Evaluation P

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

role of behavioral in pattern the design specification, the false positive tation, with cubic complexity [1], in rate practice, since with linear complexity, a candidate elements set for each ele- pattern of pattern detection results can be reduced with combination of both static and ment. sign the patterns are micro-architectures, typical values dynamic analysis as well as structural and behavioral analysis [Bin12]. ShPath(ej ; emin ) are limited and usually below 4. A In other words, let p = (< e1 ; : : : ; ek >; R) a pattern consequence complexity practical cases (with elements Due e1 ; : :to: ; ethe ) belonging to a pattern collection like thetheStrategy andobserved State ininthe k structural similarity between patterns almostcan linear with the size of Cmin . P , let Mp =< GoF m1 ; : catalog : : ; mk >[GHJV94], be the tupleusing of metrics only charstatic analysis increase the pattern detection acterizing pattern p , where each m is an array of the metfalse positive rate.i As a result, the analysis approach must take into account both rics listed in Section and corresponding each pattern Structural and Delegation Constraints Evalu of the3.2 static and dynamic toanalysis in order 3.3.2 to distinguish correctly aforementioned element, then candidates for the elements e are elements of i this section, we introduce tion some of the important and similar patterns. Following 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 Ci fxjx 2 D ^ 8mi 2 Mp : 8mij 2 mi mijx mij g without worrying about the exact identity of the classes What to Analyze volved in the relations. Structure In the lastBehaviour two stages, exact design pattern constrai Clearly, the same design element x could be in more than are applied to tuples < r1 (y ) : : : y : : : rn (y ) > wh types Static one Ci . However, actual pattern instances are surely within call graph r ( y ) 2 R ( y ) . In the first stage structural constraints k k Analysis the tuples extracted from the set collection C1 ; : : :fields ; Cnand . method signatures data applied and the setflow S of the candidate tuples formed w (program) To further reduce the search space, let’s chooseassociations, one of inheritance r ( y ) 2 R ( the sets k k y ) that satisfy those constraints is p the Ci sets, for example the set Cmin with minimum numDynamic duced as output. Let R = fpjp =< r1 (y) : : : rn (y) > ^y execution traces ber of elements; emin (the corresponding pattern element) object relationships Analysis Cmin ^ 8rk (object y) 2creation Rk (y)g, a tuple in S satisfies all the can be regarded as a node in a graph representing the pat(traces) lations in R , where RS is a subset of R representing S tern, where the remaining n , 1 pattern constituents must structural relations (i.e. without delegation constraints): of steps 2.1.1. con- Program analyses be reachable from Cmin elements in a number Figure Figurestructure. 3: The basic design patternsets detection techniques strained by the pattern Reduced candidate S def = fxjx(adapted =< x1 : : from : xn >[KB09]) 2R ^ Rj (y) with j 6= min, j = 1; : : : ; n and y 2 Cmin can be 8 r 2 Rwith r(ep ; eindiS : 100% s ; : : : et ) ) r(xp ; xs : : : xt )g defined as: by a score. Scores are typically expressed by a percentage, cating total condence. Scores might 5be taken intop;account computing where s and twhen are generic indices of a subset of patt def Rj (y) = fxjx 2 D ^ ShPath (x; y )and = ShPath g precision recall of(epattern tools as Pettersson et al. [54 j ; emin )detection elements that participates at ]a regiven relation r. 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 tuples that satisfy also these constraints is produced as o Mosttwo pattern detection algorithms match descripclasses x and y in a design,tions measured as the number of reput of the whole process. Checking delegation constrai of the expected structure and the behaviour of sought patterns against lations on the design that must be traversedabout to reach from andinvolves verifying that elements. a given method of a given patt the information the ystructure behaviour of program Relevant program analyses can be categorized in two orthogonal dimensions, x, independently on the nature of the relations. constituent actually calls a method of another pattern co with two subcategories each: Notice that, even if theoretically speaking, Rj (y ) comstituent. Information about calls contained in each meth How to analyze

def =

GENERAL NOTIONS

9

Structural Patterns

Figure

3.1

PTIDEJ

Source Code

Traces Traces

3.

Behavioral Patterns

EVALUATION RESULTS

We used our prototype implementatio Tool Suite to evaluate the approach by an Program Static Dynamic Abstract Window Toolkit, the Java Gener Execution Analysis Analysis Standard Widget Toolkit, and JUnit 3.8 results are given in [4]. Document We compared the analysis results of J Process Step Pattern Accepted / Rejected proaches. In accordance with them we Candidates Pattern Candidates Data Flow the Composite, Decorator and Template We also detected several Observer candi Figure 1: The pattern detection process namic analysis revealed that only one of t 4: The Reclipse pattern detection process [vDMT10b] rect Observer behavior. The other can rithm then applies the different rules to the abstract syntax positives. graph and tags parts whose structure complies to a pattern with annotations. For details we refer to [3].

4.

Pattern Variants and Rating of Pattern Candidates

CONCLUSIONS AND FUT

In this paper 1we presented our rever The Pattern TraceInIdentification, Detection, Enhancement (PTIDEJ) order to enable the recognition and of different pattern vari-in Java 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 formats specifically whose satisfaction is desired but not mandatory to constistructural and behavioral pattern specific an actual programs written intute Java [Guépattern 07b]. 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 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. approach andisitsa implementation are m The Reclipse 2 , based on the From UML to Java And Back Again (FUJABA), We use the information given by the satisfaction of adenough to be applied to real systems. constraints reliable reliable reverse engineeringditional tool suite aimedtoatseparate detecting thefrom GoFless design patternsIninthethe Javawe plan to allow the us future, results. This is done automatically by rating pattern ues in metric-based constraints and the source code has been developed as an eclipse plug-in at each the University of Paderborn. candidate with a percental value that relates the number of thresholds that are hard to determine. This tool integratesconstraints structural analysis a subsequent to recover satisfied by a with candidate to the total dynamic number of analysis integrate the concept of additional const constraints in the in corresponding patterntoo, specification. The State design patterns which are similar their structure such as the 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 steps involved in the Re- of dynamic analysis re The rating quantifies the degree of a pattern candidate’s clipse tool suite. Here, to have a formal andand independent notation compliance to its specification helps the reverse engineerfor the specification 5. REFERENCES truehas frombeen false positives. Moreover, a thresh-vDMT10a]. of design patterns, to a distinguish metamodel developed [vDMT10b, [1] E. Gamma, R. Helm, R. Johnson, and old can be set in order to display only pattern candidates Design Patterns. Addison-Wesley, 199 with a rating higher than the threshold. [2] M. Meyer. Pattern-based Reengineeri Dynamic Analysis Systems. In Proc. of the 13th Workin Reverse Engineering, pages 305–306, The dynamic analysis is based on traces of the pattern candidates. To obtain these traces, the system under analysis [3] J. Niere, W. Sch¨ afer, J. P. Wadsack, Recently, a novel research with relatively complete literature on the design pattern is executed and amethod calls between instances of classes J. Welsh. Towards Pattern-Based Des partby of Alexander a candidate are recorded. Note that we of Bonn Proc.[Bin12]. of the 24th International Confe detection tools has which been are done Binun at the University only trace the candidates’ behavior instead of the whole sysEngineering, pages 338–348, 2002. One of the contribution of this research is presenting a tool named Detection of tem which drastically reduces the search space for the dy[4] M. von Detten, M. Meyer, and D. Tra Patterns by Joining Forces (DPJF)3 which is claimed that it has won the gameEngineering of namic analysis. A Reverse Tool Suite. Te The expected behavior for a given pattern is formally spectr-ri-10-312, University of Paderborn, precision and recall in competing with the contemporary tools in the design pattern ified with special sequence diagrams. They describe interac[5] M. von Detten and M. C. Platenius. I detection of varioustions Java codedelements benchmarks (seepatterns Figureand 5).determine Furthermore, DPJF has a between in structural 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 spehttps://sewiki.iai.uni-bonn.de/research/dpd/dpjf/start Entwurfsmustererkennung (Structural cial automaton is automatically generated for each behavDesign 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 behavPatterns 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.

3.2

Reclipse

3.3

DPJF

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/ http://www.omg.org/spec/QVT/ 6 http://www.omg.org/spec/BPMN/ 5

7

&ƵũĂďĂ W/EKd Wd/: ^^ W:&

ϵ ϭϴ ϮϬ ϱϭ ϭϬϬ

ϭϬ ϵ ϭϱ ϲϯ ϭϬϬ

y y y ϳϴ ϯϰ ϭϰ Ϯϰ ϯϯ Ϭ ϳϬ y ϴϬ ϭϬϬ ϭϬϬ ϭϬϬ


ϭϬ ϭϴ ϮϬ ϲϲ ϭϬϬ

ϯϯ ϱϬ ϯϯ ϰϯ ϲϳ

(a) Precision

ϰϳ ϭϯ ϭϴ ϱϮ ϲϱ

y ϯϭ ϭϮ ϰϰ ϴϵ

y Ϯϰ ϭϴ y ϵϮ

y ϭϴ Ϭ Ϯϰ ϵϲ

ϰϬ Ϯϰ ϭϴ ϰϰ ϴϵ

(b) Recall

ϭϬϬ

ϭϬϬ ϵϬ ϴϬ ϳϬ ϲϬ ϱϬ ϰϬ ϯϬ ϮϬ ϭϬ Ϭ

ϵϬ ϴϬ ϳϬ ϲϬ

&ƵũĂďĂ

ϱϬ

W/EKd

ϰϬ

Wd/:

ϯϬ ϮϬ

^^

ϭϬ

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 6: The applied basic techniques of analyzed tools [Bin12] the table and a holeFigure in the graph

3.5

MARPLE-DPD

Metrics and ARchitecture Reconstruction PLugin for Eclipse-Design Pattern DetecInitialisation ƌŐŽ dĞĂŵ :,ϲ :ĂǀĂ/K td time (seconds) tion (MARPLE-DPD) is a tool suite:,ϱ which detects design hD> ŽƌĞpatterns in the Java source WƚŝĚĞũ 2,3 4,2 2,9 4,9 codes by using machine learning techniques (see 7 for more details on its ar^^ 0,9 5,2 1 2Figure 15 0,7 4 14 5 40 56 6 chitecture). After analyzingW:&ƌĞƐƚĂƌƚ the source code and constructing the Abstract Syntax W:&ĨŝƌƐƚƐƚĂƌƚ 35 150 49 390 550 60 Tree (AST), theanddetection is performed by the time other two steps named(c) Joiner (which (a) Time for initialisation analysis (b) Initialization Pure analysis time collects detected pattern instances) and Classifier (which determines the correct and ϭϬϬ ϭϬϬ incorrect detected candidate patterns). ϵϬ ϵϬ Load + Query

&ƵũĂďĂ

WŝŶŽƚ;ĂůůͿ

ůůĞǀĂůƵĂƚĞĚƉĂƚƚĞƌŶƐ

:,ϱ

:,ϲ :ĂǀĂ/K

60,0

180,0

1,0

6,0

2,0

td

ƌŐŽ hD>

dĞĂŵ ŽƌĞ

600,0

50,0

17,0

55,0

ůůĞǀĂůƵĂƚĞĚ ƉĂƚƚĞƌŶƐ

Query

:,ϱ

4,0

:,ϲ :ĂǀĂ/K

td

ƌŐŽ hD>

dĞĂŵ ŽƌĞ 9,8

WƚŝĚĞũ

39,3

99,2

9,0

14,7

WƚŝĚĞũ

37,0

95,0

6,1

^^

1,6

9,3

3,0

13,1

55,1

1,3

^^

0,7

4,1

2,0

11,1

40,1

0,6

W:&

5,2

18,0

7,0

54,8

77,0

8,0

W:&

1,2

4,0

2,0

14,8

21,0

2,0

ϴϬ

ϴϬ

ϳϬ best of our knowledge, none of the aforementioned ϳϬ To the tools [Gué07b, vDMT10b, WŝŶŽƚ;ĂůůͿ ϲϬ ϲϬ ϱϬ consider the relationships between ϱϬ Bin12] detected design patterns. WƚŝĚĞũ

4

ϰϬ ϯϬ ϮϬ ϭϬ Ϭ

ϰϬ ϯϬ ϮϬ ϭϬ Ϭ

^^ W:&

Conclusion :,ϱ

:,ϲ

:ĂǀĂ/K

td

ƌŐŽ hD>

dĞĂŵ ŽƌĞ

^^ W:&

:,ϱ

(d) Time for initialisation and analysis

WƚŝĚĞũ

:,ϲ

:ĂǀĂ/K

td

ƌŐŽ hD>

dĞĂŵ ŽƌĞ

(e) Pure analysis time

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

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

Information Detector Engine Eclipse JDT

3.1. Micro-structures detector

In the micro-structures detecto tracted by a set of visitors parsing a code, provided by the Java develo each visitor supports the detectio DPD Joiner ports the found instances. The info analysis and is characterized by 10 Model Recognition value is due to the fact that these k (Serialized to rules mechanically recognizable (Gil and M XMI) 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 (see Section 2.1) are the central ele tioned classification. Although, there are several well known support tools to detect Metrics and ARchitecture Reconstruction PLugin for Eclipse exploited in MARPLE. Micro-struct 1 is our and identify applied patterns intool the source code (likeJava Reclipse [vDMT10b], PTIDEJ implementing DPD from source code and (MARPLE) forming an exploration of the AST other functionalities. The overall architecture of metrics and architec[Gué07b], DPJF [Bin12], and MARPLE-DPD [ZFS15], to name a few), (iflack of amore uni-complex analyses needed) 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 design indynamic analysi DPD activities work on information extracted from the abstract syntax general [Zdu07, Zam09, ZB13]. that most the current commonly used design trees (ASTs) of the Note analyzed system. Thisof information is represented 3.2. Joiner by elements, or facts, which are called micro-structures (see Section patterns have been presented in natural languages. Also, to the 2), best of our knowland by metrics that have been measured inside the system. Both these The Joiner analyzes the inform edge, there is not kinds any ofconsiderable research and supporting tools regarding pattern information are used to have an abstract and more consistent tract groups of classes from the sys of the system, of directly relying on the code or on the inter-relationships view in general andinstead PLs in particular. candidate. In a pattern candidate, AST. classes areand organized according Theaarchitecture of MARPLE consists of to three main modules that As a result, presenting unified formal notation representing designthe patterns the conceptual organization of the interact through a common model. Joiner and Classifier are the prinpattern 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. in Arcelli Fontana et al. (2012). future. With a formal notation in hand for patterns and pattern inter-relationships, 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 detypes. 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 provided by MARPLE. to represent the graph. The graph • Joiner: Extracts all the potential design pattern candidates that satthrough SPARQL queries processed isfy a given definition, working on the micro-structures extracted [AACGJ01] Hervé Albin-Amiot, Pierreengine. Cointe, Y-G Guéhéneuc, and Narendra by the information detector 3.3. Classifier • Classifier: Makes inference on whether the groups patterns: of classes de- Putting bits and Jussien. Instantiating and detecting design 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, viously166–173. classified design patterns, d Proceedings. 16th Annual International Conference on, pages and computes the similarity of the extracted patterns with known are correct or not. It also ranks the design 3 pattern implementations, expressing it in the form of a IEEE, 2001. suring the reliability of the decisio confidence value. different graphical views connecte inspected some instances, it is pos [AAG01] Hervé Albin-Amiot and Yann-Gaël Guéhéneuc. Meta-modeling design incorrect. Every time new instances The remainder of this section describes the Micro-structures depatterns: Application to pattern detection and code synthesis. In repository. Pro- At any time them to the tector (MSD), Joiner, and Classifier modules.

Java Code

Micro Structures Detector

AST

Metrics Collector

References

ceedings of ECOOP Workshop on Automating Object-Oriented Software Development Methods, 2001. 3 http://www.eclipse.org/jdt/. 2

1

http://essere.disco.unimib.it/reverse/Marple.html.

3

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 pattern 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. Understanding 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¨ unter Kniesel. DPJF-design pattern detection 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 patternswhat is the problem? Software: Practice and Experience, 42(12):1495– 1529, 2012. 3 [FBB+ 14] Michael Falkenthal, Johanna Barzen, Uwe Breitenb¨ ucher, Christoph Fehling, and Frank Leymann. From pattern languages to solution implementations. 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 metamodeling approach to pattern-based model refactoring. Software, IEEE, 20(5):52–58, 2003. 2 [FMR13] Francesca Arcelli Fontana, Stefano Maggioni, and Claudia Raibulet. Design 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 approach 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. Design Patterns: Elements of Reusable Object-Oriented Software. AddisonWesley 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 repository. Proceedings of the 1st EuroPLoP Focus Group on Pattern Repositories, 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 Conference on, pages 529–530. IEEE, 2007. 6, 8, 9 [HGY14] Hossam Hakeem, Hui Guan, and Hongji Yang. A framework of patterns 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. Automatic design pattern detection. In Program Comprehension, 2003. 11th IEEE International Workshop on, pages 94–103. IEEE, 2003. 3 [KB09] G¨ unter Kniesel and Alexander Binun. Witnessing patterns: A data fusion 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-ri10-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 grammars 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