Extração de Linhas de Produtos de Software

Transcrição

1 Extração de Linhas de Produtos de Software Um Estudo de Caso Usando Diretivas de Pré-Processamento Marcus Vinícius de Ávila Couto Instituto de Informática Pontifícia Universidade Católica de Minas Gerais Marco Túlio Valente, Eduardo Figueiredo Departamento de Ciência da Computação Universidade Federal de Minas Gerais Resumo Abordagens de desenvolvimento de Linhas de Produtos de Software (LPS) estão cada vez mais atraindo a atenção da indústria e da academia. Tais abordagens propõem o reúso sistemático e em larga escala de componentes que implementam funcionalidades comuns (chamadas features) a mais de um produto em um domínio específico. Apesar do ganho de popularidade, ainda são escassas implementações públicas de LPS de médio a grande porte. A pesquisa atual nesta área geralmente se vale de pequenos sistemas sintetizados em laboratório para demonstrar ou avaliar conceitos e princípios básicos de LPS. Esses estudos são certamente úteis, mas limitados, por não permitirem uma avaliação mais ampla da escalabilidade de abordagens de LPS. Para minimizar esse problema, este artigo relata uma experiência prática de extração de uma linha de produtos de software a partir de um sistema real chamado ArgoUML. O código responsável por quatro features que abrangem cerca de 23% das 76 KLOC do sistema foi delimitado usando diretivas de pré-processamento. O artigo faz então uma análise quantitativa do código das features delimitadas sobre quatro perspectivas: tamanho, granularidade, transversalidade e localização. O resultado de tal análise nos permite identificar cenários propícios ou não para utilização das diversas técnicas existentes para implementação de LPS. I. Introdução Linhas de Produtos de Software (LPS) constitui uma abordagem emergente para projeto e implementação de sistemas que procura promover o reúso sistemático de componentes de software [1], [2]. O objetivo final é migrar para uma cultura de desenvolvimento onde novos sistemas são sempre derivados a partir de um conjunto de componentes e artefatos comuns (os quais constituem o núcleo da linha de produtos). Além de componentes do núcleo, uma linha de produtos inclui componentes responsáveis pela implementação de features que somente são necessárias em determinados domínios ou ambientes de uso. Assim, um produto específico de uma LPS é gerado compondo-se os componentes do núcleo com componentes que implementam as features particulares desse produto. Os princípios básicos de linhas de produtos de software foram propostos a cerca de 10 anos (ou até há mais tempo, visto que em essência eles apenas procuram sistematizar estratégias de reúso que sempre nortearam o projeto e implementação de sistemas [3]). No entanto, de um ponto de vista de implementação, ainda não se tem conhecimento de implementações públicas de linhas de produtos de software envolvendo sistemas de médio para grande porte. Normalmente, trabalhos de pesquisa nessa área se valem de sistemas de pequeno porte, que foram integralmente implementados em laboratório pelos próprios autores desses trabalhos. Como exemplo, podemos citar as seguintes linhas de produtos: Expression Product Line [4], Graph Product Line [5] e Mobile Media Product Line [6]. Certamente, linhas de produtos sintetizadas em laboratórios são úteis para demonstrar, avaliar e promover os princípios básicos dessa abordagem de desenvolvimento. Adicionalmente, elas tornam mais simples a investigação e aplicação de novas técnicas, ferramentas e linguagens com suporte a linhas de produtos. Por outro lado, devido a sua própria natureza, sistemas de laboratório não permitem uma avaliação mais precisa sobre a escalabilidade e aplicabilidade de abordagens de desenvolvimento orientadas por linhas de produtos. Em resumo, sendo um recurso para reúso em larga escala, é fundamental avaliar se os resultados recentes de pesquisas na área de LPS via de regra obtidos em laboratórios podem ser extrapolados para ambientes e sistemas reais de programação. Assim, descreve-se neste artigo uma experiência prática de extração de uma linha de produtos de software a partir de um sistema real. O sistema alvo dessa experiência foi o ArgoUML, uma ferramenta de código aberto largamente utilizada para projeto de sistemas em UML. Na versão analisada do sistema, a implementação de diversas features opcionais encontra-se entrelaçada com a implementação de funcionalidades mandatórias da ferramenta. Mais especificamente, descreve-se no trabalho uma experiência por meio da qual o código responsável por quatro features importantes porém não imprescindíveis ao funcionamento do sistema foi delimitado usando-se diretivas de pré-processamento. Com isso, viabilizou-se a geração de produtos de ArgoUML sem uma ou mais destas features opcionais. A versão analisada do ArgoUML possui cerca de 76 KLOC, sendo que dessas linhas cerca de 14 KLOC foram marcadas como pertencentes a pelo menos uma das quatro features consideradas no estudo. Tais números são bastante superiores a qualquer outra experiência que conhecemos de extração de features documentada na literatura.

