Evaluation of Code Smells Detection Using Meta-heuristics

3547 words (14 pages) Essay

27th Mar 2018 Computer Science Reference this

Tags:

Disclaimer: This work has been submitted by a university student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

Evaluation of code smells detection using Meta-heuristics Optimization algorithm

  • Ragulraja.M

 

Abstract-The development of software systems over many years leads to needless complexity and inflexibility in design which leads to a large amount of effort for enhancements and maintenance. To take code smells detection as a distributed optimization problem. The intention is that to aggregates different methods in parallel way to achieve a common goal detection of code smells. To this conclusion, it utilized Parallel Evolutionary algorithms (P-EA) where numerous evolutionary algorithms with adaptation are executed in parallel cooperative manner, to find unanimity between detection of code smells. An experimental results to compare the execution of our cooperative P-EA method with random search, two genetic based approaches and two bad designs detection techniques are found to provide the statistical measure of results witness to support the claim that cooperative P-EA is more economic and potential than the art detection approaches based on benchmark of open source systems, whereas the results are generated in terms of precision and recall incurred on various code smells types. In this approach should corroborate on an extra code smells types with the objective of resolve the common applicability of our methodology.

Keywords-Parallel Evolutionary Algorithm, Software Metrics, Code smells, Software Quality Engineering.

I.INTRODUCTION

Software maintenance projects are very costly. The total maintenance costs of Software project are estimated to 40%-70% of the total cost of the lifecycle of the project consequently, reducing the effort spent on maintenance can be seen as a natural way of reducing the overall costs of a software project. This is one of the main reasons for the recent interest in concepts such as refactoring and code smells. Hence, researchers have proposed several approaches to reduce defects in software .Suggested solutions include improvement of clarity in software design, effective use of process and product metrics, achievement of extensibility and adaptability in the development process. The research focusing on the study of bad software designs also called bad smells or code smells. To avoid these codes smells developers to understand the structure of source code.

The large systems of existing work in bad smells or code smells detection relies on declarative rule specification. In these specifications, rules are manually constructed to identify symptoms that can be used for categorization code smells with object oriented metrics information. Each code smell, rules are defined in the form of metrics combinations.

Many studies reported that manual categorization with declarative rule specification can be large. These need a threshold value to specify the code smells.

Further problem is that translation from symptoms to rules is not obvious because there is no unanimity symptom based description of bad smells. When unanimity occurs, the correlation of symptoms could be consociated with code smells types, it leads to precise identification of code smells types.

To handle these problems, we plan to extend an approach based on use of genetic programming to provide detection rules from the examples of code smells detection with metric combinations. However, the quality of the rules depends on the behavioral aspects of code smells, and it is not easy to confirm that coverage also because there is still some precariousness involves in detected code smells due to the difficulty to evaluate the coverage of the base of code smell examples.

In another past work, we proposed technique based on an artificial immune system metaphor to detect code smells by deviation with well designed systems. Thus, we believe in that an effective method will be to merge with detection algorithms to discover consensus when detecting code smells.

We intend to provide code smells detection as a distributed optimization problem.The implementation of our approach can be established by combining Optimization process in parallel manner to encounter consensus involving detection of code smells.

II. RELATED WORKS:

There are various studies that have mainly based on the code smells detection in software engineering using different methods. These methodologies range from fully automatic detection to direct manual inspection. However,there is no work that focuses on merging various detection algorithms to find unanimity when identifying code smells.

In this work, the classification existing approach for detection of code smells into various broad categories: symptom based approaches, manual approaches, metric based approaches, search based approaches and cooperative based approaches.

2.1 Manual approaches:

The software maintainers should manually inspect the program to detect existing code anomalies. In addition, they mentioned particular refactoring‟s for each code smells type. The technique is to create a set of “reading techniques” which help a reviewer to “read” a design artifact for calculating related information. The demerits of existing manual approaches is that they are finally a human centric process which involves a great human effort and strong analysis and interpretation attempt from software maintainers to find design fragments that are related to code smells.Furthermore, these methods are time consuming, error prone and focus on programs in their contexts. Another significant issue is that locating code smells manually has been prescribed as more a human intuition than an accurate science.

2.2 Metric based approaches:

The “detection strategy”mechanism for formulating metric based rules for finding deviations from well design code. Detection strategies permits to maintainer to directly find classes or methods subjected by a particular design smells. These detection strategies for capturing about ten important flaws of object oriented design found in literature. It is accomplished by evaluating design quality of an object oriented system via quantifying deviations from good design heuristics and principles by mapping these design defects to class level metrics such as complexity, coupling and cohesion by defining rules. Unfortunately, multi metrics neither encapsulate metrics in a more abstract construct,nor do they permit a negotiable combination of metrics.

In common, the effectiveness of combining metric or threshold is not clear, that is for each code smell, rules that are declared in terms of metric combinations need an important calibration effort to find the fixing of threshold values for each metric.

2.3 Search based approaches:

This approach is divined by contributions in the domain of search based software engineering.

SBSE uses search based approaches to resolve optimizations problems in software engineering.

Once the task is consider as a search problem, several search algorithms can be employed to solve that problem. Another approach is based on search based techniques, for the automatic identification of potential code smells in code. The detection focused on thenotion that more code deviates from good codes, the more likely it is bad. In another work, detections rule will be produced and is described as a combination of metrics or thresholds that better similar to known an examples of bad smells. Then, the correction solutions, a combination of refactoring operations, should reduce the number of bad smells detected using the detection rules.

2.4 Cooperative based approaches:

Some cooperative approaches to reference software engineering problems have been proposed recently, in this program and test cases co-evolve, regulating each other with the aim of fixing the maximum number of bugs in the programs. The objective is to improve the effectiveness of obtained test cases by evaluating their capabilities to avoid mutants.The P-EA proposal is vary from existing coevolutionary approaches, this proposal based on two populations that are referencing the same problem from various perspectives. Finally, the genetic based approaches are executed in parallel in our P-EA framework.

III. PROPOSED SCHEME

In this paper, we suggested a new search based approach for detection of code smells. In this approach a parallel metaheuristic optimization algorithm adaptation, two genetic populations are involves simultaneously with the target of each depending on the current population of other in a parallel cooperative manner. Both populations are generated, on the similar open source systems to evaluate, and the solutions are punished based on the intersection between the results of two populations are found. We extend our approach to various code smells types in order to resolve about common applicability ofcooperative parallel search based software engineering. Moreover, in this work we not only focus on the detection of code smells but also concentrate automated the correction of code smells.

Furthermore, in this paper we consider the essential need of code smells during the detection procedure using existing code changes, classes and coupling complexity. Hence, the detected code smells will be ranked based on the severity score and also an important score. We will measure also the use of more than two algorithms executed in parallel manner as a part our work to generate results of more accuracy than art detection approach. The negative impact on the code smells can be removed by applying more than two algorithms in cooperative manner it‟s difficult to find the consensus between the code smells. The research work will direct our approach to several software engineering problems such as software testing and quality assurance.

IV. PROPOSED ARCHITECTURE

Fig 1:system architecture

1. Metrics Evaluation

2. Evolutionary Algorithms

3. Code Smell Detection

4.1 METRICS EVALUATION

4.1.1 CK METRIC SUITE

Chidember and kemerer proposed a six metric suite used for analyzing the proposed variable. The six metric suite are:

1. Weighted Method Per Class(WMC):

Consider a class C1 with methods M1….Mn that are included in class. Let C1,C2…Cn be the sum of complexity.

WMC=Σ M

2. Depth Of Inheritance(DIT):

The maximum length from the node to the root of the tree.

3. Number Of Children(NOC):

Number of immediate subclasses subordinated to a class in the class hierarchy.

4. Coupling Between Objects(CBO):

It is a count of the number of other classes to which it is coupled.

5. Response For a Class (RFC)

It is the number of methods of the class plus the number of methods called by any of those methods.

4.1.2 Lack Of Cohesion of Methods (LCOM) Measure the dissimilarity of methods in a class via instanced variables.

4.2 EVOLUTIONARY ALGORITHMS

