A injeção de falhas permite acelerar a ocorrência de erros em um sistema para que seja possível a validação de seu comportamento sob falhas, assim como a avaliação do impacto dos mecanismos de detecção e remoção de erros no desempenho do sistema. Abordagens que facilitem o desenvolvimento de injetores vêm sendo buscadas com empenho, variando desde a inserção de injetores no kernel do sistema operacional até o uso de reflexão computacional para aplicações orientadas a objetos. Este trabalho explora os recursos da Programação Orientada a Aspectos como estratégia para a criação de ferramentas de injeção de falhas. A Programação Orientada a Aspectos tem como objetivo a modularização de interesses transversais, isto é, interesses que atravessam as unidades naturais de modularização. A injeção de falhas possui um comportamento que abrange os diversos módulos da aplicação alvo, afetando métodos que são executados em diversas classes em diversos pontos da aplicação. Desta forma, a injeção de falhas pode ser encapsulada sob a forma de aspectos. Para demonstrar a validade da proposta apresentada foi desenvolvida a ferramenta FICTA – Fault Injection Communication Tool based on Aspects. O objetivo é a validação de aplicações Java distribuídas, construídas sobre o protocolo UDP e que implementem mecanismos de tolerância a falhas em protocolos de camadas superiores. A importância de instrumentar um protocolo de base é justificada pelo fato da necessidade de validar aplicações, toolkits e middlewares que implementem tolerância a falhas em camadas superiores, logo, esses protocolos devem lidar corretamente com as falhas de mais baixo nível. A ferramenta abrange falha de colapso e omissão de mensagens do protocolo UDP. O uso de Programação Orientada a Aspectos na construção de FICTA resultou em uma ferramenta altamente modular, reusável e flexível, que pode ser facilmente inserida e removida da aplicação alvo, sem causar intrusividade espacial no código fonte da aplicação. / The fault injection allows us to accelerate the occurrence of failures in a system so that it is possible to validate its behavior under faults, as well as the evaluation of the impact on the mechanisms of detection and removal of failures in the performance of the system. The approaches that may facilitate the development of injectors have been searched with effort, varying from the insertion of injectors in the kernel of the operational system up to the computational reflection for object oriented applications. This work explores the resources of the Aspect Oriented Programming as a strategy to create tools of fault injection. The Aspect Oriented Programming has as its goal the modularization of the crosscutting concerns, that is to say the interests that cross the natural units of modularization. The fault injection has a behavior that covers the various modules of the target application, affecting methods that are executed in several classes of several areas of the application. Thus, the Fault Injection may be encapsulated under the form of aspects. To demonstrate the worthiness of the presented proposal, a tool called FICTA - Fault Injection Communication Tool based on Aspects, has been developed. The aim is to validate Java distributed applications built under the UDP protocol so that the fault tolerance mechanisms can be implemented in upper layers. The importance of instrumentate a protocol of base is justified by the necessity of validating applications, toolkits and middlewares that implement fault tolerance in upper layers, then, these protocols must deal correctly with the lower level faults. The tool covers crash and message omission faults of the UDP protocol. The use of Aspect Oriented Programming in the construction of FICTA resulted in a tool highly modular, reusable and flexible that may be easily inserted and removed from the target application, without causing spatial intrusiveness in the source code of the application.

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 Nayara Passos (nayara.passos@ufpe.br) on 2015-03-12T12:46:58Z No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Approved for entry into archive by Daniella Sodre (daniella.sodre@ufpe.br) on 2015-03-13T12:53:22Z (GMT) No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-13T12:53:22Z (GMT). No. of bitstreams: 2 TESE Henrique Emanuel Rabêlo.pdf: 2393775 bytes, checksum: b74f8b8b1b46d5879b334348c3110846 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014 / Design by Contract (DbC) ´e uma t´ecnica popular para desenvolvimento de programas usando especifica¸c˜oes comportamentais. Neste contexto, pesquisadores descobriram que a implementao de DbC ´e crosscutting e, portanto, sua implementa¸c˜ao ´e melhor modularizada por meio da Programa¸c˜ao Orientada a Aspectos (POA) por´em, os mecanismos de POA para dar suporte a modularide de contratos, de fato comprometem sua modularidade e entendidmento. Por exemplo, na linguagem POA AspectJ, o racioc´ınio da corretude de uma chamada de m´etodo requer uma an´alise global do programa para determinar quais advice aplicam e sobretudo o que esses advice fazem em rela¸c˜ao a implementa ¸c˜ao e checagem DbC. Al´em disso, quando os contratos so separados das classes o programador corre o risco de quebrar-los inadvertidamente. Diferentemente de uma linguagem POA como AspectJ, uma linguagem DbC preserva as principais caractersticas DbC como raciocnio modular e documenta¸c˜ao. No entanto, pr´e- e p´os-condi¸c˜oes recorrentes continuam espalhadas por todo o sistema. Infelizmente esse n˜ao o ´unico problema relacionado com modularidade que temos em linguagens DbC existentes, o seu com respectivos verificadores dinˆamicos so inconsistentes com as regras de information hiding devido a naturaze overly-dynamic na qual os contratos s˜ao checados no lado servidor. Este problema implica que durante a reportagem de erros, detalhes de implementa¸c˜ao so expostos para clientes no privilegiados. Portanto, se os programadores cuidadosamente escolherem as partes que devem ser escondidas dos clientes, durante a checagem dinˆamica de contratos, as mudanas nessas partes n˜ao deveriam afetar nem os clientes dos m´odulos nem a reportagem de erros de contratos. Neste trabalho n´os resolvemos esses problemas com AspectJML, uma nova liguagem de especifica¸c˜ao que suporta contratos crosscutting para c´odigo Java. Al´em disso, n´os demonstramos como AspectJML usa as principais caractersticas de uma linguagem DbC como racioc´ınio modular e documenta¸c˜ao dos contratos. Mais ainda, n´os mostramos como AspectJML combinado com nossa t´ecnica chamada de client-aware checking permite uma checagem dinˆamica de contratos que respeitem os princ´ıpios de information hiding em especifica¸c˜oes. Neste trabalho usamos JML para fins concretos, mas nossa solu¸c˜ao pode ser utilizadas para outras linguagems Java-likee suas respectivas linguagens DbC. Para concluir, n´os conduzimos uma avalia¸c˜ao da nossa modulariza¸c˜ao dos contratos crosscutting usando AspectJML, onde observamos que seu uso reduz o esforo de escrever pr´e- e p´os-condies, por´em com um pequeno overhead em tempo de compila¸c˜ao e instrumentação de código para checagem de contratos. / Design by Contract (DbC) is a popular technique for developing programs using behavioral specifications. In this context, researchers have found that the realization of DbC is crosscutting and fares better when modularized by Aspect-Oriented Programming. However, previous efforts aimed at supporting crosscutting contracts modularly actually compromised the main DbC principles. For example, in AspectJ-style, reasoning about the correctness of a method call may require a whole-program analysis to determine which advice applies and what that advice does relative to DbC implementation and checking. Also, when contracts are separated from classes a programmer may not know about them and may break them inadvertently. Unlike an AspectJ-like language, a DbC language keeps the main DbC principles such as modular reasoning and documentation. However, a recurrent pre- or postcondition specification remains scattered across several methods in many types. Unfortunately, this is not the only modularity problem we have with existing DbC languages. Such languages along with their respective runtime assertion checkers are inconsistent with information hiding rules because they check specifications in an overly-dynamic manner on the supplier side. This implies that during error reporting, hidden implementation details are exposed to non-privileged clients. Such details should not be used in a client’s correctness proof, since otherwise the proof would be invalidated when they change. Therefore, if programmers have carefully chosen to hide those parts “most likely” to change, most changes, in the hidden implementation details, do not affect either module clients nor DbC error reporting. In this work we solve these problems with AspectJML, a new specification language that supports crosscutting contracts for Java code. We also show how AspectJML supports the main DbC principles of modular reasoning and contracts as documentation. Additionally, we explain how AspectJML combined with our client-aware checking technique allows runtime checking to use the privacy information in specifications, which promotes information hiding. We use JML for concreteness, but the solution we propose can also be used for other Java-like languages and their respective DbC languages. To conclude, we conduct an evaluation to assess the crosscutting contract modularization using AspectJML, where we observe that its use reduces the overall design by contract code, including pre- and postconditions, but introduces a small overhead during compile time and can increase the resulting bytecode due to code instrumentation to check ordinary and crosscutting contracts

