arXiv CSopen access

What Characterizes Pairwise Modular Smells?

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

1

What Characterizes Pairwise Modular Smells?

arXiv:2606.22576v1 [cs.SE] 21 Jun 2026

Chenxing Zhong, Daniel Feitosa, Paris Avgeriou, Huang Huang, Wei Song, and He Zhang Abstract—Enhancing the modular structure of existing systems has attracted substantial research interest, primarily through (1) software modularization and (2) identifying design issues (e.g., smells) as refactoring opportunities; however, both approaches often prove impractical to guide effective improvement. Inspired by both aforementioned approaches, our previous study introduced a novel and practical architectural smell – called Pairwise Modular Smell (or PairSmell) – for identifying flawed architectural decisions that necessitate further examination. PairSmell is defined as the deviations between the actual modular relation (MR) and the ‘apt MR’– an MR agreed on by multiple modularization tools (as raters). Although PairSmell has shown its relevance, the reliance on external modularization tools makes it a relatively obscure concept within the community, which in turn may threaten its validity to be used in inspecting software module structure. The objective of this study is to explain PairSmell from the perspective of pair characteristics. To this end, we first conduct a rapid review to collect and synthesize 19 pair characteristics that have been used in the literature to represent relationships between two entities. The collected characteristics are then used to train machine learning models for predicting two forms of PairSmell – inapt separated pairs InSep and inapt collocated pairs InCol , based on a curated dataset of over 6,135,000 pairs of entities derived from 11 open-source Java projects. The trained models achieve up to a 58.6% improvement in ROC-AUC over the baselines. The interpretation of the models reveals that the most influential features for InSep are out-going dependencies, terms shared with others, and declared fields; while those for InCol include semantic similarity based on tf-idf, terms shared between the pair, terms shared with others, and in-going dependencies. We complement the work with a series of practical examples to illustrate how the influential pair characteristics impact the occurrence of PairSmell. Among our findings, a high number of out-going dependencies of a separated pair may raise questions about the separation, while a low level of shared terms may not justify collocating the two entities. Index Terms—Modular Structure, Architectural Smell, Interpretable Machine Learning

✦

1

I NTRODUCTION

Software Modularity is an essential quality attribute reflecting how a system is structured into different parts (i.e., modules), and allowing complex software to be manageable [1] and reusable [2]. This attribute has demonstrated a substantial impact on software reuse [2], and has been considered in various modern design scenarios, e.g., microservices-based systems [3] and LLM-enabled systems [4]. Nevertheless, determining appropriate modules can be challenging in practice. This is because modules can evolve quickly [5], e.g., due to changing functional or non-functional requirements. Modules that worked well in the past might not fit optimally into the current system. Substantial research effort has focused on providing methodological support to improve the modularity of existing systems [5]–[8], primarily on two directions. On the one hand, software modularization techniques search for a (near-) optimal modular solution to replace the original modules. • • • •

Chenxing Zhong and Wei Song are with the Nanjing University of Science and Technology, Nanjing 210094, China. Email: [email protected]; [email protected] Daniel Feitosa and Paris Avgeriou are with the University of Groningen, Groningen 9700AB, the Netherlands. Email: [email protected]; [email protected] Huang Huang is with State Grid Nanjing Power Supply Company, Nanjing 210000, China. Email: [email protected] He Zhang is with the State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing 210093, China. E-mail: [email protected]

Manuscript received June 30, 2025. (Corresponding author: Wei Song, He Zhang)

However, since such solutions often require extensive and costly changes to the original systems, developers rarely implement them. On the other hand, some approaches identify issues (e.g., anti-patterns and smells [9]–[11]) in modular structures as refactoring opportunities in subsequent development to improve the degraded modules. The problem is that most of the issues are coarse-grained, i.e. at the module level, making it difficult to determine refactoring strategies [12]. A typical example is Cycle Dependency [13], where the chain of relations among several modules breaks the desirable acyclic nature of modules’ dependency structure. Although we know that cycle dependencies should be broken, it is difficult to decide which dependencies to break [14]. Building on both aforementioned directions, a novel architectural smell, Pairwise Modular Smell (PairSmell), was introduced in our previous study [15] to inspect and improve the modular structure of existing software. This smell focuses on Modular Relation (MR), i.e. whether an entity (file) pair is collocated or separated within the same module. The idea is that, if multiple modularization tools consensually designate the MR of a pair as either collocated or separated, this is considered the ground truth and the relation is termed ‘apt MR’. In contrast, if the actual MR of a pair violates the apt MR, this violation indicates an inappropriate architectural decision [16] — an instance of PairSmell. More specifically, detailed deviations of the actual MR from the apt MR give rise to two specific forms of PairSmell: InSep where the apt MR for a separated pair is instead collocated, and InCol, where the apt MR for a collocated pair is instead separated. Fig. 1 depicts an instance of InSep ,

0000–0000/00$00.00 © 2021 IEEE

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025 1 KStreamTransformValues.java 2 KTableFilter.java 3 KTableImpl.java 4 KTableKTableAbstractJoin.java 5 KTableKTableLeftJoin.java 6 KTableKTableRightJoin.java 7 KTableReduce.java 8 Processor.java

1 2 3 4 5 6 7 8 (1) 0.75 0.75 0.75 0.75 0.75 1 0.75 0.75 (2) 1 0.75 0.75 0.75 0.75 1 0.75 1 (3) 0.75 0.75 0.75 0.75 1 0.75 0.75 0.75 (4) 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 (5) 0.75 0.75 0.75 0.75 0.75 0.75 0.75 0.75 (6) 0.75 0.75 1 0.75 0.75 0.75 0.75 0.75 (7) 0.75 0.75 1 1 0.75 0.75 0.75 0.75 (8)

Fig. 1: An InSep example in the project Kafka. Each number indicates the average frequency that two entities are grouped together by tools. Entities in a lined rectangle actually belong to one module.

where Processor is located in a separate module from all other files. However, we can see from the cells annotated with 1 that all tools assigned it to be collocated with files KTableFilter.java (row 2) and KTableImpl.java (row 3), suggesting that the two entities might be highly related. Our empirical study on 260,003 instances found that PairSmell (1) is prevalent in real software projects, (2) can be detrimental by inducing 190% more cross-module co-changes and 35% less within-module co-changes than appropriately collocated or separated pairs respectively, and (3) can persist long if left unaddressed. In a nutshell, PairSmell offers fundamental insights that help developers to inspect and improve software modules more effectively. This study enhances the potential of PairSmell, by making it more explainable. Specifically, PairSmell is defined as the deviations between the actual MR and the ‘apt MR’, which itself is derived using multiple modularization tools in a largely opaque or “black box” manner. The output of modularization tools is used directly as the input to identify PairSmells, following the consensus clustering strategy [17], [18]. As a result, for a pair detected as a PairSmell instance, say Processor.java and KTableFilter.java in Fig. 1, what we know is that all modularization tools agreed on their MR as collocated. However, it is hard to understand why this particular pair exhibits a PairSmell while others not – that is, what characteristics make some pairs more prone to being affected by PairSmell. Answering this question would not only deepen our understanding of PairSmell, but also help explain why such smells are detrimental to a system’s maintenance and evolution – thereby motivating potential refactoring efforts. The objective of this study is particularly to identify the characteristics that make certain pairs more susceptible to PairSmell. To achieve this, we first collect and synthesize a set of pair characteristics that can theoretically represent the relationships between two entities. We conduct a rapid review of 178 primary studies, from which we extract 19 distinct pair characteristics (features). These features capture six dimensions, including relatedness, distance, independence, complexity, cohesion, and size. Next, we employ these features as independent variables, together with two metrics indicating the presence of PairSmell – InSep and InCol – as dependent variables to train machine learning models. Our experiments, conducted on 6,028,271 separated and 107,606 collocated pairs, demonstrate that the selected characteristics can effectively distinguish InSep from other separated pairs, and InCol from other collocated pairs, with ROC-AUC values exceeding the baselines by up to 58.6%.

2

Through model interpretation, we find the most influential indicators for InSep as out-going dependencies, terms shared with others, and declared fields of a pair. For InCol , the most important indicators include semantic similarity based on tf-idf, terms shared between the pair, terms shared with others, and in-going dependencies. In addition, we complement the quantitative analysis with a qualitative examination of representative PairSmell examples, further illustrating the manifestations of the smell. Overall, this study distinguishes itself from prior work by making two significant contributions. First, this study offers a systematic characterization and explanation of PairSmell. While our previous work [15] introduced and validated the concept of PairSmell, the present study goes further by identifying and interpreting the underlying pair characteristics that explain its emergence. By examining 19 pair characteristics, the study substantially advances the understanding of PairSmell, offering empirical evidence that supports a more nuanced perspective beyond earlier findings, which primarily focused on its prevalence and consequences. Second, the contributions of this study extend beyond PairSmell to illuminate the relationships between pair characteristics and modular design. Through a rapid literature review to identify relevant pair characteristics, combined with predictive modeling and illustrative examples, this study systematically reveals which types of pair characteristics are associated with inappropriate—and appropriate—modular relationships. Consequently, the findings provide valuable insights for the modular design community, not only for managing PairSmell, but also for leveraging pair characteristics to inform future research and practice in modular design. The structure of this article is as follows. Section 2 introduces existing techniques for improving the modularity of software systems, including PairSmell. Section 3 presents a rapid literature review to collect candidate pair characteristics for explaining PairSmell. Section 4 elaborates the research methods and results of predictive modeling for characterizing PairSmell. In section 5 we use several representative examples to illustrate the important characteristics found in Section 4. How our findings would contribute the understanding of PairSmell and threats to validity are discussed in section 6 and 7. Section 8 concludes this article.

2

BACKGROUND AND R ELATED W ORK

Many studies have explored improving the modularity of existing systems, including software modularization techniques, modularity issue identification, and our PairSmell built on both types of aforementioned methods. 2.1

Software Modularization Techniques

Numerous modularization techniques have been developed to restructure a large software system into smaller and more manageable subsystems [19]. These techniques typically conceptualize modularization as an optimization problem, seeking an optimal solution to refactor the original modules. The most commonly used optimization objectives are intraconnectivity (high cohesion) and interconnectivity (low coupling), e.g., in [6], [7], [20], [21]. For instance, FCA [6]

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

is a clustering algorithm that exploits a series of operations on the dependency matrix of a system to maximize intra-dependencies within the clusters and minimize interdependencies between the clusters. Another example is from the microservices domain, where Cromlech [22] is presented to decompose operation and data entities into services that optimize cohesion and decoupling between services. Additionally, some researchers incorporate refactoring effort, such as the number of changes [5], as an objective to minimize the effort required for modularization. However, an industrial case study [5] reveals that completely modularizing an entire system remains prohibitively expensive and thus impractical, given the extensive size of the code base. Instead of seeking to restructure an entire system, the idea of PairSmell is to integrate the intelligence of multiple modularization techniques to deduce promisingly appropriate MR designs and accordingly identify inapt MRs (as opportunities that necessitate refactoring). 2.2

