Design Patterns: Current Challenges, Trends, and Research … · 2020. 9. 1. · Design Patterns: Current Challenges, Trends, and Research Directions Alireza Rouhi and Bahman Zamani

TECHNICAL REPORTReport No. UI-SE-MDSERG-2015-02Date: July 13, 2016

Design Patterns: Current Challenges,Trends, and Research Directions

Alireza RouhiBahman Zamani

Department of Software EngineeringUniversity of IsfahanHezar-Jerib Ave.Isfahan

Tel: +98-31-37934537Fax: +98-31-36699529 , [email protected]

http://mdse.bahmanzamani.com/

Design Patterns: Current Challenges,Trends, and Research Directions

Alireza Rouhi and Bahman ZamaniDepartment of Software Engineering

University of IsfahanIsfahan, Iran.

{rouhi, zamani}@eng.ui.ac.ir

Abstract: Design patterns solve recurring design problems. We canclassify the literature on design patterns into two main categories:1) Pattern Application, i.e., applying design patterns on a designmodel which is a forward engineering approach, and 2) Pattern De-tection and Identification, i.e, extracting applied design patterns froma given source code which is a reverse engineering approach. Withthe above classification in mind, this report intends to explore thecurrent challenges behind the design patterns and related tools.

Design Patterns: Current Challenges,Trends and Research Directions

Alireza Rouhi and Bahman ZamaniDepartment of Software Engineering

University of IsfahanIsfahan, Iran.

{rouhi, zamani}@eng.ui.ac.ir

Abstract: Design patterns solve recurring design problems. We canclassify the literature on design patterns into two main categories:1) Pattern Application, i.e., applying design patterns on a designmodel which is a forward engineering approach, and 2) Pattern De-tection and Identification, i.e, extracting applied design patterns froma given source code which is a reverse engineering approach. Withthe above classification in mind, this report intends to explore thecurrent 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 stateof design patterns’ challenges, trends, and research directions. Based on studyingthe past and the current researches, we classify the design pattern research field intotwo broad categories: 1) design pattern application 2) design pattern detection andidentification (see Figure 1). Design Pattern Application is aimed at applying patternsolutions 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 givensource codes. As we know, a design pattern as a solution to a recurring problemhas 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 motifsin [Gué07a], i.e. the solution components of design patterns which can be extractedfrom the source code or design model in a more tangible way.

In the following, we will explore the details of these techniques through investigatingtheir practical applications and related researches and studies.

1

Design Patterns

Source CodeDesign Model

Pattern Application Pattern Detection and Identification

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 basisand techniques to aid in the systematic pattern selection and application; and littlesupport 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 modeltransformation for the application and verification of design patterns in a designmodel. Here, first a model is developed regardless of any design pattern in mind andthen in the next step, the produced model can be refactored to improve its qualitythrough the introduction of suitable design patterns. Finally, model transformationverification 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 aPattern Language (PL) recovered from the architecture adaptation log of the underlierunning 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 problemspecification against the design model, refactoring automated through transformationon 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 softwareproblems as a whole [HGY14].

2.2.1 Providing a framework for applying patterns of PLs in softwaredevelopment

Applying suitable and correct patterns of several and inter-connected PLs in practicetogether with solving a real business and practical case study have been presentedin [HGY14]. The authors in [HGY14] claims that usage of their proposed frameworkfor applying patterns not only will provide solutions to specific design problems butalso will help them on how, when, and on what order to apply patterns. The mainsteps of [HGY14] framework are (1) adapting existing patterns first, if it is possibleand 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 repeatthe 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 whichis specified by a model designer, [Zam09] verifies the used pattern structure and itsrelationships with other applied patterns through the proposed PLV modules, i.e.,lexical, syntactical and semantical verification modules. In other words, a designmodel is developed using patterns of a PL, i.e. Patterns of Enterprise ApplicationArchitecture (PofEAA), then the PLV, named ArgoPLV, verifies that whether theapplied 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 revealsmany projects which aimed at the detection and identification of the design patterns inthe existing design model or source code [AFC98, BP00, AACGJ01, AAG01, GJ01,Don02, HHHL03, CDLD+05, TCSH06, Gué07a, GA08, SW08, vDMT10b, AFZ11,AFMR11, FZM11, EBM12, EBL13, FMR13, AZY14, YZC15, ZFS15]. This is typicalbecause of the philosophy of software patterns which is to detect and identify the bestpractices 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. Ofcourse, this process is an approximate approach. Therefore, probably the detectedand identified pattern instances will be approximate and hence controversial anddebatable. Usually, two metrics are used to evaluate the pattern detection tools andmethods applicability: precision and recall. These metrics are defined in [Gué07a]as follows (Note: here, a design motif is formed from an inter-class structure whichper se is constructed with some defined micro-architectures/µA):

