Code Smell as an Aspect of Software Maintainability - Term Paper Example

? Smell as an Aspect of Software Maintainability: the BIRT eclipse project Number Introduction Q1: A justification of the aspect of maintainability Code smells manifest flaws in design that have capacity to degrade code maintainability. Therefore, the presence of code smells seems to be an ideal maintainability assessment indicator. Developing strategies that to be used in assessment of maintainability, is very important, considering that significant cost and effort is used during maintenance. Existence of code smell has been suggested and an approach that can be used for maintainability evaluation. The presence of code smells is an indication that there are code quality issues like changeability and understandability which can introduce faults. Fowler and Beck (1999) in an informal approach describe twenty two code smells which they associated with strategies for refactoring to improve the design. Hence, code analyzing code smell opens up a possibility of integrating both improvement and assessment in the software maintenance process. Regardless, to have a code smell based maintainability evaluation there is a requirement to better understand the scope if their indicators, for instance have knowledge of their capability and also their limitation which reflect important software aspects for maintainability. Using this complementary approach can be utilized to address the factors not represented by code smell. In general this will aid in achieving more accurate and comprehensive maintainability evaluations. Past studies have investigated relationship between individual code smell and various maintain- ace characteristics like defects and change size but not much has been carried out regarding how well code smell can be used for maintainability assessments in general. Anda (2007) provides a report on a number of crucial aspects of maintainability which were extracted from expert judgment based evaluations for four medium size Java applications. Concluding that expert judgment and software measures were not opposing, but are complementary for the reason that they are both addressing different maintainability aspects is thus in order. This paper using project from eclipse project portal complement the finding from extraction of maintainability aspects important in the eyes of software maintainers. Based on these factors manifestation , identify which code smell or alternative analysis approach that can be applied to assess them and provide a general view of that capacity if current code smells definitions in overall system maintainability. There is a great deal of published product research, which are based on approaches that estimate the effort put in maintenance and the related evaluations of maintenance in assessments that are related in software engineering literature. Many of the maintenance approaches that are process centred use process related metrics or historical data to generate models of estimation. Hybrid approaches combine product and process related factors. BIRT API Test Reference Description the test spec, test framework & test cases setup and test plugins illustration Originator Harry G. Hsu 6 July, 2005 Version 1.1 Copyright Actuate Corp. Revision History Editor Description Hsu H.G. 21 July, 2005 Add some new features Wei Yu. 05 Feb., 2006 Update it according to current version The components of API Test should include two independent parts, interface classes and methods tests and extension points tests. The first part is supposed to provide functional checks on the behaviors of individual classes and methods therein. It should put an emphasis on the verification of whether the functionalities which are explicitly or implicitly described in the API SPEC are achieved and in addition, the behaviors which are not indicated in SPEC are not presented (side-effect free). The second part is supposed to verify whether the extension implementations are well loaded by the extendee, and how these extensions affect the outcomes of published APIs. The first part of test should have access to whatever has presented in the API doc, and therefore is labor-intensive, while the extension tests require more familiarities in the BIRT implementations. Q2: Reason for choosing to use the files in the index It has been suggested that Different code characteristics have affected maintainability. Earlier examples include lines of code (LOC) and complexity; some have attempted to merge them into a single value, referred to as maintainability index. Parameters of inheritance, cohesion and coupling have been suggested so as to cope with object oriented program analysis. Though such metrics may correlate with defects and effort, there lies a limitation for assessing the general maintainability of a system. A major limiting factor is that only the properties that can be automatically measured by using code are considered. Where else many important quality issues, like use of appropriate data structures and documentation that is meaningful are naturally semantic and cannot be analyzed automatically Anda (2007) reports that expert judgment and software metrics are complementary methods that address different maintainability factors. There are some important factors that have not been addressed by metrics are, component usage, choice of classes and names, Usage of components Adequate architecture design suitable to the problem domain. Code smell is a suboptimal choice of design that has the capacity to degrade different aspects of quality in coding like changeability and understand ability which can lead to introductions of faults. The process that was used to obtain maintainability aspects follows a chain of evidence after tasks like adopting an eclipse program into a new platform and addition of new functionalities required by users. Q3: A detailed explanation of how I obtained and collected the data These tasks conducted by different developers on the BIRT eclipse project repeatedly to provide 12 cases. Testing by different developers with control for level representations still underscored the same notion. Learning effects among applications are not a threat to validity on maintainability perception. As a matter of fact when different developers repeat a task on the same project actually facilitates contrasting maintainability across the project. Data analysis was done using cross case synthesis and coding methods. Cross case synthesis involves summarizing and identifying tendencies. Examples of codes are Size, data Base Queries and bad naming. Q4: A summery of the raw data Data Access Objects and Lack of Rules From the axial coding and cross case synthesis, thirteen maintainability factors arise, they include; Appropriate technical platform, coherent naming, design suited for problem domain, encapsulating, inheritance, libraries (proprietary) Simplicity, three layer architecture use of components , design consistence, Duplicate code initial defect and logic spread as shown below on Figure: 1 The last four columns of the table above show how programmers perceived each factor of the project. The coding mean the following M/N Neg; N developers talked about that aspect in the system and M number of them had a negative feedback and similarly M/N pos for positive feedback. The ones marked in NM; not mentioned for instance, considering the three layer architecture. Two having positive feedback and one negative, no developers mentioned this for the phase B evaluation hence the coding NM. Lastly for factors defines by Anda (2007) super script values show the degree of matching between developers’ impression and expert evaluation where 0 indicates no match, 1 indicates match and 2 for full match. By observing the references to maintainability aspects, it is possible to distinguish between simplicity, platform and consistency in design as the factors mostly mentioned by the all the developers. Most of the matching factors are all on the negative impression of the system, specifically design suited to the problem domain, technical platform and simplicity. In phase A and C there is a high degree of agreement in positive impression against Simplicity of the systems. While phase A displays the highest rate of disagreement between maintainers and expert judgment while D showed the highest degrees of agreement in both parties considering the project as fairly good (Mantyl, 2009). In Table 1 there is a potential limitation in that, comments are reported are negative and positive, while the magnitudes of each factor is not described. But when cross doing cross case comparison, evidence strength. Evidence strength is determined by the number of cases that support a statement. As such it is considered as an indicator if severity if a factor was mentioned by many or all developers who used that project as opposed to factors that were only mentioned by one developer. In this section of evaluation there will be a clear relating of maintainability factors to code smell, and for the factor which cannot be related to code smell there will be a discussion regarding which alternatives can be used to evaluate them. Appropriate technical platform is a factor that manifested in several ways across the project. In phase B it displayed in a form of a complex, proprietary java persistence frame work. Developers claim that a lot of time was spent trying to understand the mechanisms involved, specifically stating that many problem with regarding system maintenance can be related to implicit, undocumented requirements when a project is moved to a different environment, This is largely due to two restrictive interfaces used both being made under an assumption that identifiers for objects will always be integers. However new platform string type object may be required and Interfaces replacement in most cases is not possible because implementations are based on primitive types that instead of domain-entities. For Phase A and C, this factor was manifested in the lack of appropriate mechanisms of persistence, resulting to complex database queries embedded in java code. Q6: A discussion of what data summaries show about the current and future maintainability of Eclipse code Coherent naming reflects how accurately code vocabulary represents the domain and the facilitation between the domain, requirements and code. In phase C, similar situations took place at the method level. The Meaningfulness of the name of a code cannot be evaluated using code smells and may require semantic or manual inspection. Design that is suited to the problem domain is the selecting of a design which is adequate for the context the complexity of a system must be justifiable in regard to the chosen solution, and the maintenance staff should be competent enough to implement solutions that are in accordance with design principles. In phase B there is a counter example where a proprietary persistence library that is complex was used instead of using a generic one, which is better suited for small or medium sized information system. This relates to the general speculative smell. But this aspect of smell is very hard to evaluate using automated code analysis and expert judgment is needed. Regarding encapsulation experts concluded that small container classes were utilized to deliver more than one object as method outputs. Indicating that it introduced dependencies with potential problems regarding maintenance is therefore plausible. During phase A and C developers agree that there was an acceptable encapsulation, causing localized ripple effect. Code smells like data clumps are indicators of insufficient encapsulation, which can be manually inspected for completion. Situations That Were Described By the Developers Provided a clear cut outlook on how difficult it is to use code smell definitions for analysis of certain factors of maintainability. This case was found factors like Appropriate technical platforms, design suited to the problem-domain, coherent naming Architecture and Initial defects. These factors require additional techniques for assessment. Yet, it is important to note that factors relating to code smells include both those addresses by expert judgment and those by traditional metrics. Like, some code smells can support factors of analysis, like use of components and encapsulation (which are not captured by software metrics). An interesting aspect that was identified across the study was design consistence which played a major role in the process of various maintenance tasks. An aspect that was interpreted in a broad sense cutting across abstraction level like consistency at variable level, method level and class levels was not limited to the naming of elements. For maintainability factors identified it was found that eight of them can be addressed using current code smell definitions, but in most cases the code smell will require to be implemented using alternative methods like manual inspections and semantic analysis. Moreover, several techniques of detection for these smells are based on software metrics that are size related software metrics. Another largely notion that is related to coupling and cohesion is the logic spread factor. The results obtained here hint at the potential of code smell covering a more heterogeneous spectrum of factors than expert judgment and software metrics individually. In this project thirteen factors were identifies during the maintenance project. Developers mentioned more factors than others. For example, factors like standard convections in naming and commenting did not contribute to a major role for the developers. Present discrepancies can be because of the time can because of lack of enough contextual information for a given factor accordingly. On the other hand developers are conditioned by maintenance experience; hence factors like the kind of task may play a significant role over the perception of the most relevant software factors. All the developers that were involved in the project unanimously mentioned aspects such as simplicity and appropriate technical platform, this may be an indication that such factors should be availed more attention, since they may play significant role regardless of the context of maintenance. Also this result does suggest that in order to achieve maintainability evaluations that are which are based in expert judgment. The utilization of enough contextual detail may be necessary to enable the experts to prioritize certain factors over others. Some factors identifies n the project have not been reported previously, and they can complement the findings from aspects like logic spread and design consistency, are perceived to be very influential by maintainers but were not mentioned by the experts. This can be because maintainability of a system form an expert’s point of view is based on expert judgment focus on higher parameters (Marinescu, 2005). By understanding the capacity and limitations of different evaluation methods for addressing various factor that influence software maintainability. Code smells can give insight on different factors of maintainability. That can be improved by refactoring, never the less, some factors are not reflected using code smells and need alternative approaches to evaluate them. This paper has described a collection of factors identified as important for maintainability in the past. Through the paper some new factors that have not been reported previously and are perceived as important by developers based on the response from the developers. This paper makes the following contributions: Confirming and complementing findings by (Anda, 2007) by extracting factors of maintainability, which are important to a software maintenance perspective. And from these factor’s manifestations, this paper identifies which code smell can be used to identify them or alternative methods of analysis that can be used for evaluation. And finally provide an overview of the capacity of the code smell definitions to evaluate the overall system maintainability. Future work involves detailed evaluation of whether results obtained from code smell detection tools can be used to predict maintenance problems. This study may be limited to a set code smell that is identifiable. This is to provide a quantitative perspective regarding the coverage level or capability of code smells to reveal problematic code Appendix: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.team.tests.cvs.core/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.team.tests.core/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test-feature/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test.performance.data/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.text/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test.performance.win32/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.text.tests/ http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.test.performance.win32/ References Anda, B. (2007) Assessing Software System Maintainability using Structural Measures and Expert Assessments in Int’l Conf Softw. Maint., pp. 204–213. Fowler, M. (1999).Refactoring: Improving the Design of Existing Code. Addison-Wesley, Mantyl?a, M. (2009). Software Evolvability - Empirically Discovered Evolvability Issues and Human Evaluations, PhD Thesis, Helsinki University of Technology. Marinescu, R. (2005). Measurement and quality in object-oriented design,” in Int’l Conf. Softw. Maint. pp. 701–704. Moha, N., Gueheneuc, Y.G, Duchien, L and Le Meur, A. F (2010). DECOR: A Method for the Speci?cation and Detection of Code and Design Smells, IEEE Trans. Softw. Eng., vol. 36, no. 1, pp. 20–36, Yamashita, A. and Moonen, L. (2012). Do code smells re?ect important maintainability aspects? Simula Research Laboratory, Technical Report. Zimmermann, T., Premraj, R. & Zeller, R. (2007). Predicting Defects for Eclipse Saarland University Eclipse project Read More