Pith. sign in

REVIEW 3 major objections 4 minor 1 cited by

Comparison of Static Analysis Architecture Recovery Tools for Microservice Applications

T0 review · 3 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read This paper provides the first execution-based comparison of static architecture recovery tools, with Code2DFD best alone at F1 0.86 and a four-tool combination at 0.91.

desk verdict First execution-based comparison of microservice architecture recovery tools, but the headline rankings need a common-subset analysis before they can be believed. read the letter →

arxiv 2412.08352 v1 pith:LNGALPC6 submitted 2024-12-11 cs.SE

Simon Schneider , Alexander Bakhtin , Xiaozhou Li , Jacopo Soldani , Antonio Brogi , Tomas Cerny , Riccardo Scandariato , Davide Taibi This is my paper · ORCID
classification cs.SE
keywords microservicesarchitecturerecoverystaticanalysistoolcomparisondataflowdiagramsprecisionrecallF1endpointdetectionregisteredreport
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

This paper tries to establish the first execution-based comparison of static architecture recovery tools for microservice applications, and to show both the accuracy of individual tools and whether combining tools improves recovery. The authors identify 13 tools through a multivocal literature review, succeed in running nine of them on 17 open-source Spring-based microservice applications, and measure precision, recall, and F1 against manually built dataflow-diagram ground truth. They report that Code2DFD is the best single tool with overall F1 = 0.86, and that merging the outputs of Code2DFD, MicroDepGraph, RAD, and RAD-source raises F1 to 0.91. If the finding holds, practitioners get a concrete reference for choosing tools, and researchers get evidence that no single tool yet recovers architecture perfectly.

What carries the argument

The central mechanism is the evaluation pipeline: every tool is executed on the same 17 applications from the microSecEnD dataset, whose dataflow diagrams provide ground-truth components, connections, and endpoints; tool outputs are then manually compared to that ground truth to count true positives, false positives, and false negatives, from which precision, recall, and F1 are computed. For combinations, the paper merges per-characteristic results with logical AND and OR, so a characteristic counts as recovered under OR if any tool found it and under AND only if all tools found it. This pipeline is what makes the study an execution-based comparison rather than a review of advertised features.

What would settle it

Run one of the 17 benchmark applications and record the actual HTTP routes exposed by each service, for example by starting the service and enumerating registered mappings or reading runtime traffic, then compare that route list to the ground-truth DFD annotations. If any real endpoint is missing from the ground truth, or any ground-truth endpoint is not actually reachable, the reported precision, recall, and F1 values for endpoint extraction are wrong.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that static architecture recovery for microservices is now measurable on a common benchmark, and that the current best individual tool operates at overall F1 = 0.86. For components, Code2DFD reaches F1 = 0.98; for connections, Code2DFD scores 0.87; and for endpoints, RAD scores 0.79. Three of the nine runnable tools produced no useful output at all, and several others extracted almost nothing, while the tools that did work showed high precision but varying recall. Combining tool outputs with logical AND and OR on individual characteristics improves or matches the best individual result for almost every evaluated metric, with the four-tool combination of Code2DFD, MicroDepGraph, RAD, and RAD-source achieving overall F1 = 0.91.

Load-bearing premise

The comparison assumes the dataflow diagrams in the microSecEnD dataset are a complete and correct ground truth for components, connections, and endpoints, and that every real endpoint is declared via the Java annotations @RequestMapping, @PutMapping, @GetMapping, or @RepositoryRestResource; if the diagrams omit anything or endpoints exist through other mechanisms, every reported score shifts.

Editorial extensions

If this is right

  • Code2DFD is the tool to beat across all three characteristics at once, with per-characteristic F1 scores of 0.98 for components, 0.87 for connections, and 0.66 for endpoints.
  • A practitioner who wants reliable endpoint extraction should prefer RAD (F1 = 0.79) over RAD-source (0.67) and Code2DFD (0.66).
  • Combining the outputs of Code2DFD, MicroDepGraph, RAD, and RAD-source raises overall F1 from 0.86 to 0.91, showing that tool synergy is real despite individual weaknesses.
  • Simple parsing of deployment files yields high precision quickly, but high recall requires deeper source analysis such as detecting Java annotations in the code.
  • For each evaluated metric and each characteristic, at least one tool combination matches or beats the best individual tool.

Reading between the lines

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

  • The reported endpoint accuracy is likely an upper bound for non-Spring, non-Java stacks, because the ground truth models endpoints only through four Spring and Java annotations; a runtime-traffic-based endpoint list would probably reveal additional endpoints and shift the F1 scores.
  • The combination results are computed by merging outputs offline, not by an integrated pipeline; in practice a merging or voting layer would add integration overhead and could change the realized gains.
  • The paper's observation that no undetected characteristic is inherently undetectable suggests a single tool combining deployment-file parsing with deeper source or bytecode analysis could plausibly exceed the current 0.91 ceiling, a claim the authors hold qualitatively rather than demonstrate.
  • Extending the benchmark to non-Spring frameworks or RPC-based services would decide how far the 0.86 and 0.91 numbers generalize.
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.

