Metrics for Evaluation of Aspect-Oriented Middleware

Transcrição

1 2009 XXIII Brazilian Symposium on Software Engineering Metrics for Evaluation of Aspect-Oriented Middleware Tássia A. V. Freitas, Thaís V. Batista, Flávia C. Delicato, Paulo F. Pires Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte (UFRN) Natal(RN), Brazil tassiafreitas@gmail.com, thais@ufrnet.br, {fdelicato,paulo.f.pires}@gmail.com Resumo Este artigo apresenta um conjunto de métricas para a avaliação de sistemas de middleware orientados a aspectos (OA) de forma a avaliar os reais benefícios que a OA pode conferir a um middleware. É definida uma lista de propriedades estáticas e dinâmicas que são relevantes para um middleware, e associadas métricas a cada propriedade. Essa estratégia, de associar métricas a propriedades, permite que se analisem características de sistemas de middleware a partir de resultados de medições realizadas através da aplicação das métricas de software. Também é descrita a ferramenta CoMeTA-Lua, desenvolvida para coletar métricas de tamanho e acoplamento em código Lua. As métricas são aplicadas em dois sistemas de middleware implementados em Lua: o OiL e o AO-OiL. Sistema de middleware; métricas de software; desenvolvimento de software orientaado a aspectos Abstract We present a set of metrics to assess aspect oriented (AO) middleware aiming at evaluating the benefits of applying the AO paradigm in middleware design. We adopt a strategy based on defining a list of static and dynamic properties which are relevant to a middleware and associating metrics to each property. The adopted strategy allows the developer to analyze relevant middleware features from the results of software metrics. Besides the proposed metrics, this paper also presents CoMETA-Lua, a tool to collect coupling and size metrics in a Lua source code. The set of metrics is applied in two middleware systems implemented in Lua: OiL and AO-OiL. Middleware system; software metrics; aspect-oriented software development I. INTRODUÇÃO Nos últimos anos têm surgido vários sistemas de middleware [22], [11] que usam o paradigma de desenvolvimento de software orientado a aspectos (DSOA) [8] com o objetivo de projetar o middleware dividindo sua arquitetura em um núcleo base e um conjunto de conceitos transversais (funcionalidades que estão tipicamente espalhadas em várias partes do middleware). O paradigma de DSOA visa dar suporte à modularização de conceitos transversais. Nesse paradigma, sistemas são separados em componentes e aspectos. Componentes são elementos que implementam os conceitos básicos da aplicação. Aspectos modularizam os conceitos transversais de forma a prover a separação deste código do código dos componentes. Componentes e aspectos são combinados em tempo de compilação ou de execução para compor o sistema, através de um processo denominado weaving. Aspectos atuam sobre componentes em pontos de junção (joinpoints), definidos no código dos componentes. Ou seja, o aspecto define os pontos onde irá atuar nos componentes e também o código (advices) que será inserido quando tais pontos forem atingidos. Além disso, o aspecto define o momento (antes, durante, depois) em que irá atuar quando o ponto de junção for alcançado. Através de aspectos é possível ainda utilizar estruturas chamadas introductions, que tornam possível adicionar atributos e métodos a classes previamente declaradas. Para avaliar um middleware construído seguindo o paradigma DSOA, em geral, os trabalhos existentes medem apenas o desempenho do middleware [17] e a quantidade de memória consumida. Com o crescente número de implementações desse tipo de middleware, faz-se necessário realizar uma avaliação mais ampla, levando em conta um conjunto de métricas bem definido, que permita comparar e analisar diversas propriedades, de forma a avaliar os reais benefícios que a orientação a aspectos (OA) pode conferir a um middleware. Alguns sistemas de middleware, como JBoss AOP [11] e Lasagne [22] nem sequer possuem avaliações. Uma exceção é o trabalho [23], no qual são apresentadas métricas para avaliar a refatoração de sistemas de middleware durante a fase de implementação. No entanto, além de não fornecer métricas para a avaliação na fase de design, a refatoração é avaliada somente em termos de tamanho, complexidade, acoplamento e tempo de resposta. Faz-se necessária a avaliação de propriedades como separação de interesses e flexibilidade, por exemplo, que são atributos importantes em sistemas de middleware OA. Este trabalho tem como objetivo propor um conjunto de métricas com o intuito de prover um sistema para avaliação de sistemas de middleware OA. Para tal, o trabalho baseia-se em propostas existentes de métricas para sistemas de software OA [4], [6], [20], [19], [23], bem como métricas para sistemas OO [1], [5]. Todas essas propostas foram integradas para a construção de um arcabouço único de /09 $ IEEE DOI /SBES