Modularity Issue Identification

Identifying and analyzing modularity-related ‘issues’ is an essential objective for many architecture analysis activities, such as architectural quality measurement [23] and architectural smell detection [24], [25]. Architecture metrics, including modularity and maintainability measures [26], aim to assess the extent to which a software system is maintainable. In addition, numerous metrics of coupling [27] and cohesion [28] can be employed to identify quality issues at the module level. For instance, MCI [29] can be used to measure which services in a system are overcoupled with others and thus might need to be refactored. Architectural smells represent structural problems that negatively influence software evolution [9], [24] and can indicate refactoring opportunities in subsequent development. Since Joshua Garcia’s definition [16], numerous types of architectural smells have been introduced within the community. For example, Wong et al. [30] introduced modularity violation which refers to two components that consistently change together but belong to separate modules. Le et al. [31] discovered co-change coupling [31] where changes to one component require changes in another component. Mo et al. [32] presented cross-module dependency to indicate two structurally independent modules that frequently change together in the revision history. Compared to these smells, (1) PairSmell is defined at the fine-grained pair level, thus providing more actionable insights to enhance existing software modules; (2) while the above smells focus on the deviation between modular structure and historical revisions, PairSmell concerns deviation in the modular structure from the apt or ideal design decisions, offering a broader perspective than the existing smells. 2.3

PairSmell: Definition, Identification, and Impacts

PairSmell is defined as a triple regarding a pair of entities ei and ej , where the actual MR violates its apt MR:

PairSmell = < (ei , ej ), MRact (ei , ej ), MRapt (ei , ej ) > (1) The first element (ei , ej ) denotes a pair of entities in a target system, where ei ̸= ej . An entity is a single code file, following our previous study [15]. Both the second and third elements, MRact (ei , ej ) and MRapt (ei , ej ), denote modular

3 ~ Apt

~ A

e1 e2 e3 e4 Tool 1 …

e1 e2

Tool m

1 1

e1 e2 e3 e4

1/m

0

e1

1

2/m

e2

0

e3 e4

1

1

1

0

1/m e3 1/m 1 e4 0 2/m 1/m

Folder Structure

0

1

1

1

0 1

1

InSep

(e1, e2) … InCol

(e1, e4) …

Apt MRs

Actual MRs

PairSmells

(1)

(2)

(3)

Fig. 2: Overview of identifying PairSmell [15] relations between entities ei and ej . The MR of a pair in a specific design d is separated or collocated, formally: ( 0, if modd (ei ) ̸= modd (ej ) MRd (ei , ej ) = (2) 1, if modd (ei ) = modd (ej ) where modd (ei ) is the module to which ei belongs in design d. MRact (ei , ej ) is the actual modular relation of the pair, which could be extracted from a snapshot of the system. Inspired by consensus clustering [17], [18], an MR is considered apt if it is agreed upon by multiple modularization tools. In contrast, if modularization tools disagree, it suggests that the pair may be reasonably designed as either collocated or separated. Formally, an apt MR exists if:

MRd1 (ei , ej ) = ... = MRdm (ei , ej )

(3)

where m is the number of modularization tools considered. For PairSmell identification, the apt MRs agreed upon by multiple modularization tools are first inferred, which are then utilized as references to identify smell instances, as illustrated in Fig. 2. The apt MRs are inferred by comparing m solutions from distinct modularization tools. The actual MRs are collected from a system’s existing modules. Finally, the smell instances are detected by comparing the apt MRs with the actual MRs for each pair of entities. Our prior empirical study on 146,668,710 separated pairs and 3,866,940 collocated pairs from 20 C/C++ and Java projects reveal that (1) PairSmell is prevalent among projects, with InSep and InCol instances covering 14.60% and 20.44% of the entities on average; (2) on average, entities in InSep MRs co-change almost three times more than in other separated pairs, and entities in InCol MRs co-change 35% less than other collocated pairs, dramatically deviating from well-structured modules; and (3) PairSmells persist in software projects if left unaddressed.

3

PAIR C HARACTERISTICS TO S TUDY

This section aims to collect and synthesize pair characteristics from the literature to form the candidate features for explaining PairSmell. In particular, our aim is to answer the following research question. RQ1. What pair characteristics can be used to represent the relationship between two entities? This question is to identify the characteristics of entity pairs that can be used to describe their relationships and are thus pertinent to PairSmell; the answer can provide a solid theoretical basis for our study. We answer this question using the rapid literature review as the high-level method for data collection, and thematic synthesis as the data analysis method for synthesizing pair characteristics.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

3.1

Methodology

We follow the guidelines of Shull et al. [33] and adopt scientific literature as the source of data collection, as it offers greater rigor and credibility to the collected evidence. Although this research studies the modular design for a pair of entities, our initial searches (i.e. with Scopus, IEEE Xplore Digital Library and ACM Digital Library) indicated that only a limited set of studies explore the modular design of software specifically at this level. Therefore, we broadened the scope of the search and analyzed the literature whose subject is the modular design for multiple entities, a.k.a., ‘software modularization techniques’. Specifically, we use rapid literature review [34] – a form of evidence collection and synthesis that simplifies the process of a systematic literature review to quickly acquire knowledge. To retrieve the primary studies, we consulted the articles from the two most up-to-date, systematic reviews related to software modularization: Sarhan et al. [19] collected 143 papers that examined the clustering of software modules; and Abgaz et al. [3] collected 35 papers that studied the decomposition of monolithic applications into microservices. By combining the two sets, we obtained 178 primary studies for analysis. We retained all 178 studies without further filtering, as they have all been included in recent secondary studies and collectively represent the state of the art in software modularization. This approach was intended to preserve as much evidence as possible. Since many primary studies discussed the relationships between entities as the basis for modularization, we extracted these relationships as pair characteristics, along with the underlying rationales. These extracted items help to investigate respectively (1) what pair characteristics can be used to determine the modular structure and (2) why. At the same time, we also extracted the core objective of software modularization that is discussed by researchers to further guide our synthesis of pair characteristics. Note that while the core objective outlines the desired attributes of software modules (according to the researchers), the underlying rationales for each pair characteristic explain why the characteristic contributes to achieving the modularization objective. The research methods and procedures are detailed below. We synthesized pair characteristics from primary studies using thematic synthesis [35]. According to Cruzes and Dyba [35], general thematic synthesis steps include: extracting data (S1 ), coding data (S2 ), translating codes into themes (S3 ), creating a model of higher-order themes (S4 ), and assessing the synthesis’ trustworthiness (S5 ). Our thematic analysis process was inductive, as there is no predefined taxonomy organizing current pair characteristics. In S1 , the primary studies were assigned to two researchers (the 1st and 4th authors) with prior experience in analyzing qualitative data. The goal was to extract pair characteristics, rationales, and objectives by reading each study’s abstract, introduction, and other sections (e.g., the approach section) if required. Two researchers started by extracting data from 20 studies together to coordinate on the task and align their understanding of the extracted items (e.g., pair characteristics). After that, each researcher independently extracted data from all the remaining studies and subsequently merged the results with any disagreements resolved

4

through discussion with the other. We did not calculate a consistency score (e.g., Kappa [36]) as the extracted data is mostly qualitative without predefined categories. In S2 , two researchers independently performed open coding for all papers, assigning a code whenever a concept became apparent. For example, one primary study [37] stated: “In order to make sure that highly related building blocks appear in the same concept ... We consider a building block A to be dependent on a building block B if A uses a function or data structure in B”. When coding this data, the researchers used the code ‘method invocation’ (for “A uses a function in B”) and the code ‘data accessing’ (for “A uses a data structure in B”) as two pair characteristics relevant to modular design. In S3 , we first excluded the pair characteristics that cannot be directly retrieved from the source code (e.g., the composition relation from UML diagrams, and co-change from commit analysis). Our focus is on analyzing modular design based on the static code structure, as it directly reflects the modules in the development environment. We then performed axial coding to translate codes into themes by comparing and merging similar items. For example, ‘method invocation’ and ‘data accessing’ were translated into ‘structural dependency’ (‘dependency’ in Table 1). In S4 , selective coding was performed to output the core themes (i.e. pair characteristics) by organizing the themes into a hierarchy structure. We reviewed the themes and interpreted their relationships, placing more important themes at higher levels of the hierarchy. For example, structural dependencies, common terms, and similarities between two entities were grouped under ‘relatedness’, as they collectively describe the closeness between entities. In S5 , we validated the core themes by assessing their trustworthiness against the original data. Specifically, we examined the data to determine how well the themes captured it and how their relationships aligned with the data. 3.2

Results

The final results can be found in our online repository 1 , which covers pair characteristics relevant to six core themes derived from the thematic synthesis: relatedness, distance, independence, complexity, cohesion, and size. The theme relatedness consists of the pair characteristics that describe the connection (e.g., structural dependencies and semantic similarity) between two entities. Distance describes the degree of difference between two entities (e.g., if they are linked by a dependency). Independence emphasizes to what extent two entities are independent in the system. Finally, cohesion, complexity, and size denote the average cohesion, complexity, and size of two entities. Table 1 shows a list of 19 selected characteristics that cover the six core themes, together with the rationale for each characteristic in the context of modular design. We highlight that compared to the review results (see the appendix), we made three additional changes: (1) Although there are various types of dependencies between two entities (e.g., method invocation and data accessing), we merged these different dependencies together to provide a more comprehensive view of structural dependency. (2) While the review identified complexity, cohesion, and size as 1. https://figshare.com/s/326e080186e95a70f859

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

4

PAIR C HARACTERISTICS T HAT M ATTER

In this section, our objective is to characterize and explain PairSmells: using the pair characteristics identified in Section 3, we aim to determine if the characteristics contribute to the occurrence of PairSmell, and if so, which ones contribute more. We use the following questions to guide the exploration. RQ2. Can the pair characteristics be used as indicators for PairSmell? RQ3. Which pair characteristics are the most important indicators for PairSmell? Specifically, RQ2 aims to explore the association between pair characteristics and the occurrence of PairSmell. To an-

T.

Description and Rationale

Relatedness

TABLE 1: Selected Pair Characteristics to Study

dependency: The number of structural dependencies between two entities. intersection: The number of common terms in the code files of two entities. sim-tfidf, sim-tm: The similarity between two entities calculated using tf-idf and topic modeling. Rationale: Two entities that are more related (according to their dependencies and similarity) are likely to be collocated [38].

Distance

str-distance: The distance between two entities in a pair. The value can be 1 if there is a direct dependency between them; otherwise, INF. sem-distance: The distance between two entities according to their common terms. The value can be 1 if they have common terms; otherwise, INF. Rationale: Two entities that are close to each other are more likely to be collocated than others that are distant.

Independence

in-degree, out-degree: The average number of dependencies going into/out the two entities in a pair. degree: The average number of common terms the two entities share with all other entities in the system. Rationale: The average number of dependencies of two entities and the average number of common terms can reflect their independence in the system, which may probably affect their modular relation.

Cohesion

Complexity

cbo: Coupling between objects. The average number of dependencies coupled with each entity of a pair. wmc: Weight Method Class. The average complexity of each entity, calculated as the sum of the McCabe’s cyclomatic complexity of its methods. dit: Depth Inheritance Tree. This metric counts the average number of fathers each entity has. All classes have DIT at least 1. rfc: Response for a class. This metric counts the average number of unique method invocations in each entity. max-nested-block: Highest number of code blocks nested together in a file. comment-density: The average percentage of lines in an entity containing either comment or commented-out code. Rationale: Empirical studies show that poorly modularized artifacts correlate with higher complexity. lcom: Lack of cohesion in methods. This metric counts the average number of methods in each entity that are not related (through the sharing of some of the entity’s fields). Rationale: A highly cohesive entity is internally focused and self-contained, thus it is less likely to benefit from being clustered with other entities.

Size

relevant factors for modular design, the studies did not specify detailed metrics; consequently, we adopted commonly used metrics related to these attributes to describe the corresponding characteristics of a pair. (3) We deliberately adjust certain characteristics to ensure their suitability, and to maintain consistency between different themes. For instance, we excluded ‘same folder’ because the modular relation (collocated or separated) already captures whether two entities belong to the same folder. Please see our online repository 1 for details. While we conducted a thematic synthesis to organize the themes, some overlap between characteristics across themes may still exist. For instance, structural dependencies are utilized to measure dependency (within the Relatedness theme), str-distance (within the Distance theme), and indegree (within the Independence theme). This overlap is partially due to our inductive approach [35], in which we assigned themes based on concepts that naturally emerged from the data. For example, many primary studies emphasize the importance of relatedness between entities — such as the number of structural dependencies — as a crucial factor in determining appropriate software modules. To mitigate the potential impact of feature overlap on predictive modeling, we performed a collinearity analysis to remove collinear features, as detailed in Section 4.3. All the 19 pair characteristics can be collected automatically by leveraging tools for syntactic and semantic analysis. Specifically, to collect these pair characteristics, Depends [39] was used to recover structural dependencies, as it is capable of extracting 13 dependency types by analyzing the syntactic structures of the source code, such as call, contain, and implement. The structural dependencies also serve as the basis for collecting other characteristics, including in-degree and out-degree. For collecting semantic-related features, the Ctags [40] tool was used to extract identifiers (e.g., function and variable names) found in source code files, which were then analyzed with natural language processing techniques including topic modeling (via the NLTK [41] toolkit) and TF-IDF (via the scikit-learn [42] library). In addition, a static analysis tool called CK [43] was leveraged to calculate the complexity, cohesion, and size metrics of each entity (e.g., dbo, dit, and lcom). Finally, an open-source tool cloc [44] was used to count comment lines (comment-density) and source code lines (ncloc) for each entity. The measurements at entity level were then aggregated at pair level using the average function to derive the corresponding characteristics of a pair.

5

total-methods, total-fields: Total number of methods and declared fields in a file. ncloc: The average number of lines of code in a file, ignoring empty lines. Rationale: The size of the entities may have an impact on the likelihood of the pair to be collocated. * “T.” Stands for Themes.

swer this question, we train several machine learning models using features collected and derived from pair characteristics. A positive answer to this question is the prerequisite for exploring RQ3 which aims to identify the pair characteristics most associated with PairSmell. To answer RQ3, we identify the most important characteristics of the prediction model and analyze how a change in these characteristics affects the model’s prediction. Such an exploration can help us to better understand the type of pairs that fall into the PairSmell group. Considering the selected pair characteristics as independent variables, this section first describes the other side of machine learning models, i.e. the design of dependent variables. After that, it elaborates on our procedures for curating datasets, fitting models to characterize PairSmell, and analyzing the results to answer each research question. 4.1

Dependent Variables

We selected two metrics to serve as representations of PairSmell according to its definition (cf. Section 2.3); the metrics were identified in our previous work [15]. Inapt Separated (InSep)—two entities are separated into different modules in the actual system, but the apt MR is collocated according to modularization tools. This smell means

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

that the two separated entities are highly related despite being separated, e.g., due to interdependency. The inapt MR of these two entities may hamper the independence of the corresponding modules, making changes of one module propagating to another module [45]. Inapt Collocated (InCol)—two entities are actually implemented as collocated, but the apt MR by all tools is to separate them. This smell indicates that the two entities, while placed in the same module, are not justifiably related, e.g., they address different (or even orthogonal) concerns. This inapt MR may impede the cohesion of the current module, violating the single responsibility principle [46]. According to the above definitions, a separated pair may suffer from InSep , while a collocated pair may suffer from InCol . To represent each of these forms as a PairSmell metric to be predicted, we create a binary metric for each form: psep for a separated pair, and pcol for a collocated pair. If a separated pair is affected by InSep , then its metric psep = 1; otherwise, psep = 0. Similarly, if a collocated pair is an InCol , then the metric pcol = 1; otherwise, pcol = 0. 4.2

Data Collection and Sampling

We begin with the dataset collected in our previous study [15] that explicitly labels instances of InSep and InCol . Within the dataset, 20 projects were selected as they are non-trivial with at least 100 entities (with an average of 1,010.5 and 1,456 maximum), so that studying modularity smells in these projects is meaningful [25]. In this study, we limit our analysis to 11 java projects among the 20 ones, since one used tool (CK [43]) is restricted to this programming language. The final 11 selected projects are shown in Table 2, together with their number of entities (#Entity), structural dependencies between the entities (#Link), and commits (#Cmt). These projects differ in scale, evolution histories, and business domains. Our initial dataset consists of 6,028,271 separated pairs with 3,283 InSep instances and 107,606 collocated pairs with 1,838 InCol instances. Note that the number of separated pairs is much higher than that of collocated pairs due to combinatorial growth, as large systems are often intentionally decomposed into many modules to manage complexity [47]. In addition, our dataset is imbalanced in terms of classes, e.g., the rate of InSep and other separated pairs is 1:1,835 – which is a common phenomenon in software engineering research. Given that the minority class (i.e. PairSmell) is of greater interest than the majority – we are more concerned with inapt modular relations than with apt ones (to improve the modular structure) – we decided to conduct class balancing. This approach allows the machine learning models to focus on the minority class, enabling them to learn features that are more relevant to PairSmell. In addition, we observed that some entities may occur in the dataset more frequently than other entities. For instance, a single entity in a module can be separated with all other entities in the system and thus appear n − 1 times in the dataset. As a result, if we use the entire population as the dataset, the learned models could be biased towards these frequent entities, which might lead to overfitting on these frequent entities and underfitting on those that appear less frequently. Therefore, we adopted Inverse Transform Sampling [48] to generate samples from the entire population

6

to ensure that 1) less frequent entities have a higher chance of being selected compared to more frequent ones and 2) pairs from the minority class have a higher chance of being selected compared to that from the majority class. For determining the sampling size, we use 99% confidence level and 1% error margin. We further assessed the robustness of our main findings by varying the sampling strategy and found that the significant pair characteristics remain consistent. Detailed results are reported in the online repository 1. We acknowledge that the sampling process may affect our analysis, as different samples can lead to variations in the results. To account for this, we repeated the sampling process three times and conducted experiments using each of the resulting samples. For clarity, we present only the results from the first experiment in the main text, while visualizations of the results from the other two experiments are provided in the appendix 1. Nonetheless, our overall conclusions are drawn based on all three experiments. Our final dataset (for the first experiment) consists of 16,541 separated pairs and 14,372 collocated pairs spanning 11 projects. Among these separated pairs, 3,109 are InSep instances, and among the collocated pairs, 1,387 are InCol instances. Readers may refer to the online data to view the datasets from the other two experiments. 4.3

