O Desenvolvimento de Software Orientado a Aspectos (AOSD) vem se consolidando como uma forma de resolver vários problemas das técnicas convencionais de programação, em particular em sistemas onde diversos interesses se encontram entrelaçados. A popularização dessa tecnologia faz surgir a necessidade de metodologias e ferramentas que facilitem o seu uso, como refatorações que levem em consideração suas características. No entanto as técnicas de modelagem de software disponíveis para AOSD não tem amadurecido no mesmo passo que as de implementação. Assim, para se poder pensar em mecanismos automáticos que trabalhem com a separação de interesses, é preciso verificar se as técnicas de modelagem existentes comportam isso. Este trabalho propõe uma adaptação da abordagem Theme de modelagem, para que ela permita uma representação mais fiel de sistemas que utilizam orientação a aspectos, em especial os que utilizam a linguagem AspectJ. Essa técnica proposta é utilizada para demonstrar algumas maneiras de detectar bad smells em sistemas orientados a aspectos. Também é mostrado como essa modelagem pode ser usada como base para a geração automática de código orientado a aspectos, e como pode ser feita a engenharia reversa de código existente de forma que ele possa ser analisado em forma de modelo. / Aspect‐Oriented Software Development (AOSD) is increasingly being considered a way to solve several problems in conventional programming methods, particularly in systems with crosscutting concerns. The popularization of this technology brings the need for methodologies and tools to ease its use, such as refactorings that take into account its characteristics. However modeling techniques available for AOSD are not maturing at the same rate as implementation techniques. Thus, in order to be able to devise automatic mechanisms that deal with separation of concerns, it is first necessary to verify if existing modeling techniques support that. In this work, we propose an adaptation of the Theme modeling approach, so that it represents aspect‐oriented systems more closely, especially those using the AspectJ language. This technique is used to demonstrate a few ways of detecting bad smells in aspect‐oriented systems. It is also shown how this model can be used as a basis for the automatic generation of aspectoriented code, and how existing code can be reverse‐engineered so that its model can be analyzed.

Made available in DSpace on 2016-06-02T19:06:28Z (GMT). No. of bitstreams: 1 DissLRCR.pdf: 1289177 bytes, checksum: 0d5c30e3a6fab66cbd1251a5fc2211d1 (MD5) Previous issue date: 2005-12-19 / This dissertation presents a study case on object-oriented systems refactoring. Systems developed according to the object-oriented paradigm may contain reusable code, even though not always have been designed for it. Systems maintenance is not an easy task, even for object-oriented systems. Software design patterns favour the implementation of efficient solutions for recurrent problems, easing reusability and maintainability. In cases of systems not designed using design patterns, it is possible to refactor the system using them, without altering the system functionality. This prospective study refers to the search for guidelines to help the software engineer to conduct this type of refactoring. For that purpose, seven systems implemented in Java, that were available in the Web, have been used. The study has three phases: the first refers to existing system functionality and class model recovery; so that, in the second phase, applicable software design patterns can be implemented; and the class model previously obtained can be updated with the software design patterns applied. In the third phase, the new system functionality is verified by tests, to confirm that the conducted refactoring has not altered it. The refactored system usually presents an increase in the LOC number, but becomes more maintainable due to better structuring and cohesion. Reuse is also eased. One restriction of this research is that the case study has been conducted only for small-scale information systems. / Esta dissertação apresenta um estudo de caso de refatoração de sistemas orientados a objetos. Sistemas desenvolvidos de acordo com o paradigma de orientação a objetos podem conter código reusável, apesar de nem sempre terem sido projetados para isso. Manutenção de sistemas não é uma tarefa fácil, nem mesmo para sistemas orientados a objetos. Padrões de projeto de software favorecem a implementação de soluções eficientes para problemas recorrentes, facilitando a reusabilidade e manutenibilidade. Nos casos dos sistemas não projetados com o seu uso, é possível refatorar o sistema usando-os, sem alterar a sua funcionalidade. Este estudo prospectivo refere-se à busca de diretrizes para auxiliar o engenheiro de software a conduzir esse tipo de refatoração. Para isso, sete sistemas implementados em Java que estavam disponíveis na Web foram usados. O estudo tem três etapas: a primeira refere-se à recuperação da funcionalidade e do modelo de classes do sistema existente de modo que, na segunda etapa, padrões de projeto de software aplicáveis possam ser implementados; e o modelo de classes previamente obtido possa ser atualizado com os padrões de projeto de software aplicados. Na terceira etapa, a funcionalidade do novo sistema é verificada por testes, para confirmar que a refatoração conduzida não a alterou. O sistema refatorado, usualmente, apresenta um aumento no número de LOC, mas torna-se mais manutenível, devido a melhor estruturação e coesão. O reuso é também facilitado. Uma restrição desta pesquisa é que o estudo de caso foi conduzido apenas para sistemas de informação de pequeno porte.

