A method for modeling and identifying coupling surfaces between upstream and downstream software systems

Abstract

This invention discloses a method for constructing and identifying coupling surfaces between upstream and downstream software systems. First, based on the entity dependency information of upstream and downstream projects, a dependency graph for each project version is obtained. Then, based on the commit history of the code repositories of downstream and upstream projects, the `git blame` command is used to trace the commit history of the constituent entities to determine the commit attribution. Simultaneously, the Refactor-Miner tool is used in conjunction with refactoring operations in the commit history to ensure the completeness of the change history of each entity, resulting in a more complete change history for each entity. By combining the commit composition of the entities, the attribution information of each entity in the project dependency graph is obtained. Furthermore, based on Android's interface restriction level information, the restriction level of the entities is obtained. Finally, entities that have undergone intrusive modifications are identified, and the coupling surface between upstream and downstream software systems is output, revealing the specific form of downstream dependence on upstream.

Description

Technical Field

[0001] This invention belongs to the field of software evolution and redevelopment, and relates to a method for modeling and identifying coupling surfaces between upstream and downstream software systems. Background Technology

[0002] The coupling surface between upstream and downstream software systems is a dependency subgraph generated when a downstream project couples with an upstream system. A downstream project consists of upstream source code developed by the upstream and a large amount of code developed by the downstream itself. Therefore, the downstream is modeled as a dependency graph with different attributes, and the coupling surface between upstream and downstream software systems is defined as a subgraph. An example of the coupling surface between upstream and downstream software systems in the Android operating system ecosystem is the custom Android operating system developed by mobile device vendors based on Google's Android, i.e., the Android Open Source Project (AOSP), to enhance the functionality of the Android operating system, support new features, and add custom functions. Custom systems in AOSP include MIUI, MagicUI, LineageOS, etc. Custom Android systems are usually referred to as downstream projects, while the AOSP maintained by Google is referred to as the upstream. In addition to independent development, the downstream also needs to regularly merge changes from new versions of the upstream into their development branches and keep synchronized with the upstream. Due to the large number of commits to merge, if the automatic merge operation fails, VCS (Version Control System) such as Git will report a large number of code conflicts (named text conflicts).

[0003] Currently, research on how downstream applications depend on upstream applications and how code conflicts are related to this coupling remains lacking. Existing work has focused on conflicts caused by upstream and downstream merges, investigating overlapping changes between historical commits of a project and commits of the upstream project, while reproducing changes from downstream merges, revealing the impact of code conflicts on Android mobile applications. However, it has not studied the specific coupling forms from a system architecture perspective, nor the problems and impacts brought about by different coupling forms. Finally, there is an industry case study investigating the conflict issues caused by upstream merges in the context of Microsoft Edge development. However, all these works study merge conflicts through commit analysis. Summary of the Invention

[0004] The purpose of this invention is to overcome the lack of research in existing studies on downstream coupling to upstream systems and the correlation between code conflicts and such coupling, and to provide a method for constructing and identifying coupling surfaces between upstream and downstream software systems, characterized by comprising:

[0005] The dependency extraction module obtains the entity dependency graph between upstream and downstream projects; the attribution identification module determines the attribution of entities in downstream projects based on version information and commit history in the project repository; the intrusive modification identification module identifies upstream entities that have undergone intrusive modification operations based on the commit information of the constituent entities; the restriction level labeling module is used to label the restriction level of each entity in the dependency graph; and the coupling surface identification module between upstream and downstream software systems identifies the coupling surface between upstream and downstream software systems according to the coupling surface rules.

[0006] To achieve the above objectives, the present invention employs the following technical solution:

[0007] Modeling the coupling surface between upstream and downstream software systems includes the following parts:

[0008] S1: Dependency graph of upstream and downstream projects;

[0009] S2: Intrusive modifications and attribution of upstream entities by downstream projects;

[0010] S3: Restriction level for upstream and downstream project entities;

[0011] S4: Text conflicts that occur when a downstream project merges a new version of an upstream project.

[0012] The method for identifying coupling surfaces between upstream and downstream software systems includes the following steps:

[0013] S201: Use the ENRE tool to obtain the entity dependency graph between upstream and downstream projects;

[0014] S202: Based on the version information and commit history in the project repository, determine the owner of the entity in the downstream project;

[0015] S203: Based on the commit information of the constituent entities, combined with dependency graph analysis, Refactor-Miner and gitblame results, various modification operations are detected to identify entities that have performed intrusive modification operations;

