Paradigmas e técnicas de desenvolvimento como a programação Orientada a Objetos (OO) e a programação Orientada a Aspectos (OA) procuram melhorar os níveis de reuso e manutenibilidade na produção de software. Contudo, com a introdução de mecanismos com maior poder de expressividade e, consequentemente, a possível introdução de novos tipos de defeitos, a utilização de linguagens OO e OA pode se tornar um obstáculo ao invés de um auxílio ao desenvolvimento de software. Para lidar com esse problema, nesta dissertação é proposta uma abordagem de teste estrutural de integração para programas orientados a objetos e a aspectos implementados em Java e AspectJ. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java { chamado Grafo Def-Uso Contextual (ou Contextual Def-Use graph) - que é uma abstração formada pela integração dos grafos Def-Uso Orientados a Aspectos (AODU) da unidade sob teste com todas as unidades que interagem direta ou indiretamente com ela até um nível de profundidade de interação máximo ou definido pelo testador. São defiidos três critérios de teste: todos-nós-integrados-Nd, todas-arestas-integradas-Nd e todos-usos-integrados-Nd. Para automatizar o uso do modelo e critérios propostos, a ferramenta JaBUTi/AJ foi estendida. Exemplos de usos são discutidos e, por meio de um estudo experimental, uma análise de aplicabilidade da abordagem proposta é apresentada / Development paradigms and techniques such as Object-Oriented (OO) programming and Aspect-Oriented (AO) programming aim at improving reuse levels and maintenability in the software production. However, due to the introduction of mechanisms to support a greater power of expressiveness and, consequently, possible introduction of new type of faults, the use of OO and AO languages might become an obstacle instead of a benefit in the software development. To deal with these problems, in this dissertation is presented an integration structural testing approach for objectand aspect-oriented software based on Java and AspectJ. It is defined a control- and data- ow model based on Java bytecode { called Contextual Def-Use graph { that is an abstraction composed by the integration of Aspect-Oriented Def-Use graphs (AODU) of the unit under testing with the units triggered by the execution of the unit under testing considering either a maximum interaction depth level or an interaction depth level previously defined by the tester. Three testing criteria are also defined: all-integrated-nodes-Nd, all-integrated-edges-Nd and all-integrated-uses-Nd. To automate the use of the model and the testing criteria, the JaBUTi/AJ tool was extended. Usage examples are discussed to explain the approach and an exploratory study is conducted to evaluate the applicability of the proposed approach

Paradigmas e técnicas de desenvolvimento como a programação Orientada a Objetos (OO) e a programação Orientada a Aspectos (OA) procuram melhorar os níveis de reuso e manutenibilidade na produção de software. Contudo, com a introdução de mecanismos com maior poder de expressividade e, consequentemente, a possível introdução de novos tipos de defeitos, a utilização de linguagens OO e OA pode se tornar um obstáculo ao invés de um auxílio ao desenvolvimento de software. Para lidar com esse problema, nesta dissertação é proposta uma abordagem de teste estrutural de integração para programas orientados a objetos e a aspectos implementados em Java e AspectJ. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java { chamado Grafo Def-Uso Contextual (ou Contextual Def-Use graph) - que é uma abstração formada pela integração dos grafos Def-Uso Orientados a Aspectos (AODU) da unidade sob teste com todas as unidades que interagem direta ou indiretamente com ela até um nível de profundidade de interação máximo ou definido pelo testador. São defiidos três critérios de teste: todos-nós-integrados-Nd, todas-arestas-integradas-Nd e todos-usos-integrados-Nd. Para automatizar o uso do modelo e critérios propostos, a ferramenta JaBUTi/AJ foi estendida. Exemplos de usos são discutidos e, por meio de um estudo experimental, uma análise de aplicabilidade da abordagem proposta é apresentada / Development paradigms and techniques such as Object-Oriented (OO) programming and Aspect-Oriented (AO) programming aim at improving reuse levels and maintenability in the software production. However, due to the introduction of mechanisms to support a greater power of expressiveness and, consequently, possible introduction of new type of faults, the use of OO and AO languages might become an obstacle instead of a benefit in the software development. To deal with these problems, in this dissertation is presented an integration structural testing approach for objectand aspect-oriented software based on Java and AspectJ. It is defined a control- and data- ow model based on Java bytecode { called Contextual Def-Use graph { that is an abstraction composed by the integration of Aspect-Oriented Def-Use graphs (AODU) of the unit under testing with the units triggered by the execution of the unit under testing considering either a maximum interaction depth level or an interaction depth level previously defined by the tester. Three testing criteria are also defined: all-integrated-nodes-Nd, all-integrated-edges-Nd and all-integrated-uses-Nd. To automate the use of the model and the testing criteria, the JaBUTi/AJ tool was extended. Usage examples are discussed to explain the approach and an exploratory study is conducted to evaluate the applicability of the proposed approach

The rapid increase in mobile malware and deployment of over-privileged applications over the years has been of great concern to the security community. Encroaching on user’s privacy, mobile applications (apps) increasingly exploit various sensitive data on mobile devices. The information gathered by these applications is sufficient to uniquely and accurately profile users and can cause tremendous personal and financial damage. On Android specifically, the security and privacy holes in the operating system and framework code has created a whole new dynamic for malware and privacy exploitation. This research work seeks to develop novel analysis techniques that monitor Android applications for possible unwanted behaviors and then suggest various ways to deal with the privacy leaks associated with them. Current state-of-the-art static malware analysis techniques on Android-focused mainly on detecting known variants without factoring any kind of software obfuscation. The dynamic analysis systems, on the other hand, are heavily dependent on extending the Android OS and/or runtime virtual machine. These methodologies often tied the system to a single Android version and/or kernel making it very difficult to port to a new device. In privacy, accesses to the database system’s objects are not controlled by any security check beyond overly-broad read/write permissions. This flawed model exposes the database contents to abuse by privacy-agnostic apps and malware. This research addresses the problems above in three ways. First, we developed a novel static analysis technique that fingerprints known malware based on three-level similarity matching. It scores similarity as a function of normalized opcode sequences found in sensitive functional modules and application permission requests. Our system has an improved detection ratio over current research tools and top COTS anti-virus products while maintaining a high level of resiliency to both simple and complex obfuscation. Next, we augment the signature-related weaknesses of our static classifier with a hybrid analysis system which incorporates bytecode instrumentation and dynamic runtime monitoring to examine unknown malware samples. Using the concept of Aspect-oriented programming, this technique involves recompiling security checking code into an unknown binary for data flow analysis, resource abuse tracing, and analytics of other suspicious behaviors. Our system logs all the intercepted activities dynamically at runtime without the need for building custom kernels. Finally, we designed a user-level privacy policy enforcement system that gives users more control over their personal data saved in the SQLite database. Using bytecode weaving for query re-writing and enforcing access control, our system forces new policies at the schema, column, and entity levels of databases without rooting or voiding device warranty.

Aspect-Oriented Software Development (AOSD) is a new approach that addresses limitations inherent in conventional programming, especially the principle of separation of concerns by emphasizing the encapsulation and modularization of crosscutting concerns through a new abstraction, the "aspect." Aspect-oriented programming is an emerging AOSD programming paradigm that focuses on the modularization of concerns as appropriate for the host language and providing a mechanism for describing concerns that crosscut each other by congealing into a single textual structure behavior that conventional programming would otherwise distribute throughout the code. AspectJ is the most widely used aspect-oriented programming language to date and provides an extension of the Java language that includes several new concepts and constructs that differ from those in procedural and object-oriented programs. These include join points, pointcuts, advice, inter-type declarations, introduction and aspects. In AspectJ, as well as other aspect-oriented programming languages, "aspects" package pointcuts and advice into functional units in much the same way that object-oriented programming uses classes to package fields and methods into cohesive units but they offer a unique set of problems. Software inspections are considered a software engineering "best practice" for ensuring quality, but the introduction of new aspect-oriented programming language mechanisms drives the need for them to be tailored in a similar manner to how they were tailored to support object-oriented programs and the procedural programs. The identification of faults unique to aspect-oriented programming allowed for the design of an aspect fault model and the associated software inspection checklists criteria that provide a description of the typical faults associated with aspects and the clues that aid in betraying their presence. The proposed methodology for this research entailed a mixed methods approach based on a combination of descriptive and exploratory research methodologies using a normative case study. The proposed methodology resulted in the development of an understanding of the AspectJ primitive pointcut construct, identification of the typical faults associated with this construct and the subsequent development of a fault model, a set of programming rules and tailored software inspection checklist. A case study was conducted comparing defects detected by an inspection checklist tailored for AspectJ with one that was not tailored. The results of the case study demonstrated using software inspection checklists not tailored would result in many faults unique to aspect-oriented programming going undetected.

Aspects are units of aspect oriented programming developed for influencing the software behavior. In order to use an aspect confidently in any software, first it should be verified. For verification of an aspect, the mock classes for the original software should be prepared. These mock classes are a model of the aspect environment which the aspect is woven. In this study, considering that there are not enough tools for supporting the aspect oriented programming developers, we have developed a tool for enabling aspect verification and unit testing. The tool enables verification by generating the general environment of the aspect. By this tool the users are ensured to focus on the verification of aspects isolated from woven software.

La programación orientada a aspectos (POA) es un paradigma de programación. Permite encapsular funcionalidad que se encuentra dispersa en un sistema. Para ello utiliza pointcuts, predicados que definen eventos del programa, y advices, el código que es ejecutado en los eventos definidos por un pointcut. Un aspecto es una entidad que agrupa pointcuts y advices. AspectJ es un lenguaje de programación para POA. Está diseñado como una extensión de Java, de forma que cualquier programa Java es también un programa AspectJ válido. Además del compilador oficial del proyecto AspectJ existen otros, de los cuales AspectBench Compiler (abc) es el más avanzado. La reentrancia de aspectos ocurre cuando la ejecución de un aspecto desencadena nuevamente su propia ejecución; produciéndose bucles infinitos. Actualmente la reentrancia se soluciona utilizando chequeos y patrones adhoc. La introducción de niveles de ejecución evita la reentrancia de aspectos. La ejecución del programa se separa en distintos niveles. Por defecto, la computación base ocurre en el nivel 0, mientras que los aspectos que observan esta ejecución se ubican en el nivel 1. La ejecución en el nivel 1 sólo puede ser observada desde el nivel 2, y así sucesivamente. Esta estructura para la ejecución de los programas soluciona casi todos los casos de reentrancia. Para el caso faltante, se utiliza un mecanismo adicional de control de reentrancia. Para esta memoria se extendió el compilador abc para incorporar una adaptación de niveles de ejecución. El lenguaje soportado por el compilador extendido incorpora nueva sintaxis para ello. Y los programas compilados contienen rutinas adicionales que agregan la estructura de niveles de ejecución y el control de reentrancia. Además, es posible controlar el nivel de ejecución en que se ejecutará una expresión, si fuese necesario. Se hicieron distintas pruebas para validar el trabajo realizado. Se confeccionaron tests para las distintas funcionalidades que, en conjunto, implementan niveles de ejecución. También se verificó la correcta compilación y ejecución de AJHotDraw, un framework para interfaces gráficas de programas de dibujo. Adicionalmente se probó el compilador con RacerAJ, una herramienta para la detección de data races implementada en AspectJ. RacerAJ es de interés porque incorpora pointcuts para evitar la ocurrencia de reentrancia de aspectos; removidos estos pointcuts, el programa funciona correctamente al ser compilado con esta versión extendida de abc. Además se realizó un ligero análisis de performance para medir el impacto en los programas compilados. Para ello se utilizó una suite de benchmarks para AspectJ. Se compararon los tiempos de ejecución logrados al utilizar el compilador desarrollado y la versión original.

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.

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.

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.

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