A Domain Analysis to Specify Design Defects and Generate Detection Algorithms

Quality experts often need to identify in software systems design defects, which are recurring design problems, that hinder development\ud and maintenance. Consequently, several defect detection approaches\ud and tools have been proposed in the literature. However, we are not\ud aware of any approach that defines and reifies the process of generating\ud detection algorithms from the existing textual descriptions of defects.\ud In this paper, we introduce an approach to automate the generation\ud of detection algorithms from specifications written using a domain-specific\ud language. The domain-specific is defined from a thorough domain analysis.\ud We specify several design defects, generate automatically detection\ud algorithms using templates, and validate the generated detection\ud algorithms in terms of precision and recall on Xerces v2.7.0, an\ud open-source object-oriented system

From a Domain Analysis to the Specification and Detection of Code and Design Smells

Code and design smells are recurring design problems in software systems that must be identified to avoid their possible negative consequences\ud on development and maintenance. Consequently, several smell detection\ud approaches and tools have been proposed in the literature. However,\ud so far, they allow the detection of predefined smells but the detection\ud of new smells or smells adapted to the context of the analysed systems\ud is possible only by implementing new detection algorithms manually.\ud Moreover, previous approaches do not explain the transition from\ud specifications of smells to their detection. Finally, the validation\ud of the existing approaches and tools has been limited on few proprietary\ud systems and on a reduced number of smells. In this paper, we introduce\ud an approach to automate the generation of detection algorithms from\ud specifications written using a domain-specific language. This language\ud is defined from a thorough domain analysis. It allows the specification\ud of smells using high-level domain-related abstractions. It allows\ud the adaptation of the specifications of smells to the context of\ud the analysed systems.We specify 10 smells, generate automatically\ud their detection algorithms using templates, and validate the algorithms\ud in terms of precision and recall on Xerces v2.7.0 and GanttProject\ud v1.10.2, two open-source object-oriented systems.We also compare\ud the detection results with those of a previous approach, iPlasma

A Software Vulnerability Prediction Model Using Traceable Code Patterns And Software Metrics

Software security is an important aspect of ensuring software quality. The goal of this study is to help developers evaluate software security at the early stage of development using traceable patterns and software metrics. The concept of traceable patterns is similar to design patterns, but they can be automatically recognized and extracted from source code. If these patterns can better predict vulnerable code compared to the traditional software metrics, they can be used in developing a vulnerability prediction model to classify code as vulnerable or not. By analyzing and comparing the performance of traceable patterns with metrics, we propose a vulnerability prediction model. Objective: This study explores the performance of code patterns in vulnerability prediction and compares them with traditional software metrics. We have used the findings to build an effective vulnerability prediction model. Method: We designed and conducted experiments on the security vulnerabilities reported for Apache Tomcat (Releases 6, 7 and 8), Apache CXF and three stand-alone Java web applications of Stanford Securibench. We used machine learning and statistical techniques for predicting vulnerabilities of the systems using traceable patterns and metrics as features. Result: We found that patterns have a lower false negative rate and higher recall in detecting vulnerable code than the traditional software metrics. We also found a set of patterns and metrics that shows higher recall in vulnerability prediction. Conclusion: Based on the results of the experiments, we proposed a prediction model using patterns and metrics to better predict vulnerable code with higher recall rate. We evaluated the model for the systems under study. We also evaluated their performance in the cross-dataset validation

A Deep Learning approach to predict software bugs using micro patterns and software metrics

Software bugs prediction is one of the most active research areas in the software engineering community. The process of testing and debugging code proves to be costly during the software development life cycle. Software metrics measure the quality of source code to identify software bugs and vulnerabilities. Traceable code patterns are able to de- scribe code at a finer granularity level to measure quality. Micro patterns will be used in this research to mechanically describe java code at the class level. Machine learning has also been introduced for bug prediction to localize source code for testing and debugging. Deep Learning is a branch of Machine Learning that is relatively new. This research looks to improve the prediction of software bugs by utilizing micro patterns with deep learning techniques. Software bug prediction at a finer granularity level will enable developers to localize code to test and debug during the development process