precision =| {true µA} ∩ {identified µA} |

| {identified µA} | (1)

recall =| {true µA} ∩ {identified µA} |

| {true µA} | (2)

Design pattern detection and identification is a reverse engineering approach whichhelps to analyze and understand the legacy code design and intentions for mainte-nance and upgrading purposes as well as transferring and reusing in between designknowledge in the development of similar projects [vDMT10b, AZY14, YZC15]. There-fore, many tools regarding pattern detection and identification have been presentedto help designers understand and analyze the details of the existing source code.

Authors in [AFC98] present a design pattern recovery process which tries to recoverfive 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 copewith the combinatorial state explosion problem of the involved classes and in be-tween relationships of the detected patterns, a multi-stage reduction technique withthe exploitation of the metrics and constraints of classes and their relations is used toreduce the matched candidates in the final result of extracted design patterns. Dueto the conservative aspect which is taken by the proposed process, it is impossible tohave the false negative results in the detected patterns. However, there maybe somefalse positive results in the recovered design patterns which needs manual inspectionto 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 thetools is static or dynamic. Furthermore, static or dynamic analysis is accomplishedstructural, considering only the structural elements of the programs or behavioralwhich takes into account the program execution traces too. Due to the important

4

AOLPatternLibrary

C++ SourceCode

Code2AOL Code AOLSpecificationsTranslator

CASETool CASE2AOL

TranslatorDesign AOL

SpecificationsOMTDesign

StructuralConstraintEvaluation

DelegationConstraintEvaluation

MetricsConstraintEvaluation

DecoratedASTAST Constraints

EvaluatorMetrics

ExtractorAOL

Parser

JAVA Engine

D

R

S

P

j

Pattern Recognizer PatternCandidates

Figure 2. Pattern Extraction Process.

with linear complexity, a candidate set for each pattern ele-ment.

In other words, letp = (< e1; : : : ; ek >;R) a pattern(with elementse1; : : : ; ek) belonging to a pattern collectionP , letMp =< m1; : : : ;mk > be the tuple of metrics char-acterizing patternp, where eachmi is an array of the met-rics listed in Section 3.2 and corresponding to each patternelement, then candidates for the elementsei are elements ofthe set:

Cidef= fxjx 2 D ^ 8mi 2Mp : 8mij 2 mi mijx � mijg

Clearly, the same design elementx could be in more thanoneCi. However, actual pattern instances are surely withinthe tuples extracted from the set collectionC1; : : : ; Cn.

To further reduce the search space, let’s choose one oftheCi sets, for example the setCmin with minimum num-ber of elements;emin (the corresponding pattern element)can be regarded as a node in a graph representing the pat-tern, where the remainingn � 1 pattern constituents mustbe reachable fromCmin elements in a number of steps con-strained by the pattern structure. Reduced candidate setsRj(y) with j 6= min, j = 1; : : : ; n andy 2 Cmin can bedefined as:

Rj(y)def= fxjx 2 D ^ ShPath(x; y) = ShPath(ej ; emin)g

whereShPath(x; y) is the shortest path between twoclassesx andy in a design, measured as the number of re-lations on the design that must be traversed to reachy fromx, independently on the nature of the relations.

Notice that, even if theoretically speaking,Rj(y) com-putation could require the all pairs shortest path compu-

tation, with cubic complexity [1], in practice, since de-sign patterns are micro-architectures, typical values forShPath(ej ; emin) are limited and usually below 4. As aconsequence the complexity observed in practical cases isalmost linear with the size ofCmin.

3.3.2 Structural and Delegation Constraints Evalua-tion

The previous stages have only imposed, for each patternconstituent, the presence of certain pattern relationships,without worrying about the exact identity of the classes in-volved in the relations.

