This study investigated the need for a pointcut for parallelizable loops in an aspect-oriented programming environment. Several prototype solutions exist for loop pointcuts, but the solutions are not very granular. In particular, they are not able to differentiate between loops that are parallelizable and those that are not. Being able to identify parallelizable loops automatically, as part of an aspect-oriented compiler's weaving process, is particularly important because (1) manually identifying parallelizable loops is known to be a difficult problem and (2) aspectizing parallelized loops can lead to a reduction in code tangling and an increase in separation of concerns. This paper describes the concepts behind the loop-pointcut problem. It then describes the approach used in this study for implementing a solution in the form of an aspect-oriented Java compiler with a parallelizable loop pointcut. Identifying parallelizable loops is known to be a difficult problem, and as such, this study's parallelizable loop pointcut implements a heuristic solution. The pointcut identifies many parallelizable loops as being parallelizable, but in erring on the side of conservatism, there are some parallelizable loops that the pointcut is unable to identify as parallelizable. To test the parallelizable-loop pointcut, the pointcut was applied to a benchmark set of parallelizable programs. There were two versions of each benchmark program - (1) an aspect-oriented version, where the aspect-oriented compiler's weaver added the multi-threading functionality, and (2) a non-aspect-oriented version, where the benchmark program's source code directly implemented the multi-threading functionality. For each benchmark program, the output from the aspect-oriented version was compared to the output from the non-aspect-oriented version. The study found that each loop that was deemed parallelizable by the aspect-oriented benchmark program was executed in parallel (with multiple threads) by both versions of the program - the aspect-oriented version and the non-aspect-oriented version. There were some loops in the non-aspect-oriented benchmark programs that were deemed parallelizable and executed in parallel, but those same loops were deemed non-parallelizable by their associated aspect-oriented benchmark program. This discrepancy is explained by the study's conservative approach to identifying loops as parallelizable.

Uma das questões mais importantes nas linguagens e arcabouços orientados a aspectos atuais é a expressividade da linguagem ou mecanismo de definição de pointcuts. A expressividade de uma linguagem de pointcuts impacta diretamente a qualidade dos pointcuts, uma propriedade que pode ser decisiva para a eficácia das implementações de aspectos. Neste trabalho, propomos os seletores de pontos de junção como um mecanismo de extensão simples para enriquecer linguagens de pointcut atuais com elementos que fazem o papel de \"novos pointcuts primitivos\". Os seletores de pontos de junção permitem a criação de pointcuts com maior valor semântico. Apesar de existirem mecanismos similares em algumas abordagens existentes, o conceito subjacente não foi claramente definido ou completamente explorado. Apresentamos também uma arquitetura simples para a adição de seletores de pontos de junção a um arcabouço orientado a aspectos existente, e mostramos exemplos do uso de seletores para melhorar a qualidade de pointcuts e facilitar o desenvolvimento de aspectos. / One of the main issues in modern aspect-oriented programming languages and frameworks is the expressiveness of the pointcut language or mechanism. The expressiveness of pointcut languages directly impacts pointcut quality, a property that can be decisive for the effectiveness of aspect implementations. In this work we propose join point selectors as a simple extension mechanism for enriching current pointcut languages with constructs that play the role of \"new primitive pointcuts\". Join point selectors allow the creation of pointcuts with greater semantic value. Although similar mechanisms can be found in some existing approaches, the underlying concept has not yet been clearly defined nor fully explored. We also present a simple architecture for adding join point selectors to an existing aspect-oriented framework, and show examples of usage of join point selectors to enhance the quality of pointcuts and make aspect development easier.

Uma das questões mais importantes nas linguagens e arcabouços orientados a aspectos atuais é a expressividade da linguagem ou mecanismo de definição de pointcuts. A expressividade de uma linguagem de pointcuts impacta diretamente a qualidade dos pointcuts, uma propriedade que pode ser decisiva para a eficácia das implementações de aspectos. Neste trabalho, propomos os seletores de pontos de junção como um mecanismo de extensão simples para enriquecer linguagens de pointcut atuais com elementos que fazem o papel de \"novos pointcuts primitivos\". Os seletores de pontos de junção permitem a criação de pointcuts com maior valor semântico. Apesar de existirem mecanismos similares em algumas abordagens existentes, o conceito subjacente não foi claramente definido ou completamente explorado. Apresentamos também uma arquitetura simples para a adição de seletores de pontos de junção a um arcabouço orientado a aspectos existente, e mostramos exemplos do uso de seletores para melhorar a qualidade de pointcuts e facilitar o desenvolvimento de aspectos. / One of the main issues in modern aspect-oriented programming languages and frameworks is the expressiveness of the pointcut language or mechanism. The expressiveness of pointcut languages directly impacts pointcut quality, a property that can be decisive for the effectiveness of aspect implementations. In this work we propose join point selectors as a simple extension mechanism for enriching current pointcut languages with constructs that play the role of \"new primitive pointcuts\". Join point selectors allow the creation of pointcuts with greater semantic value. Although similar mechanisms can be found in some existing approaches, the underlying concept has not yet been clearly defined nor fully explored. We also present a simple architecture for adding join point selectors to an existing aspect-oriented framework, and show examples of usage of join point selectors to enhance the quality of pointcuts and make aspect development easier.