Programming language evolution provides room for improving existing programs. Developers can upgrade their projects, applying new features available in the latest language versions. However, during maintenance activities, the code artefacts can become distant from their original conception. In this context, the use of transformation techniques and processes can be interesting, as it reduces the error-proneness when improving source code structure. Refactoring is a process of improving the design of a software system, modifying its internal structure without changing its external observable behavior. From this scenario, this work presents a refactoring catalog focused on the new features of the Java language. Such refactorings are related to lambda expressions and seek to allow the transformation of features implemented in Java 7 for the current version 8. To evaluate the proposed refactorings applicability, we developed a static analysis and used it in a set of open source projects aiming to search for opportunities to apply those refactorings. / A evolução de uma linguagem de programação fornece espaços para melhorias de programas existentes. Dessa forma, desenvolvedores podem atualizar projetos de sistemas de software, aplicando os novos recursos disponíveis na linguagem. No entanto, ao adaptar, melhorar e modificar um sistema de software, seu código pode se afastar de sua concepção original. Nesse contexto, o uso de técnicas e processos de transformação pode ser interessante, pois reduz a possibilidade de erros ao realizar uma melhoria em uma estrutura de código, por exemplo. A refatoração é um processo de melhoria do projeto de um sistema de software, que altera sua estrutura interna, sem modificar seu comportamento externo observável. A partir desse cenário, este trabalho tem como principal objetivo apresentar um catálogo de refatorações direcionadas às novas funcionalidades da linguagem Java. Tais refatorações estão relacionadas às expressões lambda e visam permitir a transformação de construções implementadas em Java 7 para sua atual versão 8. Para avaliar a aplicabilidade das refatorações propostas, um conjunto de projetos de código aberto foi submetido a uma ferramenta de análise estática, desenvolvida para realizar buscas por oportunidades de refatoração.