Referee Report

3 major / 4 minor

Summary. The paper presents a multivocal literature review that identifies 13 static analysis architecture recovery tools for microservice applications and an execution-based comparison of nine of these tools on the microSecEnD dataset, which contains 17 Java/Spring microservice applications. The tools are compared on their ability to extract components, connections, and endpoints, with precision, recall, and F1-score computed against a manually extended ground truth. The headline claim is that Code2DFD is the best individual tool (overall F1 = 0.86) and that a combination of Code2DFD, MicroDepGraph, RAD, and RAD-source reaches F1 = 0.91. The study is described as the first execution-based comparison of such tools and is registered at MSR'24, with a replication package provided.

Significance. If the comparison is valid, this is the first independent execution-based assessment of static architecture recovery tools for microservices, a genuine contribution to a field that has relied on self-reported results. The strengths are substantial: the methodology was peer-reviewed as a registered report, the literature review used two independent coders with reported Cohen's kappa agreement, the output quantification was performed by two authors with conflict resolution, and a replication package is available. The paper also carefully documents execution obstacles and the reasons tools were excluded, which is valuable for reproducibility. However, the validity of the headline ranking depends on a controlled comparison across a common set of ground-truth items, and this is not currently established.

major comments (3)
  1. [Section 4.1, Table 5d, Table 6] The headline ranking in RQ4 is not a controlled comparison because each tool's F1 is computed over a different set of ground-truth items. For example, Code2DFD has F1 = 0.86 on GT = 727 from 17 applications, while RAD has F1 = 0.79 on GT = 391 from 13 applications and MicroDepGraph has F1 = 0.74 on GT = 355 from 10 applications. If tools run on different subsets of the dataset, the observed ordering may reflect application difficulty or dataset coverage rather than tool capability. The paper reports per-tool execution counts (Table 6) but does not provide a common-subset comparison. A same-items analysis, such as restricting all tools to the applications that every tool can analyze, or reporting per-application metrics, is needed to support the claim in the abstract that one tool is 'best-performing' and the answer to RQ4.
  2. [Section 2.3] The endpoint ground truth is defined using the same Java annotations (@RequestMapping, @PutMapping, @GetMapping, @RepositoryRestResource) that several evaluated tools (RAD, RAD-source, Code2DFD, Prophet) use for endpoint detection. The paper states that identifying these annotations is 'sufficient' to create the ground truth, but no independent endpoint inventory is provided. This is partially circular: the ground truth is constructed from the tools' own detection mechanism, so endpoint recall is measured against a standard the tools effectively define. Endpoints implemented through other mechanisms (e.g., Spring WebFlux functional routing, JAX-RS, or gateway configurations) are excluded by construction. The claim that the annotation set is complete for these applications needs stronger support, or the endpoint results should be framed as agreement with an annotation-based definition rather than absolute endpoint extraction accuracy.
  3. [Section 2.6, Table 8] The semantics of combining tools when not all tools ran on all applications is underspecified. The paper says that for OR-combinations, if only one tool produced results for an application, its results count directly, but the behavior for AND-combinations in the presence of missing tool outputs is not defined. Table 8 reports a single GT per combination without explaining whether the GT is the union, intersection, or some other aggregate of the per-tool application sets. There is also an apparent internal inconsistency: in Table 8a, AMOR has GT = 144, identical to AGG's GT, even though MDG analyzed 10 applications; if MDG analyzed any applications outside AGG's set, the union GT should be larger. The RQ5 headline result (F1 = 0.91) depends on these combination definitions, so the methodology needs to be clarified and the numbers reconciled.
minor comments (4)
  1. [Section 3.4, Table 4] The text states that seven tools extract components and seven tools extract endpoints, but Table 4 shows eight tools for each (components: AGG, C2D, MDG, MMI, MTO, PRO, PR2; endpoints: AFA, C2D, MGR, PRO, PR2, RAD, RAS, CMA). The text and table should be aligned.
  2. [Section 5.1] The sentence beginning 'A look into the individual tools’ performance – especially those that failed to produce meaningful results – shows,' is incomplete; it appears to be cut off and should be finished or removed.
  3. [Section 2.5] The manual quantification of true positives, false positives, and false negatives is reported as being performed by two authors independently, but no inter-rater agreement value is reported for this step, in contrast to the literature review phases. Reporting this agreement would strengthen the reliability of the core measurements.
  4. [Section 6.3] The conflict-of-interest statement declares no conflicts, but several evaluated tools (e.g., Code2DFD, microMiner) and the microSecEnD dataset are authored by members of this paper's author team. A disclosure and a brief discussion of any mitigation measures would be appropriate.