Made available in DSpace on 2014-06-12T15:54:05Z (GMT). No. of bitstreams: 2 arquivo6551_1.pdf: 2254714 bytes, checksum: 89a6702d1c801f178299f95585aac5ab (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2007 / Linha de Produtos de Software (LPS) é uma aborgadem promissora para o desenvolvimento de um conjunto de produtos focados em um segmento de mercado e desenvolvidos a partir de um conjunto comum de artefatos. Possíveis benefícios incluem reuso em larga escala e significativa melhoria em produtividade. Um problema-chave associado, no entanto, é o tratamento de estratégias de implantação, em que uma organização decide iniciar uma LPS a partir do zero, fazer bootstrap de produtos existentes em uma LPS, ou evoluir uma LPS. Em particular, no nível de implementação e de modelo de features, métodos de desenvolvimento carecem de apoio adequado para extração e evolução de LPSs. Neste contexto, apresentamos um m´etodo original provendo diretrizes concretas para extração e evolução de LPSs no nível de implementação e de modelo de features, nos quais proporciona reuso e segurança. O método primeiro faz o bootstrap da LPS e então a evolui com uma abordagem reativa. O método se baseia em uma coleção de refatoramentos tanto na implementação (refatoramentos orientados a aspectos) como no modelo de features. O método foi avaliado no domínio altamente variável de jogos móveis

Made available in DSpace on 2014-06-12T15:58:08Z (GMT). No. of bitstreams: 2 arquivo3259_1.pdf: 5762420 bytes, checksum: 0af73887e3af768529c1569155447ba5 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / FUNDAÇÃO DE APOIO AO DESENVOLVIMENTO DA UFPE / Linhas de Produtos de Software (LPS) são definidas como conjuntos de sistemas de software que atendem a um mercado especifico, que compartilham caracteristicas em comum, porem sendo suficientemente distintos entre si, e que são desenvolvidos a partir de um conjunto de artefatos reusaveis. Entre os beneficios possiveis com a implantação de LPS podemos citar o reuso em larga escala e o aumento de produtividade. Um fator-chave no desenvolvimento de uma LPS e o mecanismo utilizado para a estruturação fonte. Uma das tecnicas mais comumente utilizadas para a estruturação de variações de código e a compilação condicional, tambem chamada de pre-processamento. Apesar de ser amplamente utilizada, o uso de compilação condicional incorre em problemas de legibilidade, modularidade, manutenibilidade e qualidade. Programação Orientada a Aspectos (POA) e uma alternativa a compilação condicional para a estruturação de variações de codigo em LPS, podendo apresentar melhor legibilidade, modularidade, manutenibilidade, qualidade, entre outros fatores, do que a compilação condicional. Entretanto, o uso de AspectJ, implementação mais popular de POA sobre a linguagem Java, como mecanismo de estruturação de variações gera um overhead (aumento) sobre o tamanho final do codigo compilado. No contexto de LPS de sistemas para plataformas em dispositivos moveis, em plataformas como Java ME, que possuem restrições de memoria, esse overhead pode tornar inviavel o uso do produto final. Neste trabalho, analisamos o impacto do uso de AspectJ como mecanismo de estruturação de variações sobre o tamanho do codigo compilado e investigamos os motivos por tras deste aumento. Para tal, utilizamos o BestLap e o Juggling, duas LPS de jogos para dispositivos Java ME que possuem uma versão puramente pre-processada e uma versão hibrida, que utiliza pre-processamento e AspectJ. Utilizamos o BestLap na analise de tamanho para quanticar o overhead com dois compiladores AspectJ, o ajc e o abc. Em seguida, analisamos o codigo compilado de um subconjunto das construções As pectJ, a fim de identificar quais construções geram overhead no tamanho do codigo compilado e os motivos por tras deste overhead. Esse subconjunto consistiu de todas as construções AspectJ utilizadas na versão híbrida do BestLap e do Juggling, o ultimo utilizado apenas para a elicitação das construções analisadas. Com base nessa investigação, desenvolvemos quatro otimizações para o compilador abc que modificam o codigo compilado de certas construções visando a eliminar o overhead. Apresentamos detalhes da implementação e discutimos as pre-condições e a corretude das otimizações desenvolvidas. Em seguida, apresentamos o resultado da aplicação destas otimizações em duas LPS e discutimos como implementações diferentes, porem equivalentes, da mesma variação em AspectJ podem inviabilizar a aplicação das otimizações Por fim, para garantir que as modificações realizadas pelas otimizações não prejudiquem o desempenho, apresentamos o resultado de testes de desempenho realizados em programas AspectJ usados em benchmarks apos a aplicação das nossas otimizações

Made available in DSpace on 2014-06-12T15:58:29Z (GMT). No. of bitstreams: 2 arquivo4579_1.pdf: 1011460 bytes, checksum: 01e8646fc6f336c9eb54adf769b7baf0 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2004 / A criação de uma linguagem de programação pode ser comparada ao desenvolvimento de um sistema computacional. Sendo assim, o projeto e a implementação da linguagem devem atender a um conjunto de requisitos. Alguns deles estão relacionados às propriedades que a linguagem desenvolvida deve apresentar, como expressividade, capacidade de aprendizagem e produtividade. Outro grupo de requisitos compreende aqueles comuns ao desenvolvimento da maioria dos softwares, como extensibilidade, modularidade e reuso de código. Este segundo grupo de requisitos pode ser obtido através do uso de técnicas modernas de engenharia de software. Neste trabalho, apresentamos o desenvolvimento de uma linguagem multiparadigma modular que faz uso de programação Orientada a Objetos, design patterns e um paradigma de programação mais recente chamado Programação Orientada a Aspectos. A linguagem, que também pode ser vista como um conjunto de linguagens, é desenvolvida de maneira incremental, partindo de uma simples linguagem de expressões até linguagens mais complexas representando alguns dos mais representativos paradigmas de programação, finalizando com o desenvolvimento de linguagens multiparadigmas. Esta família de linguagens é criada através da integração de componentes que representam conceitos de programação. A modularidade obtida através do design proposto possibilita o reuso destes componentes na criação de diferentes linguagens, mesmo que pertencentes a diferentes paradigmas. Adicionalmente, é possível a evolução ortogonal das linguagens, já que a inclusão de novos conceitos é obtida através da simples inclusão dos componentes correspondentes, sem comprometer o funcionamento dos componentes já utilizados. A abordagem proposta para o design e implementação da linguagem também se mostrou bastante útil no ensino de conceitos de programação, já que oferece um ambiente uniforme e extensível para a prática e exploração dos conceitos pelos estudantes. Dessa forma, os estudantes não precisam lidar com diferentes notações e ambientes de desenvolvimento ao abordarem conceitos relacionados a diversos paradigmas

No description available.

Aspect-oriented programming is a relatively new programming paradigm and it builds on the basis of object oriented programming paradigm. It deals with those concerns that cross-cut the modularity of traditional programming mechanisms and it aims at reduction of code and to provide higher cohesion. As with any new technology aspect oriented programming provides some benefits and also there are some costs associated with it. In this thesis we have done a systematic review on aspect oriented software testing in the context of testing challenges. Detailed analysis have been made to show that how effective are the structural test techniques to handle these challenges. We have given the analysis of Aspect-oriented test techniques effectiveness, based on research literature. / Aspekt-orienterad programmering är ett relativt nytt programmering paradigm och det bygger på grundval av objektorienterad programmering paradigm. Det handlar om de farhågor som KORSSKUREN den modularitet av traditionell programmering mekanismer och det syftar till minskning av kod och för att ge högre sammanhållning. Som med all ny teknik aspekt-orienterad programmering ger vissa fördelar och det finns vissa kostnader associerade med den. I denna avhandling har vi gjort en systematisk översyn av aspekt orienterad mjukvara testning i samband med provning utmaningar. Detaljerad analys har gjorts för att visa att hur effektiva är de strukturella provmetoder för hantera dessa utmaningar. Vi har gett en analys av Aspect-oriented testa tekniker effektivitet, baserade på forskningslitteratur. / FOLKPARKSVAGEN 18 Room 03 Ronneby 37240 Sweden Mobile Number Kashif 073-9124604, Amar 073-6574048