Pith. sign in

REVIEW 4 major objections 6 minor 67 references

Network Centrality as a New Perspective on Microservice Architecture

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Pith's one-line read Network centrality metrics capture architectural role that traditional software metrics do not, so they can complement code metrics in detecting microservice anti-patterns.

desk verdict First systematic correlation of centrality with standard software metrics on real microservices; a useful negative result, but the false-negative bias in reconstructed graphs needs testing before the specific correlations are trusted. read the letter →

arxiv 2501.13520 v1 pith:BUQEVA56 submitted 2025-01-23 cs.SE cs.DCcs.DM

classification cs.SEcs.DCcs.DM
keywords microservicearchitecturecentralitymetricsservicedependencygraphsoftwareanti-patterndetectionstaticanalysiscorrelation
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 asks whether a microservice's position in its dependency graph reveals something that traditional code metrics do not. It reconstructs service dependency graphs for open-source Java-based microservice projects, computes eleven centrality scores for 53 microservices, and correlates them with 155 size, complexity, and quality metrics. Of 902 computed correlations, only 282 are statistically significant, and most of those are weak to moderate. The paper concludes that centrality gives a largely independent perspective on microservice architecture, making it useful for spotting architectural anti-patterns such as hub-like, nano, and mega services.

What carries the argument

The load-bearing object is the Service Dependency Graph (SDG), a directed graph whose nodes are microservices and whose edges are statically reconstructed service-to-service calls. On this graph the paper computes eleven centrality scores, including degree, betweenness, closeness, eigenvector, load, information, harmonic, and subgraph centrality, and correlates them with code metrics aggregated to the service level. The SDG structure explains the correlations that do appear: a service is central because it exposes public methods that other services call, so call-based centrality and public-method counts are tied to the same underlying edges.

What would settle it

Compare the reconstructed service dependency graphs against manually verified or runtime-derived call graphs for the same projects: if the rate of missing connections correlates with service size or complexity, the reported correlation pattern could be an artifact of incomplete reconstruction rather than a property of the systems.

Watch

Extended reading notes

Core claim

The central claim is that microservice centrality metrics are weak to moderately correlated with traditional software metrics when the correlation is statistically significant, except where the correlation arises directly from the structure of the service dependency graph. A central microservice tends to expose many public methods while having few private or protected methods, low inheritance complexity, lower complexity, and fewer quality violations, consistent with small, API-driven services. The paper argues that centrality therefore encodes architectural role and semantics rather than code structure, so it supplements rather than duplicates existing metrics. It also finds that subgraph centrality behaves differently from the other centrality scores and correlates with security-related quality metrics, possibly indicating a service's attack surface.

Load-bearing premise

The retained 24 reconstructed graphs are assumed to have missing connections that are unrelated to each service's size, complexity, or quality, so the computed centralities are not biased by reconstruction errors.

Editorial extensions

If this is right

  • Centrality metrics can be used alongside traditional software metrics to detect anti-patterns such as hub-like, nano, and mega services.
  • Ratio-based centralities such as normalized eigenvector or betweenness centrality give comparable thresholds across different systems, unlike raw call counts.
  • Subgraph centrality warrants further investigation as an indicator of security risk and attack surface in microservice architectures.
  • Weak correlations imply that centrality-based testing and refactoring priorities may target different services than size- or complexity-based approaches.
  • Tracking centrality over time could reveal architectural degradation before code-level smells become visible.

Reading between the lines

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

  • If the weak-correlation result generalizes, centrality could serve as a leading indicator of architectural degradation that appears before code smells or quality violations.
  • The reconstruction-error assumption could be tested directly by comparing statically reconstructed dependency graphs with runtime call graphs from tracing or instrumentation on the same systems.
  • The negative correlation between centrality and duplicated blocks may hide coupling through shared libraries, a mechanism the paper raises but does not confirm.
  • Because the analysis covers 53 services from 13 open-source systems, the results are a strong motivation for wider empirical testing rather than a settled law of microservice architecture.
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

4 major / 6 minor

