scholarly journals God Class Refactoring Recommendation and Extraction Using Context based Grouping

Author(s):  
Tahmim Jeba ◽  
◽  
Tarek Mahmud ◽  
Pritom S. Akash ◽  
Nadia Nahar

Code smells are the indicators of the flaws in the design and development phases that decrease the maintainability and reusability of a system. A system with uneven distribution of responsibilities among the classes is generated by one of the most hazardous code smells called God Class. To address this threatening issue, an extract class refactoring technique is proposed that incorporates both cohesion and contextual aspects of a class. In this work, greater emphasis was provided on the code documentation to extract classes with higher contextual similarity. Firstly, the source code is analyzed to generate a set of cluster of extracted methods. Secondly, another set of clusters is generated by analyzing code documentation. Then, merging these two, a final cluster set is formed to extract the God Class. Finally, an automatic refactoring approach is also followed to build newly identified classes. Using two different metrics, a comparative result analysis is provided where it is shown that the cohesion among the classes is increased if the context is added in the refactoring process. Moreover, a manual inspection is conducted to ensure that the methods of the refactored classes are contextually organized. This recommendation of God Class extraction can significantly help the developers in minimizing the burden of refactoring on own their own and maintaining the software systems.

2021 ◽  
Vol 12 (1) ◽  
pp. 1-10
Author(s):  
Sami Ouali

Software Product Lines (SPLs) refer to some software engineering methods, tools and techniques for creating a collection of similar software systems from a shared set of software assets using a common means of production. This concept is recognized as a successful approach to reuse in software development. Its purpose is to reduce production costs by reusing existing features and managing the variability between the different products with respect of particular constraints. Software Product Line engineering is the production process in product lines and the development of a family of systems by reusing core assets. It exploits the commonalities between software products and preserves the ability to vary the functionalities and features between these products. The adopted strategy for building SPL can be a top-down or bottom-up. Depending from the selected strategy, it is possible to face an inappropriate implementation in the SPL Model or the derived products during this process. The code can contain code smells or code anomalies. Code smells are considered as problems in source code which can have an impact on the quality of the derived products of an SPL. The same problem can be present in many derived products from an SPL due to reuse or in the obtained product line when the bottom-up strategy is selected. A possible solution to this problem can be the refactoring which can improve the internal structure of source code without altering external behavior. This paper proposes an approach for building SPL from source code using the bottom-up strategy. Its purpose is to reduce code smells in the obtained SPL using refactoring source code. This approach proposes a possible solution using reverse engineering to obtain the feature model of the SPL.


Author(s):  
Tran Thanh Luong ◽  
Le My Canh

JavaScript has become more and more popular in recent years because its wealthy features as being dynamic, interpreted and object-oriented with first-class functions. Furthermore, JavaScript is designed with event-driven and I/O non-blocking model that boosts the performance of overall application especially in the case of Node.js. To take advantage of these characteristics, many design patterns that implement asynchronous programming for JavaScript were proposed. However, choosing a right pattern and implementing a good asynchronous source code is a challenge and thus easily lead into less robust application and low quality source code. Extended from our previous works on exception handling code smells in JavaScript and exception handling code smells in JavaScript asynchronous programming with promise, this research aims at studying the impact of three JavaScript asynchronous programming patterns on quality of source code and application.


2021 ◽  
Author(s):  
Aleksandar Kovačević ◽  
Jelena Slivka ◽  
Dragan Vidaković ◽  
Katarina-Glorija Grujić ◽  
Nikola Luburić ◽  
...  

<p>Code smells are structures in code that often have a negative impact on its quality. Manually detecting code smells is challenging and researchers proposed many automatic code smell detectors. Most of the studies propose detectors based on code metrics and heuristics. However, these studies have several limitations, including evaluating the detectors using small-scale case studies and an inconsistent experimental setting. Furthermore, heuristic-based detectors suffer from limitations that hinder their adoption in practice. Thus, researchers have recently started experimenting with machine learning (ML) based code smell detection. </p><p>This paper compares the performance of multiple ML-based code smell detection models against multiple traditionally employed metric-based heuristics for detection of God Class and Long Method code smells. We evaluate the effectiveness of different source code representations for machine learning: traditionally used code metrics and code embeddings (code2vec, code2seq, and CuBERT).<br></p><p>We perform our experiments on the large-scale, manually labeled MLCQ dataset. We consider the binary classification problem – we classify the code samples as smelly or non-smelly and use the F1-measure of the minority (smell) class as a measure of performance. In our experiments, the ML classifier trained using CuBERT source code embeddings achieved the best performance for both God Class (F-measure of 0.53) and Long Method detection (F-measure of 0.75). With the help of a domain expert, we perform the error analysis to discuss the advantages of the CuBERT approach.<br></p><p>This study is the first to evaluate the effectiveness of pre-trained neural source code embeddings for code smell detection to the best of our knowledge. A secondary contribution of our study is the systematic evaluation of the effectiveness of multiple heuristic-based approaches on the same large-scale, manually labeled MLCQ dataset.<br></p>