2 avaliação, que provê uma solução mais completa e abrangente do que as propostas individuais. O sistema de avaliação proposto define uma lista de propriedades baseada em [6] que são relevantes para um middleware, e associa métricas a cada propriedade. A lista é composta pelas seguintes propriedades, das quais algumas são estáticas e outras dinâmicas: modularidade, flexibilidade, manutenibilidade, tamanho, complexidade, desempenho e consumo de memória. A estratégia proposta, de utilizar propriedades associadas a métricas, permite ao avaliador analisar características relevantes de sistemas de middleware a partir de resultados obtidos para métricas de software. O conjunto de métricas visa não somente avaliar sistemas de middleware com o intuito de comparar versões OO e OA (refatoração) de um mesmo middleware e avaliar seu comportamento dinâmico, como também comparar diferentes sistemas de middleware OA entre si. Como a coleta de métricas é uma tarefa repetitiva, tediosa e propensa a erros, este trabalho também apresenta a ferramenta COMETA-Lua (Ferramenta para Coleta de Métricas de Tamanho e Acoplamento em Lua), para automatizar a aquisição das métricas das propriedades de tamanho e acoplamento, as quais demandam maior trabalho na coleta. Como os sistemas de middleware usados como estudo de caso foram desenvolvidos na linguagem Lua [14], a ferramenta foi direcionada a analisar código Lua. No entanto, o conjunto de métricas proposto neste trabalho é genérico, e pode ser aplicado no contexto de qualquer linguagem de programação. De forma a validar parcialmente a aplicabilidade do conjunto de métricas proposto, elas são aplicadas ao middleware OiL (ORB in Lua) [15] e a sua versão OA, o AO-OiL [21]. Os resultados da medição são coletados e analisados de forma a levantar pontos fracos e fortes das duas versões. É importante ressaltar que, como o objetivo da avaliação nesse caso é a refatoração, somente as métricas relevantes para esse contexto foram aplicadas. Logo, a aplicação do conjunto de métricas apresentado nesse trabalho é apenas parcial. Os resultados alcançados com a aplicação das métricas no estudo de caso comprovam a eficiência das métricas para avaliação de refatoração de sistemas de middleware, como também a aplicabilidade da ferramenta como agente facilitador no processo de coleta das métricas. A relação entre propriedades e métricas estabelecida por este trabalho permite que se analisem melhorias nas propriedades de um sistema, a partir de valores obtidos para a medição. Este artigo é estruturado como segue. A Seção II apresenta o conjunto de propriedades proposto e respectivas métricas associadas. A Seção III mostra o estudo de caso que ilustra a aplicação do conjunto de métricas, a ferramenta CoMeTA-Lua e os resultados coletados para o estudo de caso, bem como uma análise desses resultados. Os trabalhos relacionados são apresentados na Seção IV. A Seção V contém as conclusões. II. MÉTRICAS PARA MIDDLEWARE OA Modularidade, flexibilidade, manutenibilidade, tamanho e complexidade são propriedades estáticas relevantes em sistemas de middleware. De forma a avaliar tais propriedades, utiliza-se um conjunto de métricas associado a cada uma delas. Além das propriedades estáticas, as propriedades dinâmicas desempenho e consumo de memória também são avaliadas através de métricas específicas. O conjunto de propriedades estáticas e dinâmicas e suas métricas são descritas no decorrer desta seção. A lista de propriedades utilizadas no presente trabalho levanta características relevantes a serem avaliadas na refatoração de sistemas distribuídos, estendendo o trabalho [6] no qual as propriedades foram originalmente propostas. Este trabalho associa métricas bem conhecidas às propriedades, para prover uma abordagem mais sistemática para o processo de avaliação. As métricas não são específicas para avaliação de sistemas de middleware, mas foram selecionadas como meio de avaliar propriedades relevantes a esse contexto. O conjunto de métricas proposto neste trabalho divide-se em duas partes. A primeira trata de métricas para fases de design, implementação e refatoração dos sistemas de middleware OA. Para essa parte define-se um conjunto de propriedades estáticas inter-relacionadas e de métricas para avaliá-las. A segunda parte avalia o comportamento dinâmico desses sistemas, focando no desempenho. A primeira parte do conjunto de métricas baseia-se no trabalho [6]. A idéia principal é definir as propriedades relevantes para um sistema de middleware e associar, a cada propriedade, métricas que possam mensurá-las. Portanto, estendemos o trabalho [6] de forma a relacionar métricas às propriedades de sistemas distribuídos como é o caso do middleware. A. Conjunto de Propriedades Estáticas de Sistemas de Middleware AO As propriedades são apresentadas a seguir, bem como os fatores que as influenciam. Cabe ressaltar que, neste trabalho, entidade é o nome dado a classes e aspectos e operações, a métodos e advices. 1. Modularidade: em [10, 3, 20], boa modularidade está associada à boa separação de interesses, ou seja, alta coesão e baixo acoplamento entre as entidades do sistema. 2. Manutenibilidade: em [5] afirma-se que a manutenibilidade é influenciada por tamanho e acoplamento: quanto maior e mais acoplado for um sistema, mais difícil é a sua compreensão, resultando em manutenção mais complexa. Contudo, a compreensão de um sistema (e consequentemente sua manutenção) é afetada não apenas pelo acoplamento, mas também por outros fatores que influenciam a modularidade. Assim, neste trabalho considera-se que manutenibilidade está associada a tamanho e modularidade. 3. Flexibilidade: no contexto de middleware, refere-se à capacidade de acoplar e desacoplar componentes à parte central do sistema, adaptando-se às necessidades da aplicação. Segundo [19], flexibilidade é afetada pelos fatores acoplamento e separação de interesses. Baixo acoplamento e alta separação de interesses promovem a flexibilidade por facilitarem a remoção ou inclusão de funcionalidades. 4. Complexidade: em [5] relaciona-se complexidade à herança, ao tamanho e a resposta para um classe (RFC - 74

3 Response for a Class). RFC é a quantidade de métodos que podem ser invocados em resposta a uma mensagem recebida pelo objeto. Quanto mais altos esses fatores, maior a complexidade. 5. Tamanho: propriedade que caracteriza o middleware quanto ao seu tamanho, não somente o número de linhas de código, mas também o tamanho do vocabulário. O vocabulário pode ser interno a uma entidade - número de atributos de uma entidade - ou relativo ao sistema - número de entidades que o compõem. Sobre acoplamento, para que se possa fazer uma avaliação detalhada dessa propriedade, ela foi dividida em duas categorias: (i) acoplamento entidade-entidade, (ii) acoplamento código base-aspecto. A primeira é a categoria mais genérica e analisa o acoplamento entre quaisquer duas entidades do sistema: seja entre classes, entre aspectos, ou entre classe e aspecto. O acoplamento código base-aspecto avalia o acoplamento entre o código-base do sistema e os aspectos que nele incidem. Essa divisão em categorias foi necessária porque algumas propriedades do conjunto de métricas proposto dependem de um tipo específico de acoplamento. Por exemplo, flexibilidade refere-se à facilidade em adicionar ou remover um aspecto ao códigobase de um sistema. Nesse caso, portanto, apenas o acoplamento entre código-base e aspectos interessa. B. Métricas para as Propriedades Estáticas de Sistemas de Middleware AO Uma vez definido o conjunto de propriedades e levantados os fatores que as influenciam, foram selecionadas as métricas mais adequadas para mensurar tais propriedades. 1) Modularidade Segundo [20], modularidade é o grau em que um sistema é composto de componentes discretos tal que uma mudança em um componente tenha impacto mínimo em outros componentes. Este trabalho segue tal definição e associa essa propriedade a três fatores: separação de interesses, coesão e acoplamento. Como o acoplamento para essa propriedade diz respeito a conexões entre as várias entidades de um sistema, o acoplamento em questão é o entidade-entidade. Um interesse é qualquer propriedade importante em um sistema que se deseja tratar de forma modular [8]. Para avaliar a separação de interesses utilizam-se as métricas do trabalho [19]: CDC(Concern Diffusion over Components), CDO (Concern Diffusion over Operations) e CDLOC (Concern Diffusion over LOC), por serem as métricas que melhor se adequam avaliação de entrelaçamento e espalhamento de conceitos em todo o código de um sistema. Essas métricas serão redefinidas da seguinte forma, a fim de se adequarem à terminologia deste trabalho: (i) CDC é o número de entidades cujo principal fim é contribuir para a implementação de um interesse; (ii) CDO é o número de operações cujo principal propósito é contribuir para a implementação de um interesse; e (iii) CDLOC é o número de pontos de transição para cada interesse do começo ao fim das linhas de código. O uso da métrica CDLOC requer um processo de sombreamento que particiona o código em áreas sombreadas e não-sombreadas. As áreas sombreadas são linhas de código que implementam um dado interesse. Pontos de transição são os pontos no código onde há transição de uma área não-sombreada para uma sombreada e vice-versa. O tipo de acoplamento relevante para a avaliação da modularidade do sistema é o entidade-entidade, pois o que se deseja avaliar é a organização do sistema, pouco interessando a abstração (classes ou aspectos) usada para atingir tal organização. Para avaliação completa do acoplamento entidade-entidade, utiliza-se o framework de acoplamento apresentado em [1]. Tal framework inclui diversas métricas disponíveis na literatura para avaliar o acoplamento em sistemas OO. Dentre estas, selecionou-se as que mais se adequam à avaliação de acoplamento em middleware. Para que essas métricas também pudessem ser aplicadas a sistemas OA, suas definições sofreram pequenas modificações, descritas a seguir: CBO' (Coupling between Objects): para uma entidade, refere-se ao número de outras entidades as quais ela está acoplada, incluindo acoplamento devido à herança. Um objeto de uma entidade é acoplado a outro se operações de uma entidade usam operações ou atributos de outra; MPC' (Messaging Passing Coupling): é o número de invocações estáticas a operações não implementadas em uma entidade A, realizadas por operações implementadas em A. Indica quão dependentes as operações de uma entidade são de operações de outras entidades; DAC' (Data Abstraction Coupling): número de atributos não herdados que têm uma entidade como seu tipo. Aplicada ao paradigma OO, a coesão é em geral medida pela similaridade entre métodos de uma classe, a qual pode ser obtida verificando se eles acessam o mesmo conjunto de atributos da classe. Em [20], a coesão é tratada sob uma perspectiva diferente: a métrica para coesão é definida baseada em interesse, uma vez que o foco do trabalho é o design OA. Adaptamos tal métrica para a terminologia adotada neste trabalho. LCC' (Lack of Concern-based Cohesion) denota o número de interesses de uma dada entidade. Tal métrica foi escolhida por avaliar se os interesses do sistema estão bem modularizados. 2) Manutenibilidade O trabalho [2] analisa o design de alto nível de um sistema de software com o propósito de prever e avaliar a dificuldade de mudança do ponto de vista dos projetistas. Ou seja, avaliam a manutenibilidade de design. Para tal, usam métricas de coesão e acoplamento. Já em [9] apresenta-se um framework orientado a interesses que suporta a instanciação e comparação de métricas usadas em estudos empíricos de manutenibilidade. O framework define três novas métricas que medem os atributos acoplamento, coesão e espalhamento de um interesse, associando essas métricas com a avaliação da propriedade manutenibilidade. Segundo os autores, a manutenibilidade de design de software OA requer que os desenvolvedores raciocinem sobre a modularidade do sistema. Em [20] também se afirma que modularidade é um atributo que influencia a manutenibilidade. Baseando-se nesses trabalhos, o conjunto 75

