Ever since its initial release in 2008, the Android OS has rapidly grown to become the world’s most widely used mobile OS. Mobile vendors extend the Android Open Source Project (AOSP) led by Google to customize their own Android variants. With the AOSP releasing new versions frequently, vendors need to periodically carry out Android upgrades that integrate the latest code changes from AOSP into their Android variants. Both the AOSP and Android variants independently undergo complex modifications. Consequently, Android upgrades often lead to merge conflicts caused by competing changes to the same code line. Vendors have devoted significant effort to understanding and resolving these problems. Despite extensive research on Android upgrades and merge conflicts, there is little understanding of the conflict-related activities performed in Android upgrade practice, and the corresponding challenges faced by practitioners . In this study, we employed a qualitative research methodology involving questionnaires with 120 practitioners and interviews with a leading Android vendor to explore the challenges and improvement opportunities. Our investigation demonstrates that the Android upgrade process is fundamentally an exercise in architectural evolution, necessitating the adoption of architectural thinking rather than relying on mere code-level patches to systematically address upgrade-induced challenges. We have identified challenges at different stages of Android upgrade implementation, including baseline analysis, conflict reason analysis, conflict resolution, and conflict impact analysis. Our findings indicate opportunities for enhancing the Android upgrade practice, particularly in documentation, management, refactoring activities, and team collaboration. Additionally, we outline future research directions from an architectural perspective. We envision that our study can benefit software ecosystems where customized downstream derivatives need to maintain co-evolution with their upstream core.

The architecture of software systems evolves along with their upgrades and maintenance, inevitably creating a gap between the defact architecture and the designed one. To perceive and fix the discrepancy, clustering-based architecture recovery methods have been developed to re-engineer the real-time system architecture from the code implementation. However, existing solutions still face several limitations. They underutilize both code-level and architecture-level semantics underlying the source code. Moreover, they overlook implicit structural dependencies that complement explicit ones to reflect code interactions. To address these challenges, we propose SemArc, an architecture recovery method that utilizes large language models to comprehend both implementation-level and architecture-level semantics, supported by well-established canonical architectural patterns as a knowledge base. SemArc also incorporates both implicit and explicit dependencies to complete the system behavior representations. Additionally, SemArc introduces a component-as-anchor guided clustering algorithm to improve the clustering process. We evaluated SemArc on 15 software systems written in C/C++, Java, and Python, using five different metrics. The results demonstrate that SemArc outperforms seven baseline methods by an average of 32 percentage points. We also examined how three factors—code semantics, architectural semantics, and implicit dependencies—as well as different levels of architectural semantic descriptions, influence recovery accuracy. A case study on the Bash project indicates that SemArc has the potential to yield even more precise recovery results than those labeled by humans.

Phone vendors customize their Android variants to enhance system functionalities based on the Android Open Source Project (AOSP). While independent development, Android variants have to periodically evolve with the upstream AOSP and merge code changes from AOSP. Vendors have invested great effort to maintain their variants and resolve merging conflicts. In this paper, we characterize the design smells with recurring patterns that break the design boundary between Android variants and AOSP. These smells are manifested as problematic dependencies across the boundary, hindering Android variants' maintainability and co-evolution with AOSP. We propose the DroidDS for automatically detecting design smells. We collect 22 Android variant versions and 22 corresponding AOSP versions, involving 4 open-source projects and 1 industrial project. Our results demonstrate that: files involved in design smells consume higher maintenance costs than other files; these infected files are not merely the files with large code size, increased complexity, and object-oriented smells; the infected files have been involved in more than half of code conflicts induced by re-applying AOSP's changes to Android variants; a substantial portion of design issues could be mitigable. Practitioners can utilize our DroidDS to pinpoint and prioritize design problems for Android variants. Refactoring these problems will help keep a healthy coupling between diverse variants and AOSP, potentially improving maintainability and reducing conflict risks.

Binary function similarity detection plays an important role in a wide range of security applications. Existing works usually assume that the query function and target function share equal semantics and compare their full semantics to obtain the similarity. However, we find that the function mapping is more complex, especially when function inlining happens.