The fundamental think of both algorithms is to explore the search space by devising a population of candidate solutions, also called individuals, germinate towards a “good” solution of a unique problem. To measure the solutions, the fitness function in both algorithms has two components. For the first component of the fitness function, GP evaluates the detection rules based on the coverage of code-smells examples. In GP, a solution is combined of terminals and functions. Hence, while applying GP to clear particular problem, they should be carefully collected and fashioned to fulfil the requirements of the current problem. Afterwards, evaluating large parameters concerned to the code-smells detection problem, the terminal set and the function set are recognized as follows. The terminals fit to different quality metrics with their threshold values (constant values). The functions that can be used between these metrics are Union (OR) and Intersection (AND).

The second algorithm run in parallel is genetic algorithm that generates detectors from welldesigned code examples. For GA, detectors defend generated artificial code fragments dignified by code elements. Thus, detectors are mentioned as a vector where each dimension is a code element. We defend these elements as sets of predicates. All predicate type represents to a construct type of an objectoriented system. Then, a set of best solutions are collected from P-EA algorithms in each iteration, Bothalgorithms interact with one other victimizing the second component of the fitness function called intersection function.

4.3 CODE SMELLS DETECTION

Code smells are design flaws that can be solved by refactoring‟s. They are considered as flags to the developer that some parts of the design may be inappropriate and that it can be improved. For the purpose of this work, we discuss a few representative code smells. There are a lot of code smells mentioned in the development of this work. A thorough catalog of code smells can be found in Fowler’s refactoring book. As this work focuses on program analysis, code smells discussed in this work include those that require analyses. Though this work develops only a subset of the code smells, it provides some grounds which can be adapted to other types of code smells.

The set of best solutions from each algorithm is stored and a new population of individuals is generated by repetitively choosing pairs of parent individuals from population p and employing the crossover operator to them. We admit both the parent and child variants in the new population pop. Then, we apply the mutation operator, with a probability score, for both parent and child to assure the solution diversity; this produces the population for the next generation. While applying change operators, no individuals are transformed between the parallel GA/GP. Both algorithms exit when the termination criterion is met, and issue the best set of rules and detectors. At last, developers can use the best rules and detectors to find code-smells on new system to evaluate.

V. EXPERIMENTAL RESULTS

Fig 2: The impact of the nmber of code smell example on detection results

Fig 3: Average execution time comparison on the different system.

VI. THREATS TO VALIDITY:

Conclusion validity related with the statistical relationship between the treatment and outcome. The Wilcoxon rank sum test was used with a 95 percent confidence level to test its important differences exist between the measurements for different treatments. This test makes no supposition that the data is normally distributed and is suitable for ordinal data, so we can be assured that the statistical relationships observed are significant. The comparison with other techniques not based on heuristic search; consider the parameters obtained with the tools. This can be regarded as a threat that can be addressed in the future by developing the impact of various parameters on the quality of results of DÉCOR and JDeodorant.

Internal validity is related with the casual relationship between the treatment and outcome. To consider the internal threats to validity in the utilization of stochastic algorithms since this experimental work based on 51 independent simulation runs for each problem instance and the obtained results are statistically analyzed by using the Wilcoxon rank sum test with a 95 percent fair comparison between CPU times.

VII. CONCLUSION AND FUTURE WORK

In this approach a parallel metaheuristic optimization algorithm adaptation, two genetic populations are involves simultaneously with the target of each depending on the current population of other in a parallel cooperative manner. Both populations are generated, on the similar open source systems to evaluate, and the solutions are punished based on the intersection between the results of two populations are found.Moreover, in this work we not only focus on the detection of code smells but also concentrate automated the correction of code smells.Furthermore, in this paper we consider the essential need of code smells during the detection procedure using existing code changes, classes and coupling complexity. Hence, the detected code smells will be ranked based on the severity score and also an important score. We will measure also the use of more than two algorithms executed in parallel manner as a part our work to generate results of more accuracy than art detection approach. Future work should corroborate our method with remaining code smell types with the objective conclude about the common applicability of our methodology. We will assess also the use of more than the algorithm accomplish simultaneously as a part of our rest of our future work. Another future issue direction attached to our approach is to adapt our cooperative parallel evolutionary approach to various software engineering problems such as software testing and the following release problem.

VIII. REFERENCES

1) WaelKessentini,MarouaneKessentini,HouariSahrao ui, Slim Bechikh:”A Cooperative Parallel Search-Based Software Engineering Approach for Code-Smells Detection” IEEE Trans. Softw. Eng.,vol. 40, no. 9, Sep 2014.