4 de métricas proposto define a propriedade manutenibilidade como dependente da modularidade e a associa a acoplamento, coesão e separação de interesses. Os mesmos atributos são medidos em [9] para avaliar a manutenibilidade. Manutenibilidade relaciona-se também ao tamanho do código. Conforme dito, quanto maior um sistema, mais difícil sua compreensão, resultando em manutenção mais complexa. Do exposto decorre que a propriedade manutenibilidade não possui métricas particulares e deve ser avaliada em função das propriedades modularidade e tamanho (ver subseções 1 e 5, respectivamente). 3) Flexibilidade Para sistemas de middleware OA, a flexibilidade que interessa medir é a relativa à inserção/remoção de aspectos no middleware. Quanto menor esse acoplamento, mais facilmente se poderá incluir e/ou remover aspectos e, portanto, mais flexível torna-se o middleware. Segundo [19], a propriedade de flexibilidade é determinada não apenas através do acoplamento, mas também em função da separação de interesses. Baixo acoplamento e separação de interesses promovem a flexibilidade facilitando o processo de adicionar e remover funcionalidades. Portanto, a flexibilidade é avaliada em função do acoplamento código base-aspectos e da separação de interesses. Levando em consideração que, no contexto de middleware OA, flexibilidade refere-se à capacidade de inserir e/ou remover aspectos no código base, o acoplamento relevante para a avaliação dessa propriedade é o acoplamento código base-aspectos. Com esse intuito, selecionaram-se métricas apresentadas em [4], as quais foram redefinidas seguindo a terminologia deste trabalho: CAE (Coupling in Advice Execution): número de aspectos contendo advices possivelmente disparados pela execução de operações de uma dada entidade. Se o comportamento de uma operação pode ser alterado por um advice, há uma dependência da operação em relação ao advice. Assim, a entidade dessa operação está acoplada ao aspecto que contém o advice. Uma mudança no advice causa impacto na operação; CIM (Coupling on Intercepted Modules): número de entidades ou interfaces explicitamente nomeadas nos pontos de corte (pointcuts) pertencentes a um aspecto. CIM captura o conhecimento direto do restante do sistema. Valores altos de CIM indicam alto acoplamento do aspecto com uma aplicação e baixa generalidade, e portanto reusabilidade; CDA (Crosscutting Degree of an Aspect): número de entidades afetadas pelos pointcuts e por introductions em um dado aspecto. Enquanto CIM considera somente entidades nomeadas explicitamente, CDA mede todas as entidades possivelmente afetadas por um aspecto. Isso dá uma idéia do impacto total de um aspecto nas outras entidades do sistema. A diferença entre CDA e CIM dá o número de entidades que são afetadas por um aspecto sem serem referenciadas explicitamente pelo aspecto, o que indica o grau de generalidade de um aspecto em termos de sua independência de classes/aspectos específicos. 4) Complexidade Segundo [5], quanto maior o número de métodos que uma classe herda, mais complexo é rastrear seu comportamento. Pode-se inferir dessa afirmação que o fator herança influencia diretamente a complexidade de um sistema. Logo, as métricas para avaliar herança serão consideradas para a avaliação dessa propriedade. Outra medida de complexidade é a métrica resposta para uma classe (RFC). A definição original de RFC em [5] diz que RFC é o conjunto resposta de uma classe, ou seja, o conjunto de métodos que podem ser potencialmente executados em resposta a uma mensagem recebida por um objeto daquela classe. Se um grande número de métodos podem ser invocados em resposta a uma mensagem, o sistema será mais complexo. Assim, essa métrica também é incluída para a propriedade complexidade, porém precisa ser adaptada aos moldes da OA. Adaptando a métrica RFC para a orientação a aspectos, RFC'(Response for a Class) passa a ser o conjunto de operações que podem ser potencialmente executadas em resposta a uma mensagem recebida por uma instância daquela entidade. Só serão consideradas na contagem operações pertencentes à entidade que recebeu a mensagem, para que se possa focalizar na complexidade de se compreender a entidade e desconsiderar acoplamento entre entidades. Entram na conta advices invocados explicitamente ou não, no código da classe ou aspecto. Essa modificação visa refletir a condição de que quanto mais advices são invocados durante a execução de uma instância da entidade, mais complexa sua estrutura e mais difícil de compreender o fluxo de execução da instância da entidade. Para avaliar a herança, métricas convencionais usadas em sistemas OO são adaptadas para poderem ser aplicadas a sistemas OA. DIT' (Depth of Inheritance Tree) - Profundidade da Árvore de Herança: é a profundidade de uma entidade na árvore de hierarquia de herança. A árvore de herança é um grafo direcionado acíclico e as entidades são representadas como nós. Essa medida é o comprimento do maior caminho entre uma determinada entidade e nó raiz da árvore. Segundo [5], quanto mais profunda uma entidade está em uma hierarquia de herança, maior o número de métodos herdados e mais complexo é rastrear o seu comportamento; NOC' (Number of Children) - é o número de entidades imediatas subordinadas à uma outra entidade. Quanto maior o número de entidades filhas, mais complexo se torna compreender a estrutura de cada entidade. 5) Tamanho Para essa propriedade, o presente trabalho usa o conjunto de métricas para tamanho proposto em [19] composto das métricas VS, LOC, NOA e WOC. Redefinindo tais métricas para ficarem em conformidade com a terminologia deste trabalho, tem-se que: VS (Vocabulary Size) denota o número de entidades do sistema; LOC (Lines of Code) é o número de 76

