SEJun 4, 2019Code
Identification and Assessment of Software Design Pattern ViolationsTamer Abdelaziz, Aya Sedky, Bruno Rossi et al.
The validation of design pattern implementations to identify pattern violations has gained more relevance as part of re-engineering processes in order to preserve, extend, reuse software projects in rapid development environments. If design pattern implementations do not conform to their definitions, they are considered a violation. Software aging and the lack of experience of developers are the origins of design pattern violations. It is important to check the correctness of the design pattern implementations against some predefined characteristics to detect and to correct violations, thus, to reduce costs. Currently, several tools have been developed to detect design pattern instances, but there has been little work done in creating an automated tool to identify and validate design pattern violations. In this paper we propose a Design Pattern Violations Identification and Assessment (DPVIA) tool, which has the ability to identify software design pattern violations and report the conformance score of pattern instance implementations towards a set of predefined characteristics for any design pattern definition whether Gang of Four (GoF) design patterns by Gamma et al[1]; or custom pattern by software developer. Moreover, we have verified the validity of the proposed tool using two evaluation experiments and the results were manually checked. Finally, in order to assess the functionality of the proposed tool, it is evaluated with a data-set containing 5,679,964 Lines of Code among 28,669 in 15 open-source projects, with a large and small size of open-source projects that extensively and systematically employing design patterns, to determine design pattern violations and suggest refactoring solutions, thus keeping costs of software evolution. The results can be used by software architects to develop best practices while using design patterns.
CRSep 2, 2025
From Attack Descriptions to Vulnerabilities: A Sentence Transformer-Based ApproachRefat Othman, Diaeddin Rimawi, Bruno Rossi et al.
In the domain of security, vulnerabilities frequently remain undetected even after their exploitation. In this work, vulnerabilities refer to publicly disclosed flaws documented in Common Vulnerabilities and Exposures (CVE) reports. Establishing a connection between attacks and vulnerabilities is essential for enabling timely incident response, as it provides defenders with immediate, actionable insights. However, manually mapping attacks to CVEs is infeasible, thereby motivating the need for automation. This paper evaluates 14 state-of-the-art (SOTA) sentence transformers for automatically identifying vulnerabilities from textual descriptions of attacks. Our results demonstrate that the multi-qa-mpnet-base-dot-v1 (MMPNet) model achieves superior classification performance when using attack Technique descriptions, with an F1-score of 89.0, precision of 84.0, and recall of 94.7. Furthermore, it was observed that, on average, 56% of the vulnerabilities identified by the MMPNet model are also represented within the CVE repository in conjunction with an attack, while 61% of the vulnerabilities detected by the model correspond to those cataloged in the CVE repository. A manual inspection of the results revealed the existence of 275 predicted links that were not documented in the MITRE repositories. Consequently, the automation of linking attack techniques to vulnerabilities not only enhances the detection and response capabilities related to software security incidents but also diminishes the duration during which vulnerabilities remain exploitable, thereby contributing to the development of more secure systems.
SEJan 5, 2019
Software Testing Process Models Benefits & Drawbacks: a Systematic Literature ReviewKatarína Hrabovská, Bruno Rossi, Tomáš Pitner
Context: Software testing plays an essential role in product quality improvement. For this reason, several software testing models have been developed to support organizations. However, adoption of testing process models inside organizations is still sporadic, with a need for more evidence about reported experiences. Aim: Our goal is to identify results gathered from the application of software testing models in organizational contexts. We focus on characteristics such as the context of use, practices applied in different testing process phases, and reported benefits & drawbacks. Method: We performed a Systematic Literature Review (SLR) focused on studies about the application of software testing processes, complemented by results from previous reviews. Results: From 35 primary studies and survey-based articles, we collected 17 testing models. Although most of the existing models are described as applicable to general contexts, the evidence obtained from the studies shows that some models are not suitable for all enterprise sizes, and inadequate for specific domains. Conclusion: The SLR evidence can serve to compare different software testing models for applicability inside organizations. Both benefits and drawbacks, as reported in the surveyed cases, allow getting a better view of the strengths and weaknesses of each model.
SEJun 20, 2018
A Large-Scale Study on Source Code Reviewer RecommendationJakub Lipcak, Bruno Rossi
Context: Software code reviews are an important part of the development process, leading to better software quality and reduced overall costs. However, finding appropriate code reviewers is a complex and time-consuming task. Goals: In this paper, we propose a large-scale study to compare performance of two main source code reviewer recommendation algorithms (RevFinder and a Naive Bayes-based approach) in identifying the best code reviewers for opened pull requests. Method: We mined data from Github and Gerrit repositories, building a large dataset of 51 projects, with more than 293K pull requests analyzed, 180K owners and 157K reviewers. Results: Based on the large analysis, we can state that i) no model can be generalized as best for all projects, ii) the usage of a different repository (Gerrit, GitHub) can have impact on the the recommendation results, iii) exploiting sub-projects information available in Gerrit can improve the recommendation results.