Connection between version control operations and quality change of the source code

Software erosion is a well-known phenomena, meaning that software quality is continuously decreasing due to the ever-ongoing modifications in the source code. In this research work we investigated this phenomena by studying the impact of version control commit operations (add, update, delete) on the quality of the code. We calculated the ISO/IEC 9126 quality attributes for thousands of revisions of an industrial and three open-source software systems with the help of the Columbus Quality Model. We also collected the cardinality of each version control operation type for every investigated revision. We performed Chisquared tests on contingency tables with rows of quality change and columns of version control operation commit types. We compared the results with random data as well. We identified that the relationship between the version control operations and quality change is quite strong. Great maintainability improvements are mostly caused by commits containing Add operation. Commits containing file updates only tend to have a negative impact on the quality. Deletions have a weak connection with quality, and we could not formulate a general statement

Analysis of static and dynamic test-to-code traceability information

Unit test development has some widely accepted guidelines. Two of them concern the test and code relationship, namely isolation (unit tests should examine only a single unit) and separation (they should be placed next to this unit). These guidelines are not always kept by the developers. They can however be checked by investigating the relationship between tests and the source code, which is described by test-to-code traceability links. Still, these links perhaps cannot be inferred unambiguously from the test and production code. We developed a method that is based on the computation of traceability links for different aspects and report Structural Unit Test Smells where the traceability links for the different aspects do not match. The two aspects are the static structure of the code that reflects the intentions of the developers and testers and the dynamic coverage which reveals the actual behavior of the code during test execution. In this study, we investigated this method on real programs. We manually checked the reported Structural Unit Test Smells to find out whether they are real violations of the unit testing rules. Furthermore, the smells were analyzed to determine their root causes and possible ways of correction

An Empirical Investigation of Code Smell ‘Deception’ and Research Contextualisation through Paul’s Criteria

Code smells represent code decay and as such should be eradicated from a system to prevent future maintenance problems. A range of twenty smells described by Fowler and Beck each require varying numbers and combinations of refactorings in order to be eradicated — but exactly how many are needed when we consider related, nested refactorings is unclear. In this paper, we enumerate these refactorings when categorised according to Mantyla’s smell taxonomy. We then show how, ironically, the ‘smelliest’ of smells (and hence most difficult to eradicate) are actually those best understood by developers. So, code smells are not only unpleasant to have around, but are deceptive in their nature and make-up. The study is thus a warning against attempting to eradicate what are seemingly easily eradicated smells — these are often the smells the developer needs to be most wary of. Finally, we incorporate the answers to six questions suggested by Paul for ‘How to write a paper properly’ to position the paper in a reflective way

Recognising object-oriented software design quality : a practitioner-based questionnaire survey

Design quality is vital if software is to be maintainable. What practices do developers actually use to achieve design quality in their day-to-day work and which of these do they find most useful? To discover the extent to which practitioners concern themselves with object-oriented design quality and the approaches used when determining quality in practice, a questionnaire survey of 102 software practitioners, approximately half from the UK and the remainder from elsewhere around the world was used. Individual and peer experience are major contributors to design quality. Classic design guidelines, well-known lower level practices, tools and metrics all can also contribute positively to design quality. There is a potential relationship between testing practices and design quality. Inexperience, time pressures, novel problems, novel technology, and imprecise or changing requirements may have a negative impact on quality. Respondents with most experience are more confident in their design decisions, place more value on reviews by team leads and are more likely to rate design quality as very important. For practitioners, these results identify the techniques and tools that other practitioners find effective. For researchers, the results highlight a need for more work investigating the role of experience in the design process and the contribution experience makes to quality. There is also the potential for more in-depth studies of how practitioners are actually using design guidance, including Clean Code. Lastly, the potential relationship between testing practices and design quality merits further investigation