In the last two stages, exact design pattern constraintsare applied to tuples< r1(y) : : : y : : : rn(y) > whererk(y) 2 Rk(y). In the first stage structural constraints areapplied and the setS of the candidate tuples formed withthe setsrk(y) 2 Rk(y) that satisfy those constraints is pro-duced as output. LetR = fpjp =< r1(y) : : : rn(y) > ^y 2Cmin ^ 8rk(y) 2 Rk(y)g, a tuple inS satisfies all the re-lations inRS , whereRS is a subset ofR representing allstructural relations (i.e. without delegation constraints):

Sdef= fxjx =< x1 : : : xn >2 R ^

8 r 2 RS : r(ep; es; : : : et)) r(xp; xs : : : xt)g

wherep; s andt are generic indices of a subset of patternelements that participates at a given relationr.

The setS is taken as input of the second stage in whichthe delegation constraints are checked and the final setP oftuples that satisfy also these constraints is produced as out-put of the whole process. Checking delegation constraintsinvolves verifying that a given method of a given patternconstituent actually calls a method of another pattern con-stituent. Information about calls contained in each methodis extracted from code.

Figure 2: Pattern Extraction Process [AFC98]

role of behavioral elements in the design pattern specification, the false positive rateof pattern detection results can be reduced with the combination of both static anddynamic analysis as well as structural and behavioral analysis [Bin12].

Due to the structural similarity between patterns like the Strategy and State in theGoF catalog [GHJV94], using only static analysis can increase the pattern detectionfalse positive rate. As a result, the analysis approach must take into account bothof the static and dynamic analysis in order to distinguish correctly aforementionedsimilar patterns. Following this section, we introduce some of the important andinvaluable tools in the pattern detection field.

��

What to AnalyzeStructure Behaviour

How

toan

alyz

e StaticAnalysis

(program)

types

fields and method signatures

associations, inheritance

call graph

data flow

Dynamic Analysis (traces)

object relationshipsexecution traces

object creation

��

� �

��

��

��

��

�� ! �� "�� #��

��$ �� %�� & ��

�� '��

�� #�� #�� (��#�� )�� *

• �� +�� * ��

�� #�� ,� �� #��+��-�� .��,�

• ��

�� #��

/�� 0��

�� #��

��

�� 1�� #�� #� +2�� !� /3�4� �� !,�

5�� #�� +��#�� 6�� !� 5�� ! �� 5� 7�� !, �� 8��#�� 9�� #�� +�� +,, �� #�� #�� :� �� #�� ;��#�� :� ��

Figure 3: The basic design pattern detection techniques (adapted from [KB09])

5

Source

Code

Behavioral

Patterns

Traces

Pattern

Candidates

Accepted / Rejected

Pattern Candidates

Static

Analysis

Dynamic

Analysis

Document

Process Step

Data Flow

Program

Execution

TracesStructural

Patterns

Figure 1: The pattern detection process

rithm then applies the different rules to the abstract syntaxgraph and tags parts whose structure complies to a patternwith annotations. For details we refer to [3].

Pattern Variants and Rating of Pattern CandidatesIn order to enable the recognition of different pattern vari-ants with a single specification, we introduce the conceptof additional constraints. They allow to specify conditionswhose satisfaction is desired but not mandatory to consti-tute an actual pattern instance.

For example, many patterns describe certain properties,like the visibility of an attribute or a class being abstract,which are not essential and are therefore often neglectedin implementations. Hence, we mark such constraints asadditional. This way, we detect both, candidates with andwithout the specified properties.

We use the information given by the satisfaction of ad-ditional constraints to separate reliable from less reliableresults. This is done automatically by rating each patterncandidate with a percental value that relates the number ofconstraints satisfied by a candidate to the total number ofconstraints in the corresponding pattern specification. Themore constraints are satisfied the higher is the rating value.

The rating quantifies the degree of a pattern candidate’scompliance to its specification and helps the reverse engineerto distinguish true from false positives. Moreover, a thresh-old can be set in order to display only pattern candidateswith a rating higher than the threshold.

Dynamic AnalysisThe dynamic analysis is based on traces of the pattern can-didates. To obtain these traces, the system under analysisis executed and method calls between instances of classeswhich are part of a candidate are recorded. Note that weonly trace the candidates’ behavior instead of the whole sys-tem which drastically reduces the search space for the dy-namic analysis.

The expected behavior for a given pattern is formally spec-ified with special sequence diagrams. They describe interac-tions between elements in structural patterns and determinewhich method calls may occur in which order between theclasses that participate in a pattern candidate.

During the analysis step, the traces are compared to thecorresponding behavioral patterns. For this purpose, a spe-cial automaton is automatically generated for each behav-ioral pattern. If a trace matches the pattern, it is acceptedand rejected otherwise [7].

