Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-04-06T13:27:55Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) versao_biblioteca.pdf: 3051240 bytes, checksum: ac1a91e08d64c78a372cb0e151bcb7c7 (MD5) / Made available in DSpace on 2016-04-06T13:27:55Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) versao_biblioteca.pdf: 3051240 bytes, checksum: ac1a91e08d64c78a372cb0e151bcb7c7 (MD5) Previous issue date: 2015-02-24 / CAPEs / Empowering application programmers to make energy-aware decisions is a critical dimension in improving energy efficiency of computer systems. Despite the growing interest in designing software development processes, frameworks, and programming models to facilitate application-level energy management, little is known on how to design application-level energy-efficient solutions for concurrent software running on parallel architectures. This is unfortunate for at least two reasons: (1) thanks to the proliferation of multicore CPUs, concurrent programming is a standard practice in modern software engineering; (2) a CPU with more cores (say 32) often consumes more power than one with fewer cores (say 1 or 2). However, application developers still do not understand how their code modifications impact energy consumption in a parallel system. Analyzing STACKOVERFLOW showed evidence that this is a real problem; Even though the interest in energy consumption issues is increasing over the years, developers still hold misconceptions and assumptions that are not always true. This lack of knowledge is primarily due to a lack of appropriate tools to measure/identify/refactor energy consumption hotspots. This thesis begins to bridge the chasm of the first problem — the lack of knowledge — by presenting an extensive experimental space exploration over two concurrent programming building blocks: (1) thread-safe collections and (2) thread management constructs. Through a list of findings that are not always obvious, we illuminate the relationship between the choices and settings of design decisions and energy consumption of parallel systems. This thesis then starts to bridge the gap of the second problem — the lack of tools. Lessons learned in our previous studies showed that ForkJoin tasks often operate on an indexable data structure, with subtasks operating only on part of this data structure. One naïve solution is to copy part of the data structure and use it in the next computation. In a recursive framework such as ForkJoin, given an array-based representation, each recursive call will create n new arrays, where n is the width of forking. To address this, we derive a refactoring that, instead of copy part of the data structure, it shares it, allowing subtasks to operate on contiguous partitions of the data structure. We manually applied this refactoring into 15 open source projects. Our refactoring succeed in saving energy for each one of them (12% average saving). We sent the refactored versions to the project owner and, during a timeframe of 40 days, 7 out of 9 projects that replied to our patches have already accepted and merged them. Discussions during the merge process revealed that developers were not aware of this optimization. We then implemented this refactoring as an Eclipse plug-in so that other developers can (1) detect uses of copy where it would be beneficial to use sharing and (2) refactor the code in an automated way. / Fornecer meios para que desenvolvedores de software tomem decisões energeticamente eficientes é uma dimensão crítica para se melhorar o consumo de energia de sistemas computacionais. Apesar do crescente interesse em processos de desenvolvimento de software, arcabouços, e modelos de programação de forma a facilitar o gerenciamento de energia no nível da aplicação, pouco se sabe sobre como arquitetar sistemas concorrentes energéticamente eficientes que rodem em arquiteturas paralelas. Isso é inoportuno por pelo menos duas razões: (1) graças a proliferação de CPUs multicore, programação concorrente se tornou uma prática padrão na engenharia de software moderna; (2) uma CPU com várias unidades de processamento (por exemplo, 32) geralmente dissipa mais potência do que uma com um número menor (por exemplo, 1 ou 2). No entanto, desenvolvedores ainda não entendem como suas modificações de código impactam no consumo de energia de uma aplicação paralela. Uma análise do StackOverflow mostrou evidências que esse é um problema real; mesmo embora exista um crescente interesse em questões relacionadas ao consumo de energia, desenvolvedores ainda cometem equívocos e mantêm suposições que não são sempre verdadeiras. Essa falta de conhecimento é primariamente devido a falta de ferramentas apropriadas para medir/identificar/refatorar hotspots de consumo de energia. Essa tese então começa a pavimentar o abismo do primeiro problema — a falta de conhecimento — através de uma extensa exploração experimental de dois dos pilares fundamentais da programação concorrente: (1) coleções thread-safe e (2) construções para o gerenciamento de threads. Através de uma lista de achados que não são sempre óbvios, esta tese ilumina o relacionamento entre escolhas de design de código paralelo com seu consumo de energia. Esta tese começa então a pavimentar a lacuna do segundo problema — a falta de ferramentas. Lições aprendidas em um dos estudos anteriores mostraram que várias tarefas do arcabouço ForkJoin operam em estrutura de dados indexáveis, com sub-tarefas operando somente em parte dessa estrutura de dados. Uma solução ingênua é de copiar parta da estrutura de dados e utiliza-la na computação sub-sequente. Em um arcabouço recursivo como o ForkJoin, dado uma representação baseada em arrays, cada chamada recursiva criará n novos arrays, onde n é a profundidade do fork. Como solução, esta tese apresenta uma refatoração que, ao invés de copiar parte da estrutura de dados, ela compartilha-a, possibilitando que sub-tarefas operem em partições contíguas da estrutura de dados. Essa refatoração foi avaliada em 15 projetos de código aberto, a qual foi capaz de economizar energia em todos os casos (média de 12% de economia). A versão refatorada foi enviada aos mantenedores do projeto original e, durante um período de 40 dias, 7 dos 9 mantenedores que responderam aos patches enviados já haviam aceitado-os e integrado-os. Discussões durante o processo de integração revelaram que desenvolvedores não estão cientes desta otimização. Esta tese então implementou essa refatoração como um plug-in da IDE Eclipse de forma que outros desenvolvedores possam (1) detectar usos de cópia em cenários o quais seriam beneficiais o uso do modelo de compartilhamento and (2) refatorar o código de forma automática.