Model Fitting

Our objective is to study what characterizes PairSmell. Thus, we train machine learning models to explore the association between pair characteristics and PairSmells. Collinear features can distort each other’s importance in the model [49]. Therefore, we first analyze collinearity among the selected characteristics (features) using Spearman’s ρ rank correlation [50]. We chose a rank correlation because it enables to detect nonlinear correlations. Similarly to prior studies [51], [52], we use ρ = 0.7 as the threshold to remove collinear features. That is, any pair of features with ρ ≥ 0.7 should have one of the features removed prior to the interpretation of the model. The correlations among the pair characteristics can be found in our online repository 1. According to the correlations, we removed the following seven characteristics when fitting the models for separated pairs: intersection, sem-distance, cbo, wmc, rfc, lcom, and ncloc. We also removed str-distance, cbo, wmc, rfc, and total-methods when fitting the models for collocated pairs. When removing features from a feature set, we do so in a manner that retains as many features as possible. For example, because rfc is highly correlated (≥ 0.7) with both out-degree and max-nested-blocks, we remove rfc and retain the other two features. The details on reasons for choosing one feature over the other can be seen in the repository. We observe that the pairs of features with ρ ≥ 0.7 are consistent among the three experiments, demonstrating small variations between the three samples. 4.4 Can the pair characteristics be used as indicators for PairSmell? (RQ2) Approach. To study the relevance of pair characteristics to the occurrence of PairSmell, we use the characteristics in Table 1 to train several machine learning models. The trained models aim to predict the appearance of PairSmell

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

7

TABLE 2: Summary of the Studied Software Projects Pi

Project

P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11

Cassandra Row store Druid Analytics database Gobblin Data management Hadoop Distributed framework Hbase Storage system Iotdb Data management Kafka Event streaming Lucene Search engine Mahout DSL framework Ozone Object store Pulsar Pub-sub messaging

Domain

TABLE 4: Comparison of Performance for Candidate Models

Version #Entity

#Link

#Cmt

0.6.10 0.7.0 0.9.0 0.20.0 1.0.2 0.11.0 0.10.2.1 2.9.2 0.6 1.0.0 2.3.0

5,569 7,651 9,743 17,266 34,968 19,273 11,593 21,377 12,939 8,595 20,519

1,752 4,980 3,717 3,461 10,061 4,209 3,247 4,042 2,269 2,698 2,892

283 1,045 1,279 890 1,456 836 747 1,006 1,052 1,380 1,142

TABLE 3: The Initial Dataset Collected From All 11 Projects Separated Pairs Pi

Separated Pairs Models

Collocated Pairs

ROC-AUC

AUPRC

ROC-AUC