If the majority of a candidate’s traces match the behav-ioral pattern, the candidate likely is an actual design patterninstance. If most of the traces for a candidate do not matchthe behavioral pattern, it is assumed to be a false positivewhich is only structurally similar to the actual pattern.

3. EVALUATION RESULTSWe used our prototype implementation in the Reclipse

Tool Suite to evaluate the approach by analyzing, e.g. Java’sAbstract Window Toolkit, the Java Generic Library, Eclipse’sStandard Widget Toolkit, and JUnit 3.8.2. Details on ourresults are given in [4].

We compared the analysis results of JUnit to other ap-proaches. In accordance with them we found instances ofthe Composite, Decorator and Template Method patterns.We also detected several Observer candidates, but the dy-namic analysis revealed that only one of them showed a cor-rect Observer behavior. The other candidates were falsepositives.

4. CONCLUSIONS AND FUTURE WORKIn this paper we presented our reverse engineering ap-

proach. The major advantages compared to other approachesare the combination of static and dynamic analysis for thedetection of patterns as well as its flexible, yet formal way ofstructural and behavioral pattern specification that enablesthe re-engineer to extend and adapt the specifications.

Furthermore, the approach allows to specify several struc-tural variants of a pattern at one go by means of additionalconstraints which are used to automatically rate detectedpattern candidates.

We obtained evaluation results which showed that ourapproach and its implementation are mature and efficientenough to be applied to real systems.

In the future, we plan to allow the usage of ”fuzzy” val-ues in metric-based constraints and thereby avoid metricthresholds that are hard to determine. We also want tointegrate the concept of additional constraints into the be-havioral patterns and intend to provide better support forthe interpretation of dynamic analysis results.