Made available in DSpace on 2014-06-12T16:00:59Z (GMT). No. of bitstreams: 2 arquivo7122_1.pdf: 1649883 bytes, checksum: 5e4109867fef651c2cd98d144b166e55 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2005 / Refactoring tem sido muito útil na reestruturação de programas orientados a objetos. Esta técnica pode proporcionar benefícios similares aos programas orientados a aspectos. Sendo assim, refactoring pode ser uma técnica interessante para introduzir aspectos em uma aplicação existente, orientada a objetos. No intuito de explorar os benefícios proporcionados pelos refactorings, desenvolvedores de aplicações orientadas a aspectos estão identificando transformações comuns para tais aplicações, em sua maioria, para a linguagem AspectJ, uma linguagem orientada a aspectos de propósito geral que estende Java. No entanto, estas transformações não possuem suporte para garantir que preservam o comportamento externo da aplicação. Tal propriedade garante que as transformações são de fato refactorings. Este trabalho foca neste problema e introduz leis de programação para AspectJ que podem ser usadas para derivar transformações que preservam comportamento (refactorings) para um subconjunto desta linguagem. Leis de programação definem equivalência entre dois programas, desde que algumas restrições sejam respeitadas. Nosso conjunto de leis não somente define como introduzir ou remover construções de AspectJ, como também como reestruturar aplicações nesta linguagem. Aplicando e compondo as leis, pode-se mostrar que uma transformação AspectJ é de fato um refactoring. Leis são apropriadas para isso pois são bem mais simples do que a maioria dos refactorings. Comparando com refactorings, as leis envolvem transformações localizadas e somente uma construção da linguagem por vez, além de seram bi-direcionais. As leis formam uma base para a definição de refactorings com uma certa confiança de que estes preservam comportamento. Nós avaliamos as leis de duas formas. A primeira utiliza as leis para derivar refactorings já existentes na literatura. Isto ajuda a definir com mais precisão as precondições associadas a estes refactorings, alem de verificar se eles preservam comportamento. A segunda forma de avaliação utiliza as leis e alguns refactorings derivados destas para reestruturar duas aplicações Java. A implementação de comportamento transversal nestas aplicações é reestruturada utilizando construções de AspectJ para tornar tal comportamento modular. Isto ilustra que as leis podem também ser úteis para transformar aplicações orientadas a objetos em aplicações orientadas a aspectos

No description available.

The goal of this paper is to present a methodology for rewriting outdated software systems. We developed this method based on a work assignment from the company SSAB AB, where we were tasked with rewriting one of their outdated systems to fit modern standards. This paper discusses the reasons for rewriting outdated systems, and the steps of planning, analysing source code, the rewriting procedure, documenting the rewritten code, and evaluating it. By using the method we developed, we were able to produce a satisfactory rewritten application for SSAB, and believe that it can be reused for similar purposes in the future.

Context. There is a need for developers to write clean code and code that adheres to a high-quality standard. We need developers not to introduce technical debt and code smells to the code. From a business perspective, developers that introduce technical debt to the code will make the code more difficult to maintain, meaning that the cost for the project will increase. Objectives. The main objective of this study is to gain an understanding about the perception the developers have about clean code and how they use it in practice. There is not much information about how clean code is perceived by developers and applied in practice, and this thesis will extend the information about those two areas. It is an effort to understand developers' perception of clean code in practice and what they think about it. Realization (Method). To understand the state-of-the-art in the area of clean code, we first performed  literature review using snowballing. To delve into developers' perception about clean code and how it is used in practice. We have developed and sent out a questionnaire survey to developers within companies and shared the survey via social networks. We ask if developers believe that clean code eases the process of reading, modifying, reusing, or maintaining code. We also investigate whether developers write clean code initially or refactor it to become clean code, or do none of these. Finally, we ask developers in practice what clean code principles they agree or disagree with. Asking this will help identify which clean code principles developers think are helpful and which are not. Results. The results from the investigation are that the developers strongly believe in clean code and that it affects reading, modifying, reusing, and maintaining code, positively. Also, developers do not write clean code initially but rather refactor unclean code to become clean code. Only a small portion of developers write clean code initially, and some do what suits the situation, while some do neither of these. The last result is that developers agree with most of the clean code principles listed in the questionnaire survey and that there are also some principles that they discard, but these fewer. Conclusions. From the first research question, we know that developers strongly believe that clean code makes the code more readable, understandable, modifiable, or reusable. Also, developers check that the code is readable using code reviews, peer reviews, or pull requests. Regarding the second research question, we know that developers mostly refactor unclean code rather than write clean code initially. The challenges are that to write clean code initially, a developer must have a solid understanding of the problem and obstacles in advance, and a developer will not always know what the code should look like in advance. The last research question showed that most developers agree with most of the clean code principles and that only a small portion of developers disagree with some of them. Static code analysis and code quality gates can ensure that developers follow these clean code practices and principles.

