Evaluation of Code Smells Detection Using Meta-heuristics

Evaluation of Code Smells Detection Using Meta-heuristics 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 ar e 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 Fowlers 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 result s 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.