AUPRC

LR SVM RF

0.648 0.673 0.612

0.412 0.44 0.369

0.778 0.793 0.812

0.385 0.459 0.649

SB CB TB

0.485 0.5 0.5

0.262 0 0.188

0.507 0.5 0.5

0.166 0 0.097

* “LR”, “SVM”, and “RF” represent logistic regression, support vector machine, and random forest, respectively. * “SB”, “CB”, and “TB” represent stratified baseline, constant baseline, and theoretical baseline, respectively.

Collocated Pairs

#InSep

#All

#InCol

#All

P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11

27 85 80 334 960 134 93 398 987 119 66

37,704 536,552 810,917 380,567 1,026,478 345,827 268,954 485,625 547,890 944,732 643,025

365 90 61 162 176 189 66 536 36 44 113

2,199 8,938 6,364 15,038 22,097 3,203 9,677 19,890 4,936 6,778 8,486

Avg.

298

548,025

167

9,782

for each pair. Specifically, two types of binary classifiers are trained: one to determine whether a separated pair is InSep , and another to determine whether a collocated pair is InCol . We evaluate the performance of the trained models based on (a) the discriminatory power and (b) the ability to balance precision and recall. The discriminatory power of the models is estimated using the Receiver Operating Characteristics-Area Under the Curve (ROC-AUC) [53] metric. The ROC is a probability curve and ROC-AUC is a value between 0 and 1 that represents the degree of which the model is capable of distinguishing between classes. The higher the ROC-AUC, the better the model is at correctly predicting classes. The Area Under Precision-Recall Curve (AUPRC) [54] is calculated to measure the models’ ability to balance precision and recall across different probability thresholds. The AUPRC is a value between 0 and 1. The higher the AUPRC, the better the model is at balancing precision and recall. We conducted preliminary experiments with Logistic Regression (LR) [55], Support Vector Machines (SVM) [56], and Random Forest (RF) [57] to compare their performance using ROC-AUC and AUPRC. We selected these models because our study is to understand the association between pair characteristics and the occurrence of PairSmell, which requires models with strong descriptive capabilities that provide insight into the data. In addition, good performance of the trained models is required in order to derive meaningful associations. We performed data normalization, which is important for LR and SVM when there is high cardinal variance between the features. All three models were trained on 80% of our dataset (training set) and evaluated on the rest 20% (test set). We tuned the hyper-parameters of each model using 10-fold cross-validation on the training set and used the best hyper-parameters across folds for training the

models. Model performance was assessed on the training set using repeated stratified 10-fold cross-validation (3 repeats). Finally, each model was retrained on the full training set and evaluated once on the held-out test set to obtain the final performance results. As presented in Table 4, the SVM models demonstrate relatively strong performance across both tasks (in fact, they also achieve the best performance in the other two experiments 1). Therefore, they were selected to explore the characteristics of PairSmell. Since there is no previous work on the use of pair characteristics to predict PairSmell, the results are compared with three baselines: the stratified baseline, the constant baseline, and the theoretical baseline. The stratified baseline uses the class distribution in the training set for weighted random predictions about the occurrence of PairSmell. The constant baseline uses constant results (with value 0). Finally, the theoretical baseline represents random guess, whose value for ROC-AUC is 0.5 and the value for AUPRC is determined tp . by the positive class prevalence [58], i.e. tp+tn Results. Table 4 shows the evaluation results regarding ROC-AUC and AUPRC. The ROC-AUC for the baseline models round up to 0.5, which is the expected ROC-AUC values when the model makes random predictions or always predicts the same class. Compared to baseline models, we can observe that SVM models improve the ROC-AUC by 34.6% for separated pairs and by 58.6% for collocated pairs. The high ROC-AUC improvement shows that the pair characteristics in Table 1 can be leveraged to predict if a pair is affected by PairSmell. In other words, they can be used as indicators of PairSmell. Finding #1: The evaluation of our classification models shows that pair characteristics can discriminate effectively between the instances of InSep and other separated pairs, as well as the instances of InCol and other collocated pairs. Regarding the AUPRC metric, we see that SVM models yield an AUPRC of 0.44 for separated pairs and an AUPRC of 0.459 for collocated pairs, surpassing the best baselines with an improvement of 1.57 times and 2.77 times, respectively. Similar results can be observed from the other two experiments (see the appendix 1). This evidence supports the model’s effectiveness in distinguishing positive instances and minimizing false positives, which is especially crucial in our dataset of separated and collocated pairs with an imbalanced class distribution.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

8

Permutation Importance

Permutation Importance sim-tfidf

out-degree

intersection degree

degree in-degree

total-fields

comment-density max-nested-blocks

out-degree 0.00

0.02

0.04

0.06

0.08

0.10

0.12

(a) The important features for predicting InSep

0.00

0.05

0.10

0.15

0.20

(b) The important features for predicting InCol

Fig. 3: The most important features associated with the occurrence of InSep and InCol

Finding #2: Our classification models demonstrate a commendable balance between precision and recall.

4.5 Which pair characteristics are the most important indicators for PairSmell? (RQ3) Approach. Pair characteristics (i.e. features) which have a greater impact on the model’s prediction of the occurrence of PairSmell are better indicators of PairSmell. To calculate the feature importance in our models, we use the permutation feature importance [59] instead of the default feature importance of SVM. While the default feature importance reflects how much a model relies on each input feature for predictions, permutation importance measures the performance drop when the values of a single feature are randomly permuted. We chose the permutation feature importance because it is model agnostic and can show the importance of a feature across models. We calculate the 10fold permutation importances by randomly permuting each feature 10 times and observing its impact on the models’ performance (ROC-AUC score). A feature (pair characteristic) is deemed more important if permuting its values has a greater impact on the models’ performance. Results. Fig. 3 presents the features whose permutation importance is higher than zero to predict the occurrence of InSep and InCol . We observed that out-degree, degree, and total-fields are the most important indicators of the occurrence of InSep , as they consistently rank among the top 4 indicators across all three experiments (see again appendix 1). This hints that these features are highly relevant to determining whether the modular design of a separated pair is appropriate. Similarly, in terms of collocated pairs, sim-tfidf, intersection, degree, and in-degree, are the most important indicators of the occurrence of InCol (as they rank among the top 4 indicators in all three experiments). Please note that we chose the top 4 indicators to keep our analysis of InCol consistent with that of InSep .

Finding #3: The most important indicators for InSep among the studied pair characteristics are out-degree, degree, and total-fields, while those for InCol are sim-tfidf, intersection, degree, and in-degree. We plot the distributions of the most important features to emphasize where the PDPs have more weight. Fig. 4 shows the distributions of the features for predicting InSep and InCol . For half of the separated pairs, each entity in the pair, on average, has fewer than 22.5 out-going dependencies, shares fewer than 693 common terms with other entities, and implements no more than two fields. On the other hand, the medians of sim-tfidf, intersection, degree, and in-degree among collocated pairs are 0.24, 3, 653.5, and 22.5 respectively. The distributions of values for important features are highly skewed, which should be considered when analyzing the impact of features. Table 5 further shows the median values of each important feature for smelly (e.g., InSep) and non-smelly pairs (e.g., Sep - InSep). We used the Mann-Whitney U test [60] to test whether the distributions of each feature for smelly and non-smelly pairs are equal. As can be seen, all features show significant differences; however, only out-degree and degree in separated pairs, and in-degree in collocated pairs, exhibit small effect sizes. Similar distributions can be observed for the other two experiments. To visualize how a change in a pair characteristic (feature) impacts the models’ decision-making for each class, we draw Partial Dependence Plots (PDP) [59] for the most important features as presented in Fig. 5. PDP can visualize the marginal effect of a feature on the prediction of the machine learning model, highlighting linear, monotone or more complex relationships between the feature and the target. In our cases, PDP can show how a change in a feature affects the models’ likelihood to predict the occurrence of PairSmell. The Y-axis represents the predicted probability for an instance belonging to PairSmell (InSep or InCol ), and the tick marks on the X-axis represent the characteristic values. For separated pairs, we see that as the number of outgoing edges (dependencies on other entities) of a pair increases, the probability of predicting the pair as InSep

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

3000

8000 6000 4000 2000 0 1000 750 500 250 0

0.2

4000

1.0

0

0

0

2000

Median = 3.0

2000 0.8

Median = 693.0

1000

0 200 400 600 800 1000 out-degree

0.4 0.6 sim-tfidf

10000

2000

Median = 22.5

Median = 0.24 0.0

9

0

20 40 intersection

60

4000 degree 3000 2000 1000 0

Median = 2.5

5000 6000

0

0

50

10000

Median = 653.5 0

100 150 total-fields Median = 22.5

5000

2000 4000 6000 8000 degree

0

0

2000 4000 6000 8000 10000 in-degree

Fig. 4: Distribution of features consistently ranked among the top 4 predictors for InSep (Blue) and InCol (Red) TABLE 5: Medians for Smelly and Non-smelly Pairs Regarding the Most Important Pair Characteristics Separated Pairs Char. out-degree *** degree*** total-fields*** -

InSep 41 941.5 3 -

TABLE 6: Percentages (%) of Dependent and Nondependent Separated Pairs Recognized as InSep, Divided by Different Number of Total Fields

Collocated Pairs

Sep. - InSep 19.5 647.5 2.5 -

Char. sim-tfidf *** intersection*** degree* in-degree***

InCol

Col. - InCol

0.09 2 703.5 99.5

0.26 3 649 19.5

* “Sep.” and “Col.” denote separated pairs and collocated pairs, respectively. * p < 0.1, p < 0.01, and p < 0.001 are denoted by *, **, and ***, respectively. * Gray results show small effect size differences, while White results indicate an absolute difference smaller than 0.2.

first increases and then drops. A pair with low out-degree suggests that both entities do not rely much on other parts of the system – they are self-contained or functionally independent of other entities and of each other. Thus, there is too little coupling to justify their collocation. In contrast, a pair with a high out-degree (greater than 100, as shown in the figure) indicates that the two entities depend heavily on other specific entities within the system. Therefore, merging them into the same module could cause the module to overrely on external modules, violating the principle of single responsibility. Finding #4: For separated pairs, the likelihood of predicting them as InSep initially rises and then falls with increasing outgoing edges. While low out-degree implies functional independence justifying separation, very high out-degree indicates excessive external dependencies that discourage merging to maintain separation of concerns among modules. For degree, the partial dependence value increases monotonically with higher degree values. In other words, separated pairs with a higher degree value are more likely to be classified as InSep . This suggests that the more terms two entities share with other entities in the system, the more likely they are to be functionally relevant, thus they should be placed together rather than separated. Finding #5: For a separated pair, a higher degree value suggests the two entities of the pair are more likely to be functionally relevant rather than separated (InSep). For total-fields, the partial dependence decreases monotonically as the value increases – separated pairs with fewer total-fields are more likely to be classified as InSep . In object-