5 linhas de código desconsiderando-se comentários e linhas em branco; NOA (Number of Attributes) é o número de atributos de uma entidade, excluindo atributos herdados; WOC (Weighted Operations per Component) é a soma das complexidades das operações de uma entidade. A complexidade de uma operação é definida em função do seu número de parâmetros. 6) Aplicação das Métricas Em [23] afirma-se que a avaliação da refatoração de sistemas deve ser feita com base nas propriedades tamanho e acoplamento. Os autores não mencionam métricas para separação de interesses, mas entende-se que esse é um dos objetivos principais ao se realizar um processo de refatoração. Como acoplamento e separação de interesses são fatores da modularidade neste trabalho e a aspectização de um sistema é realizada visando melhorar sua modularização, as métricas das propriedades modularidade e tamanho serão consideradas relevantes para a avaliação do processo de aspectização. A Fig. 1 mostra uma visão geral do conjunto de métricas para avaliação estática. A definição da fase de desenvolvimento onde cada métrica pode ser aplicada baseia-se nos trabalhos em que foram originalmente propostas. As fases consideradas são: design, implementação e refatoração. As métricas de tamanho, exceto LOC, podem ser aplicadas em todas as fases. LOC, por considerar o número de linhas de código, somente pode ser coletada nas fases de implementação e refatoração. As métricas de separação de interesses CDC e CDO podem ser aplicadas em todas as fases. A métrica CDLOC de separação de interesses, por estar atrelada às linhas de código, apenas pode ser coletada nas fases de implementação e refatoração. As métricas de coesão LCC e de acoplamento entidade-entidade podem ser coletadas em todas as fases. As métricas de acoplamento código baseaspectos CAE, CIM, CDA e as de herança DIT e NOC, por não serem relevantes para avaliar refatoração, são aplicadas nas fases de design e implementação. As métricas de acoplamento código base-aspectos não são aplicadas na refatoração por uma razão muito clara. As métricas de refatoração precisam ser aplicadas tanto na versão OO do sistema quanto na versão OA. Como a versão OO não inclui definição de aspectos, não é possível aplicar nessa versão as métricas de acoplamento código base-aspectos. A aplicação das métricas de herança na fase de refatoração não é considerada relevante para os propósitos de avaliação em questão. C. Conjunto de Propriedades Dinâmicas de Sistemas de Middleware OA O conjunto de propriedades dinâmicas para avaliação de sistemas de middleware OA é composto por desempenho e consumo de memória. Desempenho não faz parte do conjunto de propriedades original de [6], mas foi incluída neste trabalho por ser fundamental para sistemas de middleware. Mesmo que um middleware apresente bons resultados para todas as outras propriedades, se apresentar um desempenho ruim, não será viável. Outra propriedade relevante é consumo de memória, essencial para avaliar se a solução de middleware satisfaz condições de restrição de memória em determinados dispositivos, como por exemplo PDAs, nos quais deve ser executado. O fator mais impactante no desempenho e no consumo de memória é o processo de weaving e o momento em que ele é realizado. O weaving pode ser estático, que ocorre durante a compilação, ou dinâmico, que ocorre em tempo de carga, de execução ou por interceptação. Figure 1. Visão geral do conjunto de métricas para propriedades estáticas. 77

