Multi-Language Detection of Design Pattern Instances

Filipe F. Correia; Hugo Andrade; Jo\~ao Bispo

REVIEW 3 major objections 5 minor 35 references

Multi-Language Detection of Design Pattern Instances

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Design-pattern detection spans Java and C++ on one virtual AST

desk verdict A real engineering artifact with a clear architecture, but the headline performance claim rests on unlabeled raw counts and needs to be tempered or re-evaluated. read the letter →

arxiv 2506.03903 v2 pith:TSEQHN6W submitted 2025-06-04 cs.SE

Hugo Andrade , João Bispo , Filipe F. Correia This is my paper

classification cs.SE

keywords sourcecodeanalysismulti-languagedesignpatterndetectionLARAvirtualASTDP-COREJavaC++

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that design-pattern detection can be made multi-language without sacrificing accuracy. It re-implements the Java-only DP-CORE detector on LARA's shared virtual AST, extends that AST to C/C++, and reports that the reimplementation matches or improves on the original on ten Java projects while detecting the same instances on equivalent Java and C++ snippets. If the claim holds, a software team with a mixed Java and C++ codebase can run one detection tool instead of maintaining several, and adding a new object-oriented language reduces to mapping its AST onto the shared model. The paper also asserts that this architecture lowers the effort of extending and maintaining the tool compared with other multi-language detectors.

What carries the argument

The central object is the LARA Common Language join point model: a shared virtual AST of 15 join points and 21 attributes, including Class, Interface, Method, and Call. The AstMethods interface is the bridge that maps each language compiler's concrete AST nodes onto these join points. Detection itself uses DP-CORE's UML-based pattern definitions, which express abstraction types (Normal, Abstract, Interface, Abstracted, Any) and six directional connection types (inherits, has, references, creates, uses, calls), and then applies a recursive matching algorithm once on the shared model, independent of the source language.

What would settle it

Run DP-LARA and DP-CORE on a corpus with expert-annotated pattern instances for all six pattern definitions, with a comparable annotated C++ corpus, and compute precision and recall; if DP-LARA's extra detections are mostly false positives, or if its C++ detections diverge on a direct port of a Java project known to contain the patterns, the paper's central claim would be refuted.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a multi-language detection tool built on a language-agnostic AST need not be weaker than a language-specific one. DP-LARA reproduces DP-CORE's detections on all test snippets, produces close counts on ten Java projects, and after inspection of the differences the authors conclude that DP-LARA has a better implementation of DP-CORE's key concepts than the original, because it handles inner classes, filters static members, resolves full class names, and captures chained method calls. The same extraction and detection logic then runs on C/C++ through the shared virtual AST, giving cross-language consistency.

Load-bearing premise

The whole result rests on the premise that the shared virtual syntax tree keeps the meaning of DP-CORE's six connection types intact for Java and C/C++ despite C/C++ having no native interface, and that matching raw instance counts against DP-CORE is a fair test of detection quality.

Editorial extensions

If this is right

A single DP-LARA pass can analyze a mixed Java and C/C++ codebase, because detection runs on the shared virtual AST rather than on language-specific syntax.
Adding a new object-oriented language to DP-LARA only requires mapping that language's AST to the common join points and implementing the AstMethods navigation methods; the detection algorithm and pattern definitions are reused unchanged.
Writing a new design-pattern definition, or editing an existing one, is done in DP-CORE's UML-based representation language without touching the extraction code.
The extraction fixes DP-LARA makes over DP-CORE, such as inner-class traversal, static-member filtering, full-name resolution, and call-chain handling, apply to both Java and C++, so the C++ support inherits them.
The paper's consistency experiment indicates that the same pattern instances appear in closely ported Java and C++ projects, but the direct evidence is a single Observer detection.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An implication the authors leave implicit is that LARA Common Language can host multiple language-agnostic code-analysis tools, not just pattern detection, since metrics extraction already shares the same abstraction layer.
The raw-count comparison against DP-CORE is not a precision/recall measurement; a fair test would require expert-annotated ground truth for all six patterns in each language, which the paper does not provide.
Because the authors note that context changes between LARA Common Language and compiler-specific join points are expensive, and the detection logic runs as JavaScript on GraalVM, the architecture's practical ceiling may be interpreter overhead rather than the detection algorithm.
A concrete way to test the extensibility claim would be to add support for a language with no LARA compiler, such as C#, and measure the time and code required; the paper's comparison with other tools is inferred from documentation rather than measured.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

