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

Made available in DSpace on 2014-06-12T15:58:29Z (GMT). No. of bitstreams: 2 arquivo4584_1.pdf: 1969312 bytes, checksum: ebc699427e4ae5f379c7d0e4b5d9b28f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2004 / Os dispositivos computacionais estão se tornando ubíquos. Com um celular, atualmente, podemos acessar e manipular informação praticamente em qualquer lugar e a qualquer instante. Neste cenário de computação ubíqua, tem-se exigido que tais sistemas sejam adaptativos, ou seja, tenham a capacidade de se adaptar em decorrência de mudanças no contexto em que estão inseridos. É importante destacar, porém, que a adaptabilidade adiciona certa complexidade ao desenvolvimento de aplicações. Um dos problemas é que a implementação de comportamentos adaptativos em muitos casos se entrelaça com outras preocupações da aplicação, como apresentação, negócio e dados, levando a problemas de legibilidade que podem prejudicar a manutenabilidade do código. A programação orientada a aspectos pode ser usada para facilitar a resolução de problemas relacionados a código entrela¸cado, e dar suporte ao desenvolvimento de programas adaptativos, e ao mesmo tempo adaptáveis (fáceis de modificar) com bons níveis de qualidade e produtividade. Essa dissertação mostra como podemos usar aspectos, em especial em AspectJ, para estruturar aplicações adaptativas, minimizando dessa forma o entrelaçamento de código. AspectJ é uma linguagem orientada a aspectos, de propósito geral, e que estende a linguagem Java. Ela é voltada `a separação de preocupações. Em nosso trabalho ela é utilizada para promover a separação da preocupação adaptabilidade , obtendo-se assim uma implementação modular. Através do uso dessa linguagem, identificamos boas práticas para a estruturação de aplicações adaptativas, as quais foram resumidas em um padrão denominado Adaptability Aspects. Escolhemos a plataforma Java 2 Micro Edition para implementar várias preocupações relativas a adaptabilidade, principalmente pelo fato de ser uma tecnologia destinada a dispositivos ubíquos e com recursos limitados. Al´em de AspectJ, analisamos também uma outra abordagem para a estruturação de aplicações adaptativas: o uso do estilo arquitetural denominado Adaptive Object- Models . Verificamos a partir dessa análise que ele poderia ser combinado com o nosso padrão, e portanto, beneficiar-se com o uso de aspectos. Dessa forma, poderia-se oferecer suporte a um conjunto maior de adaptações e ao mesmo tempo obter-se uma estrutura ção no código mais fácil de compreender. Por fim, avaliamos o impacto de AspectJ, através do uso do padrão Adaptability Aspects, para implementar alguns requisitos de adaptabilidade em aplicações J2ME. Comparamos nossa implementação com uma solução em que a implementação destes requisitos não é tão modular e com uma outra solução utilizando padrões de projeto puramente orientados a objeto na qual se buscava tal modularidade. Alguns dos aspectos comparados foram tempo de execução, memória utilizada, tamanho da aplicação e de seu código. Além de medir tais fatores, descrevemos os ganhos que a programação orientada a aspectos pode trazer para a estruturação de aplicações adaptativas visando obter qualidade em termos de reuso e facilidade de manutenção

As software systems have grown in size and complexity, the costs of maintaining such systems increases steadily. In the early 2000's, IBM launched the autonomic computing initiative to mitigate this problem by injecting feedback control mechanisms into software systems to enable them to observe their health and self-heal without human intervention and thereby cope with certain changes in their requirements and environments. Self-healing is one of several fundamental challenges addressed and includes software systems that are able to recover from failure conditions. There has been considerable research on software architectures with feedback loops that allow a multi-component system to adjust certain parameters automatically in response to changes in its environment. However, modifying the components' source code in response to failures remains an open and formidable challenge. Automatic program repair techniques aim to create and apply source code patches autonomously. These techniques have evolved over the years to take advantage of advancements in programming languages, such as reflection. However, these techniques require mechanisms to evaluate if a candidate patch solves the failure condition. Some rely on test cases that capture the context under which the program failed---the patch applied can then be considered as a successful patch if the test result changes from failing to passing. Although test cases are an effective mechanism to govern the applicability of potential patches, the automatic generation of test cases for a given scenario has not received much attention. ReCrash represents the only known implementation to generate test cases automatically with promising results through the use of low-level instrumentation libraries. The work reported in this thesis aims to explore this area further and under a different light. It proposes the use of Aspect-Oriented Programming (AOP)---and in particular of AspectJ---as a higher-level paradigm to express the code elements on which monitoring actions can be interleaved with the source code, to create a representation of the context at the most relevant moments of the execution, so that if the code fails, the contextual representation is retained and used at a later time to automatically write a test case. By doing this, the author intends to contribute to fill the gap that prevents the use of automatic program repair techniques in a self-healing architecture. The prototype implementation engineered as part of this research was evaluated along three dimensions: memory usage, execution time and binary size. The evaluation results suggest that (1) AspectJ introduces significant overhead with respect to execution time, (2) the implementation algorithm causes a tremendous strain on garbage collection, and (3) AspectJ incorporates tens of additional lines of code, which account for a mean size increase to every binary file of a factor of ten compared to the original size. The comparative analysis with ReCrash shows that the algorithm and data structures developed in this thesis produce more thorough test cases than ReCrash. Most notably, the solution presented here mitigates ReCrash's current inability to reproduce environment-specific failure conditions derived from on-demand instantiation. This work can potentially be extended to apply in less-intrusive frameworks that operate at the same level as AOP to address the shortcomings identified in this analysis. / Graduate

A Programação Orientada a Aspectos (POA) é uma técnica de desenvolvimento que apoia a separação de interesses transversais. Na POA, adendos são aplicados a pontos de junção do sistema por meio de uma construção especial chamada descritor de conjuntos de junção (ou simplesmente conjunto de junção). Esse mecanismo apoia a modularização de comportamentos transversais, entretanto, como as interações adicionadas não ficam explícitas no código-fonte, é difícil assegurar que estão corretas. Para lidar com esse problema, nesta tese é proposta uma abordagem rigorosa de teste estrutural de integração para programas orientados a aspectos. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java chamado Grafo Def-Uso baseado em conjuntos de junção (ou PointCut-based Def-Use graph, PCDU) que modela as regiões de execução de um programa escrito em AspectJ que são afetadas por um conjunto de junção. Sobre este modelo são definidos três critérios de teste: todos-nós-baseados-em-conjunto-de-junção, todas-arestas-baseadas-em-conjunto-de-junção e todos-usos-baseados-em-conjunto-de-junção, que requerem a cobertura de todos os comandos, condicionais e pares def-uso no contexto de cada ponto de junção selecionado. Para automatizar o uso do modelo e critérios propostos, é implementada uma ferramenta chamada JaBUTi/PC-AJ. Além disso, para validar a abordagem proposta, são conduzidos estudos teóricos e experimentais que procuram avaliar os critérios tanto do ponto de vista do custo de aplicação quanto do ponto de vista da eficácia em encontrar defeitos. Os estudos oferecem indícios da aplicabilidade e da eficácia dos critérios para encontrar defeitos diretamente relacionados com a POA / Aspect-Oriented Programming (AOP) is a promising development technique that supports separation of crosscutting concerns. In AOP, advice is applied to join points in the system through a special construct called pointcut. This mechanism supports the modularization of crosscutting behavior; however, since the added interactions are not explicit in the source code, it is hard to ensure their correctness. To tackle this problem, this thesis proposes a rigorous structural testing approach for aspect-oriented programs. A control and data flow model based on Java bytecode the PointCut-based Def-Use Graph (PCDU) that models execution regions of a program affected by a pointcut is proposed. On top of this model three testing criteria are defined: all-pointcut-based-advice-nodes, all-pointcut-based-advice-edges, and all-pointcut-based-advice-uses, that require exercising all statements, branches and def-use pairs of each advice at the context of each affected join point. To automate the use of the proposed model and criteria, a tool named JaBUTi/PC-AJ is implemented. Moreover, to validate the proposed approach, both theoretical and experimental studies are presented. These studies provide evidence of the applicability and efficacy of the proposed criteria

A Programação Orientada a Aspectos (POA) é uma técnica de desenvolvimento que apoia a separação de interesses transversais. Na POA, adendos são aplicados a pontos de junção do sistema por meio de uma construção especial chamada descritor de conjuntos de junção (ou simplesmente conjunto de junção). Esse mecanismo apoia a modularização de comportamentos transversais, entretanto, como as interações adicionadas não ficam explícitas no código-fonte, é difícil assegurar que estão corretas. Para lidar com esse problema, nesta tese é proposta uma abordagem rigorosa de teste estrutural de integração para programas orientados a aspectos. É definido um modelo de fluxo de controle e de dados baseado no bytecode Java chamado Grafo Def-Uso baseado em conjuntos de junção (ou PointCut-based Def-Use graph, PCDU) que modela as regiões de execução de um programa escrito em AspectJ que são afetadas por um conjunto de junção. Sobre este modelo são definidos três critérios de teste: todos-nós-baseados-em-conjunto-de-junção, todas-arestas-baseadas-em-conjunto-de-junção e todos-usos-baseados-em-conjunto-de-junção, que requerem a cobertura de todos os comandos, condicionais e pares def-uso no contexto de cada ponto de junção selecionado. Para automatizar o uso do modelo e critérios propostos, é implementada uma ferramenta chamada JaBUTi/PC-AJ. Além disso, para validar a abordagem proposta, são conduzidos estudos teóricos e experimentais que procuram avaliar os critérios tanto do ponto de vista do custo de aplicação quanto do ponto de vista da eficácia em encontrar defeitos. Os estudos oferecem indícios da aplicabilidade e da eficácia dos critérios para encontrar defeitos diretamente relacionados com a POA / Aspect-Oriented Programming (AOP) is a promising development technique that supports separation of crosscutting concerns. In AOP, advice is applied to join points in the system through a special construct called pointcut. This mechanism supports the modularization of crosscutting behavior; however, since the added interactions are not explicit in the source code, it is hard to ensure their correctness. To tackle this problem, this thesis proposes a rigorous structural testing approach for aspect-oriented programs. A control and data flow model based on Java bytecode the PointCut-based Def-Use Graph (PCDU) that models execution regions of a program affected by a pointcut is proposed. On top of this model three testing criteria are defined: all-pointcut-based-advice-nodes, all-pointcut-based-advice-edges, and all-pointcut-based-advice-uses, that require exercising all statements, branches and def-use pairs of each advice at the context of each affected join point. To automate the use of the proposed model and criteria, a tool named JaBUTi/PC-AJ is implemented. Moreover, to validate the proposed approach, both theoretical and experimental studies are presented. These studies provide evidence of the applicability and efficacy of the proposed criteria

Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Uma abordagem de teste estrutural de integração contextual para programas OO e OA escritos em Java e AspectJ é apresentada. A finalidade dessa abordagem é descobrir defeitos que possam existir nas interfaces entre uma determinada unidade (método ou adendo) e todas as outras que interagem diretamente com ela, bem como descobrir defeitos que possam ocorrer na hierarquia de chamadas dessas unidades. Para programas OO, esse tipo de teste envolve testar a interação entre métodos; já para programas OA, o teste estrutural de integração nível um (como também pode ser chamado) deve considerar as interações método-método, método-adendo, adendo-adendo e adendo-método. Para efetuar o teste estrutural de integração nível um deve-se considerar todo o fluxo de execução (fluxo de controle e de dados) que ocorre entre uma unidade chamadora e as unidades que interagem diretamente com ela. Para isso é definido o grafo Def-Uso IN1P, que é uma abstração formada pela integração dos grafos Def-Uso Orientado a Aspectos (AODU) da unidade chamadora e das unidades que ela chama ou que a afeta. Além disso, são propostos três critérios para derivar os requisitos de teste, dois baseados em fluxo de controle (todos-nós-integrados-N1 e todas-arestas-integradas-N1) e um baseado em fluxo de dados (todos-usos-integrados-N1). A ferramenta JaBUTi/AJ foi estendida para dar apoio à abordagem de teste de integração proposta. Exemplos são apresentados para ilustrar o uso da ferramenta para o teste de profundidade um e também seu uso no contexto de uma abordagem que leva em consideração também o teste de unidades e o teste baseado em conjuntos de junção / A Contextual structural integration testing for OO and OA programs written in Java and AspectJ is presented. The purpose of this approach is to discover faults that may exist in the interfaces between a particular unit (method or advice) and all others that interact directly with it, as well as to discover defects that may occur in the call hierarchy of these units. In OO programs, this type of test involves testing the interaction among methods. For OA programs, the structural integration testing at the depth of one (as it can also be called) should consider the method-method, method-advice, advice-advice and advice-method interactions. To perform structural integration testing at the depth of one level the whole execution flow (control and data flow) that occurs among a caller unit and the units that interact directly with it it must be considered. The IN1P Def-Use graph has been defined as an abstraction formed by the integration of the Aspect-Oriented Def-Use (AODU) graphs of the caller unit and of the units that it calls or affects it. Also, three criteria to derive test requirements are proposed, two of which are based on control flow all-integrated-nodes-N1 and all-integrated-edges-N1 and one is based on data flowall-integrated-uses-N1. The tool JaBUTi/AJ was extended to support the proposed integration testing approach. Examples are presented to illustrate the use of the tool for depth 1 testing as well as its use in the context of an approach that also takes into account unit testing and pointcut-based testing

Ce travail de recherche concerne l'apport de l'approche Aspect à l'ingénierie des systèmes d'information (SI) en général et aux patrons de conception en particulier. L'objectif principal de ce travail est de développer des patrons à base d'aspects afin de faciliter et de guider l'ingénierie de SI par réutilisation de patrons.<br />Les patrons de conception par objets améliorent et accélèrent le développement en favorisant l'évolution, l'adaptation et la réutilisation de SI. Leur utilisation dans une approche strictement Objet pose cependant plusieurs problèmes et limites qui sont principalement liés à la dispersion et à l'enchevêtrement du code de leurs imitations dans l'implémentation des applications. L'approche Aspect permet de nouvelles solutions pour ces patrons contribuant à garder visible et isolée l'imitation de chaque patron dans le code des applications, afin de pallier à leurs problèmes d'utilisation et d'améliorer leur traçabilité et leur réutilisation.<br />Toutefois, un manque de consensus sur les concepts et mécanismes fondamentaux de l'approche Aspect et la diversité des modèles et langages de programmation proposés dans ce courant de recherche rendent difficile l'expression de structures par aspects de patrons indépendamment d'une technique de programmation par aspects particulière. Pour aborder cette difficulté, nous avons adopté une approche par métamodélisation et transformation de modèles. Nous avons basé cette approche sur un métamodèle général intégrant les particularités de l'approche Aspect et deux métamodèles spécifiques à AspectJ et Hyper/J. Les trois métamodèles proposés sont définis comme étant des extensions du métamodèle d'UML. Des règles de transformation sont également proposées.<br />Nous avons utilisé le métamodèle général pour l'expression de nouvelles solutions par aspects des patrons de conception par objets que nous considérons. Cette étude nous a permis de définir un système de huit nouveaux patrons originaux capitalisant des expertises en matière de conception par aspects. Les patrons proposés sont coordonnés et hiérarchisés ce qui permet d'offrir un cadre pour une démarche pour réaliser une conception et une programmation par aspects de qualité.

Made available in DSpace on 2014-12-17T15:47:48Z (GMT). No. of bitstreams: 1 NelioAAC.pdf: 1347387 bytes, checksum: 86918831f569aa83a51dd90239b6f455 (MD5) Previous issue date: 2006-12-15 / Conselho Nacional de Desenvolvimento Cient?fico e Tecnol?gico / Plataformas de middleware t?m sido utilizadas em diversos ambientes computacionais e por diferentes classes de aplica??es com requisitos variados. Para atender a cada cen?rio espec?fico, ? necess?rio conferir ?s plataformas de middleware capacidade de adapta??o da sua infra-estrutura conforme as necessidades das aplica??es e do ambiente computacional. Atualmente, uma nova gera??o de plataformas de middleware tem explorado o conceito de reflex?o computacional para possibilitar adapta??o din?mica. No entanto, esta nova gera??o de plataformas n?o endere?am os problemas introduzidos pela presen?a dos conceitos transversais entrela?ados com os conceitos b?sicos, que reduzem o potencial reuso do middleware em diferentes cen?rios e, por conseq??ncia, limitam a capacidade de adapta??o. No presente trabalho, combinamos reflex?o computacional com programa??o orientada a aspectos para permitir a separa??o dos conceitos transversais e assim melhorar o reuso e capacidade de adapta??o das plataformas de middleware. Esta combina??o ?e usada na especifica??o de uma nova estrutura para a arquitetura do Open-ORB. Tal arquitetura ? implementada usando duas estrat?gias distintas: (i) uma estrat?gia interpretada utilizando a linguagem Lua em combina??o com AspectLua; (ii) uma estrat?gia compilada que emprega a linguagem Java em combina??o com AspectJ. De forma a avaliar os benef?cios de cada estrat?gia, este trabalho apresenta uma s?rie de compara??es que traduzem as diferen?as em termos de modularidade, mem?ria utilizada e tempo de execu??o de cada uma das estrat?gias