Tools that perform semi-automated refactoring are currently under-utilized by programmers. If more programmers adopted refactoring tools, software projects could make enormous productivity gains. However, as more advanced refactoring tools are designed, a great chasm widens between how the tools must be used and how programmers want to use them. This dissertation begins to bridge this chasm by exposing usability guidelines to direct the design of the next generation of programmer-friendly refactoring tools, so that refactoring tools fit the way programmers behave, not vice-versa.

Traceability is defined as the ability to establish, record, and maintain dependency relations among various software artifacts in a software system, in both a forwards and backwards direction, throughout the multiple phases of the project’s life cycle. The availability of traceability information has been proven vital to several software engineering activities such as program comprehension, impact analysis, feature location, software reuse, and verification and validation (V&V). The research on automated software traceability has noticeably advanced in the past few years. Various methodologies and tools have been proposed in the literature to provide automatic support for establishing and maintaining traceability information in software systems. This movement is motivated by the increasing attention traceability has been receiving as a critical element of any rigorous software development process. However, despite these major advances, traceability implementation and use is still not pervasive in industry. In particular, traceability tools are still far from achieving performance levels that are adequate for practical applications. Such low levels of accuracy require software engineers working with traceability tools to spend a considerable amount of their time verifying the generated traceability information, a process that is often described as tedious, exhaustive, and error-prone. Motivated by these observations, and building upon a growing body of work in this area, in this dissertation we explore several research directions related to enhancing the performance of automated tracing tools and techniques. In particular, our work addresses several issues related to the various aspects of the IR-based automated tracing process, including trace link retrieval, performance enhancement, and the role of the human in the process. Our main objective is to achieve performance levels, in terms of accuracy, efficiency, and usability, that are adequate for practical applications, and ultimately to accomplish a successful technology transfer from research to industry.

No description available.

No description available.

Although software architecture aims for long-term stability, architectural migrations may be necessary to adapt to evolving business needs and resource availability. In recent years, numerous migrations have occurred within backend architectures. While many of these migrations partition monoliths into microservices, several prominent enterprises have reported having to unite microservices into monoliths to reduce management and communication overheads. The required unification is typically manual, substantial, tedious, and error-prone for complex systems. This thesis presents a novel automated architectural refactoring that transforms a microservice system into a functionally equivalent monolith. Our refactoring relies on abstract syntax tree merging and control flow bridging to unite distributed components into a centralized system. We have implemented our approach as μJUNITER, an automated refactoring tool that operates on Java source files of Spring Boot microservices, producing Spring Boot modular monoliths. Evaluations conducted with third-party and synthetically generated microservice applications, with up to 100 microservices, demonstrate that μJUNITER's refactoring preserves the original system's functionality, as verified by end-to-end and back-end unit testing. The refactoring also reduced latency in certain cases and resource consumption in all cases. μJUNITER's refactoring saves manual programming effort proportional to the number of microservices and their level of inter-service interaction. As software architectures must adapt to changing trends, our approach can complement and enhance the existing automated toolset for architectural migration. / Master of Science / Modern software must constantly evolve to remain useful, reliable, and efficient. Sometimes, these changes affect small parts of the software, while in other cases, the entire architecture needs to be reworked. Enterprise software architecture typically follows two main styles: monolithic systems, in which all features are bundled together, or microservices, in which features are broken into separate, remotely interacting components. While many companies have shifted from monolithic systems to microservices, some are now moving back to monolithic structures to simplify management and reduce overhead. This thesis introduces a tool called μJUNITER that automates the process of merging microservices into a single, cohesive system, saving time and reducing errors. The evaluation shows that μJUNITER preserves the original functionality while improving performance and reducing resource usage. With the continuous changes in the software landscape, μJUNITER provides an effective solution for organizations seeking to restructure the architecture of their enterprise systems.