Dependency extraction based on static analysis lays the groundwork for a wide range of applications. However, dynamic language features in Python make code behaviors obscure and nondeterministic; consequently, it poses huge challenges for static analyses to resolve symbol-level dependencies. Although prosperous techniques and tools are adequately available, they still lack sufficient capabilities to handle object changes, first-class citizens, varying call sites, and library dependencies. To address the fundamental difficulty for dynamic languages, this work proposes an effective and practical method namely PyAnalyzer for dependency extraction. PyAnalyzer uniformly models functions, classes, and modules into first-class heap objects, propagating the dynamic changes of these objects and class inheritance. This manner better simulates dynamic features like duck typing, object changes, and first-class citizens, resulting in high recall results without compromising precision. Moreover, PyAnalyzer leverages optional type annotations as a shortcut to express varying call sites and resolve library dependencies on demand. We collected two micro-benchmarks (278 small programs), two macro-benchmarks (59 real-world applications), and 191 real-world projects (10MSLOC) for comprehensive comparisons with 7 advanced techniques (i.e., Understand, Sourcetrail, Depends, ENRE19, PySonar2, PyCG, and Type4Py). The results demonstrated that PyAnalyzer achieves a high recall and hence improves the F1 by 24.7% on average, at least 1.4x faster without an obvious compromise of memory efficiency. Our work will benefit diverse client applications.

In the field of software development, the application of code quality check tools has become a key factor in improving product quality and development efficiency. While many existing tools are effective at detecting common problems in code, there are still some limitations. Firstly, these tools rely on predefined rules that may not fully encompass real-world coding challenges. Secondly, a lack of consideration of dependencies leads to failure to report violations occurring across files or modules. Third, the metrics used by these tools primarily focus on object-oriented programming, limiting their ability to assess software quality from the perspective of nationalized standards. To address these issues, this work proposes a dependency-enhanced method namely ERD-CQC for code quality detection and measurement. ERD-CQC provides 88 detection rules and 45 metrics, supplementing checking rules in categories such as Circuit Breaking, Serializable, and Security. ERD-CQC constructs an infused graph by integrating abstract syntax trees (ASTs), entities, and dependencies for violation detection. Based on the detection results, ERD-CQC provides a code quality measurement system with 4 nationalized standard dimensions for the purpose of measuring code quality from multiple perspectives. To validate the effectiveness of ERD-CQC, we manually examined 647 compliant and 528 non-compliant code snippets. ERD-CQC achieves the recall and F1 score exceeding 98%. We also collected open-source projects and closed-source projects in the real world, containing a total of 4,319 non-compliant code snippets. On this real-world benchmark, the average F1 score of ERD-CQC is 11.44% higher than the advanced tool SonarQube. Finally, we visualized the quality measurement results based on metrics and found that open-source and closed-source projects have certain patterns in metric performance. Our work will benefit developers in checking, evaluating, and monitoring their software quality comprehensively.

Mobile apps often access personal information to meet business needs, raising concerns about privacy breaches. Compliance detection methods are proposed to check for inconsistencies between program code and privacy policies. However, existing methods face challenges with the low efficiency of static data flow analysis tools and often neglect physical data transmission destinations.

The rising popularity of mini-programs deployed on super-app platforms has drawn significant attention due to their convenience. However, developers' improper handling of data permission application in mini-programs has raised concerns about non-compliance and violations. Unfortunately, existing tools lack the capability to support the construction of a universal function call graph for the mini-program and the literature lacks a comprehensive and systematic study of the abusive issues. To bridge this gap, this paper introduces an automated tool, MiniChecker, to uncover the abusive permission request behavior in mini-programs. It defines five primary categories of abusive issues, namely homepage pop-up, overlaying pop-up, bothering pop-up, repeating pop-up, and looping pop-up, based on the request behavior features. MiniChecker achieves a detection precision rate of 82.4% and a recall rate of 95.3% on our benchmark, and identifies 3,866 risky mini-programs out of 20,000 real-world mini-programs. Our analysis reveals inherent design flaws in the mini-program permission mechanism, and we have shared our findings with several mini-program platforms.

Deep neural networks (DNNs) and natural language processing (NLP) systems have developed rapidly and have been widely used in various real-world fields. However, they have been shown to be vulnerable to backdoor attacks. Specifically, the adversary injects a backdoor into the model during the training phase, so that input samples with backdoor triggers are classified as the target class. Some attacks have achieved high attack success rates on the pre-trained language models (LMs), but there have yet to be effective defense methods. In this work, we propose a defense method based on deep model mutation testing. Our main justification is that backdoor samples are much more robust than clean samples if we impose random mutations on the LMs and that backdoors are generalizable. We first confirm the effectiveness of model mutation testing in detecting backdoor samples and select the most appropriate number of mutants and mutation operators. We then systematically defend against three extensively studied backdoor attack levels (i.e., char-level, word-level, and sentence-level) by detecting backdoor samples. We also make the first attempt to defend against the latest style-level backdoor attacks. We evaluate our approach on three benchmark datasets (i.e., IMDB, Yelp, and AG news) and three style transfer datasets (i.e., SST-2, Hate-speech, and AG news). The extensive experimental results demonstrate that our approach can detect backdoor samples more efficiently and accurately than the three state-of-the-art defense approaches.

As software continues to evolve and business functions become increasingly complex, architectural inconsistency arises when the implementation architecture deviates from the expected architecture design. This architectural problem makes maintenance difficult and requires significant effort to refactor. To assist labor-intensive refactoring, automated refactoring has received much attention such as searching for optimal refactoring solutions. However, there are still three limitations: The recommended refactorings are insufficiently effective in addressing architectural consistency; the search process for refactoring solution is inefficient; and there is a lack of executable refactoring solutions. To address these limitations, we propose an effective, efficient, and executable refactoring recommendation approach namely the 3Erefactor for software architectural consistency. To achieve effective refactoring, 3Erefactor uses NSGA-II to generate refactoring solutions that minimize architectural inconsistencies at module level and entity level. To achieve efficient refactoring, 3Erefactor leverages architecture recovery technique to locate files requiring refactoring, helping accelerate the convergence of refactoring algorithm. To achieve executable refactoring, 3Erefactor designs a set of refactoring executability constraint strategies during the refactoring solution search and generation, including improving refactoring pre-conditions and removing invalid operations in refactoring solutions. We evaluated our approach on six open source systems. Statistical analysis of our experiments shows that, the refactoring solution generated by 3Erefactor performed significantly better than 3 state-of-the-art approaches in terms of reducing the number of architectural inconsistencies, improving the efficiency of the refactoring algorithm and improving the executability of refactorings.

Mini-app is an emerging form of mobile application that combines web technology with native capabilities. Its features, e.g., no need to download and no installation, have made it popular rapidly. However, privacy issues that violate the laws or regulations are breeding in the swiftly expanding mini-app ecosystem. Ensuring consistency between the mini-app's data practices embedded in its program code behavior and privacy policy description is crucial. But no work has systematically investigated the privacy problem of the mini-app before. To achieve this purpose, there are two main challenges. Firstly, the mini-app represents a novel application form, and a deficiency exists in information-sensitive code analysis tools capable of accurately discerning data practices from the code. Secondly, previous studies focusing on consistency have exhibited granularity issues related to data types and consistency patterns. This paper introduces MiniDetector, a novel approach for identifying consistency issues in mini-apps. MiniDetector employs data flow analysis to pinpoint data practices within the program code and utilizes a two-stage prompt engineering process to extract data practices from privacy policies. The results from both analyses are then compared to establish a consistency match. The proposed method undergoes sufficiency evaluations on a dataset comprising 70 mini-apps. Additionally, we conduct a comprehensive analysis of 100,000 mini-apps on the WeChat client in the wild, extracting 3,369 with privacy policies. Astonishingly, only 11 of these meet the consistency requirements, while 3,358 exhibit inconsistencies, resulting in an alarming inconsistency rate of 99.7%.

Mobile device vendors develop their customized Android OS (termed downstream) based on Google Android (termed upstream) to support new features. During daily independent development, the downstream also periodically merges changes of a new release from the upstream into its development branches, keeping in sync with the upstream. Due to a large number of commits to be merged, heavy code conflicts would be reported if auto-merge operations failed. Prior work has studied conflicts in this scenario. However, it is still unclear about the coupling between the downstream and the upstream (We term this coupling as the dependency facade), as well as how merge conflicts are related to this coupling. To address this issue, we first propose the DepFCD to reveal the dependency facade from three aspects, including interface-level dependencies that indicate a clear design boundary, intrusion-level dependencies which blur the boundary, and dependency constraints imposed by the upstream non-SDK restrictions. We then empirically investigate these three aspects (RQ1, RQ2, RQ3) and merge conflicts (RQ4) on the dependency facade. To support the study, we collect four open-source downstream projects and one industrial project, with 15 downstream and 15 corresponding upstream versions. Our study reveals interesting observations and suggests earlier mitigation of merge conflicts through a well-managed dependency facade. Our study will benefit the research about the coupling between upstream and downstream as well as the downstream maintenance practice.

During long-term software evolution, it is inevitable that an accumulation of changes leads to architectural erosion and debt. Diverse metric-based methods have been developed to identify architectural problems that violate design principles and degrade software maintainability. However, there still exists a gap between the implementation-level metrics and architecture-level metrics. Consequently, it hinders the comprehensibility, interpretability, and indicative(-bility) of the measurement results. To fill this gap, we propose the dbMIT to identify potential code changes that make architecture decay. Our dbMIT first integrates popular metrics such as the CK suite. Then dbMIT constructs a forest structure of metrics, serving as a knowledge base to relate the metrics across levels together. The forest aims to link the architecture-level metrics and implementation-level metrics. Via pre-defined rules using the forest structure, our dbMIT identifies code changes that potentially cause the architecture decay. The usage of forest structure of metrics makes it easy for developers to understand detection results, explain why the detected code changes are potential contributors to the decay, and indicate the code scope for resolution. We also contribute a web-based tool to integrate our dbMIT. Our experiments on the collected projects demonstrate the effectiveness of dbMIT against a history-based ground-truth.

Binary similarity analysis is critical to many code-reuse-related issues, where function matching is its fundamental task. “ 1-to-1 ” mechanism has been applied in most binary similarity analysis works, in which one function in a binary file is matched against one function in a source file or binary file. However, we discover that the function mapping is a more complex problem of “ 1-to-n ” (one binary function matches multiple source functions or binary functions) or even “ n-to-n ” (multiple binary functions match multiple binary functions) due to the existence of function inlining , different from traditional understanding. In this article, we investigate the effect of function inlining on binary similarity analysis. We carry out three studies to investigate the extent of function inlining, the performance of existing works under function inlining, and the effectiveness of existing inlining-simulation strategies. Firstly, a scalable and lightweight identification method is designed to recover function inlining in binaries. 88 projects (compiled in 288 versions and resulting in 32,460,156 binary functions) are collected and analyzed to construct four inlining-oriented datasets for four security tasks in the software supply chain, including code search, OSS (Open Source Software) reuse detection, vulnerability detection, and patch presence test. Datasets reveal that the proportion of function inlining ranges from 30–40% when using O3 and sometimes can reach nearly 70%. Then, we evaluate four existing works on our dataset. Results show most existing works neglect inlining and use the “1-to-1” mechanism. The mismatches cause a 30% loss in performance during code search and a 40% loss during vulnerability detection. Moreover, most inlined functions would be ignored during OSS reuse detection and patch presence test, thus leaving these functions risky. Finally, we analyze two inlining-simulation strategies on our dataset. It is shown that they miss nearly 40% of the inlined functions, and there is still a large space for promotion. By precisely recovering when function inlining happens, we discover that inlining is usually cumulative when optimization increases. Thus, conditional inlining and incremental inlining are recommended to design a low-cost and high-coverage inlining-simulation strategy.

Dependencies among software entities are the foundation for much of the research on software architecture analysis and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain dependencies indiscernible by a purely syntactic analysis of source code. We call thesepossible dependencies, in contrast with theexplicit dependenciesthat are directly manifested in source code. We find that existing architecture analysis tools have not taken possible dependencies into consideration. An important question therefore is:to what extent will these missing possible dependencies impact architecture analysis?To answer this question, we conducted a study of 499 open-source Python projects, employing type inference techniques and type hint practices to discern possible dependencies. We investigated the consequences of possible dependencies in three software maintenance contexts, including capturing co-change relations recorded in revision history, measuring architectural maintainability, and detecting architecture anti-patterns that violate design principles and impact maintainability. Our study revealed that the impact of possible dependencies on architecture-level maintainability is substantial—higher than that of explicit dependencies. Our findings suggest that architecture analysis and tools should take into account, assess, and highlight the impacts of possible dependencies caused by dynamic typing.