First thing to know: this is a legit engineering paper that ports DP-CORE onto LARA's virtual AST and demonstrates design-pattern detection in Java and C++ with a single algorithm. The architecture is sensible and the code is shipped. Second thing: the headline claim that DP-LARA has better detection performance than DP-CORE is not supported by the evidence. The comparison in Section 4.2 is raw instance counts on unlabeled projects; extra detections are never checked against ground truth. The only labeled-ish experiment, the JUnit/CppUnit consistency check, turned up a single likely-false-positive Observer. So the evidence supports "roughly equivalent output with some interpretable differences," not "better."

What's genuinely good: the detection-range experiments match DP-CORE on the Java snippets and convincingly show the tool fires on C++ snippets from Refactoring.Guru. The architecture section is concrete about the Common Language join point model and AstMethods, and the discussion of implementation differences (inner classes, static methods, naming) is a useful list of real pitfalls. Using P-MARt projects gives a common baseline for future work.

The soft spots are all in the evaluation section. The raw-count comparison conflates detection with correctness. For Nutch Builder, 25 vs 56 could mean DP-LARA finds more real instances, or it could mean it floods on false positives; the paper doesn't tell us. Section 4.2 admits labels are missing and then proceeds to claim superiority anyway. That's a logical gap. The consistency experiment is too small to carry the weight: one pattern, one instance, and the paper itself identifies it as a false positive. The extensibility comparison in 4.4 relies on inferred effort from other papers' documentation, which is weak but forgivable as a qualitative argument. The circularity concern is real but not fatal: since DP-LARA is a port, matching DP-CORE is a consistency check, not an external benchmark. That still has value.

Who's this for? People building multi-language static analysis tools or using LARA. DPD specialists will want a labeled benchmark before trusting the performance claims. The paper deserves a serious referee because it's a real system with reproducible artifacts and an honest discussion of threats; the right outcome is a revision that either tempers the claims or adds a labeled evaluation.

Recommendation: send it to peer review, but insist the performance claims be reworded to match the evidence.

Referee Report

3 major / 5 minor

Summary. The paper presents DP-LARA, a design-pattern detection tool that reimplements DP-CORE's rule-satisfaction algorithm on top of LARA's common virtual AST, aiming to support Java and C/C++ with one detection engine. The evaluation consists of a detection-range test on Java and C++ snippets, a raw-instance-count comparison against DP-CORE on ten Java projects, a consistency experiment on JUnit/CppUnit and CppUnit 1.12, and a qualitative extensibility comparison with other multi-language DPD tools. The authors conclude that a multi-language approach does not compromise detection performance and that DP-LARA improves on DP-CORE's implementation.

Significance. The architecture is a plausible route to multi-language DPD: the LARA Common Language and AstMethods interface localize language-specific work, and the public repositories, pattern definitions, and configuration files make the experiments reproducible. The detection-range results on curated snippets and the JUnit/CppUnit consistency check are useful sanity checks. However, the central performance claim, namely that DP-LARA has better design-pattern detection performance than DP-CORE, is not supported by the evidence as presented; the evaluation compares raw counts without labeled ground truth, and the strongest independent validation is a single false-positive Observer instance. The extensibility argument is qualitative and inferred from other tools' documentation. The contribution is best framed as a reproducible multi-language reimplementation with identified improvements in specific extraction behaviors, not as a demonstrated precision/recall improvement.

major comments (3)