6 D. Métricas Dinâmicas para Avaliação de Sistemas de Middleware Métricas dinâmicas são utilizadas para coletar informações sobre propriedades de execução de programas. Em sistemas de middleware OA, elas são úteis, por exemplo, para avaliar se a utilização de aspectos acarreta perda significativa de desempenho. São ainda úteis para avaliar o melhor momento de carga dos aspectos: tempo de compilação, tempo de carga, por interceptação ou tempo de execução. Com o objetivo de avaliar os pontos citados, foram definidas três métricas (Fig. 2) baseando-se em [7]: (i) tempo de execução: mede o overhead de utilizar aspectos com um determinado tipo de carga de aspectos, considerando para tal medida o tempo de execução de um programa; (ii) número de operações primárias: assim como a métrica anterior, mede o overhead de utilizar aspectos com um determinado tipo de carga, mas utilizam-se operações básicas ao invés do tempo para fins de comparação, podendo-se citar como exemplos bytecode para Java ou operação binária para outras linguagens, apresentando a vantagem em relação à métrica definida em (i) de ser independente de plataforma; (iii) consumo de memória: mede a quantidade de memória alocada para a execução de um programa. III. ESTUDOS DE CASO E FERRAMENTA Para ilustrar a utilização do conjunto de métricas proposto, ele foi aplicado aos sistemas de middleware OiL [15] e a sua versão refatorada usando OA, o AO-OiL [21], apresentados na subseção A. Com os resultados obtidos foi possível comparar duas versões de um mesmo middleware. Executou-se nesses sistemas de middleware um Sistema de Monitoramento de Poços de Petróleo, que acompanha e avalia dados sobre as condições em que está ocorrendo a extração de petróleo e gás natural. Esse sistema é composto por uma Central de Monitoramento (CM) executada em uma estação servidora que recebe dados de sensores dos poços e fornece informações para os clientes através de um sistema de eventos. O trabalho [18] apresenta informações mais detalhadas sobre esse tipo de Figure 2. Visão geral do conjunto de métricas para propriedades dinâmicas. sistema. Quando um dado é atualizado, o servidor verifica quais clientes estão interessados no tipo de dado e envia a eles uma notificação da atualização. Como o objetivo é avaliar a refatoração do OiL, as métricas aplicadas são as definidas pelo conjunto de métricas para essa fase de desenvolvimento. Com o intuito de auxiliar a coleta das métricas avaliadas, implementou-se uma ferramenta, descrita da subseção B. Os resultados para a medição são apresentados na subseção C, juntamente com uma análise da refatoração. A. OiL e AO-OiL OiL (ORB in Lua) é uma implementação da especificação CORBA na linguagem Lua [14] que se beneficia da capacidade de adaptação dinâmica de Lua para prover suporte à comunicação remota em tempo de execução, incluindo invocação e despacho de métodos. Assim, ao contrário de outras implementações CORBA, OiL não suporta stubs e skeletons e invocações a métodos são realizadas por objetos proxies que funcionam como stubs dinâmicos e fazem a invocação de acordo com uma dada definição de interface. Sempre que uma definição de classe muda, sua classe proxy associada também muda para refletir a mudança. A arquitetura de componentes do OiL é composta por duas sub-arquiteturas: a do servidor e a do cliente. A arquitetura do servidor é responsável por gerenciar os serviços: ciclos de vida, conexões, interfaces expostas e objetos que os implementam. A arquitetura cliente deve fornecer meios de recuperar referências para os objetos e permitir invocações de operações de forma t r a n s p a r e n t e p a r a a a p l i c a ç ã o c l i e n t e. O middleware orientado a aspectos AO-OiL é uma refatoração do OiL, seguindo a arquitetura de referência disponível em [13] para middleware OA, usando a biblioteca de definição de aspectos RE-AspectLua. Aproveitando a capacidade dinâmica do OiL, o AO-OiL visa possibilitar a carga dinâmica de aspectos conforme as necessidades da aplicação. A arquitetura do AO-OiL é composta de um pequeno núcleo funcional e um conjunto de extensões, uma referente à distribuição e outra à coordenação. Os códigos referentes a essas extensões representam interesses que estão entrelaçados no código do OiL, e passam a ser modularizados dentro de aspectos no AO-OiL. Portanto, as extensões são implementadas como aspectos. A modelagem da distribuição como um aspecto evita a codificação de protocolos de resolução de nomes dentro das fábricas de componentes e permite implementar diversos protocolos de comunicação remota como RMI ou CORBA. Da mesma forma, a modelagem da coordenação como um aspecto permite que diferentes protocolos de coordenação, como publish-subscribe, shared data space, possam ser programados para controlar a coordenação de diferentes componentes. B. Ferramenta COMETA-Lua Embora Lua seja uma linguagem bastante utilizada nos meios comercial e acadêmico, ainda não há uma ferramenta para coleta de métricas em código-fonte Lua. 78