5. REFERENCES[1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.

Design Patterns. Addison-Wesley, 1995.

[2] M. Meyer. Pattern-based Reengineering of SoftwareSystems. In Proc. of the 13th Working Conference onReverse Engineering, pages 305–306, 2006.

[3] J. Niere, W. Schäfer, J. P. Wadsack, L. Wendehals, andJ. Welsh. Towards Pattern-Based Design Recovery. InProc. of the 24th International Conference on SoftwareEngineering, pages 338–348, 2002.

[4] M. von Detten, M. Meyer, and D. Travkin. Reclipse –A Reverse Engineering Tool Suite. Technical Reporttr-ri-10-312, University of Paderborn, Germany, 2010.

[5] M. von Detten and M. C. Platenius. ImprovingDynamic Design Pattern Detection in Reclipse with SetObjects. In Proc. of the 7th International Fujaba Days,pages 15–19, 2009.

[6] L. Wendehals. Struktur- und verhaltensbasierteEntwurfsmustererkennung (Structural and BehavioralDesign Pattern Detection). PhD thesis, University ofPaderborn, 2007. In German.

[7] L. Wendehals and A. Orso. Recognizing BehavioralPatterns at Runtime using Finite Automata. In Proc.of the 4th ICSE Workshop on Dynamic Analysis, pages33–40, 2006.

300

Figure 4: The Reclipse pattern detection process [vDMT10b]

3.1 PTIDEJ

The Pattern Trace Identification, Detection, and Enhancement in Java (PTIDEJ)1

is also a reverse engineering tool suite which contains several modules aimed at theidentification of design patterns applied in multiple source code formats specificallyprograms written in Java [Gué07b].

3.2 Reclipse

The Reclipse 2, based on the From UML to Java And Back Again (FUJABA), is areverse engineering tool suite aimed at detecting the GoF design patterns in the Javasource code has been developed as an eclipse plug-in at the University of Paderborn.This tool integrates structural analysis with a subsequent dynamic analysis to recoverdesign patterns which are similar in their structure too, such as the State and Strategydesign patterns. Figure 4 illustrates the pattern detection steps involved in the Re-clipse tool suite. Here, to have a formal and independent notation for the specificationof design patterns, a metamodel has been developed [vDMT10b, vDMT10a].

3.3 DPJF

Recently, a novel research with a relatively complete literature on the design patterndetection tools has been done by Alexander Binun at the University of Bonn [Bin12].One of the contribution of this research is presenting a tool named Detection ofPatterns by Joining Forces (DPJF)3 which is claimed that it has won the game ofprecision and recall in competing with the contemporary tools in the design patterndetection of various Java coded benchmarks (see Figure 5). Furthermore, DPJF has a

1http://www.ptidej.net/tools/2http://www.fujaba.de/projects/reengineering/reclipse.html3https://sewiki.iai.uni-bonn.de/research/dpd/dpjf/start

6

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

reasonable speed too [BK12]. To obtain qualitative pattern detection results in termsof precision and recall as well as improving the query speed, [Bin12] applies both ofstructural and behavioral analyses to detect design motifs in the source code.

A summary of the literature and state of research on the design pattern detectionand related tools are illustrated in Figure 6.

3.4 VPML

Visual Pattern Modeling Language (VPML) [EBL13] intends to detect design patternson the Meta-Object Facility (MOF)4-based modeling languages. Each pattern ismodeled using VPML. Then, the modeled pattern through mapping to a Query,View, Transformations (QVT)-R 5 transformation, runs on a given model to detect itsused pattern instances. [EBL13] claims that its presented approach with prototypingon the Eclipse detects some of the GoF design patterns [GHJV94] on the given UnifiedModeling Language (UML) models and Control Flow patterns on the given BusinessProcess Model Notation (BPMN)6 models.

4http://www.omg.org/spec/MOF/5http://www.omg.org/spec/QVT/6http://www.omg.org/spec/BPMN/

7

��

��

��

��

��

(a) Precision

��

��

��

��

��

(b) Recall

�

��

��

��

��

��

��

��

�

�

��

��

��

��

��

��

(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’ inthe table and a hole in the graph

Load + Query

��

��

��

��

��

�� 60,0 180,0 � � 600,0 50,0

!"��#��$ 1,0 6,0 2,0 17,0 55,0 4,0

!�"�� 39,3 99,2 9,0 � � 14,7

%%�� 1,6 9,3 3,0 13,1 55,1 1,3

�!�� 5,2 18,0 7,0 54,8 77,0 8,0

(a) Time for initialisation and analysis

Initialisationtime (seconds) ��

��

��

��

��

�� 2,3 4,2 2,9 � � 4,9�� 0,9 5,2 1 2 15 0,7�� 4 14 5 40 56 6�� 35 150 49 390 550 60

(b) Initialization time

Query��

��

��

��

��

�� 37,0 95,0 6,1 � � 9,8

!!�� 0,7 4,1 2,0 11,1 40,1 0,6

��"�� 1,2 4,0 2,0 14,8 21,0 2,0

(c) Pure analysis time

�

��

��

��

��

��

��

��

�

�

��

��

��

��

��

� !�"�#�$$%

�" &�'

((�

��)

(d) Time for initialisation and analysis

�

��

��

��

��

��

��

��

�

�

��

��

��

��

��

� !"�#

$$�

��%

(e) Pure analysis time

Figure 21: Response times of each tool for detecting all evaluated patterns. In the tables, the fastest time per project is red anda bomb indicates that the tool crashed on that project. In the graphs, Fujaba is not shown since it is an order of magnitudeslower than most other tools, which would have distorted the graphs. Pure analysis time is indicated only for the tools forwhich it can be measured separately.

Figure 6: The applied basic techniques of analyzed tools [Bin12]

3.5 MARPLE-DPD

Metrics and ARchitecture Reconstruction PLugin for Eclipse-Design Pattern Detec-tion (MARPLE-DPD) is a tool suite which detects design patterns in the Java sourcecodes by using machine learning techniques (see Figure 7 for more details on its ar-chitecture). After analyzing the source code and constructing the Abstract SyntaxTree (AST), the detection is performed by the other two steps named Joiner (whichcollects detected pattern instances) and Classifier (which determines the correct andincorrect detected candidate patterns).

To the best of our knowledge, none of the aforementioned tools [Gué07b, vDMT10b,Bin12] consider the relationships between detected design patterns.

4 Conclusion

In this report, we classified the state of research on design patterns into two maincategories: 1) pattern application, and 2) pattern detection and identification. Wetried to explore and present current challenges and issues regarding the aforemen-

8

104 M. Zanoni et al. / The Journal of Systems and Software 103 (2015) 102–117

public class RestrictedCreationClass {

static RestrictedCreationClass rcc;

private RestrictedCreationClass () {

...

}

}

Listing 1. Restricted creation micro pattern example.

AST

Information Detector Engine

Micro Structures Detector

Metrics Collector

Model (Serialized to

XMI)

DPD Joiner

Recognitionrules

Classifier

Java Code

EclipseJDT

Figure 1. The architecture of MARPLE.

3. MARPLE-DPD

Metrics and ARchitecture Reconstruction PLugin for Eclipse

(MARPLE)1 is our tool implementing DPD from Java source code and

other functionalities. The overall architecture of metrics and architec-

ture reconstruction plugin for eclipse (MARPLE) is depicted in Fig. 1.

DPD activities work on information extracted from the abstract syntax

trees (ASTs) of the analyzed system. This information is represented

by elements, or facts, which are called micro-structures (see Section 2),

and by metrics that have been measured inside the system. Both these

kinds of information are used to have an abstract and more consistent

view of the system, instead of directly relying on the code or on the

AST.

The architecture of MARPLE consists of three main modules that

interact through a common model. Joiner and Classifier are the prin-

cipal modules used for DPD and represent the MARPLE-DPD module.

• Information detector engine: Builds the model of the system andcollects both micro-structures (through the micro-structures de-

tector) and metrics (through the metrics collector), storing them

in the model. This module implements the first level of abstraction

provided by MARPLE.• Joiner: Extracts all the potential design pattern candidates that sat-

isfy a given definition, working on the micro-structures extracted

by the information detector engine.• Classifier: Makes inference on whether the groups of classes de-

tected by the Joiner are (or not) realizations of design patterns.

This module helps to detect false positives identified by the Joiner,

and computes the similarity of the extracted patterns with known

design pattern implementations, expressing it in the form of a

confidence value.

The remainder of this section describes the Micro-structures de-

tector (MSD), Joiner, and Classifier modules.

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

3.1. Micro-structures detector

In the micro-structures detector (MSD), micro-structures are ex-

tracted by a set of visitors parsing an AST representation of the source

code, provided by the Java development tools (JDT)2 Eclipse plugin;

each visitor supports the detection of one micro-structure, and re-

ports the found instances. The information is acquired through static

analysis and is characterized by 100% rate of precision and recall. This

value is due to the fact that these kinds of structures are meant to be

mechanically recognizable (Gil and Maman, 2005), i.e., there is always a

1-to-1 correspondence between a micro-structure and a piece (or a set

of pieces) of code, and the algorithm that detects the micro-structure

is defined in terms of the source code structure and properties. For

the complete list of supported micro-structures, see Zanoni (2012).

Different micro-structures can be recognized in a software system

using different techniques; the only constraint is that they have to re-

fer to two (or also only one) code entities in the system. Code entities

(see Section 2.1) are the central element of the representation model

exploited in MARPLE. Micro-structures are currently detected by per-

forming an exploration of the ASTs, but it is possible to exploit also

(if needed) more complex analyses, e.g., data flow analysis (Marlowe

and Ryder, 1990), dynamic analysis (Ball, 1999).

3.2. Joiner

The Joiner analyzes the information coming from the MSD to ex-

tract groups of classes from the system, where each group is a pattern

candidate. In a pattern candidate, a role is assigned to each class and

the classes are organized according to a tree structure, which models

the conceptual organization of the pattern. The same tree structure

is used in our project for DPD tools benchmarking, and explained

in Arcelli Fontana et al. (2012).

The Joiner represents the system as a graph, where the micro-

structures extracted by the MSD are the edges and the nodes are the

types. In this way, graph matching techniques can be applied for the

extraction of pattern candidates.

In particular, the Joiner uses resource description framework (RDF)

to represent the graph. The graph matching phase is implemented

through SPARQL queries processed by the Jena ARQ3 library.

3.3. Classifier

The Classifier evaluates the similarity of pattern instances to pre-

viously classified design patterns, deciding if the evaluated instances

are correct or not. It also ranks them using a confidence value mea-

suring the reliability of the decision. Instances can be inspected with

different graphical views connected to the source code. After having

inspected some instances, it is possible to evaluate them as correct or

incorrect. Every time new instances are evaluated, it is possible to add

them to the repository. At any time, the patterns in the repository can

2 http://www.eclipse.org/jdt/.3 http://jena.apache.org/documentation/query/index.html.

Figure 7: The architecture of MARPLE-DPD [ZFS15]

tioned classification. Although, there are several well known support tools to detectand identify applied patterns in the source code (like Reclipse [vDMT10b], PTIDEJ[Gué07b], DPJF [Bin12], and MARPLE-DPD [ZFS15], to name a few), lack of a uni-fied and popular formalism is one of the main obstacles on applying design patterns ingeneral [Zdu07, Zam09, ZB13]. Note that most of the current commonly used designpatterns have been presented in natural languages. Also, to the best of our knowl-edge, there is not any considerable research and supporting tools regarding patterninter-relationships in general and PLs in particular.

As a result, presenting a unified formal notation to representing design patterns andpattern inter-relationships will be one of the main research challenges in the nearfuture. With a formal notation in hand for patterns and pattern inter-relationships,it will be easy to develop support tools in this field.

References

[AACGJ01] Hervé Albin-Amiot, Pierre Cointe, Y-G Guéhéneuc, and NarendraJussien. Instantiating and detecting design patterns: Putting bits andpieces together. In Automated Software Engineering, 2001.(ASE 2001).Proceedings. 16th Annual International Conference on, pages 166–173.IEEE, 2001. 3

[AAG01] Hervé Albin-Amiot and Yann-Gaël Guéhéneuc. Meta-modeling designpatterns: Application to pattern detection and code synthesis. In Pro-ceedings of ECOOP Workshop on Automating Object-Oriented SoftwareDevelopment Methods, 2001. 3

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

9

for self-adaptation of cloud-based architectures. In Proceedings of theWICSA 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, pages153–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 patterndetection and software architecture reconstruction. Information sciences,181(7):1306–1324, 2011. 3

[AZY14] Awny Alnusair, Tian Zhao, and Gongjun Yan. Rule-based detectionof design patterns in program code. International Journal on SoftwareTools 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 Gü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 usingautomatic design pattern detection. In 12th International Conference onSoftware Engineering and Knowledge Engineering (SEKE), pages 336–343. Citeseer, 2000. 3

[CDLD+05] Gennaro Costagliola, Andrea De Lucia, Vincenzo Deufemia, CarmineGravino, and Michele Risi. Design pattern recovery by visual languageparsing. 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 ofobject technology, 1(5):151–163, 2002. 3

[EBL13] Maged Elaasar, Lionel C Briand, and Yvan Labiche. VPML: an approachto 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 Breitenbücher, ChristophFehling, and Frank Leymann. From pattern languages to solution imple-mentations. In PATTERNS 2014, The Sixth International Conferenceson 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. Usingdesign pattern clues to improve the precision of design pattern detectiontools. Journal of Object Technology, 10(4):1–31, 2011. 3

[GA08] Y-G Guéhéneuc and Giuliano Antoniol. Demima: A multilayered ap-proach for design pattern identification. Software Engineering, IEEETransactions 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-Gaël Guéhéneuc and Narendra Jussien. Using explanations fordesign-patterns identification. In IJCAI, volume 1, pages 57–64. Citeseer,2001. 3

[Gué07a] Yann-Gaël Guéhéneuc. P-mart: Pattern-like micro architecture reposi-tory. Proceedings of the 1st EuroPLoP Focus Group on Pattern Reposi-tories, 2007. 1, 3, 4

[Gué07b] Yann-Gaël Guéhé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 38thInternational, 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. 11thIEEE International Workshop on, pages 94–103. IEEE, 2003. 3

[KB09] Gü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 modelrefactoring. 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. Softwarepatterns. Communications of the ACM, 39(10):37–39, 1996. 1

[SW08] Krzysztof Stencel and Patrycja Wegrzynowicz. Detection of diversedesign 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, andSpyros 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-areverse 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. Reverseengineering with the reclipse tool suite. In Proceedings of the 32ndACM/IEEE International Conference on Software Engineering-Volume2, pages 299–300. ACM, 2010. 3, 4, 6, 8, 9

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

12

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

[ZB13] Bahman Zamani and Greg Butler. Pattern Language Verification inModel 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 applyingmachine learning techniques for design pattern detection. Journal ofSystems and Software, 103:102–117, 2015. 3, 9

13

IntroductionPattern ApplicationTransformation-based Pattern ApplicationApplying PLs in PracticeProviding a framework for applying patterns of PLs in software developmentPLVs in Model-Driven Design

Pattern Detection and IdentificationPTIDEJReclipseDPJFVPMLMARPLE-DPD

Conclusion

Documents

Design Patterns: Current Challenges, Trends, and Research … · 2020. 9. 1. · Design Patterns: Current Challenges, Trends, and Research Directions Alireza Rouhi and Bahman Zamani