METHOD BOOK RECOMMANDING MOVEMETHODS USING OBJECTS AND TECHNIQUE

Transcription

1 METHOD BOOK RECOMMANDING MOVEMETHODS USING OBJECTS AND TECHNIQUE SOUNDAR.S Department of Computer Science and Engineering Sona College of Technology Salem, India Abstract Software refactoring is a collection of reengineering activities that aims to prove the software quality. Refactoring is widely used in agile software processes to increase software quality after a significant software development or evolution. It is the belief that refactoring improves quality factors such as understandability, flexibility, and reusability. However, there is limited empirical evidence to support such assumptions. The aim of this study is to confirm such claims using a hierarchal quality model. We study the effect of software refactoring on software quality. We provide details of our findings as heuristics that can help software developers make more informed decisions about what refactoring to perform in regard to improve a particular quality factor. We validate the proposed heuristics in an empirical setting on two open-source systems. We found that the majority of refactoring heuristics do improve quality; however some heuristics do not have a positive impact on all software quality factors. In addition, we found that the impact analysis of refactoring divides software measures into two categories: high and low impacted measures. These categories help in the endeavor to know the best measures that can be used to identify refactoring candidates. We validated our findings on two open-source systems. Eclipse and Struts. For both systems, we found consistency between the heuristics and the actual refactoring. Keywords refactoring; relational topic model; empirical studies I. INTRODUCTION A. Software Engineering Software engineering is a field of Computer science, for designing and writing programs for computers or other electronic devices. A software engineer writes software using methods that make it better quality. Better quality software is easier to use, and the code is easier to understand, to maintain, and to add new features. Becoming a software engineer requires university level classes and practice writing code. Software engineering can be very difficult work. Software engineering is often done as part of a team. Software engineering is the study to develop and application of engineering to the design, development, and maintenance of software. B. Software Process Model The template is used to format your paper and style the text. All margins, column widths, line spaces, and text fonts SAMLINSON.E Department of Computer Science and Engineering Sona College of Technology Salem,India Samlinson@gmail.com are prescribed. For example, the head margin in this template measures proportionately more than is customary. This measurement and others are deliberate, using specifications that anticipate your paper as one part of the entire proceedings, and not as an independent document. C.Waterfall Model As the original software process model, it will be viewed as a first approximation of the activities needed in the software development process. Few versions provide feedback loops from each stage to the previous ones, but it is most used as a simple linear model.it is only suitable for projects in which all the customer requirements are known at the outset of the project, a rare condition, even for small scale projects. Also note that a working version of the system is only available late in the project. C. Incremental Process Model These models is sutiable to the basic waterfall model by adding incremental iteration processes. For example, each function of the system can be telled as a separate system and developed in accordance with the waterfall model. With this matter the system can be delivered to the customer incrementally beginning with the first function and later functions one by one in a different project schedule, with each function delivered initially as a separately operating function. A variation of this incremental theme, called the Rapid Application Development (RAD), It applies the software specification stage to the entire system but for software design and implementation stages the system is divided into group projects to enable development time to be scaled down to the range of two to three months. RAD may not be an an fixed choice if the customers and developers are not prepared for the rapid pace or if the system does not lend itself to the modularization required for assignment to teams. D. Software Testing After the software system it is coded into a deliverable product, testing strategies are used to function the system requirements. Testing strategies are designed to detect errors in the system. Debugging is the process to find the source of the errors for correction. Exhaustive testing is diffucult. meanwhile, no matter how much testing is done, it is never known with certainty if all bugs have been detected. Since testing process will cleared of detecting the presence of errors, the absence of all errors cannot be guaranteed by the 60

