Software refactoring is an important process in software development. During software refactoring, code smell is a popular research topic that refers to design or implementation flaws in the software. Large class is one of the most concerning code smells in software refactoring. Detecting and refactoring such problem has a profound impact on software quality. In past years, software metrics and clustering techniques have commonly been used for the large class detection. However, deep-learning-based approaches have also received considerable attention in recent studies. In this study, we apply graph neural networks (GNNs), an important division of deep learning, to address the problem of large class detection. First, to support the extensive data requirements of the deep learning task, we apply a semiautomatic approach to generate a substantial number of data samples. Next, we design a new type of directed heterogeneous graph (DHG) as an input graph using the methods similarity matrix and software metrics. We construct an input graph for each class sample and make the graph classification with GNNs to identify the smelly classes. In our experiments, we apply three typical GNN model architectures for large class detection and compare the results with those of previous studies. The results show that the proposed approach can achieve more accurate and stable detection performance.

Code smells can be detected using tools such as a static analyzer that detects code smells based on source code metrics. Developers perform refactoring activities based on the result of such detection tools to improve source code quality. However, such an approach can be considered as reactive refactoring, i.e., developers react to code smells after they occur. This means that developers first suffer the effects of low-quality source code before they start solving code smells. In this study, we focus on proactive refactoring, i.e., refactoring source code before it becomes smelly. This approach would allow developers to maintain source code quality without having to suffer the impact of code smells. To support the proactive refactoring process, we propose a technique to detect decaying modules, which are non-smelly modules that are about to become smelly. We present empirical studies on open source projects with the aim of studying the characteristics of decaying modules. Additionally, to facilitate developers in the refactoring planning process, we perform a study on using a machine learning technique to predict decaying modules and report a factor that contributes most to the performance of the model under consideration.

By focusing on the recent swing to the centralized approach by the software defined network (SDN), this paper presents a novel network architecture for refactoring the current distributed Internet protocol (IP) by not only utilizing the SDN itself but also implementing its cooperation with the optical transport layer. The first IP refactoring is for flexible network topology reconfiguration: the global routing and explicit routing functions are transferred from the distributed routers to the centralized SDN. The second IP refactoring is for cost-efficient maintenance migration: we introduce a resource portable IP router that can behave as a shared backup router by cooperating with the optical transport path switching. Extensive evaluations show that our architecture makes the current IP network easier to configure and more scalable. We also validate the feasibility of our proposal.

An important step for improving software analyzability is applying refactorings during the maintenance phase to remove bad smells, especially the long method bad smell. Long method bad smell occurs most frequently and is a root cause of other bad smells. However, no research has proposed an approach to repeating refactoring identification, suggestion, and application until all long method bad smells have been removed completely without reducing software analyzability. This paper proposes an effective approach to identifying refactoring opportunities and suggesting an effective refactoring set for complete removal of long method bad smell without reducing code analyzability. This approach, called the long method remover or LMR, uses refactoring enabling conditions based on program analysis and code metrics to identify four refactoring techniques and uses a technique embedded in JDeodorant to identify extract method. For effective refactoring set suggestion, LMR uses two criteria: code analyzability level and the number of statements impacted by the refactorings. LMR also uses side effect analysis to ensure behavior preservation. To evaluate LMR, we apply it to the core package of a real world java application. Our evaluation criteria are 1) the preservation of code functionality, 2) the removal rate of long method characteristics, and 3) the improvement on analyzability. The result showed that the methods that apply suggested refactoring sets can completely remove long method bad smell, still have behavior preservation, and have not decreased analyzability. It is concluded that LMR meets the objectives in almost all classes. We also discussed the issues we found during evaluation as lesson learned.

Understanding which refactoring transformations were performed is in demand in modern software constructions. Traditionally, many researchers have been tackling understanding code changes with history data derived from version control systems. In those studies, problems of the traditional approach are pointed out, such as entanglement of multiple changes. To alleviate the problems, operation histories on IDEs' code editors are available as a new source of software evolution data nowadays. By replaying such histories, we can investigate past code changes in a fine-grained level. However, the prior studies did not provide enough evidence of their effectiveness for detecting refactoring transformations. This paper describes an experiment in which participants detect refactoring transformations performed by other participants after investigating the code changes with an operation-replay tool and diff tools. The results show that both approaches have their respective factors that pose misunderstanding and overlooking of refactoring transformations. Two negative factors on divided operations and generated compound operations were observed in the operation-based approach, whereas all the negative factors resulted from three problems on tangling, shadowing, and out-of-order of code changes in the difference-based approach. This paper also shows seven concrete examples of participants' mistakes in both approaches. These findings give us hints for improving existing tools for understanding code changes and detecting refactoring transformations.