[§4.2, Tables 4 and 5] The claim that DP-LARA has better design-pattern detection performance than DP-CORE is not established by raw instance counts. The paper itself states that "the comparison of their detection performance is assessed by the raw detection results, whether they are correct or incorrect instances" (Section 4.2), and Tables 4 and 5 show large differences such as AWT Abstract Factory 12 vs. 41 and Nutch Builder 25 vs. 56. Without exhaustive labeling of detected instances, extra detections cannot be distinguished from additional false positives; the only consistency experiment in Section 4.3 found one Observer instance that the paper identifies as likely false positive. Because DP-CORE is the algorithm being ported, raw-count agreement is a consistency check rather than an external benchmark. I recommend either computing precision/recall on a labeled subset (e.g., using P-MARt annotations where they cover the six patterns, or manually labeling a sample of detections) or revising the conclusion to claim that DP-LARA is a faithful multi-language reimplementation whose differences from DP-CORE correspond to identified extraction bugs.
[§3.3, §4.3] The cross-language semantic-preservation claim is under-supported. Section 3.3 notes that C/C++ has no direct Interface counterpart and that "the altered definitions of abstraction types needed to be verified" when mapping AST nodes, but no verification of that mapping is reported. The consistency experiment in Table 6 yields exactly one Observer instance, which the paper calls a false positive, and Table 7 shows a later C++ version detecting two Command instances without a symmetric Java version for comparison. A concrete mapping-validation step is needed before claiming that the virtual AST preserves DP-CORE's semantics across languages; for example, the authors could inspect the mapped abstraction types and connection types for the C++ snippets in Table 3 or evaluate against a labeled C++ corpus.
[§4.4, Table 8] The extensibility comparison is qualitative and inferred from other publications, and the paper explicitly states that the other tools' code bases were not obtained. Table 8's tasks are not measured effort, and counts such as "58 methods" for SoulJAVA versus "15 join points + 21 attributes" for DP-LARA do not account for the complexity or correctness of those methods. The conclusion that less effort is required is plausible but not empirically demonstrated. I suggest presenting Section 4.4 explicitly as an architectural argument, or supplementing it with a reproducible extension exercise, such as adding support for another LARA-compliant language and reporting the measured changes.

minor comments (5)

[§3.3, bullet list] The connection-type description is labeled "Uses connection" twice; the second entry, which is based on Call join points, should be "Calls connection" to match Table 1.
[Figure 1] The caption says the file defines the Abstract Factory design pattern, but the displayed pattern definition is for Observer; the caption or the figure should be corrected.
[Table 2] The repeated "DP-C"/"DP-L" symbols with line breaks are difficult to read; a matrix with explicit checkmarks and a legend would be clearer.
[Throughout] There are systematic spacing typos such as "T able", "T o", "Y et", and "V iew" that should be corrected.
[§4.2] The term "detection performance" is used before the paper acknowledges that the selected projects do not support precision/recall measurement; the terminology should be aligned with what is actually measured, namely raw detection counts.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the evaluation is self-referential but does not reduce the central claims to their inputs.

full rationale

The paper does not derive its detections from the definitions it feeds in. DP-LARA ports DP-CORE's six connection types and UML-style pattern definitions onto LARA's virtual AST, then independently compares DP-LARA's output with DP-CORE on shared projects. That comparison is a consistency check against the reimplemented reference, not a construction that forces the conclusion. The 'better detection performance' claim in Section 4.2 rests on interpreting raw count differences as fixes to DP-CORE's parsing limitations, e.g., the paper states that DP-CORE does not filter static methods, has 'full naming' conflicts, and mis-handles inner classes, while DP-LARA 'properly handle[s]' them. This is an evidentiary weakness because no labeled ground truth is used, but it is not circular: the conclusion is an interpretation of observed differences, not an equation that reduces to the input. Section 4.3 even identifies the single shared Observer instance as 'one (false positive) instance', which undercuts any claim that outputs were tuned to match a desired result. The self-citations to LARA [3], the LARA Common Language [32], and the LARA compilers [29,30] are prior infrastructure with public repositories; DP-LARA is built on that infrastructure, but the cited work is independent of the present paper's claims and is not invoked to forbid alternatives or to prove the detection results. Thus no step exhibits the required reduction, and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no free numerical parameters and no new physical entities. The central claims rest on the fidelity of the virtual-AST mapping and on evaluation assumptions; these are captured as domain assumptions below.

assumptions (3)

domain assumption DP-CORE's detection algorithm and pattern definitions are preserved in the LARA port.
Section 3.3 says the steps were 're-implemented in LARA' and Section 4.2 attributes differences to extraction, but no independent check verifies algorithm equivalence on a labeled corpus.
domain assumption The LARA Common Language join point model preserves the six connection types across Java and C++.
Section 3.3 maps each connection type to common join points; C++ lacks a direct Interface, so the mapping's semantic fidelity is load-bearing for consistency across languages.
ad hoc to paper Raw DP instance counts on unlabelled projects are a sufficient proxy for detection performance.
Section 4.2 compares only counts against DP-CORE and avoids precision/recall because the chosen projects are not fully labeled; the central 'does not compromise performance' claim depends on this proxy.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Multi-Language Detection of Design Pattern Instances." pith.science (2026). https://pith.science/paper/TSEQHN6W