Circularity Check

2 steps flagged · score 6.0 of 10

RQ5's best-combination F1 of 0.91 is a training-set maximum by construction, and the endpoint oracle is defined by the same annotation mechanism the tools detect.

  1. fitted input called prediction [Section 2.6 (Evaluating Combinations of Tools), Tables 7-9, Answer to RQ5]
    "The combinations were selected based on the individual results such that the used metrics (precision, recall, and F1-score) are maximized."

    The combination identity is the fitted quantity: the authors chose which tools to combine after seeing per-tool results, using the same F1 metric later reported as the outcome. BestF1=0.91 is therefore the maximum of the searched combinations on the evaluation set, not an independent estimate. RQ5's conclusion that combinations outperform individual tools is built into the selection procedure, since taking the best of many candidates on the same data will almost always beat any fixed candidate. No held-out applications or cross-validation are used, so the 0.91 gain is a training-set artifact rather than a predicted or validated improvement.

  2. self definitional [Section 2.3 (Extension of Dataset), endpoint ground truth]
    "A look into the tools that have endpoints in their extraction scopes and an investigation into possibilities for implementing endpoints revealed, that a number of Java annotations indicate such endpoints. Specifically, identifying the annotation @RequestMapping and its related, more specific annotations for a single HTTP method (@PutMapping, @GetMapping, and so on) and the annotation @RepositoryRestResource in the code is sufficient to manually create the ground truth required for this work."

    The endpoint ground truth is constructed by manually locating the same Java annotation family that the evaluated endpoint-extracting tools (e.g., RAD, RAD-source, Prophet, Code2DFD) are designed to detect. Consequently, endpoint precision/recall measures how well each tool reproduces an annotation-based oracle rather than how well it recovers an independently established set of REST endpoints. Tools using a different vocabulary are disadvantaged by construction, and the oracle itself is extended by the same authors. The scores are thus partly self-referential, though not fully forced because tools can still miss or hallucinate annotations.

full rationale

The central comparison is not circular in the derivation sense: the nine tools are executed on the public, manually created microSecEnD dataset, and TP/FP/FN counts are made by two independent authors against that ground truth. This gives the RQ4 individual-tool rankings independent empirical content despite some authors having created the dataset and Code2DFD. However, two parts of the paper reduce partly by construction. First, the RQ5 combination results are selected to maximize the very metrics reported as outcomes, so the headline F1=0.91 is the maximum observed combination on the evaluation set, not a prediction; the claimed improvement from combining tools is an artifact of this selection. Second, the endpoint ground-truth extension is defined by searching for the same Java annotations the endpoint-detecting tools are built to detect, making endpoint F1 partly a measure of agreement with an annotation-based oracle. Neither step makes the whole study circular, but the combination result and the endpoint oracle are fitted/self-referential enough to warrant a moderate score.

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

This is a benchmarking study rather than a derivation, so it introduces no free parameters or invented entities. The main epistemic load is the ground truth, especially the endpoint extension, and the in-sample selection of the best tool combination, both of which are accounted for in the axioms and red flags.

assumptions (5)
  • domain assumption The microSecEnD DFDs are a complete and correct ground truth for components, connections, and endpoints in the 17 applications.
    The entire accuracy comparison derives from counting true positives, false positives, and false negatives against these DFDs, as described in Sections 2.3 and 2.5. If the DFDs omit or mislabel characteristics, every reported F1-score changes.
  • ad hoc to paper All endpoints in the dataset are implemented via the Java annotations @RequestMapping, @PutMapping, @GetMapping, and @RepositoryRestResource, and no other implementation mechanism needs to be considered.
    Section 2.3 states that identifying these annotations is 'sufficient' to create the endpoint ground truth. This assumption aligns endpoint ground truth with the detection technique used by several compared tools.
  • domain assumption The tools' self-declared extraction scopes, taken from their papers and repositories, correctly describe what each tool is intended to extract.
    Tools are compared only on characteristics in their extraction scope, as shown in Table 4, so an inaccurate self-description would misattribute false negatives to the tool.
  • domain assumption Manual classification of tool outputs into true positives, false positives, and false negatives is sufficiently objective and consistent.
    Outputs were manually counted by two authors (Section 2.5); despite inter-rater checks, the differing output formats make this a subjective step that could affect the metrics.
  • domain assumption The 17 small-to-medium Java Spring applications are representative enough to rank tools for microservice architecture recovery.
    Section 6.3 acknowledges this as an external validity threat: the dataset is small, homogeneous, and Java/Spring-centric, which limits generalizability of the tool rankings.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Comparison of Static Analysis Architecture Recovery Tools for Microservice Applications." pith.science (2026). https://pith.science/paper/LNGALPC6