2 Adicionalmente, apresenta-se no artigo uma análise e caracterização detalhada da LPS extraída. Basicamente, nessa análise procura-se fornecer informações sobre o tamanho das features extraídas (em linhas de código), sobre o grau de transversalidade das features extraídas, sobre a granularidade dos componentes responsáveis pela implementação das features e sobre localização sintática dos trechos de código responsáveis pela implementação das features extraídas. O restante desse artigo está organizado conforme descrito a seguir. Na Seção II, apresenta-se uma visão geral da linha de produtos proposta, denominada ArgoUML- SPL, incluindo uma descrição da arquitetura do sistema base (ArgoUML) e das features extraídas para essa linha de produtos. Na Seção III, descreve-se o processo de extração, detalhando a metodologia usada para delimitação das features por meio de diretivas de pré-processamento. Na Seção IV, realiza-se uma análise quantitativa das features extraídas, usando para isso métricas de tamanho, transversalidade, granularidade e localização no código. A Seção V discute como as features extraídas podem ser classificadas, de acordo com alguns padrões normalmente utilizados na literatura. Essa seção apresenta também alguns desafios e problemas que seriam enfrentados caso se desejasse modularizar as features consideradas no trabalho usando orientação por aspectos. Por fim, a Seção VI discute trabalhos relacionados e a Seção VII conclui o artigo, apresentando também possíveis linhas de trabalhos futuros. linguagens Java, C++ e Python são exemplos de subsistemas carregáveis. Baixo Nível: são subsistemas responsáveis por tarefas como configuração, internacionalização, gerenciamento de tarefas, gerenciamento de modelos e para implementação de interfaces gráficas. Controle e Visão: são subsistemas responsáveis por controlar os outros subsistemas. Alto Nível: é o subsistema responsável por inicializar os demais subsistemas, ou seja, contém o método main() da aplicação. Cada subsistema que é utilizado por outros subsistemas deve prover dois meios de comunicação: uma classe de fachada (Padrão Facade [9]) e uma API com métodos públicos ou protegidos. A classe de fachada provê as funções mais comuns para que os subsistemas comuniquemse uns com os outros. Isto reduz a necessidade de utilizar outros métodos além daqueles providos pelas classes de fachada. As APIs que proveem acesso a métodos públicos ou protegidos são utilizadas quando não é conveniente a utilização de classes de fachada em uma determinada implementação. Em resumo, na arquitetura planejada do ArgoUML, uma classe de fachada é parte de uma API ou uma versão simplificada de uma API. II. ArgoUML-SPL A extração de uma LPS a partir de uma versão monolítica da ferramenta ArgoUML teve como objetivo principal disponibilizar à comunidade de pesquisadores da área uma linha de produtos real, criada a partir de um software relevante, maduro e de relativa complexidade. A ferramenta ArgoUML é um sistema de código aberto, largamente utilizada para modelagem de sistemas em UML. O sistema encontra-se implementado em Java e possui aproximadamente 76 KLOC. A. Arquitetura O ArgoUML possui uma arquitetura em camadas, apresentada na Figura 1. Essa arquitetura inclui os seguintes subsistemas [8]: Externos: são bibliotecas de terceiros utilizadas no ArgoUML e que não são mantidas pelo projeto, tais como bibliotecas para edição gráfica e para especificação de restrições em OCL. Carregáveis: são subsistemas que devem ser conectados ao ArgoUML apenas por meio de interfaces providas por outros subsistemas, o que permite habilitá-los ou desabilitá-los através de um módulo de carregamento. Esses módulos funcionam como plugins que podem ser acrescentados ao ArgoUML. Os módulos de geração de código e engenharia reversa para as B. Features Figura 1. Arquitetura do ArgoUML-SPL. Para criação do ArgoUML-SPL, foram selecionadas quatro features representando requisitos funcionais e não funcionais do sistema. A feature Logging é um representante dos requisitos não funcionais do sistema. Essa feature tem por finalidade registrar eventos de exceções e informações para debug, sendo que a sua escolha deveu-se à sua natureza espalhada e entrelaçada ao código base do sistema. As outras três features escolhidas representam requisitos funcionais. São elas: Suporte Cognitivo, Diagrama de Estados e Diagrama de Atividades. A feature Suporte Cognitivo tem por finalidade prover informações aos projetistas para auxiliá-los a detectar

3 e resolver problemas em seus projetos [10]. A feature é implementada por agentes de software que ficam em execução contínua em segundo plano efetuando análises sobre os diagramas criados, com a finalidade de detectar eventuais problemas nos mesmos. Esses agentes podem recomendar boas práticas a serem seguidas na construção do modelo, fornecer lembretes sobre partes do projeto que ainda não foram finalizadas ou sobre a presença de erros de sintaxe, dentre outras tarefas. A feature Diagrama de Estados tem por finalidade acrescentar ao sistema a opção de criação de diagramas de estado, que são diagramas UML usados para mapear os possíveis estados de um objeto. A feature Diagrama de Atividades acrescenta ao sistema a possibilidade de criação de diagramas de atividade, que são diagramas UML que descrevem o do fluxo de dados de um sistema. Além de representarem funcionalidades relevantes do sistema, essas duas features foram selecionados pelo fato de possuírem código compartilhado e, portanto, podem fornecer cenários interessantes ao se efetuar a refatoração do sistema. O modelo de features atual da linha de produtos ArgoUML-SPL é mostrado na Figura 2. Nesse modelo, define-se que os diagramas de classes, caso de uso, colaboração, implantação e sequência são obrigatórios 1 ; já Diagrama de Estados, Diagrama de Atividades, Suporte Cognitivo e Logging são consideradas features opcionais. ao utilizar pré-processadores no trabalho, pretendeu-se disponibilizar uma LPS que servisse como benchmark [14] para outras tecnologias de modularização, como orientação por aspectos. Em outras palavras, pretende-se com o ArgoUML-SPL disponibilizar um sistema-desafio, que contribua para avaliar o real poder de expressão de técnicas modernas de modularização e separação de interesses. Como Java não possui suporte nativo para diretivas de pré-processamento, foi utilizada uma ferramenta denominada javapp 2. Essa ferramenta disponibiliza diretivas similares àquelas existentes em C/C++, incluindo #ifdef, #ifndef e #else. Basicamente, tais diretivas informam ao pré-processador se o código fonte delimitado pela diretiva deve ou não ser compilado. Dessa maneira, é possível selecionar os trechos de código que estarão presentes na versão final de um determinado produto. A Figura 3 apresenta um exemplo de código anotado. Nessa figura, o código da linha 3 foi anotado como pertencente à feature Suporte Cognitivo, ou seja, essa linha será incluída apenas em produtos que incluam tal feature. Por outro lado, o código da linha 5 somente será incluído em produtos que não incluam a feature Suporte Cognitivo. 1 JPanel todopanel ; 2 //#i f COGNITIVE 3 todopanel = new ToDoPane ( s p l a s h ) ; 4 //#e l s e 5 todopanel = new JPanel ( ) ; 6 //#e n d i f Figura 3. Exemplo de código anotado Figura 2. Modelo de Features atualmente implementado. III. Processo de Extração A tecnologia de pré-processadores foi empregada na extração da linha de produto de software que originou o projeto ArgoUML-SPL. Claramente, diretivas de préprocessamento são conhecidas por sua capacidade de poluir o código com anotações extras, tornando-o menos legível e mais difícil de entender, manter e evoluir [11], [12], [13]. Por outro lado, pré-processadores também possuem algumas vantagens, incluindo a facilidade de utilização e entendimento. Mais importante, pré-processadores permitem a anotação de qualquer trecho de código. Ou seja, eles constituem a tecnologia mais primitiva e ao mesmo tempo mais poderosa para marcação de features. Assim, 1 O modelo de features mostrado representa a versão atual da LPS extraída no trabalho. Por isso, os diagramas UML não delimitados com diretivas de pré-processamento foram considerados mandatórios. Para automatizar a geração dos dezesseis possíveis produtos da LPS implementada, foi utilizado um conjunto de scripts ant. Basicamente, esses scripts permitem que os desenvolvedores informem quais features devem ser incluídas em um determinado produto. Feito isso, eles se encarregam da execução do pré-processador javapp, bem como da compilação e empacotamento do produto selecionado pelo desenvolvedor. Anotação do Código: A identificação dos elementos de código do ArgoUML pertencentes a uma determinada feature foi feita manualmente por um dos pesquisadores envolvidos na criação da LPS. Como esse pesquisador não era especialista na ferramenta, o primeiro passo para essa extração consistiu em um estudo detalhado da arquitetura do sistema, principalmente com o auxílio de seu cookbook [8]. Após um entendimento básico da arquitetura do ArgoUML, o seu código fonte foi estudado a fim de identificar os pontos em que cada feature era demandada. Nesta tarefa de exploração do código fonte, utilizou-se o ambiente de desenvolvimento Eclipse. Os recursos de busca textual e busca por referências dessa IDE foram extensivamente usados para auxiliar na localização dos trechos de código 2 Disponível em