@misc{pith2026250603903,
  author       = {Pith},
  title        = {Pith review of: Multi-Language Detection of Design Pattern Instances},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TSEQHN6W}},
  note         = {Machine review of arXiv:2506.03903}
}

read the original abstract

Code comprehension is often supported by source code analysis tools which provide more abstract views over software systems, such as those detecting design patterns. These tools encompass analysis of source code and ensuing extraction of relevant information. However, the analysis of the source code is often specific to the target programming language. We propose DP-LARA, a multi-language pattern detection tool that uses the multi-language capability of the LARA framework to support finding pattern instances in a code base. LARA provides a virtual AST, which is common to multiple OOP programming languages, and DP-LARA then performs code analysis of detecting pattern instances on this abstract representation. We evaluate the detection performance and consistency of DP-LARA with a few software projects. Results show that a multi-language approach does not compromise detection performance, and DP-LARA is consistent across the languages we tested it for (i.e., Java and C/C++). Moreover, by providing a virtual AST as the abstract representation, we believe to have decreased the effort of extending the tool to new programming languages and maintaining existing ones.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

35 extracted references · 33 canonical work pages

[1]

What Do We Know about the Eﬀectiveness of Software Design Patterns?

Zhang C, Budgen D. What Do We Know about the Eﬀectiveness of Software Design Patterns?. IEEE Transactions on Software Engineering2012; 38(5): 1213-1231. doi: 10.1109/TSE.2011.79

work page doi:10.1109/tse.2011.79 2011
[2]

Live software documentation of design pattern instances

Lemos F, Correia FF, Aguiar A, Queiroz PG. Live software documentation of design pattern instances. PeerJ Computer Science2024; 10: e2090

work page
[3]

Aspect composition for multiple target languages using LARA

Pinto P , Carvalho T, Bispo J, Ramalho MA, Cardoso JM. Aspect composition for multiple target languages using LARA. Computer Languages, Systems & Structures 2018; 53: 1-26. doi: https:/ /doi.org/10.1016/j.cl.2017.12.003

work page doi:10.1016/j.cl.2017.12.003 2018
[4]

Design pattern detection approaches: a systematic review of the literature

Y arahmadi H, Hasheminejad SMH. Design pattern detection approaches: a systematic review of the literature. Artiﬁcial Intelligence Review 2020; 53. doi: 10.1007/s10462-020-09834-5

doi:10.1007/s10462-020-09834-5 2020
[5]

DP-CORE: A Design Pattern Detection T ool for Code Reuse

Diamantopoulos T, Noutsos A, Symeonidis A. DP-CORE: A Design Pattern Detection T ool for Code Reuse. In: ; 2016

work page 2016
[6]

Reverse Engineering of Design Patterns from Java Source Code

Shi N, Olsson R. Reverse Engineering of Design Patterns from Java Source Code. In: ; 2006: 123-134

work page 2006
[7]

Handling large search space in pattern-based reverse engineering

Niere J, Wadsack J, Wendehals L. Handling large search space in pattern-based reverse engineering. In: ; 2003: 274-279

work page 2003
[8]

Automatic design pattern detection

Heuzeroth D, Holl T, Hogstrom G, Lowe W. Automatic design pattern detection. In: ; 2003: 94-103

work page 2003

Show all 35 references

[9]

Design patterns for object-oriented software development

Pree W. Design patterns for object-oriented software development. ACM Press/Addison-Wesley Publishing Co. . 1995

1995
[10]

JFREEDOM: a Reverse Engineering T ool to Recover Framework Design

Flores N, Aguiar A. JFREEDOM: a Reverse Engineering T ool to Recover Framework Design. Proceedings of the 6th European Conference on Object-Oriented Programming 2005

2005
[11]

Design Pattern Detection by Using Meta Patterns

Hayashi S, Katada J, Sakamoto R, Kobayashi T, Saeki M. Design Pattern Detection by Using Meta Patterns. IEICE Transactions 2008; 91-D: 933-944. doi: 10.1093/ietisy/e91-d.4.933