Dep. Non-Dep.

0 ≤total-fields ≤ 2

2 <total-fields ≤ 8

8 <total-fields

65 17

54 19

54 20

* “Dep.” and “Non-Dep.” denote pairs with and without direct dependencies between them, respectively.

oriented design, classes with few fields are often relatively simple, which means that they are not central to a business functionality. However, the number of fields seems not to be a strong predictor of InSep ; its permutation importance is below 0.04 – far lower than that of other two features in Fig. 3 (a). Further inspection shows that low total fields only increases the likelihood of InSep when combined with other evidence, e.g., direct dependencies. As shown in Table 6, only directly dependent pairs with low field counts exhibit high InSep predictions. This suggests that when two dependent entities each have few fields, separating them may be unjustified due to insufficient encapsulated responsibilities. Finding #6: For a separated pair, low total-fields slightly increases the probability of InSep , but only when combined with direct dependencies, suggesting that simple dependent entities are better kept together. For collocated pairs, we observe that higher values in sim-tfidf, intersection, and degree generally decrease the likelihood that a collocated pair will be predicted as InCol, while higher in-degree increases it. Specifically, as the sim-tfidf value increases, the partial dependence decreases slightly initially and then drops significantly (after around 0.4). That is, when the corresponding two entities have a low simtfidf (i.e. they are textually dissimilar), they are likely to be collocated inappropriately. This kind of entity pairs actually dominates the dataset according to the distribution in Fig. 4. However, two entities with a high sim-tfidf may have implemented relevant functionalities, thus keeping them into one module follows the single responsibility principle (at the module level), reducing the probability of inducing InCol. Similarly, as the intersection increases, the predicted probability of the corresponding pair as InCol decreases monotonically (except a small peak in the beginning). That is, as the two entities in a pair share more common terms, they are more likely to implement related responsibilities, making it

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

0.0 0.5 1.0 50

75 100 125 150 out-degree

Partial dependence

Partial dependence

2 4 6 8 10 0.0

0.2

0.4 sim-tfidf

0.6

0.8

2.5 5.0 7.5 10.0 12.5 15.0 17.5

0.50 0.75 1.00 1.25

500

1000 1500 degree

2000

0.25 0.50 0.75 1.00 1.25 1.50

0

2

4

6 8 total-fields

2.0 2.5 3.0

0

20

40 intersection

60

10

12

0.0

1.5 Partial dependence

25

0.25

Partial dependence

0

Partial dependence

0.00 Partial dependence

Partial dependence

0.5

10

0.5 1.0 1.5 2.0

500

1000 1500 degree

2000

0

100

200 in-degree

300

Fig. 5: Partial dependence plots for each of the most important features for prediction InSep (Blue) and InCol (Red) less likely that their collocation is considered inappropriate. Finding #7: For a collocated pair, a higher relatedness (indicated by sim-tfidf or intersection) suggests that the two entities potentially share more responsibilities or couplings, making it less likely to be affected by InCol. The partial dependence line for degree shows a clear downward trend as degree increases. A higher degree suggests that the corresponding pair shares more common terms with others in the system, suggesting that the two entities likely belong to similar conceptual or functional areas, making their collocation more likely to be appropriate (i.e. lower probability of being InCol ). In contrast, a lower degree means the entities are not jointly connected to others, i.e. they are more independent or specialized. Finding #8: For a collocated pair, a higher degree value suggests that the two entities are less independent, decreasing the probability that it is affected by InCol. For in-degree, the partial dependence increases monotonically with a higher number of ingoing edges. That is, the collocation of a pair with more ingoing edges is more likely to be identified as inappropriate (which leads to InCol ). According to Almugrin et al. [27], more dependencies from others on an entity suggests more responsibilities it has in the system. Therefore, when a pair has more ingoing edges, it implies that the corresponding entities are responsible for more functionalities. Collocating such entities could potentially overload the module, which may raise concerns about the suitability of the collocation. Libraries and util packages are an exception to this, as we discuss in more detail in Section 6.4. Finding #9: For a collocated pair, a higher in-degree value indicates that the two entities have implemented many responsibilities, making the collocation less appropriate.

5

I LLUSTRATIVE E XAMPLES

The interpretation of our models indicates that out-degree, degree, and total-fields are strong indicators of InSep , while sim-

tfidf, intersection, degree, and in-degree are strong indicators of InCol . To gain deeper insights into these relationships, we manually analyze and illustrate representative examples from the dataset. Specifically, we present distinct example pairs for each type of PairSmell – InSep and InCol – and the corresponding important features from the dataset. Note that due to the similarity between the sim-tfidf and intersection features for InCol pairs, we use a single example to illustrate both. Example for InSep: out-degree. In the Hadoop project, two entities LocatedBlocks.java and NamenodeFsck.java are placed in separated modules. However, this pair is detected as an instance of InSep , since all modularization tools consistently clustered them into the same module. We notice that the out-degree value calculated for this pair is relatively high, at 89, with their outgoing dependencies illustrated in Fig. 6. Specifically, LocatedBlocks.java has outgoing dependencies on 5 entities, while NamenodeFsck.java depends on 16 entities. Note that we omit the weight of these dependencies for clarity. A high out-degree for a separated pair often indicates that the entities they depend on are likely closely coupled. For example, Block.java, which is depended by LocatedBlocks.java, further invokes NameNode.java, which is in turn depended upon by NamenodeFsck.java. This suggests tight couplings between the entities depended upon by the pair, which in turn lead to coupling between LocatedBlocks.java and NamenodeFsck.java themselves. Moreover, a high out-degree increases the likelihood that the two entities share common dependencies, further reinforcing their coupling. In this case, several dependencies of LocatedBlocks.java, such as Block and LocatedBlock, are also dependencies of NamenodeFsck.java. Such tight couplings may question the appropriateness of placing them in separated modules. Example for InSep: degree. In the Iotdb project, TimeSeriesMetadataCache.java and MManager.java constitute an instance of InSep , according to the identification results of PairSmell. The degree value of this separated pair is high at 3,100,

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

11

NameNode LocatedBlocks NamenodeFsck

Block LocatedBlock

AggregatorMapper

TopKStringPatterns

DatanodeInfo

Direct dependency

The same entity Entity

Fig. 6: The outgoing dependencies of two separated entities, LocatedBlocks.java and NamenodeFsck.java, which share three connected entities. Moreover, there are tight couplings among the out-going dependencies.

Direct dependency

The same entity Entity

Fig. 8: The outgoing dependencies of two separated entities AggregatorMapper.java and TopKStringPatterns.java suggest they are structural dependent.

propriate. A key observation is that these two entities, though located in separated modules, are closely related. As 20 shown in Fig. 8, AggregatorMapper.java depends on TopKStringPatterns.java to define its input and out716 781 37 83 put of one of its functions. Both entities work together to identify and aggregate the top K frequent item patterns in a distributed dataset. Notably, the average total Shared terms number of fields for this pair is low – 0.5 – indicating Shared entities that they implement relatively simple functionality. SpecifFig. 7: Overlap between TimeSeriesMetadataCache.java ically, AggregatorMapper.java groups patterns under (left circle in both diagrams) and MManager.java (right individual items to facilitate top K computation, while circle in both diagrams) regarding shared entities (left TopKStringPatterns.java serves as a lightweight condiagram) and shared common terms (right diagram). tainer for frequent patterns. Given their structural dependencies and functional alignment, keeping them in separate modules might not be justified, as each encapsulates only suggesting that the two entities collectively share a to- simple and related responsibilities. tal of 6200 common terms with other entities in the sys- Example for InCol: sim-tfidf and intersection. tem (note that some terms may be shared with multiple In Pulsar, Backoff.java and ConsumerBase.java were entities). Specifically, TimeSeriesMetadataCache.java clustered into one module, which produces an instance of shares 2,311 common terms with 716 entities, while InCol. MManager.java shares 3,889 common terms with 781 entiOur analysis finds that the sim-tfidf value between ties. A high degree implies that both entities are conceptually the two entities is only 0.01 and they share only three connected to many others, indicating a high possibility of terms in common (intersection equals to 3)– both indicatoverlapping responsibilities between themselves. This raises ing a low level of semantic relatedness. Although each questions about whether the separation between the two class shares common terms with many other entities (461 entities is appropriate. As shown in the left Venn dia- for Backoff.java and 815 for ConsumerBase.java), gram in Fig. 7, there are 711 entities that share common suggesting that they both handle broad responsibilities, terms with both TimeSeriesMetadataCache.java and the minimal overlap between them implies a weak direct MManager.java, reinforcing their conceptual closeness. In connection between themselves. The loose coupling beaddition, the large number of common terms shared with tween them is further illustrated in Fig. 9. From a funcother entities also suggests that the two entities may directly tional standpoint, the two classes serve distinct purposes: share many terms themselves. Indeed, as illustrated in the Backoff.java handles exponential backoff logic, while right Venn diagram, TimeSeriesMetadataCache.java ConsumerBase.java provides a foundational implemenand MManager.java share 20 common terms, in- tation for Pulsar consumers. These findings suggest that cluding logger, metadata, and measurement, sug- grouping them into the same module may not be justified. gesting functional relevance between them. Function- Example for InCol: degree. ally, TimeSeriesMetadataCache.java is responsible In Iotdb, two entities BrokerAuthenticator.java and for caching TimeSeriesMetadata into database, while PayloadFormatter.java are collocated in the mqtt MManager.java handles serialization of all metadata info module. However, this collocation might not be appropriate, –including TimeSeriesMetadata –into files. This overlap which yields an instance of InCol. in data handling responsibilities further supports their conThe value of degree for this collocated pair is low at ceptual coupling. 53.5, which corresponds to a high predicted probability of Example for InSep: total-fields. InCol in Fig. 5. Specifically, BrokerAuthenticator.java In the Mahout project, AggregatorMapper.java and shares 79 common terms with 78 other entities, while TopKStringPatterns.java are two code files from dif- PayloadFormatter.java shares 28 common terms with ferent modules, however, this separation is considered inap- 20 entities. A low degree suggests that both entities 711

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

12

Protocol ApiKeys

SaslServerAuthenticator

Direct dependency

The same entity Entity

Fig. 11: The ingoing dependencies of two collocated entities, ApiKeys.java and Protocol.java, within the Protocol module, indicating that ApiKeys.java has implemented many responsibilities.

Fig. 9: Word clouds generated for Backoff.java (up) and ConsumerBase.java (down), sharing only three terms. 7 1 78

28

Shared entities

5

4

Shared terms

Fig. 10: Overlap between BrokerAuthenticator.java (left circles in both diagrams) and PayloadFormatter.java (right circles in both diagrams) regarding shared entities and shared common terms.