@misc{pith2026241208352,
  author       = {Pith},
  title        = {Pith review of: Comparison of Static Analysis Architecture Recovery Tools for Microservice Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LNGALPC6}},
  note         = {Machine review of arXiv:2412.08352}
}
read the original abstract

Architecture recovery tools help software engineers obtain an overview of the structure of their software systems during all phases of the software development life cycle. This is especially important for microservice applications because they consist of multiple interacting microservices, which makes it more challenging to oversee the architecture. Various tools and techniques for architecture recovery (also called architecture reconstruction) have been presented in academic and gray literature sources, but no overview and comparison of their accuracy exists. This paper presents the results of a multivocal literature review with the goal of identifying architecture recovery tools for microservice applications and a comparison of the identified tools' architectural recovery accuracy. We focused on static tools since they can be integrated into fast-paced CI/CD pipelines. 13 such tools were identified from the literature and nine of them could be executed and compared on their capability of detecting different system characteristics. The best-performing tool exhibited an overall F1-score of 0.86. Additionally, the possibility of combining multiple tools to increase the recovery correctness was investigated, yielding a combination of four individual tools that achieves an F1-score of 0.91. Registered report: The methodology of this study has been peer-reviewed and accepted as a registered report at MSR'24: arXiv:2403.06941

Figures

Figures reproduced from arXiv: 2412.08352 by the authors.