4 relativos a cada uma das features. Neste processo, uma vez identificado que um determinado trecho de código X apenas deveria ser compilado caso uma determinada feature F fosse selecionada, procedia-se à sua delimitação por meio de anotações tais como #ifdef e #endif. O ArgoUML possui diversas classes responsáveis pela automatização de testes unitários. Essas classes, criadas com apoio do framework JUnit, não foram anotadas e portanto, não fazem parte do ArgoUML-SPL. Inicialmente, a validação dos diversos produtos gerados pela LPS extraída foi feita por meio de testes funcionais, do tipo caixa preta. Esses testes visaram principalmente a validação do produto gerado de acordo com a seleção de features efetuada. Em tais testes foi avaliada a estabilidade do sistema e comparado o funcionamento do ArgoUML original com o produto gerado pela LPS. Por exemplo, suponha um produto com todas as features, exceto Diagrama de Estados. Durante os testes, esse produto foi gerado e então executado para avaliar o seu correto funcionamento (isto é, se no produto gerado a opção de criação de diagrama de estados tinha sido de fato removida). Esse procedimento foi repetido para todos as features opcionais da LPS extraída. A segunda parte da validação consistiu em uma inspeção manual de todo código fonte do sistema, a fim de verificar se os elementos sintáticos responsáveis por cada feature haviam sido de fato anotados. Ao final desse processo, a LPS extraída foi enviada para os projetistas do sistema ArgoUML, que após avaliação aprovaram a sua hospedagem no website oficial da comunidade. O principal critério para aprovação do ArgoUML- SPL como um dos sub-projetos de ArgoUML foi a sua potencial contribuição para evolução e modernização da ferramenta. Espera-se que essa hospedagem pública no repositório de versões do ArgoUML possa atrair desenvolvedores interessados em ampliar o número de features atualmente disponibilizadas pela LPS. IV. Caracterização da LPS Extraída A fim de estudar propriedades das features anotadas, foram coletados quatro conjuntos de métricas: métricas de tamanho, métricas de transversalidade, métricas de granularidade e métricas de localização. Essas métricas e os valores coletados para elas serão detalhados nas próximas subseções. A. Métricas de Tamanho Essas métricas se destinam a medir o total de linhas de código, classes e pacotes envolvidos em cada feature do sistema. Mais especificamente, foram coletadas as seguintes métricas: LOC (Lines Of Code): conta o total de linhas de código, sem comentários e linhas em branco, para cada produto gerado pela LPS; #Pacotes: conta o número de pacotes presentes em cada produto gerado pela LPS; #Classes: conta o número de classes presentes em cada produto gerado pela LPS; LOF (Lines Of Feature): proposta por Liebig et al. [15], essa métrica conta o total de linhas de código, sem comentários e linhas em branco, responsáveis pela implementação de cada feature, ou seja, a quantidade de linhas de código no interior das diretivas #ifdef e #endif que delimitam cada feature extraída na LPS. Logo, a métrica LOF equivale à diferença entre o LOC do produto com todas as features e o LOC do produto gerado sem a feature correspondente. A Tabela I apresenta os valores medidos para as métricas de tamanho em diferentes produtos do ArgoUML- SPL. A primeira coluna dessa tabela informa qual feature foi removida no produto onde a métrica foi medida. Análise de Tamanho: Como pode ser observado na Tabela I, Suporte Cognitivo é a feature que possui maior LOF. Além disso, o produto gerado sem essa feature é aquele com o menor número de classes e pacotes, o que nos leva a observar que ela se encontra devidamente modularizada em módulos específicos do sistema. Por outro lado, as features Diagrama de Atividades e Diagrama de Estados compartilham vários trechos de código e possuem implementações equivalentes, o que faz com que elas possuam tamanhos semelhantes. Logging diferencia-se das demais features por ser a única cuja remoção não implica em diminuição no número de classes do sistema. Esta característica deve-se ao fato de a feature utilizar uma biblioteca externa (Log4J 3 ). Assim, nenhuma classe do sistema implementa exclusivamente Logging. No entanto, esta feature se espalha por diversas classes do ArgoUML-SPL. Por fim, é interessante notar que um produto que não tenha nenhuma das features propostas terá um tamanho 22,58% menor do que um produto que tenha todas as features, o que sugere benefícios em termos de customização e personalização. Ou seja, em vez de uma abordagem monolítica do tipo one-size-fits-all a linha de produtos permite que usuários possam dispor de um sistema com um tamanho mais adequado às suas reais necessidades. B. Métricas de Transversalidade Essas métricas se destinam a medir o comportamento transversal das features extraídas no ArgoUML-SPL. Mais especificamente, foram coletadas as seguintes métricas: SD (Scattering Degree): proposta por Liebig et al. [15], essa métrica conta o número de ocorrências das constantes que definem cada feature. Ou seja, dada uma constante que define uma determinada feature, SD conta em quantas expressões do tipo #ifdef ela está presente. TD (Tangling Degree): para cada par de features da LPS, essa métrica conta o número de ocorrências de 3 Disponível em