2008 doi
[12]

Feature Maps: A Comprehensible Software Representation for Design Pattern Detection

Thaller H, Linsbauer L, Egyed A. Feature Maps: A Comprehensible Software Representation for Design Pattern Detection. In: ; 2019: 207-217

2019
[13]

Feature-based software design pattern detection

Nazar N, Aleti A, Zheng Y. Feature-based software design pattern detection. Journal of Systems and Software 2022; 185: 111179. doi: https:/ /doi.org/10.1016/j.jss.2021.111179

2022
[14]

Source code and design conformance, design pattern detection from source code by classiﬁcation approach

Chihada A, Jalili S, Hasheminejad SMH, Zangooei MH. Source code and design conformance, design pattern detection from source code by classiﬁcation approach. Applied Soft Computing 2015; 26: 357-367. doi: https:/ /doi.org/10.1016/j.asoc.2014.10.027

2015 doi
[15]

Software Metrics and tree-based machine learning algorithms for distinguishing and detecting similar structure design patterns

Mhawish M, Gupta M. Software Metrics and tree-based machine learning algorithms for distinguishing and detecting similar structure design patterns. SN Applied Sciences 2020; 2: 11. doi: 10.1007/s42452-019-1815-3

2020 doi
[16]

Design Pattern Detection using inexact graph matching

Gupta M, Rao RS, T ripathi AK. Design Pattern Detection using inexact graph matching. In: ; 2010: 211-217

2010
[17]

Design pattern mining using greedy algorithm for multi-labelled graphs

Gupta M. Design pattern mining using greedy algorithm for multi-labelled graphs. IJICT 2011; 3: 314-323. doi: 10.1504/IJICT.2011.043627

2011 arXiv
[18]

Design Pattern Detection by normalized cross correlation

Gupta M, Pande A, Rao RS, T ripathi A. Design Pattern Detection by normalized cross correlation. In: ; 2010: 81-84

2010
[19]

Design Pattern Detection Using Dpdetect Algorithm

Singh J, Gupta M. Design Pattern Detection Using Dpdetect Algorithm. International Journal of Innovative T echnology and Exploring Engineering 2019. 20 HUGO ANDRADE et al

2019
[20]

Detecting design patterns: a hybrid approach based on graph matching and static analysis

Singh J, Chowdhuri SR, Bethany G, Gupta M. Detecting design patterns: a hybrid approach based on graph matching and static analysis. Information T echnology and Management2021. doi: 10.1007/s10799-021-00339-3

doi
[21]

Design Pattern Detection Using Similarity Scoring

T santalis N, Chatzigeorgiou A, Stephanides G, Halkidis ST. Design Pattern Detection Using Similarity Scoring. IEEE Transactions on Software Engineering 2006; 32(11): 896-909. doi: 10.1109/TSE.2006.112

2006 doi
[22]

Design Pattern Detection by T emplate Matching

Dong J, Sun Y. Design Pattern Detection by T emplate Matching. In: ; 2008: 765-769

2008
[23]

Enhancing Software Evolution through Design Pattern Detection

Arcelli F, Cristina L. Enhancing Software Evolution through Design Pattern Detection. In: ; 2007: 7-14

2007
[24]

NET Reverse Engineering with MARPLE

Arcelli F, Franzosi D, Raibulet C. .NET Reverse Engineering with MARPLE. In: ; 2010: 227-231

2010
[25]

Language-independent detection of object-oriented design patterns

Fabry J, Mens T. Language-independent detection of object-oriented design patterns. Computer Languages, Systems & Structures 2004; 30(1): 21-33. Smalltalk Languagedoi: https:/ /doi.org/10.1016/j.cl.2003.09.002

2004 doi
[26]

Programming language neutral design pattern detection

Nagy A, Kovari B. Programming language neutral design pattern detection. In: ; 2015: 215-219

2015
[27]

CrocoPat: A T ool for Eﬃcient Pattern Recognistion in Large Object Oriented Programs

Beyer D, Lewerentz C. CrocoPat: A T ool for Eﬃcient Pattern Recognistion in Large Object Oriented Programs. Citeseer . 2003

2003
[28]

Design Patterns Detection Using a DSL-driven Graph Matching Approach