Summary. This paper investigates whether network centrality metrics computed on service dependency graphs (SDGs) provide information about microservice architecture that is not already captured by traditional software metrics (size, complexity, quality). The authors reconstruct SDGs for 24 open-source Java Spring projects using the Code2DFD tool, compute 11 centrality scores for 53 microservices, collect 155 software metrics using Understand, Jasome, and SonarQube, and test Spearman correlations between centrality and software metrics. They report 282 statistically significant correlations out of 902 at alpha=0.01, mostly weak to moderate, and conclude that centrality offers a complementary perspective, with ratio-based centralities promising for anti-pattern detection and subgraph centrality requiring further study. A replication package is provided.

Significance. Should the central claim survive scrutiny, the contribution is useful: it is one of the first empirical mappings between microservice centrality and standard static metrics, and it offers a concrete practical proposal (ratio-based centralities for hub/nano/mega detection). The study merges four existing datasets, uses multiple industrial-strength static analysis tools, reports a detailed project triage with explicit exclusion counts, and releases raw data, scripts, and reconstructed SDGs in a replication package. The main limitations are also honestly acknowledged in the threats-to-validity section, although, as detailed below, some of those acknowledged threats are not adequately addressed.

major comments (4)
  1. [§IV-C1, §VII] The central empirical result rests on the untested assumption that Code2DFD's false-negative connection errors are not systematically related to the software metrics studied. After excluding 88 of 112 projects, the retained 24 SDGs are additionally pre-processed by removing disconnected components and single-connection databases. If the false-negative rate is higher for services with many classes, long call chains, or complex Spring wiring, then degree, betweenness, and closeness are underestimated exactly for services that score high on size or complexity metrics, which would spuriously create or suppress correlations of the kind reported in RQ1 and RQ2. Section VII acknowledges false negatives but does not test whether reconstruction quality is associated with any software metric. Please add a sensitivity analysis, e.g., comparing Code2DFD output against the manually reconstructed DFDs in the microSecEnD dataset (used in Section III), or correlating edge/component ratios and the proportion of removed nodes with the studied SMs. Without such a test, the Section VIII conclusion that CMs are only weakly to moderately correlated with SMs is not securely established.
  2. [§V-B, §VI, §VIII] The paper's own interpretation in Section VI states that the significant correlations arise 'by construction of the problem,' yet the analysis does not separate construction-driven from genuinely informative correlations. Degree centrality is computed on edges that Code2DFD extracts from public API calls, and the size metrics NPM/PMd/CountDeclMethodPublic count the same public methods; likewise Fin/Fout/Si count method calls, so their strong positive correlations with degree centrality (reported in Section V-B) are at least partly definitional. The conclusion in Section VIII that CMs are 'weak to moderately correlated, when statistically significant, with traditional SMs, except when the correlations arise from the SDG's structural properties' is therefore close to a restatement of the method rather than an empirical finding. Please report the correlation results separately for the subset of metrics that are not definitionally tied to SDG edge extraction, and quantify how many of the 282 significant correlations remain after excluding that subset. Also reconcile the 'weak to moderate' summary with the 'strongly positively correlated' wording used for Fin/Fout/Si.
  3. [§IV-D] The 53 microservices are not independent observations: they are nested in only 13 systems, and centrality scores within one system are inter-dependent by construction (e.g., degree scores sum to the total edge count of that system's SDG). Spearman's rho and its p-values as computed in the paper assume independence, so the reported significance levels are likely inflated and the correlation estimates may be dominated by between-system differences rather than within-system relationships between centrality and software metrics. Please account for the nesting (e.g., with mixed-effects models, cluster-robust p-values, or separate per-system analyses) or justify why the dependence does not affect the conclusions.
  4. [§IV-D] The multiple-testing control is insufficient for the claim based on 902 correlations. At alpha=0.01, roughly 9 false positives are expected; while the reported 282 significant correlations far exceed this number, the paper does not control the false discovery rate and does not report confidence intervals for the rho values. Given that many of the 155 metrics are aggregated variants of the same underlying counts (sum/avg/max), a Benjamini-Hochberg adjustment or a table of effect sizes with confidence intervals would strengthen the quantitative support for the '282 cases' result. This is a fixable reporting issue, but it is load-bearing for the precision of the paper's headline number.
minor comments (6)
  1. [§IV-D] The text says 'while testing 155 correlations' but the actual number of pairwise tests is 902; please rephrase to avoid confusion.
  2. [§VII] There is a typo 'predoGitHub' in the External Validity paragraph; it should be 'predominantly GitHub' or similar.
  3. [Figure 2] The label 'Not tree: 36' is unclear; the exclusion criterion is 'significantly fewer connections than components,' which is not exactly 'not a tree' because a tree with N nodes has N-1 edges and many graphs with N-1 edges are trees; consider renaming the category to 'Too few connections' for accuracy.
  4. [§VI] The sentence 'the centrality of microservices are derived' should agree in number; use 'is derived'.
  5. [§IV-C3] The manual package-to-microservice mapping is described briefly; given that this mapping determines the aggregation of all software metrics, a short example and a description of how ambiguous packages (e.g., shared utility packages) were handled would improve replicability.
  6. [§V-C] The interpretation of the negative correlation with security rating is confusing: 'high centrality score correlates to poor security' while 'lower security remediation effort is considered better' — please clarify the direction of the security rating scale and the remediation effort so the reader can follow the argument.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's centrality–software-metric correlations are an observational study, and the one construction-driven correlation is explicitly acknowledged and excluded from the central claim.

full rationale

The paper does not fit a parameter and then rename it as a prediction; it is a correlation study over 53 microservices. The strongest potential circularity is the correlation between degree centrality and public-method counts, since Code2DFD infers SDG edges from public API calls and degree centrality counts those edges. However, the authors explicitly identify this as arising 'by construction of the problem' in Section VI and deliberately exclude such structural correlations from their conclusion: Section VIII claims CMs are weakly-to-moderately correlated with SMs 'except when the correlations arise from the SDG's structural properties.' Acknowledging a definitional link and excluding it from the interpretive claim is not a circular derivation. The choice of Code2DFD is justified by overlapping-author comparison studies [18]–[20], but those support the tool's generalizability and reliability and do not presuppose the centrality–SM correlation results; thus the self-citations are not load-bearing for the paper's central finding. The most serious limitation, that Code2DFD's false negatives may be systematically related to service size, complexity, or quality, is a threat to construct/internal validity rather than a circularity of the derivation chain. Therefore no circular step meeting the evidentiary bar is present.

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

The paper does not introduce new theoretical entities. Its central claim rests on a chain of empirical assumptions: the reconstructed graphs are accurate, the retained sample is representative, and the statistical testing procedure is appropriate. The two hand-chosen parameters (alpha and the tree-edge exclusion rule) shape the results materially. No fitted constants or postulated mechanisms are used.

free parameters (2)
  • significance threshold alpha = 0.01
    Hand-chosen significance level. The authors explicitly reject Bonferroni correction (which would yield 0.00032258), so with 902 tests the expected number of false positives is about 9. This inflates Type I error and affects the count of significant correlations (Section IV-D).
  • project inclusion heuristic (edge count) = at least N-1 edges
    Projects whose reconstructed graph has fewer edges than N-1 are excluded as unreliable (36 of 112 projects). This hand-chosen rule removes a large portion of the sample and may bias the retained set toward denser, better-connected architectures, directly affecting the centrality distributions (Section IV-C1 and Figure 2).
assumptions (3)
  • domain assumption Code2DFD static reconstruction of the SDG approximates the true runtime service dependency graph.
    All centrality scores are computed on these reconstructed graphs. The authors acknowledge false negatives in connection extraction but assume the retained graphs are accurate enough for the analysis (Section IV-C1, Section VII).
  • domain assumption The 24 retained projects are representative of Java Spring OSS microservice systems after exclusions.
    112 projects were reduced to 24 based on reconstruction quality, crashes, and manual validation. Representativeness is assumed rather than demonstrated, and the authors note selection bias as a threat in Section VII.
  • domain assumption Spearman's rho with alpha = 0.01 is a valid inference procedure for this dataset.
    Normality is rejected for most metrics, justifying Spearman, but no multiple-comparison correction is applied across 902 tests. The choice of alpha is defended by Type II error concerns but risks Type I errors (Section IV-D).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Network Centrality as a New Perspective on Microservice Architecture." pith.science (2026). https://pith.science/paper/BUQEVA56

@misc{pith2026250113520,
  author       = {Pith},
  title        = {Pith review of: Network Centrality as a New Perspective on Microservice Architecture},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BUQEVA56}},
  note         = {Machine review of arXiv:2501.13520}
}
read the original abstract