Sistemas de software bem modularizados podem trazer diversos benefícios como reu- sabilidade, compreensão, adaptabilidade, manutenibilidade, entre outros. O conceito de separação de interesses está diretamente ligado à ideia de modularização e consiste na capacidade de manter cada interesse em sua própria unidade modular. Um interesse pode estar relacionado tanto a requisitos funcionais como não-funcionais e em diferentes níveis de abstração. Algumas das técnicas que têm sido utilizadas para modularização de interes- ses são a Programação Orientada a Aspectos (POA) e Refatoração. Entretanto, a maioria das propostas de refatoração que envolvem a POA possui limitações para a modularização de interesses transversais: muitas delas são de granularidade fina; algumas são definidas imprecisamente e possuem sobreposição de intenções. A seleção e composição de tais refatorações para a modularização de interesses é uma tarefa difícil e não-trivial, além de variar em cada contexto específico, o que dificulta o reuso. Algumas das propostas de refatorações são voltadas especialmente para interesses transversais, no entanto possuem um nível de abstração pouco elevado e encontram-se acopladas a mecanismos específicos de linguagens de programação OO e OA. Adicionalmente, a aplicação de refatorações deve ser planejada e acompanhada sistematicamente durante o desenvolvimento e manu- tenção de um software, pois envolve alocação de recursos e avaliação de custo/benefício. O objetivo deste trabalho é apresentar um método de refatoração para modularização de interesses transversais, através de refatorações de granularidade alta, baseado em padrões recorrentes de estruturas transversais (chamados de sintomas). Além disso, como parte do método, propõem-se algoritmos para análise de impacto a fim de apoiar desenvolve- dores no processo decisório de aplicação de refatorações candidatas. Inicialmente, dois estudos bibliográficos foram conduzidos: o primeiro sobre propostas de refatorações que envolvem aspectos e o segundo sobre trabalhos de medição de interesses. Dois estudos de caso foram realizados totalizando 22 interesses de dois sistemas alvos. Este trabalho de avaliação possibilitou uma análise quantitativa e qualitativa dos resultados onde foi possível verificar a aplicabilidade do proposta. / Well-modularized software systems can bring several benefits such as reuse, com- prehension, adaptability, maintainability, among others. The concept of separation of concerns refers to the idea of modularisation, which consists on the ability to keep every concern in its own modular unit. A concern can refer to functional and non-functional requirements and can also be in different abstraction levels. Some of the techniques which have been applied for crosscutting concerns modularization are Aspect-Oriented Programming (AOP) and Refactoring. However, most of the aspect-oriented refactor- ings have limitations regarding the modularisation of crosscutting concerns. A number of them presents fine-grained transformations. While some of them are well-documented catalogues, a number of them are defined imprecisely, addressing the same situation and having overlapping intentions. They do not allow the designer to holistically reason about the elements involved in a crosscutting concern. It becomes difficult and non-trivial to choose a set of fine-grained refactorings and organize them in a feasible order to achieve the concern modularisation in a specific context. Some of the refactoring techniques are particularly focused on crosscutting concerns, however they are not placed in a suf- ficient abstraction level. Moreover they are coupled to specific OO and AO language mechanisms. Additionally, the application of refactorings should be planned and realized systematically during software development and maintenance since it involves resource allocation and tradeoff analysis. The goal of this work is to present a refactoring method for crosscutting concerns modularisation, through coarse-grained refactorings based on recurring patterns of crosscutting shapes (called symptoms). Also, as part of the method, algorithms for change-impact analysis are proposed in order to support developers during the decision process of the application of refactoring candidates. Initially, two biblio- graphic studies were made: the first one about refactoring approaches which involve as- pects, and the second one about concern measurement techniques. Two case studies were carried out totalizing 22 concerns of two target systems. This evaluation work allowed a quantitative and qualitative analysis of the results. Thus it was possible to verify the applicability of our approach.

O Desenvolvimento de Software Orientado a Aspectos (AOSD) vem se consolidando como uma forma de resolver vários problemas das técnicas convencionais de programação, em particular em sistemas onde diversos interesses se encontram entrelaçados. A popularização dessa tecnologia faz surgir a necessidade de metodologias e ferramentas que facilitem o seu uso, como refatorações que levem em consideração suas características. No entanto as técnicas de modelagem de software disponíveis para AOSD não tem amadurecido no mesmo passo que as de implementação. Assim, para se poder pensar em mecanismos automáticos que trabalhem com a separação de interesses, é preciso verificar se as técnicas de modelagem existentes comportam isso. Este trabalho propõe uma adaptação da abordagem Theme de modelagem, para que ela permita uma representação mais fiel de sistemas que utilizam orientação a aspectos, em especial os que utilizam a linguagem AspectJ. Essa técnica proposta é utilizada para demonstrar algumas maneiras de detectar bad smells em sistemas orientados a aspectos. Também é mostrado como essa modelagem pode ser usada como base para a geração automática de código orientado a aspectos, e como pode ser feita a engenharia reversa de código existente de forma que ele possa ser analisado em forma de modelo. / Aspect‐Oriented Software Development (AOSD) is increasingly being considered a way to solve several problems in conventional programming methods, particularly in systems with crosscutting concerns. The popularization of this technology brings the need for methodologies and tools to ease its use, such as refactorings that take into account its characteristics. However modeling techniques available for AOSD are not maturing at the same rate as implementation techniques. Thus, in order to be able to devise automatic mechanisms that deal with separation of concerns, it is first necessary to verify if existing modeling techniques support that. In this work, we propose an adaptation of the Theme modeling approach, so that it represents aspect‐oriented systems more closely, especially those using the AspectJ language. This technique is used to demonstrate a few ways of detecting bad smells in aspect‐oriented systems. It is also shown how this model can be used as a basis for the automatic generation of aspectoriented code, and how existing code can be reverse‐engineered so that its model can be analyzed.