2) N. Moha, Y. G. Gu_eh_eneuc, L. Duchien, and A. F. Le Meur, “DECOR: A method for the specification and detection of code and design smells,” IEEE Trans. Softw. Eng., vol. 36, no. 1, pp. 20–36, Jan./Feb. 2010.

3) Chidamber, S., Kemerer, C.: „A metrics suite for object oriented design‟,IEEE Trans. Softw. Eng., 1994, 20, (6), pp. 476–493. 

4) Mark Harman and AfshinMansouri.:”Search Based Software Engineering: Introduction to the Special Issue of the IEEE Transactions on Software Engineering”,” IEEE Trans. Softw. Eng., vol. 36, no. 6,Nov./Dec. 2010. 

5) F. Khomh, S. Vaucher, Y. G. Gu_eh_eneuc, and H.A. Sahraoui, “A bayesian approach for the detection of code and design smells,” in Proc. Int. Conf. Quality Softw., 2009, 305–314.

6) R. Marinescu, “Detection strategies: Metrics-based rules for detecting design flaws,” in Proc. 20th Int. Conf. Softw. Maintenance, 2004, pp. 350–359.

7) M. Kessentini, W. Kessentini, H. A. Sahraoui, M. Boukadoum, and A. Ouni, “Design defects detection and correction by example,” in Proc. IEEE 19th Int. Conf. Program Comprehension, 2011, pp. 81–90.

8) T. Burczy_nskia, W. Ku_sa, A. D»ugosza, and P. Oranteka,“Optimization and defect identification using distributed evolutionary algorithms,” Eng. Appl. Artif. Intell., vol. 4, no. 17, pp. 337–344, 2004.

9) A. Ouni, M. Kessentini, H. A. Sahraoui, and M. Boukadoum, “Maintainability defects detection and correction: A multiobjective approach,” Autom. Softw. Eng., vol. 20, no. 1, pp. 47–79, 2012.

10) O. Ciupke, “Automatic detection of design problems in objectoriented reengineering,” in Proc. Int. Conf. Technol. Object-OrientedLanguage Syst., 1999, pp. 18–32.

12) G. Travassos, F. Shull, M. Fredericks, and V. R. Basili, “Detecting defects in object-oriented designs: Using reading techniques to increase software quality,” in Proc. Int. conf. Object-Oriented Program.,Syst., Languages, Appl., 1999, pp. 47–56.

13) M. Harman, S. A. Mansouri, and Y. Zhang, “Search-based software engineering: Trends, techniques and applications,” ACM Comput. Surv., vol. 45, no. 1, 61 pages.

14) A. Arcuri, X. Yao, “A novel co-evolutionary approach to automatic software bug fixing,” in Proc. IEEE Congr. Evol. Comput., 2008, pp. 162–168.

15) M. J. Munro, “Product metrics for automatic identification of „Bad Smell‟ design problems in Java source-code,” in Proc. IEEE 11th Int. Softw. Metrics Symp., 2005, pp. 15–15. 

16) W. Banzhaf, “Genotype-phenotype-mapping and neutral variation: A case study in genetic programming,” in Proc. Int. Conf. Parallel Problem Solving from Nature, 1994, pp. 322–332.

17) W. H. Kruskal and W. A. Wallis, “Use of ranks in one-criterion variance analysis,” J. Amer. Statist. Assoc., vol. 47, no. 260, pp. 583–621, 1952.

18) W. J. Brown, R. C. Malveau, W. H. Brown, and T. J. Mowbray, “Anti Patterns: Refactoring Software, Architectures, and Projects in Crisis”. Hoboken, NJ, USA: Wiley, 1998.

19) N. Fenton and S. L. Pfleeger, “Software Metrics: A Rigorous and Practical Approach”. Int. Thomson Comput. Press, London, UK, 1997. 

20) Emerson Murphy-Hill, Chris Parnin, and Andrew P. Black” How We Refactor, and How We Know It”,IEEE Trans. Softw. Eng.,vol. 38,no. 1, Jan./Feb. 2012.

21) M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, “Refactoring: Improving the Design of Existing Code”. Reading, MA,USA: Addison Wesley, 1999.

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on the UKDiss.com website then please: