Evaluation of a Secure Smart Contract Development in Ethereum

In the Ethereum Blockchain, Smart Contracts are the standard programs that can perform operations in the network using the platform currency (ether) and data. Once these contracts are deployed, the user cannot change their state in the system. This immutability means that, if the contract has any vulnerabilities, it cannot be erased or modified. Ensuring that a contract is safe in the network requires the knowledge of developers to avoid these problems. Many tools explore and analyse the contract security and behaviour and, as a result, detect the vulnerabilities present. This thesis aims to analyse and integrate different security analysis tools in the smart contract development process allowing for better knowledge and awareness of best practices and tools to test and verify contracts, providing a safer smart contract to deploy. The development of the final solution that allows the integration of security analysis tools in smart contracts was performed in two stages. In the first stage, approaches, patterns and tools to develop smart contracts were studied and compared, by running them on a standard set of vulnerable contracts, to understand how effective they are in detecting vulnerabilities. Seven existing tools were found that can support the detection of vulnerabilities during the development process. In the second stage, it is introduced a framework called EthSential. EthSential was designed and implemented to initially integrate the security analysis tools, Mythril, Securify and Slither, with two ways to use, command line and Visual Studio Code. EthSential is published and publicly available through PyPI and Visual Studio Code extensions. To evaluate the solution, two software testing methods and a usability and satisfaction questionnaire were performed. The results were positive in terms of software testing. However, in terms of usability and satisfaction of the developers, the overall results did not meet expectations, concluding that improvements should be made in the future to increase the developers’ satisfaction and usability.Em Ethereum, contratos inteligentes são programas que permitem realizar operações na rede utilizando a moeda digital (ether) e os dados armazenados na mesma. Assim que estes contratos são enviados para a plataforma, o utilizador é impedido de alterar seu estado. Esta imutabilidade faz com que se o contrato tiver alguma vulnerabilidade, não poderá ser apagado ou modificado. Para garantir que um contrato seja considerado seguro, requer um conhecimento dos programadores em lidar com estas vulnerabilidades. Existem muitas ferramentas que exploram e analisam a segurança e o comportamento do contrato de forma a detectar as vulnerabilidades presentes. Esta tese tem como objectivo analisar e integrar diferentes ferramentas de análise de segurança no processo de desenvolvimento de contratos inteligentes. De forma a permitir um melhor conhecimento e consciência das melhores práticas é necessário analisar as ferramentas de teste e verificação de contratos, proporcionando assim um contrato mais seguro. O desenvolvimento da solução final foi realizado em duas fases. Na primeira fase, foram estudadas abordagens, padrões e ferramentas para desenvolver contratos inteligentes, e comparar essas ferramentas, executando-as num conjunto de contratos vulneráveis, para entender o quão eficaz são na detecção de vulnerabilidades. Neste estudo foram encontradas sete ferramentas que podem apoiar a detecção de vulnerabilidades durante o processo de desenvolvimento. Na segunda fase, é apresentada uma aplicação denominada EthSential. A aplicação foi desenhada e implementada de forma a integrar, inicialmente, as ferramentas de análise de segurança Mythril, Securify e Slither. A aplicação permite duas formas de uso, através da linha de comandos e através das extensões do Visual Studio Code. A aplicação foi publicada e disponibilizada publicamente através das ferramentas PyPI e Visual Studio Code. Para avaliar a solução, foram realizados dois métodos de teste de software e um questionário de usabilidade e satisfação. Os resultados finais foram considerados positivos em termos de teste de software. No entanto, em termos de usabilidade e satisfação dos programados, os resultados não correspoderam às expectativas. Concluindo assim que algumas melhorias devem ser feitas no futuro para aumentar a satisfação dos programadores e a respectiva usabilidade da solução

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Technical Debt Decision-Making Framework

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items

Detection of microservice smells through static analysis

A arquitetura de microsserviços é um modelo arquitetural promissor na área de software, atraindo desenvolvedores e empresas para os seus princípios convincentes. As suas vantagens residem no potencial para melhorar a escalabilidade, a flexibilidade e a agilidade, alinhando se com as exigências em constante evolução da era digital. No entanto, navegar entre as complexidades dos microsserviços pode ser uma tarefa desafiante, especialmente à medida que este campo continua a evoluir. Um dos principais desafios advém da complexidade inerente aos microsserviços, em que o seu grande número e interdependências podem introduzir novas camadas de complexidade. Além disso, a rápida expansão dos microsserviços, juntamente com a necessidade de aproveitar as suas vantagens de forma eficaz, exige uma compreensão mais profunda das potenciais ameaças e problemas que podem surgir. Para tirar verdadeiramente partido das vantagens dos microsserviços, é essencial enfrentar estes desafios e garantir que o desenvolvimento e a adoção de microsserviços sejam bem-sucedidos. O presente documento pretende explorar a área dos smells da arquitetura de microsserviços que desempenham um papel tão importante na dívida técnica dirigida à área dos microsserviços. Embarca numa exploração de investigação abrangente, explorando o domínio dos smells de microsserviços. Esta investigação serve como base para melhorar um catálogo de smells de microsserviços. Esta investigação abrangente obtém dados de duas fontes primárias: systematic mapping study e um questionário a profissionais da área. Este último envolveu 31 profissionais experientes com uma experiência substancial no domínio dos microsserviços. Além disso, são descritos o desenvolvimento e o aperfeiçoamento de uma ferramenta especificamente concebida para identificar e resolver problemas relacionados com os microsserviços. Esta ferramenta destina-se a melhorar o desempenho dos programadores durante o desenvolvimento e a implementação da arquitetura de microsserviços. Por último, o documento inclui uma avaliação do desempenho da ferramenta. Trata-se de uma análise comparativa efetuada antes e depois das melhorias introduzidas na ferramenta. A eficácia da ferramenta será avaliada utilizando o mesmo benchmarking de microsserviços utilizado anteriormente, para além de outro benchmarking para garantir uma avaliação abrangente.The microservices architecture stands as a beacon of promise in the software landscape, drawing developers and companies towards its compelling principles. Its appeal lies in the potential for improved scalability, flexibility, and agility, aligning with the ever-evolving demands of the digital age. However, navigating the intricacies of microservices can be a challenging task, especially as this field continues to evolve. A key challenge arises from the inherent complexity of microservices, where their sheer number and interdependencies can introduce new layers of intricacy. Furthermore, the rapid expansion of microservices, coupled with the need to harness their advantages effectively, demands a deeper understanding of the potential pitfalls and issues that may emerge. To truly unlock the benefits of microservices, it is essential to address these challenges head-on and ensure a successful journey in the world of microservices development and adoption. The present document intends to explore the area of microservice architecture smells that play such an important role in the technical debt directed to the area of microservices. It embarks on a comprehensive research exploration, delving into the realm of microservice smells. This research serves as the cornerstone for enhancing a microservice smell catalogue. This comprehensive research draws data from two primary sources: a systematic mapping research and an industry survey. The latter involves 31 seasoned professionals with substantial experience in the field of microservices. Moreover, the development and enhancement of a tool specifically designed to identify and address issues related to microservices is described. This tool is aimed at improving developers' performance throughout the development and implementation of microservices architecture. Finally, the document includes an evaluation of the tool's performance. This involves a comparative analysis conducted before and after the tool's enhancements. The tool's effectiveness will be assessed using the same microservice benchmarking as previously employed, in addition to another benchmark to ensure a comprehensive evaluation

Towards Usable API Documentation

The learning and usage of an API is supported by documentation. Like source code, API documentation is itself a software product. Several research results show that bad design in API documentation can make the reuse of API features difficult. Indeed, similar to code smells, poorly designed API documentation can also exhibit 'smells'. Such documentation smells can be described as bad documentation styles that do not necessarily produce incorrect documentation but make the documentation difficult to understand and use. This thesis aims to enhance API documentation usability by addressing such documentation smells in three phases. In the first phase, we developed a catalog of five API documentation smells consulting literature on API documentation issues and online developer discussion. We validated their presence in the real world by creating a benchmark of 1K official Java API documentation units and conducting a survey of 21 developers. The developers confirmed that these smells hinder their productivity and called for automatic detection and fixing. In the second phase, we developed machine-learning models to detect the smells using the 1K benchmark, however, they performed poorly when evaluated on larger and more diverse documentation sources. We explored more advanced models; employed re-training and hyperparameter tuning to further improve the performance. Our best-performing model, RoBERTa, achieved F1-scores of 0.71-0.93 in detecting different smells. In the third phase, we first focused on evaluating the feasibility and impact of fixing various smells in the eyes of practitioners. Through a second survey of 30 practitioners, we found that fixing the lazy smell was perceived as the most feasible and impactful. However, there was no universal consensus on whether and how other smells can/should be fixed. Finally, we proposed a two-stage pipeline for fixing lazy documentation, involving additional textual description and documentation-specific code example generation. Our approach utilized a large language model, GPT- 3, to generate enhanced documentation based on non-lazy examples and to produce code examples. The generated code examples were refined iteratively until they were error-free. Our technique demonstrated a high success rate with a significant number of lazy documentation instances being fixed and error-free code examples being generated

Detecting Dissimilar Classes of Source Code Defects

Software maintenance accounts for the most part of the software development cost and efforts, with its major activities focused on the detection, location, analysis and removal of defects present in the software. Although software defects can be originated, and be present, at any phase of the software development life-cycle, implementation (i.e., source code) contains more than three-fourths of the total defects. Due to the diverse nature of the defects, their detection and analysis activities have to be carried out by equally diverse tools, often necessitating the application of multiple tools for reasonable defect coverage that directly increases maintenance overhead. Unified detection tools are known to combine different specialized techniques into a single and massive core, resulting in operational difficulty and maintenance cost increment. The objective of this research was to search for a technique that can detect dissimilar defects using a simplified model and a single methodology, both of which should contribute in creating an easy-to-acquire solution. Following this goal, a ‘Supervised Automation Framework’ named FlexTax was developed for semi-automatic defect mapping and taxonomy generation, which was then applied on a large-scale real-world defect dataset to generate a comprehensive Defect Taxonomy that was verified using machine learning classifiers and manual verification. This Taxonomy, along with an extensive literature survey, was used for comprehension of the properties of different classes of defects, and for developing Defect Similarity Metrics. The Taxonomy, and the Similarity Metrics were then used to develop a defect detection model and associated techniques, collectively named Symbolic Range Tuple Analysis, or SRTA. SRTA relies on Symbolic Analysis, Path Summarization and Range Propagation to detect dissimilar classes of defects using a simplified set of operations. To verify the effectiveness of the technique, SRTA was evaluated by processing multiple real-world open-source systems, by direct comparison with three state-of-the-art tools, by a controlled experiment, by using an established Benchmark, by comparison with other tools through secondary data, and by a large-scale fault-injection experiment conducted using a Mutation-Injection Framework, which relied on the taxonomy developed earlier for the definition of mutation rules. Experimental results confirmed SRTA’s practicality, generality, scalability and accuracy, and proved SRTA’s applicability as a new Defect Detection Technique