Sistemas de software bem modularizados podem trazer diversos benefícios como reu- sabilidade, compreensão, adaptabilidade, manutenibilidade, entre outros. O conceito de separação de interesses está diretamente ligado à ideia de modularização e consiste na capacidade de manter cada interesse em sua própria unidade modular. Um interesse pode estar relacionado tanto a requisitos funcionais como não-funcionais e em diferentes níveis de abstração. Algumas das técnicas que têm sido utilizadas para modularização de interes- ses são a Programação Orientada a Aspectos (POA) e Refatoração. Entretanto, a maioria das propostas de refatoração que envolvem a POA possui limitações para a modularização de interesses transversais: muitas delas são de granularidade fina; algumas são definidas imprecisamente e possuem sobreposição de intenções. A seleção e composição de tais refatorações para a modularização de interesses é uma tarefa difícil e não-trivial, além de variar em cada contexto específico, o que dificulta o reuso. Algumas das propostas de refatorações são voltadas especialmente para interesses transversais, no entanto possuem um nível de abstração pouco elevado e encontram-se acopladas a mecanismos específicos de linguagens de programação OO e OA. Adicionalmente, a aplicação de refatorações deve ser planejada e acompanhada sistematicamente durante o desenvolvimento e manu- tenção de um software, pois envolve alocação de recursos e avaliação de custo/benefício. O objetivo deste trabalho é apresentar um método de refatoração para modularização de interesses transversais, através de refatorações de granularidade alta, baseado em padrões recorrentes de estruturas transversais (chamados de sintomas). Além disso, como parte do método, propõem-se algoritmos para análise de impacto a fim de apoiar desenvolve- dores no processo decisório de aplicação de refatorações candidatas. Inicialmente, dois estudos bibliográficos foram conduzidos: o primeiro sobre propostas de refatorações que envolvem aspectos e o segundo sobre trabalhos de medição de interesses. Dois estudos de caso foram realizados totalizando 22 interesses de dois sistemas alvos. Este trabalho de avaliação possibilitou uma análise quantitativa e qualitativa dos resultados onde foi possível verificar a aplicabilidade do proposta. / Well-modularized software systems can bring several benefits such as reuse, com- prehension, adaptability, maintainability, among others. The concept of separation of concerns refers to the idea of modularisation, which consists on the ability to keep every concern in its own modular unit. A concern can refer to functional and non-functional requirements and can also be in different abstraction levels. Some of the techniques which have been applied for crosscutting concerns modularization are Aspect-Oriented Programming (AOP) and Refactoring. However, most of the aspect-oriented refactor- ings have limitations regarding the modularisation of crosscutting concerns. A number of them presents fine-grained transformations. While some of them are well-documented catalogues, a number of them are defined imprecisely, addressing the same situation and having overlapping intentions. They do not allow the designer to holistically reason about the elements involved in a crosscutting concern. It becomes difficult and non-trivial to choose a set of fine-grained refactorings and organize them in a feasible order to achieve the concern modularisation in a specific context. Some of the refactoring techniques are particularly focused on crosscutting concerns, however they are not placed in a suf- ficient abstraction level. Moreover they are coupled to specific OO and AO language mechanisms. Additionally, the application of refactorings should be planned and realized systematically during software development and maintenance since it involves resource allocation and tradeoff analysis. The goal of this work is to present a refactoring method for crosscutting concerns modularisation, through coarse-grained refactorings based on recurring patterns of crosscutting shapes (called symptoms). Also, as part of the method, algorithms for change-impact analysis are proposed in order to support developers during the decision process of the application of refactoring candidates. Initially, two biblio- graphic studies were made: the first one about refactoring approaches which involve as- pects, and the second one about concern measurement techniques. Two case studies were carried out totalizing 22 concerns of two target systems. This evaluation work allowed a quantitative and qualitative analysis of the results. Thus it was possible to verify the applicability of our approach.