[0016] S204: Based on the project's restriction level information, obtain the restriction level of each entity in the dependency graph.

[0017] Compared with the prior art, the present invention has the following beneficial effects:

[0018] This invention discloses a method for constructing and identifying coupling surfaces between upstream and downstream software systems. First, based on the entity dependency information of upstream and downstream projects, a complete coupling model of the upstream and downstream software systems is constructed using the ENRE tool. This model contains comprehensive information and interprets the specific forms of downstream coupling to upstream from the perspective of entity dependencies, obtaining the dependency graph of each project version. Then, based on the commit history of the code repositories of downstream and upstream projects, the commit history of the constituent entities is traced back using the `git blame` command to determine the commit attribution. Simultaneously, Refactor-Miner is used to detect refactoring information that occurs during project evolution and coupling, and the `git blame` traceback information is verified to make the detection results more accurate and improve the reliability of the results, obtaining a more complete change history for each entity. By combining the commit composition of the entities, the attribution information of each entity in the project dependency graph is obtained. Furthermore, with the evolution of the Android system, Google's upstream Android system (since Android...) Since 2009, restrictions on non-SDK interfaces have been proposed through whitelists / greylists / blacklists to limit the use of non-SDK (i.e., hidden) interfaces, thereby maintaining user privacy and system interface stability. This invention combines the restriction level of the interface with entity information to output a more complete restriction level entity dependency graph. Finally, based on the ownership information of the above entities, entities that have undergone intrusive modifications are identified, and the coupling surface between upstream and downstream software systems is output. This surface includes the above entity dependency information, ownership information, and interface restriction level information, thus obtaining the specific form of downstream dependence on upstream. Attached Figure Description

[0019] Figure 1 The diagram below is a model block diagram of the coupling surface identification method between upstream and downstream software systems according to an embodiment of the present invention, wherein (a) is an entity dependency graph, (b) is an entity dependency graph with intrusive modification markers, (c) is an entity dependency graph with restriction level markings, and (d) is an entity dependency graph incorporating text conflict information.

[0020] Figure 2 This is a flowchart of the coupling surface identification method between upstream and downstream software systems according to an embodiment of the present invention;

[0021] Figure 3 This is an analytical diagram of the entity restriction level in an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] The present invention will now be described in further detail with reference to the accompanying drawings:

[0025] See Figure 1 In one embodiment of the present invention, a coupling surface modeling method between upstream and downstream software systems is provided.

[0026] Specifically, the coupling surface model between the upstream and downstream software systems includes the following parts:

[0027] S1: Dependency graph of upstream and downstream projects;

[0028] S2: Intrusive modifications made by downstream projects to upstream entities;

[0029] S3: Restriction level for upstream and downstream project entities;

[0030] S4: Text conflicts that occur when a downstream project merges a new version of an upstream project.

[0031] Specifically, the DepFCD model between upstream and downstream software systems in this invention represents downstream extension projects as dependency graphs with different attributes, that is, it defines the coupling surface between upstream and downstream software systems as a subgraph to characterize the coupling between downstream and upstream. Figure 1 The basic structure of the model is shown, and key concepts are explained in this way. Figure 1 (a) Represent upstream and downstream projects as a dependency graph, where each node represents an entity e in the source code, such as a class, interface, method, variable, etc.; each directed edge e i →e j This represents the dependencies between nodes, such as inheritance between classes, aggregation between classes, and method calls. Then, the dependency graph of downstream projects is decomposed to identify coupling surfaces, which are minimal subgraphs coupling downstream code with upstream code. The coupling surfaces between upstream and downstream software systems reveal the design decisions exposed by downstream development to depend on and extend upstream Android. For example... Figure 1 As shown in (b), the decomposition results in three parts: the upstream entity and its dependencies, the extended entity and its dependencies, and the coupling surface connecting the upstream and extended entities. The upstream entity is initially created by the upstream Android system but may be further modified by downstream development. The extended entity is created by the downstream project and is unaware of upstream development. At a fine-grained level, interface-level dependencies on the dependency surface—i.e., inheritance, implementation, aggregation, invocation, etc.—will indicate how the downstream project depends on or is dependent on the upstream project.