Workflow nets (WF-nets for short) are a mathematical model of real world workflows. A WF-net is often updated in accordance with the change of real world. This may cause places that are redundant from the viewpoint of the behavior. Such places are called implicit. We first proposed a necessary and sufficient condition to find implicit places. Then we proved that removing of implicit places is a reduction operation which forms branching bisimilarity. We also constructed an algorithm for the reduction. Next, we applied the proposed reduction operation to WF-net refactoring. Then we showed the usefulness of the proposed refactoring with two examples.

Although code clones (i.e. code fragments that have similar or identical code fragments in the source code) are regarded as a factor that increases the complexity of software maintenance, tools for supporting clone refactoring (i.e. merging a set of code clones into a single method or function) are not commonly used. To promote the development of refactoring tools that can be more widely utilized, we present an investigation of clone refactoring carried out in the development of open source software systems. In the investigation, we identified the most frequently used refactoring patterns and discovered how merged code clone token sequences and differences in token sequence lengths vary for each refactoring pattern.

A workflow net (WF-net for short) is a Petri net which represents a workflow. There are two important subclasses of WF-nets: extended free-choice (EFC for short) and well-structured (WS for short). It is known that most actual workflows can be modeled as EFC WF-nets; Acyclic WS is a subclass of acyclic EFC but has more analysis methods. An acyclic EFC WF-net may be transformed to an acyclic WS WF-net without changing the external behavior of the net. We name such a transformation Acyclic EFC WF-net refactoring. We give a formal definition of acyclic EFC WF-net refactoring problem. We also give a necessary condition and a sufficient condition for solving the problem. Those conditions can be checked in polynomial time. These result in the enhancement of the analysis power of acyclic EFC WF-nets.

Change history in project revisions provides helpful information on handling bugs. Existing studies on predicting bugs mainly focus on resulting bug patterns, not these change patterns. When a code hunk is copied onto several files, the set of original and copied hunks often need to be consistently maintained. We assume that it is a normal state when all of hunks survive or die in a specific revision. When partial change occurs on some duplicated hunks, they are regarded as suspicious hunks. Based on these assumptions, suspicious cases can be predicted and the project's developers can be alerted. In this paper, we propose a practical approach to detect various change smells based on revision history and code hunk tracking. The change smells are suspicious change patterns that can result in potential bugs, such as partial death of hunks, missed refactoring or fix, backward or late change. To detect these change smells, three kinds of hunks – add, delete, and modify – are tracked and analyzed by an automated tool. Several visualized graphs for each type have been suggested to improve the applicability of the proposed technique. We also conducted experiments on large-scale open projects. The case study results show the applicability of the proposed approach.

This paper proposes a technique for detecting the occurrences of refactoring from source code revisions. In a real software development process, a refactoring operation may sometimes be performed together with other modifications at the same revision. This means that detecting refactorings from the differences between two versions stored in a software version archive is not usually an easy process. In order to detect these impure refactorings, we model the detection within a graph search. Our technique considers a version of a program as a state and a refactoring as a transition between two states. It then searches for the path that approaches from the initial to the final state. To improve the efficiency of the search, we use the source code differences between the current and the final state for choosing the candidates of refactoring to be applied next and estimating the heuristic distance to the final state. Through case studies, we show that our approach is feasible to detect combinations of refactorings.

Refactoring is one of the promising techniques for improving program design by means of program transformation with preserving behavior, and is widely applied in practice. However, it is difficult for engineers to identify how and where to refactor programs, because proper knowledge and skills of a high order are required of them. In this paper, we propose the technique to instruct how and where to refactor a program by using a sequence of its modifications. We consider that the histories of program modifications reflect developers' intentions, and focusing on them allows us to provide suitable refactoring guides. Our technique can be automated by storing the correspondence of modification patterns to suitable refactoring operations. By implementing an automated supporting tool, we show its feasibility. The tool is implemented as a plug-in for Eclipse IDE. It selects refactoring operations by matching between a sequence of program modifications and modification patterns.

Refactoring is one of the promising techniques for improving software design by means of behavior-preserving structural transformation, and is widely taken into practice. In particular, it is frequently applied to design models represented with UML such as class diagrams. However, since UML design models includes multiple diagrams which are closely related from various views, to get behavior-preserving property, we should get the other types of design information and should handle with the propagation of the change on a diagram to the other diagrams. For example, to refactor a class diagram, we need behavioral information of methods included in the class and should also refactor diagrams which represent the behavior, such as state diagrams, activity diagrams. In this paper, we introduce refactoring on design models as transformations of a graph described by UML class diagram and action semantics. First, we define basic transformations of design models that preserve the behavior of designed software, and compose them into refactoring operations. We use Object Constraint Language (OCL) to specify when we can apply a refactoring operation. Furthermore we implement our technique on a graph transformation system AGG to support the automation of refactoring, together with evaluation mechanism of OCL expressions. Some illustrations are presented to show its effectiveness. The work is the first step to handle with refactoring on UML design models in integrated way.