Diversas refatorações têm sido propostas nos últimos anos para os mais variados paradigmas de programação, dentre eles o orientado a objetos e o orientado a aspecto. Seus impactos em atributos de qualidade são diversos, porém nem sempre a descrição original da refatoração apresenta todos os impactos que ela pode ter. Assim, é importante definir métodos de avaliação de refatorações para obter seus impactos em diferentes atributos de qualidade. A literatura apresenta trabalhos que utilizam métricas de software para fazer isso através de medições antes e depois de refatorar o código, porém este tipo de avaliação não permite obter conclusões válidas para todos os contextos em que a refatoração for aplicada. Outros trabalhos obtêm impactos abrangentes de refatorações orientadas a objetos, porém não foram encontrados métodos aplicáveis a refatorações orientadas a aspectos. Assim, este trabalho propõe uma forma de avaliar refatorações orientadas a aspectos para obter impactos abrangentes de sua aplicação, definindo um processo para avaliar refatorações orientadas a aspectos através do uso de métricas. Ele divide as etapas da refatoração em alterações pontuais e mede o impacto dessas alterações nos valores de um conjunto de métricas. O processo é usado para avaliar um conjunto de refatorações existentes na literatura definidas com o objetivo de extrair interesses transversais para aspectos. Para isso, são usados como critério de avaliação métricas para medir separação de interesses, tamanho, acoplamento e coesão do software. Como resultado, tem-se o impacto da refatoração em cada uma das métricas selecionadas, o que permite saber como o código será alterado antes mesmo de aplicar a refatoração. / Several software refactorings have been proposed on the last years for different programming paradigms, like object-oriented and aspect-oriented. They have several impacts on quality attributes, but their descriptions don’t describe all of these impacts, so it is important to have methods to assess refactorings to get their impacts on different quality attributes. Some papers apply software metrics on code before and after using the refactoring, but this kind os assessment avoids getting valid conclusions for all contexts where the refactoring can be used. Other papers propose assessment methods that get general conclusions for object-oriented refactorings, but no methods were found for assessing aspect-oriented refactorings. This work presents a process to assess aspect-oriented refactorings using software metrics to get their impacts on different quality attributes. It splits the refactoring steps into basic changes and measures the effects of these changes on some metrics. The process is used to assess some aspect-oriented refactorings for extracting crosscutting concerns into aspects, having as criteria software metrics to measure separation of concerns, size, coupling and cohesion. As result, we have the impact of the refactoring on each of the metric chosen, and know the consequences of the refactoring on the code before applying it.