5 Tabela I Métricas de tamanho Métricas Feature Removida LOC #Pacotes #Classes LOF ArgoUML-SPL (Sem remoção de nenhuma Features) Suporte Cognitivo ,04% Diagrama de Atividades ,98% Diagrama de Estados ,67% Logging ,07% Todas ,58% operadores do tipo AND e OR envolvendo essas features em diretivas usadas para anotação do código fonte. A Figura 4 apresenta um trecho de código em que essa situação ocorre. Nesse trecho, TD(Diagrama de Atividades, Diagrama de Estados) = 3, pois existe um #ifdef no qual essas duas features estão combinadas por meio de um operador AND (linha 10 8) e dois #ifdefs nos quais as duas features estão //#e n d i f 11 combinadas por um OR (linhas 1 e 22). Proposta12 //#i f ACTIVITYDIAGRAM originalmente neste artigo, o objetivo da métrica TD13 14 é medir trechos de código responsáveis por interações type == DiagramType. A c t i v i t y //#e n d i f entre as features consideradas na LPS ) && machine == null ) { ND (Nested Degree): para cada par de features da17 diagram = creatediagram (... ) ; 18 } else { LPS, essa métrica conta o número de ocorrências de 19 aninhamento de trechos de código fonte anotado. A20 //#e n d i f Figura 4 apresenta um trecho de código em que essa21 diagram = creatediagram (... ) ; 22 //#i f UMLSTATEDIAGRAM or ACTIVITYDIAGRAM situação ocorre. Nesse trecho, o código da linha 5 23 } somente será incluído na compilação do sistema se a24 //#e n d i f feature Diagrama de Estados estiver selecionada ou se ambas as features Diagrama de Estados e Diagrama de Atividades estiverem selecionadas, Figura 4. Exemplo de aninhamento e entrelaçamento de código devido ao aninhamento desse trecho de código em Tabela III relação ao código da linha 1. Proposta originalmente Métricas de entrelaçamento e aninhamento neste artigo, o objetivo da métrica ND é medir a dependência entre as features consideradas na LPS. Features envolvidas TD ND A Tabela II apresenta os valores coletados para a métrica SD. Já a Tabela III apresenta os valores coletados Diagrama de Estados Diagrama de Atividades + para as métricas que medem os graus de entrelaçamento Diagrama de Atividades + e aninhamento das features consideradas no estudo. Para Logging 0 9 Diagrama de Estados + simplificar a leitura desta tabela, não é mostrado as linhas Logging 0 30 nas quais ambas as métricas TD e ND possuem valor zero. Suporte Cognitivo + Logging Tabela II Métrica de Espalhamento 1 //#i f UMLSTATEDIAGRAM or ACTIVITYDIAGRAM 2 i f ( ( 3 4 //#i f UMLSTATEDIAGRAM 5 type == DiagramType. S t a t e 6 //#e n d i f 7 8 //#i f UMLSTATEDIAGRAM and ACTIVITYDIAGRAM 9 Feature SD Suporte Cognitivo 319 Diagrama de Atividades 114 Diagrama de Estados 113 Logging 1428 Análise de Transversalidade: De acordo com os valores apresentados na Tabela II, observa-se que a feature Logging destaca-se por possuir o maior grau de espalhamento. Existem 1428 pontos do sistema onde Logging é demandado. Esse resultado comprova as citações recorrentes na literatura, nas quais Logging é sempre mencionado como um exemplo clássico de requisito transversal. No entanto, veja que Logging possui a segunda menor LOF entre as features consideradas no estudo (Tabela I). Ou seja, Logging é usado em várias partes do sistema, porém sempre demandando pouco código em cada um desses pontos (essencialmente, uma chamada a uma das rotinas de logging providas pelo framework Log4J).

6 Já a Tabela III permite pelo menos duas observações interessantes sobre as features constituintes do ArgoUML- SPL: Dentre as features consideradas no estudo, apenas Diagrama de Atividades e Diagrama de Estados possuem código entrelaçado (seja por meio de AND ou OR). Essa conclusão é importante porque um comportamento entrelaçado claramente amplifica os problemas de entendimento e legibilidade que caracterizam técnicas de anotação de código, como #ifdef e #endif. Além disso, código cuja remoção depende de mais de uma feature é mais difícil de ser fisicamente modularizado (por exemplo, por meio de técnicas como aspectos). No entanto, como mostrado na Tabela III, existem apenas 26 pontos de compartilhamento de código entre as duas features mencionadas. Dentre as features anotadas no estudo, Logging é aquela que mais aparece lexicamente aninhada em um trecho de código anotado como pertencente a outra feature. Na verdade, foram detectados aninhamentos de Logging à todas as outras features consideradas no estudo. Esse comportamento é explicado pela característica espalhada de Logging (como medido pela métrica SD) e pelo fato de Logging ser um requisito não-funcional cuja implementação é transversal a um grande número de requisitos funcionais de um sistema. Por fim, foram detectados também 11 pontos nos quais Diagrama de Atividades se encontrava aninhado em Diagrama de Estados (métrica ND). Posterior inspeção de código nos permitiu revelar que este aninhamento se justifica pelo fato de que Diagramas de Atividades serem uma especialização de Diagramas de Estados, como definido na especificação de UML. C. Métricas de Granularidade Essas métricas medem o nível hierárquico das unidades sintáticas marcadas como sendo responsáveis pela implementação de uma feature. Considera-se que uma feature possui granularidade grossa quando sua implementação ocorre principalmente em unidades sintáticas de maior nível hierárquico na gramática de Java, tais como pacotes, classes e interfaces. Por outro lado, uma feature de granularidade fina é aquela cuja presença no código se manifesta principalmente em unidades de menor nível sintático, como comandos e expressões [16]. As métricas usadas no trabalho para medir a granularidade de uma feature são as seguintes: Package: conta as ocorrências de anotações de um pacote inteiro (todas as classes ou interfaces) utilizadas para a implementação de uma feature. Class: conta as ocorrências de anotações de classes ou interfaces inteiras para a implementação de uma feature. ClassSignature: conta as ocorrências de anotações para implementação de uma feature que incidem sobre assinaturas de classes, como elementos extends ou implements da sintaxe Java. InterfaceMethod: conta as anotações de métodos de uma interface para a implementação de uma feature. Method: conta as anotações de métodos inteiros (assinatura e corpo) para a implementação de uma feature. MethodBody: conta as ocorrências de anotações realizadas apenas sobre o corpo de um método, para a implementação de uma determinada feature. Statement: conta as ocorrências de anotações realizadas apenas em comandos e expressões, incluindo chamadas de método, atribuições, comandos condicionais, comandos de repetição, etc. Para todas as métricas de granularidade, a contagem não ocorre quando o elemento em questão já tenha sido contabilizado na contagem das métricas anteriores. Por exemplo, a contagem da métrica Class não considera uma classe ou interface pertencente a pacotes inteiramente anotados e, portanto, contados como parte da métrica Package. Nesse artigo, considera-se a seguinte divisão para elementos sintáticos de granularidade grossa e fina: Granularidade grossa: Package, Class, MethodBody, Method e InterfaceMethod. Granularidade fina: ClassSignature e Statement. A Tabela IV apresenta os valores medidos para as métricas de granularidade propostas. Análise de Granularidade: Duas constatações principais surgem de uma análise dos resultados mostrados Tabela IV: A implementação das features Suporte Cognitivo, Diagrama de Atividades e Diagrama de Estados demandou tanto a anotação de elementos de granularidade grossa como de granularidade fina. Isso demonstra que parte do código dessas features encontra-se devidamente modularizada em elementos como pacotes, classes e interfaces. Por outro lado, esses elementos são referenciados em outras partes do código, em elementos de menor granularidade. Em resumo, a implementação dessas features está modularizada, mas não o seu uso no restante do código. Logging é uma feature de granularidade fina, isto é, sua implementação ocorre em poucos métodos (e em nenhuma classe ou pacote). Por outro lado, ela é demandada em 1155 comandos do código. D. Métricas de Localização Essas métricas procuram prover informações sobre a localização sintática dos elementos anotados para implementação das features consideradas no ArgoUML-SPL. As métricas desse tipo foram calculadas apenas para elementos da granularidade Statement (segundo a classificação

7 Tabela IV Métricas de granularidade Feature Granularidade Métricas Suporte Cognitivo Diag. Atividades Diag. Estados Logging Package Class Grossa InterfaceMethod Method MethodBody Fina ClassSignature Statement da subseção anterior). O objetivo é mostrar a localização dos Statement que foram anotados para cada feature, isto é, se eles ocorrem logo no início do corpo de um método, no final do corpo de um método, antes de um comando return ou aninhados à outros comandos. A inspiração para definição dessas métricas foram os modelos de pontos de junção que são encontrados em linguagens de programação orientada a aspectos como AspectJ [17]. As métricas de localização contabilizadas no trabalho foram as seguintes: StartMethod: conta as ocorrências de código anotado para implementação de uma determinada feature quando esse encontra-se no início de um método; EndMethod: conta as ocorrências de código anotado para implementação de uma determinada feature quando esse encontra-se no final de um método; BeforeReturn: conta as ocorrências de código anotado para implementação de uma determinada feature quando esse encontra-se imediatamente antes de um comando return não anotado; NestedStatememt: conta as ocorrências de código anotado para implementação de uma determinada feature quando esse encontra-se no escopo de um comando não-anotado, como em um laço de repetição ou em um comando de decisão. A Tabela V apresenta os valores medidos para as métricas de localização propostas. Análise de Localização: Dentre as quatro localizações analisadas, aquelas que podem ser diretamente instrumentadas pela linguagem de pontos de junção de AspectJ são as seguintes: StartMethod, EndMethod e BeforeReturn. No entanto, para todas as features consideradas no estudo, essas três localizações foram aquelas que ocorreram com menor frequência. A localização dominante foi sempre NestedCommand. No entanto, a modularização física de código aninhado em um bloco de comandos é mais desafiadora, requerendo, por exemplo, transformações prévias no código orientado por objetos [18], [19]. V. Discussão Esta seção apresenta e discute alguns resultados que podem ser extraídos de nosso estudo e posiciona tais resultados em relação a outros trabalhos publicados na literatura relacionada. Em particular, as subseções a seguir discutem: (A) algumas formas transversais encontradas no ArgoUML-SPL e quão prejudiciais essas formas transversais são e (B) a viabilidade de usar técnicas de desenvolvimento orientado a aspectos para separar as quatro features opcionais do ArgoUML-SPL. A. Formas Recorrentes de Features Trabalhos recentes mostraram que nem todas as formas de manifestações transversais de uma feature são prejudiciais a atributos de qualidade do sistema, como modularidade e estabilidade [20], [21], [22]. Assim, é importante estudar e identificar as features que apresentam as formas transversais mais prejudiciais. Os resultados apresentados nas Tabelas I a IV nos ajudam a identificar três formas recorrentes de manifestações transversais já documentadas na literatura: God Concern, Black Sheep e Octopus [20], [22]. God Concern ocorre quando uma feature requer uma fração expressiva do código do sistema em sua implementação [22]. Esse tipo de feature foi inspirado na definição de God Class feita por Fowler [23]. Ou seja, assim como em God Class, elementos que implementam uma feature God Concern agregam excessiva responsabilidade no sistema de software. De acordo com os dados apresentados pelas Tabelas I e IV é possível observar que a realização da feature Suporte Cognitivo tem a forma definida por God Concern. Ou seja, esta feature envolve muitas funcionalidades do sistema como, por exemplo, 11 pacotes completos e 8 classes em outros pacotes (Tabela IV). Ademais, 8761 linhas de código do sistema (13,04%) são usadas para implementar Suporte Cognitivo (Tabela I). Felizmente, estudos recentes revelam pouca correlação entre features God Concern com problemas de modularidade e estabilidade do sistema [22]. A manifestação transversal oposta a God Concern é caracterizada como Black Sheep. Essa define uma feature transversal que é implementada por alguns trechos de código espalhados em diferentes classes do sistema [20]. A feature Black Sheep não agrega muita responsabilidade e sua remoção não impacta drasticamente o funcionamento do sistema. Por exemplo, Black Sheep ocorre quando

8 Tabela V Métricas de localização Feature Tipo de Localização Suporte Cognitivo Diag. Atividades Diag. Estados Logging StartMethod EndMethod BeforeReturn NestedCommand nenhuma classe implementa exclusivamente a feature que se encontra espalhada em pequenos trechos de código, tais como chamadas de métodos ou acessos a atributos. A feature Logging segue a forma Black Sheep no ArgoUML- SPL, pois nenhuma classe é completamente dedicada à implementação dessa feature (Tabela IV). Entretanto, a feature se espalha por alguns métodos (Tabela IV) e se entrelaça a outras features (Tabela III). Engenheiros de software devem estar atentos a uma feature que se manifesta como Black Sheep, pois estudos revelam correlação moderada entre este tipo de feature e estabilidade do sistema [22]. Diferentemente de God Concern e Black Sheep, Octopus define uma feature transversal que se encontra parcialmente modularizada em uma ou mais classes [20]. Apesar de modularizada em algumas classes, a feature Octopus também se espalha por várias outras classes do sistema. Portanto, podemos identificar dois tipos de classes nessa manifestação transversal: (i) classes que são completamente dedicadas a implementação da feature representam o corpo do polvo e (ii) classes que usam apenas pequenas partes de seu código para implementar a feature representam os tentáculos do polvo. Com base nessa definição, podemos identificar pelos dados da Tabela IV duas features que seguem a forma Octopus: Diagrama de Estados e Diagrama de Atividades. Em ambos os casos, podemos observar tanto classes completamente dedicadas (corpo) quanto classes que usam apenas alguns de seus métodos na implementação da feature (tentáculos). Assim como Black Sheep, features que se enquadram na forma Octopus apresentam moderada a elevada correlação com estabilidade do sistema [22]. Portanto, essas features devem ser cuidadosamente avaliadas pelos engenheiros de software e possivelmente refatoradas. B. Modularização por meio de Aspectos: É viável? O conjunto de métricas apresentado na Seção IV fornece dados importantes para que se possa avaliar uma possível refatoração das features selecionadas por meio de uma tecnologia de modularização tal como aspectos. Uma análise mais detalhada das informações providas pelas Tabelas I a V, nos permite avaliar quais das features apresentamse como candidatas mais aptas a uma refatoração dessa natureza. A princípio, pode-se vislumbrar que a feature Suporte Cognitivo pode ser facilmente implementada com o uso de aspectos, uma vez que de acordo com a Tabela I ela é a feature que encontra-se melhor modularizada no sistema, pois sua implementação está concentrada em alguns pacotes e classes específicas. Entretanto, de acordo com os dados da Tabela IV, essa feature é a segunda colocada em utilização de construções de granularidade fina em sua implementação, ficando atrás apenas da feature Logging. Construções de granularidade fina são as mais difíceis de serem extraídas para aspectos [16]. As features Diagrama de Estados e Diagrama de Atividades possuem uma complexidade extra para serem refatoradas em aspectos, devido à natureza entrelaçada de sua implementação, conforme pode ser visto na Tabela III. Loging é frequentemente citada como sendo uma feature que apresenta características que a tornam candidata a refatoração por meio de aspectos. Em nosso trabalho, essa feature foi a que apresentou maior número absoluto de trechos de código em condições favoráveis para instrumentação por meio pontos de junção, conforme pode ser verificado na Tabela V. Entretanto, em termos relativos, esse número ainda é pequeno frente ao total de comandos que implementam essa feature (260 comandos dos 1155, ou seja 22,5%). Além disso, foi verificado que as mensagens que são exibidas pelas chamadas de logging são diferentes umas das outras em 84,5% dos casos, o que demandaria uma extensa implementação de diferentes aspectos para cada diferente mensagem. Isto é, os aspectos implementados certamente possuíram um baixo grau de quantificação. Diante desse cenário, podemos afirmar preliminarmente que seria complexo refatorar qualquer das features usando uma tecnologia para modularização física de interesses transversais, como aspectos. VI. Trabalhos Relacionados A extração do ArgoUML-SPL foi motivada pelo fato de a maioria dos trabalhos na área de linhas de produtos se basear em sistemas de demonstração, construídos em laboratório. Por exemplo, três linhas de produtos são frequentemente usadas em tais trabalhos: Expression Product Line (EPL) [4], Graph Product Line (GPL) [5] e Mobile Media Product Line (MMPL) [6]. A EPL consiste em uma gramática de expressões cujas variabilidades incluem tipos de dados (literais), operadores (negação, adição etc) e operações (impressão e avaliação). A EPL completa, implementada em Java, possui apenas 2 KLOC. A GPL