7 Como neste trabalho estamos usando sistemas de middleware implementados em Lua, desenvolvemos COMETA-Lua (Ferramenta para Coleta de Métricas de Tamanho e Acoplamento em Lua), uma ferramenta para a coleta das métricas das propriedades tamanho e acoplamento em Lua. As métricas de tamanho que foram implementadas são: (i) VS (vocabulário do sistema), (ii) LOC (número de linhas de código), (iii) NOA (número de atributos) e (iv) WOC (operações ponderadas por componentes). As métricas de acoplamento são (i) CBO (acoplamento entre classes de objetos), (ii) MPC (acoplamento por passagem de mensagem) e (iii) DAC (acoplamento por abstração de dados). Todas essas métricas foram detalhadas na Seção II. A ferramenta foi implementada com o objetivo de auxiliar a coleta das métricas nos middleware OO e OA do estudo de caso. Assim, até o presente momento, somente a coleta das métricas de tamanho e acoplamento foram automatizadas. A coleta das métricas de separação de interesses e coesão foi realizada manualmente. COMETA- Lua é composta de um conjunto de scripts. Para cada métrica a ser coletada, há um script que a computa. O funcionamento básico é o mesmo para todos os scripts. Baseia-se em um sistema de análise estática, com duas fases bem definidas: a análise léxica e a análise semântica. Na análise léxica, procura-se por tokens relevantes para a coleta de métricas. A análise semântica coleta os resultados da medição de acordo com os tokens produzidos pela análise léxica. O cálculo das métricas ocorre por passos. Toda vez que se encontra um token no código que contribua para o valor da métrica, o valor correspondente ao elemento é somado, computando-se um valor parcial para a métrica ou armazenando-se alguma informação relevante para posterior avaliação. Somente ao fim do código é que se tem o valor final da métrica. De forma que a análise léxica e a análise semântica na implementação da ferramenta estão sobrepostas. C. Resultados Segundo o exposto na Seção II, as propriedades a serem avaliadas em fase de refatoração são modularidade e tamanho. Esta subseção apresenta os resultados da medição através da aplicação das métricas referentes a essas propriedades. A tabela 1 mostra os resultados para as métricas de tamanho VS e LOC para os dois sistemas de middleware. O AO-Oil apresentou um aumento de 17.9% no número de entidades em relação ao OiL. Em relação ao número de linhas, o AO-OiL possui 7.6% mais linhas de código que o OiL. É possível dizer que a refatoração acarretou em um pequeno aumento nessas duas medidas de tamanho. Para separar o código-base do código de interesses que estavam entrelaçados no OiL, foi necessário criar novas classes e aspectos no AO-OiL, de forma a prover a separação de interesses. Por isso o aumento no número de entidades e o aumento no número de linhas de código na versão refatorada. Para facilitar a apresentação dos resultados restantes, os módulos dos sistemas de middleware OiL e AO-OiL foram divididos em três categorias: (i) módulos referentes a definição e inicialização do middleware, (ii) módulos referentes à implementação do kernel do middleware e (iii) módulos referentes à implementação da especificação CORBA. Gráficos comparativos para as métricas NOA e WOC podem ser vistos na Fig. 3, respectivamente nos lados esquerdo e direito da figura. Por serem muitas entidades e, por motivo de espaço, não ser possível apresentar os resultados para cada uma, apresenta-se então uma média calculada da seguinte forma: soma dos resultados para a métrica de todas as entidades dividida pelo número de entidades. TABLE I. Middleware RESULTADOS DA MEDIÇÃO PARA AS MÉTRICAS VS E LOC. VS Métricas de tamanho LOC OiL AO-OiL Para facilitar a apresentação dos resultados restantes, os módulos dos sistemas de middleware OiL e AO-OiL foram divididos em três categorias: (i) módulos referentes a definição e inicialização do middleware, (ii) módulos referentes à implementação do kernel do middleware e (iii) módulos referentes à implementação da especificação CORBA. Gráficos comparativos para as métricas NOA e WOC podem ser vistos na Fig. 3, respectivamente nos lados esquerdo e direito da figura. Por serem muitas entidades e, por motivo de espaço, não ser possível apresentar os resultados para cada uma, apresenta-se então uma média calculada da seguinte forma: soma dos resultados para a métrica de todas as entidades dividida pelo número de entidades. Figure 3. Resultados da medição para as métricas de tamanho NOA e WOC. Como a refatoração do OiL contemplou distribuição e coordenação, as mudanças foram feitas nos módulos de kernel do middleware. Poucas mudanças foram necessárias nos módulos referentes à definição e inicialização do middleware e à implementação do CORBA. Por isso, para as três categorias avaliadas, somente os resultados para os módulos de implementação do kernel apresentam diferenças entre o OiL e o AO-OiL. Enquanto a média do número de atributos diminuiu no AO-OiL em 15,5% em relação ao OiL, a média do número de operações pesadas 79

8 por parâmetros subiu 40,5% no AO-OiL. O aumento considerável de WOC no AO-OiL deve-se à definição de novas operações para que fosse possível separar códigobase do código dos interesses dentro das operações. Para avaliar a modularidade, é necessário avaliar as métricas de separação de interesses, acoplamento entidadeentidade e coesão. Os resultados para a medição de tais métricas estão na tabela 2. CDC e CDO obtiveram resultados um pouco melhor para o OiL do que para o AO- OiL. Isso significa que os interesses estão implementados em um maior número de módulos e operações. Em contrapartida, o AO-OiL apresentou um resultado significativamente menor para CDLOC, indicando que o seu código encontra-se menos entrelaçado no que diz respeito à implementação dos interesses. Com a refatoração, foram criadas novas entidades e novas operações destinadas aos códigos dos interesses, separando-os do código-base. Por esse motivo, assim como houve um aumento de VS e WOC, foram registrados maiores valores para CDC e CDO para o AO-OiL. O valor consideravelmente baixo para CDLOC indica que há menos entrelaçamento dos códigos de interesses e base dentro de uma mesma entidade na versão refatorada. TABLE II. Middleware RESULTADOS DA MEDIÇÃO PARA AS MÉTRICAS SEPARAÇÃO DE INTERESSES. Métricas de separação de interesses OiL AO-OiL CDC CDO CDLOC O acoplamento entidade-entidade é avaliado através das métricas CBO, DAC e MPC. A granularidade considerada para essa métrica é categoria de classes: um conjunto de entidades pertencem a uma mesma categoria se implementam uma mesma funcionalidade, ou seja, têm um mesmo objetivo. Entre classes de uma mesma categoria, o acoplamento não é um fator negativo, mas algo esperado [16]. No OiL e AO-OiL, classes pertencentes a uma mesma categoria são agrupadas em módulos. Assim como para as métricas de tamanho NOA e WOC, os resultados das da medição através das métricas de acoplamento são apresentados como uma média (soma dos valores de cada métrica para todos os módulos dividida pelo número de módulos). A Fig. 4 apresenta gráficos comparativos para essas métricas respectivamente no lado esquerdo, centro e lado direito da figura. Pode-se observar que o OiL apresentava baixo acoplamento entre seus módulos. Mesmo assim, os valores da medição para o AO-OiL foram ainda mais baixos, indicando que houve uma diminuição do acoplamento entre os módulos. A métrica de coesão LCC, assim como as métricas de acoplamento, foi coletada na granularidade categoria de classe. Como os interesses considerados na refatoração são apenas 2 (distribuição e coordenação), esse é o número máximo que a métrica LCC pode atingir. O número de módulos com LCC = 1 no OiL é 43 e no AO-OiL é 40. O número de módulos com LCC = 2 no OiL é 2 contra apenas 1 no AO-OiL. A partir desses resultados, observase que houve melhoria na coesão dos módulos na versãorefatorada. Pode-se fazer a seguinte avaliação sobre a modularidade. No quesito separação de interesses, é difícil afirmar qual o melhor middleware: o OiL apresentou melhores resultados de medição para as métricas CDC e CDO e o AO-Oil, melhores resultados para CDLOC. Quanto à coesão e acoplamento, o AO-OiL apresentou melhores resultados para a medição de todas as métricas. Posto isso, pode-ser afirmar que o AO-OiL apresenta melhor modularidade que o OiL. Quanto ao tamanho, o OiL apresenta menor número de entidades, menor número de linhas de código e menor soma de operações ponderadas por parâmetros do que o AO-OiL. O AO-OiL obteve resultado menor apenas para o número de atributos, devido a RE-AspectLua não permitir a definição de atributos dentro de aspectos. Assim, pode-se concluir que, com relação ao tamanho, o AO-OiL é maior do que o OiL. O processo de refatoração acarretou em melhorias na modularidade, mas também aumento no tamanho. Essa relação entre melhorias na modularidade (maior separação de intesses, menor acoplamento e maior coesão) e maior tamanho após a refatoração foi também observada nos trabalhos [12] e [3]. Figure 4. Resultados da medição para as métricas de acoplamento CBO, DAC e MPC. 80