[0032] In one possible implementation, local entities from the upstream project on the coupling surface between upstream and downstream software systems may be intrusively modified by downstream development. For example... Figure 1 As shown in (b), upstream entities are divided into three types: actively native upstream entities, which are entities created upstream and remain unchanged downstream; intrusively native upstream entities, which are upstream entities directly modified by downstream; and obsoletely native upstream entities, which have been abandoned by upstream Android but are still relied upon by downstream development. Figure 1 (b) shows an intrusive upstream entity with a "rename class" operation. These upstream entities that have undergone intrusive modifications indicate tighter coupling, causing the implementation logic of downstream code to mix with upstream code. This situation is called intrusive dependency because it blurs the design boundaries between downstream and upstream, while interface dependency has clear design boundaries.

[0033] Specifically, Google's upstream Android system (since Android 9) imposes restrictions on non-SDK interfaces through whitelists / greylists / blacklists to limit the exploitation of non-SDK (i.e., hidden) interfaces. Assume that non-SDK restrictions impose dependency constraints on the coupling surface between upstream and downstream software systems—an entity should only depend on entities more stable than itself, as stated in the Stable Dependency Principle (SDP). Non-SDK entities are unstable internal and private interface entities within the Android framework. Because the level of these interfaces changes during upgrades, downstream code needs frequent modifications and maintenance to accommodate them. The restriction levels for non-SDK entities can be declared in several ways: publicly accessible SDK / whitelist, blocked / blacklist (should not be accessed), unsupported / greylist (can be exploited by developers but is unstable and will change in the future), and max-target-"X" / greylist (accessible in Android versions no lower than "X"). Figure 1 (c) shows an SDK entity and a blocked entity.

[0034] Specifically, after studying dependency surfaces with interface-level dependencies, intrusion-level dependencies, and dependency constraints, the following analysis will examine the occurrence of merge conflicts at the coupling surface between upstream and downstream software systems, such as... Figure 1 As shown in (d), merge conflicts occur when downstream code merges changes from upstream code to keep in sync with it. Of particular concern are textual conflicts reported by CVS, as their resolution is of high priority to get the updated operating system up and running quickly, facilitating subsequent functional testing.

[0035] See Figure 2 In one embodiment of the present invention, a method for identifying the coupling surface between upstream and downstream software systems is provided. Compared with existing research, this method can identify the coupling between downstream and upstream projects, as well as the correlation between text conflicts and coupling methods.

[0036] Specifically, the method for identifying the coupling surface between upstream and downstream software systems includes the following steps:

[0037] S201: Obtain the entity dependency graph between upstream and downstream projects;

[0038] S202: Based on the version information and commit history in the project repository, determine the owner of the entity in the downstream project;

[0039] S203: Identify the entities that have undergone intrusive modification operations based on the commit information of the constituent entities;

[0040] S204: Based on the project's restriction level information, obtain the restriction level of each entity in the dependency graph.

[0041] Specifically, this invention designs a DepFCD method to detect the coupling surfaces between upstream and downstream software systems, specifically downstream projects and their corresponding upstream projects. This method uses static code analysis and commit analysis techniques to localize dependency surfaces with different attributes.

[0042] join Figure 2 This demonstrates the specific steps of the method. The source code and commit history of both downstream and upstream projects are input, with their commit history managed by a version control system such as Git. First, static code analysis is performed on the source code of each version of each project to extract entities and dependencies, generating a dependency graph. U For the upstream project dependency graph, G D For downstream project dependency graphs. Entity ownership identification analysis of upstream and downstream project commit history to determine G. DThe ownership of each entity e is defined, and entity ownership e.ownership can be an active upstream, an obsolete upstream, an intrusive upstream, or an extended entity. Based on ownership, the coupling surface G between upstream and downstream software systems can be localized. F By mining G U and G D The differences in commit history and dependency graphs between upstream and downstream entities are analyzed. Intrusion operation identification detects downstream intrusion operations that modify upstream entities and stores them in `e.operation`. Next, the restriction level label exports the non-SDK restriction lists for both upstream and downstream projects. It stores the restriction levels (i.e., sdk, blocked, unsupported, max-target-"X") in the corresponding `e.restrictlevel`. Finally, DepFCD outputs the updated G' with entity attributes (i.e., entity ownership, intrusive operation, and restriction level). D , and its subgraph G F (i.e., dependency surface).

[0043] In one possible implementation, entities and dependencies are extracted from the source code using ENRE, outputting a graph G where nodes represent entities and edges represent dependencies between them. ENRE is a broad framework for multilingual dependency extraction based on Abstract Syntax Tree (AST) analysis. Extracted entities include classes, methods, interfaces, annotations, etc. Dependencies include inheritance between classes, implementations from classes to interfaces, and calls between methods.