are only loosely connected to the rest of the system, implying they are likely functionally independent or highly specialized. This raise questions about the appropriateness of their collocation. Although 7 entities share terms with both BrokerAuthenticator.java and PayloadFormatter.java (as shown in the left Venn diagram of Fig. 10), the two files themselves share only a single common term (as illustrated in the right Venn diagram). This reinforces their conceptual separation. Indeed, their functionalities seem to be unrelated: BrokerAuthenticator.java validates client authentication, whereas PayloadFormatter.java formats a payload into a list of message. Example for InCol: in-degree. ApiKeys.java and Protocol.java constitute a collocated pair within the Protocol module in Kafka. However, this pair is classified as InCol . The in-degree value of this collocated pair is high at 348, suggesting that the two entities have many in-going dependencies from others. The in-going dependencies are presented in Fig. 11, which shows that ApiKeys.java has ingoing dependencies from 14 entities, while 2 entities (including itself) depend on Protocol.java. A high indegree for a pair suggests that the corresponding entities might have implemented many responsibilities. In our case, although the ApiKeys.java entity was clustered into the module of Protocol.java (called Protocol), the entity itself has been invoked by 14 entities including 11 from

other modules, suggesting that ApiKeys.java is coupled with many other modules. This indicates that clustering ApiKeys.java into the Protocol module might not be appropriate. In addition, while ApiKeys.java enumerates high-level API keys, the Protocol module defines concrete API schema for all requests and responses. Changes in API schema do not require changes to how APIs are enumerated, making it more appropriate to separate ApiKeys.java into its own module so that the two responsibilities are separate.

6

D ISCUSSION

This section discusses how our findings would contribute to deepen the understanding of PairSmell, especially its explainability, management, and potential limitations. 6.1

Why PairSmell Is a Smell

“A (code) smell is a surface indication that usually corresponds to a deeper problem in the system,” according to the definition from Martin Fowler and Kent Beck [61], [62]. This definition expresses two subtle points of the concept of smells. First, a smell refers to a sniffable problem that indicates the underlying inappropriate decision. For example, Long Method is recognizable by checking how many lines of code a method contains. The second point is that, although smells can be promising indicators, they do not always pinpoint a real problem. For instance, some long methods are just fine. Smells that are problematic can negatively impact lifecycle properties of a system, particularly maintainability [10], thus being regarded opportunities for refactoring in subsequent development. In contrast, smells that do not generate maintenance “interest” are not true problems (or “technical debt”) [9]. As Martin Fowler notes, the “best” smells are those that most of the time lead to really interesting problems. In the case of PairSmell, it is designed to be sniffable – as it arises when the MR of a pair violates the apt MR. Thus, developers can recognize instances of PairSmell once the apt MR of a separated pair is collocated (InSep ) or the apt MR of a collocated pair is separated (InCol ). With the aid of the tooling introduced in our previous work [15], developers can efficiently and automatically detect all instances of PairSmell within a system.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

13

TABLE 7: Pair Characteristics, Corresponding Impacts, and Mitigation Means Forms

InSep

InCol

Pair Characteristics: Potential Impacts

Possible Mitigation Means

• High out-degree: Two separated entities with many out-going edges may share dependencies, making changes to those shared dependents propagating to both entities in different modules. • High degree: If two separated entities share many terms (or functionalities) with other parts of the system, they are likely overlapping responsibilities between modules and require crossmodule changes when updating a feature. • Low total-fields (if dependent): When two dependent but separated entities each have a small number of fields, they tend to represent similar, simple responsibilities that are scattered across modules, making the overall system harder to understand.

• Depending on many low-level implementations can lead to high out-degree. To avoid this, developers can abstract interface and let the separated pairs depend on the interface (following the Dependency Inversion Principle). • To reduce degree, developers can minimize the externally visible vocabularies of both entities by limiting public fields in accordance with the Information Hiding principle. • To increase total-fields, developers can identify domain invariants within each entity and defined them as fields, strengthening object responsibility.

• Low sim-tfidf : If two collocated entities are unrelated, it indicates that the current module handles distinct responsibilities, which can reduce its reusability. • Low intersection: As with sim-tfidf, but here the relatedness is measured by intersection. • Low degree: When two collocated entities have limited overlap in terms (or functionalities) with other entities in the system, they are likely independent responsibilities within a single module, thereby reducing the maintainability of the current module. • High in-degree: When two collocated entities each have many ingoing dependencies, it may indicate that they implement multiple responsibilities, thereby overloading the current module.

• To increase sim-tfidf, developers can replace entity-specific Data Transfer Objects with shared immutable value objects (to increase common identifiers). • Local identifiers of the two entities can be renamed carefully to align terminology and reduce synonym fragmentation (policy and rule). • To increase degree, developers should use the same terms to represent the same concept within one module, following the pattern of Ubiquitous Language. • Both entities of the collocated pair serve multiple unrelated use cases and attract many dependents. Developers can apply Extract Class to further separate responsibilities apart.

Regarding impact on maintainability, previous empirical evidence shows the negative influences of PairSmell statistically. To recap, entities in InSep MRs co-change 190% more than in other separated pairs, and entities in InCol MRs co-change 35% less than other collocated pairs, which dramatically deviates from well-structured modules. In this study, we advance the understanding by explaining why a pair exhibits PairSmell through the lens of pair characteristics. We disclose in Sections 4 and 5 that a pair affected by InSep often exhibits at least one of three pair characteristics, and a pair affected by InCol often manifests at least one of four pair characteristics. Regarding the impact, Table 7 further discusses why pairs that manifest such characteristics are detrimental, based on both our findings from this study and findings from studies on maintainability (e.g., [63]–[65]). 6.2

Implications for Modularity Research

This section discusses implications for future research, particularly on research within the field of modularity. Software modularization tools should carefully select pair characteristics and eliminate redundant characteristics. Existing modularization studies often use multiple features between software entities (a.k.a., pair characteristics) as the basis for analysis to derive well-designed modularization solutions. For example, Eski and Buzluca [66] used various forms of structural coupling (e.g., inheritance, aggregation, and method invocation) to extract microservices from a monolithic application. However, our analysis reveals that the multiple features employed in the current community often exhibit collinear relationships (e.g., dependency and str-distance), indicating that some features share significant similarities. Integrating multiple similar features simultaneously into a modularization tool requires collecting redundant information, which leads to unnecessary resource consumption and offers a contrived analysis that may confuse developers regarding the real modularity issues in their system. Furthermore, incorporating multiple similar features into a modularization algorithm (e.g., clustering) may cause the resulting modularization to be dominated by

a subset of primary features [67]. Therefore, we suggest that future research should explicitly account for feature similarity when designing modularization tools and carefully select features accordingly (e.g., by combining Collinear analysis with ablation experiments). In addition to pair relatedness, modularization studies may also emphasize pair independence and size to improve the rationality of the resulting solutions. Most existing modularization tools are designed around relationships between software entities (e.g., [68]–[70]), such as structural dependencies, semantic similarity, and co-change relationships. However, some researchers argue that modularization solutions based solely on these explicit dependencies are often unsatisfactory, as they overlook additional insights that are important in architectural design (e.g., implicit knowledge) [71]. Our research found that, beyond relationships between entities, pair independence and size are also significantly associated with the modular design of a given pair (Section 4.5). Inspired by this finding, pair independence and size may help reveal relevant implicit knowledge, and future modularization research could place greater emphasis on these features during the design process, thereby producing more rational modularization solutions. For example, pair independence reflects the relationship between a pair of entities and their broader system context. If two entities are highly dependent upon by many other entities within the system, aggregating them into a single module may be inappropriate, as it could result in modules with excessively large responsibilities (Section 4.5 and Section 5). The pair characteristics that are significantly associated with InSep (and InCol) pairs can be leveraged to assess modular relationships, complementing existing modularity metrics. In terms of modularity metrics, most prior studies (e.g., [68], [69]) regard high cohesion and loose coupling as the essential characteristics of ‘good’ modules. For example, the widely used Modularization Quality (MQ) [72] metric captures the extent to which entities within a module are tightly related while entities across different modules are loosely related. In contrast, only a small number of re-

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

14

searchers have proposed alternative perspectives [8]. Our findings may provide new insights for researchers into modularity measurement, thereby enriching existing approaches to assessing modularity. For two separated entities, the rationality of their separation can be evaluated using indicators such as outgoing dependencies, terms shared with other entities, and the number of declared fields within the pair (Section 4.5). For example, by examining the number of outgoing dependencies of two entities, researchers can assess the extent to which the entities depend on other parts of the system, which may help justify their separation. Conversely, for two collocated entities, the fitness of their modular relationship can be assessed from multiple perspectives, including semantic similarity based on tf-idf, terms shared within the others, and in-going dependencies. 6.3

Implications for Refactoring PairSmell

In our previous study, we discussed how PairSmells can be managed, through (1) early and continuous identification, (2) granular, intermittent, and selective refactoring, and (3) whole-process modular training, as illustrated in Fig. 12. This subsection aims to enrich PairSmell management strategies with the findings of this study (see red text of Fig. 12). To fix PairSmell, typical refactoring strategies may be used: for an InSep pair, developers could choose a single module to house both entities; while for an InCol pair, developers could separate the current module to establish clear boundaries. In addition, the close associations between pair characteristics and PairSmells suggest that developers may be able to remove some instances of PairSmells simply by adjusting the values of those important characteristics. The detailed mechanisms for mitigating PairSmells by leveraging these characteristics are exemplified in Table 7. This characteristic-driven strategy also helps developers make informed decisions during refactoring. Developers can rely on the important pair characteristics to determine whether to perform a refactoring, by considering whether such a change may induce another instance of PairSmell. Regarding the time of refactor, it is recommended to adopt intermittent floss refactoring throughout the development lifecycle. Based on this study, we further recommend performing such refactorings during the intervals between successive code changes (e.g., between two sprints), as code changes may affect key pair characteristics and potentially influence the outcomes of PairSmell analysis. Regarding which smell

Plan

Code Early identification

Early refactoring

Whole-process training

Build

Test

Deploy

Release

 IDE plugins  Granular：modular relation (characteristics-driven)  Intermittent：coding and operating (between successive changes)  Selective：Darius Sas’ theoretical model (instance-aware)  Practical examples of design concepts

Operate

Monitor

Continuous identification

Continuous refactoring

Whole-process training

Fig. 12: Management of PairSmell during the DevOps development process as adapted from prior work [15]. Additions in “Red” text are further insights obtained from this study.

to refactor first, it is suggested to balance the severity of each smell instance and the remediation effort [73]. Based on a more precise understanding of PairSmell, we further suggest to incorporate specific refactoring strategies tailored to PairSmell instances at hand (Table 7). For instance, developers might prioritize refactoring solutions that are easier to modify, e.g., revising terms used in a class (related to intersection) is often more straightforward than reducing cross-module dependencies (related to out-degree). 6.4

Limitations of PairSmell

From this study, we observed two limitations of PairSmell. • The usage of lowest-level folders as the actual modular structure may lead to false positives. As discussed in our previous study, the folder structure of a software repository can be represented by a tree hierarchy of folders and sub-folders. In this study, we notice that developers may create sub-folders inside a java package for organizational purposes, which leads to several sub-modules inside the jave module. Consequently, PairSmell instances detected using the lowest-level folders might not be problematic at the package level. For instance, two entities separated into two lowest-level folders may still belong to the same package and thus be considered collocated at the package level – leading to false positives of InSep . This suggests that developers can tailor the definition of the actual ‘modules’ when detecting PairSmells to suit their specific context (e.g., using java packages or the module system introduced in Java 9). • Utility packages may need to be excluded when analyzing PairSmell. Utility packages typically contain reusable helper classes that provide generalpurpose functionalities (e.g., exception handling), rather than cohesive responsibilities. This can lead to false positives of InCol . For instance, in Cassandra, BloomCalculations.java and XMLUtils.java are two entities collocated in the utils module despite being unrelated. Thus, excluding utility packages can improve the accuracy of PairSmell detection.

7

T HREATS TO VALIDITY

This section presents potential threats to the validity of our study and means we used to mitigate them. Construct Validity. The construct validity might be influenced by two factors. On the one hand, the 19 features used to train our model might not capture significant pair characteristics, raising concerns about their appropriateness and comprehensiveness. For example, the co-change between two entities reflects their evolutionary relationship, which has not been included in our model. This feature may explain the appropriateness of a modular relation for a pair. However, such information cannot be easily collected for each pair in the development environment, and our aim is to provide insights to aid developers in inspecting modular design during development. To mitigate this threat, we selected a set of 19 features that span six dimensions of pair characteristics by consulting the literature through a rapid review. In addition, we carefully adjust certain characteristics to ensure their suitability (i.e. consistency between

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

different themes). We believe these features are suitable, as we cross-referenced them with both modular design decisions identified in the literature and empirical characteristics observed in code repositories. On the other hand, the AURPC values of our models are low in some cases, which may appear to limit their practical usefulness in imbalanced settings. However, AUPRC is strongly affected by extreme class imbalance, as reflected by the best baseline AUPRC of 0.262. Compared with these baselines, our model improves AUPRC by up to 177%, indicating a substantially improved ability to prioritize positive instances. More importantly, our model is not intended to function as a standalone classifier, but to expose and explain indicators of PairSmell. Consequently, predictive metrics such as AUPRC do not fully capture the model’s explanatory utility, a positioning that is consistent with prior work using machine learning models primarily for explanation [52]. Internal Validity. The methodology designed in our study can influence internal validity with two possible threats. First, the validity of our dataset may be affected by several factors. To mitigate potential risks, we built our dataset based on a previously published dataset. To avoid noise, we excluded pairs in which at least one of the entities is a test file, configuration file, or inner class. To address the class imbalance issue, we applied Inverse Transform Sampling [48] to generate samples from the entire population, which may affect the distribution of our dataset. To ensure that the sampled dataset remains representative, we determined the size of our sample using a 99% confidence level and a 1% margin of error. Second, our investigation in this study may not be comprehensive enough. To address the potential threat, we conducted a rapid literature review to extract and synthesize significant pair characteristics from 178 primary studies. Our final set of 19 features encompasses six key aspects: relatedness, distance, independence, complexity, cohesion, and size. In addition, the pair characteristics obtained were used as independent variables in our analysis to investigate those that are most indicative of PairSmell. Additionally, we complemented our quantitative analysis with qualitative analysis by exploring and presenting multiple examples to illustrate and support our findings. External Validity. The generalization and application of our findings can be impacted by two threats. First, the findings of our rapid review may not be generalizable enough to represent all significant pair characteristics that describe the relationships between two entities. To minimize this threat, we include primary studies from the most up-to-date and systematic reviews related to software modularization. Our review of the literature incorporates 178 primary studies, including 143 papers examining the clustering of software modules and 35 papers studying microservices-oriented decomposition. Our review process rigorously followed the guideline of thematic analysis [35]. Second, we are aware that our analysis of the relationships between pair characteristics and PairSmell may not be generalizable to other datasets since all pairs were collected from open-source Java projects. To this end, multiple criteria were used to select projects with varying scales (283 to 1,456 entities), business domains (e.g., database, search engine), and other characteristics (Table 2). Moreover, we argue that the pair characteristics we study are language-agnostic (e.g., entity

15

dependencies) as they are not strongly tied to Java language features. Finally, from the large-scale dataset of separated and collocated pairs, we performed the sampling process three times and conducted experiments on each of the samples, all of which yielded similar findings. Therefore, this threat has been mitigated, at least to some extent.

8

C ONCLUSIONS

In order to characterize and explain PairSmell, this study first conducts a rapid review on 178 primary studies related to software modularization to collect pair characteristics that can be used to describe the relationships between two entities. We then examine 6,135,877 distinct pairs from 11 opensource Java projects. Overall 19 pair characteristics from the review, spanning the relatedness, distance, independence, complexity, cohesion, and size aspects, are then analyzed using machine learning models to understand their impact on the occurrence of PairSmells. Our findings highlight that the most influential factors for InSep are out-going dependencies, terms shared with others, and declared fields, and those for InCol are semantic similarity based on tf-idf, terms shared between the pair, terms shared with others, and in-going dependencies. We complement the quantitative analysis with a set of illustrative examples to investigate modular relations of pairs and understand how they are impacted by factors such as high out-degree. The findings of this study provides valuable insights not only for managing PairSmell, but also for leveraging salient pair characteristics to support future research and practice in modular design.

ACKNOWLEDGMENTS This work is supported by the National Natural Science Foundation of China (No.62502211, No.62302210, No.62572237), 2024 Development and Testing Tools Project (CEIEC-2024-ZM02-0066), the Natural Science Foundation of Jiangsu Province (No.BK20241195), and the Innovation Project and Overseas Open Project of State Key Laboratory for Novel Software Technology (Nanjing University) (KFKT2025A19, KFKT2025A17, KFKT2025A20, ZZKT2026A10, ZZKT2026A37, ZZKT2026A40, ZZKT2026A44, ZZKT2026A50, ZZKT2026A52, KFKT2026A11, KFKT2026A16, KFKT2026A18, KFKT2024A02, KFKT2024A13, KFKT2024A14, KFKT2026B43).

R EFERENCES [1] [2]

[3]

[4]

C. Y. Baldwin and K. B. Clark, Design rules: The power of modularity. MIT press, 2000, vol. 1. J. Krüger and T. Berger, “An empirical analysis of the costs of clone-and platform-oriented software reuse,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020, pp. 432–444. Y. Abgaz, A. McCarren, P. Elger, D. Solan, N. Lapuz, M. Bivol, G. Jackson, M. Yilmaz, J. Buckley, and P. Clarke, “Decomposition of monolith applications into microservices architectures: A systematic review,” IEEE Transactions on Software Engineering, 2023. X. Wang, R. Hu, C. Gao, X.-C. Wen, Y. Chen, and Q. Liao, “Reposvul: A repository-level high-quality vulnerability dataset,” in Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings, 2024, pp. 472–483.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

[5]

C. Schröder, A. van der Feltz, A. Panichella, and M. Aniche, “Search-based software re-modularization: A case study at adyen,” in Proceedings of the 43rd International Conference on Software Engineering: Software Engineering in Practice. IEEE, 2021, pp. 81–90. [6] N. Teymourian, H. Izadkhah, and A. Isazadeh, “A fast clustering algorithm for modularization of large-scale software systems,” IEEE Transactions on Software Engineering, vol. 48, no. 4, pp. 1451– 1462, 2022. [7] B. Pourasghar, H. Izadkhah, A. Isazadeh, and S. Lotfi, “A graphbased clustering algorithm for software systems modularization,” Information and Software Technology, vol. 133, p. 106469, 2021. [8] I. Candela, G. Bavota, B. Russo, and R. Oliveto, “Using cohesion and coupling for software remodularization: Is it enough?” ACM Transactions on Software Engineering and Methodology, vol. 25, no. 3, pp. 1–28, 2016. [9] L. Xiao, Y. Cai, R. Kazman, R. Mo, and Q. Feng, “Detecting the locations and predicting the costs of compound architectural debts,” IEEE Transactions on Software Engineering, vol. 48, no. 9, pp. 3686–3715, 2022. [10] H. Mumtaz, P. Singh, and K. Blincoe, “A systematic mapping study on architectural smells detection,” Journal of Systems and Software, vol. 173, p. 110885, 2021. [11] I. Griffith and C. Izurieta, “Design pattern decay: The case for class grime,” in Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM, 2014, pp. 1–4. [12] Y. Cai and R. Kazman, “Software design analysis and technical debt management based on design rule theory,” Information and Software Technology, vol. 164, p. 107322, 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S0950584923001775 [13] F. A. Fontana, I. Pigazzini, R. Roveda, D. Tamburri, M. Zanoni, and E. Di Nitto, “Arcan: A tool for architectural smells detection,” in Proceedings of the 2017 IEEE International Conference on Software Architecture Workshops. IEEE, 2017, pp. 282–285. [14] T. D. Oyetoyan, D. S. Cruzes, and C. Thurmann-Nielsen, “A decision support system to refactor class cycles,” in Proceedings of the 31th IEEE International Conference on Software Maintenance and Evolution. IEEE, 2015, pp. 231–240. [15] C. Zhong, D. Feitosa, P. Avgeriou, H. Huang, Y. Li, and H. Zhang, “Pairsmell: A novel perspective inspecting software modular structure,” in Proceedings of the 47th International Conference on Software Engineering. IEEE, 2025, pp. 1–12. [16] J. Garcia, D. Popescu, G. Edwards, and N. Medvidovic, “Identifying architectural bad smells,” in Proceedings of the 13th European Conference on Software Maintenance and Reengineering. IEEE, 2009, pp. 255–258. [17] A. L. Fred and A. K. Jain, “Combining multiple clusterings using evidence accumulation,” IEEE transactions on Pattern Analysis and Machine Intelligence, vol. 27, no. 6, pp. 835–850, 2005. [18] M. Zhang, “Weighted clustering ensemble: A review,” Pattern Recognition, vol. 124, p. 108428, 2022. [19] Q. I. Sarhan, B. S. Ahmed, M. Bures, and K. Z. Zamli, “Software module clustering: An in-depth literature analysis,” IEEE Transactions on Software Engineering, vol. 48, no. 6, pp. 1905–1928, 2022. [20] K. Yang, J. Wang, Z. Fang, P. Wu, and Z. Song, “Enhancing software modularization via semantic outliers filtration and label propagation,” Information and Software Technology, vol. 145, p. 106818, 2022. [21] B. S. Mitchell and S. Mancoridis, “On the automatic modularization of software systems using the bunch tool,” IEEE Transactions on Software Engineering, vol. 32, no. 3, pp. 193–208, 2006. [22] G. Quattrocchi, D. Cocco, S. Staffa, A. Margara, and G. Cugola, “Cromlech: Semi-automated monolith decomposition into microservices,” IEEE Transactions on Services Computing, 2024. [23] J. Al Dallal and L. C. Briand, “A precise method-method interaction-based cohesion metric for object-oriented classes,” ACM Transactions on Software Engineering and Methodology, vol. 21, no. 2, pp. 1–34, 2012. [24] R. Mo, Y. Cai, R. Kazman, L. Xiao, and Q. Feng, “Architecture anti-patterns: Automatically detectable violations of design principles,” IEEE Transactions on Software Engineering, vol. 47, no. 5, pp. 1008–1028, 2019. [25] A. Liu, J. Lefever, Y. Han, and Y. Cai, “Prevalence and severity of design anti-patterns in open source programs—a large-scale study,” Information and Software Technology, vol. 170, p. 107429, 2024.

16

[26] R. Mo, Y. Cai, R. Kazman, L. Xiao, and Q. Feng, “Decoupling level: A new metric for architectural maintenance complexity,” in Proceedings of the 38th International Conference on Software Engineering. IEEE, 2016, pp. 499–510. [27] S. Almugrin, W. Albattah, and A. Melton, “Using indirect coupling metrics to predict package maintainability and testability,” Journal of Systems and Software, vol. 121, pp. 298–310, 2016. [28] D. Athanasopoulos, A. V. Zarras, G. Miskos, V. Issarny, and P. Vassiliadis, “Cohesion-driven decomposition of service interfaces without access to source code,” IEEE Transactions on Services Computing, vol. 8, no. 4, pp. 550–562, 2014. [29] C. Zhong, H. Zhang, C. Li, H. Huang, and D. Feitosa, “On measuring coupling between microservices,” Journal of Systems and Software, p. 111670, 2023. [30] S. Wong, Y. Cai, M. Kim, and M. Dalton, “Detecting software modularity violations,” in Proceedings of the 33rd International Conference on Software Engineering, 2011, pp. 411–420. [31] D. M. Le, D. Link, A. Shahbazian, and N. Medvidovic, “An empirical study of architectural decay in open-source software,” in Proceedings of the 15th International Conference on Software Architecture. IEEE, 2018, pp. 176–17 609. [32] R. Mo, Y. Cai, R. Kazman, and L. Xiao, “Hotspot patterns: The formal definition and automatic detection of architecture smells,” in Proceedings of the 12th Working IEEE/IFIP Conference on Software Architecture. IEEE, 2015, pp. 51–60. [33] F. Shull, J. Singer, and D. I. Sjøberg, Guide to advanced empirical software engineering. Springer, 2008, vol. 93. [34] A. C. Tricco, J. Antony, W. Zarin, L. Strifler, M. Ghassemi, J. Ivory, L. Perrier, B. Hutton, D. Moher, and S. E. Straus, “A scoping review of rapid review methods,” BMC Medicine, vol. 13, pp. 1–15, 2015. [35] D. S. Cruzes and T. Dyba, “Recommended steps for thematic synthesis in software engineering,” in Proceedings of the 5th International Symposium on Empirical Software Engineering and Measurement. IEEE, 2011, pp. 275–284. [36] B. Kitchenham and S. Charters, Guidelines for performing systematic literature reviews in software engineering. Keele, UK, 2007. [37] M. Glorie, A. Zaidman, A. van Deursen, and L. Hofland, “Splitting a large software repository for easing future software evolution—an industrial experience report,” Journal of Software Maintenance and Evolution: Research and Practice, vol. 21, no. 2, pp. 113–141, 2009. [38] Y. Wang, H. Yu, Z. Zhu, W. Zhang, and Y. Zhao, “Automatic software refactoring via weighted clustering in method-level networks,” IEEE Transactions on Software Engineering, vol. 44, no. 3, pp. 202–236, 2017. [39] “Depends,” https://github.com/multilang-depends/depends, 2022. [40] “Ctags,” https://github.com/universal-ctags/ctags, 2022. [41] “Nltk,” https://www.nltk.org/, 2023. [42] “Scikit-learn,” https://scikit-learn.org/stable/whats new/v1.4. html#version-1-4-1, 2024. [43] “Ck,” https://github.com/mauricioaniche/ck/releases/tag/ ck-0.7.0, 2022. [44] “Cloc,” https://github.com/AlDanial/cloc/commits/v2.00, 2024. [45] E.-M. Arvanitou, A. Ampatzoglou, A. Chatzigeorgiou, and P. Avgeriou, “Introducing a ripple effect measure: A theoretical and empirical validation,” in Proceedings of the 9th International Symposium on Empirical Software Engineering and Measurement. IEEE, 2015, pp. 1–10. [46] R. C. Martin, Clean code: A craftsman’s guide to software structure and design. Pearson Education, 2018. [47] S. Newman, Building microservices. O’Reilly Media, 2021. [48] L. Devroye, “Sample-based non-uniform random variate generation,” in Proceedings of the 18th Conference on Winter Simulation, 1986, pp. 260–265. [49] S. McIntosh and Y. Kamei, “Are fix-inducing changes a moving target? a longitudinal case study of just-in-time defect prediction,” in Proceedings of the 40th International Conference on Software Engineering, 2018, pp. 560–560. [50] C. Spearman, The proof and measurement of association between two things. Appleton-Century-Crofts, 1961. [51] X. Tan, M. Zhou, and Z. Sun, “A first look at good first issues on github,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2020, pp. 398–409.

JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, JUNE 2025

[52] N. Weeraddana, M. Alfadel, and S. McIntosh, “Characterizing timeout builds in continuous integration,” IEEE Transactions on Software Engineering, 2024. [53] J. A. Hanley and B. J. McNeil, “The meaning and use of the area under a receiver operating characteristic (roc) curve,” Radiology, vol. 143, no. 1, pp. 29–36, 1982. [54] K. Boyd, K. H. Eng, and C. D. Page, “Area under the precisionrecall curve: Point estimates and confidence intervals,” in Proceedings of the 2013 European Conference on Machine Learning and Knowledge Discovery in Databases. Springer, 2013, pp. 451–466. [55] D. W. Hosmer Jr, S. Lemeshow, and R. X. Sturdivant, Applied logistic regression. John Wiley & Sons, 2013. [56] M. Awad and L. Khan, “Support vector machines,” in Intelligent Information Technologies: Concepts, Methodologies, Tools, and Applications. IGI Global, 2008, pp. 1138–1146. [57] G. Biau and E. Scornet, “A random forest guided tour,” Test, vol. 25, no. 2, pp. 197–227, 2016. [58] T. Saito and M. Rehmsmeier, “The precision-recall plot is more informative than the roc plot when evaluating binary classifiers on imbalanced datasets,” PloS one, vol. 10, no. 3, p. e0118432, 2015. [59] C. Molnar, Interpretable machine learning. Lulu. com, 2020. [60] H. B. Mann and D. R. Whitney, “On a test of whether one of two random variables is stochastically larger than the other,” The Annals of Mathematical Statistics, pp. 50–60, 1947. [61] M. Fowler, Refactoring. Addison-Wesley Professional, 2018. [62] ——, “Code smell,” 2006. [Online]. Available: https: //martinfowler.com/bliki/CodeSmell.html [63] D. I. Sjøberg, A. Yamashita, B. C. Anda, A. Mockus, and T. Dybå, “Quantifying the effect of code smells on maintenance effort,” IEEE Transactions on Software Engineering, vol. 39, no. 8, pp. 1144– 1156, 2012. [64] A. Yamashita and L. Moonen, “Do code smells reflect important maintainability aspects?” in Proceedings of the 28th IEEE International Conference on Software Maintenance. IEEE, 2012, pp. 306–315. [65] W. Jin, Y. Dai, J. Zheng, Y. Qu, M. Fan, Z. Huang, D. Huang, and T. Liu, “Dependency facade: The coupling and conflicts between android framework and its customization,” in Proceedings of the IEEE/ACM 45th International Conference on Software Engineering. IEEE, 2023, pp. 1674–1686. [66] S. Eski and F. Buzluca, “An automatic extraction approach: Transition to microservices architecture from monolithic application,” in Proceedings of the 19th International Conference on Agile Software Development: Companion, 2018, pp. 1–6. [67] M. Rostami, K. Berahmand, and S. Forouzandeh, “A novel community detection based genetic algorithm for feature selection,” Journal of Big Data, vol. 8, no. 1, p. 2, 2021. [68] W. Jin, T. Liu, Y. Cai, R. Kazman, R. Mo, and Q. Zheng, “Service candidate identification from monolithic systems based on execution traces,” IEEE Transactions on Software Engineering, vol. 47, no. 5, pp. 987–1007, 2019. [69] A. K. Kalia, J. Xiao, R. Krishna, S. Sinha, M. Vukovic, and D. Banerjee, “Mono2micro: A practical and effective tool for decomposing monolithic java applications to microservices,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2021, pp. 1214–1224. [70] C. Zhong, C. Li, and H. Zhang, “Eism: An interactive and collaborative approach for software modularization,” Journal of Systems and Software, p. 112726, 2025. [71] C. Zhong, S. Li, H. Zhang, H. Huang, L. Yang, and Y. Cai, “Refactoring microservices to microservices in support of evolutionary design,” IEEE transactions on software engineering, 2024. [72] S. Mancoridis, B. S. Mitchell, C. Rorres, Y. Chen, and E. R. Gansner, “Using automatic clustering to produce high-level system organizations of source code,” in Proceedings of 6th International Workshop on Program Comprehension. IEEE, 1998, pp. 45–52. [73] D. Sas and P. Avgeriou, “An architectural technical debt index based on machine learning and architectural smells,” IEEE Transactions on Software Engineering, vol. 49, no. 8, pp. 4169–4195, 2023.

17

Related documents

• Experimental Settings in LLM-Based Program Repair: A Study of Inputs, Tool Access, Feedback, and Validation#965480
• A11yLTLNav: Automatic Detection of Accessibility Navigation Failures#965481
• Detecting Argument-Swap Bugs Using Context-Enhanced Code Representations#965482
• A Large-Scale Empirical Study of Quality Assurance Practices and Gaps in AI Agents#965483
• CARE: A Responsibility-Oriented Architecture for Domain-Scoped Resolution in Modular and Upgradeable Smart Contracts#965484