The latest versions of AspectJ { the most popular aspect oriented extension for Java { must cope with complex changes that occurred in the Java type system, specially with the parametric polymorphism which aims to improve the type safety and the readability of the source code. However, for legacy and non-generic constructions to take advantage of this pervasive feature, they must be migrated to explicitly supply actual type parameters in both declarations and instantiations of generic classes. Even though the type systems of Java and AspectJ were designed to support this kind of migration in a gradual way, this process is somewhat complex and error prone. The reason behind this assertion is that actual type parameters must be inferred to remove as much unsafe downcasts as possible without a ecting the original semantics of the program. Therefore, tools are essential to minimize the e ort of a manual application of the refactoring steps and to prevent the introduction of new errors. Since current automated solutions focus only on Java programs, they do not consider the use of aspects to encapsulate crosscutting concerns. Thus, this dissertation proposes a novel collection of inference rules to derive type constraints for the polymorphic version of AspectJ. These rules were used together with an existing generic migration algorithm to enable the conversion of non-generic legacy code to add actual type parameters in both Java and AspectJ languages.

Submitted by Lucelia Lucena (lucelia.lucena@ufpe.br) on 2015-03-09T17:44:49Z No. of bitstreams: 2 DISSERTAÇÃO Jefferson Rodrigues de Almeida.pdf: 4623062 bytes, checksum: f4cfaea650da4ae73310745aa4b92435 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-09T17:44:49Z (GMT). No. of bitstreams: 2 DISSERTAÇÃO Jefferson Rodrigues de Almeida.pdf: 4623062 bytes, checksum: f4cfaea650da4ae73310745aa4b92435 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014-03-12 / FACEPE / Linhas de produtos de software estão emergindo como um paradigma de desenvolvimento viável e como um importante aliado que permite às empresas realizar melhorias de ordem de magnitude em tempo de mercado, custo, produtividade, qualidade e outros direcionadores de negócio. No entanto, a evolução de uma linha de produtos é arriscada, porque pode afetar muitos produtos e seus respectivos clientes. Neste contexto, ao evoluir uma linha de produtos para introduzir novas funcionalidades ou para melhorar a sua concepção, é importante garantir que os produtos existentes tenham o mesmo comportamento após a evolução. Ferramentas típicas de refatoração não podem garantir a preservação de comportamento dos produtos, porque o contexto de linha de produtos vai além de código. As linhas de produtos abrangem artefatos adicionais, tais como modelo de features e modelo de configurações. Além disso, geralmente tem que lidar com um conjunto de artefatos alternativos que não constituem um programa bem-formado. Portanto, ferramentas de refatoração existentes podem introduzir mudanças comportamentais ou invalidar configurações de produtos. Analisar essas evoluções de artefatos manualmente podem gastar muito tempo e levar a defeitos, comprometendo os benefícios de linhas de produtos de software acima mencionados. Na literatura, encontramos algumas abordagens de força bruta que se movem na direção de superar esses desafios. Elas implementam aproximações práticas de uma teoria de refinamento de linhas de produtos de software. No entanto, elas são imprecisas e gastam um tempo substancial para verificar incompatibilidades comportamentais entre as evoluções. Em contraste, uma alternativa otimizada foca na verificação de compatibilidade comportamental apenas das classes modificados durante a evolução. Isto leva a uma redução no tempo, fazendo com que a abordagem seja mais rápida quando comparado com outras abordagens propostas. Este procedimento melhora o desempenho, mas por outro lado, diminui a precisão. Portanto, neste trabalho, propomos estratégias para aumentar a precisão dessas abordagens otimizadas. Primeiramente implementados uma estratégia ao qual analisa as classes em uma hierarquia mais próxima do usuário, o que pode melhor determinar se a evolução preserva comportamento. Além disso, integramos uma nova ferramenta de geração de teste para o nosso conjunto de ferramentas, que tem uma heurística eficiente para orientar a sua busca por testes de maior qualidade. Neste trabalho, nós combinamos essas duas referidas abordagens com duas ferramentas de teste e fazemos comparações em relação ao desempenho e precisão. Elas são avaliadas em cenários concretos de evolução de duas linhas de produtos. A primeira linha de produtos gera testes funcionais a partir de especificações de casos e a segunda gerencia mídia em dispositivos móveis. Como resultado, nossas estratégias descobriram que algumas transformações introduziram mudanças comportamentais. Além disso, melhorou o desempenho e alcançou precisões mais elevadas.

Made available in DSpace on 2014-06-12T16:01:35Z (GMT). No. of bitstreams: 1 license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2012 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Desenvolvedores evoluem linhas de produtos de software (LPSs) manualmente ou usando Ferramentas típicas de refatoração de programas. No entanto, quando a evolução de uma Linha de produtos é feita para introduzir novas características, ou para melhorar o seu projeto, é importante ter a certeza de que o comportamento dos produtos existentes não é modificado. Programas típicos de refatoração de software não podem garantir isso porque o contexto de LPS vai além de código, e outros tipos de artefatos de código, e envolve artefatos adicionais, tais como modelos de feature e configuration knowledge. Além disso, em uma LPS, normalmente temos que lidar com um conjunto de possíveis artefatos de código-fonte alternativos que não constitui um programa bem formado. Como resultado, mudanças manuais e ferramentas de refatoração de software existentes podem introduzir mudanças comportamentais ou invalidar configurações de produtos existentes. Para evitar isso, propomos abordagens e implementamos ferramentas para tornar a evolução de linhas de produtos mais segura; essas ferramentas verificam se transformações em LPS são refinamentos no sentido de que preservam o comportamento dos produtos originais da LPS. Elas implementam aproximações diferentes e práticas de uma definição formal de refinamento de LPS. Avaliamos as abordagens em cenários concretos de evolução de LPS, onde o comportamento do produto existente deve ser preservado. No entanto, nossas ferramentas constataram que algumas transformações introduziram mudanças comportamentais. Além disso, avaliamos refinamentos defeituosos, e o conjunto de ferramentas detectou as mudanças de comportamento.