9 é uma linha de produtos na área de grafos, cujas variabilidades incluem características das arestas (direcionadas ou não direcionadas, com peso ou sem peso etc), métodos de busca (em profundidade ou em largura) e alguns algoritmos clássicos de grafos (verificação de loops, caminho mais curto, árvore geradora mínima etc). A GPL completa possui apenas 2 KLOC. Por fim, a MMPL é uma linha de produtos para dispositivos móveis, cujo objetivo é implementar aplicações para gerência de documentos multimídia, incluindo fotos, vídeo e músicas. Além do tipo de mídia, a MMPL inclui outras variabilidades, como transferência de documentos via SMS e algumas operações sobre os documentos gerenciados (criação, remoção, visualização, etc). A MMPL completa possui apenas 3 KLOC. Com o objetivo de avaliar a aplicação de AspectJ na implementação de variabilidades em linhas de produtos, Kästner, Apel e Batory extraíram diversas features do gerenciador de bancos de dados Oracle Berkley DB (um sistema de 84 KLOC) [24]. Inicialmente, eles identificaram um total de 38 features nesse sistema, incluindo features relacionadas com persistência, transações, cache, logging, estatísticas, sincronização de threads, etc. No entanto, devido a limitações técnicas de AspectJ, eles não conseguiram refatorar algumas features de maior granularidade, como o sistema de persistência do bando de dados. As features que foram extraídas correspondem a cerca de 10% do tamanho do sistema. Assim, por envolver um sistema real, de médio para grande porte e de grande complexidade, considera-se que esse trabalho é o que mais se aproxima dos objetivos que nos levaram a refatorar o ArgoUML. No entanto, as duas experiências possuem algumas diferenças importantes: (a) em nossa experiência, conseguimos refatorar todas as features propostas inicialmente, incluindo aquelas de maior granularidade (como os diagramas UML); (b) em nossa experiência, o total de código refatorado foi maior (cerca de 14 KLOC, contra 8 KLOC no caso do Berkley DB); (c) o ArgoUML-SPL encontra-se publicamente disponível, de modo a facilitar e incentivar seu uso pela comunidade de pesquisadores em linhas de produtos. No mais, as duas linhas de produtos (ArgoUML- SPL e Berkley DB) se complementam, pois oferecem pesquisadores a possibilidade de explorarem suas abordagens em dois sistemas heterogêneos e, assim, permitindo a generalização dos resultados de experimentos. Recentemente, Liebig et al. realizaram um extenso estudo com o objetivo de avaliar como diretivas de préprocessamento são efetivamente usadas para implementar variabilidades [15]. O trabalho envolveu a análise de quarenta sistemas (com tamanhos variando entre 10 KLOC até 1 MLOC), todos eles implementados em C. No entanto, como os sistemas não foram refatorados, as variabilidades consideradas incluem basicamente features de nível muito baixo, normalmente selecionadas por meio de parâmetros de linhas de comando (por exemplo, opções de depuração, otimização ou portabilidade, no caso dos compiladores analisados no trabalho). Por outro lado, no presente trabalho, em vez de analisar features de baixo nível de diversos sistemas legados, optou-se por analisar features de mais alto nível de um único sistema (ArgoUML), o qual teve que ser devidamente refatorado a fim de permitir a geração de diversos produtos. Por fim, diversas métricas que utilizamos para avaliar a extração do ArgoUML-SPL incluindo métricas como LOF e SD foram originalmente propostas no trabalho de Liebig et al. Anualmente, durante a Software Product Line Conference (SPLC) são escolhidos exemplos de sucesso de implantação prática dos princípios de linhas de produto, que passam a integrar o Hall da Fama dessa abordagem de desenvolvimento [25]. No entanto, esses casos não necessariamente implicam na separação física ou na anotação de código responsável pela implementação de variabilidades. Ou seja, em algumas linhas de produtos premiadas, o reúso se dá apenas em termos de arquitetura de software, processo de desenvolvimento, plataforma de execução e componentes comuns [26]. Além disso, via de regra, as linhas de produto premiadas são sistemas comerciais, que não estão publicamente disponíveis para realização de pesquisas. VII. Conclusões Neste trabalho, foi descrita uma experiência prática de extração de uma linha de produtos de software a partir de um sistema real (ArgoUML). No total, foram extraídas quatro features desse sistema (Diagrama de Atividades, Diagrama de Estados, Logging e Suporte Cognitivo). As principais contribuições do trabalho são as seguintes: Extração de uma linha de produtos de um sistema real, de relativa complexidade e tamanho. A versão utilizada no trabalho do ArgoUML possui cerca de 76 KLOC, sendo que aproximadamente 14 KLOC foram ao todo delimitadas por meio de diretivas de pré-processamento. Esse é um diferencial importante em relação aos trabalhos normalmente desenvolvidos na área. Em primeiro lugar, por utilizar um sistema real (com comunidade de usuários, comunidade de desenvolvedores, diversas versões liberadas, novas versões previstas para serem liberadas etc). Em segundo lugar, no melhor do nosso conhecimento, a quantidade de código refatorada no ArgoUML é a maior dentre todos os outros sistemas usados como estudo de caso em trabalhos na área de linhas de produtos. Disponibilização pública da linha de produtos extraída, a qual se encontra hospedada no próprio repositório de versões do ArgoUML (na seguinte URL: Essa característica é fundamental para que outros pesquisadores possam utilizar ArgoUML-SPL como referência de linha de produtos em seus trabalhos. Definição de um arcabouço para avaliação de features delimitadas em um sistema por meio de diretivas de pré-processamento. Esse arcabouço foi inspirado em um conjunto de métricas proposto originalmente

10 por Liebig et al. [15]. No entanto, novas métricas foram incluídas no mesmo, como aquelas relativas ao grau de espalhamento e aninhamento. O arcabouço proposto permite, por exemplo, uma análise das features refatoradas por meio de diferentes perspectivas, incluindo tamanho, transversalidade, granularidade e localização no código. Uma análise combinada dessas diferentes perspectivas permite entender o comportamento das features refatoradas, permitindo inclusive caracterizar o seu comportamento no código (conforme realizado na Seção V-A). Apesar de extenso (cobrindo cerca de 14 KLOC), o número de features refatoradas no estudo é relativamente pequeno (apenas quatro features). Como trabalho futuro, pretende-se continuar a refatoração de features do ArgoUML, pretendendo chegar a um conjunto de mais uma dezena de features refatoradas. Acredita-se que a disponibilização pública da LPS extraída possa contribuir nesse sentido, permitindo que novos pesquisadores e desenvolvedores ajudem nessa tarefa. Pretende-se também investir na migração das features refatoradas para paradigmas de programação como orientação por aspectos e orientação por features. Inclusive, conforme afirmado no trabalho, diretivas de préprocessamento foram escolhidas como primeira tecnologia para delimitação de features no ArgoUML-SPL exatamente como esse objetivo, isto é, fornecer um baseline que possa ser futuramente usado para comparação com outras técnicas de modularização. Por fim, a delimitação de features de forma manual, por meio de #ifdef e #endif, se revelou uma tarefa tediosa e repetitiva. Assim, pretende-se investigar o uso de técnicas automáticas ou semi-automáticas para marcação de features, como aquelas descritas em [16], [27]. Agradecimentos Este trabalho foi apoiado pela FAPEMIG e CNPq. Referências [1] P. Clements and L. M. Northrop, Software Product Lines: Practices and Patterns. Addison-Wesley, [2] V. Sugumaran, S. Park, and K. C. Kang, Introduction to the special issue on software product line engineering, Communications ACM, vol. 49, no. 12, pp , [3] D. L. Parnas, On the design and development of program families, IEEE Transactions on Software Engineering, vol. 2, no. 1, pp. 1 9, [4] R. Lopez-Herrejon, D. Batory, and W. R. Cook, Evaluating support for features in advanced modularization technologies, in 19th European Conference on Object-Oriented Programming (ECOOP), ser. LNCS, vol Springer-Verlag, 2005, pp [5] R. E. Lopez-Herrejon and D. S. Batory, A standard problem for evaluating product-line methodologies, in Third International Conference on Generative and Component-Based Software Engineering (GPCE), ser. LNCS, vol Springer-Verlag, 2001, pp [6] E. Figueiredo, N. Cacho, C. Sant Anna, M. Monteiro, U. Kulesza, A. Garcia, S. Soares, F. C. Ferrari, S. S. Khan, F. C. Filho, and F. Dantas, Evolving software product lines with aspects: an empirical study on design stability, in 30th International Conference on Software Engineering (ICSE), 2008, pp [7] (2010) Argouml-spl. [Online]. Available: tigris.org/ [8] L. Tolke, M. Klink, and M. van der Wulp. (2010) Argouml cookbook. [Online]. Available: Cookbook [9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, [10] J. E. Robbins and D. F. Redmiles, Cognitive support, uml adherence, and xmi interchange in argo/uml, Information & Software Technology, vol. 42, no. 2, pp , [11] H. Spencer, #ifdef considered harmful, or portability experience with C News, in USENIX Conference, 1992, pp [12] B. Adams, W. D. Meuter, H. Tromp, and A. E. Hassan, Can we refactor conditional compilation into aspects? in 8th ACM International Conference on Aspect-Oriented Software Development (AOSD), 2009, pp [13] S. Apel and C. Kästner, Virtual separation of concerns - a second chance for preprocessors, Journal of Object Technology, vol. 8, no. 6, pp , [14] S. E. Sim, S. Easterbrook, and R. C. Holt, Using benchmarking to advance research: A challenge to software engineering, in Proceedings of the 25th International Conference on Software Engineering (ICSE), 2003, pp [15] J. Liebig, S. Apel, C. Lengauer, C. Kästner, and M. Schulze, An analysis of the variability in forty preprocessor-based software product lines, in 32nd International Conference on Software Engineering (ICSE), [16] C. Kästner, S. Apel, and M. Kuhlemann, Granularity in software product lines, in ICSE 08: Proceedings of the 30th international conference on Software engineering. New York, NY, USA: ACM, 2008, pp [17] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold, An overview of AspectJ, in 15th European Conference on Object-Oriented Programming (ECOOP), ser. LNCS, vol Springer Verlag, 2001, pp [18] M. Nassau and M. T. Valente, Object-oriented transformations for extracting aspects, Information and Software Technology, vol. 51, no. 1, pp , [19] M. Nassau, S. Oliveira, and M. T. Valente, Guidelines for enabling the extraction of aspects from existing object-oriented code, Journal of Object Technology, vol. 8, no. 3, pp. 1 19, [20] S. Ducasse, T. Gîrba, and A. Kuhn, Distribution map, in International Conference on Software Maintenance (ICSM), 2006, pp [21] M. Eaddy, T. Zimmermann, K. D. Sherwood, V. Garg, G. C. Murphy, N. Nagappan, and A. V. Aho, Do crosscutting concerns cause defects? IEEE Transactions on Software Engineering, vol. 34, no. 4, pp , [22] E. Figueiredo, B. C. da Silva, C. Sant Anna, A. F. Garcia, J. Whittle, and D. J. Nunes, Crosscutting patterns and design stability: An exploratory analysis, in International Conference on Program Comprehension (ICPC), 2009, pp [23] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Improving the Design of Existing Code. Addison- Wesley, [24] C. Kästner, S. Apel, and D. Batory, A case study implementing features using AspectJ, in 11th International Software Product Line Conference (SPLC), 2007, pp [25] S. P. L. Conference. (2010) Product line hall of fame. [Online]. Available: [26] P. Mohagheghi and R. Conradi, An empirical investigation of software reuse benefits in a large telecom product, ACM Transactions on Software Engineering Methodology, vol. 17, no. 3, pp. 1 31, [27] V. Borges and M. T. Valente, Coloração automática de variabilidades em linhas de produtos de software, in III Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS), 2009, pp