The fairness characteristic is a critical attribute of trusted AI systems. A plethora of research has proposed diverse methods for individual fairness testing. However, they are suffering from three major limitations, i.e., low efficiency, low effectiveness, and model-specificity. This work proposes ExpGA, an explanation-guided fairness testing approach through a genetic algorithm (GA). ExpGA employs the explanation results generated by interpretable methods to collect high-quality initial seeds, which are prone to derive discriminatory samples by slightly modifying feature values. ExpGA then adopts GA to search discriminatory sample candidates by optimizing a fitness value. Benefiting from this combination of explanation results and GA, ExpGA is both efficient and effective to detect discriminatory individuals. Moreover, ExpGA only requires prediction probabilities of the tested model, resulting in a better generalization capability to various models. Experiments on multiple real-world benchmarks, including tabular and text datasets, show that ExpGA presents higher efficiency and effectiveness than four state-of-the-art approaches.

The black-box nature of the Deep Neural Network (DNN) makes it difficult for people to understand why it makes a specific decision, which restricts its applications in critical tasks. Recently, many interpreters (interpretation methods) are proposed to improve the transparency of DNNs by providing relevant features in the form of a saliency map. However, different interpreters might provide different interpretation results for the same classification case, which motivates us to conduct the robustness evaluation of interpreters.

Architecture anti-patterns violate design principles and negatively impact software internal quality. Both academia and industry have designed methods and tools to detect anti-patterns. However, these tools tend to report a large number of defects, hindering developers from prioritizing true debts. In this work, we take one step further to explore the most problematic files (we define them as root files) in the architecture anti-patterns, which are potential causes leading to the difficulty of software maintenance. Using 45 Python projects as subjects, we investigate root files' maintainability, evolution (i.e., birth, living, and death), and their interactions in different architecture anti-patterns. Our results reveal that, compared with other files in anti-patterns, these root files take only a small proportion but incur heavy maintenance costs. Our study of their evolution and interactions can help developers identify potential causes of anti-patterns. We believe our findings will benefit the practice of design problem fixing.

Dynamic programming languages have been embracing gradual typing, which supports optional type annotations in source code. Type-annotating a complex and long-lasting codebase is indeed a gradual and expensive process, where two issues have troubled developers. First, there is few guidance about how to implement type annotations due to the existence of non-trivial type practices; second, there is few guidance about which portion of a codebase should be type-annotated first. To address these issues, this paper investigates the patterns of non-trivial type-annotation practices and features of type-annotated code files. Our study detected six patterns of type-annotation practices, which involve recovering and expressing design concerns. Moreover, we revealed three complementary features of type-annotated files. Besides, we implemented a tool for studying optional typing practice. We suggest that: 1) design concerns should be considered to improve type annotation implementation by following at least six patterns; 2) files critical to software architecture could be type-annotated in priority. We believe these guidelines would promote a better type annotation practice for dynamic languages.

Monolithic systems increasingly suffer from maintainability and scalability issues as they grow in functionality, size, and complexity. It is widely believed that (micro)service-based architectures can alleviate these problems as each service is supposed to have the following characteristics: clearly defined functionality, sufficient modularity, and the ability to evolve independently. Industrial practices show that service extraction from a legacy monolithic system is labor-intensive and complex. Existing work on service candidate identification aims to group entities of a monolithic system into potential service candidates, but this process has two major challenges: first, it is difficult to extract service candidates with consistent quality; second, it is hard to evaluate the identified service candidates regarding the above three characteristics. To address these challenges, this paper proposes the Functionality-oriented Service Candidate Identification (FoSCI) framework to identify service candidates from a monolithic system. Our approach is to record the monolith's execution traces, and extract services candidates using a search-based functional atom grouping algorithm. We also contribute a comprehensive service candidate evaluation suite that uses interface information, structural/conceptual dependency, and commit history. This evaluation system consists of 8 metrics, measuring functionality, modularity, and evolvability respectively of identified service candidates. We compare FoSCI with three existing methods, using 6 widely-used open-source projects as our evaluation subjects. Our results show that FoSCI outperforms existing methods in most measures.