2 testing process. A high percentage of project resources will arrange on the testing phase. Testing is usually proceeds in two phases, first at the component level sometimes called unit testing. Unit testing is followed by integration testing in which increasingly larger groups of components are tested culminating in the total system. Unit testing is usually done by the developer and integration testing is done by an independent test group. Testing strategies for conventionally designed. Conventional software: unit testing will focuses on execution paths through component program logic with the goal of maximizing error detection by path coverage; meanwhile integration testing usually involves input and output values. Object-oriented software: unit testing is done with classes, whose definition not only internal program logic but also attributes and operations as well as conversation and collaboration. Operations must be tested in the context and class. These Two approaches to integration testing of objectoriented systems are common, thread-based and use-based testing. The thread-based approach tests the set of classes that respond to a given system input or event. Use-based testing begins with by testing classes that are relatively independent of all others and continues in stages with each stage defined by the addition of a layer of dependent classes until the entire system is encompassed. After unit testing and integration testing, the entire system will be tested in a group with the customer requirements. This final testing phase is usually called validation testing and includes alpha and beta tests. Alpha tests are performed at the developer site and beta tests will occur later at end of user sites. Final release of the software is scheduled after the beta tests are complete. E. Software Maintenance Software maintenance is an software engineering is modified of a software product after delivery to correct faults, to improve the performance or other attributes. The common perception of maintenance is that it nerly involves the fixing defects. However the one study indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions. This is modified by the users submitting problem reports that in reality are functionality enhancements to the system. More recent studies put the bugfixing proportion closer to 21%. Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969.In this period of twenty years, his research tells to the formulation of Lehman's Law. Key findings of his research include that maintenance is really evolutionary development and that maintenance decisions are overviewed by understanding what happens to systems of all time. Lehman explaines that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity. The key software maintenance issues are both managerial and technical. Key management issues are involved alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, and maintainability measurement. Software maintenance is a very broad activity that includes error correction, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable, mechanisms must be developed for evaluation, controlling and making modifications. So any work done to change the software after it is in operation is considered to be maintenance work. The purpose is to preserve the value of software over the time. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 20 years, whereas development may be 1-2 years. Typical formal definitions of software engineering are: "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software". "an engineering discipline that is concerned with all aspects of software production" "the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines" The term has been used less formally: as the informal contemporary term for the broad range of activities that were formerly called computer programming and systems analysis; as the broad term for all aspects of the practice of computer programming, as opposed to the theory of computer programming, which is called computer science; as the term embodying the advocacy of a specific approach to computer programming, one that urges that it be treated as an engineering discipline rather than an art or a craft, and advocates the codification of recommended practices This template, modified in MS Word 2007 and saved as a Word Document for the PC, provides authors with most of the formatting specifications needed for preparing electronic versions of their papers. All standard paper components have been specified for three reasons: (1) ease of use when formatting individual papers, (2) automatic compliance to electronic requirements that facilitate the concurrent or later production of electronic products, and (3) conformity of style throughout a conference proceedings. Margins, column widths, line spacing, and type styles are built-in; examples of the type styles are provided throughout this document and are identified in italic type, within parentheses, following the example. Some components, such as multi-leveled equations, graphics, and tables are not prescribed, although the various table text styles are provided. The formatter will need to create these components, incorporating the applicable criteria that follow. II. RELATED WORKS Software Module Clustering as a Multi Objective Search Problem, Kata Praditwong, Mark Harman and Xin Yao. Software module clustering is the problem of automatically organizing software units into modules to improve program structure. There has been a great deal of recent interest in 61