2020 ◽  
Author(s):  
Willian N. Oizumi ◽  
Alessandro F. Garcia

Design problems affect most software projects and make their maintenance expensive and impeditive. Thus, the identification of potential design problems in the source code – which is very often the only available and upto-date artifact in a project – becomes essential in long-living software systems. This identification task is challenging as the reification of design problems in the source code tend to be scattered through several code elements. However, stateof-the-art techniques do not provide enough information to effectively help developers in this task. In this work, we address this challenge by proposing a new technique to support developers in revealing design problems. This technique synthesizes information about potential design problems, which are materialized in the implementation under the form of syntactic and semantic anomaly agglomerations. Our evaluation shows that the proposed synthesis technique helps to reveal more than 1200 design problems across 7 industry-strength systems, with a median precision of 71% and a median recall of 78%. The relevance of our work has been widely recognized by the software engineering community through 2 awards and 7 publications in international and national venues.


Author(s):  
Manjula Peiris ◽  
James H. Hill

This chapter discusses how to adapt system execution traces to support analysis of software system performance properties, such as end-to-end response time, throughput, and service time. This is important because system execution traces contain complete snapshots of a systems execution—making them useful artifacts for analyzing software system performance properties. Unfortunately, if system execution traces do not contain the required properties, then analysis of performance properties is hard. In this chapter, the authors discuss: (1) what properties are required to analysis performance properties in a system execution trace; (2) different approaches for injecting the required properties into a system execution trace to support performance analysis; and (3) show, by example, the solution for one approach that does not require modifying the original source code of the system that produced the system execution.


2019 ◽  
pp. 649-662
Author(s):  
Ning Gui ◽  
Vincenzo De Florio ◽  
Chris Blondia

Autonomous Robots normally perform tasks in unstructured environments, with little or no continuous human guidance. This calls for context-aware, self-adaptive software systems. This paper aims at providing a flexible adaptive middleware platform to seamlessly integrate multiple adaptation logics during the run-time. To support such an approach, a reconfigurable middleware system “ACCADA” was designed to provide compositional adaptation. During the run-time, context knowledge is used to select the most appropriate adaptation modules so as to compose an adaptive system best-matching the current exogenous and endogenous conditions. Together with a structure modeler, this allows robotic applications' structure to be autonomously (re)-constructed and (re)-configured. This paper applies this model on a Lego NXT robot system. A remote NXT model is designed to wrap and expose native NXT devices into service components that can be managed during the run-time. A dynamic UI is implemented which can be changed and customized according to system conditions. Results show that the framework changes robot adaptation behavior during the run-time.


2013 ◽  
Vol 33 (2) ◽  
pp. 21-22
Author(s):  
Thomas Forster ◽  
Thorsten Keuler ◽  
Jens Knodel

2019 ◽  
Vol 214 ◽  
pp. 05001 ◽  
Author(s):  
Stefan-Gabriel Chitic ◽  
Ben Couturier ◽  
Marco Clemencic ◽  
Joel Closier

A continuous integration system is crucial to maintain the quality of the 6 millions lines of C++ and Python source code of the LHCb software in order to ensure consistent builds of the software as well as to run the unit and integration tests. Jenkins automation server is used for this purpose. It builds and tests around 100 configurations and produces in the order of 1500 built artifacts per day which are installed on the CVMFS file system or potentially on the developers’ machines. Faced with a large and growing number of configurations built every day, and in order to ease inter-operation between the continuous integration system and the developers, we decided to put in place a flexible messaging system. As soon as the built artifacts have been produced, the distributed system allows their deployment based on the priority of the configurations. We will describe the architecture of the new system, which is based on RabbitMQ messaging system (and the pika Python client library), and uses priority queues to start the LHCb software integration tests and to drive the installation of the nightly builds on the CVMFS file system. We will also show how the introduction of an event based system can help with the communication of results to developers.


Author(s):  
INGOLF KRÜGER ◽  
WOLFGANG PRENNINGER ◽  
ROBERT SANDNER ◽  
MANFRED BROY

The definition of a transparent software architecture is one of the key issues in the early development phases for complex distributed and reactive software systems. In this paper, we show how to derive an architecture systematically for systems with communication models based on broadcasting. Adequate graphical description techniques for capturing interaction requirements and logical component architectures for broadcasting systems are unavailable so far. We introduce an extension to UML's sequence diagrams to capture broadcasting scenarios. Furthermore, we present methodological steps for constructively deriving structural and behavioral aspects of the architecture under consideration from the captured scenarios.


Sign in / Sign up

Export Citation Format

Share Document