9 Para comparar o desempenho dos sistemas de middleware, considerou-se o tempo necessário para realizar 300 invocações remotas a serviços. O OiL demorou segundos contra segundos gastos pelo AO-OiL para a realização da mesma tarefa, resultando em um overhead de segundos do AO- OiL. Pode-se dizer que é um custo aceitável diante dos benefícios trazidos pela refatoração, como por exemplo, melhor modularidade. Segundo [12], um maior número de componentes (VS) na versão OA não pode ser visto como um ponto negativo, mas como uma evidência do aumento da modularidade. O mesmo pode ser concluído para o maior número de entidades no AO-OiL, em comparação ao OiL. O aumento nos resultados da métrica WOC para o AO-OiL é também reflexo da melhoria na modularidade. Para melhor organizar o sistema, foi necessário definir mais operações, de forma a separar melhor os interesses. Como conseqüência de maior VS e maior WOC, os valores de CDC e CDO também foram superiores para o AO-OiL, indicando que há mais entidades e mais operações cujo principal propósito é implementar um interesse. O código referente a um interesse que, no OiL, fazia parte de uma entidade cujo principal propósito era implementar funcionalidades do código-base, passa a ser, no AO-OiL, um componente separado, incrementando o valor de CDC. O mesmo acontece com trechos de código dentro de operações cujo propósito era implementar funcionalidades do código-base no OiL e passam a ser implementados separadamente no AO-OiL, incrementando o valor de CDO. Os valores coletados para CDLOC argumentam a favor desse raciocínio: no AO-OiL, o CDLOC é consideravelmente menor que no OiL, uma vez que há menor entrelaçamento entre código de interesses e código base dentro de uma mesma entidade. IV. TRABALHOS RELACIONADOS Embora não se tenha conhecimento de trabalhos que apresentem um conjunto de métricas para avaliação de middleware de forma mais abrangente e sistemática, encontrou-se na literatura um trabalho relacionado para avaliação de refatoração de middleware e diversos trabalhos sobre avaliação de sistemas OA. No trabalho de avaliação de refatoração de middleware [23] os autores abordam a avaliação de middleware OA definindo um conjunto de métricas, mas tratam apenas do processo de refatoração de middleware, com foco na implementação. Apesar de nosso trabalho aproveitar essa abordagem para a definição das métricas relacionadas a refatoração, avaliamos também outras propriedades importantes em outras fases de desenvolvimento (design e implementação). Em [6] apresenta-se um conjunto de propriedades a serem avaliadas no processo de refatoração de um sistema distribuído. Cada propriedade é avaliada com base na experiência do desenvolvedor. A única métrica utilizada é LOC (linhas de código). Segundo o autor, sua avaliação é mais subjetiva do que científica. Nosso trabalho define uma lista de propriedades estáticas baseada nas propriedades de [6], mas para tornar o processo de avaliação menos subjetivo, atribuímos diversas métricas para avaliar cada propriedade. Em [19] é apresentado um modelo de qualidade para avaliar reusabilidade e manutenibilidade em software OA que define como medir essas duas propriedades com base em métricas. O modelo ainda auxilia na interpretação dos dados coletados. As métricas definidas são aplicadas nas fases de design e de implementação. Nosso trabalho baseia-se nesse trabalho para avaliar a manutenibilidade do conjunto de propriedades estáticas e também para as métricas de separação de interesses (CDC, CDO, CDLOC) e tamanho (VS, LOC, NOA e WOC). No nosso trabalho avaliamos outras propriedades além de manutenibilidade, como modularidade, flexibilidade, tamanho e complexidade. Nosso trabalho também se baseia em [20] para definir a métrica LCC de coesão e também os fatores que influenciam a propriedade modularidade. Em [4] os autores propõem um conjunto de métricas para investigar a relação custo-benefício do uso da programação OA. Os autores apresentam ainda uma ferramenta para coleta dessas métricas de código em AspectJ. Não há um conjunto bem definido de propriedades que são avaliadas. Nesse ponto difere do nosso trabalho, que define uma relação entre métrica e propriedade a ser avaliada. Tal trabalho serviu como base para definirmos métricas para avaliação de acoplamento código base-aspectos. V. CONCLUSÕES Este artigo apresentou um conjunto de métricas para avaliação estática e dinâmica de middleware OA. Propusemos um conjunto de propriedades importantes para middleware OA (modularidade, flexibilidade, manutenibilidade, tamanho, complexidade, desempenho e consumo de memória) e as métricas associadas a cada propriedade. As métricas adotadas no trabalho são bem conhecidas para avaliação de sistemas OO. As métricas de avaliação de herança (DIT e NOC) e de complexidade (RFC) foram incorporadas neste trabalho e adaptadas para o paradigma OA de [5]. As métricas de avaliação de acoplamento entidade-entidade (CBO, MPC e DAC) foram também foram incorporadas neste trabalho e adaptadas para o paradigma OA do framework de acoplamento de [1]. A ferramenta CoMeTA-Lua permitiu agilizar o processo de avaliação por automatizar a coleta de métricas de tamanho e acoplamento. A ferramenta permite coletar métricas não somente no OiL e no AO-OiL, mas também em todo middleware construído em Lua. Por exemplo, como trabalho futuro aplicaremos as métricas no Aspect- OpenOrb [3]. Os estudos de caso realizados permitiram ilustrar o uso do conjunto de propriedades, métricas e da ferramenta proposta no âmbito da comparação de duas versões de um middleware: uma OO e outra AO. AGRADECIMENTOS Este trabalho foi parcialmente suportado pela ANP através da ANP/PRH-22 para Tássia Freitas. 81