3 search based formulations of this problem, in which module boundaries are identified by automated search, guided by a fitness function that captures the twin objectives of high cohesion and low coupling in a single objective fitness function. An iterative process is executed, initialized by a randomly chosen population. The iterations are called generations and the members of the population are called chromosomes, because of their analogs in natural evolution. The process terminates when a population satisfies some predetermined condition (or a certain number of generations have been exceeded). At each iteration (that is each generation), some members of the population are recombined, crossing over elements of their chromosomes. Fractions of the offspring of this union are mutated and, from the offspring and the original population a selection process is used to determine the new population. Crucially, recombination and selection are guided by the fitness function; fitter chromosomes having a greater chance to be selected and recombined. There are many variations on this overall process, but the crucial ingredients are the way in which the fitness guides the search, the recombinatory and the population based nature of the process. In the application of any genetic algorithm to any problem there is a need for a tuning phase to determine the best choice of parameter values governing the likelihood of mutation, crossover and the determination of the size of the population. Conceptual Cohesion of Classes in Object Oriented Systems, S. Megha Chandrika, E. Suresh Babu and N. Srikanth. The new measure named the Conceptual cohesion of classes is the mechanisms used to measure textual coherence in cognitive psychology and computational linguistics, presents the principles and the technology that stand behind the C3 measure. A large case study on three open source software systems is presented which compares the new measure with an extensive set of existing metrics and uses them to construct models that predict software faults. Because the main theme of the declaring class variable is, it is used in all methods. So that the declared variables are found among all the methods. In this module we are going to apply the LCOM5 (Lack of cohesion in methods) formula. If the result is equal to one means, the class is less cohesive according to the structured information. Here we are going to retrieve the index terms based on that comments which are present in all the methods. Comments are useful information according to the software engineer. In concept oriented analysis we are taking the comments. Based on the comments we are going to measure the class is cohesive or not. In this module we are going to check the index terms among the comments which are present in all the comments. In this module we are going to apply the conceptual similarity formula. Based on the result we can say the class is cohesive or less cohesive according to concept oriented. In this module we are going to compare the two results. Based on the underlying information used to measure the cohesion of a class, one can distinguish structural metrics, semantic metrics, and information entropy-based metrics, slice based metrics, metrics based on data mining, and metrics for specific types of applications like knowledgebased, Aspect oriented, and distributed systems. Based on the results we can say that cohesion according to structure oriented and unstructured oriented. DECOR: A Method for the Specification and Detection of Code and Design Smells, Naouel Moha, Yann-Ga el Gu eh eneuc, Laurence Duchien, and Anne-Franc oise Le Meur. The originality of DETEX stems from the ability for software engineers to specify smells at a high-level of abstraction using a consistent vocabulary and domain-specific language for automatically generating detection algorithms. Using DETEX, we specify four well-known design smells: the antipatterns Blob, Functional Decomposition, Spaghetti Code, and Swiss Army Knife, and their 15 underlying code smells, and we automatically generate their detection algorithms. DETEX is original because the detection algorithms are not ad hoc but generated using a DSL obtained from an in-depth domain analysis of smells. A DSL benefits the domain experts, engineers, and quality experts because they can specify and modify manually the detection rules using highlevel abstractions pertaining to their domain, taking into account the context of the analyzed systems. The context corresponds to all information related to the characteristics of the systems including types (prototype, system in development or maintenance, embedded system, etc.), design choices (related to design heuristics and principles), and coding standards. Therefore, as a first contribution, we propose DECOR, a method that subsumes all the steps necessary to define a detection technique. The method defines explicitly each step to build a detection technique. All steps of DECOR are partially instantiated by the previous approaches. However, he did not make explicit the processing of these specifications, which appears as a black box. III. EXISTING METHODOLOGY The refactoring task as a search problem in the space of alternative designs. The alternative designs are generated by applying a set of refactoring operations, e.g., push up field, and pull down method, collapse hierarchy while the search from the optimal design is guided by a quality evaluation function based on 11 object-oriented design metrics, metrics that reflect refactoring goals. Note that move method refactoring is not supported by this approach. The fine slicing is used to extract executable program slices from their surrounding code and encapsulate them in different methods. In particular, their approach automatically refractors methods in object-oriented frameworks by using weighted dependence graphs, whose edges are weighted based on the modification histories of the methods. Support refactoring at method level they (i) do not exploit textual information extracted from source code and (ii) are not aimed at removing Feature Envy bad smells. To the best of our knowledge, only three approaches exist in literature to automate move method refactoring However, an evaluation of the approach on real software systems has not been performed. To the best of our knowledge, only three approaches exist in literature to automate move method refactoring provide a metric-based visualization tool useful to identify, among others, Move Method refactoring opportunities. In particular, each method is analyzed to verify which are its structural relationships (i.e., method calls and attribute accesses) with the classes of the system. If there is a class having more dependencies with the method as compared to the class the method belongs to, a possible feature envy bad smell is identified. 62