Context: Over the past decade, the adoption of Microservice Architecture (MSA) has led to the identification of various patterns and anti-patterns, such as Nano/Mega/Hub services. Detecting these anti-patterns often involves modeling the system as a Service Dependency Graph (SDG) and applying graph-theoretic approaches. Aim: While previous research has explored software metrics (SMs) such as size, complexity, and quality for assessing MSAs, the potential of graph-specific metrics like network centrality remains largely unexplored. This study investigates whether centrality metrics (CMs) can provide new insights into MSA quality and facilitate the detection of architectural anti-patterns, complementing or extending traditional SMs. Method: We analyzed 24 open-source MSA projects, reconstructing their architectures to study 53 microservices. We measured SMs and CMs for each microservice and tested their correlation to determine the relationship between these metric types. Results and Conclusion: Among 902 computed metric correlations, we found weak to moderate correlation in 282 cases. These findings suggest that centrality metrics offer a novel perspective for understanding MSA properties. Specifically, ratio-based centrality metrics show promise for detecting specific anti-patterns, while subgraph centrality needs further investigation for its applicability in architectural assessments.

Figures

Figures reproduced from arXiv: 2501.13520 by the authors.

Figure 1
Figure 1. Data collection and analysis process. absence of many connections will make the centrality scores unreliable. Thus, we have to exclude these 36 projects from the analysis. After the manual validation, we are left with 24 projects, which we obtained from Code2DFD output reliable enough to answer the RQs [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Different categories of collected projects. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Heat-map of correlation of microservice centrality with size metrics. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Heat-map of correlation of microservice centrality with quality metrics. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Heat-map of correlation of microservice centrality with complexity metrics. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Heat-map of correlation between centrality metrics. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

67 extracted references · 53 canonical work pages

  1. [1]

    From static code analysis to visual models of microservice architecture,

    T. Cerny, A. S. Abdelfattah, J. Yero, and D. Taibi, “From static code analysis to visual models of microservice architecture,” Cluster Computing, pp. 1–26, 2024

  2. [2]

    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 2022 IEEE International Conference on Services Computing (SCC) . IEEE, 2022, pp. 31–38

  3. [3]

    Using microservice telemetry data for system dynamic analysis,

    A. Al Maruf, A. Bakhtin, T. Cerny, and D. Taibi, “Using microservice telemetry data for system dynamic analysis,” in 2022 IEEE International Conference on Service-Oriented System Engineering (SOSE) . IEEE, 2022, pp. 29–38

  4. [4]

    Evolution and anti- patterns visualized: Microprospect in microservice architecture,

    L. Adams, A. S. Abdelfattah, M. S. Hossain Chy, S. Perry, P. Harris, T. Cerny, D. Amoroso d’Aragona, and D. Taibi, “Evolution and anti- patterns visualized: Microprospect in microservice architecture,” in European Conference on Software Architecture . Springer, 2023, pp. 309–325

  5. [5]

    Industry 4.0 and Microservices with the power of Graphs,

    H. Farsi, “Industry 4.0 and Microservices with the power of Graphs,” International Workshop of Services and Industry of the Future (IWSIF 2022), Oct. 2022, poster

  6. [6]

    Service dependency graph analysis in microservice architecture,

    E. Gaidels and M. Kirikova, “Service dependency graph analysis in microservice architecture,” in Perspectives in Business Informatics Research: 19th International Conference on Business Informatics Re- search, BIR 2020, Vienna, Austria, September 21–23, 2020, Proceedings

  7. [7]

    Evaluation of microservice architectures: A metric and tool-based approach,

    T. Engel, M. Langermeier, B. Bauer, and A. Hofmann, “Evaluation of microservice architectures: A metric and tool-based approach,” in Information Systems in the Big Data Era, J. Mendling and H. Mouratidis, Eds. Cham: Springer International Publishing, 2018, pp. 74–89

  8. [8]

    Uncovering the hidden risks: The impor- tance of predicting bugginess in untouched methods,

    M. Esposito and D. Falessi, “Uncovering the hidden risks: The impor- tance of predicting bugginess in untouched methods,” in 2023 IEEE 23rd International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2023, pp. 277–282

Show all 67 references
  1. [9]

    Using topological features of microservice call graphs to predict the response time variation,

    B. Fındık, “Using topological features of microservice call graphs to predict the response time variation,” Master’s thesis, Middle East Technical University, 2024

  2. [10]

    Localizing faults in cloud systems,

    L. Mariani, C. Monni, M. Pezz ´e, O. Riganelli, and R. Xin, “Localizing faults in cloud systems,” in 2018 IEEE 11th International Conference on Software Testing, Verification and Validation (ICST) . IEEE, 2018, pp. 262–273

  3. [11]

    Micro- diag: Fine-grained performance diagnosis for microservice systems,

    L. Wu, J. Tordsson, J. Bogatinovski, E. Elmroth, and O. Kao, “Micro- diag: Fine-grained performance diagnosis for microservice systems,” in 2021 IEEE/ACM International Workshop on Cloud Intelligence (Cloud- Intelligence), 2021, pp. 31–36

  4. [12]

    Ms-rank: Multi-metric and self- adaptive root cause diagnosis for microservice applications,

    M. Ma, W. Lin, D. Pan, and P. Wang, “Ms-rank: Multi-metric and self- adaptive root cause diagnosis for microservice applications,” in 2019 IEEE International Conference on Web Services (ICWS) , 2019, pp. 60– 67

  5. [13]

    Analyzing organizational structure of microservice projects based on contributor collaboration,

    X. Li, A. S. Abdelfattah, J. Yero, D. A. d’Aragona, T. Cerny, and D. Taibi, “Analyzing organizational structure of microservice projects based on contributor collaboration,” in 2023 IEEE International Con- ference on Service-Oriented System Engineering (SOSE) . IEEE, 2023, pp. 1–8

  6. [14]

    Evaluating microservice or- ganizational coupling based on cross-service contribution,

    X. Li, D. A. d’Aragona, and D. Taibi, “Evaluating microservice or- ganizational coupling based on cross-service contribution,” in Interna- tional Conference on Product-Focused Software Process Improvement . Springer, 2023, pp. 435–450

  7. [15]

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

    R. Hutcheson, A. Blanchard, N. Lambaria, J. Hale, D. Kozak, A. S. Abdelfattah, and T. Cerny, “Software architecture reconstruction for microservice systems using static analysis via graalvm native image,” in 2024 IEEE International Conference on Software Analysis, Evolution an...

  8. [16]

    An extensive comparison of static application security testing tools,

    M. Esposito, V . Falaschi, and D. Falessi, “An extensive comparison of static application security testing tools,” in Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering, ser. EASE ’24. New York, NY , USA: Association for Compu...

  9. [17]

    Validate: A deep dive into vulnerability prediction datasets,

    M. Esposito and D. Falessi, “Validate: A deep dive into vulnerability prediction datasets,” Information and Software Technology , p. 107448, 2024

  10. [18]

    Tools reconstructing microservice architecture: A systematic mapping study,

    A. Bakhtin, X. Li, J. Soldani, A. Brogi, T. Cerny, and D. Taibi, “Tools reconstructing microservice architecture: A systematic mapping study,” Agility with Microservices Programming, co-located with ECSA , vol. 2023, 2023

  11. [19]

    Springer, 2020, pp. 128–139

  12. [20]

    Comparison of static analysis architecture recovery tools for microservice applications: Registered report,

    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: Registered report,” arXiv preprint arXiv:2403.06941, 2024

  13. [21]

    Comparison of static analysis architecture recovery tools for microservice applications: Preprint,

    ——, “Comparison of static analysis architecture recovery tools for microservice applications: Preprint,” arXiv preprint arXiv:2412.08352 , 2024

  14. [23]

    Replication package for

    A. Bakhtin, M. Esposito, L. Valentina, and D. Taibi, “Replication package for ”network centrality as a new perspective on microservice architecture”,” 2025. [Online]. Available: https://doi.org/10.5281/zenodo.14176227

  15. [24]

    Are architectural smells independent from code smells? an empirical study,

    F. A. Fontana, V . Lenarduzzi, R. Roveda, and D. Taibi, “Are architectural smells independent from code smells? an empirical study,” Journal of Systems and Software , vol. 154, pp. 139–156, 2019

  16. [25]

    On the diffuseness of technical debt items and accuracy of remediation time when using sonarqube,

    M. T. Baldassarre, V . Lenarduzzi, S. Romano, and N. Saarim ¨aki, “On the diffuseness of technical debt items and accuracy of remediation time when using sonarqube,” Information and Software Technology, vol. 128, p. 106377, 2020

  17. [26]

    Network centrality: an introduction,

    F. A. Rodrigues, “Network centrality: an introduction,” A mathematical modeling approach from nonlinear dynamics to complex systems , pp. 177–196, 2019

  18. [27]

    Centrality and network flow,

    S. P. Borgatti, “Centrality and network flow,” Social networks, vol. 27, no. 1, pp. 55–71, 2005

  19. [28]

    Centrality measures in networks,

    F. Bloch, M. O. Jackson, and P. Tebaldi, “Centrality measures in networks,” Social Choice and Welfare, vol. 61, no. 2, pp. 413–453, 2023

  20. [29]

    A curated dataset of microservices-based systems,

    M. I. Rahman, S. Panichella, D. Taibi et al. , “A curated dataset of microservices-based systems,” arXiv preprint arXiv:1909.03249 , 2019

  21. [30]

    Towards a reference dataset of microservice-based applications,

    A. Brogi, A. Canciani, D. Neri, L. Rinaldi, and J. Soldani, “Towards a reference dataset of microservice-based applications,” in Software Engineering and Formal Methods: SEFM 2017 Collocated Workshops: DataMod, FAACS, MSE, CoSim-CPS, and FOCLASA, Trento, Italy, September 4-5, ...

  22. [31]

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

    S. Schneider, T. ¨Ozen, M. Chen, and R. Scandariato, “microsecend: A dataset of security-enriched dataflow diagrams for microservice appli- cations,” in 2023 IEEE/ACM 20th International Conference on Mining Software Repositories (MSR) . IEEE, 2023, pp. 125–129

  23. [32]

    A dataset of microservices- based open-source projects,

    D. A. d’Aragona, A. Bakhtin, X. Li, R. Su, L. Adams, E. Aponte, F. Boyle, P. Boyle, R. Koerner, J. Leeet al., “A dataset of microservices- based open-source projects,” in Proceedings of the 21st International Conference on Mining Software Repositories , 2024, pp. 504–509

  24. [33]

    A feature dataset of microservices-based systems,

    W. Yang, B. Song, Y . Xing, Y . Lyu, H. Cui, Z. Liang, and Z. Tu, “A feature dataset of microservices-based systems,” in International Conference on Service Science . Springer, 2024, pp. 73–87

  25. [34]

    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,” Journal of Systems and Software , vol. 202, p. 111722, 2023

  26. [35]

    On the correlation between size and metric validity,

    Y . Gil and G. Lalouche, “On the correlation between size and metric validity,”Empirical Software Engineering, vol. 22, no. 5, pp. 2585–2611, 2017

  27. [36]

    Early Career De- velopers’ Perceptions of Code Understandability. A Study of Complexity Metrics,

    M. Esposito, A. Janes, T. Kilamo, and V . Lenarduzzi, “Early Career De- velopers’ Perceptions of Code Understandability. A Study of Complexity Metrics,” A Study of Complexity Metrics , 2023

  28. [37]

    Toward understanding the impact of refac- toring on program comprehension,

    G. Sellitto, E. Iannone, Z. Codabux, V . Lenarduzzi, A. De Lucia, F. Palomba, and F. Ferrucci, “Toward understanding the impact of refac- toring on program comprehension,” in 2022 IEEE International Con- ference on Software Analysis, Evolution and Reengineering (SANER) , 2022,...

  29. [38]

    Automatically measuring the maintainability of service- and microservice-based systems: a lit- erature review,

    J. Bogner, S. Wagner, and A. Zimmermann, “Automatically measuring the maintainability of service- and microservice-based systems: a lit- erature review,” in Proceedings of the 27th International Workshop on Software Measurement and 12th International Conference on Software Pro...

  30. [39]

    Performance and complexity comparison of ser- vice oriented architecture and microservices architecture,

    V . Raj and R. Sadam, “Performance and complexity comparison of ser- vice oriented architecture and microservices architecture,” International Journal of Communication Networks and Distributed Systems , vol. 27, no. 1, pp. 100–117, 2021

  31. [40]

    Addressing security issues during decomposing golang monolithic applications into microservices through code analysis,

    A. W. Hou, K.-H. Hsu, and Y .-Y . Chen, “Addressing security issues during decomposing golang monolithic applications into microservices through code analysis,” in 2024 10th International Conference on Applied System Innovation (ICASI) . IEEE, 2024, pp. 445–447

  32. [41]

    A comparative study of network centrality metrics in identifying key classes in software,

    M. Wang and W. Pan, “A comparative study of network centrality metrics in identifying key classes in software,”Journal of Computational Information Systems, vol. 8, no. 24, pp. 10 205–10 212, 2012

  33. [42]

    Software fault localization based on centrality measures,

    L.-Z. Zhu, B.-B. Yin, and K.-Y . Cai, “Software fault localization based on centrality measures,” in 2011 IEEE 35th Annual Computer Software and Applications Conference Workshops . IEEE, 2011, pp. 37–42

  34. [43]

    Practical service placement approach for microservices archi- tecture,

    M. Selimi, L. Cerd `a-Alabern, M. S ´anchez-Artigas, F. Freitag, and L. Veiga, “Practical service placement approach for microservices archi- tecture,” in 2017 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID) , 2017, pp. 401–410

  35. [44]

    Catalog and detection techniques of microservice anti-patterns and bad smells: A tertiary study,

    T. Cerny, A. S. Abdelfattah, A. Al Maruf, A. Janes, and D. Taibi, “Catalog and detection techniques of microservice anti-patterns and bad smells: A tertiary study,” Journal of Systems and Software , vol. 206, p. 111829, 2023

  36. [45]

    Wohlin, P

    C. Wohlin, P. Runeson, M. H ¨ost et al. , Experimentation in Software Engineering. Springer, 2012

  37. [46]

    On effort-aware metrics for defect prediction,

    J. C ¸ arka, M. Esposito, and D. Falessi, “On effort-aware metrics for defect prediction,” Empirical Software Engineering, vol. 27, no. 6, p. 152, 2022

  38. [47]

    Evaluating time-dependent methods and seasonal effects in code tech- nical debt prediction,

    M. Robredo, N. Saarimaki, D. Taibi, R. Penaloza, and V . Lenarduzzi, “Evaluating time-dependent methods and seasonal effects in code tech- nical debt prediction,” arXiv preprint arXiv:2408.08095 , 2024

  39. [48]

    Resolving security issues via quality- oriented refactoring: A user study,

    D. Gigante, F. Pecorelli, V . Santa Barletta, A. Janes, V . Lenarduzzi, D. Taibi, and M. T. Baldassarre, “Resolving security issues via quality- oriented refactoring: A user study,” in 2023 ACM/IEEE International Conference on Technical Debt (TechDebt) . IEEE, 2023, pp. 82–91

  40. [49]

    Technical debt diffuseness in the apache ecosystem: A differentiated replication,

    D. A. d’Aragona, F. Pecorelli, M. T. Baldassarre, D. Taibi, and V . Lenarduzzi, “Technical debt diffuseness in the apache ecosystem: A differentiated replication,” in 2023 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2023, pp. 825–833

  41. [50]

    Technical debt prioritization: State of the art. a systematic literature review,

    V . Lenarduzzi, T. Besker, D. Taibi, A. Martini, and F. A. Fontana, “Technical debt prioritization: State of the art. a systematic literature review,” arXiv preprint arXiv:1904.12538 , 2019

  42. [51]

    How long do junior developers take to remove technical debt items?

    V . Lenarduzzi, V . Mandi´c, A. Katin, and D. Taibi, “How long do junior developers take to remove technical debt items?” in Proceedings of the 14th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM) , 2020, pp. 1–6

  43. [52]

    Object Management Group, Business Process Model and Notation (BPMN) Version 2.0, January 2011, official Specification

  44. [53]

    E. W. Weisstein, “Tree,” 2025, accessed: 2025-01-07

  45. [54]

    Database per service pattern,

    C. Richardson, “Database per service pattern,” https://microservices.io/ patterns/data/database-per-service.html, 2019, accessed: 2025-01-07

  46. [55]

    Microservices database design: Strategies and patterns,

    Baeldung, “Microservices database design: Strategies and patterns,” https://www.baeldung.com/cs/microservices-db-design, 2024, accessed: 2025-01-07

  47. [56]

    Enhancing the defectiveness prediction of methods and classes via JIT,

    D. Falessi, S. M. Laureani, J. C ¸ arka, M. Esposito, and D. A. d. Costa, “Enhancing the defectiveness prediction of methods and classes via JIT,” Empir. Softw. Eng., vol. 28, no. 2, p. 37, 2023

  48. [57]

    Asymptotic theory of certain

    T. W. Anderson and D. A. Darling, “Asymptotic theory of certain” goodness of fit” criteria based on stochastic processes,” The annals of mathematical statistics, pp. 193–212, 1952

  49. [58]

    Descriptive statistics and normality tests for statistical data,

    P. Mishra, C. M. Pandey, U. Singh, A. Gupta, C. Sahu, and A. Keshri, “Descriptive statistics and normality tests for statistical data,” Annals of cardiac anaesthesia, vol. 22, no. 1, pp. 67–72, 2019

  50. [59]

    An analysis of variance test for normality (complete samples),

    S. S. Shapiro and M. B. Wilk, “An analysis of variance test for normality (complete samples),” Biometrika, vol. 52, no. 3-4, pp. 591–611, 1965

  51. [60]

    Edf statistics for goodness of fit and some compar- isons,

    M. A. Stephens, “Edf statistics for goodness of fit and some compar- isons,” Journal of the American statistical Association , vol. 69, no. 347, pp. 730–737, 1974

  52. [61]

    Tests based on edf statistics,

    ——, “Tests based on edf statistics,” in Goodness-of-fit-techniques. Routledge, 2017, pp. 97–194

  53. [62]

    The proof and measurement of association between two things,

    C. Spearman, “The proof and measurement of association between two things,” The American Journal of Psychology, vol. 15, no. 1, pp. 72–101, 1904

  54. [63]

    Vii. note on regression and inheritance in the case of two parents,

    K. Pearson, “Vii. note on regression and inheritance in the case of two parents,” proceedings of the royal society of London , vol. 58, no. 347- 352, pp. 240–242, 1895

  55. [64]

    Dancey, Statistics without maths for psychology

    C. Dancey, Statistics without maths for psychology. Prentice Hall, 2007

  56. [65]

    Choosing the level of significance: A decision- theoretic approach,

    J. H. Kim and I. Choi, “Choosing the level of significance: A decision- theoretic approach,” Abacus, vol. 57, no. 1, pp. 27–71, 2021

  57. [66]

    On the correlation between Architectural Smells and Static Analysis Warnings,

    M. Esposito, M. Robredo, F. A. Fontana, and V . Lenarduzzi, “On the correlation between Architectural Smells and Static Analysis Warnings,” CoRR, vol. abs/2406.17354, 2024, arXiv: 2406.17354

  58. [67]

    Bell system technical journal, volume 57, number 6,

    B. T. Laboratories, “Bell system technical journal, volume 57, number 6,” Bell System Technical Journal, vol. 57, no. 6, pp. 1899–1919, 1978, accessed: 2024-11-18

  59. [68]

    Structural coupling for microservices

    S. Panichella, M. I. Rahman, and D. Taibi, “Structural coupling for microservices.” in CLOSER, M. Helfert, D. Ferguson, and C. Pahl, Eds. SCITEPRESS, 2021, pp. 280–287

Pith tools

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