Dependencies among software entities are the basis for many software analytic research and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain syntactic dependencies indiscernible in source code. We call these possible dependencies, in contrast with the explicit dependencies that are directly referenced in source code. Type inference techniques have been widely studied and applied, but existing architecture analytic research and tools have not taken possible dependencies into consideration. The fundamental question is, to what extent will these missing possible dependencies impact the architecture analysis? To answer this question, we conducted an empirical study with 105 Python projects, using type inference techniques to manifest possible dependencies. Our study revealed that the architectural impact of possible dependencies is substantial---higher than that of explicit dependencies: (1) file-level possible dependencies account for at least 27.93% of all file-level dependencies, and create different dependency structures than that of explicit dependencies only, with an average difference of 30.71%; (2) adding possible dependencies significantly improves the precision (0.52%~14.18%), recall(31.73%~39.12%), and F1 scores (22.13%~32.09%) of capturing co-change relations; (3) on average, a file involved in possible dependencies influences 28% more files and 42% more dependencies within architectural sub-spaces than a file involved in just explicit dependencies; (4) on average, a file involved in possible dependencies consumes 32% more maintenance effort. Consequently, maintainability scores reported by existing tools make a system written in these dynamic languages appear to be better modularized than it actually is. This evidence strongly suggests that possible dependencies have a more significant impact than explicit dependencies on architecture quality, that architecture analysis and tools should assess and even emphasize the architectural impact of possible dependencies due to dynamic typing.

Over the past decades, numerous approaches were proposed to help practitioner to predict or locate defective files. These techniques often use syntactic dependency, history co-change relation, or semantic similarity. The problem is that, it remains unclear whether these different dependency relations will present similar accuracy in terms of defect prediction and localization. In this paper, we present our systematic investigation of this question from the perspective of software architecture. Considering files involved in each dependency type as an individual design space, we model such a design space using one DRSpace. We derived 3 DRSpaces for each of the 117 Apache open source projects, with 643,079 revision commits and 101,364 bug reports in total, and calculated their interactions with defective files. The experiment results are surprising: the three dependency types present significantly different architectural views, and their interactions with defective files are also drastically different. Intuitively, they play completely different roles when used for defect prediction/localization. The good news is that the combination of these structures has the potential to improve the accuracy of defect prediction/localization. In summary, our work provides a new perspective regarding to which type(s) of relations should be used for the task of defect prediction/localization. These quantitative and qualitative results also advance our knowledge of the relationship between software quality and architectural views formed using different dependency types.

Test case prioritization is widely used in testing with the purpose of detecting faults as early as possible. Most existing techniques exploit coverage to prioritize test cases based on the hypothesis that a test case with higher coverage is more likely to catch bugs. Statement coverage and function coverage are the two widely used coverage granularity. The former typically achieves better test case prioritization in terms of fault detection capability, while the latter is more efficient because it incurs less overhead. In this paper we argue that static information such as statement and function coverage may not be the best criteria for guiding dynamic executions. Executions that cover the same set of statements /functions can may exhibit very different behavior. Therefore, the abstraction that reduces program behavior to statement/function coverage can be too simplistic to predicate fault detection capability. We propose a new approach that exploits function call sequences to prioritize test cases. This is based on the observation that the function call sequences rather than the set of executed functions is a better indicator of program behavior. Test cases that reveal unique function call sequences may have better chance to encounter faults. We choose function instead of statement sequences due to the consideration of efficiency. We have developed and implemented a new prioritization strategy AGC (Additional Greedy method Call sequence), that exploit function call sequences. We compare AGC against existing test case prioritization techniques on eight real-world open source Java projects. Our experiments show that our approach outperforms existing techniques on large programs (but not on small programs) in terms of bug detection capability. The performance shows a growth trend when the size of program increases.

The main task of microservice extraction is to find which software entities (e.g., methods, classes) should be grouped together from existing monolithic software as candidate microservices, responsible for specific functionalities and evolving independently. Current methods extract microservices by analyzing source code and following the assumption that "classes with strong relation should be in the same service", which originates from software structure analysis. We find that 1) many program behaviors cannot be explicitly reflected in the source code, and 2) the relation at code-level is not equivalent to the same functionality. Thus, we propose a functionality-oriented microservice extraction (FoME) method in this study by monitoring program dynamic behavior and clustering execution traces. Instead of source code analysis, the execution traces of a program are applied to group source code entities that are dedicated to the same functionality. We also construct a systematic measurement of microservice by integrating five complementary metrics of service cohesion and coupling. These metrics measure Functional Independence of microservices. That is, it qualifies whether a microservices can have its own responsibilities independently. In the experiment, our method is compared with three state-of-the-art methods on four open-source projects. The microservice candidates generated using our method present similar functional cohesion to the services produced using the other methods, but have considerably looser coupling measurements (dramatically reducing measurements of IRN and OPN).