4 Algorithm presents the proposed recommendation algorithm. Assume a system S with a method m implemented in a class C. For all class Ci S, the algorithm verifies whether m is more similar to the methods in Ci than to the methods in its original class C. In the positive cases, we insert Ci in a list T containing the candidate target classes to receive m. Finally, we search in T for the most suitable class to receive m. In case we find such a class C0, we make a recommendation to move m to C0 (This algorithm relies on two key functions: (a) similarity (m; C) that computes the average similarity between method m and the methods in a class C; and (b) best class (m; T) that receives a list of candidate classes T to receive m and returns the most suitable one. IV. A. Structural dependencies EXISTING SYSTEM In this module, textual and structural information is extracted from the source code. The textual information is represented by words in comments and identifiers in source code and is stored in the term-by-document matrix. The structural dependencies among methods (i.e., method calls stored in the calls interaction matrix and shared instance variables stored in the shared-data matrix). B. Original design matrix The original design, i.e., which methods are contained in each class of the system, stored in the original design matrix. The structural matrices are used to adjust the topic probability distribution taking into account structural relationships between methods, besides textual information. In particular, the calls-interaction matrix and the shared-data matrix represent the two main forms of interaction among the methods of a system, i.e., calls interaction and shared instance variables, while the aim of the original design matrix is to take into account the design decisions made by the developers. C. RTM model creation Providing RTM with the original design information enables it to suggest move method refactoring operations. The model derived by RTM is then used to compute friendships among methods based on both probabilistic distributions of latent topics and underlying structural dependencies. The friendship relationships among all the pairs of methods of the system are stored in the RTM similarity matrix. In the context of our approach two methods are considered to be friends if they share responsibilities, i.e., they operate on the same data structures or are related to the same features or concepts in the program. Such a definition suggests that methods that are good friends should be in the same class, since a class should be a crisp abstraction, handle a few clear responsibilities, or some similar guideline. D. Move method recommendations Methodbook performs static code analysis to verify if a set of preconditions ensuring the preservation of the system behavior post-refactoring are satisfied for the suggested envied class (e.g., Methodbook ensures that the envied class does not contain a method having the same signature as the method to be moved). If the preconditions are satisfied, the refactoring is suggested, otherwise the second class containing the higher percentage of top friends for the method under analysis becomes the new candidate envied class and thus, is object of the preconditions verification. E. Evaluation criteria The evaluations of the refactorings in this work are subjective and informal and that because software refactoring is inherently subjective. Third, the assumption in this work that evolution of code is caused mostly by refactoring, which may not be the case in real environments. In the future, we plan to conduct more studies on larger systems either controlled or in real environments to confirm our findings. V. CONCLUSION We assessed the effect of many refactoring activities on four software quality factors: reusability, flexibility, extendibility, and effectiveness. We found that not all refactoring activities improve quality factors and some deteriorate quality. We established the refactoring heuristics that can help developers in following a goal-oriented refactoring process, i.e., developers can use particular refactoring to improve particular quality. The heuristics from our research findings, which were confirmed in two empirical studies, revealed more detailed and useful information for developers than the refactoring definitions. These heuristics can be used to classify the refactoring based on the quality it improves. For example, we may reorganize refactoring based on Reusability to safe and unsafe. The safe refactoring improves reusability and the unsafe refactoring do not improve reusability. This organization makes developer more precautions whenever they carry out any refactoring according to Fowler s catalog. These results provide more insight to the relationship between refactoring and software quality and evidence for developers to use these techniques more objectively and conveniently. REFERENCES [1] W. Stevens, G. Myers, and L. Constantine, Structured Design, IBM Systems J., vol. 13, no. 2, pp ,

5 [2] R. Pressman, Software Engineering: A Practitioner s Approach. Third ed., McGraw-Hill, [3] I. Sommerville, Software Engineering. sixth ed., Addison-Wesley, [4] V.R. Basili, L. Briand, and W.L. Melo, A Validation of Object- Oriented Design Metrics as Quality Indicators, IEEE Trans. Software Eng., vol. 22, no. 10, pp , Oct [5] A.B. Binkley and S.R. Schach, Validation of the Coupling Dependency Metric as a Predictor of Run-Time Failures and Maintenance Measures, Proc. 20th Int l Conf. Software Eng., pp , [6] A. Marcus, D. Poshyvanyk, and R. Ferenc, Using the Conceptual Cohesion of Classes for Fault Prediction in Object-Oriented Systems, IEEE Trans. Software Eng., vol. 34, no. 2, pp , Mar./ Apr [7] W.J. Brown, R.C. Malveau, W.H. Brown, H.W.McCormick III, and T.J. Mowbray, Anti Patterns: Refactoring Software, Architectures, and Projects in Crisis. first ed., John Wiley & Sons, [8] M. Fowler, Refactoring: Improving the Design of Existing Code. Addison- Wesley, [9] N. Tsantalis and A. Chatzigeorgiou, Identification of Move Method Refactoring Opportunities, IEEE Trans. Software Eng., vol. 35, no. 3, pp , May/June [10] J. Chang and D.M. Blei, Hierarchical Relational Models for Document Networks, Annals of Applied Statistics, vol. 4,