Source-linked AI summary
CC4M: Code Clone Analysis and Visualization for Microservices
Gen Kawamata, Yuki Ota, Norihiro Yoshida, Shiyu Yang, Erina Makihara, Katsuro Inoue
TL;DR
Microservice-aware clone analysis lacks service-boundary and co-modification awareness despite reported cross-service, co-modified clones. CC4M enriches clone pairs with these and file-category data, computes metrics, and visualizes them; usage scenarios illustrate potential change-impact scope, with limitations from Type-2 detection and estimated service boundaries.
Problem
Existing clone tools lack service-boundary and co-modification awareness for analyzing cross-service clones and their maintenance impact.
Method
CC4M detects Type-2 clones, identifies services, enriches clone pairs with service-boundary, co-modification, and file-category information, computes metrics, and visualizes the results.
Results
CC4M usage scenarios identify clone sets spanning services, including duplicated Order.java data across nine services, and support analysis of potential change-impact scope.
Takeaways & Limitations
Metric-based filtering and explicit service boundaries help prioritize clones with potentially higher maintenance impact and identify changes that may need propagation across services.
Takeaways & Limitations
CC4M detects only Type-2 clones, while estimated service boundaries can contain errors that affect within-service and cross-service classification.
Abstract
from arXiv · showhide
Microservice architecture supports software evolution by decomposing a system into small, loosely coupled services that can be deployed independently. Contrary to the expectation of high modularity, prior studies have reported that code clones exist across service boundaries, some of which are co-modified in the same version. Such clones may require changes to be propagated across service boundaries, thereby undermining service independence and increasing maintenance costs. However, existing tools do not support microservice-aware clone analysis. We present CC4M, a microservice-aware clone analysis and visualization tool. CC4M detects and enriches clone pairs with service-boundary, co-modification, file-category, and metric information. The enriched clones are visualized in an interactive scatter plot with explicit service boundaries, supporting metric-based filtering to prioritize clones with potentially higher maintenance impact. Using an open-source microservice application, we illustrate how CC4M helps identify the potential impact scope of code changes. A demo video and the tool are available at https://www.youtube.com/watch?v=0xOIQPFbkUg and https://doi.org/10.5281/zenodo.21204195, respectively.
I. INTRODUCTION
CC4M addresses the gap in microservice-aware clone analysis by combining service-boundary, co-modification, and file-category information with metrics and visualizations for prioritizing maintenance impact.
- Cross-service clones have been reported and can be co-modified across service boundaries between consecutive releases.
- Cross-service clones may propagate changes across services and undermine service independence, while existing tools organize clone information by files or program structure.
- Existing tools lack service-boundary awareness for distinguishing within-service from cross-service clones and clarifying change-impact scope.
- Existing tools also lack co-modification awareness, limiting identification of clones that affect maintainability.
- CC4M enriches clone pairs with service-boundary, co-modification, and file-category information, then computes metrics such as service span and co-modification frequency.
- CC4M provides explicit service boundaries in a scatter plot and a Metric View for metric-based prioritization and drill-down.
II. CC4M
CC4M analyzes clones from a Git repository by identifying microservices, detecting clone pairs, enriching them with contextual information, and presenting the results through multiple views.
- CC4M takes a GitHub URL for a Dockerized microservice system and provides Statistics, Scatter Plot, and Metric Views.
- CC4M identifies microservice boundaries, detects Type-2 clone pairs, and enriches each pair with service-boundary, co-modification, and file-category information.
- CLAIM uses Docker Compose files and related Dockerfiles to extract service definitions and estimate directories corresponding to application microservices.
- CC4M assigns source files to microservices using CLAIM’s directory information, classifying clone pairs as within-service or cross-service.
B. Code Clone Detection
CC4M detects Type-2 clones after selecting supported source languages and filtering import-like declarations, while its detector interface permits replacement by another tool.
- CC4M uses GitHub Linguist to identify repository languages and selects files whose languages CCFinderSW supports.
- Before detection, CC4M comments out import, include, and package declarations in a temporary copy to reduce trivial clones.
- CCFinderSW produces Type-2 clone pairs whose fragments differ only in whitespace, comments, and identifiers such as variable and type names.
- CC4M converts detector results into a common JSON format, making the detector replaceable through a converter to that format.
- CCFinderSW is the default because its grammars cover multiple languages, it requires no training data, behaves deterministically, and is lightweight for repeated detection.
C. Co-modification Analysis
CC4M identifies co-modified clone pairs by tracking fragments across selected Git commits and checking whether both fragments were modified in at least one common commit.
- Users can select commits at a specified interval, merge commits, or Git-tag-associated commits for co-modification analysis.
- For each target commit, CC4M detects clones and tracks each fragment across adjacent target commits using line correspondences from git diff.
- A fragment is considered modified when lines in its corresponding range are added, deleted, or changed between adjacent target commits.
- A clone pair is co-modified when the two fragments are both modified in the same commit at least once.
D. Clone Pair Classification
CC4M annotates clone pairs with service-boundary, co-modification, and file-category information to support microservice-aware analysis.
- CC4M classifies each clone pair as within-service or cross-service using computed microservice mappings.
- Each file is classified as Test, Config, Data, or Logic using path and file-name patterns applied in priority order.
- Clone-pair categories are derived from the categories of the two containing files, including Mixed for test and non-test combinations.
E. Clone Metrics Computation
CC4M computes clone-set, service, and file metrics to prioritize and filter numerous enriched clone pairs for maintenance-oriented inspection.
- CC4M characterizes clone sets, services, and files with metrics because the enriched clone pairs make individual inspection impractical.
- The MS(s) metric lists the microservices containing fragments in a clone set, with |MS(s)| measuring its service span.
- CM(s) contains commits in which at least two fragments of a clone set are modified, and |CM(s)| counts those co-modification commits.
- The co-modification fragment ratio cmr(s) is the fraction of clone-set fragments modified in at least one co-modification commit.
- CC4M displays |MS(s)|, |CM(s)|, and cmr(s) as service span, co-modification frequency, and co-modification fragment ratio, alongside service- and file-level metrics.
F. Visualization
CC4M offers project statistics, a service-boundary-aware scatter plot, and metric-driven views for filtering, prioritizing, and inspecting clone relationships.
- CC4M provides Statistics View, Scatter Plot, and Metric View for project overview, spatial visualization, and metric-driven filtering and drill-down.
- Statistics View summarizes services, files, clone sets, and lines of code, breaks them down by language, and ranks services containing the most clones.
- The Scatter Plot places the same source files on both axes, groups them by service, and marks service boundaries with gray dotted lines.
- Diagonal blocks represent within-service clone pairs, while points outside them represent cross-service pairs; color intensity indicates overlapping clone-pair counts.
- Users can filter by service scope, file category, and co-modification count, then inspect selected clone fragments with surrounding source code.
- Metric View offers microservice-based, clone-set-based, and file-based perspectives with combined metric filters for narrowing results.
III. USAGE SCENARIO
Usage scenarios on TRAIN TICKET show how CC4M prioritizes cross-service clones and exposes their potential change impact through metrics and code inspection.
- III. USAGE SCENARIO: In TRAIN TICKET, CC4M identified 41 microservices, 1,423 source files, and 10,333 clone sets; the complete analysis took 43 minutes.
- Scenario 1: Scenario 1 filters cross-service, co-modified clones to locate concentrated business-logic duplication for detailed inspection.
- Scenario 2: Scenario 2 prioritizes widely distributed Data clones with incomplete follow-up, finding an Order.java entity duplicated across 9 services with cmr(s) = 0.67.
- Scenario 2: Only 6 of those 9 fragments were modified in the co-modification commit, leaving 3 services that did not follow the update.
- Scenario 3: Scenario 3 finds an Account.java clone set spanning 3 services with co-modification frequency 2 and cmr(s) = 1.0, indicating two coordinated modifications.
IV. RELATED WORK
Prior work established that cross-service clones and their co-modification warrant service-aware analysis, while existing visualization tools did not integrate service boundaries and co-modification history. CC4M addresses this gap with service-aware clone metrics and explicit service-boundary visualization.
- 56.7% of cross-service clone pairs in 22 Java microservice projects occur in data-related files.
- Existing clone visualizations organize information around files and program structures rather than service boundaries.
- Existing tools support metric-based filtering and refactoring-candidate extraction, but do not target clone relationships across microservice architecture.
- No existing tool integrates service boundaries and co-modification history into clone visualization, leaving no directly comparable quantitative baseline for CC4M.
- CC4M overlays explicit service boundaries on scatter-plot axes and defines service-aware metrics including service span and co-modification frequency.
V. LIMITATIONS
CC4M’s analysis is constrained by Type-2 clone detection, required project artifacts, estimated service boundaries, and metrics that are prioritization aids rather than validated risk measures.
- Type-3 clones and clone pairs that diverged beyond Type-2 similarity before the analyzed snapshot fall outside CC4M’s detection scope.Its co-modification analysis covers only detected Type-2 clone pairs in the supplied snapshot.
- CC4M requires Docker Compose and Dockerfiles, supported source languages, and Git history for co-modification analysis.
- Estimated service boundaries may contain errors because CLAIM uses static analysis; prior work reports 82.0% microservice identification accuracy.Boundary errors directly affect whether clone pairs are classified as within-service or cross-service.
- Clone metrics are prioritization aids rather than validated risk measures because many clones are rarely changed and inconsistent changes are infrequent.CC4M focuses inspection rather than automatically flagging clones as defects.
VI. CONCLUSION AND FUTURE WORK
The paper concludes that CC4M integrates microservice identification, Type-2 clone detection, co-modification analysis, file-category classification, metrics, and service-boundary visualization. Future work will extend detection to Type-3 clones and evaluate usefulness during microservice maintenance tasks.
- CC4M integrates microservice identification, Type-2 clone detection, co-modification analysis, file-category classification, clone metrics, and explicit service-boundary visualization.
- Future work will extend CC4M to Type-3 clones by integrating detectors such as MSCCD.
- Future work will evaluate CC4M’s usefulness with developers performing microservice maintenance tasks.