10 [1] L.C. Briand, J.W. Daly, and J. Wüst, A unified framework for coupling measurement on object-oriented systems, IEEE Transactions on Software Engineering, vol. 25, Jan./Fev. 1999, pp , doi: / [2] L.C. Briand, S. Morasca, and V.R. Basili, Measuring and assessing maintainability at the end of the high level design, Proc. of the Conf. on Software Maintenance, 1993, pp [3] N. Cacho, T. Batista, A. Garcia, C. Sant Anna, and G. Blair, Improving modularity of reflective middleware with aspectoriented programming, Proc. of the 6th Int. Workshop on SE. and Middleware, 2006, pp , doi: / [4] C. Ceccato, and P. Tonella, Measuring the effects of software aspectization, Proc. of the 1st Workshop on Aspect Reverse Engineering [5] S.R. Chidamber, C.F. Kemerer, "A Metrics Suite for Object Oriented Design," IEEE Transactions on Software Engineering, vol. 20, June 1994, pp , doi: / [6] C. Driver, Evaluation of the Aspect-Oriented Software Development for Distributed Systems. Dissertação (Mestrado) Universidade de Dublin, [7] B. Dufour, C. Goard, L. Hendren, O. de Moor, G. Sittampalam, and C. Verbrugge Measuring the dynamic behaviour of AspectJ programs, SIGPLAN, vol. 39, Oct. 2004, pp , doi= / [8] T. Elrad, R.E. Filman, and A. Bader, Aspect-oriented programming: introduction, Commun. ACM, vol. 44, Oct. 2001, pp , doi: / [9] E. Figueiredo, C. Sant'Anna, A. Garcia, T.T. Bartolomei, W. Cazzola, and A. Marchetto, On the maintainability of the aspectoriented software: a concern-oriented measurement framework, 12th European Conf. on Software Maintenance and Reengineering (CSMR 2008), April 2008, pp , doi: /CSMR [10] A. Garcia, C. Sant'Anna, E. Figueiredo, U. Kulesza, C. Lucena, and A. von Staa, Modularizing design patterns with aspects: a quantitative study, Proc. of the 4th Int. Conf. on Aspect-Oriented software development (AOSD 05), 2005, pp. 3-14, doi: / [11] JbossAOP. Framework for Organizing Cross Cutting Concerns, july [12] U. Kulesza, C. Sant'Anna, A. Garcia, R. Coelho, A. von Staa, and C. Lucena, Quantifying the effects of aspect-oriented programming: a maintenance study. 22nd IEEE Int. Conf. on Software Maintenance (ICSM 06), Sept. 2006, pp , doi: /ICSM [13] N. Loughran, N.Parlavantzas, M.Pinto, P. Sánchez, M. Webster, A. Colyer. Survey of Aspect-Oriented Middleware, June [14] R. Ierusalimschy, Programming in Lua, Lua.org, 2nd edition, [15] R. Maia, R. Cerqueira, and R. Cosme, OiL: an object requester broker in the Lua language, Anais da sessão de ferramentas do Simposio Brasileiro de Redes de Computadores (SBRC'06), [16] R. Martin, OO Design quality metrics, Proc. of the Workshop Pragmatic and Theoretical Directions on Object-Oriented Software Metrics, [17] A. Popovici, T. Gross, and G. Alonso, Dynamic Weaving for aspect-oriented software: an assessment framework, Proc. of the 2nd Int. Conference on Aspect-oriented software development (AOSD 02), April 2002, pp , doi: / [18] D. Salim, D. Um Sistema Distribuído para Monitoramento de Poços de Petróleo com Elevação Artificial. Monografia de conclusão de curso (Graduação em Engenharia da Computação), Universidade Federal do Rio Grande do Norte, [19] C. Sant'Anna, A. Garcia, C. Chavez, C. Lucena, and A. von Staa, On the reuse and maintenance of aspect-oriented software: an assessment framework, Proc. of Brazilian Symposium on Software Engineering (SBES 03), 2003, pp [20] C.N. Sant'Anna, On The Modularity of Aspect-Oriented Design: a concern-driven measurement approach. Tese (Doutorado) PUC- Rio, Rio de Janeiro, [21] J. Silva, T. Batista, F. Delicato, and P. Pires, Um middleware orientado a aspectos baseado em uma arquitetura de referência, Workshop de Teses e Dissertações em Engenharia de Software (WTES), [22] E. Truyen, B. Vanhaute, B.N. Jørgensen, W. Joosen, and P. Verbaeton, Dynamic and Selective combination of extensions in component-based applications, Proc. of the 23rd International Conference on Software Engineering, 2001, pp [23] C. Zhang, and H. Jacobsen, Quantifying aspects in middleware plataforms, Proc. of the 2nd International Conference on Aspect- Oriented Software Development (AOSD 03), March 2003, pp , doi: /