In dynamic pointcut-advice join point models of Aspect-Oriented Programming (AOP), join points are typically selected and advised independently of each other. That is, the relationships between join points are not considered in join point selection and advice. But these inter-relationships are key to the designation and advice of arbitrary pieces of code when modularizing concerns such as exception handling and synchronization. Without a mechanism for associating join points, one must instead refactor (if possible) into one method the two or more related join points that are to be advised together. In practice, join points are often not independent. Instead, they form part of a higher-level operation that implements the intent of the developer (e.g. managing a resource). This relationship should be made more explicit. We extend the dynamic pointcut-advice join point model to make possible the designation, reication, and advice of interrelated join points. The Transactional Pointcut (transcut), which is a realization of this extended model, is a special join point designator that selects sets of interrelated join points. Each match of a transcut is a set of join points that are related through control ow, dataow, or both. This allows transcuts to dene new types of join points (pieces of computation) by capturing the key points of a computation and to provide effective access for their manipulation (i.e. advice). Essentially, transcuts almost eliminate the need for refactoring to expose join points, which is shown by others to have a signicant negative effect on software quality. The transcut construct was implemented as an extension to the AspectJ language and integrated into the AspectBench compiler. We used transcuts to modularize the concern of exception handling in two real-world software systems. The results show that transcuts are effective in designating target join points without unnecessary refactorings, even when the target code is written obliviously to the potential aspectization.

No description available.

Made available in DSpace on 2014-12-17T15:47:59Z (GMT). No. of bitstreams: 1 EbertonSM_DISSERT.pdf: 4801479 bytes, checksum: 4ff5d2fe556a6d3554decf638f20261c (MD5) Previous issue date: 2010-08-02 / Aspect-Oriented Software Development (AOSD) is a technique that complements the Object- Oriented Software Development (OOSD) modularizing several concepts that OOSD approaches do not modularize appropriately. However, the current state-of-the art on AOSD suffers with software evolution, mainly because aspect definition can stop to work correctly when base elements evolve. A promising approach to deal with that problem is the definition of model-based pointcuts, where pointcuts are defined based on a conceptual model. That strategy makes pointcut less prone to software evolution than model-base elements. Based on that strategy, this work defines a conceptual model at high abstraction level where we can specify software patterns and architectures that through Model Driven Development techniques they can be instantiated and composed in architecture description language that allows aspect modeling at architecture level. Our MDD approach allows propagate concepts in architecture level to another abstraction levels (design level, for example) through MDA transformation rules. Also, this work shows a plug-in implemented to Eclipse platform called AOADLwithCM. That plug-in was created to support our development process. The AOADLwithCM plug-in was used to describe a case study based on MobileMedia System. MobileMedia case study shows step-by-step how the Conceptual Model approach could minimize Pointcut Fragile Problems, due to software evolution. MobileMedia case study was used as input to analyses evolutions on software according to software metrics proposed by KHATCHADOURIAN, GREENWOOD and RASHID. Also, we analyze how evolution in base model could affect maintenance on aspectual model with and without Conceptual Model approaches / O Desenvolvimento de Software Orientado a Aspectos (DSOA) ? uma t?cnica que complementa o Desenvolvimento de Software Orientado a Objetos (DSOO) modularizando diversos conceitos que as abordagens para suporte ao DSOO n?o conseguiam modularizar adequadamente. No entanto, o estado da arte atual do DSOA sofre com a evolu??o de software, principalmente porque as defini??es de aspectos podem deixar de funcionar corretamente quando elementos do Modelo Base evoluem. Uma abordagem promissora para tratar este problema ? a defini??o de pontos de corte (pointcuts) baseados em modelos (model based-pointcuts), onde pontos de corte s?o definidos em termos de elementos de um Modelo Conceitual que s?o menos suscept?veis a evolu??o que elementos do Modelo Base. Com base nessa estrat?gia, este trabalho define um Modelo Conceitual em um alto n?vel de abstra??o onde se podem definir padr?es de software e de arquiteturas que atrav?s de t?cnicas de Desenvolvimento Dirigido a Modelos (Model Driven Development -MDD) podem ser instanciados e compostos em linguagens de descri??o arquitetural que suportem a modelagem de aspectos em n?vel de arquitetura. A abordagem MDD empregada permite ainda a propaga??o de conceitos descritos no Modelo Conceitual para outros n?veis de abstra??es como o de projeto com o uso de regras de transforma??o MDA (Model Driven Architecture). Este trabalho tamb?m mostra o plug-in para a plataforma Eclipse chamado de AOADLwithCM que foi implementado para dar suporte ao processo de desenvolvimento abordado. Esse plug-in foi utilizado para implementar um estudo de caso baseado no Sistema MobileMedia. Tal estudo de caso ilustra passo-a-passo a t?cnica que utiliza um Modelo Conceitual no DSOA para minimizar problemas de evolu??o (mais especificamente a Fragilidade de Pontos de Corte). O MobileMedia tamb?m foi usado como fonte para an?lise da abordagem sob m?tricas de software propostas por KHATCHADOURIAN, GREENWOOD e RASHID, e sob a perspectiva de manutenabilidade de software com e sem o Modelo Conceitual