[0044] Specifically, each entity extracted by ENRE has several common attributes: id uniquely identifies an entity, qualified name textually describes the entity's name, and position indicates its line number in the source file. Each dependency dep (from e...) i to e j It also has some attributes: src represents e i The id, dest represents e j The id and value records specific information, such as the dependency type.

[0045] In one possible implementation, by inputting a dependency graph (G) including downstream projects... D ), downstream project commit history (Commit) D ), and the corresponding upstream version's commit history (Commit) U ) and commit history of older upstream versions (Commit) O This module performs entity ownership identification. It identifies the ownership of each entity e in the downstream dependency graph GD and records the ownership label in the entity attribute e.ownership.

[0046] The specific process for identifying the entity's owner is as follows: First, the command `git blame` is used to obtain the commit set (Commit) related to entity e. e For G D In the `git blame Ln1, n2filename` command, the entity `e` is defined by the source file `e.filename`, and `e.location` specifies its starting line number (`n1`) and ending line number (`n2`). The commit is traced by running `git blame Ln1, n2filename`. e It modified rows n1 to n2 of line e. Then, according to the Commits... u Commits d Commits o and Commits e To determine the ownership of entity e. Based on

[0047] U e =Commits u ∩Commits e

[0048] D e =Commits D ∩Commits e

[0049] O e =Commits O ∩Commits e

[0050] Therefore, it is proposed

[0051]

[0052]

[0053]

[0054]

[0055] Among them, by utilizing entity ownership information, the dependency facade G was detected. F =<V‘,D’> It belongs to the downstream dependency graph G. D =<V,D> A subgraph. Each edge in the coupling surface between upstream and downstream software systems connects an extended entity and an upstream entity; that is, each edge in D′ represents d = e. i →e j All should meet one of the following conditions:

[0056] e i.ownership="extensive"and e j .ownership.endwith("native");

[0057] e j .ownership="extensive"and e i .ownership.endwith("native")

[0058] In one possible implementation, intrusive modifications are changes made by downstream developers to intrusive upstream entities from upstream versions. The specific identification process combines dependency graph analysis, Refactor-Miner, and git blame results to detect various modification operations. First, it identifies operations that modify accessibility / finality and add imports: given a class or method entity e... i e i It is a downstream dependency graph G D An intrusive upstream entity, the corresponding entity is upstream G. U e j By e i With e j Compare to determine the upstream e j The modifier keywords (such as private, public, protected, final) indicate whether the operation is newly added, modified, or deleted. If such a change occurs, the downstream operation is marked as a specific modification operation. Similarly, for the downstream file entity e... i If any new import dependencies are introduced, then e i .operation will be marked as "Add import".

[0059] Secondly, identify operations that modify method parameters / variables / body and operations that modify / add class global variables: for G D Intrusive upstream method entity e exists in i to G U The corresponding upstream entity e j Compare. Considering e i It is a modified method entity: if e i The parameter list and e j Different, e i .operation="Modify method parameters". If the code body is modified, e i .operation = "Modify method body". Similarly, by comparing G... D and G U To detect other refactoring and modification operations.

[0060] Finally, identify the operations for renaming / moving classes and moving / renaming / extracting methods: by using the Refactor-Miner tool to detect in G D An upstream entity e that undergoes intrusive modification i Refactor-Miner performs refactoring operations on the commit history. D It uses an AST-based statement matching algorithm to determine reconstruction candidates without requiring a user-defined threshold.

[0061] In one possible implementation, the restriction level labeling is intended to use upstream and downstream dependency graphs, G U and G D The restriction level attribute is used to mark entity nodes. According to the official Android guide, first execute the command "m out / soong / hiddenapi / hiddenapi-flags.csv" in the source code repository of the downstream (or upstream) Android project. The output file, hiddenapi.csv, lists the restriction levels of non-SDK interface entities.

[0062] Specifically, let's take an example to illustrate the parsing process of the restriction level file hiddenapi.csv generated by the project version. Figure 3 This displays a line from the hiddenapi.csv file. Following the JNI specification, a parser was first implemented to decode the API signature in each line. (See reference...) Figure 3 The parser divides it into several attributes: Class description = "com.android.server.backup.PermissionBackupHelper", Method name = "getBackupPayload", Parameter type = "java.lang.String", Return type = "ArrayList <byte>The restriction level is set to "blocked". Based on these attributes other than the restriction level, corresponding entities e that display the same attributes in the dependency graph can be searched and identified. If they exist, the restriction level is assigned to the corresponding e, i.e., e.restrictlevel = "blocked". In this way, the restriction level of non-SDK entities can be marked to update the original dependency graph G. Finally, DepFCD outputs the dependency surface (G). F ), updated G U Updated G D , as well as entity attributes with intrusive operations and restriction levels.