Figure 1
Figure 1. The methodology adopted in this study. often prototypes created for the sake of showing the feasibility of a presented ap￾proach and where subsequent maintenance is often neglected, such an evaluation is crucial for properly judging the tools’ qualities. The rest of this paper is structured as follows: Section 2 provides an extended and updated description of the methodology presented in the registered report of thi… view at source ↗
Figure 2
Figure 2. Results of the systematic literature review of the formally published liter [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Network Centrality as a New Perspective on Microservice Architecture

    cs.SE 2025-01 conditional novelty 5.0 of 10

    Centrality metrics calculated on service dependency graphs are only weakly to moderately correlated with traditional size, complexity, and quality metrics across 53 microservices, suggesting they capture a distinct ar...

Reference graph

Works this paper leans on

71 extracted references · 66 canonical work pages · cited by 1 Pith paper

  1. [1]

    Towards a security benchmark for the architectural design of microservice applications,

    A. Bambhore Tukaram, S. Schneider, N. E. D ´ ıaz Ferreyra, G. Simhandl, U. Zdun, and R. Scandariato, “Towards a security benchmark for the architectural design of microservice applications,” in ARES. New York, NY, USA: ACM, 2022

    work page 2022

  2. [2]

    Smells and refactorings for microservices security: A multivocal literature review,

    F. Ponce, J. Soldani, H. Astudillo, and A. Brogi, “Smells and refactorings for microservices security: A multivocal literature review,” JSS, 2022

    work page 2022

  3. [3]

    Taibi, V

    D. Taibi, V. Lenarduzzi, and C. Pahl, Microservices Anti-patterns: A Taxonomy. Cham: Springer International Publishing, 2020

    work page 2020

  4. [4]

    Catma: Conformance analysis tool for microservice applications,

    C. Cao, S. Schneider, N. Diaz Ferreyra, S. Verweer, A. Panichella, and R. Scandariato, “Catma: Conformance analysis tool for microservice applications,” in ICSE-Companion, 2024

    work page 2024

  5. [5]

    Dragoni, S

    N. Dragoni, S. Giallorenzo, A. Lluch-Lafuente, M. Mazzara, F. Montesi, R. Mustafin, and L. Safina, Microservices: yesterday, today, and tomorrow . Springer International Publishing, 2016

    work page 2016

  6. [6]

    Microservices: a definition of this new architectural term,

    J. Lewis and M. Fowler, “Microservices: a definition of this new architectural term,”

    work page

  7. [7]

    Architecting with microservices: A systematic mapping study,

    P. Di Francesco, P. Lago, and I. Malavolta, “Architecting with microservices: A systematic mapping study,” JSS, 2019. 19 https://github.com/M3SOulu/SARbenchmarks 38 Simon Schneider et al

    work page 2019

  8. [8]

    The pains and gains of microser- vices: A systematic grey literature review,

    J. Soldani, D. A. Tamburri, and W.-J. Van Den Heuvel, “The pains and gains of microser- vices: A systematic grey literature review,” JSS, 2018

    work page 2018

Show all 71 references
  1. [9]

    The impact of uml documentation on software maintenance: an experimental evaluation,

    E. Arisholm, L. C. Briand, S. E. Hove, and Y. Labiche, “The impact of uml documentation on software maintenance: an experimental evaluation,” TSE, 2006

    2006

  2. [10]

    Empirical evi- dence about the uml: a systematic literature review,

    D. Budgen, A. J. Burn, P. Brereton, A. B. Kitchenham, and R. Pretorius, “Empirical evi- dence about the uml: a systematic literature review,” Software: Practice and Experience, 2011

    2011

  3. [11]

    An empirical investigation on the relation between analysis models and source code comprehension,

    C. Gravino, G. Tortora, and G. Scanniello, “An empirical investigation on the relation between analysis models and source code comprehension,” in SAC. ACM, 2010

    2010

  4. [12]

    Source-code comprehension tasks supported by uml design models: Results from a controlled experiment and a differentiated replica- tion,

    C. Gravino, G. Scanniello, and G. Tortora, “Source-code comprehension tasks supported by uml design models: Results from a controlled experiment and a differentiated replica- tion,” Journal of Visual Languages & Computing , 2015

    2015

  5. [13]

    How dataflow diagrams impact software security analysis: an empirical experiment,

    S. Schneider, N. E. Diaz Ferreyra, P.-J. Queval, G. Simhandl, U. Zdun, and R. Scandariato, “How dataflow diagrams impact software security analysis: an empirical experiment,” in SANER, 2024

    2024

  6. [14]

    Towards micro service architecture recovery: An empirical study,

    N. Alshuqayran, N. Ali, and R. Evans, “Towards micro service architecture recovery: An empirical study,” in ICSA, 2018

    2018

  7. [15]

    Towards recovering the software architecture of microservice-based systems,

    G. Granchelli, M. Cardarelli, P. Di Francesco, I. Malavolta, L. Iovino, and A. Di Salle, “Towards recovering the software architecture of microservice-based systems,” in ICSA W, 2017

    2017

  8. [16]

    Microlyze: A framework for re- covering the software architecture in microservice-based environments,

    M. Kleehaus, ¨O. Uludag, P. Sch¨ afer, and F. Matthes, “Microlyze: A framework for re- covering the software architecture in microservice-based environments,” in Information Systems in the Big Data Era . Springer International Publishing, 2018

    2018

  9. [17]

    Extracting the architecture of microservices: An approach for explainability and traceability,

    P.-J. Qu´ eval and U. Zdun, “Extracting the architecture of microservices: An approach for explainability and traceability,” in ECSA. Cham: Springer Nature Switzerland, 2023

    2023

  10. [18]

    The mtosca toolchain: Mining, analyz- ing, and refactoring microservice-based architectures,

    J. Soldani, G. Muntoni, D. Neri, and A. Brogi, “The mtosca toolchain: Mining, analyz- ing, and refactoring microservice-based architectures,” Software: Practice and Experience, 2021

    2021

  11. [19]

    Comparison of static analysis architecture recovery tools for microservice applications,

    S. Schneider, A. Bakhtin, X. Li, J. Soldani, A. Brogi, T. Cerny, R. Scandariato, and D. Taibi, “Comparison of static analysis architecture recovery tools for microservice applications,” 2024. [Online]. Available: https://arxiv.org/abs/2403.06941

    2024 arXiv

  12. [20]

    Tools reconstructing mi- croservice architecture: A systematic mapping study,

    A. Bakhtin, X. Li, J. Soldani, A. Brogi, T. Cerny, and D. Taibi, “Tools reconstructing mi- croservice architecture: A systematic mapping study,” in Software Architecture. ECSA 2023 Tracks, Workshops, and Doctoral Symposium , B. Tekinerdo˘ gan, R. Spalazzese, H. S¨ ozer, S. Bon...

    2023

  13. [21]

    Guidelines for including grey literature and conducting multivocal literature reviews in software engineering,

    V. Garousi, M. Felderer, and M. V. M¨ antyl¨ a, “Guidelines for including grey literature and conducting multivocal literature reviews in software engineering,” IST, 2019

    2019

  14. [22]

    Toward end-to-end mlops tools map: A preliminary study based on a multivocal literature review,

    S. Moreschini, G. Recupito, V. Lenarduzzi, F. Palomba, D. H¨ astbacka, and D. Taibi, “Toward end-to-end mlops tools map: A preliminary study based on a multivocal literature review,” ArXiv, 2023

    2023

  15. [23]

    Motivations, benefits, and issues for adopting micro-frontends: A multivocal literature review,

    S. Peltonen, L. Mezzalira, and D. Taibi, “Motivations, benefits, and issues for adopting micro-frontends: A multivocal literature review,” IST, 2021

    2021

  16. [24]

    Procedures for performing systematic reviews,

    B. Kitchenham, “Procedures for performing systematic reviews,” Keele, UK, Keele Univ., vol. 33, 08 2004

    2004

  17. [25]

    Guidelines for performing systematic literature reviews in software engineering,

    B. Kitchenham and S. Charters, “Guidelines for performing systematic literature reviews in software engineering,” vol. 2, 01 2007

    2007

  18. [26]

    Empirical standards for software engineering research,

    P. Ralph, N. b. Ali, S. Baltes, D. Bianculli, J. Diaz, Y. Dittrich, N. Ernst, M. Felderer, R. Feldt, A. Filieri et al. , “Empirical standards for software engineering research,” arXiv preprint arXiv:2010.03525, 2020

    2010

  19. [27]

    Benchmarking kappa: Interrater agreement in software processassessments,

    K. E. Emam, “Benchmarking kappa: Interrater agreement in software processassessments,” EMSE, 1999

    1999

  20. [28]

    Guidelines for snowballing in systematic literature studies and a replication in software engineering,

    C. Wohlin, “Guidelines for snowballing in systematic literature studies and a replication in software engineering,” in EASE. ACM, 2014

    2014

  21. [29]

    microsecend: A dataset of security- enriched dataflow diagrams for microservice applications,

    S. Schneider, T. ¨Ozen, M. Chen, and R. Scandariato, “microsecend: A dataset of security- enriched dataflow diagrams for microservice applications,” in MSR, 2023

    2023

  22. [30]

    The state of developer ecosystem 2022,

    JetBrains, “The state of developer ecosystem 2022,” JetBrains, Tech. Rep., 2022, accessed on 09.02.2024. [Online]. Available: https://www.jetbrains.com/lp/devecosystem-2022/ microservices/

    2022

  23. [31]

    2022 java developer productivity report,

    JRebel, “2022 java developer productivity report,” JRebel, Tech. Rep., 2022, accessed on 09.02.2024. [Online]. Available: https://www.jrebel.com/resources/ java-developer-productivity-report-2022 Comparison of Static Architecture Recovery Tools for Microservices 39

    2022

  24. [32]

    The measurement of observer agreement for categorical data,

    J. R. Landis and G. G. Koch, “The measurement of observer agreement for categorical data,” Biometrics, vol. 33, no. 1, pp. 159–174, 1977

    1977

  25. [33]

    Software architecture reconstruction for microservice systems using static analysis via graalvm native image,

    R. Hutcheson, A. Blanchard, N. Lambaria, J. Hale, A. E. David Kozak, and T. Cerny, “Software architecture reconstruction for microservice systems using static analysis via graalvm native image,” in SANER 2024 , ser. SANER. Institute of Electrical and Elec- tronics Engineers, Mar. 2024

    2024

  26. [34]

    Towards security-aware mi- croservices: On extracting endpoint data access operations to determine access rights,

    A. Abdelfattah, M. Schiewe, J. Curtis, T. Cerny, and E. Song, “Towards security-aware mi- croservices: On extracting endpoint data access operations to determine access rights,” in 13th international conference on cloud computing and services science (CLOSER 2023) , 2023

    2023

  27. [35]

    Attack graph generation for microservice architecture,

    A. Ibrahim, S. Bozhinoski, and A. Pretschner, “Attack graph generation for microservice architecture,” in Symposium on Applied Computing . ACM, 2019

    2019

  28. [36]

    Automatic extraction of security-rich dataflow diagrams for microservice applications written in java,

    S. Schneider and R. Scandariato, “Automatic extraction of security-rich dataflow diagrams for microservice applications written in java,” JSS, 2023

    2023

  29. [37]

    A curated dataset of microservices-based systems,

    M. I. Rahman, S. Panichella, and D. Taibi, “A curated dataset of microservices-based systems,” 2019

    2019

  30. [38]

    Mining the architecture of microservice-based applications from their kubernetes deployment,

    G. Muntoni, J. Soldani, and A. Brogi, “Mining the architecture of microservice-based applications from their kubernetes deployment,” in Advances in Service-Oriented and Cloud Computing . Cham: Springer International Publishing, 2021

    2021

  31. [39]

    Offline mining of microservice-based architectures (extended version),

    J. Soldani, J. Khalili, and A. Brogi, “Offline mining of microservice-based architectures (extended version),” SN Comput. Sci. , 2023

    2023

  32. [40]

    Using static analysis to address mi- croservice architecture reconstruction,

    V. Bushong, D. Das, A. Al Maruf, and T. Cerny, “Using static analysis to address mi- croservice architecture reconstruction,” in ASE, 2021

    2021

  33. [41]

    Advancing static code analysis with language-agnostic component identification,

    M. Schiewe, J. Curtis, V. Bushong, and T. Cerny, “Advancing static code analysis with language-agnostic component identification,” IEEE Access , vol. 10, pp. 30 743–30 761, 2022

    2022

  34. [42]

    Rpcover: Recovering grpc dependency in multilin- gual projects,

    A. Fang, R. Zhou, X. Tang, and P. He, “Rpcover: Recovering grpc dependency in multilin- gual projects,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 1930–1939

    2023

  35. [43]

    On automated rbac assessment by constructing a centralized perspective for microservice mesh,

    D. Das, A. Walker, V. Bushong, J. Svacina, T. Cerny, and V. Matyas, “On automated rbac assessment by constructing a centralized perspective for microservice mesh,” PeerJ Computer Science, vol. 7, 2021

    2021

  36. [44]

    What developers want and need from program analysis: an empirical study,

    M. Christakis and C. Bird, “What developers want and need from program analysis: an empirical study,” in Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering , ser. ASE ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 332–343

    2016

  37. [45]

    Why don’t software developers use static analysis tools to find bugs?

    B. Johnson, Y. Song, E. Murphy-Hill, and R. Bowdidge, “Why don’t software developers use static analysis tools to find bugs?” in 2013 35th International Conference on Software Engineering (ICSE), 2013, pp. 672–681

    2013

  38. [46]

    Microservices: A systematic mapping study

    C. Pahl and P. Jamshidi, “Microservices: A systematic mapping study.” CLOSER (1), pp. 137–146, 2016

    2016

  39. [47]

    A systematic mapping study in microservice architecture,

    N. Alshuqayran, N. Ali, and R. Evans, “A systematic mapping study in microservice architecture,” in 2016 IEEE 9th international conference on service-oriented computing and applications (SOCA) . IEEE, 2016, pp. 44–51

    2016

  40. [48]

    Roadmap to reasoning in microservice systems: A rapid review,

    A. S. Abdelfattah and T. Cerny, “Roadmap to reasoning in microservice systems: A rapid review,” Applied Sciences, vol. 13, no. 3, 2023

    2023

  41. [49]

    On microservice analysis and architecture evolution: A systematic mapping study,

    V. Bushong, A. S. Abdelfattah, A. A. Maruf, D. Das, A. Lehman, E. Jaroszewski, M. Cof- fey, T. Cerny, K. Frajtak, P. Tisnovsky, and M. Bures, “On microservice analysis and architecture evolution: A systematic mapping study,” Applied Sciences, 2021

    2021

  42. [50]

    Design principles, architectural smells and refactorings for microservices: a multivocal review,

    D. Neri, J. Soldani, O. Zimmermann, and A. Brogi, “Design principles, architectural smells and refactorings for microservices: a multivocal review,” SICS, 2020

    2020

  43. [51]

    From monolith to microservices: A classification of refactoring approaches,

    J. Fritzsch, J. Bogner, A. Zimmermann, and S. Wagner, “From monolith to microservices: A classification of refactoring approaches,” in Software Engineering Aspects of Continu- ous Development and New Paradigms of Software Production and Deployment . Cham: Springer Internationa...

    2019

  44. [52]

    Migration of mono- lithic systems to microservices: A systematic mapping study,

    A. M. Saucedo, G. Rodr ´ ıguez, F. G. Rocha, and R. P. dos Santos, “Migration of mono- lithic systems to microservices: A systematic mapping study,” Information and Software Technology, p. 107590, 2024

    2024

  45. [53]

    Visualizing microservice architecture in the dynamic perspective: A systematic mapping study,

    M. E. Gortney, P. E. Harris, T. Cerny, A. A. Maruf, M. Bures, D. Taibi, and P. Tisnovsky, “Visualizing microservice architecture in the dynamic perspective: A systematic mapping study,” IEEE Access, 2022. 40 Simon Schneider et al

    2022

  46. [54]

    Change impact analysis in microservice systems: A systematic literature review,

    L. Lelovic, A. Huzinga, G. Goulis, A. Kaur, R. Boone, U. Muzrapov, A. S. Abdelfattah, and T. Cerny, “Change impact analysis in microservice systems: A systematic literature review,” Journal of Systems and Software , p. 112241, 2024

    2024

  47. [55]

    Survey on tools and techniques detecting microservice api patterns,

    A. Bakhtin, A. Al Maruf, T. Cerny, and D. Taibi, “Survey on tools and techniques detecting microservice api patterns,” in SCC, 2022

    2022

  48. [56]

    Monitoring tools for devops and microservices: A systematic grey literature review,

    L. Giamattei, A. Guerriero, R. Pietrantuono, S. Russo, I. Malavolta, T. Islam, M. D ˆ ınga, A. Koziolek, S. Singh, M. Armbruster, J. Gutierrez-Martinez, S. Caro-Alvaro, D. Ro- driguez, S. Weber, J. Henss, E. F. Vogelin, and F. S. Panojo, “Monitoring tools for devops and micros...

    2024

  49. [57]

    Microservice ar- chitecture reconstruction and visualization techniques: A review,

    T. Cerny, A. S. Abdelfattah, V. Bushong, A. Al Maruf, and D. Taibi, “Microservice ar- chitecture reconstruction and visualization techniques: A review,” in SOSE, 2022

    2022

  50. [58]

    Comparison of static code analysis tools,

    M. Mantere, I. Uusitalo, and J. Roning, “Comparison of static code analysis tools,” in SECUR WARE, 2009

    2009

  51. [59]

    A critical compar- ison on six static analysis tools: Detection, agreement, and precision,

    V. Lenarduzzi, F. Pecorelli, N. Saarimaki, S. Lujan, and F. Palomba, “A critical compar- ison on six static analysis tools: Detection, agreement, and precision,” JSS, 2023

    2023

  52. [60]

    Comparison and evaluation on static application security testing (sast) tools for java,

    K. Li, S. Chen, L. Fan, R. Feng, H. Liu, C. Liu, Y. Liu, and Y. Chen, “Comparison and evaluation on static application security testing (sast) tools for java,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Sof...

    2023

  53. [61]

    A com- prehensive study on quality assurance tools for java,

    H. Liu, S. Chen, R. Feng, C. Liu, K. Li, Z. Xu, L. Nie, Y. Liu, and Y. Chen, “A com- prehensive study on quality assurance tools for java,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis , ser. ISSTA 2023. New York, NY, USA: Ass...

    2023

  54. [62]

    How many of all bugs do we find? a study of static bug de- tectors,

    A. Habib and M. Pradel, “How many of all bugs do we find? a study of static bug de- tectors,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, ser. ASE ’18. New York, NY, USA: Association for Computing Machinery, 2018, p. 317–328

    2018

  55. [63]

    Bugs in the wild: examining the effectiveness of static analyzers at finding real-world bugs,

    D. A. Tomassi, “Bugs in the wild: examining the effectiveness of static analyzers at finding real-world bugs,” in Proceedings of the 2018 26th ACM Joint Meeting on European Soft- ware Engineering Conference and Symposium on the Foundations of Software Engineer- ing, ser. ESEC/...

    2018

  56. [64]

    To what extent could we detect field defects? an extended empirical study of false negatives in static bug-finding tools,

    F. Thung, Lucia, D. Lo, L. Jiang, F. Rahman, and P. T. Devanbu, “To what extent could we detect field defects? an extended empirical study of false negatives in static bug-finding tools,” Automated Software Engineering , vol. 22, no. 4, pp. 561–602, 2015. [Online]. Available: ...

    2015 doi

  57. [65]

    Comparing software architecture recovery techniques using accurate dependencies,

    T. Lutellier, D. Chollak, J. Garcia, L. Tan, D. Rayside, N. Medvidovic, and R. Kroeger, “Comparing software architecture recovery techniques using accurate dependencies,” in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering , vol. 2, 2015, pp. 69–78

    2015

  58. [66]

    Measuring the impact of code dependencies on software architecture recovery techniques,

    T. Lutellier, D. Chollak, J. Garcia, L. Tan, D. Rayside, N. Medvidovi´ c, and R. Kroeger, “Measuring the impact of code dependencies on software architecture recovery techniques,” IEEE Transactions on Software Engineering , vol. 44, no. 2, pp. 159–181, 2018

    2018

  59. [67]

    A comparative analysis of software architecture recovery techniques,

    J. Garcia, I. Ivkovic, and N. Medvidovic, “A comparative analysis of software architecture recovery techniques,” in 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE) , 2013, pp. 486–496

    2013

  60. [68]

    A comparative study of meta-data-based microservice ex- traction tools,

    K. Akkaya and T. Ovatman, “A comparative study of meta-data-based microservice ex- traction tools,” IJSSMET, 2022

    2022

  61. [69]

    Microservice decomposition techniques: An indepen- dent tool comparison,

    Y. Wang, S. Bornais, and J. Rubin, “Microservice decomposition techniques: An indepen- dent tool comparison,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering , 2024, pp. 1295–1307

    2024

  62. [70]

    Zenodo, 2024

    Replication package of the presented work . Zenodo, 2024. [Online]. Available: https://doi.org/10.5281/zenodo.14179613

    2024 doi

  63. [2014]

    Available: https://martinfowler.com/articles/microservices.html

    [Online]. Available: https://martinfowler.com/articles/microservices.html

Pith tools

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