Bernardi M, Cimitile M, Di Lucca G. Design Patterns Detection Using a DSL-driven Graph Matching Approach. Journal of Software: Evolution and Process 2014; in press. doi: 10.1002/smr.1674

2014 doi
[29]

Clava: C/C++ source-to-source compilation using LARA

Bispo J, Cardoso JM. Clava: C/C++ source-to-source compilation using LARA. SoftwareX 2020; 12: 100565

2020
[30]

A DSL-based runtime adaptivity framework for Java

Carvalho T, Bispo J, Pinto P , Cardoso JM. A DSL-based runtime adaptivity framework for Java. SoftwareX 2023; 23: 101496

2023
[31]

Compilation of MATLAB computations to CPU/GPU via C/OpenCL generation

Reis L, Bispo J, Cardoso JM. Compilation of MATLAB computations to CPU/GPU via C/OpenCL generation. Concurrency and Computation: Practice and Experience 2020; 32(22): e5854

2020
[32]

Multi-Language Static Code Analysis on the LARA Framework

T eixeira G, Bispo J, Correia FF . Multi-Language Static Code Analysis on the LARA Framework. In: SOAP 2021. Association for Computing Machinery; 2021; New Y ork, NY, USA: 31–36

2021
[33]

P-MARt: Pattern-like Micro Architecture Repository

Guéhéneuc YG. P-MARt: Pattern-like Micro Architecture Repository. 1st EuroPLoP Focus Group on Pattern Repositories 2007

2007
[34]

A logic meta-programming approach to support the co-evolution of object-oriented design and implementation

Wuyts R. A logic meta-programming approach to support the co-evolution of object-oriented design and implementation . PhD thesis. PhD thesis, Vrije Universiteit Brussel, ; 2001

2001
[35]

DeMIMA: A Multilayered Approach for Design Pattern Identiﬁcation

Guéhéneuc YG, Antoniol G. DeMIMA: A Multilayered Approach for Design Pattern Identiﬁcation. IEEE Transactions on Software Engineering 2008; 34(5): 667-684. doi: 10.1109/TSE.2008.48

2008 doi

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

What Do We Know about the Eﬀectiveness of Software Design Patterns?

Zhang C, Budgen D. What Do We Know about the Eﬀectiveness of Software Design Patterns?. IEEE Transactions on Software Engineering2012; 38(5): 1213-1231. doi: 10.1109/TSE.2011.79

work page doi:10.1109/tse.2011.79 2011

[2] [2]

Live software documentation of design pattern instances

Lemos F, Correia FF, Aguiar A, Queiroz PG. Live software documentation of design pattern instances. PeerJ Computer Science2024; 10: e2090

work page

[3] [3]

Aspect composition for multiple target languages using LARA

Pinto P , Carvalho T, Bispo J, Ramalho MA, Cardoso JM. Aspect composition for multiple target languages using LARA. Computer Languages, Systems & Structures 2018; 53: 1-26. doi: https:/ /doi.org/10.1016/j.cl.2017.12.003

work page doi:10.1016/j.cl.2017.12.003 2018

[4] [4]

Design pattern detection approaches: a systematic review of the literature

Y arahmadi H, Hasheminejad SMH. Design pattern detection approaches: a systematic review of the literature. Artiﬁcial Intelligence Review 2020; 53. doi: 10.1007/s10462-020-09834-5

doi:10.1007/s10462-020-09834-5 2020

[5] [5]

DP-CORE: A Design Pattern Detection T ool for Code Reuse

Diamantopoulos T, Noutsos A, Symeonidis A. DP-CORE: A Design Pattern Detection T ool for Code Reuse. In: ; 2016

work page 2016

[6] [6]

Reverse Engineering of Design Patterns from Java Source Code

Shi N, Olsson R. Reverse Engineering of Design Patterns from Java Source Code. In: ; 2006: 123-134

work page 2006

[7] [7]

Handling large search space in pattern-based reverse engineering

Niere J, Wadsack J, Wendehals L. Handling large search space in pattern-based reverse engineering. In: ; 2003: 274-279

work page 2003

[8] [8]

Automatic design pattern detection

Heuzeroth D, Holl T, Hogstrom G, Lowe W. Automatic design pattern detection. In: ; 2003: 94-103

work page 2003