[0063] All relevant content of each step involved in the aforementioned embodiments of the coupling surface model construction and identification method between upstream and downstream software systems can be referenced to the functional description of the corresponding functional module of the coupling surface identification system between upstream and downstream software systems in the embodiments of the present invention, and will not be repeated here.

[0064] The module division in this embodiment of the invention is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of the invention can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0065] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0067] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0068] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0069] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.< / byte>

Claims

1. A method for modeling coupling surfaces between upstream and downstream software systems, characterized in that, include: A dependency graph model for upstream and downstream projects, where vertices represent entities and edges represent dependencies; Intrusive modifications made by downstream projects to upstream entities and entity ownership are represented as attribute information in a graph model; The access restriction levels of upstream and downstream project entities are represented as attribute information in the graph model; Textual conflicts arising when a downstream project merges a new version of an upstream project are represented as supplementary information in a graph model; Based on the project code and commit history, the coupling surface between the downstream project and the upstream project is obtained, including: The source code of each downstream project coupled with different versions of the upstream project is converted into an abstract syntax tree, and the entity and dependency information in the project source code is extracted using the abstract syntax tree. Obtain the owner of each commit in the commit history of each version of the upstream and downstream projects, and obtain the ownership information of each entity modified in each commit in the commit history based on the entity attribute information in the project's source code and the entity information modified in each commit in the commit history. Based on the commit composition corresponding to each entity, it is determined whether the upstream entity has undergone intrusive modifications or is an outdated entity that has been abandoned by the upstream, thereby classifying upstream entities into three categories: active upstream entities. Intrusive modification of upstream entities and outdated upstream entities that have been abandoned by upstream entities. ; Active upstream entities These are entities created upstream that remain unchanged downstream; upstream entities are intrusively modified. These are upstream entities that are directly modified by downstream entities; Based on the restrictions on non-SDK interfaces proposed by upstream Android, the dependency restriction level information of the entities is obtained, including: For Android operating system projects, after cloning the code repository to the local machine, execute the command "m out / soong / hiddenapi / hiddenapi -flags.csv" in the local repository to obtain the access restriction level of the project's entities, and mark the restriction level of the entities according to the entity's attribute information to obtain the project's restriction level dependencies; Based on the project code and commit history, the coupling surface between the downstream project and the upstream project is obtained, including: Based on the ownership information and commit composition of each entity, the ownership of the entities connected by the dependency edges in the entity dependency graph of the downstream software system is determined. If a dependency edge connects an extended entity and an upstream entity, it is determined that the edge is on the coupling surface, thus obtaining the coupling surface subgraph model of the downstream project coupling the upstream project.

2. The coupling surface modeling method between upstream and downstream software systems according to claim 1, characterized in that, Based on the coupling surface information, and considering the occurrence of merging conflicts, including: When a text merging conflict exists, obtain the specific entity corresponding to the conflict and focus on the relationship between the entity and its dependencies on the coupling surface and the entity that caused the text conflict.

3. A method for identifying coupling surfaces between upstream and downstream software systems, characterized in that, include: Obtain the entity dependency graph between upstream and downstream projects; Based on the version information and commit history in the project repository, detect the owner of entities in downstream projects; Based on the commit information of the constituent entities, identify the operations that cause intrusive modifications to the entities; Based on the project's restriction level information and code entity matching, identify the restriction level of each entity in the dependency graph; According to the dependency graph G of downstream projects D Downstream project submission history The corresponding upstream version's commit history Commit history of older upstream versions The set of submissions associated with entity e The identification of entity ownership includes: Therefore, according to Ultimately, the entity's ownership is determined; The coupling surface diagram between the upstream and downstream software systems is obtained in the following way: Dependencies were detected using entity ownership information. It belongs to the downstream dependency graph. A subgraph where each edge in the coupling surface between upstream and downstream software systems connects an extending entity and an upstream entity, i.e. Each edge in the representation All should meet one of the following conditions: 。 4. The coupling surface identification method between upstream and downstream software systems according to claim 3, characterized in that, The project to be extracted is a software project written in Python, a dynamically typed language. The ENRE tool was used to extract project code entities and dependencies, the git blame command was used to trace the project's commit history, and the Refactor-Miner tool was used to identify code refactoring operations.

Images